게으른 프론트엔드 개발자가 일을 떠넘기는 방법 😈

0. 사건의 시작

우리에겐 프로젝트가 계약되고 그 프로젝트가 종료될 때까지 언제나 변경 가능성이 있는 페이지가 있습니다. 이걸 이 글에서 "브랜드 페이지"라고 부르겠습니다. (실제로 그렇습니다.)

항상 요구사항이 깔끔하게 딱 나오고, 그거에 맞춰서 구현이 되어 배포가 되고 나면 더이상 추가 요청사항 없이 끝난다면 얼마나 좋을까요?

🐝: "지수님 우리 이거 오픈 날짜가 변경되어서 업데이트 해야 돼요!"
🐝: (다음 날) "지수님 이거 디스코드 링크 잘못 만들어서 만료되었다고 나오네요. 이것도... 빨리 업데이트 해야 합니다"
🐝: (그 다음 날) "지수님 이거...이미지가 사이즈가 이상해서......"
🐝: "지수님!"
🐝: "지수님!!!!!!!"
🤖: (도망)

하지만 쉽지 않죠. 심지어 이런 일도 발생할 수 있습니다.

🤖: "브랜드 페이지 디자인 언제 오나요? 원래 오늘 받기로 했는데...💀"
🤖: (다음 날) "오늘은 받을 수 있을까요?"
🤖: (그 다음 날) "제발요"
🐝: (도망)

저희는 언제나 이게 "최최최종", "제발요 제발 최종 해주세요" 느낌으로 일을 처리하게 됩니다. 정말 사소한 글자, 이미지 수정 요청들은 요청하는 사람도 받아서 처리하는 사람도 지치게 됩니다. 미안할 일이 아닌데 미안해지고, 화낼 일이 아닌데 화가 날 수 있습니다.

하지만 우리의 꿀벌 PM은 잘못한게 없었습니다. 그저 꿀벌처럼 열심히 일을 하고, 빠르게 일을 가져다 날랐을 뿐.

그리고 사실 더 근본적인 문제가 있었습니다. 이 문제의 "브랜드 페이지" 들은 프로젝트마다 다 보여주고 싶은 것도 다르고, 누가 디자인 하는지도 다 달랐습니다. 그래서 매번 요구사항에 맞춰 하나하나 다 마크업을 해야 했고, 모든 static한 데이터들을 다 들고 있어야 했습니다. 웹 어플리케이션이 점점 더 무거워질게 뻔했습니다.

그럼 이걸 해결할 수 있을까요? 누구의 잘못도 아니지만 이상하게 서로에게 미안해지는 이 작고 소중한 수정사항들을 쉽고 빠르게 고칠 수 있는 방법은 없을까요? 이 무거운 파일들을 다른 곳에 보관할 방법은 없을까요?

1. 너는 다 계획이 있구나

다 알고 있던 일이었습니다. 너무 뻔한 결말이었기 때문에, 이렇게 될 것이란 것을 처음 요구사항 때부터 알고 있었습니다. 그래서 처음에 듣자마자 했던 이야기가 있었어요.

🤖: "우리가 프로젝트 오픈을 1, 2개 하고 말 것도 아닌데, 이런 식으로는 지속할 수 없어요."

그렇지만, 당시에는 당장 한달 안에 결제 시스템도 만들고 브랜드 페이지도 만들어서 프로젝트 오픈을 해야 했기 때문에 어쩔 수 없었습니다. 우선 지금 빠르게 오픈해야 하는 프로젝트는 어찌어찌 해내고, 최소 3, 4개 프로젝트가 오픈되기 전에 대책을 마련해야 했습니다.

🤖: "최소 4개 프로젝트 오픈 후에는 다른 프로세스로 프로젝트 오픈 할 수 있도록 대책을 세워볼게요."

대체 어떻게 해야 할까 고민을 하던 중, 갑자기 이전에 개발팀 헤드님께 들었던 말이 떠올랐습니다. (1,2개만 이야기를 했던게 아니라 시간이 지나 각색되었음)

