많은 기업과 개발자들이 LLM(거대언어모델)을 도입하며 가장 먼저 마주하는 벽은 ‘기억력의 한계’입니다. 단순히 프롬프트를 잘 작성하는 것만으로는 해결되지 않는 문제가 있습니다. 바로 AI가 복잡한 워크플로우를 수행하는 과정에서 현재 자신이 어디에 있는지, 이전 단계에서 무엇을 결정했는지, 그리고 사용자의 의도가 어떻게 변했는지를 정확히 추적하는 능력, 즉 상태 관리(State Management)의 부재입니다.

단순한 질의응답형 챗봇은 ‘무상태(Stateless)’ 구조로도 충분합니다. 하지만 스스로 도구를 선택하고, 실행 결과를 검토하며, 목표를 달성할 때까지 루프를 도는 ‘에이전틱 시스템(Agentic Systems)’에서는 이야기가 완전히 달라집니다. 상태 관리가 제대로 되지 않는 에이전트는 무한 루프에 빠지거나, 방금 수행한 작업을 잊어버리고 다시 반복하는 치명적인 결함을 보입니다. 결국 AI 에이전트의 성능은 모델의 파라미터 수보다, 그 모델이 활용하는 ‘상태’를 얼마나 정교하게 설계했느냐에 따라 결정됩니다.

상태(State)와 상태값(Status)의 결정적 차이

기술적인 구현에 들어가기에 앞서, 우리가 흔히 혼용하는 ‘State’와 ‘Status’의 개념을 명확히 할 필요가 있습니다. 이는 에이전틱 시스템의 아키텍처를 설계할 때 매우 중요한 구분점이 됩니다.

• Status (상태값): 시스템의 현재 지점을 나타내는 스냅샷입니다. 예를 들어 ‘대기 중’, ‘처리 중’, ‘완료’, ‘에러’와 같이 정의된 유한한 상태(Finite State) 중 하나를 가리킵니다. 이는 단순한 플래그(Flag)에 가깝습니다.
• State (상태): 시스템이 동작하기 위해 필요한 모든 데이터의 집합입니다. 여기에는 사용자의 이전 입력값, LLM이 생성한 중간 추론 과정, 외부 API로부터 받은 응답 데이터, 그리고 현재 달성해야 할 세부 목표들이 모두 포함됩니다.

에이전틱 시스템에서 우리가 집중해야 할 것은 단순한 Status 업데이트가 아니라, 복잡한 State의 전이(Transition)와 유지입니다. AI 에이전트는 단순한 상태 머신이 아니라, 동적으로 상태를 생성하고 수정하는 유연한 메모리 시스템을 갖춰야 하기 때문입니다.

에이전틱 시스템의 상태 관리 아키텍처

효과적인 에이전트 구현을 위해서는 상태를 세 가지 계층으로 분리하여 관리하는 전략이 필요합니다.

첫째는 단기 메모리(Short-term Memory)입니다. 이는 주로 LLM의 컨텍스트 윈도우(Context Window) 내에 존재하는 정보입니다. 현재 진행 중인 대화의 흐름과 즉각적인 추론 과정이 여기에 해당합니다. 하지만 컨텍스트 윈도우는 비용과 성능의 한계가 명확하므로, 모든 정보를 여기에 담는 것은 비효율적입니다.

둘째는 작업 메모리(Working Memory)입니다. 에이전트가 특정 목표를 달성하기 위해 임시로 저장하는 ‘스크래치패드(Scratchpad)’와 같습니다. 예를 들어, 여러 웹페이지에서 정보를 수집해 요약해야 한다면, 각 페이지에서 추출한 핵심 정보를 임시 저장소에 보관했다가 최종 단계에서 통합하는 방식입니다.

셋째는 장기 메모리(Long-term Memory)입니다. 벡터 데이터베이스(Vector DB)나 외부 데이터베이스를 통해 구현됩니다. 사용자의 과거 선호도, 기업의 정책, 과거의 성공적인 문제 해결 패턴 등을 저장하여 필요할 때마다 검색(Retrieval)하여 컨텍스트에 주입합니다.

