[엘리스 1차 프로젝트] 첫 프로젝트 회고

"2주간의 웹 서비스 개발 프로젝트가 끝났다!"

엘리스 SW 엔지니어 트랙 3기에 와서 처음 한 프로젝트가 끝이 났다.
개발부터 배포까지의 과정을 한 것은 처음이었고, 정말 하루 하루가 눈뜨면 코딩 눈감기 전에도 코딩 생각뿐이었던 것 같았다.
하루에 잠자는 시간을 제외한 모든 시간을 개발에 쏟으면서 대망의 쇼핑몰 웹 만들기를 성공리에 마쳤다.

1. 프로젝트를 진행하며 좋았던 점

◆ 협업

우선, 누구 하나 빠짐없이 열정 가득하고 열심히 하는 팀원들을 만났다는 것이 가장 좋았다.🥰
바닐라 자바스크립트 프로젝트이기 때문에 여러 가지 한계점이 존재함에도 의지와 열정으로 어려운 점들을 모두 메워줬기에 해낼 수 있었다.
또한, 매일 하루도 빠짐없이 진행하는 스크럼으로 개발의 방향성을 명확히 하고 소통에 부족함이 없었기에 서로가 맡은 영역에 대한 내용을 공유하고 같이 고민해줄 수 있었던 것이 좋았다.

노션에 매일 회의록을 작성하고 Git Lab의 Wiki에도 스크럼 회의 내용을 정리하여 올렸다.
스크럼 회의 시간은 1주차에는 오전 11시에 진행하였으며, 본격적인 개발 속도가 붙은 2주차부터는 새벽 3시 이후에 하루를 마무리하는 경우가 많아 다음날 오후 1시에 진행했다.

개발 중 발생한 문제에 대해서는 실시간으로 디스코드 채널에 팀원들에게 공유하며 서로의 문제에 대해 같이 고민하고 해결 방안을 모색하기도 했다. 혹은 Git Lab에 issue를 생성하여 발생한 이슈에 대한 내용을 정리하여 공유하기도 했다.

스크럼 시에는 Y:어제한 일, T:오늘 해야 되는 일, B:잘 안되는 일의 세 가지로 나누어 미리 노션 회의록에 작성한 후 회의를 진행했다. 회의록에 보다시피 우리 팀은 전원의 합의하에 "영어이름/닉네임" 을 사용하고 모두 "반말" 을 사용함으로써 굉장히 빠르게 친밀해지며 개발에서도 훨씬 원활한 의견 공유가 일어났다.

사실, 처음에는 반말을 한다는 것이 너무나 익숙지 않고 영어이름도 없었기 때문에 오히려 낯설었던 기분이었는데, 막상 시간이 지나다 보니 팀원들을 훨씬 친밀하게 느끼게 했고 그만큼 수월하게 내 의견을 말하고 상대방의 의견을 수용하게 되었다. 나는 첫 영어이름 "Mandy"를 사용하였다! 앞으로 있을 프로젝트에서도 영어이름을 사용하게 된다면 Mandy로 불리고 싶다.ㅎㅎ

개발에 속도가 붙을 수 있었던 것은, 백엔드 2명 외에도 프론트엔드 3명이 각자 원하는 화면을 맡아 구현하기로 했기 때문이 가장 컸다. 각자가 맡은 영역에 대해서 몰두하다 보니 책임감과 속도가 붙는 것은 열정 있는 팀원들에겐 당연했던 것 같다.

모두가 서로 의견을 적극적으로 수용해주고 자신의 의견도 잘 내주었기에 초반 기획 시기에 많은 시도가 있었고, 1주차 목요일에야 모든 게 확정되어 본격적 개발에 들어갔다. 그에 따라 시간이 촉박해지는 부작용(?)🤣 도 있었지만, 오히려 그렇게 할 말 다해보고 해볼 수 있는 시도는 다해봤기에 한 번 정해진 노선은 프로젝트 끝까지 절대 안 바뀌었고, 개발에 있어서 엄청난 가속도를 붙이며 마무리할 수 있었다.

