출처 : https://pixabay.com/ko/vectors/%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%A8%B8-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%EC%BD%94%EB%93%9C-1653351/

'실력 있는 개발자를 어떻게 채용할 수 있을까? 언론사 조직 안에서 개발자와 어떻게 잘 협업할 수 있을까?'는 언론사가 당면해온 해묵은 고민거리 중의 하나입니다. 소프트웨어 개발자의 역할 모델에 대한 이해가 부족했던 레거시 언론사들은 '디지털 전환'이라는 숙명적 과제 앞에서, 개발자들의 위상을 점차 재발견해 가고 있는 듯합니다. 이젠 실무진의 고민을 넘어서서 핵심 리더급에서도 이 문제를 해결해야 하는 중차대한 이슈로 부상하고 있다는 느낌을 받게 됩니다.

이 글 또한 최근 만난 언론사 간부와의 대화로부터 비롯됐습니다. 아직 현장 기자들은 개발자들이 왜 디지털 전환에서 중요한 위상을 가질 수밖에 없는지 체감하지 못하는 경우가 많을 겁니다. 하지만 개발자들의 역할을 빼놓고 더이상은 디지털을 논할 수 없다는 사실만큼은 언론사 간부들도 부인하지 못하는 명제가 됐다고 생각합니다.

문제는 너무 뒤늦게 깨달았다는 점이죠. 이미 업계에서 실력을 인정받는 개발자들은 플랫폼 기업들의 개발자 구인 경쟁 과정에서 한껏 몸값을 높여 이직한 경우가 많았을 겁니다. 아니면 보다 도전적인 스타트업으로 넘어가 충분히 인정을 받는 분위기에서 진취적으로 제품 개발에 매진하는 경우도 많을 것이고요. 지금은 실력을 갖춘 개발자를 언론사들이 고용하고 싶다고 해도 좀체 뽑히지 않는 수렁에 빠져 있는 것으로 보이기도 합니다. 그들에게 매력적인 연봉 테이블을 제시하기도 벅찬 상황이 된 겁니다.

수 년 전 '왜 개발자에게 기자보다 더 높은 연봉을 줘야 하는가'라고 물어보는 언론사 임원을 만난 적도 있는데요. 그러한 레거시 미디어의 리더십이 현재와 같은 상태를 낳았다고 보는 것이 저의 진단이기도 합니다.

오늘은 이 해묵은, 그래서 좀체 고쳐지지 않는 문제를 다시 지적하기 위해서 이 글을 쓰려는 것은 아닙니다. 조금이라도 해법을 찾아보고자 노트북을 연 것입니다. '어떻게 하면 언론사가 좋은 개발자를 고용할 수 있을까? 또 그들과 어떻게 하면 생산적으로 협업할 수 있을까'에 초점을 맞춰 제 조언까지 곁들여 보겠습니다.

언론사 개발 업무 경험한 지인 2명 인터뷰

위 해법을 제안하기 위해 저는 언론사에 근무 중인 2명의 개발 담당 기자 2명을 인터뷰했습니다. 한 분은 방송사에 한 분은 신문사에 현재 재직 중입니다. 구체적인 실명을 밝히지 못하는 점 이해를 부탁드립니다. 자사 부서장이 알게 되면 불편해질 수도 있다고 하더군요.

먼저 신문사에 근무 중인 개발 담당 기자의 이야기부터 들어보시요. 코멘트가 조금 길더라고 전혀 삭제하지 않고 여기에 옮겨놓겠습니다.

