서론

AI-DLC는 AWS가 제창하는, 개발 라이프사이클(Development Lifecycle) 전체에 AI를 통합하는 방법론이다. 그 Workflows 2.0에서는 공정의 구성 단위 자체가 재설계되었다. 재설계된 이유는 v1을 실제로 운용한 팀이 직면했던 과제에 있다고 한다. 따라서 이 기사에서도 그 과제가 무엇이었는지 확인하고, v1의 문제점과 v2의 개선점에 대해 정리해 보고자 한다. 중심적으로 다룰 내용은, 인간이 수행하던 합격/불합격 판정을 검사 조건으로 기술하여, 실행 가능한 검사로 대체해 나간다는 발상이다.

AI-DLC 1.0은 무엇이었나

AI-DLC 1.0은 개발 공정을 몇 개의 스테이지(Stage)로 나누고, 각 스테이지에서 AI가 결과물의 초안을 만들면 인간이 확인하며 다음 스테이지로 진행하는 구성을 취하고 있었다. 실체는 Kiro, Q Developer, Cursor, Cline, Claude Code, Copilot, Codex와 같은 에이전트(Agent)용으로 배포되는 markdown 규칙 파일이며, v2의 사양서(Specification) 자체도 v1을 이렇게 설명하고 있다.

실제로 운용한 보고도 있다. PKSHA는 AI-DLC를 Inception과 Construction의 두 가지로 나누어 운용하였으며, Construction에서는 Bolt와 Unit이라는 단위로 작업을 진행했다고 한다. 즉, 현장에서는 개발 공정을 작은 실행 단위로 나누어 AI와 함께 진행하기 위한 프레임워크(Framework)로서 사용되었던 것으로 보인다.

v1의 가치는 AI의 적용 범위를 코딩(Coding) 너머로 확장하여 요구사항, 설계, 구현, 테스트를 일련의 공정으로 연결했다는 점에 있다고 생각한다. 이 목표 자체는 v2에서도 변하지 않았다. 바뀐 것은 공정을 어떻게 구분하고, 각 구분에서 무엇을 합격으로 볼 것인가를 결정하는 방식이다.

실제로 사용해 보니, 두 가지 과제가 나타났다

과제 1: 스테이지의 구분이 현장의 작업 단위보다 거칠다

v1은 Build & Test를 하나의 스테이지로 두었다. 하지만 실제 팀에서는 코드 리뷰(Code Review), 빌드(Build), 기능 테스트(Functional Test), 보안 테스트(Security Test)는 각각 별개의 활동이며, 담당자와 합격 조건도 다르다. UI mockup을 User Stories와 동시에 만드는 팀이 있는가 하면, Design 스테이지까지 뒤로 미루는 팀도 있다. 나아가 고객별 가드레일(Guardrail)이나 컴플라이언스(Compliance) 요구사항, 도메인 특화 워크플로우는 방법론을 설계한 측의 사전 예측 범위를 벗어나서 확장된다.

정해진 스테이지 구성이 자신들의 작업 경계와 맞지 않을 때, 팀은 스테이지를 재해석하거나 방법론 자체를 포기해야 하는 상황에 처한다. v2의 사양서는 이 상황을 v1의 stage 정의가 너무 규정적(Prescriptive)이어서 채택 시 마찰(Friction)이 발생했다고 총괄하고 있다.

과제 2: 합격 기준이 인간의 머릿속에만 있다

또 다른 과제는 스테이지 내부에서 발생한다. AI가 초안을 만들더라도 그 출력을 수용해도 좋을지 판정하는 기준이 어디에도 적혀 있지 않기 때문에, 인간이 매번 동일한 관점에서 동일한 확인을 반복하게 된다.

예를 들어, 사용해서는 안 되는 API 호출이 팀 내에서 결정되어 있다고 가정하자. 리뷰어는 AI가 생성한 코드를 매번 육안으로 확인하며, 지난번에 지적했던 것과 동일한 수정을 이번에도 넣는다. 이 확인을 통해 얻은 지식은 리뷰어의 머릿속에 쌓일 뿐, 다음 실행으로 이어지지 않는다. AI 입장에서는 합격 조건이 마지막까지 불명확한 상태이므로, 동일한 실수를 반복한다.

