About me Op-eds

디지털 네이티브 미디어 조직의 개발자가 하는 일

저널리즘 미디어, 디지털 네이티브 미디어, 혹은 콘텐츠 플랫폼 서비스를 만드는 조직의 개발자는 어떤 일을 하게 될까요? 또 어떤 일을 해야할까요? 2016년부터 4년간 서비스된, 유료 콘텐츠 플랫폼 서비스이자 버티컬 미디어였던 <핀치> 개발 과정을 통해, 미디어 콘텐츠 / 저널리즘 분야를 다루는 조직의 개발자가 하게되는 / 해야하는 역할을 살펴봅니다.

핀치 개발 구성요소

핀치 팀이 주로 개발해야했던 시스템은 3가지였습니다.

  • 핀치 웹사이트 및 모바일 어플
  • 고객 구독/결제 처리 시스템
  • 인하우스 CMS : 콘텐츠 관리 시스템

각 시스템들이 개발자에게 요구하는 사항은 저마다 다릅니다.

핀치 웹사이트와 모바일 어플, 즉 엔드유저 서비스는 성능과 디자인을 모두 구비해야 했습니다. 프론트엔드와 백엔드 모든 영역에서 적용할 수 있는 거의 모든 성능 최적화 기법을 적용하고, 디자이너가 설계한 UX를 정확히 구현하여 최상의 사용성을 확보하며, A/B 테스트 등 경영상의 과제에도 기민하게 대응해야 했습니다.

구독/결제 처리 시스템은 만에 하나 장애가 발생될 경우 더욱 큰일나는 시스템입니다. 쇼핑몰들이 그렇듯 핀치 역시 정기구독 멤버십 중심의 콘텐츠 플랫폼이었기 때문에, 고객 구독/결제 시스템은 데이터 처리의 안정성을 최우선으로 두고 구축 운영되어야 했습니다.

핀치의 CMS는 통상적으로 업계에서 이야기하는 CMS를 넘어선 넓은 개념을 가리켰습니다. 핀치의 CMS는 다음과 같은 기능을 모두 담고 있었습니다.

  • 콘텐츠 작성 도구 (그야말로 CMS)
  • 에디터와 크리에이터의 편집활동을 도울 인공지능 도구
  • 독자의 만족도를 확인할 수 있는 콘텐츠 통계 시스템 (Analytics)
  • 고객 맞춤형 혜택과 유료 구독자 증대를 모색하는 CRM시스템
  • 좋은 글감과 좋은 콘텐츠를 에디터와 독자 모두에게 제공하는 추천 시스템
  • 꼼꼼한 크리에이터 정산 시스템
  • 콘텐츠 편집과 서비스 운영을 돕는 챗봇

핀치는 유료구독 멤버십 외에도 독자가 크리에이터를 직접 후원하는 기능을 갖추고 있었습니다. 콘텐츠가 마음에 들면 크리에이터에게 응원의 마음을 담아 더 많은 고료를 전하는 것입니다. 이를 신속 정확하게 정산해 크리에이터에게 약속대로 전달하는 것 역시 핀치에겐 중요한 일이었습니다. 엑셀로도 정산업무를 할 수 있지만, 기계가 할 수 있다면 기계에게 더 정확하고 신속하게 처리하도록 맡기고 사람은 다른 더 중요한 일을 하는 것이 좋을 것입니다. 그래서 핀치 개발자는 핀치 운영에 필요한 다양한 업무들을 자동화하는 도구를 만드는 과제도 수행해야 했습니다.

여기에 더해 크리에이터-에디터와 함께 콘텐츠 포맷을 개발하고, 인터렉티브 콘텐츠 제작 실험도 병행합니다. 유료콘텐츠를 보호하기 위한 보안장치를 마련하는 것도 핀치 개발자의 역할이었습니다.

핀치 팀은 스타트업으로 시작했습니다. 그래서 극단적으로 적은 개발 리소스를 최대한 효율적으로 활용해야하는 과제를 안고 있었습니다. 스타트업 단계에서의 개발은 인프라와 프론트엔드 백엔드 모바일어플 등 전 분야에 걸쳐 가장 적합한 기술을 채택하여 빠르게 서비스를 구축하는것이 중요합니다. 아울러 적은 내부 인력에도 불구하고 실수 없이 코드를 배포하고, 서비스 버그를 최소화시키고, 높은 품질을 유지해야합니다.

핀치라는 서비스는 콘텐츠를 즐기는 독자와, 그 콘텐츠를 가꾸는 에디터-크리에이터와 분리될 수 없습니다. 그래서 핀치 개발자는 에디터와 매우 긴밀하게 소통하며 에디터의 업무 프로세스 전반과 함께 맞물려져 서비스를 설계해야 했습니다. 이를 위해 핀치 팀은 초창기부터 사일로로 묶이지 않고 DevOps 철학을 개발조직 뿐만 아니라 전 팀에 적용했었습니다. 개발과 기획, 협업 커뮤니케이션 모든 영역에서 어느 하나도 빠짐이 있어서는 안되었고, 이는 개인의 역량을 넘어 조직문화나 커뮤니케이션 구조에서도 세밀하게 적용되었습니다. 이는 레거시 조직문화가 없는 스타트업이라 가능한 일이었습니다.

핀치가 사용했던 기술들

