신경-기호적 필연: 확률적 시대에 결정론적 에이전트를 설계하기

경영진 요약

인공지능 지형은 중요한 분기점에 서 있으며, 역량과 신뢰성에 대한 근본적 오해로 양분되어 있다. 한쪽에는 "챗봇"이 있다— 인간의 대화를 놀라울 정도로 유창하게 모방할 수 있는 언어 합성의 확률적 엔진. 다른 한쪽에는 "에이전트"가 있다—비즈니스 로직의 결정론적 실행자로, API 통합, 금융 거래, 상태 유지 워크플로를 통해 물리적·디지털 세계를 조작하는 임무를 맡는다. 업계의 지배적 추세는 이 두 개의 뚜렷한 개체를 혼동하는 것이었으며, 대규모 언어 모델(LLM)을 얇은 오케스트레이션 레이어로 감싸 자율적 범용 추론기로서 수행할 것을 기대했다. 이 접근법은 흔히 "프롬프트 체이닝" 또는 "LLM 래퍼" 모델로 불리며, 엔터프라이즈 배포에서 신뢰성 위기를 촉발했다. Veriprajna는 이 아키텍처적 취약성에 대한 해독제로 자리매김한다. 엄격한

업계 벤치마크 분석—특히 TravelPlanner 평가에서 GPT-4의 치명적인 0.6% 성공률—과 Global Distribution Systems(GDS) 같은 복잡한 레거시 시스템과의 심층 연계를 통해, 우리는 엔터프라이즈 AI를 위한 새로운 방법론을 정립했다: 신경-기호 오케스트레이션 . 이 백서는 신뢰할 수 있는 에이전트형 AI의 길이 더 큰 모델이나 더 긴 컨텍스트 윈도우에 있지 않고, 인지적 _추론_과 제어 흐름 의 분리에 있다고 주장한다. LangGraph 같은 프레임워크를 사용해 확률적 LLM을 엄격하고 하드코딩된 그래프에 내장함으로써, 조직은 양쪽의 장점을 달성할 수 있다: 데이터 추출을 위한 생성형 AI의 유연성과 프로세스 실행을 위한 유한 상태 기계(FSM)의 철저한 신뢰성. 1. 래퍼 망상: "에이전트형" 과대광고 사이클 해체

트랜스포머 아키텍처가 주도한 생성형 AI의 급속한 부상은

이전에는 전문 연구소만의 영역이었던 자연어 이해(NLU) 역량에 대한 접근을 민주화했다. 그러나 이 민주화는 이러한 모델의 자율성에 대한 조기 과신을 낳았다. 업계는 "에이전트" 프레임워크—AutoGPT, BabyAGI, ReAct(추론 + 행동)의 순진한 구현—의 폭발을 목격했으며, 이들은 매력적이지만 결함 있는 전제 위에서 작동했다: 고수준 목표와 도구 세트가 주어지면 LLM이 어떤 목적이든 달성하기 위한 최적 행동 순서를 자율적으로 추론할 수 있다는 것. 1.1 실패의 의미론 핵심 문제는 "그럴듯함"과 "정확성" 사이의 의미론적 격차에 있다. LLM은

통계적 가능성에 기반해 시퀀스의 다음 토큰을 예측하도록 설계된

확률적 엔진이다. 창작 글쓰기나 대화형 작업에서는 이 확률적 특성이 장점이 되어 창의성과 뉘앙스를 허용한다. 공급망 물류, ¹ 재무 감사, 여행 예약 같은 엔터프라이즈 워크플로에서는 이 특성이 치명적 버그가 된다. LLM이 "환각"할 때, 본질적으로 통계적으로 그럴듯하지만 사실과 다른 예측을 하는 것이다. 채팅 인터페이스에서는 불편함에 그치지만, API 트랜잭션 체인에서는 시스템 장애다. Veriprajna는 이 현상을 "래퍼 망상" 으로 정의한다: 확률적 모델이 프롬프트 엔지니어링만으로 결정론적 행동으로 강제될 수 있다는 믿음. 우리 ²

연구에 따르면 작업 복잡도가 선형적으로 증가할 때, 순수 LLM 아키텍처에서 실패 확률은 기하급수적으로 증가한다. 이는 단순히 "더 나은 프롬프팅"의 문제가 아니다; 모델 아키텍처(무상태, 어텐션 기반)와 작업 요구사항(상태 유지, 로직 기반) 사이의 근본적 불일치다. 1.2 순차 체이닝의 확률적 함정 에이전트 구축의 지배적 방법론—순차 도구 체이닝—은 LLM이 ³

중앙 오케스트레이터 역할을 하도록 의존한다. 이 모델에서 LLM은 도구 A의 출력을 받고,

다음에 호출할 도구(도구 B)를 결정하고, 도구 B용 입력을 포맷한 뒤, 작업이 완료될 때까지 이 과정을 반복한다. 이것이 "확률의 사슬"을 만든다. LLM이 복잡한 추론 작업에서 90% 정확하게 행동한다고 가정하면(관대한 추정), 다단계 워크플로의 수학적 신뢰성은

급격히 저하된다. ●​ 1단계: 90% 성공 확률

●​ 5단계: $0.90^5 \approx 59%$ 성공 확률

●​ 10단계: $0.90^{10} \approx 34%$ 성공 확률

