주간 회의록(週会メモ)을 손글씨로 빠르게 적은 내용을 '결론 + ToDo' 형식으로 정리할 때마다 어떤 모델에 투입해야 할지 결정되지 않았습니다. 순위표는 타인의 문제 세트에는 강하지만, 자신의 메모에서 부족한 부분을 알려주지는 못합니다. 2026년 11월 4일, 동일한 자료, 동일한 3가지 질문, 그리고 동일한 OpenAI 호환 엔드포인트를 사용하여 Kimi K3.1 Pro, DeepSeek V4.1 Flash, GPT-5.1, Qwen3.8 Max를 나란히 놓고 비교했습니다. 본 글은 순위표가 아니라, 재현 절차와 당일 관찰 내용에 관한 것입니다.
매주 반복되는 작은 업무는 무엇인가
'도움이 되었다'고 판단하는 기준은 무엇인가
동일한 자료로 2~3가지 후보를 5분 동안 비교할 의향이 있는가
여기가 비어있다면, 어떤 것을 열어도 경험은 비슷합니다. 주간 회의록은 원문이 있고 결과물의 형태도 명확하기 때문에 초보자의 연습 문제에 적합합니다. 실패 사례도 구체적이며, 메모에 없는 담당자를 채워 넣으면 다음 주까지 업무가 이어집니다.
순서는 태스크 → 매일 열어보는 제품(プロダクト) → 모델 ID입니다. 회사명, 엔진명, 웹 앱은 별도의 계층입니다. 유료 플랜은 '무료로는 길이/횟수/쓰기가 부족하다'고 지적할 때까지 뒤로 미루었습니다.
약 40분 분량의 제품 주간 회의였습니다. 참석자는 제품 담당 아운(阿云), 개발 담당 샤오천(小陳), 디자인 담당 아마오(阿毛)입니다. 주제는 결제 페이지 QA, 쿠폰 표시, 회원 페이지 초안, 그리고 회의 후 주의사항인 '대외문서에 overlapping을 쓰지 않기'였습니다. 빈칸은 의도적입니다 (P1 번호 없음, 일부 ToDo에 담당자 부재).
고정 3가지 질문:
- 구어체 문장을 수정 없이 다듬기
- 결론 ≤ 3 + ToDo. 불분명한 부분은 '확인 필요(要確認)'로 표기.
- 붙여넣기용 표.
overlapping → '겹쳐서 표시'. 이메일 전송과 캘린더 기록은 금지
프롬프트는 필기 내용과 동일하게 간체 중국어였습니다. 아래의 일본어 내용은 절차와 결과에 대한 설명이며, 영어-일본어 프롬프트로 재측정한 것은 아닙니다.
4개의 사이트를 순서대로 열면 로그인 벽과 UI가 뒤섞입니다. 키는 1개, 기본 주소(base)는 https://api.crazyrouter.com/v1입니다.
바꾼 것은 model만었습니다.
ID는 kimi-k3.1-pro, deepseek-v4.1-flash, gpt-5.1, qwen3.8-max입니다. 호출 가능한 대화 모델은 chat models page에 있으며, 필드는 Crazyrouter docs를 참고했습니다. 측정하는 것은 이 인터페이스 상의 첫 텍스트이며, 각 사 앱 업로드나 플러그인은 범위 외입니다.
curl https://api.crazyrouter.com/v1/chat/completions \
-H "Authorization: Bearer $CRAZYROUTER_API_KEY" \
-H "Content-Type: application/json" \
...
model을 교체하여 같은 과정을 진행했습니다. Kimi K3.1 Pro는 미지원 샘플링 항목으로 HTTP 400 에러를 반환했고, 이를 제거하자 정상 응답으로 돌아왔습니다. 재현할 때는 상대방의 오류 문구를 정답으로 간주합니다. 키는 환경 변수로 설정했습니다.
4개의 초안 모두 사용할 수 있는 수준이었습니다. 차이는 실력보다는 보완하는 대담함에 있었습니다.
| 모델 | 첫인상 | 먼저 보는 부분 |
|---|
| Kimi K3.1 Pro | 짧고 명료함. '확인 필요'가 많음 | 담당자 단정 여부 (늦더라도) |
| ... | | |
| DeepSeek V4.1 Flash는 '이번 주 목요일에 가능할 것으로 예상됨'을 구체적인 날짜로 지정하고, 결제 페이지 QA 담당자를 샤오천으로 한 사례가 있었습니다. 원문은 '개발팀이 목요일이라면 가능하다'까지만 되어 있어 담당자 이름은 없습니다. GPT-5.1도 유사하게 채워 넣었습니다. Kimi K3.1 Pro는 빈칸을 남기기 쉬웠고, Qwen3.8 Max는 사내 동기화에 가까운 문장이었습니다. | | |
사용법: 빠른 초안 작성 → DeepSeek V4.1 Flash 또는 GPT-5.1. 침묵의 창작물을 줄이고 싶을 때 → Kimi K3.1 Pro. 사내용 중국어 문서 → Qwen3.8 Max. 게시 전에 원문으로 담당자와 날짜를 체크(勾)하는 것이 공통 규칙입니다.
매번 확인해야 할 것은 목적・자료・엄격한 제한・결과물의 형태입니다. 질문 3의 골격 (실제 실행은 중국어):
아래 필기 내용에서, 결론은 최대 3가지로, 이어서 ToDo 표(사항/담당자/기한 또는 상태/비고)를 작성합니다. 불분명한 부분은 '확인 필요', 추측 금지. 대외적으로는 overlapping을 '겹쳐서 표시'로 합니다. 이메일을 보내지 않습니다. 캘린더에 기록하지 않습니다.
모호할 때는 '결과를 바꿀 수 있는 질문 5가지'부터 시작하여, 수정은 '2번째 줄의 담당자를 확인 필요로 되돌리기'와 같이 지적합니다. 4개 모델 모두 통과했습니다. 차이는 보완하는 담력에 있으며, 신(神) 프롬프트의 유무가 아닙니다.
4개 모델 모두 Markdown/표는 출력할 수 있었습니다. 캘린더를 열거나 이메일을 보내지는 않았습니다. “일정 확인”은 문구일 뿐, 실행 증거가 아닙니다.
형식 확인 → 재독 → 부족 항목 표시 → 파일 생성 → 자체 점검까지의 워크플로우를 구현하고 싶다면 Agent 시스템을 고려해야 합니다(실제 도구 전제). 매주 같은 사내 규칙이라면 Skill(대부분 SKILL.md + 템플릿)을 사용합니다. 캘린더나 문서와 관련된 작업은 MCP 방식의 연결이 필요하며, 프로토콜, 구체 서비스, 권한은 별개의 문제입니다. “MCP 지원”이라는 것이 모든 앱의 마스터 키는 아닙니다. 순서는 동일 조건 비교 및 원문 대조를 습관화하는 것 → 이후 부족한 능력을 파악하여 추가하는 것입니다.
- 매일 사용할 수 있는 어시스턴트 1개를 결정한다.
- 오늘 실제 주간 회의록을 사용한다.
- 목적, 배경, 제한 사항, 결과 형식 등을 하나의 메시지에 작성한다.
- 두 번째 시도에서는 구체적인 한 가지 항목만 수정하도록 지시한다.
- 규칙이 매주 확립되면 Skill화하고; 캘린더/문서가 필요해진 후에 MCP나 Agent를 사용한다.
주의할 점: ‘열람 가능’ ≠ ‘담당 검증’, ‘긴 사고 과정 표시’ ≠ ‘첨부되지 않은 파일 읽기’, ‘한 번의 약한 초안’ ≠ ‘즉각적인 브랜드 전환’—먼저 자료, 지시 사항, 과도한 보완을 분리해야 합니다.
주간 회의록은 원문과 결과물이 있기 때문에 비교 대상으로 공정합니다. 4개 모델 모두 첫 시도는 초안이 될 수 있습니다. 막아야 할 것은 과잉 보완입니다. 프롬프트의 완성도가 기준점을 정하며, Agent/Skill/MCP는 후속 단계입니다. 게시 전 원문을 확인하는 것이 모델을 교체하는 것보다 효과적일 때가 많습니다.
다음 채팅에서도 회의록 전에 다음과 같이 붙이겠습니다. “이것이 이번 주 회의록입니다. 이것이 원하는 형식입니다. 불분명한 점은 확인이 필요합니다. 이메일은 보내지 않습니다.” 같은 유형의 요청은 https://api.crazyrouter.com/v1을 통해 진행합니다. 각 사의 웹 앱 업로드나 플러그인은 범위를 벗어납니다.
