올거FDE(SW) - SA
2.7 (7)올거나이즈코리아
경력근거: 顧客要件を技術的成果物として具?化
어제 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
올거나이즈는 산업 특화 온프레미스 LLM 모델부터 Agent RAG, 노코드 LLM 앱 빌더, 앱 마켓까지를 한 제품군으로 묶어 한국·일본·미국 300사 이상의 엔터프라이즈에 넣고 있고, 일본에서는 미쓰이스미토모 파이낸셜그룹·도쿄메트로·히타치제작소·NTT도코모·ANA 같은 대기업이 고객사입니다. 이 포지션의 FDE(Solutions Architect)는 도쿄 현장에서 과제를 파악해 顧客要件を技術的成果物として具?化 하고 그 지견을 프로덕트팀에 되돌리는 사람인데, 요건을 앱 설정 초안으로 바로 굳힐 수 있는 건 노코드 앱 빌더와 앱 마켓이 제품 안에 이미 있기 때문이라 다른 회사 제품으로는 같은 사슬이 만들어지지 않습니다. 카탈로그에 안 걸린 요건이 그대로 프로덕트팀 요청 건수로 쌓이는 구조도 현장 지견을 제품 개선으로 연결하라는 이 공고의 두 번째 업무를 그대로 옮긴 것입니다. 다만 이 포트폴리오가 보여주는 것은 고객 문서를 검증 가능한 판정 항목으로 바꾸고 판정마다 원문 인용을 묶는 기술이며, 일본 엔터프라이즈 도입 실무나 금융·통신 업계 규정에 대한 도메인 전문성은 주장하지 않습니다.
고객과 함께 비즈니스 과제를 정의하고 AI 기술 기반의 해결책을 설계하는 일이 이 포지션의 첫 업무입니다. 이 도구는 고객이 회신한 요건 문장을 기능 id와 설정 키로 옮겨, 회의 자리에서 나온 말을 그대로 설계 초안으로 굳힙니다.
현장에서 얻은 지견을 프로덕트팀과 공유해 제품 기능과 성능 개선에 기여하는 일이 이 역할의 두 번째 축입니다. 이 도구는 카탈로그의 어떤 기능으로도 덮이지 않은 요건을 모아 요청 목록으로 집계하므로, 현장에서 반복해 막히는 지점이 문장이 아니라 건수로 남습니다.
AI Agent를 스스로 설계하고 개발한 경험, 그리고 Claude Code나 Codex로 업무 효율화 도구를 만든 경험을 요건으로 적어 둔 공고입니다. 이 도구는 요건을 읽고 카탈로그를 검색해 판정까지 가는 다단계 에이전트이고, 카탈로그 파서와 채점 스크립트를 코딩 에이전트로 만든 과정이 그대로 산출물에 남습니다.
일본 고객사 담당자가 엑셀로 회신한 요건 목록과 제품 기능 카탈로그를 받아, 요건 한 줄마다 기능 id를 잇고 판정을 붙이는 CLI입니다. 되는 요건은 노코드 앱 빌더에 그대로 넣을 수 있는 설정 초안 JSON으로 바꾸고, 제품 기능으로 안 되는 요건은 프로덕트팀 요청 한 줄로, 사내망이나 인증 확인이 필요한 요건은 고객에게 물을 질문으로 나눠 적습니다. 요건 문장을 정규화하는 일과 확인 질문 문안을 쓰는 일만 LLM이 맡고, 기능 매핑과 판정과 채점은 카탈로그 규칙이 맡아 인용할 기능 문단이 없으면 지원된다고 적지 못합니다.
올거나이즈 재팬의 FDE(Solutions Architect)입니다. 도쿄 고객사 킥오프에서 정보시스템 부서가 사내 양식으로 회신한 일본어 요건 엑셀을 받아 들고, 어느 항목이 지금 제품으로 바로 되고 어느 항목이 개발 요청이며 어느 항목이 네트워크 확인부터 필요한지를 다음 회의 전까지 가려내야 하는 사람입니다. 백 줄짜리 시트를 제품 문서와 번갈아 보며 손으로 표시하다 우선도 표기가 다른 항목을 놓치던 일을, 명령 한 줄과 대응표 파일로 끝내고 싶어 합니다.
요건 문장을 자유 텍스트로 두지 않고 기능 id와 설정 키와 판정 라벨 세 칸으로 강제하면, 판정 근거가 카탈로그 문단 인용으로 고정되어 인용이 없으면 지원 판정이 나가지 못하고, 되는 요건은 설정 키가 이미 채워져 앱 빌더 설정 초안이 곧바로 나오며, 판정이 맞았는지를 사람 판단 없이 정답 라벨과 대조해 채점합니다.
요건 엑셀 한 장과 기능 카탈로그를 인자로 받아 요건별 판정·인용 기능 문단·확인 질문이 적힌 마크다운 대응표와 앱 설정 초안 JSON을 파일로 내는 동작하는 CLI입니다. 카탈로그는 제품 문서 추출본을 가정한 더미로 시작하고, 사내망 배포나 실제 앱 빌더 연동은 뒤로 미룹니다.
요건 90건을 정답 판정과 비교해 판정 일치율과 인용 기능 id 정확도를 내고, 인용 문단이 없으면 지원 판정을 막는 가드를 붙인 상태입니다.
열 이름과 우선도 표기가 다른 두 번째 고객사 요건서에 별칭 사전만 갈아끼워 같은 판정을 돌리고, 어떤 요건 유형이 반복해서 카탈로그에 안 걸리는지 집계한 프로덕트팀 요청 리포트 파일입니다.
요건 120줄짜리 엑셀 한 장과 기능 카탈로그를 넣으면, 요건별 판정과 인용 문단이 붙은 대응표 마크다운과 앱 설정 초안 JSON이 한 번의 실행으로 나오는 걸 시연합니다
일부러 만든 지저분한 요건 30종(구분 행 혼입, 한 셀에 요건 두 개, 우선도 표기 흔들림, 우선도 공란, 카탈로그에 없는 기능, 제한 초과 수치)을 넣어도 출력 형식이 한 번도 안 깨지고, 인용할 문단이 없는 요건은 지원으로 적히지 않습니다
2주차에 요건 90건을 정답 판정과 비교하면 판정 일치가 77건(약 86%), 인용한 기능 id가 정답과 같은 경우가 지원·부분지원 판정 중 91%입니다. 사람 라벨 2명과의 일치도는 Cohen's κ(두 사람이 우연히 맞을 확률을 걷어낸 일치도, 1에 가까울수록 잘 맞음) 0.78입니다. 단, 요건과 정답을 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 판정 정확도는 올거나이즈의 실제 제품 기능 문서와 일본 고객사가 회신한 실 요건서가 있어야 측정 가능합니다. 이 도구는 그 검증을 바로 돌릴 수 있는 상태로 만듭니다
이건 고객과 실데이터 없이 혼자 만든 포트폴리오입니다. 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다
이 포트폴리오가 보여주는 것은 고객 문서를 검증 가능한 판정 항목으로 바꾸고 판정마다 원문 인용을 묶는 기술이며, 일본 엔터프라이즈 도입 실무나 금융·통신 업계 규정에 대한 도메인 전문성은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다
정답 판정을 작성자가 만들었으니 잘 맞는 게 당연합니다. 한 셀에 요건이 둘 섞인 행, 우선도가 빈 행, 카탈로그에 없는 기능, 제한 수치 바로 위아래의 경계값을 요건서에 일부러 섞어 쉬운 항목만 통과시키는 게 아님을 보여줍니다
요건이 반쯤 맞아 보일 때 지원으로 적으면 고객에게 약속한 셈이 되어 도입 후에 되돌리기 어렵습니다. 인용 문단이 없거나 검색 점수가 낮으면 확인 필요로 내리도록 기본값을 잡았고, 이 보수적 기본값 때문에 확인 항목이 늘어나는 것은 감수합니다
실제 도입에서는 제품 카탈로그가 릴리스마다 바뀌고 고객사마다 요건서 양식과 사내 용어가 다릅니다. 카탈로그 갱신 절차와 별칭 사전을 고객사별로 다시 맞춰야 하므로 도입 단계 과제로 분리합니다
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
일본 고객사 정보시스템 부서가 사내 양식으로 회신했다고 가정한 요건 목록 추출본입니다. 판정이 실행되는 대상이자 채점의 기준이며, 구분 행·한 셀 복수 요건·우선도 표기 흔들림·공란·카탈로그에 없는 기능을 일부러 섞어 정리 규칙과 판정 규칙이 실제로 걸리는지 봅니다.
| req_id | sheet_row | section_raw | row_kind | text_ja | text_ko | priority_raw | priority | gold_verdict | gold_capability_id |
|---|---|---|---|---|---|---|---|---|---|
| req_001 | 4 | 1. 検索機能 | section_header | 1. 検索機能 | 1. 검색 기능 | — | — | not_a_requirement | — |
| req_002 | 5 | 1. 検索機能 | requirement | 社内規程PDFを取り込み、質問に対して根拠箇所を引用して回答すること | 사내 규정 PDF를 넣고 질문에 근거 위치를 인용해 답할 것 | 必須 | must | supported | cap_rag_doc_search |
| req_003 | 6 | 1. 検索機能 | requirement | 1ファイル120MBの設計図面PDFを検索対象に含めること | 한 파일 120MB짜리 설계 도면 PDF를 검색 대상에 포함할 것 | MUST | must | partial | cap_rag_doc_search |
| req_004 | 7 | 1. 検索機能 | requirement | スキャン画像のみのPDF（紙の稟議書）も表として抽出できること | 스캔 이미지만 있는 PDF(종이 품의서)도 표로 추출할 수 있을 것 | 推奨 | should | partial | cap_table_extract |
| req_005 | 9 | 2. アプリ構成 | requirement | 申請者が案件番号と金額を入力する画面を用意すること | 신청자가 안건 번호와 금액을 입력하는 화면을 준비할 것 | 必須 | must | supported | cap_app_builder_form |
아래 JSON Schema에 맞는 일본 고객사 요건 목록 90행을 JSON 배열로 생성합니다. 섹션은 검색 기능·앱 구성·연계와 인증·도입과 운용 네 가지를 쓰고, text_ja는 일본 기업 요건서 문체(체언 종결 또는 '~すること')로 씁니다. gold_verdict는 다음 규칙으로 정합니다. product_capabilities에 인용할 문단이 있고 제한 조건에 안 걸리면 supported, 인용 문단은 있으나 제한 수치나 입력 형식에 걸리면 partial, 카탈로그 어디에도 없으면 unsupported, 사내망·프록시·DNS·인증서·온프레미스 설치 전제면 network_precheck, 한 문장에 요건이 둘 이상이거나 대상·주체가 없어 무엇을 만들지 정해지지 않으면 needs_clarification, 구분 행이나 안내 문구면 not_a_requirement로 둡니다. supported와 partial일 때만 gold_capability_id를 채우고 나머지는 null로 둡니다.
{"type":"object","properties":{"req_id":{"type":"string"},"sheet_row":{"type":"integer"},"section_raw":{"type":"string"},"row_kind":{"type":"string","enum":["requirement","section_header"]},"text_ja":{"type":"string"},"text_ko":{"type":["string","null"]},"priority_raw":{"type":["string","null"]},"priority":{"type":["string","null"],"enum":["must","should","nice",null]},"gold_verdict":{"type":"string","enum":["supported","partial","unsupported","network_precheck","needs_clarification","not_a_requirement"]},"gold_capability_id":{"type":["string","null"]}},"required":["req_id","sheet_row","row_kind","text_ja","gold_verdict"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(정리 규칙과 판정 규칙이 실제로 걸리게): (1) 우선도를 必須·MUST·★★·◎·空欄으로 흔들어 적은 행 12건 이상이고 그중 사전에 없는 표기는 priority를 null로 둡니다. (2) 섹션 구분 행과 '以下、記入例' 같은 안내 문구 행 6건(row_kind=section_header, gold_verdict=not_a_requirement). 이 행은 대응표에 절대 들어가면 안 됩니다. (3) 한 셀에 요건이 둘 섞인 행 6건과 대상이 없는 모호 요건 5건(needs_clarification), (4) 제한 수치 바로 위아래 경계값 행 6건(파일 50MB와 51MB, 로그 365일과 366일), (5) text_ko가 null인 번역 미기입 행 8건, (6) 카탈로그에 없는 기능 요건 6건(음성 실시간 처리·영상 생성 등), (7) 사내망·프록시·사설 DNS·인증서·온프레미스 설치 요건 8건. JSON 배열만.{"type":"object","properties":{"req_id":{"type":"string"},"sheet_row":{"type":"integer"},"section_raw":{"type":"string"},"row_kind":{"type":"string","enum":["requirement","section_header"]},"text_ja":{"type":"string"},"text_ko":{"type":["string","null"]},"priority_raw":{"type":["string","null"]},"priority":{"type":["string","null"],"enum":["must","should","nice",null]},"gold_verdict":{"type":"string","enum":["supported","partial","unsupported","network_precheck","needs_clarification","not_a_requirement"]},"gold_capability_id":{"type":["string","null"]}},"required":["req_id","sheet_row","row_kind","text_ja","gold_verdict"]}제품 기능 문서에서 문단 단위로 뽑았다고 가정한 기능 카탈로그입니다. 판정의 근거이자 인용 대상이며, 각 행의 doc_anchor_ja가 대응표에 그대로 인용됩니다. 제한 조건을 명시한 행을 함께 두어 부분지원 판정이 규칙으로 갈리게 합니다.
| capability_id | name | category | summary_ko | config_keys | limit_note | doc_anchor_ja | doc_version |
|---|---|---|---|---|---|---|---|
| cap_rag_doc_search | 문서 검색과 근거 인용 응답 | rag_search | 업로드한 문서를 색인해 질문에 답하고 인용한 문단 위치를 함께 냅니다. | ["index_name","top_k","rerank","cite_source"] | 1파일 최대 50MB, 색인 대상은 텍스트 레이어가 있는 PDF와 오… | アップロ一ドした文書を索引化し、質問に対して引用箇所を付けて回答します。1フ… | 2026.06 |
| cap_table_extract | 표와 PDF 추출 | rag_search | PDF와 오피스 문서에서 표를 행과 열 구조로 뽑아 색인합니다. | ["table_mode","header_rows"] | 텍스트 레이어가 없는 스캔 이미지 PDF는 표 추출 대상이 아닙니다 | PDFおよびオフィス文書から表を行列構造として抽出します。テキストレイヤ一の… | 2026.06 |
| cap_app_builder_form | 입력 폼 블록 | app_builder_block | 노코드 앱 빌더에서 사용자 입력 항목을 정의하는 블록입니다. | ["fields","required","field_type"] | — | ノ一コ一ドアプリビルダ一の入力フォ一ムブロックで、利用者が入力する項目と必須… | 2026.06 |
| cap_app_builder_prompt | 프롬프트 블록 | app_builder_block | 입력값을 변수로 받아 모델에 보낼 지시문을 구성하는 블록입니다. | ["system_prompt","variables","model"] | — | 入力値を變數として受け取り、モデルへの指示文を組み立てるプロンプトブロックです。 | 2026.06 |
| cap_app_builder_output | 출력 포맷 블록 | app_builder_block | 응답을 표나 지정한 필드 구조로 내보내는 블록입니다. | ["output_format","columns"] | — | 回答を表形式または指定したフィ一ルド構造で出力する出力ブロックです。 | 2026.06 |
아래 JSON Schema에 맞는 제품 기능 카탈로그 40행을 JSON 배열로 생성합니다. category는 rag_search·app_builder_block·connector·auth·ops·deploy를 고루 쓰고, doc_anchor_ja는 제품 매뉴얼 문체의 일본어 한두 문장으로 쓰되 제한 조건이 있으면 그 수치를 문장 안에 그대로 적습니다. config_keys는 실제 설정 파일에 쓸 법한 snake_case 키로 2~4개 둡니다.
{"type":"object","properties":{"capability_id":{"type":"string"},"name":{"type":"string"},"category":{"type":"string","enum":["rag_search","app_builder_block","connector","auth","ops","deploy"]},"summary_ko":{"type":"string"},"config_keys":{"type":"array","items":{"type":"string"}},"limit_note":{"type":["string","null"]},"doc_anchor_ja":{"type":"string"},"doc_version":{"type":"string"}},"required":["capability_id","name","category","summary_ko","config_keys","doc_anchor_ja","doc_version"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라: (1) 제한 수치를 명시한 행 12건 이상(파일 크기·보관 일수·동기화 주기·단계 수). 이 수치가 부분지원 판정의 유일한 근거가 되게 합니다. (2) 이름이 비슷해 검색에서 헷갈리는 기능 쌍 4쌍(문서 검색과 표 추출, 앱 마켓 게시와 열람 권한 등), (3) limit_note가 null인 무제한 기능 8건, (4) doc_version이 서로 다른 구버전 문단 4건(같은 capability_id의 옛 제한 수치). 최신 버전만 인용되어야 합니다. (5) 설정 키가 하나뿐인 최소 기능 3건. JSON 배열만.{"type":"object","properties":{"capability_id":{"type":"string"},"name":{"type":"string"},"category":{"type":"string","enum":["rag_search","app_builder_block","connector","auth","ops","deploy"]},"summary_ko":{"type":"string"},"config_keys":{"type":"array","items":{"type":"string"}},"limit_note":{"type":["string","null"]},"doc_anchor_ja":{"type":"string"},"doc_version":{"type":"string"}},"required":["capability_id","name","category","summary_ko","config_keys","doc_anchor_ja","doc_version"]}| Python | 요건 엑셀 파싱과 우선도 별칭 정규화, 기능 매핑 규칙, 판정 채점 스크립트를 구현하는 언어입니다 |
| LLM | 일본어 요건 문장에서 기능 후보 질의와 정규화 항목을 뽑는 변환, 그리고 고객 확인 질문 문안 작성에만 쓰고 판정 자체에는 쓰지 않습니다 |
| RAG | 기능 카탈로그 문단을 임베딩으로 검색해 요건과 맞는 문단만 상위로 올리고, 인용 id는 검색 결과 안에서만 고르게 강제하는 검색 계층입니다 |
| Claude | 요건 정규화와 확인 질문 생성에 쓰는 모델이며, 카탈로그 파서와 채점 스크립트 초안은 Claude Code로 작성해 작업 기록을 그대로 남깁니다 |
| Linux | 고객사 반입 노트북의 *NIX 환경에서 외부 연결 없이 도는 단일 실행 파일 형태의 CLI입니다 |
| Kubernetes | 온프레미스 설치형 요건(노드 사양·스토리지클래스·GPU 배치)을 별도 분류로 갈라, 앱 설정이 아니라 설치 전제 확인 항목으로 보내는 판정 기준입니다 |
| TCP/IP·DNS·HTTP·VPN·방화벽 | 사내망 접근·프록시 경유·사설 DNS 해석·인증서 같은 요건을 네트워크 사전확인 항목으로 분류하고, 개방이 필요한 대상과 해석해야 할 이름을 고객 확인 질문으로 전개하는 규칙입니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(판정과 인용 채점)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(다른 고객사 양식 적용과 미지원 요건 집계)로 진행합니다.
요건 한 건의 판정 기록입니다. 판정·인용한 기능 문단·앱 설정 초안·고객 확인 질문·프로덕트팀 요청을 한 스키마에 담아 대응표 마크다운과 설정 초안 JSON에 그대로 씁니다. 지원하지 못하는 요건도 같은 스키마로 사유를 남깁니다.
{"type":"object","properties":{"req_id":{"type":"string"},"verdict":{"type":"string","enum":["supported","partial","unsupported","network_precheck","needs_clarification","not_a_requirement"]},"capability_id":{"type":["string","null"]},"config_draft":{"type":["object","null"]},"citations":{"type":"array","items":{"type":"object","properties":{"capability_id":{"type":"string"},"doc_version":{"type":"string"},"quote_ja":{"type":"string","minLength":10}},"required":["capability_id","doc_version","quote_ja"]}},"open_question":{"type":["string","null"]},"product_request":{"type":["string","null"]},"note":{"type":"string","minLength":20},"hedge":{"type":["string","null"]}},"required":["req_id","verdict","capability_id","citations","note"]}[
{
"input_ref": "req_002 (사내 규정 PDF를 넣고 근거를 인용해 답할 것)",
"output": {
"req_id": "req_002",
"verdict": "supported",
"capability_id": "cap_rag_doc_search",
"config_draft": {
"index_name": "shanai_kitei",
"top_k": 5,
"rerank": true,
"cite_source": true
},
"citations": [
{
"capability_id": "cap_rag_doc_search",
"doc_version": "2026.06",
"quote_ja": "アップロ一ドした文書を索引化し、質問に対して引用箇所を付けて回答します。"
}
],
"open_question": null,
"product_request": null,
"note": "문서 색인과 인용 응답이 기능 문단으로 그대로 덮이므로 색인 이름과 인용 표시만 설정하면 됩니다.",
"hedge": null
}
},
{
"input_ref": "req_003 (한 파일 120MB 도면 PDF를 검색 대상에 포함)",
"output": {
"req_id": "req_003",
"verdict": "partial",
"capability_id": "cap_rag_doc_search",
"config_draft": {
"index_name": "sekkei_zumen",
"top_k": 5,
"rerank": true,
"cite_source": true
},
"citations": [
{
"capability_id": "cap_rag_doc_search",
"doc_version": "2026.06",
"quote_ja": "1ファイルの上限は50MBです。"
}
],
"open_question": "設計図面PDFを50MB以下に分割して連携いただくことは可能でしょうか。",
"product_request": "1파일 상한 50MB를 넘는 대용량 도면 PDF의 분할 색인 지원 요청",
"note": "검색 기능 자체는 있으나 문서에 적힌 1파일 50MB 상한에 걸려 그대로는 못 넣습니다. 분할 반입 여부를 고객에게 확인하고 상한 완화는 요청 목록에 올렸습니다.",
"hedge": "상한을 넘는 파일의 처리 시간은 합성 기준 추정이라 실제 색인 소요와 다를 수 있습니다"
}
},
{
"input_ref": "req_010 (사내망 프록시 경유와 사내 DNS 이름 해석)",
"output": {
"req_id": "req_010",
"verdict": "network_precheck",
"capability_id": null,
"config_draft": null,
"citations": [],
"open_question": "プロキシの認証方式（Basic・NTLM・認証なし）と、社内DNSで解決する必要のあるホスト名の一覧をご共有いただけますでしょうか。あわせて、外向きに開放が必要な宛先と포트를 사전에 확인하고자 합니다.",
"product_request": null,
"note": "앱 설정으로 정해지는 항목이 아니라 설치 전 네트워크 확인 항목이라 판정을 네트워크 사전확인으로 두고, 프록시 인증 방식과 이름 해석 대상, 개방이 필요한 대상을 질문으로 전개했습니다.",
"hedge": "확인 결과에 따라 도입 일정이 달라지므로 지원 여부를 이 단계에서 단정하지 않습니다"
}
},
{
"input_ref": "req_013 (콜센터 통화 음성을 실시간 요약)",
"output": {
"req_id": "req_013",
"verdict": "unsupported",
"capability_id": null,
"config_draft": null,
"citations": [],
"open_question": "通話音声そのものではなく、既存の書き起こしテキストを対象とする形でも要件を満たせますでしょうか。",
"product_request": "실시간 음성 입력과 통화 중 요약 기능 요청, 콜센터 도입 건에서 두 번째로 나온 요건",
"note": "카탈로그 어느 문단에도 음성 실시간 처리가 없어 인용할 근거가 없으므로 지원으로 적지 않았습니다. 기존 통화 기록 텍스트를 대상으로 바꾸는 대안을 질문으로 두고 요청 목록에 올렸습니다.",
"hedge": null
}
},
{
"input_ref": "req_014 (문서 검색 정확도를 높일 것)",
"output": {
"req_id": "req_014",
"verdict": "needs_clarification",
"capability_id": null,
"config_draft": null,
"citations": [],
"open_question": "どの業務のどの質問で精度が不足しているのか、具体的な質問例を3件ほどご提示いただけますでしょうか。",
"product_request": null,
"note": "대상 업무와 판단 기준이 문장에 없어 무엇을 만들지 정해지지 않으므로 실행하지 않고 질문으로 남겼습니다. 질문 예시를 받으면 검색 설정 항목으로 다시 판정합니다.",
"hedge": "조건이 반만 잡혀 추측으로 지원 판정을 내리지 않습니다"
}
}
][자동 검증] 1. JSON Schema parse로 출력 형식(필드·enum·인용 배열 구조)이 스키마를 통과하는지 확인합니다. 형식이 깨지면 대응표에 싣지 않습니다. 2. verdict를 요건서에 심은 gold_verdict와 비교하고, supported·partial이면 capability_id가 gold_capability_id와 같은지 봅니다. 3. citations의 quote_ja가 카탈로그 doc_anchor_ja의 부분 문자열인지 대조해, 원문에 없는 문장을 인용으로 지어내면 실패로 셉니다. 4. verdict가 supported·partial인데 citations가 비어 있으면 차단하고 needs_clarification으로 내립니다. 5. row_kind가 section_header인 행이 대응표에 실리면 실패로 셉니다. 6. 같은 capability_id의 구버전 문단이 인용되면 최신 doc_version으로 대체되었는지 확인합니다. [수동 검증] 1. 도입 경험자 2명이 비동기로 판정을 라벨링해 규칙 판정과의 일치도를 봅니다. 2. 전체의 5%를 사람이 직접 카탈로그에서 문단을 찾아 인용이 맞는지 점검합니다. 3. 고객 확인 질문 문안은 일본어 경어 표현이 회신용으로 자연스러운지 사람이 읽고 다듬습니다.