☕️: "유튜브 API 중에 화면을 어떻게 그리라는 식의 응답을 주는 게 있어요."
☕️: "Strapi라고 HeadlessCMS 있는데, 좋더라구요."

(사실 위의 사진은 방금 캡처 뜬 이미지)

생각이 번뜩 했을 때, 바로 Youtube를 들어가 DevTool을 열어서 API들을 확인해봤습니다. 이걸까, 저걸까.
데이터를 보다보니, 화면에 들어갈 title 값도 주고, simpleText 값도 주고 owerChannelName 이런 값도 눈에 들어왔습니다. 화면에 어떤 글자가 렌더링 되어야 하는지 서버와 이미 약속이 된 키값으로 주고 받는 것 같았습니다. (그래 이렇게 하면 되겠구나 🥲)

Strapi는 이전에 헤드님께서 말씀하셨을 때 궁금해서 해본게 있었기 때문에, 더 비교할 것이 없었습니다. 제가 봤을 때 이렇게 깔끔한 관리자 페이지와 endpoint 마다 role을 지정할 수 있는 기능, AWS S3 Bucket와의 쉬운 통합 기능 정도 제공한다면 당장 적용해볼 수 있겠구나 생각이 들었습니다.

Strapi를 선택한 이유

• 사용하기 편한 관리자 페이지 제공
• endpoint 마다 role 부여 가능
• AWS S3 Bucket 통합
• internationalization (줄여서 i18n, i와 n 사이에 글자가 18개나!)

하지만, 프론트엔드 팀에서만 이걸 소화해내기에는 쉽지 않아보였습니다. DB에 대해 더 잘 알아야 데이터 구조화를 더 효율적으로 잘 할 수 있을 것 같아 백엔드 팀에 함께 해달라고 요청드렸습니다. (함께 해주세요 💌)

Strapi를 개발 서버, 운영 서버에 배포를 하고 DB를 올리고, 싱크를 맞추는 등 인프라 작업도 필요했고, 어떤 API를 어떻게 만들 것인지, (single 타입으로 할지 collection 타입으로 할지) 등등 사실 가까이서 들여다보면 중요한 일이 참 많았습니다.

프론트엔드 팀에서는 그동안 했던 프로젝트들의 브랜드 페이지에서 공통적인 부분을 분리하고, 공통 컴포넌트를 만들었습니다. 언뜻 보기엔 비슷해보이는 컴포넌트여도 각기 다른 요구사항들 때문에 미묘하게 달랐습니다. 그런 부분을 디자이너 분들과 회의를 통해 공통 컴포넌트를 만들어냈습니다.

역할 분담

• 프론트엔드, 디자이너: 공통 컴포넌트 제작
• 백엔드: Strapi API 생성 및 관리

프론트엔드 팀에서 준비해둔 공통 컴포넌트들의 이름과 그 컴포넌트들이 받아야 하는 데이터들을 정리하면, 백엔드 팀에서는 Strapi를 활용해 그 데이터를 내려줄 API를 만들었습니다.

프론트에서 /api/velog 이렇게 요청하면,

{
  project: "velog",
  contents: [{
    SingleImage: {
      img: "<image_url>",
      alt: "velog main image"
    },
    SocialButtonGroup: {
      discord: "<discord_url>",
      kakao: "<kakao_open_chat_url>"
    },
    ...
  }]
}

(실제 형태가 아닙니다, 예시입니다.)
이런 식으로 데이터를 내려주고 프론트에서는 받은 데이터들을 확인해서 순서대로 화면을 렌더링했습니다.

일단 이렇게 변경을 하고나니, 엄청난 효과가 발생했습니다. 물론 처음에는 개발팀이 Strapi 관리자 페이지에서 데이터를 수정했기 때문에, 아직까지는 PM분들의 변경 요청을 받아서 처리해야 했습니다. 변경사항 업데이트에 대한 관리 주체는 여전히 개발팀입니다. 그러면 대체 무슨 효과가 있었다는 거냐, 그것은 바로 "배포"를 안해도 된다는 것이었습니다.

