AI 코딩 어시스턴트(AI coding assistants)는 코드를 작성하는 데는 뛰어나지만, 언제 작성해야 하는지는 잘 모릅니다. 기능을 하나 만들어 달라고 요청하면, 좋은 엔지니어가 먼저 던지는 질문들, 즉 '우리가 정확히 무엇을 만드는가?', '왜 만드는가?', '리스크는 무엇인가?', '어떻게 세분화해야 하는가?'와 같은 질문들을 건너뛰고 곧바로 구현 단계로 즐겁게 뛰어듭니다. 그 결과는 종종 잘못된 문제를 해결하는 빠른 결과물일 뿐입니다.

AWS의 **AI-DLC (AI-Driven Development Life Cycle, AI 주도 개발 생명 주기)**는 그 간극을 메우려는 시도입니다. 이는 awslabs에서 출시한 오픈 소스 워크플로(workflow) 규칙 세트로, AI 코딩 에이전트(AI coding agents)가 제멋대로 행동하게 두는 대신 규율 있는 소프트웨어 개발 프로세스를 따르도록 안내합니다. 중요한 점은, 이것이 설치하는 도구나 비용을 지불하는 서비스가 아니라는 것입니다. 이는 기존의 코딩 에이전트가 읽고 따를 수 있는 마크다운(markdown) 규칙 번들로 제공되는 방법론(methodology)입니다.

핵심 아이디어: 도구보다 방법론

AI-DLC의 명시된 원칙 중 하나는 "방법론 우선"입니다. 전체 시스템은 여러분의 에이전트가 프로젝트 지침으로 이미 사용하고 있는 곳에 바로 넣을 수 있는 일반 마크다운 규칙 파일 형태로 제공됩니다. 예를 들어 Claude Code를 위한 CLAUDE.md, Cursor를 위한 .cursor/rules/, GitHub Copilot을 위한 .github/copilot-instructions.md, Amazon Q를 위한 .amazonq/rules/, Kiro를 위한 스티어링 파일(steering files) 등이 있습니다. 실행할 것은 아무것도 없습니다. 에이전트가 규칙을 로드하면 그 동작이 변화합니다.

이로 인해 AI-DLC는 의도적으로 불가지론적(agnostic) 성격을 띱니다. 특정 IDE, 모델 또는 벤더(vendor)에 종속되지 않으며, 프로젝트 수준의 규칙을 지원하는 모든 코딩 에이전트가 이를 사용할 수 있습니다. 좋은 개발 방법론은 특정 도구보다 더 오래 지속되어야 한다는 철학을 담고 있습니다.

3단계 적응형 워크플로

AI-DLC의 핵심은 사려 깊은 소프트웨어가 실제로 구축되는 방식을 반영하여 작업을 세 가지 단계로 구성하는 것입니다.

Inception (구상) 단계는 무엇을(what) 그리고 왜(why) 구축해야 하는지에 대한 답을 제시합니다. 이 단계에서 에이전트는 요구사항 분석 (requirements analysis)을 수행하고, 필요한 경우 사용자 스토리 (user stories)를 생성하며, 애플리케이션 설계를 스케치합니다. 또한 작업을 병렬로 구축할 수 있는 단위로 분할하고, 코드 한 줄을 작성하기 전에 리스크와 복잡성을 평가합니다.

Construction (구축) 단계는 어떻게(how) 구축할 것인지에 대한 답을 제시합니다. 여기에는 상세한 컴포넌트 설계 (component design), 실제 코드 생성 (code generation), 빌드 구성 (build configuration), 테스트 전략 (testing strategy), 그리고 품질 검증 (quality validation)이 포함됩니다.

Operations (운영) 단계는 배포 및 모니터링 — 인프라 자동화 (infrastructure automation), 관측 가능성 (observability), 그리고 프로덕션 준비 상태 점검 (production-readiness checks)을 다룹니다. 이 단계는 현재 프로젝트에서 여전히 미래/진행 중인 상태로 표시되어 있으므로, 현재 완성된 기능이라기보다는 로드맵에 가깝습니다.

여기서 가장 중요한 단어는 **적응형 (adaptive)**입니다. AI-DLC는 모든 요청에 대해 전체 절차를 강요하지 않습니다. 요청한 작업의 복잡성을 분석하여 가치를 더하는 단계만 실행합니다. 사소한 변경 사항은 가볍게 유지되고, 복잡한 기능은 요구사항 분석, 설계, 리스크 평가를 포함한 전체 과정을 거칩니다. 이는 프로세스가 단순한 작업을 느리게 만든다는 일반적인 불만에 대한 합리적인 해답입니다.

