채팅을 데이터베이스로 쓰지 마라: 파일시스템을 AI 에이전트의 기억으로

AI 에이전트에게 짧은 질문 하나를 시키면 잘 한다. 그런데 같은 에이전트에게 "이 주제를 30개 사이트에서 조사해서 출처까지 붙여 정리해줘" 같은 긴 작업을 시키거나, 어제 하던 작업을 오늘 이어서 시키면 자주 무너진다. 중간에 했던 결정을 잊고, 출처를 흐리고, 똑같은 조사를 다시 하고, 어디까지 했는지 자기도 모른다.

원인은 모델이 멍청해서가 아니다. 대화 기록(채팅)에 모든 상태를 담으려 하기 때문이다. 이 글은 그 실패가 왜 반복되는지, 그리고 대화 대신 파일시스템을 작업의 공유 상태로 쓰면 무엇이 달라지는지를 정리한 노트다. 특정 도구나 모델 이야기가 아니라, 파일을 읽고 쓸 수 있는 에이전트라면 어디에나 적용되는 운영 패턴에 가깝다.

에이전트 워크플로우는 지루하고 반복적인 이유로 망가진다

긴 에이전트 작업이 깨지는 자리는 매번 비슷하다. 화려한 실패가 아니라 지루하고 예측 가능한 실패다.

• 원자료 과적재 — 에이전트가 조사한 원문을 전부 자기 컨텍스트 창(한 번에 들고 있을 수 있는 작업 기억)에 끌어온다. 창이 차면 앞의 내용부터 밀려 사라진다.
• 재개 불가 — 세션이 리셋되거나 대화가 너무 길어져 압축되면, 그때까지의 작업 상태가 같이 증발한다. 다음 세션은 처음부터다.
• 출처와 주장의 혼재 — "무엇을 알아냈는가"와 "그걸 어디서 봤는가"가 한 덩어리로 섞인다. 나중에 어느 문장이 검증된 사실이고 어느 문장이 모델이 지어낸 것인지 가릴 수 없다.
• 병렬 중복 — 여러 에이전트를 동시에 돌리면, 서로 무엇을 이미 찾았는지 모른 채 같은 사이트를 또 뒤진다.
• 벤더 종속 — 프로젝트 지식이 특정 회사의 숨은 메모리 시스템 안에 갇힌다. 도구를 바꾸면 기억이 따라오지 못한다.

이 다섯 가지는 모두 같은 뿌리에서 나온다. 대화 기록을 작업의 데이터베이스처럼 쓰고 있다는 것. 대화는 휘발성이고, 용량이 한정돼 있고, 검색이 안 되고, 한 벤더 안에 갇혀 있다. 데이터베이스가 가져야 할 성질을 하나도 갖추지 못했다.

해결의 한 줄: 파일시스템을 공유 상태로 삼아라

전환은 한 문장으로 요약된다. 파일시스템을 공유 상태(shared state)로 쓰고, 모델은 일꾼(worker)으로 쓰며, 대화 기록을 데이터베이스로 쓰지 마라.

구체적으로는 이렇게 흐른다.

1. 지휘하는 에이전트(orchestrator)는 전체 자료를 자기 안에 담지 않는다. 일을 쪼개 나눠주고, 진행을 측정하고, 다음에 무엇을 할지 결정만 한다.
2. 일하는 에이전트(worker)는 한정된 입력만 읽고, 결과를 구조화된 파일로 쓴다. 긴 원문은 대화에 풀어놓는 게 아니라 파일에 남긴다.
3. 완료는 기억이 아니라 파일로 추적한다. 일이 끝나면 작은 완료 표식 파일을 남기고, 지휘자는 그 파일 개수를 세어 진행률을 안다.
4. 주장은 출처와 분리해 묶어 둔다. 어느 문장이 어느 출처에서 나왔는지 파일에 기록해, 위험한 주장은 쓰기 전에 감사할 수 있게 한다.
5. 작은 인덱스 파일이 다음 에이전트에게 "어디서부터 시작할지"를 알려준다.

핵심은 다음 에이전트가 대화를 처음부터 재생하지 않고 파일에서 곧장 이어받는다는 점이다. 세션이 끊겨도, 도구를 바꿔도, 어제 일을 오늘 이어도 — 상태는 디스크 위에 그대로 남아 있다.

이 전환을 떠받치는 네 가지 장치

말로만 "파일에 써라"라고 하면 금세 흐트러진다. 그래서 몇 가지 작은 규칙이 뼈대를 잡는다.

완료 표식 (done marker)

일하는 에이전트가 작업을 끝내면 done/001.yaml 같은 작은 파일을 하나 남긴다. 그 안에는 무슨 작업이었는지, 성공인지 실패인지, 어떤 파일을 만들었는지가 적힌다. 지휘자는 "무슨 일이 있었는지 기억"하는 게 아니라 이 표식 파일의 개수를 센다. 실패한 작업도 실패로 기록한다 — 빈자리를 남기지 않는 게 핵심이다.

