냉장고 관리 애플리케이션, Fridge Link

왜 임시저장으로 목차만 만들어놓고 안쓴건지.. 그치만 원래 한달 지난 시점에서 하는 회고가 젤 재밌다

---

엘리스에서 나와서 백엔드와 나 단둘이 호기롭게 시작했던 프로젝트를 흐지부지 끝내면서 마감기한이 있는 곳에서 프로젝트를 진행해야한다는 사실을 깨달았다. 그리고 둘 다 기술 구현하고 싶어서 기획은 빨리 빨리 끝내놓고 개발에 들어갔기 때문에, 프로젝트를 어떻게 마무리해야할지 답이 없어서 중단하게 되었다. 그냥 둘이서 으쌰으쌰 결제 시스템 만져본걸로 만족했지만, 제대로 된 팀에서 프로젝트를 진행하고 싶어 연합동아리에 신청하게 되었다. 1년 사이에 개발변태가 된 나를 좋게 봐주셔서 운좋게 합격할 수 있었고, 마라팀에 들어가 냉장고 관리 애플리케이션을 제작하게 되었다.

CI/CD 세팅 해두기

로컬에서 거의 완성된 상태에서 배포를 했기 때문에 CI/CD의 중요성을 거의 몰랐었다. 오히려 다른 팀에서 vercel이 자동으로 CI/CD해주는걸 어떻게 설정해준 것이라고 생각하고 다음에 꼭 도전하겠다고 생각했다. 그런데 CI/CD를 경험하면서 프로젝트 초기에 꼭 세팅하고 가야한다는 점을 이해할 수 있었다. 일단 기본적으로 협업에는 필수적이다. 다른 사람이 작성한 코드를 실행시켜서 보는 것은 생각보다 리소스가 크다. 그리고 특히 스타일링 코드는 잘 합쳐졌는지 빌드된 상태에서 확인해보는게 훨씬 편하다. 그리고 무엇보다 내가 작성한 코드가 빌드 시점에 에러가 나지 않는지 확인하는건 필수인게, 생각보다 뜻하지 않는 빌드 에러가 상당하다. 그리고 CI/CD를 통해 PM이나 디자이너 분께 상황공유를 할 수 있기 때문에 편했다.

컨벤션 맞추기

혼자 프로젝트를 진행하는건 생각보다 좋지 않다는걸 이번에 많이 느꼈다. 나혼자만의 규칙이라는걸 아니까 그냥 매일매일 즉흥으로 규칙을 바꿔버릴 수 있다. 심지어 커밋도 그냥 모든 커밋을 바로 올리니까 기능에 따른 커밋 구분이 거의 불가능하다는 사실을 알아냈다. 물론 혼자 진행하는 프로젝트에서는 충분히 그럴 수 있다. 그러나 협업 경험은 꼭 해봐야 규칙을 지켜야한다는 사실을 깨닫게 된다. PR 템플릿이나 ISSUE 템플릿이 자동으로 뜨다보니 리뷰어의 입장에서 뭐가 필요한지를 한번 더 생각해볼 수 있었다. 그리고 처음에 연결이 안되어서 몰랐는데, 해당 PR이 main에 머지되었을때를 따로 빌드해줘서 마크업을 쉽게 확인해볼 수 있다는게 큰 장점이었다. 아직 어떤 컨벤션이 나와 맞는 컨벤션인건지는 알지 못하고 거의 따라가는 방식이었지만, 다른 팀들의 템플릿도 살펴보면서 얼마나 다양한 케이스의 컨벤션이 있고 다양한 PR 상황이 있는지 이해할 수 있었다.

나중에 알아볼 수 있도록 클린코드를 작성해야한다

아토믹 패턴을 사용하면서, 폴더 구분이 제대로 되었는가에는 자신이 없지만, 이렇게 분리해놓는게 나중에는 훨씬 편하다는 사실을 체감했다. 예전에 분류마다 페이지 폴더를 만드는게 불편해서 pages의 페이지 아래에 components, styles를 둔 적이 있는데, 이때 끝으로 가면서 폴더 깊이가 너무 깊어져서 힘들었던 적이 있다. 그러다가 아토믹 패턴을 사용해보니 아톰을 가져다 쓰는게 훨씬 편했다. 물론 pages와 templates에서 혼동이 있었지만, 정의를 잘 내리면 좋은 프로젝트 구조를 만들 수 있을 것 같다. 그리고 최근에 feature-slides design이 떠오르는데, 한 방향에서만 import 해올 수 있다는게 큰 장점이라는 사실을 아토믹 패턴을 통해서 이해할 수 있었다. 다음에 기간과 규모가 꽤 상당한 프로젝트에서 이 디자인도 구성해보고 싶다. 무엇보다 이 분류를 통해서 페이지를 보고 이 컴포넌트가 어디에 있을지 예상이 가서 재사용하기 편했다.

다양한 케이스에서 살펴보기

카카오를 통해 처음에 한번 회원가입을 하고, 냉장고를 만들어서 그 뒤로 재료를 넣다보니 회원가입과 로그인에서 발생하는 문제들을 확인할 수가 없었다. 내가 잘 되기 때문에 당연히 잘 될거라 생각하고 미루다가 배포 당일에 되어야 회원가입에 문제가 있다는 사실을 알아서 급하게 회원가입 에러가 에러 바운더리에 잡히지 않게 임시로 콘솔로만 찍었었다. 다양한 케이스를 고려해서 에러 상황을 파악했어야했는데 그 개념이 아예 없다보니 그냥 잘 되는 상황만 가정했던 것 같다. 유저 플로우를 항상 인지하고 있다가 해당 케이스를 직접 해봐야한다. 사실상 그렇게 내가 생각한 케이스보다 더 많은 케이스가 있을 수밖에 없으니 항상 뇌를 열어놔야겠다.