loaded_diaper.log

CH5 플러스 스프링 모의면접 질문범위

Mon, 29 Jun 2026 03:14:41 GMT

CH5 플러스 스프링 모의면접 예상질문 정리

QueryDSL, Cache, Redis, 인덱스, 쿼리 튜닝, 동시성, AOP, 테스트 영역에서 나올 수 있는 면접 질문과 핵심 답변을 정리했습니다.

QueryDSL 영역

Q1. QueryDSL의 BooleanExpression을 활용한 동적 쿼리 작성 방식을 설명해주세요.

QueryDSL에서는 검색 조건을 BooleanExpression 메서드로 분리해서 동적 쿼리를 만들 수 있습니다.

예를 들어 검색어, 카테고리, 상태값이 있을 때 값이 존재하면 조건을 반환하고, 값이 없으면 null을 반환합니다.

private BooleanExpression keywordContains(String keyword) {
    if (keyword == null || keyword.isBlank()) {
        return null;
    }

    return product.name.contains(keyword);
}

그리고 where()에 여러 조건을 넣으면 필요한 조건만 적용됩니다.

.where(
    keywordContains(keyword),
    categoryEq(category),
    statusEq(status)
)

이 방식은 조건이 많아져도 코드가 깔끔하고, 각 조건을 메서드로 분리할 수 있어 유지보수에 좋습니다.

꼬리질문 1. BooleanExpression을 null로 반환하는 방식이 왜 null-safe하다고 하나요?

QueryDSL의 where()는 여러 조건 중 null인 조건을 무시합니다.

그래서 검색 조건이 없을 때 억지로 1=1 같은 조건을 만들 필요가 없습니다.

즉, 조건이 있으면 적용되고 없으면 제외되기 때문에 동적 쿼리를 안전하고 간결하게 작성할 수 있습니다.

꼬리질문 2. QueryDSL 없이 JPA Specification으로도 동적 쿼리를 만들 수 있는데, QueryDSL을 선택한 이유가 있나요?

JPA Specification도 동적 쿼리를 만들 수 있지만, QueryDSL은 타입 안정성이 좋고 코드 가독성이 더 좋다고 느꼈습니다.

특히 복잡한 검색 조건, 정렬, 페이징, 조인 쿼리를 작성할 때 QueryDSL은 Java 코드처럼 읽히기 때문에 유지보수에 유리합니다.

또한 QClass를 기반으로 필드명을 컴파일 시점에 확인할 수 있어 문자열 기반 쿼리보다 실수를 줄일 수 있습니다.

Q2. QueryDSL로 페이징을 구현할 때 count 쿼리를 분리해서 최적화하는 이유가 무엇인가요?

페이징을 할 때는 실제 데이터를 가져오는 content 쿼리와 전체 개수를 구하는 count 쿼리가 필요합니다.

하지만 content 쿼리에 필요한 join이 count 쿼리에는 필요하지 않은 경우가 많습니다.

그래서 count 쿼리를 따로 작성하면 불필요한 join을 줄여 성능을 개선할 수 있습니다.

content query: 실제 목록 조회
count query: 전체 개수 조회

데이터가 많아질수록 count 쿼리 비용도 커지기 때문에, 별도로 최적화하는 것이 중요합니다.

꼬리질문 1. count 쿼리에서 불필요한 join을 제거하면 왜 성능이 개선되나요?

join이 많으면 DB가 여러 테이블을 결합하고 조건을 비교해야 합니다.

하지만 count 쿼리는 보통 “조건에 맞는 데이터 개수”만 필요하기 때문에, 응답 DTO를 만들기 위한 join이나 fetch join은 필요 없는 경우가 많습니다.

예를 들어 상품 목록 조회에서 판매자 이름을 보여주기 위해 seller를 join했다면, 전체 상품 개수를 세는 count 쿼리에서는 seller join이 필요 없을 수 있습니다.

이런 join을 제거하면 DB가 읽어야 하는 데이터와 연산량이 줄어 성능이 개선됩니다.

꼬리질문 2. Offset 페이징과 No-Offset 페이징의 성능 차이가 데이터가 많아질수록 커지는 이유를 설명해주세요.

Offset 페이징은 offset만큼 데이터를 건너뛴 뒤 필요한 데이터를 가져옵니다.

예를 들어 100만 번째 데이터부터 20개를 가져오려면 DB는 앞의 100만 개를 건너뛰는 작업을 해야 합니다.

반면 No-Offset 페이징은 마지막으로 조회한 ID나 기준값 이후의 데이터를 조회합니다.

Offset 방식:
LIMIT 20 OFFSET 1000000

No-Offset 방식:
WHERE id < 마지막으로 조회한 id
LIMIT 20

데이터가 많아질수록 Offset 방식은 건너뛰는 비용이 커지고, No-Offset 방식은 인덱스를 활용해 다음 데이터를 바로 찾을 수 있어 더 효율적입니다.

Cache 영역

Q3. @Cacheable을 적용할 때 캐시 키를 어떻게 설계했나요?

캐시 키는 같은 요청이면 같은 캐시를 사용하고, 다른 요청이면 다른 캐시를 사용하도록 설계해야 합니다.

예를 들어 상품 검색 결과를 캐싱한다면 검색어, 카테고리, 정렬 조건, 페이지 번호, 페이지 크기 등을 키에 포함해야 합니다.

@Cacheable(
    value = "productSearch",
    key = "#keyword + ':' + #category + ':' + #page + ':' + #size"
)

캐시 키를 너무 단순하게 만들면 서로 다른 검색 조건이 같은 캐시를 공유하는 문제가 생길 수 있습니다.

반대로 너무 복잡하게 만들면 캐시 재사용률이 떨어질 수 있습니다.

꼬리질문 1. 캐시가 적용된 메서드를 같은 클래스 내부에서 호출했을 때 캐시가 동작하지 않는 경우가 있습니다. 원인이 무엇인가요?

Spring의 @Cacheable은 프록시 기반 AOP로 동작합니다.

외부에서 프록시 객체를 통해 메서드를 호출해야 캐시 로직이 적용됩니다.

하지만 같은 클래스 내부에서 this.method()처럼 호출하면 프록시를 거치지 않기 때문에 @Cacheable이 동작하지 않을 수 있습니다.

이것을 Self-invocation 문제라고 합니다.

꼬리질문 2. @CachePut과 @CacheEvict를 동시에 쓰는 방식과, DB 갱신 후 캐시를 무효화하는 방식 중 어떤 기준으로 선택하나요?

@CachePut은 DB를 갱신한 뒤 캐시도 즉시 최신 값으로 갱신할 때 사용합니다.

@CacheEvict는 DB 갱신 후 기존 캐시를 삭제하고, 다음 조회 시 다시 캐싱하게 할 때 사용합니다.

방식	사용 상황
`@CachePut`	갱신 결과가 명확하고 캐시에 바로 반영하고 싶을 때
`@CacheEvict`	여러 캐시 키에 영향이 있거나 갱신 범위가 넓을 때

검색 결과 캐시처럼 하나의 데이터 변경이 여러 페이지, 여러 검색 조건에 영향을 주는 경우에는 캐시를 직접 갱신하기보다 무효화하는 방식이 더 안전합니다.

Q4. Redis TTL 설정 기준을 어떻게 결정했나요?

Redis TTL은 데이터의 변경 빈도와 실시간성이 얼마나 중요한지 기준으로 결정합니다.

자주 바뀌지 않고 조회가 많은 데이터는 TTL을 길게 가져가고, 자주 바뀌는 데이터는 짧게 가져갑니다.

예를 들어 다음과 같이 설정할 수 있습니다.

데이터	TTL 기준
상품 상세	비교적 길게
인기 검색어	짧게
재고 정보	매우 짧게 또는 캐시 제외
이벤트 상품 목록	이벤트 기간과 변경 빈도에 맞게

특히 재고처럼 정확성이 중요한 데이터는 캐시보다 DB나 Redis 원자 연산을 기준으로 처리하는 것이 안전합니다.

꼬리질문 1. TTL이 동시에 만료된 다수의 키에 대량 요청이 몰리면 어떤 문제가 생기나요?

여러 캐시가 동시에 만료되고 요청이 몰리면 많은 요청이 한꺼번에 DB로 향할 수 있습니다.

이것을 Cache Stampede 또는 Cache Avalanche라고 합니다.

완화 방법은 다음과 같습니다.

TTL에 랜덤 값을 추가해 만료 시점을 분산
캐시 재생성 시 락을 사용해 한 요청만 DB 조회
인기 데이터는 만료 전에 미리 갱신
너무 짧은 TTL을 피함

꼬리질문 2. Redis 캐시와 DB 데이터가 불일치하는 상황이 실제로 생길 수 있는 시나리오를 하나 들어보세요.

예를 들어 상품 가격을 DB에서 수정했는데 기존 상품 상세 캐시를 삭제하지 않으면 문제가 생길 수 있습니다.

DB에는 10,000원으로 수정되었지만 Redis에는 이전 가격인 12,000원이 남아 있을 수 있습니다.

이 상태에서 사용자가 상품을 조회하면 오래된 가격을 보게 됩니다.

이런 문제를 줄이려면 DB 수정 후 관련 캐시를 무효화하거나 TTL을 짧게 설정해야 합니다.

인덱스 / 쿼리 튜닝 영역

Q5. 복합 인덱스를 설계할 때 컬럼 순서를 어떤 기준으로 결정했나요?

복합 인덱스는 자주 사용되는 조회 조건과 정렬 조건을 기준으로 설계합니다.

일반적으로 다음 기준을 고려합니다.

자주 사용되는 조건인지
동등 조건인지 범위 조건인지
카디널리티가 높은 컬럼인지
정렬에 사용되는 컬럼인지
실제 쿼리의 where, order by 순서와 맞는지

예를 들어 프로모션 상품을 상태와 시작 시간 기준으로 조회한다면 다음과 같은 인덱스를 고려할 수 있습니다.

(status, start_at, id)

단, 무조건 컬럼을 많이 넣는 것이 좋은 것은 아니고, 실제 실행 계획을 보고 결정해야 합니다.

꼬리질문 1. 복합 인덱스에서 선행 컬럼을 조건에 포함하지 않고 후행 컬럼만 조회하면 어떻게 동작하나요?

복합 인덱스는 왼쪽부터 순서대로 사용됩니다.

예를 들어 (status, category_id, created_at) 인덱스가 있을 때 category_id만 조건에 사용하면 인덱스를 제대로 활용하기 어렵습니다.

-- 인덱스 활용에 유리
WHERE status = 'OPEN' AND category_id = 1

-- 선행 컬럼이 빠져 인덱스 활용이 어려울 수 있음
WHERE category_id = 1

그래서 복합 인덱스를 만들 때는 실제 쿼리에서 자주 함께 사용되는 조건 순서를 고려해야 합니다.

꼬리질문 2. 카디널리티가 낮은 컬럼에 단독 인덱스를 생성하는 것이 비효율적인 이유를 설명해주세요.

카디널리티가 낮다는 것은 값의 종류가 적다는 뜻입니다.

예를 들어 성별, 판매 상태처럼 값의 종류가 적은 컬럼은 인덱스를 타도 많은 행을 읽어야 할 수 있습니다.

이 경우 DB 입장에서는 인덱스를 사용하는 것보다 테이블 전체를 읽는 것이 더 빠를 수도 있습니다.

그래서 카디널리티가 낮은 컬럼은 단독 인덱스보다 다른 조건과 함께 복합 인덱스로 설계하는 경우가 많습니다.

Q6. EXPLAIN 실행 계획에서 type 컬럼이 ALL로 표시될 때 어떤 의미이고, 어떻게 접근해서 개선했나요?

type이 ALL로 표시된다는 것은 Full Table Scan을 의미합니다.

즉, 조건에 맞는 데이터를 찾기 위해 테이블 전체를 읽는다는 뜻입니다.

개선할 때는 다음 순서로 접근합니다.

실제 쿼리의 WHERE, ORDER BY, JOIN 조건 확인
사용 가능한 인덱스가 있는지 확인
인덱스 컬럼 순서가 쿼리 조건과 맞는지 확인
불필요한 join이나 select 컬럼 제거
데이터 분포와 카디널리티 확인
다시 EXPLAIN으로 실행 계획 확인

단순히 인덱스를 추가하는 것이 아니라, 실제 쿼리 패턴과 실행 계획을 함께 봐야 합니다.

꼬리질문 1. 인덱스가 존재하는데도 옵티마이저가 Full Scan을 선택하는 경우가 있습니다. 어떤 상황인가요?

인덱스가 있어도 옵티마이저가 Full Scan이 더 빠르다고 판단하면 인덱스를 사용하지 않을 수 있습니다.

대표적인 경우는 다음과 같습니다.

조건에 맞는 데이터가 너무 많을 때
카디널리티가 낮은 컬럼일 때
인덱스 컬럼에 함수나 연산을 적용했을 때
LIKE 검색이 %keyword처럼 앞에 와일드카드로 시작할 때
통계 정보가 오래되었을 때
조회 컬럼이 많아 결국 테이블 접근이 많이 필요한 경우

꼬리질문 2. 인덱스를 추가했는데 오히려 쓰기 성능이 나빠질 수 있습니다. 어떤 트레이드오프가 있나요?

인덱스는 조회 성능을 높일 수 있지만, 쓰기 작업에는 비용이 추가됩니다.

데이터를 INSERT, UPDATE, DELETE할 때 테이블뿐만 아니라 인덱스도 함께 갱신해야 하기 때문입니다.

따라서 인덱스가 많아질수록 저장 공간도 늘어나고 쓰기 성능은 떨어질 수 있습니다.

그래서 인덱스는 “조회에 자주 사용되는 쿼리”를 기준으로 필요한 만큼만 추가해야 합니다.

동시성 영역

Q7. 재고 차감처럼 동시성 이슈가 생기는 도메인 로직에 낙관적 락과 비관적 락 중 무엇을 선택했고, 그 이유가 무엇인가요?

재고 차감처럼 초과 판매가 발생하면 안 되는 로직에서는 비관적 락을 선택할 수 있습니다.

비관적 락은 데이터를 수정하기 전에 먼저 락을 걸어서 다른 트랜잭션이 동시에 수정하지 못하게 막습니다.

재고가 적고 요청이 몰리는 선착순 이벤트 상황에서는 충돌 가능성이 높기 때문에, 낙관적 락보다 비관적 락이 더 단순하고 안전할 수 있습니다.

다만 비관적 락은 락 대기 시간이 길어지면 성능 저하가 발생할 수 있으므로 트랜잭션 범위를 짧게 가져가야 합니다.

꼬리질문 1. 낙관적 락에서 충돌이 발생했을 때 재시도 로직은 어떻게 구현했나요?

낙관적 락은 version 컬럼을 기준으로 충돌을 감지합니다.

동시에 여러 요청이 같은 재고를 수정하면 먼저 커밋한 요청만 성공하고, 나중 요청은 버전 불일치로 예외가 발생합니다.

이때 재시도 로직을 둘 수 있습니다.

1. 재고 조회
2. 재고 차감 시도
3. OptimisticLockException 발생
4. 짧은 대기 후 재시도
5. 최대 재시도 횟수 초과 시 실패 처리

재시도 횟수는 무한정으로 두면 안 되고, 예를 들어 3회처럼 제한을 두는 것이 안전합니다.

꼬리질문 2. 비관적 락 사용 시 데드락이 발생할 수 있는 시나리오를 설명해주세요.

데드락은 두 트랜잭션이 서로가 가진 락을 기다리면서 멈추는 상황입니다.

예를 들어 주문 A는 상품 1번을 먼저 잠그고 상품 2번을 기다리고, 주문 B는 상품 2번을 먼저 잠그고 상품 1번을 기다리면 데드락이 발생할 수 있습니다.

이를 줄이려면 여러 row에 락을 걸 때 항상 같은 순서로 접근해야 합니다.

예를 들어 상품 ID 오름차순으로 정렬한 뒤 락을 획득하는 방식이 있습니다.

Q8. Redis 기반 분산 락을 구현할 때, 락을 보유한 서버가 갑자기 죽으면 어떻게 되나요?

Redis 분산 락은 보통 TTL을 함께 설정합니다.

락을 획득한 서버가 갑자기 죽더라도 TTL이 지나면 락이 자동으로 만료되어 다른 서버가 다시 락을 획득할 수 있습니다.

만약 TTL 없이 락을 잡으면 서버 장애 시 락이 영원히 풀리지 않는 문제가 생길 수 있습니다.

그래서 분산 락에서는 다음이 중요합니다.

락에 TTL 설정
락 소유자 식별값 저장
락 해제 시 내가 잡은 락인지 확인
비즈니스 로직보다 TTL이 너무 짧지 않게 설정

꼬리질문 1. Lettuce의 스핀 락 방식과 Redisson의 pub/sub 방식 중 어떤 상황에서 Redisson이 더 적합한가요?

Lettuce로 직접 분산 락을 구현하면 보통 락을 얻을 때까지 Redis에 반복 요청하는 스핀 락 방식이 됩니다.

요청이 적으면 단순해서 사용할 수 있지만, 요청이 많으면 Redis에 부담이 커질 수 있습니다.

Redisson은 pub/sub 방식으로 락 해제 이벤트를 기다릴 수 있어 불필요한 반복 요청을 줄일 수 있습니다.

따라서 트래픽이 많고 락 경합이 자주 발생하는 상황에서는 Redisson이 더 적합할 수 있습니다.

꼬리질문 2. 분산 락을 AOP로 분리한다면 어떤 장점이 있고, 주의해야 할 점은 무엇인가요?

분산 락을 AOP로 분리하면 비즈니스 로직에서 락 획득과 해제 코드를 제거할 수 있습니다.

장점은 다음과 같습니다.

중복 코드 감소
락 처리 로직 일관성 유지
비즈니스 로직 가독성 향상
여러 메서드에 공통 적용 가능

주의할 점은 다음과 같습니다.

락 획득 후 트랜잭션이 시작되는 순서를 고려해야 함
락 해제가 반드시 finally에서 수행되어야 함
락 key를 잘못 설계하면 불필요하게 넓은 범위가 잠김
Self-invocation으로 AOP가 적용되지 않을 수 있음

AOP / 테스트 영역

Q9. AOP를 통해 횡단 관심사를 분리했을 때, @Transactional과 커스텀 AOP 어드바이스가 같은 메서드에 적용되면 실행 순서가 어떻게 되나요?

@Transactional도 Spring AOP 기반으로 동작하고, 커스텀 AOP도 프록시 기반으로 동작합니다.

둘 다 같은 메서드에 적용되면 @Order 설정이나 우선순위에 따라 실행 순서가 달라질 수 있습니다.

예를 들어 분산 락 AOP와 트랜잭션이 함께 있다면 보통 다음 순서를 의도합니다.

락 획득
→ 트랜잭션 시작
→ 비즈니스 로직 실행
→ 트랜잭션 커밋
→ 락 해제

이렇게 해야 트랜잭션이 끝나기 전에 락이 먼저 풀려서 다른 요청이 들어오는 문제를 줄일 수 있습니다.

꼬리질문 1. Self-invocation 문제가 발생하는 원인이 무엇인가요? @Transactional과 @Cacheable에서도 같은 문제가 생기나요?

Self-invocation은 같은 클래스 내부에서 자기 자신의 메서드를 직접 호출할 때 발생합니다.

Spring AOP는 프록시 객체를 거쳐야 동작하는데, 내부 호출은 프록시를 거치지 않고 this.method()로 호출됩니다.

그래서 @Transactional, @Cacheable, 커스텀 AOP 모두 같은 문제가 발생할 수 있습니다.

해결 방법은 다음과 같습니다.

메서드를 다른 Bean으로 분리
외부에서 프록시를 통해 호출되도록 구조 변경
필요 시 AspectJ 방식 고려

꼬리질문 2. AOP 어드바이스 내부에서 예외가 발생했을 때 트랜잭션 롤백은 어떻게 되나요?

트랜잭션 안에서 예외가 발생하고 해당 예외가 밖으로 전파되면 롤백됩니다.

기본적으로 Spring은 RuntimeException과 Error에 대해 롤백합니다.

다만 AOP 어드바이스에서 예외를 잡고 삼켜버리면 트랜잭션은 정상 처리로 판단할 수 있습니다.

그래서 롤백이 필요한 예외는 반드시 다시 던지거나, rollbackFor 옵션을 명확히 설정해야 합니다.

Q10. 멀티 스레드 환경에서 동시성 이슈를 재현하는 테스트를 어떻게 작성했나요?

동시성 테스트는 ExecutorService와 CountDownLatch를 사용해 여러 스레드가 동시에 같은 로직을 실행하도록 작성할 수 있습니다.

흐름은 다음과 같습니다.

테스트용 상품과 재고를 생성합니다.
여러 개의 스레드를 준비합니다.
CountDownLatch로 동시에 시작하도록 맞춥니다.
각 스레드가 재고 차감 요청을 보냅니다.
모든 스레드가 끝날 때까지 기다립니다.
최종 재고와 성공한 요청 수를 검증합니다.

ExecutorService executorService = Executors.newFixedThreadPool(10);
CountDownLatch latch = new CountDownLatch(10);

for (int i = 0; i < 10; i++) {
    executorService.submit(() -> {
        try {
            stockService.decreaseStock(productId);
        } finally {
            latch.countDown();
        }
    });
}

latch.await();

이 테스트를 통해 동시에 요청이 들어와도 재고가 음수가 되지 않는지 확인할 수 있습니다.

꼬리질문 1. CountDownLatch + ExecutorService로 동시 요청을 시뮬레이션하는 방식의 한계가 무엇인가요?

이 방식은 동시성 문제를 재현하는 데 도움이 되지만 실제 운영 환경을 완전히 대체할 수는 없습니다.

한계는 다음과 같습니다.

실제 네트워크 지연이 반영되지 않음
여러 서버 인스턴스 환경을 완전히 재현하기 어려움
DB 커넥션 풀, Redis, 외부 API 병목을 모두 반영하기 어려움
스레드 스케줄링에 따라 테스트 결과가 달라질 수 있음
테스트에서 통과해도 운영 트래픽에서는 문제가 생길 수 있음

그래서 단위 테스트뿐만 아니라 통합 테스트, 부하 테스트도 함께 고려해야 합니다.

꼬리질문 2. 동시성 테스트가 로컬에서는 통과했는데 운영 환경에서 문제가 생기는 경우가 있다면 어떤 요인 때문일까요?

운영 환경은 로컬보다 훨씬 많은 변수가 있습니다.

대표적인 원인은 다음과 같습니다.

서버 인스턴스가 여러 대로 늘어난 경우
DB 커넥션 풀이 부족한 경우
트랜잭션 시간이 길어진 경우
Redis Lock TTL이 너무 짧거나 긴 경우
네트워크 지연이 발생한 경우
실제 요청량이 테스트보다 많은 경우
락 획득 순서가 일정하지 않아 데드락이 발생한 경우
외부 API 응답 지연으로 커넥션이 오래 점유된 경우

따라서 운영 환경을 고려한 동시성 제어는 단순히 로컬 테스트 통과만으로 끝내면 안 되고, 락 범위, 트랜잭션 범위, 커넥션 풀, 장애 복구까지 함께 검토해야 합니다.

마무리 정리

CH5 플러스 스프링 면접에서는 단순 CRUD보다 성능 최적화와 동시성 제어를 얼마나 이해하고 있는지 확인할 가능성이 높습니다.

특히 다음 키워드는 꼭 연결해서 설명할 수 있어야 합니다.

QueryDSL 동적 쿼리
BooleanExpression과 null-safe 조건 처리
페이징 count 쿼리 최적화
Offset / No-Offset 페이징 차이
Redis Cache와 TTL
Cache Stampede
복합 인덱스 컬럼 순서
EXPLAIN 실행 계획 분석
낙관적 락과 비관적 락
Redis 분산 락
Lettuce와 Redisson 차이
AOP 실행 순서
Self-invocation 문제
동시성 테스트 한계

면접에서는 “기능을 구현했다”보다 왜 이 방식을 선택했는지, 어떤 문제가 생길 수 있는지, 그 문제를 어떻게 완화했는지까지 함께 말하는 것이 중요합니다.

출처: 내일배움 스파르타 클럽

CH4 클라우드·결제시스템 모의면접 예상질문 리스트

Mon, 29 Jun 2026 03:11:31 GMT

CH4 클라우드·결제 시스템 모의면접 예상질문 정리

AWS 배포, Docker, HTTPS, PortOne V2 결제, Webhook, 포인트 결제, 환불, 재고 정합성, 정기 구독 결제까지 CH4 프로젝트에서 나올 수 있는 면접 질문과 핵심 답변을 정리했습니다.

AWS · 배포 영역

Q1. EC2, RDS, S3를 함께 사용하는 이유가 뭔가요? 각각 어떤 역할을 담당했나요?

EC2, RDS, S3는 각각 역할이 다르기 때문에 함께 사용했습니다.

EC2: Spring Boot 애플리케이션을 실행하는 서버
RDS: MySQL 데이터베이스를 관리하는 서비스
S3: 이미지, 파일 같은 정적 리소스를 저장하는 스토리지

