외주 vs 내재화 — 우리가 처음 외주를 시도한 이유

우리는 오래 내재화를 고집했다. “우리가 직접 만드는 게 낫다”는 생각이 기본값이었다. 외부에 맡기면 커뮤니케이션 비용이 더 들고, 품질 컨트롤이 어렵고, 나중에 유지보수가 골치 아프다는 경험담을 여러 번 들었다. 그래서 가능하면 다 직접 했다.

그러다가 특정 시점에 처음으로 외주를 시도했다. 이 글은 그 결정의 배경과, 실제 경험에서 배운 것들이다.

결정의 배경

작업이 밀리기 시작했다. 세 명이 각자 담당 영역을 가지고 있는데, 어느 순간 모든 영역이 동시에 바쁜 시기가 왔다. 그때 백오피스 화면 하나를 만들어야 했는데, 기능 자체는 단순했다. CRUD에 가까운 관리 화면이었고, 디자인도 내부용이라 꾸밀 필요가 없었다.

이런 작업을 직접 하면 최소 2주가 걸릴 것 같았다. 그 2주가 다른 우선순위 작업을 밀어낸다는 게 문제였다. 그래서 처음으로 외부에 맡기는 것을 진지하게 검토했다.

실제로 어떻게 됐나

결론부터 말하면, 기대했던 것보다 커뮤니케이션 비용이 많이 들었다. 단순해 보이는 요구사항도 막상 전달하려면 명세서가 필요하고, 그 명세서를 쓰는 데 시간이 걸린다. 첫 번째 결과물이 나왔을 때 우리가 생각한 것과 다른 부분이 있었고, 수정 사이클이 두 번 더 돌았다.

최종 결과물의 품질은 나쁘지 않았다. 하지만 총 투입 시간을 따지면 우리가 직접 했을 때와 큰 차이가 없었다. 다른 점은 우리의 집중을 덜 빼앗겼다는 것이다. 커뮤니케이션에 쓴 시간은 산발적이었고, 그 사이에 다른 작업을 계속할 수 있었다.

배운 것

외주가 효과적인 조건이 있다. 명세가 명확할 때, 수정 사이클이 최소화될 때, 그리고 담당자와의 커뮤니케이션 채널이 원활할 때다. 이 세 가지가 갖춰지지 않으면 기대보다 비용이 올라간다.

또 하나는, 외주로 넘길 수 있는 작업과 내재화해야 하는 작업의 기준을 미리 정해두는 것이 중요하다는 것이다. 우리는 이후에 “비즈니스 로직이 들어가면 내재화, 반복적인 UI 작업은 외주 후보”라는 기준을 만들었다. 완벽한 기준은 아니지만, 결정할 때마다 처음부터 고민하는 것보다는 훨씬 낫다.

처음 외주를 시도한 경험은 실패도 아니고 완전한 성공도 아니었다. 하지만 그 경험이 없었다면 우리가 언제 외주를 써야 하는지를 이렇게 구체적으로 생각해보지 못했을 것이다.

— by slecs