백엔드 시스템 로깅 베스트 프랙티스 Notes 로깅(logging)은 시스템의 상태를 추적하고 문제를 진단하는 수단이고, 보안 감사에 대응할 때 근거가 된다. 이 글은 Spring Boot 기반 백엔드 서비스를 기준으로 로깅 설계 원칙, 레벨, 수집 체계, 그리고 코드의 어느 시점에 무엇을 남기는지를 다룬다. 로그를 메트릭, 트레이스와 어떻게 나눠 쓰는지는 메트릭, 로그, 트레이스에서 따로 다뤘다... 2025/05/22 Common
테이블과 데이터만 남은 외주 시스템을 리뉴얼한 과정: 음원 유통 시스템(MDS) Notes 음원 플랫폼 회사에서 외주 개발사가 PHP로 만든 음원 유통 시스템을 새로 만든 프로젝트를 정리한다. 기존 시스템에서 넘겨받을 수 있었던 것은 테이블과 데이터뿐이었다. 그래서 이 프로젝트는 기존 코드를 옮기는 이관이 아니라, 기존 데이터에서 규칙을 읽어 스키마를 새로 설계하고 그 위에 시스템을 다시 세우는 리뉴얼이 되었다. 먼저 범위를 분명히 해 둔... 2025/05/22 Common 음원 유통 시스템(MDS) 리뉴얼 1편
MCP 전면 개편기: Map 입력을 DTO와 3단계 검증으로 바꾸기 실무 사례 Notes 음원 플랫폼 회사에서 2024년에 음원 콘텐츠 플랫폼(MCP)을 전면 개편했다. 이 시리즈는 그 개편에서 내가 직접 구현한 부분을 주제별로 나눠 정리한다. 1편은 입력 구조다. 요청을 Map으로 받던 API를 DTO로 바꾸고, 흩어져 있던 검증을 세 단계로 나눈 과정을 다룬다. 이 글의 코드는 회사의 실제 소스가 아니다. 기존 구조는 설명을 위... 2025/05/22 Common 음원 콘텐츠 플랫폼(MCP) 전면 개편 1편
MCP 전면 개편기: 계약 코드 채번의 락 경합을 줄여 2분을 10초로 실무 사례 Notes 1편에서 다룬 입력 구조와 같은 시기에, 음원 콘텐츠 플랫폼(MCP)의 계약 생성이 2분씩 걸리는 문제를 고쳤다. 원인은 계약 코드를 발급하는 방식, 즉 채번(번호를 매기는 일) 구조에 있었다. 이 글은 그 구조가 왜 락 경합을 만들었는지, 무엇을 바꿔 10초로 줄였는지, 그리고 나중에 확인한 그 설계의 결함까지 정리한다. 이 글의 SQL과 코... 2025/05/22 Common 음원 콘텐츠 플랫폼(MCP) 전면 개편 2편
MCP 전면 개편기: MyBatis와 JPA 공존 환경의 데이터 정합성 전략 실무 사례 Notes 2편까지는 음원 콘텐츠 플랫폼(MCP)의 입력과 채번을 다뤘다. 이 글은 데이터 접근 계층이다. MCP 개편에서는 변경을 MyBatis에 그대로 두고 조회만 JPA와 QueryDSL로 옮겼다. 그 결과 한 시스템 안에서 두 기술이 같은 테이블을 읽게 됐다. 이 글은 왜 그렇게 나눴는지, 두 기술이 같은 데이터를 다르게 해석하는 지점이 어디인지, 그리고... 2025/05/22 Common 음원 콘텐츠 플랫폼(MCP) 전면 개편 3편
MCP 전면 개편기: 화면 단위 API를 도메인 책임 API로 옮기기 실무 사례 Notes 1편부터 3편까지는 음원 콘텐츠 플랫폼(MCP) 개편에서 입력, 채번, 데이터 접근 계층을 다뤘다. 이 글은 그 위에 있는 API의 단위다. 기존 API는 화면 하나에 맞춰 만들어져 있었고, 그 결과 같은 데이터를 여러 번 읽고 하나의 변경을 여러 API에 나눠 담고 있었다. 이 글은 그 구조가 어떤 증상으로 드러났는지, API를 어떤 기준으로 다시 ... 2025/05/22 Common 음원 콘텐츠 플랫폼(MCP) 전면 개편 4편
MCP 전면 개편기: 판단 로직의 자리를 정하고 ArchUnit으로 지키기 실무 사례 Notes 1편부터 4편까지 음원 콘텐츠 플랫폼(MCP) 개편에서 각 판단의 자리를 정했다. 필드 하나로 판단하는 규칙은 요청 DTO에, 다른 데이터를 봐야 하는 규칙은 도메인 객체에, 트랜잭션 경계는 서비스 메서드 하나에 둔다. 이 글은 그 약속이 세 명이 동시에 작업하는 코드베이스에서 어떻게 흐트러졌는지, 그리고 그 약속을 테스트와 PR 검증으로 옮겨 지킨 ... 2025/05/22 Common 음원 콘텐츠 플랫폼(MCP) 전면 개편 5편
대용량 엑셀 다운로드 요청을 안정적으로 처리하는 방법 Notes 대용량 엑셀 다운로드는 처음에는 단순해 보인다. 쿼리를 실행하고, 결과로 파일을 만들고, 응답으로 내려주면 끝이다. 그런데 다운로드 건수가 수십만 건으로 커지고 같은 요청이 반복되면 이 기능 하나가 API 서버의 힙, DB 커넥션, 요청 스레드를 함께 붙잡는다. 이 글은 두 층으로 나뉜다. 앞쪽은 내가 실제로 겪고 고친 부분이다. 2022년 음원 플... 2025/05/22 Programming 대용량 배치·엑셀 처리 최적화 1편
무거운 엑셀 다운로드 요청을 사전에 판별하는 방법 Notes 엑셀 다운로드 기능을 운영하다 보면 모든 요청을 같은 경로로 처리하기 어렵다. 어떤 요청은 수백 건이라 즉시 내려줘도 되지만, 어떤 요청은 수십만 건을 읽어야 해서 비동기 경로로 넘기는 편이 낫다. 문제는 실행하기 전에는 그 차이가 보이지 않는다는 점이다. 이 글은 “이 요청을 즉시 처리해도 되는가, 비동기로 넘겨야 하는가”를 실행 전에 가늠하는 방... 2025/05/22 Programming 대용량 배치·엑셀 처리 최적화 2편
조건 기반 예측 캐싱: 고속 엑셀 다운로드 처리 구조 설계 Notes 전체 다운로드에 가까운 양을 요구하면서 조건이 조금씩 붙는 엑셀 요청은 미리 만들어 둘 수도 없고, 매번 처음부터 만들기에는 무겁다. 이 글은 그런 요청을 처리 비용으로 먼저 분류하고, 무거운 조건의 결과만 골라 재사용하는 구조를 설계로 정리한다. 이 글은 설계 글이다. 엑셀에 대해 내가 실제로 고치고 수치로 확인한 것은 생성 단계의 메모리다. 20... 2025/05/22 Architecture 대용량 배치·엑셀 처리 최적화 3편