◆ git 실전 사용

git에 대한 공부는 엘리스 SW 엔지니어 트랙에 합류하기 전 짧게 했었는데, 얄코님의 git 강의를 들었던 게 전부였다. 심지어 그마저도 완전하게 수강한 게 아니므로 모르는 게 많은 상태였다. 그런 와중에 git 관리 시스템으로 Git Hub 가 아닌 Git Lab을 사용하다 보니 더욱더 헷갈리는 게 많아져서 어렵게 느껴졌다. 그렇지만, 처음으로 팀 단위로 git을 사용하고 서로 git에 대해 모르는게 있다면 알려주고 정보를 공유하면서 우여곡절 끝에 프로젝트를 master - dev - dev-FE / dev-BE 로 브랜치 전략을 세워 사용했다.

프론트엔드의 경우에는 화면 단위로 브랜치를 생성해서 사용했고, 백엔드는 작성자 이름 단위로 브랜치를 생성하기도 하고 상황에 따라 브랜치 명을 작명하기도 했다.

처음 사용할 때는 많이 헤매었지만, 점차 익숙해지면서 테스트 완료된 건에 대해서는 수시로 commit, push를 생활화하며 개발하게 되었다. 위 사진에서 보다시피 2주 안에 653 commit을 수행했는데, 1주차엔 200여 commit이었으나 2주차에 400 commit을 더하여 주차별로 코드리뷰를 해주시는 프론트엔드 코치님께서 매우 놀라시며 좋아하셨다.(?)
git을 실전에서 사용해보며 git에 대한 유의미한 사용 경험을 쌓은 것 같아 의미 있었고 좋았다.

◆ 코드 리뷰

엘리스에서는 프로젝트 진행 기간 2주간 매주 코드 리뷰, 매일 오피스아워에 프론트엔드/백엔드 코치님이 번갈아가며 하루의 이슈를 답변해주시는 시간을 갖게 해주었다. 그 덕에 프로젝트 진행에 많은 도움을 받고 수월하게 진행할 수 있었다.
오피스 아워에는 프론트엔드 코치님과 백엔드 코치님 두 분 모두 질문 드린 사항에 대해 명확하고 꼼꼼하게 정리하여 답변을 해주셨고, 개발에 몰두하여 이슈나 에러를 금방 해결해버린 질문이 적거나 없는 날에는 개발이나 취업에 대한 여러 가지를 답변해주셔서 많은 도움이 되었다. 특히, 나는 프론트엔드를 맡았기에 프론트엔드 코치님께서 로직이나 ui에 대한 피드백을 주실 때 정말 많은 깨달음을 얻고 빨리 말씀 주신 부분을 수정하러 뛰쳐나가고 싶었다 ㅋㅋㅋ😆

한 주의 끝에는 그 주의 마지막 Merge Request를 기준으로 코드 리뷰를 comment로 달아주셨는데, 나 스스로 고민했던 내용도 있었고 놓치고 있던 부분도 있어서 아주 유익했다. 비록, 짧은 시간 내에 완성해야 하는 프로젝트의 특성상 리뷰해주신 모든 내용을 반영할 수는 없었지만 추후 리팩토링을 진행할 때 꼭 반영하리라 마음먹었다.

◆ IndexedDB 공부

