ToolOps - AI 에이전트를 구축하는 대부분의 개발자가 잘못된 문제를 해결하고 있습니다. 저 또한 그중 한 명이었습니다.

커뮤니티를 향한 진솔한 노트 — 제품 리뷰가 아닙니다.

아직 이름이 붙지 않은 특유의 개발자적 좌절감이 있습니다.

그것은 버그가 아닙니다. 배포 실패도 아닙니다. 모델의 환각 (Hallucination) 이나 깨진 API 계약 (API contract) 도 아닙니다. 그것은 기술적으로 정확한 것 — 실제로 작동하고 사용자가 실제로 원하는 것 — 을 구축했음에도 불구하고, 여전히 패배하고 있다는 느낌입니다. 에러 로그에는 나타나지 않는 방식으로, 천천히, 조용히 말이죠.

당신은 당신 자신의 아키텍처 (Architecture) 에 패배하고 있는 것입니다.

그 점에 대해 이야기하고 싶습니다. 그리고 이야기를 하는 중간에 어떤 도구 (Tool) 하나를 언급할 것입니다. 제가 언급할 때, 여러분이 한 가지를 알아차리길 바랍니다. 여러분은 아마 제가 하는 말을 무시하려는 반사적인 반응을 보일 것입니다. 마치 추천처럼 들리는 모든 것을 무시하는 방식처럼 말이죠. 그 반사적인 반응은 옳습니다. 그 덕분에 여러분은 과장된 라이브러리 (Library) 들에 시간을 낭비하는 일을 수백 번이나 면해왔을 것입니다.

하지만 몇 분 동안만 그 반응을 참아주시길 부탁드립니다. 제가 무언가를 팔고 싶어서가 아니라 — 저는 이 프로젝트와 관련이 없으며, 이 글을 쓰는 것에 대해 아무런 대가도 받지 않습니다 — 제가 그 반사적인 반응을 고스란히 간직한 채 몇 달 동안 저 자신의 에이전트 인프라 (Agent infrastructure) 에서 잘못된 문제를 해결하며 시간을 보냈고, 여러분은 저와 같은 우회로를 겪지 않기를 바라기 때문입니다.

문제처럼 보이지 않는 문제

데모 단계를 지나 실제 운영 (Production) 단계의 AI 에이전트 개발이 실제로 어떻게 이루어지는지 말씀드리겠습니다.

여러분은 외부 호출 (External calls) — LLM, API, 데이터베이스, 제3자 도구(Third-party tools) — 을 수행합니다. 이러한 호출은 느리고, 비용이 많이 들며, 신뢰할 수 없습니다. 여러분은 이 사실을 알고 있습니다. 이 분야에서 작업하는 모든 개발자가 이를 알고 있습니다. 표준적인 대응은 명백한 것들을 최적화하는 것입니다. 프롬프트 (Prompt) 를 압축하고, 적절한 모델 티어 (Model tier) 를 선택하며, 가능한 곳에 캐시 (Cache) 를 적용하는 것이죠.

함정은 이러한 최적화들이 충분하다고 느껴진다는 점입니다. 에러율은 낮습니다. 지연 시간 (Latency) 은 수용 가능한 수준입니다. 대부분의 관찰 가능한 지표로 볼 때, 당신의 시스템은 잘 작동하고 있습니다.

당신이 보지 못하고 있는 것 — 실패로 드러나지 않기 때문에 — 은 그 밑바닥에 깔린 구조적 낭비 (structural waste) 입니다. 멀티 에이전트 시스템 (multi-agent system) 내에서, 여러 에이전트가 공유 메모리 (shared memory) 없이 독립적으로, 동시에, 동일하거나 의미론적으로 동등한 (semantically equivalent) 쿼리를 동일한 엔드포인트 (endpoints)로 보냅니다. 각 에이전트는 이미 존재하는 결과에 대해 전체 비용을 지불합니다. 시스템이 고장 난 것이 아닙니다. 그저 대규모로, 끊임없이 망각하고 있을 뿐이며, 당신은 그 망각의 매 순간마다 비용을 지불하고 있는 것입니다.

