[버킷플레이스] 6번의 이벤트를 내보내고 나서

 

❣️버킷 플레이스❣️에 합류한 지 벌써 약 8개월의 시간이 지났습니다. 시간이 정말 빠르네요!

이번에는 2022 오페스티벌 런칭 기념으로 입사 후 8개월 간 총 6개의 이벤트를 진행하며 발전했던 경험에 대해 정리해 보려고 합니다.

 

왜 새삼스럽게 많아보이는 건데...

 

제가 런칭한 이벤트들을 보고 있자니 새삼스레 느껴지는 디자이너 분들의 노고..! 이벤트들을 정성스레 돌봐오면서 당연히 발전한 것도 있고 아직 못한 것도 많고 느낀 점도 많은데요, 가만히 두면 또 금새 잊어버릴 까봐 글로 정리해보려 합니다. 팔로미~!

 

아마도

처음 이벤트를 시작할 때의 기억이 아직도 생생 한데요... github 저장소부터 만들고 환경 설정을 시작 했었습니다. TLM(Team Lead&Manager)분과 함께 아예 처음 구성부터 컴포넌트 하나하나 직접 구현 해와서 그런지 애정이 가는 도메인 인데요, 이 때 일어났던 저의 좌충우돌 첫 이벤트에 대한 경험을 담은 포스팅은 이곳에서 확인해보실 수 있지만 쟤는 글을 왜 저렇게 써? 라는 생각이 들 수 있으니 그냥 안 보시는 것도 나쁘지 않은 선택입니다. (꼭 이러면 보더라 구요 ^ㅡ^v)

 

그래봤자 7개월 밖에 지나지 않았지만, 그 때 그 시절의 글을 보고 있자니 스스로 그동안 놀고 먹지 만은 않았구나 싶은 마음이 들어 칭찬해주기 위해 정리해보았습니다.

• 이제서야 적응한 Next 라는 신세계
  • 버킷플레이스 에서는 도입할 예정인 기술들을 미리 검증하기 위해서 이벤트 도메인이 자주 활용 되는데요, Next js에 대한 검증도 역시 이벤트에서 진행되었습니다. 처음에는 역시 장점을 파악하지 못하고 사이트에서 제공하는 Best Practice 만을 따라서 개발했습니다.
  • 이벤트를 진행하면서 Next에 대한 공부를 틈새틈새 하다보니 많은 부분이 개선 되었는데요. 예를 들어 데이터 은닉 / 데이터 정제 / 에러를 다루는 BFF layer로 next/server를 사용하고, Server Side, Client Side Data fetching을 상황에 맞게 사용할 줄 알게 된 것처럼 요 🙂
• 문서화는 일상적으로
  • 정신없이 들어오는 질문과 요청을 처리하다보면 문서화를 제대로 못하는 경우가 많습니다. 대부분의 주니어들이 가지고 있는 걱정 및 개선점이기도 한 것 같은데요. 저 역시 도메인에 새로운 분들이 영입되고 나서 문서화의 중요성을 더 강하게 느꼈습니다. 문서로 정리해두었으면 링크 한 번으로 끝날 답변을 여러 번 해야하는 경험을 하고 나서는 받은 질문들을 메모해두었다가 답변을 문서로 정리하는 것을 일상화하기 시작했습니다.
• 다짜고짜 구현은 금물
  • 무슨 자신감이었는 지 처음에는 굉장히 많은 스펙이 포함되어 있는 GNB까지도 거의 기존 코드에 대한 참조 없이 직접 구현 했는데요. 그 당시에는 새로 구현하는 것이 더 빠르다고 생각하기도 했고 이렇게까지 많은 누적 코드(기능)가 있을 지 예상치 못했습니다.
  • 현재는 특정 기능이 필요할 때 다른 도메인에서 구현된 바가 있는 지를 먼저 살펴보고 사내 툴과 연계하여 보다 쉽게 구현하고 있습니다.
  • 더해서 이벤트라는 특성 상 일회성으로 사용하기 위해 일단 구현하고 보던 컴포넌트 들도 현재는 추상화에 꽤나 시간을 들여 추후 재활용할 수 있도록 구성하고 있습니다.
