📚 Tutorial: 프로그래머 이규원의 웹사이트

블로그

May 27, 2025
@SpringBootTest 사용 테스트 성능 문제에 대한 답변
Spring 응용프로그램 개발에 TDD를 적용하는 과정에서 테스트 실행 속도와 관련된 질문이 자주 제기된다. 특히, @SpringBootTest를 사용한 테스트의 실행 성능과 관련한 고민을 많이 듣는다. 이와 관련된 인프런 Spring Boot TDD 강의의 질문이 올라와서 응용프로그램 컨텍스트(Spring application context)를 사용하는 테스트의 실행 성능에 대한 경험으로 답변했고 이 글에서 한 번 더 정리한다.
May 25, 2025
set DSL API
AutoParams의 10.3.1 버전 릴리스에는 형 안정적으로 매개변수를 지정하는 set 메서드가 새롭게 추가됐다. 이 글은 기존 방식과 새롭게 추가된 set DSL의 차이점과 사용법을 설명한다.
May 17, 2025
@Size 애노테이션 사용 컬렉션 크기 지정
AutoParams는 컬렉션 형식 인자를 생성할 때 기본적으로 3개의 요소를 포함한다. 많은 경우 이 기본 크기로 충분하지만, 테스트 대상에 따라 더 크거나 더 작은 컬렉션이 필요한 경우도 있다. Factory<T> 클래스나 @Customization 애노테이션을 사용해서 컬렉션 크기를 조절할 수 있지만, 10.1.1 버전 릴리스에 @Size 애노테이션을 사용해 컬렉션을 생성할 때 크기를 지정할 수 있는 기능이 추가되었다.
May 17, 2025
매개변수 이름에 의존하는 AutoParams 기능 사용
Java는 기본적으로 바이트코드에 매개변수 이름을 포함하지 않는다. 그렇기 때문에 일부 매개변수 이름에 의존하는 AutoParams 기능이 제대로 작동하려면 다음 방법 중 하나를 사용해야 한다:
Apr 6, 2025
@AutoParams 애노테이션
AutoParams를 처음 만들기 시작할 당시, JUnit 5의 @Test 메서드는 매개변수를 가질 수 없고 매개변수가 있는 테스트는 반드시 @ParameterizedTest를 사용해야 한다고 오해했다. 이런 인식 때문에 @ParameterizedTest와 함께 사용할 수 있는 @AutoSource 애노테이션을 만들었고, 이후 AutoParams의 기능은 이 @AutoSource 애노테이션을 중심으로 확장되었다.

하지만 시간이 지나고 JUnit 5 API에 대한 이해가 깊어지면서, @Test 메서드도 매개변수를 가질 수 있고, 이를 지원하는 확장 기능을 구현할 수 있다는 점을 알게 되었다.

이런 배경에서 10.0.0 버전 릴리스에서는 @Test 메서드에 사용할 수 있는 @AutoParams 애노테이션이 새로 추가되었다.
Apr 6, 2025
@UseBeans 애노테이션을 사용한 AutoParams와 Spring 테스트 통합
AutoParams의 핵심 모듈은 Spring에 전혀 의존하지 않는다. 이 점은 AutoParams를 다양한 환경에서 가볍게 사용할 수 있다는 장점이 되지만, Spring 기반 테스트에서는 조금 불편함을 유발하기도 한다.

예를 들어, 테스트 메서드에서 AutoParams가 자동으로 생성해주는 테스트 데이터와 함께 Spring 빈을 매개변수로 받고 싶을 때가 있다. 하지만 별도의 조치를 하지 않으면 AutoParams는 Spring 빈을 직접 생성하려고 시도하고, 이 과정에서 오류가 발생하게 된다.

이 글은 이 문제를 해결하는 기존의 방식과 10.0.0 버전 릴리스에 추가된 @UseBeans 애노테이션을 사용하는 방식을 비교 설명한다.
Apr 6, 2025
AutoParams에 도입된 DSL(Domain-Specific Language)
AutoParams의 10.0.0 버전 릴리스에는 처음으로 DSL(domain-specific language)이 도입됐다. 이 버전에 추가된 DSL은 테스트 데이터를 생성할 때 매개변수 인자를 고정하는 몇 가지 간결한 방법을 제공한다. 이 글은 DSL 사용 사례를 하나를 소개하고 기존 방식과의 차이를 비교한다.
Dec 31, 2023
이벤트와 명령
자주 사용되는 중개(brokered) 메시지 유형으로 이벤트(events)와 명령(commands)이 있다. 두 메시지 유형은 구현의 일부가 비슷할 수 있지만 일반적으로 서로 다른 특징을 갖는다.
Nov 9, 2022
쓸모없는 Java 패키지 이름 관습
Oracle은 이 페이지에서 다음과 같이 패키지 이름 관습을 제안한다.

Companies use their reversed Internet domain name to begin their package names—for example, com.example.mypackage for a package named mypackage created by a programmer at example.com.

관습 제안의 이유는 이렇다.

