파이널 프로젝트(Fessport) 및 기술 스택 회고록

 - 간략하게 기능 리뷰를 별도로 작성하였으며, 프로젝트 및 기술 스택에 대한 회고록을 시작해보겠습니다.

1. 기획

1-1. Fessport?

Fessport Logo

Fessport Preview

  - 파이널 프로젝트 Fessport는 Festival과 Passport의 합성어로, 전 세계 뮤직 페스티벌 정보를 한 곳에서 제공하면서 게임성과 커뮤니티성을 덧붙인 서비스이다. 세계여행을 하면서 여러 해외 페스티벌을 다녔던 경험이 있다. 당시 해외 페스티벌 정보를 구하기란 여간 쉬운 일이 아니었으며, 매진된 티켓이나 동행을 구하는 것은 더욱 어려운 일이었다. 이와 같이 불편했던 경험을 토대로 Fessport라는 서비스의 아이디어와 기획이 나올 수 있었다.

 - 이와는 반대로 세계여행을 하면서 비자 사증도장 모으는(포켓몬 도감 모으듯이) 재미가 꽤나 컸다. 근래에는 나이키 러닝 앱에서 일정 기록을 달성하면 챌린지, 트로피 등을 모으는 재미에 푹 빠져있었다. 이와 같이 일상에서 느끼는 재미요소를 가져와 페스티벌 'Collector', 'Challenge' 기능까지 기획하게되었다. 이로써 단순 정보 제공을 넘어 게임성 요소까지 심을 수 있었다.

 - 이번에는 팀장이 아닌 팀원으로 참여하게 되었지만, 프로젝트 주제가 내 아이디어로 채택되다 보니 이따끔 팀장 코스프레를 한 것 같기도 하다. 포트폴리오상 프론트엔드는 나 혼자 담당하게 되었고, 백엔드는 2분이 담당하였다. 서비스상 아직 부족한 부분이 많지만, 4주 동안 함께 고생한 팀원들에게 진심으로 고맙다.

 - 처음 서비스 기획하고 설계할 때, 실제 서비스 상용화보다는 포트폴리오성에 중점을 잡기로 하였다. 그래서 TypeScript, React-Hooks, Redux, Redux-Saga 등 새로운 스택을 잔뜩 배우고 활용하였다. 주니어 개발자 기술 스택이 그렇듯이 "굳이" 안 써도 구현이야 되겠지만, 이를 활용함으로써 코드와 로직이 정말 강력해질 수 있었다. (물론 이를 위한 공부와 많은 시간, 시행착오를 감내해야했다.)

 

2. 설계

2-1. Prototype & Wireframe, Flowchart, DB schema, API

 - 2주 프로젝트 경험을 교훈 삼아 파이널 프로젝트에서는 기획과 설계를 최대한 추후 수정되지 않도록 했다. 그러다보니 약 10일이라는 예상보다 긴 시간이 소요되였다. 4주라는 기간을 넉넉하다고 생각했던 분위기가 있었던 듯 싶다. 실질적으로 새로운 스택을 공부하고 개발하고 배포까지 약 20일이라는 시간밖에 없었다는 게 버거웠다.

 - 각각 맡은 분야에 상관 없이 프로토타입 및 와이어프레임, 플로우차트, DB 모델링 스키마, API까지 팀원 다 같이 진행할 수 있었다. Figma, Miro, DBdiagram, Gitbook 등 유명한 협업툴을 활용하였으며, 다 2주 프로젝트 때 활용했던 것들이라 어려움 없이 사용할 수 있었다. 일단 최대한 수정이 안될 수 있도록 설계를 하였지만, 개발을 진행하면서 수정해야 할 부분들이 상당수 생기기는 건 어쩔 수 없었다.

 - 예상보다 DB 모델링 스키마와 API가 많이 나오고 복잡했었다. 개인적으로는 더 쪼게서, 딱딱 나눠지는 무결성의 그럴싸한 RDMS을 만들고 싶었지만, 4주라는 짧은기간이었기에 이 정도로만으로 충분히 만족스럽다.

 - 디자이너가 별도로 없는 관계로 UX/UI는 국룰과 레퍼런스 자료를 모아서 참고하는 방향으로 가기로 했다. 이때, 프론트엔드 레퍼런스 사이트들을 많이 찾아볼 수 있었다. 세상에는 엄청난 디자이너와 프론트엔드 개발자가 넘쳐났으며, 좀 더 공부하고, 좀 더 잘 하고 싶다는 동기부여가 폭풍처럼 휘몰아쳤다. (동기부여가 죽은 주니어 개발자 여러분, 롤모델이 될 만한 개발자와 레퍼런스를 찾아보세요!)

