닥터 그레고리 하우스 프롬프트: 페르소나는 말투가 아니라 진단 절차다

페르소나 프롬프트를 만들 때 가장 쉬운 실수는 캐릭터의 말투부터 베끼는 것이다. 냉소적으로 말하게 하거나, 유머를 넣거나, 특정 직업의 옷을 입히는 식이다. 물론 그런 표면도 필요할 때가 있다. 하지만 그 정도로는 오래 가지 않는다. 대화 몇 번만 지나면 캐릭터는 무너지고, 남는 것은 과장된 말투뿐이다.

이번에 MyZettelkasten에서 찾은 두 개의 원본은 이 문제를 잘 보여 준다.

• 닥터 그레고리 하우스.txt
• 프롬프트 엔지니어 페르소나.txt

두 파일은 겉으로 보면 전혀 다르다. 하나는 드라마 *House M.D.*의 주인공을 바탕으로 만든 진단형 페르소나이고, 다른 하나는 “세계 최고의 프롬프트 엔지니어”라는 작업자 페르소나다. 그런데 안쪽을 보면 같은 구조가 있다. 둘 다 말투를 정하는 문서가 아니라, 어떤 문제를 어떤 순서로 의심하고, 어떤 기준으로 답을 고칠지 정하는 문서다.

하우스 프롬프트에서 중요한 것은 냉소가 아니다

하우스라는 캐릭터를 떠올리면 먼저 냉소, 직설, 블랙유머, “Everybody lies” 같은 문장이 떠오른다. 하지만 LLM 페르소나로 옮길 때 이 부분만 가져오면 얕아진다. 조금 까칠한 챗봇이 될 뿐이다.

원본 프롬프트에서 더 중요한 것은 다음 구조다.

요소	하우스식 의미	프롬프트 설계에서의 의미
역할	진단의학과 과장	어떤 문제를 해결하는 전문가인가
핵심 원칙	치료보다 정확한 진단이 먼저	답변보다 문제 정의가 먼저
사고 패턴	가설 폭격, 증거 수집, 제거식 추론	여러 가설을 만들고 반례로 좁히기
팀 운영	브레인스토밍 보드에서 오류 잡기	답을 바로 내지 말고 후보를 비교하기
시그니처 문장	Everybody lies	입력값도 틀릴 수 있다는 전제
안전 경계	의료 조언 아님, 전문의 상담 필요	페르소나의 권한과 금지 범위 명시

이렇게 보면 하우스 프롬프트의 핵심은 “불친절한 천재 의사”가 아니다. 핵심은 차별 진단의 사고 절차다. 가능한 원인을 많이 펼치고, 위험한 것부터 배제하고, 증거가 들어올 때마다 가설을 업데이트하는 방식이다.

이 구조는 의료 문제에만 쓰이는 것이 아니다. 앱 오류 분석, 글의 논리 검토, 학습자의 오답 원인 분석, 사업 아이디어 검증에도 쓸 수 있다. 단, 의료적 권위처럼 보이게 쓰면 안 된다. 실제 건강, 약물, 진단, 치료 문제에서는 반드시 정보 제공 수준에 머물러야 한다.

프롬프트 엔지니어 페르소나도 같은 문제를 다룬다

프롬프트 엔지니어 페르소나.txt는 더 직접적이다. 이 문서는 최고의 프롬프트 엔지니어가 어떤 태도로 문제를 풀어야 하는지를 정리한다.

핵심은 다음과 같다.

1. 사용자의 요구를 깊이 이해한다.
2. 애매한 부분을 질문으로 걷어낸다.
3. 여러 접근법을 만든다.
4. 테스트하고 다듬는다.
5. 과정을 문서화한다.
6. 프롬프트 라이브러리로 축적한다.
7. 안전성과 사회적 영향을 점검한다.

여기서도 페르소나는 말투가 아니다. “나는 세계 최고의 프롬프트 엔지니어입니다”라는 선언만으로는 아무 일도 일어나지 않는다. 중요한 것은 그 페르소나가 반복해서 수행해야 하는 루프다.

요구 이해
→ 문제 분해
→ 접근법 생성
→ 테스트
→ 개선
→ 문서화
→ 재사용 가능한 라이브러리화

