워크플로우에 AI를 본격적으로 통합하기 시작했을 때, 필자는 ‘모든 것을 해결해 주는 하나의 툴’이라는 약속에 매료됐다. 한 번의 로그인, 한 번의 워크플로우, 그리고 조사·글쓰기·운영·커뮤니케이션까지 모두 관리해 주는 단일 플랫폼. 이론적으로는 깔끔하고 우아했다. 그러나 시간이 지나며 그 선택이 함정이었다는 사실을 깨달았다.

무너진 것은 모두 타협할 수 없는 요소였다. 깊이와 뉘앙스, 그리고 신뢰성. 심층 리서치부터 대외 커뮤니케이션용 문장 작성, 자동화 오케스트레이션까지 모든 작업을 하나의 AI 플랫폼에 억지로 맡기려는 순간, 보이지 않는 벽에 부딪혔다. 리서치는 얕아졌고, 글은 획일화됐으며, 운영 워크플로우는 쉽게 깨지는 구조가 됐다. 하나의 AI 툴로 모든 요구를 충족시키는 것은 불가능하다는 결론에 이르렀다.

이후 필자의 사고방식에도 변화가 찾아왔다. 단일 플랫폼 중심 사고방식에서 벗어나 ‘스택’ 중심으로 전환한 것이다. 각 툴에 명확한 역할을 부여해 전문화된 툴을 선별했고, 이를 조합해 더 유연하고 회복력이 뛰어나며 실제 환경에서 훨씬 효과적인 워크플로우를 구축했다. 단일 해법을 좇는 대신, 목적에 맞는 툴을 쌓아 올리는 방식이 오히려 현실적이었다.

단일 플랫폼이라는 함정

처음에는 하나의 AI 플랫폼만 사용하는 방식이 효율적으로 느껴졌다. 모든 것이 한 지붕 아래에 모여 있었다. 여러 계정을 오갈 필요도 없고, 형식이 어긋날 일도 없었다. “AI야, 내가 간다”라는 생각이 자연스럽게 들었다. 작업 환경은 깔끔했고, 시대의 흐름에 잘 맞는 선택인 것 같았다.

하지만 균열은 생각보다 빠르게 드러났다. 가장 먼저 무너진 것은 리서치의 깊이였다. 특정 임원의 이력과 배경을 살펴보고 핵심 주제를 뽑아내며, 맥락을 정리하는 이른바 ‘심층 리서치’를 플랫폼에 맡겼다. 이어 같은 시스템에 이를 바탕으로 아웃리치용 문안이나 포지셔닝 문서, 자동화 단계로 전환해 달라고 요청했다.

겉으로 보기에는 결과물이 그럴듯했다. 그러나 시간이 지날수록 일정한 패턴이 눈에 들어왔다.

• 리서치는 폭넓었지만, 예외적인 맥락과 미묘한 차이를 놓쳤다.
• 글은 안전하고 무난했지만, 개성과 브랜드 색채가 없고 지나치게 획일적이었다.
• 운영 워크플로우는 돌아가기는 했지만, 조금만 확장하면 쉽게 흔들리거나 수작업에 의존하게 됐다.

무엇보다 가장 큰 문제는 따로 있었다. 의미 있는 일을 해내는 데 쓰는 시간보다, 플랫폼의 한계를 우회하거나 문제를 해결하는 데 더 많은 시간을 쏟고 있었던 것이다.

전환점은 CoS(Chief of Staff)를 보좌하는 ‘에이전틱’ 워크로드를 돌려보려 했을 때 찾아왔다. 필자는 이 에이전트에 ‘아일라(Isla)’라는 이름을 붙였다. 계획은 단순했다. 하나의 AI가 처음부터 끝까지 모든 과정을 처리하는 것이었다. 이메일 스레드를 읽고, 맥락을 파악하며, 답장을 초안으로 작성하고, 후속 조치를 실행 가능한 작업으로 전환하는 역할까지 맡기려고 했다. 작업량이 상당했지만, 잘못될 리 없다고 생각했다.

그러나 아일라의 작동 방식을 면밀히 들여다보자 문제가 보였다. 세부적인 부분이 완전히 흐트러져 있었다. 맥락 정확도는 급격히 떨어졌고, 대화 스레드는 잘못 연결됐으며, 요약 과정에서는 뉘앙스가 사라졌다. 후속 조치 역시 핵심적인 미묘함을 제대로 담아내지 못했다. 전체 스레드 재호출, 이름 매칭, 신뢰도 점수 부여 등 여러 방식으로 보완을 시도했지만, 프롬프트를 아무리 정교하게 다듬어도 근본적인 한계는 그대로였다. 하나의 플랫폼으로는 인간의 판단과 맥락 이해, 계층적인 논리가 결합된 복잡한 파이프라인을 흉내 내기 어렵다는 사실이 분명해졌다.

