kakaopay

문제공통 컴포넌트 라이브러리는 시간이 갈수록 누가 관리하고, 어떻게 기여 받고, breaking change 는 어떻게 알릴지 모호해진다.

접근카카오페이가 공통 컴포넌트 운영 framework 를 정리. 명확한 ownership 모델, 기여 가이드, semver 룰, deprecation 정책까지.

결과라이브러리가 "건강하게" 유지되며 새 기능 추가도 빠르다. 디자인 시스템 / 라이브러리 운영의 참고 사례.

문제수억 건의 거래 데이터를 단일 테이블에 넣으면 쿼리 / 인덱스 / 백업 모두 비효율적이 된다.

접근카카오페이가 DB 파티셔닝(range / list / hash) 을 선택 기준에 따라 적용. 파티션 키 마이그레이션, 인덱스 재구성, 운영 시 마주친 함정까지 정리.

결과대용량 쿼리 성능 개선 + 백업 / 보관 정책 효율화. 실측 성능 개선 데이터까지 공유.

문제"자연어 spec → AI 가 코드까지 작성" 워크플로의 현실은? 도메인 컨텍스트를 어떻게 spec 에 녹이는가.

접근카카오페이가 SDD(Spec-Driven Development) + spec-kit 에이전트 코딩을 실전 도입. spec 의 구조화, 컨텍스트 주입 방법, 에이전트가 만든 코드 검증 단계까지.

결과spec 만으로 신뢰할 수 있는 코드 생성이 가능한 영역과 그렇지 않은 영역을 식별. 점진 적용 framework 정리.

문제Yarn Berry 가 한때 "새로운 표준" 으로 도입됐지만 모노레포 빌드 속도, lockfile 안정성에서 한계가 노출됐다.

접근카카오페이가 pnpm 으로 전환. install 시간, dependency 처리, monorepo 운영 비교 데이터를 정리.

결과"그때는 맞고 지금은 틀리다" 의 의사결정 변화 사례. 도구 선택은 시대에 따라 다르다는 교훈.

문제JVM 기반 서비스를 배포 직후 트래픽 받으면 JIT 컴파일이 완료되기 전이라 응답 지연이 튄다.

접근카카오페이가 예열 트래픽 주입, AOT 컴파일 활용, 트래픽 점진 증가(canary 비율 조절) 를 조합한 웜업 전략 설계.

결과배포 직후 latency 스파이크 제거. 사용자 체감 영향 없이 안전한 배포 가능.

문제일 41TB, 200억 건 로그를 실시간 처리하면서 비용까지 통제해야 한다. 상용 observability 도구로는 비용이 부담된다.

접근카카오페이 "호그와트 도서관" 프로젝트 — ClickHouse 기반 ClickStack 스택을 자체 구축. 데이터 모델링, 인덱스 전략, 비용 / 성능 트레이드오프 정리.

결과페타바이트 스케일 로그를 자체 운영으로 처리 가능. 상용 대비 비용 대폭 절감.

문제프론트엔드 프로젝트가 커지면서 "이 코드는 어디에 넣어야 할까" 가 매번 의사결정 비용이 된다. 명확한 구조가 없으면 의존성이 얽혀 사이드 이펙트와 유지보수 부담이 커진다.

접근Feature-Sliced Design(FSD) 아키텍처를 도입. 코드를 Layers / Slices / Segments 세 차원으로 분리해 재사용 가능한 로직을 통제하고 응집도·결합도를 관리한다. 적용 과정을 단계별로 코드 레벨로 기록.

결과코드 위치의 명확성과 구조적 안정성을 확보한다. 프로젝트 규모가 커져도 새 기능 추가 시 "어디에 넣어야 하나" 라는 질문이 줄어든다.

문제카카오페이의 기존 AI 시스템은 반복적인 수작업·레거시 서빙 파이프라인으로 모델 배포 속도와 안정성이 떨어졌다. 표준화·확장·통합 부재가 기술 부채로 누적.

접근Kubeflow 기반 AI 플랫폼을 구축하고 H200 GPU · MIG · 하이브리드 클러스터 등 고성능 하드웨어를 도입. 금융 규제와 기존 클러스터 제약 안에서 학습·서빙·실험 환경을 통합한다.

결과모델 학습 · 등록 · 서빙이 표준 플로우로 묶인다. AI 적용 속도와 안정성을 동시에 끌어올리는 기반을 마련했다.

