일기 · slecs 블로그 — 개발·자동화·사이드프로젝트 실전 기록

새 프로젝트를 처음부터 차려 올렸다. 개인 블로그 운영을 위한 간단한 관리 시스템을 만들기로 결심하고, 깔끔한 프로젝트 구조 위에 첫 커밋을 띄웠다. 프로젝트 초기화의 작은 신중함 initial commit 이라고 해서 아무렇게나 파일을 던지는 건 아니다. 특히 1인 개발이지만, 나중에 협업하거나 코드를 공개할 가능성을 염두에 두고 처음부터 정리정돈하

읽기 →

일기 2026-05-05

환경변수 템플릿 도입으로 신규 팀원 온보딩 간소화

환경 설정 템플릿을 버전 관리에 포함시켜서 새로운 팀원이나 로컬 셋업이 훨씬 수월해졌다. 왜 .env.example이 필요한가 프로젝트를 처음 받았을 때 가장 답답한 순간이 뭐냐면, 어떤 환경 변수를 설정해야 하는지 알 수 없다는 거다. .env 파일은 보안상 git에 커밋하면 안 되니까 .gitignore에 등재하는 게 표준이다. 그런데 정작 어떤

읽기 →

일기 2026-04-30

결산 고도화와 안드로이드 결제 모니터 엣지 케이스 정복

4월, 638개 커밋. 28개월 중 최고치다. 새 회사 두 번째 달이면서 자동화, 결산, 모니터링이 동시에 달렸다.

읽기 →

일기 2026-04-30

카드 결제 PENDING 상태의 발생주의 정산 기준 정책화

내부 정책 문서에 발생주의 카드의 PENDING 상태 처리 방식을 추가했다. 배경: 카드 결제와 PENDING 상태의 모호함 결제 플랫폼을 다루다 보면 "발생주의" vs "현금주의" 같은 회계 원칙과 실제 결제 상태가 자주 엇갈린다. 특히 카드 거래는 승인 요청을 한다고 해서 즉시 돈이 빠지는 게 아니라, 몇 시간에서 며칠에 걸쳐 정산이 진행된다. 그

읽기 →

일기 2026-04-30

수수료 최소값과 비교 기준값을 정책 문서에서 명확히 분리

내부 정책 문서를 정리하면서 '비교 기준값'과 '플랫폼 수수료 최소값' 두 개념을 명확히 분리했다. 한 파일에서 여러 정책을 관리할 때 이런 개념 분리가 왜 중요한지, 그리고 어떤 문제를 예방하는지 정리해봤다. 두 가지 값의 혼동이 왜 생기나 시스템을 운영하다 보면 '기준'이라는 단어가 여러 맥락에서 나타난다. 비교 기준값(A)은 어떤 조건을 판단할

읽기 →

일기 2026-04-29

잔액 동기화 배치 주기를 2시간마다로 단축해 데이터 최신성 개선

유지보수성 개선 작업. 잔액 동기화 주기 매일 06:00 → 2시간마다 :11분. 변경 파일: 내부 클래스 2개, 설정/문서 1개, 뷰/스타일 1개 배경 기능 변경 없이 내부 품질을 높이기 위한 작업. 설정 값 업데이트, 스케줄 조정, 문서 보완 등 개발 환경과 운영 편의성을 개선했음. 스케줄 조정 이유 배치 실행 주기를 변경했음. 너무 자주 실

읽기 →

일기 2026-04-27

hold 정책 변경에 맞춰 stale 안내 문구 정정

유지보수성 개선 작업. hold 2h→2h 10m 정책 변경에 따른 stale 안내 문구 정정. 변경 파일: 뷰/스타일 2개, 내부 클래스 1개, SQL 매퍼 1개 배경 기능 변경 없이 내부 품질을 높이기 위한 작업. 설정 값 업데이트, 스케줄 조정, 문서 보완 등 개발 환경과 운영 편의성을 개선했음. 작업 내용 설정 파일, 문서, 또는 빌드 스

읽기 →

일기 2026-04-26

등급 임시 테이블 스키마에 활성 회원 고유 키 반영

문서 작업을 진행했음. tb_grade_temp_revert 정본에 active_member_sn + uk_grtr_active_member 반영. 변경 파일: SQL 파일 1개 작성 목적 코드에서 바로 읽기 어려운 정책, 설계 결정, 운영 규칙을 문서로 남겼음. "왜 이렇게 구현했는가"에 대한 배경을 기록해두지 않으면 나중에 다시 처음부터 고민하게

읽기 →