3주를 쏟아부은 AI 워크플로우가 어느 토요일 오전에 무너졌다. Zapier의 레이트 리밋이 바뀌었고, OpenAI 응답 포맷이 살짝 달라졌으며, '스마트'하다고 믿었던 프롬프트는 존재하지 않는 회사 이름을 지어내기 시작했다. 자동화가 절약해줘야 할 시간을 디버깅에 고스란히 써버린 셈이다. dev.to의 'Why Most AI Workflow Apps Fail' 저자가 이 경험을 꺼내며 던지는 말이 정확하다. "이건 도구의 문제가 아니라 설계의 문제다."
첫 실행의 마법, 백 번째 실행의 균열
AI 워크플로우 도구들이 공유하는 치명적인 패턴이 있다. 온보딩은 화려하고, 데모는 매끄럽고, 첫 실행은 마법처럼 작동한다. 문제는 그 이후다. 레이턴시는 API 호출 하나일 때는 '충분히 빨랐지만' 다섯 개를 체이닝하면 고통스러워진다. 1월에 잘 작동하던 프롬프트 템플릿은 모델이 업데이트되면 슬금슬금 품질이 떨어진다. 테스트 중엔 보이지 않던 레이트 리밋은 실제 운영에서 워크플로우 전체의 천장이 된다. 프로덕트 팀이 엔지니어링 사이클을 온보딩 경험에 집중하고 '열 번째 세션을 첫 번째보다 낫게 만드는 것'은 우선순위에서 밀어내기 때문이다.
추상화 레이어의 거짓말
'노코드'를 표방하는 시각적 캔버스는 해피 패스를 벗어나는 순간 균열을 드러낸다. Gmail 트리거를 GPT-4에 연결하고 Slack으로 보내는 데모는 완벽하다. 하지만 이메일에 PDF 첨부파일이 붙거나, 모델이 예상치 못한 필드가 포함된 JSON을 반환하는 순간 "절대 문서를 읽을 필요 없다"던 도구의 문서를 뒤지고 있는 자신을 발견한다. LLM 호출을 결정론적 함수처럼 취급하는 추상화 레이어는 반드시 새어나온다. AI 출력은 본질적으로 확률적이고 가변적이기 때문이다. 살아남는 도구들의 공통점은 하나다. 내부를 숨기지 않는다. 원시 프롬프트, 실제 API 호출, 그리고 필요할 때 코드로 내려갈 수 있는 탈출구를 제공한다.
컨텍스트는 설정이 아니라 제품 그 자체다
AI 워크플로우의 근본적 가치 단위는 컨텍스트다. 모델이 어떤 정보에 접근하는지, 어떤 형태로, 체인의 어느 지점에서 전달받는지가 결과의 품질을 결정한다. 그런데 대부분의 도구는 컨텍스트를 정적 입력처럼 다룬다. 시스템 프롬프트 텍스트박스 하나, 인풋 슬롯 하나, 나머지는 문자열 연결과 희망으로 때운다. 첫 번째 초안을 작성하는 데 필요한 컨텍스트와 QA 패스를 하는 데 필요한 컨텍스트는 다르다. 고객 대상 요약과 내부 요약이 필요로 하는 컨텍스트도 다르다. 컨텍스트를 단계별로 스코핑하고, 버전 관리하고, 품질 변화를 측정할 수 있어야 진짜 워크플로우 도구다.
뇌를 인프라로 쓰지 않는 법
프리랜서 개발자의 관점에서 이 문제는 다른 얼굴로 나타난다. dev.to의 또 다른 글 'Freelancing Got Easier When I Stopped Carrying the Whole Project in My Head'는 AI 도구 자체의 설계 문제보다 개발자 자신의 워크플로우 설계를 다룬다. 핵심 통찰은 이것이다. "AI는 레버리지이지 질서가 아니다. 워크플로우가 이미 잘 정돈되어 있으면 AI가 그것을 증폭시킨다. 워크플로우가 엉망이면 AI는 그 엉망을 놀라운 효율로 증폭시킨다." Cursor와 Codex를 사용하는 프리랜서 개발자가 얻은 가장 큰 이득은 코드 생성 속도가 아니었다. 프로젝트 컨텍스트를 더 빠르게 저장하고 복원하는 것, 즉 일을 시작하는 마찰을 줄이는 것이었다. 시작 비용이 낮아지면 실제로 더 많이 일하게 된다. 이것이 운영 레버리지다.
토큰 압축은 설계 문제의 물리적 표현이다
컨텍스트 설계 문제는 토큰 비용이라는 형태로도 실체화된다. 이탈리아 고교생 개발자가 기말고사 기간 중 만든 TITAN(Token Intelligence Through Agent Narrowing)은 이 문제를 정면으로 겨냥한다. 긴 세션이 누적될수록 컨텍스트 윈도우는 장황한 모델 추론과 필터링되지 않은 터미널 로그로 가득 차고, LLM은 '중간에서 길을 잃기' 시작한다. TITAN은 세 가지 압축 레이어로 이에 대응한다. 언어적 압축(불필요한 헤징 표현과 관사 제거), 구조적 코드 압축(YAGNI에서 시작해 최소한의 해결책만 작성하는 6단계 사다리), 그리고 컨텍스트 압축(메모리 파일 후처리, 터미널 스트림 필터링)이다. 인상적인 건 결과보다 철학이다. 제로 외부 의존성, Node.js 표준 라이브러리만 사용, 압축이 추론 품질을 저하시키지 않는지 검증하는 UID(Usable Intelligence Density) 지표까지 내장했다. 도구 하나를 만들면서도 설계 원칙을 먼저 세웠다.
워크플로우 설계자로서의 프론트엔드 개발자
세 사례가 교차하는 지점에 실용적인 시사점이 있다. AI 워크플로우에서 실제로 마주치는 마찰은 대부분 도구의 한계가 아니라 설계의 부재에서 온다. 실패 가시성(무엇이 왜 어느 단계에서 실패했는지), 프롬프트 버전 관리(변경 전후 출력 차이 추적), 단계별 컨텍스트 스코핑, 모델 라우팅(각 단계에 적합한 모델 배정), 비용 추적(단계별 API 지출 파악), 코드로의 탈출구—이 여섯 가지를 갖추지 못한 도구 위에 쌓은 워크플로우는 규모가 커질수록 반드시 고통스러워진다. 프론트엔드 개발자에게 이 관점이 특히 중요한 이유가 있다. 우리는 도구를 선택하는 사람이기도 하지만, 동시에 사용자를 위한 AI 워크플로우를 설계하는 사람이기도 하기 때문이다. 우리가 경험한 설계의 부재를 사용자에게 그대로 전가하지 않으려면, 먼저 그 마찰을 직접 겪어보고 이해해야 한다.
지금 당장 확인해야 할 것
AI 워크플로우를 설계하거나 도구를 선택하기 전, 자신에게 먼저 물어볼 질문들이 있다. 이 도구는 실패가 어느 단계에서 일어났는지 정확히 보여주는가? 프롬프트를 롤백할 수 있고, 변경 전후 출력을 비교할 수 있는가? 워크플로우의 각 단계가 서로 다른 컨텍스트를 가질 수 있는가? GUI가 부족할 때 코드로 내려갈 수 있으며, 그 전환이 기존 작업을 무너뜨리지 않는가? 도구가 이 질문들에 두 개 이상 답하지 못한다면, 규모가 커질수록 반드시 대가를 치르게 된다. AI 워크플로우는 쓰는 것이 아니라 설계하는 것이다. 그 설계는 첫 번째 실행이 작동하는 날이 아니라, 백 번째 실행이 여전히 신뢰할 수 있는 날을 기준으로 판단해야 한다.