🍳 PM에게 가장 중요한 산출물과 활용 방법은?

🍳 오늘의 레시피 ’PM의 산출물’

PM은 프로젝트의 방향성과 의사결정을 명확히 하기 위해 다양한 산출물을 체계적으로 관리해야 해요. 잘 정리된 문서는 팀원 간 원활한 협업을 돕고, 새로운 이해관계자가 빠르게 프로젝트를 파악할 수 있도록 해주죠. 또한, 변경 이력과 주요 논의 사항을 기록함으로써 동일한 실수를 반복하지 않도록 방지하고, 나아가 향후 유사한 프로젝트 진행 시 중요한 참고자료로 활용될 수 있어요.

오늘은 각자 다른 영역에서 일하는 세 명의 PM과 함께 주로 다루는 산출물은 무엇이며, 이를 관리하고 정리하는데 필요한 노하우는 무엇인지 자세히 살펴볼게요! 

🧑‍🍳 오늘의 메이커

핀테크 서비스를 담당하는 13년차 PM, 라멜라

안녕하세요, 뉴스레터 구독자 여러분! 저는 IT 분야에서 13년째 프로덕트 매니저로 일하고 있는 라멜라예요.

그동안 다양한 프로젝트를 경험하면서 산출물 하나가 팀과 프로젝트 전체의 성과를 얼마나 좌우하는지 몸소 느껴왔어요. 현장에서 겪은 다양한 성공과 실패의 경험들을 바탕으로 이번 주제와 관련해 가능한 바로 써먹을 수 있는 실무 팁과 인사이트를 전하고 싶어요.

🥕 핵심 재료

🔥 조리 방법

Q1. PM으로 주로 만드는 산출물의 종류와 가장 자주 다루는 산출물의 구성 방법은 어떻게 되나요?

PM으로서 실무에서 가장 자주 작성하고 활용하는 산출물은 프로덕트 요구사항 문서(PRD), 프로젝트 일정표, 사용자 스토리, 회고록이에요. 각 산출물을 작성할 때는 '어떻게 활용될지' 항상 고민하며 적는 습관을 들이면 팀 내 커뮤니케이션과 업무 효율이 크게 높일 수 있다고 생각해요.

먼저 PRD는 프로젝트 초기에 꼭 작성하는데, 이전에 요구사항의 배경이나 목적을 제대로 정의하지 않아서 팀 간 의견 차이가 많아 고생한 적이 있었어요. 이후부터는 프로덕트의 배경과 목표, 주요 기능 목록, 기능의 우선순위, 기대 효과를 구체적이고 간결하게 정리해 이해관계자들이 하나의 공통된 기준을 갖도록 했어요.

두 번째로 프로젝트 일정표를 작성할 때는 팀원들이 업무 간 의존 관계를 제대로 파악하지 못해 일정이 지연되는 경험을 한 뒤로, 마일스톤뿐 아니라 담당자, 기간, 선후행 업무 관계까지 명확히 표기하고 있어요. 또한 사용자 스토리는 처음엔 개발 관점에서 작성했다가 사용자의 실제 요구와 다른 결과물이 나온 적이 있어서, 이후로는 '사용자의 입장에서 원하는 행동과 목적'을 함께 적어 빠른 공감을 얻고 있어요.

마지막으로 회고록은 예전에 너무 간략하게 작성하다가 프로젝트를 반복하면서 같은 실수를 반복한 경험이 있어, 이제는 실제 배운 점과 개선해야 할 부분을 최대한 구체적으로 적어 다음 프로젝트에서 꼭 반영하고 있어요.

Q2. 좋은 산출물의 핵심 요소는 무엇이라고 생각하며 이유는 무엇인가요?

좋은 산출물의 핵심은 명확성과 최신성 두 가지로 정리할 수 있어요. 산출물은 작성 후 끝나는 것이 아니라 주기적으로 업데이트하고, 중요한 변화는 즉시 팀과 공유해 혼란을 방지하는게 정말 중요하죠.

좋은 산출물에서 명확성과 최신성이 얼마나 중요한지 깨달은 경험이 있었어요. 이전에 담당했던 앱 출시 프로젝트에서 요구사항 명세서를 작성했는데, 표현이 모호한 부분이 있어 개발팀이 서로 다른 방식으로 기능을 해석해 이틀간 작업이 지연된 적이 있었죠. 그 이후로는 핵심적인 요구사항을 더 짧고 정확하게 작성하고, 꼭 한 번 더 이해관계자에게 확인받는 습관을 갖게 되었어요.