이 문제가 충분히 논의되지 않는 이유는 간단합니다. 에러를 발생시키지 않기 때문입니다. 대신 청구서 (invoices)를 발생시킵니다.

그리고 청구서는 엔지니어링 문제라기보다 비즈니스 문제이기 때문에, 엔지니어들은 종종 이를 해결할 책임감을 느끼지 못합니다. 회의에서 대답하기 어려운 질문이 나올 정도로 금액이 커지기 전까지는 말이죠.

저도 그런 회의에 참석해 본 적이 있습니다. 다른 개발자들이 그 자리를 견디는 것을 지켜보기도 했습니다. 그리고 매번, 진짜 정답 — 즉, 아키텍처적 해답 (architectural answer) — 이 대화의 주제가 되지 않는다는 사실을 깨달았습니다.

아키텍처적 해답이란 무엇인가

올바른 해결책은 비즈니스 로직 (business logic)과 외부 호출 (external calls) 사이의 계층에서 작동해야 합니다.

프롬프트 (prompt) 수준이 아닙니다. 모델 선택 (model selection) 수준도 아닙니다. 인프라 계층 (infrastructure layer)에서 작동해야 합니다. 즉, 호출이 발생했을 때 어떤 일이 일어나는지, 결과가 어떻게 저장되는지, 중복 호출이 정말 필요한지, 그리고 엔드포인트가 실패했을 때 어떤 일이 발생하는지를 관리하는 계층 말입니다.

대부분의 팀은 모든 프로젝트마다 이 계층을 처음부터 직접 구축합니다. 커스텀 캐시 매니저 (cache managers), 수동으로 만든 재시도 로직 (retry logic), 3개 프로젝트 전의 Stack Overflow 답변에서 복사해 온 서킷 브레이커 (circuit breakers). 실제 작업은 단 세 줄뿐인데 이를 감싸는 수 페이지의 스캐폴딩 (scaffolding)은 누구도 완전히 이해할 수 없을 정도로 커져 버리고, 결국 다음번에 다시 구축해야만 합니다.

몇 달 전, 저는 이것을 다시 구축하는 것을 그만두었습니다.

이 도구의 이름은 ToolOps입니다. 이것은 오픈 소스 Python 미들웨어 SDK (middleware SDK)로, 모든 비동기 함수 (async function)를 감싸서 완전한 회복 탄력성 계층 (resilience layer)을 자동으로 제공하는 단일 데코레이터 (decorator)입니다. 캐싱 (Caching), 재시도 로직 (retry logic), 서킷 브레이킹 (circuit breaking), 요청 병합 (request coalescing), 자연어 입력을 위한 시맨틱 캐시 (semantic cache), 관찰 가능성 (observability)을 지원합니다. 프레임워크에 구애받지 않으며 (Framework-agnostic), 단 한 번의 설치 명령어로 사용 가능합니다.

pip install toolops

이 글의 남은 부분을 기능들을 나열하는 데 쓰지는 않겠습니다. 문서를 읽어보시면 됩니다. 대신 제가 하고 싶은 것은 이 프로젝트에서 실제로 흥미롭다고 생각하는 점이 무엇인지, 그리고 제가 이것을 통합한 후에도 왜 오랫동안 이 생각을 해왔는지에 대해 말씀드리는 것입니다.

생각해 볼 가치가 있는 부분

제 머릿속에 계속 남아 있는 것은 이것입니다.

제가 고객의 멀티 에이전트 시스템 (multi-agent system) — 하루에 만 건 이상의 대화를 처리하고, 서브 에이전트 (sub-agent) 네트워크를 통해 유료 도구 통합을 실행하는 챗봇 — 에 ToolOps를 추가했을 때, 비용 절감 효과는 상당했습니다. 실제 수치였고, 실제적인 영향이었습니다. 하지만 제가 계속 생각하고 있는 것은 그것이 아닙니다.

제가 계속 생각하고 있는 것은, 이 해결책을 마련하는 데 단 주말 이틀밖에 걸리지 않았다는 점입니다.

