내 업무 컨텍스트가 통째로 담긴 챗봇 구축 방법

skill을 이것 저것 만들다가 자연스럽게 따라온 생각이 있다. “이게 회의록만 되는 게 아니라 내 모든 업무 자료에 되면 어떨까?”

처음에는 정책서도, PRD도, 회의록도, 과거 결정의 히스토리도 한 폴더에 모은다는 발상 자체가 좀 과해 보였다. 지금 와서 돌아보면, 그 발상이 과한 게 아니라 그게 사실은 내가 다 정리하고, 기억하지 못하는 것을 정리해보자 라는 생각에서 출발했다

처음 시작은 정책서 하나를 못 찾으면서였다

작년 가을쯤, 어떤 정책의 이전 버전이 어디 있는지를 30분 동안 못 찾은 적이 있다. 위키에 있을 것 같아서 한참 뒤졌고, 슬랙 검색도 했고, 결국 다른 동료에게 물어서 찾았다. 그 정책서는 분명히 내가 2년 전에 직접 쓴 거였다. 근데 많은 문서들 사이에서 어떤 키워드인지 헷갈렸고, 결국에는 찾긴했지만, 문서를 찾는데 너무 많은 시간을 소비했다.

문제는 분명했다. 내 업무 자료가 슬랙, 위키, 지라, 옵시디언, 메일, 구글 드라이브 등 최소 여섯 군데에 흩어져 있었다. 검색은 각 도구의 검색에 의존해야 했고, 그 중에 어디있는지 찾지 못했기 때문이 아니었나 싶다. 나는 기본적으로 데일리 일지를 구글 스프레드시트에 모아두고, 각 위키 등 관련 문서 링크를 첨부하고있다. 그럼에도 불구하고, 그 곳에 모아지지 않는다면, 나중에 찾기가 어려워지는 문제가 생기는 것이다.

그래서 시도한 게 “한 폴더에 모아보자”였다. 모든 자료의 사본까지는 아니어도, 내가 자주 다시 보는 자료의 위치와 자료를 마크다운 버전이라도 한 곳에 두자는 결심이었다.

폴더 구조부터 정했다

폴더 구조는 한 번에 안 정해졌다. 처음엔 다섯 개 폴더로 시작했는데 두 달 뒤에 보니 폴더가 열 개를 넘었다. 줄였다가 다시 늘렸다가 한 끝에 지금 안정된 모양은 대략 이렇다.

work-context/
├── CLAUDE.md             # 이 레포에서 일할 때의 규칙
├── meetings/             # 회의록  
│   ├── 2026/
│   └── archive/
├── policies/             # 정책서
│   ├── current/          # 최신버전 정책
│   └── deprecated/       # 폐기된 정책 (히스토리용)
├── ADR/                   # ADR
│   ├── shipped/
│   └── in-progress/
├── user-feedback/        # 유저 피드백 모음
│   ├── slack/
│   ├── reviews/
│   └── surveys/
├── decisions/            # 결정 사항
│   └── project/
└── playbook/             # 자주 쓰는 워크플로우 메모

가장 중요한 폴더가 두 개 있다. decisions/와 playbook/이다.

decisions/는 ADR(Architecture Decision Record) 스타일을 빌려와서, “각 중요한 프로젝트별로 왜 그렇게 결정했나”를 한 파일씩 적어두는 폴더이고, 정책서, ADR을 바탕으로 결정사항과 주요 정책들을 모아두고있다.
정책서는 “현재 어떻게 동작하는가”인데, ADR은 “왜 이렇게 됐는가”이다. 1년 뒤의 내가 6개월 전의 결정을 다시 볼 때 가장 자주 찾는 자료가 됐다.

playbook/은 “이 작업은 이렇게 한다”의 메모다. 슬래시 커맨드보다 한 단계 위에 있는 메모라고 보면 될 것 같다. 어떤 작업은 한 줄 명령으로 정의하기엔 너무 복잡해서, 일단 글로 적어두는 폴더다.