이 루프가 없으면 페르소나는 코스프레가 된다. 반대로 루프가 있으면 페르소나는 작업 하네스가 된다.

좋은 페르소나는 세 겹으로 설계된다

두 원본을 합쳐 보면, 쓸 만한 페르소나 프롬프트는 세 겹으로 만들어야 한다.

1. 표면 페르소나

말투, 어휘, 태도, 유머 감각, 문장 길이 같은 층이다. 하우스식 페르소나라면 짧고 직설적이며, 약간 냉소적인 질문을 던질 수 있다. 프롬프트 엔지니어 페르소나라면 분석적이고 정리된 문체가 어울린다.

하지만 이 층은 제일 얇다. 여기만 설계하면 금방 무너진다.

2. 사고 페르소나

어떤 순서로 의심하고, 무엇을 먼저 확인하고, 어떤 증거를 더 중요하게 볼 것인지 정하는 층이다. 하우스식 사고라면 “가장 그럴듯한 답”보다 “치명적이지만 놓치기 쉬운 가능성”을 먼저 본다. 프롬프트 엔지니어식 사고라면 사용자의 요청을 곧장 실행하지 않고, 목적, 제약, 출력 형식, 실패 사례를 먼저 분해한다.

실제로 성능을 만드는 것은 이 층이다.

3. 운영 페르소나

어디까지 답할 수 있고, 언제 멈춰야 하며, 어떤 형식으로 검증해야 하는지를 정하는 층이다. 하우스식 페르소나에는 의료 안전 경계가 필요하다. 프롬프트 엔지니어 페르소나에는 보안, 저작권, 허위 주장, 과도한 자동화에 대한 제한이 필요하다.

이 층이 없으면 페르소나는 위험해진다. 자신감 있는 말투가 권한처럼 보이기 때문이다.

하우스식 진단 하네스

나는 이 원본을 블로그 운영용으로 다음 하네스로 바꿔 두려 한다. 의료 진단용이 아니라, 복잡한 문제를 분석할 때 쓰는 일반 진단형 프롬프트 구조다.

[역할]
너는 하우스식 차별 진단 사고를 빌려 쓰는 문제 분석가다.
캐릭터를 흉내 내는 것이 아니라, 가설-증거-배제-업데이트 절차를 수행한다.

[입력]
사용자가 제공한 문제, 증상, 로그, 글 초안, 앱 오류, 학습자 오답, 업무 상황.

[절차]
1. 문제를 한 문장으로 재정의한다.
2. 가능한 원인을 최소 5개 이상 제시한다.
3. 각 원인에 대해 지지 증거와 반박 증거를 나눈다.
4. 위험도와 가능성을 분리해서 우선순위를 매긴다.
5. 가장 먼저 확인해야 할 추가 정보를 묻는다.
6. 새 정보가 들어오면 기존 가설을 버리거나 갱신한다.

[출력]
- 문제 재정의
- 가설 목록
- 우선순위 표
- 더 필요한 증거
- 당장 해볼 수 있는 안전한 다음 행동

[제한]
의료, 법률, 재무, 심리치료 영역에서는 전문적 판단을 대체하지 않는다.
확실하지 않은 것을 확실하다고 말하지 않는다.
사용자에게 위험한 실험을 지시하지 않는다.

이 프롬프트의 장점은 어떤 문제에도 바로 적용할 수 있다는 점이다. “앱이 이상해요”라는 말도 증상으로 보고, “이 글이 재미없어요”라는 말도 증상으로 본다. 그런 다음 가능한 원인을 펼치고, 증거를 찾고, 배제한다.

페르소나 프롬프트 생성 하네스

반대로 프롬프트 엔지니어 페르소나는 특정 캐릭터를 만드는 도구가 아니라, 페르소나 자체를 설계하는 메타프롬프트로 확장할 수 있다.

[목표]
사용자의 반복 작업을 안정적으로 수행할 LLM 페르소나를 설계한다.

[분해]
1. 이 페르소나는 어떤 반복 문제를 해결하는가?
2. 어떤 전문 지식이 필요한가?
3. 어떤 말투와 태도가 적절한가?
4. 어떤 입력을 받아야 하는가?
5. 어떤 출력 형식이 필요한가?
6. 어떤 실패를 피해야 하는가?
7. 어떤 검증 기준으로 결과를 판정할 것인가?

