여러 AI에게 「공유 메모리」를 부여하고 싶어질 때, 그 끝에서 마주치는 문제

Claude Code, OpenAI Codex, GitHub Copilot과 같은 AI coding agent를 병렬로 실행하면 곧 하나의 벽에 부딪힙니다. 각 agent의 context는 분리되어 있어, 서로가 지금 무엇을 하고 있는지 알지 못합니다. Agent A는 자신의 branch만 보고, Agent B도 자신의 branch만 봅니다.

여기서 자연스럽게 떠오르는 발상이 「공유 메모리 (shared memory)」입니다. 공유 메모 파일에 작업 상황을 적습니다. 혹은 DB에 "PR-12는 인증 관련 부분을 수정 중이다", "PR-18은 PR-12에 의존하고 있다", "이 작업은 이미 완료되었다"와 같은 **의미 (meaning)**를 저장하여 모두가 참조할 수 있도록 합니다.

이 발상은 올바른 문제를 포착하고 있습니다. 부족한 것은 각 AI의 지능이 아니라, **공유 컨텍스트 (shared context)**입니다 (이 상류 단계의 이야기는 '여러 AI에게 부족한 것은 지능이 아니라 공유 컨텍스트였다'로 나누어 다룹니다).

하지만 공유 컨텍스트를 「저장 (save)」으로 유지하려 하면 부패합니다. 이 글은 왜 부패하는지, 그리고 저장이 아닌 **재도출 (re-derive)**이라는 선택지가 있음을 다룹니다. 텍스트 메모가 부패하는 이유부터 시작하여, DB에 구조화하여 저장해도 부패하는 이유, 그리고 「남겨도 좋은 것」과 「남기면 부패하는 것」의 경계까지 다룹니다.

text memory가 부패하는 이유 — 작성하는 순간부터 뒤처지게 된다

먼저 가장 소박한 형태인 텍스트 메모부터 살펴보겠습니다.

공유 메모에 "orders/pricing.py는 Agent A가 만지고 있으니 건드리지 마세요"라고 적었다고 가정해 봅시다. 이 문장은 작성한 순간에는 맞습니다. 문제는 작성한 이후에 세상이 움직인다는 점입니다.

• Agent A의 PR이 먼저 merge되었다. 이제 더 이상 "만지고 있는 중"이 아니다.
• Agent A의 PR이 close되었다. 그 주의 사항은 이제 무의미하다.
• main이 진행되어, pricing.py의 내용 자체가 다른 것으로 바뀌었다.
• Agent A가 작업 범위를 변경하여, 실제로 만지고 있는 것은 다른 파일이 되었다.

코드, PR, main은 계속 움직이지만, 텍스트에 기록된 상태는 작성 시점에 고정되어 뒤처지게 됩니다. 읽는 쪽에서는 그 문장이 지금도 유효한지 텍스트만으로는 판단할 수 없습니다. 오래된 주의 사항은 없는 것보다 더 나쁩니다. 사람도 agent도 "아직 유효할 것"이라고 오독하기 때문입니다.

이는 텍스트가 부실해서 발생하는 것이 아닙니다. 「현재의 상태」를 정적인 문장으로 저장한 시점에서, 업데이트의 책임만이 공중에 붕 뜨게 된다는 구조적인 문제입니다.

인간의 인수인계와 AI의 인수인계는 속도가 다르다

인간 사이의 느린 인수인계라면 다소 오래된 메모라도 파탄 나지 않을 수 있습니다. 인간은 메모만을 근거로 몇 분 만에 repository 전체를 새로 쓰는 일은 통상적으로 하지 않습니다. 코드를 열고, 화면을 보고, 모르면 물어보며, 제한된 범위를 조금씩 진행합니다. 메모는 현재의 진실 그 자체라기보다, 상황을 재확인하기 위한 단서로 사용됩니다.

AI coding agent는 좋든 나쁘든 다릅니다.

• session 초반에 읽은 메모를 이후 판단의 전제로 사용한다.
• 그 전제를 바탕으로 짧은 시간 안에 많은 파일, test, document를 변경한다.
• 동일한 전제를 반복해서 참조하며 다음 판단을 연쇄시킨다.
• session이 계속되는 동안에도 다른 agent의 push나 merge로 인해 repository의 상태는 움직인다.

