코딩 에이전트를 프로젝트 전 주기에 참여시키는 AI-SDLC

이 시리즈는 AI-SDLC를 다룬다. Coding Agent가 코드를 작성하는 이 한 단계에만 머무르지 않고, 요구사항 이해, 설계 검토부터 개발, 통합 테스트, 인도까지 소프트웨어 프로젝트의 전체 주기 동안 참여하도록 만드는 것이다.

시리즈에서는 두 가지를 분명히 밝힌다.

- 이 연결망을 끝까지 실행할 수 있고, 중단된 뒤에도 복구할 수 있으며, 결과가 정확함을 증명할 수 있는 엔지니어링 체계로 어떻게 만들 것인가;

- 각 설계가 Claude Code와 Codex의 어떤 메커니즘에 구체적으로 대응하는가, 여기에는 hooks, subagents, skills, MCP, 권한과 설정이 포함된다.

이 글은 총론으로, 세 가지 질문에 답한다.

- AI-SDLC란 무엇인가;

- 왜 해야 하는가, 왜 지금인가;

- 어떤 모습으로 만들어야 하는가.

AI-SDLC란 무엇인가: Coding Agent가 전체 프로젝트 주기를 참여하도록

SDLC(Software Development Life Cycle, 소프트웨어 개발 생애주기)는 하나의 요구사항이 제기되어 출시되기까지 거치는 모든 단계를 의미한다.

현재 Coding Agent의 효율 향상은 코딩이라는 한 단계에 집중되어 있다. 코드 자동완성, 대화형 수정, 설명에 따라 함수 하나나 페이지 하나를 생성하는 수준이다. 요구사항을 누가 이해하고, 설계를 누가 검토하며, 통합 과정에서 드러난 문제를 누가 수습하는지는 여전히 사람이 하나하나 처리한다.

문제는, 성숙한 대형 시스템에서 코딩은 그중 한 단계일 뿐이며 가장 긴 단계도 아니라는 점이다. 초기의 요구사항 이해, 설계 검토, 후기의 통합 테스트는 종종 프로젝트 주기의 60%는 되고 그 이상도 차지할 수 있다.

공개된 조사도 이와 같은 방향을 가리킨다. 마이크로소프트가 2024년에 484명의 개발자를 대상으로 한 조사(ICSE 2025 논문 Time Warp)에 따르면, 실제 근무 주 기준으로 코드를 작성하는 시간은 약 11%를 차지했다. 개발자가 이상적인 상태로 분배하도록 해도 코드 작성은 약 20%만 차지했다.

코딩 단계에서만 AI를 사용하는 데는 두 가지 한계가 있다.

첫째는 효율에 상한이 있다는 것이다. 압축되는 것은 주기의 절반이 안 되는 부분일 뿐이다. 요구사항 이해에 일주일이 더 걸린다든지, 통합 과정에서 재작업이 한 차례 더 발생한다든지 하는 것은 코딩이 아무리 빨라져도 메울 수 없다.

둘째 한계는 더 감추어져 있는데, 컨텍스트 부족으로 인한 품질 문제다. 코딩에만 참여하는 Agent가 받는 것은 '이 코드를 고쳐라'라는 국소적 정보일 뿐이다:

- 요구사항이 왜 이렇게 정해졌는지 모른다;

- 설계 검토 때 어떤 방식이 기각되었고 그 이유가 무엇인지 모른다;

- 통합 과정에서 어떤 인터페이스 제약이 드러났는지도 모른다.

이런 조건에서 그것이 작성한 코드는 컴파일과 단위 테스트를 통과할 수 있지만, 프로젝트에 넣으면 맞지 않는다.

AI-SDLC가 겨냥하는 것은 바로 이 두 가지 한계다. Coding Agent가 프로젝트 개발 전 과정에 참여하여 각 단계에서 컨텍스트를 확보하고, 이 단계에서 형성된 컨텍스트를 축적되도록 하여, 이를 통해 인도 품질을 높이는 것이다.

요구사항 목록과 제외 범위, 기술 설계와 검토 결론, 변경과 검증 증거, 통합 기록과 잔여 문제가 차례로 다음 단계로 전달된다. 사람의 작업은 네 가지 결정에 집중된다. 목표와 범위, 경계와 위임, 인수 기준, 외부 행동이다.

여기서 진짜 변화는 AI가 더 많이 하느냐 적게 하느냐가 아니라, 단계와 단계 사이가 무엇으로 연결되느냐다.

