에이전트는 어떤 개발 사이클을 따르는가

평가셋에서 90점을 받고 배포한 에이전트가 다음 주에는 같은 입력에 다른 답을 돌려줍니다. 코드는 한 줄도 바뀌지 않았습니다.

무엇을 배포하는지가 달라졌습니다

SDLC(소프트웨어 개발 생애주기)는 코드가 시스템의 동작을 결정한다는 전제에서 출발합니다. 같은 실행 파일에 같은 입력을 주면 같은 결과가 나오고, 동작을 바꾸려면 코드를 바꿔야 한다는 것입니다. 명세 작성부터 구현, 테스트, 배포까지 이 전제를 따릅니다.

에이전트를 배포할 때는 코드뿐 아니라 프롬프트, 스킬, 검색으로 가져오는 컨텍스트, 도구 스키마, 미들웨어, 모델까지 함께 고려해야 합니다. 이 중 하나만 바뀌어도 에이전트의 동작이 달라질 수 있습니다.

평가셋에서 받은 90점이 다음 주에도 유지되리라는 보장은 없습니다. 모델 제공자가 가중치를 미세하게 조정했거나, 검색 인덱스가 갱신됐거나, 외부 도구의 응답 형태가 달라졌을 수 있기 때문입니다.

LangChain은 이런 특성을 고려해 Agent Development Lifecycle(ADLC)을 정리했습니다. SDLC와 단계 이름은 비슷하지만, 코드 외에도 관리할 대상이 늘어난 만큼 각 단계에서 해야 할 일이 달라집니다.

단계 이름이 같아도 다루는 대상이 다릅니다

ADLC는 Build(구축), Test(평가), Deploy(배포), Monitor(모니터링), Iterate(개선)를 반복합니다. Govern(거버넌스)은 이 모든 단계에서 비용과 권한 등을 관리하는 일입니다.

• Build에서는 코드를 작성하고 프롬프트와 스킬, 도구, 미들웨어를 함께 구성합니다. 도메인 전문가도 프롬프트와 스킬을 직접 편집하므로 개발자만의 일이 아닙니다.
• Test에서는 단위 테스트와 통합 테스트에 더해 평가셋, 기준에 따른 채점, 여러 차례 대화를 주고받는 시뮬레이션을 활용합니다. 정답이 하나인 작업은 정답과 비교합니다. 여러 답이 가능한 작업은 근거를 제시했는지, 정책을 지켰는지, 불필요한 도구를 호출하지 않았는지 평가합니다.
• Deploy에서는 코드와 함께 장시간 작업을 이어 갈 수 있는 실행 환경, 샌드박스, 컨텍스트를 관리하는 허브도 배포합니다. 에이전트는 오래 실행되고 도중에 사람의 결정을 기다리기도 하므로, 실행 상태를 저장했다가 재개할 수 있어야 합니다. 프롬프트와 컨텍스트는 코드와 별도로 배포합니다.
• Monitor에서는 응답 시간과 오류율에 더해 모델과 도구의 호출 기록인 트레이스(trace)도 확인합니다. HTTP 200 OK 응답을 받았다고 작업에 성공한 것은 아닙니다. 어떤 모델과 도구를 호출해 그 결과에 도달했는지까지 살펴봐야 합니다.
• Iterate는 SDLC의 유지보수와 다릅니다. 실제 운영 중에 수집한 트레이스로 평가셋을 보완하고, 이를 다음 평가에 사용해 개선에 반영하는 과정을 반복합니다.

Govern에서는 비용과 도구 접근 권한을 관리하고, 어떤 작업에 사람의 승인이 필요한지 정합니다. 프롬프트와 스킬을 쉽게 찾고 재사용할 수 있도록 관리하는 일도 포함됩니다. 에이전트 하나를 운영할 때는 간단히 처리할 수 있지만, 조직에서 여러 에이전트를 운영하려면 이를 공통으로 관리할 체계가 필요합니다.

운영하면서 배운 것을 평가와 개선에 반영합니다

에이전트의 동작이 달라졌을 때는 변경 이력만으로 원인을 찾기 어렵습니다.

