LINE 기술 컨퍼런스 Tech-Verse 2022 Web Frontend Session

Perfume·2022년 11월 22일
7
post-thumbnail

11월 17일 ~ 11월 18일 양일간 LINE과 야후 재팬을 포함한 8개의 회사에서 선발된 발표자들이 자신의 지식과 경험을 공유하는 기술 컨퍼런스가 열렸습니다. 저는 시간 관계상 직무와 관련된 웹 프런트엔드 세션 몇 개만 들었지만, 제가 들은 세션들이나마 이 포스팅을 통해 잘 정리해보려고 합니다. (추가적으로 자료를 더 찾아보며 정리하긴 했지만, 기본적으로 라이브로 진행되는 세션을 들으며 기록했던 내용이라 틀린 부분이 있을 수 있습니다. 지적해주시면 감사한 마음으로 수정하겠습니다.)

🪄 Headless CMS in LINE

이 세션에서는 LINE Plus의 개발자 박광용님이 Headless CMS의 개념과 장단점, 그리고 LINE이 만든 Headless CMS에 대해 소개하셨습니다.

Tech-Verse 2022 사이트는 백엔드 개발자 없이 프런트엔드만으로 만들었다고 합니다. 바로 오늘의 주제인 'Headless CMS'를 이용해서 말이죠. 각종 서버 인프라가 없이도 멋진 웹페이지를 개발할 수 있게 된 겁니다.

Headless CMS란?

Headless CMS가 무엇일까요? 일단 CMS는 콘텐츠 관리 시스템(Content Management System)을 말합니다. 그러니까 Headless CMS는 직역하면 '머리가 없는' 콘텐츠 관리 시스템인 셈입니다.

여기서 머리는 콘텐츠를 보여주는 뷰(view) 부분, 즉 프런트엔드입니다. Headless CMS는 프런트엔드를 제외하고 '콘텐츠'만 관리하는 시스템을 의미합니다.

Headless CMS의 필요성

그럼 이런 헤드리스 CMS가 왜 필요할까요?

오늘날 웹페이지는 데스크탑 뿐만 아니라 모바일, 스마트 워치 등 다양한 플랫폼에 콘텐츠를 배포할 수 있어야 합니다. 또한 모든 사용자에게 동일한 콘텐츠를 보여주는 것이 아니라, 사용자의 위치나 언어 등에 기반해 개인화한 콘텐츠를 보여줘야 합니다. 이와 같이 전통적인 방식과 다르게 콘텐츠를 매체와 사용자로부터 분리해 독립적으로 유지해야 할 필요성이 생겼고, Headless CMS가 등장했습니다.

Headless CMS의 장점

Headless CMS는 프런트엔드와 콘텐츠 관리 부분을 분리했기 떄문에 개발자가 CMS 부분에서 오는 제한이나 특별한 요구 사항 없이 자유로운 기술 스택을 선택할 수 있게 됩니다.

위 그림처럼 프런트엔드 개발자는 React, Vue, 혹은 Vanilla JS 등등 어떤 프레임워크든 자유롭게 선택할 수 있습니다. 또한 새로운 CMS를 설계하고 구축하는 등 서버 영역에서 반복되는 부분마저 헤드리스로 획기적으로 줄일 수 있습니다. 개발에 들어가는 전체적인 시간과 노력이 감소하는 셈입니다.

그래서 LINE에서는 자체적인 Headless CMS를 만들었습니다. Headless CMS를 도입하면서 정적 사이트를 만드는 프로젝트에 드는 공임이 획기적으로 줄어들었습니다.

위 이미지 속 사이트들은 실제로 Headless CMS를 적용해 엄청나게 빠르게 배포까지 완료되었습니다.

더 나은 Headless CMS 만들기

하지만 Headless CMS에도 낮은 처리 속도로 api 속도를 제한적으로 받을 수 밖에 없는 등 약간의 문제가 있었습니다. 그래서 LINE Plus 개발팀은 더 나은 헤드리스를 만들기 위해 연구 끝에 두 가지 해결책을 내놓았습니다.

