코알못

[문자인코딩] 02) 문자 인코딩/디코딩 실습

코린이s — Tue, 17 Mar 2026 22:07:52 +0900

우선 실습에 앞서 프로젝트를 생성해보자!

아래 화면과 같이 자바 프로젝트를 생성하며 자바 21버전을 사용하도록 한다.

프로젝트 생성시 Add sample code 에 체크박스 했기 때문에

아래와 같이 예제 코드가 들어있다.

메인을 실행하여 동작 여부를 확인해보자!

결과를 보면 정상적으로 출력 되는것을 볼 수 있다.

이제 메인 클래스에 아래와 같이 코드를 작성해보자!

해당 코드는 현재 이용 가능한 모든 문자 집합을 조회하는 코드이다.

// 이용 가능한 모든 Charset 자바 + OS
SortedMap<String,Charset> charsets = Charset.availableCharsets();
for (String charsetName : charsets.keySet()) {
	System.out.println("charsetName = " + charsetName);
}

메인을 실행하여 확인해보면 정말 많은 문자 집합이 나오는것을 볼 수 있다.

문자 집합을 사용하고 싶을경우 이와 같이 확인하여 지원 하는지 확인해 볼 수 있다.

다음으로 MS949 문자 집합을 조회해보자!

// 문자로 조회
Charset charset = Charset.forName("MS949");
System.out.println("charset = " + charset);

지원하는 항목에 있었기 때문에 아래와 같이 정상 출력 된다.

그러나 ms949 가 아닌 처음 보는 명칭이 나왔다!

출력된 명칭이 본 명칭이며 ms949는 별칭이다.

우리가 forName 에 별칭을 대소문자 구분 없이 입력하면 해당하는 문자 집합을 가져올 수 있다!

그럼 입력 가능한 별칭은 무엇이 있을까?

아래와 같이 해당 하는 문자 집합의 별칭을 조회 해 볼 수 있다.

// 별칭 조회
Charset charset = Charset.forName("MS949");
Set<String> aliases = charset.aliases();
for (String alias : aliases) {
    System.out.println("alias = " + alias);
}

결과를 보면 우리가 사용한 ms949 별칭을 포함하여 다른 별칭도 확인 할 수 있다.

Charset.forName 으로 별칭을 입력하여 문자 집합을 가져 올 수 있지만

자주 사용되는 문자 집합은 상수로 제공하고 있다.

UTF-8 의 경우 아래와 같이 SrandardCharsets 으로 제공하는 상수를 사용하여 문자 집합을 바로 가져올 수 있다.

// 자주 사용하는 문자집합은 상수로 제공
Charset charset2 = StandardCharsets.UTF_8;
System.out.println("charset2 = " + charset2);

출력을 보면 정상적으로 가져온것을 알 수 있다.

이제 우리 시스템인 OS 에 설정된 문자 집합을 조회해보자!

// 시스템의 기본 Charset 조회
Charset charset3 = Charset.defaultCharset();
System.out.println("charset3 = " + charset3);

저자의 경우 UTF-8 로 설정 되어있는것을 볼 수 있다.

사용자 PC 마다 설정 값이 다르므로 저자와 출력은 다를 수 있다.

이제 실제로 문자 집합을 이용하여 인코딩 하는 실습을 해보자!

아래와 같이 미리 문자 집합을 상수로 지정해둔다.

그리고 encoding 메서드를 만들어 인코딩 되는 값을 출력, 몇바이트를 사용했는지 출력되도록 한다.

String.getByte 에 문자 집합을 변수로 넣으면 해당 문자집합으로 인코딩 된다.

그리고 main 함수에서 A 와 a 가 ASCII 인코딩 했을시 출력이 어떻게 되는지 확인해보자!

private static final Charset EUC_KR = Charset.forName("EUC-KR");
private static final Charset MS_949 = Charset.forName("MS949");
public static final Charset US_ASCII = StandardCharsets.US_ASCII;

public static void main(String[] args) {
    System.out.println("== ASCII 영문 처리 ==");
    encoding("A", US_ASCII);
    encoding("a", US_ASCII);
}

private static void encoding(String text, Charset charset) {
    byte[] bytes = text.getBytes(charset);
    System.out.printf("%s -> [%s] 인코딩 -> %s %sbyte\n", text, charset, Arrays.toString(bytes), bytes.length);
}

main 을 돌려보면 아래와 같이 나온다.

A 의 경우 ASCII 로 인코딩시 65 이며 1byte를 사용한다.

a 의 경우 97이다.

저번 시간에 배운대로 정상적으로 인코딩 되어 출력 되었다.

이제 동일한 A 문자를 가지고 여러 문자 집합별 결과가 어떻게 나오는지 확인해보자!

public static final Charset UTF_8 = StandardCharsets.UTF_8;
private static final Charset EUC_KR = Charset.forName("EUC-KR");
private static final Charset MS_949 = Charset.forName("MS949");
public static final Charset US_ASCII = StandardCharsets.US_ASCII;
public static final Charset ISO_88591 = StandardCharsets.ISO_8859_1;
public static final Charset UTF_16BE = Charset.forName("UTF-16BE");

public static void main(String[] args) {
    System.out.println("== ASCII 영문 처리 ==");
    encoding("A", US_ASCII);
    encoding("A", ISO_88591);
    encoding("A", EUC_KR);
    encoding("A", UTF_8);
    encoding("A", UTF_16BE);
}

private static void encoding(String text, Charset charset) {
    byte[] bytes = text.getBytes(charset);
    System.out.printf("%s -> [%s] 인코딩 -> %s %sbyte\n", text, charset, Arrays.toString(bytes), bytes.length);
}

결과를 확인해보면..

영문은 US-ASCII, ISO-8859-1, EUC-KR, MS949, UTF-8 모두 ASCII 와 호환된다.

해당 문자 집합들은 1byte 만 사용하고 숫자 65로 인코딩 한다.

그러나 UTF-16의 경우 ASCII 와 호환되지 않는다.

그 이유는 결과를 보면 2byte 를 사용하고 숫자 0, 65 로 인코딩 되어 이전 인코딩과는 다른값으로 인코딩 되기 때문이다.

이제 한글 인코딩을 테스트 해보자!

public static final Charset UTF_8 = StandardCharsets.UTF_8;
private static final Charset EUC_KR = Charset.forName("EUC-KR");
private static final Charset MS_949 = Charset.forName("MS949");
public static final Charset US_ASCII = StandardCharsets.US_ASCII;
public static final Charset ISO_88591 = StandardCharsets.ISO_8859_1;
public static final Charset UTF_16BE = Charset.forName("UTF-16BE");

public static void main(String[] args) {
    System.out.println("== 한글 지원 ==");
    encoding("가", EUC_KR);
    encoding("가", MS_949);
    encoding("가", UTF_8);
    encoding("가", UTF_16BE); // UTF-16 문자 집합 표기법중 BE, LE 가 있는데 의미하는 바는 인코딩 숫자 표기 되는 순서일뿐 두개는 같다.
}

private static void encoding(String text, Charset charset) {
        byte[] bytes = text.getBytes(charset);
        System.out.printf("%s -> [%s] 인코딩 -> %s %sbyte\n", text, charset, Arrays.toString(bytes), bytes.length);
    }

한글의 경우 EUC-KR, MS949 는 동일하게 2byte 를 사용하며 인코딩 된 값도 동일하다.

그러므로 서로 호환 되는것을 알 수 있다.

저번 시간에 MS949 는 EUC-KR 확장 버전이라고 배웠으며 그렇기 때문에 결과도 동일 하게 된다.

그러나 UTF-8 의 경우 한글 인코딩은 3byte 를 사용하므로 다르게 인코딩 된것을 볼 수 있으며

UTF-16 의 경우에는 2byte 를 사용하나 인코딩 된 값이 다르므로 호환 되지 않는다.

문자를 byte 로 변경하려면 무조건 문자 집합이 필요하다.

그래서 String.getByte() 인자로 Charset 문자집합을 넘겨줘야 한다.

넘겨주지 않을시 시스템 기본 문자집합을 인코딩에 사용한다는 점을 알 고 있어야 한다.

이제 인코딩 > 디코딩 테스트를 해보도록 하자!

아래와 같이 코드 작성하면 되며

test 메서드에서 String.getByte(문자집합) 을 통해 해당 문자집합으로 인코딩 하며

new String(인코딩 byte, 문자집합) 을 통해 해당 문자 집합으로 디코딩 한다.

인코딩, 디코딩 할때는 반드시 문자집합을 지정해줘야 하며 지정 안할 시 시스템 default 설정을 따르게 되므로

실무에서는 시스템 마다 결과가 달라지지 않도록 지정 해주도록 하자!

그리고 main 함수에서 'A' 를 ASCII 로 인코딩 하고 다른 문자 집합으로 디코딩 했을때 결과를 보도록 하자!

public static final Charset ISO_88591 = StandardCharsets.ISO_8859_1;
public static final Charset UTF_8 = StandardCharsets.UTF_8;
private static final Charset EUC_KR = Charset.forName("EUC-KR");
private static final Charset MS_949 = Charset.forName("MS949");
public static final Charset US_ASCII = StandardCharsets.US_ASCII;
public static final Charset UTF_16_BE = StandardCharsets.UTF_16BE;

public static void main(String[] args) {
    System.out.println("== 영문 ASCII 인코딩 ==");
    test("A", US_ASCII, US_ASCII);
    test("A", US_ASCII, ISO_88591);
    test("A", US_ASCII, EUC_KR);
    test("A", US_ASCII, MS_949);
    test("A", US_ASCII, UTF_8);
    test("A", US_ASCII, UTF_16_BE);
}

private static void test(String text, Charset encodingCharset, Charset decodingCharset) {
    byte[] encoded = text.getBytes(encodingCharset);
    String decoded = new String(encoded, decodingCharset);
    System.out.printf("%s -> [%s] 인코딩 -> %s %sbyte -> [%s] 디코딩 -> %s\n", text, encodingCharset, Arrays.toString(encoded), encoded.length, decodingCharset, decoded);
}

결과를 보면 UTF-16 빼고는 모두 ASCII 를 호환 하기 때문에 정상적으로 나오며

UTF-16은 지원하지 않기 때문에 '?' 로 나오는것을 볼 수있다.

이제 한글 인코딩 테스트 해보도록 하자!

