기술과 저널리즘

뉴욕타임스 텍스트 에디터 ‘Oak’와 데스킹 편의

에디터 소프트웨어 하나만 변경하더라도 기자의 업무 효율을 상당 수준 향상

이성규 2019년 05월 09일

CMS에서 에디터의 역할을 특별합니다. 어쩌면 가장 중요하다고 할 수 있을 겁니다. 매일매일 기사를 작성해야 하는 기자들은 거의 하루 종일 에디터와 씨름하곤 합니다. 때문에 에디터는 기사 작성과 데스킹의 효율성을 높이는데 결정적 기여를 할 수밖에 없습니다.

에디터가 차지하는 위상에 비해 이 기술은 의외로 조명을 덜 받습니다. 기사를 입력하는 윈도 혹은 이미지나 영상을 가져다 붙이는 창 정도로만 인식되곤 합니다. 하지만 에디터 소프트웨어의 간단한 개선만으로도 기사 작성의 효율이 상당 수준 높아질 수 있다는 사실을 간과합니다. 기자와 데스크 간의 커뮤니케이션 관계까지도 제어할 수 있다는 점은 종종 잊어버리곤 하죠. 뉴욕타임스의 사례를 통해서 이것이 지닌 잠재성을 확인해보도록 하겠습니다.

뉴욕타임스 에디터 소프트웨어의 역사

뉴욕타임스 에디터 소프트웨어 ‘Oak’

‘Oak’는 뉴욕타임스가 그들의 CMS에 적용한 에디터 소프트웨어에 붙인 이름입니다. 기존 에디터를 대체해 운영해오고 있다고 합니다. 언제 1차 개발이 완료됐는지는 정확히 확인하기는 어렵습니다. 2012년에도 훌륭한 에디터를 보유하고 있었던 것으로 알고 있는데, 그것이 Oak였는지는 기억이 나질 않습니다.

문제와 목표 : Oak는 구글 닥스의 훌륭한 기능들과 미디엄의 직관적인 UI, 뉴스룸 워크플로우에 최적화한 고유 기능을 담아내기 위해 개발이 시작됐습니다. 기존 에디터는 텍스트와 이미지, 카피에디팅, 소셜미디어 등이 서로 분리돼 탭 형태로 구성돼 있다 보니, 관리의 효율성이 떨어졌다고 합니다. 기존 에디터로 기사를 작성하려면 여러 탭을 오가며 시간을 소비해야 하는 비직관적 구조를 갖고 있었다는군요.

이를 해결하기 위해 뉴욕타임스는 2가지 목표를 세웁니다. 첫 번째는 기자와 에디터가 웹이 기사를 발행하기 전에 정확히 어떤 형태로 게시되는지 확인할 수 있도록 하는 것, 두 번째는 코드 실행의 복잡성을 제거해 유연성을 갖도록 개발한다였습니다.

image

어떻게 해결했는가 : 여러 고민 끝에 ‘Oak’는 Prosemirror라는 오픈소스 소프트웨어(리치 텍스트 에디터)로 구축하기로 했습니다. 이유는 Prosemirror는 구조가 기존 방식과 달리 잘 구조화돼 있어서입니다. 기존 에디터와 달리 Prosemirror는 DOM 트리, 마크다운 텍스트 구조로 문서를 렌더링합니다. 다소 어렵죠? 물론 제게도 어렵습니다.

DOM은 Document Object Model의 약자입니다. 풀어쓰면 문서 객체 모델입니다. 문서 객체 모델은 웹브라우저가 문서를 인식하는 방식과 관련이 돼 있습니다. DOM의 구조를 보고 웹브라우저가 표현을 한다는 것이죠.

Prosemirror는 기사 내에 포함된 이 문서의 요소들을 노드로 구조화합니다. 예를 들어, 기사에는 제목, 부제목, 요약문, 바이라인, 발행일자 및 시간, 사진과 같은 부가 미디어, 본문 등이 포함돼 있는데요. 이를 모두 개별 노드로 인식해 처리한다는 것이죠. 노드의 관계로 설명하면 기사는 부모 노드, 제목, 부제목 등은 자식 노드가 됩니다. 이렇게 트리 구조로 짜여진 것이 DOM의 구조라고 할 수 있습니다.

그런데 Prosemirror의 특이한 점은 통상 노드는 위계적 구조로 구축돼 있는데 반해, 문단 노드만큼은 직렬 노드로 처리한다는 겁니다. 문단 내 문장이 개별 노드로 존재함으로써 그 자체의 속성이 위로부터 상속되지 않고 그 자체로 살아서 존재한다는 것이죠.

이게 왜 중요하냐면, 개별 노드들이 자체 속성을 가진 채로 검색되거나 제어될 수 있다는 겁니다. 예를 들어 “나는 미디어고토사 주인장이다.”라는 문장이 있다고 가정해볼게요. ‘주인장이다’라는 어절은 에디터에서 볼드에 이탤릭, 밑줄 등의 속성을 동시에 가질 수 있습니다. 예전에 DOM 구조 문장 단위로 속성이 정의돼 분류가 됐다면, Prosemirror는 개별 어절을 노드로 처리함으로써 귀속된 문장의 속성을 물려받지 않고 그 자체로 속성이 정의될 수 있다는 거죠. 이렇게 되면 “볼드와 밑줄 된 어절을 찾아줘”라는 검색 쿼리에 정확한 응답이 가능해지고, CMS도 이러한 값을 지닌 노드를 쉽게 찾아낼 수가 있습니다.

이 구조가 사진과 영상 노드에 적용이 된다면 훨씬더 편리해질 수 있겠죠. 이 사진과 비디오 노드들에 고유ID를 부여한 뒤에 특정 속성이 입혀졌다면 특정 속성을 지닌 사진을 불러올 때 훨씬 정확한 값을 반환할 수 있게 되는 겁니다.