핀치 팀이 구성되어 본격적으로 제품을 만들기 시작한 것은 2016년 여름이었습니다. 콘텐츠 플랫폼 서비스를 만드는데에는 많은 자본과 시간이 투입되어야했지만 핀치 팀에게는 그런 여유가 없었습니다. 한편으로는 외부 투자를 받았기 때문에 빠른 제품 출시와 빠른 성장이 핀치 팀에게 꾸준히 요구되었습니다. 콘텐츠 섭외/제작과 동시에 제품이 만들어지면서, 최대한 빠르게 CMS : 콘텐츠 관리 시스템과 웹서비스를 동시에 구축해야 했습니다. 크리에이터-에디터가 사용할 수 있는 CMS구축은 한달 내에 완료해야했고, 브랜드 디자인과 UX를 입힌 웹사이트 구축은 두달 내에 완료해야했습니다. 한국의 결제시스템 승인에는 시간이 꽤나 오래 걸리고, 승인 심사과정에서 MVP 수준의 데모가 미리 준비되어야했기때문에, 개발 우선순위에서 이 부분 역시 비중있게 염두해야 했습니다. 결제시스템을 완성하고, 콘텐츠를 담고, 테스트를 거친 뒤, 그해 10월 10일 핀치는 정식 오픈을 하게 됩니다.

핀치의 시스템 아키텍쳐는 앞서 소개한 3가지 시스템을 중심으로 구성되었습니다. 엔드유저 웹서비스가 있고, 그 웹서비스에서 판매되는 콘텐츠를 인하우스가 최종적으로 편집해 업로드하는 CMS가 있었습니다. 그리고 정기결제가 이루어지는 결제처리 시스템이 있었습니다. 각 시스템을 분리하여 시스템의 목적에 맞게 제반 환경을 최적화하여 구축 운영하는것은 개발자의 역할이었습니다. 운용 안정성과 릴리즈의 용이함, 그리고 비용 절감이 최적화의 조건입니다. 핀치 인프라 상당수는 Amazon Web Service(AWS) / Google Cloud Platform(GCP) 와 같은 클라우드에 맡겼습니다. 핀치는 거의 매일 1회 이상 서비스 기능을 고쳐 릴리즈했기때문에, 무중단 배포를 위한 이중화를 목적으로 docker 컨테이너들을 설계해 가동했습니다. Amazon ECS/ECR을 이용할수도 있겠지만 핀치가 처음 만들어질 시기에는 ECS/ECR에 서울 리전이 없었고, 그냥 EC2 인스턴스에다 docker를 직접 올려 운영했습니다. static 자원에 접근하는 스토리지의 경우 AWS와 GCP에 이중으로 배포했었고, CDN으로 AWS CloudFront와 Google Cloud CDN을 동시에 사용했습니다. 이후 네트워크 속도와 비용 등을 비교하다 당시 가격이나 성능이나 통합운영의 이점이나 모두 앞섰던 AWS로 모두 넘겼습니다. 자체 웹서비스 대용량 트래픽 대응과 구독상태별 페이지 캐쉬 대응에는 ElastiCache를 활용했고, EC2 바깥 구간에서 Cloudflare도 일부 활용했습니다.

DB는 다층위로 설계할 Analytics를 고려하여 RDB를 이용했습니다. 웹서비스와 CMS 시스템 모두 Python-Django 프레임웍으로 개발했습니다. Django는 본래부터 콘텐츠 관리에 최적화된 프레임웍입니다. 여기에 RDS를 통한 통계 산출 및 그로스해킹 대응에도 십분 활용할 수 있다는 이점이 있었습니다. 섬세하고 유연한 데이터 모델 설계와 빠른 개발을 동시에 얻어내는데에는 Django가 제격이라 판단했습니다. Django는 Django Girls 커뮤니티 등 개발자를 꿈꾸는 지망생들에게 가장 접근성이 높은 프레임웍이라는 점도 고려했습니다. 당시 국내 미디어기업들이 선호하는 프레임웍인 점도 기술 채택에 함께 고려했습니다. 모바일 어플은 React-Native로 개발하였습니다. 결제 시스템과 챗봇 등 다른 시스템들 역시 이들 위에서 Python 또는 node.js로 구동했습니다. 이메일 발송이나 결제연동 등 3rd party 서비스를 쓸 수 있는 기능은 최대한 3rd party에 맡겼습니다.

성능 개선을 위한 노력

핀치 웹서비스는 초창기부터 Single Page Application 을 목표로 설계되었습니다. 이를 빠르게 구현하기 위해 초기에는 서비스에서 쓰이는 거의 모든 기능과 결부된 CSS와 JS를 몽땅 합친 구조로 서비스를 운영했습니다. 캐쉬 등 여러 기술에 힘입어, 사용성에 크게 문제가 되지 않는다면, 언젠가는 쓰게 될 다양한 기능에 대한 리소스를 미리 모두 불러오는 것이 좋겠다는 판단이었습니다. 이는 핀치 팀의 초기 가설과도 맞물린 설계였습니다.

핀치 팀은 하루 평균 읽을 수 있는 콘텐츠의 양에는 제약이 있을 수 밖에 없고, 대다수 핀치의 콘텐츠가 긴 이야기 - 롱폼 콘텐츠 - 였기 때문에, 독자들이 하루에 두세종류 씩 천천히 읽을거라 생각했습니다. 그러나 독자들의 서비스 사용패턴은 핀치 팀이 당초 예상했던 것과 전혀 다른 방향으로 나아갔습니다. 많은 핀치 독자들이 아침 출근때, 점심시간에, 저녁 퇴근때, 그리고 매일 밤마다 새로 올라온 콘텐츠를 꾸준히 확인하고 모두 정주행하고 있었습니다. 서비스가 가동되는 시간이 긴 만큼, 누적된 리소스로 인한 메모리 관리 문제가 터져나왔습니다. 구형 기기에서 브라우저나 어플이 뻗는 사례가 계속 보고되었습니다. 이는 돈을 내고 구독하는 콘텐츠 서비스에서는 치명적인 문제일 수 밖에 없었습니다.

