필자는 코드를 작성하지 않는 경영 컨설턴트(중소기업 진단사)입니다. 개발자는 아니지만, 업무의 상당 부분을 Claude Code 상에서 수행하고 있습니다.

안건별 기록과 진행 관리, 제안서나 프레젠테이션 자료 작성, 조사, 고객과의 커뮤니케이션(필자는 호스트 역할도 수행)의 구성. 에디터가 아니라, 업무의 OS로서 사용하고 있다는 감각입니다.

그런 방식으로 약 3개월 정도 사용해 보니, 최대의 적이 명확해졌습니다. AI는 길게 대화하면 바보가 된다.

이 기사는 그 문제를 "AI에게 인수인계서를 쓰게 하는" 방향으로 해결하기 위해 만든 시스템 hikitsugi를 공개하는 이야기입니다.

「AI가 점점 바보가 되는」 정체

Claude Code를 어느 정도 능숙하게 사용하는 사람이라면 아마 이 감각을 기억하고 있을 것입니다.

• 긴 작업 도중에 이전에 결정했던 사항을 잊어버리고 같은 제안을 반복함
• 세션을 다시 시작하면 동일한 전제를 다시 가르쳐야 함

원인은 능력이 아니라 기억의 구조입니다. AI의 컨텍스트(Context)는 세션마다 휘발되며, 긴 세션에서는 오래된 문맥부터 흐릿해집니다.

엔지니어는 이 문제에 대한 형식을 이미 가지고 있습니다. 코드는 Git에, 설계는 설계 문서에, 결정 사항은 ADR(Architecture Decision Record)에 남깁니다. 다음 사람(미래의 자신이나 AI)은 그것을 읽으면 따라잡을 수 있습니다. 비엔지니어의 업무에는 그 "외부 기억의 형식"에 해당하는 것이 없습니다. 이 부분이 진정한 격차라고 생각합니다.

인간 조직은 「인수인계서」로 해결해 왔다

직원이 퇴사할 때나 여러 명이서 작업할 때, 조직은 어떻게 할까요? 답은 예전부터 있었습니다. 바로 인수인계서를 쓰게 하는 것입니다.

• 지금 이 안건은 어떻게 되어 있는가 (현재 위치)
• 무엇을 어떤 순서로 할 예정인가 (계획)
• 무엇이 확정되었고, 무엇이 아직 유동적인가 (결정 사항)
• 경위는 어디를 읽으면 알 수 있는가 (시계열)

따라서 발상은 단순합니다. "Claude에게 매 세션 인수인계서를 쓰게 하면서 일하게 하면 된다". 실제로 Claude는 "기록해 줘"라고 부탁하면 기록합니다.

하지만 실제로 해보면 알 수 있듯이, 형식을 정하지 않고 AI에게 기록하게 하면 기록은 거의 확실하게 엉망이 됩니다.

• 동일한 정보가 파일 A와 B에 작성되고, 한쪽만 업데이트되어 내용이 어긋남
• 계속 덧붙여지며 비대해지는 메모가 만들어져, 어떤 것이 현재 유효한 정보인지 알 수 없게 됨
• 세션마다 저장 위치나 작성 방식이 달라짐

인간의 직장에서 인수인계서 포맷을 정하는 것과 마찬가지로, AI에게도 기록의 형식이 필요합니다. 그리고 인간과 달리 AI는 매 세션 기억이 날아가기 때문에, 형식 "을 지켜줘"라고 말하는 것만으로는 지켜지지 않습니다. 형식으로부터의 일탈을, 기록의 입구에서 기계적으로 차단하는 메커니즘이 필요합니다.

이 두 가지(기록의 형식 + 형식을 지키게 하는 자동 체크)를 패키지로 만든 것이 hikitsugi입니다.

hikitsugi의 내용

수행하는 일은 세 가지입니다.

1. 기록의 저장소를 3개 층으로 고정한다

docs/
├── dictionary/ ← 사실의 정본(인물·조직·자신). 덮어쓰기형
├── manuals/ ← 절차·노하우. 덮어쓰기형
...

포인트는 "현재 위치(덮어쓰기로 항상 최신 상태 유지)"와 "경위(덧붙이기로 시계열 축적)"를 처음부터 파일 단위로 나누는 것입니다. 기록이 엉망이 되는 대부분의 원인은 이 두 가지를 하나의 파일에 섞었기 때문에 발생합니다.

새로운 세션의 Claude에게는 "이 topic의 다음부터"라고 말하기만 하면 됩니다. 00_index.md(현재 위치)를 읽으면 재개할 수 있고, 자세한 경위가 필요할 때만 시계열을 파고듭니다.