AI 보조 코딩에서는 연결을 사람이 한다. 사람이 요구사항을 읽고, 사람이 검토 결론을 기억하고, 사람이 코드가 다 작성되었는지 판단한다. AI-SDLC에서는 연결을 기록으로 남긴 산출물이 담당한다. 다음 단계와 다음 Agent가 읽는 것은 산출물이지, 어떤 사람의 요구사항 이해가 아니다.

그래서 AI-SDLC는 공학의 문제이지 도구 선택의 문제가 아니다. 각 단계가 무엇을 읽고, 무엇을 쓰고, 다 쓴 뒤 어떻게 검사할지를 반드시 정의해야 한다.

이것은 내가 앞서 쓴 《AI-Ready와 AI-SDLC에 대해 이야기하며》에서 논한 AI-Ready와 상하 관계에 있다. AI-Ready는 'AI가 이 프로젝트를 이해할 수 있는가'를 해결하고, AI-SDLC는 'AI가 참여하여 한 번의 인도를 끝낼 수 있는가'를 해결한다.

왜 해야 하는가: 코딩 가속 이후의 세 가지 변화

첫 번째 변화는 압력이 코딩 전후 단계로 옮겨간다는 것이다. 코딩이 빨라질수록 단위 시간에 검토, 테스트, 병합으로 들어오는 변경이 많아지고, 이런 단계의 기존 수용력은 빠르게 부족해진다.

OpenAI는 2026년 11월 2일 엔지니어링 블로그에서 공개 사례를 제시했다. Codex는 엔지니어가 더 많은 작업을 병행하도록 해주며, 한 엔지니어가 흔히 동시에 여러 변경을 CI에 대기시키고, 매 push마다 여러 작업이 동일한 커밋을 가져오도록 촉발한다.

2025년 말부터 그들의 monorepo를 지탱하던 시스템은 이런 부하를 따라가지 못했고, 신뢰성은 한때 90% 아래로 떨어졌으며, 결국 그들은 Git 백엔드를 다시 작성했다.

과거에는 병목으로 여겨지지 않던 소스 관리 같은 단계가 코딩 가속 이후 병목이 되었다. 전후 단계를 함께 개조하지 않으면, 코딩에서 절약한 시간은 적체에 잡아먹힌다.

두 번째 변화는 개인의 사용 방식 차이가 확대된다는 것이다. 사람마다 AI를 쓰는 방식이 다르다. 누군가는 먼저 설계안을 내게 하고, 누군가는 바로 코드를 쓰게 한다. 누군가는 한 줄씩 검토하고, 누군가는 테스트 통과만 보면 병합한다.

같은 요구사항을 두 사람에게 주면 과정과 품질이 모두 다르다. 좋은 방법은 개인의 습관에 머물고, 문제가 생겨도 어느 단계에서 잘못됐는지 집어낼 수 없다. 인도 과정을 명확한 단계, 산출물, 검사로 써 두면 그때서야 방법이 팀 내에서 공유되고, 결과가 측정되며, 개선에 대상이 생긴다.

세 번째 변화는 문제가 'AI가 쓸 수 있는가'에서 '놓아두고 하게 할 수 있는가'로 바뀐다는 것이다. Agent의 한 번 실행은 오래 지속될 수 있고, 중간에 여러 하위 agent를 파견하기도 하므로, 사람이 일일이 지켜볼 수는 없다.

이때 놓아둘 수 있는지를 결정하는 것은 모델 능력이 아니라, 네 가지를 보장하는 메커니즘이 있느냐다:

- 중단된 뒤 이어서 할 수 있다;

- 실패한 뒤 제자리에서 재시도하지 않는다;

- 완료라고 보고할 때 실제로 완료되었다;

- 모든 변경에 증거가 있다.

이런 보장은 모델이 업그레이드된다고 자동으로 생기지 않는다.

왜 지금인가 하면, 구성 요소는 이미 갖춰졌기 때문이다. Claude Code와 Codex는 모두 subagent(컨텍스트 격리, 병렬 실행), skill(필요 시 로드하는 방법), hook(고정된 시점에 촉발되는 스크립트), MCP(외부 시스템 연결)와 세밀한 권한 설정을 제공한다.

