khu2172 님의 블로그

CORS란? (Cross-Origin Resource Sharing)

khu2172 — Thu, 7 Aug 2025 17:59:08 +0900

CORS란?

CORS(Cross-Origin Resource Sharing)는
서로 다른 Origin 간의 리소스 공유를 허용하는 표준 보안 우회 기술이다.

기본적으로 웹 브라우저는 보안상의 이유로 다른 출처(origin)의 리소스 요청을 차단한다.

CORS는 이러한 제약을 우회하여 다른 출처의 리소스에 접근할 수 있게 해준다.

Same-Origin Policy(SOP)란?

브라우저가 기본적으로 따르는 보안 정책이다.
→ 동일한 출처(origin)에서만 리소스를 공유할 수 있도록 제한한다.

Origin이란?

Origin은 다음 세 가지의 조합으로 구성된다:

프로토콜: http, https
호스트: localhost, naver.com 등
포트 번호: 80, 8080, 3000 등

이 중 하나라도 다르면 다른 Origin으로 판단되어 SOP에 의해 차단된다.

Preflight Request(프리플라잇 요청)

CORS 요청 중에서도 GET, POST 외의 HTTP 메서드(PUT, DELETE 등)를 사용하거나,
커스텀 헤더가 포함된 요청의 경우 브라우저는 본 요청을 보내기 전에 사전 확인용 요청(OPTIONS)을 보낸다. 이를 Preflight 요청이라고 한다.

동작 흐름:

브라우저가 서버에 OPTIONS 메서드로 사전 요청 전송
서버가 해당 요청을 허용하면, 브라우저가 본 요청을 실제로 보냄
허용되지 않으면 브라우저가 요청을 차단

CORS 에러 해결 경험 (Spring Boot 프로젝트)

실제 프로젝트 개발 중, 프론트엔드(React)와 백엔드(Spring Boot)가
서로 다른 포트에서 실행되며 CORS 에러가 발생한 경험이 있다.

이 문제를 해결하기 위해,

Spring의 설정 클래스를 만들고,
특정 Origin을 허용하도록 설정한 뒤,
프리플라잇 요청이 정상적으로 응답되도록 처리하였다.

이후 브라우저에서 더 이상 차단되지 않고 정상적인 API 요청이 가능해졌다.

요약

항목	설명
CORS	다른 출처 간 리소스 공유를 허용하는 웹 표준
SOP	브라우저의 동일 출처 보안 정책
Origin	Protocol + Host + Port 조합
Preflight	본 요청 전 OPTIONS 요청을 통해 허용 여부 확인
해결 경험	백엔드에서 특정 Origin을 허용해 브라우저 차단을 해소함

마무리

CORS는 단순한 에러처럼 보일 수 있지만,
웹 보안을 위한 핵심 메커니즘이며, 프론트와 백엔드가 분리된 환경에선
반드시 이해하고 설정할 수 있어야 하는 개념이다.

JWT와 OAuth의 차이점 정리

khu2172 — Tue, 29 Jul 2025 00:54:34 +0900

1. JWT (JSON Web Token)

JWT는 토큰의 한 종류로, 인증 및 권한 부여 정보를 담는 데 사용된다.
토큰 자체에 명확한 정보(사용자 ID, 권한, 만료 시간 등)가 들어 있다.
별도의 저장소에 토큰의 상태를 저장하지 않고 토큰만으로 정보를 검증한다.
구성: Header.Payload.Signature 형식으로 구성되며 Base64Url로 인코딩된 정보를 담는다.

특징

자체 완결성(Self-contained): 토큰만으로도 사용자의 인증 및 권한 정보를 확인할 수 있다.
상태 비저장(Stateless): 서버가 상태 정보를 저장할 필요가 없어 확장성이 뛰어나다.

2. OAuth (Open Authorization)

OAuth는 토큰이 아니라, 토큰을 얻기 위한인증 및 권한 부여 절차를 정의한 프레임워크이다.
애플리케이션이 사용자를 대신하여 보호된 리소스에 접근할 수 있도록 권한을 위임하는 표준 프로토콜이다.
OAuth 프레임워크를 통해 발급된 OAuth Bearer Token은 랜덤한 문자열로 구성되어 있다.
토큰 자체에는 사용자의 민감한 정보가 직접 포함되지 않고, 토큰을 통해 리소스 서버에서 정보를 조회한다.

