이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 기존 Spring MVC 기반 웹앱을 Spring Boot로 전환하는 작업을 맡았습니다. 처음에는 단순히 설정 파일만 바꾸면 될 줄 알았으나, XML 빈 설정이 200개가 넘어서 자동 설정으로 옮기는 데 생각보다 오래 걸렸습니다.
특히 @Transactional 적용 범위가 달라지면서 트랜잭션이 예상과 다르게 커밋되는 버그가 3군데에서 발생하였습니다. 테스트 없이는 발견하기 어려운 문제라서, 이때부터 통합 테스트를 꼼꼼히 챙기게 되었습니다.
전환 후 빌드 설정이 줄고 배포가 단순해졌습니다. JAR 하나로 실행되는 구조가 되니 로컬 환경 세팅도 빨라졌습니다. Spring 생태계는 설정의 자유도가 높은 만큼 트랜잭션 경계와 빈 스코프를 명확하게 이해하는 것이 중요하다는 것을 이때 배웠습니다.
졸업 프로젝트에서 Spring Boot로 REST API 서버를 처음 만들었는데, 처음엔 Controller에 비즈니스 로직을 다 넣었어요. 기능은 됐는데 나중에 같은 로직이 Controller 3개에 중복되는 걸 발견했습니다.
Service 레이어로 비즈니스 로직을 분리하고, Repository는 데이터 접근만 담당하도록 구조를 바꿨어요. 처음엔 레이어를 나누는 게 오버엔지니어링 같았는데, 기능을 추가할 때 바꿀 파일이 확실히 줄어들었습니다.
또 JPA를 쓰면서 N+1 쿼리 문제로 응답이 10배 이상 느려진 적도 있었어요. @EntityGraph로 Fetch Join을 추가해서 해결했는데, ORM을 쓴다고 쿼리를 신경 안 써도 되는 게 아니라는 걸 그때 배웠습니다. 레이어드 아키텍처는 구조가 아니라 책임 분리라는 게 핵심이었어요.
팀 프로젝트에서 Spring Security로 JWT 인증을 구현했어요. 처음엔 토큰을 검증하는 필터만 만들면 되는 줄 알았는데, 로그아웃 후에도 기존 토큰으로 API를 호출할 수 있다는 걸 뒤늦게 발견했습니다.
JWT는 서버가 상태를 안 갖기 때문에 발급된 토큰을 강제로 무효화하기 어렵다는 걸 그때 알게 됐어요. Redis에 로그아웃된 토큰을 블랙리스트로 관리하는 방식을 추가했습니다.
구현 후 블랙리스트 조회가 매 요청마다 Redis 호출을 추가하는 오버헤드가 생겼는데, 토큰 만료 시간을 짧게(15분) 가져가는 방식과 블랙리스트를 같이 쓰는 게 절충안이라는 걸 배웠어요. 보안 설계는 완벽한 방법이 없고 트레이드오프를 고르는 것이라는 점이 인상 깊었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SK inc.(AX) 솔루션 아키텍트 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.