Front End 개발전 고민해야할 것들

개발전 구성원들과 사전에 합의하고 고려할 것들을 정리해 봅니다.

2021-01-21

Front End 프로젝트 시작하기

새로 FE 프로젝트를 시작하면서 고려해야 할 것을 공유해 봅니다.

물론 미리 모든 것을 결정하고 답을 내릴 수 있다면 좋겠지만 그렇지 않은 것이 현실입니다. 따라서, 모든 결론을 내리고 시작하려 하지말고 프로젝트 중간에 조정 및 폐기를 결정할 수 있다는 열린 마음이 필요합니다.

또한 구성원들간에 합의를 이루는 과정은 때로는 발전적인 때로는 소모적인 논란을 가져옵니다. 떄로는 논리적이고 수치를 기반으로한 결정이 옳아보이지만 사람은 감정의 동물이고 일은 사람이 하는 것임을 잊어서는 안됩니다. 이해보다는 공감을 목표로 서로가 노력해야 합니다.

기획 툴 선정

2020 Tools Survey Results를 확인해 보면

Figma가 단연 선두에 있습니다. Figma는 wireflame은 물론 디자인, 에니메이션등을 표현할 수 있습니다. 또한, 여러 참여자들이 특정 위치의 디자인에 대하여 대화를 나눌 수 있습니다.

초기 아이디어 논의 단계에서는 miru라는 툴을 활용하면 좋을 것 같습니다. 하지만 이미 Figma를 사용하고 있다면, 동시 편집과 같은 협업 기능으로 충분히 brainstorimg 및 design thinking 프레임워크를 시도해 볼 수 있습니다.

프로젝트 기획

기획이 무엇보다 중요하겠죠. 무엇을 만들지 모른다면 나머지 논쟁은 의미 없을 것 입니다.

우선순위와 주요 시나리오를 파악하여, 최소한의 기능(MVP)으로 적절한 로드맵을 정하는 것이 좋습니다.

주단위 혹은 2주 단위로 기획-프로토타입핑을 반복하여 빠르게 실패하면서 정답을 찾아간다고 생각해야 합니다.

디테일은 지속적으로 가다듬는다는 생각으로 초기에 너무 지엽적인 문제에 시간을 허비하지 않도록 합니다.

모든 것을 한번에 정의하려면 한잘자국도 못 가고 지쳐버릴 겁니다.

따라서 1주 내지 격주 간격으로 적절한 산출물을 끌어낼 수 있는 정도의 기획이 필요합니다.

다만 기획을 자주 변경하는 과정 속에서 서로가 지치거나 비난을 하는 상황이 올 수 있습니다.

따라서 기획은 모두가 참여하되 사용자를 우선순위를 두고 서로의 의견을 존중하며 잦은 변경이 있을 수 있다는 공감대가 필요합니다.

기술 스텍

이제 본격적으로 기술적인 내용이 나오겠네요.

react, vue, angular js 등 다양한 프레임워크 중 어느 것이 좋을지 결정해야 합니다.

저는 next.js, typescript, recoil, tailwindcss 등을 선호합니다. (참조)

DB 인터페이싱이 필요하다면 prisma를 사용합니다.

REST API

REST API를 사용할 때에는 OpenAPI Spec 형식으로 사양을 정리합니다.

정리한 사양은 코드 생성기를 통해서 만들 수 있습니다.

참고로 저는 dtsgenerator로 json schema로 부터 type 정보를 추출하고 실제 API는 손코딩을 하는 편 입니다.

  • 참고: https://app.swaggerhub.com/search

nest.js를 사용하여 API 서버를 구현하고 swagger 문서를 생성하면 됩니다.

사양을 미리 정하고 코드를 생성하는 방식도 가능합니다. (참조)

GraphQL

API endpoint가 많고 통신 방식이 REST, gRPC, thrift 등으로 다양하다면 이들을 중간에서 proxy 해주는 API 서버를 둘 수 있습니다.

때로는 단순히 proxy를 넘어 각 endpoint의 응답을 상호 참조하고 join 하는 요청을 처리해야 할 수 있습니다.

그리고 이러한 종류의 요청이 많아지고 endpoint가 계속 추가되고 조합이 더욱 다양해 질 수 있다면 GraphQL을 고민해야 합니다.