1. 구조 개편

모델 구조를 데이터베이스로 이전했습니다. 기존에는 모델을 변경하면 재부팅을 해야 했습니다. 그래서 다시 부팅되는 동안 새 데이터를 못 받는 문제가 있었습니다.
그러나 모델 정보를 데이터베이스로 이전하자 더이상 모델을 바꿀 때마다 재부팅을 해야 할 필요가 없어졌습니다.

기존 (콜렉션 모델 수정 -> Restart -> 모델 데이터 수정)

개선 후 (콜렉션 모델 수정 -> 바로 모델 데이터 수정)

부팅 시간이 사라지니 api 요청을 언제든지 받을 수 있게 되고, 서버의 안정성이 보다 증가했습니다.

이처럼 모델 정보를 이전한 것 외에도, 스케일아웃(Scale-out)을 적용했습니다.

스케일 아웃(Scale-Out)이란 서버를 여러 대 추가하여 시스템을 확장하는 것을 말합니다. 하나의 장비에서 처리하던 일을 여러 장비에 나눠서 처리하는 것으로 수평 스케일이라고 부르기도 합니다.

위의 그림처럼 스케일아웃을 적용했고, 기존보다 처리 속도가 최대 400%가 향상되었습니다.

2. Model Cache Storage

모델 구조가 복잡해질수록 모델링 시간이 길어지는 문제를 해결하기 위해, Model Cache Storage를 도입했습니다.

Model Cache Storage를 도입하기 전에는 모델링 과정이 다음과 같았습니다.

API를 가져온다 ▶️ 모델 구조를 가져온다 ▶️ 모델을 정의한다 ▶️ 다시 모델 구조를 가져온다 ▶️ DB를 선택한다 ▶️ 응답

위 이미지에서 보듯이 재귀가 일어났습니다. 그러나 Model Cache Storage를 도입한 다음부터는 아래 그림처럼 구조가 바뀌었고, 더 이상 재귀할 필요가 없어졌습니다.

또한 Model Cache Storage에는 연관된 모든 정보를 조회할 수 있게 해서, 복잡한 관계가 있는 데이터도 빠르고 쉽게 조회할 수 있게 되었습니다.

초록색 선이 Model Cache Storage를 적용하기 전이고, 푸른 선이 적용한 이후입니다. 기존에는 데이터의 관계가 복잡할수록 프로세스에 소요되는 시간이 가파르게 증가했지만, Model Cache Storage를 도입한 이후에는 데이터의 구조와 관계없이 일정한 시간이 걸리는 것을 볼 수 있습니다.

Q&A

Q. 개발 기간은 얼마나 걸렸나요?

A. 런칭까지 약 5개월 정도 걸렸습니다. 현재 1년 넘게 운영되고 있습니다.

Q. 참고로 한 프로덕트가 있었나요?

A. 네. Strapi, Ghost 등 기타 cms를 다 참고했습니다. 동시에 새로운 기능, 기존에 없던 가장 최고의 것을 만들기 위해 노력했습니다.

기존 CMS는 운영중인 경우 중간에 변경하거나 하기가 어려웠습니다. 그런데 우리는 개발환경과 prod 환경을 분리해서 개발하다가 어느 시점 되었을 때 릴리즈 할 수 있게 했습니다. 또한 많은 계층이 있어도 성능저하 없이 운영할 수 있습니다. 개발의 편리함도 사내에서 입증되었습니다. dev쪽에서 미리 api 프리뷰도 확인할 수 있습니다.

Q. 워드프레스같은 헤드가 있는 cms에 비하면 개발방법이 많이 다른데.. 또 플러그인 같은 걸 제공하실 계획은 없나요?

A. Headless CMS 개발은 보편적인 백엔드 개발과 비슷하다고 할 수 있습니다. 또한 추가 기능은 말씀하신 것처럼 플러그인으로 제공해서 프런트엔드 개발자가 더 편하게 개발할 수 있게 할 예정입니다.

