하루 기록은 남는데 역사는 사라졌다: AI 에이전트 6명에게 ‘기전체 작업일지’를 붙인 과정

📝 한줄 요약

날짜순 업무일지만으로는 여러 AI 에이전트와 프로젝트의 관계·결정·전환점을 다시 읽기 어려웠습니다. 기존 업무일지는 그대로 보존하고, 본기·세가·열전·서지·표로 연결되는 두 번째 기전체 작업일지를 모든 채널과 6개 전문 에이전트에 적용했습니다.

바쁘시면 이것만 읽어도 됩니다.

• 기존 공동 업무일지는 없애거나 바꾸지 않았습니다.

• 날짜순 업무일지는 “무엇을 실행했는가”를 기록하는 공식 사실 원장으로 유지했습니다.

• 기전체 작업일지는 “어떤 사건·프로젝트·인물·제도가 서로 연결되는가”를 보여주는 해석·연결 원장으로 추가했습니다.

• 모든 작업을 본기·열전에 반복하지 않고, 사건 원기록을 먼저 만든 뒤 중요한 전환점만 상위 기록으로 올리는 Gate를 두었습니다.

• 타디스·C&B·피카소·Libro Vitae·한비자:상앙·워런버핏 등 6개 프로필에 공통 규칙을 연결했습니다.

• 필수 파일 누락 0건, 깨진 내부 링크 0건, 프로필 참조 누락 0건으로 검증했습니다.

🎯 이런 분들께 도움됩니다

• 여러 AI 에이전트가 서로 다른 채널에서 일하는 환경을 운영하는 분

• 업무일지는 많은데 중요한 결정의 맥락을 다시 찾기 어려운 분

• 날짜순 기록과 프로젝트별 역사를 함께 남기고 싶은 분

• 에이전트에게 기록을 맡기되 사실과 해석이 뒤섞이는 것을 막고 싶은 분

• 자동화 기록이 지나치게 커지거나 같은 내용을 반복하는 문제를 줄이고 싶은 분

😫 문제 상황: 매일의 사실은 남았지만 전체 이야기는 보이지 않았다

이미 공동 업무일지는 운영되고 있었습니다. 실질 작업이 끝나면 날짜별 파일에 요청, 수행 내용, 산출물, 검증 결과와 후속 조치를 적었습니다. 누가 어떤 작업을 했는지 확인하기에는 좋은 구조였습니다.

하지만 전문 에이전트가 늘고, 서로 다른 채널에서 프로젝트가 이어지면서 다른 질문이 생겼습니다.

• 이 결정은 어느 프로젝트의 전환점이었나?

• 여러 에이전트 중 누가 어떤 역할을 맡았나?

• 비슷한 도구 문제를 전에 어떻게 해결했나?

• 오늘의 작업이 몇 달 전 시작한 흐름과 어떻게 이어지나?

• 어떤 규칙이 언제, 왜 생겼나?

날짜순 업무일지를 전부 검색하면 사실은 찾을 수 있습니다. 그러나 사실 사이의 관계와 변화의 맥락은 매번 다시 조립해야 했습니다.

기존 업무일지를 프로젝트별로 다시 나누는 방법도 생각할 수 있었습니다. 하지만 그렇게 하면 같은 사건이 날짜별·프로젝트별·에이전트별 파일에 반복되고, 어느 쪽이 공식 원본인지 모호해질 수 있습니다. 이미 잘 작동하는 원장을 고쳐서 새로운 문제를 만들고 싶지는 않았습니다.

🌱 시작은 “기전체”라는 한 단어였다

첫 질문은 짧았습니다.

기전체

기전체는 역사를 한 줄의 연대기로만 적지 않고, 본기·세가·열전·서·표처럼 여러 관점으로 나누어 연결하는 방식입니다. 이 구조를 개인 자료 정리에 적용할 수 있는지 살펴보다가, 다음 질문으로 이어졌습니다.

그러면 여기에서 작업하는 작업기록을 이런 기전체 스타일로 할 수 있을까?

처음에는 특정 스레드의 작업기록을 기전체식으로 보여주는 방안을 생각했습니다. 그런데 곧 더 중요한 조건이 나왔습니다.

기존에 하던 업무일지는 그대로 유지하고, 새롭게 이 기전체 방식의 작업일지를 추가하는 방안은 어때?

이 문장이 설계의 중심이 됐습니다. 기존 원장을 재편하는 것이 아니라, 기존 원장을 보존한 채 두 번째 연결 계층을 추가한다.

💡 첫 번째 전환점: “대체”가 아니라 “이중 원장”으로 정했다

두 기록은 같은 일을 반복하는 문서가 아닙니다. 책임을 다르게 나눴습니다.

충돌 우선순위도 정했습니다.

