회고가 너무 늦은거 아닌가?

2차 프로젝트가 끝이 나고 회고도 하고 싶지 않을 정도로 정신건강이 좋지 않았었다. 개발이 너무 힘들어서 무너진 것은 아니지만 이런저런 이유들이 복합적으로 쌓이면서 '하기 싫음'이 극에 달았었다. 그런 상태가 3차 프로젝트 중간까지 지속이 되었다.

3차 프로젝트가 시작하는 때에는 내 감정을 정확하게 알 수 없었다. 그저 남들도 하기 싫어하니 나도 똑같은 현상을 겪고 있다고 생각했는데, 생각보다 마음이 많이 떠있었다. 그래서 팀원들에게 정말 미안하다.

프로젝트를 진행하면서 왜 내가 힘들었었는지 어떻게 극복이 되어 마지막을 불 태울 수 있었는지 하나하나 다시 생각해보자

2차와 3차 사이

3차 프로젝트가 시작하기에 3주라는 시간이 있었다. 3주간 내가 했던 일을 되돌아 보면 이것저것 계획을 세우기는 했지만 막상 제대로 공부를 했던 것은 없었다.

타입스크립트, 스토리북, 알고리즘, 전역 상태관리 프론트엔드에서 필요로 하는 것들을 공부하겠다는 마음을 먹었지만 막상 3주 동안 했던 것은 알고리즘 밖에 없었다. 알고리즘 공부를 시작하며 목표로 했던 solved.ac 골드에 진입했던 것 말고는 뚜렷하게 무언가 했다고 얘기하기 힘들어 보인다.

공부를 하기 싫은 마음도 있었지만, 폐관수련과 같은 코딩생활을 하고 있을 때 우울감이 찾아왔다.

우울감이 맞는지는 모르겠다. 어떤 감정이 우울한 감정인지 정확히 모르겠지만 다른 사람들은 이를 우울이라 하니 우울함이라고 표현을 하겠다. 코딩을 하고 싶은 마음과 해야하는 마음 중간에 우울함이 찾아오니 하고 싶은 마음이 zero가 되어 버렸다. 코딩을 억지로 해야하는 괴로움에 빠져 당시 인생에 재미가 하나도 없었다.

어찌보면 나약함이라고 표현할 수 있겠지만 하고싶은 마음 없이 어떤 일을 하는 것은 매우 힘든 일임을 이 때 알게 되었다.

이런 생각을 가졌을 때 조금은 제대로 쉬었으면 얼마나 좋았을까. 미련한 나에게 회초리를 들고 싶다. 원래 괴로운거지 하며 하루도 쉬지 않으려고 했던 지나온 날들이 너무 미련해 보였다. 그러면 이런 마음을 일찍 털어버렸을 것 같다.

어떻게 벗어났는가

보통 우울감이 찾아오면 힐링을 위해 재미난걸 하거나, 상담을 받던가, 여러가지 방법을 통해 벗어날 것이다. 하지만 당시에 나는 취미생활을 해도 그 뿐, 내가 건강해지고 있다는 생각을 하지 않았다.

그럼 나는 무엇을 했냐

그냥 버텼다. elice에서 만났던 같은 처지에 있는 사람들과 이야기를 나누고, 해야지 하는 굳은 다짐을 다시 새기며 우울감을 버텨냈다. 아! 슬픈 노래도 내 우울감을 이겨낸 아주 고마운 놈이다. 워낙 속마음을 잘 표현하지 않아 주변 사람들은 내가 힘들어 한다는 것을 잘 몰랐을 것이다. 누군가에게 막 풀었다면 좀 나아졌을지 모르겠지만 그래도 잘 이겨낸 것 같다.

그리고 결정적인 것은 아니지만 중간발표에서 멘탈 관리에 대한 코치님들에 대한 생각을 들었을 때, 당연한 이야기지만 그냥 스스로 마음을 다잡을 수 있게 되었던 것 같다.

그렇게 오랜 기간 방황을 했고, 마지막 프로젝트가 얼마 남지 않았을 때 정신을 차릴 수 있었다.