검색, 필터링, PNR 생성, 승객 정보 입력,

결제, 발권을 포함하는 항공 예약 워크플로에서 단계 수는 흔히 열 번 이상의 작업을 넘는다. 34% 성공률은 엔터프라이즈 소프트웨어에 허용 불가능하지만, 이것이 많은 순수 LLM 에이전트의 이론적 상한이다. 실제 벤치마크는 더욱 암울한 그림을 그리며, 복잡한 계획 작업에서 ⁴ 종종 1% 미만의 성공률을 보여준다. 업계에는 통제된 ⁵

데모 환경에서는 훌륭하게 작동하지만 실제 데이터의 분산 아래 무너지는 "개념 증명" 에이전트가 널렸다. 이러한 실패는 거의 공개되지 않아 AI 역량에 대한 대중 인식에 "생존자 편향"을 만든다. 우리는 무한 루프에 갇히는 에이전트, 자신 있게 잘못된 날짜를 예약하는 에이전트, 발생하지 않은 거래가 성공했다고 환각하는 에이전트를 본다. 발생하지 않은 거래가 성공했다고 환각하는 에이전트. ²

1.3 Veriprajna의 입장: 로직은 언어 작업이 아니다

Veriprajna는 제어 흐름은 언어 작업이 아니다 고 주장한다. 엄격한 비즈니스 프로세스에서 다음에 무엇을 할지 결정하는 것은 토큰 예측의 문제가 아니라 조건부 로직의 문제여야 한다. 조건부 로직의 문제여야 한다. "결제 요청" 결정은 "항공편이 선택됨"일 때만 발생해야 한다 AND "가격이 확인됨." 이것은 불리언 조건이지 확률적 제안이 아니다. By 이 로직을 LLM에 위임하면, 개발자는 애플리케이션 상태 기계의 제어를 블랙박스에 넘기는 것이다. ⁴

우리 철학은 "지능"을 오케스트레이션 레이어에서 리프 노드로 이동시킨다. The LLM은 작업자 —데이터 추출, 텍스트 요약, JSON 포맷—여야 하고, 관리자(오케스트레이션 로직)는 하드코딩된 소프트웨어여야 한다. 이 구분이 신경-기호 접근법의 토대이며, 에이전트형 시스템에서 99.9% 신뢰성에 이르는 유일한 길이다. 에이전트형 시스템. ⁸

2. 실증적 현실: TravelPlanner 벤치마크 분석

이론적 비판을 넘어서려면 실증 데이터를 검토해야 한다. 여행 도메인은 에이전트형 역량을 시험하기에 완벽한 도가니 역할을 한다. 다음에 위치하기 때문이다: "지저분한" 인간 제약(선호, 날짜, 예산)과 "엄격한" 시스템 제약(API 스키마, 항공편 가용성, 연결 로직).

2.1 TravelPlanner 벤치마크 결과

다일정 여행 계획에서 대규모 언어 모델을 시험하기 위해 설계된 엄격한 평가 프레임워크인 TravelPlanner 벤치마크는 순수 LLM 오케스트레이션에 대한 가장 결정적인 반증을 제공한다. 이 벤치마크는 에이전트가 미국 내에서 여행을 계획하도록 요구하며, 교통, 숙박, 식사, 예산에 관한 제약을 준수해야 한다. 지표 ¹⁰

GPT-4 (순수 LLM)	신경-기호 에이전트	(코드 기반) 전체 성공률
0.6%	97.0%	하드 제약 통과
률 ~4.4%	~99.0%	전달률
~93%	100%	자료 종합.

**0.6%**와 97% 사이의 극명한 격차는 과장할 수 없다. 이것은 ⁵

난수 생성기와 작동하는 소프트웨어 제품 사이의 차이를 나타낸다. 2.2 실패의 부검

세계에서 가장 진보된 모델이 왜 99.4%의 시간 동안 실패하는가? 실패는

언어적이지 않다; GPT-4는 요청을 완벽히 이해한다. 실패는 인지적 지구력과 상태 유지 에 있다. 2.2.1 컨텍스트 드리프트 현상

에이전트가 계획 과정을 반복할 때—항공편 검색, 호텔, 그다음

레스토랑—컨텍스트 윈도우는 중간 데이터로 채워진다. 이 토큰 축적은 모델의 어텐션 메커니즘을 희석시킨다. 모델은 3단계에서 예산 내 호텔을 성공적으로 찾을 수 있지만, 10단계에서 레스토랑을 선택할 때는 4단계에서 계산된 남은 예산을 효과적으로 "잊어버린다". 이것이 컨텍스트 드리프트 로 알려져 있다. "Softmax" 어텐션 점수가 너무 많은 무관한 토큰에 너무 얇게 퍼져, 모델이 세션 시작 시 설정된 하드 제약을 추적하지 못하게 한다. 2.2.2 환각 캐스케이드 ²

도구 체인 아키텍처에서 한 단계의 출력이 다음 단계의 입력이 된다. 에이전트가

