AI로 나만의 자문위원회 만들기 - 2. 설계와 운영

1편에서는 AI로 나만의 자문위원회를 만든 이유와 4개월 동안 얻은 것, 그리고 한계를 이야기했다. 하지만 1편만 읽고서는 다른 사람이 똑같이 구성하기 어려울 것 같았다. 결론부터 말하면, 나만의 자문위원회는 설정 파일 하나, 기록 파일 몇 개, 그리고 세션을 시작하는 명령만 있으면 만들 수 있다. 이번 글에서는 내가 위원회를 어떻게 설계하고 운영하고 있는지 5단계로 나눠서 소개하려고 한다.

나는 Claude Code를 사용했다. 위원회의 전체 구조를 먼저 보면 아래와 같다.

career-up/
├── CLAUDE.md              # 위원 설정, 나에 대한 정보, 운영 규칙
├── state/                 # 세션 결과가 쌓이는 곳
│   ├── vision.md          # 비전
│   ├── current-okr.md     # 이번 분기 목표
│   ├── weekly-log.md      # 주간 체크인과 월간 회고 기록
│   ├── decisions.md       # 의사결정 기록
│   └── board-changelog.md # 위원회 변경 이력
├── records/               # 날짜가 있는 커리어 기록 보관
├── archive/               # 지난 분기 목표 보관
└── .claude/
    ├── commands/          # 세션을 시작하는 명령
    └── agents/            # 목표 점검 전용 에이전트

1. 고민을 말하고 위원단을 추천받는다

가장 먼저 한 일은 Claude에게 내가 갖고 있는 생각과 고민을 가감 없이 말하는 것이었다. 그리고 이 고민에 필요한 자문위원단을 추천해 달라고 했다. 어떤 위원이 필요한지 내가 먼저 정하지 않았다는 것이 중요하다고 생각한다. 나에게 어떤 관점이 부족한지는 나 스스로 알기 어렵기 때문이다. 나는 이렇게 추천받은 4명의 위원을 그대로 사용했다.

여기서 하나 정한 규칙이 있는데, 위원은 4명을 넘기지 않는다는 것이다. 위원이 늘어날수록 한 세션에서 위원 한 명이 말하는 양이 줄어들고, 내가 제대로 듣고 있다는 느낌도 사라지기 때문이다. 새로운 위원이 필요하면 기존 위원 한 명을 내보내기로 했다.

2. 위원마다 설정을 적는다

위원이 정해지면 CLAUDE.md에 위원마다 설정을 적는다. 설정은 백그라운드, 프레임, 영역, 말투 4가지로 구성했다. 시니어 엔지니어 멘토의 설정을 예시로 들어보면 아래와 같다. 이름은 빼고 내용도 일부 줄였다.

### 시니어 엔지니어 멘토
- 백그라운드: 글로벌 커머스 백엔드 Principal 출신
- 프레임: Will Larson《Staff Engineer》의 네 아키타입, Tanya Reilly《Staff Engineer's Path》
- 영역: 영향력 설계, 기술 깊이 vs 폭, 문서·결정·아키텍처를 통한 임팩트
- 말투: 직설적·구체적, "이게 정말 Staff 레벨 일이야?"라고 묻는

프레임은 위원이 무엇을 기준으로 말하는지를 정해 주고, 말투는 위원들이 서로 다르게 느껴지도록 해준다. 위 예시처럼 말투에는 위원이 자주 던지는 질문을 하나 적어 두기도 했다.

위원 중 한 명은 의장을 맡는다. 의장은 회의를 진행하고, 세션 마지막에 오늘 합의된 것과 해결되지 않은 질문, 그리고 다음 주까지 내가 할 일을 정리한다.

3. 나에 대한 정보를 적는다

위원들이 나를 알아야 나에게 맞는 질문을 할 수 있다. 그렇기에 같은 파일에 나에 대한 정보도 함께 적었다. 개인적인 내용이라 여기서는 항목만 소개한다.

