대부분의 "데이터 분석을 위한 AI" 콘텐츠는 너무 일반적이거나 ("데이터를 설명해 달라고 요청하세요!") 또는 너무 지엽적입니다 ("GROUP BY를 작성하는 프롬프트가 여기 있습니다"). 이 중 어느 것도 실제 월요일 아침의 업무 현장에서는 살아남지 못합니다.

아래는 분석가로서 제가 실제로 사용하는 10가지 프롬프트입니다. 각 프롬프트는 자신감 있게 들리는 환각 (Hallucination) 대신 사용 가능한 결과물을 생성할 수 있도록 구조, 제약 조건 (Constraints), 그리고 실제 예시를 갖추고 있습니다.

언제나 그렇듯 패턴은 다음과 같습니다: 역할 (Role) → 문맥 (Context) → 제약 조건 (Constraints) → 출력 형식 (Output format). 마법은 바로 제약 조건에서 일어납니다. 제약 조건이 없는 프롬프트는 위키피디아식 요약을 제공하지만, 날카로운 제약 조건이 있는 프롬프트는 바로 실무에 투입할 수 있는 초안을 제공합니다.

1. 비즈니스 질문으로부터 SQL 쿼리 생성하기 (컬럼을 환각하지 않는 방식)

역할 (Role): 당신은 알려진 스키마 (Schema)를 바탕으로 SQL을 작성하는 시니어 분석가입니다.
문맥 (Context): 비즈니스 질문: {question}. 스키마 (테이블 + 컬럼 + 타입): {DDL}. SQL 방언 (Dialect): {postgres/mysql/bigquery/snowflake}.
제약 조건 (Constraints):

• 내가 붙여넣은 스키마에 존재하는 컬럼만 참조하세요. 질문에 존재하지 않는 컬럼이 필요하다면 명시적으로 말하세요. 존재하지 않는 컬럼을 만들어내지 마세요.
• 가독성을 위해 서브쿼리 (Subquery)보다 CTE (Common Table Expressions)를 선호하세요.
• 모든 JOIN은 조인 조건 (Join condition)을 명시해야 합니다. 암시적 조인 (Implicit join)은 허용하지 않습니다.
• 공백이 포함된 컬럼명이나 예약어는 큰따옴표로 감싸세요.
• 쿼리에 윈도우 함수 (Window function)가 필요하다면 사용하세요. 셀프 조인 (Self-join)으로 흉내 내지 마세요.
• 각 CTE 상단에 해당 CTE가 무엇을 반환하는지 설명하는 한 줄 주석을 추가하세요.

출력 (Output): SQL 코드, 그 다음 접근 방식에 대한 두 문장 요약.

이것이 효과적인 이유: 스키마를 붙여넣고 모델이 그 스키마 내에서만 작동하도록 제약을 거는 것은, 실제로 실행 가능한 쿼리와 당신에게 존재하지 않는 user_signups 테이블을 참조하는 쿼리 사이의 차이를 만듭니다.

2. 생소한 데이터셋을 위한 탐색적 데이터 분석 (EDA) 계획

역할 (Role): 당신은 새로운 데이터셋에 대한 첫 60분간의 탐색적 데이터 분석 (EDA) 계획을 세우는 시니어 데이터 사이언티스트 (Senior Data Scientist)입니다.
컨텍스트 (Context): 데이터셋 설명: {내용}. 컬럼 (Columns) + 타입 (Types): {목록}. 행 수 (Row count): {대략적인 수치}. 비즈니스 맥락 (Business context): {중요한 이유}.
제약 사항 (Constraints):

• 실행할 8~10개의 구체적인 분석 항목을 순서대로 번호가 매겨진 리스트로 출력하세요.
• 각 항목에 대해, 해당 분석이 답하는 질문과 사용할 차트 유형 (Chart type)을 명시하세요.
• 처음 세 가지 분석은 비즈니스 질문이 아닌 데이터 품질 체크 (Data-quality checks: 결측치 (Nulls), 중복 (Dupes), 범위 (Ranges))여야 합니다.
• 자유 텍스트 필드 (Free-text field)로 보이는 컬럼이 있다면 표시하고, 이를 어떻게 처리할지 제안하세요.
• 첫 60분 이내에 머신러닝 (Machine learning)을 제안하지 마세요.

출력 (Output): 순서가 지정된 EDA 계획.

3. 비기술적 이해관계자를 위한 변동 원인 설명

