[일잘러의 지표들] ⑥ '오래된 PM', 출판 편집자의 프로덕트 품질 개선법 3가지

지금 당신이 들고 있는 스마트폰에는 1천여 가지 부품이 들어간다. 자동차에는 3만 개의 부품이 사용되어 완제품으로 시장에 나온다. 스마트폰을 사자마자 보호필름과 케이스로 감싸고 차량은 인수 직전 전문가에게 비용을 지불하면서까지 검수한다.

그러다 만에 하나 불량을 발견하면 리퍼를 요청하거나 인수를 거부하기도 한다. 그 불량은 보는 기준에 따라 결함이라고 보기 어려운 디스플레이 색감이나 외판의 단차 같은 것도 해당한다.

책은 어떠한가. 10만 개 이상의 부품이 활자라는 이름으로 이루어져 독자에게 전달된다. 이 정도 부품이 사용되는 분야는 첨단산업에 해당하는 우주 로켓을 만드는 데 버금갈 정도다.

그러나 활자 하나 틀렸다고 교환하거나 문제시하지는 않는다. 치명적인 결함이 아니어서 그런 것인가. 아니면 인간의 사고체계를 글로 옮기는 책이라는 매체가 갖는 특수성 때문인가. 이유가 어떻든 제품, IT에서 말하는 프로덕트 관점에서는 용납하기 어려운 것이 사실이다. 내가 짠 코드가 돌아가지 않는데 그걸 가만두고 볼 일은 아니지 않은가?

이 모든 과정에서 우리는 단 하나의 키워드를 떠올릴 수 있다. 바로 ‘품질’이다. 책이나 소프트웨어 프로덕트나 독자와 사용자를 염두에 두고 만든다. 시장에서 사랑받기 위해, 아니 사랑은 고사하고 살아남기 위해서 포기할 수 없는 한 가지는 바로 품질이다.

이 글에서는 책을 매개로 프로덕트 매니지먼트 관점에서 제품의 품질을 적정 수준으로 유지하는 방법을 이야기한다. 하나의 프로덕트 생애주기를 처음부터 끝까지 관리하는 측면에서 편집자는 가장 오래된 PM이라고 할 수 있다. IT에서도 공통분모를 발견할 수 있을 테다.

책과 IT 프로덕트의 상관관계

17년간 편집자로 책을 만들다 보니 콘텐츠도 중요하지만 책을 만들어가는 과정도 못지않게 중요하다는 걸 깨닫는다. 그 과정에서 품질 개선이 이뤄지기 때문이다.

책을 만드는 과정은 소프트웨어 프로덕트를 만드는 과정과 닮았다. 책을 만드는 과정부터 살펴보자. 출판도 통상의 제품 개발 프로세스를 따른다. 시장조사를 하고 아이데이션을 통해 책의 콘셉트를 정하고 대상 독자를 특정한다. 전달하고자 하는 주제를 쓸 수 있는 저자를 섭외하고 중간중간 저자와 소통하며 집필 일정을 관리한다. 이른바 프로덕트 기획, 구현 단계이다.

탈고 후 편집 단계에서 적게는 1-2회, 많게는 5-6회 이상의 원고 검토를 반복하면서 품질을 개선한다. 이 과정에서 자유롭게 글을 가감할 수 있는 포맷인 워드에서 권한 있는 자만 수정할 수 있는 뷰어 형태의 PDF로 포맷 변환이 이루어진다. 포맷의 변경으로 인해 프로세스의 변화를 맞는다. 소통의 방식도 달라지고 품질을 개선할 수 있는 깊이와 폭도 제한된다. 편집 과정은 프로덕트 테스트, 빌드 과정이라고 볼 수 있다. (이후 제작, 배본이라는 배포 과정이 있다.)