이것이 전통적인 SDLC에 의미하는 바는 무엇인가요?

이 이름은 우연이 아닙니다. AI-DLC는 수십 년 동안 팀이 소프트웨어를 구축하는 방식을 조직해 온 SDLC — 소프트웨어 개발 생명 주기 (Software Development Life Cycle)를 의도적으로 활용한 명칭입니다. 즉, 요구사항, 설계, 구현, 테스트, 배포, 유지보수의 과정을 따릅니다. 이러한 단계들은 사람이 모든 단계에서 사고를 담당하고 프로세스가 주로 사람 간의 조율을 위해 존재했던, 인간 중심의 팀을 위해 작성된 것이었습니다.

AI-DLC의 가설은 이러한 가정이 더 이상 유효하지 않다는 것입니다. AI 에이전트가 몇 분 만에 설계와 코드를 생성할 수 있게 되면, 병목 현상은 작업을 생산하는 것(producing) 단계에서 무엇을 생산할지 결정하고 이를 검증하는 것(deciding what to produce and validating it) 단계로 이동합니다. 따라서 AI-DLC는 이러한 새로운 현실을 중심으로 라이프사이클(life cycle)을 재설정합니다. AI-DLC의 세 단계는 여전히 기존의 SDLC 단계와 매핑되지만, 그 역할은 반전되었습니다. 에이전트가 분석, 설계, 구현이라는 힘든 작업(heavy lifting)을 수행하는 반면, 인간의 역할은 각 게이트(gate)에서 방향을 잡고 승인하는 것이 됩니다. 프로세스는 더 이상 사람들을 조율하기 위해 존재하는 것이 아니라, 빠르게 움직이는 기계를 인간이 통제할 수 있도록 유지하기 위해 존재합니다.

그렇다면 이것이 AI-DLC가 SDLC를 "대체"한다는 의미일까요? 정신적인 측면에서는 그렇습니다. AI-DLC는 SDLC에 단순히 덧붙여진 것이 아니라, AI 코딩 에이전트 시대를 위해 재구축된 후계자로서 자리매김하고 있습니다. 하지만 현재의 범위를 솔직하게 인정할 필요가 있습니다. 운영(Operations) 단계는 여전히 미래의 영역으로 표시되어 있으며, 방법론은 모든 중요한 결정에 대해 인간이 승인하도록 명시하고 있고, AWS 자체도 생성형 AI(generative AI)가 여전히 실수를 저지를 수 있다고 경고합니다. 따라서 이것은 "SDLC가 죽었다"라기보다는 "SDLC가 다시 쓰여지고 있다"에 가깝습니다. 즉, 근본적인 단계는 동일하지만, 실제로 누가(또는 무엇이) 작업을 수행하느냐를 중심으로 재편된 것입니다. 순수하게 인간 중심적이며 단계 간의 인수인계(hand-offs) 모델에 매달리는 팀들은 소프트웨어가 구축되는 방식과 점점 더 동떨어지게 될 가능성이 높습니다.

인간을 루프 안에 유지하기 (Keeping the human in the loop)

AI-DLC에서 반복되는 주제는 인간이 승인하고 에이전트가 제안한다는 것이며, 그 반대는 절대 일어나지 않는다는 점입니다. 워크플로우(workflow)는 명시적인 체크포인트(checkpoints)를 중심으로 구축됩니다. 사용자는 각 실행 계획을 검토하고, 단계가 진행되기 전에 각 단계를 승인하며, 에이전트가 생성하는 산출물(artifacts)을 검증합니다. 이 모든 산출물은 aidlc-docs/ 디렉토리에 저장되므로, 무엇이 왜 결정되었는지에 대한 기록(paper trail)이 남게 됩니다.

흥미롭게도, AI-DLC는 구조화된 질문을 채팅(chat)이 아닌 파일(files) 형태로 밀어 넣습니다. 주고받는 대화 방식 대신, 에이전트가 당신이 답변할 수 있는 객관식 질문들을 문서 형태로 제시하며, 이를 통해 결정 사항들이 스크롤되는 대화 기록 속에 묻히지 않고 지속 가능하며 검토 가능한 상태로 유지됩니다. 시작하려면 단순히 "Using AI-DLC, ..."로 시작하는 요청을 작성하기만 하면 워크플로(workflow)가 활성화됩니다.