2. 작성 규칙을 소수만 정한다

• 덮어쓰기형과 덧붙이기형을 구분한다: 현재 위치·사실의 정본은 덮어쓰기(항상 최신 1장), 경위는 덧붙이기(시계열)
• 1 정보 1 홈 (1 Information 1 Home): 동일한 정보를 두 곳에 쓰지 않는다. 쓰고 싶다면 링크를 건다
• 행 수 상한: 파일이 비대해지면 분할·아카이브한다 (다시 읽을 수 없는 메모는 없는 것과 마찬가지)

규칙은 이것뿐이라고 해도 될 정도로 적지만, AI는 세션이 바뀌면 이를 아무렇지 않게 어깁니다. 그래서 다음 단계가 필요합니다.

3. hook(자동 체크 11개)가 형식을 지키게 한다

Claude Code에는 hook라는 "도구 실행 전후에 임의의 체크를 삽입하는" 메커니즘이 있습니다. hikitsugi는 여기에 11개의 체크를 배치하여, 형식으로부터의 일탈을 입구에서 차단합니다. 예를 들어:

어떤 일이 발생하면	어떻게 조치하는가
topic 내의 이상한 위치에 쓰려고 하면	반려하고 정규 위치로 유도
...

중요하게 고려한 설계 방침은, hook은 자동으로 다시 쓰거나 삭제하지 않는다는 것입니다. 반려하기, 확인하기, 제안하기 중 하나로 반드시 멈추게 합니다. AI에게 기록을 맡기는 이상, '멋대로 무언가가 사라지는' 경험은 단 한 번이라도 발생하면 신뢰가 끝나는 것이기 때문입니다.

인물 사전(상대·조직·자기 자신에 대한 '사실의 정본'을 1인당 1개 파일로 가지는 계층)도 동봉되어 있습니다. 컨설팅업에 국한되지 않고, 업무 기록은 거의 반드시 '누군가와의 대화'이므로, 인물의 사실 관계를 프로젝트의 경위와 분리하여 가질 수 있도록 설계했습니다.

업무가 어떻게 변했는가

도입 후의 변화를 과장 없이 작성합니다.

재개 비용이 거의 제로가 되었다. "〇〇 topic, 이어서"라고 하면 이전 세션의 내용이 이어서 시작된다. 이전에는 세션을 새로 시작할 때마다 상황을 처음부터 다시 설명해야 했다 -
'왜 그렇게 결정했는가'가 사라지지 않게 되었다. 과거 판단의 이유를 물어도 decisions와 시계열을 따라가면 근거와 함께 나타난다. 이는 인간 동료에게 설명할 때도 그대로 사용할 수 있다 -
기록이 'AI를 위한 메모'가 아니라 '자신의 자산'이 되었다. 인수인계서는 인간이 읽을 수 있는 일본어 markdown이므로, Claude가 작성한 기록을 그대로 자신의 회고나 보고의 베이스로 사용할 수 있다

세 번째가 이 플러그인에 hikitsugi라는 이름을 붙인 이유입니다. 인수인계서가 그대로 자산이 된다.

반대로, 맞지 않는 사람에 대해서도 적어둡니다. 자동으로 대화를 요약해서 기억해 주는 '기억 계열 도구'를 찾는 사람에게는 맞지 않습니다(해당 계통의 우수한 도구는 이미 많이 나와 있습니다). hikitsugi가 하는 일은 기억의 자동화가 아니라, 인간이 읽을 수 있는 기록을 형식을 통해 강제하는 것입니다. 수고가 제로가 되지는 않습니다. 그 대신, AI가 없어져도 읽을 수 있는 기록이 남습니다.

설치

전제 조건은 Claude Code 도입 완료 + Python 3.10+ 입니다. git clone 후 hook을 연결하면, topic은 명령어 하나로 생성할 수 있습니다 (예: python hooks/init-topic.py 20-life moving-2026). 설정 파일을 아무것도 작성하지 않아도 기본값으로 동작합니다.

README에 세팅 3단계와 퀵 스타트(Quick Start)를 정리해 두었습니다.

요약

AI가 길게 대화하다 보면 바보가 되는 이유는,

외부 기억의 형식이 없다는 것이 문제 -
인간 조직이 예전부터 해온 '인수인계서'를, 형식 + 자동 체크를 통해 AI에게 시키면 해결된다

부수적인 효과로, AI의 기록이

인간이 읽을 수 있는 자산이 된다

Discussion