Kimi K3.1 Pro 프롬프트 모음: 5가지 시나리오에서 바로 복사해 결과 얻기

Kimi K3.1 Pro가 HiAPI에 출시되었으며, 신규 가입 시 200 크레딧을 증정합니다. 아래는 트러블슈팅, 코드 리뷰, 방안 비교, 장문 문서 분석, 데이터 처리를 아우르는 5가지 실제 사용 가능한 프롬프트입니다. 각 프롬프트는 그대로 복사할 수 있고, 링크를 누르면 자동으로 채워집니다.

1. 시스템 트러블슈팅: 오류 로그에서 근본 원인 찾기

오류 로그를 모델에 던져 주고 호출 경로를 따라 계층별로 점검하게 하여, 근본 원인과 수정 단계를 출력하게 합니다. "네트워크 연결을 확인하세요" 같은 두루뭉술한 답이 아니라 구체적인 결과를 얻을 수 있습니다.

출력 예시 참고: 모델은 점검 경로(예: Nginx 리버스 프록시 설정 → 백엔드 서비스 상태 → 데이터베이스 커넥션 풀)를 나열하고, 각 계층마다 점검 명령, 예상 결과, 이상 징후를 제시한 뒤 마지막에 근본 원인(예: "PostgreSQL 커넥션 풀 고갈로 새 요청이 대기하다 타임아웃")을 특정하고 두 단계의 수정 방안을 제시합니다.

당신은 백엔드 트러블슈팅 엔지니어입니다. 아래는 프로덕션 환경의 오류 로그입니다. 다음 단계에 따라 점검하세요:

1. 로그의 핵심 시점과 오류 코드를 한 줄씩 해석
2. 호출 경로(진입점 → 미들웨어 → 서비스 → 데이터베이스)를 따라 계층별로 가능한 원인 분석
3. 가장 가능성 높은 근본 원인 제시(최대 3개)
4. 각 근본 원인마다 검증 명령과 수정 단계 제시

출력 형식:
## 로그 해석
## 계층별 점검
## 근본 원인 분석
## 수정 단계

로그:
[오류 로그를 붙여넣으세요]

이 프롬프트로 트러블슈팅하기 →

kimi-k3.1-pro, reasoning_effort: high. 참고: 약 $0.03 (입력 약 3000 token + 출력 약 2000 token).

핵심: 프롬프트에 출력 구조와 점검 경로를 정의했기 때문에 모델이 단계를 건너뛰지 않고, "재시작해 보세요" 같은 무의미한 제안도 하지 않습니다. 트러블슈팅 문제는 reasoning_effort를 high 또는 max로 설정하는 편이 더 유용합니다. low는 때때로 중간 계층을 건너뛰고 바로 결론을 추측합니다.

2. 코드 리뷰: 구조화된 JSON 출력

모델이 코드를 리뷰하고 JSON을 출력하게 하면 그대로 DB에 저장해 CI 검사에 활용할 수 있습니다. K3.1 Pro의 json_schema 모드는 출력 필드, 타입, 열거값이 정의와 엄격하게 일치하도록 보장합니다.

출력 예시 참고: 모델은 issues 배열(각 항목에 file, line, severity, category, description, suggestion 포함), summary 객체(각 심각도별 개수 포함), overall_score(0-100)를 포함한 JSON 객체를 반환합니다. 심각도는 critical / major / minor / style 네 단계로 엄격히 분류됩니다.

아래 코드를 리뷰해야 합니다. JSON Schema에 따라 리뷰 결과를 엄격하게 출력하고, JSON 외에 어떤 텍스트도 출력하지 마세요.

리뷰 관점:
- 논리 오류 및 경계 조건
- 성능 문제(N+1 쿼리, 불필요한 루프)
- 보안 위험(SQL 인젝션, XSS, 미검증 입력)
- 코드 스타일 및 가독성

출력 JSON Schema:
{
  "issues": [
    {
      "file": "string",
      "line": "number",
      "severity": "critical | major | minor | style",
      "category": "logic | performance | security | style",
      "description": "string",
      "suggestion": "string"
    }
  ],
  "summary": {
    "critical": "number",
    "major": "number",
    "minor": "number",
    "style": "number"
  },
  "overall_score": "number (0-100)"
}

코드:
[코드를 붙여넣으세요]

