AI-DLC v2 비교해보기

AWS의 AI-DLC 는 먼저 설계하고 코드를 생성한다는 접근으로 개발 생산성을 올리는 방법론이다. 최근 v2가 활발하게 업데이트 되기 시작했다.

작은 localhost 웹 앱을 같은 기획으로 두 번 만들어봤다. 한 번은 v1으로, 한 번은 v2로.

이 글은 그 두 번에서 본 차이를 정리한 후기다. 결론부터 적자면, 상황에 따라 v1과 v2 중 어느 쪽이 더 맞을지가 갈리는 옵션처럼 느껴졌다.

비교의 출발점은 두 버전이 만들어낸 디렉토리 모양이다. 같은 기획을 같은 시점에 돌렸는데, 결과 트리의 모양이 전혀 다르다.

v2 쪽은 같은 기획이 이렇게 정리됐다.

각 스킬 폴더 안에는 *-questions.md, *-plan.md, 그리고 산출물 본체가 한 세트로 들어간다.

v1은 inception, construction, build-and-test 같은 stage-gate 폴더 아래에 산출물을 모아둔다. v2는 intent-001-stargazer라는 단일 인텐트 루트 안에서 bootstrap, requirements-analysis, wireframes, code-generation 같은 스킬 단위로 questions, plan, 산출물 3종 세트를 한 폴더에 묶는다. audit과 state도 v2에서는 별도 폴더로 명시적으로 분리된다. 트리 모양만 봐도 v1은 lifecycle 흐름을 따라가고, v2는 한 인텐트 안에서 스킬 단위로 사고를 강제한다.

이 차이는 룰셋 쪽에서도 그대로 드러난다. v1의 룰 디렉토리는 aws-aidlc-rule-details/ 아래에 common/, inception/, construction/, operations/, 그리고 extensions/(security와 testing 두 버킷) 이 1차 폴더로 놓인다. lifecycle stage 이름이 그대로 디렉토리 이름이다. 그 아래에 단계별 .md 룰 파일이 들어가는, stage-folder → per-step rule file 구조다.

반면 v2의 스킬 카탈로그는 평면적이다. aidlc-application-design, aidlc-code-generation, aidlc-functional-design, aidlc-nfr-assessment, aidlc-nfr-design, aidlc-wireframes, aidlc-owasp 같은 15개 스킬이 한 디렉토리 안에 나란히 놓이고, aidlc-orchestrator가 그 위에서 어떤 스킬을 어떤 순서로 호출할지 조립한다.

wireframes가 정식 스킬로 들어와 있고, owasp가 lens 형태로 별도 스킬이 됐다는 점이 눈에 띈다. v1에서 extensions/ 버킷에 들어가 있던 security가 v2 에서는 가장 높은 우선순위로 취급되는 것이다.

이 차이는 워크플로우 통제 방식에 그대로 따라간다. v1은 단계가 위에서 아래로 흐르는 모양이라 한 단계가 끝나야 다음 단계로 간다.

phase 단위 자체가 통째로 묶여 있어, 한 phase를 통째로 conditional skip 할 수도 있다. 단위가 큰 만큼 단순한 흐름이 빠르게 진행되는 효과가 있다. v2에서는 어떤 스킬을 어떤 순서로 호출할지를 workflow.md에서 조립한다.

작은 팀의 역할 분담을 그대로 카탈로그 디렉토리 이름에 매핑할 수 있다는 게 매력이지만, 동시에 한 인텐트 안에서 호출되는 스킬 수가 많아지면 각 스킬마다 거쳐야 하는 절차 단계 수도 함께 늘어난다.

또 한 가지 갈리는 지점은 거버넌스 trail의 모양이다. v1은 audit.md라는 단일 파일에 시간 순서로 사건을 덧붙인다.

v2의 intent-state.md는 같은 사건을 표 형태로 갱신한다.

v1의 audit.md는 무슨 일이 일어났나의 흐름을 시간 순서로 적는 append-only 내러티브 로그다. ISO-8601 타임스탬프가 줄마다 붙고, AI Action과 Decision이 차곡차곡 누적된다. 리뷰어가 처음부터 끝까지 읽어 내려가야 무슨 일이 있었는지 알 수 있는 형식이다.

v2의 intent-state.md는 지금 어디까지 왔나의 현재 상태를 표로 들고 있는 stateful checkpoint다. 스킬별 step, status, attempt, 산출물이 한눈에 보이고, OWASP 같은 lens 활성화도 별도 표로 분리돼 있다.

v2의 stage 한 개는 clarification → planning → execution → validation → verification → complete 라는 6개 step을 강제로 통과한다. 그리고 각 step transition이 intent-state.md 표에 토큰 단위로 기록된다. 답변이 풍부할수록 transition 줄도 길어지고, process-checker가 매칭해야 하는 토큰도 많아진다. 답변이 길어지면 step transition 처리 시간도 그만큼 늘어난다.

