모두의포트폴리오
PE · FDE 직군을 위한 포트폴리오 밀키트
예전 판입니다 (1판)이 문서는 2026-08-02 에 새 판으로 개정됐습니다. 결과를 보여 주기만 하던 지출 분류 대시보드를 걷어내고, 회수할 좌석과 전환 시점을 사람이 화면에서 골라야만 12개월 절감액이 다시 계산되는 구독 절감안 시뮬레이터로 다시 썼습니다.최신 판 보기 →
경력고위드

법인카드 지출 내역을 자동으로 분류하고, 정책에 어긋난 이상 지출을 짚어주는 도구

고위드 공고에서 뽑은 세 가지 시그널.

고위드는 3,500여 고객사의 법인카드 지출 데이터를 가진 B2B 핀테크라, 지출을 자동 분류하고 이상 지출을 짚는 이 도구는 고위드의 실제 법인 지출 내역이 있어야 분류를 검증한다.

01

실시간 데이터 기반 금융·프로세스

'실시간 데이터를 기반으로 최적의 금융과 프로세스를 공급'이 미션. 지출 데이터를 즉시 분류·점검하는 도구가 그 방향과 정렬.

실시간데이터프로세스
02

법인카드 = 지출 데이터의 원천

스타트업 전용 법인카드가 핵심 제품. 카드 지출의 분류·이상 탐지는 고객사가 매일 마주하는 운영 문제.

법인카드거래액고객사
03

백엔드 중심 풀스택 PE

Java·Spring·MySQL·Redis 백엔드 + React. 지출 ingest→분류→점검 파이프라인을 제품으로 만드는 직무와 정렬.

SpringMySQLRedis

포트폴리오 요약

법인카드 거래 내역에 가맹점·계정 메타를 붙여, 지출을 계정 항목으로 자동 분류하고 정책 위반·이상 지출을 근거와 함께 표시하는 1주 포트폴리오.

고객 정의

고위드 PE. 고객사의 법인카드 지출을 매번 손으로 분류·점검하던 상황을 끝내고, 그 분류·이상 탐지를 자동 도구로 옮기고 싶은 사람.

고민 지점

거래 내역에 가맹점·계정 규칙을 붙이면, LLM/규칙이 (a) 지출을 계정 항목으로 분류하고 (b) 한도 초과·이중 결제·정책 위반 지출을 근거와 함께 표시한다.

주차별 일정

1주차여기까지로 완성

법인카드 지출 자동 분류 + 이상 지출

법인카드 거래를 받아 계정 항목으로 자동 분류하고 정책 위반·이상 지출을 근거와 함께 표시하는 동작하는 도구.

  1. 1일 · 거래·가맹점·계정 메타를 한 표로 묶을 스키마 설계 + 이상 지출 규칙 정의(한도·중복·시간대·정책)
  2. 2-3일 · 거래 ingest(Java) + 가맹점→계정 규칙 분류 + 미등록 가맹점 LLM 판정 + Zod 검증
  3. 4일 · 이상 지출 플래그(이중 결제·한도 초과·심야·미등록) + 근거 인용
  4. 5일 · 지출 점검 대시보드(React)계정 분류·이상 사유·근거 한 화면
  5. 6일 · 일부러 만든 결측·중복·미등록·이상 거래 30종으로 분류/탐지가 안 깨지는지 점검 + 5% 사람 확인
  6. 7일 · 7일치 시연 영상 + 직접 만든 정답과 비교한 기준선여기까지가 1주차 완성품
2주차선택 성장

자동분류·이상탐지가 실제와 맞는지 검증

실제 회계 확정 대비 자동분류 정확도와 이상 탐지 정밀도/오탐 비율을 보여주는 대시보드.

  1. 8-9일 · 실제 회계 확정 대비 자동분류 정확도 측정 + 이상 탐지 정밀도
  2. 10-11일 · 오탐 비율 점검 + 정책 룰 임계 튜닝
3주차선택 성장

월 마감 자동화 + 위반 알림

