🍯 꿀매포청천 프로젝트 회고

🍯 꿀매포청천 🍯 프로젝트가 끝이 났다!

기획부터 약 2주 반 정도의 기간동안 빠르게 완성시켰는데, 이 기간이 통째로 일주일처럼 느껴질 정도로 빠르게 지나간 것 같다.

(한이음 공모전 기간이랑도 겹쳐서 막판에는 잠을 거의 포기..)

 

맨 처음 이 프로젝트를 시작할 때 팀원들과 각자의 개인 목표를 얘기했었다.

이전까지 진행했던 프로젝트에서 늘 느꼈던 아쉬움이 있었는데, 기획 단계에서는 늘 적극적인 논의들이 오고 갔지만, 막상 개발을 시작하면 FE 개발자끼리는 약간의 개인플레이가 있지 않았나 싶었다.

물론 알아서 이미 다른 팀원 분이 만들어 둔 컴포넌트를 재사용하기도 하고, 에러가 나는 부분이 있으면 함께 공유도 하고 했지만,

좀 더 체계적으로 컴포넌트를 관리하면 개발 효율성을 높이고 코드도 깔끔하게 관리할 수 있지 않았을까? 하는 생각이 늘 있었다.

이런 아쉬움을 극복하고자 이번 프로젝트에서는,

"개발 측면에서 적극적인 협업이 있었으면 좋겠다"

는 목표를 가지고 갔다.

 

목표를 이루었는가!

이번 프로젝트에서는 아토믹 디자인 패턴과 스토리북을 사용했는데, 이 두 가지가 나의 개인적인 목표를 이루는 데 도움을 주지 않았나 싶다.

아토믹 디자인 패턴 덕에 어떤 컴포넌트들이 재사용 가능한지 파악하기 쉬웠다.

컴포넌트의 크기별로 구분해서 정리를 해두니 체계적으로 재사용이 가능했고, 후반부로 갈수록 새로 만들어야 하는 건 줄어들어서 속도도 더 낼 수 있지 않았나 싶다. 내가 만든 이 컴포넌트가 molecule인지 organism인지 판단하는 것이 쉽지 않았던 건 맞지만, 그럼에도 컴포넌트를 적극적으로 재사용하기에는 확실히 아토믹 디자인 패턴이 도움이 됐던 건 맞다.

또 atom 단위의 컴포넌트들은 특히 스토리북을 사용해서 다른 팀원 분이 만들어놓은 컴포넌트가 어떻게 생겼는지, 어떻게 커스텀할 수 있는지 파악하기에도 좋았다. (물론 스토리북은 초반에 이런 atom 단위 컴포넌트들을 재사용하려고 할 때는 도움이 됐지만, scss의 mixin이 제대로 먹히지 않는 이슈 때문에 후반으로 갈수록 약간의 방치?가 됐던 것 같기는 하다.)

 

기술 부채?

개발 시작 전부터 고민이 많았던 부분은 Next.js를 잘 활용할 수 있을까! 였다.

사실 처음으로 Next.js를 제대로 프로젝트에서 사용하는 것이었고, 2주 반이라는 길지 않은 시간 동안 이걸 다 익혀서 사용할 수 있을까 하는 걱정이 없었던 건 아니다. 다행히 우리 팀에 두 분이 사용한 경험이 있었고 또 Next.js 13버전에 대한 간단한 발표까지 해주셔서 믿고 시작할 수 있었던 것 같다. 사실 프로젝트 초반에는 정확한 이해를 미뤄두고 일단 평소 React 프로젝트를 하듯 개발을 하다가 Client 훅을 사용해야 하면 client component로 만드는 식으로 진행했던 것 같다. (기술 부채가 이렇게 쌓이는거지...) 그래도 마지막에 우리 팀의 에이스 팀원 분이 메인 페이지를 리팩토링 해준 덕분에 언제 Server Component를 사용하고 언제 Client Component를 사용하는 건지 대한 이해가 조금은 생긴 것 같다. 아직 Next.js에 대한 부채를 완전 청산하려면 멀었다고 느껴지는데, 부단히 공부하고 리팩토링도 해야겠다.

 

 

개발 프로세스

팀 회고 때도 공유했지만, 일정산정하고 업무를 배분하는 과정이 꽤 체계적이었다고 생각한다. 스프린트를 새로 시작할 때마다 해야 하는 태스크들을 리스트업하고, 각 팀원이 예상하는 소요시간을 평균내서 산정했다. 소요시간 기준으로 태스크를 분담했기 때문에 어느 한 명의 팀원에게 일이 치중되지 않도록 했고, 나름 비슷한 비중으로 일을 가져갔던 것 같다. 마지막 스프린트 때는 혹시나 태스크를 다 못 끝낼 수도 있는 위험을 감안해서 각 태스크에 대한 우선순위도 정했다. 우선순위를 정해보는 건 아예 처음부터 쭉 도입해도 괜찮을 것 같다는 생각이 든다. 어떤 게 우선적으로 개발되어야 하는지를 같이 얘기해보면 개발을 할 때도 더 책임감을 가지고 개발할 수 있을 것 같고, 업무 분배할 때도 중요한 태스크들이 한 명한테 몰리는 일을 방지할 수 있을 것 같다.

 

