코드스테이츠 파이널 프로젝트 회고

배포 링크

깃헙 링크

소개 링크

 

마지막 프로젝트가 끝났다😭😭😭

2주 프로젝트보다 만족한 점들도 있지만, 또 아쉬웠던 점들도 많았다. 4주 간 진행하며 이번에도 많은 것들을 배울 수 있었으며 이를 정리하는 시간을 가져보려 한다!!!

 

Scraplan(스크랩플랜)이란?

---

우리 팀의 프로젝트 주제는 지도를 기반으로 해당 장소의 다양한 즐길거리를 큐레이션 형식으로 제공하고, 해당 큐레이션을 이용해 나만의 일정을 편리하게 관리할 수 있는 서비스다. (plan을 scrap 하세요~!)

 

비회원은 다른 사람의 일정을 구경, 카카오톡으로 공유, 일정을 직접 만들어볼 수도 있다. 거의 대부분의 기능을 사용할 수 있다!! 하지만 저장을 하려면 회원가입을 하도록 유도했다. 후후..

 

실제 프로젝트 결과들을 보자면 우선 메인페이지에서는 서비스(프로젝트)에 대한 간략한 설명을 해준다. 포토샵을 잘 다루시는 팀원 덕분에 깔끔하고 이쁜 이미지들을 사용할 수 있었다..! 여기서 내가 구현한 것은 스크롤에 따른 이벤트, 애니메이션 효과다. 추가로 반응형도 된다!

 

 

 

로그인과 회원가입은 2주 프로젝트 때에는 페이지로 만들었다면, 이번엔 모달 형태로 구현했다. 유효성 검사와 구글은 기본!

 

이제 중요한 일정 관리 페이지로 이동해보자!

사용자를 위해 사용방법을 알려주는 튜토리얼도 마련했다! 스크랩플랜에 들어오시면 보실 수 있어요~!

 

아래 사진을 보면 왼쪽은 마커를 클릭하면 그 장소의 추천 일정들을 보여주는 리스트고, 오른쪽은 직접 일정을 관리하는 리스트다. 일정을 직접 Drag & Drop으로 시간과 순서를 편하게 조절할 수 있다! 지도와 마커는 KakaoMap API를 사용했다. API 문서가 잘 설명되어 있지만 (또 다른) 예상치 못한 오류들이 발생했기에 꼭 회고에 적고자 마음을 먹었다. 

또한 일정을 추가하면 어떤 경로로 이동하는지 실시간으로 보여주도록 구현했다. 

이 외에도 다양한 기능들이 있다. 왼쪽 상단을 보면 3가지 버튼이 나열되어 있는데 이를 순서대로 설명하자면 다음과 같다.

1. 추천 마커가 거슬리다면? -> 내 일정만 보기 / 전체 보기

2. 나만 아는 장소를 추천하고 싶다? -> 큐레이션 추천하기

3. 난 카페(식사, 놀거리 등..)만 추천 받고 싶다? -> 테마별 선택

 

주요 기능은 여기까지만 적도록 하고, 더욱 자세한 내용은 소개 링크 에 정리를 잘 해놨습니다! 지금부터 4주간 프로젝트를 진행해온 과정을 정리해보고자 한다.

 

프로젝트 진행

---

SR 단계

2주 프로젝트를 진행할 땐 아이디어 기획 단계부터 전부 줌으로 진행했었다. 그러다보니 프로젝트를 진행하면서 같은 기능에 대해 서로 다르게 이해했던 부분이 몇몇 있었다. 파이널 프로젝트인 만큼 이러한 부분을 최소화하기 위해 서울에 갔다!? 사실 결론부터 말하자면 이번 프로젝트를 진행하면서도 조금씩 오해들이 생겼었지만 한편으로는 직접 만나지 않았더라면...! 하는 생각이 들곤 했다.

 

팀원 분들이 전부 서울에 거주하고 계시고 울산에 살고 있는 나는 퍼스트 프로젝트를 할 때 '파이널때는 꼭 서울가겠습니다!' 라고 몇 번은 얘기했었다. 그리고 정말로 서울에 와서 팀원분들과 약 4일간 아이디어 회의를 진행했다. 그리하여 사용자에게 장소에 따른 추천 일정을 제공하고, 사용자는 편하게 일정을 관리할 수 있는 서비스를 만들자는 아이디어가 나왔고, 와이어프레임, 워크플로우를 함께 작성할 수 있었다.

간략하게 짜본 와이어 프레임, 더 자세한 와이어 프레임은 화질상 문제로 패스!

플로우 차트

 

사용 스택 선정 및 개발

이번 프로젝트에서는 기존에 사용했던 React, Redux에 추가로 TypeScript, KakaoMap API를 사용했다.

 

TypeScript

