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

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

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

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

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

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

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

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

ADLC의 사이클은 Build → Test → Deploy → Monitor → Iterate이고, 그 둘레에 Govern이 자리합니다. SDLC와 이름은 닮았지만 각 단계가 담는 대상이 넓어졌습니다.

• 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 시절에 외곽에 두던 것들을 사이클 안쪽으로 들여와야 합니다.

• 평가를 day-0 인프라로. 출시 전 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를 다음 평가로 끌어올 자리가 우리 인프라 안에 있는지가, 결국 어떤 사이클을 따르고 있는지를 결정합니다.