외주 견적 1억이었습니다. 700만 원에 만들었습니다

사내 IT 서비스 요청을 관리하는 시스템이 필요했습니다. 흔히 ITSM이라고 부르는 것입니다. 직원이 IT 관련 요청을 올리고, 담당자가 배정되고, 처리 상태가 추적되는 시스템입니다.

기한이 정해진 지시였습니다. 방법은 두 가지로 보였습니다. 외주를 주거나, 상용 솔루션을 사거나.

외주 견적은 1억 원이었습니다.

규모가 큰 회사라면 쓸 수 있는 금액입니다. 그런데 사내 요청 관리 시스템 하나에 1억을 쓰는 것은 우선순위가 맞지 않았습니다.

그래서 다른 길을 찾다가 소스 코드를 구할 수 있다는 것을 알았습니다. 필요한 것은 표(Grid) 컴포넌트 라이선스뿐이었고 그 값이 500만 원이었습니다.

1억과 500만 원 사이의 간격을 보면서 생각이 바뀌었습니다. 이 일의 본질이 무엇인가.

계기는 하루짜리 교육이었습니다

2026년 5월 26일, 바이브 코딩 교육을 하루 받았습니다. 다른 과제의 부속 과정으로 잡힌 일정이었고 큰 기대는 없었습니다.

바이브 코딩은 코드를 직접 타이핑하지 않고 만들고 싶은 것을 말로 설명하는 방식입니다. "로그인 페이지 만들어줘", "에러 나는데 왜 그래?", "배경색 바꿔줘" 같은 대화로 진행합니다. 파일 관리, 코드 작성, 오류 해결, 명령어 실행까지 대화로 처리됩니다.

교육을 받고 나서 판단이 하나 섰습니다. 이 방식이면 직접 만들 수 있다.

3주 후에 열었습니다

6월 16일에 ITSM을 오픈했습니다. 교육받은 날로부터 3주, 실제 작업은 4주 남짓이었습니다. 개발 인원은 한 명이었습니다. 도구는 ChatGPT와 Cursor를 함께 썼습니다.

담은 기능은 이렇습니다.

• 요청부터 결재까지 포털 하나에서 — 메일과 전화로 흩어져 있던 요청을 한 곳으로 모았습니다.
• 카테고리를 고르면 담당자가 자동으로 연결 — 누구에게 보내야 하는지 요청자가 몰라도 됩니다.
• 내 요청이 지금 어느 단계인지 보인다 — 진행 상황을 물어보는 전화가 사라졌습니다.
• 담당자별 진행 현황을 한 화면에서 — 어디에 몰려 있고 어디가 밀리는지가 보입니다.

중간에 한 번 되돌렸습니다

순탄하게 4주가 흘러간 것은 아닙니다. 중간에 한 번 크게 되돌렸습니다.

바이브 코딩을 처음 해보는 상태였으니 감이 없었습니다. 대화로 요청하면 화면이 나오고, 버튼을 누르면 반응하고, 목록도 뜹니다. 그래서 잘 되고 있다고 생각했습니다.

그런데 아니었습니다. 화면(프론트엔드)은 제대로 만들어져 있었지만 뒷단(백엔드)이 제대로 없었습니다. 겉으로는 동작하는 것처럼 보이는데 데이터가 실제로 저장되고 흐르는 부분이 비어 있었습니다.

그래서 프롬프트를 다시 만들었습니다. 무엇을 만들 것인지 요청하는 방식 자체를 바꿔야 했습니다.

가장 위험한 것은 된 것처럼 보이는 상태입니다

이 경험에서 배운 것이 이 프로젝트 전체에서 가장 값진 부분이라고 생각합니다.

안 되면 안 되는 것을 압니다. 에러가 나거나 화면이 안 뜨면 바로 알아차립니다. 그런데 반쯤 된 상태는 알아차리기 어렵습니다.

왜 이런 일이 생기는지 생각해보면 이유가 겹쳐 있습니다. AI는 화면을 만드는 일을 특히 잘합니다. 그리고 사람이 "다 됐다"고 판단하는 근거도 대개 화면입니다. 두 가지가 겹치면 착각이 생깁니다. 화면이 그럴듯하니 다 된 것으로 보이는 것입니다.

데모를 보여주면 통과합니다. 사람들이 보는 것도 화면이니까요. 그리고 실제 데이터가 쌓이기 시작한 다음에 문제가 드러납니다.

그래서 그다음부터는 요청하는 순서를 바꿨습니다. 화면부터 말하지 않고 데이터가 어디에 어떻게 저장되고 누가 언제 읽는지를 먼저 정의해서 전달했습니다. 그러고 나서 화면을 붙였습니다.

