문제를 효과적으로 해결하기: 퍼블리 제품팀의 스프린트 (이승국)

효율적인 프로세스 vs. 효과적인 프로세스

안녕하세요. 퍼블리에서 제품을 총괄하는 이승국입니다. 저는 퍼블리 제품팀의 업무 전반을 포괄하는 업무 프로세스를 말씀드리려고 합니다. 영화

영화 초반에 굉장히 강조해서 보여주는 장면이 있는데요. 주문이 들어간 다음 삼십 초 안에 햄버거를 생산하고 고객에게 전달하는 프로세스를 연습하는 장면이 오랫동안 강조됩니다.

'프로세스(process)'라 하면 '효율화'라고 많이 떠올릴 것 같아요. 그런데 잊으면 안 될 것이 있습니다. 맥도날드에는 이미 맛있는 햄버거, 시장에 잘 팔리는 햄버거를 만드는 공식이 있었어요. 당시 맥도날드에는 피클의 수, 머스터드 소스와 케첩 소스의 비율, 패티를 얼마나 익혀야 하는지 명확하게 공식화해두었고 그렇기 때문에 효율적으로 생산할 수 있었습니다.

제가 하고 싶은 얘기는 효율적이기 전에 먼저 효과적이야 한다는 것입니다. 피터 드러커(Peter F. Drucker)가 이런 얘기를 했어요.

효율적(efficiency)으로 일하는 것은
일을 적절히(the thing right) 하는 것, 
효과적으로(effectiveness) 일하는 것은
적절한 일을(the right thing) 하는 것

적절한 일을 찾는 게 우선입니다. 그런데 맥도날드와 비교한다면, 퍼블리는 아직 시장에서 잘 팔리는 햄버거 공식을 못 찾았습니다. 그래서 저희는 효과적으로 일하는 것이 중요하다고 생각했고, 퍼블리 스프린트라는 프로세스는 효율보다 효과에 치중되었다고 먼저 말씀드립니다.

퍼블리의 제품을 간단히 소개할게요. 제품군이 상당히 복잡합니다.(웃음) 저희는 제품군을 크게 콘텐츠 제작/관리, 콘텐츠 소비, 콘텐츠 판매 세 가지로 나눕니다. 여기에서 콘텐츠 소비는 독자의 읽는 경험, 콘텐츠 판매는 커머스 영역으로 생각하면 됩니다. 또한 장기적으로는 오프라인 행사 지원과 관련한 제품도 고려하고 있습니다. 디지털 콘텐츠와 오프라인 행사의 비중에 대한 고민도 많은데요. 저희를 오프라인 행사, 티켓 파는 비즈니스로 생각하는 분들도 있어요.

플랫폼 입장에서는 지금 웹만 하는데 앱까지 해야 할지 생각이 많고요. 오디오북에도 큰 관심을 품고 동향을 계속 주시하는 상태입니다. 미래에는 VR북도 가능성 있지 않을까 생각하고요.

비즈니스 모델은 명확하지 않은 상태입니다. 처음에는 크라우드 펀딩으로 시작했지만 장기적으로는 정기 결제 멤버십 모델*도 염두에 두고 있습니다. 이렇게 다양한 비즈니스 모델을 복합적으로 가져갈지, 한 가지 모델만 채택할지 고민 중입니다.

* 업데이트: 2017년 7월 20일, PUBLY 멤버십을 런칭했습니다.

사용자를 살펴보면, 독자와 저자, 내부 기획자/편집자가 있어요. 한 사용자가 동시에 여러 제품군을 사용하지 않기 때문에 각 제품군의 기능이 많이 부족하다고 느낄 수 있습니다. 예를 들어 독자 입장에서는 구매할 때 기본적인 검색 기능조차 없다, 콘텐츠를 읽을 때 밑줄 넣는 기능 정도는 있어야 한다, 이렇게 생각할 수 있죠. 하지만 전체 제품군이 이렇게 복잡한 상태이기 때문에 개별 사용자 입장에서 기본적인 기능이라고 하더라도 다 모으면 굉장히 방대합니다.

퍼블리 스프린트는 2주 동안 진행합니다. 처음 이틀 동안 무엇을 할지 정하고 구체적인 피처를 정합니다. 그다음 이틀 동안 다 구현하고, 5일 차에 내부에서 테스트하고요. 보통 여기까지 하면 금요일이잖아요. 금요일에 배포했다가 주말에 문제가 생기면 대응이 어렵습니다. 그래서 6일 차에, 그다음 주 월요일에 배포하고요. 7, 8, 9일 차 3일 동안 기존의 기술 부채나 기존에 만든 피처를 개선하는 작업을 하고 마지막 10일 차에 평가합니다.

