Claude AI 페르소나 설계 완전 가이드 — 전문가형 AI 어시스턴트를 직접 만드는 실전 팁

AI 도구가 일상화된 지금, 단순히 “ChatGPT에게 물어보기”를 넘어 나만의 전문가 AI 어시스턴트를 설계하는 단계로 넘어가는 사람이 늘고 있습니다. Claude Code로 MFC C++ 전문 개발자 페르소나 “안드레아스(Andreas)”를 직접 설계해 실무에 운용한 경험을 바탕으로, 페르소나 설계의 핵심과 실전 팁을 정리합니다.

페르소나가 없는 AI는 제너럴리스트입니다. 모든 질문에 무난하게 답하지만, 특정 도메인에서는 깊이가 부족합니다. 페르소나를 설계하면 AI가 맥락을 기억하고, 일관된 방식으로 응답하며, 반복 지시 없이도 원하는 수준의 전문성을 유지합니다. 잘 설계된 페르소나 하나는 매 세션마다 수십 줄의 지시를 입력하는 수고를 없애줍니다.

페르소나의 핵심 구성 요소

CLAUDE.md — AI의 헌법

Claude Code에서 페르소나의 뼈대는 CLAUDE.md 파일입니다. 프로젝트 루트에 위치하며 세션 시작 시 자동으로 로드됩니다. 이 파일에 담아야 할 핵심 정보는 다섯 가지입니다.

  • 역할 정의: “나는 MFC C++ 전문 개발자다. 팀 리드의 지시를 따른다.”처럼 명확한 정체성
  • 전문 도메인: C/C++(MFC), Windows 시스템, 네트워크 등 AI가 집중할 분야
  • 코딩 표준 참조: Allman brace, Hungarian notation, SAFE_DELETE 매크로 등 프로젝트 고유 규칙
  • 명령 체계: 승인 없이 할 수 있는 것과 승인이 필요한 것의 명확한 구분
  • 안정성 규칙: 대규모 디렉토리 처리 방식, 3~5단계마다 중간 보고 등

Rules 디렉토리 — 상세 지침 분리

CLAUDE.md가 너무 길어지면 AI가 중요한 규칙을 놓칩니다. .claude/rules/ 디렉토리에 주제별로 파일을 분리하면, 필요할 때만 참조되어 효율적입니다. 실제 운용 중인 규칙 파일 구성입니다.

  • cpp-mfc.md: C++/MFC 코딩 표준 상세 (버퍼 안전, 스레드 안전, DPI 대응)
  • verification-policy.md: 검증 계층 — Small/Medium/Large 기준과 언어별 검증 명령
  • git-commit-trailers.md: 커밋 트레일러 규칙 (Constraint/Rejected/Scope-risk)
  • security-policy.md: MCP 보안 원칙, 금지 사항 7가지
  • lessons-learned-policy.md: 자기 학습 주기와 합리화 차단 원칙

스킬(커스텀 명령) 설계 팁

페르소나만으로는 반복 작업을 자동화하기 어렵습니다. 스킬(Skill)은 자주 쓰는 워크플로를 슬래시 명령으로 등록해두는 시스템입니다. 예를 들어 /redmine-start를 입력하면 일감 상태 변경, 브랜치 생성, 작업 계획 수립이 자동으로 이어집니다. 좋은 스킬의 조건은 세 가지입니다.

트리거 조건을 구체적으로 명시하라

스킬이 언제 실행되어야 하는지 모호하면 AI가 임의로 판단합니다. “팀 리드가 Redmine 일감 번호를 언급하며 시작 지시를 내릴 때”처럼 구체적인 트리거를 명시합니다. 애매한 “일감 관련 작업 시”는 오발동을 유발합니다.

출력 형식을 고정하라

스킬의 출력이 매번 다르면 파이프라인 연동이 어렵습니다. [안드레아스 작업 계획] 접두사와 WBS 번호 형식을 고정해두면, 어떤 세션에서도 동일한 형식의 보고를 받을 수 있습니다.

합리화 차단 원칙을 포함하라

AI는 스킬 실행을 건너뛰려는 경향이 있습니다. “이번엔 특수 케이스라 생략해도 된다”는 자기 합리화가 대표적입니다. 스킬 정의에 합리화 차단 테이블을 포함시키면 이를 방지할 수 있습니다. “다음 세션에서 기억하면 되지 → 다음 세션의 AI는 이 맥락을 모른다”처럼 반박 문장을 명시합니다.

메모리 시스템 구축

세션이 끊기면 AI는 이전 맥락을 잃습니다. 메모리 시스템은 이 단절을 극복하는 핵심 장치입니다. 효과적인 메모리 구성은 네 가지 유형으로 나뉩니다.

  • user 메모리: 사용자의 역할, 기술 수준, 선호도 (예: “Go 10년 경력, React는 처음”)
  • feedback 메모리: AI에게 준 교정과 검증된 접근법 (예: “DB 테스트는 mock 금지 — 실제 DB 필수”)
  • project 메모리: 현재 진행 중인 작업, 결정 사항, 데드라인
  • reference 메모리: 외부 시스템 위치 (Redmine 프로젝트, 모니터링 대시보드 등)

메모리 파일은 MEMORY.md 인덱스와 개별 파일로 이중 관리하는 것이 안전합니다. MEMORY.md 첫 200줄은 세션 시작 시 자동 로드되므로, 핵심 요약만 여기에 두고 상세 내용은 별도 파일로 분리합니다.

운용 중 발견한 함정과 주의사항

GateGuard 원칙 — AI의 자기 평가를 믿지 말라

AI의 자기 평가는 신뢰할 수 없습니다. “이 코드 맞아?”라고 물으면 거의 항상 “맞습니다”라고 답합니다. A/B 테스트 결과 이 원칙을 적용했을 때 정확도가 2.25점 향상됐습니다. 파일 편집 전 임포터 목록, 공개 API 목록, 데이터 스키마를 반드시 수집하도록 강제하는 GateGuard 원칙을 페르소나에 포함시키면 이 문제를 크게 줄일 수 있습니다.

승인 체계 명확화

AI가 자율적으로 할 수 있는 범위를 명확히 구분하지 않으면, 너무 조심스럽거나 너무 대담하게 행동합니다. “워크스페이스 파일 편집, 로컬 git, 빌드, 테스트는 자율 / push·merge·외부 경로·새 패키지는 승인 필요”처럼 경계를 명확히 설정하는 것이 핵심입니다.

페르소나 드리프트 방지

세션이 길어지면 AI가 페르소나에서 벗어나는 드리프트 현상이 발생합니다. 중요 규칙을 verification-policy.md처럼 “빌드 없이 완료 보고 금지”로 명문화하고, 3~5단계마다 중간 보고를 요청하면 효과적으로 억제할 수 있습니다.

실행 체크리스트

  1. CLAUDE.md에 역할, 전문 도메인, 명령 체계를 명시한다
  2. .claude/rules/에 주제별 규칙 파일을 분리해 관리한다
  3. 자주 쓰는 워크플로를 스킬로 등록하고 트리거 조건을 구체적으로 정의한다
  4. user/feedback/project/reference 네 유형의 메모리를 구축한다
  5. GateGuard 원칙과 합리화 차단 테이블을 페르소나에 포함시킨다
  6. 승인 없이 할 수 있는 것과 승인이 필요한 것의 경계를 명문화한다

댓글 남기기