제가 본 가장 유용한 여행 에이전트(travel agent) 워크플로우는 한 번의 프롬프트로 "내 휴가 계획을 세워줘"라고 요청하는 것이 아닙니다.

그것은 스크린샷, 예약 확인서, 메모 등을 입력받아 며칠 또는 몇 주 동안 일정을 최신 상태로 유지하고, 나중에 적절한 세부 정보를 검색(retrieval)하는 지속적인 어시스턴트입니다.

이것이 중요한 이유는 검색 기반 메모리(retrieval-based memory)를 사용하면 호출당 7,000 토큰 미만으로 답변할 수 있는 반면, "그냥 전체 스레드를 다시 보내기" 식의 무차별 대입(brute-force) 방식은 쉽게 25,000 토큰 이상을 소비할 수 있기 때문입니다.

이 사실이 저에게 깨달음을 준 순간은 식당 추천과는 전혀 상관이 없었습니다.

그것은 바로 호텔 주소였습니다.

장기 실행되는 에이전트 워크플로우를 조사하던 중, r/openclaw에서 누군가가 OpenClaw를 실제로 어떻게 사용하는지 설명한 스레드를 발견했습니다. 브레인스토밍을 위해서가 아니었습니다. "꿈같은 여행을 만들어줘"라고 하기 위해서도 아니었습니다.

그들의 워크플로우는 기본적으로 다음과 같았습니다:

• 여행당 하나의 일정(itinerary) 생성
• Airbnb, 호텔, 항공편, 택시 예약 스크린샷 업로드
• 나중에 후속 질문하기
• 전체 내용을 Notion과 동기화하기

그리고 질문들은 실제로 중요한, 다소 지루한 것들이었습니다:

• 내 호텔 주소가 뭐야?
• 내 비행기 시간은 언제야?
• 예약 번호(booking reference)가 뭐야?
• 아직 누락된 게 뭐야?

그것이 바로 제품(product)입니다.

여행 계획이 아닙니다.

여행 상태 관리(Trip state management)입니다.

이 패턴을 한 번 보고 나면, 많은 소비자용 AI 데모들이 거꾸로 된 것처럼 보이기 시작합니다.

유용한 부분은 일정이 복잡해진 이후부터 시작됩니다

화려한 데모는 쉽습니다.

GPT-5나 Claude Opus 4.6에게 10일간의 일본 여행 일정을 물어보면 괜찮은 답변을 얻을 수 있습니다. 커피숍, 동네, 당일치기 여행 등등. 운이 나쁘면 몇 가지 환각(hallucination)된 세부 정보가 포함될 수도 있겠지만요.

그 부분은 재미있지만, 어려운 부분이 아닙니다.

진짜 어려운 부분은 나중에 시작됩니다:

• 항공사가 출발 시간을 변경함
• 파트너가 호텔에서 보낸 PDF를 전달함
• Airbnb 체크인 메모를 스크린샷으로 찍음
• 택시 예약이 한 곳에서는 결제되고 다른 곳에서는 취소됨
• 예약 하나가 다른 사람의 이름으로 되어 있음

이제 문제는 더 이상 "어디로 가야 할까?"가 아닙니다.

그것은 바로:

• 이 항공편은 어느 터미널에서 출발하나요?
• 공항 픽업 서비스(Airport transfer) 비용을 이미 지불했나요?
• 오후 11시 40분에 기사님께 어떤 주소를 알려드려야 하죠?
• 아직 예약되지 않은 밤은 언제인가요?

이 지점이 바로 실제 에이전트(Agent)가 추천 엔진(Recommendation engine)을 압도하기 시작하는 부분입니다.

TripIt은 수년 전에 이 점을 파악했습니다. Wanderlog도 마찬가지였습니다. 그들의 진정한 가치는 영감을 주는 것이 아닙니다. 파편화된 예약 데이터(Booking data)를 신뢰할 수 있는 무언가로 통합하는 것입니다.

OpenClaw 스타일의 워크플로우(Workflow)와의 차이점은, 그 메모리(Memory) 위에 더 범용적인 어시스턴트(Assistant)를 구축할 수 있다는 점입니다.

이것은 사실 변장한 컨텍스트 윈도우 (Context-window) 문제이다

여행 어시스턴트는 대화 스레드(Thread)가 길어지기 전까지는 단순해 보입니다.

스크린샷 하나로 시작합니다.
그다음 호텔 예약 확인서.
그다음 택시 영수증.
그다음 레이트 체크아웃(Late checkout) 메모.
그다음 식당 예약.
그다음 취소.
그다음 대체 예약.

