레저티켓 론칭 회고

0. 들어가며

2023년 3월 13일 현 회사에 입사했습니다. 입사 후 제가 어떤 프로젝트를 담당할지 물어보니 레저 티켓 을 담당하게 될 거라고 답변을 받았습니다.

다만 입사 하고 나서 바로 레저 개발이 시작된 것은 아니었기에, 셀이 담당하는 버티컬의 작업을 일부 진행하며 팀의 스타일과 회사의 일하는 방식에 익숙해져 나가고 있었습니다.

레저 티켓이 시작되면서 저의 업무는 다른 버티컬을 하던 것을 내려놓고, 레저에 더 집중하게 되었습니다.

레저 티켓의 경우 저희 셀 프론트엔드 개발자가 저 포함 4명이 들어간 프로젝트였습니다. 프로젝트 론칭 준비로 6개월 정도의 시간이 주어졌습니다.

저는 레저 티켓에서

• 상품 상세
• 상품 옵션 바텀시트
• 주문서
• 결제
• 주문완료
• 취소

를 담당하게 되었습니다.

런칭 후 프로젝트를 계속 개선해 나가며, 언젠가 회고해야지 하고 있었는데, 내일 레저 팀 내에서 4L 회고를 하기에 인제야 개인 4L 회고를 진행 해 봅니다.

1. LIKED

가장 좋았던 것은 B2C 서비스를 했다는 것과, 웹뷰 기반의 첫 프로젝트를 수행한 것입니다.

B2C 서비스 진행

이전 회사에서는 B2B로 제품을 개발했었습니다. 물류 도메인에 대한 이해와, 수많은 과정이 자동화되어 돌아간다는 느낌이 정말 신기하고 경이로운 경험이었습니다.

다만, B2B다 보니 사용자의 피드백을 주위에서 접할 수 없었으며, 제가 사용하기에도 부적합한 제품이었습니다. 저는 사업자도 아니며 벤더로써 커머스를 운영하는 것도 아니었기 때문이지요.

B2B 개발 및 내부 툴 개발만 하다 보니 내가 만든 것들이 많은 사람들에게 쓰였으면 좋겠다고 생각했습니다. 또한 많은 피드백을 받아서 제품을 성장시키고픈 마음도 있었습니다.

이 관점에서 이번 레저 티켓은 저에게 뜻깊은 경험을 만들어 주었습니다. 제가 만든 제품을 제가 구매해서 사용하기도 하고, 다른 사람들에게 추천하며 보여 줄 수도 있으니까 정말 신기하고 감사한 경험이었습니다.

이제 부지런히 만든 프로젝트에서 악취가 나는 코드와 부족한 테스트 코드를 구축해 나가며, 다음 단계를 밟아가는 레저 프로젝트가 기대됩니다.

웹뷰 프로젝트 수행

2023년에 웹뷰를 처음 경험해 봤습니다. 모바일 디바이스란 반응형으로 깨작깨작하는 것만 해봤는데 내가 웹뷰로 개발을 한다니.

근데 생각보다 꽤 죽을 맛 이었습니다. 네이티브에서 컨트롤하는 동작을 웹뷰를 연결해주는 브릿지에서, 어떤 것들이 사용 가능하고 어떤 방식으로 동작하는지 알기가 쉽지 않았습니다. 그리고, 웹에서는 잘 되는데 모바일 기기에서 동작을 안 하는 것들이 있었습니다(?!)

IE가 영면에 들면서 이제 크로스 브라우징 이슈를 해결했나 싶었는데, iOS, AOS 별 지원되고 안 되는 동작 및 버그 등등이 존재하더라구요. 그리고 safe area나 기기별 동작시 고려 / 발생하는 몇몇 케이스를 보면서 식겁한 게 한두 번이 아닙니다.

브라우저 환경만을 개발하다가 웹뷰를 해보니 신입 개발자가 된 느낌이 들었습니다. 아직 배울 것은 많고 나는 모르는 게 100만 개나 더 있구나를 느낄 수 있었습니다.

2. LEARNED

이번 레저 프로젝트를 진행하면서 가장 크게 배운 것은 프로젝트를 진행하면서 커뮤니케이션하는 방법과 프로젝트 관리에 대해 배울 수 있었습니다. 새로운 회사에 들어와서, 그리고 셀의 일원으로 배우는 것들이 정말 많았습니다.

커뮤니케이션

비대면 소통이 정말 많아졌습니다. 이전 회사에서는 궁금하거나 물어볼 게 있으면 옆자리에 가서 물어봤습니다. 그러나 현 회사에서는 다들 멀리 떨어져 있기 때문에 자리에 가서 이야기할 수는 없습니다.

