저는 자율형 AI 에이전트(AI Agents)를 활용하여 4번의 스프린트(sprints) 만에 완전한 교육 애플리케이션을 인도했습니다. 51개의 스토리(stories), 68개의 E2E 테스트, 5개의 사용자 여정(journeys). 수동 테스트에서 발견된 회귀 버그(regression bug)는 0건이었습니다. 이 모든 과정은 에이전트의 몇 시간 작업만으로 이루어졌으며, 감독과 최종 테스트를 제외한 인간의 작업은 없었습니다.

이 경험에서 제가 주목하는 것은 속도가 아닙니다. 그것을 가능하게 만든 요소, 즉 지난 20년 동안 우리가 사용해 온 프로젝트 관리 방식(제품 비전, 스토리 분할, 자동화 테스트, 품질 게이트(quality gates))을 정확히 그대로 적용했다는 점입니다. 다만 이를 개발자 팀에 적용하는 대신, 에이전트에게 적용했을 뿐입니다.

문맥(Contexte)

이 기사는 실제 환경에서의 에이전틱 AI(agentic AI)에 관한 시리즈의 일부입니다. 이 주제에 관심이 있다면, Le monorepo-mémoire : le vrai levier n'est pas le prompt 기사가 이 접근 방식의 토대를 제공합니다.

문제점: 두 가지 잘못된 선택지

기능 세트를 개발하기 위해 에이전틱 AI(agentic AI)를 사용할 때, 일반적으로 두 가지 선택지가 있지만 둘 다 만족스럽지 않습니다.

첫 번째는 기능별(feature par feature) 방식입니다. 에이전트에게 하나의 스토리(story)를 맡기고, 수동으로 테스트하고, 수정하고, 다음 단계로 넘어가는 방식입니다. 결과는 좋지만, 에이전트는 시간의 80%를 인간이 테스트하기를 기다리는 데 소비합니다. 밤이나 주말, 혹은 우리가 다른 프로젝트를 하고 있을 때 에이전트는 아무것도 하지 않습니다. 이는 상당한 시계 시간(clock time)의 낭비입니다.

