[한영자막] Claude Code 팀이 새로 공개한 INTENT.MD의 정체와 AI-Native 개발 방식

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

영상이 소개하는 INTENT.MD는 요구의 맥락을 기록해 명세·구현 계획으로 연결하는 출발점이며, AI-Native 개발의 핵심은 에이전트를 개발 전 과정에 배치하고 중요한 검토에는 사람을 참여시키는 것이다.

📌 핵심 요점

1. 개발 병목이 구현에서 프로세스로 이동한다. 영상은 에이전트가 코드 작성 시간을 줄인 만큼 기획·설계·테스트·배포·유지보수의 대기와 인계도 개선해야 한다고 설명한다.
2. INTENT.MD는 질문과 검토로 만든 요구의 기록이다. 에이전트가 반복 질문으로 도메인 지식과 맥락을 수집하고, 최초 제안자가 작성 결과를 확인·수정한다.
3. INTENT.MD → spec.md → plan.md가 산출물 연결 구조를 이룬다. 특히 구현 계획에는 변경 파일, 작업 순서, 위험, 제약, 성공 기준과 검증 방법을 담아 새 에이전트도 이전 대화 없이 작업할 수 있게 한다.
4. 자율 실행에는 권한과 검증 체계가 함께 필요하다. 워크트리·하위 에이전트로 작업을 나누고, 훅·린트·테스트·평가·배포 승인으로 실행 범위와 품질을 관리한다.
5. 유지보수는 다음 개발 주기의 입력이 된다. 로그·티켓·메시지·일정이 에이전트를 호출해 문제를 진단하고 새 의도를 기록하는 흐름을 제시하되, 팀 상황에 맞는 적용과 중요한 단계의 사람 검토를 강조한다.

🧩 배경과 문제 정의

전통적인 소프트웨어 개발 생명주기는 기획·설계·구현·테스트·배포·유지보수를 반복한다. 영상은 과거 가장 오래 걸리고 비용이 컸던 구현 단계가 에이전트로 짧아지면서, 나머지 단계의 절차와 대기가 새로운 개선 대상이 됐다고 설명한다.

이 문제에 대한 제안은 에이전트 활용을 코드 작성에서 전 과정으로 넓히는 것이다. 요구를 제시한 사람이 에이전트와 대화해 의도를 기록하고, 이를 명세와 구현 계획으로 이어 붙인다. 단계가 바뀌거나 담당 에이전트가 달라져도 문서를 통해 맥락을 전달하고, 조직 정책과 사람의 검토를 필요한 지점에 배치한다.

영상은 소개 문서의 설명에 발표자 자신의 발견 인터뷰·백로그 분류·테스트 운영 경험을 섞어 전달한다. 따라서 하나의 고정된 표준 절차보다는 팀별로 조정할 수 있는 개발 운영 구상으로 읽는 것이 적절하다.

🕒 시간순 섹션별 상세정리

1. 구현 속도 다음의 병목은 개발 절차

• AI-Native SDLC 플레이북을 소개하며 기획, 설계, 구현, 테스트, 배포, 유지보수로 이어지는 기존 개발 주기를 보여준다. [00:34]
• 에이전트가 구현 시간을 줄였으므로 다른 단계도 개선해야 한다는 문제를 제기한다. 핵심 주장은 코드보다 프로세스가 병목이라는 것이다. [01:10]

2. 반복 질문으로 의도를 문서화

• 에이전트가 기능·버그·제품에 관해 반복 질문하도록 해 제안자의 경험과 도메인 맥락을 충분히 수집한다. [01:47]
• 수집한 문제와 의도를 사람이 읽고 기계가 실행에 활용할 수 있는 문서로 기록한다. 의도 문서에서 명세로 이어지는 산출물 연결 구조도 보여준다. [02:32]
• 다크 모드 기능을 예로 들어 대화 결과를 intent 폴더의 의도 문서로 저장하고, 팀과 에이전트가 공유할 작성 방식을 안정적으로 유지하라고 권한다. [03:14]