EC2에 애플리케이션을 배포하고, 데이터는 RDS에 저장하며, 파일은 S3에 저장해서 서버와 저장소의 책임을 분리했습니다.

꼬리질문 1. EC2와 RDS를 같은 VPC 안에 두면서 보안 그룹은 어떻게 설정했나요?

EC2와 RDS는 같은 VPC 안에 두고, RDS는 외부에서 직접 접근하지 못하도록 설정했습니다.

보안 그룹은 보통 다음과 같이 구성합니다.

EC2: 80, 443, 필요 시 22번 포트 허용
RDS: 3306 포트를 EC2 보안 그룹에서 오는 요청만 허용

즉, 사용자는 EC2에만 접근하고, DB는 EC2를 통해서만 접근할 수 있게 구성합니다.

꼬리질문 2. RDS 대신 EC2에 직접 MySQL을 설치하는 방식과 비교했을 때 단점은 없나요?

RDS는 관리형 서비스라 편리하지만 비용이 더 들 수 있고, 세부 설정을 완전히 직접 제어하기는 어렵습니다.

반대로 EC2에 직접 MySQL을 설치하면 비용이나 설정 자유도는 장점이 될 수 있지만, 백업, 장애 복구, 보안 패치, 모니터링을 직접 관리해야 해서 운영 부담이 커집니다.

Q2. Docker로 애플리케이션을 컨테이너화한 이유가 뭔가요?

Docker를 사용하면 애플리케이션 실행 환경을 이미지로 고정할 수 있습니다.

개발 환경과 배포 환경의 Java 버전, 라이브러리, 실행 방식 차이를 줄일 수 있고, 어디서 실행하더라도 동일한 방식으로 애플리케이션을 띄울 수 있습니다.

즉, 배포 환경의 차이로 발생하는 문제를 줄이기 위해 사용했습니다.

꼬리질문 1. Dockerfile 작성 시 이미지 크기를 줄이기 위해 고려한 것이 있나요?

이미지 크기를 줄이기 위해 다음을 고려할 수 있습니다.

빌드 단계와 실행 단계를 분리하는 Multi-stage build 사용
실행에 필요 없는 Gradle 캐시, 테스트 파일, 소스 파일 제외
JDK 대신 실행만 가능한 JRE 기반 이미지 사용
불필요한 패키지 설치 최소화

이렇게 하면 최종 이미지에는 애플리케이션 실행에 필요한 파일만 포함할 수 있습니다.

꼬리질문 2. CI/CD 파이프라인에서 테스트 실패 시 배포가 어떻게 차단되나요?

CI/CD 파이프라인에서 보통 test 단계와 deploy 단계를 분리합니다.

./gradlew test가 실패하면 해당 job이 실패 상태가 되고, 그 다음 배포 job이 실행되지 않도록 설정합니다.

즉, 테스트를 통과한 코드만 Docker 이미지 빌드와 배포 단계로 넘어가게 해서 안정성을 높입니다.

Q3. HTTPS를 적용한 이유와 적용 방식을 설명해주세요.

HTTPS는 클라이언트와 서버 사이의 통신을 암호화하기 위해 적용합니다.

로그인 정보, 결제 정보, 개인정보가 네트워크에서 평문으로 노출되는 것을 막을 수 있습니다.

적용 방식은 보통 다음과 같습니다.

도메인 연결
SSL/TLS 인증서 발급
Nginx 또는 ALB에 인증서 적용
HTTP 요청을 HTTPS로 리다이렉트

꼬리질문 1. Let's Encrypt를 쓰는 방식과 ACM을 쓰는 방식의 차이가 뭔가요?

Let's Encrypt는 무료 인증서를 발급받아 EC2나 Nginx에 직접 적용하는 방식입니다.

ACM은 AWS Certificate Manager에서 인증서를 발급받고, ALB나 CloudFront 같은 AWS 서비스에 연결하는 방식입니다.

구분	Let's Encrypt	ACM
적용 위치	EC2, Nginx 등	ALB, CloudFront 등
관리 방식	직접 갱신 설정 필요	AWS 서비스와 연동 시 관리 편리
사용 상황	EC2 단독 구성	ALB, CloudFront 사용 구성

꼬리질문 2. ALB 없이 EC2 한 대에 HTTPS를 적용하려면 어떻게 해야 하나요?

EC2에 Nginx를 설치하고, Certbot으로 Let's Encrypt 인증서를 발급받아 Nginx에 적용할 수 있습니다.

흐름은 다음과 같습니다.

도메인을 EC2 Public IP에 연결
EC2 보안 그룹에서 80, 443 포트 허용
Nginx 설치
Certbot으로 SSL 인증서 발급
Nginx에서 443 포트 SSL 설정
80번 HTTP 요청을 443번 HTTPS로 리다이렉트

결제 시스템 영역

Q4. PortOne V2 기반 결제 흐름, Client Confirm 방식을 처음부터 끝까지 설명해주세요.

Client Confirm 방식은 클라이언트에서 결제창을 띄우고, 서버에서 최종 검증과 확정 처리를 하는 방식입니다.

전체 흐름은 다음과 같습니다.

사용자가 주문을 요청합니다.
서버가 주문 금액, 할인 금액, 포인트 사용 금액을 계산합니다.
서버가 결제 대기 상태의 주문과 결제 정보를 생성합니다.
클라이언트가 PortOne SDK로 결제창을 호출합니다.
결제 성공 후 클라이언트가 paymentId 등을 서버로 전달합니다.
서버가 PortOne 결제 정보를 조회하거나 confirm API를 호출합니다.
서버가 주문 금액과 실제 결제 금액을 검증합니다.
검증 성공 시 결제 상태를 PAID로 변경합니다.
주문 상태, 포인트 내역, 재고 상태를 함께 확정합니다.

핵심은 클라이언트 응답만 믿지 않고, 서버가 최종적으로 금액과 상태를 검증한 뒤 결제를 확정하는 것입니다.

꼬리질문 1. 사전 금액 검증을 서버에서 하는 이유가 뭔가요? 클라이언트에서 처리하면 안 되나요?

클라이언트 값은 사용자가 조작할 수 있기 때문입니다.

상품 금액, 할인 금액, 포인트 사용 금액을 클라이언트에서만 계산하면 결제 금액을 임의로 낮춰 보낼 위험이 있습니다.

따라서 최종 결제 금액은 반드시 서버가 DB 기준으로 다시 계산하고 검증해야 합니다.

꼬리질문 2. 결제 검증 후 확정 처리 중 서버가 다운되면 어떻게 되나요?

결제는 PG에서는 성공했지만, 내부 DB에는 반영되지 않은 상태가 될 수 있습니다.

이를 대비해 결제 확정 로직은 멱등하게 설계해야 합니다.

예를 들어 같은 paymentId로 다시 요청이 들어와도 이미 처리된 결제라면 중복 처리하지 않고 기존 결과를 반환합니다.

또한 Webhook이나 결제 상태 재조회 배치를 통해 PG 결제 상태와 내부 결제 상태를 다시 맞출 수 있습니다.

Q5. Webhook 멱등성 처리를 어떻게 구현했나요?

Webhook은 같은 이벤트가 여러 번 올 수 있다고 가정하고 멱등하게 처리해야 합니다.

보통 다음 기준으로 중복 처리를 막습니다.

webhookEventId
paymentId
orderId
결제 상태값

처리 흐름은 다음과 같습니다.

Webhook 요청을 받습니다.
HMAC signature를 검증합니다.
이벤트 ID 또는 paymentId로 이미 처리된 이벤트인지 확인합니다.
이미 처리된 경우 바로 성공 응답을 반환합니다.
아직 처리되지 않았다면 결제 상태를 조회하고 내부 상태를 변경합니다.
처리 완료 이벤트를 저장합니다.

핵심은 같은 Webhook이 여러 번 와도 결제, 포인트, 재고가 중복 변경되지 않게 하는 것입니다.

꼬리질문 1. HMAC 서명 검증은 어느 시점에 처리했나요?

Webhook 요청을 받은 직후, 비즈니스 로직을 실행하기 전에 처리합니다.

서명 검증에 실패한 요청은 신뢰할 수 없는 요청이므로 결제 상태 변경, 포인트 환불, 재고 복구 같은 내부 로직을 실행하면 안 됩니다.

즉, HMAC 검증은 Webhook 처리의 가장 앞단에서 수행해야 합니다.

꼬리질문 2. Webhook 수신에 실패했을 때 PortOne이 재전송을 보장하나요?

외부 결제사의 Webhook 재전송 정책에만 의존하면 위험합니다.

서버 장애, 네트워크 장애, 응답 지연 등으로 Webhook이 누락되거나 늦게 도착할 수 있기 때문입니다.

따라서 Webhook은 보조 수단으로 보고, 서버에서는 결제 단건 조회 API나 상태 동기화 배치를 통해 결제 상태를 다시 확인할 수 있게 설계하는 것이 안전합니다.

Q6. 포인트 + PG 복합 결제에서 PG 실결제 금액을 어떻게 산정했나요?

PG 실결제 금액은 최종 주문 금액에서 사용 포인트를 차감해서 계산했습니다.

PG 실결제 금액 = 최종 주문 금액 - 사용 포인트

예를 들어 주문 금액이 50,000원이고 포인트를 10,000원 사용하면 PG 결제 금액은 40,000원입니다.

다만 포인트 사용 가능 여부는 서버에서 검증해야 합니다.

사용자의 포인트 잔액이 충분한지
주문 금액보다 많은 포인트를 사용하지 않았는지
최소 결제 금액 정책을 만족하는지
이미 사용 처리된 포인트가 아닌지

꼬리질문 1. 결제 취소 시 포인트 환불은 어떻게 처리했나요?

결제 취소나 환불이 성공하면 사용했던 포인트를 다시 복구합니다.

이때 단순히 잔액만 증가시키는 것이 아니라, 포인트 사용 취소 내역을 포인트 거래 원장에 남기는 방식이 좋습니다.

예를 들어 다음과 같이 기록합니다.

결제 시: USE
환불 시: REFUND

이렇게 하면 포인트가 왜 증가하거나 감소했는지 추적할 수 있습니다.

꼬리질문 2. 포인트 잔액보다 많은 포인트를 사용하려는 요청은 어떻게 처리했나요?

서버에서 사용자의 현재 포인트 잔액을 조회하고, 요청 포인트가 잔액보다 크면 예외를 발생시킵니다.

이 경우 결제창을 띄우기 전에 요청을 차단해야 합니다.

응답은 보통 400 Bad Request로 처리하고, 메시지는 “보유 포인트보다 많은 포인트를 사용할 수 없습니다.”처럼 반환할 수 있습니다.

Q7. 부분 환불 시 결제수단별 비율 분리 산정과 반올림 오차 보정을 어떻게 구현했나요?

포인트와 PG가 함께 사용된 결제에서는 환불 금액을 결제수단별로 나눠야 합니다.

예를 들어 총 결제 금액이 100,000원이고, 포인트 20,000원, PG 80,000원으로 결제했다면 비율은 다음과 같습니다.

포인트: 20%
PG: 80%

부분 환불 금액이 30,000원이라면 비율대로 계산합니다.

포인트 환불: 6,000원
PG 환불: 24,000원

다만 나눗셈 과정에서 소수점이 생길 수 있기 때문에 반올림 오차를 보정해야 합니다.

PG 환불 금액 = 전체 환불 금액 - 포인트 환불 금액

이렇게 계산하면 포인트와 PG 환불 금액의 합이 항상 전체 환불 금액과 일치합니다.

꼬리질문 1. 반올림 오차를 PG에 몰아주는 이유가 있나요?

포인트는 내부 시스템에서 직접 관리할 수 있지만, PG 환불 금액은 외부 결제사에 정확한 금액으로 요청해야 합니다.

따라서 전체 환불 금액과 결제수단별 환불 합계가 어긋나면 안 됩니다.

한쪽을 기준으로 계산하고 나머지를 차액으로 보정하면 총액 불일치 문제를 줄일 수 있습니다.

실무에서는 회사 정책에 따라 오차를 포인트에 둘 수도 있고 PG에 둘 수도 있지만, 중요한 것은 합계가 정확히 맞도록 일관된 기준을 두는 것입니다.

꼬리질문 2. 여러 상품 중 일부만 환불하는 부분 환불과, 전체 금액의 일부만 환불하는 경우를 구분해서 처리했나요?

네, 구분해서 처리하는 것이 좋습니다.

상품 단위 부분 환불: 특정 주문 상품의 수량과 금액을 기준으로 환불
금액 단위 부분 환불: 전체 결제 금액 중 일부 금액만 환불

상품 단위 환불은 재고 복구, 주문 상품 상태 변경, 환불 가능 수량 검증이 함께 필요합니다.

반면 금액 단위 환불은 주로 결제 금액 정산과 환불 한도 검증이 중요합니다.

Q8. 재고 선차감 정책과 단일 트랜잭션 기반 정합성 보장을 어떻게 설계했나요?

재고 선차감 정책은 주문 생성 시점에 재고를 먼저 차감하는 방식입니다.

결제까지 기다렸다가 재고를 차감하면 동시에 많은 사용자가 결제할 때 초과 판매가 발생할 수 있습니다.

그래서 주문 생성 시점에 재고를 차감하고, 결제 실패나 주문 취소가 발생하면 재고를 복구하는 방식으로 설계합니다.

흐름은 다음과 같습니다.

주문 요청을 받습니다.
상품 재고를 조회합니다.
재고가 충분한지 검증합니다.
재고를 차감합니다.
주문을 생성합니다.
결제 대기 상태로 저장합니다.
결제 실패 또는 취소 시 재고를 복구합니다.

이 과정은 하나의 트랜잭션 안에서 처리해서 주문 생성과 재고 차감이 함께 성공하거나 함께 실패하도록 해야 합니다.

꼬리질문 1. 비관적 락 대신 낙관적 락을 사용하지 않은 이유가 있나요?

재고처럼 동시에 많은 요청이 몰리고, 초과 판매가 절대 발생하면 안 되는 경우에는 비관적 락이 더 단순하고 안전할 수 있습니다.

낙관적 락은 충돌이 적을 때 유리하지만, 충돌이 많으면 재시도가 많이 발생할 수 있습니다.

반면 비관적 락은 먼저 데이터에 락을 걸고 처리하므로 같은 재고를 동시에 수정하는 상황을 강하게 제어할 수 있습니다.

꼬리질문 2. 인스턴스가 N대로 늘어나도 지금의 재고 동시성 제어가 그대로 유효할까요?

DB의 비관적 락을 사용한다면 애플리케이션 인스턴스가 여러 대로 늘어나도 같은 DB row에 대한 락이 걸리기 때문에 기본적인 정합성은 유지됩니다.

하지만 애플리케이션 내부의 synchronized 같은 JVM 락만 사용했다면 인스턴스가 여러 대일 때는 유효하지 않습니다.

인스턴스가 N대로 늘어나는 환경에서는 DB Lock, Redis Lock 같은 외부 공유 자원을 기준으로 동시성을 제어해야 합니다.

꼬리질문 3. 커넥션 점유가 늘어나면 어떤 일이 발생할까요?

트랜잭션이 오래 걸리거나 락 대기가 길어지면 DB 커넥션이 오래 점유됩니다.

그 결과 커넥션 풀이 고갈되고, 다른 요청들이 DB 커넥션을 얻지 못해 지연되거나 실패할 수 있습니다.

그래서 트랜잭션 범위를 짧게 유지하고, 외부 API 호출을 트랜잭션 안에서 오래 수행하지 않도록 주의해야 합니다.

Q9. 빌링키 기반 정기 구독 결제와 스케줄러 멱등 처리를 어떻게 구현했나요?

빌링키 기반 정기 결제는 사용자가 최초 1회 결제수단을 등록하면, 이후에는 서버가 빌링키를 이용해 정해진 주기마다 자동 결제를 요청하는 방식입니다.

구현 흐름은 다음과 같습니다.

사용자가 결제수단을 등록합니다.
PortOne을 통해 빌링키를 발급받습니다.
서버에 빌링키와 구독 정보를 저장합니다.
스케줄러가 결제 예정 구독을 조회합니다.
결제 요청을 보냅니다.
결제 성공 시 다음 결제일을 갱신합니다.
결제 실패 시 실패 상태와 재시도 정보를 저장합니다.

스케줄러는 중복 실행될 수 있으므로 멱등하게 처리해야 합니다.

예를 들어 subscriptionId + billingDate 기준으로 결제 시도 이력을 저장하고, 이미 처리된 결제일이면 다시 결제하지 않도록 막습니다.

꼬리질문 1. 정기 결제 실패 시 재시도 정책은 어떻게 설정했나요?

정기 결제 실패 시 바로 구독을 종료하기보다는 재시도 정책을 둘 수 있습니다.

예를 들어 다음과 같이 처리할 수 있습니다.

1차 실패: 실패 이력 저장 후 다음 날 재시도
2차 실패: 사용자에게 결제 실패 알림
3차 실패: 구독 일시 중지 또는 만료 처리

재시도 횟수와 주기는 서비스 정책에 따라 정하고, 중복 결제가 발생하지 않도록 결제 시도 이력을 반드시 저장해야 합니다.

꼬리질문 2. 등급별 적립률 차등 적용은 어떻게 관리했나요?

회원 등급별 적립률은 코드에 하드코딩하기보다 정책 테이블이나 Enum으로 관리할 수 있습니다.

예를 들어 BASIC, VIP, VVIP 등급에 따라 적립률을 다르게 두고, 결제 완료 시점에 회원 등급을 조회해서 적립 포인트를 계산합니다.

중요한 점은 결제 당시 적용된 적립률을 이력으로 남기는 것입니다.

나중에 등급 정책이 바뀌더라도 과거 결제의 적립 내역은 그대로 추적할 수 있어야 합니다.

Q10. 결제 성공 응답과 Webhook 이벤트가 동시에 들어오거나, 서로 다른 시점에 지연 도착하는 상황을 고려해 결제 확정 로직을 어떻게 설계했나요?

결제 성공 응답과 Webhook은 도착 순서가 보장되지 않습니다.

클라이언트 성공 응답이 먼저 올 수도 있고, Webhook이 먼저 올 수도 있으며, 둘 다 동시에 들어올 수도 있습니다.

그래서 결제 확정 로직은 하나의 공통 메서드로 모으고, 멱등하게 처리해야 합니다.

예를 들어 다음과 같이 설계할 수 있습니다.

클라이언트 성공 응답 또는 Webhook 수신
paymentId 기준으로 결제 정보 조회
이미 PAID 상태라면 추가 처리 없이 종료
아직 대기 상태라면 PortOne 결제 상태 조회
금액, 주문번호, 상태 검증
검증 성공 시 내부 결제 상태를 PAID로 변경
주문, 포인트, 재고 상태를 확정
처리 이력 저장

핵심은 어느 경로로 들어오든 같은 확정 로직을 타게 만드는 것입니다.

그래야 중복 요청, 지연 요청, 동시 요청 상황에서도 결제가 한 번만 확정됩니다.

Q11. 결제 실패가 발생했을 때 원인을 어떻게 추적할 수 있나요?

결제 실패 원인을 추적하려면 외부 PG 응답과 내부 서버 로그를 연결할 수 있어야 합니다.

이를 위해 다음 값을 로그와 DB에 남기는 것이 좋습니다.

orderId
paymentId
PortOne transaction id
요청 금액
실제 결제 금액
결제 상태
실패 코드
실패 메시지
Webhook event id
요청 시각과 응답 시각

이렇게 남겨두면 결제 실패가 외부 PG 문제인지, 서버 검증 실패인지, 내부 트랜잭션 문제인지 추적할 수 있습니다.

꼬리질문. 외부 PG, Webhook, 내부 트랜잭션 장애 발생 시 어떻게 대응할 수 있나요?

장애 위치에 따라 대응 방식이 달라집니다.

장애 위치	대응 방식
외부 PG 장애	실패 응답 저장, 사용자에게 결제 실패 안내, 재시도 유도
Webhook 장애	결제 단건 조회 API나 배치로 상태 재동기화
내부 트랜잭션 장애	결제 상태와 내부 주문 상태 불일치 여부 확인 후 보정
DB 장애	트랜잭션 롤백, 실패 로그 저장, 재처리 대상 등록
네트워크 장애	timeout 설정, 재시도 정책, 중복 처리 방지

중요한 것은 결제 성공 여부를 클라이언트 응답만으로 판단하지 않고, PG 결제 상태와 내부 DB 상태를 비교해서 불일치를 복구할 수 있게 만드는 것입니다.

마무리 정리

CH4 클라우드·결제 시스템 면접에서는 단순히 기능 구현 여부보다 장애 상황에서 정합성을 어떻게 보장했는지를 많이 물어볼 수 있습니다.

특히 다음 키워드는 꼭 연결해서 답변하는 것이 좋습니다.

EC2, RDS, S3의 역할 분리
VPC와 보안 그룹 설정
Docker를 통한 실행 환경 통일
HTTPS 적용 이유
서버 기준 결제 금액 검증
Webhook 멱등성
포인트 원장 관리
부분 환불 금액 산정
재고 선차감과 복구
트랜잭션과 락
결제 실패 추적과 상태 보정

면접에서는 “구현했습니다”에서 끝내기보다, 왜 그렇게 설계했는지, 장애가 나면 어떻게 복구할 수 있는지, 중복 요청이 와도 안전한지까지 함께 설명하는 것이 중요합니다.

출처: 내일배움 스파르타 클럽

CH1-3 Java ~ 숙련 Spring 모의면접 예상질문 리스트

Mon, 29 Jun 2026 03:08:34 GMT

CH1-3 Java ~ 숙련 Spring 모의면접 예상질문 정리

Java / OOP, HTTP / Web, Spring, JPA, 인증 영역에서 자주 나올 수 있는 면접 질문과 핵심 답변을 정리했습니다.

Java / OOP 영역

Q1. OOP의 4가지 특징을 설명해주세요.

OOP의 4가지 특징은 캡슐화, 상속, 다형성, 추상화입니다.

캡슐화: 데이터와 기능을 하나의 객체로 묶고, 외부에서 직접 접근하지 못하게 보호하는 것
상속: 부모 클래스의 필드와 메서드를 자식 클래스가 물려받아 재사용하는 것
다형성: 같은 타입으로 여러 구현 객체를 다룰 수 있는 것
추상화: 공통된 특징만 뽑아 복잡한 내부 구현을 숨기고 필요한 기능만 보여주는 것

꼬리질문 1. 캡슐화와 은닉화는 같은 개념인가요?

완전히 같은 개념은 아닙니다.

은닉화는 필드를 private으로 막는 것처럼 내부 데이터를 숨기는 개념이고, 캡슐화는 데이터와 메서드를 객체 안에 묶고 필요한 기능만 외부에 제공하는 더 넓은 개념입니다.

꼬리질문 2. 다형성을 실제 코드에서 어떻게 활용했나요?

예를 들어 PaymentService가 KakaoPay, TossPay 같은 구체 클래스가 아니라 PaymentClient 인터페이스에 의존하게 만들 수 있습니다.

그러면 결제 방식이 바뀌어도 서비스 코드는 크게 변경하지 않고 구현체만 교체할 수 있습니다.

Q2. 오버로딩과 오버라이딩의 차이를 설명해주세요.

오버로딩은 같은 이름의 메서드를 매개변수 개수나 타입을 다르게 해서 여러 개 정의하는 것입니다.

오버라이딩은 부모 클래스나 인터페이스의 메서드를 자식 클래스에서 재정의하는 것입니다.

구분	오버로딩	오버라이딩
기준	메서드 이름 같음	부모 메서드 재정의
매개변수	달라야 함	같아야 함
반환 타입	자유로움	같거나 하위 타입
시점	컴파일 시점	런타임 시점

꼬리질문 1. `@Override`를 붙이지 않아도 동작하는데 왜 붙이나요?

@Override를 붙이면 컴파일러가 실제로 오버라이딩이 맞는지 검사해줍니다.

메서드 이름이나 파라미터를 실수로 잘못 작성했을 때 컴파일 단계에서 오류를 잡을 수 있어서 안정성이 높아집니다.

꼬리질문 2. 오버라이딩된 메서드에서 부모 메서드를 호출하려면 어떻게 하나요?

super.메서드명()을 사용합니다.

예를 들어 super.print()처럼 호출하면 부모 클래스의 원래 메서드를 실행할 수 있습니다.

Q3. 인터페이스와 추상 클래스의 차이를 설명하고, 어떤 상황에서 각각 선택하나요?

인터페이스는 객체가 반드시 구현해야 하는 기능의 규칙을 정의할 때 사용합니다.

추상 클래스는 공통 필드나 공통 로직을 자식 클래스에 물려주면서 일부 메서드는 자식이 직접 구현하게 할 때 사용합니다.

구분	인터페이스	추상 클래스
목적	기능 명세, 규칙 정의	공통 로직 재사용
다중 구현	가능	불가능
필드	상수 중심	인스턴스 필드 가능
생성자	없음	있음

꼬리질문 1. Java 8 이후 default 메서드가 생겼는데 추상 클래스와 차이가 없어졌나요?

아닙니다.

인터페이스에 default 메서드가 추가되어 기본 구현은 가능해졌지만, 인터페이스는 여전히 상태를 가지는 인스턴스 필드나 생성자를 가질 수 없습니다.