월 마감 리포트를 자동 생성하고 정책 위반을 봇으로 알려, 경리 마감 시간을 줄이는 단계.

  1. 12-14일 · 월 마감 리포트 자동 생성 + 정책 위반 알림 봇
  2. 15일 · 마감 자동화 시연 + 3주 통합 영상

데모 · 측정 지표

01

결측·중복·미등록·이상 거래 30종(이중 결제·한도 초과·미등록 가맹점 포함)을 넣어도 분류·탐지가 멈추지 않는 걸 시연한다

02

거래 묶음을 넣으면 계정 분류와 이상 지출 플래그가 근거와 함께 몇 초 안에 나오는 걸 시연한다

03

모든 분류·플래그 출력이 형식 검증(Zod)을 통과

측정: 자동 parse, 표본: 거래 200건

04

계정 분류 라벨 30개 중 26개가 내가 만든 정답과 일치. 단, 정답·데이터를 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건 동작'

정직 경계선

진짜 성능 검증은 여기서 멈춘다

위 수치는 더미데이터 자가채점이며, 실제 분류·이상 탐지 정확도는 고위드 실제 거래 데이터 + 회계 검수가 있어야 측정 가능. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만든다.

미리 알아둬야 할 것들

이건 고객·실데이터 없이 혼자 만든 포트폴리오라 모든 수치는 합성 데이터 자가채점이다. 면접에서 '데모 동작 + 실검증 준비 상태'로 솔직히 설명하는 게 오히려 신뢰를 준다

정답을 내가 만들었으니 잘 맞는 게 당연. 그래서 이중 결제·미등록 가맹점·표기 흔들림·결측 같은 헷갈리는 케이스를 더미에 일부러 섞어 쉬운 문제만 푸는 게 아님을 보여준다

'이상 지출'의 기준은 고객사 정책마다 다름. 규칙을 정책 설정으로 외부화하고, 애매한 건 단정하지 말고 '검토 필요'로 표시

실제 도입 시 달라지는 것: 실 거래 분포·가맹점 다양성이 더미와 다르므로 계정 사전과 이상 규칙을 실데이터로 다시 맞춰야 한다(도입 단계 과제)

더미 데이터

① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.

card_transactionsTABLE· 12 rows

법인카드 거래 한 건 로그. 분류·이상탐지 엔진이 가장 먼저 보는 표. 결측·중복·미등록·이상금액을 일부러 섞었다.

② card_transactions.seed.json 다운로드
① 인라인 샘플 (프리뷰 5 / 12)
tx_idcompany_idmerchant_rawmerchant_idamount_krwcategoryts
tx_001co_a스타벅스 강남점m_sbux18,000meal2026-05-02T09:12:00
tx_002co_aAWSm_aws1,320,000software2026-05-02T03:00:00
tx_003co_a스타벅스강남m_sbux18,000meal2026-05-02T09:12:05
tx_004co_b카카오모빌리티m_kakaot9,800transport2026-05-03T22:40:00
tx_005co_b알 수 없는 가맹점 #44—540,000—2026-05-03T02:13:00
③ 증강 프롬프트 (본인 LLM 에 붙여서 N 배 늘리기)
아래 Zod 스키마에 맞는 법인카드 거래 로그 120행 JSON 배열로 생성.

z.object({ tx_id: z.string(), company_id: z.string(), merchant_raw: z.string(), merchant_id: z.string().nullable(), amount_krw: z.number().int(), category: z.enum(["meal","transport","software","office","ad","unknown"]).nullable(), ts: z.string().nullable() })

쉬운 데이터만 만들지 말 것. 하드 케이스 의도적 혼입: (1) 동일 거래 중복(금액·가맹점 같고 ts 5초 차) 1쌍, (2) merchant_id/category/ts=null 결측 각 1~2건, (3) merchant_raw 표기 흔들림('스타벅스 강남점' vs '스타벅스강남') 1쌍과 빈 문자열 1건, (4) 미등록 가맹점(merchant_id=null) 2건, (5) 경계 금액 0원·심야 고액(>50만, 03시) 각 1건, (6) 미등록 company_id(orphan) 1건. JSON 배열만.
schema (3 층의 단일 출처)
z.object({ tx_id: z.string(), company_id: z.string(), merchant_raw: z.string(), merchant_id: z.string().nullable(), amount_krw: z.number().int(), category: z.enum(["meal","transport","software","office","ad","unknown"]).nullable(), ts: z.string().nullable() })

