에이전트는 작업실에 있지, 제품 안에는 없다
에이전트의 역량은 하루가 다르게 눈부시게 발전하고 있습니다.
그런데 지금까지 제가 실제로 출시한 소프트웨어를 가만히 돌아보면 솔직하게 인정해야 할 사실이 하나 있습니다. 저는 아직 제품 ‘안에서’ 에이전트가 직접 실행되는 소프트웨어를 만들어본 적이 없습니다.
이 글은 그 간극에 대한 문제의식에서 출발합니다.
‘에이전트가 루프 안에 있다’는 말의 두 가지 의미
업계에서 “에이전트 인 더 루프(Agents in the loop)“를 이야기할 때는 대개 전혀 다른 두 상황을 한데 섞어 말합니다. 둘은 엔지니어링 문제로서 성격부터 다릅니다.
1) 제품을 ‘만드는’ 루프에 에이전트가 들어와 있는 경우. 제가 날마다 작업실에서 겪는 현실이 이쪽입니다. Claude Code가 코드를 작성하면 제가 diff를 리뷰합니다. LLM은 블로그 글 번역 초안을 뽑아주고 또 다른 모델과는 데이터베이스 아키텍처 설계를 놓고 토론합니다. 소프트웨어를 ‘제작하는 과정’ 구석구석에 에이전트가 스며들어 있습니다. Claude Code는 제가 써본 개발 보조 도구 가운데 단연 최고 수준입니다. 에이전트가 제 개인 개발 루프 안에서 훌륭한 짝 프로그래머 역할을 해내기 때문입니다.
2) 제품이 ‘실제 실행되는’ 루프에 에이전트가 들어와 있는 경우. 제품이 배포된 뒤 프로덕션 런타임 안에서 에이전트가 돌아가는 세계입니다. 에이전트가 실제 사용자를 대신해 상황을 판단하고, 의사결정을 내리며, 시스템의 상태를 직접 조작합니다.
첫 번째 방식은 이미 개발 생산성을 크게 혁신했습니다. 하지만 두 번째 방식은 적어도 제 개인 개발 여정에서는 이제 겨우 걸음마를 떼려는 단계입니다.
지금까지 실제로 출시한 것들
제가 배포한 작업물을 하나씩 돌아보겠습니다.
- ai-sota-feed-bot: Claude Code로 만든 첫 번째 프로덕트였습니다. 이 도구는 정적 피드 생성기입니다. 파이프라인은 에이전트와 함께 구축했지만 최종 사용자가 받는 것은 미리 빌드해 둔 정적 콘텐츠뿐입니다. 런타임에는 에이전트가 전혀 개입하지 않습니다.
- 이 블로그: 마찬가지입니다. 글을 다듬고 여러 언어로 번역하는 일은 에이전트 군단의 손을 거치지만 독자가 브라우저에서 읽는 것은 순수한 정적 HTML입니다.
지금까지 제가 에이전트를 쓴 곳은 오로지 작업실뿐이었습니다. 사용자가 만나는 제품 런타임 안에는 에이전트가 없었던 셈입니다.
앞으로도 이 상태가 유지되지는 않을 것입니다
미래의 제품 생태계는 결국 여러 에이전트가 사람을 대신해 자율적으로 조율하는 쪽으로 갈 수밖에 없습니다. 에이전트는 일정 조율, 정보 필터링, 조건 협상, 핵심 요약, 인터랙티브 튜터링처럼 사용자가 매일 믿고 맡기는 핵심 부품으로 자리 잡을 것입니다.
초기 징후는 이미 보입니다. AWS가 발표한 DevOps 에이전트가 대표적입니다. 운영 환경에서 장애가 나면 에이전트가 직접 원인을 분석하고 대응 조치를 지휘합니다. 개발자의 작업실이 아니라 실제 운영 루프 한가운데에 에이전트를 배치한 사례입니다.
에이전트가 사회 곳곳에서 직접 결정을 내리고, 예산을 집행하며, 다른 에이전트와 트랜잭션을 주고받는 영역은 폭발적으로 늘어날 것입니다. 그런데 저를 포함한 대부분의 엔지니어는 이런 환경에 맞게 시스템을 설계하는 정석을 아직 충분히 익히지 못했습니다.
제품 ‘안에’ 에이전트를 안착시키기 어려운 이유
프로토타입을 만들 때마다 빠지는 전형적인 함정이 있습니다.
모델에 툴 몇 가지를 연결해 데모를 띄우면 처음에는 놀라울 만큼 그럴듯합니다. 기계가 사람처럼 맥락을 파악하고 추론하는 것처럼 보이고 시연을 보는 사람마다 감탄을 쏟아냅니다.
그런데 이걸 진짜 상용 제품으로 다듬으려는 순간 숨어 있던 균열이 한꺼번에 드러납니다.
- 결과물이 지나치게 복잡하고 뜬구름을 잡습니다. 문장은 매끄럽지만 사용자가 정말 원했던 명확한 핵심 요구사항에서 미묘하게 빗나갑니다.
- 검증 체계가 없습니다. 에이전트 스스로도 자신이 올바른 결과를 냈는지 알지 못하고 하루 요청 수가 수십 건만 넘어가도 운영자가 일일이 손으로 감시할 수 없습니다.
- 비용이 청구서를 받기 전까지 보이지 않습니다. 길어지는 프롬프트, 잦은 재시도, 불어나는 컨텍스트 윈도우, 도구 호출 루프 때문에 토큰 비용이 비선형으로 치솟지만 일반 대시보드로는 알아채기 어렵습니다.
- 성능이 기존 모니터링에 잡히지 않습니다. 롱테일 레이턴시, 부분 실패, 타임아웃, 모델의 미묘한 성능 저하는 기존 APM 모니터링 툴로 또렷하게 추적하기 어렵습니다.
이 문제들은 단순한 부가 기능이 아닙니다. “에이전트 기술을 시연해본 프로토타입”과 “고객이 안심하고 돈을 내며 사용하는 프로덕션 제품”을 가르는 결정적인 차이입니다.
지금은 이 인프라를 한곳에 매끄럽게 조립하기가 무척 어렵습니다. 평가 프레임워크, 프롬프트 레지스트리, 분산 트레이싱, 비용 계량기, 안전 가드레일 등을 누더기처럼 기워 붙이고는 어디선가 누수가 생기지 않기만 바라는 처지입니다. 이 뼈대가 갖춰지지 않으면 에이전트 시스템은 프로덕션 등급에 도달하지 못합니다.
에이전트도 예측 가능한 기계 시스템이 되어야 합니다
사회 인프라로 자리 잡은 복잡한 기술(결제, 검색, 메시징, 내비게이션, 추천 시스템)은 모두 믿을 수 있고 일관된 동작을 증명한 뒤에야 기반 인프라가 될 수 있었습니다.
영리한 것만으로는 부족했습니다. 이런 속성까지 갖추어야 했습니다.
- 경계가 명확해야 함(Bounded): 시스템이 무엇을 할 수 있고 무엇을 절대 해서는 안 되는지가 명시되어 있어야 합니다.
- 관찰 가능해야 함(Observable): 지금 무엇을 하고 있고 비용이 얼마나 드는지 한눈에 보여야 합니다.
- 복구 가능해야 함(Recoverable): 중간에 실패하더라도 시스템 전체가 뻗지 않고 상식적인 대체 동작으로 넘어가야 합니다.
- 설명 가능해야 함(Attributable): 왜 그런 판단을 내렸는지 원인을 투명하게 역추적할 수 있어야 합니다.
오늘날의 에이전트는 아직 이 기준을 다 채우지 못합니다. 모델 자체의 지능이 모자라서라기보다는 모델을 감싸고 지탱하는 시스템 아키텍처가 아직 프로덕션 수준만큼 성숙하지 않았기 때문입니다.
에이전트가 결제 엔진이나 검색 엔진처럼 우리 일상에 자연스럽게 녹아들려면 그 주변의 하네스(Harness) 시스템이 단단하게 구축되어야 합니다. 일관된 산출물, 예측 가능한 동작, 눈에 보이는 비용, 안전한 실패 복구 말입니다. 지향점은 그저 “똑똑함”이 아니라 “믿을 수 있음”이어야 합니다.
이 섹션을 시작하는 이유
Agents in the Loop 섹션은 바로 이 과제를 기록하려고 만들었습니다.
작업실에서 에이전트로 코드를 더 빨리 짜는 법은 다른 섹션의 몫입니다. 이 섹션은 에이전트를 작업실에서 제품 런타임 한복판으로 옮겨 심을 때 부딪히는 현실적인 고민을 다룹니다. 무엇이 고장 나는지, 어떤 제약이 꼭 필요한지, 프로덕션 등급의 하네스는 어떤 형태여야 하는지, 그리고 직접 시스템을 만들며 체득한 배움을 솔직하게 기록해보려 합니다.
깔끔하게 정돈된 해답은 아직 없습니다. 다만 문제의 간극을 선명하게 느끼고 있고, 몇 가지 가설을 검증하는 중입니다. 제품을 만드는 다음 세대의 규칙이 바로 이 지점에서 정해질 거라는 확신도 강합니다.
차근차근 하나씩 검증해 나가보겠습니다.