또, 프로젝트 중반에 주요 요구사항이 바뀌었는데도 문서 업데이트를 놓쳐서 개발팀과 디자인팀이 구버전의 문서를 참고하고 있던 적도 있었어요. 이를 계기로 저는 산출물에 "마지막 업데이트 날짜"를 크게 표시하고 매주 한 번씩 산출물을 점검하여 최신성을 유지하는 프로세스를 만들었는데요. 이후로는 이런 문제가 거의 발생하지 않게 되었답니다.

Q3. 가장 기억에 남는 산출물에 대한 작업 과정을 공유해주세요!

가장 기억에 남는 산출물 작업은 대규모 공공 시스템 구축 프로젝트의 요구사항 명세서였어요. 이 프로젝트는 규모가 워낙 크다 보니 여러 부처에서 다양한 이해관계자들이 참여했고, 각 부처마다 요구하는 기능과 우선순위가 모두 달라 처음에는 요구사항을 통합하는 것 자체가 매우 어려웠어요.

저는 우선 각 부처의 요구사항과 담당자 의견을 정확히 파악하기 위해 1:1 인터뷰와 그룹 워크숍을 여러 차례 진행했어요. 각 워크숍에서는 단순히 요구사항을 듣는 데 그치지 않고, "이 기능이 왜 필요한지(WHY)"를 반복해서 물어보며 각 항목의 배경과 목적을 최대한 구체적으로 문서화했죠.

특히 기억에 남는 예시는 한 부처가 요청한 '실시간 데이터 동기화' 기능이었어요. 처음에는 개발 비용과 시스템 복잡성 때문에 다른 부처들로부터 반대 의견이 많았는데요. 이때 요청 부처에서 이 기능이 없으면 민원이 발생했을 때 빠르게 파악하고 즉각적으로 대응할 수 없어 업무에 큰 지장을 준다는 배경을 설명하자, 다른 이해관계자들도 중요성을 깨닫고 점차 공감을 보였어요.

이런 방식으로 각 요구사항의 배경과 목적을 명확히 밝히고 공유한 덕분에 서로 간의 신뢰가 높아졌고, 결과적으로 모두가 합의할 수 있는 명확한 요구사항 명세서를 완성할 수 있었어요. 최종적으로 이 문서는 프로젝트 전체의 기준점이자 성공적인 구축을 위한 든든한 토대가 되었고, 지금도 실무에서 요구사항 정리의 모범 사례로 활용하고 있답니다.

Q4. 업무 관련 산출물을 만들 때 가장 어려운 점과 극복 방법을 알려주세요!

테스트 시나리오를 작성할 때 종종 어려움을 느끼는데요. 가장 어려운 점은 이해관계자마다 중요하게 생각하는 테스트 항목이 달라서 우선순위를 조정하기 어렵다는 것이에요. 특히 이해관계자가 많거나 시스템이 복잡할수록 어떤 부분을 우선적으로 테스트할지 명확한 합의를 이끌어내기가 쉽지 않죠.

예를 들어, 과거 프로젝트에서 개발팀은 핵심 기능의 성능 테스트를 먼저 요구했고, 디자인팀은 UI와 사용성 테스트를 우선시하는 상황이 있었어요. 이때 저는 각 그룹의 요구사항을 명확히 듣고, 테스트 항목별 중요도와 긴급도를 정리한 다음, 프로토타입을 통해 핵심 기능을 미리 시연했어요. 각 항목의 장단점과 영향을 객관적으로 설명하고, 실제 테스트 범위를 합리적으로 설정한 덕분에 모두가 동의할 수 있는 최적의 테스트 시나리오를 마련할 수 있었어요. 아무래도 시각적이거나 실제 동작 가능한 프로토타입을 활용하면 테스트 항목 우선순위를 정할 때 훨씬 빠르고 명확한 합의를 이끌어낼 수 있다는 걸 알게된 것 같아요.

Q5. 내 산출물을 처음 보는 사람이 쉽게 이해할 수 있도록 하기 위해 어떤 노력을 하고 있나요?