실제 산출물과 검증 근거
→ 날짜별 공동 업무일지
→ 사건별 기전체 기록
→ 본기·세가·열전·서지·표의 해석과 연결

기전체 기록이 더 읽기 좋다는 이유로 사실 원장을 덮어쓰지 않습니다. 내용이 다르면 실제 파일과 검증 결과, 날짜별 업무일지를 먼저 봅니다.

이 원칙 덕분에 기존 업무일지의 안정성을 유지하면서도 새로운 관점을 추가할 수 있었습니다.

🔧 작업 과정

1. 스레드 한정인지 전역 규칙인지 먼저 분리했다

“이 스레드에서 기록한다”는 표현은 자동으로 모든 채널에 적용되지 않습니다. 전문 에이전트는 별도 프로필과 대화 맥락을 가질 수 있기 때문입니다.

그래서 적용 범위를 다시 확인했습니다.

이 스레드에서 한다는 것은 다른 채널에도 모두 적용한다는 의미야?

답은 ‘아직 아니다’였습니다. 특정 스레드의 관행과 모든 에이전트가 따라야 하는 운영 규칙은 다릅니다.

최종 결정은 명확했습니다.

나는 모든 채널, 전문 에이전트에 적용되는 전역규칙으로 확장하고 싶어

이후부터는 단순 문서 작성이 아니라 다중 프로필 운영 규칙 변경으로 처리했습니다.

2. 먼저 변경 전 상태를 보존했다

전역 규칙은 여러 전문 에이전트의 행동에 영향을 줍니다. 그래서 공용 운영문서와 6개 프로필 지침을 수정하기 전에 원본 사본을 별도 백업 영역에 보존했습니다.

백업 대상은 다음과 같았습니다.

• 공용 운영 원칙

• 공용 안내 문서

• 타디스 프로필 지침

• C&B 프로필 지침

• 피카소 프로필 지침

• Libro Vitae 프로필 지침

• 한비자:상앙 프로필 지침

• 워런버핏 프로필 지침

총 8개 파일을 보존하고 각 파일의 해시를 확인했습니다. 잘못된 규칙이 들어가더라도 원래 상태로 돌아갈 좌표를 먼저 만든 것입니다.

3. 기전체를 바로 다섯 파일에 쓰지 않고 ‘사건 원기록’을 먼저 두었다

기전체라고 해서 모든 작업을 본기·세가·열전에 각각 복사하면 기록량이 폭발합니다. 여러 에이전트가 동시에 같은 파일을 수정할 위험도 커집니다.

그래서 먼저 사건별 원기록을 남기는 층을 추가했습니다.

모든 실질 작업은 먼저 사건으로 기록할 수 있지만, 본기와 열전까지 올라가는 것은 아닙니다. 중요한 사건만 선별 편입합니다.

4. 사건 기록의 최소 계약을 정했다

각 사건에는 다음 정보가 필요합니다.

• 고유 작업 ID

• 날짜와 작성 에이전트

• 채널 범위와 프로젝트

• 완료·진행·차단 상태

• 연결된 날짜별 업무일지

• 실제 산출물

• 관련 사건과 상위 기록

• 발단, 경과, 참여자 역할, 결과, 검증, 다음 영향

핵심은 멋진 서사가 아니라 검증 가능한 연결입니다. 다른 에이전트의 성과를 추정해서 적지 않고, 실제 수행 근거가 있을 때만 역할을 기록하게 했습니다.

5. 모든 전문 프로필에 공통 규칙을 연결했다

공용 문서만 만들어 놓으면 독립 프로필이 새 규칙을 놓칠 수 있습니다. 따라서 6개 프로필 각각의 운영 지침에 같은 규칙 좌표를 연결했습니다.

모든 채널·스레드·DM의 실질 작업은 기존 공동 업무일지와 기전체 작업일지를 병행한다.

여기서 구현을 프로필마다 복사하지 않았습니다. 각 프로필에는 공용 규칙을 읽으라는 얇은 연결만 두고, 상세 운영 계약은 하나의 공용 문서에 유지했습니다. 규칙이 바뀔 때 여섯 파일의 본문이 서로 달라지는 것을 막기 위해서입니다.

🔐 기술 계약과 Gate

전역 기록 체계가 지속되려면 “적당히 기록한다”가 아니라 통과 조건이 필요했습니다.

이중 원장 기술 계약

완료 Gate

이 Gate가 중요한 이유는 기록을 많이 만드는 것이 목표가 아니기 때문입니다. 사실은 빠짐없이 남기되, 역사적 의미는 선별해서 연결하는 것이 목표입니다.

✅ 실제 결과

