2024 KUIT 프로젝트 회고

0. KUIT

동아리 프로젝트를 진행하였다. 팀원은 10명으로 PM, 디자이너, FE, BE 으로 이루어져 있었고, BE가 4명으로 가장 많았다. BE를 파트장을 맡게 되었는데, 팀원들을 이끌어 보는 적이 많지 않았기 때문에 원할한 협업을 하기 위해 노력했다. 기존에 해봤던 개발에 SSR이 였기 때문에 프론트과 소통할 수 있는 좋은 기회였다.

1. 기획

팀에 합류하여 처음 했던 것은 기획에 대한 전반적이 설명을 들었다. 기획을 PM이 이미 정하고 UI/UX도 어느정도 나온 상태이기 때문에, 만약 기획적으로 변경해야할 부분이 있다면 최대한 기획의 큰 틀에서 벗어나지 않는 선에서 해야했다.

회의간에 이야기했던 내용은 대부분 두가지였다.

• 해당 기능이 있는 이유가 뭔가요? (의도 파악)
• 해당 기능을 이렇게 구현하려고 하는 이유가 뭔가요? (의도는 파악되었지만, 구현 상태에 대해 질문)
• 해당 상황에서 해당 기능을 사용하면 어떻게 되야 할까요? (UI나 기획에서 확인되지 않는 예외상황에 대한 질문)

이러고 싶지 않았다...

일단 나는 PM의 의견을 최대한 반영하고 싶었다. 기획자에가 보는 시선과 개발자가 보는 시선은 다르기 때문에 사소한 기능이라도 기획자가 어느정도 납득되는 이유를 제시한다면 그렇게 구현하는게 맞다고 생각한다. 개발자들끼리 프로젝트를 하다보면 특정 기능에 대해서 기획이나 유저 관점을 생각하지 않고 최대한 편한 방식으로 구현하게 되는 경우("타협" 이라고 한다)가 있는데, 이러한 자세를 최대한 지양하고 싶었던 것도 있다.(그러나 나중에는 나는 안 된다는 개발자가 되었다)

---

2. 개발 환경 구축

개발을 시작하기 전에 개발 환경을 먼저 구축해야 했다. 

스프링 프로젝트 생성

이때까지 계층형으로 디렉토리를 관리하는 방식으로 스프링 프로젝트를 진행하였는데, 도메인형 디렉토리로 관리하는 방식으로 진행하고 싶었다.

가장 큰이유는 기존 계층형으로 작업하는 경우에는 여러 클래스가 하나 디렉토리에 존재하여 관리하기가 어렵고, 가독성이 떨어졌던 것에 비해 도메인형으로 작업하는 경우 헷갈릴 필요없이 작업할 수 있었다.

특히 여러명이 동시에 작업하는 경우, 도메인 별로 따로 작업하면 더 협업하기 쉬웠다.

한가지 단점은 작성해야할 코드가 살짝 증가하였는데, 불편할 정도는 아니였다.

https://velog.io/@jsb100800/Spring-boot-directory-package

[Spring boot] 디렉터리 패키지 구조의 선택

이외에도 global 설정인 exception handler와 같은 전역 설정은 스프링 공부할때 참고하였던 playkuround와 쿠링을 참고하였다. 

https://github.com/playkuround

Playkuround

 

https://github.com/ku-ring

쿠링

배포 설정

배포 설정 관련하여 포스팅을 작성하여, 해당 포스팅으로 내용으로 대체한다.

https://bluesparrow.tistory.com/69

CI/CD 구축 (github action+Spring boot + mysql + docker-compose) (1)

https://bluesparrow.tistory.com/70

CI/CD 구축 (github action+Spring boot + mysql + docker-compose) (2)

---

3. 개발

각자 맡은 부분에 대해서 개발을 진행했다. 내가 맡은 부분은 지도 식당 검색과 커뮤니티로 상대적으로 후순위인 커뮤니티보다 지도 식당 검색을 먼저 개발했다.

실제로 기획에서 수정없는 완벽한 설계를 하는 것은 상당히 어렵기 때문에 중간에 의논할 만한 내용이 있다면 의논후 내용을 변경하기도 했다. 개발을 시작하면서 다음과 같은 여러 문제가 있었다.