통상적인 국내 인터넷 사이트와 전혀 다른 이용패턴이 발견되면서 핀치 서비스의 설계 역시 통상적인 관념을 벗어나야 했습니다. 가정과 직장은 물론 이동중에 서비스를 이용하는 분들도 많다는 사실이 확인된 것입니다. 이때부터 핀치 개발 과제에 성능개선 문제가 높은 우선순위로 다루어지기 시작했습니다. 게다가 일반적인 모바일 서비스보다 가동시간이 더 길다는 사실까지 확인되었고, 안그래도 경우에 따라서는 웹툰 서비스보다 더 많은 고품질 이미지가 제공되는 상황이었습니다. 그래서, 최대한 리소스를 경량화, 모듈화 하는 방향으로 엔드유저 서비스의 구조를 신속히 전환해야 했습니다. 이후 핀치는 이동중인 모바일 환경에서도 3초 내에 어플이 구동되는데에까지 이르렀습니다.

성능개선 문제 해결에는 쓸 수 있는 기법을 모두 다 동원하는 것 외에는 방법이 없습니다. 백엔드 파트에서는 콘텐츠를 랜더링하는 과정을 단순화하고, DB에 접근하는 쿼리를 최적화하고, 캐쉬 적용을 세분화하는 것이 첫 시작입니다. 프론트앤드 파트에서는 엔지니어링 관점에서 손볼 분야가 훨씬 더 많습니다. 핀치는 기본적으로 다음과 같은 교과서적인 기법들부터 적용되었습니다.

  • CSS/JS/HTML minify
    • 기본 중 기본입니다. 스페이스, 주석을 모두 제거하는 것만으로도 전송해야할 트래픽을 줄여 큰 개선을 볼 수 있습니다. 보안을 고려해 uglify를 겸할 수도 있습니다.
  • gzip 압축, Expires 설정
    • 역시 기본 중 기본입니다. 압축 전송의 경우 AWS Cloudfront 나 Cloudflare 의 경우 간단한 설정 체크만으로도 적용이 가능하며, GCP 의 경우 파일 업로드시 관련 플래그를 켜면 적용이 가능합니다. 캐쉬 expires 역시 메타정보를 함께 전송하면 적용이 가능합니다. 코드 배포과정 및 CMS에서의 이미지 업로드 과정에 모두 적용하였습니다.
  • 모듈화
    • 기능별로 CSS/JS static 자원를 쪼개고 필요할 때 부르는 것입니다. 비동기 번들 로딩은 요즘에는 흔하지만, 핀치가 만들어질 때에는 아직 표준이라 할만한 기법이 굳어지지 않았던 시기였습니다. 필요한 모듈만 부르도록 비동기 로딩을 직접 설계하고, 적정 시점에는 SPA 내 로딩을 깨어 처음부터 페이지를 불러오도록 엔드유저 서비스 코드를 모두 리팩토링했습니다.
    • 지금은 Webpack이 다 해주지만, 당시에는 직접 자체적으로 모듈화 코드를 짜 적용했었습니다.
  • 경량화 웹폰트 사용, prefetch/preload
    • 핀치는 유려한 읽기 경험을 중시했기 때문에 웹폰트를 사용했었고, 모두들 하는 웹폰트 최적화 기법은 모조리 다 사용했습니다.
  • LazyLoading
    • 트래픽 비용절감은 물론 사용자 브라우저의 부담을 경감시키기 위해서도 LazyLoading은 필수적이었습니다.

이들 기술은 트래픽이 많은 서비스를 개발할 때 비용을 절감시키기 위해 으레 고려하는 기술들입니다. 핀치가 고려해야할 사항은 더 있었습니다.

  • SSR : 서버사이드 랜더링
    • 핀치는 SPA : Single Page Application 형태로 구성되어 있었지만 CSR : Client side rendering 에 모두 의존하지는 않았습니다. 핀치가 만들어질 당시에는 구글 등이 브라우저 랜더링 결과를 검색 결과에 적용하고 있지 않을 때였습니다. 핀치가 콘텐츠플랫폼 서비스였던만큼 SEO : 검색엔진 최적화 대응에도 기민하게 반응할 수 있어야했고, 그러면서도 사용자가 체감하는 성능 또한 중요했습니다. React는 핀치가 만들어질 초창기엔 초기 단계의 프레임워크였기때문에 채택되지 않았습니다. 좋은 사용자 경험과 SEO 대응, 기기환경 최적화를 모두 고려할 때, 거의 모든 페이지 구성을 서버사이드 랜더링에 맡기고, 여기에 pushState를 적절히 섞어 SPA를 직접 구현하는 것이 당시에는 최선의 선택이었습니다. 적정 시점에는 SPA를 끊고 처음부터 다시 웹페이지를 로딩하도록 하여, 당시 모바일 환경에 맞는 안정성을 확보하고자 했습니다.
    • React가 보편화된 2020년 이후에는 next.js 등 다양한 대안을 고려해볼 수 있을 것입니다. 미디어 조직이 제공하는 콘텐츠가 점차 API화될 경우 프론트엔드 파트에서는 모듈식 설계 소요가 더욱 커질수도 있습니다. 제품의 특성과 향후 운영방식을 두루 고려하여 적합한 기술 스택을 선택하는 것 역시 개발자의 역할입니다.
  • 이미지 최적화
    • 품질이 떨어지지 않으면서도 가장 최적화된 이미지 리소스가 제공되도록, 이미지 후처리 로직을 전 콘텐츠에 적용하였습니다. webp를 지원하는 브라우저에서는 webp를 쓰도록 하고, 모바일 기기는 각 기기에 맞는 리사이징된 이미지가 제공되도록 하였습니다.

