AI가 긴 작업에서 계획을 어디에 두나 — OpenClaw는 맥락 속에, Hermes는 외부 목록에

개인 AI 어시스턴트 OpenClaw를 다룰 때, 그 봇은 사람이 시킨 여러 단계짜리 일을 메신저 채널에서 이어 처리했다. 그런데 도구 목록을 아무리 뒤져도 "긴 작업의 계획을 따로 적어 추적하는" 전용 도구는 없었다. 가장 가까운 것이 message 도구인데, 이건 에이전트가 채널로 결과를 능동 발신하는 도구지 계획을 붙들어 두는 도구가 아니다. 그래서 OpenClaw에서 "다음에 뭘 할지"라는 계획은 늘 대화 그 자체 — 즉 AI가 한눈에 보는 맥락 창(context window — 모델이 한 번에 입력으로 받는 대화·문서의 최대 분량) 안에 암묵적으로만 존재했다.

또 다른 오픈소스 AI 에이전트 Hermes Agent를 같은 집 서버에 올려 내부를 뜯어보니, 정확히 이 지점에 전용 도구를 하나 박아 두었다. 이름은 todo — AI가 자기 할 일 목록을 대화 밖 별도 저장소에 적고 지워 가며 일하는 도구다. 여기서 한 가지 축이 선명하게 갈린다. 긴 멀티스텝 작업에서 '계획'을 어디에 두느냐다 — 휘발성 맥락 안에 그냥 두느냐(OpenClaw, 전용 장치 없음), 아니면 도구가 관리하는 영속 외부 상태로 빼서 붙드느냐(Hermes todo). 이 글은 그 갈림길 하나만 따라간다.

같은 문제, 갈라지는 결정 — 계획을 맥락에 둘까, 외부 목록으로 뺄까

두 봇이 마주한 문제는 똑같다. AI 에이전트가 하는 일은 대부분 "이 저장소를 클론해 테스트를 돌리고, 실패 항목을 고친 뒤 PR을 올려라" 같은 여러 단계로 이뤄진 긴 작업이다. 한 번의 응답으로 끝나지 않고, 명령을 여러 번 실행하고 중간 결과를 읽으며 수십 턴을 이어 간다. 이때 "전체 계획"을 어디에 보관하느냐에서 두 봇의 결정이 갈린다.

▲ OpenClaw — 계획을 붙드는 전용 도구 없이, 대화 맥락 안에 둔다

위 다이어그램은 OpenClaw가 계획을 두는 자리를 요약한 것이다. 계획을 따로 관리하는 도구가 없으니, "다음에 뭘 할지"는 명령 실행 결과나 로그와 나란히 대화 맥락 안에 평범한 문장으로 얹힌다. 즉 계획이 다른 대화 내용과 동등한 취급을 받는다. 이건 결함이 아니라 설계 선택에 가깝다 — OpenClaw는 사람과 메신저로 주고받는 상호작용에 무게를 뒀고, 그 결과 계획 추적을 위한 별도 장치를 두지 않았다.

▲ Hermes — 계획을 도구가 쥔 외부 목록으로 빼 둔다

위 다이어그램은 Hermes가 같은 계획을 어디에 두는지 보여준다. 할 일 목록은 대화 안이 아니라 TodoStore라는 대화 밖 별도 저장소에 살고, AI는 todo 도구를 통해서만 그 목록을 읽고 쓴다. OpenClaw와의 결정적 차이가 여기서 갈린다 — 한쪽은 계획을 휘발성 맥락에 얹었고, 다른 쪽은 도구가 관리하는 외부 상태로 떼어 냈다. 왜 이 차이가 중요한지는 다음 두 장면에서 드러난다.

맥락에만 둔 계획은 압축을 못 넘는다 — OpenClaw가 감수하는 것

대규모 언어 모델(LLM, 사람의 말로 대화하고 작업을 수행하는 AI)의 맥락 창은 사람으로 치면 "한눈에 들어오는 책상 위 면적"이다. 대화가 길어지면 이 책상이 꽉 차고, 오래된 종이는 책상 밖으로 밀려난다. 계획을 그 책상 위 문장으로만 적어 둔다면, 계획도 오래된 종이와 똑같은 운명을 맞는다.