만약에 나와 같이 코딩 생활 중 비슷한 상황이 온다면, 제대로 쉬어주라고 얘기하고 싶다. 어중이떠중이로 쉬는건 전혀 도움이 안 된다. 집을 좋아하는 사람이라도 나가는 것을 적극 추천...

3차 프로젝트!

이제 본론으로 돌아와 3차 프로젝트 회고를 해보려고 한다. 지금까지 오는 과정이 너무 험난했다. 싱숭생숭한 마음으로 맞이하게 된 3차 프로젝트는 내가 무엇을 느꼈고, 뭐를 했는지, 의식의 흐름대로 적어보려고 한다.

회고의 방법을 보니 가장 유명한 방법이 있지만 그냥 하고 싶은 데로 할 것이다.

팀장을 맡았다..

팀원들과 처음으로 회의를 가졌던 시간을 생각하면, 역시 첫 만남은 어색하다. 사교성이 좋은 편은 아니지만 5주간 함께 일할 사이로 얼른 어색함을 벗어나길 바랐다. 말 주변이 좋지는 않지만 이런 저런 얘기를 나누고 싶었지만 역량 부족이었다.ㅋㅋ 이야기를 이끌어갈 솜씨가 없어 어떤 이야기를 나눴는지 기억도 나지 않는다. 관심사에 대한 이야기를 나누고, 무슨 생각을 가지며 개발을 하고 있는지 생각보다 진지한 이야기를 나눴던 것 같다.

팀장을 맡았던 이유는 첫 번째는 해보고 싶기도 했지만 아무도 없어서가 컸다.

이대로 가다간 사다리를 타야 한다는 가장 안타까운 결말을 맞이하기 때문에 내가 자진해서 팀장을 맡겠다고 했다.

팀장을 맡은 것을 후회하지 않지만, 내가 아닌 다른 사람이 맡았다면 더 잘했을 것이라고 생각이 드는 결론을 맞이했다.

당시 나는 심신미약 상태였기 때문에 팀장으로 팀에 어떤 도움을 주지 못했던 것 같다.

• 노션페이지를 잘 관리했나? x
• 스크럼을 잘 이끌었나? x
• 문서화를 통해 팀 내 정보를 잘 공유했나? x
• 기획 단계에서 적극적이었나? x
• 파트별 지식이 충분했나? x
• 팀원의 상황을 잘 파악하고 있었나? x

노션페이지를 만들어서 프로젝트 진행도를 확인할 수 있게 했지만, 오피스아워 정리와 일일 회고는 얼마 못 가 끝이 났다.

생각보다 모든 오피스아워에 참가해 이해가 안 되는 내용을 정리하는 일은 매우 매우 힘들었다.

스크럼 회의록에 적는 간단 회고 외에 프로젝트를 진행하며 느끼는 점을 TIR(Today I Review)에 적었었는데, 이 역시 심신미약 상태를 이기지 못 했다.

문서화를 잘해야 겠다는 마음만 앞섰지 하나도 제대로 하지 못 했다ㅠ

몰라서 부족했다. 기획력도 부족했고, 숲을 바라보는 시야가 부족했다. 팀원이 더 잘할 수 있도록 서포트 해주는 방법을 몰랐다. 더 생각을 해봐도 좋은 팀장이 되는건 매우 어렵다..! 1차, 2차 팀장님 사랑합니다...

모든 부분에서 아쉬운 팀장이었다고 결론을 짓겠다 탕탕

기획 너무 어려워

2차 때 느낀 기획의 중요성, 3차에서는 실수 하지 않겠어 했지만 역시나 완벽한 기획을 할 수 없었다. 서비스의 큰 그림을 그리는 일과 와이어프레임을 완성하는 것. 나는 딱히 도움이 되지 못했다. 피그마 툴을 다루는데 문제가 있었으면 오히려 좋았겠다. 툴을 잘 다뤄도 ui/ux를 고려한 완성된 화면을 그릴 수 없었다.

다행은 팀원이 너무 잘했다.. 디자인을 너무 잘해서, 엄청난 버스를 타버렸다.

혼자 와이어프레임과 디자인을 맡기는 일이 너무 미안해서 어떻게든 나도 돕기 위해 끙끙 앓았는데 전적으로 맡기고 먼저 프로젝트 구조와 폴더 구조와 같은 기본 설정을 먼저 했으면 정말 좋았겠다라고 생각이 든다.