첫 메모에 작은 오해가 있다면, 그 오해는 한 번의 판단으로 끝나지 않습니다. 동일한 session 안에서 잘못된 전제를 사용한 변경 사항이 쌓여갑니다. 게다가 읽기 시작한 시점에는 맞았던 메모라도, 다른 agent가 push한 후에는 낡은 것이 되어 AI의 local context와 GitHub의 current state가 조금씩 멀어지게 됩니다.

AI가 인간보다 부주의해서 문제가 되는 것이 아닙니다. 빠르고 많은 작업을 진행할 수 있다는 사실 자체가 오래된 context의 영향을 증폭시킵니다. 인간용 인수인계 메모를 그대로 고속 agent의 authority(권한/근거)로 삼으면, 노후화에 따른 비용이 달라집니다.

따라서 필요한 것은 더 길고 상세한 메모가 아닙니다. 작업 시작 전, push 후, merge 전, 그리고 관련 PR이 움직였을 때, 현재의 GitHub 상태를 다시 읽어올 수 있는 메커니즘입니다. 모든 것을 매 초마다 상시 감시할 필요는 없습니다. 상태가 변하는 분기점에서 open PR, current head, main, 그리고 관련된 변경 사항을 재확인할 수 있으면 충분합니다.

메모는 과거의 설명으로서 남겨둘 수 있습니다. 하지만 AI가 다음 작업을 진행하는 근거는 메모에 적힌 현재가 아니라, **현재의 상태로부터 다시 만들어진 context (문맥)**여야 합니다.

DB에 「의미」를 저장해도, 같은 이유로 부패한다

"텍스트가 모호한 게 문제라면, 구조화해서 DB에 넣자"라고 생각하기 쉽습니다. 자유 문장이 아니라, 기계 판독 가능한 레코드(record)로 저장하는 것입니다.

하지만 저장하는 내용이 현재의 의미·현재의 관계인 한, 부패하는 방식은 달라지지 않습니다. 다음과 같은 레코드를 가정해 봅시다.

PR-12는 인증을 변경하고 있다

PR-18은 PR-12에 의존하고 있다

이 작업은 완료됨

이 설명은 지금도 유효함

이 모든 것은 저장한 시점의 GitHub 상태를 전제로 한 **해석 (interpretation)**입니다. 전제가 움직이면 레코드는 조용히 낡아갑니다.

• head SHA가 움직임: PR-12에 새로운 commit이 쌓여, 인증 관련 부분은 더 이상 건드리지 않고 있을지도 모릅니다.
• main이 진행됨: 의존의 토대였던 부분이 다른 PR에 의해 이미 교체되었을지도 모릅니다.
• 관련 PR이 증감함: PR-18이 참조하던 대상이 close되어, 의존 관계 자체가 사라졌을지도 모릅니다.
• 관련 구조가 변함: 어떤 PR이 어디서 겹치는지는 open PR의 집합과 각각의 head에 의해 결정됩니다. 집합이 변하면 겹침의 지도도 변합니다.

즉, 저장된 레코드는 "어떤 SHA·어떤 시점의 스냅샷 (snapshot)"일 뿐, "지금의 정답"이 아닙니다. 그것을 "지금의 정답"으로 다시 읽어들이는 순간, 오래된 해석을 현재로 취급하는 사고가 발생합니다.

structured data (구조화된 데이터)라도, 오래된 해석은 오래된 것이다

이 부분은 혼동하기 쉬우므로 구분하겠습니다. "구조화되어 있는가"와 "오래되지 않았는가"는 별개의 축입니다.

깔끔하게 정규화(normalization)된 레코드라 할지라도, 그것이 나타내는 것이 판단·관계·상태라면 전제가 움직이는 순간 낡아버립니다. 스키마(schema)가 깔끔하다는 것이 내용이 최신임을 보장하지는 않습니다.

