BCPrincipal (Forward Deployed AI Engineer), South Korea - BCG X
4.1 (359)BCG X
경력근거: deploying AI/GenAI solutions, including Agentic AI systems, at enterprise scale
55일 전 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
BCG X 는 3,000명이 넘는 기술 인력이 여러 지역과 산업의 고객사 프로젝트를 옮겨 다니며 AI 솔루션을 짓는 조직이고, 이 자리는 공고가 적은 대로 Agentic AI 를 포함한 GenAI 솔루션을 전사 규모로 배포하는 사람을 뽑습니다. 파일럿과 전사 배포 사이가 벌어지는 이유는 고객사마다 처리량과 예산이 다르게 잡혀 있기 때문이고, 공고가 따로 적어 둔 알고리즘 계산 효율 개선과 비기술 이해관계자 설득은 그 벌어진 폭을 숫자로 보여 임원을 움직이라는 말입니다. 고객사 이름과 실제 계약 조건은 공개된 곳이 없으므로 이 포트폴리오는 client_04 같은 익명 코드로만 다룹니다. 이 포트폴리오는 실행 기록에서 비용과 응답시간과 실패율을 계산해 계약 한도와 견주는 기술을 보여줍니다. 컨설팅 프로젝트 운영이나 특정 산업의 규제 전문성은 주장하지 않습니다. 그 밖의 깊이는 아는 척하지 않고 면접에서 모른다고 답하겠습니다.
공고가 여러 지역과 산업의 고객사와 함께 설계하고 짓고 배포하는 자리라고 적었습니다. 계약마다 규모 조건이 달라지는 지점을 판정 대상으로 잡았습니다.
자격요건이 Agentic AI 를 포함한 GenAI 솔루션을 전사 규모로 배포해 본 사람을 지목합니다. 파일럿과 전사 사이에서 무엇이 먼저 막히는지를 다루는 산출물로 맞췄습니다.
알고리즘의 계산 효율을 끌어올리는 일과 비기술 이해관계자를 이끄는 일이 나란히 적혀 있습니다. 비용과 응답시간을 숫자로 내는 리포트가 그 두 요구를 한 번에 받습니다.
고객사에서 몇 주 돌린 GenAI 파일럿의 실행 기록과, 고객사가 계약 단계에서 정해 준 하루 처리량·응답시간 한도·월 예산·허용 실패율, 그리고 쓰는 모델의 공개 단가표를 한 번에 받아 유스케이스마다 전사 규모에서 무엇이 먼저 무너지는지 정하는 CLI입니다. 실행 한 건의 입력·출력 토큰에 단가를 곱해 건당 비용을 내고 하루 처리량과 한 달을 곱해 달러 금액으로 키우며, 같은 유스케이스의 응답시간을 큰 값 순으로 세워 상위 5% 지점을 잡고, 실패한 실행을 세어 비율을 내고, 한 번에 밀어 넣은 토큰이 모델이 받는 한도 안에 드는지 봅니다. 결과는 터미널 요약 표와 유스케이스별 사유가 붙은 Markdown 리포트 파일로 나와, 임원 보고 전에 손볼 곳만 남습니다.
여러 지역·산업의 고객사를 옮겨 다니며 GenAI 파일럿을 전사 배포까지 끌고 가는 엔지니어링 리드 — 파일럿 건수에서는 다 되지만 고객사가 잡아 준 하루 처리량으로 늘렸을 때 어느 유스케이스가 한도를 넘는지는 임원 보고 전날까지 아무도 모른다
파일럿을 돌린 실행 기록에는 이미 입력·출력 토큰과 응답시간과 실패 여부가 한 줄씩 남고, 전사 규모의 한도는 고객사가 계약 단계에서 숫자로 정해 둡니다. 그래서 처리량을 곱해 보는 계산만 붙이면 어느 유스케이스가 어디서 막히는지가 임원 보고 전날이 아니라 파일럿 마지막 주에 정해진다는 가정입니다.
실행 기록 JSONL 과 고객사 한도표 YAML, 모델 단가표 YAML 을 넘기면 유스케이스마다 다섯 판정 중 하나를 정하고 달마다 드는 금액과 상위 5% 응답시간, 실패율, 가장 큰 입력 토큰을 붙여 터미널 요약 표와 Markdown 리포트로 내는 CLI 입니다. 실행 기록은 지원자가 LangChain 콜백으로 자기 파일럿을 돌려 직접 남깁니다.
유스케이스 9건에 손으로 매긴 정답 판정을 붙여 자동 판정과 대조해 사유별 일치율과 어긋난 유스케이스의 목록을 내고, 같은 실행을 AWS 야간 배치로 올려 아침마다 리포트가 갱신되게 하는 단계입니다.
모델을 더 싼 것으로 바꾸거나 프롬프트에 넣는 발췌를 줄이거나 같은 질문의 응답을 재사용했을 때 달마다 드는 금액과 상위 5% 응답시간이 각각 얼마나 내려가는지 계산해, 확대 회의에 그대로 올릴 손질 후보를 붙이는 단계입니다.
엔지니어링 리드가 실행 기록과 고객사 한도표, 모델 단가표를 넘기면 유스케이스마다 판정과 근거 수치가 붙은 리포트 파일이 나오는 과정을 시연합니다.
유스케이스 9건에 손으로 매긴 정답 판정을 붙여 대조하고 사유별 일치율을 냅니다. 단, 정답과 실행 기록을 모두 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
리포트가 깨지지 않는 범위를 미리 재 둡니다. 응답시간이 안 적힌 실행과 단가표에 없는 모델 이름, 실행 기록이 하나도 없는 목표 줄을 섞은 입력 30종을 돌려 형식이 유지되는지 보고, 견주지 못한 칸은 숫자를 비운 채 그 이유를 hedge 에 적습니다.
월 예산을 1,800달러에서 2,400달러로 올렸을 때 예산으로 막히던 유스케이스가 몇 건 줄어드는지 회귀로 확인합니다.
여기까지가 이 포트폴리오가 재는 전부입니다. 위 수치는 제가 만든 실행 기록을 제가 채점한 값이고, 전사 배포 적격 여부는 BCG X 가 맡은 고객사의 실 파일럿 로그와 실 계약 조건을 넣어야 나옵니다. 그 측정을 첫날 바로 돌릴 수 있는 상태까지가 이 작업의 범위입니다.
여기 적힌 금액과 응답시간은 제가 돌린 파일럿을 제가 채점한 값이라 성능을 증명하지 못합니다. 면접에서는 리포트가 실제로 도는 것과, 고객사 실 로그가 들어오면 그날 바로 잴 수 있다는 것까지만 말합니다.
판정 기준을 정한 사람과 정답을 붙인 사람이 같으니 잘 맞는 것은 당연합니다. 응답시간이 빈 실행과 응답이 통째로 비어 돌아온 실행, 단가표에 없는 모델 이름까지 넣어 두어 잘 도는 실행만 골라 보여 주는 일이 안 되게 했습니다.
이 포트폴리오는 실행 기록에서 비용과 응답시간과 실패율을 계산해 계약 한도와 견주는 기술을 보여줍니다. 컨설팅 프로젝트 운영이나 특정 산업의 규제 전문성은 주장하지 않습니다. 판정은 곱셈과 정렬과 나눗셈이 하고 모델은 리포트 문장만 맡습니다.
인라인 실행 기록이 유스케이스마다 두세 건이라 상위 5% 지점과 실패율이 실제보다 거칠게 잡힙니다. 그래서 두 수치는 확정이 아니라 증강한 실행 기록으로 다시 세는 후보로 냅니다.
모델 단가와 한 번에 받는 토큰 한도는 공급사가 수시로 바꾸고 고객사 계약 조건도 프로젝트마다 다르므로, 두 표를 코드 밖 파일로 분리해 갱신하는 일을 도입 단계 과제로 둡니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사에서 몇 주 돌린 GenAI 파일럿의 실행 기록입니다. 실행 번호와 고객사 코드, 유스케이스 번호, 쓴 모델, 입력·출력 토큰, 응답시간, 도구 호출 수, 실패 여부, 실행 시각을 한 줄에 둡니다. 지원자는 LangChain 콜백으로 자기 파일럿을 돌려 이 표를 스스로 남깁니다. 응답시간이 안 남은 줄과 응답이 통째로 비어 돌아온 줄, 규정 문서를 여러 번 끌어와 입력 토큰이 12만을 넘긴 줄을 일부러 섞어 판정이 갈리게 둡니다.
| run_no | client_id | use_case_id | model | prompt_tokens | completion_tokens | latency_ms | tool_calls | failed | run_at |
|---|---|---|---|---|---|---|---|---|---|
| R-041201 | client_04 | UC-1042 | claude-sonnet-4-5 | 4,200 | 900 | 5,200 | 2 | false | 2026-08-24T10:12:00 |
| R-041202 | client_04 | UC-1042 | claude-sonnet-4-5 | 3,800 | 1,100 | 4,800 | 2 | false | 2026-08-24T11:30:00 |
| R-041203 | client_04 | UC-1042 | claude-sonnet-4-5 | 4,600 | 1,000 | 6,100 | 3 | false | 2026-08-25T09:41:00 |
| R-041301 | client_04 | UC-1043 | claude-haiku-4-5 | 1,200 | 380 | 9,800 | 1 | false | 2026-08-24T13:05:00 |
| R-041302 | client_04 | UC-1043 | claude-haiku-4-5 | 1,350 | 420 | 11,400 | 1 | false | 2026-08-25T14:22:00 |
아래 JSON Schema 를 그대로 만족하는 실행 기록 행을 600개 더 만들어 주세요. 고객사는 client_04 와 client_07 두 곳을 두고 유스케이스는 고객사 한도표에 있는 번호에서 고릅니다. 모델은 단가표에 있는 이름에서 고르되 단가표에 없는 이름도 두세 줄 섞습니다. prompt_tokens 는 800 에서 130000 사이로 흩되 대부분을 만 이하에 두고, completion_tokens 는 0 에서 2000 사이로 두며 몇 줄은 0 으로 둡니다. latency_ms 는 1000 에서 20000 사이로 흩고 스무 줄쯤은 아예 비웁니다. tool_calls 는 0 에서 8 사이로 두고, failed 는 전체의 2%쯤만 참으로 두되 도구 호출이 많은 줄에 몰리게 합니다. 쉬운 데이터만 만들지 말 것 — 다음 하드 케이스를 의도적으로 섞어라: 응답시간이 비어 있는 줄, 응답 토큰이 0 인 줄, 입력과 출력을 더한 값이 그 모델이 받는 한도를 넘는 줄, 실행 시각이 파일럿 기간 밖인 줄. 형식을 깨뜨리는 시도 10건은 데이터가 아니라 별도 파일로 두고 CLI 가 그 줄만 건너뛰는지 봅니다.
{"type": "object", "properties": {"run_no": {"type": "string"}, "client_id": {"type": "string"}, "use_case_id": {"type": "string"}, "model": {"type": "string"}, "prompt_tokens": {"type": "integer", "minimum": 0}, "completion_tokens": {"type": "integer", "minimum": 0}, "latency_ms": {"type": ["integer", "null"], "minimum": 0}, "tool_calls": {"type": "integer", "minimum": 0}, "failed": {"type": "boolean"}, "run_at": {"type": "string"}}, "required": ["run_no", "client_id", "use_case_id", "model", "prompt_tokens", "completion_tokens", "latency_ms", "tool_calls", "failed", "run_at"]}{"type": "object", "properties": {"run_no": {"type": "string"}, "client_id": {"type": "string"}, "use_case_id": {"type": "string"}, "model": {"type": "string"}, "prompt_tokens": {"type": "integer", "minimum": 0}, "completion_tokens": {"type": "integer", "minimum": 0}, "latency_ms": {"type": ["integer", "null"], "minimum": 0}, "tool_calls": {"type": "integer", "minimum": 0}, "failed": {"type": "boolean"}, "run_at": {"type": "string"}}, "required": ["run_no", "client_id", "use_case_id", "model", "prompt_tokens", "completion_tokens", "latency_ms", "tool_calls", "failed", "run_at"]}고객사가 계약 단계에서 정해 준 전사 규모 조건입니다. 유스케이스마다 하루에 몇 건이 돌지, 응답이 몇 밀리초 안에 와야 하는지, 달마다 얼마까지 쓸 수 있는지, 실패를 몇 퍼센트까지 봐 주는지를 한 줄로 둡니다. 지원자는 계약서 대신 공개된 SLA 문서 양식을 보고 이 표를 직접 적습니다. 파일럿을 아직 안 돌린 유스케이스도 몇 줄 두어 실행 기록이 하나도 없는 목표 줄이 어떻게 다뤄지는지 보게 합니다.
| client_id | use_case_id | use_case_name | daily_volume | p95_latency_ms | monthly_budget_usd | max_failure_rate |
|---|---|---|---|---|---|---|
| client_04 | UC-1042 | 계약서 조항 추출 | 4,000 | 9,000 | 1,800 | 0.02 |
| client_04 | UC-1043 | 콜센터 통화 요약 | 1,500 | 6,000 | 900 | 0.02 |
| client_04 | UC-1044 | 견적 초안 작성 | 2,000 | 8,000 | 600 | 0.02 |
| client_04 | UC-1045 | 사내 규정 질의응답 | 300 | 20,000 | 3,000 | 0.02 |
| client_04 | UC-1046 | 회의록 정리 | 800 | 7,000 | 400 | 0.03 |
아래 JSON Schema 를 그대로 만족하는 고객사 한도 행을 40개 더 만들어 주세요. 고객사를 네 곳쯤 두고 고객사마다 유스케이스를 대여섯 개 붙입니다. daily_volume 은 100 에서 20000 사이로 두되 문서 요약 계열은 작게, 분류 계열은 크게 둡니다. p95_latency_ms 는 2000 에서 30000 사이, monthly_budget_usd 는 300 에서 5000 사이, max_failure_rate 는 0.005 에서 0.05 사이로 둡니다. 실행 기록이 없는 유스케이스도 대여섯 줄 넣어 견줄 실행이 없는 경우가 나오게 합니다.
{"type": "object", "properties": {"client_id": {"type": "string"}, "use_case_id": {"type": "string"}, "use_case_name": {"type": "string"}, "daily_volume": {"type": "integer", "minimum": 0}, "p95_latency_ms": {"type": "integer", "minimum": 0}, "monthly_budget_usd": {"type": "number", "minimum": 0}, "max_failure_rate": {"type": "number", "minimum": 0, "maximum": 1}}, "required": ["client_id", "use_case_id", "use_case_name", "daily_volume", "p95_latency_ms", "monthly_budget_usd", "max_failure_rate"]}{"type": "object", "properties": {"client_id": {"type": "string"}, "use_case_id": {"type": "string"}, "use_case_name": {"type": "string"}, "daily_volume": {"type": "integer", "minimum": 0}, "p95_latency_ms": {"type": "integer", "minimum": 0}, "monthly_budget_usd": {"type": "number", "minimum": 0}, "max_failure_rate": {"type": "number", "minimum": 0, "maximum": 1}}, "required": ["client_id", "use_case_id", "use_case_name", "daily_volume", "p95_latency_ms", "monthly_budget_usd", "max_failure_rate"]}쓰는 모델의 공개 단가표입니다. 모델 이름과 입력 1,000토큰 단가, 출력 1,000토큰 단가, 한 번에 받는 최대 토큰을 한 줄로 둡니다. 지원자가 공급사 가격 페이지를 보고 그대로 옮겨 적을 수 있는 값이라 실물과 모양이 같습니다. 비용과 모델 입력 한도 두 판정이 모두 이 표의 계수로 계산됩니다.
| model | input_price_per_1k | output_price_per_1k | max_context_tokens |
|---|---|---|---|
| claude-sonnet-4-5 | 0.003 | 0.015 | 200,000 |
| claude-haiku-4-5 | 0.001 | 0.004 | 200,000 |
| claude-opus-4-1 | 0.015 | 0.075 | 200,000 |
| gpt-4o | 0.003 | 0.01 | 128,000 |
| gpt-4o-mini | 0 | 0.001 | 128,000 |
아래 JSON Schema 를 그대로 만족하는 단가 행을 20개 더 만들어 주세요. 공급사 가격 페이지에 실제로 올라오는 모양대로 적되 모델 이름은 소문자와 하이픈으로 씁니다. input_price_per_1k 는 0.0001 에서 0.02 사이, output_price_per_1k 는 입력 단가의 두 배에서 다섯 배 사이로 두고, max_context_tokens 는 32768·65536·128000·200000·1000000 중에서 고릅니다. 같은 계열의 작은 모델과 큰 모델을 짝지어 넣어 모델을 바꿨을 때 금액이 얼마나 갈라지는지 보게 합니다.
{"type": "object", "properties": {"model": {"type": "string"}, "input_price_per_1k": {"type": "number", "minimum": 0}, "output_price_per_1k": {"type": "number", "minimum": 0}, "max_context_tokens": {"type": "integer", "minimum": 1}}, "required": ["model", "input_price_per_1k", "output_price_per_1k", "max_context_tokens"]}{"type": "object", "properties": {"model": {"type": "string"}, "input_price_per_1k": {"type": "number", "minimum": 0}, "output_price_per_1k": {"type": "number", "minimum": 0}, "max_context_tokens": {"type": "integer", "minimum": 1}}, "required": ["model", "input_price_per_1k", "output_price_per_1k", "max_context_tokens"]}| Python | 실행 기록과 한도표, 단가표를 맞춰 유스케이스마다 막히는 사유를 정하는 판정 엔진과 CLI 본체를 맡습니다. |
| LangChain | 지원자가 자기 파일럿을 돌리며 토큰 수와 응답시간, 도구 호출 수, 실패 여부를 한 줄씩 남기는 콜백으로 씁니다. 입력 데이터를 지원자가 직접 만드는 통로입니다. |
| OpenAI | GPT 계열로 같은 유스케이스를 한 번 더 돌려, 모델을 바꿨을 때 금액과 응답시간이 어떻게 갈라지는지 3주차 비교에 씁니다. |
| AWS | 2주차부터 실행 기록 버킷과 야간 배치를 AWS 에 올려, 아침마다 리포트가 새로 만들어지게 합니다. |
| CI/CD | 판정 규칙을 고칠 때마다 정답 대조를 자동으로 돌려, 한 사유를 고치다 다른 사유가 어긋나는 것을 커밋 단계에서 잡습니다. |
✗ fail → 한도가 안 적힌 유스케이스가 절반을 넘으면 계약 담당에게 받아 먼저 채웁니다.
✓ pass → 2주차 정답 대조와 야간 배치로 넘어갑니다.
✗ fail → 어긋난 유스케이스를 모아 사유 우선순위와 상위 5% 지점을 잡는 기준을 다시 봅니다.
✓ pass → 3주차 손질 후보 계산으로 넘어갑니다.
유스케이스 하나마다 전사 규모로 늘렸을 때 무엇이 먼저 막히는지 정합니다. 막히면 예산·응답시간·실패율·모델 입력 한도 중 어느 쪽인지 싣고, 달마다 드는 금액과 상위 5% 응답시간, 실패율, 가장 큰 입력 토큰을 함께 냅니다. 리포트도 이 사유를 기준으로 절을 나눕니다.
{"type": "object", "properties": {"verdict_no": {"type": "string"}, "client_id": {"type": "string"}, "use_case_id": {"type": "string"}, "model": {"type": "string"}, "rollout_verdict": {"type": "string", "enum": ["전사 배포 가능", "월 예산 초과", "응답시간 한도 초과", "실패율 한도 초과", "모델 입력 한도 초과"]}, "monthly_cost_usd": {"type": ["number", "null"], "minimum": 0, "description": "같은 use_case_id 실행의 prompt_tokens 평균을 1000으로 나눠 input_price_per_1k 를 곱하고 completion_tokens 평균을 1000으로 나눠 output_price_per_1k 를 곱해 더한 건당 비용에 daily_volume 과 30을 곱한 달러 금액입니다."}, "p95_latency_ms": {"type": ["integer", "null"], "minimum": 0, "description": "같은 use_case_id 의 latency_ms 를 큰 값 순으로 세워 상위 5% 지점에 놓인 값입니다. 값이 안 남은 실행은 세는 대상에서 뺐습니다."}, "failure_rate": {"type": ["number", "null"], "minimum": 0, "maximum": 1, "description": "같은 use_case_id 에서 failed 가 참인 실행 수를 전체 실행 수로 나눠 소수 둘째 자리까지 남긴 비율입니다."}, "max_total_tokens": {"type": ["integer", "null"], "minimum": 0, "description": "같은 use_case_id 실행 중 prompt_tokens 와 completion_tokens 를 더한 값이 가장 큰 줄의 값입니다."}, "evidence": {"type": "array", "items": {"type": "object", "properties": {"field": {"type": "string"}, "agg": {"type": ["string", "null"]}, "value": {}}, "required": ["field", "value"]}}, "summary": {"type": "string"}, "hedge": {"type": ["string", "null"]}}, "required": ["verdict_no", "client_id", "use_case_id", "model", "rollout_verdict", "evidence", "summary"]}[
{
"verdict_no": "RV-001",
"client_id": "client_04",
"use_case_id": "UC-1046",
"model": "claude-haiku-4-5",
"rollout_verdict": "전사 배포 가능",
"monthly_cost_usd": 119.04,
"p95_latency_ms": 4300,
"failure_rate": 0,
"max_total_tokens": 3840,
"evidence": [
{
"field": "latency_ms",
"agg": "max",
"value": 4300
},
{
"field": "p95_latency_ms",
"agg": null,
"value": 7000
},
{
"field": "monthly_budget_usd",
"agg": null,
"value": 400
}
],
"summary": "하루 800건으로 늘려도 달러로 119달러에 그치고 응답시간도 한도의 절반이라 이 유스케이스는 그대로 전사에 올립니다.",
"hedge": "응답시간이 안 남은 실행이 한 건 있어 남은 실행만으로 상위 5% 지점을 잡았습니다."
},
{
"verdict_no": "RV-002",
"client_id": "client_04",
"use_case_id": "UC-1047",
"model": "gpt-4o-mini",
"rollout_verdict": "전사 배포 가능",
"monthly_cost_usd": 82.08,
"p95_latency_ms": 1600,
"failure_rate": 0,
"max_total_tokens": 1240,
"evidence": [
{
"field": "latency_ms",
"agg": "max",
"value": 1600
},
{
"field": "p95_latency_ms",
"agg": null,
"value": 3000
},
{
"field": "daily_volume",
"agg": null,
"value": 12000
},
{
"field": "monthly_budget_usd",
"agg": null,
"value": 500
}
],
"summary": "하루 12,000건으로 가장 많이 도는데도 달러로 82달러에 머물고 응답시간이 한도의 절반이라 확대에 걸리는 것이 없습니다.",
"hedge": null
},
{
"verdict_no": "RV-003",
"client_id": "client_04",
"use_case_id": "UC-1042",
"model": "claude-sonnet-4-5",
"rollout_verdict": "월 예산 초과",
"monthly_cost_usd": 3312,
"p95_latency_ms": 6100,
"failure_rate": 0,
"max_total_tokens": 5600,
"evidence": [
{
"field": "prompt_tokens",
"agg": "avg",
"value": 4200
},
{
"field": "completion_tokens",
"agg": "avg",
"value": 1000
},
{
"field": "input_price_per_1k",
"agg": null,
"value": 0.003
},
{
"field": "output_price_per_1k",
"agg": null,
"value": 0.015
},
{
"field": "daily_volume",
"agg": null,
"value": 4000
},
{
"field": "monthly_budget_usd",
"agg": null,
"value": 1800
}
],
"summary": "건당 0.0276달러가 하루 4,000건과 한 달에 곱해지면서 달러로 3,312달러가 되어 계약 예산 1,800달러를 넘습니다.",
"hedge": "조항 전문을 통째로 넣은 프롬프트가 비용의 대부분이라 확대 전에 발췌 폭부터 줄여 봅니다."
},
{
"verdict_no": "RV-004",
"client_id": "client_04",
"use_case_id": "UC-1043",
"model": "claude-haiku-4-5",
"rollout_verdict": "응답시간 한도 초과",
"monthly_cost_usd": 115.2,
"p95_latency_ms": 11400,
"failure_rate": 0,
"max_total_tokens": 1770,
"evidence": [
{
"field": "latency_ms",
"agg": "max",
"value": 11400
},
{
"field": "p95_latency_ms",
"agg": null,
"value": 6000
},
{
"field": "monthly_budget_usd",
"agg": null,
"value": 900
}
],
"summary": "상위 5% 지점이 11.4초라 상담사가 통화를 끊기 전에 요약이 못 돌아오고, 계약이 잡아 둔 6초를 두 배 가까이 넘습니다.",
"hedge": null
},
{
"verdict_no": "RV-005",
"client_id": "client_04",
"use_case_id": "UC-1044",
"model": "gpt-4o-mini",
"rollout_verdict": "실패율 한도 초과",
"monthly_cost_usd": 42.3,
"p95_latency_ms": 3400,
"failure_rate": 0.33,
"max_total_tokens": 3350,
"evidence": [
{
"field": "failed",
"agg": "count",
"value": 1
},
{
"field": "run_no",
"agg": "count",
"value": 3
},
{
"field": "max_failure_rate",
"agg": null,
"value": 0.02
}
],
"summary": "도구 호출이 여섯 번까지 늘어난 실행에서 응답이 통째로 비어 돌아왔고, 그 한 건 때문에 실패율이 계약 한도 2%를 크게 넘습니다.",
"hedge": "인라인 실행 기록이 세 건이라 비율이 크게 잡히므로 증강한 실행 기록으로 다시 셉니다."
},
{
"verdict_no": "RV-006",
"client_id": "client_04",
"use_case_id": "UC-1045",
"model": "gpt-4o",
"rollout_verdict": "모델 입력 한도 초과",
"monthly_cost_usd": 2637,
"p95_latency_ms": 18400,
"failure_rate": 0.5,
"max_total_tokens": 128700,
"evidence": [
{
"field": "prompt_tokens",
"agg": null,
"value": 126800
},
{
"field": "completion_tokens",
"agg": null,
"value": 1900
},
{
"field": "max_context_tokens",
"agg": null,
"value": 128000
},
{
"field": "tool_calls",
"agg": null,
"value": 5
}
],
"summary": "규정 문서를 다섯 번 끌어온 실행에서 입력과 출력을 합친 토큰이 128,700이 되어 이 모델이 받는 128,000을 넘었습니다.",
"hedge": "실패율도 한도를 넘지만 토큰이 모델 한도를 넘는 쪽이 확대를 먼저 막으므로 그 사유로 세웠습니다."
},
{
"verdict_no": "RV-007",
"client_id": "client_07",
"use_case_id": "UC-2051",
"model": "(미정)",
"rollout_verdict": "전사 배포 가능",
"monthly_cost_usd": null,
"p95_latency_ms": null,
"failure_rate": null,
"max_total_tokens": null,
"evidence": [
{
"field": "use_case_id",
"agg": null,
"value": "UC-2051"
},
{
"field": "run_no",
"agg": "count",
"value": 0
},
{
"field": "daily_volume",
"agg": null,
"value": 600
},
{
"field": "monthly_budget_usd",
"agg": null,
"value": 700
}
],
"summary": "설비 점검 보고 요약은 한도만 계약에 적혀 있고 파일럿을 아직 한 번도 안 돌려, 막을 근거도 통과시킬 근거도 없는 줄입니다.",
"hedge": "실행 기록이 한 줄도 없어 네 수치를 모두 비웠습니다. 판정 칸은 막을 근거가 없다는 뜻일 뿐이니 통과 묶음이 아니라 리포트 끝의 견줄 실행 없음 절에서 읽어야 합니다."
}
][자동 검증 · 코드가 판정합니다] 1. rollout_verdict 가 enum 다섯 값 중 하나인지 확인합니다. 2. verdict_no·client_id·use_case_id·model·rollout_verdict·evidence·summary 가 모두 채워졌는지 확인합니다. 3. use_case_id 가 실행 기록과 고객사 한도표 양쪽에 실재하는 값인지 대조합니다. 4. monthly_cost_usd 를 같은 use_case_id 의 prompt_tokens 평균에 input_price_per_1k 를, completion_tokens 평균에 output_price_per_1k 를 곱해 더한 건당 비용에 daily_volume 과 30 을 곱해 다시 계산하고, monthly_budget_usd 보다 크면 rollout_verdict 가 월 예산 초과인지 확인합니다. 5. p95_latency_ms 를 같은 use_case_id 의 latency_ms 를 큰 값 순으로 세워 상위 5% 지점으로 다시 계산하고, 한도표의 p95_latency_ms 보다 크면 rollout_verdict 가 응답시간 한도 초과인지 확인합니다. 다만 latency_ms 가 안 남은 실행은 세는 대상에서 뺍니다. 6. failure_rate 를 failed 가 참인 실행 수를 전체 실행 수로 나눠 다시 계산하고, max_failure_rate 보다 크면 rollout_verdict 가 실패율 한도 초과인지 확인합니다. 7. max_total_tokens 를 prompt_tokens 와 completion_tokens 의 합이 가장 큰 줄의 값으로 다시 계산하고, 그 모델의 max_context_tokens 보다 크면 rollout_verdict 가 모델 입력 한도 초과인지 확인합니다. 이 사유는 다른 넷보다 먼저 세우고, 같은 사유에 여러 줄이 걸리면 tool_calls 가 많은 줄을 위에 올립니다. 8. rollout_verdict 가 전사 배포 가능이면 위 네 조건 어디에도 안 걸리는지 다시 확인합니다. 9. evidence 의 field 이름이 실행 기록·고객사 한도표·모델 단가표에 실재하는 컬럼인지 대조합니다. 10. agg 가 없는 evidence 의 value 가 그 컬럼에 수록된 행 값과 같은지 확인합니다. 11. 한도표에 있는데 실행 기록이 한 줄도 없는 목표 줄은 monthly_cost_usd·p95_latency_ms·failure_rate·max_total_tokens 를 모두 비우고, model 은 (미정) 으로 둡니다. 네 초과 조건 중 어느 것도 걸 근거가 없으므로 rollout_verdict 는 전사 배포 가능으로 남지만, 리포트는 그 줄을 통과 묶음에 넣지 않고 견줄 실행 없음 절에 따로 세우며 hedge 에 파일럿을 아직 안 돌렸다는 사실을 적습니다. 12. latency_ms 가 비어 있으면 그 사실이 hedge 에 적혔는지 확인합니다. 13. summary 가 존댓말로 끝나는지 확인합니다. [평가 러너 · 2주차] 유스케이스 9건에 손으로 매긴 정답 판정을 붙여 자동 판정과 대조하고, 사유별 일치율과 어긋난 유스케이스의 목록을 냅니다. [수동 검증 · 사람이 봅니다] 1. 한도를 넘긴 유스케이스를 어떤 순서로 손볼지는 엔지니어링 리드가 리포트를 보고 정합니다. 2. 계약서에 적힌 처리량과 예산이 한도표에 옮겨 적은 값과 같은지는 계약 담당과 맞춰 갱신합니다.