Kimi K3.1 Pro 사용하는 방법

Kimi K3.1 Pro를 사용하려면, 액세스 경로를 선택하고 모델과 새 대화를 시작한 다음, 필요한 자료를 바탕으로 특정 작업을 지정하세요. Kimi의 제품과 API를 통해 모델에 액세스할 수 있습니다. Kimi K3.1 Pro는 iWeaver에서도 제공되며, 해당 서비스에서는 모델의 무료 체험판을 제공합니다.

가장 유용한 첫 작업은 확인할 수 있는 결과를 만들어야 합니다. 예를 들어 두 문서를 비교하거나 어려운 구절을 설명하거나, 재현 가능한 코딩 문제를 수정하는 작업이 좋습니다. 이 가이드는 그런 작업을 단계별로 안내하면서, 매번 처음부터 다시 시작하지 않고도 결과를 어떻게 더 정교하게 다듬을 수 있는지 보여줍니다.

Kimi K3.1 Pro를 어디에서 사용할지 선택하기

시작하기 전에 출시 관련 세부 사항을 확인하려면 Kimi K3.1 Pro에서 새로 나온 내용을 읽어보세요.

Kimi의 출시 공지에는 웹사이트, 앱, Kimi Work, Kimi Code, API를 통한 액세스가 나열되어 있습니다. 완료하려는 작업에 가장 적합한 경로를 선택하세요.

이러한 경로들은 계정 요구사항, 사용 허용량, 제어 방식이 각각 다릅니다. 한 서비스에서 모델에 액세스했다고 해서 다른 서비스의 이용 조건이 그대로 성립되지는 않습니다.

첫 시도라면 목표가 통합(integration)인 경우가 아니라면 API 설정은 피하세요. 채팅이나 문서 워크플로에서 확인하고 완료할 수 있는 작업부터 시작하세요.

작업을 정의하고, 모델을 선택하고, 소스를 제공한 뒤 결과를 확인하고 다듬으세요.

1단계: 자료를 추가하기 전에 결과를 먼저 정의하기

무엇을 받길 원하는지 적어두세요. “이 파일들을 분석해줘”는 너무 열려 있습니다. 반면 “제안된 런치 플랜을 인터뷰 노트와 비교하고, 뒷받침되지 않는 가정을 식별해줘”는 모델에게 더 명확한 역할을 줍니다.

유용한 작업 설명에는 네 가지 요소가 포함됩니다.

• 답을 얻기 위해 필요한 질문.
• 답이 활용해야 하는 소스.
• 최종 출력의 형태.
• 특별히 주의가 필요한 세부사항.

예를 들면:

런치 플랜을 고객 인터뷰 노트와 비교하세요. 제안 기능의 표, 인터뷰 근거, 해결되지 않은 질문을 작성하세요. 첨부된 자료만 사용하세요. 문서에 명시된 사실과 당신의 제안을 분리하세요.

첫 할당(과업)은 좁게 시작하세요. 모델이 소스를 이해하는지 확인한 뒤에 확장할 수 있습니다.

2단계: 새 세션을 시작하고 모델을 선택하기

두 가지 변형(버전) 중 무엇을 선택할지 고민 중이라면 K3.1 Pro vs. Highspeed를 참고하세요.

서비스에서 제공되는 모델 컨트롤에서 Kimi K3.1 Pro를 선택하세요. Kimi Code CLI에서 공식 모델 선택자는 /model 입니다. 해당 문서에서는 새로운 모델로 전환할 때 새 세션을 권장합니다.

모델이 보이지 않는다면, 계정에 포함된 권한(entitlement)과 현재 모델 목록을 확인하세요. 공식 Kimi 클라이언트에서는 문서에 설명된 것처럼 재시작 또는 다시 로그인하면 사용 가능 여부가 갱신될 수 있습니다. 서드파티 서비스라면 자체 롤아웃 프로세스가 있을 수 있습니다.

서로 다른 작업에서 생긴 가정을 포함한 긴 대화를 계속 이어가지 마세요. 새 세션을 사용하면 올바른 맥락을 제공하고 응답을 판단하기가 더 쉬워집니다.

3단계: 소스를 사용 가능한 순서로 제공하기

파일 이름을 명확히 짓고, 서로 어떤 관계인지 설명하세요. 최신 정책과 이전 정책은 각각 그렇게 라벨링해야 합니다. 인터뷰 노트는 귀속(attribution)에 중요하다면 발화자 이름이나 식별자를 유지하세요.

모델이 긴 답변을 쓰기 전에 소스 세트를 점검하도록 요청하세요:

사용할 수 있는 문서 목록, 각 문서의 추정 날짜, 그리고 각 문서가 어떤 질문에 답을 돕는지를 나열하세요. 읽을 수 없는 파일이나 비교를 막는 누락 정보를 표시하세요.