스프린트 1일 차: 가장 중요한 문제를 찾고 솔루션 그리기

사실 1일 차가 가장 중요합니다. 팀 전원이 참여해서 우리가 지금 가장 중요하게 해결할 문제가 무엇인지 찾습니다. 반드시 전원이 참여해야 하는데요.

첫 번째로 전문가의 저주를 피하기 위해서입니다. 전문가의 저주란 어떤 특정 분야의 전문가가 자기가 잘하는 것만 하려다가 조직에서 필요로 하는 일을 하지 않아 결과적으로 성과를 내지 못하는 현상입니다. 정말 이 조직에서 필요한 일이 무엇인지 알고 그대로 추진하려면 다 함께 참여해야 합니다.

또한 어떤 일을 하기로 결정했을 때 그 맥락을 쉽게 알 수 있습니다. 이 회의에서 자세히 기획하는 게 아니라 사용자 스토리 정도만 나오고 구체적인 부분은 구현자가 세세히 알아서 기획해야 됩니다. 맥락을 모른다면 진행하기가 아주 어렵지요. 그래서 첫날에는 모든 사람이 참여합니다.

중단기 목표를 정하는 것으로 시작합니다. 실제 저희 스프린트를 예로 보여드릴게요. '어떻게 하면 저자가 빨리 편하게 프로젝트를 런칭할 수 있을까' 하는 목표를 정했습니다. 퍼블리의 사업 목표에서 도출되어 제품 단에서 해야 할 목표입니다. 목표를 수행하는 데 어떤 위험 요소가 있는지 다 함께 목록을 만듭니다. CMS(Content Management System)가 저자들이 쓰기에 편한지, 저자는 퍼블리 콘텐츠 생산 과정을 잘 이해하고 있을지 등등 여러 질문을 던지고요.

그다음으로 주요 사용자 별로 서비스 지도를 그리는데요. 저자와 독자가 중요한 사용자층이기 때문에 각 사용자가 퍼블리 서비스에 들어와서 어떻게 마지막 목표 지점까지 이르는지 지도를 그리고 각 단계별로 어떤 문제가 있는지 정의합니다. 위 사진에서 노란색 포스트잇을 참고해주세요. 

이 문제를 정의하는 부분이 매우 중요합니다. 일반적으로 사람들은 솔루션 중심으로 생각하는 것에 익숙합니다. 포드(Ford) 자동차 회사를 창업한 헨리 포드(Henry Ford)는 다음과 같은 말을 했죠.

사람들에게
무엇을 원하냐고 물었다면
더 빠른 말을 원한다고
이야기했을 것이다

어떤 문제에 대한 해결책은 무궁무진하고 저희 팀이 할 수 있는 최적의 해결책이 무엇인지는 팀내 각 전문가가 다양하게 생각해봐야 합니다. 하지만 사용자나 일부 결정권자가 제시한 구체적인 해결 형태를 그대로 구현하는 건 자동차를 만들 수 있는 팀을 가지고 더 빠른 말을 만드는 것과 같다고 할 수 있습니다.

문제 중심으로 생각해보려고 제가 '문제 회의'를 만들었어요. 여기에서는 문제만 얘기하라고 했는데, 저를 포함한 모든 사람이 계속 해결책 중심으로 이야기했습니다. 그래서 문제 중심으로 이야기하도록 문장 구조를 만들어봤어요. '(우리가) 어떻게 하면 (사용자가) ~할 수 있을까?'라고만 이야기 하는 것입니다.

아까 포드의 예를 이 문장에 끼워 맞춰 보겠습니다. '어떻게 하면 사용자가 더 빠른 말을 만들 수 있을까?' 사용자가 대신 말을 만들어줘야 하는 사태가 발생합니다. 그래서 조금 더 생각해보게 되지요. '어떻게 하면 사람들이 목적지까지 빨리 이동할 수 있을까?'라는 진짜 문제가 포함된 문장으로 이야기할 수 있게 됩니다.

실제로 이런 문제를 던졌습니다. 어떻게 하면 저자가 콘텐츠 판매 페이지를 더 빨리 작성할 수 있을까? 어떻게 하면 독자가 미리보기에서 구매 페이지로 더 많이 이동할 수 있을까?

