*이 장을 다 읽고 나면 알게 될 것: Agent 시스템을 배포한 뒤 무엇을 봐야 하는지, 품질과 비용을 어떻게 관리하는지, 인간의 피드백을 어떻게 학습 자산으로 바꾸는지, 그리고 빠른 개선 루프를 만드는 조직이 왜 결국 이기는지*
도입: 배포 다음 날 아침
2025년 초였다. 나의 시스템의 KVIC 시스템을 처음으로 실제 사용자에게 열었던 날이다. 전날 밤까지 테스트를 돌렸다. 결과는 괜찮았다. 나는 안심하고 잠들었다.
다음 날 아침 여섯 시. 알림이 왔다. 사용자 한 명이 "삼성전자의 파운드리 경쟁력을 분석해줘"라고 요청했다. 시스템은 답을 내놨다. 그런데 그 답에 2023년 데이터가 2025년 데이터인 것처럼 섞여 있었다. 사용자는 모른다. 나만 안다. 식은땀이 났다.
그날 오전에 로그를 뒤졌다. 문제의 원인은 Retriever 노드가 가져온 문서의 시점 메타데이터가 빠져 있었기 때문이다. 테스트할 때는 최신 문서만 넣어 놨으니 문제가 안 보였다. 실제 데이터베이스에는 오래된 문서가 섞여 있었다. 테스트 환경과 운영 환경은 다르다. 누구나 아는 말이다. 그러나 직접 겪기 전까지는 그 말의 무게를 모른다.
그 사건 이후 나는 한 가지를 확신하게 되었다. 배포는 시작일 뿐이다. 진짜 승부는 운영에서 갈린다.
MLOps라는 말은 이미 익숙할 것이다. 머신러닝 모델의 배포와 운영을 체계화하는 방법론이다. AgentOps는 그것의 Agent 버전이다. 단, Agent는 모델 하나가 아니라 여러 노드의 협업이다. 그래서 더 복잡하고, 더 세밀한 관찰이 필요하다.
이 장에서는 AgentOps를 세 축으로 나눈다. 관찰, 평가, 개선. 이 세 축이 루프를 이루면 시스템은 살아남는다. 루프가 끊기면 시스템은 조용히 죽는다.
25.1 AgentOps란 무엇인가 — MLOps의 다음 단계
AgentOps는 Agent Operations의 줄임말이다. MLOps가 모델 하나를 관리하는 체계라면, AgentOps는 여러 노드가 협업하는 Agent 시스템 전체를 관리하는 체계다.
차이를 짚어보자.
MLOps에서 관리하는 것은 비교적 단순하다. 하나의 모델이 있다. 입력이 들어가고 출력이 나온다. 그 출력의 정확도를 측정한다. 정확도가 떨어지면 재학습한다. 이것이 핵심 루프다.
AgentOps는 다르다. 노드가 아홉 개다. 각 노드가 서로 다른 LLM을 쓸 수 있다. 한 노드의 출력이 다른 노드의 입력이 된다. 순환도 있다. 분기도 있다. 어디서 문제가 생겼는지 찾는 것부터 어렵다. 사용자에게 잘못된 답이 나왔다. 그런데 그것이 Retriever가 잘못된 문서를 가져왔기 때문인가, Analyzer가 문서를 잘못 해석했기 때문인가, Generator가 해석을 잘못 글로 옮겼기 때문인가. 하나의 결과에 여러 노드가 관여한다.
그래서 AgentOps는 세 가지를 동시에 관리해야 한다.
첫째, 각 노드의 성능. 노드별로 무엇이 들어가고 무엇이 나왔는지를 기록한다.
둘째, 노드 간 흐름. 어떤 순서로 노드가 실행되었는지, 어디서 분기했는지, 몇 번 순환했는지를 추적한다.
셋째, 전체 시스템의 결과. 사용자에게 최종적으로 무엇이 전달되었고, 그것이 좋았는지 나빴는지를 평가한다.
이 세 수준을 동시에 보는 것이 AgentOps의 핵심이다. 하나라도 빠지면 눈을 감고 운전하는 것과 같다.
미국에서는 LangSmith, LangFuse, Arize AI 같은 도구가 이 영역에서 빠르게 성장하고 있다. 한국에서는 아직 자체 도구가 많지 않다. 대부분 오픈소스를 조합해서 쓴다. 그러나 이 시장은 2025년 하반기부터 폭발적으로 성장할 것이다. Enterprise Agent 도입이 본격화되면, 운영 체계 없이는 아무것도 유지할 수 없기 때문이다.
잠시 멈추고 생각해보자
당신의 조직에서 소프트웨어를 배포한 뒤 운영에 쓰는 시간은 전체의 몇 퍼센트인가? Agent 시스템에서 그 비율이 더 높아야 한다면, 어떤 역량이 추가로 필요한가?
25.2 관찰 — 보이지 않으면 고칠 수 없다
운영의 첫 번째 축은 관찰이다. 관찰은 세 겹으로 나뉜다. 로깅, 트레이싱, 모니터링.
로깅은 기록이다. 각 노드가 무엇을 받았고, 무엇을 내놓았는지를 남긴다. 프롬프트의 전문, LLM의 응답 전문, 소요 시간, 토큰 수, 오류 여부. 이것을 빠짐없이 기록하는 것이 로깅이다. 단순해 보이지만 실제로는 까다롭다. 프롬프트에 사용자의 개인정보가 들어 있으면 그대로 저장하면 안 된다. 마스킹이 필요하다. 토큰 수가 많으면 저장 비용이 올라간다. 얼마나 상세하게 기록할 것인가의 판단이 필요하다.
트레이싱은 흐름의 추적이다. 사용자 요청 하나가 시스템 안에서 어떤 경로를 따라 흘렀는지를 기록한다. Intake에서 시작해 Router로 가고, Planner를 거쳐 Retriever로, 다시 Analyzer로, Critic이 반려해서 Refiner를 거쳐 다시 Generator로. 이 전체 경로를 한 눈에 볼 수 있어야 한다. LangSmith가 이 영역에서 가장 앞서 있다. 각 노드의 실행 시간, 입출력, 비용을 타임라인으로 보여준다. LangFuse도 비슷한 기능을 오픈소스로 제공한다.
모니터링은 실시간 감시다. 지금 이 순간 시스템이 정상인가를 보는 것이다. 응답 시간이 갑자기 느려지지 않았는가. 오류율이 올라가지 않았는가. 특정 노드에서 병목이 생기지 않았는가. 대시보드를 만들어 핵심 지표를 실시간으로 본다. Grafana, Datadog 같은 도구가 이 영역에서 쓰인다.
세 겹의 관찰이 모두 갖춰져야 문제가 생겼을 때 원인을 찾을 수 있다. 모니터링이 이상을 감지하면, 트레이싱으로 어떤 경로에서 문제가 생겼는지 좁히고, 로깅으로 해당 노드의 입출력을 확인한다. 이 과정이 느리면 사용자에게 잘못된 답이 계속 나간다. 빠르면 즉시 차단하거나 수정할 수 있다.
나의 시스템에서는 MLflow를 관찰의 중심 도구로 쓴다. MLflow는 원래 ML 실험 추적 도구였지만, Agent 시스템의 관찰에도 충분히 쓸 수 있다. 각 노드의 실행을 하나의 실험(run)으로 기록하고, 사용자 요청 하나를 하나의 실험 그룹(experiment)으로 묶는다. 프롬프트, 응답, 토큰 수, 소요 시간, 비용을 모두 기록한다. 화려하지는 않다. 그러나 실용적이다. 그리고 오픈소스다. 비용이 들지 않는다. 작은 팀에게 이것은 중요하다.
잠시 멈추고 생각해보자
당신이 운영하는 시스템에서 가장 마지막으로 원인을 파악하기 어려웠던 오류는 무엇이었는가? 로깅, 트레이싱, 모니터링 중 무엇이 있었다면 더 빨리 찾았을 수 있었는가?
25.3 평가 — 무엇이 좋은 답인가
관찰이 "무엇이 일어났는가"를 보는 것이라면, 평가는 "그것이 좋았는가"를 묻는 것이다.
Agent 시스템의 평가는 네 가지 축으로 나뉜다.
첫째, 정확도. 답이 맞는가. 이것이 가장 기본이다. 그러나 가장 측정하기 어렵다. 왜냐하면 Agent의 답은 객관식이 아니기 때문이다. "삼성전자의 파운드리 경쟁력을 분석해줘"라는 질문에 대한 정답은 하나가 아니다. 좋은 답의 범위가 넓다. 그래서 정확도를 자동으로 측정하려면 별도의 평가 모델이 필요하다. LLM이 LLM의 답을 평가하는 구조다. LLM-as-a-Judge라고 부른다. 완벽하지는 않다. 그러나 사람이 매번 평가하는 것보다 빠르고 싸다. 그래서 1차 필터로 LLM 평가를 쓰고, 2차로 사람이 샘플을 확인하는 방식이 현실적이다.
둘째, 응답 시간. 사용자가 요청하고 답을 받기까지 걸리는 시간이다. Agent 시스템은 여러 노드를 순차적으로 거치기 때문에 단일 LLM 호출보다 느리다. KVIC의 경우 복잡한 분석 요청은 30초에서 2분까지 걸린다. 사용자가 30초를 기다릴 수 있는가. 이것은 용도에 따라 다르다. 채팅 앱이면 3초가 한계다. 분석 보고서라면 5분도 괜찮다. 중요한 것은 기대치를 맞추는 것이다. 그리고 기대치를 넘기면 사용자에게 알려주는 것이다. "분석이 예상보다 오래 걸리고 있다"라는 한 줄이 사용자의 불안을 덜어준다.
셋째, 비용. 요청 하나당 얼마가 드는가. 이 숫자를 모르면 사업이 안 된다. 뒤에서 자세히 다룬다.
넷째, 사용자 만족도. 결국 사용자가 좋다고 느끼는가. 답이 정확해도 형식이 불편하면 만족도가 낮다. 답이 완벽하지 않아도 사용자가 원하는 것을 빨리 얻으면 만족도가 높다. 이것은 정량 지표로만 잡히지 않는다. 별점, 좋아요/싫어요, 자유 서술 피드백, 재방문율. 여러 신호를 조합해야 한다.
네 축을 동시에 보면 재미있는 것이 보인다. 정확도와 응답 시간은 종종 트레이드오프 관계다. 더 정확하게 하려면 더 많은 노드를 거쳐야 하고, 그러면 더 느려진다. 정확도와 비용도 트레이드오프다. 더 좋은 모델을 쓰면 정확도가 올라가지만 비용도 올라간다. 이 트레이드오프 안에서 최적점을 찾는 것이 AgentOps의 핵심 과제다.
25.4 비용 관리 — 보이지 않는 출혈을 막아라
Agent 시스템의 비용은 세 층으로 나뉜다.
첫째, 토큰 비용. LLM API를 호출할 때마다 입력 토큰과 출력 토큰에 비용이 발생한다. 2025년 기준으로 GPT-4o는 입력 백만 토큰당 약 2.5달러, 출력 백만 토큰당 약 10달러다. Claude Sonnet은 입력 3달러, 출력 15달러 수준이다. 이 숫자들은 빠르게 변한다. 중요한 것은 절대 금액이 아니라 구조적으로 관리하는 습관이다.
Agent 시스템은 노드가 여러 개다. 한 번의 사용자 요청이 내부적으로 LLM을 다섯 번, 열 번 호출할 수 있다. 여기에 재시도와 순환 루프가 더해지면 호출 횟수는 예측하기 어렵다. 내가 KVIC를 운영하면서 배운 것 중 하나가 이것이다. 비용은 노드 수에 비례하지 않는다. 순환 횟수에 비례한다. Critic이 반려해서 Refiner를 거쳐 다시 Generator로 가는 루프가 세 번 돌면, 비용은 직선 경로의 세 배가 아니라 그 이상이 된다. 왜냐하면 루프를 돌 때마다 컨텍스트가 커지기 때문이다. 컨텍스트가 커지면 토큰이 늘어나고, 토큰이 늘어나면 비용이 올라간다.
그래서 루프 횟수에 상한을 두는 것이 필수다. KVIC에서는 최대 3회로 제한한다. 세 번 돌려서 Critic이 통과시키지 않으면, 부족한 상태로 내보내고 사용자에게 품질 경고를 붙인다. 완벽을 포기하는 것이다. 그러나 비용이 무한히 올라가는 것보다 낫다.
둘째, API 호출 비용. 토큰 비용 외에도 외부 API 호출이 있다. 검색 API, 데이터베이스 쿼리, 벡터 검색. 이것들도 건당 비용이 발생한다. 특히 벡터 검색은 인덱스 크기에 따라 비용이 올라간다. pgvector를 자체 서버에서 운영하면 비용을 예측할 수 있다. 클라우드 벡터 DB를 쓰면 사용량에 따라 올라간다. 이 선택이 비용 구조를 바꾼다.
셋째, 인프라 비용. 서버, GPU, 네트워크, 저장소. 오픈소스 LLM을 자체 호스팅하면 GPU 비용이 고정비가 된다. RunPod 같은 서비스를 쓰면 시간당 과금이다. 쓰지 않을 때는 비용이 0이다. 이 유연성이 작은 팀에게 중요하다. 나의 시스템에서는 RunPod으로 Qwen3를 호스팅한다. 피크 시간에만 GPU를 켜고, 새벽에는 끈다. 이것만으로 월 비용을 절반 이하로 줄였다.
비용 관리의 핵심은 요청당 비용을 측정하는 것이다. 사용자 요청 하나에 토큰 비용이 얼마, API 비용이 얼마, 인프라 비용이 얼마. 이 세 가지를 합치면 요청당 총비용이 나온다. 이 숫자를 모르면 사업 모델을 세울 수 없다. 월 구독료가 만 원인데 사용자가 하루 열 번 요청하면 요청당 비용이 33원 이하여야 손익이 맞는다. 이런 계산은 지루하다. 그러나 이 계산을 안 하면 사업이 죽는다.
잠시 멈추고 생각해보자
당신의 Agent 시스템에서 가장 비용이 많이 드는 노드는 어디인가? 그 노드의 비용을 절반으로 줄이려면 무엇을 바꿔야 하는가? 품질은 얼마나 희생해야 하는가?
25.5 품질 관리 — 환각과의 전쟁
비용을 줄이는 것도 중요하지만, 품질을 지키는 것이 더 중요하다. 비용은 돈을 더 쓰면 해결된다. 품질 문제는 신뢰를 깨뜨린다. 신뢰는 돈으로 살 수 없다.
Agent 시스템의 품질 문제는 크게 세 가지다.
첫째, 환각(Hallucination). LLM이 없는 사실을 만들어내는 것이다. Agent 시스템에서 환각은 더 위험하다. 왜냐하면 여러 노드를 거치면서 환각이 증폭될 수 있기 때문이다. Retriever가 관련 없는 문서를 가져오고, Analyzer가 그 문서에서 패턴을 "발견"하고, Generator가 그 패턴을 근거로 결론을 쓴다. 각 단계에서는 그럴듯해 보인다. 그러나 전체를 보면 근거가 없다.
환각을 막는 방법은 여러 가지다. 가장 기본은 출처 추적이다. 모든 주장에 출처를 붙인다. 출처가 없는 주장은 걸러낸다. Critic 노드가 이 역할을 한다. 더 정교한 방법은 별도의 검증 파이프라인을 두는 것이다. 생성된 답을 다른 LLM이 사실 확인한다. 비용이 들지만 고위험 영역에서는 필수다. 금융 분석, 의료 조언, 법률 판단 같은 영역이 그렇다.
둘째, 일관성 문제. 같은 질문에 다른 답이 나오는 것이다. LLM은 확률적이다. 같은 프롬프트에 매번 다른 답을 낼 수 있다. temperature를 0으로 낮추면 줄어들지만 완전히 없어지지는 않는다. 그리고 temperature를 낮추면 창의성도 줄어든다. 이 역시 트레이드오프다. 중요한 것은 일관성이 필요한 노드(검증, 분류)와 다양성이 필요한 노드(생성, 브레인스토밍)를 구분해서 각각 다른 설정을 쓰는 것이다.
셋째, Human-in-the-loop. 자동화의 반대가 아니다. 자동화의 완성이다. 모든 것을 자동화할 수 없다. 특히 고위험 결정은 사람이 확인해야 한다. 좋은 AgentOps는 어디서 사람이 개입해야 하는지를 시스템이 스스로 판단하는 것이다. 자신감이 높은 답은 자동으로 내보내고, 자신감이 낮은 답은 사람에게 넘긴다. 이 "자신감"을 어떻게 측정하는가가 핵심이다. LLM의 출력 확률을 쓸 수도 있고, Critic 노드의 점수를 쓸 수도 있고, 규칙 기반 체크리스트를 쓸 수도 있다. 보통은 이것들을 조합한다.
삼성SDS는 2024년부터 사내 Agent 시스템에 3단계 검증 체계를 도입했다. 1단계는 자동 검증, 2단계는 AI 교차 검증, 3단계는 사람 확인이다. 요청의 약 80%는 1단계에서 처리된다. 약 15%가 2단계로 간다. 나머지 5%만 3단계로 간다. 이 비율이 운영 비용과 품질 사이의 균형점이다.
25.6 개선 — 피드백 루프가 경쟁력이다
관찰하고 평가했다. 문제를 발견했다. 그 다음은 고치는 것이다.
개선에는 세 가지 방법이 있다.
첫째, 프롬프트 엔지니어링. 가장 빠르고 가장 싸다. 코드를 바꾸지 않는다. 모델을 바꾸지 않는다. 프롬프트만 바꾼다. 놀라운 것은 프롬프트를 한 줄 바꾸는 것만으로 정확도가 10~20% 오르는 경우가 종종 있다는 사실이다. 그래서 프롬프트는 코드와 같은 수준으로 버전 관리해야 한다. 언제 어떤 프롬프트를 썼고, 그 결과가 어땠는지를 기록해야 한다. MLflow가 이 역할을 한다. 각 프롬프트 버전을 하나의 실험으로 기록하고, 결과를 비교한다.
둘째, A/B 테스트. 두 가지 버전을 동시에 운영해서 어느 쪽이 나은지 비교하는 방법이다. 웹 서비스에서는 오래된 기법이다. Agent 시스템에서도 같은 원리다. 프롬프트 A와 프롬프트 B를 랜덤으로 배정하고, 평가 지표를 비교한다. 또는 모델 A와 모델 B를 비교한다. 주의할 것은 트래픽이 충분해야 한다는 점이다. 하루 요청이 열 건이면 A/B 테스트의 통계적 의미가 없다. 그 경우에는 평가 데이터셋을 별도로 만들어서 오프라인으로 비교하는 것이 현실적이다.
셋째, 파인튜닝과 RAG 개선. 프롬프트 변경만으로 안 되면 더 깊이 들어간다. 검색 품질이 문제라면 임베딩 모델을 바꾸거나 청킹 전략을 조정한다. 특정 도메인의 답이 약하면 해당 도메인 데이터로 파인튜닝을 한다. 이것은 시간과 비용이 더 든다. 그래서 프롬프트 → A/B → 파인튜닝의 순서로 진행하는 것이 효율적이다. 쉬운 것부터 시도하고, 안 되면 어려운 것으로 가는 것이다.
개선에서 가장 중요한 것은 속도다. 문제를 발견하고 고치기까지 걸리는 시간이 경쟁력이다. 어떤 팀은 문제를 발견하고 일주일 뒤에 고친다. 어떤 팀은 같은 날 고친다. 같은 기술을 쓰고, 같은 모델을 쓰고, 같은 데이터를 쓴다. 그런데 후자가 이긴다. 왜냐하면 개선이 빠르면 작은 문제가 큰 문제가 되기 전에 잡히기 때문이다.
잠시 멈추고 생각해보자
당신의 조직에서 문제를 발견하고 수정 배포까지 걸리는 시간은 얼마인가? 그 시간을 절반으로 줄이려면 프로세스의 어디를 바꿔야 하는가?
25.7 인간 피드백을 학습 자산으로
사용자가 "이 답 별로야"라고 말한다. 이것은 불만인가, 자산인가.
좋은 AgentOps에서는 자산이다.
RLHF(Reinforcement Learning from Human Feedback)라는 개념이 있다. ChatGPT를 만들 때 OpenAI가 쓴 방법이다. 사람의 선호를 모아서 모델을 개선하는 것이다. 이 개념은 대형 AI 회사만의 것이 아니다. 규모는 다르지만 원리는 같다. 기업의 Agent 시스템에서도 적용할 수 있다.
구체적으로 이렇게 한다.
사용자의 피드백을 체계적으로 수집한다. 좋아요/싫어요, 별점, 수정된 답, 자유 서술. 이 데이터를 쌓는다. 충분히 쌓이면 패턴이 보인다. 어떤 유형의 질문에서 만족도가 낮은가. 어떤 노드에서 문제가 자주 생기는가. 어떤 프롬프트가 더 좋은 결과를 내는가.
이 패턴을 기반으로 세 가지를 개선한다.
프롬프트를 다듬는다. "좋은 답"의 사례를 프롬프트에 넣는다. few-shot 학습이다. 사용자가 직접 수정한 답은 최고의 few-shot 예시다.
평가 기준을 정교화한다. 처음에는 "좋은 답"의 정의가 모호하다. 피드백이 쌓이면서 선명해진다. "이 도메인에서 좋은 답은 숫자 근거가 있어야 한다", "이 사용자 그룹은 짧은 답을 선호한다" 같은 구체적 기준이 생긴다.
데이터를 보강한다. 사용자가 수정한 답은 새로운 학습 데이터가 된다. 이것을 RAG의 지식 베이스에 추가하거나, 파인튜닝 데이터로 쓸 수 있다. 이렇게 하면 사용자가 쓸수록 시스템이 좋아진다. 이것이 네트워크 효과의 Agent 버전이다.
카카오엔터프라이즈의 사내 AI 도우미 사례가 좋은 예다. 2024년 도입 초기에는 사용자 만족도가 약 60%였다. 6개월 동안 사용자 피드백을 수집하고, 그 피드백을 기반으로 프롬프트를 주 단위로 개선했다. 6개월 후 만족도는 85%를 넘었다. 모델을 바꾸지 않았다. 피드백 루프의 힘이다.
25.8 빠른 개선 루프를 만드는 조직이 이긴다
이 장의 결론이다.
AgentOps는 기술의 문제이기도 하지만, 궁극적으로는 조직의 문제다.
좋은 도구가 있어도 조직이 느리면 소용없다. LangSmith로 문제를 발견해도 수정 권한이 한 명에게만 있으면 그 한 명이 휴가를 가면 멈춘다. MLflow에 모든 실험이 기록되어 있어도 아무도 그 기록을 보지 않으면 종이 위의 숫자일 뿐이다.
빠른 개선 루프를 만드는 조직에는 공통점이 있다.
작은 팀. 의사결정이 빠르다. 프롬프트를 바꾸는 데 승인이 세 단계면 이미 늦다.
관찰 문화. 대시보드를 매일 본다. 이상이 있으면 즉시 논의한다. "그건 나중에 보자"가 없다.
실험 문화. 바꿔보는 것을 두려워하지 않는다. 프롬프트를 바꿔서 나빠지면 되돌리면 된다. 버전 관리가 되어 있으므로 되돌리기는 쉽다.
피드백 존중. 사용자의 불만을 귀찮은 것이 아니라 데이터로 본다. "왜 불만인가"를 파고든다.
나는 데이터 분석 컨설팅, 글로벌 IT기업을 거치며 컨설턴트로 여러 조직을 봤다. 기술이 뛰어난 조직이 항상 이기는 것은 아니다. 기술은 평균 수준이지만 개선 속도가 빠른 조직이 결국 앞서간다. Agent 시스템에서도 마찬가지다. 처음부터 완벽한 Agent를 만들 수는 없다. 빠르게 고치는 Agent를 만들 수 있을 뿐이다.
AgentOps는 그 "빠르게 고치기"를 가능하게 하는 체계다. 관찰하고, 평가하고, 개선한다. 이 루프를 멈추지 않는다. 멈추는 순간 Agent는 낡은 소프트웨어가 된다.
핵심 정리
AgentOps는 Agent Operations의 줄임말이다. MLOps가 모델 하나를 관리하는 체계라면, AgentOps는 여러 노드가 협업하는 Agent 시스템 전체의 운영 체계다. 배포 이후가 진짜 승부다.
관찰은 로깅, 트레이싱, 모니터링의 세 겹으로 이루어진다. 로깅은 각 노드의 입출력을 기록하고, 트레이싱은 노드 간 흐름을 추적하고, 모니터링은 실시간으로 시스템 상태를 감시한다. LangSmith, LangFuse, MLflow 같은 도구가 이 영역을 지원한다.
평가는 정확도, 응답 시간, 비용, 사용자 만족도의 네 축으로 이루어진다. 이 축들은 종종 서로 트레이드오프 관계에 있다. 최적점을 찾는 것이 핵심이다.
비용은 토큰 비용, API 호출 비용, 인프라 비용의 세 층으로 나뉜다. 순환 루프가 비용을 예측 불가능하게 만들 수 있으므로 루프 횟수에 상한을 두는 것이 필수다. 요청당 총비용을 측정하지 않으면 사업 모델이 성립하지 않는다.
품질 관리의 핵심은 환각 방지, 일관성 유지, Human-in-the-loop의 적절한 배치다. 모든 것을 자동화하려 하지 말고, 시스템이 스스로 자신감을 판단해 사람의 개입이 필요한 순간을 식별하게 해야 한다.
인간의 피드백은 불만이 아니라 학습 자산이다. 피드백을 체계적으로 수집하고, 프롬프트 개선과 평가 기준 정교화와 데이터 보강에 활용하면, 사용자가 쓸수록 시스템이 좋아지는 선순환이 만들어진다.
결국 이기는 조직은 가장 좋은 Agent를 만드는 조직이 아니라 가장 빠르게 개선하는 조직이다.
반드시 답해봐야 할 질문 5가지
질문 1. 당신의 Agent 시스템에서 사용자에게 잘못된 답이 나갔을 때, 그것을 발견하기까지 얼마나 걸리는가? 발견 후 수정까지는 얼마나 걸리는가? 이 두 시간의 합이 당신의 AgentOps 성숙도를 보여준다.
질문 2. 요청당 총비용을 알고 있는가? 토큰 비용, API 비용, 인프라 비용을 합친 숫자를 당장 말할 수 있는가? 말할 수 없다면, 무엇부터 측정해야 하는가?
질문 3. 당신의 시스템에서 Human-in-the-loop의 경계는 어디인가? 어떤 유형의 요청에 사람이 개입하고, 어떤 유형은 자동으로 처리하는가? 그 기준은 명문화되어 있는가?
질문 4. 사용자 피드백을 수집하고 있다면, 그 피드백이 실제로 시스템 개선에 반영되기까지 걸리는 시간은 얼마인가? 피드백이 수집만 되고 방치되고 있지는 않는가?
질문 5. 당신의 조직에서 프롬프트를 바꾸는 데 몇 단계의 승인이 필요한가? 그 승인 단계는 품질을 지키기 위한 것인가, 관료주의인가?
더 깊이 탐구하기
LangChain, 「LangSmith Documentation — Tracing and Evaluation」 (2025). Agent 시스템의 트레이싱과 평가를 실무적으로 다룬 공식 문서.
Chip Huyen, 「Designing Machine Learning Systems」 (2022). MLOps의 원리를 체계적으로 정리한 책. AgentOps의 이론적 기초가 된다.
MLflow 공식 문서, 「MLflow Tracking」 (2025). 실험 추적과 모델 관리의 실용 가이드. 오픈소스로 시작하기에 적합하다.
Harrison Chase, 「Building Production-Ready LLM Applications」 강연 시리즈 (2024~2025). LangChain 창업자가 직접 다루는 Agent 운영의 실전 노하우.
나의 시스템 내부 기술 백서, 「KVIC AgentOps 운영 보고」 (2025). MLflow 기반 Agent 시스템 관찰·평가·개선의 실무 사례.
다음 장에서는 Agent 시스템이 조직 밖으로 나갈 때 마주치는 벽을 다룬다. 보안, 거버넌스, 그리고 책임. 잘 작동하는 Agent가 조직의 신뢰를 얻으려면 기술 너머의 문제를 풀어야 한다.