AI를 진정한 팀 동료로 영입하는 방법

팀 프로젝트를 하면서 AI를 사용하다 보면 매일 같은 장면이 반복된다.

새로운 세션을 열고, 현재 진행하는 프로젝트가 뭔지, 팀이 뭘 하기로 했는지, 지난주에 뭘 뒤엎었는지를 처음부터 다시 설명한다. AI는 어제 나눈 대화를 기억하지 못하고, 팀원들은 각자의 AI 세션에서 각자 브리핑하니 다섯 개의 조금씩 다른 프로젝트가 굴러간다.

AI를 진정한 팀원으로 영입하려면 팀의 모든 실수와 결정 근거를 알려줘야 한다고 생각한다. 하지만 카카오톡, 디스코드, 슬랙, 노션, 오프라인 미팅에 흩어진 정보를 한곳에 모으는 일은 빠르게 목표를 향해 달려가야 하는 팀 프로젝트에서는 불가능하다.

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

이 과정을 누구나 자기 팀에 가져갈 수 있게, 실제로 쓴 구조를 일반화한 Context Hippo 템플릿도 공개했다. Obsidian 볼트로 열고, GitHub에서 Fork하거나 Use this template으로 새 프로젝트를 시작할 수 있다.

Context Hippo GitHub 주소: https://github.com/bluealmond33-debug/context-hippo

왜 Hippo인가? Context Hippo는 큰 입으로 흩어진 대화·회의·문서 조각을 받아들이고, 한 몸 안에서 다음 사람과 AI가 다시 읽을 수 있는 맥락으로 소화한다는 비유다. 모든 것을 자동으로 삼키는 도구라는 뜻은 아니다. 무엇을 공식 기록으로 남길지는 사람이 검토하고 결정한다.

Context Hippo는 따로 상상해서 만든 템플릿이 아니다. 이 해커톤에서 실제로 굴린 구조를 정리해, 다음 팀도 빈 상태에서 시작할 수 있게 떼어낸 것이다. 그래서 아래에는 템플릿의 기본 규칙과 함께, 당시 MIRI를 만들며 실제로 쌓인 파일도 같이 나온다.

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

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

또 이런 정보는 카카오톡, Slack, Discord, Notion, 오프라인 회의 등 여러 군데에 흩어져 있다.

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

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

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

옵시디언 폴더 구조가 곧 AI와의 소통 언어였다

맥락 저장소는 역할이 드러나는 폴더와 진입 문서로 나뉜다. 현재 Context Hippo 템플릿은 이렇게 시작한다.

context-hippo/
├─ Project Hub/HOME.md # 사람과 AI가 시작하는 대시보드
├─ AGENTS.md           # 공통 작업 규칙 + 킥오프 시작 게이트
├─ CLAUDE.md           # Claude Code용 진입점
├─ _system/            # 현재 상태·결정·팀·용어·운영 규칙
├─ 00 Inbox/           # 아직 정리하지 않은 원본과 접수 대장
├─ Project Hub/        # 저장소 지도·온보딩·팀 가이드
├─ 01 Meetings/        # 회의록
├─ 02 Decisions/       # 확정된 ADR/결정
├─ 03 Research/        # 조사와 문서의 Markdown 정리본
├─ 04 Worklogs/        # 개인 작업 기록
├─ 05 Tasks/           # 공식 할 일
├─ 06 Team/            # 팀원별 담당과 AI 프롬프트
├─ 07 Outputs/         # 기획서·데모·발표 등 산출물
├─ 90 Archive/         # 종료된 작업
└─ 99 Templates/       # 회의록·결정·리서치 양식

저장소의 진입점은 Project Hub/HOME.md다. 처음 들어온 사람이나 AI는 이 파일에서 프로젝트 목표·현재 우선순위·다음에 읽을 문서 지도를 잡는다. 이어서 AGENTS.md의 공통 규칙, _system/CURRENT_STATE.md의 최신 상태, _system/DECISION_LOG.md의 확정 결정을 읽는다.

Project Hub/에는 온보딩과 팀 가이드가, _system/에는 공식 운영 기준이 들어간다. 그래서 새 팀원은 작업 방법을 찾고, AI는 현재 상태와 확정된 판단부터 읽은 뒤에 필요한 근거로 들어간다.

그리고 _system/은 그냥 숨은 보관함이 아니다. 팀이 지금 같은 판단을 하게 만드는 운영 기준 폴더다. 실제 볼트에는 아래처럼 현재 상태, 결정, 팀 현황, 자료 처리 이력을 따로 둔다.

