개발
코드 / 아키텍처 / 디버깅
-
가맹점 수수료 요율 검증으로 마진 역전 버그 차단
문제: 요율 한 번 잘못 바꿨더니 마진이 음수가 됨 파트너 관리 화면에서 가맹점 충전 수수료를 0.5%로 내려달라는 요청 받음. 별생각 없이 업데이트했더니 운영팀에서 바로 핑이 옴. "이거 총판이 0.7% 받고 있는데, 가맹점이 0.5%면 총판이 -0.2% 손실 보는 거 아님?" 맞는 말이었음. 원래 구조 다시 정리해봄: - 가맹점이 가장 높은 요율
읽기 → -
파트너 정산 이중 차감과 화면별 잔액 오차 수정
정산 중복 처리, 또 너냐 파트너 정산 화면에서 같은 건이 두 번 차감되는 이슈. 결제 플랫폼 쪽에선 흔한 패턴이긴 한데, 이번엔 정산·대시보드·파트너 어드민·파트너 화면 컨트롤러 4개를 동시에 손봐야 했음. 한 곳만 고치면 다른 화면에서 다시 어긋나서, 결국 합계 산식을 원장 수준에서 한 번에 정리함. 무엇이 문제였나 - 충전 수수료, 결제 수수
읽기 → -
가맹점 계좌 승인 알림 누락과 사이드바 메뉴 미노출 수정
계좌 승인 알림이 사라진 이유 파트너 포탈에서 신규 가맹점 계좌 등록 후 관리자 승인 알림이 안 떴음. 가맹점은 등록했다고 알고 있는데 정작 관리자는 모름. 결과적으로 "왜 며칠째 승인이 안 나냐"는 문의가 누적됨. 원인은 두 군데였음. - 관리자 컨트롤러에서 알림 큐 적재 로직이 빠져있었음 (예전 리팩터링 때 누락 추정) - 파트너 포탈 사이드바에서
읽기 → -
파트너 포털 계좌 조회 API 라우팅 중복 제거로 환경별 응답 불일치 해소
무슨 일이 있었나 파트너 포털 쪽 컨트롤러를 손보다가 같은 경로에 매핑된 핸들러가 두 개 있는 걸 발견함. 한쪽은 신규 응답 스펙으로 갈아탄 메서드, 다른 한쪽은 레거시 단건 계좌 조회 API였음. 둘 다 같은 URL을 물고 있어서 어느 쪽이 먼저 잡히는지 빌드 환경마다 다르게 나오는 게 본질적 문제였음. 운영에서는 신규 메서드가 먼저 잡혀 별 탈 없이
읽기 → -
파트너 정산 계좌 다건 등록과 승인 플로우 구축
파트너 계좌 다건 관리 작업 회고 기존엔 파트너 1명당 정산 계좌가 1개만 등록 가능한 구조였음. 그런데 운영 들어가보니 사업자 명의 분리, 분점 정산, 세무 분리 등 사유로 계좌를 여러 개 굴리고 싶어하는 파트너가 적지 않았음. 그래서 다건 등록 + 관리자 승인 플로우를 한 사이클에 묶어서 작업함. 데이터 모델 정리 기존 단일 컬럼 구조를 그대로
읽기 → -
파트너 포탈 거래 내역 조회 시 권한 불일치로 0건 반환되던 버그 수정
발단 파트너 포탈에서 거래 내역을 조회하는데 결과가 비어 나온다는 제보가 들어옴. 로그 까보니 요청 파라미터에 targetSysId=GLOBAL 이 박혀 있었음. 글로벌 권한 운영자가 쓰던 키를 파트너 계정이 그대로 들고 들어오니 데이터가 0건이 되는 구조였음. 원인 권한 분기가 너무 단순했음. GLOBAL 이 들어오면 무조건 전 시스템 횡단 조회
읽기 → -
파트너 포탈에 정산·계좌 셀프 조회 화면 추가
작업 배경 파트너 포탈에 "내 정보" 메뉴가 없었음. 파트너가 본인 계정·정산 계좌·담당자 연락처 같은 기본 정보를 확인하려면 매번 운영팀에 문의해야 했고, 단순 조회 문의가 운영 대응의 상당 비중을 차지하고 있었음. 셀프서비스 채널이 필요했음. 무엇을 손봤나 - 사이드바에 "내 정보" 진입점 추가, 권한별 노출 분기 - 본인 계정 + 정산 정보 +
읽기 → -
SMS 구매 링크에 수신자 대신 발송자 소속이 박히던 버그 수정
증상 파트너 포털에서 운영자가 가맹점주에게 구매 링크 SMS 보내는 기능이 있음. QA에서 "링크 눌렀더니 다른 소속 화면으로 떨어졌다"는 제보가 올라옴. 링크에 박힌 sysId(소속 식별자)가 수신자 파트너 소속이 아니라 발송 운영자 본인 소속 기준이었던 게 원인. 원인 추적 - SMS 본문 조립 분기에서 sysId를 로그인 세션 객체에서 바로 꺼내
읽기 → -
정산 수수료 4종 차감 시점 분리로 회계 혼선 해소
정산 수수료 4종 추가하면서 깨달은 것 이번 스프린트에서 결제대행사가 청구하는 수수료 항목을 정리해 정산 모듈에 반영함. 기존엔 카드 PG 수수료 한 줄로 뭉뚱그려 차감하던 구조였는데, 정산 명세를 까보니 청구 시점이 다른 항목이 섞여 있었음. 이걸 한 번에 차감하면 머천트 입장에선 "왜 이번 달에 이 금액이 빠졌지?"가 됨. 청구 시점이 다르다는
읽기 → -
구매 링크 도메인을 설정값으로 분리해 운영팀 셀프 변경 실현
발단 파트너 포털에서 구매자에게 보내는 구매 링크 기능 점검하다가 이상한 걸 발견함. 도메인이 코드에 그냥 문자열로 박혀있었음. 스테이징/운영 환경이 다르고, 화이트라벨 파트너마다 노출 도메인이 갈리는데도 한 줄로 고정되어 있던 상황. 배포 환경이 늘어날 때마다 분기가 같이 늘어나는 구조였고, 신규 파트너 도메인 하나 붙이려면 코드 수정 + 재배포가
읽기 → -
비회원 쿠폰 바로구매 버튼 먹통과 파트너 코드 유실 수정
비회원 진입 동선이 무너졌던 이유 이커머스 파트너가 공유한 쿠폰 링크로 비회원이 들어왔을 때, 바로구매 버튼이 먹통이 됨. 로그인 회원은 멀쩡한데 비회원만 클릭해도 아무 반응이 없거나 엉뚱한 페이지로 튕김. 원인 추적해보니 두 갈래였음. - 쿠폰 상세에서 바로구매 호출할 때 세션의 사용자 식별자를 무조건 참조하고 있었음 - 파트너 추천 파라미터가 로
읽기 → -
비회원 결제 후 주문완료 화면이 막히던 문제 수정
발단 비회원으로 결제까지 마쳤는데 주문완료 페이지에서 로그인 화면으로 튕긴다는 제보가 들어옴. 결제는 성공, 돈은 빠져나갔는데 주문번호를 확인 못 하는 상황. CS 입장에서 제일 짜증나는 케이스라 우선순위 끌어올려서 바로 잡았음. 원인 추적 비회원 차단 인터셉터가 /order/** prefix 전체를 막고 있었음. 의도는 마이페이지·주문조회 같은
읽기 → -
비회원 결제에 쿠폰 라우팅·정산 연동 SMS 발송 추가
비회원 구매 흐름에 쿠폰 라우팅 붙이기 이커머스 쪽 비회원 결제 플로우에 쿠폰을 끼워 넣는 작업을 함. 회원이면 마이페이지에서 쿠폰함을 거치는데, 비회원은 그 단계가 통째로 비어있어서 결제 직후 어디로 보내야 할지 분기가 필요했음. 처음엔 단순히 "비회원이면 결제 완료 화면, 회원이면 쿠폰함" 정도로 생각했는데, 실제로는 케이스가 더 많음. - 파트
읽기 → -
모바일 파트너 코드 입력 키보드 한글 이탈 문제 해결로 가입 전환율 4%p
모바일 키보드 첫 진입이 한글이면 사용자 이탈함 파트너 코드 입력 필드, PC 에서는 멀쩡했는데 모바일 가입 전환율이 유독 낮았음. QA 팀에서 "코드 입력하다가 자판 바꾸느라 짜증났다"는 사용자 인터뷰 클립을 들고 와서야 원인이 잡힘. 파트너 코드 정책상 영문 + 숫자 조합인데, 안드로이드 기본 키보드가 한글 자판으로 떠 있으면 사용자가 매번 한영
읽기 → -
이커머스 파트너 가입 시 중복확인과 SMS 인증을 단일 동선으로 통합
사업자 회원가입 플로우 정리 이커머스 파트너 회원가입 화면을 손봤음. 기존엔 휴대폰 입력란 옆에 "중복확인" 버튼이 따로 있고, 그 아래 SMS 인증 영역이 또 따로 있었음. 사용자가 두 번 눌러야 가입 진행이 됐고, 동선이 꼬여서 이탈이 많이 났음. 무엇이 문제였나 - 중복확인 통과 후 SMS 인증 단계로 안 넘어가는 케이스가 많았음 - 중복확인
읽기 → -
파트너 코드 입력 검증 누락으로 인한 모바일 가입 실패율 개선
문제 발견
읽기 → -
결제 구간 앱 서명 위변조 트래픽을 단계별로 차단한 방법
배경 모바일 앱에서 서버로 들어오는 요청이 진짜 우리 앱에서 온 게 맞는지 확인할 방법이 필요했음. 그동안 디바이스 식별자만 보고 신뢰했는데, 리패키징된 패키지로 위변조 트래픽이 들어오는 정황이 잡힘. 결제대행사 연동 구간이라 더 미룰 수 없었음. 접근 — X-Sig-Hash 헤더 앱 서명 인증서의 SHA-256 해시를 매 요청마다 헤더에 실어 보
읽기 → -
결제 앱 APK 변조·정산 탈취 막은 다층 무결성 방어
배경 이커머스 앱이 마켓에 풀린 뒤로 이상한 트래픽이 잡히기 시작했음. 정상 클라이언트로는 절대 나올 수 없는 호출 패턴이 보였고, 추적해 보니 APK 디컴파일 후 재서명한 변종이었음. 단순 난독화로는 한계가 명확했고, 결제 플랫폼 특성상 파트너 정산 데이터에 손대는 게 보여서 더 미룰 수 없었음. 1차: 서명 해시 검증 가장 먼저 한 건 런타임
읽기 → -
연락처 송금 큐에 시도별 처리 이력 추적 기능 추가
큐는 돌아가는데 왜 실패했는지 모르겠음
읽기 → -
WHERE 절 누락으로 전체 포인트 잔고가 덮어써진 사고와 수정
사고 발견 경위
읽기 →