기술 검토서는 왜 CTO에게 “툴 잘 쓰는 외주”로 읽혔나?
기술 검토서 작성에서 CTO 독자 점수를 막은 원인은 문장이 아니라 증거였습니다. 회사 소개와 운영 규모 숫자를 앞에 세운 문서는 IT 회사 CTO에게 “툴 잘 쓰는 1인 외주”로 읽혔고, 문장을 몇 번 고쳐도 점수는 움직이지 않았습니다. 점수가 처음 크게 움직인 때는 문서의 주어를 “저희 작업 환경”에서 “고객이 받을 시스템”으로 바꾼 판이었습니다.
고객이 요구사항 정의서나 요청서를 보내오면, 저희는 그 요구를 어떻게 구현할지 설명하는 기술 검토 문서를 돌려보냅니다. 읽는 사람은 고객 쪽 CTO, 개발 담당, 조달·법무 검토자입니다. 견적서가 “얼마”를 말한다면 기술 검토서는 “이 사람들이 이 일을 실제로 해낼 수 있나”를 말합니다.
문제는 비용이었습니다. AI 견적 시스템을 의뢰한 한 기업(이하 A사) 건에서, 첫 판 9쪽에서 마지막 판 26쪽까지 가는 데 2026년 10월 15일부터 16일까지 약 18시간이 들었습니다. 그 앞 단계인 설계 자료 묶음을 만드는 데만 에이전트의 도구 호출이 150번을 넘었습니다. 그런데 그렇게 만든 문서도 CTO 역 독자에게 높은 점수를 받지 못했습니다.
CTO가 문서를 낮게 보는 방식은 꽤 일관됐습니다. 자동 실행 작업 수나 검사 장치 수 같은 개수는 결과로 읽지 않습니다. 대신 “도구를 잘 다루는 사람이 혼자 하는 일”로 분류합니다. 반대로 설계 판단과 기각한 대안, 상태 전이, 산출 식, 평가 방법이 보여야 연구 수준의 작업으로 읽습니다. 이 글은 그 차이를 처음부터 알고 있지 않았던 기록입니다.
처음 잰 숫자: 독자 시험 13회와 9쪽에서 28쪽까지
측정 방법부터 적겠습니다. 문서를 완성할 때마다 대화 맥락을 전혀 모르는 새 AI 에이전트에게 문서를 읽혔습니다. 에이전트는 고객 담당자나 심사자 역할을 맡아 문서에서 막히는 곳을 지적하고, 10점 척도로 점수를 매깁니다. 이 글에서는 이를 “독자 시험”이라 부릅니다. 매 회차 문서 안의 금액·시간 합계를 다시 계산하는 산술 확인도 함께 넣었습니다.
A사 설계 단계에서 독자 시험을 13회 돌렸습니다. 회차마다 나온 지적 수는 15, 15, 9, 10, 5, 6, 2, 3, 4, 7, 7, 6, 7이었습니다. 처음 다섯 번은 줄어들다가, 일곱 번째 2건을 바닥으로 다시 6~7건 사이를 오갔습니다. 0으로 수렴하지 않았습니다.
같은 기간 문서는 계속 커졌습니다. 첫 렌더는 9쪽, 다음 판은 20쪽, 고객 시스템 장을 넣은 판은 28쪽이었고, 마지막 판은 26쪽으로 정리했습니다. 20쪽 판을 만들 때는 문서에 쓴 수치를 처음부터 다시 재서 서로 어긋난 값 15건을 고쳤습니다. 반대 입장 검토(구매 담당·경쟁 입찰사·법무·보안 4역)를 따로 돌려 설계 단계에서 15건, 20쪽 판에서 3건을 지적받았습니다.
CTO 역 독자의 점수는 고객 시스템 장을 넣은 28쪽 판에서 5, 6, 6으로 움직였습니다. 그다음 판에서는 4라운드를 돌려 7, 6, 6이 나왔고, 거기서 더 오르지 않았습니다. 이 정체가 이 글의 출발점입니다.
세운 가설: 문장을 다듬으면 점수가 오른다
처음 세운 가설은 단순했습니다. 독자가 지적하는 곳을 하나씩 고치면 지적 수는 줄고 점수는 오른다. 지적은 대부분 문장 단위로 나왔습니다. 이 표현이 모호하다, 이 숫자의 출처가 없다, 이 장과 저 장의 날짜가 다르다. 그래서 문장을 고치는 일이 곧 문서를 고치는 일로 보였습니다.
두 번째 가설은 종료 기준이었습니다. “새 지적이 2회 연속 0건이면 끝낸다”. 지적이 줄어드는 추세라면 언젠가 0에 닿는다고 봤습니다.
세 번째 가설은 신뢰를 어디서 사느냐였습니다. 회사 개요, 대표 약력, 공공 과제에서 돌린 시범 구축(PoC) 정확도, 품질 관리 체계, 시연 데모, 개발 체계 부록을 공용 장으로 만들어 두고, 어느 고객 문서에든 붙였습니다. 공용 장이 11장, 고객마다 새로 쓰는 장이 13장이었습니다. 실적과 규모를 보여 주면 신뢰가 생긴다는 생각이었습니다.
가설이 틀린 지점은 어디였나?
첫 번째 가설은 점수가 멈추면서 깨졌습니다. 4라운드에서 7, 6, 6이 나온 뒤로는 어떤 문장을 고쳐도 같은 자리를 맴돌았습니다. 지적의 성격도 바뀌었습니다. 표현을 고쳐 달라는 요청이 아니라 “이걸 실제로 해 봤다는 근거가 없다”는 쪽으로 옮겨 갔습니다. 문장으로는 그 빈칸을 채울 수 없었습니다.
두 번째 가설은 13회 기록이 반증합니다. 지적 수가 2건까지 내려간 뒤 다시 7건으로 올라갔습니다. 앞 회차의 지적을 고치면 독자는 그 아래층을 파고들어 새 지적을 찾습니다. “새 지적 0건 2회 연속”은 층을 파는 검사에서는 닫히지 않는 조건이었습니다.
세 번째 가설은 가장 비싸게 틀렸습니다. 일반 소프트웨어 과업인 데스크톱 앱 의뢰(이하 B사)에 AI 과업용 공용 장을 그대로 붙였더니, 1라운드와 2라운드 독자가 모두 PoC 정확도·평가 방법론·개발 체계·품질 지표 장을 “관계없음”으로 지적했습니다. 운영 규모 숫자는 신뢰가 아니라 “툴 잘 쓰는 외주”라는 분류의 근거로 쓰였습니다.
수행 체계가 이 요구사항에 도달 못 함, 2026년 10월 16일, 문서를 검토한 대표의 지적
이 지적이 방향을 바꿨습니다. 저희가 얼마나 많이 갖췄는지는 고객의 요구사항과 연결되지 않았습니다. 문서 대부분이 우리 이야기였고, 고객이 받을 시스템 이야기는 일부였습니다.
진짜 원인은 무엇이었나?
원인은 두 겹이었습니다. 첫째는 문서의 주어입니다. 앞선 판들의 주어는 “저희 작업 환경”이었습니다. 점수가 처음 크게 오른 28쪽 판은 고객 시스템 장 6개를 본문에 넣고 저희 개발 체계는 부록으로 내렸습니다. 독자 점수가 5에서 6으로 오른 시점이 이 판입니다. 판 기록에도 이 변화를 “가장 큰 점프”로 남겼습니다.
둘째는 증거의 종류입니다. 점수가 2회 연속 오르지 않으면 문장 문제가 아니라 증거 문제라는 판단을 이때 세웠습니다. CTO가 원한 증거는 공공 과제 정확도가 아니라 “이 고객 과업에 대해 이미 돌려 본 것”이었습니다. 다른 과제의 수치로 신뢰를 사려는 시도는, 읽는 사람 쪽에서 보면 이 과업과 관계없는 이야기였습니다.
이 원인은 같은 질문을 AI에 다시 던져서는 찾기 어렵습니다. AI에게 기술 검토서를 써 달라고 하면 회사 소개, 실적, 일반적인 설계 원칙이 담긴 문서가 나옵니다. 경쟁 견적도 같은 AI에 같은 질문을 하면 같은 문서를 받습니다. 차이는 그 고객 과업을 직접 돌려 본 결과에서만 생겼습니다.
조치 1: 주어를 고객 시스템으로 바꾸고 설계 근거로 채웠다
가장 먼저 문서의 기본형을 바꿨습니다. 2026년 10월 20일부터 어느 고객이 와도 먼저 “고객 문의 답변형 기술 검토”를 만듭니다. 회사 개요와 공용 장 구성은 고객이 회사·수행 인력 자료를 따로 요청했을 때만 씁니다. 장 이름의 주어도 기업명이나 서비스명으로 씁니다. “귀사 시스템”이 아니라 고객사 이름을 넣은 “○○ 시스템”입니다.
기본 장 순서는 다음과 같습니다. 문의하신 것 → 요청과 대응 → 시스템 → 평가 설계 → 위험과 대응 → 수행과 인수 → 일정·계약 조건·여쭤볼 것 → 끝장. 첫 장 왼쪽 칸에는 고객이 쓴 문의 문장을 요약하지 않고 그대로 둡니다.
회사 소개를 뺀다고 CTO 기준이 낮아지지는 않습니다. 뺀 자리는 이 고객 과업의 설계 근거로 채웁니다. 기각한 대안과 그 이유, 상태 전이와 승인이 무효가 되는 조건, 산출 식과 보류 기준, 시험셋·합격선·측정 시점이 들어갑니다. A사 문서의 장 제목을 예로 들면 이렇습니다.
- 카카오 상담부터 승인 발송까지 열네 개 구성요소(C1~C14)로 나눠, 금액과 개인정보는 코드가 통제합니다
- 핵심 설계 판단마다 기각한 대안과 이유를 남겼습니다
- 견적은 정해진 열 개 상태 사이만 움직이고, 승인 뒤 조건이 바뀌면 승인이 자동으로 무효가 됩니다
- 이 체계는 과업에서 가장 위험한 일곱 곳을 직접 막습니다
- 인수 산출물은 여섯 묶음이고, 묶음마다 확인하는 시점을 정해 두었습니다
과업 유형에 따라 붙이는 장도 나눴습니다. 정의서가 챗봇·검색 기반 답변·예측·생성 같은 AI 과업이면 평가 방법론과 시범 구축 결과가 의미를 갖습니다. 데스크톱 앱·웹·연동 같은 일반 소프트웨어 과업이면 그 장들을 빼고 회사·대표·시연 3장만 남깁니다. 같은 장이라도 과업이 다르면 독자에게는 관계없는 쪽수가 됩니다.
장 제목을 주장 문장으로 쓰면 목차만 훑는 독자도 설계의 뼈대를 읽습니다. 구성도와 상태 흐름 두 장은 설계 문서의 구성요소 표와 상태 표에서 생성기로 그립니다. 같은 값을 두 곳에 적지 않기 위해서입니다.
설계 자료도 한 문서로 쓰지 않고 목적별 13개 파일로 나눴습니다. 요구 ID와 구성요소·작업·인수 시험의 대응표, 외부 연동의 공식 문서 인용표, 구성요소와 상태 전이, 스택과 운영비, 작업별 시간, 위험 목록, 축소안, 고객에게 물을 것, 금액 배분 같은 식입니다. 한 문서에 몰아 쓰면 숫자·날짜·원칙이 서로 어긋났기 때문입니다. A사 건에서도 두 문서의 날짜가 11월 20일과 11월 27일로 엇갈린 일이 있었습니다.
조치 2: 시제품을 먼저 돌리고, 생성기가 렌더를 거부하게 했다
증거 문제를 풀려면 이 과업을 실제로 돌려 본 결과가 필요했습니다. 그래서 설계가 기대는 외부 동작(브라우저·OS·API)은 최소 시제품을 먼저 만들어 조건을 바꿔 가며 3회 이상 재기로 했습니다. 화면이 있는 과업이면 실제 화면 시제품까지 만듭니다.
B사 건에서 2라운드 독자의 1순위 지적은 “콘솔뿐, WPF 증거 없음”이었습니다. 이 지적은 문장으로 풀리지 않았고 WPF 화면 시제품을 만들고서야 풀렸습니다. 시제품은 고객이 지정한 방법의 구멍도 찾아냈습니다. 자동 재생 인자 하나로는 다른 창에 가려진 상태에서 7회 중 3회 재생하지 않았습니다. 같은 프로필로 다시 실행하면 종료 코드 0으로 끝나, 비정상 종료를 정상으로 오판할 수 있었습니다.
3라운드 독자는 이 두 발견을 문서에서 “가장 설득력 있는 부분”으로 꼽았습니다. 경쟁 견적이 같은 AI에 같은 질문을 해서는 나오지 않는 내용입니다. 고객 실자료는 저희 AI 코딩 에이전트에 넣지 않고 합성 자료와 집계만 씁니다. 재위탁과 국외 이전 문제를 설계 단계에서 끊기 위해서입니다.
문장 규칙은 사람의 기억에 맡기지 않고 문서 생성기에 넣었습니다. 2026년 10월 20일 대표가 남긴 지적 7개를 각각 기계 규칙으로 바꿨고, 생성기는 규칙을 어긴 문서의 렌더를 거부합니다.
마지막 7번 규칙이 깊이 하한입니다. 설계 판단 표(기각한 대안 칸), 시스템 구성도, 기술 스택, 평가 지표와 합격선, 인수 시험, 위험과 대응 중 하나라도 빠지면 렌더하지 않습니다. 회사 소개를 뺀 문서가 얕아지는 일을 막는 장치입니다.
수치를 다루는 규칙도 몇 가지 더 세웠습니다. 결과를 본 뒤 정의를 바꾼 값은 개발용으로 내려 두고 어떤 문서에도 쓰지 않습니다. 비교 방법과의 차이에서 신뢰구간이 0을 포함하는 결과도 성과 장에 넣지 않습니다. 외부 연동은 별도 에이전트가 공식 문서를 직접 확인하고, 설계는 그 원자료의 행 번호를 인용합니다. 공식 문서의 제약을 설계 쪽에서 넓히거나 줄이지 않기 위해서입니다. 데모 주소는 응답 200을 확인한 것만 씁니다. A사 20쪽 판에서 시연 6종 중 1종의 주소가 연결되지 않았던 일이 있어서입니다.
검사 종료 기준도 바꿨습니다. “새 지적 0건 2회 연속” 대신 “심각도 상(上) 지적 0건 3회 연속 + 산술 일치”입니다. 5회차부터는 결정이나 실행을 바꿀 지적만 받습니다. 같은 독자를 3라운드 넘게 쓰지 않고, 마지막 라운드는 이전 라운드를 보지 않은 새 독자(held-out)로 바꿉니다. 문서 수치는 측정일·명령·값을 적은 파일 한 곳에서만 가져오고, 측정일이 45일을 넘은 운영 수치가 있으면 렌더를 거부합니다.
재측정 결과: 5·4·3에서 6·4·4, 새 독자는 5·5·4
바뀐 방식을 처음 끝까지 적용한 건이 B사입니다. 비AI 데스크톱 과업이라 AI용 공용 장을 빼고 회사·대표·시연 3장만 남겼습니다. CTO·개발 리드·조달·법무 검토자 세 독자의 점수는 1라운드 5·4·3, 2라운드 6·4·4였습니다. 마지막 라운드에 이전 라운드를 보지 않은 새 독자로 바꿨더니 5·5·4가 나왔습니다.
숫자를 그대로 읽으면 이렇습니다. 2라운드에서 가장 높은 점수는 6점이었습니다. 이전 라운드를 본 적 없는 독자로 바꾸자 최고점은 5점으로 내려왔고, 대신 가장 낮은 점수는 3점에서 4점으로 올라갔습니다. 세 독자 모두 6/10에 닿은 라운드는 없었습니다. 목표 6점은 넘지 못했습니다.
2라운드의 6점은 앞 라운드를 읽은 독자가 고친 문서를 다시 읽으며 준 점수였습니다. 그 독자는 무엇이 고쳐졌는지 알고 읽습니다. 마지막 라운드를 이전 기록을 모르는 새 독자로 바꾼 이유가 여기 있고, 저희는 새 독자의 5·5·4를 기준값으로 씁니다.
그래도 바뀐 것은 있습니다. 1·2라운드 독자가 “관계없음”으로 지적한 AI 공용 장은 빼면서 사라졌고, “콘솔뿐”이라는 1순위 지적은 화면 시제품으로 닫았습니다. 이 방식은 2026년 10월 20일 다른 고객(C사) 문서에도 적용해 새 규칙을 통과했습니다.
남는 한계: 6점을 막는 감점은 문서 밖에 있다
B사 새 독자가 남긴 감점은 문장이 아니라 사업 조건이었습니다. 인계 뒤 유상 대응을 어떻게 하는지, 계약이 고객을 어떻게 보호하는지, 배포 실적이 있는지. 문서를 더 다듬어서는 풀 수 없고 계약 조건이나 실적을 바꿔야 오르는 점수입니다. 앞에서 세운 판단, 점수가 2회 연속 오르지 않으면 증거 문제라는 판단이 여기서도 그대로 맞았습니다.
자동화도 덜 끝났습니다. 구성도 생성기는 한 줄짜리 주 경로만 그리고, 갈래나 보류 경로 화살표는 아직 그리지 못합니다. 13개 설계 자료는 여러 에이전트와 사람의 판단이 필요해 한 명령으로 돌지 않습니다. 개별 견적 금액은 문서에 넣지 못해, 계약 조건 장에는 지급 비율·확인·무상 범위만 씁니다. 견적은 별도 견적서로 냅니다.
문서 쪽에서 할 수 있는 일도 아직 남아 있습니다. 렌더 검사기는 한 쪽에서 내용이 넘치는 문제를 잡지 못해, A사 문서의 한 장에서 실제로 넘침이 있었습니다. 그래서 렌더한 이미지를 사람이 직접 열어 확인하는 단계를 지우지 못했습니다. 반대 입장 검토가 인용한 법·공고 조문을 원문으로 확인하지 못했으면 문서에 “원문 확인 미완”으로 표시하고 단정하지 않습니다. 기계가 보는 범위와 사람이 보는 범위의 경계가 아직 고정되지 않았습니다.
정리하면, 기술 검토서 작성에서 CTO 독자를 설득하는 쪽은 회사가 얼마나 많이 갖췄는지가 아니었습니다. 고객이 받을 시스템을 주어로 세우고, 그 과업을 직접 돌려 본 결과로 설계 판단을 받치는 쪽이었습니다. 문장 다듬기가 두 번 연속 점수를 못 올리면 거기서 멈추고 무엇이 있어야 점수가 오르는지 목록을 만드는 편이 빠릅니다.
검증을 사람의 기억 대신 기계 규칙에 넣는 방식은 AI 에이전트 작업 검증 자동화 글에 더 자세히 적었습니다. 요구사항 정의서를 받아 두고 기술 검토 문서가 필요하다면 상담으로 남겨 주세요.
작성: SGK Studio 엔지니어링