대부분의 AI 워크플로우 앱이 실패하는 이유 (그리고 살아남는 앱들의 특징)

6개월 전, 저는 3주 동안 공들여 만든 워크플로우를 폐기했습니다. 그것은 클라이언트 조사를 자동화하고, 제안서를 초안 작성하며, 모든 내용을 Notion에 저장하는 작업이었습니다. 완벽하게 작동했습니다 — Zapier가 속도 제한 (rate limit)을 변경하고, OpenAI의 응답 형식이 약간 변하며, 저의 "스마트한" 프롬프트가 회사 이름을 환각 (hallucinating)하기 시작하기 전까지는 말이죠. 저는 자동화가 저를 해방시켜 주어야 했던 실제 업무를 하는 대신, 토요일 내내 글루 코드 (glue code)를 디버깅하며 시간을 보냈습니다. 그것은 도구의 문제가 아닙니다. 설계의 문제입니다. 그리고 그 이후로 제가 사용한 거의 모든 AI 워크플로우 앱은 정확히 똑같은 실수를 저지르고 있습니다.

추상화 계층 (Abstraction Layer)은 거짓말이다

대부분의 AI 워크플로우 도구들은 시각적 캔버스나 드래그 앤 드롭 노드 에디터를 판매하며 이를 "노코드 (no-code)"라고 부릅니다. 하지만 그들이 실제로 제공하는 것은, 정상적인 경로 (happy path)를 벗어나는 순간 무너져 버리는 잘못된 추상화입니다.

데모 중에는 이 추상화가 아름답게 유지됩니다. Gmail 트리거를 GPT-4에 연결하고 Slack 메시지로 연결한 뒤, 실행을 클릭하면 작동합니다. 그러다 실제 사용 사례에 부딪힙니다: 이메일에 PDF 첨부 파일이 있고, 모델이 예상하지 못한 추가 필드가 포함된 JSON을 반환하면, 갑자기 당신은 문서를 읽을 필요가 없다고 약속했던 도구의 문서를 읽고 있게 됩니다.

추악한 비밀은 AI의 출력이 본질적으로 확률적 (probabilistic)이고 가변적이라는 점입니다. 그렇지 않은 척하는 — 즉, LLM 호출을 안정적인 반환 타입을 가진 결정론적 함수 (deterministic function)처럼 취급하는 — 모든 추상화 계층은 결국 누수될 것입니다. 당신은 결국 가공되지 않은 API를 직접 만지게 될 것입니다. 그 순간이 오면, 시각적 도구는 자산이 아니라 부채가 됩니다. 당신은 디버깅을 위해 설계되지 않은 GUI 내부에서 디버깅을 하고 있는 것입니다.

이러한 상황에서 살아남는 앱들은 내부 구조를 정직하게 노출하는 앱들입니다. 그들은 가공되지 않은 프롬프트 (raw prompt)를 보여줍니다. 정확한 API 호출을 보여줍니다. 필요할 때 코드로 전환할 수 있게 해줍니다. 실패하는 앱들은 당신이 빠져나올 수 없을 정도로 깊이 빠질 때까지 친숙한 UI 뒤에 복잡성을 계속 숨겨둡니다.

그들은 백 번째 실행이 아니라 첫 번째 실행에 최적화되어 있다

AI 툴링 (tooling) 분야에는 고질적으로 나타나는 특정한 종류의 데모용 소프트웨어 (demo-ware)가 있습니다. 한 번 써보기에는 환상적이지만, 매일 사용하기에는 점점 더 나빠지는 제품들 말입니다. 첫 번째 실행은 마법 같습니다. 하지만 백 번째 실행은 모든 균열을 드러냅니다.

실제로 그러한 균열은 다음과 같은 모습으로 나타납니다:

• 한 번의 호출에서는 "충분히 빠를" 정도였던 지연 시간 (Latency)이, 다섯 개를 체이닝 (chaining)하게 되면 고통스러워집니다.
• 실제 문서를 전달하기 전까지는 거대해 보였던 컨텍스트 윈도우 (Context windows).
• 1월에는 잘 작동하던 프롬프트 템플릿 (Prompt templates)이 기반 모델 (underlying model)이 업데이트되면서 성능이 저하되기 시작합니다.
• 테스트 중에는 보이지 않던 속도 제한 (Rate limits)이, 규모를 확장 (scale)할 때 전체 워크플로우의 천장이 됩니다.

