diff --git a/docs/research/thesis/quant/analysis/q-gemma4-26b-UD-IQ3_S.json b/docs/research/thesis/quant/analysis/q-gemma4-26b-UD-IQ3_S.json new file mode 100644 index 00000000..d8588d08 --- /dev/null +++ b/docs/research/thesis/quant/analysis/q-gemma4-26b-UD-IQ3_S.json @@ -0,0 +1,59 @@ +{ + "q-gemma4-26b-UD-IQ3_S": { + "followup": { + "calls": 40, + "success_pct": 100.0, + "tag_compliance_pct": 100.0, + "intent_accuracy_pct": 95.0, + "intent_misses": { + "f-weak-vague": [ + "DONT_KNOW" + ], + "f2-offtopic-weak": [ + "DONT_KNOW" + ] + }, + "score_label_accuracy_pct": 96.3, + "correctness_rule_accuracy_pct": 96.3, + "discrimination_gap_backend": 4.0, + "discrimination_gap_personality": 3.0, + "question_len_median": 73.0, + "question_len_le60_pct": 25.0, + "non_korean_script_pct": 0.0, + "latency_median": 8.44, + "latency_p90": 10.29, + "ttft_median": 4.04, + "ttft_p90": 5.69, + "over_3s_pct": 100.0, + "over_10s_timeout_pct": 20.0 + }, + "questions": { + "calls": 15, + "success_pct": 100.0, + "errors": [], + "count_exact_pct": 100.0, + "mode_category_fit_pct": 100.0, + "job_category_valid_pct": 100.0, + "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": 38.0, + "non_korean_script_pct": 1.3, + "markdown_in_question_pct": 0.0, + "long_context_success": "1/1", + "latency_median": 64.06, + "latency_p90": 70.97 + }, + "coaching": { + "calls": 15, + "success_pct": 100.0, + "invented_numbers_pct": 6.7, + "non_korean_script_pct": 0.0, + "comment_one_line_pct": 100.0, + "latency_median": 33.39, + "latency_p90": 36.85 + } + } +} diff --git a/docs/research/thesis/quant/raw/q-gemma4-26b-UD-IQ3_S.jsonl b/docs/research/thesis/quant/raw/q-gemma4-26b-UD-IQ3_S.jsonl new file mode 100644 index 00000000..2091675d --- /dev/null +++ b/docs/research/thesis/quant/raw/q-gemma4-26b-UD-IQ3_S.jsonl @@ -0,0 +1,70 @@ +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f-strong-backend", "rep": 0, "ok": true, "followup_question": "멱등 키를 통해 중복 요청을 막는다고 하셨는데, 만약 PG사가 동일한 멱등 키로 새로운 결제 요청을 보낸다면 시스템은 이를 어떻게 구분하나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 4.0, "logic": 4.0, "structure": "PARTIAL_STAR", "correctness": null}, "latency_sec": 5.963, "ttft_sec": 0.869, "in_tokens": 1524, "out_tokens": 90} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f-weak-vague", "rep": 0, "ok": true, "followup_question": "멱등 키가 방지하는 중복 요청 케이스와 Outbox 패턴이 보장하는 데이터 일관성 측면의 차이를 구체적으로 설명해 주실 수 있나요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 6.622, "ttft_sec": null, "in_tokens": 1394, "out_tokens": 87} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f-dont-know-explicit", "rep": 0, "ok": true, "followup_question": "괜찮습니다. 그럼 다음 질문으로 넘어가겠습니다.", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 6.432, "ttft_sec": null, "in_tokens": 1348, "out_tokens": 59} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f-dont-know-stt", "rep": 0, "ok": true, "followup_question": "괜찮습니다. 그럼 React 18 이전 버전에서 비동기 함수(setTimeout 등) 내부의 상태 업데이트가 어떻게 처리되었는지 기억하시나요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 8.193, "ttft_sec": null, "in_tokens": 1347, "out_tokens": 80} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f-clarification", "rep": 0, "ok": true, "followup_question": "HPA의 CPU 임계치 설정 근거와, 트래픽 급증 시점에 대비해 미리 스케일아웃을 진행하신 이유를 나누어 설명해 달라는 의미입니다.", "answer_intent": "CLARIFICATION", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 8.48, "ttft_sec": 4.203, "in_tokens": 1383, "out_tokens": 87} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f-confirm-short", "rep": 0, "ok": true, "followup_question": "별도 프로세스로 폴링할 때, DB 부하를 줄이기 위해 고려하신 구체적인 방식이 있나요?", "answer_intent": "NORMAL", "answer_evaluation": null, "latency_sec": 7.312, "ttft_sec": 3.901, "in_tokens": 1369, "out_tokens": 68} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f-infra-fact-error", "rep": 0, "ok": true, "followup_question": "이력서에는 트래픽 피크 대비 사전 스케일아웃을 위해 CronJob을 운영했다고 적혀 있는데, 답변하신 내용과 차이가 있네요. CronJob을 통해 사전 스케일아웃을 진행하신 구체적인 이유는 무엇인가요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 1.0, "logic": 1.0, "structure": "NONE", "correctness": 1.0}, "latency_sec": 10.715, "ttft_sec": 5.436, "in_tokens": 1665, "out_tokens": 102} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f-dba-correct-with-context", "rep": 0, "ok": true, "followup_question": "autovacuum의 scale_factor를 낮추면 dead tuple 관리에 유리하지만, 시스템 부하 측면에서 어떤 트레이드오프가 발생할 수 있나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 5.0, "logic": 4.0, "structure": "FULL_STAR", "correctness": 5.0}, "latency_sec": 10.063, "ttft_sec": 5.727, "in_tokens": 1784, "out_tokens": 84} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f-frontend-strong", "rep": 0, "ok": true, "followup_question": "VariableSizeList를 사용해 동적 높이를 처리할 때, 높이 캐시를 업데이트하는 시점과 그로 인한 리렌더링 비용 문제는 어떻게 관리하셨나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 5.0, "logic": 4.0, "structure": "FULL_STAR", "correctness": 5.0}, "latency_sec": 10.511, "ttft_sec": 5.853, "in_tokens": 1756, "out_tokens": 86} +{"label": "q-gemma4-26b-UD-IQ3_S", "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.612, "ttft_sec": 4.119, "in_tokens": 1448, "out_tokens": 68} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f-personality-rambling", "rep": 0, "ok": true, "followup_question": "구체적인 갈등 사례 없이 '대화를 많이 한다'는 원칙만 말씀하셨는데, 실제로 의견 차이를 좁히기 위해 어떤 대화 방식을 사용하셨나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 1.0, "logic": 2.0, "structure": "NONE", "correctness": null}, "latency_sec": 6.529, "ttft_sec": 2.593, "in_tokens": 1389, "out_tokens": 85} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f-stt-messy-normal", "rep": 0, "ok": true, "followup_question": "재시도 로직이 DB 부하를 높인다고 하셨는데, 분산 락을 도입했을 때의 성능 저하나 오버헤드는 어떻게 관리하셨나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 4.0, "logic": 3.0, "structure": "PARTIAL_STAR", "correctness": null}, "latency_sec": 8.465, "ttft_sec": 3.971, "in_tokens": 1422, "out_tokens": 86} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f-long-answer-history", "rep": 0, "ok": true, "followup_question": "보상 이벤트가 유실되었을 때 스위퍼 배치가 상태를 재조회한다고 하셨는데, 재조회 시 어떤 데이터 소스를 기준으로 삼으셨나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 5.0, "logic": 5.0, "structure": "FULL_STAR", "correctness": null}, "latency_sec": 10.22, "ttft_sec": 5.522, "in_tokens": 1730, "out_tokens": 84} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f-english-mixed", "rep": 0, "ok": true, "followup_question": "네트워크 요청이 40% 줄었다고 하셨는데, 이 수치는 어떤 기준으로 측정하신 건가요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 4.0, "logic": 4.0, "structure": "PARTIAL_STAR", "correctness": null}, "latency_sec": 8.053, "ttft_sec": 3.834, "in_tokens": 1403, "out_tokens": 73} +{"label": "q-gemma4-26b-UD-IQ3_S", "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.086, "ttft_sec": 5.098, "in_tokens": 1634, "out_tokens": 84} +{"label": "q-gemma4-26b-UD-IQ3_S", "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.936, "ttft_sec": 5.215, "in_tokens": 1689, "out_tokens": 74} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-infra-gitops-strong", "rep": 0, "ok": true, "followup_question": "External Secrets Operator를 도입했을 때, 시크릿 데이터의 생명주기 관리는 어떻게 이루어지나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 5.0, "logic": 4.0, "structure": "PARTIAL_STAR", "correctness": 5.0}, "latency_sec": 8.973, "ttft_sec": 5.532, "in_tokens": 1728, "out_tokens": 73} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-personality-failure-star", "rep": 0, "ok": true, "followup_question": "원인을 찾는 데 3일이 걸렸다고 하셨는데, 당시 로그가 부족한 상황에서 어떤 과정을 거쳐 SQLite의 락 문제를 확인하셨나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 4.0, "logic": 3.0, "structure": "PARTIAL_STAR", "correctness": 5.0}, "latency_sec": 9.939, "ttft_sec": 5.714, "in_tokens": 1734, "out_tokens": 84} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-backend-isolation-strong", "rep": 0, "ok": true, "followup_question": "조회 조건을 created_at 기준으로 고정하더라도, REPEATABLE READ를 사용했을 때 발생하는 스냅샷 유지로 인한 vacuum 지연 문제는 해결되지 않나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 4.0, "logic": 4.0, "structure": "NONE", "correctness": null}, "latency_sec": 7.94, "ttft_sec": 3.748, "in_tokens": 1414, "out_tokens": 80} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-integrated-tradeoff-strong", "rep": 0, "ok": true, "followup_question": "Yjs 도입 시 번들 크기가 80KB 증가한다고 하셨는데, 이 크기가 전체 서비스 성능이나 초기 로딩 속도에 미치는 영향은 어느 정도였나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 5.0, "logic": 4.0, "structure": "PARTIAL_STAR", "correctness": 5.0}, "latency_sec": 10.414, "ttft_sec": 5.689, "in_tokens": 1734, "out_tokens": 88} +{"label": "q-gemma4-26b-UD-IQ3_S", "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": 6.643, "ttft_sec": 3.603, "in_tokens": 1359, "out_tokens": 69} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-dba-vague-weak", "rep": 0, "ok": true, "followup_question": "gh-ost를 사용하면서 '조심해서 잘 썼다'고 하셨는데, 구체적으로 어떤 운영 지표나 상황을 모니터링하며 주의하셨나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 1.0, "logic": 1.0, "structure": "NONE", "correctness": null}, "latency_sec": 8.937, "ttft_sec": 4.723, "in_tokens": 1578, "out_tokens": 84} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-infra-fact-mismatch", "rep": 0, "ok": true, "followup_question": "스토리지 풀 장애를 해결하기 위해 리전 이중화와 페일오버를 선택하셨는데, 이것이 스토리지 용량 부족이라는 근본 원인을 해결하는 방법인가요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 1.0, "logic": 1.0, "structure": "PARTIAL_STAR", "correctness": 2.0}, "latency_sec": 9.989, "ttft_sec": 5.25, "in_tokens": 1666, "out_tokens": 92} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-backend-fact-mismatch", "rep": 0, "ok": true, "followup_question": "이력서에는 5시간에서 40분으로 개선했다고 적혀 있는데, Spark를 도입해 10분으로 줄였다는 말씀은 어떤 의미인가요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 1.0, "logic": 1.0, "structure": "NONE", "correctness": 1.0}, "latency_sec": 10.291, "ttft_sec": 5.665, "in_tokens": 1785, "out_tokens": 83} +{"label": "q-gemma4-26b-UD-IQ3_S", "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.143, "ttft_sec": 3.468, "in_tokens": 1344, "out_tokens": 76} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-offtopic-weak", "rep": 0, "ok": true, "followup_question": "질문은 Kafka와 RabbitMQ의 기술적 차이를 묻는 것이었습니다. 두 브로커의 처리량이나 메시지 보장 방식 측면에서 어떤 차이가 있다고 생각하시나요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 8.468, "ttft_sec": null, "in_tokens": 1364, "out_tokens": 89} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-dk-no-experience", "rep": 0, "ok": true, "followup_question": "직접적인 경험은 없더라도, 자발적 중단(Voluntary Disruption) 상황에서 서비스 가용성을 유지하기 위해 어떤 원리로 동작해야 하는지 설명해 주실 수 있나요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 8.423, "ttft_sec": null, "in_tokens": 1347, "out_tokens": 90} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-dk-pass", "rep": 0, "ok": true, "followup_question": "답변하기 어려우시다면, 브라우저가 화면을 그릴 때 요소의 크기나 위치가 바뀌는 과정(Reflow)과 색상만 바뀌는 과정(Repaint)의 차이 위주로 다시 설명해 드릴까요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 9.388, "ttft_sec": null, "in_tokens": 1334, "out_tokens": 101} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-dk-forgot", "rep": 0, "ok": true, "followup_question": "기억이 나지 않으신다면, 혹시 복구 훈련 시 사용하셨던 스냅샷 복원이나 binlog 재적용 단계 중 어느 쪽이 더 시간이 많이 소요되는 구조였는지 설명해 주실 수 있나요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 10.086, "ttft_sec": null, "in_tokens": 1579, "out_tokens": 101} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-dk-english", "rep": 0, "ok": true, "followup_question": "CAP 정리에서 네트워크 분할(Partition)이 발생했을 때, 왜 일관성과 가용성을 동시에 만족할 수 없는지 다시 한번 설명해 주실 수 있을까요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 8.094, "ttft_sec": null, "in_tokens": 1341, "out_tokens": 84} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-dk-stt-fragment", "rep": 0, "ok": true, "followup_question": "Terraform workspace와 디렉터리 분리 방식의 차이 중, 상태 파일(tfstate) 관리 측면에서 어떤 차이가 있는지 다시 설명해 드릴까요?", "answer_intent": "DONT_KNOW", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 7.765, "ttft_sec": null, "in_tokens": 1336, "out_tokens": 83} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-cl-term", "rep": 0, "ok": true, "followup_question": "멱등성이란 동일한 요청을 여러 번 보내도 서버의 상태가 처음 한 번의 요청과 동일하게 유지되는 성질을 의미합니다. 결제 API에서 중복 결제를 방지하기 위해 HTTP 레벨에서 이를 어떻게 구현할 수 있을까요?", "answer_intent": "CLARIFICATION", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 9.076, "ttft_sec": 3.872, "in_tokens": 1352, "out_tokens": 102} +{"label": "q-gemma4-26b-UD-IQ3_S", "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": 8.816, "ttft_sec": 3.94, "in_tokens": 1361, "out_tokens": 87} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-cl-example", "rep": 0, "ok": true, "followup_question": "사용자가 조회하려는 컬럼들이 모두 인덱스에 포함되어 있어, 실제 데이터 페이지(Table Heap/Clustered Index)를 방문하지 않고 인덱스만으로 결과를 반환하는 상황을 말씀드리는 것입니다.", "answer_intent": "CLARIFICATION", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 8.113, "ttft_sec": 3.594, "in_tokens": 1344, "out_tokens": 95} +{"label": "q-gemma4-26b-UD-IQ3_S", "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": 7.475, "ttft_sec": 3.677, "in_tokens": 1358, "out_tokens": 77} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-cl-stt-noisy", "rep": 0, "ok": true, "followup_question": "팀 내에서 기술 부채를 해결하기 위해 동료나 상사를 설득해 본 경험이 있는지 여쭤보았습니다.", "answer_intent": "CLARIFICATION", "answer_evaluation": {"specificity": 0.0, "logic": 0.0, "structure": "NONE", "correctness": null}, "latency_sec": 7.337, "ttft_sec": 3.714, "in_tokens": 1345, "out_tokens": 73} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-motivation-strong", "rep": 0, "ok": true, "followup_question": "멱등 키와 Outbox 패턴을 적용해 중복 주문을 0건으로 만드셨는데, 당시 발생했던 구체적인 장애 상황과 해결 과정을 설명해 주시겠어요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 4.0, "logic": 4.0, "structure": "PARTIAL_STAR", "correctness": 5.0}, "latency_sec": 10.483, "ttft_sec": 5.537, "in_tokens": 1852, "out_tokens": 89} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-repeat-history-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.795, "ttft_sec": 3.599, "in_tokens": 1415, "out_tokens": 83} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-confirm-correction", "rep": 0, "ok": true, "followup_question": "환경별 workspace를 분리할 때, 각 환경 간의 변수나 설정값 차이는 어떻게 관리하셨나요?", "answer_intent": "NORMAL", "answer_evaluation": {"specificity": 2.0, "logic": 3.0, "structure": "NONE", "correctness": null}, "latency_sec": 7.167, "ttft_sec": 4.039, "in_tokens": 1360, "out_tokens": 70} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "followup", "case_id": "f2-confirm-yes", "rep": 0, "ok": true, "followup_question": "NextAuth의 기본 Provider를 사용하면서 별도의 커스텀 로직 없이 카카오에서 전달하는 유저 정보만 그대로 사용하셨나요?", "answer_intent": "NORMAL", "answer_evaluation": null, "latency_sec": 7.166, "ttft_sec": 3.488, "in_tokens": 1349, "out_tokens": 73} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "coaching", "case_id": "c-weak-backend", "rep": 0, "ok": true, "coaching": {"model_answer": "두 기술을 함께 사용한 이유는 **'중복 요청 방지'**와 **'데이터 일관성 보장'**이라는 서로 다른 계층의 문제를 동시에 해결하기 위해서였습니다.\n\n1. **Idempotency Key (멱등성 키)**: 결제 승인 콜백이 지연되어 클라이언트나 외부 시스템에서 동일한 요청을 재전송(Retry)할 때, 이미 처리된 요청임을 식별하여 **중복 주문 생성을 방지**하는 역할을 합니다.\n2. **Transactional Outbox Pattern**: 주문 생성과 Kafka 이벤트 발행 사이의 원자성(Atomicity)을 보장하기 위해 사용했습니다. 주문 DB 업데이트는 성공했지만 메시지 발행에 실패할 경우, 서비스 간 데이터 불일치가 발생하는데, Outbox 패턴을 통해 **주문 데이터와 이벤트 데이터를 하나의 트랜잭션으로 묶어 발행 실패 시에도 최종적인 메시지 전달을 보장**합니다.\n\n결과적으로 멱등성 키로 중복 진입을 막고, Outbox 패턴으로 시스템 간 상태 불일치를 막아 중복 주문 0건을 달성할 수 있었습니다.", "answer_rewrite": "질문하신 두 기술은 해결하고자 하는 실패 케이스가 서로 다릅니다.\n\n먼저 **멱등성 키**는 외부 시스템의 재시도 요청으로 인해 동일한 주문이 여러 번 생성되는 **'중복 요청'** 문제를 막기 위해 도입했습니다. 멱등성 테이블을 통해 이미 처리된 요청인지 확인하여 중복 주문을 차단합니다.\n\n반면 **Transactional Outbox 패턴**은 주문 생성과 Kafka 이벤트 발행 사이의 **'원자성 결여'** 문제를 해결하기 위해 사용했습니다. 주문은 생성되었으나 이벤트 발행에 실패하여 후속 서비스(정산, 배송 등)로 데이터가 전달되지 않는 상황을 방지하여, 시스템 간 데이터 일관성을 유지하도록 설계했습니다.", "coaching_comment": "기술의 도입 목적과 각 기술이 해결하는 구체적인 실패 시나리오를 구분하여 설명해야 합니다."}, "latency_sec": 37.74, "in_tokens": 1398, "out_tokens": 464} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "coaching", "case_id": "c-dont-know-cs", "rep": 0, "ok": true, "coaching": {"model_answer": "PostgreSQL의 MVCC 구조에서 오래 열린 트랜잭션(Long-running transaction)은 **xmin horizon**을 고정시키는 문제를 일으킵니다. Vacuum 프로세스는 `xmin horizon`보다 오래된(즉, 현재 진행 중인 트랜잭션이 참조할 가능성이 있는) **Dead Tuple**을 삭제해야 하는데, 트랜잭션이 종료되지 않으면 해당 튜플들이 여전히 '사용 중'인 것으로 간주되어 회수되지 못합니다.\n\n이로 인해 삭제된 데이터가 물리적으로 제거되지 못하고 쌓이게 되어 **Table Bloat**(테이블 비대화) 현상이 발생하며, 이는 디스크 공간 낭비뿐만 아니라 Index Scan 성능 저하 및 I/O 부하 증가로 이어집니다.", "answer_rewrite": "현재 해당 개념에 대해 정확히 답변드리기 어렵습니다. 다만, PostgreSQL의 MVCC 메커니즘상 트랜잭션이 종료되지 않으면 Vacuum이 Dead Tuple을 정리하지 못해 Table Bloat이 발생할 수 있다는 점은 인지하고 있습니다. 추후 xmin horizon과 Vacuum의 동작 원리에 대해 명확히 학습하여 보완하겠습니다.", "coaching_comment": "모르는 질문을 받았을 때 단순히 포기하기보다, 아는 범위까지 설명하거나 학습 의지를 보여주는 태도가 중요합니다."}, "latency_sec": 22.21, "in_tokens": 931, "out_tokens": 304} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "coaching", "case_id": "c-personality-rambling", "rep": 0, "ok": true, "coaching": {"model_answer": "### [Situation & Task]\n캡스톤 프로젝트 진행 당시, 프론트엔드 팀원과 API 스펙 해석 차이로 인해 통합 직전 단계에서 개발이 2주간 지연되는 상황이 발생했습니다.\n\n### [Action]\n초기에는 제 방식이 옳다고 주장하며 팀원과 감정적인 갈등을 겪기도 했으나, 문제 해결을 위해 두 가지 행동을 취했습니다. 첫째, **OpenAPI 명세**를 선제적으로 작성하고 **Mock 서버**를 구축하여 프론트엔드 팀이 백엔드 개발 완료를 기다리지 않고 병렬로 개발할 수 있는 환경을 제안했습니다. 둘째, 의견 충돌 시 독단적으로 결정하기보다 **두 가지 이상의 대안을 함께 비교**하는 프로세스를 도입했습니다.\n\n### [Result]\n그 결과, 이후 스프린트에서는 API 관련 통합 이슈를 **3건에서 0건으로** 줄일 수 있었으며, 기술적 소통의 기준을 명확히 하여 협업 효율을 높이는 법을 배웠습니다.", "answer_rewrite": "저는 의견 충돌이 발생했을 때, 감정적인 대응보다는 **객관적인 기준과 프로세스**를 통해 해결하려 노력합니다.\n\n실제로 캡스톤 프로젝트 당시 API 스펙 해석 차이로 개발이 2주간 지연된 적이 있습니다. 초기에는 제 의견을 고집하여 팀원과 갈등을 겪기도 했지만, 이를 해결하기 위해 **OpenAPI 명세 작성과 Mock 서버 구축**을 제안하여 프론트엔드 팀의 병렬 개발을 도왔습니다.\n\n이 경험을 통해 소통의 핵심은 단순히 '말을 많이 하는 것'이 아니라, **명확한 문서화와 대안 비교 프로세스**를 갖추는 것임을 깨달았습니다. 이후에는 결정 전 대안들을 함께 비교하는 방식을 도입하여 통합 이슈를 0건으로 줄이는 성과를 거두었습니다.", "coaching_comment": "추상적인 '소통이 중요하다'는 말 대신, 본인의 경험(API 스펙 갈등)과 구체적인 해결 도구(OpenAPI, Mock 서버)를 사용하여 STAR 구조로 답변해야 합니다."}, "latency_sec": 35.375, "in_tokens": 1266, "out_tokens": 503} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "coaching", "case_id": "c2-f-strong-backend", "rep": 0, "ok": true, "coaching": {"model_answer": "두 패턴을 함께 사용한 이유는 **'요청의 중복 처리 방지(Idempotency)'**와 **'데이터 상태와 이벤트 발행의 원자성 보장(Atomicity)'**이라는 서로 다른 계층의 문제를 해결하기 위해서입니다.\n\n첫째, **Idempotency Key**는 외부 시스템(PG사)으로부터의 **중복 요청**을 막는 역할을 합니다. 네트워크 타임아웃 등으로 인해 동일한 결제 승인 콜백이 재전송될 때, DB의 Unique 제약 조건을 활용해 중복 주문 생성을 원천 차단합니다.\n\n둘째, **Transactional Outbox Pattern**은 내부 시스템의 **데이터 불일치**를 막습니다. 주문 생성 트랜잭션은 성공했으나 메시지 브로커(Kafka)로의 이벤트 발행에 실패할 경우, 주문 데이터와 후속 프로세스 간의 정합성이 깨지게 됩니다. 이를 방지하기 위해 Outbox 테이블에 이벤트를 함께 저장하여, DB 트랜잭션이 커밋되는 순간 이벤트 저장도 보장되도록 설계했습니다.", "answer_rewrite": "두 패턴은 해결하고자 하는 실패 케이스의 성격이 다르기 때문에 함께 도입했습니다.\n\n먼저 **Idempotency Key**는 **외부로부터의 중복 요청**을 방지합니다. PG사가 타임아웃 후 동일한 승인 건을 재전송할 때, 결제 키에 Unique 제약을 걸어 두 번째 요청이 들어와도 주문이 중복 생성되지 않고 기존 상태를 반환하도록 설계했습니다.\n\n반면 **Outbox 패턴**은 **내부 시스템의 원자성(Atomicity) 문제**를 해결합니다. 주문 저장과 Kafka 발행이 별개의 트랜잭션일 경우, 주문은 생성되었으나 이벤트 발행에 실패하여 데이터 불일치가 발생하는 케이스를 막기 위함입니다. 이를 위해 Outbox 테이블에 이벤트를 함께 기록하고 Relay가 이를 폴링하여 발행하도록 구현했습니다.\n\n결과적으로 이러한 이중 방어 체계를 통해 월 30건 발생하던 중복 주문 문제를 0건으로 개선할 수 있었습니다.", "coaching_comment": "두 기술이 해결하는 문제의 핵심 키워드인 '중복 요청 방지'와 '트랜잭션 원자성 보장'을 명확히 대조하여 설명하는 것이 중요합니다."}, "latency_sec": 36.231, "in_tokens": 1105, "out_tokens": 532} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "coaching", "case_id": "c2-f-infra-fact-error", "rep": 0, "ok": true, "coaching": {"model_answer": "저는 EKS 환경에서 **CPU 사용률 70%**를 HPA의 주요 메트릭으로 설정하여 운영했습니다. 단순히 리소스 사용량에만 의존하지 않고, 서비스의 특성을 고려하여 설계했습니다.\n\n특히 트래픽 피크 타임에 대한 대응을 위해 두 가지 전략을 병행했습니다. 첫째, **HPA를 통한 자동 스케일링**을 기본으로 하되, 둘째로 **CronJob을 활용한 사전 스케일아웃(Scheduled Scaling)**을 도입했습니다. 월급날 오전 10시와 같이 트래픽이 급증하는 특정 시점에는 HPA가 메트릭 변화를 감지하고 Pod을 생성하는 데 물리적인 지연 시간이 발생할 수 있기 때문입니다. 이를 방지하기 위해 피크 타임 직전에 미리 인스턴스를 확보함으로써 서비스 가용성을 안정적으로 유지했습니다.", "answer_rewrite": "HPA는 서비스의 안정성을 고려하여 **CPU 사용률 70%**를 기준으로 설정하여 운영했습니다. \n\n트래픽 피크 대응의 경우, HPA의 자동 스케일링만으로는 급격한 트래픽 증가 시 Pod 생성 지연(Latency) 문제를 해결하기 어렵다고 판단했습니다. 따라서 월급날 오전 10시와 같이 트래픽이 집중되는 시점에는 **CronJob을 이용한 사전 스케일아웃** 방식을 병행하여, 트래픽이 몰리기 전에 미리 리소스를 확보함으로써 서비스 중단 없이 대응할 수 있도록 설계했습니다.", "coaching_comment": "본인의 이력서에 기재된 구체적인 수치(CPU 70%, 월급날 10시)와 기술적 근거(CronJob 활용)를 활용하여 답변의 신뢰도를 높여야 합니다."}, "latency_sec": 30.354, "in_tokens": 1248, "out_tokens": 411} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "coaching", "case_id": "c2-f-personality-star", "rep": 0, "ok": true, "coaching": {"model_answer": "캡스톤 디자인 프로젝트 당시, API 스펙 해석 차이로 인해 프론트엔드와 백엔드 간의 통합 작업이 지연되는 상황이 발생했습니다. 당시 통합 일정이 2주가량 밀린 상태였기에, 저는 단순히 스펙을 수정하는 것을 넘어 개발 프로세스 자체를 개선하기로 했습니다.\n\n먼저 **OpenAPI 명세**를 기반으로 **Mock Server**를 구축하여 프론트엔드 팀원이 백엔드 구현 완료를 기다리지 않고 병렬로 개발할 수 있는 환경을 제안했습니다. 그 결과, 이후 스프린트부터 통합 과정에서 발생하는 이슈를 3건에서 0건으로 줄이며 개발 효율을 높일 수 있었습니다. 이 과정에서 기술적 해결만큼이나 중요한 것이 '의사결정 방식'임을 배웠으며, 이후에는 의견 충돌 시 대안들을 객관적으로 비교 분석하는 프로세스를 도입하여 팀의 협업 효율을 높이고 있습니다.", "answer_rewrite": "캡스톤 프로젝트 중 API 스펙 해석 차이로 인해 통합 일정이 2주 지연되는 문제를 겪었습니다. \n\n**[Situation & Task]** 통합 직전 단계에서 발생한 문제라 일정 복구가 시급했고, 저는 개발 병목 현상을 해결해야 하는 과제를 맡았습니다.\n\n**[Action]** 이를 해결하기 위해 **OpenAPI 명세**를 선제적으로 작성하고 **Mock Server**를 띄워, 프론트엔드 팀원이 백엔드 완성 여부와 상관없이 병렬로 개발할 수 있도록 프로세스를 제안했습니다.\n\n**[Result]** 그 결과, 다음 스프린트부터 통합 이슈가 3건에서 0건으로 감소하며 일정을 정상화할 수 있었습니다. \n\n**[Learning]** 다만, 초기에는 제 방식만을 고집하여 팀원과 소통에 어려움을 겪기도 했습니다. 이를 계기로 의사결정 시 감정적인 대립을 피하고자 '두 가지 이상의 대안을 수치나 근거로 비교하는 방식'을 도입하여 협업 태도를 개선했습니다.", "coaching_comment": "문제 해결을 위한 기술적 조치(Mock Server)와 소통 방식의 개선(대안 비교)을 STAR 구조에 맞춰 명확히 분리하여 전달하세요."}, "latency_sec": 34.99, "in_tokens": 1031, "out_tokens": 516} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "coaching", "case_id": "c2-f-stt-messy-normal", "rep": 0, "ok": true, "coaching": {"model_answer": "낙관적 락(Optimistic Lock)은 충돌이 적은 상황에서는 성능상 이점이 있지만, 타임세일과 같이 특정 상품에 트래픽이 집중되는 상황에서는 **Version Conflict**가 빈번하게 발생합니다. 이로 인해 발생하는 **Retry 로직의 반복 실행**은 CPU와 DB 자원을 과도하게 소모하며, 결과적으로 시스템 전체의 처리량을 저하시키는 원인이 됩니다.\n\n이를 해결하기 위해 Redis 기반의 **Distributed Lock(분산 락)**을 도입했습니다. 낙관적 락은 충돌 후 사후 처리에 비용이 들지만, 분산 락은 진입 단계에서 원자적(Atomic)으로 권한을 제어하여 불필요한 재시도 비용을 줄입니다. 이를 통해 데이터 불일치 건수를 월 200건에서 3건으로 개선하며 시스템의 안정성을 확보할 수 있었습니다.", "answer_rewrite": "기존에는 낙관적 락을 사용하여 재고를 관리했습니다. 하지만 타임세일과 같이 단일 상품에 요청이 몰리는 상황에서는 **Version Conflict**가 빈번하게 발생했고, 이를 해결하기 위한 **재시도(Retry) 로직이 반복되면서 DB 부하가 급격히 증가**하는 문제가 있었습니다.\n\n따라서 충돌이 발생한 후 재시도하는 방식 대신, 데이터 접근 전 단계에서 권한을 제어하는 **Redis 분산 락**으로 전환했습니다. 그 결과, 불필요한 재시도 비용을 줄여 시스템 부하를 안정화했으며, 데이터 불일치 발생 건수를 월 200건에서 3건으로 대폭 감소시킬 수 있었습니다.", "coaching_comment": "단순히 '현상이 발생해서 바꿨다'는 서술을 넘어, 낙관적 락의 메커니즘(충돌 후 재시도 비용)과 분산 락의 메커니즘(사전 제어) 사이의 트레이드오프를 기술적으로 설명해야 합니다."}, "latency_sec": 31.143, "in_tokens": 1005, "out_tokens": 460} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "coaching", "case_id": "c2-f-english-mixed", "rep": 0, "ok": true, "coaching": {"model_answer": "기존에는 Zustand와 같은 전역 상태 관리 라이브러리를 사용하여 서버 데이터를 관리했습니다. 이 방식은 클라이언트 상태와 서버 상태를 구분하지 못해, 데이터의 유효성(freshness)을 판단하거나 캐시를 무효화(invalidation)하는 로직을 개발자가 직접 구현해야 한다는 번거로움이 있었습니다. 이로 인해 stale data가 화면에 노출되는 버그가 발생하곤 했습니다.\n\nTanStack Query를 도입함으로써 **서버 상태와 클라이언트 상태를 명확히 분리**할 수 있었습니다. `staleTime`과 `cacheTime` 설정을 통해 데이터의 유효 기간을 선언적으로 관리하고, `useMutation` 이후 `invalidateQueries`를 호출하여 선언적인 데이터 갱신이 가능해졌습니다. 또한, 동일한 Query Key에 대한 **Request Deduplication** 기능을 통해 불필요한 네트워크 요청을 방지하여 효율적인 리소스 관리가 가능해졌습니다.", "answer_rewrite": "기존에는 Zustand로 fetch 결과까지 관리하며 **Client State와 Server State를 혼용**해 사용했습니다. 이로 인해 캐시 무효화(Cache Invalidation) 로직을 직접 구현해야 했고, 데이터의 유효성을 관리하는 과정에서 stale data가 발생하는 이슈가 있었습니다.\n\n이를 해결하기 위해 TanStack Query를 도입하여 다음과 같은 개선을 이루었습니다.\n1. **데이터 유효성 관리**: 화면별 특성에 맞춰 `staleTime`을 다르게 설정하여 데이터의 freshness를 제어했습니다.\n2. **선언적 데이터 갱신**: Mutation 발생 시 `invalidateQueries`를 사용하여 복잡한 로직 없이 목록을 갱신했습니다.\n3. **네트워크 최적화**: 동일한 Query Key에 대한 요청이 중복되지 않도록 **Request Deduplication**이 작동하여, 결과적으로 네트워크 요청을 약 40% 감소시켰습니다.", "coaching_comment": "클라이언트 상태와 서버 상태를 분리한다는 개념적 차이를 명확히 언급하고, 기술적 용어(Request Deduplication, Freshness 등)를 사용하여 전문성을 높이세요."}, "latency_sec": 32.919, "in_tokens": 986, "out_tokens": 479} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "coaching", "case_id": "c2-f2-frontend-a11y-strong", "rep": 0, "ok": true, "coaching": {"model_answer": "무한 스크롤은 키보드 사용자나 스크린 리더 사용자가 페이지 하단(Footer)에 접근하는 것을 방해하는 'Trapped Focus' 문제를 일으킬 수 있습니다. 이를 해결하기 위해 저는 두 가지 전략을 사용했습니다.\n\n첫째, **사용자 제어권 확보**를 위해 무한 스크롤 중간에 '더 보기' 버튼을 배치하는 하이브리드 방식을 도입했습니다. 이는 사용자가 스크롤을 멈추고 의도적으로 콘텐츠를 더 불러올지, 아니면 푸터로 이동할지 선택할 수 있게 합니다. \n둘째, **상태 변화 알림**을 위해 `aria-live=\"polite\"`를 활용하여 새로운 콘텐츠가 로드되었음을 스크린 리더 사용자에게 전달하고, 새로 추가된 콘텐츠의 첫 번째 요소로 포커스를 적절히 관리하여 탐색 흐름이 끊기지 않도록 설계했습니다. 이를 통해 Lighthouse 접근성 점수를 72점에서 89점까지 개선할 수 있었습니다.", "answer_rewrite": "무한 스크롤 구현 시 키보드 사용자가 푸터(Footer)에 접근하지 못하는 문제를 인지하고, 이를 해결하기 위해 **'더 보기' 버튼을 결합한 하이브리드 방식**을 도입했습니다.\n\n* **상황**: IntersectionObserver 기반의 무한 스크롤은 스크롤 흐름을 끊기 어렵게 만들어 키보드 탭 이동 시 푸터 접근성을 저해했습니다.\n* **행동**: 20개의 아이템마다 '더 보기' 버튼을 배치하여 사용자에게 제어권을 부여했고, 새로운 데이터 로드 시 `aria-live=\"polite\"`를 통해 상태 변화를 알렸습니다. 또한, 새로 추가된 콘텐츠의 첫 게시글로 포커스를 이동시켜 탐색의 연속성을 유지했습니다.\n* **결과**: 이러한 접근성 개선을 통해 Lighthouse 접근성 점수를 72점에서 89점까지 향상시킬 수 있었습니다.", "coaching_comment": "문제 상황-해결 방법-결과로 이어지는 구조는 좋으나, '왜' 그 기술(aria-live, 버튼)을 선택했는지에 대한 논리적 근거를 보완하면 더 완벽합니다."}, "latency_sec": 35.574, "in_tokens": 1214, "out_tokens": 510} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "coaching", "case_id": "c2-f2-dba-vague-weak", "rep": 0, "ok": true, "coaching": {"model_answer": "기존의 `pt-online-schema-change`와 같은 트리거 기반 방식은 데이터 변경 시 트리거로 인한 추가적인 부하와 복제 지연(Replication Lag)을 유발할 위험이 있었습니다. 특히 저희 서비스는 일 쓰기 2천만 건에 달하는 대용량 트래픽을 처리하고 있어, 서비스 안정성을 최우선으로 고려하여 **트리거 없이 Binlog를 직접 읽어 변경 사항을 반영하는 `gh-ost`를 도입**했습니다.\n\n운영 시에는 두 가지를 가장 주의했습니다. 첫째, **부하 제어(Throttling)**입니다. 복제 지연이 발생할 경우 `gh-ost`가 자동으로 동작을 조절하도록 설정하여 DB 성능에 영향을 주지 않도록 했습니다. 둘째, **Cut-over 단계의 락(Lock) 관리**입니다. 최종적으로 테이블을 교체하는 시점에 아주 짧은 순간 Metadata Lock이 발생할 수 있으므로, 트래픽이 가장 낮은 시간대에 실행하거나 락 대기 시간을 모니터링하며 신중하게 진행했습니다.", "answer_rewrite": "**(상황/과제)** 대용량 트래픽 환경에서 스키마 변경 시 발생하는 서비스 중단이나 성능 저하를 방지하기 위해 `gh-ost`를 도입했습니다. 기존 트리거 방식은 쓰기 부하가 높다는 단점이 있었기 때문입니다.\n\n**(행동)** `gh-ost`를 사용하여 트리거 없이 Binlog를 기반으로 스키마 변경을 수행함으로써 DB 부하를 최소화했습니다. 특히 운영 중에는 **복제 지연(Replication Lag) 발생 시 동작을 제어하는 Throttling 옵션**을 활용하여 서비스 영향도를 관리했습니다.\n\n**(결과)** 이를 통해 컬럼 추가 등의 대규모 스키마 변경 시에도 **락 대기 장애 0건**을 유지하며 안정적으로 운영할 수 있었습니다.", "coaching_comment": "단순히 '조심해서 썼다'는 표현 대신, gh-ost의 핵심 메커니즘인 '트리거 미사용'과 운영 포인트인 '부하 제어 및 락 관리'를 구체적인 용어로 설명해야 합니다."}, "latency_sec": 35.209, "in_tokens": 1157, "out_tokens": 500} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "coaching", "case_id": "c2-f2-backend-fact-mismatch", "rep": 0, "ok": true, "coaching": {"model_answer": "정산 배치 프로세스의 병목을 진단하여 실행 시간을 5시간에서 40분으로 약 86% 단축시킨 경험이 있습니다.\n\n* **상황 및 문제**: 기존 정산 로직이 대량의 데이터를 처리하는 과정에서 DB 부하와 메모리 부족 문제를 겪으며 실행 시간이 지나치게 길었습니다.\n* **해결 과정**: \n 1. **QueryDSL 튜닝**: 불필요한 Join과 Fetch Join을 최적화하고, N+1 문제를 해결하여 DB I/O를 줄였습니다.\n 2. **Chunk 기반 처리**: 전체 데이터를 한 번에 메모리에 올리는 대신, Spring Batch의 Chunk 지향 처리를 적용하여 메모리 사용량을 안정화했습니다.\n 3. **Index 재설계**: 정산 조건절에 사용되는 컬럼들을 중심으로 인덱스를 재설계하여 Scan 범위를 최소화했습니다.\n* **결과**: 이를 통해 데이터 처리 효율을 높였고, 정산 배치 시간을 5시간에서 40분으로 개선하여 정산 업무의 적시성을 확보했습니다.", "answer_rewrite": "정산 배치 성능을 개선하여 기존 5시간 걸리던 작업을 40분으로 단축시킨 경험이 있습니다.\n\n당시 병목 지점을 파악하기 위해 실행 계획을 분석한 결과, 비효율적인 쿼리와 메모리 관리 문제가 확인되었습니다. 이를 해결하기 위해 첫째, **QueryDSL을 튜닝**하여 불필요한 데이터 조회를 줄였고, 둘째, **Chunk 단위 처리**를 도입하여 메모리 부하를 방지했습니다. 마지막으로 **인덱스를 재설계**하여 데이터 접근 속도를 높였습니다. 결과적으로 정산 프로세스의 안정성과 속도를 모두 개선할 수 있었습니다.", "coaching_comment": "이력서에 기재된 실제 성과(5시간 -> 40분)와 구체적인 기술적 조치(QueryDSL, Chunk, Index)를 연결하여 논리적으로 답변해야 합니다."}, "latency_sec": 33.389, "in_tokens": 1365, "out_tokens": 459} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "coaching", "case_id": "c2-f2-personality-generic-weak", "rep": 0, "ok": true, "coaching": {"model_answer": "저의 강점은 **인프라 운영의 안정성을 확보하기 위한 '철저한 책임감'과 '문제 해결 중심의 커뮤니케이션'**입니다.\n\n[Situation & Task] 인프라 엔지니어는 서비스의 연속성을 책임져야 하기에, 장애 발생 시 신속한 대응과 재발 방지가 핵심입니다.\n[Action] 저는 단순히 주어진 업무를 수행하는 것에 그치지 않고, 장애 상황 발생 시 원인을 끝까지 추적하여 근본적인 해결책을 제시하는 것을 원칙으로 삼습니다. 또한, 유관 부서와 협업 시 기술적 이슈를 비전공자도 이해할 수 있는 언어로 전달하여 의사결정 속도를 높이는 데 주력합니다.\n[Result] 이러한 태도를 통해 인프라 가용성을 극대화하고, 팀 내 협업 효율을 높여 안정적인 서비스 운영에 기여할 수 있습니다.", "answer_rewrite": "저는 **인프라 운영의 핵심인 '책임감'과 '원활한 협업 능력'**을 갖추고 있습니다.\n\n첫째, 맡은 업무를 끝까지 완수하는 책임감을 바탕으로 인프라의 안정성을 유지합니다. 단순히 현상을 해결하는 것에 그치지 않고, 문제의 근본 원인을 파악하여 재발을 방지하는 태도를 지향합니다.\n둘째, 다양한 이해관계자와의 커뮤니케이션 역량을 보유하고 있습니다. 인프라 이슈는 개발 및 운영 팀과의 긴밀한 소통이 필수적인 만큼, 정확한 정보 전달을 통해 협업 시너지를 높이는 데 기여하겠습니다.", "coaching_comment": "추상적인 형용사(성실함, 잘함) 대신 직무 역량과 연결된 구체적인 행동 양식과 그로 인한 기대 효과를 제시해야 합니다."}, "latency_sec": 29.326, "in_tokens": 927, "out_tokens": 420} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "coaching", "case_id": "c2-f2-offtopic-weak", "rep": 0, "ok": true, "coaching": {"model_answer": "Kafka와 RabbitMQ의 핵심적인 설계 차이인 **데이터 처리 방식**과 **메시지 보존 방식**을 고려했습니다. \n\n첫째, **Throughput(처리량)** 측면에서 Kafka는 로그 기반의 Sequential I/O를 사용하여 대용량 데이터를 고속으로 처리하는 데 최적화되어 있습니다. 둘째, **Message Replay(재처리)** 기능입니다. RabbitMQ는 메시지가 소비되면 즉시 삭제되는 구조인 반면, Kafka는 Consumer Offset을 관리하며 과거 데이터를 다시 읽어올 수 있는 기능이 있어 데이터 유실 시나리오나 장애 복구에 유리하다고 판단했습니다. 따라서 대규모 스트림 데이터를 안정적으로 처리하기 위해 Kafka를 선택했습니다.", "answer_rewrite": "질문하신 의도대로 Kafka와 RabbitMQ 사이에서 고민이 있었으나, 프로젝트의 목적에 따라 Kafka를 선택했습니다. \n\n당시 프로젝트에서는 단순히 메시지를 전달하는 것을 넘어, 데이터의 흐름을 관리하고 필요 시 데이터를 다시 읽어오는 **Replay 기능**이 중요하다고 판단했습니다. RabbitMQ는 메시지 전달 중심의 Broker인 반면, Kafka는 로그 기반의 **Distributed Commit Log** 구조를 가져 대용량 처리에 유리하고 데이터 보존이 가능하다는 점이 프로젝트 요구사항에 더 적합하다고 생각하여 Kafka를 도입했습니다.", "coaching_comment": "질문에 대한 기술적 비교 근거 없이 본인의 관심사로 화제를 돌리는 것은 질문의 의도를 회피하는 인상을 줄 수 있으니 주의해야 합니다."}, "latency_sec": 24.365, "in_tokens": 947, "out_tokens": 347} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "coaching", "case_id": "c2-f2-dk-no-experience", "rep": 0, "ok": true, "coaching": {"model_answer": "PodDisruptionBudget(PDB)은 클러스터의 **Voluntary Disruption(자발적 중단)** 상황에서 서비스의 최소 가용성을 보장하기 위해 필요합니다. \n\n예를 들어, 노드 업그레이드를 위해 `kubectl drain`을 수행하거나, 클러스터 오토스케일러가 노드를 축소할 때, 특정 애플리케이션의 Pod이 한꺼번에 종료되어 서비스 장애로 이어지는 것을 방지할 수 있습니다. PDB를 통해 '최소한 이만큼의 Pod은 항상 떠 있어야 한다'는 규칙을 설정하면, 쿠버네티스 스케줄러는 해당 규칙을 위반하는 중단 요청을 거부하거나 조절하여 서비스 안정성을 유지합니다.", "answer_rewrite": "해당 기능을 직접 운영 환경에 적용해 본 경험은 없으나, 개념적으로는 **자발적 중단(Voluntary Disruption)** 시 서비스 가용성을 유지하기 위해 사용되는 것으로 알고 있습니다. 노드 드레인이나 클러스터 업그레이드 과정에서 Pod이 과도하게 종료되는 것을 막기 위해, 최소 유지해야 하는 Pod의 개수나 비율을 설정하여 서비스 중단을 방지하는 역할을 합니다.", "coaching_comment": "모르는 질문을 받았을 때 단순히 모른다고 하기보다, 아는 범위 내의 개념을 연결하여 논리적으로 접근하는 태도가 필요합니다."}, "latency_sec": 23.199, "in_tokens": 929, "out_tokens": 321} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "coaching", "case_id": "c2-f2-integrated-tradeoff-strong", "rep": 0, "ok": true, "coaching": {"model_answer": "두 가지 측면에서 **비용 대비 효율성**을 고려하여 `last-write-wins` 전략을 선택했습니다.\n\n첫째, **충돌 발생 빈도**입니다. 로그 분석 결과, 여행 일정 서비스 특성상 한 명의 주 편집자가 존재하며 동시 편집 충돌은 월 2~3건 미만으로 매우 낮았습니다. 즉, 복잡한 알고리즘을 도입해도 사용자 경험 개선 효과가 미미하다고 판단했습니다.\n\n둘째, **기술적 오버헤드**입니다. `Yjs`와 같은 `CRDT` 라이브러리를 검토했으나, 번들 사이즈 증가(약 80KB)와 서버 측 동기화 로직의 전면적인 개편이 필요했습니다. 현재 서비스 규모에서는 이러한 인프라 비용보다, 충돌 시 사용자가 데이터를 복구할 수 있도록 **이전 버전을 7일간 보관**하는 보완책을 마련하는 것이 훨씬 실용적인 접근이라고 판단했습니다.", "answer_rewrite": "당시 서비스의 **사용 패턴과 기술적 비용**을 종합적으로 고려하여 결정했습니다.\n\n**[상황 및 분석]** 로그 분석을 통해 확인한 결과, 대부분의 사용자가 단독으로 일정을 편집하고 있었으며, 동시 편집으로 인한 충돌은 월 평균 2~3건 정도로 매우 드물게 발생했습니다.\n\n**[대안 검토]** `CRDT` 방식인 `Yjs`를 활용한 프로토타입을 구현해 보았으나, 번들 사이즈가 약 80KB 증가하고 서버 아키텍처를 대폭 수정해야 하는 리스크가 있었습니다.\n\n**[결론 및 보완]** 따라서 충돌 빈도가 낮은 상황에서 복잡도를 높이기보다는 `last-write-wins`를 채택하되, 만약의 데이터 유실에 대비해 **이전 버전을 7일간 보관**하여 사용자가 직접 복구할 수 있는 안전장치를 마련하는 방향으로 설계했습니다.", "coaching_comment": "단순히 '효과가 낮다'고 하기보다 충돌 빈도(데이터)와 기술적 비용(번들/서버)을 대조하여 의사결정의 근거를 논리적으로 제시하는 것이 좋습니다."}, "latency_sec": 36.853, "in_tokens": 1317, "out_tokens": 518} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "questions", "case_id": "q-backend-tech", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "결제 콜백 지연 문제를 Transactional Outbox 패턴으로 해결하셨는데, Outbox 테이블에 저장된 이벤트를 Kafka로 발행하는 구체적인 메커니즘은 무엇인가요?", "job_category": "BACKEND", "target_evidence": "결제 승인 콜백 지연 시 중복 주문 발생 문제: 멱등 키 테이블 + Transactional Outbox 로 해결", "expected_signal": "Outbox 패턴의 동작 원리(DB 트랜잭션과 메시지 발행의 원자성 보장)와 메시지 릴레이(Polling 또는 CDC) 방식을 정확히 설명할 수 있는가"}, {"category": "TECH_CHOICE", "question": "재고 동기화 프로젝트에서 낙관적 락을 분산 락으로 전환하셨는데, 전환을 결정하게 된 구체적인 트래픽 상황이나 기술적 한계는 무엇이었나요?", "job_category": "BACKEND", "target_evidence": "Redis 기반 재고 캐시 + DB write-behind, 동시성 제어(낙관적 락 -> 분산 락 전환)", "expected_signal": "낙관적 락의 충돌 비용과 분산 환경에서의 동시성 제어 이슈를 인지하고, Redis 분산 락 도입의 트레이드오프를 이해하고 있는가"}, {"category": "PROJECT_DEEP_DIVE", "question": "정산 배치 성능을 5시간에서 40분으로 개선하셨는데, QueryDSL 튜닝과 인덱스 재설계가 실제 실행 계획(Execution Plan)에 어떤 변화를 주었나요?", "job_category": "BACKEND", "target_evidence": "정산 배치 성능 개선: 5시간 -> 40분 (QueryDSL 튜닝, 청크 단위 처리, 인덱스 재설계)", "expected_signal": "단순히 툴을 사용한 것이 아니라, DB 인덱스 구조와 쿼리 최적화 원리를 바탕으로 성능 개선의 인과관계를 설명할 수 있는가"}, {"category": "CS_FUNDAMENTAL", "question": "MSA로 전환하며 주문 서비스를 분리하고 DB를 PostgreSQL로 분리하셨는데, 서비스 간 데이터 정합성을 유지하기 위해 Kafka를 활용한 어떤 전략을 사용하셨나요?", "job_category": "BACKEND", "target_evidence": "MSA 전환: 주문 서비스를 별도 서비스로 분리, DB 분리(PostgreSQL) 및 Kafka 기반 이벤트 발행/구독 구조 도입", "expected_signal": "분산 시스템 환경에서 트랜잭션 정합성을 맞추기 위한 이벤트 기반 아키텍처(Saga 패턴 등)에 대한 이해도를 검증"}, {"category": "BEHAVIORAL", "question": "모놀리식에서 MSA로 전환하는 과정에서 팀 내 혹은 타 부서와 기술적 의사결정 차이로 인한 갈등이 있었다면, 어떻게 조율하여 프로젝트를 완수하셨나요?", "job_category": "BACKEND", "target_evidence": "모놀리식 -> MSA 전환: 주문 서비스를 별도 서비스로 분리, DB 분리(PostgreSQL) 및 Kafka 기반 이벤트 발행/구독 구조 도입", "expected_signal": "기술적 변화가 큰 프로젝트에서 발생하는 이해관계 충돌을 논리적 근거와 소통으로 해결하는 협업 역량을 확인"}], "latency_sec": 70.971, "in_tokens": 2873, "out_tokens": 830} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "questions", "case_id": "q-frontend-repo", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "react-window 도입으로 INP를 480ms에서 120ms로 개선하셨는데, 가상화 적용 시 스크롤 성능 외에 레이아웃이나 UX 측면에서 고려한 점은 무엇인가요?", "job_category": "FRONTEND", "target_evidence": "virtualize timeline, INP 480ms -> 120ms", "expected_signal": "가상화 도입 시 발생할 수 있는 레이아웃 시프트(Layout Shift)나 스크롤 경험 저하 문제를 어떻게 인지하고 해결했는지 설명해야 함"}, {"category": "TECH_CHOICE", "question": "오프라인 편집을 위해 Dexie를 선택하셨는데, IndexedDB를 활용한 낙관적 업데이트 과정에서 데이터 정합성을 어떻게 보장하나요?", "job_category": "FRONTEND", "target_evidence": "IndexedDB(Dexie) 에 낙관적 업데이트를 저장 후 온라인 복귀 시 동기화", "expected_signal": "로컬 스토리지와 서버 데이터 간의 동기화 메커니즘 및 낙관적 업데이트의 실패 시 롤백 전략을 이해하고 있는지 확인"}, {"category": "PROJECT_DEEP_DIVE", "question": "지도 마커 500개를 클러스터링할 때 useMemo를 통한 좌표 변환 캐싱을 적용하셨는데, 캐싱의 기준이 되는 의존성 배열은 어떻게 구성하셨나요?", "job_category": "FRONTEND", "target_evidence": "Kakao Map SDK 마커 500개를 클러스터링, useMemo 로 좌표 변환 캐싱", "expected_signal": "불필요한 재연산을 방지하기 위해 어떤 상태값을 의존성으로 관리했는지와 메모이제이션의 적절성을 설명해야 함"}, {"category": "CS_FUNDAMENTAL", "question": "이미지 업로드 시 클라이언트에서 WebP 변환을 수행하시는데, 이 방식이 브라우저의 메인 스레드 성능에 미치는 영향과 이를 최적화할 방법은 무엇인가요?", "job_category": "FRONTEND", "target_evidence": "이미지 업로드: presigned URL 로 S3 직접 업로드, 클라이언트에서 WebP 변환", "expected_signal": "무거운 연산이 메인 스레드를 점유할 때의 문제점(Blocking)을 인지하고 Web Worker 등을 통한 해결 방안을 제시할 수 있는지 확인"}, {"category": "TECH_CHOICE", "question": "TODO 주석에 CRDT 검토가 언급되어 있는데, 현재의 last-write-wins 방식과 비교했을 때 CRDT가 해결할 수 있는 구체적인 충돌 시나리오는 무엇인가요?", "job_category": "FRONTEND", "target_evidence": "충돌은 last-write-wins (TODO 주석: \"CRDT 검토 필요\")", "expected_signal": "분산 시스템 환경에서의 데이터 충돌 문제와 CRDT의 동작 원리(수렴성)에 대한 기술적 이해도를 확인"}], "latency_sec": 57.547, "in_tokens": 2675, "out_tokens": 765} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "questions", "case_id": "q-infra-dba-multi", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "거래내역 테이블을 월 단위로 파티셔닝할 때 선택한 파티션 전략과 그로 인해 개선된 쿼리 성능의 핵심 원리는 무엇인가요?", "job_category": "DBA", "target_evidence": "파티셔닝으로 거래내역 테이블 월 단위 분할, 슬로우 쿼리 p95 2.3초 -> 180ms", "expected_signal": "파티션 프루닝(Partition Pruning)의 개념을 이해하고 데이터 분할이 I/O 및 인덱스 스캔 범위에 미치는 영향을 설명할 수 있어야 함"}, {"category": "TECH_CHOICE", "question": "Terraform을 사용하여 VPC와 EKS를 모듈화할 때, 환경별 workspace 분리 외에 코드 재사용성과 보안을 위해 고려한 설계 원칙은 무엇인가요?", "job_category": "INFRA", "target_evidence": "Terraform 으로 VPC·RDS·EKS 모듈화, 환경별(dev/stg/prod) workspace 분리", "expected_signal": "IaC의 모듈화 전략과 환경 간 격리(Isolation)를 위한 구체적인 설계 방식 및 보안 고려 사항을 제시할 수 있어야 함"}, {"category": "PROJECT_DEEP_DIVE", "question": "트래픽 피크를 대비해 CronJob으로 사전 스케일아웃을 운영하셨는데, 이 방식이 HPA만 사용하는 방식에 비해 갖는 장점과 한계점은 무엇인가요?", "job_category": "INFRA", "target_evidence": "HPA 기준을 CPU 70% 로 설정, 트래픽 피크(월급날 10시) 대비 사전 스케일아웃 CronJob 운영", "expected_signal": "예측 가능한 트래픽 패턴에 대한 선제적 대응 능력과 HPA의 반응 속도(Lag) 문제를 인지하고 있음을 보여야 함"}, {"category": "CS_FUNDAMENTAL", "question": "PostgreSQL의 autovacuum 튜닝을 진행하셨는데, autovacuum이 적절히 동작하지 않을 때 발생할 수 있는 성능 저하 이슈와 그 메커니즘은 무엇인가요?", "job_category": "DBA", "target_evidence": "autovacuum 튜닝", "expected_signal": "MVCC 구조에서 Dead Tuple이 차지하는 영향과 Bloat 현상이 성능에 미치는 영향을 기술적으로 설명할 수 있어야 함"}, {"category": "BEHAVIORAL", "question": "RDS 스토리지 풀로 인한 장애 상황에서 CloudWatch 알람과 오토스케일링을 적용하셨는데, 장애 발생 당시의 긴박했던 상황과 본인이 취한 구체적인 조치는 무엇이었나요?", "job_category": "INFRA", "target_evidence": "장애: 2024.03 RDS 스토리지 풀로 쓰기 중단 40분 -> CloudWatch 알람 + 스토리지 오토스케일링 적용", "expected_signal": "장애 인지-대응-사후 조치(Post-mortem)의 과정을 STAR 기법에 맞춰 논리적으로 설명하고 문제 해결 역량을 증명해야 함"}, {"category": "BEHAVIORAL", "question": "ArgoCD 도입으로 배포 리드타임을 획기적으로 단축하셨는데, 이 과정에서 팀 내 개발 문화나 배포 프로세스 측면에서 겪었던 저항이나 어려움은 없었나요?", "job_category": "INFRA", "target_evidence": "ArgoCD GitOps 도입으로 배포 리드타임 1일 -> 30분", "expected_signal": "기술 도입 시 발생하는 조직적 변화 관리 능력과 협업 과정에서의 커뮤니케이션 역량을 보여주어야 함"}], "latency_sec": 68.478, "in_tokens": 2667, "out_tokens": 941} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "questions", "case_id": "q-personality-coverletter", "rep": 0, "ok": true, "questions": [{"category": "BEHAVIORAL", "question": "알림 봇 운영 중 크롤러 중단으로 항의를 받았을 때, 기술적 해결 외에 사용자 신뢰를 회복하기 위해 취했던 행동은 무엇인가요?", "job_category": "BACKEND", "target_evidence": "새벽에 크롤러가 멈춰 공지가 누락됐을 때 동아리원들의 항의를 직접 받으며, 기능보다 '멈추지 않는 서비스'가 신뢰를 만든다는 것을 배웠습니다.", "expected_signal": "문제 발생 시 기술적 조치뿐만 아니라 사용자 커뮤니케이션 및 사후 대응을 통해 신뢰를 관리하는 태도를 보여야 함"}, {"category": "BEHAVIORAL", "question": "API 스펙 해석 문제로 팀원과 갈등이 있었을 때, 본인의 방식이 옳다고 고집했던 구체적인 이유와 당시의 감정 변화는 어떠했나요?", "job_category": "BACKEND", "target_evidence": "다만 초반에 제 방식이 옳다고 고집해 팀원과 감정이 상한 적도 있어, 이후에는 결정 전에 대안 두 가지를 함께 비교하는 방식으로 바꿨습니다.", "expected_signal": "자신의 과오를 객관적으로 인지하고, 갈등 상황에서 감정적 대응을 넘어 협업 프로세스를 개선한 경험을 STAR 방식으로 설명해야 함"}, {"category": "TECH_CHOICE", "question": "SQLite에서 PostgreSQL로 전환하며 트랜잭션 격리 수준을 공부하셨는데, 당시 중복 발송 문제를 해결하기 위해 선택한 구체적인 격리 수준은 무엇인가요?", "job_category": "BACKEND", "target_evidence": "알림 봇 DB를 SQLite 로 시작했다가 동시 쓰기 락 문제로 알림이 중복 발송되었습니다. 원인을 찾는 데 3일이 걸렸고, PostgreSQL 로 이전하며 트랜잭션 격리 수준을 공부하게 됐습니다.", "expected_signal": "문제 원인(Concurrency)과 해결책(Isolation Level) 사이의 기술적 연결 고리를 정확히 이해하고 있는지 검증"}, {"category": "PROJECT_DEEP_DIVE", "question": "OpenAPI 명세와 Mock 서버 도입 이후 통합 이슈가 0건으로 줄었다고 하셨는데, 이 방식이 기존의 방식과 비교해 개발 생산성을 어떻게 높였나요?", "job_category": "BACKEND", "target_evidence": "저는 OpenAPI 명세를 먼저 작성하고 Mock 서버를 띄워 프론트가 병렬로 개발하도록 제안했고, 이후 스프린트에서는 통합 이슈가 3건에서 0건으로 줄었습니다.", "expected_signal": "도구 도입의 결과(정량적 수치)를 넘어, 개발 프로세스(병렬 개발 가능성 등)에 미친 영향력을 논리적으로 설명해야 함"}, {"category": "BEHAVIORAL", "question": "서비스의 신뢰성을 위해 '멈추지 않는 서비스'를 강조하셨는데, 본인이 생각하는 백엔드 개발자로서의 가장 중요한 직업 윤리나 가치는 무엇인가요?", "job_category": "BACKEND", "target_evidence": "기능보다 '멈추지 않는 서비스'가 신뢰를 만든다는 것을 배웠습니다.", "expected_signal": "개인적인 경험에서 도출된 기술적 가치관을 직무에 대한 책임감과 연결하여 답변할 수 있어야 함"}], "latency_sec": 61.425, "in_tokens": 2658, "out_tokens": 836} +{"label": "q-gemma4-26b-UD-IQ3_S", "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 Tailing(CDC) 중 선택한 방식의 동작 원리와 데이터 유실/중복 방지 전략을 설명할 수 있어야 함"}, {"category": "TECH_CHOICE", "question": "재고 동기화 프로젝트에서 낙관적 락에서 분산 락으로 전환하셨는데, 분산 락 도입 시 발생할 수 있는 성능 저하나 Deadlock 이슈는 어떻게 고려하셨나요?", "job_category": "BACKEND", "target_evidence": "Redis 기반 재고 캐시 + DB write-behind, 동시성 제어(낙관적 락 → 분산 락 전환)", "expected_signal": "분산 락의 획득/해제 과정에서의 오버헤드와 Redis를 활용한 락 관리의 트레이드오프를 이해하고 있는지 확인"}, {"category": "CS_FUNDAMENTAL", "question": "MSA로 전환하며 DB를 PostgreSQL로 분리하셨는데, 서비스 간 데이터 정합성을 보장하기 위해 Kafka를 사용한 이벤트 기반 구조에서 발생할 수 있는 '최종 정합성' 이슈는 무엇인가요?", "job_category": "BACKEND", "target_evidence": "주문 서비스를 별도 서비스로 분리, DB 분리(PostgreSQL) 및 Kafka 기반 이벤트 발행/구독 구조 도입", "expected_signal": "이벤트 발행 실패나 순서 보장 문제 등 분산 시스템에서의 정합성 한계를 인지하고 대응 방안을 제시할 수 있어야 함"}, {"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": 69.748, "in_tokens": 4011, "out_tokens": 823} +{"label": "q-gemma4-26b-UD-IQ3_S", "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 테이블의 메시지를 Kafka로 발행하는 Relay 프로세스의 동작 방식과 장애 복구 메커니즘을 설명할 수 있어야 함"}, {"category": "TECH_CHOICE", "question": "재고 동기화 시 낙관적 락에서 분산 락으로 전환하셨는데, 전환을 결정한 구체적인 임계점이나 트래픽 상황은 무엇이었나요?", "job_category": "BACKEND", "target_evidence": "Redis 기반 재고 캐시 + DB write-behind, 동시성 제어(낙관적 락 → 분산 락 전환)", "expected_signal": "낙관적 락의 충돌 비용과 분산 락 도입 시의 성능/복잡도 트레이드오프를 데이터 기반으로 설명할 수 있어야 함"}, {"category": "PROJECT_DEEP_DIVE", "question": "MSA 전환 과정에서 주문 서비스를 분리하며 DB를 PostgreSQL로 분리하셨는데, 서비스 간 데이터 정합성은 어떻게 보장하셨나요?", "job_category": "BACKEND", "target_evidence": "모놀리식 → MSA 전환: 주문 서비스를 별도 서비스로 분리, DB 분리(PostgreSQL) 및 Kafka 기반 이벤트 발행/구독 구조 도입", "expected_signal": "분산 환경에서 트랜잭션 정합성을 유지하기 위해 Kafka 이벤트를 어떻게 활용했는지(예: Saga 패턴 등) 설명할 수 있어야 함"}, {"category": "BEHAVIORAL", "question": "정산 배치 성능을 5시간에서 40분으로 개선하셨는데, 이 과정에서 팀원들과 기술적 의사결정을 어떻게 조율하며 진행하셨나요?", "job_category": "BACKEND", "target_evidence": "정산 배치 성능 개선: 5시간 → 40분 (QueryDSL 튜닝, 청크 단위 처리, 인덱스 재설계)", "expected_signal": "성능 개선을 위한 가설 수립, 검증, 그리고 동료를 설득하거나 협업하여 결과를 만들어낸 STAR 방식의 행동을 보여줘야 함"}, {"category": "CS_FUNDAMENTAL", "question": "대용량 트래픽 환경에서 데이터 정합성을 중시하신다고 했는데, 인덱스 재설계 시 정합성과 조회 성능 사이의 트레이드오프를 어떻게 고려하셨나요?", "job_category": "BACKEND", "target_evidence": "대용량 트래픽에서도 데이터 정합성을 지키는 서버를 만드는 데 관심이 많습니다. / 정산 배치 성능 개선: 인덱스 재설계", "expected_signal": "인덱스가 쓰기 성능(정합성 유지 비용)과 읽기 성능에 미치는 영향을 이해하고, 서비스 특성에 맞는 최적점을 찾는 논리를 제시해야 함"}], "latency_sec": 60.156, "in_tokens": 2876, "out_tokens": 788} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "questions", "case_id": "q2-backend-jd-tailored", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "결제 콜백 지연 문제를 해결하기 위해 도입한 Transactional 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": "동시성 제어 방식의 트레이드오프를 이해하고, 비즈니스 상황에 맞는 기술 선택 근거를 정량적/정성적으로 제시할 수 있는가"}, {"category": "CS_FUNDAMENTAL", "question": "정산 배치 성능을 5시간에서 40분으로 개선하셨는데, QueryDSL 튜닝 시 가장 중점적으로 고려한 DB 인덱스 전략은 무엇인가요?", "job_category": "BACKEND", "target_evidence": "정산 배치 성능 개선: 5시간 → 40분 (QueryDSL 튜닝, 청크 단위 처리, 인덱스 재설계)", "expected_signal": "대용량 데이터 처리 시 인덱스 스캔 효율성과 쿼리 실행 계획을 고려한 최적화 역량을 증명할 수 있는가"}, {"category": "PROJECT_DEEP_DIVE", "question": "모놀리식을 MSA로 전환하며 주문 서비스를 분리할 때, 서비스 간 데이터 정합성을 유지하기 위해 Kafka를 어떻게 활용하셨나요?", "job_category": "BACKEND", "target_evidence": "모놀리식 → MSA 전환: 주문 서비스를 별도 서비스로 분리, DB 분리(PostgreSQL) 및 Kafka 기반 이벤트 발행/구독 구조 도입", "expected_signal": "분산 시스템 환경에서 이벤트 기반 아키텍처를 통해 데이터 일관성을 확보하는 메커니즘을 이해하고 있는가"}, {"category": "BEHAVIORAL", "question": "핀테크 환경에서는 데이터 정합성이 최우선입니다. 본인이 개발한 시스템에서 정합성이 깨질 뻔한 위기 상황을 어떻게 극복했나요?", "job_category": "BACKEND", "target_evidence": "대용량 트래픽에서도 데이터 정합성을 지키는 서버를 만드는 데 관심이 많습니다.", "expected_signal": "장애 상황을 인지하고 해결하는 책임감과, 기술적 해결책을 통해 비즈니스 리스크를 방어한 STAR 경험을 제시할 수 있는가"}, {"category": "BEHAVIORAL", "question": "결제 플랫폼 엔지니어로서, 기술적 완성도와 빠른 배포 주기 사이의 트레이드오프를 어떻게 관리하시겠습니까?", "job_category": "BACKEND", "target_evidence": "배포 단위 축소로 배포 주기 2주 → 2일 / 결제 승인 콜백 지연 시 중복 주문 발생 문제 해결 경험", "expected_signal": "금융 도메인의 안정성 요구사항과 현대적 개발 문화(Agile/DevOps) 사이의 균형 감각을 갖추었는가"}], "latency_sec": 67.198, "in_tokens": 3019, "out_tokens": 903} +{"label": "q-gemma4-26b-UD-IQ3_S", "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의 콜백 실행 시점과 상태 관리(loading flag 등)를 통한 중복 요청 방지 로직을 설명할 수 있어야 함"}, {"category": "TECH_CHOICE", "question": "Next.js 14 App Router 환경에서 프로젝트를 진행하셨는데, Pages Router가 아닌 App Router를 선택했을 때 얻은 구체적인 이점은 무엇인가요?", "job_category": "FRONTEND", "target_evidence": "Next.js 14 App Router, TypeScript, Tailwind CSS", "expected_signal": "Server Components 활용을 통한 클라이언트 번들 사이즈 감소나 데이터 페칭 최적화 관점의 이점을 설명할 수 있어야 함"}, {"category": "PROJECT_DEEP_DIVE", "question": "Lighthouse 접근성 점수가 72점인데, 이를 개선하기 위해 구체적으로 어떤 웹 접근성 요소를 수정하셨나요?", "job_category": "FRONTEND", "target_evidence": "Lighthouse 접근성 점수 72", "expected_signal": "Semantic Markup 사용, ARIA 속성 적용, 혹은 이미지 alt 속성 등 구체적인 개선 행동과 그 이유를 설명할 수 있어야 함"}, {"category": "CS_FUNDAMENTAL", "question": "Gatsby로 블로그를 제작하며 마크다운을 사용하셨는데, Next.js와 같은 SSR/ISR 방식과 비교했을 때 Gatsby의 SSG 방식이 갖는 특징은 무엇인가요?", "job_category": "FRONTEND", "target_evidence": "Gatsby 로 마크다운 블로그 제작", "expected_signal": "빌드 타임과 런타임의 차이, 정적 사이트 생성(SSG)의 성능적 이점과 데이터 변경 시의 한계를 이해하고 있는지 확인"}, {"category": "BEHAVIORAL", "question": "부트캠프 팀 프로젝트 당시, 무한 스크롤이나 접근성 개선 과정에서 팀원들과 기술적 의견 차이가 있었다면 어떻게 해결하셨나요?", "job_category": "FRONTEND", "target_evidence": "부트캠프에서 Next.js 로 팀 프로젝트를 했고, 무한 스크롤과 접근성 개선을 담당했습니다.", "expected_signal": "STAR 기법에 따라 본인의 구체적인 소통 방식과 논리적 근거 제시 과정을 통해 갈등을 해결한 경험을 설명해야 함"}], "latency_sec": 51.487, "in_tokens": 2577, "out_tokens": 683} +{"label": "q-gemma4-26b-UD-IQ3_S", "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": "IntersectionObserver의 동작 원리를 이해하고, 스크롤 이벤트 최적화나 데이터 호출 시점 제어에 대한 구체적인 고민을 STAR 방식으로 설명함"}, {"category": "TECH_CHOICE", "question": "개인 블로그 제작 시 Gatsby를 선택하셨는데, Next.js와 비교했을 때 Gatsby가 가진 장점이 무엇이라고 판단했나요?", "job_category": "FRONTEND", "target_evidence": "Gatsby 로 마크다운 블로그 제작", "expected_signal": "정적 사이트 생성(SSG)의 특성과 프로젝트 목적(블로그)에 따른 기술 선택 근거를 논리적으로 제시함"}, {"category": "BEHAVIORAL", "question": "스터디 모집 플랫폼을 4명의 팀원과 개발하며 의견 충돌이 있었던 경험이 있다면, 어떻게 해결하셨나요?", "job_category": "FRONTEND", "target_evidence": "스터디 모집 플랫폼 (팀 4명, 2026.01)", "expected_signal": "갈등 상황에서 본인의 구체적인 커뮤니케이션 방식과 팀의 목표를 우선시하여 문제를 해결한 경험을 제시함"}, {"category": "BEHAVIORAL", "question": "Lighthouse 접근성 점수 72점을 기록하셨는데, 이 점수를 높이기 위해 어떤 시도를 하셨고 결과적으로 무엇을 배우셨나요?", "job_category": "FRONTEND", "target_evidence": "Vercel 배포, Lighthouse 접근성 점수 72", "expected_signal": "단순 수치 개선을 넘어 웹 표준과 접근성에 대한 이해도를 바탕으로 문제를 정의하고 개선하려는 태도를 보여줌"}, {"category": "BEHAVIORAL", "question": "부트캠프와 학업을 병행하며 가장 몰입했던 경험은 무엇이며, 그 과정에서 본인의 성장을 어떻게 체감하셨나요?", "job_category": "FRONTEND", "target_evidence": "부트캠프 프론트엔드 과정 수료 (2025.09 ~ 2026.02), 컴퓨터공학 학사 (2026.02 졸업)", "expected_signal": "자기주도적인 학습 태도와 목표를 달성하기 위해 몰입하는 과정, 그리고 그 결과로부터 얻은 성찰을 구체적으로 답변함"}], "latency_sec": 51.586, "in_tokens": 2557, "out_tokens": 675} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "questions", "case_id": "q2-dba-technical", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "복제 지연을 해결하기 위해 UPDATE를 1만 건 단위로 분할하셨는데, 청크 크기를 결정한 기준과 분할 시 binlog_format ROW가 지연에 미치는 영향은 무엇이었나요?", "job_category": "DBA", "target_evidence": "복제 지연 최대 90초 → 3초: 대용량 배치 UPDATE 를 1만 건 단위 청크로 분할, binlog_format ROW 유지", "expected_signal": "데이터 규모에 따른 적절한 청크 크기 산정 근거와 ROW 포맷의 복제 메커니즘에 대한 이해도를 보여주어야 함"}, {"category": "TECH_CHOICE", "question": "온라인 스키마 변경을 위해 gh-ost를 도입하셨는데, pt-online-schema-change와 같은 다른 도구 대신 gh-ost를 선택한 구체적인 이유는 무엇인가요?", "job_category": "DBA", "target_evidence": "온라인 스키마 변경: gh-ost 도입, 컬럼 추가 시 락 대기 장애 0건", "expected_signal": "도구별 동작 방식(Trigger 기반 vs Binlog 기반)의 차이와 서비스 안정성 측면에서의 선택 근거를 설명해야 함"}, {"category": "CS_FUNDAMENTAL", "question": "pt-query-digest로 선별한 슬로우 쿼리에 커버링 인덱스를 적용하셨는데, 커버링 인덱스가 실제 데이터 페이지에 접근하는 과정을 어떻게 줄여주는지 설명해주세요.", "job_category": "DBA", "target_evidence": "슬로우 쿼리: pt-query-digest 로 상위 20개 쿼리 선별, 커버링 인덱스 적용", "expected_signal": "Index Condition Pushdown이나 데이터 페이지 접근(Random I/O) 감소 원리를 기술적으로 설명해야 함"}, {"category": "PROJECT_DEEP_DIVE", "question": "Debezium CDC를 통해 BigQuery로 데이터를 적재할 때, 소스 DB의 변경 사항이 유실되지 않도록 보장하기 위해 어떤 메커니즘을 활용하셨나요?", "job_category": "DBA", "target_evidence": "데이터 파이프라인: Debezium CDC → Kafka → BigQuery 적재", "expected_signal": "Kafka의 Offset 관리, CDC의 Binlog 읽기 방식, 혹은 Exactly-once/At-least-once 보장 전략을 언급해야 함"}, {"category": "TECH_CHOICE", "question": "분기별 복구 훈련 시 RTO 40분을 달성하셨는데, 대용량 테이블(1.2TB) 환경에서 스냅샷과 binlog를 조합해 복구 시간을 단축시킨 핵심 전략은 무엇인가요?", "job_category": "DBA", "target_evidence": "백업: 매일 스냅샷 + binlog PITR, 분기별 복구 훈련(RTO 40분)", "expected_signal": "Full Backup과 Incremental/Binlog 복구의 병합 과정 및 대용량 데이터 복구 시 병렬 처리 등의 최적화 경험을 설명해야 함"}], "latency_sec": 58.274, "in_tokens": 2581, "out_tokens": 793} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "questions", "case_id": "q2-dba-infra-multi", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "MySQL 복제 지연을 90초에서 3초로 줄이기 위해 도입한 1만 건 단위 청크 분할 방식의 구체적인 로직과 binlog_format ROW 유지가 왜 중요했는지 설명해주세요.", "job_category": "DBA", "target_evidence": "복제 지연 최대 90초 → 3초: 대용량 배치 UPDATE 를 1만 건 단위 청크로 분할, binlog_format ROW 유지", "expected_signal": "대용량 트랜잭션이 복제 슬레이브에 미치는 영향과 ROW 포맷의 동작 원리를 이해하고 있는지 검증"}, {"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 거래내역 테이블에 월 단위 파티셔닝을 적용하셨는데, 파티션 키 선정 기준과 파티셔닝 도입 후 쿼리 성능 개선이 이루어진 구체적인 원리를 말씀해주세요.", "job_category": "DBA", "target_evidence": "PostgreSQL 14 (RDS) 운영: ... 파티셔닝으로 거래내역 테이블 월 단위 분할", "expected_signal": "파티셔닝 설계 능력과 Partition Pruning이 성능에 미치는 영향을 기술적으로 설명할 수 있는지 검증"}, {"category": "TECH_CHOICE", "question": "EKS 환경에서 트래픽 피크를 대비해 CronJob 기반의 사전 스케일아웃을 운영하셨는데, HPA의 자동 스케일링만으로 대응하지 않고 CronJob을 병행한 이유는 무엇인가요?", "job_category": "INFRA", "target_evidence": "HPA 기준을 CPU 70% 로 설정, 트래픽 피크(월급날 10시) 대비 사전 스케일아웃 CronJob 운영", "expected_signal": "HPA의 반응 속도 한계(Lag)를 인지하고 예측 가능한 트래픽에 대한 선제적 대응 전략을 세울 수 있는지 검증"}, {"category": "PROJECT_DEEP_DIVE", "question": "Terraform을 사용하여 VPC, RDS, EKS를 모듈화하셨는데, 환경별 workspace 분리 시 모듈의 재사용성과 환경 간 격리를 어떻게 관리하셨나요?", "job_category": "INFRA", "target_evidence": "Terraform 으로 VPC·RDS·EKS 모듈화, 환경별(dev/stg/prod) workspace 분리", "expected_signal": "IaC 관리 전략과 환경 분리 시 발생할 수 있는 설정 중복 및 격리 이슈를 해결하는 설계 능력을 검증"}, {"category": "CS_FUNDAMENTAL", "question": "ArgoCD를 통한 GitOps 도입으로 배포 리드타임을 단축하셨는데, GitOps 모델이 기존의 CI/CD 파이프라인과 비교했을 때 인프라의 상태 일관성(Consistency) 측면에서 갖는 이점은 무엇인가요?", "job_category": "INFRA", "target_evidence": "ArgoCD GitOps 도입으로 배포 리드타임 1일 → 30분", "expected_signal": "Desired State와 Actual State의 동기화 메커니즘 및 GitOps의 핵심 가치를 이해하고 있는지 검증"}], "latency_sec": 70.719, "in_tokens": 2890, "out_tokens": 963} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "questions", "case_id": "q2-infra-recent-dup", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "PostgreSQL 거래내역 테이블에 적용한 월 단위 파티셔닝의 구체적인 파티션 키와 관리 전략은 무엇인가요?", "job_category": "INFRA", "target_evidence": "파티셔닝으로 거래내역 테이블 월 단위 분할", "expected_signal": "파티션 키 선정 근거와 데이터 증가에 따른 파티션 관리 및 쿼리 성능 최적화 방안을 설명할 수 있어야 함"}, {"category": "TECH_CHOICE", "question": "Terraform을 사용하여 VPC와 EKS를 모듈화할 때, 환경별 workspace 분리 외에 보안이나 리소스 격리를 위해 고려한 설계 원칙이 있나요?", "job_category": "INFRA", "target_evidence": "Terraform 으로 VPC·RDS·EKS 모듈화, 환경별(dev/stg/prod) workspace 분리", "expected_signal": "IaC를 통한 환경 격리 및 모듈 재사용성, 보안 정책(IAM 등)을 코드 레벨에서 어떻게 관리했는지 설명할 수 있어야 함"}, {"category": "PROJECT_DEEP_DIVE", "question": "슬로우 쿼리 p95를 2.3초에서 180ms로 개선할 때, 복합 인덱스 재설계 과정에서 실행 계획(Execution Plan)을 어떻게 분석했나요?", "job_category": "INFRA", "target_evidence": "슬로우 쿼리 p95 2.3초 → 180ms (복합 인덱스 재설계, autovacuum 튜닝, 파티셔닝으로 거래내역 테이블 월 단위 분할)", "expected_signal": "Explain Analyze 등을 활용한 인덱스 스캔 방식 분석과 실제 쿼리 튜닝의 논리적 과정을 설명할 수 있어야 함"}, {"category": "CS_FUNDAMENTAL", "question": "PostgreSQL의 autovacuum 튜닝이 데이터베이스의 성능과 스토리지 효율성에 미치는 영향은 무엇인가요?", "job_category": "INFRA", "target_evidence": "autovacuum 튜닝", "expected_signal": "MVCC 구조에서 Dead Tuple이 성능과 스토리지에 미치는 영향과 autovacuum 설정값 조절의 트레이드오프를 이해하고 있어야 함"}, {"category": "TECH_CHOICE", "question": "EKS 환경에서 Prometheus와 Grafana를 활용해 인프라 모니터링을 구축할 때, 어떤 핵심 메트릭을 기준으로 장애를 감지하도록 설정했나요?", "job_category": "INFRA", "target_evidence": "Prometheus, Grafana", "expected_signal": "Node/Pod의 리소스 사용량 외에 인프라 가용성을 판단하기 위한 핵심 지표 선정 기준과 알람 임계치 설정 근거를 설명할 수 있어야 함"}], "latency_sec": 53.892, "in_tokens": 2707, "out_tokens": 722} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "questions", "case_id": "q2-backend-focus-weak", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "결제 콜백 지연 문제를 해결하기 위해 도입한 Transactional Outbox 패턴의 구체적인 동작 방식과, Outbox 테이블에 저장된 이벤트를 Kafka로 발행하는 주체는 무엇인가요?", "job_category": "BACKEND", "target_evidence": "결제 승인 콜백 지연 시 중복 주문 발생 문제: 멱등 키 테이블 + Transactional Outbox 로 해결", "expected_signal": "Outbox 패턴의 메커니즘(DB 트랜잭션과 이벤트 발행의 원자성 보장)을 정확히 설명하고, Relay(Polling 또는 CDC)의 역할을 명확히 기술해야 함"}, {"category": "TECH_CHOICE", "question": "재고 동기화 프로젝트에서 낙관적 락을 분산 락으로 전환하신 이유는 무엇이며, 분산 락 도입 시 발생할 수 있는 성능 저하나 데드락 이슈는 어떻게 고려하셨나요?", "job_category": "BACKEND", "target_evidence": "Redis 기반 재고 캐시 + DB write-behind, 동시성 제어(낙관적 락 → 분산 락 전환)", "expected_signal": "낙관적 락의 충돌 비용과 분산 락의 오버헤드 사이의 트레이드오프를 이해하고, Redis 분산 락 사용 시의 주의사항을 논리적으로 답변해야 함"}, {"category": "CS_FUNDAMENTAL", "question": "MSA 전환 과정에서 DB를 PostgreSQL로 분리하셨는데, 서비스 간 데이터 정합성을 유지하기 위해 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": "메모리 관리, 트랜잭션 범위 최적화, DB I/O 부하 분산 측면에서 청크 프로세싱의 이점을 논리적으로 설명해야 함"}, {"category": "BEHAVIORAL", "question": "모놀리식에서 MSA로 전환하는 과정에서 팀 내 개발 문화나 배포 프로세스 측면에서 가장 큰 변화를 겪은 지점은 무엇이며, 이를 위해 본인이 기여한 부분은 무엇인가요?", "job_category": "BACKEND", "target_evidence": "모놀리식 → MSA 전환: ... 배포 단위 축소로 배포 주기 2주 → 2일", "expected_signal": "기술적 변화를 넘어 조직의 생산성 향상을 위해 본인이 주도적으로 행동한 경험을 STAR 방식으로 답변해야 함"}], "latency_sec": 64.056, "in_tokens": 2991, "out_tokens": 855} +{"label": "q-gemma4-26b-UD-IQ3_S", "suite": "questions", "case_id": "q2-fullstack-multi", "rep": 0, "ok": true, "questions": [{"category": "PROJECT_DEEP_DIVE", "question": "결제 승인 지연 시 중복 주문 문제를 해결하기 위해 멱등 키와 Transactional Outbox 패턴을 어떻게 조합하여 구현하셨나요?", "job_category": "BACKEND", "target_evidence": "결제 승인 콜백 지연 시 중복 주문 발생 문제: 멱등 키 테이블 + Transactional Outbox 로 해결, 중복 주문 0건 달성", "expected_signal": "멱등성 보장 메커니즘과 DB 트랜잭션 및 메시지 발행 간의 원자성을 어떻게 유지했는지 논리적으로 설명해야 함"}, {"category": "TECH_CHOICE", "question": "실시간 재고 동기화 프로젝트에서 낙관적 락을 분산 락으로 전환하신 구체적인 이유와 전환 후의 트레이드오프는 무엇인가요?", "job_category": "BACKEND", "target_evidence": "Redis 기반 재고 캐시 + DB write-behind, 동시성 제어(낙관적 락 -> 분산 락 전환)", "expected_signal": "데이터 정합성 요구사항과 시스템 성능(Latency/Throughput) 사이의 관계를 이해하고 선택 근거를 제시해야 함"}, {"category": "PROJECT_DEEP_DIVE", "question": "여행 일정 타임라인에서 react-window를 도입하여 INP를 480ms에서 120ms로 개선하셨는데, 가상화 적용 시 발생한 레이아웃 이슈나 제약 사항은 없었나요?", "job_category": "FRONTEND", "target_evidence": "항목 2천 개 이상时 스크롤 끊김 -> react-window 가상화 도입 (virtualize timeline, INP 480ms -> 120ms)", "expected_signal": "가상화 라이브러리 사용 시 DOM 요소의 크기 계산 문제나 스크롤 성능 최적화 과정을 구체적으로 설명해야 함"}, {"category": "TECH_CHOICE", "question": "오프라인 편집 기능을 위해 Dexie를 사용하셨는데, last-write-wins 방식의 충돌 해결 정책을 선택한 이유와 CRDT 검토가 필요하다고 언급하신 이유는 무엇인가요?", "job_category": "FRONTEND", "target_evidence": "오프라인 편집: IndexedDB(Dexie) 에 낙관적 업데이트를 저장 후 온라인 복귀 시 동기화. 충돌은 last-write-wins (TODO 주석: \"CRDT 검토 필요\")", "expected_signal": "데이터 동기화 시 발생하는 충돌 해결 전략의 한계를 인지하고 있으며, 더 고도화된 알고리즘(CRDT)에 대한 이해도를 보여야 함"}, {"category": "CS_FUNDAMENTAL", "question": "MSA 전환 과정에서 주문 서비스를 분리하며 Kafka를 도입하셨는데, 이벤트 발행 시 메시지 유실을 방지하기 위해 어떤 전략을 사용하셨나요?", "job_category": "BACKEND", "target_evidence": "모놀리식 -> MSA 전환: 주문 서비스를 별도 서비스로 분리, DB 분리(PostgreSQL) 및 Kafka 기반 이벤트 발행/구독 구조 도입", "expected_signal": "분산 시스템 환경에서 메시지 전달 보장(At-least-once 등)을 위한 아키텍처적 고민을 설명해야 함"}, {"category": "BEHAVIORAL", "question": "정산 배치 성능을 5시간에서 40분으로 개선하는 과정에서 가장 큰 기술적 난관은 무엇이었으며, 이를 해결하기 위해 팀원들과 어떻게 협업하셨나요?", "job_category": "BACKEND", "target_evidence": "정산 배치 성능 개선: 5시간 -> 40분 (QueryDSL 튜닝, 청크 단위 처리, 인덱스 재설계)", "expected_signal": "문제 해결을 위한 분석 과정(STAR)과 기술적 의사결정 과정에서의 커뮤니케이션 역량을 보여줘야 함"}], "latency_sec": 71.957, "in_tokens": 3114, "out_tokens": 972} +{"label": "q-gemma4-26b-UD-IQ3_S", "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 로 시작했다가 동시 쓰기 락 문제로 알림이 중복 발송되었습니다. 원인을 찾는 데 3일이 걸렸고, PostgreSQL 로 이전하며 트랜잭션 격리 수준을 공부하게 됐습니다.", "expected_signal": "격리 수준(Isolation Level)의 개념을 정확히 이해하고, 데이터 정합성을 위해 어떤 수준을 선택했는지 기술적 근거를 제시해야 함"}, {"category": "PROJECT_DEEP_DIVE", "question": "OpenAPI 명세와 Mock 서버를 도입해 협업 효율을 높이셨는데, 명세 작성 시 API의 응답 구조나 에러 핸들링에 대해 프론트엔드와 구체적으로 어떤 합의 과정을 거쳤나요?", "job_category": "BACKEND", "target_evidence": "저는 OpenAPI 명세를 먼저 작성하고 Mock 서버를 띄워 프론트가 병렬로 개발하도록 제안했고, 이후 스프린트에서는 통합 이슈가 3건에서 0건으로 줄었습니다.", "expected_signal": "단순히 도구를 사용하는 것을 넘어, 협업을 위해 API 설계 단계에서 고려한 구체적인 커뮤니케이션 방식과 설계 원칙을 설명해야 함"}, {"category": "BEHAVIORAL", "question": "본인의 방식이 옳다고 고집해 팀원과 갈등을 겪은 후 대안을 비교하는 방식으로 바꾸셨는데, 이 과정에서 팀원의 피드백을 수용하기 위해 본인이 기울인 구체적인 노력은 무엇인가요?", "job_category": "BACKEND", "target_evidence": "다만 초반에 제 방식이 옳다고 고집해 팀원과 감정이 상한 적도 있어, 이후에는 결정 전에 대안 두 가지를 함께 비교하는 방식으로 바꿨습니다.", "expected_signal": "자신의 태도를 객관적으로 인지하고, 갈등 해결을 위해 감정적 대응이 아닌 시스템적/절차적 개선(대안 비교)을 도입한 과정을 STAR 방식으로 답변해야 함"}, {"category": "CS_FUNDAMENTAL", "question": "학사 공지 알림 봇 운영 중 크롤러가 멈추는 이슈를 겪으셨는데, 서비스의 가용성을 높이기 위해 크롤러의 재시도 로직이나 모니터링을 어떻게 설계하셨나요?", "job_category": "BACKEND", "target_evidence": "새벽에 크롤러가 멈춰 공지가 누락됐을 때 동아리원들의 항의를 직접 받으며, 기능보다 '멈추지 않는 서비스'가 신뢰를 만든다는 것을 배웠습니다.", "expected_signal": "장애 발생 시 대응 프로세스나 예외 상황(Exception Handling)을 방지하기 위한 기술적 방어 기제에 대한 이해도를 보여줘야 함"}, {"category": "BEHAVIORAL", "question": "사용자 800명이 매일 사용하는 서비스를 운영하며 느꼈던 '서비스 신뢰'에 대한 본인만의 기준은 무엇이며, 이를 백엔드 개발자로서 어떻게 구현하고 싶으신가요?", "job_category": "BACKEND", "target_evidence": "기능보다 '멈추지 않는 서비스'가 신뢰를 만든다는 것을 배웠습니다.", "expected_signal": "운영 경험을 통해 얻은 가치관을 기술적 지향점(안정성, 확장성, 모니터링 등)과 연결하여 본인만의 개발 철학을 논리적으로 설명해야 함"}], "latency_sec": 65.642, "in_tokens": 2659, "out_tokens": 913} diff --git a/docs/research/thesis/quantization-study.md b/docs/research/thesis/quantization-study.md index 0a3e03b1..80924266 100644 --- a/docs/research/thesis/quantization-study.md +++ b/docs/research/thesis/quantization-study.md @@ -89,9 +89,10 @@ F16 원본이 각 토큰에 매긴 확률 분포를 기준으로 삼고, 양자 | 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-IQ3_S | 100% | 95.0% | 96.3% | 96.3% | 100% | 8.44s | | 26B-A4B UD-IQ2_M | 100% | 92.5% | 96.3% | 96.2% | 100% | 7.98s | -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배로 늘어난다. +E4B 도 8비트에서 3비트까지 평평하다. **26B-A4B 는 3비트와 2비트 사이에서도 무너지지 않는다.** 점수 라벨이 96.3% 로 같고 의도 분류만 95.0% 대 92.5% 로 한 건 차이다. 4B 가 2비트에서 완전히 붕괴한 것과 대비된다. 파라미터가 많을수록 낮은 비트를 견딘다는 기존 관찰이 한국어 면접 과제에서도 확인된 것이며, 실무적으로는 **같은 메모리 예산에서 큰 모델을 더 강하게 줄이는 선택이 두 배로 유리하다**는 뜻이다. 다만 26B 는 이 GPU 에서 전문가 계층을 CPU 로 내보내야 하므로 지연이 8초대로 고정된다. 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배로 늘어난다. --- @@ -141,6 +142,7 @@ Qwen3 4B 10종에 대해 평균 KL 과 각 지표의 순위 상관(스피어만 | 조건 | 결과 | 원인 | |---|---|---| +| Gemma 26B UD-Q3_K_M | 실행 불가 | 12.7 GB 가중치를 6 GB VRAM + CPU 오프로드로 올리려다 연산 버퍼(633 MB) 할당 실패, 3회 재시도 후 포기 | | Qwen3 4B F16 | 실행 불가 | 8.05 GB 가중치가 6 GB VRAM 을 넘어 CUDA 초기화 실패, 3회 재시도 후 포기 | | Gemma E4B Q4_K_M, 26B IQ3_S | 컨테이너 즉시 종료 | 양자화 디렉터리 밖을 가리키는 심볼릭 링크가 컨테이너 안에서 끊김. 하드링크로 교체 후 재실행 | | Qwen3 4B Q8_0·Q6_K | 1차 실패 → 재시도 성공 | 컨테이너 생성 직후 간헐적 CUDA 초기화 실패 | @@ -156,7 +158,7 @@ Qwen3 4B 10종에 대해 평균 KL 과 각 지표의 순위 상관(스피어만 1. **4B 급 모델에서 8비트를 쓸 이유가 없다.** 3비트까지 과제 지표가 변하지 않고 파일은 절반이 된다. 6 GB GPU 에서 4B 를 3비트로 올리면 남는 메모리를 문맥 길이와 병렬 슬롯에 쓸 수 있다. 2. **한계선은 3비트와 2비트 사이에 있다.** 이 경계는 모델 크기가 아니라 구조화 출력 요구와 맞물린다. 태그·JSON 형식을 요구하는 과제가 먼저 깨지고, 자유 서술인 코칭이 늦게 깨진다. 3. **저비트를 꼭 써야 한다면 원본에서, 한국어로 보정해서 만들어야 한다.** 이미 줄어든 파일을 다시 줄이는 선택은 가장 나쁘다. -4. **같은 메모리라면 큰 모델을 강하게 줄이는 쪽이 낫다.** 26B 를 2비트로 쓴 결과가 4B 8비트보다 품질이 높았다. 다만 이 서버에서는 지연이 8초로 늘어 대화형 면접에는 쓸 수 없고, MoE 구조라 CPU 오프로드에 의존한다. +4. **같은 메모리라면 큰 모델을 강하게 줄이는 쪽이 낫다.** 26B 를 2비트로 쓴 결과가 4B 8비트보다 품질이 높았고, 26B 는 3비트와 2비트 사이에서도 품질이 유지됐다. 저비트 손상이 모델 크기에 따라 다르게 나타난다는 뜻이다. 다만 이 서버에서는 지연이 8초로 늘어 대화형 면접에는 쓸 수 없고, MoE 구조라 CPU 오프로드에 의존한다. 5. **분포 차이 지표는 사전 선별에 쓴다.** 후보를 전부 과제 평가에 올리기 전에 KL 로 걸러내면 비용을 줄일 수 있다. 단 안전 구간 안의 미세한 순위는 판정자 평가로만 가려진다. ---