2단계에서 미묘한 오류를 내는 경우—예를 들어 도착 시간을 오전 2:00이 아닌 오후 2:00으로 잘못 읽는— 그 오류는 하류로 전파된다. 환각된 시간에 기반해 잘못된 날짜에 호텔 체크인을 예약할 수 있다. GDS API는 에이전트의 _의도_를 알지 못하고, _입력_만 알기 때문에 요청을 처리한다. 에이전트는 성공적인 API 응답을 보고 자신의 오류를 강화한다. 이 환각 캐스케이드는 "성공적인" 실행 추적을 만들지만 재앙적인 실제 결과를 낳는다. 2.2.3 "추론-행동 불일치" 벤치마크는 빈번한 "추론-행동 불일치"를 드러낸다. 모델의 내부 ²

독백(사고의 사슬)이 제약을 올바르게 식별하지만, 후속 도구 호출이

이를 위반한다. 모델은 "생각"할 수 있다: $500 이하 항공편을 찾아야 한다, 그러나 검색 결과 컨텍스트에서 더 두드러지게 나타난 항공편 때문에 $600 항공편에 대한 도구 호출을 생성한다. 이 단절은 텍스트 생성을 로직 실행의 대리로 사용하는 것의 취약성을 강조한다. 2.3 신경-기호적 수정 97% 성공을 달성한 시스템은 "더 나은" LLM을 사용하지 않았다. 신경-기호 아키텍처를 사용했다. LLM을 사용해 사용자 요청을 구조화된 쿼리로 파싱한 뒤, ¹³

그 쿼리를 솔버(결정론적 알고리즘)에 넘겨 검색과

최적화를 실행했다. LLM은 "계획자"가 아닌 "번역기"로 취급되었다. 이 아키텍처 전환은 솔버가 상태(예산, 날짜)를 토큰이 아닌 변수로 유지하기 때문에 컨텍스트 드리프트를 제거한다. 3. 복잡성의 도가니: Global Distribution Systems (GDS) Veriprajna가 하드코딩된 그래프를 옹호하는 이유를 이해하려면 엔터프라이즈 API의 적대적 환경을 이해해야 한다. 항공 예약은 단순한 REST GET 요청이 아니다; Sabre, Amadeus, Travelport 같은 Global Distribution Systems(GDS)와의 ¹⁰

복잡한 상호작용이다. 메인프레임 시대에 설계된 이 시스템들은 모호함을 용납하지 않는다.

3.1 GDS 상태 기계: 엄격함의 유산 항공 예약 트랜잭션은 유한 상태 기계(FSM) 이다. 재정렬하거나 건너뛸 수 없는 정확한 작업 순서가 필요하다. 1.​ 세션 초기화(인증): ​

프로세스는 GDS에 대해 인증하여 세션 토큰을 얻는 것으로 시작한다. 이

토큰은 "Workbench" 또는 "State"를 나타낸다. 이후 모든 헤더에 명시적으로 전달되어야 한다. LLM이 이 토큰 포함을 "잊거나" 새 토큰을 환각하면,

전체 트랜잭션 컨텍스트가 손실된다. 2.​ 항공 쇼핑(검색 및 오퍼 관리): ​ Air_Sell 또는 FlightOffersSearch 명령은 "Offers" 목록을 반환한다. 중요하게도, Offer는 일시적 객체이다. 가격과 가용성은 동적이다. GDS는 복잡한, Fare Basis Codes, 수하물 허용¹⁵

모델, Segment References를 포함한 중첩 JSON 또는 XML 구조를 반환한다. 일시적 객체이다. 가격과 가용성은 동적이다. GDS는 복잡한, Fare Basis Codes, 수하물 허용 ○​ 실패 모드: LLM은 이러한 대용량 페이로드(종종 50kb+)를

잘라내지 않고 처리하는 데 어려움을 겪는다. 사용자에게 옵션을 요약할 때, 종종 다음 단계에 필요한 중요한 offerId 또는 segmentReference를 제거하여 선택을 실행 불가능하게 만든다. 3.​ "Price" 트랜잭션: ​ ¹⁷

예약 전에 "Price" 또는 "Confirm" 엔드포인트를 호출해야 한다. 이것이 재고를 잠근다. 여기서 입력은 Search 출력과 비트 단위로 일치해야 한다. ○​ 실패 모드: LLM은 "손실 압축기"로 작동한다. Search

출력에서 Price 입력으로 데이터를 전달할 때, 종종 데이터를 "자동 수정"하거나 "정규화"하여 (예: 날짜 형식 변경 또는 운임 코드의 인지된 오타 수정) API가 요구하는 암호학적 무결성을 깨뜨린다. 4.​ PNR 생성(Passenger Name Record): ​ ¹⁹

PNR 생성은 다단계 하위 루틴이다. 다음을 추가해야 한다: ○​ 여정 세그먼트.

○​ 이름 요소(엄격한 형식: LAST/FIRST MR).

○​ 연락처 요소(AP - Address Phone).

○​ 발권 기한(TKTL).

○​ "Received From" 요소(RF).

○​ 커밋 트랜잭션(ET).

○​ 실패 모드: 순서가 중요하다. "Received From"(RF) 필드를 추가하기 전에

커밋(ET)할 수 없다. 훈련 데이터에서 학습한 것 외에 고유한 시간적

순서 개념이 없는 LLM은 모든 필수 필드가 채워지기 전에 예약을 "저장"하려 자주 시도하여 ERR 1209 - SEQUENCE ERROR 같은 난해한 오류 코드를 발생시킨다. 3.2 난해한 피드백 루프 ¹⁵