전역 규칙 적용 자체를 첫 번째 기전체 사건으로 기록했습니다. 동시에 같은 작업을 기존 날짜별 업무일지에도 남겼습니다. 즉, 첫 사건부터 이중 원장 계약을 실제로 적용했습니다.

Before vs After

첫 기전체 사건이 담은 내용

• 왜 기존 업무일지를 유지했는가

• 왜 특정 스레드가 아니라 전역 규칙이 되었는가

• 누가 결정하고 누가 구현했는가

• 어떤 프로필이 영향을 받는가

• 무엇을 백업하고 무엇을 검증했는가

• 이미 열린 세션에는 언제 반영되는가

단순히 “규칙 파일을 만들었다”가 아니라, 이 변경이 공동 운영의 어느 지점에 놓이는지까지 기록할 수 있게 됐습니다.

추천 이미지: 이 섹션 아래에 chronicles 폴더의 본기·세가·열전·서지·표 구조가 한 화면에 보이는 캡처를 넣으면 좋습니다. 개인 경로와 채널 식별자는 공개 전에 가립니다.

🧭 가장 크게 배운 점

1. 날짜순 기록과 기전체 기록은 경쟁하지 않는다

날짜순 기록은 정확한 실행 순서를 보여줍니다. 기전체는 같은 사건을 프로젝트·인물·제도 관점에서 다시 찾게 해줍니다. 하나를 선택하는 문제가 아니라 역할을 나누는 문제였습니다.

2. 해석 원장은 사실 원장보다 위에 서면 안 된다

읽기 좋은 이야기가 실제 근거보다 강해지면 기록이 미화될 수 있습니다. 그래서 실제 산출물과 devlog를 우선하고, 기전체는 연결과 해석만 담당하게 했습니다.

3. 모든 사건을 본기에 올리면 본기가 다시 업무일지가 된다

중요한 전환점만 본기에 올리는 Promotion Gate가 필요했습니다. 일반 실질 작업은 사건 원기록으로 충분합니다. 역할 확립과 대표 성취가 아닌 일상 작업을 열전에 매번 반복하지 않습니다.

4. 전역 규칙은 공용 문서 하나만 만든다고 전역이 되지 않는다

독립 프로필이 실제로 그 규칙을 읽을 좌표가 있어야 합니다. 공용 계약 하나와 프로필별 얇은 참조를 함께 두어야 했습니다.

5. 기록 체계의 첫 기록은 그 체계 자체여야 한다

새 운영 규칙을 만든 뒤 첫 사건으로 그 변경을 기록했습니다. 규칙이 언제, 왜, 누구의 결정으로 생겼는지부터 남겨야 이후의 기록도 출발점을 잃지 않습니다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 기존 체계를 없애기 전에 각 기록이 답해야 하는 질문을 분리했습니다.

2. 전역 적용 여부를 스레드 관행과 분리해 명시적으로 결정했습니다.

3. 여러 프로필을 바꾸기 전에 원본 백업과 해시를 먼저 만들었습니다.

4. 모든 작업을 상위 기록에 복사하지 않고 사건→선별 승격 구조를 사용했습니다.

5. 완료 보고 전에 파일 존재, 필수 필드, 프로필 참조와 내부 링크를 실제로 검사했습니다.

이렇게 하면 위험합니다

1. 기전체가 읽기 좋다는 이유로 기존 업무일지를 없애기

2. 같은 내용을 본기·세가·열전에 매번 복사하기

3. 공용 규칙 파일만 만들고 독립 프로필의 참조 여부를 확인하지 않기

4. 다른 에이전트의 역할과 성과를 근거 없이 추정하기

5. 파일을 생성했다는 이유만으로 링크와 read-back 검사 없이 완료 처리하기

🌍 다른 업무에 적용한다면

개인 연구자료에도 같은 구조를 적용할 수 있습니다.

예를 들어 논문·판례·회의록을 날짜별로만 쌓으면 수집 시점은 알 수 있지만, 어떤 연구 질문과 인물, 기관, 방법론에 연결되는지 다시 정리해야 합니다. 원본 수집 로그를 사실 원장으로 유지하고, 사건별 연구 메모를 만든 뒤 중요한 변화만 다음처럼 선별할 수 있습니다.

• 본기: 연구 방향의 주요 전환

• 세가: 장기 연구주제와 프로젝트

• 열전: 주요 학자·판례·기관

• 서·지: 방법론·도구·분류체계

• 표: 주장·근거·반증의 비교표

원본을 옮기지 않고 연결 계층만 추가한다는 점도 같습니다.

🤝 배워서 남 주기

이 구조를 다른 팀이 그대로 복사할 필요는 없습니다. 대신 다음 세 가지 계약은 재사용할 수 있습니다.

1. 사실 원장과 해석 원장을 분리한다.

2. 모든 사건을 먼저 원기록으로 남기고 중요한 사건만 상위 색인으로 승격한다.

