LLM 기반 AI 시스템의 치명적 오류: '상태 관리' 실패가 부르는 5가지 아키텍처 함정

최근 몇 년간 AI 기술의 발전 속도는 경이롭습니다. LLM(Large Language Model) 덕분에 우리는 단순한 질의응답을 넘어, 마치 인간 비서처럼 복잡한 업무 프로세스를 자동화하는 '에이전트 시스템' 시대를 목격하고 있습니다.

하지만 현업에서 실제로 복잡한 AI 서비스를 구축하고 운영해 본 시니어 개발자나 테크 리드라면, 한 가지 공통적인 벽에 부딪히는 경험을 했을 겁니다. 모델 자체의 성능(지능)이 문제가 아니라, 시스템이 '기억'하고 '맥락'을 유지하는 구조적 설계가 무너질 때, 시스템 전체가 엉뚱한 방향으로 헛발질하는 현상 말입니다.

"왜 어제까지 잘 되던 기능이 오늘 갑자기 꼬일까?", "이 복잡한 워크플로우를 따라가다 보면 어디서부터 잘못된 건지 알 수가 없다."

이러한 문제는 모델의 근본적인 한계라기보다는, AI 아키텍처 설계 단계에서 '상태(State)'를 어떻게 정의하고 관리할 것인가라는 근본적인 질문에 대한 답이 부족했기 때문일 수 있습니다.

이 글은 LLM 기반 서비스의 가장 취약한 부분, 즉 '상태 관리'에 초점을 맞춰, 여러분의 아키텍처가 견고한지 점검할 수 있는 실질적인 가이드가 될 것입니다.

🧠 1. AI 아키텍처에서 '상태(State)'란 무엇인가? (개념 정립)

우리가 흔히 '상태'라고 생각하는 것은 단순히 이전 대화 기록(Chat History) 정도일 것입니다. 하지만 고도화된 AI 에이전트에게 상태는 훨씬 다차원적이고 복잡합니다.

📌 단순 세션(Session) vs. 시스템 상태(System State)

• 단순 세션 (Session): 사용자와 AI 간의 주고받은 텍스트 로그. (가장 얕은 수준의 기억)
• 시스템 상태 (System State): AI가 수행하는 작업의 현재 위치, 사용자 프로필의 최신 정보, 외부 시스템(DB, API)에서 가져온 임시 결과물, 그리고 이 모든 것을 관통하는 비즈니스 로직의 현재 단계를 포함합니다.

만약 이 시스템 상태가 잘못 관리되면, AI는 마치 기억력이 나쁜 사람처럼 행동합니다.

🚨 상태 관리 실패가 초래하는 5가지 치명적 오류

1. 일관성 저하 (Inconsistency): 사용자가 "지난번에 A 방식으로 처리했으니, 이번에도 그렇게 해줘"라고 요청했는데, 시스템이 이전의 처리 방식을 잊어버리고 처음부터 다시 시작하는 경우.
2. 환각 현상 심화 (Hallucination Amplification): 모델이 내부적으로 잘못된 상태(예: 이미 완료된 작업을 '아직 안 함'으로 오인)를 바탕으로 답변을 생성하여, 거짓 정보를 더욱 확신에 차서 전달하는 경우.
3. 비용 폭증 (Cost Overrun): 이전 대화 기록이나 불필요한 중간 결과물까지 모두 컨텍스트 창에 쑤셔 넣으면서, 토큰 사용량이 기하급수적으로 증가하는 경우.
4. 작업 중단 (Stalemate): 에이전트가 다음 단계를 결정해야 할 시점에, 필요한 외부 상태(예: 특정 사용자 권한 여부)를 조회하지 못해 무한 루프에 빠지거나 작업을 멈추는 경우.
5. 데이터 오염 (Data Contamination): 여러 사용자의 상태나 작업 결과가 섞여서, A 사용자의 작업 결과가 B 사용자에게 잘못 적용되는 심각한 보안/논리적 오류.

🧩 2. 성공적인 AI 아키텍처를 위한 3가지 핵심 설계 패턴

