DEVIEW 2015 - 네이버 효과툰은 어떻게 만들어졌나?

처음 떠올린 방식은 비디오형이었다. 만화를 보다 특정 시점에 움직임이 자동 재생되는 방식인데, 곧바로 난제에 부딪혔다. 언제 재생을 시작할지가 애매했다. 화면에 살짝 보일 때 시작하면 뒷부분이 안 보이고, 다 보일 때 시작하면 스크롤을 빠르게 올린 사람에게는 화면 꼭대기에서 갑자기 영상이 도는 꼴이 됐다. 거꾸로 내렸을 때 되감을지, 놓친 연출을 언제 리셋해 다시 돌릴지도 스크롤과 맞지 않았다. 그래서 스크롤을 강제로 제어하는 방식을 시도했다. 모션이 나오면 아무리 올려도 화면이 멈춰 있다가 연출이 끝나야 다시 올라가게 한 것인데, 원하는 시점에 연출을 정확히 전달할 수 있었지만 사용자가 스크롤하고 싶어도 못 하니 할 수 있는 게 없어지는 단점이 컸다. 국내 스크롤 웹툰의 핵심은 보는 속도를 독자가 직접 제어하는 데 있는데, 그 제어권을 빼앗는 순간 몹시 어색해졌다.

절친인 '전설의 주먹' 이종규 작가는 처음부터 안 될 것 같다고 했다. 만화는 애니메이션과 다르다는 것이다. 한때를 풍미한 마시마로 같은 플래시 애니메이션이 결국 코믹 만화를 대체하지 못한 것처럼. '우리는 픽사가 아니다'라는 문장이 프로젝트 전체를 다스리는 원칙이 됐다. 결론은 시간을 제어하는 주체가 사용자라는 웹툰의 본질을 지키는 것이었다. 연출을 그대로 스크롤에 매핑해, 스크롤한 거리가 곧 재생 시간이 되도록 타임라인을 사용자의 스크롤에 넘겨주었다.

저작툴 단계에서 가장 큰 걱정은 작가의 부담이었다. 일주일에 한 편씩 연재하는 것만으로도 마감이 빠듯한데 효과까지 얹으면 압박을 견디기 힘들 거라는 우려가 컸고, 매주 연재가 가능하려면 툴이 정말 쉬워야 했다. 그렇게 만든 웹툰 에디터는 프론트엔드 개발자들이 만들었고, 설치형이면서 나중에는 일반인도 다운로드 없이 웹에서 만들 수 있도록 전적으로 웹 기술만 사용했다. 앵귤러JS와 Node Webkit으로 구현해 빠른 개발 대응과 웹앱으로의 진화, 독자 참여 확장까지 염두에 뒀다. 쉬움의 기준은 '포토샵이 아니라 파워포인트보다 더 쉬워야 한다'였다. 픽셀·퍼센트·포인트 같은 개발자 용어를 일반 용어로 바꾸고, 효과 적용과 미리보기를 쉽게 하고, PSD를 변환 없이 바로 넣을 수 있게 했다. 완성된 에디터를 보고 '우와, 별거 없네'라는 반응이 나오는 것이 곧 목표였다.

뷰어에서는 독자의 시선을 어디서 잡느냐가 관건이었다. 스크롤툰은 모바일에서 화면 하단, PC에서 중간 쪽으로 시선이 떨어지는데, 연출을 이 시선 영역 안에서 보여줘야 했다. 문제는 연출 구간 설계의 어려움이었다. 연출 시간이 길어지면 스크롤을 따라 연출이 위로 올라가 독자가 아래위를 오가야 했고, 너무 짧은 구간에서 연출하면 모든 게 속도감만 남았다. 그 균형을 잡느라 차라리 책장 넘기듯 편한 컷뷰로 가고 싶을 만큼 스크롤 방식이 까다로웠지만, 시선을 제대로 잡기 위한 최적화를 거듭했다.

