Topic
테스트와 품질
시간이 지나도 의도를 지키는 테스트, 리팩터링, 정적 분석과 품질 실천을 다룹니다.
AI 변경을 동료가 리뷰할 수 있는 PR로 쪼개기
AI가 만든 코드도 작업자가 책임질 수 있도록 범위를 줄이고, 커밋과 PR을 동료가 이해하고 검토할 수 있는 단위로 나눕니다.
신뢰와 작은 성공으로 개발 문화를 바꾸는 법
새 조직을 먼저 이해하고 일로 신뢰를 얻은 뒤, 테스트와 정책 공유의 작은 성과를 보여 개발 문화를 확산합니다.
어댑터·듀얼 라이트·플래그로 Oracle을 MySQL로 이관하기
호환 어댑터, 사전 배포, 듀얼 라이트, 검증된 스위치와 롤백으로 Oracle 레거시를 MySQL로 점진 이관합니다.
긴 레거시 개편을 작은 배포로 나누는 법
지치는 레거시 개편을 작은 개발·검증·배포로 나눠 빠르게 피드백을 얻고 완벽주의의 함정을 피하는 방법입니다.
QA 전달 전에 개발자가 먼저 검증해야 하는 이유
QA 전달 전 개발자가 정상 동작을 검증해 반복 수정 비용을 줄이고 QA가 경계 조건과 제품 품질에 집중하도록 만드는 방법입니다.
동작하는 스파게티 코드를 특성 테스트로 리팩터링하기
넓은 API 특성 테스트로 레거시 동작을 고정하고 안전망 안에서 리팩터링한 뒤 작은 가역적 변경으로 배포하는 전략을 설명합니다.
바이브 코딩 시대에도 개발자 판단력이 필요한 이유
AI 코딩을 활용하면서도 문제 정의, 코드 검토, 품질 기준과 결과를 검증할 기술 지식을 지키는 방법을 다룹니다.
시니어 개발자가 다음 개발자에게 남겨야 할 유산
연차가 아니라 유지보수 가능한 코드, 테스트, 가이드와 팀의 지속가능성으로 시니어의 책임을 살펴봅니다.
모든 조회를 삼키는 만능 메서드를 목적별로 쪼개라
만능 동적 조회를 목적별 메서드로 나누고 호출부를 점진적으로 옮겨, 리팩터링의 사이드 이펙트를 줄입니다.
레거시 개선은 죽은 코드를 안전하게 지우는 데서 시작한다
런타임 증거, 데이터 확인, API 소비자 검증을 결합해 죽은 코드를 점진적으로 삭제하고 레거시를 줄입니다.
빅뱅 대신 작은 배포로 완성하는 레거시 개편
검증 가능한 작은 배포와 롤백 경계로 개편 위험을 낮추고, 프로젝트가 멈춰도 남는 가치와 진척을 만듭니다.
아키텍처 규칙 자동화보다 팀의 판단이 먼저다
레이어 규칙 자동화를 리뷰 여력, 저장소 규모, 개발자 성장, 팀의 아키텍처 토론과 함께 판단합니다.
스웨거와 REST Docs, API 문서화 도구를 상황별로 고르는 법
테스트 강제, 코드 침투성, 문서 확장성, 레거시 API의 점진적 전환 기준으로 두 도구를 비교합니다.
공통 모듈의 함정: 구체적인 기능으로 코드를 응집하라
소유권이 드러날 때까지 공통 모듈을 늦추고, 로깅·예외·공유 규격을 구체적인 기능과 책임 중심으로 묶는 방법을 다룬다.
거대한 서비스 클래스를 책임 단위로 나누는 법
개념 지도, 책임의 흐름, 테스트 경계, 구체적인 리팩터링 대안을 통해 비대해진 서비스 클래스를 나누는 방법을 설명한다.
코어를 깨끗하게 지키는 의도적인 오염 경계
피할 수 없는 복잡성을 명시적인 외부 경계에 가두고, 제한된 개발 시간을 시스템의 핵심 개념에 쓰는 방법을 다룬다.
사람이 이해하고 빌드가 지키는 레이어 규칙
안정적인 레이어 역할과 선택적 상위 레이어의 조건을 정의하고, 필요할 때만 자동 검증으로 규칙을 강제하는 방법을 다룬다.
Reader, Finder, Searcher를 행위로 구분하는 법
Reader, Finder, Searcher를 조회 건수가 아니라 직접 읽기, 추가 필터링, 복합 검색이라는 행위로 구분하는 기준을 설명한다.
추상화는 구현 뒤에 온다: Service와 Impl 관행 다시 보기
구체적인 구현에서 검증된 공통점을 추출하고, 구현체가 하나여도 실제 경계를 만드는 인터페이스만 남기는 설계 기준을 다룬다.
불필요한 조회 없이 권한 검증을 설계하는 법
로그인 사용자를 한 번만 확인하고 접근 검증의 책임을 좁히며, 시스템 관리자와 채널 단위 권한을 구분하는 설계.
테스트 편의 때문에 운영 코드의 의미를 바꾸지 마라
운영 행위가 더 명확해지거나 레거시에 테스트 경계가 필요할 때만 코드를 바꾸고, 테스트만 쓰는 값과 메서드를 억지로 노출하지 않는 기준입니다.
첫 테스트는 서툴러도 된다, 나중에 리팩터링하라
지키고 싶은 행위를 검증하는 테스트부터 만들고, 실행에 필요한 만큼 목을 쓰며, 반복과 리뷰를 통해 테스트 설계를 개선하는 방법입니다.
실제 트래픽 모양에서 성능 테스트를 설계하라
부하 도구를 고르기 전에 트래픽 규모와 유입 모양을 추정하고, 여유를 정하며, 실제 위험이 있는 기능에만 검증 근거를 요구하는 방법입니다.
공유 테스트 DB 없이 신뢰할 수 있는 데이터베이스 테스트 만들기
잡아야 할 실패에 따라 목, 인메모리 DB, Testcontainers, 실제 DB를 고르고 일반 테스트는 공유 인프라에서 격리합니다.
만든 개발자가 떠나도 살아남는 소프트웨어
좋은 회사 소프트웨어는 부채를 줄이고 팀의 운영 능력에 맞으며, 처음 만든 개발자가 떠난 뒤에도 이해하고 고칠 수 있어야 합니다.
단위 테스트는 비즈니스 의도를 지켜야 한다
비즈니스 레이어 단위 테스트는 설계를 돕고, 중요한 동작을 기록하며, 다음 개발자가 위험한 변경 앞에서 한 번 더 생각하게 할 때 의미가 있습니다.
리더와 라이터 컴포넌트로 비즈니스 흐름 드러내기
리더와 라이터는 저장소 세부사항과 변경 범위를 감추고 비즈니스 계층에 정책을 남깁니다. 다만 서비스 수명이 그 비용을 정당화해야 합니다.
거대한 서비스 클래스를 책임과 계층으로 분리하는 법
생성자 의존성과 import로 비대해진 서비스를 진단하고, 새로운 아키텍처 이름을 붙이기 전에 응집된 책임부터 분리합니다.