특징

권한 위임: 사용자의 자격 증명(비밀번호)을 공유하지 않고도 애플리케이션이 제한된 권한으로 사용자의 데이터에 접근할 수 있다.
다양한 시나리오 지원: 권한 부여 유형(Authorization Code, Implicit, Password, Client Credentials 등)을 통해 다양한 사용 사례를 지원한다.

비교표

	JWT	OAuth
종류	토큰(token)	프레임워크(framework)
정보 포함	명확한 정보 포함	랜덤한 문자열 (정보 미포함)
상태 관리	상태 비저장(Stateless)	토큰 상태 관리 가능
목적	인증 및 권한 정보 전달	애플리케이션의 권한 위임
사용 예시	로그인 세션 관리, API 접근	SNS 연동 로그인, 써드파티 앱 접근

결론

JWT는 명확한 사용자 정보를 담아 인증과 권한 관리를 위한 토큰 형식이다.
OAuth는 외부 애플리케이션에 권한을 위임하는 프로세스를 표준화한 프레임워크로, OAuth가 발급하는 토큰 자체는 정보를 담지 않은 랜덤 값이다.

이러한 특성을 잘 이해하면 보다 안전하고 효율적인 인증 및 인가 시스템을 설계할 수 있다.

[트러블슈팅] PasswordEncoder 등 빈 주입 오류, 컴포넌트 스캔 누락

khu2172 — Wed, 23 Jul 2025 00:54:30 +0900

문제 상황

Parameter 1 of constructor ... required a bean of type 'PasswordEncoder' that could not be found
(서비스 생성자 파라미터에서 주입 오류 발생)
AppConfig에서 @Bean으로 PasswordEncoder를 정상 등록했음에도
Could not autowire. No beans of 'PasswordEncoder' type found.
라는 에러가 계속 발생

원인 분석

AppConfig(설정 클래스)를
com.example.config(=최상위) 패키지에 두었으나,
메인 클래스(@SpringBootApplication)가 com.example.board 하위에 위치
→ Spring Boot의 기본 컴포넌트 스캔 정책상
메인 클래스 “하위” 패키지만 스캔
→ 최상위 config 패키지가 스캔 대상에서 누락됨
이로 인해 PasswordEncoder 빈(@Bean)이 등록되지 않아
서비스에서 주입 오류 발생

해결 방법

메인 클래스를 “최상위 패키지(com.example)”로 이동
- BoardApplication을 com.example에 두면
  그 하위 전체(=config, board, user ...)가 스캔됨
- 모든 빈(@Bean, @Service, @Mapper 등)이 자동 등록
또는,
AppConfig를 메인 클래스 하위 패키지(com.example.board.config)로 옮기기
- 하위에 두면 무조건 스캔됨
대안:
- @ComponentScan(basePackages = "com.example")로 스캔 범위 명시적으로 확장
- (실무에서는 메인 클래스를 상위로 두는 게 더 보편적)

결과 및 교훈

메인 클래스를 “최상위 패키지”에 두었더니
PasswordEncoder 등 모든 빈 주입 문제가 바로 해결!
Spring Boot의 컴포넌트 스캔 기본 정책은
“메인 클래스와 그 하위 패키지”만 스캔
→ 최상위 config, 공통 유틸 등은 항상 “메인 클래스보다 하위/동일 위치”에 둘 것
또는, 스캔 범위를 명시적으로 확장할 것

마무리

빈 주입 오류, 컴포넌트 스캔 범위 체크가 최우선!
스프링 구조 설계 시 “메인 클래스, 설정 클래스의 위치”에 항상 주의하자!

IoC와 IoC 컨테이너란?(스프링에서의 역할 정리)

khu2172 — Mon, 14 Jul 2025 23:59:46 +0900

1. IoC(Inversion of Control)란?

IoC(제어의 역전)는 객체의 생성과 생명주기 관리, 의존성 주입 등 프로그램의 제어권을 개발자가 아닌 외부(주로 프레임워크나 컨테이너)에 맡기는 설계 원칙입니다.
이 덕분에 개발자는 객체 관리에서 벗어나 비즈니스 로직 구현에 집중할 수 있게 됩니다.

2. IoC 컨테이너란?