이제 당신의 컨텍스트 윈도우(Context window) 문제는 이론적인 것이 아닙니다. 실제 운영(Production)의 문제입니다.

큰 컨텍스트 윈도우가 도움이 되긴 하지만, 실제 문제를 해결해주지는 않습니다.

OpenClaw의 압축(Compaction) 문서는 이를 매우 명확하게 설명합니다. 최근의 끝부분(Tail)은 유지하고, 오래된 트랜스크립트(Transcript) 내용은 요약합니다. 유용하지만 한계가 있습니다.

OpenClaw 커뮤니티에서 본 최고의 요약은 다음과 같았습니다:

압축(Compaction)은 트랜스크립트에 포함되지 않았던 컨텍스트(Context)를 고칠 수 없다.

정확한 지적입니다.

항공편 번호가 한 번도 깔끔하게 캡처되지 않았다면, 어떤 요약 단계도 마법처럼 그것을 복구할 수 없습니다.

호텔 주소가 흐릿한 스크린샷에 파묻혀 지속 가능한 메모리(Durable memory)로 변환되지 않았다면, 나중에 GPT-5나 Claude Sonnet 4.6이 나타나도 당신을 구해줄 수 없습니다.

이것이 바로 "그냥 더 큰 컨텍스트 윈도우를 사면 된다"가 제대로 된 아키텍처(Architecture)가 아닌 이유입니다.

메모리 규율 (Memory discipline)이 무식한 롱 컨텍스트 (Long context)보다 낫다

이 부분은 많은 개발자가 여전히 과소평가하고 있다고 생각하는 지점입니다.

현대의 메모리 레이어(Memory layer)는 매 턴마다 전체 히스토리(History)를 다시 재생하는 것이 게으르게 보일 정도로 충분히 훌륭합니다.

Mem0의 벤치마크 결과는 다음과 같습니다:

• LoCoMo에서 92.5
• LongMemEval에서 94.4
• 검색 호출(Retrieval call)당 대략 6,700 ~ 6,900 토큰

동일한 작업에 대한 전체 컨텍스트(Full-context) 베이스라인은 25,000개 이상의 토큰을 사용합니다.

이는 결코 작은 최적화가 아닙니다.

이는 비용이 저렴하게 유지되는 워크플로우와, 사용자가 후속 질문을 던질 때마다 조용히 돈을 태워버리는 워크플로우 사이의 차이입니다.

여행의 경우, 채팅 패턴은 브루트 포스(Brute-force) 방식의 컨텍스트 활용에 특히 취약합니다. 동일한 상태(State)가 계속해서 반복적으로 재방문되기 때문입니다:

1. 스크린샷 파싱 (parse screenshots)
2. 구조화된 사실 추출 (extract structured facts)
3. 노트 업데이트 (update notes)
4. 질문 답변 (answer questions)
5. 변경 사항 조정 (reconcile changes)
6. 누락된 사항 확인 (check what’s still missing)

매번 전체 여행 정보를 다시 보낸다면, 당신은 오래된 컨텍스트(Stale context)에 대해 반복적으로 비용을 지불하게 됩니다.

n8n, Make, Zapier, OpenClaw 또는 커스텀 파이프라인(Custom pipelines)에서 에이전트를 구축하는 팀들에게, 이 지점은 가격 책정이 급격히 중요해지는 구간입니다.

토큰당 과금 방식(Per-token billing)은 에이전트가 잘 수행하는 바로 그 유형, 즉 장기 실행되고 검색 집약적인(Retrieval-heavy) 워크플로우에 불이익을 줍니다.

이것이 바로 여기서 정액제(Flat-rate) API 액세스가 흥미로운 이유입니다. 만약 지속적인 에이전트 루프(Persistent agent loops), 재시도(Retries), 메모리 검색(Memory retrieval), 그리고 수많은 후속 질의응답(Q&A)을 테스트하고 있다면, 매 실행마다 토큰 지출을 일일이 감시하지 않고도 아키텍처를 최적화하고 싶을 것입니다.

Standard Compute는 그러한 종류의 워크로드에 맞춰 구축되었습니다: OpenAI 호환 API, 고정 월간 가격, 그리고 GPT-5.4, Claude Opus 4.6, Grok 4.20을 가로지르는 라우팅(Routing)을 제공합니다. 이는 워크플로우가 대화가 많아질 때마다 토큰당 비용이 급증하는 것을 지켜보는 것보다 에이전트 실험에 훨씬 더 적합합니다.

OpenClaw의 메모리 모델이 여행에 잘 부합하는 이유

