PMF 높은 글쓰기와 그로스해킹

2020/05/28 - [코딩하는 공익] - 업무 자동화 스크립트 짜주다가 국정원에 적발당한 썰

2020/05/28 - [코딩하는 공익] - 크롤러를 이용해 우체국 등기우편을 자동으로 정리해 보자

2020/05/28 - [코딩하는 공익] - 생각보다 파급력이 너무 컸다

2020/05/28 - [코딩하는 공익] - 생각보다 파급력이 너무 컸다

2020/05/28 - [코딩하는 공익] - 절필

2020/05/28 - [코딩하는 공익] - 노동청 공익과 노동부 출장 (1)

2020/05/28 - [코딩하는 공익] - 노동청 공익과 노동부 출장 (完)

2020/05/28 - [코딩하는 공익] - 노동청 공익과 행안부 출장

2020/05/28 - [코딩하는 공익] - 노동청 공익과 또 행안부 출장

2020/05/28 - [코딩하는 공익] - 예술에 대한 복잡했던 심정

2020/05/28 - [코딩하는 공익] - 혁신 못 하는 조직의 특징

2020/05/29 - [코딩하는 공익] - 공무원을 위한 정부혁신 가이드 - PDI 관점 (1)

2020/05/29 - [코딩하는 공익] - 공무원을 위한 정부혁신 가이드 - PDI 관점 (2)

2020/05/29 - [코딩하는 공익] - 공무원을 위한 정부혁신 가이드 - PDI 관점 (完)

2020/05/29 - [코딩하는 공익] - 공익근무 중에 논문을 써도 될까?

2020/05/29 - [코딩하는 공익] - 공익근무중에 논문을 몇 편이나 쓸 수 있을까?

2020/05/29 - [코딩하는 공익] - KAIST 출신 AI석사가 악플에 대처하는법

2020/05/29 - [코딩하는 공익] - KAIST 출신 AI 석사가 스팸메일에 대처하는법

2020/05/29 - [코딩하는 공익] - 책 팔아서 차도 사고 집도 사고 결혼도 할 수 있을까?

2020/05/29 - [코딩하는 공익] - AI 석사 취급이 받고 싶었던 공익

2020/05/29 - [코딩하는 공익] - 입대 전엔 대한의 아들, 입대 후에는 느그아들

2020/05/30 - [코딩하는 공익] - KCD2019 강연 후기 (1)

2020/05/31 - [코딩하는 공익] - KCD 2019 강연 후기 (2)

2020/06/01 - [코딩하는 공익] - PMF 높은 글쓰기와 그로스해킹

 

코딩하는 공익 국내도서 저자 : 반병현 출판 : 세창미디어 2020.04.27 상세보기

 

야근까지 해가며 열심히 글을 써 본 적이 있는가? 오늘 밤에도 누군가는 듀가 다가온 보고서를 처리하기 위해서, 또 누군가는 새로운 제안을 하기 위해 기안서를 작성하느라 오늘도 무거운 눈꺼풀을 간신히 지탱하며 타자를 두드리고 있을 것이다. 그런데 그 글이 항상 읽는이의 마음을 움직일 수 있는 것은 아니다. 왜 그런 것일까? 왜 고생해서 작성한 오류 없는 문서가 무용지물이 되어버리는 걸까

 

이 글은 지금까지 필자와 협업을 했던 몇 명의 개발자들 덕분에 용기를 얻어 작성하게 되었다. 그들과 함께하는 프로젝트는 저혈압 치료에 특출한 효능이 있었으며, ‘인내력’이라는 소양에도 맷집이라는 것이 붙을 수 있다는 사실을 깨닫게 해 줬다. 실무만 하는 사람은 그렇게 일해도 문제가 없다. 하지만 비전공자와 소통해야 하는 입장인 사람은 그렇게 하면 안 된다.

 