처음에 작성한 핵심 질문과 연관된 문제, 각 단계의 문제를 강조하고 그중에서 우리가 이번 스프린트에서 가장 중요하게 다루어야 하고 가장 빨리 해결해야 하는 문제가 무엇인지 투표를 진행합니다. 투표를 진행하지만 다수결로 결정하지는 않아요. 투표는 여론조사 정도로 받아들이고 결정권자가 최종적으로 결정합니다.

1일 차 후반부에서는 해결책을 찾습니다. 이미 문제는 정의되었기 때문에 이렇게 진행할 수 있어요. 먼저 성과 지표를 정합니다. 목표를 명확히해야 각자 해결 방안을 스케치할 수 있기 때문입니다.

벤치마킹 등 자료 조사에 시간을 많이 쓰는데요. 벤치마킹이라고 하면서 그저 예쁘다고 따라하는 경우가 많은데, 그보다는 비슷한 문제를 다른 서비스는 어떻게 해결했는가 접근하는 것이 중요하고요. 꼭 저희와 비슷한 사업을 하는 서비스가 아니더라도 다양한 서비스로부터 비슷한 문제를 어떻게 해결하는지 찾습니다. 벤치마킹할 소스를 다양하게 찾아놓는 게 중요합니다.

한 시간 동안 각자 벤치마킹한 이후에 해결 방안을 스케치하는데요. 해당 해결책에 필요한 화면 구성과 문구를 포함해서 서너 쪽 정도 스케치합니다. 이 스케치를 마지막으로 1일 차의 일정은 모두 끝납니다.

스프린트 2~6일 차: 솔루션 채택/구현/배포

2일 차는 1일 차에 그려둔 해결 방안을 두고 투표를 먼저 합니다. 1차와 2차에 걸쳐서 투표하고 최종 결정은 다시 한 번 결정권자가 다수결과 상관없이 결정합니다. 해결 방안으로 제시된 여러 아이디어를 합치기도 하고요.

그다음 최종적으로 구현만 하면 되는 수준으로 세부 기획에 들어갑니다. 위 스케치는 실제 스프린트에서 최종 채택한 스케치입니다. 노란색 스티커와 빨간색 스티커가 각각 1차, 2차 투표였고, 파란색 스티커가 마지막 3차로 결정권자가 하는 투표입니다.

다 같이 모여서 최종적으로 결정된 해결책을 두고 사용자 스토리와 와이어 프레임(wire-frame), 텍스트까지 모두 확정합니다. 이제 3, 4일 차, 이틀만에 다 구현해야 해요. 지금까지는 다 함께 모여 '효과적'으로 일하는 시간이었다면, 지금부터는 '효율적'으로 각자 분업하는 시기라고 할 수 있습니다. 아무래도 이틀이라는 굉장히 짧은 시간 동안 개발해야 하기 때문에 MVF(Minimum Viable Feature)로 구현합니다. 보통 MVP는 많이 들으셨을 거예요. 비슷한 의미에서 지금 만드는 피처의 성과를 평가할 수 있는 최소의 공수만 들여 개발하는 것으로 이해하면 될 것 같아요.

모든 것을 시스템화하거나 자동화하지는 않아요. 개발이란 모든 것을 자동화하고 시스템으로 만드는 것이라 생각하기 쉬운데요. MVF로 구현하다 보면 사람이 직접 수동으로 개입해서 작업해야 하는 부분도 많습니다. SaaS(Software as a Service)나 라이브러리도 최대한 활용합니다.

그래도 각자 조용히 혼자서 일할 순 없고 어느 정도 의사소통이 필요한데요. 저희는 각자 자리에서 일어나서 이야기하는 스탠드업 미팅을 합니다. 이 미팅은 3, 4일 차에만 하는 게 아니라 스프린트 마지막 날까지 합니다. 1인당 최대 3분 동안 어제 한 일, 오늘 할 일, 어려운 일을 이야기하는데요. 긴 이야기는 미팅이 끝나고 필요한 사람끼리 다시 시간을 잡아 하도록 하고요.

이 시간을 통해 서로 무엇을 하는지 파악하고 또 도움을 주는 상황이 될 수도 있습니다. 나쁘게 생각하면 서로 감시한다는 느낌도 들겠지만, 이렇게 투명하게 업무를 공유하면 서로 신뢰가 높아지기도 합니다.

5일 차에 내부 테스트 및 최종 개선 작업을 하고 6일 차에 배포합니다. 문제가 있으면 또 수정을 해야겠죠.

스프린트 7~9일 차: 기술 부채 해결 및 제품 개선