역할 (Role): 당신은 SQL을 보고 싶어 하지 않는 임원에게 지표 변화를 설명하고 있습니다.
컨텍스트 (Context): 지표 (Metric): {지표}. 변화 (Change): {기간 Z 동안 X에서 Y로 변화}. 원인 분석 (Driver breakdown, 알고 있는 경우): {세그먼트 수준의 차이 (Segment-level deltas)}.
제약 사항 (Constraints):

• 첫 번째 문장은 쉬운 영어로 방향과 규모를 설명합니다 ("지난주 매출이 12% 감소했습니다").
• 두 번째 문장은 변화량 중 가장 큰 비중을 차지하는 단일 원인을 명시합니다.
• "무엇이 변했는가 / 무엇이 변하지 않았는가 / 아직 무엇을 모르는가" 구조를 사용하세요.
• p-값 (p-values), 통계 전문 용어 (Statistical jargon), "데이터가 ~를 시사한다"와 같은 표현을 사용하지 마세요.
• 특정 세그먼트가 헤드라인과 반대 방향으로 움직였다면, 이를 숨기지 말고 명시하세요.

출력 (Output): 5문장으로 구성된 요약.

예시 (매출이 12% 감소한 경우):

지난주 매출은 8만 4천 달러에서 7만 4천 달러로 12% 감소했습니다. 이 하락은 거의 전적으로 31% 감소한 미드 티어 (Mid-tier) 요금제에 의해 발생했으며, 엔터프라이즈 (Enterprise) 및 프리 티어 (Free-tier)는 변동이 없었습니다. 고객을 잃은 것은 아닙니다. 미드 티어의 축소는 8개의 계정이 프리 티어로 다운그레이드한 것에 기인했습니다. 아직 우리가 모르는 것은 이것이 2주 전 가격 변경에 대한 반응인지 아니면 우연인지 여부입니다. 오늘 이탈 설문 조사에서 다운그레이드 사유를 추출할 예정입니다.

4. 이상치 조사 체크리스트 (Anomaly investigation checklist)

역할 (Role): 당신은 급증/급락 알림을 방금 받고 이를 분류(triage)해야 하는 분석가입니다.
맥락 (Context): 지표 (Metric): {metric}. 이상치 (Anomaly): {time T 시점의 X% 급증/급락}. 알림 시스템 (Alerting system): {발생한 알림 내용}.
제약 사항 (Constraints):

• "가장 가능성 높은 원인"부터 "가장 가능성 낮은 원인" 순으로 6~8개의 조사 단계 체크리스트를 작성하세요.
• 1단계는 반드시 데이터 파이프라인 체크(데이터가 실제로 도착했는가? 이상치가 실제 현상인가 아니면 파이프라인의 공백인가?)여야 합니다.
• "이것이 실제 현상이 아님을 확인하는 방법"에 대한 체크 항목을 포함하세요.
• 각 단계마다 어떤 결과가 해당 원인을 가리키는지 명시하세요.
• "모니터링하기"를 조사 단계로 추천하지 마세요. 그것은 조사가 아닙니다.

출력 (Output): 번호가 매겨진 분류(triage) 체크리스트.

5. 지표 정의 문서 (Metric definition document)

역할 (Role): 당신은 재무, 제품, 분석 팀 간의 논쟁을 종식시키기 위해 비즈니스 지표에 대한 표준 정의(canonical definition)를 작성하고 있습니다.
맥락 (Context): 지표 이름 (Metric name): {name}. 의도 (Intent): {지표가 포착하고자 하는 것}.
제약 사항 (Constraints):

• 섹션: 정의 (Definition) / 포함 사항 (Inclusions) / 제외 사항 (Exclusions) / 예외 사례 (Edge cases) / 갱신 주기 (Refresh cadence) / 소유자 (Owner).
• "포함 사항"과 "제외 사항"은 각각 최소 4개의 구체적인 예시를 포함해야 합니다.
• "예외 사례"는 환불, 체험판, 내부/테스트 계정, 교차 통화, 시간대를 다루어야 합니다.
• 정의 문장은 분석가가 아닌 사람도 그대로 따라 말할 수 있는 단일 문장이어야 합니다.
• 기록 시스템(System of record, 어떤 테이블/뷰가 권위 있는 데이터인지)을 명시하세요.

출력 (Output): 메트릭 카탈로그(metrics catalog)에 바로 삽입할 수 있는 지표 정의 문서.

6. 대시보드 비평 (무엇을 삭제해야 할지 알려주는 비평)

역할 (Role): 당신은 대시보드의 유용성을 검토하는 시니어 분석가입니다.
맥락 (Context): 대시보드 목적 (Dashboard purpose): {명시된 목적}. 차트 (Charts): {각 차트 목록 + 보여주는 내용}. 대상 (Audience): {대시보드를 보는 사람}.
제약 사항 (Constraints):