당시 필자에게 지옥과도 같은 나날을 선물했던 꽉 막힌 사람들을 설득하고야 말겠다는 집요한 마음으로 이 글을 준비했다. 독자 여러분들은 단락을 읽다가 혹시 필자와 생각이 일치한다면 그 부분은 굳이 정독하지 않고 넘어가도 좋다. 같은 이야기를 반복하는 것으로 보여 지루할 수도 있기 때문이다.

글이란 무엇인가

 

독자 여러분들도 필자와 마찬가지로 학창시절 국어시간에 ‘문학의 삼대 요소’ 따위의 어려운 용어를 들으며 멍 때린 경험이 있을 것이다. 필자는 글을 “생각을 활자의 형태로 고정하는 행위”라고 정의한다. 누군가의 시냅스에 잠시 머물러 있다 조만간 휘발되어 사라질 정보를 타인이 열람 가능한 정적인 형태로 재가공할 수 있다는 사실은 실로 낭만적인 일이다. 

 

이에 공감하는 사람이 이 좁은 우주에 도대체 얼마나 많은 것인지, 글과 문서는 우리 사회의 지식과 정보체계의 핵심적인 구성요소가 되어버리고 말았다. 그래서 우리는 끊임없이 글을 읽어야만 하며 새로운 글을 작성해 일터와 학계에 제출해야만 하는 슬픈 세상을 살아가고 있다. 심지어 연인이나 친구와의 연락도 카톡을 통해 글로 주고 받는다. 아아, 활자를 떠나 살 수 없는 가련한 지식인들이여.

 

우리는 매일 글을 쓰면서 살아가고 있다. 그리고 그 글 조각들에는 모두 저마다의 힘이 담겨 있다. 본지는 IT관련 잡지이므로 지나치게 감성을 자극하는 비유는 생략하고 바로 본론으로 들어가 보도록 하겠다. 글에 어떤 힘이 담겨 있는지는 아래 세 가지 요소가 결정한다.

  

1. 누가 작성한 글인가 (저자)

2. 어떤 생각을 작성한 것인가 (주제)

3. 누구에게 생각을 전달하고 싶은가 (독자)

 

아래 사례를 한 번 곱씹어 보기 바란다. 

 

  (1) 요리사가 

  (2) 닭을 맛있게 튀기는 비법을 

  (3) 요리 경험이 부족한 자취생들에게 전달하기 위해;

 

  작성한 문서

 

위 문서에는 어떤 힘이 깃들어 있을까? 아마도 쉽게 맛있는 요리를 만들 수 있도록 정보를 전달하는 힘이 담겨있지 않겠는가?

 

필자와 독자, 우리 개발자는 문제를 해결하는 사람이다. 그렇기에 개발자가 작성한 문서에는 문제를 해결하는 힘이 담겨 있다. 코드가 그렇고, 코드 속의 주석이 그렇고, 도큐멘테이션이나 RFP가 그렇다.

 

개발자가 작성하는 문서는 대체로 저자의 정체성과 주제가 명확한 편이다. 하지만 세 번째 요소인 독자에 대한 고려가 부족한 경우를 많이 봤다. 본 글에서는 PMF(product market fit)에 대한 개념을 소개하고, 개발자가 작성한 문서가 PMF를 달성하면 얼마나 큰 파급력이 발생하는지를 필자의 경험을 토대로 이야기해 보려고 한다.

개발자가 작성한 문서의 성격

 

우리 개발자라는 족속은 문제를 해결하는 데 대부분의 시간을 소모하는 사람들이며 간단하고 명확한 지시를 선호한다. 개발자는 지식과 주장을 논리적으로 컴퓨터에게 전달하는 것으로 문제를 해결하고 새로운 제품을 만드는 사람이다. 컴파일러는 논리에 문제가 없는 코드는 뱉어내지 않고 잘 받아들인다. 아주 기특하게도 말이다. 

 

