팀으로 AI와 일하며 채팅 대신 맥락 저장소를 공유한 기록

AI랑 일하다 보면 매일 아침 같은 장면이 반복된다. 새 창을 열고, 프로젝트가 뭔지, 우리가 뭘 하기로 했는지, 지난주에 뭘 뒤엎었는지를 처음부터 다시 설명한다. AI는 어제 나눈 대화를 기억하지 못하고, 팀원 다섯이 각자 자기 창에서 각자 브리핑하니 다섯 개의 조금씩 다른 프로젝트가 굴러간다.

이번 JB 해커톤에서 팀으로 AI를 쓰면서 이게 제일 거슬렸다. 그래서 도구를 하나 더 붙이는 대신, AI가 우리와 같은 곳을 읽고 쓰게 만드는 쪽으로 방향을 잡았다. 결론부터 말하면, 우리는 AI에게 채팅창이 아니라 맥락 저장소를 줬다.

모든 맥락을 한곳에 쌓는 맥락 저장소

AI와 같이 작업을 할때 근본 문제는 맥락이 휘발된다는 것이다. 사람들끼리 나눈 좋은 판단도, 어렵게 합의한 정의를 아무리 카카오톡 대화창에서 나눠도 그 내용은 사람들끼리만 알고 AI는 알지 못한다. 그래서 AI에게 명령을 내려도 AI는 다시 처음부터 작업을 시작한다.

또 이런 정보는 카카오톡, Slack, Discord, Notion 등등 여러 군데에 걸쳐 흩어져 있다.

그래서 우리는 팀의 맥락을 한 군데에 문서로 쌓기로 했다. Obsidian 볼트 하나를 만들고, 그 볼트를 통째로 GitHub 저장소를 사용해 버전을 관리했다. 회의록, 결정, 리서치, 작업 로그가 코드처럼 커밋 히스토리를 갖게 됐다.

굳이 GitHub를 쓴 이유는 단순하다. 파일을 인터넷 위에 올려두는 곳이기 때문이다. 각자 노트북 폴더에만 있으면 서로의 최신본을 볼 수 없지만, 원격 저장소에 올려두면 팀원 누구든, 각자의 AI든, 어디서든 같은 최신 맥락을 내려받아 읽을 수 있다. "공유"라는 말이 실제로 성립하려면 파일이 한 사람의 로컬이 아니라 모두가 닿을 수 있는 곳에 있어야 했고, GitHub가 그 자리를 맡았다.

여기서 핵심은 이 깃허브 맥락 저장소를 사람만 보는 곳으로 두지 않았다는 것이다. AI도 같은 폴더를 읽고, 같은 폴더에 결과를 쓴다. 사람과 AI가 같은 맥락 위에서 움직이는 순간, "AI에게 상황/맥락 설명하기"라는 귀찮은 일이 사라졌고 동시에 팀은 최고의 팀원을 영입한 효과를 주었다.

폴더 구조가 곧 공용어였다

맥락 저장소는 번호를 붙인 폴더로 나눴다. 실제 폴더는 이렇게 생겼다.

team-vault/
├─ _system/          # AI·사람이 가장 먼저 읽는 기준 (공통 규칙·현재 상태 요약·결정 로그·팀 구성)
├─ 00 Inbox/         # 아직 정리 안 된 원본 (회의 전사·인터뷰·슬랙/카톡 로그)
├─ 00 Project Hub/   # 저장소 전체 지도 — 어느 폴더에 뭐가 있는지 한 장으로
├─ 01 Meetings/      # 회의록
├─ 02 Decisions/     # 결정만 따로
├─ 03 Research/      # 리서치
├─ 04 Worklogs/      # 작업 로그
├─ 05 Tasks/         # 할 일
├─ 06 Team/          # 팀원별 담당 + AI 프롬프트
├─ 07 Outputs/       # 실제 산출물
├─ 90 Archive/       # 지난 것
└─ 99 Templates/     # 회의록·결정·노트 양식

번호와 이름을 붙인 건 사람이 헤매지 않게 하려는 목적도 있었지만, 더 큰 이유는 AI에게 "이건 어디서 찾고 어디에 쓴다"를 고정된 주소로 알려주기 위해서였다. AI에게 "리서치 정리해줘"라고 하면 03 Research에 쓰면 되고, "지금까지 정해진 게 뭐야"라고 물으면 02 Decisions만 읽으면 된다.

이 구조가 없으면 AI는 맥락을 잡으려고 볼트 전체를 훑어야 한다. 파일이 수백 개가 되면 그건 느리고, 정작 중요한 걸 놓치기도 쉽다. 그래서 우리는 폴더 안까지 들어가지 않고, 가장 바깥에 있는 파일 몇 개만 읽어도 지금 상황이 잡히게 만들었다.