이 순서가 바뀌면 결과가 확실히 달라집니다. 그리고 이것은 코딩 기술의 문제가 아닙니다. 무엇을 만들 것인지를 얼마나 정확히 말할 수 있는지의 문제입니다. 코드를 만드는 일이 쉬워질수록 이쪽이 병목이 됩니다.

실제로 든 돈

정리하면 이렇습니다.

• Grid 라이선스 — 500만 원
• 사내 인건비(증분) — 약 200만 원
• 소스 — 0원
• 합계 약 700만 원

외주 견적 1억과 비교하면 순절감이 약 1억 300만 원입니다. 라이선스와 유지보수 계약까지 회피한 금액을 합한 것입니다.

2개월 뒤의 숫자

만든 것보다 쓰이는 것이 중요합니다. 운영 2개월 시점의 실측치입니다.

• 누적 접수 112건 — 월 약 56건
• 완료 68 · 진행 35 · 접수 8 · 지연 1
• 완료율 61%, 평균 리드타임 153시간

이 숫자들이 중요한 이유는 절감액보다 이쪽이 검증이기 때문입니다. 만들어놓고 아무도 안 쓰는 시스템이 훨씬 흔합니다. 월 56건이 들어오고 있다는 것은 사람들이 실제로 이 경로를 쓰고 있다는 뜻입니다.

그리고 이 숫자는 보고서에서 가져온 것이 아닙니다. 시스템 대시보드에서 자동으로 집계된 것입니다. 만들 때 관제 화면을 함께 넣었기 때문입니다.

그런데 돈이 핵심은 아니었습니다

1억 대신 700만 원이라는 숫자가 눈에 띄지만, 몇 달 지나고 보니 더 중요한 것이 따로 있었습니다.

외주로 만들었을 때와 직접 만들었을 때 무엇이 달라지는지 정리해보면 이렇습니다.

• 초기 비용 — 과제당 수천만 원에서 1억 원대 / 라이선스와 사내 인건 수십~수백만 원
• 구축 기간 — 3~6개월 이상 / 2~4주
• 요구사항 변경 — 변경은 추가 비용과 재계약 / 대화로 즉시 반영
• 소스 소유권 — 벤더 종속, 내부는 블랙박스 / 사내 보유, 전면 공개
• 유지보수 — 연간 유지보수 계약 / 사내에서 즉시 대응
• 업무지식 — 벤더에 남는다 / 팀에 축적된다

앞의 두 개는 눈에 잘 보입니다. 그런데 실제로 일하면서 체감한 것은 뒤의 네 개였습니다.

바꿀 수 있다는 것. 쓰다 보면 반드시 고칠 것이 나옵니다. 외주였다면 변경 요청서를 쓰고 견적을 받고 승인을 받았을 일이 그날 오후에 끝납니다. 그래서 실제로 고칩니다. 고치는 비용이 높으면 불편을 참고 쓰게 되고, 참고 쓰다가 결국 엑셀로 돌아갑니다.

안이 보인다는 것. 왜 이렇게 동작하는지 알 수 있습니다. 문제가 생겼을 때 벤더에 문의하고 답을 기다리지 않습니다.

지식이 남는다는 것. 이것이 가장 큽니다. 외주 프로젝트를 하면 우리 업무를 벤더에게 설명하는 데 몇 주가 걸립니다. 그렇게 이전된 업무 지식은 프로젝트가 끝나면 벤더 쪽에 남습니다. 다음 프로젝트에서 또 설명해야 합니다. 직접 만들면 그 지식이 팀에 쌓입니다.

견적을 못 낸 게 아니라, 안 내도 됐습니다

처음에 1억 견적을 받았을 때는 "예산이 없어서 못 한다"는 결론으로 갔습니다. 지금 돌아보면 질문 자체가 틀렸습니다.

필요했던 것은 예산이 아니었습니다. 이 일을 우리가 직접 할 수 있는지에 대한 판단이었습니다. 그리고 그 판단의 근거는 하루짜리 교육에서 나왔습니다.

특별한 팀이 아니었습니다. 개발을 전업으로 하는 조직도 아니고, AI 전문 인력이 있는 것도 아닙니다. 한 명이 4주에 만들었습니다.

다음 글에서는 두 번째로 만든 시스템 이야기를 쓰겠습니다. 그쪽이 더 재미있습니다. "양식을 통일하라"는 지시를 받았는데, 양식이 필요 없는 시스템을 만들었습니다.