메신저 서비스 애플리케이션을 만들 때 사용자를 특정하여 퍼소나로 구현하는 것처럼 출판에서도 독자를 구체화하기도 한다. 가령 리액트 책의 난이도를 정할 때 3년 차 프론트엔드 개발자로 하거나 피그마 책을 만들 때 스케치를 사용했지만 클라우드 기반 협업이 필요한 기획자나 디자이너로 타기팅하는 식이다.

이쯤 되니 출판이나 IT나 비슷해 보인다. 그렇다면 다음 세 가지 품질 관리 지표를 읽을 준비가 됐다. 책 대신 자신의 프로덕트로 치환해보자.

#1 편집관 - core value

지켜야 할 핵심가치가 있는가

하나의 책을 진행하는 데 얼마의 시간이 걸릴까? 책의 성격과 분량에 따라 다르지만 통상 1년여 시간이 걸린다. 책이라는 하나의 프로젝트 치곤 제법 긴 시간인데 실제로는 편집 단계부터 편집자가 관여하므로 2개월 정도 프로젝트 매니저로서 품질 관리를 담당한다.

‘어, 2개월? 할 만한데?’라고 지레짐작하고 있다면 틀린 생각은 아니다. 하지만 이런 접시돌리기를 대여섯 개 정도 하다 보면 그게 그거 같고 접시 무게와 모양도 제각각이라 떨어뜨려 깨지기 전에 위태롭게 돌고 있는 것부터 내려놓기 바쁘다. 그런데 알고 보면 그걸 가장 오래 돌려야 하는 접시인데 다시 올려서 돌릴 수도 없는 지경이 된다.

이렇게 되면 기획한 콘셉트나 퍼소나까지 정하면서 타기팅한 독자는 온데간데 없고 오로지 접시를 ‘돌리는’ 그 행위에 매몰된다. 자신이 편집자인지 일정 관리자인지 그냥 회사원인지 역할 아노미 상태다. 일을 통제하는 것이 아니라 일에 끌려다니는 형국이다.

바로 그때 방향성을 잃지 않고 처음 기획했던, 사용자인 독자를 품었던 그 마음 그대로 가져갈 수 있는 방향타가 있다면 모든 프로덕트는 각자의 색과 결에 따라 편집자의 지휘 계통 아래 놓이게 된다. 편집자로서 PM이 프로덕트를 지배할 수 있는 은탄환, 바로 편집관이다.

편집관이 마련됐다면 긴 항해도 걱정 없다. 편집관이 있다는 것은 의사결정 준거점이 마련돼 있다는 의미이고 이는 품질의 바로미터가 된다. 그뿐인가. 저자를 설득할 때, 협업자와 소통할 때도 빛을 발한다. 일관된 틀에서 의사결정이 이루어지니 소통 비용을 줄이는 만큼 콘텐츠에 집중할 수 있다. 모두가 한 방향으로 나아갈 수 있는 동력을 제공한다.

이러한 편집관(핵심가치)은 조직의 미션이나 비전과 핏이 맞아야 한다. 출판사(조직)는 ‘적기에 내는 빠른 책’을 우선 가치로 내세우는데 편집자(구성원)는 ‘늦더라도 높은 완성도’를 편집관으로 내세운다면 이는 올바른 방향은 아니다. 서로의 가치가 상충한다면 그 부분부터 합치시켜야 한다.

편집관은 상당한 시간의 데이터가 쌓여 그 안에서 인사이트를 뽑아낼 수 있을 때 마련된다. 그저 이렇게 하겠다고 하는 선언만으로 될 성격이 아니다. 편집 데이터에 기반한 경험과 노하우, 시행착오를 축적하여 편집자 자신의 것으로 내재화할 때 비로소 ‘나는 이러한 관점으로 편집하겠다’고 말할 수 있다. 사안에 대한 문제의식이 없다면 10년을 일해도 책을 바라보는 자신만의 가치관 하나 정립할 수 없다.