저장소 맨 바깥에 세 가지를 뒀다. 저장소 전체 지도(00 Project Hub), 지금 상태 요약과 결정 로그(_system), 그리고 커밋 히스토리다. 이 세 곳만 늘 최신으로 유지하면, AI는 폴더를 하나하나 열거나 파일 속을 뒤지지 않고 이 바깥 문서 몇 장만 읽고도 "지금 우리가 어디까지 왔는지"를 잡는다. 반대로 오래된 논의의 근거를 캐거나 깊은 추론이 필요할 때만 전체 폴더와 파일 속으로 들어갔다. 평소엔 바깥 몇 장, 필요할 때만 안쪽 — 이게 맥락을 빠르게 잡는 핵심이었다.

이걸 실제로 가능하게 한 장치는 두 개였다. 하나는 공통 규칙에 **"평소 작업은 이 바깥 문서 몇 개만 읽고 시작하고, 볼트 전체를 훑지 말라"**고 명시한 것이다. 그래서 AI는 요청을 받으면 수백 개 파일을 스캔하는 대신 늘 이 진입 문서부터 열었다. 다른 하나는 AI가 작업을 끝낼 때마다 이 바깥 문서(현재 상태 요약·결정 로그)를 스스로 갱신하게 한 것이다. 진입 문서가 항상 최신이니, 다음 작업은 안쪽을 뒤지지 않고 그 몇 장만 읽어도 맥락이 맞았다. 요약을 미리, 그리고 계속 바깥에 만들어 두는 것 — 그게 "안 뒤지고도 아는" 구조의 전부였다.

특히 결정을 따로 모은 게 컸다. 회의 중에 "이렇게 가기로 했다"가 나오면 그건 작업 로그가 아니라 결정으로 남겼다. 그래야 사람도 AI도 "논의 중인 것"과 "이미 정해진 것"을 헷갈리지 않는다. AI가 이미 엎어진 방향을 다시 제안하는 사고를, 폴더를 나누는 것만으로 꽤 줄일 수 있었다.

여러 군데로 흩어진 대화를 깃허브에 모았다

팀에서 작업하는 진행 과정을 AI한테 전달하는 진짜 문제는 대화를 한 군데서 하지 않는 것 이었다. 결정은 카카오톡에서 나오고, 리서치 링크는 슬랙에 던져지고, Discord에 남긴 메모도 있고, Google Drive에다가 ppt나 pdf, 워드 파일들을 올린다. 또 정작 제일 중요한 합의는 회의에서 오직 말로만 오갔다. 프로젝트를 진행하기에도 벅찬데 이 맥락 조각들을 사람이 일일이 기록, 정리하려고 하면 너무나 귀찮은 작업이라 시작할 엄두를 못낸다.

그래서 들어오는 쪽을 자동화했다. 어디서 나온 대화든, 링크든, 회의 전사든 일단 00 Inbox에 원본 그대로 던진다. 그러면 AI가 그걸 읽어서 정리된 마크다운 노트로 바꿔 준다. 카톡 대화 덩어리 하나를 붙여넣으면 제목이 붙고 핵심이 추려진 한 장의 노트로 떨어지고, 링크 하나를 던지면 요약된 리서치 노트가 됐다.

PDF·PPT·워드 같은 문서형 원본은 그대로는 AI가 읽기 나쁘다. 이건 마이크로소프트가 만든 MarkItDown으로 먼저 마크다운 텍스트로 뽑아낸 다음 요약했다. 발표자료 한 장, 공식 보고서 PDF 한 편도 00 Inbox에 넣으면 읽을 수 있는 텍스트 노트가 되니까, "이 파일 열어서 정리해줘"라고 사람이 붙잡고 있을 일이 없었다.

변환한 마크다운만 남기고 원본을 버리진 않았다. PPT·PDF·워드 같은 원본 파일과 회의 녹음·전사 원본도 저장소 안에 그대로 뒀다. 정리된 .md는 AI가 읽는 요약본이고, 그 옆에 원본을 함께 보관해 "실제 발표자료 그대로"가 필요할 때 바로 꺼내 썼다. 요약본과 원본이 같은 버전 관리 안에 함께 있으니, 정리본과 진짜 원본 사이를 오갈 때 파일을 찾아 헤맬 일이 없었다. 다만 발표자료처럼 큰 파일은 GitHub 용량 제한(파일당 100MB) 때문에 Git LFS를 쓰거나, 원본은 Drive에 두고 노트엔 링크만 남기는 게 낫다.