위 다이어그램은 계획을 맥락에만 둔 구성이 긴 작업에서 길을 잃는 과정을 보여준다. 다섯 단계짜리 지시를 한 단계씩 실행하다 보면 명령 결과와 로그가 책상을 빠르게 채우고, 어느 순간 한눈에 담을 분량을 넘긴다. 그 시점부터 가장 오래된 내용 — 처음 받은 전체 지시와 이미 끝낸 단계들 — 이 시야에서 사라진다. 함정은 이게 모델이 멍청해서가 아니라 구조적으로 일어나는 일이라는 점이다. 더 똑똑한 모델을 써도 책상이 좁으면 오래된 종이는 똑같이 밀려난다. 계획을 위한 전용 도구가 없는 OpenClaw식 구성은, 긴 자율 작업에서 바로 이 흐름에 그대로 노출된다.

결정타는 맥락 압축(context compression — 대화가 너무 길어졌을 때 오래된 내용을 짧은 요약으로 줄여 책상 공간을 비우는 작업)이다. 압축이 일어나면 상세한 대화 기록이 요약으로 쪼그라드는데, 계획을 대화 문장으로만 적어 뒀다면 그 계획도 요약에 뭉개져 사라진다. Hermes가 굳이 계획을 도구로 떼어 낸 이유가 여기 있다.

Hermes의 답 — 계획을 도구가 쥔 외부 목록으로 뺀다

Hermes의 todo 저장소는 대화 한 세션당 하나씩 생성되고, 각 할 일 항목은 세 가지 정보만 갖는다.

# 할 일 항목 하나의 구조 (todo_tool.py)
# id      : 항목을 가리키는 고유 식별자 (AI가 직접 정함)
# content : 할 일 내용 (짧은 작업 설명)
# status  : 진행 상태 — 아래 네 가지 중 하나
VALID_STATUSES = {"pending", "in_progress", "completed", "cancelled"}
#   pending     = 아직 안 함
#   in_progress = 지금 하는 중
#   completed   = 끝냄
#   cancelled   = 취소함(실패했거나 불필요해짐)

코드 설명. 할 일 항목 하나가 어떤 모양인지 보여준다. 식별자, 내용, 상태 — 딱 세 칸이다. 핵심은 상태가 네 단계로 명시적이라는 점이다. "아직 안 함 / 지금 하는 중 / 끝냄 / 취소함"을 AI가 항목마다 표시하므로, 목록만 보면 전체 진행 상황이 한눈에 잡힌다. 계획이 대화 문장으로 흩어져 있던 OpenClaw 쪽과 달리, 여기서는 진행 상태가 데이터로 못 박혀 있다. 완료와 취소를 굳이 나눈 이유도 있는데, 실패해서 접은 항목을 끝낸 항목과 똑같이 두면 AI가 "이건 했네"라고 착각하기 때문이다.

압축을 타고 살아남는다

진짜 핵심은 이 목록이 맥락 압축을 견디고 살아남는다는 데 있다. 압축이 일어나 상세한 대화 기록이 사라지는 바로 그 순간, Hermes는 todo 목록을 압축된 대화 뒤에 다시 끼워 넣는다.

# 맥락 압축 직후 — 할 일 목록을 다시 주입 (conversation_compression.py)
todo_snapshot = agent._todo_store.format_for_injection()
if todo_snapshot:
    # 압축된 대화 기록 뒤에 할 일 목록을 user 메시지로 덧붙임
    compressed.append({"role": "user", "content": todo_snapshot})

코드 설명. 대화를 압축해 책상을 비운 직후, 별도 저장소에 살아 있던 할 일 목록을 꺼내 압축된 대화 뒤에 다시 붙이는 장면이다. 다른 모든 게 짧은 요약으로 쪼그라들어도 계획만큼은 온전한 형태로 책상 위에 다시 놓인다. 이게 앞 장면의 "계획이 압축에 뭉개진다"는 문제를 정면으로 푸는 지점이다 — 계획을 대화와 분리해 뒀기 때문에, 대화가 압축돼도 계획은 그 운명을 따라가지 않고 매번 새로 주입된다. 즉 todo 목록은 압축이라는 파도를 타고 넘는 부표처럼 동작한다. OpenClaw처럼 계획을 맥락에만 뒀다면 이 파도에 계획이 함께 쓸려 갔을 자리다.

