brunch

매거진 개발자의 생각 꾸러미

라이킷 9 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 서일환 Oct 26. 2020

미래를 향한 '이어개발하기'

기능과 운영의 조화로운 설계

이어달리기를 하려면 달리는 주자들 간에 긴밀한 협업이 이루어져야 한다. 배턴을 들고 달리는 선수는 다른 팀의 선수들보다 더 빨리 뛰기 위해 노력하고, 다음 주자가 유리한 위치에서 출발할 수 있도록 고민한다. 소프트웨어를 개발하는 활동도 이어달리기와 크게 다르지 않다. '달리기'는 짧은 시간 안에 결과가 나오는 활동이지만, '개발하기'는 오랜 시간이 걸리는 일이다. 다음 주자를 생각하지 않는 개발은 장기적으로 좋은 성과를 낼 수 없다.

개발자들은 새로운 것을 만드는 것을 좋아한다. 다른 개발자들이 만들어 놓은 것의 유지를 이어받아 그 위에 계속해서 무엇인가 쌓아 올리는 것을 그다지 좋아하지 않는다. 근데 뭔가 좀 이상하다. 과연 그럴까? 우리는 이미 누군가 만들어 놓은 환경과 도구 그리고 방법론 위에서 활동하고 있다. 그런 측면에서 보자면 개발자들은 단순히 다른 사람이 만들어 둔 것을 확장해 나가는 것 자체를 싫어하는 것은 아닌 것 같다. 결국 개발자들은 기반이 잘 다져진 소프트웨어 위에서 기능을 추가하고 유지 보수하는 것을 원한다고 볼 수 있다.

어떤 프로그램을 새로 만들 때에 개발자들은 흔히 도달해야 하는 목표를 '만드는 것 그 자체'에만 두는 경우가 종종 있다. 하지만 개발은 만드는 것이 전부가 아니다. 개발자의 개발 계획에는 먼 미래까지 미리 내다보고 세우는 백년지대계(百年之大計)가 필요하다. 개발할 때 단순히 기능이 동작하는 것 자체에만 흥미를 느끼는 것은 현재에만 충실한 것이다. 기능 명세서에 있는 기능이 잘 동작한다고 해서 개발자의 과업이 완료되는 것은 아니다.

개발자는 미래를 내다보는 능력이 매우 중요한 직업이라고 생각한다. 현재의 기능을 잘 구현하는 것도 물론 쉬운 일은 아니지만 일정한 시간이 지나면 어느 정도 수준까지는 누구나 할 수 있다. 그러나 미래를 그리면서 개발하는 능력은 시간만이 해결해주는 것은 아니다. 나는 미래를 그리면서 개발할 수 있는 능력이 프로그램의 운영 효율성과 직결되어 있다고 생각한다. 안타깝게도 대부분의 기획서나 기능 명세서에는 앞으로 어떻게 운영을 해야 하는지에 대한 내용은 기술되어 있지 않다. 개발 산출물을 평가하는 기준에도 운영 효율성을 평가하는 사례는 보기 힘들다.

운영 효율성은 '소프트웨어를 사용/변경/유지할 때 필요로 하는 사람의 일을 최소화하는 것'이다.

'소프트웨어를 사용할 때 사람의 일을 최소화하는 것'에 대해서는 운영 효율성의 범주로 봐야 하는지에 대한 이견이 있을지도 모르겠다. 하지만, 결국 사용자 편의성 부족이 변경을 발생시킨다는 관점에서 본다면 직접효과까지는 아니더라도 상당히 큰 간접효과라고 볼 수는 있다. 그것을 위해서는 사용자 경험(UX)을 좋게 하여 사람이 사용하기 효율적인 구조를 만들어 나가야 한다. 사용자의 반복적이고 불필요한 작업은 최대한 자동화하여 없애 나가야 한다.

