[저널리즘의 미래 25] 가디언이 파이어스톰(Firestorm)을 만들며 얻은 10가지 교훈

firestorm guardian

이 글을 읽기 전에

1. 이 글은 개발자의 생생한 호흡을 그대로 담고 있으며 여러 가지 통찰과 고민을 준다.
2. 얼마 전 하버드대의 미디어 관련 포럼에 참석한 뉴욕타임즈 사주는 엔지니어의 중요성에 대한 인식 부족을 스스로 지적했다고 한다.
3. 통합뉴스룸은 종이신문 기자와 인터넷뉴스 기자를 넘어 디자이너로 개발자로 협력의 범위를 넓히고 있다.
4. 결국 플랫폼이다. 청중과 어떻게, 무엇으로 연결될 것인가이다.
5. 개발자는 물론 기자와 CEO가 봐야 하는 글이다.

0. 기술 진보에 따라, 미디어 환경은 급속도로 변화하고 있다. 다양한 실험들이 시도되고 있고 기성 언론도 이 흐름에 발 맞추고 있다. 뉴욕타임즈의 스노우폴(Snowfall), 가디언의 파이어스톰(Firestorm) 등 ‘인터렉티브 저널리즘’의 탄생이 대표적이다. 이는 저널리스트 – 개발자 협업 또는 저널리스트의 기술적 역량 강화를 요구하며, 앞으로 더욱 심화될 것이다. 이런 시기, 가디언의 ‘개발자 블로그(Developer Blog)’는 참고할 만한 공간이다. 이곳에 파이어스톰의 개발자였던 조나단 리차즈(Jonathan Richards)가 3개월 간 기자, 웹디자이너, 개발자, 그리고 영국과 호주 양국의 5개 편집데스크들이 함께 한, 파이어스톰 프로젝트에서 얻은 교훈을 10가지로 정리해 게재했다. 이를 전문(全文) 번역해 소개한다.

1. 자산이 당신을 위협하지 못하게 하라

파이어스톰은 6개 챕터를 넘나들며 25개 장면을 구현하는 리치 미디어(Rich Media)이다. 여기엔 관리되어야 할 많은 자산들이 있었다. 이들은 기사, 비디어, 사진, 그래픽 등 다양한 형태를 가졌고 웹에서 압축, 인코딩 등 다양한 테스트를 거쳤다. 그리고 멀티미디어 팀, 사진부 데스크, 작가들, 개발자들에게 소스로 사용되었다. 이 모든 일들이 처리되는 과정은 매우 복잡했고, 우리는 관련 업무절차를 간소화하는데 많은 시간을 들여야 했다. 그 결과 업무절차는 이해하기 쉽게 바뀌었고 안정화 되었다.

우리는 개발 과정에서 업무 절차가 특정인 및 특정 프로세스에 의존하고 있다는 사실을 꽤나 늦게 깨달았다. 해당 특정인들이 부재 시 혹은 프로세스가 무너졌을 때, 심각한 문제를 가질 수 밖에 없었다. 이런 사실들을 사전에 인식하고 대비하는 건 중요하다.

2. 웹 상에서 비디오를 구동하는 건 어려운 일이다.

파이어스톰이 구버전의 브라우저들을 지원하지 않기로 결정한 것은 다행스런 일이었다. 하지만, 우린 HTML5 비디오를 브라우저와 플랫폼을 넘나들며 안정적으로 구현하는 데 어려움을 겪었다. 당신은 다양한 동영상 인코딩들을(mp4, webm, ogg등 – 브라우저를 넘나들며 작업하는데 필요한 것들) 창조 혹은 재창조하는데 적합한 업무 프로세스를 가지고 있는 지 확인해야 한다. 또한 대역폭(bandwidth)에도 관심을 기울여야 한다. 우리가 다양한 지역에서 수행한 시험들은 호주 등 몇몇 지역에서 1Mbps에 그치는 속도 밖에 기대할 수 없다는 것을 드러냈다. (참고: 2013년 한국 광랜 유선 인터넷 속도 – 100Mbps) 우리는 각각의 인코딩에 맞는 세 가지 다른 유형의 해법을 만들어냈다. 그 결과 각 비디오 당 총 9개의 버전이 탄생했다. 아울러 우리는 특정 고객에게 어떤 방법이 최적인지 결정하는 커스텀(custom), JS기반, 대역폭 검색테스트를 만들었다.