3. 제안자 검토와 백로그 정리

• 최초 제안자가 에이전트의 기록을 확인하고 수정한다. 제안자는 고객, 제품 관리자, 개발자 등 누구나 될 수 있다. [03:44]
• 모인 의도는 제품 책임자가 백로그로 검토하며, 발표자는 에이전트가 작업 유형·크기·우선순위 등의 태그로 분류하는 사례를 보여준다. [04:35]

4. 승인된 의도를 명세로 전환

• 의도가 커밋되거나 승인되면 훅 또는 절차를 통해 요구사항·설계 명세를 생성하는 흐름을 보여준다. 제공되는 것은 예시 프롬프트이며 팀에 맞는 스킬로 구성할 수 있다고 보여준다. [05:09]
• 기본 계획 모드나 맞춤 스킬을 활용하되, 조직의 스타일 가이드·정책·AGENTS.md 등에 담긴 기준이 명세와 다른 산출물에도 적용되도록 한다. [05:56]

5. 독립적으로 실행할 수 있는 계획과 이력

• 엔지니어가 의도와 명세를 바탕으로 plan.md를 만들고, 변경이 무엇을 깨뜨릴 수 있는지 검토한다. 새 에이전트도 이전 대화 없이 문서로 작업을 시작할 수 있어야 한다. [07:01]
• 계획에는 변경 파일, 작업 순서, 위험, 제약과 성공 기준을 담고 린트·테스트 같은 검증 방법을 명시한다. [07:28]
• 의도·명세·계획의 버전과 수정 주체를 기록해 프로젝트 지표와 AI 활용 효과를 추적할 기반을 마련한다. [07:52]

6. 권한·훅·워크트리로 구현 자동화

• 자동 실행의 범위는 조직에 따라 조정한다. 발표자는 도구, 외부 소스, 패키지 등에 대한 권한 정책을 정해 에이전트의 영향 범위를 제한할 것을 제안한다. [08:35]
• 워크트리는 여러 에이전트의 동시 작업을 지원하고, 훅은 구현 후 계획 갱신이나 특정 폴더 접근·미승인 패키지 업그레이드 차단 등에 활용할 수 있다. [09:08]
• 린트 같은 코드 기반 검사로 조건 충족 여부를 확인하고, 독립적으로 수행할 작업을 하위 에이전트에 분배한다. [09:42]

7. 사람 리뷰 이전의 테스트와 지속 평가

• 테스트 담당자를 기다리는 시간을 줄이기 위해 에이전트가 먼저 테스트 작성·실행, 린트, 빌드를 수행하고 브라우저 검사와 화면 기록도 활용하는 흐름을 보여준다. 이 부분에는 발표자의 자체 워크플로가 포함된다. [10:54]
• 스킬 변경이나 모델 업그레이드에는 평가를 적용한다. 해결했던 이슈 약 20개와 기대 결과를 모아 개발 흐름의 성능이 후퇴하는지 확인하는 예를 든다. [11:22]

8. PR 리뷰와 배포 통제

• 사람 리뷰를 거친 변경은 팀 절차에 따라 병합하거나 PR로 제안하고, CI 또는 PR 생성 시점에 에이전트가 정책·보안 기준을 비동기로 검토하는 구조를 보여준다. [11:59]
• 별도 에이전트가 리뷰 의견을 검토할 수 있으며, 특정 권한·승인자·출시일 조건을 충족해야 배포하도록 훅을 둘 수 있다. [12:29]
• 보안 검사와 CI 확인에는 린트·조건 검사 같은 코드 기반 검증과 에이전트 리뷰를 함께 활용한다. [12:49]

9. 유지보수가 새 의도로 이어지는 개발 주기