DB 스키마 (DBdiagram)

프로토타입 및 와이어프레임 (Figma)

차트플로우 (Miro)

API (Gitbook)

 

3. 기술 스택

3-1. TypeScript

 - 처음 타입스크립트에 관심을 갖게된 계기는 요즘 '핫하다'는 얘기 덕분이었다. 그리고 실제로 공부하고 활용해보니, 왜 인기가 있는지 이해할 수 있었다. (물론 이 부분은 아직까지 논란거리이기도 하다.) C++로 처음 프로그래밍 공부를 시작하였기에 자바스크립트에는 데이터 타입이 없다는 것 자체가 특이하면서도 한편으로 편하게 다가왔다. 그리고 타입스크립트를 "그냥 자바스크립트에서 데이터 타입 지정해주는거네"라고 단순하게 생각했었고, 이는 엄청난 고생 길의 시작이 되었다.

 

* 동적 타이핑? 정적 타이핑?

 - 동적 타이핑과 정적 타이핑의 각각 장단점은 존재하기에 타입스크립트의 생산성 이슈는 아직도 팽배한 듯 싶다. MPA가 아닌 SPA라 할지어도 본 프로젝트와 같이 소규모에 빠르게 진행되고 추후 유지보수가 없을 프로젝트에서는 정적 타이핑이 적합하지 않을 수 있다. 하지만 다수의 개발자가 참여하고, 장기적으로 유지보수가 필요한 서비스의 경우 정적 타이핑이 더 적합할 수도 있다. 즉, 취업을 위한 포트폴리오성으로 프로젝트를 진행하는 입장에서는 타입스크립트를 사용하는 것은 좋은 선택이었다고 생각한다.

 

* 에러잡기의 달인

 - 타입스크립트는 데이터의 타입을 일일이 정해줘야 하기에 상대적으로 안정적이고 버그 발생이 적겠구나라고 단순하게 나는 생각했었다. 하지만 동적 혹은 정적 타이핑의 종류가 버그의 발생율과는 관련이 없다는 주장이 인정받는 추세인 듯 싶다. (labs.ig.com/static-typing-promise) 즉, 런타임 상황에서의 에러는 줄일 수 있지만, 이것이 서비스상의 버그 혹은 안정성으로 연결되지는 않는다는 주장이다. (타입에러는 휴먼에러 및 개발환경에서 나타나는 것이고, 버그를 줄이려면 탄탄한 로직과 테스트 및 디버깅을 잘해야한다는 이야기인 듯 싶다.)

잘못된 타입 및 연산일 경우 해당 에러를 알려준다.

 - 그렇다면 타입스크립트를 왜 쓸까? 바로 개발자가 보다 빠른 에러 발견과 해결에 있다. 개발자가 런타임 상황에서 에러를 발견하는 것과 컴파일 상황에서 에러를 발견하는 것에는 큰 차이가 있다. (이 부분은 리팩토링 시에 정말 빛난다고 한다.) 실제 이번 프로젝트를 진행하면서 VS CODE의 타입 기반 실시간 디버깅이 매우 편하고 유용함을 체감하였다. 에러 발생뿐만 아니라 코드를 작성할 때, 해당 변수의 이름과 타입을 바로바로 체크해주기에 보다 편하고 빠르게 코딩이 가능해졌다.

 

해당 객체가 갖는 속성들과 그 타입까지 알려준다.

 

* 제네릭과 함수형 프로그래밍 (@types & d.ts)

 - 하지만 함수형 프로그래밍에서 타입스크립트를 쓰는 것이 정말 어려웠다. 여러 타입의 파라미터 혹은 리턴 값을 갖는 경우, 제네릭으로 일일이 여러 타입을 설정해주어야 한다. 또한, 여러 타입이 들어가는 모든 상황을 가정하기에 각각 타입에 대한 분기처리를 넣어줘야한다. 이게 정말 이번 프로젝트 개발을 너무나 너무나 힘들게 만들었던 부분이다.

 - Redux-Saga와 타입스크립트를 같이 쓰려니깐 초기 학습하고 기본 로직을 구축하는데 너무 힘들었다. 가뜩이나 사가를 처음 써보는터라 여러가지로 혼잡스러운 상황에서 액션 생성자, 리듀서, 사가에 대한 모든 타입을 지정해줘야 했기 때문이다. 결론적으로 `typesafe-actions`를 활용한 패턴을 적용시켰지만, 처음 로직을 구축할 때는 정말 삽질의 연속이었다.