이 체크포인트는 읽을 수 없는 첨부파일이나 버전 불일치를 초기에 드러낼 수 있습니다. 또한 모델이 그 위에 논리를 구성하기 전에 범위를 수정할 기회도 제공합니다.

Kimi는 큰 컨텍스트 윈도우를 광고하지만, 사용 가능량은 액세스 경로와 요금제에 따라 달라집니다. 한 번의 업로드로 프로젝트의 모든 파일이 들어갈 수 있다고 가정하지 마세요. 서비스의 실제 제한을 확인하세요.

4단계: 매끈한 보고서보다 먼저 근거를 요청하기

문서 작업에서는 먼저 증거 표를 시작하세요. iWeaver에서는 AI Document Summarizer를 사용해 K3.1 Pro에 집중된 비교를 요청하기 전에 자료에 방향을 잡을 수 있습니다.

이 프롬프트를 시도해 보세요:

연구 질문에 답하기 위해 필요한 근거를 추출하세요. 각 항목에 대해 확인할 수 있는 소스 이름, 제가 체크할 수 있는 문장 또는 위치, 그리고 의미를 바꾸는 어떤 조건(자격/한정)을 함께 제시하세요. 충돌되는 내용은 별도로 나열하세요. 아직 최종 보고서는 작성하지 마세요.

표를 확인해 보세요. 각 구절이 주장(케이스)을 뒷받침하나요? 한 고객에 대한 진술이 모든 고객에 대한 진술로 바뀌지는 않았나요? 예측이 관찰된 결과처럼 처리되지는 않았나요?

근거가 충분해지면 산출물을 요청하세요:

검토한 증거를 600자(단어) 분량의 브리핑으로 바꿔 주세요. 그 브리핑에서 지지하는 결정을 먼저 제시하고, 가장 강한 근거를 설명한 뒤 해결되지 않은 질문으로 마무리하세요. 소스 자료에서의 불확실성을 그대로 유지하세요.

두 단계 프로세스를 사용하면, 논리가 매끈한 문장으로 굳기 전에 추론을 바로잡을 수 있는 기회가 생깁니다.

5단계: 타깃형 후속 요청 활용하기

답이 빗나갔을 때는 문제를 정확히 찾아내세요. “다시 해봐”는 방향을 거의 주지 않습니다.

응답이 너무 광범위하다면, 하나의 의사결정만 다루도록 요청하세요. 근거와 의견이 섞여 있다면 섹션을 분리해 달라고 요청하세요. 근거 없는 결론이라면, 어떤 소스가 그 결론을 세워주고 있는지, 그리고 더 약한 표현이라면 정당화될 수 있는지 물어보세요.

예를 들면:

세 번째 문단의 권고안을 수정하세요. 인터뷰 노트는 관심이 있음을 보여주지만, 지불 의사가 있음을 보여주지는 않습니다. 그 구분을 명확히 유지하고, 이를 해소할 근거가 무엇인지 설명하세요.

PDF의 시각적 개요를 원한다면 PDF to Mind Map 워크플로가 주제 정리에 도움이 될 수 있습니다. 가지(branch) 라벨을 상세한 주장처럼 의존하기 전에, 소스를 다시 확인하세요.

코딩에 K3.1 Pro 사용하기

같은 작업에 대해 다른 모델을 평가하고 있다면 Kimi K3.1 Pro vs. Claude Opus 5.5의 작업 기준을 사용하세요.

코딩 작업에는 재현 가능한 시작점과 관찰 가능한 마무리를 제공하세요. 에러, 기대 동작, 관련 프로젝트 제약을 포함하세요.

실패하는 date-parser 테스트를 재현하세요. 원인을 식별한 뒤 가장 작은 정당한 변경을 적용하고, 관련 체크를 실행하세요. 수정으로 인해 달라지는 동작과, 확인하지 못한 케이스가 있다면 그것도 설명하세요.

변경된 파일과 테스트 결과를 검토하세요. 구현이 그 설명을 뒷받침할 때에만 자신감 있는 설명이 유용합니다.

통합(인테그레이션)을 위해서는 액세스 채널에 해당하는 문서에서 정확한 모델 식별자와 엔드포인트를 복사하세요. Kimi Code와 일반 API는 채널별 명명 규칙을 사용합니다. 채팅 메뉴의 표시 이름을 API 요청에 대신 넣지 마세요.

첫 실행에서의 문제 해결

완료한 한 가지 작업으로 다음에 무엇을 할지 결정하세요. K3.1 Pro가 신뢰할 만한 증거 표를 만들지만 보고서가 초점 없이 작성된다면, 글쓰기 지침을 다듬어 보세요. 소스의 세부가 빠졌다면 먼저 소스 정리와 체크포인트를 개선하세요. 작은 작업에서 신뢰할 수 있는 결과가 나온 뒤에 작업량을 확장하세요.