intent.md를 쓰는 사람은 누구인가 — 도메인 전문가가 AI로 서비스를 만들 때 경력이 들어가는 자리
Anthropic이 낸 AI 네이티브 개발 절차는 개발자가 아니어도 intent.md를 쓸 수 있다고 합니다. 반은 맞습니다 — 전문 분야라면 경력이 진짜 들어가는 자리는 intent.md가 아니라 그 옆에 따로 있습니다.
1. 무엇이 바뀌었나 — 인수인계 겹이 사라졌다
전통적인 개발 절차에서 “기능을 원하는 사람”과 “만드는 사람” 사이에는 백로그·유저스토리·스토리포인트·담당자 이관이 여러 겹 끼어 있었습니다. Rob Shocks의 영상은 이 겹의 정체를 이렇게 짚습니다.
“the idea passed to a backlog of user entries, user stories, story points, ownership transfers, handoff” [02:02] (아이디어가 백로그의 항목, 유저스토리, 스토리포인트, 소유권 이전, 인수인계로 넘어갔다)
원하는 사람의 머릿속 맥락을 만드는 사람에게 옮기는 과정에서 번역 장치가 끼었고, 옮길 때마다 맥락이 샜다는 뜻입니다. Anthropic Applied AI 팀의 플레이북(각주 1)은 이 겹을 문서 하나로 걷어냅니다. 발의자(originator)가 Claude와 브레인스토밍해 그 결과를 intent.md로 적고, 다음 단계는 그 문서를 읽고 시작합니다.
플레이북 원문은 intent.md를 이렇게 정의합니다.
“a proto-spec in the originator’s own terms” (발의자 자신의 말로 쓴 예비 명세)
발의자가 적는 것은 네 가지입니다 — 지금 못 하는 것, 영향을 받는 사람, 나아진 모습, 범위 밖인 것. 형식 언어는 필요 없습니다(“No formal language is required”).
2. “누구나 쓸 수 있다”는 말의 숨은 조건
영상은 발의자가 개발자일 필요가 없다고 합니다.
“It could be a customer who’s putting in a bug request. It could be a product manager who has an idea for a feature.” [03:35] (버그를 신고하는 고객일 수도, 기능 아이디어가 있는 PM일 수도 있다)
고객·PM이라는 구체적 예시는 영상의 설명입니다. 정본도 비개발자의 Claude 접근과 여러 구성원의 참여를 전제합니다 — 기반 설비 항목에 “엔지니어가 아닌 사람을 위한 Claude 접근”을 두고, Git을 모르는 기여자는 커넥터를 통해 참여하면 된다고 적습니다. 다만 전문 분야의 결과를 누가 검증할지는 별도의 설계 문제입니다.
그런데 영상이 실제로 든 예는 다크모드입니다 [02:33]. 원하는 사람이 결과를 눈으로 확인할 수 있는 기능입니다. 법률 서비스처럼 결과가 맞는지를 그 분야를 아는 사람만 판단할 수 있는 경우에는 사정이 다릅니다. 발의자가 곧 검수자가 되고, 검수자는 전문가여야 합니다.
즉 “누구나”에는 결과를 스스로 검증할 수 있는 사람이라는 조건이 숨어 있습니다. 전문 분야 서비스에서 그 조건을 만족하는 비개발자는 사실상 그 분야 전문가뿐입니다.
3. 혼자 만드는데 문서가 왜 필요한가
발의자·검수자가 한 사람이면 문서 체인은 왜 필요합니까. 그냥 AI와 대화하며 만들면 되지 않습니까.
답은 “넘길 상대”가 사람이 아니라는 데 있습니다.
“Independent agents, sub-agents are going to handle this process. … You want to hand off your planning, your intent as documents to each one, so it can start from scratch without an understanding of the previous conversation that happened.” [07:37] (독립된 에이전트와 서브에이전트가 이 과정을 맡는다. 계획과 의도를 문서로 넘겨서, 이전 대화를 모른 채 처음부터 시작할 수 있게 해야 한다)
혼자 개발이라도 컨텍스트 창은 끊깁니다. 문서는 기억이 없는 다음 에이전트에게 넘기는 인수인계서입니다.
그러면 intent.md는 spec과 plan이 나온 뒤에도 쓸모가 있습니까. 영상은 plan.md의 기준을 “intent나 spec을 참조하지 않고도 구현할 수 있어야 한다” [07:07]고 둡니다. 뒤 문서가 앞 문서를 흡수한다면 intent.md는 중간 산출물일 뿐입니다.
intent.md가 남는 이유는 하나입니다 — 개발이 잘못된 방향으로 갔을 때 돌아갈 원점. spec과 plan은 “무엇을 어떻게”만 남기고 “왜 아픈가”를 잃습니다. 플레이북도 유지보수 단계에서 같은 자리를 씁니다.
“A trigger such as a control-band breach, a ticket, a channel message or a schedule invokes Claude without a person in the path. … The agent writes its diagnosis as intent.md” (관리 범위 이탈, 티켓, 채널 메시지, 일정 같은 트리거가 사람 없이 Claude를 부른다. 에이전트는 진단 결과를 intent.md로 쓴다)
intent.md는 체인의 시작점이자 재시작점입니다.
4. 전문가 없이 “맞다”를 판정하는 장치
여기서 가장 중요한 갈림길이 나옵니다. 전문가가 intent를 쓰고 AI가 만들었다고 해서 끝이 아닙니다. 만들어진 것이 맞는지 누가 판정합니까.
영상이 제시하는 답은 평가(eval)입니다.
“you might collect 20 or so issues or things that you might have solved in the code base. You have a set of expected outcomes for those” [11:39] (해결한 이슈 20개쯤을 모으고, 각각의 기대 결과를 정해 둔다)
플레이북은 이 평가를 CI에 넣어 “CLAUDE.md·스킬·훅이 바뀔 때마다” 돌리라고 합니다.
평가를 다른 모델에 맡기는 방법도 있습니다. Claude Code가 만들면 Codex가 평가하는 식으로, 같은 모델의 맹점을 같은 모델이 못 보는 문제를 피합니다. 영상도 PR 리뷰를 별도 Claude 인스턴스에 맡깁니다 [12:39].
그러나 평가 에이전트에는 한계가 있습니다. spec대로 됐는가는 볼 수 있어도 분야 기준으로 맞는가는 못 봅니다. Codex가 Claude보다 법을 더 알지 못하니, 둘이 서로 맞다고 해도 둘 다 틀릴 수 있습니다. 평가에 쓰이는 “기대 결과”는 결국 전문가가 써야 합니다. 평가 에이전트는 전문가의 판단을 대체하는 장치가 아니라 재사용하는 장치입니다. 재사용하려면 먼저 한 번은 써 놓아야 합니다.
5. 제품 설계가 먼저다 — 두 갈래 길
“방향은 전문가가 잡고 평가는 기술이 한다”는 분업은 그럴듯하지만 구멍이 있습니다. 방향은 intent에서 한 번 정하면 되지만, 서비스의 출력물은 매번 나오고 그 하나하나가 분야 내용입니다. 계약서 검토 서비스라면 “돌아가는가”는 기술이고 “무슨 서비스인가”는 방향이지만, “이 조항을 위험하다고 짚은 것이 맞는가”는 둘 다 아닙니다.
그래서 이것은 평가 문제이기 전에 제품 설계 문제입니다.
| 길 A — AI가 분야 판단을 생성 | 길 B — 전문가 판단을 규칙화해 AI가 적용 | |
|---|---|---|
| 분야 정확성 | 매 출력마다 검증 필요 | 규칙을 검증하고 적용 결과를 반복해 평가 |
| 평가 가능성 | 기대 답 20개로도 부족 | 규칙 → 사례로 테스트 가능 |
| 전문가 역할 | 상시 검수자 | 규칙 저자 + 예외 처리 |
| 경력이 들어가는 자리 | 검수 | 설계 문서 |
길 A를 고르면 발의자는 결국 검수자로 되돌아갑니다. 길 B를 골라야 “전문가가 발의자”라는 말이 진짜 뜻을 갖습니다.
6. 그렇다면 규칙은 어디에 쓰는가
길 B를 고르면 마지막 질문이 남습니다. 전문가의 판단 규칙은 어느 문서에 들어갑니까.
- intent.md에 넣으면 — “왜 아픈가”를 넘어 규칙집이 됩니다. 무거워져서 원점 구실을 못 합니다.
- spec.md에 넣으면 — spec은 intent에서 자동 생성되는 문서입니다 [04:35]. 자동 생성기가 수십 년 판단 규칙을 만들 수는 없습니다.
플레이북에 답이 있습니다.
“The organization’s skills are applied as constraints on the spec.” (조직의 스킬이 spec에 대한 제약으로 적용된다)
문서 체인 바깥에, 체인 전체에 걸쳐 적용되는 지식층이 따로 있습니다. 전문가의 규칙은 여기 — 도메인 스킬 — 에 갑니다.
| 층 | 무엇을 담나 | 누가 쓰나 | 얼마나 자주 바뀌나 |
|---|---|---|---|
| 도메인 스킬 | 모든 기능이 따라야 할 판단 규칙 | 전문가만 | 드물게 |
| intent.md | 이번에 풀 페인 포인트, 영향받는 사람, 범위 밖 | 발의자(누구나) | 기능마다 |
| spec.md | 요구사항·설계 — 스킬을 제약으로 자동 생성 | AI | 기능마다 |
| plan.md | 바꿀 파일·순서·위험·검증 | AI + 검토 | 기능마다 |
결론이 이렇게 뒤집힙니다. 전문가의 경력이 들어가는 자리는 intent.md(이번 기능이 왜 필요한가)가 아니라 도메인 스킬(모든 기능이 따라야 할 규칙)입니다. intent.md는 그 스킬을 어떤 페인 포인트에 적용할지 고르는 가벼운 문서로 남습니다. 발의자는 누구나 될 수 있지만, 스킬 저자는 전문가만 될 수 있습니다.
7. 오늘 쓸 수 있는 것 — intent.md 검토 체크리스트
AI가 intent.md를 써 주면 발의자가 돌아가서 고쳐야 합니다 [03:04]. 그때 볼 것은 세 가지입니다.
| 항목 | 묻는 말 | 플레이북 대응 항목 |
|---|---|---|
| 대상 | 누가 쓰는 서비스인지 명확한가 | “who is affected by the idea” |
| 페인 포인트 | 그 사람의 어떤 아픔을 푸는가 | “what they cannot do today” / “what better looks like” |
| 재시작 가능성 | 개발이 어긋났을 때 이 문서만 보고 원점으로 돌아올 수 있는가 | (플레이북 없음 — 이 글의 제안) |
“제대로 된 결과가 나오는 시스템인가”는 여기서 보지 않습니다. 그것은 spec과 평가의 일이고, 그 기준은 도메인 스킬에 있어야 합니다.
8. 열린 문제
이 글이 답하지 못한 것을 적어 둡니다.
- 전문가의 판단 기준을 “사례 20개 + 기대 답” 형태로 실제로 적어 낼 수 있는가 — 가능성만 확인했고 실물은 없습니다.
- 규칙으로 담지 못하는 예외의 비율과 그 처리 경로(전문가에게 넘기는 길).
- 교차 모델 평가(Claude가 만들고 Codex가 평가)의 실효 — 실측이 없습니다.
출처
- Anthropic Applied AI 팀, “The AI-Native SDLC playbook”, 2026-08-21, https://claude.com/blog/the-ai-native-sdlc-playbook. 영상은 이 문서를 Claude Code 개발자가 냈다고 소개하지만 [00:00], 본문 저자는 Louis Claxton이고 해당 이름은 등장하지 않습니다.
- Rob Shocks, “Claude Code’s New INTENT.MD, What is It?”, https://www.youtube.com/watch?v=LoMOPj-lO8U — 본문의 [mm:ss] 인용.
확인 범위 위 1번 플레이북 원문은 직접 대조했습니다. 영상 발언의 타임스탬프 [mm:ss] 는 영상을 보며 적은 것이고 따로 재확인하지는 않았습니다 — 글 아래 원본 영상 주소로 직접 확인하실 수 있습니다.