#2 - Spring Boot 4를 배우기 전에, 백엔드는 무엇을 해야 할까?

Spring Boot 4를 배우기 전에, 백엔드는 무엇을 해야 할까?

IT 백엔드 초보 개발자가 반드시 한 번은 겪게 되는 이야기
그리고 가능하면… 겪지 않아도 됐을 실수들

1. 어느 날, 프론트를 믿었던 백엔드 개발자

백엔드를 처음 맡았을 때 이런 말을 자주 듣는다.

"프론트에서 다 검증했어요."
"이 값은 무조건 이렇게 옵니다."
"사용자가 이 버튼을 누를 수 있는 경우는 없어요."

그리고 그 말을 그대로 믿은 순간, 백엔드는 조용히 무너지기 시작한다.

음수 가격
존재하지 않는 ID
권한 없는 사용자의 요청
순서가 뒤틀린 상태 전이

이 모든 것은 프론트가 악해서가 아니라,
백엔드의 역할을 착각했기 때문에 발생한다.

2. 백엔드의 첫 번째 명제: "모든 입력은 거짓일 수 있다"

백엔드를 시작할 때 가장 먼저 머리에 새겨야 할 명제는 이것이다.

"백엔드가 받는 모든 입력은 신뢰할 수 없다."

여기서 말하는 입력은 단순히 사용자 입력만이 아니다.

프론트엔드에서 보내는 JSON
모바일 앱 요청
내부 관리자 페이지 요청
심지어 같은 팀원이 만든 서비스의 요청까지

👉 HTTP 요청은 모두 외부 입력이다.

백엔드는 이 입력을 **사실(Fact)**이 아니라
**주장(Claim)**으로 받아들여야 한다.

3. 그래서 백엔드는 무엇을 해야 할까?

백엔드의 역할을 한 문장으로 정의하면 이렇다.

"비즈니스의 최종 심판"

프론트는 경험을 만들고,
백엔드는 규칙을 지킨다.

백엔드가 반드시 책임져야 할 것들

데이터 무결성
권한과 인증
상태 전이의 순서
비즈니스 규칙
실패했을 때의 복구 가능성

프론트가 아무리 예쁘고 친절해도,
이 중 하나라도 백엔드가 놓치면 사고는 반드시 난다.

4. 초보 백엔드 개발자가 가장 많이 하는 실수

❌ 실수 1. "프론트에서 막아주니까 괜찮겠지"

프론트의 검증은 UX를 위한 것이지,
보안을 위한 것이 아니다.

브라우저 개발자 도구
Postman
curl

이 세 가지만 있으면 프론트는 언제든지 우회된다.

❌ 실수 2. "이 API는 내부에서만 써요"

오늘의 내부 API는,
내일의 공개 API가 된다.

배치
어드민
마이그레이션

**"내부니까 대충"**이라는 생각은
나중에 기술 부채로 돌아온다.

❌ 실수 3. "에러는 나중에 정리하죠"

백엔드에서 에러 처리를 미루는 것은,

"문제는 언젠가 더 크게 터지게 두겠다"

라는 말과 같다.

에러는 지금 정의하지 않으면,
나중에 제어할 수 없다.

5. 백엔드는 '방어적으로' 사고해야 한다

초보 백엔드 개발자에게 가장 중요한 사고 방식은 이것이다.

"이 요청이 악의적이라면?"

값이 없다면?
타입이 다르다면?
순서가 잘못됐다면?
이미 처리된 요청이라면?

이 질문을 코드로 옮기는 것,
그게 바로 백엔드 로직이다.

6. 그래서 Spring Boot 4를 왜 배우는가

Spring Boot는 편리한 프레임워크다.

하지만 이것을 편의 도구로만 쓰면,
백엔드는 프론트의 하청이 된다.

Spring Boot 4를 배우기 전에,
이 질문에 답할 수 있어야 한다.

이 검증은 어디서 해야 하는가?

이 규칙은 누가 책임지는가?

이 실패는 시스템에 어떤 영향을 주는가?

프레임워크는 답을 대신해주지 않는다.

7. 이 강의의 출발점

이 강의는 이렇게 시작한다.

코드를 먼저 쓰지 않는다
기능보다 규칙을 먼저 본다
"동작한다"보다 "깨지지 않는다"를 우선한다

백엔드는 믿지 않는 역할이다.
그리고 그 불신이 시스템을 지킨다.

다음 단계에서는,
이 사고방식을 Spring Boot 4의 구조와 코드로 어떻게 옮기는지 살펴본다.