그러다 보니 개발자들은 간혹 논리에 문제가 없는 의견을 전달하면 사람도 반드시 설득할 수 있을 것이라고 생각한다. 기술적으로 완벽한 이야기를 문서로 작성해 전달했는데, 이를 보고도 고개를 갸우뚱하는 사람을 만나면 당혹감을 느낀다. 마치 문제 없는 코드를 줬는데도 에러를 일으키는 컴퓨터를 만났을 때처럼 조금씩 혈압이 오르기도 한다.

 

입어 줄 사람에 대한 고려가 부족한 채로 만들어진 옷은 천조각 이상의 가치를 가질 수 없다. 잘 풀려 봐야 걸레로 사용되고 말지 않겠는가. 주인으로부터 사랑받는 옷을 만들고 싶다면 재단을 시작하기에 앞서 그것을 입을 사람의 체형과 치수, 선호하는 디자인 등을 반드시 고려해야 한다. 글을 쓰는 과정 또한 비슷한 점이 많다. 누가 이 문서를 읽을 것인지, 그 사람에게 알맞는 글은 어떤 형태일지에 대한 깊은 고민이 녹아들어가야 한다. 

 

코드에 삽입되는 주석이나 동료 개발자와 소통을 위해 작성한 개발문건 또는 논문 등 기술적 요소를 다루는 문서는 그 성격상 문서를 작성한 개발자와 비슷하거나 그 이상의 도메인 지식을 갖춘 사람이 읽을 것을 전제로 작성하게 된다. 그러다 보니 작성할 때 아주 편하다. 기술적인 오류 없이 논리에 맞게 순서대로 정보를 전달하면 되기 때문이다. 

 

하지만 그런 문서는 개발자가 아닌 사람이 읽기 곤란하다. 내용에 설득력이 부족하거나 오류가 있어서가 아니다. 논리가 복잡하고 어려워서도 아니다.

 

첫 번째 문제는 용어 자체가 낯설게 느껴진다는 것이다. 개발자들이 끼리끼리 모여 놀기 때문에 쉽게 망각하는 사실이 있는데, 이 세상 사람들 중 절대 다수는 개발자가 아니기 때문에 우리와 달리 일상에서 개발 관련 용어를 사용하지 않는다. 우리들 사이에서 편하게 쓰는 언어로 풀어 적은 글을 관련 지식이 없는 사람이 접하면, 마치 온갖 처음 보는 소스를 잔뜩 끼얹은 음식을 접한 것 처럼 거부감을 느낄 수 있다는 점을 잊지 말아야 한다. 

 

두 번째 문제는 기능보다는 작동 원리를 중심으로 서술하는 경우가 많아 문서 전체를 조감하는 데 있어 진입장벽이 높다는 뜻이다. 개발자는 새로운 기능을 개발하거나 기존의 기능을 개선하는 과정에 있어서, 결과보다 과정을 고민하는 데 더욱 오랜 시간을 투입하는 종족이다. 우리가 까만 창을 띄워두고 하는 일이 대부분 문제를 해결하는 방법을 탐구하는 일이기 때문에 어찌 보면 자연스러운 일일 것이다. 하지만 이 습관에 따라 작성된 문서는 설명하고자 하는 대상이 무엇이고 어떤 기능을 수행하는지를 빠르게 훑어보는 데 적합하지 못하다.

 

의사결정권이 있는 경영진이나 회사의 제품에 대해 관심을 가지는 비개발자는 개발자가 작성한 문서를 읽으면서 설명하는 대상이 (1) 어떤 기능을 수행할 수 있고, (2) 어떤 장단점이 있으며 (3) 비용은 얼마나 들어가는지에 대하여 알고 싶을 것이다. 그것을 만드는 방법이 아니라. 이를 토대로 수익성을 고민해 보거나 도입 또는 투자를 결정하기 위해서. 이런 의도로 개발자와 소통하고 싶은 사람에게 있어 프로덕트가 어떤 방식으로 작동하는지는 큰 고려 대상이 아니다. 어쩌면 전혀 관심이 없을 수도 있고.

  

 

