에이Forward Deployed Engineer
3.3 (53)에이아이트릭스
경력근거: 현장에서 반복되는 문제를 트러블슈팅에서 끝내지 않고, ADP 플랫폼 표준(연동 고도화·온톨로지화·자동화)으로 자산화
어제 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
공고가 FDE 리드의 일로 '병원 도입 전반(제안·설계·연동·검증·배포·안정화) 총괄' 을 적었고, 이어서 '현장에서 반복되는 문제를 트러블슈팅에서 끝내지 않고, ADP 플랫폼 표준(연동 고도화·온톨로지화·자동화)으로 자산화' 를 요구했습니다. 이 포트폴리오는 1주차에 병원별 규격 적합성을 가르고, 2주차에 병원마다 반복되는 위반을 모아 공통 프로파일 후보로 냅니다. 'FDE팀의 업무 체계와 표준 프로세스 직접 정의 및 구축' 도 그 두 단계를 잇는 자리입니다. 이 포트폴리오가 보여주는 것은 규격을 데이터로 두고 받은 메시지와 맞춰 적합 여부를 가르는 기술이며, 임상 지식이나 의료정보 표준 제정 전문성은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
'병원 도입 전반(제안·설계·연동·검증·배포·안정화) 총괄'. 연동과 검증 사이에 이 도구가 놓입니다.
'FDE팀의 업무 체계와 표준 프로세스 직접 정의 및 구축'. 병원마다 반복되는 위반을 모아 표준 후보로 올리는 것이 2주차입니다.
'데이터 연동·파이프라인 또는 엔터프라이즈 시스템 통합에 대한 이해와 직접 구현 경험'. 규격 적합성 확인이 그 실무의 앞단입니다.
병원이 보내온 연동 메시지가 그 병원과 약속한 규격을 지켰는지 항목마다 가릅니다. 병원별 프로파일에 세그먼트와 위치별 필수 여부, 기대 코드 체계, 허용 값을 두고 받은 메시지와 맞춰, 다 맞으면 적합으로 넘기고 그렇지 않으면 필수 누락·코드 미대응·허용 밖 값 중 어느 쪽인지 사유로 남깁니다. 프로파일에 없는 세그먼트는 미선언으로, 프로파일 자체가 없는 병원은 미작성으로 남겨 규격을 먼저 정하게 합니다. 메시지는 실 환자 자료 대신 지원자가 HL7 공개 규격으로 만든 것을 가정하며 실제 환자 정보를 쓰지 않습니다.
여러 병원 도입을 동시에 끌고 가는 FDE 리드입니다. 병원마다 보내는 항목이 조금씩 다른데 그 차이를 설치를 마치고 데이터가 흐르기 시작한 뒤에야 알게 되어, 매번 로그를 뒤져 어느 항목이 안 왔는지 세던 사람입니다.
병원마다 기대하는 세그먼트와 항목을 프로파일로 적어 두고 받은 메시지와 맞추면, 어긋난 항목이 연동 전에 목록으로 나오고 어긋난 이유가 근거로 남는다는 가정입니다. 프로파일이 없는 병원은 미작성으로 빠지므로 규격을 아직 약속하지 않은 현장이 그대로 드러납니다.
받은 메시지와 병원별 프로파일을 넣으면 항목마다 적합·위반을 판정하고, 위반이면 필수 누락·코드 미대응·허용 밖 값·미선언 세그먼트·프로파일 미작성 중 어느 쪽인지 붙여 병원별로 묶은 적합성 리포트를 터미널과 Markdown 파일로 내는 CLI 가 도는 완결품입니다.
여러 병원의 판정을 합쳐 같은 세그먼트·항목에서 반복되는 위반을 세고, 두 곳 이상에서 같은 모양으로 걸린 항목을 공통 프로파일 후보 목록으로 냅니다.
위반 항목을 담당 조직별로 갈라 확인 요청 문서를 조립하고, 코드 미대응 항목은 대응표에 채울 빈칸을 함께 내는 단계입니다.
FDE 리드가 메시지와 병원별 프로파일을 넣으면 항목마다 적합 여부와 위반 사유가 병원별로 묶여 나오는 과정을 시연합니다.
HL7 공개 규격으로 만든 메시지 500건에 손으로 붙인 정답 적합성과 대조해 일치율을 냅니다. 단, 정답과 메시지를 모두 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
값이 비었거나 세그먼트 표기가 흔들리거나 프로파일에 없는 세그먼트가 섞인 입력 30종을 넣어도 출력 형식이 안 깨지고 사유별로 빠지는 비율을 보여줍니다.
프로파일의 필수 여부와 허용 목록을 바꿨을 때 옛 판정이 어떻게 뒤집히는지 회귀로 확인합니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 작성자가 만든 메시지의 자가채점이며, 실제 연동 적합성은 에이아이트릭스가 도입한 병원의 실 인터페이스 규격이 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아니므로, 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 붙였으니 잘 맞는 게 당연하므로, 필수 결측과 허용 밖 값, 프로파일에 없는 확장 세그먼트를 일부러 섞어 쉬운 항목만 푸는 함정을 피합니다.
이 포트폴리오가 보여주는 것은 규격을 데이터로 두고 받은 메시지와 맞춰 적합 여부를 가르는 기술이며, 임상 지식이나 의료정보 표준 제정 전문성은 주장하지 않습니다. 판정은 필수 여부와 허용 목록 대조가 하고 LLM 은 담당자가 읽을 사유 문장만 맡습니다.
메시지 값은 전부 합성이고 실제 환자 정보를 다루지 않으므로, 실제 도입에서는 병원 반출 규정을 먼저 확인하는 일이 앞섭니다.
병원마다 자체 확장 세그먼트가 다르므로, 프로파일을 병원별로 새로 채우는 일을 도입 단계 과제로 둡니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
병원이 보내온 연동 메시지를 항목 단위로 편 것입니다. 행 번호와 메시지 번호, 병원 코드, 세그먼트 표기, 항목 위치, 받은 값, 코드 체계 표기, 수신 시각을 한 행에 둡니다. 세그먼트 표기는 보내는 쪽 설정에 따라 'OBX'와 'obx'처럼 흔들립니다. 값이 빈 행, 허용 목록 밖의 값, 프로파일에 없는 자체 확장 세그먼트, 프로파일이 아직 없는 병원 행을 일부러 섞어 두어 사유가 갈리게 둡니다.
| row_no | msg_no | site_code | segment_raw | field_pos | value_raw | code_system_raw | received_at |
|---|---|---|---|---|---|---|---|
| HR-001 | MSG-7001 | H-A | PID | 3 | 1002938 | MR | 2026-08-20T09:12:00 |
| HR-002 | MSG-7001 | H-A | PID | 7 | 19580214 | — | 2026-08-20T09:12:00 |
| HR-003 | MSG-7001 | H-A | PID | 8 | — | — | 2026-08-20T09:12:00 |
| HR-004 | MSG-7002 | H-A | OBX | 3 | 8867-4 | LN | 2026-08-20T09:31:00 |
| HR-005 | MSG-7002 | H-A | obx | 5 | 78 | — | 2026-08-20T09:31:00 |
아래 JSON Schema 를 그대로 만족하는 연동 메시지 항목 행을 500개 더 만들어 주세요. 병원 코드를 서넛 두고 세그먼트를 PID·OBX·OBR·PV1 로 섞습니다. 세그먼트 표기는 몇 행에서 소문자로 두고, 2할은 값이나 코드 체계를 비우며, 몇 행은 허용 목록 밖의 값과 'Z'로 시작하는 자체 확장 세그먼트를 넣으세요. 실제 환자 정보를 쓰지 말고 식별자와 날짜를 지어냅니다. 적합 여부나 사유는 넣지 마세요.
{"type": "object", "properties": {"row_no": {"type": "string"}, "msg_no": {"type": "string"}, "site_code": {"type": "string"}, "segment_raw": {"type": "string"}, "field_pos": {"type": "integer"}, "value_raw": {"type": ["string", "null"]}, "code_system_raw": {"type": ["string", "null"]}, "received_at": {"type": "string"}}, "required": ["row_no", "msg_no", "site_code", "segment_raw", "field_pos", "value_raw", "code_system_raw", "received_at"]}{"type": "object", "properties": {"row_no": {"type": "string"}, "msg_no": {"type": "string"}, "site_code": {"type": "string"}, "segment_raw": {"type": "string"}, "field_pos": {"type": "integer"}, "value_raw": {"type": ["string", "null"]}, "code_system_raw": {"type": ["string", "null"]}, "received_at": {"type": "string"}}, "required": ["row_no", "msg_no", "site_code", "segment_raw", "field_pos", "value_raw", "code_system_raw", "received_at"]}병원별로 약속한 인터페이스 프로파일입니다. 규칙 번호와 병원 코드, 세그먼트, 항목 위치, 항목 이름, 필수 여부, 기대 코드 체계, 허용 값, 담당을 한 행에 둡니다. 같은 세그먼트라도 병원마다 필수 여부와 허용 값이 달라 한 메시지가 어느 병원 것이냐로 결과가 갈립니다. 메시지에 나오는 병원 중 일부는 일부러 넣지 않아 프로파일 미작성이 도출되게 둡니다.
| rule_no | site_code | segment_raw | field_pos | field_label | required_flag | code_system_raw | allowed_values | owner_name |
|---|---|---|---|---|---|---|---|---|
| IP-101 | H-A | PID | 3 | 환자 식별자 | true | MR | — | 연동팀 |
| IP-102 | H-A | PID | 7 | 생년월일 | true | — | — | 연동팀 |
| IP-103 | H-A | PID | 8 | 성별 | true | — | ["M","F","U"] | 연동팀 |
| IP-104 | H-A | OBX | 3 | 관측 항목 | true | LN | — | 임상데이터 |
| IP-105 | H-A | OBX | 5 | 관측 값 | true | — | — | 임상데이터 |
아래 JSON Schema 를 그대로 만족하는 인터페이스 프로파일 행을 40개 더 만들어 주세요. 병원마다 같은 세그먼트에 필수 여부와 허용 값을 다르게 두고, 허용 값이 필요 없는 항목은 비웁니다. 메시지에 나오는 병원 중 일부는 일부러 넣지 마세요 — 미작성이 있어야 규격을 아직 약속하지 않은 현장이 드러납니다. 판정 결과는 넣지 마세요.
{"type": "object", "properties": {"rule_no": {"type": "string"}, "site_code": {"type": "string"}, "segment_raw": {"type": "string"}, "field_pos": {"type": "integer"}, "field_label": {"type": "string"}, "required_flag": {"type": "boolean"}, "code_system_raw": {"type": ["string", "null"]}, "allowed_values": {"type": ["array", "null"], "items": {"type": "string"}}, "owner_name": {"type": "string"}}, "required": ["rule_no", "site_code", "segment_raw", "field_pos", "field_label", "required_flag", "owner_name"]}{"type": "object", "properties": {"rule_no": {"type": "string"}, "site_code": {"type": "string"}, "segment_raw": {"type": "string"}, "field_pos": {"type": "integer"}, "field_label": {"type": "string"}, "required_flag": {"type": "boolean"}, "code_system_raw": {"type": ["string", "null"]}, "allowed_values": {"type": ["array", "null"], "items": {"type": "string"}}, "owner_name": {"type": "string"}}, "required": ["rule_no", "site_code", "segment_raw", "field_pos", "field_label", "required_flag", "owner_name"]}| Python | 메시지 행과 프로파일을 맞춰 필수 여부와 허용 값을 견주는 판정기를 맡습니다. |
| SQL | 여러 병원의 판정을 합쳐 반복되는 위반을 세는 2주차 집계를 맡습니다. |
| Docker | 병원 폐쇄망에서 같은 결과가 나오도록 CLI 를 컨테이너로 싸 둡니다. |
| Markdown | 병원별 적합성 리포트와 확인 요청 문서를 파일로 냅니다. |
✗ fail → 미선언이 절반을 넘으면 프로파일을 먼저 채웁니다.
✓ pass → 2주차 반복 위반 집계로 넘어갑니다.
✗ fail → 병원마다 다른 위반만 나오면 공통 프로파일 후보를 내지 않고 병원별로 둡니다.
✓ pass → 3주차 확인 요청 문서로 넘어갑니다.
메시지 항목 하나와 프로파일 규칙이 만나는 자리마다 규격을 지켰는지 정합니다. 어긋나면 필수 누락·코드 미대응·허용 밖 값·미선언 세그먼트·프로파일 미작성 중 어느 쪽인지 싣습니다. 화면과 리포트는 이 사유 코드로 묶습니다.
{"type": "object", "properties": {"verdict_no": {"type": "string"}, "row_no": {"type": "string"}, "msg_no": {"type": "string"}, "site_code": {"type": "string"}, "segment_raw": {"type": "string"}, "field_pos": {"type": "integer"}, "rule_no": {"type": ["string", "null"]}, "conform_code": {"type": "string", "enum": ["conformant", "required_missing", "code_unmapped", "value_not_allowed", "segment_undeclared", "profile_absent"]}, "field_label": {"type": ["string", "null"]}, "owner_name": {"type": ["string", "null"]}, "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", "row_no", "msg_no", "site_code", "segment_raw", "field_pos", "conform_code", "evidence", "summary"]}[
{
"verdict_no": "FC-001",
"row_no": "HR-001",
"msg_no": "MSG-7001",
"site_code": "H-A",
"segment_raw": "PID",
"field_pos": 3,
"rule_no": "IP-101",
"conform_code": "conformant",
"field_label": "환자 식별자",
"owner_name": "연동팀",
"evidence": [
{
"field": "code_system_raw",
"agg": null,
"value": "MR"
},
{
"field": "required_flag",
"agg": null,
"value": true
}
],
"summary": "필수 항목이 값과 코드 체계를 모두 채워 프로파일과 맞습니다.",
"hedge": null
},
{
"verdict_no": "FC-002",
"row_no": "HR-005",
"msg_no": "MSG-7002",
"site_code": "H-A",
"segment_raw": "obx",
"field_pos": 5,
"rule_no": "IP-105",
"conform_code": "conformant",
"field_label": "관측 값",
"owner_name": "임상데이터",
"evidence": [
{
"field": "segment_raw",
"agg": null,
"value": "obx"
},
{
"field": "value_raw",
"agg": null,
"value": "78"
}
],
"summary": "세그먼트를 소문자로 적어 보냈으나 접으면 OBX 와 같아 프로파일과 맞습니다.",
"hedge": null
},
{
"verdict_no": "FC-003",
"row_no": "HR-003",
"msg_no": "MSG-7001",
"site_code": "H-A",
"segment_raw": "PID",
"field_pos": 8,
"rule_no": "IP-103",
"conform_code": "required_missing",
"field_label": "성별",
"owner_name": "연동팀",
"evidence": [
{
"field": "value_raw",
"agg": null,
"value": null
},
{
"field": "required_flag",
"agg": null,
"value": true
}
],
"summary": "성별이 필수인데 값이 비어 들어와 연동팀에 되물어야 합니다.",
"hedge": null
},
{
"verdict_no": "FC-004",
"row_no": "HR-007",
"msg_no": "MSG-7003",
"site_code": "H-B",
"segment_raw": "OBX",
"field_pos": 3,
"rule_no": "IP-108",
"conform_code": "code_unmapped",
"field_label": "관측 항목",
"owner_name": "임상데이터",
"evidence": [
{
"field": "code_system_raw",
"agg": null,
"value": "LOCAL"
},
{
"field": "value_raw",
"agg": null,
"value": "HR001"
}
],
"summary": "표준 코드 체계를 기대하는 자리에 병원 자체 코드가 와서 대응표가 필요합니다.",
"hedge": "'HR001'이 심박수로 보이나 코드만으로 단정하지 않고 병원에 확인합니다."
},
{
"verdict_no": "FC-005",
"row_no": "HR-008",
"msg_no": "MSG-7003",
"site_code": "H-B",
"segment_raw": "OBX",
"field_pos": 11,
"rule_no": "IP-109",
"conform_code": "value_not_allowed",
"field_label": "결과 상태",
"owner_name": "임상데이터",
"evidence": [
{
"field": "value_raw",
"agg": null,
"value": "X"
},
{
"field": "allowed_values",
"agg": null,
"value": [
"F",
"P",
"C"
]
}
],
"summary": "결과 상태가 허용 목록 밖의 'X'로 와서 그대로 받으면 뒤 단계가 갈립니다.",
"hedge": null
},
{
"verdict_no": "FC-006",
"row_no": "HR-010",
"msg_no": "MSG-7004",
"site_code": "H-B",
"segment_raw": "ZBI",
"field_pos": 2,
"rule_no": null,
"conform_code": "segment_undeclared",
"field_label": null,
"owner_name": null,
"evidence": [
{
"field": "segment_raw",
"agg": null,
"value": "ZBI"
},
{
"field": "rule_no",
"agg": "count",
"value": 12
}
],
"summary": "프로파일 열두 행에 없는 자체 확장 세그먼트라 받을지 먼저 정해야 합니다.",
"hedge": null
},
{
"verdict_no": "FC-007",
"row_no": "HR-012",
"msg_no": "MSG-7005",
"site_code": "H-C",
"segment_raw": "OBR",
"field_pos": 4,
"rule_no": null,
"conform_code": "profile_absent",
"field_label": null,
"owner_name": null,
"evidence": [
{
"field": "site_code",
"agg": null,
"value": "H-C"
},
{
"field": "site_code",
"agg": "count",
"value": 12
}
],
"summary": "이 병원의 프로파일이 아직 없어 무엇을 기대할지 정해 두지 않았습니다.",
"hedge": null
}
][자동 검증 · 코드가 판정합니다] 1. conform_code 가 enum 여섯 값 중 하나인지 확인합니다. 2. verdict_no·row_no·msg_no·site_code·segment_raw·field_pos·conform_code·evidence·summary 가 모두 채워졌는지 확인합니다. 3. row_no 가 메시지 행에 실재하는 번호인지 대조합니다. 4. rule_no 가 있으면 프로파일에 실재하는 행 번호인지 대조합니다. 5. rule_no 가 있으면 field_label·owner_name 이 그 규칙 행의 값과 같은지 대조합니다. 6. segment_raw 를 대소문자를 접어 프로파일과 맞추고, 같은 병원에 그 세그먼트 규칙이 없으면 conform_code 가 segment_undeclared 인지 확인합니다. 7. site_code 가 프로파일에 한 행도 없으면 conform_code 가 profile_absent 인지 확인합니다. 8. required_flag 가 참인데 value_raw 가 비어 있으면 conform_code 가 required_missing 인지 확인합니다. 9. conform_code 가 code_unmapped 이면 code_system_raw 가 규칙의 기대 코드 체계와 다른지 확인합니다. 10. allowed_values 가 있으면 value_raw 가 그 목록 안에 있는지 확인하고, 없으면 conform_code 가 value_not_allowed 인지 확인합니다. 11. conform_code 가 conformant 이면 필수·코드 체계·허용 값 검사를 모두 통과하는지 다시 확인합니다. 12. evidence 의 field 이름이 메시지 행과 프로파일에 실재하는 컬럼인지 대조합니다. 13. agg 가 없는 evidence 의 value 가 그 컬럼에 수록된 행 값과 같은지 확인합니다. 14. summary 가 존댓말로 끝나는지 확인합니다. [평가 러너 · 2주차] 여러 병원의 판정을 합쳐 같은 세그먼트·항목에서 반복되는 위반을 세고, 두 곳 이상에서 같은 모양으로 걸린 항목을 공통 프로파일 후보 목록으로 냅니다. [수동 검증 · 사람이 봅니다] 1. 병원 자체 코드를 표준 코드 어디에 붙일지 임상 담당이 정합니다. 2. 자체 확장 세그먼트를 받을지 연동팀이 정합니다.