_system/
├─ CURRENT_STATE.md        # 지금 할 일·막힌 일·다음 행동을 한 화면에 요약
├─ DECISION_LOG.md         # 확정한 선택과 근거
├─ TEAM.md                 # 팀원 역할과 담당 범위
├─ WORKING_AGREEMENTS.md   # 회의·연락·결정 방식 같은 팀 규범
├─ KICKOFF_INTERVIEW.md    # 시작 시 AI가 팀장과 채우는 인터뷰
├─ UPLOAD_RULES.md         # 원본 보관과 Markdown 정리 규칙
├─ PROJECT_RULES.md        # 파일·브랜치 공통 규칙
├─ INTEGRATION_RULES.md    # 통합 책임자와 보호 경로 규칙
├─ GOVERNANCE.md           # 단독 작성자/팀 협업 모드와 검토 기준
└─ GLOSSARY.md             # 팀이 함께 쓰는 용어

이 중 CURRENT_STATE.md와 DECISION_LOG.md가 작업을 이어받는 공식 기준점이다. 그 밖의 문서는 누가 어떤 범위를 바꿀 수 있는지, 원본을 어떻게 남기는지, 팀이 어떤 합의로 움직이는지를 고정한다.

폴더 안의 README.md도 진입점이다

README.md는 모든 파일을 설명하는 장황한 문서가 아니라, 그 폴더를 처음 여는 사람과 AI가 역할·작성 규칙·다음 링크를 바로 잡는 짧은 안내판이다. 00 Inbox/, 01 Meetings/, 02 Decisions/, 04 Worklogs/, 07 Outputs/, 90 Archive/, 99 Templates/와 그 하위 폴더에 README를 둔다.

• 00 Inbox/README.md는 새 원본을 먼저 넣고, 분류가 끝나면 목적지 _raw/로 옮기는 흐름을 설명한다.
• 01 Meetings/README.md는 회의록 파일명과 “결정사항·할 일을 반드시 남긴다”는 규칙을 적는다.
• 02 Decisions/README.md는 결정 내용·근거·대안·나중에 다시 볼 조건을 기록하게 한다.
• 04 Worklogs/README.md는 오늘 한 일·막힌 것·다음 행동을 짧게 남기는 양식을 준다.
• 07 Outputs/README.md와 99 Templates/README.md는 최종 산출물의 기준과 복사해서 쓰는 문서 양식을 연결한다.

새로 들어온 사람은 Project Hub/HOME.md → AGENTS.md → _system/CURRENT_STATE.md → _system/DECISION_LOG.md 순서로 읽고, 그 다음에 요청과 직접 관련된 폴더로 들어간다. 이 순서가 있어야 AI도 볼트를 전부 훑지 않고 필요한 맥락부터 잡을 수 있다.

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

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

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

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

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

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

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

그래서 들어오는 자료는 한 곳에 모았다. 어디서 나온 대화든, 링크든, 회의 전사든 일단 00 Inbox에 원본 그대로 넣고, 사람 또는 AI가 이를 읽어 정리된 마크다운 노트로 소화한다. AI가 정리할 때도 자동 처리 서비스처럼 혼자 끝내는 것이 아니라, 분류·원본 이동·공식 상태 반영을 제안하고 브랜치 담당자의 확인 뒤에 push한다.

00 Inbox는 비우는 쓰레기통이 아니라 분류 대기열이었다. INTAKE_INDEX.md에 접수일·담당자·원본 경로·최종 이동 위치를 남기고, 분류할 때는 삭제가 아니라 git mv로 01~07 폴더에 옮겼다. 그래서 Inbox의 활성 목록은 비워질 수 있어도, 원본·정리본·Git 이력은 사라지지 않는다.

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

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

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

핵심은 사람이 원본을 모으고, 정리와 분류는 공통 규칙을 읽은 AI가 도울 수 있게 만든 데 있다. 다만 AI의 Markdown 변환·분류·링크 작업은 자동으로 확정되는 것이 아니라, 사람이 검토하고 승인할 수 있는 변경으로 남긴다. 그래야 흩어진 대화가 하나의 읽을 수 있는 맥락으로 수렴하면서도, 공식 맥락의 품질과 책임이 유지된다.

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

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

나는 AGENTS.md라는 파일을 저장소 맨 위에 뒀다. 모든 팀원의 AI 작업에 적용하는 공통 규칙이다. 이 파일 안에서 먼저 읽을 문서 순서, 원본 보관 방식, 기록 위치와 수정 권한을 정한다. 실제 파일은 아래처럼 짧다.