도전적인 개발 프로젝트를 계속하고, 외부에 알려야 합니다. CMS나 홈페이지 개편, 인터랙티브 콘텐츠 제작 등은 개발자에게 도전적인 과제가 아닙니다. 그마저도 개발은 외주에 맡기도 유지/보수만 하는 경우도 많죠. 개발자들이 모를 리 없다고 생각합니다. 개발자는 직업 특성상 끊임 없이 공부해야 하는 만큼, 업무를 통한 능력 계발을 중시합니다. 개발자 구인구직 시장에서는 실무 프로젝트 경험이 곧 능력을 증명하는 방식이기도 하고요. 최신 기술을 적용한 사례를 지속적으로 만들고, 이를 개발자들에게 '기술에 관심이 있고, 계속해서 적용하려 하는 회사'라는 증명으로 알려야 합니다. 개발자 컨퍼런스 등을 후원하거나, 참석해 사례를 발표하는 것도 방법일 수 있을 것 같네요.
최신 기술을 적극 도입해야 합니다. 언론사는, 굳이 입사해보지 않아도 '10여년 전 기술로도 무리 없이 돌아가는 곳'임을 겉으로만 봐도 알 수 있습니다. 개발자에게 회사는 '배움이 있어야 하는 곳'입니다. 기술이 없는 곳에 개발자는 가지 않습니다.
연봉 역시 중요합니다. 개발자에게 이직은 곧 연봉 인상을 뜻합니다. 파격 대우도 서슴지 않는 IT 기업들의 행보를 드물지 않게 접하셨을 겁니다. 사명감이나 논조 등을 입사 기준으로 삼는 언론사가 이들을 속물처럼 여기지 않고, 아낌 없는 대우를 해야 합니다. 그것이 그들의 문화이기 때문입니다.
그럼에도 불구하고 언론사는 개발자에게 매력 있는 직장이기 어려울 수 있습니다. 저널리즘 마인드가 있는 개발자, 콘텐츠 제작에 관심이 많은 개발자를 찾기는 쉽지 않기 때문입니다. 그래서, 저널리즘 마인드가 있거나 콘텐츠 제작에 특기가 있는 이들을 개발자로 키워야 합니다.

이 분의 얘기를 제가 한 단어로 요약하면 '개발자의 성장 지원'이라고 할 수 있을 겁니다. 개발자는 개발자로서 첫발을 내딛는 순간부터 끊임없는 자기계발을 목표로 삼게 됩니다. 더 많이 실험하고 더 많이 실패하면서 또 스스로 성장하고 학습하는 과정을 당연한 숙명처럼 받아들입니다. 당연히 더 도전적인 기술을 활용해보고 싶고 배워보고 싶어 합니다.

하지만 언론사들은 기술 분야에서 더 높은 성취감을 개발자들에게 제공할 만큼 높은 과제를 부여하지 않습니다. 쉽게 말해 개발자 입장에선 동기부여가 되지 않는 것이죠. 위 지인이 언급했다시피 10여년 전의 기술을 바탕으로 '디지털 전환'과 '디지털 저널리즘'을 외치고 있는 것이 대부분 우리 언론사들의 현실입니다. 새로운 기술을 습득해 적용해 보고 싶어하는 개발자들의 '욕망'이 발현되기 어려운 조직구조입니다.

반면 포털이나 플랫폼 기업들은 최신 기술을 자체 개발하거나 활용해 사회적 문제, 언론의 문제를 해결하는데 주저하지 않습니다. 조금은 극단적이긴 하지만 기술로 세상의 모든 문제를 해결할 수 있다고 확신하는 분들도 적지 않습니다. 개발자로서 끊임없는 도전 욕구를 자극하는 플랫폼 기업의 조직 분위기와 달리, 새로운 기술을 배워도 써먹을 곳을 용인하지 않는 언론사의 내부 분위기는 좋은 개발자가 들어설 공간이 없다고 보는 것이 타당하지 않을까 합니다.

출처 : https://knightfoundation.org/articles/the-present-and-potential-of-ai-in-journalism/

이번엔 방송사에 근무하는 데이터 저널리스트의 이야기를 들어보겠습니다. 저는 이 분의 조언 중에 해결 방안 부분만 발췌했습니다.

