AI 대화에서 빠진 조각
모두가 AI 에이전트에 대해 이야기합니다. 기술 피드를 훑어보면 대규모 언어 모델(LLM)이 단 한 번의 놀라운 대화로 항공권을 예약하거나, 코드를 작성하거나, 고객 지원 티켓에 답변하는 수십 개의 데모를 볼 수 있습니다. 그 밑바탕에 깔린 메시지는 명확해 보입니다. 사용자를 LLM에 연결하기만 하면 마법이 일어난다는 것입니다.
그 환상은 5분짜리 데모에서는 아주 잘 작동합니다. 하지만 실제 사용자, 실제 데이터, 그리고 실제 돈이 개입되는 순간 무너집니다. 프로덕션 환경에서 관계는 결코 '사용자 ↔ LLM'에 그치지 않습니다. 그것은 '사용자 ↔ LLM을 포함하는 복잡한 시스템'입니다. 아무도 이야기하지 않는 그 시스템의 핵심 요소는 바로 하네스(harness)입니다. 모델 주변의 모든 것을 선택하고, 라우팅하고, 보호하며, 오케스트레이션하는 뼈대 말입니다. 하네스가 없다면 여러분은 제품을 가진 것이 아니라 프로토타입을 가진 것에 불과합니다.
단순한 루프가 깨지는 이유
데모는 통제된 환경입니다. 쿼리는 짧고, 컨텍스트는 제한적이며, 리스크는 낮습니다. 개발자가 단 한 번의 API 호출을 하고 유려한 응답을 받으면 청중은 박수를 보냅니다. 하지만 프로덕션은 혼란스럽습니다. 사용자는 모호한 후속 질문을 던집니다. 서드파티 API는 타임아웃이 발생합니다. 어제까지 완벽한 JSON을 생성하던 모델이 갑자기 마크다운을 뱉어내기도 합니다. 컨텍스트 윈도우는 가득 차고, 최악의 순간에 속도 제한(rate limit)이 걸립니다.
가공되지 않은 프롬프트-응답 루프는 이 모든 문제에 대한 답을 가지고 있지 않습니다. 어떤 모델 변체가 특정 작업을 처리해야 하는지 알지 못합니다. 3단계 전의 대화 내용을 기억하지 못합니다. 실패한 호출을 재시도하거나, 비용이 급증할 때 요청을 조절하거나, 데이터베이스에 저장되기 전에 출력을 정제할 수도 없습니다. 이것들은 예외적인 상황(edge cases)이 아닙니다. 실제 소프트웨어의 결정적인 특징들입니다. 이를 처리하는 것이 바로 하네스의 역할입니다.
하네스가 실제로 하는 일
하네스를 언어 모델을 영리한 텍스트 생성기에서 신뢰할 수 있는 서비스 구성 요소로 탈바꿈시키는 엔지니어링 레이어라고 생각하십시오. 하네스의 책임은 구체적이고 화려하지 않으며, 바로 그 점 때문에 간과되곤 합니다.
당면한 작업에 적합한 모델 선택. 모든 상호작용에 가장 강력한 파운데이션 모델이 필요한 것은 아닙니다. 어떤 작업은 순수한 추론 능력을 요구하지만, 어떤 작업은 단순히 속도와 저렴한 비용이 필요합니다. 잘 구축된 하네스는 요청을 지능적으로 라우팅합니다. 예를 들어, 고객 지원 에이전트는 들어오는 메시지의 의도(환불 요청인지 배송 문의인지)를 분류하기 위해 빠르고 저렴한 모델을 사용할 수 있습니다. 만약 의도가 복잡한 정책 분쟁을 나타낸다면, 하네스는 해당 작업을 더 무거운 추론 모델로 에스컬레이션합니다. 사용자가 단순히 배송 추적 링크를 원하는 것이라면, 경량 모델이 즉시 답변하여 비용 소모율(burn rate)을 합리적으로 유지합니다.
데이터 흐름 관리. 실제 애플리케이션은 진공 상태에서 작동하지 않습니다. AI 에이전트는 종종 벡터 스토어에서 문서를 가져오고, CRM을 조회하고, 최근 사용자 활동을 읽은 다음, 이 모든 것을 일관된 응답으로 합성해야 합니다. 하네스는 이러한 데이터 수집(ingestion)을 관리합니다. 적절한 컨텍스트 청크를 가져오고, 관련성을 잃지 않으면서 토큰 제한 내에 들어오는지 확인하며, 모델이 이해할 수 있도록 구조화한 뒤, 결과물을 체인의 다음 시스템으로 전달합니다. 이러한 오케스트레이션이 없다면 모델은 컨텍스트가 부족해 굶주리거나 노이즈에 파묻히게 됩니다.
오류 관리. LLM은 전통적인 서비스와는 다른 방식으로 실패합니다. 구조화된 출력을 환각(hallucinate)하거나, 빈 응답을 반환하거나, 기반 모델 버전이 약간만 바뀌어도 포맷팅 지침을 어기기도 합니다. 하네스는 이러한 실패를 놀라운 일이 아닌 예상된 동작으로 취급합니다. 스키마를 검증하고, 잘못된 응답을 잡아내며, 지수 백오프(exponential backoff)를 적용한 재시도 로직을 실행하고, 기본 엔드포인트에 문제가 생기면 보조 제공자나 캐시된 결과로 전환합니다. 모든 방법이 실패하면, 유료 고객에게 아무 의미 없는 내용을 조용히 제공하는 대신 인간 운영자에게 에스컬레이션합니다.
시스템 신뢰성 확보. 프로덕션 환경은 동시 접속 사용자, 비용 상한선, 예측 불가능한 지연 시간을 의미합니다. 하네스는 속도 제한을 강제하고, 커넥션 풀링을 관리하며, 서킷 브레이커(circuit breaker)를 구현하여 하나의 느린 모델 제공자가 전체 애플리케이션을 멈추게 하지 않도록 합니다. 또한 모든 상호작용을 로그로 남겨 특정 세션이 왜 어긋났는지 추적할 수 있게 하며, 프롬프트 버전을 관리하여 배포 시 감사 추적(audit trail) 없이 에이전트의 성격이 실수로 바뀌는 일을 방지합니다.
동일한 모델, 완전히 다른 결과
이것은 많은 제품 팀을 혼란스럽게 만드는 현상을 설명합니다. 두 회사가 완전히 동일한 파운데이션 모델—동일한 가중치, 동일한 컨텍스트 윈도우, 동일한 학습 데이터 컷오프—로 시작하더라도, 전혀 다른 경험을 제공할 수 있습니다. 한 쪽은 불안정하고 느리며 이상하게도 잘 잊어버리는 느낌을 줍니다. 다른 한 쪽은 빠릿빠릿하고 일관되며 신뢰할 수 있는 느낌을 줍니다.
차이는 결코 모델 자체에 있지 않습니다. 모델을 감싸고 있는 시스템에 있습니다. 한 팀은 모델을 제품 전체로 취급했습니다. 다른 팀은 모델을 규율 있는 아키텍처 내부의 하나의 구성 요소로 취급했습니다. 그 규율이 살아 숨 쉬는 곳이 바로 하네스(harness)입니다.
프롬프트에서 아키텍처로의 전환
초기 AI 개발은 프롬프트 엔지니어링을 전면에 내세웠습니다. 문구를 다듬고, 예시를 추가하고, 역할극 지침을 계층화하는 것만으로도 출력 품질을 극적으로 개선할 수 있었습니다. 그 기술은 여전히 중요하지만, 경쟁 우위(moat)로서의 가치는 한계 효용 체감의 단계에 접어들었습니다. 재시도 정책(retry policy)이 없거나, 개인적인 컨텍스트가 공개 응답으로 유출되는 엉망인 데이터 파이프라인 문제를 프롬프트만으로는 해결할 수 없습니다.
지금 일어나고 있는 진정한 변화는 소프트웨어 아키텍처로의 이동입니다. 엔지니어들은 상태 머신(state machines)을 설계하고, 모델 계층과 애플리케이션 로직 사이의 엄격한 인터페이스를 정의하며, 비결정성(non-determinism)을 일급 엔지니어링 과제로 다루고 있습니다. 그들은 분산 시스템에 관한 질문을 던집니다. 다회차 대화(multi-turn conversation)에서 상태는 어떻게 유지되는가? 다운스트림 도구를 사용할 수 없게 되면 어떻게 되는가? 핵심 구성 요소가 확률적인 시스템을 어떻게 테스트할 것인가? 이러한 질문들이 장난감과 도구를 구분 짓습니다.
프로덕션 구축: 관측 가능성과 제어
제품을 제대로 출시하고 싶다면, 하네스는 무엇보다 두 가지 특성, 즉 관측 가능성(observability)과 오케스트레이션(orchestration)을 요구합니다.
관측 가능성이란 모델이 무엇을 받았는지, 무엇을 반환했는지, 각 단계에 시간이 얼마나 걸렸는지를 볼 수 있음을 의미합니다. 이는 에이전트의 의사결정 루프를 14번의 도구 호출에 걸쳐 추적하고, 루프에 빠지거나 임무에서 벗어나기 시작한 정확한 지점을 찾아낼 수 있음을 의미합니다. 이러한 가시성이 없다면 AI 시스템을 디버깅하는 것은 어둠 속에서 자동차 엔진을 수리하는 것과 같습니다.
오케스트레이션이란 비즈니스 로직이 모델 상호작용 계층과 분리되어 있음을 의미합니다. 이는 코드를 버전 관리하듯 프롬프트를 버전 관리하여, 새로운 배포가 동작을 조용히 변경하지 않도록 함을 의미합니다. 또한, API를 요청 중간에 중단하거나, 잘못된 형식의 도구 결과를 입력하거나, 컨텍스트 윈도우 오버플로를 시뮬레이션하는 등 실패 모드를 의도적으로 테스트하여 하네스가 시스템을 안정적으로 유지하는지 확인하는 것을 의미합니다. 프레임워크는 생겼다 사라지기를 반복하며, 기성 오케스트레이션 라이브러리를 채택하든 직접 구축하든, 브랜드 이름보다는 규율이 더 중요합니다.
핵심 요점
파운데이션 모델은 계속 발전할 것입니다. 더 빨라지고, 더 저렴해지며, 더 유능해질 것입니다. 하지만 더 강력한 엔진이 고장 난 섀시를 고쳐주지는 않습니다. 향후 몇 년간 승리할 팀은 가장 화려한 모델 접근 권한을 가진 팀이 아닙니다. 신뢰할 수 있고, 관측 가능하며, 잘 오케스트레이션된 하네스를 구축한 팀이 승리할 것입니다. 그들은 애플리케이션을 다시 작성하지 않고도 모델을 교체할 수 있을 것입니다. 하네스가 모든 토큰을 관리하기 때문에 비용을 제어할 수 있을 것입니다. 시스템이 우아하게 실패(fail gracefully)하기 때문에 밤에 잠을 편히 잘 수 있을 것입니다.
모델 그 자체에만 집착하는 것을 멈추십시오. 모델을 실행하는 시스템에 집착하기 시작하십시오. 미래는 똑똑한 모델 주변에 더 똑똑한 시스템을 구축하는 엔지니어들의 것입니다.
이 기사는 Abdulaziz Zos가 "Beyond The Model"에서 논의한 아이디어를 바탕으로 작성되었습니다.
AI 엔지니어링 및 시스템 설계에 관한 더 많은 논의는 GyaanSetu learning community에서 확인하세요.