이번 팀 프로젝트를 통해서 배운 점도 많고 나의 마인드도 성장할 수 있는 계기가 되어서 회고록을 남기려 한다.
1편에서는 프로젝트 과정과 내 감정과 배움을 작성하고
2편에서는 내가 고민 했던 코드들과 직면했던 문제, 해결법에 대해서
작성했다.
프로젝트 소개
우선 프로젝트에 대해서 간략히 소개하자면 사용자가 질문에 대해서 답변을 하면 그 답변 결과를 토대로 주변 음식점을 추천해 주는 서비스이다.
팀은 프론트 엔드 1명, 백엔드 1명, 디자이너 1명, 기획자 1명으로 이뤄졌고 나는 백엔드 개발자로서 10일 동안 프로젝트를 진행하였다.
기술 스택
- Back-end :
Spring bootJPAMy SQLJWT - 공통 협업 도구 :
SlackNotionGithubDiscode
프로젝트 과정
아이디어 선정
각자가 생각하고 있는 아이디어를 우선 얘기하고 그 중에서 투표를 통해 주변 식당을 추천해주는 서비스가 채택되었다. 하지만 기존 서비스가 존재 했고 이와 차별점을 두기 위해 질문과 답변을 통해 주변의 식당을 추천해 주는 서비스로 개발하기로 했다.
기능 정의서 작성
선정된 아이디어에 대해서 큰 틀은 기획자님이 정해 주셨고 세부적인 기능과 서비스에 대한 설계, 전체적인 서비스의 흐름과 구성을 내 의견을 주축으로 다른 팀원들과 소통하면서 작성하였다.
서비스의 내용이 명확하고 세부적으로 분류가 되었고 시간도 크게 절약 했기 때문에 이와 같은 소통 방식에 메리트를 느꼈다.
하지만 프로젝트 막바지에 이르러 위의 소통방식에 대한 문제점을
뼈저리게 느꼈다...
이번 프로젝트에서 내가 크게 실수한게 두개가 있다고 생각하는데 이것이 그 중 첫번째다.
그 이유는 개발 과정에서 설명하겠다.
도메인 분석과 엔티티 설계
기능 정의서를 토대로 도메인 분석과 엔티티 설계를 작업 하고 다른 프론트 개발자님께 전달하고 수정해야될 부분이 없는지 소통하고 개발 과정에 대해서 논의했다.
로그인 기능은 네이버 로그인 API를 사용하고 로그인 과정은 프론트에서 인증을 요청하고 백엔드에서 인가하는 방식으로 구현하기로 정하였다.
그리고 주변 식당을 추천해 주기 위해서 현재 위치를 받아오는 naver GeoLocation API와 음식점을 검색할 수 있는 naver MAP API 를 사용하기로 정했다.
GeoLocation API와 naver MAP API를 백엔드에서 구현하는 것으로 생각했는데 과정을 생각해보니 백엔드에서 구현하는 것 보다 프론트에서 구현하는 것이 더 합리적이라는 생각이 들어서 프론트 개발자님과 논의 후 변경하였다.
프론트에서 구현이 더 합리적이라고 생각한 이유는 백엔드에서 API를 구현한다면 사용자가 선택한 답변 내용을 프론트에서 받아 오고 해당 데이터를 토대로 API를 요청하고 응답된 데이터를 다시 프론트에 넘겨주는 과정이 진행된다.
프론트에서 API를 구현한다면 가지고 있는 데이터로 API를 호출하고 응답 된 데이터를 바로 화면에 보여주면 되기 때문에 통신의 횟수가 3번에서 1번으로 줄게 된다. 또한 답변 내용과 API의 응답 내용은 휘발성 데이터이기 때문에 데이터가 백엔드로 넘어와야할 이유가 없다.
이러한 이유로 프론트에서 해당 API들을 구현하기로 정하였다.
개발
위의 과정까지 4일이 소요 되었다.
프로젝트 종료 시간이 오후 2시였고 내가 개발한 API를 프론트에 연결하고 서비스의 작동까지 확인하려면 하루 정도는 여유일이 있어야 할 것 같아서
실제 개발할 수 있는 시간은 4.5일 정도로 생각하고 개발 하였다.
아쉬웠던 점
- 개발 하는 과정에서 기능을 추가하거나 기존 기능을 약간 변경이 가능하냐는 요청 사항에 나도 프로젝트에 욕심이 나서 "내가 잠 좀 줄이면 되지!" 라는 생각으로 팀원의 의견을 수용하려 했다.
이것이 나의 두 번째 잘못이다...
설계한 엔티티의 구조를 변경해야 되는 요청사항들이 있었는데 이를 수용하다 보니 개발된 API의 내용도 수정해야 하고 연관관계도 변경하게 되면서
시간이 많이 소모 되었다.
내 진행속도가 지체된 만큼 프론트도 지체 되었다.
내가 객관적으로 진행 상황을 인지하고 요구사항을 조율했어야 됐는데 미흡했다.
이후 개발을 하다보니 시간이 부족할 것 같아서 설계를 변경해야 되는 요청사항은 거절하고 기능을 추가하는 변경사항은 MVP를 먼저 개발하고 나서 시간적 여유가 있을 때 추가하기로 결정했다.
이후 개발하면서 가장 애먹은 부분은 CORS 문제와 소셜 로그인 부분이였다.
프론트로부터 code와 state 값을 받는다면 filter와 handler를 이용하여 자동으로 response에 자체 JWT토큰을 헤더에 추가하여 보내려고 하였는데
username을 자꾸 읽어오지 못했다.
그래서 controller와 service를 이용하여 해당 로직을 처리하였다.
CORS도 해결하면 다른 CORS 이슈가 생기고 다시 생기고 해서 고생했다.
이 부분은 2편에서 코드와 함께 다루겠다.
프로젝트 9일차에 접어들었을 때 배포와 DB에 데이터 추가만 남았었다.
배포를 하고나서 CORS문제 때문에 시간이 더 촉박하였는데 DB에 데이터를 추가할 때 문제점이 생겼다.
9일차 저녁에 질문과 답변 데이터를 기획자님으로 부터 받았는데
이럴수가... 기존에 상의하고 정했던 데이터의 구조와 달랐다.
한 질문에는 하나의 카테고리만 들어가고 한 답변에도 하나의 키워드만 들어가는 것으로 정했었다.
하지만 질문에 다수의 카테고리, 답변에도 다수의 키워드가 포함되어 있던 것이다.
나와 기획자님의 관점의 차이로 발생한 문제였다.
나의 관점은 "하나"라는 이 숫자가 중요한 거였지만
기획자님은 질문에 "카테고리"가 들어간다는 것에 포커스를 맞춘것이였다.
이미 모든 것이 개발 됐고 시간이 부족했기 때문에
질문1 - 카테고리 1, 2, 3, 4...9로
되있는 데이터를
질문1 - 카테고리 1, 질문 1 - 카테고리 2 ... 질문 1 - 카테고리9
이런 식으로 분리해서 저장했다.
데이터의 중복성이 존재하지만 시간 관계상 어쩔수 없었다.
왜 이런 문제가 왜 발생했나??
내가 비개발자들도 개발자의 사고방식의 차이를 간과했기에 발생한 문제였다.
이것이 위에서 말했던 나의 첫 번째 실수다.
이게 발생한 문제는 쉽게 해결할 수 있었지만 문제의 원인은 사소한 것이 아니라 생각하여 나의 큰 실수라고 생각한다.
이 일을 계기로 개발자 커뮤니티에서 잘 이해가 안갔던 글이 있었는데 그 글이 완벽히 이해가 갔다.
그 글의 핵심 내용은
"비개발자가 개발자의 사고방식을 이해하는 것이 개발자가 비개발자의 사고방식을 이해하는 것 보다 훨씬 어렵다. 그러므로 개발자의 의사소통 능력이 중요하다"
라는 내용의 글이였다. 링크를 첨부하고 싶은데 못 찾았다..
이후 DB에 데이터를 저장하고 CORS도 해결하고 프로젝트를 성공적으로 끝마쳤다.
코드에 대한 회고록은 아래 링크에 정리하였다.
내가 고민했던 부분, 직면했던 오류들에 대한 해결방안을 위주로 작성하였다.
https://velog.io/@pju114/%ED%8C%80-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%ED%9A%8C%EA%B3%A0%EB%A1%9D%EC%BD%94%EB%93%9C
후기
우여곡절 끝에 프로젝트를 완성하였고 그 날은 못 잤던 잠을 몰아서 잤다.
매일 개발시간을 체크하였는데 알바를 하는 날에는 약 9시간, 아닌 날에는
15시간 정도 개발하였고 프로젝트 마지막날에는 밤을 샜다.
이렇다 보니 프로젝트를 기간 동안 평균 5시간 정도 잤다.
하지만 막상 프로젝트를 할 때는 힘듦을 몰랐다.
이 프로젝트에 대한 책임감 때문에 어떻게든 완성하려고 노력한 것도 있지만
내가 프로젝트를 하는 것 자체가 재밌었기에 힘든 것을 모르지 않았나 싶다.
개발을 하면서 오류를 직면하여 화날 때도 있고 능력부족을 체감하며 좌절할 때도 있었다.
하지만 결국 해결하면서 고통이 기쁨으로 변하고 문제를 해결했다는
성취감은 "이 맛에 코딩하지!!" 라는 생각이 절로 들게 한다.
그래서 이번 프로젝트를 통해서 내가 개발자를 하고 싶어하는 이유를 다시 한번 상기 하였고 기술적인 성장 말고도 책임감, 의사소통 등 나의 개발자 마인드도 성장하는 계기가 되었기 때문에 너무 뜻 깊은 프로젝트였다.
