[태고의 달인 서열표] 1. 프로젝트 준비

동네 오락실에 태고의 달인이 거의 10년 만에 다시 들어왔다. 그것도 최신 버전으로.

 

그 동안은 어쩌다 간 곳 근처의 오락실에 태고가 있으면 해보는게 전부였는데 모처럼 동네에 왔으니 제대로 해보려고 카드도 구입하고 서열표도 참고하면서 하려고 이미지로 저장을 미리 해뒀는데...

 

생각보다 잘 안보였다. 보려면 못볼 건 없는데 가뜩이나 제목 표시도 다르니 보면서 곡을 찾다보면 100초가 금방 다 가버렸다.

 

그래서 마침 프론트엔드 사이드 프로젝트를 하나 했으면 하는 참에 잘됐다 싶어서 이 서열표를 웹 페이지로 구현하기로 결정.

현재는 일단 데이터가 전부 들어가진 않았지만 페이지는 구현한 상황이다.

태고의 달인 난이도 서열표 (focused-bartik-b7a742.netlify.app)

 

이번엔 절대로 실수를 반복하지 않겠다

다행히 Sunlapse는 마무리까지 했지만 지금까지 한 사이드 프로젝트가 중간에 많이 엎어졌었다. 시작 전에 왜 그랬을까 돌이켜보니 이런 문제가 있었다.

1. 확실하게 기획을 하지 않고 시작함
2. 새로운 기술을 과하게 사용하려고 함

기획부터 차근차근

기획을 짜지 않고 코딩부터 시작하다보니 다음 문제들이 있었다.

1. 처음에는 생각하지 않은 기능을 중간에 생각해서 추가하다가 이도저도 아니게 되거나 프로젝트가 너무 무거워짐
2. 중간에 개발이 끊기면 기억이 나지 않아 결국 그대로 중단

그래서 이번 프로젝트는 꼭 마무리를 하겠다는 다짐 하에 프로토타이핑 툴로 기획을 하고 시작했었다. 내가 사용한건 JustInMind라는 툴로 다른 유명한 툴에 비해 웹 개발자에 직관적인 인터페이스라 사용하게 되었다.

프로토타입으로 만든 페이지 기획

현재 구현한 페이지

첫 번째 사진이 프로토타이핑 툴을 이용해 만든 이미지. 두 번째가 현재 구현한 페이지이다. 구현하면서 실제 적용했을 때 아니다 싶어서 바꾼 점이 몇 개 있고 footer 등 구현 이후에 새로 추가한 점이 있긴 하지만 기본적으로는 초반에 의도한 대로 거의 그대로 구현할 수 있어서 만족했다.

 

아이러니한 것은 첫 번째 이미지를 실제 개발할 때는 거의 참고하지 못했다는 점인데 처음으로 만든 프로젝트 저장소를 지워버리다 파일까지 지워졌다고 생각했기 때문이다. 이 글을 위해 혹시나 찾아보니까 휴지통에 있더라.

 

그렇지만 오히려 초반 기획의 힘을 더욱 느낄 수 있던 기회였다. 저렇게 며칠을 걸려서 만들고 나니까 이미지가 굉장히 선명하게 남았고 이후에도 이전 프로젝트처럼 흔들리지 않고 개발을 할 수 있었다. 하는 동안 몇 번이고 바로 개발에 들어갈까라는 유혹에 빠질 뻔했지만 참고 끝낸 보람이 있었다.

유혹에 당하지 않기

신기술 도입을 과하게 하는건 이런 문제가 있었다.

1. 단순 기술 스택용으로 기술을 도입하다보니 규모에 비해 불필요한 경우가 생김
2. 학습을 하면서 구현까지 하다보니 미숙하고 동시에 가볍게 시작한 프로젝트가 스트레스가 됨

이번 프로젝트는 React를 이용하기로 결정했다. React는 이전에도 엎어진 프로젝트나 개인 공부에서 몇 번 사용해본 적이 있었기 때문에 어느 정도 익숙한 점이 있었고 기존에 class 형식에서 Hooks를 이용한 함수형으로 바뀐 것만 적용해보기로 했다. 그런데 또 React를 쓰게 되고 회사들의 지원 자격 요건을 보니 아른거리는 기술이 있었다.

 

바로 Redux와 Typescript. 많은 회사들이 React와 같이 쓰고 있어서 한번 욕심이 났다. 그래도 일단 Redux는 아예 써본 적이 없어서 됐다하고 넘어갈 수 있었는데 Typescript는 뭔가 해볼만해 보였다. 그래서 처음에는 Typescript를 사용하면서 프로젝트를 진행했었는데 이게 React에서 사용하려다보니 생각보다 직관적이지가 않았다. 내가 Typescript를 아주 잘 알고 있는 것도 아니었고. 결국 그러다 한번 프로젝트를 엎었고 그 과정에서 위에서 말했듯이 프로토타입 이미지가 날아가버리는 참사도 발생해버렸다.

 

다행히 정신을 차리고 React만 사용해서 프로젝트를 완성할 수 있었다. 결국 또 처음에 재미로, 필요해서 만드려던 프로젝트를 어느새 뭔가 보여주기 용도로 써버릴까하는 유혹에 빠질 뻔했던 것이다. 앞으로는 사용할 기술도 딱 정해놓고 시작하기로 했고 새로운 기술을 적용하고 싶으면 우선 완성하고 이후에 적용해서 수정해보는 방식으로 하기로 마음 먹었다.

Git도 실제처럼

저번 프로젝트와 이번 프로젝트 사이에 회사에서 들어간 프로젝트에서 실제 업무에서 사용 중인 Git의 구조와 브랜치 관리를 접할 수 있었다. 나도 이번에는 그걸 참고해서 기능별로 브랜치를 구분해서 만들고 혼자 PR 요청도 하고 수락도 하는 식으로 구성해봤다. 혼자하다 보니 중간중간 굳이 이래야하나 싶은 불편함도 있긴 했지만 또 이렇게 하다 보니 오히려 코드 작성하면서 기능별로 분리하는 선이 잘 보이는 느낌이었다. 기존에 main 브랜치에서 한번에 할 때는 개발이 중간중간 왔다갔다하기도 하고 그랬는데 이렇게 하니까 하나씩 컴포넌트별로 마무리를 하면서 넘어갈 수 있었다.

 

이런 과정을 통해 모처럼 돌입한 사이드 프로젝트를 사실상 완성 단계까지 마무리할 수 있었다. 그동안 아이디어만 꺼내고 그대로 도중에 멈춰버린 프로젝트들이 아쉽기는 하지만 그래도 또 그런 경험이 이번 프로젝트를 여기까지 이끌어줬다고 생각해야지.