빠진 것은 조립 방법이다. 어떤 일을 어떤 메커니즘에 맡기고, 어느 정도까지 쓰고, 어디에는 쓸 수 없는가다. 이 시리즈의 각 글은 이 부분을专门으로 다룰 것이다.

어떤 모습으로 만들어야 하는가: 신뢰성 있는 실행과 올바른 인도라는 두 가지 목표

Agent가 '전부 완료'라고 말할 때, 실은 두 가지를 나눠 봐야 한다. 흐름이 끝까지 갔는가, 산출물이 요구에 부합하는가. 이 두 가지는 자주 일치하지 않는다.

전형적인 워크플로를 하나 들자면, 요구사항은 App에 목록 페이지를 하나 추가하는 것이고, 다섯 단계가 모두 완료로 표시되었으며 컴파일과 단위 테스트가 전부 통과했다. 그러나 문제는 두 군데 있었다:

- 디자인 시안에는 데이터가 있을 때의 모습만 그려져 있고, 목록이 비었을 때, 로딩이 실패했을 때 어떻게 표시하는지는 그려져 있지 않았는데, Agent는 묻지 않고 스스로 스타일을 추측했다;

- 인수 기준에는 '네트워크가 끊겼을 때 사용자에게 재시도를 안내한다'라고 적혀 있었지만, 이를 커버하는 테스트는 하나도 없었다.

흐름상으로는 모든 단계가 끝까지 갔다. 인도상으로는 두 군데가 요구에 부합하지 않았다.

반대 방향의 상황도 똑같이 존재한다. 어떤 하위 작업의 코드는 올바르게 작성되었지만, 대화가 너무 길어져 자동으로 압축된 뒤 스케줄링을 담당하는 메인 Agent가 이 하위 작업의 결과가 어디에 있는지 잊어버렸고, 이후 단계가 옛 방안을 그대로 들고 계속 진행하다가 최종 인도에 오류가 발생한다.

앞의 실패는 정확성에서 발생하고, 뒤의 실패는 실행에서 발생하는데, 둘의 수정 수단은 거의 겹치지 않는다. 테스트를 아무리 많이 보강해도 잃어버린 결과를 되찾을 수 없고, 상태 관리를 아무리 빈틈없이 해도 추측으로 만들어낸 인터페이스를 막을 수 없다.

따라서 AI-SDLC는 두 가지 목표를 동시에 달성해야 하며, 둘은 서로를 대체하지 않는다. 작업이 신뢰성 있게 끝까지 실행되는 것, 그리고 결과가 실제로 올바른 것. 각 목표 아래에는 반드시 해결해야 할 다섯 가지 문제가 있다.

신뢰성 있는 실행: 모든 단계에 근거가 있고, 중단을 복구할 수 있어야 한다

문제 해결 방법 대화가 너무 길어 Agent가 어느 단계까지 했는지 정확히 기억하지 못함 단계 상태, 산출물, 검증 기록을 대화에만 두지 않고 작업 디렉터리에 기록함 유형이 다른 작업은 흐름도 다름 흐름 정의로 어떤 단계가 있고 선후 의존 관계가 어떠한지 규정하며, 각 단계에 입력, 실행, 출력, 검사를 명시함 여러 Agent가 협업할 때 정보 손실 작업을 배정할 때 목표, 필요한 자료, 수정 허용 범위를 명시하고, 반환 시에는 「완료했다」는 한마디가 아니라 대조 검증 가능한 산출물을 제시함 오류 발생 후 반복 재시도하지만 진전이 없음 먼저 문제가 어느 고리(요구사항, 설계, 구현, 환경, 권한)에서 발생했는지 판단하고, 해당 단계로 되돌아가 처리하며, 각 경로마다 횟수를 제한함 일부만 완료했는데 전부 완료했다고 보고함 실제로 도달한 단계, 필수 산출물, 검사 결과, 미해결 문제를 기준으로 완료 상태를 계산하며, Agent의 자기 진술을 기준으로 삼지 않음

이 측면에서 가장 과소평가되기 쉬운 것은 컨텍스트 압축이다. 긴 작업에서는 압축이 일상적이며, 단계 상태와 산출물 경로가 대화 안에만 존재하면 어느 순간 압축될 때 사라진다. 그래서 이 모든 것을 작업 디렉터리에 기록하고, 복구 시에는 파일을 읽지 모델이 앞 문맥에 대해 가진 인상을 읽지 않는다.

올바른 인도: 모든 판단이 사실과 대조하여 검증 가능해야 한다

