뉴욕타임스 텍스트 에디터 ‘Oak’와 실시간 동시 편집

[2019년 12월18일]

뉴욕타임스가 풀려고 했던 3가지 문제는 다음과 같습니다.

• 어떻게 실시간 업데이트를 에디터에 통합시킬 것인가
• 각 편집 버전의 충돌을 어떻게 다룰 것인가
• 깜빡깜빡하는 와이파이 상태로 인해 발생하는 에러를 어떻게 다룰 것인가

위 3가지는 실시간 협업 에디팅을 필요로 하는 언론사들에게 무척이나 골치아픈 문제거리입니다. 구글 닥스처럼 실시간 업데이트와 버전 히스토리를 지원하는 툴이 아니라면 해결하기가 쉽지 않는 것들입니다. 뉴욕타임스 개발팀도 고백하고 있듯, 구글처럼 대규모의 인력과 리소스를 투입할 수 없는 개별 언론사의 환경에서 이 문제를 풀어내는 건 간단치 않습니다. 뉴욕타임스는 이 난제를 해결해가는 과정을 그들의 블로그에 소개를 했습니다.

앞선 글에서 소개했다시피, 뉴욕타임스는 ProseMirror라는 오픈소스 에디터를 바탕으로 에디터 툴을 업그레이드 해가고 있습니다. ProseMirror 사이트를 다시 방문해 보니 제법 많은 기능들이 업데이트가 됐덕군요. 왜 뉴욕타임스 개발자들이 ‘운이 좋게도’라고 표현했는지 알 수 있었습니다. 이미 ProseMirror는 실시간 협업 에디팅 기능을 지원하고 있었더군요. 심지어 펀딩하는 주체들도 상당히 많이 늘어났습니다. 워드프레스 창업자 매트 멀렌웨그도 1만2000 유로를 펀딩했더군요. 이건 핵심이 아니니 얼른 넘어가겠습니다.

에디터를 둘러싼 뉴욕타임스의 CMS는 아래와 같은 구조를 띠고 있었습니다.(이건 제가 글을 보고 추정한 것입니다)

먼저 위 그림을 쉽게 설명을 드리면, ProseMirror 기반의 Oak 에디터에서 실시간으로 작업한 기사 내용은 기자의 개별 노트북이나 컴퓨터에 저장이 됩니다.(local) 한명 한명 기자가 작성한 버전은 step이라는 형태로 저장돼 ‘지휘/인가 서버'(Authority Server)로 전송이 됩니다. 지휘 서버는 Firestore에서 구성된다고 하네요. 이 지휘 서버는 동시 작성 기사의 결과물을 step 단위로 줄을 세웁니다. 여기에 운영 전환(Operational Transformation) 알고리듬이 개입합니다. 여러 명이 보내온 step들을 최신 버전으로 정렬하는 알고리즘이라고 합니다. 여기서 대략 디지털 버전이 완료가 됩니다.

디지털 버전으로 발행된 버전은 이제 인쇄 신문으로 넘어갈 준비를 합니다. 인쇄 버전 기사로 넘어가려면 먼저 디지털 버전에 포함된 하이퍼링크와 임베드 콘텐츠를 제거해야만 하죠. 그렇지 않으면 지저분한 코드들과 함께 신문 편집판으로 보내질 수 있기 때문입니다. 뉴욕타임스는 인쇄 기사가 담기는 별도의 서버를 운영 중이더군요. MySQL 데이터베이스 형태로 구축이 됐습니다.

뉴욕타임스는 Firestore에 저장된 디지털 버전 기사를 인쇄 신문용 기사가 담겨 있는 MySQL데이터베이스로 복사하기 위해 별도의 복제 시스템을 개발을 했더군요. 정기적인 시차를 두고 디지털 버전이 인쇄 버전으로 옮겨가는 방식이었습니다. 아시다시피 국내에 적지 않은 신문사들은 아직도 이 복제를 인간에게 맡기고 있습니다. 물론 대형 언론사들은 이미 이 문제를 시스템을 해결했습니다만.

이 복제 시스템은 구글 클라우드 펑션과 구글 클라우드 태스크로 구축이 됐다고 합니다. 신문으로 인쇄되기 전에 최신 버전을 프리뷰할 수 있도록 설계되기도 했고요. 이렇게 디지털 버전이 인쇄 신문 버전으로 넘어오고 최종적으로 인쇄판에 오르게 되면 Finish Line이 만들어진다고 합니다.

여기서 끝이 아닙니다. 기사 발행 뒤 정정, 반론이 남아있죠. 정정이 발생하면, 해당 문구는 다시 디지털 버전이 저장된 지휘 서버로 넘어가는 프로세스라고 합니다. 인쇄 신문 데이터베이스로는 곧장 반영되지는 않는 모양이더군요.

[2019년 5월]

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

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

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

• 2012년 1월 : Introducing ICE: Writing for the Web First
• 2012년 1월 : Ice Demo
• 2014년 1월 : Scoop: A Glimpse Into the NYTimes CMS
• 2014년 7월 : Why the NYT is Building Their Own CMS
• 2017년 : CMS search optimization and typographic headline balancing
• 2018년 4월 : Building a Text Editor for a Digital-First Newsroom

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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