전통적인 시스템에서는 커밋과 릴리스 노트, git blame을 통해 어제와 오늘의 동작이 왜 다른지 추적했습니다. 에이전트가 사용하는 모델의 가중치나 외부 도구의 응답 형태가 바뀌어도 우리 저장소의 커밋 이력에는 남지 않습니다.

에이전트를 운영하는 일은 신입 사원을 가르치는 일과 비슷합니다. 직무기술서만으로 그 사람의 모든 판단을 정할 수는 없습니다. 처음에는 수습 과제로 업무를 익히게 하고, 일을 시작하면 결과뿐 아니라 판단 과정도 함께 살펴봅니다. 에이전트의 평가셋과 트레이스도 이런 역할을 합니다. 한 번 잘못 판단했다고 해고하기보다는 다음에 더 잘할 수 있도록 코칭합니다. 그 사람이 어떻게 일하는지 알아갈수록 더 어려운 과제도 맡길 수 있습니다.

신입 사원은 경험을 통해 스스로 배우지만, 에이전트는 운영 중에 얻은 경험을 저절로 익히지 않습니다. 운영하는 사람이 그 경험을 프롬프트와 스킬, 컨텍스트, 평가셋에 반영해야 합니다. ADLC에서는 운영 중에 트레이스를 수집하고, 평가셋에 추가하고, 평가 결과에 따라 프롬프트를 고치는 과정을 반복합니다. 이 과정을 이어 갈 수 있도록 운영 체계를 갖추는 일도 우리의 책임입니다.

평가와 운영을 개발 과정에 포함해야 합니다

이 과정을 실제로 반복하려면 개발 초기부터 다음을 준비해야 합니다.

• 평가셋은 개발 첫날부터 관리합니다. 출시 직전에 한 번 검수하는 데 그치지 않고, 첫 커밋을 작성할 때부터 평가셋도 함께 만듭니다. 운영 중에 수집한 트레이스를 계속 추가해야 다음 릴리스를 제대로 평가할 수 있습니다.
• 프롬프트와 스킬, 컨텍스트는 코드와 별도로 관리합니다. 버전 관리와 리뷰, 롤백 절차를 각각 마련합니다. 자주 바뀌는 내용을 매번 코드 릴리스에 맞춰 배포해야 하면 개선이 늦어집니다.
• 사람의 승인이 필요한 작업을 정합니다. 사람이 작업 과정에 개입하는 human-in-the-loop은 사용자 경험뿐 아니라 권한 관리와도 관련됩니다. 어떤 작업을 누가 승인했는지 추적할 수 있어야 합니다.
• 실행 중에 발생하는 비용을 관리합니다. 모델을 호출하거나 재시도할 때마다 비용이 듭니다. 분기마다 비용을 검토하는 데 그치지 않고, 릴리스 과정에서도 이를 확인해야 합니다.
• 트레이스를 디버깅과 제품 분석에 활용합니다. 사용자가 무엇을 요청하고, 어디서 막히고, 어떤 결과를 정정하는지 트레이스에 남습니다. 이 기록으로 다음에 개선할 부분을 찾을 수 있습니다.

한 팀이 이 모든 기능을 처음부터 만들 필요는 없습니다. LangSmith, AgentCore, Temporal 같은 도구가 필요한 기능을 제공하고 있습니다. 어떤 도구를 고르든 평가와 승인, 비용 관리, 트레이스 수집을 개발 과정에 포함해야 합니다. 준비하지 않으면 문제가 생길 때마다 개별적으로 해결해야 합니다.

릴리스 노트에 "no code changes"라고 적어도 에이전트의 동작은 달라질 수 있습니다. 그래서 ADLC에서는 코드 머지 이후에도 운영 기록을 수집하고 평가에 반영하는 과정이 이어집니다. 다음 평가에 쓸 데이터는 이미 운영 중인 에이전트의 트레이스에 쌓이고 있습니다. 그 기록을 평가셋으로 옮기고 개선에 활용할 절차가 있는지 확인해야 합니다.