Written by
seonest
At
Thu May 21 2026
AIDLC — AI가 짜고, 사람이 승인한다
AWS가 공개한 AIDLC는 'Using AI-DLC,' 한 줄로 코딩 에이전트의 사이클을 다시 짜는 방법론입니다. AI가 짜고 사람이 승인하는 이 분업을 커뮤니티는 어떻게 받아들이고 있는지 살펴봅니다.
같은 AIDLC를 도입한 두 팀이 한 주 만에 다른 결론에 이르렀습니다. 한 팀은 하룻밤 사이에 새 기능 6개를 만들어 냈고, 다른 팀은 일주일을 돌려 보고도 "그래서 우리가 정말 중요한 일을 더 많이 하고 있나?"라는 질문 앞에서 멈췄습니다.
두 팀이 본 사실은 같습니다. 다른 것은 그 사실이 무엇을 뜻하느냐였습니다.
Using AI-DLC, 한 줄로 무엇이 바뀌는가
AIDLC(AI-Driven Development Life Cycle)는 AWS가 2025년 말에 공개한 개발 방법론이자, 그 방법론을 코딩 에이전트에서 그대로 돌릴 수 있게 만든 규칙 모음입니다. 배포 zip을 풀어 .cursor/rules/나 CLAUDE.md 같은 자리에 두기만 하면, 사용자가 Using AI-DLC, ...로 운을 떼는 순간 에이전트가 정해진 사이클을 따라 움직입니다.
사이클은 세 단계로 끊어져 있습니다.
- Inception — 무엇을 왜 만들지를 묻는 단계입니다. 요구사항 분석, 사용자 스토리, 워크플로 계획, 작업 단위(유닛, Units of Work) 분할까지 이 단계에서 이뤄집니다.
- Construction — 어떻게 만들지를 풀어 가는 단계입니다. 유닛마다 기능 설계 → 비기능 요구사항 → 코드 계획 → 코드 생성 → 빌드·테스트가 반복됩니다.
- Operations — 배포·모니터링·유지보수가 들어갈 자리입니다. 다만 현재 리포지토리에는 이 자리가 "future operational phases"라는 한 줄짜리 빈칸으로만 남아 있습니다.
리듬도 새로 잡혀 있습니다. 2주짜리 스프린트는 몇 시간에서 며칠짜리 Bolt로 줄었고, 비동기 티켓 핸드오프 자리에는 팀이 한자리에 모여 에이전트의 제안을 함께 검토하는 Mob Elaboration·Mob Construction이 들어섰습니다. 이름만 새로워 보이지만, 사이사이에는 강제 조항이 단단히 박혀 있습니다 — 각 단계마다 Wait for Explicit Approval 게이트가 있고, 모든 사용자 입력은 audit.md에 그대로 적힙니다.
이 한 줄이 바꾸는 것은 도구가 아니라 권한 구조입니다.
베팅은 "AI가 짜고 사람이 승인한다"는 분업입니다
리포지토리에는 다섯 강령이 적혀 있습니다. 중복 없음, 방법론 우선, 재현 가능, 도구 비의존, 그리고 사람이 루프 안에 있을 것. 마지막 줄은 본문에서 한 문장으로 요약돼 있습니다 — "The agent proposes, the human approves."
이 분업이 성립하려면 두 가지 가정이 모두 참이어야 합니다.
첫째, 코드 생산이 가장 큰 비용이었어야 합니다. 에이전트가 코드를 짜는 동안 사람이 절약하는 시간이 의미가 있으려면, 그 자리가 원래 가장 무거운 짐이었어야 합니다.
둘째, 의도 표현이 코드 생산보다 싸야 합니다. 명세를 적고 검토하고 승인하는 비용이 직접 짜는 비용보다 크다면, 게이트는 절약이 아니라 부담이 됩니다.
다섯 강령 중 "Human in the loop" 하나가 이 두 가정의 무게를 모두 떠안고 있습니다. 나머지 네 강령은 이 한 줄이 참이어야 살아납니다 — 중복이 없는 산출물도, 재현 가능한 흐름도, 도구에 의존하지 않는 규칙도, 결국 사람이 게이트를 빠르고 정확히 통과시킬 수 있어야 의미가 생깁니다.
커뮤니티는 이 분업이 어디서 무너지는지 봅니다
지지 측과 회의 측이 보는 사실은 거의 같습니다. 다만 그 사실을 어떤 비용 구조에 비추어 읽느냐가 다릅니다.
지지 측은 brownfield 현대화와 신속한 실행을 가리킵니다. AWS Hero인 Bhuvana Subramani는 AI-DLC 핸드북에서 "AI-DLC는 그린필드만을 위한 것이 아니다"라고 적었습니다. 리포지토리에 리버스 엔지니어링 규칙이 따로 들어 있고, 기존 코드는 새 파일로 복제하지 않고 제자리에서 수정하도록 강제됩니다. AWS Summit Seoul 2026은 AI-DLC 활용도를 심사 항목에 넣은 7시간짜리 개발 서바이벌을 열기도 했습니다.
회의 측은 정확히 같은 자리에서 다른 신호를 읽습니다. Wakamole Guy는 AI-DLC Solves the Wrong Bottleneck에서 자기 조직이 AI 도구를 전사에 깐 뒤 엔지니어 한 명이 일주일에 서비스 하나를 끝까지 출시할 수 있게 됐다고 적습니다. 그러고는 묻습니다 — "그런데 왜 우리는 정말 중요한 일을 더 많이 만들지 못하고 있는가?" 그가 보기에 병목은 코드 생산이 아니라 사용자 이해와 이해관계자 정렬이었고, AI가 그 자리를 좁힌 적은 없습니다.
스타트업 50곳 이상의 엔지니어링 리더를 조사한 Kerno의 보고는 이 회의적 시선을 한 줄로 요약합니다 — "코드 리뷰가 지배적인 병목이 됐다. 풀 리퀘스트는 더 커졌고, 디프는 읽기 더 어려워졌으며, 개발자들은 에이전트가 짠 코드보다 사람이 짠 코드를 더 신뢰한다." Reddit의 한 30년 차 엔지니어는 같은 사실을 두 문장으로 줄입니다 — "Humans are information makers, AI is information synthesizers. This is a crucial difference."
지지 측은 "AI가 빠르게 짠다"는 사실에서 사이클의 효율을 봤고, 회의 측은 같은 사실에서 옮겨 간 부담을 봤습니다.
게이트를 옮기면 병목도 함께 옮겨갑니다
병목이 한 자리에서 사라지면 다른 자리에 쌓입니다.
고속도로 톨게이트에서 비슷한 일이 일어납니다. 톨게이트는 모든 차량이 통과해야 하는 점검 지점입니다. 어느 지점의 톨게이트를 자동화로 무인 통과시키면, 그 지점의 정체는 사라집니다. 그러나 도로 위 차량 수는 줄지 않습니다 — 정체는 다음 점검 지점, 출구 램프, 합류 지점에서 다시 자랍니다. 시스템 전체의 처리량은 가장 좁은 길에서 결정되기 때문입니다.
비유의 한계가 한 군데 있습니다. 톨게이트는 단방향 흐름인데, AIDLC의 게이트는 반려가 가능합니다. 사람이 승인을 거부하면 에이전트가 다시 제안을 만들고, 그 왕복이 또 다른 비용으로 쌓입니다. 톨게이트가 닫혔을 때의 정체보다 더 깊은 정체가 가능하다는 뜻입니다.
AIDLC는 코드 생산이라는 톨게이트를 무인화합니다. 활성화 문구 한 줄로 에이전트가 유닛 여섯 개를 하룻밤에 처리하는 그림이 나옵니다. 그러나 그 처리량은 다음 게이트 — Inception의 요구사항 검토, Construction의 코드 계획 승인, 빌드 후 산출물 검증 — 에서 다시 사람의 속도에 묶입니다. 풀 리퀘스트가 더 커졌다는 Kerno의 관찰도, 코드 리뷰가 새 병목이 됐다는 진단도, 모두 바로 이 지점에서 나옵니다.
리포지토리가 Operations 단계를 빈칸으로 두고 있다는 사실은 우연이 아닙니다. Operations는 게이트로 끊기 가장 어려운 자리 — 운영 중인 시스템의 상태가 게이트마다 사람의 검토를 기다려 줄 만큼 한가하지 않은 자리 — 입니다. 게이트 위주 사이클을 어디까지 끌고 갈 수 있는지가, 이 빈칸이 묻는 진짜 질문입니다.
도입 전에 점검할 세 자리
AIDLC를 받아들이는 일은 새 도구를 까는 일이 아니라 새 병목을 받아들이는 일입니다. 받아들이기 전에 세 자리를 점검해 봐야 합니다.
- 우리 팀의 실제 병목이 무엇입니까. 코드 생산이 가장 무거운 짐이었다면 AIDLC는 그 무게를 옮겨 줍니다. 검토·검증·이해가 무거웠다면 게이트가 늘어나면서 같은 무게가 더 큰 단위로 쌓입니다. 지난 분기의 PR 리드 타임을 어디서 잡아먹었는지 한 번 들여다보면 답이 거의 보입니다.
- 활성화 한 줄로 게이트를 둘 만큼 audit이 작동하는 환경입니까.
audit.md에 모든 입력이 그대로 적히고, 산출물이 디렉터리에 쌓입니다. 그 산출물이 코드 리뷰처럼 사람의 손에서 검토되고, 반려가 다음 사이클로 전달되는 흐름이 이미 있다면 AIDLC는 그 위에 얹힙니다. 그렇지 않다면 게이트는 이름뿐인 절차가 됩니다. - Operations가 비어 있는 사이클을 받아들일 수 있습니까. 배포 이후의 자리를 우리가 기존 인프라와 절차로 채울 수 있어야 합니다. 그렇지 않으면 사이클이 빌드 직후에서 끊기고, 그 단절을 사람이 매번 메워야 합니다.
세 자리 중 두 자리 이상에서 막힌다면, AIDLC를 통째로 들여놓기 전에 그 자리를 먼저 정리해야 합니다.
게이트의 위치가 곧 병목의 위치입니다. AIDLC가 가장 크게 옮긴 것은 도구도 산출물도 아니라, 작업이 통과해야 하는 지점입니다. 그 지점이 우리 팀의 가장 좁은 길과 같은 곳에 있다면 사이클은 빨라지고, 다른 곳에 있다면 같은 양의 부담이 다른 이름으로 다시 자랍니다. 받아들일지 말지의 질문은 결국 — 우리가 가장 자주 멈추는 자리가 어디였는가에 답하는 일과 같습니다.