두 번째는 한꺼번에(tout d'un coup) 방식입니다. 모든 기능을 한 번에 실행하고 나중에 돌아오는 방식입니다. 문제는 테스트해야 할 코드의 산더미를 마주하게 된다는 점입니다. 마치 휴가에서 돌아온 프로덕트 오너(Product Owner)가 칸반(Kanban) 보드에서 30개의 스토리가 "제품 QA(Product QA)" 상태로 쌓여 있는 것을 발견하는 것과 같습니다. 팀은 매우 잘 진행했고 단위 테스트(unit tests)는 통과했지만, 사용자 여정(user journey)이 처음부터 끝까지 제대로 작동하는지 확인하기 위해 버튼을 한 번도 클릭해 본 사람이 없는 상황과 같습니다.

제3의 길이 필요했습니다. 그리고 4번의 프로덕션 스프린트(sprints)를 거친 후, 저는 이 제3의 길이 실제로 작동한다는 것을 말할 수 있습니다.

방법론: 3계층 하네스 (3-layer harness)

이론은 간단합니다. 에이전트에게 개발해야 할 스토리(stories)뿐만 아니라, 자신의 작업이 올바른지 스스로 확인할 수 있는 기준을 제공하는 것입니다. 단순히 "코드가 컴파일되는가"가 아니라 "사용자 여정(user journey)이 작동하는가"를 확인하는 것이죠.

구체적으로, 저는 세 개의 보안 계층을 쌓아 구축했습니다.

계층 1: 정적 분석(static analysis) 및 단위 테스트(unit tests). 이는 최소한의 요구사항입니다 — PHPStan, TypeScript strict, PHPUnit 등이 포함됩니다. 에이전트는 각 스토리 이후에 이를 실행합니다. 만약 결과가 실패(red)라면, 다음 단계로 넘어가기 전에 수정합니다. 여기서 새로운 것은 없습니다. 이는 모든 개발 팀이 당연히 해야 하는 일입니다.

계층 2: 스토리당 하나의 Playwright E2E 테스트. 각 스토리에는 수락 기준(acceptance criteria)을 검증하는 실제 브라우저 테스트가 동반됩니다. 프론트엔드 단위 테스트가 아니라, 로그인, 탐색, 동작, 확인을 포함하는 전체 여정(complete parcours)입니다. 에이전트는 이 테스트를 직접 작성하고 실행까지 완료합니다.

계층 3: 스토리 간 여정 테스트(cross-stories journey tests). 여기서부터 흥미로워집니다. 코딩을 시작하기 전에, 견적서 생성부터 교육 증명서 발송까지 제품 전체를 관통하는 3가지 엔드 투 엔드(end-to-end) 시나리오를 작성했습니다. 이 테스트들은 초기에는 비활성화(test.fixme) 상태입니다. 에이전트가 진행함에 따라, 자신이 맡은 스토리가 해제하는 단계들을 활성화합니다. 만약 이후의 스토리로 인해 여정 테스트가 깨지면, 에이전트는 즉시 이를 수정합니다.

각 스토리에 대한 에이전트의 프로토콜은 다음과 같습니다:

1. 스토리와 수락 기준(acceptance criteria)을 읽는다
2. 백엔드(backend) + 프론트엔드(frontend)를 구현한다
3. 해당 스토리의 E2E 테스트를 작성한다
...

황금률은 냉혹합니다. 테스트가 실패(red) 상태라면 절대 다음 스토리로 넘어가지 마십시오.

실제 적용 사례: 4번의 스프린트 (sprints)

최종 범위(scope)는 내 CRM을 위한 완전한 교육 애플리케이션인 academie.alva.do입니다. 모든 것을 한 번에 시작하는 대신, 작업을 4개의 순차적인 스프린트로 나누었으며, 각 스프린트는 Docker 컨테이너 내의 자율형 에이전트(autonomous agent)에게 맡겼습니다.

첫 번째 에이전트를 실행하기 전, 약 2시간 동안 기반을 다지는 준비 작업을 거쳤습니다. 비전을 설명하는 3페이지 분량의 PRD(제품 요구 사항 문서), 수락 기준(acceptance criteria)이 포함된 18개의 상세 스토리, fixme 모드로 작성된 3개의 테스트 저니(test journey), 모든 도구(PHP, Node, Playwright, Chromium)가 포함된 Dockerfile, 테스트 데이터를 생성하는 시드(seed) 명령어, 그리고 게이트별(gate by gate) 프로토콜을 설명하는 200줄 분량의 프롬프트(prompt)를 준비했습니다.

스프린트 1 — 기반이 되는 EPIC : 기초를 위한 18개의 스토리(주간 보고서, 교육 세션, 협약, 디지털 출석부, 교육생 앱, 공유 문서). 에이전트 작업 시간 1시간 20분. 결과: 완전한 새로운 웹 앱, 25개의 API 엔드포인트(endpoints), 275개의 단위 테스트(unit tests).

스프린트 2 — 프레젠테이션 : 교육 프로그램을 위한 11개의 MDX 프레젠테이션(각각 45분 분량, 15개 슬라이드). 에이전트는 단순한 코드가 아닌 교육 콘텐츠를 생성했습니다. 각 프레젠테이션이 컴파일되고 표시되는지 확인하는 33개의 E2E 테스트.

스프린트 3 — 퀴즈 인프라 : 데이터 모델(Quiz, QuizAnswer), API(18개 엔드포인트), 실시간 순위가 포함된 서버 측 스코어링(scoring), CSV 내보내기, 강사용 관리 인터페이스. 14개의 E2E 테스트 + 11개의 단위 테스트.

스프린트 4 — 인터랙티브 경험 : 애니메이션 타이머가 포함된 전체 화면 퀴즈 페이지, 메달이 포함된 실시간 순위, 질문별 상세 결과, 익명 ROTI(Return on Time Invested), 인사 담당자(RH)를 위한 PDF 내보내기. 21개의 E2E 테스트 + 1개의 전체 저니(journey).

4번의 스프린트 후의 결과:

중요한 점 하나: 저는 더 이상 코드를 읽지 않습니다. 4번의 스프린트 동안 코드를 읽지 않았고, 그 이후에도 읽지 않을 것입니다. 이것은 태만이 아닙니다. 3개 계층의 테스트가 저 대신 검증 작업을 수행하기 때문입니다. 5개의 저니 테스트 (journey tests)가 통과한다면, 이는 사용자가 로그인하고, 타이머와 실시간 순위가 포함된 퀴즈에 참여하며, 출석을 확인하고, 자신의 결과를 볼 수 있음을 의미합니다. 이는 그 어떤 수동 코드 리뷰 (manual code review)보다 더 신뢰할 수 있습니다.

무엇이 실패했는가 (그리고 그것이 우리에게 가르쳐준 것)

스프린트 1에서 모든 것이 한 번에 작동한 것은 아닙니다. 에이전트(Agent)는 견고한 백엔드(Backend)와 함께 18개의 스토리를 전달했지만, 저니 테스트를 "범위 외 (out of scope)"라고 판단했습니다. 그것은 잘못된 판단이었고, 저는 에이전트를 다시 실행했습니다. 두 번째 실행(run)에서는 시드(seed)에 버그가 있었습니다. 에이전트가 컨트롤러(controllers)를 읽는 대신 API 필드 이름을 추측해 버린 것입니다. 이는 개발자가 문서를 읽지 않고 API를 대상으로 코딩하는 것과 같습니다. 아키텍처상의 지름길(슬라이드의 네이티브 렌더링 대신 iframe 사용)을 수정하기 위해 세 번째 프롬프트(prompt)가 필요했습니다.

놀라운 점은 그 이후의 과정입니다. 스프린트 2, 3, 4는 실행 중 인간의 개입 없이 각각 **단 한 번의 실행 (single run)**으로 완료되었습니다. 모든 게이트(gates) (PHPStan, PHPUnit, TypeScript, Playwright)가 단 한 번에 통과되었습니다. 이유는 간단합니다. 각 스프린트가 이전 단계의 교훈을 활용했기 때문입니다. 프롬프트는 정교해졌습니다. 가드레일(guardrails)은 더 명확해졌습니다 ("이스케이프된 유니코드 문자를 사용하지 마시오", "각 스토리 후에 git commit을 수행하시오"). 테스트 하네스(test harness)는 더욱 풍부해졌습니다.

워커(worker) 인프라 또한 진행 과정에서 진화했습니다. 첫 번째 스프린트에서는 실행할 때마다 클론(clone)을 삭제하는 단순한(naïve) 스크립트를 사용했는데, 이로 인해 의존성(dependencies)을 재설치하는 데 10분이 낭비되었습니다. 이전 프로젝트에서 영감을 얻어, 저는 지속 가능한 클론(persistent clones)과 워커 간에 공유되는 pnpm 스토어(store)를 사용하여 시스템을 다시 작성했습니다. 결과적으로, 워커의 두 번째 실행은 10분 대신 15초밖에 걸리지 않습니다.

4번의 스프린트 동안 총 소요된 시간은 에이전트 작업 몇 시간, 인간의 시간(설정, 감독, 수동 테스트, UX 수정) 약 반나절이었습니다. 좋은 소식은 각 수정 사항이 이후 과정을 위해 시스템을 더욱 견고하게(robust) 만들었다는 점입니다. 에이전트는 테스트 환경에서 Google Drive를 대체하기 위해 스스로 "더미(bouchon)" 서비스를 생성했는데, 이는 외부 설정 없이 모든 테스트를 실행할 수 있게 해주는 패턴입니다.

진짜 교훈: 순차적 스프린트(sequential sprints)

순차적 스프린트로 나누는 것은 처음에 계획된 것이 아니었습니다. 처음에는 모든 것을 단 하나의 프롬프트(prompt)로 처리하고 싶었습니다. 하지만 스프린트 1 이후, 패턴이 명확해졌습니다. 각 스프린트는 이전 것을 기반으로 구축되어야 하며, 한 번에 모든 것을 하려고 해서는 안 된다는 것입니다.

스프린트 1 (백엔드 + 앱) → 스프린트 2 (콘텐츠) → 스프린트 3 (퀴즈 인프라) → 스프린트 4 (대화형 UX). 각 스프린트는 이전 스프린트의 코드, 테스트 및 컨텍스트(context)를 상속받습니다. 스프린트 3의 에이전트는 스프린트 2의 에이전트가 생성한 문서를 읽을 수 있습니다. 스프린트 4의 에이전트는 스프린트 3의 에이전트가 생성한 엔드포인트(endpoints)를 재사용할 수 있습니다.

이는 인간 팀과 동일한 원리입니다. 한 명의 개발자에게 아키텍처, 콘텐츠, 인프라, 프론트엔드를 동시에 수행하라고 요구하지 않습니다. 단계를 나누고, 순서를 정하고, 매 단계마다 검증합니다. 차이점은 여기서 각 "개발자"는 인간이 2~3주 걸릴 일을 30분 만에 해내는 에이전트라는 점입니다.

왜 모범 사례(best practices)가 더 중요해지는가, 덜 중요해지는 것이 아니라

이러한 경험적 피드백은 하나의 강력한 확신을 뒷받침합니다. 즉, 에이전트 기반 AI (Agentic AI)가 프로젝트 관리의 모범 사례 (best practices)에 대한 필요성을 없애는 것이 아니라, 오히려 그 중요성을 더욱 높인다는 점입니다.

PRD (제품 요구사항 문서)가 없다면, 에이전트는 공허 속에서 코드를 작성합니다. 세분화된 스토리 (stories)가 없다면, 에이전트는 일관성 없는 아키텍처 (architectural) 선택을 합니다. 자동화된 테스트 (automated tests)가 없다면, 컴파일은 되지만 엔드 투 엔드 (end-to-end)로 작동하지 않는 코드를 생성합니다. 품질 게이트 (quality gates)가 없다면, 회귀 (regressions) 오류가 조용히 쌓여갑니다. 그리고 스프린트 (sprints) 단위의 분할이 없다면, 중간에 경로를 이탈한 에이전트는 단 하나의 스프린트가 아닌 전체 작업량을 낭비하게 만듭니다.

제가 교육 (formation)에서 사용하는 비유는 지휘자에 관한 것입니다. 지휘자는 악기를 연주하지 않지만, 지휘자가 없다면 오케스트라는 불협화음을 냅니다. PRD는 악보입니다. 스토리는 마디입니다. 테스트는 리허설입니다. 에이전트는 오케스트라입니다. 그리고 당신은 지휘자입니다.

AI와 함께 변화하는 것은 오케스트라가 100배 더 빠르게 연주한다는 점입니다. 변하지 않는 것은, 정확하게 연주하기 위해서는 반드시 악보가 필요하다는 사실입니다.

인간이 더 잘하는 것 (그리고 계속해야 하는 것)

68개의 E2E 테스트는 통과(green) 상태입니다. 5개의 사용자 여정 (journeys)도 통과했습니다. 메커니즘은 작동합니다. 하지만 에이전트가 검증할 수 없는 영역이 남아 있으며, 이를 명확히 정의하는 것이 중요합니다.

첫 번째는 **UX적 느낌 (feeling UX)**입니다. 4번의 스프린트가 끝난 후, 저는 한 시간 동안 강사의 입장과 교육생의 입장이 되어 애플리케이션을 탐색했습니다. 퀴즈 타이머가 카운트다운 방식(15 → 0)으로 되어 있었는데, 이는 속도 경쟁이 아니기에 카운트업(증가하는 방식)으로 변경했습니다. 교육생들이 특정 질문에서 "함정!"이라는 배지를 보게 되어 있었는데, 이는 교육적 가치가 없었기에 제거했습니다. 순위표에 응답 시간이 표시되어 불필요한 압박을 주고 있었기에 숨김 처리했습니다. 이러한 유형의 수정 사항 6건은 모두 수동 테스트 (manual test)에서 발견되었으며, 자동화된 테스트로는 전혀 감지할 수 없었습니다.

다음은 정보 설계 (Information Design) 단계입니다. 에이전트는 강사 인터페이스에 "발표 (Presentations)"와 "퀴즈 (Quiz)"라는 두 개의 분리된 블록을 생성했습니다. 실제로 강사는 "프로그램 (programme)" 단위로 사고합니다. 즉, 첫째 날 아침에 "프로젝트 메모리 (Mémoire du projet)" 발표를 진행하고, 바로 직후에 그에 상응하는 퀴즈를 진행한다는 것을 알고 있습니다. 저는 이 두 가지를 일별 및 반일별로 그룹화된 단일 "프로그램 (Programme)" 블록으로 통합했습니다. 이러한 구조적인 결정은 에이전트로부터 나올 수 없는 것이었으며, 도메인 지식 (understanding of the business)에서 비롯된 것입니다.