조기 최적화는 모든 악의 근원(Premature optimisation is the root of all evil; Donald Knuth) 이라는 말이 있습니다. 정말 그렇습니다. 하지만 최적화는 머지 않아 해변으로 밀려오는 파도와도 같습니다. 파도가 밀려온 직후 기민하게 움직이는 것도 개발자의 과업입니다.

CMS 설계

CMS는 Content Management System, 즉 콘텐츠를 편집하고 발행하여 운영하는 시스템입니다. 핀치가 제공하려던 고품질 텍스트 콘텐츠를 편집하는데에 적합한 시판 CMS는 없었습니다. 포털이 제공하는 콘텐츠 편집 도구는 훌륭하지만 이를 쓰기 위해선 포털 플랫폼의 규칙에 따라야했고 멤버십 서비스를 만들 수는 없었습니다. 워드프레스와 같은 CMS로는 예쁜 사이트를 만드는데엔 무리가 없지만, 체계적인 피드백 관리, 통계 분석, 그리고 다양한 포멧 개발까지 함께 대응하는 것은 어려운 일이었습니다. 그래서 핀치 팀은 핀치의 콘텐츠에 걸맞는 CMS를 직접 만들기로 했습니다.

핀치의 CMS는 기본적으로는 핀치가 지향하는 고품질 콘텐츠를 만들어 낼 수 있는 도구여야 했습니다. 여기에 앞서 언급한 것처럼 단순 콘텐츠 편집 발행은 물론, 각 콘텐츠에 대한 독자의 관심, 주제별 호응도, 각 읽기 경험에서의 만족도 또한 세밀하게 분석하여 그 평가를 이후 콘텐츠 편집 과정에 반영할 수 있도록 하는 시스템도 필요합니다. 꾸준히 트랜드와 데이터를 분석해 에디터에게 더 좋은 콘텐츠를 만드는데 보탬이 될 제안을 CMS가 스스로 제시해야 했습니다. CMS 시스템의 기능 하나하나가 감각있게 서비스를 운영하는 내부 에디터 한명의 몫을 감당하는 셈입니다.

핀치의 CMS는 콘텐츠를 관리하는 것은 물론 사이트 빌더의 역할을 수행하기도 했습니다. 어떤 콘텐츠를 오늘의 주된 헤드라인으로 올릴 것인지, 유료 사용자에게 어떤 콘텐츠를 추천할 것인지, 한 콘텐츠를 다 읽고나면 그 다음에 읽을 콘텐츠로 어떤 콘텐츠를 추천할 지 고르는 것 역시 역시 CMS가 해야하는 일이었습니다. 다음에 읽을 콘텐츠를 잘 골라낸다면 독자의 만족도는 높아질 것이고 유료 구독자는 더욱 늘어날 것입니다. 다양한 A/B 테스트를 수행해 데이터를 축적해나가며 지속적인 성장을 도모하는 것 역시 CMS의 몫이었습니다. 유료 구독상품을 이용하는 독자가 아닐 경우, 적절한 시점에 구독을 권유해야하기 때문에, 적절한 시점을 찾는 실험을 진행하여 결과를 축적하는 것 역시 CMS에서 제공해야하는 기능입니다. 그래서 핀치 CMS는 단순한 CMS 가 아닌, 핀치 콘텐츠를 함께 만드는 에디터이자, 핀치의 성장을 도모하는 마케터 또는 데이터 사이언티스트 역할을 하는 구성원처럼 작동했습니다. 에디터, 콘텐츠 Analytics, 고객 분석을 포함한 CRM 등, 뉴스룸과 멤버십 비즈니스 조직이 필요로 하는 모든 기능을 서비스로 개발되었습니다. 핀치 팀의 투자유치 과정에서 “CMS 개발을 왜 직접 하느냐” “개발자는 빼고 워드프레스로만 운영하라” 고 조언하는 이들도 꽤나 많았습니다. 개발자 인건비도 비싸고 하니 콘텐츠로만 수익을 내보라는 조언이었지요. 종종 저도 그쪽을 권해보곤 했지만, 핀치 팀은 위와 같은 운영을 기민하게 진행하기 위하여, 양질의 콘텐츠를 만들고 매체의 톤을 관리하는 것과 함께 CMS를 직접 만드는 의지를 마지막까지 놓지 않았습니다. 추후 이를 SaaS로 확대하거나 같은 시스템으로 다른 버티컬 매체를 더 만드는 것도 핀치 팀 계획에 있었기 때문에 이를 위한 개발도 진행했습니다.

챗봇

