AIDLC — 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로 짧아집니다. 티켓을 쌓아 두고 비동기로 주고받는 대신, 팀원들이 모여 에이전트의 제안을 함께 검토합니다. AIDLC는 이 모임을 Mob Elaboration·Mob Construction이라고 부릅니다. 이름만 바뀐 것 같지만, 곳곳에 강제 조항이 박혀 있습니다. 단계마다 Wait for Explicit Approval 게이트가 사람의 승인을 기다리고, 사용자가 입력한 내용은 전부 audit.md에 그대로 남습니다.

이 한 줄이 바꾸는 것은 도구가 아니라 권한 구조입니다.

AIDLC는 "AI가 만들고 사람이 확인한다"는 분업에 베팅합니다

리포지토리에는 다섯 강령이 적혀 있습니다. 중복 없음, 방법론 우선, 재현 가능, 도구 비의존, 그리고 사람이 루프 안에 있을 것. 마지막 줄은 본문에 한 문장으로 요약돼 있습니다. "The agent proposes, the human approves."

이 분업이 성립하려면 두 가지 가정이 모두 참이어야 합니다.

첫째, 코드 생산이 가장 큰 비용이었어야 합니다. 에이전트가 코드를 짜는 동안 사람이 아끼는 시간이 의미가 있으려면, 원래 코드 작성이 가장 무거운 짐이었어야 합니다.

둘째, 의도 표현이 코드 생산보다 싸야 합니다. 명세를 적고 검토하고 승인하는 비용이 직접 짜는 비용보다 크다면, 게이트는 절약이 아니라 부담이 됩니다.

다섯 강령 중 "Human in the loop" 하나가 이 두 가정을 모두 짊어지고 있습니다. 나머지 네 강령은 이 한 줄이 참이어야 살아납니다. 중복이 없는 산출물도, 재현 가능한 흐름도, 도구에 의존하지 않는 규칙도 사람이 게이트를 빠르고 정확하게 통과시킬 수 있어야 의미가 생깁니다.

커뮤니티의 반응은 둘로 갈립니다

지지하는 쪽도 회의적인 쪽도 AI가 코드를 빨리 만들어 낸다는 데는 이견이 없습니다. 그 속도가 팀 전체를 빠르게 만들었는지를 두고는 생각이 다릅니다.

지지하는 쪽은 기존 시스템에도 통한다는 점과 실전 사례를 내세웁니다. 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는 도구나 산출물보다 작업이 통과해야 하는 지점을 가장 크게 옮겼습니다. 그 지점이 우리 팀의 가장 좁은 길과 겹친다면 사이클은 빨라지고, 어긋난다면 같은 부담이 이름만 바꿔 다시 나타납니다. 도입할지 말지는 결국 우리가 어디서 가장 자주 멈춰 서는지에 달려 있습니다.