큐빅
경력근거: 데모, benchmark, 실험 등 공개 가능한 기술적 증거를 제작
※ 실제 산출물이 아닌 AI 예측 시안입니다.
큐빅은 제품을 써서 만든 기술적 증거를 외부 커뮤니티에 발행하고 반론에 직접 답하는 일을 이 자리의 업무로 적었습니다. 공개 벤치마크에 들어오는 반론은 대개 수치 자체가 아니라 조건을 안 밝혔다는 지적이라, 발행 전에 무엇이 빠졌는지 알면 그 반론의 상당수가 미리 사라집니다. 이 필요는 자기 제품 수치를 공개 채널에서 방어해야 하는 자리에서만 생깁니다. 공고 업무는 콘텐츠 발행부터 시장 반응 구조화까지 걸쳐 있는데 1주 범위에서 고를 수 있는 것은 하나라 재현 조건 점검 축을 골랐습니다. 이 포트폴리오는 실행 기록과 문서를 규칙으로 대조해 빠진 것을 목록으로 만드는 기술을 보여줍니다. 합성 데이터나 프라이버시 공학 자체의 전문성은 주장하지 않습니다. 그 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
제품을 직접 써서 데모와 벤치마크, 실험 같은 공개 가능한 기술적 증거를 만드는 일이 첫 업무로 적혀 있습니다. 그 증거는 남이 다시 돌려 볼 수 있어야 증거가 됩니다.
공개 채널에서 들어오는 논의와 반론에 직접 대응하는 일이 업무입니다. 반론의 상당수가 조건을 밝히지 않았다는 지적이라 조건 관리가 곧 대응 준비입니다.
커뮤니티와 고객, 세일즈에서 반복되는 질문과 반론을 자료로 전환하는 일이 업무에 있습니다. 재현 조건 목록이 그 자료의 바탕이 됩니다.
벤치마크 실행 기록과 공개 문서에 적은 조건 목록을 대조해, 문서에 빠졌거나 실행마다 값이 달랐던 조건을 사유별로 나눠 출력하고 발행 전 점검 목록을 남기는 CLI입니다. 판정은 조건 항목의 문서 기재 여부와 실행 간 값 일치를 견주는 대조로 정합니다.
제품 벤치마크를 만들어 공개 채널에 올리는 담당자입니다. 발행하고 나면 어떤 하드웨어에서 몇 번 돌렸냐는 질문이 반드시 붙는데, 실행 로그를 다시 뒤져 답을 맞추다 보면 정작 실행마다 설정이 달랐다는 것을 그때 알게 됩니다.
실행 기록에 조건이 값으로 남아 있으면, 문서가 재현에 필요한 것을 다 적었는지는 사람이 기억에 기대지 않아도 대조로 갈라집니다.
벤치마크 실행 기록과 문서 조건 목록 파일을 인자로 받아 조건별 판정을 터미널에 출력하고 발행 전 점검 목록을 떨구는 CLI입니다. 벤치마크를 직접 돌리지 않고 남은 기록만 읽습니다.
같은 벤치마크의 여러 실행을 함께 읽어 조건 값이 실행마다 달랐던 항목을 골라 내는 구성입니다.
판정을 통과한 조건을 모아 외부 독자가 따라 할 수 있는 재현 안내문 초안을 마크다운으로 떨구는 구성입니다.
담당자가 실행 기록 50행과 문서 조건 목록을 넣어 빠진 조건이 사유별로 나뉜 판정표와 점검 목록이 나오는 것을 시연합니다.
결측·중복·미등록 조건이 섞인 입력 30종을 넣어도 출력 형식이 깨지지 않고, 판정하지 못한 조건은 사유가 붙어 남습니다.
값이 비어 있는 조건은 적힌 것으로 세지 않고 값 누락으로 따로 답니다. 확인하지 못한 것을 통과로 만들지 않습니다.
판정과 손으로 만든 정답표를 맞춰 사유별로 어긋난 건을 셉니다. 단, 기록과 정답을 모두 작성자가 만든 합성 기준이라 성능 측정이 아니라 데모 조건 동작입니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 더미데이터 자가채점이며, 실제 재현률은 큐빅의 실제 실행 기록과 실제 발행 문서가 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
작성자가 실행 기록과 공개 문서를 함께 만들었습니다. 빠진 조건을 잘 찾는 게 당연하니 조건 이름이 버전마다 다른 건과 값이 빈 건, 문서에 없는 조건을 기록에 함께 넣었습니다.
조건을 다 적었다고 해서 외부에서 같은 수치가 나온다고 단정할 수 없습니다. 하드웨어와 네트워크 상태는 문서로 옮길 수 없으므로, 판정은 밝힐 수 있는 것을 밝혔는지까지만 읽어야 합니다.
실제 도입하면 벤치마크 종류마다 밝혀야 할 조건이 다릅니다. 조건 목록을 기술 리더와 합의해 채우는 일이 도입 단계의 실제 과제입니다.
수치 자체가 공정한 비교인지의 판단은 이 도구의 범위 밖입니다. 조건이 적혔는지까지만 보므로, 비교 설계의 타당성은 사람이 봅니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
벤치마크 실행마다 남은 조건 값 기록입니다. 조건 이름이 도구 버전마다 대소문자·구분자로 흔들리고, 사전에 없는 신규 조건과 같은 기록 번호가 두 번 들어온 건, 값이 비어 있는 행을 일부러 섞었습니다.
| record_no | run_no | benchmark_name | condition_raw | condition_value | ran_at |
|---|---|---|---|---|---|
| RC-001 | RUN-A | 적재 처리량 | dataset_size | 1000000 | 2026-08-10 |
| RC-002 | RUN-A | 적재 처리량 | worker_count | 8 | 2026-08-10 |
| RC-003 | RUN-A | 적재 처리량 | Machine_Type | c5.4xlarge | 2026-08-10 |
| RC-004 | RUN-A | 적재 처리량 | repeat_count | 3 | 2026-08-10 |
| RC-005 | RUN-B | 적재 처리량 | dataset_size | 1000000 | 2026-08-12 |
아래 JSON Schema에 맞는 벤치마크 실행 조건 행을 더 만들어 주세요. {"type":"object","properties":{"record_no":{"type":"string"},"run_no":{"type":"string"},"benchmark_name":{"type":"string"},"condition_raw":{"type":"string"},"condition_value":{"type":["string","null"]},"ran_at":{"type":"string"}},"required":["record_no","run_no","benchmark_name","condition_raw","condition_value","ran_at"]} benchmark_name은 한글로 적고 한 run_no에 조건이 세 건 이상 붙도록 만들어 주세요. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 미매핑으로 condition_raw가 사전에 없어 condition_id가 null인 행, 둘째 표기흔들림으로 같은 조건을 machine_type과 Machine_Type과 machine type처럼 대소문자와 구분자만 다르게 적은 행, 셋째 중복으로 같은 record_no가 두 행에 있는 재적재 건, 넷째 결측으로 condition_value가 null인 행, 다섯째 같은 벤치마크의 두 실행에서 같은 조건의 값이 다른 행 쌍. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 ran_at을 빼거나 record_no에 숫자 타입을 넣어 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"record_no":{"type":"string"},"run_no":{"type":"string"},"benchmark_name":{"type":"string"},"condition_raw":{"type":"string"},"condition_value":{"type":["string","null"]},"ran_at":{"type":"string"}},"required":["record_no","run_no","benchmark_name","condition_raw","condition_value","ran_at"]}공개 문서에 실제로 적어 둔 조건 목록입니다. 재현에 필수인데 문서에 없는 항목과, 필수가 아닌 항목을 함께 두었습니다.
| condition_id | condition_label | is_required_for_repro | stated_in_doc | doc_section |
|---|---|---|---|---|
| dataset_size | 데이터셋 크기 | true | true | 실험 설정 |
| worker_count | 워커 수 | true | false | — |
| machine_type | 머신 종류 | true | true | 실험 설정 |
| repeat_count | 반복 횟수 | true | false | — |
| model_version | 모델 버전 | true | true | 모델 |
아래 JSON Schema에 맞는 공개 문서 조건 행을 더 만들어 주세요. {"type":"object","properties":{"condition_id":{"type":"string"},"condition_label":{"type":"string"},"is_required_for_repro":{"type":"boolean"},"stated_in_doc":{"type":"boolean"},"doc_section":{"type":["string","null"]}},"required":["condition_id","condition_label","is_required_for_repro","stated_in_doc","doc_section"]} condition_label과 doc_section은 한글로 적어 주세요. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 재현에 필수인데 stated_in_doc이 false인 항목, 둘째 필수가 아닌데 문서에는 적힌 항목, 셋째 stated_in_doc이 true인데 doc_section이 null인 항목, 넷째 실행 기록에는 나오지 않는 condition_id. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 is_required_for_repro에 문자열을 넣거나 condition_id를 빼서 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"condition_id":{"type":"string"},"condition_label":{"type":"string"},"is_required_for_repro":{"type":"boolean"},"stated_in_doc":{"type":"boolean"},"doc_section":{"type":["string","null"]}},"required":["condition_id","condition_label","is_required_for_repro","stated_in_doc","doc_section"]}| Python | 실행 기록과 문서 조건을 읽어 대조 판정을 돌리고 점검 목록을 만드는 본체입니다. |
| SQL | 실행 기록이 쌓인 표에서 벤치마크와 기간으로 잘라 내려받는 질의를 씁니다. |
| API | 제품 실행 결과를 받아 오는 입력 경로로 두되, 1주차에는 내려받은 기록만 읽습니다. |
| 데이터 파이프라인 | 실행마다 조건을 같은 모양으로 남기는 적재 흐름이며, 이 도구가 그 결과를 검사합니다. |
| observability | 무엇을 기록해야 재현이 서는지를 정하는 관점이며, 조건 목록이 그 최소 집합입니다. |
| notebook | 발행 전 점검 결과를 실행 결과와 나란히 놓고 확인하는 작업 공간입니다. |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 실행 간 값이 흔들린 조건을 짚습니다.
✓ pass → 편차 확인까지가 한 덩어리입니다. 더 키우려면 재현 안내문 초안을 만들어 냅니다.
벤치마크 조건 하나가 외부 재현을 지탱하는지의 판정 결과입니다. 못 지탱하면 왜인지를 근거와 함께 담습니다.
{"type":"object","properties":{"record_no":{"type":"string"},"verdict":{"type":"string","enum":["documented","required_but_not_stated","value_missing","value_varies_across_runs","section_missing","condition_unmapped","duplicate_record"]},"condition_id":{"type":["string","null"]},"observed_value":{"type":["string","null"]},"evidence":{"type":"array","items":{"type":"object","properties":{"field":{"type":"string"},"agg":{"type":["string","null"]},"value":{},"quote":{"type":["string","null"]}},"required":["field","value"]}},"next_action":{"type":"string"}},"required":["record_no","verdict","condition_id","observed_value","evidence","next_action"]}[
{
"record_no": "RC-001",
"verdict": "documented",
"condition_id": "dataset_size",
"observed_value": "1000000",
"evidence": [
{
"field": "condition_value",
"value": "1000000"
},
{
"field": "stated_in_doc",
"value": true
},
{
"field": "doc_section",
"value": "실험 설정"
}
],
"next_action": "실행 값과 문서 기재가 모두 있습니다. 그대로 발행합니다."
},
{
"record_no": "RC-011",
"verdict": "documented",
"condition_id": "model_version",
"observed_value": "v2.3",
"evidence": [
{
"field": "condition_value",
"value": "v2.3"
},
{
"field": "stated_in_doc",
"value": true
},
{
"field": "doc_section",
"value": "모델"
}
],
"next_action": "실행 값과 문서 기재가 모두 있습니다. 그대로 발행합니다."
},
{
"record_no": "RC-002",
"verdict": "required_but_not_stated",
"condition_id": "worker_count",
"observed_value": "8",
"evidence": [
{
"field": "is_required_for_repro",
"value": true
},
{
"field": "stated_in_doc",
"value": false
},
{
"field": "condition_value",
"value": "8"
}
],
"next_action": "재현에 필수인데 문서에 없습니다. 발행 전에 실험 설정 절에 추가합니다."
},
{
"record_no": "RC-008",
"verdict": "value_missing",
"condition_id": "repeat_count",
"observed_value": null,
"evidence": [
{
"field": "condition_value",
"value": null
},
{
"field": "is_required_for_repro",
"value": true
}
],
"next_action": "실행 기록에 값이 없습니다. 적힌 것으로 세지 않고 실행 로그를 다시 확인합니다."
},
{
"record_no": "RC-006",
"verdict": "value_varies_across_runs",
"condition_id": "worker_count",
"observed_value": "16",
"evidence": [
{
"field": "condition_value",
"value": "16"
},
{
"field": "condition_raw",
"agg": "count",
"value": 2
}
],
"next_action": "같은 벤치마크인데 실행마다 워커 수가 달랐습니다. 어느 실행을 대표로 쓸지 정하고 그 값만 밝힙니다."
},
{
"record_no": "RC-009",
"verdict": "condition_unmapped",
"condition_id": null,
"observed_value": "true",
"evidence": [
{
"field": "condition_raw",
"value": "cache_warmup",
"quote": "cache_warmup"
}
],
"next_action": "조건 사전에 없는 항목입니다. 재현에 영향을 주는지 판단해 목록에 넣을지 정합니다."
},
{
"record_no": "RC-006",
"verdict": "duplicate_record",
"condition_id": "worker_count",
"observed_value": "16",
"evidence": [
{
"field": "record_no",
"agg": "count",
"value": 2
}
],
"next_action": "같은 기록 번호가 두 번 적재됐습니다. 앞 건으로만 판정하고 뒤 건을 기록에서 뺍니다."
}
][자동 검증 · 1주차] 1. verdict가 enum 일곱 값 안에 있는지 확인합니다. 2. record_no·verdict·condition_id·observed_value·evidence·next_action이 모두 있는지 확인합니다. 3. stated_in_doc이 true이면 doc_section이 있는지 확인합니다. 4. condition_value가 null이면 verdict가 value_missing인지 확인합니다. 5. evidence의 field가 두 입력 표의 컬럼에 실재하는지 확인합니다. 6. evidence의 quote가 그 행 condition_raw의 일부인지 확인합니다. 7. next_action이 존댓말로 끝나는지 확인합니다. [판정 규칙] 1. 조건 이름은 대소문자와 띄어쓰기, 구분자를 없애 소문자로 모은 뒤 published_conditions의 condition_id와 맞춥니다. 맞는 것이 없으면 미매핑으로 남기고 그 행은 나머지 판정에서 뺍니다. 2. 같은 행 번호가 두 번 들어오면 앞 건만 남기고 뒤 건은 적재 단계에서 사유와 함께 뺍니다. [수동 검증] 1. 사전에 없는 조건이 재현에 영향을 주는지 기술 리더가 판단해 목록에 넣을지 정합니다. 2. RC-003·RC-007처럼 조건 표기가 흔들렸지만 사전으로 맞춰진 기록은 미매핑 사유를 달지 않는 것이 맞는지 확인합니다. [평가 러너 · 2주차] 1. 같은 벤치마크의 여러 실행에서 값이 흔들린 조건이 몇 건인지 세고 어느 조건이 자주 흔들리는지 나눕니다. 2. 기록과 정답을 작성자가 만든 합성 기준이라 이 수치는 성능 측정이 아니라 데모 조건 동작입니다.
근거: 데모, benchmark, 실험 등 공개 가능한 기술적 증거를 제작