카카프로덕트 엔지니어 - 사내 생산성 플랫폼
3.8 (312)카카오페이
경력근거: 조직의 일하는 방식 자체를 다시 설계하는 카카오페이 AX(AI Transformation)
어제 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
카카오페이 AX 조직은 단순 AI 도구 도입을 넘어 조직의 일하는 방식 자체를 다시 설계하며 비즈니스 난제를 기술로 풉니다. 이 도구는 카카오페이가 다루는 업무 프로세스와 효과·난이도 기준이 있어야 의미가 생기고, 막연한 AI 도입이 아니라 단계에 붙는 기회 목록이 됩니다.
공고가 단순 AI 도구 도입을 넘어 조직의 일하는 방식을 다시 설계하는 AX 의 최전선이라고 밝힌다. 자동화 기회 발굴 도구가 그 진입점이다.
비즈니스 핵심 난제를 깊이 고민해 기술 해결책을 서비스에 녹인다. 프로세스를 단계로 받아 자동화 지점을 짚는 구조가 맞는다.
조직 역량을 AI 로 증폭해 생산성을 끌어올리는 자리라, 기회를 효과·난이도로 우선순위화하는 도구가 직결된다.
사내 업무 AX 기회 발굴 도구입니다. 업무 프로세스 설명을 받아 AI 자동화 가능 단계와 기대 효과·난이도·우선순위를 근거 배열과 함께 냅니다.
카카오페이 프로덕트 엔지니어(AX)와 자동화 대상 업무 담당입니다.
업무 프로세스 단계 설명만으로도 자동화 기회와 효과·난이도의 1차안을 만들 수 있고, 담당자는 그 우선순위를 보고 어디부터 손댈지 정하면 됩니다.
업무 프로세스 단계 설명(누가·무엇을·얼마나 자주·도구)을 넣으면 AI 자동화 가능 단계와 기대 효과·난이도·우선순위를 근거 배열과 함께 내는 웹 도구입니다. 실제 사내 시스템 연동은 빼고 프로세스 설명 메타가 주어졌다는 가정으로만 시작한다(실 연동·실측 효과는 빠진 20% 작업이라 W3로 분리).
1주차 결과를 사람 AX 담당 정답(자동화 적합·난이도)과 비교해 헛짚은 기회를 재고, 우선순위 기준을 보정한 v2.
각 기회에 구현 스케치(필요 데이터·모델·가드)와 규제·민감정보 리스크 플래그를 붙여 착수 직전 골격까지 만드는 확장판입니다.
업무 프로세스 설명 한 건을 넣으면 자동화 기회와 효과·난이도·우선순위, 그 근거가 한 화면에 나오는 걸 시연합니다.
기회 근거가 모두 입력 프로세스 단계를 가리키는지 judge 로 검사해 근거 인용율 100%를 보여줍니다. 단, 정답·데이터를 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
결측 단계·모호 설명·민감정보 함정을 일부러 섞은 프로세스 30종을 넣어도 출력 JSON 형식이 안 깨지고 '설명부족·민감주의'로 알리는 걸 시연합니다.
기회 판정과 합성 정답의 일치도를 Cohen's κ(두 채점자가 우연 이상으로 얼마나 일치하는지 -1~1 점수, 높을수록 일치)로 2주차에 보고합니다. 합성 기준 추정이라 실제와 다를 수 있습니다.
위 수치는 더미데이터 자가채점이며, 실제 자동화 효과는 카카오페이 실 업무 데이터와 실 AX 담당 판단이 있어야 측정 가능합니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 결측 단계·모호 설명·민감정보 함정을 더미에 일부러 섞어 쉬운 문제만 푸는 함정을 피합니다.
자동화 가능해 보여도 규제·민감정보 때문에 실제로는 막힐 수 있습니다. 실데이터 도입 단계에서 규제 검토를 선행 과제로 분리합니다.
실제 도입 시 합성 정답이 실 AX 판단으로 바뀌고 업무·조직도 달라집니다. 효과·난이도 기준과 자동화 유형 enum 을 실 업무로 다시 맞추는 일을 도입 과제로 둡니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
팀 업무 프로세스 단계 설명. 자동화 기회 발굴의 입력.
| step_id | process | actor | action_text | frequency | tool_raw | sensitive |
|---|---|---|---|---|---|---|
| WP01 | 정산 마감 | 재무팀 | 매일 거래 내역을 받아 엑셀로 분류하고 합계를 검증 | daily | Excel | true |
| WP02 | 정산 마감 | 재무팀 | 분류 결과를 사내 시스템에 수기 입력 | daily | 사내ERP | true |
| WP03 | 고객 문의 대응 | CS팀 | 문의를 읽고 유형을 나눠 담당자에게 전달 | daily | 헬프데스크 | false |
| WP04 | 그거 | — | 맨날 하는 그 작업 | — | false | |
| WP05 | 리스크 점검 | 리스크팀 | 거래 로그에서 이상 패턴을 찾아 보고서로 정리 | weekly | BI도구 | true |
다음 Zod 스키마를 따르는 업무 단계를 더 생성하라: {"type":"object","properties":{"step_id":{"type":"string"},"process":{"type":"string"},"actor":{"type":["string","null"]},"action_text":{"type":"string"},"frequency":{"type":["string","null"],"enum":["daily","weekly","monthly","adhoc"]},"tool_raw":{"type":"string"},"sensitive":{"type":"boolean"}},"required":["step_id","process","actor","action_text","frequency","tool_raw","sensitive"]}. 쉬운 데이터만 만들지 말 것 — 다음 하드 케이스를 의도적으로 섞어라: actor 나 frequency 가 null 인 미상, action_text 가 '맨날 하는 그 작업' 처럼 모호한 건, tool_raw 가 빈 문자열인 미기록, sensitive true 인 개인정보·금융정보 단계(자동화 시 규제 주의). 추가로 형식 깨뜨리기 시도 3건(타입이 어긋난 행)을 별도 표시해 파서 가드 테스트에 쓴다.{"type":"object","properties":{"step_id":{"type":"string"},"process":{"type":"string"},"actor":{"type":["string","null"]},"action_text":{"type":"string"},"frequency":{"type":["string","null"],"enum":["daily","weekly","monthly","adhoc"]},"tool_raw":{"type":"string"},"sensitive":{"type":"boolean"}},"required":["step_id","process","actor","action_text","frequency","tool_raw","sensitive"]}| Python | 발굴 엔진 런타임. 프로세스 파싱·LLM 호출·스키마 검증·우선순위 규칙을 묶는다. |
| TypeScript | 기회·우선순위를 보여주는 검토 화면의 타입 안전한 로직. |
| Java | 사내 백엔드(Java/Kotlin)에서 나오는 프로세스 메타를 받는 어댑터 예시 작성. |
| Kotlin | 기존 서버 스택과 맞춘 수집·조회 API 구성. |
| LLM | 프로세스 단계를 보고 자동화 기회와 효과·난이도·근거를 생성한다. |
| LLM-as-judge | 기회 근거가 실제 단계 설명을 인용했는지 검사하는 보조 모델. |
✓ pass → 여기서 멈춰도 AX 발굴 보조 도구로 완결입니다. 더 키우려면 2주차에서 정답과 비교해 헛짚은 기회를 보정합니다.
✓ pass → 신뢰가 붙으면 3주차에서 구현 스케치와 리스크 플래그로 넓힙니다.
업무 단계 한 건에 대한 AI 자동화 기회와 우선순위.
{"type":"object","properties":{"step_id":{"type":"string"},"automatable":{"type":"string","enum":["yes","partial","no","review"]},"auto_type":{"type":"string","enum":["extract","classify","generate","route","summarize","none"]},"effort":{"type":"string","enum":["low","mid","high"]},"priority":{"type":["number","null"]},"risk_flag":{"type":"string","enum":["none","sensitive","regulated"]},"evidence":{"type":"array","items":{"type":"object","properties":{"field":{"type":"string","enum":["action_text","frequency","tool_raw","sensitive"]},"note":{"type":"string"}},"required":["field","note"]},"minItems":1},"hedge":{"type":"string"}},"required":["step_id","automatable","auto_type","effort","priority","risk_flag","evidence","hedge"]}[
{
"step_id": "WP03",
"automatable": "yes",
"auto_type": "classify",
"effort": "low",
"priority": 8,
"risk_flag": "none",
"evidence": [
{
"field": "action_text",
"note": "'유형을 나눠 전달' 은 분류 자동화 적합"
},
{
"field": "frequency",
"note": "daily 라 효과 큼"
}
],
"hedge": "효과·난이도는 합성 기준 추정이라 실 업무와 다를 수 있다."
},
{
"step_id": "WP02",
"automatable": "partial",
"auto_type": "extract",
"effort": "high",
"priority": 5,
"risk_flag": "sensitive",
"evidence": [
{
"field": "sensitive",
"note": "사내ERP 수기 입력은 민감정보라 가드 필요"
},
{
"field": "action_text",
"note": "수기 입력 일부 자동화 가능"
}
],
"hedge": "민감정보라 자동화 범위는 규제 검토 후 확정. 합성 기준."
},
{
"step_id": "WP04",
"automatable": "review",
"auto_type": "none",
"effort": "mid",
"priority": null,
"risk_flag": "none",
"evidence": [
{
"field": "action_text",
"note": "'맨날 하는 그 작업' 뿐이라 단계 불명, 확인필요"
}
],
"hedge": "모호 설명이라 판정 보류. 합성 기준."
}
]automatable·auto_type·effort·risk_flag enum, evidence min(1)은 Zod 로 자동 검증한다. priority 계산(효과×빈도÷난이도)은 규칙 엔진으로 자동 검증하고, 자동화 적합·근거 의미·hedge 의 합성 기준 표기는 judge 와 수동 spot-check 로 검증한다. priority 는 합성 기준이라 metrics 의 정직 경계선과 일관되게 검증된 수치로 제시하지 않는다.