코드숨(codesoom) 프로젝트 1&2주차 회고하기

전에 작성한 내용을 재작성하였습니다.

1주차부터 휴식

목요일부터 갑자기 휴일이 잡혀서 수요일까지 프로젝트를 진행했더니 아이디어 기획만 하다가 끝난 1주 차였다.

홀맨님께서 함께 자라기(애자일로 가는 길) 책을 추천하셔서 잽싸게 책을 주문했던 책이 생각나서 휴일 동안 조금씩 읽었다.

(자라기 파트부분을 읽었다~)

이해는 다 하지 못했지만, 책 내용이 나를 좋은 곳으로 이끄는 듯한 느낌이었다.

먼저, 홀맨님께서 강조하시는 피드백이 왜 중요한지 확실하게 알 수 있었다.

피드백은 선택이 아닌 필수라는 생각을 가지게 되었던 계기였다.

간단하게 말하면, 성장은 피드백으로부터 온다이다.

그래서 시간을 투자해서 어떻게 행동할 것인지에 대해서 점검해 보는 시간을 갖기로 했다. (이 글을 쓰는 시점에서는 진행 중이다!)

주제 선정의 어려움

프로젝트 주제를 정하는데 정말 많은 생각과 변화?가 있었다. (후 주제가 제일 어려우잉..)

초기에 “내가 당장 필요한 것은 무엇일까?”라는 스스로 질문을 했을 때,

‘내가 학습한 내용이 단기기억에서 장기기억으로 갈 수 있게 도움을 줄 수 있는 서비스‘를 만들면 좋을 것 같다는 생각을 했었다.

그리고 좀 더 생각해보니 다른 사용자에게도 도움을 주면 좋겠다는 생각을 했다.

이런 식으로 살을 붙이다 보니, 더 좋은 건 아니지만 좋아 보이는 아이디어가 떠오르기도 했다.

프로젝트가 잘되면 좋겠고 상용화시키고 싶고 많은 사람이 쓸 수 있었으면 좋겠고.. 등등 후의 일도 생각하고 있었다.

그렇게 여러 가지를 생각하다가 일단 결정된 프로젝트 주제는

취업과 이직에 관련해 면접 준비를 도와줄 수 있는 서비스로 정하게 되었다. (다른 일은 하지 못하고 3일 내내 주제에 대해 생각만 했다.)

하지만 여러 가지 아이디어가 합쳐진 상태에서 진행되었다.

어떻게 보면 시간은 흘러가고 있기 때문에 초조한 마음으로 빨리 주제를 정해야 된다는 생각 때문에 정리가 안 된 상태에서 출발했던 것 같다.

1주 차 때 목표는 주제 정하기, 기능 정하기, 개발 환경 세팅과 일부분 개발하기이었기 때문에 시간이 빠듯했다.

일단 주 차별로 진행사항을 깃 저장소에 올려야 해서 생각한 내용을 작성해서 올리게 되었다.

사실 트레이너분들이 주제를 생각할 때 참고하라고, 여러 가지 레퍼런스를 던져주시긴 했다. 하하..

하지만 흔들리는 내 마음

2주 차가 들어오면서 할 일을 작성하고 헤더 영역을 먼저 개발하고 있었다.

그런데 시간이 가면 갈수록

  • 면접 준비를 도와주는 서비스가 내가 하고 싶은 주제인가?
  • 아이디어가 너무 약한 거 아닌가?
  • 정말, 이 서비스가 도움이 되나?
  • 만들고 났는데 쓸모없는 서비스가 되면 어떻게 하지?

등 프로젝트 주제에 대해 의심을 하기 시작했다.

아마도 이건 대학교 때 창업을 한 경험 때문인 것 같다.

막상 서비스를 만들었는데.. 기대했던 일이 일어나지 않았던 기억 때문에 더 걱정이 컸던 것 같다.

‘다른 사람들은 어떻게 하고 있지?‘하면서 다른 분들의 레파지토리(저장소)를 기웃기웃하여 훑어봤다.

다른 사람들은 뭔가 잘하고 있는 듯한 모습이었다. 하지만 큰 도움은 안 되고 오히려 걱정만 늘고 있었다.

'힝구.. 뭐야.. 프로젝트 주제 정하다가 끝나겠는걸..'라는 생각을 했다.

흔들리는 마음, 왜 그러니..

그러다가 1주 차 회고록을 작성하면서 문제점을 일부 해결할 방법을 알게 되었다.

다음 이미지는 초기에 작성한 구체적인 사례이다.

구체적인 사례는 무엇인가요

