에이전트가 20분 만에 작동하는 코드를 만들어냈다. 그런데 아무도 그게 맞는 걸 만든 건지 확신하지 못한다. 요구사항은 여전히 느슨한 산문으로 남아 있고, 리뷰어는 diff를 보며 의도를 역추적하고 있고, 테스트는 코드 짠 에이전트가 스스로 작성했다. 이게 지금 많은 팀이 '에이전트 도입했다'고 부르는 상태다.
dev.to에 게재된 ADLC 분석 글은 이 상황을 명확하게 진단한다. 문제는 속도가 아니라 구조라고. 에이전트를 기존 SDLC의 '구현' 박스 안에 집어넣고 나머지를 그대로 두면, 빠른 에이전트 주변에 슬로우 레인이 생긴다. 2주 스프린트는 8개 변경사항을 담도록 설계됐는데, 이제 40개가 쌓인다. 병목이 사람의 속도에서 프로세스의 설계로 이동한 것이다.
그래서 등장한 개념이 ADLC(AI-Driven Development Lifecycle)다. AWS가 공식 DevOps 블로그에서 제시한 이 프레임워크는 세 단계로 구성된다. Inception(AI가 비즈니스 의도를 요구사항으로 변환, 팀 전체가 실시간 검증), Construction(AI가 아키텍처·코드·테스트를 제안, 팀이 기술 결정에 실시간 개입), Operations(이전 단계 컨텍스트를 바탕으로 AI가 인프라와 배포 관리). 세 단계 모두를 관통하는 원칙은 하나다. AI가 계획하고 실행한다. 인간이 결정한다.
이 프레임워크에서 가장 주목할 변화는 두 가지 아티팩트의 위상이 달라진다는 점이다. 스펙(specification)과 평가셋(eval set)이 릴리스 사이에 썩어가는 문서가 아니라, 프로젝트의 핵심 영구 자산이 된다. 코드 재생성은 이제 저렴한 단계다. 비싼 단계는 검증이다. 따라서 스펙이 정밀할수록, 평가셋이 촘촘할수록 전체 루프의 품질이 올라간다. 실패 루프가 코드로 돌아가지 않고 스펙으로 돌아간다는 것도 여기서 나온다.
그렇다면 이 루프를 물리적으로 어떻게 구현하나. Google ADK 팀이 소개한 하네스 엔지니어링(Harness Engineering) 개념이 바로 이 질문에 답한다. 하네스는 에이전트를 감싸는 결정론적 구성 요소들의 집합이다. 오케스트레이션 레이어, 실행 샌드박스, 상태 저장, 검증 도구. 에이전트가 아무리 강력해도 하네스 없이는 레이스트랙 없는 경주마다.
하네스 설계의 핵심은 세 가지다. 첫째, 엄격한 경계 설정. 에이전트가 접근할 수 있는 파일과 디렉터리를 명시적으로 제한한다. 추측으로 건드리다 프로덕션 데이터를 날리는 상황을 구조적으로 막는다. 둘째, 리페어 루프(Repair Loop). 빌드 실패나 테스트 실패가 발생하면 에러 로그를 정제해서 에이전트에게 자동으로 피드백한다. 인간이 에러를 복붙해서 다시 프롬프트 치는 단계를 제거한다. 셋째, 킬 스위치. 에이전트가 무한 루프에 빠졌을 때 하네스가 자동으로 중단시킨다. OpenAI의 사례에서 0줄의 수동 코드로 내부 베타 제품을 출시한 3인 팀이 실제로 작성한 것도 앱 로직이 아니라 이 하네스였다.
이게 추상적으로 들린다면, Claude Code 실사용 사례가 구체적인 그림을 준다. 브라우저 레이싱 게임 프로젝트에서 개발자는 단 한 문장을 입력했다. "make it AAA quality." Claude Code는 먼저 2,028줄짜리 단일 파일을 14개 모듈로 분리했다. 그 다음 5개의 병렬 에이전트를 스폰해서 각 모듈 그룹을 동시에 작업했다. 브라우저에서 직접 확인할 수 없는 환경이었기 때문에, 검증은 node --check와 커스텀 node 하네스로 처리했다. 자동차 물리 37개 어서션, 모듈 간 경계 173개 어서션. 에이전트가 만든 코드를 에이전트 없이 검증하는 구조를 먼저 갖춰야 에이전트를 마음 놓고 돌릴 수 있다는 걸 이 사례는 보여준다.
이 케이스에서 가장 솔직한 교훈은 따로 있다. 2백만 토큰을 썼는데, 사용자가 체감한 가장 큰 차이는 물리 엔진이나 사운드가 아니라 조명을 껐을 때였다고 한다. 에이전트가 무엇을 만들어야 하는지보다 결과물이 어떻게 보여야 하는지를 먼저 결정하는 것이 실제로 더 중요하다는 뜻이다. 프롬프트보다 평가 기준이 먼저다.
세 사례를 엮으면 팀 리드가 지금 당장 해야 할 일의 윤곽이 나온다. ADLC 프레임워크가 '무엇을'을 알려준다면, 하네스 엔지니어링은 '어떻게'를 알려주고, Claude Code 사례는 '실제로 어디서 막히는지'를 보여준다.
팀 리드가 설계해야 할 세 가지 레이어:
- 의도 레이어 — 에이전트가 플래닝을 시작하기 전에 스펙과 접근 범위를 확정한다. 느슨한 한 줄짜리 태스크는 에이전트가 아니라 프로세스의 실패다.
- 실행 레이어 — 샌드박스 경계, 리페어 루프, 킬 스위치. 에이전트가 혼자 고칠 수 있는 구조를 만들면 인간 리뷰는 최종 판단에만 집중할 수 있다.
- 검증 레이어 — 평가셋을 코드와 같은 수준의 1급 아티팩트로 관리한다. 검증 기준이 명확해야 재생성 루프가 수렴한다.
ADLC가 스프린트를 '볼트(bolt)'로 대체하는 이유도 같은 맥락이다. 스프린트가 2주인 건 사람이 구현하는 데 그만큼 걸리기 때문이었다. 에이전트가 몇 시간 안에 구현을 마친다면, 사이클의 단위가 바뀌어야 한다. 그리고 그 짧은 사이클을 안전하게 돌리려면 각 루프마다 검증이 자동화되어 있어야 한다. 세레모니가 줄어드는 게 아니라, 세레모니가 코드로 이식된다.
팀을 AI-First로 리빌딩한다는 건 에이전트를 도입하는 게 아니다. 에이전트가 안전하게 실행될 수 있는 레일을 설계하는 것이다. 가장 빠른 팀은 에이전트가 가장 많은 팀이 아니라, 에이전트가 혼자 고치고 검증하고 다음 단계로 넘길 수 있는 하네스를 먼저 구축한 팀이다. 팀 리드의 역할은 코드를 덜 쓰는 게 아니라, 구조를 더 잘 설계하는 것으로 이동하고 있다.