당신이 이미 쌓고 있는 (그리고 인지하지 못하는) AI 워크플로우 부채

지난 화요일, 저는 11개의 브라우저 탭을 열어두고 있었습니다. 초안 작성을 위한 Claude, 제2의 의견을 위한 ChatGPT, 리서치를 위한 Perplexity, 코딩을 위한 Cursor, 팀원이 11월에 만들었지만 아무도 문서화하지 않은 커스텀 GPT 래퍼(wrapper), 두 개의 서로 다른 API 플레이그라운드(playgrounds), 그리고 이 도구들 중 어느 것도 서로 통신하지 않기 때문에 의사 메모리(pseudo-memory) 역할을 하는 4개의 마크다운(markdown) 파일까지 말이죠. 저는 기능을 출시했습니다. 하지만 원래 걸렸어야 할 시간보다 3시간이 더 걸렸습니다. 아무도 이를 문제라고 부르지 않았습니다. 왜냐하면 그것이 현재 AI와 함께 일하는 모습, 즉 근육 기억(muscle memory)으로 지휘하는 덕테이프 오케스트라와 같기 때문입니다. 그것은 워크플로우(workflow)가 아닙니다. 그것은 워크플로우 부채(workflow debt)이며, 이는 복리로 쌓입니다.

탭 문제는 사실 멘탈 모델(Mental-Model)의 문제이다

아무도 겉으로 말하지 않는 사실이 있습니다. 개발자들이 10개의 AI 도구를 저글링하듯 다루는 이유는 "최고의" 도구가 없기 때문이 아닙니다. 각 도구가 자신만의 세션, 자신만의 컨텍스트 윈도우(context window), 자신만의 인터페이스에 최적화되어 있기 때문이며, 인간이 머릿속에서 모든 통합 작업을 수행하고 있기 때문입니다.

이는 우리가 2012년 SaaS를 사용할 때 저질렀던 것과 동일한 실수입니다. 모든 팀은 프로젝트 관리 도구, 별도의 문서 도구, 별도의 커뮤니케이션 도구, 그리고 별도의 시간 추적 도구를 가지고 있었습니다. 도구들은 개별적으로는 괜찮았습니다. 통합 비용은 눈에 보이지 않았으나, 누군가 회사를 떠나고 나서야 비로소 발견되었습니다. 도구들이 상태(state)를 공유하지 않았기 때문에 조직의 지식 절반이 그 사람의 머릿속에만 존재한다는 사실을 깨닫게 된 것입니다.

현재의 AI 도구들은 바로 그 통합 전 단계에 머물러 있습니다. 당신이 바로 통합 계층(integration layer)입니다. 당신의 클립보드(clipboard)가 API이며, 당신의 브라우저 탭이 워크플로우 엔진입니다. 당신은 스스로를 자신의 툴체인(toolchain)의 핵심 경로(critical path)로 만들어 버렸습니다. 이는 당신이 자리에 없거나 과부하가 걸리는 순간, 워크플로우가 붕괴됨을 의미합니다.

컨텍스트 윈도우(Context Windows)가 컨텍스트 관리(Context Management)를 대체할 수는 없다

몇 달마다 누군가는 마치 그것이 문제를 해결할 것처럼 더 큰 컨텍스트 윈도우 (Context Window)를 발표합니다. 하지만 그렇지 않습니다. 200K 토큰의 컨텍스트 윈도우가 있다고 해서 Claude가 지난주 목요일 당신이 Perplexity 세션에서 내린 결정을 알려주는 것은 아닙니다. 3주 전에 당신이 특정 아키텍처 (Architecture)를 거부했다는 사실도 알지 못합니다. 당신의 PM이 Slack에서 지나가는 말로 언급하여 당신이 내리는 모든 기술적 결정에 조용히 영향을 미치고 있는 그 제약 사항도 기억하지 못합니다.

컨텍스트 관리 (Context Management)는 메모리 (Memory)의 문제가 아닙니다. 그것은 아직 존재하지 않는 워크플로우 프리미티브 (Workflow Primitive)입니다.

