비하Forward Deployed Engineer (FDE) 1년 이상
3.0 (3)비하베스트
경력근거: 자산, 거래, 데이터, 권한, 감사 흐름을 직접 모델링하고
어제 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
비하베스트(Altus)는 스테이블코인 결제·실물자산 토큰화(RWA)·온체인 트레이딩에서 자산, 거래, 데이터, 권한, 감사 흐름을 production-grade 시스템으로 구현하는 co-builder 입니다. 자산의 발행부터 보관·담보·정산·상환까지 상태 전이를 규칙으로 판정하고 감사 추적을 남기는 이 원장은, Altus 가 다루는 실물자산 토큰화와 규제·감사 대응 맥락이 있어야 의미가 있습니다. 다른 도메인 데이터로는 발행에서 정산·상환으로 이어지는 상태 사슬과 감사 요건을 그대로 만들 수 없습니다. 이 포트폴리오가 보여주는 것은 TypeScript 로 상태머신·해시 체인 감사 로그·통합 레이어를 설계·구현하는 기술이며, 블록체인 코어(Cosmos 기반 EVM·Commonware·Canton)나 금융 규제 실무의 깊이는 주장하지 않습니다. 정답은 상태 전이 규칙과 원문 인용 일치로 객관 채점하고, LLM 은 노트 구조화와 리포트 요약 보조만 맡습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
비즈니스 핵심이 되는 자산, 거래, 데이터, 권한, 감사 흐름을 직접 모델링해 production-grade 시스템으로 만드는 역할입니다. 발행에서 보관·담보·정산·상환으로 이어지는 상태 전이와 감사 추적이 한 시스템으로 닫혀야 합니다.
Forward Deployed Engineer 는 고객의 요구를 custom application, internal tool, API, integration layer 로 직접 설계·개발해 출시까지 end-to-end 로 책임집니다. 추상 점검이 아니라 실제로 돌아가는 산출물이 핵심입니다.
실물 자산을 규제 요건을 충족하는 방식으로 토큰화하고 보관·감사 추적까지 하나의 시스템으로 연결하는 문제를 풉니다. 상태 전이 적법성과 감사 추적이 규칙으로 결정론적으로 검증되어야 합니다.
고객 파트너의 자산 운영 이벤트와 자유서술 운영 노트를 받아, TypeScript 상태머신이 자산 라이프사이클 전이(발행·보관·담보·정산·상환·소각)를 규칙으로 허용·거부·보류 판정하고, 위·변조가 검증되는 해시 체인 감사 로그를 남깁니다. LLM 은 운영 노트를 구조화 이벤트로 변환하고 감사 로그를 규제 대응 리포트로 요약하는 보조만 맡고, 전이 적법성 판정은 결정론 규칙 엔진이 합니다. 1주차만으로 동작하는 원장이고, 판정이 실제로 맞았는지 확인(2주차)·규제 리포트 자동화와 두 번째 자산군 확장(3주차)으로 키웁니다. (근거는 채용공고 정렬이고, 데이터는 작성자가 만든 더미입니다.)
비하베스트 FDE. 고객사의 자산 발행·보관·정산 요청이 자유서술 노트와 스프레드시트로 흩어져 들어오는 상황을, 한 원장에서 전이 적법성 판정과 감사 추적을 확인하고 싶은 사람입니다.
자산·거래·상태·권한을 한 스키마로 묶고 전이 규칙을 상태머신으로 명시하면, (a) 고객 운영 노트를 LLM 이 구조화 이벤트로 변환하고, (b) 규칙 엔진이 각 전이를 허용·거부·보류로 결정론적으로 판정하며, (c) 모든 판정이 해시 체인 감사 로그로 추적되어 규제 대응 리포트가 자동으로 생성됩니다.
운영 노트를 넣으면 LLM 이 구조화 이벤트로 바꾸고, 상태머신이 전이를 허용·거부·보류로 판정하며, 해시 체인 감사 로그가 쌓이고 타임라인으로 보이는 동작하는 원장입니다. 온·오프체인 연동은 실제 블록체인이 빠진 20% 이므로 mock 체인 어댑터(메타·API 가정)로 시작하고, 실제 체인 연동은 인터페이스만 둡니다.
직접 만든 정답셋과 대조해 전이 판정 정확도(규칙이라 결정론)와 LLM 추출 근거 인용 일치를 재고, 규제 검토자 페르소나 2명이 판정이 타당한지 라벨링해 신뢰도를 보여주는 대시보드입니다.
감사 로그를 관할·자산군별 규제 대응 리포트로 자동 요약하고, 두 번째 자산군(매출채권)을 규칙 enum 만 갈아끼워 추가해 코어가 재사용되는 걸 보여주는 단계입니다.
고객 운영 노트 20건을 넣으면, 구조화 이벤트 추출과 전이 허용·거부·보류 판정, 해시 체인 감사 로그가 몇 초 안에 쌓이는 걸 시연합니다.
일부러 만든 불법 전이·결측·미등록 자산(orphan)·별칭 표기 30종을 넣어도 출력 형식이 한 번도 안 깨지고, 불법 전이는 규칙 엔진이 전부 거부로 잡습니다. 전이 적법성은 규칙 결정론이라 이 검출은 100% 이지만, 입력 데이터가 작성자 합성이라 '규칙 구현이 맞다'는 증명이지 실제 자산 운영 성능 검증은 아닙니다.
감사 로그를 한 줄이라도 바꾸면 해시 체인 검증이 즉시 깨지는 걸 시연하고, 규제 대응 리포트가 로그에서 자동 생성되는 걸 보여줍니다.
내가 만든 정답 30건 중 LLM 추출 근거 인용이 원문과 일치한 게 26건(87%). 단, 정답과 노트를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작' 입니다.
위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 추출 정확도·규제 적합 판정은 비하베스트 실제 자산 운영 데이터와 규제·감사 검토자가 있어야 측정 가능합니다. 이 도구는 그 검증을 바로 돌릴 수 있는 상태로 만듭니다.
이건 고객·실데이터 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 데이터 자가채점이라 '성능 증명'이 아닙니다. 면접에서 솔직히 '데모 조건 동작 + 실검증 준비 상태'로 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 일부러 불법 전이·결측·미등록 자산·별칭 표기 같은 경계 케이스를 더미에 섞어, 쉬운 문제만 푸는 게 아님을 보여줍니다.
규칙 엔진이 '적법'이라 판정해도 실제 규제 적합성과 다를 수 있습니다. 여기 전이 규칙은 작성자가 만든 합성 규칙일 뿐이고, 규제 판정은 실무·법무 검토 대상이지 이 도구가 최종 판정하지 않습니다. 이 도구는 상태 전이 적법성이라는 결정론 부분만 자동화합니다.
자산명 표기가 제각각입니다(같은 자산이 원문·별칭으로 들어옴). raw_name 과 asset_id 를 분리해 정규화하고, 못 묶은 건 추측하지 말고 미매핑(unknown_asset)으로 알립니다.
실제 도입 시 달라지는 것을 명시합니다. mock 체인 어댑터·합성 전이 규칙·페르소나 검토자를 실제 체인 연동·실 규제 규칙·실 감사 검토자로 교체해야 하고, 이는 도입 단계 과제로 분리합니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
토큰화 자산의 마스터와 현재 상태. 전이 판정과 감사 로그가 가장 먼저 조회하는 진실원입니다. 운영 현실대로 별칭 표기·액면가 결측·터미널 상태·이례적 자산군을 일부러 섞어, 쉬운 데이터만 푸는 게 아님을 보여줍니다.
| asset_id | raw_name | asset_class | current_state | face_value_krw | custodian | issued_at |
|---|---|---|---|---|---|---|
| ast_gold_001 | 골드바 1kg 발행분 A | gold | custody | 95,000,000 | 한국금거래소보관 | 2026-05-02 |
| ast_gold_002 | Gold Bar 1kg (A-lot) | gold | custody | 95,000,000 | 한국금거래소보관 | 2026-05-02 |
| ast_silver_010 | 실버바 5kg B | silver | pledged | 6,200,000 | 제일보관 | 2026-05-05 |
| ast_recv_100 | 대형제조사 매출채권 2026-Q2 | receivable | issued | 1,800,000,000 | — | 2026-06-01 |
| ast_recv_101 | 매출채권 유동화분 C | receivable | settled | — | — | 2026-06-03 |
아래 JSON Schema 에 맞는 토큰화 자산 마스터 40행 JSON 배열로 생성하세요. 자산군 4종(gold/silver/receivable/bond)과 상태 7종을 자연스럽게 분포시키세요.
{"type":"object","properties":{"asset_id":{"type":"string"},"raw_name":{"type":"string"},"asset_class":{"type":"string","enum":["gold","silver","receivable","bond"]},"current_state":{"type":"string","enum":["draft","issued","custody","pledged","settled","redeemed","burned"]},"face_value_krw":{"type":["integer","null"]},"custodian":{"type":["string","null"]},"issued_at":{"type":["string","null"]}},"required":["asset_id","raw_name","asset_class","current_state"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 문제만 푸는 함정 회피): (1) 같은 자산의 별칭·영문 표기 혼입(raw_name 이 '골드바 1kg 발행분 A' 와 'Gold Bar 1kg (A-lot)' 처럼 흔들려 정규화가 필요), (2) face_value_krw 가 null 인 액면가 미입력 행 2~3건, (3) custodian/issued_at 가 null 인 결측 행 여럿, (4) 터미널 상태(redeemed·burned) 자산 각 1~2건(이 자산에 대한 추가 전이 요청은 거부되어야 함), (5) draft 처럼 아직 발행 전 자산 1건. asset_id 는 자산군 접두어로 만들고, JSON 배열만 출력하세요.{"type":"object","properties":{"asset_id":{"type":"string"},"raw_name":{"type":"string"},"asset_class":{"type":"string","enum":["gold","silver","receivable","bond"]},"current_state":{"type":"string","enum":["draft","issued","custody","pledged","settled","redeemed","burned"]},"face_value_krw":{"type":["integer","null"]},"custodian":{"type":["string","null"]},"issued_at":{"type":["string","null"]}},"required":["asset_id","raw_name","asset_class","current_state"]}고객사가 자유서술로 보내는 자산 운영 노트. LLM 추출의 입력이고, 규칙 엔진이 판정할 전이 요청이 여기서 나옵니다. 불법 전이·미등록 자산·금액 결측·별칭·복합 이벤트를 일부러 섞어, 추출과 판정이 애매·불법 입력을 만났을 때도 안 깨지는지 보여줍니다.
골드바 1kg 발행분 A(ast_gold_001) 실물이 한국금거래소보관에 입고 완료되었습니다. 보관 상태로 전환 부탁드립니다.
Silver 5kg (B-lot) 담보로 62백만원 중 40백만원 설정 요청합니다. 카운터파티는 대주기관 K 입니다.
아래 JSON Schema 에 맞는 고객 자산 운영 노트 30건을 JSON 배열로 생성하세요. body 는 실무자가 급히 쓴 한국어 자유서술이고, asset_registry 의 자산을 참조합니다.
{"type":"object","properties":{"note_id":{"type":"string"},"title":{"type":"string"},"body":{"type":"string"},"submitted_by":{"type":["string","null"]}},"required":["note_id","title","body"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 문제만 푸는 함정 회피): (1) 불법 전이 요청 5~6건. 이미 상환·소각된 자산의 담보 설정, draft 자산의 정산(상태 건너뜀), 터미널 상태 되돌리기 등 규칙 엔진이 거부해야 하는 노트, (2) 미등록 자산(asset_registry 에 없는 이름·id) 참조 2~3건, (3) 금액·카운터파티가 빠져 애매한 노트 2~3건(needs_human 보류가 맞음), (4) 같은 자산을 별칭·영문으로 부르는 표기 흔들림, (5) 한 노트에 두 이벤트를 섞은 복합 요청 1~2건(ambiguous_multi_event). 나머지는 정상 전이 노트로 채우고, JSON 배열만 출력하세요.{"type":"object","properties":{"note_id":{"type":"string"},"title":{"type":"string"},"body":{"type":"string"},"submitted_by":{"type":["string","null"]}},"required":["note_id","title","body"]}| TypeScript | 자산 라이프사이클 상태머신의 전이 규칙·불변식과 도메인 타입(자산·거래·권한·감사)을 정의해, 엔진·API·프런트가 한 언어와 한 타입 정의를 공유합니다. |
| XState | 허용 전이·가드 조건·터미널 상태를 선언적 상태머신으로 정의해, 불법 전이(예: 이미 상환된 자산의 담보 설정)를 전이 단계에서 차단합니다. |
| Node.js | 이벤트 수신 API 와 LLM 추출 워커를 실행합니다. 노트를 구조화 이벤트로 바꾸고, 규칙 판정을 거쳐 감사 로그에 append 하는 파이프라인입니다. |
| Next.js | 감사 추적 타임라인과 규제 대응 리포트 뷰 대시보드를 렌더링합니다. |
| PostgreSQL | asset_registry / audit_log(해시 체인) / transition_rules 를 단일 진실원으로 두고, 자산별 현재 상태 뷰(v_asset_state)를 둡니다. |
| Node crypto (SHA-256) | append-only 감사 로그의 각 줄을 이전 줄 해시에 연결해, 한 줄이라도 변조되면 체인 검증이 즉시 깨지게 합니다. |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우고 싶으면 2주차(판정·추출이 실제로 맞았는지 확인)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(규제 리포트 자동화와 두 번째 자산군 확장)로 진행합니다.
1) 고객 운영 노트를 구조화된 상태 전이 이벤트로 변환하고 각 필드의 근거를 원문 인용(substring)으로 남기며, 2) 규칙 엔진이 그 전이를 허용·거부로 결정론적으로 판정하고, 3) 애매하면 사람 검토로 보류합니다. LLM 은 추출·인용만, 판정은 규칙 엔진이 합니다.
{"type":"object","properties":{"note_id":{"type":"string"},"extracted":{"type":"object","properties":{"asset_id":{"type":["string","null"]},"event_type":{"type":"string","enum":["issue","custody_in","pledge","settle","redeem","burn","unknown"]},"from_state":{"type":["string","null"]},"to_state":{"type":["string","null"]},"amount_krw":{"type":["integer","null"]},"counterparty":{"type":["string","null"]},"evidence":{"type":"array","items":{"type":"object","properties":{"field":{"type":"string"},"quote":{"type":"string"}},"required":["field","quote"]}}},"required":["event_type","evidence"]},"rule_verdict":{"type":"object","properties":{"allowed":{"type":"boolean"},"reason_code":{"type":"string","enum":["ok","illegal_transition","terminal_state","over_amount","unknown_asset","missing_field","ambiguous_multi_event"]},"reason":{"type":"string"},"broken_invariants":{"type":"array","items":{"type":"string"}}},"required":["allowed","reason_code"]},"needs_human":{"type":"boolean"}},"required":["note_id","extracted","rule_verdict","needs_human"]}[
{
"input_ref": "note_001 (골드바 A 보관 입고, 현재 상태 custody)",
"output": {
"note_id": "note_001",
"extracted": {
"asset_id": "ast_gold_001",
"event_type": "custody_in",
"from_state": "custody",
"to_state": "custody",
"amount_krw": null,
"counterparty": null,
"evidence": [
{
"field": "asset_id",
"quote": "골드바 1kg 발행분 A(ast_gold_001)"
},
{
"field": "body",
"quote": "보관 상태로 전환 부탁드립니다"
}
]
},
"rule_verdict": {
"allowed": true,
"reason_code": "ok",
"reason": "이미 custody 상태이며 보관 입고 확인은 상태를 유지하는 멱등 이벤트입니다.",
"broken_invariants": []
},
"needs_human": false
}
},
{
"input_ref": "note_003 (상환완료 골드바 D 담보 요청, 현재 상태 redeemed)",
"output": {
"note_id": "note_003",
"extracted": {
"asset_id": "ast_gold_003",
"event_type": "pledge",
"from_state": "redeemed",
"to_state": "pledged",
"amount_krw": 30000000,
"counterparty": null,
"evidence": [
{
"field": "asset_id",
"quote": "골드바 500g D"
},
{
"field": "body",
"quote": "담보로 다시 잡아주세요"
},
{
"field": "body",
"quote": "30백만원 규모입니다"
}
]
},
"rule_verdict": {
"allowed": false,
"reason_code": "illegal_transition",
"reason": "redeemed 상태에서는 pledge 전이가 허용되지 않습니다. 상환 완료 자산은 담보로 설정할 수 없습니다.",
"broken_invariants": [
"redeemed -> pledged 는 상태머신 허용 전이가 아님"
]
},
"needs_human": false
}
},
{
"input_ref": "note_005 (미등록 자산 발행 요청)",
"output": {
"note_id": "note_005",
"extracted": {
"asset_id": null,
"event_type": "issue",
"from_state": null,
"to_state": "issued",
"amount_krw": null,
"counterparty": null,
"evidence": [
{
"field": "body",
"quote": "발행 처리 바랍니다"
},
{
"field": "asset_id",
"quote": "신규 골드바 2kg 발행분 Z"
}
]
},
"rule_verdict": {
"allowed": false,
"reason_code": "unknown_asset",
"reason": "asset_registry 에 없는 자산입니다. 정규화로도 매핑되지 않아 미매핑으로 보고합니다. 자산 등록 후 재요청이 필요합니다.",
"broken_invariants": [
"asset_id 가 registry 에 존재하지 않음"
]
},
"needs_human": true
}
},
{
"input_ref": "note_007 (실버 J 담보+정산 복합 요청, 금액 미정)",
"output": {
"note_id": "note_007",
"extracted": {
"asset_id": "ast_silver_012",
"event_type": "unknown",
"from_state": "custody",
"to_state": null,
"amount_krw": null,
"counterparty": null,
"evidence": [
{
"field": "asset_id",
"quote": "실버바 5kg J"
},
{
"field": "body",
"quote": "담보 설정하고 같은 날 정산까지 한 번에"
}
]
},
"rule_verdict": {
"allowed": false,
"reason_code": "ambiguous_multi_event",
"reason": "한 노트에 pledge 와 settle 두 전이가 섞였고 금액이 미정입니다. 이벤트를 분리하고 금액을 받은 뒤 재요청이 필요합니다.",
"broken_invariants": [
"단일 노트 단일 이벤트 규칙 위반",
"amount_krw 결측"
]
},
"needs_human": true
}
}
][자동 검증 · 규칙과 결정론으로 채점] 1. 출력이 JSON Schema 를 통과하는지(형식·enum·required). 무엇을 거르나: LLM 이 event_type 을 enum 밖 문자열로 내거나 evidence 를 빠뜨린 출력. 2. extracted.evidence[].quote 가 원문 노트에 실제 존재하는 substring 인지(공백 정규화 후). 무엇을 거르나: 근거 없이 지어낸 추출. 3. rule_verdict.allowed 와 reason_code 가 상태머신 전이 규칙과 일치하는지 재계산해 대조. 전이 적법성은 규칙 결정론이라 LLM 판정을 신뢰하지 않고 엔진 결과와 비교합니다. 4. 과대·단정 표현 토큰 검출 + LLM-as-judge 의미 검사(reason 이 근거를 넘어 단정하지 않는지). [수동 검증 · 사람이 판단] 1. 규제 검토자 페르소나 2명이 비동기로 판정 타당성을 라벨링 → bootstrap Cohen's κ(두 검토자 답이 우연 이상으로 일치하는 정도, 0~1) 하한 ≥ 0.6 확인. 2. needs_human=true 로 보류된 노트를 사람이 실제로 해소 가능한지 5% 표본 점검.