변경을 위한 사람의 일을 최소화하는 것은 가장 중요하다. 그중에서도 가장 중요한 것은 소스 코드의 정갈함을 유지하는 것이다. 소스 코드는 끊임없는 리팩터링 작업을 통해 쉽게 확장할 수 있는 구조를 깨뜨리지 않고 유지해야 한다. 공정화된 배포 체계를 갖추어서 개발부터 서비스 배포까지의 과정이 명확하고 쉬워야 한다. 그리고 그 체계 또한 지속적으로 운영자에 의해 리팩터링 되고 사용되어야 한다. 소스코드는 언제나 빌드와 실행이 가능한 상태를 유지해야 한다. 다른 서비스나 시스템과 유기적으로 동작해야 할 때 그것들이 없어도 잘 동작하도록 구성해야 한다.

서비스를 유지하는 일에도 사람의 일을 최소화해야 한다. '유지'란 단어는 서비스가 아무런 변동이 없는 안정된 상태라는 느낌을 준다. 관리자들은 으레 유지를 하는 것은 비용이 들지 않는 작업이라고 생각하는 경우가 많다. 하지만 안정된 상태를 유지하는 것은 생각보다 비용이 많이 드는 작업이다. 유지 상태에서는 이전에 발생했던 이슈에서 다음 이슈가 발생하기까지의 시간이 어느 정도 걸리기 마련이다. 움직이고 있지 않은 상태에서 발생하는 이슈를 해결하기 위해서는 다시 움직여야 한다. 그 움직임을 만들기 위해서는 어느 정도 수준의 모멘텀이 필요하다. 그러한 모멘텀을 만들어내는 활동은 개발자들의 주위를 분산시키고 의지를 고갈시키는 경향이 있다. 이를 위한 활동에는 인프라 작업이나 장애로부터의 영향도를 최소화하는 것과 같은 것들이 있다. 이러한 이벤트가 발생했을 때 빠르게 감지해내고 자동으로 복구할 수 있는 방안을 고민해야 한다.

오래된 개발팀이 흔하게 빠지는 사이클이 있다.

프로젝트 초반에는 새로운 서비스를 만들기 위한 구성원들의 의지가 충만하다. 모든 구성원이 팀의 업무에 열정적이다. 열정으로 도전한 구성원들의 프로젝트는 성공할 가능성이 높다.

프로젝트 중반에는 기존의 것을 유지하면서 더 많은 기능을 만들기 위해 구성원이 늘어난다. 초반에 큰 기여를 했던 핵심 개발자들은 다른 프로젝트를 찾아 떠나기 시작한다. 왠지 모르게 프로젝트 구성원들의 활기는 이전과 같지 않다.

프로젝트 후반, 즉 오래된 개발팀의 현재에는 언제부터인지 서비스의 문맥은 크게 이상하지 않은데 코드의 문맥은 이상해져 있다. 해당 서비스의 담당 개발자들이 여러 차례 교체되었다. 프로젝트를 담당하는 개발자들은 스스로를 엔지니어가 아니고 청소부라고 생각하기 시작한다. 이 지점에 이르면 손을 쓰기는 이미 늦었다.

결론적으로 이 문제를 해결하기 위해서는 프로젝트 초반부터 소프트웨어의 미래 운영에 대한 큰 그림을 그려야 한다. 서비스의 사용자나 고객이 떠나는 것은 큰 문제이지만 프로젝트의 구성원이 지치는 것은 더욱 큰 문제다. 물론 개발자 개인으로 보면 '나는 초반에 재밌는 부분만 하고 빠지는 게 좋은데?'라고 생각할지도 모르겠다. 그런데 결국 커밋 로그, 주석, 문서는 남는다. 후세의 사람들은 그 개발자를 좋은 개발자로 평가 할리가 만무하다. 그것이 또 언제 어디서 자신에게 화살이 되어 돌아올지 누가 알겠는가? 그런 걸 차치하고서라도 엔지니어라면 응당 잘 만드는 것이 희망이 되어야 하지 않나 생각한다. 개발을 할 때는 소프트웨어 아키텍처를 구상하는 것만큼이나 운영에 대한 설계도 중요한 작업이다. 개발을 위한 설계와 운영을 위한 설계는 반드시 병행되어야 한다. 소스코드를 지속적으로 리팩터링 하여 개선해 나가듯이 운영체계도 지속적으로 개선해야 한다.

keyword