13강은 새로운 코드를 많이 치는 강의가 아니었다.
대신 지금까지 우리가 왜 이렇게 복잡한 구조를 만들었는지를 정리해주는 강의였다.
이 강의를 한 문장으로 요약하면 이거다.
스프링부트는 사용자를 기억하지 못한다.
1️⃣ 스프링부트는 금붕어다
강의에서 가장 인상 깊었던 표현이 있었다.
스프링부트는 금붕어다.
이 말의 의미는 이거다.
- 스프링부트는
- 이전 요청을 기억하지 못한다
- 매 요청을 완전히 새 요청으로 본다
즉,
이 요청이 user1이 보낸 건지
user2가 보낸 건지
스프링부트는 모른다2️⃣ 사용자를 구분한다는 건 무슨 의미일까?
사용자를 구분한다 =
이 요청을 누가 보냈는지 아는 것
예를 들면:
- 이 글을 user1이 썼는지
- user2가 썼는지
- 아니면 아예 로그인 안 한 사람인지
👉 이걸 모르면 생기는 문제:
- 아무나 글 수정 가능
- 아무나 댓글 삭제 가능
- 사칭 가능
그래서 모든 요청에는 “나는 누구다”라는 정보가 필요하다.
이걸 인증 정보(신분증)라고 부른다.
3️⃣ 지금까지 우리가 쓰던 인증 정보
현재까지 우리가 쓰고 있는 인증 정보는 이거였다.
username
password즉, 요청마다 이렇게 보냈다.
POST /api/v1/posts?username=user1&password=1234또는 body + parameter 조합으로 전달했다.
이렇게 해서 스프링부트에게 알려준 것이다.
“이 요청은 user1이 보낸 거예요.”
4️⃣ 그런데 이 구조의 치명적인 문제
❌ 문제 1: 매 요청마다 개인정보가 날아간다
- username
- password
이 둘은 민감한 개인정보다.
그런데:
- 글 작성
- 댓글 작성
- 수정
- 삭제
👉 모든 요청마다 네트워크를 통해 전송됨
이건 보안적으로 굉장히 안 좋은 구조다.
❌ 문제 2: 앱이 비밀번호를 저장해야 한다
인증 정보를 매 요청마다 보내려면,
클라이언트(앱)는 이 정보를 어딘가에 저장해야 한다.
즉:
- 앱 안에 username 저장
- 앱 안에 password 저장
👉 이것도 보안상 매우 위험하다.
5️⃣ 지금 구조는 “동작은 하지만 좋은 구조는 아니다”
여기까지의 구조를 정리하면 이렇다.
✅ 장점
- 스프링부트가 사용자를 구분할 수 있다
- 사칭을 어느 정도 막을 수 있다
❌ 단점
- 매 요청마다 비밀번호 전송
- 앱에 비밀번호 저장
- 보안적으로 좋지 않음
- 실무에서 거의 안 쓰는 방식
그래서 강의에서 분명히 말했다.
이 구조는 학습용이다.
6️⃣ 그래서 등장하는 새로운 인증 정보: API KEY
이 문제를 해결하기 위해
이제부터 인증 정보를 이렇게 바꿀 것이다.
username/password ❌
API KEY ⭕개념만 정리하면:
- 로그인할 때 한 번만 username/password 사용
- 서버가 API KEY(신분증) 발급
- 이후 모든 요청에는 API KEY만 보냄
👉 이렇게 하면:
- 비밀번호를 매번 보낼 필요 없음
- 앱에 비밀번호 저장 안 해도 됨
- 보안이 훨씬 좋아짐
7️⃣ 13강 핵심 요약
✔ 스프링부트는 요청을 기억하지 못한다
→ 요청마다 누군지 알려줘야 한다
✔ 인증 정보가 필요하다
→ 지금은 username/password
✔ 지금 방식의 문제점
- 보안에 취약
- 실무에서 쓰기 어렵다
✔ 해결 방향
→ username/password 대신 API KEY 사용
🔚 마무리
13강은
“이제 JWT 들어가니까 외워라” 같은 강의가 아니었다.
오히려 이 질문에 답해주는 강의였다.
“우리가 지금까지 왜 이렇게 고생했는가?”
이제야 이해했다.
- 인증이 왜 필요한지
- 스프링부트가 왜 사용자 구분을 못 하는지
- 왜 더 나은 인증 방식이 필요한지