System.out.println("== 한글 인코딩 ==");
test("가", US_ASCII, US_ASCII);
test("가", ISO_88591, ISO_88591);
test("가", EUC_KR, EUC_KR);
test("가", MS_949, MS_949);
test("가", UTF_8, UTF_8);
test("가", UTF_16_BE, UTF_16_BE);

ASCII , ISO-8859의 경우에는 한글 지원 하지 않기 때문에 ? 로 나왔으며

나머지는 한글 지원하므로 정상적으로 인코딩, 디코딩이 되는것을 볼 수 있다.

이제 복잡한 한글인 '뷁'을 인코딩 해보자!

System.out.println("== 한글 인코딩 - 복잡한 문자 ==");
test("뷁", EUC_KR, EUC_KR);
test("뷁", MS_949, MS_949);
test("뷁", UTF_8, UTF_8);
test("뷁", UTF_16_BE, UTF_16_BE);

저번 시간에 배운 내용과 같이 EUC-KR 은 자주사용하는 한글만 표기 되도록 집합이 구성되어있어 '뷁'은 문자 집합에 없다.

그래서 ? 로 나오는것을 볼 수 있다.

그리고 EUC-KR 의 확장 버전인 MS-949와 그 뒤에 나온 UTF-8, 16 모두 정상적으로 인코딩, 디코딩 되는것을 볼 수있다.

이제 한글 인코딩과 디코딩이 다른경우를 보자!

System.out.println("== 한글 인코딩 - 디코딩이 다른경우 ==");
test("가", EUC_KR, MS_949);
test("뷁", MS_949, EUC_KR);
test("가", MS_949, UTF_8);
test("가", UTF_8, MS_949);

결과를 보면..

'가' 의 경우 EUC-KR, MS949 모두 지원하므로 정상 인코딩, 디코딩 되어 출력 된것을 볼 수 있다.

그러나 '뷁' 의 경우 EUC_KR 에서 지원하지 않기 떄문에 인코딩은 정상적으로 됐을지라도 디코딩에서 실패하여 '?' 로 노출된다.

그리고 MS949 와 UTF-8 은 한글 인코딩 되는 byte 수 부터 다르기 때문에 ? 로 나오게 된다.

영문의 경우에도 보자!

System.out.println("== 영문 인코딩 - 디코딩이 다른경우 ==");
test("A", EUC_KR, UTF_8);
test("A", MS_949, UTF_8);
test("A", UTF_8, MS_949);
test("A", UTF_8, UTF_16_BE);

영문의 경우 모두 1byte 로 인코딩 되며 모두 호환 되지만, UTF-16 의 경우 2byte 로 인코딩 값이 다르다.

그러므로 UTF-16 으로 디코딩 한 부분만 ? 로 나오는것을 볼 수 있다.

이제 총 정리 해보자!

영문은 대부분 모두 호환 되나 UTF-16 은 호환 되지 않아 인코딩/디코딩시 오류 발생 한다.

한글의 경우 EUC-KR 과 MS949 는 호환 되나 '뷁' 같이 자주 사용하지 않는 한글은 EUC-KR 에서는 문자 집합이 없기에 오류 발생할 수 있다.

그 외 한글 인코딩/디코딩을 다른 문자 집합으로 할때 서로 호환 되지 않아 오류 발생 할 수 있다.

# 참고

1) byte 출력에 - 가 나오는 이유는 ?

1byte 는 8bit 로 256 가지 표현된다. 그러나 자바에서 byte 는 양수, 음수 모두 표현 가능하다.

그러므로 십진수로 표기 할때 256 가지 이지만 -128 ~ 127 로 표기 한다.

메모리에 이진수로 저장되는 값은 같으나 화면에 십진수에 표기 되는거만 다른것 뿐이다.

[문자인코딩] 01) 문자 인코딩이란?

코린이s — Mon, 16 Mar 2026 22:12:43 +0900

우리는 컴퓨터를 사용하면서 이런 의문을 가진다..

컴퓨터는 문자를 어떻게 저장할까?

컴퓨터는 우리가 보는 글자 그대로를 저장하지 않는다. 모든 정보를 0과 1로만 처리한다.

그 이유는 컴퓨터의 메모리는 반도체로 만들어져 있고
전기가 흐르냐(1) / 안 흐르냐(0) 두 가지 상태로만 데이터를 표현하기 때문이다.

그래서 컴퓨터는 모든 데이터를 이진수(0과 1) 로 표현한다.

컴퓨터에서 가장 작은 데이터 단위를 bit(비트) 라고 한다.

1bit는 0 또는 1 이진수 두 가지를 표현할 수 있다.

비트 별로 표현할 수 있는 가지수를 보자!

비트	표현 가능 수
1 bit	0, 1 (2가지)
2 bit	00, 01, 10, 11 (4가지)
3 bit	000, 001, 011 .... (8가지)
8 bit	256가지

8bit는 256가지 경우를 표현할 수 있으며
이 8bit = 1byte(바이트) 라고 부른다.

그럼 숫자는 어떻게 저장할까 ?

예를 들어 10진수 100이라는 숫자를 저장한다고 해보자.

컴퓨터는 10진수를 직접 저장하지 않는다!

그래서 아래와 같이 10진수를 2진수로 변환하여 저장한다.

100 (10진수)
→ 1100100 (2진수)

이렇게 변환된 이진수 형태로 메모리에 저장된다.

그럼 음수는 어떻게 표현할까?

컴퓨터는 양수와 음수도 표현해야 한다. 그래서 보통 1bit를 부호 표현에 사용한다.

예를 들어 8bit를 사용한다고 해보자.

1bit → 부호
7bit → 숫자 표현

부호는 1bit 사용되며 양수는 0 , 음수는 1로 표현된다.

그래서 표현 범위는 이렇게 된다.

양수 : 0 ~ 127
음수 : -128 ~ -1

그럼 문자는 어떻게 저장할까?

숫자는 이진수로 바꾸면 된다. 하지만 문자는 어떨까?

A
B
a
b

위와 같은 문자를 0 과 1로 표현하기에는 어렵다.

여기서 등장하는 개념이 바로 문자 집합(Character Set) 이다.

문자 집합은 말 그대로 문자를 숫자에 매핑해 놓은 표이다.

예를 들어 이런 식이다.

A → 65
B → 66
a → 97
b → 98

그래서 컴퓨터는 문자 → 숫자 → 2진수 이렇게 변환해서 저장한다.

그리고 읽을 때는 반대로 2진수 → 숫자 → 문자 로 읽는다.

이 과정을 문자 인코딩, 디코딩이라고 표현한다.

문자 → 숫자 변환 = 문자 인코딩 (Encoding)
숫자 → 문자 변환 = 문자 디코딩 (Decoding)

그런데 문제가 발생했다..!

만약 컴퓨터마다 문자 집합이 다르면 어떻게 될까?

예를 들어

A = 65 (컴퓨터1)
A = 120 (컴퓨터2)

이러면 서로 데이터를 교환할 때 문자가 깨져버린다.

그래서 표준 문자 집합이 필요해졌다!

그래서 등장한 것이 바로

ASCII (American Standard Code for Information Interchange) 문자 집합이다.

ASCII는 7bit 문자 집합이다.

2^7 = 128개 문자를 표현할 수 있다.

대표적으로

영문 대문자
영문 소문자
숫자
기본 특수문자

같은 것들이 포함되어 있다.

하지만 문제점이 있었다. ASCII는 이름에서도 보이듯이 American 미국 중심 문자만 포함되어 있었다!

그래서 유럽에서 사용하기 위해 ISO-8859-1 (Latin-1) 이 등장했다.

ASCII는 7bit였지만 여기에 1bit를 추가해서 é 와 같은 라틴어을 포함하여 8bit로 만들었다.

2^8 = 256 문자

한국에서도 컴퓨터 사용이 늘어나면서 한글 표현 문제가 생겼다.

한글은 글자가 매우 많기 때문에 ASCII처럼 1byte로는 표현이 부족했다.

그래서 등장한 것이 EUC-KR 이다.

영문 → 1byte, 한글 → 2byte 로 표현 할 수 있으며 ASCII는 그대로 사용하여 호환이 가능하다.

그리고 2byte로도 충분히 공간이 남아서 한자와 일본어 일부도 포함되어있다.

윈도우에서는 EUC-KR을 확장한 MS949 인코딩을 사용한다.

EUC-KR이 표현하지 못하던 '쀍 등' 같은 잘 사용하지 않는 한글이 포함된다.

현재도 Windows 한글 시스템에서는 이전 윈도우 호환성을 위해 기본 인코딩으로 사용된다.

시간이 지나면서 문제가 생겼다.

컴퓨터가 전 세계적으로 사용되기 시작한 것이다.

그래서 모든 언어를 하나의 문자 집합으로 표현해야 했으며 그래서 등장한것이 유니코드(Unicode) 이다.

대표적인 인코딩 방식은 UTF-16, UTF-8 이 있다.

UTF-16은 기본으로 2byte 기반이며 일부 특수 문자(이모지, 고대문자 등)들은 4byte 를 사용한다.

하지만 ASCII 문자도 2byte 를 사용하기에 기존 ASCII(1byte를 사용하므로) 호환되지 않으며

저장 공간도 1byte > 2byte 로 늘어나게 되는 단점이 있다.

그래서 나온것이 UTF-8 이다.

UTF-8은 가변 길이 인코딩이다. 즉 문자에 따라 사용하는 byte가 달라진다.

1byte → ASCII, 영문, 기본 라틴 문자
2byte → 그리스어, 히브리어, 라틴 확장
3byte → 한글, 한자, 일본어
4byte → 이모지, 고대 문자

UTF-8 은 ASCII가 1byte 를 사용하기에 ASCII로 이전에 저장된 문자와 완벽히 호환되며

영문 문서의 경우 그대로 1byte 사용하므로 용량의 증가가 없고(대부분 문서가 영문, 코딩도 영문이므로 중요한 부분중 하나), 전세계 문자 표현도 가능하다.

그래서 현재까지 웹사이트, 앱, 서버, DB 와 같이 다양한 곳에서 가장 많이 사용하는 인코딩이 UTF-8가 되었다.

그래서 정리해보면

컴퓨터는 문자 → 숫자 → 이진수 로 데이터를 저장한다.

그리고 이 과정에서 필요한 것이 문자 집합, 문자 인코딩 이다.

ASCII에서 시작해서 EUC-KR, MS949를 거쳐

지금은 UTF-8이 사실상 표준 인코딩이 되었다.

[TDD] SpringBoot 를 통한 TDD 손쉬운 작성 - 05) 테스트 코드 품질 높이기! - 03

