#lock
-
관리자 화면에 알림 수신 탭·LLM 연동·통계 API 한번에 추가
오늘 관리자 화면에 알림 수신 탭을 새로 붙이고, 외부 LLM 연동 + 통계 집계 API까지 한 PR에 묶어서 밀어넣음. 세 덩어리라 부담스러웠는데, 결국 같은 운영자 워크플로우를 노리는 작업이라 쪼개는 게 더 어색했음. 알림 수신 탭 기존 관리자 화면은 거래·정산만 다뤘는데, 파트너 쪽에서 "왜 알림이 안 옴?" 문의가 늘면서 수신 이력 가시성이 필
읽기 → -
결제 송금 알림 메시지 빌더를 분리해 가독성 개선
왜 손댔나 연락처 송금 메시지 유틸이 너무 비대해졌음. 결제 플랫폼에서 파트너끼리 잔액을 옮길 때 알림 문구를 만드는 부분인데, 한 메서드 안에 분기가 켜켜이 쌓여 있었음. - 송금 성공/실패/대기/취소 4종 - 파트너 등급별 호칭 표기 차이 - 결제대행사 결과코드에 따른 문구 분기 - 다국어 금액 포맷 분기 새 메시지 한 줄 추가하려고 200라인짜
읽기 → -
정산 주문 매칭 로직을 변경 축 기준으로 분리해 누락 추적 속도를 높임
매칭 로직을 다시 봐야 했던 이유 파트너별 정산 화면에서 주문 누락이 보고됐음. 입금 데이터를 받아 주문과 매칭하고, 그 결과로 파트너를 결정한 뒤 계좌를 조회하는 흐름인데, 단계마다 책임이 섞여 있어서 어느 단계에서 어긋난 건지 추적이 오래 걸림. 기존 컨트롤러는 다음을 한꺼번에 하고 있었음: - 입금 식별자 파싱 - 주문 후보 조회 - 매칭 우선
읽기 → -
파트너 대시보드에 송금·주문 통계 위젯 추가
파트너 대시보드에 송금·주문 통계 붙이기 기존 파트너 대시보드는 결제 흐름 위주로만 정보를 뿌려줬음. 그러다 보니 파트너가 송금 내역이나 주문 추이를 보려면 메뉴를 두세 번 더 타고 들어가야 했고, "한 화면에서 다 보고 싶다"는 피드백이 누적돼 있었음. 이번 작업으로 두 가지를 한 위젯 영역에 묶었음. - 연락처 송금 통계: 일/주/월 단위 송금
읽기 → -
파트너 화면에 쿠폰·광고·메시지 메뉴 4종 추가
사이드바부터 손댄 이유 파트너 화면 기능이 늘어나는데 진입점은 그대로였음. 신규 페이지를 한꺼번에 붙이려니 메뉴 구조부터 정리해야 했음. 단순 링크 추가가 아니라 권한 단계에 따라 노출 항목이 달라져서, 사이드바 모델을 손볼 수밖에 없었음. 한 번에 묶은 화면들 오늘 붙인 컨트롤러는 4종류: - 파트너 간 메시지 화면 - 쿠폰 광고 배너 관리 -
읽기 → -
포트폴리오에서 비공개 저장소 링크 노출 차단
비공개 저장소 링크 제거하다 발견한 권한 누수 포트폴리오 페이지에 프로젝트 리스트 뿌리는데, 비공개 레포까지 그냥 클릭 가능한 링크로 박혀있던 걸 뒤늦게 발견함. 외부에서 클릭하면 404로 튕기긴 하지만, 그 자체로 "여기 비공개 레포 있음"을 노출하는 거라 좋은 그림은 아님. 뭐가 문제였는지 - 카드 컴포넌트에서 repo.url 을 무조건 앵커
읽기 → -
깃허브 프로필을 터미널 테마로 전면 개편한 과정
프로필 README 갈아엎은 이유 오랜만에 깃허브 프로필 들어가봤더니 예전에 대충 박아둔 자기소개랑 깨진 뱃지 몇 개가 다였음. 방문자가 와도 내가 뭘 하는 사람인지, 뭘 만들어왔는지 30초 안에 파악이 안 되는 구조였음. 한 번 갈아엎기로 결정. 목표는 두 가지로 잡음. - **첫 인상에서 정체성 전달**: 어떤 스택을 쓰고 어떤 결과물을 만드는지
읽기 → -
가맹점 계좌 승인 알림 누락과 사이드바 메뉴 미노출 수정
계좌 승인 알림이 사라진 이유 파트너 포탈에서 신규 가맹점 계좌 등록 후 관리자 승인 알림이 안 떴음. 가맹점은 등록했다고 알고 있는데 정작 관리자는 모름. 결과적으로 "왜 며칠째 승인이 안 나냐"는 문의가 누적됨. 원인은 두 군데였음. - 관리자 컨트롤러에서 알림 큐 적재 로직이 빠져있었음 (예전 리팩터링 때 누락 추정) - 파트너 포탈 사이드바에서
읽기 → -
결제 구간 앱 서명 위변조 트래픽을 단계별로 차단한 방법
배경 모바일 앱에서 서버로 들어오는 요청이 진짜 우리 앱에서 온 게 맞는지 확인할 방법이 필요했음. 그동안 디바이스 식별자만 보고 신뢰했는데, 리패키징된 패키지로 위변조 트래픽이 들어오는 정황이 잡힘. 결제대행사 연동 구간이라 더 미룰 수 없었음. 접근 — X-Sig-Hash 헤더 앱 서명 인증서의 SHA-256 해시를 매 요청마다 헤더에 실어 보
읽기 → -
결제 웹훅 원장·잔액 대조 배치로 정산 분쟁 추적 가능해짐
웹훅 원장 기록부터 깔았음 결제대행사 웹훅이 들어올 때 처리만 하고 흘려보내던 구조였는데, 정산 분쟁 한 번 터지고 나니 "그때 그 웹훅 진짜 왔었냐"는 질문에 답을 못 했음. 헤더, 페이로드, 서명검증 결과, 처리 결과까지 전부 원장으로 적재하기로 했음. - 들어온 원본은 가공 없이 그대로 저장 - 처리 단계별 상태 코드 분리 (수신완료 / 검증완료
읽기 → -
충전 수수료를 충전 트랜잭션 단위로 매칭해 회계 역추적 해결
충전 수수료 차감, 어느 시점 요율을 따라야 하나 결제 플랫폼에서 파트너가 잔액을 충전할 때 충전 수수료를 떼는 구조인데, 환불·취소 흐름에서 차감 기준이 애매했음. 충전 시점 요율을 박아두는 방식이었는데, 파트너 등급이 중간에 바뀌면 과거 충전건과 현재 차감액이 어긋남. 회계팀에서 "이 충전건이 그 차감인지 매칭이 안 된다"는 컴플레인이 들어와서 손을
읽기 → -
입금 웹훅 구조를 레지스트리 패턴으로 전환해 은행 추가 용이성 개선
배경 연락처 송금 기능에 입금 통보 받을 은행이 한 곳 더 늘어남. 기존엔 진입 컨트롤러에서 은행 코드별 if-else로 분기하던 구조라 추가할 때마다 같은 파일을 또 건드려야 했음. 이번에 인터넷전문은행 한 곳 더 붙이라는 요청 받았는데, 같은 자리를 또 손대기 싫어서 레지스트리 패턴으로 갈아엎기로 함. 무엇을 바꿨나 - 결제대행사 웹훅 수신 진입점
읽기 → -
에이전트 산출물 디렉터리를 깃이그노어로 차단해 PR 노이즈 제거
.omc/ 를 .gitignore 에 박은 이유 작업 도중 워킹트리에 .omc/ 디렉터리가 슬금슬금 늘어나는 걸 발견함. 에이전트 상태, 노트패드, 프로젝트 메모리, 플랜 초안, 로그까지 죄다 그 안에 쌓이고 있었음. 깜빡하고 한 번 커밋했다가 PR 디프가 본질 변경 30줄에 부산물 800줄로 부풀어버려서, 리뷰어가 "이거 뭐냐"고 물어본 게 트리거였음
읽기 → -
결제 웹훅 중복 처리를 멱등성 락으로 차단
결제대행사 Webhook이 같은 건을 두 번 때리는 문제 운영 중 결제대행사에서 같은 결제 건에 대해 동일한 웹훅이 두 번, 세 번 들어오는 케이스가 누적됨. 첫 호출에서 정상 처리됐는데 두 번째 호출이 잔액을 한 번 더 건드리거나 알림이 중복 발송되는 사고가 발생했음. 원인을 정리하면 이런 흐름이었음. - 결제대행사가 응답 ACK를 못 받으면 일정
읽기 → -
송금 수수료 홀딩 정책 도입과 파트너별 입금 통계 화면 추가
연락처 송금 수수료 관리, 그리고 파트너 입금 통계 오늘은 결제 플랫폼에 두 가지를 한 번에 밀어넣음. 하나는 연락처 송금 흐름에 수수료 정책을 붙이는 작업, 다른 하나는 파트너별로 입금 내역을 합산해서 운영팀이 볼 수 있게 만드는 통계 화면. 처음엔 두 작업이 별개라고 생각했는데, 막상 들여다보니 **잔액 계산 유틸리티**가 양쪽에서 똑같이 호출되고
읽기 → -
송금 대사 배치로 원장·결제·큐 불일치 자동 감지
연락처 송금 대사 배치를 만들게 된 이유 운영 들어간 지 한 달쯤 됐을 때 파트너 한 곳에서 "어제 송금 건 합계가 안 맞는다"는 문의가 들어왔음. 큐에 쌓인 송금 요청, 결제대행사로 넘긴 실제 출금, 우리 원장 잔액 차감 — 이 셋이 따로 노는 순간이 가끔 있다는 걸 그제서야 발견함. 사람이 매일 아침 SQL 돌려서 맞추고 있었는데 이게 지속 가능하지
읽기 → -
파트너 정산 은행 도메인 누락으로 송금 인증 실패하던 문제 수정
채팅 메시지 속 은행 링크를 못 찾았음 파트너 정산 채널에서 송금 인증 캡처 대신 메시지 앱 링크를 그대로 붙여넣는 케이스가 점점 늘었음. 메시지 본문에서 은행 도메인을 뽑아 송금 사실을 검증하는 로직이 있는데, CS팀에서 "특정 은행만 매번 인증 실패가 난다"는 리포트가 연달아 들어옴. 원인: 도메인 화이트리스트 노후화 은행 URL 추출기는 정규
읽기 → -
송금 URL로 은행 자동 판별하는 구조 짜기
캡처된 송금 URL을 어떻게 받을지 고민함 스마트폰에서 연락처 송금을 누르면 은행 앱이 뜨는 게 일반적인데, 우리는 한 칸 앞에 끼어들어야 했음. 사용자가 송금 직전에 URL을 캡처해 넘겨주면, 그걸 보고 어느 은행인지 판별하고 후속 흐름을 잇는 구조. 문제는 은행마다 URL 포맷이 제각각이라는 점. 은행 판별을 어떻게 짰나 처음엔 정규식 한 줄
읽기 → -
연락처 송금 결제수단 추가로 콜백과 매칭 로직 전면 재작성
연락처 송금이 결제수단으로 들어왔을 때 이커머스 결제 흐름에 새 결제수단이 하나 끼어들었음. 기존 카드/가상계좌/포인트 옆에 "연락처 송금"이 들어오는 작업. 처음엔 단순히 결제수단 enum 하나 늘리는 줄 알았는데, 까보니 매칭 로직이 본체였음. 매칭이 진짜 일이었음 연락처 기반이라 "보낸 사람 번호"와 "받을 사람 번호"가 정확히 매핑돼야 함
읽기 → -
연락처이체 자동화 오류 13건을 조건 대기와 이중 검증으로 해결
13개가 한꺼번에 터졌다 연락처이체 웹 자동화가 또 깨졌음. 은행별 페이지 구조가 미묘하게 달라서 한 곳 고치면 다른 데서 터지는 두더지잡기. 이번엔 분산해서 잡지 말고 13개 케이스 한꺼번에 모아서 정리함. 증상은 비슷했음: - "이체 성공"으로 찍혔는데 실제 거래는 미체결 - 페이지 전환 도중 다음 step 클릭해서 element not found
읽기 →