GDS가 오류를 반환할 때, 설명적이지 않은 경우가 많다. UC(Unable to Confirm) 또는

NO RECAP 같은 오류는 LLM에게 문제를 해결하는 의미론적 단서를 주지 않는다. ●​ LLM 응답: 도움이 되도록 훈련된 모델은 종종 오류를 "글리치"로 해석하고

정확히 동일한 요청을 단순히 재시도한다. ●​ 무한 루프: 이것은 "죽음의 루프"로 이어지며, 에이전트가 토큰과

API 속도 제한을 소진하며 이해할 수 없는 벽에 반복적으로 부딪힌다. ●​ Veriprajna 솔루션: 그래프의 하드코딩된 ErrorHandler 노드가 특정 오류 ⁶

코드(예: UC)를 특정 복구 전략(예: "재쇼핑 워크플로 트리거")에 매핑한다. 복구 중 LLM은 완전히 우회되어 루프를 방지한다. 4. 신경-기호 르네상스: 이론적 프레임워크 ²²

이러한 실패에 대한 해결책은 "더 많은 AI"가 아니라 "더 나은 컴퓨터 과학"이다. Veriprajna는

연결주의(신경망)와 상징주의(로직/규칙)라는 AI의 두 위대한 전통을 융합하는 패러다임인 신경-기호 아키텍처를 옹호한다. 4.1 양쪽의 장점

●​ 신경망("시스템 1" 뇌): 패턴 인식, 퍼지

매칭, 자연어 이해에 탁월하다. "너무 이르지 않은 항공편을 원한다"고 말할 때 사용자가 의미하는 바를 이해하는 지각 에 빛난다. ●​ 상징 AI("시스템 2" 뇌): 규칙 실행, 로직, 산술, 일관성에 탁월하다. A > B이면 C 를 보장하는 추론 에 빛난다.

Veriprajna 아키텍처에서 우리는 이러한 강점에 따라 책임을 할당한다: ●​ LLM은 인터페이스 레이어 이다. 비구조화된 사용자 의도를 구조화된

데이터(JSON)로 번역한다.

●​ 그래프는 실행 레이어 이다. 구조화된 데이터를 받아 결정론적 코드로 비즈니스 로직을 실행한다.

4.2 파이프라인에서 그래프로 전통적 소프트웨어는 파이프라인(선형 실행)을 사용한다. 에이전트형 워크플로는 사이클 ⁸

(루프)이 필요하다. 에이전트는 단계를 시도하고, 실패하고, 오류를 분석하고, 재시도할 수 있어야 한다.

이 요구사항은 앞으로만 이동하는 방향 비순환 그래프(DAG)에서 순환 상태 그래프로의 전환을 필요로 한다. ●​ LangChain(기본 형태)은 LLM 체인을 위한 DAG를 대중화했다. ●​ LangGraph는 순환 그래프를 도입하여 조건부 로직에 기반해

이전 노드로 루프백할 수 있는 상태 기계 생성을 가능하게 한다.

4.3 "슈퍼바이저" 패턴 우리는 중앙의 하드코딩된 상태 기계가 ²⁴

요청의 수명 주기를 관리하는 "슈퍼바이저" 아키텍처를 구현한다. LLM은 "CEO"에서 "작업자"로 강등된다.

●​ **슈퍼바이저(그래프)**가 결정한다: "우리는 예약 상태에 있다. 다음 단계는 CollectPassengerInfo이다."

●​ **작업자(LLM)**가 실행한다: "이 이메일 텍스트에서 승객 이름을 추출하라." ●​ **슈퍼바이저(그래프)**가 검증한다: "이름이 유효한가? 예. 상태를 Payment로 전환."

코드가 LLM을 호출하고, LLM이 코드를 작성하는 것이 아닌—이 제어 역전이

견고한 에이전트형 시스템의 정의적 특성이다.

5. 결정론 설계: LangGraph 프레임워크 LangGraph는 Veriprajna 방법론의 기술적 백본 역할을 한다. LLM의 ⁷

확률적 특성에 견디는 상태 유지, 다중 액터 애플리케이션을 구축하는 데 필요한

프리미티브를 제공한다. 5.1 제어의 프리미티브 LangGraph는 세 가지 핵심 개념으로 작동한다: State, Nodes, Edges .

5.1.1 공유 상태 스키마

대화 기록(문자열 목록)에 의존하는 표준 챗봇과 달리, LangGraph는

State Schema 에 의존한다. 이것은 에이전트의 "메모리" 역할을 하는 타입이 지정된 데이터 구조(일반적으로 Pydantic 모델 또는

TypedDict)이다. 이 스키마가 "진실의 원천"이다. 전체 워크플로에 걸쳐 지속된다. LLM이 환각하더라도, 해당 필드를 업데이트하도록 특별히 승인된 노드가 없는 한 session_id를 덮어쓸 수 없다.

class FlightBookingState(TypedDict):
    # The conversational history for context
    messages: Annotated[list[AnyMessage], operator.add]

    # Structured variables extracted from the conversation
    origin: Optional[str]
    destination: Optional[str]
    travel_dates: Optional

    # The GDS Session Token (Crucial for transactional integrity)
    session_id: Optional[str]

    # The selected offer object (Raw JSON from API)
    selected_offer: Optional

    # Business logic flags
    is_price_locked: bool
    manager_approval_status: Enum("PENDING", "APPROVED", "REJECTED")

