[회고] 첫 팀 프로젝트를 마치며

첫 팀 프로젝트를 마치며

첫 팀 프로젝트를 시작하기 전에는 내가 맡은 역할에 맞춰 충분히 공부했다고 생각했고, 어느 정도 자신감도 있었다. 실무에 가까운 구조와 간결한 코드를 목표로 삼고 프로젝트를 시작했다.

 

하지만 실제로 프로젝트를 진행해보니 생각처럼 쉽지 않았다. 처음 진행하는 팀 프로젝트였고, 기능 구현 자체가 막히는 순간도 많았다. 그럴 때마다 조급함이 앞섰고, 설계나 구조를 충분히 고민하기보다 일단 기능을 완성하는 데 집중하게 되었다.

 

그 결과 많은 로직이 컨트롤러에 몰리는 비효율적인 구조가 만들어졌다. 프로젝트를 완성한 뒤 다시 코드를 돌아보니, 내가 직접 작성한 코드임에도 흐름을 한눈에 파악하기 어려웠고 수정하기도 부담스러웠다.

 

팀 프로젝트였기 때문에 팀원의 코드를 이해하고 활용해야 하는 상황도 많았다. 하지만 코드의 의도가 명확하게 드러나지 않거나, 충분한 커뮤니케이션 없이 작성된 코드는 파악하는 데 시간이 오래 걸렸다. 이 경험을 통해 코드 가독성과 협업에서의 커뮤니케이션이 얼마나 중요한지 체감했다.

 

이후 일부 코드를 리팩토링하면서 서비스 레이어를 분리하고, 공통 응답 처리에는 제네릭 와일드카드를 적용해보았다. 로직의 책임이 분리되자 코드의 의도가 더 명확해졌고, 흐름도 훨씬 쉽게 읽혔다. 이 과정에서 코드의 간결함은 단순히 짧게 작성하는 것이 아니라, 가독성과 유지보수성을 높이는 방향이어야 한다는 것을 배웠다.

 

프로젝트를 시작하기 전에는 팀 프로젝트가 끝나면 바로 새로운 개인 프로젝트를 준비할 생각이었다. 하지만 프로젝트를 마친 뒤 생각이 바뀌었다. 무작정 여러 프로젝트를 만드는 것보다, 하나의 프로젝트를 깊이 있게 돌아보고 부족했던 부분을 개선하는 과정이 더 중요하다고 느꼈다.

 

그래서 이 프로젝트를 다시 살펴보며 Spring Boot 기반으로 마이그레이션하고, 기존에 아쉬웠던 구조를 하나씩 개선해보기로 했다. 테스트 코드를 작성해 기존 기능을 검증하고, Spring Security로 인증/인가 구조를 정리하며, 이후 JPA와 Redis 세션, CI/CD까지 단계적으로 적용해볼 계획이다.

 

이번 경험을 통해 기능을 완성하는 것만큼 중요한 것은 유지보수 가능한 구조를 만드는 것이라는 점을 배웠다. 다음 프로젝트에서는 처음부터 관심사의 분리와 코드 가독성을 더 의식하며 개발하고 싶다.