# AGENTS.md — 사람과 AI의 공통 규칙
 
## 반드시 먼저 읽을 것
1. `Project Hub/HOME.md`
2. `_system/CURRENT_STATE.md`
3. `_system/DECISION_LOG.md`
4. 요청과 직접 관련 있는 폴더의 문서
 
## 작업 규칙
- 확인되지 않은 사실·결정·수치를 지어내지 않는다. 모르면 `_system/CURRENT_STATE.md`의 미해결 항목 또는 질문으로 남긴다.
- PDF·PPT·Word·녹음 원본을 지우지 않는다. `_raw/`에 원본을 보관하고, 읽기 쉬운 Markdown 정리본을 같은 폴더에 둔다.
- 작업 전후에 자신의 작업 기록을 `04 Worklogs/`에 남긴다.
- 팀원 브랜치에서는 근거·초안·산출물만 다룬다. `_system/`, `02 Decisions/`, `05 Tasks/`, 최상위 안내 파일은 통합 책임자만 바꾼다.
- AI가 만든 글·코드·요약은 출처와 가정을 함께 적고 사람이 검토할 수 있게 둔다.
 
## 우선순위
사람의 직접 지시 > 이 파일의 공통 규칙 > AI 기본 동작

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

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

팀원마다 AI 프롬프트와 브랜치를 따로 뒀다

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

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

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

파일을 같이 편집한다고 해서 모두가 main을 직접 만지게 하지는 않았다. 팀원은 member/<이름>-<작업> 브랜치에서 자기 자료·회의록·리서치·산출물을 올리고 PR을 열었다. 공식 CURRENT_STATE.md, 결정 로그, 태스크와 규칙은 통합 책임자가 integrate/... 브랜치에서만 갱신했고, 최종 main 머지는 팀장이 검토·승인했다. AI에게도 같은 규칙을 읽게 했기 때문에, 누군가의 AI가 팀의 확정 상태를 근거 없이 덮어쓰는 일을 줄일 수 있었다.

PR이 머지된 뒤에도 개인 브랜치 이름을 버릴 필요는 없다. 작업이 완전히 끝났을 때만 그 브랜치를 main과 동기화해서 다음 작업의 깨끗한 출발점으로 재사용했다. 반대로 main보다 앞선 고유 커밋이 있거나 담당자가 확인하지 않은 브랜치는 자동 삭제하지 않았다. 감사 스크립트는 삭제 후보를 보여줄 뿐, 사람의 검토 없이 기록을 지우지 않게 만들었다.

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

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

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

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

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

이 규칙이 없으면 "오픈 PR은 없는데, 머지되지 않은 브랜치가 남아 있는" 상태가 생긴다. 그래서 브랜치마다 active, review, stale, cleanable, archived 상태를 나누고 정기 감사했다. main보다 고유 커밋이 0개인 브랜치만 정리 후보가 되고, 고유 문서·리서치·코드가 남은 브랜치는 담당자가 선별 반영하거나 보관할 때까지 검토 대상으로 남는다. 자동화가 사람의 결정을 대신하게 하지 않은 것이 핵심이다.

커밋 메시지 통일

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

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

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

맥락 저장소(세컨 브레인) 완성

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

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

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

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

핵심 요약

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

1. 사람이 회의·결정·맥락을 원본과 함께 저장소에 쓴다.
2. AI가 공통 규칙과 현재 상태를 먼저 읽고, 필요한 Markdown 근거를 찾아 작업한다.
3. AI의 산출물이 다시 저장소의 정해진 자리와 팀원 브랜치에 쌓인다.
4. 변경이 PR·커밋으로 남고, 통합 책임자와 팀장이 공식 상태를 검토한다.
5. 사람이 다음 결정을 저장소에 쓰면, 다음 사람과 다음 AI가 같은 최신 상태에서 시작한다.

실제로 함께 쓴 도구 화면

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

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

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

앞으로 팀으로 AI와 일한다면 이 조합은 계속 쓸 것 같다. 다음에는 공통 규칙을 더 짧게, 정말 지켜야 할 것만 남기고 싶다. 규칙이 길어지면 사람도 AI도 안 읽는다. 처음부터 만들 필요는 없다. Context Hippo을 Fork한 뒤 프로젝트 이름과 현재 상태만 채우면 같은 구조로 시작할 수 있다.

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