• 사실은 부패하지 않습니다. "2026-07-20에 SHA abc123을 보고 이 판단을 내렸다"는 언제 읽어도 참입니다. 과거의 기록이기 때문입니다.
• 해석은 부패합니다. "이 PR은 지금 인증을 바꾸고 있다"는 현재형 주장입니다. 현재가 움직이면 거짓이 됩니다.

저장에 적합한 것은 전자(과거의 사실)이며, 후자(현재의 해석)를 저장했다가 다시 읽어오는 것은 부패를 심는 것과 같습니다.

선긋기 — 남겨도 되는 것 / 남기면 부패하는 것

그렇다면 무엇을 저장하고, 무엇을 저장해서는 안 되는가. 이 글의 핵심은 바로 이것입니다. 저는 이 선긋기를 스키마 설계의 좋고 나쁨이 아니라, "그것이 과거의 사실인가, 현재의 해석인가"라는 단 하나의 기준으로 긋습니다.

왼쪽은 움직이지 않는 과거입니다. 무엇이 일어났는지, 어떤 SHA를 보았는지, 사람이 언제 무엇을 결정했는지. 이것들은 기록이므로 언제 읽어도 참입니다. 따라서 안심하고 영속화(persistence)할 수 있습니다.

오른쪽은 움직이는 현재입니다. 관계, 도착 순서, 상태, 권장 사항. 이것들은 "현재의 GitHub 상태"에 대한 해석이며, 저장된 행을 "지금의 정답"으로 다시 읽어오면 부패합니다. 그러므로 저장하지 않고, 필요할 때마다 다시 만듭니다.

Veripsa Core는 이 선긋기에 따라 동작합니다. 현재의 verdict(지금 이 PR은 어떤 상황인가)를 저장된 행에서 다시 읽어오지 않습니다. 이벤트가 올 때마다 그 시점의 GitHub 상태 — open PR의 집합, 각각의 head, 변경 파일, label, check — 에 대해 현재의 관계를 **재계산 (re-calculation)**하여 내놓습니다. 남기는 것은 오른쪽이 아니라 왼쪽, 즉 이력과 사실뿐입니다.

재도출이기에 성립하는 것

"저장된 현재를 다시 읽지 않고, 그때마다 다시 만든다"를 선택하면, 부패에 대해 다음과 같은 점들이 자연스럽게 성립합니다.

• exact SHA에 대한 고정: 판단은 반드시 특정 commit에 묶입니다. "이 PR은 괜찮다"가 아니라 "SHA abc123...

시점에서, "이 비교 대상에 대해 이렇게 판단했다"가 됩니다. head가 움직인다면, 그것은 별개의 질문이 됩니다.

• invalidation (무효화)가 자동으로 발생: 오래된 판단을 명시적으로 지우며 다닐 필요가 없습니다. 다음 이벤트에서 현재 상태로부터 다시 만들기 때문에, 전제가 바뀐 판단은 참조되지 않은 채 교체됩니다. 뒤처진 메모가 남지 않는 구조입니다.

• ACK가 오래된 결합에 남지 않음: ACK (acknowledge to proceed)는, 사람이 그 시점의 경고 스냅샷을 보고, 그럼에도 불구하고 진행하기로 결정했다는 기록입니다. code review (코드 리뷰)의 승인도, conflict (충돌)의 해소도, 영구적인 mute (음소거)도 아닙니다. Veripsa가 본 결합의 스냅샷 — 상대방의 PR과 겹치는 파일 — 이 바뀌면, 이전의 ACK는 현재 상태로 자동 계승되지 않으며, 필요하다면 다시 pause (일시 중지)하여 재확인을 촉구합니다. ACK 자체는 "누가·언제·무엇에 대해"의 이력(왼쪽 열)으로 남지만, "이 PR은 앞으로 계속 OK"라는 현재형 권한으로는 저장되지 않습니다.

• Unknown은 Clear가 아님: 판단을 다시 만드는 설계에서는, "지금은 확인하지 못했다"를 편의상 Clear (문제 없음)로 몰아갈 필요가 없습니다. 근거가 부족한 면은 Unknown으로 두어, "이곳은 침묵이 아니라 확인되지 않은 상태이다"라고 보이게 합니다. 저장된 오래된 "괜찮음"을 초록색 체크 표시 아래에 온존하는 식의 부패를 일으키지 않습니다.