여기에는 빠져있는 게 있었다. 문제점을 해결한다는 부분은 있지만, 어떻게 해결한다는 부분이 없었다.

예로 모두 흩어져 있어서 준비하는 데 어려움을 겪는다는 아는데, 그래서 어떻게 해결할 건데? 라던지

챌린지를 통해 여러 유형을 한꺼번에 대답하는 연습을 도와준다는데, 어떻게 도와주고 어떤 점이 도움이 될 것인지에 대한 구체적인 내용이 없었다.

흔들리는 마음 잡아버리기

그러면 해결방안을 포함하여 서비스의 목표를 구체적으로 한 문장으로 만들자!

어떻게 해결할 건데?

지금까지 생각해온 부분들을 사용하자!

문제 해결방법을 기존에 단기 기억을 장기 기억으로 넘겨주는 방법 이용하기면접을 도와주는 아이디어를 합치자는 생각을 했고, 기존에 읽었던 책의 내용이 떠올랐다.

읽었던 책의 내용은 단기 기억에서 장기 기억으로 가는 인출 효과와 피드백이 큰 주제였다.

그래서 정한 해결방안을 포함하여 서비스의 목표!

다양한 면접 유형 중에서 지식을 확인하는 부분을 대상으로 문제를 풀어볼 수 있도록 환경을 제공하고 스스로 피드백을 하면서 성장하게 만들 수 있는 서비스를 만들자.

그렇게 서비스의 가치를 가지고, 먼저 가치를 제공할 수 있는 수단으로 면접 환경 제공과 피드백을 결정한 것이다.

(서비스 가치는 인터뷰에 어려움을 겪는 사람들에게 도움이 되자 - 비전과 느낌이 비슷하군..)

정하고 나니 마음이 편안해졌고 방향성을 잡기도 쉬워졌다.

주제 선정이 힘들 때, 개발하면서 했던 행동들..

앞에서 이야기했듯이 프로젝트 주제를 선정하는 데 많은 어려움을 겪었다.

아무래도 좀 더 잘해보고 싶다는 생각을 하고 있어서 그랬던 것 같다.

나는 대학교 때 창업한 경험이 있다. (아무것도 모른 상태로 시작했지만..)

기획부터 시작해서 개발까지 동시에 하다 보니 전체적인 흐름을 보는 것이 중요하다고 생각하고 있었다.

왜냐하면 한정된 자금에서 아웃풋을 내려면 실수가 없어야 한다는 생각을 하고 있기 때문이다.

그러기 위해선 실수를 최소로 줄이기 위해서 전체적인 흐름을 봐야 하고, 그 뒤에 구체적인 부분을 봐야 한다고 생각했다.

그러다 보니 이 사이드 프로젝트에서도 나는 개발에서도 향후 내용까지 생각하고 있었다.

예로 다른 사용자들도 쓸 수 있어야 되고 로그인 회원가입, 소셜 로그인, 사용자 대시보드, 운영은 어떻게 하면 될까, 사용자 타깃은 누구지, 푸터에 뭐가 들어가면 좋을까, 헤더에 뭐가 들어가면 좋을까, 메뉴는 뭐로 구성되면 좋을까 등등 모든 걸 생각하고 있었다.

그러다 보니 개발 시작은 자연스럽게 지연되고 있었다. (이때 주제 선정도 어려움을 겪고 있었는데.. 개발도 그렇다니ㅋㅋㅋ 하하..)

나는 바보 멍충이였구나

1주 차 때, 홀맨님께서 슬랙에 글을 올리셨다.

수년 간 경험을 돌아봐도 오랜 고민이 좋은 결과를 낳은 적이 단 1번도 없습니다.
일단 빠른 공개를 해주세요. 포트폴리오라고 힘줬다가 몇 개월 지나도 완성 못하는 이유는
완성에 집착하기 때문이에요. 프로그램엔 완성이 없습니다.
일단 뭐가 됐든 사용할 수 있으면 됩니다.
라고 말씀하신걸 보고 충격을 받게 되었고, 자잘한 생각을 그만두고 개발을 시작할 수 있었다.

이 피드백을 보고 위에서 말한 로그인, 회원가입 등이 사실 내 프로젝트의 주요 관심사는 아녔다.

즉, 일단 내 프로젝트에선 생각할 필요가 없는 부분들이었다… 주 관심사가 따로 있었다.

그렇게 나는 프로젝트 개발에 집중을 할 수 있었다.

프로젝트 개발 시작

