당신이 발주한 시스템, 실제로 누가 만들고 있을까
한국 SI 시장에 대한 어느 27년차 개발자의 추측
어느 평범한 오후, 국내 개발자 일감 플랫폼에서 본 공고 하나
오늘 플랫폼에서 인사평정 시스템 구축 공고를 봤습니다.
요구사항은 잘 정리되어 있었습니다. 1차 평정, 2차 평정, 다면 평정이 결합된 전사 근무평정 시스템. 조직개편과 인사이동에 따른 과거 데이터 보존, 평가 항목의 신규 추가/삭제 시 기존 기록 유지, 권한 등급별 메뉴 분리, 가/감점 자동 산출, 승진 서열명부 출력까지. 직원 200명 이상 규모 중견기업의 표준적인 인사평정 RFP로 보였습니다.
예산은 1,500만원, 기간은 3개월. 그리고 지원자는 48명이었습니다.
이 숫자가 한참 머릿속에 남았습니다. 글을 한 편 써보기로 한 건 그래서입니다. 명확한 결론을 내릴 수 있어서가 아니라, 오히려 잘 이해되지 않아서입니다.
왜 이 숫자가 이상하게 느껴졌는지
저는 27년 동안 백엔드 시스템을 만들어 왔습니다. 삼성전자, LG상사, 아모레퍼시픽, 한화첨단소재 같은 대기업 SI 프로젝트와 서울시교육청, 아주대학교 같은 공공·교육 부문 시스템에 참여하면서, 인사·재무·회계 도메인을 들여다본 시간이 길었습니다.
그 경험으로 이 RFP를 보면, 표면적으로는 단순한 CRUD 웹앱처럼 보이지만 실제로는 까다로운 부분이 몇 군데 있는 프로젝트로 읽혔습니다. 어디까지나 제 시각이지만, 적어도 세 가지 정도가 신경 쓰였습니다.
첫째, 시점별 조직 이력 관리. 2024년 평가를 조회할 때는 그 시점의 조직도로 봐야 합니다. 직원이 부서를 옮기고, 팀이 통폐합되고, 평가자가 바뀌어도 과거 평가는 그 당시 구조 그대로 보존되어야 합니다. 단순한 외래키 설계로는 부족할 가능성이 큽니다.
둘째, 평가 항목의 가변 구조. 매년 평가 기준이 조금씩 바뀌는 게 보통입니다. 그러면서도 작년 데이터는 그대로 조회 가능해야 하니, 스키마 설계 단계부터 고민이 필요한 부분입니다.
셋째, 권한 매트릭스의 복잡성. 1차/2차/다면 평정자가 다 다르고, 다면평가는 익명성 보장이 핵심입니다. 누가 누구를 평가했는지 데이터베이스 차원에서 역추적 불가능하게 만드는 것 — 이게 생각보다 까다롭습니다.
이런 부분이 초기 설계에서 제대로 다뤄지지 않으면, 보통 2년차 운영에 들어가서 데이터 정합성 문제가 슬슬 나타나기 시작합니다. 제가 본 사례들이 그랬습니다.
이 정도 스코프를 정상적인 SI 시장에서 만든다면 대략 5,000만원에서 1억 사이가 될 것으로 짐작합니다. 정확한 숫자는 회사마다 다르고 저도 모든 시장을 알지는 못하지만, 적어도 1,500만원/3개월은 시니어 한 명이 정상적으로 수행할 수 있는 단가는 아닐 것 같다는 게 제 직감이었습니다.
그런데 48명이 지원했다는 사실이 그 직감을 흔들었습니다. 시장에 무언가 제가 모르는 메커니즘이 있다는 뜻이거든요.
한 가지 가설: 갑-을-병-정 구조
여기부터는 저의 가설입니다. 확신은 아니고, 제가 보아온 한국 SI 시장의 패턴을 가지고 추측해보는 것입니다.
한국 SI 산업에는 오래된 다층 하청 구조가 있습니다. 업계에서는 흔히 갑-을-병-정 구조라고 부르는데, 대략 이런 모양입니다.
갑은 진짜 발주처입니다. 대기업, 공공기관, 금융사, 그리고 어쩌면 이 공고의 진짜 주인공일지도 모르는 어느 중견기업의 HR 부서.
을은 1차 수주 SI 또는 IT 컨설팅 업체입니다. 갑한테 정상 단가로 계약을 따내는 곳.
병은 2차 하청을 받는 중소 SI나 에이전시. 위시켓 같은 플랫폼에 공고를 올리는 주체일 가능성이 있는 단계.
정은 3차 하청. 개인 프리랜서, 영세 업체, 또는 점점 더 많아지는 해외 개발팀.
오늘 본 그 공고가 정확히 이 구조의 어느 단면인지 저는 모릅니다. 다만 RFP의 작성 수준, 사용된 용어("근무평정", "서열명부" 같은 정통 인사 용어), 산출물 명시 방식 등을 종합해 보면, 공고를 올린 주체와 진짜 발주처가 같지 않을 가능성이 꽤 있어 보였습니다.
이게 단순한 상상이 아니라는 걸, 저는 27년 동안 두 번 직접 확인한 적이 있습니다.
첫 번째 사례: 라이브쇼핑 앱과 인도
몇 년 전, 저는 어느 대형 유통사 계열 매장에 납품할 라이브 쇼핑 제작용 앱 개발 프로젝트를 맡게 됐습니다. 당시 외주 방식으로 진행됐고, 제가 속한 회사가 수주해서 다른 한국 업체에 발주된 것으로 알고 있었습니다.
그런데 프로젝트는 지지부진 했고 요구사항은 변경되고 충족되지도 않고 해서 제가 직접 검사를 하기로 했습니다. 서버에 접속해 작업하다가, 우연히 이전에 누군가 올려둔 테스트 동영상 파일을 발견했습니다. 동영상 속 인물은 한국인이 아니었고, 음성도 한국어가 아니었습니다. 인도 어딘가에서 만들어진 테스트 영상이었던 것입니다.
파일 메타데이터와 디렉토리 구조를 보니 명확해졌습니다. 한국 업체가 수주한 프로젝트가, 인도 개발팀으로 넘어가 작업되고 있었던 것이죠. 제가 의도적으로 찾으려고 한 게 아니었습니다. 그냥 평범하게 작업하다가 서버에 남아있던 흔적을 발견한 것뿐입니다. 저희에게서 앱 개발을 수주한 업체는 처음부터 인도 업체에게 넘기고 중간 차액을 챙기려고 했을 수도 있습니다. 그리고 발주처도 저도 앱이 인도에서 만들어지고 있다는 사실을 까맣게 모르고 있었습니다. 계약서상으로는 한국 업체가 자체 개발하는 것으로 되어 있었으니까요.
저는 그때 처음으로 "해외 재하청"이라는 게 단순한 도시전설이 아니라, 실제로 일어나는 일이라는 걸 눈으로 확인했습니다. 미국에서 같은 사례가 있었는데 그 직원은 뛰어난 성과로 승진에 승진을 했었다고 하더군요. 모두가 성공하는 건 결코 아닙니다.
두 번째 사례: 4단계 재하청과 한 달의 구조
두 번째는 더 극적인 사례입니다.
대형 그룹사의 계열사에서 진행되던 프로젝트였습니다. 발주는 같은 그룹의 IT 계열사가 받았고 — 즉, 그룹 내부 SI 업체가 1차 수주자였습니다. 그런데 그 1차 수주자는 직접 만들지 않고, A사라는 회사에 재하청을 줬습니다. A사도 직접 만들지 않고, 다시 B사에 재재하청을 줬습니다. 그리고 B사가 마지막으로 베트남 개발팀에 재재재하청을 준 구조였습니다.
발주처(첨단소재 계열사) → 그룹 IT 계열사(1차) → A사(2차) → B사(3차) → 베트남(4차)
4단계 하청. 발주처가 결제한 금액 중에서 실제로 코드를 작성하는 베트남 개발자에게 도달한 비율이 얼마였을지는 짐작만 할 수 있을 뿐입니다.
문제는 납기 직전에 터졌습니다. 베트남에서 만들어진 결과물이 요구사항을 제대로 충족하지 못했고, 그 위로 올라오는 동안 단계마다 의사소통 비용이 누적되면서, 납기를 못 맞출 상황이 된 것입니다. 4단계 사슬의 어느 지점에서도 책임지고 해결할 수 없는 상태였습니다.
그 시점에 제가 들어가게 됐습니다.
직접 코드를 분석하고, 핵심 로직을 다시 짜고, 데이터 흐름을 정리하고, 통합을 마무리하는 데 한 달이 걸렸습니다. 발주처는 결과물을 받았고, 납기에 가까스로 맞췄습니다.
지금 와서 생각해보면, 만약 저 4단계 재하청이 없었다면 이 프로젝트는 처음부터 시니어 한두 명이 두세 달이면 깔끔하게 끝낼 일이었을 겁니다. 그런데 4단계를 거치면서 더 많은 비용이 발생했고, 더 많은 시간을 잃었고, 마지막에는 긴급 외부 인력까지 불러와야 했습니다.
발주처는 끝까지 4단계 재하청 구조의 전모를 알지 못했을 것 입니다. 알았다 하더라도 이미 납기가 코앞이라 손쓸 방법이 없었을 테고요. 아마 가장 가슴을 졸인건 1차 하청인 IT 계열사 담당자을 것 입니다. 하지만 2차, 3차 재하청, 재재하청 업체들은 뻔뻔하더군요.
두 사례가 말해주는 것
이 두 사례는 어디까지나 제 개인 경험입니다. 한국 SI 시장 전체를 일반화하기에는 표본이 작고, 모든 외주가 이런 식이라는 것도 결코 아닙니다. 정직하게 한국에서 직접 개발하는 좋은 SI 업체들도 많고, 책임 있게 프로젝트를 마무리하는 곳도 많습니다.
다만 적어도 두 가지는 말씀드릴 수 있을 것 같습니다.
첫째, 다층 재하청은 실재합니다. 도시전설이나 음모론이 아닙니다. 제가 두 번 직접 확인했고, 업계에 있어보면 더 많은 사례를 듣게 됩니다.
둘째, 발주처는 보통 모릅니다. 제가 본 두 사례 모두 발주처는 자신의 프로젝트가 어떤 경로로 누구에 의해 만들어지고 있는지 모르고 있었습니다. 알고도 모른 척한 게 아니라, 정말로 몰랐을 가능성이 높습니다.
이 두 사실이 합쳐지면, 오늘 본 그 인사평정 공고에 대한 가설이 약간 다른 무게를 가지게 됩니다.
1,500만원에 48명이 지원한 그 공고가 어떤 구조의 어느 단계인지 저는 모릅니다. 어쩌면 발주처가 직접 올린 공고일 수도 있습니다. 다만 만약 그 공고가 다층 하청의 어느 지점이라면, 제가 본 두 사례와 비슷한 일이 또 한 번 진행되고 있을 가능성도 있다는 것입니다.
갑은 이 구조를 잘 모를 가능성이 큽니다
만약 이 가설이 맞다면, 이 구조가 유지되는 가장 큰 이유는 진짜 발주처가 이 구조를 잘 보지 못하기 때문일 거라고 저는 생각합니다.
계약서에는 보통 "재하청 금지" 조항이 있습니다. SI 업체는 PM 명함을 들고 와서 "저희 자체 개발팀입니다"라고 말합니다. 갑 입장에서는 받은 결과물이 어디서 만들어졌는지, 시니어가 설계했는지 신입이 만들었는지 확인할 방법이 마땅치 않습니다.
문제는 보통 1년쯤 후에 드러나기 시작합니다.
평정 시즌이 시작되고, 권한 설정이 꼬이고, 데이터 매핑 오류가 나오고, 평가자들의 컴플레인이 폭주하고, 다면평가의 익명성이 깨졌다는 의혹이 제기됩니다. 작년 데이터와 올해 데이터의 정합성이 어긋나기 시작합니다.
그제서야 발주처는 묻기 시작합니다. "이거 누가 만들었어요?"
그런데 그 시점에는 보통 답을 얻기가 어렵습니다. 플랫폼에 공고를 올렸던 에이전시는 이미 다른 프로젝트로 옮겨갔을 수 있고, 해외 개발팀은 연락이 끊겨 있을 수 있고, 코드는 인수인계 부실로 사실상 활용 불가능한 상태일 수 있습니다.
결국 발주처는 두 번째 수표를 끊게 됩니다. 이번엔 정식 SI 업체에, 이번엔 더 큰 예산으로. 처음부터 정직하게 정상 예산을 썼더라면 한 번에 끝났을 일을, 두세 배의 비용으로 다시 만들게 되는 것입니다.
제가 두 번째 사례에서 한 달 만에 정리한 그 프로젝트도, 만약 그 시점에 들어가서 손쓰지 않았다면 비슷한 결말로 갔을 겁니다. 납기를 놓치고, 발주처는 분쟁에 휘말리고, 최악의 경우 처음부터 다시 만들어야 했을지도 모릅니다.
진짜 비용은 돈이 아닐지도 모릅니다
재구축 비용이 늘어나는 것 자체보다, 더 아픈 손실이 있을 수 있다고 저는 생각합니다.
1년치 평가 데이터. 첫 시스템에 누적된 1년의 인사평정 결과는 새 시스템으로 깔끔하게 이관되지 않는 경우가 많습니다. 시점별 조직 이력 설계가 부실하면 정합성을 맞춰 옮기기가 어렵고, 그렇다고 새로 입력하기에는 평가자들의 협조를 다시 받기가 쉽지 않습니다.
조직 신뢰. 평정 시스템의 오류는 단순한 IT 이슈로 끝나지 않습니다. 누군가의 성과급, 누군가의 승진이 걸린 문제이기 때문입니다. 시스템이 한 번 신뢰를 잃으면, 다음 평정 시즌에 평가자도 피평정자도 결과를 못 미더워하기 시작합니다.
HR 부서의 정치적 자본. "잘 도입됐다"고 보고했던 시스템이 1년 후 무너지면, 그 보고를 했던 담당자의 회사 내 입지가 흔들립니다. 다음번 IT 투자 결재를 올리기가 더 어려워지는 식의 부작용도 있을 수 있습니다.
그리고 시간. 다시 만드는 데 또 6개월에서 1년. 그동안 인사평정은 다시 엑셀로 돌아가거나 임시방편으로 굴러가게 됩니다.
그런데 왜 이 구조가 지속되는가
이게 제일 답답하면서도 흥미로운 부분이라고 생각합니다.
이 구조가 누군가의 악의 때문에 유지되는 게 아닌 것 같다는 점입니다. 발주처도, 1차 SI도, 플랫폼 에이전시도, 해외 개발팀도, 각자의 자리에서는 합리적인 선택을 하고 있습니다.
발주처 실무자는 책정된 예산 안에서 외주를 마무리하면 KPI 달성입니다. 시스템이 1년 후에 망가질지는 그때의 일이고, 그 시점에 본인이 같은 자리에 있을지도 모르는 일입니다.
SI 업체는 마진을 챙깁니다. 결과물 책임은 계약서상 어느 정도 분산되어 있고, 평판 리스크도 분산되어 있습니다.
플랫폼 에이전시도 마진을 챙깁니다. 품질 문제는 "협력사 이슈"로 넘기는 패턴이 가능합니다.
해외 개발팀은 받은 만큼 만듭니다. 제가 두 번째 사례에서 본 베트남 팀도, 그들이 받은 단가에서 그들이 할 수 있는 만큼 만든 것이었습니다. 단가가 적정했다면 결과도 달랐을지 모릅니다.
모두가 자기 자리에서 합리적인데 결과는 종합적으로 비합리적인 — 이게 제가 보는 한국 SI 시장의 한 단면인 것 같습니다. 어느 한 주체를 비난해서 해결되는 문제가 아닐 수 있다는 점이 이 구조의 가장 답답한 부분입니다.
발주처가 한 번 시도해볼 만한 것들 — 그리고 형식만으로는 안 되는 이유
이 글의 진짜 독자는 발주처에 계신 분들이라고 생각합니다. 직원 200명, 500명, 1,000명 규모 회사의 HR 임원, IT 임원, 경영지원실장, 그리고 그분들에게 보고하는 실무자들.
제가 위에서 말씀드린 두 사례 같은 일이 다른 곳에서도 일어나고 있다면 — 그리고 그 손실이 결국 발주처에게 돌아간다면 — 그 손실의 상당 부분은 예방 가능할지도 모릅니다.
그런데 한 가지 먼저 짚고 가야 할 것이 있습니다. 보통 이런 글에서 가장 많이 등장하는 조언은 "계약서에 실제 코드 작성자의 이력서를 첨부하도록 명시하라" 입니다. 저도 처음에는 이 조언을 적으려고 했습니다.
문제는, 이 조항이 거의 다 우회된다는 점입니다.
이력서 첨부 의무를 계약서에 넣어두면, 수주사는 정직하게 보이는 시니어 이력서를 첨부합니다. 그런데 킥오프가 끝나고 나면 "사정이 생겨서 담당자가 바뀌었습니다"라는 통보가 옵니다. 누가 진짜로 코드를 짜고 있는지는 그때부터 다시 모르게 됩니다. "건강 문제로 빠졌다", "다른 프로젝트에 긴급 투입됐다", "회사 사정상 인력 재배치가 필요했다" — 이런 사유가 계약을 깨뜨리는 수준은 아니라서 발주처 입장에서는 받아들이는 것 외에 뾰족한 수가 없습니다.
이게 형식적 조항의 한계입니다. 종이 위에서는 작동하지만, 현장에서는 거의 다 빠져나갑니다. 재하청 금지 조항도 마찬가지고요.
그래서 정말로 의미가 있는 건 형식이 아니라 실질적으로 검증할 수 있는 행동들 인 것 같습니다. 단정이 아니라 제안입니다.
시스템 설계에 들어가는 시니어를 발주처가 직접, 정기적으로 만나는 것. 한 번이 아니라 프로젝트 내내 입니다. PM이 아니라 실제로 설계하고 코드를 짜는 사람을. 킥오프 때 한 번 보고 그 다음 보고는 PM만 나오는 구조라면, 그 사이에 무슨 일이 일어나도 발주처는 알 수 없습니다.
개발 중간에 서버를 직접 들여다보는 것. 코드 커밋 로그, 작업 시간대, 파일 메타데이터 같은 것들은 거짓말을 하기가 어렵습니다. 제가 첫 번째 사례에서 인도 재하청을 발견한 것도 결국 서버에 남아있던 흔적이었습니다.
단가가 비현실적으로 낮으면 한 번쯤 멈추고 생각해보는 것. 업계 시세보다 30~40% 낮은 견적이 들어왔다면, 어딘가에서 비용이 절감되고 있다는 뜻일 가능성이 큽니다.
그런데 솔직히, 비전문가가 이걸 다 할 수 있을까요
여기서 한 가지를 정직하게 짚어야 할 것 같습니다.
위에 적은 검증법들은, 솔직히 비전문가가 직접 하기는 어렵습니다.
"실제 설계자를 만나라"고 해도, 그 사람이 진짜 시니어인지 그럴듯하게 말하는 PM인지 임원이 30분 만에 구별하기는 거의 불가능합니다. "서버를 들여다보라"고 해도, Git 커밋 로그를 보면서 "이건 한국 시간대가 아니네", "이 코드 스타일은 자동 생성된 거네" 같은 신호를 잡아내려면 결국 시니어의 눈이 필요합니다.
시니어는 코드 한 줄, 미팅 5분으로 신호를 잡습니다. 비전문가가 그 신호를 알아보기는 어렵습니다. 이걸 짚지 않고 "이렇게 하세요"만 적으면, 글이 공허해집니다.
그래서 좀 더 현실적인 방향들을 추가로 적어보겠습니다.
산출물에 작성자 명시를 의무화하고, 인수 시점에 확인하는 것. "이 모듈은 누가 작성했는지" 산출물에 명시되면, 다층 하청은 자연스럽게 어려워집니다. 비전문가도 인수 단계에 한 번 확인하는 정도는 할 수 있습니다.
인수 테스트 시나리오를 발주 단계에 미리 넣어두는 것. "1년 후 평가 항목을 추가했을 때 작년 데이터 정합성이 유지되는가", "조직개편 시점 이전 평가가 그대로 조회되는가" 같은 시나리오를 계약서 단계에 박아두면, 코드를 직접 안 봐도 시스템의 미래 안정성을 어느 정도 검증할 수 있습니다. 이건 비전문가도 요구사항 단계에 명시 가능합니다.
별도 시니어에게 1주일 단위 코드 리뷰를 의뢰하는 것. 인수 시점에 외부 시니어 한 명에게 1주일치 코드 리뷰를 맡기는 비용은, 전체 프로젝트 비용의 1~2% 수준입니다. 그 1~2%가 1년 후 3억 재구축을 막을 수 있다면 합리적인 투자입니다.
한 가지 더 — Fractional CTO
여기까지 적고 보니, 이 모든 게 사실상 같은 결론을 가리키고 있습니다.
비전문가 임원이 IT 외주를 직접 검증하는 건 어렵습니다. 그렇다고 정규직 CTO를 뽑기엔 부담입니다. 그 사이를 메우는 모델이 있으면 가장 좋습니다.
해외에는 이런 모델이 이미 보편화되어 있습니다. Fractional CTO, 또는 분할 기술 자문이라고 부릅니다. 시니어 한 명을 주 1~2일 또는 프로젝트 단위로 빌려쓰는 구조입니다. 미국에선 월 $5,000~$25,000, 유럽에선 월 €6,000~€18,000 선에서 시장이 형성되어 있고, "Top 20 Fractional CTOs" 같은 랭킹과 가격 비교 사이트까지 갖춰져 있습니다. 정규직 CTO 비용의 10~30% 수준에서 시니어급 기술 리더십을 빌려쓰는 모델입니다.
다만 정직하게 짚어야 할 부분이 있습니다.
해외의 Fractional CTO 모델은 주로 스타트업/스케일업의 사내 기술 리더십 역할입니다. 시리즈 A 전후의 엔지니어 80명 이하 회사들이 주 고객이고, 사내 아키텍처 설계, 엔지니어링 팀 빌딩, 기술 전략 수립이 핵심 업무입니다. 즉, 외주 발주 검증 용도로 쓰는 건 해외에도 표준 사례가 아닙니다. 검색해보시면 그런 용례는 거의 나오지 않습니다.
그러니까 제가 제안 드리는 건 정확히 말하면 이렇습니다. "해외에 이미 보편화된 Fractional CTO 컨셉을, 한국 중견기업의 IT 외주 검증이라는 영역에 응용해보면 어떨까" 라는 제안입니다. 새로운 모델을 만들자는 게 아니라, 검증된 모델을 비어있는 자리에 가져다 쓰자는 것입니다.
생각해보면 이 응용은 자연스럽습니다. Fractional CTO가 스타트업에서 하는 일 — 아키텍처 검토, 견적 적정성 판단, 코드 품질 점검, 미래 확장성 평가 — 이 그대로 외주 발주의 검증 단계에서 필요한 일들이기 때문입니다. 다만 정규직으로 모실 필요가 없고, 외주 프로젝트 단위로 단기 자문을 받으면 충분합니다. 발주 견적 검토 단계에 1주, 중간 점검에 격주 반나절, 인수 단계에 1주. 그 정도면 위에서 말씀드린 모든 검증을 임원 대신 시니어가 수행할 수 있습니다.
비용은 외주 프로젝트 전체 비용의 5~10% 수준입니다. 그 5~10%가 1년 후 3억 재구축을 막을 수 있다면, 합리적인 투자입니다.
한국에서는 아직 이 모델을 외주 검증에 응용하는 시장이 명확하지 않습니다. 직접 시니어를 찾아 나서야 하는 번거로움이 있고, 그 시니어가 자기 회사 IT를 잘 이해해 줄 사람인지 판단하는 또 다른 문제가 생깁니다. 다만 이런 응용 방식이 가능하다는 것 자체를 아는 것 만으로도, 다음 IT 외주 발주 때 옵션이 하나 늘어납니다. 임원 혼자 모든 걸 떠안지 않아도 되는 길이 있다는 걸 아는 것, 그게 출발점이라고 생각합니다.
한 가지만은 단언할 수 있습니다
지금까지 거의 모든 이야기를 "제 추측"으로 말씀드렸습니다. 시장 구조도 가설이고, 발주처가 모를 가능성이 크다는 것도 짐작이고, 어떤 검증법이 효과적일지도 제안일 뿐입니다.
그런데 한 가지만은 27년 경험을 걸고 단언할 수 있습니다.
"누가 만들든 결과물은 비슷하니까 싸게 만들면 된다"는 가정은 틀렸습니다.
이 가정이 한국 IT 외주 시장에서 가장 비싼 값을 치르는 오해입니다. 시니어가 두 달이면 깔끔하게 끝낼 시스템을, 주니어 또는 해외 재하청 팀에 맡기면 표면적으로는 비슷해 보이는 결과물이 나옵니다. 화면이 뜨고, 버튼이 동작하고, 데이터가 저장됩니다. 발주처는 받아보고 "잘 됐네" 합니다.
차이는 1년 후, 2년 후에 드러납니다.
책임감 있는 시니어가 설계한 시스템은 5년이 지나도 운영됩니다. 그리고 그 시스템의 유지보수를 귀찮아하지 않습니다. 유지보수비를 정당하게 지급한다면 오히려 더 신경 써서 봐줍니다. 자기가 만든 시스템이 오래 잘 돌아가는 게 본인의 평판이자 자존심이기 때문입니다.
반대편이 있습니다. 재하청을 받아 또 재재하청을 돌리는 3년차, 5년차의 잔머리 대마왕들. 이들은 결제가 끝나면 연락이 끊깁니다. 다음 프로젝트로 옮겨가 있고, 회사를 옮겼고, 담당자가 바뀌었다는 식의 답이 돌아옵니다. 1년 후 시스템에 문제가 생겨도 책임질 사람이 없습니다.
이 두 부류의 차이는 결제 시점에는 안 보입니다. 둘 다 같은 시기에 비슷한 기능의 시스템을 납품하고, 발주처는 둘 다 받아보고 "잘 됐네" 합니다. 차이는 1년, 2년, 3년 후에 누적되어 드러납니다. 잔머리 대마왕들이 만든 시스템은 첫 해는 잘 굴러갑니다. 두 번째 해부터 데이터가 슬슬 어긋나기 시작합니다. 세 번째 해에는 아무도 그 코드를 만질 수 없게 됩니다. 네 번째 해에 발주처는 새 시스템을 발주합니다.
처음에 5,000만원을 아꼈다고 생각했는데, 4년 후에 3억을 쓰는 구조입니다. 그리고 그 3억이 끝이 아닙니다. 잃어버린 4년치 데이터, 무너진 평가 신뢰도, HR 부서의 사내 입지까지 합치면 진짜 비용은 계산이 어려운 영역으로 갑니다.
시니어는 단순히 코드를 빨리 짜는 사람이 아닙니다. 3년 후, 5년 후에 무엇이 무너질지 미리 보는 사람입니다. 이게 단가의 진짜 차이입니다. 그리고 이 차이는 결제 시점에는 보이지 않고, 운영 2~3년차부터 누적되어 나타납니다.
"싸게 만들면 된다"는 가정은 결제 순간에는 맞아 보이지만, 시스템 수명 전체로 보면 거의 항상 틀립니다. 이건 추측이 아니라 27년 동안 한국에서 시스템이 무너지고 다시 만들어지는 모습을 반복해서 본 사람의 결론입니다.
그런데 요즘에는 AI가 있잖아요?
이 글을 여기까지 읽으신 분이라면, 한 가지 반박이 떠오르실 겁니다.
"요즘엔 AI로 빠르고 싸게 만들 수 있는데, 왜 굳이 비싼 시니어를 써야 하나?"
타당한 의문입니다. 저도 매일 AI 코딩 도구를 씁니다. 같은 일을 5년 전보다 두세 배 빨리 할 수 있게 된 것도 사실입니다. AI가 시장을 바꾸고 있는 것은 분명합니다.
다만 한 가지는 짚어야 할 것 같습니다. AI는 "만드는 속도"는 빠르게 해줬지만, "무엇을 만들어야 하는지 판단하는 능력"은 빠르게 만들어주지 않습니다.
AI는 시키는 대로 코드를 잘 짭니다. 그런데 인사평정 시스템에서 시점별 조직 이력을 어떻게 보존할지, 다면평가의 익명성을 데이터베이스 차원에서 어떻게 보장할지, 평가 항목이 매년 바뀌어도 작년 데이터가 안전하게 조회되도록 스키마를 어떻게 설계할지 — 이런 판단은 AI한테 맡길 수 없습니다. 정확히는, AI에게 맡기려면 누군가는 "이런 것들을 고민해야 한다"는 사실 자체를 먼저 알고 있어야 합니다.
3년차 개발자가 AI를 쓴다고 시니어가 되지는 않습니다. AI에게 "인사평정 시스템 만들어줘"라고 입력하면, 위에 적은 세 가지 기술적 도전을 다 무시한 시스템이 깔끔하게 나옵니다. 화면이 뜨고, 버튼이 동작하고, 데이터가 저장됩니다. 첫 해까지는 잘 굴러갑니다. 그리고 두 번째 해부터 무너집니다. 위에서 말씀드린 그대로의 패턴입니다.
AI 시대에 오히려 더 중요해지는 게 시니어의 판단력이라고 저는 생각합니다. 코드를 짜는 노동은 AI가 가져가고, "무엇이 5년 후에 무너질지"를 보는 눈만 사람의 영역으로 남기 때문입니다. 그 눈을 가진 사람한테 AI를 쥐어주면 더 빠르고 정확하게 만듭니다. 그 눈이 없는 사람한테 AI를 쥐어주면, 표면적으로는 더 그럴듯한데 운영 단계에서 더 빨리 무너지는 시스템이 나옵니다.
"AI로 싸게 빨리 만들 수 있다"는 가정도, "누가 만들든 비슷하다"는 가정의 새 버전일 뿐입니다. 도구가 바뀌었을 뿐, 책임감 있게 설계하는 사람과 잔머리로 결과만 뽑아내는 사람의 차이는 그대로 남아있습니다. AI는 그 차이를 없애지 않고, 오히려 더 가속화합니다.
마무리
오늘 본 그 공고에 저는 지원하지 않을 것입니다. 단가가 안 맞기도 하지만, 그보다는 만약 제 가설이 맞다면 저 공고의 진짜 클라이언트는 플랫폼에 없을 가능성이 크기 때문입니다.
진짜 클라이언트는 아마도 어딘가의 중견기업 HR 부서일 것이고, 그분들은 자신의 회사 시스템이 어떤 경로를 거쳐 어떤 가격에 거래되고 있는지 잘 모르고 계실 가능성이 있습니다. 제가 두 번 직접 본 그 두 회사처럼요.
이 글이 그분들 중 한 분이라도 읽게 된다면, 그리고 다음 IT 외주를 발주할 때 한 번이라도 "직접 검증이 어려우니 외부 시니어 자문을 한 명 둬야겠다"고 생각하시게 된다면, 이 글은 제 역할을 한 것 같습니다.
물론 다 제 추측이고 직감입니다. 시장 전체를 다 알지는 못합니다. 다만 27년 동안 한국에서 시스템을 만들면서 직접 두 번 부딪힌 일이 있고, 그걸 통해 만들어진 어떤 패턴 인식이 있고, 그걸 한 번 글로 정리해보고 싶었던 오후였다고 받아주시면 될 것 같습니다.
— 스티붕
27년차 백엔드 개발자. 삼성전자, LG상사, 아모레퍼시픽(구 태평양), 한화첨단소재, 삼성BP화학 등 대기업 SI 프로젝트와 서울시교육청, 아주대학교 등 공공·교육 부문 시스템 구축에 참여해 왔습니다. 레거시 복구와 긴급 디버깅, 복잡한 시스템 통합을 주로 다룹니다.