요청과 데이터가 서버에서 어떻게 처리되는지 — 백엔드 기본기.
2026년 11월 13일
안녕하세요, 자바파커입니다. "GET은 조회, POST는 생성. 그리고 HTTPS 쓰면 둘 다 안전하다." 면접 준비할 때 이렇게 정리하셨다면, 하나가 빠져 있습니다. 로그인 폼을 GET으로 만들면, HTTPS를 써도 비밀번호가 서버 로그에 그대로 찍힙니다. 브라우저 주소창과 방문 기록에도 남습니다. 결론부터 말씀드리면, GET은 보낼 내용을 주소에 적고…
2026년 11월 7일
안녕하세요, 자바파커입니다. "TCP는 신뢰성 있고, UDP는 신뢰성 없다." 면접 준비하면서 다들 이렇게 외우셨을 겁니다. 그런데 이상하지 않으세요? 그렇게 좋은 TCP를 두고, 영상통화나 게임은 왜 UDP를 쓸까요? 다 도착하는 쪽이 더 좋은 거 아닌가요? 결론부터 말씀드리면 — TCP는 "전부, 순서대로"를 약속하고, 그 대가로 기다립니다. UDP는…
2026년 9월 4일
안녕하세요. 자바파커입니다. 분산 캐시에 서버가 세 대 있다고 가정해 보겠습니다. 가장 단순한 배치식은 다음과 같습니다. 이 방식은 빠르고 이해하기 쉽습니다. 하지만 네 번째 서버를 추가하는 순간 식이 로 바뀝니다. 같은 키의 해시값은 그대로인데 나누는 수가 달라져 기존 키 대부분의 목적지가 달라질 수 있습니다. 일관된 해싱의 목적은 데이터를 완벽히 균등…
2026년 9월 3일
안녕하세요. 자바파커입니다. 데이터가 수억 건 있는 저장소에 어떤 키가 존재하는지 확인해야 한다고 생각해 보겠습니다. 매 요청마다 DB나 디스크를 읽으면 정확하지만 비쌉니다. 그렇다고 모든 키를 메모리에 보관하면 메모리가 커집니다. 블룸 필터(Bloom Filter)는 이 문제에 독특한 답을 냅니다. 없다고 판정하면 확실히 없습니다. 있다고 판정하면 실제…
2026년 8월 28일
안녕하세요. 자바파커입니다. 결제 서버 하나가 느려졌습니다. 주문 서버는 친절하게 세 번 재시도했습니다. 잠시 뒤 주문·재고·알림 서버까지 모두 느려졌습니다. 실패를 줄이려던 재시도가 왜 전체 장애를 만들었을까요? 서킷 브레이커는 실패를 없애는 장치가 아닙니다. 실패가 다른 서비스로 번지는 것을 막는 장치입니다. 요청이 쌓이다 차단기가 열리고, 시험 요청…
2026년 8월 27일
안녕하세요. 자바파커입니다. 캐시 적중률이 99%인데 DB가 갑자기 멈췄습니다. 캐시를 더 많이 쓰고 있었는데 왜 장애가 났을까요? 원인은 인기 키 하나의 만료 시각이었습니다. 캐시가 없어서가 아니라, 모두가 같은 순간 캐시가 없다는 사실을 발견해서 터집니다. TTL이 이 되는 순간 요청이 DB로 폭발하고, 락 하나로 다시 한 줄이 되는 과정은 52초 영…
2026년 8월 26일
안녕하세요. 자바파커입니다. 서버가 세 대라서 요청도 세 대에 똑같이 나눴습니다. 그런데 잠시 뒤 1번 서버의 연결은 8개, 2번과 3번 서버는 각각 1개가 됐습니다. 요청 개수는 공평했는데 왜 부하는 공평하지 않을까요? 로드 밸런싱의 목표는 요청 개수를 똑같이 만드는 것이 아니라, 사용 가 능한 서버가 감당할 수 있도록 트래픽을 분배하는 것입니다. 요청이…
2026년 8월 25일
안녕하세요. 자바파커입니다. 초당 요청이 100건 들어오는데 서버는 20건밖에 처리하지 못한다고 해보겠습니다. 직접 호출이라면 20건은 처리되고 나머지는 타임아웃이나 오류가 됩니다. 그 사이에 메시지 큐를 넣으면 어떻게 될까요? 서버가 빨라지는 것은 아닙니다. 처리하지 못한 80건이 실패 대신 대기가 됩니다. 이것이 메시지 큐의 핵심입니다. 메시지 큐는 …