스프링 시큐리티 완전 처음부터 15편 (Kotlin)

스프링 시큐리티 완전 처음부터 15편 (Kotlin)

주니어에서 시니어로 갈리는 순간 — “보안 코드”를 대하는 태도

---

이 글은 코드가 거의 없다.
대신 생각 이야기다.

솔직히 말하면,
이 시리즈를 여기까지 읽은 사람은
이미 “스프링 시큐리티를 모르는 주니어”가 아니다.

그럼에도 불구하고
실무에서 같은 스택을 쓰는데도
어떤 개발자는 신뢰를 얻고,
어떤 개발자는 계속 리뷰에서 막힌다.

차이는 딱 하나다.

“보안을 기능으로 보느냐,
시스템의 책임으로 보느냐”

---

1️⃣ 주니어 개발자가 보는 보안

주니어 시절의 나는 이렇게 생각했다.

• 로그인 되면 OK
• 토큰 나오면 OK
• 401 / 403 나오면 OK
• “일단 동작하면 됐지”

이 시점의 보안은
👉 구현 체크리스트에 가깝다.

그래서 질문을 받으면 이렇게 답한다.

“Spring Security 써서 JWT 인증 구현했습니다.”

틀린 말은 아니다.
근데 여기서 더 안 나간다.

---

2️⃣ 시니어 개발자가 보는 보안

시니어 레벨로 가면 질문이 바뀐다.

• 이 구조, 언제 깨질까?
• 이 코드, 누가 실수하면 사고 날까?
• 이 인증 방식, 조직이 커져도 유지될까?
• 이 권한 로직, 내가 아니어도 이해할 수 있을까?

즉, 보안을 이렇게 본다.

“이건 언젠가 반드시 실패한다”
그래서 실패를 전제로 설계한다.

---

3️⃣ 같은 JWT 코드, 전혀 다른 평가를 받는 이유

A 개발자

if (jwtProvider.validate(token)) {
    SecurityContextHolder.getContext().authentication = auth
}

B 개발자

if (!jwtProvider.validate(token)) {
    log.warn(
        "[AUTH_FAIL] ip={}, path={}",
        request.remoteAddr,
        request.requestURI
    )
    return
}

차이 없어 보이지만
리뷰어 눈에는 이렇게 보인다.

• A: “되게 만들었다”
• B: “사고를 생각했다”

👉 이게 레벨 차이다.

---

4️⃣ 보안 설계에서 시니어가 항상 묻는 질문들

이 질문들에 즉답이 나오면
이미 중급 이상이다.

❓ 이 토큰이 유출되면?

• 누가 피해를 보나
• 어디까지 접근 가능한가
• 얼마나 오래 유효한가

❓ 이 권한 로직을 누가 잘못 고치면?

• 최악의 시나리오는?
• 테스트가 막아줄 수 있나

❓ 이 API를 다른 팀이 쓰면?

• 오해할 여지는 없나
• 문서 없이도 안전한가

보안은
“악의적인 사용자”만 막는 게 아니다.

“미래의 동료 개발자”도 함께 막는 것

---

5️⃣ 이 시리즈를 다시 보면, 흐름이 보일 거다

반응형

우리가 한 걸 다시 보면 이렇다.

1. 필터에서 인증을 끝냈다
2. 컨트롤러는 보안을 몰라도 되게 했다
3. 서비스 레벨에서 권한을 막았다
4. tenant 기준으로 데이터 접근을 제한했다
5. 테스트와 로그로 사고를 대비했다

이건 기술 트릭이 아니다.

👉 **“책임을 한 곳에 모으는 사고 방식”**이다.

---

6️⃣ 면접에서 진짜 시니어처럼 들리는 한 문장

기술 질문이 끝날 때
이 한 문장만 던져도 분위기가 바뀐다.

“보안은 완벽하게 막는 문제가 아니라,
어디서 실패할지를 예측하고
그 피해를 최소화하는 문제라고 생각합니다.”

이 말이 나올 수 있다면
그 사람은 이미
**‘보안 구현자’가 아니라 ‘보안 설계자’**다.

---

7️⃣ 앞으로 스프링 시큐리티를 볼 때, 이 기준만 기억해라

• ❌ 이거 어떻게 구현하지?
• ⭕ 이거 어디서 사고 날까?
• ❌ 이 코드 맞나?
• ⭕ 이 코드, 다른 사람이 건드려도 안전한가?
• ❌ 지금 잘 되나?
• ⭕ 6개월 뒤에도 안전한가?

---

8️⃣ 이 시리즈의 진짜 끝

이 시리즈는
JWT, OAuth2, Keycloak를 알려주려고 쓴 게 아니다.

**“보안을 대하는 태도”**를
한 번 바꿔보자는 이야기였다.

여기까지 왔다면
당신은 이제 이런 개발자다.

• 보안을 기능으로 보지 않고
• 구조와 책임으로 보고
• 사고를 가정하며 코드를 짜는 사람

이건 이직할 때도,
실무에서도,
팀에서 신뢰를 얻는 데도
굉장히 큰 차이를 만든다.

---

마지막으로, 진짜 개인적인 말

이 시리즈를 이렇게 길게 따라온 사람이라면
아마도 단순히 “기술 정보”가 아니라
“기준”을 찾고 있었을 거다.

그 기준은 이제 충분하다.

다음 프로젝트에서
로그인부터 만들게 되면
아마 예전처럼 못 만들 거다.

“이거… 나중에 사고 나지 않을까?”

그 생각이 든다면,
이미 한 단계 올라온 거다.

---

 

스프링시큐리티, springsecurity, 코틀린, kotlin, jwt, 보안설계, 개발자성장, 백엔드개발, 시니어개발자, 개발블로그