역할 분담이라는 것을 어떻게 해야 효율적으로 할 수 있었을까 돌아보게 된다. 아직 리더쉽 : 팔로쉽 = 1 : 9 인가보다...

일기?

심리학을 공부한 팀원의 엄청난 도움을 받아 자연어처리에 적절한 주제를 선택할 수 있었다. 감정지능의 필요성과 현대 사회인이 겪는 문제점에 한 줄기 빛이 되는 좋은 목적을 가진 서비스를 기획했다. 물론 나에게 너무 필요한 서비스였다.

항상 혼란스러웠던 내 감정을 인공지능을 통해 알 수 있고, 내가 느끼는 감정들을 기록하는 저장소! 너무 좋았다. 글을 쓰면서 감정을 정리하고, 해소하는 공간, 일기를 주제로 한 것은 대만족이다.

이런 주제를 생각해준 팀원들에게 너무 고맙다.

프로젝트 구조

이제 개발의 시작이다. 기획을 하면서 팀원들과 타입스크립트를 기본 언어로 하자고 의견을 냈고, 다들 해본 적이 없어 자신이 없었지만, 우리의 코치님의 의견을 수렴해 타입스크립트 기반으로 코드를 짜기로 했다.

기존에 프론트, 백만 있던 구조에서 인공지능 서버가 추가되어 어떻게 인공지능 서버와 통신을 해야하는지 고민이 많았었다. 처음 선택은 프론트와 백, 프론트와 인공지능, 인공지능과 백 전부 통신을 하는 구조로 했다.

일기 감정 분석을 요청할 때 백엔드를 거칠 필요가 없다고 생각해, 프론트에서 인공지능 서버로 post를 보내기로 했다.

이 때는 몰랐다. 이렇게 구조를 짜면 어떤 문제를 겪는지... 뭐가 문제인지...

프론트에서 인공지능으로 post 요청을 보낸 순간, 첫 경험을 했다. cors를 직면했다. 지금까지 cors를 직접 보지 못 해서 개념 자체도 잘 몰랐었다. 단순히 리소스 출처가 달라서 생기는 보안 오류라고 알고 있었다.

이를 발견한 시점은 팀원들이 자고 있을 새벽시간이었다. 당장 다음 날 중간 발표가 있기에 해결을 봐야하는 상황... 이 때 마음의 불이 켜진 것 같다. 작아졌던 책임감과 열정이 활활 하는 시간이었다.

왜 cors

cors가 일어나는 이유는 아주 많다. 그 중에 내가 겪은 이유는 인공지능 서버는 8000번 포트를 client는 3000번 포트를 사용하기 때문에 다른 출처의 리소스를 사용하기 때문에 발생했다.

가장 단순한 방법은 모든 권한을 가능하게 바꾸는 방법이다. flask에서 cors 모듈을 다운 받으면 간단하게 해결이 가능하다. 하지만 이 경우는 보안 상 권장하지 않는 방법이다. 마음은 급하지만 제대로 된 방법을 찾기 위해 시간을 더 투자했다.

최선의 방법은 아니지만 특정 포트만 허용 가능하도록 만들면 팀원들이 일어나서 도움을 줄 것이라고 생각을 했다. 하지만 내가 가진 도메인 지식은 이를 해결하기에 부족했다. 시간을 가지고 공부하면서 바라봤다면 원하는 방향으로 해결을 했지만, cors 모듈을 다운 받아서 해결하는 좋지 않은 방법으로 일단 구멍을 막았다.

아침에 팀원의 도움을 받아 확실하게 cors를 마주치지 않도록 수정을 했지만 찜찜한 마음을 떨쳐낼 수 없었다..

아침이 밝아서야, 이슈를 해결하고 발표 준비를 시작했다..

프론트 폴더 구조

개발을 시작하기 전 폴더 구조에 대한 고민을 많이 했다. 어떤 구조가 좋은 구조일까, 팀원과 협업하기 좋은 구조는 어떤 구조일까, 지금까지 했던 구조들을 살펴보며 뭐가 별로였는지 보고, 좋다고 생각한 프로젝트들을 염탐하고, 코치님께 조언을 구해 아토믹 구조를 선택했다.