지금 자신이 참여한 프로덕트에서 나는 이런 관점으로 프로덕트를 만든다고 말할 수 있는가. 프로덕트는 어떠해야 한다고 스스로 정의할 수 있을 때 그 프로덕트의 적정 품질을 유지할 수 있다.

#2 교차 리뷰 - reward by trust

신뢰에 기반한 보상이 있는가

퍼소나를 예로 들어보자. 저자가 UX를 주제로 집필하면서 persona를 페르소나로 표기한다. 페르소나. 미디어에서 많이 들었던 말이다. 편집자는 페르소나persona라고 영문 병기하여 독자 이해도를 돕는다. 그리고 책은 그대로 독자에게 전달된다.

무슨 문제가 있는가? 책의 성격이 영화와 관련된 문화 교양서라면 괜찮다. 그쪽에서는 주로 페르소나로 칭하니까. 그런데 이 책은 UX 책이다. 그렇다면 IT 영역에서 persona를 어떻게 다루는지 확인해야 한다. 앨런 쿠퍼 옹의 이야기를 들어보자.

그렇다고 한다. 퍼소나로 써야 한다. 외래어 표기 규정을 따르더라도 발음기호상 퍼소나가 맞는 표기다. 그러나 저자도, 편집자도 이를 걸러내지 못했다. 문제의식을 갖지 않으면 이러한 문제는 언제든 벌어진다.

하지만 말이 문제의식이지 매 사안에 문제의식을 품을 수는 없다. 그건 엄청난 에너지 소모이며 정신 노동이다. 망치를 들면 모든 게 못으로 보인다고 책 하나 만들려다가 사회부적응자가 될 수도 있다. 그렇다면 해결할 수 있는 방법은 없을까?

방법은 있다. 다른 편집자가 봐주는 것. ‘주고 받다’가 왜 틀렸는지 모르는 편집자는 백날 봐야 그 오자는 못 잡는다. 더 많은 정보량을 갖고 있거나 다른 관점을 가진 누군가가 그 원고를 볼 때 개선점이 나오고 문제를 해결할 수 있다. 코드 리뷰나 짝 프로그래밍도 그런 고민에서 시작된 방법론 아닌가.

그러나 출판사 조직 구조상 교차 리뷰는 요원하다. 영세하게 운영되는 상황에서 자신의 태스크만 처리해도 버거운데 다른 이의 원고까지 보라? 일을 하는 데 선의에 기대는 것만큼 위험한 것은 없다.

이들을 움직이기 위해서는 보상이 필요하다. 다만 여기서의 보상은 즉각적이고 실질적인 보상이 아니다. 단기적 이득(benefit)이 아닌 신뢰에 기반한 성장(growth)의 관점으로 봐야 한다.

동료의 원고를 검토하는 것은 결국 나의 편집 역량을 성장시키는 훈련이다. 이것은 동료가 나의 문제 해결에 도움이 된다는 서로에 대한 신뢰(trust)를 바탕으로 한다. 그리고 그 결과는 프로덕트 품질 개선으로 이어진다. 선순환 고리를 만드는 셈이다.

팀에 참여하고, 동료의 문제 해결에 자신의 생각을 더하고, 나의 문제 해결을 위해 동료에게 도움을 요청하는 신뢰에 기반한 성장이라는 보상이 작동하면 품질은 개선된다. 하다못해 개선은 어렵더라도 기준 이하로 떨어지지는 않는다. 팀에서 정한 핵심가치를 모두 공유하고 있으므로 그 준거점이 작동하기 때문이다.

#3 OK 검토 - check list

극한의 환경에서 점검 항목을 갖췄는가 

나는 이 과정을 저널리즘의 ‘데스킹(desking)’에 비유한다. 데스킹은 언론사 부장이나 국장이 기사를 송고하기 전 기사 품질을 점검하는 단계를 일러 부르는 말이다.

