2025-11-04-TIL TIL Today I Learned 오늘은 링크드인에서 B사의 개발자분이 직접 채용공고와 함께 글을 올린것을 보았다. 편하게 연락달라는 글과 연락처 및 메일, 그리고 채용공고 링크가 있었다. 이렇게 올라온 글은 어떤 목적으로 쓰여진 것일까? 내가 생각하기로는 지원자 입장에서는 편하게 연락해서 커피챗이나 간단한 통화를 해보고 내 이력서의 이름이라도 한 번 더... 2025/11/04 2025-TIL
주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 - 2장 느려진 서비스, 어디부터 봐야 할까 Book 서비스가 느려졌을 때 가장 흔한 실수는 “일단 코드 최적화부터 시작하는 것”이다. 실무에서는 먼저 병목이 어느 계층에 있는지부터 구분해야 한다. 기본 분류 성능 문제는 대체로 네 군데에서 시작한다. 애플리케이션 CPU 사용량 증가 DB 지연 외부 시스템 응답 지연 네트워크 또는 인프라 계층 문제 같은 “응답 지연”이어도 원... 2025/11/03 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식
유통사가 늘 때마다 복사되던 File Observer 구현체 정리: 제네릭을 걷어낸 Base 클래스와 DB 기반 권리사 ID 실무 사례 Notes 음원 콘텐츠 플랫폼(MCP)의 입수 파이프라인 앞단에는 File Observer라는 계층이 있었다. 유통사(소니, 워너, 유니버설, 카카오M, CD Baby 등)가 음원 원본 파일을 올리면, File Observer가 유통사별 디렉터리를 감시(observe)하다가 새 파일을 처리 대상으로 인식한다. 이 글은 그 계층의 구현체 쪽 중복을 내가 직접 정리... 2025/11/01 Common 음원 콘텐츠 플랫폼(MCP) 전면 개편 8편
주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 - 1장 들어가며 Book 이 책의 시작점은 단순하다. 주니어 백엔드 개발자는 언어 문법이나 프레임워크 문법을 아는 것만으로는 충분하지 않다. 실제 서비스 환경에서는 다음 질문에 답할 수 있어야 한다. 왜 서비스가 느려졌는가 DB가 병목일 때 어디를 봐야 하는가 외부 연동 실패를 어떻게 해석해야 하는가 동시성 문제를 어떤 관점으로 분해해야 하는가 서버, 네... 2025/10/28 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식
카카오 「MySQL DATETIME, TIMESTAMP 데이터 타입에 대한 분석」 리뷰 — 바이트 단위 저장 구조부터 아직 안 고쳐진 Y2K38까지 Tech Blog Review 원문: MySQL DATETIME, TIMESTAMP 데이터 타입에 대한 분석 — kakao tech, 2025-10-17 한 줄 요약 DATETIME은 연월일시분초를 5바이트 정수로 묶어 부호 오프셋을 더해 저장하고(정렬 순서가 시간 순서와 같게), TIMESTAMP는 세션 타임존으로 UTC로 바꿔 32비트 정수로 저장한다. 소수 초는 선언 ... 2025/10/27 Kakao 빅테크 기술 블로그 리뷰 14편
엑셀로 처리하던 계약 갱신과 라이선스 변경을 Spring Batch와 Jenkins로 옮긴 기록 실무 사례 Notes 음원 유통 시스템(MDS)의 계약은 만료일이 오면 연장되거나, 라이선스 변경에 따라 권리가 넘어가거나 서비스가 멈췄다가 다시 열린다. 리뉴얼 전에는 이 처리를 운영 담당자가 엑셀로 했다. 이 글은 그 처리를 Spring Batch Job과 Jenkins로 옮기면서 무엇을 나눴고, 실패를 어떻게 다뤘고, 무엇이 줄었는지 정리한 기록이다. 어떤 시스... 2025/10/26 Common 음원 유통 시스템(MDS) 리뉴얼 4편
폴링 배치를 SQS 이벤트 파이프라인으로 바꾼 이유: 재시도, DLQ, 메시지 ID 멱등 실무 사례 Notes 음원 유통 시스템(MDS)에서는 앨범 등록, 검수 요청, 외부 음원 플랫폼으로의 전송이 계속 발생한다. 처음에는 이 작업들을 폴링 배치가 순서대로 처리했다. 이 글은 그 구조가 어디서 막혔는지, 큐로 바꾸면서 무엇을 새로 떠안게 되는지(중복 전달, 순서, 실패 격리), 그리고 운영에서 확인된 것과 확인하지 못한 것을 나눠 정리한 기록이다. 어떤 ... 2025/10/19 Common 음원 유통 시스템(MDS) 리뉴얼 3편
같은 음원이 여러 유통사에서 들어올 때: 콘텐츠 유니피케이션 시스템을 운영하며 정리한 구조 실무 사례 Notes 음원 콘텐츠 플랫폼(MCP)에는 같은 음원이 여러 경로로 들어온다. 한 곡이 여러 유통사와 권리사를 거쳐 입수되고, 경로마다 제목 표기, 아티스트 이름, 앨범 정보가 조금씩 다르다. 이 중복을 하나로 묶는 것이 콘텐츠 유니피케이션(중복 통합) 시스템이다. 먼저 범위를 밝혀 둔다. 이 시스템은 내가 맡았을 때 이미 구축되어 있었고, 나는 설계자가 아니... 2025/10/11 Common 음원 플랫폼 운영과 클라우드 전환 2편
정산이 진행되는 동안 기준 데이터 수정을 막는 방법: 상태 플래그와 AOP로 만든 경량 락 실무 사례 Notes 음원 유통 시스템(MDS)에서 정산은 계약, 앨범, 곡 메타데이터를 기준으로 수익을 계산하는 프로세스였다. 이 글은 정산이 도는 동안 그 기준 데이터가 바뀌는 문제를 어떻게 막았는지, 왜 DB 락이 아니라 애플리케이션 레벨의 상태 플래그를 택했는지, 그 선택이 남긴 틈이 무엇인지 정리한 기록이다. 어떤 시스템이었나 MDS는 외주 개발사가 PHP... 2025/10/05 Common 음원 유통 시스템(MDS) 리뉴얼 2편
Map 기반 입력을 DTO와 3단계 검증으로 바꾸기: Bean Validation, 매핑, 도메인 규칙 실무 사례 Notes API를 도메인 책임 단위로 다시 나눈 작업과 같은 시기에, 음원 콘텐츠 플랫폼(MCP)의 입력 구조도 바꿨다. 기존 API는 요청 본문을 Map으로 받았고, 그 값이 맞는지 확인하는 코드는 여러 계층에 흩어져 있었다. 이 글은 그 구조가 어떤 문제를 만들었는지, 검증을 어떤 기준으로 세 단계로 나눴는지, 각 단계에 어떤 규칙을 두었는지, 그리고 이 ... 2025/09/27 Common 음원 콘텐츠 플랫폼(MCP) 전면 개편 7편