AI 에이전트가 코드 작성과 테스트를 맡는 개발 방식에서는 사람의 역할이 구현에서 요구사항 정의와 설계 검토로 이동한다. Yugabyte의 프린시펄 엔지니어 하리 크리슈나 순다르(Hari Krishna Sunder)는 이를 에이전트 개발 생명주기(ADLC)로 설명하며, 시제품 검증부터 운영 피드백까지 개발 과정에 맞춰 바뀌어야 한다고 제안한다.

순다르는 한 엔지니어링 팀에서 18개월 동안 세 시스템을 구축한 사례를 들었다. 첫 시스템은 설계 문서 작성부터 발표까지 7개월, 두 번째는 4개월이 걸렸다. 세 번째는 첫 논의부터 공개까지 5주가 걸렸고, 12명이 1년간 작업한 앞선 사례와 달리 엔지니어 두 명이 만들었다고 밝혔다.

ADLC는 요구사항, 설계, 코딩, 테스트, 배포, 운영이라는 기존 소프트웨어 개발 생명주기(SDLC)의 단계를 유지하되 각 단계의 실행 주체를 바꾼다. 엔지니어는 의도를 명시하고 승인 관문을 관리하며, 에이전트는 계획을 세우고 코드를 작성·검토하며 테스트를 실행한다. 일부 고도화된 구현에서는 에이전트가 사람의 검토 없이 풀 리퀘스트를 병합하기도 한다.

배포 후에도 생명주기는 이어진다. 에이전트는 변경 사항을 배포하고 운영 신호를 살피며, 장애를 분류하고 수정안을 제안한다. 제안은 다시 검토와 테스트를 거친다. 운영 문제에서 드러난 공백은 새 계약 조항, 회귀 테스트 또는 공유 프로젝트 맥락 업데이트 같은 지속적으로 활용할 자료로 개발 초기 단계에 반영할 수 있다. 이런 피드백 경로가 없으면 같은 종류의 결함을 반복해서 발견하게 된다는 설명이다.

구현 비용이 낮아지면 위험은 허술하게 만드는 데서 잘못된 것을 만드는 쪽으로 옮겨간다. 이에 ADLC는 요구사항 작성 전에 실험 단계를 둔다. 측정 가능한 핵심성과지표(KPI)를 기준으로 가설을 시험하는 시제품을 만들고, 제작 전에 성공 지표와 중단 기준을 정한다. 시제품 비용이 낮으므로 여러 접근법을 병렬로 만들어 같은 지표로 비교할 수 있으며, 요구사항 문서는 가정이 아니라 측정 결과를 토대로 작성한다.

시제품 코드는 폐기할 수 있는 것으로 다뤄야 한다. 작동하는 시제품을 그대로 출시하려는 압력이 생길 수 있지만, 그렇게 하면 이후 생명주기가 의존하는 계약, 검토, 마이그레이션, 테스트를 건너뛰게 된다. 실험을 통과한 설계는 정식 개발 절차에 따라 다시 구현한다.

에이전트가 코드 대부분을 만들면 사람의 검토 역량이 병목이 된다. 풀 리퀘스트가 사람에게 도달하기 전 자동 AI 검토와 수정이 여러 차례 이뤄지고, 저장소 규칙과 코딩 표준을 명문화해 스타일 지적이나 사소한 오류 확인에 드는 부담을 줄인다. 에이전트가 만든 변경 사항을 줄 단위로 검토하는 방식은 확장하기 어렵고 설계 문제를 늦게 발견할 수 있다. 따라서 사람이 에이전트 실행 전에 결과를 좌우할 수 있는 마지막 지점인 설계 검토가 중요해진다. 요구사항과 설계 문서는 구현을 평가하는 계약으로 쓸 수 있을 만큼 정확해야 하며, 이에 따라 설계 검토는 더 길고 까다로워진다.

테스트는 정확성 확인뿐 아니라 에이전트가 작업할 범위를 정한다. 테스트는 ‘완료’의 의미를 정의하고 변경 사항이 의도한 범위를 벗어나면 실패하도록 한다. 계약 기반 설계(Design by Contract)처럼 각 구성 요소가 무엇을 보장하고 무엇은 보장하지 않는지 계약에 명시하면, 약속되지 않은 동작을 다른 팀이 전제로 삼는 일을 막을 수 있다.

단계 간 맥락 전달도 중요하다. 각 에이전트가 직전 단계의 결과만 받으면 입력 뒤에 있는 판단 근거를 처음부터 다시 구성하는데, 순다르는 이를 ‘콜드 스타트’라고 부른다. 기사에 따르면 테스트에서 관련 맥락을 이어받는 ‘웜 핸드오프’는 콜드 스타트보다 비용이 37~45% 적게 들었고, 팀의 판단 근거를 비결정적으로 다시 만드는 일도 피했다. 다만 자료를 많이 넘기는 것보다 관련 있는 맥락을 골라 전달하는 일이 중요하다. 관련 자료가 희석되면 결과 품질은 정점에 이른 뒤 떨어질 수 있다(관련 연구).

전체 대화 기록을 다음 에이전트에 넘기는 방식은 적절하지 않다. 최종 결정과 폐기된 방안을 구별하기 어렵기 때문이다. 대신 다음 작업에 필요한 결정, 제약, 미해결 질문만 공유 맥락에 담고, 어떤 정보를 공유 맥락으로 넘길지 규칙을 명시해야 한다.

엔지니어링 속도가 빨라지면 영업, 마케팅, IT, 법무 등 관련 팀이 다음 병목이 될 수 있다. 순다르는 개발 요구사항과 설계 문서, 릴리스 노트를 공유 맥락으로 제공하면 다른 팀이 회의나 인수인계 문서로 내용을 재구성하지 않고 엔지니어링의 기존 자료에서 출발할 수 있다고 제안한다. 영업 지원 자료, 출시 안내, 계약 검토도 같은 자료를 바탕으로 시작할 수 있다.

그는 팀이 코드 작성보다 결과와 목표, 명확한 기대치를 정하는 데 집중해야 한다고 권고한다. 여기에는 시제품 제작 전 KPI 설정, 비용 최적화를 위한 토큰 사용량 추적, 에이전트 실행을 안내하는 계약 강화가 포함된다. 운영 문제를 개발 생명주기 개선에 활용하고, 공유 맥락을 엔지니어링 외부로 확대해 다른 업무 부문도 빨라진 개발 주기에 맞춰야 한다고 밝혔다.

하리 크리슈나 순다르의 글