카카오에서의 2년 [5]
카카오 T 주차
2016년 6월, 나는 O2O 사업부의 파킹 TF로 팀을 이동했다. 파킹 TF는 주차의 경험을 즐겁게 할 새로운 서비스를 준비하는 목적 조직 형태의 TF였다.
소식을 들은 사람들이 물어봤다.
왜 파킹으로 이동했어?
좋은 질문이었다. 나는 왜 파킹으로 이동하려고 했을까? 무엇을 기대했을까?
O2O라는 특성상 온라인에서만 머무는 것이 아니라, 오프라인의 무언가를 온라인으로 연결시킨다는 점이 재미있어 보였고, 주차는 당시 아직 오픈하지 않은 서비스였기 때문에, 준비/오픈하는 과정에 직접 참여하며 경험해볼 수 있는 좋은 기회라고 생각했다. 서비스의 방향성에 대한 그림을 같이 그려볼 수 있을 거라는 기대감이 컸다.
새로운 팀으로 가면서 이동에 중점을 두었던 부분, 내가 노력했던 부분에 대해 이야기해보려고 한다.
1. 피드백을 원활히 주고받을 수 있는 문화인가?
내가 개발자이다 보니, 피드백의 주요 원천은 개발자들끼리 일할 때다. 가장 대표적인 사례는 코드 리뷰이다. 우리 팀의 경우, 개발 후에는 코드리뷰가 필수이며, 그 후 PR 머지 및 배포가 원칙이다. 리뷰는 언제나 옳은 것이라고 생각한다. 리뷰에는 누구나 자유롭게 어떠한 의견이라도 제시할 수 있다. 오직 코드에 관한 이야기만 하는 것이기 때문에, '나이가 어려서/많아서..' 수직적으로 생각하지 않아도 된다. 리뷰를 하며 더 좋은 방향에 대해 이야기하곤 한다. 미리 경험해봤던 이가 제시해줄 수도 있고, 남들과 이야기하다 보면 내 생각이 정리되면서 문득 더 좋은 방법이 떠오를 때도 있다. 또, 생각지 못했던 부분에 대해 피드백을 받으면 버그나 장애 상황을 미리 대비할 수도 있다. 가끔 스타일에 관한 논의도 있는데, 우리같이 소규모의 인원이 프로젝트를 개발할 때는 매우 엄격할 필요는 없는 것 같다고 생각했고, 루비 스타일 가이드를 기반으로 한 루보캅(Rubocop)을 통해 스타일을 서로 맞추고 있다.(이 또한 논의를 통해 수위가 조절되고 있다.)
팀에 적응하고 나서, 처음 해보고 싶었던 것은 리액트(React.js)를 도입하는 것이었다.
당시 공급자 쪽 웹사이트를 맡고 있었고, 대부분의 개발이 마무리되어갈 때 즈음이었다. Front-end 관련 컨퍼런스에서 리액트 도입기를 듣게 되었는데, 우리 팀에서도 도입하면 좋을 것이라 생각했다. 왜냐하면, 당시 우리는 jQuery만 사용하고 있었는데, 재활용할 수 있는 영역들, 한 파일에 담기엔 복잡하거나 가독성이 떨어지는 로직들이 이 분명하게 존재했기 때문이다.
리액트를 도입하면 앞으로의 작업 효율성이 훨씬 좋아질 거라 확신했다. 하지만, 내가 익숙지 않은 기술을 학습하고, 한 달 안에 개발-테스트-오픈까지 한다는 것은 자칫 위험할 수 있는 상황이었다. 테스트 기간을 제외하면 약 15일의 워킹데이가 남아 있던 것으로 기억한다. 하지만 앞으로의 유지보수를 위해서라면 한번 겪어야 할 일이라고 생각하여, 팀원들에게 의견을 물어보기로 했다. 아무것도 모른 채 의견을 물을 수 없으니, 주말에 공부를 하면서 샘플링으로 작업된 페이지들을 리액트 변환했다. 생각보다 속도가 빨랐고, 주말 내에 전체 페이지의 약 70%를 변환했다. 주말이 지나고 리액트를 도입하지 않았을 때와 도입했을 때의 경우를 비교하며 의견을 물었고, 결국 '해보자'는 긍정적인 결론을 이끌어내게 되었다. 그렇게 파킹에서는 리액트를 도입하게 되었다.
2. 제도가 바뀔 수 있는가?
그렇다. 무언가 바꾸고 싶은 게 있다면 언제든 제안할 수 있다.
우리의 Git의 브랜치 변천사만 봐도 그렇다. 서비스 오픈 전과 후의 우리의 브랜치 전략은 많이 달라졌다. 이 과정에선 항상 충분한 논의가 있었다. 예기치 못한 상황이 발생할 경우, 더 나은 방향의 브랜치 전략으로 보완한다.
일례로, sandbox에서만 테스트가 유의미한 피쳐(브랜치)가 있었다. 우리의 배포 환경 상, alpha → sandbox → production 순의 배포 절차를 지켜줘야 했는데, alpha에 배포를 하지 않고 sandbox → production에만 배포를 해버리는 경우가 종종 발생했는데, 코드가 꼬이면서 결국 컨플릭이 몇 번 발생했다. 컨플릭을 푸는 게 오랜 시간이 걸리는 것은 아니지만 휴먼 에러이다 보니 이런 부분에 있어서는 게으를 필요가 있다고 느꼈고, 논의하는 자리를 만들었다. 우리는 상위 브랜치에 머지를 하면 자동으로 하위 브랜치에도 머지시키는 job을 추가하기로 했다. 사실, 뚝딱 만든 후 '이렇게 할게요'라고 공유만 할 수도 있었다. 하지만, 문제를 제기하고 상황에 대해 모두를 공감시키고, 다같이 논의함으로써 우리가 조금 더 나은 방향으로 발전한다고 믿고있다.
3. 변화에 적극적인가?
'무조건 최신 기술만 고집하는' 그런 의미의 변화를 이야기한 것은 아니다. 서비스에 의미가 있는지, 개발자의 욕구를 적절히 충족시켜줄 선인지에 의미를 두는 것이다. 우리 팀은 적극적이다. 우리가 프로젝트 내에서 사용하고 있는 스킬 셋에 대해서도 최신 버전을 유지하려고 한다. 버전 업데이트를 하기에 귀찮음을 느끼는 경우를 몇몇 봤다. 기능이 추가되는 것도 아닌데, 워킹하는 코드를 다시 구성해야 할 수도 있기 때문일 것이다. 또, 어떤 side-effects가 있을지 100% 파악하기 힘들기 때문에, 전체 테스트를 다시 해야 하는 경우가 발생할 수도 있다. 그런 분야도 있다. 테스트 코드가 충분하지 않은 채로 운영한 지 오래된 서비스들, 테스트 코드로 충분히 커버하기 어려운 영역들이 있을 수도 있다. 프로젝트의 일정상 버전 업데이트를 위해 많은 시간을 투자하기란 현실적으로 쉽지 않을지도 모른다. 하지만, 취약점이 분명하게 존재하는 버전을 사용한다던가, '잘 동작하는데 왜?'라는 귀찮음 정도는 뒤로 하는 것은 어떨까..
4. 서비스를 '같이' 만들어나갈 수 있는가?
우리 팀에서 내가 가장 만족하는 부분 중 하나는, 막내이든 아니든 자유롭게 참여가 가능하고 결정에 대해 존중해준다는 것이다. Top-down으로 팀장/파트장이 '이걸 개발하세요'로 일을 시키지 않는다는 것이다. 해야 할 일을 리스팅 하고, 하고 싶은 일이 무엇인지 논의하는 자리가 명확하게 있다. 주차 서비스가 오픈하기 전, 쿠폰 및 기타 스펙에 대해 개발 담당자를 지정하는 자리가 있었다. 파트장님은 내게 하고 싶은 게 있는지, 어떤 것을 하고 싶은지 나의 의견을 물어보셨다. 말 한마디였지만, 그가 남긴 임팩트는 꽤나 컸다. 리더가 의견을 묻고, 구성원이 결정을 할 수 있도록 돕는다는 것은 해당 기능과 서비스에 대한 오너십을 가질 수 있게 하는데 큰 영향을 준다고 생각한다. 나는 주차의 쿠폰 시스템을 설계/개발하는 일을 선택했고, 내가 결정한 일이다 보니 더 적극적으로, 재미있게 일할 수 있었다.
경험이 많지 않아 이렇다 저렇다 비교할 순 없겠지만, 내외적으로 우리 팀은 꽤나 협업이 잘되는 팀인 것 같다. 서버의 로직을 물어보고 같이 테스트 케이스를 고민하는 기획자와 기획 요소의 필요성을 생각하고 더 나은 사용성을 고민하는 개발자들이 있다.
궁금한 것을 눈치 보지 않고 물을 수 있고, 나의 의견을 제시할 수 있다는 것은 좋은 분위기가 아닐까?