5.1.2 노드: 결정론적 작업 단위 그래프의 각 노드는 Python 함수이다. ●​ 에이전트 노드: 특정 인지 작업을 수행하기 위해 LLM을 호출한다(예: "날짜 추출"). ²⁵

5.1.2 노드: 결정론적 작업 단위

●​ 도구 노드: 외부 API를 호출한다(예: "Amadeus Search").

●​ 로직 노드: 순수 Python 코드를 실행한다(예: "날짜 형식 검증").

API 호출을 Python 코드가 실행하는 "도구 노드"로 격리함으로써(

LLM 생성 코드가 아님), "환각 주입"을 제거한다. API 호출은

State의 검증된 변수를 사용해 구성되어 페이로드가 매번 구문적으로 완벽하다. 5.1.3 조건부 엣지: 신경계 라우팅의 "지능"은 조건부 엣지 에 있다. 이것은 ²⁸

State를 검사하고 다음 노드를 결정하는 함수이다.

●​ 표준 LLM 접근법: 모델이 "검색 도구 호출"을 출력한다(확률적). ●​ LangGraph 접근법: 엣지 함수가 state.origin AND state.destination을 읽어:

return "Search_Node" else: return "Ask_User_Node"(결정론적).

이것은 에이전트가 단계를 건너뛸 수 없음 을 보장한다. State에 selected_offer 변수가 채워지기 전에 예약을 시도하는 것은 물리적으로 불가능하다.

5.2 지속성과 체크포인팅 엔터프라이즈 워크플로는 장시간 실행된다. 사용자가 예약을 시작하고, 중단되고, ²⁴

몇 시간 후 돌아올 수 있다. LangGraph의 체크포인팅 기능은 모든 노드 전환 후 상태를 데이터베이스(예:

Postgres, Redis)에 저장한다. ●​ 세션 재개: 사용자가 돌아오면 그래프는 데이터베이스에서 정확한 상태를 다시 로드한다. 정확히 어디서 멈췄는지 안다(예: "결제 대기 중"). 전체 채팅 기록을 다시 읽고 컨텍스트를 재추론할 필요가 없다; 컨텍스트는 구조화되어

저장된다. ●​ 타임 트래블 디버깅: 에이전트가 프로덕션에서 실패하면, 개발자는 실패 직전 체크포인트를 로드하고 노드 실행을 재생하여 문제를 진단할 수 있다. 이 관측 가능성은 블랙박스 LLM 체인에서는 불가능하다. ²⁷

6. Veriprajna 청사진: 견고한 항공 예약 사례 연구 이러한 원칙의 실제 적용을 보여주기 위해 Veriprajna Flight Agent Reference Architecture 를 제시한다. 이것은 이론적 모델이 아니다; Sabre/Amadeus GDS와 상호작용할 수 있는 ²⁶

프로덕션급 시스템을 위한 청사진이다.

6.1 아키텍처 개요 시스템은 계층적 상태 그래프 로 설계된다. ●​ 마스터 그래프: 고수준 라우팅(항공편 예약 vs. 취소 vs. FAQ)을 처리한다.

●​ 서브 그래프(항공 예약): 예약 프로세스의 특정 FSM을 처리한다.

6.2 상세 노드 워크스루

노드 1: "Collector"(인지 레이어)

●​ 기능: 이 노드는 LLM을 사용해 사용자의 자연어 입력을 파싱한다.

●​ 목표: State의 SearchCriteria를 채운다.

●​ 기법: 가이드 생성(예: JSON Mode 또는 Function Calling)을 사용해

LLM이 특정 스키마를 출력하도록 강제한다: {origin: str, dest: str, date: str}.

●​ 검증: Python 검증기가 공항 코드가 유효한지 확인한다(예: "LHR"는 유효,

"London"은 모호). 모호하면 그래프는 "Disambiguation" 노드로 루프백하여 사용자에게 "히스로우인가 개트윅인가?"를 명확히 요청한다. LLM은 추측할 수 없다.

노드 2: "Retriever"(도구 레이어) ●​ 기능: GDS 검색을 실행한다. ●​ 입력: State의 검증된 SearchCriteria. ⁷

●​ 동작: Amadeus.shopping.flight_offers_search.get()을 호출한다.

●​ 로직:

○​ Response == 200이면: 원시 JSON을 state.flight_cache에 저장. Summarizer로 전환.

○​ Response == Empty이면: BroadenSearch 노드로 전환(+/- 3

일 제안).

○​ Response == Error이면: GDS_ErrorHandler로 전환.

●​ 핵심 통찰: 여기서 LLM은 완전히 우회된다. API와의 상호작용은 순수 코드이다.

노드 3: "Summarizer"(인지 레이어)

●​ 기능: 원시 JSON을 사용자 친화적 메시지로 변환한다. ●​ 입력: state.flight_cache의 상위 5개 오퍼.

●​ 제약: LLM 프롬프트는 JSON에 있는 데이터만 표시 하도록 엄격히 지시된다.

혜택을 발명하거나 가격을 변경하는 것은 금지된다.

