네이버 데뷰 2015 노트 - 네이버 효과툰
네이버 데뷰 2015에서 흥미로웠던 세션들 정리
세션 1. 네이버 효과툰은 어떻게 만들어졌나?
발표자: 김효(NAVER), 이현철(NAVER)
슬라이드: http://www.slideshare.net/deview/111-52720751
세션 2. 네이버 효과툰 구현 이야기
발표자: 임대현(NAVER), 김지한(NAVER)
슬라이드: http://www.slideshare.net/deview/121-52734801
세션 1과 세션 2는 이어지는 내용이어서 이 두 세션에 관한 소감을 같이 쓴다.
웹 기술에 대한 선입견
나는 네이버 효과툰이 나왔을 때 처음 보고 선입견을 가졌다.
- 자바스크립트 스크롤 이벤트를 이용해 만들 수 있는, 누구나 할 수 있는 별 것 아닌 기술인데 가장 먼저 웹툰에 도입했다는 이유만으로 필요 이상으로 주목 받고 있다.
- 웹툰 만화 작가들이 자바스크립트를 다룰 수 없을 것이므로 웹툰 한 편 한 편이 올라올 때마다 개발자들이 해야 할 부수작업이 생길 것이다.
오늘날 웹 기술이나 자바스크립트 기술이 결코 만만한 것이 아닌데도 나는 여전히 나도 모르는 새 이것들을 깔보고 있었나하는 생각이 든다. 하지만 이 세션을 통해 내 선입견이 완전히 잘못된 것이었음을 알게 됐다. 결론부터 말하면,
- 네이버 효과툰의 효과는 생각보다 꽤 질이 좋고(웹툰을 잘 보지 않아 몰랐던 부분), 이것이 나오기까지는 나름대로의 철학과 연구가 있었다.
- 네이버 효과툰의 기술은 구현하기가 그렇게 만만한 것이 아니다.
- 물론 웹툰 만화 작가들이 자바스크립트를 다루지는 않는다. 그렇다고 개발자들이 만화 한 편 한 편에 달라붙는 것도 아니다. 개발자들은 만화 작가들이 사용할 수 있는 매우 쉽고 효과적인 저작 도구를 개발해 제공했다. (가장 인상적이었던 부분이다.)
네이버 효과툰을 개발한 팀은 3.5명 정도로 구성됐고, 구상부터 첫 버전을 릴리즈하는데까지 두세달밖에 걸리지 않았다고 한다. 굉장한 기술력, 집행력, 팀워크라고 생각한다.
네이버 효과툰의 철학
연사는 네이버 효과툰을 개발할 때의 마음가짐으로 몇 가지를 얘기했다. 그 중 기억나는 것은 이 세 가지다.
- 네이버 효과툰은 모든 사용자가 즐길 수 있어야 한다.
- 작가들에게 적극적으로 수요 조사를 하고 피드백을 받는다.
- 효과툰은 웹툰이다. (애니메이션이 아니라)
단순한 웹뷰 자바스크립트 프로그래밍이 아니다.
네이버 효과툰 팀은 모든 사용자가 효과툰을 즐기도록 하기 위해 많은 노력을 했다고 한다. 이 한 가지 목표 때문에 많은 기술 이슈가 있었던 모양이다.
- 여전히 매우 다양한(비표준적이고, 낡은) 환경들이 있다.
- 모든 브라우저, 웹뷰가 스크롤 이벤트를 지원하는 것은 아니다.
- PC의 마우스 휠을 이용한 스크롤은 연속적이지 않다.
- 사운드 재생 지원/제약도 제각각이다.
- 효과툰이 “죽어도” 구현되지 않는 환경도 있다.
효과툰 팀은 이 한 가지 목표를 위해 cocos2dx를 통한 네이티브 지원, 다양한 웹뷰 지원, 자바스크립트 해킹 등 온갖 노력을 했다고 한다.
작가들이 쉽게 쓸 수 있는 저작 도구
가장 인상적이었던 것이 저작 도구였다. 나는 멍청해서 작가들이 만화를 업로드할 때마다 개발자들이 자바스크립트를 입힐 줄 알았는데, 네이버 효과툰 팀은 작가들이 쉽게 쓸 수 있는 저작 도구를 만들었다.
저작도구의 레이아웃은 포토샵과 비슷했다. 언뜻 생각하면 애니메이션을 다루는 프로그램이므로 포토샵보다 더 복잡할 것 같다. 그런데 이 도구는 매우 쉬워서 작가들이 웹툰 한 편에 효과를 입히는 데 한 시간도 안 걸린다고 한다.
저작도구의 기능은 효과툰 서비스에 최적화되어 있다고 한다. 불필요한 이미지 제거, 용량, 이미지 사이즈 조절, PSD(포토샵) 파일 파싱/출력, 다국어 지원, 스틸컷 버전 출력 등을 자동화해 놓았다.
매우 어렵고 복잡한 개발 과정이 필요할 것 같지만 발표자들은 웹킷과 여러 라이브러리들을 이용해서 비교적 쉽게 개발한 듯하다.
어떻게 만들었나?
두번째 세션은 네이버 효과툰이 구현된 기술적 내용을 좀 더 자세히 소개했다. 내 자신이 프론트엔드 개발 경험이 많지 않아서 발표된 내용을 많이 흡수할 수는 없었지만 기억나는 것을 남겨 본다.
저작 도구 개발
효과툰 팀이 개발한 제품은 웹툰 뷰어와 저작 도구이며, 이것은 (프론트엔드) 웹 기술로 제작됐다. 웹툰 뷰어는 웹 환경이니 당연히 웹 기술이 필요했겠지만 저작 도구는 다른 방식으로도 만들 수 있었을 텐데도 웹 기술을 채택했다.
웹 기술을 채택한 이유는 무엇일까? 당연히 네이버가 웹 기술을 중심으로 한 회사니까 그렇겠지만… 세션 내용에 따르면 다양한 환경을 지원하기 위한 목적이 컸고 오늘날에는 다양한 라이브러리와 웹킷을 이용해 빠르게 개발해 패키지화하는 것도 가능했기 때문인 듯하다.
특히 Angular.js를 적극 활용해 적은 코드로 빠르게 개발할 수 있었다고 한다. 물론 Angular.js를 쓸 때도 잘못된 구조로 설계하면 코드가 복잡해질 수 있다고 한다. 또, Angular.js 자체의 버그나 잘못된 사용법으로 인해 성능 문제도 발생할 수 있다고 한다. 연사는 이를 피하기 위한 노하우들을 소개했다.
효과툰 저작 도구는 내부적으로 데이터를 저장할 때 JSON 형식으로 저장하며 여기에 각종 이미지 바이너리를 묶어 패키지화한다고 한다.
Undo/Redo 기능은 구현하기가 꽤 어려울 것 같이 생각되는데, 효과툰 팀은 그냥 작업별로 전체 상태를 저장하는 방식으로 간단히 구현했다고 한다.
PSD 파싱 방법도 흥미로웠다. 나 같으면 아마도 라이선스가 걸려 있을 듯해 보이는 PSD 포맷을 파싱하겠다는 생각 자체를 잘 안 하게 됐을 것 같은데, 효과툰 팀은 만화 작가들의 요구에 부응해 PSD 파싱을 시도했다. 그런데 생각보다 간단한 문제였던 모양이다. PSD 파싱 라이브러리가 많이 나와있었기 때문이다.
그 중 자바스크립트용 라이브러리인 psd.js가 좋지만, 자바스크립트 라이브러리는 환경 자체로 인한 메모리 문제가 있어 대용량 파일을 처리할 수 없다고 한다. 효과툰 팀은 그 대신에 Node.js의 자식 프로세스 실행 기능을 이용해 파이썬용 라이브러리인 python psd-tools를 사용했다고 한다.
효과툰을 만들 때 사용한 테스트 자동화 도구에 관해서도 소개됐다. 여러 가지 도구가 소개됐는데 그 가운데 End-to-End 테스트 도구인 Jasmine이 신기했다. 마치 매크로처럼 GUI 도구를 컴퓨터가 자동으로 작동시켜 테스트하는 방식인 것 같다.
뷰어 개발
뷰어 개발에서는 역시 다양한 환경에 동일한 애니메이션/사운드 동작을 지원하도록 하는 것이 가장 큰 문제였던 모양이다. 성능 문제도 있었던 것 같다. 기기별로 상이한 동작에 대해 알려주고 부족한 부분을 어떻게, 어떤 기술로, 어떤 해킹으로 땜빵했는지에 관한 내용이었다. 유용한 노하우일 수는 있지만 나는 이 부분에선 큰 흥미를 느끼진 못했다.
소감
네이버 효과툰 팀은 효과툰을 더 발전시켜 이미지 번역을 통해 다국어 지원을 더 강화하는 기술적 도전을 할 예정이며 플래시의 대체재로서의 모션 플랫폼으로 성장시킬 포부라고 한다.
이 세션에서 훌륭한 개발 철학과 여러 가지 노하우를 접할 수 있었다. 웹 개발이 흥미진진한 이슈가 많은 녹록치 않은 분야라는 것도 새삼 느낄 수 있었고 프론트엔드 개발에도 더 많은 관심을 갖게 될 것 같다.