AI 프로젝트 인테이크 양식 설계

들어가며: 캔 것을 한 장으로 굳힌다

1편에서 인터뷰로 암묵지를 캐고, 2편에서 현행 업무(as-is)를 포착했다. 문제는 그 결과가 회의실을 나서는 순간 슬라이드와 기억으로 증발한다는 것이다. 그래서 이번 글의 목표는 단순하다. 그 캔 것을 복사해 쓰는 한 장짜리 양식으로 굳힌다.

이게 컨설팅 추상론이 아니라는 증거는 의외로 가까이 있다. AWS는 "Generative AI workload assessment questionnaire"를 다운로드 가능한 엑셀로 공개한다. 9개 섹션, 각 행이 질문 + 예시 답으로 돼 있고, 첫 칸은 그대로 *"이 유스케이스의 주된 목표 또는 성공 기준은 무엇인가?"*다.¹ 인테이크를 양식으로 받는다는 발상은 이미 벤더가 제품화했다.

다만 이 글의 양식은 한 가지가 다르다. 받아 적는 사양서가 아니라 컴파일러 입력이라는 점이다. 그게 무슨 뜻인지부터 짚자.

양식은 사양서가 아니다

가장 흔한 오해는 인테이크 양식을 "완전한 사양서를 받아내는 도구"로 보는 것이다. 그건 불가능하다. 고객은 결과를 봐야 비로소 자기가 뭘 원하는지 안다 - Barry Boehm이 2000년에 IKIWISI(I'll Know It When I See It)라고 이름 붙인, 25년 된 법칙이다.² (이 "결과 보고 요구가 쏟아지는" 문제는 6편의 주제다.)

그래서 좋은 인테이크 양식은 "원하는 걸 다 적으세요"를 "보여드릴 테니 반응하세요"로 바꾼다. 구체적으로 두 가지를 양식에 명시적으로 넣는다.

• 싼 데모 라운드를 산출물이 아니라 라인 아이템으로 약속한다. "1-3일 안에 같은 플로우의 2-3개 버전을 만들어 보여드린다"를 양식에 적는다. 데모를 보고 고객이 내뱉는 "이것도 돼? / 저건 왜 안 돼?"가 그 자리에서 발견된 요구사항이다.
• "미룬 요구사항(deferred)" 컬럼을 둔다. 인테이크 시점에 나온 "나중에 이것도" 요청을 거절도 흡수도 하지 않고 여기에 적어 둔다. Boehm이 말한 evolution requirements다. 이 레지스터는 다음 프로젝트 인테이크의 입력으로 되먹임된다.

이 두 장치 덕분에 양식은 "한 번에 다 받아내는 계약서"가 아니라 "발견을 구조화하는 그릇"이 된다.

한 장짜리 인테이크 양식

본론이다. 아래를 복사해서 쓰면 된다. 0번 게이트를 통과하지 못하면 1-6번은 의미가 없다.

# AI 프로젝트 인테이크: <프로젝트명>
 
## 0. 준비도 게이트 (먼저 통과해야 함)
- 이 업무가 디지털화돼 있나? (데이터·로그가 남는가) [예/부분/아니오]
- 데이터 사일로가 통합돼 접근 가능한가? (MIT CISR 2단계) [예/아니오]
- 막힌다면: 기술이 안 된 건가, 조직이 안 된 건가?
- 판정: [AX 진행 / 먼저 DX부터 / 보류]
 
## 1. As-Is: 지금 사람이 실제로 어떻게 하나
- (2편의 Work-as-Done 맵 / Domain Storytelling 결과 첨부)
- 정식 절차 vs 실제 우회·예외:
- "이상하다/잘했다"의 암묵 기준:
 
## 2. AI는 여기서 무엇을 하나 (멘탈 모델)
- 예측(AI가 싸게 하는 것):
- 판단(사람이 유지하는 것):
- 행동 / 결과:
- "마법"이 아니라 "예측 비용 하락"으로 적었는가? [체크]
 
## 3. 위임 경계 (무엇을 AI에, 무엇을 사람에)
- AI 위임 후보(반복·검증 쉬움):
- 인간 게이트 유지(되돌리기 어렵거나 검증 비쌈):
- 경계 밖이라 지금은 안 하는 것:
 
## 4. AI가 필요로 하는 정보 + 포맷
- 데이터 소스:
- 형태/스키마(표·문서·로그?), 양, 품질:
- 라벨/정답은 누가 만드나:
 
## 5. 성공과 모니터링 (빌드 전에 정한다)
- 합격 기준(통계치 또는 오류 비용 기반):
- 누가 채점하나(사용자/전문가 grader):
- 드리프트·재학습 트리거:
- go/no-go 기준:
 
## 6. 주의할 점 / 리스크
- pre-mortem: "1년 뒤 실패했다면 왜?"
- EU AI Act 리스크 등급(또는 사내 규정):
- 개인정보·보안·법적 제약:
 
## 7. 미룬 요구사항 (deferred / evolution)
- "나중에 이것도": (우선순위 오를 때만 진입)
 
## 8. 데모 라운드 약속
- N일 내 일회용 데모 X개로 반응 수집: [일정]

이 게이트가 비싸 보이는가. 게이트를 건너뛴 한 프로젝트를 통과한 적이 있다. 거기선 게이트 없이 발주가 나고, PoC를 몇 종 돌린 뒤 곧장 빌드로 들어갔다. 초반에 '전부 새로 짓는다'를 결정으로 먼저 박았는데, 며칠 만에 다른 회의에서 실제 작업 범위가 손에 꼽을 만큼 작아 전면 재설계가 불필요하다는 사실이 드러났고, 그 결정은 나흘 뒤 공식 폐기됐다. as-is(실제 범위)를 먼저 한 칸에 적었다면 애초에 안 내렸을 결정이다.

그 프로젝트에서 결정 기록(ADR)은 이 글이 그리는 방향과 반대로 작동했다. 이 글은 양식의 decisions 칸이 ADR 씨앗을 심는다고(앞에서 뒤로) 그리지만, 거기선 빌드를 시작한 뒤 사실이 하나씩 드러날 때마다 앞선 결정을 뒤집는 supersede 기록으로 ADR이 쌓였다. 한 결정이 다음 결정에 폐기되고 그게 또 정정되는 연쇄가 반복됐다. ADR이 인테이크에서 자란 씨앗이 아니라 게이트를 안 거쳐 생긴 재작업의 영수증으로 기능한 셈이다. 양식의 역할은 그 사후 정정의 빈도를 줄이는 것이지 0으로 만드는 게 아니다.

각 칸은 즉흥이 아니라 출처가 분명한 디스커버리 도구의 산출물이다. 그래서 채울 때 그 도구의 방법을 그대로 쓰면 된다.

고객과 개발자가 같은 양식의 다른 칸을 채운다

1편에서 인터뷰는 고객(도메인 진실)과 개발자(구현 진실) 양쪽에 한다고 했다. 인테이크 양식이 그 둘을 한 장에서 만나게 한다. 같은 섹션을 두 트랙으로 채운다.

두 칸이 충돌하면(고객은 "이게 1순위"인데 개발자는 "데이터가 없어 불가") - 그 충돌이 곧 ADR 후보다. 모건스탠리가 GPT-4 어시스턴트를 성공시킨 비결 하나가 이거였다. 어드바이저(현업)를 채점자(grader)로 양식에 묶어, 사용자와 빌더가 같은 성공 기준에 사인하게 했다.¹³ 또 Thoughtworks의 Lean Inception은 "Is / Is Not / Does / Does Not" 매트릭스로 범위 밖(NOT)을 명시적으로 적게 한다 - 3번 "지금은 안 하는 것" 칸이 바로 이것이다.¹⁴

한 사내 AI 빌더 프로젝트는 이 '범위 밖을 명시한다'는 원칙을 양식 규칙으로 더 밀어붙였다. 거기선 모든 컴포넌트 정의서에 'When NOT to Use'(이걸로 풀면 안 되는 경우 + 대신 어디로 라우팅)를 의무 섹션으로 두고, 능력 목록보다 먼저 읽게 배치했다. '안 쓸 때'를 '쓸 때'보다 더 길게 적게 하니 책임 누수와 중복 구현이 설계 단계에서 드러났다. 미완성 절은 빈칸으로 두지도 거짓으로 메우지도 않고 '(후속 작업으로 연기됨)' 표시를 붙인 뒤 별도 백로그에서 우선순위(P1/P2/영구 보류)로 추적했다. 7번 미룬 요구사항 칸의 정신이 이것이다. 미룬 항목도 통과/실패 이진이 아니라 추적 가능한 살아있는 자산으로 다뤄야 다음 인테이크의 입력으로 되먹임된다.

여기서 1편의 견적 검토 예시를 이어 보면, 채워진 양식은 이렇게 생긴다(발췌).

## 3. 위임 경계
- AI 위임 후보: 이상 견적 1차 스크리닝
- 인간 게이트 유지: 최종 "이상" 판정(김 과장)
- 지금은 안 하는 것(NOT): 자동 반려/승인
 
## 4. 정보 + 포맷
- 데이터 소스: 과거 견적서 PDF + 분리/통과 이력
- 형태: 표준화 안 됨(거래처별 양식 제각각) ← 개발자 플래그
- 라벨: 김 과장의 과거 판정 = 정답 데이터
 
## 7. 미룬 요구사항
- "통과한 것도 점수로 보여줘" → 우선순위 오르면 진입

출력이 컴파일러 입력이다

양식의 마지막 일은 기계가 읽을 수 있는 형태로 굳는 것이다. 사람이 채운 양식의 머리에 frontmatter를 붙이면, 그대로 Wiki raw로 들어가고 결정 칸은 ADR 씨앗을 심는다.

---
type: intake
project: 견적-스크리닝
status: scoped          # gate-passed | scoped | building
maturity_gate: pass     # pass | dx-first | hold
ai_role: 예측(이상 스크리닝), 판단은 인간 게이트
data_format_risk: high  # 거래처별 비표준 양식
success_metric: 재현율 우선, 오류비용=놓친 이상건
decisions:              # → ADR 씨앗
  - 1차 스크리닝만 AI, 최종 판정 인간 게이트
deferred:
  - 통과건 점수화
owners: [domain: 김과장, dev: ...]
review_after: 2026-08-28
---

이 frontmatter가 있으면 LLM Wiki의 검색·승격 루틴이 그대로 받아 처리할 수 있고(type·status·owners·review_after), decisions 항목은 ADR로, deferred는 다음 인테이크로 흐른다. 도구(어떤 양식 편집기를 쓰든)가 바뀌어도 이 마크다운은 남는다 - 8편에서 다룰 "도구에 안 묶이는 산출물"의 전형이다.

이 'frontmatter가 컴파일러 입력'이라는 발상은, 정작 게이트를 못 지킨 그 프로젝트가 사후적으로는 정확히 실천한 부분이기도 하다. 거기선 모든 설계 문서 머리에 사람이 읽는 '상태: 진행중' 한 줄 대신 기계가 파싱하는 frontmatter(status 생명주기, owners, 참조 링크)를 강제했다. AI가 문서를 읽고 유지하는 구조라 기계가 파싱할 머리표가 필요했기 때문이다. 한 발 더 나아가 인덱스나 상태 표 같은 파생물은 손으로 유지하지 못하게 막고, frontmatter의 status와 표의 status가 어긋나면 CI가 커밋을 막았다. 그런 자동 검증이 없던 초기에는 손으로 유지하던 문서 인덱스가 파일을 옮길 때마다 어긋났고, 특정 문서가 인덱스에서 통째로 누락된 채 한참 방치된 적도 있었다. 들어가며에서 말한 '회의실을 나서는 순간 증발한다'는 회의 산출물만의 문제가 아니다. 문서끼리도 드리프트한다. 인테이크 양식의 frontmatter도 정확히 이 자리에 놓인다: 사람이 채우되 드리프트는 기계가 잡는다.

한 가지 현실 점검. 이 양식을 LLM에게 통째로 채우라고 시키면 안 된다. 산업 조사에서 elicitation은 AI가 가장 약한 단계였고(완전 자동 5.4%),¹⁵ 인터뷰는 사람이 돌리되 LLM은 전사·구조화·빈칸 표시를 맡는다. 양식은 사람의 인터뷰를 담는 그릇이지, 인터뷰를 대신하는 봇이 아니다.

정리

• 인테이크 양식은 사양서가 아니라 컴파일러 입력이다. AWS가 인테이크 질문지를 공개하듯, 양식화 자체는 이미 검증된 실무다.
• 완전한 스펙을 받아내려 하지 마라(IKIWISI). 양식은 "적으세요"를 "보고 반응하세요"로 바꾸고, 싼 데모 라운드와 미룬 요구사항 컬럼을 명시한다.
• 구성: 0 준비도 게이트(DX 됐나) → 1 as-is → 2 AI 멘탈 모델(예측 vs 판단) → 3 위임 경계 → 4 정보+포맷 → 5 성공·모니터링 → 6 리스크(pre-mortem + EU AI Act) → 7 미룬 요구사항. 각 칸은 출처 있는 도구(AI/ML Canvas, Event Storming, pre-mortem)의 산출물.
• 고객과 개발자가 같은 양식의 다른 칸을 채운다. 충돌은 ADR 후보. 모건스탠리처럼 현업을 채점자로 묶고, Lean Inception처럼 범위 밖(NOT)을 명시한다.
• 양식 출력에 frontmatter를 붙이면 Wiki raw + ADR 씨앗으로 승격된다. 도구가 바뀌어도 마크다운은 남는다.

다음 글에서는 이 양식의 3번 칸, **"무엇을 AI에 위임할까"**를 깊게 판다. 답은 직관이 아니라 검증 비용으로 결정된다는 것, 그리고 jagged frontier 위에서 위임 결정을 어떻게 기록으로 남기는지.

참고 자료

인테이크 / 인셉션 양식 (실제 사례)

• AWS Generative AI workload assessment questionnaire
• Lean Inception (Paulo Caroli / martinfowler.com)
• Evaluate and define your gen AI use case (Google Cloud)
• Enterprise knowledge management with LLMs: Morgan Stanley (ZenML)

디스커버리 도구 (각 칸의 출처)

• A Simple Tool to Start Making Decisions with the Help of AI - AI Canvas (Agrawal, Gans, Goldfarb, HBR 2018)
• Machine Learning Canvas (Louis Dorard, OWN ML)
• Domain Storytelling (Hofer & Schwentner)
• EventStorming (Alberto Brandolini, Avanscoperta)
• User Story Mapping (Jeff Patton)
• Performing a Project Premortem (Gary Klein, HBR 2007)

게이트 · 리스크 · 범위

• Building Enterprise AI Maturity (MIT CISR)
• From Potential to Profit: Closing the AI Impact Gap (BCG, 2025)
• EU AI Act Article 6: Classification Rules for High-Risk AI Systems
• Requirements That Handle IKIWISI, COTS, and Rapid Change (Boehm, IEEE Computer 2000)
• AI for Requirements Engineering (Rani et al., arXiv 2511.01324)