그러다 보니 슬랙 위주의 커뮤니케이션을 많이 하게 되는데요, 슬랙 스레드를 작성하고 이야기를 나누는 게 생각보다 힘들었습니다. 내가 궁금하거나 물어볼 것을 상대방이 이해하기 위해 어떻게 메시지를 작성해야 할지 고민하다 보면 하나의 스레드를 작성하기 위해 10분, 20분을 쓸 때도 있었습니다.

또한 스레드에 답글이 수십 개가 달리고, 이런 스레드가 하루에도 적게는 몇 개, 많게는 수십 개씩 생기는데 여기서 생기는 히스토리를 파악한다는 게 죽을 맛이었습니다.

그래도 사람이 시간이 지나면서 점점 학습하고 익숙해지듯, 슬랙으로 커뮤니케이션하는 게 익숙해 지고 있습니다. 이제는 더 나아가서 제가 담당하고 있는 피쳐뿐만 아니라 프로젝트에서 논의되고 있는 내용들을 보면서 도메인을 넓혀가는 것을 목표로 하고 있습니다.

프로젝트 관리

프로젝트를 하다 보면 언제나 새로운 기능이 추가가 됩니다. 개발한 것은 뭔가 놓친 부분이 존재하며, 기획했던 내용에서 추가가 되는 부분도 있고, 변경이 되는 부분도 있습니다. 저희 셀은 이런 상황들을 종종 맞이했습니다.

슬랙으로 스레드를 만들면서 논의하다가 수정해야 할 부분이 있을 때, 회의에서 이야기하다가 문뜩 잘못됨을 느꼈을 때, 개발을 하다가 뭔가 부족하거나 추가 논의가 필요한 부분이 있을 때, 이때마다 새로운 일들이 생겨났습니다.

작년에 제가 이런 일들을 경험했을 때 정말 막막했습니다. 현 회사에서 저희 셀은 어떤 이슈에 대해 논의가 끝난 이후 변경 또는 추가, 제거 등이 발생하게 되면 셀 내 공유 후 지라티켓을 만들어 둡니다. 중요도에 따라 이번 스프린트에 진행하거나 백로그에 넣어두고 공유를 합니다. 백로그에 들어간 태스크는 다음 스프린트에 추가되어 프로젝트를 수행하게 됩니다.

어떤 분들에게는 당연한 일들이겠지만, 저에게는 너무 신선한 충격이었습니다. 저는 메모와 기록의 중요성을 알고는 있지만, 습관화가 되지 않았기에 정말 크게 배웠습니다. 현 회사에 들어와서 지라 태스크를 만들 때 스레드에 논의했던 내용을 기록해 두고, 필요하면 사진이나 영상을 첨부해 가며 디스크립션을 작성했습니다. 이를 기반으로 업무를 수행하는 게 처음에는 귀찮고 번거로울 수 있으나, 기록을 기반으로 업무를 진행하면 히스토리도 남고, 추가적인 커뮤니케이션 비용을 줄일 수 있다는 점을 뼈저리게 느끼게 되었습니다.

커뮤니케이션은 다다익선

‘내가 괜한 걸 물어보는 거 아니야?’ “내가 이런 걸 물어보는 게 너무 바보 같지 않을까?”라는 생각은 접어두는 게 맞다는 것을 알게 되었습니다. 물론 충분히 검색해 보고 물어봐야 하긴 하지만, 커뮤니케이션에서는 임의로 내가 수행하는 것보다 그전에 물어보고 진행하는 게 맞다고 느꼈습니다. 그리고 다양한 커뮤니케이션을 통해 제가 담당하고 있는 ‘프론트엔드 개발’ 뿐만 아니라 더 나아가 도메인과 프로젝트에 대한 이해를 한층 높이는 게 프로젝트를 성공적으로 수행하기 위한 방법임을 알게 되었습니다.

3. LACKED

문서화와 테스트코드가 부족했습니다. 그리고 회사에 적응하면서 허둥지둥 대다 보니 꼼꼼히 개발하지 못하고 실수를 연발한 부분이 부족한 부분이었습니다.

문서화

프로젝트 문서화를 어떻게 진행해야 하는지 잘 모르기에 점점 배워나가야 할 것 같습니다. 제가 만든 코드들이 어떤 의도로 만들어져 있고, 그 내면에 어떤 스레드들이 오갔는지는 저는 알지만 저의 팀원과, 훗날 새로 들어오게 될 팀원은 모를 수밖에 없을 것입니다. 이런 점에서 프로젝트와 관련된 문서를 작성해야 하는데, 이 부분이 참 익숙해지지 않고 있습니다.