• 다양한 기술을 적합하게 쓰기
  • 처음부터 다양한 기술을 도입하고 사용해보긴 했지만, 이러한 기술들을 도입할 때 충분한 검증(PoC 및 테스트)을 거치지 않았고 이는 곧 몇 번의 에러와 리팩토링으로 이어졌습니다. 이제는 기술의 도입 시 다른 기술과의 비교를 통해 적합한 기술을 선택하고, 무엇보다 현재 상황에서 해당 기술의 단순성(simplicity)에 대해 고려하고 있습니다.
• 최대한 배포하지 않기
  • 배포를 나가려면 stage 모드에서의 검증과 더불어 여러 번의 빌드를 거쳐야 하므로 배포 시간이 걸리기 때문에 빠른 대응이 불가능합니다. 하지만 일회성의 특징을 띄는 이벤트는 수정 사항과 추가 스펙이 수시로 들어오기 때문에 빠른 대응 및 개발이 필요합니다. 이를 해결하기 위해 담당자가 이벤트의 정보를 변경할 수 있도록 admin을 구성해두고, 이미지와 같은 asset을 업로드 해두고 사용하는 형태로 발전시켰습니다.

 

뿌듯하면서도 아직 부족한 것이 매우 많은 걸 알고 있습니다. (좋지만 불편한 이 마음 흑흑 햄보칼 수 없어) 이제 반성의 시간입니다..

이 시간이 제일 재밌죠 🙂

 

• 클린 코드 및 이쁘게 commit 올리기
  • 아직 다른 분들의 commit 기록을 보면 깔끔하게 PR의 구분이 명확하고 각 PR에는 이와 관련된 커밋만 정리해서 올리시는데, 아직 저는 그런 능력이 부족한 것 같습니다. 더해서 빠른 개발을 핑계로 코드의 구성이 뒤죽박죽이거나 import 문의 순서가 정리되어 있지 않은 등 사소한 습관들도 고쳐야 합니다.
• 기존 히스토리 문서화 하기
  • 많은 부분을 문서화하고 있는 중이긴 하지만 아직도 부족합니다. 문서 만으로 대부분의 히스토리와 스펙을 파악할 수 있도록 새로운 인원이 유입되기 전까지 최대한 문서화해두어야합니다. 이는 효과적인 위임과 관련이 있는데 아직 해당 스킬이 부족합니다.
• 커뮤니케이션 필수로 하기
  • 비슷한 스펙이라고 뇌피셜로 구현 했다가는 추가 수정의 늪에 빠질 수 있습니다... 항상 곳곳에 도사리고 있는 사소한 스펙 수정에 유의하세요..!
  • 현재 버킷플레이스의 문화 중 가장 좋은 것이 서로 칭찬하고 잘못을 나무라지 않는 것입니다. 이를 본받아서 실수가 생기더라도 탓할 사람을 찾기보다 문제가 발생한 이유와 개선할 방향만을 바라보도록 해야겠습니다.
• 밀린 백로그 처리하기
  • 이 때까지 이벤트들을 런칭 하느라 달려왔다면 이제 시간이 없어서 못했던 백로그들을 처리할 시간입니다.  백로그들에는 내가 싼 똥 내가 치운다 라는 다짐이 내포되어 있는데요.  이때껏 공부하며 적용해 온 코드들이 많지만 아직도 개선할 수 있는 점들이 스윽- 봐도 찾을 만큼 많습니다. 팀원 분들과의 스터디 및 개인공부를 통해 개선해나가서 현재 상황에서 만들 수 있는 최선의 코드를 만드는 것이 목표입니다.

 

마지막은 좀 진지하게 정리해보자면,

 

이벤트 도메인을 가꾸면서 빠르게 기술들을 배우고 도입할 수 있었던 것이 재밌었고, 이에 따른 실수를 탓하지 않고 도전으로 보는 버킷플레이스의 문화에 감사했습니다. 일어나보니 전 날 짠 코드가 마음에 안 드는 때도 있었지만, 그만큼 하루하루 빠른 발전을 해왔다고 생각하면 이 또한 감사할 따름입니다. 다양한 분들과 다양한 주제를 가지고 일을 해본 8개월은 개인적으로는 회사에 적응하고 애정을 쌓아가는 기간이었습니다. 앞으로 core team으로써 개발자 분들께 도움이 되는 여러 툴들을 개발하고 best pratice를 작성 할 텐데 이벤트 도메인에서의 경험이 추후에 비즈니스 쪽 도메인을 이해하는 데에 많은 도움이 될 것이라 예상합니다.

 

앞으로도 재밌고 유용한 업무를 하며 쑥쑥 크는 햇병아리 개발자가 되겠습니다 😊