7일 차부터 9일 차까지 사흘 동안 기술 부채를 해결하고 기존 피처를 개선합니다. 기술 부채는 퍼블리의 특수한 상황 때문이에요. 예전에 기술 기반이 갖춰지지 않은 상태에서 과도하게 피처 개발을 많이 해서 새로운 피처를 개발할 때 지속적인 걸림돌이었습니다. 이런 상황이 이자가 발생하는 것과 같고 '언젠가 원금을 갚아야 된다'라고 해서 기술 부채라는 말을 쓰는데요.

실제로 서비스도 제공하고 새로운 피처를 개발하면서 진행하다 보니 아주 오랜 시간을 필요로 합니다. 사용자 입장에서는 큰 변화가 없어 보이지만 사실 1년 전의 기술 구조와 현재는 완전히 달라졌습니다.

그리고 기존 피처가 아까 말씀드렸듯이 MVF라는 형태로 굉장히 부족한 수준이기 때문에 개선이 필요한데요. 물론 지금 이 스프린트 내에서 개발하는 피처는 아직 평가가 안 됐죠. 없어질 수도 있는 피쳐예요. 그래서 해당 스프린트에서 개발하는 피처는 개선 대상으로 삼지 않고요.

이전까지 만든 피처 중에 개선하기로 결정한 피처를 개선합니다. 또 없애기로 결정한 피처를 없애는 것도 이때 진행하게 됩니다. 기술 부채와 마찬가지로 쓸데없는 피처가 많이 생겨서 제품을 복잡하게 만드는 것을 제품 부채라고도 하는데요. 복잡도를 줄이려면 이런 불필요한 피처를 없애는 것도 매우 중요합니다.

스프린트 10일 차: 성과 평가

10일 차에는 6일 차에 배포했던 피처에 대한 성과를 평가합니다. 저희 목표는 이때 정량적으로 다 평가하는 게 목표였는데요. 서비스가 아무래도 유료 콘텐츠 비즈니스니까 트래픽(traffic)이 굉장히 적어요. 그래서 일주일 동안의 성과를 기반으로 한 정량적 평가는 어렵습니다.

정성적 평가가 많이 들어가거나 어쩔 때는 정량 평가 기간을 굉장히 길게 두기도 합니다. 한두 달씩 연장해서 나중에 평가하기도 하고요. 프로세스 자체에 대한 업무 평가, 서로 개선할 부분이 있는지 이런 부분도 같이 살펴보고 있습니다.

이런 과정을 2주를 주기로 계속 반복합니다. 당분간은 이런 프로세스를 계속 유지할 예정입니다. 다만 장기적으로 사업의 방향성과 제품 로드맵이 더 명확해진다면 효율이 점점 더 중요해지겠다는 생각이 들어요. 그럼 퍼블리 스프린트를 계속 해야 할까, 한다면 어떤 방향으로 가야 할까 고민이 많고요.

구성원의 수가 더 많아지면 어떻게 할지도 고민입니다. 다 같이 일하는 프로세스를 유지하게 되면 사람이 늘어날수록 의사소통 비용이 급격히 커질 테니까요. 결국 팀을 쪼개야 할 텐데, 계속 교차 기능적(Cross-functional)으로 갈지, 전문 영역대로 분업하는 구조로 갈지 고민 중입니다.

또한 주요 기술 부채가 곧 해결되면 이후 기술 부채를 해결하던 시간을 어떻게 써야 할까 고민도 많이 하고 있습니다. 그런데 저희가 스프린트를 계속 진행하면서 개선해야 할 MVF가 계속 쌓이잖아요. 이걸 개선하는 데 시간을 많이 쓰게 될 것 같아서 그 기간은 아마 그대로 있지 않을까 생각하고 있습니다.

퍼블리의 첫 번째 스프린트 다시 보기

2017년 3월 6일에 처음 퍼블리 스프린트를 도입했습니다. 그때 '콘텐츠를 더 많이 생산하려면 어떻게 해야 할까'라고 목표를 정하고, '저자가 많아야 한다', '펀딩을 많이 성공해야 한다' 이런 질문을 남겨놨어요. 그리고 서비스 지도에서 저자가 서비스로 유입되는 단계를 개선 대상으로 선택했습니다. 

이 단계에 대해 각자 해결 방안을 스케치하고 성과 지표는 주간 저자 지원자 수 등으로 정해서 최종적으로 해결책을 결정한 다음 아래와 같이 구현했습니다.

