스플 웹 FE를 소개합니다.

스플 웹 서비스는 앱에 비해 쉬운 사용성으로 신규유저 진입의 허들을 낮추고, 웹의 손쉬운 배포를 통해 신규 서비스를 우선 런칭 하여 유저 반응을 분석하는데 사용하고 있습니다. 이 글에서는 스플 웹에서 사용하는기술, 배포 과정 등을 소개합니다.

스플 웹 서비스는 어떤것이 있나요?

스플 웹은 총 4개의 서비스가 있습니다.

스플 웹 (https://storyplay.com/)

• 스토리플레이 웹 서비스
• 현재(2022-07) 1.5 버전 배포 완료

스플 Landing (https://about.storyplay.com/)

• 스플 소개 페이지
• 현재(2022-07) 스플 도메인 변경 작업으로 사용불가 (재 배포 예정)

스플 관리자 페이지

• 스플 서비스 관리자 페이지

스플 스튜디오

• 스플 작품 작성을 위한 웹 서비스

스플 프론트앤드는 이런 기술로 만들어졌어요.

React

• react는 facebook에서 제공하는 자바스크립트 기반의 라이브러리, component 기반으로 쉽게 UI를 만들 수 있습니다. 웹 FE 프레임워크 사용율 에서도 큰 차이로 1위를 차지하고 있습니다.

* npm trands

Next.js

• nextjs는 React로 만드는 SSR(서버사이드 렌더링) 프레임워크 입니다. SSR을 통해 스플 사용자에게 더 빠르게 웹을 보여주고, SPA의 SEO문제를 해결하여 검색엔진이 스플을 좀 더 쉽게 찾을수 있도록 합니다.

TypeScript

• 스플은 TypeScript를 사용하여 개발자의 실수를 줄이고 빌드 시간에 오류를 찾아내어 안정적이고 효율적으로 작업합니다. (JavaScript의 superset으로 JS와 100% 호환됩니다.)

Emotion(CSS)

• 스플은 Emotion을 사용하여 CSS-in-JS로 CSS를 작성합니다. CSS-in-JS는 class 명명이 편하고 css가 컴포넌트 단위로 추상화 되어 모듈간 의존성을 고려할 필요가 없고, 컴포넌트 상태값에 따라 CSS를 구성하기 편합니다. styled-component보다 상대적으로 파일 사이즈가 작고 SSR적용시 서버에 따로 작업이 필요없다는 장점도 있습니다.
• CSS Composition 방식을 기본으로 작성합니다.

Apollo

• 스플 서버는 GraphQL로 작성되어 있어 클라이언트가 선언한 데이터 구조를 그대로 서버에 요청해서 받아 사용할 수 있습니다. GraphQL 데이터 관리를 위해 GraphQL 기반 플랫폼인 Apollo를 도입했습니다. Apollo-client에서 지원하는 글로벌 저장소, 캐시 기능을 활용하여 서버 상태(state)를 쉽게 관리할 수 있습니다. 캐싱된 데이터를 클라이언트에서 바로 사용할 수 있어 클라이언트 상태관리 코드를 최소화 할 수 있습니다.
• Apollo-Client는 React, angular, vue.js, Android, iOS 등 다양한 환경에서 사용이 가능합니다.

Redux Toolkit

• 서버 데이터를 클라이언트에서 관리가 필요한 경우 RTK를 사용하여 관리합니다. Redux의 단점(보일러플레이트 코드(action, reducer,…), 패키지 의존성(redux-thunk, immer,…))을 극복할 수 있고, Slice를 통해 action, reducer 구조를 쉽게 작성할 수 있습니다.
• state를 공유하는 컴포넌트가 많지 않거나 state가 단순할 경우 Context를 사용하기도 합니다.

코드 컨벤션

• ThingsFlow JS 코드 컨벤션을 사용합니다.

CI / CD

• Github Action
• Github에서 제공하는 workflow 자동화 tool로 스플 브랜치별 CI/CD 세팅을 하여 빌드 확인과 AWS배포 등 작업을 자동화하고, 결과를 Slack을 통해 전달받을 수 있도록 합니다.

serverless next.js

• Web 서비스 AWS 배포시 Serverless next,js(link) 를 사용하여 쉽고 빠르게 AWS 배포를 수행합니다.
• AWS 관련 정보는 인프라팀 담당자에게 전달받아 사용합니다.

Git Flow

깃 전략 수립을 통해 개발, 배포, QA 상태를 확인하고 개발 상황을 쉽게 인식할 수 있습니다.

*스플 웹FE 개발 파트는 아래의 규칙에 따라 작업을 진행 합니다.

1. 스프린트 계획 회의를 통해 jira에 스프린트를 생성합니다.
2. 생성된 스프린트에 작업할 Story를 생성하고, Story 구현을 위한 개발 Task를 생성합니다.
3. feature branch는 “task-id + 작업이름” 의 형식으로 작성하여 jira 티켓과 github가 연동되도록 하고, 작업 상태는 jira에서 임의로 바꾸지 않고 github branch 상태에 맞춰 자동으로 jira에 업데이트 되도록 합니다.
4. 작업 완료된 feature는 pull request 요청 합니다. 모든 리뷰어의 ‘approval’ comment가 등록완료 되면 작업자가 직접 merge합니다.
5. merge가 완료된 feature branch는 바로 삭제 합니다.

Branch에는 항상 유지되는 (main, develop, contents develop, platform develop, dev deploy, prod deploy) branch와 작업 기간에만 유지되는 feature, hotfix, QA branch가 있습니다.

• main : 운영 서비스로 출시되는 branch, 검증이 완료된 코드만 merge되며 배포시 tag, release 정보를 상세하게 기록한다.
• develop : 개발을 위한 branch로 contents develop, platform develop 각 팀에서 개발 완료된 코드가 merge 된다. 배포 테스트가 필요한 경우 dev deploy로 머지 하여 배포한다.
• contents, platform develop : 컨텐츠, 플랫폼 팀 간의 작업 의존성을 줄이기 위해 각 팀별로 개발 브랜치를 운영한다. 다른팀 작업 완료된 사항을 develop 브랜치에서 pull받아 최신 개발 상태를 유지한다.
• dev deploy : 개발 배포를 위한 브랜치, 코드 머지 시 개발 서버에 배포된다.
• prod deploy: 운영 배포를 위한 브랜치, 코드 머지 시 운영 서버에 배포된다.
• feature : Task 별 개발 브랜치, 개발 완료 후 contents, platform develop 으로 머지 후 브랜치 삭제
• QA : 스프린트 개발 완료 후 QA 진행할때 생성, QA중 발생한 이슈 브랜치 생성 후 작업 완료되면 QA 브랜치에 머지한다. QA 종료 시 develop에 코드 머지하고 브랜치 삭제
• hotfix : 운영 서비스에서 발생한 이슈에 대응하는 브랜치로 main 바로 작업 진행한다.

어떤걸 더 해볼수 있을까?

SSR

• 현재 앱과 동일 수준으로 개발이 완료되지 않았고 홈 리뉴얼 작업이 필요해 SSR이 모든 페이지에 구현되지는 않았습니다. 웹TF 종료 후 유저분들께 빠른 화면을 보여드릴 수 있도록 SSR 확대 적용을 검토하고 있습니다.

TDD

• 보다 안정적인 스플 웹을 만들수 있도록 jest 를 사용하여 TDD도입을 고려하고 있습니다. TDD를 통해 개발단계에서 버그발견, 유지보수, 리팩터링 할 수 있어 개발에서 서비스 배포까지의 시간을 절약할 수 있고 안정적인 서비스를 운영할수 있을거라 예상합니다.

Typescript, React 코드 컨벤션

• JS 기반으로 작성되어있는 코드 컨벤션을 TS, React 까지 확장해서 띵스플로우 웹 FE의 공통 컨벤션을 웹FE 개발자 분들과 함께 만들어 나가면 좋겠습니다.

마치며

이상 스플웹 FE에 대해 간략하게 소개드렸습니다. 스플 웹 기술선정에 있어 안정성과 성능, 확장성을 우선으로 고려했고 선정한 기술은 웹FE 직무미팅을 통해 의견을 모아 확정했습니다. 스플 개발, 배포 과정에서 의도치 못한오류들을 만났지만 띵플러분들의 도움으로 무사히 개발완료 할 수 있었습니다. 현재 스플 유입 유저의 절반가까운 분들이 스플 웹으로 진입하고 있을 정도로 스플 웹이 좋은 결과를 보여주고 있습니다. 앞으로 스플 웹이 스플 서비스의 성공과 띵스플로우 웹FE 기술 발전에 큰 역할을 할 수 있기를 바라며 지금까지 긴 글 읽어주셔서 감사합니다.