코린이s — Tue, 10 Mar 2026 22:10:14 +0900

저번 시간까지는 하나의 값에 대한 검증하는 방법을 배웠다!

이번 시간에는 컬렉션 검증에 자주 사용되는 AssertJ 메서드에서 알아보자!

1) extracting() 을 이용한 정보 추출 검증, contains() 를 통한 내부값 포함 여부 검증

객체 리스트에서 특정 필드만 추출해서 검증하고 싶을 때 extracting()을 사용해보자!

예를 들어 객체 리스트에서 name 필드만 추출해서 검증할 수 있다.

assertThat(users)
    .extracting(User::getName)
    .contains("Kim", "Lee");

이렇게 하면 객체 내부의 값을 꺼내서 원하는 데이터만 집중적으로 검증할 수 있다!

그리고 contains() 를 통해 내부에 해당 값을 전부 포함하고 있는지 확인한다.

2) containsAll() 목록 포함 여부 검증

앞에 contains() 와 기능 부분은 동일하게 해당 값을 전부 포함하는지 확인할 수 있다!

다만 다른점은 내부 매개변수를 직접 정의가 아닌 컬렉션으로 정의할 수 있다.

아래 예시를 보자!

assertThat(users)
	.extracting(User::getName)
	.containsAll(Arrays.asList("Kim","Lee"));

Arrays.asList 와 같이 컬렉션을 넘겨 해당 값들을 전부 포함하고 있는지 확인한다.

정의한 값 중에 하나라도 없으면 오류가 발생하고, 해당 값 이외에 다른 값이 더 있어도 오류 발생하지 않는점은 위 contains() 와 동일하다!

3) doesNotContain() 요소가 포함되지 않았는지 검증

특정 값이 리스트에 존재하지 않는지 확인하고 싶다면 doesNotContain()을 사용해보자!

assertThat(users)
	.extracting(User::getName)
	.doesNotContain("Kim");

이렇게 하면 name 중에 "Kim' 이 있다면 검증 실패가 된다.

doesNotContain 을 사용하면 해당 요소가 목록에 포함되어 있지 않은지 검증할 수 있다!

4) isSortedAccordingTo() 정렬 기준 검증

리스트가 특정 기준으로 정렬되어 있는지 확인하고 싶다면 isSortedAccordingTo()를 사용해보자!

오름차순인지 보려면 아래와 같이 Comparator 코드에는 natualOrder() 을 사용하면 되며

우리가 보통 네츄럴 하게 생각하는 정렬은 오름차순이기에 natualOrder 가 오름차순 정렬을 검증하는것 이라고 한다.

assertThat(numbers).isSortedAccordingTo(Comparator.naturalOrder());

오름차순은 아래와 같이 간단하게 검증 할 수 있다!

assertThat(numbers).isSorted();

만약에 내림차순 정렬 여부를 검증 한다고 하면

뒤에 Comparator 코드만 내림차순인 reverseOrder 로 변경하면 된다!

assertThat(numbers)
    .isSortedAccordingTo(Comparator.reverseOrder());

직접 Comparator 기준을 작성해서 넣을수도 있다!

Comparator 코드 작성하는 방법은 다음에 필요할때 검색해서 사용해보도록 하고 현재는 검증 방법만 알아두도록 하자!

5) containsExactly() 정확한 값과 순서 검증

앞에서 contains(), containsAll() 을 통해 리스트의 값이 모두 포함되어 있는지를 검증 할 수 있었다.

여기에 순서까지 체크하고 싶다면 containsExactly()를 사용해보자!

assertThat(numbers)
    .containsExactly(1, 2, 3);

이 메서드는

값이 정확히 같아야 하고
순서도 동일해야 하고
추가 데이터도 없어야 한다

즉 완전히 동일한 목록인지 검증할 때 사용한다!

6) containsExactlyElementsOf() 동일 목록 + 동일 순서 검증

containsExactlyElementsOf()도 containsExactly()와 비슷하다.

assertThat(numbers)
    .containsExactlyElementsOf(List.of(1, 2, 3));

이 메서드 역시

값 동일
순서 동일
추가 데이터 없음

을 검증한다.

차이점은 입력 방식이다!

containsExactly() → 개별 값 입력
containsExactlyElementsOf() → 컬렉션 형태 입력

즉 검증 대상 데이터를 List나 Set 형태로 받을 때 사용하기 편하다!

끝!

[TDD] SpringBoot 를 통한 TDD 손쉬운 작성 - 04) 테스트 코드 품질 높이기! - 02

코린이s — Sun, 8 Mar 2026 15:25:24 +0900

저번 시간에 이어서 테스트 코드 품질을 개선하는 방법에 대해서 알아보자!

이번 시간에는 아래 방법에 대해서 예시를 통해 하나씩 보도록 한다.

TestRestTemplate.postForObject
TestRestTemplate.exchange
AssertJ.isCloseTo
@DirtiesContext
TestFixture
TestDSL

우리는 TestRestTemplate.postForEntity 를 이전 시간에 사용했다.

그러나 우리가 응답의 헤더나 상태코드가 필요 없고 응답 데이터만 필요할 때가 있다.

그럴때 사용할 수 있는 메서드는 postForObject 이다!

아래와 같이 예제 코드를 작성해보자.

Users users = Users.builder()
            .name("코린이")
            .id("test")
            .password(password)
            .build();
            
Users response = client
            .postForObject("/users", users, Users.class);
System.out.println(response.getName());

그러면 바로 응답 데이터인 Users로 받게 되어 아래와 같이 getBody 를 호출하지 않아도 바로 받아 처리 할 수 있어

간단한 요청 테스트에 사용할 수 있다.

Users users = response.getBody();

다음으로는 TestRestTemplate.exchange 에 대해서 알아보자!

exchange() 는 HTTP Header, Method, Entity 등을 모두 지정할 수 있는 메서드이다.

기존에 사용하던 postForEntity 나 postForObject 의 경우 따로 지정 할 수 없었다.

그래서 원하는 대로 지정해서 사용하고자 하면 exchange를 사용하면 된다!

아래 예시와 같이 Header 과 요청값을 정의하고 exchange 에 넣는다.

HttpHeaders headers = new HttpHeaders();
headers.add("Authorization", "Bearer token");

Users users = Users.builder()
            .name("코린이")
            .id("test")
            .password(password)
            .build();
HttpEntity<Users> request = new HttpEntity<>(users, headers);

ResponseEntity<Users> response = client.exchange(
    "/users",
    HttpMethod.POST,
    request,
    Users.class
);

System.out.println(res01.getBody().getName());

실행해보면 아래와 같이 정상적으로 출력됨을 확인 할 수 있다.

그리고 검증 기능 하나 더 알아 보자면..

DB에 저장되는 시간을 검증할 때는 현재 시각과 약간의 차이가 발생할 수 있다.

따라서 정확히 같은 시간을 비교하면 테스트가 실패할 수 있다.

이때 AssertJ의 isCloseTo 를 사용하면 된다.

우선 우리가 regDate 라는 칼럼을 생성하지 않았으므로 아래와 같이 생성한다.

@EntityListeners(AuditingEntityListener.class)
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor
@Builder
@Getter
@Entity
public class Users {

    @Id
    String userId;
    String name;
    String password;
    @CreatedDate
    LocalDateTime regDate;
}

@EntityListeners 가 자동으로 @CreatedDate 가 붙은 컬럼에 생성일을 추가하여 Insert 쿼리를 날린다.

참고 사항으로 만약 Spring 이 아니라 DB에서 자동 생성 되도록 하려면 아래와 같이 수정한다.

@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor
@Builder
@Getter
@Entity
public class Users {

    @Id
    String userId;
    String name;
    String password;
    @Column(insertable = false, updatable = false)
    LocalDateTime regDate;
}

@Column(insertable = false, updatable = false) 을 지정하여 업데이트와 임의로 데이터 추가 안되도록 정의하고

@CreateDate 와 @EntityListeners 를 제거 한다.

그리고 DB 의 regDate 칼럼 생성시 아래와 같이 Default 값 자동으로 들어가도록 설정 해야 한다.

reg_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP

이제 테스트 코드에 Regdate 값을 isCloseTo 로 비교하는 문을 넣는다.

@Test
void 유저_생성(){
    // Arrange
    LocalDateTime now = LocalDateTime.now();
    Users users = UserFixture.createUser();

    // Act
    ResponseEntity<Users> response = userDSL.회원생성(users);

    // Assert
    assertThat(response.getStatusCode().value()).isEqualTo(200);
    assertThat(response.getBody()).isNotNull();
    assertThat(response.getBody()).isNotNull();
    assertThat(response.getBody().getRegDate()).isCloseTo(now, within(1, ChronoUnit.SECONDS));
}

해당 코드는 상단에 테스트 코드 실행시 현재 시간을 저장한 now 와, DB의 regdate 값의 1s 이내 차이 까지는

허용 하겠다는 의미로 코드 실행 시점부터 instert 까지 ms 정도 차이가 있을수 있으니

1s 의 차이는 테스트 통과로 지정한다!

그럼 아래와 같이 테스트 코드가 통과하는것을 볼 수 있다.

그리고 만약 테스트 실행중에 같이 사용하는 클래스가 서로 영향을 주어 실패한다고 하면..

아래와 같이 @DirtiesContext 를 테스트 코드 위에 정의 한다!

@SpringBootTest
@DirtiesContext
class ServiceTest {
...}

스프링에서 bean 생성은 싱글톤 이라서 컨테이너에 빈 하나만 생성되고 계속적으로 사용된다.

그러므로 테스트마다 다음 테스트에 영향을 주면 안되는 경우에 @DistiesContext 를 정의하여

매번 빈을 생성하여 테스트 끼리 공유 되지 않도록 할 수 있다!

이제 테스트 픽스처(Test Fixture)에 대해서 알아보자!

테스트 픽스처(Test Fixture) 는 테스트를 수행하기 위해 미리 준비해두는 데이터나 객체를 의미한다.

테스트에서 반복적으로 사용하는 객체 생성 코드를 한 곳에 모아서 관리하면 테스트 코드의 가독성이 좋아진다.

예시로 알아보자!

우리는 테스트 진행할때 테스트 할 더미 유저를 많이 생성했다.

이를 미리 준비해두고 사용하는것이 더 좋을것 같아 유저 생성하는 메서드를 테스트 픽스처로 만들어 보도록 한다!

유저 픽스쳐를 만들고 static 으로 유저 생성하는 메소드를 만든다.

package test.commerce.fixture;

