프론트엔드 주도 개발

주도 개발

TDD, BDD, DDD 뒤에 붙은 DD(Driven Development) 에서 따온 단어인데요.

개발뿐만 아니라 협업에서도 주도하는 역할이 중요하다고 생각합니다. 저는 프론트엔드 개발자로서 여러 프로젝트에서 다양한 분들과 협업을 해 왔는데요. 프론트엔드 개발자가 할 수 있는 주도 개발에는 어떤 것이 있을 지 고민해 봤습니다.

프론트엔드가 하는 일

프로젝트에서 프론트엔드가 하는 작업은 UI/UX를 고려한 컴포넌트 설계 및 제작, api 요청응답 관리, 라우팅 설계, 최적화 작업 등 여러 가지가 있습니다.

이 중에서 저는 오늘 UI/UX와 api에 관련하여 프론트엔드가 주도할 수 있는 작업을 얘기하려고 합니다.

늦어지는 작업 속도

"디자인이 아직 없어서 컴포넌트를 제작할 수 없어."

"백엔드 api 구현이 안 되어서 api 연동을 못 하네. 일단 mock data로 대신해서 보여줘야 하나..?"

다들 프로젝트를 하면서 이런 경험을 한 번쯤 해 보셨을 것 같아요. 개발을 처음 시작했을 때는 이 간극을 어떻게 메워야 할 지, 팀원에게 어떤 식으로 얘기할 지 고민이 많았던 것 같습니다.

여러 프로젝트를 진행해 오면서 이 고민은 점점 커졌습니다. 어떻게 하면 디자이너-프론트, 프론트-백엔드 간의 작업 병목을 해소할 수 있을까 하고요.

Storybook으로 디자이너와 협업하기

Storybook은 React, Vue 등에서 사용되는 UI 컴포넌트를 효율적으로 관리할 수 있는 개발 도구입니다.
그 외에 Storybook에 대해 조금 더 알고 싶으시다면 React + Storybook 적용을 참고해주세요!

개발을 하다 보면 UI 컴포넌트가 많아져 폴더를 일일이 찾아봐야 하는 번거로움이 생길 때가 있습니다.

이때 Storybook을 사용하면, 현재 추가한 UI 컴포넌트들만 모아 볼 수 있어요. 버튼을 예로 들면 Button.stories.ts로 버튼 스토리를 추가할 수 있어요.

UI 컴포넌트가 많아질수록 추가해야 할 스토리 파일도 많아질 거에요. 저는 stories 라는 폴더에 스토리 파일들을 배치했어요. 컴포넌트 파일과 같이 두는 경우도 있지만 확장성을 고려한다면 저처럼 다른 폴더로 분리하는 것을 추천합니다.

Storybook 본 컴포넌트

스토리북을 설치하셨다면 npm run storybook으로 스토리북을 실행할 수 있어요.

왼쪽 파일들이 모두 stories.ts 파일입니다. 오른쪽엔 이름, 설명, 타입, 제어 등 다양한 속성이 존재해요.

import { Button } from '@/components/Button/Button';
import type { Meta, StoryObj } from '@storybook/nextjs';

const meta: Meta<typeof Button> = {
  title: 'Components/Button',
  component: Button,
  tags: ['autodocs'],
};

export default meta;
type Story = StoryObj<typeof Button>;

해당 코드는 Button 스토리 파일에서 기본으로 설정해야 하는 코드입니다. tags: ['autodocs'] 부분이 문서 페이지를 자동으로 생성해주는 부분이고요.

meta 객체는 스토리북 사이드바에 표시될 경로, 그리고 문서를 만들 대상 컴포넌트를 지정하는 핵심적인 설정이에요.
그 외 StoryObj 타입이나 export default meta 구문은 타입스크립트의 타입 안정성을 등록하기 위한 표준 보일러플레이트입니다.

Chromatic으로 배포

아직은 로컬에서만 보이는 스토리북을 배포할 수 있는 방법이 따로 있습니다. 바로 Chromatic이라는 도구입니다. netlify,vercel 같은 배포 도구가 있지만 chromatic은 배포 전에 컴포넌트를 미리 볼 수 있고, 무엇보다 스토리북에 최적화되어 있다는 것이 장점이기에 사용했습니다.

npm install --save-dev chromatic // 의존성 설치

npx chromatic --project-token <your-project-token> // 스토리북을 chromatic에 배포

명령어를 수행하면 추가한 스토리북 파일들이 chromatic에 배포됩니다. 실제로 제가 배포한 스토리북 배포링크 입니다.

디자이너에게 공유하기

위 링크는 서비스가 배포되기 전에 미리 디자이너에게 공유할 수 있습니다. 이것의 가장 큰 장점은 디자이너가 보는 UI와 개발자가 제작한 UI 간극을 최대한 줄일 수 있다는 것입니다.

이미 머지가 된 PR인데 갑자기 수정 요청이 오면 당황스럽겠죠. 또 자주 그런 일이 발생한다면 개발자나 디자이너 모두에게 부담이 될 것입니다.

💁🏻 개발 주도하기