●​ 출력: "5개 항공편을 찾았습니다. 최적 옵션은 United $450..."

노드 4: "Selector"(상태 레이어) ●​ 기능: 사용자 선택을 캡처한다.

●​ 동작: 사용자가 "두 번째 것 예약"이라고 말한다. LLM이 "두 번째 것"을 flight_cache의 특정

offer_id로 해석한다.

●​ 업데이트: state.selected_offer_id = "eJzTD9..." (긴 GDS 해시).

●​ 전환: Pre_Booking_Validation으로 이동. 노드 5: "Gatekeeper"(거버넌스 레이어)

●​ 기능: 트랜잭션 전 비즈니스 규칙을 확인한다.

●​ 로직:

○​ 가격이 기업 정책 한도 내인가?

○​ 항공편이 블랙리스트 항공사인가?

●​ 조건부 엣지:

○​ 위반 시: ManagerApproval(HITL)로 라우팅.

○​ 정상 시: CreatePNR로 라우팅.

노드 6: "Transactor"(도구 레이어)

●​ 기능: PNR 생성 시퀀스를 실행한다.

●​ 시퀀스:

1.​ AddSegments(state.selected_offer_id)

2.​ AddPassenger(state.passenger_details)

3.​ PricePNR() -> 중요 확인: 반환된 가격 vs. 캐시된 가격 비교.

4.​ CommitPNR()

2. AddPassenger(state.passenger_details)

●​ 오류 처리: GDS가 "가격 변경" 경고를 반환하면(여행에서 흔함),

노드는 중단하고 PriceChangeNotification 노드로 라우팅하여 사용자에게

새 가격 확인을 요청한다. 더 높은 요금으로 자동 예약하지 않는다. 6.3 표: Veriprajna 아키텍처 vs. 표준 래퍼 기능 ¹⁵

표준 LLM 래퍼

Veriprajna	(신경-기호 그래프)	제어 흐름 확률적(LLM이
다음 단계 결정)	결정론적(그래프 엣지가 결정)	상태 지속성 암묵적(채팅 기록)
명시적(데이터베이스 기반	스키마)	GDS 상호작용 LLM이 JSON 본문 생성
(오류 취약)	코드가 JSON 본문 생성(타입 안전)	오류 복구 "죄송합니다, 실패했습니다."(포기)
"오류 8102 감지.	형식 B로 재시도." 루핑	무한 루프 위험(토큰 소모)
Max_Retries가 있는	제어된 루프 컴플라이언스	불투명한 "블랙박스" 로직 노드의
전체 감사 추적	7. 인간 요소: 거버넌스와 HITL	엔터프라이즈에서 AI의 목표는 완전한 자율성이 아니라 증강된 생산성 이다. 법적으로나 운영상 인간 판단이 필요한 순간이 있다. 순수 LLM 체인은

인간을 위해 일시 정지하고 기다리기 어렵다; LangGraph는 이를 네이티브 프리미티브로 만든다.

7.1 "인터럽트" 패턴 우리는 LangGraph의 interrupt_before 기능을 활용해 워크플로에 "에어갭"을 만든다. ●​ 시나리오: 항공편이 $2,000. 정책상 관리자 승인 필요.

●​ 메커니즘: 그래프는 Booking 노드까지 실행한다. 조건부 엣지가

price > 1000을 감지한다. 인터럽트 를 트리거한다.

●​ 상태 동결: 그래프는 실행을 일시 중단한다. State는 데이터베이스에 지속된다.

메모리가 해제된다. ●​ 오프라인 동작: 시스템이 관리자에게 링크가 포함된 이메일을 보낸다.

●​ 재개: 관리자가 "승인"을 클릭한다. API가 Graph Supervisor에 신호를 보낸다. 그래프는 State를 다시 로드하고, approval_status = APPROVED로 업데이트한 뒤

Booking 노드에서 워크플로를 재개한다.

7.2 감사 추적 및 규제 컴플라이언스

EU AI Act와 신흥 미국 규제는 고위험 AI 시스템(여행 예약 같은 금융 거래 포함)에 대한 투명성을 요구한다. ²⁹

●​ 래퍼 문제: LLM 추적은 토큰의 혼란에 불과하다. 에이전트가 왜 특정 항공편을

예약했는지 증명하기 어렵다. ●​ 그래프 솔루션: Veriprajna는 노드 실행 로그 를 제공한다.

○​ 로그 항목: [2023-10-27 14:00:01] Node:Gatekeeper | Input: Price=1200 | Rule: Policy_Limit=1000 | Output: REJECT_NEED_APPROVAL

○​ 이 로그는 감사관이 읽을 수 있다. 시스템이 거버넌스

정책을 결정론적으로 따랐음을 증명한다. 8. 경제적 논거: 효율성과 비용

신뢰성 외에도 Veriprajna 접근법에 대한 설득력 있는 경제적 논거가 있다. 순수 LLM 에이전트는 계산 비용이 높다. ³⁴

8.1 환각 루프의 비용

LLM 에이전트가 루프에 갇혀—새 매개변수를 환각하며 GDS 오류를 수정하려 할 때— 수천 개의 입출력 토큰을 생성한다. 단일 "막힌" 세션은 타임아웃 전에

API 크레딧으로 $5-$10이 들 수 있다.