CLAUDE.md가 결국 가장 중요했다

폴더 구조보다 더 중요한 게 사실은 CLAUDE.md 하나였다. 이 파일은 다들 알겠지만 “이 폴더에서는 어떤 톤으로, 어떤 규칙으로 일해야 하는가”를 알려주는 안내문이다.

내 CLAUDE.md는 처음에 다섯 줄짜리였다. 3개월쯤 지나니까 50줄이 됐고, 지금은 200줄이 좀 안 된다. 늘어난 부분의 대부분은 “이건 하지 마세요” 쪽이었다. 회의록에서 결정사항을 추출할 때 임의 해석 금지, 유저 피드백을 분류할 때 카테고리 임의 추가 금지, 정책서를 인용할 때 출처 파일 경로 반드시 표시. 이런 식이었다.

처음엔 잘 됐던 작업이 어느 순간부터 잘 안 되면, 대부분 CLAUDE.md에 한 줄을 더 추가하는 일로 해결했다. 근데, 계속 CLAUDE.md 추가하다보니, 지침이 길어졌고, 중간에 지침을 재정비해서 내가 원하는 방향으로 업데이트 하기도했다.

활용 시나리오, 가장 자주 쓰는 세 가지

지금 가장 자주 쓰는 활용 시나리오는 대략 세 가지다.

하나, “이 정책의 히스토리는?” 새 정책을 쓰기 전에 비슷한 결의 이전 정책과 그 정책의 ADR을 같이 펴두고 시작한다. 6개월 전의 결정 이유를 30초 안에 다시 찾는다.

둘, “지난 분기 같은 주제 회의에서 어떤 결정이 있었지?” 회의 들어가기 전에 한 번씩 던지는 질문. 잊고 있던 결정 사항을 회의실에 들고 들어간 적이 여러 번 있다.

셋, “비슷한 정책이 있었나?” 새로운 기능을 검토하기 전에 비슷한 결의 가능이 있는지, 참고할 만한 기능이 있는지를 확인한다

이 세 가지가 합쳐지면서 어떤 변화가 있었냐면, “6개월 전의 나에게 물어볼 수 있게 됐다”는 점이다. 6개월 전의 내가 적어둔 결정의 이유를, 6개월 뒤의 내가 다시 꺼내 볼 수 있다는 것이 가장 큰 장점이다.

아무래도 많은 것들을 기억하기위해서는 어려움이 있기때문에 내가 반드시 기억해야할 것들이 아니라면 바로바로 저장해두고, 다음에 물어볼 수 있어서 믿음직스럽다

유지보수에 대한 솔직한 얘기

여기까지 보면 멋있어 보이지만, 사실 이 폴더의 가장 큰 문제는 유지보수이다.

처음 한 달은 신나서 자료를 다 옮겨 넣었다. 그런데 두 달째부터 안 옮기게 됐다. 회의록은 다음 주 회의 때문에 어쩔 수 없이 옮겼는데, 정책서나 PRD는 한 번 쓴 뒤에 폴더로 옮기는 게 자꾸 잊혔다. 어느 순간 폴더는 옛날 자료가 되어 있었다.

해결은 두 가지로 했다. 하나는 금요일 30분 정리 시간을 캘린더에 잡아둔다. 한 주 동안 위키나 슬랙에 쓴 자료 중에 폴더에 들어가야 할 게 있으면 그 시간에 옮긴다. 다른 하나는 새로 쓰는 자료는 처음부터 이 폴더에서 쓰고 이후에 최신버전을 다시 업데이트하는 방식이다. 처음부터 옮긴다면, 잊어버려서 모으기가 어려운 상황이 발생하기도 했다.

하지만, 지금도 100% 잘 굴러가는 건 아니다. 한 달에 한 번쯤은 “이 폴더 진짜 쓰는 게 맞나” 싶은 순간이 온다. 그래도 이전에 내가 고민하던 것들과 결정된 것들, 최신 버전에 대해서 주기적으로 관리하다보니 어떤 질문이 있더라도 한번 더 체크하고 유관부서 또는 주변 동료들에게 물어볼 수 있다는 점이 큰 장점이라고 생각한다.