여기서 한 걸음 더 갔다. Obsidian처럼 노트를 만들 때 관련된 다른 노트를 [[ ]] 링크로 엮게 했다. 새로 들어온 리서치가 지난주 결정과 닿아 있으면 그 결정 노트로 링크가 걸리고, 같은 주제의 회의록끼리도 서로를 가리켰다. 덕분에 Obsidian에서 열면 노트들이 그래프처럼 이어져 있고, VS Code에서 폴더를 봐도 주제별로 파일이 알아서 자리를 잡은 상태였다.

핵심은 사람이 "정리"라는 일을 따로 하지 않았다는 것이다. 대화가 오간 곳에서 원본만 저장소로 옮기면, 마크다운 변환도 분류도 링크도 AI가 뒤에서 처리했다. 흩어져 있던 몇 군데의 대화가 하나의 읽을 수 있는 맥락으로 수렴하는 데, 사람이 들인 노력은 "붙여넣기" 정도였다.

AI가 가장 먼저 읽는 공통 규칙을 뒀다

가장 효과가 컸던 건 AI를 위한 규칙을 저장소 안에 파일로 박아둔 것이다.

나는 AGENTS.md라는 파일을 저장소 맨 위에 뒀다. 모든 팀원의 AI가 작업을 시작하기 전에 가장 먼저 읽는 공통 규칙이다. 제품 정의, 절대 바꾸면 안 되는 것, 용어의 정확한 의미, 하면 안 되는 표현, 그리고 "어디서 읽고 어디에 쓰는지"까지 여기 못박아 뒀다.

여기에 우선순위까지 명시했다.

사람이 내린 직접 지시 > 이 공통 규칙 > AI 기본 동작

이 한 줄이 생각보다 중요했다. AI가 그럴듯하게 지어내거나 프로젝트 정의를 슬쩍 바꾸려 할 때, 개별 팀원의 즉흥 지시보다 이 규칙이 위에 있으니 방향이 흔들리지 않았다. 그리고 사람의 직접 지시가 규칙보다 위에 있으니, 필요할 땐 사람이 언제든 덮어쓸 수 있었다.

채팅이었으면 이 규칙을 매번 프롬프트에 다시 붙여야 했을 것이다. 하지만 규칙이 저장소 안 파일로 존재하니, AI는 그냥 그 파일을 읽는 것으로 매번 같은 기준에서 출발했다.

사람마다 AI 프롬프트를 따로 뒀다

팀원이 다섯이면 각자 맡은 게 다르다. 그래서 공통 규칙인 AGENTS.md와는 별도로, 사람마다 자기 몫의 AI 명령 프롬프트를 각자 파일로 뒀다 — 06 Team 폴더 안에 팀원 이름별로 하나씩. 공통 규칙 하나에 모두의 지시를 욱여넣은 게 아니라, 각자가 실제로 자기 AI에게 건네는 명령이 사람 수만큼 따로 있었던 것이다. 각 프롬프트는 맨 먼저 공통 규칙(AGENTS.md)을 읽게 한 다음, 그 사람의 담당 업무와 맥락을 얹는 구조였다.

이렇게 하니 다섯 명의 AI가 서로 다른 일을 하면서도 같은 프로젝트 위에 있었다. 나는 내 담당에 집중하는 AI를 쓰고, 옆 사람은 자기 담당 AI를 쓰지만, 둘 다 같은 규칙과 같은 저장소를 공유했다. 다섯 개의 조금씩 다른 프로젝트가 되는 문제가 여기서 풀렸다.

프롬프트가 파일이라는 점도 좋았다. 누가 자기 AI를 어떻게 세팅했는지 서로 볼 수 있고, 더 나은 지시 방식을 발견하면 그 파일을 고쳐서 커밋하면 팀 전체가 개선을 공유했다.

Git이 사람과 AI의 공유 기억이 됐다

깃허브로 맥락을 관리하니 얻은 게 하나 더 있다. 바로 맥락에 히스토리가 생겼다는 점이다.

누가 언제 어떤 결정을 고쳤는지, 어제와 오늘의 정의가 어떻게 달라졌는지가 그냥 커밋 히스토리로 남았다. 사람에게도 유용했지만 AI에게 특히 그랬다. "최근에 뭐가 바뀌었어?"에 대한 답이 채팅 기억이 아니라 파일 변경 이력이라는 사실 위에 있었다.

귀찮은 노트 쪽 동기화는 Obsidian Git 플러그인이 대신 처리했다. 켜두면 알아서 원격을 당겨오고, 편집하면 자동으로 커밋·동기화가 걸렸다. 디자이너든 기획자든 노트를 쓰기만 하면 최신 상태가 공유됐고, 아무도 커밋 명령을 외울 필요가 없었다. 공유 맥락이 항상 살아 있게 유지되는 마찰을 여기서 거의 없앴다.