또 처음으로 Github Project를 활용했다. 중간에도 팀과 함께 해봤던 얘기인데, 과연 이걸 꼭 사용해야 할까? 하는 얘기였다. 사실 매번 어떤 일을 해야 하는지, 어떤 일을 하고 있는지 등을 서로 파악하고 스스로도 정리할 수 있어서 사용하는 건데, 막상 사용하니 자주 깜빡할 때가 있었다. 또 돌이켜 생각해보니 우리는 매일 스크럼을 하기 때문에 서로 어떤 일을 하고 있는지 바로 파악할 수 있었어서, 사용할 필요가 크게 있었을까? 싶긴 하다. 다만 꼭 서로 어떤 일을 하고 있는지 파악하는 용도가 아니더라도 어떤 일들이 이번 스프린트에 남아있는지 한 눈에 확인하려면 Github Project 등의 툴이 필수적인 것 같긴 하다. 이슈는 어차피 생성해야 하고, 그 이슈들을 Project 칸반보드에서 관리하면 돼서 편리하기도 하니 그래도 안 쓸 이유는 없는 것 같다.

 

다음 프로젝트에서는

Next.js 등 기술 자체에 대한 팀원 간의 토론? 같은 과정이 더 있으면 좋을 것 같다. 아무래도 나 포함 세 명은 이번이 처음이기도 하고, 기간도 짧았다 보니 어떻게 사용할 것인지, 또는 모르는 부분에 대해서 충분한 이야기가 오고가지는 못했던 것 같다. 다음 프로젝트에서는 함께 기술에 대해서 고민도 해보고 하는 시간이 있다면 좋을 것 같다.

 

또 초반에 꼼꼼히 잘 봤으면 발생하지 않았을 버그 같은 것들을 마지막에 고치느라 조금 허겁지겁 하게 되지 않았나 하는 생각이 든다. 기능이 잘 돌아가는 걸 확인했다고 생각했는데, 미처 생각하지 못한 케이스에서는 잘 돌아가지 않는 것을 마지막에 발견한 경우가 많아 아쉽다. 뭔가 단편적으로만 확인하고 잘 개발됐다고 들뜬 마음에 빨리 PR 올려야지! 하며 성급하지 않았나 싶다. 다음 프로젝트에서는 적어도 내가 개발한 것들에 대해서는 여러 케이스들을 다 테스트해보고 정상 작동하는 것을 확인한 후에 PR을 올리자..!

 

이렇게 처음부터 꼼꼼히 개발을 한다면 마지막에 발견하지 못한 버그들이 우수수 나타나는 걸 막을 수 있을 테니, 마지막에 바쁘다는 핑계로 코드리뷰를 소홀히 하게되는 일도 방지할 수 있을거다. 개발한 사람이 발견하지 못한 예외 상황들을 제3자가 봤을 땐 더 잘 보이는 경우도 많고, 또 서로가 기능을 어떻게 개발했는지를 알아야 나중에 또 도움이 될 수도 있으니 코드리뷰는 꼭! 필요하다고 생각한다. 또 나중에 재사용하게 될 컴포넌트에 대해서는 특히 리뷰를 하는 것이 좋은 것 같다. (나중에 내가 쓰게 될 컴포넌트니까) 개인적으로 나는 코드리뷰로 도움도 꽤 받았던 것 같아 좋았다. 다음 프로젝트에서는 보다 더 의미있는 코드리뷰를 적극적으로 하고 싶은 마음이다.

 

가장 굵직하게 고민해봐야 하는 건 서비스의 기획 부분 같다. 참신성 같은 것도 중요하지만, 이 서비스가 왜 필요한지, 어떤 부분이 사용자들에게 어필이 될 수 있을지를 기획 단계에서 많이 고민해봐야 할 것 같다. 필요성과 차별성에 대해 개발자들이 인지하지 못한다면 개발하는 과정도 재미가 없어지니까! 꿀매포청천은 필요성에 대해서는 어느 정도 인지가 됐지만, 아무래도 이미 갖추어진 API 틀 내에서 기획을 하려다보니 글 내용 말고는 다른 커뮤니티형 서비스랑 크게 다를 것이 없는 점이 아쉬웠다. 싫어요 기능을 구현하기 위해 API를 어느 정도 커스텀하기는 했지만 싫어요 기능마저도 흔한 기능이다보니, 사용자들이 작성하는 글의 내용과 서비스의 컨셉말고는 특별하게 내세울 만한 기능이 없었던 것 같다. 다음 프로젝트에서는 이런 것들을 고려해서 대체재가 없는 서비스가 되도록 기획을 잘 하고 싶다. 또 프로젝트 기간 이후에도 (또는 여유 기간을 미리 빼두어서) 실제 사용자들의 피드백을 듣고 반영해보는 시간을 갖고 싶다. 프로젝트를 개발하고 끝이 아니라, 사용자들의 의견을 듣고, 개선사항들을 정리해 리팩토링의 방향성을 잡는 시간도 있으면 좋을 것 같다. 무엇보다 정말 누군가가 사용할 서비스라고 생각하고 개발을 해야 사용자 경험을 고려하며 개발할 수 있어 실력 향상에도 더 도움이 될 거라 생각한다.