우리는 AI 에이전트 8체로 구성된 '조직'을 6개월 이상 운용하고 있습니다. 각 에이전트에는 역할(총괄, 품질 관리, 콘텐츠 제작, SNS 운영, 디자인 등)이 있으며, Discord 상에서 인간 오너 1명과 협업하며 블로그, SNS, Web 서비스 운영을 매일 수행하고 있습니다. cron 작업은 약 80개이며, 일일 기사 공개나 배포(Deploy)는 기본적으로 에이전트가 실행합니다.

이 기사는 기술 해설이라기보다 관찰 기록입니다. AI 에이전트에게 장기 기억을 부여하기 전과 후로 조직이 어떻게 변했는지, 그 과정에서 발생한 사고, 작동한 메커니즘과 작동하지 않은 메커니즘을 가능한 한 솔직하게 작성하겠습니다.

기억의 구현 자체(Markdown 파일 기반의 스토어, MCP 서버화)는 이전 두 번의 기사에 작성했으므로, 이번에는 '도입하면 어떤 일이 일어나는가'에 집중하겠습니다.

도입 전의 상태부터 말씀드리면, 세션이 끊길 때마다 에이전트는 모든 것을 잊어버립니다. 이는 개인 이용이라면 '조금 불편하다' 정도로 끝나지만, 조직 운영에서는 치명적이었습니다.

• 같은 지적을 반복함. "배포 후에는 운영 URL을 실측한 뒤 완료 보고를 해줘"라고 지난주에 말했는데, 이번 주에도 검증되지 않은 채 "완료했습니다"라고 보고가 들어옴
• 과거의 결정이 증발함. "이 기능은 A안으로 가기로 결정했다"가 사라지고, 다른 세션에서 B안이 재제안됨
• 실패가 자산이 되지 않음. 어떤 에이전트가 빠진 함정을 다음 주에 다른 에이전트가 그대로 빠짐

인간 조직으로 치면, 전원이 매일 아침 기억상실 상태로 출근하는 회사와 같습니다. 아무리 우수해도 조직으로서 성립되지 않습니다. 문서를 쓰면 된다는 이야기도 아닙니다. '쓴 문서를 읽는' 것 자체도 기억에 의존하기 때문입니다.

장기 기억(특히 '피드백 기억' = 오너의 수정 지시를 1건당 1개의 파일로 영속화하는 메커니즘)을 도입하고 처음 체감한 변화는 의외였습니다. 사과가 줄어들고, 재발 방지가 늘어난 것입니다.

도입 전 에이전트의 실패 대응은 "죄송합니다, 앞으로 주의하겠습니다"였습니다. 그리고 앞으로 주의하지 않습니다. 잊어버리기 때문입니다.

도입 후에는 실패할 때마다 다음과 같은 파일이 남습니다.

---
name: deploy-verify-live-url
description: 「배포 완료」는 운영 URL 실측 후에만 보고할 것
...

포인트는 이것이 다음 세션 시작 시 자동으로 주입된다는 점입니다. '주의하겠다'는 정신론이 아니라, 다음 입력 컨텍스트(Context)의 일부가 됩니다. 동일한 계통의 실패 재발이 눈에 띄게 줄었습니다. 체감상 수정 지시의 대부분이 '새로운 지적'이 되었고, "전에도 말했잖아"라는 상황이 거의 사라졌습니다.

이는 인간 조직의 포스트모템(Post-mortem) 문화와 같은 구조이지만, AI는 인간보다 더 철저히 할 수 있는 이점이 있습니다. 기억의 주입을 강제할 수 있기 때문입니다. 인간은 재발 방지 문서를 읽기 넘길 수 있지만, 에이전트의 컨텍스트 주입은 건너뛸 수 없습니다.

운용을 계속하다 보니 기억의 저장 장소가 자연스럽게 두 층으로 나뉘었습니다.

workspace-shared/ # 조직의 기억: 규칙, 결정 사항, 각종 정본(Source of truth)
workspace-<agent>/ # 개인의 기억: 담당 업무의 지견, 작업 상태

중요했던 것은 정본(Source of truth)의 명시입니다. 동일한 정보가 여러 곳에 적혀 있으면 에이전트는 오래된 것을 가져옵니다. 우리는 "마스터는 이 파일이다. 모순될 경우 이쪽을 우선한다"라는 선언을 기억 측에 적는 운용 방식을 택했습니다. 인간 조직에서 문서의 소유권(Ownership)을 결정하는 것과 완전히 동일합니다.

또 하나 흥미로웠던 점은, 에이전트 간의 인수인계가 기억을 통해 이루어지게 된 것입니다. 담당자 교체(모델 교체나 역할 변경) 시, 인수인계서를 작성하게 하여 새로운 담당자의 기억 디렉토리에 둡니다. 새로운 담당자는 첫 세션에서 그것을 읽고 업무를 계속합니다. "AI는 교체되어도 기억은 조직에 남는다"는 상태가 되면, 특정 모델이나 도구에 대한 락인(Lock-in) 현상이 체감상 옅어집니다.