과제 1이 어디서 공정을 구분할 것인가의 문제라면, 과제 2는 무엇을 합격으로 볼 것인가의 문제로 성격이 다르다. v2는 이 두 가지에 대해 별도의 답을 준비해 두었는데, 과제 1에는 Skill로의 분해가, 과제 2에는 Three-Compartment Model이라고 불리는 메커니즘이 대응한다. 이 기사에서 자세히 살펴보고 싶은 것은 과제 2 쪽이다.

스테이지를 Skill로 분해하기

과제 1에 대한 v2의 답은 공정의 구성 단위를 작게 만드는 것이었다. v1에서는 Build & Test와 같은 커다란 스테이지가 구성 단위였으나, v2에서는 이를 Code Review, Build, Functional Test, Security Test와 같은 Skill로 분해한다. 스테이지라는 용어는 상위 레이블(Label)로서 남지만, 팀이 선택하거나 재배열하는 것은 Skill이 된다. 코드 리뷰와 보안 테스트가 별개의 활동으로 움직이는 팀이라면, 그 경계 그대로 Skill을 배치하면 된다.

각 Skill의 내용은 3개의 구획(Compartment)으로 작성한다. 앞서 이름만 언급했던 Three-Compartment Model이 바로 이것이며, 첫 번째 구획인 Compartment 1에는 Skill이 무엇을 입력받고 무엇을 출력하는지를 작성한다. 최종 결과물뿐만 아니라, 이를 건너뛸 경우 하류(downstream)의 품질이 저하되는 중간 결과물도 포함한다. 예를 들어 설계(Design) Skill이라면, User Stories에서 Domain Model에 이르는 과정에서 필요하게 되는 events, aggregates, bounded contexts를 명시해 둔다. Security Test라면 입력은 변경된 코드와 의존성 목록이 되고, 출력은 검사 보고서와 합격/불합격 여부가 된다.

하지만 여기까지는 과제 1에 대한 답일 뿐이다. Skill로 나누어 입출력을 작성하더라도 합격 기준이 없다면, 그 검사 보고서를 받아들여도 될지 여부는 결국 리뷰어가 매번 육안으로 결정하게 된다. 그 합격 기준을 작성하는 곳이 두 번째 구획인 Compartment 2다.

합격 기준을 Skill에 작성하기

Compartment 2에는 AI의 출력을 받아들여도 될지를 판정하는 조건을 작성한다. 사양서(Specification)에서 "How Do We Know It's Right"라고 명명한 구획으로, 작성할 수 있는 검사는 두 종류가 있다. 설계 리뷰의 관점이나 UX의 자연스러움처럼 글로 작성하여 LLM이 판정하게 하는 LLM instructions와, 테스트(Test), 린트(Lint), 타입 체크(Type Check), 보안 스캔(Security Scan)처럼 AI 외부에서 프로그램으로서 실행할 수 있는 Executables다.

굳이 두 종류로 나누어 놓은 이유는 LLM instructions만으로는 검사로서 힘이 약하기 때문이다. 동일한 AI가 만든 출력을 동일한 AI가 채점하면, 지시 문구에는 부합하더라도 의도를 충족하지 못하는 출력이 통과될 수 있다. 따라서 사양서는 가능한 검사를 executable로 옮길 것을 권장한다.

Security Test에 대입해 보면, 검사에는 기계화하기 쉬운 것과 그렇지 않은 것이 있다. 사용해서는 안 되는 API 호출은 정적 분석(Static Analysis)으로 검출할 수 있고, 명명 규칙은 linter나 custom script로 확인할 수 있다. 반면, 설계가 보안 관점에서 타당한지에 대한 판단은 LLM instructions와 인간의 리뷰로 남는다. 과제 2에서 언급한 리뷰어의 육안 확인 중 정적 분석으로 전환할 수 있는 것들이 여기서 검사 조건으로 변한다.

인간의 수정 사항을 다음 합격 기준으로 바꾸기

물론 처음부터 Compartment 2를 완벽하게 작성할 수 있는 팀은 없을 것이다. 누락된 기준은 운영이 시작된 후 인간의 수정(Manual correction)이라는 형태로 나타난다. 세 번째 구획인 Compartment 3는 이러한 수정 사항을 기록하는 장소로, "What Did We Learn"이라는 이름이 붙어 있다. 실행 중에 인간이 수정한 내용, 재실행이 된 이유, 예외를 인정한 이유를 남겨 다음 검사 조건의 후보로 삼는다.