내가 맡은 상품 상세화면, 장바구니 화면은 엘리스 측에서 개발 시 요구된 사항이 분명했다.
장바구니 관련 데이터는 백엔드 데이터베이스가 아닌, 프론트단(localStorage, sessionStorage, indexedDB 등)에서 관리되어야 하는 것이었다. 또한, 사용자가 새로고침해도 장바구니에 상품이 그대로 남아있어야 한다는 것 외에도 장바구니 화면에 대한 요구사항이 굉장히 많았다.
나는 3가지 웹 스토리지 중 무엇을 사용해야 할 것인지에 대해 다른 누구도 아닌 나 스스로 결정해야 했기에 고민이 많았다.
하지만, 여러가지 비교 글을 읽고 나니 엘리스에서도 학습했고 용량이 커서 데이터 용량에 대한 걱정을 덜 수 있으며, 비동기적으로 동작하고 브라우저 종료 시에도 휘발되지 않는다는 점, 데이터가 자바스크립트가 읽을 수 있는 형태로 저장/읽기가 가능하기에 JSON.parse() 나 JSON.stringify() 하지 않아도 된다는 점에서 편리함과 처음 써보는 수단에 흥미를 느끼고 indexedDB를 장바구니 기능 구현에 사용하기로 했다.

사진과 같이 쇼핑몰에서 개발자 도구로 IndexedDB 를 확인할 수 있다.
IndexedDB에 대해서는 이미 수많은 블로그에서 정리하였고, 그에 대해 정리하는 것은 별도의 포스팅이 좋을 것 같아 이번 회고에서는 간략하게만 요약해보려 한다.
우선, IndexedDB는 말 그대로 DB처럼 동작한다. DB를 먼저 생성해줘야 하고, 그 안에 데이터가 저장될 스토어를 생성하고 열어줘야 하며 스토어에서는 트랜잭션을 사용해 특정 객체 저장소에 접근할 수 있다. readwrite/readonly/versionchange 의 3가지 트랜잭션 모드가 있으며, 나는 DB의 version을 업그레이드할 예정이 없었으므로 versionchange은 제외하고 사용하였다. 다만, 사용에 대해서는 블로그 글들을 봐도 쉽게 와 닿지 않았기 때문에 엘리스에서 인스타그램 클론코딩 학습 때 게시글 작성/수정/삭제에서 indexedDB를 사용했던 것을 떠올리고 해당 부분을 다시 학습하면서 이해할 수 있었다.

indexedDB를 사용했기에 화면을 벗어나거나 브라우저를 종료해도 장바구니의 내용은 저장되며, 수량이나 체크된 상품 등 여러 가지 정보들을 손쉽게 저장하고 읽어낼 수 있었다. 또한, 이 화면의 이전 화면인 상품 상세 페이지 화면과 이 화면의 다음 화면인 주문결제 화면에서도 indexedDB 를 이용했다. 장바구니에서 체크된 상품만을 주문서 작성하며, 체크된 상품이라는 사실은 indexedDB에 저장되기에 다음 화면인 주문결제 화면에서 이를 활용하기 수월했다.

다만, 장바구니 화면에서는 상품에 대한 데이터를 키값인 상품 id를 이용하여 fetch 함수로 백 데이터를 GET 요청하여 화면에 그려주도록 했다.
이유인 즉슨, 이미 indexedDB에 상품id를 포함하여 상품 상세화면에서 fetch로 GET 한 상품에 대한 정보를 담고 있지만 만약 관리자가 상품을 수정하거나 삭제할 경우 상품 정보가 최신상태가 아니기에 주문 이후 상품 사진이나 정보가 표시되지 않는 오류를 발생시킬 수 있으므로 항상 최신의 상품정보를 가져오기 위해 fetch로 상품 정보를 GET 요청해와 그려준다.

이 부분에 대해서는 추후에 조금 더 좋은 방법이 있다면 리팩토링 해보고 싶었고, indexedDB를 제어하는 코드를 처음 작성해 보았기에 많은 부분이 서툴고 모자랐지만, 최대한 에러나 버그가 나지 않도록 fix 하는 것에 신경 써가며 개발했다.
이러한 부분들 덕에 이번 프로젝트에서 굉장히 좋은 공부가 되었고 나머지 웹 스토리지들도 사용해보고 싶다는 생각이 들었다.