IoC 컨테이너는 IoC 원칙을 실제로 구현하는 객체 관리자입니다.
스프링 프레임워크에서는 IoC 컨테이너가 애플리케이션을 구성하는 Bean(객체)들을 생성하고, 서로 연결하며, 필요할 때 소멸까지 관리합니다.
대표적으로 ApplicationContext, BeanFactory가 있습니다.

3. 스프링 IoC 컨테이너의 주요 역할

객체(Bean) 생성
개발자가 직접 new로 객체를 만들지 않고, 컨테이너가 빈 설정에 따라 객체를 생성합니다.
객체의 생명주기 관리
객체의 생성부터 소멸까지 전체 라이프사이클을 책임집니다.
의존관계 주입(Dependency Injection, DI)
객체가 필요로 하는 다른 객체를 자동으로 연결해줍니다.
덕분에 객체 간 결합도가 낮아지고 코드가 더 유연해집니다.
설정 및 환경 관리
빈의 프로퍼티, 환경 설정, 프로파일 등 각종 설정값을 관리합니다.
AOP 등 부가기능 적용
트랜잭션 처리, AOP(관점 지향 프로그래밍) 같은 기능도 IoC 컨테이너가 객체에 자동으로 적용해줄 수 있습니다.

4. IoC 컨테이너의 장점

코드 결합도 감소 및 유연성 향상
테스트 용이성 증가
확장성 및 유지보수성 개선
중복 코드 감소

5. 결론

정리하자면,
스프링 IoC 컨테이너는 객체의 생성, 관리, 의존성 주입, 설정, 생명주기 관리 등 애플리케이션에서 필요한 핵심 작업을 자동으로 처리해주는 관리자입니다.
이 덕분에 개발자는 비즈니스 로직 구현에 집중할 수 있고, 코드의 확장성과 유지보수성이 크게 향상됩니다.

[트러블슈팅] Spring 단위 테스트 실패

khu2172 — Thu, 10 Jul 2025 15:06:06 +0900

1. 문제 상황

회원(유저) 서비스의 단위 테스트 코드가
NullPointerException이나
IllegalStateException("id를 찾지 못함") 등
각종 에러로 실패.
테스트 흐름:
회원가입 → 전체 유저 목록에서 id 찾기 → 단건 조회/삭제 검증

2. 증상/에러 메시지

가입 후 전체 유저: 0
찾은 id: null
id를 찾지 못함 예외
NullPointerException: ... because "user" is null

3. 원인 분석

Mock 환경에선 실제 DB 저장/조회가 발생하지 않음.
→ 단순히 메소드 호출만 검증하는 구조라
가짜 데이터의 반환값을 직접 세팅하지 않으면
항상 빈 값(0개)만 반환.
테스트 코드에서 반환값 세팅을 생략해서,
전체 유저 목록이 항상 0명 → id 찾지 못함.
엔터티 클래스에 테스트용 생성자(id 포함) 누락
→ 원하는 테스트 데이터를 만들지 못함.

4. 해결 방법

Mock 객체의 리턴값을 명확히 지정
(테스트용 데이터는 직접 만들어서 사용)
엔터티/DTO 클래스에 id까지 포함한 생성자를 추가
테스트 흐름/방식(단위테스트 vs 통합테스트) 구분 명확히 하기

5. 배운 점

Mock 기반 단위 테스트에선 실제 DB와는 다르게 동작한다는 사실을 인지해야 함
모든 테스트 데이터는 직접 세팅해줘야 한다
에러 로그, println 등으로 중간값을 찍으며 원인 추적하는 과정이 중요
테스트 목적(단위/통합)에 따라 테스트 방식/코드 작성법이 달라진다

[트러블슈팅] 윈도우 한글 경로(ClassNotFoundException)로 인한 자바/테스트 에러

khu2172 — Tue, 8 Jul 2025 23:29:47 +0900

문제 현상

메인 메소드 실행은 정상
JUnit 테스트, Gradle 빌드, 외부 명령 실행 등에서 아래와 같은 에러 발생

오류: 기본 클래스 worker.org.gradle.process.internal.worker

.GradleWorkerMain을(를) 찾거나 로드할 수 없습니다.

원인: java.lang.ClassNotFoundException: worker.org.gradle

.process.internal.worker.GradleWorkerMain

추가로, JAVA_HOME/PATH 에러, 파이프 닫힘 등 부가적 메시지 반복 발생