하드코딩된 오류 핸들러를 사용함으로써, Veriprajna는 이러한 루프를 방지한다. 오류는 코드(비용 0)에 의해 포착되고, 분석되고, 수정된다. LLM은 절대적으로 필요할 때만 호출된다. 8.2 토큰 최적화 신경-기호 아키텍처에서는 LLM에 전체 50kb GDS 응답을 공급할 필요가 없다. "Fetcher" 노드(코드)가 JSON을 파싱하고, 관련 5개 필드를 추출한 뒤,²

"Summarizer" 노드(LLM)에만 전달한다. 이것은 컨텍스트 윈도우 사용을

90% 줄여 추론 비용과 지연 시간을 크게 낮춘다. 9. 미래 전망: 그래프의 진화 챗봇에서 그래프로의 전환은 일시적 유행이 아니다; AI 업계의 성숙이다. "에이전트형" 역량이 표준이 되면서, 차별화는 "누가 ³⁶

가장 똑똑한 모델을 갖고 있는가?"에서 "누가 가장 견고한 그래프를 갖고 있는가?"로 이동할 것이다.

Veriprajna는 표준화된 에이전트 프로토콜 의 부상을 예측한다—일반 작업을 위한 사전 구축·검증된 업계. "에이전트형" 역량이 표준이 되면서, 차별화는 "누가 서브 그래프 라이브러리(예: LangGraph.Hub.FlightBooking,

LangGraph.Hub.SalesforceUpdate). 기업은 검증된 그래프를 이어 붙여 애플리케이션을 구성하고, LLM은 자연어 인터페이스를 매끄럽게 하는 접착제로만 사용할 것이다. 우리는 결정론적 AI 의 시대에 진입하고 있다. 마법은 프롬프트에 있지 않고, 아키텍처에 있다.

결론 대규모 언어 모델이 "TravelPlanner" 벤치마크를 신뢰성 있게 정복하지 못한 것은

AI에 대한 비난이 아니다; "래퍼" 방법론에 대한 비난이다. 확률적

모델에게 결정론적 오케스트레이션을 수행하도록 요구함으로써, 업계는 그들을 실패하도록 설정했다. Veriprajna는 검증된 전진 경로를 제공한다. 신경-기호 오케스트레이션 을 수용함으로써, LLM이 가장 잘하는 것—인간 의도의 뉘앙스 이해—에 LLM을 활용하면서

소프트웨어 엔지니어링이 가장 잘하는 것—복잡하고 상태 유지· 컴플라이언트 비즈니스 프로세스 실행—의 엄격함을 유지한다. 현대 엔터프라이즈에게 선택은 명확하다: 일을 말하는 챗봇을 만들 수도 있고, 일을 하는 에이전트를 설계할 수도 있다. 차이는 그래프이다.

참고 문헌 LLM Recap: LLM Limitations and how to overcome them | by Chanon Krittapholchai | Medium, 2025년 12월 11일에 접근,

https://medium.com/@chanon.krittapholchai/llm-recap-llm-limitations-and-how-to-overcome-them-cecdddf9af8d

1. Why Do Multi-Agent LLM Systems Fail? Insights for Owners | SEO Locale, 2025년 12월 11일에 접근, https://seolocale.com/why-do-multi-agent-llm-systems-fail-insights-for-owners/

2. What drives Multi-Agent LLM Systems Fail ? - Hugging Face, 2025년 12월 11일에 접근, https://huggingface.co/blog/Musamolla/multi-agent-llm-systems-failure

3. Evaluating LLMs on Sequential API Call Through Automated Test Generation arXiv, 2025년 12월 11일에 접근, https://arxiv.org/html/2507.09481v2

4. TravelPlanner: A Benchmark for Real-World Planning with Language Agents arXiv, 2025년 12월 11일에 접근, https://arxiv.org/html/2402.01622v4

5. Why do Multi-Agent LLM Systems Fail - Galileo AI, 2025년 12월 11일에 접근, https://galileo.ai/blog/multi-agent-llm-systems-fail

6. [D] A contract-driven agent runtime: separating workflows, state, and LLM contract generation : r/MachineLearning - Reddit, 2025년 12월 11일에 접근, https://www.reddit.com/r/MachineLearning/comments/1phl090/d_a_contractdriven_agent_runtime_separating/

7. How Neurosymbolic AI Brings Hybrid Intelligence to Enterprises - Orange Bridge Marketing, 2025년 12월 11일에 접근, https://orange-bridge.com/latest-ai-data-trends/neurosymbolic-ai-promises-to-bring-hybrid-intelligence-to-enterprises

8. Neurosymbolic Programming for AI Agents | by Dorian Smiley - Medium, 2025년 12월 11일에 접근, https://dorians.medium.com/neurosymbolic-programming-for-ai-agents-2720257db7f3

9. CHINATRAVEL: A REAL-WORLD BENCHMARK FOR LANGUAGE AGENTS IN CHINESE TRAVEL PLANNING - OpenReview, 2025년 12월 11일에 접근, https://openreview.net/pdf?id=9dfRC2dq0R

10. TravelPlanner Benchmark - Emergent Mind, 2025년 12월 11일에 접근, https://www.emergentmind.com/topics/travelplanner-benchmark

