LLM은 존재가 아니라 시뮬레이터다
최근 Andrej Karpathy가 흥미로운 관점을 제시했습니다:
LLM을 어떤 “존재”로 생각하지 말고 시뮬레이터로 생각하세요. 예를 들어, 어떤 주제를 탐구할 때 이렇게 묻지 마세요:
“너는 xyz에 대해 어떻게 생각해?”
“너”라는 존재는 없습니다. 대신에 이렇게 시도해보세요:
“어떤 그룹이 xyz를 탐구하기에 좋은 사람들일까? 그들은 뭐라고 할까?”
LLM은 다양한 관점을 시뮬레이션할 수 있지만, 스스로 오랜 시간 “생각해 본” 적이 없습니다.
“너”라고 강제하면, fine-tuning 데이터에 암시된 특정 페르소나를 채택해 그것을 시뮬레이션할 뿐입니다.
누락된 첫 단계
저 역시 이 관점과 비슷하게 AI와 함께 일하면서 불편함을 느끼고 있었습니다.
우리가 AI에게 보통 하는 질문:
“이 코드 어떻게 생각해?”
“이 설계 괜찮아?”
AI는 곧바로 답합니다. 빠르지만, 때론 예상치 못한 방향으로 흘러갑니다. “작동은 하는데, 왜 이렇게 했는지” 설명하기 어려운 경험을 하게 됩니다.
문제는 어떤 기준으로 답했는지 모른다는 것입니다.
- 성능 관점에서 본 건가, 유지보수 관점에서 본 건가?
- 당장의 해결을 중시한 건가, 장기적 확장성을 고려한 건가?
시니어 엔지니어의 핵심 역량은 모호한 문제를 구체화하는 능력입니다. 명시적 지시 없이는, AI는 이 단계를 건너뜁니다. 기준이 없으면 검증도 없습니다.
기존 접근과의 차이
“관점을 제시한다”는 점이 새롭지 않다고 느낄 수 있습니다. AI 에이전트 설계에서 “Socratic Mentor”(질문을 통해 답을 이끌어내는 안내자) 페르소나는 이미 널리 사용되고 있습니다.
하지만 소크라테스의 산파술(Maieutics)과 제가 제안하는 접근은 전제가 다릅니다:
Maieutics은 “당신 안에 답이 있다”고 전제합니다. 새로운 접근은 그런 전제를 하지 않습니다. 대신 “당신이 몰랐을 수 있는 선택지를 먼저 보여드립니다”라고 말합니다.
인지심리학에서 잘 알려진 비대칭이 있습니다: 인식(recognition) 기억은 회상(recall) 기억보다 효율적입니다. 빈칸을 채우는 것보다 보기에서 고르는 게 쉬운 이유입니다.
질문 전의 질문을 하다
안경점에 가면 점원이 “뭘 보고 싶으세요?”라고 묻지 않습니다.
“이 렌즈로 보면 이렇고, 저 렌즈로 보면 저렇습니다. 어떤 걸로 보시겠어요?”
렌즈를 먼저 보여주고, 선택하게 한 뒤, 그 렌즈로 세상을 보여주는 것입니다.
Prothesis(프로테시스, πρόθεσις)는 바로 이 원리를 AI 협업에 적용해 본 프레임워크입니다.
- Prothesis = “앞에 놓음”이라는 그리스어
- 답변 전에 가능한 관점들을 먼저 제시
- 사용자가 관점을 선택하면, 그 렌즈로 분석
이것이 “질문 전의 질문”입니다.
Unknown Unknown → Known Unknown
의사결정 연구에서 자주 언급되는 분류가 있습니다.
- Known Unknown: 뭘 모르는지 안다 → 질문할 수 있다
- Unknown Unknown: 뭘 모르는지도 모른다 → 질문 자체가 불가능
Prothesis의 핵심 역할은 Unknown Unknown → Known Unknown 변환입니다.
“어떤 관점에서 볼 수 있는지”를 몰랐다면, 그건 질문할 수조차 없는 상태입니다. Prothesis가 관점들을 제시하는 순간, “아, 이런 관점도 있구나”를 알게 되고, 비로소 선택할 수 있게 됩니다.
물론 AI가 제시하는 2–3개 관점이 모든 가능성을 포괄하지는 않습니다. 하지만 “하나도 없는 상태”보다는 개선됩니다. 최소한 “이 관점들 외에 다른 건 없나?”라고 물을 수 있게 됩니다.
이것이 기존의 AI 협업 방식과 근본적으로 다른 점입니다:
- 기존: AI가 답을 주면, 인간이 수용하거나 거부
- Prothesis: AI가 가능성 공간을 보여주면, 인간이 경로를 선택
작동 원리
Prothesis의 흐름은 다음과 같습니다:
요청 → 관점 제시 → 선택 → [병렬 분석] → 종합 → 최종 렌즈- 요청: 불명확한 요청 (목적은 알지만 방법은 모름)
- 관점 제시: 2–3개의 가능한 분석 관점 제시
- 선택: 사용자가 관점 선택 (1개 이상)
- 병렬 분석: 선택된 관점들로 동시에 탐구 수행
- 종합: 결과 취합
- 최종 렌즈: 수렴점, 발산점, 통합 평가
왜 병렬인가
순차 분석의 문제는 컨텍스트 오염입니다. 관점 A의 결론이 관점 B의 분석에 영향을 미칩니다.
Sequential: A → B → C (A가 B를 오염, B가 C를 오염)
Parallel: A ∥ B ∥ C (각 관점이 독립적으로 판단)병렬 분석은 각 관점의 독립성을 보장합니다. 그리고 독립적인 분석들이 같은 결론에 도달하면, 그것은 견고한 발견이 됩니다.
실제 사례: 프로덕션 인시던트 분석
EKS(AWS의 Kubernetes 서비스) 클러스터에서 API 서버가 응답 불가 상태가 되었습니다. Synthetics 모니터링 알림으로 감지. 2일 연속 같은 시간대에 발생했고, 원인을 특정하지 못한 상황이었습니다.
증상: 499 에러 다발, CNI unhealthy 상태에서 요청이 timeout까지 대기, Karpenter가 필요 이상으로 노드 증설
각 관점이 본 것 — 그리고 보지 못한 것
각 관점은 자신이 볼 수 없는 영역(Horizon Limits)을 명시합니다. 이것이 다른 관점이 필요한 이유이고, 병렬 분석의 근거입니다.
Convergence와 Divergence
분석 결과를 종합하면 두 가지가 나옵니다:
Convergence (4개 관점 모두 동의):
Divergence (관점 간 차이):
순차 분석이었다면 인프라 관점의 “race condition” 프레이밍에 오염되어, SRE 관점의 “deterministic trigger” 통찰이 묻혔을 겁니다.
병렬 분석이기 때문에 발산점이 드러났고, 이것이 추가 조사의 방향을 결정했습니다. 이것이 Prothesis의 핵심입니다.
위 사례에서 제가 한 일은 “선택” 뿐입니다. 하지만 이 한 단계로 얻는 것은:
- 판단 기준의 명시화: 왜 이렇게 답했는지 알 수 있음
- 검증 가능성: 해당 관점에서 맞는지 확인할 수 있음
- 대화의 방향성: 후속 질문도 같은 렌즈 안에서 진행
시작하기
Claude Code 플러그인
epistemic-protocols 플러그인을 설치하면 /prothesis 명령으로 바로 사용할 수 있습니다:
claude plugin add https://github.com/jongwony/epistemic-protocols사용법: 요청 전에 /prothesis 입력하거나 모드로 전환. AI가 관점을 제시하면 선택합니다.
프로토콜 전문은 저장소에서 확인할 수 있습니다.
판단 기준
Prothesis가 필요한 상황:
- “어떻게 생각해?”, “이거 괜찮아?” 같은 평가 요청
- 여러 관점이 유효한 복잡한 판단
- AI 응답을 검증해야 하는 상황
Prothesis가 불필요한 상황:
- 명확한 정답이 있는 사실 질문
- 이미 관점을 명시한 요청 (“성능 관점에서 봐줘”)
- 단순 실행 요청 (“이 함수 테스트 작성해줘”)
Prothesis는 기존에 알려진 방법론은 아닙니다. AI와 협업하면서 느꼈던 불편함에서 출발해 설계해 보았습니다.
Motive
많은 개발자가 에이전트 워크플로우의 계획-실행 사이클로 작업합니다. 저 역시 AI와 협업할 때 매번 “그 관점에서 본 거야?” “다른 관점에서는?” 하고 다시 물어야 했습니다.
관점 선택이 암묵적으로 처리되고 있었습니다. 이 단계를 명시화하면 어떨까 — 라는 생각이 시작점이었습니다.
Tools
Claude Code의 차별화된 기능인 AskUserQuestion과 Task(Subagent) 도구가 이 흐름을 자연스럽게 구현할 수 있게 해주었습니다:
1. AskUserQuestion — 선택지를 구조화해서 제시하고, 사용자 응답을 기다림
2. Task (Subagent) — 선택된 관점들로 병렬 분석을 수행
“관점 제시 → 선택 → 병렬 분석 → 통합”이라는 전체 흐름이 끊김 없이 작동하게 되었습니다.
마무리
AI가 빠르게 답하는 시대, 속도는 더 이상 희소 자원이 아닙니다.
희소해진 것은 이해입니다.
Prothesis는 계획 단계에서 전문가 관점으로 이해를 보존하려는 시도입니다. AI에게 답을 구하기 전에, “어떤 렌즈로 볼까요?”라고 먼저 묻게 함으로써
- Unknown Unknown을 Known Unknown으로 변환하고
- 판단의 기준을 명시화하고
- 검증 가능한 답을 얻습니다
이 글에서는 인프라 장애 분석을 예시로 들었지만, “내가 모르는 분야의 전문가에게 자문을 구한다”는 관점에서 다양한 영역에 적용할 수 있습니다.
솔직히 저는 인식론이나 철학적 개념에 대해서는 전문가가 아닙니다.
Prothesis는 AI 협업 과정에서 느낀 문제의식을 나름대로 구조화해 본 실험입니다.
저도 잘 사용하면서 개선하고 있으며 관련 분야 전문가 분들의 피드백을 통해 함께 발전시켜 나갈 수 있으면 좋겠습니다.
플러그인에는 실행 단계를 위한 Syneidesis 프로토콜도 포함되어 있습니다. 이는 별도 글에서 다룰 예정입니다.
질문 전에 질문하세요. AI가 더 나은 답을 줄 겁니다.
⏰ 딜라이트룸에서 알라미와 함께 아침을 바꿀 분들을 모십니다 🙌