주장 장부 (claim ledger)

에이전트가 뽑아낸 주장 하나하나를 그 출처에 묶어 기록하는 파일이다. "이 사실은 어디서 왔는가"가 항상 따라붙기 때문에, 공개 글이나 의사결정에 쓰기 전에 위험한 주장만 골라 검증할 수 있다. 근거가 없으면 모델의 기억으로 빈칸을 메우지 않고 UNKNOWN이라고 적는다. 이 한 줄 규칙이 할루시네이션(그럴듯하지만 근거 없는 생성)을 막는 마지막 방어선이다.

축 분할 (axis discovery)

조사 주제를 처음부터 한 덩어리로 던지면, 지휘자의 첫 추측이 곧 작업의 천장이 된다. 그래서 주제를 서로 독립적인 하위 축(axis)으로 먼저 쪼갠다. 그러면 여러 에이전트가 서로 겹치지 않고 동시에 일할 수 있고, 빠진 관점도 드러난다.

지휘자–일꾼 구조 (orchestrator–worker)

지휘자는 전체를 보되 원문을 읽지 않고, 일꾼은 좁은 범위를 깊게 파되 결과만 파일로 돌려준다. 일꾼이 지휘자에게 돌려주는 건 긴 원문이 아니라 "상태 / 만든 파일 경로 / 막힌 점 / 짧은 메모"뿐이다. 긴 자료는 대화가 아니라 파일에 남는다.

코드 프레임워크와 무엇이 다른가

여기서 자연스럽게 떠오르는 질문이 있다. LangChain, CrewAI, AutoGPT 같은 에이전트 프레임워크가 이미 있는데 뭐가 다른가?

그것들은 코드 프레임워크다. 라이브러리를 설치하고, 제어 흐름이 파이썬이나 자바스크립트 코드 안에 산다. 반면 여기서 말하는 건 **파일 규칙(protocol)**이다. 설치할 런타임도, 가져다 쓸 라이브러리도 없다. 계약은 디스크 위의 파일이고, 그 파일은 어떤 에이전트든 사람이든 읽고 쓸 수 있다.

그래서 벤더에 묶이지 않는다. 손으로 직접 돌려도 되고, 스크립트로 돌려도 되고, 에이전트에게 통째로 맡겨도 된다. 작업 도중에 모델 회사를 바꿔도 아무것도 다시 쓸 필요가 없다. 코드 프레임워크가 "어떻게 실행할지"를 고정한다면, 파일 규칙은 "무엇을 남길지"만 정하고 실행 방법은 열어 둔다.

언제 쓰고, 언제는 쓰지 않나

이 패턴은 만능이 아니다. 한 번의 프롬프트로 답이 나오는 일에는 과하다. 짧은 질문에 완료 표식 파일을 만들 이유는 없다.

쓰는 게 맞는 경우는 작업이 한 컨텍스트 창에 담기엔 너무 크거나, 한 세션보다 오래 사는 경우다.

• 출처 기반 조사 코퍼스를 만들 때
• 한 프로젝트를 여러 세션에 걸쳐 끌고 갈 때
• 여러 에이전트에게 일을 나눠 병렬로 돌릴 때
• 결과를 나중에 다시 재개하거나 감사(audit)할 수 있어야 할 때

기준은 단순하다. 작업이 한 번의 대화로 끝나지 않는다면, 그 상태를 대화 밖 파일에 두라는 것.

직접 굴려본 자리

이건 책상 위 이론만은 아니다. 지금 읽고 있는 이 블로그 자체가 파일 기반 프로젝트 기억(이 시리즈에서 다룰 seogo)으로 운영된다 — 진행 상태, 폐기한 접근, 세션 핸드오프가 전부 저장소 안 파일로 남아, 세션이 리셋돼도 다음 작업이 그 파일에서 이어진다.

이 글에서 설명한 패턴들은 한곳에 정리해 공개 저장소로 묶어 두었다. 네 가지 프로토콜(출처 기반 리서치, AI용 프로젝트 문서, 멀티모델 심의, 프로젝트 기억)이 들어 있고, 전부 설치할 것 없는 순수 파일 규칙이다.

저장소: github.com/aminpiano/agentic-workflows

정리

에이전트 워크플로우가 무너지는 이유는 대부분 지루하고 반복적이며, 뿌리는 하나다 — 대화 기록을 데이터베이스로 쓰는 것. 휘발성 대화 대신 파일시스템을 공유 상태로 삼고, 완료 표식으로 진행을 세고, 주장과 출처를 분리하고, 작업을 독립 축으로 쪼개면, 긴 작업과 여러 세션을 견디는 에이전트 워크플로우가 된다.

다음 글에서는 이 패턴을 "AI로 만든 프로젝트가 세션이 끊기면 왜 무너지는가"라는 더 구체적인 문제 — 비개발자에게 특히 절실한 프로젝트 연속성 — 에 적용해 본다.