문제모바일 앱 테스트는 OS 버전·해상도별로 실제 기기가 필요하다. 기기 관리·할당 비용이 커지고, 기획자·디자이너도 테스트 환경 구축에 시간을 쓰게 된다.

접근가상 기기 기반 macOS 앱 "멀티버스" 를 자체 개발. 맥북 한 대로 iOS / 다양한 OS 버전 / 해상도 환경에서 페이 앱을 테스트할 수 있도록 가상 기기 풀과 테스트 편의 기능을 제공한다.

결과기기 부족·관리 비용 문제를 해소하고 개발자·기획자·디자이너가 같은 도구를 공유. 사내 테스트 플랫폼이 "동료를 고객으로 본다" 는 관점의 성공 사례가 됐다.

문제카카오페이증권은 모니터링·옵저버빌리티 같은 기술 영역 가시화는 고도화돼 있었지만, "고객 관점에서 지금 어떤 불편을 겪고 있는가" 를 빠르게 파악할 수단이 부족했다.

접근서비스 상태 가시화 + 장애 관리 자동화 프로젝트 "핑크와드" 를 구축. 장애 감지 → 지라 티켓 · Slack 채널 생성 → 담당자 초대 → 고객센터 공유까지의 흐름을 자동화하고, 고객 관점 상태 보드를 노출한다.

결과장애 등록·전파 시간이 줄고 고객 경험 영향도 실시간으로 가시화된다. "고객이 지금 어떤 불편을 겪는가" 를 운영 의사결정의 1급 신호로 끌어올렸다.

문제백엔드 개발자가 LLM 을 활용하면서 "왜 이 프롬프트가 잘 되고 저건 안 되는지" 를 직관으로만 이해한다. 내부 동작을 모르면 활용·디버깅에 한계가 있다.

접근LLM 의 응답 생성 과정을 토큰화 → 임베딩 → 위치 인코딩 → 트랜스포머·어텐션 → 예측 → 디코딩 6단계로 압축. 각 단계의 동작과 백엔드 개발자가 알아야 할 핵심만 골라 설명한다.

결과깊은 수식 없이 LLM 의 동작 모델을 머릿속에 그릴 수 있게 만든다. 프롬프트 작성·서비스 설계 의사결정에 "왜 그런지" 를 답할 수 있는 기반을 제공.

문제카카오페이가 제공하는 결제·송금·자산관리 등 서비스가 다양하지만, 사용자가 필요한 순간에 적절한 서비스를 떠올리고 찾기는 어렵다.

접근사용자의 위치·시간·이용 기록을 분석해 능동적으로 서비스를 추천하는 AI 컨시어지 "페이지니" 를 개발. AWS Bedrock 기반 멀티 에이전트가 "전체 서비스 추천" 과 "가맹점 혜택 추천" 을 분담하고, STT · TTS · RAG · 프롬프트 엔지니어링을 조합한다.

결과검색이 아닌 능동적 발견 경험을 제공한다. 멀티 에이전트 구조로 새로운 추천 도메인을 모듈처럼 확장할 수 있게 설계.

문제대출 시장의 정보 불균형 때문에 사용자는 자기 상황에 맞는 상품을 알아보는 과정 자체에 불안감을 느낀다. 기존 챗봇은 "무엇을 묻고 무엇을 결정할지" 까지 도와주지 못한다.

접근AWS Bedrock 의 Knowledge Base 와 Agent 답변 지침으로 할루시네이션을 억제하면서 RAG 기반 "AI 대출 코치" 를 1박 2일 해커톤에서 구현. 사용자 상황을 단계별로 묻고 의사결정을 가이드한다.

결과대출 과정의 불확실성을 줄여 사용자가 주체적으로 선택할 수 있게 돕는다. 짧은 해커톤 안에서도 LLM 의 정확도와 UX 를 동시에 잡는 패턴을 정리.

문제카카오페이 결제 API 를 AI 에이전트와 연동하려면 OpenAI function calling·LangChain tool 같은 프레임워크별 어댑터를 일일이 작성해야 했다. 표준이 없어 유지보수 비용이 커진다.

접근Model Context Protocol(MCP) 을 도입해 결제·정기결제 등 8개 Tool 을 표준 규격으로 설계. LangChain, OpenAI, Vercel AI SDK 등 여러 프레임워크에서 같은 Toolkit 을 그대로 쓸 수 있게 멀티 프레임워크 어댑터를 함께 제공한다.