확장(Extensions): 자신만의 규칙 계층화하기

기본적으로 핵심 워크플로는 범용적이지만, AI-DLC는 추가적인 제약 조건을 상위에 계층화할 수 있는 **확장 시스템 (extension system)**을 지원합니다. 확장은 카테고리별로 그룹화되어 있으며, 프로젝트에는 예시로 security/ 베이스라인과 property-based testing/ 확장이 포함되어 있습니다.

각 확장은 규칙 파일(rules file)과 선택적 참여 프롬프트(opt-in prompt) 한 쌍으로 구성됩니다. 워크플로가 시작되면 AI-DLC는 이러한 선택적 참여 프롬프트를 스캔하고, 요구사항 분석(requirements analysis) 단계에서 각 프롬프트를 활성화할지 사용자에게 묻습니다. 참여(opt-in)를 선택하면 해당 규칙들은 _차단 제약 조건 (blocking constraints)_이 됩니다. 즉, 모델은 다음 단계로 진행하기 전에 모든 단계에서 반드시 준수 여부를 확인해야 합니다. 선택적 참여 파일이 없는 확장은 항상 강제 적용됩니다. 이를 통해 조직은 보안, 컴플라이언스(compliance), 또는 조직 특유의 표준을 내재화하여 AI가 이를 몰래 건너뛰지 못하도록 할 수 있습니다.

참고할 점: AWS는 번들로 제공되는 보안 확장을 프로덕션(production) 환경에 즉시 적용 가능한 정책이 아닌, _방향성 참조 (directional reference)_로 명시적으로 규정하고 있습니다. 사용자는 해당 규칙에 의존하기 전에 자신만의 규칙을 구축, 맞춤화 및 테스트해야 합니다.

이를 지탱하는 원칙들

AI-DLC의 설계는 몇 가지 짧은 원칙들에 뿌리를 두고 있습니다: 중복 금지 (단일 진실 공급원(one source of truth)을 유지하고 다른 형식은 거기서 생성), 방법론 우선 (설치할 것이 없음), 재현성 (서로 다른 모델이 유사한 결과를 낼 수 있을 만큼 규칙이 명시적임), 도구 불가지론 (tool-agnosticism), 그리고 인간 참여형 제어 (human-in-the-loop control)입니다. 이 원칙들을 종합하면 왜 앱이 아닌 마크다운(markdown)을 사용하는지, 왜 여러 에이전트에 걸쳐 작동하는지, 그리고 왜 곳곳에 승인 게이트(approval gates)가 있는지와 같은 대부분의 설계 선택을 설명할 수 있습니다.

시도해 볼 가치가 있을까?

이미 AI 코딩 에이전트 (AI coding agent)에 의존하고 있지만, 에이전트가 너무 서둘러 코드를 작성하거나, 단순한 요청을 과하게 설계 (over-engineers)하거나, 사고 과정을 건너뛰는 것에 답답함을 느끼고 있다면, AI-DLC는 부담 없는 실험이 될 수 있습니다. 이는 무료이며, 단순히 파일들로 구성되어 있고, 이미 사용 중인 도구들과 함께 작동하며, 언제든 아주 쉽게 다시 제거할 수 있습니다. 솔직한 주의 사항을 말씀드리자면, 운영 (operations) 단계가 아직 완성되지 않았고, 보안 확장 기능은 완성된 통제 수단이라기보다는 시작 단계에 있으며, 그리고 — AWS 자체에서도 언급했듯이 — 생성형 AI (generative AI)는 여전히 실수를 저지르기 때문에, 검토 게이트 (review gates)는 선택적인 요식 행위가 아닙니다. 그것이 바로 핵심입니다.

일회성 코드 폭발이 아니라 AI 어시스턴트로부터 일관되고 검토 가능한 동작을 끌어내려는 팀에게, 이는 진정으로 유용한 프레임워크 (framing)입니다.

더 알아보기

이 프로젝트는 MIT-0 라이선스 하에 오픈 소스로 제공되며 GitHub에서 확인할 수 있습니다: awslabs/aidlc-workflows. 해당 저장소에는 Kiro, Amazon Q, Cursor, Cline, Claude Code, 그리고 GitHub Copilot을 위한 설정 지침과 함께, AWS의 AI-DLC 방법론 블로그 및 방법 정의 논문으로 연결되는 링크가 포함되어 있습니다.

출처: awslabs/aidlc-workflows on GitHub