기술적 구현의 트레이드오프: 중앙 집중형 vs 분산형

상태를 어디서 관리하느냐에 따라 시스템의 확장성과 안정성이 달라집니다. 아래 표는 대표적인 두 가지 접근 방식의 비교입니다.

실제 산업 적용 사례: DAM과 PMS의 진화

최근 등장하는 ‘에이전틱’ 솔루션들은 이러한 상태 관리 개념을 비즈니스 로직에 녹여내고 있습니다. 예를 들어, 최근 발표된 에이전틱 디지털 자산 관리(Agentic DAM) 시스템의 경우, 단순히 파일을 저장하고 검색하는 것을 넘어 ‘콘텐츠의 거버넌스 상태’를 관리합니다. AI 에이전트가 자산의 사용 권한, 브랜드 가이드라인 준수 여부, 업데이트 주기 등의 상태를 실시간으로 추적하며, 조건이 충족되지 않은 자산은 자동으로 격리하거나 수정 제안을 보냅니다.

또한 에이전틱 부동산 관리 시스템(Agentic PMS)은 임대 계약의 생애주기라는 거대한 ‘상태’를 관리합니다. 입주 문의부터 계약, 임대료 수납, 유지보수 요청, 퇴거에 이르기까지 각 단계의 상태를 AI가 인식하고, 다음 단계로 넘어가기 위해 필요한 액션을 스스로 결정합니다. 이는 단순한 자동화 툴이 아니라, 비즈니스 프로세스 자체를 상태 기반의 에이전트 워크플로우로 재설계한 사례라고 볼 수 있습니다.

실무자를 위한 에이전틱 상태 설계 액션 아이템

단순한 래퍼(Wrapper) 수준의 AI 앱을 넘어 진정한 에이전틱 시스템을 구축하려는 개발자와 PM이라면 다음의 단계를 밟으십시오.

• 상태 전이도(State Transition Diagram) 작성: 코드를 짜기 전, 에이전트가 가질 수 있는 모든 상태와 그 상태를 변화시키는 트리거(Trigger)를 시각화하십시오. LLM에게 모든 것을 맡기지 말고, 핵심 비즈니스 로직은 결정론적인(Deterministic) 상태 머신으로 제어해야 합니다.
• 컨텍스트 다이어트 실시: 모든 대화 기록을 LLM에 밀어 넣지 마십시오. 현재 단계에서 반드시 필요한 정보만 추출하여 전달하는 ‘컨텍스트 압축’ 또는 ‘요약 상태’를 도입하여 토큰 비용을 줄이고 추론 정확도를 높이십시오.
• 상태 체크포인트 및 롤백 구현: AI 에이전트는 언제든 잘못된 방향으로 추론할 수 있습니다. 특정 단계마다 상태를 저장(Checkpointing)하고, 오류가 발견되었을 때 이전의 안정적인 상태로 되돌릴 수 있는 롤백 메커니즘을 설계하십시오.
• 관측 가능성(Observability) 확보: 에이전트가 현재 어떤 상태에 있으며, 왜 다음 상태로 전이했는지 로그를 남기십시오. ‘AI가 왜 이렇게 행동했지?’라는 질문에 답할 수 있는 유일한 방법은 상태 변화의 기록을 추적하는 것입니다.

결론: 모델의 지능보다 시스템의 구조가 우선이다

GPT-4o나 Claude 3.5 같은 고성능 모델의 등장은 놀랍지만, 모델의 지능만으로는 복잡한 엔터프라이즈 문제를 해결할 수 없습니다. 모델은 ‘엔진’일 뿐이며, 그 엔진이 목적지까지 정확하게 도달하게 만드는 것은 ‘핸들과 내비게이션’, 즉 정교한 상태 관리 시스템입니다.

결국 경쟁력 있는 AI 제품을 만드는 팀은 더 좋은 모델을 찾는 팀이 아니라, 모델이 가장 효율적으로 작동할 수 있는 상태 구조를 설계하는 팀이 될 것입니다. 지금 바로 여러분의 에이전트가 ‘무엇을 기억하고 있고, 어디로 가고 있는지’를 정의하는 것부터 시작하십시오.