아토믹 구조를 짜는 과정은 굉장히 고역이었다. 프로젝트 전체에서 사용하는 컴포넌트들을 전부 정의하는 것은 디자이너가 아니라면 사실상 힘들다. 개발할 당시 디자인에 대한 개념이 없었다. 그래서 아토믹 너무 어렵잖아! 이거 왜 하는거지? 이렇게까지 하는 게 맞는 것인가? 의문의 의문을 품었는데 그 이유를 명확히 알게 되었다.

디자이너 없이 아토믹은 오히혀 악이다. 왜냐하면 우리는 디자이너 처럼 화면에서 사용할 컴포넌트들을 시스템화해서 전부 정의하는 일이 너무 어렵기 때문이다. 개발자는 이렇게 정리된 피그마를 가지고 추상화를 거쳐 코드로 구현하는 일을 하는 사람이기에 시작부터 난관이었다.

그런데도 아토믹으로 했다. 왜? 가독성을 위해. 굉장히 유명한 사람이 이런 말을 했다.

어떤 바보도 컴퓨터가 이해하는 코드를 짤 수 있다. 하지만 사람이 이해하는 코드를 짜는 것은 아무나 할 수 없다.

그래서 선택했다. 최대한 가독성이 좋은 코드를 짜고 싶은 욕구, 욕망이 있었다.

우리는 디자인 요소를 줄이는 방향으로 아토믹 구조를 잡는 어려움을 조금 해소했다. 최대한 심플한 디자인을 바탕으로 구조를 잡아 나갔다.

What the Tuck!!

타입스크립트는 정말 괴상한 언어였다. 처음 접하는 언어이기에 유료 강의도 구매했고, 1주일을 거의 프로젝트 구조와 타입스크립트에 적용하는 기간을 가졌던 것 같다. 타입스크립트만 공부했을 때는 '오 자스에서도 타입 명시를 하니 세련된 언어가 된 것 같은 느낌'에 기분이 상당히 좋았지만,,, react + typescript를 사용하니 안되는 일이 뭐가 이렇게 많은지 불평, 불만이 많았다.

뭐만 하면 string | undefined 타입은 string 타입에 할당할 수 없다. 와 같은 아주 뭐시기한 상황이 너무 많이 일어났다. 또 개체가 null인 것 같다고 수도 없이 많은 에러를 터져나왔다.

아마 typescript를 사용하신 분들은 많이 경험하셨을 것 같네요.

굉장히 당황스러웠지만... javascript를 사용할 때는 이런 에러를 겪지 못 했고, 만약에 있다고 하더라도, ? 하나 붙이면 에러가 말끔하게 사라졌었는데 이게 무슨 일인가 싶었다.

이 때 깨달았던 점은 내가 지금까지 예외처리를 고민하지 않고 있었구나 였다. ?를 붙이는 게 올바른 코드였던가 생각하면 전혀 그렇지 않았다. 값이 없는 경우에 예외처리를 해야 웹이 죽는 일이 없었는데 지금까지 그런 생각을 안 했었다. typescript 덕에 예외처리의 중요성을 알게 됐습니다.

항상 데이터가 null, undefined일 가능성이 있다면 분기 처리를 해서 정확하게 상황을 나눠서 코딩했습니다.

arr?.map((v, i) => callback)

정말 많이 사용했던 패턴일 것입니다. 하지만 저는 typescript를 사용하고 절대 사용하지 않겠다고 생각한 패턴이다.

if (!arr) return '예외처리'
else arr.map((v, i) => callback)

항상 이렇게 사용하고 있습니다.

이걸 전부 읽을 사람은 없겠지만 타스를 사용할 때 예외처리를 잊지 마세요!

서스펜스...

모든 상황을 if문을 이용해서 처리하는 것은 함수의 단일원칙에 굉장히 어긋나는 일이었다..! 클린코드에 대해 알게 되니 if문을 많이 쓰는 행위가 옳지 않다는 것을 알게 됐다. 그래서 찾아보니 리액트에서 기본적으로 제공하는 서스펜스를 이용해서 패칭 중일 때 다른 컴포넌트를 보여줄 수 있는 기능을 제공하고 있었다... 왜 이걸 몰랐을까..

