차근차근정확하게

# 테스트가 설계를 바꾸기 시작했다: TDD를 체험해보다

거북이의 기술블로그 — Sun, 23 Nov 2025 17:26:39 +0900

1편에서 이야기했듯, 나는 초기에 테스트를 잘못 이해한 방식으로 사용하고 있었다.
테스트에서 기능을 만들어보지만 실제 프로덕션 코드는 다시 처음부터 작성하는 구조였고,
테스트는 참고용 코드에 불과했다.

하지만, 이 시행착오를 겪은 덕분에, 테스트를 제대로 활용하는 방식,
즉 테스트 → 설계 → 프로덕션 코드 승격이라는 진짜 TDD적 흐름을 이해하게 되었다.

이 글에서는 내가 테스트를 활용하는 방식을 어떻게 바꿨고,
그 과정에서 어떤 설계 개선이 이루어졌는지 기록해보려고 한다.

# 테스트에서 시작하고, 설계로 이어지는 흐름을 만들다

예전처럼 테스트에서 기능을 만들고 프로덕션에서 처음부터 다시 만드는 대신,
나는 다음과 같은 흐름으로 개발을 진행하기 시작했다.

테스트에서 간단한 프로토타입을 작성하고 원하는 동작을 검증한다.
이 동작이 타당하다고 판단되면
테스트 안에서 만든 코드를 main으로 ‘승격’시키고,
해당 기능의 책임을 명확히 나눈다.
이후 @SpringBootTest 기반 DI 테스트로 리팩토링한다.

이 흐름을 사용하자,
테스트는 단순 검증 도구가 아니라 설계를 이끄는 도구가 되기 시작했다.

# 테스트 코드가 설계를 요구하기 시작했다

테스트를 작성하면 자연스럽게 이런 고민이 생긴다.

“이 메서드는 너무 많은 일을 하고 있지 않나?”
“여기 의존성은 분리해야 테스트하기 쉬울 것 같은데?”
“이 로직을 재사용하려면 별도 클래스로 빼는 게 맞겠다.”

즉, 테스트하기 어려운 코드는 설계가 잘못되었다는 신호였다.

아래는 실제로 내가 겪은 예시다.

Step 1) POJO 스타일로, 테스트 메서드 내부에서 ‘기능을 직접 구현’

아직 프로덕션 코드는 전혀 만들지 않은 상태.
테스트 메서드 안에서 내가 원하는 기능을 “그냥 작성해보는 단계”다.

@Test
void saveFile_basicPrototype() throws Exception {
    // POJO 스타일, 모든 로직이 여기 들어 있음
    File file = new File("test.txt");
    String content = "Hello";

    boolean result = false;
    try (FileWriter fw = new FileWriter(file)) {
        fw.write(content);
        result = true;
    } catch (Exception e) {
        result = false;
    }

    assertTrue(result);
}

테스트와 프로덕션을 나누지 않고, 기능을 하나의 테스트 내부에 전부 작성
일종의, "기능 프로토타입"

Step 2) 테스트 폴더 내에서 'Method로 1차 분리'

@Test
void saveFile_extractMethod() throws Exception {
    File file = new File("test.txt");
    String content = "Hello";

    boolean result = save(file, content);

    assertTrue(result);
}

private boolean save(File file, String content) {
    try (FileWriter fw = new FileWriter(file)) {
        fw.write(content);
        return true;
    } catch (Exception e) {
        return false;
    }
}

save()라는 메서드로 분리
아직 src/test/ 아래에 메서드 존재

Step 3) 책임을 가진 메서드를 'static 내부 클래스' 로 이동

@Test
void saveFile_withInnerClass() throws Exception {
    File file = new File("test.txt");

    FileStorage storage = new FileStorage();
    boolean result = storage.save(file, "Hello");

    assertTrue(result);
}

static class FileStorage {
    public boolean save(File file, String content) {
        try (FileWriter fw = new FileWriter(file)) {
            fw.write(content);
            return true;
        } catch (Exception e) {
            return false;
        }
    }
}

해당 단계가 가장 중요!

아직 프로덕션 코드로 승격하지 않음 (테스트 내부에 존재)
설계 개선을 위해서, 책임을 분리하는 단계
내부 클래스로 만들어서 객체를 new로 생성하여 이용

Step 4) 어느정도 구조가 자리를 잡으면, 프로덕션(main)코드로 승격

@Component
public class FileStorage {

    public boolean save(File file, String content) {
        try (FileWriter fw = new FileWriter(file)) {
            fw.write(content);
            return true;
        } catch (Exception e) {
            return false;
        }
    }
}

내부클래스 >> src/main/java/.../FileStorage.java로 이동
테스트에서 만든 내부클래스를 그대로 승격

Step 5) @SpringbootTest로 전환하여 DI 주입

@SpringBootTest
class FileStorageTest {

    @Autowired
    FileStorage fileStorage;

    @Test
    void givenFile_whenSave_thenSuccess() {
        // Given
        File file = new File("sample.txt");
        String content = "Sample";

        // When
        boolean result = fileStorage.save(file, content);

        // Then
        assertTrue(result);
    }
}

실제 프로덕션 코드를 주입받아서 검증하는 단위테스트가 된다
해당 테스트 코드는 프로타입이 아닌, 구현된 기능
Given - When - Then 구조만 남음 (깔끔한 테스트 코드 상태)

Step 6) 리펙토링 내성이 생기고, 생산성이 극적으로 증가

이제 FileStorage를 아래처럼 바꿔도 테스트가 보호해준다

저장 경로 분리
경로 전략 적용
네트워크 저장소로 전환
AWS S3로 변경
예외 정책 변경

그 어떤 구조 변경을 하더라도
테스트가 실패하지 않으면 “그대로 동작함”을 확신할 수 있다.

# 전체 흐름 다시 요약

단계	설명
1	테스트 메서드 내부에서 POJO 스타일로 기능 구현
2	메서드 분리 (테스트 폴더 내)
3	static 내부 클래스로 책임 분리
4	충분히 검증되면 프로덕션(main)으로 승격
5	@SpringBootTest + DI 기반 테스트로 재정비
6	안전한 리팩토링 가능, 생산성 향상

# 마무리

TDD에서는
1. 실패하는 테스트케이스 작성 (RED)
2. 성공하는 테스트 작성 (GREEN)
3. 리펙토링 하기 (REFECTOR)
를 하게되는데, RED작업을 많이 해보면 할수록 많은 예외사항을 처리할 수 있게된다.

많은 시간이 없다면, GREEN과 REFECTOR를 통해서 작성만 해두어도 나중에 많은 시간을 절약할 수 있고 리펙토링을 할때에도 겁먹지 않고 편안하게 할 수 있게된다.

하지만, 적응하는데에는 꽤나(?) 시간이 걸릴거같은 생각이든다...
자연스럽게 테스트케이스가 생각나지 않음....

※ 참고) 리펙토링 방법

▷ 켄트 백(Kent Beck)

단계	내용
1	이름 변경 (Rename)
2	매직넘버 제거
3	중복 제거
4	함수 추출 (Extract Method)
5	조건문 단순화
6	가드절 도입
7	부작용(side-effect) 제거
8	임시 변수 분리
9	책임 분리(Extract Class)
10	데이터 구조 개선(파라미터 객체)
11	조건문(if)을 반복문(loop) 기반 흐름으로 변환
12	반복문을 재귀(recursion)로 단순화
13	최종 단계: 재귀 제거 → 반복문으로 최적화 (거의 가지 않음)

