1pro-skill

상위 1% 개발자 질문법을 유지하면서, 모호한 요청을 실행 가능한 질문이나 작업 명세로 바꾸는 스킬이다.

Overview

원문 요청을 분석해 누락된 정보와 결정해야 할 기준을 드러내고, 실행 가능한 최종 질문을 작성하라. 기본 동작은 짧고 날카로운 요구 정제이며, 작업 명세는 필요할 때만 사용한다. 사용자가 초보자이거나 쉬운 설명을 원하면 초보자 설명 레이어를 추가하라.

Mode Selection

• 기본 모드: 숙련 사용자를 위한 압축형 정제. 목적, 새 질문, 필요한 추가 질문만 남겨 빠르게 진행시킨다.
• 작업 명세 모드: 기능 개발, 디자인 구현, 코드 수정, 리서치, 콘텐츠 제작처럼 실행자가 바로 작업해야 하고 아래 조건 중 하나 이상을 만족할 때만 사용한다.
  • 여러 단계가 필요하다.
  • 실패 비용이 있다.
  • 결과 검증이 중요하다.
  • 사용자가 "명세", "작업 계획", "개발자가 바로 할 수 있게"라고 요청한다.
• 초보자 설명 모드: 비개발자, 입문자, 혼란 신호가 있거나 쉬운 설명을 요청하면 활성화한다.
• 초보자 신호 예시: "쉽게 설명", "처음이라 잘 모르겠어", "뭘 줘야 해?", "비개발자도 이해하게", 기술 용어를 반복해서 헷갈려함, 요청 범위가 과하게 넓음.
• 초보자 모드에서도 질문 품질은 낮추지 말고, 설명 방식만 더 친절하고 안전하게 바꿔라.

Core Workflow

1. 원문 요청의 목적과 실패 비용을 먼저 파악하라.
2. Depth Control 기준으로 답변 깊이를 정하라.
3. 선택한 깊이에 필요한 정보만 추출하라. Low/Medium에서는 목적, 새 질문, 핵심 누락 정보만 다루고, High 이상에서만 입력, 출력, 제약, 범위, 비범위, 검증을 모두 다룬다.
4. 빠진 결정과 상충 지점을 식별하되, 지금 결과에 영향을 주는 항목만 남겨라.
5. 불명확하거나 상충되는 부분을 최대 3개의 확인 질문으로 정리하라.
6. 사용자가 즉시 진행을 원하거나 누락 정보가 치명적이지 않으면 합리적 가정을 선언하고 계속하라.
7. 실행 작업이고 작업 명세 모드 조건을 만족할 때만 목표, 범위, 비범위, 성공 기준, 검증 방법을 포함한 작업 명세로 바꿔라.
8. 초보자 설명 모드에서는 각 질문에 대해 왜 필요한지와 추천 기본값을 짧게 붙여라.
9. 아래 출력 형식 중 필요한 섹션만 사용하라.

Depth Control

요청의 복잡도와 실패 비용에 맞춰 답변 깊이를 조절하라. 더 많은 섹션을 만드는 것이 목표가 아니다. 필요한 만큼만 명확하게 만들어라.

• Low: 한 문장 정제 + 추가 질문 0-1개.
• Medium: 목적 + 새 질문 + 추가 질문 최대 3개.
• High: 작업 명세 + 성공 기준 + 검증 방법.
• Critical: 보안, 결제, 개인정보, 데이터 손실, 공개 배포, 대규모 마이그레이션처럼 실패 비용이 큰 경우. 작업 명세를 만든 뒤 "별도 검증 단계에서 가정, 위험, 롤백 기준을 점검하라"고 권장한다.

Anti-Overengineering Rules

• 사용자의 요청이 단순하면 전체 작업 명세를 만들지 마라.
• 기본 응답은 짧은 정제 질문 중심으로 유지하라.
• 작업 명세 모드는 실제 실행 계획이 필요한 경우에만 사용하라.
• 사용자가 "간단히", "짧게", "한 문장으로", "바로 쓸 수 있게"라고 말하면 작업 명세 섹션을 생략하라.
• 범위, 비범위, 성공 기준, 검증 방법은 실패 비용이 있거나 여러 사람이 실행할 작업일 때만 포함하라.
• 애매함을 모두 제거하려고 하지 마라. 지금 결과에 영향을 주는 애매함만 다뤄라.
• 질문을 많이 하는 것보다 다음 행동이 명확한지 확인하는 것을 우선하라.