This works well unless two independent programmers use the same name for their packages. What prevents this problem? Convention.

이건 전통인가 악습인가?
Apr 4, 2021
커밋 메시지 주도 개발
나는 자신이 없는 코딩을 할 수록 계획을 작게 나눈다. 작은 계획을 실천하도록 사용하는 도구 중 한가지는 코드를 쓰기 전에 내가 어떤 코드를 쓸 지 커밋 메시지를 먼저 작성하는 것이다. 누군가에게 이 기법을 소개할 때에 ‘커밋 메시지 주도 개발’이란 표현을 쓴다.
Jul 31, 2020
좋은 코드란 무엇인가
많은 프로그래머들이 좋은 코드에 대해 얘기한다. 최근 코딩 경험이 적은 한 주니어가 나에게 좋은 코드는 유지보수 비용을 낮춘다고 말했다. 반면 잘 훈련되고 경험 많은 프로그래머들로부터는 그런 확신에 찬 얘기를 듣기 어렵다. 어떤 코드가 좋은 코드인가? 요즘 유행하는 클린 코드가 좋은 코드인가? 모르겠다. ‘코드’가 뭔지는 안다. 그럼 ‘좋은’이 뭔지만 분명해지면 좋은 코드도 이해할 수 있을 것 같다.
Jul 24, 2020
React에는 '함수형 컴포넌트'가 없다
이 글이 작성되는 시점에 React에는 ‘함수형(functional) 컴포넌트’가 없다. 내가 미쳤다고? 훗. 바로 증명하겠다. 지금 당장 공식 사이트에 들어가서 ‘functional component’라는 말이 나오는지 눈씻고 찾아보라. 한국어 사이트에 들어가서 ‘함수형 컴포넌트’라는 말도 찾아보라. 검색 기능도 제공하니 몇 초면 내가 제정신이란 걸 알게 될거다. React는 함수형 컴포넌트란 걸 제공하지 않는다.

하지만 넓은 인터넷 세상엔 React와 관련해 ‘함수형 컴포넌트’ 또는 ‘functional component’라는 말이 넘친다. 국내에 발행된 각종 서적 역시 마찬가지다. 어떻게 된거야?
Jun 23, 2020
이벤트 소싱의 본질
이벤트 소싱은 그렇게 어렵지 않다. 이벤트 소싱 패턴은 명령 패턴, CQRS, EDA, DDD 등과 자주 함께 설명되지만 그것들은 이벤트 소싱과 조합될 수 있는 설계 도구일 뿐 이벤트 소싱의 핵심이 아니다. 이벤트 소싱의 본질은 함수형 데이터 기록과 복원이다. 이벤트 소싱을 사용하는 시스템은 과거의 이벤트에 기반해 입력을 새로운 이벤트로 변환한다. 시스템의 이벤트 스트림을 만들어가는 과정이 이벤트 소싱의 정수다.
May 10, 2020
정말로 테스트 대역이 필요한가
얼마전 주니어 동료가 내 코드를 리뷰하며 이런 질문을 했다.

의존 대상을 추상화 해서 테스트 대역을 사용하면 테스트 조건을 설정하기 쉬울 것 같은데 왜 실제 코드를 사용했나?

처음 받는 질문이 아니다. 그동안 같은 질문을 여러 프로그래머들에게서 수십 번은 받았다. 테스트 대역(test double)보다 실제 DOC(depended-on component)를 선호해야 한다는 주장이 최근에 시작된 건 아니지만 아직 많은 프로그래머들이 단위 테스팅을 위해 테스트 대역이 필수라고 생각한다.

다른 주니어 동료가 반문했다.

테스트를 편하게 하기 위해 운영 코드 설계를 변경하는 것이 옳은 선택인가?
Dec 15, 2019
MV* 패턴에서 모델이란 무엇인가

이 글이 참조한 두 문서의 링크가 현재 정상적으로 동작하지 않는다. 대신 여기에 방문하면 두 문서의 내용이 모두 담긴 파일을 확인할 수 있다.

두괄식으로 결론부터 제시한다.

“Models represent knowledge.” - MODELS - VIEWS - CONTROLLERS, 1979
Dec 7, 2019
당신의 시스템은 도메인 주도 설계에 기반하는가

당신의 시스템은 도메인 주도 설계에 기반하는가?

이런 질문을 종종 받는데 난 그렇게 생각하지 않는다고 답한다. 도메인 전문가와의 긴밀한 협력 없이는 도메인 주도 설계(domain-driven design)의 의미와 가치가 급감하는데 이게 소프트웨어 전문가의 노력만으론 해결되지 않더라. 도메인 전문가도 도메인 주도 설계의 철학과 방식에 어느 정도는 공감을 가져야 한다. 그런데 프로그래머들도 도메인 주도 설계를 잘 이해하지 못하는데 어떻게 비즈니스 조직을 설득할 것인가?
Jul 22, 2019
현실 세상의 TDD
현실 세상에서 TDD는 가능하지 않다거나 효율이 너무 떨어져 쓸모없다는 주장은 지겹도록 들어왔지만 여전히 안타깝다. 나는 2018년에 이런 답답함을 조금이라도 풀어보고자 페이스북을 통해 5개월간 약 60명을 대상으로 ‘TDD 참관’이라는 행사를 진행했다.
Mar 3, 2019
TDD는 설계 방법론이 아니다
소셜 미디어에서 국내 저자의 어떤 서적에서 발췌했다는 다음 문장을 발견했다.

