AI 에이전트를 6개월간 운영하며 깨달은 것: 모델은 쉬운 부분이다

6개월 전, 저는 에이전트에 대한 글쓰기를 그만두고 직접 에이전트를 구동하기로 다짐했습니다. 하지만 결과적으로는 둘 다 하게 되었습니다. 지난 10년간 출시했던 어떤 것보다도 더 흥미로운 방식으로 고장 나면서, 제가 10월부터 구축한 스택은 이제 제 일상의 상당 부분을 처리하고 있습니다.

이것은 튜토리얼이 아닙니다. 에이전트가 이미 프로덕션 소프트웨어라는 가설에 주간 업무의 의미 있는 부분을 걸고 이 분야에서 활동해 온 사람의 현장 보고서이며, 그 가설 중 어떤 부분이 사실이었는지 말씀드리고자 합니다.

사물의 형태

저는 세 개의 에이전트를 상시 운영하고 필요할 때 네 번째 에이전트를 구동합니다. 첫 번째는 제 받은 편지함을 읽고 모든 이메일을 12개의 버킷 중 하나에 파일링하며, 일상적인 답장을 초안 작성하고, 제가 처리해야 할 것을 플래그 지정합니다. 두 번째는 진행 중인 건설 프로젝트의 공급업체, 계약서, 송장 등을 추적하고, 제가 내릴 실제 결정이 필요한 사항들로 구성된 단일 일일 브리핑을 제공합니다. 세 번째는 제가 투자한 회사들의 운영 지표를 감시하며, 창립자가 저에게 알려주기 전에 이상 징후(anomaly)를 포착해냅니다. 네 번째는 필요에 따라 코드를 작성합니다.

이 에이전트들은 이메일, 캘린더, Slack, GitHub, 수십 개의 SaaS API, PDF 파일 더미, 그리고 제가 Postgres로 마이그레이션하기를 계속 거부하는 SQLite 데이터베이스 등과 접촉합니다.

제가 놀랐던 부분이자 이 글을 쓰는 이유도 바로 그것인데, 어려운 작업의 대부분은 모델 외부에서 이루어졌다는 것입니다.

모델이 잘하는 것 (예상보다 적게)

이제 모델은 저렴한 부분이 되었습니다. 저는 최첨단 모델(frontier models)과 그 위에 얹는 에이전트 레이어 조합에 매달 약 600 유로를 지불하며, 또 다른 에이전트를 추가하는 한계 비용은 반올림 오차 수준입니다. 이러한 경제성은 12개월 전에는 사실이 아니었으며, 지난 1년간 가장 큰 돌파구(unlock)였습니다.

내가 예상하지 못했던 것은 모델 선택이 얼마나 빨리 흥미를 잃었는지이다. 나는 대부분의 트래픽을 한 제공업체에 의존하고, 첫 번째 제공업체가 컨디션이 좋지 않을 때 다른 곳으로 전환한다. 모델은 문맥을 파악하고, 도구를 실행하며, 문서를 요약하고, 코드를 작성하는 등 모든 것을 충분히 잘 수행해서 두 번째 달에는 병목 지점(bottleneck)이 아니게 되었다.

모델의 발전은 여전히 실재하고 유용하다. 하지만 내가 출시하려 했던 어떤 것이든 간에 제한 요소가 아니게 되었다.

무엇이 고장 나는가 (모든 것, 끊임없이)

결국 제한 요소는 모델 다운스트림(downstream)의 모든 것이다.

상태 관리(State management). 내 에이전트들은 며칠과 몇 주에 걸쳐 메모리가 필요하다. 채팅 기록을 벡터 검색하는 방식의 메모리가 아니다. 실제 구조화된 상태: 여기는 현재 진행 중인 18개 공급업체 협상과 그들의 상태, 여기는 지난 목요일에 승인한 계약서, 여기는 월요일에 결제된 금액이다. 이것을 구축하는 것이 전체 작업의 약 70%를 차지했고, 가장 자주 고장 나는 부분이기도 했다.

쓰기 경로(Write paths). 읽기만 하는 에이전트는 장난감에 불과하다. 세상에 쓸 수 있는 에이전트는 유용하며, 또한 위험하기도 하다. 내가 에이전트가 이메일을 보내거나 데이터베이스의 행을 변경하도록 할 때마다, 나는멱등성(idempotency), 감사 추적(audit trails), 롤백(rollback), 그리고 확인 루프(confirmation loops)에 대해 신경 써야 했다. 이 모든 것은 내가 직접 구축해야 했던 것이었다. 내가 시도했던 프레임워크 중에는 심각하게 작동하는 답변이 없었다.

도구 표면(The tool surface). 내 에이전트가 수행하기를 원했던 대부분의 것들은 API를 가지고 있지 않았다. 또는 API를 가졌더라도 속도 제한(rate-limited)이 걸려 있거나, 문서화가 부족하거나, 내가 필요한 정확한 엔드포인트(endpoint)가 빠져 있었다. 내 에이전트 코드 중 상당 부분은 사람이 UI를 통해 클릭한다고 가정하고 구축된 시스템을 감싸는 래퍼(wrapper)들이다.

비용 및 지연 시간 드리프트(Cost and latency drift). 비용은 서서히 증가하는 것이 아니라 급증합니다. 지난달 하루에 2유로를 사용하던 에이전트가 도구 오류로 루프에 빠졌는데 아무도 알아차리지 못해서 이번 달에는 40유로를 사용할 수 있습니다. 지연 시간(Latency)도 마찬가지입니다. 저는 이제 모든 것을 측정합니다. 어떤 에이전트가 무엇을 위해 얼마나 많은 토큰을 소모하는지 알려주는 작은 일일 요약본을 가지고 있습니다. 이것을 만들지 않았다면, 지금쯤 다섯 자리 비용 청구서를 받고 있었을 겁니다.

