지난 10월 20일, 카카오 비즈인프라FE파트가 mm에 총출동했습니다.

영입 인터뷰 자리 또는 카카오에서 진행하는 여러 기술 이벤트에서 카카오 비즈인프라FE개발자들의 일하는 방식에 대해 많이 물어보시는 내용과 궁금해하셨던 내용들을 중심으로 이야기 나누는 시간을 가졌습니다. 밋업 당일 함께 나누었던 이야기들을 공유합니다.

비즈인프라FE파트가 하는 일

먼저 비즈인프라FE파트가 담당하고 있는 서비스와 기술 스택에 대해 소개하는 시간을 가졌습니다.

- 제이제이(모더레이터)

먼저 본격적인 진행에 앞서서 저희 조직에 대해 간략하게 소개를 부탁드리겠습니다.

- 폴
안녕하세요. 비즈인프라FE파트의 폴입니다. 비즈인프라FE파트는 크게 카카오의 여러 비즈니스 서비스와 지도 서비스의 프론트엔드를 담당하는 조직입니다. 파트 내에는 담당하는 서비스에 따라 비즈FE1셀, 비즈FE2셀, 맵FE셀 3개의 셀로 나누어져 있습니다. 각 셀에서 담당하는 세세한 서비스들의 이야기는 오늘 자리하신 스피커들이 생생하고 솔직하게 이야기 드리겠습니다.

- 제이제이(모더레이터)
비즈인프라FE파트(비즈FE1셀, 비즈FE2셀, 맵FE셀로 구성)에는 약 20여 명의 파트 구성원이 있습니다. 오늘 이 자리에는 각 서비스별 대표 담당자분들이 스피커로 함께하고 있는데요. 각각 자기소개와 어떤 서비스를 담당하고 있는지에 대해 짧게 소개를 부탁드립니다.

공통 플러그인, 비즈니스폼, 제로라이브러리

공통 플러그인

비즈니스 폼

- 레인
공통 플러그인은 카카오톡 안에서 발생하는 다양한 비즈니스적인 요구들을 소화하기 위한 서비스 중 하나입니다. 최근 가장 쉽게 접할 수 있는 곳은 톡 내 광고를 선택했을 때 이벤트에 참여할 수 있는, “화면의 반 정도를 덮는 창이 아래에서 올라오는 화면”입니다. 그 외에 간편 결제를 위한 서비스나 주문을 할 때 메뉴를 선택하는 등의 용도로 사용하는 플러그인 등이 있습니다. 톡의 비즈니스 요구를 소화하기 위한 서비스이다 보니 Android 또는 iOS 톡 앱의 WebView 위에서 동작합니다.

공통 플러그인은 Javascript의 ES6+로 만들어져 있고, Webpack, Babel을 사용합니다. 그리고 테스트 도구로는 Jasmine과 Karma를 사용하고 있습니다.

제로 라이브러리

- 존
제로라이브러리는 카카오의 서비스에서 카카오페이의 결제 수단을 보여주고 선택할 수 있게 해주는 라이브러리에요. “선물하기”에서 결제를 진행할 때 보신 분들도 있을 거에요. 플러그인과 마찬가지로 ES6+로 만들어져 있고, Webpack, Babel, Jasmine과 Karma를 사용하고, E2E 테스트 도구로는 Cypress를 사용하고 있습니다.

구독ON

구독ON

- 토마스
구독ON은 카카오 비지니스에 입점한 파트너사들에서 제공하고 있는 다양한 상품들을 큐레이션하여 많은 사람들에게 추천하는 서비스입니다. 이를 통해 실물 상품뿐만 아니라 멤버십, 그리고 무형의 서비스까지 많은 사람들이 접하고 구독할 수 있도록 노력하고 있습니다. Next.js와 React, Typescript를 기반으로 개발하였고, SWR과 Recoil.js을 적절히 사용해 상태를 관리하고 있습니다.

광고 SDK

- 제이크
광고 SDK는 iOS, Android와 같이 다양한 플랫폼에서 제공되고 있습니다. 이 중 비즈인프라FE파트에서는 웹에서 동작하는 웹 SDK의 개발을 담당하고 있습니다. 광고 SDK는 광고를 노출하기 위해 사용자에게 제공되는 스크립트입니다. 자신의 블로그나 사이트에 광고를 노출시켜서 수익을 얻고자 하는 사용자뿐만 아니라 다음, 카카오톡 등의 서비스에서도 광고 SDK를 사용하고 있습니다.

사용하는 기술 스킬셋은 바닐라(Vanilla) Javascript를 주로 사용합니다. 최근에는 Typescript와 React 같은 최신 기술을 도입하고 있는 중이고요. 빌드 용량에 민감한 SDK의 경우에는, “작은 React”라고 할 수 있는 Preact를 사용합니다.

오픈빌더, 지식관리자센터

오픈빌더

지식관리자센터

