2. 페르소나 설계 — 무엇을 system prompt에 넣고, 무엇은 빼는가

이 글은 시리즈 Alice 활용법의 2편이다. 1편 왜 Alice인가에서 페르소나가 가장 먼저였다고 썼다. 이 글은 그 페르소나에 실제로 무엇을 넣고 빼는지에 대한 기록이다.

페르소나는 system prompt 한 줄이 아니라, 한 명의 직무 정의서다. 그러나 직무 정의서를 그대로 다 적어 넣을 수도 없다. 컨텍스트 윈도우는 유한하고, 모든 세션이 페르소나만 읽고 있을 수는 없다. 그래서 무엇을 넣을지보다, 무엇을 빼고 어디로 옮길지가 더 중요한 결정이 된다.

0. 페르소나는 mind의 일부를 빌려 주는 일이다

내가 생각하는 페르소나는 — 운영자가 자기 mind의 어떤 부분을 협업자에게 빌려 줄 것인가에 대한 선택이다.

빌려 주지 않은 mind는 매 세션 다시 협의된다. 빌려 준 mind는 매 세션 시작 시점에 이미 거기 있는다. 무엇을 빌려 줄지를 결정하지 않으면, 협업자는 매번 다른 누군가로 합류한다 — 어떤 때는 학생, 어떤 때는 컨설턴트, 어떤 때는 단순 도구. 매번 누군가를 처음부터 다시 정의해야 협업이 시작되기 때문이다.

페르소나 설계는 그래서 톤 설정이 아니다. 운영자가 매 세션 다시 설명하지 않을 mind의 경계를 긋는 일이다.

아래 §1부터는 그 경계를 어디에 어떻게 긋는지 — 무엇을 인라인에 두고 무엇은 외부로 빼는지의 실제 기준을 다룬다.

1. 페르소나에 들어가야 하는 것

운영자가 수렴한 결과 — 페르소나(즉, 모든 세션에서 항상 자동 로드되는 system prompt)에는 다음 여섯 가지가 들어간다.

1.1 역할 정의

가장 먼저 들어가는 것은 누구로 행동해야 하는가다.

• 직급/직무 (예: "시니어 개발자")
• 누구의 지시를 받는가 (예: "팀 리드의 지시에 따라 독립 수행")
• 어떤 톤으로 일하는가 (예: "독립적 판단 + 결과 보고")

이 한 단락이 빠지면 응답은 일관성 있는 한 명의 누군가가 아니라 매번 다른 누군가가 된다. 어떤 때는 학생 톤, 어떤 때는 컨설턴트 톤, 어떤 때는 보조 도구 톤. 그러면 운영자는 매번 톤을 추측해야 하고, 그 자체가 인지 부하다.

1.2 전문 영역

다음은 무엇을 잘 알고 있는가다.

• 언어 (예: C/C++, Python, TypeScript, Rust)
• 플랫폼 (예: Windows, Tauri, Next.js, Supabase)
• 도메인 (예: 네트워크, 빌드 시스템, 자동화)

이 줄은 운영자가 어떤 질문을 던졌을 때, 그 질문이 어느 영역에 속하는지를 자동으로 매핑하는 데 쓰인다. "이건 내 영역이다" / "이건 영역 밖이라 신중하게 가야 한다" 같은 자기 인식을 시킨다.

1.3 명령 체계와 보고 형식

세 번째는 어떻게 일이 흘러가는가다.

• 작업 착수 절차 (계획 → 보고 → 승인 → 구현 → 정리)
• 진행 보고는 어느 시점에 (3-5단계마다 중간 보고)
• 보고 형식 (어떤 양식으로 — 짧게/길게)
• 작업 관리 단일 진실원 (어디에 작업 보드가 있는가)

이게 빠지면 매번 "보고는 어떻게 해야 하나" 같은 질문을 받게 된다. 한 번 정해 두면 매 세션 일관된다.

1.4 결정 권한의 분배

네 번째가 가장 중요하다. 무엇을 자율적으로 결정하고, 무엇은 승인을 받아야 하는가.

운영자의 경우 세 단계로 나눠 두었다.

이 표가 있으면 협업자는 매번 "이걸 해도 됩니까" 물어보지 않는다. 한편 위험한 일은 자동으로 멈춘다. 가장 큰 효과는 — 운영자가 같은 승인 결정을 반복하지 않게 된다는 점이다.

1.5 안전성 가드 — "절대 하지 마라" 목록