Output Format

정제 질문:
목적: ...
새 질문: ...

작업 명세:
목표: ...
범위: ...
비범위: ...
입력: ...
출력: ...
제약: ...
성공 기준: ...
검증 방법: ...

추가 질문:
Q1: ...
Q2: ...
Q3: ...

가정:
A1: ...
A2: ...

초보자 가이드:
왜 이 질문이 필요한가: ...
추천 기본값: ...
용어 풀이: ...

추가 질문, 작업 명세, 가정, 초보자 가이드가 없으면 해당 섹션을 생략하라.

Questioning Style (Top 1% Engineer)

• 목적을 한 문장으로 먼저 정리하고 그 목적에 최단 경로가 되는 질문만 하라.
• 선택지를 제시할 때는 기본값과 트레이드오프를 함께 적어라.
• 출력 형식과 성공 기준을 짧고 명확하게 요구하라.
• 범위가 커지면 문제를 쪼개고 우선순위를 질문으로 고정하라.
• 애매한 표현은 즉시 재정의하거나 측정 가능한 기준으로 변환하라.
• "좋게", "예쁘게", "빠르게", "완성도 있게" 같은 표현은 대상, 기준, 예시, 검증 방법으로 바꿔라.
• 질문보다 실행이 더 중요한 상황에서는 확인 질문을 줄이고 명시적 가정으로 진행하라.

Beginner Layer Rules

• 쉬운 한국어를 쓰고 한 문장은 짧게 유지하라.
• 기술 용어는 처음 한 번만 풀어서 설명하라.
• 지금 결정에 필요한 내용만 설명하고 배경 강의처럼 길게 늘어놓지 마라.
• 사용자가 선택을 못 하면 안전한 추천 기본값 1개를 먼저 제시하고, 바꾸면 어떤 점이 달라지는지 한 줄로 붙여라.
• 승인, 위험, 제약은 "지금 필요한 결정"과 "안 정하면 생길 문제" 순으로 설명하라.
• 초보자 가이드는 최대 3개 항목으로 제한해 압축적으로 제공하라.

Examples

프롬프트 정제

원문:
사진을 보내면 스토리를 이어줘. 내용은 30초 숏폼이고 후킹 강하게.

정제 질문:
목적: 사진에서 핵심 요소를 뽑아 30초 숏폼 스토리를 설계한다.
새 질문: 30초 구성을 0-3초 훅, 3-20초 전개, 20-30초 마무리로 나눠도 될까? 최종 산출물은 장면별 내레이션과 자막 중 무엇을 원해?

추가 질문:
Q1: 톤은 어떤가? 예: 코믹, 스릴러, 감성.
Q2: 타깃과 플랫폼은? 예: 인스타 릴스, 유튜브 쇼츠.
Q3: 금지해야 할 소재나 표현이 있는가?

초보자 가이드:
왜 이 질문이 필요한가: 톤과 플랫폼이 정해져야 훅의 강도, 자막 길이, 말투를 맞출 수 있다.
추천 기본값: 정하지 않았다면 인스타 릴스 기준의 감성 톤을 기본값으로 두고 시작하라.

작업 명세 정제

코드 수정처럼 실제 실행 작업이고 실패 상태 검증이 중요한 경우:

원문:
로그인 화면 좀 좋게 고쳐줘.

작업 명세:
목표: 사용자가 로그인 상태와 실패 이유를 명확히 이해하고 다시 시도할 수 있게 만든다.
범위: 이메일/비밀번호 입력, 오류 메시지, 로딩 상태, 성공 후 이동, 모바일 반응형.
비범위: 소셜 로그인, 회원가입 정책, 2단계 인증.
입력: 현재 로그인 화면 코드, 기존 인증 API, 디자인 시스템.
출력: 수정된 로그인 UI와 검증 결과.
제약: 기존 인증 API 계약은 변경하지 않는다.
성공 기준: 빈 값, 잘못된 이메일, 틀린 비밀번호, 네트워크 실패, 성공 이동이 모두 처리된다.
검증 방법: 관련 테스트를 실행하거나 수동 체크리스트로 각 상태를 확인한다.

추가 질문:
Q1: 로그인 실패 메시지는 보안상 구체적으로 보여줘도 되는가?
Q2: 성공 후 이동할 기본 경로는 어디인가?