import commerce.command.Users;

public class UserFixture {

    public static Users createUser() {
        return Users.builder()
            .name("코린이")
            .id("test")
            .password("test")
            .build();
    }
}

아래 코드는 이전 시간에 만든 테스트 코드 이다.

@Test
void 비밀번호검증(
    @Autowired TestRestTemplate client
) {
    // Arrange
    Users users = Users.builder()
        .name("코린이")
        .id("test")
        .password("test")
        .build();

    // Act
    ResponseEntity<Users> response = client
        .postForEntity("/users", users, Users.class);

    // Assert
    assertThat(response.getStatusCode().value()).isEqualTo(200);
    assertThat(response.getBody()).satisfies(this::assertName);
    assertThat(response.getBody()).satisfies(this::assertPassword);
}

유저 생성하는 코드를 테스트 픽스쳐로 변경하면 코드 가독성 향상이 되고

나중에 유저 생성하는 테스트 케이스가 있다면 중복 정의 하지 않고 재사용 가능하다.

@Test
void 비밀번호검증(
    @Autowired TestRestTemplate client
) {
    // Arrange
    Users users = UserFixture.createUser();

    // Act
    ResponseEntity<Users> response = client.postForEntity("/users", users, Users.class);

    // Assert
    assertThat(response.getStatusCode().value()).isEqualTo(200);
    assertThat(response.getBody()).satisfies(this::assertName);
    assertThat(response.getBody()).satisfies(this::assertPassword);
}

매번 사용하는 코드를 미리 준비하는것이 TestFixture 라는것을 알아봤다.

이제 알아볼것은 Test DSL 이다.

Test DSL 은 Test Domain Spectific Language 로 영어 그대로 해석해 보면 도메인에 맞게 만든 언어 라는 의미 이다.

즉, 테스트 코드를 읽기 쉽게 만드는것으로 '테스트 코드의 가독선 개선'을 위해 만들어진 개념이다.

유저 생성 예시를 통해 알아보자!

@Test
void 유저_생성(
    @Autowired TestRestTemplate client
) {
    // Arrange
    Users users = UserFixture.createUser();

    // Act
    ResponseEntity<Users> response = client.postForEntity("/users", users, Users.class);

    // Assert
    assertThat(response.getStatusCode().value()).isEqualTo(200);
    assertThat(response.getBody()).satisfies(this::assertName);
    assertThat(response.getBody()).satisfies(this::assertPassword);
}

Act 부분의 유저 생성 부분을 직관적으로 알 수 있게 DSL 로 만들어 보자

그럼 UserDSL 을 먼저 생성하여 유저 생성 메서드를 만든다.

package test.commerce.dsl;

import commerce.command.Users;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.web.client.TestRestTemplate;
import org.springframework.http.ResponseEntity;
import org.springframework.stereotype.Component;

@Component
public class UserDSL {

    @Autowired
    TestRestTemplate testRestTemplate;

    public ResponseEntity<Users> 회원생성(Users users) {
        return testRestTemplate.postForEntity("/users", users, Users.class);
    }
}

그리고 해당 DSL 을 사용하기 위해서는 해당 빈을 스캔해줘야하는데

우리 실습 같은 경우에는 @SpringTest 에 스캔할 클래스를 지정했다.

그러므로 UserDSL 도 스캔해야하니 지정하도록 한다.

@SpringBootTest(
    classes = {CommerceApiApp.class, UserDSL.class},
    webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT
)

그리고 테스트 코드에 회원 생성하는 부분을 DSL 로 변경한다.

@Test
void 유저_생성(
@Autowired UserDSL userDSL){
    // Arrange
    Users users = UserFixture.createUser();

    // Act
    ResponseEntity<Users> response = userDSL.회원생성(users);
    
    // Assert
    assertThat(response.getStatusCode().value()).isEqualTo(200);
    assertThat(response.getBody()).satisfies(this::assertName);
    assertThat(response.getBody()).satisfies(this::assertPassword);
}

이렇게 변경하면 행위에 대한 부분을 알기 쉽게 표현하여 가독성이 좋아진다.

이처럼 데이터를 미리 셋팅하고 준비하는것이 TestFixture 라고 하면,

테스트 코드 케이스 중 행위에 대한 반복이 이뤄 지게 되는데, 이를 누구나 알기 쉽게 정의 해두는것은 Test DSL 이라고 한다.

두개 개념이 비슷해서 헷갈릴 수 있다. 몇가지 더 예시를 통해 알아보자!

우선 구조는 아래와 같이 보통 두게 되며

핵심은 데이터 준비는 Fixture, 행동은 DSL, 검증은 테스트 본문에 두는 것이다.

src
└─ test
     └─ java
         ├─ fixture
         │   ├─ UserFixture
         │   └─ OrderFixture
         │
         ├─ dsl
         │   ├─ UserApiDsl
         │   └─ OrderApiDsl
         │
         └─ user
             └─ UserApiTest

유저 생성 관련해서 Fixture 를 아래와 같이 둔다. 보면 데이터 준비 관련 내용이다.

public class UserFixture {

    public static UserCreateRequest 회원가입요청내용() {
        return new UserCreateRequest(
                "tester",
                "tester@test.com",
                "password123"
        );
    }

}

public class OrderFixture {

    public static OrderCreateRequest 주문요청내용(Long userId) {
        return new OrderCreateRequest(
                userId,
                "상품1",
                2
        );
    }
}

DSL의 경우 테스트에 대한 행위를 둔다.

@Component
public class UserApiDsl {

    private final TestRestTemplate restTemplate;

    public UserApiDsl(TestRestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    public UserResponse 회원가입(UserCreateRequest request) {
        return restTemplate.postForObject(
                "/users",
                request,
                UserResponse.class
        );
    }
}

@Component
public class OrderApiDsl {

    private final TestRestTemplate restTemplate;

    public OrderApiDsl(TestRestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    public OrderResponse 주문생성(OrderCreateRequest request) {
        return restTemplate.postForObject(
                "/orders",
                request,
                OrderResponse.class
        );
    }
}

그리고 테스트 코드를 아래와 같이 작성 할 수 있다.

@Test
void 주문_생성시_상품명_정상리턴() {
	
    UserCreateRequest request = UserFixture.회원가입요청내용();
    
    UserResponse user = userApiDsl.회원가입(request);

    OrderCreateRequest orderRequest =
            OrderFixture.주문요청내용(user.getId());

    OrderResponse order =
            orderApiDsl.주문생성(orderRequest);

    assertThat(order.getProductName()).isEqualTo("상품1");
}

가독성 좋은 코드가 되며, 대상 데이터 준비는 Fixture, 행위 관련 내용은 DSL 에 정의 되어 있는것을 알 수 있다.

그리고 테스트를 하다 보면 다양한 입력값이 필요하다.
이때 매번 값을 직접 만드는 것은 번거롭기 때문에 임의 값 생성 클래스를 만들어 사용하는 것이 좋다.

패스워드와 이름을 자동 생성하는 제너레이터를 만든다.

package test.commerce.ganerator;

import java.util.UUID;

public class DataGenerator {
    public static String randomPassword() {
        return UUID.randomUUID() + "Password!";
    }

    public static String randomName() {
        return "user-" + UUID.randomUUID();
    }
}

그리고 Fixture 에 매개변수를 받으면 해당 매개변수로 생성, 그렇지 않으면 랜덤 생성하는 메서드를 만든다.

package test.commerce.fixture;

import commerce.command.Users;
import test.commerce.ganerator.DataGenerator;

public class UserFixture {

    public static Users createUser() {
        return Users.builder()
            .name(DataGenerator.randomName())
            .id("test")
            .password(DataGenerator.randomPassword())
            .build();
    }

    public static Users createUser(String name, String password) {
        return Users.builder()
            .name(name)
            .id("test")
            .password(password)
            .build();
    }
}

이제 테스트 코드를 아래와 같이 돌리면

@Test
void 유저_생성(){
    // Arrange
    Users users = UserFixture.createUser();

    // Act
    ResponseEntity<Users> response = userDSL.회원생성(users);

    // Assert
    assertThat(response.getStatusCode().value()).isEqualTo(200);
    assertThat(response.getBody()).isNotNull();
    assertThat(response.getBody()).isNotNull();
}

정상으로 돌아가는것을 볼 수 있다.

그리고 @BeforeEach 와 @BeforeAll 에 대해서 알아보자!

두개의 어노테이션은 테스트 실행 전에 준비 작업 할 때 사용하는 어노테이션이다.

실행 시점과 특징은 아래와 같다!

어노테이션	실행 시점	특징
@BeforeEach	각 테스트 메서드 실행 전에 매번 실행	테스트마다 초기 상태를 만들어줌
@BeforeAll	테스트 클래스 시작 전에 딱 한 번 실행	공통 리소스 초기화 (DB 연결 등)

이제 예시를 통해 알아보자!

@BeforeEach 는 매번 실행하는 코드로 매번 계산해야하는 코드가 있다면 아래와 같이 setup 메소드에 어노테이션을 붙인다.

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

class CalculatorTest {

    Calculator calculator;

    @BeforeEach
    void setUp() {
        calculator = new Calculator();
        System.out.println("BeforeEach 실행");
    }

    @Test
    void addTest() {
        System.out.println("addTest 실행");
    }

    @Test
    void subtractTest() {
        System.out.println("subtractTest 실행");
    }
}

실행을 하면 아래와 같이 로그가 찍히며 테스트 케이스 실행 될때 마다 실행 되는부분을 확인 할 수 있다.

BeforeEach 실행
addTest 실행

BeforeEach 실행
subtractTest 실행

이제 @BeforeAll 에 대해서 알아보자!

만약 DB 연결을 하는 코드 정의가 필요하다고 해보자..! 우선 BeforeAll 어노테이션을 붙이기 위해서는 static 메소드로 정의해야 실행 가능하다.

static 으로 정의 하지 않을시 아래와 같이 빨간줄이 뜨는것을 볼 수 있다.

아래와 같이 DB 연결 코드는 @BeforeAll 로 한번 실행 되도록 하고 setup 은 매번 셋팅 되도록 @BeforeEach 로 실행한다면

class UserServiceTest {

    static Database db;
    UserService userService;

    @BeforeAll
    static void initDB() {
        db = new Database(); // DB 연결
        System.out.println("BeforeAll 실행");
    }

    @BeforeEach
    void setUp() {
        userService = new UserService(db); // 테스트용 객체 생성
        System.out.println("BeforeEach 실행");
    }
    
