#api
-
이커머스 PG 플랫폼 디자인 토큰 통일
feat: 이커머스 PG 플랫폼 사용자 페이지 전반 UI 개선 및 CSS/SCSS 정리 CSS/SCSS 작업은 눈에 잘 안 보이지만 쌓이면 시스템 전체 일관성에 영향 줌. 이번엔 디자인 토큰 통일과 반응형 최적화가 메인이었음. CSS 변수 통일 작업 컴포넌트마다 4px, 6px, 8px, 12px이 혼재해있었음. 디자인 시스템 기준을 잡고 CSS
읽기 → -
후원·포인트·즐겨찾기 페이지 개선
feat: 후원 리스트/마이포인트/즐겨찾기 페이지 개선 및 API 파라미터 수정 포인트/잔액 관련 로직은 정합성이 핵심임. 동시성 이슈와 소수점 처리를 특히 조심해야 함. 포인트 차감 순서 무상 포인트 먼저 차감 → 부족하면 유상에서 차감 (세금 처리, 환불 정책과 연관됨) 동시성 처리 sql -- 비관적 락으로 잔액 차감 SELECT b
읽기 → -
백엔드 로직 중복 제거와 엣지 케이스 처리로 시스템 안정성 강화
전체 시스템 최종 검증 결과 이번 작업의 핵심은 기존 기능 안정화와 코드 일관성 확보였음. 변경 범위가 여러 레이어에 걸쳐있어서 영향 범위를 꼼꼼히 체크했음. 변경 영역 | 레이어 | 파일 수 | 주요 변경 | |--------|--------|---------| | 백엔드 로직 | 6개 | 핵심 처리 로직 개선 | | 화면 (JSP) | 0개 |
읽기 → -
모바일 대응 관리자 테이블을 카드형으로 개선
메뉴 정리 및 툴팁 기능 등 수정 JSP UI 작업은 레거시 환경에서 어떻게 사용성을 올릴 수 있는지 계속 고민하게 만듦. 테이블 레이아웃 개선 모바일에서 가로 스크롤 없이 보이게 하는 게 과제였음. 카드형 뷰로 폴백 처리함. jsp <%-- PC: 테이블 형태 --%> <div class="admin-table-wrapper d-none d-m
읽기 → -
계정 정지와 출금 정지를 분리해 독립적으로 작동하도록 개편
정지 유형을 이분화하는 구조 개편했음. 기존엔 계정 정지만 있었는데, 이번에 출금 정지를 분리해서 두 기능이 독립적으로 작동하도록 함.
읽기 → -
이커머스 결제 플랫폼 사용자 페이지 모바일 레이아웃
fix : 이커머스 PG 플랫폼 사용자페이지 QA 버그 수정 JSP UI 작업은 레거시 환경에서 어떻게 사용성을 올릴 수 있는지 계속 고민하게 만듦. 테이블 레이아웃 개선 모바일에서 가로 스크롤 없이 보이게 하는 게 과제였음. 카드형 뷰로 폴백 처리함. jsp <%-- PC: 테이블 형태 --%> <div class="admin-table-wra
읽기 → -
SQL 쿼리 정리로 코드 일관성과 가독성 개선
feat: 불필요 메세지 정리 이번 작업의 핵심은 기존 기능 안정화와 코드 일관성 확보였음. 변경 범위가 여러 레이어에 걸쳐있어서 영향 범위를 꼼꼼히 체크했음. 변경 영역 | 레이어 | 파일 수 | 주요 변경 | |--------|--------|---------| | 백엔드 로직 | 0개 | 핵심 처리 로직 개선 | | 화면 (JSP) | 0개
읽기 → -
Apple OAuth 콜백 차단·세션 유실 문제 해결
feat: QR 프로모션 관리 및 랜딩 페이지 기능 추가 Apple OAuth가 구글/카카오랑 달리 까다로운 이유가 있음. form_post 방식을 강제하기 때문에 콜백이 POST로 들어오고, 이 과정에서 세션이 끊기거나 CORS 문제가 발생함. Apple OAuth 특이사항 - 콜백이 GET이 아닌 POST (form_post) - 봇 차단 필터
읽기 → -
결제 웹훅 이중 디코딩 버그 수정으로 시그니처 검증 안정화
feat: Webhook API 연동 가이드 페이지 및 컨트롤러 추가 Webhook 처리 로직에서 꽤 골치 아픈 이슈를 잡았음. 핵심은 이중 URL decode 문제임. 문제 발생 배경 결제대행사 Webhook은 POST body로 암호화된 필드를 넘겨주는데, 이 값이 URL-encoded 상태로 들어옴. 서버 프레임워크가 Content-Type:
읽기 → -
리뷰 별점 렌더링 불일치 해소와 구매 확정 후 작성 정책 구현
feat: 주문, 리뷰 및 쿠폰 관련 주요 기능 추가 리뷰/별점 기능 구현 작업임. SVG 별점 렌더링이 생각보다 신경 쓸 게 많았음. SVG 별점 통일 다양한 아이콘 세트에서 가져온 별 아이콘들의 viewBox가 제각각이어서 크기가 맞지 않았음. 24x24로 통일하고 width/height로만 크기 조절함. scss .star-icon {
읽기 → -
정산 수수료 상한 검증과 멱등성 처리 개선
feat: 시스템 수수료 상한 검증 로직 및 JSP/SQL 개선 정산 및 수수료 로직은 버그 하나가 금전 오류로 직결되는 영역이라 신중하게 접근해야 함. 수수료 계산 구조 유통 단계별로 수수료가 누적되는 구조임. 최하위 파트너가 가장 높은 요율을 부담하고, 상위로 갈수록 낮아지며 그 차액이 각 단계의 수익임. | 단계 | 요율 | 수익 | |--
읽기 → -
수수료 단계별 정산 로직과 멱등성 처리 구현
docs: 수수료 시스템 구현 지시서 및 결과 보고서 추가 정산 및 수수료 로직은 버그 하나가 금전 오류로 직결되는 영역이라 신중하게 접근해야 함. 수수료 계산 구조 유통 단계별로 수수료가 누적되는 구조임. 최하위 파트너가 가장 높은 요율을 부담하고, 상위로 갈수록 낮아지며 그 차액이 각 단계의 수익임. | 단계 | 요율 | 수익 | |-----
읽기 → -
파트너 실시간 문의용 PIP 채팅 위젯 구현
feat: PIP 채팅 위젯 기능 추가 관리자 채팅 기능 추가 작업임. 파트너가 관리자에게 실시간으로 문의할 수 있는 PIP 채팅 위젯 구현. 채팅 아키텍처 WebSocket 대신 Polling 방식으로 구현함. 실시간성이 중요한 채팅이 아니라 문의/답변 형태여서 30초 폴링으로 충분함. javascript // 30초마다 새 메시지 확인 set
읽기 → -
Pay 정책 생성 시 대상 시스템 유효성 검증 강화
fix: Pay 정책 생성 시 targetSysId 유효성 검증 로직 추가 이번 작업의 핵심은 기존 기능 안정화와 코드 일관성 확보였음. 변경 범위가 여러 레이어에 걸쳐있어서 영향 범위를 꼼꼼히 체크했음. 변경 영역 | 레이어 | 파일 수 | 주요 변경 | |--------|--------|---------| | 백엔드 로직 | 1개 | 핵심 처리
읽기 → -
정산 수수료 단계별 누적 구조와 멱등성 처리 개선
feat: 정산 로직(수수료/마진) 및 Pay 정책 등급 기반 개선 정산 및 수수료 로직은 버그 하나가 금전 오류로 직결되는 영역이라 신중하게 접근해야 함. 수수료 계산 구조 유통 단계별로 수수료가 누적되는 구조임. 최하위 파트너가 가장 높은 요율을 부담하고, 상위로 갈수록 낮아지며 그 차액이 각 단계의 수익임. | 단계 | 요율 | 수익 | |
읽기 → -
이벤트 참여·회원 등급 배치 설계와 멱등 실행 구조 도입
feat: 이벤트 참여 및 회원 등급 기능 관련 다수 파일 추가 배치 작업은 운영 중에 터지면 치명적이라 스케줄링 설계를 꼼꼼히 해야 함. 배치 설계 원칙 - 멱등성: 동일 조건으로 여러 번 돌아도 같은 결과 - 실패 로그: 어떤 건이 실패했는지 추적 가능해야 함 - 부분 성공: 일부 실패해도 나머지는 처리 계속 - 알림: 오류 발생 시 담당자에게
읽기 → -
다중 시스템 UI와 SQL 분석에 에러 처리까지 구현한 과정
다중 시스템 UI, SQL 분석 및 에러 처리 로직 추가 구현기 2026-02-06. 기능 명세 나오고 나서 바로 착수했던 작업임. 설계 결정 구현 전에 몇 가지 선택지가 있었음. 기존 코드에 덧붙이는 방식 vs 새로 작성하는 방식. 결국 기존 구조를 최대한 활용하되, 새 기능 부분만 분리해서 작성하는 방향으로 정했음. 나중에 테스트하기 쉽고, 변
읽기 → -
이커머스 결제 API 문서 전면 보완으로 코드 불일치까지 해결
이커머스 결제 연동 플랫폼 API 명세 전체 보완 및 신규 섹션 추가 2026-02-06. API 문서 작업. 코드가 아무리 잘 짜여 있어도 문서가 없으면 다른 사람이, 또는 미래의 내가 쓰기 어려움. 문서화 범위 - **API 엔드포인트**: 경로, HTTP 메서드, 요청/응답 스펙 - **파라미터 명세**: 필수/선택 여부, 타입, 유효성 규칙
읽기 → -
파트너 포털 결제 API 문서 정비로 온보딩 시간 단축
Pay 관리 및 파트너 포털 관련 API 문서 업데이트 2026-02-06. 내부 문서 정비 작업. 신규 멤버가 왔을 때 온보딩 시간을 줄이는 게 목표였음. 왜 지금 했나 기능 개발이 어느 정도 안정됐고, 이 시점에 문서를 안 쓰면 나중에는 더 안 쓰게 됨. 코드를 짤 때의 맥락과 결정 이유는 시간이 지나면 희미해지기 때문에, 그 기억이 남아 있을
읽기 → -
후원 관리 페이지와 API를 처음부터 구현한 과정
후원 관리 페이지 및 API 구현 2026-02-06. 컨트롤러, SQL 쿼리 레이어에 실제 동작하는 로직을 심는 작업이었음. 기술적 접근 요구사항 분석 후 다음 순서로 진행했음: 1. **스키마/모델 정의** — 어떤 데이터를 어떻게 저장할지 먼저 결정 2. **핵심 로직 구현** — 컨트롤러부터 시작 3. **API 연결** — 외부에서 호출
읽기 →