문제 해결 방법 일반적인 경험으로 이 업무의 규칙을 대체함 현재 업무의 규칙을 읽고, 규칙의 적용 범위와 출처를 확인함 설계도가 불완전한데 Agent가 스스로 인터페이스를 추측함 설계 원천으로 돌아가 설계를 가져오고, 컴포넌트 상태와 시각 규격을 하나씩 대조하며, 없으면 물어봄 존재하지 않는 API를 만들어내거나 이미 있는 컴포넌트를 중복으로 만듦 착수 전에 현재 코드, 기존 컴포넌트, 인터페이스 정의를 먼저 확인함 한 플랫폼의 작성 방식을 다른 플랫폼에 그대로 옮김 업무 동작은 재사용하되, 각 플랫폼 자체의 아키텍처와 코딩 제약을 각각 준수함 테스트는 통과했지만 실제 요구사항을 커버하지 못함 인수 기준에 따라 항목별로 검증을 배치하고, 커버하지 못한 항목을 명확히 나열함

이 다섯 가지 문제에는 하나의 공통된 실패 패턴이 있다. 일반적인 경험으로 구체적인 사실을 대체하는 것이다. 추측이 설계 원천을 대체하고, 기억 속의 API가 현재의 인터페이스 정의를 대체하며, 테스트 통과가 인수 커버리지를 대체한다.

이는 또한 첫 절과 호응한다. Agent가 참여하는 고리가 많을수록 얻을 수 있는 사실이 많아지고, 경험에 의존해 추측해야 하는 지점은 줄어든다.

두 목표의 공통 원칙

두 표에 담긴 해결 방법 뒤에는 같은 원칙이 있다. 판단 근거는 디스크에 기록된 사실에 두고, 채팅 기억에 근거하지 않으며, 모델의 자기 진술에도 근거하지 않는다.

두 목표는 「완료」 판정에서 교차한다. 검증 통과는 제출 완료를 의미하지 않고, 제출 완료는 배포 완료를 의미하지 않으며, 권한을 얻지 못한 외부 동작은 명확히 미실행으로 적어야 한다. 제07편에서 이 판정 방식을 펼쳐 설명한다.

아키텍처 계층화: Coding Agent 호스트, CLI와 Agent

Claude Code, Codex 같은 Coding Agent 호스트가 이미 이렇게 많은 메커니즘을 제공하고 있으니, 전체 흐름을 곧바로 그 안에 작성하자는 자연스러운 발상이 있다. 상태 머신은 하나의 skill로 쓰고, 게이트는 하나의 hook으로 쓰는 것이다. 이 두 방식 모두 구조적인 문제가 있다.

skill의 본문은 모델이 이해한 뒤 실행한다. 동일한 「먼저 A를 검사한 뒤 B로 진행한다」는 설명이라도 서로 다른 워크플로에서 실행 결과가 일치하지 않으며, 모델은 단계를 건너뛰고 컨텍스트 압박 아래에서 검사를 생략한다.

hook의 문제는 다른 쪽에 있다. 그것이 실행되는지 여부는 호스트 버전, 사용자 설정, 신뢰 설정에 따라 달라지며, 같은 설정이 서로 다른 기기에서 모두 실행된다는 보장이 없다.

그래서 세 층으로 나누고, 각 층의 책임은 「매번 결과가 일치해야 하는지」에 따라 구분한다.

- Coding Agent 호스트는 실행 능력과 최후 보루를 담당한다. 세션, 도구, 권한 상한, 서브 에이전트의 생명주기, 외부 연결은 호스트가 제공하고, hook은 시작, 압축 복구 등의 시점에 최소 컨텍스트를 주입하고 명백한 위험 동작을 차단하지만, 상태를 진행시키지 않고 사용자 권한을 대신하지 않으며, 한 줄의 프롬프트만으로 작업 완료를 선언하지도 않는다.

- CLI는 상태와 결정론적 검증을 담당한다. 실행 상태의 읽기·쓰기, 단계 진행, 산출물 등록, 각종 검사는 모두 일반 명령어로, 같은 입력에 같은 출력을 얻으며, 버전은 한 번의 실행에 따라 고정된다.

- Agent는 판단과 구성을 담당한다. 요구사항 이해, 작업 분해, 역할 선택, 실패 후 수정 경로 결정, 언제 반드시 사람에게 물어야 하는지 판단하는 것은 이해와 취사선택이 필요하다.

