배민 신춘문예 개발기

Mar.20.2017 조은

Web Frontend

배민 신춘문예 개발기

인생은 멀리서 보면 희극이고 가까이서 보면 비극이다.
~ Charlie Chaplin

배민신춘문예는 매년 이맘때 진행하는 이벤트로 그 해 마케팅실의 염원을 담아 대규모로 진행하는 이벤트이다. 보통 우리 회사에서는 이벤트를 마케팅실에서 직접 정해진 템플릿을 이용해 구현하나 신춘문예같은 복잡한 형태의 이벤트는 팀(웹UI개발팀)에서 작업해주는 케이스가 있다.

배민 신춘문예 사이트: http://spring.baemin.com

애자일 아닌 애자일

이번 프로젝트는 회사에서 새로 도전하는 스펙이었기 때문에 초기 기획단계에서 디자이너 & 개발자(나) & 기획자가 함께 모여서 프로젝트를 진행했는데, 처음으로 시도해 보는 거라서 많은 연구와 구현가능성에 대한 이슈를 가질 수밖에 없었다.

프로젝트를 진행하면서 최초에 만든 프로토타입은 http://codepen.io/ChoEun/pen/YNmGwNhttp://codepen.io/ChoEun/pen/LxMdwX 같이 기획에서 의도하는 다양한 기능이 구현 가능한가에 대한 연구를 위해 구현하였으며, 이를 실제 서비스에 적용하지는 않았으나 마케팅실과 디자인실에서 해당 프로토타입을 보며 어떤 기능이 구현 가능할 지 불가할 지 여부를 체크하여 기능을 정의하고 디자인하였기 때문에 작업을 하면서 매끄럽게 진행할 수 있었다고 생각한다.

이번 프로젝트에서 프로토타이핑을 통해 얻을 수 있던 인사이트가 크게 세가지 있었는데,

  1. 기능을 명확히 하고 이 기능을 어느정도까지 사용 가능한가에 대한 고민
  2. 기획에서 의도한 내용이 이게 맞는가에 대한 사전 확인 작업. (삽질을 줄일 수 있었다)
  3. 적정 기술에 대한 고민. 무엇보다 수정기능은 라이브러리의 기본 제공 기능을 사용했다.

특히 처음 기능을 구현할 때 ‘이게 가능할까?’라는 생각을 했지만 프로토타입을 구현해나가는 과정에서 가능할 거란 생각이 들기 시작했고 그를 바탕으로 올해 배민신춘문예를 캔버스 방식으로 구현하게 되었다.

하지만 프로토타입이 아닌 실제 제품을 구현하기 시작하면서 애초에 의도한 것과 달리, 사용자 흐름을 다시 정리해야할 필요가 있었는데 구현 가능한 범주에서 최상의 사용성을 제공하기 위해서 수정해야하는 것이 많았다.

Figure 1. 디자이너가 보면 죽는 짤

우리가 이번 작업을 진행해나가면서 겪게 된 것 중 긍정적으로 평가하는 혹은 가치있는 시간이라고 생각하는 것 중 대표적인 건, 서로 이야기를 해나가면서 문제를 해결해나갔다는 점이라 생각한다. 서로 특정한 지점에서 문제를 발견했을 때 주저 않고 공유하여 문제를 해결해나가는 데 가장 많은 힘을 쏟았고 그를 통해 문제를 빨리 수정하여 다음 단계를 밟을 수 있도록 한 게 이번 프로젝트의 가장 큰 성과라 생각한다.

Figure 2. 프로젝트가 끝나갈 때

다만 이 프로젝트가 비교적 짧은 시간동안 진행되었고 많은 수정은 곧 많은 작업을 의미했기 때문에 좋은 제품을 만들어 나가기 위해 짧고 굵게 고통받았다. 이 포인트에서 우리가 겪었던 걸 반드시 좋은 경험이라 부를 수는 없겠지만, 좋은 제품을 만들기 위한 공통의 목표에서 서로가 각자의 영역에서 맡은 바 최선을 다했다고 생각하고 있다.

