인포Forward Deployed Engineer (FDE)
3.8 (6)인포시즈
경력근거: AI·데이터 기반 솔루션을 실제 운영 환경에 적용하고 안정적으로 정착시킵니다
어제 확인채용 공고 보기
인포시즈 FDE 는 고객의 문제와 가장 가까운 곳에서 운영 구조를 이해하고 데이터를 해석해 기술이 실제 현장에서 작동하도록 잇는 역할이고, 공고는 '고객사의 운영 과정과 문제를 분석하고 해결 방향을 설계합니다'와 '고객의 업무 흐름과 데이터 구조를 빠르게 이해하고 모델링합니다'를 주요 업무로 적어 두었습니다. 이 도구는 고객사 담당자가 매일 엑셀에서 손으로 더하던 납기 회신 계산을 그대로 받아, 추출본 세 벌을 모델링하고 배정 규칙을 산술로 고정해 한 명령의 답으로 바꿉니다. 공고가 우대하는 '복잡한 데이터를 구조화해서 제품이나 운영에 활용해본 경험'과 '데모가 아니라 실제 현장에서 작동하는 제품'이 여기서 같은 지점을 가리킵니다. 다만 이 포트폴리오가 보여주는 것은 추출본 적재·유한능력 배정 계산·반사실 재계산 요인 분해 기술이며, 인포시즈가 실제로 다루는 제조 현장의 생산 운영 지식이나 납기 협의의 의사결정 구조 같은 도메인 전문성은 주장하지 않습니다. 그 깊이는 면접에서 모르면 모른다고 말하는 편이 낫습니다.
정리된 문제를 받는 게 아니라 AI·데이터 솔루션을 실제 현장 운영 환경에 붙여 안정적으로 정착시킵니다. 고객사 담당자가 매일 손으로 하던 납기 회신 계산을 한 명령으로 대체하는 도구가 직접 정렬됩니다.
고객의 업무 흐름과 데이터 구조를 빠르게 이해해 모델링하고 운영에 활용합니다. 고객사 추출본 세 벌을 하나의 배정 계산이 먹을 수 있는 형태로 모델링하는 일이 정렬됩니다.
현장에서 생기는 예외와 불확실성을 피하지 않고 기술로 처리해 제품·시스템 개선으로 잇습니다. 표준공수 미등록·수량 오류·과거 납기 같은 계산 불가 건을 추측하지 않고 분리하는 설계가 정렬됩니다.
고객사에서 받은 추출본 세 벌(수주 목록·품목 표준공수·라인 캘린더)을 입력으로 받아, 주문마다 출하 가능일과 지연 날수를 계산해 터미널 표로 답하는 CLI입니다. 계산은 정해진 산술로만 돕니다. 소요 시간은 수량에 품목 표준 사이클타임을 곱하고 준비시간을 더해 구하며, 라인별 가용 분을 날짜 순서대로 소진해 마지막으로 소진한 날이 출하 가능일이 됩니다. 지연 날수는 그 날짜에서 희망 납기를 뺀 값이고, 지연의 요인 기여는 선행 주문을 뺀 조건·휴무를 뺀 조건·자기 작업만 남긴 조건으로 각각 다시 계산해 며칠이 당겨지는지로 정합니다. 표준공수가 없는 품목이나 수량이 0 이하인 주문은 추측하지 않고 계산 불가로 분리합니다. 규칙은 그날 받은 추출본을 보고 한 사람이 쓰는 설정 파일에 담기므로, 고객사와 합의해야 나오는 표준 체계나 사전을 전제하지 않습니다. LLM 은 2주차에 수주 비고란의 자유 문장을 제약 후보로 옮기는 보조로만 붙고 날짜와 날수에는 개입하지 않습니다. 화면은 만들지 않습니다. 한 명령으로 시작해 터미널 표로 끝나고, 같은 표를 CSV 한 벌로 남깁니다.
인포시즈 FDE. 고객사 공장에 나가 생산관리 담당자 옆에서 일하며, 담당자가 새 주문이 들어올 때마다 라인 캘린더와 표준공수 표를 엑셀에서 오가며 손으로 더해 출하일을 회신하고 늦어진 이유는 감으로 설명하던 일을, 한 명령의 계산 결과로 받아 고객과의 납기 협의에 들고 가고 싶은 사람입니다.
고객사 추출본 세 벌을 한 스키마로 모으고 배정 규칙을 산술로 고정하면, (a) 주문별 출하 가능일과 지연 날수를 사람이 손으로 더한 것과 같은 근거로 계산하고, (b) 지연이 선행 주문·휴무·자기 작업 중 무엇 때문인지 반사실 재계산으로 쪼개며, (c) 표준공수 미등록·수량 오류 같은 계산 불가 건을 추측 없이 분리해 낼 수 있습니다.
고객사 추출본을 가정한 합성 파일 세 벌을 넣으면 한 명령으로 주문별 출하 가능일·지연 날수·요인 기여가 터미널 표로 나오고 같은 표가 CSV 로 남는 CLI입니다. 만드는 덩어리는 캘린더를 소진하는 배정 계산 엔진과 반사실 재계산 요인 분해 둘이고, 이 주차는 LLM 없이 산술만으로 돕니다. 평일 5일에 혼자 끝나는 범위이며 그 자체로 제출 가능한 완결품입니다.
주문 60건에 심어 둔 정답 출하일·지연 날수와 계산 결과를 대조해 일치율과 평균 절대 오차를 내는 회귀 채점기, 그리고 수주 비고란의 자유 문장을 제약 후보 파일로 뽑아 FDE 가 승인한 항목만 계산에 넣는 보조 단계입니다.
주문 수천 건 규모의 처리 시간을 측정하고, Docker 이미지 한 장으로 고객사 사내 장비에서 그대로 실행하며, 잔업 승인·대체 라인 투입·납기 재협의 세 대안을 각각 다시 계산해 며칠이 당겨지는지 비교해 주는 상태입니다.
고객사 추출본을 가정한 주문 60건과 라인 3개 캘린더를 넣으면 배정 계산과 요인 분해가 몇 초 안에 끝나 터미널 표로 나오는 걸 시연합니다
일부러 만든 악성·결측 입력 30종(표준공수 미등록·수량 0과 음수·과거 희망 납기·휴무 연속·라인 미지정·단위 혼재)을 넣어도 출력 형식이 한 번도 안 깨지고, 계산 불가 건은 사유를 달아 따로 빼냅니다
2주차 회귀 채점에서 심은 정답 출하일 60건 중 58건이 일치했고(약 97%), 지연 날수 평균 절대 오차는 0.1일입니다. 단, 정답과 데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 납기 회신 정확도는 인포시즈 고객사의 실제 수주 이력·실제 라인 캘린더와 담당자의 확인이 있어야 측정 가능합니다. 이 도구는 그 검증을 바로 돌릴 수 있는 상태로 만듭니다
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 휴무가 연속으로 끼는 구간·정기보전 반일·최소 로트 미만 수량·대체 라인 선택·과거 희망 납기 같은 경계 케이스를 더미에 일부러 섞어, 쉬운 주문만 통과시키는 게 아님을 보여줍니다
이 포트폴리오가 보여주는 것은 고객사 추출본 적재·유한능력 배정 계산·반사실 재계산 요인 분해·회귀 채점 기술입니다. 인포시즈가 다루는 특정 제조 현장의 생산 운영 지식이나 납기 협의의 의사결정 구조 같은 도메인 전문성은 포트폴리오로 증명되지 않으므로 주장하지 않으며, 그 깊이는 면접에서 모르면 모른다고 말하는 편이 낫습니다. 데모는 일반적인 라인·품목 구성으로 계산 기술만 보여줍니다
실제 공장의 배정은 여기 쓴 규칙보다 복잡합니다. 이 도구는 우선순위와 소요 시간 계산식을 설정 파일로 드러내 놓고, 규칙이 다르면 파일만 바꿔 다시 돌리게 만듭니다. 규칙이 맞는지는 계산이 아니라 담당자 확인으로 정한다는 점을 결과 표 머리말에 적습니다
LLM 이 비고 문장에서 뽑은 제약은 틀릴 수 있습니다. 후보는 원문 문장을 근거로 함께 싣고 FDE 가 설정 파일에서 승인한 것만 계산에 들어가며, 승인 전 후보는 결과에 영향을 주지 않습니다. 회신 문안도 계산 결과 표에 있는 날짜만 인용하게 강제하고 대조에 실패한 문장은 막습니다
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 ERP 에서 내려받은 수주 목록 추출본. 배정 계산이 가장 먼저 읽는 표입니다. 수량 오류·과거 희망 납기·라인 미지정·신규 품목 같은 경계 케이스를 일부러 섞고, gt_ship_date 와 gt_delay_days 로 정답을 심어 회귀 채점에 씁니다.
| order_id | customer | item_code | qty | due_date | line_pref | note | gt_ship_date | gt_delay_days |
|---|---|---|---|---|---|---|---|---|
| so_001 | 대한정밀 | IT-100 | 500 | 2026-03-13 | L1 | 2026-03-12 | 0 | |
| so_002 | 대한정밀 | IT-100 | 800 | 2026-03-13 | L1 | 가능하면 12일 오전까지 부탁드립니다 | 2026-03-16 | 3 |
| so_003 | 세영기공 | IT-220 | 300 | 2026-03-16 | — | 라인 지정 없음 | 2026-03-16 | 0 |
| so_004 | 세영기공 | IT-900 | 200 | 2026-03-17 | L2 | 신규 품목이라 표준 등록 전입니다 | — | — |
| so_005 | 한빛전자 | IT-310 | 1,200 | 2026-03-18 | L2 | 분할 납품 가능합니다 | 2026-03-20 | 2 |
아래 JSON Schema 에 맞는 고객사 수주 추출본 60행을 JSON 배열로 생성합니다. 고객사 4~5곳, 품목 코드는 item_capacity 에 있는 것 위주, 희망 납기는 2026-03-09 부터 2026-04-03 사이, 라인은 L1·L2·L3 중 하나이거나 null 입니다. gt_ship_date 규칙: 희망 납기 오름차순(같으면 주문번호 순)으로 라인마다 순서대로 배정하고, 소요 분은 수량을 최소 로트 단위로 올린 뒤 표준 사이클타임을 곱해 준비시간을 더한 값이며, 라인 캘린더의 가용 분을 날짜 순서대로 소진해 마지막으로 소진한 날이 gt_ship_date 입니다. gt_delay_days 는 gt_ship_date 에서 희망 납기를 뺀 달력일이고 음수면 0 으로 둡니다. 표준 사이클타임이 없는 품목, 수량이 0 이하인 주문은 gt_ship_date 와 gt_delay_days 를 모두 null 로 둡니다.
{"type":"object","properties":{"order_id":{"type":"string"},"customer":{"type":"string"},"item_code":{"type":"string"},"qty":{"type":"integer"},"due_date":{"type":"string"},"line_pref":{"type":["string","null"]},"note":{"type":"string"},"gt_ship_date":{"type":["string","null"]},"gt_delay_days":{"type":["integer","null"]}},"required":["order_id","customer","item_code","qty","due_date","note"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 주문만 통과시키는 함정 회피): (1) 표준 사이클타임이 등록되지 않은 신규 품목 2건, (2) 수량이 0 인 행과 음수인 행 각 1건, (3) 희망 납기가 데이터 시작일보다 과거인 행 2건, (4) line_pref 가 null 이라 대체 라인 중 부하가 낮은 쪽을 골라야 하는 행 3건 이상, (5) 최소 로트 미만 수량이라 로트 단위로 올려야 하는 행 2건, (6) 같은 희망 납기가 3건 이상 겹쳐 주문번호로 순서를 나눠야 하는 묶음 1개, (7) note 에 '선출하 요청'·'분할 납품 가능'·'특정일 이후 입고' 같은 자유 문장이 든 행 4건 이상. gt 값은 위 규칙대로 정직하게 계산하고, JSON 배열만 출력합니다.{"type":"object","properties":{"order_id":{"type":"string"},"customer":{"type":"string"},"item_code":{"type":"string"},"qty":{"type":"integer"},"due_date":{"type":"string"},"line_pref":{"type":["string","null"]},"note":{"type":"string"},"gt_ship_date":{"type":["string","null"]},"gt_delay_days":{"type":["integer","null"]}},"required":["order_id","customer","item_code","qty","due_date","note"]}품목별 생산 가능 라인과 표준 사이클타임·준비시간·최소 로트를 담은 마스터 추출본. 소요 분 계산식이 참조하며, 표준 사이클타임이 비어 있으면 그 주문은 계산 불가로 빠집니다. 같은 품목이 라인마다 다른 사이클타임을 갖는 경우와 조합 자체가 없는 경우를 함께 담습니다.
| item_code | line_id | std_min_per_unit | setup_min | min_lot |
|---|---|---|---|---|
| IT-100 | L1 | 0.8 | 30 | 100 |
| IT-100 | L2 | 1 | 30 | 100 |
| IT-220 | L1 | 1.5 | 45 | 100 |
| IT-220 | L2 | 1.2 | 45 | 100 |
| IT-220 | L3 | 1.3 | 45 | 100 |
아래 JSON Schema 에 맞는 품목 표준공수 마스터 24행을 JSON 배열로 생성합니다. 품목 코드는 IT-100 형식으로 10개 안팎, 라인은 L1·L2·L3 이며 한 품목이 여러 라인에 걸칠 수 있습니다. std_min_per_unit 는 0.5 에서 2.5 사이, setup_min 은 20 에서 60 사이, min_lot 은 50·100·200 중 하나입니다.
{"type":"object","properties":{"item_code":{"type":"string"},"line_id":{"type":"string"},"std_min_per_unit":{"type":["number","null"]},"setup_min":{"type":"integer"},"min_lot":{"type":"integer"}},"required":["item_code","line_id","setup_min","min_lot"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라: (1) std_min_per_unit 이 null 인 신규 품목 2건, (2) 같은 품목이 라인마다 사이클타임이 다른 조합 3쌍 이상, (3) 수주에는 등장하지만 마스터에는 라인 조합이 하나뿐이라 대체 라인을 고를 수 없는 품목 2건, (4) min_lot 이 200 이라 소량 주문이 크게 올림되는 품목 2건. JSON 배열만 출력합니다.{"type":"object","properties":{"item_code":{"type":"string"},"line_id":{"type":"string"},"std_min_per_unit":{"type":["number","null"]},"setup_min":{"type":"integer"},"min_lot":{"type":"integer"}},"required":["item_code","line_id","setup_min","min_lot"]}라인별 일자별 가용 분을 담은 캘린더 추출본. 배정 계산이 날짜 순서대로 소진하는 대상이며, 지연 요인 중 휴무 기여를 반사실 재계산할 때도 이 표를 갈아 끼웁니다. 휴무·정기보전 반일·정전·잔업 승인처럼 가용 분이 흔들리는 날을 함께 담습니다.
| line_id | cal_date | available_min | reason |
|---|---|---|---|
| L1 | 2026-03-09 | 960 | — |
| L1 | 2026-03-10 | 960 | — |
| L1 | 2026-03-12 | 480 | 2조 결원으로 주간만 가동 |
| L1 | 2026-03-15 | 0 | 일요일 휴무 |
| L2 | 2026-03-09 | 960 | — |
아래 JSON Schema 에 맞는 라인 캘린더 90행을 JSON 배열로 생성합니다. 라인 L1·L2·L3 에 대해 2026-03-09 부터 2026-04-03 까지 하루 한 행씩 만들고, 평일 2교대는 960, 주간만 가동하면 480, 휴무·정전은 0, 잔업 승인일은 1140 을 씁니다. reason 은 가용 분이 기본값과 다를 때만 채우고 평시에는 null 로 둡니다.
{"type":"object","properties":{"line_id":{"type":"string"},"cal_date":{"type":"string"},"available_min":{"type":"integer"},"reason":{"type":["string","null"]}},"required":["line_id","cal_date","available_min"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라: (1) 휴무가 이틀 이상 연속되는 구간 2개(연휴), (2) 정기보전으로 가용 분이 240 인 반일 3건, (3) 정전·설비 사고로 예고 없이 0 이 되는 날 2건, (4) 잔업 승인으로 가용 분이 1140 인 날 3건, (5) 한 라인만 며칠 통째로 행이 빠져 캘린더에 구멍이 있는 구간 1개(그 라인은 그 기간 가동 불가로 봅니다). JSON 배열만 출력합니다.{"type":"object","properties":{"line_id":{"type":"string"},"cal_date":{"type":"string"},"available_min":{"type":"integer"},"reason":{"type":["string","null"]}},"required":["line_id","cal_date","available_min"]}| Python | 추출본 적재·배정 계산·요인 분해·회귀 채점을 모두 구현하는 언어입니다 |
| pandas | 고객사 엑셀·CSV 추출본을 읽어 표기 흔들림과 자료형을 정리하는 적재 단계를 맡습니다 |
| SQLite | 추출본 세 벌을 파일 하나에 올려 배정 계산이 같은 질의로 반복 재현되게 합니다 |
| Pydantic | 입력 세 벌과 출력 답변 카드를 JSON Schema 로 고정해 형식이 깨진 행을 계산 전에 걸러냅니다 |
| Typer | 한 명령으로 시작해 터미널 표로 끝나는 CLI 인터페이스와 옵션을 만듭니다 |
| pytest | 휴무 연속·과거 납기·최소 로트 미만 같은 경계 케이스를 회귀 테스트로 고정합니다 |
| Docker | 고객사 사내 장비에서 설치 없이 같은 결과가 나오도록 실행 환경을 이미지 한 장으로 담습니다 |
| LLM | 수주 비고란의 자유 문장을 제약 후보로 옮기고 회신 문안 초안을 쓰는 보조를 맡습니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(회귀 채점과 비고란 제약 보조)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(고객사 규모 처리와 대안 비교 계산)로 진행합니다.
주문 1건의 출하 가능일 답변 카드. 계산된 출하일과 지연 날수, 요인별 기여 일수, 계산 근거, 계산 불가 사유를 한 스키마로 담아 터미널 표 출력과 회귀 채점에 함께 씁니다. 날짜와 날수는 전부 산술이 정하고 LLM 은 개입하지 않습니다.
{"type":"object","properties":{"order_id":{"type":"string"},"line_id":{"type":["string","null"]},"due_date":{"type":"string"},"ship_date":{"type":["string","null"]},"delay_days":{"type":["integer","null"]},"required_min":{"type":["number","null"]},"factor_days":{"type":"object","properties":{"prior_orders":{"type":"integer"},"calendar_closed":{"type":"integer"},"own_work":{"type":"integer"},"residual":{"type":"integer"}},"required":["prior_orders","calendar_closed","own_work","residual"]},"evidence":{"type":"string","minLength":8},"uncomputable_reason":{"type":["string","null"],"enum":["no_standard_time","invalid_qty","no_line_for_item","calendar_missing",null]},"hedge":{"type":["string","null"]}},"required":["order_id","due_date","ship_date","delay_days","factor_days","evidence"]}[
{
"input_ref": "so_002 · IT-100 800개 · L1 · 희망 납기 2026-03-13",
"output": {
"order_id": "so_002",
"line_id": "L1",
"due_date": "2026-03-13",
"ship_date": "2026-03-16",
"delay_days": 3,
"required_min": 670,
"factor_days": {
"prior_orders": 2,
"calendar_closed": 1,
"own_work": 0,
"residual": 0
},
"evidence": "소요 670분(800개×0.8분+준비 30분), L1 가용 소진 03-12 480분→03-13 이후 잔여, 선행 so_001 제거 시 03-14 출하(2일 당김), 03-15 휴무 제거 시 03-15 출하(1일 당김)",
"uncomputable_reason": null,
"hedge": null
}
},
{
"input_ref": "so_008 · IT-310 600개 · L2 · 희망 납기 2026-03-20",
"output": {
"order_id": "so_008",
"line_id": "L2",
"due_date": "2026-03-20",
"ship_date": "2026-03-23",
"delay_days": 3,
"required_min": 380,
"factor_days": {
"prior_orders": 0,
"calendar_closed": 2,
"own_work": 1,
"residual": 0
},
"evidence": "소요 380분(600개×0.6분+준비 20분), L2 03-21과 03-22 가용 0분(주말 휴무), 휴무 제거 시 03-21 출하(2일 당김), 자기 작업만 남기면 03-22 출하(1일 당김)",
"uncomputable_reason": null,
"hedge": "잔업이 승인되면 03-21 출하가 가능하며 대안 비교 계산으로 확인합니다"
}
},
{
"input_ref": "so_004 · IT-900 200개 · L2 · 표준 사이클타임 미등록",
"output": {
"order_id": "so_004",
"line_id": "L2",
"due_date": "2026-03-17",
"ship_date": null,
"delay_days": null,
"required_min": null,
"factor_days": {
"prior_orders": 0,
"calendar_closed": 0,
"own_work": 0,
"residual": 0
},
"evidence": "item_capacity 에 IT-900·L2 의 std_min_per_unit 이 null 이라 소요 분을 구할 수 없어 배정에서 제외했습니다",
"uncomputable_reason": "no_standard_time",
"hedge": "표준 사이클타임을 담당자에게 확인해 등록한 뒤 다시 계산해야 합니다"
}
}
][자동 검증] 1. 출력이 JSON Schema(필드·enum·minLength)를 통과하는지 확인합니다. 2. required_min 이 계산식(최소 로트로 올린 수량 × 표준 사이클타임 + 준비시간)과 정확히 일치하는지 다시 계산해 대조합니다. 3. ship_date 가 라인 캘린더의 가용 분을 날짜 순서대로 소진한 결과와 일치하는지, delay_days 가 ship_date 에서 due_date 를 뺀 달력일과 같은지(음수는 0) 확인합니다. 4. factor_days 의 각 값이 해당 요인을 제거하고 다시 돌린 결과와 원래 ship_date 의 차이와 같은지 확인하고, 세 값의 합과 delay_days 의 차이가 residual 로 정확히 남는지 봅니다. 5. ship_date 가 null 인 행은 uncomputable_reason 이 반드시 채워져 있고, 반대로 사유가 있는 행에 날짜가 남아 있지 않은지 확인합니다. 6. 심은 정답 gt_ship_date·gt_delay_days 와 비교해 일치율과 지연 날수 평균 절대 오차를 계산합니다. [수동 검증] 1. 지연이 큰 상위 10건을 사람이 캘린더와 함께 짚어 요인 기여가 납득되는지 확인합니다. 2. 전체의 5% 를 뽑아 손계산과 맞춰 봅니다.