- 프레이
오픈빌더는 비즈니스 사용자가 고객들과 소통을 위한 챗봇 개발을 도와주는 플랫폼입니다. 인공지능을 사용해 사용자의 발화와 적절한 답변을 학습하거나 지식관리자센터와 연동해서 다양한 형식의 질문과 답변을 데이터베이스화하여 챗봇이 사용자의 발화에 답변을 해줄 수 있게 도와줍니다.

지식관리자센터는 상담원들이 보고 상담에 활용할 수 있는 질문과 답변 데이터를 관리하는 시스템이라고 생각하시면 될 것 같아요. 저장된 질답 데이터의 버전 관리를 담당합니다. 혼자만으로는 잘 사용하지 않지만, 다른 서비스와의 연동을 통해서 시너지를 발휘하는 서비스입니다. 특이하게도 저희는 개발에 Angular를 사용하고 있습니다. Angular v10을 이용해 개발을 진행하고 있습니다.

지도 서비스

카카오맵 서비스

카카오맵 매장관리

- 제이미
지도 SDK를 활용한 다양한 서비스를 제공하고 있습니다. PC/모바일 웹 지도뿐만 아니라 지도 내에 들어가는 장소 상세, 지도 정보 수정, 매장주를 위한 매장관리 서비스 등을 개발하고 있습니다. 이외에도 티스토리, 카페 등에서 플러그인으로 사용되는 플러스맵 라이브러리도 저희 쪽에서 서비스하고 있어요.
개발 스킬셋은 Polyfill을 사용하는 ES3, ES5, ES6 등의 Vanilla Javascript를 활용한 스펙에서부터 Vue,Typescript까지 다양한 기술 스택을 사용하고 있습니다.

카카오비즈니스

카카오비즈니스

- 저스틴
앞서 소개된 공통 플러그인, 비즈니스폼, 구독ON, 광고 SDK 등은 통틀어서 “카카오에서 제공하는 비즈니스 서비스”라고 할 수 있습니다. 한편, “카카오비즈니스”라는 말은 저희가 운영하고 있는 하나의 웹 서비스를 말합니다. “카카오비즈니스” 서비스는 사업을 하는 비즈니스 유저들이 앞에 소개된 다양한 비즈니스 서비스들을 사용할 수 있도록 엔트리 포인트 역할을 하는 웹 서비스라고 보면 될 것 같습니다… 카카오가 비즈니스 유저들에게 제공하는 다양한 서비스들을 소개하고, 자신이 가진 채널이나 광고 비즈니스폼 등의 비즈니스 자산을 관리할 수 있는 페이지를 제공합니다. 기술 스택으로는 Javascript(Typescript는 아니고요), Vue, Nuxt.js, Vuex, Jest를 사용하고 있습니다.

통합가입

통합가입

- 릴리
통합가입은 “카카오비즈니스”라는 여러 비즈니스 서비스들을 모은 플랫폼 안에서 하나의 회원 체계를 구축한 것입니다. 통합가입을 한 사용자라면, 비즈니스폼, 채널, 광고와 같은 여러 서비스들에 쉽게 접근할 수 있습니다.
개발 스킬셋으로는 Vanilla, Typescript, Babel, Webpack과 카카오 내부의 ESLint를 사용하고 있고, 테스트에는 Jest와 Cypress를 사용하고 있습니다.

기술에 대한 이야기

비즈인프라FE파트에서 구현하고 있는 기술에 대한 이야기를 조금 더 자세히 나누었습니다.

개발 범위에 대하여

- 제이제이(모더레이터)
FE파트에서의 개발이라고 하면, 그 범위가 어디까지인지를 궁금해하시는 분들이 많았거든요. 저희가 실제로 개발하는 범위에 대해 이야기 나눠볼까요?

- 저스틴(카카오비즈니스)
저희는 Javascript를 사용해서 웹서비스를 개발하는 것을 가장 중점적으로 하고 있습니다. 서비스에 따라 TypeScript를 사용하거나 React, Vue, Angular와 같은 프레임워크를 사용하기도 합니다. 브라우저나 인앱 환경에서 동작하는 웹 서비스를 주로 개발하고 있습니다(일부 Electron, Node.js 웹서버를 사용하기도 합니다.) HTML/CSS 같은 경우에는 저희가 직접 작성하기보다는 마크업 담당자분이 담당해 주시는 경우가 많습니다. 그렇기는 하지만 웹 개발을 위한 기본적인 HTML/CSS 지식은 반드시 필요합니다.

- 제이제이(모더레이터)
꼭 필요한 지식에 대한 이야기가 나왔는데요, 프레임워크를 사용하지 않는 서비스도 있지만 저희가 사용하고 있는 프레임워크들이 다양하다 보니까, “저는 Angular 혹은 React를 할 줄 모르는데요. 혹시 입사하게 되면 해보지 않은 프레임워크를 다루게 되나요? 따로 공부할 시간이 주어지나요?”라는 물어보는 질문들도 있었습니다. 니나나 저스틴은 카카오 입사 전에 지금 담당하고 있는 서비스에서 사용하는 Angular나 Vue를 다뤄 보셨었나요?

