코딩 에이전트(coding agent)는 스레드(thread)를 활성 상태로 유지하면서도 여전히 망각하는 것처럼 느껴질 수 있습니다.

그것은 제가 상주형 어시스턴트, Claude Code, Codex CLI, 모델 라우팅(model routing), 채널(channels), 그리고 예약된 작업(scheduled work)을 위한 로컬 컨트롤 플레인(local control plane)인 CliGate에서 세션 연속성(session continuity)을 수정한 후 맞닥뜨린 짜증스러운 부분이었습니다.

세션은 존재했습니다. 후속 작업(follow-up)도 작동했습니다. 하지만 반복되는 작업들은 여전히 마땅히 그래야 하는 것보다 느렸습니다.

왜일까요?

에이전트가 대화(conversation)를 기억했을 뿐, 작업(work)을 기억하지 못했기 때문입니다.

활성 세션은 사용 가능한 메모리(usable memory)와 동일하지 않다

세션 연속성(Session continuity)은 하나의 실제 문제를 해결합니다.

그것은 다음과 같은 후속 작업들이 완전히 새로운 시작으로 변하는 것을 방지합니다:

• 계속해 (continue)
• 이 파일에 대해서도 똑같이 해줘
• 저걸 다시 시도해 (retry)
• 에러를 설명해줘

그것은 중요합니다.

하지만 며칠 후 워크플로(workflow)를 반복하는 순간 나타나는 또 다른 문제는 해결하지 못합니다.

만약 에이전트가 이전에 다음과 같은 것들을 파악했다면:

• 어떤 버튼이 실제로 작동하는지
• 어떤 단계가 막다른 길인지
• 어떤 필드에 특별한 처리가 필요한지
• 사용자가 항상 적용하기를 원하는 규칙이 무엇인지

그렇다면 여전히 열려 있는 세션만으로는 충분하지 않습니다.

유용한 것은 스레드(thread)가 존재하는 것이 아닙니다.

유용한 것은 에이전트가 지난 실행을 성공하게 만들었던 것이 무엇인지 회상(recall)할 수 있는 것입니다.

버그는 "프로세스 건망증(process amnesia)"이었다

첫 번째 실행에는 보통 비용이 많이 드는 부분이 포함됩니다.

그때 에이전트는 탐색하고, 검증하고, 되돌아가고(backtracks), 이상적인 프롬프트(prompt)에는 절대 들어있지 않은 아주 작은 세부 사항들을 발견합니다:

• 이 페이지는 메뉴 아래에 동작을 숨겨 놓았다
• 이 에디터는 실제로는 iframe이다
• 이 프로젝트는 중국어 답변과 간결한 상태 업데이트를 원한다
• 이 환경 URL은 프로덕션(production)과 다르다

CliGate에서 이 문제를 수정하기 전에는, 이러한 세부 사항들이 오직 가공되지 않은 실행 기록(raw execution history)으로만 존재했습니다.

그것은 에이전트가 기술적으로는 로그(logs)를 가지고 있지만, 재사용 가능한 메모리(reusable memory)는 없다는 것을 의미했습니다.

다음번에 유사한 작업이 주어졌을 때, 에이전트는 종종 너무 많은 것을 다시 발견해야만 했습니다.

그것은 지능이 아닙니다.

그것은 동일한 디버깅 비용을 두 번 지불하는 것입니다.

나는 메모리를 채팅 트랜스크립트(chat transcript) 문제처럼 취급하는 것을 그만두었다

잘못된 모델은 다음과 같았습니다:

더 많은 히스토리 저장 -> 더 많은 컨텍스트 (context) 유지 -> 다음 실행 시 이를 잘 활용하기를 기대함

이 방식은 약간의 도움이 되지만, 금방 노이즈 (noise)가 심해집니다.

제가 실제로 필요했던 것은 더 작고 재사용 가능한 계층이었습니다:

• 절차 (procedures)
• 사실 (facts)
• 지시 사항 (directives)
• 참조 (references)

다시 말해, "일어난 모든 일"이 아니라, "일어난 일 중에서 기억해야 할 것"이 필요했습니다.

그것이 시스템의 형태를 바꾸어 놓았습니다.

다음 실행 시 거대한 트랜스크립트 (transcript)로부터 교훈을 추론하도록 강제하는 대신, 이제 어시스턴트는 다음과 같은 내용을 회상할 수 있는 파일 기반의 메모리 계층 (memory layer)을 갖게 되었습니다:

• 절차 (procedure): 현재 가장 최선의 단계와 알려진 막다른 길
• 사실 (fact): URL, 환경 규칙, 또는 알려진 설정
• 지시 사항 (directive): 사용자가 일을 처리하기를 원하는 방식
• 참조 (reference): 관련 문서가 있는 위치

이것이 사람들이 실제로 일하는 방식에 훨씬 더 가깝습니다.

중요한 규칙은 '확인 후 신뢰 (verify-then-trust)'였습니다

워크플로 (workflow) 메모리의 함정은 명백합니다.

인터페이스 (interface)는 변합니다.

버튼의 위치가 바뀝니다.

과거의 단계들은 쓸모없게 됩니다.

그래서 저는 "완벽한 재생 (perfect replay)"을 원하지 않았습니다.

저는 다음과 것에 더 가까운 것을 원했습니다:

이전의 최선이었던 절차를 회상함
-> 먼저 시도함
-> 각 중요한 단계를 확인(verify)함
...

그것이 깨지기 쉬운 자동화 (brittle automation)와 유용한 운영 메모리 (operational memory) 사이의 차이점이 되었습니다.

기억된 워크플로는 판단을 대체하는 것이 아니라, 탐색 (exploration) 과정을 아껴주어야 합니다.

이것은 두 번째 문제도 해결했습니다: 사용자 규칙이 노이즈 속에서 계속 사라지던 문제

런타임 세션 (runtime session)에 전혀 속하지 않는 또 다른 종류의 "메모리"가 있습니다.

다음과 같은 것들입니다:

• 항상 중국어로 답변할 것
• 답변을 간결하게 유지할 것
• 운영 데이터 (production data)를 건드리지 말 것
• 이 프로젝트는 이 테스트 환경을 사용함

이것들은 단순한 후속 컨텍스트 (context)가 아닙니다.

이것들은 고정된 운영 규칙 (standing operating rules)입니다.

이것들을 일반적인 대화 기록으로부터 분리하자, 어시스턴트는 훨씬 더 예측 가능해졌습니다.

모델은 더 이상 작업 중간에 동일한 사용자 선호도를 다시 발견할 필요가 없었습니다. 그것으로부터 바로 시작할 수 있었습니다.

사소하게 들릴지 모르지만, 이는 많은 마찰 (friction)을 줄여줍니다.

진짜 개선 사항은 재발견 (re-discovery) 과정을 건너뛰는 것이었습니다

이 변화가 중요했다는 가장 좋은 신호는 메모리 레이어 (memory layer)가 우아해 보였다는 점이 아니었습니다.

반복되는 작업이 짧아졌다는 점이었습니다.

어시스턴트가 매번 빈 전술 모델 (tactical model)로 시작하지 않아도 되었기 때문에 더 빠르게 움직일 수 있었습니다.

다음과 같은 방식 대신에:

• 다시 조사하기 (inspect again)
• 다시 추측하기 (guess again)
• 다시 시도하기 (retry again)
• 동일한 막다른 길을 재발견하기 (rediscover the same dead end)

이제는 이렇게 할 수 있었습니다:

• 가장 잘 알려진 경로를 회상하기 (recall the best-known path)
• 이를 검증하기 (verify it)
• 거기서부터 계속하기 (continue from there)

이는 데스크톱 스타일의 워크플로우 (workflows)와 비데스크톱 작업 모두에 더 나은 루프 (loop)입니다.

그리고 하나의 긴 세션 (session)이 실제 메모리 (memory)를 대신할 수 있는 것처럼 가장하는 것보다 더 잘 확장 (scale)됩니다.

내가 유지할 규칙

만약 당신이 코딩 에이전트 (coding agent)를 구축하고 있다면, "스레드 (thread)가 여전히 연결되어 있다"는 것과 "시스템이 유용한 무언가를 학습했다"는 것을 혼동하지 마세요.

세션 (session)은 연속성 (continuity)을 돕습니다.

메모리 (memory)는 반복되는 작업을 돕습니다.

이것들은 서로 다른 레이어 (layers)입니다.

세션은 대화를 계속 유지해야 합니다.

메모리 레이어는 유용한 교훈을 계속 유지해야 합니다.

이 두 가지를 분리하자, CliGate는 매우 긴 버퍼 (buffer)를 가진 채팅 시스템이라기보다, 작업이 어떻게 수행되는지를 실제로 학습할 수 있는 어시스턴트에 더 가깝게 느껴지기 시작했습니다.

만약 당신이 에이전트 워크플로우 (agent workflows)를 구축하고 있다면, 당신의 시스템은 스레드를 기억하고 있습니까, 아니면 성공적인 절차 (procedure)를 기억하고 있습니까?