회사 자료, 보안, 개인정보

여기서 한 단락은 꼭 따로 빼고 싶다. 이 폴더는 회사 자료의 비식별화된 사본이다. 원본은 위키, 슬랙, 깃허브에 있고, 이 폴더에는 회사, 프로덕트, 고객을 특정할 수 있는 디테일을 다 제거한 형태로 옮긴다. 정책서라면 “어떤 결정 구조였는가”는 남기고, 구체적 매출이나 고객사 이름, 금액은 다 빼는 식이다. 즉 회사의 기본적인 보안이 필요한 부분들은 내 폴더로 옮기지 않고, 프로덕트의 구조와 PM 적으로 확인해야하는 것들만 남기고있다.

이게 단순히 보안 정책 때문만은 아니다. 시간이 지나면 내가 다시 봐도 너무 디테일한 자료는 부담스럽다. 6개월 전 회의록에 적힌 파트너사와 그 회의록을 다시 볼 때 쓸데없이 무겁다. 비식별화는 자료를 가볍게 유지하는 방법이기도 했다.

내가 만든 skill 파일

이 폴더 전체의 동작 방식을 정의하는 CLAUDE.md는 두 번째 뇌의 핵심 파일이다. 길이는 200줄 가까이 되지만, 핵심 골격만 줄이면 이런 모양이다.

work-context/CLAUDE.md:

# work-context 폴더 안내

이 폴더는 내 업무 자료의 비식별화된 사본 모음이다.
원본은 노션, 슬랙, 깃허브에 있고, 여기는 검색, 참조, 결정 추적용이다.

## 폴더별 역할

- `meetings/`: 회의록. 형식은 `meetings/CLAUDE.md` 참고.
- `policies/current/`: 현재 살아있는 정책서.
- `policies/deprecated/`: 폐기된 정책 (히스토리용).
- `prds/shipped/`, `prds/in-progress/`: PRD.
- `user-feedback/`: 유저 피드백 raw 모음.
- `decisions/adr/`: ADR 스타일의 결정 기록.
- `playbook/`: 워크플로우 메모.

## 작업 시 규칙

1. 정책서, PRD를 인용할 때는 반드시 출처 파일 경로를 표시한다.
   예: `policies/current/refund-policy.md` 참고.
2. 회사, 고객을 특정할 수 있는 디테일이 등장하면 출처로 표기한다.
   고객사 이름, 매출, 담당자 실명, 금액 단위 모두 포함.
3. 결정의 "왜"를 묻는 질문은 먼저 `decisions/adr/`을 본다.
   ADR이 없는 결정은 정책서 본문에서 찾고, 그것도 없으면 "ADR 없음"을 표시한다.
4. 카테고리, 태그, 분류 기준을 임의로 추가하지 않는다.
   새 카테고리가 필요해 보이면 사용자에게 먼저 묻는다.
5. 환각 방지: 본문에 명시되지 않은 내용은 "추정"임을 표시하고, "출처"를 반드시 명시한다.

## 자주 쓰는 질문 패턴

- "이 정책의 히스토리는?" → `policies/`와 `decisions/adr/`을 함께 본다.
- "지난 분기 X 주제 회의 결정은?" → `meetings/{지난분기}/`를 다 훑는다.
- "비슷한 PRD가 있었나?" → `prds/shipped/`와 `prds/in-progress/`를 다 본다.

## 결과물 형식

- 모든 응답은 마크다운으로.
- 인용한 파일은 응답 끝에 "참고한 파일" 섹션으로 모은다.
- 추정, 환각 의심 부분은 `[검토필요]` 태그를 단다.

처음엔 다섯 줄이었던 지침들이 점점 많아지고, 클로드로 지침을 잘 정리하는 과정 자체도, 내가 이 도구와 어떻게 사용하여 일해야 하는지를 천천히 배워가는 과정이 아니었을까 싶다.