이러한 상태 관리 문제를 해결하기 위해, 우리는 LLM 자체에 의존하는 것이 아니라, **모델 외부(External)**에 상태를 관리하는 구조를 설계해야 합니다.

💡 패턴 1: 메모리 계층화 (Memory Layering)

단순히 대화 기록을 쌓는 것이 아니라, 정보의 중요도와 활용 빈도에 따라 메모리를 계층화해야 합니다.

• Level 1: Context Window (단기 기억): 가장 최근의 몇 턴 대화. 휘발성이 강하며, 프롬프트에 직접 주입됩니다. (가장 빠르지만 용량 한계가 명확함)
• Level 2: Vector DB (중기 기억): 검색 증강 생성(RAG)의 핵심. 대화의 의미적 유사성을 기반으로 관련 문서를 검색하여 컨텍스트를 풍부하게 만듭니다.
• Level 3: Knowledge Graph (장기 기억): 엔티티(개체)와 그들 간의 관계를 구조화하여 저장합니다. "누가(Who) 무엇을(What) 언제(When) 했는지"와 같은 복잡한 관계 추론이 가능해지며, 단순 키워드 검색을 넘어섭니다.

💡 패턴 2: 상태 추적 엔진 (State Tracking Engine)

이것이 가장 중요한 개념적 도약입니다. LLM이 "내가 지금 무엇을 하고 있었지?"라고 물어볼 때, 모델은 대답할 수 없습니다. 외부의 전용 엔진이 이 질문에 답해야 합니다.

이 엔진은 Tool Calling/Function Calling의 개념을 극대화한 것입니다.

[개념적 흐름 예시]

1. 사용자 입력: "지난주에 주문한 상품의 배송 상태를 확인하고, 만약 지연되었다면 고객센터에 문의 티켓을 생성해 줘."
2. State Tracker: 이 요청을 받고, 현재 상태를 확인합니다. (→ 현재 작업: 배송 조회 필요)
3. Tool Call 1: get_order_status(order_id) 호출. (외부 DB 조회)
4. 결과 수신: "배송 지연 중"
5. 다음 액션 결정: "사용자에게 지연 사실을 알리고, 자동 문의 티켓 생성"
6. 결과 출력: 사용자에게 알림 및 티켓 ID 제공.

이처럼, 모델은 '결과'를 생성하는 것이 아니라, '다음 단계의 액션'을 결정하는 오케스트레이터 역할을 수행해야 합니다.

💡 비교: 단순 LLM vs. 에이전트 프레임워크

🚀 실전 적용: 상태 관리의 중요성 (State Management)

가장 흔한 실패 지점은 '상태(State)'를 잃어버리는 것입니다.

예시 시나리오: 사용자가 "내 주문 조회" $\rightarrow$ "배송지 변경" $\rightarrow$ "결제 취소" 순서로 요청할 때.

만약 시스템이 '주문 조회' 단계에서 받은 주문 ID를 다음 단계인 '배송지 변경' 단계에서 참조하지 못한다면, 시스템은 어떤 주문을 변경해야 할지 모르게 됩니다. 이 '주문 ID'를 다음 호출까지 유지하고 참조하는 것이 바로 '상태 관리'입니다.

🛠️ 요약 및 체크리스트

1. 상태 정의: 현재 프로세스에서 반드시 유지되어야 할 핵심 변수(ID, 사용자 인증 정보, 중간 결과물 등)를 명확히 정의하세요.
2. 도구(Tool) 정의: 외부 시스템과 상호작용할 수 있는 모든 API 호출을 명확한 함수(Tool)로 정의하세요.
3. 실행 루프 구축: LLM의 출력을 단순히 텍스트로 받아들이지 말고, **"다음으로 실행해야 할 Tool의 이름과 입력값"**으로 파싱하고, 이 루프를 돌리는 코드를 반드시 작성해야 합니다.

이러한 구조를 갖추는 것이 LLM을 단순한 챗봇을 넘어, 실제 업무를 수행하는 자동화 에이전트로 만드는 핵심 열쇠입니다.