ゆるコンピュータ科学ラジオ(Yuru Computer Science Radio)를 매주 즐겁게 듣고 있습니다. 조금 전의 「개인 정보를 보호하는 시대는 끝났습니다.」라는 회차에서, AI에게 무언가를 부탁할 때 자신의 정보를 어디까지 전달할 것인가에 대한 이야기를 하고 있었습니다. 들으면서 '확실히 나도 매번 여러 가지를 전달하고 있구나'라고 생각한 것이 계기가 되었습니다.

그래서 AI에게 단발적으로 상담하는 것이 아니라, 자신의 문맥(Context)을 Markdown과 git에 저장해 두고, 매번 동일한 전제 조건에서 작업하도록 합니다. 이를 위한 workspace 템플릿을 만들었습니다.

이 기사에서 쓰는 내용은 그 템플릿이 무엇을 관리하고 있으며, 어떻게 사용을 시작하는가에 대한 것입니다.

모델의 성능 비교나 RAG, 벡터 DB(Vector DB)에 대한 이야기는 하지 않겠습니다. 하고 있는 일은 심플합니다. AGENTS.md를 두고, context/에 기억을 두며, minutes/에 작업 로그를 남기는 것, 그뿐입니다. 검증한 것은 Codex와 Claude(Claude Code)이며, 이 두 가지에 동일한 AGENTS.md를 읽게 하여 작동시켰습니다. 그 외의 에이전트(Agent)로는 테스트하지 않았습니다.

왜 만들었는가

실제로 사용해 보니 가장 번거로운 것은 매번 처음부터 설명해야 한다는 점이었습니다. 내가 누구인지, 지금 무엇을 진행하고 있는지, 어떤 문체를 선호하는지, 과거에 어떤 판단을 내렸는지. "전에도 말했잖아"라고 생각하며 채팅창에 다시 쓰는 것은 지속하기 어렵습니다. 그렇다고 전부 거대한 프롬프트(Prompt)에 붙여넣으면, 내용이 오래되거나 길어지고, 어디에 무엇을 썼는지 알 수 없게 됩니다.

그래서 채팅이 아니라 repo(Repository)를 만들기로 했습니다. AI에게 기억을 갖게 한다기보다, AI가 매번 읽을 작업 공간을 마련한다는 발상입니다.

ChatGPT나 Claude의 메모리 기능으로는 안 되는가

안 되는 것은 아닙니다. 채팅 내에서 취향이나 전제를 기억하게 하는 것뿐이라면 빌트인(Built-in) 메모리 기능이 더 간편합니다.

다만, 제가 AI에게 부탁하는 작업은 채팅 안에서 완결되지 않는 것이 많습니다. PC 조작, 간단한 스크립트(Script), 단발적인 HTML. 작업도 결과물도 파일의 세계에서 일어나기 때문에, 기억도 같은 장소에 두는 것이 자연스러웠습니다.

그 상태에서 repo에 두면, 원하던 세 가지를 모두 갖출 수 있습니다.

• 벤더(Vendor)를 넘나들 수 있다. Codex에서도 Claude Code에서도 동일한 AGENTS.md와 context/를 읽고 작동한다.
• 내용을 볼 수 있다. 무엇을 기억하고 있는지가 Markdown으로 읽히고, git diff로 리뷰할 수 있으며, 잘못된 기억은 스스로 수정할 수 있다.
• 경계를 스스로 결정할 수 있다. 무엇을 전달하고 무엇을 전달하지 않을지를 미리 결정하고, 나중에 감사(Audit)도 할 수 있다.

요컨대, 기억을 '기능'이 아니라 '파일'로서 소유하고 싶었다는 이야기입니다.

만든 것

템플릿은 3개 층(Layer)으로 나뉘어 있습니다.

Rules layer AGENTS.md / CLAUDE.md 어떻게 행동할 것인가
Memory layer context/ 다음 이후에도 사용할 기억
Log layer minutes/ generated/ 작업 로그·생성물

중심이 되는 파일은 다음과 같습니다.

기본 방침: 기억과 로그를 분리하기

AI는 다음 흐름으로 작동합니다.

• 세션 시작 시 AGENTS.md를 읽는다
• context/INDEX.md를 읽는다
• 의뢰와 관계된 context/만 추가로 읽는다
• 작업한다
• 작업 기록을 minutes/에 남긴다
• 다음 이후에도 사용할 사실만 context/에 증류(Distill)한다

핵심은 3번의 "관련 있는 것만 읽는다"입니다. 처음에는 전부 읽게 하면 된다고 생각했습니다. context/가 작을 때는 실제로 그렇게 작동합니다. 하지만 규모가 커질수록 파탄이 났습니다. 그래서 INDEX.md를 입구로 삼아, 의뢰와 관련된 것만 읽게 하는 형식을 취하고 있습니다.

context/에는 본문을 가득 채우지 않습니다. 회의 메모 전문이나 작업 로그 전문은 minutes/에 두고, context/에 두는 것은 다음 이후에도 사용할 판단·취향·결정·안건의 상태로만 제한합니다. 기억과 로그를 분리하는 것이 이 메커니즘의 핵심입니다.

데이터 경계

개인의 문맥(Context)을 repo에 넣기 때문에, 데이터 경계를 먼저 정합니다. 템플릿에서는 3단계로 나누고 있습니다.

템플릿 본체는 public으로 설정되어 있지만, 여기서 만드는 개인 workspace는 private을 권장합니다. 판단 기준은 "private repo에 맡겨도 되는가"입니다. 망설여진다면 넣지 마세요. 이 부분은 템플릿 측에도 강하게 명시해 두었습니다.