    @Test
    void addTest() {
        System.out.println("addTest 실행");
    }

    @Test
    void subtractTest() {
        System.out.println("subtractTest 실행");
    }
}

아래와 같이 로그가 찍히는것을 볼 수 있다.

BeforeAll 실행

BeforeEach 실행
addTest 실행

BeforeEach 실행
subtractTest 실행

끝!

[TDD] SpringBoot 를 통한 TDD 손쉬운 작성 - 03) 테스트 코드 품질 높이기! - 01

코린이s — Mon, 2 Mar 2026 08:15:12 +0900

실무에서 테스트 코드를 작성하다 보면 반복 되는 코드가 많거나 가독성이 떨어지는 경우가 많다.
이런 테스트 코드의 품질을 높이기 위한 방법이 있다!
아래 방법을 통해 개선 작업을 진행해보자!
1) assertThat().satisfies()
satisfies 를 사용하면 아래와 같은 경우 사용 가능하다.

해당 여러 검증 코드를 하나로 묶을 때
자유롭게 검증 코드를 작성하기 위해

예시를 통해 알아보자!
우선 간단한 회원 가입 로직을 만들어보자!
간단한 API 를 만들기 위해 필요한 라이브러리는 아래와 같다.

dependencies {
    implementation("org.springframework.boot:spring-boot-starter-web")
    implementation("org.springframework.boot:spring-boot-starter-data-jpa")
    compileOnly("org.projectlombok:lombok")
    runtimeOnly("com.h2database:h2")
    annotationProcessor("org.projectlombok:lombok")
    testImplementation("org.springframework.boot:spring-boot-starter-test")
    testRuntimeOnly("org.junit.platform:junit-platform-launcher")
}

간단한 유저 엔티티를 정의 하고

@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor
@Builder
@Getter
@Entity
public class Users {
    @Id
    String id;
    String name;
    String password;
}

Repository 를 만들자

@Repository
public interface UserRespository extends JpaRepository<Users, Integer> {
}

그리고 '/users' 를 post 로 호출시 데이터가 저장 될 수 있도록 controller 에 정의 한다. (예시기에 contoller 에 로직을 작성한다.)

@RestController
public class TestController {

    @Autowired
    UserRespository userRespository;

    @PostMapping("/users")
    public ResponseEntity<Users> user(@RequestBody Users users) {

        Users response = userRespository.save(users);

        return ResponseEntity.ok().body(response);
    }
}

이제 검증 로직을 작성해보자.
여러 검증 코드를 하나로 묶기전에 아래와 같은 코드가 될 수 있다.

@Test
    void 비밀번호검증(
        @Autowired TestRestTemplate client
    ) {
        // Arrange
        Users users = Users.builder()
            .name("코린이")
            .id("test")
            .password("test")
            .build();

        // Act
        ResponseEntity<Users> response = client.postForEntity("/users", users, Users.class);

        // Assert
        assertThat(response.getStatusCode().value()).isEqualTo(200);
        assertThat(response.getBody()).isNotNull();
        assertThat(response.getBody().getName()).isEqualTo("코린이");

    }

해당 코드를 가독성을 위해 같은 코드 끼리 묶어 보자!

@Test
    void 비밀번호검증(
        @Autowired TestRestTemplate client
    ) {
        // Arrange
        Users users = Users.builder()
            .name("코린이")
            .id("test")
            .password("test")
            .build();

        // Act
        ResponseEntity<Users> response = client.postForEntity("/users", users, Users.class);

        // Assert
        assertThat(response.getStatusCode().value()).isEqualTo(200);
        assertThat(response).satisfies(res -> {
            assertThat(res.getBody()).isNotNull();
            assertThat(res.getBody().getName()).isEqualTo("코린이");
        });
    }

상태코드 검증은 따로 두고, body 검증은 하나로 묶어서 표현했다.
이를 통해 상태코드는 200 이여야 하고 ,, body 내용 관련 정책은 이게 맞아야 하는구나 한눈에 알 수 있다.
예시는 복잡하지 않으니 크게 느껴지지 않으나 많은 정책이 들어간다고 하면 관련 있는것끼리 묶었을때 가독성이 훨씬 좋아 질 것이다.
satisfies 는 내부에 자유롭게 코드를 작성할 수 있으므로, 아래와 같이 검증 관련 메소드를 따로 빼서 사용 가능하다.

@Test
    void 비밀번호검증(
        @Autowired TestRestTemplate client
    ) {
        // Arrange
        Users users = Users.builder()
            .name("코린이")
            .id("test")
            .password("test")
            .build();

        // Act
        ResponseEntity<Users> response = client.postForEntity("/users", users, Users.class);

        // Assert
        assertThat(response.getStatusCode().value()).isEqualTo(200);
        assertThat(response.getBody()).satisfies(this::assertName);
        assertThat(response.getBody()).satisfies(this::assertPassword);
    }

    private void assertName(Users users) {
        assertThat(users.getName()).isNotNull();
        assertThat(users.getName()).isEqualTo("코린이");
    }
    
    private void assertPassword(Users users) {
        assertThat(users.getPassword()).isNotNull();
        assertThat(users.getPassword()).matches( p -> p.length() >= 4);
    }

보기 좋게 칼럼 별 검증 로직은 따로 메소드로 빼서 표현하게 된다면 이게 어떤 코드구나 네이밍으로 정리되어 가독성이 좋다.
2) 테스트 클래스 어노테이션 추상화
이제 어노테이션으로 테스트 클래스의 반복 되는 부분을 줄여 보자!
우리는 보통 테스트 코드를 작성할때,
테스트로 돌아가기 위한 @SpringBootTest 정의,
테스트 코드에서 repository 로 데이터 조작시 원복을 위한 @Transactional,
특정 환경으로 돌아가게 하기 위한 @ActiveProfiles 를 작성한다.

@Transactional
@SpringBootTest(
    classes = CommerceApiApp.class,
    webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT
)
@ActiveProfiles("test")

이러한 코드는 테스트 코드를 작성할때마다 필요하므로 해당 코드를 어노테이션으로 만들어 재사용 해보자!
어노테이션은 @Retention 과 @Target 어노테이션으로 만들수 있다.
Retention 은 언제까지 해당 정보를 유지 할지 결정 하는것으로
Source 는 컴파일 후 사라지고, Class 는 class 파일로 존재, Runtion 으로 하면 실행중에도 유지 되도록 할 수 있다.
여기서는 실행중에도 동작 해야 하므로 Runtime 으로 설정 한다.
다른 경우는 사실 어떤 경우에 사용하는지 감이 안잡힌다.. 나중에 어노테이션을 만들 경우가 있을경우 사용하면서 익히도록 해보자.
그리고 @Target 의 경우 이 어노테이션을 어디에 붙일지 이다.
- 클래스면 type
- 메서드 : method
- field : 필드
- parameter : 파라미터
우리는 테스트 클래스 상단에 붙일 예정이니 type으로 지정 한다.
이제 위에 결정한대로 아래와 같이 UserServiceTest 어노테이션을 만들어 보자!

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@Transactional
@SpringBootTest(
    classes = CommerceApiApp.class,
    webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT
)
@ActiveProfiles("test")
public @interface UserServiceTest {
}

이제 Test 클래스에 가서 @UserServiceTest 어노테이션을 붙여 본다.

@UserServiceTest
@DisplayName("POST /user")
public class POST_specs {

실행해보면 정상적으로 코드가 돌아가는것을 볼 수 있다.

3) @MethodSource
이제 우리가 전 시간에 배운 @ParameterizedTest 와 @ValueSource 를 보자!

@ParameterizedTest
    @ValueSource(strings = {
        "1243",
        "*&^%",
        "test1234"
    })

@ValueSource 에 테스트 변수를 여러 곳에서 사용한다면 한번에 해당 소스를 정의해두고 재 사용하면 코드가 간단해진다.
그렇게 처리 할 수 있는것이 MethodSource 이다!
예시를 통해 알아보자!
@ValuseSource 에 있던 패스워드를 아래와 같이 UserSource 라는 클래스를 만들어
VaildPasswords 라는 static 메서드를 만든다. (@methodSource 에는 static 만 허용 한다.)

public class UserSource {
    static Stream<Arguments> validPasswords () {
        return Stream.of(
            Arguments.of("1243", false),
            Arguments.of("*&^%", false),
            Arguments.of("test1234", true)
        );
    }
}

첫번째 매개 변수에는 패스워드를 넣고 두번째는 기대하는 검증 결과를 적는다.
이제 테스트 케이스로 가서 아래와 같이 경로를 적고 # 뒤에 메소드 명을 적어두고, 매개 변수로 정의한 값이 넘어 가도록 password 와 expected 를 받는다.

    @ParameterizedTest
    @MethodSource("test.commerce.sources.UserSource#validPasswords")
    void id_잘못된파라미터_400_리턴(String password, boolean expected, @Autowired TestRestTemplate client) {

이제 테스트 코드를 실행하면 아래와 같이 2개의 파라미터가 정상적으로 넘어가는것을 볼 수 있다.

해당 방식을 쓰면 여러 테스트 코드에서 동일하게 사용하는 케이스를 미리 source 로 정의하여
반복하게 사용하는곳에 재 사용하며 코드를 간결하게 작성 할 수 있다.

[TDD] SpringBoot 를 통한 TDD 손쉬운 작성 - 02) TDD 작성 해보기!

코린이s — Sun, 1 Mar 2026 17:25:49 +0900

TDD 를 예시를 통해 알아보자 !

우리는 회원관리 시스템을 만든다고 하자! 그 중 유저 생성 API 로 TDD 를 수행해보자!

1) 테스트 시나리오 작성

- 유저 생성 API 호출하여 정상 처리시 상태 코드 200을 리턴한다.

- 유저 생성 API 호출시 이름, ID, 패스워드 정보를 전달 받으며 이 중 하나라도 없다면 상태 코드 400을 리턴한다.

- 이름 파라미터는 세자리이며 맞지 않을 경우 상태코드 400을 리턴한다.

- ID 파라미터는 영어로만 이뤄지며 맞지 않을 경우 상태코드 400을 리턴한다.

- 패스워드 파라미터는 영문자 숫자로 이뤄지며 최소 4자리 이상이여야 하며 맞지 않을 경우 상태코드 400을 리턴한다.

2) API 설계 문서화

요청 정보

메서드 : POST
경로 : /user
헤더 : Content-Type: application/json
본문 :

User {
  name: string,
  id : string,
  password: string
}

성공 응답