#1 테스트 코드의 필요성을 절실히 느낀 이유...

거북이의 기술블로그 — Sun, 23 Nov 2025 16:52:36 +0900

테스트의 시작

개발자인 경우, 누구나 자신이 만든 기능이 정상 수행하는지 확인하는 절차를 가져야한다.
처음에는 만들면서 케이스들을 고려하여 구현하게되고, 마무리 단계에서 몇가지의 테스트들을 통해 직접 검증하는 방식으로 확인하였다.

하지만, 그런 검증 방식에서 당연히 되야한다고 생각했던것들에서 항상 1~2개씩 놓치게되어 다시 재배포하는 경우가 발생하게 되었다.
처음에는 QA단계에서 발생하여 다행이다라고 생각을 하게되었지만, 몇번 이런 일들이 생기게되니 점차 스스로도 신뢰하지 못하는 단계에 이르게 되었다.

그래서 테스트의 필요성을 깨닫고, 테스트를 시작하며 직면한 문제(?)에 대해서 기록해보고자 한다.

# 테스트를 해야겠다고 느낀 이유

1. 완성했다고 생각한 기능에서 계속되는 문제 발생

기능을 구현하고 "이제 동작하겠지"라고 생각했는데 실제로 테스트해보면 자꾸 예상치 못한 케이스에서 오류가 발생

public int getLength(String input){
    return input.length();
}

" 위의 코드에서 고려해야하는 것들이 어떤게 있을까? "

빈 문자열 처리 ("")
공백 처리 (" ")
null 입력
특수문자 처리
특정 인코딩 문자 길이

위의 예외 케이스 중 한개라도 방어 로직이 들어가지 않는다면, 해당 문제를 직면했을때 곧바로 예외처리 혹은 오류로 인해서 원활한 서비스를 하지 못하게 될것이다.

2. 리펙토링을 하고 싶어도, 어떤일이 발생할지(?) 짐작이 안가서 도전을 못함

“리팩토링 후 코드가 정상 동작하는지 확인할 방법이 ‘직접 검증’밖에 없었다.”

기능이 하나일 때는 직접 테스트하는 게 어렵지 않았지만,
기능이 복잡해지고 외부 서비스와 얽히기 시작하면 직접 검증은 사실상 불가능해진다.

API 호출 직접 테스트
파일 업로드 직접 테스트
데이터베이스 상태 직접 확인
특정 조건 재현을 위한 환경 세팅

이 모든 것을 수동으로 반복하는 것은 개발 효율을 크게 떨어뜨렸다.
결국 리팩토링을 하고 싶어도, **“두려워서 할 수 없는 코드”**가 되어버렸다.

이때부터 자동으로 검증해주는 테스트가 필요하다는 것을 진짜로 깨닫게 되었다.

# 테스트를 도입했지만, 잘못된 방식으로 사용하고 있었다

테스트의 필요성을 크게 느낀 후, 나는 곧바로 테스트 작성에 들어갔다.
문제는, 그 방식이 TDD에서 말하는 테스트 기반 개발 흐름과 전혀 달랐다는 점이다.

❌ 테스트 방식은 이런 흐름이었다

테스트 폴더로 이동한다. (src/test/java)
테스트 케이스를 작성한다.
테스트 안에서 직접 메서드를 만들어본다.
테스트 안에서 만든 기능이 어느 정도 작동하는 것 같으면,
프로덕션 코드로 옮기는 것이 아니라…
main 폴더에서 기능을 처음부터 다시 만든다. (테스트 케이스의 내용들을 참고하며...)
즉, 테스트는 테스트대로 있고, 프로덕션 코드는 다시 처음부터 작성하는 구조가 되어버렸다.

# 왜 이 방식이 비효율적이었나?

1) 테스트 코드와 실제 코드가 완전히 따로 놀았다

테스트 안에서 프로토타입처럼 코드를 작성했지만,
그 코드를 그대로 프로덕션으로 승격하지 않고 별도로 다시 구현했다.

이 때문에

로직이 중복되고
테스트와 프로덕션이 서로 다른 방향으로 진행되고
버그가 발생해도 양쪽을 모두 봐야 했고
생산성은 눈에 띄게 낮아졌다

# 테스트는 검증 도구가 아니라 참고용 코드가 되어버렸다

테스트의 근본적인 의미는 “동작을 보장하는 자동화된 안전망”이다.
하지만 나는 테스트 코드를 단순히 참고용 예제처럼 사용했기 때문에 테스트의 장점을 전혀 살리지 못했다.

결국

테스트는 작성하는 데만 시간이 들고
실제 코드 품질 개선에는 기여하지 못하며
리팩토링의 안전망 역할도 하지 못했다

즉, 테스트의 목적 자체를 잘못 사용하고 있었던 것이다.

# 지금 돌아보면 TDD와는 정반대 흐름이었다

1) TDD는 다음 흐름을 따른다.

실패하는 테스트 작성 (RED)
테스트를 통과시키기 위한 최소한의 코드 작성 (GREEN)
구조 개선 (REFACTOR)

2) 하지만 나는 이렇게 했다.

테스트에서 기능을 만들어봄 (RED/GREEN 뒤섞임)
프로덕션 코드에서 기능을 다시 구현
테스트는 참고용으로만 사용
설계 개선은 없음

즉, ‘테스트를 쓰긴 했지만’
테스트가 개발을 이끄는 구조가 아니라 개발을 방해하는 구조가 되어버린 셈이다.

# 하지만 이 시행착오가 다음 단계의 시작이 되었다

이 비효율적인 경험 덕분에 나는 한 가지 중요한 사실을 깨달았다.

“테스트의 목적은 기능 확인이 아니라, 설계를 더 좋게 만드는 것”

이 깨달음 이후,

1. 나는 테스트를 기반으로 책임을 분리하고,
2. 기능을 테스트에서 검증한 후 프로덕션 코드로 자연스럽게 승격시키는 구조를 만들기 시작했다.

이 과정은 2편에서 자세히 다뤄보려고 한다.

2편 예고

테스트에서 작은 기능을 먼저 만들고
그 기능을 main 코드로 승격시키는 진짜 TDD 흐름
책임 분리, 클래스 분리, DI 구성
@SpringBootTest 기반 테스트 개선
Given–When–Then만 남는 깔끔한 구조
테스트가 리팩토링을 가능하게 만든 과정

다음 글에서 이어서 설명하겠다.

