AIDLC — AI가 만들고 사람이 확인한다

seonest

같은 AIDLC를 도입한 두 팀이 한 주 만에 다른 결론에 이르렀습니다. 한 팀은 하룻밤 사이에 새 기능 여섯 개를 만들어 냈고, 다른 팀은 일주일을 돌려 보고도 "그래서 우리가 정말 중요한 일을 더 많이 하고 있나?"라는 질문 앞에서 멈췄습니다.

에이전트는 두 팀에서 똑같이 빨랐습니다. 그 속도를 성과로 볼 것이냐를 두고 판단이 갈렸을 뿐입니다.

Using AI-DLC 한 줄로 무엇이 바뀌는가

AIDLC(AI-Driven Development Life Cycle)는 AWS가 2025년 말에 공개한 개발 방법론입니다. 코딩 에이전트가 이 방법론을 따르도록 만든 규칙 모음도 제공합니다. 배포한 zip 파일을 풀어 .cursor/rules/나 CLAUDE.md 같은 위치에 두고, 요청을 Using AI-DLC, ...로 시작하면 에이전트가 정해진 개발 절차를 따릅니다.

사이클은 세 단계로 나뉩니다.

작업을 진행하는 방식도 다릅니다. 2주짜리 스프린트 대신 몇 시간에서 며칠 동안 진행하는 Bolt를 사용합니다. 티켓을 비동기로 주고받는 대신 팀원들이 모여 에이전트의 제안을 함께 검토합니다. AIDLC에서는 이런 모임을 Mob Elaboration·Mob Construction이라고 부릅니다.

사람의 승인은 필수 절차입니다. 각 단계에는 승인을 받을 때까지 작업을 멈추는 게이트가 있고, 규칙에는 Wait for Explicit Approval이라고 명시되어 있습니다. 사용자가 입력한 내용도 전부 audit.md에 그대로 남습니다.

에이전트가 작업을 진행하되 다음 단계로 넘어갈지는 사람이 결정하는 구조입니다.

에이전트의 제안을 사람이 검토하고 승인합니다

리포지토리에는 다섯 가지 원칙이 있습니다. 중복을 만들지 않고, 방법론을 우선하며, 같은 과정을 재현할 수 있어야 합니다. 특정 도구에 의존하지 않고, 사람이 판단 과정에 참여해야 한다는 원칙도 있습니다. 마지막 원칙은 본문에서 이렇게 표현합니다. "The agent proposes, the human approves."

이 분업이 효과를 내려면 두 조건을 충족해야 합니다.

우선 기존 작업에서 코드 작성이 가장 많은 비용을 차지해야 합니다. 그래야 에이전트에게 구현을 맡겨 아끼는 시간이 팀 전체의 작업 시간도 줄일 수 있습니다.

또한 의도를 설명하고 결과를 확인하는 비용이 직접 코드를 작성하는 비용보다 낮아야 합니다. 명세를 쓰고 검토하고 승인하는 데 오히려 더 많은 시간이 든다면 승인 절차만 늘어납니다.

사람이 제안을 빠르고 정확하게 검토하고 승인할 수 있어야 다른 원칙도 효과를 냅니다. 산출물의 중복을 없애고, 같은 과정을 재현하며, 특정 도구에 의존하지 않는 규칙을 갖추더라도 사람이 매번 승인 과정에서 막히면 작업은 빨라지지 않습니다.

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

지지하는 쪽도 회의적인 쪽도 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를 통째로 들여놓기 전에 막힌 곳부터 정리해야 합니다.

AIDLC를 도입할 때는 사람이 검토하고 승인해야 하는 단계가 우리 팀의 작업 과정에 어떻게 들어가는지 살펴봐야 합니다. 코드 작성 때문에 늦어졌다면 시간을 줄일 수 있습니다. 이미 검토할 결과물이 밀려 있다면, 코드 생성량이 늘어나는 만큼 대기 시간도 길어질 수 있습니다. 우리 팀에서 시간이 가장 많이 드는 작업부터 확인해야 도입 효과를 판단할 수 있습니다.