개발자가 리딩할 수 있는 부서가 필요합니다. 일례로 뉴욕타임스 개발팀을 들 수 있죠. R&D 전담 부서인데 저널리즘을 위한 다양한 실험을 진행합니다. 개발자의 시선에서 언론사 시스템은 바꿀 수 있는 게 많습니다. 저만 해도 ‘데이터’ 관점에서 봤을 때 내부의 다양한 리소스(취재자료, 기사 등등)를 DB화 하고 api를 만들어서 내부에서 편리하게 쓰고 싶지만 그걸 지원해줄 수 있는 부서가 없어서 답답하거든요. 근데 이런 건 다른 부서에서 지원해줄 수 있는 게 아니라 저널리즘에 관심있는 개발자가 모인 팀에서 자발적으로 해줘야 서로 윈윈할 수 있습니다.
그리고 개발자와 저널리스트 사이에서 매니징을 할 수 있는 매니저 역할도 필요하다고 봅니다. 국내 기자들과 개발자 사이의 커뮤니케이션 간극은 엄청납니다. 서로 오해가 생기고 갈등이 생길 수밖에 없는데요. 그걸 완화할 수 있는 매니저가 있으면 개발자들의 오해와 언어를 이해하고 원할한 커뮤니케이션이 될 수 있습니다.
무엇보다 중요한 건 개인적으로 개발자에게도 저널리스트 직함을 줘야 한다고 봅니다. 이건 직함의 문제보다 시선과 문화인데요. 기자만 저널리즘을 한다는 생각을 버려야 하고 이들을 기자로 대해줘야 개발자들도 그들만의 방식으로 저널리즘을 구현하고 언론사에 매력을 느낄거라고 봅니다. 이달의 기자상도 기자협회 등록된 사람만 수상하니 함께 고생해서 좋은 기사 만들어도 개발자, 디자이너는 소외감을 느낄 수밖에 없습니다.

언론사 내 조직 문화의 획기적 변화를 요구하는 목소리입니다. 근본적이고 본질적인 문제 제기라고 할 수 있을 겁니다. 언론사 조직 내 개발자의 위상, 커뮤니케이션 방식에 대한 변화 없이는 좋은 개발자가 언론사로 들어오진 않을 것이라고 보는 시각입니다.

기자들은 서운해 할 수도 있겠지만 디지털 전환이 생존의 핵심 과정으로 들어선 지금, 기자와 개발자, 디자이너, PM(프로덕트 매니저)의 위상은 동등합니다. 동등해야 하고요. 더이상 펜/방송 기자 중심으로 언론사가 돌아가야 한다는 인식에서 벗어나야 합니다. 또한 기자들만이 핵심 부서의 요직을 독차지 해야하고 주도할 수 있다는 오만함도 내려놓아야 합니다. 그렇지 않으면 신문과 전통적인 방송 모델만 계속 지속할 수밖에 없게 될 것입니다.

뉴욕타임스 R&D팀이 진행중인 프로젝트들. 

이 분이 지적했다시피, 저널리즘 관련 개발 업무가 주축이 되는 부서에 펜 출신 기자가 부서장으로 임명되는 인사는 자제돼야 합니다. 언론사 내부에 만연한 '펜 기자 만능주의'부터 포기해야 한다는 것이죠. 특히 언론사 내 고위 임원급들이 유념해야 할 지적입니다. 프로덕트 개발 과정과 접근법에 대한 이해가 부족한 펜 기자 출신 간부는 '개발의 장애물'로 인식될 가능성이 높습니다. 더 높은 커뮤니케이션 비용을 초래할 것이고 조직의 불화를 불러일으켜 개발자들의 이탈을 조장하게 될 것입니다.

일단 개발자들이 안전하고 자유롭게 그들 문화가 지지받는 조직 구조 안에서 역동적으로 개발에 전념할 수 있도록 조직 차원의 대안을 제시해야 한다는 것이죠. 그런 조직 하나가 어쩌면 더 실력 있는 개발자들을 채용할 수 있는 초석이 되지 않을까 생각이 됩니다.

또 한 가지 간과하지 않아야 할 부분은 개발자와 기자 간의 가교 역할을 해줄 수 있는 직군으로서 프로덕트 매니저의 채용과 육성을 주문한 점입니다. 사실 국내 언론사들 안에서 기획자라는 이름으로 평가절하되고 있는 프로덕트 매니저는 그 역할의 중요성에도 제대로 된 대접을 받지 못하고 있습니다. 그러다 보니 그저 '기획안을 문서화하는 사람', '프로덕트 목업 그리는 사람' 정도로 인식되고 말죠. 이들이 좋은 개발자와 훌륭한 저널리스트들의 의사소통을 전담하게 된다면, '번역의 공백'에 따른 소통 부재와 갈등을 상당 부분 해소할 수 있지 않을까 합니다.

해외 언론사도 다르지 않았다