각 호스트 메커니즘이 이 체계 안에서 구체적으로 무엇을 관리하는지, Claude Code와 Codex 양쪽의 설정과 동작에 어떤 차이가 있는지는 제01편에서 대조표 하나로 항목별로 설명한다.

AI-SDLC 자동화 정도를 측정하는 네 단계 사다리

AI-SDLC의 자동화 정도를 측정할 때는 사람이 무엇을 하고 있는지를 본다. 이 기준에 따라 네 단계로 나눌 수 있다.

- L0 전 수작업: 사람이 코드를 작성한다.

- L1 Spec Driven Development: 사람이 spec을 작성하고 수문장 역할을 하며, 하나의 표준 흐름에서 사람이 일곱 개 정도의 노드에서 확인해야 Agent가 계속 진행할 수 있다.

- L2 Harness 플라이휠: 사람은 제약 자체(규칙, skill, 역할, hook)만 조정하고, Agent는 제약 안에서 전체 흐름을 전자동으로 실행하며, 실행 궤적과 평가 결과가 사람에게 환류된다.

- L3 자기 진화: Agent가 실패 궤적에서 새 규칙을 초안하고, 사람이 승인하면 업그레이드되며, 지표가 퇴화하면 롤백한다.

상위 단계에서 축적된 spec, 규칙, 패턴이 하위 단계의 원재료이며, 네 단계 사이는 축적 관계이지 대체 관계가 아니다.

대부분의 팀은 현재 L1에 있고, 가장 쉽게 건너뛰는 것은 L2다. 자기 진화의 전제는 한 번의 수정이 결과를 더 좋게 만들었는지 판단할 수 있는 것인데, 이에는 안정적인 측정, 재현 가능한 평가, 단일 변수 대조가 필요하다. 이것들이 없으면 이른바 자기 진화는 그저 규칙이 무작위로 표류하는 것일 뿐이다.

그래서 이 시리즈의 중심은 L2에 필요한 엔지니어링 설비에 둔다.

시리즈 편 소개

시리즈는 인도 단계에 따라 펼쳐지며, 베이스와 횡단 역량은 별도 편으로 구성한다.

각 단계 편은 같은 질문 묶음에 답한다. Agent가 이 단계에서 어떤 컨텍스트를 받고, 무엇을 하며, 무엇을 산출하고, 사람이 어디서 의사결정하며, 어떻게 검사하고, Claude Code와 Codex의 어느 메커니즘에 대응하는지.

편 주제 00 총강: AI-SDLC란 무엇이며, 왜 해야 하는가 01 메커니즘 지도: 여섯 가지 메커니즘이 각각 무엇을 담당하는지, 하나의 자산 세트가 어떻게 두 개의 호스트에서 구동되는지 02 프로세스 토대: 단계 계약, 상태 머신과 복구 03 요구사항 이해: 요구사항 문서, 디자인 시안, 저장소의 사실을 유일한 스펙으로 수렴시키기 04 방안 설계와 리뷰: 방안을 실행 가능한 작업 그래프로 바꾸기 05 개발: 다중 Agent가 작업 그래프에 따라 병렬로 06 검증과 연동 테스트: 동결된 후보 버전에서 마무리 07 전달: 동작별 승인, 부분 완료는 완료로 보고하지 않음 08 지식: 계층적 읽기, 전달에 따라 회신(回寫) 09 측정과 평가: 이 프로세스가 좋아졌음을 어떻게 증명할 것인가 10 플러그인화: 하나의 프로세스로 여러 팀에 서비스하기 11 플라이휠: 매번 전달 과정의 문제를 Harness로 다시 침전시키기

메커니즘 자체의 기초 지식(hook에는 어떤 이벤트가 있는지, skill은 어떻게 작성하는지)은 이전의 Harness Engineering 시리즈에서 다루었으므로, 본 시리즈에서는 바로 인용하고 이 메커니즘들이 어떻게 조합되어 하나의 전달 파이프라인을 이루는지만 논의한다.

다음 편에서는 메커니즘 지도를 그린다: Agent, Skill, Hook, MCP, 진입 파일과 설정, Checker 여섯 가지 메커니즘이 각각 무엇을 담당하는지, 그리고 하나의 자산 세트가 어떻게 Claude Code와 Codex에서 동시에 구동되는지.

ZzT

모바일 @水团子

109

글

154k

조회수

165

팬