[유효성검증 #3] 유효성 검증 아키텍처 설계

거북이의 기술블로그 — Mon, 9 Jun 2025 22:34:02 +0900

전체 아키텍처 흐름도 이미지

Spring AOP 기반 유효성 검증 처리 구조 정리

Spring에서 DTO 유효성 검증을 처리할 때, 기본 제공되는 BeanValidation만으로는 부족한 경우가 있다.
이럴 때 커스텀 Validator를 추가로 적용할 수 있도록 구조를 설계하며, 두 가지 방식을 함께 활용한다.

✅ BeanValidation + CustomValidation을 함께 사용하도록 구성한다.
✅ 유효성 검증을 AOP로 감싸 공통 포맷으로 처리하도록 만든다.
✅ 어노테이션(@CustomValidate)을 통해 자동으로 Validator를 스캔하고 매핑한다.

전체 흐름 개요

Controller (with @CheckValidation)
        ↓
ValidationAspect (AOP)
    ├─ BeanValidation 실행
    └─ CustomValidation 실행
         └─ DTO에 @CustomValidate가 붙어 있을 경우 해당 Validator 연결

핵심 구성 요소

1. @CheckValidation 어노테이션

Controller에서 유효성 검증 처리를 위한 어노테이션
(AOP의 trigger 역할)

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface CheckValidation {}

2. AOP - ValidationAspect

유효성검증 공통 처리를 위한 AOP
1. Bean Validation을 먼저 수행
2. Custom Validation을 수행 (getValidator()를 이용한 등록된 커스텀 검증 클래스를 가져옴)

@Around("@annotation(CheckValidation)")
public Object validationAdvice(ProceedingJoinPoint joinPoint) throws Throwable {
    for (Object arg : joinPoint.getArgs()) {
        // 1. BeanValidation 수행
        springValidator.validate(arg);

        // 2. CustomValidator 수행
        Validator validator = validFactory.getValidator(arg.getClass());
        if (validator != null) {
            DataBinder binder = new DataBinder(arg);
            binder.addValidators(validator);
            binder.validate();
        }
    }
    return joinPoint.proceed();
}

3. @CustomValidate 어노테이션

DTO 클래스에 이 어노테이션을 붙이면 커스텀 Validator 대상으로 인식된다.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface CustomValidate {}

4. ValidateFactoryImpl - Validator 자동 등록

해당 패키지 하위에 있는, @CustomValidate 붙은 커스텀 유효섬 검증 클래스를 등록
(scanValidateTarget() 5번 코드 참고)

public ValidateFactoryImpl(List<Validator> validators) {
    Set<Class<?>> targets = scanValidateTarget("패키지명");

    for (Validator v : validators) {
        if (isSpringDefault(v)) continue;

        for (Class<?> dto : targets) {
            if (v.supports(dto)) {
                map.put(dto, v);
            }
        }
    }
}

5. @CustomValidate 스캔 메서드

ClassPathScanningCandidateComponentProvider를 이용해 DTO (@CustomValidate) 를 스캔한다.
( Custom 유효성 검증 클래스를 자동 등록하기 위한 Annotation )

private Set<Class<?>> scanValidateTarget(String basePackage) {
    ClassPathScanningCandidateComponentProvider scanner =
        new ClassPathScanningCandidateComponentProvider(false);

    scanner.addIncludeFilter(new AnnotationTypeFilter(CustomValidate.class));

    for (BeanDefinition bd : scanner.findCandidateComponents(basePackage)) {
        results.add(Class.forName(bd.getBeanClassName()));
    }
    return results;
}

Controller 예시

@CheckValidation
@PostMapping("/post/member")
public ResponseEntity<?> postMember(@RequestBody MemberDto dto) {
    return ResponseEntity.ok().build();
}

컨트롤러에서는 단순히 @CheckValidation만 붙이면, 내부적으로 모든 유효성 검사가 자동 수행된다.

장점

1. 다양한 DTO마다 다른 유효성 검증이 필요한 경우

예: 회원가입 DTO, 주문 DTO, 주소 DTO 등에서 각각 다른 검증 로직이 필요할 때
@CustomValidate + Validator 조합으로 DTO별 맞춤 검증 로직을 적용할 수 있다.

2. 기본 BeanValidation으로는 한계가 있는 경우

예: 한 필드만 판단해서는 안 되고, 다른 필드와 조합해 유효성을 판단해야 하는 경우 (ex. startDate < endDate)
Validator 내부에서 객체 전체를 보고 로직 작성이 가능하다.

3. 유효성 검증을 공통 포맷으로 통일하고 싶은 경우

AOP로 감싸기 때문에 유효성 실패 응답도 일관되게 처리할 수 있다.
에러 응답 포맷을 커스터마이징하고, 프론트엔드와 사전 약속된 형태로 맞출 수 있다.

4. 유효성 로직이 컨트롤러를 지저분하게 만드는 것이 싫을 때

@CheckValidation 하나로 유효성 검증이 끝나므로, 컨트롤러는 핵심 로직에 집중할 수 있다.

주의할 점

런타임 스캔 비용	@CustomValidate 스캔은 클래스 수가 많을수록 비용이 발생함 (앱 초기 구동 시) (해결 : 스캔할 영역을 최대한 제한 -> DTO를 모아두는 패키지에서만 스캔 적용)
동적 등록의 복잡성	프레임워크 초심자 입장에서는 구조를 이해하는 데 진입장벽이 있음 (해결 : 아키텍처 문서 필요)
AOP 사용	AOP를 사용하므로, 디버깅 시 흐름을 추적하기가 다소 어려움 (특히 유효성 오류가 잘못 매핑될 경우) ( 해결 : AOP 내부 진입 로그 (JoinPoint 진입 클래스 로깅) + DTO 로그 + 예외 발생 전후 로깅 필요 )

정리

1. BeanValidation과 CustomValidation을 함께 적용할 수 있도록 설계한다.
(Bean Validation도 같이 사용하므로 Field 단위 어노테이션도 사용 가능)

2. AOP로 유효성 검증을 감싸 컨트롤러 로직을 간결하게 유지한다.

3. @CustomValidate를 통해 DTO에 대응하는 Validator를 자동 등록한다.

확장 아이디어
1. @ValidPhone, @ValidName 같은 필드 단위 어노테이션 추가
2. @Validated(Group.class) 등 그룹 유효성 검증 도입
3. 다국어 메시지 처리를 위한 messages.properties 연동

[유효성검증 #2] Bean Validation를 이용한 유효성 검증

거북이의 기술블로그 — Fri, 6 Jun 2025 22:21:01 +0900

Spring Bean Validation과 커스텀 어노테이션

Spring Boot에서 사용자 입력값을 검증할 때 가장 많이 사용하는 방식은 Bean Validation이다. 간단한 유효성 조건은 어노테이션 한 줄로 처리할 수 있고, 복잡한 로직이 필요한 경우에는 커스텀 유효성 어노테이션을 직접 만들어 적용할 수 있다.

이 글에서는 Bean Validation의 기본 사용법과 함께 @PasswordValidate라는 커스텀 어노테이션을 만들어서 비밀번호 조건을 검사하는 과정을 정리해본다.

1. DTO에 유효성 어노테이션 적용

public static class TestV2Dto {

    // spring bean validation (기본)
    @NotBlank
    private String name;

    // bean validation custom (커스텀 유효성 검사)
    @PasswordValidate
    private String password;

    // spring bean validation (기본 제공 : 맞춤 유효성 검사 제공)
    @Pattern(regexp = "^([0-9]{0,3})-([0-9]{0,4})-([0-9]{0,4})$")
    private String phone;

    // getter/setter 생략
}

@NotBlank - null, 빈 문자열, 공백 문자열 모두 허용하지 않음
@PasswordValidate - 직접 만든 비밀번호 유효성 검사 어노테이션
@Pattern - 전화번호는 하이픈 포함된 형식으로 입력해야 함

2. 컨트롤러에서 검증 적용

@PostMapping("/api/v2/test")
public ResponseEntity<?> validateTestV2(@Validated @RequestBody TestV2Dto testDto,
                                        BindingResult bindingResult) {
    if (bindingResult.hasErrors()) {
        return new ResponseEntity<>(bindingResult.getFieldError().getDefaultMessage(),
                                    HttpStatus.BAD_REQUEST);
    }
    return new ResponseEntity<>(HttpStatus.OK);
}

@Validated를 통해 DTO에 선언된 유효성 어노테이션들이 동작하게 되며,

BindingResult를 통해 에러가 존재하는지 검사할 수 있다.

사실 BindingResult는 생략해도 된다. 생략하면 유효성 실패 시 MethodArgumentNotValidException이 발생하고, Spring이 자동으로 400 에러를 내려준다.

3. 커스텀 어노테이션 `@PasswordValidate` 구현

어노테이션 정의

@Documented
@Constraint(validatedBy = PasswordValidator.class)
@Target({ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
public @interface PasswordValidate {
    String message() default "비밀번호 형식이 유효하지 않습니다.";
    Class<?>[] groups() default {};
    Class<? extends Payload>[] payload() default {};
}

필수 선언 메서드
- message () : 유효성 검사 실패시 나오게 될 메시지
- groups () : 그룹별 유효성 검사 지정을 위한 메서드 ( 유효성 검사를 위한 group을 지정할 떄 구현 )
- payload() : 메타데이터 관련 spring framework 내부적으로 사용되는 메서드 ( 주로 사용되지 않음 )

Validator 클래스 구현

public class PasswordValidator implements ConstraintValidator<PasswordValidate, String> {

    @Override
    public boolean isValid(String value, ConstraintValidatorContext context) {
        String regex = "^(?=.*[a-z])(?=.*[A-Z])(?=.*\\d).{8,}$";
        return value != null && value.matches(regex);
    }
}

Spring에서 추상화한 ConstraintValidator 를 이용하여 PasswordValidate 어노테이션을 지정 (Spring에서 가져다 사용할 수 있도록)
isValid()를 오버라이딩 하여, 유효성 검증 구현 로직 추가

위 정규식은 아래 조건을 만족한다:
- 8자 이상
- 소문자 1개 이상
- 대문자 1개 이상
- 숫자 1개 이상

4. 테스트 예시

요청 (잘못된 입력)

{
  "name": "",
  "password": "1234",
  "phone": "01012345678"
}

응답 예시

HTTP/1.1 400 Bad Request
"비밀번호 형식이 유효하지 않습니다."

5. 마무리

Spring Bean Validation을 활용하면 복잡한 로직 없이도 사용자 입력 검증을 손쉽게 적용할 수 있다. @NotBlank, @Pattern 등 기본 제공 어노테이션만으로 충분한 경우도 많지만, 직접 비즈니스에 맞는 커스텀 어노테이션을 만들어 사용하는 것도 매우 유용하다.

다음 글에서는 유효성 검사를 더욱 체계적으로 관리하기 위해 Validator 인터페이스, @InitBinder, AOP와 어노테이션 기반 유효성 검사 확장 전략에 대해 소개할 예정이다.

[유효성검증 #1] Validator + BindingResult를 이용한 유효성 검증

거북이의 기술블로그 — Fri, 6 Jun 2025 13:29:23 +0900

Spring에서 Validator를 이용한 커스텀 유효성 검사와 BindingResult 활용

Spring에서는 사용자 입력 값을 검증하기 위해 Bean Validation(JSR-380)을 많이 사용하지만, 더 복잡한 조건이 있거나 커스터마이징이 필요한 경우에는 org.springframework.validation.Validator를 직접 구현하여 사용할 수 있다. 이 포스팅에서는 Validator를 이용한 유효성 검사와 BindingResult를 통해 검증 결과를 처리하는 방법을 소개한다.

1. Validator 인터페이스 구현하기

Spring의 Validator 인터페이스는 두 가지 메서드를 구현해야 한다:

supports(Class<?> clazz): 이 Validator가 어떤 클래스 타입을 지원하는지 명시
validate(Object target, Errors errors): 실제 유효성 검사 로직 구현

Ex) 이름(name), 비밀번호(password), 전화번호(phone) 세 가지 필드를 가진 DTO를 검증하도록 구현했다.

@Component
public class TestV1Validate implements Validator {

    @Override
    public boolean supports(Class<?> clazz) {
    	// TestDto에 대한 Validator라는 것을 의미
        return clazz.isAssignableFrom(V1Controller.TestDto.class);
    }

    @Override
    public void validate(Object target, Errors errors) {
        V1Controller.TestDto testDto = (V1Controller.TestDto) target;
        String regex = "^([0-9]{0,3})-([0-9]{0,4})-([0-9]{0,4})$";

        if (testDto.getName() == null || testDto.getName().trim().equals("")) {
            errors.rejectValue("name", "name.required");
        }
        if (testDto.getPassword() == null || testDto.getPassword().trim().equals("")) {
            errors.rejectValue("password", "password.required");
        }
        if (testDto.getPhone() == null || testDto.getPhone().trim().equals("")) {
            errors.rejectValue("phone", "phone.required");
        } else if (!testDto.getPhone().matches(regex)) {
            errors.rejectValue("phone", "phone.invalid");
        }
    }
}

2. DTO 클래스 정의

@Data
public static class TestDto {
    private String name;
    private String password;
    private String phone;
}

3. Validator 등록: @InitBinder 사용

해당 testValidate는 아직 Spring에 등록된 상태가 아니므로, InitBinder를 통해 특정 Controller 혹은 객체에 등록을 해줘야한다
@InitBinder 대신해서 전역적으로 적용할경우, 해당 validator가 자동으로 검증 단계에 사용될 수 있음 (주의)

@InitBinder
public void initBinder(WebDataBinder binder) {
    binder.addValidators([CustomValidator]);
}

4. 컨트롤러에서 BindingResult 처리하기

@PostMapping("/api/v1/test")
public ResponseEntity<?> TestDtoVersion1(@Validated @RequestBody TestDto testDto, BindingResult bindingResult) {
    if (bindingResult.hasErrors()) {
        return new ResponseEntity<>(
            bindingResult.getFieldError().getCodes(),
            HttpStatus.BAD_REQUEST
        );
    }
    return new ResponseEntity<>(testDto, HttpStatus.OK);
}

@Validated는 Validator와 연계되어 동작하며, 내부적으로 WebDataBinder가 등록된 Validator를 사용하게 된다. BindingResult를 바로 옆 파라미터로 선언하면 Spring이 자동으로 유효성 검사 결과를 바인딩해준다.

5. 응답 결과

요청:

POST /api/v1/test
Content-Type: application/json

{
  "name": "admin",
  "password": "1234",
  "phone": "010-1234"
}

응답:

[
  "phone.invalid"
]

6. 마무리

이번 포스팅에서는 Spring의 Validator 인터페이스를 직접 구현하고, BindingResult를 통해 검증 결과를 처리하는 기본 흐름을 살펴보았다. 이를 통해 개발자는 단순한 필드 검사 외에도 복잡한 조건문, 데이터베이스 중복 검사, 특정 필드 간 상호관계 등 자유로운 검증 로직을 구현할 수 있다.

다음 포스팅에서는 보다 널리 쓰이는 방식인 @NotNull, @Pattern 등으로 대표되는 Bean Validation을 소개할 예정이다.
그 이후에는 Validator와 Bean Validation을 조합하고, AOP 및 사용자 정의 어노테이션을 활용한 유효성 검사 아키텍처의 확장 방법을 다룰 계획이다.

[트랜잭션 #1] @Transactional 프록시 생략으로 인한 Rollback 실패 사례

거북이의 기술블로그 — Wed, 30 Apr 2025 16:24:03 +0900

트랜잭션(Transaction) 실패 경험을 통한 내용 정리

1.. 예외처리로인한 Transaction Proxy 실패
2. self Call로 인한 @Transactional 실패

트랜잭션(Transaction) 개요

스프링 프레임워크에서 트랜잭션은 ACID(원자성·일관성·격리성·지속성) 규칙을 따르며,
하나의 처리 흐름이 모두 성공해야 커밋되고, 중간에 문제가 발생하면 전부 롤백되도록 보장
주로 @Transactional 애노테이션을 통해 스프링 AOP 프록시가 트랜잭션 경계를 관리

원자성(Atomicity): 작업 전체가 성공하거나, 하나라도 실패하면 모두 롤백
일관성(Consistency): 트랜잭션 전후에 데이터베이스 일관성이 유지
격리성(Isolation): 동시성 제어를 통해 트랜잭션 간 간섭을 방지
지속성(Durability): 커밋된 변경 사항은 시스템 장애가 발생해도 보존

@Transactional의 특성

1. 기본 예외 처리

런타임 예외(RuntimeException)나 Error 발생 시에만 기본적으로 롤백
체크 예외(Exception)까지 롤백하려면 rollbackFor 속성을 명시해야 롤백이 진행 (rollbackFor 옵션)

@Transactional(rollbackFor = Exception.class)
public void someMethod() { … }

2. 트랜잭션 매니저

스프링 환경에서는 PlatformTransactionManager(txManager)가 내부적으로 트랜잭션 경계를 관리합니다.
직접 트랜잭션을 제어하려면, TransactionAspectSupport.currentTransactionStatus().setRollbackOnly() 등을 활용할 수 있습니다. (직접 롤백 요청)

3. 예외 처리 시 주의사항

메서드 내에서 try–catch로 예외를 모두 처리해 버리면, 트랜잭션 프록시가 예외를 인지하지 못해 Commit이 진행
- catch 블록에서 정상화를 진행하게 될경우, TransactionAspectSupport를 이용해 직접 롤백을 지정 )

자기 호출(self-invocation)을 할 경우, 메서드를 직접 호출하게 되어 AOP 프록시가 작동하지 않으므로 @Transactional이 적용되지 않음

주요 트러블슈팅 사례

1. try–catch로 예외를 모두 처리해 버린 경우

@Transactional(rollbackFor = Exception.class)
public Map<String,Object> run() {
    Map<String, Object> result = new HashMap<>();
    try {
        // 엔티티 생성 및 저장 로직
        save(transportation, bus);
        result.put("code", "1");
    } catch(Exception e) {
        log.error("Service Error: {}", e);
        result.put("code", "9999");
        // 롤백 의도 명시
        TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
    }
    return result;
}

문제: catch 블록에서 예외를 잡아 버리면, 실제로는 Commit 진행
해결:
- 방법1) TransactionAspectSupport.currentTransactionStatus().setRollbackOnly() 호출
- 방법2) 예외를 다시 던져서(AOP 프록시가 인지하도록) 자동 롤백 유도

2. AOP 기반 커스텀 트랜잭션 처리

스프링 @Transactional 대신 직접 PlatformTransactionManager를 사용해 트랜잭션을 관리하는 AOP 예제 (@CustomTransactional)

@Aspect
@Component
public class TransactionAspect {

    private final PlatformTransactionManager txManager;

    public TransactionAspect(PlatformTransactionManager txManager) {
        this.txManager = txManager;
    }

    @Around("@annotation(CustomTransaction)")
    public Object around(ProceedingJoinPoint pjp) throws Throwable {
        TransactionStatus status = txManager.getTransaction(new DefaultTransactionDefinition());
        try {
            Object ret = pjp.proceed();
            txManager.commit(status);
            return ret;
        } catch(Throwable e) {
            txManager.rollback(status);
            Map<String, Object> errorResult = new HashMap<>();
            log.error("[Error] {}", e.getMessage());
            errorResult.put("code", "404");
            return errorResult;
        }
    }
}

장점: 트랜잭션 로직을 통합 관리 가능
주의: AOP 포인트컷이 정확히 적용되는지, 트랜잭션 전파 속성(PROPAGATION_REQUIRED 등)이 적절한지 확인이 필요

3. 자기 호출(Self-invocation)으로 인한 트랜잭션 미적용

public Map<String,Object> run() {
    // ...
    save(transportation, bus);  // 같은 클래스 내부 메서드 호출
    // ...
}

@Transactional
public void save(Transportation t, Bus b) {
    transportationRepository.save(t);
    busRepository.save(b);
}

//======================================================

// **해결(Proxy로 자신 클래스를 가져와서 직접 호출 (ApplicationContext에서 자기 자신 빈을 주입 받아 호출 ) **//
@Service
public class MyService {
    private final MyService selfProxy;
    public MyService(MyService selfProxy) {
        this.selfProxy = selfProxy;
    }

    public void run() {
        // 트랜잭션 적용을 위해 프록시를 통해 호출
        selfProxy.save(...);
    }

    @Transactional
    public void save(...) { … }
}

문제: 스프링은 프록시 기반이기 때문에, 동일 클래스의 내부 메서드 호출은 프록시를 거치지 않아 트랜잭션이 적용이 되지 않음
해결:
- 방법1 ) 외부에서 호출되도록 구조를 변경
- 방법 2) ApplicationContext에서 자기 자신 빈을 주입 받아 호출

