CodeCenter Web이 개인 중심 AI 코딩을 조직의 협업 플랫폼으로 확장하는 구조와 로드맵을 정리합니다.
Resources > Insight Report > Webinar
에이전트를 운영한다는 것은 결과 품질과 실행 경로, 실행 비용을 함께 관리하는 것입니다.
2026.01.30
에이전트는 이제 “할 수 있다”의 영역을 넘어 “운영할 수 있다”의 영역으로 이동하고 있습니다. 데모와 PoC는 비교적 빠르게 만들어집니다. 하지만 운영에 들어가는 순간, 팀이 실제로 마주치는 질문은 다음과 같이 바뀝니다.
이 질문들은 프롬프트 몇 줄을 고치는 것으로 해결되지 않습니다. 실행이 길어지고, 상태가 쌓이고, 도구 호출이 얽히는 순간 에이전트는 모델 호출이 아니라 운영되는 시스템이 되기 때문입니다.
지난 1월 슬렉슨 웨비나에서는 그 시스템을 운영하기 위한 관점으로서 AgentOps에 대해 이야기 했습니다. 이 글에서는 웨비나에서 다뤘던 핵심 내용을 토대로, AgentOps 관점에서 실제 운영을 전제로 한 Agentic AI 설계 · 운영 인사이트를 정리해보고자 합니다.
에이전트는 흔히 “LLM이 일을 대신한다”로 설명됩니다. 그러나 운영에서 본질은 지능이 아니라 실행입니다. 에이전트의 실무 동작을 한 문장으로 바꾸면 다음과 같습니다.
‘하나의 사용자 요청이 여러 단계로 쪼개지고, 각 단계의 결과가 다음 행동을 다시 결정한다’
즉 에이전트는 단발성 요청-응답 API가 아닙니다. 계획을 만들고, 행동을 선택하고, 도구를 실행하고, 그 결과를 바탕으로 다시 계획하는 흐름으로 움직입니다. 아래 [그림 1]과 같이 이 과정은 반복되며, 상황에 따라 분기됩니다.
여기서 운영 난이도를 폭발시키는 조건이 생깁니다.
이 특성 때문에 에이전트를 운영한다는 것은 결과 품질만 보는 일이 아니라 실행 경로와 실행 비용을 함께 관리하는 일이 됩니다.
현장에서 가장 자주 터지는 문제는 다양해 보이지만, 요약하면 두 축으로 정리됩니다.
관측이 안 되면, 개선이 안 된다.
에이전트가 “왜 그렇게 행동했는지”를 설명할 수 없으면, 팀은 대부분 다음 중 하나를 선택하게 됩니다.
관측이 안 되는 상태에서는 품질 문제도, 비용 문제도, 안전 문제도 구조적으로 해결되지 않습니다. 운영은 결국 측정 가능한 단위를 전제로 하기 때문입니다. 에이전트에서는 그 단위가 단순 “요청 1회”가 아니라 세션/트레이스/스텝으로 확장됩니다.
통제가 없으면, 에이전트는 ‘자동화’가 아니라 ‘리스크’가 됩니다
에이전트가 도구를 호출할 수 있다는 것은, 반대로 말하면 실제 시스템에 영향을 줄 수 있다는 뜻입니다. 결제, 고객 데이터, 권한 변경, 사내 리소스 접근 같은 행동이 포함되는 순간, 운영에서 필요한 것은 “더 똑똑한 모델”이 아니라 “중간에 멈출 수 있는 장치”입니다.
실무에서 자주 나오는 장면은 다음과 같습니다.
따라서 운영 가능한 에이전트란, 성능 좋은 에이전트가 아니라 위험한 행동을 제어할 수 있고, 실패를 국소화할 수 있는 에이전트가 됩니다.
AgentOps를 단순히 “에이전트 모니터링”으로 이해하면 범위가 줄어듭니다. AgentOps의 핵심은 에이전트의 실행을 운영 가능한 시스템으로 만드는 계층을 갖추는 데 있습니다.
이를 제품 개발 사이클로 표현하면 다음과 같습니다.
여기서 중요한 관점 전환이 필요합니다.
에이전트를 운영한다는 것은, ‘정답률을 올린다’가 아니라 ‘실행을 다룬다’가 됩니다.
AgentOps는 구현 관점에서 다섯 가지 레이어로 정리할 수 있습니다. 각 레이어는 서로 독립된 기능이 아니라, 운영에서 “반드시 같이 묶여야 하는” 기능들입니다.
에이전트의 실행은 “한 번의 호출 로그”로는 재구성되지 않습니다. 실행을 세션/스텝/상태 전이 단위로 기록하고 재생할 수 있어야 합니다. 이 레이어가 없으면 품질/비용/안전 논의는 추상화됩니다.
실무 체크 포인트는 다음과 같습니다.
운영에서 “잘 된다”는 느낌이 아니라 수치가 되어야 합니다. 특히 에이전트는 스텝 수가 늘수록 품질·비용·지연이 동시에 변하는 시스템이므로, 최소한 다음이 필요합니다.
관측과 평가는 “사후 대응”입니다. 운영에는 “사전 차단”이 필요합니다. Control은 에이전트 런타임에 게이트를 두는 일입니다.
이 레이어가 없으면 에이전트는 자동화가 아니라 사고의 원인이 되기 쉽습니다.
기업 환경에서 운영은 기술만으로 끝나지 않습니다. “누가 무엇을 허용했는가”가 남아야 합니다.
Govern은 보안/감사/컴플라이언스 요구사항을 에이전트 실행에 연결하는 레이어입니다.
에이전트는 한 번 만들고 끝나는 시스템이 아닙니다. 데이터, 도구, 정책, 모델이 바뀌면 실행이 바뀝니다. 따라서 운영 관점에서는 “배포”가 아니라 “라이프사이클”이 됩니다.
Govern은 보안/감사/컴플라이언스 요구사항을 에이전트 실행에 연결하는 레이어입니다.
에이전트가 확산되는 속도는 빠릅니다. 하지만 운영에서 살아남는 에이전트는 단순히 똑똑한 에이전트가 아닙니다. 다음을 만족하는 에이전트가 운영 가능한 에이전트가 됩니다.
AgentOps는 이 조건을 부가 기능이 아니라 “운영의 기본 구조”로 만드는 접근입니다. 에이전트가 제품으로 자리 잡을수록, AgentOps는 선택지가 아니라 필수 아키텍처가 됩니다.
▶관련 주제를 더 보고 싶다면 아래 블로그를 참고해보세요.
CodeCenter Web이 개인 중심 AI 코딩을 조직의 협업 플랫폼으로 확장하는 구조와 로드맵을 정리합니다.
이번 웨비나에서는 요구사항 분석, 테스트 생성, 변경 영향 분석을 자동화하는 단 하나의 AI 요구사항 솔루션 Trace.Space에 대해 알아봅니다.
이번 업데이트는 단순 기능 확장을 넘어 AI 기반 요구사항 관리 도구가 어떤 형태로 성숙해가는지 확인할 수 있는 지점입니다.
단순 요청 기반 코딩과 컨텍스트 엔지니어링 기반 Agentic 코딩을 동일 과제로 비교한 실험 결과를 정리합니다.
2025년은 AI 기술이 여러 방향에서 한꺼번에 진화를 이루며, 다시 한 번 변화의 흐름을 확인하게 만든 해였습니다.
이번 웨비나는 AI 코딩 도구 CodeCenter를 중심으로, 컨텍스트 엔지니어링이 개발 효율과 결과물 품질에 어떤 차이를 만드는지 검증합니다.
© SLEXN, Inc. All rights reserved.
이번 웨비나에서 성능 편차·비용·거버넌스의 현실적 한계를 실제 사례로 짚고, AI 자동화와 인간 개입의 명확한 기준을 제시합니다.