-
결제 플랫폼 README 반년치 부패 한 번에 정리
README 업데이트, 한 시간이면 끝날 줄 알았음 결제 플랫폼 사이드 레포 README가 반년째 방치돼 있길래 가볍게 손보려고 함. 결과적으로 두 시간 넘게 붙잡고 있었음. 문서가 코드보다 빨리 썩는다는 말이 진짜라는 걸 또 체감. 뭐가 문제였나 기존 README 훑어보니 다음 같은 이슈들이 보였음. - 설치 가이드의 의존성 버전이 두 단계 뒤
읽기 → -
README 외부 이미지 과다로 생기는 렌더링 누락 해결
외부 이미지 폭탄으로 README가 안 보임 오늘 머지한 PR 확인하려고 메인 레포 페이지 들어갔더니 README 중간이 통째로 비어있었음. 처음엔 마크다운 문법이 깨진 줄 알고 raw 파일을 열어봤는데 멀쩡함. 그런데 렌더된 페이지에서만 이미지 절반이 X 박스로 뜨고, 어떤 건 아예 placeholder조차 안 나옴. 원인 추적 확인해보니 외부
읽기 → -
프로필 페이지 리디자인으로 체류 시간 3배 늘린 과정
프로필 페이지 갈아엎은 날 오래 묵힌 프로필 페이지를 손봤음. 기존 페이지는 정적인 카드 한 장에 이름·소개·연락처만 박아둔 형태였는데, 방문자가 1초 보고 바로 닫는다는 피드백이 누적돼서 작정하고 리디자인 들어감. 목표는 세 가지였음. - 첫 화면 진입 시 시선 잡아끄는 모션 - 보유 스킬을 한눈에 파악 가능한 아이콘 그리드 - 누적 활동량을 보여
읽기 → -
포트폴리오에서 비공개 저장소 링크 노출 차단
비공개 저장소 링크 제거하다 발견한 권한 누수 포트폴리오 페이지에 프로젝트 리스트 뿌리는데, 비공개 레포까지 그냥 클릭 가능한 링크로 박혀있던 걸 뒤늦게 발견함. 외부에서 클릭하면 404로 튕기긴 하지만, 그 자체로 "여기 비공개 레포 있음"을 노출하는 거라 좋은 그림은 아님. 뭐가 문제였는지 - 카드 컴포넌트에서 repo.url 을 무조건 앵커
읽기 → -
깃허브 프로필을 터미널 테마로 전면 개편한 과정
프로필 README 갈아엎은 이유 오랜만에 깃허브 프로필 들어가봤더니 예전에 대충 박아둔 자기소개랑 깨진 뱃지 몇 개가 다였음. 방문자가 와도 내가 뭘 하는 사람인지, 뭘 만들어왔는지 30초 안에 파악이 안 되는 구조였음. 한 번 갈아엎기로 결정. 목표는 두 가지로 잡음. - **첫 인상에서 정체성 전달**: 어떤 스택을 쓰고 어떤 결과물을 만드는지
읽기 → -
비회원 주문의 쿠폰 핀 발급 오류 수정
비회원 주문에서 터진 핀 생성 버그 이커머스 백오피스에서 핀(쿠폰 코드) 생성 로직을 손봤음. 어드민 화면과 파트너 화면 양쪽에서 핀을 발급할 수 있는데, 비회원 주문이 끼면 회원 식별값이 없어서 다운스트림에서 NPE가 터지거나 매칭이 엉뚱하게 붙는 케이스가 있었음. 원래는 핀 생성 시 회원 식별값을 그대로 던지면 그만이었는데, 비회원 결제 비중이 늘
읽기 → -
이커머스 프로젝트 초기 설정으로 협업·코드 리뷰 품질 잡기
새 프로젝트 첫 삽 오랜만에 빈 디렉토리부터 시작하는 작업을 맡았음. 이커머스 사이드 프로젝트인데, 첫 커밋부터 설정 파일만 4개 깔았음. config 폴더, ESLint, Prettier, gitignore. 기능 코드 한 줄 없는 initial commit이지만, 이게 나중에 가장 중요했음. 왜 처음부터 lint·format을 박았나 - 협업자
읽기 → -
가맹점 수수료 요율 검증으로 마진 역전 버그 차단
문제: 요율 한 번 잘못 바꿨더니 마진이 음수가 됨 파트너 관리 화면에서 가맹점 충전 수수료를 0.5%로 내려달라는 요청 받음. 별생각 없이 업데이트했더니 운영팀에서 바로 핑이 옴. "이거 총판이 0.7% 받고 있는데, 가맹점이 0.5%면 총판이 -0.2% 손실 보는 거 아님?" 맞는 말이었음. 원래 구조 다시 정리해봄: - 가맹점이 가장 높은 요율
읽기 → -
정산 유니크 제약 누락으로 중복 적재되던 문제 수정
dump.rdb 가 또 올라왔음 로컬에서 캐시 띄워놓고 작업하다 보면 워킹 디렉토리에 dump.rdb 가 슬쩍 생김. 평소엔 잘 피해다녔는데 다른 변경이랑 같이 add 되면서 한번 커밋에 따라 들어간 적이 있었음. 수십 MB 바이너리가 히스토리에 박히면 클론할 때마다 짜증나고, 무엇보다 캐시 스냅샷에 뭐가 들었는지 모르니 보안적으로도 찜찜함. 그래서
읽기 → -
파트너 정산 이중 차감과 화면별 잔액 오차 수정
정산 중복 처리, 또 너냐 파트너 정산 화면에서 같은 건이 두 번 차감되는 이슈. 결제 플랫폼 쪽에선 흔한 패턴이긴 한데, 이번엔 정산·대시보드·파트너 어드민·파트너 화면 컨트롤러 4개를 동시에 손봐야 했음. 한 곳만 고치면 다른 화면에서 다시 어긋나서, 결국 합계 산식을 원장 수준에서 한 번에 정리함. 무엇이 문제였나 - 충전 수수료, 결제 수수
읽기 → -
가맹점 계좌 승인 알림 누락과 사이드바 메뉴 미노출 수정
계좌 승인 알림이 사라진 이유 파트너 포탈에서 신규 가맹점 계좌 등록 후 관리자 승인 알림이 안 떴음. 가맹점은 등록했다고 알고 있는데 정작 관리자는 모름. 결과적으로 "왜 며칠째 승인이 안 나냐"는 문의가 누적됨. 원인은 두 군데였음. - 관리자 컨트롤러에서 알림 큐 적재 로직이 빠져있었음 (예전 리팩터링 때 누락 추정) - 파트너 포탈 사이드바에서
읽기 → -
파트너 포털 계좌 조회 API 라우팅 중복 제거로 환경별 응답 불일치 해소
무슨 일이 있었나 파트너 포털 쪽 컨트롤러를 손보다가 같은 경로에 매핑된 핸들러가 두 개 있는 걸 발견함. 한쪽은 신규 응답 스펙으로 갈아탄 메서드, 다른 한쪽은 레거시 단건 계좌 조회 API였음. 둘 다 같은 URL을 물고 있어서 어느 쪽이 먼저 잡히는지 빌드 환경마다 다르게 나오는 게 본질적 문제였음. 운영에서는 신규 메서드가 먼저 잡혀 별 탈 없이
읽기 → -
파트너 정산 계좌 다건 등록과 승인 플로우 구축
파트너 계좌 다건 관리 작업 회고 기존엔 파트너 1명당 정산 계좌가 1개만 등록 가능한 구조였음. 그런데 운영 들어가보니 사업자 명의 분리, 분점 정산, 세무 분리 등 사유로 계좌를 여러 개 굴리고 싶어하는 파트너가 적지 않았음. 그래서 다건 등록 + 관리자 승인 플로우를 한 사이클에 묶어서 작업함. 데이터 모델 정리 기존 단일 컬럼 구조를 그대로
읽기 → -
파트너 포탈 거래 내역 조회 시 권한 불일치로 0건 반환되던 버그 수정
발단 파트너 포탈에서 거래 내역을 조회하는데 결과가 비어 나온다는 제보가 들어옴. 로그 까보니 요청 파라미터에 targetSysId=GLOBAL 이 박혀 있었음. 글로벌 권한 운영자가 쓰던 키를 파트너 계정이 그대로 들고 들어오니 데이터가 0건이 되는 구조였음. 원인 권한 분기가 너무 단순했음. GLOBAL 이 들어오면 무조건 전 시스템 횡단 조회
읽기 → -
파트너 포탈에 정산·계좌 셀프 조회 화면 추가
작업 배경 파트너 포탈에 "내 정보" 메뉴가 없었음. 파트너가 본인 계정·정산 계좌·담당자 연락처 같은 기본 정보를 확인하려면 매번 운영팀에 문의해야 했고, 단순 조회 문의가 운영 대응의 상당 비중을 차지하고 있었음. 셀프서비스 채널이 필요했음. 무엇을 손봤나 - 사이드바에 "내 정보" 진입점 추가, 권한별 노출 분기 - 본인 계정 + 정산 정보 +
읽기 → -
SMS 구매 링크에 수신자 대신 발송자 소속이 박히던 버그 수정
증상 파트너 포털에서 운영자가 가맹점주에게 구매 링크 SMS 보내는 기능이 있음. QA에서 "링크 눌렀더니 다른 소속 화면으로 떨어졌다"는 제보가 올라옴. 링크에 박힌 sysId(소속 식별자)가 수신자 파트너 소속이 아니라 발송 운영자 본인 소속 기준이었던 게 원인. 원인 추적 - SMS 본문 조립 분기에서 sysId를 로그인 세션 객체에서 바로 꺼내
읽기 → -
정산 수수료 4종 차감 시점 분리로 회계 혼선 해소
정산 수수료 4종 추가하면서 깨달은 것 이번 스프린트에서 결제대행사가 청구하는 수수료 항목을 정리해 정산 모듈에 반영함. 기존엔 카드 PG 수수료 한 줄로 뭉뚱그려 차감하던 구조였는데, 정산 명세를 까보니 청구 시점이 다른 항목이 섞여 있었음. 이걸 한 번에 차감하면 머천트 입장에선 "왜 이번 달에 이 금액이 빠졌지?"가 됨. 청구 시점이 다르다는
읽기 → -
구매 링크 도메인을 설정값으로 분리해 운영팀 셀프 변경 실현
발단 파트너 포털에서 구매자에게 보내는 구매 링크 기능 점검하다가 이상한 걸 발견함. 도메인이 코드에 그냥 문자열로 박혀있었음. 스테이징/운영 환경이 다르고, 화이트라벨 파트너마다 노출 도메인이 갈리는데도 한 줄로 고정되어 있던 상황. 배포 환경이 늘어날 때마다 분기가 같이 늘어나는 구조였고, 신규 파트너 도메인 하나 붙이려면 코드 수정 + 재배포가
읽기 → -
비회원 구매 흐름에 핀 검증과 주문 자동매칭까지 완성
비회원 구매에 마침표 찍은 날 이커머스 플랫폼에 비회원 구매 흐름 붙이는 작업이 드디어 끝남. 회원만 받던 구조에 비회원 진입로를 뚫어야 했는데, 뚫는 김에 핀 검증·배송지 입력·주문-회원 자동매칭까지 한 번에 묶음. 분리해서 배포하면 비회원이 결제까지 갔다가 매칭 누락으로 고아 주문 생길 게 뻔해서 묶어서 가는 게 맞다고 판단함. 핀 검증, 보안과
읽기 → -
비회원 쿠폰 바로구매 버튼 먹통과 파트너 코드 유실 수정
비회원 진입 동선이 무너졌던 이유 이커머스 파트너가 공유한 쿠폰 링크로 비회원이 들어왔을 때, 바로구매 버튼이 먹통이 됨. 로그인 회원은 멀쩡한데 비회원만 클릭해도 아무 반응이 없거나 엉뚱한 페이지로 튕김. 원인 추적해보니 두 갈래였음. - 쿠폰 상세에서 바로구매 호출할 때 세션의 사용자 식별자를 무조건 참조하고 있었음 - 파트너 추천 파라미터가 로
읽기 →