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

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

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

SDLC(software development lifecycle)는 코드가 곧 행동이라는 등식에서 출발합니다. 같은 binary는 같은 입력에 같은 결과를 돌려주고, 행동을 바꾸려면 코드를 바꿔야 했습니다. 명세, 구현, 테스트, 배포가 모두 이 전제 위에 짜여 있습니다.

에이전트는 이 등식을 깹니다. production에 올라가는 것은 코드만이 아니라 프롬프트, 스킬, 검색용 컨텍스트, 도구 스키마, 미들웨어, 그리고 그 묶음을 받는 모델까지입니다. 그중 어느 한 축만 바뀌어도 시스템의 행동이 달라집니다.

평가셋 90점이 다음 주에 흔들리는 이유가 이것입니다. 모델 제공자가 가중치를 미세하게 조정했거나, 검색 인덱스가 갱신됐거나, 외부 도구의 응답 형태가 달라졌을 수 있습니다. 코드는 한 줄도 바뀌지 않았는데 시스템은 다른 시스템이 됐습니다.

LangChain이 정리한 Agent Development Lifecycle(ADLC)은 이 사실을 출발점으로 삼습니다. SDLC와 단계 이름이 닮은 곳이 많지만, 다루는 대상이 넓어진 만큼 각 단계의 의미가 다시 짜여 있습니다.

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

ADLC의 사이클은 Build → Test → Deploy → Monitor → Iterate이고, 그 둘레에 Govern이 자리합니다.

• Build는 코드 작성이 아니라 코드 + 프롬프트 + 스킬 + 도구 + 미들웨어의 구성입니다. 도메인 전문가가 프롬프트와 스킬을 직접 편집하는 흐름이 들어오면서, build는 더 이상 한 직군의 일이 아닙니다.
• Test는 unit/integration test 자리에 eval dataset, 기준 평가(criteria-based judging), 멀티턴 시뮬레이션이 함께 들어옵니다. 정답이 하나인 작업은 정답 비교로, 갈래가 여럿인 작업은 "근거를 댔는가, 정책을 지켰는가, 불필요한 도구 호출이 없었는가"로 채점합니다.
• Deploy는 코드 push에 더해 durable runtime, sandbox, context hub가 함께 갑니다. 에이전트는 길게 동작하고 도중에 사람의 결정을 기다리기도 하므로 checkpoint와 resume이 필요합니다. 프롬프트와 컨텍스트는 코드와 별개의 배포 경로를 갖습니다.
• Monitor는 latency·error rate에 더해 trace를 봅니다. 200 OK 응답이 곧 성공이 아니므로, 어떤 모델 호출과 도구 호출의 궤적으로 그 응답에 도달했는지를 같이 들여다봐야 합니다.
• Iterate는 SDLC의 maintenance와 결이 다릅니다. 결함 수정이 아니라 production trace를 다음 dataset으로 끌어와 다음 평가에 붙이는 닫힌 학습 루프입니다.

Govern은 비용, 도구 접근, human-in-the-loop 승인, 그리고 prompt·skill 같은 자산의 검색·재사용까지를 사이클 둘레에 두릅니다. 에이전트 한 개에는 가벼울 수 있지만, 조직이 여러 개를 띄우는 순간 그 자체가 인프라가 됩니다.

학습이 어디에 쌓이는지가 다릅니다

단계 이름보다 더 큰 차이는 따로 있습니다. 코드가 같아도 행동이 달라진다는 사실입니다.

전통적 시스템에서 행동의 변화는 commit으로 추적할 수 있었습니다. release 노트와 git blame이 "왜 어제와 오늘이 다른가"를 설명했습니다. 에이전트에서는 그렇지 않습니다. 모델 가중치가 갱신되고 외부 도구의 응답 형태가 바뀌어도 우리 commit history에는 흔적이 남지 않습니다. 코드는 그대로인데 시스템은 이미 다른 시스템입니다.

신입 사원을 한 명 들이는 일에 가깝습니다. 직무기술서로 그 사람의 모든 결정을 고정할 수 없습니다. 수습 과제 몇 개로 손을 풀게 하고(eval dataset), 일을 시작하면 결과만이 아니라 결정의 과정 하나하나를 같이 들여다봅니다(trace). 나쁜 판단 한 번이 해고가 아니라 코칭으로 이어집니다(iterate). 시간이 갈수록 그 사람이 어떻게 일하는지가 또렷해지고, 그 이해 위에서 다음 케이스를 더 어렵게 던집니다.

다만 신입 사원은 배운 것이 본인 안에 쌓이지만, 에이전트는 그렇지 않습니다. 학습은 우리 쪽에 쌓입니다. 프롬프트, 스킬, 컨텍스트, eval dataset이 그 학습의 형태입니다. 그래서 ADLC는 닫힌 루프(production → trace → dataset → eval → 다음 prompt)를 사이클의 중심에 둡니다. 학습 책임이 시스템 안이 아니라 시스템 바깥, 즉 우리 운영 인프라 위에 놓여 있습니다.

SDLC 바깥에 있던 것을 사이클 안으로 들입니다

이 차이를 운영으로 옮기려면 SDLC 시절에 외곽에 두던 것들을 사이클 안쪽으로 들여와야 합니다.

• 평가는 첫날부터 인프라로 둡니다. 출시 전 QA 한 번이 아니라, 첫 commit 옆에 평가셋이 같이 자리합니다. dataset이 production trace와 함께 자라야 다음 release를 신뢰할 수 있습니다.
• 프롬프트·스킬·컨텍스트는 코드와 분리된 자산으로 다룹니다. 별도의 버전, 별도의 리뷰, 별도의 롤백 경로를 갖습니다. 가장 자주 바뀌는 부분이 git release cycle에 묶이면 그 자체가 병목이 됩니다.
• Human-in-the-loop은 UX 옵션이 아니라 거버넌스입니다. 어떤 액션에서 사람의 승인을 받을지는 화면 흐름의 문제가 아니라 감사 추적과 권한 관리의 일부입니다.
• 비용은 런타임에서 관리합니다. 모델 호출도 retry도 매번 돈이 나갑니다. SDLC에서 비용은 분기 회의에 있었지만, ADLC에서는 release pipeline 안에 있어야 합니다.
• Trace는 디버깅 도구이자 product analytics 입력입니다. 사용자가 무엇을 시키고 어디서 막히고 어디서 정정하는지가 trace에 남고, 이는 곧 다음 build의 입력이 됩니다.

이걸 한 팀이 처음부터 다 만들 필요는 없습니다. LangSmith, AgentCore, Temporal 같은 도구가 이미 각 빈틈을 채우고 있고, 다음 분기에는 더 많아질 것입니다. 도구 이름보다 중요한 것은 이런 장치가 사이클 안에 있어야 한다는 인식입니다. 비워 두면 결국 매번 새로 메우게 됩니다.

릴리스 노트에 "no code changes"라고 적어도 시스템 행동은 달라질 수 있습니다. 이것이 ADLC가 SDLC 위에 한 겹 더 얹히는 이유입니다. 머지 버튼은 끝이 아니라 dataset 수집의 시작이고, 다음 dataset은 이미 production trace로 쌓이고 있습니다. 그 trace를 다음 평가로 끌어올 자리가 우리 인프라 안에 있는지가, 결국 어떤 사이클을 따르고 있는지를 결정합니다.