일반적으로는 디자이너가 먼저 Figma 같은 디자인툴을 이용해 컴포넌트를 디자인하고, 개발자가 이를 코드로 구현하는 "디자인 주도 개발" 방식을 따릅니다.

하지만 개발자가 먼저 공통 컴포넌트를 만들고 디자이너에게 공유하는 개발을 주도할 수 있지 않을까요?

장점

심미적인 부분이나 UX적인 흐름보다 기능 구현에 초점을 맞춰 공유한다면, 디자이너는 기능적인 측면의 고민들보다 UX와 그 외 스타일 부분들에 집중할 수 있어요. 또한 빠른 프로토타입을 만들어야 할 때 유용합니다.

단점

물론 단점도 존재합니다. 디자이너가 나중에 컴포넌트를 보고 마음에 들지 않는다고 하면, 개발자는 다시 코드를 대폭 수정해야 하겠죠.

그럼에도 추천해요

프로젝트의 성격에 따라 개발을 주도할 수 있는 방법이 달라질 것 같은데요, 이런 방법도 가능할 것 같다~ 라는 하나의 예시로 봐 주시면 될 것 같아요. 그럼에도 불구하고 Storybook과 Chromatic을 사용하는 것은 프론트엔드와 디자인 간의 의사소통을 더 적극적으로 가능하게 하고, 작업 병목을 해소할 수 있는 아주 좋은 방법이라고 생각합니다.

백엔드와 협업하기

그 다음은 프론트엔드-백엔드 사이의 작업 병목을 해결하기 위해서 어떤 방법을 사용할 수 있을까에 대한 고민을 해 봤어요.

API 연동 프로세스

개발자는 API 개발을 하기 위해 해야 하는 여러 가지 단계가 있습니다.

➡️ API 명세서 작성 -> 프론트 UI 개발 -> 백엔드 API 개발 (기다려야 함) -> API 연동

여기서 백엔드 개발자가 API를 개발하기 전까지 프론트엔드는 기다려야 합니다.

추가적으로 생기는 귀찮음도 존재해요.

• 백엔드는 매번 mock api를 생성해주고 삭제해야 함
• mock api를 적용할 때와 아닐 때 api 주소를 변경해야 함

이때 MSW를 활용하여 프론트에서 미리 API 요청/응답을 모의 테스트할 수 있습니다.

msw

Mock Server Worker(msw)는 프론트엔드 개발에서 백엔드 개발이 완료되기 전에 API 요청을 가로채서 모의(mock)응답을 보내주는 라이브러리입니다.

msw 사용 방법

이제 msw 기본 설정에 필요한 핵심 코드들을 설명해보겠습니다.

API 핸들러 정의

📂 src/mocks/handlers.js

http는 어떤 HTTP 요청을 가로챌지 정의하는 메서드들의 모음입니다. 흔히 아는 HTTP 메서드명과 이름이 같아요. 실제 api 코드처럼 작성하면 됩니다.

단지 실제 api 요청을 보내는 것이 아니라, 요청을 백엔드 서버에 도착하기전에 가로챈다는 것이 차이점이에요.

HttpResponse는 http가 가로챈 요청에 대해 실제 브라우저에게 돌려줄 mock 응답을 쉽게 만들어줍니다. 가장 많이 사용되는 게 바로 HttpResponse.json() 메서드에요.

브라우저 환경 설정

📂 src/mocks/browser.js

이제 서비스 워커를 등록하여 mock 폴더에서 발생하는 모든 네트워크 요청을 서비스 워커가 감시하고 가로채도록 합니다.

과거 모킹 라이브러리에서는 fetch나 axios 함수 자체를 덮어쓰는 방식을 사용했다고 해요. MSW는 그보다 더 낮은 네트워크 레벨에서 서비스 워커를 통해 요청을 가로채기 때문에, 코드를 더 깔끔하게 유지할 수 있어요.

어플리케이션에 적용

MSW는 개발 환경에서만 실행되어야 하기 때문에 앱 진입점에 설정해야 할 부분이 있어요.

이제 development 환경에서만 msw가 실행되도록 변경했습니다.
bypass 옵션은 핸들러애 정의되지 않은 요청을 실제 네트워크로 전달하도록 합니다.

💁🏻 개발 주도하기

➡️ API 명세서 작성 -> 프론트 UI 개발 -> 백엔드 API 개발 (기다려야 함) -> API 연동

다시 API 개발 프로세스를 가져오면, 이제 프론트엔드는 백엔드 API 개발이 완료되기 전에 기다림없이 API 요청과 응답을 테스트할 수 있어요.

실제 api 로직이 들어갈 부분에 mock api 코드를 추가하여 개발할 수 있고,
추후 백엔드에서 API 개발이 완료되면 mock api 부분을 실제 api 요청 코드로 변경만 하면 바로 연동이 가능합니다.

마무리

프론트엔드 개발자 입장에서 작업을 주도하는 방법에 대해 알아봤습니다.

글을 쓰면서 프론트 뿐만 아니라 백엔드, 디자이너 등 각 분야의 팀원이 주도할 수 있는 방법은 무엇일지 고민해봐도 좋을 것 같다는 생각이 들었습니다.

제 포스트가 팀프로젝트에 도움이 되었길 바라며 이것으로 마칩니다.