본문 바로가기

전체 글

 (182)
PG 전환 3편 - 정산 자동화와 장애 대응, 시스템이 보장해야 한다 이 글은 카카오 PG에서 토스 PG로 전환하는 과정에서 마주한 구조적 문제와 해결 과정을 정리한 시리즈의 세 번째 글입니다.1부. 정산 자동화문제PG 전환 이전, 정산 과정은 경영 기획실에서 주 단위로 수동으로 진행되고 있었다. 매주├── 내부 정산 데이터 추출├── 예약 데이터 추출└── 엑셀 수식 폼에서 수동 비교 겉으로 드러나는 문제는 없었다. 하지만 구조적으로 두 가지 문제가 있었다. PG 실제 정산 데이터와 비교하지 않았다. 내부 데이터끼리만 대사를 진행했기 때문에, PG와의 누락이 발생해도 발견할 수 없는 구조였다.사람이 하는 작업은 언제든 실수가 발생할 수 있다. 정산의 신뢰도가 시스템이 아닌 사람에 의존하는 구조였다.그래서 PG 전환을 계기로 정산 프로세스 전반을 자동화하기로 했다.개선정산..
PG 전환 2편 - 결제와 예약, 상태가 어긋날 때 이 글은 카카오 PG에서 토스 PG로 전환하는 과정에서 마주한 구조적 문제와 해결 과정을 정리한 시리즈의 두 번째 글입니다.문제PG 전환 작업을 진행하면서 기존 시스템에서 반복적으로 발생하던 문제를 발견했다. 결제와 예약의 상태가 서로 어긋나는 현상이었다. 구체적으로 두 가지 케이스가 있었다.케이스 1. 결제 취소 완료 → 예약은 완료 상태로 남음결제 취소 응답은 PG로부터 정상적으로 받았다. 하지만 예약 상태가 취소로 업데이트되지 않는 경우가 발생했다. 원인을 추적해보니 취소 후 실행되는 후처리 로직 구조가 문제였다. 결제 취소 응답 수신 ↓후처리 로직 실행 (try-catch로 전체 묶임)├── 헤어짱 예약 취소 요청├── 디자이너 예약 가능 시간 업데이트├── 예약 취소 알림 발송└── DB ..
PG 전환 1편 - 결제 시스템의 구조적 문제 이 글은 카카오 PG에서 토스 PG로 전환하는 과정에서 마주한 구조적 문제와 해결 과정을 정리한 시리즈의 첫 번째 글입니다.배경서비스에서 사용하던 카카오 PG 계약이 종료되면서 토스 PG로의 전환이 필요했다. 전환 대상은 전체 약 3~4만개 매장이었다. 리스크를 줄이기 위해 매출 규모 기준으로 약 1,000개 매장을 먼저 전환하고, 이상이 없으면 전체 매장으로 확대하는 방식을 택했다. 1차 전환 대상의 일 결제 건수는 약 300건 규모였다. 1차 전환까지 주어진 기간은 2주였다. 개발은 혼자 담당했고, 정산 계산식 검증을 위해 경영 기획실, 매장 전환 안내를 위해 성장 기획실과 커뮤니케이션하며 진행했다. 처음에는 단순한 외부 서비스 교체라고 생각했다. 하지만 실제로는 결제 시스템 전반의 구조적인 문제를 ..
코드 리뷰 스킬을 테스트하다가 문제 정의를 다시 했다 Claude Code 스킬을 만들고나서 "이 스킬이 실제로 얼마나 잘 잡는가" 궁금해졌다.성능 확인을 위해 임시 코드(좋은 코드, 나쁜 코드, 모호한 코드)를 작성하고 스킬을 돌려 결과를 확인했다. 같은 스킬을 사용해 동일한 코드에 대한 리뷰를 시켰을 때, 사전에 미리 만들어 놓은 정답지에 부합하게 결과가 나왔다. 정답지 / 스킬 리뷰 결과더보기 코드 리뷰 스킬이 내가 정의한 리뷰 기준에 따라 잘 잡아주다보니, 이것저것 더 넣고싶은 것이 생겼다. 그래서 "한 줄이 100자 이내", "하나의 메서드는 50줄 이내" 등 코드 컨벤션부터 해서 추가하기 시작했다. 처음에는 더 정교해지는 것 같아 잘 만들어지고 있다고 느꼈다. 그런데 체크리스트가 계속해서 늘어나자 스킬은 무거워졌고 오히려 목적이 흐릿해지는 ..
Claude Code를 통해 코드 리뷰 스킬을 만들며 배운 것 SNS와 유튜브에서 AI에 대한 수많은 이야기를 봤지만, 개발자인 나에게 가장 크게 와 닿은 말은 이것이었다.누구나 상상한 것을 바로 만들어볼 수 있는 시대가 왔다. 작은 아이디어조차 늘 머릿속에서만 맴돌던 내게 그 말은 꽤 큰 울림이었다. 그래서 더 고민하지 않고, Claude Code를 통해 간단한 코드 리뷰 스킬을 직접 만들어보기로 했다.직접 만들어보기테스트 대상은 Java Spring, JPA 환경에서 개발한 사이드 프로젝트 Lifepuzzle이었다.프로젝트 구조를 함께 전달하자 Claude Code는 맥락을 기반으로 코드 리뷰 스킬을 구성해주었다. 처음 만든 스킬은 리뷰가 일관되지 않았다. 때로는 사소한 네이밍을 지적했고, 때로는 아키텍처를 문제 삼았다.무엇을 가장 중요하게 보는지 알 수 없는 ..
AWS 대신 Mac mini로 홈서버 구축하기: Minikube로 애플리케이션 이전 DB를 Minikube로 옮긴 이후에 애플리케이션을 이전을 진행하기로 했습니다. 이전하면서 CD 환경도 같이 구성을 하였습니다. 하면서 중요하게 생각했던 부분들에 대해서 작성해보려고 합니다.이미지 기반 배포 전략기존에는 애플리케이션을 컨테이너 기반으로 실행하고 있었기 때문에, 이미지를 어디에 저장하고 어떻게 가져다 쓸지가 핵심 이슈였습니다. 가장 먼저 고려한 저장소는 Docker Hub였지만, 무료로 사용할 수 있는 범위가 제한적이라 다른 대안을 찾아야 했습니다.그래서 선택한 것이 GitHub Container Registry(GHCR)입니다. ✔ GitHub 프로젝트와의 연동이 용이 ✔ 퍼블릭 저장소 기준으로는 비용이 무료 ✔ GitHub Actions와의 통합도 용이GitHub Actions..
AWS 대신 Mac mini로 홈서버 구축하기: Minikube로 MySQL 이전 Mac mini 홈서버로 전환 이유사이드 프로젝트에서 AWS 비용이 매달 약 10만 원이 발생하다 보니, 자연스럽게 대체재를 고민하게 되었습니다. 그러던 중 이미 보유하고 있던 Mac mini(M1) 기기를 활용해 홈서버를 구축해 보기로 했습니다. 전기세 등을 고려했을 때 월 1,000원 이하로 유지 가능하다는 점도 큰 매력으로 다가왔습니다.1. 유지하고 이전할 서비스 구분이미지, 동영상 등 유저가 등록한 데이터를 저장할 공간은 여전히 필요하므로 S3는 그대로 유지하기로 했습니다. 반면 가장 비용이 많이 드는 EC2에 배포된 자바 애플리케이션과 RDS(MySQL)는 홈 서버로 이전하기로 했습니다. 이 중 MySQL을 우선적으로 이전하기로 했습니다. 추가로 비용 문제로 운영하지 못했던 테스트 환경도 함께 ..
어뷰징 대응의 시작 - 고정 윈도우 기반 Rate Limit 시범 운영기 1. 투표의 신뢰를 지키기 위한 첫 대응 이전 시상식 기간 중 매크로 사용과 다중 계정 생성 정황이 포착되었고, 행동이 이상한 일부 유저에 대해 CS 인입 및 커뮤니티 내 매크로 사용법 공유 사례도 있었습니다.회사의 투표 시스템 신뢰성 강화를 위해, 이러한 어뷰징 유저 탐지 및 단속의 필요성이 높아졌습니다. 2. 작게 시작한 시범 운영, 리스크를 최소화하다 이번 시상식에서 투표 기간 중에 시범적으로 어뷰징 탐지 시스템을 만들어 운영해보기로 했습니다. 처음 적용하는 시스템이면서 해당 시스템이 우리가 예상한대로 동작했을 때 이점보다, 동작하지 않았을 때 리스크가 더 크다고 판단이 되었기 때문입니다. 고정 윈도우 기반의 간단한 탐지 체계를 구성해 특이 행동을 모니터링하고, 개발자가 수동으로 판단 및 조치하는 ..

티스토리툴바