- 니나(오픈빌더/지식관리자센터)
저는 서비스 개발하면서 처음 Angular를 다뤘습니다. 맨 처음에는 좀 막막했어요. 하지만, 입사 초기에는 업무량이 많은 것이 아니다 보니 공부에 시간을 더 많이 쓰다가 차츰 업무에 시간을 쓰면서 자연스럽게 적응을 할 수 있었던 것 같아요. 그리고 처음에 입사하면 “버디”라고 해서 저희 파트 내에서 다른 분들보다 좀 더 적극적으로 적응을 도와주시는 분을 정해 주는데요, “누구에게 질문을 드려야 하지” 하는 고민 없이 질문을 마음껏 드릴 수 있었습니다. 저같은 경우는 버디에게 업무와 관련된 내용뿐만 아니라 공부하다 모르는 부분도 다 여쭤봤던 것 같고요.
마지막으로 저희 프로젝트에서는 입사 직후부터 모든 팀원이 필수 코드 리뷰어가 되기 때문에 다른 분들이 실무에서 어떤 코드를 작성하시는지 볼 기회가 많았습니다. 잘 모르는 상태에서도 리뷰를 하다 보면 “내가 공부한 내용이 이렇게 사용되고 있구나”가 보여서 알아가는 재미가 있었고, 또 학습에 동기부여도 많이 되었던 것 같아요.

- 저스틴(카카오비즈니스)
저는 입사 시점에 React만 할 줄 아는 상태에서 Vue를 사용하는 프로젝트를 담당하게 되었습니다. 그런데 조직에 배정된 후로 바로 개발을 시작하기보다는 어느 정도 Vue 전반을 공부할 시간이 주어졌습니다. 그 시간 동안, 여러 문서를 보면서 차근차근 Vue를 공부하는 중에 프로젝트 내에서 작은 업무를 시작하게 되었고, 그러면서 Vue를 자연스럽게 익히게 되었습니다.

- 제이제이(모더레이터)
프레임워크 이야기가 나온 김에 좀 더 이야기해 보겠습니다. 저희 파트에서 담당하고 있는 서비스가 대략 20개 내외 정도 되는데요, 크게는 React, Vue 그리고 Angular를 쓰는 서비스, Vanilla로 구현된 서비스 등등 스킬셋이 다양한데요, 이런 스킬셋은 어떻게 정해지는지 질문드리고 싶습니다.

- 저스틴(카카오비즈니스)
저희는 Vue를 사용하고 있는데요. Vue 같은 경우에는 v-bind, v-if 같은 디렉티브를 지원하는 것이 장점인 것 같아요. React의 경우 Javascript JSX 문법으로 조건부 랜더링이나 데이터 바인딩을 사용하는 것으로 아는데, Vue만의 간단한 디렉티브 문법으로 조건부 렌더링, 데이터 바인딩 등을 사용할 수 있는 게 장점인 것 같아요. 그리고 React에서는 state를 지정하는 useState를 통해서 state의 세터를 직접 받아오는 것에 비해, Vue에서는 state로 지정해두면 값이 변할 때 자동으로 렌더링 해 주는 편리성도 있습니다.

- 존(공통 플러그인/비즈니스폼)
조금 덧붙여보자면, 제가 담당하고 있는 비즈니스폼 같은 경우에는 분리된 별개의 서비스이긴 하지만, 저스틴이 방금 말씀해 주셨던 카카오비즈니스의 하위에 있는 서비스이다 보니까 여러 가지 정책, 디자인 등을 공유하고 있어 동일하게 Vue를 선택하게 되었습니다. 카카오비즈니스에서 이미 사용했었기 때문에 익숙하기도 하고, 러닝 커브가 낮다는 장점이 있었어요. Vue나 Nuxt의 경우, 공식 문서가 잘 되어 있다 보니 따로 문서화하는 비용이 줄어든다는 장점도 있었습니다.

사용하는 각 프레임워크에 대하여

- 제이제이(모더레이터)
이런 프레임워크의 이점도 있겠지만 통합가입 같은 경우에는 Vanilla로 되어 있잖아요? 어떤 이점을 보기 위해서였을까요?

- 릴리(통합가입)
통합가입은 Vanilla와 Typescript의 조합으로 구현되어 있는데요. 이 스킬셋의 배경은 통합가입이 비교적 단순한 화면으로 구성된 것에 있습니다. 가입, 탈퇴, 약관 목록 이렇게 세 화면으로 구성되어 있어요. 그래서 무거운 프레임워크를 사용하기보다는 가볍게 사용할 수 있도록 Vanilla를 선택하게 되었습니다.

