Refactoring on philipjkim

번역글: AI와 함께 더 빨리 실패하기

Wed, 08 Apr 2026 14:39:54 +0900

이 글은 Claude Opus 4.6 을 이용해 번역되었으며, 이후 퇴고를 거쳤습니다.

원문: Dave Thomas, Pragmatic Programmers Newsletter — “Failing Faster With AI”

“모든 거대한 컴퓨팅 재앙은 너무 많은 아이디어를 한곳에 집어넣으려다 생겨났습니다.”

— Gordon Bell

지난 8년쯤 개인 프로젝트를 하나 진행해 왔습니다. 1970년대 중반의 오래된 PIC 언어를 구현하는 것으로 시작했습니다. 셀 수 없이 많은 반복을 거쳤는데, 순수한 PIC 언어로 출발해서 오늘날에는 프로토타입 기반 스크립팅 언어와 애니메이션 기능을 내장한 형태가 되었습니다.

WELC ver. 2026 Part 5: 의존성 깨기 기법 카탈로그

Wed, 04 Mar 2026 10:03:52 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

도입

원서 Chapter 25는 25가지 의존성 깨기(Dependency-Breaking) 기법을 카탈로그 형태로 제시합니다. 각 기법은 “테스트 하네스에 코드를 넣기 위해 의존성을 어떻게 끊을 것인가"라는 질문에 대한 구체적인 답입니다.

다만 일부 기법은 C/C++ 전용이거나, 현대 Java에서는 불필요합니다. Link Substitution, Text Redefinition, Replace Function with Function Pointer 같은 기법이 대표적입니다. 이 파트에서는 2026년 현재 Java 개발에서 특히 유용한 핵심 기법들을 선별하여 정리합니다.

WELC ver. 2026 Part 4: 대규모 코드 문제 다루기

Wed, 04 Mar 2026 10:03:51 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

도입

레거시 시스템에서 가장 자주 마주치는 문제는 규모의 문제입니다. 한 클래스가 수천 줄, 한 메서드가 수백 줄인 코드는 현업에서 흔히 발견됩니다. 이런 코드는 읽기 어렵고, 테스트하기 어렵고, 변경하면 예상치 못한 곳에서 장애가 발생합니다.

이번 글에서는 Michael Feathers의 Working Effectively with Legacy Code 14~22장을 바탕으로, 대규모 코드 문제를 다루는 전략을 JDK 25 기준의 modern Java 코드로 살펴봅니다. SOLID 원칙 중 SRP, ISP, OCP의 실전 적용이 핵심입니다.

WELC ver. 2026 Part 3: 테스트 하네스에 코드 넣기

Wed, 04 Mar 2026 10:03:50 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

도입

레거시 코드를 변경하려면 먼저 테스트를 작성해야 합니다. 하지만 테스트를 작성하려면 코드의 의존성을 깨야 합니다. 의존성을 깨려면 코드를 변경해야 하는데, 변경의 안전성을 보장해줄 테스트가 아직 없습니다.

이것이 Feathers가 말하는 “레거시 코드의 딜레마"입니다.

In legacy code, the weights work against us. We have to pull out a piece to work with because we can’t easily test it in place. — Michael Feathers, Working Effectively with Legacy Code (2004)

WELC ver. 2026 Part 2: 안전한 코드 변경 패턴 — Sprout와 Wrap

Wed, 04 Mar 2026 10:03:49 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

도입

Part 1에서 다룬 Legacy Code Change Algorithm의 5단계 중, 이번 글은 “변경 및 리팩터링” 단계에 해당하는 실전 패턴들을 다룹니다. Michael Feathers의 Working Effectively with Legacy Code 6~8장에 등장하는 핵심 기법입니다.

레거시 코드에 기능을 추가해야 하는데 시간이 없을 때, 기존 코드를 전면 리팩터링하는 것은 현실적이지 않습니다. 이때 사용할 수 있는 4가지 패턴이 있습니다.

패턴	핵심 아이디어
Sprout Method	새 기능을 별도 메서드로 추출
Sprout Class	새 기능을 별도 클래스로 분리
Wrap Method	기존 메서드를 감싸서 전후 동작 추가
Wrap Class	Decorator 패턴으로 기존 클래스를 감싸기

이 4가지 패턴의 공통점은 기존 코드를 가능한 한 건드리지 않으면서 새 기능을 추가한다는 것입니다.

WELC ver. 2026 Part 1: 레거시 코드의 정의와 변경의 역학

Wed, 04 Mar 2026 10:03:48 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

