Reflection
경력근거: defining playbooks, best practices, technical standards, and mentorship
※ 실제 산출물이 아닌 AI 예측 시안입니다.
Reflection의 이 자리는 배포 조직을 키우면서 플레이북과 기술 표준을 정의하는 일을 함께 맡습니다. 표준은 정의한 순간이 아니라 여러 고객사에서 실제로 지켜질 때 의미가 생기는데, 퍼블릭 클라우드와 사설망, 온프레미스를 오가면 구성 값이 환경마다 갈라져 사람 눈으로는 좇기 어렵습니다. 이 부담은 배포 건수가 늘어나는 조직을 만드는 자리에서만 생깁니다. 공고 업무는 사전 논의부터 파인튜닝 협업까지 걸쳐 있는데 1주 범위에서 고를 수 있는 것은 하나라 표준 준수 축을 골랐습니다. 이 포트폴리오는 표준을 데이터로 두고 규칙으로 집행해 근거를 남기는 기술을 보여줍니다. 오픈 모델 학습이나 추론 최적화 자체의 전문성은 주장하지 않습니다. 그 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
배포 조직을 키우면서 플레이북과 모범 사례, 기술 표준을 정의하는 일이 이 자리의 업무로 적혀 있습니다. 표준을 문서로만 두면 지켜지는지 알 수 없습니다.
퍼블릭 클라우드와 사설망, 온프레미스를 오가는 배포를 끝까지 책임지는 일이 업무입니다. 환경마다 구성 값이 달라지는 자리가 표준이 가장 잘 깨지는 곳입니다.
사전 논의부터 운영 배포까지 복잡한 에이전트 애플리케이션의 기술 전략과 전달을 총괄합니다. 고객사가 늘수록 구성 편차를 눈으로 좇기 어려워집니다.
고객사별 배포 구성 값과 팀이 정한 표준표를 대조해, 표준을 벗어났거나 필수 항목이 빠진 구성을 사유별로 나눠 출력하고 인수인계용 리포트를 남기는 CLI입니다. 판정은 구성 값을 허용 목록과 필수 여부에 견주는 대조로 정합니다.
고객사 여러 곳의 배포를 동시에 끌고 가는 파견 리드입니다. 팀이 늘면서 사람마다 조금씩 다른 값으로 붙이는데, 사고가 난 뒤에야 그 고객사만 재시도 횟수가 빠져 있었다는 식으로 알게 됩니다.
팀 표준이 항목과 허용 값으로 적혀 있으면, 어느 고객사 구성이 벗어났는지는 사람이 배포마다 열어 보지 않아도 대조로 갈라집니다.
고객사 배포 구성 파일과 표준표를 인자로 받아 항목별 판정을 터미널에 출력하고 인수인계용 리포트를 떨구는 CLI입니다. 실제 클러스터에 붙지 않고 내보낸 구성 값만 읽습니다.
같은 항목을 고객사별로 가로로 늘어놓아 어디만 값이 다른지 한눈에 보여주는 비교표를 리포트에 넣는 구성입니다.
표준표를 바꿨을 때 새로 위반이 되는 고객사를 먼저 뽑아, 표준 개정의 파급을 알고 결정하게 하는 구성입니다.
담당자가 구성 값 50행과 표준표를 넣어 벗어난 항목이 사유별로 나뉜 판정표와 인수인계용 리포트가 나오는 것을 시연합니다.
결측·중복·미등록 항목이 섞인 입력 30종을 넣어도 출력 형식이 깨지지 않고, 판정하지 못한 항목은 사유가 붙어 남습니다.
값이 비어 있는 필수 항목은 지킨 것으로 세지 않고 값 누락으로 따로 답니다. 확인하지 못한 것을 통과로 만들지 않습니다.
판정과 손으로 만든 정답표를 맞춰 사유별로 어긋난 건을 셉니다. 단, 구성과 정답을 모두 작성자가 만든 합성 기준이라 성능 측정이 아니라 데모 조건 동작입니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 더미데이터 자가채점이며, 실제 준수율은 Reflection 고객사의 실제 배포 구성과 실제 표준표가 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
표준을 지킨 구성만 넣으면 어긋난 값을 찾는 일이 성립하지 않습니다. 항목 이름이 플랫폼마다 다른 건, 값이 빈 건, 표준표에 없는 항목을 구성 목록에 섞어 둔 이유입니다.
표준을 벗어났다고 해서 잘못이라고 단정할 수 없습니다. 고객사 환경 제약으로 일부러 다르게 잡은 값일 수 있으므로, 판정은 표준과 다르다는 사실까지만 읽어야 합니다.
실제 도입하면 고객사마다 환경 제약과 예외 승인 이력이 다릅니다. 예외를 표준표에 어떻게 적을지 정하는 일이 도입 단계의 실제 과제입니다.
구성이 표준을 지켰다고 성능이 나온다는 뜻은 아닙니다. 값의 일치까지만 보므로, 실제 성능은 부하 시험으로 따로 봅니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사별 배포에서 내보낸 구성 값입니다. 항목 이름이 플랫폼마다 대소문자·구분자로 흔들리고, 표준표에 없는 신규 항목과 같은 설정 번호가 두 번 들어온 건, 값이 비어 있는 행을 일부러 섞었습니다.
| setting_no | account_name | env_kind | item_raw | item_value | applied_at |
|---|---|---|---|---|---|
| CF-001 | 한성금융 | vpc | retry_limit | 3 | 2026-08-01 |
| CF-002 | 한성금융 | vpc | request_timeout_sec | 30 | 2026-08-01 |
| CF-003 | 한성금융 | vpc | log_level | info | 2026-08-01 |
| CF-004 | 대양제조 | on_prem | Retry_Limit | 0 | 2026-08-03 |
| CF-005 | 대양제조 | on_prem | request timeout sec | 30 | 2026-08-03 |
아래 JSON Schema에 맞는 배포 구성 행을 더 만들어 주세요. {"type":"object","properties":{"setting_no":{"type":"string"},"account_name":{"type":"string"},"env_kind":{"type":"string","enum":["public_cloud","vpc","on_prem"]},"item_raw":{"type":"string"},"item_value":{"type":["string","null"]},"applied_at":{"type":"string"}},"required":["setting_no","account_name","env_kind","item_raw","item_value","applied_at"]} account_name은 한글 회사명으로 적고, 한 고객사에 항목이 세 건 이상 붙도록 만들어 주세요. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 미매핑으로 item_raw가 표준표에 없어 item_id가 null인 행, 둘째 표기흔들림으로 같은 항목을 retry_limit과 Retry_Limit과 RETRY_LIMIT처럼 대소문자와 구분자만 다르게 적은 행, 셋째 중복으로 같은 setting_no가 두 행에 있는 재적재 건, 넷째 결측으로 item_value가 null인 필수 항목, 다섯째 경계극단으로 값이 허용 범위의 상한과 정확히 같은 행. 표준을 지킨 정상 구성이 전체의 절반쯤 되게 해 주세요. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 env_kind에 enum 밖 값을 넣거나 applied_at을 빼서 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"setting_no":{"type":"string"},"account_name":{"type":"string"},"env_kind":{"type":"string","enum":["public_cloud","vpc","on_prem"]},"item_raw":{"type":"string"},"item_value":{"type":["string","null"]},"applied_at":{"type":"string"}},"required":["setting_no","account_name","env_kind","item_raw","item_value","applied_at"]}팀이 정한 배포 표준입니다. 허용 값이 아직 정해지지 않은 항목을 일부러 섞었습니다.
| item_id | item_label | is_required | allowed_values | max_number | applies_to_env |
|---|---|---|---|---|---|
| retry_limit | 재시도 횟수 | true | — | 5 | all |
| request_timeout_sec | 요청 제한 시간 | true | — | 60 | all |
| log_level | 로그 수준 | true | info|warn|error | — | all |
| tool_approval_gate | 도구 승인 게이트 | true | on | — | all |
| model_alias | 모델 별칭 | true | — | — | all |
아래 JSON Schema에 맞는 팀 표준 행을 더 만들어 주세요. {"type":"object","properties":{"item_id":{"type":"string"},"item_label":{"type":"string"},"is_required":{"type":"boolean"},"allowed_values":{"type":["string","null"]},"max_number":{"type":["integer","null"]},"applies_to_env":{"type":"string"}},"required":["item_id","item_label","is_required","allowed_values","max_number","applies_to_env"]} item_label은 한글로 적고 allowed_values는 세로선으로 구분한 목록으로 적어 주세요. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 결측으로 allowed_values와 max_number가 모두 null인 제한 없는 항목, 둘째 경계극단으로 허용 값이 하나뿐인 항목과 max_number가 1인 항목, 셋째 특정 환경에만 적용되는 항목. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 is_required에 문자열을 넣거나 item_id를 빼서 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"item_id":{"type":"string"},"item_label":{"type":"string"},"is_required":{"type":"boolean"},"allowed_values":{"type":["string","null"]},"max_number":{"type":["integer","null"]},"applies_to_env":{"type":"string"}},"required":["item_id","item_label","is_required","allowed_values","max_number","applies_to_env"]}| Python | 구성 값과 표준표를 읽어 대조 판정을 돌리고 리포트를 만드는 본체입니다. |
| TypeScript | 판정 결과를 팀 대시보드가 받아 갈 때 쓰는 타입 정의와 내보내기 스크립트입니다. |
| Kubernetes | 배포 구성이 실제로 적용되는 환경이며, 내보낸 설정 값이 이 도구의 입력입니다. |
| Docker | 판정기를 이미지로 묶어 고객사 환경에서도 같은 방식으로 돌립니다. |
| CI/CD | 배포 파이프라인에 이 판정을 걸어 표준을 벗어난 구성이 나가지 못하게 합니다. |
| 에이전트 오케스트레이션 | 표준 항목의 상당수가 이 계층의 설정입니다. 재시도와 타임아웃, 도구 권한 범위가 여기에 속합니다. |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 고객사끼리 나란히 놓고 편차를 봅니다.
✓ pass → 비교까지가 한 덩어리입니다. 더 키우려면 표준 개정 시 새로 위반이 되는 고객사를 먼저 냅니다.
배포 구성 항목 하나가 팀 표준을 지켰는지의 판정 결과입니다. 벗어났다면 어떻게 벗어났는지를 근거와 함께 담습니다.
{"type":"object","properties":{"setting_no":{"type":"string"},"verdict":{"type":"string","enum":["conforms","value_not_allowed","number_over_limit","required_value_missing","item_unmapped","duplicate_setting"]},"observed_value":{"type":["string","null"]},"standard_hint":{"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":["setting_no","verdict","observed_value","standard_hint","evidence","next_action"]}[
{
"setting_no": "CF-001",
"verdict": "conforms",
"observed_value": "3",
"standard_hint": "5 이하",
"evidence": [
{
"field": "item_value",
"value": "3"
},
{
"field": "max_number",
"value": 5
}
],
"next_action": "표준 안입니다. 그대로 둡니다."
},
{
"setting_no": "CF-003",
"verdict": "conforms",
"observed_value": "info",
"standard_hint": "info|warn|error",
"evidence": [
{
"field": "item_value",
"value": "info"
},
{
"field": "allowed_values",
"value": "info|warn|error"
}
],
"next_action": "허용 목록 안입니다. 그대로 둡니다."
},
{
"setting_no": "CF-006",
"verdict": "value_not_allowed",
"observed_value": "debug",
"standard_hint": "info|warn|error",
"evidence": [
{
"field": "item_value",
"value": "debug"
},
{
"field": "allowed_values",
"value": "info|warn|error"
}
],
"next_action": "허용 목록에 없는 로그 수준입니다. 민감 값이 로그에 남을 수 있어 먼저 내립니다."
},
{
"setting_no": "CF-008",
"verdict": "number_over_limit",
"observed_value": "120",
"standard_hint": "60 이하",
"evidence": [
{
"field": "item_value",
"value": "120"
},
{
"field": "max_number",
"value": 60
}
],
"next_action": "제한 시간이 표준의 두 배입니다. 상류 서비스 타임아웃과 맞는지 확인하고 조정합니다."
},
{
"setting_no": "CF-009",
"verdict": "required_value_missing",
"observed_value": null,
"standard_hint": "on",
"evidence": [
{
"field": "item_value",
"value": null
},
{
"field": "is_required",
"value": true
}
],
"next_action": "필수 항목의 값이 비어 있습니다. 지킨 것으로 세지 않고 배포 전에 채웁니다."
},
{
"setting_no": "CF-011",
"verdict": "item_unmapped",
"observed_value": "0.1",
"standard_hint": null,
"evidence": [
{
"field": "item_raw",
"value": "canary_ratio",
"quote": "canary"
}
],
"next_action": "표준표에 없는 항목입니다. 표준으로 올릴지 개별 설정으로 둘지 팀에서 정합니다."
},
{
"setting_no": "CF-004",
"verdict": "duplicate_setting",
"observed_value": "0",
"standard_hint": "5 이하",
"evidence": [
{
"field": "setting_no",
"agg": "count",
"value": 2
}
],
"next_action": "같은 설정 번호가 두 번 적재됐습니다. 앞 건으로만 판정하고 뒤 건을 목록에서 뺍니다."
}
][자동 검증 · 1주차] 1. verdict가 enum 여섯 값 안에 있는지 확인합니다. 2. setting_no·verdict·observed_value·standard_hint·evidence·next_action이 모두 있는지 확인합니다. 3. max_number가 있는 항목의 item_value가 0 이상 그 값 이하인지 확인합니다. 4. item_value가 null이고 is_required가 true이면 verdict가 required_value_missing인지 확인합니다. 5. evidence의 field가 두 입력 표의 컬럼에 실재하는지 확인합니다. 6. evidence의 quote가 그 행 item_raw의 일부인지 확인합니다. 7. next_action이 존댓말로 끝나는지 확인합니다. [판정 규칙] 1. 항목 이름은 대소문자와 띄어쓰기, 구분자를 없애 소문자로 모은 뒤 team_standards의 item_id와 맞춥니다. 맞는 것이 없으면 미매핑으로 남기고 그 행은 나머지 판정에서 뺍니다. 2. 같은 행 번호가 두 번 들어오면 앞 건만 남기고 뒤 건은 적재 단계에서 사유와 함께 뺍니다. [수동 검증] 1. 표준을 벗어난 값이 고객사 환경 제약 때문인지 배포 담당자가 확인합니다. 2. CF-004·CF-007처럼 항목 표기가 흔들렸지만 표준으로 맞춰진 구성은 미매핑 사유를 달지 않는 것이 맞는지 확인합니다. [평가 러너 · 2주차] 1. 같은 항목을 고객사별로 늘어놓아 한 곳만 다른 값을 쓰는 항목이 몇 건인지 셉니다. 2. 구성과 정답을 작성자가 만든 합성 기준이라 이 수치는 성능 측정이 아니라 데모 조건 동작입니다.
근거: defining playbooks, best practices, technical standards, and mentorship