3. 완료를 파일 생성이 아니라 근거·링크·개인정보·read-back Gate로 판정한다.

여러 AI 에이전트를 운영하는 사람뿐 아니라 프로젝트 회고, 연구노트, 조직 의사결정 기록, 개인 아카이브에도 적용할 수 있습니다.

🕊️ 널리 사람을 이롭게 한다면

기록이 많아질수록 사람은 기록을 더 열심히 쓰는 대신 중요한 맥락을 다시 찾느라 시간을 씁니다. 특히 여러 AI 에이전트가 빠르게 산출물을 만들면 “무엇을 했는가”는 많이 남지만 “왜 이렇게 되었는가”가 더 빨리 사라질 수 있습니다.

이중 원장 방식은 기존 기록을 버리지 않으면서도 관계와 전환점을 복원합니다. 팀원은 긴 로그를 처음부터 읽지 않고 프로젝트의 흐름을 파악할 수 있고, 운영자는 AI가 과거 성과를 과장하거나 잘못 연결하지 않았는지 실제 근거로 확인할 수 있습니다.

줄이고 싶은 것은 세 가지입니다.

• 과거 결정의 맥락을 다시 조립하는 반복노동

• 여러 에이전트 사이에서 책임이 흐려지는 문제

• 읽기 좋은 요약이 실제 사실을 덮어버리는 위험

🚀 앞으로의 계획

앞으로 실제 작업에서 사건 기록이 얼마나 안정적으로 쌓이는지 관찰할 예정입니다. 특히 다음을 점검해야 합니다.

• 사건 파일이 지나치게 많이 생성되지 않는가

• 본기·열전 승격 기준이 느슨해지지 않는가

• 여러 에이전트가 동시에 기록할 때 충돌이 없는가

• 새로운 전문 프로필이 추가될 때 공통 규칙 연결이 누락되지 않는가

• 사건·devlog·산출물 사이의 링크가 시간이 지나도 유지되는가

충분한 운영 사례가 쌓이면 월별 색인과 누락 검사, 깨진 링크 확인을 읽기 전용 점검으로 자동화할 수 있습니다. 다만 자동수정은 별도 승인과 검증을 거쳐야 합니다.

📋 재사용 가능한 프롬프트

프롬프트 1: 기존 업무일지를 보존한 이중 원장 설계

현재 사용 중인 [업무일지 경로와 형식]을 삭제하거나 재편하지 말고 공식 사실 원장으로 유지해 주세요. 그 위에 사건·프로젝트·참여자·제도·상태를 연결하는 두 번째 기록 계층을 설계해 주세요. 두 원장의 역할, 충돌 시 우선순위, 중복 방지 규칙, 기록 대상과 제외 대상, 저장 구조를 먼저 제안해 주세요. 기존 파일은 승인 없이 이동하거나 이름을 바꾸지 마세요.

프롬프트 2: 기전체식 사건 기록 만들기

다음 작업의 실제 산출물과 검증 근거를 확인한 뒤 기전체식 사건 기록을 작성해 주세요: [작업 설명 또는 산출물 경로]. 발단, 경과, 참여자와 확인된 역할, 결과, 근거와 검증, 이후 영향으로 나누고, 날짜별 업무일지와 산출물 경로를 연결해 주세요. 근거가 없는 성과나 다른 참여자의 역할은 추정하지 마세요. 본기·세가·열전·서지·표 중 어디에 추가 편입할 가치가 있는지도 이유와 함께 판단해 주세요.

프롬프트 3: 사건 기록 완료 Gate 검사

[기전체 기록 루트]를 읽기 전용으로 검사해 주세요. 각 사건에 고유 ID, 날짜, 작성자, 상태, 프로젝트, 날짜별 업무일지, 산출물, 검증 섹션이 있는지 확인하고, 내부 링크와 실제 파일 존재 여부를 검사해 주세요. 비밀값·불필요한 개인정보 가능성을 별도로 표시하고, 본기·세가·열전·서지·표에 동일 내용을 과도하게 복제한 항목을 찾아 주세요. 자동수정하지 말고 PASS·WARN·BLOCKED와 근거 경로만 보고해 주세요.

처음의 질문은 “기전체” 한 단어였습니다. 그 질문은 개인 자료 정리법을 거쳐, 여러 AI 에이전트가 함께 일한 역사를 어떻게 남길 것인가라는 운영 문제로 이어졌습니다.

결론은 기존 기록을 버리는 것이 아니었습니다.

업무일지는 매일의 좌표를 남기고, 기전체는 그 좌표들이 어떤 항로를 만들었는지 보여준다.

둘을 함께 두었을 때 비로소 실행 사실과 전체 맥락을 동시에 보존할 수 있었습니다.