여기에 mark라는 정의도 활용할 수 있습니다. 특정 스타일 속성을 정의하는 기능이라고 할까요. 또 예를 들어야겠죠. 소제목에는 하이퍼링크를 허용하지만, 대제목에는 하이퍼링크를 허용하지 않고 싶다고 할 때, 어떻게 해야 할까요? 이때 mark를 통해서 특정 노드의 속성 허용 범위를 제한하거나 허용할 수 있다는 겁니다. 개별 요소들을 노드로 인식하고, 그 노드를 개별적으로 통제할 수 있는 구조를 가졌기 때문에 가능해지는 겁니다.

물론 그럴리는 없겠지만, 기사 전체를 하나의 노드로 인식하고 있다면 이런 기능은 구현이 불가능해지죠. 문장 단위, 어절 단위까지도 노드로 인식하기 때문에 구현해낼 수 있는 기능들입니다.

image

무엇이 개선됐을까 : 뉴욕타임스가 자랑하는 건 3가지 기능입니다. 하나하나 살펴보죠.

  • 수정 추적(Track Change) 기능 : 기자가 기사를 작성해 데스크에 보내면, 데스크나 편집부에선 제목부터 본문까지 여러 부분을 수정하게 됩니다. 하지만 무엇이 수정됐는지 확인하기 어렵죠. 적어도 국내 언론사 사용하고 있는 에디터 가운데 이 기능까지 지원하는 경우는 그리 많지 않았던 걸로 기억합니다. 데스크가 추가한 문장, 단어, 어절은 녹색으로, 삭제한 문장, 어절, 단어는 적색으로 표시됩니다. 당연히 수정 전 문서로 되돌릴 수 있고, 수정 후 문서로 복원할 수도 있습니다. 이것은 위에서 말씀드렸다시피 개별 요소들을 노드로 분류함으로써 가능해진 기능입니다. 여기에 추가하자면, Prosemirror는 첫 기사가 완료된 A상태에 수정이 가해지면(new step object가 발생하면) A상태를 대체하지 않고 B상태 문서를 생성합니다. 그리고 버전 히스토리로 남기게 됩니다. 이런 구조들이 결합되면서 수정 추적 기능이 가능해진 것이죠.

  • 맞춤형 헤더 : Oak는 제목 유형을 3가지로 변형할 수 있습니다. 기본 제목 유형, 가로 전면 이미지 제목 유형, 세로 전면 이미지 제목 유형. 실제 사례를 보시면 쉽게 이해가 갈 겁니다. 제목을 어떻게 구성할 것인가를 에디터 단에서 제어할 수 있습니다. 이 또한 제목과 이미지, 바이라인, 요약문 등이 노드로서 인식될 수 있었기 때문에 구현이 가능해진 겁니다.

  • 에디터 내 댓글 : 이런 상황은 자주 있을 겁니다. 기자가 기사를 써서 제출하면 데스크가 “이 문장이 어떤 의미야? 내용 좀 보충해봐”라고 지시를 하죠. 그럴 때마다 해당 문장의 위치를 찾아서 확인하고 전화로 재보고를 하는 과정을 거쳐야 합니다. 혹은 메신저로 그것을 대신하죠. 에디터 내 댓글은 이 문제를 해결해줍니다.

기사 에디터 안에서 특정 문장에 댓글을 게시하면 에디터 우측에 주석처럼 메모장이 붙게 됩니다. 구글 닥스의 댓글 기능을 떠올리시면 될 겁니다. 주석 메모장을 시뮬레이션 한 케이스라고 볼 수 있을 겁니다. 이를 통해 기자와 데스크/편집부 간의 커뮤니케이션의 명확성을 확보할 수가 있습니다. 이 또한 mark로 통제돼 특정 속성을 갖거나 제한할 수 있도록 했다고 합니다.

에디터 소프트웨어와 국내 뉴스룸의 접근 방식

우리가 배워야 할 점 : 기자협회보 최근 기사에 이런 문장이 쓰여있더군요. “기자들이 해당 CMS에서 느끼는 불편함은 종종 시스템이 먹통 되거나 따옴표 등의 약물이 지면편집시스템에는 연동되지 않고, 사진설명칸에선 약물을 인식조차 못하는 것 등이다.”

왜 이런 결과가 발생할까요? 어떤 문제를 해결하기 어떤 목표를 설정하고 무엇을 바꾸어야 하는가에 대한 철저한 조사와 고민이 부족했기 때문이라고 생각합니다. 무엇을 해결하기 위한 CMS인가, 그 CMS 안에서 에디터의 역할을 무엇이고, 에디터에 대해 누적된 불편사항(Pain Point)가 무엇이었나에 대한 사전 조사가 부족했다는 의미입니다. 린/애자일 소프트웨어 개발 방법론을 무시한 채로 개발 프로세스를 진행했다는 이야기이기도 합니다. 외주 개발 시 흔하게 나타나는 결과이기도 합니다.

소프트웨어는 이미 언론의 일상 속으로 깊숙하게 파고 들었습니다. 하지만 그 소프트웨어가 기자 자신의 어떤 업무 영역을 제어히고 제한하는지는 관심을 두지 않습니다. 이미 업무의 파트너로서 자리잡은 저작/편집 소프트웨어지만 그것의 위상과 역할에 걸맞는 대접을 받고 있지 못하다는 것이죠.

에디터 하나만 변경하더라도 기자의 업무 효율을 상당 수준 향상될 수 있습니다. 편집부의 역할을 덜어낼 수도 있고 커뮤니케이션 구조도 변형할 수 있습니다. 허드렛일을 줄여 저널리즘 자체에 집중할 여유를 확보할 수도 있죠.