상대의 입장에서 생각해 보자

 

소통하고자 하는 상대방의 도메인 지식에 따라 내 분야의 자부심을 내려놓을 줄도 알아야 진짜 장인이다.

 

최근 인문계 출신들이 가장 열광하는 IT 키워드들을 구글에 검색해 보라. 필자가 글을 작성하는 현재 시점에는 딥러닝이나 블록체인 등의 용어가 적절하겠다. 굉장히 많은 블로그가 검색 결과로 나올텐데 그들을 한번 유심히 살펴 보기 바란다. 일반인이나 비전공자를 위한 글인 척 하고 있지만 막상 본문을 읽어보면 자신이 가진 지식을 뽐내기 바쁜 사람들이 많은 것 같다. 애석하게도 게시물 제목에 붙어 있는 ‘쉬운’, ‘일반인도 이해할 수 있는’이라는 수식어가 설득력을 갖추지 못 하는 것이다.

 

정말로 일반인이나 비전공자를 위해 복잡한 기술을 설명하고자 한다면 지식을 뽐내기 위한 글이 아니라 이해를 도와주기 위한 글을 작성해야 한다. 우리들 사이에서는 수식 한 줄이 백 마디 말을 대신할 수도 있지만, 비개발자를 위한 글을 작성할 때에는 차라리 백 마디 말이 더욱 효율적으로 정보를 전달할 수도 있다는 점을 명심하자.

 

기술 문서를 읽는 사람은 문서에서 설명하는 정보를 시선이 움직이는 순서대로 받아들이고, 정보의 진위나 유용성을 판단한다. 이 과정에서 문서가 제공하는 정보가 독자의 기준을 충족한다면 조금씩 설득력이라는 것이 축적된다. 이를 기반으로 논리일탈이 아닌 주장을 펼쳤을 때, 독자의 판단에 설득력이 충분히 쌓였다면 그 문서는 힘을 가지는 것이다.

 

따라서 기술적, 학술적 무결성은 논문과 같은 기술문서에 설득력과 완성도를 부여한다. 정확한 정보를 논리적으로 전달하는 것은 노블한 것이다. 구구절절 옳은 말을 논리적인 순서로 배치한다면 누구든지 고개를 끄덕거릴 것이다. 단, 독자에게 당업자 수준의 지식이 있을 경우에만.

 

당업자를 독자로 설정해도 되는 경우

 

당업자는 특허법에서 사용하는 용어로, 특허심사과정에서 진보성 판단의 기준이 되는 사람이다. 특허법에서는 그 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 선행기술을 바탕으로 용이하게 발명할 수 있는 기술은 특허를 받을 수 없다고 규정하는데, 여기에서 ‘그 발명이 속하는 기술분야에서 통상의 지식을 가진 자’를 당업자라고 한다.

 

특허청 심사지침에 따르면 당업자는 관련 필드의 기술 상식을 보유한 전문가이며, R&D를 위해 실험장비나 연구비 등의 인프라를 자유롭게 사용할 수 있는 금수저이며, 출원 전 시점의 기술수준(솔루션)에 있는 모든 것을 입수하여 자신의 지식으로 할 수 있는 성실한 사람이고, 솔루션 기술분야 뿐 아니라 그 특허가 해결하고자 하는 문제와 관련된 기술분야의 지식을 자신의 지식으로 할 수 있는, 필요하다면 다른 전공분야 지식도 자유자재로 습득 가능한 천재이다. 한 마디로 탈 지구급 인재다. 혹시 그런 사람을 현실에서 만나본 적이 있는가? 필자는 단 한 번도 없다. 특허청도 당업자를 ‘상상 속의 인물’이라고 못박아 두었다. 이는 특허심사과정을 더욱 깐깐하게 하기 위한 기교로 받아들이면 되겠다.

 