때로는 이러한 종류의 요청이 매우 무거운 작업이라 cache등이 필요할 수 있습니다.

GraphQL에서 cache의 구현은 어려운 주제가 될 수 있기에 실제로 구현하기 전에 고민이 필요합니다.

디자인 시스템

디자인 시스템을 직접 정의하고 개발하는 것은 또 다른 수준의 이야기 입니다.

다행히 여러 분야의 회사에서 디자인 시스템을 만들고 오픈 소스로 공유하고 있습니다.

https://adele.uxpin.com/

각각의 지향점이 다른 만큼 프로젝트의 성격에 맞게 이들 중에서 선택하는 것도 좋을 것 같습니다.

모니터링 툴

감각에 의지해 UX를 결정하는 시대는 지났습니다.

Data driven 디자인을 통해 UX를 개선하고 검증해야 합니다.

오류

브라우저의 exception 등을 리포팅 해 줍니다

사용성

방문 사용자 정보를 통해 사용자들이 어느 경로를 통해서 페이지 이동을 하는지(Funnel) 측정 합니다.

Rudder stack은 정보를 한곳에 모아 GA등에 전달하는 오픈소스 CDP(Customer Data Platform) 입니다.

feature flag, A/B 테스트

Feature flag를 통해 신규 기능을 on/off 할 수 있습니다.

신규 시나리오를 특정 조건의 사용자에게 노출하여 개선사항을 확인해 보고 싶다면, A/B 테스트 솔루션을 검토합니다.

퍼포먼스

페이지가 느려지지 않았는지 관련 지표(CLS, FID, LCP)를 모니터링해야 합니다.

퍼포먼스가 사용자 경험에 영향을 미치지지는 않는지 사용성 지표와 함께 수집함으로서 지속적으로 관찰합니다.

라이브러리를 새로 추가할 때, bundling 크기와 함께 퍼포먼스 지표를 측정하여 사용성에 영향은 없는지 확인합니다.

  • https://github.com/GoogleChrome/web-vitals

Front-End Performance Checklist 2021 — Smashing Magazine를 참고하여 그 밖에 놓치고 있는 개선사항은 없는지 확인합니다.

Session recording

사용자 화면 전체를 레코딩 하는 툴 입니다.

때로는 특정 사용자와 특정 경로의 조합으로만 발생하는 버그나 이슈가 있습니다. 이럴때, 어떠한 경로를 통해 문제가 발생했는지 파악이 필요할 때가 있습니다.

Session recording은 이러한 경우 유용합니다.

다만 개인 정보 보호 이슈는 없는지 확인하고 적용합니다.

테스트 방식 고민

테스트 자동화를 통해 테스트를 최소화 합니다. 아이러니 하죠.

우리 개발자는 모두 게으릅니다. 하지만 책임감이 없는 것은 아니죠. 책임조차 자동화 하고 싶을 뿐 입니다.

개인적으로는 storybook과 api mocking을 통해 edge case 시나리오를 재현하고 selenium을 통해 테스트 하는 것을 선호 합니다.

물론 특정 알고리즘이나 비지니스 로직 라이브러리를 위해 유닛테스트를 수행해야 겠죠.

그렇다고 사용자가 마주하게될 UX를 테스트 안할 수 없습니다.

E2E 테스트는 독립적인 테스트 환경과 테스트 환경의 재현성이 보장되어야 의미 있습니다.

또한 빠른 릴리즈를 위해 적정한 테스트 시간을 유지하는 것도 중요 합니다.

storybook/api mocking/selunium 조합을 사용하여 API 서버를 제외한 모든 UX를 검증할 수 있습니다.

마치며...

위에 나열한 내용 말고 프로젝트 kick off 시 고민해야 할 것들이 많을 겁니다.

생각나는 것이 있다면 피드백 부탁 드립니다.

가장 힘든 것은 구성원 모두가 지식의 저주에 빠지지 않고 서로를 득하며, 무작정 신기술과 유행하는 방법론을 쫓아 over engineering 하지 않고 서로가 의견을 일치해 나가는 인내와 배려 입니다.

모두가 만족하는 적정 수준의 솔루션을 선택하는 것이 중요합니다.

Loading script...