시리즈 소개

2004년 Michael Feathers가 출판한 Working Effectively with Legacy Code (a.k.a. WELC)는 레거시 코드를 안전하게 변경하는 기법들을 체계적으로 정리한 명저입니다. 출판된 지 20년이 넘었지만, 이 책이 제시하는 원칙과 알고리즘은 여전히 유효합니다. 코드베이스가 노후화되는 속도보다 개발자가 이 책을 읽는 속도가 느린 것이 문제일 뿐입니다.

원서의 예제는 Java 1.4/5, C++, C 시대의 코드입니다. 이 시리즈에서는 JDK 25 (2025년 9월 GA, LTS) 기준의 modern Java로 핵심 기법들을 재현합니다. Sealed class, record, text block, pattern matching 등 최신 언어 기능을 적극 활용하여, 원서의 기법이 오늘날 어떤 형태로 적용되는지 보여드리겠습니다.

개발 팁: 읽기 쉽고 확장 가능한 if 구문 리팩토링 가이드

Fri, 05 Sep 2025 13:02:51 +0900

프로그래밍에서 if 를 사용하는 조건부 로직을 대체할 수 있는 방법들에 대해 gemini 2.5 pro 에게 요청한 연구 결과입니다.
모든 예제 코드는 Go 로 작성되었으나, 다른 프로그래밍 언어에 공통적으로 적용할 수 있는 내용들입니다.

서론: 조건문의 확산과 기술 부채의 축적

소프트웨어 개발에서 if-else 문은 제어 흐름을 구성하는 가장 기본적인 도구 중 하나입니다. 그러나 이 근본적인 구조는 종종 오용되어, 시간이 지남에 따라 시스템의 건강을 심각하게 해치는 주범이 되기도 합니다. 복잡하게 중첩되거나 끝없이 이어지는 if-else 체인은 가독성을 저해하고 유지보수를 악몽으로 만들며, 이는 소프트웨어 공학에서 “코드 스멜(code smell)“이라 불리는 명백한 위험 신호입니다. [1, 2, 3]

TotT: 인터페이스 테스트하기

Mon, 21 Jul 2025 10:01:35 +0900

원문: https://testing.googleblog.com/2008/07/tott-testing-against-interfaces.html (Translated by Google Gemini)

부족함에 대한 지속적인 느낌을 억누르기 위해, 당신은 공학 분야의 진정한 통과 의례인 자신만의 행성 파괴 광선총을 만드는 데 시간을 들였습니다. 축하합니다. 그리고 당신은 매우 자랑스러워했지만, 그 다음 주말에 이워크¹ 해설이 포함된 한정판 스타워즈 3부작을 구매하여 데스스타²가 알데라안³을 파괴하는 것을 보고 잘못된 결정을 내렸다는 것을 깨달았습니다. 당신의 행성 파괴 광선총은 파란색 레이저를 가지고 있지만, 녹색 레이저가 훨씬 더 멋있어 보입니다. 하지만 라디오셱⁴에 가서 기존의 파괴 광선총에 끼울 수 있는 녹색 레이저를 사는 것은 간단한 문제가 아닙니다. 녹색 레이저를 가지려면 처음부터 다른 행성 파괴 광선총을 만들어야 할 것입니다. 두 개의 파괴 광선총을 소유하는 것이 하나보다 이웃들의 질투심을 더 자극할 것이므로 당신에게는 괜찮습니다.

TotT: "Static Cling" 퇴치하기

Thu, 17 Jul 2025 17:03:43 +0900

원문: https://testing.googleblog.com/2008/06/defeat-static-cling.html (Translated by Google Gemini)

당신은 페어 프로그래밍을 하고 있고, 많은 뛰어난 사람들이 그렇듯이 소리 내어 말하고 있습니다. “목을 만들고, 주입하고, 테스트를 다시 실행할 거야. 통과해야 하는데… 젠장!” 당신의 파트너는 예외 "ConnectionFactory not initialized"를 발견합니다. “뭐?” 그녀는 말합니다. “뭔가가 데이터베이스를 사용하고 있어? 젠장, 이건 작은 테스트여야 했는데.”

검사해보니 당신의 클래스가 다른 클래스의 정적 메서드를 호출하고 있다는 것을 발견했습니다. Static Cling¹이 발생한 것입니다! 만약 정적 메서드에 의존하는 코드를 생성하는 데이터 지속성 레이어를 (잘못) 사용하고, 주의를 기울이지 않았다면, 당신의 코드는 다음과 같을 수 있습니다.