추상 클래스는 공통 상태와 공통 로직을 함께 관리할 수 있다는 차이가 있습니다.

꼬리질문 2. 다중 상속이 필요한 상황에서 인터페이스를 선택하는 이유는 무엇인가요?

Java는 클래스 다중 상속을 지원하지 않지만, 인터페이스는 여러 개 구현할 수 있습니다.

그래서 여러 역할이나 기능을 동시에 부여해야 할 때 인터페이스를 사용합니다.

Q4. Java 컬렉션 프레임워크에서 List, Set, Map의 특징과 차이를 설명해주세요.

List: 순서가 있고, 중복을 허용합니다.
Set: 순서가 보장되지 않는 경우가 많고, 중복을 허용하지 않습니다.
Map: Key-Value 구조로 데이터를 저장하고, Key는 중복될 수 없습니다.

구분	특징
List	순서 있음, 중복 허용
Set	중복 불가
Map	Key-Value 저장, Key 중복 불가

꼬리질문 1. ArrayList와 LinkedList의 시간복잡도 차이는 무엇인가요?

ArrayList는 배열 기반이라 인덱스 조회가 빠릅니다.

조회: O(1)
중간 삽입/삭제: O(n)

LinkedList는 노드 연결 구조라 중간 삽입/삭제에 유리할 수 있지만, 특정 위치까지 이동해야 하므로 조회가 느립니다.

조회: O(n)
삽입/삭제: 위치를 알고 있으면 O(1)

일반적인 조회가 많으면 ArrayList를 주로 사용합니다.

꼬리질문 2. HashMap의 키 중복 판단 기준은 무엇인가요?

HashMap은 먼저 hashCode()로 저장 위치를 찾고, 같은 해시 위치에 값이 있으면 equals()로 실제 같은 Key인지 비교합니다.

즉, Key 중복 판단에는 hashCode()와 equals()가 함께 사용됩니다.

HTTP / Web 기초 영역

Q5. GET과 POST의 차이를 데이터 전달 방식과 사용 목적 관점에서 설명해주세요.

GET은 주로 데이터를 조회할 때 사용하고, 요청 데이터는 보통 URL의 Query Parameter로 전달합니다.

POST는 데이터를 생성하거나 처리할 때 사용하고, 요청 데이터는 주로 Body에 담아 전달합니다.

구분	GET	POST
목적	조회	생성, 처리
데이터 전달	Query Parameter	Body
멱등성	일반적으로 있음	일반적으로 없음
캐싱	가능	보통 캐싱하지 않음

꼬리질문 1. GET 요청에 Body를 담아 보내면 어떻게 되나요?

기술적으로 Body를 담는 것이 완전히 불가능한 것은 아닙니다.

하지만 HTTP 표준 관점에서 일반적인 사용 방식이 아니고, 서버나 프록시, 라이브러리에서 Body를 무시할 수 있기 때문에 권장하지 않습니다.

꼬리질문 2. 조회 API인데 요청 파라미터가 많아 URL 길이 제한에 걸리면 어떻게 설계하나요?

복잡한 검색 조건이라면 POST /search처럼 Body에 검색 조건을 담는 방식으로 설계할 수 있습니다.

단, 이 경우에도 실제 의미는 조회이므로 API 이름과 문서에서 검색용 요청이라는 것을 명확히 하는 것이 좋습니다.

Q6. HTTP 상태코드 200, 201, 400, 404, 500의 의미를 설명해주세요.

상태코드	의미
200 OK	요청 성공
201 Created	리소스 생성 성공
400 Bad Request	잘못된 요청
404 Not Found	리소스를 찾을 수 없음
500 Internal Server Error	서버 내부 오류

꼬리질문 1. 생성 API에서 200 대신 201을 반환해야 하는 이유가 있나요?

201 Created는 새로운 리소스가 생성되었다는 의미를 더 명확하게 전달합니다.

따라서 생성 API에서는 200 OK보다 201 Created가 RESTful한 의미에 더 잘 맞습니다.

꼬리질문 2. 없는 리소스를 요청했을 때 404 대신 200과 빈 데이터를 반환하는 방식도 있는데, 어떤 방식이 더 적절한가요?

단건 조회에서 특정 ID의 리소스가 없다면 404 Not Found가 더 적절합니다.

반면 목록 조회 결과가 비어 있는 경우에는 요청 자체는 성공한 것이므로 200 OK와 빈 배열을 반환하는 것이 자연스럽습니다.

Q7. Cookie와 Session의 차이를 저장 위치와 보안 관점에서 설명해주세요.

Cookie는 클라이언트 브라우저에 저장되는 데이터입니다.

Session은 서버에 사용자 상태를 저장하고, 클라이언트는 Session ID만 Cookie로 들고 있습니다.

구분	Cookie	Session
저장 위치	클라이언트	서버
보안	상대적으로 취약	상대적으로 안전
서버 부담	적음	있음
사용 예시	자동 로그인, 사용자 설정	로그인 상태 관리

꼬리질문 1. Session 사용 중 서버가 여러 대로 확장되면 어떤 문제가 생기나요?

서버마다 세션 저장소가 다르면 사용자가 처음 로그인한 서버가 아닌 다른 서버로 요청했을 때 세션을 찾지 못할 수 있습니다.

이를 해결하기 위해 Redis 같은 중앙 세션 저장소를 사용하거나 Sticky Session을 사용할 수 있습니다.

꼬리질문 2. Cookie의 HttpOnly와 Secure 속성은 각각 어떤 보안 위협을 방지하나요?

HttpOnly는 JavaScript에서 쿠키에 접근하지 못하게 해서 XSS 공격으로 쿠키가 탈취되는 위험을 줄입니다.

Secure는 HTTPS 통신에서만 쿠키가 전송되도록 해서 네트워크 구간에서 쿠키가 노출되는 위험을 줄입니다.

Spring 기초 영역

Q8. 3 Layer Architecture를 사용하는 이유는 무엇인가요?

3 Layer Architecture는 역할을 분리해서 코드의 유지보수성과 테스트 편의성을 높이기 위해 사용합니다.

Controller: 요청과 응답 처리
Service: 비즈니스 로직 처리
Repository: 데이터베이스 접근

각 계층의 책임이 분리되면 변경이 필요한 부분을 찾기 쉽고, 테스트하기도 쉬워집니다.

꼬리질문 1. Service 레이어에서 다른 Service를 호출하는 것이 왜 문제가 될 수 있나요?

Service끼리 무분별하게 호출하면 의존 관계가 복잡해지고 순환 참조가 발생할 수 있습니다.

또한 하나의 Service가 너무 많은 책임을 가지게 되어 유지보수가 어려워질 수 있습니다.

여러 도메인이 엮이는 로직은 Facade 계층을 두어 흐름을 조율하는 방식도 사용할 수 있습니다.

꼬리질문 2. Controller에 비즈니스 로직을 바로 작성하면 어떤 문제가 생기나요?

Controller가 요청 처리뿐만 아니라 비즈니스 로직까지 담당하게 되어 책임이 커집니다.

그 결과 코드 중복이 생기고, 테스트가 어려워지며, API 변경 시 비즈니스 로직까지 영향을 받을 수 있습니다.

Q9. Spring의 IoC와 DI가 무엇인지, 생성자 주입이 권장되는 이유를 설명해주세요.

IoC는 객체 생성과 의존성 관리의 제어권을 개발자가 아니라 Spring 컨테이너가 가지는 것입니다.

DI는 필요한 의존 객체를 직접 생성하지 않고 외부에서 주입받는 방식입니다.

생성자 주입이 권장되는 이유는 다음과 같습니다.

의존성을 final로 선언할 수 있음
객체 생성 시점에 필수 의존성을 보장할 수 있음
테스트 코드 작성이 쉬움
순환 의존성을 빠르게 발견할 수 있음

꼬리질문 1. 필드 주입은 편한데 왜 권장하지 않나요?

필드 주입은 외부에서 의존성을 주입하기 어렵기 때문에 테스트가 불편합니다.

또한 의존성이 숨겨져 있어 객체가 어떤 의존성을 필요로 하는지 명확히 드러나지 않습니다.

꼬리질문 2. 순환 의존성이란 무엇이고, 생성자 주입에서는 왜 더 빨리 감지되나요?

순환 의존성은 A가 B를 필요로 하고, B도 다시 A를 필요로 하는 구조입니다.

생성자 주입은 객체 생성 시점에 모든 의존성이 필요하기 때문에 순환 구조가 있으면 애플리케이션 시작 단계에서 바로 오류가 발생합니다.

Q10. Spring Bean이 무엇이고, 싱글톤으로 관리되는 이유가 무엇인가요?

Spring Bean은 Spring 컨테이너가 생성하고 관리하는 객체입니다.

Spring은 기본적으로 Bean을 싱글톤으로 관리합니다.

그 이유는 매 요청마다 객체를 새로 만들지 않고 하나의 객체를 재사용해서 메모리 사용을 줄이고 성능을 높이기 위해서입니다.

꼬리질문 1. 스프링 빈이 싱글톤이면 멀티스레드 환경에서 상태를 가지면 어떤 문제가 생기나요?

싱글톤 Bean은 여러 요청이 동시에 공유합니다.

따라서 인스턴스 필드에 사용자별 상태를 저장하면 다른 요청과 데이터가 섞이는 동시성 문제가 발생할 수 있습니다.

그래서 Service나 Controller Bean은 보통 상태를 가지지 않도록 설계합니다.

꼬리질문 2. `@Component`와 `@Bean`의 차이는 무엇인가요?

@Component는 클래스에 붙여서 Spring이 자동으로 스캔해 Bean으로 등록하게 합니다.

@Bean은 설정 클래스에서 메서드에 붙여 직접 객체를 생성하고 Bean으로 등록할 때 사용합니다.

구분	사용 상황
`@Component`	내가 만든 클래스를 자동 등록할 때
`@Bean`	외부 라이브러리 객체를 Bean으로 등록할 때

Q11. DTO를 사용하는 이유가 무엇인가요? Entity를 직접 반환하면 안 되는 이유를 설명해주세요.

DTO는 계층 간 데이터를 전달하기 위한 객체입니다.

Entity를 직접 반환하면 다음과 같은 문제가 생길 수 있습니다.

DB 구조가 API 응답에 그대로 노출됨
민감한 필드가 노출될 수 있음
Entity 변경이 API 스펙 변경으로 이어짐
양방향 연관관계에서 무한 참조 문제가 발생할 수 있음

따라서 API 요청과 응답에는 Entity 대신 DTO를 사용하는 것이 좋습니다.

꼬리질문 1. RequestDTO와 ResponseDTO를 분리하는 이유는 무엇인가요?

요청 데이터와 응답 데이터의 목적이 다르기 때문입니다.

RequestDTO는 클라이언트가 보내는 값을 검증하는 데 집중하고, ResponseDTO는 클라이언트에게 보여줄 데이터만 담는 데 집중합니다.

꼬리질문 2. Entity에 `@JsonIgnore`를 붙여 민감한 필드를 숨기면 DTO 없이도 되지 않나요?

간단한 경우에는 가능할 수 있지만 권장되지는 않습니다.

@JsonIgnore는 직렬화 문제만 일부 해결할 뿐, API 응답 구조와 Entity 구조가 강하게 묶이는 문제는 해결하지 못합니다.

DTO를 사용하면 API 스펙과 DB 모델을 분리할 수 있습니다.

JPA 영역

Q12. JPA의 영속성 컨텍스트란 무엇이고, 어떤 이점이 있나요?

영속성 컨텍스트는 JPA가 Entity를 관리하는 1차 캐시 공간입니다.

EntityManager가 Entity를 저장하고 관리하는 영역이라고 볼 수 있습니다.

주요 이점은 다음과 같습니다.

1차 캐시
동일성 보장
변경 감지
쓰기 지연
지연 로딩 지원

꼬리질문 1. 같은 트랜잭션 내에서 같은 ID로 두 번 조회하면 SQL이 몇 번 실행되나요?

처음 조회할 때만 SQL이 실행되고, 두 번째 조회는 영속성 컨텍스트의 1차 캐시에서 가져옵니다.

따라서 같은 트랜잭션 안에서는 같은 ID의 Entity에 대해 동일성이 보장됩니다.

꼬리질문 2. 준영속 상태란 무엇이고, 언제 발생하나요?

준영속 상태는 한 번 영속성 컨텍스트에서 관리되었지만 현재는 분리되어 관리되지 않는 상태입니다.

예를 들어 트랜잭션이 끝나거나, detach(), clear(), close()가 호출되면 Entity가 준영속 상태가 될 수 있습니다.

Q13. 더티 체킹이란 무엇인가요? save()를 호출하지 않아도 UPDATE가 되는 이유를 설명해주세요.

더티 체킹은 영속성 컨텍스트가 관리 중인 Entity의 변경 사항을 감지해서 트랜잭션 커밋 시점에 자동으로 UPDATE 쿼리를 실행하는 기능입니다.

JPA는 Entity를 처음 조회했을 때의 스냅샷을 가지고 있다가, 커밋 시점에 현재 Entity와 비교해 변경 사항이 있으면 UPDATE를 실행합니다.

꼬리질문 1. `@Transactional`이 없는 메서드에서 Entity를 수정하면 더티 체킹이 동작하나요?

일반적으로 동작하지 않습니다.

더티 체킹은 영속성 컨텍스트와 트랜잭션 안에서 의미가 있습니다.

트랜잭션 없이 Entity를 수정하면 변경 사항이 DB에 반영되지 않을 수 있습니다.

꼬리질문 2. 더티 체킹으로 발생하는 UPDATE 쿼리는 변경된 컬럼만 업데이트하나요, 전체 컬럼을 업데이트하나요?

기본적으로 JPA는 전체 컬럼을 업데이트하는 경우가 많습니다.

변경된 컬럼만 업데이트하고 싶다면 Hibernate의 @DynamicUpdate를 사용할 수 있습니다.

다만 무조건 사용하는 것이 좋은 것은 아니고, 상황에 따라 선택해야 합니다.

Q14. 즉시 로딩보다 지연 로딩을 권장하는 이유를 설명해주세요.

즉시 로딩은 Entity를 조회할 때 연관된 Entity까지 바로 조회합니다.

이로 인해 예상하지 못한 SQL이 실행되거나 성능 문제가 발생할 수 있습니다.

반면 지연 로딩은 실제로 연관 Entity가 필요할 때 조회하기 때문에 불필요한 조회를 줄일 수 있습니다.

그래서 실무에서는 기본적으로 LAZY를 권장합니다.

꼬리질문 1. 지연 로딩 상태에서 연관 Entity에 접근할 때 트랜잭션이 없으면 어떤 예외가 발생하나요?

LazyInitializationException이 발생할 수 있습니다.

이는 영속성 컨텍스트가 닫힌 상태에서 프록시 객체를 초기화하려고 할 때 발생합니다.

꼬리질문 2. N+1 문제가 무엇이고, Fetch Join으로 어떻게 해결하나요?

N+1 문제는 처음에 1번의 쿼리로 목록을 조회한 뒤, 각 Entity의 연관 데이터를 조회하기 위해 추가 쿼리가 N번 발생하는 문제입니다.

Fetch Join을 사용하면 처음 조회할 때 연관 Entity를 함께 가져와 추가 쿼리 발생을 줄일 수 있습니다.

인증 영역

Q15. 세션 방식과 JWT 방식의 차이를 서버 상태 관리와 확장성 관점에서 설명해주세요.

세션 방식은 서버가 로그인 상태를 저장하고, 클라이언트는 Session ID를 쿠키로 전달합니다.

JWT 방식은 로그인 정보를 담은 토큰을 클라이언트가 가지고 있고, 서버는 토큰을 검증해서 인증합니다.

구분	세션	JWT
상태 관리	서버가 상태 저장	서버가 상태 저장하지 않음
확장성	세션 저장소 필요	상대적으로 확장 쉬움
무효화	쉬움	상대적으로 어려움
저장 위치	서버	클라이언트

꼬리질문 1. JWT 토큰이 탈취됐을 때 즉시 무효화하기 어려운 이유는 무엇인가요?

JWT는 서버가 상태를 저장하지 않고 토큰 자체를 검증하는 방식입니다.

그래서 한 번 발급된 Access Token은 만료 시간 전까지 유효합니다.

즉시 무효화하려면 블랙리스트를 관리해야 하는데, 그러면 서버가 별도의 상태를 관리해야 합니다.

꼬리질문 2. Access Token과 Refresh Token을 분리해서 사용하는 이유는 무엇인가요?

Access Token은 API 요청에 사용되기 때문에 탈취 위험을 줄이기 위해 만료 시간을 짧게 가져갑니다.

Refresh Token은 Access Token을 재발급받기 위해 사용하며, 상대적으로 긴 만료 시간을 가집니다.

이렇게 분리하면 보안성과 사용자 편의성을 함께 챙길 수 있습니다.

마무리 정리

이번 면접 질문들은 Java 기본기부터 Spring, JPA, 인증 방식까지 백엔드 개발자가 반드시 이해해야 하는 핵심 개념들입니다.

단순히 키워드를 외우기보다는 다음 흐름으로 답변하는 연습이 중요합니다.

개념을 한 문장으로 설명한다.
왜 사용하는지 말한다.
실제 프로젝트에서 어떻게 적용했는지 예시를 든다.
장단점이나 주의점을 함께 말한다.

면접에서는 완벽한 암기보다, 개념을 실제 코드와 연결해서 설명하는 것이 중요합니다.

출처: 내일배움 스파르타 클럽

[트러블슈팅] RedissonClient Bean 등록 후 테스트 빌드 실패 해결

Tue, 23 Jun 2026 10:50:06 GMT

문제 상황

선착순 이벤트 기능에서 Redis Lock을 사용하기 위해 RedisLockManager를 구현했다.

@Component
@RequiredArgsConstructor
public class RedisLockManager {

    private final RedissonClient redissonClient;
}

하지만 이후 빌드를 실행하자 테스트 단계에서 실패했다.

bash ./gradlew clean build

처음 발생한 에러는 다음과 같았다.


Team8SaleCommerceApplicationTests > contextLoads() FAILED
java.lang.IllegalStateException
Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException

1차 원인

RedisLockManager는 RedissonClient를 생성자 주입으로 받고 있다.

그런데 프로젝트에 아직 RedissonClient를 Spring Bean으로 등록하는 설정 클래스가 없었다.

즉, Spring이 애플리케이션 컨텍스트를 로딩하면서 다음 흐름으로 실패했다.

RedisLockManager Bean 생성 시도
↓
RedissonClient 필요
↓
Spring Context 안에 RedissonClient Bean 없음
↓
NoSuchBeanDefinitionException 발생

1차 해결

RedissonClient를 Bean으로 등록하기 위해 RedissonConfig를 추가했다.

package com.example.team8salecommerce.global.config;

import org.redisson.Redisson;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * Redisson 설정 클래스
 *
 * Redis Lock을 사용하기 위해 RedissonClient를 Spring Bean으로 등록한다.
 */
@Configuration
public class RedissonConfig {

    @Value("${spring.data.redis.host:localhost}")
    private String redisHost;

    @Value("${spring.data.redis.port:6379}")
    private int redisPort;

    @Bean(destroyMethod = "shutdown")
    public RedissonClient redissonClient() {
        Config config = new Config();

        config.useSingleServer()
                .setAddress("redis://" + redisHost + ":" + redisPort);

        return Redisson.create(config);
    }
}

이제 RedissonClient Bean은 정상적으로 등록되었다.

하지만 다시 빌드하자 또 다른 에러가 발생했다.

Caused by: org.redisson.client.RedisConnectionException
Caused by: java.net.ConnectException

2차 원인

이번에는 Bean이 없어서 실패한 것이 아니라, 실제 Redis 서버 연결에 실패한 문제였다.

RedissonConfig가 추가되면서 테스트 실행 시에도 실제 Redis 서버에 연결하려고 했다.

하지만 로컬에서 Redis가 실행 중이 아니었기 때문에 다음 흐름으로 실패했다.

Spring Context 로딩
↓
RedissonClient Bean 생성
↓
localhost:6379 Redis 연결 시도
↓
Redis 서버 실행 중 아님
↓
RedisConnectionException 발생

즉, 문제의 핵심은 다음과 같았다.

실제 애플리케이션 실행에서는 Redis를 사용해야 한다.
하지만 contextLoads 테스트에서는 실제 Redis 서버 연결까지 필요하지 않다.

contextLoads() 테스트는 실제 Redis Lock 동작을 검증하는 테스트가 아니라, Spring 애플리케이션 컨텍스트가 정상적으로 로딩되는지만 확인하는 테스트이기 때문이다.

최종 해결

테스트 환경에서는 RedissonClient를 실제 Bean이 아니라 Mock Bean으로 대체했다.

package com.example.team8salecommerce;

import org.junit.jupiter.api.Test;
import org.redisson.api.RedissonClient;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.bean.override.mockito.MockitoBean;

/**
 * 애플리케이션 컨텍스트 로딩 테스트
 *
 * RedisLockManager는 RedissonClient를 필요로 한다.
 * 하지만 contextLoads 테스트에서 실제 Redis 서버까지 연결할 필요는 없으므로
 * RedissonClient를 MockitoBean으로 대체한다.
 */
@SpringBootTest
class Team8SaleCommerceApplicationTests {

    /**
     * 테스트용 RedissonClient Mock Bean
     *
     * 실제 Redis 서버가 켜져 있지 않아도
     * Spring Context가 정상적으로 로딩될 수 있게 한다.
     */
    @MockitoBean
    private RedissonClient redissonClient;

    @Test
    void contextLoads() {
    }
}

수정 후 다시 빌드를 실행했다.

bash ./gradlew clean build

결과적으로 빌드가 성공했다.

BUILD SUCCESSFUL

실제 Redis를 안 쓰는 건가?

아니다.

실제 프로젝트에서는 Redis를 사용한다.

다만 테스트 중 contextLoads()에서는 실제 Redis 서버에 연결할 필요가 없기 때문에 Mock Bean으로 대체한 것이다.

정리하면 다음과 같다.

상황	Redis 사용 여부
실제 서버 실행	실제 Redis 사용
선착순 구매 Redis Lock	실제 Redis 사용
결제 실패 재고 복구 Lock	실제 Redis 사용
환불 재고 복구 Lock	실제 Redis 사용
contextLoads 테스트	Mock RedissonClient 사용

실제 기능 테스트나 Postman 시연에서는 Redis 서버를 실행해야 한다.

docker run -d --name team8-sale-redis -p 6379:6379 redis:7-alpine

이미 Redis 컨테이너가 존재한다면 다음 명령어로 실행할 수 있다.

docker start team8-sale-redis

정리

이번 문제는 두 단계로 나눠서 발생했다.

첫 번째 문제는 RedissonClient Bean이 등록되어 있지 않아 발생한 NoSuchBeanDefinitionException이었다. 이를 해결하기 위해 RedissonConfig를 추가하여 RedissonClient를 Spring Bean으로 등록했다.

두 번째 문제는 테스트 실행 시 실제 Redis 서버에 연결하려다가 실패한 RedisConnectionException이었다. 이를 해결하기 위해 contextLoads() 테스트에서는 RedissonClient를 Mock Bean으로 대체했다.

결과적으로 실제 애플리케이션에서는 Redis Lock을 정상적으로 사용할 수 있고, 기본 빌드 테스트는 Redis 서버 실행 여부에 의존하지 않도록 개선할 수 있었다.

배운 점

외부 인프라를 사용하는 Bean을 추가할 때는 실제 실행 환경과 테스트 환경을 분리해서 생각해야 한다.

Redis, Kafka, S3, 외부 API처럼 별도 서버나 외부 서비스가 필요한 의존성은 테스트에서 실제 연결이 필요하지 않은 경우 Mock 처리하거나 테스트 전용 설정을 따로 두는 것이 좋다.

이번 경험을 통해 단순히 Bean을 등록하는 것뿐 아니라, 테스트 환경에서 해당 Bean이 어떻게 동작하는지도 함께 고려해야 한다는 점을 배웠다.

[Spring] CH 5 플러스 Spring 과제 초기 설정 트러블슈팅

Fri, 19 Jun 2026 01:31:07 GMT

들어가며

CH 5 플러스 Spring 과제를 진행하면서 본격적인 기능 구현에 들어가기 전, 프로젝트 실행 환경을 맞추는 과정에서 몇 가지 문제가 발생했다.

이번 과제는 기존 GitHub Repository를 fork한 뒤 local로 clone해서 진행하는 방식이었다. 프로젝트를 처음 실행하고 테스트를 돌리는 과정에서 Gradle Wrapper, Java 버전, JWT 설정값 관련 문제가 연속으로 발생했고, 이를 해결한 과정을 정리해보려고 한다.

1. Gradle Wrapper 설정 파일 누락 문제

문제 상황

프로젝트를 clone한 뒤 테스트를 실행했다.

./gradlew test

그런데 아래와 같은 에러가 발생했다.

Wrapper properties file '.../gradle/wrapper/gradle-wrapper.properties' does not exist.

원인

프로젝트에는 gradlew 파일과 gradle-wrapper.jar 파일은 존재했지만, Gradle Wrapper가 어떤 Gradle 버전을 사용할지 정의하는 gradle-wrapper.properties 파일이 없었다.

