소규모 조직에서 성장을 설계하는 개발총괄의 역할

우리는 아이러니하게도 스스로 생각하는 것보다 훨씬 더 주변 사람들의 영향을 받으며 살아간다. 개인의 의지와 능력이 중요하지 않다는 의미는 아니지만, 현실적으로는 개인의 성과와 성장 속도가 속한 환경의 평균값에 강하게 수렴하는 경우가 많다.

 

이를 설명하기 위해 두 개의 대학교를 가정해 보자. 성적 수준이 매우 높은 A대학교와, 상대적으로 성적이 낮은 B대학교가 있다. 홍길동이라는 학생이 주변 환경의 영향을 거의 받지 않는 유형이라면, 어느 학교에 가더라도 일정 수준 이상의 성과를 낼 수 있을 것이다. 그러나 동수라는 학생이 주변 환경의 영향을 많이 받는 유형이라면 이야기는 달라진다. 동수는 본래 우수한 학생일 수 있지만, A대학교가 아닌 B대학교에 진학할 경우 성적이 하락할 가능성이 높아진다.

 

이는 단순히 개인의 역량 문제라기보다 환경의 문제에 가깝다. 두 대학교의 커리큘럼이 동일하더라도, 수업의 깊이와 이를 받아들이는 학생들의 수준에는 차이가 발생한다. A대학교에서는 한 학생이 던진 질문이 다른 학생들의 이해 수준을 끌어올리고, 그 과정에서 강의 자체의 밀도가 높아진다. 반면 B대학교에서는 애초에 문제의식을 느끼지 못하는 주제가 많아, 동일한 내용임에도 학습의 깊이는 얕아질 수밖에 없다.

 

공부량에서도 차이는 분명하게 나타난다. B대학교에서는 일주일에 1~2시간 정도의 학습만으로도 과 내 상위권을 유지할 수 있을 수 있지만, A대학교에서는 하루 10시간을 공부해도 부족하다고 느끼는 상황이 발생한다. 물론 이러한 비교에는 평균의 함정이 존재한다. B대학교에도 소수의 매우 우수한 학생은 분명 존재한다. 그러나 집단 전체가 만들어내는 분위기와 기준선이 개인에게 미치는 영향까지 부정하기는 어렵다.

 

결국 동일한 동수라는 사람이, 환경의 영향을 많이 받는다는 이유만으로 어떤 조직에 속하느냐에 따라 성장 속도와 도달할 수 있는 수준이 달라질 수 있다는 결론에 이른다. 냉정하게 보았을 때, 우리 주변에는 홍길동과 같은 환경 독립형 인간보다는 동수와 같은 환경 의존형 인간이 훨씬 더 많다.

 

이제 이 관점을 대학교가 아니라 개발조직에 적용해 보자.

 

겉으로 보기에는 비슷한 기술 스택과 동일한 업무를 수행하는 두 개발조직이 있다고 가정하자. 한 조직에서는 코드 리뷰가 형식적으로 이루어지고, “동작하면 된다”는 기준이 지배적이다. 기술적 의사결정의 이유를 묻는 질문은 귀찮은 것으로 취급되고, 일정과 납기가 최우선 가치가 된다.

 

반면 다른 조직에서는 이 개발을 왜 해야하고, 어떤 임팩트가 있으며, 어떤 도메인과 타 기능에 영향을 주고 향후 어떤 유사한 요구사항이 함께 발생할 지를 고민해보고, 또 코드 리뷰를 통해 추가적인 학습의 장이 된다. 또한, 설계 의도와 책임 분리에 대한 질문이 자연스럽게 오가고, 성능, 확장성, 트레이드오프에 대한 논의가 반복되며, 개발자 개인의 기준선 자체가 계속해서 상향된다.

 

이 두 조직에 동일한 개발자가 속했을 때의 결과는 명확하다. 개인의 능력이나 잠재력이 달라진 것이 아니라, 주변에서 오가는 질문의 수준과 허용되는 기술적 기준이 달라졌을 뿐인데도, 몇 년 후의 실력 격차는 분명하게 벌어진다. 대부분의 개발자는 자신이 속한 조직의 평균적인 사고 수준과 기술적 깊이에 수렴하게 된다. 결국 개발자의 성장은 개인의 의지나 노력만의 문제가 아니다. 자신이 어떤 환경에 몸을 두고 있는지, 어떤 기준선 속에서 매일 일을 하고 있는지가 성장의 방향과 속도를 결정한다. 이 사실을 인정하지 않는 순간, 연차는 쌓이지만 실력은 정체되는 개발자가 될 가능성은 높아진다.

 

소규모 개발조직일수록 이 문제는 더욱 치명적이다. 인원이 적다는 이유로, 혹은 당장의 일정과 생존을 이유로 기준선을 낮추는 순간, 조직은 빠르게 B대학교형 환경으로 기울어진다. 코드 리뷰는 형식이 되고, 설계 논의는 비효율로 치부되며, 기술적 질문을 던지는 사람은 “일을 느리게 하는 사람”이 된다. 이 상태가 지속되면 조직은 두 가지 부작용을 겪게 된다. 하나는 성장 욕구가 있는 인재가 먼저 떠난다는 점이고, 다른 하나는 남아 있는 구성원들조차 점차 평균 이하의 기준선에 안주하게 된다는 점이다.

 

