일기
회고 / 메모
-
쿠폰 재전송 횟수 추적 컬럼을 발급 이력 테이블에 추가
tb_coupon_issue_history 테이블에 resend_count 컬럼을 추가하는 DDL 작업을 했다.
읽기 → -
시드 스크립트 로그의 운영 정보 자동 마스킹으로 보안 강화
보안 스캔 자동화 시스템을 다시 점검하던 중, 기존 마스킹 규칙이 너무 성글다는 걸 깨달았다. 인프라 운영 관련 민감 정보가 로그나 시드 데이터에 노출될 여지가 있었고, 이걸 체계적으로 막기 위해 차단 룰을 한 단계 더 촘촘하게 만들기로 했다.
읽기 → -
관리자 진입 경로를 README와 푸터에 명확히 정리
README와 footer에 관리자 진입 경로를 명확히 문서화했다. 단순 UI 텍스트 추가 같아 보이지만, 실제로는 사용자 접근성과 운영 효율성에 영향을 미치는 작은 결정들이 담겨 있었다.
읽기 → -
개인 블로그 관리 시스템 뼈대를 처음부터 직접 설계해 띄운 이야기
새 프로젝트를 처음부터 차려 올렸다. 개인 블로그 운영을 위한 간단한 관리 시스템을 만들기로 결심하고, 깔끔한 프로젝트 구조 위에 첫 커밋을 띄웠다. 프로젝트 초기화의 작은 신중함 initial commit 이라고 해서 아무렇게나 파일을 던지는 건 아니다. 특히 1인 개발이지만, 나중에 협업하거나 코드를 공개할 가능성을 염두에 두고 처음부터 정리정돈하
읽기 → -
환경변수 템플릿 도입으로 신규 팀원 온보딩 간소화
환경 설정 템플릿을 버전 관리에 포함시켜서 새로운 팀원이나 로컬 셋업이 훨씬 수월해졌다. 왜 .env.example이 필요한가 프로젝트를 처음 받았을 때 가장 답답한 순간이 뭐냐면, 어떤 환경 변수를 설정해야 하는지 알 수 없다는 거다. .env 파일은 보안상 git에 커밋하면 안 되니까 .gitignore에 등재하는 게 표준이다. 그런데 정작 어떤
읽기 → -
결산 고도화와 안드로이드 결제 모니터 엣지 케이스 정복
4월, 638개 커밋. 28개월 중 최고치다. 새 회사 두 번째 달이면서 자동화, 결산, 모니터링이 동시에 달렸다.
읽기 → -
카드 결제 PENDING 상태의 발생주의 정산 기준 정책화
내부 정책 문서에 발생주의 카드의 PENDING 상태 처리 방식을 추가했다. 배경: 카드 결제와 PENDING 상태의 모호함 결제 플랫폼을 다루다 보면 "발생주의" vs "현금주의" 같은 회계 원칙과 실제 결제 상태가 자주 엇갈린다. 특히 카드 거래는 승인 요청을 한다고 해서 즉시 돈이 빠지는 게 아니라, 몇 시간에서 며칠에 걸쳐 정산이 진행된다. 그
읽기 → -
수수료 최소값과 비교 기준값을 정책 문서에서 명확히 분리
내부 정책 문서를 정리하면서 '비교 기준값'과 '플랫폼 수수료 최소값' 두 개념을 명확히 분리했다. 한 파일에서 여러 정책을 관리할 때 이런 개념 분리가 왜 중요한지, 그리고 어떤 문제를 예방하는지 정리해봤다. 두 가지 값의 혼동이 왜 생기나 시스템을 운영하다 보면 '기준'이라는 단어가 여러 맥락에서 나타난다. 비교 기준값(A)은 어떤 조건을 판단할
읽기 → -
잔액 동기화 배치 주기를 2시간마다로 단축해 데이터 최신성 개선
유지보수성 개선 작업. 잔액 동기화 주기 매일 06:00 → 2시간마다 :11분. 변경 파일: 내부 클래스 2개, 설정/문서 1개, 뷰/스타일 1개 배경 기능 변경 없이 내부 품질을 높이기 위한 작업. 설정 값 업데이트, 스케줄 조정, 문서 보완 등 개발 환경과 운영 편의성을 개선했음. 스케줄 조정 이유 배치 실행 주기를 변경했음. 너무 자주 실
읽기 → -
hold 정책 변경에 맞춰 stale 안내 문구 정정
유지보수성 개선 작업. hold 2h→2h 10m 정책 변경에 따른 stale 안내 문구 정정. 변경 파일: 뷰/스타일 2개, 내부 클래스 1개, SQL 매퍼 1개 배경 기능 변경 없이 내부 품질을 높이기 위한 작업. 설정 값 업데이트, 스케줄 조정, 문서 보완 등 개발 환경과 운영 편의성을 개선했음. 작업 내용 설정 파일, 문서, 또는 빌드 스
읽기 → -
등급 임시 테이블 스키마에 활성 회원 고유 키 반영
문서 작업을 진행했음. tb_grade_temp_revert 정본에 active_member_sn + uk_grtr_active_member 반영. 변경 파일: SQL 파일 1개 작성 목적 코드에서 바로 읽기 어려운 정책, 설계 결정, 운영 규칙을 문서로 남겼음. "왜 이렇게 구현했는가"에 대한 배경을 기록해두지 않으면 나중에 다시 처음부터 고민하게
읽기 → -
파트너 잔액 정산 감사 내부 정책 문서화
문서 작업을 진행했음. tb_partner_balance_audit 가이드 추가 (내부 정책). 변경 파일: 설정/문서 2개 작성 목적 코드에서 바로 읽기 어려운 정책, 설계 결정, 운영 규칙을 문서로 남겼음. "왜 이렇게 구현했는가"에 대한 배경을 기록해두지 않으면 나중에 다시 처음부터 고민하게 됨. 정책 문서화 비즈니스 규칙은 코드에만 있으면
읽기 → -
깃허브 프로필 기술 스택 정정
GitHub 프로필 README를 업데이트했음. 간편결제 플랫폼 스택 정정(JSP/Thymeleaf/jQuery) + 회사명 마스킹. 변경 목적 개발자 프로필은 첫인상이 중요함. 채용 담당자나 협업 상대가 프로필을 볼 때 5초 안에 어떤 개발자인지 파악할 수 있어야 한다고 생각해서 계속 다듬는 중. 특히 GitHub 프로필은 이력서보다 먼저 보는 경우가 많아서
읽기 → -
GitHub 프로필에 KOSA 검증 경력
GitHub 프로필 README를 업데이트했음. KOSA 검증 경력 반영 + 간편결제 플랫폼 row 정정 + Verified Career 섹션 추가. 변경 목적 개발자 프로필은 첫인상이 중요함. 채용 담당자나 협업 상대가 프로필을 볼 때 5초 안에 어떤 개발자인지 파악할 수 있어야 한다고 생각해서 계속 다듬는 중. 특히 GitHub 프로필은 이력서보다 먼저 보
읽기 → -
출금 모달 개선
partner 버그를 수정했음. 출금 모달 UX 개선 및 정산계좌 승인시각 기록 보정. 변경 파일: SQL 매퍼 1개, 뷰/스타일 1개 문제 원인 기존 로직에서 엣지 케이스가 처리되지 않아 특정 상황에서 잘못된 결과를 반환하거나 오류가 발생하고 있었음. 수정 내용 - SQL 쿼리 조건/집계 수정 - 화면 렌더링 수정 - 프론트 스크립트 수정
읽기 → -
거래명세서 집계 구조를 결제 단일 행으로 단순화
statement 리팩토링을 진행했음. 거래명세서 집계 단순화 — 결제 단일 행으로 통일. 변경 파일: 내부 클래스 1개, SQL 매퍼 1개, 뷰/스타일 1개 리팩토링 이유 기능은 잘 돌아가지만 코드 구조가 나중에 유지보수하기 어려운 상태였음. 특히 같은 로직이 여러 곳에 중복돼 있거나, 한 파일에 너무 많은 책임이 몰려 있는 경우가 있었음. 기능 추
읽기 → -
결제 대시보드에 포인트 캐시 재계산
dashboard 영역에 새 기능을 추가했음. 시스템 포인트 캐시 수동 재계산 + UI 정리. 변경 파일: 내부 클래스 2개, SQL 매퍼 1개, 뷰/스타일 1개 배경 기존 화면/API에서 제공하지 않던 데이터나 동작이 필요해져서 기능을 확장했음. 단순 UI 추가가 아니라 쿼리 레벨부터 설계해서 정합성을 맞췄음. 구현 내용 - 대시보드에 신규 K
읽기 → -
정산 역분배 정책 문서 오류 정정
내부 정책 — 역분배(잔여 방식)가 정책임을 정정 내부 정책 — 역분배(잔여 방식)가 정책임을 정정 작업을 완료했음. 배경 서비스 운영 중에 필요한 정리/유지보수 작업이 있었음. 기능에는 영향을 주지 않지만 코드베이스 품질 유지에 필요한 작업임. 작업 내용 원칙 코드 정리는 기능 동작에 영향을 주지 않아야 함. 정리 전후로 동작이 같은지
읽기 → -
정산 SQL 롤백 대비 패치와 운영 DB 설계 점검
정산 유틸 수정 + 운영 SQL 패치 (세션 중 작업) 유지보수 및 정리 작업을 했음. 배경 기능 개발에 집중하다 보면 불필요한 코드, 오래된 설정, 중복 파일이 쌓임. 이런 기술 부채는 당장은 문제가 없어 보여도 점점 코드베이스를 읽기 어렵게 만듦. 작업 내용 - 운영 SQL 패치 파일 관리 - 롤백 SQL을 함께 작성해두어 문제 발생 시
읽기 → -
운영 DB 스키마와 결제 컬럼을 DDL 파일에 동기화
DDL_TABLES.sql 을 운영 3DB 현실에 맞춰 동기화 DDL 정의 파일을 운영 DB 현실에 맞춰 동기화했음. 배경 코드베이스에 DDL을 유지하는 이유는 스키마를 문서처럼 읽을 수 있게 하기 위함임. 운영 중에 ALTER를 직접 쳤거나 핫픽스로 컬럼을 추가하면 DDL 파일이 뒤처지기 시작함. 이 차이가 누적되면 새 환경 구성 시 재현이 안
읽기 →