no-lib

이번 프로젝트의 목표 중 하나는 라이브러리 사용을 지양하자 였다. 최소한의 라이브러리를 가지고 개발을 하면서 스스로 고민하면서 많은 것을 배울 수 있는 기회를 가지고자 했다.

일단 ui 관련한 라이브러리는 styled-components만 사용을 하고자 마음 먹었다. 이 라이브러리를 사용한 이유는 컴포넌트명이 직관적으로 표현이 가능해 가독성이 높아지기 때문에 선택했다. 다만 프로젝트를 마무리하고 styled-components를 사용한 것을 후회도 했습니다. 또 다른 목표라 하면 최적화를 열심히 해보자였기 때문입니다.

styled-components가 편리한 이유는 css-in-js이기 때문입니다. 그러면 앱이 빌드 될 때 우리가 짠 css 코드는 어떻게 컴파일이 일어날까요?

styled-components로 짠 코드는 js로 빌드됩니다. network 탭을 보거나 퍼포먼스 탭을 보면 어떤 파일을 로드 하는지 확인할 수 있는데, 이 때 css파일이 엄청나게 작습니다. js로 로드하는 게 뭐가 문제냐고 할 수 있지만, 브라우저 렌더링에 대해 공부를 하면 성능을 끌어올리기 위해서는 순수 css를 쓰는 게 더 빠르구나를 느낄 수 있습니다.

브라우저에 화면이 나오는 순서는 html, css, js 순으로 읽는데 중간에 css 코드를 읽어 화면에 출력하지 않고 가장 큰 js를 읽으면서 화면에 페인트를 하기 때문에 시간이 더 오래 걸립니다. 뼈 아픈 설계를 해서 울적하기도 했지만, 코드 자체에 대한 최적화를 많이 진행했기에...... 자기위로를 진행했다.

그러면 뭐하나요. 처음 로드 되는 시간에서 빨간 불이 떴는데.

내가 생각한 부분은 굉장히 마이크로한 부분에 초점을 맞추고 있었다. 불필요한 렌더링을 줄이기 위해 useCallback, useMemo, React.memo를 이용해서 줄이고, react-query를 사용해서 api 요청을 최소화 하고, 라이브러리 다운을 줄여 번들사이즈를 줄이려고 노력했지만, 가장 중요한 부분을 놓쳐 많은 아쉬움을 느꼈다.

제대로 공부해서 정확한 방법으로 무언가를 진행해야 된다는 것을 뼈저리게 느꼈습니다.

아 그래서 ui 관련한 라이브러리는 딱 하나 framer-motion?을 제외하고 전부 구현했다. 스낵바, 모달, 드롭다운, 스피너, 기본적인 레이아웃 등 다만 스토리북을 같이 써봤다면 더 좋았겠다 싶은 마음이 남아서 조금씩 해보려고 합니다.

css in js, pure css

나는 분명 css in js가 로드 되는 속도가 더 느리다고 생각했다. 그런데 또 다른 시각을 알게 됐다. 사실 아직 정확히 아는 것은 아니다. 해당하는 문서를 찾아볼 수 없어 검증이 되지 않았지만, 순수 css에서 hover와 같은 이벤트 처리를 dom에서 탐색하는 과정이 css in js 보다 느리기 때문에 실제 로드 되는 속도는 순수 css보다 빠르다는 의견이 있었다..

개발의 세계는 정말 정답이 있을까... 아무튼 이러한 의견도 있으니 찾아봐야겠지만 찾기가 생각보다 쉽지 않았다..

team

솔직하게 말하면 팀워크가 좋았다고는 말할 수 없었다. 아침 스크럼을 제외하고 대화를 많이 하지 않았다. 각자 열심히 개발했지만, 수 많은 아이디어가 오가고, 방향성에 대해 이야기를 나누는 그런 모습은 아니었다. 하지만 다들 최선을 다해 개발을 했다! 일단 팀장인 나도 프로젝트 초반에는 심신미약 상태로 허이 했으니 팀원들은 그 모습을 보면서 얼마나 답답했을까... 프로젝트가 끝나고 많이 아쉽다며 팀원에게 사과도 했었지만 다시 생각하니 정말 미안했다...ㅎ

