브이엠에스홀딩스
경력근거: AI 개발 환경 생산성을 위한 Claude Code Max 모델 구독 지원
※ 실제 산출물이 아닌 AI 예측 시안입니다.
브이엠에스홀딩스의 인턴 업무는 '다양한 기업 고객의 비즈니스 문제를 해결하기 위한 AI 기반 프로젝트를 초기 단계부터 빠르게 설계하고 개발합니다' 와 '생성형 AI와 AI Agent를 실제 비즈니스 환경에 어떻게 녹여낼지 정의하고 기술을 정교하게 깎아나가는(Optimization) 작업을 합니다' 두 줄로 적혀 있습니다. 이 창구가 그 두 줄을 그대로 밟습니다. 고객사 하나의 업무 규칙을 조항 표로 받아 며칠 만에 도는 MVP를 세우고, 그 위에서 에이전트가 어디까지 답하고 어디서 사람에게 넘길지를 도구 호출과 판정 상태로 정의합니다. 기획자 역할이 따로 없다고 밝힌 팀이라 요청 유형을 정하고 화면을 잡는 일도 같은 사람이 하는데, 1주차가 정확히 그 순서입니다. 조항 표만 갈아끼우면 다음 고객사에 같은 골격이 붙어, 여러 MVP를 빠르게 출시하고 반응이 오는 사업에 집중한다는 이 회사의 전략과도 맞물립니다. 다만 이 포트폴리오가 보여주는 것은 도구를 부르는 에이전트 골격 설계와 근거 강제, 규칙 계산 분리, 백엔드와 화면 구현이라는 기술 역량입니다. 해양(Maritime) 산업 도메인 전문성이나 인사 노무 실무 전문성은 주장하지 않으며, 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
인턴 업무 첫 줄이 '실전 B2B AI 솔루션 및 MVP 빌딩' 이고, 다양한 기업 고객의 비즈니스 문제를 해결하려고 초기 단계부터 빠르게 설계하고 개발한다고 적혀 있습니다. 요구사항 한 덩어리를 받아 며칠 만에 도는 물건으로 세워 본 사람이 바로 붙습니다.
'AI Agent 프레임워크 정의 및 고도화' 가 업무로 못박혀 있고, 기능 구현을 넘어 생성형 AI와 AI Agent를 실제 비즈니스 환경에 어떻게 녹여낼지 정의하고 기술을 깎아나가는 작업이라고 설명합니다. 에이전트가 무엇을 도구로 부르고 어디서 사람에게 넘기는지를 정해 본 경험이 그대로 쓰입니다.
'별도의 기획자 역할이 존재하지 않습니다' 라고 적고 필요하면 어떤 역할이든 유연하게 맡아야 한다고 밝힙니다. 요구사항을 기술로 구현하는 것을 넘어 고객의 문제를 어떻게 더 스마트하게 풀지 고민하는 프로덕트 마인드를 찾는다고도 적혀 있어, 요청 유형을 정하고 화면을 잡는 단계부터 손댄 결과물이 필요합니다.
기업 고객의 사내 규정을 조항 단위로 담아 두고, 직원이 보낸 업무 요청을 받아 처리 결과 초안을 만드는 웹 화면입니다. 요청이 들어오면 에이전트가 어느 조항이 걸리는지 찾아 그 문장을 인용하고, 지급액이나 휴가 일수처럼 계산이 필요한 값은 규칙 계산기를 불러 채웁니다. 담당자 화면에는 요청 원문과 인용된 조항, 계산에 쓴 식과 입력값, 그 둘로 만든 회신 초안이 한 자리에 놓여 그대로 복사해 보내거나 고쳐 보냅니다. 날짜나 금액이 빠져 있거나 걸리는 조항이 없는 요청은 답을 지어내지 않고 무엇이 비었는지 적어 담당자 확인 목록으로 넘깁니다. 규정과 요청 유형은 고객사마다 갈리므로 조항 표만 갈아끼우면 같은 골격이 다음 고객사에 붙습니다. 데모 고객사는 해운사 인사팀으로 놓고 만듭니다.
해운사 인사팀에서 직원 요청을 받는 담당자입니다. 출장 일비가 하루 얼마인지, 교육비를 언제까지 신청해야 하는지 같은 질문이 매일 반복되는데, 답장을 쓸 때마다 규정집 파일을 열어 조항을 찾고 한도를 확인합니다. 올해 개정된 조항이 있어 예전 답장을 복사하면 틀린 금액이 나가고, 그렇다고 매번 다시 읽자니 오전이 지나갑니다. 답장에 어느 조항 때문인지 붙여 두고 싶지만 조항 번호를 찾는 데 시간이 더 들어 말로 대충 설명하고 넘어갑니다. 요청이 들어오면 걸리는 조항과 금액이 이미 채워진 초안을 보고, 애매한 건 도구가 임의로 답하지 말고 자기에게 넘겨 주기를 바라는 사람입니다.
직원 요청의 대부분은 조항과 그 조항에 적힌 한도·계산식으로 답이 정해진다고 보고 조항 표를 정본으로 두면, (a) 요청마다 인용해야 할 조항이 규칙으로 정해져 답이 맞았는지 사람 판단 없이 대조되고, (b) 금액과 일수는 규칙 계산기가 채워 에이전트가 숫자를 지어낼 자리가 사라지며, (c) 값이 빠졌거나 걸리는 조항이 없는 요청은 초안이 만들어지기 전에 담당자 확인 목록으로 빠집니다.
규정 조항 40개와 직원 요청 40건을 담아 두고, 요청 하나를 고르면 에이전트가 인용한 조항과 규칙 계산기가 채운 금액·일수, 그 둘로 만든 회신 초안을 한 화면에 보여주는 웹 앱입니다. 값이 빠졌거나 걸리는 조항이 없는 요청은 초안 대신 확인 목록으로 넘깁니다. 요청은 화면에 붙여 넣는 텍스트로만 받고, 첨부 영수증·신청서 판독은 문서 판독이 들어가므로 2주차로 미룹니다.
조항에 시행일과 폐지일을 두어 요청 날짜 기준으로 그때 유효한 조항이 인용되게 하고, 담당자가 초안을 고쳐 보내면 무엇을 고쳤는지 요청 옆에 남는 검토 흐름을 붙이는 단계입니다. 첨부된 영수증과 신청서도 이때 요청에 붙여 다룹니다.
조항 표와 요청 유형만 갈아끼워 두 번째 고객사를 같은 코드로 띄우고, Terraform으로 정의한 AWS ECS 위에 올려 GitHub Actions로 배포하는 단계입니다.
함정을 섞은 직원 요청 40건을 넣으면 요청마다 인용 조항 번호와 계산된 금액·일수, 그 둘로 만든 회신 초안이 나오는 걸 시연합니다. 초안 아래에는 어느 조항의 어느 문장을 근거로 썼는지와 계산에 쓴 식·입력값이 함께 보입니다
인용 조항이 맞았는지는 조항 표로 정해 둔 정답 집합과 대조해 자동 판정됩니다. 일부러 만든 함정 4종(계산에 필요한 값이 본문에 없음, 금액이 한도와 정확히 같음, 개정 전후 조항이 겹치는 날짜, 규정에 아예 없는 제도)이 초안으로 새지 않고 확인 목록으로 빠지는지 매번 검사합니다
측정: 요청 40건 배치 실행 로그, 표본: 실행마다 전건
요청 문장이 지저분한 30종(두 건이 한 메시지에 섞임, 금액을 십만 원처럼 한글로 적음, 부서명 표기가 갈림, 본문이 한 줄뿐, 첨부만 언급하고 수치가 없음)을 넣어도 출력 형식이 깨지지 않고 처리하지 못한 요청과 그 이유를 보여줍니다
에이전트 모델을 Claude Sonnet과 Gemini, GPT-4o-mini로 바꿔 끼워 같은 요청 묶음을 돌리면 인용 조항이 갈리는 요청 목록이 나오는 걸 보여줍니다. 조항과 요청을 모두 작성자가 만든 합성 기준이라 어느 모델이 낫다는 결론이 아니라 같은 기준으로 비교되는 구조가 돈다는 시연입니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 회신 정확도는 고객사의 실제 규정 문서와 담당자 검수가 있어야 측정됩니다. 이 창구는 그 검증을 바로 돌릴 수 있는 상태로 만듭니다
이건 고객사도 실데이터도 없이 혼자 만든 포트폴리오입니다. 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서 '데모 조건 동작 + 실검증 준비 상태' 로 솔직히 설명합니다
조항도 요청도 내가 만들었으니 잘 맞는 게 당연합니다. 한도와 정확히 같은 금액, 값이 빠진 요청, 개정 전후가 겹치는 날짜, 규정에 없는 제도 문의 같은 경계 케이스를 요청 묶음에 섞어 쉬운 문제만 푸는 게 아님을 보여줍니다
조항 표가 곧 이 창구의 시야입니다. 표에 넣지 않은 규정이 걸리는 요청은 판정이 조용히 비는 게 아니라 확인 목록으로 빠지게 만들었지만, 그래도 확인 목록이 길어지면 담당자 일이 그대로 남습니다. 초안이 나온 비율을 품질로 읽지 말고 조항 표가 덮는 범위로 읽어야 합니다
규칙으로 답이 정해지는 요청만 다룹니다. 징계 수위나 평가 이의처럼 사람이 판단해야 하는 요청은 애초에 처리 대상에서 빼 두었으므로, 이 창구가 덮는 범위를 실제보다 넓게 말하지 않아야 합니다
실제 도입 시 달라지는 것을 명시합니다. 고객사의 실제 규정 문서와 개정 공지 반영, 메일·메신저 연동, 담당자 검수 절차로 교체해야 하며 이는 도입 단계 과제로 분리합니다
이 포트폴리오가 보여주는 것은 도구를 부르는 에이전트 골격 설계와 근거 강제, 규칙 계산 분리, 백엔드와 화면 구현이라는 기술 역량입니다. 해양(Maritime) 산업 도메인 전문성이나 인사 노무 실무 전문성은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 사내 규정을 조항 단위로 쪼갠 표입니다. 어떤 요청에 어느 조항이 걸리는지와 금액·일수가 얼마인지를 정하는 기준이며, 한도가 조항에 없거나 개정으로 두 버전이 겹치는 조항을 섞어 판정이 늘 깔끔하지는 않게 만들었습니다.
| clause_id | category | title | body | effective_from | effective_to | limit_amount | limit_unit | formula | needs_approval |
|---|---|---|---|---|---|---|---|---|---|
| C-101 | 출장 | 국내 출장 일비 | 국내 출장 시 일비는 1일 30,000원을 지급한다. 출발일과 도착일… | 2024-01-01 | 2026-03-31 | 30,000 | 원/일 | 일비 = 30000 * 출장일수 | false |
| C-102 | 출장 | 국내 출장 일비(2026년 개정) | 국내 출장 시 일비는 1일 35,000원을 지급한다. 출발일과 도착일… | 2026-04-01 | — | 35,000 | 원/일 | 일비 = 35000 * 출장일수 | false |
| C-103 | 출장 | 국내 출장 숙박비 | 국내 출장 숙박비는 1박 100,000원을 한도로 실비 정산한다. 한… | 2024-01-01 | — | 100,000 | 원/박 | 숙박비 = min(영수증금액, 100000 * 숙박일수) | false |
| C-104 | 출장 | 해외 출장 숙박비 | 해외 출장 숙박비는 지역별 한도표에 따라 실비 정산한다. 지역별 한도… | 2024-01-01 | — | — | — | — | true |
| C-105 | 교육 | 직무교육비 지원 | 직무와 관련된 외부 교육 수강료는 1인당 연 1,000,000원 한도… | 2025-01-01 | — | 1,000,000 | 원/년 | 지원액 = min(수강료, 1000000 - 당해연도누적지원액) | true |
아래 JSON Schema 에 맞는 해운사 사내 규정 조항 60건을 JSON 배열로 생성. category 는 출장·교육·수당·휴가·경조 다섯 가지를 고루 섞고, body 는 실제 규정문처럼 '~한다' 종결의 한 문단으로 쓸 것. clause_id 는 C-101 부터 연속으로.
{"type":"object","properties":{"clause_id":{"type":"string"},"category":{"enum":["출장","교육","수당","휴가","경조"]},"title":{"type":"string"},"body":{"type":"string"},"effective_from":{"type":"string"},"effective_to":{"type":["string","null"]},"limit_amount":{"type":["number","null"]},"limit_unit":{"type":["string","null"]},"formula":{"type":["string","null"]},"needs_approval":{"type":"boolean"}},"required":["clause_id","category","title","body","effective_from","needs_approval"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. (1) 같은 항목이 개정돼 구 조항(effective_to 에 날짜가 있음)과 신 조항(effective_to 가 null)이 짝으로 존재하는 쌍 6쌍, (2) 한도가 조항에 없고 별도 표를 참조해 limit_amount 와 limit_unit 이 null 인 조항 8건, (3) formula 가 null 이라 금액 계산이 아니라 절차만 규정하는 조항 10건, (4) limit_amount 가 0 이라 지원하지 않는다는 뜻인 조항 3건(0 과 null 을 구분해서 쓸 것), (5) body 안 금액 표기를 '500,000원'·'50만원'·'금 오십만원' 처럼 흔들어 쓴 조항 8건, (6) 같은 category 안에서 조건이 겹쳐 어느 조항을 적용할지 사람이 정해야 하는 조항 4건. formula 는 사람이 읽고 그대로 계산할 수 있는 한 줄 식으로 쓸 것. JSON 배열만.{"type":"object","properties":{"clause_id":{"type":"string"},"category":{"enum":["출장","교육","수당","휴가","경조"]},"title":{"type":"string"},"body":{"type":"string"},"effective_from":{"type":"string"},"effective_to":{"type":["string","null"]},"limit_amount":{"type":["number","null"]},"limit_unit":{"type":["string","null"]},"formula":{"type":["string","null"]},"needs_approval":{"type":"boolean"}},"required":["clause_id","category","title","body","effective_from","needs_approval"]}직원이 인사팀에 보낸 업무 요청 메시지입니다. 에이전트가 읽고 처리하는 입력이며, 값이 빠지거나 두 건이 한 메시지에 붙거나 규정에 없는 제도를 묻는 요청을 일부러 섞어 쉬운 요청만 푸는 게 아님을 보여줍니다.
5월 11일부터 5월 13일까지 부산 조선소 입회 출장을 다녀옵니다. 일비가 하루 얼마로 계산되는지, 3일 다 인정되는지 알려주세요.
3월 9일부터 3월 10일까지 목포 출장분을 이제야 올립니다. 정산이 늦어졌는데 일비는 어느 기준으로 계산되나요.
아래 JSON Schema 에 맞는 해운사 직원 업무 요청 60건을 JSON 배열로 생성. body 는 직원이 실제로 쓴 메일·메신저 문장처럼 존댓말 두세 문장으로 쓰고, request_id 는 R-001 부터 연속으로.
{"type":"object","properties":{"request_id":{"type":"string"},"title":{"type":"string"},"body":{"type":"string"},"dept_raw":{"type":"string"},"submitted_at":{"type":["string","null"]},"attachment_note":{"type":["string","null"]},"channel":{"enum":["메일","메신저","구두전달"]}},"required":["request_id","title","body","dept_raw","channel"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. (1) 금액이나 일수가 규정 한도와 정확히 같은 경계 요청 8건, (2) 계산에 필요한 값(통상시급·출장 일자·수강료)이 본문에 없는 결측 요청 10건, (3) submitted_at 이 null 이고 본문에도 날짜가 '다음 주' 처럼만 적힌 요청 6건, (4) 같은 부서를 '해상운영팀'·'해상운영본부'·'해상운영' 으로 다르게 적은 표기 흔들림 10건, (5) 규정에 아예 없는 제도를 묻는 요청 5건, (6) 한 메시지에 서로 다른 두 건을 같이 물어본 요청 6건, (7) 금액을 '십만 원'·'100,000원'·'10만원' 으로 흔들어 적은 요청 8건, (8) attachment_note 에 첨부를 언급하지만 본문에는 수치가 없는 요청 5건. JSON 배열만.{"type":"object","properties":{"request_id":{"type":"string"},"title":{"type":"string"},"body":{"type":"string"},"dept_raw":{"type":"string"},"submitted_at":{"type":["string","null"]},"attachment_note":{"type":["string","null"]},"channel":{"enum":["메일","메신저","구두전달"]}},"required":["request_id","title","body","dept_raw","channel"]}| Claude | 요청 문장에서 유형과 필요한 값을 뽑고 회신 초안 문구를 쓰는 에이전트 모델입니다. 조항 판정과 금액 계산은 맡기지 않습니다 |
| Nest.js | 요청 접수·조항 조회·처리 결과 기록을 맡는 백엔드 API(사내 Server 스택 중 Node 계열) |
| React.js | 요청 원문과 인용 조항, 계산 과정, 회신 초안을 한 화면에 놓는 담당자 검토 UI |
| Next.js | 검토 화면과 조회 경로를 한 벌로 배포하는 프레임워크 |
| PostgreSQL | 조항·요청·처리 결과·회신 이력을 담는 저장소이며, 요청 날짜 기준으로 그때 유효한 조항을 고르는 질의도 여기서 돕니다 |
| LLM(Gemini, GPT) | 에이전트 모델을 바꿔 끼울 때의 비교 대상으로, 같은 요청 묶음에서 인용 조항이 갈리는지 봅니다 |
| Terraform | 3주차에 실행 환경을 코드로 정의해 같은 구성을 다시 세울 수 있게 남깁니다 |
| AWS ECS | 3주차에 컨테이너를 올려 창구를 상시 띄우는 실행 기반 |
| GitHub Actions | 조항 표나 프롬프트가 바뀌면 요청 묶음을 자동으로 다시 처리하고 배포까지 잇는 자동화 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우고 싶으면 2주차(개정 조항 구분·담당자 수정 기록)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(두 번째 고객사·AWS 배포)로 진행합니다.
요청 하나를 처리한 결과입니다. 인용한 조항과 그 원문 한 줄, 계산에 쓴 식과 입력값, 회신 초안, 담당자에게 넘긴 이유를 나눠 담아 판정이 규칙대로 됐는지 기계로 다시 검사할 수 있게 합니다.
{"type":"object","properties":{"request_id":{"type":"string"},"model":{"type":"string"},"request_type":{"enum":["출장","교육","수당","휴가","경조","분류불가"]},"verdict":{"enum":["처리가능","보완필요","규정없음","담당자확인"]},"cited_clauses":{"type":"array","items":{"type":"object","properties":{"clause_id":{"type":"string"},"quoted_line":{"type":"string"}},"required":["clause_id","quoted_line"]}},"computed":{"type":["object","null"],"properties":{"field":{"type":"string"},"value":{"type":["number","null"]},"unit":{"type":"string"},"formula":{"type":"string"},"inputs":{"type":"object"}},"required":["field","value","unit","formula"]},"missing_fields":{"type":"array","items":{"type":"string"}},"handoff_reason":{"type":["string","null"]},"reply_draft":{"type":["string","null"]}},"required":["request_id","model","request_type","verdict","cited_clauses","missing_fields","reply_draft"]}[
{
"input_ref": "R-001 부산 출장 일비 문의 · Claude Sonnet · prompt v2",
"output": {
"request_id": "R-001",
"model": "claude-sonnet",
"request_type": "출장",
"verdict": "처리가능",
"cited_clauses": [
{
"clause_id": "C-102",
"quoted_line": "국내 출장 시 일비는 1일 35,000원을 지급한다."
}
],
"computed": {
"field": "일비",
"value": 105000,
"unit": "원",
"formula": "일비 = 35000 * 출장일수",
"inputs": {
"출장일수": 3,
"출발일": "2026-05-11",
"도착일": "2026-05-13"
}
},
"missing_fields": [],
"handoff_reason": null,
"reply_draft": "안녕하세요. 5월 11일부터 13일까지 3일 출장은 출발일과 도착일을 각각 1일로 세어 일비 3일분이 나옵니다. 2026년 4월 1일 출발분부터 1일 35,000원이 적용돼 합계 105,000원입니다. 출장보고서와 함께 정산 올려 주시면 됩니다."
}
},
{
"input_ref": "R-002 개정 전 날짜의 출장 정산 (구 조항이 인용돼야 하는 경우)",
"output": {
"request_id": "R-002",
"model": "claude-sonnet",
"request_type": "출장",
"verdict": "처리가능",
"cited_clauses": [
{
"clause_id": "C-101",
"quoted_line": "국내 출장 시 일비는 1일 30,000원을 지급한다."
}
],
"computed": {
"field": "일비",
"value": 60000,
"unit": "원",
"formula": "일비 = 30000 * 출장일수",
"inputs": {
"출장일수": 2,
"출발일": "2026-03-09",
"도착일": "2026-03-10"
}
},
"missing_fields": [],
"handoff_reason": null,
"reply_draft": "안녕하세요. 3월 9일부터 10일까지 출장은 개정 전 기준이 적용돼 1일 30,000원으로 계산합니다. 2일분 합계 60,000원이며, 정산이 늦어진 것과 무관하게 출장 당시 기준을 씁니다."
}
},
{
"input_ref": "R-007 야간작업 수당 문의 (통상시급이 본문에 없음)",
"output": {
"request_id": "R-007",
"model": "claude-sonnet",
"request_type": "수당",
"verdict": "보완필요",
"cited_clauses": [
{
"clause_id": "C-108",
"quoted_line": "22시부터 익일 06시 사이에 근무한 시간에 대해 통상시급의 1.5배를 지급한다."
}
],
"computed": null,
"missing_fields": [
"통상시급",
"근무일자"
],
"handoff_reason": "야간근무시간은 본문에서 8시간으로 읽히지만 통상시급이 없어 금액을 정할 수 없습니다. 지난주 화요일과 목요일이 며칠인지도 본문만으로는 확정되지 않습니다.",
"reply_draft": null
}
},
{
"input_ref": "R-009 반려동물 돌봄비 문의 (조항 표에 걸리는 조항 없음)",
"output": {
"request_id": "R-009",
"model": "claude-sonnet",
"request_type": "분류불가",
"verdict": "규정없음",
"cited_clauses": [],
"computed": null,
"missing_fields": [],
"handoff_reason": "조항 표 다섯 개 분류 어디에도 걸리는 조항이 없어 담당자가 제도 유무를 직접 답해야 합니다.",
"reply_draft": null
}
}
][자동 검증: 결정론, 사람 없이 통과] 1. JSON Schema 통과: verdict·request_type 열거값과 인용 배열 구조를 기계로 검사해 형식이 깨진 출력을 거릅니다. 2. 인용 조항 대조: cited_clauses 의 clause_id 집합을 요청마다 미리 정해 둔 정답 조항 집합과 비교합니다. 빠진 조항과 더 붙은 조항을 따로 셉니다. 3. 인용 문장 존재 확인: quoted_line 이 그 조항 body 안에 실제로 있는 문장인지 대조해, 조항 번호만 맞고 문장을 지어낸 경우를 잡습니다. 4. 계산값 재계산: computed.formula 와 inputs 로 값을 다시 계산해 value 와 맞는지 봅니다. 초안 문구 안 숫자도 뽑아 computed.value 와 같은지 대조해 모델이 다른 숫자를 적는 경우를 막습니다. 5. 근거 없는 초안 차단: verdict 가 처리가능인데 cited_clauses 가 비었거나, 보완필요·규정없음인데 reply_draft 가 채워져 있으면 실패로 처리합니다. 6. 결측 강제: missing_fields 가 비어 있지 않으면 computed 는 반드시 null 이어야 합니다. 값이 없는데 금액을 채운 조합이 나오면 실패입니다. 7. 시행일 검사: 인용한 조항의 effective_from 과 effective_to 사이에 요청 기준일이 들어가는지 확인해, 개정 전후가 겹치는 시점에서 엉뚱한 버전을 인용하지 않았는지 봅니다. [수동 검증: 사람 필요] 1. 인사 담당 경험자 2명이 회신 초안을 그대로 보낼 만한지 3단계(그대로 발송·문구만 수정·다시 씀)로 라벨링하고, 두 사람 판정 일치도를 Cohen's κ(두 사람 답이 우연 이상으로 일치하는 정도, 0~1)로 봅니다. 2. 확인 목록으로 넘긴 요청 가운데 사실은 조항으로 답할 수 있었던 건이 얼마나 되는지 10% 표본을 사람이 점검합니다.
근거: AI 개발 환경 생산성을 위한 Claude Code Max 모델 구독 지원