사실 이러한 고민은 비단 국내 언론사만의 문제는 아닙니다. 해외 언론사들도 겪었거나 겪고 있는 문제입니다. 이 문제를 슬기롭게 해결한 언론사들은 디지털 전환에 성공적으로 안착한 경우라고 할 수 있을 겁니다. 이 문제에 대해서는 괜찮은 글이 있어서 제가 번역을 해두었습니다. 곧 다시 공개해 드리도록 하겠습니다.

언론사 리더들에게 드리는 개인적인 조언들

어쩌면 요약하고 정리하는 것일 수도 있습니다. 6가지로 축약했지만 실은 이보다 더 많긴 합니다. 앞선 인터뷰와 위에서 살짝 언급해드린 해외 사례의 조언들을 종합해서 제 이야기를 풀어보도록 하겠습니다.

(1) 프로덕트 매니저를 채용하고 그들의 성장을 도와주세요 :

출처 : https://medium.com/@sundve/the-need-for-product-management-in-media-fe02cddf5ec3

최근 로이터 저널리즘 연구소 보고서를 보면, 프로덕트 매니저의 중요성에 대한 인식이 크게 높아지고 있다는 사실을 관찰할 수 있습니다. 다만 그 역할의 이해가 낮은 것이 문제이긴 하지만요. 프로덕트 매니저는 기자 경력으로도 전환할 수 있는 중요한 직군 중 하나입니다. 프로덕트적 사고에 친숙한 역할 모델로, 저널리즘에 대한 깊이 있는 이해와 데이터 기반의 분석 방법, 개발 과정에 대한 폭넓은 인식을 바탕으로 프로덕트로서의 저널리즘을 성공적으로 완성시킬 수 있는 직군이자 직무입니다.

아직 국내에서는 이처럼 다재다능한 '프로덕트 매니저'가 언론사에 많지 않은 게 현실입니다. 결국 언론사 안에서 이분들을 육성하고 지원하는 정책이 뒷받침돼야만 합니다. 기자와 개발자가 서로의 이해가 부족한 상태에서 현재 의사소통하면서 좋은 프로덕트를 만들어가는 건 갈등을 초래할 확률만 높일 뿐입니다. 훈련받아온 과정이 다르고 과정과 목표가 다르기 때문입니다. 이를 완충하고 보완하는 역할로서 프로덕트 매니저를 내부에 채용하거나 성장시키는 것이 일단 개발자와 협업하는데 도움이 될 것이라고 생각합니다.

(2) 여러 직군이 공동으로 협업하는 독립 프로젝트 조직을 구성해 보세요. 단 조직장에 처음부터 기자를 임명하지 마세요 :

개발과 관련한 모든 문제를 한꺼번에 풀어내려는 욕심을 조금은 내려놓으시는 게 좋을 겁니다. 일단 성공적인 사례를 협업을 통해서 완성시키는 실험을 반드시 먼저 시작해볼 것을 제안합니다. 단 전제가 있습니다. 디지털 저널리즘 관련 프로젝트를 수행하되, 반드시 여러 직군이 공동으로 참여하는 팀을 꾸리셔야 합니다. 그리고 조직장은 될 수 있으면 기자를 배제하는 것이 좋습니다. 물론 기자들도 천차만별인지라 디지털 이해도가 높은 디지털 프로젝트를 여러 차례 수행한 경험을 갖추고 있다면 예외일 수 있습니다. 하지만 이런 정도의 경험을 갖추지 못한 기자를 조직장으로 앉히고 프로젝트를 주도하도록 내맡긴다면 실패할 확률은 상당히 높아질 것입니다.

기자 출신 임원들의 눈에는 '그래도 한국에선 기자가 가장 능력 있는 집단'으로 비칠 수 있을 겁니다. 아닙니다. 기자들보다 훨씬 빼어난 능력과 실력을 갖춘 이들이 다른 직군에서 높은 퍼포먼스를 내는 경우가 다반사입니다. 다시 말씀드리지만 기자는 모든 영역에서 늘 최상의 성과를 뽑아내는 만능 엘리트가 아닙니다. 이 생각을 버리지 않는 이상 좋은 개발자를 조직 안에 붙잡아두기는 어려울 겁니다.