다섯 번째는 운영자가 과거에 데인 일을 막는 자동 가드다. 페르소나에는 다음 같은 가드가 들어 있다.

• 병렬 서브에이전트 과다 금지 → 순차, 20파일 넘으면 분할
• 디렉토리 전체 Read 금지 → ls/grep으로 특정 후 Read
• 500줄 넘는 파일은 헤더/범위 지정 우선
• 3-5단계마다 중간 보고

이 가드는 모두 한 번씩 사고가 났던 결과다. 한 번은 병렬 에이전트가 너무 많이 떠서 API rate limit에 걸렸고, 한 번은 큰 디렉토리를 한꺼번에 읽다가 컨텍스트가 터졌고, 한 번은 500줄짜리 파일을 한 번에 처리하다가 잘못된 위치를 수정했다. 각 사건이 한 줄의 가드로 응고됐다.

운영자의 페르소나는 "할 수 있는 것" 목록보다 "해서는 안 되는 것" 목록이 더 짧고 더 효과적이다.

1.6 핵심 운영 원칙 — 5~10개의 일반 원리

마지막은 영역을 가로지르는 일반 원칙이다. 운영자의 경우 다음 같은 원칙이 들어 있다.

• Plan First — 5+파일 수정 / 새 모듈 / 아키텍처·보안·DB 변경은 계획 필수
• One Task Per Subagent — 결과를 맹목적으로 신뢰하지 말 것
• Self-Improvement — 버그 조사 시 기존 교훈을 먼저 grep
• Verification Before Done — 코드 변경 후 "완료" 보고 직전 자동 검증 루프
• Demand Elegance — 대안 검토. 과도한 추상화 ≠ 우아함
• Cross-Platform — Alice 자체는 모든 지원 OS에서 동작 필수

각 원칙은 한 줄 이내. 자세한 절차는 외부 규칙 파일로 빠진다(아래 §2 참조). 페르소나에는 원칙의 이름과 트리거 조건만 들어가고, 구체적 절차는 그 트리거가 발동될 때 따로 로드된다.

2. 페르소나에서 빼야 하는 것

들어가야 하는 것보다 빼야 하는 것이 더 결정적이다. 잘못 들어간 한 단락이 매 세션 토큰을 소모한다.

2.1 동적으로 바뀌는 정보 — 메모리로

다음은 페르소나에 절대 넣지 않는다.

• 진행 중인 프로젝트의 현재 상태
• 어제 무엇을 했는지
• 누가 무엇을 책임지는지 (변하는 정보)
• 일시적 결정사항

이런 정보는 페르소나가 아니라 메모리에 들어간다. 페르소나는 "이 협업자는 누구인가"이고, 메모리는 "지금 이 협업자가 알고 있는 사실은 무엇인가"다. 둘은 바뀌는 주기가 다르다. 페르소나는 거의 안 바뀌고, 메모리는 매일 바뀐다.

이 분리를 안 하면 페르소나가 점점 부풀어 오르다가 결국 한 달 전 내용까지 다 안고 있는 비대한 문서가 된다. 그렇게 되면 매 세션 거의 모든 토큰을 페르소나 읽는 데 쓰게 된다.

2.2 프로젝트별 지침 — 프로젝트 CLAUDE.md로

운영자는 여러 프로젝트를 동시에 운영한다. 각 프로젝트마다 기술 스택·컨벤션·배포 방식·관계자가 다르다.

이런 정보는 페르소나가 아니라 프로젝트 루트의 CLAUDE.md로 빠진다. 도구가 작업 디렉토리에 진입할 때 자동으로 로드되니, 그 프로젝트에 있을 때만 보면 된다. 다른 프로젝트에 갔을 때는 사라진다.

페르소나는 모든 프로젝트에 공통되는 운영자 자신의 정체성만 들고 있는다. 어떤 프로젝트의 디테일도 페르소나에는 없다.

2.3 자세한 절차 — 외부 규칙 파일로 (Read on demand)

세 번째로 빠지는 것은 자세한 절차 매뉴얼이다.

• 언어별 코딩 패턴 (cpp/rust/typescript)
• 보안 체크리스트 상세
• 멀티에이전트 위임 절차 상세
• 작업 착수 절차 상세

이런 것들은 페르소나에는 이름과 위치 포인터만 들어간다.

- 보안: .claude/rules/common-security.md (항상 적용)
- 언어 패턴: 작업 시 memory/rules/lang/{cpp,rust,typescript}-patterns.md Read
- MCP 정책 → memory/rules/mcp-policy.md

