카카오페이
경력근거: 내부 조직의 업무 현장에 들어가 AI 적용 가치가 큰 병목 지점을 발견
※ 실제 산출물이 아닌 AI 예측 시안입니다.
카카오페이 FDE는 개발·비개발 직군 구분 없이 내부 조직의 업무 현장에 들어가 AI 적용 가치가 큰 병목을 찾아 솔루션을 설계·구현하고, 그 효과를 업무 처리 시간·공수 절감 지표와 AI 생산성 대시보드로 정량화하는 역할입니다. 백엔드 조직에서 매 PR마다 반복되는 코드 리뷰 지적은 Java·Kotlin 백엔드 역량을 기본으로 한 이 직무가 정면으로 마주치는 병목이라, 그 반복을 규칙으로 자동화하고 남은 판단만 사람에게 돌리는 이 게이트는 JD의 핵심(현장 병목의 AI 자동화 + 도입 효과 정량화 + 백엔드 골조)을 그대로 보여줍니다. 결제·정산의 규제 판단 같은 도메인 전문성은 포트폴리오로 증명되지 않으므로 결제는 샘플 코드의 테마로만 쓰고 그 깊이는 면접에서 솔직히 다룹니다. 반복 리뷰 지적을 규칙·근거로 라우팅하는 이 사슬은 일반 문서 질의나 지식 검색 맥락으로는 그대로 만들 수 없습니다.
내부 조직 업무 현장의 반복 병목을 찾아 AI 솔루션으로 설계·구현합니다. 반복되는 코드 리뷰 지적을 규칙과 LLM으로 자동화하는 이 게이트가 직접 정렬됩니다.
AI 도입 전후 효과를 업무 처리 시간·공수 절감 지표로 설계·측정하고 대시보드로 정량화합니다. 리뷰 공수 절감을 재는 3주차 대시보드가 정렬됩니다.
Java·Kotlin 기반 백엔드 역량을 기본으로 전사 프로젝트를 지원합니다. 규칙이 잡는 위반 패턴이 Java·Kotlin 백엔드 관용이라 언어 역량이 골조로 쓰입니다.
백엔드 PR의 변경 diff를 받아, LLM이 뽑은 위반 후보(규칙·심각도·근거 라인·리뷰 코멘트)를 규칙(diff 근거 없음·심각도 차단·미등록 서비스·표기 정규화)으로 검사해 자동승인 후보로 둘지 사람 리뷰로 돌릴지 머지를 막을지 정합니다. 결정은 사내 규칙셋과 diff 근거로 내리고, LLM은 위반 패턴 설명과 리뷰 코멘트 문장 작성만 보조합니다. 코드가 좋은지 나쁜지 총평하는 도구가 아니라 정해진 규칙 위반을 근거와 함께 걸러 라우팅하는 게이트입니다.
카카오페이 FDE. 전사 프로젝트에 합류해 백엔드 조직의 업무 현장에 들어가면, 매 PR마다 트랜잭션 경계·감사 로그·API 하위호환·예외 처리 같은 똑같은 지적을 사람이 반복해 다는 병목이 보입니다. 그 반복 리뷰를 규칙으로 자동화하고 남은 판단만 사람에게 돌려, 한 게이트에서 판정·근거·라우팅을 함께 보고 싶은 사람입니다.
PR 변경 diff를 규칙셋과 한 스키마로 묶으면, (a) 트랜잭션 경계 밖 외부 호출·감사 로그 누락·API 하위호환 깨짐·예외 삼킴을 규칙으로 걸러 리뷰 코멘트를 자동으로 달고, (b) diff에 근거가 없는 지적은 사람에게 돌려 오탐이 자동 차단으로 새지 않게 하며, (c) 도입 전후 리뷰 공수를 대시보드로 정량화합니다.
백엔드 PR diff를 받아 사내 규칙으로 위반을 판정하고 리뷰 코멘트를 자동으로 달아 자동승인 후보·사람 리뷰 필요·머지 차단으로 가르는 동작하는 게이트입니다. PR·diff·규칙셋은 결제 서비스 백엔드를 테마로 한 더미로 시작하고, 코드 저장소 연동 대신 diff 텍스트와 서비스 메타데이터를 입력으로 가정합니다.
게이트 판정을 심은 정답 라벨·리뷰어 2명 라벨과 비교해 정밀도·재현율과 일치도를 보여주는 화면입니다.
규칙 유형별 위반 분포와 자동승인 비율, 사람 리뷰로 넘어간 건수, 도입 전후 리뷰 처리 시간 추이를 집계해 공수 절감을 보여주는 AI 생산성 대시보드입니다.
리뷰 시나리오 12종(정상 PR·차단급 위반·근거 없는 지적)을 넣으면, 규칙 판정과 리뷰 코멘트, 라우팅 결과가 몇 초 안에 나오는 걸 시연합니다
일부러 만든 악성·결측 입력 30종(미등록 서비스·서비스명 표기 흔들림·diff 근거 없는 지적·심각도 경계값)을 넣어도 출력 형식(스키마)이 한 번도 안 깨집니다
더미에 심은 정답 라벨 44건 중 자동승인 후보·리뷰·차단 판정이 일치한 게 39건(약 89%)입니다. 단, 정답·데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 정밀도·재현율과 리뷰 공수 절감은 카카오페이의 실 저장소 PR과 실 리뷰어가 있어야 측정 가능합니다. 이 게이트는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다
이 포트폴리오는 diff 파싱·규칙 판정·근거 인용 LLM 코멘트 생성·심각도 라우팅 기술을 보여줍니다. 결제·정산의 규제 판단이나 핀테크 도메인 전문성은 포트폴리오로 증명되지 않으므로 주장하지 않으며, 결제는 샘플 코드의 테마로만 씁니다. 그 도메인 깊이는 면접에서 모르면 모른다고 말하는 편이 낫습니다
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 미등록 서비스·서비스명 표기 흔들림·diff 근거 없는 지적·심각도 경계값 같은 경계 케이스를 더미에 일부러 섞어, 쉬운 PR만 통과시키는 게 아님을 보여줍니다
LLM이 짚은 위반은 그럴듯해도 실제 diff에 근거가 없을 수 있습니다. 지적마다 diff 근거 라인 인용을 달게 하고, 근거가 없으면 자동승인·차단으로 새지 않게 '근거 없음'으로 사람 리뷰에 돌립니다
서비스명·규칙 표기가 제각각입니다. 정규화로 같은 서비스로 묶고, 못 묶은 건 추측하지 말고 '미등록 서비스'로 알립니다. 실제 도입 시 사내 코딩 컨벤션과 규칙셋이 더미와 다르므로 규칙을 다시 정의해야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
백엔드 PR 변경 단위 리뷰 로그. 규칙 판정 엔진이 가장 먼저 질의하는 테이블입니다. 미등록 서비스·서비스명 표기 흔들림·diff 근거 없는 지적·심각도 경계값을 일부러 섞고, label로 정답을 심어 자가채점합니다.
| pr_id | service_raw | service_id | lang | rule_id | rule_hit | grounded | severity | has_ticket_link | label | ts |
|---|---|---|---|---|---|---|---|---|---|---|
| pr_001 | 결제 서비스 | pay-core | Java | api_backward_incompat | true | true | block | true | block | 2026-05-04T09:00 |
| pr_002 | 정산 서비스 | settle | Kotlin | tx_boundary_violation | true | true | block | true | block | 2026-05-04T10:00 |
| pr_003 | 결제 서비스 | pay-core | Java | missing_audit_log | true | true | warn | true | needs_review | 2026-05-04T11:00 |
| pr_004 | 결제서비스 | pay-core | Kotlin | swallowed_exception | true | true | warn | false | needs_review | 2026-05-04T12:00 |
| pr_005 | 송금 서비스 | — | Java | none | false | true | — | true | needs_review | 2026-05-04T13:00 |
아래 Zod 스키마에 맞는 PR 리뷰 로그 60행 JSON 배열로 생성합니다. 서비스 3~4개, 규칙 유형 분포, 정상 위주에 리뷰·차단을 섞습니다. label 규칙: grounded=false → needs_review(근거 없는 지적은 사람에게), rule_hit=true 이고 severity=block → block, rule_hit=true 이고 severity in (warn,info) → needs_review, service_id=null → needs_review, 그 외(rule_hit=false·근거 있음·서비스 등록) → approve_candidate.
{"type":"object","properties":{"pr_id":{"type":"string"},"service_raw":{"type":"string"},"service_id":{"type":["string","null"]},"lang":{"type":"string","enum":["Java","Kotlin"]},"rule_id":{"type":"string"},"rule_hit":{"type":"boolean"},"grounded":{"type":"boolean"},"severity":{"type":["string","null"],"enum":["block","warn","info"]},"has_ticket_link":{"type":"boolean"},"label":{"type":"string","enum":["approve_candidate","needs_review","block"]},"ts":{"type":"string"}},"required":["pr_id","service_raw","service_id","lang","rule_id","rule_hit","grounded","severity","has_ticket_link","label","ts"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 PR만 통과시키는 함정 회피): (1) 같은 서비스의 표기 별칭('결제 서비스'/'결제서비스', '정산 서비스'/'정 산 서비스'처럼 service_master로 정규화돼야 함) 3건 이상, (2) 미등록 서비스(service_id=null) 2건, (3) diff 근거 없는 지적(grounded=false) 2건, (4) 경계값 severity=block 과 warn 과 info 각 2건 이상, (5) rule_hit=false 인 정상 PR 2~3건. label은 위 규칙대로 정직하게. JSON 배열만.{"type":"object","properties":{"pr_id":{"type":"string"},"service_raw":{"type":"string"},"service_id":{"type":["string","null"]},"lang":{"type":"string","enum":["Java","Kotlin"]},"rule_id":{"type":"string"},"rule_hit":{"type":"boolean"},"grounded":{"type":"boolean"},"severity":{"type":["string","null"],"enum":["block","warn","info"]},"has_ticket_link":{"type":"boolean"},"label":{"type":"string","enum":["approve_candidate","needs_review","block"]},"ts":{"type":"string"}},"required":["pr_id","service_raw","service_id","lang","rule_id","rule_hit","grounded","severity","has_ticket_link","label","ts"]}| Java | 리뷰 대상 백엔드 코드가 Java로 작성돼, 규칙이 Java 관용 위반(예외 삼킴·트랜잭션 경계 밖 호출)을 잡는 언어입니다 |
| Kotlin | 결제 서비스 일부가 Kotlin이라, 같은 규칙셋이 Kotlin diff에서도 감사 로그 누락·API 하위호환 깨짐을 잡습니다 |
| Python | 규칙 유형별 위반 분포·리뷰 공수 절감을 집계하는 3주차 대시보드 데이터 파이프라인 구현 언어입니다 |
| TypeScript | diff 파서·규칙 판정 엔진·출력 스키마·게이트 화면의 구현 언어입니다 |
| LLM | 변경 diff에서 위반 패턴을 짚어 근거 라인을 인용하고 리뷰 코멘트 문장을 생성하는 엔진입니다 |
| Claude | 리뷰 코멘트 생성·근거 인용 LLM입니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(판정이 맞았는지 확인)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(도입 전후 리뷰 공수 대시보드)로 진행합니다.
PR 변경 1건의 리뷰 결정 카드. 결정·위반 요인·근거 라인·리뷰 코멘트를 한 스키마로 담아 화면 카드에 씁니다. 코드 총평이 아니라 규칙 정합성 게이트입니다.
{"type":"object","properties":{"pr_id":{"type":"string"},"service_id":{"type":["string","null"]},"decision":{"type":"string","enum":["approve_candidate","needs_review","block"]},"factors":{"type":"array","items":{"type":"string","enum":["api_backward_incompat","tx_boundary_violation","missing_audit_log","swallowed_exception","n_plus_one_query","ungrounded","unmapped_service"]}},"line_ref":{"type":"string"},"comment":{"type":"string","minLength":20},"evidence":{"type":"string","minLength":8},"hedge":{"type":["string","null"]}},"required":["pr_id","service_id","decision","factors","line_ref","comment","evidence","hedge"]}[
{
"input_ref": "pr_002 (트랜잭션 경계 밖 외부 호출)",
"output": {
"pr_id": "pr_002",
"service_id": "settle",
"decision": "block",
"factors": [
"tx_boundary_violation"
],
"line_ref": "SettlementService.kt:142",
"comment": "트랜잭션 경계 밖에서 외부 결제 API를 호출해 실패 시 정산 레코드가 부분 커밋됩니다. 호출을 트랜잭션 밖으로 빼거나 보상 처리를 넣기 전에는 머지를 막습니다.",
"evidence": "rule_id=tx_boundary_violation, severity=block, grounded=true",
"hedge": "심각도 차단 규칙이라 자동승인하지 않습니다"
}
},
{
"input_ref": "pr_006 (지적에 diff 근거 없음)",
"output": {
"pr_id": "pr_006",
"service_id": "pay-core",
"decision": "needs_review",
"factors": [
"ungrounded"
],
"line_ref": "미상",
"comment": "N+1 쿼리 가능성이 지적됐지만 변경 diff에서 해당 반복 조회 라인을 찾지 못했습니다. LLM이 근거 없이 지적했을 수 있어 자동으로 막지 않고 사람 리뷰로 돌립니다.",
"evidence": "grounded=false, rule_id=n_plus_one_query",
"hedge": "diff 근거를 못 찾아 사람 확인이 필요합니다"
}
},
{
"input_ref": "pr_005 (서비스 마스터 미등록)",
"output": {
"pr_id": "pr_005",
"service_id": null,
"decision": "needs_review",
"factors": [
"unmapped_service"
],
"line_ref": "미상",
"comment": "변경 대상 서비스가 서비스 마스터에 등록돼 있지 않아 어느 규칙셋을 적용할지 정할 수 없습니다. 서비스 등록 후 재평가가 필요해 사람 리뷰로 돌립니다.",
"evidence": "service_raw=송금 서비스, service_id=null",
"hedge": "미등록 서비스라 규칙셋을 특정하지 못했습니다"
}
}
][자동 검증] 1. Zod parse로 출력 형식(필드·enum)이 스키마를 통과하는지 확인합니다. 2. decision이 라우팅 규칙(근거 없음→needs_review·심각도 차단→block·경고/정보→needs_review·미등록 서비스→needs_review·정상→approve_candidate)과 일치하는지 봅니다. 3. evidence가 입력 PR의 실제 값 인용인지 토큰 매칭으로 확인하고, grounded=false면 block이 되지 않게 강제합니다. 4. decision을 심은 정답 label과 비교해 정밀도·재현율을 계산합니다. [수동 검증] 1. 리뷰어 2명이 비동기로 판정을 라벨링해 정밀도·재현율과 bootstrap Cohen's κ(두 사람 일치가 우연 이상인 정도, 0~1) 하한 0.6 이상을 봅니다. 2. 전체의 5%를 사람이 직접 점검합니다.
근거: 내부 조직의 업무 현장에 들어가 AI 적용 가치가 큰 병목 지점을 발견