예상하지 못했던 응용은, 기억을 승인 플로우(Approval Flow)의 실체로 만드는 방식입니다.

우리 조직에서는 기사 공개나 배포 전에 품질 관리 담당(QC 담당 에이전트)의 리뷰를 필수화하고 있습니다. 당초 이는 Discord 상의 "QC 통과했습니다"라는 보고 기반으로 운용했으나, 보고와 실행이 분리되어 있어 리뷰되지 않은 채 공개가 진행되는 허점이 있었습니다.

현재는 QC 담당이 승인 시 승인 파일을 공유 디렉토리에 쓰고, 공개 스크립트는 해당 파일의 존재와 내용을 검증한 후에야 공개할 수 있도록 설계되어 있습니다.

def has_qc_approval(slug: str, channel: str) -> bool:
    """QC 담당의 승인 파일이 없으면 공개하지 않는다"""
    file = APPROVAL_DIR / f"{slug}.{channel}.approved.json"
    ...

{
"slug": "example-article",
"qc_pass": true,
...
}

「승인」이라는 조직적인 합의가 대화 로그 속이 아니라 **기계적으로 검증 가능한 파일 (machine-verifiable file)**로서 존재합니다. 이것 또한 기억의 한 형태입니다. 리뷰의 흔적이 남고, 승인 위조가 어려우며, 복구 후에도 승인 상태를 재현할 수 있다는 등 장점이 많아, 외부 공개 관련 플로우는 모두 이 방식으로 통일했습니다.

도입 후 몇 달이 지나 되돌아보니, 인간 오너(Owner)의 일하는 방식이 변해 있었습니다.

도입 전, 오너의 시간 대부분은 동일한 지시를 재발행하는 데 사용되었습니다. 도입 후, 개별 지시는 줄어든 대신 그 자리를 채운 것이 "어떤 기억을 확정(confirm)할 것인가", "어떤 방침을 폐지할 것인가"와 같은 기억에 대한 편집 판단입니다.

이는 권한 설계에서도 나타납니다. 우리의 운용 방식에서는 에이전트가 작성한 기억은 가설(draft)로서 입력되며, 확정(confirmed) 상태로 승격되기 위해서는 본인 이외의 확인이 필요합니다. 즉, 일상적인 운용에서 인간이 다루는 것은 개별 태스크가 아니라, 조직이 무엇을 믿고 움직일 것인가에 대한 정의입니다. 에이전트에 대한 지시서(시스템 프롬프트에 해당하는 규범 파일) 또한 실패할 때마다 인간과 에이전트가 공동으로 개정합니다.

「AI에게 일을 맡긴다」라고 하면 작업의 위임이 떠오르지만, 실제로 일어난 일은 판단 기준의 언어화가 강제되는 것이었습니다. 인간이 암묵적으로 수행하던 판단은 기억으로서 명문화하지 않으면 에이전트에게 인계되지 않습니다. 6개월 치의 기억 디렉토리는 결과적으로 이 조직의 의사결정 기준을 담은 스냅샷이 되었습니다. 이는 부수적인 효과로, 새로운 에이전트(또는 인간 멤버)의 온보딩(onboarding) 자료로서도 기능하고 있습니다.

좋은 점만 있는 것은 아닙니다. 6개월 동안 발생한 기억 관련 사고들은 모두 인간 조직에서 발생하는 고전적인 사고와 유형이 같았습니다.

사고 1: 백업의 silent failure (15일간 지속)

기억 디렉토리의 원격 백업이 용량 초과로 인해 15일 동안 계속 실패하고 있었습니다. 실패 알림이 없었기에 아무도 알아채지 못했고, 서버 복구 작업 중에 일일 자동화 스크립트 3개와 며칠 분의 기억이 소실되었습니다. "백업은 성공하고 있다는 전제"라는, 인간의 인프라 운용에서 수백 번이나 반복되었던 사고를 그대로 답습했습니다.

대책도 고전적인 방식 그대로입니다. 백업 실패를 알림으로 보낼 것. 복구 절차를 훈련이 아닌 실전에서 검증할 것.

사고 2: 사라진 코드의 "열화 복원"

사고 1의 복구 시점에 사라진 스크립트를 재구현했는데, 완성된 결과물은 이전보다 명백히 품질이 떨어져 있었습니다. 나중에 알게 된 사실이지만, 원래의 사양은 기억에 남아 있었습니다. 복구 작업을 수행한 에이전트가 그것을 읽지 않고 추측만으로 재구현한 것입니다.

