비하Forward Deployed Engineer (FDE) 경력직
3.0 (3)비하베스트
경력근거: 대형 제조사의 매출채권을 신뢰 가능한 방식으로 금융 상품화하고, 새로운 자금 흐름을 만들려면 무엇이 필요한가
어제 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
Altus(비하베스트)는 기관 고객의 외주 파트너가 아니라 공동 빌더로 일하고, FDE 가 실제로 마주하는 질문 중 하나가 대형 제조사의 매출채권을 신뢰 가능한 방식으로 금융 상품화해 새로운 자금 흐름을 만드는 일입니다. 그 첫걸음은 고객사 재무팀이 ERP 에서 내려받은 채권 원장을 계약 조건표대로 계산해 무엇이 되고 무엇이 안 되는지를 같은 표에서 합의하는 일이라, 이 도구는 파견 첫 주에 실제로 손에 쥐고 시작할 물건입니다. 제가 이 포트폴리오로 보여주는 것은 고객사의 지저분한 엑셀을 파싱해 조건표 규칙과 금액 계산을 결정론으로 돌리고 판정 근거를 원문 문구로 되짚는 엔지니어링 기술입니다. 스테이블코인 결제나 실물 자산 토큰화, 규제 대응 같은 블록체인 금융 인프라 도메인의 전문성을 갖췄다고 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
FDE 는 고객 비즈니스의 핵심이 되는 자산, 거래, 데이터, 권한, 감사 흐름을 온·오프체인에 걸쳐 직접 모델링하고 통합해, 핵심 로직이 정확하게 도는 시스템으로 만듭니다. 매출채권을 자금 흐름으로 바꾸는 일도 원장 데이터 모델링에서 시작합니다.
고객의 요구사항에 맞는 custom application, internal tool, API, integration layer 를 직접 설계하고 개발해 출시까지 책임집니다. 자료를 정리해 넘기는 역할이 아니라 고객사 담당자가 매달 여는 화면을 만드는 역할입니다.
고객사의 기술팀과 경영진, 법무 및 규제 전문가, 감사 파트너와 직접 소통하며 문제를 정의하고 해결 방향을 맞춥니다. 그래서 판정 결과에는 항상 어느 계약 문구 때문인지가 함께 붙어야 대화가 됩니다.
제조사 고객사의 매출채권 원장 엑셀과 계약 조건표를 입력으로 받아, 자금화 가능한 채권과 제외 사유, 조달 가능 금액과 월별 회수 일정을 계산해 한 화면에서 보여주는 내부 운영 도구입니다. 판정은 조건표 규칙과 금액 계산으로 결정하고, LLM 은 표기 흔들림 정규화 후보와 문서 문안 작성만 맡습니다.
매달 ERP 에서 채권 원장을 내려받아 자금화 대상을 추리는데, 어느 채권이 왜 빠졌는지와 돈이 언제 들어오는지를 회의 때마다 엑셀을 다시 뜯어 설명하고 있는 제조사 재무팀의 자금 담당자입니다.
제외 사유가 계약 조건표의 원문 문구로 고정되면, 자금화 대상 논의가 담당자 해석을 맞추는 자리에서 조건을 어떻게 바꿀지 정하는 자리로 바뀝니다. 판정과 금액 계산을 규칙으로 돌리고 애매한 건만 사람에게 남기면 한 달치 원장을 회의 전에 한 번에 훑습니다.
고객사 ERP 연동 없이 내려받은 엑셀 파일 입력을 가정하고, 300행짜리 원장과 10줄짜리 조건표로 적격·제외 판정, 제외 사유의 계약 원문 인용, 조달 가능 금액과 월별 회수 일정을 내는 웹 콘솔을 Vercel 에 올려 링크로 제출합니다.
채무자 표기 흔들림과 미등록 채무자, 결측 증빙을 Claude Haiku 4.5 가 정규화 후보로 제안하고 담당자가 확인하는 검토 큐를 붙여, 확인 전후로 판정이 달라진 건을 나란히 보여줍니다.
선지급률과 할인율, 만기 한도를 바꿔 조달 금액과 회수 시점을 비교하는 시나리오 화면과 고객 미팅용 요약 문서 내보내기를 붙이고, 규칙 변경 이력으로 판정이 언제 왜 달라졌는지 되짚습니다.
고객사 원장 엑셀 300행과 계약 조건표 10줄을 넣으면 자금화 가능 채권 목록, 제외 사유별 건수, 조달 가능 금액 합계, 월별 회수 일정표가 한 화면에 나오는 흐름을 처음부터 끝까지 시연합니다.
제외 사유마다 조건표의 원문 문구와 규칙 번호가 붙어, 어느 문장 때문에 빠졌는지를 건별로 짚어 보여줍니다. 같은 입력에 항상 같은 판정과 같은 금액이 나오는지는 스냅샷 테스트 40건으로 확인합니다. 다만 정답도 조건표도 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건에서의 동작 확인입니다.
결측 증빙과 채무자 표기 흔들림, 미등록 채무자, 만기 경계일, 외화 표기를 섞은 하드 케이스 30종을 넣어도 출력 형식이 깨지지 않고, 억지 판정 대신 확인 필요로 분리되는 비율을 보여줍니다.
2주차에는 정규화 후보 제안과 담당자 확인이 얼마나 겹쳤는지를 Cohen's κ(두 판단자가 우연을 넘어 얼마나 일치했는지 재는 -1~1 지표로, 1에 가까울수록 일치)로 재고 어긋난 건을 유형별로 모아 규칙을 고칩니다. 이 값도 작성자가 만든 더미 기준입니다.
위 수치는 전부 더미데이터 자가채점이며, 실제 판정 정확도와 조달 금액의 적정성은 비하베스트 고객사의 실제 채권 원장과 계약서, 재무·법무 검토자가 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태로 만듭니다.
수치는 전부 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모가 도는 상태와 실검증을 바로 붙일 준비가 된 상태로 솔직하게 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 결측 증빙, 같은 채무자의 세 가지 표기, 만기 경계일, 외화 건, 수치 기준이 없는 조건 문구를 더미에 일부러 섞어 두었습니다.
계약 문구 해석은 원래 법무 검토 영역입니다. 이 도구는 조건표에 수치로 적힌 규칙만 계산하고, 문구에 기준이 없으면 판정을 만들지 않고 확인 필요로 남깁니다.
이 포트폴리오가 보여주는 것은 지저분한 엑셀 파싱과 규칙·금액 계산, 근거 추적이라는 엔지니어링입니다. 실물 자산 토큰화나 스테이블코인 결제 같은 블록체인 금융 도메인 전문성은 주장하지 않으며, 모르는 깊이는 면접에서 모른다고 말합니다.
실제 도입 때는 고객사마다 컬럼명과 소계 행 모양이 다르고 채무자 마스터도 따로 있어, 매핑 프로파일을 먼저 맞추는 작업이 앞에 붙습니다. 조건표도 계약이 개정될 때마다 바뀌므로 규칙 변경 이력이 함께 필요합니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
제조사 고객사가 ERP 에서 내려받아 보내는 매출채권 원장입니다. 자금화 판정과 회수 일정 계산의 입력이며, 실제 파일이 그렇듯 표기가 흔들리고 값이 비어 있는 행을 섞어 두었습니다.
| invoice_no | debtor_raw | debtor_id | issue_date | due_date | amount | currency | payment_terms_raw | tax_invoice_no | overdue_days | status_raw | memo |
|---|---|---|---|---|---|---|---|---|---|---|---|
| INV-2026-0412 | (주)한성정밀 | D-1007 | 2026-05-12 | 2026-08-10 | 184,500,000 | KRW | 월말 마감 익월 25일 지급 | T-2026-0512-118 | 0 | 정상 | — |
| INV-2026-0418 | 한성정밀㈜ | — | 2026-05-19 | 2026-08-17 | 62,400,000 | KRW | 월말 마감 익월 25일 지급 | T-2026-0519-204 | 0 | 정상 | 지점 발행 건 |
| INV-2026-0431 | 대영기계 | D-1042 | 2026-05-28 | 2026-11-30 | 97,800,000 | KRW | 검수 완료 후 180일 | T-2026-0528-061 | 0 | 정상 | — |
| INV-2026-0447 | 세종테크(주) | D-1015 | 2026-06-02 | 2026-08-31 | 45,300,000 | KRW | 익월 말일 | — | 0 | 정상 | 세금계산서 재발행 대기 |
| INV-2026-0455 | 우성모빌리티 | D-1088 | 2026-04-15 | 2026-06-30 | 133,000,000 | KRW | 월말 마감 익월 말일 | T-2026-0415-330 | 37 | 입금대기 | 부분 협의 중 |
아래 JSON Schema 를 그대로 만족하는 매출채권 원장 행을 40개 더 만들어 주세요. 한국 제조업 고객사가 ERP 에서 내려받은 파일이라고 가정하고, 채무자는 5~8개 회사 안에서 반복해 등장하게 합니다.
{"type":"object","properties":{"invoice_no":{"type":"string"},"debtor_raw":{"type":"string"},"debtor_id":{"type":["string","null"]},"issue_date":{"type":"string"},"due_date":{"type":"string"},"amount":{"type":"number"},"currency":{"type":"string","enum":["KRW","USD"]},"payment_terms_raw":{"type":["string","null"]},"tax_invoice_no":{"type":["string","null"]},"overdue_days":{"type":["integer","null"]},"status_raw":{"type":"string"},"memo":{"type":["string","null"]}},"required":["invoice_no","debtor_raw","issue_date","due_date","amount","currency","status_raw"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어 주세요. (1) 결측: debtor_id 가 null 인 미등록 채무자 5건, tax_invoice_no 가 null 인 증빙 누락 4건, overdue_days 가 null 인 집계 미반영 3건, payment_terms_raw 가 null 인 행 2건. (2) 경계값: 만기가 발행일로부터 정확히 90일인 행 2건, amount 가 30000000 원 정확히인 행 2건, amount 가 0 인 반품 정산 행 1건. (3) 미등록·중복: 같은 tax_invoice_no 를 쓰는 두 행 1쌍, 금액과 만기가 같은 중복 발행 의심 행 1쌍. (4) 표기 불일치: 같은 채무자를 (주)OO, OO㈜, 영문 상호 세 가지로 쓴 행을 각각 넣고, status_raw 에 한국어 값과 영어 값(clearing, pending)을 섞습니다. (5) 통화: USD 건 3건을 넣어 환산이 필요한 상황을 만듭니다.
추가로 형식을 깨뜨리려는 시도 3건을 별도 목록으로 만들어 주세요. amount 를 "184,500,000" 문자열로 넣기, due_date 를 2026.09.13 형식으로 넣기, currency 를 "원" 으로 넣기 같은 행이며, 이 3건은 스키마를 통과하지 못하는 입력으로 파서가 거부하는지 확인하는 용도입니다.{"type":"object","properties":{"invoice_no":{"type":"string"},"debtor_raw":{"type":"string"},"debtor_id":{"type":["string","null"]},"issue_date":{"type":"string"},"due_date":{"type":"string"},"amount":{"type":"number"},"currency":{"type":"string","enum":["KRW","USD"]},"payment_terms_raw":{"type":["string","null"]},"tax_invoice_no":{"type":["string","null"]},"overdue_days":{"type":["integer","null"]},"status_raw":{"type":"string"},"memo":{"type":["string","null"]}},"required":["invoice_no","debtor_raw","issue_date","due_date","amount","currency","status_raw"]}고객사와 합의한 자금화 프로그램 조건표입니다. 계약서와 메일에 흩어져 있던 문구를 규칙 한 줄씩으로 옮긴 것이며, 판정의 정답은 전부 이 표에서 결정됩니다.
| rule_id | rule_type | threshold | unit | source_quote | effective_from | note |
|---|---|---|---|---|---|---|
| R-01 | 만기한도 | 90 | 일 | 매입 대상 채권의 만기일은 양도일로부터 90일 이내여야 한다. | 2026-01-01 | — |
| R-02 | 만기한도 | 120 | 일 | 성수기(6월부터 8월)에 한하여 만기 120일 채권까지 편입할 수 있다. | 2026-06-01 | R-01 과 적용 기간이 겹쳐 어느 규칙이 우선인지 확인이 필요합니다. |
| R-03 | 연체 | 0 | 일 | 연체 이력이 있는 채무자의 채권은 대상에서 제외한다. | 2026-01-01 | — |
| R-04 | 연체 | 15 | days | 15 days 이상 지연된 채권은 재심사 후 편입 여부를 결정한다. | 2026-03-01 | 단위 표기가 영문이라 R-03 과 같은 기준으로 묶어야 합니다. |
| R-05 | 집중도 | 30 | % | 단일 채무자에 대한 편입 잔액은 프로그램 총 잔액의 30%를 초과할 … | 2026-01-01 | — |
아래 JSON Schema 를 그대로 만족하는 프로그램 조건표 규칙을 20개 더 만들어 주세요. 계약서와 합의 메일에서 옮겨 적은 문장이라고 가정하고, source_quote 는 실제 계약 문서처럼 한 문장으로 씁니다.
{"type":"object","properties":{"rule_id":{"type":"string"},"rule_type":{"type":"string","enum":["만기한도","연체","집중도","증빙","통화","최소금액","선지급률","할인율"]},"threshold":{"type":["number","null"]},"unit":{"type":["string","null"]},"source_quote":{"type":"string"},"effective_from":{"type":"string"},"note":{"type":["string","null"]}},"required":["rule_id","rule_type","source_quote","effective_from"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어 주세요. (1) 결측: threshold 가 null 인 규칙 4건을 넣어 문구는 있으나 수치 기준이 없는 상황을 만듭니다. (2) 상충: 같은 rule_type 인데 effective_from 과 threshold 가 다른 규칙 쌍을 3쌍 넣습니다. (3) 표기 불일치: unit 을 일과 days, %와 퍼센트, 원과 KRW 로 섞어 씁니다. (4) 경계 문구: 범위나 예외가 붙은 문장(90일 이내, 연장 시 120일까지 같은 문구)을 3건 넣어 한 문장에서 수치가 둘 나오게 합니다. (5) 이력: 같은 rule_id 계열이 개정된 것처럼 effective_from 이 다른 후속 버전을 2건 넣습니다.
추가로 형식을 깨뜨리려는 시도 2건을 별도 목록으로 만들어 주세요. rule_type 을 목록에 없는 값으로 넣기, threshold 를 "90일" 문자열로 넣기이며, 파서가 이 입력을 거부하는지 확인하는 용도입니다.{"type":"object","properties":{"rule_id":{"type":"string"},"rule_type":{"type":"string","enum":["만기한도","연체","집중도","증빙","통화","최소금액","선지급률","할인율"]},"threshold":{"type":["number","null"]},"unit":{"type":["string","null"]},"source_quote":{"type":"string"},"effective_from":{"type":"string"},"note":{"type":["string","null"]}},"required":["rule_id","rule_type","source_quote","effective_from"]}| TypeScript | 조건표 규칙과 채권·채무자 도메인 타입을 한 곳에 정의해 규칙 엔진과 계산 모듈, 화면이 같은 타입을 씁니다. 판정 결과 타입이 바뀌면 화면이 먼저 컴파일 에러로 알려 줍니다. |
| Next.js | 채권 목록과 제외 사유, 월별 회수 일정 세 화면을 렌더링하고 1주차 결과를 Vercel 로 배포해 링크 하나로 보여줍니다. |
| Golang | 수만 행짜리 원장을 배치로 훑는 계산기를 별도 CLI로 둡니다. 화면 없이도 월 마감 시점에 같은 판정을 돌려 결과 파일을 남깁니다. |
| Rust | 금액 계산 모듈에 씁니다. 원 단위 고정소수 연산과 외화 환산, 선지급률·할인율 계산에서 반올림이 생기는 지점을 한 곳으로 고정해 합계가 흔들리지 않게 합니다. |
| LLM (Claude Haiku 4.5) | 채무자 표기 흔들림과 결제조건 자유서술을 정규화 후보로 바꾸고, 조건표 문구에서 수치 기준을 뽑아 규칙 초안을 제안합니다. 최종 판정은 규칙 엔진이 하고 LLM 출력은 사람이 확인한 뒤에만 반영됩니다. |
| 코딩 에이전트 (Claude Code) | 조건표를 바꿀 때마다 판정 회귀 스냅샷 테스트를 다시 만들고 달라진 건을 요약하는 일에 씁니다. 하루 작업 흐름에 코딩 에이전트를 붙여 규칙 변경의 영향 범위를 매번 확인합니다. |
| PostgreSQL | 원장 스냅샷과 채무자 마스터, 조건표 버전, 판정 결과를 저장해 어느 조건표 버전으로 낸 판정인지 되짚습니다. |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 표기 흔들림과 미등록 채무자를 사람이 확인하는 검토 큐를 2주차에 붙입니다.
✓ pass → 여기까지도 완결입니다. 더 키우려면 조건을 바꿔 조달 금액을 비교하는 시나리오 화면을 3주차에 붙입니다.
채권 한 건에 대한 판정 결과입니다. 자금화 가능 여부와 제외 사유, 조달 가능 금액과 회수 예정일을 담고, 제외 사유마다 어느 규칙의 어느 계약 문구 때문인지를 함께 남깁니다.
{"type":"object","properties":{"invoice_no":{"type":"string"},"status":{"type":"string","enum":["자금화 가능","제외","확인 필요"]},"excluded_reasons":{"type":"array","items":{"type":"object","properties":{"rule_id":{"type":"string"},"observed":{"type":"string"},"threshold":{"type":["string","null"]},"source_quote":{"type":"string"}},"required":["rule_id","observed","source_quote"]}},"advance_amount_krw":{"type":["number","null"]},"expected_settlement_date":{"type":["string","null"]},"converted_from":{"type":["string","null"]},"needs_human_check":{"type":"boolean"},"hedge":{"type":"string"}},"required":["invoice_no","status","excluded_reasons","needs_human_check","hedge"]}[
{
"invoice_no": "INV-2026-0412",
"status": "자금화 가능",
"excluded_reasons": [],
"advance_amount_krw": 156825000,
"expected_settlement_date": "2026-08-25",
"converted_from": null,
"needs_human_check": false,
"hedge": "선지급률 85%와 회수일 계산은 더미 조건표 R-09 와 결제조건 문구를 그대로 적용한 합성 기준 계산입니다. 실제 프로그램 요율과 상관례는 계약마다 다릅니다."
},
{
"invoice_no": "INV-2026-0431",
"status": "제외",
"excluded_reasons": [
{
"rule_id": "R-01",
"observed": "발행일 2026-05-28 기준 만기 186일",
"threshold": "90일",
"source_quote": "매입 대상 채권의 만기일은 양도일로부터 90일 이내여야 한다."
}
],
"advance_amount_krw": null,
"expected_settlement_date": null,
"converted_from": null,
"needs_human_check": false,
"hedge": "만기 초과는 조건표 수치로 결정되는 판정이라 사람 확인 없이 냅니다. 다만 성수기 예외 규칙 R-02 와 겹치는 기간이면 확인 필요로 올라갑니다."
},
{
"invoice_no": "INV-2026-0461",
"status": "확인 필요",
"excluded_reasons": [
{
"rule_id": "R-07",
"observed": "통화 USD, 별도 합의 문서 없음",
"threshold": null,
"source_quote": "원화 표시 채권을 원칙으로 하며, 외화 채권은 별도 합의에 따른다."
},
{
"rule_id": "R-06",
"observed": "채무자 표기 HANSUNG PRECISION CO., LTD. 가 마스터에 없어 debtor_id 미매핑",
"threshold": null,
"source_quote": "세금계산서 사본이 첨부된 채권에 한하여 매입한다."
}
],
"advance_amount_krw": null,
"expected_settlement_date": null,
"converted_from": "USD 128,000",
"needs_human_check": true,
"hedge": "조건표에 수치 기준이 없는 규칙이라 판정을 만들지 않고 담당자 확인으로 넘깁니다. 환산액을 미리 계산해 두지만 적용 환율은 합성 기준입니다."
}
][자동 검증 · 사람 손이 필요 없는 부분] 1. 출력이 JSON Schema 를 통과하는지 확인합니다. status 가 세 값 중 하나인지, 제외 판정인데 excluded_reasons 가 비어 있지 않은지를 여기서 거릅니다. 2. excluded_reasons 의 rule_id 가 조건표에 실제로 있는 규칙인지 대조해, 없는 규칙을 지어낸 출력을 떨어뜨립니다. 3. source_quote 가 조건표 원문과 글자까지 같은지 대조합니다. 요약하거나 바꿔 쓴 문구는 통과시키지 않습니다. 4. advance_amount_krw 를 액면 금액에 선지급률을 곱해 다시 계산하고 원 단위 반올림까지 같은지 비교합니다. 5. 같은 입력에 같은 판정이 나오는지 스냅샷 테스트로 비교해, 조건표를 고치지 않았는데 결과가 달라지면 실패로 잡습니다. [수동 검증 · 사람이 봐야 하는 부분] 1. 수치 기준이 없는 규칙(증빙·통화)에서 판정을 자동으로 내리지 않고 확인 필요로 남겼는지 눈으로 봅니다. 2. 같은 채무자의 세 가지 표기를 하나로 묶은 결정이 맞는지 채무자 마스터와 함께 확인합니다. 3. 만기 한도처럼 규칙이 상충하는 구간에서 어느 규칙을 적용했는지, 그 선택을 고객사와 합의했는지 확인합니다.