주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 - 6장 동시성, 데이터가 꼬이기 전에 잡아야 한다 Book 동시성 문제는 멀티스레드 문법 문제로만 이해하면 부족하다. 실무에서 동시성은 대부분 “같은 데이터를 여러 요청이 동시에 건드릴 때 어떤 결과가 만들어지는가”의 문제다. 자주 만나는 동시성 문제 Lost Update Double Spending 중복 처리 재고 음수 상태 전이 꼬임 순서 역전 왜 위험한가 테스트 환경에서는... 2026/02/14 Book, 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식
대용량 파일 업로드를 위한 Presigned URL Notes Presigned URL이 필요한 이유 파일 업로드를 API 서버가 직접 중계하면 파일 크기가 커질수록 서버가 불필요한 병목이 된다. 네트워크 대역폭, 메모리, 타임아웃 관리 비용이 모두 서버 쪽으로 몰리기 때문이다. Presigned URL은 이 문제를 해결하기 위해, 서버가 스토리지 접근 권한만 짧게 위임하고 실제 파일 전송은 클라이언트가 스토... 2026/02/13 Notes, Web
주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 - 5장 비동기 연동, 언제 어떻게 써야 할까 Book 비동기는 단순히 “빠르게 만드는 기법”이 아니다. 정확히는 요청 처리 경로를 분리해서 사용자 응답 시간과 내부 처리 비용을 분리하는 설계 방식에 가깝다. 언제 비동기를 고려해야 하는가 요청 직후 반드시 끝날 필요가 없는 작업 오래 걸리는 외부 연동 대량 처리 실패해도 재시도 가능한 작업 사용자 경험과 분리해도 되는 후처리 예... 2026/02/10 Book, 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식
주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 - 4장 외부 연동이 문제일 때 살펴봐야 할 것들 Book 외부 시스템 연동은 “우리 코드가 아닌 부분”이 섞이기 때문에 장애 해석이 더 어렵다. 실무에서는 연동 자체보다 실패를 어떻게 다루는가가 더 중요하다. 외부 연동에서 흔한 문제 타임아웃 일시적 네트워크 실패 상대 시스템의 지연 증가 재시도로 인한 중복 요청 스펙 변경 부분 성공 상태 먼저 구분해야 할 것 1. 연결 실패... 2026/01/12 Book, 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식
대량 배치 안정성을 높이기 위한 구조 개선: Part 1 - 시스템을 압박하기 시작한 배치 Notes 1편. 대량 배치 작업이 시스템을 압박하기 시작했을 때 들어가며 서비스가 성장하면서 데이터는 자연스럽게 누적된다. 문제는 “언제부터 기존 구조가 한계에 도달했는지”를 시스템이 아니라 사람이 먼저 체감한다는 점이다. 이번 글에서는 실행 시점마다 수십만 건 이상의 데이터를 처리해야 하는 배치 작업이 어떻게 시스템 전체의 안정성을 위협하게 되었는지, ... 2026/01/03 Notes, Common
대량 배치 안정성을 높이기 위한 구조 개선: Part 2 - 전체 삭제 후 전체 등록 구조의 위험성 Notes 2편. 전체 삭제 → 전체 등록 구조의 위험성 들어가며 1편에서 살펴본 것처럼, 대량 데이터를 처리하는 배치 작업은 어느 순간부터 “느리다”는 문제를 넘어 “위험하다”는 영역으로 들어섰다. 이번 글에서는 그 원인이 되었던 “전체 삭제 → 전체 등록” 구조가 왜 대규모 환경에서 치명적인 선택이 되는지, 그리고 어떤 관점으로 개선 목표를 설정했는지를... 2026/01/03 Notes, Common
대량 배치 안정성을 높이기 위한 구조 개선: Part 3 - 청크 분할과 병렬 처리로 재설계하기 Notes 3편. 청크 분할과 병렬 처리로 배치 구조 재설계하기 들어가며 앞선 두 편에서 문제를 정리했다면, 이번 글부터는 “그래서 어떻게 바꿨는가”에 대한 이야기다. 개선의 출발점은 단순했다. 모든 데이터를 한 번에 처리하지 않는다. 이 원칙을 실제 시스템 구조로 옮기는 과정에서 가장 먼저 손을 댄 것이 청크 분할과 병렬 처리였다. 전체를... 2026/01/03 Notes, Common
대량 배치 안정성을 높이기 위한 구조 개선: Part 4 - 분산 락이 있어도 레이스가 발생한 이유 Notes 4편. 분산 락이 있음에도 Race Condition이 발생한 이유 들어가며 청크 분할과 병렬 처리로 배치 성능은 크게 개선됐다. 처리 시간은 줄었고, 시스템 부하도 안정적으로 관리되기 시작했다. 하지만 예상하지 못한 문제가 남아 있었다. 락을 사용하고 있음에도, 작업 순서가 깨지고 있었다. 이번 글에서는 왜 분산 락이 존재했는데도 R... 2026/01/03 Notes, Common
대량 배치 안정성을 높이기 위한 구조 개선: Part 5 - 배타적 락과 조건부 해제로 순서를 보장하기 Notes 5편. 배타적 락과 조건부 해제로 순서를 보장하기 앞선 글에서 확인한 문제는 단순했다. 락을 쓰고 있었지만, 락의 생명주기와 실제 작업 생명주기가 일치하지 않았다. 결국 필요한 것은 “락이 존재하느냐”가 아니라 누가 락을 가졌는지, 그리고 그 락을 누가 해제할 수 있는지를 분명하게 만드는 구조였다. 왜 단순한 SET / DEL 패턴으로는 부족했나 ... 2026/01/03 Notes, Common
키 생성 병목을 추적해 구조를 바꾼 기록: Part 1 - INSERT가 느린 줄 알았다 Notes Part 1. INSERT가 느린 줄 알았다 – 2분짜리 배치의 착각 (기술 보강판) 성능 이슈를 처음 마주하면, 우리는 거의 본능적으로 같은 곳을 본다. INSERT. 그리고 대부분의 경우, 그 판단은 절반은 맞고 절반은 틀리다. 1. 문제 상황: “실패하지 않지만, 너무 느린 배치” 문제가 된 배치는 구조적으로 단순했다. 입... 2026/01/03 Notes, Common