카카오페이

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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