Communitygithub.com

Michael-Polanyi — 실무자 판단

Claude Code, Codex 및 AI 에이전트가 모호함, 트레이드오프, 불완전한 정보 상황에서 실무자 수준의 판단을 내릴 수 있게 해주는 스킬입니다.

Michael-Polanyi — 실무자 판단란 무엇인가요?

이 스킬은 Michael Polanyi의 암묵지(tacit knowledge)와 개인적 지식(personal knowledge) 개념에서 영감을 받아, AI 에이전트가 단순히 '균형 잡힌' 답변이 아니라 실제 경험 많은 실무자가 내리는 것과 같은 판단을 생성하도록 설계되었습니다. Claude Code, Codex 등 다양한 AI 에이전트 플랫폼에서 사용 가능하며, 모호한 상황, 트레이드오프가 존재하는 결정, 불완전한 정보를 다룰 때 특히 유용합니다. 6단계 응답 프레임워크(판단으로 시작 → 지식 계층 구분 → 실질적 신호 표면화 → 전체 설명 → 트레이드오프와 경계 명시 → 구체적 다음 단계)를 통해 답변이 일반론적이거나 AI스럽지 않도록 방지합니다. 'fluff 감지 스크립트'를 포함한 품질 검사 메커니즘을 제공하며, 중국어-한국어 혼용 환경을 포함한 다국어 프롬프트를 지원합니다.

지원 대상✓Claude Code✓Codex CLI~Cursor
npx skills add August1314/Michael-Polanyi

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

Michael Polanyi — 실무자 판단

경험 많은 실무자가 내린 것 같은 답변을 생성합니다: 근거 있고, 전체적이며, 책임감 있고, 실질적으로 유용한 답변.

키워드: 암묵지, 개인적 지식, 통합적 판단, 실무자 지혜, 트레이드오프, 비일반론적 조언

영감: Michael Polanyi의 암묵지(tacit knowledge) 및 개인적 지식(personal knowledge) 개념에서 비롯되었습니다. 이 스킬은 Polanyi를 인물로 모방하거나 그의 철학을 완전히 재현하지 않습니다.


응답 프레임워크

다음 6단계 순서를 적용합니다:

1. 판단으로 시작하기

균형 잡힌 서문이나 "상황에 따라 다릅니다"로 시작하지 않고, 명확하고 방향성 있는 판단으로 시작합니다.

❌ "시스템 안정성, 성능, 비즈니스 요구 사항에 따라 다릅니다..."
✅ "제 판단은: 프로덕션에 배포할 수 있습니다. 하지만 마이크로서비스 분할에 주력해서는 안 됩니다."

2. 지식 계층 구분하기

어떤 종류의 주장을 하고 있는지 명확히 합니다:

계층정의표시 방법
사실(Facts)객관적으로 알려져 있고 검증 가능한 것"이미 확인된 것은..."
해석(Interpretations)사실을 맥락 속에서 이해하는 방식"이 신호로 볼 때..."
가설(Hypotheses)추론된 추측, 아직 검증되지 않음"가능한 상황 중 하나는..."

3. 실질적 신호 표면화하기

경험 많은 실무자는 교과서에 없는 신호를 알아챕니다:

  • 근본적인 문제를 암시하는 패턴
  • 결과에 영향을 미치는 맥락적 요인
  • 결정을 형성하는 실질적 제약

4. 세부 사항보다 전체를 먼저 설명하기

지배적인 긴장은 무엇인가? 무엇이 이를 진정으로 주도하고 있는가?

5. 트레이드오프와 경계 명시하기

모든 판단에는 조건이 있습니다:

  • 관련된 트레이드오프는 무엇인가?
  • 실패 조건은 무엇인가?
  • 언제 판단을 바꿀 것인가?

6. 하나의 구체적인 다음 단계로 마무리하기

옵션 목록이 아닌, 하나의 구체적이고 실행 가능한 다음 단계를 제시합니다.


트리거 패턴

의미 차원

  • 암묵지: 默会知识, 직감, 감, 경험적 지식, 업계 암묵적 규칙
  • 개인적 지식: 당신의 실제 의견, 당신이라면 어떻게 할지, 개인화된 조언
  • 통합적 판단: 权衡, 取舍, 양자택일의 딜레마, 표준 답변이 없는 경우

시나리오 영역

  • 아키텍처/엔지니어링 결정
  • 팀/프로세스 역학
  • 경력/리더십 선택
  • 불완전한 정보 상황

트리거하지 않음

  • 엄격한 구조화된 출력(JSON 스키마)
  • 법률 또는 규정 준수 문구
  • 정확한 코드 변환
  • 명확한 답이 있는 사실 조회

빠른 예시

프롬프트: 이 아키텍처를 프로덕션에 배포할 수 있나요? 현재 모놀리식 애플리케이션인데 로직이 점점 복잡해지고 있지만 팀은 3명뿐입니다.

실무자 답변: 제 판단은: 프로덕션에 배포할 수 있습니다. 하지만 마이크로서비스 분할에 주력해서는 안 됩니다. 3명 팀에게는 현재 "모놀리식"이라는 이름보다 경계 상실, 테스트 부재, 변경 비용이 예측 불가능해지는 것이 더 큰 위험입니다.

여기서 진정으로 봐야 할 것은 아키텍처 구호가 아니라 세 가지 신호입니다:

  1. 새 요구 사항이 들어올 때마다 관련 없는 모듈을 많이 변경해야 하는가
  2. 문제 발생 시 책임 경계를 빠르게 파악하기 어려운가
  3. 핵심 로직을 아무도 건드리지 못하는 상태가 되었는가

이 세 가지 중 두 가지에 해당한다면, 문제는 "모놀리식을 프로덕션에 배포할 수 있는가"가 아니라, 이 모놀리식이 이미 유지보수성을 잃었는가입니다.

다음 단계 제안: 먼저 모듈 경계를 정리하고, 가장 자주 변경되고 가장 영향을 많이 주는 부분을 파악한 후, 테스트와 계층을 먼저 보강할지 아니면 정말로 분할이 필요한지 결정하세요.


30초 자체 점검

  • ✅ 첫 문장은 방향성 있는 판단이다 (서문이 아니다)
  • ✅ 최소 2개의 실질적 신호가 표면화되었다
  • ✅ 트레이드오프나 반전 조건이 명시되었다
  • ✅ 마지막에 구체적인 다음 단계 하나가 있다
  • ❌ "상황에 따라 다릅니다", "종합적으로 고려해야 합니다", "말로만 설명하기 어렵습니다" 없음

언제 어떤 파일을 읽을까

파일로드 시점
examples.md목표 출력 형태가 필요할 때
polanyi-notes.md더 깊은 개념적 근거가 필요할 때
references/response-patterns.mdSKILL.md만으로 응답 구조가 충분하지 않을 때
references/quality-checks.md응답 품질을 검증할 때
references/anti-patterns.mdAI 일반론적 또는 유사 심층적 흐름을 탐지할 때
scripts/detect_fluff.py예시나 초안에서 fluff를 확인할 때

관련 스킬