2026년 6월 9일 Cucumber 시나리오 절반이 Skipped됩니다. 이 상태가 당신을 속이는 이유는 이렇습니다. Cucumber의 'skipped' 상태는 서로 완전히 다른 세 가지 문제를 숨깁니다. 어떤 것이 테스트 스위트를 갉아먹고 있는지 진단하고 멈추는 방법은 다음과 같습니다. deep-divescucumberbddtest-maintenance
2026년 6월 8일 Gherkin 스펙은 당신에게 거짓말을 하고 있다 Gherkin 스펙은 사람이 수동으로 업데이트하도록 맡기는 순간부터 동기화가 깨지기 시작한다. 여기서 feature 파일을 정직하게 유지하는 자동화 검증 방법을 소개한다. deep-divesgherkinbddliving-documentation
2026년 6월 7일 컴파일러가 문법을 검사한다면, 테스트는 아키텍처를 검사해야 한다. 대부분의 팀은 아키텍처 규칙을 위키에 문서화한다. 의존성 그래프가 어긋났을 때 CI를 실패시키는 실행 가능한 테스트로 작성하는 방법을 알아보자. deep-divesarchitecture-testingclean-architectureci-cd
2026년 6월 6일 도메인 계층이 Postgres를 임포트합니다. CI는 신경 쓰지 않습니다. 클린 아키텍처 다이어그램은 화이트보드 위에서 멋지게 보입니다. 빌드 파이프라인이 의존성 방향을 강제하여 도메인 코드가 인프라에 닿지 못하도록 만드는 방법을 소개합니다. deep-divesclean-architectureci-cddependency-rules
2026년 6월 5일 아키텍처 다이어그램은 이미 거짓말이다 아키텍처 문서는 저장하는 순간부터 썩기 시작한다. 코드로부터 다이어그램을 생성하고, ADR을 남기며, 자동화된 아키텍처 테스트로 문서를 정직하게 유지하는 방법을 알아본다. deep-divesarchitecturedocumentationliving-docs
2026년 6월 4일 재시도 루프는 첫 번째 요청이 실패했다고 가정합니다. 아마도 그렇지 않았을 겁니다. 타임아웃이나 크래시가 API 요청이 사라졌다는 뜻은 아닙니다. idempotency key가 재시도를 안전하게 만드는 방식, 그리고 실제로 중복을 방지하는 저장소 패턴을 소개합니다. deep-divesidempotencyapi-designresilience
2026년 6월 3일 프로세스보다 오래 사는 락: 분산 리스가 실제로 어떻게 동작하는지 서버를 재시작하면 인메모리 뮤텍스는 사라진다. 펜싱 토큰과 TTL을 갖춘 분산 리스가 크래시 이후 중복 작업을 어떻게 막는지, 그리고 여전히 물러서는 지점은 어디인지 설명한다. deep-divesdistributed-locksleasingresilience
2026년 6월 2일 goroutine도, timer도, background overhead도 없는 circuit breaker 대부분의 circuit breaker 라이브러리는 복구를 probe하기 위해 background thread를 생성한다. 그럴 필요 없다. 이 글에서는 correctness를 희생하지 않으면서 모든 background overhead를 제거하는 request-driven 설계를 소개한다. deep-divescircuit-breakerperformanceresilience
2026년 6월 1일 웹 서비스에 그레이스풀 셧다운 경로가 있다. 그게 버그다. 크래시 온리 소프트웨어는 모든 실패를 크래시로, 모든 시작을 복구로 취급한다. 웹 서비스에 적용하면, 셧다운 로직을 삭제하고 kill -9를 견디는 상태를 설계하는 것을 의미한다. deep-divescrash-only-softwareresiliencedistributed-systems
2026년 5월 31일 Mutant가 무엇을 바꿨는지 모를 때 Surviving Mutant를 죽이는 방법 Mutation testing이 survivor를 찾았는데, 그 mutation이 도대체 무엇을 하는지 전혀 모르겠다. Mutant를 먼저 이해하지 않고도 올바른 테스트를 작성하는 단계별 방법이다. deep-divesmutation-testingtest-writingdebugging
2026년 5월 30일 인증 코드는 90% mutation coverage가 필요합니다. 문자열 유틸리티는 아닙니다. 전체 코드베이스에 단일 mutation score를 강제하는 것이 왜 실수인지, 그리고 실제 리스크에 맞는 모듈별 임계값을 설정하는 방법. deep-divesmutation-testingauthtest-quality
2026년 5월 29일 테스트는 통과한다. mutation score는 40%다. surviving mutant가 실제로 말해주는 것 code coverage는 안전하다고 말한다. mutation testing은 테스트가 대부분 장식이라고 말한다. surviving mutant가 이 간극을 드러내는 방법과 그것을 메우는 방법을 알아보자. deep-divesmutation-testingsurviving-mutantstest-quality
2026년 5월 28일 Rust에서 뮤테이션 테스트는 통하지만, 컴파일 시간이 복수한다 cargo-mutants는 코드를 검증하는 척만 하는 테스트를 찾아낸다. Rust에서 뮤테이션 테스트가 어떻게 작동하는지, 무엇을 잡아내는지, 그리고 컴파일 시간 비용이 감당할 만한 가치가 있는지 알아본다. deep-divesmutation-testingrustcargo-mutantstest-quality
2026년 5월 27일 뮤테이션 테스트는 4시간이 걸린다. 팀은 실제로 CI에서 어떻게 사용할까? 대부분의 팀은 매 커밋마다 전체 뮤테이션 테스트 스위트를 실행하지 않는다. 엔지니어링 팀이 뮤테이션 테스트를 CI에 통합하면서도 빌드 파이프라인을 망가뜨리지 않는 실제 방법을 소개한다. deep-divesmutation-testingci-cdtest-quality
2026년 5월 26일 유닛 테스트는 통과하는데, 데이터는 여전히 사라진다 모의 데이터베이스 테스트는 SQL 문법은 검증하지만, 행이 크래시나 동시 쓰기, 스키마 불일치에서 살아남는지는 검증하지 않는다. 여기 지속성을 진짜로 테스트하는 방법이 있다. deep-divesdatabasetestingpersistence
2026년 5월 25일 모든 mock action에 매몰리지 않고 Redux 테스트하기 모든 Redux action을 mock하면 테스트가 변경 로그 검증기가 된다. 대신 실제 상태 전환으로 store를 테스트하는 방법. deep-divesreduxtestingstate-management
2026년 5월 24일 100번 테스트 실행은 거짓말이다: Property-Based Test를 실제로 사이징하는 법 Property-based testing의 기본값인 100개 예제는 통계 전략이 아닌 사회적 타협이다. 자신의 신뢰도 요구사항과 CI 예산에 맞는 실행 횟수를 선택하는 방법을 알아보자. deep-divesproperty-based-testingtest-coverageshrinking
2026년 5월 23일 Rust의 Property-Based Test가 당신의 Unit Test가 놓치는 버그를 찾아낸다 Example-based testing은 당신이 생각해낸 입력만 커버한다. Property-based testing은 무작위 데이터를 생성하고, invariant를 검증하며, 실패를 최소한의 counterexample로 축소한다. deep-divesrustproperty-based-testingquickcheckproptest
2026년 5월 22일 단위 테스트는 통과했지만, 프로덕션 코드는 여전히 망가져 있다. 코드 커버리지 지표는 허위 안전감을 조성한다. 단위 테스트가 실제로 잠을 설치게 하는 버그를 놓치는 이유, 그리고 대신 무엇을 테스트해야 하는지 알아보자. deep-divesunit-testingtest-qualitybug-prevention
2026년 5월 21일 Rust 런타임 contracts는 릴리스 빌드에서 오버헤드 없이 사용할 수 있지만, 컴파일러가 대신 해주지는 않는다 Rust는 디버그 assertions를 자동으로 제거하지만, 진정한 design-by-contract는 debug_assert! 이상의 것이 필요하다. 릴리스 바이너리에서 완전히 사라지는 zero-cost runtime contracts를 만드는 방법을 소개한다. deep-divesrustruntime-contractsperformance
2026년 5월 20일 0개, 1개, 아니면 12개: 프로덕션 함수에 실제로 필요한 assertion의 개수 개발자들은 assertion을 색종이처럼 뿌리거나 아예 사용하지 않는다. 유용한 invariant와 프로덕션 crash를 유발하는 요인을 구분하는 결정 프레임워크를 소개한다. deep-divesassertionsproduction-codedefensive-programming
2026년 5월 19일 검증 계층이 비즈니스 로직보다 더 커지는 경우 수동 검증은 codebase를 부풀리고 여전히 엣지 케이스를 놓친다. 선언적 스키마로 runtime contracts를 간섭 없이 강제하는 방법을 알아본다. deep-divesruntime-contractsvalidationdesign-by-contract
2026년 5월 18일 TypeScript strictNullChecks는 컴파일 타임 가드일 뿐, 런타임 방패가 아니다 strict mode는 내가 작성한 null만 잡아낼 뿐, API나 DOM 쿼리, JSON.parse를 통해 런타임에 유입되는 null은 잡지 못한다. 타입 시스템의 한계가 끝나는 지점과 진짜 방어가 시작되는 지점을 살펴 본다. deep-divestypescriptnull-safetystrict-mode