"기억은 있는데 읽히지 않는다"는 도입 후기의 가장 큰 테마였습니다. 문서가 잘 갖춰진 인간 회사에서도 아무도 읽지 않는, 바로 그 문제입니다. 대책은 문화가 아니라 프로세스에 심는 것이었습니다. "복구 및 재구현 전에 해당 기억을 반드시 검색한다"라는 절차 자체를 최우선 피드백 기억으로 주입하는 것입니다. 메타적이지만, 이것이 가장 효과적이었습니다.

사고 3: 되돌아간 장부와 이중 실행

복구 과정에서 스테이트 파일(state file)이 이전 상태로 되돌아갔고, 이미 공개된 기사를 "미공개"로 판정한 cron이 동일한 기사의 공개를 3일 동안 계속 재시도했습니다. 외부 조작 기록(무엇을 공개했는가)은 기억이 아니라 회계 기록이어야 하므로, append-only 방식의 장부에 증적 URL과 함께 분리하는 설계로 변경했습니다.

나열해 보면 알 수 있듯이, 이 중 어느 것도 AI 고유의 사고는 아닙니다. AI 에이전트 조직의 신뢰성 문제는 결국 인간 조직에서 이미 검증된 관행(알림, 정본 관리, 장부, 포스트모템(post-mortem))을 재적용하는 것으로 귀결된다는 점이 6개월간의 가장 큰 배움일지도 모릅니다.

솔직하게, 도입했지만 기능하지 않았던 것도 기록해 둡니다.

"중요한 것은 기억해 둬"라는 지시. 무엇이 중요한지 판단하는 것은 AI에게 어렵기 때문에, 모든 것을 저장하다가 기억이 쓰레기장처럼 변해버렸습니다. 효과가 있었던 것은 "저장하지 않을 조건"을 명문화하는 것이었습니다(일시적인 대화, 코드를 보면 알 수 있는 내용, 이 대화에서만 의미를 갖는 내용은 저장 금지).

정기적인 기억의 재고 조사. "월 1회 기억을 정리한다"는 인간과 마찬가지로 실현되지 않는 미래였습니다. 실제로 기능했던 것은 기록 시의 기계적 제약(1줄 요약 200자 상한, 1파일 1사실)과 오류 발견 시 즉시 deprecated(사용 중단) 처리하는 방식이었습니다.

삭제를 통한 정리. 오래된 기억을 삭제했더니, "왜 그 방침을 그만두었는지"를 알 수 없게 되어, 폐지된 방침이 다시 제안되는 역류 현상이 발생했습니다. 현재는 삭제를 금지하고 모두 아카이브(Archive)로 옮깁니다. 기억은 결론뿐만 아니라 경위(Context) 자체가 자산입니다.

정량적인 면도 적어둡니다. 규모감을 참고해 주세요.

• 에이전트 8체, cron 약 80개, 운용 기간 6개월 이상
• 기억 저장소(Memory Store)의 실체는 Markdown 파일군 + git. 스토리지 비용은 실질적으로 제로
• 1 세션당 기억 주입은 수천~1만 토큰 정도. prompt caching(기억 블록에 캐시 경계를 두는 방식)으로 런닝 코스트(Running Cost)는 거의 흡수할 수 있습니다. 오히려 캐시 TTL(5분)을 모른 채 기동 간격을 설계했던 시기의 비용이 더 높았습니다.
• 가장 큰 비용은 토큰이 아니라 **설계의 재작업(Rework)**이었습니다. "일단 대화 로그를 전부 저장하자"로 시작했던 초기 구현은 결국 거의 전부 버렸습니다. 처음부터 "증류된(Distilled) 상태를 가진다"는 방침으로 설계했다면 1개월은 단축할 수 있었을 것입니다.

6개월간의 관찰을 한 줄로 요약하면, 기억은 AI를 똑똑하게 만드는 기능이 아니라, 조직을 성립시키는 인프라였습니다.

앞으로 시도할 분들에게는 이 순서를 추천합니다.

• 피드백 기억부터 시작하기. 오너(Owner)의 수정 지시를 1건당 1파일로 남기고, 매 세션 주입한다. 구현이 가장 가볍고 효과를 가장 체감하기 쉽다 ("전에도 말했잖아"가 사라진다).
• 외부 조작의 대장(Ledger). 공개·배포(Deploy)를 맡기려면 필수다. 중복 실행은 대외적인 실질적 피해로 이어진다.
• 기억의 상태 관리(가설/확정/폐지). 에이전트가 여러 개가 되고 서로의 기억을 참조하기 시작하는 타이밍에 필요해진다. 벡터 DB(Vector DB)나 고도화된 검색은 마지막에 해도 좋다. 수백 건까지는 grep으로도 문제없었다.

그리고 무엇보다, 기억의 사고 대책은 인간 조직의 프랙티스(Practice)에서 수입할 것. 백업 알림, 정본 관리, 대장, 포스트모템(Post-mortem). AI 에이전트 운용은 새로운 분야처럼 보이지만, 신뢰성의 근간은 놀라울 정도로 검증된(Mature) 기술들로 이루어져 있습니다.