당업자라는 개념은 엔지니어 입장에서도 상당히 유용한 개념이다. 특허문서나 논문을 작성할 때에는 당업자가 독자라고 생각하고 작성하면 된다. 그러면 간결하면서도 기술적 설득력을 갖춘 문서를 만들 수 있다. 

 

특허를 먼저 예시로 들어 보겠다. 학사학위만 소지한 채로 기술고시에 합격한 경력 20년차 특허심사관이 최신기술을 박사학위 소지자 수준에서 이해하고 심사하는 것은 쉽지 않은 일일 것이다. 이때 당업자가 등장한다. 심사관은 자신이 아니라 당업자의 입장에서 발명을 평가한다. ‘나는 이런 걸 개발하지 못하지만, 당업자라면 선행기술을 토대로 용이하게 이런 발명을 할 수 있을 것이다.’라는 판단이 들면 그 특허를 거절할 수 있는 것이다. 심사의 기준이 당업자의 시선이므로 엔지니어는 독자의 지적 수준을 크게 고려하지 않고 마음 편하게 특허명세서를 작성하면 된다.

 

논문도 마찬가지다. 피어리뷰를 들어오는 박사들은 해당 분야 최첨단 수준의 기술수준을 보유하고 있을 것이므로. 물론 당신이 세계 최고의 학자고, 인류가 여태 도달하지 못 한 수준의 지식을 다루었다면 리뷰어들이 당신이 작성한 논문의 내용을 이해하지 못 할 수도 있지만 그럴 사람은 많지 않을 것이므로 당업자를 독자로 설정하고 작성하면 된다.

 

당업자라는 개념은 문건을 작성중인 개발자에게 상당히 위안이 되는 존재다. 당업자는 엔지니어가 기술한 정보를 모두 이해할 수 있는 사람이므로 독자가 과연 이 글을 이해할 수 있을지에 대한 걱정을 전혀 하지 않아도 된다. 복잡하고 어려운 개념이라 하더라도 업계 평균 수준의 전문가가 이를 배경지식으로 숙지하고 있다는 판단이 들면, 당연히 당업자도 이를 이해하고 있을 것이라 전제하고 그에 대한 상세한 설명을 생략해도 된다. 이 얼마나 좋은 일인가.

  

당업자는 가상의 존재다  

 

1년 전이었나 2년 전이었나, K 대학교의 후원으로 모 소규모 특허사무소를 통해 상상텃밭의 딥러닝 특허를 출원할 기회가 있었다. 이 특허사무소의 변리사들은 당업자 수준에서 작성된 문서를 전혀 이해하지 못했다. 의뢰 과정에서 미완성된 발명을 완성시키려 하는 것이 아니냐는 코멘트까지 받았다. 

 

K 대학측과의 협약이 어떤 형태였는지는 모르겠지만 시간이 굉장히 촉박하다고 했다. 막판에 출원서의 최종본을 우리 컨펌도 받지 않고 심사청구까지 신청해서 출원해버렸던데 청구항을 읽다가 해탈하는 줄 알았다. 혹시나 저 끔찍한 특허가 등록되어 성공보수를 요구당할까 걱정되어 조용히 취하했다.

 

당업자는 어디까지나 가상의 존재다. 학술적인 문서를 제외하면 당신이 작성한 문서를 당업자 수준의 독자가 검토하는 일은 일어나지 않는다고 봐야 한다. 특허문서도 위와 같은 일이 일어날 수 있는데 하물며 일상이나 직장에서는 더더욱.

 

앞서 “기술적, 학술적 무결성은 논문과 같은 기술문서에 설득력과 완성도를 부여한다.”고 서술하였는데 여기에 부연설명을 조금 추가하여 아래와 같이 다듬어 보겠다.

 

“기술적, 학술적 무결성은 기술문서에 설득력과 완성도를 부여한다. 단, 당업자가 독자일 경우에 한한다.”

 

즉 현실에서는 기술적, 학술적 완성도가 문서에 설득력을 충분히 제공하지 못하는 경우가 더 많다는 뜻이다.

 