Q. 앞으로 더 확장할 방향이나 개선점?

A. 아직까지는 기존에 연결된 데이터베이스가 있는 서비스는 Headless cms를 이용할수가 없습니다. 다른 DB에 연결된 데이터마저도 우리 Headless cms에서 이용할 수 있도록 고민하고 있습니다.

Q. 이걸 만든 개발팀 규모가 어떻게 되나요?

A. 처음엔 저혼자 만들다가 나중에 다른 개발자들이 더 투입됐습니다. 서버는 저 혼자 담당했고, 프런트엔드는 2명 정도였습니다. 운영 중인 현재는 총 20명 가량입니다.

Q. 관계형 데이터베이스(Relational Database)와 비슷해보이는데 이렇게 만든 이유?

A. 맞습니다. 관계형 데이터베이스와 흡사하게 만들었습니다. 그런데 그랬더니 아까 말씀드렸듯이 특정 상황에 속도 저하가 발생했습니다. 그래서 부분적으로 튜닝해서 다른 DB 형태도 이용했습니다. 기본적으로 마이크로서비스 아키텍처를 사용했습니다.

Q. 어떤 다른 거요?

A. 엘라스틱 서치(Elastic Search)도 사용했고 NoSQL도 사용했고 다양합니다.

Q. LINE에서 만든 CMS에 유효성 검사(validation) 같은 부가기능도 있나요?

A. 네. 길이 제한이라던가 카테고라이징해서 특정 텍스트 이외에는 못 들어오게 하는 enum 필드 같은 것도 지정할 수 있게 했습니다. 진짜 서버에서 받고 싶던 내용들 그대로 다 받을 수 있습니다. 심지어 필터링해서 받을 수도 있습니다.

1️⃣ 포스트를 작성하며 참조한 글들

LINE에서 하루 만에 정적 웹 페이지 개발해서 배포하는 방법
Headless CMS explained in 5 minutes
스케일 업(Scale-Up)과 스케일 아웃(Scale-Out)이란?

🪄 Feature Toggle을 이용한 대규모 업데이트 개발 접근 방법 in LINE

이 세션에서는 LINE Growth의 개발자 Kenjiro Isomura님이 Feature Toggle을 이용한 대규모 업데이트 개발에 대한 이야기를 해주셨습니다.

주의: Feature Toggle은 CI 파이프라인이 잘 자리잡은 성숙한 개발팀에게만 유용한 전략입니다. -Matt Sokola

우리에게 Feature Toggle이 필요했던 이유

올 5월, LINE Growth팀은 위 이미지처럼 30개가 넘는 변경 사항과 예상 기간이 6개월이나 되는 장기 대규모 업데이트를 앞두고 있었습니다. Growth 팀은 각자 자율적인 권한을 가진 Squad 형태로 일하는데, 기존에는 전혀 문제 없었지만 이정도 규모의 업데이트를 진행하자니 몇 가지 우려되는 지점이 있었습니다. 예를 들자면 한 스쿼드가 1개 릴리즈할 기능 만드는 사이에 어떤 스쿼드는 20개를 릴리즈할 수도 있습니다. 이로 인해 고민하던 중 한 팀원이 Feature Toggle을 제안했습니다.

Feature Toggle이란?

간단히 말해 배포할 때 어떤 기능을 코드의 변경 없이 활성화하거나 비활성화할 수 있는 메커니즘입니다.


이미지 출처: https://buildd.co/marketing/feature-toggles

예를 들어 어떤 기능을 개발했을 때, 그 기능을 특정 인원에게만 접근할 수 있게 토글해서 운영환경에서 테스트 할 수 있습니다.(참고: 카나리 배포) 이 경우 새 기능에 문제가 생겨도 폭발 반경을 크게 줄일 수 있죠. 좀 더 응용하자면 역할과 권한이 다른 사용자에게는 다른 기능을 표시할 수도 있습니다. (A/B 테스트)