상태 코드 : 200 Ok

정책

name 파라미터는 3자 이여야 한다.
id 파라미터는 영어로만 이뤄져야 한다.
password 파라미터는 영문 또는 숫자로 구성되며 4자리 이상이여야 한다.

테스트 항목

정상 요청 → 200 반환
파라미터 없음 → 400 반환
형식 오류 → 400 반환

3) 테스트 코드 작성

AAA 패턴

테스트 코드는 보통 Arrange - Act - Assert(AAA) 패턴으로 작성한다.

명칭	내용
Arrange(구성)	테스트용 데이터 준비
Act(실행)	테스트 대상 실행
Assert(검증)	결과 검증

우선 요청 파라미터를 담을 Recode 를 만든다!

public record User(
    String name,
    String id,
    String password
) {
}

그리고 테스트 시나리오대로 테스트 케이스를 만든다.

우선 첫번째 시나리오인 성공시 200을 리턴하는 테스트 케이스를 작성 하였다.

// [1] SpringBootTest
@SpringBootTest(
    classes = [테스트대상클래스명].class,
    webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT
)
// [2] DisplayName
@DisplayName("POST /user")
public class POST_specs {

// [3] Test
    @Test
    void 성공시_200_리턴(
        @Autowired TestRestTemplate client
    ) {
        // [4] Arrange
        User user = new User(
            "corin",
            "test",
            "test"
        );

        // [5] Act
        ResponseEntity<Void> response = client.postForEntity(
            "/user",
            user,
            Void.class
        );

        // [6] Assert
        assertThat(response.getStatusCode().value()).isEqualTo(200);
    }
}

하나씩 보자!

[1] @SpringBootTest 어노테이션

해당 어노테이션은 Spring Boot 환경에서 테스트를 실행하도록 설정하는 부분이다.

- classes 옵션

미지정 시 전체 빈 스캔하게 되어 모든 컨텍스트를 스캔, 빈 생성 하기에 로딩 시간을 줄이고 싶다면

테스트 진행 대상만 클래스를 지정하여 필요한 빈만 로딩하여 테스트 속도를 향상 할 수 있다.

- webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT 옵션

테스트 실행시 랜덤 포트로 실행 되도록 하여 테스트 실행시 사용중인 포트 이외 포트를 사용하여 테스트 실행 오류를 방지 한다.

[2] @DisplayName 어노테이션

테스트 결과 화면에 표시되는 이름을 설정 하는 어노테이션으로 HTTP 메서드명, API 주소를 표기하여 어떤 테스트 인지 알 수 있도록 한다.

[3] @Test 어노테이션

메서드에 @Test 를 붙여 테스트 메서드로 동작하도록 한다.

[4] TestRestTemplate 활용

Spring Boot Test에서는 Http 요청 관련 테스트를 위한 TestRestTemplate을 제공한다. RestTemplate 가 아닌 Test 에서 제공하는 클래스를 이용하면 테스트에 용이하게 정의 되어있어 (예 : 500 에러 시 예외 대신 응답 반환) Http 관련 테스트 진행시 해당 클래스를 이용한다.

[5] Arrange 단계

정의 단계로, API 요청 파라미터인 User를 정의 한다.

[6] Act 단계

실행 단계로, TestRestTemplate 를 이용하여 /user API 로 Post 호출 하며 실행 결과를 얻어온다.

[7] Assert 단계

검증 단계로, 보통 SpringBootTest 에 포함 되어 있는 AssertJ 라이브러리를 사용하여 검증을 코드로 구현한다.

아래 코드는 http 상태코드를 받아 200이면 테스트 검증 통과 처리 하며 아니라면 실패 처리 한다.

assertThat(response.getStatusCode().value()).isEqualTo(200);

해당 테스트 실행 결과를 보자 !!

아래와 같이 왼쪽 박스 부분을 보면, DisplayName 에 정의한 내용과 메서드 명이 표기 되어 어떤 테스트인지 한눈에 알 수 있다.

그리고 테스트 결과는 '초록색'이 아닌 '노란색 X 박스'로 표기 되어 검증 실패임을 알 수 있고,

그 원인을 오른쪽 박스의 오류 로그를 보면,

테스트 코드로 작성한 '상태 코드 200' 이기대한 값이지만 404로 나와 검증 실패 되었음을 알 수 있다!

이렇게 켄트 백의 TDD 중 Red 부분 작성이 완료 되었다!

이제 Green 단계를 진행해보자!

해당 코드가 통과 할 수 있는 코드를 작성하면 된다. 아래 조건을 만족하면 200을 리턴하면 된다.

name 파라미터는 3자 이여야 한다.
id 파라미터는 영어로만 이뤄져야 한다.
password 파라미터는 영문 또는 숫자로 구성되며 4자리 이상이여야 한다.

이제 200이 나올 수 있도록 작성을 해보자!

@PostMapping("/user")
    public ResponseEntity<?> user(@RequestBody User user) {
        if (user.name().length() == 3 && user.id().matches("^[a-zA-Z]*$") && user.password().matches("^[a-zA-Z0-9]{4,}$")) {
            return ResponseEntity.ok().build();
        }
        return ResponseEntity.badRequest().build();
    }

돌려보면 정상적으로 패스 한다.

여기까지 하면 Green 단계 한 사이클을 완료한 것이다.

이제 다음 케이스인 '파라미터 없음 → 400 반환'를 만들어 나머지 Red + Green 단계 진행 해보자!

@Test
    void 파라미터없을시_400_리턴(@Autowired TestRestTemplate client) {

        // Arrange
        User user = new User(
            null,
            null,
            null
        );

        // Act
        ResponseEntity<Void> response = client.postForEntity(
            "/user",
            user,
            Void.class
        );

        // Assert
        assertThat(response.getStatusCode().value()).isEqualTo(400);
    }

이렇게 해서 돌리게 되면 실패하게 되고

파라미터 값이 없을경우 400이 나오도록 코드를 추가한다.

@PostMapping("/user")
    public ResponseEntity<?> user(@RequestBody User user) {
        if(user.name() == null || user.id() == null || user.password() == null) {
            return ResponseEntity.badRequest().build();
        }

그리고 돌려보면 테스트 정상 통과 한다!

그런데 여기서 잘못된 파라미터가 넘어올시 400 리턴되는 케이스가 필요하다는 생각이 들었다.

이러한 테스트 케이스 추가하는 작업이 Green 단계에서 이뤄진다. 계속해서 체크하며 좋은 테스트 케이스를 만든다!

그럼 실습을 위해 id 파라미터에 대해서만 테스트 케이스 추가 작업 해보도록 한다.

id 파라미터는 영어만 받기로 정했기에 '숫자, 특수문자, 영어+숫자' 를 호출했을때 400이 나오는 케이스를 추가한다.

하나의 테스트 케이스에 특정 값만 변경해서 호출하고 싶으면 '@ParameterizedTest' 와 '@ValueSource' 어노테이션을 이용하여 반복 테스트 가능하다.

id 파라미터 예시로 보자!

@ParameterizedTest
    @ValueSource(strings = {
        "1243",
        "*&^%",
        "test1234"
    })
    void id_잘못된파라미터_400_리턴(String id, @Autowired TestRestTemplate client) {

        // Arrange
        User user = new User(
            "코린이",
            id,
            "test"
        );

        // Act
        ResponseEntity<Void> response = client.postForEntity("/user", user, Void.class);

        // Assert
        assertThat(response.getStatusCode().value()).isEqualTo(400);
    }

@ValueSource 로 변경 하여 테스트 하고자 하는 값을 나열하고 테스트 매개변수 id 로 받으면 해당 값이 변경되며 호출 된다.

결과는 아래와 같으며 모든 케이스 통과 하였다!

이제 Refactor 단계를 진행해보자!

작성한 코드를 보면 보기 어렵게 되어있고 좋지 않은 코드이다.

이렇게 코드를 개선 하는것이 Refactor 과정이다! 아래 변경을 해보자!

@PostMapping("/user")
    public ResponseEntity<?> user(@RequestBody User user) {
        if(user.name() == null || user.id() == null || user.password() == null) {
            return ResponseEntity.badRequest().build();
        }

        if (user.name().length() == 3 && user.id().matches("^[a-zA-Z]*$") && user.password().matches("^[a-zA-Z0-9]{4,}$")) {
            return ResponseEntity.ok().build();
        }

        return ResponseEntity.badRequest().build();
    }

코드를 가독성 좋게 기능을 메서드로 뺐다.

@PostMapping("/user")
    public ResponseEntity<Void> user(@RequestBody User user) {

        if (hasEmptyParam(user)) {
            return ResponseEntity.badRequest().build();
        }

        if (!isValidUser(user)) {
            return ResponseEntity.badRequest().build();
        }

        return ResponseEntity.ok().build();
    }

    /** null 체크 */
    private boolean hasEmptyParam(User user) {
        return user.name() == null
            || user.id() == null
            || user.password() == null;
    }

    /** 유효성 검사 */
    private boolean isValidUser(User user) {
        return isValidName(user.name())
            && isValidId(user.id())
            && isValidPassword(user.password());
    }

    private boolean isValidName(String name) {
        return name.length() == 3;
    }

    private boolean isValidId(String id) {
        return id.matches("^[a-zA-Z]+$");
    }

    private boolean isValidPassword(String password) {
        return password.matches("^[a-zA-Z0-9]{4,}$");
    }

이제 테스트 케이스 모두 돌려서 모든 케이스를 통과하는지 최종 점검 한다.

모두 통과 하였으며 TDD 마지막 단계까지 완료 하였다!

최종 정리 !

지금까지 TDD와 테스트 작성 방법을 정리해 보면 다음과 같다고 한다.

TDD는 테스트 먼저 작성하고 기능 개발 하며 코드 개선하는 방식이다.
Red → Green → Refactor 구조로 반복된다.
실무에서는 하이브리드 TDD를 많이 사용한다.
테스트 코드 작성시에는 AAA 패턴으로 작성 한다.

테스트는 귀찮은 작업이 아니라,

미래의 나를 지켜주는 보험이라고 한다.

꾸준히 연습하면서 TDD에 익숙해져 보자!

* 참고

# Java 에서 record란 무엇인가?

record는 Java 17부터 도입된 문법으로 불변 데이터를 정의하는 VO 와 같은 객체를 정의 할때 '보일러 플레이트 코드'를 줄여준다.

특징

불변 객체 (필드에 final 이 붙는다.)
getter, 생성자(모든 변수 정의된 생성자), toString 자동 생성

보일러 플레이트란?

반복적으로 작성하는 코드를 의미한다. (같은 내용을 인쇄하는 변경 불가능한 판의 이름이 보일러 플레이트다.)
VO 같은 클래스에 자주 등장한다고 한다.

[TDD] SpringBoot 를 통한 TDD 손쉬운 작성 - 01) TDD 란 ?

