왜부터 적는다 — 의도 파이프라인(intent → spec → plan)
하네스 엔지니어링 시리즈의 네 번째 글. 앞의 글들이 무엇을 지을 것인가(여섯 층)와 어떻게 굴릴 것인가(규칙의 밀도)를 다뤘다면, 이 글은 그 앞에 놓여야 할 한 칸 — 왜 — 를 다룬다. 2026-09-08 후니님·지미 대화에서 나왔다.
1. 문제 — 코드는 몇 시간이면 나온다. 그런데 “왜”는 어디 있나
에이전트가 코드를 짜는 속도는 이제 문제가 아니다. 작업 하나가 몇 시간이면 끝나고, 며칠짜리도 하루면 된다. 그러자 다른 것이 병목이 됐다. 앤트로픽이 2026년 8월 낸 「AI-Native SDLC 플레이북」의 첫 문장이 그것이다 — 코드는 더 이상 병목이 아니다. 당신의 개발 과정이 병목이다.
우리 자리에서 보면 병목의 정체는 더 좁다. 왜 만드는지가 적혀 있지 않다.
지금 우리 하네스에는 끝난 뒤의 기록만 있다. 인수인계(HANDOVER)는 무엇을 했나를 남기고, 레슨은 무엇이 틀렸나를 남긴다. 둘 다 사후다. 착수 시점에 무엇을 하려 했나를 남기는 자리가 없다. 그래서 회고할 때 의도를 그 자리에서 재구성하게 되고, 재구성된 의도는 결과에 맞춰 굽는다. 잘 됐으면 “원래 이걸 노렸다”가 되고, 안 됐으면 “그건 부차적이었다”가 된다. 사후 합리화는 게을러서 생기는 게 아니라 기록이 없어서 생긴다.
이 상태에서 에이전트에 속도를 붙이면 한 가지가 늘어난다. 개발을 위한 개발. 무엇을·어떻게는 완벽한데 왜가 없는 일. 잘 굴러가는 잘못된 일.
2. 어텐션이 가져간 것, 남긴 것
「Attention Is All You Need」(2017)가 한 일을 한 줄로 줄이면 이렇다 — “무엇에 주목할지”를 기계가 스스로 정하게 만들었다. (어텐션 노드) 그 뒤로 아홉 해 동안 무엇을과 어떻게는 계속 기계 쪽으로 넘어갔다. 문장을 고르는 일, 코드를 짜는 일, 검색하고 요약하는 일.
넘어가지 않은 것이 하나 남았다. 왜. 마이크로소프트 연구소의 라히리가 2026년 3월 「의도 형식화」 논문에서 못박은 대로, 명세가 맞는지 판정할 오라클은 사용자밖에 없다. 1960년에 노버트 위너가 “기계에 넣은 목적이 우리가 진짜 바라는 목적인지 확실히 해두라”고 쓴 것과 같은 자리다. 66년 동안 자리는 안 움직였고, 그 자리를 비워두는 비용만 커졌다.
3. 골든 서클 — 세 겹, 그리고 방향
사이먼 시넥의 골든 서클은 세 겹이다. 안쪽부터 왜(Why) → 어떻게(How) → 무엇을(What). 요점은 세 겹이 있다는 것보다 방향에 있다. 보통은 밖에서 안으로 간다 — 무엇을 만들고, 어떻게를 설명하고, 왜는 나중에 붙인다. 드문 쪽은 안에서 밖으로 간다.
우리 하네스를 그 원에 얹어 보면 어느 겹이 두꺼운지 바로 보인다.
| 골든 서클 | 우리 실물 | 두께 |
|---|---|---|
| What | 산출물·코드·HANDOVER의 완료 기록 | 두껍다 |
| How | 레드라인 12개, 레슨 66개, 메모리 265개, 스킬 25종, 훅 | 아주 두껍다 |
| Why | — | 얇다 |
바깥 두 겹만 살이 쪘다. 그리고 이게 규칙이 늘기만 하는 이유이기도 하다. 규칙은 어떻게(How)다. 왜가 같이 안 적히면 규칙은 훈시가 되고, 사고가 날 때마다 한 줄씩 는다. 규칙의 밀도에서 “이 체계의 핵심 규칙 중 하나가 규칙을 지워라”라고 했는데, 지우려면 그 규칙이 어떤 의도를 지키려고 생겼는지를 알아야 지운다. 왜가 떨어져 나간 규칙은 못 지운다. 무서워서 못 지운다.
4. 앤트로픽 intent.md — 왜를 파일로 만든다
앤트로픽 플레이북이 제안한 것은 단순하다. 일을 시작하기 전에, 아이디어를 낸 사람이 자기 말로 다섯 가지를 적어 git에 커밋하라.
# Intent: (한 줄 제목)
Author: 누가. Status: draft.
## Problem — 무엇이 문제인가
## Proposed outcome — 어떻게 되면 좋겠는가
## Affected users and systems — 누가·무엇이 영향받는가
## Constraints — 지켜야 할 것
## Open questions — 아직 모르는 것이걸 intent.md라 부른다. 클로드와 브레인스토밍해서 초안을 뽑고, 낸 사람이 틀린 데를 고치고, 커밋한다. 커밋되는 순간 작성자와 시각이 박힌다. 이게 핵심이다. 승인 절차가 아니라 시간 도장이다. 나중에 “원래 의도가 뭐였나”를 물을 때 재구성이 아니라 기록을 꺼낼 수 있게 된다.
앤트로픽 템플릿에 한 가지가 빠져 있다. 문제(Problem)는 있는데 **“우리는 왜 이 일을 하는 조직인가”**가 없다. 골든 서클의 왜는 개별 작업의 이유(reason)가 아니라 변하지 않는 목적(purpose)이다. 규제 산업 SI라면 없어도 굴러가지만, 우리는 이게 빠지면 뒤에서 말할 “타당했나”의 판정 기준이 사라진다. 그래서 우리 판에는 칸 하나를 앞에 둔다.
## Why — 상위 목적과의 연결
이 일이 잇닿는 상수 why. 어느 정체성 노드·헌법 조항에 걸리는가.
여기에 한 줄도 못 적으면 그 자체가 신호다.못 적었다고 막지 않는다. 못 적었다는 사실만 남긴다. 게이트가 아니라 신호등이다.
5. 파이프라인 — 왜에서 시작해 왜로 돌아온다
앤트로픽이 그린 사슬은 이렇다. 각 단계가 끝날 때 파일 하나를 커밋하고, 다음 단계가 그 파일을 읽고 시작한다.
intent.md → spec.md → plan.md → 코드+테스트 → PR(리뷰기록) → 배포 → 사건기록 → 다시 intent.md
왜 무엇을 어떻게 실물 검증 운영 배움 왜
골든 서클을 파일 순서로 구현한 것에 가깝다. 안에서 밖으로, 그리고 바깥에서 다시 안으로. 사슬 전체가 감사추적이 된다 — 누가 무엇을 요청했고, 에이전트가 뭘 만들었고, 누가 승인했는가.
우리 실물에 대응시키면 이미 있는 것과 없는 것이 갈린다.
| 단계 | 앤트로픽 | 우리 실물 | 있나 |
|---|---|---|---|
| 왜 | intent.md | — | 없다 |
| 무엇을 | spec.md | PDCA 「기준」 에이전트의 완료 기준 | 있다 |
| 어떻게 | plan.md | /plan, planning-with-files | 있다 |
| 실물 | 코드+테스트 | 산출물 | 있다 |
| 검증 | PR 리뷰 | PDCA 「시현」(코드)·「심아」(문서) | 있다 |
| 배움 | 사건기록 | 레슨, DEBUG_NOTES | 있다 |
| 환류 | 다시 intent | 「환이」 → 메모리·스킬 | 반쪽 |
첫 칸 하나가 비어 있고, 마지막 칸이 반쪽이다. 환류가 반쪽인 이유가 첫 칸이 비어서다 — 의도가 기록돼 있지 않으면 환류가 돌아갈 자리가 없다.
6. 세 층에 심는다 — 하네스·에이전틱·루프
우리 작업 체계는 세 층이다. 하네스는 에이전트 하나의 둘레(지시문·기억·규칙·도구·검증). 에이전틱은 여러 에이전트 사이의 분업(위임·팀·워크플로우). 루프는 시간 축의 반복(타이머·재귀·감시). 왜는 세 층 모두에 들어가야 하고, 들어가는 모양이 층마다 다르다.
하네스 — 규칙에 왜를 붙인다. 레드라인·레슨·메모리 항목에 “왜 생겼나”가 붙어 있어야 지울 수 있다. 레슨은 사고 기록이라 대개 왜가 있다. 레드라인은 일부가 금지 행위만 남았다. 소급해서 붙이는 일이 이 층의 숙제다.
에이전틱 — 위임에 왜를 싣는다. 지금 위임 프롬프트에는 어떻게(레드라인 동봉)는 실리는데 왜는 안 실린다. 받은 쪽은 시킨 것만 완벽하게 해내고 엉뚱한 데 도착한다. 왜를 아는 쪽은 명시 안 된 경계에서 스스로 멈추고, 모르는 쪽은 경계를 모른 채 완주한다. 서브에이전트도 사람도 같다. 왜를 넘기면 지시를 다 적을 필요가 줄어든다. 위임 대역폭이 준다.
루프 — 종료조건을 바꾼다. 지금 루프의 종료조건은 “할 일을 다 했나”다. 이걸 “의도가 충족됐나”로 바꾼다. 단, 여기 함정이 하나 있다. 루프가 자기 의도 충족을 자기가 판정하면 자기채점이다. “됐을 것 같다”를 구조로 만든 꼴이 된다. 그래서 우리 루프는 무인 재귀가 아니라 반자동이다 — 발견·분류까지 자동, 판정은 사람. 의도 충족의 판정자는 의도를 낸 사람이다.
7. 회고 — 세 질문, 그리고 세 번째의 판정 기준
의도가 기록돼 있으면 회고에서 세 질문을 던질 수 있다.
- 의도가 무엇이었나 — 기록이 없으면 못 하는 질문. 있으면 꺼내기만 하면 된다.
- 의도대로 되었나 — 누구나 한다. 결과가 눈앞에 있으니까.
- 그 의도는 타당했나 — 거의 아무도 안 한다. 빠지면 잘 굴러가는 잘못된 일이 된다.
세 번째를 안 하는 진짜 이유는 판정 기준이 없어서다. “타당한가”를 무엇에 비추어 판정하나. 골든 서클을 끌어오면 기준이 생긴다. 왜가 두 층이기 때문이다.
- 상수 why — 이 조직이 왜 존재하는가. 우리는 이미 문서로 있다. 품아이·연대지능 같은 정체성 노드, 그리고 지미 메모리의 연대지능 헌법·품아이 헌법.
- 작업 why — 이 일을 왜 지금 하는가.
intent.md가 담는 자리.
그러면 세 번째 질문이 이렇게 구체화된다. “그 의도는 타당했나” = “작업 why가 상수 why와 정합했나.” 판정 대상이 생기고, 대조할 문서도 이미 있다. 개발을 위한 개발이란 결국 작업 why가 상수 why와 끊긴 채 어떻게·무엇을만 도는 상태고, 이 대조가 그걸 잡아낸다.
8. 함정 셋
형식이 되면 죽는다. 모든 작업에 의도문을 요구하면 두 주 안에 형식이 된다. 발동 조건이 필요하다. 우리는 위임이 발생하는 일 하나로 시작한다 — 그때는 어차피 프롬프트를 쓰니 추가 비용이 거의 없고, 왜가 안 넘어가서 나는 사고가 실제로 가장 잦다.
게이트가 되면 사람을 막는다. 이건 기록이지 관문이 아니다. 승인제로 만들지 않는다. 남의 직무를 승인제로 막는 사고를 우리는 세 번 냈다. 앤트로픽 템플릿의 “제품 오너 승인”을 그대로 들여오면 같은 사고가 난다. 우리 판에서는 못 적은 사실만 남기고 막지 않는다.
근거를 과장하지 않는다. 시넥이 골든 서클의 근거로 든 변연계·신피질 설명은 신경과학적으로 거칠다는 비판을 꾸준히 받는다. 프레임으로는 쓸모 있다. “뇌과학이 증명한다”고는 쓰지 않는다. 도구의 쓸모와 근거의 강도는 별개다.
9. 첫 실물
이 글이 나온 대화에서 첫 intent.md를 썼다. 대상은 이 일 자체 — 의도 기록을 하네스에 심기. _shared_ai/intent/20260908_의도기록을_하네스에_심기.md. 다섯 절 그대로 갔고, 열린 질문 여섯 개 중 하나(“타당했나는 누가 언제 하나”)가 이 글을 쓰면서 닫혔다 — 정리해 때, 상수 why 문서와 대조해서.
나머지 다섯 개는 아직 열려 있다. 발동 조건은 하나로 갈지 넷 다 갈지, 저장 자리는 별도 파일인지 인수인계 머리 한 줄인지, 루프 종료조건의 판정자는 정확히 누구인지, 레드라인 열두 개에 왜를 소급할지, 이걸 스킬로 만들지 기존 스킬에 얹을지. 답이 나오는 대로 그 파일에 적힌다. 그게 이 방식의 요점이다 — 의도가 어떻게 변해 갔는지가 파일에 남는다.
참고
- 앤트로픽, The AI-Native SDLC playbook (2026-08-21) · Capture as intent.md (Claude Academy)
- Shuvendu K. Lahiri, Intent Formalization: A Grand Challenge for Reliable Coding in the Age of AI Agents (arXiv:2603.17150, 2026-03)
- Norbert Wiener, “Some Moral and Technical Consequences of Automation”, Science 131(3410), 1960
- Vaswani et al., Attention Is All You Need (2017) — 어텐션 노드
- 시넥의 골든 서클 근거에 대한 비판은 별도 조사 없이 통설로 적었다. 대외 문서에 옮길 때 확인할 것.
- 같은 시리즈: 왜 같은 모델이 다른 성능을 내는가 → 하네스 엔지니어링 → 규칙의 밀도 → 이 글