이 프롬프트로 코드 리뷰하기 →

kimi-k3.1-pro, response_format: json_schema. 참고: 약 $0.04 (입력 약 4000 token + 출력 약 2500 token).

핵심: 출력 형식을 고정하려면 반드시 response_format: {"type": "json_schema", "json_schema": {...}}를 전달해야 합니다. 프롬프트에 Schema를 한 번 더 작성하는 것은 이중 안전장치입니다. json_schema가 적용되지 않더라도 모델이 형식에 맞춰 출력합니다. severity는 자연어 설명이 아닌 열거값을 사용해 다운스트림에서 바로 분기 판단을 할 수 있도록 보장합니다.

3. 기술 방안 비교: 다차원 점수표

두 기술 방안 사이에서 결정을 못 내릴 때, 모델이 여러 차원에서 점수를 매기고 총점을 계산하게 하면 동료가 감으로 정하는 것보다 공정합니다.

출력 예시 참고: 모델은 성능, 유지보수성, 생태계 성숙도, 학습 비용, 팀 적합도 등 5-6개 항목을 포함한 비교 표를 생성하고, 각 항목에 1-10점과 한 줄 이유를 제시한 뒤 마지막에 가중치를 적용해 총점을 계산하고 선택을 권장합니다.

두 기술 방안 중 하나를 선택해야 합니다: 방안 A와 방안 B. 다음 6가지 차원에서 하나씩 비교하고, 각 차원에 점수(1-10)를 매기고 한 줄 이유를 작성한 뒤, 마지막에 가중치를 적용해 총점을 계산하고 추천을 제시하세요.

비교 차원 및 가중치:
- 성능(가중치 25%)
- 유지보수성(가중치 20%)
- 생태계 성숙도(가중치 20%)
- 학습 비용(가중치 15%)
- 팀 기존 기술 스택 적합도(가중치 15%)
- 커뮤니티 활성도(가중치 5%)

출력 형식:
| 차원 | 방안 A 점수 | 방안 B 점수 | 이유 |
|---|---|---|---|
| 성능 | | | |
| ... | | | |
| **가중 총점** | | | |

마지막 단락: 추천 이유(최대 3문장)

방안 A: [방안 A 설명, 예: 기술 스택, 아키텍처, 핵심 의존성]
방안 B: [방안 B 설명, 예: 기술 스택, 아키텍처, 핵심 의존성]
배경: [선택: 팀 규모, 기존 기술 스택, 비즈니스 시나리오]

이 프롬프트로 방안 비교하기 →

kimi-k3.1-pro, reasoning_effort: high. 참고: 약 $0.04 (입력 약 3000 token + 출력 약 3000 token).

핵심: 가중치는 실제 상황에 맞게 조정하세요. 팀에 이미 선호가 있다면 가중치를 프롬프트에 직접 적으세요. 모델이 점수 계산에 반영합니다. 방안 이름만 주지 말고 각 방안의 핵심 기술 선택, 의존성, 팀 상황을 명확히 작성해야 모델이 근거 있는 점수를 제시할 수 있습니다.

4. 장문 문서 분석: 매뉴얼 전체에서 핵심 정보 추출

수십 페이지의 기술 문서, 회의록, 사용자 피드백을 던져 넣고 정말 관심 있는 몇 가지 핵심을 모델이 추출하게 합니다. K3.1 Pro의 1M token 컨텍스트는 매뉴얼 한 권을 충분히 소화합니다.

출력 예시 참고: 모델은 먼저 문서 주제와 구조를 요약한 뒤 각 핵심 질문에 하나씩 답하고, 마지막에 놓치기 쉬운 경계 상황과 모순점을 나열합니다.

아래는 완전한 기술 문서입니다. 다음 구조에 따라 핵심 정보를 추출하세요:

1. 문서 주제 및 구조 개요(한 단락)
2. 다음 구체적 질문에 답하기:
   - [질문 1]
   - [질문 2]
   - [질문 3]
3. 문서에 언급된 모든 제약 조건과 전제 가정(항목별 나열)
4. 놓치기 쉬운 경계 상황(최소 3개)
5. 문서에 모순되거나 불명확한 부분(있는 경우)

문서:
[문서 전문을 붙여넣으세요]

이 프롬프트로 문서 분석하기 →