콘텐츠기업이나 언론사에서 챗봇에 대해 이야기할때는 챗봇 형태를 갖춘 웹서비스 또는 메신저에서 작동하는 큐레이팅 서비스나 대화에 반응하는 스토리텔링 콘텐츠를 이야기할때가 많습니다. QUARTZ 가 챗봇 형태의 어플을 선보인 바 있고, 카카오도 챗봇 뉴스를 선보인 바 있습니다. 핀치 팀은 핀치클럽 멤버십의 기대에 걸맞는 콘텐츠 포맷 개발을 꾸준히 고민해 왔습니다. 대화형 인터렉티브 역시 후보중의 하나였습니다. 여기에도 장차 챗봇과 같은 기획이 활용될 수도 있었을 것입니다.

하지만 핀치 팀이 챗봇을 우선 도입한 영역은 이쪽이 아니었습니다. 팀의 생산성 향상을 위한 도구로서 챗봇을 우선 만들어 팀 구성원들이 직접 쓰기 시작했습니다. 인력과 시간은 제한되어있고, 운영해야할 이슈는 많았기 때문에, 챗봇을 통해 시간을 절약하여 더 많은 콘텐츠를 길어올리는 것이 챗봇 설계의 주된 목표였습니다.

콘텐츠를 검수하고 승인하는 에디터가 항상 사무실 컴퓨터 앞에만 앉아있을 수는 없는 일입니다. 크리에이터와도 만나야하고, 가끔은 취재나 인터뷰를 직접 진행하기도 합니다. 콘텐츠의 수정과 발행을 위해 항상 노트북을 들고다니는 것도 쉽지 않습니다. 그렇다고 컴퓨터 앞에 앉아있는 개발자에게 콘텐츠 첨삭 수정까지 봐달라고 하는 것도 곤란한 일입니다. 모바일 웹으로 이 문제를 해결할 수도 있을 것입니다. 특정 시스템에 접속해서, 정보를 확인한 뒤, 터치로 일을 수행하는 방법이 있습니다. 상당수 배달 중개 서비스가 모바일 앱 중심으로 작동하는 것처럼 말입니다. 하지만 미디어 콘텐츠 조직은 업무 커뮤니케이션에 채팅이 사용되는 비중이 압도적일 수 밖에 없습니다. 메신저 알림에 바로 답하기만 하면 되는 챗봇은 그런 이유에서 모바일 어드민보다 더 효율적이라고 평가되었습니다.

챗봇을 설계하는 것은 그리 어렵지 않습니다. 대화의 흐름을 프로그램으로 만들기만 하면 됩니다. 사용자가 ‘호출’을 하게 되면, 필요한 질문을 사용자에게 묻고, 받은 답을 토대로 일을 수행하는 식입니다. 이런 대화 설계는 30여년 전 유행했다는 텍스트 기반의 대화형 게임이 만들어질때와 거의 달라지지 않았습니다. 인터넷에는 너무나도 많은 챗봇 기획 요령 가이드가 널려있습니다. 슬랙과 같은 업무용 메신저 플랫폼이 보편화된 시대에는 봇이 텍스트뿐만 아니라 이미지나 액션 버튼을 제시할 수도 있어 다소 복잡한 정보도 봇에게 쉽게 전달할 수 있습니다.

핀치 팀은 에디터에서 텍스트를 모바일 환경에 맞게 재편집하는 것 외의 거의 모든 업무를 챗봇으로 수행했습니다. 예컨대 CMS에서 SNS에 노출되는 대표 이미지를 넣거나, 제목을 수정하는 것부터, 대기중인 글을 발행하는데에 이르기까지, 소셜채널의 새 글을 모니터링하는 것부터, 즉각 대응해야하는 기술적 문제를 알리는 것까지, 운영 업무의 상당 부분을 챗봇이 담당했습니다. 그 덕분에 핀치 에디터들은 이동 중에도 새 콘텐츠를 발행해 멤버십 독자들에게 전달할 수 있었고, 결제부터 고객문의까지 신속히 처리해야하는 사안도 챗봇의 도움을 받아 대응할 수 있었습니다. CMS부터 CRM시스템까지 넓은 범위의 업무를 챗봇이 담당하는 셈입니다. 챗봇은 핀치 CMS의 일부로 작동했습니다.

챗봇 시스템의 개발에서 중요한 것은 업무 프로세스를 유심히 관찰하여 어떤 종류의 챗봇이 필요한지 찾아내는 것입니다. 이후 계속 강조하겠지만, 그 또한 미디어조직의 개발자가 함께 해야하는 일이었습니다.

BM 개발

버티컬 미디어 서비스는 읽을 만한 콘텐츠, 읽고 싶은 콘텐츠를 마련하여 제공하는 것이 주된 비즈니스 모델입니다. 여기에 더하여, 유료 구독제 콘텐츠 플랫폼 서비스는 단순히 콘텐츠를 제공하는 것 이상으로 구독자와 좋은 관계를 맺고 유익한 경험을 선사하여 커뮤니티의 중심이 되는 것까지 고려해야합니다.

그래서 핀치 팀은 콘텐츠 제공을 위한 서비스를 만드는 것 이상으로, 커뮤니티를 구성하는데에 있어 필요한 서비스도 함께 개발했습니다. 핀치 서비스의 경우 콘텐츠 구독료 지불은 물론 크리에이터에게 직접 서포트를 할 수 있는 후원 기능도 제공했기 때문에 관련 결제기능을 추가로 개발했습니다. 콘텐츠를 넘어 오프라인 행사 티켓을 판매하는 서비스도 만들었습니다. 핀치 멤버십의 베네핏이 유료 콘텐츠 열람은 물론, 크리에이터와의 만남 이벤트부터 오프라인 페어, 강연에까지 확대되었기 때문입니다. 핀치 서비스 종료 결정 전에는 오픈된 글쓰기 플랫폼으로의 확장이 검토되었고, 이를 위해 CMS 시스템을 확대하여 블로그와 유사한 서비스를 개발하기도 했습니다.

