아이지에이웍스
경력근거: 고객의 1st-party Data와 SCI를 결합하여 PoC 및 Prototype을 설계·구현합니다.
공고가 이 자리의 일을 '고객의 1st-party Data와 SCI를 결합하여 PoC 및 Prototype을 설계·구현합니다' 로 적었고, 다른 업무 줄은 '고객의 개발/데이터/사업 조직과 협업하며 Integration, Data Quality 및 기술적 이슈를 해결합니다' 입니다. SCI 의 예측은 회사 소개가 밝힌 '소비자 행동 Foundation Model - WorksFM' 이 앱 사용과 결제 흐름을 읽어 내는 것이라, 고객사 이벤트가 규격대로 들어오지 않으면 결합 자체가 성립하지 않습니다. 이 포트폴리오는 두 규격표를 이름으로 맞추고 버전과 값 형식을 수치로 견주는 기술을 보여주며, 모바일 어트리뷰션 실무나 소비자 행동 모델링 전문성은 주장하지 않습니다. SDK 가 올린 이벤트를 규격에 맞추는 자리까지가 제가 다뤄 본 범위이고, 어트리뷰션 정산이나 WorksFM 학습 쪽은 그렇지 않습니다.
주요 업무 두 번째가 '고객의 1st-party Data와 SCI를 결합하여 PoC 및 Prototype을 설계·구현합니다' 입니다. 결합의 첫 칸은 고객사 앱이 이미 쌓아 둔 이벤트가 WorksFM 이 읽을 모양인지 정하는 일입니다.
'고객의 개발/데이터/사업 조직과 협업하며 Integration, Data Quality 및 기술적 이슈를 해결합니다' 가 주요 업무에 있습니다. 어느 이벤트가 왜 규격과 어긋나는지를 줄 단위로 내주면 그 대화가 화면 캡처가 아니라 목록 위에서 돕니다.
'고객 현장에서 반복적으로 발견되는 문제와 해결 방식을 재사용 가능한 Module, Workflow, Product 기능으로 발전시킵니다' 가 업무이고, 회사 소개는 SCI 의 핵심이 '소비자 행동 Foundation Model - WorksFM' 이라고 밝힙니다. 앱마다 다르게 심긴 이벤트를 규격으로 맞춰 보는 규칙은 고객사가 바뀌어도 그대로 다시 씁니다.
고객사 앱에서 뽑아 온 이벤트 수집 내역을 SCI 이벤트 규격표와 이벤트 이름·파라미터 이름으로 맞춰, 짝마다 다섯 사유 중 하나를 정합니다. SDK 버전은 점으로 끊어 앞자리부터 수치로 견주므로 10.0.1 이 8.0.0 보다 낮게 잡히는 일이 없고, 샘플 값은 규격이 적은 형식대로 읽어 봐 통화 표시가 붙은 금액이나 늘 비어 있는 수량을 가려냅니다. 규격에 아예 없는 이벤트와 필수인데 안 올라오는 파라미터는 따로 사유를 붙입니다. 표준출력은 이벤트 이름 아래 파라미터를 들여쓴 트리로 서고, 같은 실행이 고객사 앱 개발자에게 보낼 수정 요청 Markdown 을 남깁니다.
고객사에 들어가 SCI 를 붙이는 아이지에이웍스 FDE 엔지니어
붙였는데 예측이 안 뜨는 일이 잦은 이유는 모델이 약해서가 아니라, 고객사 앱이 예전에 심어 둔 이벤트 이름과 SCI 규격이 요구하는 이름이 서로 다르고 그 차이를 아무도 줄 단위로 본 적이 없기 때문입니다. 수집 내역과 규격표를 이름으로 맞춰 보면 연동 첫날에 고칠 목록이 나옵니다.
고객사 이벤트 수집 내역과 SCI 규격표를 넣으면 이벤트·파라미터 짝마다 다섯 사유 중 하나를 정하고, 버전 수치와 규격이 요구하는 형식을 달아 이벤트별 트리 출력과 수정 요청 Markdown 을 내는 CLI 가 도는 완결품입니다. 수집 내역은 고객사 분석 도구에서 내려받은 표로 두고, SDK 를 직접 붙여 수집하는 일은 다루지 않습니다.
여러 앱 실행을 합쳐 이벤트 이름마다 걸린 횟수를 세고, 두 앱 이상에서 같은 사유로 걸린 이벤트를 연동 가이드 손질 후보로 냅니다.
수정 요청을 반영한 수집 내역을 다시 넣어 직전 실행과 사유별로 견주고, 규격과 맞은 이벤트만으로 WorksFM 입력 표를 만들어 어느 사용자까지 예측이 도는지 셉니다.
FDE 엔지니어가 앱 식별자 하나로 명령을 걸면 이벤트별 트리가 서고 파라미터마다 사유가 붙는 장면을 시연합니다.
앱 두 곳에서 뽑은 이벤트·파라미터 짝 80건에 어느 사유가 맞는지 먼저 손으로 적어 두고 도구가 낸 사유와 맞춰 봅니다. 수집 내역도 규격표도 제가 지어낸 합성 기준이라, 이 숫자는 데모가 어느 조건까지 도는지를 말할 뿐 성능이 아닙니다.
샘플 값이 비어 있는 파라미터와 통화 표시가 붙은 금액, 자리 수가 둘뿐인 버전 문자열이 섞인 입력 30종을 걸어 트리 출력이 끝까지 서고 이벤트별 건수가 어긋나지 않는지 봅니다.
규격표의 최소 SDK 버전을 한 단계 올려 두고, 어제까지 통과하던 이벤트가 어디서부터 걸리기 시작하는지 회귀로 봅니다.
이 숫자들은 제가 지은 수집 내역을 제 규칙으로 채점한 자가채점입니다. 연동이 실제로 몇 종에서 살아났는지는 아이지에이웍스가 SCI 를 붙인 고객사의 실 이벤트 로그를 걸어야 나옵니다. 그 로그를 같은 컬럼의 파일로 내려받으면 여기 만든 명령에 그대로 걸립니다.
수집 내역도 규격표도 제가 지어냈으니, 짝 80건 일치율은 제가 심어 둔 어긋남을 제 규칙이 도로 찾아냈다는 말입니다. 고객사 앱에서 올라온 이벤트 로그를 한 번도 본 적 없는 상태의 숫자라는 것을 면접에서 먼저 밝힙니다.
더미가 깨끗하면 형식 판독기가 늘 맞으므로, 값이 늘 비어 있는 파라미터와 통화 표시가 붙은 금액, 규격에 자리가 없는 이벤트를 일부러 섞어 두었습니다.
이 포트폴리오는 두 규격표를 이름으로 맞추고 버전과 값 형식을 수치로 견주는 기술을 보여주며, 모바일 어트리뷰션 실무나 소비자 행동 모델링 전문성은 주장하지 않습니다. 판정을 정하는 것은 이름 대조와 버전 계산이고, 클로드가 맡는 자리는 앱 개발자에게 보낼 요청 한 줄입니다.
샘플 값 하나로 형식을 정하면 그 하나만 예외였던 경우를 놓칩니다. 실제 도입에서는 이벤트마다 값을 여러 개 뽑아 비율로 보는 편이 맞고, 여기서는 줄마다 대표 값 하나만 두었습니다.
이 도구가 어긋남이라고 부른 것이 곧 고객사 앱의 잘못은 아닙니다. 고객사 사업에 필요해 따로 심은 이벤트도 있어, SCI 규격에 자리를 만들지 앱을 고칠지는 SCI 조직과 고객사가 정합니다.
실 이벤트 로그에는 광고 식별자처럼 개인을 가리키는 값이 섞입니다. 그래서 도입 첫 단계는 판정을 고객사 망 안에서 돌리고 어긋난 이벤트 목록만 밖으로 내보내는 구성을 잡는 일입니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 앱이 지난 이레 동안 실제로 올린 이벤트 수집 내역입니다. 줄 번호와 앱 식별자, 이벤트 이름, 파라미터 이름, 샘플 값, SDK 버전, 수집일을 한 줄에 둡니다. 금액은 통화 표시를 붙인 문구로 올라오기도 하고 '58000' 처럼 숫자로 올라오기도 해서 규격의 number 자리와 그대로는 견줄 수 없습니다. 파라미터가 아예 없는 이벤트 줄과 값이 늘 비어 있는 파라미터 줄을 일부러 섞어 사유가 갈리게 둡니다.
| collect_no | app_id | event_name | param_key | sample_value | sdk_ver | collected_at |
|---|---|---|---|---|---|---|
| CE-001 | kr.co.bank.smart | purchase | amount | 12,000원 | 8.1.0 | 2026-09-15 |
| CE-002 | kr.co.bank.smart | purchase | currency | KRW | 8.1.0 | 2026-09-15 |
| CE-003 | kr.co.bank.smart | purchase | order_id | ORD-99231 | 8.1.0 | 2026-09-15 |
| CE-004 | kr.co.bank.smart | sign_up | referrer | kakao | 8.1.0 | 2026-09-15 |
| CE-005 | kr.co.bank.smart | coupon_pressed | — | — | 8.1.0 | 2026-09-16 |
아래 JSON Schema 를 그대로 만족하는 이벤트 수집 줄을 300개 더 만들어 주세요. 앱을 다섯쯤 두고 앱마다 6~12종 이벤트를 올리게 씁니다. 이벤트 이름은 purchase·sign_up·view_item·app_open·add_to_cart 같은 표준 이름과 고객사가 따로 심은 이름을 섞고, 금액 파라미터는 '12,000원'·'12000'·'12,000 KRW' 처럼 표기를 섞습니다. SDK 버전은 7.0.0 부터 10.2.1 까지 흩뿌리고 몇 줄은 '8.1' 처럼 자리를 둘만 적습니다. 스무 줄에 한 번꼴로 샘플 값을 비우고, 파라미터 이름이 아예 없는 줄도 몇 개 넣으세요. 판정 결과나 사유는 넣지 마세요.
{"type": "object", "properties": {"collect_no": {"type": "string"}, "app_id": {"type": "string"}, "event_name": {"type": "string"}, "param_key": {"type": ["string", "null"]}, "sample_value": {"type": ["string", "null"]}, "sdk_ver": {"type": "string"}, "collected_at": {"type": "string"}}, "required": ["collect_no", "app_id", "event_name", "param_key", "sample_value", "sdk_ver", "collected_at"]}{"type": "object", "properties": {"collect_no": {"type": "string"}, "app_id": {"type": "string"}, "event_name": {"type": "string"}, "param_key": {"type": ["string", "null"]}, "sample_value": {"type": ["string", "null"]}, "sdk_ver": {"type": "string"}, "collected_at": {"type": "string"}}, "required": ["collect_no", "app_id", "event_name", "param_key", "sample_value", "sdk_ver", "collected_at"]}SCI 가 고객사에 건네는 이벤트 규격표입니다. 규격 줄 번호와 이벤트 이름, 파라미터 이름, 값 형식, 필수 여부, 최소 SDK 버전을 한 줄에 둡니다. 이 표는 SCI 조직이 배포하는 연동 가이드에서 받은 것이고 이 도구가 만들지 않습니다. 최소 SDK 버전은 이벤트마다 달라, 앱 하나 안에서도 어떤 이벤트는 되고 어떤 이벤트는 안 되는 상황이 나옵니다.
| spec_no | event_name | param_key | value_type | is_required | min_sdk_ver |
|---|---|---|---|---|---|
| ES-001 | purchase | amount | number | true | 8.0.0 |
| ES-002 | purchase | currency | string | true | 8.0.0 |
| ES-003 | purchase | order_id | string | true | 8.0.0 |
| ES-004 | sign_up | method | string | true | 7.5.0 |
| ES-005 | sign_up | referrer | string | false | 7.5.0 |
아래 JSON Schema 를 그대로 만족하는 규격 줄을 80개 더 만들어 주세요. 이벤트를 스무 종쯤 두고 이벤트마다 2~6개 파라미터를 답니다. 값 형식은 string·number·integer·boolean·timestamp 중에서 고르고, 필수 여부는 셋에 하나쯤만 참으로 둡니다. 최소 SDK 버전은 7.0.0·7.5.0·8.0.0·9.0.0 중에서 고르되 이벤트마다 다르게 둡니다. 파라미터 이름은 모바일 분석에서 실제로 쓰는 영문 이름으로 씁니다. 판정 결과는 넣지 마세요.
{"type": "object", "properties": {"spec_no": {"type": "string"}, "event_name": {"type": "string"}, "param_key": {"type": "string"}, "value_type": {"type": "string", "enum": ["string", "number", "integer", "boolean", "timestamp"]}, "is_required": {"type": "boolean"}, "min_sdk_ver": {"type": "string"}}, "required": ["spec_no", "event_name", "param_key", "value_type", "is_required", "min_sdk_ver"]}{"type": "object", "properties": {"spec_no": {"type": "string"}, "event_name": {"type": "string"}, "param_key": {"type": "string"}, "value_type": {"type": "string", "enum": ["string", "number", "integer", "boolean", "timestamp"]}, "is_required": {"type": "boolean"}, "min_sdk_ver": {"type": "string"}}, "required": ["spec_no", "event_name", "param_key", "value_type", "is_required", "min_sdk_ver"]}| Python | SDK 버전을 자리별 수치로 견주고 값을 형식대로 읽어 다섯 사유로 정하는 규칙 엔진과 CLI 를 맡습니다. |
| TypeScript | 고객사 앱 개발자가 수정 요청을 열어 보는 문서 생성기의 타입을 판정 결과 규격과 한 벌로 맞춥니다. |
| JavaScript | 고객사 웹 SDK 에서 올라온 이벤트 이름이 앱 쪽과 다른 현장을 위해 이름 대응표를 별도 파일로 받습니다. |
| Java | 고객사 안드로이드 팀이 결과를 그대로 읽도록 출력 규격을 JSON 한 벌로 고정합니다. |
| Kotlin | 안드로이드 SDK 버전 문자열이 스냅숏 표기로 올라오는 현장을 대비해 버전 읽기 규칙을 따로 둡니다. |
| LLM | 어긋난 이벤트를 고객사 앱 개발자가 어느 화면의 어느 호출을 고쳐야 하는지 아는 수정 요청 문장으로 씁니다. |
| RAG | 3주차 수정 요청 문서에 SCI 연동 가이드의 해당 절을 붙이려고 가이드 문서 단위 색인을 둡니다. |
| ETL | 고객사 분석 도구에서 내려받은 수집 내역을 판정이 읽는 줄 모양으로 옮기는 적재 작업을 맡습니다. |
✗ fail → 규격에 없는 이벤트가 절반을 넘으면 이름 대응표를 먼저 고객사와 맞춥니다.
✓ pass → 이름이 대체로 맞으면 2주차 집계로 넘어갑니다.
✗ fail → 한 앱에서만 나온 이벤트라면 가이드를 손보자고 하지 않고 그 앱 문제로 남깁니다.
✓ pass → 3주차 재실행 비교와 입력 표 만들기로 넘어갑니다.
고객사 앱의 이벤트 하나, 파라미터 하나가 SCI 규격대로 들어오는지 정합니다. 다섯 사유 중 하나를 싣고 버전 수치와 규격이 요구하는 형식, 대조한 규격 줄 번호를 함께 담아 트리 출력과 수정 요청 문서가 그대로 읽습니다.
{"type":"object","properties":{"verdict_no":{"type":"string"},"app_id":{"type":"string"},"event_name":{"type":"string"},"param_key":{"type":["string","null"]},"collect_no":{"type":["string","null"]},"spec_no":{"type":["string","null"]},"verdict":{"type":"string","enum":["규격과 맞음","필수 파라미터가 빠짐","값 형식이 다름","규격에 없는 이벤트","SDK 버전이 낮음"]},"expected_type":{"type":["string","null"]},"sdk_rank":{"type":["integer","null"],"description":"client_events.sdk_ver 를 점으로 끊어 앞자리부터 major×1000000 + minor×1000 + patch 로 더한 값입니다. 세 자리로 안 읽히면 null 입니다"},"min_sdk_rank":{"type":["integer","null"],"description":"sci_event_spec.min_sdk_ver 를 같은 식으로 더한 값입니다. 규격에 없는 이벤트이면 null 입니다"},"evidence":{"type":"array","items":{"type":"object","properties":{"table":{"type":"string","enum":["client_events","sci_event_spec"]},"field":{"type":"string"},"agg":{"type":["string","null"]},"value":{}},"required":["table","field","value"]}},"summary":{"type":"string"},"hedge":{"type":["string","null"]}},"required":["verdict_no","app_id","event_name","verdict","evidence","summary"]}[
{
"verdict_no": "EV-001",
"app_id": "kr.co.bank.smart",
"event_name": "purchase",
"param_key": "amount",
"collect_no": "CE-001",
"spec_no": "ES-001",
"verdict": "값 형식이 다름",
"expected_type": "number",
"sdk_rank": 8001000,
"min_sdk_rank": 8000000,
"evidence": [
{
"table": "client_events",
"field": "sample_value",
"agg": null,
"value": "12,000원"
},
{
"table": "sci_event_spec",
"field": "value_type",
"agg": null,
"value": "number"
}
],
"summary": "결제 금액을 '12,000원' 처럼 통화 표시를 붙여 보내 수치로 안 읽힙니다.",
"hedge": null
},
{
"verdict_no": "EV-002",
"app_id": "kr.co.bank.smart",
"event_name": "sign_up",
"param_key": "method",
"collect_no": null,
"spec_no": "ES-004",
"verdict": "필수 파라미터가 빠짐",
"expected_type": "string",
"sdk_rank": 8001000,
"min_sdk_rank": 7005000,
"evidence": [
{
"table": "sci_event_spec",
"field": "is_required",
"agg": null,
"value": true
},
{
"table": "client_events",
"field": "param_key",
"agg": "count",
"value": 1
}
],
"summary": "가입 이벤트에서 파라미터가 referrer 하나만 올라와 필수인 method 가 없습니다.",
"hedge": null
},
{
"verdict_no": "EV-003",
"app_id": "kr.co.bank.smart",
"event_name": "coupon_pressed",
"param_key": null,
"collect_no": "CE-005",
"spec_no": null,
"verdict": "규격에 없는 이벤트",
"expected_type": null,
"sdk_rank": 8001000,
"min_sdk_rank": null,
"evidence": [
{
"table": "client_events",
"field": "event_name",
"agg": null,
"value": "coupon_pressed"
},
{
"table": "sci_event_spec",
"field": "event_name",
"agg": "count",
"value": 12
}
],
"summary": "쿠폰 누름 이벤트는 규격 열두 줄 어디에도 없어 WorksFM 이 읽을 자리가 없습니다.",
"hedge": "고객사가 따로 심은 이벤트로 보이므로, 버릴지 규격에 자리를 만들지는 SCI 조직과 고객사가 정합니다."
},
{
"verdict_no": "EV-004",
"app_id": "kr.co.bank.smart",
"event_name": "app_open",
"param_key": "session_id",
"collect_no": "CE-006",
"spec_no": "ES-008",
"verdict": "SDK 버전이 낮음",
"expected_type": "string",
"sdk_rank": 7002001,
"min_sdk_rank": 8000000,
"evidence": [
{
"table": "client_events",
"field": "sdk_ver",
"agg": null,
"value": "7.2.1"
},
{
"table": "sci_event_spec",
"field": "min_sdk_ver",
"agg": null,
"value": "8.0.0"
}
],
"summary": "앱 실행 이벤트가 7.2.1 에서 올라와 규격이 요구하는 8.0.0 에 못 미칩니다.",
"hedge": null
},
{
"verdict_no": "EV-005",
"app_id": "kr.co.bank.smart",
"event_name": "add_to_cart",
"param_key": "quantity",
"collect_no": "CE-010",
"spec_no": "ES-010",
"verdict": "값 형식이 다름",
"expected_type": "integer",
"sdk_rank": 8001000,
"min_sdk_rank": 7000000,
"evidence": [
{
"table": "client_events",
"field": "sample_value",
"agg": null,
"value": null
},
{
"table": "sci_event_spec",
"field": "value_type",
"agg": null,
"value": "integer"
}
],
"summary": "장바구니 수량 파라미터는 올라오지만 값이 늘 비어 있어 정수로 안 읽힙니다.",
"hedge": "앱에서 값을 안 실어 보내는 것인지 수집 단계에서 떨어진 것인지는 고객사 개발자와 확인합니다."
},
{
"verdict_no": "EV-006",
"app_id": "kr.co.shop.mall",
"event_name": "app_open",
"param_key": "session_id",
"collect_no": "CE-016",
"spec_no": "ES-008",
"verdict": "규격과 맞음",
"expected_type": "string",
"sdk_rank": 10000001,
"min_sdk_rank": 8000000,
"evidence": [
{
"table": "client_events",
"field": "sdk_ver",
"agg": null,
"value": "10.0.1"
},
{
"table": "sci_event_spec",
"field": "min_sdk_ver",
"agg": null,
"value": "8.0.0"
}
],
"summary": "앱 실행 이벤트가 10.0.1 에서 올라와 8.0.0 을 넘습니다.",
"hedge": null
},
{
"verdict_no": "EV-007",
"app_id": "kr.co.shop.mall",
"event_name": "purchase",
"param_key": "amount",
"collect_no": "CE-011",
"spec_no": "ES-001",
"verdict": "규격과 맞음",
"expected_type": "number",
"sdk_rank": 8002000,
"min_sdk_rank": 8000000,
"evidence": [
{
"table": "client_events",
"field": "sample_value",
"agg": null,
"value": "58000"
},
{
"table": "sci_event_spec",
"field": "value_type",
"agg": null,
"value": "number"
}
],
"summary": "결제 금액이 58000 으로 올라와 수치 그대로 읽힙니다.",
"hedge": null
}
][자동 검증 · 코드가 판정합니다] 1. verdict 가 규격과 맞음·필수 파라미터가 빠짐·값 형식이 다름·규격에 없는 이벤트·SDK 버전이 낮음 다섯 값 중 하나인지 확인합니다. 2. verdict_no·app_id·event_name·verdict·evidence·summary 가 모두 채워졌는지 확인합니다. 3. sdk_rank 가 sdk_ver 를 점으로 끊어 major×1000000 + minor×1000 + patch 로 더한 값과 같은지 다시 계산합니다. 자리 수가 셋이 아니면 null 인지 봅니다. 문자열로 견주면 10.0.1 이 8.0.0 보다 작게 나옵니다. 4. min_sdk_rank 가 min_sdk_ver 를 같은 식으로 더한 값과 같은지 다시 계산합니다. 규격에 없는 이벤트이면 null 인지 봅니다. 5. sdk_rank 가 0 이상 99999999 이하인지 범위를 봅니다. 6. expected_type 을 적었다면 그 값이 spec_no 가 가리키는 규격 줄의 value_type 과 같아야 합니다. 7. event_name 이 sci_event_spec.event_name 목록에 없으면 verdict 가 규격에 없는 이벤트인지 확인합니다. 8. sdk_rank 가 min_sdk_rank 보다 작으면 verdict 가 SDK 버전이 낮음인지 확인합니다. 9. sci_event_spec.is_required 가 참인 param_key 가 같은 app_id·event_name 의 client_events.param_key 에 없으면 verdict 가 필수 파라미터가 빠짐인지 확인합니다. 10. sample_value 가 value_type 으로 안 읽히면 verdict 가 값 형식이 다름인지 확인합니다. number 와 integer 는 SCI 가 숫자 그대로 받는 자리라, 통화 표시나 천 단위 쉼표가 한 글자라도 섞이면 안 읽힌 것으로 보고 떼어 내서 다시 읽지 않습니다 — '58000' 처럼 숫자만 있는 값은 읽히고, 쉼표나 '원' 이 붙은 값은 읽히지 않습니다. timestamp 는 ISO 8601 이나 밀리초 정수여야 하고, boolean 은 true·false 여야 합니다. 값이 비어 있으면 어느 형식으로도 안 읽힌 것으로 봅니다. 11. verdict 가 규격과 맞음이면 이름 대조·버전 비교·필수 확인·형식 읽기를 한 번 더 돌려 걸리는 것이 없는지 봅니다. 12. 판정 순서는 규격에 없는 이벤트, SDK 버전이 낮음, 필수 파라미터가 빠짐, 값 형식이 다름 순으로 먼저 걸리는 갈래를 씁니다. 다만 SDK 가 낮은 이벤트는 파라미터가 그 버전에서 아예 안 실리는 것이라 값 형식 검사를 돌리지 않습니다. 13. collect_no 가 있으면 client_events 에 실재하는 줄 번호이고 그 줄의 app_id·event_name 이 판정과 같은지 대조합니다. 14. spec_no 가 있으면 sci_event_spec 에 실재하는 줄 번호이고 그 줄의 event_name·param_key 가 판정과 같은지 대조합니다. 15. evidence 에 적은 field 가 client_events·sci_event_spec 에 실재하는 컬럼 이름인지 대조합니다. 16. agg 가 없는 evidence 는 그 value 가 인용한 줄의 원문 값과 글자까지 같은지 봅니다. 17. summary 는 고객사 앱 개발자에게 바로 나가는 줄이라 존댓말로 닫혀 있어야 합니다. [평가 러너 · 2주차] 1. 짝 80건을 골라 손으로 적은 사유와 도구가 낸 사유를 맞춰 일치율을 냅니다. 2. 사유별 건수를 앱마다 세어 두 앱 이상에서 되풀이되는 이벤트를 추립니다. [수동 검증 · 사람이 봅니다] 1. 값이 늘 비어 있는 파라미터를 앱이 안 실어 보내는지 수집에서 떨어지는지 고객사 개발자와 확인합니다. 2. 규격에 없는 이벤트를 버릴지 규격에 자리를 만들지 SCI 조직과 고객사가 정합니다.