8월말부터 부스트캠프 멤버십이 시작되었다. 멤버십의 시작은 학습스프린트로, 2주간 주어진 프로젝트를 구현하기위해 기획하고 공부하고 개발하는 과정이다.
2주라는 짧은 시간에 혼자서 개발하는 것인만큼 크게 어려운 과제가 나오진 않았다. 그래도 아직 제대로된 개발 경험이 없던 나에게는 생각보다 어렵게 다가왔다.
나는 프로젝트 개발에서 가장 중요한 부분이 프로젝트를 어떻게 진행할지에 대한 설계를 세우는 단계라고 생각한다. 그래서 과제를 받고 하루동안은 2주일동안 어떻게 개발을 진행할 것인지, 구현해야할 기능은 무엇인지, 프로젝트의 구조, api 구조는 어떻게 잡을 것인지 등등... 프로젝트를 설계하는데만 시간을 쏟았다.
그런데 그렇게 시간을 쏟아도 제대로 된 계획이 잡히지 않았다. 기능을 어떻게 나누어야 하는지, 내가 정해진 시간동안 이걸 할 수 있을지, 등 다양한 부분에서 문제가 발생했다. 그리고 설계가 부실해지니 당연히 개발 도중 초기에 생각해두었던 데이터 형식이 맞지 않거나 설계했던 api 중 사용하지 않는 것도 생기기도 하였다. 또, 계속해서 수정할 사항들이 생기니 그때그때 코드를 수정하느라, 코드가 점점 더러워지기도 하였다.
이러한 일이 발생한 이유는 여러개가 있겠지만, 나는 경험의 부재가 가장 크다고 생각한다. 경험이 없으니, 내가 어디까지 할 수 있는지, 프로젝트의 기능을 어떻게 나눌 수 있을지, 데이터는 어떤 형식으로 다루는 것이 좋은지 등 설계를 할 때 고려해야할 다양한 사항들을 다룰 수가 없었다.
또, 경험의 부재와는 별개로 설계에 대한 지식이 없다는 것도 큰 이유라고 생각한다. 사실 코딩하는데 필요한 기술이나 CS 지식들만 공부해왔지, 설계에 대해서는 제대로 공부해본 적이 없다. 비록 이전에 설계 과목을 수강하긴 하였으나, 시간이 오래 지나 거의 기억이 나지않고 그 당시에도 그렇게 깊게 배우지는 않았다. 설계라는 것도 당연히 규칙이 있을 것이고, 방법이 있을 것인데 이런 지식 없이 설계를 시작했던 것이 문제였던 것 같다.
이번 주차 프로젝트의 설계는 아쉬운 점이 많았다. 조금 더 잘할 수 있었음에도 그러지 못한 것에 아쉽고, 조금 더 많은 경험을 쌓아오지 못한 것에 또 아쉽다. 그래도 나에게 모자란 것이 무엇인지 알게 되었고, 설계를 할 때 어떤 것들을 고려해야하는지 조금 더 알 수 있게 되었다. 앞으로도 계속 많은 프로젝트들을 설계하고 개발할 상황이 많을 것이니, 점점 더 배워나갈 수 있을 것이다.
나는 솔직히 내가 Git을 조금 만질 줄 안다고 생각했다... 오만이었다. 이번 프로젝트에서 PR의 병합 정책을 Rebase and Merge로 진행했었다. 나는 Rebase and Merge를 이번 프로젝트에서 처음 들었었고, Rebase and Merge도 일반적인 Merge 정책과 별차이 없을 줄 알았다. 그래서 PR이 병합된 후, 추가적인 명령없이 로컬에서 그냥 개발을 진행하였다. 그런데 Rebase and Merge는 Rebase되는 과정에서 커밋 객체가 변한다!! 당연히 내 로컬의 커밋과 원격의 커밋이 서로다른 객체가 되므로, 다음번 PR에서는 Merge Conflict가 발생한다. 하지만 나는 그걸 몰랐었고... 나중에 그걸 해결한다고 고생을 좀 했다.
그래도 한두번 문제를 겪고, Rebase에 대해 제대로 공부하였고 이 과정에서 이전에 공부해뒀던 Git의 내부구조가 매우 큰 도움이 되었다. Rebase를 사용하면 왜 커밋 객체가 바뀌는지에 대해 쉽게 이해할 수 있었고, 그 이후에는 문제가 발생하는 일이 없었다.
이 문제를 해결하면서 Rebase로 브렌치를 합치는 것 말고도 다른 명령어들에 대해 많이 학습하였다. rebase interaction 모드로 커밋 객체를 수정하는 방법도 공부하였고, cherry-pick으로 커밋객체를 가져오는 것도 같이 공부할 수 있었다. 또, PR의 병합 정책은 단순 Merge말고도 Rebase and Merge, Squash and Merge로 총 3가지가 있으며, 이 것들이 어떤 동작을 하는 지도 알 수 있게 되었다.
이번 프로젝트를 하면서 이전보다 Git에 대해 꽤나 많이 알게되었다. 물론 아직도 많이 모자라고 알지 못하거나 이해하지 못하는 기능들이 있겠지만, 예전보다 나아졌으니 좋은 성과이다.
재사용이 가능하도록 코드를 작성한다는게 진짜 많은 생각과 고민을 해야한다는 것을 느꼈다. 코드를 재사용할 수 있게 추상화하는 것부터 추상화된 함수의 인자를 어떻게 할지, 리턴값은 무엇으로 둘 지, 또 그 함수를 어느 파일에 위치시킬지까지 등, 많은 고민을 하면서 코드를 작성했다.
그런데 고민을 하면 할수록 점점 더 미궁에 빠지는 기분이었다. 이런 것까지 분리를 하는게 맞는지? 이것을 분리하면서 얻는 이득이 기존 코드보다 클지? 등 많은 생각을 하게 되었다. 물론 재사용이 가능하도록 코드를 분리하는게 좋다지만, 단순히 잘게 나누기만해서 좋다곤 할 수 없으니 이런 생각들을 하게 된 것 같다.
또 클린 코드를 작성하는 것도 매우 힘들었다. 이번 프로젝트가 백엔드 비중이 적어서 그런지 백엔드 영역은 나름 가독성 좋게 클린 코드를 작성한 것 같은데, 프론트엔드 영역이 경험이 적기도 하고 양이 많다보니 점점 코드가 더러워졌다. 또, 웹팩과 같은 번들러를 사용한 것이 아니라 한 두개의 파일에서 작업을 하다보니 점차 코드의 양이 비대해지고 점점 알아보기 힘들게 되었다.
최근에는 단순히 코드를 짜는거보다 나중에 알아볼 수 있도록 클린하게 코드를 작성하는 것에 중점을 두고있는데, 매번 느끼는 것이지만 이것은 정말 어려운 일이다. 앞으로도 항상 고민하고 노력하다보면 언젠가 지금보다는 쉬워질거라 생각하며 공부해야겠다.
나는 백엔드쪽으로 진로를 생각하고 있는 만큼, 프론트엔드를 그리 많이 다루어보지 않았다. 그런 상황에서 프론트 영역을 개발하니 태그의 클래스명을 정하는게 너무너무 힘들었다. CSS 명명 규칙으로 BEM이나 SMACSS, OOCSS 등 다양한 규칙들이 존재하는데, 처음에는 이러한 규칙을 사용하지 않고 나만의 규칙으로 클래스나 ID 명을 지어주었다. 그런식으로 진행하니, 나만의 규칙은 사실상 규칙이 아닌 그냥 내맘대로 짓는 것이나 다를게 없어졌다. 그러다보니 내가 지은 클래스명을 봐도 이게 뭘 나타내는 건지 알기 힘들었고, 여러 요소들간의 관계도 나타나지 않았다.
그래서 추후 BEM 방식을 적용해보려 했으나, 이미 저질러놓은 결과물이 너무 많아 이번에는 적용을 하지않았다. 이번 프로젝트에서는 비록 똥같은 CSS 코드가 나왔으나, 다음 프로젝트에서는 조금더 생각을 하고 보기 좋은 CSS 코드를 만들어야 겠다.
이번에 만든 프로젝트를 Heroku를 통해 배포를 진행하였다. 덕분에 Heroku와 Nodejs, Database를 연동하는 방법을 알게되었다. 또한, 이전에 작성한 글인 git 서로다른 브렌치에 push하기와 Git 파일 및 폴더명 대소문자 변경도 Heroku에 배포하는 과정에서 알게되었다.
Git Rebase나 Cherry-pick과 같은 명령어들을 이해하게 되었다. 그리고 PR의 병합 정책들에 대해 이해하게 되었으며, Git의 병합과정 혹은 로그 관리 중 문제가 발생하였을 때 이를 해결하는 방법도 여럿 익혔다. 마지막으로 이전에 공부했던 Git 내부구조를 이번 프로젝트를 통해 더 깊게 이해할 수 있었다.
BEM, SMACSS, OOCSC라는 것에 대해 알게되었다. 아직 완벽히 이해한 것도 아니고 잘 사용하지는 못하지만, 내가 뭘 모르는지 모르는 단계보다는 낫기 때문에 앞으로 차차 공부해나갈 것이다.
프론트엔드 영역에서 사용하는 DOM API들을 많이 다루었다. 기존에는 React같은 프레임워크를 사용해서 DOM API를 직접 다룰 일이 없었는데, 이번 기회에 좀더 로우한 레벨의 API들을 많이 다루어보았다. 현업에서는 더 추상화된 프레임워크를 사용한다 할지라도, 프레임워크를 걷어낸 저차원의 함수를 이해하는 것은 중요하다고 생각하기에 좋은 경험이 되었다.
2주일동안 프로젝트를 진행하면서 내가 아직 잘 모른다는 것도 많이 느꼈고, 반대로 이미 알고있던 것들을 다른 사람들과 나누면서 더 깊게 이해하기도 했다. 이번주는 아무래도 처음인만큼 아쉬웠던 점들이 많다. 다음 주에는 조금 더 아쉬움이 없도록 해봐야겠다!