취재기자가 작성한 기사가 팩트에 부합하는지, 오탈자는 없는지, 기사 방향이나 시의성에 부합하는지 등 기사의 품질을 올리고 오류를 줄이는 과정이다. 얼토당토한 기사를 보게 되면 “데스크는 뭐하고 있냐?” 같은 말을 종종 하는데 한마디로 권한 있는 책임자는 어디서 뭐하고 있길래 기사를 이따위로 내도 아무도 모르냐는 소리다. 시스템이 제대로 기능하지 않는다는 말과도 같다.

그런데 이러한 데스킹의 문제는 ‘권한 있는 책임자’는 늘 바쁘다는 데 있다. 발행되는 모든 기사를 검토할 정도의 짬이라면 대부분 직책자여서 회의실에 상주하다시피 한다. 회의를 마치고 나오더라도 다른 회의로 끌려가고 있을 확률이 높다. 그렇다고 독자와 만나기 전 최종 단계를 건너뛸 수도 없다. 시간은 부족한데 품질은 적정 수준을 유지해야 한다. 빠르고 퀄리티가 좋아야 한다는 소리다.

출판에도 이러한 단계가 있다. ‘OK교’라고 불리는 인쇄 전 최종 검수 과정이다. 배포 전 마지막 테스트 단계라고 생각하면 된다. 이때의 품질은 출판될 책의 그것과 99% 동일해야 한다. 그리고 지금 상황은 바로 인쇄를 걸어야 할 타이밍이라는 거다. 빨리 검토해야 하는데 품질까지 보장해야 한다.

이 경우 해결할 수 있는 방법은 두 가지다. 침침한 눈으로 돋보기를 들었다 놨다 하며 스윽 보는 것만으로 편집 오류를 잡아내는 ‘사기캐’ 같은 편집장이 있으면 된다. 그러나 그런 캐릭터는 보통 출판사를 운영하고 있지 조직에 남아 있지 않다. 간혹 남아 있다면 회의실에서 나오지 못하고 있을 게 분명하다. 이른바 만렙 시니어가 조직에 있다면 그나마 품질 유지에 도움이 된다.

그렇지 않다면 최종 검토 단계에서 확인해야 할 사항을 목록화하는 것이다. 조직에 축적된 데이터에 기반하여 단시간에 극도의 완성도를 확보하는 가이드 문서가 있으면 된다. 사람에 의존하지 않기 때문에 어느 순간에서도 적정 품질을 담보할 수 있으며, 치명적인 오류는 일어나지 않는다는 일종의 심리적 저항선이 생겨 실수를 예방하기도 한다.

이러한 문서는 관리가 잘 되는 조직에는 보통 마련되어 있다. 그럼에도 오류는 발생하는데 이런 체크 리스트는 어처구니없는 실수를 방지하는 것이지 콘텐츠 본연의 품질을 드라마틱하게 올려주지는 않는다.

품질은 최종 단계에서 올리는 게 아니다. 릴리스 전에 치명적인 실수를 줄여 앞서 마련한 품질을 담보함으로써 브랜드 가치를 확보하는 수단으로 활용해야 한다.

마치며

스티븐 킹이 “창작은 인간의 영역, 편집은 신의 영역”이라고 하지 않았던가. 패턴을 정형화할 수 없는 일을 반복한다는 것은 참으로 고되다. 몇 십만 자의 부품으로 이루어진 원고를 자동화 같은 도구 없이 수회에 걸쳐 읽으면서도 품질을 유지할 수 있는 것은 책을 일관되게 이끌어가는 핵심가치, 신뢰를 바탕으로 한 협업에 의한 성장, 극한 환경에서도 적정 수준을 유지할 수 있는 점검 항목이 있기 때문이다.

모든 프로덕트에는 사연이 있다. 그 사연이 품질 저하의 변명이 되어서는 안 된다. 어떠한 사연에도 프로덕트 품질을 개선해야 한다. 프로덕트를 세상에 내보내고 열악한 사연에도 불구하고 우리는 품질을 지켰다고 서로를 다독이며 말할 수 있도록 말이다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.