TDD는 설계를 위한 기법이다.

나는 그 책을 읽지 않았기 때문에 전후 맥락을 모르지만 만약 이 문장을 통한 작가의 의도가 TDD(Test-Driven Development)를 설계 방법론이라고 말하는 것이라면 그 위험한 생각에 서슴치 않고 반대하겠다. 나는 TDD를 즐겨 사용하지만 TDD가 잘 못 사용되어 프로젝트나 제품에 나쁜 영향을 미치는 것을 바라지 않는다.
Jan 4, 2019
코딩 시험과 TDD
구직 과정에 코딩 시험이 있었다. 면접관의 컴퓨터와 응사자의 컴퓨터가 코딩 시험 도구로 연결되어 면접관이 응시자의 코딩을 지켜보거나 개입할 수 있는 환경이었다. 어떤 문제의 답 코드를 쓰다 10줄 이상이 되니 자신감이 떨어져 TDD를 사용하기로 했다. 여기서 나는 흥미로운 경험을 했다.
Dec 19, 2018
소프트웨어 테스팅의 False Positive
False Positive는 이진 분류(binary classification) 실험 오류 중 하나로 통계 실험에서는 1종 오류(Type I Error)라고도 부르며 소프트웨어 테스팅에서도 쓰이는 용어다. 하지만 이진 분류와 통계 실험에 대한 배경지식이 없는 경우 소프트웨어 테스팅의 False Positive는 본래의 뜻과 반대의 의미로 잘 못 사용되곤 한다. 언어가 잘 못 사용되면 당연히 의사소통 장애로 이어진다.
Jun 24, 2018
TDD가 해결해 주는 것들
2014년에 DHH는 ‘TDD is dead. Long live testing.’이라는, 제목이 아니라 내용이, 다소 황당한 글을 썼고 얼마 후 Kent Beck은 관련된 글을 썼다.

RIP TDD

DHH가 TDD를 죽여서 TDD를 대신할 방법을 찾아야 한다는 글인데, 제대로 읽었다면 누구도 이것이 Kent Beck이 TDD를 떠난다고 말하는 글이라고는 생각하지 않을 것이다. 내 가설의 증거는 댓글들이다. 재미있으니 댓글들도 한 번 읽어보기를 추천한다.

그럼 실제 내용은 뭘까? 프로그래머가 TDD를 통해 얻을 수 있는 가치의 나열이 대부분이고 나머지 조금은 DHH에 대한 조롱이다. 나는 여기에 나열된 TDD의 효과 모두를 느껴왔고 그래서 TDD를 사용한다. 그리고 이 가치들이 더욱 알려지기를 바라는 마음에 한국어로 번역했다. 내 영어 실력은 아주 형편 없어서, 노력했지만 두 구절은 충분히 이해하지 못해 직역했다. 표시해 뒀으니 좋은 해석 의견이 있다면 대환영이다. 이후로는 모두 내 글이 아니라 번역이다.
Mar 5, 2017
MVVM 아키텍처 패턴
MVVM(Model/View/ViewModel) 패턴은 UI를 가지는 응용프로그램을 위한 아키텍처 패턴(architectural pattern)이다. MVVM 패턴은 MVC(Model/View/Controller) 패턴의 변형으로 뷰의 추상화를 만드는 것이 핵심이다. 뷰의 추상화는 재사용할 수 있고(reusable) 테스트하기 쉽다(testable). 뷰의 추상화를 통해 응용프로그램 구조는 단순해지고, 이상적으로, 시각 디자인과 표현 논리를 독립적으로 구현할 수 있다.
Feb 6, 2017
두렵다면 테스트를 작성하라
얼마전 다음과 같은 코드에 매개변수 param에 대한 null 여부 검사가 필요한지 의견을 묻는 글을 발견했다.
```
public void MyCode(string param)
{
    if (TheirCode(param))
    {
        DoSomething();
    }
}
```
May 19, 2016
스타트업에 취업하기
박재성님의 ‘최근 구직, 구인 글을 보면서 느끼는 단상’이란 글을 읽었는데 무척이나 공감했다. 특히 다음 구절에서 생각나는 일화가 있어서 적어본다.

다양한 스펙을 쌓는 것에 집중하기 보다 프로그래밍 자체를 즐기는 진정성을 보여주면 더 좋겠다. 경험도 너무 많은 경험보다는 한 가지 경험이라도 깊이 있는 경험을 하면 좋겠다. 프로그래밍 자체에 대한 열정은 자연스럽게 드러난다.