인포Sr. Forward Deployed Engineer (Sr. FDE)
3.8 (6)인포시즈
경력근거: 고객의 업무 흐름과 데이터 구조를 빠르게 이해하고 모델링합니다.
어제 확인채용 공고 보기
인포시즈 Sr. FDE 는 고객의 업무 흐름과 데이터 구조를 빠르게 이해하고 패턴을 찾아내는 일에서 시작해, 기술을 모르는 고객과도 명확하게 소통하며 비즈니스와 기술 사이의 인터페이스 역할을 하는 자리입니다. 이 도구는 그 첫 업무인 고객사 데이터 상태 파악을 한 명령으로 만들고, 그 결과를 고객이 고치지 않고 읽는 리포트 문장으로 내는 데까지 책임집니다. 검사는 공고의 기술 골조인 Python 과 관계형 데이터베이스와 데이터 파이프라인으로 구현하고, 현장에서 발생하는 다양한 예외 상황을 결함 카드로 남김없이 분류하는 설계와 규칙 파일 교체만으로 다음 고객사에 다시 쓰는 구조는 재사용 가능한 공통 프레임워크와 컴포넌트를 만들어내는 이 역할의 요구와 정렬됩니다. 시니어 공고라고 범위를 키우는 대신 첫 주는 검사 엔진과 리포트 생성기 둘로 좁혔고, 왜 그렇게 잘랐는지를 결정 게이트에 판단 근거로 남겼습니다. 이 포트폴리오가 보여주는 것은 데이터 점검 규칙 설계와 파이프라인 구현과 고객이 읽는 산출물 작성이며, 인포시즈 고객사가 속한 산업의 공정 지식이나 금융·공공 규제 도메인 전문성은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
고객의 업무 흐름과 데이터 구조를 빠르게 이해하고 패턴을 찾아내는 일이 이 역할의 첫 관문입니다. 추출본의 결측과 공백과 상충을 규칙으로 드러내는 점검 리포트가 그 첫 업무에 직접 정렬됩니다.
현장의 예외와 불확실성을 기술로 처리하고 재사용 가능한 공통 프레임워크를 남기는 시니어 범위입니다. 읽지 못한 행까지 사유와 함께 남기는 결함 분류와 규칙 파일 교체만으로 다음 고객사를 점검하는 구조가 정렬됩니다.
고객사 경영진·실무진과 직접 소통하며 비즈니스와 기술 사이의 인터페이스 역할을 하는 자리입니다. 검사 결과를 기술 용어가 아니라 고객이 그대로 읽는 리포트 문장으로 내는 산출물 설계가 정렬됩니다.
새 고객사 온보딩 때 받는 데이터 추출본(CSV 여러 벌)을 입력으로, FDE 가 추출본을 보고 직접 쓰는 검사 규칙 파일(YAML)로 빠진 값·기간 공백·원천끼리 상충하는 기록·미등록 설비 참조·범위 이탈·표기 흔들림 여섯 유형의 결함을 찾아내는 CLI입니다. 추출본을 SQLite 파일 하나에 올려 검사는 전부 SQL 과 결정론 규칙이 수행하고, 산출물은 결함 카드(JSON)와 고객 미팅에서 그대로 읽을 점검 리포트(Markdown) 두 파일입니다. 검사 규칙 파일은 한 사람이 그날 받은 추출본을 보고 쓰는 파일이라, 고객사와 합의해야 나오는 표준이나 사전 같은 조직 산출물을 전제하지 않습니다. LLM 은 2주차에 결함 목록만 받아 요약 절을 쓰는 보조로 붙고 결함 판정과 수치에는 개입하지 않습니다. 화면은 만들지 않습니다. 터미널에서 한 명령으로 시작해 리포트 파일로 끝납니다.
인포시즈 Sr. FDE. 새 고객사 온보딩 첫 주에 받은 추출본 수만 행을 표 계산 프로그램에서 눈으로 훑으며 어느 설비의 기록이 며칠 비었는지, 두 파일의 숫자가 왜 다른지 손으로 대조하던 일을, 한 명령의 점검 리포트로 받아 고객 미팅에 들고 가고 싶은 사람입니다.
추출본 점검을 검사 규칙 파일과 결정론 규칙으로 세우면, (a) 빠진 값과 기간 공백과 어긋난 기록이 결함 카드로 남김없이 잡히고, (b) 리포트의 모든 수치가 규칙 산출값에서만 나와 고객 앞에서 틀린 숫자를 읽을 일이 없으며, (c) 규칙 파일 교체만으로 다음 고객사 추출본을 같은 도구로 점검합니다.
설비 가동 기록과 정비 일지를 가정한 합성 추출본 두 벌과 검사 규칙 파일을 넣으면, 한 명령으로 결함 카드(JSON)와 점검 리포트(Markdown)가 나오는 CLI입니다. 만드는 덩어리는 검사 규칙 엔진(적재 포함)과 리포트 생성기 둘이고, 이 주차의 리포트 문장은 전부 규칙 템플릿이라 LLM 없이 돕니다. 평일 5일에 혼자 끝나는 범위이며 그 자체로 제출 가능한 완결품입니다.
리포트 맨 앞에 Claude Haiku 가 결함 카드만 받아 쓴 요약 절이 붙고, 문장 속 숫자를 결함 카드와 대조해 목록에 없는 숫자면 그 문장을 버리는 가드가 걸리며, 심은 결함 대비 유형별 검출 재현율과 놓친 사례 정리가 붙은 상태입니다.
코드 수정 없이 검사 규칙 파일 교체만으로 다른 도메인 추출본이 점검되는 걸 보이고, Docker 이미지 하나와 CI 회귀 채점(규칙 변경 시 심은 결함 재채점)을 붙인 재사용 패키지입니다.
설비 가동 기록과 정비 일지를 가정한 합성 추출본 두 벌과 검사 규칙 파일을 넣으면, 한 명령으로 결함 카드(JSON)와 고객 미팅용 점검 리포트(Markdown)가 나오는 걸 시연합니다
일부러 만든 악성·결측 입력 30종(빈 파일·헤더만 있는 파일·날짜 형식 흔들림·숫자 자리에 문자·중복 행)을 넣어도 도구가 중간에 죽지 않고, 읽지 못한 행도 사유가 붙은 결함 카드로 남아 처리한 행 수 합계가 입력 행 수와 일치합니다
심은 결함 36건(여섯 유형 각 6건) 기준 결함 카드로 잡힌 게 33건이고, 리포트 본문과 요약 절의 숫자는 규칙 산출값과 100% 일치하며 대조에 실패한 문장은 리포트에 실리지 않습니다. 단, 결함과 데이터를 모두 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건에서의 동작임을 명시합니다
위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 결함 검출률과 리포트의 유용성은 인포시즈 고객사의 실 추출본과 실무진 피드백이 있어야 측정 가능합니다. 이 도구는 그 검증을 바로 돌릴 수 있는 상태로 만듭니다
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다
결함을 작성자가 심었으니 잘 잡히는 게 당연합니다. 빈 파일과 헤더만 있는 파일과 날짜 형식 흔들림과 숫자 자리의 문자와 두 원천이 상충하는 기록을 더미에 일부러 섞어, 깨끗한 추출본만 통과시키는 게 아님을 보여줍니다
시니어 공고라고 첫 주 범위를 키우지 않았습니다. 첫 주는 검사 규칙 엔진과 리포트 생성기 둘만 만들고, LLM 요약과 재사용 패키지는 뒤 주차로 미뤘습니다. 어느 것도 검증할 깊이가 안 나오는 동시 착수를 피한 판단이고, 그 근거를 결정 게이트에 남겼습니다
이 포트폴리오가 보여주는 것은 데이터 점검 규칙 설계와 파이프라인 구현과 고객이 읽는 산출물 작성 기술입니다. 인포시즈 고객사가 속한 산업의 공정 지식이나 금융·공공 규제 환경 설계 같은 도메인 전문성은 주장하지 않으며, 그 깊이는 면접에서 모르면 모른다고 말하는 편이 낫습니다
LLM 은 그럴듯한 숫자를 지어낼 수 있습니다. 요약 절은 결함 카드 목록만 컨텍스트로 받고, 문장 속 숫자를 결함 카드와 대조해 목록에 없는 숫자면 그 문장을 리포트에 싣지 않습니다
실제 고객사 추출본은 파일 형식과 결함 분포가 더미와 다릅니다. 고객사별 검사 규칙 파일을 새로 쓰는 일은 이 도구가 줄여 주는 대상이지 없애 주는 대상이 아니라서, 도입 단계 과제로 분리해 잡습니다
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 온보딩 때 받는 설비 일일 가동 기록 추출본을 흉내 낸 행입니다. 자동 수집분(mes_export)과 현장 수기 입력분(manual_sheet) 두 원천으로 나눠, 같은 설비·같은 날짜의 상충 기록과 기간 공백과 결측과 표기 흔들림을 일부러 섞었습니다.
| row_id | file_source | equipment_code | run_date | runtime_hours | downtime_hours | operator |
|---|---|---|---|---|---|---|
| r_001 | mes_export | PRS-01 | 2026-03-02 | 21.5 | 0.5 | 김반장 |
| r_002 | mes_export | PRS-01 | 2026-03-03 | 22 | — | 김반장 |
| r_003 | manual_sheet | PRS-01 | 2026-03-03 | 8 | — | — |
| r_004 | mes_export | PRS-01 | 2026-03-04 | 21 | 1 | 김반장 |
| r_005 | mes_export | PRS-02 | 2026-03-02 | — | — | 이주임 |
아래 JSON Schema 에 맞는 설비 가동 기록 60건을 JSON 배열로 생성해 주세요. 설비 5대 안팎을 mes_export 와 manual_sheet 두 원천에 나눠 담고, 같은 설비의 같은 날짜가 두 원천에 함께 나오는 경우를 섞습니다.
{"type":"object","properties":{"row_id":{"type":"string"},"file_source":{"type":"string","enum":["mes_export","manual_sheet"]},"equipment_code":{"type":"string"},"run_date":{"type":"string"},"runtime_hours":{"type":["number","null"]},"downtime_hours":{"type":["number","null"]},"operator":{"type":["string","null"]}},"required":["row_id","file_source","equipment_code","run_date"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어 주세요: (1) 같은 설비·같은 날짜인데 두 원천의 runtime_hours 가 다른 상충 기록 3쌍, (2) 한 설비의 기록이 5일 이상 통째로 비는 기간 공백 2건, (3) runtime_hours 나 operator 가 null 인 결측 행 6건 이상, (4) 'PRS-02'/'prs-02'/'PRS 02' 처럼 대소문자·공백이 흔들리는 설비 코드 표기 4건, (5) 하루 24시간을 넘는 runtime_hours 1건 이상과 0 인 경계값 1건 이상. 형식을 깨뜨리는 시도(타입 오류)는 데이터에 넣지 말고 별도 3건으로 만들어 주세요. JSON 배열만.{"type":"object","properties":{"row_id":{"type":"string"},"file_source":{"type":"string","enum":["mes_export","manual_sheet"]},"equipment_code":{"type":"string"},"run_date":{"type":"string"},"runtime_hours":{"type":["number","null"]},"downtime_hours":{"type":["number","null"]},"operator":{"type":["string","null"]}},"required":["row_id","file_source","equipment_code","run_date"]}같은 고객사에서 받은 정비 작업 일지 추출본을 흉내 낸 행입니다. 가동 기록과 교차 검사하는 입력이라, 가동 기록에 없는 설비 참조와 추출 기간 밖 날짜와 결측과 음수 금액과 같은 작업의 금액이 다른 중복 기록을 일부러 섞었습니다.
| log_id | equipment_code | work_date | work_type | parts_cost | note |
|---|---|---|---|---|---|
| m_001 | PRS-01 | 2026-03-03 | 교체 | 450,000 | 프레스 금형 교체 |
| m_002 | PRS-02 | 2026-03-05 | 점검 | — | — |
| m_003 | CNC-07 | 2026-03-08 | 수리 | 1,200,000 | 스핀들 수리로 가동 중단 |
| m_004 | GRD-11 | 2026-03-06 | 점검 | 90,000 | 연삭기 정기 점검 |
| m_005 | WLD-03 | 2026-03-07 | 수리 | 300,000 | 토치 교체 |
아래 JSON Schema 에 맞는 정비 작업 일지 40건을 JSON 배열로 생성해 주세요. 설비는 가동 기록과 대부분 겹치게 하되 일부만 어긋나게 합니다.
{"type":"object","properties":{"log_id":{"type":"string"},"equipment_code":{"type":"string"},"work_date":{"type":"string"},"work_type":{"type":["string","null"]},"parts_cost":{"type":["integer","null"]},"note":{"type":["string","null"]}},"required":["log_id","equipment_code","work_date"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어 주세요: (1) 가동 기록에 한 번도 나오지 않는 설비 코드를 참조하는 행 2건, (2) 추출 기간(2026-03-01~2026-03-31) 밖의 work_date 2건, (3) work_type 이나 parts_cost 가 null 인 결측 행 4건 이상, (4) parts_cost 가 음수인 행 1건, (5) 같은 설비·같은 날짜·같은 작업인데 parts_cost 가 다른 중복 기록 1쌍, (6) 'prs-01' 처럼 대소문자가 흔들리는 설비 코드 표기 2건. 형식을 깨뜨리는 시도(타입 오류)는 데이터에 넣지 말고 별도 3건으로 만들어 주세요. JSON 배열만.{"type":"object","properties":{"log_id":{"type":"string"},"equipment_code":{"type":"string"},"work_date":{"type":"string"},"work_type":{"type":["string","null"]},"parts_cost":{"type":["integer","null"]},"note":{"type":["string","null"]}},"required":["log_id","equipment_code","work_date"]}| Python | 추출본 적재기·검사 규칙 실행 엔진·리포트 생성기의 구현 언어입니다 |
| 관계형 데이터베이스 | 추출본을 SQLite 에 올려 결측률·기간 공백·상충을 SQL 로 계산합니다. 파일 하나로 끝나 고객사 환경에 설치가 없습니다 |
| 비관계형 데이터베이스 | 받은 추출본 원본과 결함 카드를 JSON 문서로 보관해, 규칙을 고칠 때마다 원본에서 다시 점검합니다 |
| 데이터 파이프라인 | 적재, 검사, 리포트 생성을 한 명령으로 잇는 배치 경로이며 같은 입력을 다시 돌려도 같은 리포트가 나오게 만듭니다 |
| LLM Agent | 2주차에 규칙이 산출한 결함 카드만 받아 요약 절을 쓰는 보조이고, 결함 판정과 수치에는 개입하지 않습니다 |
| 프롬프트·컨텍스트 엔지니어링 | 요약 프롬프트에 결함 카드 목록만 컨텍스트로 줘서, 목록에 없는 수치가 문장에 들어가지 못하게 막습니다 |
| RAG | 요약을 쓸 때 결함 카드에서 심각도 높은 항목을 검색해 컨텍스트로 붙이는 좁은 용도입니다 |
| 임베딩 | 같은 원인으로 보이는 결함 설명끼리 묶어, 리포트가 같은 지적을 수백 번 반복하지 않게 합니다 |
| 벡터 DB | 결함 설명 임베딩을 담는 검색 층입니다. 규모가 작아 로컬 파일 인덱스로 충분합니다 |
| Docker | 고객사 환경에서 같은 명령으로 돌게 3주차에 도구를 이미지 하나로 쌉니다 |
| CI/CD | 검사 규칙 파일이 바뀔 때마다 심은 결함 회귀 채점을 돌려 통과해야 반영합니다 |
✓ pass → 그대로 멈춰도 완결입니다. LLM 요약을 붙이고 싶어도 여기서 참습니다. 규칙 검출이 검증되기 전의 생성 문장은 틀린 숫자를 그럴듯하게 포장할 뿐이라는 판단이고, 이 잘라내기가 시니어 범위 설정의 근거입니다. 더 키우려면 2주차(요약 절과 자가채점)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(규칙 파일 교체만으로 두 번째 고객사 점검과 패키지화)로 진행합니다.
추출본 점검에서 나온 결함 1건의 카드입니다. 결함 종류와 심각도와 근거 행과 규칙 산출값과 고객 미팅에서 읽을 리포트 문장을 한 스키마로 담아, 점검 리포트와 회귀 채점에 함께 씁니다. 판정과 수치는 전부 규칙이 정하고 요약 문장화만 LLM 보조입니다.
{"type":"object","properties":{"finding_id":{"type":"string"},"kind":{"type":"string","enum":["missing_value","period_gap","conflicting_records","unknown_reference","out_of_range","notation_drift"]},"severity":{"type":"string","enum":["critical","warn","info"]},"dataset":{"type":"string"},"row_refs":{"type":"array","items":{"type":"string"}},"measured":{"type":["string","null"]},"evidence":{"type":"string"},"report_sentence":{"type":"string"},"hedge":{"type":["string","null"]}},"required":["finding_id","kind","severity","dataset","row_refs","evidence","report_sentence"]}[
{
"input_ref": "r_002, r_003 (같은 설비·같은 날짜의 가동시간이 두 원천에서 다름)",
"output": {
"finding_id": "f_conflict_prs01_0303",
"kind": "conflicting_records",
"severity": "critical",
"dataset": "machine_runtime_rows",
"row_refs": [
"r_002",
"r_003"
],
"measured": "mes_export=22.0, manual_sheet=8.0",
"evidence": "PRS-01 의 2026-03-03 가동시간이 자동 수집분에서는 22.0시간, 수기 입력분에서는 8.0시간으로 다릅니다. 한쪽을 임의로 고르지 않았습니다.",
"report_sentence": "3월 3일 PRS-01 의 가동시간이 자동 수집분(22.0시간)과 수기 입력분(8.0시간)에서 다르게 기록돼 있습니다. 두 기록 중 정본으로 삼을 원천을 정해 주시면 이후 점검 기준에 반영하겠습니다.",
"hedge": "어느 쪽이 정본인지는 고객 확인이 필요합니다."
}
},
{
"input_ref": "r_009, r_010 (CNC-07 의 가동 기록이 3월 4일부터 11일까지 빔)",
"output": {
"finding_id": "f_gap_cnc07_0304",
"kind": "period_gap",
"severity": "warn",
"dataset": "machine_runtime_rows",
"row_refs": [
"r_009",
"r_010"
],
"measured": "missing_days=8",
"evidence": "CNC-07 은 2026-03-03 기록 다음이 2026-03-12 라서 사이 8일치 가동 기록이 없습니다.",
"report_sentence": "CNC-07 설비는 3월 4일부터 3월 11일까지 8일간 가동 기록이 없습니다. 이 기간에 실제로 멈춰 있었는지, 추출에서 빠졌는지 확인 부탁드립니다.",
"hedge": "정비 일지에 3월 8일 스핀들 수리 기록이 있어 실제 중단이었을 가능성도 있습니다."
}
},
{
"input_ref": "m_004 (정비 일지의 GRD-11 이 가동 기록에 없음)",
"output": {
"finding_id": "f_unknownref_grd11",
"kind": "unknown_reference",
"severity": "warn",
"dataset": "maintenance_log_rows",
"row_refs": [
"m_004"
],
"measured": null,
"evidence": "정비 일지의 GRD-11 설비가 가동 기록 추출본에 한 번도 나오지 않습니다. 임의로 다른 설비에 붙이지 않았습니다.",
"report_sentence": "정비 일지에 있는 GRD-11 설비는 가동 기록에 한 번도 나오지 않습니다. 가동을 수집하지 않는 설비인지, 다른 코드로 기록되는 설비인지 알려 주세요.",
"hedge": null
}
},
{
"input_ref": "r_008 (하루 가동시간이 24시간을 넘는 값)",
"output": {
"finding_id": "f_range_cnc07_0302",
"kind": "out_of_range",
"severity": "critical",
"dataset": "machine_runtime_rows",
"row_refs": [
"r_008"
],
"measured": "runtime_hours=26.5, max=24.0",
"evidence": "CNC-07 의 2026-03-02 가동시간이 26.5시간으로 하루 상한 24시간을 넘습니다.",
"report_sentence": "3월 2일 CNC-07 의 가동시간이 26.5시간으로 기록돼 하루 24시간을 넘습니다. 계측 단위나 입력 과정에 오류가 있는지 확인이 필요합니다.",
"hedge": "상한 24시간은 검사 규칙 파일의 가정값이라 실제 교대 기준과 다를 수 있습니다."
}
},
{
"input_ref": "r_005 (runtime_hours 결측 집계)",
"output": {
"finding_id": "f_missing_runtime",
"kind": "missing_value",
"severity": "info",
"dataset": "machine_runtime_rows",
"row_refs": [
"r_005"
],
"measured": "null_count=1, null_rate=7.1%",
"evidence": "runtime_hours 가 비어 있는 행이 전체 14행 중 1행입니다.",
"report_sentence": "가동 기록 14행 중 1행(7.1%)은 가동시간이 비어 있습니다. 결측 행을 빼고 볼지, 다시 받을 수 있는지 정해 주시면 됩니다.",
"hedge": null
}
}
][자동 검증] 1. 결함 카드가 JSON Schema(필드·enum·필수값)를 통과하는지 확인합니다. 2. row_refs 의 모든 행 id 가 입력 추출본에 실재하는지 대조하고, 없는 행을 가리킨 카드는 오류로 잡습니다. 3. report_sentence 와 measured 안의 숫자가 규칙 산출값과 일치하는지 대조해, 어디에도 없는 숫자가 리포트에 들어가지 못하게 막습니다. 4. 결함 카드를 심은 결함 목록과 비교해 유형별 재현율을 계산하고, 검사 규칙 파일이 바뀔 때마다 CI 에서 회귀 채점을 돌립니다. [수동 검증] 1. 리포트 문장 20건을 뽑아 고객 미팅에서 고치지 않고 그대로 읽을 문장인지 점검합니다. 2. 전체의 5% 를 사람이 직접 점검합니다.