스프링을 따라치기로만 공부하면 면접에서 막히는 이유
Spring Boot 강의를 따라 하면 서버는 생각보다 빨리 뜹니다. 컨트롤러를 만들고, 서비스와 레포지토리를 나누고, JPA로 저장까지 해보면 백엔드를 공부한 것처럼 느껴집니다.
면접에서 막히는 지점은 그다음입니다. "왜 이 구조를 썼나요?", "DI가 없으면 무엇이 불편한가요?", "JPA가 해결한 문제가 무엇인가요?" 같은 질문에 사용법만으로는 답하기 어렵습니다.
장면 요약: 서버를 띄운 경험과 이유를 설명하는 능력은 다릅니다.
따라치기는 작동 경험을 주지만 이유를 남기지 않습니다
프레임워크는 많은 불편함을 숨겨줍니다. 그래서 처음부터 Spring Boot로 시작하면 무엇이 편해진 것인지 알기 어렵습니다. 서버 소켓을 열고, HTTP 요청을 파싱하고, 응답 포맷을 직접 만들고, DB 결과를 객체로 옮겨보면 프레임워크가 대신해주는 일이 보입니다. 불편함을 겪은 뒤에야 추상화의 가치가 설명됩니다.
면접관은 API를 만들 수 있는지만 보지 않습니다. 왜 레이어를 나눴는지, 왜 의존성을 주입하는지, 왜 트랜잭션 경계를 잡았는지 묻습니다. 이 질문은 사용법보다 경험에서 답이 나옵니다.
JPA도 JDBC의 고통을 알아야 이해됩니다
JPA를 바로 쓰면 `save`와 `findById`가 마법처럼 보일 수 있습니다. 하지만 실제로는 SQL 문자열, 파라미터 바인딩, RowMapper, 객체 매핑, ID 생성, 트랜잭션 같은 반복 문제를 줄여주는 도구입니다.
JDBC로 작은 CRUD를 직접 만들어보면 JPA가 왜 필요한지 명확해집니다. 단순히 "편해서 씁니다"가 아니라 "객체와 테이블 사이의 반복 매핑과 변경 추적 비용을 줄이기 위해 씁니다"라고 설명할 수 있습니다.
DI, IoC, AOP, 프록시도 비슷합니다. 외울 개념이 아니라 개발자가 반복해서 부딪히는 결합도, 공통 관심사, 테스트 어려움을 줄이는 장치로 연결해야 합니다.
장면 요약: 불편함을 한 번 겪어야 프레임워크가 숨겨준 일이 보입니다.
3일짜리 실전 로드맵
스프링을 이미 따라 해봤다면, 다음 순서로 빈칸을 채우는 것이 좋습니다.
순수 Java로 아주 작은 HTTP 서버를 만들어 봅니다.
문자열 응답, JSON 응답, 라우팅을 직접 처리합니다.
JDBC로 CRUD를 만들고 매핑 반복을 경험합니다.
같은 기능을 Spring MVC와 JPA로 다시 만듭니다.
DI가 테스트와 변경에 어떤 차이를 만드는지 비교합니다.
트랜잭션, 예외 처리, 검증을 한 흐름으로 정리합니다.
이 과정은 오래 걸리는 커리큘럼이 아니라 "왜 스프링이 필요한지"를 몸으로 확인하는 압축 실험입니다.
강의를 볼 때 질문을 바꾸면 달라집니다
같은 Spring Boot 강의를 보더라도 질문이 달라지면 학습 효과가 달라집니다. "어떻게 따라 치는가"보다 "이 코드가 없으면 무엇이 불편한가"를 먼저 봐야 합니다.
컨트롤러가 요청을 받는 장면에서는 직접 HTTP를 처리했다면 어떤 코드가 필요했을지 떠올려야 합니다. JPA를 쓰는 장면에서는 JDBC였다면 어떤 매핑 코드가 반복됐을지 비교해야 합니다. 트랜잭션을 붙이는 장면에서는 실패 중간 상태가 DB에 어떻게 남을지 질문해야 합니다. 이런 비교가 쌓이면 면접 답변이 외운 정의에서 경험 기반 설명으로 바뀝니다.
바로 적용할 체크리스트
면접 준비용으로는 다음 질문에 답할 수 있어야 합니다.
Spring MVC가 직접 HTTP 처리보다 줄여주는 일은 무엇인가요?
DI를 쓰지 않으면 테스트와 변경에서 무엇이 불편한가요?
JPA가 SQL을 없애는 도구가 아니라면, 정확히 무엇을 줄여주나요?
AOP와 프록시는 어떤 반복 코드를 밖으로 빼기 위한 장치인가요?
트랜잭션 경계는 어느 레이어에서 잡았고, 그 이유는 무엇인가요?
스프링 공부의 목표는 서버를 한 번 띄우는 것이 아닙니다. 프레임워크가 감춘 불편함을 이해하고, 그 선택을 자기 말로 설명할 수 있게 되는 것입니다.