중요한 것은 린스타트업의 문법처럼 수용자들의 핵심 문제에 천착해 저널리즘의 접근법으로, 기술을 동원해 풀어내는 것입니다. 상의하달의 폭포수 모델에 익숙한 기자들은 이 과정 자체를 주도할 만큼 개발 과정에 대한 이해도가 높지 않은 경우가 더 많습니다. 기자를 무시해서가 아니라 기자가 잘하지 못하는 영역에 기자들을 만능 재능꾼처럼 활용해서는 안된다는 말씀을 드리고 싶은 겁니다.

(3) 개발자들의 언론사 기술 블로그 운영을 장려하세요

인터뷰에 응해줬던 지인이 강조한 바처럼, 언론사의 기술 블로그를 적극적으로 운영하고 자랑해보세요. 뉴욕타임스의 개발 블로그 NYT Open, BBC의 R&D블로그를 참고해 보세요. 이 블로그가 외부의 개발자들에게 얼마나 매력적일 수밖에 없는지를 경험하게 되실 겁니다. 기술 블로그를 운영하게 되면 해당 언론사가 어떤 기술을 어떤 방식으로 활용하는지를 알림으로써 기술친화적인 문화를 갖추고 있다는 걸 홍보하는 효과를 얻을 수 있습니다. 그 노하우를 대외에 알림으로써 기술기업으로서의 면모를 과시할 수도 있습니다.

사내 개발자들이 적극적으로 기술 블로그를 운영할 수 있도록 독려하고 지원해 보세요. 그 블로그를 타고 더 좋은 개발자를 모실 수 있는 기회를 얻게 될 것이라고 생각합니다. 단, 블로그에 채워넣을 기술적 도전과 실험 사례가 없다면 있으나마나 할 겁니다. 결국 새로운 기술을 도입하고 내부 문제를 해결하는데 활용할 때에만 이 블로그 운영이 유효할 것이라는 점을 말씀드립니다.

(4) 신규 기술로 내부 문제를 해결할 수 있는 야심찬 프로젝트를 제안하세요.

3번과 이어지는 이슈입니다. 이미 언론사들은 디지털 뉴스 생산 분야에서 여러 어려움들을 겪고 있습니다. 기사를 작성해서 카피한 뒤 CMS 안에서 편집하고, 이미지를 찾아 붙이는 등 생산 과정에서부터 여러 기술에 의존하고 있습니다. '왜 이렇게 불편하냐', '품이 너무 많이 든다', '시간을 줄일 수 있는 방법이 없냐' 등등의 불만도 수차례 제기됐을 겁니다. 이런 문제를 새로운 기술로 해결해 보는 시도를 적극적으로 도와주셔야 합니다. 예산을 배정하는데도 인색하지 않아야 할 겁니다.

여기에 그치지 않고, 기술의 힘을 동원한 보다 야심찬 프로젝트를 제안해 보세요. 특히 AI를 활용한 저널리즘 사례들을 학습해서 과감하게 시도해 보세요. 나이트재단의 최근 자료를 보면, 언론사들은 기사 거리나 속보를 발견하기 위해 AI 기술을 활용하는 경우가 늘어나고 있었습니다. 또 내부 기자 인원 부족으로 커버하지 못하는 출입처나 보도 영역을 기계가 대신해서 생산하는 '기사 생산' 영역에도 적극적으로 AI를 도입하고 있습니다. 비용감소에 활용하는 건 너무나도 당연한 것이고요. 이처럼 고도화한 기술을 활용해 내부 문제를 해결하는데 기술을 적극적으로 활용해 보시기 바랍니다. 개발자들의 심장을 뛰게 하는 야심찬 프로젝트라면 더더욱 추천해 봅니다. 그리고 그 성과를 다시 기술 블로그를 통해 알려보세요.

(5) 애자일 문화를 배우고 이해하기 위해 노력해보세요

어쩌면 애자일이라는 용어를 처음 듣는 분도 있을지 모르겠네요. 아예 아래 도표를 보여드리는 게 좋을 것 같습니다.

위키피디아는 이렇게 소개합니다. "애자일 개발 방법론은 계획을 통해서 주도해 나갔던 과거의 방법론과는 다르게 앞을 예측하며 개발을 하지 않고, 일정한 주기를 가지고 끊임없이 프로토 타입을 만들어내며 그때 그때 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발해 나가는 adaptive style 이라고 할 수 있다."