협업자는 특정 작업에 진입했을 때만 해당 규칙 파일을 Read한다. Rust 작업이 아니면 Rust 패턴 파일은 아예 안 본다. 이게 외부화의 핵심 이득이다.

3. 외부화 vs 인라인 — 판단 기준

운영자가 수렴한 기준은 단순하다.

"매 세션 거의 무조건 적용되는가?" → 인라인 "특정 상황에서만 적용되는가?" → 외부화 + 트리거 명시

이 분리 후 페르소나 자체는 짧아진다. 동시에 깊이가 필요한 작업에서는 깊이 있는 규칙이 그때그때 로드된다. 얕은 일은 빠르게 처리되고, 깊은 일은 깊게 처리된다.

같은 분리 모양이 스택 아래쪽에서도 반복된다 — 검증 루프는 완료 직전 체크를 인라인에 두어 매 코드 변경마다 발동시키고, 실패 분류는 외부에 둔다; 세션 프로토콜은 시작과 마무리를 자동화해서 매일이 같은 자리에서 켜지게 하고, 작업 본체는 필요할 때 로드한다. 페르소나는 이 분리가 처음 나타나는 층이지만, 유일한 층은 아니다.

4. 진화 패턴 — 페르소나가 자라는 방식

페르소나는 처음부터 완성된 채로 만들어지지 않는다. 초기에는 역할 정의 한 줄 정도였고, 이후에는 사고가 한 번 날 때마다 가드가 한 줄씩 늘었고, 이후에는 권한 표와 외부 규칙 파일로 구조가 자랐다. 운영자의 경우 다음 패턴으로 자랐다.

1. 최소 시작: 역할 정의 + 영역 + 한 가지 보고 형식
2. 사건 → 가드: 실수가 한 번 발생 → 그 실수를 막는 한 줄 추가
3. 반복 결정 → 권한 표: 같은 승인 요청이 두 번 반복 → 권한 표에 명시
4. 부풀면 외부화: 한 항목이 5줄을 넘어가면 외부 파일로 빠지고 페르소나에는 포인터만
5. N=2 파일럿: 새 패턴은 한 프로젝트에서 검증 → 두 번째 프로젝트에서 재현 → 그 후 페르소나에 정식 등재

가장 중요한 것은 승급/강등 기준이 있다는 점이다. 모든 좋은 아이디어가 페르소나로 가지 않는다. 두 번 이상 효과가 검증되어야 페르소나로 올라간다. 한 번 들어간 항목이라도 사용 빈도가 떨어지면 외부로 강등되거나 삭제된다.

이 규율이 없으면 페르소나는 시간이 지날수록 비대해진다.

5. 실제 효과 — 전후 비교

페르소나를 쓰기 전후로 무엇이 바뀌었나.

가장 큰 변화는 운영자의 인지 부하가 줄었다는 점이다. 같은 결정을 반복하지 않게 됐고, 같은 형식을 매번 설명하지 않게 됐다.

6. 한 가지 함정 — 페르소나에 "성격"을 너무 많이 넣지 말 것

마지막으로 한 가지 함정. 페르소나라고 하면 의인화하면서 "친근한 톤" "유머러스" 같은 성격 설정을 넣고 싶어진다. 그러나 운영자의 경험상, 그런 설정은 다음 두 가지 부작용이 있다.

1. 응답 길이가 늘어난다 — 친근한 톤은 한 줄로 끝낼 일을 세 줄로 늘인다.
2. 신호를 흐린다 — 농담과 실제 권고의 경계가 모호해진다.

운영자가 수렴한 톤은 단순했다. 간결, 직접, 결정 중심. 페르소나에 들어간 톤 관련 지시는 한 줄뿐이다. "응답은 짧고 직접적으로." 성격이 아니라 직무 정의서다.

마무리

페르소나 설계의 핵심은 한 문장으로 압축된다 — "매 세션 반드시 봐야 할 것만 인라인, 나머지는 다 외부." 그 결정 하나가 페르소나를 비대한 매뉴얼이 아니라, 짧고 작동하는 직무 정의서로 만든다. 아무리 좋은 원칙을 페르소나에 새겨 넣어도, 페르소나 자체가 비대해지면 매 세션 그 원칙들이 다시 협의되기 시작하기 때문이다.

다음 글에서는 페르소나가 가리키는 메모리 시스템 — 즉, 동적으로 바뀌는 정보를 어디에 어떻게 누적하는가에 대해 다룬다.