“개발 일정을 자꾸 딜레이되요.”
“기술부채? 그건 일정을 늘리는 핑계 같던데…”
창업자나 대표라면 한 번쯤 해봤을 생각입니다.
이 글은 개발을 모르는 리더가 좋은 개발자와 합리적 일정을 판단하는 기준을 고민하며 쓴 글입니다.
회사를 창업하시고 A부터 Z까지 공을 들여 사업을 일구어오신 창업자분들, 그리고 이제 내부에 개발자들을 보유하고 IT 서비스를 운영하시는 회사의 대표님들이 가지신 공통점들이 있습니다.
“제가 다른 것은 다 할 수 있고 구성원들에게 지시도 할 수 있고 잘하고 있는지 못하고 있는지를 알겠는데, 개발은 모르겠습니다. 그 놈의 기술부채라는 것 때문에 처음부터 시간을 쓰고 공을 들여 잘 만들어야 되는 건 알겠는데 그래도 원하는 기능, 목표했던 것을 빨리 만들면 좋겠습니다.”
이 분들의 입장에서 보면 당장은 빨리 원하는 것을 만들어서 배포해주는 개발자가 잘하는 개발자입니다. 그러다가 개발자들과 대화를 하고 경험을 쌓으신 분들은 기술부채라는 것을 이해하게 되십니다. 몇 년이 지나 서비스가 비대해진 상황에서 기능을 조금 크게 변경하려고 하면 이전과 다른, 기대보다 더 커진 일정을 말씀드리는 개발자를 보게 되십니다. 그들은 한결같이 지금 개발된 코드가 매우 복잡하거나 데이터베이스가 깔끔하지 않다고 하며 이것을 정리할 시간이 필요하다고 합니다. 코드 리팩토링이나 데이터베이스 개선, 이런 기능 추가 본연의 업무 외의 작업이 계속해서 따라다니게 됩니다.
그러다보니 기술부채를 해결하려고 해도 사전 정리하는 시간이 필요하고, 기술부채를 두고 기능을 빠르게 만든다고 해도 암시적인 도메인에 대한 이해 없이 배포 후 잦은, 치명적인 에러를 만나게 됩니다. 그러다보니 개발자들은 기술부채를 해결하지 않더라도 기존 코드 이해 및 점검 차원에서 일정을 보수적으로 잡을 수밖에 없습니다. 시간이 지나고 기술부채라는 것이 쌓이게 되면서 고도화되는 과정에서 어쨌든 과거보다 일정이 더 필요한 걸 어쩔 수 없이 받아들이게 됩니다.
이것이 소위 말하는 레거시 코드로 인해 늘어나는 일정 산정을 어쩔 수 없이 받아들여야만 하는 회사의 입장으로 보입니다.
조직이 커져가고 레거시 코드가 많아질수록 개발일정은 원하는 대로 나오지 않습니다. 그럼에도 몰아붙이다보면 개발자가 지쳐서 나가게 되거나(이럴 때 꼭 잘하는 개발자가 나갑니다) 버그가 많은 채로 출시되어 사후 관리에 오히려 더 많은 리소스를 쓰게 됩니다.
기대하지 않게 늘어난 일정에 대응하는 방법으로는 어쩔 수 없이 개발자의 일정을 수용하거나, 혹은 타이트한 일정을 요구하여 강행하게끔 할 수도 있습니다. 개발조직에서 공수 산정을 하고 제시하면 그때부터 리소스를 감안한 업무 우선순위를 논하게 되고 개발할 순서를 정하고 일정을 조율하게 됩니다. 경험한 바에 따르면 케이스에 따라 여러 방법으로 일정 조율이 됩니다. 크게는 개발 조직을 신뢰하고 있는 경우와 그렇지 않은 경우로 나눌 수 있습니다.
신뢰를 하는 경우
1. 개발자의 공수를 그대로 받아들이고 이것을 상수로 픽스하고 우선순위 및 기타 일정을 조율합니다. 스프린트 내에서 작은 기능을 개발하는 경우 이렇게 흘러가는 경우가 많습니다.
2. 사이즈가 큰 업무의 경우 공수와 일정이 통제될 확률이 높습니다. 그러나 이 경우에도 공수 세부내역의 항목들을 변경하거나 삭제하는 식으로 변경되고 각 세부 항목의 공수를 받아들이고 작업이 진행됩니다.
신뢰를 하지 않는 경우
1. 가장 극단적인 경우는 개발자의 공수를 파악하기보다 일정을 타이트하게 픽스해 지킬 것을 요구합니다. 기능추가나 서비스 론칭에 대한 날짜를 픽스한 뒤 개발 외적으로 마케팅, 홍보, 기타 운영 관련 업무가 정리되면서 개발도 반드시 그렇게 만들어져야만 하는 상황으로 갑니다. 생각보다 적지 않은 개발자들이 이런 경우에도 익숙한 것으로 보입니다.
2. 개발자의 공수를 파악해 일정 산정을 하지만 그 공수 자체를 통제하는 경우가 있습니다. 왜 그렇게 공수를 산정했는지를 세세하게 파악하고 공수 자체를 줄일 수 있는지에 대해서 초점을 맞춥니다. 외부 신뢰하는 개발자에게 해당 업무의 공수를 의뢰해 비교하는 경우도 있습니다. 개발에 대한 이해도가 떨어질 경우 결국에는 일정을 줄이는 강요 위주의 대화가 됩니다.
이처럼 개발자와 공존하는 회사는 항상 개발자들의 일정을 조율하는 과정에서 믿고 가거나 또는 불만을 가진 채로 일을 진행하거나 공수를 줄이는 압박을 하게 됩니다.
회사를 운영하는 관점에서 내부 개발자들이 잘하는지를 파악하는 것은 어렵지만 중요한 문제입니다. 좋은 개발자를 내부에 계속 남겨야 하고 그러기 위해서 그들을 알아보고 그들에게 좋은 평가를 줄 수 있어야 합니다. 다만 안타깝게도 평가자가 개발을 이해하지 못한다면 반쪽짜리 평가밖에 할 수 없습니다. 이는 역량이라는 지점에서 양과 질을 다 갖춘 좋은 개발자를 평가할 수 없기 때문입니다. 즉, 개발의 질을 평가할 수 없기 때문에 양으로만 평가할 수밖에 없습니다.
이에 대한 좋은 대안은 개발 외적인 항목, 즉 컬처핏이라고 부르는 평가입니다. 회사마다 생각하는 코어 밸류가 다르고 컬처핏 항목도 그에 따라 세부적으로 다르겠지만 대부분 중요하게 생각하는 컬처핏 항목이 있습니다. 공격적이지 않고 방어적이지 않은 태도, 성장욕심, 커뮤니케이션 능력, 끈기와 인내의 그릿, 책임감, 주도성과 오너십 등이 있을 것입니다. 이런 항목들이 개발자가 생산하는 코드의 질이 좋거나 나쁠 수 있는 것에 영향을 미치기에 좋은 대안이라 할 수 있습니다.
개발의 질은 결국 나중에 이것이 얼마나 유지보수, 고도화, 기능 확장에 긍정적 혹은 부정적 영향을 미치는지에 대한 것입니다. 6개월 뒤, 1년 뒤, 2년 뒤에 그 코드에서 혹은 그 코드를 의존하여 다시 개발을 하는 사람들이 얼마나 쉽게 개발을 할 수 있는지에 대한 문제입니다. 좋은 코드는 이후 개발을 더 빠르게 할 수 있습니다. 적절히 확장성을 고려해 데이터베이스를 설계하고 아키텍처를 설계했다면, 그리고 코드의 가독성이 충분히 좋다면 다시 개발하는 것보다 더 빠르게 고도화가 가능합니다. 반면에 나쁜 코드는 정확히 그 반대로 이후 개발을 더 느리게 만듭니다. 가장 치명적인 경우가 이 코드는 도저히 손을 댈 수 없으니 다시 만들어야 할 때입니다. 흔히 말하는 레거시 마이그레이션입니다.
개발의 양을 빠르게 생산하는 것이라고 한다면 단기적으로 눈에 쉽게 띄기 때문에 평가하기 어렵지 않습니다. 하지만 개발의 질은 나중에 드러나기 때문에 판단할 수가 없고 그렇기에 이런 태도를 가진 사람이라면 잘하겠지라는 생각으로 컬처핏으로 유추하는 것도 좋은 판단이 될 수 있습니다.
일정 이상 조직의 규모를 갖추게 되면 개발매니저가 내부에서 혹은 외부에서 지정되어 의무를 하게 됩니다. 내부 개발자들을 적합하게 평가하고 신뢰할 수 있는 개발조직을 갖추기 위해서 가장 좋은 방법은 개발매니저를 채용하는 것이라 생각합니다. 여기에 몇 가지 이유가 있습니다.
1. 개발매니저는 개발의 질을 평가할 수 있습니다.
개발자를 매니징하고 그들을 평가하는 매니저는 보통 개발을 이해하고 있습니다. 따라서 현재 코드 상태가 어떻고 그 코드를 개발한 개발자의 코딩 능력을 파악할 수 있습니다. 즉, 개발의 질과 양을 판단할 수 있고 좋은 개발자를 적합하게 평가해 차후 개발이 지속될 때도 빠르게 질 좋은 코드가 나오는 환경을 유지할 수 있습니다.
2. 개발매니저는 개발자의 퀄리티를 더 높일 수 있습니다.
코드리뷰나, 테스트, 배포 프로세스 등 개발문화를 만들고 이를 규율 있게 실행해 가면서 개발자들이 상호간, 프로세스 내에서 좋은 영향을 받을 수 있도록 할 수 있습니다. 구성원들이 실무에 집중하고 있을 때 큰 관점에서 생산성을 확보하는 방안을 고민할 수 있고 구성원들에게 코드의 질을 높일 수 있는 올바른 피드백을 주어 그들이 더 성장할 수 있게 할 수 있습니다.
3. 좋은 개발자를 채용할 수 있습니다.
경험이 많은 매니저는 좋은 개발자를 알아볼 수 있습니다. 면접과 온보딩 과정을 거쳐 충분히 그 개발자를 파악할 수 있고 궁극적으로 좋은 개발자만 계속 남기는 선순환을 만들어낼 수 있습니다. 반대로 구직하는 개발자 입장에서도 좋은 리더가 있는 것을 보고 그 회사에 가고 싶은 마음이 더 들 수 있습니다.
그러나 회사가 원하는 좋은 개발매니저는 하나의 중요한 역량이 필요합니다. 그리고 그것이 다른 어떤 경험이나 가치관보다 더 중요하다고 생각합니다.
회사 입장을 고려하는 것과 밸런스를 고려하는 것은 각각 개별적이고 똑같이 중요합니다.
먼저 개발 매니저는 회사의 입장을 고려할 수 있어야 합니다. 즉, 어느 정도는 회사의 편이어야 합니다. 어떤 개발매니저는 구성원들의 입장에서 또는 개발조직의 입장에서 의사결정을 합니다. 이것이 때로는 회사 입장에서는 큰 문제가 되고 개발조직과 벽을 쌓게 되는 계기가 되기도 합니다. 그들이 가지고 있는 생각은 아래와 같습니다.
1. 타이트한 일정을 강요하는 것은 그들의 동기부여를 깎고 결국 좋은 개발자를 떠나보낼 것이라고 생각합니다.
2. 좋은 코드를 만드는 것이 중요하고 그렇게 개발하기 위해 충분한 개발일정을 요구합니다.
3. 개발자를 보호하는 것이 어쩌면 그 리더의 가장 큰 목표입니다. 타 부서나 비개발자와의 협업에서 종종 보수적, 방어적일 수 있습니다.
좋은 개발 매니저는 회사 입장을 고려해야 합니다. 이는 회사의 비즈니스 가치를 고려할 수 있어야 한다는 것입니다. 다만 너무 회사 입장에서 구성원들을 압박해서도 안 됩니다. 밸런스를 맞추어서 때에 따라 회사의 입장에서, 그리고 구성원의 입장에서 상황을 보고 의사결정을 할 수 있어야 합니다. 그리고 이런 밸런스 있는 생각을 갖추는 것이 굉장히 어렵다고 생각됩니다.
비즈니스 가치를 안다는 것은 내가 지금 하고 있는 개발이 회사의 비즈니스에 어떤 긍정적인 영향을 줄 수 있는지를 이해하고 있다는 것입니다. 이 제품이 나와야 할 타이밍을 이해하고 그에 따라 개발항목을 조율하고 기획까지 참여하면서 의견을 제시해 조율합니다. 3년 뒤에도 누구나 우러러볼 개발작품을 만드는 것이 아니라 비즈니스적으로 적합하게 필요한 항목을 원하는 타이밍에 출시할 수 있게 하는 것이 중요합니다. 모든 개발자는 좋은 코드에 대한 집착이 있고 이것이 그들의 가치를 높여줄 수 있으므로 유지보수 좋은 개발산출물을 만드는 것이 물론 필요합니다. 하지만 이것만 생각하면 안 되는 것이 바로 회사입장을 밸런스 있게 고려할 줄 알아야 한다는 점입니다.
특히 개발매니저가 이 생각을 갖추고 있지 않다면 좋은 개발문화와 개발자들이 점차 갖춰져가고 있음에도 회사의 비즈니스에 의미 있는 기여를 할 수 없습니다. 비개발조직과 개발조직의 동상이몽이 시작되는 것입니다.
회사 입장을 고려한 의사결정을 진심으로 한다면 제품을 근본적으로 이해하고 초기 단계부터 의견을 제시하고 개발 일정을 축소하고 의미 있는 기능을 만드는데 기여할 수 있습니다. 그리고 구성원들이 모두 제품을 이해하고 무엇을 위해 개발을 하고 있는지 회사 입장에서 고려할 수 있게 만들 수 있습니다.
너무나 당연하게도 비개발조직은 이 개발매니저와 개발조직을 더 신뢰할 수 있습니다. 그리고 신뢰가 쌓이는 협업 관계에서 더 고객에게 의미 있는 가치를 전달할 수 있을 것입니다.
개발은 단순 생산이 아닙니다. 좋은 개발조직은, 좋은 코드만큼 좋은 상호작용에서 만들어집니다.
개발매니저의 역할은 ‘보호자’가 아니라, 회사와 개발자 사이의 의미 있는 통역자입니다.
이 통역이 성공해야, 회사는 앞으로 나아갈 수 있습니다.