원칙: Persistent history. Disposable context.

지금까지의 내용을 한 줄로 요약하면 다음과 같습니다.

Persistent history. Disposable context.

이력은 남긴다. 판단은 다시 만든다.

과거에 무엇이 일어났는가 (history)는 지우지 않고 남길 가치가 있는 사실입니다. 지금 무엇을 의미하는가 (context)는 일회용으로 취급하여, 현재 상태로부터 매번 다시 도출합니다. 이 두 가지를 섞어서 "현재의 의미"를 영속화하는 순간, 공유 메모리는 부패하기 시작합니다.

저장이 잘못된 것이 아닙니다. 저장해야 할 대상을 착각하는 것이 부패의 원인입니다. 사실과 이력은 남깁니다. 현재의 관계·도착 순서·권장 사항·자유 문장 설명은 저장 대상이 아니라, 재도출의 대상입니다.

1인 + 다수 AI 환경에서 이것이 어떻게 효과를 발휘하는가

이 설계는 대규모 팀만을 위한 이야기가 아닙니다. 여러 개의 coding agent (코딩 에이전트)를 동시에 구동하는 한 명의 개발자에게도, 가치가 발생하는 지점은 바로 여기입니다. 병렬로 분리된 context (컨텍스트)가 여러 개 존재한다는 것 자체가 조건이며, 인원수는 관계없습니다.

각 agent의 context는 분리된 상태여도 상관없습니다. Veripsa는 각각의 agent에게 영구 기억을 부여하거나, agent의 session (세션)에 상황을 멋대로 주입하지 않습니다. 대신, 모두가 이미 공유하고 있는 측면 — GitHub의 pull request (PR) — 위에, 그 시점에 유효한 관계를 매번 계산하여 올려둡니다. 사람도 agent도 그것을 PR 상에서 읽습니다 (agent라면 gh pr checks <PR 번호>나 gh pr view <PR 번호> --comments로 읽을 수 있습니다).

따라서 특정 agent의 메모가 오래되더라도, 다른 agent가 읽는 공유 측면은 오래되지 않습니다. 공유 측면은 저장된 누군가의 기억이 아니라, 지금의 GitHub 상태로부터 다시 만들어진 관계이기 때문입니다. 일회성 분석이 아니라, PR 생성·push·merge·close·ACK·head 업데이트에 맞춰 계속해서 업데이트된다는 점도 같은 이유입니다. 두 개의 PR을 단 한 번 비교하는 것이 아니라, 상태가 움직일 때마다 다시 만듭니다.

이것은 "agent memory platform"이 아니다

만약을 위해 카테고리를 혼동하지 않도록 하겠습니다. "저장이 아닌 재도출"이라는 말을 들으면, Veripsa가 **AI의 기억 기반 (memory platform)**처럼 보일 수 있지만, 그렇지 않습니다.

Veripsa Core의 카테고리는 일관되게 pre-merge PR traffic control (머지 전 PR 트래픽 제어)입니다. agent에게 기억을 갖게 하는 플랫폼도, AI code reviewer (AI 코드 리뷰어)도, 자동으로 merge (머지)하는 도구도 아닙니다. "저장하지 않는다 / 재도출한다"는 그 traffic control을 부패하지 않게 만들기 위한 설계 방침이지, 제품 카테고리를 확장하는 이야기가 아닙니다.

Veripsa Core 자체의 개요는 'Veripsa Core란 무엇인가?'라는 GitHub에서 늘어나는 AI의 PR을 merge 전에 확인하는 GitHub App에 관한 내용으로 나누어져 있습니다. 이 글에서는 "왜 저장(save)이 아니라 재도출(re-derivation)인가"에 초점을 맞춥니다.

재도출이 traffic control에 어떻게 연결되는가

마지막으로, 이 설계가 PR 위에 나타나는 구체적인 결과물로 어떻게 이어지는지 연결하겠습니다.