처음 프로젝트를 시작하면서 처음 개발환경을 만드는데 시간을 많이 사용했다. 1주 차부터 3주 차까지 넘어가서 신경 썼던 것 같다.

먼저 웹팩부터 바벨등 우리가 기존에 과제를 진행해오면서 접했던 셋팅을 최대한 손으로 작성했다.

각 설정이 무엇을 의미 하는지 파악하고 넘어가려고 했다. 이 부분에서 시간이 많이 걸렸던 것 같다.

우선순위 똥망

홀맨님께서 또 주옥같은 조언 글을 올리셨다.

홀맨님 피드백

홀맨님 피드백

홀맨님 피드백

홀맨님 피드백

“사용자가 이번 주 일요일에 쓴다고 생각하면서 만들어보세요.”

“오 마이갓 이번주에 당장 사용한다고?…” 충격이었다.

나는 처음에 헤더 부분부터 작성하고 있었다… 헤더 부분은 사용자가 쓸 수는 없잖아..

나는 헤더 부분을 퍼블리싱하고 기능을 넣고 차례대로 가려고 잡았던 우선순위가 잘 못 되었다는 것을 알게 되었다.

(그래서 앞으로 우선순위를 잘 잡았냐고? 잡으려고 노력했다!)

나는 개선해야 할 점이 많구나! 배울 점도 많고! 매우 좋다.

홀맨님 피드백

뭔 고민과 뭘 해보았나

프리젠테이션 컴포넌트가 먼저냐 컨테이너가 먼저냐

나중에 생각해보면 어린 생각이지만.. 개발하면서 프리젠테이션 컴포넌트와 컨테이너 컴포넌트 중 어떤 것을 먼저 작성해야 되는지 고민을 좀 하게 되었다.

처음엔 컨테이너 먼저 만들고 프리젠테이션 컴포넌트를 만드는게 뭔가 불편했다.

부품이 먼저 있고 그 부품을 조립해야 되는 거 아닌가?

그래서 프리젠테이션 컴포넌트를 먼저 작성하고 컨테이너를 작성하는 식으로 해보았다.

하지만

프리젠테이션 컴포넌트를 먼저 작성하고 거기에 상태를 입혀 컨테이너를 만들려고 하다 보니 상태에 따라서 프리젠테이션 컴포넌트를 계속 건들게 되더이다…

여기에서 문제가 뭘냐는 생각을 해보니..

처음부터 컴포넌트를 분리해서 생각하려고 한 행동들이 문제였다.

사실 컨테이너에다가 먼저 코드를 작성하고 나중에 그 부분을 분리해서 프리젠테이션 컴포넌트로 만들면 됐을 텐데…

이걸 알고 나니 행복함을 느꼈다.

서서히 파악해나가는 테스트

기존에 과제 진행하면서 상태에 대한 useDispatch, useSelector를 목킹 하면서 태스트 코드를 작성했다.

한번도 useState을 목킹하고 테스트 해본 적이 없었는데 이번에 경험할 수 있었다.

스타일 컴포넌트 뭐야..

스타일 컴포넌트가 많아지고 있다. 이를 어떻게 하면 좋을지 고민하고 있다.

파일로 분리해서 하는 게 좋을 것인가..

분리한다면 어떤 조건일 때 분리하는 게 좋을까.

재사용이 가능한 부분이면 분리하는 게 좋겠는걸 이라는 생각을 초반에 하게 되었다.

재사용 되지 않는다면 굳이 분리하지 않기로 했다.

괜히 분리했다가 한쪽에서 수정하면 다른쪽 에서도 그 수정에 대한 대응을 신경 쓰고 있어야 했었다..

디자인을 어떻게 해야 되냐..

디자인도 내가 마음에 드는 걸 찾기까지 많은 시간이 흘렀던 것 같다.

나는 심플한 디자인이 좋았다. 깔끔한!!

핀터레스트에 있는 모든 템플릿을 본 것 같다..

그러다가 그 중 네이버 Expert 페이지와 프로그래머스의 디자인을 참고했다.

나중에 UI,UX 공부도 해보고 싶었다.

백엔드 부분을 생각해보기

백엔드 구현해야지~

‘프론트엔드는 백엔드로 부터 데이터를 받아야 된다’ 라는 생각을 가지고 있었다. 그러니깐 백엔드는 필수지! 라고 생각했다.

그래서 시작할 때, 백엔드도 개발해야겠다라는 생각을 가지고 당장 구현은 당장 힘드니 Webpack-Dev-Server안에서 사용할 수 있는 Mock api를 세팅하였다.