- 제이제이(모더레이터)
Angular를 사용하는, 저희 파트에서는 어떻게 보면 약간은 마이너 한 길을 걷고 있는 서비스도 있습니다. 오픈빌더, 지식관리자센터는 어떻게 Angular를 선택하게 됐나요?

- 프레이(오픈빌더/지식관리자 센터)
현재 담당하는 프로젝트들 중 가장 먼저 개발된 오픈빌더는 기존에 백엔드 개발자분들께서 개발하신 프로젝트였어요. 이때 Angular를 사용하였는데, 이 프로젝트의 유보수 업무가 저희 파트로 넘어오면서 기술 스택을 Angular로 가져가게 된 것 같습니다.

이후 새로 오픈한 지식관리자센터도 저희가 개발을 진행하면서 어떤 프레임워크로 개발할지 고민을 했었죠. 결론은 Angular를 다시 쓰게 되었어요. 오픈빌더와 지식관리자센터가 유기적으로 동작하는 프로젝트들인 만큼 스킬셋이 동일하다면 서비스 간 개발자 투입이 유연할 테고, 각각의 서비스에 공통으로 사용하는 코드는 Angular 라이브러리화해서 중복 제거를 시도해 볼 수 있을 것 같았어요. 이 중에서 라이브러리화 작업은 차후 서비스별 과제에서 진행해 볼 예정입니다.

- 제이제이(모더레이터)
Angular를 선택해서 얻은 장점? 단점? 그런 것도 혹시 있었을까요?

- 프레이(오픈빌더/지식관리자 센터)
Angular를 사용했을 때의 장/단점이라기보다 다름을 느꼈던 부분은, Angular를 이용해 개발할 때 좀 더 추상적인 레벨, 하이레벨에서의 고민에 시간을 더 많이 투자할 수 있었다는 점이었어요. 그렇다고 Angular를 이용했을 때 개발 시간이 더 길어졌다는 것은 아니고요. 동일한 시간이 주어졌을 때 Angular와 그렇지 않은 프레임워크를 이용했을 때를 비교해 보면, Angular를 이용했을 때가 좀 더 로우 레벨에서의 고민을 덜하게 되었고, 그만큼 하이 레벨에서의 고민에 좀 더 시간을 투자할 수 있었던 것 같아요. 웹앱을 구현하기 위한 도구를 모두 Angular가 제공을 해주고 우리는 이 도구를 이용해 어떻게 하면 우아하게, 그리고 아름답게 구현할지에 대해서 고민을 했던 것 같아요. 설계에 대해 좀 더 깊게 고민해 볼 수 있었다는 거죠.
단점이라면, 파트 내 많이 사용되는 프레임워크가 아니다 보니 다른 크루들로부터 관심을 받지 못하는 것이 단점인 것 같네요. 리뷰 인원이 제일 적은 것 같아요.

코드 리뷰 방법에 대하여

- 제이제이(모더레이터)
코드 리뷰에 대한 이야기가 나온 김에 저희 파트의 코드 리뷰는 어떻게 이루어지는지도 이야기 들어볼게요.

- 폴(파트장)
GitHub PR(Pull Request)의 코멘트를 통해서 합니다. 필요하면 오프라인 리뷰도 하지만 빈도가 낮습니다. 리뷰어 선정은 프로젝트에서 설정한 필수 리뷰어와 사내 툴인 리뷰도비라고 부르는 자동화된 툴이 랜덤으로 지정해 주는 리뷰어가 함께 리뷰합니다. 리뷰도비는 리뷰어를 랜덤으로 선정해 주고, 선정된 리뷰어에게 알림을 줍니다. 또 리뷰가 늦어질 때는 리마인드할 수 있도록 주기적으로 알림을 주기도 합니다.

리뷰가 완료되면 머지하는 룰은 각 프로젝트마다 조금씩 다르지만 마지막에 리뷰 OK를 한 리뷰어가 머지하는 룰이 주로 사용됩니다.

- 제이제이(모더레이터)
저희 파트에서는 코드 리뷰를 풍성하게 받고 싶을 때 리뷰어 외에도 누구든 오셔서 리뷰해 주실 수 있게 자발적으로 파트 단톡방에 PR을 공유할 때도 있고, 또 리뷰하다 보니 PR 내에서 토론회가 열릴 때도 있고 한데요. 파트에서 코멘트가 많이 달리는 PR을 “코드 리뷰 맛집”이라고 부르고 있어요. “코드 리뷰 맛집”을 열었던 경험, 혹은 맛집에 참가한 경험도 좀 들어보고 싶은데요.

- 케이드(지도)
저 같은 경우는 올해 런칭한 매장관리 프로젝트를 진행하면서, 의도하지 않게 “코드 리뷰 맛집”을 자주 열었었습니다. 코드 리뷰를 많이 접하지 않은 상태에서 리뷰에 코멘트가 많이 달리는 경험을 처음 하게 되면 “혹시 내가 공격을 받고 있는 건 아닌지” 하는 거부감을 느낄 수 있습니다.

