#api
-
관리자 화면에 알림 수신 탭·LLM 연동·통계 API 한번에 추가
오늘 관리자 화면에 알림 수신 탭을 새로 붙이고, 외부 LLM 연동 + 통계 집계 API까지 한 PR에 묶어서 밀어넣음. 세 덩어리라 부담스러웠는데, 결국 같은 운영자 워크플로우를 노리는 작업이라 쪼개는 게 더 어색했음. 알림 수신 탭 기존 관리자 화면은 거래·정산만 다뤘는데, 파트너 쪽에서 "왜 알림이 안 옴?" 문의가 늘면서 수신 이력 가시성이 필
읽기 → -
영상 감지율을 60%에서 94%로 끌어올린 네트워크 후킹 도입
문제 상황 이전 videoDetector는 페이지 로드 시점의 <video> 태그만 훑고 끝났음. 그러다 보니 - SPA에서 라우팅 후 동적으로 붙는 영상은 놓침 - 플레이어가 blob URL이나 MSE로 스트림을 주입하면 src가 비어있어서 못 잡음 - API가 m3u8 매니페스트만 내려주고 DOM에는 아무것도 안 박히는 케이스도 있음 결국 "감지
읽기 → -
안드로이드 웹뷰 백지 화면, 결제 콜백 평문 트래픽 차단이 원인
안드로이드 웹뷰에서 갑자기 화면이 백지로 뜬 사건 QA에서 "안드로이드 앱 켜면 흰 화면만 나옴" 제보가 들어왔음. iOS는 멀쩡한데 안드로이드만 그럼. 로그를 까보니 익숙한 메시지가 보임. net::ERR_CLEARTEXT_NOT_PERMITTED 원인은 한 줄로 정리됨. 안드로이드 9(API 28)부터 평문 HTTP 트래픽이 기본 차단됨. 우
읽기 → -
SNS 영상 감지와 OAuth 리다이렉트 오류 동시에 수정
구글 로그인이 또 깨졌다 오랜만에 사이드 프로젝트 손봤더니 OAuth가 안 됐음. 콘솔에는 redirect_uri_mismatch. 도메인 옮긴 걸 까먹은 게 원인이었음. 등록된 redirect와 실제 요청 URL이 슬래시 한 글자 차이로 어긋나 있었음. - 콘솔 → 인증 정보 → 승인된 리디렉션 URI 갱신 - 로컬/스테이징/프로덕션 3개 환경 따로
읽기 → -
README 외부 이미지 과다로 생기는 렌더링 누락 해결
외부 이미지 폭탄으로 README가 안 보임 오늘 머지한 PR 확인하려고 메인 레포 페이지 들어갔더니 README 중간이 통째로 비어있었음. 처음엔 마크다운 문법이 깨진 줄 알고 raw 파일을 열어봤는데 멀쩡함. 그런데 렌더된 페이지에서만 이미지 절반이 X 박스로 뜨고, 어떤 건 아예 placeholder조차 안 나옴. 원인 추적 확인해보니 외부
읽기 → -
파트너 포털 계좌 조회 API 라우팅 중복 제거로 환경별 응답 불일치 해소
무슨 일이 있었나 파트너 포털 쪽 컨트롤러를 손보다가 같은 경로에 매핑된 핸들러가 두 개 있는 걸 발견함. 한쪽은 신규 응답 스펙으로 갈아탄 메서드, 다른 한쪽은 레거시 단건 계좌 조회 API였음. 둘 다 같은 URL을 물고 있어서 어느 쪽이 먼저 잡히는지 빌드 환경마다 다르게 나오는 게 본질적 문제였음. 운영에서는 신규 메서드가 먼저 잡혀 별 탈 없이
읽기 → -
파트너 정산 계좌 다건 등록과 승인 플로우 구축
파트너 계좌 다건 관리 작업 회고 기존엔 파트너 1명당 정산 계좌가 1개만 등록 가능한 구조였음. 그런데 운영 들어가보니 사업자 명의 분리, 분점 정산, 세무 분리 등 사유로 계좌를 여러 개 굴리고 싶어하는 파트너가 적지 않았음. 그래서 다건 등록 + 관리자 승인 플로우를 한 사이클에 묶어서 작업함. 데이터 모델 정리 기존 단일 컬럼 구조를 그대로
읽기 → -
결제대행사 연동 제거로 충전 로직 버그까지 발견 정리
결제대행사 연동 삭제와 충전 로직 손질 오늘 작업은 두 갈래였음. 더 이상 트래픽이 들어오지 않는 결제대행사 연동을 들어내는 것, 그리고 충전 흐름에 쌓여있던 잔버그를 정리하는 것. 왜 들어냈는가 - 해당 결제대행사로 유입되는 트래픽이 사실상 0에 수렴 - 그런데 유지보수 비용은 그대로 발생 (콜백 검증, 환불 분기, 예외 처리) - 다른 결제대행
읽기 → -
결제 수단 추가로 드러난 정산 쿼리 누락과 분기 구조 개선
새 결제 수단 붙이기 이커머스에서 결제대행사 한 곳을 추가함. 기존엔 카드/가상계좌만 받던 흐름에 새 수단이 끼어들면서, 결제 요청 분기에서 슬슬 균열이 보이기 시작함. 처음엔 그냥 if 한 줄 더 넣고 끝날 줄 알았는데, 실제로 붙여보니 응답 콜백 포맷이 달라서 파싱 단계부터 다시 짜야 했음. 단순 추가가 아니라 "이미 너무 비대해진 분기"를 건드리
읽기 → -
결제대행사 회원 동기화를 비동기 큐로 전환해 정산 누락 해소
발단 이커머스 결제대행사 연동 작업 중 회원 정보 동기화 스펙 추가 요청 받았음. 신규 가입 시 결제대행사 쪽에 우리 회원 식별값을 함께 넘겨야 환불·정산 매칭이 깔끔해진다는 운영팀 피드백 때문이었음. 기존엔 결제 시점에 임시로 끼워 넣고 있어서 매칭 누락이 가끔 터졌음. 무엇을 추가했는가 가입/수정 흐름에 정식 필드를 박고, 변경 이벤트를 외부로
읽기 → -
이커머스 파트너 충전 결제 연동과 잔액 정산 안정화
결제대행사 충전 플로우 붙이기 이커머스 파트너 잔액에 충전 기능 하나 추가하는 일이었음. 단순히 API 한 개 더 까는 줄 알았는데, 결제대행사 쪽 응답 파싱이랑 트랜잭션 경계 잡는 게 생각보다 까다로웠음. 기본 흐름은 이렇게 정리: - 클라이언트 충전 요청 → 서버에서 주문 키 발급 - 결제대행사 팝업 띄워서 결제 진행 - 콜백 수신 → 검증 →
읽기 → -
결제 콜백 후 잔액 즉시 반영
결제 콜백 후 잔액이 안 보이던 문제 결제대행사 콜백이 들어와서 충전이 끝났는데, 정작 파트너 화면에서 새 잔액을 보려면 새로고침을 두세 번 해야 했음. 콜백 처리 자체는 멀쩡한데 후처리 흐름이 어긋난 것. 원인을 까보니: - 콜백 트랜잭션 커밋 직후 응답을 돌려주는데, 조회 API 쪽이 자체 캐시를 들고 있었음 - 잔액 반영 이벤트가 비동기로 흐르
읽기 → -
결제대행사 웹훅 멱등 처리와 명세 불일치 극복기
결제대행사 API 연동, 명세서부터 다시 읽음 결제대행사 연동 작업 들어가면서 받아둔 명세서 PDF를 처음부터 다시 정독함. 이전에 한 번 훑었을 때는 "어차피 표준 PG 흐름이지" 싶어서 대충 봤는데, 막상 코드로 옮기려니까 필드 단위에서 막히는 부분이 한둘이 아니었음. 특히 헷갈렸던 포인트: - 승인 응답과 webhook 통보 메시지의 필드 이름
읽기 → -
은행 연동 코드를 어댑터 패턴으로 신규 프로젝트에 이전
은행 핸들러 마이그레이션 시작 기존 이커머스 플랫폼에 흩어져 있던 은행 연동 코드를 신규 프로젝트로 옮김. 단순 복붙이 아니라 의존성부터 정리해야 했음. 문제는 기존 코드가 캐시 유틸을 직접 import 하고 있었고, 신규 쪽엔 그 유틸이 없었음. 같은 이름으로 새로 깎느냐, 인터페이스만 맞추느냐 사이에서 고민하다가 신규에 얇게 다시 만드는 쪽으로 감
읽기 → -
결제대행사 연동 프로젝트 첫 커밋을 가볍게 시작하는 법
새 프로젝트 첫 커밋 결제대행사 연동 솔루션 신규 프로젝트의 첫 삽을 떴음. 빈 디렉토리에 그래들 래퍼 뜯어 넣고, .gitignore 깔고, 빌드 스크립트 골격만 박아두는 작업. 별 거 아닌 것 같지만 매번 이 단계에서 30분~1시간씩 까먹음. 왜 래퍼부터 박는가 팀에 합류하는 사람마다 로컬 그래들 버전이 다르면 빌드 결과도 달라짐. 래퍼 jar
읽기 → -
알림 파이프라인에서 발신자 표시명 분리 정규화로 채널별 오발송 해결
v3.1 릴리스 — senderDisplay 필드 추가하다 만난 알림 파이프라인 이슈 API 스펙 작은 변경 하나가 알림 파이프라인 전체를 흔드는 경험을 또 함. 파트너 쪽에서 "발신자 표시명을 별도로 받고 싶다"는 요청이 왔고, 기존 sender 외에 senderDisplay 를 추가했음. 처음엔 단순 nullable 문자열 추가라 30분이면 끝날
읽기 → -
입금 계좌 로테이션과 AI 입금자명 자동 매칭 도입
한 계좌만 쓰던 시절의 한계 파트너가 늘어나면서 단일 입금 계좌 구조가 슬슬 깨지기 시작함. 일 거래량이 일정 수준을 넘어가니 은행 쪽에서 거래 패턴을 의심하기도 하고, 한도에 막혀서 오후 늦게 입금이 튕기는 사고도 종종 났음. 파트너 입장에서는 한 번 튕긴 경험이 재충전 의욕을 꺾어버려서, 단순한 운영 이슈로 끝나지 않고 매출 직격타로 돌아왔음. 그
읽기 → -
안드로이드 절전 정책으로 끊기던 새벽 알림 수집 해결
24시간 돌려야 하는 수집기, 새벽마다 멈췄음 알림 수집 모듈을 백그라운드로 24시간 띄워놓는 구조였는데, 새벽 3~5시 사이에 수집이 끊기는 현상이 반복됐음. 처음엔 네트워크 이슈인 줄 알았는데 로그를 까보니 프로세스 자체가 잠들어 있었음. Doze 모드와 App Standby가 만든 합작품이었음. Doze가 뭘 죽이는지부터 정리 배터리 최적화
읽기 → -
이커머스 결제 앱 빌드 파이프라인 보안·성능 일괄 정비
v3.1 릴리스 정리: 보안·성능·배포 설정을 한 번에 손봄 이커머스 결제 플랫폼 모바일 빌드 v3.1 작업하면서 빌드 스크립트, 난독화 규칙, 버전 메타, gitignore 4종 세트를 같이 갈아엎었음. 한 번에 묶은 이유는 단순함 — 셋 중 하나만 건드리면 나머지가 무조건 어긋남. .gitignore 부터 정리 처음에 잡힌 추적 누락 파일들 보
읽기 → -
결제대행사 콜백이 봇 필터에 막혀 정산 PENDING이 쌓인 문제 해결
외부 결제대행사 콜백이 차단당했음 이커머스 운영 중에 결제대행사 콜백이 봇 차단 필터에서 4xx로 떨어지는 사고 발생. 사용자 결제는 정상 완료됐는데 콜백이 막히니까 결제 플랫폼 내부 상태가 PENDING에서 안 넘어감. 정산 화면 보다가 발견했으니 운영 모니터링이 한 박자 늦은 것도 같이 발견됨. 원인 파악 - 봇 차단 필터를 외부 노출 API 경
읽기 →