전체 글282

• 

  CAP을 넘어 PACELC로: 평상시 트레이드오프와 합의 알고리즘 CAP을 넘어 PACELC로: 평상시 트레이드오프와 합의 알고리즘이전 1편: 피터 도이치의 8가지 오류에서 분산 환경의 물리적 한계, 2편: CAP 이론에서 P 상황의 트레이드오프, 3편: 주문/결제 시스템에서 CP와 AP 선택하기에서 1·2차 방어선으로 풀어내는 실무 전략을 다뤘습니다.3편 §5의 도메인 매트릭스에서 우리는 "정합성이 절대적인 도메인에는 CP 기반 분산 락(ZooKeeper/etcd)"이라고 정리했습니다. 그 CP 락 안에서는 무슨 일이 일어나고 있을까요? 그리고 CAP 이론이 다루지 못한 "평상시 트레이드오프"는 어떻게 설명할까요? 이번 4편은 이 두 질문에 답합니다.Hook: 네트워크 장애가 안 나면 CAP은 끝인가요? — 평상시에도 시스템은 트레이드오프에 직면합니다. PACELC .. CS/분산시스템 2026. 10. 9.

• 

  주문/결제 시스템에서 CP와 AP 선택하기 (feat. 블랙프라이데이) 주문/결제 시스템에서 CP와 AP 선택하기 (feat. 블랙프라이데이)이전 1편: 피터 도이치의 8가지 오류에서 분산 환경의 모든 고통이 물리적 한계에서 시작된다는 사실을 확인했습니다. 2편: CAP 이론에서는 "P는 선택이 아니라 전제, C와 A 중 하나를 포기해야 한다"는 트레이드오프의 수학적 정의를 짚었습니다.이번 3편에서는 이 트레이드오프를 실제 이커머스 주문 시스템에 대입합니다. "완벽한 정합성(CP)만 고집하면 왜 서비스가 터지는가"부터, "어떻게 AP로 가되 사가 패턴과 멱등성으로 방어하는가"까지, 결제 도메인의 생존 전략을 짚습니다.Hook: 결제창이 3초 멈추면 매출이 증발한다 — 그래서 우리는 정합성을 한 박자 늦추기로 했다.1. 실무의 고민 — 왜 CP만 고집하면 서비스가 터질까?2편.. CS/분산시스템 2026. 10. 9.

• 

  빛과 전파의 한계에서 시작하는 분산 시스템: 피터 도이치의 8가지 오류와 현실 분산 시스템의 진짜 출발점: 피터 도이치의 8가지 오류단일 서버(Monolith) 환경에서 개발을 할 때는 모든 것이 평화롭습니다. 함수를 호출하면 결과가 즉시 돌아오고, 메모리에 올린 데이터는 안전하며, 디스크나 네트워크 I/O는 대개 순조롭게 흘러갑니다.하지만 서비스를 확장해 마이크로서비스 아키텍처(MSA)나 대규모 분산 시스템을 구축하는 순간, 이 '당연함'들은 전부 거대한 착각이었음을 깨닫게 됩니다. 도대체 왜 분산 환경은 우리를 괴롭히는 걸까요? 답을 찾으려면 추상화된 코드를 걷어내고, 데이터가 움직이는 물리적 세계로 내려가야 합니다.이 글은 분산 시스템 시리즈 1편입니다. 1편에서는 물리적 한계 → 개발자들이 무의식적으로 빠지는 8가지 착각 → 이 한계 위에서 살아남는 회복 탄력성 전략까지 다.. CS/분산시스템 2026. 10. 9.

