22.01.26 코드스테이츠 4주차 Final Project 회고록

👀  4주차 Final Project 회고록

 

📌  4주차 두 번째 프로젝트의 시작 

 

2주 프로젝트가 끝나고 쉼없이 4주 프로젝트가 시작되었다.

대화를 많이 하고 기획을 꼼꼼히 하기로 다짐했던 만큼 5일의 시간을 들여 계획했다.

 

운 좋게도, 내가 하고싶었던 아이디어로 웹을 만들게 되었다.

아이디어를 간단히 소개하자면 :

 

-> 기획 의도

사진은 생각보다 많은 정보를 담고 있습니다.
"사진을 저장하다 = 추억을 기억한다" 는 의미가 통하는 시대입니다.

갤러리의 수많은 사진들 사이에서 내가 원하는 사진 한장을 찾아 헤매본 적이 있으신가요 ?
정보의 저장은 쉬워졌지만 해당 정보를 제대로 관리할 수 있는 도구는 많지 않습니다.

블로그와 SNS에서 본 사진을 보고 반해 찾아간 장소의 주변에서 놀거리를 찾지 못해 당황한 적이 있으신가요 ?
리뷰의 힘이 커진만큼 계획을 세울 때 참고할 자료들 마저 선별적으로 탐색해야합니다.

사진을 단순히 저장만 하는 것이 아니라, 사진들 간의 연결고리를 만들어 기억을 범주화시키고 싶습니다.
어떤 일을 기억할 때 시간의 흐름을 쫓듯 해당 사진을 찍었던 장소, 거리, 풍경을 매개체로 연결하고자 했습니다.

연결된 사진들을 하나의 스토리카드로 만들고 공유해, 흩어진 자료들을 모아볼 수 있는 효과를 주고 싶었습니다.
이렇게 하나로 묶인 사진과 장소는 사용자로 하여금 장소의 위치를 기준으로 분류된 정보를 볼 수 있게 합니다.

 

-> 기획 방향

- [ 장소 + 해당 장소와 관련된 사진 ] 여러개를 묶어 하나의 카드로 저장하고 관리할 수 있는 웹이다.
- 저장된 카드 중 공유된 카드는 검색을 통해 서치가 가능하다.

 

 

📌  5일간의 기획이 물거품이 될뻔한 사연 

 

Software Requirements 작업을 끝내고 나면 크루 분께 피드백을 받는다.

첫번째 SR 기획에서는 카드를 "저장"하는 기능만 생각했었다.

정직한 기록 웹을 만들고 싶다는 마음이 앞서 ^!^ 하하

 

그런데 크루 분께서

" 사진 기반으로 서비스를 제공하려면 모바일 중심이어야 할까요? PC웹 중심이어야 할까요 ? "

라는 질문을 던지셨다.

머리를 댕 ~ 한 대 맞은 느낌이었다.

반응형 웹을 구현할거니까 앱과 같은 효과를 줄 수 있지 않을까 ? 란 안일한 생각이 문제였다.

정말 사진을 저장하고 기록할거라면 앱을 통한 관리가 훨씬 쉬웠다. -> 카메라가 내장되어있으니까 !!!

 

머릿속이 멍해져서 React-Native 공식 문서를 살펴보기 시작했다.

Android Studio 도 깔고 ... 어느새 앱을 만들기 위한 준비를 하고 있었다 ...

프론트엔드, 백엔드 할 거 없이 나뉘어 새로운 기술 스택을 짧게 공부한 다음 모여서 회의를 진행했다.

 

2 vs 2 로 나뉘었고, 각자의 의견은 이랬다.

 

👍🏻 : 기술의 변화는 빠르다. 일찍 경험해본다 생각하고 도전하는 건 어떨까 ?
     새로운 환경에 자신을 던질 줄 아는 개발자가 성장의 기회도 얻을 수 있지 않나.
👎🏻 : 지금 우리가 구현하려는 기능은 게시판에 입력된 정보를 띄우는 단순한 프로세스가 아니다.
     지도 api도 사용해야하고, DB 스키마도 3중 join이 쓰일 것 같다.
     타입스크립트도 새로 도입하는 입장에서, 기능을 추가해 기획의 방향을 바꾸는 게 맞지 않나.

 

나는 찬성의 입장이었다. 팀원의 지지만 있다면 새로운 기술에 과감히 뛰어들었을거다. 😋 

( 같이 헤매는 과정 .. 매우 즐거워 *^_^* )

그러나 이미 2명의 팀원이 기술 도입을 지양했기에 이 상황에서 도전을 강요하고 싶진 않았다.

오히려 역효과가 날 수 있다는 걸 2주 프로젝트 때 경험했기에 !! 실패를 거름 삼아, 기획을 손보기로 결정했다.

 

이 앱의 강점은 사진과 장소를 함께 묶어 하나의 루트를 만들어 볼 수 있다는 것이다.

이렇게 완성된 루트를 사람들이 볼 수 있게 공개 / 비공개 설정을 사용자에게 부여하면 좋겠다는 생각이 들었다.