타입스크립트는 퍼스트 프로젝트때부터 팀원들과 이야기를 하면서 파이널 때는 꼭 사용하자! 라고 했었다. 처음엔 단순히 요즘 유행하는 언어다! 라고만 알았었다. 하지만 아이디어 선정 기간동안 타입스크립트 공부를 겸했는데, 조금이나마 왜 타입스크립트가 대세인지 알 듯 했다. javascript는 사용하기에 매우 편하지만 그만큼 엄격하지 않아 어디서 오류가 발생했는지 항상 찾기가 어려웠었다. 하지만 typescript는 정적 타입을 지원하므로 컴파일 단계에서부터 에러가 발생하기 때문에, 보다 빠르게 에러를 발견하고 해결할 수 있었다.

또한 서버나 외부 API를 통해 받아온 데이터들에 타입을 지정해 타입에 의한 오류를 방지하고, 팀원들과 협업을 하며 변수명 뿐아니라 데이터 타입도 참고할 수 있어서 파악을 하는 데 시간을 많이 낭비할 필요가 없었다.

물론 자세한 공부를 하지않아 조금 어렵다 싶은 것들은 any로 우선 진행했다.. 이는 타입스크립트를 사용하는 의미가 없다고 생각을 했고, 팀원들과 리팩토링을 진행하기로 했다! (추가로 데이터 구조를 처음부터 다시 짜보기로..!)

 

KakaoMap API

카카오맵 API는 장소나 특정 이름의 가게를 검색하면, 그 위치를 얻기 위해 사용했다. 또한 시각화를 위해 가이드를 보며 마커, 오버레이, 인포윈도우 등을 사용하고 직접 커스텀하기도 했다.

 

앞서 말했던 오류를 여기서 정리해보고자 한다. 지나고보니 조금만 생각해보면 정말 간단한 이유인데 그 당시에는 생각이 안나 시간을 꽤 잡아먹었다... 팀원분이 지도를 띄우고 지도가 이동, 줌인아웃이 될 때 새로운 요청을 보내는 코드를 작성해놓으셨다. 그리고 내가 맡은 부분은 일정에 맞춰 마커, 경로 생성 이벤트를 구현하는 것이었다. 이때, 팀원분이 작성하신 코드(지도 생성)는 하나의 함수로써 처음 렌더링이 될 때 사용하기 위해 useEffect에서 호출하고, 의존성 배열에 위치, 줌인아웃과 관련된 변수를 넣어 새로 렌더링 되도록 했었다.

 

처음에 단순히 팀원분이 작성하신 코드안에 마커, 경로 생성 이벤트를 넣고 앞서 말한 useEffect 의존성 배열에 마커, 경로 관련 변수를 넣고 실행을 해보았다. 잘 작동되는가 싶더만 어느 순간 지도가 엄청나게 렉이 걸렸었다...? 이렇게 적어보니 정말 단순한 이유로 인해 생긴 문제인데 진짜 프로젝트를 할 땐 왜이렇게 바로바로 생각이 안났는지ㅠㅠ 사실 맵을 생성하는 코드가 의존성배열안에 있는 변수에 따라 계속 실행이 되어 맵이 중첩이 된 것이었다!

 

원인을 알고나서 코드를 분리했고, 공식문서에는 생성했던 마커, 경로 등을 제거해야한다는 직접적인 언급은 없었지만, 개발자창을 확인해본 결과 한번 생성된 것들이 사라지지 않는 것을 확인했다. 그래서 이벤트에 따라 생성된 것들(맵 제외)을 전부 사전에 제거해주고 다시 생성 및 렌더링 해주도록 코드를 수정하니 다행히 정상적으로 작동했다.

 

프로젝트 후기

---

1달간의 프로젝트를 진행하며 발생했던 오류, 느낀 점, 공부해야 할 것들을 생각날 때마다 A4용지에 휘갈겨 적었는데 진짜 수십장은 되는 것 같다. 그만큼 배운 것들이 많은 프로젝트였다. 회고글을 적으며 꼭 정리를 하고자 했는데 그게 바로 지금인 것 같다!

태스크 분배의 중요성

이전 프로젝트에서는 명확한 태스크없이 단순히 한 컴포넌트, 페이지 단위로 개발을 했었다. 그러다보니 얼마가 걸릴지도 모르고 연관된 것들이 개발이 안 된 상태라면 중단된 상태로 다른 것을 우선적으로 처리했었다. 이를 개선해보고자 이번 프로젝트에서는 개발을 시작하기 전 깃헙을 활용했다. 프로젝트를 마일스톤 단위로 나누고, 이를 또 태스크 단위로 나누어 이슈카드를 만들어 분배했다. 

 

확실히 자신이 어느 부분을 개발해야 할 지 명확했고, 추후에 오류가 발생했을 때 그 부분을 맡은 팀원이 해결해나감으로써 수월했다. 하지만 아쉬웠던 점은 좀 더 세부적으로 생각하지 못해 시간관리를 제대로 하지 못했던 점이었다. 물론 나의 실력과 집중력이 부족했기 때문이다. 맡은 것에 집중을 해나갔으면 됐을텐데, 자꾸 연관된 다른 컴포넌트, 기능들을 건드리게 되고 궁금한 것들이 많아졌었다. 이를 극복하기 위해 다시 맡은 이슈카드(태스크)에 먼저 내가 구현해야 될 것들을 상세히 리스트화 시켰고, 하나 둘씩 완료해나갔다. 그러다보니 하나씩 성취해나가는 느낌?이 들어 좀 더 집중을 할 수 있었던 것 같다.

