인턴 멘토링 프로그램에서 서버 개발의 기본 개념부터 데이터베이스와 JPA, API 설계, Controller와 Service 계층의 분리, 테스트 코드 작성, 그리고 Spring Security를 활용한 로그인과 인증까지 백엔드 개발의 전반적인 흐름을 처음으로 경험하며 Todo 애플리케이션을 구현하였다. 백엔드 개발을 본격적으로 접한 것이 이번이 처음이었기 때문에, 단순히 기능을 완성하는 것보다 서버가 어떻게 동작하는지 이해하는 것을 목표로 과제를 진행하였다.
초반에는 “일단 기능이 동작하게 만드는 것”이 가장 중요하다고 생각했다. 엔티티 설계 역시 데이터베이스 테이블을 그대로 옮기는 수준으로만 인식했고, API도 필요할 때마다 그때그때 추가하는 방식으로 접근하였다. 그러나 구현이 진행될수록 코드가 점점 복잡해졌고, 간단한 수정에도 여러 파일을 동시에 수정해야 하는 상황을 겪으면서 설계 없이 구현을 시작한 것이 오히려 더 큰 혼란을 만든다고 느끼게 되었다.
이러한 경험을 통해 기능 구현에 앞서 도메인 구조를 먼저 정리하는 과정이 필요하다는 것을 체감하였다. User, Group, Task 엔티티를 설계할 때 단순히 필드를 나열하는 것이 아니라, 각 객체가 어떤 책임을 가지는지, 어떤 상태 변경이 허용되어야 하는지를 고민하게 되었다. 그 결과 setter 사용을 지양하고, 의미 있는 update 메서드를 통해 상태를 변경하도록 설계하였고, 이는 코드의 의도를 스스로 이해하는 데에도 큰 도움이 되었다.
또한 Lombok과 JPA 어노테이션을 사용하면서 불필요한 코드가 줄어들자, 클래스 하나를 보더라도 핵심 구조와 역할이 이전보다 훨씬 명확하게 보이기 시작했다. enum 클래스를 통해 상태 값을 관리하여 잘못된 값이 들어오지 않도록 보호할 수 있었다. 처음에는 설계 과정이 구현 속도를 늦추는 것처럼 느껴졌지만, 이후 기능을 추가하거나 수정할 때 구조를 크게 건드리지 않아도 된다는 점에서 효율적이라 느꼈다.
Controller와 Service 계층을 분리하면서, 백엔드 코드에서 “역할”이라는 개념을 처음으로 명확히 인식하게 되었다. 처음에는 모든 로직을 한 곳에 작성하는 것이 더 편하게 느껴졌지만, 요청 처리, 검증, 비즈니스 로직이 뒤섞이면서 코드의 흐름을 이해하기 어려워졌다.
Service 계층에 비즈니스 로직과 검증을 집중시키고, Controller는 요청과 응답 변환에만 집중하도록 구조를 정리하자 각 역할이 분명해졌다. 특히 로그인한 사용자가 자신의 데이터만 접근할 수 있도록 검증하는 로직을 Service 계층에 두면서, 단순히 API를 만드는 것이 아니라 도메인 규칙을 코드로 표현하는 방법을 배울 수 있었다. 이 경험을 통해 계층 분리는 형식적인 규칙이 아니라, 변경에 강한 코드를 만들기 위한 설계 원칙이라는 점을 이해하게 되었다.
멘토링에서 가장 어렵게 느껴졌던 부분은 Spring Security였다. 인증 과정이 필터 체인 내부에서 처리되기 때문에 코드의 흐름이 눈에 보이지 않았고, 작은 설정 오류에도 401이나 403 오류가 발생하여 원인을 파악하기가 쉽지 않았다. 처음에는 “왜 막히는지”조차 감이 잡히지 않아 답답함을 느꼈다.
이 문제를 해결하기 위해 Spring Security의 전체 인증 흐름을 단계별로 정리해 보았다. 요청이 들어오면 어떤 필터가 실행되는지, JWT 인증 필터가 언제 토큰을 검사하는지, 그리고 인증 정보가 어떤 방식으로 SecurityContext에 저장되는지를 나누어 이해하려고 노력했다. 특히 JwtAuthenticationFilter가 Authorization 헤더에서 토큰을 읽고, 이를 검증한 뒤 Authentication 객체를 생성하여 SecurityContextHolder에 저장하는 과정을 추적하였다.
또한 Swagger를 활용해 다양한 상황을 직접 테스트하였다. 토큰이 없는 상태, 잘못된 토큰을 전달한 상태, 다른 사용자의 자원에 접근한 상태를 각각 만들어 요청을 보내고, 그 결과로 어떤 상태 코드와 예외가 발생하는지를 확인하였다. 이 과정을 통해 인증(Authentication) 실패와 인가(Authorization) 실패가 서로 다른 문제이며, 같은 403 오류처럼 보여도 원인이 다를 수 있다는 점을 체감하게 되었다.
문제가 발생할 때마다 추측에 의존하지 않고, 필터 → SecurityContext → Controller → Service 순서로 흐름을 따라가며 하나씩 검증하였다. 특히 @AuthenticationPrincipal이 어떤 조건에서 정상적으로 주입되는지를 직접 확인하면서, 보안 문제 역시 일반적인 디버깅 문제처럼 접근할 수 있다는 자신감을 얻게 되었다. 이 경험을 통해 Spring Security는 설정을 외워서 사용하는 기술이 아니라, 요청 흐름을 이해해야 다룰 수 있는 기술이라는 점을 깨닫게 되었다.
백엔드 개발을 처음 접했을 때는 요청이 들어와 데이터베이스에 저장되고 다시 응답으로 돌아오기까지의 흐름이 명확히 보이지 않아 막막하게 느껴졌다. 프론트엔드와 달리 즉각적인 화면 변화가 없기 때문에, “지금 무엇을 만들고 있는지”조차 혼란스러운 순간도 많았다. 하지만 과제를 진행하며 Controller, Service, Repository를 거쳐 데이터가 흐르는 구조를 반복적으로 구현하고 디버깅하면서, 백엔드 개발은 데이터의 흐름을 설계하는 작업이라는 점을 이해하게 되었다. 또한 처음부터 모든 것을 이해하려 하기보다, 오류를 겪고 하나씩 해결해 나가며 흐름을 연결해 나가는 방식이 효과적이라는 점도 배울 수 있었다.
이번 멘토링을 통해 “동작하는 코드”와 “설명할 수 있는 코드”의 차이를 처음으로 인식하게 되었고, 결과뿐만 아니라 구조와 이유를 함께 설명할 수 있어야 한다는 점을 느꼈다.
이번 Todo 애플리케이션 제작은 단순한 CRUD 구현을 넘어, 백엔드 개발자로서 가져야 할 사고방식과 학습 태도를 정리할 수 있었던 경험이었다. 특히 설계를 먼저 고민하는 습관, 요청 흐름을 따라 문제를 해결하는 방식, 그리고 보안 구조를 이해하려는 노력이 앞으로 더 복잡한 서버 프로젝트를 진행하는 데에 중요한 기반이 될 것이라고 생각한다. 백엔드를 처음 접한 입장에서 기술을 많이 안다기보다, 어떻게 공부하고 어떻게 문제를 마주해야 하는지를 배운 경험이었다는 점에서 의미가 컸다.