외부 API의 타입을 지정해주지 않은 경우

 - 이와 연결되는 내용으로 초기에 설정되지 않은 속성이나 리턴값들을 활용해야 하는 경우에는, 이러한 값들까지 사전에 이름과 타입을 다 설정해야 사용이 가능하다. (null 이나 undefined까지도) 또한, @types에 없는 라이브러리라면 d.ts를 직접 설정해줘야 한다. 이러한 검사를 통과하기 위해 any를 써버리게 되버리면, 타입스크립트를 쓰는 의미가 또 모호해져버린다. 진퇴양난이다 정말. 즉, 자바스크립트와 타입스크립트를 둘 다 제대로 활용하려면 이러한 부분을 일일이 다 설정해줘야 하는 어려움이 존재한다.

@types에서 지원하지 않는 라이브러리

 

* 사용해야 할까?

 - 자바스크립트의 장점으로 함수형 프로그램밍과 프로토타입, 그리고 동적 타이핑을 뽑을 수 있다. 이것이 단점이 되기도 하지만, 자바스크립트의 대표적 특징이라는 것에는 변함이 없다. 그리고 타입스크립트로 이러한 자바스크립트의 특징들이 없어져버린다. 단점은 보완되었으나, 정작 자바스크립트가 추구했던 특색을 잃어버리는 아이러니한 상황이 발생되는 것이다. (막상 타입스크립트를 컴파일한 결과를 보면 프로토타이핑 호출단계가 많이 발생된다는 글을 본적이 있다.) 

 - 타입스크립트의 도입에 여러 찬반 의견이 존재하지만, 근래에는 지지하는 쪽으로 대세가 된 듯 싶다. 나 역시도 지지하는 쪽에 손을 들고 싶다. 나는 무엇보다도 개발은 "단기간 처리하는 일이 아니다", "혼자하는 일이 아니다"는 점에서 타입스크립트를 장점이 있다고 생각한다. 여러 개발자가 참여하고, 개발이 완성된 상태에서 새로운 개발자가 참여할 수도 있고, 기존 코드를 유지보수 하거나 새로운 기능이 추가된다는 등 리팩토링하는 일도 많을 것이다. 이처럼 많은 개발자가 참여하고 거대하고 장기적으로 지속되는 서비스의 경우에서는 타입스크립트의 단점보다는 장점이 크게 적용되지 않을까 싶다. (아직 어색해서 그런걸까? 공부해야 할 것도 너무 많고, 귀찮은 것도 너무 많은건 사실이다... :')

 - 자바스크립트와 리액트 기반으로 구상했던 로직과 기능들이 엄청나게 많았다. 하지만 이를 타입스크립트로 구현시키려니 예상치 못한 에러와 시간적 한계를 대면하게되었다. 결국 로직을 완전히 바꾸거나 기능을 제외한 부분도 상당수 존재한다. 지금도 수정해야 할 부분들이 산더미처럼 많아 보인다 :'

 

3-2. Redux-Saga

* 사이드 이펙트 관리 : 컴포넌트는 순수함수, 비즈니스 로직은 Saga에서

 - 2주 프로젝트 때 일부러 Redux를 사용하지 않았기에 Redux의 필요성과 편리함에 대해서 뼈저리게 느낄 수 있었다. 그리고 사가를 더해서 비동기 비즈니스 로직을 깔끔하게 처리할 수 있었다. 러닝커브가 살짝 있다고들 하지만, 정말 유용한 기술 스택이다. 그렇기에 사가는 어떻게 사용하는지 사용법을 아는 것보다 원리와 흐름을 이해하는 것이 무엇보다 중요하다고 생각든다.

 - 흔히들 리덕스 사가를 비동기 상태 관리라고 표현을 하는데, 개인적으로 사이드 이펙트 관리라는 표현이 좀 더 마음에 든다. 즉, 단순하게 상태 관리를 하는게 아니라, 사이드 이펙트가 일어날 수 있는 비즈니스 로직을 관리하는 역할 수행한다. (썽크와 달리 비동기 로직을 사가가 직접 처리하는 것은 아니고 미들웨어에 명령을 하는 형태이다.)

redux saga의 기본 로직 (출처: stackoverflow)

 - 리액트는 컴포넌트 주축으로 구성되어 있으며, 이 컴포넌트는 prop를 받아 엘리먼트를 반환하는 함수 형태이다. 그리고 이 컴포넌트가 순수 함수로써 역할을 수행해야 좋은 로직이라 할 수 있다. (리덕스 또한 리듀서라는 순수함수로 이뤄진다.) 그래서 사이드 이펙트가 일어날 수 있는 비동기 비즈니스 로직을 리덕스 사가로 컨트롤을 해주는 것이다. 이것이 정말 편하고 안정적이며, 가독성 및 유지보수성까지 좋아지는 코드를 만들어준다.

 - 원리는 자바스크립트의 제너레이터 함수를 활용하는 단순한 방식이다. 사가는 액션 리스너로서 dispatch 되는 액션들을 살펴보다 일치하는 액션이 발생되면 해당되는 제너레이터 함수를 실행시키는 방식이다. 타입스크립트 환경에서 사가를 구현해야 했기에 `typesafe-actions' 를 활용해봤다. 처음에는 'createAsyncAction'와 'createReducer' 메서드 원리를 이해하는데만 해도 큰 시간을 썼던 것 같다. 누가 옆에서 설명만 해줬어도 빠르게 넘어갈 수 있었을 것을 혼자 파해치다 보니 어려웠던 것 같다.

 

* Thunk와의 차이점 : Saga는 순수하다.

Redux Thunk (출처:https://medium.com/@shoshanarosenfield)

 - 흔히들 썽크와 사가의 가장 큰 차이점을 클로저 패턴 등의 문법 차이를 둘 수 있다. 일반적으로 액션생성함수는 객체 형태를 반환하는 함수인데, 썽크는 객체가 아닌 디스패치를 인자로 받는 함수를 반환한다. 해당 함수는 필요할 때 호출되며, 내부에서 비동기 처리 및 처리되어야 할 액션들을 디스패치 한다.

Redux Saga (출처:https://medium.com/@shoshanarosenfield)

 - 사가는 순수함수로써 썽크와 같은 장황한 코드 없이, call, put 등의 이펙트 생성자를 통해 비동기 처리를 하며, 다른 액션 작업들을 순서대로 진행할 수 있다. 즉, 사가는 명령을 내리는 역할만을 수행할 뿐이지 썽크처럼 비동기 로직을 직접적으로 수행하는 것이 아니다. 그리고 미들웨어들이 처리한 값을 사가는 돌려받는다.

 - 이는 단순히 가독성만을 높여주는 것이 아니다. 비동기 로직이 아무리 복잡하여고 간단한 분기처리 코드들로만 테스트 및 디버깅, 분기처리가 가능해진다. 이번 프로젝트는 로직 자체가 단순하여서 임펙트있게 이 부분을 활용하지는 못하였지만, 순수함수로써 객체를 반환한다는 것만으로도 가독성 및 유지보수성이 훨씬 좋아졌다.

 - 또한, 썽크는 하나의 액션으로 스토어를 업데이트 할 수 없다. 즉, 액션에 직접적으로 응답을 할 수 없는 것이다. 썽크 안에서 디스패치를 통해서 로직을 처리해야 한다. 하지만 사가는 특정 액션타입이 디스패치 되면 이를 감지해내고 비동기 처리를 하거나 스토어를 업데이트 하는 등 그에 맞는 동작을 바로 수행 할 수 있다.

 

* 사용해야 할까?

 - 사가는 제너레이터 함수인 사가 함수를 추가로 구현해줘야 하는 등 단점도 있다. 당연히 코드도 길어질뿐더러 사가 로직과 제너레이터 함수의 대한 공부와 이해도 필요로한다. 그리고 만들어 놓은 것을 읽고 수정하기는 편하지만 처음에 구축하는 단계에서 귀찮게 느껴졌다.

 - 그래도 비동기 로직 및 사이드 이펙트를 효과적으로 관리할 수 있다는 점에서 엄청나게 유용한 스택이라고 생각든다. 또한, 가독성 및 유지보수성까지 좋으니 사가를 안 쓸 이유가 없다고 생각든다. 해당 프로젝트에서는 사가의 기능을 100% 활용하지는 못하였다. 특정 액션이 디스패치되고 또 다른 액션을 디스패치 작업을 하는 등에 보다 병렬적인 작업들, 테스트 및 디버깅에 활용한더던지 등의 사가가 강력하다는 불리우는 이유들에 대해서 말이다. 정말 공부하고 알아야할 것들이 산더미이다.

 

3-3. React-Hooks

 - 이제는 훅 없이 리액트 개발을 할 생각을 하면 끔찍하다. (특히, useState와 useEffect) 2주 프로젝트 때 life cycle을 일일이 관리하느라 정말 고생하였는데, useEffect을 활용하여 정말 편하게 life cycle 컨트롤이 가능해졌다. 이전까지 didMount, didUpdate, shouldUpdate에서 일일이 조건 걸어줘가며 이전 state와 props를 비교해주고... 다시 생각해도 복잡하고 난잡한 코드가 그려진다.

 - 또한, 리덕스를 활용할 때, mapStateToProps 등의 함수를 만들고, connect 함수로 컴포넌트를 감싸고, 액션 생성 함수를 props로 전달하는 등의 Higher Order Component(HOC)를 구현하지 않아도 되는 것이었다! 단순히 useSelector와 useDispatch로 너무나 편하게 리덕스 상태 관리가 가능해졌다. 

 - 개인적으로 편했던 것은 모든 component를 class component가 아닌 function component만으로 다뤄도 된다는 것이다. 거기다가 redux에서 다루는 state 말고도 해당 페이지서만 활용하는 단순한 입력값이나 좌표값등은 useState로 하여 각각의 container에서 다를 수 있도록 하니, 이처럼 편할 수가 없다.

- 이밖에도 useRef, useParams, useLocation, useHistory 등 정말 편한 hooks가 많으며, customer hooks를 만들어 활용한다면 정말 편하고 깔금하게 react를 다룰 수 있을 것이다.

 

3-4. Design Pattern

* React State Management Patterns

 Prop-drilling & Redux-centric (출처: itnext.io)

 - 조언을 받아 Redux는 글로벌 상태관리, Saga에서는 모든 비즈니스 로직을 처리, Component는 순수함수로써 구성되도록 짜보았다. 사실 처음 설계 단계에서 Container & Presenter 패턴을 적용시켜서 만들어가려고 했다. 하지만 점점 이 Container와 Component의 경계선이 없어지고, 무의미한 Props의 전달만 이뤄지는게 아닐걸까라는 생각이 들어버렸다. 실제로 특정 Cotainer가 너무 커져버려서 하위 Component에서 redux 혹은 hook을 활용한 상태 관리등을 추가할 수 밖에 없었다. 여기서 개발 경험이 아직 많이 부족하구나를 많이 느꼈다. 디자인 패턴에 대해서는 앞으로도 공부를 해보고 싶은 분야이다.

 - 그렇다고 단점만 존재하는 것은 아니다. 프로젝트 전체를 볼 때, 각각의 역할 구분이나 전체 그림을 그리고 로직을 이해할 때 가독성이 올라간다. 또한, 협업이나 개발단계에서 데이터의 흐름을 추적할 때에는 Container 개념이 큰 도움이 되었다. 

 

* Redux Duck Pattern

duck pattern

 - 뭔가 국룰처럼 쓰여지는 패턴이라 배우고 사용했다. 그리고 정말 깔끔하고 좋은 코드가 나오기에 추천하고 싶다. 사실 이게 엄청나게 거창한 방법은 아니고 기능별로 파일을 구분하는 것이다. 일반적으로 리덕스를 활용할 때, 여러 개의 액션타입과 액션, 리듀서가 하나의 묶음으로 만들어진다. 이를 구조 중심이 아니라 기능(모듈)중심으로 나누는 패턴인데, 이게 가독성도 유지보수할 때도 정말 편리하다.

 - 일반적인 방법에서 추가된 것은 타입스크립트와 사가를 활용하여 프로젝트를 진행하였기에 state와 action의 타입을 설정해주는 types.ts와 사가 비동기 로직 미들웨어인 api를 별도로 만들어서 관리해주었다.

 

3-5. git & aws

 - 2주 프로젝트에서 git과 AWS 관련되어서 너무 큰 고생을 한 덕분에 이번에는 큰 이슈없이 활용할 수 있었다. 또한, 프로젝트 업무 분담도 명확되어 겹치는 부분도 없었고, redux로 상태 관리를 하였기에 상태관리에서도 충돌날만한 상황이 없었다.

 - 늘 쓰는 명령어와 기능들만 활용하는 것 같아서 아쉬움이 있긴하다. upstream과 내 로컬환경을 분리하고, 브랜치 관리하고, commit, push, pull, pull request 그리고 merge. 가끔 충돌이 발생하면 보정해서 머지하고. 2주 프로젝트에서는 프로젝트, 스톤마일과 이슈, 테스크 카드 작성하는 것도 어려움의 연속이였는데, 확실히 한 번 써봤던 기능들이라 편하게 다가왔다. 좀 더 공부해서 다양한 명령어와 기능들을 써보고 싶다.

 - S3와 CloudFront를 활용해서 정상적으로 배포가 되긴되었다. 다만, 기본적인 기능만 사용하였지, 전체기능 중 절반도 제대로 활용 못하고 있는 듯한 기분이 든다. AWS의 기능들이 너무 많고 뭐 먼저 공부해야할지 감이 잘 안잡힌다. AWS와 도커 관련되어서는 추후에 꼭 공부를 해봐야겠다.

 

4. 마무리

4-1. 독학의 어려움과 스터디 노트

 - 실제 개발기간이 약 20일 정도였는데, 이 기간 동안 새로운 스택을 공부하고 적용시켜 프로젝트 완성시켜야하는 것이 절대 쉽지 않았다. 특히나 타입스크립트와 사가가 별개가 아닌 서로 조합하여서 사용해야 하는 점에서 큰 어려움을 겪었던 것 같다. 각각의 학습자료는 많은데, 막상 '타입스크립트 + 사가' 관련 자료들은 많지가 않았다. 무엇보다도 별도의 멘토나 선생님 없이 혼자 공부하려다 보니, 제대로 이해했는지에 대한 확인이나 삽질을 정말 많이한 것 같다. 사실 코드스테이츠 측에서 코드리뷰까지는 아니어도 프로젝트에 대한 피드백이나 멘토링이 있을 줄 알았는데, 그런 것도 일절 없었던게 아쉬움이 크다.

노션 개인 스터디 노트

 - 이번 프로젝트에도 스터디한 내용 및 에러, 실수 해결 내용들을 별도 노션 스터디 노트에 담아봤다. 개발을 하다보면 당장 문제해결에 급급해서 급한 불을 끄기 바꾸다. 그리고 문제를 해결하고 난 뒤에 얼마 지나지 않아 해당 내용을 잃어버려서 다시 검색하고 공부하는 경우가 허다했다. 이렇게 공부했던 내용이나 겪었던 문제들을 정리해 놓으니 나중에 복습할 때 정말 큰 도움이 되었다. 지금은 나만 보도록 정리가 안되었지만, 쓸만한 내용들은 블로그에 포스팅해볼까 생각한다.

 - 그래도 새로운 스택들을 공부하면서 나는 한단계 더 성장한 느낌이고, 포트폴리오 성격을 갖는 해당 프로젝트에서는 큰 도움이 되었다. 아직은 수박 겉핥기 수준이다. 각 스택이 가진 장점을 제대로 활용하려면 앞으로 더 많이 많이 공부해야할 듯 싶다.

 

4-2. 역할분담의 중요성

 - 프로젝트 처음에는 프론트엔드를 2명으로 시작하였다. 하지만 다른 한분이 2주 프로젝트 때 백엔드를 하셨던 분이라 그런지, 리액트, 타입스크립트, 리덕스와 사가를 공부하는데 꽤나 힘들어 하셨다. 그래서 팀원들은 언제즈음이 공부가 완료되고 개발을 시작할 수 있을지 끊임 없이 체크하고, 담당하는 파트도 줄여줬다. 또한, 새로운 스택이 부담스러우면 단순하게 hook과 axios 등을 활용하여 컨테이너에서 비동기 로직을 처리하거나 any를 쓰는 쪽으로 권유드렸다.

 - 담당하셨던 분은 피해를 주고 싶지 않은 마음에 "이때까지는 할 수 있다."고 말씀해주셨고, 우리는 믿었다. 하지만 마감기한이 얼마 안 남은 시간부터 제대로된 코딩이 시작되었고, 결국, 기능도 코드도 제대로 구현되지 못하였다. 부랴부랴 그 분이 담당하셨던 부분을 내가 만들어서 포트폴리오를 만들 수밖에 없었다. 시간이 부족한 관계로 커뮤니티 파트까지는 구현할 수 없었다. 이 부분이 가장 마음 아프다.

 - 프로젝트에서 팀원 개개인의 의견을 듣고, 믿고, 지지해주는 것은 당연히 좋은 자세이다. 하지만 모두에게 중요한 프로젝트고 기간이 한정적이기에 좀 더 현실적으로 생각을 했었어야 했던 아쉬움이 든다. 프론트를 맡으셨던 분은 2주 프로젝트 때에는 백을 담당하였고, 백은 크게 할게 없어서 쉬웠다고 말씀해주셨다. 그리고 이번 프로젝트 때 백을 담당하셨던 한 분은 프론트에 대한 이해도가 높으셨다. 만약 이 두 분의 포지션이 바뀐 상태에서 프로젝틀르 진행하였다면 결과가 좀 더 좋은 쪽으로 나오지 않았을까 하는 아쉬움이 남는다. 즉, 이렇게 스터디가 아닌 단기간에 결과물을 보여줘야하는 중요한 프로젝트의 경우, 개개인이 잘하는 것을 담당하는게 더 좋지 않았을까 생각이 든 프로젝트였다.

 

4-3. 설계와 스케줄의 중요성

 - 처음 기획과 설계 단계에서 이것저것 욕심나는 기능들이 많았다. 하지만 우리가 3주라는 기간 동안 얼마나 공부하고 어디까지 구현시킬 수 있을지에 대한 감을 잡기가 어려웠다. 그렇기에 Advanced한 기능들은 optional로 설정하고 마구잡이식 테스크 카드와 스케줄이 편성이 되었다. 또한, 뒤늦게 설계가 수정된 부분에서 누구는 구현하고, 누구는 구현하지 못하는 상황이 발생하게 되었다. 이처럼 설계가 중요하기도 하면서, 잡아놓은 스케줄에서 어긋나는 갑작스러운 변화들은 오히려 독이 될 수도 있음을 느꼈다.

 - 이렇다 보니 누구는 언제까지 어디까지 구현되고, 다른이는 여기까지 구현되고 등 진행되는 속도가 가지각색이었다. 자연스럽게 배포가 늦어지게 되었고, 배포 후 테스트 및 디버깅할 시간이 부족했다. 그 짧은 시간동안 예상치 못했던 에러들을 잡기가 매우 힘들었다. (다행히 다 잡기는 했다.) 2주 프로젝트 때도 배포가 늦어져서 고생했었는데, 이번에 내가 조금만 더 강하게 배포를 빨리해보자고 목소리를 내볼껄 하는 아쉬움이 남는다.

 - 마지막 목업 데이터를 넣느라 너무 고생하였다. 역시나 시간이 없는 관계로 기능 구현을 위해 무작위로 데이터를 넣었기에, 콘텐츠의 퀄리티나 정확성이 없어져버렸다. 설계 단계에서 페스티벌은 어렵더라도 아티스트 및 관련 비디오 정도는 크롤링 하는 방향으로 설계했다면 더 좋지 않았을까 아쉬움이 남는다.

 

4-5. 프로젝트를 마치며.

 - 애착이 많이 갔기에 아쉬움도 그만큼 큰 프로젝트였다. 글을 쓰면서도 "아쉬움이 남는다."라는 표현이 벌써 몇번 나왔는지 모르겠다. 그래도 4주 동안 정말 열심히 달렸기에 큰 후회는 없다. 다시 한 번 함께 고생해준 팀원들에게 진심으로 고맙다.

 - 앞서도 여러번 말했지만 4주라는 짧은 시간동안 무엇을 할 수 있고, 내가 얼마나 성장할 수 있을지에 대한 의문이 많았다. 실력적인 부분에서는 아직 많이 부족하지만, 그래도 이 짧은 시간이 제법 개발자다운 생각과 자세를 갖는 시발점이 되었다고 생각든다. 프로젝트가 끝났지만, 이제부터가 진짜 시작이다. 몇 년 뒤에 현재 내가 쓴 (부족한)글과 코드를 봤을 때, 부끄러워 할 수 있는 지금보다 훨씬 성장한 개발자가 되고 싶다.