기술 상세 · 아키텍처·운영·출력 스키마

기술 스택 매핑
Java거래 ingest + 분류 규칙 + 이상 탐지(한도·중복·시간대) 배치
Spring분류·점검 API (`POST /classify`. 거래 배열 → 계정 라벨 + 이상 플래그)
React지출 점검 대시보드 + Zod 런타임 검증
Redis가맹점→계정 매핑 캐시
LLM 선택
model
규칙 기반 1차 분류 + Claude Haiku(미등록 가맹점·모호 지출 계정 판정)
prompt
few-shot 3 예시 + 계정 분류 사전 주입 + 정책 규칙 + Zod schema 강제
rationale
대다수 거래는 가맹점→계정 규칙으로 즉시, 미등록 가맹점만 LLM 판정. 대량·저비용이라 Haiku.
결정 게이트
1주차 끝1주차 완성품이 자동으로 도는가. 여기까지가 그 자체로 제출 가능한 완성품.

✓ pass → 그대로 멈춰도 완성품. 더 키우려면 2주차(자동분류·이상탐지가 실제와 맞는지 검증)로.

2주차 끝자동분류·이상탐지가 실제와 맞는지 검증 결과가 나오는가.

✓ pass → 여기서 멈춰도 완결. 더 키우려면 3주차(월 마감 자동화 + 위반 알림)로.

재사용 레이어 · 코어 70% / 도메인 30%
core (재사용 가능)
  • 거래 ingest + 가맹점·계정 메타 조인
  • 계정 자동분류 모델/룰 + 분류 근거 부착
  • 이상 지출 탐지 + Zod 스키마 강제 검증
  • 검수 대시보드(React)
  • 5% 인간 spot-check 자동 샘플러
domain (교체 대상)
  • 계정과목 체계 + 지출 정책 룰
  • 가맹점 카테고리 사전
  • 지출 하드케이스(미등록 가맹점·경계 금액·중복) 더미 생성기
출력 스키마 · expense_classification

거래 단위 계정 분류 + 이상 지출 플래그 출력. 근거 인용 포함.

schema (JSON Schema)
z.object({ tx_id: z.string(), category: z.enum(["meal","transport","software","office","ad","unknown"]), anomaly: z.array(z.enum(["duplicate","over_limit","late_night","unmapped_merchant","zero_amount","none"])).min(1), evidence: z.array(z.object({ field: z.string(), quote: z.string() })).min(1), hedge: z.string().min(8).nullable() })
모범 출력 (3)
[
  {
    "tx_id": "tx_003",
    "category": "meal",
    "anomaly": [
      "duplicate"
    ],
    "evidence": [
      {
        "field": "merchant_raw",
        "quote": "스타벅스강남"
      },
      {
        "field": "ts",
        "quote": "2026-05-02T09:12:05"
      }
    ],
    "hedge": "tx_001 과 5초 차 동일 금액. 이중 결제 의심"
  },
  {
    "tx_id": "tx_005",
    "category": "unknown",
    "anomaly": [
      "unmapped_merchant",
      "late_night"
    ],
    "evidence": [
      {
        "field": "merchant_id",
        "quote": "null"
      }
    ],
    "hedge": "미등록 가맹점 + 심야 고액, 계정 단정 보류"
  },
  {
    "tx_id": "tx_009",
    "category": "office",
    "anomaly": [
      "zero_amount"
    ],
    "evidence": [
      {
        "field": "amount_krw",
        "quote": "0"
      }
    ],
    "hedge": "0원 거래. 취소/오류 가능"
  }
]
검증 노트 (자동 vs 수동)

자동: (1) Zod parse, (2) evidence.field 가 입력 스키마 실제 필드명인지, (3) unmapped_merchant 플래그 시 category=unknown 권장 규칙 체크. 수동/judge: 이상 판정 적정성은 회계 정책 기준 사람 5% 확인.