[내일배움캠프_사전캠프_8기]_Days_19 TIL_ 팀 프로젝트-발표

발표회를 통해 배운 점

프로젝트 발표회를 들으며 구현한 기능 만을 소개하는 것이 아니라, 같은 기술이라도 전달하는 방식과 문제를 설명하는 흐름이 프로젝트의 완성도를 크게 높여준다는 점을 느꼈다.

 

특히 인상 깊었던 점은 대부분의 팀이 단순히 "무엇을 구현했다"가 아니라 "왜 이런 기술을 선택했고, 어떤 문제를 해결하기 위해 적용했는지"를 중심으로 발표를 구성했다는 것이다.

 

예를 들어 QueryDSL을 사용한 팀은 "검색 기능을 구현했다"에서 끝나지 않고, 기존 JPQL 방식에서 문자열 기반 쿼리의 한계와 유지보수 문제를 설명한 뒤 QueryDSL을 적용한 이유와 기대 효과까지 자연스럽게 이어서 설명했다.

 

기술을 적용한 배경과 선택 이유를 함께 설명하는 방식이 훨씬 설득력 있게 느껴졌다.

 

아키텍처를 소개할 때도 클라이언트의 요청이 서버를 거쳐 데이터베이스까지 어떻게 흐르는지를 시나리오 형태로 설명하는 팀이 많았다.

 

요청 처리 흐름을 먼저 이해시키고 이후 세부 기술을 설명하니 발표 내용이 훨씬 이해하기 쉬웠다.

 

트러블슈팅 역시 인상적이었다. 대부분의 팀이 문제 → 원인 → 해결 → 결과의 순서로 발표를 진행했고, 끝나고 진행해주는 튜터님의 피드백에서 문제를 해결했다는 것에서 끝나는 것이 아니라 왜 그런 설계를 선택했는지, 다른 방법과 비교했을 때 어떤 장점이 있었는지까지 함께 설명해주셨다. 이러한 발표 방식은 듣는 사람 입장에서도 기술을 이해하기 쉬웠고, 발표의 흐름도 훨씬 자연스러웠다.

 

아키텍처 다이어그램을 먼저 보여주며 전체 구조를 이해시킨 뒤 각 기술의 역할을 설명하는 발표가 많았다. 사용자의 요청이 어떤 경로를 거쳐 서버에서 처리되는지, 어떤 이유로 해당 기술을 선택했는지를 함께 설명하니 프로젝트를 처음 접하는 사람도 전체 구조를 쉽게 이해할 수 있었다.

특히 한 팀은 아키텍처 다이어그램을 거의 사용하지 않고, 클라이언트의 요청이 JWT 필터를 거쳐 Controller, Service, Repository, DB까지 이동하는 데이터 흐름(Request Flow) 을 중심으로 발표를 진행했다.

 

Client
   ↓
JWT Filter
   ↓
Controller
   ↓
Service
   ↓
Repository
   ↓
Database

 

세부적인 코드 흐름을 따라가며 요청이 어떻게 처리되는지 설명하다 보니 발표 시간이 대부분 여기에 사용되었지만, 오히려 그만큼 자신이 작성한 코드의 동작 원리를 깊이 이해하고 있다는 것이 느껴졌다."데이터가 왜 이런 순서로 이동하는지"를 자연스럽게 설명하는 모습이 매우 인상적이었다.

 

본인도 저런 설명으로 다음 팀 프로젝트에서 발표를 진행해보고싶다고 느꼇고 한단계 더 좋은 기술적 설명에 대해 배웠다고 생각한다.

이러한 발표를 보며 코드를 잘 작성하는 것만큼 자신의 설계를 논리적으로 설명하는 능력도 개발자의 중요한 역량이라는 점을 다시 한번 느꼈다.

 

발표를 듣는 입장에서도 기능 설명보다 전체 흐름을 먼저 이해할 수 있었고, 기술이 프로젝트 안에서 어떤 역할을 하는지 훨씬 쉽게 이해할 수 있었다. 개인적으로도 이런 발표 방식이 상당히 세련되고 진정성이 느껴지는 발표라고 생각했다.

 

발표를 들으며 QueryDSL의 장점도 새롭게 알게 되었다. 프로젝트에서는 사용하지 않았지만, QueryDSL은 문자열 기반 JPQL과 달리 자바 코드 기반으로 작성되어 컴파일 시점에 오류를 확인할 수 있고, IDE 자동완성과 리팩터링 지원을 받을 수 있다는 점, 기존 방식은 문자열로 JPQL방식을 사용하지만 이 QueryDSL방식은 동적으로 작성할수있기때문에 동적 검색 조건이나 Fetch Join, Left Join과 같은 복잡한 조회를 훨씬 깔끔하게 작성할 수 있다는 점에서 다음 프로젝트에서는 직접 적용해 보고 싶다는 생각이 들었다.

 

이번 발표회를 통해 다양한 팀의 프로젝트를 보며 "이런 방식으로도 설계할 수 있구나", "이렇게 설명하면 전달력이 높아지는구나"라는 점을 많이 배울 수 있었다. 앞으로는 프로젝트를 진행할 때 단순히 기능 구현에만 집중하기보다 기술을 선택한 이유와 설계 의도를 함께 고민하고 기록하는 습관과 데이터흐름을 시나리오를 작성하는 습관을 가져야겠다고 느꼈다.

 

또한 발표를 준비할 때도 구현 내용을 나열하기보다, 문제 해결 과정과 기술 선택의 배경을 중심으로 설명하는 발표를 준비해 보고 싶다.