종합하자면, 이상 요인들을 제거할 수 있는 서로 다른 구동 체계를 준비해야 한다는 것이다. 참고로 애플의 운영체제인 iOS에선 특히 자동재생 배경 미디어(auto-playing background media) 구동에 어려움이 있다.

3. 기꺼이 특색을 버려라 (그리고 ‘No’라고 말하라)

‘만약 –라면 대단하지 않을까?’ 등의 대화를 하는 것은 쉬운 일이다. 반면 당신이 ‘많은 특징들을 가지는 인터렉티브(Intercative) 체계를 구현할 때, 중요한 몇몇 특색이 구현되지 않는 것은 흔한 일이다. 서비스 시작 2-3주 전 인터렉티브 초기 버전이 구동되기 시작했을 때, 우리는 매일 오전 10시에 피드백을 평가하고 새로운 요청들을 검토하기 위한 회의를 가졌다. 그런 요청들에 대해 합리적이면서 확고한 태도를 갖는 것은 중요하다. 물론 에디터들은 더 많은 걸 요구하기 마련이다. 하지만 단언컨대 더 중요하면서도 까다로운 기술은 그런 요구들은 어떻게 제거하는 지를 아는 것이다. 이 맥락에서, 개발자는 지속적으로 에디터가 원하는 바와 주어진 프레임 안의 ‘현실적인 부분’ 사이에서 균형을 잡아야 한다. 당신이 창조적인 비전에 이를 수 있는 특징들을 확실히 하라. 하지만, 이는 적절히 구동되어야 하고 테스트되어야 한다는 점을 명심하라.

4. 프로토타입(prototype)의 한계를 인식하라

프로토타입은 프로젝트 초기 단계에서 테스트를 하고, 서로 간 비전을 공유하는 데 훌륭한 수단이다. 하지만, 이를 추후 편집을 위한 예측의 소스로 활용하는 데 있어선 주의를 기울여야 한다. 우리는 프로젝트 초기 8~10개의 다양한 프로토타입을 개발했다. 하지만 지나고 나서 보니, 그렇게나 많이 필요하진 않았다. 그것들은 에디터와 비전을 공유할 수 있는 유용한 수단이지만, 실제 데이터 산출 시 덜 중요한 것으로 판명될 면들로 인해 혼란을 초래할 수 있다. 초기 개발 업무는 우리 자산들을 위한 적절한 업무 프로세스를 만드는 데 초점을 맞출 수 있었다. 하지만 이는 성가인 일들이 되곤 했다.

5. 기존의 디자인을 깨기 위해 노력하라

파이어스톰은 선형 경험(linear experience)이고, 디자인의 주요 포인트는 사용자들이 어떻게 하면 각 장면을 쉽게 이동할 수 있게 하느냐이다. 우리는 이것을 어드밴스 메커닉(Advance mechanic)이라고 부른다. 우리는 많은 대안들을 시도한 뒤, 결국 사용자들이 챕터 안의 장면들을 스크롤하며 진행하는 접근법을 확정했다. 하지만, 여전히 해결해야 할 많은 문제들이 있었다. 어떻게 사용자들은 신속하게 다음 장면으로 넘어갈 수 있을까? 장면들 사이뿐 아니라, 한 장면 안에서 스크롤 하는 것도 가능한가? 장면 전환 과정에서 끊김 현상은 없는가? 전환은 미디어의 종류에 따라 다르게 느껴지는가? 디자인이 탄생했을 때, 우리는 가능한 모든 ‘장면들의 전개, 배치 방식’을 시뮬레이션 하는 것이 유용한 방법임을 깨달았다. 그리고 계속해서 질문을 던졌다. 디자인이 깨지는가? 언제나 직관적인 방법으로 발전해 나가는 것이 가능한가? 개발 초기, 우리의 디자인은 항상 문제점을 노출하곤 했다. 예를 들어, 원래 화면 전환 버튼(Advance prompt)은 화면 하단에 이를 때만 나타났다. 하지만 이는 A-roll 비디오 같은 스크롤이 없는 장면 유형에서 문제점을 노출했다. 우린 결국 모든 미디어 유형과 연속된 장면들을 문제 없이 재생할 수 있는 지속 가능 디자인을 만들어냈다.