물론 코드 품질 등에서는 많은 아쉬움을 가지고 있지만, 이 내용을 바탕으로 더 나은 무언가를 만들 수 있을 수 있지 않을까 생각하고 있다.

Figure 3. 이미지 정렬 문제가 해소되었을 때

기술에 대한 고민

우리가 정리했던 초기 스펙은

  1. 유저가 시(최대 20자)와 작가명(최대 10자)을 입력한다
  2. 특정한 형태의 이미지를 만들고 배경을 선택할 수 있게 한다
  3. 배경은 미리 정해진 이미지와 유저가 선택한 이미지를 선택할 수 있다
  4. 이미지를 저장하여 페이스북 or 카카오톡 or 인스타그램에 공유한다

이 스펙에서 주된 키워드는 이미지를 만들고 배경을 선택하여 저장하여 공유한다 였는데, 이런 형태의 UI를 구현하는 데에 Canvas가 적합하다고 생각하여 처음에는 HTML5 Canvas API를 기본 형태로 사용하여 구현하고자 하였으나 프로토타이핑을 거친 후 이런 형태가 적합하지 않다고 생각하였고, 사용 가능한 유용한 라이브러리를 찾던 중 Fabric.js를 채택하였다.

Fabric.js는 오픈소스 캔버스 라이브러리로 각 객체의 크기 변형, 패턴 지정, 배경 지정 등 이번 프로젝트에서 필요로 하는 모든 기능을 제공해주고 있어서 개별 이슈에 하나하나 고민을 하는 게 아닌 로직에서만 고민할 수 있게 해주어 구현하는 데 이슈가 덜하게 만들어주었다.

구현을 하며 겪었던 몇가지 이슈 중 굵직한 것들만 몇가지 살펴보자면.

Q. 한나체를 적용해야하는데 canvas에 폰트를 삽입하는 순간 서버에서 한나체를 다운로드 받기 시작하여 한나체가 적용되려면 캔버스를 한번 유저가 강제로 클릭해줘야 했던 이슈

A. 최초에 캔버스를 초기화할 때 빈 텍스트객체를 사전에 넣어 한나체로 지정해두었다. 이렇게 하여 페이지에 접근하여 캔버스를 초기화하는 단계에서 한나체를 서버에서 불러오고, 유저가 실제로 시를 입력하여 반영하는 단계에서 한나체가 제대로 적용될 수 있었다.

Q. 사용자가 지정한 이미지를 넣을 경우 이미지가 정사각형인지, 직사각형인 지 구분할 수 없었고 크기가 다양했기 때문에, 우선 캔버스 크기에 우겨넣었더니 이미지가 깨지는 효과가 나타났다.

A. 이미지를 받고 난 후 중앙정렬을 시켜주도록 로직을 다시 설계했고, 이미지 자체를 변형하는 게 아닌 스케일을 조정하여 이미지가 확대되거나 축소되도록 설계했다.

Q. 페이스북 공유하기를 og_shares라는 걸로 구현했는데 현재 API 버전에서는 더이상 사용하지 않아 페이스북 공유하기가 팝업까지는 뜨나 실제 공유하기로 넘어가지 않았다

A. 페이스북 공유하기는 더 상세히 살펴보니 feed_dialog라는 게 있어 그걸로 구현하였다. 페이스북 공유하기라는 버튼의 텍스트에 너무 집착하여 share_dialog만 생각하고 있었다. 만약 이미지가 수정되는 형태의 공유하기라면 feed_dialog 사용을 검토해보자.

끝으로

배민신춘문예는 내가 처음 기대했던 것 이상으로 어려운 작업이었고, 또 성공한 작업이라고 생각한다. 함께 작업해준 멤버들에게 고맙다는 인사를 꼭 전하고 싶고, 내년에는 내가 안할거다.

Figure 4. 함께해서 즐거웠고 다시 만나지 맙시다