6개월 동안 AI 도구들을 서로 연결하며 깨달은 점: 실제로 무엇이 고장 나는가.

지난 10월, 저는 브라우저 탭 세 개를 열어둔 채 백그라운드에서는 Python 스크립트를 실행하고 있었고, Zapier의 zap은 세 번 실행될 때마다 조용히 메시지를 누락시키고 있었습니다. 저는 제품을 만들고 있어야 했습니다. 하지만 대신 GPT-4, Notion 데이터베이스, 그리고 재시도 로직(retry logic)이 없는 웹훅(webhook) 사이의 글루 코드(glue code)를 디버깅하고 있었습니다. 그날 저는 모든 실패 지점(failure point)을 기록하기 시작했습니다. 6개월 후, 그 목록은 제가 지금 만들고 있는 것의 기반이 되었으며, 이러한 AI 워크플로우 도구들이 실제로 무엇을 하는지, 그리고 무엇을 약속하는지에 대한 잔혹한 교육이 되었습니다.

"노코드 (No-Code)" AI 파이프라인의 환상

Zapier, Make, n8n은 모두 현대적인 AI 스택의 연결 조직(connective tissue)이라고 스스로를 홍보합니다. 그리고 "이 양식이 제출되면, 이를 OpenAI로 보내고 결과를 이메일로 발송한다"와 같은 단순한 사용 사례의 경우, 이들은 잘 작동합니다. 하지만 상태 유지(stateful), 분기(branching), 또는 문맥 인식(context-aware) 기능이 조금이라도 필요해지는 순간, 당신은 도구와 싸우기 시작할 것입니다.

핵심적인 문제는 이 플랫폼들이 결정론적(deterministic) API 호출을 위해 설계되었다는 점입니다. AI는 본질적으로 비결정론적(non-deterministic)입니다. GPT-4가 예상보다 300 토큰(tokens) 더 긴 응답을 반환하여 다운스트림 파서(downstream parser)를 망가뜨리는 순간, Zapier는 무엇을 해야 할지 모릅니다. Zapier는 해당 zap을 실패로 표시하고, 당신에게 이메일을 보낸 뒤 다음 단계로 넘어갑니다. 문맥을 포함한 재시도(retry-with-context)라는 개념이 내장되어 있지 않으며, 실패 내용을 모델에 다시 입력하여 제약 조건을 가지고 다시 시도하도록 요청할 방법도 없습니다. 결국 당신은 코드 단계(code step)에서 이를 직접 구축해야 하며, 이는 도구를 사용하는 목적 자체를 무색하게 만듭니다.

n8n은 세 가지 중 가장 정직합니다. 오픈 소스(open-source)이며, 결국에는 JavaScript를 작성해야 할 수도 있다는 사실을 숨기지 않기 때문입니다. Make(이전의 Integromat)는 가장 예쁜 시각적 에디터를 가지고 있지만, 5개 이상의 노드(nodes)를 다룰 때는 학습 곡선(learning curve)이 가장 가파릅니다. Zapier는 설정이 가장 빠르지만, 한계(ceiling)에 도달하는 속도 또한 가장 빠릅니다.

이들 중 그 어떤 것도 스트리밍 응답 (streaming responses)을 처리하지 못합니다. 멀티턴 대화 상태 (multi-turn conversation state)에 대한 일급 지원 (first-class support)을 제공하는 것도 없습니다. 이는 비난이 아닙니다. 애초에 이를 위해 만들어진 것이 아니기 때문입니다. 하지만 개발자들은 "노코드 (no-code)"와 "모든 것을 처음부터 직접 작성하기" 사이에서 이보다 더 나은 위치에 있는 도구가 없기 때문에 계속해서 이들을 찾고 있습니다.

LangChain과 LlamaIndex: 프레임워크 비용 (The Framework Tax)