- 제이제이(모더레이터)
그렇죠. 코드 리뷰에 익숙하지 않은 분이라면, 간혹 코드에 대한 이야기를 본인에 대한 이야기로 생각하게 되어 마음 아파하게 되거나 하는데요. 이거는, 익숙해지면 “코드는 코드, 나는 나” 이렇게 분리할 수 있게 되는 거 같아요.

- 케이드(지도)
저는 개인적으로 조직 내에서 수평 문화라고 하는 부분이 가장 잘 반영이 된 사례가 코드 리뷰라고 생각해요. 조직장이나 시니어, 주니어 구분 없이 의견을 편하게 낼 수 있거든요. 처음에는 "편하게 리뷰해 주세요"라는 말이 굉장히 어렵게 다가왔었는데, (왠지 시험 보는 기분이기도 했고…) 지금은 서로 아는 지식을 공유하고, 확인하고 배워나가는 좋은 기회라고 생각합니다.

이번 프로젝트에서도 여러 POC를 드래프트 버전의 코드로 리뷰를 진행했었는데, 특히 전역 데이터 관리 모듈을 라이브러리 없이 직접 만들어서 사내 발표도 하고, 실제 배포까지 진행할 수 있게 되었던 부분이 기억에 남습니다. 쉽지는 않았지만, 바쁜 개발 진행 중에 의미 있는 토론을 할 수 있었던 경험이었습니다.

- 제이제이(모더레이터)
저도 그 열띤 토론을 굉장히 재밌게 관전했었고, 그 결과가 반영된 케이드의 사내 발표도 정말 재밌게 들었었습니다. 코드도, 개발 경험도 튼튼하게 만들어 주는 그런 코드 리뷰들이 잘 이루어지고 있는 편인 것 같아요.

테스트에 대하여

- 제이제이(모더레이터)
제가 체감하기로는 최근에 코드 리뷰에서 테스트 코드들을 부쩍 많이 보고 있는 것 같은데요. 각 서비스들이 유닛 테스트, E2E 테스트 커버리지를 올리기 위해서 요즘 많이 노력하고 있는 것 같아요. 저희 테스트에 대한 이야기도 좀 해볼까요?

- 레인(공통 플러그인/비즈니스폼)
플러그인 서비스는 유닛 테스트 위주로 작성되어 있어요. 전체를 다 작성하진 않고 앱의 코어에 해당하는 부분들 위주로 작성하고 있는데, 로직 수정 이후에 영향 범위를 파악하는 데 많은 도움을 받고 있어요.

제로라이브러리는 유닛 테스트와 함께 E2E 테스트도 일부 작성되어 있는데요, 리팩토링을 한 번 크게 할 일이 있었는데 리팩토링 전후의 동작이 동일함을 보장하기 위해서 유닛 테스트와 E2E 툴을 활용한 UI 테스트를 함께 진행했었습니다.

- 제이크(광고 SDK)
광고 SDK의 사례도 얘기해 보고 싶은데요, 광고 SDK도 테스트가 굉장히 중요한 프로젝트 중의 하나입니다. 그래서 최근에는 유닛 테스트의 커버리지 목표를 80% 이상으로 높여서 개발하고 있습니다.

Jest 같은 테스트 프레임워크를 사용하면, 테스트 커버리지 목표를 설정하고 목표보다 커버리지가 작으면 테스트가 실패하도록 할 수 있습니다. 이렇게 하면 GitHub에 PR을 올려도 테스트가 실패하면 머지가 안되도록 해서 테스트를 반드시 작성하도록 유도를 했습니다.
또, 테스트를 열심히 작성했어도 시간이 지나면 소홀해지는 경향이 있잖아요? 그래서 테스트를 작성하는 부담을 어떻게 줄일 수 있을까 하는 고민도 했습니다. 저는 테스트 파일을 별도 디렉토리에 분리해 두지 않고, 소스 파일과 같은 레벨의 디렉토리에 유닛 테스트 파일을 두는 방법을 시도해 봤어요. 소스 파일 바로 옆에 테스트 파일이 있어서 코드가 수정되거나 기능이 추가되면 테스트 파일로의 이동도 쉽고 눈에 띄기 때문에, 테스트가 부담되지 않고 또 꼭 해야 하는 작업으로 느껴지는 장점이 있었다는 이야기를 해보고 싶었습니다.

서비스에 대한 이야기

다른 서비스와 연결되어 있는 서비스를 개발할 때에는

- 제이제이(모더레이터)
서비스에 대한 이야기도 좀 해볼게요. 저희 파트에서 다루고 있는 서비스들은 다양한 환경 위에서 다양한 타깃을 대상으로 서비스되고 있습니다. 공통 플러그인이나 구독ON은 인앱 환경에서 서비스되고 있잖아요. 인앱 웹뷰 서비스를 개발하는 건 어떻게 다른지 궁금합니다.