코린이s — Mon, 16 Feb 2026 22:16:20 +0900

테스트 주도 개발(TDD) 개념부터 실무 활용까지 알아보자!

개발을 하다 보면 “테스트는 나중에 하지 뭐…”라고 생각하는 경우가 많다고 한다.

하지만 안정적인 서비스를 만들기 위해서는 테스트가 매우 중요하다.

이때 등장하는 개념이 바로 TDD(Test-Driven Development) 다!

지금부터 하나씩 알아보자!

TDD(Test-Driven Development)란?

TDD는 테스트 시나리오대로 코드를 먼저 작성한 뒤,
그 테스트를 통과시키기 위해 코드를 만들고,
이후 리팩토링을 통해 계속해서 개선하는 개발 방법이라고 한다.

이 개념은 켄트 벡이 정립한 개발 방법론으로 알려져 있다고 한다.

TDD의 3단계

TDD는 크게 3단계로 반복된다!

간단하게 설명하면 아래와 같다!

Red → 실패하는 테스트 작성
Green → 최소한으로 통과
Refactor → 구조 개선

각각의 과정에 대한 내용을 적어보면 아래와 같이 진행한다.

이름	내용
Red 단계	테스트 시나리오를 작성한다. 반드시 실패하는 테스트를 만든다. 아직 기능이 없으므로 테스트는 실패 상태라고 한다.
Green 단계	테스트를 통과할 수 있는 최소한의 코드를 작성한다. 빠진 테스트 케이스가 있다면 추가한다. 목표는 “일단 통과”라고 한다.
Refactor 단계	코드 개선 및 구조 리팩토링을 진행한다. 이 과정을 통해 설계를 개선한다.

이 모든 테스트 케이스가 통과되면 테스트 작성이 종료 된다!

실무에서는 하이브리드 TDD !

이론적으로는 테스트부터 작성하는 것이 이상적이라고 한다.
하지만 실무에서는 “일단 돌아가게부터 만들어 주세요…” 라는 요구가 많을 수 있다.

이런 상황 때문에 테스트를 먼저 만들기 어려운 경우가 많다.

그래서 실무에서는 하이브리드 TDD 방식을 많이 사용한다고 한다.

기능 먼저 구현
이후 테스트 코드 작성
TDD 방식으로 보완

TDD 단위 테스트

하나의 기능만 정확히 테스트하는것이 '단위 테스트'이다.

여기서 통합 테스트와 다르게 단위 테스트는

하나의 클래스/메서드만 테스트하는 것으로 외부 의존성 전부 Mock / Stub 처리 한다.

TDD의 80~90%는 단위 테스트로 진행하며, 각각의 단위 테스트는 서로 영향 주지 않게 작성하며 이를 '테스트 격리' 라고 한다.

이러한 테스트 코드들이 있기에 리펙토리를 해도 테스트를 진행하면 되기에 기능이 안전하다고 생각할 수 있다.

이러한 특징을 '리팩토링 안전망' 이라고 부른다!

여기서 단위 테스트할때 의존성의 Mock[목], Stub[스텁] 처리 한다고 하는데 해당 개념이 무엇인지 알아보자!

Mock과 Stub은 모두 테스트에서 실제 DB, API, 메일 서버 대신 사용하는 가짜 객체다.

이를 사용하는 목적은 아래와 같다!

✔️ 테스트를 빠르게
✔️ 테스트를 안정적으로
✔️ 외부 환경에 의존하지 않게

이제 가짜 객체인 Mock Stub 을 어떤 상황에 쓰는지 알아보자!

Stub 은 값을 대신 돌려주는 객체로 미리 정해둔 값만 반환하는 역할을 한다.

아래와 같이 적으면 userRepo 에서 kim 값을 찾으면 kim 인 User 객체를 반환하도록 모의로 셋팅 하는것이다.

when(userRepo.find("kim"))
    .thenReturn(new User("kim"));

Mock은 행동을 검증하는 객체로 메서드가 호출되었는지 자체를 검증한다.

예를 들어 “회원가입하면 메일이 반드시 발송되어야 한다” 를 검증한다고 해보자!

아래와 같이 service.register 을 하면 mailService 에서 해당 이메일로 메일이 가도록 구현 되어있는지 로직만 검증 하는것이다.

@Mock
MailService mailService;  // 가짜

@InjectMocks
UserService service;       // mailService가 service에 주입됨

User user = new User("kim", "a@test.com");

service.register(user);

verify(mailService).send("a@test.com");

우선 개념만 간단하게 알아봐서 사실 실제 작성해보지 않으면 모르겠다..!

다음 시간에는 실습을 통해 차근차근 TDD에 대해서 알아보자!

[코테] 재귀함수

코린이s — Sun, 20 Apr 2025 18:22:14 +0900

재귀함수에 대해서 알아보자!

재귀함수란, 자기 자신을 다시 호출하는 함수를 말한다.
말 그대로, 함수가 자기 자신을 반복적으로 부르는 구조라고 할 수 있다!

재귀를 사용하면 코드를 간결하게 표현할 수 있고,
특히 반복적인 구조나 문제를 잘게 쪼개는 상황에서 유용하게 쓰인다.

재귀함수는 언제 고려해야할까?

재귀함수는 다음과 같은 상황에서 고려해볼 수 있다

반복적인 계산 구조일 때
탐색 범위를 계속 줄여야 할 때

재귀함수의 핵심: 탈출 조건!

재귀함수를 사용할 때 가장 중요한 건 탈출 조건이다!
자기 자신을 계속 부르다 보면 무한 루프에 빠질 수 있기 때문에,
어디선가 반드시 멈춰야 한다.
이걸 탈출 조건이라고 한다.

팩토리얼 예제로 재귀를 이해해보자!

팩토리얼은 1부터 N까지의 정수를 모두 곱한 값을 말한다.
3!이라면 이렇게 계산된다:

3! = 3 × 2 × 1 = 6

연산 하는 방법을 수학적으로 표현하면 아래와 같다!

N! = N × (N-1) × (N-2) ... × 1

탐색 범위가 작아지며 반복적인 구조를 가지고 있기에 재귀로 풀면 된다.

재귀에 필요한 정보인 재귀 호출 값, 탈출 조건을 지정해야하며 재귀 호출값은 탐색범위를 줄인 데이터를 넘겨 범위를 줄여 탐색 한다.

재귀 호출 값 : N - 1
→ 한 단계 작아진 데이터로 나를 다시 호출한다.
탈출 조건 : N == 1
→ 더 이상 곱할 게 없을 때 멈춘다.

이를 바탕으로 코드를 작성하면 아래와 같다.

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello World!");
        System.out.println("TEST :: " + solution(3));
    }

    public static int solution(int n) {
        if (n == 1) return 1;
        return n * solution(n - 1);
    }
}

테스트 해보면 3! 인 6이 나오는것을 확인할 수 있다.

회문 예제로 재귀를 이해해보자!

회문이란, 예를 들어 "abcba"처럼
앞에서 읽든, 뒤에서 읽든 똑같은 문자열을 말한다.

쉽게 말해, 종이에 적어놓고 반으로 접었을 때
왼쪽과 오른쪽이 똑같이 생긴 문자열이라고 생각하면 된다!

회문을 어떻게 처리할지 생각해보면,

양 끝 문자를 비교해서 같으면 → 남은 안쪽 문자열도 회문인지 확인해보자!
이렇게 점점 문자열을 줄여가다 보면 → 결국 비교할 게 없어지거나, 다르거나 중 하나가 된다.

즉, 문자열 양쪽을 잘라가며 반복 확인하는 구조다.
바로 이런 반복적인 패턴과 탐색 범위가 줄어드는 재귀에 딱 맞는 상황이다!

문제 풀기 앞서 재귀에 필요한 재귀 호출값과 탈출 조건을 정리하면 아래와 같다.

재귀 호출 값 : s.substring(1, s.length() - 1)
→ 맨 앞과 맨 뒤를 제거한 문자열을 넘긴다.
탈출 조건 :
- 양 끝이 다르면 return false;→ 더 볼 필요 없이 회문이 아니다
- 문자열의 길이가 0 또는 1이면 return true;
  → 더 비교할 문자가 없으니 회문이다

이를 코드로 나타내면 아래와 같다.

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello World!");
        System.out.println("TEST :: " + solution("abcba"));
    }

    public static boolean solution(String s) {
        if (s.charAt(0) != s.charAt(s.length() - 1)) return false;
        if (s.length() <= 1) return true;
        return solution(s.substring(1, s.length() - 1));
    }
}

위 코드 돌려보면 abcba는 앞으로 읽어도 abcba 뒤로 읽어도 abcab 이니 회문으로 true 가 나온다!

끝!

[코테] 이진 탐색

코린이s — Sun, 20 Apr 2025 14:57:32 +0900

탐색에 대해서 알아보자!

데이터 속에서 원하는 값을 찾는 대표적인 방법에는
순차 탐색(Sequential search)과 이진 탐색(Binary search)이라는 방식이 있다.
이 둘은 어떤 차이가 있을까? 그리고 이진 탐색은 왜 더 빠르다고 할까?
지금부터 함께 알아보자!

순차 탐색(Sequential search)이란?

순차 탐색은 말 그대로 데이터를 앞에서부터 하나씩 차례대로 확인해보는 방법이다.

리스트의 첫 번째 인덱스부터 시작해서,
찾고자 하는 값이 나올 때까지 계속 다음 값을 확인해나간다.

즉, 모든 데이터를 순서대로 검사하는 방식이라고 할 수 있다!

✅ 시간 복잡도는?

O(N)
데이터가 100개 있다면, 최악의 경우 100번을 다 확인해야 한다.
데이터가 많아질수록 시간이 오래 걸리게 된다.

이진 탐색(Binary search)이란?

이진 탐색은 정렬된 데이터에서만 사용할 수 있는 탐색 방법이다.
리스트가 오름차순으로 정렬되어 있다는 조건이 필요하기에 처음에 배열을 정렬 하고 탐색한다.

탐색 방식을 알아보자!

