스프링을 따라치기로만 공부하면 면접에서 막히는 이유

Spring Boot는 처음 배울 때 매우 편합니다. 어노테이션 몇 개를 붙이고, 의존성을 추가하고, 예제를 따라 치면 서버가 금방 뜹니다. 그래서 “스프링 별거 아니네”라는 느낌을 받기도 쉽습니다. 문제는 서버가 돌아가는 것과 내가 그 구조를 설명할 수 있는 것은 전혀 다른 일이라는 점입니다.

강의를 틀어놓고 그대로 따라 친 뒤 “어, 돌아가네”에서 끝나면 사용법은 익힐 수 있습니다. 하지만 면접에서는 보통 사용법만 묻지 않습니다. 왜 이 구조를 쓰는지, 이 어노테이션 뒤에서 무슨 일이 일어나는지, 트랜잭션은 어디서 시작되고 어디서 끝나는지, JPA가 왜 필요한지 묻습니다. 따라치기로 만든 프로젝트는 화면상으로는 그럴듯하지만, 질문 앞에서는 쉽게 무너질 수 있습니다.

스프링의 편리함은 불편함 뒤에 보입니다

스프링을 제대로 이해하려면 편한 것부터 시작하지 않는 편이 좋습니다. 먼저 불편한 경험이 필요합니다. 예를 들어 순수 Java로 아주 단순한 웹서버를 만든다고 생각해보면 해야 할 일이 꽤 많습니다. 서버 소켓을 열어야 합니다. 클라이언트 요청을 받아야 합니다. input stream을 읽어야 합니다. HTTP 응답 형식에 맞춰 status line, header, body를 직접 구성해야 합니다.

이 과정을 직접 겪어보면 웹 프레임워크가 얼마나 많은 반복 작업을 대신해주는지 보입니다.

처음부터 Spring Boot로 시작하면 `@RestController`, `@GetMapping`, `@PostMapping`이 편하다는 것만 알게 됩니다. 하지만 순수 Java 웹서버를 거친 뒤 Spring Boot를 보면 관점이 바뀝니다. 이 편리함이 어디서 왔는지, 어떤 반복을 감춘 것인지, 어떤 규칙 위에서 돌아가는지 보이기 시작합니다.

면접은 사용법보다 동작 원리를 묻습니다

백엔드 면접에서 “컨트롤러는 어떻게 만드나요?”만 묻는 경우는 많지 않습니다. 오히려 이런 질문이 나옵니다.

• 요청이 들어오면 어떤 흐름으로 컨트롤러까지 도달하나요?

• 객체는 누가 만들고, 의존성은 누가 넣어주나요?

• 프록시는 왜 필요하고 어디에 쓰이나요?

• AOP는 어떤 문제를 해결하나요?

• 트랜잭션은 어떻게 적용되나요?

이 질문들은 외운 정의만으로는 답하기 어렵습니다. 내가 어떤 불편함을 겪었고, 그 불편함을 줄이기 위해 스프링이 어떤 구조를 제공하는지 이해해야 답변이 자연스러워집니다.

DI/IoC, AOP, 프록시, application context는 따로 떨어진 키워드가 아닙니다. 스프링이 객체 생성과 연결, 공통 관심사 처리, 실행 흐름 제어를 어떻게 다루는지 설명하는 하나의 흐름입니다.

JPA도 SQL의 불편함 뒤에 이해됩니다

JPA도 마찬가지입니다. 처음부터 JPA만 쓰면 `save`, `findById`, `@Entity`는 익숙해질 수 있습니다. 하지만 왜 JPA가 필요한지 설명하기는 어렵습니다.

먼저 SQL 문자열을 직접 만들어보면 불편함이 보입니다. 조회 결과를 객체로 옮기기 위해 RowMapper를 작성해야 합니다. 테이블 컬럼과 객체 필드를 맞춰야 합니다. ID 생성 방식도 직접 고민해야 합니다. 변경이 생길 때마다 SQL과 매핑 코드를 같이 고쳐야 합니다. 이 경험이 있어야 JPA가 단순히 “SQL을 안 써도 되는 도구”가 아니라는 점이 보입니다.