결과결제 API 가 AI 에이전트 생태계 전반에 한 번의 연동으로 노출된다. 자연어로 결제·정기결제 흐름을 다룰 수 있는 표준화된 발판을 마련.

문제카카오페이손해보험의 암호화 모듈이 정적 메서드 위주의 유틸리티 클래스로 짜여 있어 규정 변화·라이브러리 업그레이드에 취약했다. 호환성 문제로 AEM 알람이 빈번히 울렸다.

접근도메인 개념 기반으로 리팩토링하면서 암호화 기본기(대칭/비대칭, 키 관리, 시저→AES 까지 발전사) 를 정리. 키를 "무엇을 어떻게 보호하는가" 의 1급 도메인 개념으로 끌어올려 알고리즘 교체를 안전하게 만든다.

결과보안 규정 변화에 대응할 수 있는 확장 구조를 갖춘다. 엔지니어가 알아야 할 암호화 기본기와 실무 노하우를 같이 정리.

문제카카오페이 머니 충전 서비스에서 Next.js SSR 환경에서 CORS 에러와 Version Skew(구·신 버전 자원 불일치) 가 발생. 일정 압박과 사내 인프라 제약이 더해져 가설 검증이 어려웠다.

접근가설을 좁히는 디버깅 사이클로 접근. `crossOrigin` 속성, dynamic import 로 청크 로딩 시점 분리, SessionStorage 로 버전 상태 추적 등 SSR/CSR 경계에서 안전한 패턴을 도입.

결과CORS · Version Skew 양쪽을 모두 해결. 비슷한 상황에서 적용할 디버깅 흐름과 배포 전략까지 함께 문서화.

문제카카오페이 후불결제(BNPL) 의 여신코어는 대출·심사·승인 같은 복잡한 도메인 규칙을 다룬다. 절차적 설계로는 도메인 변경이 곧 코드 곳곳의 수정으로 번지기 쉽다.

접근DDD(Domain Driven Design) 를 적용. 도메인 전문가와 공용하는 유비쿼터스 언어를 정의하고, Spring Multi Module 환경에서 도메인·애플리케이션·인프라 모듈을 분리한다. Entity 와 Repository 의 책임을 명확히 한다.

결과도메인 규칙 변화가 도메인 모듈 안에서 닫힌다. 신규 시스템 구축 시 DDD 적용 패턴과 실패 포인트를 코드 레벨로 공유.

문제증권업은 99.999% 가용성이 사실상 의무다. 단일 클라우드·단일 클러스터 의존은 장중 거래량 급변·플랫폼 장애에 취약하다.

접근AWS EKS · IDC Kubernetes · KakaoCloud KE 세 플랫폼에 같은 서비스를 분산 배포하는 멀티 / 하이브리드 클러스터 구조를 설계. 장애 시 트래픽을 다른 클러스터로 흘리도록 라우팅·헬스체크·배포 파이프라인을 통일.

결과클라우드 종속을 줄이면서 99.999% 에 가까운 가용성을 추구한다. 장중 변동성에 유연하게 대응할 수 있는 인프라 토대를 확보.

문제비대면 대출은 정보 비대칭과 의사결정 부담이 커서, 사용자가 자기 상황에 맞는 상품을 직접 찾기 어렵다. 텍스트 챗봇만으로는 상담 부재 문제를 해결하지 못한다.

접근Amazon Transcribe · Bedrock · Polly 로 음성 입력 → 텍스트 변환 → 응답 생성 → 음성 합성 파이프라인을 구축. 개인정보 이슈를 피하려 합성 데이터를 만들고, RAG 로 맞춤형 대출 상품 추천을 강화한다.

결과비대면 환경에서도 음성 기반 1:1 상담 경험을 구현했다. AWS AI 서비스 조합으로 금융 도메인에 맞는 생성형 AI 활용 패턴을 정리.

문제카카오페이 통합내역의 거래 데이터는 단순 기록으로만 소비된다. 사용자가 자신의 소비 흐름을 직관적으로 탐색·기억하기 어렵다.

접근해커톤 프로젝트 MOZ 가 거래 내역에 메모를 추가하고 시각적으로 요약된 이미지 캘린더를 생성. AWS Nova Canvas 로 이미지, Claude 3.5 기반 Text2SQL · tool calling 으로 자연어 검색을 구현한다.

결과거래 내역을 "감성과 지능" 이 더해진 일기 형태로 변환했다. 자연어 검색이 특정 거래 회상을 쉽게 만들어 해커톤 2등을 수상.