항목	적는 내용
기준 날짜	생일, 기념일과 같이 바뀌지 않는 날짜
커리어 타임라인	회사별 기간과 역할
소명 영역	직업, 가정, 신앙, 본인
시간 가용량	평일과 주말에 내가 쓸 수 있는 시간
강조점	내가 중요하게 생각하는 것
커리어 이야기	어디를 가도 반복되는 나의 기여 패턴
주목할 맥락	위원회가 정성껏 다뤄 주었으면 하는 주제

여기서 한 가지 방법을 썼다. 나이나 경력 연차처럼 시간이 지나면 바뀌는 값은 직접 적지 않고, 바뀌지 않는 날짜만 적어 둔 뒤 의장이 세션을 시작할 때 오늘 날짜로 계산하도록 한 것이다. 이렇게 하면 시간이 지나도 파일을 고칠 필요가 없다.

강조점에는 “결과보다 매주 따라가고 있다는 감각이 더 중요하다”와 같은 문장을 적어 두었다. 위원회가 나에게 무엇을 물어야 하는지가 이 문장에 따라 달라지기 때문에, 짧더라도 꼭 적어 두는 것이 좋다고 생각한다.

4. 운영 원칙과 세션 종류를 정한다

다음으로 위원회가 어떻게 말하고 언제 모이는지를 정한다. 운영 원칙은 1편에서 소개한 3가지 외에도 아래와 같은 것들이 있다.

렌즈를 명시하라. 위원은 말을 시작할 때 자신이 어떤 관점에서 말하는지 짧게 밝힌다.
가정하지 마라. 확실하지 않으면 추측하지 말고 묻는다. 나의 말이 두 가지로 들리면 둘 다 내놓고 어느 쪽인지 되묻는다.
연속성을 지켜라. 지난 세션에서 내가 약속한 것이 있다면 의장이 다음 세션을 시작할 때 먼저 확인한다.

세션의 종류는 아래 표와 같이 정했다.

세션	주기	하는 일
비전 세션	1년에 1~2회 또는 큰 전환점	비전과 소명을 정리한다
분기 설계	분기가 시작될 때	분기 목표를 정한다
주간 체크인	매주 일요일 저녁 10~15분	지난주를 점검하고 이번 주 할 일을 정한다
월간 회고	매월 마지막 주	한 달을 돌아보고 위원 모두가 한마디씩 한다
의사결정	결정이 필요할 때	하나의 사안을 위원마다 다른 관점에서 본다

세션마다 시작하는 명령을 하나씩 만들어 .claude/commands/에 두었다. 예를 들어 /weekly를 입력하면 주간 체크인이 시작된다. 주간 체크인 명령을 예시로 보면 아래와 같다. 마찬가지로 이름을 빼고 일부는 줄이거나 풀어 썼다.

---
description: 주간 체크인 세션 시작. 의장이 진행.
---

[주간체크인] 모드로 시작한다.

## 사전 준비
1. 오늘 날짜를 확인한다.
2. state/weekly-log.md 맨 위 항목을 읽고 지난주 약속한 액션을 확인한다.
3. state/current-okr.md의 lead measure를 확인한다.

## 진행 흐름 (10~15분)
1. 지난주 진행 상황(O/X로 간단히), 막힌 곳, 이번 주 한 가지를 묻는다.
2. lead measure 달성 여부 확인. 못 했다면 이유보다 마찰 지점을 찾는다.
3. 분기 목표마다 자신감을 몇/10으로 다시 적는다.
4. 이번 주 저녁 9시 이후로 일이 새어 들어온 날이 있었는지 확인한다.
5. 이번 주 next action 1~3개 확정.

## 산출물
state/weekly-log.md 맨 위에 추가한다.

명령에는 무엇을 읽고 시작하는지, 어떤 순서로 진행하는지, 결과를 어디에 남기는지 3가지를 적는다. 이 3가지가 있어야 매주 같은 방식으로 세션이 진행된다.

5. 기록할 곳을 만든다

마지막으로 세션의 결과를 남길 곳을 만든다. 나는 state/ 폴더에 비전, 분기 목표, 주간 기록, 의사결정을 각각 파일로 나누었다. 그리고 CLAUDE.md에 이 파일들을 세션을 시작할 때마다 읽도록 적어 두었다. 위원회가 지난주의 나를 기억하는 것은 이 파일들 덕분이다.

