플렉
2.4 (31)플렉스
경력근거: OpenAPI 및 SDK를 활용하여 시스템 간 연동 과제를 수행하며
수집일 없음
※ 실제 산출물이 아닌 AI 예측 시안입니다.
flex 의 FDE 는 flex 표준 기능과 고객사 요구 사이의 기술 격차를 식별하고, 고객사 Legacy ERP·보안 정책에 맞춘 연동·배포 아키텍처를 설계하며, OpenAPI·SDK 로 재사용 가능한 표준 모듈이나 전용 Web App 을 구축합니다. 옛 ERP 의 인사·급여 필드를 flex 표준 항목으로 매핑해 동기화하는 이 사슬은, 근태·급여·인사 항목이 표준 스키마로 정리된 flex 플랫폼과 그걸 고객사 레거시에 연결하는 OpenAPI 가 있어야 의미가 있습니다. 이 포트폴리오는 서로 다른 스키마 사이의 필드 매핑을 규칙으로 다루고 OpenAPI 로 연동 커넥터를 구현하는 능력을 보여주며, 특정 고객사의 실제 ERP 스키마 지식이나 인사 정보 보안 컴플라이언스의 실무 깊이는 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
FDE 는 flex 표준 기능과 고객사 요구 사이의 기술 격차를 찾아, 고객사 Legacy ERP 와 보안 정책에 맞춘 연동·배포 아키텍처를 설계하는 사람입니다. 옛 ERP 의 필드를 flex 표준 항목으로 옮기는 매핑이 그 격차를 닫는 첫 관문입니다.
개별 요구를 플랫폼 안에서 재사용 가능한 표준 모듈이나 전용 Web App 으로 구축하는 것이 이 역할의 핵심입니다. OpenAPI 와 SDK 로 시스템 간 연동 과제를 실제로 돌아가는 커넥터로 만들어야 가치가 완결됩니다.
현장에서 검증된 특수 로직 중 범용화 가치가 높은 요소를 골라 Product Engineer(PE)에게 기술 피드백으로 넘기고 제품 코어 로드맵에 기여합니다. 한 고객사용 일회성이 아니라 다음 고객사와 제품으로 재사용되는 엔진이어야 합니다.
고객사 IT 담당자가 옛 ERP 에서 내려받은 인사·급여 파일(사번·성명·부서·기본급·근무시간 같은 컬럼)을 올립니다. 클로드가 각 컬럼을 flex 표준 항목(employee_no·name·dept·base_salary 등)으로 매핑하는 후보를 제안하고, 별칭 컬럼명(사번=사원번호)·단위 불일치(급여 천원 단위)·날짜 형식(YYYYMMDD)을 규칙으로 정규화합니다. 검증을 통과한 레코드는 OpenAPI 스펙 기반 flex 로 밀어넣어, 옛 ERP 의 인사·급여 데이터가 flex 로 실제 동기화되는 커넥터 Web App 으로 완결됩니다. flex 테넌트는 실 연동 대신 flex OpenAPI 스펙을 가정한 mock 으로 시작하고, 매핑이 맞았는지 결정론 채점과 다음 고객사 재사용까지 이어집니다. 근거는 채용공고 정렬이고, 데이터는 작성자가 만든 더미입니다.
flex FDE. 고객사에 상주하며 회사마다 다른 옛 ERP 의 인사·급여 파일을 매번 손으로 뜯어보고 flex 항목에 맞춰 옮기던 상황을 끝내고, 매핑이 flex 표준대로 정확히 됐는지까지 확인한 뒤 동기화 커넥터를 배포하고 싶은 사람입니다.
옛 ERP 파일의 컬럼을 flex 표준 항목으로 매핑하고 단위·형식·별칭을 규칙으로 정규화하면, (a) 컬럼별 매핑 후보와 변환 규칙을 근거와 함께 제안하고, (b) 검증을 통과한 인사·급여 레코드를 OpenAPI 로 flex 에 동기화하며, (c) 직접 만든 정답 매핑 라벨과 대조해 매핑이 맞았는지 객관 채점할 수 있습니다.
옛 ERP 인사·급여 파일을 올리면 컬럼별 flex 표준 필드 매핑안과 단위·형식 변환, 그리고 flex 로 밀어넣기 전 동기화 미리보기(dry-run)까지 뜨는 동작하는 Web App 커넥터입니다. flex 테넌트는 실 연동 대신 flex OpenAPI 스펙을 가정한 mock 엔드포인트로 시작하고, 실 flex OpenAPI 동기화는 3주차로 분리합니다.
직접 만든 정답 매핑 라벨과 제안 매핑을 컬럼 단위로 대조해 오탐·누락을 객관 채점하고, 단위·형식 변환 결과를 샘플값으로 역검증하며, 동기화 전 매핑 변경분(diff)을 고객사 IT 담당자가 승인해야 반영되는 게이트와 감사 로그를 붙인 대시보드입니다.
반복되는 ERP 컬럼 패턴을 고객사 프로파일 템플릿으로 만들어 다음 고객사 온보딩을 단축하고, 실제 flex OpenAPI·SDK 로 실 동기화를 붙이며, 범용화 가치가 높은 매핑 로직을 PE 피드백용 표준 모듈로 추출하는 단계입니다.
옛 ERP export 20개 컬럼을 넣으면, 컬럼별 flex 표준 필드 매핑안과 단위·형식 변환, 그리고 flex 로 밀어넣기 전 동기화 미리보기(dry-run)까지 몇 분 안에 나오는 걸 시연합니다.
컬럼별로 직접 만든 정답 매핑 라벨 20건과 제안 매핑을 대조해 18건이 정확히 일치했습니다(오탐·누락 컬럼 0~2건). 단 ERP 파일·정답 라벨을 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'입니다.
일부러 만든 별칭·단위 불일치·날짜 형식·결측·대응 없는 컬럼 30종을 넣어도 매핑 명세 형식(JSON Schema)이 한 번도 안 깨지고, flex 표준에 대응 필드가 없는 컬럼은 임의 매핑 대신 needs_human_review 로 담당자에게 넘깁니다.
위 수치는 전부 작성자가 만든 더미 ERP 파일·정답 라벨 자가채점이며, 실제 매핑 정확도는 flex 고객사의 실 ERP export + 실제 IT 담당자 확인이 있어야 측정 가능합니다. 이 커넥터는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
이건 고객·실데이터 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 ERP 파일 자가채점이라 '성능 증명'이 아닙니다. 면접에서는 '데모 조건 동작 + 실검증 준비 상태'로 솔직히 설명합니다
정답 매핑 라벨을 제가 만들었으니 잘 맞는 게 당연합니다. 별칭 컬럼명·단위 불일치·날짜 형식·결측·대응 없는 컬럼 같은 헷갈리는 케이스를 ERP 더미에 일부러 섞어, 쉬운 컬럼만 매핑하는 게 아님을 보여줘야 합니다.
매핑은 틀리면 곧 사고입니다(급여·근태 값이 엉뚱한 flex 항목으로 들어가면 정산 오류). LLM 에 매핑 확정을 맡기지 않고 후보 제안만 시키며, 실제 확정·변환·검증은 flex 표준 사전 대조 규칙으로 하고 동기화 전 사람 승인 게이트를 반드시 거칩니다.
컬럼명은 회사마다 표기가 흔들립니다. '사번'과 '사원번호'처럼 같은 뜻의 별칭은 정규화하되, flex 표준에 대응이 없는 orphan 컬럼('노조가입여부' 등)은 추측하지 않고 미매핑으로 알려 담당자가 커스텀 필드 여부를 정하게 합니다.
실제 도입 시 달라지는 것을 명시합니다. 고객사 실 ERP 의 컬럼 규모·표기·단위·보안 정책(폐쇄망·민감정보 마스킹)이 더미와 달라 별칭 사전과 변환 규칙을 다시 맞춰야 하고, 자가 승인도 실제 IT 담당자 승인과 실 flex OpenAPI 동기화로 교체해야 합니다(도입 단계 과제로 분리).
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 옛 ERP 에서 내려받은 인사·급여 파일의 컬럼 정의와 샘플값, 그리고 그 컬럼이 매핑돼야 할 정답 flex 표준 필드(intended_flex_field)입니다. 결정론 채점의 정답 라벨로, flex_standard_schema 의 flex_field 를 참조합니다. 별칭 컬럼명·단위 불일치·날짜 형식·결측·대응 없는 orphan 컬럼을 일부러 섞어, 쉬운 컬럼만 매핑하는 게 아님을 보여줍니다.
| source_field_raw | sample_value | erp_type | unit_raw | intended_flex_field | transform_hint |
|---|---|---|---|---|---|
| 사원번호 | A-10021 | string | — | employee_no | — |
| 사번 | A-10044 | string | — | employee_no | 사원번호의 별칭 표기, 정규화 필요 |
| 성명 | 김서준 | string | — | name | — |
| 소속부서 | 재무회계팀 | string | — | dept | — |
| 직위 | 대리 | string | — | position | — |
아래 JSON Schema 에 맞는 한국 중견기업 ERP 인사·급여 export 컬럼 정의 30건을 JSON 배열로 생성하세요. 인사(사번·성명·부서·직급·고용형태·입사일)·급여(기본급·수당·계좌)·근태(근무시간·연차) 컬럼을 자연스럽게 섞으세요. intended_flex_field 는 flex_standard_schema 의 flex_field 중 하나이거나, 대응이 없으면 null 로 두세요.
{"type":"object","properties":{"source_field_raw":{"type":"string"},"sample_value":{"type":["string","null"]},"erp_type":{"type":"string","enum":["string","number","date"]},"unit_raw":{"type":["string","null"]},"intended_flex_field":{"type":["string","null"]},"transform_hint":{"type":["string","null"]}},"required":["source_field_raw","erp_type","intended_flex_field"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞으세요: (1) 별칭 표기: 같은 flex 필드로 매핑되는 다른 컬럼명('사번'/'사원번호', '성명'/'이름')을 각각 두어 정규화 대상으로, (2) 단위 불일치: 급여를 '천원'·'만원' 단위로, 근무시간을 '시간' 단위로(각각 원·분 변환 대상), (3) 날짜 형식: 'YYYYMMDD'·'YY.MM.DD' 같이 변환이 필요한 표기, (4) 결측: sample_value=null 인 행 1~2건(계측·입력 누락), (5) 대응 없는 orphan: flex 표준에 없는 컬럼('노조가입여부'·'사내메신저ID' 등, intended_flex_field=null), (6) enum 표기 흔들림: 고용형태를 '정규'/'정규직'/'계약' 처럼 다르게. JSON 배열만.{"type":"object","properties":{"source_field_raw":{"type":"string"},"sample_value":{"type":["string","null"]},"erp_type":{"type":"string","enum":["string","number","date"]},"unit_raw":{"type":["string","null"]},"intended_flex_field":{"type":["string","null"]},"transform_hint":{"type":["string","null"]}},"required":["source_field_raw","erp_type","intended_flex_field"]}flex 표준 인사·급여·근태 항목 사전입니다. OpenAPI 스펙에서 읽은 필드명·타입·단위·enum·필수 여부로, 매핑 검증기가 ERP 컬럼의 매핑 후보를 대조하는 기준 마스터입니다. 타입·enum·단위가 명시돼 있어야 단위 변환과 형식 검증을 결정론으로 돌릴 수 있습니다.
| flex_field | label | type | unit | enum | required |
|---|---|---|---|---|---|
| employee_no | 사번 | string | — | — | true |
| name | 이름 | string | — | — | true |
| dept | 부서 | string | — | — | false |
| position | 직급 | string | — | — | false |
| employment_type | 고용형태 | string | — | ["정규직","계약직","파견","인턴"] | true |
아래 JSON Schema 에 맞는 HR SaaS 표준 인사·급여·근태 필드 사전 16건을 JSON 배열로 생성하세요. flex_field 는 snake_case 영문(employee_no·base_salary 등), label 은 한글, type·unit·enum·required 를 명시하세요.
{"type":"object","properties":{"flex_field":{"type":"string"},"label":{"type":"string"},"type":{"type":"string","enum":["string","number","date"]},"unit":{"type":["string","null"]},"enum":{"type":["array","null"],"items":{"type":"string"}},"required":{"type":"boolean"}},"required":["flex_field","label","type","required"]}
쉬운 데이터만 만들지 말 것. 다음을 의도적으로 반영하세요: (1) 단위가 있는 수치 필드: base_salary(원)·work_minutes(분)·annual_leave_days(일)처럼 ERP 단위 변환 대상이 되게, (2) enum 고정 필드: employment_type(정규직·계약직·파견·인턴)처럼 표기 정규화가 필요한 필드, (3) date 형식 필드: hire_date(YYYY-MM-DD)로 ERP 날짜 형식 변환 대상, (4) 민감정보 필드: resident_reg_no 처럼 마스킹이 전제되는 필드, (5) required 필드와 optional 필드를 섞어 필수값 누락 검증이 의미 있게. JSON 배열만.{"type":"object","properties":{"flex_field":{"type":"string"},"label":{"type":"string"},"type":{"type":"string","enum":["string","number","date"]},"unit":{"type":["string","null"]},"enum":{"type":["array","null"],"items":{"type":"string"}},"required":{"type":"boolean"}},"required":["flex_field","label","type","required"]}| TypeScript | 대표 언어입니다. 매핑 규칙 엔진(별칭 정규화·단위 변환·타입 검증), ERP 파일 파서, 동기화 커넥터, 결정론 채점기까지 전 계층을 한 언어로 구현합니다. |
| OpenAPI | flex 표준 API 스펙입니다. 인사·급여 레코드를 flex 엔터티로 밀어넣는 연동 계약이자, 매핑 대상 표준 필드·타입·enum 을 스펙에서 그대로 읽어 검증 규칙으로 씁니다. |
| SDK | flex SDK 로 인증·엔터티 생성/갱신 호출을 감싸 커넥터를 구현합니다. 3주차 실 동기화에서 재시도·부분 실패 처리를 SDK 계층에 둡니다. |
| Node.js | ERP 파일 파싱과 매핑·동기화 배치를 실행하는 런타임입니다. dry-run 미리보기와 실제 push 를 같은 파이프라인으로 돌립니다. |
| React | 매핑 검토·승인 콘솔과 전용 Web App 화면을 만듭니다. 컬럼별 매핑안·변환·근거를 보여주고 담당자가 배포 전 diff 를 승인하게 합니다. |
| Next.js | 커넥터 Web App 의 배포 단위입니다. App Router 로 업로드·매핑·동기화 화면을 나누고 매핑 API 를 제공합니다. |
| LLM | ERP 컬럼명과 샘플값을 보고 flex 표준 필드 매핑 후보를 제안합니다. 제안만 맡고 검증·변환·채점은 결정론 규칙 엔진이 합니다. |
| Claude | 매핑 제안 모델은 Claude Sonnet 을 씁니다. 커넥터 골격과 OpenAPI 클라이언트 생성은 Claude Code·Cursor 로 빠르게 만듭니다. |
| PostgreSQL | erp_source_fields·flex_standard_schema·확정 매핑 명세·동기화 이력·감사 로그의 단일 진실원입니다. |
| Docker | (우대) 고객사 보안 정책상 폐쇄망 배포가 필요할 때 커넥터를 컨테이너로 묶어 사내망에서 구동합니다. |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우고 싶으면 2주차(매핑이 맞는지 결정론 채점)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(재사용 표준 모듈 + 실 flex OpenAPI 연동)로 진행합니다.
ERP 컬럼 하나를 flex 표준 필드로 매핑하는 후보를 구조화해 제안하고, evidence_phrase 로 원본 컬럼명·샘플값의 어느 부분에서 판단했는지 추적합니다. proposed_flex_field 는 채점 대상 후보값이고, 단위·형식 변환은 transform enum 으로 표기해 결정론 변환기가 그대로 적용합니다. flex 표준에 대응이 없으면 임의 매핑 대신 needs_human_review 로 에스컬레이션합니다.
{"type":"object","properties":{"source_field_raw":{"type":"string"},"proposed_flex_field":{"type":["string","null"]},"transform":{"type":"string","enum":["none","unit_won_from_thousand","minutes_from_hour","date_from_yyyymmdd","normalize_enum","alias_normalize"]},"evidence_phrase":{"type":"string"},"confidence":{"type":"number"},"needs_human_review":{"type":"boolean"},"review_reason":{"type":["string","null"]}},"required":["source_field_raw","proposed_flex_field","transform","evidence_phrase","needs_human_review"]}[
{
"source_field_raw": "사원번호",
"proposed_flex_field": "employee_no",
"transform": "none",
"evidence_phrase": "사원번호",
"confidence": 0.94,
"needs_human_review": false,
"review_reason": null
},
{
"source_field_raw": "기본급여",
"proposed_flex_field": "base_salary",
"transform": "unit_won_from_thousand",
"evidence_phrase": "기본급여 · 단위 천원",
"confidence": 0.81,
"needs_human_review": false,
"review_reason": null
},
{
"source_field_raw": "노조가입여부",
"proposed_flex_field": null,
"transform": "none",
"evidence_phrase": "노조가입여부",
"confidence": 0.3,
"needs_human_review": true,
"review_reason": "flex 표준 항목에 대응 필드가 없는 orphan 컬럼. 커스텀 필드로 만들지 여부를 담당자가 확인해야 함."
}
][자동 검증: 규칙·결정론으로 채점] 1. JSON Schema 통과: 매핑 명세가 형식(source_field_raw·proposed_flex_field·transform·evidence_phrase)을 지키는지. 깨지면 동기화 차단. 2. evidence_phrase 실재: evidence_phrase 가 원본 컬럼명·unit_raw 의 실제 부분 문자열인지(공백 정규화 후). LLM 이 없는 근거를 지어내면 탈락. 3. 표준 사전 정합: proposed_flex_field 가 flex_standard_schema 의 flex_field 에 실재하고, transform 적용 후 샘플값이 그 필드의 type·enum·단위와 맞는지 검증(예: base_salary 는 number·원, employment_type 은 enum 통과). 4. 정답 라벨 대조: proposed_flex_field 를 intended_flex_field 와 컬럼 단위로 대조해 오탐(잘못 매핑)·누락(빠뜨림)을 집계. 5. orphan 처리: 표준 사전에 대응이 없는 컬럼은 자동으로 미매핑 표시 후 needs_human_review=true. [수동 검증: 사람이 판단] 1. orphan·모호 컬럼(needs_human_review=true)은 고객사 IT 담당자가 커스텀 필드 여부·의미를 확정해야 동기화. 자동 매핑 금지. 2. 동기화 전 매핑 diff(현재 vs 새 매핑)를 담당자가 승인해야 flex 로 push.
근거: OpenAPI 및 SDK를 활용하여 시스템 간 연동 과제를 수행하며