사양서에는 예시가 나와 있다. 생성된 요구사항 문서의 동일한 섹션을 인간이 매번 다시 쓰고 있다면, 그 수정 패턴으로부터 새로운 post-condition을 제안한다. 특정 설계 판단을 인간이 반복적으로 덮어쓰고 있다면, 그 판단을 guardrail의 후보로 삼는다. 제안이 자동으로 활성화되지는 않으며, 인간이 승인해야 비로소 active rule set에 포함된다.

Security Test에서도 같은 일이 일어난다. 리뷰어가 매번 같은 종류의 취약한 작성 방식을 지적하고 있다면, 그 지적은 정적 분석 규칙의 후보가 된다. 과제 2에서 썼던, 리뷰어의 머릿속에 쌓여 다음으로 이어지지 못했던 지식들이 여기서 검사 조건으로서 Skill에 기록되어 간다. 사양서가 Principle 1에 두는 "Human Judgement Insights Can Be Distilled into Machines"는 바로 이러한 움직임을 의미한다.

AI가 스스로 수정할 수 있는 범위

검사 조건이 executable이 되면 또 하나의 메커니즘이 작동하기 시작한다. AI가 검사 실패를 보고 수정하며 다시 검사를 받는 Self-Correcting Loop다. 합격 여부를 인간이 확인하는 동안에는 수정할 때마다 확인 대기 시간이 발생하지만, 검사가 프로그램이라면 AI는 인간을 기다리지 않고 루프를 돌릴 수 있다.

다만, 사양서(specification)는 이 루프를 무조건적으로 허용하지는 않는다. 사후 조건(post-condition)이 AI 스스로는 변경할 수 없는 프로그램으로 검사 가능해야 하며, 성공 기준에 반복을 통해 도달할 수 있다는 전망이 있어야 하고, 1회 반복 비용이 저렴해야 한다. 또한, 최대 반복 횟수나 토큰 예산(token budget)과 같은 정지 조건(stopping condition)을 가져야 하며, 수렴하지 않을 때는 인간에게 에스컬레이션(escalation)하는 것도 요구된다.

Security Test의 경우를 예로 들면, 정적 분석 규칙을 통과할 때까지 AI가 스스로 코드를 수정하는 것은 이 루프에 해당한다. 설계의 우수성(design quality)처럼 실행 가능한(executable) 검사가 없는 판단은 루프 밖에서 인간이 확인한다. 즉, AI에게 맡길 수 있는 범위를 결정하는 것은 Compartment 2와 3이며, 어디까지 검사 조건을 작성할 수 있느냐에 따라 달라진다. 맡길 수 있는 범위를 넓히고 싶다면 검사 조건을 계속해서 추가해 나가야 한다.

인간의 업무는 어디에 남는가

이렇게 보면, 인간의 역할은 매번 출력을 확인하는 역할에서 검사 조건을 설계하고 육성하는 역할로 옮겨간다. 기계화할 수 있는 판단은 Compartment 2에 작성하고, 매번 발생하는 수정 사항은 Compartment 3에서 검사 조건의 후보로 바꾸어 나간다면, 진행을 위해서만 필요한 승인은 줄어들게 된다.

그럼에도 남는 업무는 있다. 어떤 검사 조건을 작성할지, 언제 업데이트할지, 어디까지 자율화를 허용할지는 인간이 결정할 수밖에 없으며, 목적이나 우선순위, 요구사항끼리 충돌했을 때의 조정, 변경에 대한 책임도 마찬가지다. v2가 기계로 넘기는 것은 합격/불합격의 판정이며, 무엇을 합격으로 정의할지에 대한 책임은 인간에게 계속 남는다.

마치며

AI-DLC Workflows 2.0을 v1의 운영 과제로부터 추적해 왔다. 스테이지의 구분이 현장에 맞지 않는 과제에는 Skill로의 분해를, 합격 기준이 인간의 머릿속에만 있는 과제에는 Compartment 2와 3라는 대응을 통해, 인간이 매번 수행하던 합격/불합격 판정은 검사 조건으로 기술되며, 가능한 것부터 기계로 실행할 수 있는 검사로 변해간다.

내가 이 사양에서 얻은 통찰은, AI에게 맡길 수 있는 범위는 검사 조건을 작성한 만큼 넓어진다는 관점이다. 새로운 모델의 성능에 화제가 집중되기 쉽지만, 실제 운영에서 효과를 발휘하는 것은 리뷰할 때마다 반복되는 지적 사항을 하나씩 검사 조건으로 바꾸어 나가는 꾸준한 작업이라고 생각한다.

Discussion