Gradle Wrapper가 정상적으로 동작하려면 보통 아래 구조가 필요하다.

gradle
└── wrapper
    ├── gradle-wrapper.jar
    └── gradle-wrapper.properties

하지만 현재 프로젝트에는 gradle-wrapper.properties가 누락되어 있어서 ./gradlew 명령어를 실행할 수 없었다.

해결

gradle/wrapper/gradle-wrapper.properties 파일을 직접 생성하고 Gradle 배포 URL을 설정했다.

distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-8.8-bin.zip
networkTimeout=10000
validateDistributionUrl=true
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists

이후 다시 Gradle 명령어를 실행하자 Wrapper 관련 에러는 해결되었다.

2. Java 버전 불일치 문제

문제 상황

Gradle Wrapper 문제를 해결한 뒤 다시 테스트를 실행했다.

./gradlew test

이번에는 아래와 같은 에러가 발생했다.

Unsupported class file major version 67

원인

major version 67은 Java 23에 해당한다.

현재 터미널에서 Java 23이 사용되고 있었고, 프로젝트와 Gradle 환경은 Java 17 기준으로 맞추는 것이 적절했다. 즉, 프로젝트에서 기대하는 Java 버전과 실제 터미널에서 사용하는 Java 버전이 달라서 문제가 발생한 것이다.

해결

터미널과 IntelliJ 설정을 Java 17로 맞췄다.

터미널에서는 JAVA_HOME을 Java 17로 설정했다.

export JAVA_HOME=$(/usr/libexec/java_home -v 17)
export PATH="$JAVA_HOME/bin:$PATH"

이후 확인했다.

java -version

또한 IntelliJ에서도 아래 설정을 Java 17로 맞췄다.

Project SDK: Java 17
Gradle JVM: Java 17

이후 Gradle daemon을 정리하고 다시 테스트를 실행했다.

./gradlew --stop
./gradlew clean test

Java 버전 문제는 해결되었다.

3. JWT secret key 누락 문제

문제 상황

Java 버전 문제를 해결한 뒤 테스트를 실행했지만, 이번에는 Spring Context 로딩 중 실패가 발생했다.

에러의 핵심은 다음과 같았다.

PropertyPlaceholderHelper

프로젝트 코드를 확인해보니 JwtUtil에서 아래 설정값을 사용하고 있었다.

@Value("${jwt.secret.key}")
private String secretKey;

원인

테스트 환경에서 jwt.secret.key 값이 설정되어 있지 않았다.

Spring은 ${jwt.secret.key} 값을 찾아 주입해야 하는데, 테스트 실행 시 해당 설정값을 찾지 못해 ApplicationContext 로딩에 실패했다.

해결

테스트 전용 설정 파일을 생성했다.

src/test/resources/application.properties

그리고 테스트용 JWT secret key를 추가했다.

처음에는 일반 문자열을 넣었지만, 이후 Base64 디코딩 과정에서 다시 오류가 발생했다.

IllegalArgumentException at Base64.java

JwtUtil 내부에서 secret key를 Base64로 디코딩하고 있었기 때문에, 일반 문자열이 아니라 Base64 형식의 값이 필요했다.

그래서 테스트용 값을 Base64 형식으로 수정했다.

jwt.secret.key=c3BhcnRhLXNwcmluZy1wbHVzLXRlc3Qtand0LXNlY3JldC1rZXktMTIzNDU2Nzg5MA==

이후 Spring Context가 정상적으로 로딩되었다.

4. Controller 테스트 기대값 불일치 문제

문제 상황

초기 설정 문제를 해결한 뒤에도 아래 테스트가 실패했다.

todo_단건_조회_시_todo가_존재하지_않아_예외가_발생한다()

테스트 코드를 확인해보니 서비스에서 예외를 던지도록 설정되어 있었다.

when(todoService.getTodo(todoId))
        .thenThrow(new InvalidRequestException("Todo not found"));

하지만 테스트의 기대 응답은 200 OK로 되어 있었다.

.andExpect(status().isOk())

원인

InvalidRequestException은 GlobalExceptionHandler에서 400 BAD_REQUEST로 처리되고 있었다.

즉 실제 응답은 400 BAD_REQUEST인데, 테스트는 200 OK를 기대하고 있었기 때문에 실패한 것이다.

해결

테스트 기대값을 실제 예외 처리 결과에 맞게 수정했다.

.andExpect(status().isBadRequest())
.andExpect(jsonPath("$.status").value(HttpStatus.BAD_REQUEST.name()))
.andExpect(jsonPath("$.code").value(HttpStatus.BAD_REQUEST.value()))
.andExpect(jsonPath("$.message").value("Todo not found"));

수정 후 테스트가 정상적으로 통과했다.

최종 결과

위 문제들을 해결한 뒤 전체 테스트를 다시 실행했다.

./gradlew clean test

결과적으로 테스트가 정상적으로 통과했다.

BUILD SUCCESSFUL

정리

이번 트러블슈팅을 통해 프로젝트를 시작할 때 기능 구현만큼이나 실행 환경을 정확히 맞추는 것이 중요하다는 것을 느꼈다.

특히 다음 내용을 다시 확인할 수 있었다.

Gradle Wrapper는 gradle-wrapper.properties 파일이 필요하다.
프로젝트 Java 버전과 터미널/IDE Java 버전이 일치해야 한다.
테스트 환경에서도 필요한 설정값은 별도로 제공해야 한다.
JWT secret key처럼 내부에서 Base64 디코딩하는 값은 형식까지 맞춰야 한다.
테스트는 실제 예외 처리 정책과 기대값이 일치해야 한다.

이번 과제에서는 초반 설정 문제를 해결한 뒤, 이후 필수 기능들을 하나씩 구현하며 전체 테스트를 통과시킬 수 있었다.

# 🛠️ [트러블슈팅] 전액 환불 시 `ORDER_004` 오류가 발생한 이유

Tue, 09 Jun 2026 07:21:08 GMT

✅ 문제 상황

커머스 결제 시스템 프로젝트에서 주문 환불 API를 테스트하던 중, 요청 Body 형식은 올바르게 작성했는데 계속 아래와 같은 오류가 발생했다.

{
  "code": "ORDER_004",
  "message": "유효하지 않은 주문 상태입니다."
}

Postman 요청은 다음과 같았다.

POST /api/orders/8/refunds

{
  "items": [
    {
      "orderItemId": 8,
      "quantity": 3
    }
  ],
  "reason": "단순 변심으로 인한 환불"
}

테스트 데이터도 정상적으로 준비되어 있었다.

orders.status = COMPLETED
payment.status = COMPLETED
order_item.quantity = 3

즉, 이미 결제가 완료된 주문이었고, 전액 환불을 진행할 수 있는 상태라고 생각했다.

그런데 계속 ORDER_004가 발생했다.

🔍 원인 분석

처음에는 Request Body 형식이 잘못된 줄 알았다.

하지만 Body 구조는 DTO와 일치했다.

{
  "items": [
    {
      "orderItemId": 8,
      "quantity": 3
    }
  ],
  "reason": "단순 변심으로 인한 환불"
}

그래서 오류 코드를 기준으로 검색해보았다.

grep -R "INVALID_ORDER_STATUS" -n src/main/java

검색 결과, Order.java 안에서 INVALID_ORDER_STATUS가 발생하고 있었다.

src/main/java/com/paymentsystemproject/domain/order/entity/Order.java:92

문제는 기존 Order.cancel() 메서드였다.

public void cancel() {
    if (this.status != OrderStatus.PENDING_PAYMENT) {
        throw new BusinessException(ErrorCode.INVALID_ORDER_STATUS);
    }

    this.status = OrderStatus.CANCELLED;
}

기존 cancel() 메서드는 결제 대기 상태 주문 취소를 위한 메서드였다.

즉, 아래 흐름만 허용하고 있었다.

PENDING_PAYMENT → CANCELLED

하지만 전액 환불은 이미 결제가 완료된 주문에서 발생한다.

전액 환불의 상태 전이는 아래와 같아야 한다.

COMPLETED → CANCELLED

결국 문제는 이것이었다.

주문 직접 취소와 전액 환불 취소가 같은 order.cancel() 메서드를 공유하고 있었다.

💥 실제 오류 흐름

전액 환불 요청이 들어오면 내부 흐름은 다음과 같았다.

환불 요청
→ 전체 환불 여부 판단
→ Payment 상태를 REFUNDED로 변경
→ Order 상태를 CANCELLED로 변경하기 위해 order.cancel() 호출
→ order.cancel()은 PENDING_PAYMENT만 허용
→ 현재 주문 상태는 COMPLETED
→ INVALID_ORDER_STATUS 발생

즉, 전액 환불 로직 자체가 틀렸다기보다 주문 상태를 변경하는 메서드의 책임이 너무 넓게 묶여 있었던 것이 문제였다.

✅ 해결 방법

취소 목적에 따라 메서드를 분리했다.

주문 취소는 크게 두 가지 상황이 있다.

상황	시작 상태	변경 상태
사용자가 결제 전 주문 취소	`PENDING_PAYMENT`	`CANCELLED`
결제 완료 주문을 전액 환불	`COMPLETED`	`CANCELLED`

둘 다 결과는 CANCELLED지만, 출발 상태가 다르기 때문에 하나의 메서드로 처리하면 안 된다.

그래서 Order 엔티티에 메서드를 분리했다.

🔧 수정 코드

기존 코드

public void cancel() {
    if (this.status != OrderStatus.PENDING_PAYMENT) {
        throw new BusinessException(ErrorCode.INVALID_ORDER_STATUS);
    }

    this.status = OrderStatus.CANCELLED;
}

수정 후 코드

/**
 * 결제 대기 상태의 주문을 회원이 직접 취소합니다.
 */
public void cancelPendingOrder() {
    if (this.status != OrderStatus.PENDING_PAYMENT) {
        throw new BusinessException(ErrorCode.INVALID_ORDER_STATUS);
    }

    this.status = OrderStatus.CANCELLED;
}

/**
 * 전액 환불로 인해 주문을 취소 상태로 변경합니다.
 */
public void cancelByFullRefund() {
    if (this.status != OrderStatus.COMPLETED) {
        throw new BusinessException(ErrorCode.INVALID_ORDER_STATUS);
    }

    this.status = OrderStatus.CANCELLED;
}

🔁 호출부 수정

주문 직접 취소 API

기존에는 주문 취소에서도 order.cancel()을 사용하고 있었다.

order.cancel();

이를 주문 직접 취소 전용 메서드로 변경했다.

order.cancelPendingOrder();

전액 환불 처리

전액 환불 시에는 아래 메서드를 사용하도록 수정했다.

order.cancelByFullRefund();

최종적으로 전액 환불 흐름은 다음과 같이 정리되었다.

RefundService
→ 전체 환불 판단
→ Payment 상태를 REFUNDED로 변경
→ OrderService.cancelByFullRefund()
→ order.cancelByFullRefund()
→ COMPLETED 주문을 CANCELLED로 변경

✅ 테스트 결과

수정 후 다시 Postman으로 전액 환불 요청을 보냈다.

POST /api/orders/8/refunds

{
  "items": [
    {
      "orderItemId": 8,
      "quantity": 3
    }
  ],
  "reason": "단순 변심으로 인한 환불"
}

이후 DB를 확인했다.

SELECT id, status
FROM orders
WHERE id = 8;

SELECT id, status
FROM payment
WHERE order_id = 8;

결과는 정상적으로 변경되었다.

orders.status = CANCELLED
payment.status = REFUNDED

상품 재고도 환불 수량만큼 정상 복구되었다.

또한 빌드도 성공했다.

sh ./gradlew clean compileJava

📌 배운 점

이번 문제를 통해 같은 결과 상태를 만들더라도, 상태 전이의 출발점이 다르면 메서드를 분리해야 한다는 점을 배웠다.

처음에는 단순히 주문을 취소하는 행위라고 생각해서 cancel() 하나로 처리했다.

하지만 실제 도메인에서는 다음 두 흐름이 전혀 다르다.

결제 전 주문 취소
PENDING_PAYMENT → CANCELLED

결제 완료 후 전액 환불
COMPLETED → CANCELLED

둘 다 최종 상태는 CANCELLED지만, 의미와 검증 조건이 다르다.

그래서 도메인 메서드는 단순히 “결과 상태”만 기준으로 만들면 안 되고, 어떤 비즈니스 상황에서 호출되는 메서드인지 이름과 검증 조건에 드러나야 한다.

✅ 정리

이번 오류의 핵심은 Request Body 문제가 아니었다.

문제의 원인은 다음과 같았다.

주문 직접 취소와 전액 환불 취소가 같은 order.cancel() 메서드를 공유하면서, COMPLETED 주문의 전액 환불까지 PENDING_PAYMENT 검증에 걸려 실패한 문제

해결은 다음과 같이 진행했다.

order.cancel()
→ cancelPendingOrder()
→ cancelByFullRefund()

이를 통해 주문 직접 취소와 전액 환불의 상태 전이 책임을 명확히 분리할 수 있었다.

# [Spring Boot + Docker MySQL] Access denied for user 'root'@'localhost' 해결 — 원인은 비밀번호가 아니라 포트 충돌이었다

Wed, 27 May 2026 11:35:11 GMT

지피티랑 1시간 넘게 싸웠는데 알고 보니 포트 번호 문제;;

문제 상황

Spring Boot 프로젝트에서 Docker로 MySQL을 띄운 뒤 애플리케이션을 실행하려고 했다.

처음 설정은 다음과 같았다.

docker-compose.yml

services:
  mysql:
    image: mysql:8
    container_name: sparta-payment-mysql
    environment:
      MYSQL_ROOT_PASSWORD: root1234
      MYSQL_DATABASE: payment_db
    ports:
      - "3306:3306"
    volumes:
      - mysql_data:/var/lib/mysql
    command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci

volumes:
  mysql_data:

application.yaml

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/payment_db?useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Seoul
    username: root
    password: root1234
    driver-class-name: com.mysql.cj.jdbc.Driver

  jpa:
    open-in-view: false
    hibernate:
      ddl-auto: create
    show-sql: true
    properties:
      hibernate:
        format_sql: true
        dialect: org.hibernate.dialect.MySQLDialect

하지만 Spring Boot를 실행하면 계속 아래 에러가 발생했다.

Access denied for user 'root'@'localhost' (using password: YES)

최종적으로는 JPA가 DB 커넥션을 얻지 못해 entityManagerFactory 생성에 실패했고, 애플리케이션 실행이 중단됐다.

Failed to initialize JPA EntityManagerFactory
Unable to open JDBC Connection for DDL execution
Application run failed

처음에 의심한 것: root 비밀번호 문제

에러 메시지만 보면 가장 먼저 의심되는 것은 MySQL 비밀번호였다.

Access denied for user 'root'@'localhost'

그래서 처음에는 root 계정의 비밀번호가 잘못되었거나, IntelliJ가 예전 비밀번호를 저장하고 있다고 생각했다.

내가 확인했던 비밀번호 후보는 다음과 같았다.

root1234
dlatjsrn1!

먼저 Docker 컨테이너 안에서 root 계정으로 접속해봤다.

docker exec -it sparta-payment-mysql mysql -uroot -p

비밀번호로 root1234를 입력하니 정상 접속됐다.

Welcome to the MySQL monitor.

그리고 DB도 정상적으로 선택됐다.

USE payment_db;
SHOW TABLES;

결과는 다음과 같았다.

Database changed
Empty set

즉, Docker 컨테이너 내부의 MySQL에서는 root / root1234가 정상적으로 동작했다.

root 비밀번호 직접 확인

그래도 확실히 하기 위해 명령어로 비밀번호를 직접 검증했다.

docker exec -i sparta-payment-mysql mysql -uroot -proot1234 -e "SELECT 'root1234 OK';"

결과는 성공이었다.

root1234 OK
root1234 OK

반대로 예전에 다른 프로젝트에서 쓰던 비밀번호도 확인했다.

docker exec -i sparta-payment-mysql mysql -uroot -p'dlatjsrn1!' -e "SELECT 'old password OK';"

결과는 실패였다.

ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

따라서 현재 Docker MySQL의 root 비밀번호는 root1234가 맞았다.

헷갈렸던 부분: 터미널에서는 되는데 Spring Boot는 안 됨

이상했던 점은 터미널에서는 접속이 되는데 Spring Boot에서는 계속 실패한다는 점이었다.

컨테이너 내부에서는 아래 명령어가 정상 동작했다.

docker exec -it sparta-payment-mysql mysql -uroot -p

하지만 Spring Boot 실행 로그에서는 계속 아래 에러가 발생했다.

Access denied for user 'root'@'localhost' (using password: YES)

처음에는 이 차이를 이해하지 못해서 다음과 같은 것들을 의심했다.

1. application.yaml 비밀번호 오타
2. IntelliJ Database 탭의 비밀번호 캐시 문제
3. MySQL root 계정 권한 문제
4. Docker 볼륨에 예전 비밀번호가 남아있는 문제

그래서 payment_user라는 새 계정도 만들어보고, 권한도 부여해봤다.

CREATE USER 'payment_user'@'%' IDENTIFIED BY 'payment1234';
GRANT ALL PRIVILEGES ON payment_db.* TO 'payment_user'@'%';
FLUSH PRIVILEGES;

하지만 이것도 근본 해결이 아니었다.

나중에 확인해보니 문제는 계정이 아니었다.

IntelliJ Database 연결도 실패

IntelliJ 오른쪽 Database 탭에서도 MySQL 연결을 시도했다.

처음에는 다음과 같이 설정했다.

Host: localhost
Port: 3306
User: root
Password: root1234
Database: payment_db

하지만 IntelliJ Database에서도 계속 연결이 실패했다.

Access denied for user 'root'@'localhost' (using password: YES)

이때까지만 해도 계속 비밀번호나 계정 문제라고 생각했다.

하지만 Docker 컨테이너 안에서는 root / root1234가 정상 접속되기 때문에 앞뒤가 맞지 않았다.

application.yaml 확인

설정 파일이 실제로 반영됐는지도 확인했다.

처음에는 파일명을 application.yml로 착각해서 확인했다.

cat src/main/resources/application.yml | grep "jdbc:mysql"

하지만 실제 파일명은 application.yaml이었다.

find . -name "application.yml" -o -name "application.yaml" -o -name "application.properties"

결과는 다음과 같았다.

./build/resources/main/application.yaml
./src/main/resources/application.yaml

그래서 실제 파일을 다시 확인했다.

cat src/main/resources/application.yaml | grep "jdbc:mysql"
cat build/resources/main/application.yaml | grep "jdbc:mysql"

둘 다 정상적으로 같은 설정을 가지고 있었다.

url: jdbc:mysql://127.0.0.1:3306/payment_db?useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Seoul

즉, Spring Boot 설정 파일 문제도 아니었다.

root 계정 host 권한 확인

혹시 root 계정이 외부 접속을 허용하지 않는 문제일 수도 있어서 MySQL 계정의 host 값을 확인했다.

docker exec -i sparta-payment-mysql mysql -uroot -proot1234 -e "SELECT user, host FROM mysql.user WHERE user = 'root';"

결과는 다음과 같았다.

user    host
root    %
root    localhost

root@%가 있다는 것은 외부 접속도 허용된다는 뜻이다.

따라서 root 계정 권한 문제도 아니었다.

진짜 원인 확인: 3306 포트 충돌

결국 3306 포트를 누가 사용하고 있는지 확인했다.

lsof -iTCP:3306 -sTCP:LISTEN -n -P

결과는 다음과 같았다.

COMMAND     PID    USER     NAME
mysqld      1529   imsungu  TCP 127.0.0.1:3306 (LISTEN)
com.docke   52511  imsungu  TCP *:3306 (LISTEN)

여기서 핵심은 이 부분이었다.

mysqld ... TCP 127.0.0.1:3306 (LISTEN)

내 Mac에 예전에 설치되어 있던 로컬 MySQL이 이미 127.0.0.1:3306을 사용하고 있었다.

즉, Spring Boot가 아래 주소로 접속할 때,

jdbc:mysql://127.0.0.1:3306/payment_db

내가 의도한 Docker MySQL이 아니라 Mac 로컬 MySQL로 접속하고 있었던 것이다.

그래서 Docker MySQL의 비밀번호인 root1234를 넣어도 Mac 로컬 MySQL에서는 맞지 않기 때문에 계속 로그인 실패가 발생했다.

Access denied for user 'root'@'localhost'

원인 정리

문제의 흐름은 다음과 같았다.

1. Mac 로컬 MySQL이 127.0.0.1:3306 사용 중
2. Docker MySQL도 3306으로 열려고 함
3. Spring Boot는 127.0.0.1:3306으로 접속
4. 실제로는 Docker MySQL이 아니라 Mac 로컬 MySQL에 접속
5. Docker용 비밀번호 root1234를 넣음
6. Mac 로컬 MySQL 입장에서는 틀린 비밀번호
7. Access denied 발생

즉, 원인은 비밀번호가 아니라 포트 충돌이었다.

해결 방법

Docker MySQL의 외부 포트를 3306에서 3307로 변경했다.

docker-compose.yml 수정 전

ports:
  - "3306:3306"

docker-compose.yml 수정 후

ports:
  - "3307:3306"

최종 docker-compose.yml은 다음과 같다.

services:
  mysql:
    image: mysql:8
    container_name: sparta-payment-mysql
    environment:
      MYSQL_ROOT_PASSWORD: root1234
      MYSQL_DATABASE: payment_db
      MYSQL_ROOT_HOST: '%'
    ports:
      - "3307:3306"
    volumes:
      - mysql_data:/var/lib/mysql
    command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci

volumes:
  mysql_data:

그리고 Spring Boot의 application.yaml도 3307로 변경했다.

spring:
  datasource:
    url: jdbc:mysql://127.0.0.1:3307/payment_db?useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Seoul
    username: root
    password: root1234
    driver-class-name: com.mysql.cj.jdbc.Driver

Docker 재실행

설정 변경 후 Docker 컨테이너를 재실행했다.

docker compose down
docker compose up -d

이미 데이터 초기화가 필요한 상황은 아니었기 때문에 -v는 붙이지 않았다.

docker compose down -v

-v를 붙이면 볼륨까지 삭제되어 DB 데이터가 초기화된다.

IntelliJ Database 연결도 다시 설정

IntelliJ Database 탭에서도 기존 localhost:3306 연결은 삭제하고 새로 만들었다.

새 연결 정보는 다음과 같다.

Host: 127.0.0.1
Port: 3307
User: root
Password: root1234
Database: payment_db

URL은 다음과 같이 잡혔다.

jdbc:mysql://127.0.0.1:3307/payment_db

그 결과 Test Connection이 성공했다.

Succeeded
DBMS: MySQL 8.4.9

드디어 IntelliJ Database 탭에서도 payment_db가 정상적으로 보이기 시작했다.

최종 정리

이번 문제는 단순한 비밀번호 문제가 아니었다.

처음에는 root 비밀번호, MySQL 계정 권한, IntelliJ 비밀번호 저장 문제라고 생각해서 한참을 헤맸다.

하지만 실제 원인은 Mac 로컬 MySQL과 Docker MySQL이 같은 3306 포트를 사용하면서 발생한 포트 충돌이었다.

Mac 로컬 MySQL  → 127.0.0.1:3306 사용 중
Docker MySQL    → 원래 3306으로 열려고 함
Spring Boot     → 127.0.0.1:3306으로 접속
결과             → Docker가 아니라 Mac 로컬 MySQL로 접속

해결 후 구조는 다음과 같다.

Mac 로컬 MySQL       → 127.0.0.1:3306
Docker MySQL 외부접속 → 127.0.0.1:3307
Docker 내부 MySQL    → 3306

즉, 내 Mac에서 Docker MySQL에 접속할 때는 3307을 사용해야 하고, Docker 컨테이너 내부에서는 여전히 3306을 사용한다.

배운 점

docker exec로 MySQL 접속이 성공한다고 해서 Spring Boot도 같은 MySQL에 접속하고 있다고 단정하면 안 된다.

docker exec -it sparta-payment-mysql mysql -uroot -p

이 명령어는 컨테이너 내부에서 MySQL에 접속하는 것이다.

반면 Spring Boot는 Mac에서 Docker MySQL에 접속한다.

그래서 로컬 PC에 이미 MySQL이 설치되어 있고 3306 포트를 사용 중이라면, Spring Boot가 Docker MySQL이 아니라 로컬 MySQL로 접속할 수 있다.

포트 충돌이 의심될 때는 아래 명령어로 확인하자.

lsof -iTCP:3306 -sTCP:LISTEN -n -P

한 줄 요약

Docker MySQL 비밀번호 문제가 아니라, Mac 로컬 MySQL이 3306 포트를 이미 사용하고 있어서 Spring Boot와 IntelliJ Database가 Docker가 아닌 로컬 MySQL에 접속하던 문제였다.

CH4. 클라우드 아키택처 설계 & 배포 트러블 슈팅

Tue, 26 May 2026 01:16:07 GMT

[AWS RDS] MySQL 접속 중 Unknown database '3306' 오류 해결

문제 상황

AWS RDS에 MySQL 데이터베이스를 생성한 뒤, EC2에서 RDS에 접속 테스트를 진행했다.