그 순간 질문이 바뀌었다. “어떻게 하나의 툴로 모든 일을 하게 만들 것인가”가 아니라, “각 작업에 맞게 설계된 툴은 무엇인가”를 묻기 시작했다.

보이지 않던 맹점의 발견

‘모든 것을 해결하는 하나의 툴’을 추구하지 않아도 된다고 생각한 순간, 사고방식은 자연스럽게 스택 중심으로 전환됐다. 각기 다른 역할에 최적화된 전문 툴을 선별해 조합하고, 각자가 가장 잘하는 일을 맡도록 하는 방식이었다.

진짜 깨달음은 여기에 전용 리서치 엔진을 하나 추가했을 때 찾아왔다. 이전에는 전혀 보이지 않던 간극들이 드러나기 시작했다. 예를 들면,

• 한 임원이 지난해에 했던 발언과 불과 한 달 전 발언 사이의 모순을 찾아냈다.
• 소규모 업계 팟캐스트나 잘 알려지지 않은 인터뷰, 특정 분야의 전문 글에 숨어 있던 틈새 관점을 발견했다.
• 공식적인 이력에서는 드러나지 않던 전략적 긴장 관계를 감지했다.

이는 리서치 품질이 개선된 차원이 아니었다. 인식할 수 있는 현실 자체가 달라졌다. 이전에는 프롬프트를 잘못 작성한 탓이라고 여겼던 문제가 실제로는 하나의 툴을 지나치게 광범위하게 사용한 데서 비롯된 한계였다는 사실이 분명해졌다. 스택을 구축하는 방식이야말로 가장 합리적인 선택이라는 확신이 들었다.

축적이 아닌 선별이 핵심

스택 사고는 반짝이는 새로운 툴을 닥치는 대로 모으는 일이 아니다. 선별이 핵심이다. 필자는 이제 툴을 사람을 채용하듯 대한다. 각 툴은 분명한 역할에 특화돼 있어야 하고, 그만한 가치를 가져와야 한다. 필자가 툴을 스택에 포함시키기 전에 던지는 질문은 다음과 같다.

• 이 툴은 어떤 일을 유독 잘하는가? 조금 더 나은 수준이라면 자리를 줄 이유가 없다.
• 시간이 지날수록 효과가 누적되는가? 일회성 성과보다 매주 반복되는 시간 절감이 더 중요하다.
• 기존 워크플로우의 리듬을 깨뜨리지 않고 통합될 수 있는가? 습관을 다시 설계해야 한다면, 최소한 10배 이상의 보상이 필요하다.

대부분은 첫 번째 질문에서 탈락한다. 이들은 전문 툴을 자처하지만, 실제로는 범용 툴에 가깝다. 필자에게 필요한 것은 ‘웬만한 건 다 하는’ 모델이 아니다. 단 하나의 영역에서 압도적인 성능을 발휘하는 존재다. 기준은 단순하다. 한 문장으로 그 툴의 고유한 역할을 설명할 수 없다면, 스택에 오를 자격이 없다.

여러 툴을 하나처럼 관리하기

멀티 툴 스택은 이론적으로는 우아해 보여도 실제로는 복잡하다. 여러 툴을 함께 쓰다 보면 맥락 전환이 잦아지고 형식이 어긋나며, 데이터 전달 과정에서 마찰이 발생한다. 이런 오버헤드를 방치하면 위험 요소로 작용한다.

필자가 찾은 해법은 하나였다. 엄격한 규율과 구조화된 오케스트레이션이다. 다음과 같은 원칙을 기준으로 워크플로우를 설계했다.

• 툴 간에 고정된 입력·출력 스키마를 정의한다.
• 시스템 간 변환을 담당하는 오케스트레이터 프롬프트는 최소한으로 유지한다.
• 툴 간 자유로운 대화는 피한다. 모든 과정은 예측 가능하고, 테스트 가능하며, 교체 가능한 프레임워크를 거친다.