지속적 통합(CI)을 하는 개발팀의 경우, 이 매커니즘을 이용해서 미완성 코드를 메인 브랜치에 병합합니다. 완성되지 않은 코드는 프로덕션 환경에서 비활성화되므로, 불완전한 기능이 사용자에게는 노출되지 않습니다. 아직 개발중인 기능이라 하더라도 사용자에게는 숨긴 상태로 운영환경에 둘 수 있는 셈입니다.

결국 Feature Toggle의 본질은 코드 배포(deploy)와 기능 릴리즈(release)를 분리하는 것입니다. 따라서 개발자는 위험을 줄이면서 새로운 기능과 소프트웨어를 신속하게 출시할 수 있습니다.

Feature Toggle의 단점

Feature Toggle을 도입할 경우 세 가지 우려사항이 있었습니다.

  1. 조건 로직이 복잡해진다.
  2. 기능이 노출될 위험성이 생긴다.
  3. QA의 비용이 증가한다.

그러나 이러한 점들에도 불구하고 도입했을 때 얻는 이득이 더 크다는 판단을 내렸고, 프로젝트에 적용하게 되었습니다.

React Custom Hook을 이용해서 Feature Toggle 구현하기

구현하는 법을 설명하기 앞서 프런트엔드가 Feature Toggle을 개발할 때 주의해야 할 점이 2가지 있습니다.

1. 기능이 유출되지 않도록 잘 off 해두기
2. 각 개발환경마다 각자 토글할 수 있게 해야 함

설명을 돕기 위해 Next.js로 간단한 sample 앱을 만들어봤습니다. useFeatureToggle이라는 hook은 isEnable이라는 State와 3개의 렌더함수를 갖고 있습니다.

isEnable을 자세히 살펴보면 feature라는 환경변수를 가지고 있으며 targetFeature가 바뀔 때 isEnable의 state가 업데이트 되는 구조입니다.

renderFeatureToggle이라는 함수를 살펴보겠습니다. renderFeatureToggle은 on과 off라는 프로퍼티를 가집니다. isEnable이 true면 On 요소를 표시하고, false면 Off요소를 표시합니다.

renderFeatureOn과 renderFeatureOff 역시 흡사한 방식으로, isEnable이 True면 render하고, false면 render하지 않습니다.



render hooks를 쓴 이유

소스코드 클린업에 유리하기 때문입니다. Feature Toggle의 경우 업데이트가 완전히 끝난 다음에는 관련 코드를 제거해줘야 하는데 render hook을 사용하면 코드를 어렵게 수정할 필요 없이 지우는 것만으로 간단히 제거할 수 있습니다.


배포 전략

배포에는 가상 릴리즈 작업 흐름(Virtual Release Operation Flow)를 사용했습니다.

가상 릴리즈에 대해 알아보기 전에 일반적인 릴리즈를 먼저 살펴보겠습니다. 일반 릴리즈는 보통 하나의 스프린트가 4단계로 나눠지고, 아래 이미지와 같은 형태로 진행됩니다.

일반적인 릴리즈 작업 흐름

개발 단계(Development phase)

  • 스쿼드 A가 로컬에서 어떤 기능을 개발합니다.

기능 QA 단계(Feature QA phase)

  • 스쿼드 A의 feature 브랜치에서 스쿼드 A의 develop 브랜치로 머지됩니다.
  • 스쿼드 A의 환경에 배포됩니다.
  • 그 기능의 QA를 하고 이슈를 해결합니다.

회귀 테스트 단계(Regression QA phase)

  • 스쿼드 A의 develop 브랜치를 프로젝트의 develop 브랜치로 머지합니다.
  • 베타 환경을 배포합니다.
  • 회귀 테스트를 진행합니다.

릴리즈 단계(Release phase)

  • develop 브랜치를 master 브랜치로 머지합니다.
  • 프로덕션 환경을 배포합니다.
  • 프로덕트 QA를 합니다.
  • 릴리즈합니다.
  • 스쿼드의 develop 브랜치로 백머지(Back-merge)합니다.

가상 릴리즈 작업 흐름