RDS Endpoint는 정상적으로 복사했고, EC2에서 MySQL 클라이언트도 설치한 상태였다.

처음에는 아래 명령어로 접속을 시도했다.

mysql -h team-profile-rds.c50wseaoq4uw.ap-northeast-2.rds.amazonaws.com -p 3306 -u admin -p

그런데 다음과 같은 에러가 발생했다.

ERROR 1049 (42000): Unknown database '3306'

처음에는 RDS 보안 그룹 문제인지, 데이터베이스가 제대로 생성되지 않은 문제인지 헷갈렸다.

원인 분석

에러 메시지를 보면 다음과 같이 나온다.

Unknown database '3306'

즉, MySQL은 3306을 포트 번호가 아니라 데이터베이스 이름으로 해석하고 있었다.

문제는 접속 명령어에서 사용한 옵션이었다.

내가 작성한 명령어는 다음과 같았다.

mysql -h RDS_ENDPOINT -p 3306 -u admin -p

여기서 실수한 부분은 이 옵션이다.

-p 3306

MySQL 명령어에서:

-p  → password 옵션
-P  → port 옵션

즉, 포트 번호를 지정하려면 소문자 -p가 아니라 대문자 -P 를 사용해야 한다.

나는 포트 번호 3306을 지정하려고 했지만, 소문자 -p를 사용해서 MySQL이 명령어를 잘못 해석한 것이다.

해결 방법

포트 번호 옵션을 대문자 -P로 수정했다.

mysql -h team-profile-rds.c50wseaoq4uw.ap-northeast-2.rds.amazonaws.com -P 3306 -u admin -p

수정 후 비밀번호를 입력하자 정상적으로 접속되었다.

Welcome to the MariaDB monitor.
Commands end with ; or \g.

MySQL [(none)]>

그다음 데이터베이스 목록을 확인했다.

SHOW DATABASES;

결과는 다음과 같았다.

+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| teamprofiledb      |
+--------------------+

teamprofiledb가 정상적으로 보이는 것을 확인했다.

최종 정리

잘못된 명령어

mysql -h RDS_ENDPOINT -p 3306 -u admin -p

올바른 명령어

mysql -h RDS_ENDPOINT -P 3306 -u admin -p

배운 점

이번 문제는 RDS 설정이나 보안 그룹 문제가 아니라, MySQL 접속 명령어 옵션을 잘못 사용해서 발생한 문제였다.

특히 MySQL CLI에서는 소문자와 대문자 옵션이 다른 의미를 가진다.

-p : 비밀번호 입력 옵션
-P : 포트 번호 지정 옵션

앞으로 MySQL에 접속할 때는 포트 번호를 지정할 경우 반드시 대문자 -P를 사용해야 한다.

또한 에러 메시지에서 Unknown database '3306'이라고 나왔기 때문에, MySQL이 3306을 포트가 아닌 데이터베이스 이름으로 해석했다는 점을 통해 원인을 추적할 수 있었다.

스프링 정리 3

Wed, 20 May 2026 10:33:16 GMT

7. 조회전략과 N + 1

01. ⭐ JPA 조회 전략

a. Eager Loading - 즉시 조회

단방향(@MnayToOne) 의 기본 조회 전략입니다. 엔티티를 가져올때 연관된 엔티티도 함께 조회합니다.

i. 즉시 조회 설정 방법

@Entity
@Table(name = "students")
public class Student {

        ...

    @ManyToOne(fetch = FetchType.EAGER) // ✅ 기본 조회 전략(생략 가능)
    @JoinColumn(name = "course_id")
    private Course course;

        ...
}

ii. 즉시조회 코드로 살펴보기 - V1, V2

학생 정보만 조회하더라도 연관된 수업의 정보를 함께 조회하는 모습을 확인할 수 있습니다.

b. Lazy Loading - 지연 조회

연관관계에 있는 엔티티의 정보가 필요할 때만 조회합니다. 양방향(@OneToMany, @ManyToMany)의 기본 조회 전략입니다.

i. 지연 조회 설정 방법

@Entity
@Table(name = "students")
public class Student {

        ...

    @ManyToOne(fetch = FetchType.LAZY) // ✅ 지연 조회 설정
    @JoinColumn(name = "course_id")
    private Course course;

    ...
}

02. 논의 포인트 - 지연 조회 전략

Lazy 전략을 활용해 조회를 한다면 연관된 속성 안에는 무엇이 들어가 있을까요?

03. ⭐ 프록시 객체

proxy == 대리인

a. 정체와 구조

실제 객체 대신 먼저 앞에서 요청을 받아주는 객체입니다. 프록시 덕분에 지연로딩이 가능해집니다. 프록시 객체 덕분에 지연로딩이 가능해집니다.

Eager Loading 일 경우

Lazy Loading 일 경우

b. 동작 원리

JPA 는 지연로딩을 가능하게 만들기 위해 연관관계 조회시점에 진짜 객체(엔티티) 대신 프록시 객체를 주입해줍니다. 이 프록시는 식별자(id)만 가진 껍데기 객체입니다. 이후 실제 필드에 접근하는 순간 DB 쿼리가 실행되어서 진짜 데이터가 조회됩니다.

03. ⭐ 지연 로딩의 한계 → N + 1

ORM 을 활용하면서 데이터를 객체처럼 쉽게 다룰 수 있게 되었습니다! 하지만 조회전략을 잘 이해하지 못하고 활용한다면 연관된 데이터를 가져오기 위해 n 개의 추가 쿼리가 발생하는 성능 문제가 발생할 수 있습니다.

a. 퀴즈: 아래 구조에서 쿼리가 몇번 발생할까요? 4번의 쿼리 발생

b. 흔히 발생하는 n + 1 문제 유형 살펴보기

i. 반복문 내부

반복문 내부에서 연관된 엔티티 조회시

  public List getStudentListV1() {
        // 1. 학생 목록 조회
        List foundStudentList = studentRepository.findAll();

        // 2. Dto 만들기
        // 2-1. dto 리스트 준비
        List studentDetailResponseDtoList = new ArrayList<>();

        for (Student student : foundStudentList) {
            // 2-1. dtoDetail 요소 재료 준비
            Long foundStudentId = student.getId();
            String foundStudentName = student.getName();
            Course foundCourse = student.getCourse();
            String foundCourseName = foundCourse.getName(); // n + 1 문제

            // 2-2. dto 요소 만들기
            StudentDetailResponseDto studentDetailResponseDto = new StudentDetailResponseDto(
                    foundStudentId,
                    foundStudentName,
                    foundCourseName
            );

            // 2-3. dto 리스트에 detailDto 추가
            studentDetailResponseDtoList.add(studentDetailResponseDto);
        }
        return studentDetailResponseDtoList;
    }

ii. stream 내부

stream 내부에서 연관된 엔티티 조회시

    public List getStudentListV2() {
        // 1. 학생 목록 조회
        List foundStudentList = studentRepository.findAll();

        // 2. Dto 만들기
        // 2-1. dto 리스트 준비
        List studentDetailResponseDtoList = foundStudentList.stream()
                .map(student -> new StudentDetailResponseDto(
                                student.getId(),
                                student.getName(),
                                student.getCourse()
                                        .getName() // n + 1 문제
                        )
                )
                .collect(Collectors.toList());
        return studentDetailResponseDtoList;
    }

iii. dto 내부

dto 내부에서 연관된 엔티티 조회시

    public List getStudentListV3() {
        // 1. 학생 목록 조회
        List foundStudentList = studentRepository.findAll();

        // 2. Dto 만들기
        // 2-1. dto 리스트 준비
        List studentDetailResponseDtoList = foundStudentList.stream()
                .map(student -> new StudentDetailResponseDto(student)
                )
                .collect(Collectors.toList());
        return studentDetailResponseDtoList;
    }

class StudentDetailResponseDto {
        ...
        private String courseName;

        public StudentDetailResponseDto(Stduent student) {
                this.student.getCourse().getName(); // n + 1 문제 발생

        }
}

04. ⭐ n + 1 문제 해결 방법

a. join fetch

    @Query("SELECT s FROM Student s LEFT JOIN FETCH s.course")
    List findAllWithStudent();

b. entityGraph

i. 기본 활용 방법

Student 엔티티에 연관된 객체들을 어떻게 조회할건지 미리 그래프로 정해놓고 repository 에서 사용하는 방법입니다.

하나만 정의해놓기(student ↔ course):

@Entity
@Table(name = "students")
@NamedEntityGraph(
        name = "Student.withCourse",
        attributeNodes = @NamedAttributeNode("course")
)
public class Student {
    ...
    private Course course;
}