프로젝트 마지막 날 다른 팀들의 발표가 있기 전, 구현된 쇼핑몰을 구경하는데 나와 같이 indexedDB를 사용한 팀은 1팀밖에 발견하지 못했다. 잘만 사용하면 굉장히 효율적이고 편한 방식이지만 이해하는 게 쉬운 내용은 아닌 것 같았다. 또한, 내가 indexedDB의 특징인 데이터에 index를 적용해 indexedDB를 사용한 게 아니므로 나조차도 완벽하게 모든 기능을 활용한 게 아니다.

비동기 방식이 디폴트이기 때문에 동기 방식의 처리가 필요할 경우 async,await / Promise와 같은 비동기를 동기식으로 처리하는 방법을 사용해야 한다. 이 부분에 이해나 숙지가 부족하면 완벽하고 능숙하게 다루기 어렵다는 점이 단점인 것 같다. 나도 동기 방식으로 처리할 일이 없었기에 이러한 어려움을 마주하지 않았기에 무리 없이 이용이 가능했던 것일 수 있다. 이번 경험 덕분에 async,await / Promise에 대한 이해가 부족한 것으로 보여 공부도 다시 해보기로 마음먹게 되었다. 하지만 이러한 배움에 대한 필요와 의지를 다진 것도 이번 프로젝트의 굉장히 좋은 점 중 하나라고 생각했다.

2. 프로젝트를 진행하며 아쉬웠던 점

◆ 의사결정의 어려움

초보 개발자에게 있어 활발한 소통은 양날의 검이라고도 생각한다. 의견이 획일화되고 적은 팀이라면 다양한 의견이 나오지 않는다는 단점이 있지만 그만큼 의견충돌이나 의사결정 딜레이가 적게 일어날 수 있다. 그렇지만 능숙하지 않은 개발자들이 모여 다양하게 의견을 주고받는 팀은 그만큼 여러 가지 시도와 회의를 해야 하고 그에 따른 시간적 손실이 필연적으로 따라온다.

이 많은 걸 하루에 결정했음에도 본격적인 개발까지 3일이 더 소요됐다...

엘리스에서 요구한 대로라면 1주차에는 기본 기능을, 2주차에는 추가 기능을 구현해야 했지만, 대다수 팀이 추가 기능 구현을 하는 것이 어려웠다. 대부분 1주차에 바로 개발에 들어가지 않고 여러가지를 정하느라 이런 상황이 발생했던 것인데, 우리 팀은 특히 의견 개진이 너무나 활발하여 html 템플릿인 pug, ejs를 사용할지 말지에 대한 여부와 시도까지도 해본 다음 프론트엔드의 하는 일이 너무 없어지고 성장할 수 없고 실력 향상에 도움이 안 되는 프로젝트가 될 것을 우려하여 결국 js만을 이용하여 진행했다. css도 tailwind, daisyUI, bootstrap 중 어느 것을 사용할지 고민과 시도 끝에 bootstrap을 사용하게 되었다.

비록 모든 결정이 전부 최고의 선택이 되었지만 😅 그 결정에 다다르기까지 너무나 수많은 시행착오의 연속이었기에 다음 프로젝트에서는 이러한 과정이 조금 더 효율적으로 진행되면 좋을 것 같다는 생각이 들었다.
효율적인 시간분배에 대해서 공부하고 이해한 뒤 회의를 하게 되면 더 좋은 결과물을 시일 내에 낼 수 있으리라 생각했다.

◆ 모듈화하지않은 코드

빠른 시간안에 완성해야 하기 때문에 indexedDB와 관련된 함수를 완전히 모듈화하지 않았고, 자주 쓰이는 함수들도 마찬가지로 모듈화하지 않았으며 로직이 비슷하게 겹치는 함수마저 만들어져있었기에 내가 작성한 코드는 유지 보수적으로는 굉장히 실망스러운 코드가 아닌가 생각이 들었다.