원인 파악을 위한 시도들

JDK/Gradle 재설치
- JDK, Gradle 최신 버전으로 재설치
- 환경변수 JAVA_HOME, Path 재설정
- → 여전히 동일 에러 발생
인텔리제이 캐시/빌드 캐시 무효화
- File > Invalidate Caches, .gradle/.idea 폴더 삭제 등 시도
- → 에러 해결 안 됨
프로젝트 경로/환경변수 점검
- JDK/Gradle 경로가 정상인지 확인
- CMD에서 java -version, gradle -v 등 실행
- → 콘솔에서는 정상, 테스트에서는 에러 반복

결국 원인은 ‘한글 계정(경로)’

윈도우 사용자 폴더(C:\Users\한글계정명) 등
계정명에 한글이 포함된 상태에서 JDK/Gradle 등 개발 도구가 경로를 제대로 인식하지 못함
IDE(인텔리제이)에서 메인 메소드는 잘 동작해도
JUnit/Gradle 등은 OS의 환경변수 및 경로 인코딩에 더 민감해서 문제 발생

최종 해결법: 영문 계정으로 마이그레이션

영문명 새 계정 생성, 관리자 권한 부여
필요한 프로젝트/자료만 새 계정으로 복사
인텔리제이, JDK, Gradle 등 개발 툴 새로 설치
JAVA_HOME, Path 등 환경변수 “영문 경로”로 다시 세팅
테스트/Gradle 빌드/외부 도구 등 모든 기능 정상 동작 확인

교훈

윈도우 환경에서 개발하려면
‘영문 계정/영문 경로’는 선택이 아니라 필수!
여러 환경설정/재설치만으로는
‘한글 경로’ 문제를 완전히 해결할 수 없음
트러블슈팅 과정 자체도 큰 경험!
(이후 환경이 꼬였을 때 빠른 원인 파악 가능)

요약

에러 메시지
- ClassNotFoundException: worker.org.gradle.process.internal.worker.GradleWorkerMain
해결 위해 시도한 것들
- JDK/Gradle 재설치, 환경변수 재설정, 캐시 삭제 등
결국 한글 경로(계정) 때문이었음
- 영문 계정으로 마이그레이션 후 완전 해결!

JWT(Json Web Token)란?

khu2172 — Sat, 5 Jul 2025 23:59:11 +0900

JWT는 Json Web Token의 약자로, 웹 또는 모바일 환경에서 사용자 인증(Authentication)을 위해 사용되는 토큰 기반 인증 방식이다.
로그인 후 서버가 발급한 토큰을 클라이언트가 저장하고, 이후 요청마다 해당 토큰을 함께 전송함으로써 사용자를 식별하고 권한을 확인한다.

JWT의 구조

JWT는 총 3개의 구성 요소로 이루어져 있으며, 각각 Base64Url 방식으로 인코딩되어

'.(dot)'으로 연결된다:

Header
- 토큰의 타입(JWT)과 해싱 알고리즘(예: HS256) 정보가 담긴다.
Payload
- 실제 토큰에 담고 싶은 사용자 정보가 포함된다.
- 이 안의 정보를 Claim(클레임)이라 부른다.
Signature
- Header와 Payload를 조합한 후, 서버의 비밀 키(SECRET_KEY)를 사용해 서명한 값이다.
- 토큰이 위변조되지 않았는지 검증하는 역할을 한다.

Claim(클레임)이란?

Claim은 Payload 안에 담기는 정보 조각이며, key-value 쌍으로 구성된다.
Claim의 종류는 다음과 같다:

등록된(Registered) Claim
- iss(발급자), exp(만료시간), sub(주제) 등 표준으로 정의된 클레임
공개(Public) Claim
- 충돌을 방지하기 위해 공개적으로 정의되거나 URI로 명시된 클레임
비공개(Private) Claim
- 발급자와 사용자 간 약속된 커스텀 정보 (예: userId, role 등)

Signature(서명)의 역할

Signature는 토큰의 위조를 방지하기 위한 검증 수단이다.
Header와 Payload가 조작되면 서명이 유효하지 않게 되며, 서버는 이를 통해 신뢰 여부를 판별한다.

JWT의 특징