대부분의 워크플로우 앱 빌더들은 온보딩 (onboarding), 즉 "60초 만에 첫 번째 워크플로우를 만드세요"와 같은 화려한 경험에 엔지니어링 사이클을 소비합니다. 리텐션 엔지니어링 (Retention engineering) — 즉, 열 번째 세션을 첫 번째 세션보다 더 좋게 만드는 것 — 은 진정으로 어렵고도 매력적이지 않은 일입니다. 여기에는 계측 (instrumentation), 실패 로깅 (failure logging), 재시도 로직 (retry logic), 캐싱 전략 (caching strategies), 그리고 모델 버전 관리 (model versioning)를 어떻게 처리할지에 대한 확고한 견해가 필요합니다. 대부분의 팀은 이것이 스크린샷으로 찍었을 때 멋지게 나오지 않는다는 이유로 이를 건너뜁니다.

컨텍스트는 사후 고려 사항으로 취급된다

모든 AI 워크플로우에서 가치의 근본적인 단위는 컨텍스트 (Context)입니다. 즉, 모델이 어떤 정보에, 어떤 형태로, 체인의 어느 시점에서 접근할 수 있는가 하는 점입니다. 대부분의 앱은 컨텍스트를 정적인 입력값처럼 취급합니다. 시스템 프롬프트 (system prompt)를 한 번 작성하고, 데이터 소스 (data source)를 연결하면 끝이라고 생각합니다.

실제 워크플로우는 동적입니다. 모델이 좋은 초안을 작성하는 데 필요한 컨텍스트는 QA 패스 (QA pass)를 수행하는 데 필요한 컨텍스트와 다릅니다. 고객용 요약에 필요한 컨텍스트는 내부용 컨텍스트와 다릅니다. 컨텍스트는 단순한 설정 옵션이 아닙니다. 그것이 바로 제품 그 자체입니다.

제가 지속적으로 목격하는 현상은 이렇습니다. 앱들은 시스템 프롬프트(system prompt)를 위한 텍스트 박스 하나와 "입력(input)"을 위한 슬롯 하나만을 제공합니다. 그 외의 모든 것은 문자열 연결(string concatenation)과 요행에 의존하여 임시방편으로 짜 맞춰져 있습니다. "워크플로우의 이 단계에서는 모델이 이 세 가지 소스에는 접근할 수 있어야 하지만, 저 소스에는 접근해서는 안 된다"라고 말할 수 있는 구조적인 방법이 없습니다. 어떤 변경 사항이 품질 저하를 일으켰는지 추적할 수 있는 프롬프트 버전 관리(version control)도 없습니다. 실제 워크플로우 컨텍스트 내에서 컨텍스트 전략들을 서로 A/B 테스트할 방법도 없습니다.

이를 제대로 구현한 앱들은 컨텍스트를 일급 객체(first-class object)로 취급합니다. 컨텍스트를 구성하고, 버전 관리하고, 단계별로 범위를 지정(scope)하며, 그 영향을 측정할 수 있게 해줍니다.

무시되고 있는 멀티 모델(Multi-Model)의 현실

GPT-4가 워크플로우의 모든 단계에 적합한 모델은 아닙니다. Claude는 특정 추론(reasoning) 작업에 더 뛰어납니다. Gemini는 더 긴 컨텍스트 창(context window)을 가지고 있습니다. Llama는 로컬에서 무료로 실행됩니다. 미세 조정(fine-tuned)된 Mistral은 귀하의 특정 도메인에서 이들 모두보다 뛰어난 성능을 보일 수도 있습니다.

거의 모든 AI 워크플로우 앱은 사실 "모델 전환"을 위한 드롭다운 메뉴만 갖춘 채, 한 제공업체의 API를 얇게 감싼 래퍼(wrapper)에 불과합니다. 그것은 멀티 모델 지원이 아닙니다. 진정한 멀티 모델 지원이란 비용, 지연 시간(latency), 능력, 그리고 출력 요구 사항에 따라 서로 다른 단계를 서로 다른 모델로 라우팅(routing)하는 것을 의미하며, 제공업체에 장애가 발생했을 때를 대비한 폴백(fallback) 로직을 갖추어 자동으로 이루어져야 합니다.

사용자를 단일 제공업체에 종속시키는 앱들은 해당 제공업체의 지속적인 시장 지배력에 자신들의 제품 해자(moat)를 거는 도박을 하고 있습니다. 이는 나쁜 도박이자 나쁜 경험입니다. 도구가 요약 단계에는 더 저렴한 모델을, 추론 단계에는 더 강력한 모델을 사용하도록 허용하지 않기 때문에, 결국 필요 이상으로 느리고 비용이 많이 드는 워크플로우를 갖게 됩니다.

체크리스트: 지속 가능한 AI 워크플로우 도구에 실제로 필요한 것

어떤 AI 워크플로우 플랫폼 위에서 구축을 시작하기 전에 — 혹은 직접 구축하기 전에 — 다음 사항들을 통해 검증해 보십시오:

• 실패 가시성 (Failure visibility): 무엇이, 왜, 어느 단계에서 실패했는지 정확히 알 수 있습니까? 단순히 "워크플로우 오류"라고 뜨는 것이 아니라, 실제 API 응답을 확인할 수 있어야 합니다.
• 프롬프트 버전 관리 (Prompt versioning): 프롬프트 변경 사항을 롤백할 수 있습니까? 프롬프트 v1과 v2 사이의 차이점(diff)과 그로 인해 출력값이 어떻게 변했는지 확인할 수 있습니까?
• 단계별 컨텍스트 범위 지정 (Context scoping per step): 동일한 워크플로우 내의 각 단계가 서로 다른 컨텍스트를 가질 수 있습니까, 아니면 모두 전역(global)으로 적용됩니까?
• 모델 라우팅 (Model routing): 각 단계에 서로 다른 모델을 할당하고, 폴백(fallback) 로직을 적용할 수 있습니까?
• 실제 출력 스키마 검증 (Real output schema validation): 모델 출력에 대해 실제 구조화된 검증이 이루어집니까, 아니면 단순히 문자열 매칭(string matching)을 수행합니까?
• 증분 실행 (Incremental runs): 워크플로우 전체를 처음부터 다시 실행하지 않고, 실패한 특정 단계만 재실행할 수 있습니까?
• 비용 추적 (Cost tracking): 각 워크플로우 실행 시 단계별로 발생하는 API 비용을 정확히 파악할 수 있습니까?
• 코드로의 탈출구 (Escape hatch to code): GUI만으로 부족할 때, 모든 것을 다시 작성하지 않고도 코드로 전환하여 작업할 수 있습니까?

만약 어떤 도구가 이 중 두 가지 이상을 충족하지 못한다면, 규모가 커질수록(at scale) 당신에게 해가 될 것입니다.

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

제가 AI Handler를 구축해 온 이유는, 기존에 사용하던 도구들에서 위에서 언급한 모든 실패 모드(failure mode)를 계속해서 마주했기 때문입니다. 이는 기존 팀들을 비판하려는 것이 아닙니다 — 이 문제를 제대로 해결하는 것은 진정으로 어려운 일입니다 — 다만, 어려운 부분들이 존재하지 않는 척하지 않는 무언가를 만들고자 하는 동기였습니다.

AI Handler는 몇 가지 구체적인 가설을 바탕으로 구축되었습니다. 첫째, 컨텍스트(context)는 일급 객체(first-class object)입니다. 워크플로우의 모든 단계는 명시적이고, 검사 가능하며, 버전 관리가 가능한 컨텍스트를 가집니다. 모델 호출 전후에 무엇이 입력되고 출력되는지 정확히 확인할 수 있습니다. 둘째, 멀티 모델 라우팅(multi-model routing)은 프리미엄 추가 기능이 아닌 핵심 기능입니다. 사용자가 역량 요구사항을 정의하면, 시스템이 적절한 모델로 라우팅합니다. 셋째, 실패에 대한 계측(instrumentation)이 첫날부터 이루어집니다. 모든 실행은 단계별 원시 요청(raw request), 원시 응답(raw response), 지연 시간(latency), 그리고 비용을 로그로 남깁니다. 무언가 고장 났을 때 — 그리고 반드시 고장 나게 되어 있습니다 — 당신은 디버깅을 위한 실제 데이터를 갖게 됩니다.

추상화 계층(abstraction layer)은 정직합니다. 일반적인 사례를 위한 GUI(그래픽 사용자 인터페이스)가 있으며, 그 외의 모든 상황을 위해 깔끔한 코드 탈출구(code escape)가 마련되어 있습니다. 이 두 모드는 동일한 기본 데이터 모델(underlying data model)을 공유하므로, 모드 간 전환이 워크플로우(workflow)를 다시 작성해야 함을 의미하지는 않습니다.

또한 저는 워크플로우가 단순히 실행되는 것에 그치지 않고 시간이 지남에 따라 개선되어야 한다는 가정하에 제품을 구축하고 있습니다. 프롬프트 버전 관리(Prompt versioning), 출력 비교(output comparisons), 그리고 단계별 비용 추적(step-level cost tracking)은 분석용 애드온(analytics add-ons)이 아니라 제품의 핵심 기능(core product)에 포함되어 있습니다.

이 중 어느 것도 마법이 아닙니다. 이는 그동안 너무 빠르게 움직이느라 이를 실천하지 못했던 제품 카테고리에 엔지니어링 규율(engineering discipline)을 적용한 것뿐입니다. 목표는 첫 번째 실제 사용 사례(use case)를 마주한 뒤 한계를 드러내는 도구가 아니라, 사용하면 할수록 더 좋아지는 도구를 만드는 것입니다.

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