지난 2년 동안 LLM을 사용하여 사소하지 않은 무언가를 구축해 보았다면, 아마 LangChain을 접해 보았을 것입니다. LangChain은 인상적일 정도로 포괄적이며 프로토타이핑 (prototyping)에 진정으로 유용합니다. 하지만 동시에 제가 프로덕션 환경에서 다뤄본 의존성 (dependencies) 중 가장 좌절감을 주는 것 중 하나이기도 합니다.

추상화 누수 (abstraction leaks)가 끊임없이 발생합니다. 당신의 체인 (chain)이 왜 API 호출을 한 번이 아닌 두 번 하는지 이해하기 위해 오후 내내 소스 코드를 읽고 있어야 할 수도 있습니다. 버전 업그레이드는 조용히 문제를 일으킵니다. 에러를 내뱉는 것이 아니라, 사용자가 불만을 제기할 때까지는 알아차릴 수 없는 미묘하게 달라진 동작으로 나타납니다. LCEL 재작성은 인터페이스를 정리했지만 근본적인 문제는 해결하지 못했습니다. 체인 깊은 곳에서 무언가 잘못되었을 때, 에러 메시지는 거의 쓸모가 없습니다.

LlamaIndex는 더 집중되어 있으며 (검색 (retrieval) 및 RAG), 그 특정 작업에는 더 뛰어납니다. 만약 당신의 워크플로우가 문서 수집 (document ingestion) → 청킹 (chunking) → 임베딩 (embedding) → 검색 (retrieval)이라면, 이것이 올바른 도구입니다. 하지만 그 외의 다른 것을 수행해야 한다면, 당신은 다시 코드를 이어 붙여야 (stitching) 할 것입니다.

이러한 프레임워크의 실제 비용은 인지적 부하 (cognitive overhead)입니다. 당신의 프로젝트에 합류하는 모든 개발자는 AI 레이어 (AI layer)를 건드리기 전에 프레임워크의 멘탈 모델 (mental model)을 이해해야 합니다. 이 부하는 복리로 쌓입니다. 저는 팀들이 실제 제품 로직을 개선하는 것보다 LangChain의 추상화 구조를 관리하는 데 더 많은 시간을 소비하는 것을 보았습니다.

관리형 플랫폼: Flowise, Dify, 그리고 호스팅된 도박

Flowise와 Dify는 LangChain/LlamaIndex의 기반을 가져와 시각적 인터페이스 (visual interface)로 감쌌습니다. 이들은 엔지니어가 아닌 인원들이 배포 주기 (deployment cycle) 없이 프롬프트 (prompts)를 수정하거나 모델을 교체할 수 있도록 하고 싶은 팀에게 유용합니다. 만약 그것이 당신의 병목 현상 (bottleneck)이라면, 이들은 진정으로 그 문제를 해결해 줍니다.

트레이드오프 (tradeoff)는 락인 (lock-in)과 투명성입니다. Flowise 워크플로우가 환각 (hallucination) 현상을 보이기 시작할 때, 당신은 실제로 전송되는 프롬프트 (prompt)를 숨기고 있는 UI를 통해 디버깅을 해야 합니다. 커스텀 미들웨어 (custom middleware)를 쉽게 추가할 수 없으며, 로깅 (logging)은 제한적입니다. 관찰성 (observability)은 사후 고려 사항에 불과합니다.

Dify는 제품 측면에서 더 빠르게 움직였으며, 데이터셋 관리 (dataset management) 및 API 퍼블리싱 (API publishing)과 같은 기능을 추가하여 프로토타입보다는 실제 플랫폼에 더 가깝게 느껴지도록 만들었습니다. 하지만 두 도구 모두 당신의 워크플로우가 주로 챗봇 형태라고 가정합니다. 만약 당신이 배치 작업 (batch jobs), 이벤트 기반 파이프라인 (event-driven pipelines), 또는 내부 데이터베이스와 복잡한 방식으로 상호 작용해야 하는 워크플로우를 실행하고 있다면, 이는 도구의 설계 의도와 반대로 작업하는 셈이 됩니다.

