이 개발, 아웃소싱 맡겼으면 얼마였을까
처음 나온 숫자는 3.5주에서 4.5주였고, 그 숫자는 틀렸습니다
앞의 세 편에서 AI 담당자를 조직도에 심고, 여덟 자리까지 늘리고, 그걸 계속 켜두는 과정을 적었습니다. 어느 시점에 궁금해졌습니다. 이걸 사람을 뽑아서 했다면 얼마나 걸렸을까.
물어봤더니 처음에는 3.5주에서 4.5주라는 답이 나왔습니다. 그 숫자를 그대로 안 받고 조건을 하나씩 되짚었더니, 같은 대화 안에서 숫자가 세 번 바뀌었습니다. 마지막에 남은 건 혼자 하면 3개월에서 4개월, 두 명이 나눠 하면 1.5개월에서 2.5개월이었습니다.
이 편은 그 숫자보다 숫자가 왜 바뀌었는지에 대한 기록입니다. 아웃소싱 견적을 받아본 적 있는 실무자라면 익숙한 이야기일 겁니다. 처음 나온 숫자는 언제나 가장 유리한 가정 위에 서 있습니다.
무엇을 만들었는지부터 나눠봤습니다
기간을 따지려면 대상을 먼저 쪼개야 합니다. 네 덩어리로 나뉘었습니다.
첫째, 업무 화면 본체입니다. 업무를 한 곳에서 받아 법인과 부서로 배분하고, 각 담당자별로 실행을 관리하고, 진행 상태를 실시간으로 화면에 표시하는 부분입니다. 업무 이력은 서버에, 개인 메모는 브라우저에 나눠 저장합니다.
둘째, 윈도우 위에서 이걸 계속 살려두는 부분입니다. 프로세스 감시와 재시작, 중복 실행 방지, 로그온 시 자동 시작, 권한 문제 우회가 여기 들어갑니다.
셋째, 외부 접속입니다. 사설망을 붙여서 사무실 밖이나 휴대폰에서 열리게 하는 부분입니다.
넷째, 4개 법인의 실제 조직 구조를 화면과 권한 설계에 반영하는 부분입니다. 겉보기에 제일 안 티 나는데 실제로는 여기가 제일 오래 걸립니다.
필요한 능력을 적어보니 한 사람이 아니었습니다
각 덩어리에 붙는 능력을 적어봤습니다.
- 백엔드 개발: 서버를 짜고, 여러 AI 실행을 동시에 관리하고, 업무 대기열과 상태 갱신, 승인 흐름을 설계하는 부분
- 프론트엔드 개발: 실시간 상태가 보이는 화면, 저장 위치가 다른 두 종류 데이터를 나눠 그리는 부분
- 윈도우 시스템 관리: 작업 스케줄러, 프로세스 감시, 관리자 권한 문제 우회
- 네트워크와 인프라: 사설망 연결, 포트 관리, 방화벽
- AI 담당자 설계: 여덟 자리의 역할과 도구 권한을 정하고, 담당자별로 모델을 나누고, 문서에 안 적힌 동작을 실제로 돌려서 찾아내는 일
- 도메인 지식: 4개 법인이 실제로 어떻게 굴러가는지, 어디에 승인이 필요한지 판단하는 부분
- 이 전부를 조율하고 애매한 지점마다 결정을 내리는 일
일곱 가지입니다. 이 중 앞의 네 가지는 채용 시장에 있는 직군입니다. 다섯째는 최근에 생긴 영역이라 경력자가 드뭅니다. 여섯째는 애초에 밖에서 살 수 없습니다.
경력 5년이면 되지 않느냐고 물었습니다
이렇게 물었더니 항목별로 답이 갈렸습니다.
윈도우 시스템 관리와 네트워크는 경력 3년에서 5년이면 충분히 커버됩니다. 다만 AI 서버를 24시간 안정적으로 돌린다는 요구 자체가 최근에 생긴 것이라, 전통적인 시스템 관리자도 이런 사례를 자주 다뤄본 적이 없습니다. 앞 편에 적은 것 같은 시행착오는 경력 연차와 무관하게 납니다.
백엔드와 AI 담당자 설계를 겸하는 부분은 다릅니다. 백엔드 경력 5년 이상이면서 최근 1, 2년 사이 AI 담당자 오케스트레이션을 직접 만져본 사람이어야 하는데, 이런 조합은 시장에 드뭅니다. 순수 백엔드 시니어는 많아도 이 영역만큼은 5년차도 사실상 처음입니다.
법인 구조 반영은 아예 밖에서 살 수 없습니다. 본인이거나 오래 같이 일한 내부 관리자만 아는 정보입니다. 경력 몇 년으로 해결되는 항목이 아니고, 결국 제가 직접 붙어서 설명해야 하는 병목입니다.
정리하면 이렇습니다. 경력 5년짜리 한 명을 구하면 혼자 다 됐을 것이 아니라, 경력 5년짜리 한 명에 제 지속적인 개입이 붙어야 최소 요건이 됩니다.
숫자가 바뀐 지점
여기까지 정리하고 나니 처음 나온 3.5주에서 4.5주가 어떤 가정 위에 서 있었는지 보였습니다. 이 일곱 가지 능력을 이미 다 갖춘 사람이 처음부터 막힘없이 짠다는 가정이었습니다. 그런 사람은 사실상 없습니다.
그래서 현실적인 경우로 바꿔서 다시 계산했습니다. 경력 있는 백엔드 시니어를 데려오되, AI 담당자 설계 부분은 처음 해보게 시키는 경우입니다. 순수 코딩 시간은 그대로 필요하지만, 여기에 무엇이 되고 무엇이 안 되는지 자체를 모르는 상태에서 생기는 시행착오가 붙습니다.
앞 편에 적은 포트 충돌 문제가 좋은 예입니다. 프로세스 목록과 포트 상태를 몇 분 만에 뽑아 원인을 좁히면 금방 끝나지만, 처음 이런 시스템을 만드는 사람은 화면이 왜 안 뜨는지에서 출발해 방화벽인지 코드 오류인지 프로세스가 죽은 건지 포트 충돌인지를 하나씩 다 뒤집니다. 반나절에서 하루가 나갑니다. 이런 게 프로젝트 전체에 누적됩니다.
여기에 제 확인 대기 시간이 붙습니다. 법인 구조는 제가 설명해야 하는데, 저는 본업이 따로 있습니다. 미팅 잡고 답변 기다리는 텀이 계속 끼어듭니다.
이렇게 다시 계산하니 6주에서 8주 풀타임, 달력 기준으로는 2개월에서 3개월이 나왔습니다.
그래도 한 명이 하기는 어렵습니다
한 명이 5주에서 8주에 끝낸다는 것 자체가 무리한 가정이라는 지적이 그다음에 나왔습니다. 이유가 네 가지였습니다.
병렬 처리가 안 됩니다. 백엔드를 짜다 막히면 그 상태로 두고 화면 작업으로 넘어가기 어렵습니다. 인프라 문제가 터지면 개발 흐름이 통째로 끊깁니다.
도메인 전환 비용이 붙습니다. 오전에는 서버 코드, 오후에는 윈도우 권한 문제, 저녁에는 조직 구조 설명 듣기. 성격이 완전히 다른 작업을 하루에 오가면 전환 자체에 실질 작업 시간의 20에서 30퍼센트가 나갑니다. 8시간 근무가 8시간 작업이 아니게 되는 핵심 이유입니다.
막혔을 때 물어볼 사람이 없습니다. 문서가 없는 영역을 혼자 시행착오로 알아내야 하는데, 이런 삽질은 예측 자체가 안 되고 보통 예상의 두세 배로 늘어집니다.
그리고 하루 8시간이 온전히 이 일에 들어가는 경우는 실제로 거의 없습니다. 회의와 잡무가 붙습니다.
그래서 최종적으로 이렇게 정리됐습니다. 한 명이 전담해도 달력 기준 3개월에서 4개월. 정상적인 회사라면 최소 두 명을 붙여 병렬로 진행하는 게 맞고, 인수인계 부담이 있어도 병렬 이득이 더 커서 달력 기준 1.5개월에서 2.5개월입니다.
숫자를 믿으면 안 되는 이유
한 대화 안에서 3.5주가 3개월로 바뀌었습니다. 저는 새 정보를 준 게 아닙니다. 조건을 되물었을 뿐입니다.
처음 숫자가 나온 자리에는 가장 유리한 가정이 깔려 있었습니다. 모든 능력을 갖춘 사람이, 처음부터 막힘없이, 하루 8시간 온전히, 요구사항 변경 없이 진행한다는 가정입니다. 이 네 개가 한꺼번에 성립하는 현장은 거의 없습니다.
중간에 엉뚱한 항목이 섞여 들어간 적도 있었습니다. 이 화면 이야기를 하는데 개인 프로젝트 개발 기간이 합산에 끼어 있었습니다. 지적하니 빼고 다시 계산했습니다. 견적서를 받아본 실무자라면 이 대목이 익숙할 겁니다. 총액이 아니라 항목부터 봐야 합니다.
AI가 내놓는 기간이나 비용 추정도 똑같습니다. 근거 없이 지어내는 게 아니라, 안 적힌 가정 위에서 계산합니다. 그 가정을 하나씩 꺼내 되물으면 숫자는 계속 바뀝니다. 숫자를 받는 게 아니라 가정을 받아야 합니다.
AI가 내놓은 숫자는 조건부터 캐묻습니다
이 방식이 기간 추정에만 쓰이는 건 아닙니다. 이후로 다른 업무에서 AI가 숫자나 결론을 내놓을 때도 같은 순서를 씁니다. 먼저 답을 받고, 그 답이 어떤 조건 위에 서 있는지 하나씩 물어서 조건을 눈에 보이게 꺼내는 순서입니다. 다만 이 방식이 통하려면 먼저 그 업무의 조건을 제가 스스로 나눌 수 있어야 합니다. 이번 편에서 네 덩어리, 일곱 가지 능력으로 나눴던 것처럼, 대상을 쪼개는 눈이 없으면 AI에게 무엇을 되물어야 하는지조차 떠오르지 않습니다.
다른 부서 담당자에게 이 방식을 설명할 때는 견적서 검토하듯 하라고 말합니다. 총액만 보고 넘기지 말고 항목별로 뜯어서, 그 항목이 어떤 가정에서 나온 숫자인지 하나씩 캐물으라는 뜻입니다. 실제로 견적서 검토 경험이 있는 사람일수록 이 설명을 빨리 알아들었습니다.
쪼개 보니 시간이 어디로 갔는지 보였습니다
기간을 세 번 되물어 다시 계산하는 과정에서 예상치 못한 부수 효과가 하나 있었습니다. 네 덩어리로 나누고 일곱 가지 능력으로 쪼개는 작업 자체가, 정작 만든 것이 무엇인지를 제가 다시 정리하는 계기가 됐습니다. 만드는 동안에는 눈앞의 문제를 하나씩 처리하느라 전체 구조를 한 번에 볼 일이 없었는데, 기간을 따지려고 억지로 쪼개다 보니 어느 부분에 시간이 제일 많이 들어갔는지가 그제야 선명해졌습니다.
반대로 귀찮아진 점도 있습니다. 한 번 조건을 캐물어 추정 기간이 늘어나는 경험을 하고 나니, 이후로는 AI가 내놓는 숫자를 곧이곧대로 받아들이기가 더 어려워졌습니다. 간단한 작업 시간을 물어볼 때도 습관적으로 가정을 되묻게 되는데, 정말 대략적인 감만 필요한 상황에서는 이 습관이 오히려 시간을 더 잡아먹기도 합니다. 언제 캐묻고 언제 그냥 받아들일지를 가리는 것도 결국 새로 생긴 판단입니다.
그래서 이 4부작의 결론
네 편에 걸쳐 적은 내용을 실무자 기준으로 정리하면 이렇습니다.
되는 것과 안 되는 것의 경계는 명확합니다. 업무 내용을 받아 정리하고, 필요한 자료를 판단하고, 연결된 자료를 뒤져 대조하고, 차이의 원인 후보를 제시하고, 회신 초안까지 만드는 데까지는 확실히 됩니다. 발송과 이체, 장부 확정, 신고는 안 됩니다. 연결할 도구가 아직 없는 것도 있고, 연결할 수 있어도 사람 손에 남겨둘 것도 있습니다.
시간이 걸리는 자리는 예상과 다릅니다. AI가 짜주는 코드가 아니라 화면 배치를 조정하고, 프로세스가 멈춘 원인을 찾고, 조직 구조를 정리하는 데 대부분이 들어갔습니다. 코딩이 병목이 아니었습니다.
만들다 보면 산출물이 화면이 아닌 경우가 있습니다. 첫 편에서 적었듯이 실제 결과물은 어떤 자료를 누가 볼 수 있는지 정리한 접근 범위였고, 그 과정에서 서류상 조직과 실제 운영이 어긋나는 지점이 드러났습니다. 화면을 안 만들었으면 넘어갔을 대목입니다.
그리고 이걸 사람에게 맡겼다면 두 명이 두 달 정도입니다. 다만 그 두 달을 아꼈다는 말로 정리하고 싶지는 않습니다. 제가 붙어서 설명하고 결정해야 하는 부분은 여전히 그대로 남아 있었고, 그 부분은 누구에게도 맡길 수 없었습니다. 줄어든 건 사람을 구하고 인수인계하고 코드를 짜는 시간이지, 무엇을 만들지 정하는 시간이 아니었습니다.
이어서 읽을 기록