산출물의 이해도를 높이는 데는 몇 가지 핵심 전략이 있어요. 우선 MECE 원칙(Mutually Exclusive, Collectively Exhaustive)을 적용하는데, 정보를 서로 중복되지 않으면서도 빠짐없이 포괄적으로 구성하는 방법이에요. 잘 지키면 문서가 체계적이고 논리적으로 구성되어 읽는 사람이 혼란 없이 이해할 수 있죠. 지키지 않으면 정보가 중복되어 혼란스럽거나 중요한 내용을 빠뜨릴 수 있기 때문에, 프로젝트 문서를 작성할 때 꼭 적용해야 해요.

또 헤딩, 서브헤딩, 글머리 기호처럼 시각적 계층 구조를 활용하면, 읽는 사람이 문서의 구조와 핵심을 쉽게 파악할 수 있죠. 특히 중요한 메시지는 문서 초반에 요약하고 본문에서도 볼드 처리 등으로 강조하면 더 효과적이에요. 마지막으로, 액션 아이템을 명확히 하고 초안 단계에서부터 이해관계자의 피드백을 받아 반영하면, 문서를 수정하는 시간이 많이 줄어드는 걸 경험했어요.

MECE는 쉽게 말해 "겹치지 않게, 빠짐없이" 정보를 정리하는 방법이에요. 조금 더 풀어서 말하면,

예를 들어, 팀 업무를 정리할 때 각자의 업무가 겹치면 혼란이 생기고, 빠진 업무가 있으면 일이 제대로 안 돌아가겠죠? MECE를 잘 지키면 산출물이 깔끔하고 명확해져서 읽는 사람이 쉽게 이해하고 업무 효율도 높아질 수 있어요.

🍬 디저트

이 글은 PM에게 꼭 필요한 산출물을 효과적으로 작성하는 방법을 실제 경험을 바탕으로 친절하게 소개하고 있어요. PRD, 프로젝트 일정표, 사용자 스토리, 회고록 등 각 문서의 중요성을 명확한 사례를 들어 쉽게 설명해주고 있죠. 특히 산출물을 만들 때 흔히 겪는 문제와 해결 방법을 실무자의 언어로 잘 풀어내서 공감이 되는 내용이에요. PM으로서 업무 역량을 키우고 싶은 분이라면 꼭 읽어보길 추천해요.

모바일 서비스 기획 및 콘텐츠 운영을 담당하고 있는 11년차 PM, 디오니소주

안녕하세요. 저는 대한민국 대표 음악 스트리밍 서비스에서 모바일 서비스 기획 및 콘텐츠 운영을 담당하고 있는 디오니소주 입니다.

🥕 핵심 재료

🔥 조리 방법

Q1. PM으로 주로 만드는 산출물의 종류와 가장 자주 다루는 산출물의 구성 방법은 어떻게 되나요?

저는 주로 모바일 서비스 구현을 위한 기획서나 모바일 서비스 사용 현황을 정리하는 문서를 만들고 있어요. 이 문서는 개발, 디자인, 마케팅 등 모바일 서비스 구현에 필요한 모든 관계자가 참고할 수 있도록, 서비스의 기능을 포함한 요구사항을 정리하는 역할을 해요. 또한 이 문서에는 배경 및 목적, 상세 요구사항, 일정, 고려사항 등도 포함되어 있어요.

Q2. 좋은 산출물의 핵심 요소는 무엇이라고 생각하며 이유는 무엇인가요?

저는 산출물에서 가장 먼저 ‘목적’이 명시되어야 한다고 생각해요. 산출물은 언제나 완벽할 수 없고, 그것 자체가 최종 목적이 아니라 또 다른 산출물을 만들기 위한 과정이기 때문에 계속 수정될 수 밖에 없어요. 하지만 목적이 명시되지 않으면 수정 방향이 처음 의도와 달라질 수 있기 때문에, 언제나 목적을 가장 먼저 정하는 것이 중요해요. 제 아무리 완벽해 보이는 산출물이라도, 목적이 없거나 명시된 목적과 맞지 않는다면 좋은 산출물이라고 할 수 없을 거에요.

Q3. 가장 기억에 남는 산출물에 대한 작업 과정을 공유해주세요!

가장 기억에 남는 산출물은 검색 서비스의 개선 방향과 요구 사항을 정리한 문서에요. 당시 검색 서비스는 말 그대로 ‘검색’ 기능만 제공하고 있었는데, 저는 사용자가 단순히 원하는 콘텐츠를 ‘검색’하는데 그치지 않고, 다양한 콘텐츠를 ‘탐색’할 수 있는 서비스를 제공하는데 초점을 맞췄었어요.

