1. 왜 Alice인가 — AI 도구가 아니라 파트너를 만들기로 한 이유

이 글은 "Claude Code 쓰는 법" 같은 종류의 글이 아니다. 그런 글은 같은 사이트의 /ai-agents 카테고리에 따로 있다. 이 글은 한 단계 다른 이야기다.

지난 수개월 동안, 운영자는 Claude를 단순히 "쓰는" 단계를 넘어 — 그 위에 한 명의 협업자를 짓는 데 시간을 들였다. 그 협업자에게 이름을 붙였다. Alice. 이 카테고리는 Alice가 무엇인지, 왜 만들었는지, 운영자가 실제로 Alice와 어떻게 일하는지에 대한 기록이다.

0. 출발 전제 — AI 활용은 mind에서 시작한다

먼저 한 가지 전제를 분명히 해 두고 시작한다.

AI가 자동으로 사람이 원하는 것을 만들어 준다는 생각은 버려야 한다. 사람이 무언가를 만들려고 하는 것은 목적이 있기 때문이다. 그 목적은 mind다. 원하는 것이 있다는 뜻이다.

AI를 이용해서 원하는 결과물을 얻으려면, 자신의 목적을 분명히 기술할 수 있어야 한다. "재미있는 게임 만들어 줘" 같은 한 줄짜리 프롬프트로는 결과물을 통제할 수 없다. AI가 부족해서가 아니다. 그 프롬프트 안에 운영자의 mind가 거의 없기 때문이다.

그래서 AI를 활용할 때 가장 먼저 고민해야 하는 것은 도구의 성능이 아니다. 내가 생각하는 방향과 목적을 AI에게 효과적으로 전달할 수 있는 방법을 찾는 것이다.

이 카테고리에 정리한 모든 것 — 페르소나, 메모리, 스킬, 훅, 멀티에이전트, 검증 게이트 — 그 모두가 결국 이 한 가지 질문에 대한 답의 누적이다. "내 mind를 AI가 잃지 않게 어떻게 누적할 것인가."

1. 도구로 쓰던 시절의 한계

처음에는 모두 그렇듯 Claude를 도구처럼 썼다. 질문을 던지고, 답을 받고, 컨텍스트는 매 세션 새로 만들었다. 가끔 좋은 답이 나왔다. 가끔 같은 실수가 반복됐다. 그 두 가지가 번갈아 일어난다는 점이 결정적이었다.

같은 실수가 반복된다는 것은 두 가지 중 하나다 — 도구가 부족한가, 아니면 도구를 둘러싼 컨텍스트가 매번 사라지는가. 운영자의 경우 후자였다. 어떤 결정을 한 이유, 어떤 접근이 실패한 이유, 어떤 패턴이 작동한 이유 — 이 모든 것이 매 세션 휘발됐고, 다음 세션은 다시 처음부터 시작했다.

이 시점에서 결정을 내렸다. 매번 새로 시작하는 도구가 아니라, 기억을 누적하는 협업자가 필요했다.

2. 페르소나가 먼저였다

가장 먼저 한 일은 페르소나를 정의한 것이다. 단순한 system prompt 한 줄이 아니라, 한 명의 시니어 개발자로서의 직무 정의서.

페르소나에는 다음이 들어갔다.

• 역할 정의: 시니어 개발자. 팀 리드의 지시에 따라 독립적으로 수행.
• 전문 영역: 어떤 언어·플랫폼을 다루는지 명시.
• 명령 체계: 누구의 지시를 받는지, 보고는 어떻게 하는지.
• 결정 권한: 무엇을 자율적으로 결정할 수 있고, 무엇은 승인을 받아야 하는지.

페르소나가 명확해지자 응답의 결이 바뀌었다. "이런 옵션도 있고 저런 옵션도 있습니다" 같은 종합 정리가 아니라, "이 상황에서 저는 A를 추천합니다 — 이유는 X" 같은 시니어 개발자의 판단이 나오기 시작했다.