• 

  CAP 이론, "P를 보장한다"는 것의 진짜 의미 서론분산 시스템을 배우기 시작하면 거의 100% 마주치는 공식이 있습니다. CAP."C, A, P 셋 중 두 개만 가질 수 있다."이 한 줄이 모든 것을 잘못 가르쳤습니다. 이 글에서는 그 잘못을 바로잡고, "P는 선택이 아니라 전제"라는 Brewer의 2012년 재해석까지 도달해 보겠습니다.1. 왜 다시 CAP인가? — 모든 것의 시작2000년 7월, 포르투갈에서 열린 ACM PODC 학회 키노트 무대에 UC 버클리의 에릭 브루어(Eric Brewer)가 섰습니다. 그는 Google과 Inktomi 같은 대규모 분산 검색 시스템을 직접 구축하면서 겪은 직관을 정리해 발표했는데, 그것이 후에 "CAP 이론"으로 불리게 되는 추측이었습니다.당시만 해도 분산 데이터베이스는 무조건 ACID(원자성·일관성·격리.. CS/분산시스템 2026. 10. 8.

• 

  to-do 앱 만들며 배우는 SDD + TDD 그리고 에이전틱 코딩에 필요한 이유 SDD + TDD가 에이전틱 코딩에 왜 필요한가 — to-do 앱 하나 완성하며 겪은 것들학습용 to-do 앱 하나를 Claude Code로 처음부터 끝까지(기획 → 설계 → 구현 → 배포 → 관측성까지) 만들었다. 다른 점이 하나 있었다면, 이번엔 코드부터 짜지 않고 SDD(Spec-Driven Development)와 TDD를 처음부터 강제했다는 것이다. 결과만 먼저 말하면: 전체 54커밋 중 버그 수정 커밋이 1개, 107개의 설계 결정 중 구현 착수 후 뒤집힌 게 0개, 테스트 388개가 전부 구현 전에 먼저 정의됐고, 여러 기능이 쌓인 뒤 처음 돌린 CI가 한 번에 통과했다.이 글은 그 과정에서 "왜 이게 일반적인 개발보다 에이전틱 코딩에서 더 중요한가"를 정리한 것이다.SDD와 TDD, 짧게S.. LLM/VibeCoding 2026. 9. 23.

• 사업 준비 중인 당신이 겪지 않았으면 하는 시행착오들 (2023/05) 사업 준비 중인 당신이 겪지 않았으면 하는 시행착오들근 2달 간 개발자 겸 대표 역할을 하며 겪은 시행착오들을 다른 분들은 경험하지 않았으면 하는 마음에서 글을 올립니다. 먼저, 저희 팀은 위티라는 간과 모임(주최자와 참여자로 구성된)을 크라우드 펀딩 형태로 이어주는 중개 플랫폼을 진행하려 했습니다. 간략하게 저를 소개하면, 저는 대학에선 "세상을 이해하고 싶어서" 경제학 공부를 했고, 졸업 후엔 "직접 변화를 만들고 싶어서" 스타트업에서 일해 왔습니다. 또 "유저들에게 새로운 가치를 제공할 수 있어서" 개발자를 택했고, 달리셔스와 페오펫이란 스타트업에서 풀스택 개발자로 일한 경험이 있습니다. 시작도 제대로 안해보고 접었기 때문에, 접었다고 표현하기에도 조금 우습지만 부디 다른 분들은 저와 같은 바보짓은.. 생각정리/회고 2026. 9. 8.

• 

  캐싱 설계 가이드: Cache-Aside, Write 전략, 캐시 붕괴(Stampede·Penetration·Avalanche) 방어 1. 문서 제목캐싱 설계 가이드: Cache-Aside, Write 전략, 캐시 붕괴(Stampede·Penetration·Avalanche) 방어2. 기술 개요캐시(Cache)는 자주 조회되지만 매번 다시 계산하거나 DB를 조회하기엔 비싼 데이터를, 더 빠른 저장소(메모리, Redis 등)에 사본으로 미리 준비해두는 것이다. 목적은 단순하다. 응답 속도를 올리고 원본 저장소(DB)의 부하를 줄이는 것.문제는 캐시를 쓰는 순간 "진짜 데이터(DB)"와 "사본(캐시)" 두 벌이 생긴다는 점이다. 원본이 바뀌었는데 사본이 안 바뀌면 사용자는 낡은 값을 보게 된다. 그래서 캐싱 설계는 사실상 아래 두 질문으로 귀결된다.읽을 때, 캐시에 없으면 누가 채우는가? (읽기 전략)원본이 바뀌었을 때, 캐시를 어떻게 처.. DB 2026. 9. 1.

• 

  질문으로 정리하는 Redis: 동작 원리부터 캐시·클러스터·분산락까지 서론위 글은 최근 읽었던 개발자를 위한 Redis란 책을 요약 겸 복습하기 위해 정리한 글입니다. 핵심요약1. Redis란 무엇이고 어떤 원리로 동작할까?Redis란 무엇이며, 왜 사용하는가?Redis는 어떤 데이터 구조를 지원하는가?Redis의 주요 사용 사례는 무엇인가?2. Redis는 NoSQL인가? 그렇다면 어떤 데이터 구조를 제공하는가?String, List, Set, Sorted Set, Hash 등의 데이터 타입별 특징과 사용 예시는?Bitmaps, HyperLogLog, Streams 등 고급 데이터 타입은 언제 사용하면 좋은가?TTL(Time to Live) 및 Expire 기능을 어떻게 활용할 수 있는가?3. Redis를 캐시, 세션스토어, 메세지 브로커로 쓸 때 알아야 할 것들캐시(C.. DB/Redis 2026. 9. 1.

• 

  Redis 분산락 통합 정리 : SET NX 한계부터 RLock·RedLock·Fencing Token·멱등성까지 1. 문서 제목Redis 분산락 통합 정리 : SET NX 한계부터 RLock·RedLock·Fencing Token·멱등성까지2. 기술 개요 요약여러 서버(프로세스)가 같은 자원을 동시에 건드리면 데이터가 꼬인다. "지금 이 자원은 내가 쓰고 있다"는 표시를 공유 저장소(Redis 등)에 남기고 다른 프로세스는 그 표시가 사라질 때까지 기다리게 만드는 장치가 분산락(Distributed Lock)이다. 주로 두가지 경우에 쓰인다. 외부 서비스를 포함하여, 이종의 DB의 락을 통합적으로 관리해야 하는 경우, 서버가 여러 대로 늘어나는 순간(스케일아웃) 언어 레벨 락만으로는 부족한 경우에 필요해진다.Redis로 만드는 가장 단순한 분산락은 SET key value NX EX ttl 명령 하나다. 구현이 간.. DB/Redis 2026. 9. 1.

• 

  Spring AOP 완벽 이해하기 AOP 구현 방식 2가지Spring은 AOP(관심사 분리 — 로깅·트랜잭션·보안 등 부가기능을 핵심 로직과 분리)를 프록시 객체로 구현한다. 대상 빈을 감싸는 프록시를 런타임에 생성하는 방법이 두 가지다.1) JDK Dynamic Proxy조건: 인터페이스가 반드시 있어야 함원리: java.lang.reflect.Proxy + InvocationHandler로, 인터페이스를 구현하는 프록시 클래스를 런타임에 생성한계: 인터페이스에 선언된 메서드만 프록시 가능 (구현체의 인터페이스 외 메서드는 프록시 안 됨)성능: 생성되는 바이트코드가 단순해서 CGLIB보다 빠름2) CGLIB조건: 인터페이스 불필요 — 구체 클래스를 상속해서 프록시 생성원리: ASM 바이트코드 조작 라이브러리로 대상 클래스의 서브클래스를.. Framework/Spring 2026. 7. 30.