산출물 쪽에서 자동 동기화만으로 부족한 순간 — 지금 뭘 올리는지 눈으로 확인하거나 변경을 직접 묶어야 할 때 — 에는 GitHub Desktop이 Git을 덜 무섭게 만들어줬다. Git을 깊게 모르는 팀원도 무엇이 바뀌었는지 보면서 커밋할 수 있었다.

커밋 메시지도 AI가 형식을 맞췄다

히스토리가 쌓여도 커밋 메시지가 제각각이면 나중에 아무것도 못 찾는다. 0608_재용4, 업로드, 수정 같은 메시지만 줄줄이 남으면 "그때 뭘 바꿨더라"를 되짚을 수가 없다.

그래서 커밋 메시지 형식도 공통 규칙(AGENTS.md)에 못박아 뒀다. feat:(새 문서·기능), docs:(문서 수정), meeting:(회의록), research:(리서치), fix:(오류 수정), vault:(자동 백업) — 앞에 종류를 붙이고 한 줄로 요약하는 식이다.

핵심은 이 형식을 사람이 외우지 않아도 됐다는 것이다. AI가 AGENTS.md를 먼저 읽으니, "커밋해줘"라고만 하면 AI가 방금 바뀐 내용을 보고 알아서 meeting: 6/6 결정사항 정리처럼 형식에 맞는 메시지를 붙였다. 규칙을 파일에 한 번 박아두는 것만으로, 다섯 명이 각자 커밋해도 히스토리가 한 사람이 쓴 것처럼 일관되게 남았다.

물어보면, 맥락 저장소가 답했다

이렇게 맥락이 쌓이니 재밌는 게 가능해졌다. 팀원이 궁금한 걸 그냥 물어보면 AI가 저장소를 읽고 바로 답했다.

• "이번 주에 바뀐 결정 뭐 있어?" → 02 Decisions의 최근 변경을 짚어 정리해 줬다.
• "우리 제품 정의가 지금 뭐지?" → 공통 규칙을 읽고 한 줄로 답했다.
• "이 기능 왜 이렇게 하기로 했더라?" → 관련 결정 노트와 회의록을 이어서 근거까지 짚어 줬다.

중요한 건 이 답이 AI의 기억이나 추측이 아니라 맥락 저장소에 실제로 적힌 것 위에 있었다는 점이다. 새로 합류한 팀원이든 어제 회의를 놓친 사람이든, 물어보기만 하면 팀의 현재 상태를 즉시 따라잡았다. "이건 누구한테 물어봐야 하지"가 "그냥 물어보면 된다"로 바뀌었다.

물론 저장소가 비어 있으면 이것도 안 된다. 답의 품질은 결국 우리가 맥락을 얼마나 성실히 쌓았는지에 달렸다. 그래서 아래 흐름이 계속 돌아야 했다.

사람이 쓰고, AI가 읽고, 다시 쌓였다

도구를 각각 잘 쓰는 게 핵심이 아니었다. 사람과 AI가 하나의 흐름 안에서 도는 게 핵심이었다.

1. 사람이 회의·결정·맥락을 저장소에 쓴다.
2. AI가 공통 규칙과 해당 폴더를 읽고, 그 맥락 위에서 작업한다.
3. AI의 산출물이 다시 저장소의 정해진 자리에 쌓인다.
4. 변경이 커밋으로 남아 팀 전체가 같은 최신 상태를 본다.
5. 사람이 그걸 검토하고, 다음 결정을 다시 저장소에 쓴다.

이 순환이 돌기 시작하면 AI가 매번 처음 보는 외부인이 아니라, 프로젝트를 이미 아는 팀원처럼 움직인다. "상황 설명 → 요청"이 아니라 그냥 "요청"부터 시작할 수 있다는 게 팀 속도에서 꽤 큰 차이였다.

다음에도 이 구조를 쓸 것 같다

거창한 시스템은 아니다. 볼트 하나, 저장소 하나, 규칙 문서 몇 개다. 하지만 이 단순한 구조가 두 가지를 동시에 해결했다. 팀원끼리 맥락을 잃지 않게 했고, 동시에 AI를 팀의 맥락 안으로 끌어들였다.

앞으로 팀으로 AI와 일한다면 이 조합은 계속 쓸 것 같다. 다음에는 공통 규칙을 더 짧게, 정말 지켜야 할 것만 남기고 싶다. 규칙이 길어지면 사람도 AI도 안 읽는다.

배운 건 하나였다. AI와 잘 소통하는 팀은 프롬프트를 잘 쓰는 팀이 아니라, AI가 읽을 수 있는 공유 맥락을 만드는 팀이었다. 채팅은 닫으면 사라지지만, 맥락 저장소는 남아서 다음 사람과 다음 AI를 기다린다.