4. MethodUtil.inboke()와 같은 외부 유틸리티를 통한 Method() 직접 호출

public class MethodUtil {

    public static void invokeMethod(Object target, String methodName) throws Exception {
        Method method = target.getClass().getMethod(methodName);
        method.invoke(target);  // !! 프록시를 타지 않음 → @Transactional 등 동작 안 함
    }
}


/* 해결방법 1 */
@Autowired
private MyService myService; // 프록시 객체

public void invokeThroughProxy() throws Exception {
    Method method = myService.getClass().getMethod("someTransactionalMethod");
    method.invoke(myService);  // AOP 적용됨
}


/* 해결방법 2 */
@Autowired
private ApplicationContext context;

public void invokeFromContext() throws Exception {
    MyService proxy = context.getBean(MyService.class); // 프록시 객체
    Method method = proxy.getClass().getMethod("someTransactionalMethod");
    method.invoke(proxy);  // AOP 적용됨
}

문제: Spring은 프록시 기반 AOP를 사용합니다. 따라서 외부 유틸리티(예: MethodUtil)를 통해 리플렉션으로 메서드를 직접 호출하면, 해당 호출은 프록시 객체를 경유하지 않고 실제 객체 인스턴스의 메서드를 직접 실행하게 된다. 이는 Spring 컨테이너가 제공하는 @Transactional, @Cacheable, @Async 등의 AOP 기능이 작동하지 않게 되는 원인이 됩니다. 다시 말해, 스프링의 프록시 관리를 벗어난 직접 호출은 AOP 적용 대상에서 제외된다
해결:
- 방법1 ) AOP 프록시 객체를 이용한 리플렉션 호출
  → 실제 빈이 아닌 스프링 컨테이너에 등록된 프록시 객체를 이용해서 invoke