현실의 독자가 기술문서를 접한다면

 

인문계 출신의 40대 남성을 한 번 가상의 독자로 설정해 보자. 서술의 편의상 이 분을 봉팔 씨라고 부르도록 하겠다. 봉팔씨는 당신의 직장 상사로 부장 기타 임원급에게 직접적인 보고를 올릴 수 있는 위치에 있다.

 

당신은 새로운 프로젝트를 기획하거나 새로운 개발 툴을 회사에 도입하고 싶어 경영진을 설득하고자 한다. 우선 그에 앞서 당신의 상사 봉팔씨부터 설득하고 싶다. 당신은 며칠 야근을 해가며 기안서를 작성해 봉팔씨에게 제출했다. 그런데, 그 기안서는 당업자를 독자로 설정하고 작성된 기술문서이다. 당신은 기술적 정보와 실제 사례, 기대 효과 등을 논리적인 순서로 작성하였다. 그 문서는 당업자가 읽는다면 고개를 끄덕이게 만들기 충분한 설득력을 발휘할 수 있다.

 

이 문서를 봉팔씨는 어떻게 받아들이게 될까?

 

우선 못 알아듣는 용어는 전부 뇌리에서 지워질 것이다. 아래 그림과 같이.

 

전문용어만 지워도 글의 대부분이 날아간다.

 

봉팔씨는 처음 보는 용어는 일단 건너뛰고 읽을 것이다. 그리고 한 번 문서를 죽 훑어본다. 아마 문서를 읽고 난 봉팔씨의 소감은 아래와 같을 것이다.

 

‘알아들을 수 없는 무언가를 뭐 어떻게 배치하라고? 그리고 거기에 뭘 제공해? 그 제공이라는 행위에 예산을 배정해야 되나? 그러면 현재 회사에서 사용하고 있는 기술에 비해 효율이 높아진다고? 대체 왜? 뭘 했다고 효율이 높아져? 성능평가 지표를 바꾸라고? 지금 지표는 뭐가 문젠데? 왜 바꿔야돼?’

 

설득력이라는게 한순간에 증발해버렸다.

 

현실에서, 특히 직장에서 대부분의 경우 기술적, 학술적 완성도는 설득력과 비례하지 않는다. 문서를 이해하기 위해 필요한 배경지식의 양이 방대해질수록, 어려운 용어가 많이 등장할수록 문서의 설득력과 파급력은 감소한다. 

 

당업자를 설득하기 위한 문서는 의사결정권이 있는 대부분의 사람들에게는 효험이 떨어질 것이다. 못 알아 들으니까.

 

로우 레벨 문서, 하이 레벨 문서

 

개발자들에게 익숙한 표현을 준비해 봤다. 필자보다 독자 여러분들이 더 잘 알겠지만 프로그래밍 언어에는 레벨이 있다. 로우레벨 언어일수록 컴퓨터가 알아듣기 용이하고 하이레벨 언어일수록 인간이 알아듣기 용이하다. 마찬가지로 기술문서에도 레벨이라는 것이 있다. 낮은 레벨로 내려갈수록 문서가 간결해지고 배경지식을 많이 요구한다. 윗쪽 레벨 동네로 올라가면 문서의 간결함이 떨어지고 이해하기 쉬운 문서가 된다.

 

로우 레벨 문서는 복잡한 지식을 빠르게 전달하기 위한 문서다. 현실에서 우리가 용이하게 접할 수 있는 문서 중 가장 레벨이 낮은 문서는 논문이 아닐까. 논문은 대량의 정보를 간결하게 압축할 수 있도록 수식을 포함하기도 하며, 독자가 해당 분야의 통상의 지식을 갖춘 것을 전제로 작성하므로 배경지식에 대한 구구절절한 설명도 생략된다. 실무진끼리 빠른 소통을 위해 작성한 문건은 논문보다는 높은 레벨에 있을 것이다. 하지만 아직까지는 로우레벨의 문서다.

 