루트를 비공개 처리하면 사용자 개인적으로 저장해서 볼 수 있고,

공개 처리하면 다른 사용자가 검색을 통해 해당 루트의 정보를 참고할 수 있게 된다.

데이트 코스, 가족 여행 코스, 여행자 코스 등등 하루의 계획이 궁금한 사람들의 유입을 끌어낼 수 있을 듯 했다. 

 

검색 기능의 추가와 함께 "기록과 검색" 에 초점을 맞춰 새로운 정보를 제공하는 플랫폼으로 기획을 업데이트했다 !!

 

다행이 SR 기획을 잘 마무리했지만 그 과정에서 팀 분위기가 많이 다운되었다.

나로서는 당황한 태를 내지 않기 위해 쉬지 않고 구글링을 했던 것도 있고 .. 🤣

팀장님도 전체적인 기압이 낮은 걸 아셨는지 주말을 재정비 시간으로 두는 거 어떻냐고 제안해주셨다.

주말에 추가된 기능 프로토타입을 짜면서 천천히 기획을 다지고 새로운 마음으로 시작할 수 있었다. : )

 

 

📌  우리팀이 잘한 점 

 

📎  게더 타운에 모여 팀플을 진행하여 소회의를 자주 열었다.

 

변경 사항이나 현재 상황 업데이트 등을 실시간으로 추적할 수 있었다.

식사 시간이나 휴식시간 또한 보고 형식으로 진행해 2주 프로젝트보다 체계적으로 진행하였다.

 

📎  주말 계획을 토요일 오후 1시에 공유하고 월요일 아침에 확인하는 패턴을 유지했다.

 

2주 프로젝트 때는 주말도 평일과 똑같은 스케줄로 진행했다.

전체 계획 자체가 빡빡해서 의도치 않게 쉬는 시간이 삭제 되었었다.

4주 프로젝트에는 이를 보완하기 위해 주말은 자유롭게 보내는 걸로 정했다.

대신, 토요일날 주말 계획을 보고하는 규칙을 만들었다.

( 친구를 만난다거나, 기능을 구현한다든가, 개인 공부를 한다든가 컨텐츠는 자유로움 😉 )

프로젝트의 진척도에 따라 주말을 자유자재로 사용할 수 있어 좋았다. 

 

📎  KPT 회고를 통해 도출된 try 항목들은 팀에 도입하려 애썼다.

 

✔ 여가 시간을 어떻게 보내야하는 지 모르겠다 -> 서로 휴식하는 방법 공유

✔ 점점 거북목이 되어가는 것 같다 -> 팀장님이 2시간에 한번씩 "기지개"라고 채팅 쳐주심

✔ 공식적인 merge time 에 모두가 모이는 건 효율적이지 않다 -> 서로 상관없는 PR은 프론트엔드, 백엔드 나눠 진행

 

일주일에 2번 있는 KPT 회고는 4주간 진행하면서 그 주기가 꽤 빨리 돌아온다는 느낌이 들었다.

새로운 try 항목을 생각해 내기도 힘들었고 .. ㅎ 문제 발생 -> 고칠 방법 루틴이 만들어져야하는데

이런 상황이 발생하기엔 기간이 너무 짧지 않나 ..! 

그럼에도 유지할 항목, 문제인 항목, 시도할 항목을 나눠 진짜 열심히 적었다. : )

 

 

📌  우리팀이 개선할 점 

 

📎  코드 리뷰를 전혀 못했다.

 

백엔드 개발자분들의 nest.js 도입은 꽤 큰 파장을 일으켰다. 데코레이터라는 새로운 문법과 함께

서버쪽 코드를 읽으려면 nest.js부터 공부해야했기에 코드를 리뷰한다거나 수정할 수 있는 권한이 없었다 ㅠ.ㅠ

그게 진짜 아쉽다. 프론트도 타입스트립트 에러 잡으랴 문법 보랴 정신없었으니 누굴 탓할 일은 아니지만,

코드의 질을 생각했을 땐 좋은 방법은 아니었다. ㅠ^ㅠ

 

기능 구현을 하고나서야 눈에 들어오는 "반 모듈화" ... 세상에 😢

컴팩트한 모듈 대신 눈에 들어오는 지저분한 코드들 ,,, 31일까지 리팩토링하며 정리할 계획을 세워뒀다.

PR을 확인하면서 짧게라도 코드에 대한 코멘트를 남겨두는 것이 나중을 위해서라도 좋은 방법인 것 같다.

 

 

📌  개인적인 회고 

 

📎  기술을 "빠르게" 도입하는 것은 중요치 않다. "빠르고 바르게" 도입하는 것이 중요하다.

 

이번에 프론트엔드 담당으로서 Typescript와 React를 기술 스택으로 사용하였다.

React.js 이니 자바스크립트 위에 타입스크립트를 살짝 올렸다고 할 수 있다.

모든 파일이 tsx 형식을 가지고 컴파일되고 있는데 정작 나는 자신있게 타입스크립트 쓸 줄 알아요 ! 말은 못한다.

Redux로 상태 관리할 때 타입을 정의하는 것 말고는 제대로 사용하지 못했기 때문이다.