저의 운용 방식에서도 업무 정보는 이 workspace에 일절 넣지 않습니다. 여기에 있는 것은 개인의 문맥뿐입니다. 업무에서 다루는 정보에는 소속 기관의 규칙이 있으며, 그것은 개인의 repo로 가져올 문제가 아닙니다.

시작하는 방법

추천하는 방법은 GitHub의 템플릿 기능입니다.

• shown-it/ai-delegation-workspace-template를 연다
• Use this template → Create a new repository
• repo 이름을 정하고, Private으로 만든다
• clone 한다

로컬에서 복제하여 시작하는 경우에는 템플릿 측의 git 이력을 제거한 뒤 초기화합니다.

git clone https://github.com/shown-it/ai-delegation-workspace-template.git my-ai-workspace
cd my-ai-workspace
rm -rf .git
...

GitHub에 빈 repo를 만들고, remote를 추가하여 push 합니다.

git remote add origin https://github.com/<YOUR_ACCOUNT>/<YOUR_REPO>.git
git push -u origin main

첫 실행

첫 실행 시에는 AI에게 이 repo를 열게 하고, 다음과 같이 인사합니다.

안녕하세요

그것만으로도 작동하도록 설계되어 있습니다. context/profile.md가 미초기화 상태이거나 minutes/가 비어 있을 때, AGENTS.md의 Bootstrap이 발화합니다. AI는 prompts/init-profile.md를 읽고, 짧은 인터뷰를 거쳐 다음을 초기화합니다.

• context/profile.md
• AGENTS.md의 <USER_NAME> / <REPO_NAME> / <REMOTE_URL> / <PRIMARY_LANGUAGE>

repo 이름이나 remote URL은 git에서 가져올 수 있는 것을 자동으로 추측하며, 가져올 수 없는 것만 질문하는 구조입니다.

정기 운용

사용하기 시작하면 minutes/가 늘어납니다. 로그이므로 계속 늘어나도 상관없지만, 거기서 기억을 추출하는 것을 잊어버리면 단순한 로그에 불과하게 됩니다. 추출(Pick up)을 위한 prompt도 포함되어 있습니다.

GitHub Actions는 초기 상태에서는 수동 실행만 가능하도록 설정했습니다. 갑자기 cron을 활성화하지는 않습니다. 1주일 정도 수동으로 사용하며, context/feedback.md

가 잘 형성되는지, 혹은 minutes/에서 context/로 잘 증류 (distillation)할 수 있는지를 지켜본 뒤, 정기 실행으로 전환할 계획입니다.

사용하며 느낀 점

가장 효과적이었던 것은 모델을 바꿔도 문맥이 레포지토리 (repo)에 남는다는 점이었습니다. Codex로 작업하든 Claude로 작업하든, 혹은 다른 단말기에서 열더라도 우선 동일한 AGENTS.md와 context/를 읽습니다. 모델마다 장단점은 있지만, 적어도 "나는 어떤 사람이고, 이 repo에서는 무엇을 지킬 것인가"라는 입구는 통일됩니다.

또 다른 점은 수정 사항이 남는다는 것입니다. 출력 결과에 대해 "그 방식은 틀렸다", "다음부터는 이렇게 해달라"라고 말했을 때, 그 자리에서 끝내지 않고 context/feedback.md에 이유와 적용 방법까지 기록합니다. 동일한 실수가 발생했을 때, 이쪽에서 바로잡을 수 있는 지점이 생겼습니다.

만들면서 의외였던 점은 데이터 경계 (data boundary)의 효용성입니다. AI에게 정보를 더 많이 전달할수록 경계가 방해가 될 것이라고 생각했습니다. 하지만 반대였습니다. 경계를 먼저 결정해 두는 편이, 안심하고 전달할 수 있는 정보가 늘어납니다.

주의사항

마법 같은 기억 시스템은 아닙니다. context/에 무엇이든 넣으면 금방 읽을 수 없는 기억이 되어버리고, minutes/에 남겨두기만 하고 증류 (distillation)하지 않으면 다음번에 사용되지 않습니다.

개인정보나 생활 정보를 다룰 수 있게 할수록, repo는 프라이빗 (private)을 전제로 하게 됩니다. secrets, 업무 기밀, 제3자의 민감한 정보는 넣지 마세요. 망설여진다면 넣지 마십시오. AI에게 전달하는 정보를 늘리는 것과 경계를 없애는 것은 별개의 문제입니다.

그리고 개인의 문맥을 어디까지 GitHub에 맡길지는 자기 책임입니다. private repo라 하더라도 유출 리스크가 제로가 되지는 않습니다. 템플릿이 제공하는 것은 경계를 결정하기 위한 메커니즘까지이며, 무엇을 맡길지에 대한 판단을 대신해 줄 수는 없습니다.

요약

제가 만든 것은 AI에게 매번 컨텍스트 (context)를 전달하기 위한 workspace 템플릿입니다.

내용물은 대부분 마크다운 (Markdown)이며, AGENTS.md, context/, minutes/, prompts/가 전부입니다. 매번 처음부터 설명하는 것을 그만두고 싶은 사람에게는, 이 정도의 작업 공간이 딱 적당했다는 이야기였습니다.

개인정보를 보호하는 시대가 끝났는지 아닌지는 아직 알 수 없습니다. 다만, 경계를 결정한 뒤에 전달한다는 저만의 답은 내릴 수 있었습니다. 우선 repo를 만들고, 안녕하세요라고 입력하는 것부터 시작해 보세요.

Discussion