복잡한 웹 페이지도 개발자 없이 만드는 웹 빌더 “에디터” 개발기 (1)
안녕하세요. 캐치테이블 프론트엔드 개발자 엄지혁입니다!
저는 합류 초기에 주로 마케팅 관련 업무를 담당했는데요. 이 글에서는 그 경험과 그 과정에서 직접 기획하고 제안하여 개발한 ‘에디터’에 대해 소개하고자 합니다.
먼저 이 글은 총 3개의 편으로 구성될 예정입니다.
1편: 에디터의 탄생 과정
2편: 에디터의 개선 과정과 방향성
3편: 에디터에 담긴 기술 이야기
1. 에디터란 무엇인가
에디터는 비개발 직군 누구나 웹 페이지를 생성할 수 있는 툴입니다. 목적에 따라 기능이 조금씩 다르지만, 이런 종류의 프로덕트를 웹 빌더라고 부릅니다. 우아콘을 통해 알려진 만다오에서 영감을 받아 기획하고 개발했습니다.
캐치테이블에서는 단순한 정적 프로모션 페이지 개발을 대체하는 것을 시작으로, 현재는 동적인 프로모션 페이지뿐만 아니라 다양한 유형의 페이지도 에디터로 제작하고 있습니다.
이제부터 에디터를 만들게 된 배경부터 기획 과정, PoC, 개발 과정 순으로 살펴보겠습니다.
2. 에디터를 만든 배경
2–1. 마케팅 관련 업무란?
캐치테이블에서 프론트엔드 개발자가 담당하는 마케팅 관련 업무는 대부분 일회성 프로모션 페이지를 제작하는 일을 의미합니다.
제가 입사했을 당시, 프로모션 페이지는 프론트엔드 개발자가 제작하고 있었고, 몇 년 전부터 축적된 사용하지 않는 이전 프로모션의 잔재들이 프론트엔드 저장소 곳곳에 흩어져 있었습니다.
마케팅 업무 담당자로 입사한 제가 처음 맡은 업무도 위 이미지에 있는 오이스터 페스티벌 프로모션 페이지를 제작하는 것이었습니다.
2–2. 입사 후 프로모션 페이지를 만들다 보니…
프로모션 페이지를 만드는 일 자체는 어렵지 않았지만, 수많은 수정 과정을 거쳤습니다. 와인 이미지 교체, 와인 이름 수정, 설명 오타 정정, 이벤트 기간 변경 등 다양한 수정 사항이 있었습니다!
프로모션의 특성 상 페이지를 완성한 후에도, 심지어 실제 사용자에게 공개된 이후에도 수정이 필요해 핫픽스 배포(치명적인 문제가 있다고 판단하면 최대한 빠르게 수정하는 방식)가 이루어지는 경우가 종종 있었습니다.
수정 사항이 생길 때마다 다음과 같은 프로세스를 거쳐야 했습니다.
- 변경 사항 수정 요청
- 디자인 시안 수정
- 페이지 수정 사항 반영
- 코드 리뷰
- 배포 (테스트 환경 또는 실제 환경)
- QA (소프트웨어의 품질 보증 과정) 진행
- 수정 요청자 확인
대부분이 이미지 교체나 텍스트 수정 같은 단순한 작업인 것에 비해 많은 인력과 리소스가 필요했습니다. 때로는 QA 중에 또 다른 변경 사항이 생겨 같은 부분에 대한 수정 요청이 오기도 했습니다. 이런 일들은 프로모션이 종료될 때까지 언제든 발생할 수 있었습니다.
이런 과정을 프로모션 페이지를 계속 만들어가며 반복하다 보니 “이 프로세스를 꼭 개선해야겠다.” 라는 결심을 하게 되었습니다.
3. 문제 정의
3–1. 각양각색의 수정 사항
수많은 고민과 시도 끝에 깨달은 점은, 일부 툴을 이용해 페이지의 일부분을 수정 가능하도록 하는 것은 의미가 없다는 점이었습니다.
수정 범위가 조금만 넓어지거나 예상과 다르면 결국 같은 과정을 반복해야 했기 때문이죠. 이에 저는 일부가 아닌 전체 페이지를 자유롭게 수정할 수 있어야 한다고 판단했습니다.
블록 기반의 웹 빌더가 이상적인 해결책이라고 생각했지만, 해결하고자 하는 문제를 구체화해서 웹 빌더의 개발 방향성을 고민할 필요가 있었습니다.
3–2. 정확한 공수 산정의 어려움
단순히 수정 사항이 많다는 것만이 프로모션 제작 과정의 문제는 아니었습니다. 프로모션 제작 전, 기획 리뷰 시간을 가지는데요, 기획서 상으론 기간 안에 구현하기에 문제가 없어 보여도, 디자인 시안이 완성되면 상황이 달라지는 경우가 많다는 것입니다.
기존 프로모션 페이지에 없던 새로운 디자인으로 인해 기존 코드를 재사용할 수 없거나, 팝업이나 폰트 크기가 캐치테이블 앱의 기준과 달라 재조정이 필요한 경우가 빈번했습니다.
3–3. 유사한 기능의 반복적인 구현
마지막으로 알림 신청 기능처럼 비슷한 기능을 구현할 때도 고려해야 할 사항이 매번 조금씩 달라져(예: 중복 참여 가능 여부, 일일 참여 횟수 제한 등) 프로모션마다 새로운 API를 만들어야 했습니다.
물론 일회성 프로모션에서 사용하는 API와 관련 코드들이 제때 삭제되지 않아 계속 남아있는 것도 해결해야 했죠.
요약하자면, 아래 세 가지가 주된 개선 사항이었습니다.
- 기획 및 개발 과정에서 수정 사항이 빈번하게 발생한다.
- 기획 리뷰를 거치더라도, 디자인의 영향으로 정확한 공수 산정이 어렵다.
- 매우 유사한 기능임에도 프로모션마다 새로 개발하는 경우가 많다.
4. 해법 찾기
3가지 개선 사항에 대해 제가 찾은 해법을 말씀드리겠습니다.
4–1. 각양각색의 수정 사항
이 문제에 대해 제가 내린 해답은 이미 글의 초입에 나와 있었습니다.
“여러 가지 블록들의 조합으로 웹 페이지를 제작할 수 있도록 한다.”
이 방식은 수정이 빈번하고 각양각색으로 일어난다는 문제를 잘 해결했습니다. 이전에는 페이지의 단순 이미지나 텍스트를 교체하는 수준은 일부 툴로 가능했지만, 전체 레이아웃에 영향을 주는 변경은 어려웠습니다.
하지만 에디터에서는 화면에 그려질 모든 정보를 자유롭게 구성해 페이지를 제작할 수 있습니다. 프론트엔드는 블록들의 조합 정보를 전달 받아 웹 페이지로 변환해 보여주기만 합니다.
수정이 필요하다면 프론트엔드에 전달할 블록들의 조합 정보를 에디터에서 수정하면 끝입니다!
4–2. 정확한 공수 산정의 어려움, 유사한 기능의 반복적인 구현
미묘한 차이의 요구 사항으로 개발 공수가 발생하는 2, 3번 문제에 대한 해법은 다양한 수정이 일어난다는 문제보다는 상대적으로 간단했습니다.
“반복 사용하는 기능에 대한 매뉴얼을 제공하고, 가능한 커스텀 옵션 또한 보여주자.” 가 해결책이었습니다.
결국 “어디까지 커스텀을 지원할 것인가”에 대한 합의가 필요했고, 어디까지 수정할 수 있는 지가 이미 정해져 있다면 이런 문제 또한 해소될 것 같았습니다.
5. 본격적인 시작
제 머릿속에서 모든 정리가 끝났으니 본격적으로 시작할 시간이었습니다. 현재 상황과 에디터의 기대 효과를 기반으로 담당PM, 파트 리드님들에게 비공식적 프로젝트로라도 시도해볼 수 있도록 요청을 드리려 했습니다.
5–1. 현재 상황
제가 입사한 이후 약 6개월 동안 제가 제작한 프로모션은 10개였습니다. 이 과정에는 QA, 백엔드 & 프론트엔드 개발자, PM, 마케터, 디자이너 등 많은 인력의 업무 리소스가 투입되었고, 소통 비용도 발생했습니다.
게다가 프로모션 제작 기간은 개발 기간만 따져도 보통 3~5일입니다. QA기간과 디테일한 수정을 하는 기간을 더한다면 보통 2주가 넘는 시간이 걸립니다.
에디터를 도입한다면 어떻게 달라질까요?
5–2. 기대 효과
에디터를 도입한다면 프로모션을 제작하는 인원을 제외하고는 특별히 업무 리소스를 투입할 일이 없습니다. 추가로, 인원이 적어지는 만큼 소통 비용도 발생하지 않습니다.
3~5일 걸리던 프로모션 제작 기간은 몇 분~몇 시간 수준으로 줄어들고, 수정하는 기간 또한 마찬가지로 대폭 줄어들 것입니다.
그리고 많은 사람들이 남는 리소스를 활용해서 캐치테이블 서비스의 발전을 위해 더 많은 일을 할 수 있습니다.
5–3. 제안 결과
이런 상황과 기대 효과를 토대로 리드님께 제안을 드렸고, 아래의 전제 조건을 기반으로 약 2주간 PoC(특정 방식이나 아이디어를 실현하여 타당성을 증명하는 것) 및 개발을 해볼 수 있는 기회를 얻게 되었습니다.
- 다른 사람의 리소스를 투입하지 않는다
- 기존 업무를 모두 끝내고 남는 시간에 PoC 및 개발을 진행한다
이제 제가 생각했던 것들을 증명할 시간입니다!
6. 빠른 PoC
PoC 단계에서는 핵심적인 것을 중심으로 빠르게 확인해보기로 했습니다.
블록들의 조합 정보(이하 메타 정보)를 문제 없이 UI로 그릴 수 있는가?
일단 최소 단위로의 테스트를 위해 에디터가 있다고 가정하고 에디터가 생성할 형태로 메타 정보만 구성해보았습니다. 이걸로 프론트엔드에서 변환해 페이지를 문제 없이 보여준다면 PoC는 끝입니다.
가장 먼저 블록이라는 단위의 개념을 구체화했습니다.
먼저 블록은 유형과 스타일을 가집니다.
유형은 이 블록이 무엇을 할 수 있는 지를 알려줍니다. (예: 이미지 블록이면 이미지 삽입 가능)
스타일은 이 블록이 어떤 UI로 보이는 지를 지정할 수 있습니다. 블록의 유형 별로 지정할 수 있는 스타일은 조금씩 다릅니다.
- 부모 유형의 블록은 다른 블록을 하위 블록으로 가질 수 있습니다. 이는 레고 블록처럼 조합되기 위한 필수적인 기능입니다.
부모 블록은 클릭했을 때 액션을 수행할 수도 있습니다. (액션이란 페이지 이동, 페이지 공유 등 사용자의 클릭에 특정 행동을 하는 것을 말합니다.)
자식 유형의 블록은 그 무엇도 수행할 수 없지만, 자신이 보여줄 콘텐츠를 가질 수 있습니다.
PoC 단계에서는 블록을 핵심적인 세 가지만 가정했습니다.
액션도 페이지 이동 하나만 가정했습니다.
- 부모 유형의 블록인 그룹 블록.
- 자식 유형의 블록이자 콘텐츠로 이미지URL을 가지는 이미지 블록.
- 자식 유형의 블록이자 콘텐츠로 텍스트를 가지는 텍스트 블록.
해당 블록들의 조합으로 메타 정보를 구성해보았습니다.
결과는 성공적이었습니다.
성능 문제도 없었고, 로딩이나 페이지 전환 간에 스크롤을 기억하는 로직이 추가되긴 했지만 문제되는 부분 없이 페이지를 그려냈습니다.
‘기본 액션(페이지 이동, 공유 등)을 수행할 수 있는 웹 페이지는 당장 에디터로 만들어 낼 수 있겠다.’는 확신이 들었습니다.
7. 에디터 개발
이제 에디터를 만들어볼 차례입니다.
에디터가 무한한 수정도 개발 없이 대응할 수 있게 해주기를 기대해봅시다!
다만, 대부분의 개발 과정이 기술적인 이야기라 이 글에서는 구현 과정에서의 제 의도를 표현하는 것으로 짧게 설명하겠습니다.
에디터는 도구상자, 레이어, 뷰어, 인스펙터로 구성했습니다.
- 도구상자: 페이지를 구성할 블록들을 볼 수 있는 곳
- 레이어: 페이지를 구성하고 있는 블록들의 조합 형태를 볼 수 있는 곳
- 뷰어: 완성된 화면이 앱에서 어떻게 보일지 보여주는 곳
- 인스펙터: 블록을 커스터마이즈할 수 있는 곳
그리고 페이지를 구성할 블록을 정의했습니다. 스타일, 사용자 상호작용 등의 일부 기능을 커스텀으로 열어두었습니다.
에디터의 블록들을 어떻게 조합하고 커스터마이징 하느냐에 따라 하나의 새로운 웹 페이지가 됩니다.
그리고 에디터 수정의 결과물을 실시간으로 뷰어를 통해 확인함으로써 어떤 형태로 나올지 예상할 수 있게 되었습니다.
완성된 에디터로 만든 페이지를 살펴 보겠습니다.
스크롤을 이동할 수 있는 탭 UI가 있고, 마이페이지로 이동할 수 있는 버튼과 캐치테이블 검색 페이지로 이동할 수 있는 버튼이 있습니다.
페이지가 개발 없이 잘 생성되었습니다!
이제 간단한 수정을 테스트해볼까요? 버튼의 색과 텍스트, 이동할 페이지를 변경해보겠습니다.
이로써, 에디터 개발이 성공적으로 끝났습니다. 메인 과제들을 다 끝내고 저만의 프로젝트에 밤낮으로 몰두하던 시간들이 결과물을 낸 순간입니다!
짧다면 짧고 길다면 긴 2주라는 기간 동안 이 정도면 훌륭한 결과물을 만들어낸 것 같아 내심 뿌듯했던 기억이 납니다.
8. 에디터는 무엇을 해냈나
이 글을 작성하는 시점으로 다시 돌아와서, 위에서 이야기했던 기대 효과를 에디터를 충분히 냈는지 살펴보겠습니다.
제가 입사한 이후 약 6개월 동안 제가 제작한 프로모션은 10개였습니다. 이 과정에는 QA, 백엔드 & 프론트엔드 개발자, PM, 마케터, 디자이너 등 많은 인력의 업무 리소스가 투입되었고, 소통 비용도 발생했습니다.
게다가 프로모션 제작 기간은 개발 기간만 따져도 보통 3~5일입니다. QA기간과 디테일한 수정을 하는 기간을 더한다면 보통 2주가 넘는 시간이 걸립니다.
에디터 도입 후는 어떨까요?
에디터 도입 후 약 7개월 동안 개발자 없이 제작한 프로모션은 약 60~70개에 달합니다. 원한다면, 얼마든지 더 제작할 수도 있습니다.
에디터를 사용하면 프로모션 요청 측의 리소스만 필요하고, 특별한 경우를 제외하면 다른 인력의 업무 리소스가 필요 없습니다.
더불어 프로모션 제작 기간이 3~5일에서 몇 분~몇 시간 단위로 크게 단축되었습니다. 에디터로 제작한 프로모션은 수정도 간단하고, QA도 대부분 진행하지 않으니 실질적인 개선 정도는 더 높습니다.
돌이켜보니 에디터가 정말 많은 일을 해내고 있다는 것을 새삼 실감합니다.
여기서 잠깐!
과연 에디터는 시작부터 순조롭게 프로모션 페이지들을 잘 만들어냈을까요? 시행착오는 없었을까요?
이번 글은 여기서 마치고, 다음 글에서 에디터를 이용한 첫 프로모션과 시행착오부터 이어나가도록 하겠습니다.
긴 글 읽어주셔서 감사드리며, 2편으로 찾아오겠습니다!