- 방법 2) ApplicationContext를 통해 스프링이 관리하는 프록시 객체를 가져와 사용
  → @Autowired, 혹은 직접적으로 ApplicationContext.getBean()을 사용해서 프록시 객체를 확보

정리

예외 처리 전략
- 비즈니스 로직 내 try–catch는 최소화하고, 예외는 되도록 밖으로 던져 프록시가 인지하도록 설계
- 체크 예외일 경우, 롤백하려면 rollbackFor = Exception.class를 지정
트랜잭션 전파(Propagation)
- 내부 호출 구조나 재진입 호출이 많은 복잡한 서비스 레이어에서는 전파 속성을 명확히 설계 필요
AOP와 프록시 주의사항
- 자기 호출 시 프록시 우회 문제를 인지하고, 필요한 경우 selfProxy 주입이나 인터페이스 기반 프록시를 활용필요
- 또는, 외부 유틸리티의 사용 혹은 직접 호출하게 될경우, 프록시 객체가 적용이 안되므로 스프링이 지원하는 AOP를 사용할 수 없게 된다.
공통 처리(AOP) 활용
- 여러 서비스에서 동일한 트랜잭션 로직·예외 처리를 한다면, AOP로 묶어서 관리하면 코드 중복 방지 가능

[게임서버프로그래밍#6] 클라이언트-서버 구현을 위한 소켓 기초 정리

거북이의 기술블로그 — Tue, 29 Apr 2025 00:56:17 +0900

이 글에서는 소켓 통신의 기초부터, Blocking/Non-Blocking 구조, Winsock2 함수(ioctlsocket, getsockopt, select) 사용법, 클라이언트-서버 프로그램 기본 흐름까지 실제 코드 예제와 함께 설명한다.

소켓(Socket)이란 무엇인가

소켓은 네트워크 연결을 제어하는 핸들이다.
파일 핸들처럼 읽고 쓰기를 담당하지만 대상이 네트워크다.

Blocking 통신 구조

Blocking 통신은 소켓 함수 호출 시 완료될 때까지 대기하는 구조를 의미한다.

* 클라이언트 Blocking 흐름

socket() : 소켓 핸들 생성
bind() : 클라이언트 포트 설정
connect() : 서버 연결 (연결 완료될 때까지 대기)
send() : 송신 버퍼에 데이터 저장 (버퍼가 꽉 차면 Blocking)
close() : 소켓 닫기

* 서버 Blocking 흐름

socket() : 소켓 핸들 생성
bind() : 서버 포트 설정
listen() : 연결 요청 대기
accept() : 클라이언트 연결 수락 (연결 전까지 Blocking)
recv() : 데이터 수신 (버퍼에 데이터 올 때까지 대기)
close() : 소켓 닫기

비동기(Non-Blocking) 통신 구조

Non-Blocking 통신은 소켓 함수 호출이 즉시 반환되어 다른 작업을 할 수 있도록 한다.

ioctlsocket()을 사용하여 소켓을 비동기 모드로 설정한다.
select()를 통해 소켓의 I/O 가능 여부를 확인한다.

* Non-Blocking 클라이언트 흐름

socket() : 소켓 핸들 생성
ioctlsocket(sock, FIONBIO, &mode) : 비동기 모드 설정
connect() 호출 → Would Block 오류 무시
select()로 연결 완료 여부 확인
send()/recv() 전에 select()로 I/O 가능 상태를 확인

* Non-Blocking 서버 흐름

socket() : 소켓 핸들 생성
ioctlsocket(sock, FIONBIO, &mode) : 비동기 모드 설정
listen()으로 연결 요청 대기
select()를 통해 accept() 가능 여부 탐지
연결된 소켓에 대해 recv(), send() 진행

주요 함수 정리

1. ioctlsocket()

소켓 핸들에 명령을 내려 속성을 설정한다.

FIONBIO : 동기/비동기 설정
FIONREAD : 읽을 수 있는 데이터 양 확인
SIO_KEEPALIVE_VALS : TCP Keep-Alive 시간 변경
SIO_GET_EXTENSION_FUNCTION_POINTER : 확장 함수 포인터 획득

2. getsockopt()

소켓의 현재 상태나 설정값을 조회할 수 있다.

SO_REUSEADDR : 주소 재사용 허용
SO_KEEPALIVE : 유휴 연결 상태 유지
SO_LINGER : 소켓 종료 시 데이터 전송 여부 설정
SO_SNDBUF / SO_RCVBUF : 송수신 버퍼 크기 설정
SO_ERROR : 소켓 오류 상태 확인

3. select()

복수 소켓의 상태를 감시할 수 있다.
FD_ZERO(), FD_SET() 매크로와 함께 사용한다.

fd_set 종류	감시 내용
readfds	읽기(read) 가능 여부 확인
writefds	쓰기(write) 가능 여부 확인
exceptfds	오류 발생 여부 확인

FD_ZERO(&readSet);
FD_SET(sock, &readSet);
timeval timeout = {1, 0}; // 1초 대기
int result = select(0, &readSet, nullptr, nullptr, &timeout);
if (result > 0 && FD_ISSET(sock, &readSet)) {
    recv(sock, buffer, size, 0);
}

Blocking vs Non-Blocking 비교

항목	Blocking 구조	Non-Blocking 구조
대기 여부	함수 호출 시 완료될 때까지 대기	함수 호출 즉시 반환
구현 난이도	비교적 간단	select/poll 로직 필요
성능	적은 클라이언트 처리에 적합	대규모 동시 접속 처리에 적합

Non-Blocking에서 주의할 점

Would Block 에러는 정상:
아직 소켓이 준비되지 않았다는 의미이며, select()로 대기 후 재시도해야 한다.
0바이트 송신법:
Non-Blocking connect() 후, 연결 성공 여부를 확인할 때 0바이트를 송신해본다.
CPU 낭비 주의:
select()에 timeout을 설정하여 무한 루프에서 CPU를 소모하지 않도록 한다.
UDP 주의사항:
송신버퍼는 남아있더라도 패킷 크기가 맞지 않으면 보내지 못할 수 있다.

실제 코드 흐름 요약

* 클라이언트

Winsock winsock;
ClientSocket client("localhost", "27015");
client.send("Hello");
auto response = client.receive(512);

* 서버

Winsock winsock;
ServerSocket server;
server.accept_connection();
server.socket_recv("Hello from server");

[File I/O #6] File이외의 I/O Stream 정리 (Object, Audio, Piped 등)

거북이의 기술블로그 — Sun, 20 Apr 2025 00:36:20 +0900

목차

1. Resource와 Stream I/O 이해
2. Resource 구현체 이해하기

3. InputStream/OutputStream 이해하기

4. InputStreamReader, BufferedReader 이해하기

5. Multipartfile 처리하기

6. File 이외의 I/O stream 정리

File I/O #6 — 고급 입출력 스트림 정리 (Object, Audio, Piped 등)

1. ObjectInputStream / ObjectOutputStream

객체를 바이트 형태로 저장하거나 다시 객체로 복원하는 데 사용됩니다.

직렬화(Serialization)와 역직렬화(Deserialization) 기능을 제공하죠.

// 객체 저장 (직렬화 - 바이트로 저장)
ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("object.dat"));
oos.writeObject(new User("홍길동", 30));
oos.close();

// 객체 읽기 (역직렬화 - 바이트 읽기)
ObjectInputStream ois = new ObjectInputStream(new FileInputStream("object.dat"));
User user = (User) ois.readObject();
ois.close();

주의: 직렬화하려는 클래스는 implements Serializable 필요

2. AudioInputStream

Java에서 WAV, AU 등 오디오 파일을 읽고 재생하거나 분석할 때 사용되는 스트림입니다.
(Java의 javax.sound.sampled 패키지)

File audioFile = new File("example.wav");
AudioInputStream audioStream = AudioSystem.getAudioInputStream(audioFile);

// 포맷 확인
AudioFormat format = audioStream.getFormat();
System.out.println("Sample Rate: " + format.getSampleRate());

3. PipedInputStream / PipedOutputStream

두 스레드 간에 데이터를 주고받을 수 있게 해주는 스트림입니다.

한 스레드가 쓰고, 다른 스레드가 읽음으로써 실시간 통신 구조를 만들 수 있어요.

PipedInputStream pipedIn = new PipedInputStream();
PipedOutputStream pipedOut = new PipedOutputStream(pipedIn);

// 쓰기 스레드
new Thread(() -> {
    try {
        pipedOut.write("스레드 간 통신 데이터".getBytes());
        pipedOut.close();
    } catch (IOException e) {
        e.printStackTrace();
    }
}).start();

// 읽기 스레드
new Thread(() -> {
    try {
        int data;
        while ((data = pipedIn.read()) != -1) {
            System.out.print((char) data);
        }
        pipedIn.close();
    } catch (IOException e) {
        e.printStackTrace();
    }
}).start();

4. SequenceInputStream

여러 InputStream을 하나로 연결하여 연속적으로 데이터를 읽을 수 있게 해줍니다.
예를 들어 여러 파일을 하나의 스트림처럼 처리하고 싶을 때 유용합니다.

InputStream input1 = new FileInputStream("file1.txt");
InputStream input2 = new FileInputStream("file2.txt");

SequenceInputStream sis = new SequenceInputStream(input1, input2);
int data;
while ((data = sis.read()) != -1) {
    System.out.print((char) data);
}
sis.close();

고급 Stream I/O 정리

스트림	설명	사용 예시
ObjectInputStream ObjectOutputStream	객체를 저장하고 불러오기	세이브 데이터, 설정 저장
AudioInputStream	오디오 파일 처리	음악 재생, 오디오 분석
PipedInputStream PipedOutputStream	읽기/쓰기 스레드 간 실시간 통신	실시간 처리 구조
SequenceInputStream	여러개의 InputStream 연결	여러 파일 합치기

5. 채널 기반 입출력 (Channel I/O)

Java NIO(New I/O)에서는 기존의 InputStream, OutputStream보다 더 빠르고 효율적인 입출력 방식으로 Channel을 제공합니다.
Channel은 읽기와 쓰기가 모두 가능한 이중 구조이며, 버퍼(Buffer)와 함께 사용됩니다.

주요 채널 인터페이스

ReadableByteChannel – 읽기 전용
WritableByteChannel – 쓰기 전용
FileChannel – 파일 기반 입출력 지원 (읽기/쓰기)

FileChannel 사용 예제

// 파일에서 읽기
try (FileInputStream fis = new FileInputStream("data.txt");
     FileChannel channel = fis.getChannel()) {

    ByteBuffer buffer = ByteBuffer.allocate(1024);
    while (channel.read(buffer) > 0) {
        buffer.flip(); // 읽을 준비
        while (buffer.hasRemaining()) {
            System.out.print((char) buffer.get());
        }
        buffer.clear(); // 버퍼 비우기
    }
}

// 파일에 쓰기
try (FileOutputStream fos = new FileOutputStream("output.txt");
     FileChannel channel = fos.getChannel()) {

    String data = "Hello, FileChannel!";
    ByteBuffer buffer = ByteBuffer.wrap(data.getBytes());
    channel.write(buffer);
}

FileChannel vs Stream 비교

항목	InputStream / OutputStream	Channel (NIO)
기반	바이트 기반 스트림	채널 & 버퍼 기반
속도	상대적으로 느림	빠름 (DirectBuffer, OS 지원)
기능	순차적 읽기/쓰기	랜덤 액세스, 이중 채널, 멀티스레드 효율적
멀티스레드	지원 제한적	동기화에 적합

Resource와 Channel 함께 사용하기

Spring의 Resource는 readableChannel() 메서드로 NIO 채널도 지원합니다.

Resource resource = new ClassPathResource("data.txt");
ReadableByteChannel channel = Channels.newChannel(resource.getInputStream());

ByteBuffer buffer = ByteBuffer.allocate(1024);
while (channel.read(buffer) > 0) {
    buffer.flip();
    while (buffer.hasRemaining()) {
        System.out.print((char) buffer.get());
    }
    buffer.clear();
}
channel.close();

Channel I/O 요약

FileChannel은 파일 입출력을 더 빠르고 효율적으로 처리 가능
ByteBuffer를 이용해 메모리 직접 제어
Resource + Channel 조합으로 Spring에서도 활용 가능
대용량 파일 처리나 성능 최적화에 매우 유리

시리즈 마무리

지금까지 총 6편에 걸쳐 Java의 파일 입출력(File I/O)에 대해 알아보았다.

#1 기본 개념: Resource, InputStream, OutputStream
#2 Resource 구현체
#3 InputStream과 OutputStream
#4 InputStreamReader & BufferedReader
#5 MultipartFile 업로드 처리
#6 File이외의 I/O Stream 정리 (Object, Audio, Piped 등)

[File I/O #5] MultiPartFile (Form데이터) 처리하기

거북이의 기술블로그 — Sun, 20 Apr 2025 00:32:47 +0900

목차

1. Resource와 Stream I/O 이해
2. Resource 구현체 이해하기

3. InputStream/OutputStream 이해하기

4. InputStreamReader, BufferedReader 이해하기

5. Multipartfile 처리하기

6. File 이외의 I/O stream 정리

File I/O #5 — MultipartFile 업로드 처리 흐름

MultipartFile이란?

Spring MVC에서 클라이언트가 전송한 파일 업로드 요청을 다루기 위한 인터페이스입니다.
HTML의 <input type="file">에서 전송된 데이터를 서버에서 받기 위해 사용됩니다.

public interface MultipartFile {
    String getName();                         // 파라미터 이름
    String getOriginalFilename();             // 업로드된 원본 파일명
    String getContentType();                  // MIME 타입
    boolean isEmpty();                        // 파일이 비어있는지 확인
    long getSize();                           // 파일 크기
    byte[] getBytes() throws IOException;     // 바이트 배열로 읽기
    InputStream getInputStream() throws IOException; // InputStream으로 읽기
    void transferTo(File dest) throws IOException;   // 파일로 저장
}

MultipartFile → InputStream 흐름

[HTML 파일 업로드]
       ↓
[Spring Controller: MultipartFile 수신]
       ↓
MultipartFile.getInputStream()
       ↓
InputStream (→ BufferedReader 또는 직접 처리)

결국 MultipartFile은 내부에 저장된 파일 내용을 InputStream으로 꺼내어 읽을 수 있게 해주는 구조입니다.

1. InputStream으로 읽기

파일 내용을 바이트 스트림으로 처리

@PostMapping("/upload")
public String upload(@RequestParam("file") MultipartFile file) {
    try (InputStream is = file.getInputStream()) {
        int data;
        while ((data = is.read()) != -1) {
            System.out.print((char) data);
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
    return "업로드 완료";
}

2. BufferedReader로 줄 단위 읽기 (주로 사용됨)

텍스트 파일인 경우 가장 자주 사용되는 방식

@PostMapping("/upload")
public String upload(@RequestParam("file") MultipartFile file) {
    try (BufferedReader reader = new BufferedReader(
            new InputStreamReader(file.getInputStream(), StandardCharsets.UTF_8))) {

        String line;
        while ((line = reader.readLine()) != null) {
            System.out.println("줄 내용: " + line);
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
    return "업로드 완료";
}

3. byte[]로 한 번에 읽기 (파일 내용 한번에 읽을 때 유용)

바이너리 파일이나 전체 내용을 통째로 읽고 싶을 때

byte[] data = file.getBytes();
String content = new String(data, StandardCharsets.UTF_8);
System.out.println("파일 전체 내용: " + content);

4. 파일로 저장하기 (transferTo)

서버에 파일을 직접 저장하고 싶을 때 사용

File targetFile = new File("/tmp/" + file.getOriginalFilename());
file.transferTo(targetFile);
System.out.println("파일 저장 완료: " + targetFile.getAbsolutePath());

어떤 방식이 적절할까?

방법	설명	적합한 상황
getInputStream()	스트림 기반 읽기 (InputStream 가져오기)	대부분의 파일 처리, 성능 중심
BufferedReader	줄 단위 텍스트 읽기	CSV, TXT, 로그 등 텍스트 파일
getBytes()	전체 내용을 바이트로 한 번에	파일 크기가 작을 때, JSON 등
transferTo()	파일로 저장 (다른이름으로 저장 같은 느낌)	파일 백업, 임시 저장 필요 시

정리

- MultipartFile : 업로드된 파일을 추상화한 객체
- getInputStream() : 파일 내용을 InputStream으로 읽을 수 있음
- BufferedReader : 줄 단위로 쉽게 읽을 수 있음
- transferTo() : 서버에 파일을 저장할 수도 있음 (서버에 "파일을 다른이름으로 저장" 같은 느낌으로 저장)

[File I/O #4] InputStreamReader & BufferedReader 완전 분석

거북이의 기술블로그 — Sun, 20 Apr 2025 00:31:04 +0900

목차

1. Resource와 Stream I/O 이해
2. Resource 구현체 이해하기

3. InputStream/OutputStream 이해하기

4. InputStreamReader, BufferedReader 이해하기

5. Multipartfile 처리하기

6. File 이외의 I/O stream 정리

File I/O #4 — InputStreamReader & BufferedReader 완전 분석

InputStreamReader란?

InputStreamReader는 바이트 스트림(InputStream)을 문자 스트림(Reader)으로 변환해주는 클래스입니다.
즉, 파일이나 네트워크에서 읽은 바이트를 UTF-8 같은 문자 인코딩을 고려해서 문자 단위로 읽게 해줍니다.

InputStream is = new FileInputStream("text.txt");
InputStreamReader reader = new InputStreamReader(is, StandardCharsets.UTF_8);

int ch;
while ((ch = reader.read()) != -1) {
    System.out.print((char) ch);
}

reader.close();

BufferedReader란?

BufferedReader는 Reader(예: InputStreamReader)를 감싸서 성능을 높이고, 편하게 줄 단위로 읽을 수 있게 해줍니다.
가장 많이 사용하는 기능은 readLine() 메서드로 한 줄씩 읽는 것입니다.

InputStream is = new FileInputStream("text.txt");
BufferedReader reader = new BufferedReader(new InputStreamReader(is, StandardCharsets.UTF_8));

String line;
while ((line = reader.readLine()) != null) {
    System.out.println(line);
}

reader.close();

InputStreamReader vs BufferedReader 차이

구분	InputStreamReader	BufferedReader
기능	바이트 → 문자 변환 (UTF-8 변환)	문자 스트림 → 줄 단위 처리
주요 메서드	`read()`	`readLine()`
단독 사용	O (가능)	O (Reader 기반이면 가능)
함께 사용	InputStream → InputStreamReader → BufferedReader 조합이 가장 일반적

언제 어떤 걸 써야 할까?

- 파일이 텍스트 파일이고 줄 단위로 읽고 싶다 → BufferedReader
- 파일을 문자 단위로 읽고 싶다 → InputStreamReader
- 파일 내용을 한 줄씩 읽어서 파싱하고 싶다 → 둘을 함께 사용

실전 예제: Resource + BufferedReader

Resource를 통해 파일을 가져오고 줄 단위로 읽는 가장 흔한 패턴입니다.

Resource resource = new ClassPathResource("data.txt");

try (BufferedReader reader = new BufferedReader(
         new InputStreamReader(resource.getInputStream(), StandardCharsets.UTF_8))) {
    
    String line;
    while ((line = reader.readLine()) != null) {
        System.out.println("읽은 줄: " + line);
    }
} catch (IOException e) {
    e.printStackTrace();
}

정리

- InputStreamReader: 바이트 → 문자로 변환해줌
- BufferedReader: 문자 스트림을 줄 단위로 효율적으로 읽기

차근차근정확하게

# 테스트가 설계를 바꾸기 시작했다: TDD를 체험해보다

# 테스트에서 시작하고, 설계로 이어지는 흐름을 만들다

# 테스트 코드가 설계를 요구하기 시작했다

# 전체 흐름 다시 요약

# 마무리

※ 참고) 리펙토링 방법

#1 테스트 코드의 필요성을 절실히 느낀 이유...

# 테스트를 해야겠다고 느낀 이유

# 테스트를 도입했지만, 잘못된 방식으로 사용하고 있었다

# 왜 이 방식이 비효율적이었나?

# 테스트는 검증 도구가 아니라 참고용 코드가 되어버렸다

# 지금 돌아보면 TDD와는 정반대 흐름이었다

# 하지만 이 시행착오가 다음 단계의 시작이 되었다

2편 예고

[유효성검증 #3] 유효성 검증 아키텍처 설계

전체 흐름 개요

핵심 구성 요소

1. @CheckValidation 어노테이션

2. AOP - ValidationAspect

3. @CustomValidate 어노테이션

4. ValidateFactoryImpl - Validator 자동 등록

5. @CustomValidate 스캔 메서드

Controller 예시

장점

주의할 점

정리

[유효성검증 #2] Bean Validation를 이용한 유효성 검증

Spring Bean Validation과 커스텀 어노테이션

1. DTO에 유효성 어노테이션 적용

2. 컨트롤러에서 검증 적용

3. 커스텀 어노테이션 @PasswordValidate 구현

4. 테스트 예시

요청 (잘못된 입력)

응답 예시

5. 마무리

[유효성검증 #1] Validator + BindingResult를 이용한 유효성 검증

1. Validator 인터페이스 구현하기

2. DTO 클래스 정의

3. Validator 등록: @InitBinder 사용

4. 컨트롤러에서 BindingResult 처리하기

5. 응답 결과

요청:

응답:

6. 마무리

[트랜잭션 #1] @Transactional 프록시 생략으로 인한 Rollback 실패 사례

트랜잭션(Transaction) 개요

@Transactional의 특성

주요 트러블슈팅 사례

정리

[게임서버프로그래밍#6] 클라이언트-서버 구현을 위한 소켓 기초 정리

소켓(Socket)이란 무엇인가

Blocking 통신 구조

* 클라이언트 Blocking 흐름

* 서버 Blocking 흐름

비동기(Non-Blocking) 통신 구조

* Non-Blocking 클라이언트 흐름

* Non-Blocking 서버 흐름

주요 함수 정리

1. ioctlsocket()

2. getsockopt()

3. select()

Blocking vs Non-Blocking 비교

Non-Blocking에서 주의할 점

실제 코드 흐름 요약

[File I/O #6] File이외의 I/O Stream 정리 (Object, Audio, Piped 등)

1. ObjectInputStream / ObjectOutputStream

2. AudioInputStream

3. PipedInputStream / PipedOutputStream

4. SequenceInputStream

고급 Stream I/O 정리

5. 채널 기반 입출력 (Channel I/O)

주요 채널 인터페이스

FileChannel 사용 예제

FileChannel vs Stream 비교

Resource와 Channel 함께 사용하기

Channel I/O 요약

시리즈 마무리

[File I/O #5] MultiPartFile (Form데이터) 처리하기

MultipartFile이란?

3. 커스텀 어노테이션 `@PasswordValidate` 구현