세팅하면서 Json형태로 받을 데이터들에 대한 구조를 작성하는 데 피곤함을 느끼기도 했다.

빈번하게 수정되었기 때문이다.

나중에 백엔드 구성은 어떻게 했나요

나중에 프로젝트 완료될 때, 백엔드는 아에 만들지도 않았다. 그리고 mock api 쓰지도 않았다.

간단하게 파일에서 데이터를 불러오게 했다.

홀맨님 피드백

테스트 작성하기

테스트 코드를 작성하는 건 어렵다.

익숙하지 않은 이유도 있고, 무엇을 테스트해야 할지 어떻게 테스트해야 할지 감을 잡기가 어려웠다.

그래서 규칙이 있는 게 중요하다고 생각했다.

홀맨님께서 말씀해주신 규칙을 따라보자.

1. 실패한 단위 테스트를 만들기 전에는 제품 코드를 만들지 않는다.
2. 컴파일이 안 되거나 실패한 단위 테스트가 있으면 더 이상의 단위 테스트를 만들지 않는다.
3. 실패한 단위 테스트를 통과하는 이상의 제품 코드는 만들지 않는다.

하지만 TDD 하면서 또 또 또! 테스트 코드에 없는 걸 구현하고 있다.

[미래에서 왔음] 프로젝트가 완료될 때쯤엔 많이 고쳐졌다.

이봐요..나는 CI / CD 구성 처음 해봐요

있는 거 이용만 해봤지 구성은 처음 해보았다. 환경 세팅과 같이 진행했지만, GitHub Pages에 배포하는 설정을 하는 데도 많은 시행착오가 있었다.

결론적으로는 깃 허브의 action을 처음 써봤는데, 너무 좋았다. 테스트까지 자동화시켜서 반복적인 작업을 대신해주니..

전에 창업 회사에서는 서비스 부분과 구현 부분에 포커스를 맞추다 보니이런 건 생각하기가 힘들었다.

현재 이 블로그에도 Github Actions을 이용하여 CI/CD를 구성해놨다.

정말 뜻깊은 시간이었다.

실수들이 잦았다네..

수많은 실수를 했다. 그중에서 가장 실수를 고치는데 시간을 많이 쓴 부분이 있다.

  1. import 할 때, default export 문으로 모듈을 내보내지 않았는데, default export 문으로 내보낸 것처럼 import 하고 있었다.
// index.js
export { functionName }

// other.js
import functionName from './images/index.js' (X)

import { functionname } from './images/index.js (O)
  1. 테스트 코드 작성할 때, context() 메서드 안에 it()을 사용하지 않고 작성했다.

이건 신기하게 오류를 내뱉는 경우도 있었고 아닌 경우도 있었는데, 오류가 발생하지 않아서 나중에 리듀서 부분에 단체로 안 쓴걸 발견해서 it() 안으로 코드를 넣어줬다.

그래서 결론적으로 뭘 느꼈냐

2주 동안 많은 생각과 과정을 통해 성장한 시간을 가졌다.

프로젝트를 진행하면서 어떤 부분에 관심을 두고 진행해야 되는지 좋을지에 대해서도 알 수 있었다.

내 생각들을 점검해 보는 시간을 가질 수 있었다.

CI/CD도 구성해보는 경험 해보지 못했던 경험들을 많이 했다.

좀 더 좋은 방향으로 개발하고 싶다는 생각을 많이 하게 되었다.

한 일 리스트

  • 주제 선정
  • 기능 생각하기
  • 개발 환경 세팅(lint, webpack, babel, test 등)
  • 반응형 헤더 영역 퍼블리싱하기
  • 헤더 영역에 로그인/로그아웃 시 보여주는 부분 다르게 보여주기
  • 인터뷰 질문 리스트 페이지 작성
  • 카테고리에 따른 데이터 불러오기
  • 질문 리스트 보여주기
  • 인터뷰 질문 리스트 페이지 디자인
  • 그 외 디자인이 필요한 부분 적용
  • 코드숨 과제 CI 적용해보기(시행착오가 엄청 많았음)

추가

윤석님 피드백

이 부분은 그때 당시에는 그냥 정말 물어보는 건 줄 알았는데..

나중에 생각해보니 정말 무엇을 할 수 있는지 인터뷰 질문들을 확인을 할 수 있는지 보기엔 알 수 없었기 때문에 물어보신 거 같다.

즉, 문서를 작성하는 데 부족함이 있다는 의미였던 것 같다.


@kwonmory
성장을 위해 노력하고 있는 모리입니다.

깃허브