리스트의 가운데 값을 확인해본다.
찾고자 하는 값이 가운데 값보다 작은지, 큰지를 비교한다.
작다면 왼쪽 절반만 다시 탐색
크다면 오른쪽 절반만 다시 탐색
이렇게 범위를 반씩 줄여가며 반복해서 값을 찾는 방식이다.

상세하게 알아본다면..!

먼저 최소 인덱스(min) 는 0, 최대 인덱스(max)는 배열 크기 - 1 로 셋팅 한다.
중간 인덱스(mid)는 (min + max) / 2 값을 내림해서 정수값이 나오도록 구한다.
중간값 = 리스트[mid]

그리고 찾고자 하는 값과 중간값을 비교한다.

찾는 값 < 중간값 → 최대 인덱스 = mid - 1
찾는 값 > 중간값 → 최소 인덱스 = mid + 1
찾는 값 == 중간값 → 값을 찾게 된다!

이 과정을 찾을 때까지 반복하면 된다.

✅ 시간 복잡도는?

O(log(N))
데이터가 많아도 탐색 시간이 급격히 줄어든다!
예를 들어 1024개의 데이터가 있으면, 최대 10번 안에 찾을 수 있다.

순차 탐색은 순차적으로 인덱스 0부터 찾는값이 나올때까지 찾는다.

이진 탐색은 데이터 오름차순으로 정렬후 가운데 값을 찾고자 하는 값과 비교하여 업/다운으로 찾는다.

작은 데이터에서는 순차 탐색도 충분히 괜찮지만,
데이터의 양이 많아질수록 이진 탐색이 훨씬 더 효율적이라 데이터가 많고 정렬이 가능하다면 이진 탐색을 사용할것 같다!

정수 찾기로 탐색 익숙해지기!

이제 순차탐색과 이진 탐색의 개념을 알아 봤으니 문제를 직접 풀어보자!

정수 찾기 문제를 풀어보자! (링크 클릭시 프로그래머스로 이동!)

정수 리스트 num_list와 찾으려는 정수 n이 주어질 때, num_list안에 n이 있으면 1을 없으면 0을 return하도록 solution 함수를 완성해주세요.

순차 탐색으로 구현해보면 아래와 같이 구현해볼 수 있다!

public class Main {

    public static void main(String[] args) {
        int[] num_list = new int[5];
        num_list[0] = 15;
        num_list[1] = 98;
        num_list[2] = 23;
        num_list[3] = 2;
        num_list[4] = 15;
        System.out.println("TEST :: " + solution(num_list, 20));
    }

    public static int solution(int[] num_list, int n) {
        for (int num : num_list) {
            if (num == n) {
                return 1;
            }
        }
        return 0;
    }
}

코드를 돌려보면 배열에 20이 없으니 0 이 정상적으로 나오는것을 볼 수 있다.

값은 정상적으로 나오지만 num_list 크기가 크다면 위에 순차 탐색은 이진 탐색으로 구현한 코드보다 오랜 시간이 소요 될 것이다.

이를 이진탐색으로 구현해보자!

import java.util.Arrays;

public class Main {

    public static void main(String[] args) {
        int[] num_list = new int[5];
        num_list[0] = 15;
        num_list[1] = 98;
        num_list[2] = 23;
        num_list[3] = 2;
        num_list[4] = 15;
        System.out.println("TEST :: " + solution(num_list, 20));
    }

    public static int solution(int[] num_list, int n) {
        if (num_list == null || num_list.length == 0) {
            return 0;
        }
        Arrays.sort(num_list);
        int low = 0;
        int high = num_list.length - 1;
        while (low <= high) {
            int mid = (low + high) / 2;
            if (num_list[mid] == n) {
                return 1;
            }
            if (num_list[mid] < n) {
                low = mid + 1;
            }
            if (num_list[mid] > n) {
                low = mid - 1;
            }
        }
        return 0;
    }
}

이진 탐색으로 구현하면 코드는 길어지지만 성능적으로는 좋은 코드이다.

추가적으로 해당 문제를 아래와 같이 풀어 볼 수도 있다.

public static int solution(int[] num_list, int n) {
    return IntStream.of(num_list).anyMatch(v -> v == n) ? 1 : 0;
}

코드는 매우 간결해지지만 IntStream.of(...).anyMatch(...)의 경우 내부적으로 순차 탐색을 수행하기에 배열의 크기가 크다면 이진 탐색에 비해 느리므로 배열의 크기가 작거나 코드의 간결함이 중요한 경우에 사용하면 된다.

이와 같이 코드별로 장단점이 있으므로 상황에 맞게 코드를 구현하면 된다.

끝..!

[코테] 시간/공간 복잡도

코린이s — Sun, 13 Apr 2025 14:38:59 +0900

시간/공간 복잡도란?

시간 복잡도는 알고리즘이 실행되는데 걸리는 시간/사용되는 공간을 수학적으로 표현한 개념입니다. 입력 크기 N이 커질수록 얼마나 많은 연산이 수행되는지를 알려주기 때문에, 알고리즘의 성능 비교에 유용 합니다.

시간 복잡도 계산법

예제 코드로 살펴보기

아래 코드는 리스트 안에서 가장 큰 숫자를 찾는 간단한 함수입니다:

def find_max_num(array):
    for number in array:
        is_max_num = True
        for compare_number in array:
            if number < compare_number:
                is_max_num = False
        if is_max_num:
            return number

이 코드를 기준으로, 각 부분이 얼마나 많은 연산을 수행하는지 분석해보겠습니다.

안쪽의 is_max_num = False 까지 걸리는 시간

for number in array:
    for compare_number in array:
        if number < compare_number:
            is_max_num = False

array의 길이가 N이라고 할 때,
첫번째 for문은 N번 반복됩니다.
두번째 for문도 N번 반복됩니다.
반복 안에서는 조건문 if와 대입문 is_max_num = False가 각각 1번씩 실행되므로, 1 + 1 = 2번의 연산이 매 반복마다 일어납니다.

총 연산 수:
N * N * 2 = 2N^2

그 다음 if is_max_num: 의 시간

for number in array:
    if is_max_num:
        return number

이 부분은 바깥 루프가 한 번씩 돌 때마다 실행 가능성이 있으므로,
최대 N번 실행된다고 볼 수 있고, 조건문 하나만 있으니

총 연산 수:

N * 1

최종 시간 복잡도

앞서 계산한 두 개를 합치면:

2N^2 + N

하지만 시간 복잡도는 대략적인 성능 비교용이기 때문에, 가장 영향이 큰 항만 남기고 나머지는 생략합니다.

따라서 최종 시간 복잡도는:

여기서 잠깐!

가끔 시간 복잡도를 계산하다 보면, 다음과 같이 상수값이 나오는 경우가 있습니다.

예를 들어 어떤 알고리즘이 항상 정확히 26번의 연산만 수행된다고 해봅시다. 그러면 이 알고리즘의 시간 복잡도는 26이라고 말할 수 있겠지만 사실 시간 복잡도에서는 이런 상수값은 중요하지 않습니다.

시간 복잡도는 입력 크기 N이 커질수록 알고리즘의 성능이 어떻게 변하는지를 보는 것이지, 정확한 실행 횟수 자체를 따지는 게 아니기 때문입니다.

즉,

"26이나 1이나 결국은 항이 따로 없고 입력 크기에 따라 변하지 않기 때문에, 시간 복잡도는 "

️ 공간 복잡도 계산법

시간 복잡도와 함께 알고리즘을 평가할 때 꼭 함께 고려해야 할 것이 공간 복잡도입니다.

공간 복잡도는 문제를 해결하는 데 얼마나 많은 메모리(공간)를 사용하는지를 나타냅니다.
당연히 필요한 공간을 적게 쓸수록 더 효율적인 알고리즘이라고 볼 수 있습니다.

예제 코드로 살펴보기

이 코드를 기준으로 어떤 공간들이 사용되었는지 살펴보겠습니다.

def find_max_occurred_alphabet(string):
    alphabet_occurrence_array = [0] * 26

    for char in string:
        if not char.isalpha():
            continue
        arr_index = ord(char) - ord('a')
        alphabet_occurrence_array[arr_index] += 1

    max_occurrence = 0
    max_alphabet_index = 0
    for index in range(len(alphabet_occurrence_array)):
        alphabet_occurrence = alphabet_occurrence_array[index]
        if alphabet_occurrence > max_occurrence:
            max_occurrence = alphabet_occurrence
            max_alphabet_index = index

    return chr(max_alphabet_index + ord('a'))

사용된 메모리 분석

alphabet_occurrence_array → 26개의 공간 사용 (알파벳 개수)
arr_index → 1개
max_occurrence, max_alphabet_index, alphabet_occurrence → 각각 1개씩, 총 3개

전체 공간 사용량은

26 + 1 + 3 = 30 이 됩니다.

최종 공간 복잡도

이론적으로는 30이지만, 입력 크기와 무관하게 고정된 수만큼의 공간만 사용하는 경우, 공간 복잡도는 상수로 봅니다.

즉,

"입력에 따라 메모리 사용량이 늘어나지 않기 때문에, 이 알고리즘의 공간 복잡도는 1 입니다."

이처럼 시간 복잡도와 공간 복잡도를 함께 고려해서 계산하면, 보다 효율적이고 현실적인 알고리즘을 설계할 수 있습니다.

그렇다면 이 복잡도들을 어떻게 표기할까요?

점근 표기법

복잡도는 보통 수학적인 기호로 표현하는데, 이를 점근 표기법이라고 합니다.

가장 대표적인 표기법은 다음과 같습니다:

표기법설명

(빅 오)	최악의 경우에 필요한 연산량 또는 공간
(빅 오메가)	최선의 경우에 필요한 연산량 또는 공간

❗ 왜 빅오(Big-O) 표기법을 주로 사용할까?

현실에서는 입력값이 언제나 좋게 들어온다는 보장이 없기 때문입니다.

즉, 우리는 최악의 상황에서도 알고리즘이 어느 정도 성능을 유지할 수 있어야 하고, 이를 위해 빅오 표기법을 기준으로 평가합니다.

복잡도 표기 예시

복잡도를 점근 표기법으로 표현할 때는 다음과 같이 작성합니다:

시간 복잡도가 N^2이라면 →
공간 복잡도가 1이라면 → O(1)

이처럼 시간과 공간 복잡도는 각각 독립적으로 계산하고, 점근 표기법(Big-O)을 사용해 간단하게 표현합니다.

각 시간 복잡도는 위 그림과 같이 비교 할 수 있으며 이를 참고하여 다음 시간 부터 알고리즘을 풀어보도록 하자!