필자는 속도와 추진력을 위해 한 플랫폼에서 대규모 사이트를 구축한 적이 있다. 리플릿에서 800MB가 넘는 프로젝트를 빠르게 만들어냈지만, 최종 호스팅 환경으로는 적합하지 않았다. 프로덕션 수준의 아키텍처를 다루기 위해서는 전혀 다른 스택이 필요했다. 그러나 특정 플랫폼에 집착하지 않고 ‘벤치(bench)’ 관점으로 구축했기 때문에 기존 결과물을 과감히 분리해 옮기고 다시 구성하는 작업은 쉬웠다.

필자가 정의하는 자유란 ‘업체 종속성에서 벗어날 수 있는 독립성, 이동성과 신뢰성’이다. 필자의 워크플로우와 비즈니스는 특정 툴의 로드맵이 아니라, 스스로 정한 기준 위에서 작동한다.

전문성을 적재적소에 연결

처음으로 ‘AI 툴 벤치(tool bench)’를 구축하려 한다면, 툴부터 고르지 말고 기능부터 정의해야 한다. 핵심은 각 기능을 신중하게 구분해 매핑하는 것이다. 예를 들면 다음과 같다.

• 리서치 및 감지 : 범위, 정보 수집, 검증
• 종합 및 추론 : 모호성 처리 능력과 다단계 논리
• 제작 : 톤, 형식, 미디어 출력
• 운영 및 자동화 : 라우팅, 트리거, 작업 지속성

문제는 이들 기능이 뒤섞일 때 발생한다. 리서치 엔진에 마케팅 카피라이터처럼 글을 쓰길 기대하거나, 글쓰기 엔진에 워크플로우 관리를 맡기거나, 자동화 툴이 인간처럼 추론해 주길 바라는 경우다. 이런 기대는 모두 평균 이하의 결과로 이어진다. 팔방미인이지만 어느 한 분야의 달인은 아니다.

필자는 실제 운영 과정에서도 단일 에이전트에 의존하지 않는다. 각 기능을 분리해 역할이 명확한 여러 에이전트로 나눠 운용하는 방식이 훨씬 더 효과적이다.

스택을 올바르게 관리하는 방법

AI 기술이 빠르게 진화하면서 새로운 출시나 차세대 플랫폼을 따라가고 싶은 유혹은 늘 존재한다. 그러나 필자는 그렇게 하지 않는다. 대신 툴 벤치를 하나의 제품 로드맵처럼 다룬다. 체계적이고, 현실적이며, 구성 또한 다양하게 유지한다.

필자는 새로운 툴을 검토할 때 다음과 같은 기준을 따른다.

• 현재 스택에서 마찰이 발생하거나 성능의 한계가 드러나는 지점을 먼저 찾는다.
• 신규 툴은 샌드박스 워크플로우에서 시험한다. 범위를 제한하고, 통제된 환경에서, 기존 시스템과 분리해 검증한다.
• 화제성이나 인상이 아니라, 실제 활용 과정에서의 전후 성능 차이를 기준으로 효과를 측정한다.
• 기존 툴과 기능이 크게 겹치는데도 압도적인 우위를 보여주지 못한다면 과감히 제외한다.

이와 같은 규율 아래 반복적 접근 방식을 유지하면 아키텍처는 탄탄해진다. 하나의 올인원 시스템이 갖는 구조적 취약성에서 벗어나 변화 속에서도 쉽게 흔들리지 않는 스택을 유지할 수 있기 때문이다.

‘성’이 아니라 ‘벤치’를 구축하라

오늘날 비즈니스 운영과 콘텐츠 제작, 자동화, 장기 전략을 위해 AI를 활용하고 있다면 ‘하나의 플랫폼으로 모든 것을 해결할 수 있다’는 신화를 경계하기를 바란다. 매력적이고 단순해 보이는 발상이지만, 그 단순함은 뒤에 취약점이 숨어 있을 수 있다.

그 대신 스택 사고를 고려해 보라. 어떤 툴이 어떤 역할을 맡을지 의도적으로 설계하고, 벤치를 주기적으로 정리하라. 스키마를 정의하고, 툴 간 전달 과정을 표준화하며, 화제성보다 워크플로우에 얼마나 잘 맞는지를 기준으로 선택하라.

AI가 꼭 하나의 거대한 덩어리일 필요는 없다. 현실의 마찰을 전제로 설계된, 회복력 있고 유연한 구조면 충분하다. 성처럼 단단한 단일 플랫폼이 아니라 교체 가능한 벤치를 구축할 때 얻는 이점은 명확함, 품질, 그리고 자유다. 끊임없이 변화하는 환경에서 이는 어떤 단일 툴보다 훨씬 강력한 경쟁력이 된다.
dl-itworldkorea@foundryco.com