TL;DR — 혼자 AI 에이전트 여러 대랑 사업을 굴립니다. 일을 시키다 보니 문서가 자연스럽게 세 종류로 갈렸어요. ① 어떻게 하는지(절차) ② 무엇을 해왔고 지금 어디인지(프로젝트 기록) ③ 무엇을 지켜야 하는지(원칙). 그런데 ②번이 좀 이상했어요. 절차도 아니고 원칙도 아닌데, 업계에 딱 부르는 이름도 없더라고요. 그 정체를 쫓다가 "살아있는 시스템"이라는 결론까지 갔습니다.
저는 사진 일을 20년 했어요. 지금은 어쩌다 AI 에이전트 여러 대를 데리고 혼자 회사를 굴립니다. 코드도 배포도 콘텐츠도 에이전트들이 나눠 하죠. 그런데 사람이든 AI든 여럿이 같이 일하려면 결국 글로 적어둬야 합니다. 말로는 안 남아요. 그래서 저는 문서광이 됐어요.
일을 시키다 보니, 적어두는 문서가 저절로 세 종류로 갈리더라고요.
- 절차 — "이 작업은 이렇게 한다." 배포하는 법, 보고서 쓰는 법. 어떻게(how) 를 담아요.
- 프로젝트 기록 — "이 프로젝트는 이렇게 시작해서 지금 여기까지 왔다." 무엇을(what) 해왔는지를 담죠.
- 원칙 — "무슨 일이 있어도 이건 지킨다." 절대 어기면 안 되는 규범. 왜(why) 에 해당해요.
여기까지는 깔끔했어요. 그런데 어느 날 의문이 들었습니다. 이 셋은 정확히 어떻게 다르고, 어떻게 한 몸으로 도는 거지? 특히 가운데 있는 '프로젝트 기록' 말이에요. 얘는 절차도 아니고 원칙도 아닌데, 그럼 대체 정체가 뭐죠?
이 질문 하나를 붙잡고 한참을 갔습니다. 생각보다 멀리요.
1. 절차와 기록은 '품사'가 다르더라고요
먼저 절차와 프로젝트 기록을 나란히 놓고 봤어요. 그랬더니 둘은 아예 품사가 다른 존재였습니다.
절차는 동사예요. "이걸 어떻게 하나." 상태가 없어요(무상태). 부르면 실행되고, 끝나면 사라지죠. 매번 똑같이 돕니다. 함수 같은 거예요.
프로젝트 기록은 명사예요. "지금 어디까지 왔나." 상태를 품고 있어요. 어제의 결정, 오늘의 진행, 쌓여온 역사가 다 들어있죠. 계속 누적됩니다. 데이터 같은 거예요.
이걸 깨닫고 나니 둘의 관계가 보였어요. 경쟁하는 게 아니라 직교(直交) 합니다. 한쪽은 가로축, 한쪽은 세로축이에요. 그리고 결정적으로 — 절차가 프로젝트 기록을 읽고 갱신합니다. 객체와 메서드의 관계랑 똑같아요. 기록(데이터)이 있고, 절차(함수)가 그걸 다루죠.
그럼 세 번째인 '원칙'은요? 얘는 위에서 둘 다를 내려다봅니다. 절차도 기록도 원칙을 어기면 안 돼요. 그러니까 세 층위가 이렇게 좌표계를 이루는 거예요.
원칙 (위에서 통제)
│
기록(상태) ┼ 절차(행위)
│
여기서 한 가지가 분명해졌어요. 절차와 원칙은 업계에 흔한 개념이에요. 절차는 런북(runbook)이고, 원칙은 설계 원칙이나 규약이죠. 그런데 가운데 '프로젝트 기록'은… 이게 정확히 뭐라고 불리는 거지? 궁금해졌습니다.
2. 그래서 찾아봤어요. 근데 이름이 없더라고요
'프로젝트 단위로 상태와 역사를 다 품은 살아있는 문서.' 이런 걸 업계에서 뭐라고 부를까. 찾아봤더니 딱 떨어지는 단일 용어가 없었어요. 대신 이미 확립된 여러 패턴이 하나로 융합된 형태더라고요.
- 도메인 주도 설계(DDD)의 '경계 잡힌 맥락(bounded context)' — 하나의 응집된 영역을 통째로 묶는 개념. 제 프로젝트 기록 하나하나가 정확히 이거였어요.
- 이벤트 소싱(event sourcing)의 '추가만 하는 로그' — 수정·삭제 없이 사건을 쌓기만 하고, 현재 상태는 그 사건들을 합산해 얻는 방식. 제 기록의 '히스토리'가 그대로 이 패턴이었죠.
- AI 에이전트의 '장기 기억(long-term memory)' — 에이전트가 맥락을 잃지 않게 영속적으로 붙들어 두는 저장소. 제 기록의 용도가 바로 이거고요.
- 게다가 보통 따로 노는 문서들 — 설계 결정 기록(ADR), 장애 회고(post-mortem), 목표·지표(OKR), 리스크 대장 — 이걸 저는 프로젝트 하나당 한 문서에 다 욱여넣고 있었어요.
업계엔 이게 각각 따로 있어요. 결정 기록은 결정 기록대로, 회고는 회고대로, 지표는 스프레드시트대로. 그런데 저는 모르고 그걸 프로젝트 단위로 응축시켜 버린 거예요.
결정적 차이도 하나 있었어요. 기존의 이런 문서들은 전부 사람이 일차 독자예요. 제 건 AI 에이전트가 일차 독자고요. 에이전트가 일을 시작할 때 제일 먼저 읽는 게 이 기록이거든요.
그래서 내린 결론은 이거였어요. 제가 만든 건 아직 업계에 이름이 안 붙은, 막 떠오르는 패턴(emerging pattern) 이다. 한 문장으로 풀면 — '프로젝트'를 머릿속이나 흩어진 파일이 아니라, 읽고 쓰고 색인할 수 있는 하나의 데이터 구조(일급 객체)로 승격시킨 것. 보통 조직에서 '프로젝트'는 사람 머리와 산발적 문서에 흩어져 있잖아요. 저는 그걸 결정화해서 객체로 만들어 버린 거였어요.
여기까지 오니까, 정작 제가 왜 처음에 그렇게 헤맸는지가 거꾸로 보이기 시작했습니다.
3. 폴더를 100개 만들고 뿌듯했는데, 다 죽었어요
처음에 저는 누구나 하는 걸 했어요. 주제별 폴더요. 전략/ 인프라/ 기술/ 철학/. 분야별로 칸을 딱딱 나눠놓고 어찌나 뿌듯하던지요.
일주일 뒤에 무슨 일이 일어났게요? 아무도 그 폴더를 안 열었어요. 에이전트도, 저도요.
이제는 이유를 알아요. 주제별 폴더는 도서관이거든요. 책을 칸에 꽂는 구조. 그런데 도서관의 숙명은 방치예요. 전략/ 폴더에 전략 문서를 넣는 순간 그건 죽습니다. 다시 안 꺼내고, 갱신도 안 되고, 한 달 뒤엔 현실과 어긋나 있죠. 정적인 분류는 시간을 못 견뎌요.
앞에서 찾은 답이 여기서 빛을 발했어요. 문제는 분류의 기준이었던 거예요. '주제'로 나누면 안 되고 '생애'로 나눠야 했어요. "이게 무슨 분야지?"가 아니라 "이건 어떤 프로젝트의 살아있는 흐름이지?" 로요. 그래야 같은 문서라도 죽지 않고 계속 참조되고 갱신됩니다. 자산이란 결국 계속 일하는 것이니까요. 무덤 속 문서는 일을 안 하지만, 흐름 속 문서는 일을 합니다.
4. 결국 규칙은 딱 하나로 줄었어요
그래서 프로젝트 기록을 운영하는 규칙을 별별 거 다 만들어봤는데, 끝까지 살아남은 건 하나였어요.
중복은 허용하되, 누락은 금지한다.
처음엔 반대로 했어요. "중복은 비효율이니까 미리 정리하자." 그런데 이게 함정이더라고요. 뭐가 중요한지도 모르는 상태에서 자꾸 가지를 치니까, 나중에 필요한 게 이미 사라지고 없는 거예요.
이게 왜 맞는지는 사실 수학이에요. 두 실수의 비용이 완전히 다르거든요.
- 누락은 비가역적입니다. 한 번 안 적은 건 영원히 복구 불가예요. 그 순간의 맥락은 그냥 증발하죠.
- 중복은 가역적입니다. 겹친 건 나중에 언제든 합치고 줄일 수 있어요. 잠깐 자리만 차지하는 잉여일 뿐이에요.
비용이 비대칭이니 답은 정해져 있어요. 헷갈리면 일단 남겨라. 이거, 자연과 공학이 이미 검증한 패턴이에요. DNA도 먼저 유전자를 복제해놓고 나중에 분화시킵니다. 그 여분의 사본이 새 기능의 재료가 돼요. 깃(Git) 도 일단 다 커밋하고 나중에 정리하죠. 먼저 보존, 나중에 응축. 미리 최적화하지 않아요.
5. 이게 "살아있다"는 뜻이에요
그럼 쌓기만 하면 지저분해지지 않냐고요? 여기에 핵심이 있어요.
효율은 쌓아가면서 응축하는 거지, 쌓기도 전에 가두는 게 아니에요.
충분히 쌓이면 그 안에서 중복이 자연스럽게 드러나요. 그때 합치면 됩니다. 시스템이 스스로 모순을 발견하고, 스스로 정리하고, 스스로 규칙을 고쳐요. 초기엔 중복과 비효율로 보이던 게, 시간이 지나며 응축되면서 진화하는 거죠. 이게 죽은 도서관과 살아있는 시스템의 차이예요.
그리고 여기서 아까 그 세 층위가 다시 만나요. 매일의 작업 기록이 프로젝트 기록으로 옮겨지고(상태), 거기서 반복되는 교훈이 절차로 굳고(행위), 절대 어기면 안 될 게 드러나면 원칙으로 올라갑니다(규범). 하루치 대화 → 프로젝트 자산 → 절차 → 원칙. 그냥 흘러가버릴 한순간이, 단계를 밟아 올라가며 점점 단단한 자산으로 결정화되는 거예요.
저한테는 이 질문이 제일 중요했어요. "오늘 한 일을, 어떻게 방치하지 않고 자산으로 세울까?" 세 층위 문서 시스템은 결국 이 질문에 대한 답이었던 거죠.
6. 솔직한 고백 — 아직 못 푼 숙제
여기까지 읽으면 꽤 그럴듯하죠? 정직하게 말할게요.
이 시스템이 살아있는 진짜 이유는, 제가 매일 들여다보기 때문이에요. 응축할 때가 됐는지, 뭐가 빠졌는지, 어디가 어긋났는지 — 결국 지금은 제가 심장 노릇을 하고 있습니다.
그래서 다음 숙제는 분명해요. 이 생명력을 자동화할 수 있을까? 제가 안 보는 날에도 시스템이 스스로 빠진 걸 감지하고 응축을 시작하게 만들 수 있을까. "누락 금지"를 사람이 아니라 시스템이 보증하게 만드는 거요. 살아있는 것의 궁극은 결국 스스로 뛰는 것이니까요. 거기까지 가면 그건 더 이상 제 문서 정리법이 아니라, 진짜 하나의 운영 체제가 되겠죠.
긴 글이었네요. 정리하면 — 절차·기록·원칙이라는 세 층위로 시작했는데, 가운데 '프로젝트 기록'의 정체를 쫓다 보니 이름 없는 패턴과 살아있는 시스템이라는 데까지 왔어요.
여러분께 묻고 싶어요. 혹시 프로젝트를 이렇게 '하나의 데이터 구조(일급 객체)'로 다뤄본 분 있나요? 있다면 그걸 뭐라고 부르세요? 그리고 그 "응축하는 판단"까지 자동화해본 분 있으면 꼭 듣고 싶어요. 저는 딱 거기서 막혀 있거든요.
읽어주셔서 고맙습니다. 🙏
글쓴이는 사진 일을 거쳐 지금은 AI 도구로 작은 사업을 만들어가고 있습니다.