협업에서 아쉬웠던 점이 있다면.

일단 mr 요청을 잘 활용하지 못해 아쉬웠다. 하루하루 개발한 것을 mr을 통해 아침마다 리뷰하면서 진행했어야 했는데 3번 째 협업에서도 잘하지 못 한 것이 너무 아쉽다. 그래서 다들 아침 스크럼 때 할 얘기도 별로 없이 흐지부지 했던 것 같다...

일일 회고를 작성하지 않았던 점도 매우 아쉽다. 내가 쓰자고 했지만 나도 미뤘다가 쓰는데 어떻게 팀원들이 자진해서 쓸까... 후회가 된다. 결국 마지막까지 작성하지 않은 팀원도 있고, 큰 의미가 없는 스크럼 일지가 되어 버려서 아쉬움이 많이 남았다. 처음 목표는 굉장했지만... 정말 굉장한 문서화를 꿈꾸면서 프로젝트를 시작했지만 그렇지 않아서 아쉬웠다.

앞으로

문서화에 집중하려고 한다. 문서화만큼 남는 것이 없는 것 같다. 프로젝트 이슈들을 보면 그 때 무슨 생각을 해서 이런 코드를 짰는지 기억이 나는 것을 보고 느꼈다. 그래서 앞으로 개발 일지를 작성해보려고 합니다. 약간의 강제성을 불어 넣어, 개발을 안 하는 날이 없도록!.

그렇게 프로젝트를 통해서 3주가 지났지만 마음을 다잡자!.

엘리스 안녕

사실 프로젝트에 대한 부분은 포트폴리오에 많이 적었기 때문에 더이상 쓰고 싶지 않다. 서합이 많이 됐다면 많이 썼을 것 같지만..?

그래서 후련하기도, 아쉽기도한 엘리스에게 작별인사를 끝으로 회고를 마무리 하려고 한다.

너무 글의 흐름이 없어서 나도 다시 안 볼 것 같지만, 내 안에 있던 생각들을 후련하게 뱉을 수 있어서 속이 시원하다. 이 회고는 그저 그런 용도이다. 멋지고 다듬어진 글을 통해 누군가에게 알리고 싶은 것이 아니라 그냥 의식의 흐름을 그대로 보여주기 위함이다.

엘리스 수료식을 끝으로, 이제 새로운 코딩생활이 펼쳐졌다. 그 전에 내 맥북이 사망했다. 2년이 채 되지 않은 싱싱한 맥북이었지만, 많이 힘들었나보다. 수료식이 끝나고 '와 이제 끝이구나..' 하며 충전선을 뽑은 그 순간 내 화면도 같이 죽었다. 갑자기 노트북 화면이 검게 나왔고, 전원을 껐다 켜도 똑같았다. 불길했지만 가끔 이런 적이 있었으니 되겠지 했지만,,,,,,,,, 메인보드 사망으로 저세상으로 간 맥북이다.

엘리스는 내게 중요한 코딩생활의 발판을 주었지만 코딩을 위한 도구는 빼앗아갔다ㅋㅋㅋ

급하게 다시 맥북을 구매..(나는 텅장이 되었다.)

마지막

정말 많은 일이 있었던 엘리스를 끝으로 이제 취업 시장에 뛰어들었다.

생각보다 서류 붙는 일이 힘들구나를 느끼며 나의 부족함을 더더더더더더더 많이 느끼게 되었다.

손가락으로 꼽을 수 있을 정도로 면접을 보며 느낀 것은 아는 척 하지 말자. 그리고 제대로 공부하자. 봤던 것은 공부가 아니다. 버스를 타고 지나가면 맛집이라고 써진 간판을 봤다고 그 집을 맛집이라고 하는 사람은 아무도 없을 것이다. 공부도 그런 것 같다. 스쳐지나가는 지식들을 실제로 먹어봐야지 그걸 설명도 할 수 있다.

제대로 공부하자..