kimi-k3.1-pro, reasoning_effort: max, max_tokens: 8000. 참고: 약 $0.07 (입력 약 15000 token + 출력 약 3000 token). 장문 문서의 입력 token은 실제 문서 길이로 계산되며, 여기서는 약 1만 한자의 보수적 추정치입니다.

핵심: 질문 2와 3은 문서에서 정말 알고 싶은 내용으로 바꾸고, 템플릿의 [질문 1]을 남기지 마세요. 문서가 길 때는 reasoning_effort를 max로 설정하세요. low는 장문 컨텍스트 시나리오에서 정보를 놓치기 쉽습니다. 같은 장문 문서를 반복 분석할 때 두 번째부터는 캐시 읽기 비용이 $0.2156/M token(입력 가격의 1/10)에 불과합니다.

5. 데이터 분석: 원본 데이터에서 인사이트 리포트 생성

CSV 또는 JSON 데이터를 주고 자동으로 통계를 내고, 트렌드를 발견하고, 이상치를 찾아 주간 보고서에 바로 붙여넣을 수 있는 리포트를 출력하게 합니다.

출력 예시 참고: 모델은 먼저 데이터 개요(행 수, 필드, 시간 범위)를 만들고, 핵심 지표 통계, 트렌드 설명, 이상 데이터 포인트 표시를 출력한 뒤 마지막에 실행 가능한 제안 2-3개를 제시합니다.

당신은 데이터 분석가입니다. 아래는 원본 데이터입니다. 다음 분석을 완료하고 리포트를 출력하세요:

1. 데이터 개요: 행 수, 필드 목록, 시간 범위, 데이터 완전성(결측률)
2. 핵심 지표 통계: 필드 유형에 따라 적절한 통계량을 자동 선택
   - 수치 필드: 평균, 중앙값, 최댓값, 최솟값, 표준편차
   - 범주형 필드: 상위 5개 범주 및 비율
3. 트렌드 분석: 시간 필드가 있으면 주/월 단위로 주요 지표를 집계하고 트렌드 설명
4. 이상 탐지: 평균에서 표준편차 2개를 초과해 벗어난 데이터 포인트 표시
5. 결론 및 제안: 실행 가능한 제안 2-3개

출력 형식: Markdown 리포트, 섹션 제목, 핵심 숫자는 굵게.

데이터:
[CSV 또는 JSON 데이터를 붙여넣으세요]

이 프롬프트로 데이터 분석하기 →

kimi-k3.1-pro, reasoning_effort: high. 참고: 약 $0.03 (입력 약 2000 token + 출력 약 2000 token). 데이터량이 많으면 입력 token도 그에 따라 증가합니다.

핵심: 데이터에 민감 정보(실제 사용자 ID, 휴대폰 번호, 키)가 없도록 하세요. 데이터 행 수가 많다면 앞쪽 200행이면 모델이 트렌드와 이상치를 발견하기에 충분합니다. K3.1 Pro는 전체 데이터 없이도 정확한 통계 결론을 제시할 수 있습니다.

프롬프트 공통 작성법

K3.1 Pro는 추론 모델이므로 "당신은 전문적인 XX입니다" 같은 만능 접두사를 쓸 필요가 없습니다. 세 가지 핵심:

1. 사고 과정이 아닌 구조를 주기: 출력 형식과 반드시 다뤄야 할 차원을 정의하고, 채우는 방법은 모델이 스스로 추론하게 하는 편이 단계를 하나하나 가르치는 것보다效果好
2. 구체적인 질문하기: "이 로그를 분석해 줘"보다 "이 500줄 로그에서 가장 먼저 나타난 이상, 그 상위 호출자, 그리고 수정에 어떤 설정을 바꿔야 하는지 찾아 줘"가 낫습니다.
3. reasoning_effort는 시나리오에 맞게 선택: 트러블슈팅과 장문 문서는 high 또는 max, 간단한 질의응답과 형식 변환은 low를 사용하면 비용 차이가 몇 배에 달합니다.

Kimi K3.1 Pro 모델 페이지 열기에서 시나리오를 고르고 프롬프트를 복사해 생성을 시작하세요.

Kimi K3.1 Pro 시리즈 글

• 모델 페이지
• API는 어떻게 쓰나요? 5분 만에 첫 호출 성공하기
• 가격 비교
• Kimi K3.1 Pro vs Claude Opus 5.5