개발 단계(Development phase)

  • 스쿼드 A가 Feature Toggle이 On된 상태로 로컬에서 개발합니다.

기능 QA 단계(Feature QA phase)

  • feature 브랜치를 스쿼드 A의 develop 브랜치로 머지합니다.
  • 두 개의 환경에 배포합니다
    - 스쿼드 A-1 (토글 off 환경)
    • 스쿼드 A-2 (토글 on 환경)

회귀 테스트 단계(Regression QA phase)

  • 스쿼드 A의 브랜치를 develop 브랜치로 머지합니다.
  • 베타 환경에 배포합니다.
  • 회귀 테스트를 진행합니다.

릴리즈 단계(Release phase)

  • 이 단계에서 마스터 브랜치로 머지하지 않습니다.
  • 스프린트 개발이 끝난 것으로 간주합니다.
  • 이를 '가상 릴리즈'라고 부릅니다.
  • 다른 스쿼드 브랜치로 백머지(Back-merge) 합니다.
  • 현재 발생한 Conflict들을 해결합니다.

자, 이쯤에서 질문이 생기실 겁니다. 그럼 우리가 만든 건 언제 가상 릴리즈가 아니라 실제로 릴리즈 되나요?

바로 '다른 스쿼드의 기능들도 다 테스트까지 끝났을 때'입니다.

Feature Toggle을 도입하고 생긴 변화

  • Conflict 감소
    워낙 대규모 업데이트라 충돌이 아예 안 날 수는 없었습니다. 하지만 많이 줄었습니다.

  • 개발이 계획대로 진행됨

    회색 선이 계획했던 개발 일정이고 파란 선이 실제 일정입니다. 빨간 박스 부분을 보시면 후반부에는 심지어 계획했던 것보다 속도가 더 빨랐습니다. 후반부에 발생할 것이라 예측했던 QA를 많이 줄였기 때문입니다.

결론

"Feature toggle은 대규모 업데이트를 해야 하는 팀에게 유용한 전략이 될 수 있습니다."

개인적으로 세션을 마무리하며 말씀해주신 아래 내용이 가장 인상 깊었습니다.

우리가 마주하는 모든 문제는 우리가 처음 마주한 것이 아니라 누군가가 이미 마주했던 문제입니다. 저도 Feature Toggle을 공부할 때 다른 프로젝트의 도움을 정말 많이 받았습니다. 그래서 우리의 프로젝트가 다른 사람들에게도 좋은 힌트가 되었으면 합니다.

Q&A

Q. 서드파티 라이브러리도 사용하셨나요?

A. 우린 사용하지 않았습니다. 검토를 해보긴 했는데 이번 업데이트에선 쓸 필요 없겠다는 결론을 내렸습니다.

Q. feature toggle을 커스텀 훅으로 구현한 이유는?

A. 기존에 사용자가 토글할 수 있는 기능도 이미 hook으로 만들어져있었습니다. 그리고 우리는 데이터 관리를 Redux로 하고 있었기 때문에 custom hook과 궁합이 좋았습니다.

Q. 업데이트 끝난 다음에 만들어진 feature toggle은 어떻게 되나요? 아마 제거될 거 같은데.. 또 이 이후에도 feature toggle을 이용해서 개발할 생각 있으신가요?

A. 맞습니다. 업데이트가 끝난 후 관련 코드는 삭제했습니다. 음, 그리고 Feature Toggle은 6개월 정도의 대규모 개발일 경우에는 효과가 크다 생각하는데 평상시, 그러니까 자질구레한 스프린트에서 쓸 때는 검토가 필요할 거 같습니다.

2️⃣ 포스트를 작성하며 참조한 글들

Build Your Own Feature Toggle with Next.js and React in Under 30 Minutes
Git Flow에서 트렁크 기반 개발으로 나아가기
What is Feature Toggles (aka Feature Flags)
How to implement feature flags in React
[DevOps] Feature flag란 무엇일까?

profile
공부하는 즐거움

0개의 댓글