주입할 때 한 가지 영리한 선별이 들어간다. 끝냈거나 취소한 항목은 빼고, 아직 안 한 것과 하는 중인 것만 다시 넣는다.

위 다이어그램은 압축 후 어떤 항목만 골라 되돌리는지 보여준다. 아직 안 한 항목과 지금 하는 중인 항목만 책상 위로 올리고, 이미 끝냈거나 취소한 항목은 일부러 뺀다. 끝낸 항목까지 매번 다시 보여 주면, AI가 압축 직후 "어 이것도 해야 하나?" 하며 이미 마친 일을 다시 하는 사고가 생기기 때문이다. 직관과 반대인데 — 완료한 일을 계속 보여 주는 게 친절해 보이지만, 실제로는 그게 중복 수행을 부르는 덫이다. "보여 주지 않음"이 오히려 안전한 설계다.

인스턴스가 새로 떠도 계획은 복구된다

Hermes의 게이트웨이(텔레그램·디스코드 같은 메신저 메시지를 받아 AI에 넘기는 입구)는 메시지가 올 때마다 AI 인스턴스를 새로 만든다. 그러면 메모리에 살던 todo 저장소도 매번 텅 빈 채로 시작한다 — 계획을 맥락에만 뒀다면 매 메시지마다 계획이 리셋되는 셈이다. Hermes는 이 빈틈도 외부 상태로 막는다.

위 다이어그램은 매번 새로 태어나는 AI가 어떻게 직전 계획을 되찾는지 보여준다. 새 인스턴스의 할 일 저장소는 비어 있으므로, 지난 대화 기록을 가장 최근 쪽부터 거꾸로 훑어 마지막으로 남긴 todo 응답을 찾아낸다. todo 도구는 호출될 때마다 항상 목록 전체를 응답으로 남기기 때문에, 그 최신 응답 하나만 찾으면 계획의 완전한 스냅샷이 통째로 잡힌다. 그걸 저장소에 다시 채우면 계획이 복구되고, AI는 끊김 없이 작업을 이어 간다. 계획이 대화 맥락이 아니라 되찾을 수 있는 외부 상태로 존재하기에 가능한 복구다.

정리 — 계획을 어느 층에 맡겼나

결국 두 봇은 "긴 작업을 끝까지 추적하라"라는 같은 요구를, 계획을 어디에 두느냐라는 결정 하나로 전혀 다르게 감당한다. OpenClaw는 계획을 휘발성 맥락에 두고 전용 장치를 두지 않았고, Hermes는 계획을 도구가 쥔 영속 외부 상태로 떼어 냈다.

	OpenClaw	Hermes
계획이 사는 곳	맥락 창 안 — 전용 도구 없이 대화 문장으로	대화 밖 todo 목록 — 도구가 상태로 관리
맥락 압축·인스턴스 재시작 때	계획도 함께 휘발·리셋될 수 있음	미완 항목만 자동 재주입·복구

어느 쪽이 옳다기보다, 각자 강한 자리가 다르다. OpenClaw는 사람과 메신저로 주고받는 상호작용에 무게를 뒀고, 결과를 채널에 능동 발신하는 message 같은 도구가 그 강점이다 — 대신 긴 자율 작업에서 계획을 붙드는 장치는 감수하지 않았다. Hermes의 todo는 화려한 기능이 아니라 "AI가 긴 작업의 전모를 잊지 않게 붙들어 주는 외부 기억 장치"다. 사람도 복잡한 일을 할 때 머릿속에만 담아 두지 않고 종이에 할 일을 적어 하나씩 지워 나간다. 맥락 창은 좁고 대화는 압축되며 인스턴스는 매번 새로 뜨는데, 그 모든 휘발을 견디고 살아남는 한 장의 목록이 있느냐 없느냐가 "다섯 단계짜리 작업을 끝까지 해내는 에이전트"와 "세 단계쯤에서 길을 잃는 에이전트"를 가른다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.