• 

  Java 개발자라면 반드시 알아야 할 GC의 동작 원리와 실무에서의 성능 영향 들어가며: "왜 Spring Batch 테스트가 OOM으로 터졌을까?"어느 날 Spring Batch 통합 테스트를 돌리다 갑자기 빌드가 java.lang.OutOfMemoryError: Java heap space로 실패했다.메모리 누수도 없고, 데이터도 적은데 왜 떨어지는 걸까. 며칠간 삽질한 끝에 알게 된 사실은 충격적이었다. Context 캐싱 한계로 Spring TestContext Framework가 새로운 Application Context를 계속 생성했고, GC가 충분히 빠르지 못해 메모리가 쌓여가고 있었던 것이다.그때 느낀 것이다.GC를 모르면, Java 개발자는 왜 느린지, 왜 터지는지 원인을 절대 알 수 없다.이 글에서는 GC의 동작 원리를 실제 운영 관점에서 설명하고, OOM 같은 .. Language/Java & Kotlin 2026. 7. 17.

• 

  Spring Batch 프로젝트 테스트코드 최적화 방안 배경12월 4일 이후, Spring Batch 프로젝트의 테스트코드 양이 증가하며, OOM 문제로 인해, 테스트가 50분이 넘도록 돌아가지 않고 실패했습니다. 불과 100개도 안되는 테스트 였음에도 말이죠!! 무언가 이상했습니다. webapp은 300개가 넘는 테스트가 돌고 있음에도, 동일한 Heap Memory 스펙 하에서, 더 빠른 시간 안에 처리가 됐기 때문입니다.뿐 만 아니라, 테스트가 중간에 끝났음에도 Heap Memory Size는 줄어들지 않고 있었습니다. 이로써, Batch 쪽 테스트코드 로직에 문제가 있음을 직감할 수 있었습니다.문제해결과정테스트를 실행할 때, 갑작스럽게 OutOfMemoryError가 발생했을 때, 어딘가 메모리 누수가 발생되고 있다고 판단했습니다. 따라서 기존에 작성된.. 생각정리 2026. 7. 17.