Stateless
서버가 사용자 정보를 별도로 저장하지 않아도 됨
Self-contained
사용자 정보를 토큰 안에 자체적으로 포함하고 있음
URL-safe
Base64Url 인코딩 덕분에 URL 파라미터나 HTTP 헤더에 안전하게 사용 가능
Authorization 헤더 사용
보통 Authorization: Bearer <토큰> 형태로 전송됨

주의사항

Payload는 암호화되지 않으며, 누구나 열람할 수 있으므로 민감한 정보는 절대 포함하지 말아야 한다.
반드시 만료 시간(exp)을 설정해 토큰 탈취와 재사용을 방지해야 한다.
서명(Signature)이 유효하더라도, 정보 자체가 노출된다는 점을 인지해야 한다.

JWT는 인증 시스템을 간결하고 확장성 있게 만들어주는 강력한 도구이지만, 보안 설계에 대한 충분한 이해와 주의가 필요하다.
올바르게 사용한다면 세션 방식보다 더 효율적인 인증 체계를 구축할 수 있다.

[트러블슈팅] MyBatis 매퍼(static context 에러) — 객체 주입과 메서드 호출 실수

khu2172 — Fri, 4 Jul 2025 18:32:35 +0900

문제 상황

MyBatis/Spring 프로젝트에서
매퍼 메서드를 “클래스명.메서드()”로 호출해서
Non-static method 'findXXX' cannot be referenced from a static context
에러가 발생!

에러 예시

설명:
InquiryMapper는 MyBatis 매퍼 인터페이스(빈)
findInquiryById는 “static 메서드”가 아님(=인스턴스 메서드)
에러:
- Non-static method 'findInquiryById(java.lang.Long)' cannot be referenced from a static context

원인 분석

MyBatis 매퍼는
Spring이 “객체(빈)”로 만들어서 DI(주입) 해줌
InquiryMapper.findInquiryById(id)처럼
“클래스명으로 직접” static 메서드 호출하듯이 쓰면
자바가 “static 메서드가 아닌데 왜 클래스명으로 부르냐?”고 에러!

올바른 사용 방법

매퍼 객체(빈)를 DI(의존성 주입) 받는다
- 보통 final InquiryMapper inquiryMapper;로 선언
- 생성자, @Autowired 등으로 주입
객체(변수)로 메서드를 호출해야 한다

교훈/정리

MyBatis 매퍼 메서드는 static이 아니라 인스턴스 메서드!
항상 “객체(빈)로 주입받아서” 메서드를 호출해야 한다
InquiryMapper.findXXX(id); X (클래스명 호출 = static만 가능)
inquiryMapper.findXXX(id); O (객체로 호출 = 인스턴스 메서드)

한 줄 정리

MyBatis 매퍼는 반드시 ‘주입받은 객체’로 메서드를 호출해야 하며,
클래스명.메서드()는 static에서만 쓸 수 있다!

[트러블슈팅] FK 무결성 오류와 로그인 미구현 상태에서 user_id 입력 문제

khu2172 — Wed, 2 Jul 2025 19:47:16 +0900

문제 상황

Spring Boot + MyBatis + MySQL 환경에서
문의글(inquiry) 생성 시 FK 무결성 오류가 발생했다.
또, 로그인/인증 기능 없이 user_id를 자동 세팅하려다 문제가 생김.

주요 에러/현상

FK 무결성 오류
- Cannot add or update a child row: a foreign key constraint fails ...
- Column 'user_id' cannot be null
로그인 기능 없이 user_id 자동 세팅 시도
- 서버가 로그인된 유저 정보를 알지 못해 user_id 값을 자동으로 넣지 못함

원인 분석

FK 무결성 오류:
inquiry 테이블의 user_id 값과
user 테이블의 id 값이 일치하지 않았음
로그인/인증 미구현:
서버가 "현재 로그인한 유저" 정보를 모름
→ user_id를 클라이언트가 직접 입력해야만 INSERT 가능
→ 자동 세팅 시도 시 null 또는 잘못된 값으로 저장됨

해결 방법

FK 무결성 오류 해결
- inquiry.user_id의 값이 user.id에 실제로 존재하는지 확인
  - 확인 결과, inquiry.user_id의 값과 user.id의 값이 불일치했음
- 로그인 기능 미구현으로 인하여 user_id 값을
  클라이언트가 직접 입력하여INSERT 실행