답변이 풍부한 프로젝트일수록 이 처리 시간이 더 길어진다. 한 줄로 적힌 디자인 토큰이나 도메인 정의가 wireframes 단계에서 한 번 결정되면, application-design 단계에서는 그 한 줄이 default 입력으로 자동 채워지고, code-generation 단계에서도 동일하게 이어진다. 이렇게 한 번 결정된 어휘가 다음 스킬의 입력으로 자동 이어지는 구조 자체는 v2의 강점이다. 다만 같은 어휘를 audit 표에 transition으로 다시 적는 일이 stage마다 반복된다는 점이 동시에 부담으로 작동한다.

거버넌스가 핵심 가치인 프로젝트라면 이 처리 시간이 거버넌스 trail이라는 산출물로 회수된다. 처리 시간이 곧 감사 가능한 기록이 되는 셈이다. 반대로 빠른 iteration이 우선인 프로젝트라면 처음부터 이 처리 시간이 비용으로 작용한다. workflow-composition의 옵션으로 step 수를 줄여보려고 해도 잘리는 건 clarification 답변 자동화 정도고, step transition, validator 호출, process-checker 매칭은 그대로 다 돈다.

즉 v2의 처리 시간은 프로젝트 성격에 따라 산출물로 활용되기도 하고, 그대로 비용으로 남기도 한다.

같은 기획을 v1과 v2로 두 번 돌리고 본 인상은 한 가지로 모인다. 프로젝트가 무엇을 우선하느냐에 따라 더 적합한 쪽이 달라진다는 점이다.

빠른 iteration이 우선이라면 v1의 phase 단위 stage gate가 가속으로 작동한다. Inception → Construction → Build/Test 라는 phase 단위 자체가 통째로 묶여 있어 흐름이 단순하고, 한 phase를 통째로 conditional skip 할 수도 있다. 시각이나 디자인 디테일이 중요한 프로젝트에서도 의외로 v1 쪽이 잘 맞는 경우가 있다. v1 Construction의 단계 분해(Functional Design, NFR Requirements, NFR Design, Code Generation)가 디자인 일관성을 NFR 단계에서 한 줄씩 고정해주기 때문이다. 그 한 줄이 코드 단계까지 그대로 따라간다.

거버넌스나 감사 가능성이 우선이라면 v2가 자연스럽다. 스킬 카탈로그가 역할과 1:1로 매핑되고, OWASP lens 활성화가 intent-state.md에 명시되어 보안 trail이 끊어지지 않는다. abuse-case persona가 user-stories에 자동으로 들어가고, builder/validator agent 분리 덕에 LLM이 자기가 쓴 글을 자기가 통과시키는 함정도 줄어든다.

다만 v2에는 결정적 빈자리가 하나 있다. build-and-test skill이 placeholder다. 두 서버를 띄우고 API contract를 검증하는 통합 게이트가 공식 단계에 없어서, 끝까지 가려면 이 부분은 직접 채워야 한다. 통합 빌드 게이트가 채워지면 사내 표준 후보로도 검토 가능한 수준으로 보인다.

v1 쪽은 반대로 Operations phase가 거의 placeholder다. SLO나 모니터링이나 인시던트 대응 룰이 비어 있어, 운영에 들어가면 다시 채워야 한다.

여기까지 본 차이를 한 화면에 정리하면 다음과 같다.

v1과 v2는 서로 보완 가능한 짝으로 보인다. v1이 v2에서 가져갈 만한 것은 stateful checkpoint, builder/validator agent 분리, wireframes의 정식 등재다. 반대 방향으로는 phase 단위 stage gate 옵션과 통합 빌드 게이트, conditional EXECUTE/SKIP 메커니즘이 v1에서 v2로 옮겨갈 후보로 보인다.

그리고 양쪽 모두에 빠져 있는 공통의 부분이 있다. workflow-mode: workshop | demo | full 같은 표준 신호어다. v1의 Conditional EXECUTE/SKIP과 v2의 Speed mode는 둘 다 "프로젝트 성격에 맞춰 절차 단계를 줄이기"라는 같은 메커니즘인데 표준이 없어, 어디서는 AGENTS.md preference로, 어디서는 workflow-composition 옵션으로, 어디서는 자연어 트리거로 표현된다. 워크샵 모드라는 단일 신호어가 룰 차원에 명시되면 비슷한 비교에서 단계가 한층 단순해질 거라 본다.

같은 기획을 두 버전으로 돌려보는 게 처음에는 과하다 싶었지만, 한 번만 돌려서는 못 보는 분기점이 분명히 있다. 비슷한 비교를 직접 해볼 생각이라면, 결과는 당신이 우선하는 가치에 따라 달라질 거라 본다.

AI-DLC 자체에 관한 배경은 AWS DevOps 블로그의 AI-DLC 소개 글 에 잘 정리되어 있으니, 시간이 허락한다면 한 번 읽어보길 권한다.

내가 본 분기점이 잘못된 것일 수도 있다. 비슷한 비교를 직접 해보고 다르게 보였다면 댓글로 알려주면 좋겠다.