전체 글291

• 

  테스트 전략, @DataJpaTest와 Django TestCase는 같은 것을 검증하지 않는다 1편:[Framework/Django] - Spring Boot/NestJS 개발자가 바라본 Django의 설계 철학, AI 시대에 다시 묻다2편:[Framework/Django] - Spring Data JPA와 Django ORM, 같은 CRUD를 두 번 짜 보면 보이는 것3편:[Framework/Django] - Flyway와 Django migrations, 스키마 변경을 누가 결정하는가ORM 비교 글을 쓰면서 가장 자주 나온 질문은 "그래서 어느 쪽이 테스트하기 쉬운가"였습니다. 그런데 이 질문에는 전제 오류가 하나 있습니다. Spring의 @DataJpaTest와 Django의 TestCase는 같은 층위의 도구가 아닙니다. 하나는 컨텍스트의 일부만 띄우는 슬라이스 테스트이고, 다른 하나는 애.. Framework/Django 2026. 10. 20.

• 

  Flyway와 Django migrations, 스키마 변경을 누가 결정하는가 1편:[Framework/Django] - Spring Boot/NestJS 개발자가 바라본 Django의 설계 철학, AI 시대에 다시 묻다2편:[Framework/Django] - Spring Data JPA와 Django ORM, 같은 CRUD를 두 번 짜 보면 보이는 것 2편에서 "Django에서는 모델 수정이 곧 스키마 변경"이라고 적었습니다. 그 문장은 편리함에 대한 설명이었지만, 동시에 위험에 대한 예고이기도 했습니다. 실제로 배포 파이프라인에 들어가면 이 차이는 코드 스타일 문제가 아니라 누가 스키마의 진실(source of truth)을 쥐고 있는가라는 운영 문제로 바뀝니다.여기서 질문: "스키마 변경 이력은 개발자가 쓴 SQL이 기준인가, 모델 코드가 기준인가?"Spring 진영의 Fl.. Framework/Django 2026. 10. 20.

• 

  Spring Data JPA와 Django ORM, 같은 CRUD를 두 번 짜 보면 보이는 것 1편: [Framework/Django] - Spring Boot/NestJS 개발자가 바라본 Django의 설계 철학, AI 시대에 다시 묻다ORM을 바꾸면 코드가 짧아질 거라고 생각했습니다. 그런데 회원 테이블 하나를 Spring Data JPA와 Django ORM으로 각각 구현하고 나서 깨달은 것은, 실제로 달라진 것이 코드의 길이가 아니라 책임의 위치라는 점이었습니다. Repository 인터페이스가 사라진 자리, @Transactional과 dirty checking이 사라진 자리에는 빈 공간이 남은 게 아니라 다른 주체가 들어와 있었습니다.이 글의 질문: "Data Mapper와 Active Record는 어디서 갈라지고, 그 차이는 실무에서 어떤 비용으로 돌아오는가?"결론을 먼저 적으면, .. Framework/Django 2026. 10. 20.

• 

  Spring Boot/NestJS 개발자가 바라본 Django의 설계 철학, AI 시대에 다시 묻다 5년 넘게 Spring Boot와 NestJS(TypeScript)로 백엔드를 만들어 오면서, 나는 "좋은 아키텍처"라는 말을 떠올릴 때마다 언제나 같은 그림을 떠올렸습니다. 명시적인 의존성 주입(Dependency Injection), Controller-Service-Repository의 뚜렷한 격리, Data Mapper 패턴의 JPA와 TypeORM. 이 그림이 정답이라고 오랫동안 생각했습니다.그런데 Django(장고)와 DRF(Django REST Framework)를 학습하기 시작하면서 그 확신이 흔들렸습니다. Repository 인터페이스도, 별도의 DTO 계층도 없이 훨씬 적은 코드로 같은 결과를 내는 프레임워크가, 왜 20년째 현업에서 살아남았을까요?여기서 질문: "AI가 코드를 대신 짜.. Framework/Django 2026. 10. 20.