제품의 확장, 회사의 성장에 따라 개발자가 만들어야 할 기능도 많아지고 돌보아야 할 서비스도 커져나가기 마련입니다. 앞서 언급했듯 핀치 팀이 만드는 제품은 콘텐츠 플랫폼이었지만 비즈니스는 본질적으로 구독제 멤버십 비즈니스였습니다. 콘텐츠를 편집하는 도구를 만드는 것, 콘텐츠를 제공하는 서비스를 만드는 것, 고객 결제 시스템을 만드는 것을 넘어, 비즈니스 목표에 따라 늘 기민하게 대응하며 다양한 BM을 실증하는 것 역시 유료 콘텐츠 플랫폼 서비스 / 유료 멤버십 서비스를 만드는 팀 개발자의 역할이었습니다.

인터렉티브 콘텐츠

데이터를 시각화하거나, 인터렉티브 요소를 가미한 스토리텔링 콘텐츠를 만드는 것 역시 디지털 저널리즘 조직에서 일하는 개발자의 몫입니다. 이는 시스템을 설계하는 일과는 사뭇 다른, 편집과 출판 디자인의 영역에 가깝습니다. 한때 HTML/CSS 로 웹페이지를 만드는 이들을 ‘웹마스터’ 로 부르거나 ‘UI개발자’로 부르거나, ‘웹디자이너’로 퉁쳐서 부르거나 ‘퍼블리셔’로 부르던 시절이 있었습니다. 프론트엔드 기술의 복잡성, 엔지니어링 수요의 급증, 직무의 전문성이 부각되면서, 이제 우리는 이들을 ‘프론트엔드 개발자’ 라는 이름으로 부릅니다. 웹디자인 역시 UI/UX에 무게가 실리면서 UI/UX개발자 라는 이름으로 부르곤 합니다. 그러한 시대적 변화에도 불구하고, 특정 주제와 이야기를 적절한 디자인과 기술을 가미해 인터렉티브 요소를 담아 전하는 ‘디지털 스토리텔링’은 프론트엔드 개발이나 UI/UX 디자인과는 사뭇 다른 전문적인 영역입니다. 저는 이것이 본질적인 ‘웹 퍼블리싱’ 영역이며, 이 일을 하는 이를 ‘디지털 스토리텔링 개발자’ 혹은 ‘디지털 스토리텔러 : Digital Storyteller (DS)’ 등으로 따로 부를만하다고 생각합니다.

인터렉티브 콘텐츠를 만드는 일은 콘텐츠가 노출될 환경과 스토리텔링의 주제를 함께 고려하여 코드를 써내려가는 일입니다. 사용자의 인터렉션, 그러니까 디바이스의 화면을 손가락으로 위아래로 쓸거나, 마우스 스크롤을 옮겼을 때, 텍스트를 어떻게 이동시킬지, 이미지를 어떻게 배치할지, 데이터를 어떤 방식으로 시각화할지, 디바이스의 특성에 맞는 애니메이션은 어떻게 구성해야 몰입도를 증가시킬지, 비주얼적인 반짝거림에 집중할지, 특정 구호의 호소력을 더 높일지 또는 긴 글 읽기에 집중할 수 있도록 도울지 등의 문제를 스토리의 주제의식, 소재, 타깃 주 독자 등을 고려하여 편집자와 함께 결정하고 구현하는 것이 텍스트 스토리텔링 개발자의 역할입니다.

한국 언론조직은 광고협찬 인터렉티브 콘텐츠나, 정부 지원과제 예산 확보를 위해 제작하는 콘텐츠를 제외하면 인터렉티브 콘텐츠에 대한 수요가 거의 없는 편입니다. 정부 지원금으로 인건비를 충당하거나 기업 광고비를 끌어오려는 요량으로 대충 짠 인터렉티브 콘텐츠를 만들기로 하고 이를 위해 잠깐 쓸 개발자만 찾아온게 관행이었습니다. 한때 진지하게 데이터저널리즘이니 인터렉티브니 하는 이야기가 한때 유행했지만 이건 이거대로 “돈만 까먹는다” 는 조직 내 저항에 시달리곤 했습니다. PV와 CPC/CPM 광고수익이 주된 인센티브 지표로 작동하는 한국 언론의 디지털부서 체제 하에서는 본격적인 인터렉티브 콘텐츠란 ‘스트레이트 기사에 비해 공이 많이 들어간다’ 또는 ‘그런거 할 때가 아니다’ 같은 취급을 받는 것이 당연할 것입니다.

그럼에도 불구하고, 방송사가 흔히 저렴하게 시청률 당길 수 있는 와이드쇼 대신 비싼 기획 다큐멘터리를 일부러라도 만드는 것 처럼, 디지털 기기 안으로 들어온 언론사라면 인터렉티브 콘텐츠나 데이터 시각화 콘텐츠를 꾸준히 만들어내어 제작 노하우를 내재화해야 합니다. 디지털 문명의 독자들은 글로 정보를 얻는 것 외에도, 더 다양한 방법으로 정보를 얻고자 하며, 디지털 기기는 단순히 글로 이야기를 전하는 것 이상으로, 더 많은 방법으로 메시지를 전달하고 몰입을 이끌어낼 수 있는 훌륭한 수단이기 때문입니다. 신문 지면을 모니터 화면으로 옮겨오는 시대는 1990년대에 이미 끝났습니다.