여기서 저자가 지원서를 작성하는 단계를 MVF의 구체적인 예로 들 수 있겠습니다. 이 단계를 저희가 직접 구현하지 않고 타입폼(Typeform)이라는 외부 솔루션을 사용했습니다.

참고로 제가 퍼블리 스프린트를 계획할 때 지대한 영향을 끼친 책이 두 권 있어요. 「린 스타트업(Running Lean)」의 저자 애시 모리아가 최근에 쓴 「스케일링 린(Scaling Lean)」과 구글 벤처스의 제이크 냅이 쓴 「스프린트(Sprint)」가 굉장히 큰 영향을 미쳤습니다.

Q & A

원래 제품 관리자가 결정권자는 아니잖아요. CPO(Chief Product Officer)니까 결정할 수 있죠?(웃음) 한 사람이 단독으로 결정할 때 발생하는 문제는 없는지요? 

문제 상황이라면, 제가 내린 최종 결정을 일부 또는 전체가 납득하지 못하는 경우겠죠. 하지만 만장일치가 아니라면, 다수결을 따르든 제가 결정하든 이런 문제가 생길 수 있습니다. 제가 아이디어를 혼자 내고 독단적으로 결정하는 것이 아니라 팀 내에서 나온 아이디어와 팀 내에서 나온 해결책을 제가 선택하는 구조이고, 그 과정을 모두 공개하기 때문에 웬만한 경우는 설득하는 것 같아요.

사실 다수결과 다른 결정을 내리기가 쉽지는 않아요. 다수결대로 하고 편하게 넘어가고 싶다는 유혹을 많이 느낍니다. 그래서 실제로 제 의견 대신 다수결을 따른 적도 있지만, 백이면 백 후회하게 되더라고요. 그래서 왜 사람들이 다수결로 선택했는지 많이 생각해본 다음 제가 하려는 방향으로 설득하려고 노력합니다. 그래서 다수결과 다른 방향으로 갈 때는 좀 더 깊게 대화하고 설득하는 과정을 거칩니다.

물론 이 과정에서 합리적으로 설득할 수 없는 경우도 있어요. 서로 생각하는 목표 지점이 다를 때입니다. 회사의 비전과 구성원의 비전이 잘 일치하면 이상적입니다만, 실제로는 어려운 문제입니다. 특히 저희 같은 초기 스타트업은 미션이 명확할지 몰라도 비전은 명확하지 않잖아요. 제품 로드맵이 불명확하다고 이야기한 것처럼요. 그렇게 되면 결국 각자의 의견은 각자의 비전에만 부합하고 회사의 비전과는 맞지 않을 수 있는 거죠.

결국 제게 결정권이 위임된 것은 회사의 비전과 잘 합치하는 결정을 내릴 것으로 기대한다는 의미라고 생각합니다. 그리고 이런 과정을 통해 팀원의 다양한 비전을 확인하고 회사의 비전을 조율하는 과정을 거치고 있어요. 흔히 '디스어그리 앤드 커밋(disagree and commit)'이라고 하죠. 저희 팀 구성원은 이런 부분에서 이해도가 상당히 높습니다.

2주라는 스프린트 기간이 강한 인상을 남겼나 봐요. 질문이 많은데요. 2주 스프린트가 반복되면서 생기는 번아웃(burn-out)은 어떻게 해결하시는지요?

MVF식으로 최소화하는 것도 번아웃을 줄이기 위해서예요. '빡센' 스케줄 같아 보여도 초과 근무는 거의 없습니다. 그리고 5일 차에 내부 테스트할 때 하루 종일 테스트만 하는 건 아니니까 그 시간이 어느 정도 버퍼(buffer)로 작용해요. 기술 부채를 해결하는 사흘도 일부분은 스프린트 피처 개발을 위한 버퍼로 쓰기 때문에 진행 규모가 큰 피처는 그런 버퍼 기간을 활용합니다. 저희가 2017년 3월에 시작해서 얼마 안 되었어요. 번아웃이 올지 안 올지 저도 잘 모르겠습니다.(웃음)

한 번의 스프린트에서 해결 못할 규모는 어떤 식으로 구현하는지요?

스프린트 주기에 맞춰 무조건 쪼갰어요. 버퍼 기간을 활용해서인지 아직까지 큰 어려움은 없습니다. 다만 버퍼로 남겨둔 시간을 과도하게 써야 했던 적은 있어요. 일정을 예측할 때 어떤 문제가 있었고, 어떤 부분을 수정해야 했나 사후에 평가하는 시간을 둡니다.

