이 경우, 프로젝트가 망하는 이유는 기술이 아니라 ‘수주 시점의 판단’에서 이미 결정됩니다.
프로젝트별 사일로 생성
속도를 위해 분리한 결정이 시간이 지날수록 조직을 분리한다.
대부분의 조직은 사일로가 문제라는 사실을 이미 알고 있습니다.
하지만 프로젝트 수주가 일정과 무관하게 늘어나기 시작하면 이 전제는 쉽게 무너집니다.
빠른 대응을 위해 특정 인력들이 반복적으로 같은 프로젝트에 배치되기 시작하면서,
공식적인 협업 구조보다 비공식적인 커뮤니케이션을 우선하게 됩니다.
그렇게 이 인력 묶음은 '검증된 조합'이라는 이유로 그대로 이동하기 시작합니다.
결국 회사는 프로젝트 단위로 돌아가는 것이 아니라 사람 단위의 묶음이 조직의 기본 단위가 됩니다.
이 상태를 우리는 사일로 라고 부릅니다.
현재의 부채 > 미래의 부채
수주 시점의 판단은 항상 [지금 당장의 문제]를 과대평가한다.
많은 조직들은 당면한 일정과 요구사항을 해결하는 것이
곧 고객의 문제를 해소하는 것이라고 생각하곤 합니다.
이 믿음은 자연스럽게 다음 프로젝트 수주로 이어집니다.
사업팀은 이미 한번 해소한 일처럼 보이기 때문입니다.
하지만 프로젝트가 진행될수록 해결되고 있는 것은 과제일 뿐,
개발팀의 입장에서 고객의 근본적인 문제는 그대로 남아있는 경우가 많습니다.
이 때 해결되지 않은 문제들은 눈에 보이지 않는 형태로 누적되고,
미래의 부채로 연결됩니다.
문제는 이 부채가 즉시 비용으로 드러나지 않는다는 점입니다.
그래서 대부분의 조직은 이를 나중에 정리해도 되는 문제로 과소평가합니다.
시간이 지나고 나서야 그 부채가 이미 단순히 정리할 수 없는 수준으로
커져있음을 발견합니다.
뒤늦게 이를 해소하려 하지만,
여전히 반복되는 당면 과제들이 발목을 잡습니다.
결국 조직은 현재의 문제도, 미래의 부채도,
모두 제대로 해결하지 못한 채 이도 저도 아닌 상태에 머무르게 됩니다.
코드 단일화 난이도 상승
프로젝트 수가 늘어날수록 코드 단일화의 난이도는 기술적인 문제가 아니라 의사결정 문제로 변한다.
수주가 연속적으로 진행되는 상황에서는 어떤 기능을 공통으로 가져가고,
어디까지를 각 프로젝트의 책임으로 둘 것인지에 대한 정리가 선행되기 어렵습니다.
이 상태에서 개발은 가장 빠른 선택을 반복하게 됩니다.
이미 존재하는 코드가 있음에도, 프로젝트별 요구사항에 맞춰 유사한 구현이 다시 만들어지는 것이죠.
시간이 지나면서 중복 코드는 자연스럽게 누적됩니다.
하지만 이 중복은 즉시 문제로 드러나지 않습니다.
이후 유사한 요구가 다시 등장하면
사업팀의 입장에서는 이미 한 번 작업했던 내용처럼 보입니다.
반면 개발팀의 입장에서는 다른 프로젝트에 종속된 구현일 뿐입니다.
이 시점부터 대화는 어긋나기 시작합니다.
사업팀은 속도를 묻고, 개발팀은 코드 구현의 비용을 설명합니다.
문제는 이 간극이 개인의 역량이나 협업 태도의 문제가 아니라,
초기 수주 단계에서 단일화에 대한 판단이 이루어지지 않았던 구조의 결과라는 점입니다.
결국 코드는 합칠 수 없고, 논의는 반복되며,
조직은 같은 문제를 두고 계속 다른 언어로 말하게 됩니다.
맺는말
많은 개발자분들이 이 지점에서 스스로를 자책을 하곤 합니다.
'내가 코드를 막 짜서 이렇게 된건가.'
'그 때, CI/CD 좀 손 봐둘껄...'
'이제 다음 코드는 어떻게 하지'
하지만 이것은 프로젝트 중간에 해결할 수 있는 성질이 아닙니다.
이 지점부터는 기술의 문제가 아니라, 수주 시점에 어떤 판단이 내려졌는가에 대한 문제입니다.