여러개 정의해놓기(student ↔ course, student ↔ tutor, student:

@Entity
@Table(name = "students")
@NamedEntityGraphs({
    @NamedEntityGraph(
        name = "Student.withCourse",
        attributeNodes = @NamedAttributeNode("course")
    ),
    @NamedEntityGraph(
        name = "Student.withTutor",
        attributeNodes = @NamedAttributeNode("tutor")
    ),
    @NamedEntityGraph(
        name = "Student.withCourseAndTutor",
        attributeNodes = {
            @NamedAttributeNode("course"),
            @NamedAttributeNode("tutor")
        }
    )
})
public class Student {
    ...
    private Course course;
    private Tutor tutor;
}

public interface StudentRepository extends JpaRepository {

    @EntityGraph("Student.withCourse")
        List findAll();

    @EntityGraph("Student.withTutor")
        List findAll();

    @EntityGraph("Student.withCourseAndTutor")
        List findAll();

        @EntityGraph("Student.withCourse")
        List findByName(String name);
}

queryMethod 방식, JPQL 방식 모두 활용 가능

ii. 간단한 사용 방법

    @EntityGraph(attributePaths = {"course"})
    @Query("SELECT s FROM Student s")
    List findAllWithEntityGraph();

    @EntityGraph(attributePaths = {"course"})
    List findAll();

8. JWT - 인증인가

01. JWT 개념

토큰 안에 담기는 데이터를 json 형식으로 표현하는 토큰인증 방식입니다.

a. JWS 와 JWE

JWS: 어떻게 데이터를 보호할까? → 서명방식으로!
JWE: 어떻게 데이터를 보호할까? → 암호화방식으로!

c. JWT 살펴보기

우리가 쓰는 토큰은 정확히 말하면 ”JWS로 서명된 JWT” 입니다.

i. jwt 예시

어떤 알고리즘(HMAC, SHA256 등)을 사용해서 signature(서명) 를 만들지 명시하는 곳입니다.
Base64 로 인코딩 되어 있어서 누구나 간단하게 읽을 수 있습니다.
토큰 검증시 header 부분을 보고 어떤 알고리즘을 활용해서 서명을 검증할지 판단할 수 있습니다.

b. ⭐ Payload - 토큰 내용

토큰의 내용(payload)이 담기는 곳입니다.
Base64 로 인코딩 되어 있어서 누구나 간단하게 읽을 수 있습니다.
key-value 형식으로 저장되어 있습니다.
userId, role 등 다양한 정보를 담을 수 있습니다.

c. ⭐ Signature - 서명

공식: Base64(header) + Base64(payload) + secret = signature
검증시 서명을 확인해서 토큰이 위변조 되었는지 확인할 수 있습니다.

d. ⭐ Secret - 비밀키

Signature(서명) 를 만들때 사용합니다.
외부로 유출될 경우 누구든지 유효한 서명을 가진 JWT 를 만들 수 있음으로 보안에 신경써야합니다.

e. 정리

Header: 서명을 만들 때 어떤 알고리즘을 사용할지 선언하는 곳
Payload: 토큰의 내용이 담기는 곳
Signature: Header + Payload + Secret 조합하고 서명 알고리즘을 활용해 만들어내는 서명
Secret: Signature 를 만들기위해 사용되는 비밀키

03. JWT 흐름

b. 검증

서버는 Header 의 alg 값을 보고 어떤 알고리즘을 사용해서 서명을 만들지 판단합니다. 그렇게 생성한 서명을 토큰에 담겨온 서명과 비교해서 일치하지 않으면 위변조된 토큰으로 판단합니다.

⭐ 06. 인증인가 jwt 실습

정리

흔히 개발자들이 말하는 JWT 는 Header, payload, Signature 세 부분으로 구성됩니다.

JWS 은 JWT 를 서명(Signature)으로 보호한 형태를 의미합니다.

JWE은 JWT 를 암호화(Encryption)로 보호한 형태를 의미합니다.

모든 JWS 는 JWT 이지만 모든 JWT 는 JWS 가 아니다 (O)

JWS 의 서명(Signature)부분을 만들때 Header, payload, secret 를 조합하여 만들어집니다.

서명(signature)을 만들때 사용되는 알고리즘은 Header부분에 선언되어 있습니다.

토큰에서 실제 내용이 담기는 곳은 payload부분입니다.

9. AOP 관점지향 프로그래밍

01. AOP

a. OOP(Object Oriented Programming)

b. AOP(Aspect Oriented Programming)

AOP 핵심 키워드 - 횡단 관심사

횡단관심사는 여러곳에서 공통적으로 발생하는 기능(부가기능)을 의미합니다.

AOP - 관점지향 프로그래밍이란 ?

비즈니스 로직에서 횡단관심사(부가기능) 을 분리해서 관리하는 것 - 관점을 가지고 설계를 하는것!

AOP 중요 키워드

a. ⭐ 어드바이스(Advice)

부가기능 @Around, @Before, @After, @AfterThrowing

b. ⭐️포인트컷(PointCut)

어드바이스(부가기능 / 횡단관심사) 이 적용될 구체적인 범위를 표현하는 규칙

c. ⭐️대상객체(Target)

포인트컷 조건에 의해 어드바이스가 적용되는 실제 객체(클래스)

d. ⭐️조인포인트(JoinPoint)

어드바이스가 적용되는 실행지점(메서드)

// com.example.service 패키지에 포함되어 있는 CourseService 객체의 모든 메서드
execution(* com.example.service.CourseService..*(..))

e. ⭐️에스팩트(Aspect)

AOP 를 구성하는 하나의 단위(어드바이스 + 포인트컷)

정리

10. 운영환경 배포와 클라우드

a. 다양한 빌드 도구

JVM 진영의 대표적인 빌드 도구들은 다음과 같습니다.

Ant - 직접 빌드 스크립트를 작성 후 실행
Maven - XML(pom.xml) 파일 기반
Gradle - xml 의 한계 극복 → build.gradle

b. 빌드 파일 종류와 용도

SpringBoot 에서 jar 로 빌드하면 애플리케이션과 WAS(내장 톰캣)이 함께 패키징 되기 때문에 해당 jar 파일만으로 직접 실행할 수 있습니다.

c. 빌드파일 살펴보기 build.gradle

i. 어떤 빌드 규칙을 사용할지 결정

이건 자바 프로젝트야 그리고 2. 스프링부트도 쓸꺼야 3.. 의존성은 자동관리 시스템을 쓸꺼야

plugins {
    id 'java'
    id 'org.springframework.boot' version '3.4.5'
    id 'io.spring.dependency-management' version '1.1.7'
}

ii. 결과물의 이름 & 버전 설정

빌드하면 결과물(jar 파일) 이 만들어지는데 그 파일에 붙일 이름표를 결정하는 부분

group = 'com.example'
version = '0.0.1-SNAPSHOT'

프로파일(profile)

같은 애플리케이션을 환경별로 다르게 설정하기 위한 기능

a. 다양한 환경

⭐ 프로파일을 활용한 운영환경 배포 방법

a. 클라우드 개념

클라우드란 구름 - 구름이 하늘에 떠 있는 것처럼 인터넷 상에 떠있는 컴퓨터 자원을 의미합니다.

b. 클라우드에 배포 - 운영환경에 배포 해보기

i. 프로젝트 빌드 ii. 클라우드에 떠있는 Ec2 로 빌드 파일 원격 전송

scp -i <보안키.pem> <빌드파일경로> <아이디>@:<설치경로

scp -i ~/.ssh/id_rsa build/libs/basic-0.0.1-SNAPSHOT.jar gygimdev@34.64.152.58:~/app.jar

c. 클라우드에서 서버 실행

⚠️ 수동배포의 번거로움 번거로운 환경설정 → JVM 설치과정

이래서 도커가 나옴

정리

Q. 다음 중 스프링 프로젝트를 운영 서버에 배포하는 절차를 올바른 순서로 나열한 것은?

빌드 파일을 실행한다.
빌드 파일을 원격 서버로 전송한다.
프로젝트를 빌드해 실행 가능한 파일을 만든다.

C. 3 -> 2 -> 1

Q. ./gradlew build 명령어를 시작했을때 만들어지는 결과물은 무엇일까요?

A. .class 파일만 생성된다.

B. 실행 가능한 .jar 파일이 생성된다.

C. 소스 코드(.java) 복사된다.

D. 데이터베이스 스키마가 만들어진다.

Q. Ec2 서버에 jar 파일을 성공적으로 옮겼지만 java -jar app.jar 실행시

"command not found" 에러가 발생합니다. 가장 가능성이 높은 원인은?

A. jar 파일이 손상되었다.

B. 서버에 자바 런타임(JRE, JDK) 가 설치되지 않았다.

C. 포트가 열려있지 않다.

D. 데이터베이스 연결이 실패했다.

Q. 다음 중 로컬에서 만든 빌드파일을 원격 서버(EC2) 에 전송할때 사용하는 명령어는 ?

A. ssh

B. scp

C. git push

D. curl

Q. 스프링 프로젝트에서 profile 을 사용하는 가장 큰 이유는 무엇일까요?

A. 빌드 속도를 빠르게 하기 위해서

B. 코드 양을 줄이기 위해서

C. 개발, 운영 등 환경별로 다른 설정을 쉽게 적용하기 위해서

D. 자바 버전을 자동으로 맞추기 위해서

11. 도커(docker) - 컨테이너기술

01. 도커를 왜 배워야할까?

서버마다 환경을 설정해줘야하는 번거로움

02. 도커(docker)

리눅스 커널 기반으로 만들어진 컨테이너 기술입니다. 앱과 실행 환경을 통째로 묶어서 어디서든 똑같이 실행할 수 있게 도와주는 기술입니다.

a. 컨테이너의 3가지 철학

재현성 - 어디서든 동일한 실행 결과 보장
격리 - 컨테이너마다 독립된 환경에서 실행
불변성 - 이미지는 수정없이 항상 새 버전으로 교체

b. 다양한 컨테이너 기술들

docker, podman, containerD, etc

03. 가상머신(VM: virtual machine)

컴퓨터 안에 새로운 컴퓨터를 만드는 기술

vm 이 만들어질때 컴퓨터의 자원을 미리 나눠가집니다.(RAM, CPU)
- 컴퓨터 자원: RAM 16GB, CPU 8 코어
  - HOST: RAM 8GB, 4 코어
  - VM 1: RAM 4GB, 2 코어(나눠줌)
  - VM 2: RAM 4GB, 2 코어(나눠줌)
다른 곳에서 자원을 가져가지 못합니다.

OS Kernel

운영체제의 핵심부분입니다. 하드웨어와 소프트웨어 사이에서 통역하고 관리해주는 총 관리자라고 생각하시면 충분합니다.

window - NT Kernel (ms 독자 개발)
Mac -XNU (unix 계열)
Linux -Linux 커널 (도커가 그대로 도는 환경(네이티브 환경), unix 계열)

출처: 내일배움 스파르타 클럽

Spring심화 과제 트러블슈팅

Mon, 11 May 2026 01:17:34 GMT

🛠️ Spring Boot 프로젝트 실행 실패 해결하기 - JWT Secret Key와 DataSource 설정

🚨 문제 상황

새 과제 프로젝트를 clone한 뒤 애플리케이션을 실행했는데 서버가 정상적으로 실행되지 않았다.

처음 실행했을 때 아래와 같은 에러가 발생했다.

ApplicationContextException: Unable to start web server

처음에는 단순히 서버 실행 문제라고 생각했지만, 에러 로그를 아래로 내려보니 진짜 원인은 따로 있었다.

Could not resolve placeholder 'jwt.secret.key' in value "${jwt.secret.key}"

즉, Spring Boot가 실행되는 과정에서 jwt.secret.key 값을 찾지 못해서 JwtUtil Bean 생성에 실패하고 있었다.

🔍 원인 분석

프로젝트의 JwtUtil 클래스에서는 JWT Secret Key 값을 설정 파일에서 주입받고 있었다.

@Value("${jwt.secret.key}")
private String secretKey;

하지만 프로젝트를 처음 열었을 때 src/main/resources/application.properties 파일이 존재하지 않았다.

즉, Spring Boot 입장에서는 아래 값을 읽어와야 하는데,

jwt.secret.key=...

해당 설정 자체가 없었기 때문에 애플리케이션 실행에 실패한 것이다.

🧩 1차 해결 시도

먼저 src/main/resources 폴더를 만들고, 그 안에 application.properties 파일을 생성했다.

그리고 아래처럼 JWT Secret Key 값을 추가했다.

jwt.secret.key=sparta-spring-advanced-secret-key-2026-must-be-at-least-32-bytes

하지만 다시 실행해보니 또 다른 에러가 발생했다.

Illegal base64 character 2d

⚠️ 추가 문제 발생

이번 에러는 jwt.secret.key 값이 없어서 발생한 문제가 아니라, Secret Key의 형식이 잘못되어 발생한 문제였다.

JwtUtil 내부에서 Secret Key를 Base64로 디코딩하고 있었기 때문에 일반 문자열을 넣으면 안 됐다.

처음 넣은 값에는 - 하이픈이 포함되어 있었고, 이 문자는 Base64 디코딩 과정에서 문제가 되었다.

✅ 2차 해결

그래서 Secret Key 값을 Base64 형식의 문자열로 변경했다.

jwt.secret.key=MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDE=

이후 JWT 관련 에러는 해결되었다.

하지만 이번에는 DB 설정 관련 에러가 발생했다.

Failed to configure a DataSource: 'url' attribute is not specified

🗄️ DataSource 에러 원인

build.gradle을 확인해보니 MySQL 의존성이 추가되어 있었다.

runtimeOnly 'com.mysql:mysql-connector-j'

즉, 이 프로젝트는 MySQL DB 연결이 필요한 프로젝트였다.

하지만 application.properties에 DB 연결 정보가 없었기 때문에 Spring Boot가 어떤 DB에 연결해야 하는지 알 수 없었다.

✅ 최종 해결

MySQL에 사용할 데이터베이스를 생성했다.

CREATE DATABASE spring_advanced;

그리고 application.properties에 MySQL 연결 설정을 추가했다.

spring.datasource.url=jdbc:mysql://localhost:3306/spring_advanced
spring.datasource.username=root
spring.datasource.password=내 MySQL 비밀번호
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

spring.jpa.hibernate.ddl-auto=update
spring.jpa.show-sql=true

최종적으로 application.properties에는 JWT 설정과 DB 설정이 함께 들어가게 되었다.

jwt.secret.key=MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDE=

spring.datasource.url=jdbc:mysql://localhost:3306/spring_advanced
spring.datasource.username=root
spring.datasource.password=내 MySQL 비밀번호
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

spring.jpa.hibernate.ddl-auto=update
spring.jpa.show-sql=true

🎉 결과

다시 애플리케이션을 실행하니 서버가 정상적으로 실행되었다.

Tomcat started on port 8080
Started ExpertApplication

또한 Hibernate가 필요한 테이블들도 정상적으로 생성했다.

create table users
create table todos
create table comments
create table managers

🔐 주의한 점

application.properties에는 MySQL 비밀번호 같은 민감한 정보가 들어간다.

그래서 GitHub에 올라가지 않도록 반드시 .gitignore 적용 여부를 확인했다.

git check-ignore -v src/main/resources/application.properties

확인 결과 아래처럼 .gitignore에 의해 무시되고 있었다.

.gitignore:40:*.properties src/main/resources/application.properties

즉, DB 비밀번호가 GitHub에 올라가지 않는 안전한 상태였다.

🧠 알게 된 점

이번 트러블 슈팅을 통해 Spring Boot 프로젝트 실행 실패 로그를 볼 때는 가장 위의 에러만 볼 것이 아니라, 아래쪽의 Caused by를 따라가며 진짜 원인을 찾아야 한다는 것을 알게 되었다.

또한 @Value("${...}")로 주입받는 설정값은 반드시 application.properties 또는 application.yml에 존재해야 한다.

JWT Secret Key처럼 내부에서 Base64 디코딩을 수행하는 값은 단순 문자열이 아니라 Base64 형식으로 넣어야 한다는 점도 알게 되었다.

마지막으로 MySQL 의존성이 있는 프로젝트에서는 DataSource 설정이 없으면 애플리케이션 실행 단계에서 실패할 수 있다는 것도 확인했다.

📌 정리

이번 문제의 흐름은 다음과 같았다.

1. 프로젝트 실행 실패
2. jwt.secret.key 설정 누락 확인
3. application.properties 생성
4. JWT Secret Key 추가
5. Base64 형식 문제 해결
6. DataSource 설정 누락 확인
7. MySQL DB 생성 및 연결 설정 추가
8. 서버 정상 실행

단순히 에러 메시지만 보고 해결하려고 하기보다, 로그의 원인을 단계별로 따라가면서 해결하는 것이 중요하다는 것을 배웠다.

스프링 정리 2

Wed, 06 May 2026 11:47:16 GMT

3.데이터베이스 접근 방법(JPA)

01. JPA(Java Persistence API)

JPA(Java Persistence API) 는 자바에서 ORM을 위한 표준 명세 입니다.

a. ORM(Object Relational Mapping)

데이터베이스를 Object로 다루는 기술입니다. 자바에서는 Object 는 객체를 의미합니다.

b. 다양한 JPA 구현체

JPA 를 실제로 동작하게 하는 여러 구현체가 있습니다. 스프링부트에서 어떤 구현체를 사용할지 개발자가 결정할 수 있지만 기본적으로 Hibernate 구현체를 사용하고 있습니다.

02. JPA 가 SQL 을 실행하는 과정

JPA 로 편하게 DB 를 조작하는 것은 DB 에 SQL 을 보내는 과정을 편하게 만든 것입니다. → 실제로 DB 에 SQL 을 보내는 것은 JDBC 가 담당하게 됩니다.

JDBC(Java Database Connectivity)

자바와 DB 사이의 통신 규약(인터페이스)입니다.
구현체는 DB-driver(mysql, mariadb, 등) 가 담당합니다.

03. JPA 핵심 키워드 & 동작원리

⭐ a. EntityManagerFactory

EntityManagerFactory 는 DB 연결에 필요한 모든 세팅을 미리 해놓습니다. 그리고 요청이 들어오면 EntityManager 생성에 사용됩니다.

⭐ b. EntityManager

EntityManager 는 DB 에 저장, 조회, 수정, 삭제하는 작업자 입니다.

*Transaction 단위로 생성됩니다.

⭐ c. 엔티티

데이터베이스의 테이블 구조를 그대로 표현하는 역할을 가진 객체입니다.

@Entity
public class Book {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    private String author;
}

⭐ d. 영속성 컨텍스트

엔티티의 정보를 메모리에서 관리하는 임시 저장소. 데이터를 반영하기전 변경사항을 모두 기록합니다. 트랜잭션이 끝나면 모든 변경사항을 DB 에 반영합니다.

class Service {

        // 트랜잭션 시작
        @Transactional 
        public void doService() {

                // 1. 데이터 조회, 생성, 수정, 삭제 
                // ...
                // ...
        }
    // 트랜잭션 끝
}

i. 엔티티의 상태 ii. 영속성 컨텍스트의 4가지 특징

1차 캐싱

Book a = em.find(Book.class, "의문의책A"); // SELECT * FROM books WHERE id = '의문의책A'
Book b = em.find(Book.class, "의문의책A"); // SELECT 쿼리 발생 X (1차 캐시 사용)

동일성 보장

Book a = em.find(Book.class, "의문의책A");
Book b = em.find(Book.class, "의문의책A");

// 동일성 비교 true (같은 객체 반환) System.out.println(a == b);


3. 쓰기 지연
```java
EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();

//데이터 변경시 트랜잭션을 시작
transaction.begin(); // 트랜잭션 시작

em.persist(bookA); // (1) INSERT ...
em.persist(bookB); // (2) INSERT ...

// 쓰기지연은 persist 호출시 SQL 이 바로 실행되지 않습니다.
// (1, 2 의 sql 을 모았다가 보낸다.)
trasnaction.commit(); 트랜젝션 커밋

변경감지 ```java

--> 트랜잭션 시작

// 영속 Book findBook = em.find(Book.class, "채식주의자"); findBook.setName("소년이온다");

// persist 호출 불필요합니다. // 변경된 속성은 트랜잭션 커밋 시 자동 반영 됩니다. // em.persist(findBook);

--> 트랜잭션 끝


## ⭐ 요약

`EntityManager`  는 실제로 엔티티를 DB 에 저장, 조회, 수정, 삭제하는 작업자입니다. 


`EntityManagerFactory` 는 DB 에 연결에 필요한 모든 세팅을 미리 해놓고 `EntityManager` 생성에 사용됩니다.


`EntityManagerFactory` 는 애플리케이션 시작시 딱 한번 만들어지고 애플리케이션이 종료될때까지 유지됩니다.


 EntityManagerFactory 를 만들려면 `DataSource` 가 정상적으로 생성되어야합니다.


 EntityManager 는 EntityManagerFactory 로부터 생성되며 `Transaction`  단위로 생성되고 종료됩니다.

 `영속성컨텍스트`  는 엔티티를 메모리에서 관리하는 임시 저장소입니다.


 ---

 # 4. 인증인가 기초(쿠키, 세션, 토큰)

 ## ⭐ 01. 인증인가
 ![](https://velog.velcdn.com/images/loaded_diaper/post/213bb1b1-8eda-4e35-84de-b5b8bd9e908d/image.png)

a. 인증(Authentication) 
>누구인가 확인하는 단계 
![](https://velog.velcdn.com/images/loaded_diaper/post/93cdeb09-9471-4ca8-844c-edbea2b180d0/image.png)

b. 인가(Authorization) 
>자격을 확인하는 단계
![](https://velog.velcdn.com/images/loaded_diaper/post/2ecaf2a2-d044-461f-9858-df10d0902c1b/image.png)

## ⭐ 02. 쿠키
> 브라우저의 저장공간

![](https://velog.velcdn.com/images/loaded_diaper/post/c28b9781-7b70-4e09-9021-56727ab9bd7d/image.png)

### 쿠키인증의 한계
![](https://velog.velcdn.com/images/loaded_diaper/post/8df66b3d-1a61-4b64-b226-9b351f3ef1bf/image.png)


## ⭐ 03. 세션
>클라이언트와 서버의 연결을 나타내는 하나의 상태
![](https://velog.velcdn.com/images/loaded_diaper/post/16485669-8c1e-4cce-93e2-45c55398a43e/image.png)

 ### 세션의 한계
![](https://velog.velcdn.com/images/loaded_diaper/post/0e8eb433-7978-48f3-9185-6a51e033e01f/image.png)


## ⭐ 04. 토큰
>의미 있는 불규칙한 문자열
 ![](https://velog.velcdn.com/images/loaded_diaper/post/4fe7aeb1-f7c0-4bc2-a822-b61bca157a9b/image.png)
![](https://velog.velcdn.com/images/loaded_diaper/post/218d217c-dafd-436e-bc5e-b199c7169330/image.png)

### 토큰인증방식의 한계
암호화가 아닙니다 - 단순한 문자열(Base64 적용)


## ⭐ 요약
![](https://velog.velcdn.com/images/loaded_diaper/post/a95face2-5a8a-4b14-9234-118d815e2fb6/image.png)


---

# 5. 연관관계

## ⭐ 01. 데이터베이스 모델링
>어떤 서비스를 만들 때 필요한 데이터들을 정리하고 구조화하는 작업(테이블 명세 + ERD)
![](https://velog.velcdn.com/images/loaded_diaper/post/2d0db63a-5efa-46ab-a435-581a4a9a61f5/image.png)
![](https://velog.velcdn.com/images/loaded_diaper/post/1a0cfcec-7f8f-4e7d-949b-29e9f40545dd/image.png)


### 연관관계
>객체(엔티티) 가 서로 연결되어 있는 모습을 연관관계 라고 합니다. (JPA 와 다른 ORM 에서 사용하는 용어).

a. 연관관계 주인
b. 부모-자식 관계
c. 단방향과 양방향 연관관계


## ⭐ a. 연관관계 주인
>연관관계가 있는 테이블 사이에서
 물리적으로 다른테이블의 외래키를 소유하고 있는 테이블/엔티티를 연관관계의 주인이라고 표현합니다. 

![](https://velog.velcdn.com/images/loaded_diaper/post/05fe0921-f2b3-4dca-bec9-35885602cfed/image.png)
![](https://velog.velcdn.com/images/loaded_diaper/post/d6d40e6e-c21b-4532-b038-2ff360e8bf98/image.png)

## ⭐ b. 부모 - 자식 관계
>비즈니스 관점에서 한 도메인이 다른 도메인을 포함하는 논리적인 관계를 의미합니다.

- 부모: 포함하고 있는 도메인
- 자식: 포함되는 도메인

![](https://velog.velcdn.com/images/loaded_diaper/post/7679cb3a-b662-402b-913c-5ac4ce9286c6/image.png)

수강생은 연관관계 부모-자식 관계에서 `자식` 이다. 

수업은 연관관계 부모-자식 관계에서 `부모` 이다. 

### 연관관계 정리
![](https://velog.velcdn.com/images/loaded_diaper/post/0af24e5d-fe6a-4804-ab1a-0d9d61e96d61/image.png)

## ⭐ i. 단방향

> 한쪽에서만 다른 엔티티를 참조하는 상황 (`@ManyToOne`)

## ⭐ ii. 양방향

> 엔티티(객체) 들이 서로 참조하는 상황(`@OneToMany`)


## cascadeType 그리고 orphanRemoval
>양방향 연관관계를 더 멋지게? 사용하는 방법

## a. cascadeType

> 양방향 연관관계(@OneToMany) 에서 부모 엔티티를 PERSIT 하거나 REMOVE할때 연관된 자식 엔티티에게도 그 작업을 자동으로 적용할지 결정하는 설정
>![](https://velog.velcdn.com/images/loaded_diaper/post/97b91768-8577-461f-aed1-fcce42360720/image.png)

## b. orphanRemoval 
>부모와의 연관관계가 끊겨 있는 엔티티를 자동으로 삭제할지 결정하는 기능 
→ 부모 없는 엔티티 → 고아(orphan) 이라고 표현합니다. 
![](https://velog.velcdn.com/images/loaded_diaper/post/e389eb60-5bcd-4a9d-8de7-319b7d96b1bb/image.png)

## c. 조합 정리(cascadeType + orphanRemoval) 
 ![](https://velog.velcdn.com/images/loaded_diaper/post/4263d8c5-180e-416e-bb3c-a7385d51e847/image.png)


## ⭐ 05. 양방향 연관관계의 위험성
>양방향 연관관계 사용시 객체의 상태가 양쪽에 존재하기 때문에 어떤 값을 DB 에 반영해야하는지 JPA 가 자동으로 판단할 수 없는 모호한 상황이 발생할 수 있습니다.
![](https://velog.velcdn.com/images/loaded_diaper/post/1534765b-9456-488a-8ddb-d39deb9edcc7/image.png)

실무는 대부분 단방향


---

# 6. 스프링의 예외처리 원리
![](https://velog.velcdn.com/images/loaded_diaper/post/b0ce93a8-8e92-49aa-856d-dcfa64429430/image.png)

## 01. 예외 처리 복습 
>예외 처리 라고 하는 것은 크게 두가지로 나누어져 있습니다. 

예외 처리 
1. 직접 처리
2. 전파 후 처리(책임전가)

## 예외 종류
a. 체크예외(Exception) 
- `RuntimeException` 을 제외한 Exception 클래스를 상속받은 모든 하위 클래스
- 반드시 명시적으로 예외를 처리해야합니다.
- 컴파일러가 컴파일 단계에서 검사해줍니다. 

b. 언체크예외(UncheckedException) 
- `RuntimeException` 클래스를 상속 받은 모든 하위 예외 클래스
- 처리방식은 똑같지만 예외처리를 강제하지 않습니다.
- 컴파일 단계에서 검사해주지 않습니다. 

### 정리
 ![](https://velog.velcdn.com/images/loaded_diaper/post/137d12fa-01a5-4b11-b074-74ec6e320b61/image.png)


## ⭐ 4. 논의 - 언제 check / unchecked 를 사용해야할까?
>프로그램 실행 흐름안에서 직접 처리시 복구가능성이 있는 상황이라면 `checked` 그렇지 않다면 `unchecked` 를 사용합니다. 
 ![](https://velog.velcdn.com/images/loaded_diaper/post/f31748a9-4186-4573-ab3d-8dde808dca36/image.png)

![](https://velog.velcdn.com/images/loaded_diaper/post/3c8e2b45-c83b-4f13-8000-2c731e5d8f00/image.png)
![](https://velog.velcdn.com/images/loaded_diaper/post/63d8c003-9e10-4a9f-9c51-92932a3858eb/image.png)

## ⭐ 스프링 예외처리 흐름
>예외가 발생하면 /error 경로로 BasicErrorController 를 호출해서 에러 응답 본문을 만들어줍니다.
![](https://velog.velcdn.com/images/loaded_diaper/post/4e9130b9-f26d-42e3-a0a5-392499a592d7/image.png)
![](https://velog.velcdn.com/images/loaded_diaper/post/990075e3-0bbc-489d-8359-78b231b20a76/image.png)

## 예외처리 흐름 살펴보기 - 필터  
a. 필터 
>스프링필터는 WAS 와 DispatcherServlet 사이에 위치합니다. 이 위치 덕분에 모든 요청 응답에 대한 공통작업(보안검사, 요청/응답 기록 등) 처리에 적합한 역할을 합니다. 
![](https://velog.velcdn.com/images/loaded_diaper/post/f5a33055-f025-4b96-88a5-3d5f05ae8a0a/image.png)

## ⭐ 05. ExceptionResolver
>스프링은 3가지 resolver 를 활용해 예외처리시 사용할 상태코드, 에러메시지 등을 미리 설정합니다.
![](https://velog.velcdn.com/images/loaded_diaper/post/c5edd8f4-ebcb-4d7b-9a8e-4ef7841aaf85/image.png)

스프링에서 예외가 발생했을때  **c → b → a**  순차적으로 예외를 처리하려고 시도합니다.

1. DefaultHandlerExceptionResolver
2. ResponseStatusExceptionResolver
3. *(현업사용) ExceptionHandlerExceptionResolver

### 1. DefaultHandlerExceptionResolver

- 스프링에서 기본적으로 정의해놓은 표준 예외(메시지, 상태코드)를 처리하는 resolver 입니다.
- BasicErrorController 통해서 예외를 처리합니다.
- 파일참고: DefaultHandlerExceptionResolver.java 참고

### 2. ResponseStatusExceptionResolver

- @ResponseStatus  로 설정한 예외를 처리하는 resolver 입니다.
- BasicErrorController 통해서 예외를 처리합니다.

### ⭐ c. ExceptionHandlerExceptionResolver
커스텀하게 특정 예외에 상태코드, 메시지, 응답 본문을 만들어 줄 수 있습니다.
![](https://velog.velcdn.com/images/loaded_diaper/post/20ce57e7-206f-4e91-a78a-264862fa36d1/image.png)
![](https://velog.velcdn.com/images/loaded_diaper/post/be9da2d4-e6a7-4403-b9eb-9d861d037780/image.png)



















































































** 출처: 내일배움 스파르타 코딩 클럽**

[Spring Boot 트러블 슈팅] `@ModelAttribute` DTO에 값이 안 들어와서 상태 필터 검증이 동작하지 않았던 문제

Tue, 28 Apr 2026 04:01:39 GMT

주문 목록 조회 API를 구현하던 중, 분명히 잘못된 상태값을 보냈는데도 400 Bad Request가 아니라 200 OK가 반환되는 이상한 문제를 겪었다.

처음에는 상태 검증 로직이 잘못된 줄 알았는데, 원인은 전혀 다른 곳에 있었다.

문제 상황

주문 목록 조회 API는 아래처럼 구현되어 있었다.

@GetMapping
public ResponseEntity> getOrders(
        @SessionAttribute(name = SessionConst.ADMIN_ID) Long adminId,
        @ModelAttribute OrderListSearchRequestDto requestDto
) {
    OrderListResponseDto responseDto = orderService.getOrders(adminId, requestDto);

    OrderApiResponse response = OrderApiResponse.success(
            HttpStatus.OK.value(),
            "주문 목록 조회 성공",
            responseDto
    );

    return ResponseEntity.ok(response);
}

서비스에서는 status 값이 들어오면 enum 변환을 통해 유효한 상태값인지 검증하도록 작성해두었다.

OrderStatus orderStatus = null;

if (requestDto.getStatus() != null && !requestDto.getStatus().isBlank()) {
    try {
        orderStatus = OrderStatus.valueOf(requestDto.getStatus());
    } catch (IllegalArgumentException exception) {
        throw new ApiException(ErrorCode.INVALID_ORDER_STATUS);
    }
}

이 상태에서 아래 요청을 보냈다.

GET /api/orders?status=REA

REA는 유효한 주문 상태값이 아니므로, 당연히 INVALID_ORDER_STATUS 예외가 발생해서 400 Bad Request가 나와야 한다고 생각했다.

그런데 실제 결과는 200 OK였다.

처음에 의심했던 부분

처음에는 서비스 로직이 이상하다고 생각했다.

OrderStatus.valueOf(...)가 잘못된 걸까?
예외 처리가 이상한 걸까?
혹시 status 검증이 호출되지 않는 걸까?

코드만 계속 보고 있으면 원인을 찾기 어려웠다. 그래서 실제로 서비스에 어떤 값이 들어오는지 확인해보기로 했다.

원인 확인 방법

OrderService의 getOrders() 메서드 맨 위에 아래 로그를 찍었다.

System.out.println("status = " + requestDto.getStatus());
System.out.println("sortBy = " + requestDto.getSortBy());
System.out.println("direction = " + requestDto.getDirection());

그리고 다시 같은 요청을 보냈다.

GET /api/orders?status=REA

콘솔 결과는 이렇게 나왔다.

status = null
sortBy = orderedAt
direction = desc

여기서 원인이 확실해졌다.

쿼리파라미터로 status=REA를 보냈는데도 DTO 안에는 null로 들어오고 있었다.

즉, 문제는 상태 검증 로직이 아니라 아예 status 값이 DTO에 바인딩되지 않고 있었다는 점이었다.

왜 이런 일이 발생했나

문제의 DTO는 아래처럼 작성되어 있었다.

@Getter
@NoArgsConstructor
public class OrderListSearchRequestDto {

    private String keyword;
    private String status;

    @Min(value = 1, message = "페이지 번호는 1 이상이어야 합니다.")
    private Integer page = 1;

    @Min(value = 1, message = "페이지 크기는 1 이상이어야 합니다.")
    private Integer size = 10;

    private String sortBy = "orderedAt";
    private String direction = "desc";
}

겉보기에는 문제가 없어 보였지만, 여기엔 setter가 없었다.

이번 API는 GET 요청이고, 컨트롤러에서는 @ModelAttribute를 사용해서 쿼리파라미터를 DTO에 바인딩하고 있었다.

그런데 @ModelAttribute 방식으로 값을 채울 때는 현재 구조에서는 setter가 있어야 필드에 값이 정상적으로 들어갔다.

즉,

status=REA를 요청으로 보냄
하지만 DTO에 setter가 없음
그래서 status 필드에 값이 안 들어감
결국 requestDto.getStatus()는 null
상태 검증 로직이 실행되지 않음
전체 주문 목록이 그대로 조회됨

이 흐름이었다.

왜 `sortBy`, `direction`은 값이 있는 것처럼 보였을까

처음에 sortBy = orderedAt, direction = desc가 찍혀서 바인딩이 되고 있는 줄 착각할 수 있었다.

하지만 이 값들은 요청에서 들어온 게 아니라, DTO에 미리 설정해둔 기본값이었다.

private Integer page = 1;
private Integer size = 10;
private String sortBy = "orderedAt";
private String direction = "desc";

즉,

status는 바인딩 실패 → null
sortBy, direction은 바인딩 성공이 아니라 기본값 출력

이었던 것이다.

이 부분 때문에 문제를 처음에 더 늦게 파악했다.

해결 방법

해결은 간단했다. DTO에 @Setter를 추가했다.

@Getter
@Setter
@NoArgsConstructor
public class OrderListSearchRequestDto {

    private String keyword;
    private String status;

    @Min(value = 1, message = "페이지 번호는 1 이상이어야 합니다.")
    private Integer page = 1;

    @Min(value = 1, message = "페이지 크기는 1 이상이어야 합니다.")
    private Integer size = 10;

    private String sortBy = "orderedAt";
    private String direction = "desc";
}

그리고 다시 같은 요청을 보냈다.

GET /api/orders?status=REA

이번에는 콘솔에 이렇게 찍혔다.

status = REA
sortBy = orderedAt
direction = desc

이제는 status 값이 DTO에 정상적으로 들어왔고, 서비스의 상태값 검증 로직도 제대로 동작했다.

최종 응답도 기대한 대로 바뀌었다.

400 Bad Request
errorCode = INVALID_ORDER_STATUS

해결 전 / 해결 후

해결 전

status=REA 요청
DTO의 status 값이 null
상태 검증 로직이 실행되지 않음
전체 주문 목록이 200 OK로 조회됨

해결 후

status=REA 요청
DTO의 status 값이 "REA"로 정상 바인딩됨
OrderStatus.valueOf("REA")에서 예외 발생
INVALID_ORDER_STATUS와 함께 400 Bad Request 반환

이번 문제에서 배운 점

1. 로직보다 먼저 “실제 입력값”을 확인해야 한다

처음에는 검증 코드가 틀린 줄 알았다. 하지만 실제 문제는 DTO에 값이 안 들어오는 것이었다.

코드를 오래 붙잡고 있기보다, 서비스에 어떤 값이 실제로 들어오는지 먼저 확인하는 게 훨씬 빠르다는 걸 배웠다.

2. `@RequestBody`와 `@ModelAttribute`는 바인딩 방식이 다르다

이전에는 POST 요청에서 @RequestBody를 많이 다뤄서 DTO 바인딩을 비슷하게 생각하고 있었다.

하지만 이번 경험으로 차이를 더 분명히 이해했다.

@RequestBody → JSON 본문 바인딩
@ModelAttribute → 쿼리파라미터 바인딩

겉보기엔 둘 다 DTO를 받는 것 같지만, 실제로는 동작 방식이 다르다는 점을 체감했다.

3. 기본값이 있으면 바인딩 문제를 놓치기 쉽다

sortBy, direction이 계속 값이 찍히니까 처음에는 바인딩이 잘 되고 있다고 착각하기 쉬웠다.

하지만 그 값은 요청에서 들어온 값이 아니라 DTO 기본값이었다.

즉, 기본값이 들어간 DTO를 디버깅할 때는 “이 값이 진짜 요청에서 들어온 값인지, 그냥 기본값인지”를 꼭 구분해야 한다는 걸 배웠다.

정리

이번 트러블 슈팅의 핵심은 이 한 문장으로 정리할 수 있다.

@ModelAttribute로 받는 DTO에 setter가 없어서 쿼리파라미터가 바인딩되지 않았고, 그 결과 상태값 검증 로직이 동작하지 않았다.

처음에는 서비스 로직 문제처럼 보였지만, 실제로는 DTO 바인딩 문제였다.

작은 로그 출력 하나로 원인을 바로 확인할 수 있었고, DTO에 @Setter를 추가해서 해결할 수 있었다.

최종 코드

Controller

@GetMapping
public ResponseEntity> getOrders(
        @SessionAttribute(name = SessionConst.ADMIN_ID) Long adminId,
        @ModelAttribute OrderListSearchRequestDto requestDto
) {
    OrderListResponseDto responseDto = orderService.getOrders(adminId, requestDto);

    OrderApiResponse response = OrderApiResponse.success(
            HttpStatus.OK.value(),
            "주문 목록 조회 성공",
            responseDto
    );

    return ResponseEntity.ok(response);
}

DTO

@Getter
@Setter
@NoArgsConstructor
public class OrderListSearchRequestDto {

    private String keyword;
    private String status;

    @Min(value = 1, message = "페이지 번호는 1 이상이어야 합니다.")
    private Integer page = 1;

    @Min(value = 1, message = "페이지 크기는 1 이상이어야 합니다.")
    private Integer size = 10;

    private String sortBy = "orderedAt";
    private String direction = "desc";
}

Spring 에러 로그 읽는 법

Wed, 22 Apr 2026 06:25:33 GMT

Trouble Shooting - 스프링 에러 로그 읽는 법과 `Not a managed type` 문제

유저 생성 기능을 추가한 뒤 서버 실행 중 아래와 같은 에러가 발생했다.

Error starting ApplicationContext
Application run failed
...
Not a managed type: class com.schedule2.entity.User

처음에는 맨 위의 Application run failed 만 보고 원인을 찾으려고 했는데, 이 문장은 단순히 “애플리케이션 실행이 실패했다” 는 요약일 뿐이었다.

실제 원인은 에러 로그를 아래로 내려가며 확인한 Caused by 부분에 있었다.

에러 흐름은 다음과 같았다.

UserController 생성 실패
UserService 생성 실패
UserRepository 생성 실패
최종 원인: Not a managed type: class com.schedule2.entity.User

즉, JPA가 User 클래스를 엔티티로 관리되는 타입으로 인식하지 못해서 UserRepository를 생성할 수 없었고, 그 결과로 서비스와 컨트롤러도 연쇄적으로 생성되지 못한 것이었다.

원인

User 엔티티가 JPA 엔티티로 제대로 등록되지 않은 상태였다.

해결 방법

User 클래스에 엔티티 관련 설정이 제대로 들어가 있는지 확인했다.

@Entity
@Table(name = "users")
public class User extends BaseEntity {

그리고 저장/빌드 상태까지 다시 확인한 뒤 서버를 재실행하니 문제가 해결되었다.

이번에 배운 점

스프링 에러 로그를 볼 때는 맨 위 요약 문장만 보면 안 되고, 반드시 아래쪽의 Caused by 와 가장 마지막의 구체적인 에러 문장을 확인해야 한다.

즉,

위쪽: 어떤 작업이 실패했는지
아래쪽: 왜 실패했는지

이 순서로 읽는 습관이 중요하다.

Spring 숙련 과제 트러블 슈팅

Wed, 22 Apr 2026 05:59:02 GMT

Trouble Shooting - `getCreatedAt()` / `getUpdatedAt()` 메서드가 인식되지 않은 문제

유저 생성 기능을 구현하면서 UserService에서 아래 코드를 작성했을 때 에러가 발생했다.

savedUser.getCreatedAt()
savedUser.getUpdatedAt()

처음에는 BaseEntity에 createdAt, updatedAt 필드와 getter를 만들어 두었기 때문에 User 엔티티에서도 당연히 사용할 수 있을 것이라고 생각했다.

하지만 원인은 User 엔티티가 BaseEntity를 상속받고 있지 않았기 때문이었다.

기존 코드는 다음과 같았다.

public class User {

이 상태에서는 User 클래스가 BaseEntity의 필드와 메서드를 물려받지 못하므로 getCreatedAt()과 getUpdatedAt()을 사용할 수 없다.

그래서 클래스 선언부를 아래처럼 수정했다.

public class User extends BaseEntity {

수정 후에는 User 엔티티가 BaseEntity의 공통 필드와 메서드를 상속받게 되었고, createdAt, updatedAt, getCreatedAt(), getUpdatedAt()을 정상적으로 사용할 수 있었다.

정리

getCreatedAt()이 안 잡힌 이유: User가 BaseEntity를 상속하지 않았기 때문
해결 방법: User extends BaseEntity로 수정
배운 점: 공통 필드/공통 메서드를 부모 클래스에 만들었더라도, 자식 클래스가 상속하지 않으면 사용할 수 없다

숙련 스프링 과제하면서 헷갈렸던 것들

Tue, 21 Apr 2026 11:35:40 GMT

package com.schedule2.service;

import com.schedule2.dto.ScheduleCreateRequestDto;
import com.schedule2.dto.ScheduleResponseDto;
import com.schedule2.entity.Schedule;
import com.schedule2.repository.ScheduleRepository;
import org.springframework.stereotype.Service;

// 일정 관련 비즈니스 로직을 처리하는 서비스 클래스
@Service
public class ScheduleService {

    // ==================== 속성 ====================

    // 일정 데이터를 데이터베이스에 저장하고 조회할 레포지토리
    private final ScheduleRepository scheduleRepository;


    // ==================== 생성자 ====================

    // 서비스가 레포지토리 객체를 전달받는 생성자
    public ScheduleService(ScheduleRepository scheduleRepository) {
        this.scheduleRepository = scheduleRepository;
    }


    // ==================== 기능 ====================

    // 일정 생성 기능
    public ScheduleResponseDto createSchedule(ScheduleCreateRequestDto requestDto) {

        // 1. 요청값 꺼내기
        String username = requestDto.getUsername();
        String title = requestDto.getTitle();
        String contents = requestDto.getContents();

        // 2. 요청값으로 Schedule 엔티티 만들기
        Schedule schedule = new Schedule(username, title, contents);

        // 3. DB에 저장하기
        Schedule savedSchedule = scheduleRepository.save(schedule);

        // 4. 저장된 결과를 응답 DTO로 만들기
        ScheduleResponseDto responseDto = new ScheduleResponseDto(
                savedSchedule.getId(),
                savedSchedule.getUsername(),
                savedSchedule.getTitle(),
                savedSchedule.getContents(),
                savedSchedule.getCreatedAt(),
                savedSchedule.getUpdatedAt()
        );

        // 5. 응답 DTO 반환하기
        return responseDto;
    }
}

### `save()` 결과를 다시 변수에 담는 이유

```java
Schedule savedSchedule = scheduleRepository.save(schedule);

처음 만든 schedule 객체는 아직 DB에 저장되기 전 상태라서 id, createdAt, updatedAt 같은 값이 비어 있을 수 있다.

하지만 save()로 DB에 저장하고 나면

id가 생성되고
createdAt, updatedAt 같은 값도 채워질 수 있다.

그래서 저장 결과를 savedSchedule에 다시 담아서 저장 후 최종 상태의 객체를 사용한다.

즉,

schedule = 저장 전 객체
savedSchedule = 저장 후 값이 반영된 객체

라고 이해하면 된다.

// 일정 전체 조회 기능
public List getAllSchedules() {

    // 1. DB에서 일정 전체 조회하기
    List scheduleList = scheduleRepository.findAll();

    // 2. 응답 DTO들을 담을 빈 리스트 만들기
    List responseDtoList = new ArrayList<>();

    // 3. 조회한 일정들을 하나씩 꺼내서 응답 DTO로 바꾸기
    for (Schedule schedule : scheduleList) {

        ScheduleResponseDto responseDto = new ScheduleResponseDto(
                schedule.getId(),
                schedule.getUsername(),
                schedule.getTitle(),
                schedule.getContents(),
                schedule.getCreatedAt(),
                schedule.getUpdatedAt()
        );

        // 4. 만들어진 응답 DTO를 리스트에 담기
        responseDtoList.add(responseDto);
    }

    // 5. 최종 응답 리스트 반환하기
    return responseDtoList;
}

일정 전체 조회 로직 정리

getAllSchedules() 메서드는 DB에서 일정 전체를 조회한 뒤,
그 결과를 그대로 반환하지 않고 ScheduleResponseDto 리스트로 바꿔서 반환한다.

흐름은 다음과 같다.

scheduleRepository.findAll()로 DB에 저장된 일정들을 모두 조회한다.
조회한 결과는 List 형태로 받아온다.
응답용 리스트(List)를 새로 만든다.
반복문을 사용해서 Schedule 객체를 하나씩 꺼낸다.
각 Schedule 객체를 ScheduleResponseDto로 변환한다.
변환한 DTO를 응답용 리스트에 담는다.
최종적으로 DTO 리스트를 반환한다.

즉,
엔티티 리스트를 그대로 주는 것이 아니라, 응답용 DTO 리스트로 변환해서 반환하는 과정이라고 이해하면 된다.

DB 세팅

`ddl-auto` 옵션 간단 정리

Spring JPA에서 ddl-auto 옵션은 애플리케이션 실행 시
테이블을 어떻게 다룰지 정하는 설정이다.

create
실행할 때 테이블을 새로 생성한다.

기존 데이터가 사라질 수 있어서 개발 중 테스트용으로만 주로 사용한다.
update
엔티티 변경 사항을 기준으로 테이블 구조를 맞춰준다.
기존 데이터는 유지되기 때문에 개발 중 가장 많이 사용한다.
none
JPA가 테이블 생성이나 수정에 관여하지 않는다.
DB를 직접 준비한 경우에 사용한다.
validate
엔티티와 테이블 구조가 맞는지만 검사한다.
테이블을 새로 만들거나 수정하지 않기 때문에 제출용이나 최종 점검용으로 많이 사용한다.

스프링 기본 활용

Thu, 16 Apr 2026 11:56:38 GMT

베이직 1회차

스프링이란? → IoC 컨테이너

스프링은 IoC 컨테이너 를 제공해주는 프레임워크입니다. → 핵심 기능은 IoC 기반의 DI 을 제공하는 ApplicationContext 라는 IoC 컨테이너입니다.

⭐ 개념1 - 스프링컨테이너(IoC 컨테이너)

애플리케이션이 시작될때 스프링컨테이너(IoC 컨테이너) 는 애플리케이션 실행에 필요한 객체를 생성하고 각 객체에 필요한 의존성을 주입합니다. 스프링컨테이너는 이렇게 생성한 객체를 미리 생성해두고 관리하기 때문에 요청이 들어오면 요청처리에 적합한 객체를 활용해 요청을 처리합니다.

⭐ 개념2 - 스프링빈(SpringBean)

IoC 컨테이너에 의해서 생성되고 관리되는 객체를 스프링빈(SpringBean) 이라고 합니다.

⭐ 스프링기술 - 컴포넌트 스캔(Component Scan)

스프링의 자체 기능 - 자바 객체를 스프링 빈으로 등록하는 기술 컴포넌트스캔 을 활용해서 자바 클래스를 스프링 빈 등록 대상으로 지정할 수 있습니다.

다양한 어노테이션 종류들

@Component
@RestController
@Controller
@Service
@Repository
etc

⭐ web 기술 - 요청 연결 매핑(Request Mapping)

@RequestMapping() - 보통 클래스 레벨에서 공통 경로 잡을 때 사용
- @GetMapping() - 조회. 데이터 가져올 때 (목록 조회, 상세 조회)
- @PostMapping() - 생성. 새 데이터 만들 때 (회원가입, 글 작성)
- @PatchMapping() - 부분 수정. 기존 데이터 일부만 바꿀 때 (이름만 변경)
- @DeleteMapping() - 삭제. 데이터 지울 때 (글 삭제, 회원 탈퇴)

⭐ web 기술 - 클라이언트에서 데이터를 받아오는 방법

@RequestBody

클라이언트가 HTTP 요청 바디로 데이터를 전송할때 사용해야합니다.

POST example.com/schedule

"title": "코딩"

 @PostMapping("/requestbody")
    public String useRequestBody(@RequestBody DataTransferObject dto) {
        System.out.println("message = " + dto.getMessage());
        return "response 문자열";
    }

@PathVariablle

클라이언트가 URL 경로로 데이터를 전송할 때 사용해야합니다.

GET example.com/schedule/1

@GetMapping("/schedule/{id}")
public String find(@PathVariable Long id) {
    return "조회 ID: " + id;
}

@RequestParm

클라이언트가 URL 쿼리 파라미터로 데이터를 전송할때 사용해야합니다.

GET example.com/schedule?title=코딩

@GetMapping("/schedule")
public String search(@RequestParam String title) {
 return "검색어: " + title;
}

⭐ JPA 기술 - 데이터베이스를 다루는 방법

a. 엔티티

엔티티는 자바 클래스와 DB 테이블을 연결해주는 개념입니다.

@Entity

b. repository

JpaRepository 를 활용해서 인터페이스를 만들면 스프링이 알아서 ScheduleRepository클래스를 구현해줍니다!

public interface ScheduleRepository extends JpaRepository {}

자동으로 구현된 기능:
- 전체 조회 - findAll()
- 단건조회 - findById(…)
- 저장 - save()
- 삭제 - delete()

⭐ 3 계층

⭐ 요약

스프링이 관리하는 객체를 스프링 빈이라고 한다.
스프링 빈을 보관하고 관리하는 곳을 Ioc컨테이너라고 한다.
@Component, @Service, @Repository 등이 붙은 클래스를 자동으로 찾아서 스프링 빈으로 등록하는 기술을 컴포넌트스캔 이라고 합니다.
클라이언트가 URL 경로에 데이터를 보낼 때 사용하는 어노테이션은 @PathVariable 이다. 요청예시: GET /schedule/1
클라이언트가 HTTP 요청 바디로 데이터를 보낼 때 사용하는 어노테이션은 @RequestBody 이다. 요청예시: POST /schedule {"title": "코딩"}
클라이언트가 쿼리 파라미터로 데이터를 보낼 때 사용하는 어노테이션은 @RequestParam 이다. 요청예시: GET /schedule?title="코딩"
자바 클래스와 DB 테이블을 연결해주는 설계도 역할을 하는 것을 엔티티(entity) 라고 합니다.

베이직 2회차

객체간의 결합도를 통한 3계층 이해(DI, IoC)

의존(Dependency)

객체지향 프로그래밍에서는 객체들이 서로 상호작용합니다. 이 과정에서 한 객체가 다른 객체를 필요하게 되는데 이 관계를 의존(Dependency) 라고 표현합니다.

⭐ 의존성 주입(Dependency Injection)

Car 라는 객체가 필요로 하는 객체(의존객체: Engine) 를 외부에서 생성해서 Car 에 주입해주는 것을 의존성 주입이라고 합니다.

⭐ 객체간의 결합도

객체간의 의존성을 어떻게 설정해주느냐에 따라서 객체간의 결합도가 달라집니다.

1단계 - 직접 의존 + 스스로 생성

필요한 의존 객체를 직접 생성하는 구조

강한 결합
변경에 취약

2단계 - 직접 의존 + 외부에서 생성

의존 객체를 외부에서 생성해서 전달받는 구조

생성 책임이 외부로 분리됨
하지만 여전히 구체적인 클래스에 의존

3단계 - 추상화에 의존

구현체가 아니라 추상화(인터페이스)에 의존하는 구조

구현체 자유롭게 변경 가능
느슨한 결합

⭐ 다형성

하나의 형태(인터페이스/부모클래스)로 여러가지 형태(구현체) 를 다룰 수 있는 성질

⭐ IoC(제어 역전: Inversion of Control)

프로그램 제어흐름을 외부(제 3의 주체) 로 넘기는 설계원칙 → 스프링에서는 IoC 개념을 컨테이너 형태로 제공해줍니다.

⭐ 스프링의 의존성 주입 방법

생성자 주입

@Service
public class MemberService {...}

@RestController
public class MemberController {
 private final MemberService memberService;

     @Autowired // 생략 가능
 public UserController(MemberService memberService) {
     this.memberService = memberService;
 }
}

@Autowired생략가능

필드주입

@Service
public class MemberService {...}

@RestController
public class MemberController {

     @Autowired
 private MemberService memberService;

 ...
}

세터주입

@Service
public class MemberService {...}

@RestController
public class MemberController {
 private MemberController memberService;

     @Autowired
 public void setMemberService(MemberController memberService) {
     this.memberService = memberService;
 }

     ...
}

⭐ 정리

⭐ 요약

하나의 데이터타입으로 다양한 구현체를 다룰 수 있는 성질을 다형성 이라고 합니다.
프로그램 제어흐름을 외부로 넘기는 설계 원칙을 제어 역전(IoC: Inversion of Control) 라고 합니다.
구현체가 아닌 인터페이스에 의존하면 Car 코드를 수정하지 않고도 Engine 을 자유롭게 교체할 수 있었습니다. 이를 느슨한 결합 결합이라고 합니다.
객체가 필요로 하는 B객체(의존객체) 를 외부에서 생성해서 주입해주는 것을 의존성주입(DI: dependency Injection) 이라고 합니다.
private Engine engine = new ElectricEngine(); 처럼 의존 객체를 직접 생성하면 엔진을 교체하려고 할때 코드를 수정해야합니다. 이를 강한 결합 결합이라고 합니다.

출처: 내일배움스파르타

스파르타 15일차

Mon, 30 Mar 2026 08:38:41 GMT

객체지향 설계에서 무분별한 Setter를 지양해야 하는 이유

오늘은 자바 객체지향 과제를 진행하면서 Setter를 무조건 만드는 것이 꼭 좋은 것은 아니라는 점을 다시 정리하게 되었다. 처음에는 클래스 필드를 만들면 자연스럽게 Getter, Setter를 전부 작성하는 습관이 있었는데, 과제를 진행하고 피드백을 들으면서 중요한 값은 함부로 바뀌지 않도록 설계하는 것이 더 객체지향적이라는 점을 이해하게 되었다.

1. 처음에는 왜 Setter를 다 만들게 될까?

자바를 처음 배우면 보통 이렇게 배운다.

필드는 private으로 숨긴다
Getter로 값을 조회한다
Setter로 값을 수정한다

그래서 자연스럽게 모든 필드에 대해 Getter, Setter를 전부 만드는 습관이 생긴다.

예를 들어 Product 클래스가 있으면 이렇게 작성하기 쉽다.

public class Product {

    private String productName;
    private long productPrice;
    private String productDescription;
    private int productStock;

    public Product(String productName, long productPrice, String productDescription, int productStock) {
        this.productName = productName;
        this.productPrice = productPrice;
        this.productDescription = productDescription;
        this.productStock = productStock;
    }

    public String getProductName() {
        return productName;
    }

    public void setProductName(String productName) {
        this.productName = productName;
    }

    public long getProductPrice() {
        return productPrice;
    }

    public void setProductPrice(long productPrice) {
        this.productPrice = productPrice;
    }

    public String getProductDescription() {
        return productDescription;
    }

    public void setProductDescription(String productDescription) {
        this.productDescription = productDescription;
    }

    public int getProductStock() {
        return productStock;
    }

    public void setProductStock(int productStock) {
        this.productStock = productStock;
    }
}

처음에는 이 방식이 정석처럼 보인다. 하지만 이렇게 하면 객체의 중요한 정보가 외부에서 너무 쉽게 변경될 수 있다.

2. 무분별한 Setter가 왜 문제일까?

예를 들어 상품 가격, 상품명, 재고는 중요한 데이터다. 그런데 Setter를 전부 열어두면 밖에서 이렇게 바꿀 수 있다.

product.setProductPrice(-10000);
product.setProductName("이상한 상품명");
product.setProductStock(-5);

이렇게 되면 객체가 스스로 자신의 상태를 지키지 못한다. 즉, 객체가 안전하지 않다.

객체지향에서는 단순히 필드를 숨기는 것만 중요한 것이 아니라, 그 값을 누가, 언제, 어떤 방식으로 바꿀 수 있는지까지 통제하는 것이 중요하다.

3. Getter는 조회, Setter는 수정이다

오늘 다시 정리한 중요한 포인트는 이것이다.

Getter는 객체의 값을 읽기 위해 사용한다
Setter는 객체의 값을 바꾸기 위해 사용한다

문제는 “조회”보다 “수정”이 훨씬 위험하다는 점이다.

값을 읽는 것은 비교적 안전하지만, 값을 수정하는 순간 객체 상태가 달라진다. 그래서 수정 메서드는 정말 필요한 경우에만 열어두는 것이 좋다.

4. 현재 단계에서는 Setter가 꼭 필요하지 않았다

이번 커머스 과제에서 만든 클래스들은 대략 이런 역할을 가진다.

Product : 상품 1개 정보
Category : 카테고리 이름 + 상품 목록
Customer : 고객 정보
CommerceSystem : 프로그램 흐름 제어

이 단계에서 대부분의 객체는 조회가 중심이었다.

예를 들면:

상품명을 출력한다
가격을 출력한다
설명을 출력한다
카테고리 이름을 출력한다
고객 정보를 확인한다

즉, 값을 읽는 것은 많이 하지만 중간에 값을 계속 수정할 필요는 거의 없었다.

그래서 Setter를 모두 둘 필요가 없다고 판단했다.

5. 불필요한 Setter를 제거한 방향

예를 들어 Category는 생성될 때 이름과 상품 목록이 정해지면, 실행 중에 굳이 계속 이름을 바꿀 필요가 없다.

그래서 이런 식으로 최소한의 구조로 가져가는 것이 더 자연스럽다.

public class Category {

    private String categoryName;
    private List products;

    public Category(String categoryName, List products) {
        this.categoryName = categoryName;
        this.products = products;
    }

    public String getCategoryName() {
        return categoryName;
    }

    public List getProducts() {
        return products;
    }
}

Customer도 마찬가지다.

public class Customer {

    private String customerName;
    private String email;
    private String grade;

    public Customer(String customerName, String email, String grade) {
        this.customerName = customerName;
        this.email = email;
        this.grade = grade;
    }

    public String getCustomerName() {
        return customerName;
    }

    public String getEmail() {
        return email;
    }

    public String getGrade() {
        return grade;
    }
}

이렇게 하면 객체를 만들 때 필요한 값을 넣고, 그 이후에는 필요한 정보만 조회하는 구조가 된다.

6. Setter 대신 더 의미 있는 메서드를 만드는 것이 좋다

오늘 공부하면서 가장 인상 깊었던 부분은 무조건 setXXX()를 만드는 것보다, 의도가 드러나는 메서드를 만드는 것이 더 좋다는 점이다.

예를 들어 상품 재고는 나중에 주문 기능이 생기면 바뀔 수 있다. 그런데 이렇게 작성하는 것보다:

product.setProductStock(29);

이렇게 작성하는 것이 훨씬 자연스럽다.

product.decreaseStock(1);

왜냐하면 setProductStock(29)는 그 값이 왜 29가 되었는지 문맥이 잘 드러나지 않는다.

반면 decreaseStock(1)은 “재고를 1개 줄인다”는 의도가 명확하다.

즉, Setter는 단순 수정이고 의미 있는 메서드는 행동 중심 설계에 더 가깝다.

7. 캡슐화와도 연결된다

이번 과제 Step 4가 캡슐화였는데, Setter를 줄이는 방향은 캡슐화와도 연결된다.

캡슐화는 단순히 private을 붙이는 것만이 아니라 객체 내부 상태를 안전하게 관리하는 것이다.

즉:

필드는 private으로 숨기고
필요한 값은 Getter로 조회하고
수정은 꼭 필요한 경우에만 허용하고
가능하면 의미 있는 행동 메서드로 표현한다

이런 방식이 더 좋은 캡슐화라고 느꼈다.

8. 오늘 정리한 기준

앞으로는 필드를 만들 때 무조건 Setter를 만들지 않고, 아래 기준으로 생각해보려고 한다.

Setter가 필요 없는 경우

생성 시 값이 정해지고 이후 잘 바뀌지 않는 경우
외부에서 함부로 수정되면 안 되는 중요한 정보
현재 단계에서 조회만 필요한 경우

Setter 대신 다른 메서드가 더 좋은 경우

값 수정에 명확한 의도가 있는 경우
단순 대입이 아니라 “행동”을 표현해야 하는 경우

예:

setProductStock() 보다 decreaseStock()
setOrderStatus() 보다 completeOrder()

9. 오늘 느낀 점

예전에는 Getter, Setter를 모두 만드는 것이 좋은 습관이라고만 생각했다. 하지만 오늘은 “모든 Setter가 좋은 것은 아니다”라는 점을 분명히 이해하게 되었다.

객체지향에서 중요한 것은 단순히 클래스를 나누는 것이 아니라, 객체가 자신의 데이터를 어떻게 지키는지 설계하는 것이었다.

특히 이번 커머스 과제를 하면서 Product, Category, Customer 같은 클래스는 지금 단계에서 조회가 중심이기 때문에 불필요한 Setter를 열어두지 않는 것이 더 적절하다고 느꼈다.

10. 한 줄 요약

Setter는 무조건 만드는 것이 아니라, 정말 필요한 경우에만 열어두고, 가능하면 객체의 의도가 드러나는 메서드로 설계하는 것이 더 객체지향적이다.

스파르타 14일차

Fri, 27 Mar 2026 11:49:45 GMT

객체지향적 코딩에 대해서 생각해보았다 코딩을 하면서 처음으로 생각해 본 듯?

생성자 주입이 왜 좋은가?

이전에는 Scanner를 CommerceSystem 안에서 직접 생성할지, 아니면 Main에서 만들어서 넘길지 고민했다.

예를 들면 이런 두 방식이 있다.

1. 클래스 내부에서 직접 생성하는 방식

public class CommerceSystem {

    private Scanner scanner = new Scanner(System.in);

}

2. 생성자로 전달받는 방식

public class CommerceSystem {

    private Scanner scanner;

    public CommerceSystem(Scanner scanner) {
        this.scanner = scanner;
    }
}

이 두 방식 중에서 객체지향적으로 더 깔끔한 방법은 생성자 주입 방식이다.

1. 생성자 주입이란?

생성자 주입은 클래스가 필요한 객체를 스스로 만들지 않고, 밖에서 전달받는 방식이다.

예를 들면:

Scanner scanner = new Scanner(System.in);
CommerceSystem commerceSystem = new CommerceSystem(scanner);

이 구조는 이런 흐름이다.

Main이 필요한 객체를 생성한다.
CommerceSystem은 생성자를 통해 그 객체를 전달받는다.
전달받은 객체를 필드에 저장해서 사용한다.

즉, CommerceSystem이 Scanner를 직접 만들지 않고 이미 준비된 Scanner를 받는 구조다.

2. 왜 직접 생성하지 않고 전달받는 것이 좋을까?

이유 1. 역할이 더 분명해진다

Main은 프로그램 시작점이고, 필요한 객체를 준비하는 역할을 맡는다.

CommerceSystem은 준비된 객체를 받아서 실제 기능을 수행하는 역할을 맡는다.

즉 역할이 이렇게 나뉜다.

Main : 준비 담당
CommerceSystem : 실행 담당

이 구조가 더 자연스럽다.

만약 CommerceSystem 안에서 Scanner를 직접 만든다면, CommerceSystem은 기능 수행뿐 아니라 객체 생성까지 같이 하게 된다.

그러면 역할이 조금 섞인다.

이유 2. 코드가 더 일관적이다

이미 CommerceSystem은 products도 밖에서 받고 있다.

public CommerceSystem(List products, Scanner scanner) {
    this.products = products;
    this.scanner = scanner;
}

즉 products는 밖에서 받고, scanner만 내부에서 직접 만들면 설계가 통일되지 않는다.

반면 둘 다 밖에서 전달받으면 흐름이 깔끔하다.

필요한 객체는 모두 Main이 준비한다.
CommerceSystem은 전달받은 것만 사용한다.

이런 구조가 더 읽기 쉽고 설계 의도가 분명하다.

이유 3. 나중에 변경하기 쉬워진다

처음에는 Scanner(System.in)을 쓸 수 있다. 그런데 나중에는 입력 방식이 달라질 수도 있다.

예를 들어:

파일에서 입력받기
테스트용 입력값 사용하기
다른 입력 객체로 변경하기

만약 CommerceSystem 안에서 직접 new Scanner(System.in)을 써버리면, 입력 방식을 바꾸려면 CommerceSystem 코드를 직접 수정해야 한다.

하지만 생성자 주입 구조라면 CommerceSystem은 그대로 두고, Main에서 어떤 Scanner를 넘길지만 바꾸면 된다.

즉 변경에 더 유연하다.

이유 4. 테스트하기 쉬워진다

지금 단계에서는 테스트 코드까지 깊게 안 가도 되지만, 구조적으로는 이것도 큰 장점이다.

직접 생성하는 방식은:

private Scanner scanner = new Scanner(System.in);

이렇게 고정돼 있어서 테스트할 때 다루기 불편하다.

반면 생성자 주입은:

public CommerceSystem(Scanner scanner) {
    this.scanner = scanner;
}

이렇게 되어 있으니, 테스트할 때 원하는 입력 객체를 넣어볼 수 있다.

즉 외부에서 조립 가능하다는 점이 장점이다.

3. 직접 생성 방식과 생성자 주입 방식 비교

직접 생성 방식

public class CommerceSystem {

    private Scanner scanner = new Scanner(System.in);

}

이 방식의 특징:

편해 보인다
바로 쓸 수 있다
하지만 클래스가 도구를 직접 만들고 있다
변경과 테스트에 불리하다

생성자 주입 방식

public class CommerceSystem {

    private Scanner scanner;

    public CommerceSystem(Scanner scanner) {
        this.scanner = scanner;
    }
}

이 방식의 특징:

처음엔 조금 더 길어 보인다
하지만 구조가 더 깔끔하다
필요한 객체를 외부에서 조립할 수 있다
역할 분리가 명확하다

4. 현재 프로젝트에 적용하면

Main.java

Scanner scanner = new Scanner(System.in);

CommerceSystem commerceSystem = new CommerceSystem(products, scanner);
commerceSystem.start();

scanner.close();

CommerceSystem.java

private List products;
private Scanner scanner;

public CommerceSystem(List products, Scanner scanner) {
    this.products = products;
    this.scanner = scanner;
}

이 구조의 장점은 명확하다.

Main이 필요한 객체를 준비한다.
CommerceSystem은 전달받은 객체를 사용한다.
설계가 일관적이다.

5. 초보자 눈높이로 이해하면

이걸 아주 쉽게 생각하면:

직접 생성 방식

CommerceSystem이 말한다.

“상품도 내가 받고, Scanner는 내가 직접 만들게.”

생성자 주입 방식

Main이 말한다.

“필요한 재료는 내가 다 준비해줄게. 너는 그걸 받아서 일만 하면 돼.”

두 번째가 더 깔끔하지 않나?

즉 생성자 주입은 필요한 재료를 밖에서 넣어주는 방식이라고 생각하면 된다.

6. 생성자 주입의 핵심 정리

생성자 주입이 좋은 이유는 다음과 같다.

역할 분리가 더 명확하다
객체 생성 책임이 Main에 모인다
설계가 일관적이다
변경에 유연하다
테스트하기 쉽다

7. 내가 이번에 이해한 점

이번 과제를 하면서 느낀 점은, 단순히 “동작만 하면 된다”가 아니라 누가 만들고, 누가 받고, 누가 사용하는지를 나누는 것이 중요하다는 점이었다.

특히 Scanner처럼 작은 객체 하나도 어디서 생성하는지가 설계 차이를 만든다는 걸 알게 됐다.

처음에는 CommerceSystem 안에서 직접 new Scanner(System.in)을 해도 된다고 생각했지만, 생성자 주입 방식으로 바꾸고 나니 코드의 역할이 더 분명해지고 구조도 더 자연스러워졌다.

한 줄 요약

생성자 주입은 클래스가 필요한 객체를 직접 만들지 않고, 밖에서 전달받아 사용하는 방식이며, 역할 분리와 유지보수 측면에서 더 좋은 설계이다.

스파르타 12일차

Wed, 25 Mar 2026 06:33:10 GMT

Java 계산기 과제에서 제네릭과 Number 이해하기

정수 전용 계산기에서 실수까지 처리하도록 확장해보기

계산기 과제를 진행하면서 처음에는 int만 사용하는 계산기를 만들었다. 즉, 정수끼리만 계산할 수 있는 구조였다.

예를 들어 이런 입력은 가능했다.

1 + 2
10 - 3
5 * 4

하지만 이런 입력은 처리할 수 없었다.

1.5 + 2.3
5 / 2 = 2.5

즉, 기존 계산기는 정수 전용 계산기였다.

그런데 과제를 진행하면서 실수도 받을 수 있게 확장하라, 그리고 제네릭을 활용하라는 요구사항이 나왔다.

처음에는 “그냥 int를 double로 바꾸면 되는 거 아닌가?” 라고 생각했지만, 과제의 핵심은 단순히 실수 계산이 아니라 여러 숫자 타입을 더 유연하게 받을 수 있는 구조를 이해하는 것이었다.

이번 글에서는 계산기 과제를 통해 배운 제네릭과 Number의 역할, 그리고 왜 doubleValue()를 사용했는지를 정리해보려고 한다.

1. 처음 계산기는 왜 한계가 있었을까?

기존 계산 메서드는 이런 느낌이었다.

public int calculate(int a, int b, OperatorType operatorType) {
    int result = 0;

    if (operatorType == OperatorType.ADD) {
        result = a + b;
    } else if (operatorType == OperatorType.SUBTRACT) {
        result = a - b;
    } else if (operatorType == OperatorType.MULTIPLY) {
        result = a * b;
    } else if (operatorType == OperatorType.DIVIDE) {
        result = a / b;
    }

    return result;
}

이 구조의 문제는 명확했다.

a, b가 int라서 정수만 받을 수 있다
나눗셈 결과도 정수로 잘릴 수 있다
실수 입력인 1.2, 2.5를 받을 수 없다

예를 들어:

5 / 2

를 계산하면 수학적으로는 2.5여야 하지만, 정수 계산에서는 2가 나와버린다.

즉, 정수 타입에 너무 묶여 있는 구조였다.

2. 그럼 그냥 double로 바꾸면 되지 않을까?

처음에는 이런 생각을 했다.

public double calculate(double a, double b, OperatorType operatorType)

이렇게 바꾸면 정수도 받을 수 있고, 실수도 받을 수 있다.

실제로 이 방식도 동작은 한다. 하지만 과제에서는 여기서 한 걸음 더 나아가 제네릭을 사용해서 여러 숫자 타입을 받을 수 있는 구조를 이해하는 것이 중요했다.

즉 핵심은

단순히 double 계산기를 만드는 것이 아니라, 숫자 타입에 유연한 계산기 구조를 만드는 것

이었다.

3. 제네릭(Generic)이란?

제네릭은 쉽게 말하면

타입을 나중에 정하는 문법

이다.

예를 들어 아래 코드를 보자.

public class Box {
    private T item;
}

여기서 T는 아직 정해지지 않은 타입이다.

나중에 사용할 때

Box
Box

처럼 실제 타입을 넣어서 사용할 수 있다.

즉 T는 일종의 임시 타입 이름이다.

4. 계산기에서 왜 제네릭이 필요했을까?

계산기의 입력값은 이제

정수일 수도 있고
실수일 수도 있다

즉 어떤 때는 Integer, 어떤 때는 Double이 들어올 수 있다.

그런데 이런 서로 다른 숫자 타입을 하나의 계산기 메서드가 받을 수 있으면 좋겠다고 생각했다.

그래서 계산기 클래스를 이렇게 바꿨다.

public class ArithmeticCalculator {
}

5. `T extends Number`는 무슨 뜻일까?

이 문장은 처음 보면 조금 어렵게 느껴진다.

public class ArithmeticCalculator

하지만 뜻은 생각보다 단순하다.

T = 나중에 정해질 타입
extends Number = 그런데 아무 타입이나 안 되고, 숫자 타입만 허용

즉 이 계산기는

Integer
Double
Long
Float

같은 숫자 타입만 받을 수 있다는 의미다.

반대로 이런 건 받을 수 없다.

String
Student

즉 이 코드는 한 줄로 이렇게 해석할 수 있다.

숫자 타입만 받을 수 있는 계산기 클래스를 만들겠다

6. Number는 무엇인가?

Number는 자바에서 숫자 타입들의 부모 클래스 같은 존재다.

대표적으로 이런 클래스들이 Number 계열이다.

Integer
Double
Long
Float

즉 Number는 “숫자 타입들의 공통 부모” 라고 이해하면 편하다.

그래서 T extends Number라고 쓰면, 정수도 가능하고 실수도 가능한 구조를 만들 수 있다.

7. 실제 계산기 코드는 어떻게 바뀌었을까?

기존 Calculator 클래스를 ArithmeticCalculator로 바꾸고, calculate 메서드를 이렇게 수정했다.

import java.util.ArrayList;
import java.util.List;

public class ArithmeticCalculator {

    private List results = new ArrayList<>();

    public double calculate(T num1, T num2, OperatorType operatorType) {

        double num1Double = num1.doubleValue();
        double num2Double = num2.doubleValue();

        double result = 0;

        if (operatorType == OperatorType.ADD) {
            result = num1Double + num2Double;
        } else if (operatorType == OperatorType.SUBTRACT) {
            result = num1Double - num2Double;
        } else if (operatorType == OperatorType.MULTIPLY) {
            result = num1Double * num2Double;
        } else if (operatorType == OperatorType.DIVIDE) {
            result = num1Double / num2Double;
        }

        results.add(result);
        return result;
    }
}

8. 여기서 왜 `doubleValue()`를 썼을까?

이 부분이 가장 중요했다.

double num1Double = num1.doubleValue();
double num2Double = num2.doubleValue();

num1, num2는 T extends Number이기 때문에 실제로는 Integer일 수도 있고 Double일 수도 있다.

예를 들면:

num1 = Integer 3
num2 = Double 2.5

이런 식이다.

그런데 계산을 하려면 타입을 하나로 통일하는 게 편하다. 그래서 계산 전에 모두 double로 바꾼 것이다.

Number 계열은 공통적으로 doubleValue() 메서드를 가지고 있기 때문에, 어떤 숫자 타입이 들어와도 double로 바꿀 수 있다.

예를 들어:

Integer a = 3;
Double b = 2.5;

System.out.println(a.doubleValue()); // 3.0
System.out.println(b.doubleValue()); // 2.5

즉 doubleValue()는

어떤 숫자 타입이 오든 계산하기 편한 double로 통일하는 역할

을 한다고 이해하면 된다.

9. 왜 결과는 `List`가 아니라 `List`로 저장했을까?

처음에는 나도 이런 생각을 했다.

입력 타입이 T니까 결과도 List로 저장하면 되는 거 아닌가?

그런데 곰곰이 생각해보면 문제가 있다.

예를 들어 계산기가 Integer를 받는다고 해도 나눗셈 결과는 실수가 될 수 있다.

5 / 2 = 2.5

즉 입력 타입이 Integer라고 해서 결과도 항상 Integer가 되는 건 아니다.

그래서 결과 저장은 아예

private List results = new ArrayList<>();

이렇게 Double 타입으로 통일했다.

이렇게 하면

정수 결과도 저장 가능 (3 → 3.0)
실수 결과도 저장 가능 (2.5 → 2.5)

즉 결과를 더 유연하게 저장할 수 있다.

10. App에서는 어떻게 입력을 처리했을까?

입력값은 더 이상 nextInt()로 바로 받을 수 없었다. 왜냐하면 1.2 같은 실수 입력도 받아야 하기 때문이다.

그래서 입력은 먼저 문자열로 받고, 그 문자열이 정수인지 실수인지 판단해서 숫자로 바꾸는 방식을 사용했다.

System.out.print("첫 번째 숫자를 입력하세요: ");
String input1 = scanner.next();

System.out.print("두 번째 숫자를 입력하세요: ");
String input2 = scanner.next();

Number num1 = parseNumber(input1);
Number num2 = parseNumber(input2);

그리고 parseNumber() 메서드는 이렇게 만들었다.

private static Number parseNumber(String number) {
    if (number.contains(".")) {
        return Double.parseDouble(number);
    } else {
        return Integer.parseInt(number);
    }
}

즉

"3" 입력 → Integer
"1.5" 입력 → Double

로 처리하도록 만든 것이다.

이렇게 하면 App 입장에서는 정수와 실수를 구분해서 적절한 숫자 타입으로 바꾸고, 계산기에는 Number로 넘겨줄 수 있게 된다.

11. 정리하면 이번 과제에서 배운 핵심은?

이번 제네릭 과제를 하면서 정리된 핵심은 이렇다.

1) 제네릭은 타입을 유연하게 만든다

ArithmeticCalculator

이렇게 하면 정수와 실수 같은 여러 숫자 타입을 받을 수 있다.

2) `Number`는 숫자 타입들의 공통 부모다

Integer, Double 같은 숫자 타입을 하나의 공통 타입으로 다룰 수 있게 해준다.

3) `doubleValue()`는 계산 전에 타입을 통일하는 역할을 한다

정수든 실수든 상관없이 double로 바꿔 계산하면 훨씬 편하다.

4) 결과는 `Double`로 저장하는 것이 자연스럽다

입력은 정수일 수도 있지만, 결과는 실수가 될 수 있기 때문이다.

12. 느낀 점

처음에는 T extends Number가 굉장히 추상적으로 느껴졌다. 하지만 계산기처럼 “정수도 받고 실수도 받고 싶다”는 상황에 적용해보니, 왜 이런 문법이 필요한지 조금 이해가 됐다.

이번 과제를 통해 느낀 건,

제네릭은 단순히 어려운 문법이 아니라, 타입을 더 유연하고 재사용 가능하게 만드는 도구라는 점이었다.

그리고 Number와 doubleValue()를 함께 사용하면 정수와 실수를 하나의 계산 흐름 안에서 자연스럽게 다룰 수 있다는 것도 알게 되었다.

마무리

이번 계산기 과제에서 제네릭과 Number를 적용해보면서 기존의 정수 전용 계산기를 정수와 실수 모두 처리 가능한 계산기로 확장할 수 있었다.

한 줄로 정리하면:

T extends Number는 숫자 타입만 받게 제한하는 것이고, doubleValue()는 그 숫자들을 계산하기 쉬운 형태로 통일하는 역할을 한다.

처음에는 조금 어렵게 느껴졌지만, 직접 계산기에 붙여보면서 제네릭이 “왜 필요한지”를 조금은 이해할 수 있었던 시간이었다.

스파르타 11일차

Tue, 24 Mar 2026 08:22:52 GMT

Java 계산기 과제에서 Enum 이해하기

`char` 대신 왜 `enum`을 쓰는지 처음부터 정리

계산기 과제를 진행하면서 STEP 3에서 enum을 활용하라는 요구사항을 만났다. 처음에는 솔직히 이렇게 생각했다.

+, -, *, /는 그냥 문자니까 char로 하면 되는 거 아닌가?

실제로 STEP 1, STEP 2까지는 char 타입으로도 계산기를 충분히 만들 수 있었다. 하지만 STEP 3에서는 단순히 “동작하는 계산기”를 넘어서, 연산자 타입을 더 명확하고 안전하게 관리하는 방식으로 코드를 개선하는 것이 핵심이었다.

이번 글에서는 내가 계산기 과제를 하면서 이해한 enum이 무엇인지, 왜 계산기에서 enum을 쓰는지, 기존 코드에 어떻게 연결했는지를 정리해보려고 한다.

1. enum이란 무엇인가?

enum은 정해진 값들만 가질 수 있도록 만든 특별한 타입이다.

예를 들어 이런 것들이 있다.

요일: 월, 화, 수, 목, 금, 토, 일
계절: 봄, 여름, 가을, 겨울
상태: 대기중, 진행중, 완료
연산자: 더하기, 빼기, 곱하기, 나누기

이런 값들은 공통점이 있다.

값의 종류가 미리 정해져 있다.

자바에서는 이렇게 정해진 종류만 있는 값들을 표현할 때 enum을 사용한다.

예를 들어 계산기의 연산자를 enum으로 만들면 이렇게 표현할 수 있다.

public enum OperatorType {
    ADD,
    SUBTRACT,
    MULTIPLY,
    DIVIDE
}

이제 OperatorType은 새로운 타입이 되고, 이 타입은 오직 아래 네 값만 가질 수 있다.

OperatorType.ADD
OperatorType.SUBTRACT
OperatorType.MULTIPLY
OperatorType.DIVIDE

즉, enum의 핵심은

아무 값이나 들어오지 못하게 하고, 정해진 값만 다루게 만드는 것

이라고 이해하면 된다.

2. 기존 계산기에서는 왜 `char`를 썼을까?

처음 만들었던 계산기에서는 사용자가 사칙연산 기호를 직접 입력했다.

예를 들면 이런 식이다.

char operator = scanner.next().charAt(0);

그리고 계산할 때는 이렇게 비교했다.

if (operator == '+') {
    result = a + b;
} else if (operator == '-') {
    result = a - b;
} else if (operator == '*') {
    result = a * b;
} else if (operator == '/') {
    result = a / b;
}

이 방식은 동작은 잘 한다. 하지만 문제는 char 타입은 연산자만 넣는 타입이 아니라는 점이다.

즉 아래 같은 값도 모두 들어갈 수 있다.

'a'
'?'
'1'

즉 char는 그저 “문자 한 글자”를 저장하는 타입일 뿐이고, “연산자 전용 타입”은 아니다.

여기서 enum을 쓰는 이유가 생긴다.

3. 계산기에서 enum을 쓰는 이유

계산기에서는 사실 연산자의 종류가 딱 4개로 정해져 있다.

더하기
빼기
곱하기
나누기

즉 아무 문자나 들어오는 게 아니라 정해진 연산자만 관리하고 싶다는 요구가 있다.

이럴 때 enum을 사용하면 코드가 훨씬 명확해진다.

기존 방식

char operator = '+';

enum 방식

OperatorType operatorType = OperatorType.ADD;

둘 다 결국 더하기를 의미하지만, OperatorType.ADD 쪽이 훨씬 의미가 분명하다.

'+'는 그냥 문자 하나처럼 보이지만, ADD는 누가 봐도 “더하기 연산자”라는 걸 알 수 있다.

즉 enum을 쓰면

의미가 더 명확해지고
잘못된 값을 관리하기 쉬워지고
연산자의 종류를 타입 차원에서 제한할 수 있다

는 장점이 있다.

4. 계산기에 enum을 어떻게 붙였는가?

사용자는 여전히 +, -, *, /를 입력한다. 하지만 프로그램 내부에서는 이 문자를 바로 계산에 쓰지 않고, 먼저 enum 값으로 바꾸도록 했다.

즉 흐름은 이렇게 바뀐다.

예전 방식

'+' -> 바로 Calculator에 전달

enum 적용 후 방식

'+' -> OperatorType.ADD 로 변환 -> Calculator에 전달

즉 사용자 입력은 여전히 문자지만, 프로그램 내부 계산 로직은 enum 기반으로 동작하게 바꾼 것이다.

5. OperatorType enum 만들기

먼저 연산자의 종류를 enum으로 정의했다.

package com.example.calculator;

public enum OperatorType {
    ADD,
    SUBTRACT,
    MULTIPLY,
    DIVIDE
}

이제 OperatorType은 계산기에서 사용하는 연산자 타입이 되었다.

6. 문자 입력을 enum으로 바꾸는 메서드 추가

문제는 사용자가 입력하는 값은 +, -, *, / 같은 문자라는 점이다. 그래서 이 문자를 enum 값으로 변환해주는 메서드가 필요했다.

package com.example.calculator;

public enum OperatorType {
    ADD,
    SUBTRACT,
    MULTIPLY,
    DIVIDE;

    public static OperatorType fromChar(char operator) {
        if (operator == '+') {
            return ADD;
        } else if (operator == '-') {
            return SUBTRACT;
        } else if (operator == '*') {
            return MULTIPLY;
        } else if (operator == '/') {
            return DIVIDE;
        } else {
            throw new IllegalArgumentException("잘못된 연산자입니다.");
        }
    }
}

이 메서드는 말 그대로 문자(char)를 받아서 OperatorType으로 바꾸는 역할을 한다.

예를 들어:

OperatorType type = OperatorType.fromChar('+');

이렇게 하면 결과는:

OperatorType.ADD

가 된다.

즉, 사용자 입력을 프로그램 내부에서 안전하게 사용할 수 있는 enum 값으로 바꾸는 과정이라고 보면 된다.

7. 기존 Calculator 클래스 수정하기

원래 Calculator 클래스는 char를 매개변수로 받았었다.

기존 코드

public int calculate(int a, int b, char operator) {
    int result = 0;

    if (operator == '+') {
        result = a + b;
    } else if (operator == '-') {
        result = a - b;
    } else if (operator == '*') {
        result = a * b;
    } else if (operator == '/') {
        result = a / b;
    }

    results.add(result);
    return result;
}

이제는 char 대신 OperatorType을 받도록 바꾸었다.

수정 후 코드

public int calculate(int a, int b, OperatorType operatorType) {
    int result = 0;

    if (operatorType == OperatorType.ADD) {
        result = a + b;
    } else if (operatorType == OperatorType.SUBTRACT) {
        result = a - b;
    } else if (operatorType == OperatorType.MULTIPLY) {
        result = a * b;
    } else if (operatorType == OperatorType.DIVIDE) {
        result = a / b;
    }

    results.add(result);
    return result;
}

여기서 핵심 변화는 두 가지였다.

매개변수가 char에서 OperatorType으로 바뀜
비교 대상이 '+' 같은 문자에서 OperatorType.ADD 같은 enum 값으로 바뀜

이렇게 바꾸니 계산 로직이 훨씬 의미 중심으로 읽히기 시작했다.

8. App 클래스에서는 어떻게 연결했는가?

사용자 입력은 그대로 문자로 받았다.

char operator![](https://velog.velcdn.com/images/loaded_diaper/post/3c15d636-f7a5-4d3c-af62-619e293eb424/image.png)
![](https://velog.velcdn.com/images/loaded_diaper/post/2b29aaa4-8fab-4ea9-9c49-699f0e312eb9/image.png)
![](https://velog.velcdn.com/images/loaded_diaper/post/f04d90c3-ea63-4161-88c9-4f473e001d2c/image.png)
 = scanner.next().charAt(0);

그다음 바로 Calculator에 넘기는 대신, 먼저 enum으로 바꿨다.

OperatorType operatorType = OperatorType.fromChar(c);

그리고 이 enum 값을 Calculator에 전달했다.

int result = calculator.calculate(a, b, operatorType);

즉 App 클래스의 역할은

입력 받기
입력받은 문자를 enum으로 변환하기
Calculator에 넘기기

가 되었다.

9. enum을 적용하면서 느낀 점

처음에는 솔직히 “문자 하나 받아서 if문으로 계산하면 되는데 굳이 enum까지 써야 하나?” 라는 생각이 들었다.

하지만 직접 적용해보니 enum의 장점이 조금씩 보이기 시작했다.

1) 코드 의미가 더 분명해진다

'+'보다는 OperatorType.ADD가 훨씬 읽기 쉽다.

2) 정해진 값만 다룬다는 것이 코드에서 드러난다

연산자는 아무 문자나 들어오는 값이 아니라, 정해진 4가지 중 하나라는 사실이 코드 구조에 반영된다.

3) 나중에 확장하기 좋다

지금은 단순히 연산 종류만 관리하지만, 나중에는 각 enum에 기호, 설명, 계산 로직까지 붙일 수도 있다.

즉 enum은 단순히 “문법 하나 더 배운 것”이 아니라 정해진 종류를 더 안전하게 표현하는 방식이라는 걸 느꼈다.

10. 정리

이번 계산기 과제에서 enum을 적용하면서 가장 중요하게 느낀 점은 다음과 같다.

enum은 정해진 값들만 가지는 타입이다.
계산기의 연산자처럼 종류가 미리 정해져 있는 값에 잘 어울린다.
기존에는 char로 직접 비교했지만,
enum을 사용하면 의미가 더 분명하고 안전한 코드가 된다.
사용자 입력은 문자로 받더라도, 프로그램 내부에서는 enum으로 변환해서 처리할 수 있다.

한 줄로 정리하면:

계산기에서 enum을 사용한다는 것은 연산자를 단순한 문자로 다루는 것이 아니라, 정해진 연산 타입으로 명확하게 관리하겠다는 의미였다.

마무리

처음에는 enum이 조금 추상적으로 느껴졌지만, 계산기처럼 연산자 종류가 명확한 예제에 직접 붙여보니 왜 필요한지 이해가 됐다.

이번 과제를 통해 단순히 “계산이 되게 만드는 것”에서 한 걸음 더 나아가, 코드를 더 명확하고 구조적으로 표현하는 방법을 조금씩 배우고 있다는 느낌이 들었다.

다음에는 enum뿐만 아니라 제네릭, 람다, 스트림도 계산기 과제에 어떻게 연결되는지 차근차근 정리해보고 싶다.