Netty Notes Netty를 왜 배우는가 Netty는 Java에서 고성능 네트워크 서버와 클라이언트를 만들기 위한 프레임워크다. 단순히 “빠른 소켓 라이브러리”라기보다, NIO 기반 네트워크 프로그래밍의 복잡도를 줄여 주는 실행 모델과 파이프라인 추상화를 제공한다. 고성능 API 서버, 메시징 시스템, 게임 서버, RPC 프레임워크에서 자주 등장한다. 등장 배경... 2026/02/25 Notes, Web
2026-02-24-TIL: AI 활용에 대하여 TIL Today I Learned 오늘은 간만에 간단한 면접을 보았다. 이 면접을 통해 지금 내가 무엇을 공부하고 있고 어디를 향해 나아갈지 다시 한 번 생각해보는 계기가 되었다. 나는 지금 어떻게 공부하고 있고 어떻게 공부하는게 가장 효과적일까? 내가 지금 공부하는 방식은 대부분 ‘사고실험‘의 형태로 진행된다. 실무에서 경험했던 사례를 기억날때마다 구... 2026/02/24 TIL, 2026-TIL
주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 - 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