무엇이 문제였나: 개발 외주 제안서가 “툴 잘 쓰는 외주”로 읽혔다
개발 외주 제안서를 기술을 아는 사람에게 보낼 때 가장 큰 위험은 문장이 아니라 분류였습니다. 저희가 받은 일은 IT 회사가 보낸 요구사항 정의서에 맞춰 회사 개요와 수행 체계, 검증 결과를 담은 문서를 내는 일이었고, 그 문서를 읽을 사람은 그 회사의 CTO와 개발 담당자였습니다.
첫 판들은 저희가 어떻게 일하는지를 열심히 설명했습니다. 자동으로 도는 작업이 몇 개인지, 검사 장치가 몇 개인지, 승인을 몇 번 받았는지 같은 개수를 앞에 세웠습니다. 저희 눈에는 규모와 성실함의 증거였습니다.
그런데 맥락 없는 독자에게 CTO 역할을 맡겨 읽히자 반응이 달랐습니다. IT 회사 CTO는 크론 수나 도구 수 같은 개수를 결과로 읽지 않고, 그 문서를 쓴 쪽을 “툴 잘 쓰는 1인 외주”로 분류했습니다. 개수가 많을수록 오히려 그 분류가 굳었습니다.
비용도 컸습니다. 열 번째 판까지 가는 데 2026년 10월 15일부터 16일까지 약 18시간이 들었고, 요구사항을 설계 문서로 옮기는 단계에서만 도구 호출이 150번 넘게 들었습니다. 판마다 쪽수가 오르내렸습니다. 네 번째 판은 9쪽, 다섯 번째 판은 20쪽, 일곱 번째 판은 28쪽, 열 번째 판은 26쪽이었습니다.
시간을 쓰는 만큼 점수가 오르면 문제가 아닙니다. 문제는 다듬어도 점수가 그대로라는 점이었고, 그 원인을 잘못 짚은 채로 몇 판을 더 돌렸다는 점이었습니다. 이 글은 그 오판을 그대로 남깁니다.
처음 잰 숫자: 독자 검사 13회차 신규 지적 15건에서 시작
측정 방법부터 적겠습니다. 문서를 완성할 때마다 대화 맥락을 전혀 모르는 새 AI 독자를 띄우고, 고객 담당자와 심사자 역할을 맡겨 문서를 읽게 했습니다. 독자는 빈틈과 의문을 지적하고 10점 척도로 점수를 매깁니다. 매 회차 문서 속 금액·시간·날짜를 다시 계산하는 산술 검사도 넣었습니다.
설계 문서 단계에서 이 검사를 13회 돌렸습니다. 회차별 신규 지적 수는 15·15·9·10·5·6·2·3·4·7·7·6·7건이었습니다. 처음 두 회차는 15건씩 나왔고, 일곱 번째 회차에 2건까지 줄었다가 다시 7건으로 올라갔습니다.
수치 자체도 흔들렸습니다. 다섯 번째 판을 만들 때 문서에 쓴 숫자를 한 파일에 모아 다시 재 보니 서로 어긋난 값이 15건 나왔습니다. 개요와 과업내용서, 견적서, 회신 메일이 같은 날짜와 금액을 서로 다르게 적은 사례도 있었습니다. 한 문서는 11월 20일, 다른 문서는 11월 27일이었습니다.
반대 입장에서 문서를 공격하는 패널(구매 담당·경쟁 입찰사·법무·보안 네 역할)도 돌렸습니다. 설계 단계에서 15건, 다섯 번째 판에서 3건을 지적받았습니다. 점수로는 첫 판들이 10점 만점에 5점 근처였습니다.
시연 주소도 검사 대상이었습니다. 다섯 번째 판에 넣은 시연 6종 가운데 1종은 DNS 자체가 없어 열리지 않았습니다. 문장이 아무리 좋아도 열리지 않는 링크 하나가 문서 전체의 신뢰를 깎습니다.
정리하면 출발점은 이랬습니다. 독자 점수는 5점 근처, 신규 지적은 회차당 15건에서 시작, 수치 불일치 15건, 열리지 않는 시연 1종. 이 넷 가운데 어느 것이 점수를 붙잡고 있는지는 아직 몰랐고, 저희는 가장 눈에 띄는 숫자인 지적 건수와 불일치 건수부터 줄이기로 했습니다.
어떤 가설을 세웠나?
숫자를 보고 저희가 세운 가설은 두 가지였습니다. 둘 다 그럴듯했고, 둘 다 하던 일을 계속하라고 말해 주는 가설이었습니다.
- **가설 1: 문장과 숫자의 품질이 점수를 정한다.** 어긋난 수치를 바로잡고, 번역투와 과장을 걷어 내고, 운영 규모를 더 정확한 숫자로 보여 주면 점수가 오를 거라는 생각입니다.
- **가설 2: 신규 지적이 2회 연속 0건이면 문서가 끝난다.** 독자 검사를 반복해 새 지적이 더 나오지 않으면 그 문서는 완성이라는 기준입니다.
가설 1을 따라 다섯 번째 판에서 수치를 한 파일로 모아 다시 쟀고, 여섯 번째 판에서는 하자보수 1년 조건을 넣고 문장을 손봤습니다. 가설 2를 따라 독자 검사 회차를 계속 늘렸습니다. 지적이 줄면 끝이 가까워진다고 믿었습니다.
돌이켜 보면 두 가설 모두 문서의 주어를 건드리지 않습니다. 주어는 여전히 “저희가 일하는 방식”이었고, 저희는 그 주어 아래에서 문장만 계속 고쳤습니다.
가설은 어디서 틀렸나?
가설 2가 먼저 무너졌습니다. 13회차까지 돌려도 신규 지적은 0건으로 수렴하지 않았습니다. 일곱 번째 회차에 2건까지 내려간 뒤 3·4·7·7·6·7건으로 다시 올라갔습니다. 독자가 한 층을 고치면 그 아래 층을 파고드는 검사라서, “신규 0건 2회 연속”이라는 종료 기준은 처음부터 닫힐 수 없었습니다.
가설 1은 여덟 번째 판에서 무너졌습니다. 수치를 재측정 값으로 맞추고 원본 대조로 정정하고 인수 산출물 장까지 더했는데, 독자 점수는 4라운드째 7·6·6점에서 멈췄습니다. 문장을 더 다듬어도 점수가 2회 연속 오르지 않았습니다.
돌아보면 신호는 일찍 있었습니다. 처음 두 회차에 15건씩 나온 지적의 상당수가 개별 문장이 아니라 “이 시스템이 실제로 어떻게 움직이나”를 묻고 있었습니다. 저희는 그 질문을 문장의 모호함으로 읽고 문장을 고쳤고, 독자는 다음 회차에 같은 질문을 한 층 아래에서 다시 했습니다.
운영 규모 숫자를 더 정확하게 보여 주는 일은 오히려 역효과였습니다. CTO 독자는 개수를 결과로 읽지 않았고, 개수가 정확해질수록 “도구를 잘 쓰는 외주”라는 분류만 선명해졌습니다. 숫자가 맞는지가 아니라, 그 숫자가 독자의 질문에 답하는지가 문제였습니다.
이 지점에서 실패한 가설을 지우지 않고 규칙으로 남겼습니다. 점수가 2회 연속 오르지 않으면 문장 문제가 아니라 증거 문제로 보고, 다듬기를 멈추고 “무엇이 있으면 점수가 오르나”를 목록으로 넘깁니다.
진짜 원인은 무엇인가: 문서의 주어가 우리였다
진짜 원인은 문서의 주어였습니다. 첫 판들의 주어는 “저희 작업 환경”이었고, CTO가 알고 싶은 것은 “우리 회사가 받을 시스템”이었습니다. 대표가 일곱 번째 판을 보기 전에 남긴 지적도 같았습니다. 수행 체계가 이 요구사항에 도달하지 못한다는 말이었습니다.
기술을 아는 독자는 연구 수준인지 아닌지를 다섯 가지로 가립니다. 설계 판단과 그때 기각한 대안, 상태 전이, 산출 식, 평가 프로토콜입니다. 이 다섯이 고객 시스템을 주어로 보여야 문서를 연구 수준으로 읽고, 우리 작업 환경 설명은 그 뒤에 부록으로 있으면 충분합니다.
IT 회사 CTO 는 크론 수·도구 수 같은 개수를 결과로 읽지 않고 “툴 잘 쓰는 1인 외주”로 분류한다. 설계 판단과 기각한 대안, 상태 전이, 산출 식, 평가 프로토콜이 보여야 연구 수준으로 읽힌다.
두 번째 원인은 증거였습니다. 문장으로 메울 수 없는 감점이 있었습니다. 고객이 지정한 방법이 실제로 돌아가는지, 화면이 있는 과업이면 그 화면을 실제로 만들어 봤는지는 문장으로 증명할 수 없습니다. 이런 질문에는 시제품을 돌린 결과만 답할 수 있습니다.
세 번째 원인은 숫자의 집이 여러 곳이었다는 점입니다. 날짜와 금액, 주차를 문서마다 따로 적으니 판을 바꿀 때마다 어디선가 어긋났습니다. 15건의 불일치와 11월 20일과 11월 27일의 충돌이 같은 뿌리였습니다.
여섯 번째 판에서 받은 지적도 같은 방향이었습니다. 문서 안에서 약점과 한계, 불리한 비교를 스스로 지목하는 문장이 가장 나쁜 인상을 남겼습니다. “X에서 Y로 높였다”고 쓰면 자기 개선 서사로 읽혀 이전 값이 약점이 됩니다. 그래서 고객 문서에서는 “기준선 X를 넘어 Y”로 쓰고, 수치는 그대로 두되 약점을 지목하는 문장만 뺍니다. 신뢰구간 같은 통계 정직성은 남깁니다.
조치: 고객 시스템 장 13장과 시제품 3회 측정
일곱 번째 판에서 문서 구조를 뒤집었습니다. 고객 시스템을 주어로 한 장 6개를 본문 앞쪽에 세우고, 저희 개발 체계는 부록으로 내렸습니다. 이후 이 구조를 고객 전용 장 13장과 공용 장 11장으로 굳혔습니다.
고객 전용 장의 제목은 주장 문장으로 씁니다. 예를 들어 구성도 장의 제목은 “카카오 상담부터 승인 발송까지 열네 개 구성요소(C1~C14)로 나눠, 금액과 개인정보는 코드가 통제합니다”입니다. 상태 흐름 장은 견적이 정해진 열 개 상태 사이만 움직이고, 승인 뒤 조건이 바뀌면 그 승인을 자동으로 무효 처리한다고 적습니다.
위험 장은 그 과업에서 가장 위험한 일곱 곳을 이 체계가 직접 막는다고 쓰고, 인수 산출물 장은 산출물 여섯 묶음과 묶음마다 확인하는 시점을 적습니다. 일정 장은 11월 2일에 착수하면 8주차에 검수와 인수인계를 마치고 9주차는 정산에 쓴다고 적습니다. 일정의 요일은 코드로 계산하고, 주말에 걸리면 금요일로 당깁니다.
설계 문서는 목적별로 01부터 13까지 나눴습니다. 요구 ID와 구성요소·작업·인수 시험을 잇는 추적표, 외부 연동의 공식 문서 실측표, 구성요소와 상태 전이와 실패 경로, 스택과 운영비, 작업별 시간과 주차 부하, 위험 목록, 축소안, 고객에게 물을 것, 금액 배분, 미팅 안건을 각각 한 파일에 둡니다. 한 장으로 쓰면 숫자·날짜·원칙이 서로 어긋나기 때문입니다.
증거 문제에는 시제품으로 답했습니다. 설계 판단이 기대는 외부 동작(브라우저·OS·API)은 최소 시제품을 만들어 조건을 바꿔 가며 3회 이상 재고, 조건·값·설계 반영을 결과 파일에 남깁니다. 데스크톱 앱 과업에서는 고객이 지정한 자동 재생 인자 하나로는 가려진 창에서 7회 중 3회 재생하지 않았고, 같은 프로필로 다시 실행하면 종료 코드 0으로 끝나 비정상 종료를 정상으로 오판했습니다. 독자는 이 두 발견을 문서에서 가장 설득력 있는 부분으로 꼽았습니다. 경쟁 견적이 같은 AI에 같은 질문을 해서는 나오지 않는 내용입니다.
숫자의 집은 한 곳으로 모았습니다. 이번 문서에서 쓰는 수치는 측정일·명령·값을 적은 사실 파일 하나에서만 가져오고, 측정일이 45일을 넘은 운영 수치는 렌더 단계에서 거부합니다. 한 번 측정한 PoC 결과(98.3%·0.887 같은 값)는 고정값으로 두되, 결과를 본 뒤 정의를 바꾼 값은 어떤 문서에도 쓰지 않습니다.
검사는 다섯 단계로 순서대로 전부 돌립니다. 렌더하면서 금지어를 자동으로 잡고, 발표 자료 규칙 일곱 가지(P1~P7)로 구조를 보고, 반대 입장 패널로 공격하고, AI 티(대시·낫표·이모지·과장)를 잡고, 마지막으로 내부 경로나 내부 번호가 새지 않았는지 봅니다. 기계가 못 보는 것은 사람이 확인합니다. 데모 주소는 응답 코드 200을 확인한 것만 쓰고, 자격·등록 행은 보관함 원본과 품목·발급기관·날짜를 다시 대조합니다.
PoC 행을 넣는 기준도 정했습니다. 넣기 전에 그 PoC 폴더에서 검증 데이터 누수와 묶음 단위 bootstrap을 확인하는 감사 스크립트가 통과해야 하고, 비교 방법과의 차이 신뢰구간이 0을 포함하는 PoC는 성과 장에 넣지 않습니다. “진행 중”이나 “결과 대기”인 행도 넣지 않습니다. 렌더한 PNG는 직접 열어 한 쪽이 넘쳤는지 확인합니다. 렌더 검사는 한 쪽 넘침을 못 잡는다는 사실을 네 번째 장에서 실제로 겪었기 때문입니다.
종료 기준도 바꿨습니다. “신규 지적 0건 2회 연속” 대신 “상급 지적 0건 3회 연속 + 산술 일치”로 닫고, 5회차부터는 결정이나 실행을 바꿀 지적만 받습니다. 독자는 CTO·개발 리드·조달·법무 검토자 3역으로 두고, 같은 독자를 3라운드 넘게 돌리지 않으며, 마지막 라운드는 이전 라운드를 보지 않은 새 독자로 바꿉니다. 비슷한 실패를 겪은 글로 AI 견적 자동화에서 규칙을 안 읽는 문제도 함께 보시면 좋습니다.
고객 실자료는 저희 AI 코딩 에이전트에 넣지 않고, 합성 자료와 집계만 씁니다. 재위탁과 국외 이전 문제를 설계 단계에서 끊으려는 조치이고, 문서에도 실자료는 고객 환경에서만 다룬다고 적습니다.
재측정 결과: 5점이 6점으로, 그리고 6점에서 멈췄다
구조를 뒤집은 일곱 번째 판 28쪽은 맥락 없는 독자 점수가 5→6→6점으로 올랐습니다. 판을 거듭한 가운데 가장 큰 점프였고, 문장을 다듬은 판들이 내지 못한 상승이었습니다. 이후 PoC 3행과 대표 약력 12건을 정리한 열 번째 판 26쪽을 기준 문서로 삼았습니다.
일곱 번째 판 이후의 변화는 주로 증거를 바로잡는 일이었습니다. 여덟 번째 판은 PoC를 재측정 값 2행으로 맞췄고, 아홉 번째 판은 PoC 3행(NSFMS 과제 98.3%, 운송 과제 0.887 등)으로 정리했습니다. 열 번째 판은 고객사 수와 영업 건수를 지우고, 운영 규모를 나열하던 장을 품질 관리 체계(검사 장치·사람 승인·지식 카드) 장으로 바꿨습니다. 이 판들은 점수를 크게 올리지는 못했지만, 독자가 같은 지적을 되풀이하는 일은 줄였습니다.
다음으로 이 구조가 다른 과업에서도 통하는지 재측정했습니다. AI가 아닌 데스크톱 앱 과업에서 독자 3역의 점수는 1라운드 5·4·3점, 2라운드 6·4·4점이었고, 이전 라운드를 보지 않은 새 독자의 마지막 라운드는 5·5·4점이었습니다. 목표로 둔 6/10에 미달했습니다.
숫자를 정직하게 읽으면 이렇습니다. 주어를 바꾼 조치는 첫 과업에서 점수를 1점 올렸고, 같은 구조를 다른 성격의 과업에 옮기자 6점에 닿지 못했습니다. 한 번 재고 끝냈다면 “구조를 바꾸면 6점”이라고 적었을 텐데, 두 번째 과업이 그 결론을 반쯤 깎았습니다.
두 번째 과업에서 남은 감점은 문장이 아니었습니다. 독자는 인계 뒤 유상 대응 조건, 계약 보호 장치, 배포 실적을 지적했습니다. 이 셋은 문서를 고쳐서 얻을 수 없고, 계약 조건을 정하거나 실제로 납품해야 생깁니다.
남는 한계: 공용 장은 AI 과업 전제였다
첫째 한계는 공용 장의 전제입니다. 공용 장 11장 가운데 PoC 정확도, 품질 관리 체계, PoC 표, 개발 체계·평가 방법론·리서치 부록은 AI 과업을 전제로 만들었습니다. 데스크톱 앱 과업에서는 독자 두 라운드 모두 이 장들을 “관계없음”으로 지적했고, 그래서 비AI 과업 판은 회사·대표·시연 3개만 남깁니다.
둘째 한계는 사람 손입니다. 설계 문서 01~13은 서브에이전트 여러 개와 사람의 판단이 필요해 한 명령으로 돌지 않고, 첫 과업에서 도구 호출이 150번 넘게 들었습니다. 구성도 생성기는 한 줄 주 경로만 그리고, 갈래와 보류 경로 화살표는 아직 그리지 않습니다.
셋째 한계는 금액입니다. 개별 견적 금액을 이 문서에 싣지 못해, 계약 조건 요약 장은 금액 없이 지급 비율과 확인 시점, 무상 범위만 적습니다. 독자가 지적한 계약 보호와 유상 대응 조건도 같은 자리에 걸려 있습니다.
넷째, 6/10 자체가 아직 넘지 못한 선입니다. 남은 점수는 실제 납품 실적과 계약 조건이 쌓여야 움직일 것으로 보고 있고, 그 전까지 문장을 더 다듬는 일은 멈춰 둡니다.
다섯째, 이 방식은 반복 비용이 큽니다. 13회차 검사와 패널 15건, 판 열 개를 거치는 데 약 18시간이 들었고, 이 시간의 상당 부분은 점수가 움직이지 않는 다듬기에 썼습니다. 점수 정체를 더 일찍 증거 문제로 판정했다면 그 시간을 줄일 수 있었습니다.
개발 외주 제안서를 보내기 전에 무엇을 확인해야 하나?
이 과정을 거치며 남긴 확인 항목을 정리합니다. 개발 외주 제안서를 기술을 아는 독자에게 보내기 전에 아래를 먼저 봅니다.
- 문서의 주어가 “우리”인가 “고객이 받을 시스템”인가. 장 제목을 주장 문장으로 쓰고 주어를 고객 시스템에 둡니다.
- 설계 판단마다 기각한 대안과 이유, 상태 전이, 산출 식, 평가 프로토콜이 보이는가.
- 설계가 기대는 외부 동작을 시제품으로 3회 이상 재 봤는가. 고객이 지정한 방법의 구멍도 여기서 나옵니다.
- 날짜·금액·주차가 한 파일에서만 나오는가. 개요·과업내용서·견적서·회신을 서로 대조했는가.
- 시연 주소가 실제로 열리는가. 시연 6종 중 1종이 DNS 없이 나간 적이 있습니다.
- 점수가 2회 연속 오르지 않으면 문장을 멈추고 “무엇이 있으면 점수가 오르나”를 적는다.
요구사항 정의서를 받고 수행 체계 문서를 어떻게 짜야 할지 막막하다면, 저희가 같은 방식으로 정리해 드릴 수 있습니다. 상담으로 정의서를 보내 주시면 됩니다.