모든 미디어에는 개발자가 있어야 한다
<핀치>를 만들 때 꽤 빈번하게 들었던 질문이 있다.
왜 개발자가 팀에 있죠?
논리는 이렇다.
미디어에서 콘텐츠를 생산하는 데에 개발자가 항상 있어야 할 필요는 없다. 어차피 글을 매일매일 쓰는 것은 기자들 아닌가? 개발자가 필요한 콘텐츠를 매일 만들 것도 아니고. 필요한 콘텐츠에 대해서만 외주를 주는 식(외주라고 하면 그나마 양반이다. 대부분 인턴을 쓰거나 재능기부로 퉁치면 안되냐고들 하던데)으로 협업하면 되고, CMS 등 디지털 툴은 워드프레스를 쓰거나, 다른 기타 유료 플랫폼을 구매해서 충분히 크리에이터가 사용할 수 있다. 유지보수도 어렵지 않을 뿐더러 광고는 구글 Ad를 연결하기만 해도 알아서 해 주는데 대체 무엇에 개발자를 쓰겠다는 것이냐?
물론 나는 위의 주장에 단 한 마디도 동의하지 않는다. 그리고 디지털 시대의 미디어 업계 종사자라면 누구나 위와 같은 주장을 펼치면 안 된다고 생각한다. 성공적인 디지털 전환을 이룬 미디어와 그렇지 않은 미디어의 가장 큰 차이는 바로 조직, 그리고 그 조직을 이루는 사람이다. 예를 들어, <Washington Post>는 자사의 콘텐츠 퍼블리싱 플랫폼인 Arc Publishing 팀에 100명 이상의 개발자를 두고 있으며 CTO는 마이크로소프트 출신이다. <Washington Post>는 Arc Publishing 뿐만 아니라 하드코딩이 필요한 다양한 포맷의 인터랙티브 콘텐츠에 아낌없이 개발자를 투입하며 Arc publishing만으로는 만들 수 없는 새로운 포맷을 연이어 선보이고 있다.
기자들이 새로운 기술을 배워서 적응하기만 하면 디지털 혁신이 이루어질 수 있다는 나이브한 생각이 조금이라도 남아 있다면 부디 접어주길 바라며 미디어에 기술 전담 인력이 필요한 이유를 얘기한다.
기자는 개발자가 될 수 없거나 되어서는 안 된다
될 수 없다는 부분부터 짚어보자. 좋은 기자가 갖춰야 하는 자질과 좋은 개발자가 갖춰야 하는 자질은 완전히 다르기 때문이다. 이 둘은 완전히 다른 전문직종이다. 좋은 기자는 발군의 취재능력과 글쓰기능력을 갖추고 굳건하게 언론 윤리와 직업의식을 사수할 수 있어야 한다. (적어도 그래야 한다고 배웠다.) 하지만 당연하게도 개발자가 갖춰야 할 개발자만의 직업의식을 제외한 나머지 세 가지는 개발자의 능력과 아무 상관이 없다.
기자들에게 새로운 시대에 발맞춰 각종 언어와 코딩을 가르치는 붐이 한 때 일었고, 이 붐은 꽤 꾸준한 경향으로 자리잡았다. 하지만 어디까지나 기자가 개발을 배우는 이유는 개발자의 작업 방식과 개발자가 위치한 맥락을 이해하기 위해서이지 직접 개발을 하기 위해서는 아니어야 한다. 진료는 의사에게, 약은 약사에게 만큼이나 당연한 말인데 굳이 강조하는 것도 참 새삼스럽지만 인력이 모자라고 예산이 부족하다는 이유로 기자에게 실제 개발 태스크까지 맡기면 다음과 같은 엔딩을 맞게 된다.
취재시간이 절대적으로 부족해진 기자가 좋은 취재를 하지 못한다. 기사 내용이 부실해진다. 부실한 콘텐츠라서 안 팔린다.
매우 단기간에 개발을 배운 기자가 어찌저찌 뭔가를 만들어내도 여기저기서 오류가 빵빵 터진다. 웹페이지가 제대로 굴러가지 않는다. 노력은 많이 쏟아부었지만 아무도 보지 못하는 슬픈 콘텐츠가 된다.
취재도 개발도 둘 다 잘 해보려다가 번아웃이 되어버린다. 결과물을 내지 못하고 커리어의 사춘기를 겪는다.
취재도 잘하고 개발도 훌륭하게 해내서 멋진 콘텐츠를 만드는 엔딩… 이 있다면 좋겠지만, 아쉽게도 국내, 국외를 통들어 그런 경우를 보지 못했다. 훌륭한 리치 포맷 콘텐츠의 크레딧을 살펴보면 모두 개발자, 기획자, 디자이너, 기자가 분리되어 있다. 보셨다면 제보 바람.
다음. 되어서는 안 된다는 부분이다. 위의 1번 엔딩과 관련된 이야기다. 결국 콘텐츠의 핵심은 콘텐츠가 함유하고 있는 내용 그 자체다. 아무리 훌륭한 포장을 한다고 해도 부족한 내용을 채울 수는 없다. 미디어의 성장을 위해서 콘텐츠 크리에이터 인력은 필수다. 한 사람이 조직에서 여러 가지 역할을 맡을 수도 있다. 하지만 그것은 전문 직종이 아닐 때의 얘기다. 기자와 개발자는 완전히 다른 계열의 전문 직종이고, 이 두 가지를 동시에 할 수 있는 대단한 사람이 드물게 있다고 하더라도 당연히 한 가지 직종에만 집중하게 하는 것이 훨씬 더 좋은 결과를 낳는다. 특히 전혀 다른 종류의 끈기를 요구하는 일이기 때문에 그렇다.
콘텐츠가 웹에 올라가는 이상,
개발자는 (당연히) 항상 있어야 한다
어떻게 (정말 대체 어떻게) 개발자가 없어도 웹사이트가 아무 문제 없이 돌아갈 거라는 자신감을 가질 수 있는지 모르겠다. 웹사이트는 굉장히 정교하고 복잡하며 섬세한 구조물이다. 종류와 상관없이 웹 페이지에서는 수십, 수백 가지의 스크립트가 돌아가는 게 기본이다. 이 스크립트들은 서로 맞물려서 돌아가는 톱니바퀴 같은 것이라서 대체로 하나만 어긋나도 와르르 작동을 멈추게 된다.
그럴 때, 당신은 개발자 없이 이 문제상황을 해결할 수 있는가?
아닐 가능성이 매우 높다.
미디어 조직 전체에 개발자가 한둘 있는 수준이 아닌, 콘텐츠 생산 단위별로 개발자가 있어야 하는 이유는 이렇다. 포맷의 혁신을 고려할 때도 ‘항상 개발자가 있는지’와 ‘필요할 때 개발자를 불러야 하는지’는 엄청난 차이를 낳는다. 콘텐츠 크리에이터가 새로운 아이디어를 떠올렸을 때 그것이 기술적으로 실현 가능한지, 어느 정도의 리소스가 드는 일인지 바로 검토하고 피드백을 줄 수 있는 개발자가 팀 안에 있어야만 꾸준히 시도를 할 수 있다. 자문을 구할 동료가 없다면 비정상적으로 많은 개발 리소스가 들어가는 아이디어를 구상하고는 왜 얼핏 보기엔 간단해 보이는 아이디어가 이렇게 실현이 어려운지에 대해 불평하게 된다. (그렇기 때문에 개발 프로세스의 이해를 위해 개발을 공부하는 것은 매우 권장한다는 것이다. 일의 크기를 가늠하는 데에 큰 도움이 되니까.) 기획 및 취재 단계부터 콘텐츠의 아웃풋을 고려해야 하는 시대다. 내놓을 수 있는 결과물의 종류에 따라 구비해야 하는 콘텐츠의 밑재료도 달라지는 것은 당연한 일.
콘텐츠 퍼블리싱 툴을 꾸준히 최적화할 사람이 있어야 한다
노 코드 CMS, WYSIWYG 등 개발자가 없어도 웹 콘텐츠 제작/퍼블리싱 툴을 사용할 수 있다는 메시지는 플랫폼 사업자들의 단골 홍보 소재다. 솔깃할 수밖에 없다. 인력을 늘리느니 어느 정도 괜찮은 값을 내고 개발자 없이 구동할 수 있는 툴을 구매한다면 모든 문제가 해결될 것만 같다. 하지만 실제로 그런 마법같은 일은 일어나지 않는다. 근본적인 이유는 어떤 툴이든 각각의 미디어 팀과 크리에이터가 처한 상황에 최적화되어있지 않기 때문이다. 원하는 기능과 구색을 갖추려면 최소한 수백 가지 툴 중 여러 개를 조합할 줄 알아야 하고, 필요한 부분은 고칠 줄 알아야 한다.
최적화 작업은 절대로 단기간 외주로 의미있는 결과를 낼 수 없다. 흥미롭고 서글픈 사례가 언론진흥재단의 통합 CMS다. 자체 CMS를 개발하거나 구축할 여력이 없는 언론사들이 사업에 참여했지만, 정작 이 CMS는 입찰을 통해 미디어 환경에 대한 이해가 크게 없는 것으로 보이는 (결과를 놓고 보면 그렇게 말할 수밖에 없다) 외주 업체가 개발했다. 그 결과 기사 예약발행 기능조차 없는 59억원짜리 CMS가 탄생했다. 차라리 그 59억으로 기본적인 콘텐츠 관리 기능을 갖춘 프로덕트의 라이센스를 확보해 이를 기반으로 한국 언론사의 환경에 맞는 최적화 작업을 거쳤다면 훨씬 나은 결과물을 만들 수 있었을 것이다.
미디어 조직에서의 기술 최적화란 미디어 조직이 가진 고유한 관습을 툴에 반영하고 이 관습이 디지털화되었을 때 발생하는 바틀넥을 제거하는 작업이다. 디지털 전환이 기존에 가진 모든 프로세스를 뒤엎는 고통스러운 일이 되어야 할 필요는 전혀 없다. 미디어 조직에는 파괴적 혁신이 필요하지 않다. 조금씩 체질을 개선해 나가는 꾸준한 최적화 작업이 필요할 뿐이다. 거기에 끊임없이 쏟아지는 독자의 새로운 니즈에도 부응해야 하니 사실상 디지털 최적화는 끝이 없는 일이다. 이를 전담해 미디어 조직이 맞부딪힌 막막함을 조금씩이라도 없애줄 사람이 필요한 거다.
어떻게 함께 일할 것인가
물론 미디어 조직 내 개발자의 필요성을 절실히 공감하는 조직에서조차 개발자를 확보한 경우는 매우 드물다. 어렵사리 ‘모셔’ 온다고 해도 이탈율이 높다. 미디어 조직과 그 구성원이 개발자와 일할 준비를 전혀 하지 않은 채로 졸속 ‘혁신’을 위해 사람을 뽑았을 때 생기는 비극이다. 개발자를 미디어 조직에 포함시키고 정착시키기 위해서는 최소한 다음 조건을 충족해야 한다.
계약직으로 뽑지 말라. (너무 당연해서 첨언할 것이 없다.)
개발자의 경력과 직군에 걸맞은 대우를 제시하라. 솔직히 말하면, 개발자의 경력에 걸맞는 대우보다 더 매력적인 조건을 붙여야 마땅할 것이다. IT 회사에서 다른 IT 회사로의 이직이 아닌, 완전히 다른 성질의 조직에 합류하게 만들려면 당연히 무엇이라도 혹하는 게 있어야 할 것 아닌가? 미디어 조직은 이미 개발자에게 매력적인 일터가 되기 힘든데, 처우도 불합리하면서 네임밸류만 강조해봤자 별 소용이 없다.
기자들이 개발자의 상사처럼 굴지 않도록 한다. 탑다운이 아닌 서로 의견을 주고받을 수 있는 수평적인 의사결정구조를 보장하라.
개발자가 속한 디지털 전담 조직을 장기적으로 운영하라. 태스크포스나 임시 팀, 특별 팀이 아닌 상시 존재하는 조직이 되어야 한다.
인터랙티브 기사 몇 개, 새로운 포맷의 기사 몇 개와 같은 식의 업무만 주지 말라. 기술 혁신이 없는 단순 구현 업무는 개발자에게 전혀 매력적이지 않다. 개발자가 고민하고 성장할 수 있는, 기술 측면에서 challengable한 업무 목표를 정하자.
개발자가 제시하는 새로운 방식, 툴, 프로세스를 실무에 적극적으로 수용하려는 태도가 필요하다. 무엇이든 ‘그렇게 하면 안 된다/그렇게 할 수 없다’부터 튀어나오는 미디어 조직만큼 혁신을 적극적으로 거부하는 업계도 참 찾기 힘들 거라고 생각한다. 관행, 중요하다. 나름 가지고 있는 자부심과 ‘곤조’도 모두 중요한 것, 알고 있다. 하지만 그게 언론사의 생존을 훼방 놓고 있다면 언젠가는 내려놓아야 할 유산이 아닐까?
직접 개발을 하진 않더라도 개발과 개발자에 대한 최소한의 이해는 갖춘다.
혁신 조급증, 이제 그만
결국 미디어 조직이 디지털 혁신에 끊임없이 실패하는 근본적인 이유는 디지털 혁신이 하루아침에 모든 문제를 해결해 줄 수 있는 마법 같은 무언가라고 생각하기 때문이다. 스스로 아무 것도 알아보지 않고 그저 외주 개발자에게 무언가를 만들어 내라고 호령해서 나온 ‘인터랙티브’ 기사 하나를 혁신이라고 자랑스럽게 말하는 모습은 그만 보고 싶다. 미디어 조직의 디지털 혁신은 반드시 장기적인 관점에서 접근해야 하며, 이 관점에 기반해 좋은 개발자가 적극적으로 팀의 의사결정과정에 참여하고 콘텐츠의 개발을 리드할 수 있어야 한다.