여기서 제가 OpenClaw에서 좋게 보는 점은 파일 기반 메모리 모델(File-based memory model)이 추론하기에 충분히 간단하다는 것입니다.

여행 상태를 다음과 같은 계층(Layer)으로 나눌 수 있습니다:

이러한 분리는 단순히 외관상의 문제가 아닙니다.

이는 모든 프롬프트가 오래된 컨텍스트로 가득 찬 쓰레기차(Garbage truck)가 되는 것을 막는 방법입니다.

어시스턴트는 미래의 모든 답변에 해당 노트를 끌고 들어가지 않고도, 어제의 택시 노트를 어디에서 찾아야 하는지 알아야 합니다.

실제적인 버전은 다음과 같습니다:

trip-agent/
├── USER.md
├── MEMORY.md
...

USER.md 예시:

사용자 선호도 (User Preferences)

• 통로 좌석 선호
• 가능한 경우 오전 8시 이전 출발 지양
  ...

MEMORY.md 예시:

# 지속 가능한 여행 사실 (Durable Trip Facts)
- 9월 14일 ANA NH112편 확정, SFO 터미널 G에서 13:20 출발
- 교토 호텔: 호텔 그란비아 교토 (Hotel Granvia Kyoto)
...

날짜가 포함된 노트 예시:

# 2025-09-10
- 항공사 출발 시간이 12:40에서 13:20으로 변경됨
- 배우자가 업데이트된 PDF 확인서를 전달함
...

이러한 구조는 지루해 보일 수 있지만, 바로 그 점 때문에 효과적입니다.

핵심 파이프라인은 캡처(capture) -> 정규화(normalize) -> 검색(retrieve)입니다

만약 제가 오늘 이 시스템을 구축한다면, 아키텍처를 고통스러울 정도로 단순하게 유지할 것입니다.

1단계: 예약 아티팩트(booking artifacts) 캡처

지저분한 입력값들을 수용합니다:

• 스크린샷 (screenshots)
• 전달된 이메일 (forwarded emails)
• PDF
• 붙여넣은 텍스트 (pasted text)
• 채팅 메시지 (chat messages)

2단계: 구조화된 사실 추출

원시 입력값을 신뢰할 수 있는 필드로 변환합니다:

{
  "type": "hotel",
  "name": "Hotel Granvia Kyoto",
...

3단계: 지속 가능한 메모리 기록

MEMORY.md 또는 구조화된 저장소(structured store)에 지속 가능한 사실을 추가합니다.

4단계: 대화 기록 재생이 아닌 검색을 통한 답변

사용자가 "제 호텔 주소가 뭐죠?"라고 물을 때, 전체 여행 스레드를 모델에 다시 쏟아붓는 대신 관련 메모리를 가져옵니다.

최소 구현 스케치

다음은 OpenAI 호환 API를 위한 대략적인 CLI 스타일의 흐름입니다.

curl https://api.standardcompute.com/v1/chat/completions \
  -H "Authorization: Bearer $STANDARD_COMPUTE_API_KEY" \
  -H "Content-Type: application/json" \
...

그 다음 추출된 사실을 검색 가능한 어딘가에 저장합니다.

의사 코드 (Pseudo-code):

booking = extract_booking(raw_input)
write_durable_memory(booking)
index_for_retrieval(booking)

나중에:

question = "교토에 있는 제 호텔 주소가 무엇인가요?"
context = retrieve_relevant_memory(question)
answer = ask_model(question, context)

이것이 전체 패턴입니다.

화려하지는 않지만, 매우 효과적입니다.

TripIt과 Wanderlog은 여전히 때때로 정답입니다

분명히 말씀드리자면: 만약 여러분의 유일한 요구사항이 "내 예약 정보를 한곳에 모으는 것"이라면, TripIt과 Wanderlog은 이미 훌륭한 제품입니다.

단순히 TripIt의 더 약한 버전을 재현하기 위해 커스텀 에이전트 (Custom Agent)를 구축해서는 안 됩니다.

커스텀 에이전트는 일정 가져오기(Itinerary Import) 이상의 기능이 필요할 때 승리합니다:

• 스크린샷, 메모, 채팅 기록 전반에 걸친 임의의 질의응답 (Q&A)
• 여러 소스 간의 충돌 해결 (Conflict Resolution)
• 아직 누락된 항목 추적
• 예약 정보와 사용자 선호도 결합
• 취약한 글루 코드 (Glue Code) 없이 비정형 입력 처리

이 지점에서 OpenClaw 스타일의 메모리 (Memory)가 중요해지기 시작합니다.

지루한 부분이 실제 제품입니다

제 주관적인 견해는 다음과 같습니다:

여행 추천은 데모(Demo)입니다.
일정 유지 관리 (Itinerary Maintenance)가 제품입니다.

"나를 위해 완벽한 10일간의 일본 여행을 만들어줘"는 재미있습니다.

"내 ANA 항공편, 에어비앤비(Airbnb) 도어 코드, 신칸센 예약, 교토 호텔 주소를 기억했다가, 내가 아직 예약하지 않은 것이 무엇인지 알려줘"는 유용합니다.

하나는 엔터테인먼트입니다.

다른 하나는 배터리가 3% 남은 채 공항 밖에 서 있고 호텔 확인 이메일이 어디로 갔는지 전혀 모를 때 여러분을 구해줍니다.

이것이 여행이 매우 강력한 소비자 에이전트 워크플로우 (Consumer Agent Workflow)인 이유입니다.

데이터는 파편화되어 있습니다.
작업은 며칠 또는 몇 주에 걸쳐 진행됩니다.
질문은 구체적입니다.
정확한 답변의 가치는 즉각적입니다.
그리고 메모리가 허술할 때 발생하는 실패 모드 (Failure Mode)는 잔인할 정도로 명확합니다.

개발자를 위한 실질적인 시사점

장기 실행 에이전트 (Long-running Agents)를 구축하고 있다면, 이 여행 사례는 잘 일반화될 수 있습니다.

1. 생성 (Generation)과 메모리를 혼동하지 마세요

멋진 일정을 생성하는 것은 쉽습니다.
변화하는 여행 상태 (Trip State)를 기억하는 것이 어려운 부분입니다.

2. 더 큰 컨텍스트 윈도우 (Context Window)가 캡처 (Capture)를 대체할 수는 없습니다

만약 어떤 사실이 한 번도 깔끔하게 추출되지 않았다면, 200k 윈도우도 여러분을 구원하지 못할 것입니다.

3. 내구성이 있는 메모리는 구조화되어야 합니다

스크린샷과 PDF는 입력값 (Inputs)이지 메모리가 아닙니다.
메모리는 추출되고, 정규화되며, 검색 가능한 상태 (Retrievable State)입니다.

4. 검색 (Retrieval)이 일반적으로 재생 (Replay)보다 낫습니다

사용자가 동일한 코퍼스 (Corpus)에 대해 반복적인 질문을 던지는 경우, 전체 트랜스크립트 (Transcript)를 모델에 다시 밀어 넣는 것보다 검색 (Retrieval)이 더 효과적입니다.

5. 에이전트 설계에는 비용 모델이 중요합니다

장기 실행되는 자동화 (Automations)는 대화량이 많아집니다. 정액제 방식의 액세스 (Flat-rate access)는 이러한 워크플로우 (Workflows)를 얼마나 공격적으로 테스트하고, 반복 개선하며, 배포할 수 있는지를 변화시킵니다.

만약 여러분이 n8n, Make, Zapier, OpenClaw 또는 자체 스택 내에서 작동하는 에이전트를 구축하고 있다면, 이것이 바로 Standard Compute가 합리적인 이유가 되는 워크로드 유형입니다. OpenAI와 호환되는 동일한 API 형태를 유지하면서도, 에이전트가 생각하거나, 재시도하거나, 검색하거나, 상태 (State)를 조정해야 할 때마다 토큰당 비용을 걱정할 필요가 없습니다.

만약 제가 이번 주에 이것을 만든다면

저는 다음과 같이 시작하겠습니다:

mkdir -p trip-agent/memory
touch trip-agent/USER.md trip-agent/MEMORY.md

그다음 세 가지 함수를 구현하겠습니다:

def extract_booking(raw_artifact):
    ...

...

그리고 이 세 가지가 안정적으로 작동할 때까지 화려한 오케스트레이션 (Orchestration)에는 손을 대지 않을 것입니다.

왜냐하면 핵심은 오케스트레이션이 아니기 때문입니다.

그것은 절제된 캡처 (Capture)입니다.

모든 예약 아티팩트 (Booking artifact)는 내구성이 있는 사실 (Durable facts)이 되어야 합니다.
모든 내구성이 있는 사실은 검색 가능한 어딘가에 존재해야 합니다.
모든 검색은 전체 여행 기록을 재생 (Replaying)하는 것보다 저렴해야 합니다.

이것이 설계의 핵심입니다.

이 점을 깨닫고 나면, 여행 서비스는 더 이상 귀여운 소비자용 AI 데모처럼 보이지 않고, 지속성 있는 에이전트 (Persistent agents)가 마침내 현실이 되고 있다는 가장 명확한 증거 중 하나로 보이기 시작할 것입니다.