• 

  광고 클릭 집계 시스템 설계, 스트림 처리 파이프라인, 이벤트 시간 윈도우, Exactly-Once 개요광고를 한 번 클릭하면 어떤 일이 벌어지는가. 사용자에겐 0.3초짜리 페이지 이동이지만 시스템 뒤에서는 그 한 번의 클릭이 수십 개의 서비스를 지나고, 수십억 건의 다른 클릭과 합쳐져 실시간 집계된다. 광고주는 "오늘 우리 광고가 몇 번 클릭됐는지"를 5분 안에 알고 싶어 한다. 너무 늦으면 예산을 재조정할 타이밍을 놓친다. 그런데 이 한 번의 클릭을 중복 없이, 누락 없이, 초 단위로 집계하는 일은 생각보다 까다롭다. 한 이벤트가 Kafka로 들어가기 직전에 네트워크가 끊기면 어떻게 되는가. Flink가 집계하다가 죽으면 어디까지가 유효한가. Pinot이 응답하기 전에 새 클릭이 들어오면 어떻게 합치는가.Vol 2 Ch6(Ad Click Event Aggregation)는 스트림 처리의 정확도(En.. CS/시스템 설계 2026. 10. 15.

• 

  지표 모니터링 및 경보 시스템 설계 : Prometheus · Datadog, 시계열 데이터와 Gorilla 압축 가상면접 시스템 설계 시리즈 5편 (Vol 2 Ch5)개요서비스가 한 대였을 때는 SSH로 들어가 uptime을 치는 것만으로도 충분했다. 사용자가 몰리는 시간에 CPU가 얼마나 쓰이는지, 응답이 얼마나 걸리는지, 한눈에 보였다. 그런데 웹 서버가 10대, DB 복제본이 5대, 캐시 노드가 12대로 늘어나는 순간, "지금 뭐가 어떻게 돌고 있는지"를 묻는 질문 자체가 달라진다. 더 이상 단일 머신을 보는 게 아니라 수십 대에서 쏟아지는 숫자를 한 그래프에 합쳐야 한다. 그리고 그 숫자의 모양새가 일반 데이터와 다르다는 사실을 깨닫는다. 시간에 묶인 수치, 시계열(Time Series) 이다.19편은 운영 3요소인 로그·메트릭·자동화를 큰 그림에서 훑었다. 이번 글은 그중 메트릭 한 축만 깊게 파고든다. .. CS/시스템 설계 2026. 10. 14.

• 

  아파치 카프카와 주키퍼: 분산 시스템의 코디네이터에서 KRaft(내재화)로의 진화 가상면접 시스템 설계 시리즈 4.5편 (Vol 2 Ch4 보강편)0. 들어가며 — 분산 시스템의 까다로운 두 문제분산 시스템을 설계할 때 가장 마주하기 까다로운 문제는 "여러 노드가 정확히 동일한 상태를 바라보게 만드는 것(Consistency)"과 "네트워크 분할이나 장애 상황 속에서도 누가 리더인지 합의하는 것(Consensus)"입니다.아파치 카프카(Apache Kafka)는 초기 버전부터 클러스터의 메타데이터 관리, 브로커 상태 감지(Service Discovery), 컨트롤러 선출 등의 코디네이션(Coordination) 역할을 아파치 주키퍼(Apache ZooKeeper)에 전적으로 위임해 왔습니다. 하지만 최근 카프카는 주키퍼를 완전히 걷어내고 자체 메타데이터 관리 방식인 KRaft(Kafk.. CS/분산시스템 2026. 10. 14.

• 

  Distributed Message Queue 설계 : Kafka · RabbitMQ · RocketMQ 가상면접 시스템 설계 시리즈 4편 (Vol 2)개요알림 시스템에서 배운 교훈을 떠올려 보자. 푸시 서버가 APNs·FCM에 동기적으로 요청을 보내면 응답 지연이 우리 서버의 스레드와 DB 커넥션까지 잠식해 결제·로그인까지 무너진다(13편). 해법은 메시지 큐를 사이에 두고 비동기로 분리하는 것이었다. 알림 서버는 큐에 이벤트를 던져놓고 돌아서고, 워커가 큐에서 꺼내 서드 파티로 보낸다. 이 한 번의 분리가 시스템 전체를 캐스케이딩 실패에서 구한다.Vol 1 Ch10(알림)에서 "왜 메시지 큐로 비동기 분리하는가"의 원칙을 배웠다. Vol 2 Ch4는 그 다음 질문인 "어떤 메시지 큐를 쓰는가" 의 깊이로 들어간다. Apache Kafka, RabbitMQ, RocketMQ, 그리고 클라우드 관리형인 AW.. CS/시스템 설계 2026. 10. 14.

• 

  채팅 시스템 설계, 수백만 개의 열린 연결을 버티는 법 가상면접 사례로 배우는 시스템 설계 시리즈 15편개요REST API 설계에 자신감이 붙은 백엔드 3~5년 차 엔지니어라면 이런 순간을 만난다. 면접관이 말한다. "카카오톡 같은 채팅 시스템을 설계해 보세요. 동시 접속 수백만 명." 평소에는 무상태(Stateless) 세계에서 살던 엔지니어는 여기서 당황한다. 무상태를 버리는 게 미덕이던 환경에서, 갑자기 수백만 개의 TCP 커넥션을 메모리에 꽉 쥐고 절대 놓지 않는 상태 유지의 늪으로 들어가야 하기 때문이다.채팅의 본질을 한 문장으로 말하면 이렇다. 상대방이 메시지를 보냈을 때, 그 메시지는 서버가 먼저 말을 걸어서 내 화면에 떠야 한다. 그런데 HTTP는 태생적으로 클라이언트가 먼저 입을 열어야만 응답할 수 있는 단방향 프로토콜이다. 이 모순을 어떻게.. CS/시스템 설계 2026. 10. 14.

• 

  뉴스피드 시스템 설계, 0.1초의 화면 뒤에 숨은 팬아웃 전쟁 가상면접 사례로 배우는 시스템 설계 시리즈 14편개요출근길 지하철에서 피드를 새로 고침한다. 로딩 아이콘이 휙 돌더니, 정확히 0.1초 만에 친구들의 글이 쏟아진다. 우리는 이 0.1초를 전등 스위치처럼 당연하게 여긴다. 하지만 그 짧은 찰나에 서버 몇 만 대가 움직이고, 수백만 건의 데이터 조각이 해체됐다가 다시 조립된다. 그리고 무엇보다, "지금 이 순간 친구 5,000명 중 누가 무슨 글을 썼는지"를 알아내는 탐색이 일어난다.뉴스피드는 겉보기엔 "최신 글을 시간순으로 보여주는 목록"이다. 그런데 그 단순한 기능 뒤에 이런 질문이 숨어 있다. 한 명이 글을 쓰면 그 글이 어떻게 수천 명의 화면에 동시에 닿는가? 이 문제가 바로 이 장의 주인공, 팬아웃(Fan-out)이다. 이 글은 읽기/쓰기 비대칭에.. CS/시스템 설계 2026. 10. 14.

• 

  한 서버의 메모리로는 부족하다, 분산 키-값 저장소(Key-Value Store) 설계 가상면접 사례로 배우는 시스템 설계 시리즈 09편개요키-값 저장소(Key-Value Store)는 단순해 보인다. 사전 하나면 되는 것을 왜 수십 대의 서버로 쪼개서 만들까. 답은 물리적 한계에 있다. 단일 서버의 메모리, 디스크, 네트워크 대역폭은 전부 유한하다. 사용자 수가 늘면 메모리에 전부 올리던 것도 디스크로 흘러내리고, 디스크도 차면 이제 진짜 문제가 시작된다.이 글은 Amazon Dynamo 스타일의 분산 키-값 저장소를 설계한다. CAP 이론에서 출발해 쿼럼(Quorum)과 벡터 클락(Vector Clock)으로 일관성을 타협하고, 안정 해시로 데이터를 분산·다중화하고, 가십 프로토콜과 머클 트리(Merkle Tree)로 장애를 감지·복구하고, LSM-Tree와 B-Tree 사이에서 저장 .. CS/시스템 설계 2026. 10. 14.

• 

  서버 한 대를 추가했더니 캐시가 통째로 사라졌다, 안정 해시(Consistent Hashing) 설계 가상면접 사례로 배우는 시스템 설계 시리즈 08편개요캐시 서버가 4대로 운영 중이라고 상상해 보자. 어느 날 트래픽이 늘어 서버를 1대 추가했다. 그런데 갑자기 캐시 적중률이 바닥으로 떨어지고, DB에 읽기 요청이 수십 배로 몰리기 시작한다. 서버를 늘렸는데 왜 시스템은 더 느려지는 걸까.원인은 hash(key) % N 이다. 이 글은 왜 나머지 연산(Modulo)이 서버 증감 앞에서 붕괴하는지, 그리고 이를 해결하는 안정 해시(Consistent Hashing)가 어떤 원리로 "재배치를 최소화"하는지를 설계 관점에서 설명한다.1. hash(key) % N의 함정 — 재배치 폭풍캐시 서버가 4대 있다고 하자. 특정 키가 어느 서버에 저장될지는 보통 이렇게 결정한다.server_index = hash(ke.. CS/시스템 설계 2026. 10. 14.