전체 글278

• 

  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.

• 

  Java 개발자라면 알아야 할 JVM의 모든 것: 클래스 로더부터 실행 엔진까지 Java의 탄생 배경Java는 1991년 썬 마이크로시스템즈(이하 썬)의 제임스 고슬링과 아서 밴 호프를 주축으로 한 엔지니어들이 플랫폼으로부터 독립적으로 실행 가능하도록 개발한 언어입니다. 참고로 여기서 플랫폼이란 운영체제와 CPU 아키텍처를 말합니다. 대표적으로 Windows, Linux, Mac 그리고 x86과 핸드폰에 주로 쓰이는 arm이 있습니다. 90년대 초는 C와 C++의 사용률이 높았던 시절입니다. 썬의 개발자들이 당시 핫했던 C나 C++를 사용하지 않은 이유는 무엇일까요? 객체지향 프로그래밍은 C++로도 가능했지만, C++는 플랫폼에 따라 컴파일러에 차이가 있어 플랫폼 간 실행파일의 호환성이 보장되지 않았습니다. 이는 인터넷의 발전으로 다양한 환경에서 실행될 가능성이 높아진 프로그램들을 .. Language/Java & Kotlin 2026. 7. 17.

• 

  배포 후 첫 5분이 느린 이유: JVM 워밍업 없이 트래픽을 받으면 안 되는 이유 들어가며: 이 글은 어떤 질문에서 시작됐나Spring 서버를 배포하고 로드밸런서에 붙인 지 1분이 채 안 돼 모니터링을 보면, 같은 API 요청의 응답 시간이 200ms에서 50ms로 뚝 떨어진다. 처음엔 캐시 워밍업이라고 생각했는데, 알고 보니 JIT 컴파일러 때문이었다.이 글은 "JIT가 뭐죠?" 하는 면접 답변 수준을 넘어서, 실무에서 서버 성능을 직접 다루는 엔지니어가 알아야 할 JIT의 원리를 다룬다. 특히 다음 질문들에 답한다:왜 처음엔 느리고 계속 실행하면 빨라지나?C1, C2 컴파일러는 뭐가 다른가?배포 직후 응답 지연을 어떻게 피할까?문제 상황: 실무에서는 어디서 헷갈리나상황 1: 배포 후 초기 응답 지연서버를 Kubernetes로 무중단 배포하는 상황을 생각해보자.시간 API 응.. Language/Java & Kotlin 2026. 7. 17.

• 

  [MySQL] 인덱스 심화 2 — ORDER BY가 인덱스를 타는 조건, 암시적 형변환, 인덱스 없는 UPDATE의 락 확산 1. 문서 제목MySQL 인덱스 심화 2 — ORDER BY가 인덱스를 타는 조건, 암시적 형변환, 인덱스 없는 UPDATE의 락 확산2. 기술 개요 요약인덱스의 기본 구조(B+Tree, 클러스터드/세컨더리, 복합 인덱스 컬럼 순서)를 이해한 다음 단계는 경계 사례다. "인덱스가 있는데도 안 타는 쿼리"와 반대로 "안 탈 것 같은데 타는 쿼리"를 정확히 가르는 기준, 그리고 인덱스가 조회 성능을 넘어 UPDATE의 락 범위까지 좌우한다는 사실이 이 문서의 주제다. 판단 기준은 두 가지로 압축된다: ① 인덱스는 "저장된 정렬"이므로, 그 정렬을 그대로 활용할 수 있는 형태의 조건/정렬만 인덱스를 탄다 ② 가공되는 쪽이 컬럼이면 못 타고, 비교값이면 탄다.다루는 질문:#질문핵심 키워드1복합 인덱스 (a,b,.. DB/MySQL 2026. 7. 12.

• 

  [Kafka] 핵심 원리 정리 — 처리량이 높은 이유, acks, 오토커밋 유실·중복, 리밸런싱 1. 문서 제목Kafka 핵심 원리 정리 — 처리량의 진짜 이유, acks, 오토커밋 유실·중복, 리밸런싱까지2. 기술 개요 요약Kafka를 학습하다 보면 "파티션으로 병렬 처리한다"는 표면 지식까지는 금방 도달하지만, 한 겹 아래의 질문들 — 브로커 한 대는 왜 빠른가, 프로듀서 단에서도 순서가 꼬일 수 있는가, 오토커밋은 유실을 내는가 중복을 내는가 — 에서 막히기 쉽다. 이 문서는 그 한 겹 아래에 해당하는 6개 질문을 정리한다. 관통하는 원칙은 하나다: Kafka 파티션의 존재 이유는 "병렬 처리"와 "순서 보장" 두 가지이고, 모든 설정(acks, max.in.flight, 오토커밋, 리밸런싱, 파티션 증설)은 이 두 축 + "유실 vs 중복" 트레이드오프 위에서 해석하면 답이 나온다.다루는 질.. 메세지 브로커/Kafka 2026. 7. 12.