두 도구의 호스팅 버전 (hosted versions)은 세 번째 우려 사항을 추가합니다. 당신의 프롬프트, 데이터, 그리고 API 키가 타인의 인프라 (infrastructure) 상에 존재하게 된다는 점입니다. 사이드 프로젝트라면 괜찮습니다. 하지만 실제 사용자 데이터를 다루는 것이라면, 법무 팀과 심도 있는 논의가 필요합니다.

관찰성: 모두가 무시하다가 문제가 터지고 나서야 깨닫는 누락된 계층

LangSmith, Helicone, Braintrust, Arize — 순수하게 LLM 관찰성 (observability)에 집중하는 도구 카테고리가 성장하고 있습니다. 호출 추적 (tracing calls), 토큰 사용량 로깅 (logging token usage), 프롬프트 버전 비교, 출력값 평가 (evaluating outputs) 등이 포함됩니다. 이 카테고리는 위에 언급된 오케스트레이션 (orchestration) 도구들에 비해 과소평가되어 있으며 논의도 부족한 편입니다.

LangSmith는 (당연하게도) LangChain과 긴밀하게 통합되어 있으며, 이미 해당 생태계에 있다면 최고의 선택지입니다. Helicone은 프록시 계층 (proxy layer)으로 작동하며 모델 불가지론적 (model-agnostic)이기 때문에 어떤 스택에도 쉽게 도입할 수 있습니다. Braintrust는 평가 (evals)에 대해 가장 진지합니다. 만약 프롬프트 변형을 비교하기 위해 구조화된 실험을 수행하고 있다면, 학습 곡수 (learning curve)를 감수할 가치가 있습니다.

문제는 대부분의 팀이 프로덕션 (production) 환경에서 무언가 고장 난 후에야 사후 고려 사항으로서 관찰성을 추가한다는 점입니다. 그때가 되면 당신은 불완전한 로그로부터 문맥 (context)을 재구성해야 합니다. 첫날부터 관찰성을 구축하는 것 — 정확히 어떤 프롬프트가 전송되었는지, 어떤 응답이 돌아왔는지, 시간이 얼마나 걸렸는지, 그리고 비용이 얼마였는지를 아는 것 — 은 당신의 반복 (iterate) 방식을 변화시킵니다. 추측을 멈추고 측정을 시작하게 됩니다.

제가 사용해 본 그 어떤 AI 워크플로우 도구도 관측성 (Observability)을 처음부터 일급 시민 (First-class citizen)으로 다루지 않았습니다. 그것은 항상 플러그인, 통합 (Integration), 또는 별도의 구독 서비스로 존재했습니다.

선택을 위한 프레임워크 (흔한 상투어구 없이)

도구를 선택하기 전에, 다음 다섯 가지 질문에 솔직하게 답해 보십시오:

• 워크플로우가 상태 유지 (Stateful) 방식입니까? 단계나 세션 전반에 걸쳐 컨텍스트 (Context)를 기억해야 한다면, Zapier나 Make를 주요 레이어로 고려 대상에서 제외하십시오. 이들은 고통스러운 우회 방법 없이는 이를 수행할 수 없습니다.
• 스트리밍 (Streaming)이 필요합니까? 최종 사용자가 출력이 생성되는 것을 실시간으로 지켜봐야 한다면, SSE (Server-Sent Events)를 처리할 수 있는 도구나 커스텀 코드가 필요합니다. 대부분의 노코드 (No-code) 플랫폼은 이를 지원하지 않습니다.
• 출시 후 누가 프롬프트 (Prompt)를 변경할 것입니까? 엔지니어만 변경한다면, 코드 기반 접근 방식이 버전 관리 (Version control)와 CI (지속적 통합)를 제공합니다. 비기술적 이해관계자가 변경한다면 시각적 에디터 (Visual editor)가 필요하며, 그에 따른 트레이드오프 (Tradeoffs)를 받아들여야 합니다.
• 모델이 쓰레기 값 (Garbage)을 반환하면 어떻게 됩니까? 해피 패스 (Happy path)를 설계하기 전에 실패 처리 (Failure handling)를 설계하십시오. 사용 중인 도구가 조건부 분기 (Conditional branches), 재시도 (Retries), 폴백 모델 (Fallback models)을 지원합니까? 지원하지 않는다면, 이를 어떻게 구축할 것입니까?
• 비용 가시성 (Cost visibility)이 중요합니까? 토큰 (Token) 비용은 규모가 커짐에 따라 빠르게 복리로 증가합니다. 단계별로 세분화된 워크플로우당 비용을 볼 수 없다면, 당신은 눈을 감고 비행하는 것과 같습니다.