문서를 읽는 독자가 비개발자라면 굉장히 하이레벨에서 문서를 작성해야 한다. 경우에 따라서는 용어에 대한 설명이나 배경지식을 구구절절 제시할 필요도 있고, 필요하다면 과감하게 작동원리에 대한 설명을 포기하고 기능만 제공할 필요도 있다. 이해를 돕기 위하여 비유나 실례를 많이 삽입해야 할지도 모른다.

 

학술적인 영역은 특수하니 아예 배제하고 설명한다. 직장에서 당신이 실무를 많이 뛸수록 로우레벨 언어 문서를 많이 사용할 것이지만 당신의 직위가 올라갈수록, 조직 내에서 당신이 파급력을 크게 행사해야 할수록 하이레벨 언어로 문서를 작성해야 한다. 이걸 이해하지 못하는 상사와 함께 일하는 것은 정말 지옥과도 같다. 

 

독자의 지식 수준을 설정하는 데 성공했다면

 

축하한다. 이제 첫 단추는 끼운 것이나 마찬가지다. 가장 중요한 고비를 넘겼다. 하지만 아직 갈 길은 멀고 험하다. 이제부터가 진짜 게임이다. 

 

앞서 이야기했듯 개발자는 문제를 해결하는 사람이며, 개발자의 글은 문제를 해결하는 능력을 갖고 있다. 문서는 독자와의 PMF를 달성하면 파급력이 극대화된다. 재미나 감동을 주기 위한 글이 행사하는 파급력도 어마어마한데, 문제를 해결하는 능력을 가진 글이 파급력을 갖춘다면 어떤 일이 일어날까? 

 

개발자의 생각은 일종의 에너지 덩어리이며 개발자가 쓴 글은 그것을 가공해 만든 신기한 원석이다. 이 원석은 PMF가 달성되었을때 가장 아름답게 빛나며, 힘이 강해진다.

 

그런데 대체 PMF가 뭐야?

 

기술문서를 접한 비개발자 독자의 기분을 조금이나마 맛보여드리고자 PMF가 무엇인지 설명을 하지 않았다. PMF는 product market fit의 약자로 ‘제품과 시장 사이의 친화도’ 정도로 이해할 수 있는 개념이다. PMF는 문학이나 작문 분야 용어는 아니고, 스타트업 경영론 및 마케팅 용어다. 혹시 린 스타트업(lean startup)이나 그로스 해킹(growth hacking)이라는 용어를 들어 보았는가? 

 

린스타트업은 시장에 MVP라는 제품을 출시해 반응을 살핀다. MVP는 minimal viable product의 약자로, 최소한의 기능을 탑재한 제품을 의미한다. 예를 들면 자동차를 만들 계획을 가진 팀이 자동차를 출시하기에 앞서 자동차에 들어가는 제어 소프트웨어만 먼저 만들어 판매해 보는 것이다. 반응이 별로라면 제품을 수정해 재출시해 보고, 영 아니다 싶으면 다른 사업분야로 눈을 돌리는 피봇(pivot)을 수행한다. 약삭빠르게 방향을 바꿔 나가면서 시장의 반응을 살피고, 조금씩 더 시장이 좋아할만한 제품으로 도달해 나가는 기법이다.

 

 

그로스 해킹은 개발자들이 만든 마케팅 방법이다. 고객의 반응을 유도하기 위한 수단과 이를 분석하기 위한 IT기술이 결합하여 만들어진 마케팅 수단인 것이다. MVP를 출시하여 시장의 반응을 탐색하고 고객이 더 열광할 만한 요소를 더해 나가며 시장과 기업 사이의 친화도(PMF)를 추구해 나간다는 것이 이 철학의 핵심이다. PMF가 달성되면 제품이 불티 나게 팔려 나갈 가능성이 어느 정도 담보될 것이라 본다. 다만 이를 확립해 나가는 과정에서 전략을 어떻게 짜고 지표를 어떻게 분석하는지가 이론으로 정립되지 않은 상태이며 그로스 해커의 역량에 온전히 달려 있다.

 

