diff --git a/docs/research/thesis/quant/analysis/q-gemma4-26b-UD-IQ2_M.json b/docs/research/thesis/quant/analysis/q-gemma4-26b-UD-IQ2_M.json index b909284..92f29e4 100644 --- a/docs/research/thesis/quant/analysis/q-gemma4-26b-UD-IQ2_M.json +++ b/docs/research/thesis/quant/analysis/q-gemma4-26b-UD-IQ2_M.json @@ -1,37 +1,40 @@ { "q-gemma4-26b-UD-IQ2_M": { "followup": { - "calls": 40, + "calls": 80, "success_pct": 100.0, "tag_compliance_pct": 100.0, "intent_accuracy_pct": 92.5, "intent_misses": { "f-weak-vague": [ + "DONT_KNOW", "DONT_KNOW" ], "f2-offtopic-weak": [ + "DONT_KNOW", "DONT_KNOW" ], "f2-repeat-history-weak": [ + "DONT_KNOW", "DONT_KNOW" ] }, "score_label_accuracy_pct": 96.3, - "correctness_rule_accuracy_pct": 96.2, - "discrimination_gap_backend": 5.0, + "correctness_rule_accuracy_pct": 94.2, + "discrimination_gap_backend": 4.5, "discrimination_gap_personality": 3.0, - "question_len_median": 79.5, - "question_len_le60_pct": 20.0, + "question_len_median": 79.0, + "question_len_le60_pct": 16.2, "non_korean_script_pct": 0.0, - "latency_median": 7.98, + "latency_median": 8.0, "latency_p90": 9.83, - "ttft_median": 3.86, - "ttft_p90": 5.45, + "ttft_median": 3.88, + "ttft_p90": 5.53, "over_3s_pct": 100.0, "over_10s_timeout_pct": 7.5 }, "questions": { - "calls": 15, + "calls": 30, "success_pct": 100.0, "errors": [], "count_exact_pct": 100.0, @@ -42,20 +45,20 @@ "evidence_grounded_pct": 100.0, "near_duplicate_pair_pct": 0.0, "repeated_recent_question_count": 0, - "question_len_le80_pct": 32.9, + "question_len_le80_pct": 35.4, "non_korean_script_pct": 0.0, "markdown_in_question_pct": 0.0, - "long_context_success": "1/1", - "latency_median": 57.63, - "latency_p90": 70.64 + "long_context_success": "2/2", + "latency_median": 57.84, + "latency_p90": 68.41 }, "coaching": { - "calls": 15, + "calls": 30, "success_pct": 100.0, "invented_numbers_pct": 6.7, "non_korean_script_pct": 0.0, "comment_one_line_pct": 100.0, - "latency_median": 30.15, + "latency_median": 29.99, "latency_p90": 35.09 } } diff --git a/docs/research/thesis/quant/analysis/q-gemma4-e4b-Q4_K_M.json b/docs/research/thesis/quant/analysis/q-gemma4-e4b-Q4_K_M.json new file mode 100644 index 0000000..c1ca30e --- /dev/null +++ b/docs/research/thesis/quant/analysis/q-gemma4-e4b-Q4_K_M.json @@ -0,0 +1,52 @@ +{ + "q-gemma4-e4b-Q4_K_M": { + "followup": { + "calls": 40, + "success_pct": 100.0, + "tag_compliance_pct": 100.0, + "intent_accuracy_pct": 100.0, + "intent_misses": {}, + "score_label_accuracy_pct": 88.9, + "correctness_rule_accuracy_pct": 96.2, + "discrimination_gap_backend": 3.0, + "discrimination_gap_personality": 2.0, + "question_len_median": 82.5, + "question_len_le60_pct": 10.0, + "non_korean_script_pct": 0.0, + "latency_median": 2.72, + "latency_p90": 4.51, + "ttft_median": 1.42, + "ttft_p90": 2.8, + "over_3s_pct": 40.0, + "over_10s_timeout_pct": 0.0 + }, + "questions": { + "calls": 15, + "success_pct": 100.0, + "errors": [], + "count_exact_pct": 100.0, + "mode_category_fit_pct": 86.7, + "job_category_valid_pct": 93.3, + "multi_job_coverage_pct": 100.0, + "evidence_present_when_required_pct": 100.0, + "evidence_grounded_pct": 100.0, + "near_duplicate_pair_pct": 0.0, + "repeated_recent_question_count": 0, + "question_len_le80_pct": 11.4, + "non_korean_script_pct": 0.0, + "markdown_in_question_pct": 0.0, + "long_context_success": "1/1", + "latency_median": 24.13, + "latency_p90": 29.87 + }, + "coaching": { + "calls": 15, + "success_pct": 100.0, + "invented_numbers_pct": 0.0, + "non_korean_script_pct": 0.0, + "comment_one_line_pct": 100.0, + "latency_median": 11.28, + "latency_p90": 12.86 + } + } +} diff --git a/docs/research/thesis/quant/judge-pilot.jsonl b/docs/research/thesis/quant/judge-pilot.jsonl new file mode 100644 index 0000000..514f561 --- /dev/null +++ b/docs/research/thesis/quant/judge-pilot.jsonl @@ -0,0 +1,240 @@ +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-clarification", "ratings": {"q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "지원자가 질문을 쉽게 다시 해달라고 요청했으나, 원본 질문을 그대로 반복하며 오히려 지원자에게 쉽게 설명해달라고 요구하여 문맥을 파악하지 못했습니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "지원자의 재설명 요청을 반대로 해석함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "질문이 길다는 피드백에 맞춰 두 가지 복합 질문 중 하나(CPU 70% 기준)로 좁혀서 다시 질문한 점은 적절하나, 문장이 여전히 다소 깁니다.", "relevance": 3, "depth": 3, "language": 4, "overall": 3, "issue": "질문을 하나로 좁혔으나 여전히 문장이 다소 김"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자가 질문을 쉽게 다시 해달라고 요청했으나, 원본 질문을 그대로 반복하며 오히려 지원자에게 쉽게 설명해달라고 요구하여 문맥을 파악하지 못했습니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "지원자의 재설명 요청을 반대로 해석함"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "질문이 길다는 요청에 '각각' 설명해달라고 덧붙였을 뿐, 원본 질문의 복잡한 구조를 전혀 쉽게 풀어주지 않고 그대로 반복했습니다.", "relevance": 2, "depth": 2, "language": 4, "overall": 2, "issue": "원본 질문을 그대로 반복하여 쉽게 재설명하지 않음"}, "q-gemma4-e4b-Q8_0": {"rationale": "지원자가 질문을 쉽게 다시 해달라고 요청했으나, 원본 질문을 토씨 하나 바꾸지 않고 그대로 반복하여 대화의 흐름에 맞지 않습니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "원본 질문을 그대로 반복함"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자가 질문을 쉽게 다시 해달라고 요청했으나, 원본 질문을 그대로 반복하며 오히려 지원자에게 쉽게 설명해달라고 요구하여 문맥을 파악하지 못했습니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "지원자의 재설명 요청을 반대로 해석함"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 0, "q-qwen3-4b-Instruct-2507-Q3_K_M": 1, "q-qwen3-4b-Instruct-2507-Q8_0": 2, "q-gemma4-e4b-Q3_K_M": 3, "q-gemma4-e4b-Q8_0": 4, "q-qwen3-4b-Instruct-2507-Q4_K_M": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 98, "q-qwen3-4b-Instruct-2507-Q3_K_M": 116, "q-qwen3-4b-Instruct-2507-Q8_0": 98, "q-gemma4-e4b-Q3_K_M": 100, "q-gemma4-e4b-Q8_0": 97, "q-qwen3-4b-Instruct-2507-Q4_K_M": 98}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-clarification", "ratings": {"q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자는 면접관에게 질문을 쉽게 다시 해달라고 요청했으나, 오히려 지원자에게 원문 그대로 쉽게 설명해 달라고 요구하여 대화의 문맥을 완전히 상실했습니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "지원자의 재설명 요청 의도 파악 실패"}, "q-gemma4-e4b-Q8_0": {"rationale": "질문을 쉽게 풀어주지 않고 원문을 그대로 반복했으며, 지원자가 아직 답변하지 않았음에도 '다시 설명해 주시겠어요'라고 어색하게 대응했습니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "질문 단순화 요청 무시 및 어색한 호응"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "질문이 길다는 지원자의 말에 '각각 설명해 달라'고 분리하려는 시도는 있었으나, 질문 내용을 전혀 쉽게 풀어주지 않고 원문을 앵무새처럼 반복했습니다.", "relevance": 2, "depth": 1, "language": 4, "overall": 1, "issue": "질문을 쉽게 재구성하지 않고 원문 반복"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자는 면접관에게 질문을 쉽게 다시 해달라고 요청했으나, 오히려 지원자에게 원문 그대로 쉽게 설명해 달라고 요구하여 대화의 문맥을 완전히 상실했습니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "지원자의 재설명 요청 의도 파악 실패"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "질문을 쉽게 다시 해달라는 지원자의 요청을 완전히 무시하고, 오히려 특정 부분에 대해 더 길고 복잡한 형태의 꼬리질문을 던졌습니다.", "relevance": 1, "depth": 2, "language": 4, "overall": 1, "issue": "단순화 요청을 무시하고 더 복잡한 질문 제시"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "지원자는 면접관에게 질문을 쉽게 다시 해달라고 요청했으나, 오히려 지원자에게 원문 그대로 쉽게 설명해 달라고 요구하여 대화의 문맥을 완전히 상실했습니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "지원자의 재설명 요청 의도 파악 실패"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 0, "q-gemma4-e4b-Q8_0": 1, "q-gemma4-e4b-Q3_K_M": 2, "q-qwen3-4b-Instruct-2507-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q3_K_M": 4, "q-qwen3-4b-Instruct-2507-Q5_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 98, "q-gemma4-e4b-Q8_0": 97, "q-gemma4-e4b-Q3_K_M": 100, "q-qwen3-4b-Instruct-2507-Q8_0": 98, "q-qwen3-4b-Instruct-2507-Q3_K_M": 116, "q-qwen3-4b-Instruct-2507-Q5_K_M": 98}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-clarification", "ratings": {"q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "재설명 요청을 정확히 분류하고 질문을 되짚었으나, '쉽게'라는 말만 붙였을 뿐 원 질문을 거의 그대로 반복해 실제로 풀어서 설명하지 못했다. 반응 지연 vs 예측 가능한 피크라는 핵심 축을 평이한 말로 바꿔 주지 못한 점이 아쉽다.", "relevance": 3, "depth": 2, "language": 4, "overall": 3, "issue": "원 질문 재진술에 그쳐 실질적인 쉬운 설명이 없다"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "'각각'으로 두 갈래(임계값 근거 / 사전 스케일아웃 이유)를 분리해 답변 구조를 살짝 안내한 점이 다른 후보보다 낫다. 다만 용어를 쉬운 말로 풀지는 못해 재설명 요청을 완전히 해소하지는 못했다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "질문을 분리했을 뿐 용어 자체는 풀어 주지 않음"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "CLARIFICATION으로 분류하면서도 재설명 대신 새 질문(당시 상황·트래픽 데이터)으로 전환해 의도 대응이 어긋난다. 문장도 길고 '구체적인 상황이나' 부분이 어색해 이해를 더 어렵게 만든다.", "relevance": 2, "depth": 3, "language": 3, "overall": 2, "issue": "재설명 요청을 무시하고 새 질문으로 전환"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "의도 분류는 맞지만 A와 동일하게 원 질문을 거의 그대로 되풀이해 '쉽게'라는 약속을 지키지 못했다. 메트릭 수집·파드 기동 지연 같은 핵심을 풀어 설명하는 보조 문구가 없다.", "relevance": 3, "depth": 2, "language": 4, "overall": 3, "issue": "표현만 바꾼 동일 질문 반복"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "분류는 적절하나 내용은 원 질문의 단순 재진술로, 지원자가 막힌 지점을 해소해 주지 못한다. 문장은 간결하고 자연스럽다.", "relevance": 3, "depth": 2, "language": 4, "overall": 3, "issue": "쉬운 말로 풀어 주는 재설명이 부재"}, "q-gemma4-e4b-Q8_0": {"rationale": "'다시 설명해 주시겠어요'로 원문을 그대로 반복해 재설명 요청에 대한 배려가 가장 적다. 질문 분해나 용어 풀이가 전혀 없어 대화가 제자리에 머문다.", "relevance": 2, "depth": 2, "language": 4, "overall": 2, "issue": "난이도 조정 없이 동일 질문을 그대로 재요청"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 0, "q-gemma4-e4b-Q3_K_M": 1, "q-qwen3-4b-Instruct-2507-Q3_K_M": 2, "q-qwen3-4b-Instruct-2507-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q4_K_M": 4, "q-gemma4-e4b-Q8_0": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 98, "q-gemma4-e4b-Q3_K_M": 100, "q-qwen3-4b-Instruct-2507-Q3_K_M": 116, "q-qwen3-4b-Instruct-2507-Q8_0": 98, "q-qwen3-4b-Instruct-2507-Q4_K_M": 98, "q-gemma4-e4b-Q8_0": 97}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-clarification", "ratings": {"q-gemma4-e4b-Q8_0": {"rationale": "의도 분류는 맞지만 직전 질문을 거의 그대로 되풀이해 '쉽게 다시 설명' 요구를 충족하지 못했다. 질문이 길어서 못 알아들은 지원자에게 동일 부담을 다시 준다.", "relevance": 2, "depth": 2, "language": 4, "overall": 2, "issue": "직전 질문 문구를 그대로 반복해 재설명 효과가 없음"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "CLARIFICATION 대응으로 방향은 맞고 문장은 간결하나, 표현만 바꿨을 뿐 질문을 쪼개거나 용어를 풀어주지 않았고 '쉽게 설명해 달라'는 요구를 오히려 지원자에게 되돌렸다.", "relevance": 3, "depth": 2, "language": 4, "overall": 3, "issue": "질문을 분해·평이화하지 않아 재설명이라 보기 어려움"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "B와 동일한 출력으로, 의도 파악은 적절하지만 재설명 없이 같은 질문을 재차 묻는 수준이다. 기대 신호(반응 지연 vs 예측 가능 피크)로 유도하는 힌트도 없다.", "relevance": 3, "depth": 2, "language": 4, "overall": 3, "issue": "핵심 축을 풀어 설명하는 힌트가 전혀 없음"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "쉬운 재설명 대신 당시 수치 근거와 트래픽 패턴 데이터를 새로 캐물어, 이해를 못 한 지원자에게 더 복잡한 질문을 던졌다. 문장도 길고 사전 스케일아웃 축이 흐려졌다.", "relevance": 2, "depth": 3, "language": 3, "overall": 2, "issue": "재설명 요청에 더 길고 어려운 질문으로 응답"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "'각각'을 넣어 두 논점을 나눠 답하도록 유도한 점이 미세하게 낫고 문장도 간결하다. 다만 용어 풀이나 지연·예측 구분 힌트가 없어 여전히 재설명이라 하기엔 약하다.", "relevance": 3, "depth": 2, "language": 4, "overall": 3, "issue": "질문을 두 갈래로 나눴을 뿐 평이하게 풀어주진 못함"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "B, C와 같은 문장으로, 의도 대응은 무난하지만 실질적 재설명·힌트가 없어 변별력이 낮다. 간결성과 한국어 자연스러움은 양호하다.", "relevance": 3, "depth": 2, "language": 4, "overall": 3, "issue": "동일 질문 재제시 수준으로 추가 정보 제공 없음"}}, "positions": {"q-gemma4-e4b-Q8_0": 0, "q-qwen3-4b-Instruct-2507-Q4_K_M": 1, "q-qwen3-4b-Instruct-2507-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q3_K_M": 3, "q-gemma4-e4b-Q3_K_M": 4, "q-qwen3-4b-Instruct-2507-Q5_K_M": 5}, "ordering": 1, "output_chars": {"q-gemma4-e4b-Q8_0": 97, "q-qwen3-4b-Instruct-2507-Q4_K_M": 98, "q-qwen3-4b-Instruct-2507-Q8_0": 98, "q-qwen3-4b-Instruct-2507-Q3_K_M": 116, "q-gemma4-e4b-Q3_K_M": 100, "q-qwen3-4b-Instruct-2507-Q5_K_M": 98}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-clarification", "ratings": {"q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "재설명 요청 의도는 맞게 분류했지만, 원 질문을 거의 그대로 반복해 쉽게 풀어주지 못했습니다. HPA 반응 지연과 예측 가능한 피크라는 핵심 구분도 드러나지 않습니다.", "relevance": 3, "depth": 2, "language": 4, "overall": 3, "issue": "질문을 쉽게 바꾸지 않고 원문을 반복함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "CPU 70%의 근거와 트래픽 패턴 데이터로 좁힌 점은 일부 관련 있지만, 지원자의 재설명 요청에 비해 질문이 더 복잡해졌습니다. HPA 지연과 사전 스케일아웃의 대비도 명확하지 않습니다.", "relevance": 2, "depth": 3, "language": 4, "overall": 2, "issue": "재설명 요청에 맞지 않게 추가 심화 질문을 던짐"}, "q-gemma4-e4b-Q8_0": {"rationale": "직전 질문을 다시 묻고는 있지만 표현이 거의 동일해 지원자가 요청한 쉬운 설명이 아닙니다. 기대 신호인 HPA 지연과 예측 피크의 차이를 풀어내지 못했습니다.", "relevance": 2, "depth": 2, "language": 4, "overall": 2, "issue": "원 질문의 단순 반복에 가까움"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "재설명 요청 의도는 맞게 분류했지만, 원 질문을 거의 그대로 반복해 쉽게 풀어주지 못했습니다. HPA 반응 지연과 예측 가능한 피크라는 핵심 구분도 드러나지 않습니다.", "relevance": 3, "depth": 2, "language": 4, "overall": 3, "issue": "질문을 쉽게 바꾸지 않고 원문을 반복함"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "재설명 요청 의도는 맞게 분류했지만, 원 질문을 거의 그대로 반복해 쉽게 풀어주지 못했습니다. HPA 반응 지연과 예측 가능한 피크라는 핵심 구분도 드러나지 않습니다.", "relevance": 3, "depth": 2, "language": 4, "overall": 3, "issue": "질문을 쉽게 바꾸지 않고 원문을 반복함"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "두 질문을 ‘각각’ 나눠 달라고 해 구조는 조금 더 명확해졌지만, 여전히 쉬운 재설명으로는 부족합니다. HPA가 늦게 반응할 수 있다는 핵심 배경을 풀어주지 못했습니다.", "relevance": 3, "depth": 2, "language": 5, "overall": 3, "issue": "분리만 했을 뿐 핵심 개념을 쉽게 설명하지 않음"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 0, "q-qwen3-4b-Instruct-2507-Q3_K_M": 1, "q-gemma4-e4b-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q4_K_M": 3, "q-qwen3-4b-Instruct-2507-Q8_0": 4, "q-gemma4-e4b-Q3_K_M": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 98, "q-qwen3-4b-Instruct-2507-Q3_K_M": 116, "q-gemma4-e4b-Q8_0": 97, "q-qwen3-4b-Instruct-2507-Q4_K_M": 98, "q-qwen3-4b-Instruct-2507-Q8_0": 98, "q-gemma4-e4b-Q3_K_M": 100}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-clarification", "ratings": {"q-gemma4-e4b-Q3_K_M": {"rationale": "지원자가 재설명을 요청했는데 원 질문을 거의 그대로 반복해 쉽게 풀어주지 못했습니다. 다만 CPU 70% 근거와 사전 스케일아웃 이유를 각각 묻는 구조는 유지했습니다.", "relevance": 3, "depth": 2, "language": 4, "overall": 2, "issue": "재설명 요청에 대해 질문을 쉽게 바꾸지 않고 반복함"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "재설명 요청에 '쉽게 설명해 달라'는 표현만 붙였을 뿐, 질문 자체는 원문과 거의 같습니다. HPA 지연과 예측 피크의 구분도 드러나지 않습니다.", "relevance": 2, "depth": 1, "language": 4, "overall": 2, "issue": "쉽게 설명하지 않고 원 질문을 반복함"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "B와 동일하게 원 질문을 거의 그대로 반복하며, 지원자가 이해할 수 있도록 풀어쓴 내용이 없습니다. 기대 신호인 HPA 반응 지연과 사전 대응의 차이도 반영되지 않았습니다.", "relevance": 2, "depth": 1, "language": 4, "overall": 2, "issue": "재설명 역할을 수행하지 못함"}, "q-gemma4-e4b-Q8_0": {"rationale": "원 질문을 다시 말해 달라는 형태라 지원자의 요청에 맞지 않고, 쉬운 재구성이 없습니다. 내용상 핵심 구분이나 추가 설명도 없습니다.", "relevance": 2, "depth": 1, "language": 4, "overall": 2, "issue": "원 질문 반복에 그쳐 이해를 돕지 못함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "CPU 70% 수치 근거와 트래픽 패턴 데이터라는 구체 축을 짚어 일부 변별력은 있습니다. 하지만 재설명 요청에 비해 질문이 더 복잡해졌고, HPA 반응 지연과 사전 스케일아웃의 관계는 빠졌습니다.", "relevance": 3, "depth": 3, "language": 3, "overall": 3, "issue": "재설명보다 새로운 심화 질문에 가까움"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "B, C와 동일하게 '쉽게 설명'이라는 말만 추가했을 뿐 실제로 쉽게 풀어 설명하지 않습니다. 기대 신호를 유도하는 구조도 부족합니다.", "relevance": 2, "depth": 1, "language": 4, "overall": 2, "issue": "지원자의 clarification 요청에 실질적으로 대응하지 않음"}}, "positions": {"q-gemma4-e4b-Q3_K_M": 0, "q-qwen3-4b-Instruct-2507-Q8_0": 1, "q-qwen3-4b-Instruct-2507-Q4_K_M": 2, "q-gemma4-e4b-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q3_K_M": 4, "q-qwen3-4b-Instruct-2507-Q5_K_M": 5}, "ordering": 1, "output_chars": {"q-gemma4-e4b-Q3_K_M": 100, "q-qwen3-4b-Instruct-2507-Q8_0": 98, "q-qwen3-4b-Instruct-2507-Q4_K_M": 98, "q-gemma4-e4b-Q8_0": 97, "q-qwen3-4b-Instruct-2507-Q3_K_M": 116, "q-qwen3-4b-Instruct-2507-Q5_K_M": 98}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-confirm-short", "ratings": {"q-gemma4-e4b-Q8_0": {"rationale": "지원자의 긍정 대답을 바탕으로 폴링 시 데이터 조회 메커니즘(오프셋, 상태값 등)을 묻는 매우 적절하고 깊이 있는 꼬리질문입니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "없음"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자가 방금 '네'라고 대답한 직전 질문을 그대로 다시 묻고 있어 대화의 흐름을 끊습니다.", "relevance": 2, "depth": 2, "language": 4, "overall": 2, "issue": "직전 질문 불필요하게 반복"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "폴링 주기나 지연 시간에 대한 질문 의도는 좋으나, '특정 메시지나 트랜잭션에 대해'라는 표현이 다소 어색하고 장황합니다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "다소 모호하고 장황한 표현"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자가 방금 대답한 직전 질문을 토씨 하나 틀리지 않고 그대로 반복하여 면접이 진행되지 않습니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "직전 질문 완벽히 반복 (사용 불가)"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "직전 질문을 반복하고 있으며, 프로세스에 존칭을 사용하는('실행되셨나요') 어법 오류가 있습니다.", "relevance": 2, "depth": 2, "language": 2, "overall": 2, "issue": "사물 존칭 오류 및 질문 반복"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "이미 확인된 사실을 다시 묻는 문장으로 시작하며, 이어지는 질문도 다소 포괄적입니다.", "relevance": 3, "depth": 3, "language": 4, "overall": 3, "issue": "불필요한 확인 질문 포함"}}, "positions": {"q-gemma4-e4b-Q8_0": 0, "q-qwen3-4b-Instruct-2507-Q8_0": 1, "q-gemma4-e4b-Q3_K_M": 2, "q-qwen3-4b-Instruct-2507-Q4_K_M": 3, "q-qwen3-4b-Instruct-2507-Q5_K_M": 4, "q-qwen3-4b-Instruct-2507-Q3_K_M": 5}, "ordering": 0, "output_chars": {"q-gemma4-e4b-Q8_0": 79, "q-qwen3-4b-Instruct-2507-Q8_0": 66, "q-gemma4-e4b-Q3_K_M": 89, "q-qwen3-4b-Instruct-2507-Q4_K_M": 58, "q-qwen3-4b-Instruct-2507-Q5_K_M": 71, "q-qwen3-4b-Instruct-2507-Q3_K_M": 109}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-confirm-short", "ratings": {"q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "직전 질문에서 이미 확인한 내용을 다시 묻고 있어 대화의 흐름이 부자연스럽습니다.", "relevance": 2, "depth": 3, "language": 4, "overall": 2, "issue": "불필요한 재확인 질문 포함"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "폴링 주기를 묻는 의도는 좋으나, 프로세스에 존칭을 사용하는 등 어색한 표현이 있습니다.", "relevance": 4, "depth": 3, "language": 2, "overall": 2, "issue": "사물에 대한 잘못된 높임말 사용"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "직전 질문을 토씨 하나 바꾸지 않고 거의 그대로 반복하고 있어 면접관의 질문으로 부적절합니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "직전 질문 완벽히 반복"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "폴링 방식의 핵심 한계점인 처리 지연 시간(latency)에 대한 설계 목표를 물어보아 변별력이 높습니다.", "relevance": 5, "depth": 4, "language": 5, "overall": 4, "issue": "없음"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "폴링 주기를 묻는 것은 좋으나, 직전 질문에서 이미 대답한 내용을 다시 묻는 문장이 포함되어 아쉽습니다.", "relevance": 2, "depth": 3, "language": 4, "overall": 2, "issue": "불필요한 재확인 질문 포함"}, "q-gemma4-e4b-Q8_0": {"rationale": "폴링 시 대상 데이터를 식별하는 메커니즘을 묻는 실무적인 질문이나, '특정 시점의 데이터'라는 표현이 다소 모호합니다.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "다소 모호한 용어 선택"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 0, "q-qwen3-4b-Instruct-2507-Q5_K_M": 1, "q-qwen3-4b-Instruct-2507-Q4_K_M": 2, "q-gemma4-e4b-Q3_K_M": 3, "q-qwen3-4b-Instruct-2507-Q8_0": 4, "q-gemma4-e4b-Q8_0": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 109, "q-qwen3-4b-Instruct-2507-Q5_K_M": 71, "q-qwen3-4b-Instruct-2507-Q4_K_M": 58, "q-gemma4-e4b-Q3_K_M": 89, "q-qwen3-4b-Instruct-2507-Q8_0": 66, "q-gemma4-e4b-Q8_0": 79}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-confirm-short", "ratings": {"q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "이미 '네, 맞습니다'로 확인된 사실을 다시 되묻는 군더더기가 앞에 붙고, 핵심 질문은 폴링 주기 단일 항목에 머문다. 어미가 어색해 문장 흐름도 매끄럽지 않다.", "relevance": 3, "depth": 3, "language": 3, "overall": 3, "issue": "확인된 사실 재확인 + 주기라는 얕은 단일 축"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "직전 질문을 거의 그대로 되풀이해 지원자가 이미 '네'로 답한 내용을 다시 묻는다. 새 정보가 전혀 없어 면접 진행이 멈춘다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "직전 질문 그대로 반복해 정보 획득 0"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "앞부분은 확인된 사실 반복이고, 뒤는 '어떻게 읽고 발행하는지'라는 범위가 넓은 설명 요청이라 초점이 흐리다. 두 문장으로 길어 간결성도 떨어진다.", "relevance": 3, "depth": 3, "language": 3, "overall": 3, "issue": "확인 반복 + 초점 없는 포괄적 설명 요청"}, "q-gemma4-e4b-Q8_0": {"rationale": "폴링 시 어떤 행을 집어오는지(상태 컬럼·커서·락)를 겨누어 중복 발행과 순서 문제로 자연스럽게 확장될 수 있는 질문이다. 한 문장으로 간결하고 확인 반복도 없다.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "'특정 시점의 데이터'라는 표현이 다소 모호함"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "확인된 사실을 한 번 더 묻는 문장이 앞에 붙어 중복이며, 실질 질문은 폴링 주기로 비교적 평범하다. 다만 한국어는 자연스럽고 짧다.", "relevance": 3, "depth": 3, "language": 4, "overall": 3, "issue": "이미 확인된 내용 재질문 + 주기라는 표면적 축"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "'얼마나 빠르게 처리하는 것을 목표로'라는 표현이 모호해 지연 목표인지 처리량인지 불분명하고, 구현 약점(중복 발행·락·재시도)을 찌르지 못한다.", "relevance": 3, "depth": 2, "language": 3, "overall": 2, "issue": "질문 의도가 모호해 변별력 있는 답을 유도하기 어려움"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 0, "q-qwen3-4b-Instruct-2507-Q4_K_M": 1, "q-qwen3-4b-Instruct-2507-Q3_K_M": 2, "q-gemma4-e4b-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q8_0": 4, "q-gemma4-e4b-Q3_K_M": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 71, "q-qwen3-4b-Instruct-2507-Q4_K_M": 58, "q-qwen3-4b-Instruct-2507-Q3_K_M": 109, "q-gemma4-e4b-Q8_0": 79, "q-qwen3-4b-Instruct-2507-Q8_0": 66, "q-gemma4-e4b-Q3_K_M": 89}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-confirm-short", "ratings": {"q-gemma4-e4b-Q3_K_M": {"rationale": "폴링 방식 확정 뒤 처리 지연 목표를 물어 중복 없이 한 걸음 나아갔으나, '얼마나 빠르게'라는 표현이 모호해 지연/주기/SLA 중 무엇을 묻는지 불명확하다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "질문 대상이 모호해 답변이 산만해질 수 있음"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "앞 문장이 직전 질문을 그대로 되물어 대화를 반복하고, 이어지는 폴링 주기 질문은 무난하지만 중복 발행 방지 같은 핵심 축은 건드리지 못했다.", "relevance": 3, "depth": 3, "language": 4, "overall": 3, "issue": "이미 확인된 내용 재질문으로 앞부분이 낭비됨"}, "q-gemma4-e4b-Q8_0": {"rationale": "미발행 레코드를 어떻게 선별해 가져오는지(커서·상태 컬럼·락)를 파고들어 변별력이 있고 반복도 없다. 다만 '특정 시점의 데이터'라는 표현이 약간 애매하다.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "표현이 다소 추상적이라 의도 전달이 약함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "확인이 끝난 사실을 다시 되묻고 '어떻게 처리하는지 설명해 달라'는 광범위한 요청이라 초점이 없다. 문장도 길어 면접 질문으로 무디다.", "relevance": 2, "depth": 2, "language": 3, "overall": 2, "issue": "직전 확인 반복 + 초점 없는 포괄 질문"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자가 '네'로 확인한 직전 질문을 거의 그대로 반복해 정보 획득이 전혀 없다. 문장 자체는 짧고 자연스럽지만 질문으로서 무가치하다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "직전 질문 그대로 반복해 대화 진전 없음"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "앞부분은 확인된 내용 반복이고, '말씀이에요'와 '실행되셨나요' 등 어색한 높임·비문이 섞여 있어 다듬어지지 않았다.", "relevance": 2, "depth": 3, "language": 2, "overall": 2, "issue": "비문·어색한 어투와 직전 질문 중복"}}, "positions": {"q-gemma4-e4b-Q3_K_M": 0, "q-qwen3-4b-Instruct-2507-Q8_0": 1, "q-gemma4-e4b-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q3_K_M": 3, "q-qwen3-4b-Instruct-2507-Q4_K_M": 4, "q-qwen3-4b-Instruct-2507-Q5_K_M": 5}, "ordering": 1, "output_chars": {"q-gemma4-e4b-Q3_K_M": 89, "q-qwen3-4b-Instruct-2507-Q8_0": 66, "q-gemma4-e4b-Q8_0": 79, "q-qwen3-4b-Instruct-2507-Q3_K_M": 109, "q-qwen3-4b-Instruct-2507-Q4_K_M": 58, "q-qwen3-4b-Instruct-2507-Q5_K_M": 71}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-confirm-short", "ratings": {"q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자의 단답을 받아 릴레이 구현 방식을 더 설명하게 하는 점은 관련성이 있다. 다만 질문이 넓고 이전 답변의 'outbox 테이블을 읽어 발행'을 반복해 변별력이 다소 약하다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "구체적인 실패 처리나 락/재시도 대신 구현 설명을 넓게 요구한다."}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "별도 프로세스 폴링이라는 답변에 이어 실행 주기를 묻는 점은 자연스럽고 관련 있다. 하지만 주기만 묻는 것은 비교적 얕고, '실행되셨나요' 표현이 어색하다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "폴링 주기만 물어 변별력이 제한적이고 존칭 사용이 부자연스럽다."}, "q-gemma4-e4b-Q8_0": {"rationale": "폴링 시 가져올 데이터 범위나 기준을 묻는 의도는 outbox 구현 검증에 어느 정도 의미가 있다. 다만 '특정 시점의 데이터만'이라는 표현이 모호해 무엇을 답해야 할지 불분명하다.", "relevance": 3, "depth": 3, "language": 3, "overall": 3, "issue": "질문 의도가 워터마크인지 락인지 배치 기준인지 모호하다."}, "q-gemma4-e4b-Q3_K_M": {"rationale": "폴링 기반 릴레이의 처리 지연 목표를 묻는 것은 설계 판단을 확인하는 관련 질문이다. 그러나 outbox의 핵심 쟁점인 중복, 재시도, 락, 원자성보다 변별력이 약하다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "성능 목표에 치우쳐 outbox 안정성 구현 검증이 부족하다."}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "직전 질문과 사실상 동일한 내용을 다시 물어 지원자의 '네, 맞습니다' 답변에 대응하지 못했다. 새로운 검증 포인트가 없어 꼬리질문으로 부적절하다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "이미 답한 질문을 반복한다."}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "답변을 확인한 뒤 폴링 주기를 묻는 흐름은 자연스럽고 관련성이 있다. 다만 앞부분은 직전 질문 반복이고, 주기만으로는 구현 안정성을 깊게 검증하기 어렵다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "불필요한 재확인과 비교적 얕은 주기 질문에 머문다."}}, "positions": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 0, "q-qwen3-4b-Instruct-2507-Q5_K_M": 1, "q-gemma4-e4b-Q8_0": 2, "q-gemma4-e4b-Q3_K_M": 3, "q-qwen3-4b-Instruct-2507-Q4_K_M": 4, "q-qwen3-4b-Instruct-2507-Q8_0": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 109, "q-qwen3-4b-Instruct-2507-Q5_K_M": 71, "q-gemma4-e4b-Q8_0": 79, "q-gemma4-e4b-Q3_K_M": 89, "q-qwen3-4b-Instruct-2507-Q4_K_M": 58, "q-qwen3-4b-Instruct-2507-Q8_0": 66}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-confirm-short", "ratings": {"q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자의 단답 확인을 받아 폴링 주기로 이어가는 점은 적절합니다. 다만 직전 질문을 다시 반복하는 부분이 있어 밀도가 떨어집니다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "이미 답한 확인 질문을 반복한 뒤 비교적 평이한 주기 질문에 그침"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "직전 질문과 사실상 동일한 내용을 다시 묻고 있어 지원자의 '네, 맞습니다' 답변 이후 진행이 없습니다. 변별력 있는 후속 탐색이 전혀 없습니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "이미 답변된 질문을 그대로 반복함"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "폴링 방식에서 중요한 처리 지연 목표를 묻는 질문이라 단답 이후의 후속 질문으로 적절합니다. 다만 표현이 약간 장황하고 '특정 메시지나 트랜잭션'이라는 범위가 다소 모호합니다.", "relevance": 4, "depth": 4, "language": 3, "overall": 4, "issue": "질문 대상이 약간 모호하고 문장이 다소 어색함"}, "q-gemma4-e4b-Q8_0": {"rationale": "폴링 시 데이터 선별 메커니즘을 묻는 것은 구현 세부로 이어질 수 있습니다. 하지만 '특정 시점의 데이터만'이라는 표현이 불명확해 실제로 무엇을 검증하려는지 흐립니다.", "relevance": 3, "depth": 3, "language": 3, "overall": 3, "issue": "질문의 기술적 초점이 모호함"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "별도 프로세스와 폴링 주기를 이어 묻는 점은 맥락상 맞습니다. 그러나 '실행되셨나요'처럼 사물에 높임을 쓰는 표현이 어색하고, 앞부분도 다소 구어적입니다.", "relevance": 4, "depth": 3, "language": 2, "overall": 3, "issue": "높임법 오류로 면접 질문 품질이 떨어짐"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "단답 확인 이후 outbox 테이블 조회와 발행 처리 흐름을 구체적으로 설명하게 해 구현 이해도를 볼 수 있습니다. 다만 앞의 확인 질문은 중복이고 질문이 조금 넓습니다.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "확인 질문이 중복되고 답변 범위가 다소 넓음"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q8_0": 0, "q-qwen3-4b-Instruct-2507-Q4_K_M": 1, "q-gemma4-e4b-Q3_K_M": 2, "q-gemma4-e4b-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q5_K_M": 4, "q-qwen3-4b-Instruct-2507-Q3_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q8_0": 66, "q-qwen3-4b-Instruct-2507-Q4_K_M": 58, "q-gemma4-e4b-Q3_K_M": 89, "q-gemma4-e4b-Q8_0": 79, "q-qwen3-4b-Instruct-2507-Q5_K_M": 71, "q-qwen3-4b-Instruct-2507-Q3_K_M": 109}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-dba-correct-with-context", "ratings": {"q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자가 이미 2.3초에서 900ms로 줄었다고 구체적인 수치를 제시했는데, 기여 비율을 다시 묻는 것은 대화의 흐름상 부자연스럽습니다.", "relevance": 2, "depth": 2, "language": 4, "overall": 2, "issue": "이미 답변한 수치에 대해 불필요한 비율 질문"}, "q-gemma4-e4b-Q8_0": {"rationale": "지원자가 언급한 복합 인덱스를 짚고, 컬럼 순서 결정 기준(카디널리티, 쿼리 조건 등)을 묻는 핵심적이고 변별력 높은 훌륭한 질문입니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": ""}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자가 이미 명확히 설명한 내용을 그대로 반복하며 맞는지 확인만 하고 있어 면접 질문으로서 가치가 없습니다.", "relevance": 2, "depth": 1, "language": 4, "overall": 1, "issue": "지원자 답변을 그대로 반복하는 무의미한 확인형 질문"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "기존 인덱스의 문제점을 묻는 것은 좋으나, 새로 설계한 컬럼과 성능 개선 효과는 지원자가 이미 답변한 내용임에도 다시 묻고 있습니다.", "relevance": 2, "depth": 1, "language": 3, "overall": 1, "issue": "이미 답변한 내용(컬럼 구성, 개선 효과)을 중복 질문"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "실행 계획 전후 비교를 묻는 것은 무난하나, 인덱스 적용 후 seq scan이 줄었는지 묻는 것은 다소 뻔하고 깊이가 부족합니다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "다소 뻔한 수준의 실행 계획 확인 질문"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자는 파티셔닝을 통해 180ms로 개선했다고 명확히 밝혔으나, 이를 인덱스 순서 변경 때문으로 오해하여 질문하는 치명적인 오류가 있습니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "지원자의 답변 내용을 완전히 잘못 이해한 환각(Hallucination)"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 0, "q-gemma4-e4b-Q8_0": 1, "q-qwen3-4b-Instruct-2507-Q4_K_M": 2, "q-gemma4-e4b-Q3_K_M": 3, "q-qwen3-4b-Instruct-2507-Q5_K_M": 4, "q-qwen3-4b-Instruct-2507-Q8_0": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 137, "q-gemma4-e4b-Q8_0": 95, "q-qwen3-4b-Instruct-2507-Q4_K_M": 140, "q-gemma4-e4b-Q3_K_M": 159, "q-qwen3-4b-Instruct-2507-Q5_K_M": 155, "q-qwen3-4b-Instruct-2507-Q8_0": 141}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-dba-correct-with-context", "ratings": {"q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자는 파티셔닝을 통해 180ms로 개선했다고 명확히 밝혔으나, 이를 인덱스 순서 변경으로 잘못 이해한 질문입니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "지원자 답변 내용 오해"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "실행 계획 전후 비교를 묻는 것은 무난하지만, 인덱스 적용 후 seq scan이 줄어든 것은 당연한 결과이므로 변별력이 다소 떨어집니다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "다소 뻔한 질문"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "지원자가 이미 복합 인덱스의 컬럼(user_id, created_at)과 성능 개선 효과(900ms)를 언급했음에도 이를 다시 묻고 있습니다.", "relevance": 2, "depth": 1, "language": 4, "overall": 2, "issue": "이미 답변한 내용 중복 질문"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자가 방금 설명한 내용을 그대로 반복하며 단순 확인만 하고 있어 면접 질문으로서 가치가 없습니다.", "relevance": 2, "depth": 1, "language": 4, "overall": 1, "issue": "단순 확인형 질문으로 변별력 없음"}, "q-gemma4-e4b-Q8_0": {"rationale": "복합 인덱스에서 컬럼 순서(카디널리티 등)를 어떻게 결정했는지 묻는 질문으로, DBA로서의 깊이를 파악하기에 매우 적절합니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "없음"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자가 이미 2.3초에서 900ms로 개선되었다고 구체적인 수치를 제시했는데, 굳이 퍼센트 비율을 다시 묻는 것은 어색합니다.", "relevance": 3, "depth": 2, "language": 4, "overall": 2, "issue": "불필요한 수치(퍼센트) 요구"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q8_0": 0, "q-qwen3-4b-Instruct-2507-Q5_K_M": 1, "q-gemma4-e4b-Q3_K_M": 2, "q-qwen3-4b-Instruct-2507-Q4_K_M": 3, "q-gemma4-e4b-Q8_0": 4, "q-qwen3-4b-Instruct-2507-Q3_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q8_0": 141, "q-qwen3-4b-Instruct-2507-Q5_K_M": 155, "q-gemma4-e4b-Q3_K_M": 159, "q-qwen3-4b-Instruct-2507-Q4_K_M": 140, "q-gemma4-e4b-Q8_0": 95, "q-qwen3-4b-Instruct-2507-Q3_K_M": 137}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-dba-correct-with-context", "ratings": {"q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "인덱스 적용 전후 실행계획 비교를 요구해 답변 대목을 짚긴 하나, 지원자가 이미 EXPLAIN ANALYZE로 seq scan을 확인했다고 말해 사실상 확인성 반복에 가깝다. 문장도 길고 괄호 병기가 어색하다.", "relevance": 3, "depth": 2, "language": 3, "overall": 3, "issue": "이미 언급한 진단 과정을 되묻는 수준이라 변별력이 낮음"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자가 이미 진술한 내용을 그대로 되물어 새 정보를 얻지 못하며, '그 기여를 주었나요?' 등 비문에 가까운 표현이 있다.", "relevance": 2, "depth": 1, "language": 2, "overall": 2, "issue": "답변 반복 확인에 그치고 문장이 어색함"}, "q-gemma4-e4b-Q8_0": {"rationale": "답변에서 가장 근거가 비어 있는 (user_id, created_at) 컬럼 순서 선택 이유를 정확히 겨냥했고, 카디널리티·범위조건 이해를 가려낼 수 있는 변별력 있는 질문이다. 한 문장으로 간결하다.", "relevance": 4, "depth": 4, "language": 5, "overall": 4, "issue": "autovacuum·파티셔닝 기여 구분 축은 건드리지 못함"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자가 말하지 않은 (created_at, user_id) 변경을 사실인 양 전제한 환각이고, 180ms는 파티셔닝 결과라는 답변 내용과도 어긋난다.", "relevance": 1, "depth": 1, "language": 3, "overall": 1, "issue": "답변에 없는 내용을 지어낸 전제로 질문함"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "이미 답변에 나온 복합 인덱스 컬럼 구성과 효과를 다시 묻는 중복 질문이며, 세 가지를 한 번에 묻는 장문이라 면접 질문으로 늘어진다.", "relevance": 3, "depth": 2, "language": 2, "overall": 2, "issue": "기존 답변 재요약 요구 + 과도하게 긴 다중 질문"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자가 900ms/180ms로 이미 기여를 구분해 말했는데 퍼센트 기여도를 재차 묻고, EXPLAIN ANALYZE로 기여 비율을 확인한다는 전제도 기술적으로 부자연스럽다.", "relevance": 2, "depth": 2, "language": 3, "overall": 2, "issue": "이미 구분된 기여도를 되묻고 전제가 기술적으로 부정확함"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 0, "q-qwen3-4b-Instruct-2507-Q4_K_M": 1, "q-gemma4-e4b-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q8_0": 3, "q-gemma4-e4b-Q3_K_M": 4, "q-qwen3-4b-Instruct-2507-Q3_K_M": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 155, "q-qwen3-4b-Instruct-2507-Q4_K_M": 140, "q-gemma4-e4b-Q8_0": 95, "q-qwen3-4b-Instruct-2507-Q8_0": 141, "q-gemma4-e4b-Q3_K_M": 159, "q-qwen3-4b-Instruct-2507-Q3_K_M": 137}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-dba-correct-with-context", "ratings": {"q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자가 이미 900ms/180ms로 인덱스·파티셔닝 기여를 구분해 말했는데 '기여 비율 몇 퍼센트'를 다시 묻는 중복 질문이다. 두 문장으로 길고 정량 비율 자체는 변별력이 낮다.", "relevance": 3, "depth": 2, "language": 3, "overall": 2, "issue": "이미 답한 기여 구분을 퍼센트로 되묻는 중복 질문"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "새 인덱스의 컬럼 구성은 지원자가 이미 (user_id, created_at)으로 말했는데 다시 묻고 있어 반복이며, 한 문장에 세 가지를 몰아넣어 매우 장황하다.", "relevance": 2, "depth": 2, "language": 2, "overall": 2, "issue": "이미 진술된 내용 재요구 + 과도하게 긴 복합 질문"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자가 말하지 않은 '(created_at, user_id)로 변경'을 사실처럼 전제하고, 900→180ms 개선도 파티셔닝 효과인데 인덱스 순서 탓으로 왜곡했다. 사실 오류가 두 군데다.", "relevance": 1, "depth": 1, "language": 3, "overall": 1, "issue": "답변에 없는 인덱스 순서 변경을 날조한 전제"}, "q-gemma4-e4b-Q8_0": {"rationale": "답변의 구체적 기술 선택인 인덱스 컬럼 순서의 설계 근거를 한 문장으로 간결히 파고들어, 카디널리티·범위 조건 이해도를 가릴 수 있다. 반복 없고 표현도 자연스럽다.", "relevance": 4, "depth": 4, "language": 5, "overall": 4, "issue": "autovacuum 기여 정량화라는 가장 약한 축은 비껴감"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자가 이미 말한 seq scan·인덱스 적용 사실을 그대로 확인만 하는 무정보 질문이고, '그 기여를 주었나요' 같은 비문이 있다.", "relevance": 2, "depth": 1, "language": 2, "overall": 1, "issue": "이미 진술된 사실 확인에 그쳐 변별력 없음 + 비문"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "실행 계획 전후 비교라는 진단 근거를 요구해 관련성은 있으나, seq scan이 인덱스 스캔으로 바뀐 건 이미 자명해 통찰이 얕다. 문장이 길고 영문 병기가 어색하다.", "relevance": 3, "depth": 3, "language": 3, "overall": 3, "issue": "예측 가능한 답만 유도하는 뻔한 확인성 질문"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 0, "q-gemma4-e4b-Q3_K_M": 1, "q-qwen3-4b-Instruct-2507-Q8_0": 2, "q-gemma4-e4b-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q4_K_M": 4, "q-qwen3-4b-Instruct-2507-Q5_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 137, "q-gemma4-e4b-Q3_K_M": 159, "q-qwen3-4b-Instruct-2507-Q8_0": 141, "q-gemma4-e4b-Q8_0": 95, "q-qwen3-4b-Instruct-2507-Q4_K_M": 140, "q-qwen3-4b-Instruct-2507-Q5_K_M": 155}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-dba-correct-with-context", "ratings": {"q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자가 제시한 (user_id, created_at) 인덱스와 p95 900ms 수치를 짚어 관련성은 있다. 다만 이미 수치상 기여가 제시된 부분을 퍼센트로 재요구해 변별력은 제한적이다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "이미 답한 개선 수치를 비율로 다시 묻는 데 그침"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "인덱스 적용과 seq scan 해소라는 답변 내용을 짚지만, 사실상 확인형 질문에 가깝다. EXPLAIN 결과나 인덱스 선택 근거를 깊게 파고들지 못한다.", "relevance": 3, "depth": 2, "language": 4, "overall": 2, "issue": "재확인성 질문이라 면접 변별력이 낮음"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자가 말하지 않은 (created_at, user_id) 변경을 전제로 삼아 사실관계가 틀렸다. 900ms에서 180ms 개선도 파티셔닝 효과라고 답했는데 인덱스 순서 변경처럼 오해하고 있다.", "relevance": 1, "depth": 2, "language": 4, "overall": 1, "issue": "없는 내용을 만들어 낸 잘못된 전제"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "seq scan 해소와 EXPLAIN ANALYZE 전후 비교를 요구해 진단 근거를 검증할 수 있다. 이미 언급된 내용을 반복하긴 하지만 실행 계획 세부로 들어가 변별력은 있다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "문장이 다소 길고 일부 반복적임"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "p95 900ms 개선과 기존/신규 인덱스 문제를 짚어 관련성은 높다. 다만 새 인덱스 컬럼은 이미 답변에 있어 일부 반복이며, vacuum·파티셔닝 기여 구분은 파고들지 않는다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "이미 말한 컬럼 구성을 다시 묻는 부분이 큼"}, "q-gemma4-e4b-Q8_0": {"rationale": "복합 인덱스 컬럼 순서의 근거를 묻는 질문이라 실제 쿼리 조건과 카디널리티 이해를 검증할 수 있다. 짧고 자연스러우며 반복도 적다.", "relevance": 5, "depth": 4, "language": 5, "overall": 4, "issue": "파티셔닝·vacuum 기여 구분까지는 다루지 않음"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 0, "q-qwen3-4b-Instruct-2507-Q4_K_M": 1, "q-qwen3-4b-Instruct-2507-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q5_K_M": 3, "q-gemma4-e4b-Q3_K_M": 4, "q-gemma4-e4b-Q8_0": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 137, "q-qwen3-4b-Instruct-2507-Q4_K_M": 140, "q-qwen3-4b-Instruct-2507-Q8_0": 141, "q-qwen3-4b-Instruct-2507-Q5_K_M": 155, "q-gemma4-e4b-Q3_K_M": 159, "q-gemma4-e4b-Q8_0": 95}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-dba-correct-with-context", "ratings": {"q-gemma4-e4b-Q8_0": {"rationale": "지원자가 언급한 (user_id, created_at) 복합 인덱스의 컬럼 순서를 직접 짚고 있어 관련성이 높습니다. 다만 파티셔닝·vacuum 기여 구분까지 더 파고들지는 못해 범위는 다소 좁습니다.", "relevance": 5, "depth": 4, "language": 5, "overall": 4, "issue": "인덱스 설계에만 집중해 vacuum이나 파티셔닝 검증은 놓침"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "p95 900ms와 기존/신규 인덱스를 짚어 구체성은 있으나, 이미 답변한 컬럼 구성과 효과를 다시 묻는 부분이 많습니다. 문장이 길고 한 질문 안에 여러 항목이 섞여 면접 질문으로는 다소 산만합니다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "이미 답한 내용을 반복하고 질문이 과하게 김"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "seq scan 감소 여부와 EXPLAIN ANALYZE 전후 실행 계획 비교를 요구해 진단 근거를 검증하는 좋은 꼬리질문입니다. 다만 인덱스 축에 집중되어 파티셔닝·vacuum의 기여 분리는 추가로 필요합니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "실행 계획 검증은 좋지만 기여도 전체 분리는 부족함"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자는 (user_id, created_at) 인덱스 후 900ms, 파티셔닝 후 180ms라고 했는데, 질문은 (created_at, user_id)로 바꿔 180ms가 된 것처럼 잘못 전제합니다. 사실관계가 틀려 실제 면접에서 혼선을 줍니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "지원자 답변과 반대되는 잘못된 전제를 둠"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자의 수치와 EXPLAIN ANALYZE, 복합 인덱스를 짚기는 하지만 사실상 이미 말한 내용을 확인하는 폐쇄형 질문입니다. 변별력 있는 추가 설명을 끌어내기 어렵고 문장도 다소 어색합니다.", "relevance": 3, "depth": 1, "language": 2, "overall": 2, "issue": "이미 답한 인덱스 기여를 단순 확인하는 데 그침"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "인덱스의 p95 감소 기여를 정량적으로 분리하려는 의도는 기대 신호와 맞습니다. 하지만 EXPLAIN ANALYZE로 ‘기여 비율’을 명확히 확인했다는 전제는 다소 부정확하고 과도하게 수치화를 요구합니다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "성능 개선 기여도를 퍼센트로 단정 요구해 현실성이 떨어짐"}}, "positions": {"q-gemma4-e4b-Q8_0": 0, "q-gemma4-e4b-Q3_K_M": 1, "q-qwen3-4b-Instruct-2507-Q5_K_M": 2, "q-qwen3-4b-Instruct-2507-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q4_K_M": 4, "q-qwen3-4b-Instruct-2507-Q3_K_M": 5}, "ordering": 1, "output_chars": {"q-gemma4-e4b-Q8_0": 95, "q-gemma4-e4b-Q3_K_M": 159, "q-qwen3-4b-Instruct-2507-Q5_K_M": 155, "q-qwen3-4b-Instruct-2507-Q8_0": 141, "q-qwen3-4b-Instruct-2507-Q4_K_M": 140, "q-qwen3-4b-Instruct-2507-Q3_K_M": 137}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-dont-know-explicit", "ratings": {"q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자가 모른다고 명확히 답변했음에도 불구하고, 기대 신호 키워드를 나열하며 동일한 질문을 더 어렵게 다시 묻고 있어 대화의 흐름을 완전히 무시했습니다.", "relevance": 1, "depth": 1, "language": 3, "overall": 1, "issue": "모른다는 지원자에게 동일한 질문 반복"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자가 모른다고 답변했으나, 정답 키워드만 추가하여 똑같은 질문을 다시 강요하고 있어 면접관으로서 부적절한 대응입니다.", "relevance": 1, "depth": 1, "language": 3, "overall": 1, "issue": "모른다는 지원자에게 동일한 질문 반복"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "모른다고 답변한 지원자에게 오히려 더 구체적으로 말해달라고 요구하는 모순된 질문을 생성했습니다.", "relevance": 1, "depth": 1, "language": 3, "overall": 1, "issue": "모른다는 지원자에게 구체적 설명 요구"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "모른다고 한 지원자에게 '모르시는 이유가 무엇인가요?'라고 묻는 것은 매우 어색하고 무례하며, 이후의 질문 내용도 대화 맥락에 맞지 않습니다.", "relevance": 1, "depth": 1, "language": 2, "overall": 1, "issue": "어색하고 공격적인 화법 및 맥락 무시"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "지원자가 모른다는 사실을 수용하고, MVCC와 밀접하게 연관된 데이터베이스 트랜잭션 격리 수준으로 주제를 자연스럽게 전환하여 면접을 이어갑니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "도입부 화법이 다소 직설적임"}, "q-gemma4-e4b-Q8_0": {"rationale": "모른다는 답변에 맞춰 연관 주제인 트랜잭션 격리 수준으로 잘 전환했으나, '이해가 부족하신 것 같은데'나 '아는 것이 있으신가요?'와 같은 표현이 다소 어색하고 부정적인 뉘앙스를 줍니다.", "relevance": 4, "depth": 4, "language": 3, "overall": 3, "issue": "다소 부정적이고 어색한 화법"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 0, "q-qwen3-4b-Instruct-2507-Q4_K_M": 1, "q-qwen3-4b-Instruct-2507-Q5_K_M": 2, "q-qwen3-4b-Instruct-2507-Q8_0": 3, "q-gemma4-e4b-Q3_K_M": 4, "q-gemma4-e4b-Q8_0": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 162, "q-qwen3-4b-Instruct-2507-Q4_K_M": 139, "q-qwen3-4b-Instruct-2507-Q5_K_M": 130, "q-qwen3-4b-Instruct-2507-Q8_0": 190, "q-gemma4-e4b-Q3_K_M": 112, "q-gemma4-e4b-Q8_0": 121}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-dont-know-explicit", "ratings": {"q-gemma4-e4b-Q8_0": {"rationale": "지원자가 모른다고 답변한 의도를 파악하고 연관된 기초 개념인 트랜잭션 격리 수준으로 화제를 전환한 점은 좋습니다. 다만 '이해가 부족하신 것 같은데'라는 표현은 면접관으로서 다소 부적절한 뉘앙스를 줍니다.", "relevance": 4, "depth": 4, "language": 3, "overall": 3, "issue": "면접관으로서 다소 무례하게 들릴 수 있는 쿠션어 사용"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "모른다는 답변에 맞춰 트랜잭션 격리 수준으로 질문을 넘긴 것은 적절합니다. 하지만 '지식이 부족하다고 하셨는데'라는 표현은 지원자의 발언을 다소 과장하여 받는 느낌이 있어 어색합니다.", "relevance": 4, "depth": 4, "language": 3, "overall": 3, "issue": "부자연스럽고 다소 어색한 쿠션어 사용"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자가 모른다고 명확히 밝혔음에도 불구하고 모르는 이유를 묻고, 기대 신호를 그대로 노출하며 다시 질문하여 대화의 문맥을 전혀 파악하지 못했습니다.", "relevance": 1, "depth": 1, "language": 3, "overall": 1, "issue": "모른다는 지원자에게 모르는 이유를 묻고 동일 주제를 다시 질문함"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "지원자가 모른다고 답변하여 다음 질문으로 넘어가길 요청했으나, 오히려 해당 주제에 대해 더 구체적으로 묻고 있어 문맥에 전혀 맞지 않습니다.", "relevance": 1, "depth": 1, "language": 3, "overall": 1, "issue": "모른다는 지원자에게 더 깊은 수준의 꼬리질문을 강행함"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자가 답변을 포기했음에도 불구하고, 평가 기준에 있는 기대 신호 키워드들을 그대로 나열하며 똑같은 질문을 반복하고 있습니다.", "relevance": 1, "depth": 1, "language": 3, "overall": 1, "issue": "답변 포기 의도를 무시하고 기대 신호를 노출하며 재질문함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자가 잘 모르겠다고 답변했으나, 이를 무시하고 기대 신호의 키워드 간 인과관계를 설명하라고 요구하여 면접 진행이 불가능한 수준입니다.", "relevance": 1, "depth": 1, "language": 3, "overall": 1, "issue": "모른다는 답변을 무시하고 동일한 질문을 반복함"}}, "positions": {"q-gemma4-e4b-Q8_0": 0, "q-gemma4-e4b-Q3_K_M": 1, "q-qwen3-4b-Instruct-2507-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q5_K_M": 3, "q-qwen3-4b-Instruct-2507-Q4_K_M": 4, "q-qwen3-4b-Instruct-2507-Q3_K_M": 5}, "ordering": 1, "output_chars": {"q-gemma4-e4b-Q8_0": 121, "q-gemma4-e4b-Q3_K_M": 112, "q-qwen3-4b-Instruct-2507-Q8_0": 190, "q-qwen3-4b-Instruct-2507-Q5_K_M": 130, "q-qwen3-4b-Instruct-2507-Q4_K_M": 139, "q-qwen3-4b-Instruct-2507-Q3_K_M": 162}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-dont-know-explicit", "ratings": {"q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "모른다고 한 지원자에게 '모르시는 이유'를 캐묻는 비면접적 접근이며, 질문이 두 문장으로 장황하고 답변 가능성이 없다.", "relevance": 1, "depth": 2, "language": 2, "overall": 1, "issue": "모름 의도에 '왜 모르냐'고 되묻는 부적절한 대응"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "직전 질문을 거의 그대로 재질문하면서 기대 신호(xmin horizon·bloat)를 통째로 노출해 변별력이 사라졌다.", "relevance": 2, "depth": 2, "language": 3, "overall": 2, "issue": "동일 질문 반복 + 정답 키워드 노출"}, "q-gemma4-e4b-Q8_0": {"rationale": "모름을 인정한 상황에서 인접한 쉬운 주제(격리 수준)로 난이도를 낮춘 전환이 적절하고 간결하다. 다만 '이해가 부족하신 것 같은데'라는 평가성 표현이 톤을 해친다.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "지원자 수준을 단정하는 평가성 어투"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "모른다는 답에 같은 내용을 '좀 더 구체적으로' 요구해 논리가 어긋나고, dead tuple이 '지연된다'는 표현도 부정확하다.", "relevance": 2, "depth": 2, "language": 3, "overall": 2, "issue": "모름 상태에서 동일 주제 심화 요구"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "직전 질문과 기대 신호를 그대로 나열한 재질문으로, 대화 진행도 변별력도 얻지 못한다.", "relevance": 2, "depth": 1, "language": 3, "overall": 2, "issue": "직전 질문의 사실상 복사 + 기대 신호 전면 노출"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "모름을 받아들이고 기초 인접 주제인 격리 수준으로 자연스럽게 내려간 전환이며 한 문장으로 간결하다. 다만 '지식이 부족하다고 하셨는데'는 지원자가 하지 않은 말의 과한 요약이다.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "지원자 발언을 '지식 부족'으로 단정한 표현"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q8_0": 0, "q-qwen3-4b-Instruct-2507-Q3_K_M": 1, "q-gemma4-e4b-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q5_K_M": 3, "q-qwen3-4b-Instruct-2507-Q4_K_M": 4, "q-gemma4-e4b-Q3_K_M": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q8_0": 190, "q-qwen3-4b-Instruct-2507-Q3_K_M": 162, "q-gemma4-e4b-Q8_0": 121, "q-qwen3-4b-Instruct-2507-Q5_K_M": 130, "q-qwen3-4b-Instruct-2507-Q4_K_M": 139, "q-gemma4-e4b-Q3_K_M": 112}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-dont-know-explicit", "ratings": {"q-gemma4-e4b-Q3_K_M": {"rationale": "모름 의도를 정확히 받아 난이도를 낮춘 인접 주제(격리 수준)로 자연스럽게 전환했다. 서두 언급이 다소 길지만 실제 면접 흐름에 부합한다.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "'지식이 부족하다고 하셨는데' 전제가 다소 단정적이고 문장이 길다"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "모른다고 한 질문을 거의 그대로 되물으며 기대 신호(xmin horizon, dead tuple, bloat)까지 노출해 변별력이 사라졌다.", "relevance": 2, "depth": 1, "language": 3, "overall": 1, "issue": "모름 답변에 동일 질문 재요구 + 정답 키워드 유출"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "모름 의도에 대해 오히려 더 구체적인 설명을 요구해 대응이 어긋나고, 정답 힌트를 노출한다. 표현도 '지연되는지'가 모호하다.", "relevance": 2, "depth": 2, "language": 3, "overall": 2, "issue": "모른다는 지원자에게 같은 주제를 더 깊게 재질문"}, "q-gemma4-e4b-Q8_0": {"rationale": "난이도를 낮춘 인접 주제로 전환한 방향은 옳으나, '이해가 부족하신 것 같은데 아는 것이 있으신가요'는 다소 무례하고 예/아니오형에 가깝다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "표현이 다소 무례하고 폐쇄형 질문에 가까움"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "동일 주제를 기대 신호 전부와 함께 되물어 사실상 답을 알려주며, '어떻게 이해하셨는지' 표현이 모른다는 답변과 논리적으로 충돌한다.", "relevance": 2, "depth": 2, "language": 2, "overall": 2, "issue": "정답 키워드 나열 + 모름 답변과 모순되는 질문 구성"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "'모르시는 이유가 무엇인가요'는 지원자를 추궁하는 부적절한 대응이며, 두 문장으로 길고 산만하다.", "relevance": 1, "depth": 2, "language": 2, "overall": 1, "issue": "모르는 이유를 캐묻는 비면접적·압박형 질문"}}, "positions": {"q-gemma4-e4b-Q3_K_M": 0, "q-qwen3-4b-Instruct-2507-Q4_K_M": 1, "q-qwen3-4b-Instruct-2507-Q5_K_M": 2, "q-gemma4-e4b-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q3_K_M": 4, "q-qwen3-4b-Instruct-2507-Q8_0": 5}, "ordering": 1, "output_chars": {"q-gemma4-e4b-Q3_K_M": 112, "q-qwen3-4b-Instruct-2507-Q4_K_M": 139, "q-qwen3-4b-Instruct-2507-Q5_K_M": 130, "q-gemma4-e4b-Q8_0": 121, "q-qwen3-4b-Instruct-2507-Q3_K_M": 162, "q-qwen3-4b-Instruct-2507-Q8_0": 190}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-dont-know-explicit", "ratings": {"q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "지원자가 모른다고 했는데 거의 같은 내용을 더 구체적으로 다시 묻고 있어 의도 대응이 부적절합니다. 기대 신호 일부는 포함하지만 다음 질문으로서 변별력이 낮습니다.", "relevance": 2, "depth": 2, "language": 3, "overall": 2, "issue": "모른다는 답변 뒤에 같은 질문을 재요청함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "xmin horizon, dead tuple, bloat의 인과관계를 짚은 점은 기술적으로 맞지만, 지원자가 모른다고 한 질문을 그대로 확장해 다시 묻습니다. 문장도 길고 실제 면접 흐름상 압박적으로 느껴질 수 있습니다.", "relevance": 2, "depth": 2, "language": 3, "overall": 2, "issue": "DONT_KNOW 상황에 원질문을 반복함"}, "q-gemma4-e4b-Q8_0": {"rationale": "모른다는 답변을 받아 더 기본적인 격리 수준으로 전환한 점은 어느 정도 적절합니다. 다만 '이해가 부족하신 것 같은데'는 불필요하게 평가적이고, 질문도 다소 넓습니다.", "relevance": 3, "depth": 2, "language": 3, "overall": 3, "issue": "표현이 다소 무례하고 질문 초점이 넓음"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "지원자가 모른다고 한 뒤 관련 기초 개념인 트랜잭션 격리 수준으로 넘어가 실전 흐름은 비교적 자연스럽습니다. 다만 MVCC/vacuum 기대 신호를 직접 보완하지는 못하고 표현이 약간 단정적입니다.", "relevance": 3, "depth": 3, "language": 4, "overall": 3, "issue": "관련 기초로 전환했지만 원 질문의 약점을 깊게 파고들지는 못함"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "모른다는 이유를 묻는 방식은 면접 질문으로 부적절하고 압박적입니다. 원래 모른다고 한 내용을 다시 길게 요구해 서비스에 내보내기 어렵습니다.", "relevance": 1, "depth": 1, "language": 2, "overall": 1, "issue": "모르는 이유를 추궁하며 같은 내용을 장황하게 반복함"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "기대 신호를 모두 포함했지만, 지원자가 이미 모른다고 답한 원질문을 거의 그대로 다시 묻고 있습니다. DONT_KNOW 의도에 맞춘 전환이나 쉬운 재설명이 없습니다.", "relevance": 2, "depth": 2, "language": 3, "overall": 2, "issue": "원질문 반복으로 면접 흐름 대응 실패"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 0, "q-qwen3-4b-Instruct-2507-Q3_K_M": 1, "q-gemma4-e4b-Q8_0": 2, "q-gemma4-e4b-Q3_K_M": 3, "q-qwen3-4b-Instruct-2507-Q8_0": 4, "q-qwen3-4b-Instruct-2507-Q4_K_M": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 130, "q-qwen3-4b-Instruct-2507-Q3_K_M": 162, "q-gemma4-e4b-Q8_0": 121, "q-gemma4-e4b-Q3_K_M": 112, "q-qwen3-4b-Instruct-2507-Q8_0": 190, "q-qwen3-4b-Instruct-2507-Q4_K_M": 139}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-dont-know-explicit", "ratings": {"q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자가 모른다고 했는데 사실상 같은 질문을 기대 키워드만 붙여 다시 묻고 있습니다. 변별력 있는 우회 질문이나 난이도 조절이 없습니다.", "relevance": 2, "depth": 2, "language": 3, "overall": 2, "issue": "모른다는 답변에 같은 질문을 반복함"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "모른다는 이유를 캐묻는 방식이 부적절하고 압박적으로 들립니다. 질문도 길고 산만하며 같은 주제를 더 어렵게 되묻습니다.", "relevance": 1, "depth": 2, "language": 2, "overall": 1, "issue": "부적절하게 추궁하며 질문이 과도하게 장황함"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "모른다는 답변을 받아들여 인접한 기본 개념인 트랜잭션 격리 수준으로 전환한 점은 적절합니다. 다만 표현이 다소 평가적이고 MVCC/vacuum과의 연결성은 약합니다.", "relevance": 4, "depth": 3, "language": 4, "overall": 4, "issue": "연결성은 약하지만 적절한 난이도 하향 질문"}, "q-gemma4-e4b-Q8_0": {"rationale": "기본 개념으로 전환한 방향은 괜찮지만 '이해가 부족하신 것 같은데'가 면접 서비스 문장으로는 거칠게 들립니다. 영어 병기와 표현도 다소 불필요합니다.", "relevance": 3, "depth": 3, "language": 3, "overall": 3, "issue": "평가적인 표현이 부자연스럽고 다소 무례함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자가 모른다고 했는데 xmin horizon, dead tuple, bloat의 인과관계를 다시 설명하라고 요구합니다. 원 질문을 거의 재포장한 수준이라 대응이 부적절합니다.", "relevance": 2, "depth": 2, "language": 3, "overall": 2, "issue": "모른다는 답변에 기대 신호를 나열해 재질문함"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "원 질문의 일부를 다시 묻는 데 그치며, 'xmin horizon이 오래된 트랜잭션을 인식'한다는 표현도 기술적으로 어색합니다. 난이도 조절이나 주제 전환이 부족합니다.", "relevance": 2, "depth": 2, "language": 3, "overall": 2, "issue": "기술적으로 어색한 표현으로 같은 내용을 반복함"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 0, "q-qwen3-4b-Instruct-2507-Q8_0": 1, "q-gemma4-e4b-Q3_K_M": 2, "q-gemma4-e4b-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q3_K_M": 4, "q-qwen3-4b-Instruct-2507-Q5_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 139, "q-qwen3-4b-Instruct-2507-Q8_0": 190, "q-gemma4-e4b-Q3_K_M": 112, "q-gemma4-e4b-Q8_0": 121, "q-qwen3-4b-Instruct-2507-Q3_K_M": 162, "q-qwen3-4b-Instruct-2507-Q5_K_M": 130}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-dont-know-stt", "ratings": {"q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자가 모른다고 답변했음에도 불구하고, 지원자가 하지 않은 말을 가정하며 질문의 논리가 매우 어색합니다.", "relevance": 1, "depth": 1, "language": 2, "overall": 1, "issue": "지원자의 답변을 무시한 환각 및 비논리적 질문"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "지원자가 명확히 모른다고 대답했으나, 기대 신호를 지원자가 이미 말했다고 착각하여 꼬리질문을 하고 있습니다.", "relevance": 1, "depth": 1, "language": 3, "overall": 1, "issue": "지원자가 정답을 말했다고 가정하는 환각 오류"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "모른다는 의도를 파악했음에도 똑같은 질문을 반복하고 있으며, 괄호 안에 정답을 그대로 노출하는 치명적인 오류가 있습니다.", "relevance": 1, "depth": 1, "language": 2, "overall": 1, "issue": "동일 질문 반복 및 괄호를 통한 정답 노출"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "후보 B와 마찬가지로 지원자가 모른다고 답변한 사실을 무시하고, 정답을 이미 말했다고 가정하는 환각을 보입니다.", "relevance": 1, "depth": 1, "language": 3, "overall": 1, "issue": "지원자가 정답을 말했다고 가정하는 환각 오류"}, "q-gemma4-e4b-Q8_0": {"rationale": "지원자가 모른다고 답변한 상황에 완벽하게 대응하여, 난이도를 낮춰 '배칭'의 기본 개념을 묻는 훌륭한 우회 질문입니다.", "relevance": 5, "depth": 4, "language": 5, "overall": 5, "issue": "없음"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "지원자가 모른다고 대답했음에도 불구하고, 기대 신호에 대한 내용을 지원자가 이미 확인해 본 것처럼 가정하고 질문합니다.", "relevance": 1, "depth": 1, "language": 3, "overall": 1, "issue": "지원자의 답변을 무시한 환각 오류"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 0, "q-qwen3-4b-Instruct-2507-Q5_K_M": 1, "q-qwen3-4b-Instruct-2507-Q3_K_M": 2, "q-qwen3-4b-Instruct-2507-Q8_0": 3, "q-gemma4-e4b-Q8_0": 4, "q-gemma4-e4b-Q3_K_M": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 159, "q-qwen3-4b-Instruct-2507-Q5_K_M": 159, "q-qwen3-4b-Instruct-2507-Q3_K_M": 145, "q-qwen3-4b-Instruct-2507-Q8_0": 151, "q-gemma4-e4b-Q8_0": 115, "q-gemma4-e4b-Q3_K_M": 118}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-dont-know-stt", "ratings": {"q-gemma4-e4b-Q3_K_M": {"rationale": "지원자가 모른다고 답했음에도 불구하고, 비동기 환경에서 확인해 본 경험을 묻고 있어 대화의 문맥에 전혀 맞지 않습니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "지원자의 '모름' 답변을 무시하고 경험을 요구함"}, "q-gemma4-e4b-Q8_0": {"rationale": "지원자가 모른다고 한 점을 자연스럽게 수용하고, 난이도를 낮춰 '배칭'의 기본 개념을 묻는 훌륭한 대처입니다.", "relevance": 5, "depth": 4, "language": 5, "overall": 5, "issue": "없음"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자가 모른다고 대답했으나, 정답을 말했다고 가정하고 꼬리질문을 던지는 심각한 환각(Hallucination) 오류가 있습니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "지원자가 정답을 말했다고 착각함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "의도 분류가 틀렸으며, 모른다고 한 지원자에게 똑같은 질문을 다시 하면서 괄호로 정답을 알려주는 어색한 형태입니다.", "relevance": 1, "depth": 1, "language": 3, "overall": 1, "issue": "모른다는 지원자에게 동일 질문 반복 및 괄호 정답 노출"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "후보 C와 마찬가지로 지원자가 정답을 말했다고 착각하여 구체적인 예시를 묻고 있어 문맥에 어긋납니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "지원자가 정답을 말했다고 착각함"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "문장 구조가 논리적으로 전혀 맞지 않으며, 모른다는 답변에 대해 엉뚱한 이유를 묻는 등 횡설수설하고 있습니다.", "relevance": 1, "depth": 1, "language": 1, "overall": 1, "issue": "비논리적이고 어색한 문장 구조"}}, "positions": {"q-gemma4-e4b-Q3_K_M": 0, "q-gemma4-e4b-Q8_0": 1, "q-qwen3-4b-Instruct-2507-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q3_K_M": 3, "q-qwen3-4b-Instruct-2507-Q5_K_M": 4, "q-qwen3-4b-Instruct-2507-Q4_K_M": 5}, "ordering": 1, "output_chars": {"q-gemma4-e4b-Q3_K_M": 118, "q-gemma4-e4b-Q8_0": 115, "q-qwen3-4b-Instruct-2507-Q8_0": 151, "q-qwen3-4b-Instruct-2507-Q3_K_M": 145, "q-qwen3-4b-Instruct-2507-Q5_K_M": 159, "q-qwen3-4b-Instruct-2507-Q4_K_M": 159}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-dont-know-stt", "ratings": {"q-gemma4-e4b-Q3_K_M": {"rationale": "모른다고 답한 지원자에게 '어떤 비동기 환경에서 확인해 보셨는지' 경험을 전제해 물어 대응이 어긋납니다. 기대 신호를 그대로 노출해 변별력도 없습니다.", "relevance": 2, "depth": 2, "language": 3, "overall": 2, "issue": "존재하지 않는 경험을 전제한 질문으로 DONT_KNOW 대응 실패"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "'말씀하신 게 아니라면 그 이유를' 같은 구문이 논리적으로 성립하지 않아 지원자가 무엇을 답해야 할지 알 수 없습니다.", "relevance": 2, "depth": 1, "language": 2, "overall": 1, "issue": "문장 자체가 비논리적이고 답변 불가능"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자가 전혀 언급하지 않은 내용을 '말씀하셨는데'라고 잘못 전제했고, 정답을 먼저 알려준 뒤 예시를 요구해 평가 기능이 사라졌습니다.", "relevance": 1, "depth": 2, "language": 4, "overall": 2, "issue": "답변 내용을 왜곡한 허위 전제"}, "q-gemma4-e4b-Q8_0": {"rationale": "'공부를 안 했다'는 실제 대목을 짚고 난이도를 낮춰 기본 개념부터 확인하는, 모름 상황에 가장 알맞은 대응입니다. 한국어도 자연스럽고 간결합니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "비동기 콜백 축으로 유도하는 힌트가 없어 변별 폭이 다소 좁음"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "C와 동일한 허위 전제에 '들였는지' 등 어색한 표현까지 섞여 문장 완성도가 낮습니다.", "relevance": 1, "depth": 2, "language": 2, "overall": 1, "issue": "말하지 않은 내용을 전제 + 비문"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "의도를 NORMAL로 잘못 분류했고, 괄호로 정답을 그대로 제시해 사실상 답을 알려줬습니다. 다만 다시 기회를 주는 방향성은 일부 타당합니다.", "relevance": 3, "depth": 2, "language": 3, "overall": 2, "issue": "의도 오분류와 정답 노출로 변별력 상실"}}, "positions": {"q-gemma4-e4b-Q3_K_M": 0, "q-qwen3-4b-Instruct-2507-Q4_K_M": 1, "q-qwen3-4b-Instruct-2507-Q8_0": 2, "q-gemma4-e4b-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q5_K_M": 4, "q-qwen3-4b-Instruct-2507-Q3_K_M": 5}, "ordering": 0, "output_chars": {"q-gemma4-e4b-Q3_K_M": 118, "q-qwen3-4b-Instruct-2507-Q4_K_M": 159, "q-qwen3-4b-Instruct-2507-Q8_0": 151, "q-gemma4-e4b-Q8_0": 115, "q-qwen3-4b-Instruct-2507-Q5_K_M": 159, "q-qwen3-4b-Instruct-2507-Q3_K_M": 145}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-dont-know-stt", "ratings": {"q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "모름 답변인데 NORMAL로 오분류했고, 정답 힌트를 괄호로 노출한 채 같은 질문을 되묻는 구성이라 변별력이 떨어진다. 문장도 길고 이중 질문이다.", "relevance": 3, "depth": 2, "language": 3, "overall": 2, "issue": "의도 오분류 + 정답을 힌트로 노출해 되묻기"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "의도 분류는 맞았으나 지원자가 말하지 않은 내용을 '말씀하셨는데'라고 전제하는 환각이 있고, '들였는지' 등 비문이 섞였다.", "relevance": 1, "depth": 1, "language": 2, "overall": 1, "issue": "지원자가 한 적 없는 발언을 전제하는 환각"}, "q-gemma4-e4b-Q8_0": {"rationale": "모름 의도를 정확히 잡고 난이도를 낮춰 배칭의 기본 개념을 확인하는 적절한 대응이며, 한 문장으로 간결하다. 다만 파고드는 깊이는 제한적이다.", "relevance": 5, "depth": 4, "language": 5, "overall": 4, "issue": "기본 개념 확인에 머물러 변별 폭이 다소 좁음"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "B와 동일하게 지원자가 답한 적 없는 내용을 언급했다고 전제해 대화 맥락이 깨진다. 모른다고 한 사람에게 예시를 요구하는 것도 부적절하다.", "relevance": 1, "depth": 1, "language": 3, "overall": 1, "issue": "답변 내용 환각으로 모름 대응 실패"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "'모르겠다고 말씀하셨는데'와 '말씀하신 게 아니라면'이 뒤섞여 무엇을 묻는지 불명확하고, 이유를 캐묻는 방향도 무의미하다.", "relevance": 1, "depth": 1, "language": 1, "overall": 1, "issue": "문장 논리가 붕괴되어 질문 의도 불명"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "한국어는 비교적 자연스럽지만, 지원자가 확인해 본 경험을 전제하는 환각이라 모름 답변에 맞지 않는 후속 질문이다.", "relevance": 2, "depth": 2, "language": 4, "overall": 2, "issue": "모른다는 답변에 경험 전제 질문을 던짐"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 0, "q-qwen3-4b-Instruct-2507-Q5_K_M": 1, "q-gemma4-e4b-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q4_K_M": 4, "q-gemma4-e4b-Q3_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 145, "q-qwen3-4b-Instruct-2507-Q5_K_M": 159, "q-gemma4-e4b-Q8_0": 115, "q-qwen3-4b-Instruct-2507-Q8_0": 151, "q-qwen3-4b-Instruct-2507-Q4_K_M": 159, "q-gemma4-e4b-Q3_K_M": 118}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-dont-know-stt", "ratings": {"q-gemma4-e4b-Q8_0": {"rationale": "지원자가 모른다고 한 점을 정확히 반영해 더 기본 개념으로 낮춰 묻고 있습니다. 다만 React 18의 핵심 차이인 비동기 콜백 배칭까지는 직접 변별하지 못합니다.", "relevance": 5, "depth": 3, "language": 4, "overall": 4, "issue": "핵심 기대 신호보다는 일반 개념 확인에 머뭄"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "모른다고 한 답변을 언급하긴 하지만 의도 분류가 틀렸고, 예시로 사실상 정답을 알려 줍니다. 오탈자도 있어 실제 면접 질문으로는 어색합니다.", "relevance": 2, "depth": 2, "language": 2, "overall": 2, "issue": "정답을 힌트로 제공해 변별력이 낮음"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자가 해당 내용을 말하지 않았는데 '말씀하셨는데'라고 전제해 사실과 다르게 이어갑니다. 질문 자체는 기술적으로 관련 있으나 답변 맥락에는 맞지 않습니다.", "relevance": 1, "depth": 2, "language": 4, "overall": 1, "issue": "지원자 답변을 정반대로 오인함"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "지원자가 예시를 든 적이 없는데 '어떤 상황을 들였는지'라고 물어 맥락 오류가 큽니다. 기술 주제는 맞지만 실제 대화 흐름에는 사용할 수 없습니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "존재하지 않는 이전 답변을 전제로 함"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "비동기 콜백 배칭이라는 기대 신호를 다루지만, 모른다고 한 지원자에게 경험 기반 구체 예시를 요구해 난도가 부적절합니다. 정답 방향을 많이 노출하는 점도 아쉽습니다.", "relevance": 2, "depth": 3, "language": 4, "overall": 2, "issue": "모른다는 답변에 맞춘 완화 질문이 아님"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "모른다고 한 점은 언급하지만 문장이 매우 우회적이고, '말씀하신 게 아니라면 그 이유'라는 질문은 면접 질문으로 부자연스럽습니다. 기대 신호도 그대로 노출합니다.", "relevance": 2, "depth": 1, "language": 2, "overall": 1, "issue": "질문 의도가 불명확하고 정답을 노출함"}}, "positions": {"q-gemma4-e4b-Q8_0": 0, "q-qwen3-4b-Instruct-2507-Q3_K_M": 1, "q-qwen3-4b-Instruct-2507-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q5_K_M": 3, "q-gemma4-e4b-Q3_K_M": 4, "q-qwen3-4b-Instruct-2507-Q4_K_M": 5}, "ordering": 0, "output_chars": {"q-gemma4-e4b-Q8_0": 115, "q-qwen3-4b-Instruct-2507-Q3_K_M": 145, "q-qwen3-4b-Instruct-2507-Q8_0": 151, "q-qwen3-4b-Instruct-2507-Q5_K_M": 159, "q-gemma4-e4b-Q3_K_M": 118, "q-qwen3-4b-Instruct-2507-Q4_K_M": 159}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-dont-know-stt", "ratings": {"q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자가 모른다고 했다는 점은 반영했지만, 기대 답안을 거의 제시한 뒤 ‘그 이유’를 묻는 형태라 부자연스럽고 변별력이 낮습니다. 질문도 길고 조건절이 어색합니다.", "relevance": 2, "depth": 2, "language": 2, "overall": 2, "issue": "모른다는 답변에 정답을 주입하고 이유를 묻는 어색한 질문"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "DONT_KNOW 분류는 맞지만, 지원자가 확인해 본 적이 있다는 전제로 묻고 있어 실제 답변과 맞지 않습니다. 기대 신호를 겨냥하긴 하나 모르는 지원자에게는 부적절합니다.", "relevance": 2, "depth": 2, "language": 4, "overall": 2, "issue": "모른다고 한 지원자에게 경험과 예시를 전제함"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "지원자가 말하지 않은 내용을 ‘말씀하셨는데’라고 전제해 사실과 맞지 않습니다. 문장은 자연스럽지만 답변 의도 대응이 크게 어긋납니다.", "relevance": 1, "depth": 2, "language": 4, "overall": 2, "issue": "지원자가 하지 않은 말을 했다고 전제함"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "C와 마찬가지로 지원자가 언급하지 않은 핵심 내용을 말했다고 전제합니다. 기대 신호를 다루지만 모름 답변에 대한 후속 질문으로는 부적절합니다.", "relevance": 1, "depth": 2, "language": 4, "overall": 2, "issue": "모른다는 답변을 무시하고 정답 언급을 전제함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "‘모른다’는 답변은 반영했지만 분류가 NORMAL로 틀렸고, 괄호 예시로 사실상 정답을 알려 줍니다. 질문 자체는 직전 질문과 관련 있으나 변별력이 약합니다.", "relevance": 3, "depth": 2, "language": 3, "overall": 3, "issue": "분류 오류와 정답을 직접 힌트로 제시한 점"}, "q-gemma4-e4b-Q8_0": {"rationale": "DONT_KNOW 의도를 정확히 반영하고, 더 기본 개념인 배칭 정의로 낮춰 묻는 점이 적절합니다. 기대 신호 자체를 직접 파고들지는 않지만 실제 면접 후속 질문으로 자연스럽습니다.", "relevance": 5, "depth": 4, "language": 5, "overall": 5, "issue": "React 18 차이점보다는 기본 개념 확인에 머무름"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 0, "q-gemma4-e4b-Q3_K_M": 1, "q-qwen3-4b-Instruct-2507-Q5_K_M": 2, "q-qwen3-4b-Instruct-2507-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q3_K_M": 4, "q-gemma4-e4b-Q8_0": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 159, "q-gemma4-e4b-Q3_K_M": 118, "q-qwen3-4b-Instruct-2507-Q5_K_M": 159, "q-qwen3-4b-Instruct-2507-Q8_0": 151, "q-qwen3-4b-Instruct-2507-Q3_K_M": 145, "q-gemma4-e4b-Q8_0": 115}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-english-mixed", "ratings": {"q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자가 언급한 화면별 staleTime 설정에 대해 가장 길게 설정한 화면과 그 이유를 물어 실무적인 고민을 깊이 있게 파고들었습니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "없음"}, "q-gemma4-e4b-Q8_0": {"rationale": "40%라는 구체적인 수치에 대해 측정 기준과 시나리오를 물어보아 지원자의 검증 능력을 효과적으로 확인합니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "없음"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자의 답변을 바탕으로 구체적인 예시를 묻고 있으나, 질문이 다소 평이하여 변별력이 약간 떨어집니다.", "relevance": 4, "depth": 3, "language": 5, "overall": 4, "issue": "다소 평이한 질문"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "질문이 길고 여러 가지를 한 번에 묻고 있으며, '말씀해 주세요?'와 같이 어색한 종결 어미를 사용했습니다.", "relevance": 4, "depth": 3, "language": 2, "overall": 2, "issue": "어색한 종결 어미와 다소 긴 문장"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "지원자의 발언을 인용하여 질문했으나, 문장이 다소 길고 평이한 예시 요구에 그쳐 깊이가 아쉽습니다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "다소 길고 평이한 질문"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "후보 C와 동일한 출력으로, 무난하지만 변별력이 다소 부족한 평이한 질문입니다.", "relevance": 4, "depth": 3, "language": 5, "overall": 4, "issue": "다소 평이한 질문"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 0, "q-gemma4-e4b-Q8_0": 1, "q-qwen3-4b-Instruct-2507-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q5_K_M": 3, "q-gemma4-e4b-Q3_K_M": 4, "q-qwen3-4b-Instruct-2507-Q4_K_M": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 99, "q-gemma4-e4b-Q8_0": 90, "q-qwen3-4b-Instruct-2507-Q8_0": 92, "q-qwen3-4b-Instruct-2507-Q5_K_M": 107, "q-gemma4-e4b-Q3_K_M": 108, "q-qwen3-4b-Instruct-2507-Q4_K_M": 92}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-english-mixed", "ratings": {"q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자의 staleTime 설정에 대한 구체적인 예시와 수치를 물어보아 무난하게 경험을 검증할 수 있는 질문입니다.", "relevance": 5, "depth": 4, "language": 5, "overall": 4, "issue": "없음"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "A와 유사한 의도이나 '말씀하신 ~' 등의 표현이 들어가 문장이 다소 길고 장황합니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "다소 길고 장황한 문장"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "질문의 의도는 좋으나 평서문/명령문 형태에 물음표를 붙인 어색한 맺음말이 사용되었습니다.", "relevance": 4, "depth": 3, "language": 2, "overall": 2, "issue": "어색한 문장 맺음말 ('말씀해 주세요?')"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "A와 완전히 동일한 질문으로, 무난하고 간결하게 핵심을 짚었습니다.", "relevance": 5, "depth": 4, "language": 5, "overall": 4, "issue": "없음"}, "q-gemma4-e4b-Q8_0": {"rationale": "지원자가 언급한 '40% 감소'라는 구체적인 수치의 측정 기준을 파고들어 실제 경험 여부를 날카롭게 검증하는 훌륭한 질문입니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "없음"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "staleTime을 다르게 설정한 기준 중 '가장 긴 화면과 그 이유'를 특정하여 물어봄으로써 지원자의 캐싱 전략 이해도를 깊이 있게 검증합니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "없음"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 0, "q-gemma4-e4b-Q3_K_M": 1, "q-qwen3-4b-Instruct-2507-Q5_K_M": 2, "q-qwen3-4b-Instruct-2507-Q8_0": 3, "q-gemma4-e4b-Q8_0": 4, "q-qwen3-4b-Instruct-2507-Q3_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 92, "q-gemma4-e4b-Q3_K_M": 108, "q-qwen3-4b-Instruct-2507-Q5_K_M": 107, "q-qwen3-4b-Instruct-2507-Q8_0": 92, "q-gemma4-e4b-Q8_0": 90, "q-qwen3-4b-Instruct-2507-Q3_K_M": 99}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-english-mixed", "ratings": {"q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "답변의 '화면별 staleTime' 대목을 정확히 짚었으나 설정 예시만 요구해 판단 기준·트레이드오프까지는 파고들지 못했다. '예시나, 어떤 화면에서 얼마나'는 두 요구가 겹쳐 다소 늘어진다.", "relevance": 4, "depth": 3, "language": 4, "overall": 4, "issue": "사실 나열만 유도하고 설정 근거를 묻지 않아 변별력이 제한적"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "예시에 더해 '어떤 문제를 해결했는지'까지 물어 A보다 깊이가 있으나, '~말씀해 주세요?'라는 어색한 종결과 요구 항목 3개로 문장이 길어졌다.", "relevance": 4, "depth": 4, "language": 3, "overall": 4, "issue": "청유형에 물음표를 붙인 비문과 과다한 질문 항목"}, "q-gemma4-e4b-Q8_0": {"rationale": "'40% 감소'라는 수치의 측정 근거를 파고들어 지원자 주장 검증이라는 면접 변별력이 높고 문장도 간결하다. 다만 캐싱·서버상태 구분이라는 기대 신호보다는 측정 방법 쪽에 치우친다.", "relevance": 5, "depth": 4, "language": 5, "overall": 4, "issue": "기술 이해 자체보다 수치 검증에 집중해 기대 신호 커버는 부분적"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "A와 동일한 취지지만 답변 문구를 따옴표로 그대로 인용해 장황하고 '어떤 상황에서 어떤 방식으로'가 중복된다. 깊이도 예시 요구 수준에 머문다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "불필요한 인용과 중복 표현으로 문장이 길고 둔탁함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "가장 긴 staleTime 화면과 그 이유를 물어 데이터 신선도 판단 기준을 끌어내는 초점이 분명하고 문장도 간결하다. 다만 mutation 후 invalidate 전략 등 다른 약한 축은 건드리지 않는다.", "relevance": 4, "depth": 4, "language": 5, "overall": 4, "issue": "질문 범위가 staleTime 한 축에 한정됨"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "A와 동일한 문장으로, 답변 대목은 잘 짚었으나 설정 값 확인 수준에 그쳐 깊이가 평이하다.", "relevance": 4, "depth": 3, "language": 4, "overall": 4, "issue": "설정 근거·트레이드오프를 묻지 않아 무난하지만 평범함"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 0, "q-qwen3-4b-Instruct-2507-Q5_K_M": 1, "q-gemma4-e4b-Q8_0": 2, "q-gemma4-e4b-Q3_K_M": 3, "q-qwen3-4b-Instruct-2507-Q3_K_M": 4, "q-qwen3-4b-Instruct-2507-Q8_0": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 92, "q-qwen3-4b-Instruct-2507-Q5_K_M": 107, "q-gemma4-e4b-Q8_0": 90, "q-gemma4-e4b-Q3_K_M": 108, "q-qwen3-4b-Instruct-2507-Q3_K_M": 99, "q-qwen3-4b-Instruct-2507-Q8_0": 92}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-english-mixed", "ratings": {"q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "staleTime 화면별 설정이라는 답변 대목을 짚었으나 '예시나 얼마나' 수준의 일반적 구체화 요구로, 갱신 정책 판단 근거까지는 파고들지 못했다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "구체 예시 요구에 머물러 변별력이 약함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "가장 길게 잡은 화면과 그 이유를 물어 데이터 신선도 기준·트레이드오프 판단을 검증할 수 있다. 문장도 간결하고 자연스럽다.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "서버/클라이언트 상태 구분 축은 여전히 미확인"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "답변을 인용해 관련성은 있으나 '어떤 상황에서 어떤 방식으로 예시를 들어' 식으로 장황하고, 실질 질문은 단순 구체화 요청이다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "문장이 길고 중복 표현이 많아 초점이 흐림"}, "q-gemma4-e4b-Q8_0": {"rationale": "40% 감소라는 수치의 측정 근거를 짚어 과장 여부를 검증하는 좋은 접근이며 다른 후보와 각도가 다르다.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "캐싱 정책 설계 역량보다 지표 검증에 치우침"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "설정 예시와 해결한 문제를 함께 물어 정보량은 있으나 질문이 두 겹으로 길고, 청유형 끝에 물음표가 붙어 어색하다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "다중 질문·어색한 종결로 문장 완성도가 낮음"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "A와 동일한 문구로, 관련성은 있으나 일반적 구체화 요구에 그쳐 판단 근거를 끌어내지 못한다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "차별점 없는 단순 구체화 질문"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q8_0": 0, "q-qwen3-4b-Instruct-2507-Q3_K_M": 1, "q-gemma4-e4b-Q3_K_M": 2, "q-gemma4-e4b-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q5_K_M": 4, "q-qwen3-4b-Instruct-2507-Q4_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q8_0": 92, "q-qwen3-4b-Instruct-2507-Q3_K_M": 99, "q-gemma4-e4b-Q3_K_M": 108, "q-gemma4-e4b-Q8_0": 90, "q-qwen3-4b-Instruct-2507-Q5_K_M": 107, "q-qwen3-4b-Instruct-2507-Q4_K_M": 92}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-english-mixed", "ratings": {"q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자의 '화면별 staleTime' 언급을 직접 짚어 구체 사례를 요구해 관련성이 높습니다. 다만 설정 이유나 실제 버그 해결까지 파고들지는 않아 변별력은 중간 이상입니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "staleTime 값의 근거와 효과까지는 묻지 않음"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "A와 동일하게 지원자의 구체 주장인 화면별 staleTime 설정을 잘 짚었습니다. 사례 확인 질문으로 적절하지만 추가적인 설계 판단이나 트레이드오프 검증은 부족합니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "구체 예시 확인에 머물러 심화 검증이 약함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "화면별 staleTime 중 가장 길게 둔 사례와 이유를 물어 캐싱 전략의 판단 근거를 확인할 수 있습니다. 특정 한쪽 사례에만 좁혀져 전체 정책이나 문제 해결 효과 검증은 제한적입니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "가장 긴 staleTime 사례로 질문 범위가 다소 좁음"}, "q-gemma4-e4b-Q8_0": {"rationale": "지원자가 제시한 '네트워크 요청 40% 감소' 수치를 검증해 실제 측정 근거를 확인하는 질문입니다. 다만 TanStack Query 선택의 핵심인 stale 관리나 invalidation 설계보다는 성과 지표 검증에 치우칩니다.", "relevance": 5, "depth": 4, "language": 5, "overall": 4, "issue": "핵심 상태 관리 설계보다 수치 검증에 초점이 있음"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "화면별 staleTime 적용 상황을 예시로 요구해 답변의 핵심 주장과 잘 연결됩니다. 표현이 다소 장황하고, 왜 그렇게 설정했는지나 어떤 문제를 해결했는지까지는 명확히 요구하지 않습니다.", "relevance": 5, "depth": 3, "language": 4, "overall": 4, "issue": "적용 방식만 묻고 판단 근거·효과 검증이 부족함"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "화면별 staleTime 설정 예시뿐 아니라 설정 방식과 해결한 문제까지 요구해 캐싱 전략의 근거와 효과를 함께 검증합니다. 지원자의 답변을 반복하지 않으면서 가장 변별력 있게 파고듭니다.", "relevance": 5, "depth": 5, "language": 4, "overall": 5, "issue": "문장이 다소 길어 간결성은 조금 아쉬움"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 0, "q-qwen3-4b-Instruct-2507-Q8_0": 1, "q-qwen3-4b-Instruct-2507-Q3_K_M": 2, "q-gemma4-e4b-Q8_0": 3, "q-gemma4-e4b-Q3_K_M": 4, "q-qwen3-4b-Instruct-2507-Q5_K_M": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 92, "q-qwen3-4b-Instruct-2507-Q8_0": 92, "q-qwen3-4b-Instruct-2507-Q3_K_M": 99, "q-gemma4-e4b-Q8_0": 90, "q-gemma4-e4b-Q3_K_M": 108, "q-qwen3-4b-Instruct-2507-Q5_K_M": 107}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-english-mixed", "ratings": {"q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "지원자가 언급한 화면별 staleTime 설정을 직접 짚고, 실제 사례와 해결한 문제까지 요구해 검증력이 있다. 다만 문장이 다소 길고 invalidation·dedupe 쪽 추가 검증은 없다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "좋은 질문이지만 서버 상태 전반보다 staleTime에만 집중됨"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "staleTime을 화면별로 다르게 줬다는 답변의 핵심 대목을 잘 이어받았다. 그러나 적용 예시만 요구해 트레이드오프나 버그 해결 검증까지는 약하다.", "relevance": 5, "depth": 3, "language": 4, "overall": 4, "issue": "구체 사례 요청에 그쳐 변별력이 다소 제한적"}, "q-gemma4-e4b-Q8_0": {"rationale": "지원자의 40% 감소라는 수치 주장을 정확히 짚고 측정 근거를 확인한다. 지표 검증 측면에서 좋지만 TanStack Query 선택 이유의 핵심인 캐싱·stale 관리보다는 다소 주변적이다.", "relevance": 5, "depth": 4, "language": 5, "overall": 4, "issue": "성능 수치 검증에 치우쳐 서버 상태 관리 설계 검증은 약함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "화면별 staleTime 설정이라는 구체 대목을 이어받아 이유를 묻는 점은 적절하다. 다만 '가장 길게 설정한 화면'으로 범위를 좁혀 실제 설계 판단 전반을 보기에는 제한적이다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "질문이 특정 사례 하나에 과도하게 좁혀짐"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자의 staleTime 설정 사례를 구체화하도록 유도해 관련성은 충분하다. 하지만 단순히 어떤 화면에 얼마나 설정했는지 묻는 수준이라 깊은 판단 근거 검증은 부족하다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "설정값 나열을 유도할 뿐 의사결정 근거를 충분히 파고들지 않음"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자의 staleTime 설정 사례를 구체화하도록 유도해 관련성은 충분하다. 하지만 단순히 어떤 화면에 얼마나 설정했는지 묻는 수준이라 깊은 판단 근거 검증은 부족하다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "설정값 나열을 유도할 뿐 의사결정 근거를 충분히 파고들지 않음"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 0, "q-gemma4-e4b-Q3_K_M": 1, "q-gemma4-e4b-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q3_K_M": 3, "q-qwen3-4b-Instruct-2507-Q8_0": 4, "q-qwen3-4b-Instruct-2507-Q4_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 107, "q-gemma4-e4b-Q3_K_M": 108, "q-gemma4-e4b-Q8_0": 90, "q-qwen3-4b-Instruct-2507-Q3_K_M": 99, "q-qwen3-4b-Instruct-2507-Q8_0": 92, "q-qwen3-4b-Instruct-2507-Q4_K_M": 92}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-frontend-strong", "ratings": {"q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "지원자의 답변 중 '높이 캐시'를 정확히 짚었으며, 동적 높이 리스트에서 핵심적인 캐시 무효화(invalidation) 조건을 물어보아 깊이가 훌륭합니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": ""}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "가상화(Virtualization)가 스크롤 위치에 따라 뷰포트에 보이는 항목을 렌더링한다는 기본 원리를 전혀 이해하지 못한 기술적 오류가 있는 질문입니다.", "relevance": 2, "depth": 1, "language": 4, "overall": 1, "issue": "가상화의 기본 원리에 어긋나는 질문"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자의 답변을 잘 반영하여 캐시 저장 방식과 갱신 조건을 물어보는 적절하고 자연스러운 질문입니다.", "relevance": 5, "depth": 4, "language": 5, "overall": 4, "issue": ""}, "q-gemma4-e4b-Q3_K_M": {"rationale": "구현 방식을 묻는 것은 좋으나, 캐싱이 가상화 성능에 미치는 영향은 이미 지원자가 답변한 내용(INP 감소)과 겹치거나 다소 뻔한 대답을 유도할 수 있습니다.", "relevance": 5, "depth": 3, "language": 5, "overall": 3, "issue": "다소 뻔한 대답을 유도하는 꼬리질문"}, "q-gemma4-e4b-Q8_0": {"rationale": "VariableSizeList 사용 시 가장 까다로운 문제인 '동적 높이 측정 방식'을 정확히 파고들어 실무적인 변별력이 매우 높은 질문입니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": ""}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "캐시 구현과 갱신 조건을 묻는 좋은 질문이나, UI 렌더링 캐시에서 '만료(expiration)'라는 용어는 시간 기반 캐시에 주로 쓰여 약간 어색합니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "문맥상 '만료'보다는 '무효화'나 '갱신'이 더 자연스러움"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 0, "q-qwen3-4b-Instruct-2507-Q3_K_M": 1, "q-qwen3-4b-Instruct-2507-Q4_K_M": 2, "q-gemma4-e4b-Q3_K_M": 3, "q-gemma4-e4b-Q8_0": 4, "q-qwen3-4b-Instruct-2507-Q8_0": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 116, "q-qwen3-4b-Instruct-2507-Q3_K_M": 188, "q-qwen3-4b-Instruct-2507-Q4_K_M": 118, "q-gemma4-e4b-Q3_K_M": 120, "q-gemma4-e4b-Q8_0": 133, "q-qwen3-4b-Instruct-2507-Q8_0": 96}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-frontend-strong", "ratings": {"q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자의 답변 중 '높이 캐시'를 잘 짚었으나, 프론트엔드 렌더링 캐시 맥락에서 '만료'보다는 '갱신'이나 '무효화'라는 용어가 더 자연스럽습니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "'만료'라는 용어 선택이 다소 어색함"}, "q-gemma4-e4b-Q8_0": {"rationale": "동적 높이 측정 및 캐싱 방식을 잘 물어보았으나, 질문이 다소 길고 장황한 편입니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "질문이 다소 길고 장황함"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "구현 방식을 묻는 것은 좋으나, 캐싱이 성능에 미치는 영향을 묻는 것은 다소 모호하고 뻔한 답변을 유도할 수 있습니다.", "relevance": 5, "depth": 3, "language": 4, "overall": 3, "issue": "캐시 갱신 전략보다 변별력이 떨어지는 후속 질문"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "높이 캐시의 저장 방식과 갱신 조건을 물어보아 실무적인 변별력이 높으며, 문맥과 용어 선택이 자연스럽습니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "없음"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "가상화 리스트가 뷰포트(화면에 보이는 영역)를 기준으로 항목을 렌더링한다는 기본 원리를 무시한 엉뚱한 질문입니다.", "relevance": 2, "depth": 1, "language": 4, "overall": 1, "issue": "가상화 기술에 대한 이해가 부족한 질문"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "지원자의 답변을 정확히 짚고, 캐시 구현 방식과 '무효화' 조건을 물어보아 프론트엔드 실무 지식을 검증하기에 매우 적절합니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "없음"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q8_0": 0, "q-gemma4-e4b-Q8_0": 1, "q-gemma4-e4b-Q3_K_M": 2, "q-qwen3-4b-Instruct-2507-Q4_K_M": 3, "q-qwen3-4b-Instruct-2507-Q3_K_M": 4, "q-qwen3-4b-Instruct-2507-Q5_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q8_0": 96, "q-gemma4-e4b-Q8_0": 133, "q-gemma4-e4b-Q3_K_M": 120, "q-qwen3-4b-Instruct-2507-Q4_K_M": 118, "q-qwen3-4b-Instruct-2507-Q3_K_M": 188, "q-qwen3-4b-Instruct-2507-Q5_K_M": 116}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-frontend-strong", "ratings": {"q-gemma4-e4b-Q3_K_M": {"rationale": "높이 캐시라는 동적 높이 트레이드오프를 정확히 인용해 파고들었으나, '성능에 미치는 영향'은 이미 INP 수치로 답한 부분과 겹쳐 변별력이 다소 낮다. 문장도 길고 질문이 두 갈래로 늘어진다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "성능 영향 부분이 기존 답변과 중복되어 추가 변별력이 약함"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "높이 캐시 구현과 무효화 시점을 물어 동적 높이 가상화의 실제 난점(resetAfterIndex, 내용 변경 시 재측정)을 짚는 실무형 질문이다. 다만 접근성 축은 여전히 미탐색이고 문장이 조금 길다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "접근성·검색 축은 건드리지 않아 기대 신호를 일부만 커버"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "B와 거의 동일한 초점이면서 더 간결해 읽기 좋다. 다만 캐시 '만료'는 TTL 뉘앙스로 이 맥락에선 '무효화/재측정'이 정확한 용어다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "'만료 조건'이라는 용어가 높이 캐시 맥락에 다소 부정확"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "캐시 저장 방식과 갱신 조건을 함께 물어 동적 높이의 핵심 난점을 잘 겨눈다. 의미는 정확하나 수식어가 많아 한 문장이 다소 길다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "문장이 길어 구두 질문으로는 장황함"}, "q-gemma4-e4b-Q8_0": {"rationale": "VariableSizeList와 높이 측정 방식을 구체적으로 물어 관련성은 높지만, 무효화·재측정 같은 어려운 지점 없이 구현 설명 요청에 머물러 변별력이 상대적으로 낮다. 문장이 길고 늘어진다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "측정·캐싱 방식 설명 요청에 그쳐 트레이드오프 탐색이 얕음"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "'화면에 보이는 30개'를 가상화의 뷰포트 계산이 아니라 선별 기준으로 오해하고, '높이가 가장 큰 항목 기준' 같은 틀린 예시를 제시해 면접관 신뢰도를 떨어뜨린다. '선택되었는가요' 등 비문도 있다.", "relevance": 2, "depth": 1, "language": 2, "overall": 1, "issue": "가상화 동작 원리를 오해한 잘못된 전제의 질문"}}, "positions": {"q-gemma4-e4b-Q3_K_M": 0, "q-qwen3-4b-Instruct-2507-Q5_K_M": 1, "q-qwen3-4b-Instruct-2507-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q4_K_M": 3, "q-gemma4-e4b-Q8_0": 4, "q-qwen3-4b-Instruct-2507-Q3_K_M": 5}, "ordering": 0, "output_chars": {"q-gemma4-e4b-Q3_K_M": 120, "q-qwen3-4b-Instruct-2507-Q5_K_M": 116, "q-qwen3-4b-Instruct-2507-Q8_0": 96, "q-qwen3-4b-Instruct-2507-Q4_K_M": 118, "q-gemma4-e4b-Q8_0": 133, "q-qwen3-4b-Instruct-2507-Q3_K_M": 188}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-frontend-strong", "ratings": {"q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "'30개가 어떤 기준으로 선택되는가, 높이가 가장 큰 항목 기준인가'는 가상화 동작(뷰포트+overscan)에 대한 잘못된 전제에서 나온 질문이라 변별력이 없고 면접관 신뢰도를 떨어뜨린다. 문장도 길고 '줄어든다는 점에서'처럼 논리 연결이 어색하다.", "relevance": 2, "depth": 1, "language": 2, "overall": 2, "issue": "가상화 기본 동작을 오해한 전제로 무의미한 질문을 던짐"}, "q-gemma4-e4b-Q8_0": {"rationale": "높이 캐시라는 답변의 약한 지점을 정확히 짚고 측정·캐싱 방식을 물어 타당하나, 접근성·검색 트레이드오프 축은 손대지 않아 깊이가 제한적이다. 한 문장이 다소 길고 늘어진다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "문장이 장황하고 접근성 축 미탐색"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "높이 캐시의 저장 방식과 '갱신 조건'까지 물어 동적 높이 처리의 취약점(내용 변경 시 재측정)을 자연스럽게 파고든다. 한국어도 간결하고 매끄럽다.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "접근성·검색 트레이드오프 축은 여전히 미탐색"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "가장 짧고 명료하며 캐시 구현과 무효화 시점을 묻는 핵심은 잘 잡았으나, '만료'는 TTL 뉘앙스라 재측정 조건을 묻는 표현으로는 약간 부정확하다.", "relevance": 4, "depth": 3, "language": 4, "overall": 4, "issue": "'만료' 용어가 높이 재측정 맥락과 미묘하게 어긋남"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "답변 문구를 정확히 인용하며 캐시 구현과 무효화 조건을 물어 동적 높이 처리의 실제 함정을 짚는다. 용어 선택도 적확하지만 문장이 조금 길다.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "문장이 다소 길고 접근성·검색 축은 다루지 않음"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "캐시 구현은 잘 짚었으나 뒤따르는 '가상화 성능에 미친 영향'은 이미 INP 수치로 답한 내용과 겹쳐 새로운 변별 정보를 끌어내기 어렵다. 문장도 길고 중복 표현이 있다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "후반부 질문이 이미 답한 성능 개선과 중복"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 0, "q-gemma4-e4b-Q8_0": 1, "q-qwen3-4b-Instruct-2507-Q4_K_M": 2, "q-qwen3-4b-Instruct-2507-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q5_K_M": 4, "q-gemma4-e4b-Q3_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 188, "q-gemma4-e4b-Q8_0": 133, "q-qwen3-4b-Instruct-2507-Q4_K_M": 118, "q-qwen3-4b-Instruct-2507-Q8_0": 96, "q-qwen3-4b-Instruct-2507-Q5_K_M": 116, "q-gemma4-e4b-Q3_K_M": 120}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-frontend-strong", "ratings": {"q-gemma4-e4b-Q3_K_M": {"rationale": "지원자가 언급한 ‘높이 캐시’를 정확히 짚고 구현 방식과 성능 영향을 묻는다. 다만 캐시 갱신·무효화 조건까지는 직접 파고들지 않아 변별력은 약간 제한된다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "성능 영향 질문은 좋지만 캐시 무효화 조건이 빠졌다."}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "INP 수치와 30개 렌더링을 짚었지만, 가상화에서 30개 항목이 ‘높이가 큰 항목 기준’으로 선택된다는 식의 오해가 섞여 있다. 질문 자체가 잘못된 방향으로 유도해 면접 품질이 낮다.", "relevance": 3, "depth": 2, "language": 2, "overall": 2, "issue": "react-window의 렌더링 기준을 오해한 질문이다."}, "q-gemma4-e4b-Q8_0": {"rationale": "VariableSizeList와 높이 캐시라는 핵심 트레이드오프를 잘 짚고, 동적 측정 구현을 구체적으로 묻는다. 다만 캐시 갱신 조건이나 resetAfterIndex 같은 후속 검증 포인트까지는 부족하다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "구현 방식에 집중되어 무효화·갱신 전략 검증이 약하다."}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "동적 높이 상황에서 캐시 저장 방식과 갱신 조건을 묻기 때문에 실제 구현 경험을 잘 가려낼 수 있다. 지원자 답변의 약한 축을 반복 없이 구체적으로 파고든다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "큰 문제 없음."}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "높이 캐시 구현과 무효화 조건을 함께 물어, VariableSizeList의 실제 운영 난점을 잘 검증한다. 간결하고 자연스러우며 바로 서비스에 내보내기 적합하다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "큰 문제 없음."}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "높이 캐시 구현과 조건을 묻는 방향은 적절하지만, ‘캐시가 만료되는 조건’이라는 표현은 동적 높이 캐시에는 다소 부정확하다. 무효화나 재측정 조건이라고 묻는 편이 더 자연스럽다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "‘만료’ 표현이 캐시 무효화 맥락과 조금 어긋난다."}}, "positions": {"q-gemma4-e4b-Q3_K_M": 0, "q-qwen3-4b-Instruct-2507-Q3_K_M": 1, "q-gemma4-e4b-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q4_K_M": 3, "q-qwen3-4b-Instruct-2507-Q5_K_M": 4, "q-qwen3-4b-Instruct-2507-Q8_0": 5}, "ordering": 0, "output_chars": {"q-gemma4-e4b-Q3_K_M": 120, "q-qwen3-4b-Instruct-2507-Q3_K_M": 188, "q-gemma4-e4b-Q8_0": 133, "q-qwen3-4b-Instruct-2507-Q4_K_M": 118, "q-qwen3-4b-Instruct-2507-Q5_K_M": 116, "q-qwen3-4b-Instruct-2507-Q8_0": 96}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-frontend-strong", "ratings": {"q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자 답변의 ‘동적 높이 캐시’ 대목을 정확히 짚고 구현과 만료 조건을 물어 변별력이 있습니다. 가상화의 핵심 난점인 reset/재측정 전략까지 이어질 수 있는 좋은 질문입니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "큰 문제 없음"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "높이 캐시 구현과 무효화 조건을 구체적으로 요구해 답변의 핵심 트레이드오프를 잘 파고듭니다. 문장이 약간 길지만 자연스럽고 서비스에 적합합니다.", "relevance": 5, "depth": 5, "language": 4, "overall": 5, "issue": "문장이 조금 길다"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "동적 높이 상황에서 캐시 저장 방식과 갱신 조건을 묻는 질문으로, 답변의 약한 구현 세부를 잘 검증합니다. 표현도 자연스럽고 간결합니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "큰 문제 없음"}, "q-gemma4-e4b-Q8_0": {"rationale": "VariableSizeList와 높이 캐시를 직접 짚고 측정·캐싱 구현을 묻는 점은 적절합니다. 다만 캐시 무효화나 동적 콘텐츠 변경 시 대응까지는 덜 파고듭니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "무효화 조건 질문이 빠져 깊이가 조금 부족함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "수치와 기술명을 언급해 겉보기 관련성은 있으나, ‘30개 항목을 어떤 기준으로 선택’이나 ‘높이가 가장 큰 항목 기준’은 react-window 동작을 오해한 질문입니다. 면접 질문으로 혼란을 줄 가능성이 큽니다.", "relevance": 2, "depth": 2, "language": 3, "overall": 2, "issue": "가상화 렌더 범위 선택 방식을 오해한 질문"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "높이 캐시 구현과 성능 영향까지 물어 가상화 적용의 효과를 검증할 수 있습니다. 다만 동적 높이에서 중요한 무효화·재측정 조건을 직접 묻지는 않아 A~C보다 약합니다.", "relevance": 5, "depth": 4, "language": 5, "overall": 4, "issue": "캐시 무효화 조건을 직접 확인하지 않음"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q8_0": 0, "q-qwen3-4b-Instruct-2507-Q5_K_M": 1, "q-qwen3-4b-Instruct-2507-Q4_K_M": 2, "q-gemma4-e4b-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q3_K_M": 4, "q-gemma4-e4b-Q3_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q8_0": 96, "q-qwen3-4b-Instruct-2507-Q5_K_M": 116, "q-qwen3-4b-Instruct-2507-Q4_K_M": 118, "q-gemma4-e4b-Q8_0": 133, "q-qwen3-4b-Instruct-2507-Q3_K_M": 188, "q-gemma4-e4b-Q3_K_M": 120}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-infra-fact-error", "ratings": {"q-gemma4-e4b-Q3_K_M": {"rationale": "시스템 프롬프트 용어인 '검색 문서'를 그대로 노출하여 면접관 페르소나를 심각하게 훼손했습니다.", "relevance": 4, "depth": 4, "language": 1, "overall": 1, "issue": "'검색 문서'라는 시스템 용어 노출"}, "q-gemma4-e4b-Q8_0": {"rationale": "이력서와 답변 내용이 상충하는 부분을 정확히 짚어냈으나, 문장이 다소 길고 피크 대응에 대한 모순점은 누락했습니다.", "relevance": 5, "depth": 4, "language": 3, "overall": 4, "issue": "다소 반복적인 어미 사용과 피크 대응 모순점 누락"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "이력서에 기재된 내용을 '다른 프로젝트'로 잘못 가정하여, 지원자의 답변과 이력서 간의 모순을 제대로 지적하지 못했습니다.", "relevance": 2, "depth": 2, "language": 4, "overall": 2, "issue": "이력서 맥락을 잘못 해석함"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "질문이 90자를 초과하여 장황하며, 이력서와의 내용 불일치를 명확히 지적하지 않고 일반적인 질문으로 우회했습니다.", "relevance": 3, "depth": 2, "language": 3, "overall": 2, "issue": "지나치게 길고 장황한 문장"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "질문은 간결하나, 이력서에 CPU 70%로 기재되어 있다는 사실을 직접 언급하지 않아 답변의 모순을 예리하게 찌르지 못했습니다.", "relevance": 3, "depth": 3, "language": 5, "overall": 3, "issue": "이력서와의 내용 불일치를 직접 언급하지 않음"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "이력서 내용을 '선택한 사례'로 뭉뚱그려 표현하여, 지원자 답변의 거짓이나 착오를 날카롭게 파고들지 못했습니다.", "relevance": 2, "depth": 2, "language": 4, "overall": 2, "issue": "이력서 맥락을 모호하게 표현함"}}, "positions": {"q-gemma4-e4b-Q3_K_M": 0, "q-gemma4-e4b-Q8_0": 1, "q-qwen3-4b-Instruct-2507-Q5_K_M": 2, "q-qwen3-4b-Instruct-2507-Q4_K_M": 3, "q-qwen3-4b-Instruct-2507-Q3_K_M": 4, "q-qwen3-4b-Instruct-2507-Q8_0": 5}, "ordering": 0, "output_chars": {"q-gemma4-e4b-Q3_K_M": 129, "q-gemma4-e4b-Q8_0": 109, "q-qwen3-4b-Instruct-2507-Q5_K_M": 104, "q-qwen3-4b-Instruct-2507-Q4_K_M": 139, "q-qwen3-4b-Instruct-2507-Q3_K_M": 81, "q-qwen3-4b-Instruct-2507-Q8_0": 89}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-infra-fact-error", "ratings": {"q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "이력서의 CPU 70% 내용을 간접적으로 언급하며 비교를 요구했으나, 이력서와 답변의 불일치를 명확히 짚어내지는 못했습니다.", "relevance": 4, "depth": 4, "language": 5, "overall": 4, "issue": "이력서와의 내용 상충을 직접적으로 지적하지 않음"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "이력서 내용을 바탕으로 CPU 70%를 언급했으나, 이력서에 기재되어 있다는 맥락을 생략해 질문이 다소 뜬금없게 들릴 수 있습니다.", "relevance": 3, "depth": 3, "language": 5, "overall": 3, "issue": "맥락 없는 수치(CPU 70%) 제시"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "질문이 너무 길고 장황하며, 여러 질문을 한 번에 던져 면접 대화로서 부자연스럽습니다.", "relevance": 3, "depth": 3, "language": 3, "overall": 2, "issue": "지나치게 길고 장황한 문장 구성"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "이력서의 내용을 '다른 프로젝트'로 임의로 가정하여 질문한 점이 아쉽습니다.", "relevance": 4, "depth": 3, "language": 5, "overall": 3, "issue": "이력서 내용을 다른 프로젝트로 단정지음"}, "q-gemma4-e4b-Q8_0": {"rationale": "이력서(CPU 70%)와 지원자의 답변(메모리 50%)이 상충하는 부분을 정확히 짚어내어 사실 확인을 요구하는 훌륭한 압박 질문입니다.", "relevance": 5, "depth": 5, "language": 4, "overall": 5, "issue": "'-는데'가 반복되어 문장이 약간 매끄럽지 않음"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "시스템 프롬프트 용어인 '검색 문서'를 그대로 노출하여 실제 면접관의 발화로 사용할 수 없습니다.", "relevance": 2, "depth": 3, "language": 1, "overall": 1, "issue": "'검색 문서'라는 시스템 용어 노출"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q8_0": 0, "q-qwen3-4b-Instruct-2507-Q3_K_M": 1, "q-qwen3-4b-Instruct-2507-Q4_K_M": 2, "q-qwen3-4b-Instruct-2507-Q5_K_M": 3, "q-gemma4-e4b-Q8_0": 4, "q-gemma4-e4b-Q3_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q8_0": 89, "q-qwen3-4b-Instruct-2507-Q3_K_M": 81, "q-qwen3-4b-Instruct-2507-Q4_K_M": 139, "q-qwen3-4b-Instruct-2507-Q5_K_M": 104, "q-gemma4-e4b-Q8_0": 109, "q-gemma4-e4b-Q3_K_M": 129}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-infra-fact-error", "ratings": {"q-gemma4-e4b-Q8_0": {"rationale": "답변의 메모리 50%와 이력서의 CPU 70% 불일치를 정면으로 짚어 변별력이 높으나, '~했는데/~되어 있는데'가 겹쳐 문장이 늘어지고 어색하다. 피크 대응 CronJob 누락은 짚지 못했다.", "relevance": 5, "depth": 4, "language": 3, "overall": 4, "issue": "연결어 중복으로 문장이 길고 어색함"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "모순을 지적하고 어느 쪽이 실제 설계인지 이유까지 물어 검증력은 좋지만, '검색 문서'라는 내부 시스템 용어를 면접 발화에 노출했고 문장이 과도하게 길다.", "relevance": 5, "depth": 4, "language": 2, "overall": 3, "issue": "'검색 문서' 내부 용어 노출 및 장문"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "메모리 기준 근거를 묻는 점은 적절하나, 이력서에 없는 'CPU 70%를 사용한 다른 프로젝트'를 전제해 사실을 왜곡했다. 사전 스케일아웃 부재도 놓쳤다.", "relevance": 3, "depth": 3, "language": 4, "overall": 3, "issue": "존재하지 않는 다른 프로젝트를 전제한 사실 오류"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "간결하고 메트릭 선택 근거를 바로 파고들지만, 'CPU 70%가 더 적절하지 않았나요'는 답을 유도하는 형태이고 이력서 모순임을 명시하지 않아 검증 강도가 약하다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "유도성 질문이며 이력서 불일치를 명시하지 않음"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "근거를 묻는 방향은 맞으나 'CPU 70%를 선택한 사례'의 주체가 불명확해 지원자가 질문 의도를 오해할 수 있고, 기대 신호인 사전 스케일아웃은 다루지 않았다.", "relevance": 3, "depth": 3, "language": 4, "overall": 3, "issue": "비교 대상 '사례'의 주체가 불명확함"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "메모리 임계값의 판단 근거와 CPU 대비 선택 이유를 함께 물어 깊이는 있으나, 예시가 붙은 다중 질문으로 길고 구어체로 산만하다.", "relevance": 4, "depth": 4, "language": 2, "overall": 3, "issue": "질문이 두세 개로 쪼개진 장문"}}, "positions": {"q-gemma4-e4b-Q8_0": 0, "q-gemma4-e4b-Q3_K_M": 1, "q-qwen3-4b-Instruct-2507-Q5_K_M": 2, "q-qwen3-4b-Instruct-2507-Q3_K_M": 3, "q-qwen3-4b-Instruct-2507-Q8_0": 4, "q-qwen3-4b-Instruct-2507-Q4_K_M": 5}, "ordering": 0, "output_chars": {"q-gemma4-e4b-Q8_0": 109, "q-gemma4-e4b-Q3_K_M": 129, "q-qwen3-4b-Instruct-2507-Q5_K_M": 104, "q-qwen3-4b-Instruct-2507-Q3_K_M": 81, "q-qwen3-4b-Instruct-2507-Q8_0": 89, "q-qwen3-4b-Instruct-2507-Q4_K_M": 139}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-infra-fact-error", "ratings": {"q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "메모리 50% 근거를 짚었고 CPU 70%도 언급했지만 이력서와의 불일치를 명확히 대조하지 않고 예시까지 덧붙여 장황하다. 피크 대응 공백(사전 스케일아웃)은 전혀 파고들지 못했다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "질문이 두 갈래로 길고 기대 신호의 절반인 사전 스케일아웃을 놓침"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "간결하게 메모리 50% 근거를 묻지만 'CPU 70%를 선택한 사례'가 어디 사례인지 불명확해 지원자가 혼란스러울 수 있다. 피크 대응 미비는 다루지 않았다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "CPU 70% 출처(이력서)를 명시하지 않아 대조 의도가 흐릿함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "짧고 읽기 쉬우나 'CPU 70%가 더 적절하지 않았나요'는 면접관이 정답을 유도하는 압박형 문장이라 변별력이 떨어진다. 피크 대응 공백도 미검증.", "relevance": 3, "depth": 3, "language": 4, "overall": 3, "issue": "유도·단정형 어조로 근거 탐색보다 지적에 가까움"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "이력서의 CPU 70%를 '다른 프로젝트'로 잘못 설정해 사실관계를 왜곡했고, 비교 경험 유무를 묻는 예/아니오 질문이라 깊이가 얕다.", "relevance": 3, "depth": 2, "language": 3, "overall": 2, "issue": "존재하지 않는 '다른 프로젝트'를 전제로 한 사실 왜곡"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "이력서와의 모순을 정면으로 짚은 점은 변별력이 있으나 '검색 문서'라는 내부 용어를 노출했고 '~는데'가 반복되는 장문이라 면접 발화로 부자연스럽다.", "relevance": 4, "depth": 4, "language": 2, "overall": 3, "issue": "내부 시스템 용어(검색 문서) 노출과 지나치게 긴 한 문장"}, "q-gemma4-e4b-Q8_0": {"rationale": "답변의 메모리 50%와 이력서의 CPU 70% 불일치를 자연스럽게 대조해 실제 설계를 확인하는 실전형 질문이다. 다만 사전 스케일아웃 CronJob 관련 모순은 묻지 않았고 '~는데'가 중복된다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "피크 대응(사전 스케일아웃) 모순은 끝까지 검증하지 못함"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 0, "q-qwen3-4b-Instruct-2507-Q8_0": 1, "q-qwen3-4b-Instruct-2507-Q3_K_M": 2, "q-qwen3-4b-Instruct-2507-Q5_K_M": 3, "q-gemma4-e4b-Q3_K_M": 4, "q-gemma4-e4b-Q8_0": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 139, "q-qwen3-4b-Instruct-2507-Q8_0": 89, "q-qwen3-4b-Instruct-2507-Q3_K_M": 81, "q-qwen3-4b-Instruct-2507-Q5_K_M": 104, "q-gemma4-e4b-Q3_K_M": 129, "q-gemma4-e4b-Q8_0": 109}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-infra-fact-error", "ratings": {"q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자 답변의 '메모리 50%'를 짚고 이력서의 CPU 70%와 비교를 요구해 관련성은 높습니다. 다만 피크 대응을 HPA에만 맡겼다는 약점을 파고들지 못합니다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "사전 스케일아웃 누락을 추궁하지 않음"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "메모리 50% 기준의 근거와 CPU 70%와의 차이를 구체적으로 묻는 점은 좋습니다. 하지만 질문이 길고, 피크 대응 설계 부재라는 핵심 약점을 놓쳤습니다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "핵심 기대 신호 중 피크 대응을 다루지 않음"}, "q-gemma4-e4b-Q8_0": {"rationale": "답변과 이력서의 HPA 메트릭 불일치를 정확히 짚어 검증 질문으로 적절합니다. 다만 실제 메트릭 확인에 그쳐 선택 근거와 사전 스케일아웃 이유까지 확장하지 못했습니다.", "relevance": 5, "depth": 3, "language": 4, "overall": 4, "issue": "불일치 확인 이후의 설계 근거 검증이 부족함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "메모리 50% 기준의 이유를 묻는 점은 관련성이 있습니다. 그러나 'CPU 70%가 더 적절하지 않았나요'는 다소 유도적이고, 피크 대응 방식의 허점을 묻지 않습니다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "유도 질문에 가깝고 피크 대응 검증이 없음"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "답변과 문서의 CPU 70% 불일치를 짚고 실제 설계와 이유를 묻는 점이 가장 명확합니다. 다만 '검색 문서'라는 표현은 면접 맥락에서 어색하고, 사전 스케일아웃 누락은 별도로 묻지 않습니다.", "relevance": 5, "depth": 4, "language": 3, "overall": 4, "issue": "면접 질문에 '검색 문서' 표현이 부자연스러움"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "메모리 50% 기준 근거를 묻는 점은 적절하지만, CPU 70%를 '다른 프로젝트'로 표현해 주어진 이력서 맥락과 어긋납니다. 피크 대응 설계의 부재도 파고들지 못했습니다.", "relevance": 3, "depth": 3, "language": 4, "overall": 3, "issue": "CPU 70% 맥락을 잘못 해석함"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q8_0": 0, "q-qwen3-4b-Instruct-2507-Q4_K_M": 1, "q-gemma4-e4b-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q3_K_M": 3, "q-gemma4-e4b-Q3_K_M": 4, "q-qwen3-4b-Instruct-2507-Q5_K_M": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q8_0": 89, "q-qwen3-4b-Instruct-2507-Q4_K_M": 139, "q-gemma4-e4b-Q8_0": 109, "q-qwen3-4b-Instruct-2507-Q3_K_M": 81, "q-gemma4-e4b-Q3_K_M": 129, "q-qwen3-4b-Instruct-2507-Q5_K_M": 104}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-infra-fact-error", "ratings": {"q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "지원자 답변의 메모리 50% 기준을 짚고 이력서의 CPU 70%와 비교를 요구해 관련성은 높습니다. 다만 피크 대응을 HPA에만 맡긴 부분이나 사전 스케일아웃 누락은 파고들지 못했습니다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "피크 대응 방식의 약점을 추가로 검증하지 못함"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "메모리 50% 답변과 문서의 CPU 70% 불일치를 직접 확인해 핵심 모순을 잘 짚었습니다. 그러나 '검색 문서'라는 표현은 면접 상황에서 부자연스럽고, 사전 스케일아웃 누락은 묻지 않았습니다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "'검색 문서' 표현이 부자연스럽고 피크 대응 검증이 빠짐"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "메모리 50% 기준의 근거를 묻는 점은 적절하지만, CPU 70%가 더 적절하다는 식의 유도 질문에 가깝습니다. 이력서와의 불일치나 사전 스케일아웃 미흡을 충분히 파고들지 못했습니다.", "relevance": 3, "depth": 3, "language": 4, "overall": 3, "issue": "질문이 다소 유도적이고 피크 대응 검증이 부족함"}, "q-gemma4-e4b-Q8_0": {"rationale": "답변과 이력서의 메트릭 불일치를 정확히 짚고 실제 적용 메트릭을 확인하는 질문이라 관련성이 높습니다. 다만 선택 근거와 트래픽 피크 사전 대응까지 확장하지 않아 변별력은 제한적입니다.", "relevance": 5, "depth": 3, "language": 5, "overall": 4, "issue": "실제 메트릭 확인에 그치고 설계 근거와 피크 대응을 묻지 않음"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "메모리 50% 기준의 근거와 성능 영향, CPU 70%가 아닌 이유를 구체적으로 요구해 메트릭 선택 근거를 잘 파고듭니다. 다만 답변의 또 다른 약점인 피크 사전 스케일아웃 부재는 검증하지 못했고 문장이 다소 깁니다.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "메트릭 근거에는 강하지만 피크 대응 설계 검증이 빠짐"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "메모리 50% 기준의 이유와 CPU 70% 사례 비교를 요구해 핵심 메트릭 선택 근거를 확인할 수 있습니다. 하지만 이력서와의 불일치를 명확히 짚지 않고, 사전 스케일아웃 누락도 다루지 않습니다.", "relevance": 4, "depth": 3, "language": 5, "overall": 3, "issue": "비교 질문은 적절하나 피크 대응 누락을 파고들지 않음"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 0, "q-gemma4-e4b-Q3_K_M": 1, "q-qwen3-4b-Instruct-2507-Q3_K_M": 2, "q-gemma4-e4b-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q4_K_M": 4, "q-qwen3-4b-Instruct-2507-Q8_0": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 104, "q-gemma4-e4b-Q3_K_M": 129, "q-qwen3-4b-Instruct-2507-Q3_K_M": 81, "q-gemma4-e4b-Q8_0": 109, "q-qwen3-4b-Instruct-2507-Q4_K_M": 139, "q-qwen3-4b-Instruct-2507-Q8_0": 89}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-long-answer-history", "ratings": {"q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "지원자가 언급한 스위퍼 배치의 구체적인 실행 주기와 타 서비스 상태 확인 로직을 파고들어 적절한 변별력을 가집니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "질문이 다소 길지만 허용 범위 내임"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "멱등성 처리 로직을 묻는 핵심은 좋으나, 지원자의 답변을 그대로 읊는 배경 설명이 너무 길어 부자연스럽습니다.", "relevance": 4, "depth": 4, "language": 2, "overall": 2, "issue": "불필요하게 길고 장황한 배경 설명 (170자 이상)"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "이벤트 기반 아키텍처에서 보상 흐름은 당연히 이벤트를 수신한 시점에 실행되므로, '어떤 시점에서 실행되는지'를 묻는 것은 의도가 불분명합니다.", "relevance": 3, "depth": 2, "language": 3, "overall": 2, "issue": "질문의 의도가 모호하고 변별력이 낮음"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자의 답변을 거의 그대로 반복하며 200자가 넘는 매우 장황한 문장을 구사하여 면접관의 질문으로 부적합합니다.", "relevance": 3, "depth": 2, "language": 1, "overall": 1, "issue": "지나치게 길고 복잡한 문장 구조"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "재조회 후 최종 상태로 업데이트해야 하는데 '다시 PENDING 상태로 되돌리는지'를 묻고 있어 논리적 오류가 있습니다.", "relevance": 3, "depth": 2, "language": 3, "overall": 2, "issue": "지원자의 의도와 어긋나는 논리적 오류 포함"}, "q-gemma4-e4b-Q8_0": {"rationale": "지원자가 이미 '30분 이상 PENDING인 주문'이라고 명확히 답했음에도 타임스탬프나 상태 코드를 다시 묻고 있어 대화의 흐름을 끊습니다.", "relevance": 3, "depth": 1, "language": 4, "overall": 1, "issue": "지원자가 이미 답변한 내용을 중복해서 질문함"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 0, "q-qwen3-4b-Instruct-2507-Q4_K_M": 1, "q-qwen3-4b-Instruct-2507-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q3_K_M": 3, "q-gemma4-e4b-Q3_K_M": 4, "q-gemma4-e4b-Q8_0": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 146, "q-qwen3-4b-Instruct-2507-Q4_K_M": 234, "q-qwen3-4b-Instruct-2507-Q8_0": 149, "q-qwen3-4b-Instruct-2507-Q3_K_M": 282, "q-gemma4-e4b-Q3_K_M": 184, "q-gemma4-e4b-Q8_0": 127}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-long-answer-history", "ratings": {"q-gemma4-e4b-Q8_0": {"rationale": "지원자가 이미 '30분 이상 PENDING'이라고 기준을 밝혔음에도 상태 코드나 타임스탬프 기준을 다시 묻고 있어 대화를 반복하는 셈입니다.", "relevance": 2, "depth": 2, "language": 4, "overall": 2, "issue": "이미 답변한 내용을 중복 질문함"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "스위퍼 배치가 주문을 '다시 PENDING 상태로 되돌린다'는 잘못된 이해를 바탕으로 질문하여 문맥에 완전히 어긋납니다.", "relevance": 1, "depth": 1, "language": 3, "overall": 1, "issue": "지원자의 답변 내용을 잘못 이해함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자의 답변 내용을 불필요하게 길게 요약하여 질문이 장황하며, '어떤 로직에서 소비하는지'라는 질문도 다소 모호합니다.", "relevance": 3, "depth": 2, "language": 2, "overall": 2, "issue": "서론이 지나치게 길고 장황함"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "보상 처리가 '어떤 시점에서 실행되는지' 묻는 것은 이벤트를 소비할 때라는 뻔한 답변을 유도하므로 변별력이 낮습니다.", "relevance": 3, "depth": 2, "language": 4, "overall": 2, "issue": "질문의 의도가 모호하고 깊이가 얕음"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "멱등성 처리 로직을 묻는 것은 좋은 접근이나, 질문의 서론이 지원자의 답변을 그대로 반복하여 너무 길고 장황합니다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "불필요하게 긴 서론"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "스위퍼 배치가 타 서비스의 상태를 어떻게 확인하여 정합성을 맞추는지(재조회 로직) 묻는 것은 분산 환경의 핵심을 찌르는 좋은 질문입니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "권장 길이(60자)를 초과하여 다소 김"}}, "positions": {"q-gemma4-e4b-Q8_0": 0, "q-gemma4-e4b-Q3_K_M": 1, "q-qwen3-4b-Instruct-2507-Q3_K_M": 2, "q-qwen3-4b-Instruct-2507-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q4_K_M": 4, "q-qwen3-4b-Instruct-2507-Q5_K_M": 5}, "ordering": 1, "output_chars": {"q-gemma4-e4b-Q8_0": 127, "q-gemma4-e4b-Q3_K_M": 184, "q-qwen3-4b-Instruct-2507-Q3_K_M": 282, "q-qwen3-4b-Instruct-2507-Q8_0": 149, "q-qwen3-4b-Instruct-2507-Q4_K_M": 234, "q-qwen3-4b-Instruct-2507-Q5_K_M": 146}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-long-answer-history", "ratings": {"q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "보상 흐름을 짚긴 했으나 '어떤 시점에서 실행되는지'라는 모호한 질문이라 변별력이 낮고, 지원자가 이미 설명한 흐름을 되묻는 성격이 강하다.", "relevance": 3, "depth": 2, "language": 4, "overall": 2, "issue": "질문 초점이 모호해 이미 답변한 내용을 반복시킬 가능성이 큼"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "스위퍼라는 가장 약한 축을 겨냥한 점은 좋으나, '정상 상태로 판단하고 다시 PENDING으로 되돌린다'는 전제가 답변 내용과 어긋나 오독이 드러난다. 문장도 지나치게 길다.", "relevance": 4, "depth": 3, "language": 2, "overall": 2, "issue": "답변을 잘못 이해한 전제(PENDING으로 되돌림)가 질문에 섞임"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "정합성 보장의 가장 취약한 지점인 스위퍼의 실행 시점·재조회 설계를 직접 파고들어 실무적으로 유효하고, 문장도 비교적 자연스럽다. 다만 '실행 시점' 부분은 다소 평이하다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "질문이 조금 길고 재조회 신뢰성(소스 오브 트루스)까지는 못 파고듦"}, "q-gemma4-e4b-Q8_0": {"rationale": "스위퍼를 짚은 방향은 맞지만 '타임스탬프·상태 코드' 같은 형식적 기준을 묻는 사소한 질문이라 면접 변별력이 떨어진다.", "relevance": 4, "depth": 2, "language": 4, "overall": 2, "issue": "조회 조건 형식 수준의 지엽적 질문"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자 답변을 거의 그대로 장황하게 재나열한 뒤 '어떤 로직에서 소비하는지'라는 모호한 질문으로 끝나 정보 이득이 거의 없다.", "relevance": 3, "depth": 2, "language": 1, "overall": 1, "issue": "과도한 중복 요약과 초점 없는 질문으로 사실상 재진술"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "멱등 처리 구현을 묻는 것 자체는 유효하나, 앞부분 흐름 재나열이 길고 재고 차감 요청 방식 서술도 부정확해 질문이 산만하다.", "relevance": 3, "depth": 2, "language": 2, "overall": 2, "issue": "장황한 전제와 부정확한 흐름 요약으로 질문 핵심이 흐려짐"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q8_0": 0, "q-gemma4-e4b-Q3_K_M": 1, "q-qwen3-4b-Instruct-2507-Q5_K_M": 2, "q-gemma4-e4b-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q3_K_M": 4, "q-qwen3-4b-Instruct-2507-Q4_K_M": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q8_0": 149, "q-gemma4-e4b-Q3_K_M": 184, "q-qwen3-4b-Instruct-2507-Q5_K_M": 146, "q-gemma4-e4b-Q8_0": 127, "q-qwen3-4b-Instruct-2507-Q3_K_M": 282, "q-qwen3-4b-Instruct-2507-Q4_K_M": 234}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-long-answer-history", "ratings": {"q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "이벤트 ID 기반 멱등 처리라는 답변의 실제 대목을 짚은 점은 적절하나, 앞부분에 전체 이벤트 흐름을 불필요하게 장황하게 되풀이해 질문 핵심이 흐려진다. 멱등 키 저장소·보존 기간 같은 변별 포인트로 좁히지 못하고 '구체적으로'에 머물렀다.", "relevance": 3, "depth": 3, "language": 2, "overall": 3, "issue": "지원자 답변 요약이 질문의 대부분을 차지해 과도하게 길다"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자가 이미 설명한 보상 흐름 전체를 그대로 재서술한 뒤 '어떻게 구현했는지'만 묻고 있어 사실상 대화 반복에 가깝다. 질문 초점이 둘(구현 방식/소비 로직)로 갈라져 모호하다.", "relevance": 2, "depth": 2, "language": 1, "overall": 2, "issue": "이미 답한 내용을 그대로 되묻는 장황한 중복 질문"}, "q-gemma4-e4b-Q8_0": {"rationale": "답변에서 가장 임시방편적인 스위퍼 배치를 짚은 선택은 타당하고 문장도 간결하다. 다만 '타임스탬프/상태 코드 기준'이라는 세부 스펙 확인에 그쳐 Saga 설계 역량을 가르는 변별력은 중간 수준이다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "질문 축이 다소 지엽적(조회 기준 확인)이라 변별력이 제한적"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "답변의 약한 고리인 스위퍼 배치를 실행 주기와 상태 재조회 로직 두 축으로 자연스럽게 파고들어 설계 판단을 드러내게 한다. 문장이 간결하고 한국어도 매�끄럽다.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "보상 실패·조회 모델 정합성 등 더 깊은 축까지는 가지 못함"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "스위퍼를 겨냥한 것은 좋으나 '정상 상태로 판단하고 다시 PENDING으로 되돌린다'는 질문 전제가 답변 내용과 모순되어 지원자가 혼란을 겪을 수 있다. 문장도 길고 꼬여 있다.", "relevance": 3, "depth": 2, "language": 2, "overall": 2, "issue": "답변을 잘못 이해한 모순된 전제로 질문을 구성함"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "PaymentFailed 이벤트에 결제 서비스가 취소를 한다는 식으로 지원자가 말한 보상 흐름을 잘못 옮겼고, '어떤 시점에 실행되는지'라는 질문도 모호해 기대 신호와 연결되지 않는다.", "relevance": 2, "depth": 2, "language": 3, "overall": 2, "issue": "이벤트 흐름을 잘못 인용한 부정확한 질문"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 0, "q-qwen3-4b-Instruct-2507-Q3_K_M": 1, "q-gemma4-e4b-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q5_K_M": 3, "q-gemma4-e4b-Q3_K_M": 4, "q-qwen3-4b-Instruct-2507-Q8_0": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 234, "q-qwen3-4b-Instruct-2507-Q3_K_M": 282, "q-gemma4-e4b-Q8_0": 127, "q-qwen3-4b-Instruct-2507-Q5_K_M": 146, "q-gemma4-e4b-Q3_K_M": 184, "q-qwen3-4b-Instruct-2507-Q8_0": 149}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-long-answer-history", "ratings": {"q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자 답변의 이벤트·보상 흐름을 짚고는 있지만 대부분을 길게 반복하며, 일부 주체 관계도 어색합니다. 구현 로직을 묻는 방향은 가능하나 질문이 장황해 변별력이 떨어집니다.", "relevance": 3, "depth": 3, "language": 2, "overall": 2, "issue": "답변 내용을 과도하게 반복하고 질문이 너무 장황함"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "지원자가 운영 이슈로 언급한 PENDING 스위퍼 배치를 정확히 짚고, 실행 시점과 재조회 로직을 물어 실무 검증성이 있습니다. 다만 Saga 전체 정합성 설계보다 특정 운영 보완책에 초점이 좁습니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "좋은 질문이지만 스위퍼 구현 세부에 다소 한정됨"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "보상 흐름을 묻는 의도는 맞지만 PaymentFailed와 결제 취소 흐름을 섞어 사실관계가 부정확합니다. 질문도 '어떤 시점'에 머물러 깊이가 약합니다.", "relevance": 2, "depth": 2, "language": 3, "overall": 2, "issue": "이벤트 흐름을 잘못 이해한 질문"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "PENDING 스위퍼의 판단 기준을 묻는 점은 관련성이 있지만, '정상 상태로 판단하고 다시 PENDING으로 되돌린다'는 표현이 논리적으로 어색합니다. 지원자 답변의 해결 방향을 잘못 해석한 인상이 큽니다.", "relevance": 3, "depth": 2, "language": 2, "overall": 2, "issue": "상태 전이 이해가 부정확하고 질문 문장이 어색함"}, "q-gemma4-e4b-Q8_0": {"rationale": "보상 이벤트 유실과 스위퍼 배치라는 구체적 대목을 짚고, 재조회 기준을 물어 운영 정합성 검증에 적절합니다. 간결하고 자연스러우며 실제 면접 꼬리질문으로 사용 가능합니다.", "relevance": 5, "depth": 4, "language": 5, "overall": 4, "issue": "좋지만 재조회 대상 시스템이나 최종 상태 결정 방식까지는 덜 파고듦"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "멱등 처리 로직을 묻는 것은 분산 이벤트 처리에서 중요한 심화 질문입니다. 다만 PaymentApproved 수신 주체를 잘못 표현했고 문장이 지나치게 길어 명확성이 떨어집니다.", "relevance": 3, "depth": 4, "language": 2, "overall": 3, "issue": "핵심 주체 관계 오류와 장황한 문장"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 0, "q-qwen3-4b-Instruct-2507-Q5_K_M": 1, "q-qwen3-4b-Instruct-2507-Q8_0": 2, "q-gemma4-e4b-Q3_K_M": 3, "q-gemma4-e4b-Q8_0": 4, "q-qwen3-4b-Instruct-2507-Q4_K_M": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 282, "q-qwen3-4b-Instruct-2507-Q5_K_M": 146, "q-qwen3-4b-Instruct-2507-Q8_0": 149, "q-gemma4-e4b-Q3_K_M": 184, "q-gemma4-e4b-Q8_0": 127, "q-qwen3-4b-Instruct-2507-Q4_K_M": 234}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-long-answer-history", "ratings": {"q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "이벤트 ID 기반 멱등 처리라는 답변의 특정 대목을 잘 짚었고, 분산 이벤트 처리에서 중요한 검증 포인트입니다. 다만 질문이 지나치게 길고 흐름을 재진술하는 비중이 커서 면접 질문으로는 다소 장황합니다.", "relevance": 4, "depth": 4, "language": 2, "overall": 3, "issue": "질문이 너무 길고 반복 설명이 많아 핵심이 흐려짐"}, "q-gemma4-e4b-Q8_0": {"rationale": "보상 이벤트 유실과 스위퍼 배치라는 운영상 핵심 대목을 정확히 짚었습니다. 재조회 기준을 묻는 질문은 실제 정합성 회복 설계를 검증할 수 있어 변별력이 있습니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "타임스탬프·상태 코드 기준에 다소 좁게 한정됨"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "30분 이상 PENDING 주문 재조회라는 구체적 내용을 짚은 점은 좋습니다. 그러나 이미 PENDING인 주문을 '다시 PENDING 상태로 되돌린다'는 표현이 논리적으로 어색해 질문 의도가 흔들립니다.", "relevance": 3, "depth": 3, "language": 2, "overall": 2, "issue": "상태 전이 표현이 부정확해 기술적으로 혼란을 줌"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "보상 흐름을 묻는 방향은 관련이 있지만, PaymentFailed와 결제 취소 흐름을 섞어 답변 내용을 부정확하게 재구성했습니다. '어떤 시점에서 실행되는지'도 다소 모호해 깊이가 부족합니다.", "relevance": 2, "depth": 2, "language": 3, "overall": 2, "issue": "이벤트 흐름을 잘못 이해한 듯한 질문"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "지원자가 언급한 30분 이상 PENDING 스위퍼를 정확히 짚고, 실행 시점과 재조회 로직을 물어 운영 설계 검증으로 이어집니다. 간결하고 실제 면접에서 자연스럽게 사용할 수 있습니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "보상 처리의 정합성 판정 기준까지는 조금 더 구체화할 수 있음"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "전체 이벤트 흐름을 다시 읊은 뒤 구현 로직을 묻고 있어 관련성은 있으나 반복이 과도합니다. 질문이 길고 초점이 넓어 어떤 역량을 검증하려는지 선명하지 않습니다.", "relevance": 3, "depth": 3, "language": 2, "overall": 2, "issue": "장황한 재진술과 넓은 질문 범위로 면접 변별력이 떨어짐"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 0, "q-gemma4-e4b-Q8_0": 1, "q-gemma4-e4b-Q3_K_M": 2, "q-qwen3-4b-Instruct-2507-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q5_K_M": 4, "q-qwen3-4b-Instruct-2507-Q3_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 234, "q-gemma4-e4b-Q8_0": 127, "q-gemma4-e4b-Q3_K_M": 184, "q-qwen3-4b-Instruct-2507-Q8_0": 149, "q-qwen3-4b-Instruct-2507-Q5_K_M": 146, "q-qwen3-4b-Instruct-2507-Q3_K_M": 282}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-personality-rambling", "ratings": {"q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "구체적인 사례를 요구하는 방향은 좋으나, '영향을 준다고 말씀해 주실 수 있나요?'라는 표현이 과거 경험을 묻는 것인지 일반적인 생각을 묻는 것인지 모호하게 들립니다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "어색한 시제 및 표현"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자의 답변에서 부족한 STAR 요소를 잘 짚어냈으나, 한 번에 너무 많은 질문을 던져 문장이 지나치게 깁니다.", "relevance": 4, "depth": 4, "language": 2, "overall": 3, "issue": "질문이 너무 길고 복합적임"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "상황을 '가정'하라고 하면서 과거에 어떻게 '시도하셨는지' 묻는 논리적 모순이 있어 질문이 매우 어색합니다.", "relevance": 3, "depth": 2, "language": 2, "overall": 2, "issue": "가정과 과거 경험을 묻는 시제의 논리적 모순"}, "q-gemma4-e4b-Q8_0": {"rationale": "지원자의 발언('서로 대화를 많이 하는 것')을 직접 인용하여 자연스럽게 연결했으며, 누락된 구체적 상황과 해결 과정을 묻는 핵심을 정확히 찔렀습니다.", "relevance": 5, "depth": 5, "language": 4, "overall": 5, "issue": "없음"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "구체적인 사례와 결과를 묻는 의도는 훌륭하나, 문장이 다소 길어 면접관의 질문이라기보다 서면 질의처럼 느껴집니다.", "relevance": 4, "depth": 4, "language": 3, "overall": 4, "issue": "문장이 다소 길고 장황함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "구체적인 상황이나 결과보다는 '어떤 말로 시작했는지'와 같은 지나치게 지엽적인 대화 기법에 집착하여 변별력을 확보하기 어렵습니다.", "relevance": 3, "depth": 2, "language": 3, "overall": 2, "issue": "핵심을 벗어난 지엽적인 꼬리질문"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 0, "q-qwen3-4b-Instruct-2507-Q4_K_M": 1, "q-gemma4-e4b-Q3_K_M": 2, "q-gemma4-e4b-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q8_0": 4, "q-qwen3-4b-Instruct-2507-Q3_K_M": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 95, "q-qwen3-4b-Instruct-2507-Q4_K_M": 131, "q-gemma4-e4b-Q3_K_M": 115, "q-gemma4-e4b-Q8_0": 106, "q-qwen3-4b-Instruct-2507-Q8_0": 115, "q-qwen3-4b-Instruct-2507-Q3_K_M": 119}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-personality-rambling", "ratings": {"q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자의 답변을 짚었으나, 구체적인 경험(STAR)을 묻기보다 대화 기법이나 시작하는 말 등 지나치게 지엽적인 부분을 물어 변별력이 떨어집니다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "지엽적인 꼬리질문"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자가 누락한 구체적인 사례와 그에 따른 결과(STAR)를 명확하게 요구하여 면접 변별력을 높입니다.", "relevance": 5, "depth": 5, "language": 4, "overall": 4, "issue": "다소 긴 문장 길이"}, "q-gemma4-e4b-Q8_0": {"rationale": "지원자의 답변 내용('서로 대화를 많이 하는 것')을 직접 인용하며 구체적인 경험과 해결 과정을 요구해 매우 자연스럽고 예리합니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "없음"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "상황을 '가정'하라고 하면서 과거형('시도하셨는지')으로 묻는 논리적 모순이 있어 질문이 어색합니다.", "relevance": 3, "depth": 3, "language": 2, "overall": 2, "issue": "시제와 논리가 맞지 않는 어색한 문장"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "요구하는 바는 명확하나 질문이 여러 문장으로 나뉘어 있고 길이가 100자를 초과하여 구두 면접용으로는 다소 장황합니다.", "relevance": 5, "depth": 4, "language": 3, "overall": 3, "issue": "권장 길이를 초과한 장황한 질문"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "구체적인 사례를 묻고 있으나, '영향을 준다고 말씀해 주실 수 있나요?'라는 마무리가 과거 경험을 묻는 맥락에서 다소 어색합니다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "어색한 문장 호응"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 0, "q-qwen3-4b-Instruct-2507-Q8_0": 1, "q-gemma4-e4b-Q8_0": 2, "q-gemma4-e4b-Q3_K_M": 3, "q-qwen3-4b-Instruct-2507-Q4_K_M": 4, "q-qwen3-4b-Instruct-2507-Q5_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 119, "q-qwen3-4b-Instruct-2507-Q8_0": 115, "q-gemma4-e4b-Q8_0": 106, "q-gemma4-e4b-Q3_K_M": 115, "q-qwen3-4b-Instruct-2507-Q4_K_M": 131, "q-qwen3-4b-Instruct-2507-Q5_K_M": 95}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-personality-rambling", "ratings": {"q-gemma4-e4b-Q8_0": {"rationale": "답변의 '서로 대화를 많이 하는 것'이라는 대목을 직접 인용해 구체 사례와 해결 과정을 요구했고, 가장 약한 축(구체적 행동·상황)을 정확히 파고들었다. 다만 정량적 결과나 이후 달라진 점은 명시적으로 요구하지 않았다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "정량적 결과·이후 변화 축까지는 끌어내지 못함"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "'크게 싸운 적 없다'는 표현을 근거로 DONT_KNOW로 본 것은 과한 분류이며(모름 요청이 아닌 추상적 답변), 가정 상황으로 유도해 실제 경험 검증력이 떨어진다.", "relevance": 3, "depth": 3, "language": 4, "overall": 3, "issue": "의도 오분류 후 가상 상황으로 유도해 경험 검증력 약화"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "충돌 내용·대화 과정·결과 변화까지 STAR 축을 고르게 요구해 변별력이 있으나, 두 문장에 걸친 나열식으로 길고 '구체적'이 반복돼 간결성이 떨어진다.", "relevance": 4, "depth": 4, "language": 3, "overall": 4, "issue": "질문이 길고 요구 항목 나열로 산만함"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "사례·대화 내용·팀 성과와 분위기 변화까지 물어 결과 축을 잘 커버했다. 다만 답변의 특정 표현 인용이 약하고 문장이 다소 길다.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "답변 인용이 약하고 문장이 길어 간결성 아쉬움"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "'소통을 중시했다'를 짚은 점은 좋지만, '어떤 말로 시작했는지' 같은 대화 기법 세부로 좁혀져 결과·행동의 임팩트 검증이 빠졌다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "대화 첫마디 등 사소한 디테일로 초점이 좁아짐"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "의도는 맞으나 '어떤 대화 내용이나 행동이 실제 결과에 영향을 준다고 말씀해 주실 수 있나요'는 문장 호응이 깨져 무엇을 묻는지 모호하다.", "relevance": 3, "depth": 3, "language": 2, "overall": 2, "issue": "비문으로 질문 의도가 불명확해 그대로 노출하기 어려움"}}, "positions": {"q-gemma4-e4b-Q8_0": 0, "q-gemma4-e4b-Q3_K_M": 1, "q-qwen3-4b-Instruct-2507-Q4_K_M": 2, "q-qwen3-4b-Instruct-2507-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q3_K_M": 4, "q-qwen3-4b-Instruct-2507-Q5_K_M": 5}, "ordering": 0, "output_chars": {"q-gemma4-e4b-Q8_0": 106, "q-gemma4-e4b-Q3_K_M": 115, "q-qwen3-4b-Instruct-2507-Q4_K_M": 131, "q-qwen3-4b-Instruct-2507-Q8_0": 115, "q-qwen3-4b-Instruct-2507-Q3_K_M": 119, "q-qwen3-4b-Instruct-2507-Q5_K_M": 95}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-personality-rambling", "ratings": {"q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "답변의 '소통' 대목을 짚어 구체 사례를 요구한 점은 적절하나, '어떤 대화 내용이나 행동이 실제 결과에 영향을 준다고'라는 문장 구조가 어색하고 질문 초점이 흐릿하다. 정량적 결과·변화 축을 명확히 겨냥하지 못했다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "문장이 어색하고 요구 포인트(구체 행동/결과)가 모호함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "소통 중시 발언을 인용한 점은 좋으나 '어떤 말로 시작했는지' 같은 대화 기법 세부로 좁혀져 STAR의 결과·변화 축을 놓쳤다. 문장도 길고 절이 많아 늘어진다.", "relevance": 3, "depth": 2, "language": 3, "overall": 2, "issue": "대화 첫마디 같은 사소한 초점으로 변별력 저하"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "구체 사례, 실제 대화 내용, 그리고 팀 성과·분위기 변화까지 STAR의 A와 R을 균형 있게 파고들었다. 다소 길지만 자연스럽고 면접 변별력이 있다.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "정량적 결과를 명시적으로 요구하지 않고 문장이 다소 김"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "충돌 상황·대화·결과 변화를 순서대로 요구해 STAR 전 축을 커버하지만, 두 문장에 항목 나열이 많아 한 문장 간결성 기준에서 감점된다.", "relevance": 4, "depth": 4, "language": 3, "overall": 4, "issue": "질문이 장황하게 나열되어 간결성 부족"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "지원자는 원론적 답변을 했을 뿐 '모른다'고 하지 않았는데 DONT_KNOW로 오분류했고, 가정 상황을 전제하면서 과거 행동('시도하셨는지')을 묻는 모순이 있다. 가상 시나리오로 도피시켜 실제 경험 검증력이 떨어진다.", "relevance": 2, "depth": 2, "language": 4, "overall": 2, "issue": "의도 오분류 및 가정형 전환으로 실경험 검증 실패"}, "q-gemma4-e4b-Q8_0": {"rationale": "'서로 대화를 많이 하는 것'이라는 답변 원문을 직접 인용해 구체 사례와 문제 해결 연결을 요구한 점이 날카롭다. 결과의 정량화까지는 유도하지 못했지만 간결하고 자연스럽다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "정량적 성과 축을 명시적으로 묻지 않음"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 0, "q-qwen3-4b-Instruct-2507-Q3_K_M": 1, "q-qwen3-4b-Instruct-2507-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q4_K_M": 3, "q-gemma4-e4b-Q3_K_M": 4, "q-gemma4-e4b-Q8_0": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 95, "q-qwen3-4b-Instruct-2507-Q3_K_M": 119, "q-qwen3-4b-Instruct-2507-Q8_0": 115, "q-qwen3-4b-Instruct-2507-Q4_K_M": 131, "q-gemma4-e4b-Q3_K_M": 115, "q-gemma4-e4b-Q8_0": 106}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-personality-rambling", "ratings": {"q-gemma4-e4b-Q3_K_M": {"rationale": "지원자가 갈등 경험을 회피한 점을 짚은 것은 좋지만, 실제 경험 대신 가정 상황을 요구해 행동면접의 변별력이 떨어집니다. 문장도 '가정하고... 시도하셨는지'가 다소 어색합니다.", "relevance": 3, "depth": 2, "language": 3, "overall": 2, "issue": "실제 STAR 경험이 아니라 가정 답변으로 흐르게 함"}, "q-gemma4-e4b-Q8_0": {"rationale": "'서로 대화를 많이 한다'는 모호한 표현을 구체화하도록 잘 되짚었습니다. 다만 정량적 결과나 이후 변화까지 명확히 요구하지는 않아 깊이는 조금 부족합니다.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "결과와 변화에 대한 요구가 다소 약함"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "소통이라는 추상 답변을 실제 사례, 충돌 내용, 대화 과정, 결과 변화로 풀어내게 해 기대 신호와 잘 맞습니다. 약간 길지만 실제 면접에서 그대로 쓰기 좋습니다.", "relevance": 5, "depth": 5, "language": 4, "overall": 5, "issue": "문장이 다소 길고 정량 결과 요구는 명시적이지 않음"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "구체 사례와 대화 내용, 성과나 분위기 변화를 묻고 있어 답변의 약점을 잘 보완합니다. 다만 어떤 의견이 충돌했는지와 본인의 행동을 직접 묻는 힘은 C보다 약합니다.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "갈등의 원인과 본인 행동을 충분히 특정하지 않음"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "구체적 행동과 결과의 연결을 요구하려는 의도는 있으나 문장이 어색하고 질문이 모호합니다. '영향을 준다고 말씀해'라는 표현 때문에 자연성이 떨어집니다.", "relevance": 3, "depth": 3, "language": 2, "overall": 3, "issue": "표현이 어색하고 무엇을 답해야 하는지 불명확함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자의 '소통' 주장에 맞춰 구체적 대화 방식을 묻는 점은 관련성이 있습니다. 그러나 특정 말투나 기법에 치우쳐 갈등 상황, 결과, 변화 등 STAR 핵심을 충분히 파고들지 못합니다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "소통 기법에 치우쳐 결과와 변화 검증이 약함"}}, "positions": {"q-gemma4-e4b-Q3_K_M": 0, "q-gemma4-e4b-Q8_0": 1, "q-qwen3-4b-Instruct-2507-Q4_K_M": 2, "q-qwen3-4b-Instruct-2507-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q5_K_M": 4, "q-qwen3-4b-Instruct-2507-Q3_K_M": 5}, "ordering": 0, "output_chars": {"q-gemma4-e4b-Q3_K_M": 115, "q-gemma4-e4b-Q8_0": 106, "q-qwen3-4b-Instruct-2507-Q4_K_M": 131, "q-qwen3-4b-Instruct-2507-Q8_0": 115, "q-qwen3-4b-Instruct-2507-Q5_K_M": 95, "q-qwen3-4b-Instruct-2507-Q3_K_M": 119}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-personality-rambling", "ratings": {"q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자의 '소통이 중요하다'는 대목을 짚고 구체 행동을 요구한 점은 적절합니다. 다만 실제 갈등 상황, 결과, 이후 변화까지는 파고들지 못하고 대화 기법에 치우쳤습니다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "구체 사례와 결과 검증 없이 대화 방식만 묻는다"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "구체 사례와 행동이 결과에 미친 영향을 묻는 방향은 맞습니다. 그러나 문장이 다소 어색하고, 어떤 갈등이었는지나 정량적 결과·변화까지 구조적으로 끌어내지는 못합니다.", "relevance": 4, "depth": 3, "language": 2, "overall": 3, "issue": "질문 표현이 어색하고 검증 축이 불명확하다"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자의 추상적인 '소통' 답변을 구체 사례, 대화 내용, 성과·분위기 변화로 확장해 묻는 점이 좋습니다. 다만 정량적 결과나 본인의 구체적 역할을 더 직접적으로 요구하면 더 좋겠습니다.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "본인 행동과 정량 결과 요구가 다소 약하다"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "구체적인 의견 충돌, 당시 대화, 결과적 변화까지 물어 STAR의 핵심을 잘 보완합니다. 질문이 다소 길지만 실제 면접 꼬리질문으로 충분히 사용할 수 있습니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "질문이 길고 정량적 결과 요구는 빠져 있다"}, "q-gemma4-e4b-Q8_0": {"rationale": "구체적인 갈등 상황을 요구하고 '대화를 많이 했다'가 어떻게 해결로 이어졌는지 파고드는 점이 적절합니다. 다만 결과의 수준, 수치, 이후 달라진 점까지 확인하는 깊이는 부족합니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "해결 결과와 사후 변화 검증이 부족하다"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "지원자가 완전히 모른다고 답한 것은 아닌데 DONT_KNOW로 분류했고, 실제 경험 대신 가정 상황을 유도해 원 질문의 의도를 흐립니다. '가정'과 '구체적인 예'가 섞여 질문도 다소 부자연스럽습니다.", "relevance": 2, "depth": 2, "language": 3, "overall": 2, "issue": "답변 의도 분류가 부정확하고 경험 검증 대신 가정을 묻는다"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 0, "q-qwen3-4b-Instruct-2507-Q5_K_M": 1, "q-qwen3-4b-Instruct-2507-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q4_K_M": 3, "q-gemma4-e4b-Q8_0": 4, "q-gemma4-e4b-Q3_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 119, "q-qwen3-4b-Instruct-2507-Q5_K_M": 95, "q-qwen3-4b-Instruct-2507-Q8_0": 115, "q-qwen3-4b-Instruct-2507-Q4_K_M": 131, "q-gemma4-e4b-Q8_0": 106, "q-gemma4-e4b-Q3_K_M": 115}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-personality-star", "ratings": {"q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "인성/경험 면접임에도 API 엔드포인트 개수나 명세서 페이지 수 등 지엽적이고 무의미한 수치를 묻고 있어 변별력이 없습니다.", "relevance": 2, "depth": 1, "language": 3, "overall": 1, "issue": "지엽적이고 무의미한 수치 질문"}, "q-gemma4-e4b-Q8_0": {"rationale": "지원자가 언급한 감정적 충돌 상황을 잘 짚었으며, 갈등 해결 과정에서의 구체적인 행동(경청/수용)을 파고들어 인성 면접의 목적에 매우 부합합니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "없음"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "인성/경험 면접에서 Mock 서버의 응답 시간이라는 전혀 맥락에 맞지 않는 기술적 수치를 묻고 있어 부적절합니다.", "relevance": 1, "depth": 1, "language": 3, "overall": 1, "issue": "맥락에 맞지 않는 기술적 수치 질문"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "Mock 서버의 응답 시간을 밀리초 단위로 묻는 등 인성 면접의 의도와 전혀 맞지 않는 사소한 질문을 던집니다.", "relevance": 1, "depth": 1, "language": 3, "overall": 1, "issue": "무의미하고 사소한 수치 질문"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "감정이 상했던 상황을 짚고, 이를 해소하기 위한 구체적인 대화나 행동을 물어보아 갈등 해결 능력을 평가하기에 적절합니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "없음"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "협의가 몇 시간 이내에 이루어졌는지 묻는 등 인위적이고 사소한 수치에 집착하여 면접 질문으로 부자연스럽습니다.", "relevance": 2, "depth": 1, "language": 3, "overall": 1, "issue": "사소한 수치(시간)에 집착하는 질문"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 0, "q-gemma4-e4b-Q8_0": 1, "q-qwen3-4b-Instruct-2507-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q5_K_M": 3, "q-gemma4-e4b-Q3_K_M": 4, "q-qwen3-4b-Instruct-2507-Q4_K_M": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 153, "q-gemma4-e4b-Q8_0": 100, "q-qwen3-4b-Instruct-2507-Q8_0": 156, "q-qwen3-4b-Instruct-2507-Q5_K_M": 126, "q-gemma4-e4b-Q3_K_M": 112, "q-qwen3-4b-Instruct-2507-Q4_K_M": 107}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-personality-star", "ratings": {"q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "협의가 몇 시간 이내에 이루어졌는지 묻는 것은 인성 면접의 본질을 벗어난 억지스러운 수치 요구입니다.", "relevance": 2, "depth": 1, "language": 3, "overall": 1, "issue": "무의미하고 억지스러운 정량적 수치 요구"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "지원자가 언급한 '감정적 충돌'에 초점을 맞춰, 이를 해소하기 위한 구체적인 행동과 대화 과정을 적절하게 파고들었습니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "없음"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "인성/행동 면접에서 Mock 서버의 응답 시간을 밀리초 단위로 묻는 것은 질문의 의도와 완전히 어긋납니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "면접 맥락에 맞지 않는 사소한 기술적 수치 요구"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "갈등 해결 경험을 묻는 맥락에서 Mock 서버의 응답 시간을 묻는 것은 부적절하며 변별력이 없습니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "면접 맥락에 맞지 않는 사소한 기술적 수치 요구"}, "q-gemma4-e4b-Q8_0": {"rationale": "자신의 방식을 고집해 감정이 상했던 상황에서 상대방의 의견을 어떻게 수용했는지 물어보아 인성 면접의 목적에 매우 부합합니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "없음"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "API 엔드포인트 개수나 명세서의 페이지 수를 묻는 것은 지원자의 역량을 평가하는 데 아무런 도움이 되지 않는 무의미한 질문입니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "무의미하고 사소한 정량적 수치 요구"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 0, "q-gemma4-e4b-Q3_K_M": 1, "q-qwen3-4b-Instruct-2507-Q5_K_M": 2, "q-qwen3-4b-Instruct-2507-Q8_0": 3, "q-gemma4-e4b-Q8_0": 4, "q-qwen3-4b-Instruct-2507-Q3_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 107, "q-gemma4-e4b-Q3_K_M": 112, "q-qwen3-4b-Instruct-2507-Q5_K_M": 126, "q-qwen3-4b-Instruct-2507-Q8_0": 156, "q-gemma4-e4b-Q8_0": 100, "q-qwen3-4b-Instruct-2507-Q3_K_M": 153}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-personality-star", "ratings": {"q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "답변의 기술 조치를 언급하긴 하나, 인성(BEHAVIORAL) 모드에서 엔드포인트 개수·명세 페이지 수 같은 무의미한 계량을 묻는다. 문장도 '알려주신다면?'으로 끝나 미완성 느낌.", "relevance": 2, "depth": 1, "language": 2, "overall": 1, "issue": "인성 질문인데 명세 페이지 수 등 사소한 수치를 물어 변별력이 없음"}, "q-gemma4-e4b-Q8_0": {"rationale": "지원자가 스스로 밝힌 '방식만 고집해 감정이 상했다'는 가장 약한 축을 정확히 파고들어 갈등 해소 행동을 요구한다. 다만 지원자 발화를 그대로 인용해 '제 방식'이라 표현한 점과 다소 긴 문장이 아쉽다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "'제 방식'이라는 인용 표현이 면접관 발화로는 어색"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "Mock 서버 응답 시간은 인성 면접 맥락에서도, 통합 이슈 해소 맥락에서도 핵심이 아니다. 질문 길이도 과도하게 길다.", "relevance": 2, "depth": 1, "language": 3, "overall": 1, "issue": "Mock 서버 응답 시간이라는 무관·사소한 지표로 초점이 이탈"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "협의가 '몇 시간 이내'였는지는 의미 없는 수치이며, 절차 질문과 시간 질문이 뒤섞여 초점이 흐리다.", "relevance": 2, "depth": 2, "language": 3, "overall": 2, "issue": "'몇 시간 이내 협의'라는 무의미한 정량 요구"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "밀리초 단위 Mock 서버 응답 시간은 갈등 해결 역량과 전혀 무관한 질문으로, 인성 면접 흐름을 깨뜨린다.", "relevance": 1, "depth": 1, "language": 3, "overall": 1, "issue": "인성 면접에서 밀리초 수치를 묻는 완전한 초점 이탈"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "감정 충돌 해소를 위한 구체적 대화·행동을 물어 STAR의 Action 공백을 정확히 공략한다. 인용식 '제 방식' 표현과 다소 긴 문장만 흠.", "relevance": 5, "depth": 5, "language": 4, "overall": 5, "issue": "지원자 발화 인용으로 '제 방식'이 되어 주어가 혼동될 수 있음"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 0, "q-gemma4-e4b-Q8_0": 1, "q-qwen3-4b-Instruct-2507-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q4_K_M": 3, "q-qwen3-4b-Instruct-2507-Q5_K_M": 4, "q-gemma4-e4b-Q3_K_M": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 153, "q-gemma4-e4b-Q8_0": 100, "q-qwen3-4b-Instruct-2507-Q8_0": 156, "q-qwen3-4b-Instruct-2507-Q4_K_M": 107, "q-qwen3-4b-Instruct-2507-Q5_K_M": 126, "q-gemma4-e4b-Q3_K_M": 112}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-personality-star", "ratings": {"q-gemma4-e4b-Q3_K_M": {"rationale": "답변에서 가장 약한 축인 '감정 충돌 해소를 위한 본인의 구체 행동'을 정확히 짚어 PERSONALITY/BEHAVIORAL 모드에 적합하다. 문장이 다소 길지만 자연스럽고 변별력이 있다.", "relevance": 5, "depth": 5, "language": 4, "overall": 5, "issue": "문장이 60자를 다소 넘어 길다"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "인성 면접 맥락에서 Mock 서버 응답 시간(ms)을 묻는 것은 무의미하고 답변 의도와 완전히 어긋난다. 사소한 수치 캐묻기의 전형.", "relevance": 2, "depth": 1, "language": 4, "overall": 1, "issue": "인성 질문에 무관한 사소한 성능 수치를 요구"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "절차를 묻는 앞부분은 일부 유효하나 '협의가 몇 시간 이내였는지'는 무의미한 수치 강요이며 갈등 해결의 본질을 비껴간다.", "relevance": 3, "depth": 2, "language": 3, "overall": 2, "issue": "'몇 시간 이내' 같은 무의미한 정량화 요구"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "프론트 개발 속도 영향으로 연결한 점은 B보다 낫지만, 여전히 Mock 서버 응답 시간이라는 핵심과 무관한 수치를 전제로 하고 문장도 장황하다.", "relevance": 3, "depth": 2, "language": 3, "overall": 2, "issue": "응답 시간이라는 부적절한 지표에 초점, 문장 과다 장문"}, "q-gemma4-e4b-Q8_0": {"rationale": "감정 충돌과 경청·수용 행동을 파고들어 기대 신호의 약한 축을 정확히 겨냥했다. A와 유사하나 '어떻게 수용/경청했는지'로 초점이 명확하고 간결하다.", "relevance": 5, "depth": 4, "language": 5, "overall": 5, "issue": "A와 유사한 방향으로 차별점은 크지 않음"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "엔드포인트 개수, 명세 페이지 수 등 변별력 없는 사소한 수치를 나열해 묻고 문장이 어색하게 끝난다. 인성 면접 목적과 동떨어진다.", "relevance": 2, "depth": 1, "language": 2, "overall": 1, "issue": "명세 페이지 수 등 무의미한 질문과 미완결 어투"}}, "positions": {"q-gemma4-e4b-Q3_K_M": 0, "q-qwen3-4b-Instruct-2507-Q5_K_M": 1, "q-qwen3-4b-Instruct-2507-Q4_K_M": 2, "q-qwen3-4b-Instruct-2507-Q8_0": 3, "q-gemma4-e4b-Q8_0": 4, "q-qwen3-4b-Instruct-2507-Q3_K_M": 5}, "ordering": 1, "output_chars": {"q-gemma4-e4b-Q3_K_M": 112, "q-qwen3-4b-Instruct-2507-Q5_K_M": 126, "q-qwen3-4b-Instruct-2507-Q4_K_M": 107, "q-qwen3-4b-Instruct-2507-Q8_0": 156, "q-gemma4-e4b-Q8_0": 100, "q-qwen3-4b-Instruct-2507-Q3_K_M": 153}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-personality-star", "ratings": {"q-gemma4-e4b-Q8_0": {"rationale": "지원자 답변의 ‘제 방식만 고집해 감정이 상했다’는 대목을 정확히 짚고, 갈등 상황에서의 경청과 수용 행동을 확인한다. 다만 이미 이후 변화로 일부 답한 내용을 다시 묻는 느낌이 있어 변별력은 E보다 약간 낮다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "갈등 해소 행동보다 경청 여부에 다소 일반적으로 머문다"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "OpenAPI와 Mock 서버라는 구체 대목을 짚었지만, 행동면접에서 중요한 갈등 해결보다 기술 절차와 협의 시간에 초점이 쏠린다. ‘몇 시간 이내’는 근거 없는 제약이라 답변 품질을 떨어뜨린다.", "relevance": 3, "depth": 2, "language": 4, "overall": 3, "issue": "임의적인 시간 기준을 묻고 갈등 해결의 핵심을 충분히 파고들지 못한다"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "Mock 서버를 언급한 점은 답변과 연결되지만, 응답 시간은 이 behavioral 질문의 기대 신호와 거의 무관하다. 개발 속도 영향도 이미 통합 이슈 감소로 일부 제시되어 있어 추가 변별력이 낮다.", "relevance": 2, "depth": 2, "language": 4, "overall": 2, "issue": "인성면접 맥락에서 중요하지 않은 Mock 서버 성능으로 질문이 새고 있다"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "OpenAPI와 Mock 서버 조치를 짚긴 했지만, API 엔드포인트 수나 명세 페이지 수는 갈등 해결 역량을 평가하는 데 사소하다. 문장도 ‘알려주신다면?’으로 끝나 어색하고 질문 완결성이 낮다.", "relevance": 2, "depth": 1, "language": 2, "overall": 2, "issue": "기술 산출물의 양적 세부사항에 치우쳐 행동면접 변별력이 낮다"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "감정적 충돌이라는 답변의 약한 축을 정확히 짚고, 실제 대화나 행동을 요구해 STAR의 행동 부분을 보완하게 한다. 갈등 해결 역량을 직접 검증하는 좋은 꼬리질문이다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "큰 문제 없음"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "Mock 서버 언급과 표면적으로만 연결될 뿐, 응답 시간이 몇 밀리초였는지는 갈등 해결 경험 평가와 무관하다. 지나치게 기술 성능 질문으로 변질되어 실제 서비스에 부적합하다.", "relevance": 2, "depth": 1, "language": 4, "overall": 1, "issue": "행동면접 질문에서 무의미한 성능 수치를 묻는다"}}, "positions": {"q-gemma4-e4b-Q8_0": 0, "q-qwen3-4b-Instruct-2507-Q4_K_M": 1, "q-qwen3-4b-Instruct-2507-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q3_K_M": 3, "q-gemma4-e4b-Q3_K_M": 4, "q-qwen3-4b-Instruct-2507-Q5_K_M": 5}, "ordering": 0, "output_chars": {"q-gemma4-e4b-Q8_0": 100, "q-qwen3-4b-Instruct-2507-Q4_K_M": 107, "q-qwen3-4b-Instruct-2507-Q8_0": 156, "q-qwen3-4b-Instruct-2507-Q3_K_M": 153, "q-gemma4-e4b-Q3_K_M": 112, "q-qwen3-4b-Instruct-2507-Q5_K_M": 126}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-personality-star", "ratings": {"q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "지원자 답변의 OpenAPI·Mock 서버 대목을 짚기는 했지만, Mock 서버 응답 시간은 행동면접 맥락과 충돌 해결 역량 검증에 거의 관련이 없습니다. 사소한 기술 수치로 흘러 변별력이 낮습니다.", "relevance": 2, "depth": 1, "language": 4, "overall": 2, "issue": "행동면접에서 중요하지 않은 Mock 서버 응답 시간에 집착함"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "지원자가 약점으로 언급한 ‘제 방식만 고집해 감정이 상했다’는 부분을 정확히 짚고, 실제 갈등 해소 행동을 묻습니다. STAR 중 행동과 변화의 진정성을 검증하기에 적절합니다.", "relevance": 5, "depth": 5, "language": 4, "overall": 5, "issue": "문장이 다소 길지만 큰 문제는 없음"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "OpenAPI와 Mock 서버라는 특정 대목은 짚었지만, 엔드포인트 수나 명세 페이지 수는 충돌 해결 경험의 핵심과 거리가 있습니다. 질문도 장황하고 끝맺음이 어색합니다.", "relevance": 3, "depth": 2, "language": 2, "overall": 2, "issue": "기술 산출물의 양적 정보에 치우쳐 행동 역량 검증이 약함"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "Mock 서버와 프론트 개발 속도 영향이라는 구체 대목을 묻지만, 응답 시간은 갈등 해결 맥락에서 부차적입니다. 결과 영향까지 묻는 점은 일부 유효하나 행동면접 꼬리질문으로는 초점이 흐립니다.", "relevance": 3, "depth": 2, "language": 4, "overall": 3, "issue": "기술 성능 지표에 초점이 쏠려 갈등 해결 역량 검증이 약함"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "OpenAPI·Mock 서버 절차와 협의 과정을 묻는 점은 일부 관련이 있으나, ‘몇 시간 이내’라는 제한은 근거 없고 부자연스럽습니다. 갈등 해결의 핵심 행동이나 관계 회복을 충분히 파고들지 못합니다.", "relevance": 3, "depth": 2, "language": 3, "overall": 2, "issue": "임의의 시간 기준을 붙여 질문의 타당성이 떨어짐"}, "q-gemma4-e4b-Q8_0": {"rationale": "지원자가 인정한 고집과 감정 충돌을 바탕으로, 반대 의견을 어떻게 수용·경청했는지 묻는 적절한 후속 질문입니다. 다만 감정적 충돌을 실제로 어떻게 해소했는지까지는 B보다 약간 덜 직접적입니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "갈등 해소 결과보다 경청 방식에만 초점이 조금 좁음"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 0, "q-gemma4-e4b-Q3_K_M": 1, "q-qwen3-4b-Instruct-2507-Q3_K_M": 2, "q-qwen3-4b-Instruct-2507-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q4_K_M": 4, "q-gemma4-e4b-Q8_0": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 126, "q-gemma4-e4b-Q3_K_M": 112, "q-qwen3-4b-Instruct-2507-Q3_K_M": 153, "q-qwen3-4b-Instruct-2507-Q8_0": 156, "q-qwen3-4b-Instruct-2507-Q4_K_M": 107, "q-gemma4-e4b-Q8_0": 100}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-strong-backend", "ratings": {"q-gemma4-e4b-Q3_K_M": {"rationale": "지원자가 언급한 이벤트 유실 상황의 구체적인 장애 포인트를 파고들어 분산 환경에 대한 이해도를 확인하는 좋은 질문입니다. 다만 문장이 다소 깁니다.", "relevance": 4, "depth": 4, "language": 3, "overall": 4, "issue": "질문이 다소 길고 장황함"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자의 답변을 바탕으로 질문했으나, 채점 기준에 명시된 대로 키의 형식이나 조합을 묻는 것은 사소하고 변별력이 낮습니다.", "relevance": 3, "depth": 1, "language": 4, "overall": 2, "issue": "사소하고 뻔한 질문(키의 형식)으로 변별력 부족"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자가 이미 유니크 제약을 통해 기존 주문을 반환한다고 명확히 답했음에도, 불필요하게 SQL 조건이나 구체적 로직을 다시 묻고 있어 깊이가 얕습니다.", "relevance": 3, "depth": 2, "language": 4, "overall": 2, "issue": "이미 답변한 해결 방식에 대해 불필요한 SQL 조건을 요구함"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "지원자가 'PG사가 타임아웃 후 재전송하면서'라고 실패 케이스를 이미 구체적으로 설명했는데 이를 그대로 다시 묻고 있습니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "지원자가 이미 설명한 시나리오를 반복해서 질문함"}, "q-gemma4-e4b-Q8_0": {"rationale": "지원자가 '주문은 저장됐는데 이벤트가 안 나가는 경우'라고 Outbox가 막는 실패 케이스를 이미 설명했음에도 다시 묻고 있습니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "지원자가 이미 설명한 실패 케이스를 반복해서 질문함"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자가 '기존 주문을 그대로 돌려주도록 했습니다'라고 처리 방식을 이미 밝혔는데, 어떻게 처리했는지 다시 묻고 있습니다.", "relevance": 1, "depth": 1, "language": 4, "overall": 1, "issue": "지원자가 이미 답변한 처리 로직을 반복해서 질문함"}}, "positions": {"q-gemma4-e4b-Q3_K_M": 0, "q-qwen3-4b-Instruct-2507-Q8_0": 1, "q-qwen3-4b-Instruct-2507-Q3_K_M": 2, "q-qwen3-4b-Instruct-2507-Q5_K_M": 3, "q-gemma4-e4b-Q8_0": 4, "q-qwen3-4b-Instruct-2507-Q4_K_M": 5}, "ordering": 0, "output_chars": {"q-gemma4-e4b-Q3_K_M": 159, "q-qwen3-4b-Instruct-2507-Q8_0": 150, "q-qwen3-4b-Instruct-2507-Q3_K_M": 129, "q-qwen3-4b-Instruct-2507-Q5_K_M": 115, "q-gemma4-e4b-Q8_0": 124, "q-qwen3-4b-Instruct-2507-Q4_K_M": 105}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-strong-backend", "ratings": {"q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자가 이미 '기존 주문을 그대로 돌려주도록 했다'고 답변했음에도, 키가 존재할 때의 처리 방식을 다시 묻고 있어 변별력이 없습니다.", "relevance": 2, "depth": 1, "language": 4, "overall": 2, "issue": "이미 답변한 내용(기존 주문 반환)을 중복 질문함"}, "q-gemma4-e4b-Q8_0": {"rationale": "지원자가 이미 '주문은 저장됐는데 이벤트가 안 나가는 경우'라고 Outbox의 도입 배경을 설명했음에도 실패 케이스를 다시 묻고 있습니다.", "relevance": 2, "depth": 1, "language": 3, "overall": 2, "issue": "이미 답변한 내용(이벤트 미발행)을 중복 질문함"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "지원자가 'PG사 타임아웃 후 재전송'이라는 구체적인 상황을 이미 언급했음에도 동일한 시나리오를 다시 묻고 있어 깊이가 없습니다.", "relevance": 2, "depth": 1, "language": 4, "overall": 2, "issue": "이미 답변한 내용(타임아웃 후 재전송)을 중복 질문함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "유니크 제약 조건 발생 시의 예외 처리 등 구체적인 구현 로직을 묻는 점은 유효하나, 질문 문장이 다소 장황하고 반복적입니다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "질문이 다소 장황하고 핵심을 예리하게 찌르지 못함"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "채점 기준에서 명시적으로 피하라고 지시한 '키의 형식이나 생성 방식' 등 사소한 부분을 묻고 있어 면접 질문으로서 부적절합니다.", "relevance": 2, "depth": 1, "language": 3, "overall": 1, "issue": "지시사항을 어기고 사소한 질문(키의 형식)을 함"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "DB 커밋과 이벤트 발행 사이의 장애(Dual-write 문제)가 발생하는 구체적인 원인과 시나리오를 파고들어 지원자의 실제 경험을 검증하기 좋습니다.", "relevance": 5, "depth": 4, "language": 3, "overall": 4, "issue": "질문 길이가 권장 기준(60자)을 초과하여 다소 긺"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 0, "q-gemma4-e4b-Q8_0": 1, "q-qwen3-4b-Instruct-2507-Q5_K_M": 2, "q-qwen3-4b-Instruct-2507-Q3_K_M": 3, "q-qwen3-4b-Instruct-2507-Q8_0": 4, "q-gemma4-e4b-Q3_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 105, "q-gemma4-e4b-Q8_0": 124, "q-qwen3-4b-Instruct-2507-Q5_K_M": 115, "q-qwen3-4b-Instruct-2507-Q3_K_M": 129, "q-qwen3-4b-Instruct-2507-Q8_0": 150, "q-gemma4-e4b-Q3_K_M": 159}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-strong-backend", "ratings": {"q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "'기존 주문을 그대로 돌려준다'는 대목을 정확히 짚고 구현 로직을 요구해 동시 요청 경합·유니크 위반 처리 같은 변별점으로 이어질 여지가 있다. 다만 경합 상황을 명시하지 않아 SQL 세부 확인에 머물 위험이 있고 문장이 다소 길다.", "relevance": 4, "depth": 4, "language": 3, "overall": 4, "issue": "동시성·경합을 명시하지 않아 단순 구현 확인으로 끝날 수 있음"}, "q-gemma4-e4b-Q8_0": {"rationale": "지원자가 이미 '주문은 저장됐는데 이벤트가 안 나가는 경우'라고 Outbox의 방지 케이스를 설명했는데 그것을 그대로 다시 묻는다. 새 정보를 끌어내지 못한다.", "relevance": 3, "depth": 2, "language": 4, "overall": 2, "issue": "이미 답변된 내용을 반복 질문"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "'PG 타임아웃 후 재전송으로 같은 승인이 두 번 온다'고 이미 구체적으로 답한 부분을 되묻는 중복 질문이다. 기대 신호 중 약한 축(중복 발행·소비자 멱등성 등)을 전혀 파고들지 않는다.", "relevance": 2, "depth": 2, "language": 4, "overall": 2, "issue": "답변에 이미 나온 시나리오를 그대로 재질문"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "지원자 문장을 인용해 커밋 후 발행 실패 시점을 구체화하라는 점은 자연스럽지만, 이 역시 답변에서 이미 언급된 동기라 추가 변별력이 제한적이다. 문장이 길고 수식어가 많다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "이미 설명된 도입 동기를 재확인하는 수준"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "멱등 키의 형식·생성 방식을 묻는 것은 기준상 사소한 질문이며, 예시로 든 '승인 시간 스탬프' 조합은 멱등성을 오히려 깨는 잘못된 유도다.", "relevance": 2, "depth": 1, "language": 3, "overall": 1, "issue": "키 형식이라는 사소한 주제 + 멱등성을 해치는 잘못된 예시 유도"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "지원자는 두 번째 요청을 '거절'이 아니라 기존 주문을 반환했다고 했는데 질문이 거절로 오독했고, 처리 방식도 이미 답변에 나와 있다.", "relevance": 2, "depth": 2, "language": 4, "overall": 2, "issue": "답변 내용을 오독(거절)하고 이미 나온 처리를 재질문"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 0, "q-gemma4-e4b-Q8_0": 1, "q-qwen3-4b-Instruct-2507-Q5_K_M": 2, "q-gemma4-e4b-Q3_K_M": 3, "q-qwen3-4b-Instruct-2507-Q8_0": 4, "q-qwen3-4b-Instruct-2507-Q4_K_M": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 129, "q-gemma4-e4b-Q8_0": 124, "q-qwen3-4b-Instruct-2507-Q5_K_M": 115, "q-gemma4-e4b-Q3_K_M": 159, "q-qwen3-4b-Instruct-2507-Q8_0": 150, "q-qwen3-4b-Instruct-2507-Q4_K_M": 105}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-strong-backend", "ratings": {"q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "유니크 제약 충돌 시 처리 로직을 물어 동시 요청 레이스 컨디션으로 연결될 여지가 있고 문장이 간결하다. 다만 '기존 주문을 그대로 돌려줬다'는 답변 내용과 상당 부분 겹쳐 새로운 변별력은 제한적이다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "이미 답한 내용의 구현 확인 수준이어서 놓친 축(릴레이 중복 발행·소비자 멱등성)을 파지 못함"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "멱등 키의 형식·생성 방식을 묻는 전형적인 사소한 질문이며, 예시로 든 '승인 시간 스탬프' 조합은 멱등성을 오히려 깨뜨리는 잘못된 유도다. 문장도 길고 늘어진다.", "relevance": 3, "depth": 1, "language": 3, "overall": 2, "issue": "키 형식이라는 뻔한 지점을 묻고 잘못된 예시를 제시해 변별력이 없음"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "답변 문구를 직접 인용해 관련성은 있으나, 지원자가 이미 설명한 'DB 커밋 후 발행 실패' 케이스를 되묻는 셈이라 반복성이 크다. 문장이 길고 조건절이 중첩돼 읽기 불편하다.", "relevance": 4, "depth": 2, "language": 3, "overall": 2, "issue": "지원자가 이미 설명한 Outbox 도입 이유를 다시 묻는 중복 질문"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "PG 타임아웃 재전송 시나리오는 지원자가 답변 앞부분에 그대로 말한 내용으로, 사실상 같은 질문을 되돌려준다. 압박이나 검증 효과가 거의 없다.", "relevance": 3, "depth": 1, "language": 4, "overall": 2, "issue": "직전 답변을 그대로 되묻는 반복 질문으로 정보 획득이 없음"}, "q-gemma4-e4b-Q8_0": {"rationale": "두 패턴의 역할을 대비시키는 구조는 자연스럽지만, Outbox가 막는 실패 케이스는 지원자가 이미 트랜잭션 경계까지 언급해 설명한 부분이다. '더 구체적으로'라는 요구만 남아 새로운 축을 열지 못한다.", "relevance": 4, "depth": 2, "language": 4, "overall": 2, "issue": "이미 답변된 Outbox 실패 케이스를 재요청해 대화가 제자리에 머묾"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "두 번째 요청의 실제 처리 경로와 SQL 조건을 물어 구현 진위 검증에는 쓸모가 있고, 유니크 위반 예외 처리로 확장될 여지도 있다. 다만 질문이 길고 답변에 이미 있는 결론을 재확인하는 성격이 강하다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "구현 세부 확인에 머물러 동시성·중복 발행 같은 더 약한 축을 건드리지 못함"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 0, "q-qwen3-4b-Instruct-2507-Q8_0": 1, "q-gemma4-e4b-Q3_K_M": 2, "q-qwen3-4b-Instruct-2507-Q5_K_M": 3, "q-gemma4-e4b-Q8_0": 4, "q-qwen3-4b-Instruct-2507-Q3_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q4_K_M": 105, "q-qwen3-4b-Instruct-2507-Q8_0": 150, "q-gemma4-e4b-Q3_K_M": 159, "q-qwen3-4b-Instruct-2507-Q5_K_M": 115, "q-gemma4-e4b-Q8_0": 124, "q-qwen3-4b-Instruct-2507-Q3_K_M": 129}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-strong-backend", "ratings": {"q-gemma4-e4b-Q3_K_M": {"rationale": "지원자 답변의 '주문 저장과 Kafka 발행이 한 트랜잭션이 아니어서'라는 핵심 대목을 정확히 짚고, DB 커밋 이후 발행 실패라는 트랜잭션 경계 실패를 구체화하게 한다. 이미 답한 내용을 단순 반복하지 않고 Outbox 도입 이유의 실제 장애 시나리오를 검증한다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "문장이 다소 길지만 면접 변별력은 충분하다."}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "PG사 재전송과 멱등 키라는 답변 대목을 짚기는 했지만, 지원자가 이미 타임아웃 후 재전송과 중복 콜백 사례를 설명했다. 새롭게 검증하는 축이 약해 반복 질문에 가깝다.", "relevance": 4, "depth": 2, "language": 5, "overall": 3, "issue": "이미 답한 멱등 키 실패 케이스를 다시 묻는다."}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "결제 키 유니크 제약과 두 번째 요청 처리 로직을 묻는 점은 관련성이 있다. 다만 지원자가 이미 '기존 주문을 그대로 돌려준다'고 답했기 때문에 구현 세부 확인 이상의 깊이는 부족하다.", "relevance": 4, "depth": 2, "language": 5, "overall": 3, "issue": "기존 답변을 크게 확장하지 못하는 구현 확인 질문이다."}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "두 번째 요청 처리 방식과 SQL 조건을 물어 멱등 처리의 원자성, 유니크 제약 충돌 처리, 조회 반환 로직까지 확인할 수 있다. 지원자 답변의 특정 표현을 짚으면서도 구현상의 실패 가능성을 더 파고든다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "질문이 조금 길고 SQL로 범위를 좁히는 면이 있다."}, "q-gemma4-e4b-Q8_0": {"rationale": "멱등 키와 Outbox가 막는 실패 케이스를 구분하도록 유도하며, Outbox의 구체적 장애 시나리오를 추가로 확인한다. 지원자가 이미 개괄 설명은 했지만, 더 구체화를 요구한다는 점에서 유효하다.", "relevance": 5, "depth": 4, "language": 5, "overall": 4, "issue": "Outbox가 막는 실패 종류는 이미 일부 답변되어 있어 약간 반복된다."}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "결제 키 유니크 제약을 언급한 점은 관련이 있지만, 키의 형식이나 생성 방식은 핵심 기대 신호인 멱등성과 트랜잭션 경계 검증에서 벗어난다. 특히 승인 시간 스탬프 조합 예시는 오히려 멱등 키 설계의 본질을 흐릴 수 있다.", "relevance": 3, "depth": 1, "language": 4, "overall": 2, "issue": "사소한 키 형식 질문으로 면접 변별력이 낮다."}}, "positions": {"q-gemma4-e4b-Q3_K_M": 0, "q-qwen3-4b-Instruct-2507-Q5_K_M": 1, "q-qwen3-4b-Instruct-2507-Q4_K_M": 2, "q-qwen3-4b-Instruct-2507-Q3_K_M": 3, "q-gemma4-e4b-Q8_0": 4, "q-qwen3-4b-Instruct-2507-Q8_0": 5}, "ordering": 0, "output_chars": {"q-gemma4-e4b-Q3_K_M": 159, "q-qwen3-4b-Instruct-2507-Q5_K_M": 115, "q-qwen3-4b-Instruct-2507-Q4_K_M": 105, "q-qwen3-4b-Instruct-2507-Q3_K_M": 129, "q-gemma4-e4b-Q8_0": 124, "q-qwen3-4b-Instruct-2507-Q8_0": 150}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-strong-backend", "ratings": {"q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "결제 키 유니크 제약이라는 특정 대목을 짚은 점은 좋습니다. 다만 키 형식·생성 방식은 멱등성과 트랜잭션 경계 검증의 핵심에서 벗어나며, 예시도 다소 사소합니다.", "relevance": 4, "depth": 2, "language": 3, "overall": 2, "issue": "핵심 실패 케이스보다 키 형식이라는 주변부를 묻고 있습니다."}, "q-gemma4-e4b-Q8_0": {"rationale": "멱등 키와 Outbox의 역할 구분이라는 주제에는 맞지만, 지원자가 이미 주문 저장 후 이벤트 미발행 케이스를 설명했습니다. 추가 변별력 있는 후속 질문이라기보다 재설명을 요구하는 성격이 강합니다.", "relevance": 4, "depth": 2, "language": 4, "overall": 3, "issue": "이미 답한 내용을 다시 묻는 중복 질문입니다."}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "두 번째 콜백을 기존 주문으로 돌려주는 로직이라는 구체 대목을 잘 짚었습니다. SQL 조건이나 처리 흐름을 물어 동시성·유니크 제약 활용 여부를 더 검증할 수 있습니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "좋은 질문이나 Outbox 쪽 실패 케이스 검증은 다루지 않습니다."}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "결제 키 존재 시 처리 로직을 묻는 점은 관련성이 있습니다. 그러나 지원자가 이미 기존 주문을 돌려준다고 말했기 때문에 C보다 덜 구체적이고, '거절'이라는 표현도 답변 내용과 약간 어긋납니다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "질문이 다소 일반적이고 이미 답한 내용을 반복합니다."}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "PG 타임아웃 후 재전송이라는 구체 사례를 짚었지만, 이는 지원자가 이미 명확히 설명한 내용입니다. 새로운 검증 포인트나 약한 축을 파고들지 못합니다.", "relevance": 3, "depth": 1, "language": 4, "overall": 2, "issue": "직전 답변을 거의 그대로 다시 설명하라고 묻고 있습니다."}, "q-gemma4-e4b-Q3_K_M": {"rationale": "주문 저장과 Kafka 발행의 트랜잭션 경계라는 핵심 대목을 정확히 짚었습니다. DB 커밋 후 발행 시 장애 같은 구체 시나리오를 요구해 Outbox 도입 이유를 더 깊게 검증할 수 있습니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "좋은 질문이나 릴레이 중복 발행·컨슈머 멱등성까지는 확장하지 않습니다."}}, "positions": {"q-qwen3-4b-Instruct-2507-Q8_0": 0, "q-gemma4-e4b-Q8_0": 1, "q-qwen3-4b-Instruct-2507-Q3_K_M": 2, "q-qwen3-4b-Instruct-2507-Q4_K_M": 3, "q-qwen3-4b-Instruct-2507-Q5_K_M": 4, "q-gemma4-e4b-Q3_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q8_0": 150, "q-gemma4-e4b-Q8_0": 124, "q-qwen3-4b-Instruct-2507-Q3_K_M": 129, "q-qwen3-4b-Instruct-2507-Q4_K_M": 105, "q-qwen3-4b-Instruct-2507-Q5_K_M": 115, "q-gemma4-e4b-Q3_K_M": 159}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-stt-messy-normal", "ratings": {"q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자의 수치 언급을 잘 짚었으나, 기술적인 트레이드오프나 해결 과정보다는 단순 측정 방법에 집중하여 면접 변별력이 다소 떨어집니다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "기술적 깊이보다는 단순 측정 지표에 집중함"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "분산 락 적용 후에도 남은 3건의 불일치 원인을 묻는 것은 트랜잭션 커밋 시점과 락 해제 시점의 불일치 등 분산 락의 엣지 케이스를 파고드는 매우 훌륭한 시니어급 질문입니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "없음"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "질문의 의도는 좋으나 '얼마나 하던지'와 같은 어색한 한국어 표현이 포함되어 있어 서비스에 그대로 노출하기 어렵습니다.", "relevance": 4, "depth": 4, "language": 2, "overall": 2, "issue": "어색한 문법 ('얼마나 하던지')"}, "q-gemma4-e4b-Q8_0": {"rationale": "낙관적 락을 선택했던 초기 설계 당시의 예상치와 실제 충돌률을 비교하게 하여, 지원자의 트레이드오프 분석 능력을 잘 검증할 수 있는 좋은 질문입니다.", "relevance": 5, "depth": 4, "language": 5, "overall": 4, "issue": "없음"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "데이터 정합성 지표(불일치 건수)와 성능 지표(DB 부하)를 인과관계처럼 묶어서 질문하여 논리적 연결이 다소 어색합니다.", "relevance": 4, "depth": 3, "language": 4, "overall": 3, "issue": "서로 다른 두 지표(정합성, 부하)를 어색하게 연결함"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "'말씀이 맞는가요?'라는 불필요하고 어색한 확인성 멘트가 포함되어 있으며, 질문하는 시점(그때)이 모호합니다.", "relevance": 3, "depth": 2, "language": 2, "overall": 2, "issue": "어색한 화법 및 모호한 시점 지칭"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 0, "q-gemma4-e4b-Q3_K_M": 1, "q-qwen3-4b-Instruct-2507-Q4_K_M": 2, "q-gemma4-e4b-Q8_0": 3, "q-qwen3-4b-Instruct-2507-Q8_0": 4, "q-qwen3-4b-Instruct-2507-Q5_K_M": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 132, "q-gemma4-e4b-Q3_K_M": 103, "q-qwen3-4b-Instruct-2507-Q4_K_M": 146, "q-gemma4-e4b-Q8_0": 107, "q-qwen3-4b-Instruct-2507-Q8_0": 115, "q-qwen3-4b-Instruct-2507-Q5_K_M": 98}, "n_candidates": 6} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-stt-messy-normal", "ratings": {"q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "지원자의 답변을 잘 짚었으나, '말씀이 맞는가요?'와 같이 불필요한 확인성 질문이 포함되어 다소 어색합니다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "불필요한 확인성 질문 및 두 문장 구성"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "지원자가 언급한 수치를 바탕으로 DB 부하 감소 정도를 구체적으로 물어보아 적절한 깊이를 가집니다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "무난하나 C나 E에 비해 날카로움이 다소 부족함"}, "q-gemma4-e4b-Q8_0": {"rationale": "낙관적 락 설계 당시의 예상치와 실제 충돌률을 비교하게 하여, 기술 선택의 근거와 트레이드오프를 깊이 있게 파고듭니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "없음"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "질문의 의도는 좋으나 '얼마나 하던지'와 같은 어색한 표현이 있고 문장이 지나치게 깁니다.", "relevance": 4, "depth": 4, "language": 2, "overall": 2, "issue": "어색한 문법('얼마나 하던지') 및 장황한 문장"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "분산 락 적용 후에도 여전히 남은 3건의 불일치 원인을 파고들어, 지원자의 트러블슈팅 깊이를 확인할 수 있는 훌륭한 질문입니다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "없음"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "측정 기준을 묻는 것은 나쁘지 않으나, 핵심적인 기술 트레이드오프보다는 지엽적인 부분에 집중되었고 문장이 다소 깁니다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "다소 지엽적인 질문 방향 및 장황한 문장"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 0, "q-qwen3-4b-Instruct-2507-Q8_0": 1, "q-gemma4-e4b-Q8_0": 2, "q-qwen3-4b-Instruct-2507-Q4_K_M": 3, "q-gemma4-e4b-Q3_K_M": 4, "q-qwen3-4b-Instruct-2507-Q3_K_M": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q5_K_M": 98, "q-qwen3-4b-Instruct-2507-Q8_0": 115, "q-gemma4-e4b-Q8_0": 107, "q-qwen3-4b-Instruct-2507-Q4_K_M": 146, "q-gemma4-e4b-Q3_K_M": 103, "q-qwen3-4b-Instruct-2507-Q3_K_M": 132}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-stt-messy-normal", "ratings": {"q-gemma4-e4b-Q8_0": {"rationale": "지원자의 '버전 충돌이 많아 재시도가 계속 돌았다'는 대목을 정확히 인용하고, 예상 동시 요청량 대비 실제 충돌률을 물어 낙관적 락 포기 판단의 근거를 정량으로 검증한다. 기대 신호인 충돌 빈도 축을 정면으로 파고들며 문장도 자연스럽다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "분산 락 전환 후의 비용(처리량 저하·락 실패) 축은 건드리지 못함"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "수치 인용은 했으나 '얼마나 하던지' 같은 비문이 있고 질문이 두 갈래로 늘어져 장황하다. 내용상 충돌 빈도-재시도 비용 연결은 적절하지만 지원자가 이미 언급한 인과를 되묻는 느낌도 있다.", "relevance": 3, "depth": 3, "language": 2, "overall": 2, "issue": "한국어 비문과 중언부언으로 질문 초점이 흐려짐"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "'3건으로 줄었다'는 수치를 짚으면서 남은 불일치의 원인 분석을 요구해, 분산 락의 한계(락 타임아웃·예외 경로·TTL 등) 이해까지 자연스럽게 검증한다. 간결하고 한국어도 매끄럽다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "충돌 빈도 정량화 축은 우회적으로만 확인됨"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "측정 시점·기준과 이전 충돌 빈도 측정 방법을 함께 묻는 방향은 타당하나, 두 질문이 겹쳐 문장이 길고 '사용하던 시점의' 등 표현이 어색하다. 측정 방법론에 치우쳐 락 방식 트레이드오프 변별력은 상대적으로 약하다.", "relevance": 4, "depth": 3, "language": 3, "overall": 3, "issue": "한 문장에 두 질문을 얹어 장황하고 초점이 분산됨"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "이미 명확히 말한 수치를 '맞는가요?'로 재확인하는 군더더기가 있고 표현이 어색하다. 다만 재시도 빈도와 락 실패율을 묻는 후반부는 기대 신호에 맞는다.", "relevance": 3, "depth": 3, "language": 2, "overall": 3, "issue": "불필요한 사실 확인과 어색한 어미로 면접관 톤이 떨어짐"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "수치를 인용해 재시도 횟수·DB 부하 감소폭을 정량으로 묻는 것은 재시도 비용 축에 부합하고 문장도 자연스럽다. 다만 지원자가 이미 'DB 부하가 커졌다'고 말한 내용의 수치화 요구에 그쳐 새 축 확장은 제한적이다.", "relevance": 4, "depth": 3, "language": 4, "overall": 4, "issue": "기존 진술의 수치 확인 수준으로 변별력이 다소 얕음"}}, "positions": {"q-gemma4-e4b-Q8_0": 0, "q-qwen3-4b-Instruct-2507-Q4_K_M": 1, "q-gemma4-e4b-Q3_K_M": 2, "q-qwen3-4b-Instruct-2507-Q3_K_M": 3, "q-qwen3-4b-Instruct-2507-Q5_K_M": 4, "q-qwen3-4b-Instruct-2507-Q8_0": 5}, "ordering": 0, "output_chars": {"q-gemma4-e4b-Q8_0": 107, "q-qwen3-4b-Instruct-2507-Q4_K_M": 146, "q-gemma4-e4b-Q3_K_M": 103, "q-qwen3-4b-Instruct-2507-Q3_K_M": 132, "q-qwen3-4b-Instruct-2507-Q5_K_M": 98, "q-qwen3-4b-Instruct-2507-Q8_0": 115}, "n_candidates": 6} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-stt-messy-normal", "ratings": {"q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "답변의 핵심 수치(월 200→3건)를 짚고 재시도·DB 부하 감소량이라는 기대 신호(재시도 비용)로 연결해 자연스럽다. 다만 지원자가 이미 언급한 'DB 부하 증가'를 되묻는 느낌이 있어 변별력은 중간 수준.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "이미 진술한 DB 부하 논지를 재확인하는 성격이 일부 있음"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "수치를 짚은 점은 좋으나 '맞는가요?'라는 불필요한 확인이 붙어 두 문장이 되고 어투가 어색하다. 락 실패율 질문 자체는 트레이드오프 탐침으로 유효.", "relevance": 3, "depth": 4, "language": 3, "overall": 3, "issue": "불필요한 사실 확인 문장으로 질문이 늘어지고 어색함"}, "q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "측정 기준·시점을 파고드는 방향은 타당하나 한 문장에 질문 3개를 욱여넣어 길고 장황하며, 낙관적 락 충돌 측정 질문이 중복된다.", "relevance": 4, "depth": 3, "language": 2, "overall": 3, "issue": "과도하게 길고 다중 질문이라 면접 발화로 부자연스러움"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "남은 3건의 원인을 물어 분산 락의 한계(TTL 만료, 락 해제 실패, 원자성)까지 자연스럽게 검증할 수 있는 고변별 질문이며 간결하고 한국어가 매끄럽다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "재시도 비용 축은 직접 다루지 않음"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "충돌 빈도→재시도 비용 연결은 기대 신호에 맞지만 '얼마나 하던지' 같은 비문이 있고 문장이 장황해 그대로 내보내기 어렵다.", "relevance": 4, "depth": 3, "language": 2, "overall": 2, "issue": "비문('얼마나 하던지')과 장황한 중복 표현"}, "q-gemma4-e4b-Q8_0": {"rationale": "지원자의 '버전 충돌이 많았다'는 주장을 인용하고 예상 동시성 대비 실제 충돌률을 물어 낙관적 락 선택 근거를 검증하는 좋은 탐침이며 간결하다.", "relevance": 4, "depth": 4, "language": 4, "overall": 4, "issue": "핵심 성과 수치(200→3건) 검증은 건드리지 않음"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q8_0": 0, "q-qwen3-4b-Instruct-2507-Q5_K_M": 1, "q-qwen3-4b-Instruct-2507-Q3_K_M": 2, "q-gemma4-e4b-Q3_K_M": 3, "q-qwen3-4b-Instruct-2507-Q4_K_M": 4, "q-gemma4-e4b-Q8_0": 5}, "ordering": 1, "output_chars": {"q-qwen3-4b-Instruct-2507-Q8_0": 115, "q-qwen3-4b-Instruct-2507-Q5_K_M": 98, "q-qwen3-4b-Instruct-2507-Q3_K_M": 132, "q-gemma4-e4b-Q3_K_M": 103, "q-qwen3-4b-Instruct-2507-Q4_K_M": 146, "q-gemma4-e4b-Q8_0": 107}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-stt-messy-normal", "ratings": {"q-qwen3-4b-Instruct-2507-Q3_K_M": {"rationale": "지원자 답변의 핵심 수치인 월 200건→3건과 충돌 빈도를 짚어 측정 기준을 확인한다. 다만 질문이 다소 길고, 분산 락 전환의 트레이드오프까지는 직접 파고들지 않는다.", "relevance": 5, "depth": 4, "language": 4, "overall": 4, "issue": "측정 기준 질문에 치우쳐 락 방식의 비용·부작용 검증이 약함"}, "q-qwen3-4b-Instruct-2507-Q8_0": {"rationale": "불일치 감소 수치를 재시도 횟수와 DB 부하 감소로 연결해, 답변의 핵심 근거를 정량적으로 검증한다. 기대 신호인 충돌 빈도와 재시도 비용 이해를 잘 파고드는 질문이다.", "relevance": 5, "depth": 5, "language": 5, "overall": 5, "issue": "분산 락 자체의 운영 비용이나 장애 시나리오까지는 묻지 않음"}, "q-gemma4-e4b-Q3_K_M": {"rationale": "지원자가 제시한 월 200건→3건 수치를 짚고, 남은 불일치의 원인을 묻는 점은 관련성이 있다. 그러나 낙관적 락의 충돌·재시도 비용과 분산 락 선택 트레이드오프 검증에서는 다소 벗어난다.", "relevance": 4, "depth": 3, "language": 5, "overall": 4, "issue": "핵심 전환 이유보다 사후 불일치 원인 분석으로 초점이 이동함"}, "q-qwen3-4b-Instruct-2507-Q5_K_M": {"rationale": "재시도 빈도와 락 실패율을 묻는 점은 동시성 제어 지표를 확인하는 질문으로 유의미하다. 하지만 '맞는가요?'라는 확인형 표현이 불필요하고, 락 실패율이 어느 시점의 지표인지 다소 모호하다.", "relevance": 4, "depth": 4, "language": 3, "overall": 3, "issue": "확인형 문장과 모호한 지표 표현 때문에 면접 질문으로 덜 매끄러움"}, "q-gemma4-e4b-Q8_0": {"rationale": "버전 충돌이 많았다는 답변을 바탕으로 예상 동시 요청량 대비 실제 충돌률을 묻는 것은 적절하다. 다만 재시도 비용이나 분산 락으로 바꾼 트레이드오프까지는 이어 묻지 못한다.", "relevance": 5, "depth": 4, "language": 5, "overall": 4, "issue": "충돌률 검증에 집중되어 재시도 비용·락 전환 비용 검증이 부족함"}, "q-qwen3-4b-Instruct-2507-Q4_K_M": {"rationale": "버전 충돌 빈도와 재시도 비용의 연결을 묻는 방향은 기대 신호와 잘 맞는다. 그러나 문장이 길고 '얼마나 하던지' 같은 어색한 표현이 있어 실제 서비스 출력으로는 품질이 떨어진다.", "relevance": 5, "depth": 4, "language": 2, "overall": 3, "issue": "문법적으로 어색하고 장황해 질문 전달력이 낮음"}}, "positions": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 0, "q-qwen3-4b-Instruct-2507-Q8_0": 1, "q-gemma4-e4b-Q3_K_M": 2, "q-qwen3-4b-Instruct-2507-Q5_K_M": 3, "q-gemma4-e4b-Q8_0": 4, "q-qwen3-4b-Instruct-2507-Q4_K_M": 5}, "ordering": 0, "output_chars": {"q-qwen3-4b-Instruct-2507-Q3_K_M": 132, "q-qwen3-4b-Instruct-2507-Q8_0": 115, "q-gemma4-e4b-Q3_K_M": 103, "q-qwen3-4b-Instruct-2507-Q5_K_M": 98, "q-gemma4-e4b-Q8_0": 107, "q-qwen3-4b-Instruct-2507-Q4_K_M": 146}, "n_candidates": 6} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-stt-messy-normal", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-weak-vague", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f-weak-vague", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-weak-vague", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f-weak-vague", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-weak-vague", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f-weak-vague", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-backend-fact-mismatch", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-backend-fact-mismatch", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-backend-fact-mismatch", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-backend-fact-mismatch", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-backend-fact-mismatch", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-backend-fact-mismatch", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-backend-isolation-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-backend-isolation-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-backend-isolation-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-backend-isolation-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-backend-isolation-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-backend-isolation-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-cl-example", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-cl-example", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-cl-example", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-cl-example", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-cl-example", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-cl-example", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-cl-repeat", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-cl-repeat", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-cl-repeat", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-cl-repeat", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-cl-repeat", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-cl-repeat", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-cl-stt-noisy", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-cl-stt-noisy", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-cl-stt-noisy", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-cl-stt-noisy", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-cl-stt-noisy", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-cl-stt-noisy", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-cl-term", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-cl-term", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-cl-term", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-cl-term", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-cl-term", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-cl-term", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-cl-which-part", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-cl-which-part", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-cl-which-part", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-cl-which-part", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-cl-which-part", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-cl-which-part", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-confirm-correction", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-confirm-correction", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-confirm-correction", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-confirm-correction", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-confirm-correction", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-confirm-correction", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-confirm-yes", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-confirm-yes", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-confirm-yes", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-confirm-yes", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-confirm-yes", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-confirm-yes", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-dba-replication-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-dba-replication-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-dba-replication-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-dba-replication-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-dba-replication-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-dba-replication-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-dba-vague-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-dba-vague-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-dba-vague-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-dba-vague-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-dba-vague-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-dba-vague-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-dk-english", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-dk-english", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-dk-english", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-dk-english", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-dk-english", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-dk-english", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-dk-forgot", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-dk-forgot", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-dk-forgot", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-dk-forgot", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-dk-forgot", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-dk-forgot", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-dk-no-experience", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-dk-no-experience", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-dk-no-experience", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-dk-no-experience", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-dk-no-experience", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-dk-no-experience", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-dk-pass", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-dk-pass", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-dk-pass", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-dk-pass", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-dk-pass", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-dk-pass", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-dk-stt-fragment", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-dk-stt-fragment", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-dk-stt-fragment", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-dk-stt-fragment", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-dk-stt-fragment", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-dk-stt-fragment", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-frontend-a11y-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-frontend-a11y-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-frontend-a11y-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-frontend-a11y-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-frontend-a11y-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-frontend-a11y-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-frontend-buzzword-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-frontend-buzzword-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-frontend-buzzword-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-frontend-buzzword-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-frontend-buzzword-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-frontend-buzzword-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-infra-fact-mismatch", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-infra-fact-mismatch", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-infra-fact-mismatch", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-infra-fact-mismatch", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-infra-fact-mismatch", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-infra-fact-mismatch", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-infra-gitops-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-infra-gitops-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-infra-gitops-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-infra-gitops-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-infra-gitops-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-infra-gitops-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-integrated-tradeoff-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-integrated-tradeoff-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-integrated-tradeoff-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-integrated-tradeoff-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-integrated-tradeoff-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-integrated-tradeoff-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-motivation-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-motivation-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-motivation-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-motivation-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-motivation-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-motivation-strong", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-offtopic-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-offtopic-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-offtopic-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-offtopic-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-offtopic-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-offtopic-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-personality-failure-star", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-personality-failure-star", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-personality-failure-star", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-personality-failure-star", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-personality-failure-star", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-personality-failure-star", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-personality-generic-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-personality-generic-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-personality-generic-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-personality-generic-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-personality-generic-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-personality-generic-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-repeat-history-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gemini-3.1-pro-preview", "suite": "followup", "case_id": "f2-repeat-history-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-repeat-history-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "claude-opus-5", "suite": "followup", "case_id": "f2-repeat-history-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-repeat-history-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} +{"judge": "gpt-5.5", "suite": "followup", "case_id": "f2-repeat-history-weak", "error": "HTTPStatusError: Client error '402 Payment Required' for url 'https://factchat-cloud.mindlogic.ai/v1/gateway/chat/completions'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402"} diff --git a/docs/research/thesis/quant/raw/q-gemma4-26b-UD-IQ2_M.jsonl b/docs/research/thesis/quant/raw/q-gemma4-26b-UD-IQ2_M.jsonl index 0c1d7b8..a105724 100644 --- a/docs/research/thesis/quant/raw/q-gemma4-26b-UD-IQ2_M.jsonl +++ b/docs/research/thesis/quant/raw/q-gemma4-26b-UD-IQ2_M.jsonl @@ -68,3 +68,73 @@ {"label": "q-gemma4-26b-UD-IQ2_M", "suite": "questions", "case_id": "q2-backend-focus-weak", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "결제 콜백 지연 문제를 해결하기 위해 멱등 키와 Transactional Outbox 패턴을 함께 사용하셨는데, Outbox 테이블을 읽어 이벤트를 발행하는 과정에서 발생할 수 있는 '중복 발행' 이슈는 어떻게 방지하셨나요?", "job_category": "BACKEND", "target_evidence": "결제 승인 콜백 지연 시 중복 주문 발생 문제: 멱등 키 테이블 + Transactional Outbox 로 해결", "expected_signal": "Outbox 패턴 구현 시 메시지 발행의 'At-least-once' 보장과 그로 인한 중복 가능성을 이해하고, 이를 Consumer 측의 멱등성 처리로 어떻게 완결했는지 논리적으로 설명해야 함"}, {"category": "TECH_CHOICE", "question": "실시간 재고 동기화 프로젝트에서 낙관적 락(Optimistic Lock) 대신 분산 락(Distributed Lock)으로 전환하셨는데, 전환을 결정하게 된 결정적인 트레이드오프 기준은 무엇이었나요?", "job_category": "BACKEND", "target_evidence": "Redis 기반 재고 캐시 + DB write-behind, 동시성 제어(낙관적 락 → 분산 락 전환)", "expected_signal": "낙관적 락의 충돌 빈도(Retry 비용)와 분산 락의 성능 오버헤드 사이의 트레이드오프를 데이터(재고 불일치 건수 감소 등)와 연결하여 논리적으로 설명해야 함"}, {"category": "CS_FUNDAMENTAL", "question": "모놀리식에서 MSA로 전환하며 Kafka를 도입하셨는데, 서비스 분리 후 데이터 정합성을 위해 '이벤트 기반 최종 정합성(Eventual Consistency)'을 선택하셨을 때 발생할 수 있는 가장 큰 리스크는 무엇이었나요?", "job_category": "BACKEND", "target_evidence": "모놀리식 → MSA 전환: 주문 서비스를 별도 서비스로 분리, DB 분리(PostgreSQL) 및 Kafka 기반 이벤트 발행/구독 구조 도입", "expected_signal": "분산 시스템에서 데이터 불일치 상태가 노출될 때의 비즈니스 영향과 이를 기술적으로(예: 보상 트랜잭션 등) 어떻게 완화할 수 있는지에 대한 이해도"}, {"category": "PROJECT_DEEP_DIVE", "question": "정산 배치 성능을 5시간에서 40분으로 단축하셨는데, QueryDSL 튜닝과 인덱스 재설계 과정에서 가장 먼저 개선했던 병목 지점은 무엇이었고, 왜 그 지점을 선택하셨나요?", "job_category": "BACKEND", "target_evidence": "정산 배치 성능 개선: 5시간 → 40분 (QueryDSL 튜닝, 청크 단위 처리, 인덱스 재설계)", "expected_signal": "단순히 '튜닝했다'가 아니라, 실행 계획(Execution Plan) 분석을 통해 IO나 CPU 병목을 식별하고, 이를 해결하기 위한 구체적인 논리적 근거를 제시해야 함"}, {"category": "BEHAVIORAL", "question": "MSA 전환과 같은 대규모 구조 변경 프로젝트를 수행하면서, 기존 모놀리식 구조에 익숙한 팀원들과 기술적 견해 차이가 있었다면 어떻게 설득하거나 조율하셨나요?", "job_category": "BACKEND", "target_evidence": "모놀리식 → MSA 전환: 주문 서비스를 별도 서비스로 분리", "expected_signal": "기술적 근거를 바탕으로 동료를 설득하는 과정(STAR)과 팀의 목표를 우선시하는 협업 태도를 보여주어야 함"}], "latency_sec": 63.438, "in_tokens": 2991, "out_tokens": 902} {"label": "q-gemma4-26b-UD-IQ2_M", "suite": "questions", "case_id": "q2-fullstack-multi", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "주문 서비스 분리 시 Kafka를 도입하셨는데, 이벤트 발행과 DB 업데이트 사이의 원자성을 어떻게 보장하셨나요?", "job_category": "BACKEND", "target_evidence": "모놀리식 -> MSA 전환: 주문 서비스를 별도 서비스로 분리, DB 분리(PostgreSQL) 및 Kafka 기반 이벤트 발행/구독 구조 도입.", "expected_signal": "Transactional Outbox 패턴을 활용하여 데이터 일관성을 유지한 구체적인 메커니즘을 설명할 수 있는가."}, {"category": "TECH_CHOICE", "question": "결제 지연 이슈를 해결할 때 멱등 키와 Outbox 패턴을 선택하셨는데, 다른 대안과 비교했을 때 이 방식의 장점은 무엇이었나요?", "job_category": "BACKEND", "target_evidence": "결제 승인 콜백 지연 시 중복 주문 발생 문제: 멱등 키 테이블 + Transactional Outbox 로 해결, 중복 주문 0건 달성", "expected_signal": "단순 구현을 넘어 기술 선택의 트레이드오프를 이해하고 비즈니스 요구사항(중복 주문 방지)에 맞춰 결정했음을 보여주는가."}, {"category": "PROJECT_DEEP_DIVE", "question": "실시간 재고 동기화 프로젝트에서 낙관적 락에서 분산 락으로 전환하셨는데, 전환을 결정하게 된 결정적인 임계점은 무엇이었나요?", "job_category": "BACKEND", "target_evidence": "Redis 기반 재고 캐시 + DB write-behind, 동시성 제어(낙관적 락 -> 분산 락 전환)", "expected_signal": "낙관적 락의 재시도 비용이나 충돌 빈도가 시스템 성능에 미치는 영향을 인지하고, 분산 락 도입의 근거를 데이터나 현상으로 설명할 수 있는가."}, {"category": "TECH_CHOICE", "question": "여행 플래너 앱에서 IndexedDB를 활용한 오프라인 편집 기능을 구현하셨는데, 온라인 복귀 시 충돌 해결을 위해 TODO로 남겨둔 CRDT 검토는 어떤 이유로 필요하다고 판단하셨나요?", "job_category": "FRONTEND", "target_evidence": "오프라인 편집: IndexedDB(Dexie) 에 낙관적 업데이트를 저장 후 온라인 복귀 시 동기화. 충돌은 last-write-wins (TODO 주석: 'CRDT 검토 필요')", "expected_signal": "Last-write-wins 방식의 데이터 유실 한계를 인지하고, 분산 환경에서의 데이터 정합성을 위한 CRDT의 필요성을 기술적으로 이해하고 있는가."}, {"category": "PROJECT_DEEP_DIVE", "question": "타임라인 항목이 2천 개 이상일 때 가상화를 도입하여 INP를 개선하셨는데, react-window 도입 후 스크롤 성능 외에 메모리 사용량 측면에서는 어떤 변화가 있었나요?", "job_category": "FRONTEND", "target_evidence": "일정 타임라인: 항목 2천 개 이상일 때 스크롤 끊김 -> react-window 가상화 도입 (커밋 메시지: 'virtualize timeline, INP 480ms -> 120ms')", "expected_signal": "DOM 노드 개수 감소가 브라우저 렌더링 성능과 메모리 효율에 미치는 영향을 연결하여 설명할 수 있는가."}, {"category": "BEHAVIORAL", "question": "정산 배치 성능을 5시간에서 40분으로 단축하는 과정에서, 팀 내에서 기술적 의견 차이가 있었다면 어떻게 설득하고 조율하셨나요?", "job_category": "BACKEND", "target_evidence": "정산 배치 성능 개선: 5시간 -> 40분 (QueryDSL 튜닝, 청크 단위 처리, 인덱스 재설계)", "expected_signal": "성능 개선이라는 목표를 달성하기 위해 동료와 협업하거나, 데이터 기반의 근거로 의사결정을 이끌어내는 STAR 방식의 경험을 보여주는가."}], "latency_sec": 70.638, "in_tokens": 3114, "out_tokens": 1009} {"label": "q-gemma4-26b-UD-IQ2_M", "suite": "questions", "case_id": "q2-coverletter-integrated", "rep": 0, "ok": true, "questions": [{"category": "TECH_CHOICE", "question": "SQLite에서 PostgreSQL로 이전할 때, 동시 쓰기 문제를 해결하기 위해 선택한 트랜잭션 격리 수준은 무엇이며 그 이유는 무엇인가요?", "job_category": "BACKEND", "target_evidence": "알림 봇 DB를 SQLite 로 시작했다가 동시 쓰기 락 문제로 알림이 중복 발송되었습니다. ... PostgreSQL 로 이전하며 트랜잭션 격리 수준을 공부하게 됐습니다.", "expected_signal": "데이터 정합성을 위해 선택한 격리 수준(Isolation Level)의 특성과 중복 발송 문제를 해결할 수 있는 기술적 근거를 설명할 수 있는가?"}, {"category": "PROJECT_DEEP_DIVE", "question": "800명이 사용하는 알림 봇의 크롤러가 멈추지 않게 하기 위해, 당시 도입했던 모니터링이나 재시도 전략이 있었나요?", "job_category": "BACKEND", "target_evidence": "새벽에 크롤러가 멈춰 공지가 누락됐을 때 동아리원들의 항의를 직접 받으며, 기능보다 '멈추지 않는 서비스'가 신뢰를 만든다는 것을 배웠습니다.", "expected_signal": "서비스의 가용성을 높이기 위해 장애를 감지하고 대응하는 구체적인 메커니즘(Retry, Monitoring 등)을 고민해 보았는가?"}, {"category": "BEHAVIORAL", "question": "API 스펙 문제로 팀원과 감정이 상했을 때, 본인의 고집을 내려놓고 대안을 비교하는 방식으로 바꾼 구체적인 과정은 무엇인가요?", "job_category": "BACKEND", "target_evidence": "초반에 제 방식이 옳다고 고집해 팀원과 감정이 상한 적도 있어, 이후에는 결정 전에 대안 두 가지를 함께 비교하는 방식으로 바꿨습니다.", "expected_signal": "자신의 커뮤니케이션 스타일을 객관적으로 성찰하고, 협업 효율을 위해 태도를 변화시킨 구체적인 행동(STAR)을 제시할 수 있는가?"}, {"category": "CS_FUNDAMENTAL", "question": "OpenAPI 명세를 활용해 Mock 서버를 구축했을 때, 프론트엔드와의 통합 이슈가 3건에서 0건으로 줄어든 기술적 이유는 무엇인가요?", "job_category": "BACKEND", "target_evidence": "저는 OpenAPI 명세를 먼저 작성하고 Mock 서버를 띄워 프론트가 병렬로 개발하도록 제안했고, 이후 스프린트에서는 통합 이슈가 3건에서 0건으로 줄었습니다.", "expected_signal": "Interface-First Design의 이점과 API 명세가 데이터 타입 및 구조의 일관성을 어떻게 보장하는지 이해하고 있는가?"}, {"category": "BEHAVIORAL", "question": "사용자 800명의 신뢰를 얻는 것이 중요하다고 말씀하셨는데, 본인이 생각하는 '신뢰할 수 있는 백엔드 개발자'의 정의는 무엇인가요?", "job_category": "BACKEND", "target_evidence": "기능보다 '멈추지 않는 서비스'가 신뢰를 만든다는 것을 배웠습니다.", "expected_signal": "기술적 완성도와 서비스 운영에 대한 본인만의 철학을 서비스의 안정성(Reliability) 관점에서 논리적으로 설명할 수 있는가?"}], "latency_sec": 57.629, "in_tokens": 2659, "out_tokens": 826} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f-strong-backend", "rep": 0, "ok": true, "followup_question": "Outbox 패턴을 위해 릴레이가 테이블을 폴링할 때, 발생할 수 있는 데이터베이스 부하 문제를 어떻게 고려하셨나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 4.0, "logic": 4.0, "structure": "PARTIAL_STAR", "correctness": null}, "latency_sec": 4.392, "ttft_sec": 0.748, "in_tokens": 1524, "out_tokens": 78} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f-weak-vague", "rep": 0, "ok": true, "followup_question": "멱등 키와 Outbox 패턴이 각각 어떤 구체적인 실패 상황(예: 네트워크 타임아웃, DB 트랜잭션 실패 등)을 방지하는지 설명해 주실 수 있나요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 6.804, "ttft_sec": null, "in_tokens": 1394, "out_tokens": 92} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f-dont-know-explicit", "rep": 0, "ok": true, "followup_question": "그럼 PostgreSQL의 트랜잭션 격리 수준과 관련하여, MVCC가 데이터 일관성을 어떻게 보장하는지 설명해 주실 수 있을까요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 7.716, "ttft_sec": null, "in_tokens": 1348, "out_tokens": 82} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f-dont-know-stt", "rep": 0, "ok": true, "followup_question": "React 18에서 도입된 automatic batching이 비동기 작업 내부의 상태 업데이트를 어떻게 처리하는지 설명해 주실 수 있을까요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 7.215, "ttft_sec": null, "in_tokens": 1347, "out_tokens": 79} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f-clarification", "rep": 0, "ok": true, "followup_question": "HPA 임계치를 70%로 설정한 기술적 근거와, 트래픽 급증에 대비해 사전에 스케일아웃을 수행한 이유를 각각 나누어 설명해 주세요.", "answer_intent": "CLARIFICATION", "answer_evaluation": null, "latency_sec": 8.403, "ttft_sec": 4.075, "in_tokens": 1383, "out_tokens": 89} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f-confirm-short", "rep": 0, "ok": true, "followup_question": "폴링 방식을 선택하셨다면, 데이터 변경 시마다 발생하는 폴링 주기에 따른 지연 시간(Latency) 문제를 어떻게 해결하셨나요?", "answer_intent": "NORMAL", "answer_evaluation": null, "latency_sec": 7.001, "ttft_sec": 3.69, "in_tokens": 1369, "out_tokens": 74} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f-infra-fact-error", "rep": 0, "ok": true, "followup_question": "이력서에는 CPU 70% 기준과 CronJob을 통한 사전 스케일아웃을 사용했다고 적혀 있는데, 메모리 50%를 기준으로 잡으신 특별한 이유가 있나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 1.0, "logic": 1.0, "structure": "NONE", "correctness": 0.0}, "latency_sec": 9.341, "ttft_sec": 5.338, "in_tokens": 1665, "out_tokens": 91} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f-dba-correct-with-context", "rep": 0, "ok": true, "followup_question": "autovacuum의 scale_factor를 0.05로 낮추면 dead tuple 관리에 유리하지만, 반대로 어떤 부작용이 발생할 수 있나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 5.0, "logic": 4.0, "structure": "FULL_STAR", "correctness": 5.0}, "latency_sec": 9.689, "ttft_sec": 5.527, "in_tokens": 1784, "out_tokens": 84} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f-frontend-strong", "rep": 0, "ok": true, "followup_question": "VariableSizeList를 사용하면서 높이 캐시를 별도로 관리하셨다고 했는데, 캐시가 만약 실제 DOM 높이와 불일치하게 될 경우 발생하는 스크롤 위치 오류는 어떻게 방지하셨나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 5.0, "logic": 4.0, "structure": "FULL_STAR", "correctness": 5.0}, "latency_sec": 10.351, "ttft_sec": 5.557, "in_tokens": 1756, "out_tokens": 96} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f-personality-star", "rep": 0, "ok": true, "followup_question": "결정 전 대안을 비교하는 방식으로 바꾼 뒤, 실제로 팀원들의 의견 수렴 과정이나 의사결정 속도 면에서 어떤 변화가 있었나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 4.0, "logic": 4.0, "structure": "FULL_STAR", "correctness": null}, "latency_sec": 7.99, "ttft_sec": 3.914, "in_tokens": 1448, "out_tokens": 82} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f-personality-rambling", "rep": 0, "ok": true, "followup_question": "구체적인 갈등 사례 없이 '대화가 중요하다'는 원론적인 말씀만 하셨는데, 실제로 의견이 부딪혔을 때 어떤 방식으로 대화를 이끌어 결론을 내셨는지 사례를 들어 말씀해 주세요.", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 1.0, "logic": 1.0, "structure": "NONE", "correctness": null}, "latency_sec": 7.104, "ttft_sec": 2.462, "in_tokens": 1389, "out_tokens": 95} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f-stt-messy-normal", "rep": 0, "ok": true, "followup_question": "재시도 비용이 커져서 분산 락을 선택하셨다면, Redis 분산 락 도입 후의 전체적인 응답 시간(Latency) 변화는 어떠했나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 3.0, "logic": 4.0, "structure": "PARTIAL_STAR", "correctness": null}, "latency_sec": 7.694, "ttft_sec": 3.839, "in_tokens": 1422, "out_tokens": 88} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f-long-answer-history", "rep": 0, "ok": true, "followup_question": "보상 흐름을 위해 도입한 스위퍼 배치가 상태를 재조회할 때, 재조회 시점의 데이터가 최신임을 어떻게 보장하나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 5.0, "logic": 4.0, "structure": "FULL_STAR", "correctness": null}, "latency_sec": 9.438, "ttft_sec": 5.476, "in_tokens": 1730, "out_tokens": 84} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f-english-mixed", "rep": 0, "ok": true, "followup_question": "staleTime을 화면별로 다르게 설정하셨다고 했는데, 그 기준을 정한 구체적인 근거는 무엇인가요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 5.0, "logic": 4.0, "structure": "PARTIAL_STAR", "correctness": null}, "latency_sec": 7.446, "ttft_sec": 3.71, "in_tokens": 1403, "out_tokens": 77} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-frontend-a11y-strong", "rep": 0, "ok": true, "followup_question": "새로 추가된 첫 게시글로 포커스를 옮길 때, 스크린리더 사용자가 기존에 읽던 맥락을 놓치지 않게 하기 위해 별도로 처리하신 부분이 있나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 5.0, "logic": 4.0, "structure": "FULL_STAR", "correctness": 5.0}, "latency_sec": 9.558, "ttft_sec": 5.011, "in_tokens": 1634, "out_tokens": 91} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-dba-replication-strong", "rep": 0, "ok": true, "followup_question": "청크 사이에 50ms의 휴식 시간을 준 것이 복제 지연 감소에 구체적으로 어떤 메커니즘으로 기여했나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 5.0, "logic": 4.0, "structure": "FULL_STAR", "correctness": 5.0}, "latency_sec": 8.773, "ttft_sec": 5.219, "in_tokens": 1689, "out_tokens": 80} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-infra-gitops-strong", "rep": 0, "ok": true, "followup_question": "Git revert를 통한 롤백이 리드타임을 30분으로 줄인 핵심 요인인가요, 아니면 다른 기술적 요소가 더 큰 비중을 차지했나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 5.0, "logic": 4.0, "structure": "PARTIAL_STAR", "correctness": 5.0}, "latency_sec": 10.287, "ttft_sec": 5.599, "in_tokens": 1728, "out_tokens": 89} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-personality-failure-star", "rep": 0, "ok": true, "followup_question": "로그를 제대로 남기지 않아 원인 파악에 3일이 걸렸다고 하셨는데, 당시 어떤 로그가 누락되어 문제 추적에 어려움을 겪으셨나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 4.0, "logic": 4.0, "structure": "PARTIAL_STAR", "correctness": 5.0}, "latency_sec": 9.576, "ttft_sec": 5.415, "in_tokens": 1734, "out_tokens": 90} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-backend-isolation-strong", "rep": 0, "ok": true, "followup_question": "조회 조건을 created_at 기준으로 고정했다면, 배치 실행 중 새로 생성된 데이터가 정산 대상에 포함되지 않도록 보장하는 메커니즘은 무엇인가요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 4.0, "logic": 4.0, "structure": "PARTIAL_STAR", "correctness": null}, "latency_sec": 7.787, "ttft_sec": 3.744, "in_tokens": 1414, "out_tokens": 87} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-integrated-tradeoff-strong", "rep": 0, "ok": true, "followup_question": "Yjs 도입 시 번들 크기 증가 외에 서버 구조 변경이 구체적으로 어떤 부분을 어떻게 바꿔야 했나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 4.0, "logic": 4.0, "structure": "PARTIAL_STAR", "correctness": 5.0}, "latency_sec": 8.945, "ttft_sec": 5.488, "in_tokens": 1734, "out_tokens": 74} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-frontend-buzzword-weak", "rep": 0, "ok": true, "followup_question": "서버 컴포넌트가 SEO에 유리하다는 점 외에, 클라이언트 번들 크기 측면에서는 구체적으로 어떤 변화가 있나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 1.0, "logic": 2.0, "structure": "NONE", "correctness": null}, "latency_sec": 6.705, "ttft_sec": 3.422, "in_tokens": 1359, "out_tokens": 78} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-dba-vague-weak", "rep": 0, "ok": true, "followup_question": "장애 방지를 위해 도입하셨다면, gh-ost의 어떤 메커니즘이 기존 방식(pt-online-schema-change 등)보다 안전하다고 판단하셨나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 1.0, "logic": 1.0, "structure": "NONE", "correctness": null}, "latency_sec": 8.696, "ttft_sec": 4.687, "in_tokens": 1578, "out_tokens": 84} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-infra-fact-mismatch", "rep": 0, "ok": true, "followup_question": "리전 이중화와 자동 페일오버를 구현하셨다면, 스토리지 풀 장애가 발생했을 때 데이터 유실 없이 전환되는 것을 어떻게 보장하셨나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 1.0, "logic": 2.0, "structure": "PARTIAL_STAR", "correctness": 4.0}, "latency_sec": 8.999, "ttft_sec": 5.112, "in_tokens": 1666, "out_tokens": 88} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-backend-fact-mismatch", "rep": 0, "ok": true, "followup_question": "이력서에는 QueryDSL과 인덱스 재설계로 5시간에서 40분으로 개선했다고 적혀 있는데, Spark를 사용해 10분으로 줄인 것은 별개의 작업인가요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 1.0, "logic": 1.0, "structure": "NONE", "correctness": 0.0}, "latency_sec": 10.185, "ttft_sec": 5.434, "in_tokens": 1785, "out_tokens": 92} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-personality-generic-weak", "rep": 0, "ok": true, "followup_question": "본인이 말씀하신 '책임감 있게 끝까지 완수했던 경험' 중 가장 기억에 남는 사례를 구체적으로 말씀해 주실 수 있나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 1.0, "logic": 1.0, "structure": "NONE", "correctness": null}, "latency_sec": 7.04, "ttft_sec": 3.328, "in_tokens": 1344, "out_tokens": 79} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-offtopic-weak", "rep": 0, "ok": true, "followup_question": "기술적 비교 대신 개인적인 학습 계획을 말씀하셨는데, RabbitMQ와 비교했을 때 Kafka가 해당 프로젝트의 요구사항(처리량, 순서 보장 등)을 더 잘 충족했던 구체적인 이유는 무엇인가요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 8.319, "ttft_sec": null, "in_tokens": 1364, "out_tokens": 98} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-dk-no-experience", "rep": 0, "ok": true, "followup_question": "PodDisruptionBudget(PDB)은 노드 드레인이나 클러스터 업그레이드 같은 자발적 중단 상황에서 Pod의 최소 가용성을 보장하기 위해 사용합니다. 이 개념을 다시 설명해 드려도 될까요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 8.71, "ttft_sec": null, "in_tokens": 1347, "out_tokens": 102} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-dk-pass", "rep": 0, "ok": true, "followup_question": "브라우저의 렌더링 과정에서 요소의 크기나 위치가 변경될 때 발생하는 리플로우와 리페인트의 차이점을 설명해 주실 수 있을까요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 7.53, "ttft_sec": null, "in_tokens": 1334, "out_tokens": 87} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-dk-forgot", "rep": 0, "ok": true, "followup_question": "그럼 RTO 40분을 달성하기 위해 복구 프로세스에서 가장 핵심적으로 관리했던 지표는 무엇이었나요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 8.318, "ttft_sec": null, "in_tokens": 1579, "out_tokens": 76} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-dk-english", "rep": 0, "ok": true, "followup_question": "CAP 정리에서 네트워크 분할(Partition)이 발생했을 때, 왜 일관성(Consistency)과 가용성(Availability)을 동시에 보장할 수 없는지 다시 한번 설명해 주실 수 있을까요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 7.991, "ttft_sec": null, "in_tokens": 1341, "out_tokens": 93} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-dk-stt-fragment", "rep": 0, "ok": true, "followup_question": "Terraform에서 workspace를 사용했을 때와 디렉터리 구조로 환경을 분리했을 때, 상태 파일(state file)이 관리되는 방식의 차이점을 설명해 주실 수 있을까요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 7.93, "ttft_sec": null, "in_tokens": 1336, "out_tokens": 91} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-cl-term", "rep": 0, "ok": true, "followup_question": "멱등성이란 동일한 요청을 여러 번 보내더라도 서버의 상태와 응답이 처음 한 번의 요청과 동일하게 유지되는 성질을 의미합니다. 결제 API에서 중복 결제를 방지하기 위해 HTTP 레벨에서 이를 어떻게 구현할 수 있을지 설명해 주세요.", "answer_intent": "CLARIFICATION", "answer_evaluation": null, "latency_sec": 9.258, "ttft_sec": 3.823, "in_tokens": 1352, "out_tokens": 106} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-cl-repeat", "rep": 0, "ok": true, "followup_question": "S3에 presigned URL을 사용하여 직접 업로드하는 과정에서, 서버의 부하를 줄이기 위해 클라이언트 측에서 이미지를 WebP로 변환했을 때 얻은 이점과 그로 인해 발생한 한계점에 대해 설명해 주세요.", "answer_intent": "CLARIFICATION", "answer_evaluation": null, "latency_sec": 8.362, "ttft_sec": 3.882, "in_tokens": 1361, "out_tokens": 98} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-cl-example", "rep": 0, "ok": true, "followup_question": "커버링 인덱스는 인덱스에 포함된 컬럼들만으로 쿼리의 모든 데이터를 충족하여 테이블 데이터 페이지에 접근하지 않고도 결과를 반환할 수 있는 상태를 말합니다. 이 개념을 바탕으로, 어떤 조건일 때 커버링 인덱스가 성능을 높일 수 있는지 예시와 함께 설명해 주실 수 있을까요?", "answer_intent": "CLARIFICATION", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 9.342, "ttft_sec": 3.555, "in_tokens": 1344, "out_tokens": 124} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-cl-which-part", "rep": 0, "ok": true, "followup_question": "소통 방식과 기술적 조치 모두에 대해 답변해 주시면 됩니다. 어떤 부분부터 말씀해 주셔도 좋습니다.", "answer_intent": "CLARIFICATION", "answer_evaluation": null, "latency_sec": 6.432, "ttft_sec": 3.622, "in_tokens": 1358, "out_tokens": 71} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-cl-stt-noisy", "rep": 0, "ok": true, "followup_question": "팀의 개발 효율을 높이기 위해 기술 부채 해결의 필요성을 동료나 상사에게 제안하고 설득했던 구체적인 사례를 말씀해 주세요.", "answer_intent": "CLARIFICATION", "answer_evaluation": null, "latency_sec": 7.025, "ttft_sec": 3.496, "in_tokens": 1345, "out_tokens": 80} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-motivation-strong", "rep": 0, "ok": true, "followup_question": "승인부터 정산까지 직접 설계하고 싶다고 하셨는데, 본인이 설계한 정산 프로세스가 기존 외부 PG에 의존하던 방식보다 어떤 기술적 우위를 가질 수 있다고 생각하시나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 4.0, "logic": 3.0, "structure": "PARTIAL_STAR", "correctness": null}, "latency_sec": 9.942, "ttft_sec": 5.537, "in_tokens": 1852, "out_tokens": 92} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-repeat-history-weak", "rep": 0, "ok": true, "followup_question": "이벤트 발행 누락은 막을 수 있지만, 중복 발행 시 소비자 측에서 중복 데이터를 처리하지 않기 위한 구체적인 메커니즘은 무엇이었나요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 7.182, "ttft_sec": null, "in_tokens": 1415, "out_tokens": 85} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-confirm-correction", "rep": 0, "ok": true, "followup_question": "환경별로 workspace를 분리할 때, 공통 모듈의 버전 관리와 환경 간의 상태(State) 격리는 어떻게 처리하셨나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 7.515, "ttft_sec": 3.718, "in_tokens": 1360, "out_tokens": 77} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "followup", "case_id": "f2-confirm-yes", "rep": 0, "ok": true, "followup_question": "카카오 로그인 시 NextAuth의 기본 Provider를 사용하면, 사용자로부터 추가적인 정보(예: 이메일, 프로필 사진 등)를 가져오는 과정에서 발생할 수 있는 보안 이슈나 권한 문제를 어떻게 관리하셨나요?", "answer_intent": "NORMAL", "answer_evaluation": null, "latency_sec": 8.0, "ttft_sec": 3.391, "in_tokens": 1349, "out_tokens": 93} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "coaching", "case_id": "c-weak-backend", "rep": 0, "ok": true, "coaching": {"model_answer": "두 기술은 서로 다른 실패 시나리오를 방어하기 위해 함께 사용했습니다.\n\n먼저 **Idempotency Key(멱등 키)**는 **'동일한 요청의 중복 처리'**를 막기 위해 사용했습니다. 결제 승인 콜백이 지연되거나 클라이언트의 재시도(Retry)로 인해 동일한 결제 요청이 여러 번 들어올 때, DB의 멱등 키 테이블을 조회하여 이미 처리된 요청이면 즉시 중복 응답을 반환하도록 설계했습니다.\n\n반면 **Transactional Outbox 패턴**은 **'데이터베이스 상태와 메시지 발행 간의 원자성(Atomicity) 결여'**를 막기 위해 도입했습니다. 주문 DB에 주문을 저장하는 트랜잭션과 Kafka로 이벤트를 발행하는 과정 사이에서, DB는 성공했지만 네트워크 오류로 메시지 발행이 실패하는 상황을 방지해야 했습니다. 이를 위해 Outbox 테이블에 이벤트를 함께 저장하고, 별도의 Relay 프로세스가 이를 읽어 Kafka로 안정적으로 발행하게 함으로써 주문 생성과 이벤트 발행의 일관성을 보장했습니다.", "answer_rewrite": "두 기술은 각각 '중복 요청'과 '데이터 불일치'라는 서로 다른 실패 케이스를 해결하기 위해 사용했습니다.\n\n* **멱등 키(Idempotency Key):** 결제 콜백 지연이나 클라이언트의 재시도로 인해 동일한 요청이 중복 전달되는 상황을 막습니다. 이미 처리된 멱등 키가 확인되면 추가 로직을 수행하지 않고 기존 결과를 반환하여 중복 주문을 방지했습니다.\n* **Transactional Outbox 패턴:** 주문 DB 업데이트와 Kafka 메시지 발행 사이의 원자성을 보장합니다. DB 트랜잭션은 성공했지만 메시지 발행 단계에서 장애가 발생해 주문 정보와 이벤트 정보가 불일치해지는 상황을 막기 위해, Outbox 테이블을 활용해 이벤트 발행의 신뢰성을 높였습니다.\n\n결과적으로 멱등 키로 중복 주문을 차단하고, Outbox 패턴으로 시스템 간 데이터 정합성을 유지하여 중복 주문 0건을 달성할 수 있었습니다.", "coaching_comment": "기술의 개념적 정의뿐만 아니라, 각 기술이 어떤 구체적인 장애 상황(Failure Case)을 방어하는지 구분하여 답변해야 합니다."}, "latency_sec": 38.894, "in_tokens": 1398, "out_tokens": 529} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "coaching", "case_id": "c-dont-know-cs", "rep": 0, "ok": true, "coaching": {"model_answer": "PostgreSQL의 MVCC 메커니즘에서 오래 열린 트랜잭션(Long-running transaction)은 **xmin horizon**을 앞당겨, Vacuum이 Dead Tuple을 정리하지 못하게 만드는 원인이 됩니다. \n\nMVCC는 각 행(Tuple)의 가시성을 판단할 때 트랜잭션 ID를 참조하는데, 가장 오래된 활성 트랜잭션의 ID가 `xmin`의 하한선이 됩니다. 만약 특정 트랜잭션이 종료되지 않고 오래 유지되면, Vacuum 프로세스는 해당 트랜잭션이 참조할 가능성이 있는 데이터들을 삭제할 수 없게 됩니다. 결과적으로 삭제된 데이터인 **Dead Tuple**이 테이블 내에 계속 쌓이게 되어 **Table Bloat** 현상이 발생하며, 이는 디스크 사용량 급증과 인덱스 스캔 성능 저하로 이어집니다.", "answer_rewrite": "현재 해당 메커니즘의 상세한 동작 방식에 대해 정확히 숙지하지 못했습니다. 하지만 PostgreSQL의 MVCC 구조상, 오래된 트랜잭션이 존재하면 Vacuum이 Dead Tuple을 회수하는 데 제약이 생겨 테이블 Bloat가 발생할 수 있다는 점은 인지하고 있습니다. 면접이 끝나면 반드시 xmin horizon과 Vacuum의 관계를 정확히 학습하여 보완하겠습니다.", "coaching_comment": "모르는 질문이 나왔을 때 바로 포기하기보다, 아는 범위 내의 키워드(MVCC, Bloat 등)를 활용해 접근하려는 태도를 보여주는 것이 중요합니다."}, "latency_sec": 23.91, "in_tokens": 931, "out_tokens": 351} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "coaching", "case_id": "c-personality-rambling", "rep": 0, "ok": true, "coaching": {"model_answer": "캡스톤 프로젝트 당시, 프론트엔드 팀원과 API 스펙 해석 차이로 인해 통합 단계에서 2주간의 지연이 발생한 적이 있습니다. 당시 저는 제 방식이 효율적이라 믿고 고집을 부리다 팀원과 감정적인 갈등을 겪기도 했습니다.\n\n이를 해결하기 위해, 단순히 제 주장을 펼치기보다 **OpenAPI 명세를 기반으로 한 Mock 서버 구축**을 제안하여 프론트엔드와 백엔드가 동시에 병렬 개발할 수 있는 환경을 만들었습니다. 결과적으로 통합 이슈를 3건에서 0건으로 줄일 수 있었습니다. 이 과정에서 갈등은 기술적 논리만으로는 부족하며, 결정 전 **'두 가지 이상의 대안을 함께 비교하는 프로세스'**를 거쳐야 팀원들의 합의를 끌어낼 수 있다는 점을 배웠습니다.", "answer_rewrite": "캡스톤 프로젝트 진행 중, API 스펙 해석 문제로 프론트엔드 팀원과 의견이 충돌하여 통합 작업이 2주간 지연된 경험이 있습니다. 당시 제 방식만을 고집하다 보니 팀원과 감정적인 갈등이 생기기도 했습니다.\n\n저는 이 문제를 해결하기 위해 먼저 **OpenAPI 명세를 작성하고 Mock 서버를 제공**하여, 서로의 해석 차이를 명확히 하고 병렬 개발이 가능하도록 환경을 개선했습니다. 그 결과, 이후 스프린트에서는 통합 이슈를 3건에서 0건으로 줄이는 성과를 거두었습니다. 이 경험을 통해 의견 충돌 시에는 제 주장만 앞세우기보다, **두 가지 이상의 대안을 객관적으로 비교하는 과정**이 팀워크와 프로젝트 효율을 모두 잡는 핵심이라는 것을 깨달았습니다.", "coaching_comment": "추상적인 '소통'이라는 단어 대신, 본인의 이력서에 있는 구체적인 갈등 상황과 기술적 해결책(OpenAPI, Mock 서버)을 STAR 구조로 답변해야 합니다."}, "latency_sec": 30.254, "in_tokens": 1266, "out_tokens": 454} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "coaching", "case_id": "c2-f-strong-backend", "rep": 0, "ok": true, "coaching": {"model_answer": "두 패턴은 **'중복 요청 처리'**와 **'데이터 일관성 보장'**이라는 서로 다른 문제를 해결하기 위해 함께 사용되었습니다.\n\n먼저 **Idempotency Key(멱등 키)**는 외부 시스템(PG사)으로부터의 **중복 요청(Duplicate Request)**을 막기 위해 사용했습니다. PG사가 타임아웃 후 재전송(Retry)을 보낼 때, 동일한 요청이 여러 번 들어와도 시스템은 단 한 번의 비즈니스 로직만 수행하고 기존 결과를 반환해야 합니다. 이를 위해 결제 키에 Unique 제약을 걸어 중복 생성을 원천 차단했습니다.\n\n반면 **Transactional Outbox 패턴**은 시스템 내부의 **분산 트랜잭션 불일치(Partial Failure)**를 막기 위해 사용했습니다. 주문 DB 저장과 Kafka 메시지 발행이 별도의 프로세스로 동작할 때, 주문은 성공했으나 메시지 발행이 실패하여 후속 서비스(재고, 배송 등)가 동작하지 않는 상황을 방지해야 합니다. 이를 위해 주문과 Outbox 이벤트를 하나의 로컬 트랜잭션으로 묶어 원자성(Atomicity)을 보장하고, Relay가 이를 안정적으로 발행하도록 설계했습니다.", "answer_rewrite": "두 패턴은 해결하고자 하는 실패 케이스가 명확히 다르기 때문에 함께 사용했습니다.\n\n첫째, **멱등 키**는 외부 API의 재전송으로 인한 **'중복 요청'** 문제를 해결합니다. PG사가 타임아웃 후 동일한 결제 건을 재전송할 때, 결제 키에 Unique 제약을 걸어 두 번째 요청부터는 기존 주문 정보를 그대로 반환하도록 처리하여 중복 주문 생성을 막았습니다.\n\n둘째, **Outbox 패턴**은 시스템 내부의 **'데이터 불일치'** 문제를 해결합니다. 주문 저장과 Kafka 발행이 별개의 트랜잭션일 때, 주문은 생성되었으나 이벤트 발행이 누락되는 상황을 방지하기 위해 도입했습니다. 주문과 이벤트를 하나의 DB 트랜잭션 내에서 Outbox 테이블에 함께 저장하고, Relay가 이를 폴링하여 발행하게 함으로써 메시지 발행의 신뢰성을 확보했습니다.\n\n결과적으로 이러한 설계를 통해 월 30건 발생하던 중복 주문 문제를 0건으로 해결할 수 있었습니다.", "coaching_comment": "각 패턴이 해결하는 문제의 정의(중복 요청 vs 데이터 불일치)를 명확히 구분하여 기술적 차이점을 설명하는 것이 핵심입니다."}, "latency_sec": 36.175, "in_tokens": 1105, "out_tokens": 572} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "coaching", "case_id": "c2-f-infra-fact-error", "rep": 0, "ok": true, "coaching": {"model_answer": "저는 EKS 환경에서 **CPU 사용률 70%**를 HPA의 주요 메트릭 기준으로 설정하여 운영했습니다. 서비스의 안정적인 리소스 확보를 위해 CPU 사용률을 모니터링하며 최적의 임계치를 결정했습니다.\n\n트래픽 피크 대응을 위해 HPA의 반응 속도에만 의존하지 않고, **사전 스케일아웃(Pre-scaling)** 방식을 병행했습니다. 예를 들어, 서비스 특성상 트래픽이 몰리는 '월급날 오전 10시'와 같은 특정 시점에는 **Kubernetes CronJob**을 활용하여 미리 파드(Pod) 수를 늘려두었습니다. 이는 HPA가 메트릭을 감지하고 새로운 파드를 생성하여 서비스에 투입되기까지 발생하는 **Provisioning Latency**로 인한 서비스 지연을 방지하기 위함이었습니다.", "answer_rewrite": "HPA 기준은 **CPU 사용률 70%**를 기준으로 설정하여 운영했습니다. 트래픽 피크 대응의 경우, HPA가 메트릭을 감지하고 스케일아웃하는 데 걸리는 시간 차이를 고려하여 **사전 스케일아웃(Pre-scaling)** 방식을 함께 사용했습니다. 구체적으로는 트래픽이 집중되는 특정 시간대에 맞춰 **CronJob**을 통해 미리 리소스를 확보함으로써, 급격한 트래픽 증가 시 발생할 수 있는 서비스 지연을 방지했습니다.", "coaching_comment": "본인의 이력서에 있는 구체적인 수치(CPU 70%)와 대응 방식(CronJob)을 활용하여 '왜 그렇게 설계했는지'에 대한 논리적 근거를 반드시 포함해야 합니다."}, "latency_sec": 26.892, "in_tokens": 1248, "out_tokens": 392} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "coaching", "case_id": "c2-f-personality-star", "rep": 0, "ok": true, "coaching": {"model_answer": "캡스톤 프로젝트 당시 프론트엔드 팀원과 API 스펙에 대한 해석 차이로 인해 통합 단계에서 2주의 지연이 발생한 적이 있습니다. [Situation & Task] 저는 백엔드 담당자로서 지연된 일정을 만회하고, 재발 방지를 위한 프로세스를 구축해야 했습니다. [Action] 우선, 모호한 API 명세가 원인임을 파악하고, OpenAPI Specification을 기반으로 명확한 문서를 작성한 뒤 Mock 서버를 구축하여 프론트엔드가 백엔드 구현과 병렬로 개발할 수 있는 환경을 제안했습니다. [Result] 그 결과, 다음 스프린트부터 통합 이슈 발생 건수를 3건에서 0건으로 줄이며 개발 효율을 높였습니다. [Learning] 이 과정에서 제 방식만 고집하기보다, 결정 전 두 가지 이상의 대안을 제시하고 팀원과 비교 검토하는 과정을 거치는 것이 협업의 핵심임을 배웠습니다.", "answer_rewrite": "캡스톤 프로젝트 중 프론트엔드 팀원과 API 스펙 해석이 달라 통합 단계에서 2주간의 일정이 지연되는 상황이 발생했습니다. [Situation & Task] 저는 지연된 일정을 복구하고 향후 동일한 문제를 방지하고자 했습니다. [Action] 먼저 OpenAPI 명세를 표준화하여 작성하고, Mock 서버를 구축해 프론트엔드 팀원이 백엔드 완성도를 기다리지 않고 병렬로 개발할 수 있도록 프로세스를 제안했습니다. [Result] 이를 통해 다음 스프린트부터는 통합 이슈가 3건에서 0건으로 감소하며 안정적인 개발 흐름을 확보했습니다. [Learning] 다만 초기에는 제 방식만 고집하여 팀원과 감정적 갈등이 있었기에, 이후에는 결정 전 두 가지 이상의 대안을 함께 비교하며 합의를 이끌어내는 소통 방식을 도입하여 협업 능력을 개선했습니다.", "coaching_comment": "문제 해결을 위한 기술적 조치(Mock 서버, OpenAPI)와 본인의 태도 변화(소통 방식 개선)를 명확히 구분하여 STAR 구조로 전달하는 것이 중요합니다."}, "latency_sec": 31.3, "in_tokens": 1031, "out_tokens": 477} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "coaching", "case_id": "c2-f-stt-messy-normal", "rep": 0, "ok": true, "coaching": {"model_answer": "타임세일과 같이 특정 시점에 트래픽이 몰리는 상황에서 **낙관적 락(Optimistic Lock)**을 사용했을 때, 버전 충돌(Version Conflict)이 빈번하게 발생했습니다. 이로 인해 애플리케이션 레벨에서의 **재시도(Retry) 로직**이 과도하게 실행되었고, 이는 오히려 DB의 CPU 부하를 높이고 응답 속도를 저하시키는 결과를 초래했습니다.\n\n따라서 충돌을 사전에 방지하기 위해 **Redis를 활용한 분산 락(Distributed Lock)**으로 전환했습니다. 분산 락을 통해 데이터 수정 전 단계에서 원자적(Atomic)으로 권한을 확보함으로써, 불필요한 재시도 비용을 줄이고 데이터 정합성을 안정적으로 유지할 수 있었습니다. 결과적으로 데이터 불일치 발생 건수를 월 200건에서 3건으로 대폭 감소시켰습니다.", "answer_rewrite": "기존에는 **낙관적 락**을 사용하여 버전 기반으로 동시성을 제어했습니다. 하지만 타임세일처럼 짧은 시간에 요청이 집중되는 상황에서는 버전 충돌이 빈번하게 발생했고, 이를 해결하기 위한 **재시도(Retry) 로직**이 반복 실행되면서 DB 부하가 급증하는 문제가 있었습니다.\n\n이를 해결하기 위해 **Redis 기반의 분산 락**으로 전환하여, 충돌이 발생한 후 재시도하는 방식이 아닌 **충돌을 사전에 차단하는 방식**으로 구조를 변경했습니다. 이를 통해 시스템 부하를 안정화했을 뿐만 아니라, 데이터 불일치 발생 건수를 월 200건에서 3건으로 줄이며 정합성을 개선했습니다.", "coaching_comment": "단순히 '많이 발생해서 바꿨다'는 현상 설명에 그치지 말고, 낙관적 락의 '재시도 비용'과 분산 락의 '사전 차단'이라는 메커니즘의 차이를 기술적으로 설명해야 합니다."}, "latency_sec": 29.835, "in_tokens": 1005, "out_tokens": 461} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "coaching", "case_id": "c2-f-english-mixed", "rep": 0, "ok": true, "coaching": {"model_answer": "클라이언트 상태(UI state)와 서버 상태(Server state)를 분리하여 관리하기 위해 TanStack Query를 선택했습니다. 기존에는 Zustand로 fetch 결과까지 관리하며 캐시 무효화(Cache Invalidation) 로직을 직접 구현했으나, 데이터의 신선도(Stale)를 관리하는 과정에서 복잡도가 높아지고 데이터 불일치 버그가 발생했습니다.\n\nTanStack Query를 도입하여 **staleTime**과 **cacheTime**을 통해 데이터의 유효 기간을 선언적으로 관리하고, **Mutation** 이후 **invalidateQueries**를 호출함으로써 서버 상태를 동기화하는 구조를 구축했습니다. 이를 통해 데이터의 신선도를 효율적으로 제어하고, 동일한 Query Key에 대한 **Request Deduplication**을 통해 불필요한 네트워크 비용을 줄일 수 있었습니다.", "answer_rewrite": "기존에는 Zustand를 사용하여 클라이언트 상태와 서버 상태를 함께 관리했습니다. 그러다 보니 캐시 무효화(Cache Invalidation) 로직을 직접 구현해야 했고, 이 과정에서 데이터의 신선도(Stale) 관리가 어려워져 데이터 불일치 버그가 발생하곤 했습니다.\n\n이를 해결하기 위해 TanStack Query로 전환하여 서버 상태 관리를 전담시켰습니다. 구체적으로는 화면별 요구사항에 맞춰 **staleTime**을 다르게 설정하여 데이터 유효성을 관리했고, **Mutation** 발생 시 **invalidateQueries**를 통해 관련 목록만 정확히 갱신하도록 설계했습니다. 결과적으로 동일한 Query Key에 대한 요청이 **Deduplication**되어 네트워크 요청을 약 40% 절감하는 효과를 얻었습니다.", "coaching_comment": "클라이언트 상태와 서버 상태를 분리해야 하는 근본적인 이유를 먼저 언급하여 기술 선택의 철학을 보여주세요."}, "latency_sec": 26.606, "in_tokens": 986, "out_tokens": 414} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "coaching", "case_id": "c2-f2-frontend-a11y-strong", "rep": 0, "ok": true, "coaching": {"model_answer": "무한 스크롤은 사용자 경험 측면에서 편리하지만, 키보드 사용자나 스크린 리더 사용자의 접근성을 저해할 수 있다는 점을 고려했습니다.\n\n**첫째, 키보드 내비게이션 문제입니다.** 스크롤이 자동으로 계속되면 사용자가 탭(Tab) 키를 이용해 푸터(Footer)나 다른 메뉴로 이동하는 것이 불가능해집니다. 이를 해결하기 위해 일정 주기마다 '더 보기' 버튼을 제공하는 하이브리드 방식을 도입하여, 사용자가 의도적으로 다음 콘텐츠를 호출할 수 있게 설계했습니다.\n\n**둘째, 스크린 리더 피드백 문제입니다.** 새로운 콘텐츠가 DOM에 추가되어도 시각 장애 사용자는 이를 인지하기 어렵습니다. 이를 위해 `aria-live=\"polite\"` 속성을 활용하여 새로운 아이템이 추가되었음을 알리고, 포커스를 새로 생성된 첫 번째 아이템으로 이동시켜 흐름이 끊기지 않도록 관리했습니다. 결과적으로 Lighthouse 접근성 점수를 72점에서 89점까지 개선할 수 있었습니다.", "answer_rewrite": "무한 스크롤 구현 시, 키보드 사용자가 콘텐츠 끝에 도달하지 못해 푸터로 이동할 수 없는 문제와 스크린 리더 사용자가 새로운 콘텐츠의 추가를 인지하지 못하는 문제를 고려했습니다.\n\n**[Situation & Task]** 기존 IntersectionObserver 방식은 스크롤에만 의존하여 키보드 내비게이션이 끊기는 문제가 있었습니다.\n**[Action]** 이를 해결하기 위해 20개 단위로 '더 보기' 버튼을 배치하는 하이브리드 방식을 도입하여 키보드 접근성을 확보했습니다. 또한, 콘텐츠가 추가될 때 `aria-live=\"polite\"`를 통해 상태를 알리고, 포커스를 새로 추가된 첫 게시글로 이동시켜 스크린 리더 사용자의 흐름을 유지했습니다.\n**[Result]** 이러한 조치로 Lighthouse 접근성 점수를 72점에서 89점까지 높일 수 있었습니다.", "coaching_comment": "문제 상황과 해결 방안을 '키보드 사용자'와 '스크린 리더 사용자'라는 두 가지 핵심 관점으로 나누어 구조적으로 답변하면 훨씬 전문적으로 보입니다."}, "latency_sec": 33.453, "in_tokens": 1214, "out_tokens": 513} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "coaching", "case_id": "c2-f2-dba-vague-weak", "rep": 0, "ok": true, "coaching": {"model_answer": "대규모 트래픽이 발생하는 환경에서 `ALTER TABLE`로 인한 서비스 중단을 방지하기 위해 `gh-ost`를 도입했습니다. 기존 `pt-online-schema-change`와 같은 트리거 기반 방식은 쓰기 부하가 높은 상황에서 트리거로 인한 추가적인 Lock 경합이나 성능 저하가 발생할 위험이 있었으나, `gh-ost`는 **Trigger-less** 방식으로 동작하여 원본 테이블에 미치는 영향을 최소화할 수 있었습니다.\n\n운영 시에는 크게 두 가지를 주의했습니다. 첫째는 **Replication Lag**입니다. 데이터 변경 사항을 복제본에 반영하는 과정에서 지연이 발생할 수 있어, `monitor-interval`과 `max-lag-multiplier` 설정을 통해 복제 지연을 실시간으로 체크하며 작업 속도를 조절했습니다. 둘째는 **Cut-over 시점의 Lock**입니다. 최종적으로 테이블을 교체하는 순간에 짧은 Lock이 발생하므로, 트래픽이 가장 낮은 시간대를 선택하거나 해당 시점의 Lock 대기 시간을 모니터링하며 안정성을 확보했습니다.", "answer_rewrite": "서비스 중단 없이 온라인 스키마 변경을 수행하기 위해 `gh-ost`를 도입했습니다. 기존 방식과 달리 트리거를 사용하지 않아 쓰기 부하가 높은 환경에서도 안정적이었으며, 실제로 컬럼 추가 시 발생할 수 있는 락 대기 장애를 0건으로 관리할 수 있었습니다.\n\n운영 시에는 두 가지 측면을 주의했습니다. 우선 **Replication Lag**을 제어하기 위해 복제 지연 정도에 따라 작업 속도를 조절하는 옵션을 활용하여 복제본의 상태를 유지했습니다. 또한, 작업 마지막 단계인 **Cut-over** 과정에서 발생하는 짧은 Lock이 서비스에 영향을 주지 않도록 모니터링하며 신중하게 진행했습니다.", "coaching_comment": "단순히 '장애가 안 나게 하려고'라는 추상적인 표현 대신, gh-ost의 핵심 특징인 'Trigger-less' 방식과 'Replication Lag/Cut-over Lock' 제어에 대한 기술적 근거를 제시해야 합니다."}, "latency_sec": 32.484, "in_tokens": 1157, "out_tokens": 489} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "coaching", "case_id": "c2-f2-backend-fact-mismatch", "rep": 0, "ok": true, "coaching": {"model_answer": "당시 정산 배치 프로세스는 약 5시간이 소요되어 운영 효율이 낮았습니다. 저는 이를 개선하기 위해 세 가지 단계로 접근했습니다.\n\n첫째, **QueryDSL 튜닝**을 통해 불필요한 Join과 Fetch를 제거하고, 데이터 추출 단계에서의 병목을 해결했습니다. 둘째, **Chunk 단위 처리** 방식을 도입하여 대량의 데이터를 한 번에 메모리에 올리지 않고 적절한 단위로 나누어 처리함으로써 Memory Out of Memory 문제를 방지했습니다. 셋째, **Index 재설계**를 통해 정산 대상 데이터를 조회하는 Query의 Scan 범위를 최적화했습니다.\n\n그 결과, 전체 배치 수행 시간을 **5시간에서 40분으로 약 87% 단축**하며 안정적인 정산 프로세스를 구축할 수 있었습니다.", "answer_rewrite": "정산 배치 프로세스가 약 5시간 정도 소요되는 병목 현상이 있어, 이를 개선하기 위해 세 가지 조치를 취했습니다.\n\n먼저 **QueryDSL 튜닝**을 통해 데이터 추출 쿼리의 효율성을 높였고, **Chunk 단위 처리** 방식을 적용하여 대량 데이터 처리 시의 메모리 부하를 관리했습니다. 마지막으로 **Index 재설계**를 통해 조회 성능을 최적화했습니다. 이러한 과정을 통해 기존 5시간 걸리던 배치를 **40분으로 단축**하는 성과를 거두었습니다.", "coaching_comment": "이력서에 적힌 실제 성과(5시간 -> 40분)와 구체적인 기술적 조치(QueryDSL, Chunk, Index)를 기반으로 답변해야 신뢰를 얻을 수 있습니다."}, "latency_sec": 27.088, "in_tokens": 1365, "out_tokens": 383} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "coaching", "case_id": "c2-f2-personality-generic-weak", "rep": 0, "ok": true, "coaching": {"model_answer": "저의 강점은 인프라 운영의 핵심인 **'장애 대응을 위한 끈질긴 분석력'**과 **'유관 부서와의 원활한 기술적 커뮤니케이션'**입니다. \n\n[Situation & Task] 과거 프로젝트(또는 업무) 당시, 예상치 못한 시스템 부하로 인해 서비스 지연이 발생했던 적이 있습니다. \n[Action] 단순히 재시작하는 것에 그치지 않고, 로그 분석과 메트릭 추적을 통해 근본 원인(Root Cause)을 끝까지 파고들어 해결책을 찾아냈습니다. \n[Result] 결과적으로 동일한 장애가 재발하지 않도록 가이드를 작성하고 자동화 스크립트를 도입하여 운영 효율을 높인 경험이 있습니다. 이러한 태도로 안정적인 인프라 환경을 구축하겠습니다.", "answer_rewrite": "저는 맡은 업무를 끝까지 완수하는 **책임감**과 기술적 이슈를 명확히 전달하는 **커뮤니케이션 역량**을 갖추고 있습니다. \n\n단순히 '열심히 한다'는 태도를 넘어, 인프라 엔지니어로서 장애 발생 시 원인을 끝까지 추적하여 해결하는 **집요함**을 보여드리겠습니다. 또한, 인프라 이슈가 발생했을 때 개발팀이나 운영팀이 상황을 정확히 이해할 수 있도록 **데이터 기반의 명확한 커뮤니케이션**을 수행하여 서비스 가용성을 지키는 데 기여하겠습니다.", "coaching_comment": "추상적인 형용사(성실, 책임감) 대신 직무와 연결된 구체적인 행동 양식과 그로 인해 얻을 수 있는 가치를 제시해야 합니다."}, "latency_sec": 25.324, "in_tokens": 927, "out_tokens": 394} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "coaching", "case_id": "c2-f2-offtopic-weak", "rep": 0, "ok": true, "coaching": {"model_answer": "두 기술 모두 메시지 브로커이지만, 이번 프로젝트의 요구사항인 **'대용량 데이터의 고처리량(High Throughput) 처리'**와 **'이벤트 로그의 영속성 기반 재처리(Replay)'** 측면에서 Kafka가 더 적합하다고 판단했습니다.\n\nRabbitMQ는 복잡한 라우팅 기능과 메시지 전달 보장에 강점이 있지만, 메시지가 소비되면 삭제되는 구조라 과거 데이터를 다시 읽기 어렵습니다. 반면, Kafka는 **Append-only Log** 구조를 사용하여 데이터를 디스크에 일정 기간 저장하므로, 장애 발생 시 특정 Offset부터 다시 읽어오는 **Replay**가 가능하고, 대량의 이벤트를 순차적으로 빠르게 처리하는 데 최적화되어 있어 Kafka를 선택했습니다.", "answer_rewrite": "질문하신 의도를 고려했을 때, 단순히 기술적 관심도를 넘어 두 브로커의 아키텍처 차이를 바탕으로 결정해야 했습니다. 제가 Kafka를 선택한 이유는 RabbitMQ의 라우팅 중심 설계보다는, **데이터의 영속성을 유지하며 대량의 스트림 데이터를 순차적으로 처리**하는 것이 이번 프로젝트의 목적에 더 부합했기 때문입니다. RabbitMQ는 메시지 전달 후 삭제되는 방식인 반면, Kafka는 로그 기반 저장 방식을 사용하여 **데이터 재처리(Replay)**가 가능하다는 점이 결정적인 차이였습니다.", "coaching_comment": "질문에 대한 기술적 비교(처리량, 저장 방식, 재처리 가능 여부) 없이 본인의 학습 계획으로 화제를 전환하는 것은 답변 회피로 간주될 수 있습니다."}, "latency_sec": 23.466, "in_tokens": 947, "out_tokens": 365} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "coaching", "case_id": "c2-f2-dk-no-experience", "rep": 0, "ok": true, "coaching": {"model_answer": "PodDisruptionBudget(PDB)은 **자발적 중단(Voluntary Disruption)** 상황에서 서비스의 가용성을 유지하기 위해 사용합니다. 예를 들어, 노드 유지보수를 위해 `kubectl drain`을 수행하거나, 클러스터 업그레이드를 위해 노드를 교체할 때, 쿠버네티스 스케줄러는 Pod를 임의로 종료할 수 있습니다. 이때 PDB를 통해 **'최소한 이만큼의 Pod는 동시에 떠 있어야 한다'**는 규칙(minAvailable)이나 **'최대 이만큼까지만 종료될 수 있다'**(maxUnavailable)는 제약을 설정함으로써, 특정 시점에 서비스가 중단되는 것을 방지하고 고가용성을 보장할 수 있습니다.", "answer_rewrite": "해당 개념을 직접 적용해 본 경험은 부족하지만, PDB는 노드 드레인(Drain)이나 클러스터 업그레이드와 같은 **자발적 중단 상황**에서 서비스 가용성을 보장하기 위한 설정으로 알고 있습니다. 특정 시점에 동시에 종료될 수 있는 Pod의 수를 제한함으로써, 인프라 작업 중에도 서비스가 최소한의 복제본(Replica)을 유지하도록 제어하는 역할을 합니다.", "coaching_comment": "모르는 질문이 나오더라도 '모른다'로 끝내지 말고, 아는 범위 내에서 개념의 정의나 목적을 유추하여 답변하는 태도가 필요합니다."}, "latency_sec": 21.256, "in_tokens": 929, "out_tokens": 328} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "coaching", "case_id": "c2-f2-integrated-tradeoff-strong", "rep": 0, "ok": true, "coaching": {"model_answer": "서비스의 핵심 사용 패턴과 기술적 비용(Trade-off)을 고려하여 결정했습니다. \n\n첫째, **충돌 발생 빈도**를 분석했을 때, 여행 일정 앱 특성상 한 명이 주도적으로 편집하고 나머지는 조회하는 패턴이 지배적이었습니다. 로그 분석 결과 월간 동시 편집 충돌이 2~3건 수준으로 매우 낮았습니다.\n\n둘째, **대안 기술과의 비용 대비 효율성**을 검토했습니다. CRDT(Yjs 등)를 도입할 경우, 번들 사이즈가 약 80KB 증가하고 서버의 동기화 로직을 완전히 재설계해야 하는 오버헤드가 발생합니다. 낮은 충돌 빈도에 비해 시스템 복잡도가 너무 높아지는 리스크가 있었습니다.\n\n따라서 **Last-write-wins**로 구현하되, 데이터 유실에 대한 사용자 불안을 해소하기 위해 **이전 버전을 7일간 보관하는 복구 메커니즘**을 함께 구축하여 안정성과 효율성 사이의 균형을 맞췄습니다.", "answer_rewrite": "서비스의 사용 패턴과 기술적 비용을 고려해 결정했습니다. \n\n**[Situation & Task]** 오프라인 편집 후 동기화 과정에서 발생하는 충돌을 어떻게 처리할지 결정해야 했습니다.\n**[Action]** 우선 로그 분석을 통해 동시 편집 충돌이 월 2~3건 정도로 매우 드물다는 점을 확인했습니다. 또한 CRDT(Yjs) 도입을 검토했으나, 번들 사이즈 80KB 증가와 서버 구조 변경에 따른 비용이 낮은 충돌 빈도에 비해 과도하다고 판단했습니다.\n**[Result]** 이에 따라 Last-write-wins 방식을 채택하되, 데이터 유실 리스크를 방지하기 위해 이전 버전을 7일간 보관하여 사용자가 직접 복구할 수 있는 안전장치를 마련했습니다.", "coaching_comment": "단순히 '비용이 높다'고 하기보다, 낮은 충돌 빈도와 기술적 복잡도 사이의 트레이드오프(Trade-off) 관점에서 논리를 전개하는 것이 좋습니다."}, "latency_sec": 33.189, "in_tokens": 1317, "out_tokens": 492} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "questions", "case_id": "q-backend-tech", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "결제 콜백 지연 문제를 해결하기 위해 도입한 Transactional Outbox 패턴의 구체적인 구현 방식과, Outbox 테이블의 데이터를 메시지 브로커로 발행할 때의 신뢰성을 어떻게 보장했나요?", "job_category": "BACKEND", "target_evidence": "결제 승인 지연으로 인한 중복 주문 발생 문제: 멱등 키 테이블 + Transactional Outbox 로 해결", "expected_signal": "Outbox 패턴의 메커니즘(DB-Message 발행 간 원자성)과 메시지 발행 누락을 방지하기 위한 Relay/Polling 전략을 설명할 수 있어야 함"}, {"category": "TECH_CHOICE", "question": "실시간 재고 동기화 프로젝트에서 낙관적 락(Optimistic Lock) 대신 분산 락(Distributed Lock)으로 전환하게 된 결정적인 기술적 배경과, Redis를 활용한 분산 락의 한계점은 무엇이었나요?", "job_category": "BACKEND", "target_evidence": "Redis 기반 재고 캐시 + DB write-behind, 동시성 제어(낙관적 락 → 분산 락 전환)", "expected_signal": "낙관적 락의 충돌 빈도 이슈와 분산 환경에서의 데이터 정합성 문제를 인지하고, Redis 분산 락의 성능/안정성 트레이드오프를 설명할 수 있어야 함"}, {"category": "PROJECT_DEEP_DIVE", "question": "모놀리식에서 MSA로 전환하며 주문 서비스를 분리할 때, DB를 PostgreSQL로 분리하면서 발생한 데이터 정합성 이슈나 서비스 간 통신(Kafka) 설계 시 가장 고려했던 점은 무엇인가요?", "job_category": "BACKEND", "target_evidence": "모놀리식 → MSA 전환: 주문 서비스를 별도 서비스로 분리, DB 분리(PostgreSQL) 및 Kafka 기반 이벤트 발행/구독 구조 도입", "expected_signal": "DB 분리로 인한 트랜잭션 범위 축소 문제와 Kafka를 통한 이벤트 기반 최종 정합성(Eventual Consistency) 설계 경험을 설명할 수 있어야 함"}, {"category": "CS_FUNDAMENTAL", "question": "정산 배치 성능을 5시간에서 40분으로 개선하셨는데, QueryDSL 튜닝과 인덱스 재설계 과정에서 데이터의 양(Volume)과 처리 방식(Chunk)이 성능에 미친 영향은 무엇이었나요?", "job_category": "BACKEND", "target_evidence": "정산 배치 성능 개선: 5시간 → 40분 (QueryDSL 튜닝, 청크 단위 처리, 인덱스 재설계)", "expected_signal": "대량 데이터 처리 시 Fetch Size, 인덱스 스캔 효율, 메모리 관리(Chunking)가 성능 최적화에 어떻게 기여하는지 기술적으로 설명할 수 있어야 함"}, {"category": "BEHAVIORAL", "question": "커머스 도메인에서 3년 동안 근무하며 대용량 트래픽과 데이터 정합성이라는 어려운 과제를 다뤄오셨는데, 본인이 생각하는 '신뢰성 있는 서버'를 만들기 위해 개발자로서 가장 중요하게 지키는 원칙은 무엇인가요?", "job_category": "BACKEND", "target_evidence": "대용량 트래픽에서도 데이터 정합성을 지키는 서버를 만드는 데 관심이 많습니다.", "expected_signal": "본인의 기술적 지향점과 실제 업무 태도를 연결하여, 정합성/안정성을 위해 어떤 검증(테스트, 모니터링 등)을 수행하는지 STAR 방식으로 답변할 수 있어야 함"}], "latency_sec": 70.831, "in_tokens": 2873, "out_tokens": 895} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "questions", "case_id": "q-frontend-repo", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "타임라인 항목 2천 개를 처리하며 INP를 480ms에서 120ms로 개선했는데, react-window 도입 시 렌더링 성능 외에 메모리 관리 측면에서 고려한 점은 무엇인가요?", "job_category": "FRONTEND", "target_evidence": "항목 2천 개 이상일 때 스크롤 끊김 -> react-window 가상화 도입 (commit: virtualize timeline, INP 480ms -> 120ms)", "expected_signal": "가상화(Virtualization)가 DOM 노드 수를 줄여 메모리 점유율과 메인 스레드 부하를 어떻게 최적화했는지 기술적 인과관계를 설명할 수 있는가"}, {"category": "TECH_CHOICE", "question": "오프라인 편집을 위해 Dexie를 선택하셨는데, TanStack Query의 캐시 데이터와 IndexedDB 간의 데이터 일관성을 어떻게 유지하셨나요?", "job_category": "FRONTEND", "target_evidence": "오프라인 편집: IndexedDB(Dexie) 에 낙관적 업데이트를 저장 후 온라인 복귀 시 동기화.", "expected_signal": "로컬 DB와 메모리 상의 서버 상태(Server State) 간의 동기화 전략 및 데이터 정합성 유지 방식을 설명할 수 있는가"}, {"category": "CS_FUNDAMENTAL", "question": "낙관적 업데이트 시 last-write-wins 방식을 사용하셨는데, 만약 사용자 간의 동시 수정으로 데이터 유실이 발생한다면 CRDT를 어떻게 적용할 수 있을까요?", "job_category": "FRONTEND", "target_evidence": "충돌은 last-write-wins (TODO 주석: \"CRDT 검토 필요\")", "expected_signal": "분산 환경에서의 데이터 충돌 해결 방식인 CRDT의 개념을 이해하고, 이를 프론트엔드 상태 동기화에 어떻게 접목할지 논리적으로 답변할 수 있는가"}, {"category": "PROJECT_DEEP_DIVE", "question": "Lighthouse 성능 점수를 68에서 91로 올리는 과정에서, 이미지 WebP 변환 외에 가장 큰 영향을 준 최적화 작업은 무엇이었나요?", "job_category": "FRONTEND", "target_evidence": "Lighthouse 성능 점수 68 -> 91 (PR #57 설명)", "expected_signal": "단순 이미지 최적화를 넘어, 번들링, 코드 분할, 혹은 렌더링 차단 리소스 제거 등 성능 지표를 개선한 구체적인 액션 아이템을 제시할 수 있는가"}, {"category": "TECH_CHOICE", "question": "Kakao Map SDK 마커 500개를 useMemo로 캐싱하셨는데, 좌표 데이터가 변경될 때 캐시 무효화(Invalidation)를 어떤 기준으로 처리하셨나요?", "job_category": "FRONTEND", "target_evidence": "지도 마커 렌더링: Kakao Map SDK 마커 500개를 클러스터링, useMemo 로 좌표 변환 캐싱", "expected_signal": "useMemo의 의존성 배열(Dependency Array) 설계와 불필요한 재계산을 방지하기 위한 데이터 구조 설계 능력을 검증할 수 있는가"}], "latency_sec": 58.081, "in_tokens": 2675, "out_tokens": 824} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "questions", "case_id": "q-infra-dba-multi", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "PostgreSQL 거래내역 테이블을 월 단위로 파티셔닝 하셨는데, 파티션 키 선정 기준과 쿼리 성능 최적화 시 고려한 점은 무엇인가요?", "job_category": "DBA", "target_evidence": "파티셔닝으로 거래내역 테이블 월 단위 분할", "expected_signal": "파티션 프루닝(Partition Pruning) 원리와 데이터 생명주기를 고려한 설계 역량"}, {"category": "TECH_CHOICE", "question": "Terraform으로 VPC와 EKS를 모듈화할 때, 환경별 workspace 분리 외에 보안이나 리소스 격리를 위해 어떤 전략을 사용하셨나요?", "job_category": "INFRA", "target_evidence": "Terraform 으로 VPC·RDS·EKS 모듈화, 환경별(dev/stg/prod) workspace 분리", "expected_signal": "IaC를 활용한 인프라 표준화 및 환경 간 격리 설계 능력"}, {"category": "PROJECT_DEEP_DIVE", "question": "RDS 스토리지 풀 장애 당시, CloudWatch 알람과 오토스케일링 적용 외에 근본적인 원인 분석은 어떻게 진행하셨나요?", "job_category": "INFRA", "target_evidence": "장애: 2024.03 RDS 스토리지 풀로 쓰기 중단 40분 → CloudWatch 알람 + 스토리지 오토스케일링 적용", "expected_signal": "장애 발생 시 원인 파악(Root Cause Analysis) 과정과 재발 방지 대책 수립 능력"}, {"category": "CS_FUNDAMENTAL", "question": "EKS 환경에서 HPA를 CPU 70%로 설정하셨는데, CPU 사용량 외에 메모리나 커스텀 메트릭을 함께 고려하지 않은 이유는 무엇인가요?", "job_category": "INFRA", "target_evidence": "HPA 기준을 CPU 70% 로 설정, 트래픽 피크(월급날 10시) 대비 사전 스케일아웃 CronJob 운영", "expected_signal": "Kubernetes 스케일링 메커니즘과 워크로드 특성에 대한 이해도"}, {"category": "BEHAVIORAL", "question": "ArgoCD 도입으로 배포 리드타임을 1일에서 30분으로 단축하셨는데, 이 과정에서 팀원들을 설득하거나 협업하며 겪은 어려움은 무엇이었나요?", "job_category": "INFRA", "target_evidence": "ArgoCD GitOps 도입으로 배포 리드타임 1일 → 30분", "expected_signal": "기술 도입 시 발생하는 변화 관리(Change Management) 및 커뮤니케이션 역량"}, {"category": "BEHAVIORAL", "question": "플랫폼 엔지니어로서 인프라 안정성과 개발 생산성 사이에서 충돌이 발생한다면, 어떤 기준으로 의사결정을 하시나요?", "job_category": "INFRA", "target_evidence": "", "expected_signal": "엔지니어로서의 우선순위 설정 기준과 비즈니스 가치에 대한 태도"}], "latency_sec": 56.239, "in_tokens": 2667, "out_tokens": 810} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "questions", "case_id": "q-personality-coverletter", "rep": 0, "ok": true, "questions": [{"category": "BEHAVIORAL", "question": "알림 봇 운영 중 발생한 항의를 경험하셨는데, 당시의 감정적 상황을 어떻게 극복하고 서비스 신뢰를 회복하기 위해 구체적으로 어떤 행동을 하셨나요?", "job_category": "BACKEND", "target_evidence": "새벽에 크롤러가 멈춰 공지가 누락됐을 때 동아리원들의 항의를 직접 받으며, 기능보다 '멈추지 않는 서비스'가 신뢰를 만든다는 것을 배웠습니다.", "expected_signal": "사용자 피드백에 대한 책임감과 문제 해결을 위한 구체적인 행동(STAR) 및 회복 탄력성"}, {"category": "BEHAVIORAL", "question": "API 스펙 문제로 팀원과 감정이 상했던 경험이 있는데, 이후 대안을 비교하는 방식으로 바꾼 뒤 팀 내 의사결정 방식은 어떻게 달라졌나요?", "job_category": "BACKEND", "target_evidence": "초반에 제 방식이 옳다고 고집해 팀원과 감정이 상한 적도 있어, 이후에는 결정 전에 대안 두 가지를 함께 비교하는 방식으로 바꿨습니다.", "expected_signal": "자신의 커뮤니케이션 스타일을 객적으로 성찰하고, 협업 프로세스를 개선할 수 있는 유연성"}, {"category": "PROJECT_DEEP_DIVE", "question": "SQLite에서 PostgreSQL로 이전할 때, 단순히 DB를 바꾼 것을 넘어 트랜잭션 격리 수준을 공부하게 된 결정적인 기술적 이유는 무엇이었나요?", "job_category": "BACKEND", "target_evidence": "알림 봇 DB를 SQLite 로 시작했다가 동시 쓰기 락 문제로 알림이 중복 발송되었습니다. ... PostgreSQL 로 이전하며 트랜잭션 격리 수준을 공부하게 됐습니다.", "expected_signal": "문제의 근본 원인(Locking/Concurrency)을 파악하고 기술적 해결책을 학습하는 과정의 논리성"}, {"category": "TECH_CHOICE", "question": "800명이 사용하는 알림 봇의 '멈추지 않는 서비스'를 위해, 크롤러의 안정성을 보장할 수 있는 모니터링이나 재시도 전략을 설계한다면 무엇을 고려하시겠습니까?", "job_category": "BACKEND", "target_evidence": "사용자 800명이 매일 쓰는 서비스를 운영해 본 경험이 있습니다. ... 기능보다 '멈추지 않는 서비스'가 신뢰를 만든다는 것을 배웠습니다.", "expected_signal": "운영 안정성을 고려한 백엔드 설계 역량 및 장애 대응에 대한 기술적 고민"}, {"category": "BEHAVIORAL", "question": "본인이 생각하는 '신뢰할 수 있는 백엔드 개발자'의 정의는 무엇이며, 이를 위해 본인이 가진 가장 큰 강점은 무엇인가요?", "job_category": "BACKEND", "target_evidence": "기능보다 '멈추지 않는 서비스'가 신뢰를 만든다는 것을 배웠습니다.", "expected_signal": "개발자로서의 직업 윤리, 가치관, 그리고 본인의 강점과 서비스 안정성 사이의 연결성"}], "latency_sec": 55.292, "in_tokens": 2658, "out_tokens": 785} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "questions", "case_id": "q-long-context-p90", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "Transactional Outbox 패턴을 적용할 때, Outbox 테이블의 이벤트를 Kafka로 발행하는 Relay 프로세스는 어떻게 구현하셨나요?", "job_category": "BACKEND", "target_evidence": "결제 승인 콜백 지연 시 중복 주문 발생 문제: 멱등 키 테이블 + Transactional Outbox 로 해결", "expected_signal": "이벤트 발행의 원자성을 보장하기 위한 구체적인 메커니즘(Polling Publisher 또는 Transaction Log Mining 등)을 설명할 수 있는가"}, {"category": "TECH_CHOICE", "question": "재고 동기화 프로젝트에서 낙관적 락에서 분산 락으로 전환하신 이유는 무엇이며, Redis를 활용한 분산 락의 한계점은 어떻게 극복하셨나요?", "job_category": "BACKEND", "target_evidence": "Redis 기반 재고 캐시 + DB write-behind, 동시성 제어(낙관적 락 → 분산 락 전환)", "expected_signal": "낙관적 락의 충돌 비용과 분산 락의 성능/정합성 트레이드오프를 이해하고 전환 근거를 제시할 수 있는가"}, {"category": "CS_FUNDAMENTAL", "question": "MSA 전환 과정에서 DB를 분리하셨는데, 주문 서비스와 다른 서비스 간의 데이터 정합성을 맞추기 위해 어떤 전략을 사용하셨나요?", "job_category": "BACKEND", "target_evidence": "모놀리식 → MSA 전환: 주문 서비스를 별도 서비스로 분리, DB 분리(PostgreSQL) 및 Kafka 기반 이벤트 발행/구독 구조 도입", "expected_signal": "분산 시스템 환경에서 Saga 패턴이나 최종 정합성(Eventual Consistency) 모델을 어떻게 적용했는지 설명할 수 있는가"}, {"category": "TECH_CHOICE", "question": "정산 배치 성능 개선 시 QueryDSL 튜닝과 인덱스 재설계를 언급하셨는데, 구체적으로 어떤 실행 계획(Execution Plan)을 보고 병목을 찾아내셨나요?", "job_category": "BACKEND", "target_evidence": "정산 배치 성능 개선: 5시간 → 40분 (QueryDSL 튜닝, 청크 단위 처리, 인덱스 재설계)", "expected_signal": "단순히 코드를 고친 것이 아니라, DB 엔진의 동작 원리와 인덱스 구조를 바탕으로 성능을 최적화했음을 증명할 수 있는가"}, {"category": "BEHAVIORAL", "question": "API 스펙 이슈로 팀원과 갈등이 있었을 때, 본인의 방식을 고집하기보다 대안을 함께 비교하는 방식으로 바꿨다고 하셨는데, 이 과정에서 얻은 가장 큰 교훈은 무엇인가요?", "job_category": "BACKEND", "target_evidence": "저는 OpenAPI 명세를 먼저 작성하고 Mock 서버를 띄워 프론트가 병렬로 개발하도록 제안했고... 이후에는 결정 전에 대안 두 가지를 함께 비교하는 방식으로 바꿨습니다.", "expected_signal": "기술적 의사결정 과정에서 커뮤니케이션 방식의 변화가 팀의 생산성에 미친 영향을 성찰적으로 답변할 수 있는가"}], "latency_sec": 64.67, "in_tokens": 4011, "out_tokens": 799} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "questions", "case_id": "q2-backend-integrated", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "결제 콜백 지연 문제를 해결하기 위해 멱등 키와 Outbox 패턴을 사용하셨는데, 두 패턴이 각각 어떤 역할을 분담했나요?", "job_category": "BACKEND", "target_evidence": "결제 승인 콜백 지연 시 중복 주문 발생 문제: 멱등 키 테이블 + Transactional Outbox 로 해결", "expected_signal": "멱등 키를 통한 중복 요청 방지와 Outbox 패턴을 통한 메시지 발행의 원자성 보장 원리를 구분하여 설명할 수 있는가"}, {"category": "TECH_CHOICE", "question": "실시간 재고 동기화 프로젝트에서 낙관적 락에서 분산 락으로 전환하셨는데, 전환을 결정하게 된 결정적인 트래픽 상황이나 기술적 한계는 무엇이었나요?", "job_category": "BACKEND", "target_evidence": "Redis 기반 재고 캐시 + DB write-behind, 동시성 제어(낙관적 락 → 분산 락 전환)", "expected_signal": "낙관적 락의 충돌 빈도 문제와 분산 락 도입 시의 Trade-off(성능 vs 정합성)를 기술적으로 설명할 수 있는가"}, {"category": "CS_FUNDAMENTAL", "question": "모놀리식에서 MSA로 전환하며 Kafka를 도입하셨는데, 이벤트 발행 시 메시지 유실을 방지하기 위해 어떤 전략을 사용하셨나요?", "job_category": "BACKEND", "target_evidence": "모놀리식 → MSA 전환: 주문 서비스를 별도 서비스로 분리, DB 분리(PostgreSQL) 및 Kafka 기반 이벤트 발행/구독 구조 도입", "expected_signal": "At-least-once delivery 보장을 위한 Producer 설정이나 Outbox 패턴과의 연계 방식을 이해하고 있는가"}, {"category": "PROJECT_DEEP_DIVE", "question": "정산 배치 성능을 5시간에서 40분으로 개선하셨는데, QueryDSL 튜닝과 인덱스 재설계 과정에서 가장 핵심적으로 건드렸던 부분은 무엇인가요?", "job_category": "BACKEND", "target_evidence": "정산 배치 성능 개선: 5시간 → 40분 (QueryDSL 튜닝, 청크 단위 처리, 인덱스 재설계)", "expected_signal": "데이터 처리량에 따른 인덱스 스캔 효율화 및 대량 데이터 처리 시의 메모리/I/O 최적화 경험을 구체적으로 설명할 수 있는가"}, {"category": "BEHAVIORAL", "question": "대용량 트래픽 환경에서 데이터 정합성을 지키는 것에 큰 관심을 두고 계신데, 본인이 개발한 시스템에서 정합성 이슈를 발견하고 해결했던 가장 도전적인 경험은 무엇인가요?", "job_category": "BACKEND", "target_evidence": "대용량 트래픽에서도 데이터 정합성을 지키는 서버를 만드는 데 관심이 많습니다.", "expected_signal": "문제 발견(Situation) - 원인 분석(Task) - 기술적 해결(Action) - 정량적 결과(Result)의 STAR 구조로 답변할 수 있는가"}], "latency_sec": 56.651, "in_tokens": 2876, "out_tokens": 792} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "questions", "case_id": "q2-backend-jd-tailored", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "결제 콜백 지연 문제를 해결하기 위해 도입한 Transactional Outbox 패턴에서, Outbox 테이블의 데이터를 Kafka로 발행하는 주체는 무엇이며 이때 발생할 수 있는 메시지 중복 발행 이슈는 어떻게 방지했나요?", "job_category": "BACKEND", "target_evidence": "결제 승인 콜백 지연 시 중복 주문 발생 문제: 멱등 키 테이블 + Transactional Outbox로 해결", "expected_signal": "Outbox 패턴의 동작 원리(Relay/Poller)를 이해하고, 메시지 발행의 원자성과 중복 방지 전략을 설명할 수 있는가"}, {"category": "TECH_CHOICE", "question": "실시간 재고 동기화 프로젝트에서 낙관적 락에서 분산 락으로 전환하며 재고 불일치 건수를 줄였는데, 분산 락 도입 시 Redis의 어떤 메커니즘을 사용했으며 전환 후 성능 측면의 트레이드오프는 무엇이었나요?", "job_category": "BACKEND", "target_evidence": "Redis 기반 재고 캐시 + DB write-behind, 동시성 제어(낙관적 락 -> 분산 락 전환)", "expected_signal": "동시성 제어 방식의 차이점을 인지하고, 분산 환경에서의 데이터 정합성과 시스템 성능 간의 균형을 고려했는지 확인"}, {"category": "CS_FUNDAMENTAL", "question": "정산 배치 성능을 5시간에서 40분으로 개선하셨는데, QueryDSL 튜닝과 인덱스 재설계 과정에서 PostgreSQL의 어떤 실행 계획(Execution Plan)을 참고하여 병목 지점을 찾아냈나요?", "job_category": "BACKEND", "target_evidence": "정산 배치 성능 개선: 5시간 -> 40분 (QueryDSL 튜닝, 청크 단위 처리, 인덱스 재설계)", "expected_signal": "RDBMS의 인덱스 구조와 쿼리 최적화 원리를 실제 성능 개선 사례에 연결하여 설명할 수 있는가"}, {"category": "PROJECT_DEEP_DIVE", "question": "모놀리식에서 MSA로 전환하며 주문 서비스를 분리할 때, 서비스 간 데이터 정합성을 보장하기 위해 Kafka를 활용한 이벤트 기반 구조에서 트랜잭션의 완결성을 어떻게 설계했나요?", "job_category": "BACKEND", "target_evidence": "모놀리식 -> MSA 전환: 주문 서비스를 별도 서비스로 분리, DB 분리(PostgreSQL) 및 Kafka 기반 이벤트 발행/구독 구조 도입", "expected_signal": "분산 시스템 환경에서 Saga 패턴이나 이와 유사한 데이터 일관성 유지 전략을 구체적으로 설명할 수 있는가"}, {"category": "BEHAVIORAL", "question": "커머스 도메인에서 3년 동안 근무하며 대용량 트래픽과 데이터 정합성이라는 어려운 과제를 해결해 오셨는데, 본인이 기술적으로 가장 몰입했던 순간은 언제이며 그 과정에서 어떤 성장을 경험했나요?", "job_category": "BACKEND", "target_evidence": "대용량 트래픽에서도 데이터 정합성을 지키는 서버를 만드는 데 관심이 많습니다.", "expected_signal": "기술적 난관을 해결하려는 자기주도적 태도와 경험을 통한 성찰(STAR)을 보여줄 수 있는가"}, {"category": "BEHAVIORAL", "question": "핀테크 산업은 높은 수준의 보안과 정합성이 요구됩니다. 이전 직장에서 정산이나 결제 로직을 다룰 때, 본인이 스스로 정한 데이터 검증 기준이나 보안 관련 원칙이 있었나요?", "job_category": "BACKEND", "target_evidence": "주문/결제 도메인 담당. 일 평균 주문 12만 건 처리", "expected_signal": "금융권 업무에 필요한 꼼꼼함과 데이터 정합성에 대한 본인만의 철학/기준을 제시할 수 있는가"}], "latency_sec": 68.412, "in_tokens": 3019, "out_tokens": 984} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "questions", "case_id": "q2-frontend-junior", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "스터디 플랫폼의 무한 스크롤 구현 시 IntersectionObserver를 사용하셨는데, 데이터 로딩 중 발생할 수 있는 중복 요청 문제를 어떻게 방지하셨나요?", "job_category": "FRONTEND", "target_evidence": "게시글 목록 무한 스크롤 (IntersectionObserver)", "expected_signal": "로딩 상태(loading state)를 활용한 중복 호출 방지 로직과 IntersectionObserver의 동작 원리에 대한 이해"}, {"category": "TECH_CHOICE", "question": "Next.js 14 App Router를 사용하셨는데, 기존 Pages Router와 비교했을 때 프로젝트에서 느낀 가장 큰 구조적 차이나 장점은 무엇이었나요?", "job_category": "FRONTEND", "target_evidence": "Next.js 14 App Router, TypeScript, Tailwind CSS", "expected_signal": "App Router의 서버 컴포넌트와 클라이언트 컴포넌트의 구분 및 데이터 페칭 전략에 대한 기술적 판단 근거"}, {"category": "CS_FUNDAMENTAL", "question": "Lighthouse 접근성 점수가 72점이었는데, 점수를 높이기 위해 구체적으로 어떤 웹 표준이나 접근성 가이드라인을 적용하셨나요?", "job_category": "FRONTEND", "target_evidence": "Lighthouse 접근성 점수 72", "expected_signal": "Semantic Markup 사용, ARIA 속성 적용, 혹은 키보드 네비게이션 등 접근성 개선을 위한 구체적인 실행 내용"}, {"category": "TECH_CHOICE", "question": "개인 블로그에서 Gatsby를 선택하셨는데, Next.js와 비교했을 때 정적 사이트 생성(SSG) 측면에서 Gatsby가 가진 이점은 무엇이었나요?", "job_category": "FRONTEND", "target_evidence": "Gatsby 로 마크다운 블로그 제작", "expected_signal": "SSG의 특징과 데이터 소스 처리 방식에 대한 이해 및 기술 선택의 이유"}, {"category": "BEHAVIORAL", "question": "팀 프로젝트 당시 무한 스크롤과 접근성 개선을 담당하셨는데, 팀원들과 기술적 의사결정을 하는 과정에서 의견 차이가 있었다면 어떻게 해결하셨나요?", "job_category": "FRONTEND", "target_evidence": "부트캠프에서 Next.js 로 팀 프로젝트를 했고, 무한 스크롤과 접근성 개선을 담당했습니다.", "expected_signal": "협업 과정에서의 커뮤니케이션 방식과 갈등을 논리적으로 해결하는 태도"}], "latency_sec": 46.969, "in_tokens": 2577, "out_tokens": 654} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "questions", "case_id": "q2-frontend-personality", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "스터디 모집 플랫폼에서 IntersectionObserver를 활용한 무한 스크롤을 구현하셨는데, 성능 최적화 측면에서 고려한 점이 있나요?", "job_category": "FRONTEND", "target_evidence": "게시글 목록 무한 스크롤 (IntersectionObserver)", "expected_signal": "DOM 요소의 생성과 메모리 관리, 혹은 스크롤 이벤트의 효율적 처리 방식에 대한 기술적 고민을 STAR 방식으로 답변"}, {"category": "TECH_CHOICE", "question": "개인 블로그는 Gatsby를, 스터디 플랫폼은 Next.js를 선택하셨는데 두 프레임워크의 차이점에 기반해 기술을 선택한 이유가 무엇인가요?", "job_category": "FRONTEND", "target_evidence": "개인 블로그 (Gatsby 로 마크다운 블로그 제작), 스터디 모집 플랫폼 (Next.js 14 App Router)", "expected_signal": "정적 사이트 생성(SSG)과 서버 사이드 렌더링(SSR/App Router)의 목적에 따른 기술 선택 근거 제시"}, {"category": "BEHAVIORAL", "question": "스터디 모집 플랫폼 프로젝트를 팀원 4명과 진행하셨는데, 협업 과정에서 의견 차이가 발생했을 때 어떻게 해결하셨나요?", "job_category": "FRONTEND", "target_evidence": "스터디 모집 플랫폼 (팀 4명, 2026.01)", "expected_signal": "갈등 상황에서 본인의 구체적인 커뮤니케이션 방식과 협업을 위한 행동(Action)을 STAR 방식으로 답변"}, {"category": "BEHAVIORAL", "question": "Lighthouse 접근성 점수 72점을 기록하셨는데, 이 점수를 올리기 위해 시도했거나 혹은 더 개선하고 싶은 구체적인 부분이 있나요?", "job_category": "FRONTEND", "target_evidence": "Lighthouse 접근성 점수 72", "expected_signal": "단순 수치 확인을 넘어 웹 표준이나 사용자 경험(UX)을 개선하려는 자기 주도적 학습 태도와 실행력"}, {"category": "BEHAVIORAL", "question": "컴퓨터공학 전공 과정과 부트캠프를 거치며 프론트엔드 개발자로 성장하기 위해 가장 몰입했던 경험은 무엇인가요?", "job_category": "FRONTEND", "target_evidence": "부트캠프 프론트엔드 과정 수료, 컴퓨터공학 학사", "expected_signal": "본인의 기술적 성장 동력과 특정 기술(React, TypeScript 등)에 깊게 파고든 경험을 구체적으로 설명"}], "latency_sec": 48.463, "in_tokens": 2557, "out_tokens": 681} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "questions", "case_id": "q2-dba-technical", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "복제 지연을 90초에서 3초로 줄이기 위해 배치 UPDATE를 1만 건 단위로 분할하셨는데, 이 청크 크기를 결정한 구체적인 기준은 무엇인가요?", "job_category": "DBA", "target_evidence": "복제 지연 최대 90초 → 3초: 대용량 배치 UPDATE 를 1만 건 단위 청크로 분할", "expected_signal": "데이터 규모와 시스템 부하(CPU, IO, Replication Lag) 사이의 트레이드오프를 고려한 수치 결정 근거"}, {"category": "TECH_CHOICE", "question": "온라인 스키마 변경을 위해 gh-ost를 도입하셨는데, pt-online-schema-change와 비교했을 때 gh-ost를 선택한 기술적 이유는 무엇인가요?", "job_category": "DBA", "target_evidence": "온라인 스키마 변경: gh-ost 도입, 컬럼 추가 시 락 대기 장애 0건", "expected_signal": "Trigger 기반 방식과 Binlog 기반 방식의 차이점 및 gh-ost의 동작 메커니즘에 대한 이해"}, {"category": "CS_FUNDAMENTAL", "question": "슬로우 쿼리 개선을 위해 커버링 인덱스를 적용하셨는데, 인덱스 스캔 시 데이터 페이지를 읽지 않고 인덱스만으로 쿼리를 처리할 수 있는 원리를 설명해주세요.", "job_category": "DBA", "target_evidence": "슬로우 쿼리: pt-query-digest 로 상위 20개 쿼리 선별, 커버링 인덱스 적용", "expected_signal": "B-Tree 인덱스 구조와 Index Only Scan의 동작 원리에 대한 정확한 개념"}, {"category": "PROJECT_DEEP_DIVE", "question": "Debezium CDC를 통해 BigQuery로 데이터를 적재할 때, 데이터 유실이나 순서 보장을 위해 Kafka 파이프라인에서 특별히 관리한 설정이 있나요?", "job_category": "DBA", "target_evidence": "데이터 파이프라인: Debezium CDC → Kafka → BigQuery 적재", "expected_signal": "CDC 데이터의 정합성(At-least-once 등)과 파이프라인 안정성을 위한 엔지니어링 경험"}, {"category": "BEHAVIORAL", "question": "분기별 복구 훈련을 통해 RTO 40분을 달성하셨는데, 훈련 과정에서 예상치 못한 장애나 실패를 경험하고 이를 개선했던 사례가 있다면 말씀해주세요.", "job_category": "DBA", "target_evidence": "백업: 매일 스냅샷 + binlog PITR, 분기별 복구 훈련(RTO 40분)", "expected_signal": "장애 대응 프로세스에서의 문제 발견, 원인 분석 및 재발 방지를 위한 행동(STAR)"}], "latency_sec": 51.25, "in_tokens": 2581, "out_tokens": 740} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "questions", "case_id": "q2-dba-infra-multi", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "MySQL 복제 지연을 90초에서 3초로 줄이기 위해 대용량 UPDATE를 1만 건 단위로 분할하셨는데, 이 청크 크기를 결정한 기술적 근거는 무엇인가요?", "job_category": "DBA", "target_evidence": "복제 지연 최대 90초 → 3초: 대용량 배치 UPDATE 를 1만 건 단위 청크로 분할, binlog_format ROW 유지", "expected_signal": "데이터 처리량과 복제 지연(Replication Lag) 사이의 트레이드오프를 고려한 수치적 근거 제시"}, {"category": "TECH_CHOICE", "question": "온라인 스키마 변경을 위해 gh-ost를 도입하셨는데, pt-online-schema-change와 같은 다른 도구 대비 gh-ost를 선택한 이유는 무엇인가요?", "job_category": "DBA", "target_evidence": "온라인 스키마 변경: gh-ost 도입, 컬럼 추가 시 락 대기 장애 0건", "expected_signal": "트리거 기반 방식과 binlog 기반 방식의 차이 및 gh-ost의 동작 메커니즘에 대한 이해"}, {"category": "PROJECT_DEEP_DIVE", "question": "PostgreSQL 거래내역 테이블을 월 단위로 파티셔닝하셨는데, 파티션 키 선정 기준과 파티션 프루닝(Partition Pruning)이 성능에 미친 영향은 무엇인가요?", "job_category": "DBA", "target_evidence": "PostgreSQL 14 (RDS) 운영: ... 파티셔닝으로 거래내역 테이블 월 단위 분할", "expected_signal": "파티셔닝 전략이 쿼리 실행 계획 및 I/O 효율성에 기여하는 방식 설명"}, {"category": "TECH_CHOICE", "question": "Terraform을 통해 VPC와 RDS를 모듈화하셨는데, 인프라 코드(IaC) 관리 시 state 파일의 충돌이나 보안 이슈를 어떻게 해결하셨나요?", "job_category": "INFRA", "target_evidence": "Terraform 으로 VPC·RDS·EKS 모듈화, 환경별(dev/stg/prod) workspace 분리", "expected_signal": "Remote Backend 활용 및 Workspace 분리를 통한 환경 격리 및 상태 관리 경험"}, {"category": "PROJECT_DEEP_DIVE", "question": "EKS 환경에서 트래픽 피크를 대비해 CronJob 기반의 사전 스케일아웃을 운영하셨는데, HPA의 반응 속도와 CronJob의 예측 정확도 사이의 간극을 어떻게 조율하셨나요?", "job_category": "INFRA", "target_evidence": "HPA 기준을 CPU 70% 로 설정, 트래픽 피크(월급날 10시) 대비 사전 스케일아웃 CronJob 운영", "expected_signal": "예측 기반 스케일링과 반응 기반 스케일링의 상호보완적 운영 전략 설명"}, {"category": "CS_FUNDAMENTAL", "question": "ArgoCD를 도입하여 배포 리드타임을 단축하셨는데, GitOps 모델에서 Git의 상태와 클러스터의 실제 상태가 불일치(Drift)할 때 발생하는 문제와 해결 방안은 무엇인가요?", "job_category": "INFRA", "target_evidence": "ArgoCD GitOps 도입으로 배포 리드타임 1일 → 30분", "expected_signal": "Declarative configuration의 핵심 원리와 Reconciliation loop의 동작 원리 이해"}], "latency_sec": 63.198, "in_tokens": 2890, "out_tokens": 904} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "questions", "case_id": "q2-infra-recent-dup", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "PostgreSQL 거래내역 테이블을 월 단위로 파티셔닝했을 때, 쿼리 성능 최적화를 위해 고려한 Partition Key 선정 기준은 무엇인가요?", "job_category": "INFRA", "target_evidence": "파티셔닝으로 거래내역 테이블 월 단위 분할", "expected_signal": "데이터 분포와 쿼리 패턴을 고려한 Partition Key 선정 논리와 Partition Pruning의 동작 원리 이해"}, {"category": "TECH_CHOICE", "question": "Terraform을 사용하여 VPC와 EKS를 모듈화할 때, 환경별 workspace 분리 외에 리소스 간 의존성 관리를 위해 어떤 전략을 사용했나요?", "job_category": "INFRA", "target_evidence": "Terraform 으로 VPC·RDS·EKS 모듈화, 환경별(dev/stg/prod) workspace 분리", "expected_signal": "IaC 모듈화 시 재사용성과 격리성을 확보하기 위한 구조적 설계 능력"}, {"category": "CS_FUNDAMENTAL", "question": "PostgreSQL의 autovacuum 튜닝을 통해 해결하고자 했던 구체적인 문제 상황과, 튜닝 후 지표의 변화는 어떠했나요?", "job_category": "INFRA", "target_evidence": "autovacuum 튜닝, 슬로우 쿼리 p95 2.3초 → 180ms", "expected_signal": "MVCC 구조에서 Vacuum의 역할과 Bloat 현상이 성능에 미치는 영향에 대한 이해"}, {"category": "PROJECT_DEEP_DIVE", "question": "EKS 클러스터 운영 중 트래픽 피크를 대비해 CronJob으로 사전 스케일아웃을 수행할 때, 노드(EC2)의 수급과 파드(Pod)의 스케일링 간의 정렬을 어떻게 관리했나요?", "job_category": "INFRA", "target_evidence": "트래픽 피크(월급날 10시) 대비 사전 스케일아웃 CronJob 운영", "expected_signal": "Cluster Autoscaler와 HPA 간의 관계 및 리소스 부족을 방지하기 위한 선제적 대응 로직"}, {"category": "TECH_CHOICE", "question": "Prometheus와 Grafana를 활용해 인프라를 모니터링할 때, 장애를 사전에 감지하기 위해 설정한 가장 핵심적인 골든 시그널(Golden Signals)은 무엇이었나요?", "job_category": "INFRA", "target_evidence": "Prometheus, Grafana", "expected_signal": "단순 CPU/Memory 지표를 넘어 Latency, Traffic, Error, Saturation을 인프라 관점에서 정의하고 활용하는 능력"}], "latency_sec": 49.165, "in_tokens": 2707, "out_tokens": 693} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "questions", "case_id": "q2-backend-focus-weak", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "결제 콜백 지연 문제를 해결하기 위해 멱등 키와 Outbox 패턴을 사용하셨는데, Outbox 테이블에 저장된 이벤트를 Kafka로 발행하는 시점과 보장 방식은 어떻게 설계하셨나요?", "job_category": "BACKEND", "target_evidence": "결제 승인 콜백 지연 시 중복 주문 발생 문제: 멱등 키 테이블 + Transactional Outbox 로 해결", "expected_signal": "Transactional Outbox 패턴의 핵심인 DB 트랜잭션과 메시지 발행 간의 원자성 보장 메커니즘(Relay/Polling 방식 등)을 논리적으로 설명할 수 있는가"}, {"category": "TECH_CHOICE", "question": "실시간 재고 동기화 프로젝트에서 낙관적 락에서 분산 락으로 전환하셨는데, 낙관적 락을 포기하고 분산 락을 선택한 구체적인 판단 근거와 트레이드오프는 무엇이었나요?", "job_category": "BACKEND", "target_evidence": "Redis 기반 재고 캐시 + DB write-behind, 동시성 제어(낙관적 락 -> 분산 락 전환)", "expected_signal": "충돌 빈도에 따른 성능 저하와 데이터 정합성 사이의 트레이드오프를 이해하고, 분산 락 도입 시 발생하는 네트워크 비용이나 복잡성을 인지하고 있는가"}, {"category": "CS_FUNDAMENTAL", "question": "모놀리식에서 MSA로 전환하며 DB를 분리하셨는데, 서비스 분리 후 발생할 수 있는 분산 트랜잭션 문제(예: 주문-결제 간 데이터 불일치)를 방지하기 위해 어떤 전략을 고려하셨나요?", "job_category": "BACKEND", "target_evidence": "모놀리식 -> MSA 전환: 주문 서비스를 별도 서비스로 분리, DB 분리(PostgreSQL) 및, Kafka 기반 이벤트 발행/구독 구조 도입", "expected_signal": "Saga 패턴이나 2PC 같은 분산 트랜잭션 관리 개념을 실제 프로젝트의 구조적 변화와 연결하여 논리적으로 설명할 수 있는가"}, {"category": "PROJECT_DEEP_DIVE", "question": "정산 배치 성능을 5시간에서 40분으로 개선하셨는데, QueryDSL 튜닝과 인덱스 재설계 과정에서 가장 결정적이었던 데이터 접근 방식의 변화는 무엇이었나요?", "job_category": "BACKEND", "target_evidence": "정산 배치 성능 개선: 5시간 -> 40분 (QueryDSL 튜닝, 청크 단위 처리, 인덱스 재설계)", "expected_signal": "단순 쿼리 수정을 넘어, 데이터 처리 단위(Chunk)와 인덱스 구조가 대용량 배치 성능에 미치는 영향을 기술적으로 분석하여 답변하는가"}, {"category": "BEHAVIORAL", "question": "대용량 트래픽 환경에서 데이터 정합성을 지키는 서버를 만드는 데 관심이 많다고 하셨는데, 본인이 생각하는 '신뢰성 있는 백엔드 개발자'의 가장 중요한 역량은 무엇인가요?", "job_category": "BACKEND", "target_evidence": "대용량 트래픽에서도 데이터 정합성을 지키는 서버를 만드는 데 관심이 많습니다.", "expected_signal": "본인의 기술적 지향점과 개발 철학을 구체적인 사례나 가치관에 기반하여 일관성 있게 전달하는가"}], "latency_sec": 62.021, "in_tokens": 2991, "out_tokens": 869} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "questions", "case_id": "q2-fullstack-multi", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "주문 서비스 분리 시 Kafka를 도입하셨는데, 이벤트 발행과 DB 업데이트 간의 원자성을 어떻게 보장하셨나요?", "job_category": "BACKEND", "target_evidence": "모놀리식 -> MSA 전환: 주문 서비스를 별도 서비스로 분리... Kafka 기반 이벤트 발행/구독 구조 도입", "expected_signal": "Transactional Outbox 패턴을 활용하여 데이터 일관성을 유지한 구체적인 메커니즘 설명"}, {"category": "TECH_CHOICE", "question": "결제 지연 이슈를 해결할 때 멱등 키와 Outbox 패턴을 선택하셨는데, 다른 대안과 비교했을 때 이 방식의 장점은 무엇인가요?", "job_category": "BACKEND", "target_evidence": "결제 승인 콜백 지연 시 중복 주문 발생 문제: 멱등 키 테이블 + Transactional Outbox 로 해결", "expected_signal": "분산 환경에서 중복 요청을 방지하고 데이터 유실 없이 이벤트를 전달하기 위한 기술적 타당성 제시"}, {"category": "PROJECT_DEEP_DIVE", "question": "정산 배치 성능을 5시간에서 40분으로 단축하셨는데, QueryDSL 튜닝과 인덱스 재설계 시 가장 핵심적으로 고려한 부분은 무엇인가요?", "job_category": "BACKEND", "target_evidence": "정산 배치 성능 개선: 5시간 -> 40분 (QueryDSL 튜닝, 청크 단위 처리, 인덱스 재설계)", "expected_signal": "대량 데이터 처리 시 I/O 부하를 줄이기 위한 Fetch 전략 및 인덱스 스캔 최적화 경험"}, {"category": "TECH_CHOICE", "question": "실시간 재고 동기화 프로젝트에서 낙관적 락에서 분산 락으로 전환하셨는데, 전환을 결정하게 된 결정적인 임계점은 무엇이었나요?", "job_category": "BACKEND", "target_evidence": "Redis 기반 재고 캐시 + DB write-behind, 동시성 제어(낙관적 락 -> 분산 락 전환)", "expected_signal": "충돌 빈도 증가에 따른 성능 저하나 데이터 정합성 이슈를 인지하고 적절한 동시성 제어 모델을 선택한 근거"}, {"category": "PROJECT_DEEP_DIVE", "question": "여행 일정 앱에서 2천 개 이상의 항목을 처리할 때 react-window를 도입하셨는데, 가상화 도입 후 INP 수치가 개선된 구체적인 이유는 무엇인가요?", "job_category": "FRONTEND", "target_evidence": "일정 타임라인: 항목 2천 개 이상일 때 스크롤 끊김 -> react-window 가상화 도입 (virtualize timeline, INP 480ms -> 120ms)", "expected_signal": "DOM 노드 개수 감소가 메인 스레드의 작업 부하와 입력 지연(INP)에 미치는 영향에 대한 이해"}, {"category": "BEHAVIORAL", "question": "기술적 난관을 해결하기 위해 CRDT 검토와 같은 새로운 기술을 탐색하는 과정에서, 본인만의 학습 및 적용 방식이 있다면 무엇인가요?", "job_category": "FRONTEND", "target_evidence": "충돌은 last-write-wins (TODO 주석: \"CRDT 검토 필요\")", "expected_signal": "문제를 정의하고, 현재의 한계를 인지하며, 더 나은 해결책을 위해 기술을 탐구하는 자기주도적 성장 태도"}], "latency_sec": 64.113, "in_tokens": 3114, "out_tokens": 901} +{"label": "q-gemma4-26b-UD-IQ2_M", "suite": "questions", "case_id": "q2-coverletter-integrated", "rep": 0, "ok": true, "questions": [{"category": "TECH_CHOICE", "question": "SQLite에서 PostgreSQL로 이전할 때, 동시 쓰기 락 문제를 해결하기 위해 구체적으로 어떤 트랜잭션 격리 수준을 선택했나요?", "job_category": "BACKEND", "target_evidence": "알림 봇 DB를 SQLite 로 시작했다가 동시 쓰기 락 문제로 알림이 중복 발송되었습니다. ... PostgreSQL 로 이전하며 트랜잭션 격리 수준을 공부하게 됐습니다.", "expected_signal": "데이터 정합성을 위해 선택한 격리 수준(Isolation Level)의 기술적 근거와 그에 따른 부작용(예: 성능 저하, Phantom Read 등)을 이해하고 있는지 확인"}, {"category": "PROJECT_DEEP_DIVE", "question": "800명이 사용하는 알림 봇의 크롤러가 멈추지 않게 하기 위해, 서비스의 가용성을 높이려 도입한 기술적 장치가 있나요?", "job_category": "BACKEND", "target_evidence": "사용자 800명이 매일 쓰는 서비스를 운영해 본 경험이 있습니다. ... 기능보다 '멈추지 않는 서비스'가 신뢰를 만든다는 것을 배웠습니다.", "expected_signal": "단순 기능 구현을 넘어 모니터링, 재시도 로직(Retry), 혹은 에러 핸들링을 통한 서비스 안정성 확보 경험을 STAR 방식으로 설명"}, {"category": "BEHAVIORAL", "question": "API 명세로 인한 갈등 상황에서 본인의 방식을 고집하다 감정이 상했던 경험을 말씀해주셨는데, 이후 대안을 비교하는 방식으로 바꾼 뒤 실제 협업에서 어떤 변화가 있었나요?", "job_category": "BACKEND", "target_evidence": "초반에 제 방식이 옳다고 고집해 팀원과 감정이 상한 적도 있어, 이후에는 결정 전에 대안 두 가지를 함께 비교하는 방식으로 바꿨습니다.", "expected_signal": "자신의 커뮤니케이션 스타일을 객관적으로 성찰하고, 팀의 생산성을 위해 개인의 태도를 어떻게 구체적으로 수정했는지 답변"}, {"category": "CS_FUNDAMENTAL", "question": "OpenAPI 명세를 작성하고 Mock 서버를 구축하여 프론트엔드와의 병렬 개발을 유도하셨는데, 이때 설계한 API의 데이터 일관성을 어떻게 보장했나요?", "job_category": "BACKEND", "target_evidence": "저는 OpenAPI 명세를 먼저 작성하고 Mock 서버를 띄워 프론트가 병렬로 개발하도록 제안했고", "expected_signal": "API 설계 단계에서 데이터 타입, 에러 코드, 응답 구조 등을 정의하여 인터페이스의 규격(Contract)을 맞추는 역량 확인"}, {"category": "BEHAVIORAL", "question": "기술적 결함(DB 락 문제)을 해결하는 데 3일이라는 시간이 소요되었다고 하셨는데, 당시 문제를 파악하기 위해 어떤 디버깅 과정을 거쳤고 무엇을 배웠나요?", "job_category": "BACKEND", "target_evidence": "원인을 찾는 데 3일이 걸렸고, PostgreSQL 로 이전하며 트랜잭션 격리 수준을 공부하게 됐습니다.", "expected_signal": "문제의 근본 원인(Root Cause)을 파악하기 위한 논리적 추론 과정과 실패를 통해 기술적 지식을 내재화하는 학습 태도 확인"}], "latency_sec": 58.051, "in_tokens": 2659, "out_tokens": 829} diff --git a/docs/research/thesis/quant/raw/q-gemma4-e4b-Q4_K_M.jsonl b/docs/research/thesis/quant/raw/q-gemma4-e4b-Q4_K_M.jsonl index ecba032..0921397 100644 --- a/docs/research/thesis/quant/raw/q-gemma4-e4b-Q4_K_M.jsonl +++ b/docs/research/thesis/quant/raw/q-gemma4-e4b-Q4_K_M.jsonl @@ -17,3 +17,54 @@ {"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-infra-gitops-strong", "rep": 0, "ok": true, "followup_question": "말씀하신 'OutOfSync 알림'이 발생했을 때, 구체적으로 어떤 조건에서, 어떤 방식으로 알림을 받으셨는지 예를 들어 설명해 주실 수 있나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 3.0, "logic": 4.0, "structure": "PARTIAL_STAR", "correctness": 5.0}, "latency_sec": 4.106, "ttft_sec": 2.731, "in_tokens": 1724, "out_tokens": 88} {"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-personality-failure-star", "rep": 0, "ok": true, "followup_question": "SQLite에서 PostgreSQL로 이전하며 트랜잭션 격리 수준을 공부하셨다고 했는데, 구체적으로 어떤 격리 수준을 적용했고, 그 결정의 기술적 근거는 무엇이었나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 4.0, "logic": 4.0, "structure": "PARTIAL_STAR", "correctness": 5.0}, "latency_sec": 4.217, "ttft_sec": 2.791, "in_tokens": 1730, "out_tokens": 91} {"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-backend-isolation-strong", "rep": 0, "ok": true, "followup_question": "READ COMMITTED를 사용하면서 발생할 수 있는 '비반복적 읽기(Non-repeatable Read)' 현상에 대해, 정산 로직상 어떤 위험을 감수하고 계신 건가요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 4.0, "logic": 4.0, "structure": "NONE", "correctness": null}, "latency_sec": 2.858, "ttft_sec": 1.419, "in_tokens": 1410, "out_tokens": 91} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-integrated-tradeoff-strong", "rep": 0, "ok": true, "followup_question": "월 2~3건의 충돌 빈도라는 근거 외에, last-write-wins가 사용자 경험 측면에서 어떤 '최소한의 허용 가능한' 수준이라고 판단하셨는지 구체적인 사용자 시나리오를 들어 설명해 주시겠어요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 4.0, "logic": 5.0, "structure": "PARTIAL_STAR", "correctness": 5.0}, "latency_sec": 4.571, "ttft_sec": 2.804, "in_tokens": 1730, "out_tokens": 108} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-frontend-buzzword-weak", "rep": 0, "ok": true, "followup_question": "서버 컴포넌트가 성능에 좋다고 하셨는데, 구체적으로 클라이언트 컴포넌트 대비 번들 크기나 데이터 패칭 방식에서 어떤 이점이 발생하는지 예를 들어 설명해주시겠어요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 1.0, "logic": 2.0, "structure": "NONE", "correctness": null}, "latency_sec": 2.765, "ttft_sec": 1.333, "in_tokens": 1355, "out_tokens": 92} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-dba-vague-weak", "rep": 0, "ok": true, "followup_question": "gh-ost 도입 시 '락 대기 장애 0건'이라고 하셨는데, 구체적으로 어떤 종류의 스키마 변경 작업에서 락 대기 이슈를 막으셨는지 사례를 들어 설명해 주시겠어요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 1.0, "logic": 3.0, "structure": "PARTIAL_STAR", "correctness": 4.0}, "latency_sec": 3.68, "ttft_sec": 2.108, "in_tokens": 1574, "out_tokens": 99} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-infra-fact-mismatch", "rep": 0, "ok": true, "followup_question": "답변에서 '리전을 이중화해서 자동 페일오버'를 구현하셨다고 했는데, 이 과정에서 구체적으로 어떤 메커니즘(예: Route 53 지연 전파, ALB 설정 등)을 사용하셨는지 설명해 주시겠어요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 2.0, "logic": 3.0, "structure": "PARTIAL_STAR", "correctness": 3.0}, "latency_sec": 4.223, "ttft_sec": 2.459, "in_tokens": 1662, "out_tokens": 110} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-backend-fact-mismatch", "rep": 0, "ok": true, "followup_question": "말씀하신 'Spark로 옮겨서 10분으로 줄였다'는 부분에서, 기존 3시간 배치와 Spark 적용 후 10분으로 줄이면서 구체적으로 어떤 병목 지점을 진단했고, 그 병목을 해결하기 위해 Spark의 어떤 기능을 활용하셨는지 설명해 주시겠어요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 1.0, "logic": 2.0, "structure": "NONE", "correctness": 1.0}, "latency_sec": 4.94, "ttft_sec": 3.046, "in_tokens": 1781, "out_tokens": 117} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-personality-generic-weak", "rep": 0, "ok": true, "followup_question": "'책임감이 강하다'는 것을 보여줄 수 있는, 가장 기억에 남는 프로젝트나 업무 사례를 하나만 구체적으로 말씀해주시겠어요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 1.0, "logic": 3.0, "structure": "NONE", "correctness": null}, "latency_sec": 2.426, "ttft_sec": 1.208, "in_tokens": 1340, "out_tokens": 79} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-offtopic-weak", "rep": 0, "ok": true, "followup_question": "Kafka의 처리량과 순서 보장 같은 특성이 RabbitMQ보다 우위에 있다고 판단하신 구체적인 기술적 근거가 무엇인가요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 1.0, "logic": 2.0, "structure": "NONE", "correctness": null}, "latency_sec": 2.466, "ttft_sec": 1.318, "in_tokens": 1360, "out_tokens": 76} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-dk-no-experience", "rep": 0, "ok": true, "followup_question": "PodDisruptionBudget이 가용성 보장을 위해 어떤 메커니즘으로 작동하는지 개념적으로 설명해 주시겠어요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 2.39, "ttft_sec": null, "in_tokens": 1343, "out_tokens": 76} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-dk-pass", "rep": 0, "ok": true, "followup_question": "렌더링 파이프라인의 레이아웃과 페인트 단계에 대해 설명하지 못하셨는데, 혹시 어떤 부분이 가장 이해가 안 되셨나요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 2.426, "ttft_sec": null, "in_tokens": 1330, "out_tokens": 83} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-dk-forgot", "rep": 0, "ok": true, "followup_question": "분기별 복구 훈련 시 RTO 40분 중 가장 오래 걸린 단계가 정확히 기억나지 않으신다면, 해당 훈련에서 가장 어려웠던 '기술적 병목'은 무엇이었는지 설명해주실 수 있나요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 1.0, "logic": 3.0, "structure": "NONE", "correctness": null}, "latency_sec": 3.766, "ttft_sec": null, "in_tokens": 1575, "out_tokens": 103} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-dk-english", "rep": 0, "ok": true, "followup_question": "CAP 정리에서 네트워크 분할 시 일관성과 가용성 중 하나를 포기해야 하는 이유에 대해 조금 더 자세히 설명해 주실 수 있나요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 2.452, "ttft_sec": null, "in_tokens": 1337, "out_tokens": 82} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-dk-stt-fragment", "rep": 0, "ok": true, "followup_question": "Terraform workspace 대신 디렉터리로 환경을 분리하는 방식과 비교했을 때, 구체적으로 어떤 부분에서 차이점이나 장단점이 있다고 보십니까?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 2.435, "ttft_sec": null, "in_tokens": 1332, "out_tokens": 83} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-cl-term", "rep": 0, "ok": true, "followup_question": "결제 승인 API의 멱등성이라는 것이, 요청을 여러 번 보내도 서버 상태에 부작용이 없도록 보장하는 것을 의미하는 것이 맞을까요?", "answer_intent": "CLARIFICATION", "answer_evaluation": {"specificity": 1.0, "logic": 2.0, "structure": "NONE", "correctness": null}, "latency_sec": 2.544, "ttft_sec": 1.268, "in_tokens": 1348, "out_tokens": 85} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-cl-repeat", "rep": 0, "ok": true, "followup_question": "presigned URL 로 S3 에 직접 업로드할 때 클라이언트에서 WebP 로 변환한 이유와 그 한계는 무엇인지 다시 설명해 주시겠어요?", "answer_intent": "CLARIFICATION", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 2.481, "ttft_sec": 1.243, "in_tokens": 1357, "out_tokens": 83} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-cl-example", "rep": 0, "ok": true, "followup_question": "커버링 인덱스가 성능에 도움이 되는 조건에 대해, 어떤 종류의 쿼리(예: WHERE 절, SELECT 절)에서 인덱스만으로 모든 정보를 얻을 수 있는지 구체적인 예시를 들어 설명해 주시겠어요?", "answer_intent": "CLARIFICATION", "answer_evaluation": {"specificity": 1.0, "logic": 2.0, "structure": "NONE", "correctness": null}, "latency_sec": 2.817, "ttft_sec": 1.249, "in_tokens": 1340, "out_tokens": 101} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-cl-which-part", "rep": 0, "ok": true, "followup_question": "장애 대응 과정에서 팀과 어떻게 소통했고, 기술적으로는 어떤 조치를 했는지 함께 말씀해 주세요.", "answer_intent": "CLARIFICATION", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 2.267, "ttft_sec": 1.235, "in_tokens": 1354, "out_tokens": 71} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-cl-stt-noisy", "rep": 0, "ok": true, "followup_question": "팀 내에서 기술 부채를 줄이자고 설득했던 경험이 있는지 다시 한번 설명해 주시겠어요?", "answer_intent": "CLARIFICATION", "answer_evaluation": {"specificity": 1.0, "logic": 1.0, "structure": "NONE", "correctness": null}, "latency_sec": 2.267, "ttft_sec": 1.242, "in_tokens": 1341, "out_tokens": 71} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-motivation-strong", "rep": 0, "ok": true, "followup_question": "말씀하신 '멱등 키와 Outbox 적용 경험'이 구체적으로 어떤 상황에서 중복 주문 0건을 달성하게 했는지, 그 메커니즘을 조금 더 자세히 설명해 주시겠어요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 4.0, "logic": 5.0, "structure": "PARTIAL_STAR", "correctness": 5.0}, "latency_sec": 4.331, "ttft_sec": 2.782, "in_tokens": 1848, "out_tokens": 98} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-repeat-history-weak", "rep": 0, "ok": true, "followup_question": "Outbox 릴레이가 두 번 발행했을 때, 소비자 측에서 멱등성을 보장하기 위해 구체적으로 어떤 메커니즘(예: 이벤트 ID 저장 방식)을 사용하셨나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 1.0, "logic": 3.0, "structure": "NONE", "correctness": null}, "latency_sec": 2.803, "ttft_sec": 1.421, "in_tokens": 1411, "out_tokens": 89} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-confirm-correction", "rep": 0, "ok": true, "followup_question": "환경별 workspace 분리 시, 각 환경 간의 의존성 충돌을 방지하기 위해 어떤 구체적인 제약 조건(Constraint)을 설정하셨나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 2.0, "logic": 3.0, "structure": "NONE", "correctness": null}, "latency_sec": 2.565, "ttft_sec": 1.329, "in_tokens": 1356, "out_tokens": 81} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "followup", "case_id": "f2-confirm-yes", "rep": 0, "ok": true, "followup_question": "JWT 전략을 사용하셨다고 했는데, 세션 만료 시 토큰 재발급 로직은 어떻게 설계하셨나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 2.0, "logic": 3.0, "structure": "NONE", "correctness": null}, "latency_sec": 2.263, "ttft_sec": 1.188, "in_tokens": 1345, "out_tokens": 72} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "coaching", "case_id": "c-weak-backend", "rep": 0, "ok": true, "coaching": {"model_answer": "두 패턴을 함께 사용한 이유는 각각 다른 계층의 실패 시나리오를 방어하기 위함입니다. **멱등 키(Idempotency Key)**는 외부 시스템(결제 게이트웨이)으로부터의 요청이 네트워크 문제 등으로 인해 재전송될 때, 우리 시스템이 동일한 요청을 중복 처리하는 것을 막는 '요청 레벨'의 방어책입니다. 즉, '이 요청이 이전에 처리된 적이 있는가?'를 확인합니다.\n\n반면, **Outbox 패턴**은 내부적으로 발생하는 비즈니스 로직(주문 생성)이 성공적으로 DB에 기록된 후, 이 변경 사항을 외부 메시지 브로커(Kafka)로 '안전하게' 발행하는 과정의 원자성(Atomicity)을 보장합니다. 즉, DB 트랜잭션과 메시지 발행이 하나의 단위로 묶여, 주문이 DB에 기록되었는데 메시지가 유실되는 '내부 전파 실패' 케이스를 막아줍니다. 결론적으로, 멱등 키는 '재시도 요청'을 막고, Outbox는 '내부 데이터 변경 후 이벤트 유실'을 막아 완벽한 데이터 일관성을 확보했습니다.", "answer_rewrite": "결제 승인 콜백 지연으로 인한 중복 주문 문제를 해결하기 위해 멱등 키와 Outbox 패턴을 조합했습니다. 이 둘은 서로 다른 실패 지점을 보완합니다.\n\n첫째, **멱등 키**는 외부 콜백 요청이 네트워크 문제 등으로 인해 재전송될 때, 우리 시스템이 동일한 결제 요청을 중복으로 처리하는 것을 방지합니다. 이는 '외부 요청의 중복 수신'에 대한 방어입니다.\n\n둘째, **Outbox 패턴**은 주문 생성과 같은 핵심 비즈니스 로직이 DB에 성공적으로 커밋된 후, 이 변경 사항을 Kafka로 이벤트 발행하는 과정에서 발생할 수 있는 '내부 데이터와 이벤트 간의 불일치'를 방지합니다. 즉, 주문은 생성되었으나 이벤트가 유실되는 상황을 막는 것입니다.\n\n따라서 멱등 키는 외부 요청의 안전성을, Outbox는 내부 트랜잭션의 안전성을 보장하여 중복 주문 0건을 달성할 수 있었습니다.", "coaching_comment": "단순히 '잘 처리했다'가 아니라, 각 패턴이 막는 '구체적인 실패 시나리오'를 명확히 구분하여 설명해야 합니다."}, "latency_sec": 16.015, "in_tokens": 1394, "out_tokens": 560} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "coaching", "case_id": "c-dont-know-cs", "rep": 0, "ok": true, "coaching": {"model_answer": "PostgreSQL의 MVCC(Multi-Version Concurrency Control)는 트랜잭션의 격리성을 보장하기 위해 데이터의 여러 버전을 유지합니다. 오래 열린 트랜잭션이 존재하면, 해당 트랜잭션이 참조하는 데이터의 'xmin' (트랜잭션 ID)이 활성 상태로 남아있게 됩니다. 이로 인해 PostgreSQL은 해당 트랜잭션이 종료될 때까지 해당 데이터의 'dead tuple'을 안전하게 회수(cleanup)할 수 없습니다. \n\n이러한 'xmin horizon'의 지연은 `VACUUM` 프로세스가 해당 튜플을 제거하지 못하게 만들어, 테이블 공간이 불필요하게 점유되는 'Table Bloat' 현상을 유발하고, 시스템 성능 저하의 원인이 됩니다. 따라서 장기 실행 트랜잭션 관리는 데이터베이스 성능 유지에 매우 중요합니다.", "answer_rewrite": "죄송하지만, 해당 질문에 대해 깊이 있는 답변을 드리기 어렵습니다. 하지만 MVCC의 기본 원리 중 트랜잭션 ID(XID)와 Dead Tuple 회수에 대해 알고 있습니다. 만약 이 질문에 대해 답변해야 한다면, '오래 열린 트랜잭션은 해당 트랜잭션의 XID가 활성 상태로 남아있어, VACUUM이 해당 튜플을 안전하게 제거할 수 있는 시점(xmin horizon)을 지연시키고, 결과적으로 테이블 블로트(Table Bloat)를 유발할 수 있다'는 구조로 설명하는 것이 핵심이라고 이해하고 있습니다.", "coaching_comment": "모르는 질문이라도 핵심 키워드(MVCC, XID, Vacuum, Bloat)를 언급하며 구조적으로 접근하려는 시도를 보여주는 것이 중요합니다."}, "latency_sec": 9.25, "in_tokens": 927, "out_tokens": 401} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "coaching", "case_id": "c-personality-rambling", "rep": 0, "ok": true, "coaching": {"model_answer": "캡스톤 프로젝트 당시, 프론트엔드 팀원과 API 스펙 해석에 대한 의견 충돌이 있었습니다. 저는 초기 설계 단계에서 제가 생각하는 명세가 가장 효율적이라고 판단하여 제 방식을 고수하려 했습니다. 이로 인해 팀원과 감정적인 마찰이 있었고, 프로젝트 통합 직전에 2주 지연이라는 심각한 상황에 놓였습니다. 저는 이 상황을 해결하기 위해, 제 주장을 관철하기보다 '팀의 목표 달성'에 초점을 맞추기로 했습니다. 구체적으로, OpenAPI 명세를 먼저 작성하고 Mock 서버를 띄워 프론트엔드가 병렬 개발을 시작하도록 제안했습니다. 이 접근 방식 덕분에 병목 현상을 해소하고, 이후 스프린트에서는 통합 이슈를 3건에서 0건으로 줄이는 성과를 낼 수 있었습니다. 이 경험을 통해, 기술적 우위 주장보다 '모두가 동의할 수 있는 합의 도출 과정'이 더 중요하다는 것을 배웠고, 이후에는 결정 전에 반드시 대안 두 가지를 함께 비교하는 방식으로 접근 방식을 바꿨습니다.", "answer_rewrite": "캡스톤 프로젝트에서 프론트엔드 팀원과 API 스펙 해석에 대해 의견 충돌이 있었습니다. 저는 제 방식이 기술적으로 옳다고 생각하여 강하게 주장했지만, 이로 인해 팀원과 감정이 상했고 프로젝트 통합 직전에 2주 지연이라는 문제가 발생했습니다. 이 상황을 해결하기 위해, 저는 제 주장을 굽히기보다 문제를 해결하는 데 집중했습니다. 먼저 OpenAPI 명세를 제가 주도하여 작성하고 Mock 서버를 띄워 프론트엔드가 병렬로 개발할 수 있도록 제안했습니다. 이 행동 덕분에 병목 현상을 해소했고, 이후 스프린트에서는 통합 이슈를 3건에서 0건으로 줄이는 결과를 얻었습니다. 이 경험을 통해, 기술적 논쟁을 넘어 '모두가 수용 가능한 합의 도출 과정'이 중요하다는 것을 깨달았고, 이후에는 어떤 결정을 내리기 전에 반드시 대안 두 가지를 함께 비교하며 논의하는 습관을 들였습니다.", "coaching_comment": "단순히 '소통이 중요하다'고 말하는 대신, 실제 갈등 상황(캡스톤 프로젝트)을 STAR 기법에 맞춰 구체적인 행동과 정량적 결과로 설명해야 합니다."}, "latency_sec": 12.863, "in_tokens": 1262, "out_tokens": 530} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "coaching", "case_id": "c2-f-strong-backend", "rep": 0, "ok": true, "coaching": {"model_answer": "두 패턴을 함께 사용한 이유는 각각 다른 지점에서 발생하는 비즈니스 로직의 실패 케이스를 방어하기 위함입니다. **멱등 키(Idempotency Key)**는 외부 시스템(PG사)으로부터의 **재시도(Retry)**에 의해 발생하는 '동일한 요청의 중복 처리'를 방지합니다. 즉, 외부 입력의 중복을 막아 주문 자체의 중복 생성을 원천 차단하는 역할을 합니다. 반면, **Outbox 패턴**은 시스템 내부의 **분산 트랜잭션(Distributed Transaction)** 실패를 방지합니다. 주문 데이터베이스에 주문이 성공적으로 저장되었더라도, 이후 Kafka 발행 과정에서 네트워크 문제 등으로 이벤트가 유실될 수 있습니다. Outbox는 DB 트랜잭션 내에서 '이벤트 발생 의도'를 DB에 기록하고, 별도의 리레이가 이를 감지하여 발행함으로써, '주문은 성공했으나 이벤트가 누락되는' 상황을 막아 데이터 일관성을 보장합니다. 요약하면, 멱등 키는 '입력의 중복'을, Outbox는 '시스템 내부의 전파 누락'을 막는 역할을 합니다.", "answer_rewrite": "멱등 키와 Outbox 패턴을 함께 사용한 이유는 각각 다른 종류의 실패 지점을 보완하기 위함입니다. **멱등 키**는 PG사로부터의 콜백 재전송 시, 동일한 승인 요청이 여러 번 들어와도 주문이 한 번만 생성되도록 보장합니다. 이는 외부 시스템의 불안정성으로 인한 '동일 입력의 중복 처리'를 방지합니다. 반면, **Outbox 패턴**은 주문 DB에 주문이 성공적으로 저장된 후, 해당 주문 정보를 Kafka로 발행하는 과정에서 발생할 수 있는 '데이터 전파 누락'을 막기 위해 사용했습니다. 주문 저장과 이벤트 발행을 단일 DB 트랜잭션으로 묶지 않고 Outbox 테이블에 기록함으로써, DB 트랜잭션의 성공 여부에 따라 이벤트 발행 의도가 확실하게 보존됩니다. 덕분에 월 30건 발생하던 중복 주문 이슈를 0건으로 줄일 수 있었습니다.", "coaching_comment": "두 패턴의 역할 분담(외부 입력 vs 내부 전파)을 명확히 구분하여 설명하면 기술적 깊이가 훨씬 높아집니다."}, "latency_sec": 12.052, "in_tokens": 1101, "out_tokens": 520} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "coaching", "case_id": "c2-f-infra-fact-error", "rep": 0, "ok": true, "coaching": {"model_answer": "HPA 설정 시에는 단순히 메모리 사용률에만 의존하기보다, 서비스의 특성과 트래픽 패턴을 종합적으로 고려하여 메트릭을 선택했습니다. 저희는 CPU 사용률을 주요 지표로 설정하고, 목표치(Target)를 70%로 잡았습니다. 이는 시스템이 여유 자원을 확보하면서도 급증하는 트래픽에 빠르게 반응할 수 있는 균형점을 찾은 결과입니다.\n\n특히 트래픽 피크 대응에 있어서는 HPA의 반응 속도(Reactive)만으로는 부족하다고 판단했습니다. 월급날과 같은 예측 가능한 피크 시나리오에 대비하여, 저는 CronJob을 활용한 사전 스케일아웃 전략을 도입했습니다. 이를 통해 트래픽이 실제로 급증하기 전에 미리 파드를 증설하여 서비스의 안정성을 확보하고, 사용자 경험 저하를 방지할 수 있었습니다.", "answer_rewrite": "HPA 기준은 서비스의 부하 특성을 고려하여 CPU 사용률 70%로 설정했습니다. 메모리 사용률도 고려했지만, CPU 부하가 실제 요청 처리량과 더 밀접한 상관관계를 가진다고 판단했습니다.\n\n트래픽 피크 대응 방식은 두 가지로 설계했습니다. 첫째, HPA가 동적으로 대응하도록 설정했습니다. 둘째, 예측 가능한 트래픽 피크(예: 월급날 10시)에 대비하여 CronJob을 이용한 사전 스케일아웃을 운영했습니다. 이를 통해 HPA가 반응하는 시간적 지연(Latency)을 보완하고, 피크 발생 시점부터 안정적인 리소스를 확보할 수 있었습니다.", "coaching_comment": "단순히 '메모리 50%'라고 말하는 대신, 실제 경험(CPU 70%)을 언급하며 '왜 그 메트릭을 선택했는지'에 대한 근거를 제시해야 합니다."}, "latency_sec": 10.989, "in_tokens": 1244, "out_tokens": 428} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "coaching", "case_id": "c2-f-personality-star", "rep": 0, "ok": true, "coaching": {"model_answer": "캡스톤 프로젝트에서 프론트엔드 팀원과 API 스펙 해석 차이로 통합 직전에 2주 지연이 발생했던 상황이 있었습니다. 이 문제는 단순한 기술적 오해가 아닌, 커뮤니케이션 방식의 차이에서 비롯되었다고 판단했습니다. 저는 즉시 상황을 객관화하기 위해, 양측의 요구사항을 모두 반영한 OpenAPI 명세를 선행적으로 작성하고, 이를 기반으로 Mock 서버를 구축하여 프론트엔드가 병렬 개발을 진행하도록 제안했습니다. 이 행동 덕분에 개발 지연을 최소화하고, 이후 스프린트에서는 통합 이슈를 3건에서 0건으로 줄이는 성과를 냈습니다. 다만, 초기에는 제 방식만을 고집하여 팀원과의 갈등이 있었기에, 이후에는 갈등 상황 발생 시 '상대방의 관점'을 먼저 이해하려는 노력을 하고, 반드시 두 가지 이상의 대안을 함께 비교 검토하는 프로세스를 도입하여 협업의 질을 높였습니다.", "answer_rewrite": "캡스톤 프로젝트에서 프론트엔드 팀원과 API 스펙 해석이 달라 통합 직전에 2주가 밀리는 상황이 있었습니다. (Situation) 이 문제를 해결하기 위해, 저는 감정적인 충돌을 피하고 기술적 해결에 집중하고자 했습니다. (Task/Action) 먼저, 양측의 요구사항을 명확히 정리하여 OpenAPI 명세를 표준화하고, 이 명세를 기반으로 Mock 서버를 띄워 프론트엔드가 병렬로 개발할 수 있도록 제안했습니다. 그 결과, 다음 스프린트부터는 통합 이슈가 3건에서 0건으로 감소하는 가시적인 성과를 얻었습니다. (Result) 다만, 초기에는 제 방식만 고집하여 팀원과 감정적으로 충돌했던 점을 반성했습니다. 이 경험을 통해, 이후에는 의견 충돌 시 기술적 해결책 제시 이전에, 상대방의 입장을 경청하고 두 가지 이상의 대안을 함께 비교하는 방식으로 접근 방식을 개선했습니다.", "coaching_comment": "갈등 해결 과정에서 '기술적 해결책 제시'와 '커뮤니케이션 개선'을 분리하여 STAR 구조에 맞춰 서술하면 훨씬 논리적입니다."}, "latency_sec": 11.282, "in_tokens": 1027, "out_tokens": 501} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "coaching", "case_id": "c2-f-stt-messy-normal", "rep": 0, "ok": true, "coaching": {"model_answer": "초기에는 낙관적 락(Optimistic Locking)을 사용하여 동시성 문제를 해결하고자 했습니다. 하지만 타임세일과 같이 트래픽이 폭증하는 시나리오에서는 버전 충돌(Version Conflict)이 매우 빈번하게 발생했습니다. 이로 인해 애플리케이션 레벨에서 잦은 재시도(Retry)가 발생했고, 이 재시도 과정 자체가 DB에 불필요한 부하를 가중시키는 병목 현상을 초래했습니다. 따라서, 트랜잭션 시작 시점부터 동시성을 강하게 제어할 필요가 있었고, Redis를 활용한 분산 락(Distributed Lock)으로 전환했습니다. 분산 락은 충돌 발생 시 재시도 비용을 줄이고, 트랜잭션의 원자성(Atomicity)을 더 강력하게 보장하여, 최종적으로 월별 불일치 건수를 200건에서 3건 수준으로 크게 감소시키는 결과를 얻었습니다.", "answer_rewrite": "처음에는 낙관적 락을 적용했습니다. 하지만 타임세일처럼 요청이 집중되는 상황에서는 버전 충돌이 너무 빈번하게 발생했고, 이로 인해 시스템이 잦은 재시도를 반복하면서 오히려 DB 부하가 증가하는 문제가 있었습니다. 이 문제를 해결하기 위해 Redis를 이용한 분산 락으로 변경했습니다. 분산 락을 사용함으로써 동시성 제어를 더 강력하게 할 수 있었고, 그 결과 월별 데이터 불일치 건수를 200건에서 3건으로 줄일 수 있었습니다. 핵심은 트래픽 집중 시 재시도 비용을 줄이고 일관성을 확보하는 것이었습니다.", "coaching_comment": "단순히 '많이 나서'가 아닌, '왜' 그 현상이 발생했고 '어떤 메커니즘' 때문에 문제가 되었는지 기술적 원인과 트레이드오프를 명확히 설명해야 합니다."}, "latency_sec": 10.049, "in_tokens": 1001, "out_tokens": 433} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "coaching", "case_id": "c2-f-english-mixed", "rep": 0, "ok": true, "coaching": {"model_answer": "TanStack Query를 선택한 핵심 이유는 서버 상태(Server State)와 클라이언트 상태(Client State)를 명확히 분리하고, 서버 데이터 관리에 필요한 복잡한 로직을 프레임워크 레벨에서 자동화해주기 때문입니다. 기존에 Zustand로 API 호출 결과를 직접 상태에 저장했을 때는 캐시 무효화(cache invalidation) 로직이나 데이터의 신선도(staleness) 관리를 수동으로 구현해야 했고, 이 과정에서 버그 발생률이 높았습니다. TanStack Query는 `staleTime` 설정을 통해 데이터의 신선도를 정의하고, `invalidateQueries`를 통해 필요한 데이터만 효율적으로 갱신할 수 있게 해줍니다. 또한, 동일한 Query Key에 대한 중복 요청을 자동으로 제거(deduplication)해주어 불필요한 네트워크 부하를 줄여주어 성능 최적화에 크게 기여했습니다.", "answer_rewrite": "기존에는 Zustand를 사용하여 API 호출 결과를 상태로 관리했는데, 이 방식은 서버 상태 관리를 직접 구현해야 했기 때문에 캐시 무효화(cache invalidation)나 데이터의 신선도(staleness) 관리를 수동으로 짜야 했고, 이로 인해 버그가 자주 발생했습니다. TanStack Query로 전환하면서 이 문제를 해결할 수 있었습니다. 구체적으로, `staleTime`을 화면별로 다르게 설정하여 데이터의 신선도를 정밀하게 제어할 수 있게 되었고, `mutation` 후 `invalidateQueries`를 사용해 필요한 목록만 선별적으로 갱신했습니다. 가장 체감한 개선점은 동일한 Query Key 요청에 대한 deduplication 덕분에 네트워크 요청이 약 40% 정도 줄어들어 성능이 향상된 것입니다.", "coaching_comment": "기술 선택의 이유를 설명할 때, '왜' 필요한지(기대 신호)를 먼저 언급하고, 그 후에 '어떻게' 적용했는지(구체적 경험)를 연결하면 훨씬 논리적인 답변이 됩니다."}, "latency_sec": 10.417, "in_tokens": 982, "out_tokens": 452} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "coaching", "case_id": "c2-f2-frontend-a11y-strong", "rep": 0, "ok": true, "coaching": {"model_answer": "무한 스크롤 구현 시 접근성 측면에서 가장 중요하게 고려한 부분은 키보드 및 스크린리더 사용자가 콘텐츠 로딩 상태를 인지하고 상호작용할 수 있도록 하는 것이었습니다. 초기에는 IntersectionObserver만 사용했을 때, 키보드 사용자가 페이지를 탐색할 때 로딩 상태나 새로 추가된 콘텐츠의 존재를 인지하기 어려웠습니다. 이를 해결하기 위해 두 가지 전략을 적용했습니다. 첫째, 일정 간격(예: 20개)마다 '더 보기'와 같은 명시적인 트리거 버튼을 배치하여 키보드 사용자가 명확하게 상호작용할 수 있도록 했습니다. 둘째, 새로 로드되는 콘텐츠 영역에 `aria-live=\"polite\"`를 적용하여 스크린리더가 콘텐츠 추가를 부드럽게 알리도록 했습니다. 또한, 콘텐츠가 로드될 때 포커스를 새로 추가된 첫 번째 요소로 이동시켜 사용자가 즉시 새로운 내용을 인지하고 탐색을 시작할 수 있도록 했습니다. 이러한 개선을 통해 Lighthouse 접근성 점수를 72점에서 89점으로 향상시킬 수 있었습니다.", "answer_rewrite": "처음 IntersectionObserver만 사용했을 때, 키보드 사용자가 콘텐츠 로딩 상태를 인지하기 어렵다는 접근성 문제를 발견했습니다. 이를 해결하기 위해 하이브리드 방식으로 접근했습니다. 첫째, 20개 단위로 '더 보기' 버튼을 배치하여 키보드 사용자가 명확하게 상호작용할 수 있는 지점을 제공했습니다. 둘째, 새로 불러온 콘텐츠 영역에 `aria-live=\"polite\"`를 적용하여 스크린리더가 콘텐츠 추가를 자연스럽게 알리도록 했습니다. 마지막으로, 콘텐츠 로드 시 포커스를 새로 추가된 첫 게시글로 이동시켜 사용자가 즉시 새로운 내용을 탐색할 수 있도록 했습니다. 이 과정을 통해 Lighthouse 접근성 점수를 72점에서 89점으로 개선할 수 있었습니다.", "coaching_comment": "접근성 이슈를 발견한 '문제 정의'와 적용한 '구체적인 기술적 해결책'을 STAR 구조에 맞춰 명확히 분리하여 설명하면 좋습니다."}, "latency_sec": 11.871, "in_tokens": 1210, "out_tokens": 489} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "coaching", "case_id": "c2-f2-dba-vague-weak", "rep": 0, "ok": true, "coaching": {"model_answer": "gh-ost를 도입한 주된 이유는 서비스 운영 중 발생하는 스키마 변경(Schema Change)으로 인한 다운타임 및 락(Lock) 이슈를 근본적으로 제거하기 위함이었습니다. 특히, 저희 환경처럼 대용량 트래픽을 처리하는 환경에서는 `ALTER TABLE` 시 발생하는 쓰기 락(Write Lock)이 서비스 장애로 직결될 위험이 높습니다. gh-ost는 트리거를 사용하지 않고 백그라운드에서 복제본을 생성하여 변경사항을 적용하므로, 서비스 중단 없이 안전하게 컬럼 추가 등의 변경을 수행할 수 있었습니다.\n\n운영 시 주의했던 핵심 포인트는 **부하 제어**와 **컷오버 시점 관리**였습니다. gh-ost는 변경 작업 시 시스템 부하를 유발할 수 있으므로, 변경 작업의 진행 속도(Rate)를 모니터링하며 트래픽 피크 타임을 피해 진행했습니다. 또한, 컷오버(Cutover) 시점에 데이터 동기화 지연이 발생하지 않도록, 변경 작업의 진행 상황과 리플리케이션 딜레이를 면밀히 체크하며 안정적인 전환을 유도했습니다.", "answer_rewrite": "gh-ost를 도입한 이유는 서비스 운영 중 발생하는 스키마 변경 시 발생하는 락(Lock)으로 인한 장애를 방지하기 위해서입니다. 저희는 대용량 트래픽 환경에서 `ALTER TABLE` 시 발생하는 쓰기 락이 치명적이라고 판단했습니다.\n\n운영 시에는 두 가지에 중점을 두었습니다. 첫째, **부하 제어**입니다. gh-ost가 백그라운드에서 작업을 수행하며 부하를 줄 수 있기 때문에, 작업 진행 속도를 모니터링하며 트래픽이 적은 시간대에 진행했습니다. 둘째, **컷오버 안정성 확보**입니다. 변경 작업이 완료되기 전까지 데이터 동기화 지연이 발생하지 않도록, 리플리케이션 딜레이를 지속적으로 체크하며 안전하게 컷오버를 진행했습니다.", "coaching_comment": "단순히 '조심해서 썼다'가 아니라, 어떤 위험(락/부하)을 피하기 위해 어떤 구체적인 운영 전략(부하 제어/딜레이 체크)을 사용했는지 명시해야 합니다."}, "latency_sec": 12.238, "in_tokens": 1153, "out_tokens": 521} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "coaching", "case_id": "c2-f2-backend-fact-mismatch", "rep": 0, "ok": true, "coaching": {"model_answer": "정산 배치 성능 개선은 병목 지점을 정확히 진단하고, 각 기술적 조치가 어떤 기여를 했는지 분리하여 설명하는 것이 중요합니다. 제가 진행한 개선은 크게 세 가지 축으로 진행되었습니다. 첫째, **QueryDSL 튜닝**을 통해 복잡한 정산 로직의 SQL 쿼리 자체의 비효율성을 제거했습니다. 둘째, 대량 데이터 처리 시 발생하는 메모리/트랜잭션 부하를 줄이기 위해 **청크(Chunk) 단위 처리**를 적용하여 한 번에 처리하는 데이터의 크기를 최적화했습니다. 셋째, 데이터베이스 레벨에서 조회 성능을 극대화하기 위해 정산에 사용되는 주요 필드들에 대한 **인덱스를 재설계**했습니다. 이 세 가지 조치를 통해 기존 5시간 소요되던 배치를 40분으로 단축할 수 있었습니다. 특히, 단순히 Spark로 옮긴 것이 아니라, 기존 RDBMS 환경 내에서 쿼리 최적화와 처리 로직 개선을 병행한 것이 핵심이었습니다.", "answer_rewrite": "정산 배치 성능 개선을 위해 세 가지 주요 병목 지점에 집중하여 개선을 진행했습니다. 첫째, **QueryDSL 튜닝**을 통해 정산 로직에서 발생하는 복잡한 Join 및 조건 검색의 비효율성을 개선하여 쿼리 실행 시간을 단축했습니다. 둘째, 대량 데이터 처리 시 발생하는 트랜잭션 부하를 줄이기 위해 데이터를 **청크(Chunk) 단위로 나누어 처리**하도록 로직을 수정했습니다. 셋째, 정산 데이터 조회 시 발생하는 I/O 병목을 해소하기 위해 관련 테이블의 **인덱스를 재설계**했습니다. 이 세 가지 조치를 종합적으로 적용한 결과, 기존 5시간 걸리던 배치를 40분으로 단축하는 성과를 얻었습니다.", "coaching_comment": "단순히 '빨라졌다'가 아니라, 어떤 기술적 조치(QueryDSL, 청크, 인덱스)가 어떤 역할을 했는지 구체적인 기여도를 명시해야 합니다."}, "latency_sec": 12.259, "in_tokens": 1361, "out_tokens": 475} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "coaching", "case_id": "c2-f2-personality-generic-weak", "rep": 0, "ok": true, "coaching": {"model_answer": "제가 가진 가장 큰 강점은 '문제 해결을 위한 끈기와 책임감'입니다. 인프라 환경은 예기치 않은 장애나 복잡한 이슈가 발생하기 쉬운데, 저는 이러한 상황에서 포기하지 않고 근본 원인을 파악하는 끈기를 보여왔습니다. 예를 들어, [구체적인 인프라 이슈 상황]에서 발생한 성능 저하 문제를 해결할 때, 단순히 임시 조치에 그치지 않고 로그 분석, 모니터링 데이터 검토 등을 통해 [구체적인 원인]을 찾아내고, 이를 [구체적인 해결 방안]으로 적용하여 최종적으로 [정량적 개선 결과]를 달성했습니다. 이러한 집요함과 책임감은 안정적인 시스템 운영에 핵심적인 기여를 할 것이라고 확신합니다.", "answer_rewrite": "저의 강점은 맡은 인프라 영역에 대한 '높은 책임감과 문제 해결을 위한 끈기'입니다. 단순히 '성실하다'는 표현보다는, 제가 맡은 시스템이 안정적으로 동작하도록 끝까지 파고드는 실행력으로 설명드리고 싶습니다. 예를 들어, [만약 관련 경험이 있다면 STAR 구조로 설명]. 만약 구체적인 경험을 말하기 어렵다면, '저는 장애 발생 시, 원인을 찾을 때까지 관련 로그와 모니터링 툴을 끈기 있게 분석하고, 관련 팀과 적극적으로 소통하여 해결책을 도출해내는 과정을 습관화하고 있습니다'와 같이 행동 방식을 구체화하여 답변하는 것이 좋습니다.", "coaching_comment": "추상적인 성격적 장점 대신, 직무와 연결된 '구체적인 행동'과 '결과'를 반드시 포함해야 합니다."}, "latency_sec": 9.038, "in_tokens": 923, "out_tokens": 392} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "coaching", "case_id": "c2-f2-offtopic-weak", "rep": 0, "ok": true, "coaching": {"model_answer": "Kafka를 선택한 주된 이유는 저희 시스템이 요구하는 **높은 처리량(High Throughput)**과 **데이터 순서 보장(Ordering Guarantee)** 때문입니다. 특히, Kafka는 로그 기반의 분산 스트리밍 플랫폼으로 설계되어 대량의 메시지를 지속적으로 안정적으로 처리하는 데 최적화되어 있습니다. RabbitMQ는 주로 메시지 큐(Message Queue) 패턴에 강점을 가지며, 복잡한 라우팅이나 QoS(Quality of Service) 설정에 유연하지만, 대규모 데이터 스트림 처리량이나 영속성(Persistence) 관점에서는 Kafka가 더 적합하다고 판단했습니다. 또한, Kafka의 리플레이(Replay) 기능은 과거 데이터를 재처리하여 시스템 장애 시 복구하거나 새로운 로직을 테스트하는 데 필수적이어서 이 부분을 중요하게 고려했습니다.", "answer_rewrite": "제가 Kafka를 선택한 이유는 저희 서비스의 핵심 요구사항인 **대용량 데이터 스트림 처리**와 **데이터의 순서 보장** 때문입니다. RabbitMQ도 훌륭한 메시징 시스템이지만, 저희는 초당 수만 건 이상의 트래픽을 안정적으로 처리해야 했고, Kafka는 로그 기반 아키텍처 덕분에 이러한 높은 처리량을 보장할 수 있었습니다. 또한, Kafka의 분산 로그 특성상 특정 시점의 데이터를 다시 읽어와 재처리(Replay)하는 기능이 필요한데, 이 기능은 저희 시스템의 안정성과 디버깅에 매우 중요하다고 판단하여 Kafka를 채택했습니다.", "coaching_comment": "기술 질문에는 '왜' 선택했는지에 대한 기술적 근거(요구사항 매칭)를 명확히 제시해야 합니다."}, "latency_sec": 8.765, "in_tokens": 943, "out_tokens": 377} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "coaching", "case_id": "c2-f2-dk-no-experience", "rep": 0, "ok": true, "coaching": {"model_answer": "PodDisruptionBudget (PDB)은 클러스터 운영 중 발생하는 '자발적 중단(Voluntary Disruption)' 상황에서 애플리케이션의 가용성(Availability)을 보장하기 위해 사용됩니다. 예를 들어, 노드 업그레이드나 노드 드레인(Node Drain)과 같이 사용자가 의도적으로 파드를 종료해야 하는 상황이 발생할 때, PDB는 '최소한 몇 개의 파드는 항상 실행 중이어야 한다'는 제약 조건을 정의합니다. 만약 노드 드레인으로 인해 정의된 최소 개수보다 많은 파드가 동시에 종료될 위험이 있다면, Kubernetes는 해당 작업을 지연시키거나 경고를 발생시켜 서비스 중단을 방지합니다. 즉, PDB는 운영 안정성을 위한 '최소 서비스 수준 보장' 메커니즘입니다.", "answer_rewrite": "직접 사용해보지 않은 경험은 있지만, PDB의 목적을 설명드리자면, 이는 클러스터의 **자발적 중단(Voluntary Disruption)** 시 애플리케이션의 가용성을 보장하기 위해 사용됩니다. 예를 들어, 노드 업그레이드나 노드 드레인 작업 시, PDB는 '특정 애플리케이션의 파드 중 최소 N개는 항상 실행 상태를 유지해야 한다'는 제약을 설정합니다. 이 제약 덕분에, 시스템이 의도적으로 파드를 종료하려 할 때도 서비스의 핵심 기능이 중단되는 것을 방지할 수 있습니다.", "coaching_comment": "경험 부족을 인정하기보다, 개념 자체를 명확히 정의하고 핵심 용어(자발적 중단, 가용성)를 사용하여 답변의 깊이를 보여주세요."}, "latency_sec": 8.989, "in_tokens": 925, "out_tokens": 389} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "coaching", "case_id": "c2-f2-integrated-tradeoff-strong", "rep": 0, "ok": true, "coaching": {"model_answer": "Last-Write-Wins (LWW)를 선택한 주된 이유는 비즈니스 요구사항과 운영 비용 측면에서 가장 합리적인 트레이드오프였기 때문입니다. 저희 서비스의 특성상, 일정 공유는 대부분 '한 사용자가 주도적으로 편집하고 나머지는 조회'하는 패턴이 지배적입니다. 로그 분석 결과, 실제 동시 편집 충돌 빈도는 월 2~3건으로 매우 낮았습니다. 따라서, 복잡한 CRDT 구현으로 인한 오버헤드(예: Yjs 도입 시 80KB 번들 증가 및 서버 구조 변경)를 감수하는 것보다, 충돌 발생 시 데이터 손실 위험을 최소화하는 것이 우선이었습니다. LWW를 적용하되, 데이터 손실에 대한 대비책으로 이전 버전을 7일간 보관하는 복구 메커니즘을 추가하여 사용자 경험의 안정성을 확보했습니다. 이는 낮은 충돌 빈도와 구현 복잡도를 고려했을 때 최적의 균형점이라고 판단했습니다.", "answer_rewrite": "저희 서비스의 사용 패턴을 분석했을 때, 대부분의 사용자가 일정을 단독으로 편집하고 나머지는 조회하는 경우가 많았습니다. 실제로 로그를 분석한 결과, 심각한 동시 편집 충돌은 월 2~3건에 불과했습니다. CRDT(예: Yjs)를 검토했지만, 프로토타입 테스트 결과 80KB의 번들 증가와 서버 구조 변경이라는 상당한 비용이 발생했습니다. 따라서, 이 낮은 충돌 빈도를 고려했을 때, 복잡한 CRDT 도입의 이점이 크지 않다고 판단했습니다. 대신 LWW를 적용하되, 데이터 유실 위험을 방지하기 위해 충돌 발생 시 이전 버전을 7일간 보관하는 복구 기능을 구현하여 안정성을 확보했습니다.", "coaching_comment": "단순히 '비용 대비 효과가 낮다'고 판단하기보다, '낮은 충돌 빈도'라는 정량적 근거와 '복구 메커니즘'이라는 대안을 제시하며 트레이드오프를 설명하는 것이 좋습니다."}, "latency_sec": 11.992, "in_tokens": 1313, "out_tokens": 474} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "questions", "case_id": "q-backend-tech", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "결제 콜백 지연으로 중복 주문을 해결할 때, 멱등 키를 어떻게 설계하고 적용했는지 구체적인 로직을 설명해 주세요.", "job_category": "BACKEND", "target_evidence": "결제 승인 콜백 지연 시 중복 주문 발생 문제: 멱등 키 테이블 + Transactional Outbox 로 해결, 중복 주문 0건 달성", "expected_signal": "멱등 키의 범위, 검증 시점, 그리고 트랜잭션 경계 내에서의 동작 방식을 명확히 설명할 수 있어야 합니다."}, {"category": "TECH_CHOICE", "question": "모놀리식에서 MSA로 전환하며 주문 서비스를 분리했을 때, Kafka 이벤트 파이프라인 설계 시 고려했던 가장 중요한 트레이드오프는 무엇이었나요?", "job_category": "BACKEND", "target_evidence": "모놀리식 → MSA 전환: 주문 서비스를 별도 서비스로 분리, DB 분리(PostgreSQL) 및 Kafka 기반 이벤트 발행/구독 구조 도입.", "expected_signal": "분산 시스템 설계 시 발생 가능한 일관성, 지연 시간, 복잡성 등의 상충 관계를 이해하고 있음을 보여주어야 합니다."}, {"category": "PROJECT_DEEP_DIVE", "question": "실시간 재고 동기화 프로젝트에서 낙관적 락을 분산 락으로 전환한 이유와, 사용한 분산 락 구현 방식(예: Redis 기반)에 대해 설명해 주세요.", "job_category": "BACKEND", "target_evidence": "Redis 기반 재고 캐시 + DB write-behind, 동시성 제어(낙관적 락 → 분산 락 전환)", "expected_signal": "락 메커니즘의 필요성을 정확히 파악하고, Redis를 활용한 분산 락 구현의 세부적인 동작 원리를 설명할 수 있어야 합니다."}, {"category": "CS_FUNDAMENTAL", "question": "PostgreSQL을 사용하며 정산 배치 성능을 개선할 때, QueryDSL 튜닝과 인덱스 재설계 외에 고려했던 데이터베이스 레벨의 최적화 포인트가 있나요?", "job_category": "BACKEND", "target_evidence": "정산 배치 성능 개선: 5시간 → 40분 (QueryDSL 튜닝, 청크 단위 처리, 인덱스 재설계)", "expected_signal": "단순 쿼리 튜닝을 넘어, 트랜잭션 격리 수준, 병렬 처리, 또는 DB 아키텍처 관점의 이해도를 보여주어야 합니다."}, {"category": "BEHAVIORAL", "question": "대용량 트래픽 환경에서 데이터 정합성을 지키는 서버를 만드는 것에 관심이 있다고 하셨는데, 가장 까다로웠던 정합성 이슈와 그것을 해결하기 위해 취한 본인만의 접근 방식은 무엇인가요?", "job_category": "BACKEND", "target_evidence": "대용량 트래픽에서도 데이터 정합성을 지키는 서버를 만드는 데 관심이 많습니다.", "expected_signal": "단순히 기술을 적용한 것이 아니라, 문제 정의부터 해결책 도출까지의 사고 과정(STAR)을 구체적인 행동과 함께 설명해야 합니다."}], "latency_sec": 26.888, "in_tokens": 2869, "out_tokens": 797} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "questions", "case_id": "q-frontend-repo", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "travel-planner에서 react-window를 도입하며 INP를 480ms에서 120ms로 개선했는데, 가상화 구현 시 가장 까다로웠던 렌더링 이슈는 무엇이었나요?", "job_category": "FRONTEND", "target_evidence": "일정 타임라인: 항목 2천 개 이상일 때 스크롤 끊김 → react-window 가상화 도입 (커밋 메시지: \"virtualize timeline, INP 480ms -> 120ms\")", "expected_signal": "단순히 라이브러리를 사용한 것이 아니라, 렌더링 최적화 과정에서 발생한 구체적인 성능 병목 지점과 해결 방식을 설명할 수 있어야 합니다."}, {"category": "TECH_CHOICE", "question": "오프라인 편집 시 Dexie를 사용해 낙관적 업데이트를 구현했는데, 충돌 해결 전략으로 last-write-wins를 선택한 구체적인 이유와 한계점은 무엇인가요?", "job_category": "FRONTEND", "target_evidence": "오프라인 편집: IndexedDB(Dexie) 에 낙관적 업데이트를 저장 후 온라인 복귀 시 동기화. 충돌은 last-write-wins (TODO 주석: \"CRDT 검토 필요\")", "expected_signal": "선택한 전략의 장단점을 명확히 이해하고 있으며, CRDT 검토가 필요하다고 언급한 이유를 기술적으로 설명할 수 있어야 합니다."}, {"category": "PROJECT_DEEP_DIVE", "question": "Kakao Map SDK에서 마커 500개를 클러스터링할 때 useMemo로 좌표 변환을 캐싱했는데, 이 캐싱이 성능에 미친 영향과 의존성 관리는 어떻게 했는지 궁금합니다.", "job_category": "FRONTEND", "target_evidence": "지도 마커 렌더링: Kakao Map SDK 마커 500개를 클러스터링, useMemo 로 좌표 변환 캐싱", "expected_signal": "useMemo의 동작 원리를 이해하고 있으며, 불필요한 재계산을 막기 위해 의존성 배열을 어떻게 설계했는지 구체적인 코드를 바탕으로 설명할 수 있어야 합니다."}, {"category": "TECH_CHOICE", "question": "S3에 이미지 업로드를 presigned URL로 직접 처리했는데, 이 방식이 일반적인 API 게이트웨이 경유 방식 대비 보안 및 성능 측면에서 어떤 이점을 제공하나요?", "job_category": "FRONTEND", "target_evidence": "이미지 업로드: presigned URL 로 S3 직접 업로드, 클라이언트에서 WebP 변환", "expected_signal": "클라이언트와 스토리지 간의 직접 통신이 가지는 네트워크 오버헤드 감소 및 인증/인가 흐름에 대한 이해도를 보여주어야 합니다."}, {"category": "BEHAVIORAL", "question": "Lighthouse 점수를 68에서 91로 올린 PR #57에서, 성능 개선을 위해 가장 먼저 집중했던 영역과 그 과정에서 발생한 기술적 난관은 무엇이었나요?", "job_category": "FRONTEND", "target_evidence": "Lighthouse 성능 점수 68 → 91 (PR #57 설명)", "expected_signal": "성능 최적화에 대한 체계적인 접근 방식(측정 -> 가설 설정 -> 실행 -> 재측정)을 보여주고, 단순히 코드를 수정한 것이 아닌 근본적인 원인을 해결했음을 설명해야 합니다."}], "latency_sec": 22.767, "in_tokens": 2671, "out_tokens": 854} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "questions", "case_id": "q-infra-dba-multi", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "PostgreSQL RDS에서 슬로우 쿼리 p95를 2.3초에서 180ms로 개선하셨는데, 복합 인덱스 재설계 시 어떤 쿼리 패턴을 가장 중점적으로 분석하셨나요?", "job_category": "DBA", "target_evidence": "PostgreSQL 14 (RDS) 운영: 슬로우 쿼리 p95 2.3초 → 180ms (복합 인덱스 재설계, autovacuum 튜닝, 파티셔닝으로 거래내역 테이블 월 단위 분할)", "expected_signal": "단순 튜닝이 아닌, 실제 데이터 접근 패턴 분석을 통해 병목 지점을 정확히 파악했는지 확인합니다."}, {"category": "TECH_CHOICE", "question": "EKS 클러스터 운영 시 HPA 기준을 CPU 70%로 설정하셨는데, 트래픽 피크 시점에 CPU 외에 고려한 다른 메트릭이나 스케일링 정책이 있었나요?", "job_category": "INFRA", "target_evidence": "HPA 기준을 CPU 70% 로 설정, 트래픽 피크(월급날 10시) 대비 사전 스케일아웃 CronJob 운영", "expected_signal": "CPU 외의 리소스(메모리, 요청 수 등)를 고려한 다차원적인 스케일링 전략을 이해하고 있는지 확인합니다."}, {"category": "PROJECT_DEEP_DIVE", "question": "ArgoCD GitOps 도입으로 배포 리드타임을 1일에서 30분으로 줄이셨는데, 이 과정에서 발생한 가장 까다로운 동기화 이슈는 무엇이었나요?", "job_category": "INFRA", "target_evidence": "ArgoCD GitOps 도입으로 배포 리드타임 1일 → 30분", "expected_signal": "CI/CD 파이프라인 구축 시 발생하는 실제 운영상의 복잡한 문제 해결 경험을 확인합니다."}, {"category": "CS_FUNDAMENTAL", "question": "RDS 스토리지 풀로 쓰기 중단 장애 시, CloudWatch 알람과 오토스케일링을 적용하셨는데, 이 장애의 근본 원인인 '스토리지 풀'의 동작 원리를 어떻게 이해하고 계신가요?", "job_category": "DBA", "target_evidence": "장애: 2024.03 RDS 스토리지 풀로 쓰기 중단 40분 → CloudWatch 알람 + 스토리지 오토스케일링 적용", "expected_signal": "단순히 알람을 설정한 것이 아니라, 데이터베이스 인프라의 내부 동작 메커니즘을 깊이 이해하고 있는지 확인합니다."}, {"category": "BEHAVIORAL", "question": "Terraform으로 VPC, RDS, EKS 모듈화를 진행하셨는데, 환경별 workspace 분리 시 발생할 수 있는 잠재적 설정 충돌을 어떻게 방지하셨나요?", "job_category": "INFRA", "target_evidence": "Terraform 으로 VPC·RDS·EKS 모듈화, 환경별(dev/stg/prod) workspace 분리", "expected_signal": "IaC(Infrastructure as Code) 구현 시 발생 가능한 설계적 위험 요소를 예측하고 선제적으로 방어하는 능력을 확인합니다."}, {"category": "BEHAVIORAL", "question": "4년차 플랫폼 엔지니어로서, 현재 운영 중인 인프라/DB 환경에서 가장 개선하고 싶은 부분은 무엇이며, 그 이유는 무엇인가요?", "job_category": "INFRA", "target_evidence": "경력: (주)핀링크 — 플랫폼 엔지니어 (2022.01 ~ 현재)", "expected_signal": "현재 경험을 바탕으로 한 비판적 사고와 지속적인 학습 의지, 그리고 직무에 대한 주도적인 관심을 확인합니다."}], "latency_sec": 24.691, "in_tokens": 2663, "out_tokens": 961} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "questions", "case_id": "q-personality-coverletter", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "알림 봇 DB를 SQLite에서 PostgreSQL로 이전하면서 겪은 동시 쓰기 락 문제를 구체적으로 어떻게 해결하셨나요?", "job_category": "BACKEND", "target_evidence": "알림 봇 DB를 SQLite 로 시작했다가 동시 쓰기 락 문제로 알림이 중복 발송되었습니다. 원인을 찾는 데 3일이 걸렸고, PostgreSQL 로 이전하며 트랜잭션 격리 수준을 공부하게 됐습니다.", "expected_signal": "단순히 DB를 바꾼 것이 아니라, 트랜잭션 격리 수준(Isolation Level)을 이해하고 적용하여 동시성 문제를 해결했는지 확인."}, {"category": "BEHAVIORAL", "question": "캡스톤 프로젝트에서 API 스펙 해석 차이로 지연되었을 때, OpenAPI 명세 작성과 Mock 서버 제안의 구체적인 행동 과정은 무엇이었나요?", "job_category": "BACKEND", "target_evidence": "저는 OpenAPI 명세를 먼저 작성하고 Mock 서버를 띄워 프론트가 병렬로 개발하도록 제안했고, 이후 스프린트에서는 통합 이슈가 3건에서 0건으로 줄었습니다.", "expected_signal": "갈등 상황에서 기술적 해결책을 제시하고, 그 과정에서 팀원과의 협업을 어떻게 이끌어냈는지 STAR 기법으로 설명하는지 확인."}, {"category": "TECH_CHOICE", "question": "SQLite에서 PostgreSQL로 마이그레이션하며 트랜잭션 격리 수준을 공부하셨는데, 어떤 격리 수준이 알림 중복 발송 문제에 가장 적합하다고 판단하셨나요?", "job_category": "BACKEND", "target_evidence": "알림 봇 DB를 SQLite 로 시작했다가 동시 쓰기 락 문제로 알림이 중복 발송되었습니다. 원인을 찾는 데 3일이 걸렸고, PostgreSQL 로 이전하며 트랜잭션 격리 수준을 공부하게 됐습니다.", "expected_signal": "특정 DB 환경에서 발생한 문제에 대해 트랜잭션 격리 수준의 개념적 이해와 실제 적용 방안을 명확히 설명하는지 확인."}, {"category": "BEHAVIORAL", "question": "협업 시 초반에 본인의 방식이 옳다고 고집하여 팀원과 감정이 상했던 경험에 대해, 이후 어떤 구체적인 변화를 주셨나요?", "job_category": "BACKEND", "target_evidence": "다만 초반에 제 방식이 옳다고 고집해 팀원과 감정이 상한 적도 있어, 이후에는 결정 전에 대안 두 가지를 함께 비교하는 방식으로 바꿨습니다.", "expected_signal": "실패 경험을 통해 얻은 교훈을 행동 변화로 연결하고, 이를 통해 팀워크와 커뮤니케이션 방식을 어떻게 개선했는지 확인."}, {"category": "PROJECT_DEEP_DIVE", "question": "사용자 800명이 쓰는 알림 봇 운영 경험에서, '멈추지 않는 서비스'를 위해 크롤러 장애 발생 시 어떤 예외 처리 로직을 설계하셨나요?", "job_category": "BACKEND", "target_evidence": "학부 동아리에서 학사 공지 알림 봇을 만들며 사용자 800명이 매일 쓰는 서비스를 운영해 본 경험이 있습니다. 새벽에 크롤러가 멈춰 공지가 누락됐을 때 동아리원들의 항의를 직접 받으며, 기능보다 '멈추지 않는 서비스'가 신뢰를 만든다는 것을 배웠습니다.", "expected_signal": "단순히 재시도(Retry)를 넘어, 장애 발생 시 서비스 신뢰도를 유지하기 위한 구체적인 모니터링/복구 메커니즘을 설계했는지 확인."}], "latency_sec": 23.597, "in_tokens": 2654, "out_tokens": 905} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "questions", "case_id": "q-long-context-p90", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "MSA 전환 시 주문 서비스를 분리하며 Kafka 이벤트 파이프라인을 설계하셨는데, 이벤트 발생 시 데이터 정합성을 보장하기 위해 어떤 메커니즘을 고려하셨나요?", "job_category": "BACKEND", "target_evidence": "모놀리식 → MSA 전환: 주문 서비스를 별도 서비스로 분리, DB 분리(PostgreSQL) 및 Kafka 기반 이벤트 발행/구독 구조 도입.", "expected_signal": "이벤트 발행/구독 과정에서 발생할 수 있는 데이터 불일치 상황에 대한 구체적인 설계적 고민과 해결책을 설명할 수 있어야 합니다."}, {"category": "TECH_CHOICE", "question": "실시간 재고 동기화 프로젝트에서 낙관적 락을 분산 락으로 전환하셨는데, 분산 락 구현 시 사용한 기술과 그 선택의 기술적 근거는 무엇인가요?", "job_category": "BACKEND", "target_evidence": "Redis 기반 재고 캐시 + DB write-behind, 동시성 제어(낙관적 락 → 분산 락 전환)", "expected_signal": "분산 락 구현 시 발생 가능한 문제점(예: 데드락, 네트워크 지연)을 인지하고, 선택한 기술의 장단점을 명확히 설명해야 합니다."}, {"category": "PROJECT_DEEP_DIVE", "question": "GitHub 레포의 주문 관리 어드민에서 IndexedDB를 사용해 오프라인 편집을 구현하셨는데, 충돌 해결 전략으로 last-write-wins를 선택한 구체적인 이유는 무엇인가요?", "job_category": "BACKEND", "target_evidence": "오프라인 편집: IndexedDB(Dexie) 에 낙관적 업데이트를 저장 후 온라인 복귀 시 동기화. 충돌은 last-write-wins (TODO 주석: \"CRDT 검토 필요\")", "expected_signal": "last-write-wins가 해당 도메인(주문 관리)의 요구사항을 어떻게 충족시키는지, 그리고 CRDT 검토가 필요한 이유를 기술적으로 설명할 수 있어야 합니다."}, {"category": "BEHAVIORAL", "question": "자기소개서에서 '멈추지 않는 서비스'의 중요성을 언급하셨는데, 동아리 알림 봇에서 크롤러가 멈췄을 때, 재발 방지를 위해 어떤 시스템적 개선을 시도하셨나요?", "job_category": "BACKEND", "target_evidence": "새벽에 크롤러가 멈춰 공지가 누락됐을 때 동아리원들의 항의를 직접 받으며, 기능보다 '멈추지 않는 서비스'가 신뢰를 만든다는 것을 배웠습니다.", "expected_signal": "단순한 임시 조치가 아닌, 장애 예방 및 모니터링 관점에서 구체적인 시스템적 개선 행동(예: 재시도 로직, 알림)을 설명해야 합니다."}, {"category": "TECH_CHOICE", "question": "자기소개서에서 SQLite 사용 시 동시 쓰기 락 문제로 알림이 중복 발송된 경험이 있는데, PostgreSQL로 이전하며 트랜잭션 격리 수준을 공부하셨다면, 어떤 수준을 선택하셨고 그 이유는 무엇인가요?", "job_category": "BACKEND", "target_evidence": "알림 봇 DB를 SQLite 로 시작했다가 동시 쓰기 락 문제로 알림이 중복 발송되었습니다. 원인을 찾는 데 3일이 걸렸고, PostgreSQL 로 이전하며 트랜잭션 격리 수준을 공부하게 됐습니다.", "expected_signal": "선택한 격리 수준(Isolation Level)이 해당 비즈니스 로직(알림 발송)의 데이터 정합성 요구사항을 어떻게 만족시키는지 설명할 수 있어야 합니다."}], "latency_sec": 29.869, "in_tokens": 4007, "out_tokens": 915} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "questions", "case_id": "q2-backend-integrated", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "결제 콜백 지연 시 중복 주문 문제를 멱등 키와 Outbox 패턴으로 해결하셨는데, 이 두 패턴을 적용할 때 발생한 가장 까다로운 동시성 이슈는 무엇이었나요?", "job_category": "BACKEND", "target_evidence": "결제 승인 콜백 지연 시 중복 주문 발생 문제: 멱등 키 테이블 + Transactional Outbox 로 해결, 중복 주문 0건 달성", "expected_signal": "패턴 적용 과정에서 발생한 구체적인 기술적 난제와 이를 해결하기 위한 본인의 심층적인 설계/구현 방식을 설명할 수 있어야 합니다."}, {"category": "TECH_CHOICE", "question": "MSA 전환 시 주문 서비스를 분리하고 Kafka를 도입하셨는데, 주문 서비스 간의 데이터 정합성을 보장하기 위해 Kafka 외에 고려했던 다른 동기화 메커니즘이 있었나요?", "job_category": "BACKEND", "target_evidence": "모놀리식 → MSA 전환: 주문 서비스를 별도 서비스로 분리, DB 분리(PostgreSQL) 및 Kafka 기반 이벤트 발행/구독 구조 도입.", "expected_signal": "이벤트 기반 아키텍처의 한계를 이해하고, 데이터 정합성 확보를 위해 다른 대안(예: 2PC, Saga 패턴 등)을 비교 분석한 경험이 있어야 합니다."}, {"category": "PROJECT_DEEP_DIVE", "question": "실시간 재고 동기화 프로젝트에서 낙관적 락에서 분산 락으로 전환하셨는데, Redis를 활용한 분산 락 구현 시 발생한 성능 저하 또는 데드락 방지 로직은 어떻게 설계하셨나요?", "job_category": "BACKEND", "target_evidence": "Redis 기반 재고 캐시 + DB write-behind, 동시성 제어(낙관적 락 → 분산 락 전환)", "expected_signal": "분산 락 구현의 세부 메커니즘(예: RedLock 알고리즘의 변형, 타임아웃 처리 등)을 이해하고 실제 적용 시 발생한 트레이드오프를 설명할 수 있어야 합니다."}, {"category": "BEHAVIORAL", "question": "대용량 트래픽 환경에서 데이터 정합성을 지키는 서버를 만드는 것에 관심이 있다고 하셨는데, 가장 중요하게 생각하는 '정합성'의 정의는 무엇이며, 이를 위해 어떤 개발 원칙을 고수하시나요?", "job_category": "BACKEND", "target_evidence": "대용량 트래픽에서도 데이터 정합성을 지키는 서버를 만드는 데 관심이 많습니다.", "expected_signal": "단순히 기술적 구현을 넘어, 비즈니스 관점에서 데이터 정합성을 어떻게 정의하고, 개발 프로세스에 어떻게 반영하는지 철학적인 관점을 보여주어야 합니다."}, {"category": "TECH_CHOICE", "question": "정산 배치 성능 개선 시 QueryDSL 튜닝과 인덱스 재설계를 하셨는데, 이 중 어떤 부분이 가장 큰 병목이었으며, 튜닝 과정에서 가장 먼저 확인한 성능 지표는 무엇이었나요?", "job_category": "BACKEND", "target_evidence": "정산 배치 성능 개선: 5시간 → 40분 (QueryDSL 튜닝, 청크 단위 처리, 인덱스 재설계)", "expected_signal": "성능 최적화 과정에서 병목 지점을 정확히 진단하고, QueryDSL이나 DB 레벨의 튜닝을 통해 정량적인 개선을 이끌어낸 경험을 구체적으로 설명해야 합니다."}], "latency_sec": 24.009, "in_tokens": 2872, "out_tokens": 873} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "questions", "case_id": "q2-backend-jd-tailored", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "결제 콜백 지연으로 중복 주문 문제를 멱등 키와 Outbox 패턴으로 해결하셨는데, Outbox 패턴 구현 시 트랜잭션 경계와 메시지 발행 시점의 동기화 이슈는 어떻게 관리하셨나요?", "job_category": "BACKEND", "target_evidence": "결제 승인 콜백 지연 시 중복 주문 발생 문제: 멱등 키 테이블 + Transactional Outbox 로 해결, 중복 주문 0건 달성", "expected_signal": "트랜잭션 커밋과 메시지 발행 간의 원자성 보장 메커니즘에 대한 깊은 이해를 보여주어야 합니다."}, {"category": "TECH_CHOICE", "question": "MSA 전환 시 주문 서비스를 분리하고 Kafka를 도입하셨는데, 주문 서비스와 결제 서비스 간의 이벤트 통신에서 Kafka Topic 설계 시 고려했던 파티셔닝 전략과 그 이유는 무엇인가요?", "job_category": "BACKEND", "target_evidence": "MSA 전환: 주문 서비스를 별도 서비스로 분리, DB 분리(PostgreSQL) 및 Kafka 기반 이벤트 발행/구독 구조 도입.", "expected_signal": "데이터 정합성 및 처리량(Throughput)을 고려한 Kafka Topic 설계 역량을 검증해야 합니다."}, {"category": "PROJECT_DEEP_DIVE", "question": "실시간 재고 동기화 프로젝트에서 낙관적 락에서 분산 락으로 전환하셨는데, Redis를 활용한 분산 락 구현 시 발생할 수 있는 데드락 상황을 어떻게 방지했는지 구체적인 메커니즘을 설명해주세요.", "job_category": "BACKEND", "target_evidence": "Redis 기반 재고 캐시 + DB write-behind, 동시성 제어(낙관적 락 → 분산 락 전환)", "expected_signal": "분산 시스템 환경에서 동시성 제어의 복잡성과 안정성을 확보하는 능력을 확인해야 합니다."}, {"category": "CS_FUNDAMENTAL", "question": "PostgreSQL을 사용하며 정산 배치 성능을 개선하셨는데, QueryDSL 튜닝과 인덱스 재설계 외에, RDBMS의 격리 수준(Isolation Level) 중 어떤 것을 선택했고 그 이유가 무엇인가요?", "job_category": "BACKEND", "target_evidence": "정산 배치 성능 개선: 5시간 → 40분 (QueryDSL 튜닝, 청크 단위 처리, 인덱스 재설계)", "expected_signal": "데이터 정합성 보장을 위해 트랜잭션 격리 수준에 대한 깊이 있는 이해가 필요합니다."}, {"category": "BEHAVIORAL", "question": "일 평균 주문 12만 건을 처리하는 환경에서 데이터 정합성을 지키는 서버를 만드는 데 관심이 있다고 하셨는데, 가장 까다로웠던 데이터 정합성 이슈와 그것을 해결하기 위해 취했던 본인의 구체적인 행동은 무엇인가요?", "job_category": "BACKEND", "target_evidence": "주문/결제 도메인 담당. 일 평균 주문 12만 건 처리", "expected_signal": "STAR 기법에 따라 본인의 주도적인 문제 해결 과정과 그 성과를 명확히 설명해야 합니다."}, {"category": "TECH_CHOICE", "question": "커머스 주문/결제 도메인에서 Spring Boot 3와 Kotlin을 사용하셨는데, 이 스택을 선택한 주된 이유와, 특히 Kotlin의 어떤 기능이 백엔드 개발 생산성 향상에 가장 기여했다고 보시나요?", "job_category": "BACKEND", "target_evidence": "Kotlin, Java 17, Spring Boot 3, JPA/QueryDSL, PostgreSQL, Kafka, Redis, Docker, GitHub Actions", "expected_signal": "기술 스택 선택의 합리적인 근거와 언어적 특성을 실제 개발 맥락에 연결하여 설명할 수 있어야 합니다."}], "latency_sec": 26.462, "in_tokens": 3015, "out_tokens": 961} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "questions", "case_id": "q2-frontend-junior", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "스터디 모집 플랫폼에서 IntersectionObserver를 이용해 무한 스크롤을 구현하셨는데, 이 구현 시 성능 최적화를 위해 고려했던 부분이 있나요?", "job_category": "FRONTEND", "target_evidence": "게시글 목록 무한 스크롤 (IntersectionObserver)", "expected_signal": "IntersectionObserver 사용 시 발생 가능한 리렌더링 이슈나 로딩 지연에 대한 구체적인 해결 방안을 설명할 수 있어야 합니다."}, {"category": "TECH_CHOICE", "question": "Next.js 14 App Router를 사용하셨는데, 이 프로젝트에서 Server Components와 Client Components를 어떤 기준으로 분리하고 선택하셨는지 설명해주세요.", "job_category": "FRONTEND", "target_evidence": "Next.js 14 App Router, TypeScript", "expected_signal": "컴포넌트의 렌더링 시점(서버/클라이언트)에 따른 기술적 장단점을 이해하고 실제 프로젝트에 적용한 근거를 제시해야 합니다."}, {"category": "PROJECT_DEEP_DIVE", "question": "Lighthouse 접근성 점수가 72점이었는데, 이 점수를 개선하기 위해 구체적으로 어떤 접근성(Accessibility) 이슈를 발견했고 어떻게 수정했는지 예시를 들어 설명해주세요.", "job_category": "FRONTEND", "target_evidence": "Lighthouse 접근성 점수 72", "expected_signal": "WCAG 가이드라인 중 특정 항목을 이해하고, 해당 코드를 수정하여 점수를 올린 구체적인 행동과 그 결과를 설명할 수 있어야 합니다."}, {"category": "TECH_CHOICE", "question": "개인 블로그를 Gatsby로 만드실 때, 마크다운 파일의 데이터를 가져와 렌더링하는 과정에서 발생한 데이터 처리 로직의 복잡성이나 선택 이유가 궁금합니다.", "job_category": "FRONTEND", "target_evidence": "개인 블로그 (Gatsby 로 마크다운 블로그 제작)", "expected_signal": "정적 사이트 생성(SSG) 환경에서 데이터 파싱 및 빌드 시 발생하는 이슈를 어떻게 해결했는지 기술적으로 설명할 수 있어야 합니다."}, {"category": "BEHAVIORAL", "question": "무한 스크롤과 접근성 개선을 담당하셨는데, 이 두 가지 요구사항이 충돌하거나 우선순위가 모호했을 때 어떻게 우선순위를 정하고 문제를 해결해 나갔는지 경험을 말씀해주세요.", "job_category": "FRONTEND", "target_evidence": "부트캠프에서 Next.js 로 팀 프로젝트를 했고, 무한 스크롤과 접근성 개선을 담당했습니다.", "expected_signal": "기술적 제약 조건 하에서 목표를 달성하기 위해 논리적 판단을 내리고 이해관계자(팀원)와 소통한 과정을 STAR 기법으로 설명해야 합니다."}], "latency_sec": 19.781, "in_tokens": 2573, "out_tokens": 708} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "questions", "case_id": "q2-frontend-personality", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "스터디 모집 플랫폼에서 IntersectionObserver를 사용해 무한 스크롤을 구현하셨는데, 이 로직을 구현할 때 발생한 성능 최적화 포인트나 고려사항이 있었나요?", "job_category": "FRONTEND", "target_evidence": "게시글 목록 무한 스크롤 (IntersectionObserver)", "expected_signal": "단순 구현을 넘어 성능 저하 요소를 예측하고 이를 해결한 구체적인 기술적 판단이 드러나야 합니다."}, {"category": "TECH_CHOICE", "question": "스터디 플랫폼에서 Next.js 14 App Router를 선택하신 이유와, 기존 React 기반 프로젝트 대비 App Router의 어떤 장점을 활용하셨는지 설명해주세요.", "job_category": "FRONTEND", "target_evidence": "Next.js 14 App Router, TypeScript, Tailwind CSS", "expected_signal": "프레임워크 선택의 이유를 명확히 설명하고, 해당 기술 스택의 핵심 기능을 프로젝트에 어떻게 적용했는지 연결해야 합니다."}, {"category": "PROJECT_DEEP_DIVE", "question": "개인 블로그 제작 시 Gatsby를 사용하셨는데, 마크다운 파일을 가져와서 동적으로 렌더링할 때 데이터 파싱이나 빌드 타임에 어떤 이슈가 있었고 어떻게 해결했나요?", "job_category": "FRONTEND", "target_evidence": "개인 블로그 (Gatsby 로 마크다운 블로그 제작, 다크 모드 토글)", "expected_signal": "정적 사이트 생성(SSG) 환경에서 발생할 수 있는 데이터 처리의 복잡성을 이해하고 해결한 경험이 필요합니다."}, {"category": "TECH_CHOICE", "question": "스터디 플랫폼에서 NextAuth를 이용해 카카오 로그인을 구현하셨습니다. 이 과정에서 OAuth 인증 흐름 중 보안 측면에서 특별히 주의 깊게 확인했던 부분이 있나요?", "job_category": "FRONTEND", "target_evidence": "로그인: NextAuth 카카오 로그인", "expected_signal": "단순 API 연동을 넘어, 인증 과정의 보안 취약점이나 토큰 관리 측면에서 깊이 고민한 흔적이 보여야 합니다."}, {"category": "BEHAVIORAL", "question": "프로젝트 진행 중 기술적 난관에 부딪혔을 때, 스스로 문제를 해결하기 위해 어떤 접근 방식을 취하셨는지 구체적인 사례를 들어 설명해주세요.", "job_category": "FRONTEND", "target_evidence": "", "expected_signal": "문제를 정의하고, 다양한 해결책을 탐색하며, 최종적으로 어떤 행동을 취해 목표를 달성했는지 STAR 기법으로 설명해야 합니다."}], "latency_sec": 18.729, "in_tokens": 2553, "out_tokens": 663} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "questions", "case_id": "q2-dba-technical", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "복제 지연을 90초에서 3초로 줄이셨는데, 대용량 배치 UPDATE 시 binlog_format ROW를 유지한 구체적인 이유와 그 과정에서 발생한 트레이드오프는 무엇이었나요?", "job_category": "DBA", "target_evidence": "복제 지연 최대 90초 → 3초: 대용량 배치 UPDATE 를 1만 건 단위 청크로 분할, binlog_format ROW 유지", "expected_signal": "ROW 포맷 선택의 기술적 근거와 성능 최적화 과정에 대한 깊이 있는 이해를 보여주어야 합니다."}, {"category": "TECH_CHOICE", "question": "온라인 스키마 변경 시 gh-ost를 도입하셨는데, gh-ost가 락 대기 장애를 막는 핵심 메커니즘과 MySQL의 MVCC 관점에서 설명해주실 수 있나요?", "job_category": "DBA", "target_evidence": "온라인 스키마 변경: gh-ost 도입, 컬럼 추가 시 락 대기 장애 0건", "expected_signal": "gh-ost의 작동 원리(Shadow Copy, Dual Write 등)와 MySQL의 동시성 제어 메커니즘을 정확히 연결하여 설명해야 합니다."}, {"category": "PROJECT_DEEP_DIVE", "question": "Debezium CDC를 Kafka를 통해 BigQuery로 적재하는 파이프라인에서, 데이터 정합성(Data Consistency)을 보장하기 위해 어떤 메커니즘을 적용하셨는지 구체적인 사례를 들어 설명해주세요.", "job_category": "DBA", "target_evidence": "데이터 파이프라인: Debezium CDC → Kafka → BigQuery 적재", "expected_signal": "CDC 환경에서 발생 가능한 데이터 유실이나 순서 오류를 방지하기 위한 설계적 고민과 구현 방안을 제시해야 합니다."}, {"category": "CS_FUNDAMENTAL", "question": "pt-query-digest로 상위 쿼리를 선별하고 커버링 인덱스를 적용하셨는데, 커버링 인덱스가 실제로 쿼리 실행 계획(Execution Plan)에서 어떤 이점을 가져오는지 기술적으로 설명해주세요.", "job_category": "DBA", "target_evidence": "슬로우 쿼리: pt-query-digest 로 상위 20개 쿼리 선별, 커버링 인덱스 적용", "expected_signal": "인덱스 스캔 방식(Index Scan vs Full Table Scan)의 차이와 커버링 인덱스가 I/O 오버헤드를 줄이는 원리를 명확히 설명해야 합니다."}, {"category": "BEHAVIORAL", "question": "RTO 40분 복구 훈련을 진행하셨는데, 이 훈련 과정에서 예상치 못한 장애 상황이 발생했을 때, 어떤 의사결정 과정을 거쳐 목표 RTO를 달성하셨나요?", "job_category": "DBA", "target_evidence": "백업: 매일 스냅샷 + binlog PITR, 분기별 복구 훈련(RTO 40분)", "expected_signal": "실제 장애 상황에서 침착하게 문제의 근본 원인을 파악하고, 우선순위에 따라 복구 전략을 실행한 경험을 STAR 기법으로 설명해야 합니다."}], "latency_sec": 21.8, "in_tokens": 2577, "out_tokens": 817} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "questions", "case_id": "q2-dba-infra-multi", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "MySQL Aurora에서 복제 지연을 90초에서 3초로 줄이셨는데, 대용량 배치 UPDATE를 1만 건 단위 청크로 분할하고 binlog_format ROW를 유지한 구체적인 이유와 그 과정에서 발생한 트레이드오프는 무엇인가요?", "job_category": "DBA", "target_evidence": "복제 지연 최대 90초 → 3초: 대용량 배치 UPDATE 를 1만 건 단위 청크로 분할, binlog_format ROW 유지", "expected_signal": "대용량 트랜잭션 처리 시 복제 부하를 줄이고 일관성을 유지하기 위한 설계 의도와 기술적 이해도를 확인합니다."}, {"category": "PROJECT_DEEP_DIVE", "question": "PostgreSQL RDS에서 슬로우 쿼리 p95를 2.3초에서 180ms로 개선하셨는데, 복합 인덱스 재설계와 파티셔닝 중 어떤 부분이 가장 큰 성능 향상을 가져왔는지 구체적인 쿼리 예시와 함께 설명해주세요.", "job_category": "DBA", "target_evidence": "슬로우 쿼리 p95 2.3초 → 180ms (복합 인덱스 재설계, autovacuum 튜닝, 파티셔닝으로 거래내역 테이블 월 단위 분할)", "expected_signal": "성능 개선의 핵심 원인을 정확히 파악하고, 튜닝 과정에서 적용한 구체적인 데이터베이스 최적화 기법을 설명할 수 있어야 합니다."}, {"category": "TECH_CHOICE", "question": "EKS 클러스터 운영 시 HPA 기준을 CPU 70%로 설정하셨는데, 트래픽 피크 대비 사전 스케일아웃 CronJob을 운영하는 전략적 선택의 근거와, 이 방식이 가진 잠재적 리소스 오버헤드는 무엇이라고 보십니까?", "job_category": "INFRA", "target_evidence": "HPA 기준을 CPU 70% 로 설정, 트래픽 피크(월급날 10시) 대비 사전 스케일아웃 CronJob 운영", "expected_signal": "단순한 설정 적용을 넘어, 비즈니스 요구사항(트래픽 피크)에 맞춰 인프라를 선제적으로 설계한 판단 근거를 확인합니다."}, {"category": "PROJECT_DEEP_DIVE", "question": "Debezium CDC를 Kafka를 통해 BigQuery에 적재하는 파이프라인을 구축하셨는데, CDC 과정에서 발생하는 데이터 정합성 이슈나 Kafka 토픽의 메시지 순서 보장 측면에서 고려했던 설계 사항이 있나요?", "job_category": "DBA", "target_evidence": "데이터 파이프라인: Debezium CDC → Kafka → BigQuery 적재", "expected_signal": "데이터 파이프라인의 안정성과 데이터 무결성을 보장하기 위해 고려한 스트리밍 데이터 처리의 깊이 있는 이해도를 확인합니다."}, {"category": "TECH_CHOICE", "question": "Terraform으로 VPC, RDS, EKS 모듈화를 하셨는데, 환경별 workspace 분리 시 상태 파일(State File)의 격리 외에, 모듈 간 의존성 관리나 보안 정책 적용 시 특별히 신경 쓴 부분이 있나요?", "job_category": "INFRA", "target_evidence": "Terraform 으로 VPC·RDS·EKS 모듈화, 환경별(dev/stg/prod) workspace 분리", "expected_signal": "IaC(Infrastructure as Code) 구현 시, 단순 배포를 넘어선 모듈화의 복잡성 관리 및 보안 측면의 고민을 확인합니다."}, {"category": "PROJECT_DEEP_DIVE", "question": "gh-ost를 도입하여 온라인 스키마 변경을 성공적으로 수행하셨는데, 이 과정에서 발생 가능한 잠재적 리소스 병목(CPU, I/O)을 예측하고 이를 완화하기 위해 어떤 튜닝을 병행했는지 설명해주세요.", "job_category": "DBA", "target_evidence": "온라인 스키마 변경: gh-ost 도입, 컬럼 추가 시 락 대기 장애 0건", "expected_signal": "고가용성 환경에서 스키마 변경 시 발생할 수 있는 성능 저하 요소를 사전에 분석하고 대응한 경험을 확인합니다."}], "latency_sec": 27.651, "in_tokens": 2886, "out_tokens": 1068} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "questions", "case_id": "q2-infra-recent-dup", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "PostgreSQL 14에서 복합 인덱스 재설계와 파티셔닝을 통해 거래내역 테이블의 성능을 개선한 구체적인 과정과 가장 큰 기술적 난관은 무엇이었나요?", "job_category": "DBA", "target_evidence": "PostgreSQL 14 (RDS) 운영: 슬로우 쿼리 p95 2.3초 → 180ms (복합 인덱스 재설계, autovacuum 튜닝, 파티셔닝으로 거래내역 테이블 월 단위 분할)", "expected_signal": "인덱스 설계 결정의 근거와 파티셔닝 구현 시 발생한 데이터 무결성 또는 쿼리 최적화 관련 구체적인 해결 방안을 설명할 수 있어야 합니다."}, {"category": "TECH_CHOICE", "question": "Terraform으로 VPC, RDS, EKS 모듈을 분리하고 workspace를 사용한 이유와, 환경별(dev/stg/prod) 구성 차이를 어떻게 관리했는지 설명해주세요.", "job_category": "INFRA", "target_evidence": "Terraform 으로 VPC·RDS·EKS 모듈화, 환경별(dev/stg/prod) workspace 분리", "expected_signal": "IaC 설계 시 모듈화 및 workspace 분리의 장점을 명확히 이해하고 있으며, 실제 환경 구성의 차이점을 체계적으로 관리했음을 보여줘야 합니다."}, {"category": "PROJECT_DEEP_DIVE", "question": "EKS 클러스터에서 HPA 기준을 CPU 70%로 설정하고 트래픽 피크 대비 CronJob을 운영한 구체적인 시나리오와, 이 설정이 실제 트래픽 패턴에 어떻게 반응했는지 설명해주세요.", "job_category": "INFRA", "target_evidence": "EKS 기반 쿠버네티스 클러스터 3개 운영 (파드 약 400개) / HPA 기준을 CPU 70% 로 설정, 트래픽 피크(월급날 10시) 대비 사전 스케일아웃 CronJob 운영", "expected_signal": "단순 설정 적용이 아닌, 비즈니스 트래픽 패턴 분석을 기반으로 한 선제적 대응 전략을 수립하고 실행했음을 증명해야 합니다."}, {"category": "CS_FUNDAMENTAL", "question": "RDS 스토리지 풀 쓰기 중단 장애 시, CloudWatch 알람과 오토스케일링을 적용한 것이 근본적인 해결책이 된 이유와, 이 장애가 발생한 내부적인 원인(I/O 병목 등)을 어떻게 분석했나요?", "job_category": "DBA", "target_evidence": "장애: 2024.03 RDS 스토리지 풀로 쓰기 중단 40분 → CloudWatch 알람 + 스토리지 오토스케일링 적용", "expected_signal": "단순한 모니터링/자동화 적용을 넘어, 데이터베이스 인프라 레벨에서 발생한 근본적인 리소스 제약 문제를 정확히 진단했음을 보여줘야 합니다."}, {"category": "BEHAVIORAL", "question": "ArgoCD GitOps 도입을 통해 배포 리드타임을 1일에서 30분으로 단축한 경험에서, 팀원들의 초기 저항이나 기술적 이해 부족을 어떻게 설득하고 협업을 이끌어냈나요?", "job_category": "INFRA", "target_evidence": "ArgoCD GitOps 도입으로 배포 리드타임 1일 → 30분", "expected_signal": "기술적 성과 달성 과정에서 발생한 조직적/인적 요소를 어떻게 관리하고, 변화를 성공적으로 이끌어낸 리더십 또는 커뮤니케이션 능력을 보여줘야 합니다."}], "latency_sec": 24.127, "in_tokens": 2703, "out_tokens": 919} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "questions", "case_id": "q2-backend-focus-weak", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "결제 콜백 지연으로 중복 주문을 막기 위해 멱등 키와 Outbox 패턴을 사용하셨는데, 이 두 패턴이 각각 어떤 문제를 해결하며 어떻게 상호 보완하는지 설명해 주시겠어요?", "job_category": "BACKEND", "target_evidence": "결제 승인 콜백 지연 시 중복 주문 발생 문제: 멱등 키 테이블 + Transactional Outbox 로 해결, 중복 주문 0건 달성", "expected_signal": "두 패턴의 역할 분담(멱등 키=멱등성 보장, Outbox=원자적 이벤트 발행)과 통합적인 동작 원리를 명확히 설명해야 합니다."}, {"category": "TECH_CHOICE", "question": "MSA 전환 시 주문 서비스를 분리하고 Kafka를 도입하셨는데, 주문 서비스와 결제 서비스 간의 통신에서 Kafka를 선택한 구체적인 기술적 근거는 무엇인가요?", "job_category": "BACKEND", "target_evidence": "모놀리식 → MSA 전환: 주문 서비스를 별도 서비스로 분리, DB 분리(PostgreSQL) 및 Kafka 기반 이벤트 발행/구독 구조 도입.", "expected_signal": "단순한 '분리'를 넘어, 비동기 통신, 확장성, 혹은 서비스 간 결합도 측면에서 Kafka의 장점을 구체적으로 제시해야 합니다."}, {"category": "PROJECT_DEEP_DIVE", "question": "실시간 재고 동기화 프로젝트에서 낙관적 락에서 분산 락으로 전환하신 이유와, Redis를 활용한 write-behind 전략의 동시성 제어 메커니즘을 설명해 주세요.", "job_category": "BACKEND", "target_evidence": "Redis 기반 재고 캐시 + DB write-behind, 동시성 제어(낙관적 락 → 분산 락 전환)", "expected_signal": "락 전환의 필요성(경쟁 조건 등)과 write-behind 시 데이터 정합성을 유지하기 위한 분산 락 구현 방식을 구체적으로 설명해야 합니다."}, {"category": "CS_FUNDAMENTAL", "question": "PostgreSQL을 사용하셨는데, 정산 배치 성능 개선 시 QueryDSL 튜닝과 인덱스 재설계 외에, 트랜잭션 격리 수준(Isolation Level) 측면에서 고려했던 부분이 있나요?", "job_category": "BACKEND", "target_evidence": "정산 배치 성능 개선: 5시간 → 40분 (QueryDSL 튜닝, 청크 단위 처리, 인덱스 재설계)", "expected_signal": "성능 개선 과정에서 데이터 일관성(Consistency)과 동시성(Concurrency) 사이의 트레이드오프를 이해하고 있음을 보여줘야 합니다."}, {"category": "BEHAVIORAL", "question": "대용량 트래픽 환경에서 데이터 정합성을 지키는 서버를 만드는 데 관심이 있다고 하셨는데, 가장 까다로웠던 데이터 정합성 이슈와 그것을 해결하기 위해 취했던 본인만의 접근 방식은 무엇인가요?", "job_category": "BACKEND", "target_evidence": "대용량 트래픽에서도 데이터 정합성을 지키는 서버를 만드는 데 관심이 많습니다.", "expected_signal": "단순히 기술을 나열하는 것이 아니라, 문제 정의(Situation/Task)부터 본인의 구체적인 판단과 행동(Action)을 STAR 기법에 맞춰 설명해야 합니다."}], "latency_sec": 23.906, "in_tokens": 2987, "out_tokens": 842} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "questions", "case_id": "q2-fullstack-multi", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "travel-planner에서 react-window를 도입하며 INP를 480ms에서 120ms로 개선했는데, 가상화 구현 시 가장 까다로웠던 렌더링 최적화 포인트는 무엇이었나요?", "job_category": "FRONTEND", "target_evidence": "일정 타임라인: 항목 2천 개 이상일 때 스크롤 끊김 → react-window 가상화 도입 (커밋 메시지: \"virtualize timeline, INP 480ms -> 120ms\")", "expected_signal": "단순히 라이브러리를 적용한 것이 아니라, 렌더링 로직이나 데이터 처리 과정에서 발생한 구체적인 병목 지점을 파악하고 해결했음을 설명해야 합니다."}, {"category": "TECH_CHOICE", "question": "travel-planner에서 오프라인 편집 시 IndexedDB(Dexie)를 사용하고 충돌 해결을 last-write-wins로 구현했는데, CRDT 검토가 필요하다고 언급한 이유와 그 대안적 접근법은 무엇인가요?", "job_category": "FRONTEND", "target_evidence": "오프라인 편집: IndexedDB(Dexie) 에 낙관적 업데이트를 저장 후 온라인 복귀 시 동기화. 충돌은 last-write-wins (TODO 주석: \"CRDT 검토 필요\")", "expected_signal": "Last-write-wins의 한계(데이터 손실 가능성)를 이해하고 있으며, CRDT가 제공하는 분산 환경에서의 데이터 일관성 보장 메커니즘에 대해 설명할 수 있어야 합니다."}, {"category": "PROJECT_DEEP_DIVE", "question": "마켓온에서 결제 승인 지연으로 인한 중복 주문 이슈를 멱등 키와 Transactional Outbox 패턴으로 해결했는데, Outbox 패턴을 도입하기 전의 시스템적 취약점은 무엇이었나요?", "job_category": "BACKEND", "target_evidence": "결제 승인 콜백 지연 시 중복 주문 발생 문제: 멱등 키 테이블 + Transactional Outbox 로 해결, 중복 주문 0건 달성", "expected_signal": "단순히 코드를 추가한 것이 아니라, 트랜잭션 경계와 메시지 발행 시점의 원자성(Atomicity) 보장 실패가 핵심 문제였음을 명확히 설명해야 합니다."}, {"category": "TECH_CHOICE", "question": "travel-planner에서 Kakao Map SDK 마커 500개를 클러스터링하고 useMemo로 좌표 변환 캐싱했는데, 클러스터링 로직을 구현할 때 성능 저하를 막기 위해 고려한 구체적인 최적화 전략이 있나요?", "job_category": "FRONTEND", "target_evidence": "지도 마커 렌더링: Kakao Map SDK 마커 500개를 클러스터링, useMemo 로 좌표 변환 캐싱", "expected_signal": "useMemo를 적용한 범위를 넘어, 클러스터링 알고리즘 자체의 시간 복잡도나 렌더링 시점에 대한 고려 사항을 제시할 수 있어야 합니다."}, {"category": "BEHAVIORAL", "question": "마켓온에서 모놀리식에서 MSA로 전환하며 주문 서비스를 분리했을 때, 팀 내에서 발생한 기술적 합의 도출 과정이나 의견 충돌은 어떻게 해결했나요?", "job_category": "BACKEND", "target_evidence": "모놀리식 → MSA 전환: 주문 서비스를 별도 서비스로 분리, DB 분리(PostgreSQL) 및 Kafka 기반 이벤트 발행/구독 구조 도입.", "expected_signal": "기술적 결정(예: Kafka 사용 여부, DB 분리 범위)에 대한 본인의 주장을 논리적으로 뒷받침하고, 다른 이해관계자(동료)의 의견을 수용하며 합의에 도달한 구체적인 과정을 STAR 기법으로 설명해야 합니다."}, {"category": "CS_FUNDAMENTAL", "question": "실시간 재고 동기화 프로젝트에서 낙관적 락을 분산 락으로 전환한 이유가 무엇이며, 분산 락 구현 시 발생할 수 있는 데드락(Deadlock) 상황을 어떻게 방지했나요?", "job_category": "BACKEND", "target_evidence": "실시간 재고 동기화 (2024): Redis 기반 재고 캐시 + DB write-behind, 동시성 제어(낙관적 락 → 분산 락 전환)", "expected_signal": "분산 락의 필요성(단일 DB/프로세스 한계)을 이해하고 있으며, 분산 락 구현 시 발생하는 교착 상태를 회피하기 위한 타임아웃 설정이나 락 획득 순서 지정 등의 구체적인 메커니즘을 설명해야 합니다."}], "latency_sec": 30.336, "in_tokens": 3110, "out_tokens": 1153} +{"label": "q-gemma4-e4b-Q4_K_M", "suite": "questions", "case_id": "q2-coverletter-integrated", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "알림 봇 DB를 SQLite에서 PostgreSQL로 이전하며 겪은 동시 쓰기 락 문제를 구체적으로 설명해 주시겠어요? 트랜잭션 격리 수준 중 어떤 것을 적용하셨나요?", "job_category": "BACKEND", "target_evidence": "알림 봇 DB를 SQLite 로 시작했다가 동시 쓰기 락 문제로 알림이 중복 발송되었습니다. 원인을 찾는 데 3일이 걸렸고, PostgreSQL 로 이전하며 트랜잭션 격리 수준을 공부하게 됐습니다.", "expected_signal": "문제의 근본 원인 분석 능력과 PostgreSQL의 트랜잭션 격리 수준에 대한 깊이 있는 이해도를 보여주는가."}, {"category": "TECH_CHOICE", "question": "캡스톤 프로젝트에서 API 스펙 해석 차이로 지연되었을 때, OpenAPI 명세와 Mock 서버를 제안하셨는데, 이 방식이 병렬 개발에 구체적으로 어떤 이점을 주었나요?", "job_category": "BACKEND", "target_evidence": "저는 OpenAPI 명세를 먼저 작성하고 Mock 서버를 띄워 프론트가 병렬로 개발하도록 제안했고, 이후 스프린트에서는 통합 이슈가 3건에서 0건으로 줄었습니다.", "expected_signal": "기술적 선택(Mocking/Specification)이 실제 개발 프로세스 효율성(병렬성, 이슈 감소)에 미친 영향을 정량적으로 설명하는가."}, {"category": "BEHAVIORAL", "question": "협업 시 초반에 본인의 방식이 옳다고 고집해 팀원과 감정이 상했던 경험이 있습니다. 이후 '대안 두 가지 비교'로 바꾼 구체적인 과정과 그 변화가 팀워크에 어떤 영향을 주었나요?", "job_category": "BACKEND", "target_evidence": "다만 초반에 제 방식이 옳다고 고집해 팀원과 감정이 상한 적도 있어, 이후에는 결정 전에 대안 두 가지를 함께 비교하는 방식으로 바꿨습니다.", "expected_signal": "갈등 상황에서 자신의 태도를 성찰하고, 이를 건설적인 협업 방식으로 개선해 나가는 자기 객관화 능력을 보여주는가."}, {"category": "CS_FUNDAMENTAL", "question": "알림 봇 서비스 운영 중 '멈추지 않는 서비스'의 중요성을 깨달았다고 하셨는데, 백엔드 관점에서 서비스의 안정성을 확보하기 위해 고려해야 할 핵심 요소는 무엇이라고 생각하나요?", "job_category": "BACKEND", "target_evidence": "새벽에 크롤러가 멈춰 공지가 누락됐을 때 동아리원들의 항의를 직접 받으며, 기능보다 '멈추지 않는 서비스'가 신뢰를 만든다는 것을 배웠습니다.", "expected_signal": "단순한 기능 구현을 넘어, 장애 대응, 모니터링, 복원력(Resilience) 등 시스템 안정성에 대한 깊이 있는 이해를 보여주는가."}, {"category": "BEHAVIORAL", "question": "사용자 800명이 매일 쓰는 서비스를 운영하며 느낀 '신뢰'의 중요성을 바탕으로, 이 회사/직무에서 가장 기여하고 싶은 부분은 무엇이며 그 이유는 무엇인가요?", "job_category": "BACKEND", "target_evidence": "학부 동아리에서 학사 공지 알림 봇을 만들며 사용자 800명이 매일 쓰는 서비스를 운영해 본 경험이 있습니다. 새벽에 크롤러가 멈춰 공지가 누락됐을 때 동아리원들의 항의를 직접 받으며, 기능보다 '멈추지 않는 서비스'가 신뢰를 만든다는 것을 배웠습니다.", "expected_signal": "자신의 경험(신뢰 구축)을 회사의 비즈니스 목표와 연결하여, 직무에 대한 명확한 이해와 강한 몰입 의지를 보여주는가."}], "latency_sec": 24.298, "in_tokens": 2655, "out_tokens": 932} diff --git a/docs/research/thesis/quantization-study.md b/docs/research/thesis/quantization-study.md index 808dffa..0a3e03b 100644 --- a/docs/research/thesis/quantization-study.md +++ b/docs/research/thesis/quantization-study.md @@ -87,10 +87,11 @@ F16 원본이 각 토큰에 매긴 확률 분포를 기준으로 삼고, 양자 | E4B Q8_0 | 100% | 97.5% | 88.9% | 96.2% | 100% | 3.51s | | E4B Q6_K | 100% | 97.5% | 88.9% | 96.2% | 100% | 3.24s | | E4B Q5_K_M | 100% | 97.5% | 88.9% | 96.2% | 100% | 2.81s | +| E4B Q4_K_M | 100% | 100% | 88.9% | 96.2% | 100% | 2.72s | | E4B Q3_K_M | 100% | 92.5% | 88.9% | 100% | 100% | 3.07s | | 26B-A4B UD-IQ2_M | 100% | 92.5% | 96.3% | 96.2% | 100% | 7.98s | -E4B 도 8비트에서 3비트까지 평평하다. 주목할 점은 **26B 를 2비트로 줄인 쪽이 4B 를 8비트로 쓰는 쪽보다 모든 품질 지표에서 낫다**는 것이다(점수 라벨 96.3% 대 88.9%, 카테고리 적합 100% 대 86.7%). 파일 크기는 10.0 GB 대 8.2 GB 로 비슷하다. 다만 지연은 2.3배로 늘어난다. +E4B 도 8비트에서 3비트까지 평평하다. 26B 조건은 이틀에 걸쳐 두 번 독립적으로 돌렸는데 점수 라벨 96.3%, 지연 중앙값 7.98초와 8.00초로 거의 같은 값이 나왔다(사실대조만 96.2% 대 94.2%). 케이스 70건·반복 1회 설계의 측정 잡음이 이 정도 범위임을 보여준다. 주목할 점은 **26B 를 2비트로 줄인 쪽이 4B 를 8비트로 쓰는 쪽보다 모든 품질 지표에서 낫다**는 것이다(점수 라벨 96.3% 대 88.9%, 카테고리 적합 100% 대 86.7%). 파일 크기는 10.0 GB 대 8.2 GB 로 비슷하다. 다만 지연은 2.3배로 늘어난다. --- @@ -144,6 +145,8 @@ Qwen3 4B 10종에 대해 평균 KL 과 각 지표의 순위 상관(스피어만 | Gemma E4B Q4_K_M, 26B IQ3_S | 컨테이너 즉시 종료 | 양자화 디렉터리 밖을 가리키는 심볼릭 링크가 컨테이너 안에서 끊김. 하드링크로 교체 후 재실행 | | Qwen3 4B Q8_0·Q6_K | 1차 실패 → 재시도 성공 | 컨테이너 생성 직후 간헐적 CUDA 초기화 실패 | +심볼릭 링크 문제는 하드링크로 바꿔 해결했고 해당 조건을 모두 다시 돌렸다. F16 만 하드웨어 제약으로 영구 결측이다. + 세 번째 항목은 이 서버에서 반복 관측된 현상이다(6.4절 운영 교훈). 조건마다 재시도 루프를 두지 않으면 실패가 조용히 결측으로 남는다. --- @@ -158,9 +161,32 @@ Qwen3 4B 10종에 대해 평균 KL 과 각 지표의 순위 상관(스피어만 --- +## 7-1. 예비 판정 결과 — 규칙이 같다고 사람(판정자)도 같다고 보는가 + +규칙 지표가 8비트와 3비트를 구분하지 못했기 때문에, 같은 출력을 블라인드로 채점해 확인했다. 후보 6종(Qwen3 4B 의 Q8_0·Q5_K_M·Q4_K_M·Q3_K_M, Gemma E4B 의 Q8_0·Q3_K_M)을 익명 라벨로 섞어 3계열 판정자(Google·Anthropic·OpenAI)가 순서를 바꿔 두 번 채점하는 설계였다. + +**게이트웨이 채점 크레딧이 도중에 소진되어 40케이스 중 12케이스만 완전 판정됐다.** 아래는 그 12케이스의 예비 결과이며, 같은 계열 판정자를 제외한 점수다(Gemma 후보에서 Google 판정자 제외). + +| 후보 | 종합 (5점) | 95% 신뢰구간 | +|---|---|---| +| Gemma E4B Q8_0 | 3.56 | [3.17, 3.90] | +| Gemma E4B Q3_K_M | 3.06 | [2.62, 3.54] | +| Qwen3 4B Q5_K_M | 2.61 | [2.06, 3.21] | +| Qwen3 4B Q4_K_M | 2.42 | [1.83, 3.04] | +| Qwen3 4B Q3_K_M | 2.38 | [1.93, 2.85] | +| Qwen3 4B Q8_0 | 2.36 | [1.75, 2.99] | + +- **Qwen3 4B 는 비트 폭에 따른 차이가 보이지 않는다.** Q8_0 대비 Q5·Q4·Q3 의 짝지은 차이가 모두 0.25 이하이고 부호도 일정하지 않다(Wilcoxon p = 0.31~0.61). 규칙 지표 결과와 같은 방향이다. +- **Gemma E4B 는 8비트가 3비트보다 0.50점 높게 나왔다**(p = 0.155). 케이스 12건으로는 유의하지 않지만, 규칙 지표가 완전히 같았던 두 조건 사이에 판정자만 감지한 차이라는 점에서 주목할 만하다. 40케이스 전체로 확인이 필요하다. +- 같은 계열 편향도 재현됐다. Google 판정자는 Gemma 후보에 다른 계열 판정자보다 높은 점수를 줬다(Q8_0 에서 전체 평균 3.64 대 계열 제외 3.56). + +**남은 작업**: 채점 크레딧을 다시 확보하면 같은 설계로 나머지 28케이스(163회 호출)를 이어 돌린다. 원자료는 `quant/judge-pilot.jsonl`. + +--- + ## 8. 한계 -- 자동 규칙 지표만 집계했다. 같은 형식을 지키면서 질문의 깊이가 떨어지는 변화는 이 지표로 잡히지 않는다. 판정자 평가는 호출 예산 때문에 축소 설계로 따로 진행한다. +- 판정자 평가가 12케이스에서 멈췄다(7-1절). 본 분석의 주 결론은 자동 규칙 지표에 근거하며, 같은 형식을 지키면서 질문의 깊이만 떨어지는 변화는 규칙으로 잡히지 않는다. - 케이스는 과제당 15~40건, 반복 1회다. 1~2건 차이는 해석하지 않았다. - 분포 차이 측정은 Qwen3 4B 계열만 했다. Gemma 계열은 과제 지표로만 확인했다. - 보정 텍스트가 이 프로젝트 문서에서 왔으므로, 평가 케이스와 주제가 겹칠 여지가 있다. 평가 텍스트는 분리했지만 도메인은 같다.