Amazon의 AI는 화염병 제조법을 알려주었다. 나는 그 원인을 안다.
어느 날 잠재 고객——Amazon은 아니지만 그에 견줄 만큼 큰 대형 e커머스 기업——과 통화하던 중, 해당 기업의 엔지니어링 부사장이 던진 한마디에 저는 마시던 커피를 내려놓을 수밖에 없었습니다.
"저희 AI 어시스턴트는 기본적으로 완성되었습니다. 프롬프트를 미세 조정해 줄 사람만 있으면 됩니다."
이전에도 이런 말을 들어본 적이 있습니다. 엔터프라이즈 AI가 프롬프트 엔지니어링의 문제에 불과하다는 믿음 말입니다. 파운데이션 모델을 가져와 '도움이 되고, 안전하며, 이상한 말은 하지 말라'는 시스템 프롬프트로 감싼 뒤 제품 카탈로그와 연결하여 배포하면 그만이라는 생각입니다. 예전에는 사람들이 그렇게 말할 때 예의 바르게 고개를 끄덕이곤 했습니다. 하지만 2024년 Amazon의 Rufus 출시가 파국을 맞는 모습을 지켜본 후——Super Bowl 개최지를 엉뚱하게 지어내고, 일반적인 제품 검색 쿼리를 통해서도 소이 무기 제작 지침을 안내하며, 기본적인 반품 처리조차 실패하는 것을 목격한 후——저는 고개를 끄덕이는 것을 멈췄습니다.
"끝난 것이 아닙니다," 저는 그에게 말했습니다. "아직 시작조차 하지 않으셨습니다."
Rufus의 참사는 홍보(PR) 문제나 모델 품질의 문제가 아니었습니다. 그것은 아키텍처의 문제였습니다. 그리고 그것은 제가 감사했던 거의 모든 엔터프라이즈 AI 배포 내부에도 도사리고 있는 바로 그 아키텍처 문제입니다. 모델 자체는 잘 작동합니다. 모델을 둘러싼 시스템이 사상누각일 뿐입니다.
Amazon Rufus에서 실제로 무엇이 잘못되었는가?
Rufus 보도에 대해 대다수의 사람들이 오해한 점이 바로 여기에 있습니다. 언론의 헤드라인은 Super Bowl 장소 오류, 위험한 지침, 먹통이 된 반품 처리 등 생성된 결과물에만 초점을 맞추었습니다. 논평가들은 모델을 비난했습니다. "GPT는 커머스에 아직 준비되지 않았다," "LLM은 원래 환각을 일으키는데 무엇을 기대했는가?"라면서요.
하지만 저는 몇 주 동안 그 출시의 기술적 세부 사항을 낱낱이 분석했고, 모델이 주된 실패 지점이 아니었습니다. 문제는 바로 그라운딩 아키텍처(grounding architecture)였습니다.
Rufus에게 Super Bowl이 어디서 열리는지 물었을 때 어떤 일이 일어나는지 생각해 보십시오. 시스템은 웹에서 텍스트 스니펫을 가져옵니다. 일부는 최신 정보이고, 일부는 오래되었으며, 일부는 익명 포럼의 무작위 게시물입니다. 시스템은 그 스니펫들을 언어 모델에 입력합니다. 모델은 전달받은 내용을 바탕으로 답변을 합성합니다. 만약 검색 메커니즘이 상충되는 정보를 가져왔거나, 모델의 학습 데이터(지식 컷오프 시점이 존재함)가 검색된 텍스트와 모순된다면 모델은 자체적인 판단을 내려야 했습니다. 하지만 언어 모델은 판단을 내리지 않습니다. 통계적 예측을 수행할 뿐입니다.
2차 검증 계층은 존재하지 않았습니다. 교차 검증을 위한 지식 그래프도 없었습니다. "잠깐, 모델은 Super Bowl이 X 도시에서 열린다고 주장하지만 검증된 사실 데이터베이스에는 Y 도시라고 되어 있다"고 제동을 걸 수 있는 시스템이 없었던 것입니다. 모델의 근거 없는 추측이 고객에게 여과 없이 전달되었습니다.
검증 계층 없이 AI를 구축하는 것은 어시스턴트를 만드는 것이 아닙니다. 자신감에 찬 거짓말쟁이를 만드는 것입니다.
그것이 바로 제가 'LLM 래퍼(Wrapper)' 접근 방식이라고 부르는 것의 핵심 문제입니다. 강력한 생성 모델을 가져와 얇은 소프트웨어 계층으로 감싼 뒤 기도만 올리는 방식입니다.
프롬프트가 우리를 구원할 수 없음을 깨달은 밤
저는 이 사실을 명확히 깨달았던 바로 그 순간을 기억합니다. 저희는 한 고객을 위한 프로토타입을 구축하고 있었습니다. 유통업이 아니라 오답이 실질적인 피해를 낳는 전문 분야였습니다. 저희는 완벽하다고 자부했던 시스템 프롬프트를 갖추고 있었습니다. 수 페이지에 달하는 지침. "항상 출처를 인용하라. 절대 추측하지 말라. 확신이 없다면 솔직히 밝혀라."
밤 11시였고, 공동 창업자와 저는 적대적 테스트를 진행하고 있었습니다. 탈옥(jailbreak) 같은 악의적 공격이 아니라, 일상적인 질문을 살짝 변형한 표현들이었습니다. 피곤에 지친 실제 사용자가 새벽 2시에 완벽한 표준 영어가 아닌 어조로 입력할 법한 문장들이었습니다.
시스템은 작화증(confabulation) 증세를 보이기 시작했습니다. 극단적으로 위험한 것은 아니었습니다. 무기를 만들라고 하지는 않았으니까요. 하지만 존재하지 않는 제품 기능을 꾸며냈습니다. 2년 전의 반품 정책을 인용했습니다. 답변을 회피했어야 마땅한 질문에 자신 있게 오답을 내놓았습니다.
저는 공동 창업자를 돌아보며 말했습니다. "프롬프트는 제안일 뿐이야. 모델은 그걸 단순한 제안으로 취급하고 있어." 그는 로그를 살펴보더니 이렇게 답했습니다. "아니야. 모델은 프롬프트를 웅성거리는 방 안의 수많은 목소리 중 하나로 취급하고 있어. 그리고 검색된 컨텍스트의 목소리가 훨씬 더 크게 들리는 거지."
이것이 바로 Rufus 안전 사고에서 일어난 정확한 현상입니다. 시스템 프롬프트에는 '유해한 정보를 제공하지 말라'고 명시되어 있었습니다. 하지만 검색 계층은 이미 해당 정보가 포함된 웹 콘텐츠를 가져와 모델의 컨텍스트 윈도우에 주입해 버렸습니다. 모델은 안전 지침보다 방금 검색된 새로운 데이터를 우선시했습니다. 정교한 탈옥 기법은 필요하지 않았습니다. 그저 부적절한 콘텐츠를 우연히 끌어온 평범한 제품 검색 쿼리였을 뿐입니다.
프롬프트 엔지니어링을 통한 보안은 진정한 보안이 아닙니다. 그것은 막연한 희망에 불과합니다.
왜 AI는 내 반품을 처리하지 못하는가?
Rufus의 세 번째 실패——주문 상태 확인이나 반품 처리를 수행하지 못하는 문제——는 저를 가장 답답하게 만들었던 대목입니다. 왜냐하면 그것이야말로 가장 해결 가능하면서도 가장 흔한 문제이기 때문입니다.
Rufus는 하루 종일 반품 정책에 대해 말할 수는 있었습니다. 30일 환불 기간을 설명하고, 절차를 안내하며, 어떤 품목이 반품 대상인지 설명할 수 있었습니다. 하지만 실제로 고객의 주문을 조회하여 반품 절차를 시작하는 것은 불가능했습니다. 메뉴판을 읊어줄 수는 있었지만 주문을 접수하지는 못했던 셈입니다.
이것이 바로 제가 실행 격차(Action Gap)라고 부르는 현상이며, 대부분의 LLM 배포가 '텍스트 입력, 텍스트 출력' 시스템으로 안이하게 구축되어 있기 때문에 발생합니다. 반품을 정상적으로 처리하려면 AI가 안전한 데이터베이스에서 정확한 주문을 식별하고, 현재 비즈니스 규칙에 따라 반품 가능 여부를 검증하며, 완전히 성공하거나 완전히 롤백되는 상태 변경 API 호출을 실행해야 합니다. 어중간하게 처리된 반품이란 용납될 수 없습니다.
이 마지막 조건이 핵심입니다. 데이터베이스 엔지니어링에서는 이를 ACID 컴플라이언스——원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability)——라고 부릅니다. 이는 시스템이 반품 건 전체를 완벽하게 처리하거나 아니면 아예 처리하지 않아야 함을 의미합니다. 환불 처리는 완료되었는데 재고 수량이 업데이트되지 않거나, 고객은 확인 알림을 받았는데 백엔드에는 요청이 접수조차 되지 않는 사태는 결코 허용될 수 없습니다.
언어 모델에는 ACID 컴플라이언스라는 개념 자체가 없습니다. 모델은 텍스트를 생성할 뿐, 트랜잭션을 실행하지 않습니다. 그리고 Rufus 아키텍처에서 AI 계층은 트랜잭션 백엔드와 기능적으로 완전히 단절되어 있었습니다. 그 결과 나타난 것이 제가 트랜잭션 기억상실(Transactional Amnesia)이라고 부르기 시작한 문제입니다. 시스템은 액션을 약속하고 고객은 그것이 처리되었다고 믿지만, 데이터베이스에는 실제로 아무런 변경도 일어나지 않는 상태입니다.
저는 이러한 장애 패턴과 아키텍처적 해결 방안에 대해 저희의 인터랙티브 분석에서 심도 있게 기술한 바 있습니다.
아무도 이야기하지 않는 속도의 덫
Rufus 아키텍처와 관련하여 대외적으로 크게 보도되지 않았으나 많은 사실을 시사하는 기술적 세부 사항이 있습니다. Prime Day 기간 동안 Amazon의 시스템은 300밀리초라는 목표 응답 시간 내에 분당 수백만 건의 쿼리를 감당해야 합니다. 이 목표를 달성하기 위해 Rufus 팀은 맞춤형 AWS AI 칩에서 병렬 디코딩을 도입했습니다. 모델이 단어를 한 번에 하나씩 순차 생성하는 대신 미래의 여러 단어를 동시에 예측하는 기법입니다.
이로 인해 추론 속도는 두 배로 빨라졌습니다. 하지만 동시에 제가 시맨틱 드리프트(Semantic Drift)라고 부르는 위험을 동반했습니다.
여러 토큰을 병렬로 예측하게 되면, 현재의 생각을 온전히 마무리하기도 전에 문장이 어디로 향할지 성급하게 짐작하게 됩니다. 검증 메커니즘이 이러한 예측의 일관성을 검사하지만, 3억 명의 고객을 실시간 응대하기 위해 검증을 속도 중심으로 극단적으로 완화하면 경계 사례들이 여과 없이 통과됩니다. 문법적으로는 흠잡을 데 없지만 원본 데이터의 사실 관계와는 완전히 유리된 문장들이 생성되는 것입니다.
Super Bowl 장소 환각 사건에는 이러한 무리한 절충의 흔적이 고스란히 남아 있습니다. 시스템은 그럴듯함——듣기에 자연스러운가?——에 매몰되어, 정작 중요한 진실성——실제로 사실과 부합하는가?——을 희생시킨 것입니다.
엔터프라이즈 AI는 지연 시간과 정확도 사이의 치명적인 역설을 안고 있습니다. 아키텍처를 근본적으로 재설계하지 않는 한, 응답 속도를 재촉할수록 신뢰도는 떨어집니다.
Veriprajna에서 저희는 초기에 많은 반발을 무릅쓰고 한 가지 단호한 결정을 내렸습니다. 저희는 300밀리초 대신 500~800밀리초를 목표로 삼았습니다. 이 추가적인 시간 여유를 통해 다층 검증을 구현할 수 있었습니다. 생성 모델의 출력이 사용자에게 도달하기 전에 전문화된 모델들이 교차 검증을 수행하는 합의 단계입니다. 과거 한 투자자가 저에게 "사용자들은 800밀리초를 기다려주지 않을 것"이라고 지적한 적이 있습니다. 저는 한 번의 오답을 겪은 사용자는 다시는 돌아오지 않는다고 답했습니다. 이미 소비자의 45%가 정확도에 대한 우려로 인해 AI보다 사람 상담원을 선호합니다. 정확성이 결여된 속도 경쟁은 자멸의 지름길일 뿐입니다.
"이 자켓 세탁기 가능?"
Rufus 데이터에서 발견된 실패 사례 중 저를 유독 서늘하게 만드는 유형이 있습니다. Cornell Tech의 연구에 따르면 Rufus는 사용자가 아프리카계 미국인 영어, 치카노 영어, 인도계 영어로 질문을 입력했을 때 성능이 현저하게 저하되었습니다. 누군가 아프리카계 미국인 영어의 대표적 특성인 연결 동사를 생략한 채 "this jacket machine washable?"이라고 묻자, 시스템은 엉뚱하게 응답하거나 전혀 무관한 상품 페이지로 안내했습니다.
이는 결코 지엽적인 문제가 아닙니다. 전 세계 2억 5천만 명에게 서비스를 제공하는 시스템이 사용자의 말투를 이유로 차별적이고 열악한 서비스를 제공하고 있었던 것입니다.
기술적 근본 원인은 자명합니다. 언어 모델이 압도적으로 표준 미국식 영어 텍스트 위주로 학습되었기 때문입니다. 다양한 방언적 변형은 명확한 의미를 지닌 정당한 언어 체계가 아니라 노이즈나 모호성으로 치부됩니다. 하지만 해결책은 결코 단순하지 않습니다. 학습 데이터셋에 방언 데이터를 몇 줌 더 집어넣는다고 해결될 문제가 아닙니다. 저희가 방언 인식 감사(Dialect-Aware Auditing)라고 부르는 계층이 필수적입니다. 사용자의 원래 의도를 훼손하지 않으면서 입력 구문을 정규화하고, 다양한 언어적 맥락 전반에서 정기적인 레드팀(Red-teaming) 검증을 결합한 계층입니다.
저희가 이 기능을 프레임워크에 구축한 것은 고객사의 요청 때문이 아니었습니다. 집에서는 힌디어 억양의 영어를, 직장에서는 '전문적인' 표준 영어를 능숙하게 오가며 자란 저희 팀 엔지니어 한 명이 기술 매뉴얼 같은 표준 영어로만 시스템을 테스트하고 있던 저희의 맹점을 꼬집었기 때문입니다. "너희는 기술 문서처럼 글을 쓰는 사람만을 위해 제품을 만들고 있어," 그녀의 지적은 정확했습니다. 저희는 실제로 그러고 있었습니다.
진정으로 신뢰할 수 있는 시스템은 어떤 모습이어야 하는가?
Rufus 사후 분석을 거치고, 밤을 새워가며 자체 프로토타입을 테스트하고, "좋은 프롬프트와 GPT만 있으면 된다"고 우기던 투자자들과 치열하게 논쟁한 끝에, 저와 팀은 뉴로-심볼릭(Neuro-Symbolic)이라 명명한 아키텍처에 도달했습니다. 대규모 언어 모델을 강력하지만 결코 최종 권한을 갖지 않는 컴포넌트로 규정하는 시스템입니다.
여기서 가장 중요한 핵심어는 바로 비권위적(non-authoritative)이라는 개념입니다. LLM은 사용자의 질의를 이해하고 유창한 답변을 작성하는 데는 천재적입니다. 하지만 자신이 뱉은 말이 사실인지, 안전한지, 실제로 트랜잭션 실행이 가능한지 판별하는 능력은 처참할 정도로 부족합니다. 따라서 저희는 어떤 사안에 대해서도 LLM이 단독으로 최종 결정을 내리지 못하게 제한합니다.
AI의 사실 환각을 어떻게 차단하는가?
기존의 검색 증강 생성(RAG)은 질문과 표면적으로 비슷해 보이는 텍스트 조각을 긁어옵니다. 반면 저희가 구현한 인용 강제형 GraphRAG(Citation-Enforced GraphRAG)는 지식 그래프 내의 의미론적 관계(semantic relationships)를 엄격하게 추적합니다. 이 차이는 결정적입니다.
저희 시스템에서 LLM은 자신을 뒷받침하는 검증된 데이터 경로를 지식 그래프에서 확보하지 못하면 어떠한 주장도 내놓을 수 없습니다. 게이밍용 TV를 추천하고 싶으신가요? 시스템은 그래프 내에서 특정 제품과 '120Hz 주사율'이라는 특정 사양을 정확히 연결해야만 합니다. 만약 모델이 그래프에 없는 기능을 멋대로 날조하려 하면, 검증 계층이 답변이 생성되기 전에 차단합니다. 사후 수습이 아니라 사전 차단입니다.
이는 방대한 컨텍스트 윈도우 깊숙이 묻힌 정보를 LLM이 간과하는 소위 'Lost in the Middle' 문제를 원천적으로 해결합니다. 검증된 사실들이 무질서한 텍스트 덩어리가 아니라 정형화된 그래프로 관리될 때, 정보가 길을 잃을 위험은 원천 배제됩니다.
뛰어난 단일 모델 하나만 쓰면 안 되는 이유
사람들은 저에게 끊임없이 묻습니다. "GPT-5가 나오면 훨씬 나아질 텐데, 기다리면 되지 않나요?" 그럴 수도 있습니다. 하지만 더 좋은 모델이 나온다고 해서 아키텍처의 결함이 마법처럼 치유되지는 않습니다. 브레이크가 고장 난 스포츠카는 출력이 높아질수록 더 위험할 뿐입니다.
단 하나의 모델이 모든 것을 처리하도록 방치하는 대신, 저희는 멀티 에이전트 시스템(Multi-Agent System)을 가동합니다. 감독 에이전트가 사용자의 의도를 분석해 전문 에이전트들에게 분배합니다. 계획 에이전트가 업무를 구조화합니다. 검색 에이전트가 올바른 데이터베이스를 쿼리합니다. 도구 에이전트가 API 호출을 실행합니다. 컴플라이언스 에이전트가 최종 결과물을 안전 지침과 기업 비즈니스 규칙에 비추어 정밀 검사합니다.
이러한 체계적 분업을 통해 저희는 단일 모델 방식이 상용 환경에서 기록하던 약 72% 수준의 신뢰도를 약 88%까지 끌어올렸습니다. 더 중요한 점은 완벽한 감사 추적성(Audit Trail)이 확보된다는 사실입니다. 규제 당국이나 고객이 "AI가 왜 그렇게 답했는가?"라고 추궁할 때, 저희는 어떤 에이전트가 어떤 데이터를 근거로 해당 판단을 내렸는지 명백하게 입증할 수 있습니다. 단일 모델에 프롬프트 하나 걸어둔 구조에서는 꿈도 꿀 수 없는 일입니다.
다층 검증 체계와 정형 신뢰도 모델을 포함한 본 아키텍처의 상세한 기술적 내역은 저희의 연구 논문을 참고하시기 바랍니다.
트랜잭션을 수호하는 샌드위치 구조
반품 처리처럼 실제 비즈니스 작업을 수행하는 능력의 부재, 즉 실행 격차를 극복하기 위해 저희는 샌드위치 아키텍처(Sandwich Architecture)를 적용합니다. 엄격한 엔지니어링 패턴치고는 다소 친근한 이름이라는 점은 인정합니다.
최상단 계층은 AI입니다. 사용자의 요구를 파악해 정형화된 파라미터를 추출합니다. "12345번 주문 반품 처리, 사유: 사이즈 불일치." 중간 계층은 순수 결정론적 코드입니다. 실제 데이터베이스를 상대로 이 파라미터들을 엄격히 검증합니다. 주문 번호가 실재하는가? 반품 가능 기한 내인가? 고객 계정이 활성 상태인가? 최하단 계층은 사후 검증입니다. 고객에게 완료 메시지를 띄우기 전에 별도 시스템이 액션이 정상 완결되었음을 물리적으로 최종 확인합니다.
언어 모델은 데이터베이스와 직접 통신하지 않습니다. 트랜잭션을 독단적으로 실행하지도 않습니다. 모델은 사람의 의도를 정형 데이터로 번역해 줄 뿐이며, LLM이 세상에 등장하기 수십 년 전부터 트랜잭션 무결성을 보장해 온 시스템에 작업을 위임합니다. 모델은 자신이 잘하는 언어적 역할에 충실하고, 데이터베이스는 그 자체가 본래 잘하는 데이터 일관성 유지에 집중합니다. 아무도 자신의 분수를 넘어서지 않습니다.
화염병 사건은 필터링이 아닌 설계의 실패다
저는 Rufus의 안전성 참사로 다시 돌아가고자 합니다. 이 사건이야말로 업계가 AI 리스크를 얼마나 안이하게 다루고 있는지 여실히 드러내기 때문입니다.
사고가 터진 직후 업계의 논의는 더 강력한 콘텐츠 필터링, 키워드 차단 강화, 공격적인 안전성 미세 조정에만 쏠렸습니다. 하지만 이 모든 대책은 모델이 이미 유해한 결과물을 생성한 뒤에 수습하려는 뒷북치기식 반응적 조치에 불과합니다.
저희의 설계 사상은 다릅니다. 저희는 쿼리 유입 단계에서 의미론적 의도 인식(Semantic Intent Recognition) 메커니즘을 작동시킵니다. 검색 계층이 웹으로 쿼리를 전송하기도 전에 보안 전담 에이전트가 질의의 의미론적 의도를 심층 평가합니다. 질의의 의도가 무기 제조, 자해, 불법 행위 등 금지된 영역에 해당하면 콘텐츠를 조회하는 단계 자체를 사전에 원천 차단합니다.
이러한 선제적 차단이 결정적인 이유는 Rufus 사건이 해커의 정교한 탈옥 기법으로 발생한 것이 아니기 때문입니다. 고객은 지극히 일상적인 제품 탐색 질문을 던졌을 뿐입니다. 외부 웹을 성실히 크롤링하던 검색 엔진이 우연히 위험한 배합법이 담긴 웹문서를 긁어왔고, 가져온 문서를 충실히 요약하던 모델이 그 내용을 고객의 화면에 띄웠을 뿐입니다. 모든 부품은 원래 기획된 로직대로 성실하게 작동했습니다. 결국 시스템의 설계 자체가 총체적 실패의 원인이었던 것입니다.
안전은 개발 막바지에 덧씌우는 얇은 필터가 아닙니다. 기초 설계 단계부터 시스템의 근간에 새겨 넣어야 하는 불가역적 제약 조건입니다. AI가 위험한 콘텐츠를 끌어올 수 있는 구조로 방치되어 있다면, 언젠가는 반드시 위험한 콘텐츠를 고객에게 건네게 됩니다.
불편한 손익 계산서
Amazon CEO는 Rufus를 통해 100억 달러의 추가 매출을 창출할 것이라 호언장담했습니다. 하지만 그 천문학적인 숫자는 제가 전환 신뢰도(Conversion Confidence)라 부르는 지표, 즉 고객이 AI의 조언을 신뢰하여 '구매하기' 버튼을 누를 확률에 완전히 종속되어 있습니다. 한 번의 거짓말, 한 번의 반품 처리 오류, 방언을 이해하지 못해 멍때리는 반응이 누적될 때마다 그 전환 신뢰도는 회복 불가능할 정도로 깎여 나갑니다.
단순 래퍼 방식이 초기 도입 비용 측면에서 훨씬 저렴하다는 점은 인정합니다. LLM 래퍼는 몇 주면 뚝딱 만들어 배포할 수 있습니다. 반면 저희가 제시하는 아키텍처는 수개월의 공수가 소요됩니다. 1단계는 사내 데이터를 정제하고 상품과 정책의 확실한 기준점을 세우는 데이터 감사입니다. 2단계는 멀티 에이전트 인프라와 지식 그래프 구축입니다. 3단계는 현장 고객센터의 실제 피드백을 통해 에이전트의 판단력을 끊임없이 고도화하는 피드백 플라이휠입니다.
하지만 현실의 손익 계산서는 명확합니다. 대형 유통업체에게 'AI가 고객에게 사제 무기 제조법을 가르쳤다'는 치명적인 뉴스 헤드라인 하나가 초래하는 유무형의 브랜드 피해는, 제대로 된 엔지니어링 시스템을 구축하는 전체 예산을 가볍게 상회합니다. 이미 AI 상담원을 불신하고 있는 45%의 스마트한 소비자들은 응답 속도가 몇백 밀리초 빨라졌다고 해서 돌아오지 않습니다. 오직 정확하게 작동하는 시스템만이 그들의 신뢰를 되찾아올 수 있습니다.
래퍼의 시대는 끝났다
저는 지난 2년 동안 수많은 기업들이 똑같은 참사를 조급하게 되풀이하는 광경을 지켜보았습니다. 화려한 데모에 현혹되어 기술적 유창함에 눈이 멀고, 서둘러 래퍼를 씌워 출시한 뒤, 이듬해 내내 그 모델이 저지른 사고를 수습하고 사과하느라 천문학적인 비용을 낭비합니다. 기반 모델이 GPT-4이든, Gemini이든, Claude이든, 앞으로 등장할 그 어떤 최신 모델이든 간에, 모델 자체는 결코 기업의 궁극적 차별점이 될 수 없습니다. 오직 그 모델을 감싸고 제어하는 아키텍처만이 결정적 차이를 만들어냅니다.
언어 모델은 강력한 증기 기관과 같습니다. 산업 지형을 송두리째 바꿀 수 있을 만큼 엄청난 에너지를 품고 있습니다. 하지만 피스톤, 밸브, 압력 조절기가 갖춰지지 않은 증기 기관은 그저 시한폭탄 같은 위험물에 불과합니다. 그 막대한 에너지를 올바른 궤도로 유도하고 통제하는 정밀 엔지니어링——검증 계층, 지식 그래프, 에이전트 오케스트레이션, 트랜잭션 무결성——이야말로 단순한 장난감 데모와 진정한 엔터프라이즈 제품을 가르는 유일한 기준입니다.
이 진리를 꿰뚫어 본 기업만이 실질적인 시장 가치를 독점하게 될 것입니다. 얄팍한 프롬프트로 모델을 포장한 채 요행만을 바라는 기업들은 앞으로도 신문 1면의 사건 사고란을 장식하게 될 것입니다. 저는 제가 이 거대한 분기점의 어느 쪽에 서서 시스템을 구축하고 있는지 매우 확신하고 있습니다.
