코리FDE(Forward Deployed Engineer, 3년이상)
2.6 (36)코리아포트원
경력근거: 고객 요구사항을 재사용 가능한 코어 제품 기능·자산으로 범용화
어제 확인채용 공고 보기
포트원 FDE 는 결제가 필요한 고객사와 여러 PG사 사이의 연동을 돕는 B2B 핀테크 인프라에서, 고객사 현장에 들어가 제품을 진단·온보딩·구축하고 고객 요구사항을 재사용 가능한 코어 자산으로 범용화합니다. 연동 요청을 PG 스펙으로 검증해 설정을 생성하는 이 게이트는 그 핵심(연동 온보딩 자동화·스펙 정합성 검증·재사용 코어화)을 정면으로 보여주고, LangChain·LangGraph 로 요청 파싱에서 설정 생성까지를 상태 그래프로 잇습니다. 결제 규제 준수·정산 적정성 같은 핀테크 도메인 전문성은 포트폴리오로 증명되지 않으므로 일반 결제 더미 스펙으로 기술만 보이고, 그 깊이는 면접에서 솔직히 다룹니다. PG 스펙 규칙·원문 근거로 연동 설정 생성을 잇는 사슬은 3,000여 고객사와 다수 PG 연동을 다루는 포트원 맥락이라야 의미가 있고 단순 LLM 파싱으로는 그대로 만들 수 없습니다.
고객사 현장에 들어가 제품을 진단하고 온보딩·구축하며 끝까지 책임집니다. 연동 요청을 스펙으로 검증해 설정을 생성하는 온보딩 게이트가 직접 정렬됩니다.
고객 요구사항을 재사용 가능한 코어 자산으로 범용화해 문제해결 속도를 높입니다. 도메인 무관 재사용 코어와 갈아끼우는 스펙 마스터로 나눈 이 게이트 구조가 정렬됩니다.
LangChain·LangGraph 로 Agentic Workflow 를 짜고 도메인 복잡도를 타입 안전한 코드로 녹입니다. 요청 파싱→스펙 조회→검증→설정 생성 상태 그래프가 정렬됩니다.
고객사가 자유형 온보딩 메시지로 보낸 결제 연동 요청(PG사·결제수단·필드값)을 LLM 이 구조화한 뒤, 규칙(PG 연동 스펙의 필수 필드·형식·허용 enum·미등록 PG·웹훅 결측)으로 배포 가능한 설정을 생성할지 검토로 돌릴지 막을지 정합니다. 통과 여부는 PG 연동 스펙과 필드 규칙으로 결정하고, LLM 은 요청 파싱·필드 근거 인용 보조만 맡습니다. 결제 규제·정산 적정성 판단이 아니라 연동 스펙 정합성 게이트입니다.
포트원 FDE. 고객사가 PG 연동을 요청할 때마다 각 PG 연동 문서를 뒤져 필수 필드·형식·허용값을 일일이 대조하고 설정을 손으로 만들던 일을, 한 게이트에서 요청 파싱·스펙 검증·설정 생성 결과를 함께 보고 싶은 사람입니다.
연동 요청을 한 스키마로 묶고 PG 연동 스펙(필수 필드·허용값)을 붙이면, (a) 필수 필드 누락·형식 위반·허용 안 된 값·미등록 PG를 규칙으로 거르고, (b) 통과한 요청은 배포 가능한 연동 설정으로 바로 생성하며, (c) 여러 PG·고객사 요청을 끊김 없이 온보딩합니다.
자유형 온보딩 메시지에서 연동 요청 필드를 뽑아 PG 연동 스펙(필수 필드·형식·허용값·미등록·웹훅)을 검사해 통과 요청만 배포 가능한 연동 설정으로 생성하는 동작하는 게이트입니다. PG 스펙·요청은 일반 결제 더미로 시작합니다.
판정과 생성 설정을 심은 정답·검토자 2명 라벨에 비교해 정밀도·재현율과 일치도를 보여주는 화면입니다. 2주차부터 AWS·Kubernetes 로 컨테이너 배포·운영을 시작합니다.
PG·결제수단별 생성 성공률과 차단 사유 분포를 누적 집계해 자주 막히는 필드를 보여주는 화면입니다.
요청 시나리오 12종(정상·필수 누락·형식 위반·미등록 PG)을 넣으면, 파싱·스펙 검증·설정 생성 결과가 몇 초 안에 나오는 걸 시연합니다
더미에 심은 정답 판정 40건 중 생성/검토/차단이 일치한 게 35건(약 88%)입니다. 단, 정답·데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
일부러 만든 악성·결측 입력 30종(웹훅 URL 결측·미등록 PG·결제수단 표기 흔들림·형식 위반)을 넣어도 출력 형식(스키마)이 한 번도 안 깨지고, 통과하지 않은 요청은 설정을 생성하지 않습니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 정밀도·재현율은 포트원의 실 PG 연동 스펙과 실 고객 요청, 실 검토자가 있어야 측정 가능합니다. 이 게이트는 그 검증을 바로 돌릴 수 있는 상태로 만듭니다
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다
이 포트폴리오가 보여주는 것은 연동 요청을 스키마로 제약한 LLM 파싱 + PG 스펙·필드 규칙 검증 + 설정 생성 기술입니다. 결제 규제 준수·정산 적정성 판단 같은 핀테크 도메인 전문성은 포트폴리오로 증명되지 않으므로 주장하지 않으며, 그 깊이는 면접에서 모르면 모른다고 말하는 편이 낫습니다. 데모는 일반 결제 더미 스펙으로 기술만 보여줍니다
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 미등록 PG·결제수단 표기 흔들림·웹훅 결측·형식 경계값 같은 경계 케이스를 더미에 일부러 섞어, 쉬운 요청만 통과시키는 게 아님을 보여줍니다
LLM 이 뽑은 필드는 그럴듯해도 원문 메시지에 없을 수 있습니다. 필드마다 원문 인용을 달게 하고, 근거가 없으면 '미근거'로 걸러 설정을 생성하지 않습니다
PG·결제수단 표기가 제각각입니다. 정규화로 같은 PG 로 묶고, 못 묶은 건 추측하지 말고 '미등록 PG'로 검토에 돌립니다. 실제 도입 시 PG 연동 스펙·허용값이 더미와 다르므로 스펙 마스터를 다시 맞춰야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 연동 요청 파싱·판정 로그. 스펙 검증 규칙이 가장 먼저 질의하는 테이블입니다. 미등록 PG·결제수단 표기 흔들림·웹훅 결측·형식 위반을 일부러 섞고, label 로 정답을 심어 자가채점합니다.
| request_id | pg_raw | pg_id | pay_method | pg_in_spec | required_present | format_valid | enum_allowed | webhook_url | label | ts |
|---|---|---|---|---|---|---|---|---|---|---|
| req_001 | 토스페이먼츠 | toss | card | true | true | true | true | https://shop.example.com/webhook | generate | 2026-04-02T09:00 |
| req_002 | 토스 페이먼츠 | toss | easy_pay | true | true | true | true | https://mall.example.com/pg/webhook | generate | 2026-04-02T10:00 |
| req_003 | 나이스페이 | nice | virtual_account | true | false | true | true | https://store.example.com/webhook | reject | 2026-04-02T11:00 |
| req_004 | 케이지이니시스 | inicis | card | true | true | false | true | https://shop2.example.com/webhook | reject | 2026-04-02T12:00 |
| req_005 | 카카오페이 | kakaopay | phone | true | true | true | false | https://shop3.example.com/webhook | reject | 2026-04-02T13:00 |
아래 Zod 스키마에 맞는 연동 요청 파싱 로그 60행 JSON 배열로 생성합니다. PG 5~7개, 결제수단 분포, 정상 위주에 거름·검토를 섞습니다. label 규칙: pg_in_spec=false → review, 그 외에 required_present=false 또는 format_valid=false 또는 enum_allowed=false → reject, 그 외에 webhook_url=null → review, 그 외(스펙 등록·필수·형식·허용·웹훅 모두 정상) → generate.
{"type":"object","properties":{"request_id":{"type":"string"},"pg_raw":{"type":"string"},"pg_id":{"type":["string","null"]},"pay_method":{"type":"string","enum":["card","virtual_account","transfer","phone","easy_pay"]},"pg_in_spec":{"type":"boolean"},"required_present":{"type":"boolean"},"format_valid":{"type":"boolean"},"enum_allowed":{"type":"boolean"},"webhook_url":{"type":["string","null"]},"label":{"type":"string","enum":["generate","review","reject"]},"ts":{"type":"string"}},"required":["request_id","pg_raw","pg_id","pay_method","pg_in_spec","required_present","format_valid","enum_allowed","webhook_url","label","ts"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 요청만 통과시키는 함정 회피): (1) 같은 PG의 표기 별칭('토스페이먼츠'/'토스 페이먼츠'처럼 pg_id 로 정규화돼야 함) 3건 이상, (2) 미등록 PG(pg_in_spec=false, pg_id=null) 2건, (3) 결측: webhook_url=null 인 웹훅 미기입 행 2~3건, (4) 경계값으로 필수 누락(required_present=false)·형식 위반(format_valid=false)·PG가 허용하지 않는 결제수단(enum_allowed=false) 각 2건, (5) pg_id 는 등록됐지만 웹훅만 빠진 review 케이스 2~3건. label 은 위 규칙대로 정직하게. JSON 배열만.{"type":"object","properties":{"request_id":{"type":"string"},"pg_raw":{"type":"string"},"pg_id":{"type":["string","null"]},"pay_method":{"type":"string","enum":["card","virtual_account","transfer","phone","easy_pay"]},"pg_in_spec":{"type":"boolean"},"required_present":{"type":"boolean"},"format_valid":{"type":"boolean"},"enum_allowed":{"type":"boolean"},"webhook_url":{"type":["string","null"]},"label":{"type":"string","enum":["generate","review","reject"]},"ts":{"type":"string"}},"required":["request_id","pg_raw","pg_id","pay_method","pg_in_spec","required_present","format_valid","enum_allowed","webhook_url","label","ts"]}| TypeScript | 온보딩 게이트 화면과 요청 파서·출력 스키마(Zod) 검증의 구현 언어입니다 |
| Kotlin | 연동 스펙 검증 규칙 엔진과 도메인 모델을 Domain-Driven Design 기반 Layered Architecture 로 구현하는 백엔드 언어입니다 |
| Go | 웹훅 통지 설정이 살아 있는지 확인하는 경량 프로브 컴포넌트의 구현 언어입니다 |
| PostgreSQL | 연동 요청·판정 로그·PG 연동 스펙 마스터를 저장하는 데이터베이스입니다 |
| BigQuery | 3주차에 PG·결제수단별 온보딩 정합성·차단 사유 추이를 집계하는 분석 저장소입니다 |
| AWS | 2주차부터 게이트를 배포·운영하는 클라우드입니다 |
| Kubernetes | 게이트를 컨테이너로 묶어 AWS 위에서 배포·운영하는 오케스트레이션입니다 |
| LLM | 자유형 온보딩 메시지에서 연동 요청 필드를 추출하는 엔진입니다 |
| LangChain | 요청 파싱·스펙 조회·검증 단계를 잇는 체인 구성입니다 |
| LangGraph | 요청 파싱에서 스펙 조회, 검증, 설정 생성까지를 상태 그래프로 오케스트레이션합니다 |
| Claude | 연동 요청 필드 추출·근거 인용 LLM 입니다 |
| REST | 고객 요청 수신과 생성 설정 반환을 주고받는 REST API 인터페이스입니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(생성한 설정이 맞았는지 확인)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(PG·결제수단별 온보딩 정합성 추이)로 진행합니다.
연동 요청 1건의 온보딩 결정 카드. 결정·요인·근거와 통과 시 생성 설정을 한 스키마로 담아 화면 카드에 씁니다. 결제 규제·정산 적정성 판정이 아니라 스펙 정합성 게이트입니다.
{"type":"object","properties":{"request_id":{"type":"string"},"pg_id":{"type":["string","null"]},"decision":{"type":"string","enum":["generate","review","reject"]},"factors":{"type":"array","items":{"type":"string","enum":["required_field_missing","format_invalid","enum_not_allowed","unmapped_pg","missing_webhook"]}},"generated_config":{"type":["string","null"]},"reason":{"type":"string","minLength":20},"evidence":{"type":"string","minLength":8},"hedge":{"type":["string","null"]}},"required":["request_id","pg_id","decision","factors","generated_config","reason","evidence","hedge"]}[
{
"input_ref": "req_001 (스펙·필수·형식·허용·웹훅 모두 정상)",
"output": {
"request_id": "req_001",
"pg_id": "toss",
"decision": "generate",
"factors": [],
"generated_config": "{ \"pg\": \"toss\", \"pay_method\": \"card\", \"webhook_url\": \"https://shop.example.com/webhook\" }",
"reason": "PG가 스펙에 등록돼 있고 필수 필드·형식·허용 결제수단·웹훅이 모두 충족돼 배포 가능한 연동 설정을 생성합니다.",
"evidence": "pg_in_spec=true, required_present=true, format_valid=true, enum_allowed=true, webhook_url 존재",
"hedge": null
}
},
{
"input_ref": "req_004 (형식 위반)",
"output": {
"request_id": "req_004",
"pg_id": "inicis",
"decision": "reject",
"factors": [
"format_invalid"
],
"generated_config": null,
"reason": "필드 형식이 이니시스 연동 스펙과 어긋나 그대로 설정을 생성하면 연동이 실패합니다. 설정을 만들지 않고 형식 사유와 함께 막습니다.",
"evidence": "format_valid=false",
"hedge": "형식이 스펙과 맞지 않아 설정을 생성하지 않습니다"
}
},
{
"input_ref": "req_006 (미등록 PG)",
"output": {
"request_id": "req_006",
"pg_id": null,
"decision": "review",
"factors": [
"unmapped_pg"
],
"generated_config": null,
"reason": "요청한 PG가 연동 스펙 마스터에 없어 필수 필드·허용값을 검증할 기준이 없습니다. 추측하지 않고 스펙 등록 후 재평가하도록 검토로 돌립니다.",
"evidence": "pg_in_spec=false, pg_id=null",
"hedge": "미등록 PG라 스펙 기준이 없어 검토로 둡니다"
}
}
][자동 검증] 1. Zod parse 로 출력 형식(필드·enum)이 스키마를 통과하는지 확인합니다. 2. decision 이 스펙 정합성 규칙(미등록 PG→review·필수 누락/형식 위반/허용 안 된 결제수단→reject·웹훅 결측→review·통과→generate)과 일치하는지 봅니다. 3. decision=generate 일 때만 generated_config 가 채워지고 그 외에는 null 인지, evidence 가 입력 요청의 실제 값 인용인지 토큰 매칭으로 확인합니다. 4. decision 을 심은 정답 label 과 비교해 정밀도·재현율을 계산합니다. [수동 검증] 1. 검토자 2명이 비동기로 온보딩 판정을 라벨링해 정밀도·재현율과 bootstrap Cohen's κ(두 사람 일치가 우연 이상인 정도, 0~1) 하한 0.6 이상을 봅니다. 2. 전체의 5% 를 사람이 직접 점검합니다.