서비스 단계의 벽은 '한 명의 독자도 놓치지 않겠다'는 목표가 곧 모든 환경 지원을 의미한다는 점이었다. PC 브라우저 버전들, 업데이트 안 된 IE, 안드로이드 갤럭시 단말의 파편화, iOS 7·8, 카카오톡·네이버 앱 등이 쓰는 웹뷰, 그리고 네이버 웹툰 앱까지 전부 대응해야 했다. 저사양 폰에서도 모션을 즐기게 하려고 앱에서는 게임용 라이브러리 코코스 스튜디오(Cocos2d-x 계열)로 네이티브 구현을 해 웹툰 앱 안에 라이브러리로 녹여 넣었다. PC에서는 휠을 돌릴 때마다 화면이 툭툭 끊겨 연출이 끊기는 문제가 있어 가속도를 먹인 자바스크립트 스무드 스크롤 에뮬레이션을 직접 만들었고, 라인 웹툰 같은 글로벌 서비스에서는 동남아의 열악한 환경을 고려해 이미지 용량을 줄였다. 바이러스로 원본을 날린 작가를 위해 효과툰 파일에서 역으로 PSD를 복원하는 툴을 만든 에피소드도 있는데, 그 툴은 지금 번역 서비스에 쓰이고 있다. 이렇게 효과툰은 완전히 스크롤로 모션을 주며 연재하는 '세계 최초의 풀스펙 스크롤 타입 만화 서비스'로 출시됐다.

이어 기술 리드 이현철이 개발자 관점의 내부 이야기를 시작한다. 효과툰을 만든 가장 큰 원칙은 '웹툰의 장르를 벗어나지 않는다'였다. 애니메이션처럼 사실적 묘사를 지향하지 않고 '효과는 내용 전달을 거들 뿐'이라는 팝업북 비유로 절제했다. 대부분의 효과를 스크롤 위치에 매핑해 사용자가 진행률을 직접 컨트롤하게 하되, 흔들기·반짝이기처럼 자동 재생이 자연스러운 효과는 예외로 뒀다. 내부 동작은 뷰어가 실행되면 효과가 정의된 JSON 파일을 먼저 불러오고 이미지·오디오 리소스를 에셋 매니저로 로딩하는데, 알파 블렌딩 때문에 PNG를 쓰다 보니 용량이 3~5배 불려 PNG 압축·레이지 로딩·온디맨드 로딩이 필수였다. 핵심 기능은 스크롤 이벤트로, 현재 활성 페이지에 위치와 방향을 전달하면 페이지 모델이 각 레이어에 진행률을 계산해 넘기고, 시작·종료 값 사이는 선형 보간(linear interpolation)으로 상태 값을 결정한다. 최종 렌더링은 CSS3와 CSS 애니메이션으로 구현하되 DOM 모드와 캔버스 모드를 모두 제공해 환경마다 유리한 방식으로 동작시켰다. 기본 구현의 두 배 정도 시간을 최적화·안정성·호환성에 쏟았다.

타이밍과 구간 최적화에도 공을 들였다. 정지 웹툰과 달리 효과툰은 시선이 효과를 따라 움직여 자칫 피곤해지므로 렌더 라인이라는 연출 기준선을 두어 모든 효과가 그 선에서 시작되게 했고, 가로세로비가 다른 환경에서는 가변적으로 최적의 연출선을 잡았다. 비나 눈처럼 화면에 들어오기 전부터 시작돼 있어야 자연스러운 연출은 시작 타이밍을 앞당겨 보정했다. 연출 구간은 페이지 높이에 비례하기 때문에 짧은 페이지에는 시선 범위를 벗어나지 않는 한도에서 구간을 확장 보정해, 앞뒤 연출이 약간 겹쳐도 속도 변화를 체감하지 않게 했다. iOS 7·8의 UI 웹뷰에서는 연속 스크롤 이벤트가 발생하지 않는 문제를 자바스크립트 에뮬레이션으로 풀었고, 더 까다로운 안드로이드는 같은 제조사 단말 사이에서도 동작이 달라 중요도 낮은 효과를 하나씩 빼거나 스틸컷으로 폴백하고 일부는 캔버스 모드로 성능을 끌어올렸다. 캔버스로 바꾸니 음악·효과음이 안 돼 롤백한 사례도 있었다. 핵심은 '여러 개의 심장을 가진 뷰어'라는 결정이다. 기획자라면 운영 비용을 위해 스펙을 줄였을 수도 있지만, 개발자가 기획에 참여하면서 '한 명의 독자라도 제대로 볼 수 있다면 멋진 기술을 놓치지 말자'는 방향을 택했다. 마지막으로 효과툰이 작가의 노동력을 고려하지 않았다는 타사 인터뷰를 반박하며, 마우스 동선까지 줄여 하일권 작가는 효과 편집에 1시간도 안 걸린다고 답했다는 점을 전하며 발표를 마친다.