한샘[한샘가온]프로덕트 엔지니어 채용 공고
1.0 (1)한샘가온
경력근거: AI 도구를 적극 활용하면서도 결과를 꼼꼼하게 검토할 수 있는 분
4일 전 확인채용 공고 보기
한샘가온의 이 공고는 회사 소개나 제품 설명 없이 쓰는 기술과 일하는 방식만 적어 놓았습니다. 자격요건은 경력 무관(신입 지원 가능)과 학력무관 두 줄이 전부이고, 실제 판단 기준은 우대사항 여덟 줄이 대신합니다. 접수는 사람인 온라인 이력서와 포트폴리오로 받고 전형은 서류전형, 1차면접, 최종합격 세 단계이며 접수기간은 2026년 8월 6일부터 9월 5일까지 한 달입니다. 경력과 학력을 열어 둔 공고에는 배경이 제각각인 지원서가 한 달 내내 쌓이는데, 그 여덟 줄 가운데 요구사항 정리, 사용자 경험, 우선순위, 팀 소통, AI 결과 검토 다섯 줄은 키워드로 가려지지 않아 결국 사람이 읽어야 합니다. 이 관리자 페이지는 그 공고 문장을 그대로 요건 표로 옮겨 지원서 옆에 붙이고, 가려지는 항목만 규칙과 인용으로 처리한 뒤 나머지는 면접 질문으로 돌립니다. 확정하기 전에는 다음 전형이 열리지 않게 만든 것도 'AI 도구를 적극 활용하면서도 결과를 꼼꼼하게 검토할 수 있는 분' 이라는 문장을 화면 구조로 옮긴 것입니다. 다만 이 포트폴리오가 보여주는 것은 Next.js 와 Node.js, PostgreSQL 로 이어지는 웹 서비스 전체 흐름 구현과 규칙 기반 대조, 인용 실재성 검사, 확정 전까지 다음 상태를 잠그는 상태 전이 설계라는 기술 역량이며, 채용 평가나 인사 도메인 전문성은 주장하지 않습니다. 안내 발송과 결제처럼 사업자 계정이 필요한 기능은 문안 초안까지만 두고 범위 밖으로 뺐습니다.
자격요건은 경력 무관과 학력무관 두 줄이 전부이고, 실제로 무엇을 보는지는 우대사항 여덟 줄이 대신합니다. 그래서 서류를 읽는 사람은 매번 그 여덟 줄을 머릿속에 띄워 놓고 이력서를 훑게 됩니다. 요건을 표로 고정해 지원서 옆에 붙여 두면 그 왕복이 사라집니다.
요구사항을 함께 정리해 구현 가능한 형태로 풀고, 우선순위를 고려해 현실적으로 개발하며, 기획부터 출시와 운영까지 함께한 사람을 찾는다고 적혀 있습니다. 공고에 적힌 여덟 줄을 판정 가능한 요건과 사람이 읽어야 하는 요건으로 나눠 놓는 작업 자체가 그 능력을 그대로 보여줍니다.
AI 도구를 적극 활용하면서도 결과를 꼼꼼하게 검토할 수 있는 사람을 우대한다고 적혀 있습니다. 이 관리자 페이지는 그 문장을 화면 구조로 옮겨, 모델이 만든 인용과 질문 초안은 전부 미확정 상태로 놓이고 담당자가 하나씩 확정해야만 상태가 다음으로 넘어갑니다.
채용 공고의 요건 항목 표와 지원서 표를 받아, 지원자마다 요건별로 지원서 원문에서 근거 문장을 찾아 그대로 인용해 붙이는 관리자 페이지입니다. 스택 이름처럼 대조로 판정되는 항목은 규칙이 먼저 맞춰 보고, 지원서 원문에서 근거 문장을 찾아 그대로 인용하는 일만 모델이 맡습니다. 소통이나 사용자 경험처럼 문장만으로는 가려지지 않는 항목은 자동 판정 불가로 세워 두고 면접에서 물어볼 질문 초안을 대신 만듭니다. 점수나 순위, 합격 여부 추천은 만들지 않습니다. 각 항목은 담당자가 충족과 근거 부족 가운데 하나로 확정해야 하고, 미확정 항목이 하나라도 남으면 서류전형에서 1차면접으로 넘기는 버튼이 잠긴 채 무엇이 남았는지만 보여줍니다. 합격 안내나 불합격 안내는 문안 초안을 만드는 데까지이며 발송은 하지 않습니다. 이력서 PDF 판독도 범위 밖이라 지원서는 텍스트 필드로 받습니다.
한샘가온에서 개발자 채용을 챙기는 사람입니다. 접수 한 달 동안 배경이 제각각인 지원서가 쌓이는데, 자격요건은 경력 무관 한 줄이라 결국 우대사항 여덟 줄을 머릿속에 띄워 놓고 이력서를 한 장씩 훑습니다. 어제 본 지원자가 어느 항목에서 걸렸는지 기억이 안 나 다시 읽는 일이 잦고, 면접에 들어가서야 '이 사람한테 뭘 물어보기로 했더라' 를 다시 떠올립니다. 지원서 문장을 요건 옆에 그대로 붙여 놓고 항목마다 확정 표시를 남기고 싶고, 확정하지 않은 채로 다음 전형에 넘기는 실수를 도구가 먼저 막아 주기를 바라는 사람입니다.
요건과 지원서의 대조는 원문 인용으로 결정되는 일이라고 보고 규칙이 먼저 후보 문장을 찾은 다음, 모델에게는 그 문장을 인용해 한 줄로 옮기고 빈 항목의 면접 질문을 쓰는 일만 맡기면, (a) 지원서마다 요건 여덟 줄을 다시 떠올리던 왕복이 화면 한 장으로 줄고, (b) 모든 표시에 지원서 원문이 붙어 왜 그렇게 봤는지가 남으며, (c) 미확정 항목이 남은 지원자는 다음 전형으로 넘어가지 않아 모델이 만든 초안이 사람의 판단을 대신하는 일이 구조적으로 막힙니다.
요건 표와 지원서 표를 넣으면 지원자별 검토 시트가 열리고, 요건마다 인용 근거나 근거 부족 표시가 붙으며, 담당자가 항목을 확정해야 1차면접으로 넘기는 버튼이 열리는 Next.js 웹 콘솔입니다. 지원서는 텍스트 필드로 받는 것을 전제로 하고 이력서 PDF 판독은 넣지 않습니다. 안내 문안은 초안 생성까지만 하고 발송 기능은 두지 않습니다. 이 주차는 Vercel 기본 배포로 바로 돌아갑니다.
리액트와 React, 넥스트JS와 Next.js처럼 표기만 다른 스택 이름을 정규화 사전으로 묶어 같은 근거가 갈라지지 않게 하고, 검토자 2명이 같은 지원서 40건을 각자 확정해 판정이 갈리는 항목을 뽑아 보는 단계입니다. 이 주차부터 Docker 이미지로 묶어 AWS 로 배포하고 GitHub Actions 로 배포 흐름을 잇습니다.
누가 언제 무엇을 확정했는지 남긴 이력을 모아, 매번 근거 부족으로 남는 요건과 아무도 판정하지 못한 요건을 집계해 공고 문구 개선 후보와 면접 질문 개선 후보로 내보내는 단계입니다. 지원자 개인정보는 가명 처리한 뒤 집계에만 쓰고 보관 기간이 지난 지원서는 자동으로 지웁니다.
함정을 섞은 지원서 200건과 요건 16개를 넣으면 지원자별 검토 시트가 열리고, 요건마다 지원서 원문 문장이 인용돼 붙거나 근거 부족으로 표시되며, 미확정 항목이 남은 지원자는 1차면접 버튼이 잠긴 채 무엇이 남았는지 보여주는 걸 시연합니다
시트에 붙은 모든 인용문이 지원서 원문에 그대로 있는지 공백 정규화 후 대조해 100% 자동 판정합니다. 일부러 만든 함정 5종(스택 표기 흔들림, 사전에 없는 스택 이름, 같은 사람의 중복 지원, 자기소개가 빈 지원서, 키워드로는 가려지지 않는 요건)이 근거 있음으로 넘어가지 않는지 매번 검사합니다
지저분한 지원서 30종(자기소개가 빈 칸, 링크 한 줄만 적힌 본문, 이모지와 표가 섞인 붙여넣기, 3만 자짜리 장문, 깨진 인코딩, 같은 문장 반복)을 넣어도 콘솔이 죽지 않고 읽지 못한 항목을 따로 세워 보여줍니다
확정 없이 전형을 옮기려는 시도를 전부 막는지 검사하고, 누가 언제 어떤 항목을 어떻게 확정했는지가 이력에 남는지 확인합니다. 단, 지원서와 요건 판정을 모두 작성자가 만든 합성 기준이라 '성능 검증' 이 아니라 '데모 조건에서의 동작' 입니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 검토 시간이 실제로 줄었는지와 확정 판단이 사람 사이에서 일관되는지는 한샘가온의 실제 지원서와 실제 채용 담당자가 있어야 측정 가능합니다. 이 콘솔은 그 검증을 바로 돌릴 수 있는 상태로 만듭니다
이건 고객·실데이터 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 데이터 자가채점이라 '성능 증명' 이 아닙니다. 면접에서 '데모 조건 동작 + 실검증 준비 상태' 로 솔직히 설명합니다
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 스택 표기 흔들림, 사전에 없는 이름, 중복 지원, 빈 자기소개, 키워드로 가려지지 않는 요건 같은 경계 케이스를 더미에 섞어 쉬운 문제만 푸는 게 아님을 보여줍니다
사람을 자동으로 거르는 도구가 아닙니다. 점수와 순위, 합격 추천을 아예 만들지 않고 근거 문장 배치와 확정 게이트까지만 두었습니다. 자동 판정이 사람의 판단을 대신하면 지원서 문장 스타일 같은 것이 그대로 편향으로 굳기 때문입니다
근거가 없다는 표시는 역량이 없다는 뜻이 아니라 지원서에 안 적혔다는 뜻입니다. 근거 부족 항목은 탈락 사유가 아니라 면접 질문으로 돌리는 것을 기본값으로 두었고, 화면에도 그 문장을 함께 씁니다
실제 도입 시 달라지는 것을 명시합니다. 실제 지원서에는 개인정보가 들어 있어 보관 기간과 접근 권한, 파기 절차를 정해야 하고 사람인 접수 데이터 연동과 실제 담당자 검수로 교체해야 하며, 이는 도입 단계 과제로 분리합니다
이 포트폴리오가 보여주는 것은 Next.js 와 Node.js, PostgreSQL 로 이어지는 웹 서비스 전체 흐름 구현과 규칙 기반 대조, 인용 실재성 검사, 확정 전까지 다음 상태를 잠그는 상태 전이 설계라는 기술 역량이며, 채용 평가나 인사 도메인 전문성은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
공고의 자격요건과 우대사항, 주요업무를 항목으로 쪼개 둔 요건 표입니다. 새 평가 체계를 만드는 것이 아니라 이미 공고에 적힌 문장에 판정 방식만 붙인 것입니다. 키워드로 가려지지 않는 소프트 항목과 서로 겹치는 항목을 함께 넣어, 자동 판정이 함부로 넘어가지 않는지 검사하게 합니다.
| req_id | kind | text_ko | match_keywords | skill_key | auto_checkable | note_ko |
|---|---|---|---|---|---|---|
| r01 | 자격요건 | 경력 무관 (신입 지원 가능) | [] | — | false | 거를 조건이 아니라 열어 둔 조건이라 판정하지 않고 표시만 합니다 |
| r02 | 자격요건 | 학력무관 | [] | — | false | 판정 대상이 아닙니다 |
| r03 | 우대사항 | React를 활용해 웹 서비스를 만들어본 경험이 있으신 분 | ["React","리액트"] | react | true | — |
| r04 | 우대사항 | 요구사항을 함께 정리하고 구현 가능한 형태로 풀어갈 수 있는 분 | [] | — | false | 문장만으로는 가려지지 않아 면접 질문으로 돌립니다 |
| r05 | 우대사항 | 사용자 경험을 고민하며 제품을 만들어가는 것을 좋아하는 분 | [] | — | false | 자기소개에 비슷한 표현이 있어도 근거로 삼지 않습니다 |
아래 JSON Schema 에 맞는 웹 서비스 개발 직군 채용공고의 요건 항목 24건을 JSON 배열로 생성. 이미 공고에 적힌 문장을 항목으로 쪼개고 판정 방식만 붙이는 설정이라는 전제로(새 평가 기준을 발명하지 말 것). text_ko 는 공고에 실제로 쓰일 법한 문장 그대로.
{"type":"object","properties":{"req_id":{"type":"string"},"kind":{"enum":["자격요건","우대사항","주요업무"]},"text_ko":{"type":"string"},"match_keywords":{"type":"array","items":{"type":"string"}},"skill_key":{"type":["string","null"]},"auto_checkable":{"type":"boolean"},"note_ko":{"type":["string","null"]}},"required":["req_id","kind","text_ko","match_keywords","auto_checkable"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. (1) 키워드로는 가려지지 않는 소프트 항목 8건(소통·태도·우선순위·사용자 경험 같은 문장, auto_checkable=false 가 정답이어야 한다), (2) 서로 다른 두 항목이 같은 skill_key 를 가리켜 같은 근거가 중복으로 붙는 쌍 2개, (3) 한 문장이 두 가지 기술을 함께 묻는 항목 3건(근거가 반쪽만 나오는 사례), (4) match_keywords 가 빈 배열인 항목 5건, (5) 거의 모든 지원서에 등장해 변별이 되지 않는 흔한 키워드를 가진 항목 2건, (6) skill_key 가 스킬 사전에 없는 신생 기술을 가리키는 항목 2건. req_id 는 r01 부터 연속으로. JSON 배열만.{"type":"object","properties":{"req_id":{"type":"string"},"kind":{"enum":["자격요건","우대사항","주요업무"]},"text_ko":{"type":"string"},"match_keywords":{"type":"array","items":{"type":"string"}},"skill_key":{"type":["string","null"]},"auto_checkable":{"type":"boolean"},"note_ko":{"type":["string","null"]}},"required":["req_id","kind","text_ko","match_keywords","auto_checkable"]}접수된 지원서입니다. 요건별 근거 인용과 면접 질문 초안이 모두 이 표에서 나옵니다. 스택 표기 흔들림, 경력 미기재, 포트폴리오 링크 없음, 같은 사람의 중복 지원, 빈 자기소개를 일부러 섞어 쉬운 데이터만 푸는 게 아님을 보여줍니다. 실명 대신 가명 식별자만 두어 지원자 개인을 알아볼 수 없게 했습니다.
| application_id | applicant_alias | submitted_at | source | career_years | stated_stack_raw | portfolio_url | resume_text | answers |
|---|---|---|---|---|---|---|---|---|
| app-001 | 지원자-0413 | 2026-08-07T10:12:00+09:00 | 사람인 | 2 | TypeScript, React, Next.js, PostgreSQL | https://portfolio.example.com/0413 | 커머스 스타트업에서 2년간 상품 상세와 주문 화면을 Next.js 로… | [{"question_key":"지원동기","body":"작은 팀에서 기획부터 운영까지 직접 보고 싶어 지원했습니다."},{"question_key":"대표프로젝트","body":"사내 주문 관리 화면을 처음부터 만들어 출시하고 6개월간 운영했습니다."}] |
| app-002 | 지원자-0511 | 2026-08-08T21:40:00+09:00 | 사람인 | — | 리액트, 넥스트JS, 노드 | — | 부트캠프를 마치고 팀 프로젝트로 중고 거래 웹을 만들었습니다. 리액트… | [{"question_key":"지원동기","body":"신입도 받는다고 적혀 있어 지원합니다."},{"question_key":"대표프로젝트","body":null}] |
| app-003 | 지원자-0522 | 2026-08-09T09:05:00+09:00 | 직접지원 | 0 | Vue, Nuxt, Firebase | https://github.example.com/0522 | 학부 졸업 프로젝트로 Vue 와 Nuxt 로 학과 행사 신청 사이트를… | [{"question_key":"지원동기","body":"React 로 옮겨 제품을 만들고 싶습니다."},{"question_key":"대표프로젝트","body":"행사 신청 사이트를 기획부터 운영까지 혼자 했습니다."}] |
| app-004 | 지원자-0530 | 2026-08-10T13:22:00+09:00 | 추천 | 18 | Java, Spring, Oracle | — | SI 환경에서 18년간 백엔드를 맡았습니다. 최근 3년은 사내 인사 … | [{"question_key":"지원동기","body":"작은 조직에서 제품을 처음부터 다시 만들어 보고 싶습니다."},{"question_key":"대표프로젝트","body":"인사 시스템 재구축을 기획 단계부터 참여해 출시하고 운영했습니다."}] |
| app-005 | 지원자-0604 | 2026-08-11T18:47:00+09:00 | 사람인 | 3 | — | https://portfolio.example.com/0604 | 타입스크립트로 사내 관리자 화면을 만들고 도커로 묶어 AWS 에 올려… | [{"question_key":"지원동기","body":"제품을 끝까지 책임지는 자리를 찾고 있습니다."},{"question_key":"대표프로젝트","body":"관리자 화면을 기획부터 배포까지 맡았습니다."}] |
아래 JSON Schema 에 맞는 웹 서비스 개발 직군 지원서 300건을 JSON 배열로 생성. 경력과 학력을 열어 둔 공고라 배경이 제각각인 지원자가 섞이도록 하고, 실명 대신 가명 식별자만 쓸 것. resume_text 는 3~5문장으로 실제 이력서 본문처럼.
{"type":"object","properties":{"application_id":{"type":"string"},"applicant_alias":{"type":"string"},"submitted_at":{"type":"string"},"source":{"enum":["사람인","직접지원","추천"]},"career_years":{"type":["number","null"]},"stated_stack_raw":{"type":["string","null"]},"portfolio_url":{"type":["string","null"]},"resume_text":{"type":"string"},"answers":{"type":"array","items":{"type":"object","properties":{"question_key":{"type":"string"},"body":{"type":["string","null"]}},"required":["question_key","body"]}}},"required":["application_id","applicant_alias","submitted_at","source","resume_text","answers"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. (1) 같은 스택을 한글과 영어, 대소문자, 띄어쓰기만 다르게 적은 stated_stack_raw 표기 흔들림 60건 이상(리액트 / React / react, 넥스트JS / Next.js / nextjs), (2) career_years 가 null 인 경력 미기재 50건과 0 인 신입 30건, 15 이상인 장기 경력 10건, (3) portfolio_url 이 null 인 지원서 60건, (4) 같은 applicant_alias 로 접수 기간 안에 두 번 낸 중복 지원 8쌍, (5) resume_text 가 한 문장뿐이거나 answers 의 body 가 전부 null 인 빈 지원서 20건, (6) stated_stack_raw 는 비어 있고 본문에만 스택이 적힌 지원서 25건, (7) 스킬 사전에 없는 신생 프레임워크만 적은 지원서 12건, (8) 이모지와 표 서식이 섞여 붙여넣기된 본문 10건과 3만 자가 넘는 장문 3건. application_id 는 app-001 부터 연속으로. JSON 배열만.{"type":"object","properties":{"application_id":{"type":"string"},"applicant_alias":{"type":"string"},"submitted_at":{"type":"string"},"source":{"enum":["사람인","직접지원","추천"]},"career_years":{"type":["number","null"]},"stated_stack_raw":{"type":["string","null"]},"portfolio_url":{"type":["string","null"]},"resume_text":{"type":"string"},"answers":{"type":"array","items":{"type":"object","properties":{"question_key":{"type":"string"},"body":{"type":["string","null"]}},"required":["question_key","body"]}}},"required":["application_id","applicant_alias","submitted_at","source","resume_text","answers"]}| TypeScript | 요건 항목과 지원서, 검토 시트의 모양을 한 벌의 타입으로 정의해 화면과 API 가 같은 구조를 쓰게 하는 대표 언어 |
| React | 요건 목록과 지원서 원문을 좌우로 붙여 놓고 항목을 확정하면 그 자리에서 상태가 바뀌는 검토 시트 화면 |
| Next.js | 지원자 목록과 검토 시트 화면, 그리고 확정과 전형 이동을 처리하는 서버 액션을 한 앱에 두는 뼈대 |
| Tailwind CSS | 근거 있음과 근거 부족, 자동 판정 불가 세 상태를 한눈에 갈리게 하는 시트 레이아웃과 상태 표시 |
| shadcn/ui | 확정 다이얼로그와 상태 배지, 잠긴 버튼의 안내 문구처럼 판단이 걸리는 지점의 화면 요소 |
| Node.js | 지원서와 요건을 대조해 후보 문장을 찾고 인용을 검사한 뒤 시트를 만들어 돌려주는 API 계층 |
| PostgreSQL | 요건 표와 지원서, 항목별 확정 이력과 전형 상태를 담는 저장소이며 확정 이력은 덮어쓰지 않고 쌓아 감사 흔적을 남깁니다 |
| Docker | 웹과 API, 데이터베이스를 한 벌로 묶어 2주차부터 같은 이미지가 로컬과 배포 환경에서 똑같이 돌게 합니다 |
| Linux | 배포 인스턴스의 실행 환경이며 지원서 보관 기간이 지난 데이터를 지우는 정리 작업을 여기에 걸어 둡니다 |
| AWS | 2주차부터 Docker 이미지를 올려 배포하고 운영하는 인프라이며 데이터베이스와 저장소도 여기로 옮깁니다 |
| Git · GitHub Actions | 변경마다 타입 검사와 인용 실재성 검사를 돌리고 통과한 커밋만 AWS 로 배포하는 흐름 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우고 싶으면 2주차(스택 표기 정규화와 두 검토자 확정 비교, AWS 배포)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(확정 이력 집계와 공고 문구 개선 후보)로 진행합니다.
지원자 한 명의 검토 시트입니다. 요건별 판정 상태와 인용한 지원서 원문, 근거가 없는 항목에서 만든 면접 질문, 그리고 다음 전형으로 넘어가지 못하게 막고 있는 이유를 담습니다. 점수나 합격 추천 필드를 아예 두지 않아, 도구가 사람 대신 판단하는 출력이 나올 수 없게 했습니다.
{"type":"object","properties":{"sheet_id":{"type":"string"},"application_id":{"type":"string"},"stage":{"enum":["접수","서류검토중","서류확정","1차면접","최종"]},"findings":{"type":"array","items":{"type":"object","properties":{"req_id":{"type":"string"},"status":{"enum":["근거있음","근거부족","자동판정불가"]},"cited_field":{"type":["string","null"]},"cited_text":{"type":["string","null"]},"note_ko":{"type":"string"},"confirmed_by":{"type":["string","null"]},"confirmed_at":{"type":["string","null"]}},"required":["req_id","status","note_ko","confirmed_by"]}},"interview_questions":{"type":"array","items":{"type":"object","properties":{"req_id":{"type":"string"},"question_ko":{"type":"string"},"why_ko":{"type":"string"}},"required":["req_id","question_ko","why_ko"]}},"blocked":{"type":"array","items":{"type":"object","properties":{"reason":{"enum":["미확정항목","인용없음","스킬미등록","표기불일치","중복지원"]},"refs":{"type":"array","items":{"type":"string"}},"note_ko":{"type":"string"}},"required":["reason","refs","note_ko"]}},"next_stage_open":{"type":"boolean"}},"required":["sheet_id","application_id","stage","findings","interview_questions","blocked","next_stage_open"]}[
{
"input_ref": "app-001 · 요건 16개 · 담당자 확정 전",
"output": {
"sheet_id": "sheet-app-001",
"application_id": "app-001",
"stage": "서류검토중",
"findings": [
{
"req_id": "r03",
"status": "근거있음",
"cited_field": "resume_text",
"cited_text": "상품 상세와 주문 화면을 Next.js 로 만들었습니다",
"note_ko": "React 계열 웹 서비스 제작 경험이 본문에 그대로 적혀 있습니다.",
"confirmed_by": null,
"confirmed_at": null
},
{
"req_id": "r11",
"status": "근거있음",
"cited_field": "resume_text",
"cited_text": "PostgreSQL 쿼리를 정리해 목록 응답 시간을 줄였습니다",
"note_ko": "PostgreSQL 쪽 근거는 있으나 Node.js API 언급은 없어 반쪽입니다. 한 항목이 두 기술을 함께 묻고 있습니다.",
"confirmed_by": null,
"confirmed_at": null
},
{
"req_id": "r04",
"status": "자동판정불가",
"cited_field": null,
"cited_text": null,
"note_ko": "요구사항을 정리해 구현 가능한 형태로 푸는 일은 문장만으로 가려지지 않아 면접 질문으로 돌렸습니다.",
"confirmed_by": null,
"confirmed_at": null
},
{
"req_id": "r15",
"status": "근거부족",
"cited_field": null,
"cited_text": null,
"note_ko": "Linux, Docker, AWS 를 가리키는 문장이 지원서에 없습니다. 없다는 뜻이 아니라 안 적혔다는 뜻입니다.",
"confirmed_by": null,
"confirmed_at": null
}
],
"interview_questions": [
{
"req_id": "r04",
"question_ko": "주문 상태 전이를 서버 한 곳으로 모으기로 정할 때, 그 요구를 누구와 어떻게 정리해 범위를 잘랐는지 말씀해 주세요.",
"why_ko": "본문에 결과만 적혀 있고 요구사항을 정리한 과정이 없어 근거로 삼지 않았습니다."
},
{
"req_id": "r15",
"question_ko": "만든 화면을 어디에 어떻게 배포해 운영했는지, 배포 환경을 직접 다뤄 본 범위를 알려 주세요.",
"why_ko": "인프라 관련 문장이 지원서에 없어 확인이 필요합니다."
}
],
"blocked": [
{
"reason": "미확정항목",
"refs": [
"r03",
"r04",
"r11",
"r15"
],
"note_ko": "네 항목이 아직 확정되지 않아 1차면접으로 넘기는 버튼이 잠겨 있습니다."
}
],
"next_stage_open": false
}
},
{
"input_ref": "app-012 · 스택을 한글로 적은 지원서 · 정규화 전",
"output": {
"sheet_id": "sheet-app-012",
"application_id": "app-012",
"stage": "서류검토중",
"findings": [
{
"req_id": "r10",
"status": "근거부족",
"cited_field": null,
"cited_text": null,
"note_ko": "본문에는 타입스크립트와 넥스트가 적혀 있으나 사전이 영문 표기만 알고 있어 맞추지 못했습니다. 2주차 정규화 대상입니다.",
"confirmed_by": null,
"confirmed_at": null
},
{
"req_id": "r16",
"status": "근거있음",
"cited_field": "resume_text",
"cited_text": "배포는 깃허브 액션으로 돌렸습니다",
"note_ko": "한글 표기가 사전에 등록돼 있어 맞았습니다.",
"confirmed_by": "채용담당-김",
"confirmed_at": "2026-08-23T10:20:00+09:00"
}
],
"interview_questions": [],
"blocked": [
{
"reason": "표기불일치",
"refs": [
"타입스크립트",
"넥스트",
"포스트그레SQL"
],
"note_ko": "한글로 적힌 스택 이름이 사전에 없어 근거를 찾지 못했습니다. 사람이 읽으면 보이는 내용이라 근거 부족을 그대로 확정하지 말라고 표시했습니다."
},
{
"reason": "미확정항목",
"refs": [
"r10"
],
"note_ko": "한 항목이 미확정이라 다음 전형이 열리지 않습니다."
}
],
"next_stage_open": false
}
},
{
"input_ref": "app-007 · 같은 지원자가 두 번 낸 경우 · 모든 항목 확정 후",
"output": {
"sheet_id": "sheet-app-007",
"application_id": "app-007",
"stage": "서류확정",
"findings": [
{
"req_id": "r03",
"status": "근거있음",
"cited_field": "resume_text",
"cited_text": "리액트와 테일윈드로 화면을 짰고",
"note_ko": "이전 지원서(app-006)의 같은 문장과 동일합니다.",
"confirmed_by": "채용담당-김",
"confirmed_at": "2026-08-23T11:02:00+09:00"
},
{
"req_id": "r07",
"status": "자동판정불가",
"cited_field": null,
"cited_text": null,
"note_ko": "팀 소통은 문장으로 가려지지 않아 면접에서 확인하기로 확정했습니다.",
"confirmed_by": "채용담당-김",
"confirmed_at": "2026-08-23T11:04:00+09:00"
}
],
"interview_questions": [
{
"req_id": "r07",
"question_ko": "혼자 만들던 방식에서 팀으로 옮겨 갈 때 무엇이 가장 달라질 것 같은지, 최근 협업 경험을 들어 말씀해 주세요.",
"why_ko": "프리랜서 이력이라 팀 협업 근거가 지원서에 없습니다."
}
],
"blocked": [
{
"reason": "중복지원",
"refs": [
"app-006",
"app-007"
],
"note_ko": "같은 지원자가 접수 기간 안에 두 번 냈습니다. 어느 지원서를 기준으로 볼지 사람이 골라야 하며, 두 건을 합치거나 지우지 않고 나란히 보여 줍니다."
}
],
"next_stage_open": true
}
}
][자동 검증: 결정론, 사람 없이 통과] 1. JSON Schema 통과: findings 와 blocked 의 필수 필드, status 와 reason 열거값을 기계로 검사해 형식이 깨진 출력을 거릅니다. 점수나 합격 추천 필드가 새로 끼어들면 그 자리에서 실패입니다. 2. 인용 실재 대조: cited_text 가 해당 지원서의 cited_field 안에 그대로 있는지 공백 정규화 후 대조합니다. 원문에 없는 문장을 인용하면 실패입니다. 3. 상태 일관성: findings 에 confirmed_by 가 null 인 항목이 하나라도 있으면 next_stage_open 이 반드시 false 여야 하고, stage 도 서류확정 이상으로 올라가지 않아야 합니다. 4. 자동 판정 불가 강제: 요건 표에서 auto_checkable=false 인 항목이 근거있음으로 표시되면 실패로 처리합니다. 소프트 항목을 도구가 판정해 버리는 것을 막는 핵심 검사입니다. 5. 질문 대응: status 가 근거부족이거나 자동판정불가인 항목은 interview_questions 에 같은 req_id 의 질문이 있는지 확인합니다. 6. 사유 재현: blocked 의 중복지원과 스킬미등록은 지원서 표와 스킬 사전으로 다시 계산해 같은 결론이 나오는지 대조합니다. [수동 검증: 사람 필요] 1. 검토자 2명이 같은 지원서 40건을 각자 확정하고, 두 사람 판정이 갈린 항목을 뽑아 기준을 맞춥니다. 일치 정도는 Cohen's κ(두 사람 답이 우연 이상으로 일치하는 정도, 0~1)로 봅니다. 2. 면접 질문 초안이 지원자를 깎아내리거나 요건과 무관한 사생활을 묻지 않는지 10% 표본을 사람이 읽습니다.