현재 개발자들이 하고 있는 일은 컨텍스트를 수동으로 유지하는 것입니다. 세션 간에 요약본을 복사하여 붙여넣거나, 프롬프트 (Prompt) 상단에 "배경 컨텍스트 (Background Context)" 섹션을 작성하거나, 주요 작업을 수행하기 전에 Notion에 적어둔 노트를 복사하여 붙여넣는 식입니다. 이는 확장 가능하지 않으며 (Not scalable), 조합 가능하지도 않습니다 (Doesn't compose). 다른 팀원을 추가하거나, 다른 AI 에이전트 (AI Agent)를 추가하거나, 다른 도구를 추가하는 순간 컨텍스트 동기화 비용은 배로 늘어납니다.

진정한 돌파구는 더 긴 밧줄을 얻는 것이 아니라, 밧줄을 아예 들고 다닐 필요가 없게 만드는 것입니다.

에이전트 (Agents)는 프로덕션 준비가 되었지만, 오케스트레이션 (Orchestration)은 그렇지 않다

2026년의 에이전틱 AI (Agentic AI)는 진정으로 인상적입니다. 키보드에 손을 대지 않고도 코드를 작성하고, 테스트하고, 반복 개선하는 Cursor 에이전트를 실행할 수 있습니다. Claude Projects를 사용하여 세션 전반에 걸쳐 소프트 컨텍스트 (Soft Context)를 유지할 수 있습니다. OpenAI의 오퍼레이터 스타일 (Operator-style) 에이전트는 당신이 API화하고 싶지 않은 인터페이스를 직접 클릭하며 작동할 수 있습니다.

하지만 두 개의 에이전트가 협력해야 하는 순간 — 예를 들어, 리서치 에이전트가 발견한 내용을 코딩 에이전트에게 전달하고, 그 코딩 에이전트가 다시 문서화 에이전트를 업데이트하기를 원하는 순간 — 당신은 오케스트레이션 코드 (Orchestration Code)를 직접 작성하거나, 상태 (State)가 어떻게 흘러가야 하는지에 대해 서로 다른 의견을 가진 네 가지 경쟁 프레임워크 (Framework) 중 하나를 사용해야만 합니다.

LangChain, LlamaIndex, AutoGen, CrewAI: 각각은 진정으로 유용하지만, 각각은 당신이 그 추상화 (Abstractions)를 학습할 것을 요구하며, 그 중 어느 것도 에이전트 (Agents)가 컨텍스트 (Context)를 공유하고, 완료 신호를 보내거나, 실패를 우아하게 처리해야 하는 방식에 대해 합의를 이루지 못했습니다. 우리는 에이전트 프레임워크 (Agent Frameworks)의 캄브리아기 대폭발 (Cambrian explosion) 단계에 있으며, 이는 흥미로운 일이기도 하지만 지금 당신이 내리는 어떤 프레임워크에 대한 선택도 그 반감기 (Half-life)가 불분명하다는 것을 의미합니다.

실질적으로 이는 현재 승리하고 있는 빌더 (Builders)들이 완벽한 프레임워크를 찾아낸 사람들이 아니라는 것을 의미합니다. 그들은 오케스트레이션 로직 (Orchestration logic)을 얇게 유지하고, 에이전트 인터페이스 (Agent interfaces)를 단순하게 유지하며, 탈출구 (Escape hatches)를 명확하게 만들어 둔 사람들입니다.

프롬프트는 새로운 설정 파일이다 (설정 파일처럼 다루라)

만약 당신이 한 프로젝트에서 다른 프로젝트로 프롬프트 (Prompt)를 복사해서 붙여넣었다가 완전히 다른 동작을 경험한 적이 있다면, 이를 직접 겪어본 것입니다. 프롬프트는 단순히 지침 (Instructions)일 뿐만 아니라, 그것이 작성된 환경의 축적된 컨텍스트 (Context), 제약 조건 (Constraints), 그리고 암묵적인 가정 (Implicit assumptions)이기 때문에 이식성 (Portable)이 없습니다.

대부분의 팀은 프롬프트를 일시적인 것으로 취급합니다. 그것들은 코드 주석, Notion 페이지, 6개월 전의 Slack 메시지 속에 존재합니다. 아무도 그것들을 버전 관리 (Versioning)하지 않습니다. 아무도 그것들을 리뷰 (Review)하지 않습니다. 아무도 코드를 소유하는 방식처럼 그것들을 소유하지 않습니다.

이것은 '일단 출시하자 (Ship-it-now)'는 비용이며, 나중에 온콜 (On-call) 문제로 나타납니다. 모델이 업데이트되었거나, 컨텍스트 가정 (Context assumption)이 바뀌었거나, 누군가가 시스템 프롬프트 (System prompt)를 "그냥 살짝 수정"했기 때문에 AI의 동작이 변할 때, 당신에게는 차이점 (Diff), 롤백 (Rollback), 감사 추적 (Audit trail)이 없습니다.

프롬프트는 코드와 동일한 엔지니어링 규율 (Engineering discipline)이 필요합니다: 버전 관리 (Version control), 리뷰 (Review), 스테이징 대 운영 (Staging vs. Production), 관측 가능성 (Observability). 이를 가장 먼저 깨닫는 팀은 다른 모든 이들이 추측에 의존하는 동안 자신들의 AI 동작을 디버깅 (Debuggable)할 수 있기 때문에 복리 효과가 있는 우위를 점하게 될 것입니다.

프레임워크: 지금 당장 당신의 AI 워크플로우를 감사하기 위한 5가지 질문

새로운 것을 구축하기 전에, 현재의 워크플로우를 다음 항목에 따라 실행해 보십시오:

• 컨텍스트(Context)가 어디에 머물고 있는가? 만약 답이 "내 머릿속" 또는 "내 클립보드"라면, 그것이 가장 먼저 해결해야 할 문제입니다.
• 당신이 자리에 없을 때는 어떤 일이 발생하는가? 만약 팀원이 문서만 보고 당신의 AI 워크플로우(Workflow)를 재현할 수 없다면, 당신은 단일 장애점(Single-point-of-failure)을 가지고 있는 것입니다.
• 하나의 작업을 수행하기 위해 얼마나 많은 도구를 거치는가? 작업의 전달(Handoff) 횟수를 세어보십시오. 전달 단계 하나하나가 지연 시간(Latency), 컨텍스트 손실, 그리고 잠재적인 실패 지점입니다.
• 프롬프트(Prompt)에 버전이 관리되고 있는가? 만약 지난주에 프롬프트를 변경한 후 성능이 저하되었다면, 5분 이내에 이전 상태로 되돌릴(Rollback) 수 있습니까?
• 에이전트(Agent)가 틀렸을 때 무엇을 하는가? 만약 실패 모드가 침묵형(에이전트가 잘못된 출력을 자신 있게 생성하는 경우)이라면, 이는 시스템이 완전히 중단되는 것보다 더 나쁩니다.

이 질문들에 답하며 불편함을 느꼈다면, 당신이 뒤처진 것이 아닙니다. 단지 업계의 실제 현주소를 정직하게 마주하고 있을 뿐입니다.

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

위의 문제들은 철학적인 문제가 아닙니다. 이는 구체적인 엔지니어링 문제이며, 제가 지난 8개월 동안 해결하기 위해 구축해 온 바로 그 문제들입니다.

AI Handler는 세 가지 가설(Bet)을 바탕으로 구축되었습니다:

첫 번째 가설: 제품은 모델이 아니라 워크플로우(Workflow)다. 당신이 사용하는 모델은 아키텍처 결정 사항이 아니라 설정(Configuration)의 선택 사항이어야 합니다. AI Handler를 사용하면 워크플로우를 다시 작성할 필요 없이 비용, 지연 시간(Latency), 성능에 따라 작업을 적절한 모델로 라우팅(Routing)할 수 있습니다. 모든 곳을 수정할 필요 없이, 한 곳에서 Claude를 GPT-4o로 교체할 수 있습니다.

두 번째 가설: 컨텍스트(Context)는 일급 시민(First-class citizen)이다. AI Handler의 모든 세션은 도구와 에이전트 전반에 걸쳐 유지되는 구조화된 컨텍스트를 유지합니다. 요약본을 붙여넣을 필요가 없습니다. 새로운 세션마다 프로젝트를 다시 설명할 필요도 없습니다. 컨텍스트는 범위(Scope)가 지정되고, 버전이 관리되며, 팀원 또는 워크플로우 내의 다른 에이전트와 공유할 수 있습니다.

세 번째: 프롬프트는 엔지니어링(Engineering)을 받을 가치가 있습니다. AI Handler는 프롬프트를 코드 산출물(Code artifacts)로 취급합니다: 버전 관리(Version-controlled)가 가능하고, 검토(Reviewable) 가능하며, 테스트(Testable)할 수 있습니다. 실제 작업에 대해 프롬프트 변형(Prompt variants)을 A/B 테스트할 수 있고, 프롬프트가 변경될 때 차이점(Diffs)을 확인할 수 있으며, 무언가 잘못되었을 때 롤백(Roll back)할 수 있습니다. 이는 아무도 처음부터 직접 만들고 싶어 하지 않는 지루한 인프라 작업이기에, 제가 한 번에 구축하고 있습니다.

목표는 여러분이 이미 사용 중인 도구들을 대체하는 것이 아닙니다. Cursor는 훌륭합니다. Claude도 훌륭합니다. 목표는 여러분 자신이 통합 계층(Integration layer)이 되는 것을 멈추는 것입니다. 즉, 여러분의 워크플로우가 실제로 살아 숨 쉬고, 컨텍스트(Context)가 자동으로 흐르며, 여러분의 AI 스택(AI stack)이 무엇을 하고 있는지 확인하고 디버깅(Debug)할 수 있는 공간을 제공하는 것입니다.

제가 이를 공개적으로 구축(Building in public)하는 이유는 피드백 루프(Feedback loop)가 더 빠르기 때문이며, 이 글을 읽고 있는 분들이야말로 제가 틀렸을 때 정확히 지적해 줄 분들이라고 생각하기 때문입니다.

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