API의 변경

대부분 9할은 이문제에서 시작되는데, 개발하기 전에 정한 API명세서에 수정이 필요한 경우이다.필요한 이유는 다음 중 하나였다.

• API에 특정 필드가 없는 경우(가게이름을 조회하는데 가게이름이 없는경우)
• API를 추가해야하는 경우 (히스토리를 추적해야 하거나, 추가 기능이 필요한 경우)
• API가 너무 억지스러운 상황 (로직이 BE나 FE에게 알맞지 않은 경우, 기능을 구현하는데 문제가 없지만 설계상 변경을 하면 좋겠는 상황)

API명세서를 BE에서 대부분 만들었기 때문에 FE간 연결간에 API가 변경되는 경우가 많았다.(API 명세서는 반드시 리뷰를 해야함을 느꼈다.) dummyAPI를 만들어 놓았기 때문에 FE에서 최대한 변경이 일어나지 않는것이 좋다고 생각하였는데, 너무 API가 억지스러운 것도 변경했다.

기획 변경

기획에서는 큰 문제가 없어보였는데 개발중 기획적으로 의논해볼 것도 있었다. 유저한테 어느정도 자유성을 줄것인가와 같이 API에 직접적으로 영향을 주었기 때문에 이경우 다시 논의하였다.

소통중 잘못된 이해

가장 큰 문제로 기획과 개발자 사이나 FE와 BE 사이에 소통을 하지 못한 부분이나 소통을 했지만 서로 다르게 이해한 부분이 나중에 큰 문제로 이어지는 경우가 있었다. BE에서는 DB를 변경하는 경우가 있었는데 다대일에서 다대다로 연관관계를 수정해야하는 상황이 발생했다. ERD는 확실하게 확인하고 작성하였는데도 이러한 문제가 발생하였다는 점에서 개발 문서 작성이 얼마나 중요한지 느꼈다.(개발자나 기획자가 공유하는 기능 문서) 특히나 BE에서 API를 UI를 보고 설계하였는데, UI가 변경되는 경우에 API에 영향을 주는 경우가 많아서 API를 데이터 관점에서 만들어야하는데 사용자 관점에서 만들어야 하는지 생각해보게 되었다.

---

3. 데모데이

데모데이까지 최대한 기능을 구현한 형태로 데모데이에 들어갔다.

다른 조 대부분이 완성도가 뛰어난지라 걱정하면서 데모데이 시간을 보냈다.

운좋게 우수상을 받아서 좋았다. 그간 고생했던게 해소되는 느낌이였다. 특히 프론트인원이 적어서 프론트분들이 고생을 많이 했었다. 백엔드도 개발중 변경되는 요구사항이 좀 많았는데 다들 유연하게 대처해줘서 고마웠다.

---

4. 개선해야 할 부분

프로젝트를 진행하면서 잘된 부분도 있고 그렇지 않는 부분도 있는 이후에 협업을 할때 주의해야 할 부분을 생각해봤다.

• API 명세서를 작성하고 반드시 FE,BE에게 리뷰를 자세히 해야한다.
• 기획과 관련된 개발 문서를 작성해야한다.(적어도 BE 입장에서 이해할 수 있고, 헷갈리지 않는 문서가 필요하다.)
• 개발전 컨벤션에 대한 논의가 필요하다.(특히 변수명에 대해)
• API를 작성함에 있어서 API가 데이터중심과 API 기능 중심중 어느 쪽에 더 부합하는지 의논해야한다.
• 구현이 불가능한 기능에 대해서 근거를 논리적으로 이야기해야한다.
• 개발보다 소통 중심으로 협업을 진행해야한다.

짧게 작성하였는데 각각 프로젝트를 진행하면서 문제되는 발화점을 제공하는 순간이 였다. 한문장으로 요약하면 마지막 줄 "소통 중심의 협업"을 지향해야한다. 

역시 유튜브나 포스팅을 보는 것보다 직접 협업을 해보니 많을 것을 배울 수 있었다.