대부분의 팀은 무언가를 이미 구축하고 벽에 부딪힌 후에야 이 질문들에 답합니다. 핵심은 시작하기 전에 이 질문들을 던지는 것입니다.

AI Handler가 이 문제에 접근하는 방식

저는 6개월 동안 이러한 모든 고충을 겪으며 구축해 왔고, 계속해서 마주치는 패턴은 동일했습니다. 단 하나의 도구가 전체 루프 (Full loop)를 소유하지 않는다는 것이었습니다. 오케스트레이션 레이어 (Orchestration layer), 관측성 레이어 (Observability layer), 상태 관리 레이어 (State management layer), 그리고 이들을 하나로 묶어줄 글루 코드 (Glue code)를 서로 연결해야 했으며, 항상 문제가 발생하는 지점은 바로 그 글루 코드였습니다.

AI Handler는 워크플로우 (workflow), 상태 (state), 관찰 가능성 (observability), 그리고 모델 라우팅 (model routing)이 모두 일관된 데이터 모델 (data model) 아래 한 곳에 존재해야 한다는 아이디어를 중심으로 구축되었습니다. 이는 통합된 것이 항상 더 낫기 때문이 아니라, 특히 AI 워크플로우에서는 이러한 요소들 사이의 경계가 너무 모호하여 여러 도구를 사용하는 방식으로는 신뢰성을 유지하기 어렵기 때문입니다.

구체적으로 설명하자면: AI Handler의 모든 워크플로우는 노드 (node)들의 그래프 (graph)로 구성되며, 각 노드는 자신의 입력 스키마 (input schema), 출력 스키마 (output schema), 그리고 실패 동작 (failure behavior)을 알고 있습니다. 상태 (state)는 일급 객체 (first-class)로 취급됩니다. 즉, 별도의 커스텀 코드를 작성하지 않고도 컨텍스트 (context)를 전달하거나, 이전 출력을 참조하거나, 모델 출력에 따라 루프 (loop)를 탈출할 수 있습니다. 관찰 가능성 (observability)은 부가 기능이 아닙니다. 모든 실행은 무엇이 전송되었고, 무엇이 반환되었으며, 얼마나 걸렸고, 비용이 얼마였는지를 정확히 보여주는 트레이스 (trace)를 기록합니다. 모델 라우팅 (model routing)을 통해 폴백 체인 (fallback chains)을 정의할 수 있습니다. 기본 모델이 실패하거나 지연 시간 임계값 (latency thresholds)을 초과하면 자동으로 다음 모델로 전환됩니다.

이 도구가 모든 문제를 해결한다고 장담하지는 않겠습니다. 멀티 에이전트 조정 (Multi-agent coordination)은 여전히 어렵습니다. 평가 (Evals) 기능은 로드맵에 있으나 아직 출시되지 않았습니다. 스트리밍 (streaming) 구현에는 제가 여전히 다듬고 있는 예외 케이스 (edge cases)들이 있습니다. 하지만 워크플로우를 정의하고, 이를 안정적으로 실행하며, 무슨 일이 일어났는지 파악하는 핵심 루프 (core loop)는 견고합니다.

AI Handler는 제가 만들고 있는 통합 AI 워크플로우 도구입니다. 2026년 6월 출시 예정입니다. 베타 액세스 권한을 원하시면 **ceo@eternalsix.com**으로 이메일을 보내주세요.