리팩토링을 하게 될 때 모듈화와 로직을 간결하게 수정하는 방법을 적용하고자 하지만, 프로젝트를 어떻게든 굴러가게 하려고만 해서 유지 보수성에 신경 쓰지 않은 점이 아쉬웠다. 무엇보다 코치님께 지적받기도 전에 나 스스로 알고 있음에도 기한에 맞춰야 한다는 마음에 조급해져 모듈화와 로직 수정을 하지 않은 채 코드를 작성한 게 아쉬웠다.
이번 프로젝트 이후 리팩토링이 예정되어있는데, 리팩토링 시간에는 새로운 기능을 추가하고 개선하는 것도 좋지만, 코드를 유지보수 하기 좋게 변경하는 것에 힘쓰도록 해야겠다.

3. 프로젝트를 진행하며 이슈를 해결했던 방법

◆ 활발한 팀 협업 과 오피스 아워

사실, 내가 맡은 부분은 다른 팀원과 거의 겹치지 않았기 때문에 이슈가 발생할 때 대부분 내 스스로 내가 작성한 코드를 살펴보고 문제를 파악해서 개선해야 되는 것이 많았다. 그리고 다른 팀원들도 매우 바쁘게 개발 중이었기 때문에 시간 내 알려주기 힘들기도 했다. 하지만 그럼에도 팀원들은 내가 공유한 이슈에 대해 같이 생각해주고 나는 잘 모르지만, 팀원은 잘 알고 있는 개념에 대해 설명해주기도 하면서 어려웠던 점들을 해결할 수 있었다.
백엔드 팀원으로부터 fetch로 브라우저에서 어떻게 요청해서 백에서 어떻게 받는지, 백에서 어떻게 결과를 주면 브라우저에서 어떻게 처리하는지에 대해 설명을 들으면서 수업 때 제대로 이해하지 못한 fetch에 대한 개념을 완전히 이해하게 되면서 코드를 작성하는 것에 막힘이 없게 되었다.

팀원에게 물어봐도 해결되지 않은 문제 대부분은 스스로 고민하고 머리를 식히고 와서 번뜩이는 순간 해결하기도 했는데 그럼에도 어려운 부분은 오피스 아워 시간에 프론트엔드 코치님께 질문하기도 하면서 해결했다.
위 이슈에 대한 코치님의 답변은 Promise를 사용하여 비동기인 indexedDB를 동기식 처리하여 해결하는 것이었다.
하지만, 해당 이슈에 대해서는 코드 자체를 변경하여 진행하는 바람에 코치님께서 알려주신 방식을 적용하지는 않게 되었다. 그런데 코치님께서 Promise 를 사용하면 해결할 수 있다 하셨을 때, 내가 Promise에 대한 이해가 상당히 부족하다는 것을 알게 되어 반드시 이 부분은 공부해야겠다고 생각하게 되었다.

4. 프로젝트를 회고하며...

이번 프로젝트에서는 정말 그 어느 때보다 열심히 살고 열심히 공부하고 지냈던 것 같다. 팀원들과 잠자는 시간 외엔 온종일 소통하고, 개발하고 밥마저도 컴퓨터 앞에서 먹고, 이슈가 생기면 잠시 쉬는 중에도 아이디어가 떠오르면 못 참고 바로 컴퓨터 앞에 달려가서 해결하기도 했다.

비록 800줄이 넘어가는 끔찍한😵 코드를 작성하고야 말았지만, 기능에서 어떠한 에러나 버그가 없고 이벤트 꼬임 없이 동작한다는 것에 자부심을 느끼고 프로젝트를 마무리할 수 있었다. 다른 팀원들이 완성해준 화면들, 백엔드 팀원들이 만들어준 Router, Controller, Service, Model, 배포 덕에 성공리에 프로젝트를 마치고 심지어 배포 이슈 없이 끝날 수 있었다!
후에 엘리스 SW 엔지니어 트랙 N기 분들이 이 글을 보신다면 조금은 도움이 되길 바라고

끝으로 자랑스러운 개굿(개발자굿즈)쇼핑몰의 링크를 두고 가며, 회고를 마치겠다.

https://gaegood.com/