현재는 Github Actions를 활용한 이미지 빌드 및 업로드가 자동으로 되어 편해졌습니다. 그러나 당시에는 로컬에서 미리 짜둔 빌드 스크립트를 활용해서 컴퓨터 자원을 백배 활용해야 했고(😭) 다음과 같은 과정을 거쳐야 했습니다.

과거의 배포 과정

• Docker 이미지를 만다
• ECR에 올린다.
• 그 이미지명을 가져다가 ArgoCD에 들어간다
• 이미지명을 변경하고 Sync를 한다

이걸 안해도 된다니. 변경 요청사항을 대응하려면 간단한거라도 최소 30분이 걸렸고, 작업, 배포 및 확인 과정까지 하려면 최소 3명의 사람이 필요했습니다. 그러나 이제 Strapi 관리자 페이지에서 변경할 사람과 확인할 사람, 딱 2명만 있으면 5분도 걸리지 않는 작업이 된 것입니다.

이때 발생한 효과

• 최소 30분의 시간 > 최소 5분 컷
• 작업 1명, 배포 1명, QA 1명 (여기서 글자 하나 변경이라도 PR 리뷰를 할거라면 1명 더 필요함) > 작업 1명, QA 1명

최소한으로 만들어진 공통 컴포넌트가 있었기 때문에, 앞으로 프로젝트가 새로 들어온다고 하면 가이드 문서를 제공하면 되기 때문에 디자인 공수도 어느정도 줄었습니다. 규격화된 폼이 있기에 추가로 요청사항이 있을 때만 새로운 컴포넌트를 생성하면 되었습니다.

심지어 개발 서버에 있는 Strapi 관리자 페이지에서 업데이트를 하고 개발 서버에서 미리 확인까지 가능하니까 QA 기간까지 확 단축될 수 있었습니다.

2. 모든 것을 드릴게요

이것만으로도 작업 기간이 짧아졌기 때문에 어제보다 행복한 오늘이지만, 저는 게으른 개발자이기 때문에 이 일에서도 벗어나고 싶습니다. (🤖)

이제는 Strapi 관리자 페이지의 매뉴얼을 작성하고 PM분들과 프로젝트를 계약하고 관리해주시는 팀에 온보딩을 진행합니다. A 컴포넌트에 이 값은 무조건 있어야 한다거나 B 컴포넌트는 C 컴포넌트와 함께 쓸 수 없다거나 하는 중요한 사항 들부터 정말 Strapi라는 것을 전혀 모르는 팀원분들도 들어가서 사용하실 수 있도록 꼼꼼하게 문서 작성을 했습니다.

팀원분들이 사용을 하면서 발생하는 질문들에 대한 Q&A 문서(자주 묻는 질문)도 작성해두고, 혹시라도 사용하면서 의문이 드는 포인트가 있다면 문서부터 확인해볼 수 있도록 했습니다.

여기까지 되었을 때 새로운 효과가 발생했습니다. 이제는 새로운 브랜드 페이지를 오픈할 때, 새롭게 만들어야 할 컴포넌트가 없다면 아예 개발팀 없이 운영팀에서 브랜드 페이지를 만들 수 있게 되었습니다. (🎉)

최종적으로 발생한 효과
기존 - 작업기간 한달, 개발팀 필요함, 변경사항 있을 때마다 개발자한테 요청해야 함
현재 - 작업기간 빠르면 1주일, 개발팀 필요없음, 변경사항 직접 적용

저희는 이렇게 공수를 들여서 만들어놓은 프로세스를 차근차근 메인 홈의 슬라이드에도 적용하고, 이벤트 배너에도 적용해갔습니다. 그래서 지금은 Strapi로 데이터를 받아서 렌더링하는 컴포넌트가 꽤 많아졌네요. 모든 부분들이 다 브랜드 페이지처럼 컴포넌트부터 관리하지는 않지만, 메인 홈 슬라이드의 이미지를 순서대로 관리를 한다거나 하는 부분에 간단하게 만들기 좋습니다.

이제 게으른 개발자는 자유를 얻었습니다. 🎉