- 토마스(구독ON)
제가 먼저 이야기해 보겠습니다. 일반적인 웹 서비스와는 다르게, 인앱 웹뷰를 통해서 서비스를 제공하기 때문에 클라이언트인 앱 내의 설정에 의존성이 있다는 점이 가장 큰 차이라고 생각합니다. 그렇기 때문에 앱 클라이언트 개발자분들과의 직접적인 커뮤니케이션을 통해서 문제를 해결해 보았던 것이 새로운 경험이었습니다.

그리고 무엇보다도 대한민국 국민의 대부분이 사용하고 있는 카카오톡 내에 본인이 개발한 서비스를 제공할 수 있다는 점과 카카오톡의 트래픽을 조금이나마 맛볼 수 있다는 점, 그리고 무엇보다 제 지인에게 제가 개발한 서비스를 소개할 때 “카카오톡에서 네 번째 탭에 보면 “구독ON” 이라고 있어. 한번 써봐” 이렇게 좀 더 쉽고 자신감 있게 소개할 수 있는 점이 가장 큰 매력 포인트라고 생각합니다.

- 제이제이(모더레이터)
특별히 인앱 웹뷰 환경이기 때문에 신경 써서 개발하고 있거나 어려웠던 점이 있거나 한 부분이 있었는지도 궁금합니다.

- 존(공통 플러그인/비즈니스폼)
플러그인에 대해서도 이야기해보고 싶은데요. 아무래도 모바일 인앱 환경에서만 쓰이는 서비스이다 보니까 OS나 브라우저, 인앱 환경인지 아닌지 등 고려할 것이 많아져서 간단한 기능 하나를 구현하더라도 환경별로 조금씩 다른 동작을 일원화하는 과정이 많이 필요했던 것 같아요.
또, 카카오톡 인앱 환경에서만 접근이 가능하도록 되어 있어서 디버깅이 어렵다는 점도 있었는데요.

- 제이제이(모더레이터)
레인과 존과 좀 더 이야기해 보고 싶은데요. 두 분이 담당하고 계신 서비스는 결제에 관련된 부분이기도 하고, 특히 제로라이브러리는 다른 서비스에서 사용되는 라이브러리라는 특성이 있어서 조심스러운 부분들도 있을 것 같은데요. 어떠세요?

- 존(공통 플러그인/비즈니스폼)
제로라이브러리 같은 경우에는 여러 서비스로 제공되는 UI 라이브러리이다 보니 간혹 예상치 못한 형태로 사용되어서 개선이 필요해 지거나 새로운 기능을 추가할 때 이전에 제공하던 다른 기능에 영향을 주게 되는 경우가 종종 있었는데요. 앞서 레인이 이야기해 주셨던 것처럼 E2E, 유닛 테스트를 적용하면서 이러한 어려움들을 최소화하려고 노력하고 있습니다.

- 제이제이(모더레이터)
광고 SDK 같은 경우에도 다른 서비스 안에 포함되다 보니 비슷하게 고민되는 부분도 있을 것 같은데요?

- 제이크(광고 SDK)
광고 SDK도 다른 서비스에 포함되어 사용되는 형태입니다. 그래서 다양한 브라우저와 모바일 환경을 지원해야 하고요, 그렇기 때문에 아무래도 Vanilla Javascript를 자주 사용하게 되는 것 같습니다. 구 버전의 IE 브라우저도 지원해야 해서 사용하려는 문법이나 기능 등이 지원되는지 꼼꼼히 살핀 후 개발하고 있어요.

하지만 올해 IE10의 지원이 종료되었고, 내년엔 IE11도 지원이 종료될 예정입니다. 그래서 덕분에 최근에는 Typescript와 React 같은 최신 기술을 적극적으로 도입해 보려 하고 있습니다. 또, 광고 SDK에서 에러나 버그가 발생하면 광고 매출에도 직접적으로 영향을 주지만 광고를 붙인 서비스에도 서비스가 먹통이 되는 것과 같은 치명적인 영향을 줄 수가 있어요. 그래서 유닛 테스트와 E2E 테스트는 필수적으로 작성하고 있습니다.

- 제이제이(모더레이터)
통합가입 같은 경우에도 서비스 안에 들어가는 것은 아니지만, 다른 서비스와 긴밀하게 닿아 있잖아요.

- 릴리(통합가입)
그렇죠. 통합가입이 여러 서비스들과 맞닿아있기 때문에 신경 쓰는 부분들이 있는데요. 다양한 서비스가 통합가입을 통해 가입과 탈퇴가 이루어지기 때문에, 서비스마다 서로 다른 이슈들을 처리해야 합니다. 그리고, 통합가입을 연동하고자 하는 각 서비스들에게 도움이 될 수 있도록, 통합가입 연동가이드, 마크업 연동가이드와 같은 문서화 작업도 개발만큼이나 신경을 많이 씁니다.

