Neon
경력근거: own our customer-facing documentation, and build out new features
※ 실제 산출물이 아닌 AI 예측 시안입니다.
Neon은 게임 퍼블리셔가 자기 웹샵을 붙여 쓰는 플랫폼이고, 이 자리는 개발자 온보딩과 고객 대면 문서를 직접 소유합니다. 퍼블리셔마다 붙이는 시점이 달라서 어떤 파트너는 반년 전 문서를 보고 연동하는데, 그 사이 응답 필드가 바뀌면 문의가 문서 문제인지 연동 문제인지부터 가려야 합니다. 이 부담은 외부 개발자가 문서만 보고 붙이는 제품에서만 생깁니다. 공고 업무는 온보딩부터 팀 성장까지 걸쳐 있는데 1주 범위에서 고를 수 있는 것은 하나라 문서 대조 축을 골랐습니다. 결제 처리 자체는 사업자 계정이 있어야 열리는 기능이라 제품 골조에서 뺐습니다. 이 포트폴리오는 명세와 실물을 규칙으로 대조하고 갱신할 것을 목록으로 만드는 기술을 보여줍니다. 게임 결제 정산이나 앱스토어 정책 자체의 전문성은 주장하지 않습니다. 그 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
개발자 온보딩을 만들고 고객 대면 문서를 소유하는 일이 이 자리의 업무로 적혀 있습니다. 문서가 실제 응답과 어긋나면 온보딩이 그 자리에서 멈춥니다.
복잡한 기술 제품의 API 문서를 쓰고 유지한 경험을 자격요건으로 못박습니다. 문서와 응답을 기계로 대조하는 일이 그 유지의 실제 방법입니다.
특정 고객 요청을 처리하려고 풀스택 제품 개발로 넘나드는 일이 업무에 있습니다. 어긋난 필드 목록이 그 요청의 근거 자료가 됩니다.
API 문서에 적힌 응답 필드 명세와 실제 연동 응답 기록을 대조해, 문서에 없는 필드와 문서에만 있는 필드, 타입이 어긋난 필드를 사유별로 나눠 출력하고 문서 갱신 목록을 남기는 CLI입니다. 판정은 필드 이름과 타입, 필수 여부를 명세와 견주는 대조로 정합니다.
게임 퍼블리셔가 웹샵 연동을 붙이도록 돕는 파트너 엔지니어입니다. 문서대로 붙였는데 안 된다는 문의가 오면 응답 예시를 받아 문서와 한 줄씩 맞춰 보는데, 어느 필드가 언제 바뀌었는지 기억에 의존해 찾느라 같은 문의가 반복됩니다.
문서의 필드 명세가 표로 뽑혀 있으면, 문서가 실제 응답과 어긋난 지점은 사람이 눈으로 맞춰 보지 않아도 대조로 갈라집니다.
문서 필드 명세와 응답 기록 파일을 인자로 받아 필드별 판정을 터미널에 출력하고 문서 갱신 목록을 떨구는 CLI입니다. 실제 API를 호출하지 않고 받아 둔 응답 기록만 읽습니다.
응답 기록을 버전별로 나눠 어느 버전부터 필드가 사라지거나 추가됐는지 표시해, 파트너에게 안내할 시점을 정하게 하는 구성입니다.
문서 명세를 파일로 분리해 제품별 엔드포인트 묶음을 같은 판정으로 돌리고, 파이프라인에서 문서를 고칠 때마다 자동 실행합니다.
담당자가 문서 명세 40행과 응답 기록을 넣어 어긋난 필드가 사유별로 나뉜 판정표와 문서 갱신 목록이 나오는 것을 시연합니다.
결측·중복·미등록 엔드포인트가 섞인 입력 30종을 넣어도 출력 형식이 깨지지 않고, 판정하지 못한 필드는 사유가 붙어 남습니다.
응답 기록이 없는 엔드포인트는 문서가 맞다고 세지 않고 관측 없음으로 따로 답니다. 확인하지 못한 것을 통과로 만들지 않습니다.
판정과 손으로 만든 정답표를 맞춰 사유별로 어긋난 건을 셉니다. 단, 명세와 정답을 모두 작성자가 만든 합성 기준이라 성능 측정이 아니라 데모 조건 동작입니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 더미데이터 자가채점이며, 실제 대조 정확도는 Neon의 실제 문서와 실제 파트너 응답 기록이 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
일치율이 높게 나오는 것만으로는 아무것도 말하지 못합니다. 엔드포인트 표기가 문서 판마다 흔들린 건과 타입이 빈 명세, 관측에 없는 엔드포인트가 섞여 있어야 대조에 뜻이 생깁니다.
문서에 없는 필드라고 해서 문서가 틀렸다고 단정할 수 없습니다. 내부 전용 필드를 일부러 안 적었을 수 있으므로, 판정은 둘이 다르다는 사실까지만 읽어야 합니다.
실제 도입하면 파트너마다 보는 문서 버전이 다릅니다. 어느 버전을 기준으로 삼을지 정하는 일이 도입 단계의 실제 과제입니다.
결제 처리와 정산은 사업자 계정이 있어야 열리는 기능이라 이 포트폴리오에 넣지 않았습니다. 그 층은 제품이 맡고, 여기서는 연동 문서의 정확성만 다룹니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
API 문서에 적힌 응답 필드 명세입니다. 엔드포인트 표기가 문서 판마다 대소문자·구분자로 흔들리고, 실제로는 없는 엔드포인트와 같은 명세 번호가 두 번 들어온 건, 타입이 비어 있는 행을 일부러 섞었습니다.
| spec_no | endpoint_raw | field_path | field_type | is_required | doc_version |
|---|---|---|---|---|---|
| SP-001 | GET /v1/orders | order_id | string | true | 2026-02 |
| SP-002 | GET /v1/orders | amount | number | true | 2026-02 |
| SP-003 | get /v1/orders | currency | string | true | 2026-02 |
| SP-004 | GET /v1/orders | coupon_code | string | false | 2026-02 |
| SP-005 | GET /V1/ORDERS | buyer.region | string | false | 2026-02 |
아래 JSON Schema에 맞는 문서 필드 명세 행을 더 만들어 주세요. {"type":"object","properties":{"spec_no":{"type":"string"},"endpoint_raw":{"type":"string"},"field_path":{"type":"string"},"field_type":{"type":["string","null"]},"is_required":{"type":"boolean"},"doc_version":{"type":"string"}},"required":["spec_no","endpoint_raw","field_path","field_type","is_required","doc_version"]} 한 endpoint_id에 필드가 두 건 이상 붙도록 만들어 주세요. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 미매핑으로 endpoint_raw가 실제 엔드포인트 목록에 없어 endpoint_id가 null인 행, 둘째 표기흔들림으로 같은 엔드포인트를 GET /v1/orders와 get /v1/orders와 GET /V1/ORDERS처럼 대소문자만 다르게 적은 행, 셋째 중복으로 같은 spec_no가 두 행에 있는 재등록 건, 넷째 결측으로 field_type이 null인 행, 다섯째 경계극단으로 중첩 깊이가 세 단계인 field_path. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 is_required에 문자열을 넣거나 field_path를 빼서 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"spec_no":{"type":"string"},"endpoint_raw":{"type":"string"},"field_path":{"type":"string"},"field_type":{"type":["string","null"]},"is_required":{"type":"boolean"},"doc_version":{"type":"string"}},"required":["spec_no","endpoint_raw","field_path","field_type","is_required","doc_version"]}파트너 연동에서 실제로 관측된 응답 필드 기록입니다. 문서에 없는 신규 필드와 문서에는 있는데 응답에 없는 필드를 만들어 두었습니다.
| obs_no | endpoint_id | field_path | observed_type | api_version | sample_count |
|---|---|---|---|---|---|
| OB-001 | get_orders | order_id | string | 2026-08 | 1,200 |
| OB-002 | get_orders | amount | string | 2026-08 | 1,200 |
| OB-003 | get_orders | currency | string | 2026-08 | 1,200 |
| OB-004 | get_orders | buyer.region | string | 2026-08 | 1,180 |
| OB-005 | get_orders | settlement_batch_id | string | 2026-08 | 1,200 |
아래 JSON Schema에 맞는 관측 응답 필드 행을 더 만들어 주세요. {"type":"object","properties":{"obs_no":{"type":"string"},"endpoint_id":{"type":"string"},"field_path":{"type":"string"},"observed_type":{"type":"string"},"api_version":{"type":"string"},"sample_count":{"type":"integer"}},"required":["obs_no","endpoint_id","field_path","observed_type","api_version","sample_count"]} 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 문서 명세에는 없는데 응답에만 있는 신규 field_path, 둘째 문서에는 있는데 응답에 아예 없는 field_path 조합, 셋째 같은 field_path인데 observed_type이 문서와 다른 행, 넷째 경계극단으로 sample_count가 1인 거의 안 나오는 필드. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 sample_count에 문자열을 넣거나 endpoint_id를 빼서 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"obs_no":{"type":"string"},"endpoint_id":{"type":"string"},"field_path":{"type":"string"},"observed_type":{"type":"string"},"api_version":{"type":"string"},"sample_count":{"type":"integer"}},"required":["obs_no","endpoint_id","field_path","observed_type","api_version","sample_count"]}| Python | 명세와 응답 기록을 읽어 필드 대조 판정을 돌리고 갱신 목록을 만드는 본체입니다. |
| API | 판정 대상 자체입니다. 엔드포인트별 응답 필드가 한 행으로 들어옵니다. |
| JSON | 응답 기록의 형식이며, 중첩 구조를 평탄화해 필드 경로로 다룹니다. |
| 풀스택 | 고객 요청으로 필드를 더할 때 문서와 응답을 함께 고치는 흐름을 전제로 둡니다. |
| 문서화 | 이 도구의 산출물이 곧 문서 갱신 목록이라, 문서를 유지하는 작업 자체가 자동화 대상이 됩니다. |
| CI | 문서를 고칠 때마다 이 판정을 돌려 어긋난 채로 배포되는 것을 막습니다. |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 어느 버전부터 어긋났는지 짚습니다.
✓ pass → 버전 추적까지가 한 덩어리입니다. 더 키우려면 명세를 제품별로 분리하고 문서 수정 때마다 자동 실행합니다.
문서 필드 하나가 실제 응답과 맞는지의 판정 결과입니다. 어긋났다면 어떻게 어긋났는지를 근거와 함께 담습니다.
{"type":"object","properties":{"spec_no":{"type":["string","null"]},"obs_no":{"type":["string","null"]},"verdict":{"type":"string","enum":["in_sync","type_mismatch","missing_in_response","undocumented_field","type_unspecified","endpoint_unmapped","duplicate_spec"]},"doc_type":{"type":["string","null"]},"observed_type":{"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":["spec_no","obs_no","verdict","doc_type","observed_type","evidence","next_action"]}[
{
"spec_no": "SP-001",
"verdict": "in_sync",
"doc_type": "string",
"observed_type": "string",
"evidence": [
{
"field": "field_path",
"value": "order_id"
},
{
"field": "field_type",
"value": "string"
},
{
"field": "observed_type",
"value": "string"
}
],
"next_action": "문서와 응답이 같습니다. 그대로 둡니다.",
"obs_no": null
},
{
"spec_no": "SP-007",
"verdict": "in_sync",
"doc_type": "number",
"observed_type": "number",
"evidence": [
{
"field": "field_path",
"value": "price"
},
{
"field": "field_type",
"value": "number"
},
{
"field": "observed_type",
"value": "number"
}
],
"next_action": "문서와 응답이 같습니다. 그대로 둡니다.",
"obs_no": null
},
{
"spec_no": "SP-002",
"verdict": "type_mismatch",
"doc_type": "number",
"observed_type": "string",
"evidence": [
{
"field": "field_type",
"value": "number"
},
{
"field": "observed_type",
"value": "string"
},
{
"field": "sample_count",
"value": 1200
}
],
"next_action": "문서는 숫자인데 응답은 문자열입니다. 파트너 파싱이 깨지므로 문서와 응답 중 어느 쪽을 고칠지 먼저 정합니다.",
"obs_no": null
},
{
"spec_no": "SP-004",
"verdict": "missing_in_response",
"doc_type": "string",
"observed_type": null,
"evidence": [
{
"field": "field_path",
"value": "coupon_code"
},
{
"field": "is_required",
"value": false
}
],
"next_action": "문서에는 있는데 응답에 한 번도 안 나왔습니다. 선택 필드라 삭제할지 문서에 조건을 적을지 정합니다.",
"obs_no": null
},
{
"spec_no": null,
"verdict": "undocumented_field",
"doc_type": null,
"observed_type": "string",
"evidence": [
{
"field": "field_path",
"value": "settlement_batch_id"
},
{
"field": "sample_count",
"value": 1200
}
],
"next_action": "응답에는 늘 나오는데 문서에 명세가 없습니다. 공개할 필드인지 확인한 뒤 문서에 추가합니다.",
"obs_no": "OB-005"
},
{
"spec_no": "SP-008",
"verdict": "type_unspecified",
"doc_type": null,
"observed_type": "number",
"evidence": [
{
"field": "field_type",
"value": null
},
{
"field": "observed_type",
"value": "number"
}
],
"next_action": "문서에 타입이 비어 있어 대조하지 못했습니다. 맞다고 세지 않고 문서에 타입을 채웁니다.",
"obs_no": null
},
{
"spec_no": "SP-009",
"verdict": "endpoint_unmapped",
"doc_type": "string",
"observed_type": null,
"evidence": [
{
"field": "endpoint_raw",
"value": "GET /v1/webshops",
"quote": "/v1/webshops"
}
],
"next_action": "실제 엔드포인트 목록에 없습니다. 폐기된 문서인지 확인한 뒤 문서에서 내립니다.",
"obs_no": null
},
{
"spec_no": "SP-002",
"verdict": "duplicate_spec",
"doc_type": "number",
"observed_type": "string",
"evidence": [
{
"field": "spec_no",
"agg": "count",
"value": 2
}
],
"next_action": "같은 명세 번호가 두 번 등록됐습니다. 앞 건으로만 판정하고 뒤 건을 문서에서 뺍니다.",
"obs_no": null
}
][자동 검증 · 1주차] 1. verdict가 enum 일곱 값 안에 있는지 확인합니다. 2. spec_no·obs_no·verdict·doc_type·observed_type·evidence·next_action 칸이 모두 있고, 둘 중 하나 이상이 채워져 있는지 확인합니다. 3. sample_count가 0보다 큰지 확인합니다. 4. field_type이 null이면 verdict가 type_unspecified인지 확인합니다. 5. evidence의 field가 두 입력 표의 컬럼에 실재하는지 확인합니다. 6. evidence의 quote가 그 행 endpoint_raw의 일부인지 확인합니다. 7. next_action이 존댓말로 끝나는지 확인합니다. [판정 규칙] 0. 판정 단위는 엔드포인트와 필드 경로의 짝입니다. 문서에만 있으면 obs_no를 비우고, 응답에만 있으면 spec_no를 비웁니다. 1. 엔드포인트 표기은 대소문자와 띄어쓰기, 구분자를 없애 소문자로 모은 뒤 observed_responses의 endpoint_id와 맞춥니다. 맞는 것이 없으면 미매핑으로 남기고 그 행은 나머지 판정에서 뺍니다. 2. 같은 행 번호가 두 번 들어오면 앞 건만 남기고 뒤 건은 적재 단계에서 사유와 함께 뺍니다. [수동 검증] 1. 문서에 없는 필드가 공개해도 되는 값인지 제품 담당자가 확인합니다. 2. SP-003·SP-005처럼 엔드포인트 표기가 흔들렸지만 표준으로 맞춰진 행은 미매핑 사유를 달지 않는 것이 맞는지 확인합니다. [평가 러너 · 2주차] 1. 버전별로 나눠 필드가 사라지거나 추가된 시점이 하나로 특정되는지 셉니다. 2. 명세와 정답을 작성자가 만든 합성 기준이라 이 수치는 성능 측정이 아니라 데모 조건 동작입니다.
근거: own our customer-facing documentation, and build out new features