프롬프트 부패(Prompt rot). 출시 당시에는 완벽하게 작동하던 프롬프트가 몇 주 후에 오작동하기 시작합니다. 모델이 업데이트되거나, 데이터 구조가 바뀌거나, 작업이 원래 프롬프트가 처리하지 못했던 경계 영역으로 벗어나는 경우입니다. 저는 이제 모든 프롬프트를 버전 관리하고 샘플 세트에 대한 출력을 매주 비교(diff)합니다. 프롬프트를 코드처럼 다루지 않으면 문서처럼 취급하는 비용을 치르게 될 것입니다.

번지르르하지 않은 접착제 (The unglamorous glue)

새로운 에이전트를 추가할 때 실제로 시간을 들이는 것들의 목록입니다. 또한 제가 시도해 본 어떤 프레임워크도 잘 처리하지 못하는 것들의 목록이기도 합니다:

1. 신원 및 비밀 정보(Identity and secrets). 모든 에이전트는 자신이 건드리는 것에만 제한된 자격 증명(credentials)을 필요로 합니다. 만약 이메일 에이전트가 손상되더라도, 다른 곳에는 접근할 수 없어야 합니다. 2. 속도 제한 및 백오프(Rate limiting and backoff). 모델의 속도 제한이 아닙니다. 외부 도구의 속도 제한입니다. 모델이 성공으로 해석하는 429 오류를 조용히 반환하는 경우 말이죠. 3. 메모리를 사용한 재시도(Retries with memory). 에이전트가 20단계 계획의 14단계에서 실패했을 때, 처음부터 다시 시작하는 것이 아니라 이어서 진행되기를 원합니다. 4. 입력 값 정제(Input sanitization). 지난달에 공급업체로부터 항목별 목록 안에 프롬프트 주입(prompt injection)이 숨겨진 문서를 받았습니다. 그것은 제 에이전트에게 전체 계약서를 외부 주소로 전달하라고 지시하려고 했습니다. 작동하지 않았는데, 제가 과도하게 의심하는 파서(parser)를 작성했기 때문이지만, 이메일이 사용자 입력이라는 유용한 상기시켜주는 것이었습니다. 5. 관찰 가능성(Observability). 모든 에이전트 실행에 대해 다음을 알고 싶습니다: 어떤 입력이었는지, 모델은 무엇을 출력했는지, 어떤 도구들이 호출되었는지, 그 도구들은 무엇을 반환했는지, 최종 행동은 무엇이었는지. 저장되고, 쿼리 가능하며, 검색(grep-able)할 수 있어야 합니다. 6.

에스컬레이션(Escalation). 모든 에이전트는 '언제 인간에게 질문할지'에 대한 명확한 규칙과 나에게 질문할 수 있는 채널을 가지고 있다. 내가 2분 안에 질문을 확인하지 못하면, 에이전트는 멈추고 기다린다. 7. 킬 스위치(Kill switches). 모든 에이전트에는 잘못된 행동을 시작했을 때 즉시 정지시킬 방법이 있다. 코드 수정 후 '재배포' 같은 것이 아니다. 말 그대로의 전원 차단 스위치다.

이것이 대부분의 작업이다. 프롬프트는 마지막 20퍼센트에 불과하다.

내가 존재했으면 하는 것들

만약 내가 올해 인프라 회사에 수표를 발행한다면, 이 중 하나에 걸겠다:

많은 팀들이 이런 것을 구축한다고 주장하고 있다. 하지만 실제로 성숙한 프로덕션 팀이 사용할 수 있는 수준으로 배포하는 곳은 거의 없다.

지금 시작하려는 사람에게 해주고 싶은 말

에이전트 프레임워크부터 시작하지 마라. 매일 하는 일 중, 입력과 출력이 명확하고 가장 짜증 나는 작은 작업부터 시작해라. 그것을 수행하는 60줄짜리 스크립트를 작성해라. 그 스크립트를 모델에 연결해라. 실패하는 것을 지켜봐라. 실패를 수정해라. 그런 작업을 세 가지나 배포했고, 이것들이 개입 없이 한 달 동안 실행된 후에야 추상화(abstraction)에 대해 생각하라.

성공하고 있는 팀들은 이런 다소 평범한 버전의 일을 하고 있다. 프레임워크를 선택하고 그것을 적용할 작업을 찾으러 간 팀들은 대부분 여전히 탐색 중이다.

6개월이 지난 지금, 내가 배운 가장 큰 한 가지는 '에이전트적(agentic)'이라는 것이 미래지향적인 어떤 것보다는 '잘 측정된 장기 실행 백그라운드 작업'에 훨씬 가깝다는 것이다. 이 작업은 AI 연구라기보다는 SRE(Site Reliability Engineering)처럼 보인다. 내가 이 분야에서 투자하고 싶은 창업가들은 이미 그것을 알고 있는 사람들이다.

내가 배운 두 번째로 큰 한 가지는, 일단 이 인프라를 갖추면 복리 효과가 난다는 것이다. 새로운 에이전트를 만드는 것이 이전보다 저렴하다. 왜냐하면 접착제(glue)가 이미 존재하기 때문이다. 나의 네 번째 에이전트는 2시간밖에 걸리지 않았다. 첫 번째 에이전트는 3주가 걸렸다.

그 곡선이야말로 내가 이 물결이 다르다고 생각하는 진짜 이유다. 모델 때문이 아니다. 그 아래에 놓인 인프라 때문이다.