데이터 시각화를 잘 활용하는 언론사로 2021년에는 BBC를 들 수 있겠습니다.

Covid-19 in the UK: How many coronavirus cases are there in your area? - BBC News

인터렉티브 스토리텔링에 대한 투자는 뉴욕타임즈가 꾸준히 해오고 있습니다.

What I Saw in Syria - The New York Times

오랫동안 인터렉티브 스토리텔링에 신경써온 언론사로는 호주 공영방송 SBS가 있습니다. 호주 SBS는 시사 콘텐츠를 기획할 때 TV에 방영할 시리즈와 온라인에 배포할 인터렉티브를 동시에 제작하는 시스템을 갖추고 있습니다. 이보다 더 아름다운 읽기 경험은 없겠다 싶은, 예술에 가까운 스토리텔링을 보여줍니다. 디지털 노하우가 축적된 공영방송이라 가능한 일이었을 것입니다.

Junko’s Story: Surviving Hiroshima’s Atomic Bomb - SBS

핀치 팀이 만드는 인터렉티브는 QUARTZ 의 간결한 데이터 시각화와, 호주 SBS의 몰입도 높은 인터렉티브를 모델로 했습니다. 디지털 기기를 이해하고 디지털 스토리텔링을 이해하는 편집자, 디자이너, 일러스트레이터, 그리고 개발자가 함께 표현 기법을 고민하고 개발하는 방식이었습니다. 데이터시각화 콘텐츠는 이후 데이터만 모아 정보를 전달하는 Pinch Numbers 서비스로 피봇하여 구성되기도 하였습니다. 다음은 핀치에서 발행된 인터렉티브 스토리텔링 중 일부입니다.

인터렉티브 콘텐츠는 콘텐츠의 스토리텔링을 위해 별도의 CSS와 별도의 Javascript 코드를 넣어야 합니다. 이는 경직된 CMS 에서는 구현하기 어렵기 때문에 상당수 국내 언론사들이 인터렉티브 콘텐츠를 제공하기 위한 별도의 ‘호스팅’ 서버를 구성하곤 합니다. (이후 유지보수를 못하거나 서버비를 내지 못해 애써 만든 콘텐츠가 유실되는 일도 많습니다) 핀치 팀은 인터렉티브 콘텐츠의 코드를 일반 콘텐츠와 마찬가지로 쉽게 연결해 발행하고 배포할 수 있도록 CMS 설계 초기부터 고려했었습니다. 테스트 환경과 실서버 발행 환경에 충돌이 없고, 기존 사용자 경험과 이어지며, 유료 구독자에 한하여 인터렉티브 콘텐츠가 제공되는 것 또한 가능토록 구현했었습니다. 이질적이지 않은 것, 지속적으로 관리되는 것 또한 인터렉티브 콘텐츠를 만듦에 있어 고려해야할 사항입니다.

미디어 조직의 일하는 방법을 설계하기

지금까지 살펴본 내용을 모두 종합하면, 디지털 네이티브 미디어 조직에서 개발자가 만들어야 할 코드는 정말 많습니다. “사이트 하나, 앱 하나 그냥 뚝딱 만들면 되는거 아니야?” 라고 결코 이야기할 수 없는 고도의 복잡도를 지닌 시스템을 여럿 만들어야 합니다. 엔드유저 웹서비스든 모바일 개발이든 운영 레이어 개발이든 간에 기술 난이도 역시 일반 커머스기업이나 포털의 그것과 크게 다르지 않음을 알 수 있습니다.

콘텐츠 플랫폼을 만드는 개발자에게 요구되는 다른 직군과의 협업 및 커뮤니케이션의 깊이 또한, 여느 산업분야에 못지 않게 정말 많은 소통과 협력이 필요함을 알 수 있습니다. 말이 언론사고 미디어고 콘텐츠지, IT기업이나 데이터 중심 기업의 시니어 개발자 업무와 하나도 다르지 않습니다. 저널리즘/미디어 관련 조직이라 하더라도 ‘디지털 기기’에서 작동하는 ‘제품’을 만드는 조직의 일이기 때문에 그렇습니다. 즉 ‘제품’을 만든다는 면에서 IT기업의 그것과 하나도 다르지 않은 것입니다.

그저 위에서 시키는 일만 하는 개발자만 있어서는 지속 가능한 어떤 제품도 만들어낼 수 없습니다. 그저 주문한대로 납품받는 외주업체에만 맡겨서는 성장하는 제품을 만들어낼 수 없습니다. 제품을 넘어, 조직과 업무, 제품 설계, 시장 환경을 두루 살피는 역할이 조직 내에 요구됩니다. 일반 IT기업에 빗대면 CTO / CPO 레벨의 과제까지 돌아볼 수 있어야 미디어 조직 역시 디지털 시대에 맞는 기술과 운영 노하우를 축적할 수 있습니다.