사내 위키에 언젠가 조금씩 조금씩 작성해서 도메인을 이해할 수 있게 기록하는 것을 목표로 하고 있습니다.

테스트코드

4년 차 개발자이지만, 아직 테스트코드 작성이 참 미숙합니다. 특히 TDD는 정말 손에 잘 안 잡히게 되는 게 있습니다. 그래서 이제나마 중요한 비즈니스 로직만 테스트코드를 작성하고 있는데 이 또한 맞는지 틀린 지는 잘 모르겠습니다.

하지만 오히려 더 좋은 기회라고 생각도 듭니다. 제가 담당하는 프로젝트면서, 테스트코드와 함께 문서화를 같이 진행해 나간다면 더 좋은 시너지를 낼 수 있지 않을까요? 이 또한 저의 액션 아이템으로 남아 있습니다.

빈번한 실수

저의 죄를 고해 성사합니다

1. 기획서를 잘 보지 않고 개발을 했었습니다.
2. 피그마를 보고 개발을 했지만 좀 놓치는 부분들이 있었습니다.
3. 해피 케이스만 고려해서 개발을 하고는 했었습니다.
4. 태스크에 눈이 멀어 일단 작성하고 PR을 올리다 보니 코드의 퀄리티나 구조에 대해 고려를 못 한 적이 많습니다.

언제나 “개발하기 전에 설계를 먼저 하고, 뭘 어떻게 만들지 고민하자!”라고 생각하며 말하지만 참 쉽지 않습니다.

더 많은 질문을 하기

백엔드에서 API를 내려줄 때, 이를 기반으로 그냥 프론트에서 조합해서 작업을 했었습니다. PR 리뷰에서 그런데 이거 백엔드에서 처리해 주면 나중에 관리하기 더 좋지 않을까요?라는 이야기가 나왔습니다.

저는 백엔드에서 주는 대로 만드는 거에 익숙했는데, 더 나은 작업 및 코드를 위해 이런 식의 커뮤니케이션을 해야 하는 것도 잘 몰랐습니다.

기획에서 이야기하는 내용에 대해 혹시 어떤 의도가 있을까요? 이 방식보다 다른 방식은 어떨까요?라는 이야기는 못했습니다. 그런 생각도 없이 그냥 기획서랑 피그마에 있는 내용을 만들기만 했었거든요.

디자인에서 컴포넌트별 조금 다른 디자인 요소들도 맞춰달라는 이야기 할 생각 없이 매번 새로 css를 만들고 있었습니다.

조금 부끄럽지만, 그냥 만들라는 대로 만들었습니다.

그러나 개발자로서, 단지 기획 및 디자인된 것을 그대로 만드는 것이 아닌 제품을 만들어 내는 것이기 때문에 다양한 질문과 수많은 요청들로 제품을 풍성하게 만들어 나가는 과정이 참으로 중요한 것 같다고 느꼈습니다.

4. LONGED FOR

1. 논리적인 근거로 이야기 하기

   무엇인가를 하고 싶거나, 주장할 때 이를 뒷받침 하는 이론 또는 근거를 충분히 가지고 설득하기.

2. 문서화와 테스트 코드에 힘쓰기

   내가 하는 업무가 수많은 사람들의 시간을 줄여주고, 그보다 더 많은 버그 및 디버깅 시간을 줄여 줄 것.

3. 작업하기 전에 배경을 충분히 이해 하기

   키보드에 손 떼고, 무슨 작업을 왜, 어떻게 할지 고민해보고 난 이후에 키보드에 손대기

4. 나는 복사기가 아닌 메이커임을 인지하기

   좋은 상품은 좋은 커뮤니케이션과 좋은 질문들로 인해 만들어진다. 많은 질문과 의사소통을 진행하자

5 마치며

이전 회사에서는 꼬마 팀장이라 많이 힘들었는데, 이직 후 팀원으로 들어와서 정말 좋았습니다. 팀장으로서의 책임감을 내려놓고, 팀원으로 적극적으로 참여하고 성과를 내고 싶었지만 역량이 충분치 못해 그러지 못한 게 아쉬웠습니다.

하지만 긍정적으로 생각해 보면, 이제 슬슬 업무 및 회사의 일하는 환경, 도메인 지식 및 개발적인 부분도 익숙해지면서 전에 했던 잦은 실수들은 점점 줄어들고 있고, 이전에 힘들었던 일들도 이제는 자연스럽게 해내고는 합니다.

이제 프로젝트를 유지 보수 및 추가 피쳐를 통해 업그레이드하면서 더 나은 성과를 낼 수 있을 것이라 기대하며, 회고를 마칩니다.