일기
회고 / 메모
-
사이트 목록 중복 로직 제거로 가독성·유지보수성 개선
사이트 목록 품질 개선 리팩토링 작업을 완료했음. 리팩토링 이유 코드 가독성과 유지보수성 향상을 위한 리팩토링이었음. 변경 전/후 java // 수정 전: 중복/복잡 로직 // 각 클래스에 동일 로직 반복 // 수정 후: 명확하고 단일 책임 public static Long resolveId(Object source) { if (so
읽기 → -
Gradle 병렬빌드·GC 최적화로 빌드 속도 개선
gradle JVM 힙·G1GC·병렬빌드 설정 최적화 Gradle 빌드 환경 설정을 개선했음. 배경 빌드 속도와 안정성은 개발 생산성에 직접 영향을 줌. 특히 멀티모듈 프로젝트에서 병렬 빌드를 활성화하지 않으면 불필요하게 순차 처리를 기다리게 됨. 변경 설정 properties gradle.properties org.gradle.jvmarg
읽기 → -
월 매출 쿼리에 쿠폰판매 합산
월 매출 쿼리에 쿠폰판매 합산 + 주석 정비 리팩토링 작업을 완료했음. 리팩토링 이유 쿼리가 복잡해지면서 실행 계획을 예측하기 어려워졌음. 가독성과 성능을 동시에 개선했음. 변경 전/후 sql -- 수정 후: 명확한 컬럼 구조 SELECT DATE_FORMAT(t.created_at, '%Y-%m') as month, SUM(CASE
읽기 → -
대시보드 카드 정리
대시보드 카드 정리 + 정산 출금 로그 파트너 추적 대시보드 카드 정리 + 정산 출금 로그 파트너 추적 기능을 구현했음. 배경 기능 확장에 따라 관리 편의성과 사용자 경험을 높이기 위해 구현했음. 구현 방식 내부 클래스 2개, SQL 쿼리 2개, JSP 화면 2개를 작성했음. 코드 예시 java // 핵심 로직 public void ex
읽기 → -
파트너 대시보드 계층 분기와 PENDING 정산 구조 개선
파트너 대시보드 계층 분기 + PENDING 정산 구조 최종 정리 파트너 대시보드 계층 분기 + PENDING 정산 구조 최종 정리 기능을 구현했음. 배경 기능 확장에 따라 관리 편의성과 사용자 경험을 높이기 위해 구현했음. 구현 방식 내부 클래스 1개, JSP 화면 1개를 작성했음. 코드 예시 java // 핵심 로직 public vo
읽기 → -
파트너 대시보드 역배분 엣지케이스 버그 수정
파트너 대시보드 데이터 정리 및 역배분 예시 수정 파트너 대시보드 데이터 정리 및 역배분 예시 수정 버그를 수정했음. 원인 분석 로직 일부가 엣지케이스를 처리하지 못하고 있었음. 실제 운영 데이터에서 발생한 케이스로 재현했음. 재현 조건 특정 조건에서 의도치 않은 동작 확인. 수정 내용 java // 수정 전: 엣지케이스 미처리 publ
읽기 → -
파트너 포탈 SQL·CSS 리팩토링으로 가독성과 유지보수성 개선
파트너 포탈 CSS 리팩토링 및 SQL 개선 리팩토링 작업을 완료했음. 리팩토링 이유 코드 가독성과 유지보수성 향상을 위한 리팩토링이었음. 변경 전/후 java // 수정 전: 중복/복잡 로직 // 각 클래스에 동일 로직 반복 // 수정 후: 명확하고 단일 책임 public static Long resolveId(Object source)
읽기 → -
중복 매칭 로직 정리로 코드 유지보수성 향상
불필요한 UI 컴포넌트 및 Java 매칭 로직 개선 리팩토링 작업을 완료했음. 리팩토링 이유 코드 가독성과 유지보수성 향상을 위한 리팩토링이었음. 변경 전/후 java // 수정 전: 중복/복잡 로직 // 각 클래스에 동일 로직 반복 // 수정 후: 명확하고 단일 책임 public static Long resolveId(Object sour
읽기 → -
CSS 공통 스타일 정비로 코드베이스 가독성 개선
apple.css 초기화 및 공통 스타일 정의 추가 유지보수 및 정리 작업을 했음. 배경 기능 개발에 집중하다 보면 불필요한 코드, 오래된 설정, 중복 파일이 쌓임. 이런 기술 부채는 당장은 문제가 없어 보여도 점점 코드베이스를 읽기 어렵게 만듦. 작업 내용 - CSS 파일 초기화 및 공통 스타일 재정의 - 불필요하게 쌓인 override 규
읽기 → -
파트너 가입 페이지 UI 개선
파트너 가입 페이지 UI 개선 및 CSS 통합 리팩토링 작업을 완료했음. 리팩토링 이유 코드 가독성과 유지보수성 향상을 위한 리팩토링이었음. 변경 전/후 java // 수정 전: 중복/복잡 로직 // 각 클래스에 동일 로직 반복 // 수정 후: 명확하고 단일 책임 public static Long resolveId(Object source)
읽기 → -
파트너 가입 정책 개선
파트너 관리 및 가입 정책 개선, 비밀번호 초기화 로직 추가 파트너 관리 및 가입 정책 개선, 비밀번호 초기화 로직 추가 기능을 구현했음. 배경 기능 확장에 따라 관리 편의성과 사용자 경험을 높이기 위해 구현했음. 구현 방식 내부 클래스 6개를 작성했음. 코드 예시 java // 핵심 로직 public void execute(Reques
읽기 → -
하위 정산 관리 JSP 삭제로 코드베이스 기술 부채 해소
불필요한 하위 정산 관리 JSP 제거 및 관련 코드 정리 유지보수 및 정리 작업을 했음. 배경 기능 개발에 집중하다 보면 불필요한 코드, 오래된 설정, 중복 파일이 쌓임. 이런 기술 부채는 당장은 문제가 없어 보여도 점점 코드베이스를 읽기 어렵게 만듦. 작업 내용 - 사용하지 않는 JSP/코드 제거 - 데드코드 방치 시 코드베이스 파악이 어려
읽기 → -
공통코드 초기화 스크립트 추가로 신규 환경 세팅 자동화
공통코드 그룹 및 상세 항목 초기화 스크립트 추가 2026-04-01에 공통코드 관련 기능을 추가했음. 공통코드는 상태값, 타입, 카테고리 같은 값들을 DB에서 관리하는 구조임. 하드코딩을 줄이고, 관리자가 화면에서 코드 목록을 수정할 수 있게 하는 게 목적임. 구조 공통코드 그룹 (GROUP_CODE) ├── 코드 항목 1 (CODE_VA
읽기 → -
결제 모니터링·영상 다운로더 직접 제작한 이직 첫 달 적응기
3월, 새 회사 첫 달. 공식 등록은 아직이었는데, 그건 절차의 문제이고 실제 작업은 3월 초부터 시작됐다.
읽기 → -
쇼핑몰과 운영서버 간 공급 모듈 통신 초기 세팅
쇼핑몰 플랫폼과 운영서버 간 공급 모듈 통신 초기 세팅 2026-03-31에 기능을 추가하거나 개선했음. 수정 파일: 내부 클래스, 내부 클래스, common.js 실제로 사용자가 쓰는 흐름에서 필요한 기능이었거나, 운영 중 발견된 개선 포인트를 반영한 작업임. 구현 포인트 - 요청 파라미터 검증 및 바인딩 처리 - 내부 클래스에서 비즈니스 로
읽기 → -
커미션 조회 화면 안정성
20260329 0230 commission-overview-refactor 2026-03-29에 기능을 추가하거나 개선했음. 수정 파일: 내부 클래스 실제로 사용자가 쓰는 흐름에서 필요한 기능이었거나, 운영 중 발견된 개선 포인트를 반영한 작업임. 구현 포인트 - 요청 파라미터 검증 및 바인딩 처리 - 내부 클래스에서 비즈니스 로직 처리 -
읽기 → -
은행 이체 알림 판정을 정규식 우선으로 전환해 응답 속도 개선
정규식 먼저, AI는 폴백으로 은행 알림에서 "이체 완료" 여부를 판정하는 핸들러들을 손봤음. 기존엔 AI 분류기를 1차로 돌리고 정규식을 폴백으로 두는 구조였는데, 이걸 뒤집었음. 정규식 1차, AI 폴백. 왜 뒤집었나 처음 설계 의도는 "AI가 더 똑똑하니까 먼저 시키고, 못 잡으면 정규식이 보조한다"였음. 근데 운영 들어가니 뒤집힌 비용 구조
읽기 → -
SMS 수신 추적과 자체 점유인증으로 알림 사각지대 제거
알림 수신 통계 — 보낸 것보다 받은 게 더 중요했음 이커머스 운영하면서 결제·배송 알림을 SMS로 쏴왔는데, 그동안 로그에는 "발송했음"만 남기고 있었음. 근데 진짜 봐야 할 건 **수신자가 실제로 받았느냐**였음. 통신사 리포트랑 우리 발송 카운트가 종종 어긋났고, 파트너 CS로 "고객이 못 받았다" 컴플레인이 들어오면 추적이 어려웠음. 이번에 회
읽기 → -
입금 매칭 라우팅 개선으로 은행 통보 미매칭 70% 복구
배경: 은행 통보 메시지 라우팅이 자꾸 어긋남 파트너 입금 매칭 파이프라인은 SMS/푸시로 들어온 은행 통보를 파싱해 은행별 핸들러로 보내는 구조임. 그런데 한 시중은행이 발신 번호 포맷을 살짝 바꿨는지, 그 시점부터 매칭률이 슬금슬금 떨어지기 시작함. 룰이 헤더 패턴 한 줄에만 의존하고 있어서, 통신사가 표기 방식을 손대거나 은행이 캠페인 문구를 끼우
읽기 → -
송금 매칭 쿼리에 파트너 식별자 누락으로 인한 오정산 수정
송금 주문 매칭에서 새어나간 필터 이커머스 결제 플랫폼에서 연락처 기반 송금 기능을 만지다가 매칭 로직에 구멍 발견함. 입금 통보가 들어오면 미체결 송금 주문을 찾아 매칭하는데, 파트너 식별자를 조건에 안 넣고 있었음. 다른 파트너의 동일 금액·동일 계좌 주문이 우연히 먼저 잡히면 엉뚱한 곳으로 정산이 흘러가는 시나리오였음. 발견한 순간 등에 식은땀.
읽기 →