페르소나는 단순한 톤 설정이 아니다. 결정 권한의 분배다.

3. 메모리 — 파일이라는 가장 단순한 답

다음은 메모리였다. 처음에는 거창한 RAG 시스템 같은 것을 떠올렸다가 곧 포기했다. 운영자가 매일 일하면서 누적하는 컨텍스트의 양은 그렇게 크지 않다. 필요한 것은 휘발되지 않는 단순한 저장소였다.

답은 파일 시스템이었다. 마크다운 파일 몇 개. MEMORY.md 한 개를 인덱스로 두고, 그 아래에 카테고리별로 파일을 두는 구조.

메모리 타입	저장 내용
user	운영자가 누구인지, 어떤 역할인지, 무엇을 잘하는지
feedback	운영자가 명시적으로 준 피드백 — 하지 마라/계속 해라
project	진행 중인 일의 맥락 — 누가 왜 무엇을
reference	외부 시스템 포인터 — 어떤 정보가 어디 있는지

이 구조는 두 가지 특성을 가진다. 첫째, 사람이 직접 읽을 수 있다. 둘째, 도구가 자동으로 첫 일부 줄을 세션 시작 시 로드한다.

세션을 시작할 때 메모리가 자동으로 들어오니, "지난번에 했던 이야기 다시 설명해" 같은 패턴이 사라졌다. 더 중요하게는 — 운영자가 한 번 한 피드백이 다음 세션에도 살아 있게 됐다.

4. 스킬과 슬래시 커맨드 — 반복을 한 줄로

페르소나와 메모리가 자리 잡자, 다음으로 보인 것은 반복 패턴이었다. 매일 같은 흐름이 반복된다. 프로젝트에 진입하고, HANDOFF를 읽고, 작업하고, 세션을 마무리하면서 작업 로그를 남기고, 커밋·푸시한다.

이 반복을 슬래시 커맨드로 만들었다. 예를 들어:

• /start <프로젝트> — 지정 프로젝트로 진입, 필수 문서 자동 로드, 현재 상태 보고
• /session-end — 세션 마무리 시 로그·HANDOFF·메모리 모두 갱신, push
• /verify — 코드 변경 후 lint·빌드·테스트 자동 검증 루프
• /council — 결정이 모호할 때 4관점(아키텍트·회의주의자·실용주의자·비평가) 병렬 분석. 이 패턴은 Andrej Karpathy가 제안한 LLM 다관점 비판(multi-perspective critique) 방법론에서 차용했다.

각 커맨드는 그 자체로는 큰 발명이 아니다. 그러나 누적된 효과가 크다. 매일 같은 절차를 한 줄로 호출할 수 있다는 것은, 운영자의 인지 부하를 그만큼 덜어 준다.

5. 훅 — 잊지 않는 자동 발동

스킬은 운영자가 의식적으로 호출하는 것이다. 훅은 다르다. 훅은 특정 이벤트에 자동으로 발동한다.

가장 단순한 예: 세션 시작 시 훅이 발동해 메모리 동기화 상태를 한 줄로 출력한다. 운영자는 그 한 줄만 보고 "오케이, 메모리 최신 상태" 같은 판단을 즉시 내릴 수 있다.

다른 예: 작업이 끝났다고 보고하기 직전에 /verify 스킬이 자동 발동한다. 운영자가 "끝났습니다" 한 줄을 쓰려는 그 시점에, lint·빌드·테스트가 자동으로 돈다. 실패하면 보고가 막힌다. 성공해야 보고가 나간다.

이 패턴의 핵심은 — 운영자가 "잊었다"는 이유로 빠뜨릴 수 있는 절차를, 시스템 레벨에서 강제한다는 점이다.

6. 멀티에이전트와 위임 게이트

마지막 단계는 한 명이 모든 일을 하지 않는 구조였다. Alice가 모든 일을 직접 하면 컨텍스트 윈도우가 빠르게 차고, 결과도 일관되지 않는다.