그래서 이 산출물을 만들기 위해 기존 검색 서비스 사용자의 사용 현황 데이터를 분석하고, 내부 및 외부 사용자의 다양한 의견을 적극적으로 반영하려고 노력했어요. 그 결과, ‘검색’에서 ‘탐색’으로 발전할 수 있는 방향을 구체적으로 기획할 수 있었어요.

Q4. 업무 관련 산출물을 만들 때 가장 어려운 점과 극복 방법을 알려주세요!

산출물을 만들 때 가장 어려운 점은 모든 이해관계자가 같은 방향을 이해하고 실행할 수 있도록 만드는 것이에요. 개발, 디자인, 마케팅 등 다양한 부서 담당자가 산출물을 참고하지만, 같은 내용을 보더라도 각자가 다르게 해석할 수 있기 때문이에요.

그래서 저는 산출물로만 의사소통하는 것 보다, 산출물을 의사소통을 위한 수단으로 보고 적극적으로 설명하려는 노력이 꼭 필요하다고 생각해요. 이렇게 해야만 모든 관계자가 같은 방향으로 이해하고 효과적으로 협업할 수 있어요.

Q5. 내 산출물을 처음 보는 사람이 쉽게 이해할 수 있도록 하기 위해 어떤 노력을 하고 있나요?

저는 언제나 산출물을 보는 사람의 입장에서 생각하려고 노력하고 있어요. 산출물을 만들 때 처음에는 이를 고려하지만, 작업이 진행될수록 산출물 자체에 집중하게 되어, 보는 사람의 입장을 점점 잊게 되는 경우가 많거든요. 그래서 산출물을 만드는 사람은 쉽게 이해할 수 있지만, 정작 보는 사람에게는 어려울 수 있는 표현은 최대한 지양하고, 가능한 한 상세하면서도 장황하지 않게 기술하려고 해요.

또한, 산출물의 가장 앞부분에는 목적과 전체 구성을 요약해 정리해요. 이렇게 하면 처음 접하는 사람도 전체적인 내용을 빠르게 파악할 수 있고, 이후 내용을 이해하는 데에도 도움이 될 수 있어요.

🍬 디저트

이 책은 애자일 조직 문화와 협업 방식을 중심으로, 개인과 팀이 함께 성장하는 방법을 다루고 있어요. PM이 산출물을 만들 때 중요한 것은 단순히 문서를 작성하는 것이 아니라, 이해관계자들과 원활하게 소통하고, 피드백을 반영하며 지속적으로 개선하는 과정이에요. 이 책은 그런 점에서 PM이 산출물을 보다 효과적으로 관리하는 데 도움이 될 수 있으니 읽어보는 것을 추천해요!

라이프타임 커리어 플랫폼 인프런 4년차 프로덕트 매니저, 테디 

안녕하세요, 라이프타임 커리어 플랫폼 “인프런” 운영사 인프랩에서 프로덕트 매니저로 일하고 있는 테디입니다. 인프런에서 사용자들이 보다 의미 있는 학습을 할 수 있도록 고민하고 있어요.

개인적으로 스스로 부족한 부분을 더 못하지 않게끔 노력하는 것을 가장 잘한다고 생각합니다. 오늘 제 경험이 누군가에게 부족한 부분에 도움이 되면 좋겠습니다.

🥕 핵심 재료

🔥 조리 방법

Q1. PM으로 주로 만드는 산출물의 종류와 가장 자주 다루는 산출물의 구성 방법은 어떻게 되나요?

PM으로서 주로 만드는 산출물은 일을 진행시키기 위한 기초 문서라고 생각합니다.

사전 문서로는 PRD(product requirement document), 사용자 스토리 기반의 명세서, 스프린트 플래닝 문서 등이 있고요. 이후 진행 및 마무리 과정에서는 회고록, QA를 위한 Test Case, 배포 후에 공지를 위한 릴리즈 노트 등을 주로 작성하고 있어요.

구성 방법은 사실 저는 템플릿화 하는 걸 그렇게 선호하진 않고 머릿속에 구조를 정리하고 각 프로젝트의 성격에 맞춰 매번 새롭게 구성하는 걸 더 좋아합니다.

예를 들어, 4주가 넘어가는 큰 프로젝트는 진행 기간 동안 여러 문서가 많이 쌓이다 보니 PRD를 훨씬 간소하게 작성하는 편인데요. 반면 1~2주 정도로 예상되는 작업의 경우는 PRD를 세세하게 적고, 문서 개수를 최소화하려고 하는 편입니다.