타 서비스에 독립적인 서비스를 개발할 때에는

- 제이제이(모더레이터)
반대로 영향 범위가 담당하고 있는 서비스에 한정되는 경우에는 좀 더 자유롭게 도전해 볼 수 있는 부분도 있을 것 같습니다.

- 토마스(구독ON)
저는 “구독ON” 이라는 새로운 서비스를 준비하는 과정에서 어떤 기술을 사용하여 개발할 것인지를 결정하는 순간을 함께 했는데요. 이 과정에서 기존에 쓰지 않던 기술을 도입하는 것에 대해서 주저함이 없다는 것을 몸소 느꼈어요.
만일 도입하고 싶은 기술이 있다면, 그 기술이 서비스 개발에 있어서 어떤 역할을 하는지와 다른 기술과의 장단점에 대해 설명을 하고, 충분한 토론과 합의를 통해서 사용할 기술을 결정했었습니다. 이러한 과정을 통해서 앞서 설명드렸던 React의 상태(state) 관리를 위해 비교적 최신 라이브러리인 Recoil.js을 선택하게 되었어요. 토론 과정에서 나왔던 후보를 간단히 말씀드리자면 Redux + Redux-thunk, mobX, recoil 가 있었습니다.

규모가 큰 서비스를 개발할 때에는

- 제이제이(모더레이터)
또 한 편으로는, 서비스의 규모가 굉장히 크고 또 유저의 폭도 넓어서, 한꺼번에 빠르게 트렌드를 적용하기 어려운 서비스도 있거든요. 케이드와 제이미가 담당하고 있는 지도 서비스 같은 경우에는 낮은 사양의 유저들도 사용할 수 있도록 하는 세심한 고려가 필요하기 때문에 서비스에 최신 트렌드를 바로 적용하기에는 어려움이 있을 것 같습니다.

그러다 보니까 스킬셋으로 ES3, ES5를 다루기도 하시는데, 상대적으로 오래된 코드를 다루고 있기 때문에 느껴지는 어려움 같은 게 있을까요?

- 케이드(지도)
오래된 코드가 어떤 코드냐에 따라 다를 거 같아요. PC 지도의 코드는 오래되었지만, 10년 이상의 기간을 정상적으로 동작하고 있는 훌륭한 레거시입니다. 소위 레거시에 대해 안 좋은 시선을 가진 분들이 많지만, 오랜 시간 많은 스펙을 확장하면서도 기본 구조를 유지해 내는 코드에게서 배울 점은 생각보다 많습니다. 책에서 볼 수 있던 여러 가지 디자인 패턴의 실 사례도 그에 포함되고요. 최근에 수많은 라이브러리들이 빠른 속도로 생겨나면서, “왜 그것을 써야 하는지?” “왜 그것이 만들어졌는지?”보다는 “어떻게 사용할 수 있는지?”에 더 많은 시선이 끌리는 거 같아요. 본질적으로 더 나은 프로그래밍을 하는 것이 우리의 목적이라면, 오래된 코드를 만진다는 게 단점이 될 경우는 그다지 없을 거 같아요. 실제로 얼마 전에 Vue와 Typescript 스펙으로 서비스를 런칭하기도 했고요.

- 제이제이(모더레이터)
지도 서비스 안에 또 멀티레포 형태로 새로운 서비스들도 들어가기 때문에 레거시를 통해 배우고, 또 새로운 기술적인 도전도 할 수 있는 지도 서비스는, 온고지신이라는 단어가 생각나는 서비스인 것 같아요.

서비스 이야기는 이 정도로 마무리를 짓겠습니다. 이어서, 저희가 실제로 어떻게 일하는지와 저희만의 문화나 생활에 대한 이야기를 해볼까 하는데요, 이 이야기는 카카오 비즈인프라FE파트 개발자는 어떻게 일할까? - 업무&문화편에서 이어집니다.

현장 Q&A

오픈채팅으로 진행한 현장 Q&A

Q: Typescript를 사용할 때 라이브러리 호환성 문제는 많이 없었나요? Javascript만 호환되는 라이브러리들이 있어서 Typescript로 못 넘어가고 있습니다.

- 케이드(지도)
Typescript를 사용하는 데 있어서 라이브러리 호환성 문제는 필연적으로 마주하는 문제인 거 같아요. 이 부분에 대한 대답은 타입 작성이 되어있지 않은 라이브러리에 대해 타입을 작성하려는 방향과, 그렇지 않고 사용할 때 어떤 방법을 선택할 수 있는지 정도로 나눌 수 있을 것 같은데요.

전자의 경우에 대해 사내에서는 사내 라이브러리에 대해 @types를 작성하는 DTS 프로젝트를 진행하고 있습니다. DTS 프로젝트란, 개발자가 d.ts 파일을 작성하여 dts 레포에 PR을 통해서 일반적인 Typescript에서 타입을 설치하듯이 @types/xxxxx 형태로 설치할 수 있게 해주는 프로젝트입니다.