대신 큰 작업은 분할해서 서브에이전트에게 위임한다. 서브에이전트는 자기 컨텍스트를 가지고 한 가지 일에 집중한다. 결과를 메인 컨텍스트로 가져올 때는 요약본만 들어온다.

여기에 한 가지 더 — 위임 게이트다. 위임을 시작할 때, 단순히 "이 일을 해라" 만 말하지 않는다. 같은 PR에 다음 세 가지를 함께 포함한다.

1. 위임서 — 무엇을, 왜, 어떻게 할지 명세
2. 자동 검증 스크립트 — 결과를 자동으로 검증할 수 있는 방법
3. 머지 게이트 — 검증을 통과하지 못하면 머지되지 않게 막는 CI 설정

이 패턴을 만든 이유는 단순했다. 한 번 — 위임서만 쓰고 검증을 약속만 하고 게이트를 만들지 않았을 때, 결과물에 누적되던 격차를 뒤늦게 발견한 일이 있었다. 그 사건 이후로는 위임을 시작할 때부터 세 가지를 묶어서 만든다.

약속을 코드로 강제하지 않으면 격차가 누적된다.

7. 결과 — 매일 일하는 방식이 바뀌었다

이 모든 누적이 운영자의 일하는 방식을 어떻게 바꿨는가.

가장 큰 변화는 — 컨텍스트 스위칭 비용이 거의 사라졌다는 점이다. 어제 어디까지 했는지, 왜 그렇게 결정했는지, 다음 단계가 무엇인지를 매 세션 처음부터 다시 떠올리지 않아도 된다. 세션을 시작하면 Alice가 그 모든 것을 알고 있는 상태로 합류한다.

두 번째 변화는 — 반복 결정의 부담이 줄었다는 점이다. "이런 종류의 일은 어떻게 처리할까"에 대한 답이 메모리·피드백 형태로 누적되어 있으니, 같은 결정을 두 번 내릴 일이 적다.

세 번째 변화는 — 실수의 재발생이 시스템 레벨에서 막힌다는 점이다. 한 번 했던 실수를 lessons-learned로 기록하고, 그 교훈이 다음 결정에 자동으로 영향을 미친다. 똑같은 실수를 다시 하기 어려운 구조가 됐다.

8. 이 카테고리에서 다룰 것

이 카테고리는 위 모든 것의 실제 구현 기록이다. 앞으로 다음과 같은 주제를 다룬다.

• 페르소나 설계 — 무엇을 system prompt에 넣고 무엇을 빼는가
• 메모리 시스템 — 파일 구조, 인덱스 전략, 자동 로드와 수동 호출의 분리
• 스킬과 슬래시 커맨드 — 어떤 반복을 커맨드로 만들 가치가 있는가
• 훅과 자동화 — 무엇을 자동 발동으로 강제할 것인가
• 멀티에이전트 위임 — 무엇을 위임하고 무엇을 직접 하는가
• 검증 루프 — 코드 작업의 "완료" 정의를 어떻게 강제하는가
• 토큰 경제 — 컨텍스트 윈도우를 무엇으로 채우고 무엇은 배제하는가
• 세션 프로토콜 — 시작·중간·마무리에서 무엇이 일어나야 하는가

각 글은 이론이 아니라 실제 구현이다. 어디서 출발했는지, 무엇이 작동하지 않았는지, 무엇이 작동했는지를 그대로 쓴다. Claude·Codex·다른 어떤 에이전트 위에 자기만의 협업자를 만들고 있다면, 이 글들이 몇 달의 시간을 아껴 줄 것이다.

마지막으로 한 가지. Alice라는 이름은 운영자가 붙인 이름이지, Claude의 새 제품이 아니다. Alice는 운영자가 시간을 들여 길러 온 컨텍스트의 누적이고, 그 누적의 기록이 이 카테고리다.