6. 함께 앉아라

물리적 근접의 중요성은 간과되기 쉽다. 우리는 꽤나 큰 규모의 프로젝트 팀을 꾸렸다. 팀은 디자이너, 두 명의 에디터, 두 명의 멀티미디어 제작자, 작가, 몇 명의 개발자들로 구성되었다. 우리는 대부분 함께 모여 앉았다. 그러나 멀티미디어 팀은 분리된 스튜디오에 있었고 그들과 좀 더 가까이 있었다면 훨씬 더 좋았을 것이다. ‘함께 있는’ 팀의 좋은 점은 무엇일까? 뭔가를 새롭게 시도할 때나, 피드백을 얻을 때나, 개선할 때 ‘변함 없는 청중’이 있다는 점이다. 이는 몇 번이고 다시 반복되는 순환 공식이었고, 많은 성공적 작품들의 핵심 요인이다.

7. 사용자 테스트 세션에 에디터를 데려와라

이는 특별한 시간이며, 상호간 권한 위임을 할 수 있는 기회이다.

8. 단일 편집 책임자를 두어라

에디터들은 바쁜 사람들이다. 또한 그들은 자주 자신의 생각을 바꾸곤 한다. 프로젝트가 에디터가 별도로 존재하는 복수의 파트에 걸쳐 있을 때, 서로 다른 방향들로 일이 진행되기 쉽다. 단일 프로젝트에 단일 편집 포인트를 선정하는 것은 무척 유용한 일이다. 다른 파트로부터 피드백을 얻을 수 있지만, 단일 결정권자만이 궁극적으로 결정을 내리고 프로젝트 방향을 승인해야 한다.

9. 내부 시스템에 함몰되지 말아라

가디언도 다른 조직들처럼, 외부 공격으로부터 내부 네트워크를 보호하기 위한 ‘방어 체계’가 있다. 이 방어 체계는 예상치 못한 결과를 초래했다. 내부 네트워크의 기계들, 미디어 재생을 위한 브라우저 능력에 대한 믿음이 약화되었다는 점이다. 이는 문제 발생 시, 수정의 어려움을 수반했다.

어느 날 우리는 유용한 제안을 받았다. “작업을 위해 동네 스타벅스에 가서, 와이파이를 사용해 볼 생각을 해 보았느냐?” 이 시점에서 우리는 우리가 문제에 빠졌음을 실감했다. 항상 당신의 예상 밖, 장애물들을 극복할 수 있도록 준비하라.

10. 사운드도 웹디자인의 일부임을 생각하라

배경을 구성하는 것은 텍스트, 이미지, 최근엔 인터렉티브한 레이아웃들로서 생각되며, 디자인의 핵심 요소로 여겨진다. 우리의 리포팅팀이 호주 태즈매이니아섬에서 돌아온 직후, 우리는 한 가지 사실을 깨달았다. 만약 어떤 것이 분위기 있게 잘 전달되었다면 ‘사운드’가 큰 역할을 했다는 점이었다. 우리는 운 좋게도 편집인 프란 파네타(Fran Panetta)가 라디오 경험이 있었고, 그 결과 ‘음악 파노라마 시리즈’들과 함께할 수 있었다. 하지만, 우리는 더 일찍 협력했어야 했다. 이를 통해, 소리는 촬영의 한 부분으로서 정확히 녹음될 수 있었을 것이다.

결과적으로 우리는 비디오를 영상과 사운드의 요소들로 분리하고, 각 단계들을 공고히 하고, 재생의 순환고리를 만드는 데 많은 시간을 썼다.

이현동

출처: 가디언, 링크

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s