• 유지보수 자동화를 지향적인 단계로 보여준다. 이벤트·티켓·Slack 메시지·일정이 에이전트를 호출하고, 로그나 요청을 바탕으로 진단과 새 의도 문서 생성을 수행하는 흐름이다. [13:48]
• 페이지 이상이나 API 관련 지표 변화 등을 계기로 사람이 확인하기 전에 문제를 진단하고 대응 제안을 준비하는 사례를 보여준다. [14:07]
• 결말에서는 전 과정의 사람 투입 시간을 줄이면서 중요한 리뷰에는 사람을 참여시키라고 강조한다. 팀마다 적합한 방식이 다르므로 기존 체계를 모두 버리지 말고 상황에 맞게 적용하라는 제안으로 마무리한다. [15:05]

🧾 결론

• INTENT.MD의 가치는 파일 이름보다 요구의 배경과 목적을 사람이 읽고 에이전트가 실행에 활용할 수 있는 형태로 남기는 데 있다.
• 단계별 산출물은 대화 맥락이 없는 다른 에이전트나 엔지니어에게 작업을 넘기는 기준점이다. 작성 후 검토와 변경 이력 관리가 함께 필요하다.
• 자동화의 범위는 작업의 중요도와 조직 정책에 따라 달라진다. 영상도 기존 개발 체계를 전부 버리고 단일 방식을 채택하라고 권하지 않는다.

📈 투자·시사 포인트

• 개발 도구의 가치를 평가할 때 코드 생성 속도뿐 아니라 요구 수집, 테스트, 리뷰, 유지보수까지 연결하는 능력을 살펴볼 수 있다.
• 조직의 도입 성과는 도구 선택과 함께 문서 표준화, 권한 정책, 검증 체계의 준비 수준에 영향을 받을 수 있다. 이는 영상의 운영 제안에서 도출되는 시사점이다.
• AI 효과를 판단하려면 산출물 변경 이력과 프로젝트 지표를 추적해야 한다. 영상은 DORA 지표를 언급하지만 실제 개선 수치나 비교 실험 결과는 제시하지 않는다.
• 특정 기업의 매출·수익성·가치평가 자료는 없다. 이 영상은 개발 운영 방식의 변화를 검토하는 자료로 활용하는 것이 적절하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 영상이 소개하는 플레이북의 원문 링크·버전·공식 파일 규격은 제공되지 않는다. INTENT.MD의 구체적인 필수 항목과 공식 권고 범위는 이 자료만으로 확정할 수 없다.
• 전사에는 제품·인물·파일 이름의 표기 흔들림이 있다. 제목의 INTENT.MD와 본문의 intent.mmd 등이 혼재하므로 실제 도입 시 정확한 명칭과 경로를 확인해야 한다.
• 발표자는 테스트 단계에서 자신의 교육용 워크플로가 소개 문서와 조금 다를 수 있다고 밝힌다. 개인 사례와 문서의 권고를 모두 동일한 공식 절차로 취급해서는 안 된다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 작은 기능이나 버그 하나를 골라 에이전트의 반복 질문으로 요구·배경·제약을 수집하고 INTENT.MD 초안을 만든 뒤 최초 제안자가 검토한다.
• 의도·명세·계획의 저장 위치와 작성 방식을 팀 기준으로 정하고, 변경 이력과 검토자를 기록한다.
• plan.md에 변경 파일, 작업 순서, 위험, 제약, 성공 기준과 검증 방법을 넣고 이전 대화 없이 구현 가능한지 확인한다.
• 자동 실행 전에 접근 가능한 도구·외부 소스·패키지·폴더와 승인 조건을 정하고 필요한 훅을 구성한다.

❓ 열린 질문

• 우리 팀에서 구현 외에 가장 긴 대기와 인계가 발생하는 단계는 어디이며, 어떤 지표로 개선을 확인할 것인가?
• 최초 제안자, 제품 책임자, 엔지니어는 각각 어떤 산출물을 검토하고 승인해야 하는가?
• 에이전트가 스스로 처리할 수 있는 낮은 중요도의 작업과 사람 승인이 필요한 작업을 어떤 기준으로 구분할 것인가?