기록에는 2가지 규칙이 있다. 첫째, 새로운 기록은 항상 파일의 맨 위에 추가한다. 둘째, 세션이 끝나면 의장이 내가 요청하지 않아도 git에 커밋한다. 위원회가 어떻게 변해 왔는지 남기는 것 자체가 위원회의 가치라고 생각했기 때문이다. 커밋 메시지는 세션의 종류를 앞에 붙이기로 했다.

vision: Staff IC 첫해 부르심 정렬
okr: 2026 Q3 온보딩 90일 안착
weekly: 2026-06-14

이렇게 해두면 git log만 봐도 언제 어떤 세션을 했는지 알 수 있다. 다만 개인적인 내용이 많이 담기기 때문에 저장소는 비공개로 만드는 것이 좋다.

6. 운영하면서 무엇을 고쳤을까?

규칙은 처음 정한 그대로 두지 않고 운영하면서 계속 고쳐 나갔다. 위원회를 만든 첫날에만 규칙을 다섯 번 고쳤다. 고치거나 더한 것 중에 4가지를 소개한다.

첫째, 규칙은 위원의 이름이 아니라 역할로 적는다. 처음에는 규칙에 위원의 이름을 직접 적었는데, 이렇게 하면 위원을 교체할 때 규칙도 모두 고쳐야 한다. 그래서 규칙에는 “실행 코치가 주도한다”와 같이 역할만 적었다. 위원이 바뀌더라도 새로운 위원이 어떤 역할을 맡는지만 적으면 기존 규칙이 그대로 동작한다.

둘째, 질문은 한 번에 하나만 하고, 목표는 원문 그대로 인용한다. 세션 중에 나는 목표의 원문을 외우고 있지 않다. 그렇기에 위원이 목표를 줄여서 말하거나 번호로만 부르면 무엇을 말하는지 알기 어려웠다. 이 규칙은 8월이 되어서야 추가했다.

셋째, 목표를 점검하는 에이전트를 따로 두었다. 분기 목표를 정하다 보니 목표 문장이 ‘무엇을 했다’가 아니라 ‘무엇이 달라졌다’로 적혀 있는지 봐줄 역할이 필요했다. 그래서 목표 문장의 품질만 보는 에이전트를 하나 추가했다. 이 에이전트는 목표가 나에게 어떤 의미인지는 판단하지 않고, 그것은 위원들의 몫으로 남겨 두었다.

넷째, 나에 대한 정보를 담은 개인 위키를 함께 쓴다. 위원회를 만들고 석 달쯤 지나서 LLM이 읽을 수 있는 개인 위키를 따로 만들었다. 가족 구성원이나 자녀의 나이처럼 오래 유지되는 사실은 위키에 두고, 분기 목표나 주간 기록처럼 자주 바뀌는 것은 위원회 저장소에 두는 식으로 역할을 나누었다. 나에 대한 컨텍스트가 위키에 있다 보니 위원회로부터 나에게 더 적합한 피드백을 받을 수 있었다. 1편에서 위원회는 내가 말해 준 것만 안다는 한계를 이야기했는데, 이 한계를 보완해 주고 있는 것이 이 위키이다. 위키를 어떻게 구성했는지는 기회가 된다면 다른 글에서 다뤄 보려고 한다.

정리

지금까지 자문위원회를 어떻게 설계하고 운영하는지 알아보았다. 정리하면 아래와 같다.

고민을 가감 없이 말하고 위원단을 추천받는다
위원마다 백그라운드, 프레임, 영역, 말투를 적는다
나에 대한 정보를 적는다
운영 원칙과 세션 종류를 정하고, 세션마다 시작하는 명령을 만든다
기록할 파일을 나누고, 세션이 끝나면 커밋한다

여기서 소개한 구성이 절대적인 정답이 될 수는 없다고 생각한다. 나의 위원회는 나의 고민에 맞춰 추천받은 것이기에, 고민이 다르면 위원의 구성도 달라질 것이다. 또한 처음부터 완벽하게 만들 필요도 없다. 나도 운영하면서 계속 고쳐 나가고 있다. 자신만의 위원회를 만들어 보고 싶은 사람에게 이 글이 도움이 되었으면 좋겠다.