[데브코스] Spring Boot 인증·인가(Auth) (16~17강) - apiKey 인증의 의미와 한계, 그리고 다음 문제(사용성)
[데브코스] Spring Boot 인증·인가(Auth) 기초
이번 글은 apiKey 인증으로 전환한 뒤(15강 이후)
강의에서 “왜 apiKey가 더 낫다고 말하는지 / 근데 왜 완전 안전한 건 아닌지”를 정리한 내용이다.
그리고 17강에서 바로 이어지는 새로운 문제(사용성 문제)까지 같이 정리한다.
0️⃣ 현재 시나리오 다시 보기 (강의 흐름)
처음엔 인증이 없어서 사칭(4칭) 이 가능했다.
- 회원 기능이 없었을 때: “누가 요청 보냈는지” 서버가 구분 불가
- 그래서 글/댓글 작성자에 user1, user2 같은 “정체성”이 없었음
- 이후 인증을 붙이면서 “작성자가 누구인지”를 알려주는 과정이 시작됨
1️⃣ username/password 방식으로 사칭을 막긴 했는데…
사칭(4칭)을 막으려고 이런 방식으로 바꿨다.
POST /api/v1/posts?username=user1&password=1234이렇게 하면 user2가 user1인 척 하려면 비밀번호까지 알아야 하니까,
사칭이 “쉬운 상태”에서 “어려운 상태”로 바뀐다.
하지만 강의에서 말한 것처럼, 여기서 문제가 3개가 터졌다.
문제 1) 오류 메시지가 들쭉날쭉
- 어떤 곳은 IllegalArgumentException
- 어떤 곳은 NoSuchElementException
- 응답 포맷/코드가 제각각
👉 그래서 ServiceException으로 통일하는 흐름이 나왔다.
(이건 “예외를 던질 때 resultCode + msg를 같이 담자”가 핵심)
문제 2) 매 요청마다 username/password를 포함해야 함
- 매 요청마다 인증정보를 실어 보내야 “서버가 사용자를 구분”할 수 있음
- 그런데 password가 매번 네트워크를 타는 건 찜찜함
문제 3) 클라이언트(앱/브라우저)가 username/password를 저장해야 함
- 요청마다 보내려면 어딘가에 저장돼야 함
- 근데 비밀번호 저장은 위험도가 큼
2️⃣ 그래서 apiKey를 도입한다 (핵심 논리)
강의에서 강조한 포인트는 이거였다.
apiKey 방식이라고 해서 “해커 입장에서 탈취가 더 어려워지는 것”은 아니다.
그냥 피해 규모가 작아지는 것이다.
✅ 중요한 오해 정리: “apiKey면 해킹이 어렵다?” ❌
apiKey도 결국
- 네트워크로 전송됨 (가로채기 가능)
- 클라이언트에 저장됨 (악성앱/분실 등으로 탈취 가능)
즉, 탈취 가능성 자체는 비슷하다.
그런데도 왜 apiKey를 쓰냐?
✅ 왜 apiKey가 더 낫다고 하는가? (피해 규모)
강의에서 나온 예시가 명확했다.
- 사람들은 여러 사이트에서 비슷한 비밀번호를 재사용하는 경향이 있다.
- 만약 어떤 서비스에서 username/password가 털리면?
- 그 해커는 다른 사이트(메일/은행/포털 등)에 로그인 시도를 한다.
- 피해가 서비스 하나로 끝나지 않는다.
반면 apiKey는:
- 그 서비스 내부에서만 의미가 있음
- 털리면 그 서비스에서 사칭이 가능하긴 하지만,
- apiKey만 재발급하면 그 즉시 무력화된다.
👉 결론:
apiKey는 “안전해서”가 아니라, “회복/대응이 쉬워서” 상대적으로 낫다.
3️⃣ Postman에서 바로 겪는 변화 (16강 실습 포인트)
이제 username/password로 호출하면 실패한다.
예를 들어 이런 요청을 보내면:
POST /api/v1/posts?username=user1&password=1234컨트롤러는 apiKey를 요구하는데 apiKey가 없으니까,
@NotBlank 검증에서 걸린다.
그래서 응답이 이런 식으로 떨어진다(형태는 프로젝트 설정에 따라 다름):
- 400 Bad Request
- 메시지에
apiKey-NotBlank...같은 검증 실패 정보
✅ 즉, “username/password를 보냈는데 왜 안 되지?”가 아니라
서버가 이제부터는 apiKey만 받도록 스펙이 바뀐 것이다.
4️⃣ 17강: apiKey 인증의 새로운 문제(사용성)
강의에서 바로 다음 문제가 나온다.
문제 발생 ✅
특정 사용자 입장에서 username/password와 다르게
apiKey는 외워서 쓰기가 어렵다.
- username/password는 (본인 한정) 외워서 입력 가능
- apiKey는 랜덤 문자열이라 사람이 외우기 힘듦
그래서 Postman에서도 이런 상황이 생긴다.
- user2로 활동하려면 user2의 apiKey를 알아야 함
- user3로 활동하려면 user3의 apiKey를 알아야 함
- 즉, apiKey를 어딘가에서 “조회/획득”하는 단계가 필요해진다.
5️⃣ 지금까지 문제/해결 흐름 한 장 요약
문제 리스트 (강의 정리)
- 사칭이 가능하다
- 오류 메시지가 통일되지 않는다
- 매 요청마다 username/password를 포함시켜야 한다
- 클라이언트에 username/password가 저장돼야 한다
- apiKey는 외워서 사용하기 어렵다
현재까지 해결된 것
- username/password → apiKey로 바꿈으로써
- “비밀번호 유출” 같은 큰 사고의 피해 규모를 줄이는 방향
- 클라이언트 저장도 password보다 apiKey가 상대적으로 낫다
- 예외는 ServiceException 등으로 응답 포맷을 통일하는 흐름
남은 문제(17강 포인트)
- apiKey를 사용하려면 사용자가 “그 apiKey를 알아야” 한다
→ 그래서 다음 단계에서 “로그인으로 apiKey를 얻는” 구조가 필요해진다(강의에서 언급)
🔚 마무리
16강에서 가장 인상 깊었던 말은 이거였다.
apiKey가 해킹을 막아주는 건 아니다.
다만 “피해 규모를 줄이고 대응을 쉽게 만드는 방식”이다.
그리고 17강은 그 apiKey 방식의 현실적인 단점(사용성)을 딱 짚어준다.
- 보안만 보면 apiKey가 낫지만
- 사용성 관점에서 “apiKey를 어떻게 얻고 쓰게 할 것인가” 문제가 남는다
여기까지가 16~17강의 핵심 흐름이다.