하지만 모든 프로젝트에 위와 같이 타입을 제공할 수 있지는 않습니다. 저희가 사용하는 지도 SDK 같은 경우는 현재 type뿐만 아니라 npm의 형태로도 제공하고 있지 않은 상황이라, js 파일을 cdn 형식으로 직접 로드해서 사용하고 있습니다. 이와 같은 경우에 대해 지도 서비스에서는 전역 변수를 활용해 window 내에 해당 키를 선언(declare) 해 놓고, 사용처에서 타입 가드를 통해 사이드 이펙트를 최소화하려고 노력하고 있습니다.

다른 케이스로는 점진적으로 스펙을 변경해야 하는 경우에 대해, IE11 미만의 스펙과 기타 스펙을 구분해 빌드 시에 케이스를 나누고, 서버 혹은 클라이언트 측에서 접근한 브라우저를 판단해 서로 다른 빌드 버전을 제공하거나 하는 노력도 함께 하고 있습니다.

Q: 이미지 용량을 줄이기 위한 Super Resolution ML을 사용할 계획이나 진행은 혹시 있으신가요?

- 폴(파트장)
답변부터 드리면 Super Resolution ML을 사용 중은 아닙니다. 하지만 검토를 했던 적은 있어요. 웹 프론트에서 ML을 활용하여 어떤 일을 할 수 있을까 고민을 많이 하고 있고, Super Resolution ML도 고민했던 주제 중의 하나입니다. ML을 프론트에 도입하는 것은 기술적으로 의미가 있다고 판단하고 있거든요. 아직은 진행 중이지 않지만 개인적으로는 충분히 도입을 검토해 볼 만한 기술이라고 생각합니다.

Q: Recoil을 도입하시게 된 배경이 궁금합니다. 사용하시면서 좋은점, 불편한 점이 있다면 어떤 점이 있는지 알려주실수 있을까요?

- 토마스(구독ON)
토마스 / 앞에서 Redux, mobx, Recoil이 후보로 나왔다고 말씀드렸는데, 논의 과정에서 나온 저희가 생각하는 해당 라이브러리의 장단점을 간단히 말씀드리면 좋을 것 같네요.
우선 저희 프로젝트의 크기가 그렇게 크지 않았고, 상태 관리를 필요로 하는 부분이 많지 않았습니다. 이런 상황에서 Redux는 라이브러리에 자체에 대한 검증은 충분하지만 다른 라이브러리에 비해서 상태 추가를 위한 기본적인 코드의 양이 좀 많아 비효율적이라고 판단했습니다.

mobx는 함수형 컴포넌트를 사용하는 저희 프로젝트에는 다소 적합하지 않은 라이브러리라고 판단이 되었습니다.

Recoil은 비록 라이브러리에 대한 검증과 보일러 플레이트가 충분하진 않았지만, 상태 관리를 위한 코드의 양도 적었고, React를 위한 라이브러리답게 React hooks를 한 번쯤 다뤄본 사람이라면 큰 어려움 없이 사용할 수 있을 정도로 큰 이질감이 없었습니다. 그래서 그만큼 러닝커브도 적다고 판단이 되어 해당 라이브러리를 사용하기 결정했던 것 같습니다. 물론 Recoil을 사용해 보고 싶었던 제 의지도 아주아주 조금은 반영되었던 것 같습니다. :)

Q: 기존 개발코드 작업들을 리팩토링을 하다 보면 상대적으로 적게 리팩토링을 하는 경우도 있지만 Vanilla에서 React나 Vue로 전환을 하는 큰 작업도 가끔은 있을 것 같은데, 큰 작업을 리팩토링하게 될 경우에는 작업 진행 방향을 어떻게 잡고 개발하시나요?

- 존(공통 플러그인/비즈니스폼)
Vanilla에서 프레임워크를 사용하도록 전환하는 것만큼 큰 리팩토링은 아니었던 것 같지만, 최근에 리팩토링을 진행했던 경험을 말씀드리면, 아무래도 리팩토링을 하기 전/후 기능이 동일하게 동작함을 보장해야 하기 때문에 E2E, 유닛 테스트를 꼼꼼하게 먼저 작성했습니다. 테스트를 작성하고, 모든 케이스가 성공하는 걸 확인한 후에, 리팩토링을 최소 단위로 한 단계씩 진행할 때마다 테스트를 실행하고, 실패 케이스가 생기면 리팩토링 한 작업을 되돌리고 모든 테스트가 성공할 때까지 다시 리팩토링하는 형태로 진행했습니다.

카카오 비즈인프라FE파트가 일하는 방식, 비즈인프라FE파트만의 문화와 생활에 대한 이야기는 카카오 비즈인프라FE파트 개발자는 어떻게 일할까? - 업무&문화편에서 이어집니다.

카카오 비즈인프라FE파트 개발자는 어떻게 일할까? - 기술편