이때, 개발총괄(CTO. Head, 개발팀장 등)의 역할이 중요하다. 소규모 조직에서 모든 영역을 단번에 A대학교 수준으로 끌어올리는 것은 현실적으로 불가능하다. 중요한 것은 모든 영역을 바꾸는 것이 아니라, 조직의 기준선을 결정하는 핵심 지점을 의도적으로 A대학교로 만드는 것이다.

 

우선적으로 손대야 할 것은 코드와 설계가 평가되는 방식이다. 코드 리뷰는 단순한 승인 절차가 아니라, 조직 내 사고 수준을 전파하는 가장 강력한 수단이다. 리뷰에서 “왜 이렇게 설계했는가”, “이 책임은 어디에 두는 것이 맞는가”, “다른 선택지는 무엇이었는가”와 같은 질문이 반복적으로 등장하기 시작하면, 구성원들은 자연스럽게 그 수준에 맞춰 사고하기 시작한다. 이는 추가적인 교육이나 강제 규칙보다 훨씬 강력하게 작동한다.

 

물론 이 모든 논의에는 한 가지 중요한 전제가 빠져서는 안 된다. 그것은 비즈니스 속도다. 개발총괄의 역할은 개발조직을 이상적인 A대학교로 만드는 데 있지 않다. 조직은 학습 기관이 아니라, 비즈니스를 전진시키기 위해 존재한다. 기술적 완성도를 이유로 시장 대응 속도를 잃는다면, 그 조직은 또 다른 형태의 실패를 맞이하게 된다.

 

따라서 소규모 개발조직을 A대학교형 환경으로 전환하는 과정은, 언제나 비즈니스 속도와의 균형 위에서 설계되어야 한다. 모든 코드 리뷰를 학술 토론처럼 만들거나, 모든 설계를 완벽하게 정제하려는 시도는 오히려 조직의 기동성을 떨어뜨릴 수 있다. 이때 형성되어야 것은 “가장 이상적인 개발 환경”이 아니라, 현재 비즈니스 단계에서 허용 가능한 최선의 기준선이다.

 

이 관점에서 보면, A대학교형 조직이란 단순히 기술 수준이 높은 조직을 의미하지 않는다. 오히려 빠른 의사결정을 가능하게 하는 공통된 사고 기준을 가진 조직에 가깝다. 설계 논의가 반복될수록 느려지는 조직이 아니라, 이미 합의된 기준 덕분에 논의가 짧아지는 조직이 A대학교형 조직이다.

 

코드 리뷰 역시 마찬가지다. 모든 리뷰에서 깊이 있는 논의를 요구하는 것은 현실적이지 않다. 대신 개발총괄은 “속도를 늦추지 않으면서도 기준선을 유지해야 하는 영역”과 “빠른 실행이 우선되는 영역”을 명확히 구분해야 한다. 핵심 도메인, 장애 가능성이 높은 영역, 장기 비용이 큰 설계에는 A대학교 수준의 엄격함을 적용하고, 실험적 기능이나 단기 검증 영역에는 속도를 우선하는 판단이 허용되어야 한다.

 

기술적 의사결정의 가시화 역시 동일하다. 모든 결정을 문서화하는 것이 목적이 아니다. 중요한 결정만 남기되, 그 기록이 다음 결정을 빠르게 만드는 방향으로 기능해야 한다. 문서가 학습 자료가 아니라 의사결정 가속 장치로 작동할 때, 비즈니스 속도와 기술 수준은 충돌하지 않는다.

 

질문 문화 또한 마찬가지다. 좋은 질문은 조직을 느리게 하지 않는다. 오히려 잘못된 방향으로 빠르게 가는 것을 막아준다. 이때 경계해야 할 것은 질문 그 자체가 아니라, 질문이 끝없이 결론 없이 반복되는 상태다. 질문은 명확한 결론과 실행으로 이어질 때만 조직의 속도를 지키면서 기준선을 끌어올릴 수 있다.

 

결국 소규모 조직에서의 A대학교화는 “느려지는 것”을 의미하지 않는다. 오히려 단기적인 속도 저하를 감수하더라도, 중장기적으로는 재작업, 장애, 기술 부채로 인한 속도 손실을 줄이는 선택에 가깝다. 비즈니스 속도를 고려하지 않은 기술적 이상주의는 위험하지만, 기술 기준선을 방치한 채 속도만 추구하는 조직 역시 결국 더 큰 속도 저하를 맞이한다.

 

즉, 이 두 극단 사이에서 균형점을 설계하는 것이다. 동수형 인재가 대부분이라는 현실을 인정하면서도, 그들이 비즈니스를 늦추지 않고 성장할 수 있는 환경을 만드는 것이 중요하다.