쉽게 말해, 가볍게 반복적으로 사용자 피드백을 바탕으로 자주 업그레이드 하면서 개선하는 방식이라고 할 수 있습니다. 세밀한 기획안을 만들어놓고 그 계획대로 흐트러짐 없이 개발하는 폭포수 모델과는 정반대의 프로세스입니다. 마감 시간을 중심으로 기사의 완결성을 추구하는 기자 생산 절차와도 완전히 다릅니다. 애자일 문화를 이해하지 못하는 기자들에게 개발 주도권을 넘겨준다는 것은 그래서 위험할 수밖에 없습니다.

특히 애자일 방법론은 협업을 핵심 가치로 삼습니다. 기사 작성 과정에서 협업 자체에 익숙하지 않은 기자들에겐 애자일 방법론은 그 자체로 장벽입니다. 철저한 문서/ 계획 기반 방법론으로 기민한 대응을 주저하게 하는 기존의 개발 및 프로젝트 추진 방식과도 거리가 있습니다. 반면 개발자들은 이러한 애자일 문화를 당연하게 받아들이는 경향들이 점차 늘어나고 있죠. 이런 차이를 인정하지 않으면, 또 이런 방법론을 존중하지 않으면 좋은 개발자들과 함께 일할 수 있는 기회는 줄어들 수밖에 없을 겁니다.

혹시나 하여, 애자일 선언문 링크를 여기에 남겨둡니다.

(6) 의사소통 방법, 특히 '이 문제를 해결하기 위해 무엇을 도와줄까요?'라는 질문에 익숙해지세요.

이제 마지막 조언입니다. 개발 절차를 충분히 숙지하고 있다손 치더라도 아주 세밀한 영역까지 리더나 기자가 개발 사항을 다 알기는 어려울 겁니다. 그러다보니 매번 '언제까지 가능하지? 반드시 지켜야 해!'라는 주문만 반복하게 됩니다. 이건 개발자들을 스트레스의 함정으로 밀어넣는 소통방식입니다.

기자든, 조직 임원이든, 개발자들과 일할 때에는 '현재 무엇 때문에 어려움을 겪고 있는지, 어떤 부분을 도와주면 해결될 수 있는지'를 더 많이 물어봐야 합니다. 질문 자체가 바뀌어야 한다는 거죠. 개발자들이 개발과정에서 부딪히게 되는 어려움 중에는 기술적 문제도 존재하겠지만 사내 조직의 역학 관계도 존재합니다. 주도권 다툼으로 개발 관련 접근권을 허용하지 않는다든가, 의도적으로 데이터 지원을 회피한다든가 하는 경우가 빈번합니다. 결과물의 QA 과정에서 기자들의 도움이 반드시 필요한데 이를 외면하는 경우도 적지 않을 겁니다. 개발자들과 함께 한다면, 이런 어려움을 해결해주는 역할을 도맡아줘야 합니다.

개발자들에게 해당 문제를 해결하기 위해 무엇을 도와줄 수 있느냐가 자주 물어보셔야 합니다. 사실 개발자에게만 해당하지는 않습니다. 적어도 언론사 내 조직의 리더급이라면 후배 기자들에게도 이러한 질문을 던지는데 익숙해져야 한다고 생각합니다.

정리하며

앞선 두 분의 인터뷰를 진행하면서 동일하게 들었던 푸념같은 한 마디가 있었습니다. "바뀌지 않는다는 건 알지만..."입니다. 앞선 모든 조언들이 도움이 됐으면 하는 바람이긴 하지만, 레거시 미디어의 조직 문화 안에서 이 조언들이 수용된다는 게 얼마나 어려운지 저도 잘 알고 있습니다. 저 또한 여러 직장을 거치면서 비로소 체할 수 있었기에 하루아침에 변화하지 않을 것이라는 점도 잘 이해합니다. 물론 저 또한 "바뀌지 않을 것이라는 걸 잘 알고"는 사람 중 한명입니다. 그럼에도 이 글을 쓰는 건 조금이나마 그 변화에 작은 기여라도 해보고 싶어서입니다. 만약 본인이 바꿀 생각이 없다면, 바꾸고자 하는 사람들에게 힘이라도 실어주셨으면 하는 바람을 전하며 글을 마무리 하겠습니다.