11. ChinaTravel: A Real-World Benchmark for Language Agents in Chinese Travel Planning, 2025년 12월 11일에 접근, https://arxiv.org/html/2412.13682v2

12. Why Do Multi-Agent LLM Systems Fail? - arXiv, 2025년 12월 11일에 접근, https://arxiv.org/pdf/2503.13657

13. Why Do Multi-Agent LLM Systems Fail? - OpenReview, 2025년 12월 11일에 접근, https://openreview.net/pdf?id=MqBzKkb8eK

14. Air Booking Guide - Support, 2025년 12월 11일에 접근, https://support.travelport.com/webhelp/JSONAPIs/Airv11/Content/Air11/Book/BookingGuide.htm

15. Sabre API Integration Guide for Travel Portals Flights Hotel - phptravels, 2025년 12월 11일에 접근, https://phptravels.com/blog/sabre-api-integration

16. Flight APIs Tutorial - Amadeus for Developers, 2025년 12월 11일에 접근, https://developers.amadeus.com/self-service/apis-docs/guides/developer-guides/resources/flights/

17. Sabre Air API Solutions | Flight Shopping & Pricing API - Traveltekpro, 2025년 12월 11일에 접근, https://traveltekpro.com/sabre-air-api-solutions-flight-shopping-pricing-api/

18. Toolchaining: The Problem No One is Talking About | Scale, 2025년 12월 11일에 접근, https://scale.com/blog/toolchaining-llm-plans

19. Sabre API Integration: Hands-On Experience with a Leading GDS - AltexSoft, 2025년 12월 11일에 접근, https://www.altexsoft.com/blog/sabre-api-integration/

20. How to Integrate a Flight Booking API: A Step-by-Step Guide - Traveltekpro, 2025년 12월 11일에 접근, https://traveltekpro.com/how-to-integrate-a-flight-booking-api-a-step-by-step-guide/

21. LangGraph State Machines: Managing Complex Agent Task Flows in Production, 2025년 12월 11일에 접근, https://dev.to/jamesli/langgraph-state-machines-managing-complex-agent-task-flows-in-production-36f4

22. Building Better Agentic Systems with Neuro-Symbolic AI | Cutter Consortium, 2025년 12월 11일에 접근, https://www.cuter.com/article/building-bett

23. er-agentic-systems-neuro-symbolic-t ai LangChain vs LangGraph: Explained - Peliqan, 2025년 12월 11일에 접근, https://peliqan.io/blog/langchain-vs-langgraph/

24. What is LangGraph and How It Is Useful In Building LLM-Based Applications? Ampcome, 2025년 12월 11일에 접근, https://www.ampcome.com/articles/what-is-langgraph-how-it-is-useful-in-building-llm-based-applications

25. LangChain Vs LangGraph: Best, Definitive 2025 Agents Guide, 2025년 12월 11일에 접근, https://binaryverseai.com/langchain-vs-langgraph-decision-guide-framework/

26. LangGraph State: The Engine Behind Smarter AI Workflows - CloudThat Resources, 2025년 12월 11일에 접근, https://www.cloudthat.com/resources/blog/langgraph-state-the-engine-behind-smarter-ai-workflows

27. AI Agent Workflows: A Complete Guide on Whether to Build With LangGraph or LangChain, 2025년 12월 11일에 접근, https://towardsdatascience.com/ai-agent-workflows-a-complete-guide-on-whether-to-build-with-langgraph-or-langchain-117025509fa0/

28. Why use LangGraph? : r/AI_Agents - Reddit, 2025년 12월 11일에 접근, https://www.reddit.com/r/AI_Agents/comments/1l4uq7v/why_use_langgraph/

29. LangChain vs. LangGraph: A Developer's Guide to Choosing Your AI Workflow, 2025년 12월 11일에 접근, https://duplocloud.com/blog/langchain-vs-langgraph/

30. LangChain vs. LangGraph: A Developer's Guide to Choosing Your AI Workflow, 2025년 12월 11일에 접근, What is LangGraph? - IBM, 2025년 12월 11일에 접근,

31. https://www.ibm.com/think/topics/langgraph Constraining LLM Outputs with Finite State Machines | by Chirag Bajaj | Medium, 2025년 12월 11일에 접근,

32. https://medium.com/@chiragbajaj25/constraining-llm-outputs-with-finite-state-machines-79ca9e336b1f Human in the Loop AI: Benefits, Use Cases, and Best Practices - WitnessAI, 2025년 12월 11일에 접근,

33. https://witness.ai/blog/human-in-the-loop-ai/ What Is Human In The Loop (HITL)? - IBM, 2025년 12월 11일에 접근,

34. https://www.ibm.com/think/topics/human-in-the-loop The Human-AI Agents Partnership: In-, On-, or Out-of-the-Loop? - Lumenova AI, 2025년 12월 11일에 접근,

35. https://www.lumenova.ai/blog/ai-agents-the-human-ai-partnership/ LLM Inference Optimization Techniques | Clarifai Guide, 2025년 12월 11일에 접근,

36. https://www.clarifai.com/blog/llm-inference-optimization/ Effective context engineering for AI agents - Anthropic, 2025년 12월 11일에 접근,

37. https://www.anthropic.com/engineering/efective-context-engineering-for-ai-agfents https://www.anthropic.com/engineering/efective-context-engineering-for-ai-agfents