AI 코딩 도구는 이제 자동완성 수준을 넘어 설계와 구현의 상당 부분을 대행하는 단계에 접어들었다. 문제는 프로젝트가 커질수록 이 작업들이 서로 연결되지 않는다는 점이다. 요구사항, 설계 결정, 실제 코드, 테스트, 운영 작업이 각각의 대화와 파일에 흩어지면서 '왜 이렇게 만들었는가'를 추적하기 어려워진다. AWS 랩스가 공개한 AI-DLC(AI-Driven Development Life Cycle) 워크플로는 바로 이 맥락 손실 문제를 겨냥한다. 핵심 아이디어는 AI 어시스턴트를 자유로운 대화 상대가 아니라 정해진 단계와 검증 지점을 따르는 구조화된 전달 워크플로로 전환하는 것이다.
하나의 코어, 여러 하네스
AI-DLC의 설계에서 눈에 띄는 지점은 '하네스 중립적인(harness-neutral)' 단일 코어다. 같은 방법론을 Claude Code, Kiro CLI, Kiro IDE, Codex CLI, Cursor, opencode, GitHub Copilot에서 네이티브로 동일하게 돌린다. 실무자 입장에서 이는 특정 도구에 종속되지 않고도 팀 전체가 같은 개발 생명주기 규칙을 공유할 수 있다는 의미다. 설치는 네이티브 aidlc 명령과 각 하네스 런타임을 한 번에 구성하며, 이때는 Bun이나 Node.js를 따로 깔 필요가 없다. 반대로 프로젝트 파일을 직접 관리하고 싶거나 네이티브 실행 파일 설치가 어려운 경우에는 수동 복사 경로를 쓰는데, 이 경로에서만 Bun이 필요하고 릴리스의 런타임 디렉터리를 프로젝트에 그대로 넣는 방식이다.
도구별로 호출 방식이 조금씩 다르다는 점은 알아둘 만하다. 대부분 /aidlc 형태를 쓰지만 Codex CLI는 $aidlc를 사용하고, Kiro IDE에서는 채팅 패널의 에이전트 선택기에서 먼저 aidlc를 골라야 한다. 설정은 하네스를 지정해 aidlc config를 실행하거나, --harness 없이 실행하면 터미널 환경에서 대화형 설정이 시작된다.
승인 게이트라는 설계 철학
이 프로젝트의 실무적 가치는 작동 방식에 있다. AI-DLC는 사용자의 요청에서 적절한 워크플로를 스스로 선택하고, 결정되지 않은 사항이 있으면 먼저 물으며, 다음 단계로 넘어가기 전에 '승인 게이트'에서 멈춘다. 즉 AI가 요구사항 해석부터 구현까지 한 번에 질주하지 않고, 사람이 중간중간 확인하고 결재하는 구조를 강제한다. 요구사항·결정·구현·테스트·운영 작업이 하나의 감사 가능한(audited) 생명주기로 이어진다는 설명도 같은 맥락이다. AI가 만든 결과물이 왜 그렇게 나왔는지 거슬러 올라갈 수 있게 흔적을 남기는 것이다.
워크플로는 하나로 고정돼 있지 않다. Classic, Express, 그리고 목적이 좁은 전용 워크플로를 비교해 고르는 '워크플로 프로파일' 개념이 제공되며, 아키텍처와 방법론은 AI-DLC Workflows 2.0 명세에 정리돼 있다. 작업 규모와 성격에 따라 무거운 전체 생명주기와 가벼운 흐름을 선택할 수 있도록 한 셈이다.
모델과 보안 고려사항
방법론 자체는 공급자 중립적이지만, 실제 모델 선택은 하네스의 몫으로 남겨 둔다. 프로젝트 구성은 사용자가 이미 고른 공급자와 모델을 그대로 유지하고, aidlc config providers로 지원되는 환경에서 Amazon Bedrock 설정을 적용하거나 다른 하네스의 수동 설정을 기록할 수 있다. Kiro CLI와 Kiro IDE는 모델 접근이 Kiro와 함께 제공되므로 별도 공급자 응답이 필요 없다. AI-DLC는 추론 능력이 뛰어난 모델에서 가장 잘 작동하며, 현재 권장 모델로 Claude Opus 4.8이 제시된다.
보안 측면에서 짚을 부분도 있다. 윈도우에서는 현재 계정 기준으로 설치되며 관리자 권한으로 연 PowerShell에서 실행하면 경고가 뜨는데, 관리자 설치가 더 위험하기 때문이다. Kiro IDE에서 신뢰하지 않은 폴더의 자체 터미널을 쓰면 신뢰 여부를 먼저 묻는데, '신뢰'를 선택하면 해당 폴더의 .kiro 훅이 기기에서 명령을 실행할 수 있으므로 본인이 검토한 프로젝트에만 허용하라는 안내가 붙는다. 외부에서 받은 저장소를 다룰 때 특히 유의할 대목이다.
정리하면 AI-DLC는 '더 똑똑한 생성'이 아니라 '생성 과정의 관리'에 초점을 둔 도구다. 생성형 AI가 실수할 수 있으니 결과물과 비용을 실행 전에 검토하라는 경고가 문서에 명시돼 있다는 점은, 이 프로젝트가 자동화의 속도보다 통제와 추적성을 우선한다는 성격을 그대로 드러낸다. 이미 여러 AI 코딩 도구를 혼용하는 팀이라면, 도구를 바꾸지 않고도 공통된 개발 규율을 입힐 수 있는지 시험해 볼 만한 접근이다. 다만 승인 게이트와 단계화가 주는 안정성은 그만큼의 절차 비용을 수반하므로, 가벼운 작업까지 전체 생명주기에 태우는 것이 적절한지는 워크플로 프로파일을 저울질해 판단해야 한다.