협업에서 소통의 중요성

팀 단위의 협업에서 소통은 항상 강조해도 과하지 않은 것 같다. 2주 프로젝트 때 느꼈던 점이 같이 회의를 하며 기능에 대해 이야기를 나눴어도 각자 생각하고 있는 것이 다르다는 것이었다. 그래서 이번 프로젝트에선 이러한 부분들을 최소화하기 위해 서울에 가서 이야기를 하기도 했다. 그럼에도 서로 간의 오해들이 발생했다. 4일이라는 기간 동안 주제, 기능에 대해서만 이야기 했지만 중요한 건 시간이 아니라 효율적인 대화였다. 개발자로써 같은 기능에 대해 다르게 생각한다는 것은 참으로 문제가 아닐 수 없다. 사실 효율적인 대화는 그만큼 의식을 하고 많이 해봐야 기를 수 있는 역량이라고 생각한다. 앞으로의 프로젝트 혹은 개발자로써 협업을 진행하며 항상 곱씹으며 노력할 것이다.

나의 상황을 명확히 말하자

우리 팀은 매일 아침 10시, 오후 5시, 저녁 11시에 1시간 씩 각자의 이슈, 진행상황을 공유했다. 많다고 느껴질 수 있지만 서로에게 도움이 되는 시간이라 생각하는 것에 다들 공유를 했었다. 하지만 프로젝트 초기, 공유를 하던 나의 모습을 바꾸고자 노력했다. 아직도 나는 못한다, 모른다를 부끄러워 하는 것 같았다. 아침 공유시간에 태스크를 맡아 호기롭게 OO시 전엔 끝내겠습니다! 라고 해놓고 다음 공유 시간에는 '죄송합니다.. 얼른 끝내보겠습니다..'라고 한게 다였다. 즉 이건 올바른 공유가 아닌 선언이라고 생각이 들었다. 물론 내가 해결하지 못한 것들을 팀원들의 시간을 뺐어가며 해결하긴 싫었다.

 

하지만 시간 내로 끝내고 맡아야 할 다음 태스크들이 팀원에게 넘어가는 느낌이 들었다. 즉, 피해를 입히기 싫었던 마음이 오히려 더욱 피해를 입히는 것 같았다. 그래서 말하는 방식을 바꿔보기로 했다. 단순히 못했다가 끝이 아닌, 나의 상황을 명확히 전달하려고 노력했다. 현재 내가 맡고 있는 부분은 이러이러한데, 어떤 부분이 막혀 곤란함을 겪고 있다 혹은 나는 이렇게 구현해보려고 하는 데 다른 좋은 방법이 있을까요? 등. 그럴때마다 팀원분들은 감사하게도 본인들의 생각과 의견을 말씀해주셨다. 도중에 이해가 되지 않았던 것들은 다시 여쭤보고 정확히 이해를 한 후 코드를 다시 쳐보니 술술 진행이 되었다! 협업에 있어서 일방적인 대화는 올바르지 않다고 생각이 든다. 그만큼 상대방의 의견과 상황을 적극적으로 수용하고, 나 또한 나의 상황을 명확히 말하며 올바른 대화를 위해 노력할 것이다. 

개발적인 부분

• 내 코드를 남이 봤을 때 이해하기 쉬운가? 생각하기
• 단순히 기능 뿐 아니라, 서버와 연결했을 때 어떤 상황이 발생할 지 고려하기
• State관리를 잘하자...!
• 코드가 길어지면 내가 뭘 하고 있는지 헷갈린다 -> 세분화를 통해 한 가지에 몰두하자
• 공식 문서를 자세히 읽어보자
• 새로운 기술을 많이 배우고 싶다. 하지만 기본기를 탄탄히 하자
• 너무 재밌다~
• 끊임없이 올바른 코드를 작성하고 있는지 생각해보자 + 피드백을 받고 싶다

 

마무리

---

좋은 팀원들 덕분에 무사히 프로젝트를 마칠 수 있었다. 배운 점, 느낀 점도 정말 많다. 그리고 코드스테이츠에서의 공부는 끝이다. 5달 간 쉬지 않고 달려온 나를 칭찬하지만 아직 부족한 부분이 너무 많다는 생각이 든다. 그만큼 앞으로도 쉬지 않고 더 달려야 할 것이다. 이제 프론트엔드 개발자로써 단순히 코드만 치는 것이 아닌 스스로 생각할 줄 아는, 성장할 줄 아는 개발자가 되기 위해 끊임없이 고민하고 공부하고 노력할 것이다!!