프로젝트 성격에 따라서도 다른데요. 실험 기반의 작업이라면 가설과 검증 지표를 중심으로 작성하고 디테일한 기능 명세에 대한 부분은 디자이너나 개발자에게 맡기고 있어요. 신규 기능이라면 배경과 목적, 타겟으로 삼는 고객, 장기적인 로드맵과 기대효과, 핵심적으로 봐야 할 지표 등을 우선 정리하고 상세 내용을 채워나가고 있고요.

그리고 사실 모두가 놓치기 쉬운 산출물이 실무자 간 주고받는 메시지(메신저 내의)라고 생각해요. 예를 들어 담당자 간 슬랙으로 주요 내용을 논의했다면 이 메시지를 어디에 어떻게 적어두느냐도 정말 중요하거든요.

특정 상태나 상황을 모호한 표현이나 나만 아는 이상한 단어로 만들어서 작은 혼란을 주는 케이스도 솔직히 많다고 생각하는데요. 그래서 저는 슬랙 메시지도 문서를 구조화하듯 두괄식, 피라미드 형태로 작성하기 위해 신경 쓰려고 하고 있습니다.

Q2. 좋은 산출물의 핵심 요소는 무엇이라고 생각하며 이유는 무엇인가요?

사실 저는 앞서 설명드린 문서가 산출물(output)이라고 보진 않는데요. 이유는 이 문서들은 진짜 산출물(Product)을 만들기 위한 도구일 뿐이라고 생각하기 때문이에요.

그래도 문서 작성을 산출물이라 생각하고 핵심 요소를 정리해면, 탄탄한 구조라고 생각합니다.

프로젝트의 맥락을 가능한 정확하고 해상도 높게 전달하는 것이 중요한데, 구조를 잘 잡는다면 문서의 내용은 자연스럽게 채워진다고 생각해요. 그래서 구조와 기본 요소를 잘 정리해 둔다면, 문서 자체가 처음엔 조금 부족하거나 빈틈이 있더라도 구조에 맞춰 이후 팀원들이 그 부분을 보완해 줄 수 있는 환경이 되더라고요.

구조를 잡을 때 가장 중요한 것부터 작성하는 두괄식 형태를 도입해서, 피라미드 형태로 작성하고 위에서 아래로 뻗어나가는 내용 자연스럽게 흐르고 논리적으로 잘 연결이 되도록 하는 편입니다.

Q3. 가장 기억에 남는 산출물에 대한 작업 과정을 공유해주세요!

주니어 시절 가장 기억에 남는 순간이자 산출물이 하나 있는데요. 그건 바로 그 시절 상위 리더 중 한 분이 다른 동료에게 업무를 요청하는 슬랙 메시지였어요.

앞서 말씀드린 것처럼 동료 간의 메시지도 또 하나의 산출물이라 생각해서 그 메시지가 떠오르는데요. 업무 요청 메시지의 전달력이 굉장히 탁월해서, ‘저 분과 일해보고 싶다’는 생각이 들 정도였어요.

당시 내용은 꽤 큰 요청사항을 단순 메시지인데도 불구하고 제목, 요약, 배경, 왜 해야 하는지, 세부적인 요구사항, 관련된 담당자까지 명확해서 이해하기 쉽더라고요. 그래서 그 메시지를 복사해 놓고 메시지를 작성할 때마다 장점을 흡수하려 노력했던 것 같아요.

Q4. 업무 관련 산출물을 만들 때 가장 어려운 점과 극복 방법을 알려주세요!

개인적으로 사용자 스토리 기반의 기능 명세서나 서비스 정책 문서를 작성할 때가 가장 어려운 것 같아요. 주요 정책은 변하지 않더라도 세부적으로 뻗어나가는 정책들은 계속 추가되거나 수정되다 보니 개발 작업 중에 예상치 못한 케이스를 대응하면서 문서의 양도 길어지는데요.

그러다 보니 작업자 입장에서 때로는 문서를 팔로업하는 것만으로도 피로도가 높아질 수 있고, PM 입장에서도 항상 문서를 최신 상태로 관리하는 게 더욱 힘들어지는 것 같아요. 길어진 문서를 잘 관리하더라도 너무 길어지면 읽는 사람 입장에서 부담스러워지기도 하고요. 이에 대한 극복 방법은 솔직히 없다고 생각합니다.