Veripsa가 유지하고 있는 것은 공유 coordination context (공유 조정 컨텍스트) — 지금 이 순간, 다른 in-flight(진행 중인) 변경 사항들이 어디로 향하고 있는지, 왜 현재의 PR과 관계가 있는지, merge 전에 다음에 어떻게 움직여야 하는지에 대한 공유 상태입니다. 흔히 말하는 traffic control(대기 / rebase / 착지 순서)은 이 공유 컨텍스트로부터 **도출되는 action (액션)**입니다.

그 action이 항상 최신 상태이려면, 바탕이 되는 공유 컨텍스트가 오래되어서는 안 됩니다. 그렇기에 저장된 현재를 다시 읽어오는 것이 아니라, 이벤트마다 현재 상태로부터 다시 만듭니다. 착지 순서 제안도, 기다려야 할 대상도, 상류 의존성(upstream dependency)이 지금 막 움직이고 있다는 경고도, 모두 "현재의 open PR과 head"로부터 재계산된 관계입니다. head SHA가 움직이면 조언도 다시 만들어집니다.

또한, content-free(콘텐츠 프리)하다는 것 — source file body나 diff body를 저장·표시하지 않고, signal(시그널) 계산에 필요한 구조를 처리 시에 일시적으로 취득한 뒤, 영구 저장이나 코멘트에 붙여넣기를 하지 않고 처리 후에 폐기하는 것 — 은 private repository에 도입하기 위한 **신뢰 경계 (trust boundary)**입니다. 이 글의 주제인 "재도출"과는 별개의 축이며, "본문을 전혀 읽지 않는다"는 의미도 아닙니다. 저장하는 것은 PR traffic control에 필요한 최소한의 운영 메타데이터(왼쪽 열)뿐입니다.

Veripsa Core는 advisory by default(기본적으로 권고 사항)입니다. 무엇을 block(차단)할지는 repository 측에서 Veripsa check를 branch protection / rulesets의 required check(필수 체크)로 설정하느냐에 따라 결정됩니다. 우선 하나의 selected repository에서 branch protection을 변경하지 않고 signal을 관찰한 뒤, 운영에 적합하다고 판단되면 required check로 승격할 수 있습니다.

요약

• 여러 AI의 "공유 메모리"를 저장 방식으로 유지하려 하면 부패한다. 텍스트로 저장하든, DB에 구조화하든, 저장하고 있는 것이 현재의 의미라면 head SHA / main / 관련 PR / 관련 구조가 움직이는 순간 데이터는 낡은 것이 된다.

• 인간의 느린 인수인계에서는 메모가 재확인을 위한 단서로 쓰일 수 있지만, 고속으로 동작하는 AI에서는 메모가 session(세션) 전체의 전제가 되기 쉬워 작은 오해가 동일한 session 내에서 연쇄적으로 증폭될 수 있다.

• AI에게 필요한 것은 더 긴 메모가 아니라, 작업 시작 전·push 후·merge 전과 같이 상황이 변할 때 current GitHub state(현재 GitHub 상태)를 다시 읽어올 수 있는 메커니즘이다.

• structured data(구조화된 데이터)라 할지라도, 그것이 나타내는 것이 판단·관계·상태라면 오래된 해석은 낡은 것이다. 깔끔한 스키마(schema)가 최신성을 보장하지는 않는다.

• 구분 기준은 "과거의 사실인가, 현재의 해석인가"이다. event · exact SHA · human decision(인간의 결정) · 운영 메타데이터는 남긴다. 현재의 관계 · 착지 순서 · 권장 사항 · 자유 문장 설명은 다시 만든다.

• 재도출 방식이기 때문에, exact SHA에 대한 고정, 자동적인 invalidation(무효화), ACK가 오래된 head에 남지 않는 것, Unknown을 Clear로 몰아붙이지 않는 것이 자연스럽게 성립된다.

• 원칙은 Persistent history. Disposable context. (이력은 남기고, 판단은 다시 만든다.)

• 이것은 agent memory platform이 아니라, pre-merge PR traffic control이 부패하지 않도록 하기 위한 설계 방침이다.

• 설치: https://veripsa.com/go/install?source=zenn:why-shared-memory-rots

• 메커니즘 (설치~merge): https://veripsa.com/ja/how-it-works

Discussion