• 각 차트에 대해 다음을 명시하세요: 이 차트가 의사결정에 답을 주는가? 그렇지 않다면 삭제를 권장하세요.
• 대시보드에 이미 있는 정보와 중복되는 차트가 있다면 식별하세요.
• 대상(Audience)이 축(axis)이나 필터(filter)를 해석할 수 없는 차트가 있다면 표시하세요.
• 누락되었으나 실제로 의사결정을 이끌어낼 수 있는 차트를 1~2개 제안하세요.
• "시각적으로 더 매력적이게 만드세요"와 같은 권장 사항은 하지 마세요. 그것은 문제가 아닙니다.

출력 (Output): 삭제/유지/추가 권장 사항이 포함된 차트별 검토 내용.

7. 코호트 분석 (Cohort analysis) 설계

역할 (Role): 당신은 리텐션(retention, 유지율) 질문에 답하기 위한 코호트 분석을 설계하고 있습니다.
맥락 (Context): 질문: {월간 사용자가 주간 사용자보다 리텐션이 더 높은가? / 가입 경로가 중요한가? / 기타}. 사용 가능한 데이터: {사용자 이벤트, 가입 날짜 등}.
제약 사항 (Constraints):

• 코호트 키(cohorting key, 사용자를 코호트로 그룹화하는 기준)를 정의하세요.
• 코호트 크기(cohort size)를 정의하세요 (주간? 월간? 그 이유는 무엇인가).
• 리텐션 지표(retention metric)를 정의하세요 (D7? D30? 특정 기간 내 활성 여부? 그 이유는 무엇인가).
• 수행할 비교 내용과 그 비교가 이끌어낼 의사결정을 명시하세요.
• 선택 편향(selection bias) 위험을 지적하세요 — 이 코호트 정의에서 어떤 유형의 사용자가 과잉 대표(over-represented)되는가?

출력 (Output): 쿼리(query)가 아닌 코호트 명세서(spec).

8. A/B 테스트 결과 요약 (과장하지 않는 방식)

역할 (Role): 당신은 제품 팀을 위해 A/B 테스트 결과를 요약하고 있습니다.
맥락 (Context): 가설 (Hypothesis): {테스트한 내용}. 변수 (Variant): {변경 사항}. 샘플 (Samples): {각 그룹당 n명}. 결과 (Result): {리프트 (lift), 신뢰 구간 (confidence interval), p-value}.
제약 사항 (Constraints):

• 결과가 통계적으로 유의미한지(statistically significant) 여부를 단정적으로 명시하세요.
• 유의미하다면, 효과 크기(effect size)를 단순히 "% 리프트"가 아닌 원래 단위로 명시하세요.
• 점 추정치(point estimate)뿐만 아니라 신뢰 구간(confidence interval)을 보고하세요.
• (세분화했을 경우) 효과가 달랐던 세그먼트(segment)를 하나 언급하세요. 세분화하지 않았다면 그렇다고 명시하세요.
• 이 테스트가 무엇을 증명하지 "않는지"를 명시적으로 밝히세요 (개입(intervention) 범위를 벗어난 인과 관계 주장 금지).

출력 (Output): 4문장의 요약 + 1문장의 권장 사항.

예시 (Example):

새로운 결제 흐름(checkout flow)은 전환율을 3.1%에서 3.4%로 증가시켰습니다 (상대적 상승폭 +9.7%, 95% 신뢰 구간 (CI) [+2.1%, +17.9%], p=0.012). 이는 통계적으로 유의미합니다 (statistically significant). 이 효과는 데스크톱과 모바일 모두에서 일관되게 나타났습니다. 이 테스트는 새로운 흐름이 더 높은 전환율을 기록한다는 것을 증명하지만, 그 이유를 증명하는 것은 아니며, 더 높은 트래픽에서도 이 상승폭이 유지될 것을 보장하지는 않습니다.

9. 새 테이블을 위한 데이터 품질 보고서 (Data quality report)

역할 (Role): 당신은 다른 사용자가 사용하기 전에 새로운 테이블을 프로파일링 (profiling)하는 전문가입니다.
컨텍스트 (Context): 테이블: {name}. 컬럼 및 타입: {list}. 샘플 행: {paste 5 rows}.
제약 사항 (Constraints):