정석대로라면 HTML Element 와 React Hook ( useState, useEffect, useReducer 등 ), Props

의 타입도 지정해줘야했지만 기능 구현에 쫓겨 넘기는 일이 빈번했다.

 

제대로된 코드를 작성하기 위해서는 새로운 스택을 학습하는 시간이 따로 빠져있어야한다는 걸 느꼈다.

숙지하지 못하고 쓴 언어는 어디에도 영양가가 없음을 깨닫는다 😢

그래도 ,,, 타입스크립트를 쓰며 느낀점은,

루트, 핀, 사진 등등 객체 안의 객체, 여러개의 키와 값을 가진 자료구조를 다루는 우리 프로젝트에서 유용했다.

해당 값은 배열이여야 한다, 문자열이여야한다, console 창에서 확인할 수 있어 에러 핸들링 시간을 단축시켜주었다.

 

아무리 기존 언어와 비슷한 환경을 가지고 있다고 해서 가볍게 여기지 말자.

학습할 시간을 꼭 빼두자 .

 

 

📎  기록의 습관이 중요하다. 기록의 형식은 중요하지 않으나 되도록이면 플랫폼을 이용해 드러내도록 하자.

 

4주 프로젝트를 하며 팀원들끼리 암묵적으로 동의한 약속이 있다.

바로 " Dev-log를 매일 쓰자 " 였다. Dev-log 는 코드를 짠 이후 느낀점, 내일 할 일 등을 정리한 기록장이다.

 

초반에는 ( 모두가 그렇듯 ) 열심히 작성했다. 바쁘지 않았고, 생각할 여유도 있었다.

그러나 코드가 복잡해질수록 프론트 단은 손으로 그려야하는 요소들이 많았고

github에 있는 Dev-log 형식에 맞춰 글을 쓰기 어려워졌다.

분명 내 노트는 빼곡히 정리되어있는데 issue 탭에 Dev-log가 많이 비어있으니 속상하긴 하더라.

 

매일매일 오늘 한 일과 내일 할 일을 적으면서 내가 어디쯤에 있나 위치를 파악할 수 있어 좋았다.

하루도 정리하고 내 머리속도 정리하고. 수기로 작성했던 Dev-log 들은 블로그에 올려놓을 예정이다.

개발자로서가 아니라 그냥 인간으로도 기록과 회고는 성장에 있어 중요한 수단임을 느낀다.

 

 

📌  그래서, 프론트엔드 개발자 ? 

 

7월 중순부터 1월 말까지 약 7개월이라는 시간을 달렸다.

빠른 학습보다 정확한 학습을 추구했던 나에게 코드스테이츠는 도전이었다.

개발자에 대한 열망이 컸기에 이런 선택을 했고, 또 해낼 수 있었다.

 

다시 봐야할 자료들도 많고 더 학습해야할 자료들도 넘쳐난다.

공부에 있어 가졌던 고정관념이 깨지며 새로운 학습 패턴을 만들 수 있었다.

 

✔ 어 ..? 이게 되네 ..? 왜 되지 ?

✔ 내가 알고 있는 선에선 이게 에러의 원인이어야 하는데 아니네 ..? 왜지 ?

✔ 이렇게 구현하고 싶은데 어떤 모듈을 도입해야되지 ..? 이건 뭐가 좋고 뭐가 나쁘지 ?

 

모든 게 "질문"에서 출발하였다. 필요에 의한 질문은 목표를 명확하게 만들었다.

정석대로 chapter 1 부터 chapter 12 까지 순서대로 익혔던 나에겐 신선한 충격이었다.

chapter 5 갔다가 9 갔다가 왔다갔다 하는 거니까 ㅋㅋㅋ

 

이렇게 학습했을 때의 문제점은 체계적이지 않다는 거다.

이를 보완하기 위해 기록을 한다. 블로그든 뭐든. 기록은 남아서 다시 볼 수 있는 기회를 제공하기에

빠른 러닝커브에 따르는 단점을 커버한다.

 

대신, 내 언어로 정리한 글을 써야하기에 처음엔 정말 힘들다.

그러나 스스로 논리의 유무를 판단하는 작업을 계속 하다보니 기준이 생기고 그게 학습의 방향을 결정하더라.

이제 공부 방법을 어렴풋이 익힌 것 같은데, 그래서 나는 개발자인가 ?

 

쉼없이 이력서 작업이 필요하다. 내가 어떤 사람인지 또 증명해야한다.

무언가를 해낸 사람이라는 타이틀을 통해 자신을 믿고 또 도전할 수 있는 용기를 얻었다면 

그걸로 부트 캠프를 졸업한 의의가 있지 않나 싶다.

 

조급해하지말고, 내가 개발을 좋아하는 사람이라는 증거를 차곡차곡 모아갔으면 좋겠다.

모든 기록이 그 사실을 증명할 단서이긴하나 수단에 사로잡혀 목적을 잃지 말자. 

누군가 부탁했을 때 당당히 " 내가 그거 만들어줄게 " 라고 말할 수 있는 개발자가 되자 👌