이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
Spring에서 가장 유용하게 활용한 기능은 의존성 주입(DI)입니다. 객체 간 결합도를 낮춰 테스트 코드 작성이 훨씬 수월해졌고, 인터페이스로 의존하면 구현체를 교체해도 상위 코드를 수정할 필요가 없었습니다.
AOP(관점 지향 프로그래밍)는 로깅과 트랜잭션 처리에 활용했습니다. 메서드마다 로그를 직접 넣는 대신 어노테이션 하나로 공통 로직을 적용할 수 있어 중복 코드가 크게 줄었습니다.
@Transactional 어노테이션은 편리하지만, 트랜잭션 경계를 제대로 이해하지 못하면 예외 발생 시 롤백이 안 되는 상황이 생깁니다. 이를 직접 경험하고 나서 트랜잭션 전파 속성과 격리 수준을 꼼꼼히 확인하는 습관이 생겼고, 예상치 못한 버그를 사전에 막을 수 있었습니다.
학부 프로젝트에서 주문 생성 API를 만들 때 오류가 나면 DB가 롤백될 거라 믿었는데, 실제로는 재고 차감만 되고 주문은 생성되지 않는 상태가 남았습니다. 을 서비스 메서드에 붙였는데도 롤백이 안 된 이유를 처음엔 전혀 몰랐습니다. 알고 보니 내부에서 로 예외를 잡아 삼켜버린 게 원인이었습니다. Spring은 예외가 메서드 밖으로 전파돼야 롤백을 트리거하는데, 내부에서 처리하면 트랜잭션이 정상 종료된 것으로 인식한다는 걸 공식 문서에서 확인했습니다. 수정 후에도 Checked exception은 기본적으로 롤백 대상이 아니라는 사실을 추가로 발견했고, 롤백 대상 예외를 명시하는 설정을 추가했습니다. 이후 트랜잭션을 쓸 때 예외 전파 경로를 먼저 그려보는 습관이 생겼습니다.
학부 프로젝트에서 처음 JWT 기반 인증을 구현할 때 Spring Security 없이 직접 필터를 만들었습니다. 토큰 파싱, 서명 검증, 역할 확인을 모두 수작업으로 짜다 보니 400줄이 넘는 필터 코드가 생겼고, 팀원이 건드리기를 꺼려했습니다. 다음 프로젝트에서 Spring Security를 처음 도입했는데, 설정과 서비스 구현만으로 같은 기능을 40줄 안에 구성할 수 있었습니다. 처음에는 요청 경로별 접근 제한 설정이 직관적이지 않아 모든 엔드포인트가 열려버리는 실수를 했지만, 공식 문서 예제와 비교해가며 고쳤습니다. 방어나 세션 관리 같은 보안 기본 설정도 프레임워크가 기본값으로 잡아줘서 빠뜨리기 어렵다는 걸 알게 됐습니다. 인증 로직은 검증된 프레임워크를 이해하고 올바르게 쓰는 편이 더 안전하다는 걸 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.