로그인 기능 없이 user_id 처리
- 클라이언트(포스트맨 등)에서 user_id를 직접 JSON 바디에 입력해서 요청
- 이후 로그인/인증 기능을 개발하면
  user_id를 자동으로 세팅하는 구조로 리팩토링

교훈/체크리스트

FK(외래키) 무결성:
- 참조하는 값(user_id)은 반드시 user 테이블에 실제로 존재해야 함
로그인/인증 없이 user_id 자동 세팅은 불가능:
- 인증 미구현 단계에서는 user_id를 반드시 직접 입력해야 함
- 인증 도입 후에는 서버가 로그인 정보로 user_id를 추출해서 사용

[트러블슈팅] @Controller vs @RestController, 404 에러 & 정상 동작 차이

khu2172 — Sat, 28 Jun 2025 05:56:10 +0900

문제 상황

Spring Boot에서 API를 개발하다가,
DB에는 데이터가 잘 들어가는데, Postman에선 404 Not Found 에러가 발생했다.

원인 분석

InquiryController에 @Controller 애노테이션을 붙이고,
@PostMapping으로 API를 작성했다.
하지만 @RestController가 아닌 @Controller만 쓰면,
기본적으로 “뷰(HTML 화면)”를 반환하려고 동작한다.
API에서 리턴 값이 없거나, JSON/객체/문자열 등
데이터만 내려줄 때는 @RestController를 사용해야 한다!
이걸 놓치면, 요청 자체가 매핑이 안 되거나(특히 void 리턴 시),
예상과 다른 동작(404, 응답 없음 등)이 발생한다.

해결 과정

@Controller 애노테이션을
@RestController 애노테이션으로 변경
서버 재시작
다시 Postman에서 요청
→ 정상 200 OK 응답 & DB에도 데이터 정상 입력!

느낀 점/정리

@RestController는 “데이터(API)” 반환,
@Controller는 “뷰(화면)” 반환용이다!
데이터만 반환하는 API는 @RestController로 만드는 게 정답
리턴 값이 없어도, JSON이 아니어도,
“API라면 무조건 @RestController”
404 에러가 났는데 DB에는 값이 들어간다면,
엔드포인트 매핑이나 애노테이션(@RestController)부터 꼭 점검할 것!

khu2172 님의 블로그

CORS란? (Cross-Origin Resource Sharing)

CORS란?

Same-Origin Policy(SOP)란?

Origin이란?

Preflight Request(프리플라잇 요청)

동작 흐름:

CORS 에러 해결 경험 (Spring Boot 프로젝트)

요약

마무리

JWT와 OAuth의 차이점 정리

1. JWT (JSON Web Token)

2. OAuth (Open Authorization)

비교표

결론

[트러블슈팅] PasswordEncoder 등 빈 주입 오류, 컴포넌트 스캔 누락

문제 상황

원인 분석

해결 방법

결과 및 교훈

마무리

IoC와 IoC 컨테이너란?(스프링에서의 역할 정리)

1. IoC(Inversion of Control)란?

2. IoC 컨테이너란?

3. 스프링 IoC 컨테이너의 주요 역할

4. IoC 컨테이너의 장점

5. 결론

[트러블슈팅] Spring 단위 테스트 실패

1. 문제 상황

2. 증상/에러 메시지

3. 원인 분석

4. 해결 방법

5. 배운 점

[트러블슈팅] 윈도우 한글 경로(ClassNotFoundException)로 인한 자바/테스트 에러

문제 현상

원인 파악을 위한 시도들

결국 원인은 ‘한글 계정(경로)’

최종 해결법: 영문 계정으로 마이그레이션

교훈

요약

JWT(Json Web Token)란?

JWT의 구조

Claim(클레임)이란?

Signature(서명)의 역할

JWT의 특징

주의사항

[트러블슈팅] MyBatis 매퍼(static context 에러) — 객체 주입과 메서드 호출 실수

문제 상황

에러 예시

원인 분석

올바른 사용 방법

교훈/정리

한 줄 정리

[트러블슈팅] FK 무결성 오류와 로그인 미구현 상태에서 user_id 입력 문제

문제 상황

주요 에러/현상

원인 분석

해결 방법

교훈/체크리스트

[트러블슈팅] @Controller vs @RestController, 404 에러 & 정상 동작 차이

문제 상황

원인 분석

해결 과정

느낀 점/정리

참고