방금 설명하신 스프린트 내용대로 진행하면 해결하지 못한 문제가 계속 백로그에 쌓이잖아요. 그러면 같은 내용의 문제 찾기가 반복될 확률이 높은데 어떻게 해결하는지요?

그래서 문제 정의를 하는 첫 단계가 중요합니다. 저희는 중단기 목표를 2, 3개월에 한 번씩 바꾸는데요. 한 번 바꿀 때마다 위험 요소 목록을 만들고 서비스 지도에 문제를 정의합니다. 이때 시간이 굉장히 많이 걸려요. 이후 목표가 바뀌기 전까지는 기존에 작성해둔 위험 요소와 문제 목록을 재활용합니다. 그렇게 해서 남는 시간을 스프린트의 다른 부분에 더 투자합니다.

하루 동안 문제 해결을 고민하면서 자기 아이디어를 내잖아요. 그렇게 되면 아이디어에 애착을 많이 가지는 거 같아요? 아니면 그냥 툭 가볍게 던지게 되는 거 같아요?

제 개인적으로 말씀드리면, 애착을 갖게 돼요. 실제로는 하루만 고민해서 스케치를 하는 것이 아니라, 전부터 생각하던 것을 쏟아내는 경우도 있거든요. 아무래도 오래 고민한 생각일수록 더 애착이 생기긴 합니다. 그렇게 고민이 길수록 더 잘 채택되기도 하고요. 하지만 막상 투표에서 선택을 많이 못 받으면 그 순간 마음 편히 포기하게 되더라고요.

그리고 아이디어를 실행하는 데에는 더 많은 사람이 엮여 있잖아요. 실제로 구현해야 하는 사람, 운영해야 하는 사람이 있지요. 결국 아무리 시간을 써서 아이디어를 냈다고 해도, 추후에 다른 사람들이 써야 할 시간도 충분히 존중하기 때문에 결과는 깨끗이 인정할 수 있습니다.

퍼블리 제품팀의 다른 엔지니어로부터 이야기를 듣고 싶은데요. 차새날 엔지니어의 이야기를 들어보겠습니다. 자신의 아이디어가 채택이 안 된 경우가 있죠? 그 과정에서 서로 의견은 충분히 나누었다고 생각하세요?

차새날 많죠.(웃음) 서로 자신의 아이디어를 설득하려고 논리를 펼치고, 긍정하고 수긍하고 동의하는 과정을 거쳐요. 그러다 보면 앞으로 더 잘해야겠다는 생각, 의지가 막 불타오르고요. 그렇게 진행하고 있습니다.

퍼블리의 핵심 제품은 플랫폼인가요, 콘텐츠인가요? 물론 둘 다 중요하겠지만 제품 관리자 측면에서 더 집중하는 것은 뭔가요?

퍼블리는 플랫폼 회사라고 이야기하고 싶습니다. 저희 회사 조직이 크게 콘텐츠팀, 제품팀으로 나눠져 있는데요. 제품팀의 기술을 기반으로 콘텐츠팀이 콘텐츠를 직접 생산해 시장에 내놓는 것이 아니라, 이 전체 조직이 플랫폼으로 작용하는 것입니다. 저자는 콘텐츠를 만들고 독자는 골라 읽는, 이 모든 과정을 연결하는 사업이라고 이해할 수 있습니다.

퍼블리의 저자는 자신의 전문 분야에서 내공을 갖추었죠. 하지만 대부분의 저자는 전문적으로 글을 쓰는 사람이 아닙니다. 이런 저자가 독자가 돈을 내고 볼 만한 글을 쓰도록 뒷받침하는 부분은 사실 기술로만 풀어내기는 매우 어렵습니다. 흔히 생각하는 글 쓰는 기술이나 편집 같은 부분뿐만 아니라 관계 형성에 있어서도 콘텐츠팀이 매우 강력한 역할을 합니다.

유료 글을 써본 경험이 적은 저자의 경우 어떻게 구매자가 만족할 글을 쓸 수 있을지 심적으로 많은 부담을 느끼는데요. 콘텐츠팀은 글의 방향성에 대한 논의를 함께하는 등 저자가 더 확신을 가지고 글을 쓰는 환경을 만들어줍니다. 미디엄 같은 해외의 대표적인 콘텐츠 플랫폼 서비스가 기술적으로는 뛰어날지 몰라도, 콘텐츠 생산과 유통 부분에서 저희가 오히려 더 많은 경험을 쌓고 있다고 자신합니다.