피드백 트래커
멘토·강사님 피드백의 접수와 반영 이력을 추적한다 — 언제 어떤 피드백을 받았고, 언제 무엇을 수정했는지.
코멘트 및 숙제 (팀원별) - 진수택: 모델 비교를 하셨는데, 어떤 기준으로 정량적으로 비교할 수 있을지 고민 필요. - 박소연: 여러 가지 모델 학습 방법에 대한 공부. Colab 에 의문을 가진 점이 좋다 — 그런 궁금증을 많이 가지되, 궁금한 데서 멈추지 말고 공부로 이어갈 것. - 이우정: 프로젝트를 진행하며 발생하는 문제 → 해결 과정을 조금 더 파헤쳐 볼 것 (예: git conflict). 기능 구현되는 것에만 집중하면 정작 해야 하는 경험을 놓칠 수 있음. - 김민아: 사용 중인 언어/프레임워크의 개념적인 것을 공부할 것. "React 를 왜 썼나 / 뭐가 장점인가" 같은 질문에 답이 나와야 하고, 그에 따른 꼬리 질문을 통해 본인의 경험을 드러낼 수 있음.
진수택 — 정량 비교 기준을 세워 Qwen vs Claude 정량·품질 보고서 작성(09-22) · 같은 채점기(judge.py)로 pass_rate(26.1→69.6→73.9) + 판정 항목별·질문 유형별·실패의 질·요약 어댑터 품질·비용·지연·해석 주의(채점기 편향·23건 표본)까지. 나머지 3건(박소연·이우정·김민아)은 개인 학습 과제로 각자 이어간다.
2주차~3주차 숙제 - 서비스 1차 완성 (지원자·관리자 입장에서 각각 시연 가능하도록 준비) - 모델 학습 결과 확인 → public API 사용할지 학습된 모델 사용할지 결정 (학습 결과를 어떻게 평가했는지도 알려주세요. 모델 성능을 어떻게 측정했는지? 업무 환경에서 핫한 주제임) - 실시간 비디오 면접 등 기능에 대한 성능 향상 전반적인 코멘트: 클로드 등의 AI 를 프로젝트에 활용하는 것은 좋으나, 클로드가 해준 작업에 대해 한 depth 정도는 들어가서 내용을 공부하셔야 함
서비스 1차 완성 — 담당자·지원자 데모 계정으로 양쪽 시연 가능(09-18 코드 동결 시점 충족) · 모델 결정(09-18) — 같은 채점기(judge.py · 동일 23건)로 비교해 클라우드 + Claude 확정, Qwen 자체학습은 R&D 자산으로 보존 · 평가 방법은 Qwen vs Claude 정량·품질 보고서(09-22)로 정리 · 실시간 면접 성능은 09-17 GPU 벤치(T4)까지 — 운영 GPU 가동은 10-14~27 계획.
멘토가 21가지 항목을 짚었고, 팀에서 우리 프로젝트 현황과 대조해 정리했다. A. 서류·AI 요약 (6항목) - 이력서 포맷 종류 확정 · hwp 는 요약 안 되니 hwpx 안내 · 이미지는 안 받기 - 다양한 이력서에서 요약이 나오는지 · 영어·비개발 직군 실측 필요 - 에이전트 요약 저장·읽기 흐름 (설명만 하면 됨 — 이미 동작) - 다른 직종 지원 시 프롬프트 편향 확인 (마케팅·영업 케이스 실측) - 장점·단점 색으로 강조 (fit=초록, concerns=적갈) - 서류·인터뷰 적합성 점수화 (이미 등급 + 근거로 되어 있음) B. 면접 (7항목) - 이력서의 거짓 판정 (거짓 판정 안 함 · 네 겹 대조로 대체) - 면접 중 추가 질문 (사전 생성 됨 · 즉석 후속 질문은 후보) - 질문 음성 재생 (TTS · 결정 필요 · 마이크 오염 함정) - 면접 시간 상한 (전역 기본값 · 결정 필요) - 지원자 질문 창구 (없이 · 마무리 안내만 · 결정 됨) - "이상입니다" 종료 발화 인식 (버튼이 해결 · 우선순위 낮음) - 면접 관련 확장 방법 (답변 기반 즉석 후속 질문 후보) C. 지원자 쪽 (4항목) - 지원서 업로드 때 로그인 정보 (이메일 + 생년월일 · 동작) - 채용 공고 지원 방법 · 지원 페이지 (동작 · 실링크 시연) - 지원자 진행 사항 확인 (앱·메일 링크 · 동작) - 에이전트에 파일 넣어 접수 (도구 신설 필요) D. 화면·앱·학습 (4항목) - 평가 현황판 정확한 내용 정하기 (대시보드와 역할 갈라 정리) - 대시보드 깔끔하게 (진행 중 것만 · 이미 정리) - 앱 최적화 (다른 기기 실측 · Play Store 서명 · 배터리 실측) - 파인튜닝 방법 (표정 ViT · Qwen3-8B QLoRA · 이미 두 건 수행) 이번 주 안 우선순위: 1. 결정 3개 (질문 TTS · 면접 시간 상한 · 평가 현황판 역할) 2. 실측 2개 (영어 이력서 · 비개발 직군) 3. 폼 안내 (생년월일 필수 · hwp 안내) 4. 화면 문구 (fit/concerns 색 강조 · 면접 종료 마무리) 5. 아르에 파일 넣어 접수 (신규 도구) 6. 앱 다른 기기 실측 · Play Store (계정 승인 대기)
PR#174·175·178 로 인터뷰방 답변 저장 실패·서류 대조·CONFLICT 409 해결 · PR#182 로 서류 판정 알고리즘 정확성 개선 · PR#183 로 Qwen 학습 파이프라인 착수. 나머지 세부 항목은 시연 준비 중 지속 반영.
이번 주 숙제 — 기능 레벨의 설계 및 전체적인 아키텍처(혹은 서비스 진행 흐름)를 조금 더 구체적으로 완성해올 것. 기술 스택까지 고려하여 구현 가능성을 염두에 두어야 하며, 어떻게 구현할지가 안 떠오른다면 간단하게 실험해볼 것
ADR-0028(무결성 앵커)·0029(표정·음성 보조 신호)·0030(n8n 자동화)·0031(AWS 최소화)·0032(추론 모델 3종 확정)·0033(지원자 앱 로그인) 확정. 서비스 진행 흐름을 결정 문서로 못박고, 각 결정마다 실측·근거·비용까지 담았다.
프로젝트 소개가 기능 나열에 그쳐 매력과 핵심 포인트가 드러나지 않고, 실무(현업) 관점과의 접점이 약함 — 실제 채용 현장의 문제를 해결하는 서사로 더 가까워질 것
소주제를 '현업 pain point 해결' 중심으로 전면 재구성 — ① 보안에 강한 로컬 AI 에이전트 신설(채용 데이터 반출 우려 → 온프레미스 sLLM·STT로 내부망 완결), ② 면접 일정 자동화 신설(수 회 메일 왕복 조율 제거), ③ 24시간 지원자 셀프서비스 신설(전형 현황 실시간 확인·챗봇 응대로 반복 문의 제거), ④ STT를 [STT→RAG→sLLM] 근거 인용 분석 파이프라인으로 확장. 기능 나열이 아닌 '누구의 어떤 비효율을 없애는가' 구조로 재작성
📖 사용 규칙 보기 (기록 방법)
멘토링·강의에서 받은 피드백을, 반영을 담당하는 팀원이 _data/feedback/<자기 GitHub 아이디>.yml에 기록한다 — 칸반과 같은 원칙(한 사람 = 파일 하나)이라 git 충돌이 없다.
- 자기 파일만 수정한다. 어느 도메인 소관인지 애매한 피드백은 팀 채널에서 담당을 정한 뒤 그 사람이 기록한다.
- 새 항목은 파일 맨 위에 추가한다(최신순 유지). 형식: ```yaml
- received: 2026-09-01 # 피드백 들어온 날짜 from: “09/04 중간점검” # 출처 (예: 멘토링·강사 피드백·중간점검) content: “피드백 내용” status: todo # todo(대기) | doing(수정 중) | done(반영 완료) fixed: # 수정한 날짜 — 반영 완료 시 기입 fix: “” # 수정한 내용 — 반영 완료 시 기입 ```
- 접수 시점에는
received/from/content/status: todo만 채우고, 반영이 끝나면 같은 항목에fixed·fix를 채우고status: done으로 바꾼다 — 접수와 반영이 한 줄에서 추적된다. - 반영이 칸반 카드로 이어지면 카드
note에 “피드백 반영”이라고 적어 연결한다.