종이 매체의 콘텐츠를 기자나 에디터 디자이너 일러스트레이터가 만들듯, 디지털 매체의 콘텐츠도 기자나 에디터 디자이너 일러스트레이터가 만듭니다. 종이 매체의 발행을 신문 조판과 교열 담당자, 윤전기사가 맡아왔듯 디지털 매체의 운영은 소프트웨어 개발자가 합니다. 여기에다, 개발자는 단지 매체 사이트의 운영을 너머 매체 조직이 일하는 방식 자체를 새로이 설계하는 일까지 주도적으로 이끕니다. 종사자 역시 디지털 기기를 활용해 일을 하고, 콘텐츠를 만들고, 독자의 데이터를 바탕으로 의사결정을 하기 때문에 거의 모든 일에 소프트웨어 개발자의 손길이 닿지 않은 데가 없습니다.

하필 개발자는 과거 윤전기사와 다르게 이 분야의 일이 아니어도 AI니 핀테크니 게임이니 포털이니 모빌리티니 등등 일자리는 많고, 그 때문에 몸값이 치솟은 상황입니다. 그래서인지 좋은 개발자를 모시는 일을 더욱 도외시하는 한국 언론사들이 많아졌다는 소식이 요즘 종종 들려옵니다. 저렴한 젊은 개발자 잠깐 계약직으로 쓰다 던져도 먹고사는데에 별 문제 없다고 여기는 언론사 경영진들도 꽤나 많습니다. 웹서비스나 모바일 서비스를 주력 제품이 아닌 부업 쯤으로, 자회사나 외주 업체가 맡아서 운영할 일 정도로만 취급하는 것이 한국 기성 매체조직 대다수의 형편입니다. CTO / CPO 직을 신설할 수도 없는, 디지털 세계에 존재하는 제품을 만든다는 자각을 할 수도 없는, 개발자를 동등한 동료로 여기지 않는, 경직된 조직 질서에서 벗어나지 못하는 것 역시 한국 기성 매체조직의 한계라 하겠습니다.

뉴욕타임즈는 자사 CMS에 사용하던 공동편집 에디터 ProseMirror 를 오픈소스로 공개한 바 있습니다. 기술 고도화에 있어 개발자들의 크레딧을 띄우고, 개발자 커뮤니티와 함께 성장하고자 하는 노력일 것입니다. 뉴욕타임즈는 자사에서 사용하는 CMS 도구와 에디터를 만든 개발팀이 뉴스룸의 일부임을 밝힌 바 있습니다.

정말 그렇습니다. 개발자가 뉴스룸의 일부이며, 일원인 곳이 있습니다. 개발자를 골방 전산실에서 대기하다가 컴퓨터 고쳐주는 사람으로 취급하는 것이 아니라, 뉴스 콘텐츠를 만드는 뉴스룸의 일원으로 함께하는 곳 말입니다. 게임회사에서 게임 작가 뿐만 아니라 개발자가 핵심 인원인 것처럼 미디어 콘텐츠 회사도 기자, 에디터, 비즈니스 영역과 함께 개발자도 함께 핵심 인원으로 일할 수 있습니다. 개발자와 함께 일하지 않는 조직과, 함께 일하는 조직은 디지털 공간에서 만들어내는 제품의 수준 자체가 다르고, 독자에게 제공할 수 있는 경험이 다를 것입니다. 한국은 여전히 전자가 건제하지만, 그 수명이 얼마나 유지될지는 저도 모릅니다. 종이신문은 폐지로 즉시 수출되고 있고, 대부분의 독자들이 디지털 기기로 콘텐츠를 소비하고 있으며, 디지털 기기 안에는 단순히 미디어 조직 외에도 넷플릭스같은 OTT, 유투브같은 동영상 서비스, 생활과 함께하는 수많은 서비스 어플과 게임들이 가득한 시대가 되었습니다. 10년 뒤 누가 사라지고 누가 살아남을지에 대해서는 답이 분명해 보입니다. “뉴스 미디어에서 제품 중심으로 사고하기”에 대해서는 저와 함께 일한, 정세윤 전 핀치 대표님의 글을 참고하십시오.

나아가 워싱턴포스트는 아예 웹의 표준을 만드는 W3C의 일원으로도 참여하고 있습니다. 자사의 주력 제품이 웹에서 작동하는 제품이고, 자사의 광고 비즈니스가 웹에서 작동하는 비즈니스이기때문에, 아예 공식적으로 월드 와이드 웹 거버넌스의 일원이 되기로 한 것입니다.

The Washington Post joins the World Wide Web Consortium - The Washington Post

디지털 네이티브 미디어 조직에서 개발자는 미디어 조직이 일하는 방식을 새로이 설계하는 사람입니다. 그 조직에는 광고 영업 사업을 담당하는 사람부터 콘텐츠를 만드는 기자나 에디터까지 모두 포함됩니다. 디지털 세계에 존재하는 미디어 제품을 설계하고, 비용구조를 결정하고, 성장을 위한 발판을 마련하는 사람이 바로 소프트웨어 개발자입니다. 모두가 모바일 기기만 바라보는 새로운 시대, 좋은 개발자를 확보하고 그 개발자가 잘 일할 수 있는 조직이 만드는 제품만이 시장에서 살아남을 것입니다. 3~6개월의 단타 성공만 쫓는 한국 스타트업 생태계, 기자가 ‘주’고 개발자가 ‘종’인 한국 재래매체에서는 기회가 많지 않을 것입니다. 5년뒤 10년뒤에는 어떤 콘텐츠/저널리즘/미디어 조직이 개발자와 함께 성장하게 될까요? 분명 자신이 새로이 서 있는 곳이 어디인지 자각하는, 감각있는 누군가가 그 자리를 차지할 것입니다.