5장. AI 작업 계약을 쓴다
“요약해 줘”와 “이사회가 투자 여부를 결정할 수 있도록 세 페이지로 요약해 줘”는 다른 작업이다. AI 작업 계약은 모델을 통제하는 마법 문장이 아니라, 사람과 AI가 같은 완료 상태를 바라보게 하는 짧은 명세다.
작업 계약의 필수 칸은 다음과 같다.
goal: 무엇을 위해 무엇을 만든다
audience: 누가 어떤 상황에서 읽는다
decision: 이 결과로 무엇을 결정한다
inputs: 사용할 자료와 기준일
constraints: 금지·범위·보안·길이
output: 형식과 필수 항목
evidence: 주장에 필요한 근거
success: 완료를 판정하는 관측 기준
authority: 읽기·수정·외부 실행 권한
DecisionDesk의 계약은 “제품 출시 분석”이 아니다. “고객 인터뷰와 운영 제약을 근거로 4주 베타를 시작할지 조건부 연기할지 결정하는 한 페이지 브리프”다. 필수 출처 세 개, 근거 없는 수치 금지, 개인정보 반복 금지, 외부 공지 승인 대기를 명시한다.
{
"decision": "지금 베타를 시작할지, 조건부 연기할지 선택",
"output": "한 페이지 결정 브리프와 승인 요청",
"requiredSourceIds": ["SRC-01", "SRC-02", "SRC-03"],
"authority": "초안 작성만, 발송·게시 금지"
}
계약을 길게 쓰는 것이 목표가 아니다. 결과를 바꾸는 정보만 넣는다. 문체를 다섯 번 반복하면서 정작 독자와 결정이 빠진 프롬프트는 나쁘다. 반대로 “한 문단”이라도 결정, 자료, 금지, 검증이 분명하면 강하다.
실패했을 때는 “AI가 말을 안 듣는다”라고 끝내지 않는다. 어떤 계약 칸이 비었는지 확인한다. 근거가 없으면 입력 문제, 형식이 흔들리면 출력 계약 문제, 중요 반대 의견이 빠지면 성공 기준 문제일 수 있다.
examples/work-contract.json을 복사해 자신의 업무로 바꾸되, 첫 시도에는 칸을 추가하지 않는다. 결과를 본 뒤 필요한 칸만 늘린다.
계약 디버깅 워크숍
결과가 불만족스러울 때 증상과 계약 칸을 연결한다.
| 증상 | 먼저 확인할 칸 | 수정 예 |
|---|---|---|
| 결론이 독자에게 너무 기술적 | audience | 선행지식과 읽는 상황 추가 |
| 중요한 쟁점 누락 | decision·success | 결정 기준과 필수 질문 추가 |
| 없는 숫자 생성 | inputs·evidence | 필수 출처와 abstain 규칙 추가 |
| 매번 형식이 달라짐 | output | 필수 섹션 또는 schema 추가 |
| 마음대로 게시 | authority | 초안/외부 행동 경계와 승인 추가 |
계약을 수정할 때 이전 버전을 보존한다. 결과가 나빠지면 어느 변경이 원인인지 알 수 있어야 한다. v1 → v2에서 한 번에 한 요소만 바꾸고 같은 fixture로 다시 실행한다. “더 친절하게, 더 정확하게, 전문가처럼” 같은 관측 불가능한 문구는 성공 기준으로 바꾼다. 예를 들어 “처음 등장하는 용어를 한 문장으로 정의하고 각 단계에 예상 결과와 실패 복구를 붙인다”라고 쓴다.