• 각 컬럼에 대해 다음을 보고하세요: null 비율 (샘플에서 추정 가능한 경우), 고유 값 (distinct values), 최소/최대값 또는 상위 3개 값.
• 형식이 일관되지 않은 컬럼을 표시하세요 (두 가지 형식의 날짜, 혼합된 대소문자의 ID 등).
• 고유해야 할 것으로 보이지만 그렇지 않은 컬럼을 표시하세요.
• 외래 키 (foreign keys)로 추정되는 항목을 식별하고, 예상되는 부모 테이블과 조인 (join)되는 것으로 보이는지 명시하세요.
• 전반적인 신뢰도 등급을 매기세요: 운영 환경 사용 가능 (production-ready) / 주의 사항과 함께 사용 (use-with-caveats) / 아직 사용 금지 (do-not-use-yet).

출력 (Output): 신뢰도 등급이 포함된 프로파일링 보고서.

10. 이해관계자 질문 → 분석 계획 (범위 축소 프롬프트)

역할 (Role): 당신은 모호한 이해관계자의 요청에 대응하는 시니어 분석가 (senior analyst)입니다.
컨텍스트 (Context): 요청 내용 (원문 그대로): {paste}. 이해관계자: {role}. 타임라인: {사용 가능한 시간}.
제약 사항 (Constraints):

• 이해도를 확인하기 위해 질문을 당신의 언어로 다시 서술하세요.
• 모호한 요청 속에 숨겨진 2~3개의 하위 질문을 식별하세요.
• 각 하위 질문에 대해, 이를 답변할 데이터가 존재하는지 명시하세요.
• 최소 기능 분석 (minimum viable analysis, 질문의 80%를 해결하는 20%의 핵심 분석)을 제안하세요.
• 당신이 수행하지 '않을' 작업과 그 이유를 명시적으로 밝히세요 (데이터 부재 / 시간 대비 가치 낮음 / 범위 외).

출력 (Output): 범위를 확인하고 정중하게 범위를 축소 (de-scope)하는 이해관계자용 답변.

내가 분석 프롬프트를 테스트하는 방법

1. 이미 알고 있는 데이터셋에서 실행해 보세요. 만약 프롬프트의 EDA (탐색적 데이터 분석) 계획이 데이터에 포함되어 있다는 것을 당신이 이미 알고 있는 내용을 놓친다면, 제약 조건 (constraints)이 너무 느슨한 것입니다.
2. 실제 스키마 (schema)와 SQL을 대조해 보세요. 환각 (hallucination)된 컬럼은 가장 흔한 실패 유형입니다. 스키마를 붙여넣지 않으면, 존재하지 않는 테이블 이름이 만들어질 것입니다.
3. 이해관계자용 요약을 소리 내어 읽어보세요. 만약 데이터 과학자가 다른 데이터 과학자를 위해 쓴 것처럼 들린다면, 전문 용어 (jargon)를 금지하도록 제약 조건을 다시 작성하세요.

이 프롬프트들의 출처

이 프롬프트들은 제가 실제 분석, 제품, 그리고 엔지니어링 업무 전반에 걸쳐 구축하고 테스트해 온 더 큰 라이브러리의 일부입니다. 전체 세트를 원하신다면:

• Developer Product-Launch Prompt Pack ($9) — 데이터 기반 제품 출시를 위한 7가지 프롬프트: gum.co/qevvy
• Developer Productivity Prompt Library ($49) — 데이터 + 엔지니어링 워크플로우를 포함한 30가지 프롬프트: gum.co/plytri
• SaaS Marketing Copy Prompt Pack ($49) — 분석 기반 마케팅을 위한 25가지 프롬프트: gum.co/orcwxs
• AI Startup Operations Prompt System ($199) — 데이터 중심 기업 운영을 위한 50개 이상의 프롬프트 + 10가지 워크플로우: gum.co/aeqnd
• AI Business Transformation Playbook ($999) — 100개 이상의 프롬프트 + 12가지 워크플로우를 포함한 전체 시스템: gum.co/boivub

$9 팩이 가장 저렴한 진입점입니다. 만약 이 팩이 "그 컬럼이 뭐였더라?"라고 묻는 과정을 한 번이라도 줄여준다면, 이미 본전은 뽑은 것입니다.

자산은 특정 프롬프트 자체가 아니라 그 구조입니다. 역할 (Role) → 맥락 (Context) → 제약 조건 (Constraints) → 출력 (Output) 구조가 근육 기억 (muscle memory)이 되면, 당신의 분석 워크플로우에서 반복 가능한 모든 부분에 대해 자신만의 프롬프트를 작성할 수 있게 될 것입니다. 위에 소개된 10가지는 실제 매주 사용하며 검증된 것들입니다.

만약 이 프롬프트들보다 성능이 뛰어난 분석 프롬프트를 가지고 있다면, 저도 보고 싶습니다. 최고의 프롬프트는 항상 매일 쿼리를 실행하는 사람들에게서 나옵니다.