최대한 커진 문서는 더 세부적이고 정확하게 쪼개고, 쪼개진 문서가 다시 무거워지면 또 가볍게 만들고, 가벼워지면서 생기는 비효율은 다시 합치면서 채우고 이런 식으로 계속 최적화를 하는데 힘써야 할 것 같아요.

그리고 산출물을 만드는 과정의 어려움을 이겨내는 것도 필요하겠지만, 이보다는 제품(Product)을 잘 만들 수 있는 환경에 좀 더 신경 쓰고 힘쓰는 편입니다.

Q5. 내 산출물을 처음 보는 사람이 쉽게 이해할 수 있도록 하기 위해 어떤 노력을 하고 있나요?

앞서 작성한 내용과 유사한데요. 두괄식으로 중요한 것부터 작성하는 점과 피라미드 형태로 작성하여 위에서 아래로, 좌에서 우로 이어지는 내용이 논리적으로 잘 연결이 되도록 신경을 많이 쓰고 있습니다.

그래서 문서 구조를 잘 짤 수 있도록 시간을 투자해 문서에서 전달해야 하는 문제와 요구사항이 잘 이어질 수 있도록 노력해요.

이런 형태로 초기 구조를 탄탄하게 잡으면 문서에 담긴 프로젝트의 성격도 자연스럽게 드러나거든요. 큰 규모의 프로젝트라면 '왜 해야 하는지'와 작은 규모의 작업이라면 빠르게 실행될 수 있도록 효율적으로 정리되어 있어야 하는 거죠.

그러다 보니 늘 좋은 책이나 영화, 전시등의 업무 외의 콘텐츠도 꾸준히 접해야 하는 것 같아요. 책이나 영화, 전시 등의 문화적인 요소들도 결국 구조가 어떻게 짜여 있느냐에 따라 감상이 완전히 달라지잖아요. 그래서 평소에도 잘 와닿고 이해하기 쉬운 콘텐츠의 구조는 무엇이 다른지 많이 분석해보려 합니다.

물론 내 프로덕트의 일이 되면 말처럼 쉽지 않아서 ‘나부터 잘하자!’라는 다짐을 하고는 하는데요. 더 깊이 고민하다 보면 때론 길을 잃을 때가 있는 것 같아요ㅠㅠ 그래도 항상 구조에서 파생될 수 있도록 노력해 보겠습니다!ㅎㅎ

🍬 디저트

바바라 민토의 <논리의 기술> 혹시 읽지 않으셨다면 꼭 읽어보시면 좋을 것 같아요!

📚 혹시 기획력이 부족하다 생각하세요?

책과 연결된 확장된 지식과 정보를 다양한 형식으로 함께 수집하고, 저자와 함께 온라인 세션을 진행하는 메이커의 레시피 북클럽 4기를 모집합니다!

✨주차별 완독해야 하는 구간에 대한 저자의 Tip도 함께 제공

✨특별 세션 : 저자와의 온라인 세션

4기와 함께해주시는 저자는 빅아이디어연구소 김종섭 대표(홈페이지, SNS) 님입니다.

삼성전자, 신한은행 등 다수의 기업과 CLASS101(강의 링크)에서 강의도 진행하시는 10년차 프로 광고러인데요.한 장으로, 한 문장으로 사용자의 시선을 사로잡는 창의력과 기획력에 관심있는 분들께 강력하게 추천드립니다!

참여할 경우, 아래와 같은 혜택을 추가로 얻으실 수 있어요!

메이커의 레시피 북클럽은 함께하는 분들이 모은, 책과 관련된 다양한 정보가 차곡차곡 쌓여 많은 도움을 받으실 수 있어요. 북클럽과 관련된 보다 자세한 내용은 아래 링크를 참고해주세요!

북클럽 4기 신청하기

팁스터 멤버십 주요 혜택과 프로그램을 확인해보세요!

- 팁스터 뉴스레터를 더 깊이있게, ‘팁 다이브’ (월 3-4회)
- 주제에 대한 다양한 시각을 공유하는, '에디터 브리핑' (월 1회)
- 한 주제에 대한 상반된 입장, ‘팁스터 아고라’ (월 1회)
- 새롭게 업데이트 되는, '기존 멤버십 콘텐츠' (월 1회)
- 사례집 접근 권한과 유료 클럽 할인 혜택 제공
- 나만의 셀프 업무 레시피를 만드는, 멤버십 커뮤니티

👉 팁스터 멤버십 살펴보러 가기

팁스터 뉴스레터의 공식 오픈채팅방에 참여해보세요!