JPA는 객체와 테이블 사이의 반복 매핑 문제를 줄여줍니다. 엔티티의 생명주기를 관리합니다. 영속성 컨텍스트, 지연 로딩, 변경 감지 같은 개념으로 개발자가 직접 관리하던 일부 부담을 프레임워크 쪽으로 옮깁니다. 이것도 결국 불편함을 겪은 뒤에야 제대로 이해됩니다.

기초는 HTTP와 데이터베이스에서 시작합니다

Spring Boot를 잘 쓰려면 스프링만 공부하면 된다고 생각하기 쉽습니다. 하지만 실제로는 그 앞단의 기초가 받쳐줘야 합니다. HTTP가 무엇인지 알아야 합니다. GET과 POST가 어떻게 다른지 알아야 합니다. JSON이 왜 쓰이는지 알아야 합니다. 서버가 요청을 받고 응답을 돌려주는 기본 흐름을 이해해야 합니다.

데이터베이스도 마찬가지입니다. 처음에는 메모리에 데이터를 저장해볼 수 있습니다. 그다음 데이터베이스로 옮겨보면 연결, 쿼리, 트랜잭션, 매핑의 문제가 보입니다. 이 경험이 있어야 Spring Data JPA나 트랜잭션 추상화가 왜 편한지 이해할 수 있습니다.

기초를 건너뛰고 프레임워크 사용법만 익히면 빠르게 무언가를 만들 수는 있습니다. 하지만 에러가 났을 때 어디서부터 봐야 하는지 모르게 됩니다.

스프링 학습은 아키텍처와 운영으로 이어져야 합니다

스프링 입문은 컨트롤러와 API 만들기에서 끝나지 않습니다. 실제 백엔드 개발은 구조를 나누는 일로 이어집니다. 컨트롤러, 서비스, 리포지토리로 책임을 나눕니다. 트랜잭션 경계를 정합니다. 예외를 어떻게 처리할지 정합니다. 입력값 검증을 어디서 할지 정합니다. 데이터베이스 변경과 API 응답 형식을 함께 생각합니다.

그다음에는 배포와 테스트로 이어집니다. 로컬에서만 돌아가는 서버는 실제 서비스가 아닙니다. 배포된 환경에서 정상 동작해야 하고, 테스트로 변경의 안정성을 확인해야 합니다.

그래서 스프링 학습 로드맵은 HTTP, 순수 Java 웹서버, 데이터베이스 연결, 스프링 동작 원리, 3계층 아키텍처, 트랜잭션, 예외 처리, 검증, 배포, 테스트로 이어지는 편이 좋습니다.

경험으로 답변하는 개발자가 되어야 합니다

면접에서 강한 답변은 보통 정의 암기에서 나오지 않습니다. 경험에서 나옵니다. “DI는 의존성 주입입니다”라고 말하는 것보다, 직접 객체를 생성하고 연결하다가 생긴 불편함을 설명하고, 스프링 컨테이너가 그 문제를 어떻게 줄여주는지 말하는 답변이 더 설득력 있습니다.

“JPA는 ORM입니다”라고 말하는 것보다, SQL 문자열과 객체 매핑을 직접 관리할 때 생긴 반복을 설명하고, JPA가 어떤 부담을 줄여주는지 말하는 답변이 더 강합니다.

따라치기는 시작점이 될 수 있습니다. 하지만 거기서 멈추면 약합니다. 한 번은 불편한 방식으로 만들어보고, 그다음 프레임워크가 무엇을 대신해주는지 확인해야 합니다. 스프링을 빨리 쓰는 것보다 더 오래 남는 것은 “왜 이렇게 쓰는지”를 설명할 수 있는 경험입니다.