제 고객에게 필요했던 모든 것 — 캐싱 (caching), 회복 탄력성 (resilience), 동시 실행되는 에이전트 간의 요청 병합 (request coalescing) — 이 이미 구축되어 있었고, 이미 테스트되었으며, 이미 프로덕션 환경에 적용할 준비가 되어 있었습니다. 통합 과정은 데코레이터를 배치하고 백엔드 (backend)를 설정하는 것이 전부였습니다. 에이전트는 변하지 않았습니다. 비즈니스 로직 (business logic)도 변하지 않았습니다. 몇 달 동안 돈을 낭비하고 있었던 인프라 전체의 문제가 단 이틀 만에 해결되었습니다.

그리고 저는 생각했습니다. '지금 이 순간에도 해결책이 어려워서가 아니라, 단지 팀원 중 누구도 이런 해결책이 존재한다는 사실을 말해주지 않아서, 정확히 이 문제를 해결하지 못한 채 운영되고 있는 프로덕션 AI 시스템이 얼마나 많을까?'

그 질문이 제가 이 글을 쓰는 이유입니다.

제가 실제로 여러분께 요청드리는 것

거창한 것은 아닙니다.

만약 여러분이 Python으로 AI 에이전트 (AI agents)를 구축하고 있다면 — LangChain, CrewAI, LlamaIndex, 혹은 순수 OpenAI 호출 (raw OpenAI calls) 등 무엇이든 상관없습니다 — 저는 여러분이 ToolOps에 20분만 투자해 보시기를 요청합니다. 설치해 보세요. 도구 함수 (tool function) 하나를 감싸 보세요 (wrap). 여러분의 관측성 (observability) 출력 결과가 어떻게 변하는지 지켜보세요.

놀라움에 빠지라고 말씀드리는 것이 아닙니다. 어쩌면 놀라지 않을 수도 있습니다. 이미 인프라 (infrastructure)가 잘 갖춰져 있을 수도 있고, 이 도구가 아직 여러분에게 없는 문제를 해결해 주는 것일 수도 있습니다.

하지만 외부 호출 비용 (external call costs)이 실질적인 부담이 되기 시작하는 규모에 도달했거나, 곧 그 단계로 향하고 있다면, 여러분은 이 도구가 해결하는 문제를 즉시 알아차릴 것이라고 생각합니다. 그리고 그 깨달음 뒤에는 대개 다음과 같은 특정한 생각이 뒤따릅니다.

누군가 6개월 전에 이 사실을 말해줬더라면 좋았을 텐데.

저는 그 생각이 나중에가 아니라 지금 여러분 앞에 놓이기를 바랄 뿐입니다.

그리고 만약 여러분이 그 문제를 알아차렸다면

누군가에게 알려주세요.

제품 추천으로서가 아니라, 실무자 (practitioner)로서 말이죠. 수 시간을 아껴준 디버깅 기술 (debugging technique)을 언급하거나, 엉망이었던 코드베이스 (codebase)를 마침내 읽기 쉽게 만들어준 아키텍처 패턴 (architectural pattern)을 언급하는 것과 같은 방식으로요. 개발자 커뮤니티는 그런 종류의 지식 전수 — 문서에는 나타나지 않는 비공식적이고 동료 간의(peer-to-peer) 지식 전수 — 를 통해 움직입니다.

이 도구의 존재를 알게 되었을 때 가장 큰 혜택을 볼 팀은, 현재 직접 인프라를 구축하고 있으며 (hand-rolling), API 크레딧을 낭비하고, 결제 회의에 참석하며, 실제 문제는 하위 레이어 (layer underneath)에 있는데 모델 선택의 문제인지 고민하고 있는 팀들입니다.

그들은 제품 페이지를 통해서는 이 도구를 찾지 못할 것입니다. 대신 팀원 중 누군가가 무언가를 읽고, 시도해 보고, Slack 메시지나 포럼 댓글, 짧은 게시글

만약 직접 시도해 보시고 긍정적이든, 회의적이든, 혹은 그 중간 어디쯤이든 의견을 형성하신다면, 저는 진심으로 댓글을 통해 그 의견을 읽고 싶습니다. 이처럼 초기 단계에 있는 프로젝트를 위해 여러분이 할 수 있는 가장 유용한 일은 지지해 주는 것이 아닙니다. 다른 개발자들이 대화를 찾아볼 수 있도록, 솔직하고 공개적으로 참여해 주는 것입니다.