정리하면 그로스 해킹은 빠르게 PMF를 달성하기 위한 기법이고 린스타트업은 그로스 해킹을 통해 성장해 나가는 조직이라고 생각할 수 있겠다.

 

PMF라는 개념을 어떻게 글에 적용할 수 있을까?

 

여기서 Market은 독자이며 Product는 문서다. 즉 “PMF가 좋은 문서를 작성해야 한다.”는 말은 “독자와 친화도가 높은(궁합이 좋은) 글을 작성해야 한다.”는 뜻으로 받아들일 수 있겠다. 이는 개발자 뿐 아니라 글을 쓰는 모든 사람들이 달성하고 싶어하는 목표다.

 

문제를 해결하는 힘을 가진 개발자의 문서가 PMF를 달성하는 순간 그 파급력이 극대화된다. 글 몇 편으로 대한민국을 움직일 수도 있다. 구체적인 사례가 궁금하다면? 필자가 쓴 책을 읽어보자!

 

코딩하는 공익 국내도서 저자 : 반병현 출판 : 세창미디어 2020.04.27 상세보기

 

 

다시 PMF이야기로 돌아가자

 

필자는 책에서 소개된 사례에서 초기에는 PMF달성을 위해 노력했고, PMF가 달성된 이후에는 불특정 다수에게 노출되기 위하여 노력했다. 덕분에 많은 국민들에게 공감을 살 수 있었고, 국가를 움직일 수 있었다.

 

이 사례를 현실적인 규모로 축소해 보자. 작게는 팀 내에 새로운 작업도구를 도입하는 것에서 부터, 새로운 프로젝트를 런칭하기 위한 기안서를 올리는 것, 또는 연구과제를 따오기 위해 RFP를 작성하는 과정 등 강한 설득력을 갖추어야 하는 문서는 PMF를 잘 고려해야 한다.

 

필자가 타겟팅한 market은 대한민국 국민이었다. 직장에서는 상사나 경영진이 될 것이다. 직장 내에서 PMF가 맞는 글이란 상사나 경영진이 읽기에 좋은 글일 것이다. 인문계를 나온 경영진에게 가장 PMF가 떨어지는 글은 전문용어나 기술적 언어가 가득 들어있는 문서일 것이다. 당업자는 상상속의 동물과도 같은 존재다. 합리적인 추론으로 어느정도 조정 가능한 선에서 최대한 설득시키고 싶은 이의 눈높이에 맞는 글을 작성하도록 하자.

  

개발자 문서와 PMF

 

개발자는 문제를 해결하는 사람이다. 개발자가 쓴 글은 문제를 해결하는 힘이 깃들어 있는 글이다. 글은 PMF가 달성되면 호소력이 생긴다. 호소력이 있는 글은 설득력을 가진다. 개발자가 PMF 높은 글을 작성할 수 있다면, 문제를 해결하는 능력을 자유자재로 발휘할 수 있게 된다. 조직 입장에서도, 개발자 개인 입장에서도 좋은 기회가 될 것이다.

 

독자의 지식 수준에 맞게 하이레벨 언어로 작성할 것인지, 로우레벨 언어로 작성할 것인지 고민하는 습관은 훌륭한 초석이 될 것이다. 익숙해지면 조금씩 조금씩 더 독자의 취향을 반영해 나가면 된다. 그리고 당신이 작성한 문건이 독자를 설득하는데 성공했던 실패했던 가능하면 피드백을 요청하도록 하자. 그리고 그 피드백을 분석해 다음에는 더 나은 방향을 찾아갈 수 있기를 바란다. 이러한 경험이 쌓이면 그게 곧 실력이 될 것이다.

 

 

치즈케익 스튜디오

코딩하는 공익

법대로 합시다

실전 민사소송법

공학자의 지혜묵상