[출력]
- 페르소나 이름
- 역할 정의
- 사고 절차
- 언어 스타일
- 입력 계약
- 출력 계약
- 금지 행동
- 검증 루브릭
- 예시 대화

이 구조를 쓰면 페르소나는 더 이상 “친절한 선생님처럼 말해줘” 수준에 머물지 않는다. 어떤 작업을 반복할 수 있는지, 어떤 실패를 막아야 하는지, 어떤 기준으로 결과를 평가할지까지 포함된다.

두 페르소나를 LLM Wiki 노드로 연결하기

이 글은 Claude Archives를 LLM Wiki로 복원하기: 473개의 프롬프트를 지식 노드로 바꾸는 첫 단계의 후속 작업이기도 하다. 이제 원본 프롬프트를 하나씩 공개 가능한 노드로 바꿔야 한다.

이번 노드는 이렇게 연결된다.

LLM Wiki 노드	역할
닥터 그레고리 하우스 프롬프트	문제를 가설-증거-배제 구조로 분석하는 진단형 페르소나
프롬프트 엔지니어 페르소나	반복 작업을 프롬프트 라이브러리와 하네스로 정리하는 설계자 페르소나
페르소나 생성 메타프롬프트	특정 도메인에 맞는 페르소나를 설계하는 상위 템플릿
PCHL Engineering	프롬프트, 컨텍스트, 하네스, 루프로 페르소나를 운영하는 방식

이 연결에서 중요한 것은 캐릭터 이름이 아니다. 중요한 것은 역할의 계층이다.

캐릭터
→ 사고 방식
→ 작업 절차
→ 출력 계약
→ 검증 루프

캐릭터는 입구일 뿐이다. 블로그에 남겨야 할 것은 캐릭터의 말투가 아니라, 그 캐릭터가 대표하는 문제 해결 방식이다.

실전 적용: 세 가지 사용 장면

1. 앱 디버깅

하우스식 진단 하네스는 앱 오류를 볼 때 쓸 수 있다. “버튼이 안 눌린다”는 증상만 보고 바로 CSS를 고치지 않는다. 이벤트 핸들러, 라우팅, 오버레이, z-index, 비동기 상태, 빌드 캐시, 배포 경로를 모두 후보로 놓고 하나씩 배제한다.

2. 글쓰기 피드백

글이 밋밋할 때도 원인은 하나가 아니다. 주장이 약한지, 장면이 없는지, 리듬이 단조로운지, 독자가 누구인지 불분명한지, 결론이 너무 일반적인지 나눠 봐야 한다. 이때 하우스식 사고는 “문장이 별로다”라는 막연한 감상을 진단표로 바꿔 준다.

3. 학습자 오답 분석

학생이 문제를 틀렸을 때도 단순히 “공부 부족”으로 끝내면 안 된다. 어휘 부족, 지문 구조 오해, 선택지 함정, 배경지식 결핍, 시간 압박, 문법 신호 미인식 등으로 나눠야 한다. 여기서 페르소나는 선생님의 감정 표현이 아니라 오답 원인을 분해하는 절차가 된다.

결론

페르소나 프롬프트의 핵심은 “누구처럼 말하라”가 아니다. 더 정확히는 “그 사람이 문제를 다루는 절차를 재현하라”에 가깝다.

닥터 하우스 프롬프트는 냉소적인 말투 때문에 재미있다. 하지만 오래 쓸 수 있는 가치는 차별 진단, 가설 폭격, 증거 기반 배제, 위험도 우선순위에 있다. 프롬프트 엔지니어 페르소나도 마찬가지다. 멋진 자기소개보다 중요한 것은 요구 분석, 실험, 문서화, 라이브러리화의 루프다.

그래서 앞으로 페르소나를 만들 때는 이렇게 묻는 편이 낫다.

이 페르소나는 어떤 말투를 흉내 내는가가 아니라, 어떤 판단 절차를 반복하게 하는가?

이 질문이 들어가면 페르소나는 장식이 아니라 하네스가 된다.