💬 업무 리뷰 그거.. 어떻게 잘하는 건데?

준비한 내용을 공유하고 설득하기 위한 '업무 리뷰'

첫 기획 리뷰를 진행하고, 디자인 리뷰에 참여했을 때가 아직도 생각나요. 나름 철저하게 준비한 정책을 공유한다는 것에 대한 설렘도 있었고, 부족한 것이 드러나면 어쩌지? 하는 불안도 함께 있었는데요. 여전히 어려운 리뷰지만, 업무를 진행하는 데 있어 꼭 필요한 시간이기에 오늘은 기획(정책) 리뷰와 디자인 리뷰에 대한 다섯 명의 메이커 이야기를 소개하고자 합니다. 우리 스스로가 진행 중인 리뷰 방법과 함께 비교해 보고, 좋은 내용을 흡수할 수 있는 시간이 될 수 있기를 바라요!

프로덕트 매니저 K : 리뷰 시 가장 중요한 건, 설득의 근거를 설계하는 것

아마 저와 같은 분이 국내에 꽤 있을 것 같아요. 저는 PM으로 일하고 있지만, 규모가 크지 않은 스타트업에 있기에 기획 업무를 함께 하고 있습니다. 그렇게 가장 자주 하는 업무 중 하나가 ‘기획/정책 리뷰’인데요. 우선순위에 따라 우리가 개발할 기능이 결정되면 저는 바로 요구사항 문서를 작성하고 있어요. 여기에는 기능에 대한 개요, 우리가 해결하고자 하는 문제, 달성 목표와 검증 기준, 논의에서 제외할 내용, 사용자 시나리오, 상세 정책 등이 포함됩니다. 리뷰는 크게 두 단계로 나눠서 진행하는데 하나는 정책 작성 전까지의 내용이며 피드백 등을 통해 내용이 확정되면 상세 정책과 데이터를 어떻게 볼 것인지 정리하고 다시 한번 리뷰를 진행하고 있어요.

리뷰의 성격은 다르지만, 리뷰는 늘 쉽지 않고 비슷한 패턴으로 흘러가는 경우가 많아요. 정해진 시간보다 길어지는 경우도 발생합니다. 여러 이유가 있겠지만 대표적으로 PM이나 기획자가 작성한 초기 내용에 대해 바로 수긍하기 어렵거나 디자인 또는 개발 과정에서 문제가 발생할 상황이 보이기 때문입니다. 문제가 발생할 것 같은 경우는 개발 과정을 나누거나 다른 해결방법을 나름 객관적으로 따져볼 수 있는데, ‘설득이 잘 되지 않는’ 상황은 쉽게 해결되지 않는 경우가 많아요. 이성과 감정이 자주 뒤섞이는 시간이기도 합니다.

특히 감정이 앞서게 되면, 내가 더 많은 시간을 고민했는데 질 수 없지! 와 같은 태도로 연결되는데 실제 미팅에서 자주 발생하는 상황이기도 해요. 감정싸움이 되는 경우도 있고요. 이런 태도는 서로가 조심해야 하기에, 미팅 전 우리가 지켜야 할 태도 정도로 한 번씩 공유하고 시작하는 것도 도움이 됩니다. 아예 다 같이 미팅 가이드와 기준을 만들어 동기화하는 시간을 갖는 것도 좋아요. 이보다 더 어려운 건, 리뷰를 통해 제안한 내용에 대해 참여자들이 쉽게 수긍하지 못하는 상황입니다.

물론, 제안한 내용을 모두가 바로, 매번 그대로 받아들이는 건 건강하지 못한 업무 방식이라고 생각해요. 그래서 저는 기능을 풀어가는 방법에 대해 1개가 아닌 2-3개의 안을 동일한 기준에 따라 정리한 뒤 리뷰에 참여하고 있어요. 각 안을 우리가 어떻게 활용할 수 있으며 장점과 단점에는 어떤 것들이 있는지 작성하는 것이죠. 논리의 구조를 만들어갈 때 보통 하나가 아니라 여러 결론에 다다르는 경우가 많아 설득의 근거가 명확하고 구체적인 것들을 정해 내용을 준비하는 방법이기도 합니다. 리뷰 때 각 안을 설명한 뒤, 기획자(PM)가 원하는 안을 공유하고 그렇게 생각하고 결정한 기준을 함께 설명하고 있어요.

이 방법이 중요한 이유는, 한 가지 안을 제안했을 때 참여자들이 이거보다 더 좋은 방법이 있을 것 같은데, 당장 떠오르지는 않아서 논의가 길어지는 것을 방지할 수 있기 때문이에요. 또 참여자들로 하여금 다른 길로 새지 않고, 장점과 단점 등 공유한 기준에 따라 의견을 제시하고 반박할 수 있는 환경을 마련해 줄 수 있다는 점에서도 저는 도움이 된다고 생각합니다.

💡 메이커의 꿀팁

리뷰 과정에서 설득의 근거가 필요할 때 읽어보면 좋은 글

‘함께 일하는 구성원들을 설득하기 위해 필요한 것들’에서도 비슷한 내용을 찾아볼 수 있어요. 신규 비즈니스를 제안하는 과정에서 각각의 이해관계자를 위한 리뷰를 진행하고, 설득하는 과정에 대한 내용인데요. “기존 서비스와 연동이 가능했고, 확장의 개념이 컸기에 구성원들의 공감이 있을 거라 예상했지만 반응은 생각보다 좋지 않았다. 발표가 끝난 뒤, 팀 단위로 다시 의견을 물었는데 예상치 못한 답변을 들을 수 있었다. 하나의 프로덕트를 담당하면서도 할 일이 많은 스타트업 특성상, 프로덕트 하나를 더 만들고 운영하는 것에 대한 부담감이 크다는 것이었다.”

초기 설득 대상이 전체가 아니라 진행해도 좋다는 사인을 받아야 할 C레벨이었기에 수익화와 방향에 초점이 맞춰져 있어 실무자들의 공감을 얻지 못했다는 걸 알 수 있어요. 그래서 글쓴이는 서비스를 만들기 위해 필요한 기능을 하나씩 나열하고 기능이 필요한 이유와 담당 인원을 함께 작성했어요. 담당 인원을 미리, 함께 적은 이유는 신규 채용이 이뤄진다 하더라도 팀원들이 기존 업무와 병행할 상황을 미리 안내하고 투입이 어려울 경우 활용 가능한 방법을 논의할 수 있을 거란 생각 때문이었다고 합니다.

필요한 기능, 필요한 이유, 담당 인원 세 가지를 한 묶음으로 20여 개의 기능을 정리한 뒤 다시 한번 팀 단위로 미팅을 진행했는데요. 미팅의 목적은 이 기능을 어떻게 개발할까? 가 아니라 나열된 기능을 론칭 기준 최소 단위로 줄이고, 현재 진행 중인 업무와 병행했을 때 투자할 수 있는 시간을 미리 점검하는 것이었다고 해요. 또 기능 개발 시 우려되는 점, 이슈에 대해 미리 확인하며 구성원들이 공감할 수 있는 수준으로 내용을 구체화하고자 하는 목적도 포함되어 있었다고 합니다. 이런 과정을 통해 프로젝트 진행 여부 등 논의가 왜? 에 머물지 않고 구성원들의 현재 상황을 고려해 어떻게? 에 초점을 맞춰 이야기를 진행할 때 설득 확률을 높일 수 있다는 사실을 제대로 알 수 있었다고 해요.

서비스기획자 B : 기획 리뷰에서 중요한 건 디테일이 아니라 큰 그림

저는 워터풀 프로세스로 일하는 회사의 기획팀에서 일하고 있습니다. 클라이언트로부터 요구사항을 받으면 스토리보드 초안을 작업하는 것까지가 저의 몫인데요. 회사에서 리뷰라고 하면 완성된 스토리보드를 디자인팀, 개발팀, PM에게 설명하는 자리를 의미합니다. 리뷰는 한 번으로 끝날 수도 있지만 피드백을 받는 과정에서 이슈가 많이 나오면 최종 리뷰를 다시 준비하는 경우도 있습니다. 신입으로 첫 리뷰를 하게 되었을 때는 완벽한 스토리보드를 보여줘야 한다는 욕심에 아주 작은 부분까지 상세히 만들었던 기억이 납니다.

그러나 리뷰를 몇 번 경험해 보니 필요한 것이 밀리미터(mm) 단위로 완벽한 기획서가 아니라는 것을 알게 되었습니다. 기획자의 생각과 다른 작업자의 생각에는 늘 차이가 있고, 아무리 열심히 만든 스토리보드라도 수정은 불가피하기 때문에 완벽한 기획서라는 것은 존재할 수 없다는 생각을 하게 되었어요. 또 ‘내가 여기까지 공들여 기획했는데…’라는 마음으로 리뷰에서 사소한 부분을 설명하는 데 시간을 많이 쓰는 것도 바람직하지 않다는 생각이 들었습니다. 리뷰 참여자들도 기획의 핵심에 대한 피드백을 주기보다는 사소한 부분에 대한 피드백으로 새는 경우가 많았어요.

그 후로 리뷰를 할 때 생긴 저의 요령은, 리뷰에 앞서 기획 의도나 필요성 같은 큰 그림을 언급하는 것입니다. 예전에는 리뷰를 시작하자마자 스토리보드의 첫 화면부터 띄우고 화면의 기능이나 와이어프레임을 설명했다면, 지금은 이러한 기획이 나오게 된 배경과 의도, 기대효과에 대해 간단히 짚고 나서 스토리보드를 설명하는 과정으로 넘어갑니다. ‘어떻게 만들 건지’를 설명하기 전에 ‘왜 만들어야 하는지’를 탄탄하게 준비해서 설명하게 되면 스토리보드를 처음 보는 개발자와 디자이너도 몰입이 쉬워지고, 좀 더 본질적인 부분에 대한 피드백을 받을 수 있다는 것을 알게 되었기 때문이에요. 무엇보다 ‘공통의 기준’에 따라 이야기를 나누고 기획 내용을 보완할 수 있다는 점에서 지금도 많은 도움을 받고 있어요.

💡 메이커의 꿀팁

리뷰에서 팀원과 큰 그림을 함께 그리기 위해 읽어보면 좋은 글

우아한형제들에서 PM으로 일하고 있는 이기호님의 인터뷰에서도 비슷한 이야기를 들을 수 있었어요. 기획자에게 있어야 하는 중요한 역량을 묻는 질문에 기호님은 ‘기획자로서 무엇을 해결해야 하는지 정확하게 이해하고, 해결해야 하는 문제에 집중하는 능력이 가장 중요하다고 생각한다‘고 답했어요. 무엇을 해결해야 하는지가 바로 ’왜 만들 건지‘와 같은 맥락의 내용인 것 같아요. 또한 프로젝트 초반에 해결해야 하는 문제에 대해서 팀 전체와 합의를 이루게 하는 것이 중요한 능력이라고 말했는데요. 리뷰 앞에 기획 의도에 대해 설명하는 것도 이러한 합의에 도움이 되는 작업이라고 생각해요.

기획자와 기획 리뷰에서는 기획 리뷰 시 건설적인 코멘트를 받을 수 있는 방법에 대해 소개하고 있어요. 글쓴이도 예전에 리뷰 참여자들이 자신의 기획 내용에 대해 알고 있을 것이라 생각하고 일방적인 리뷰를 진행했다가 공감대를 사는 데 실패했다고 합니다. 그 후로 글쓴이는 리뷰 전이라도 기획서를 만드는 중간에 유관부서 사람들과 구두 미팅을 통해 기획 방향을 대략적으로 설명하고, 기획 리뷰 일정을 공지하면서 사전에 기획서를 공유하여 참가자들이 사전 지식을 얻도록 돕고 있어요. 또한, 간단한 프로토타입을 만들어서 참가자들의 빠른 이해를 도와서 의미 있는 코멘트가 나올 수 있게 유도한다는 팁은 개인적으로 다음 리뷰 때 시도해보고 싶은 내용이었어요.

서비스 디자이너 M : 어떤 문제를 해결하기 위한 화면인지 기억하기

저는 회사에서 디자인팀 리딩을 담당하고 있는 7년 차 디자이너입니다. 디자이너에게 리뷰는 크게 2가지 종류가 있는 것 같아요. 첫 번째는 프로젝트 초기 단계에 컨셉에 어울리는 디자인 아이디어와 그에 맞는 컬러 시스템 등에 대한 리뷰가 있고요. 두 번째로는 프로젝트 진행 중, 기획서를 기반으로 사용자에게 제공해야 하는 경험이 잘 풀렸는지에 대한 UI/UX 리뷰가 있습니다. 종류에 따라 리뷰의 방향과 디자이너가 확보해야 할 피드백이 조금씩 다르다고 생각하는데요. 그중에서 UI/UX 리뷰는 모든 디자이너가 떨리는 마음으로 참여하는 것 같아요.

저희 팀의 경우, UI/UX 리뷰는 1차로 디자인 팀 내부 인원들의 리뷰, 2차로 기획자, 운영자, 개발자 전 직군을 포함한 리뷰를 두 번에 걸쳐 진행합니다. 1차 내부 리뷰는 주로 메인 기능과 강조해야 하는 포인트에 따라 레벨이 잘 적용되었는지 확인합니다. 특히 같은 컬러 계열에서도 50~950까지 나뉠 수 있어, 주요 기능에 따라 레벨이 적절히 배치되었는지 확인하는 것을 중요하게 생각하고 있어요. 예를 들어 내가 올린 게시글 통계를 볼 수 있는 마이페이지에 “통계” 버튼과 “프로필 설정” 버튼 2개가 제공된다고 생각해 볼게요. 이때, 더 밀어줘야 할 기능이 “통계” 버튼이라면 “프로필 설정” 버튼이 더 강조되는 900 단위의 컬러가 적용되었을 경우 다시 조정하는 작업이 필요해요. 그리고 누구에게나 접근성이 좋고 일관성 있는 디자인이 적용되었는지도 1차 내부 리뷰에서 확인하고 있어요.

이후 2차 리뷰에서는 주로 사용자 경험이 적절한지, 사용자 행동과 흐름에 있어 불편한 점이 없는지 최종적으로 확인하고 있어요. 이때 전 직군의 동료들이 모이기 때문에 정말 다양한 피드백을 받을 수 있는데요. 사실 이 시간이 디자이너에게 두려운 건, 고민해 온 결과에 확신이 드는 것보다 동료들의 의견에만 신경써 화면을 만들 때 고려한 기준과 근거 등을 잊는 것이 아닐까 싶어요. 그래서 2차 리뷰를 준비할 때 저는 화면을 구성하며 근본으로 생각한 요인과 왜 이렇게 풀어냈는지 설명하는 것을 중요하게 생각하고 있어요. 이를 바탕으로 리뷰에 참여한 동료들이 다른 기준에 따라 벗어나는 결과를 만들지 않도록 하고 있어요.

개인적으로 디자인은 기획과 개발을 이어주는 징검다리의 역할로 동료들의 의견을 육안으로 확인할 수 있는 수단이자 사용자 경험의 끝점이라고 생각해요. 그래서 디자인 리뷰는 항상 어떤 문제를 해결하기 위한 기능인지와 같은 기준을 잊지 않고 진행하는 것이 중요하다고 생각해요.

💡 메이커의 꿀팁

정해진 기준과 범위 내에서 리뷰를 진행하고자 할 때 읽어보면 좋은 글

웹 접근성을 고려한 컬러시스템 만들기는 디자이너라면 한 번쯤은 파고들어야하는 영역이라고 생각해요. 디자인 리뷰를 진행할 때 접근성, 통일성, 효율성 등 동일한 기준에 따라 서로 더 좋은 피드백을 주고 받을 수 있기 때문인데요. 디자인은 주관적 의견이 많이 반영될 수 있기에 이런 기준이 있다면 정해진 범위 내에서 논의가 진행될 수 있으며 이러한 시스템이 적용되면 사용자도 안정감을 느낄 수 있어요. 결국 서비스의 일관성은 리뷰 시, 일정한 기준이 될 수 있다는 점에서 눈여겨봐야 할 내용이 아닐까 싶어요.

다른 디자이너의 디자인 리뷰 후기(Permission to Design)도 살펴보면, 명확한 ‘커뮤니케이션’이 중요하다는 것을 알 수 있는데요. 여기서 ‘명확함’이란, 우리가 해결하고자 하는 문제를 잘 풀어냈는지가 기준이 되어야 하며 비판을 하는 데 있어 구체적인 근거와 의견을 가지고 이야기해야 한다는 점이에요. 대안 없는 비판이나 근거 없이 감정적인 코멘트는 자제하는 것이 좋다는 이야기도 포함되어 있어요. 정리해보면, 서비스의 일관성을 위한 시스템 적 접근은 물론, 우리가 근본적으로 이 기능과 화면을 왜 만들고자 하는지에 대한 논의가 리뷰의 핵심이라고 할 수 있어요.

서비스 기획자 J : 시간을 더 쓰더라도, 기획팀 리뷰를 먼저 진행하는 이유

처음에 기획 리뷰를 진행했을 때, 가장 답답했던 건 제가 설명한 내용이 잘 전달되지 않은 것처럼 느껴지는 상황이었어요. 파악을 위해 의견을 물어도, 구체적인 답으로 돌아오지 않을 때가 많아 더 어렵게 느껴진 것 같아요. 문제는 스스로 작성한 내용을 다시 보고 또 봐도 잘못된 점을 빠르게 인지하지 못한다는 점입니다. 스스로가 쓴 글을 다시 봐도 잘못 작성된 내용을 잘 발견하지 못하는 것과 비슷한 것 같아요. 그래서 3명뿐이지만, 같은 업무를 하는 동료들과의 리뷰를 먼저 진행하는 방법을 떠올렸어요. 다행히 다른 기획자들도 비슷한 생각을 하고 있었기에 다음 정책부에 대해 15-20분 정도 시간을 잡고 진행할 수 있었습니다.

이 시간을 통해, 내용이 이해하기 쉬운지는 물론 달성하고자 하는 목표나 해결이 필요한 문제 등이 잘 반영되었는지 그리고 그에 따른 데이터 등의 근거가 포함되어 있는지를 확인했어요. 또 디자인과 개발자 입장에서 확인하고 싶거나 이슈가 될 수 있는 내용들을 미리 살펴보는 것도 잊지 않았죠. 시간을 더 투자해야 하는 일이었지만, 이전보다 더 탄탄한 내용을 만든 뒤 전체 리뷰를 진행할 수 있다는 점에서 도움이 많이 되었습니다. 지금은 기획팀만의 중요한 문화가 되어 더 다양한 이야기를 주고받고 있어요.

제가 일하고 있는 스타트업에서는 스토리보드를 사용하지 않은지 오래되었고, 보통 스펙 문서와 정책서를 바탕으로 기획/정책 리뷰를 진행하고 있는데요. 기획팀 리뷰를 만들면서 내용은 더 좋아졌지만 텍스트 중심이라 전체 리뷰 시 설명하기 어려운 상황이 종종 발생했어요. 그래서 간단한 프로토타입을 주요 기능 중심으로 만들어 함께 활용하고 있어요. 피그마 등을 활용하면 욕심이 생겨 시간을 많이 뺏긴다는 것을 알기에 종이에 그려 사진을 찍은 뒤 문서에 첨부하는 방법을 쓰고 있어요. (최근에는 페이퍼 프로로타입을 디자인으로 바꿔주는 서비스도 있어요)

💡 메이커의 꿀팁

기획팀 리뷰를 먼저 진행하고 싶을 때 살펴보면 좋은 글

‘제안서, 단계마다 검증할 시어머니를 둬라’에서는 제안서를 잘 만드는 것도 중요하지만 제대로 리뷰하는 것의 중요성을 이야기하고 있어요. 가장 중요한 건, 무엇이 잘못되었나에 초점을 맞추는 것이 아니라 어떻게 개선할 것인가에 대한 의견을 받아야 한다는 점인데요. 앞서 살펴본 ‘기획팀 리뷰’에서 몇 가지 기준을 정하고, 이에 대한 개선안을 받는 시간으로 활용한다는 것이 다시 떠올랐어요. 또, 제안서의 내용이 일관되어 있는지 확인하는 ‘시어머니’ 역할의 중요성도 포함되어 있는데, 전체 리뷰 시에는 각자 담당하게 될 업무와 관련된 의견이 나올 수 있기에 기획팀 리뷰에 참여하는 다른 동료들이 시어머니 역할을 할 수 있지 않을까?라는 생각도 들었습니다.

프로덕트 디자이너 C : 팀별 디자인 리뷰가 필요한 이유

저희는 각각 디자인팀이랑 하는 리뷰와 운영, 개발, QA팀이 모두 참여하는 전체 리뷰가 있는데요. 보통 디자인팀 내 리뷰는 슬랙 문서 형태로 디자인 진행 과정을 공유하고, 의견을 받는 방법으로 진행하고 있어요. 전체 리뷰는 어느 정도 디자인팀 내 협의가 된 내용을 발표 형식으로 공유하고 피드백받는 쪽으로 진행하죠. 다만 진행하는 작업과 관련된 모두가 참여하는 전체 리뷰의 경우 수집한 피드백을 반영하는 과정이 쉽지 않았어요.

디자인 리뷰를 통해 1) 개발이 진행이 어려운 방안이거나 2) 운영적으로 적절치 않은 방안이라는 등의 피드백을 받아 디자인 변경을 하게 되는 경우가 생기는데요. 모든 팀을 모아 디자인 리뷰를 하게 되면 위의 의견들이 한 번에 나오게 되고, 팀별로 중요하게 생각하는 기준과 그에 따른 의견이 조금씩 달라서 취합이 어려웠어요. 예를 들어 운영팀은 운영 관점에서 적절한 디자인인지에 대한 의견을 주고, 개발팀에선 개발 가능 여부 등에 대한 의견, QA팀에서는 디자인에 누락된 케이스들에 대한 보완 요청 등에 대한 의견이 나와요. 시간은 정해져 있는데, 각자가 집중하고 싶은 분야가 다르다 보니 충분하지 않다는 단점도 있었어요.

그래서 최근에는 시간은 더 투자해야 하지만, 운영, 개발, QA 조직에게 따로 디자인 리뷰 시간을 갖고 있어요. 각 팀에서 원하는 내용을 더 적극적으로 확인할 수 있는 방법이라는 판단 때문이에요. 팀별로 리뷰를 진행한 뒤 수렴할만한 의견/그렇지 않은 의견을 나누고 수렴할 의견 중 바로 반영할 것/이후 반영할 것을 나눠 정리하고 있어요. 물론, 단점도 여전히 존재하는데요. 예를 들어 팀별 리뷰를 할 때 작업하는 주제에 따라 운영팀과 먼저 점검하는 경우도 있고, 개발팀과 먼저 진행하는 게 적합할 때가 있어서 순서를 적절하게 잡는데 시간을 많이 투자해야 합니다.

💡 메이커의 꿀팁

개별 팀 리뷰가 필요할 때 읽어보면 좋은 글 

‘발산과 수렴을 잘해야 디자인을 잘한다’에서도 디자인 리뷰에 대한 이야기를 볼 수 있어요. 여러 관련자의 다양한 시각에서 피드백을 받고(발산) 이 중 타당한 피드백을 선별하여 적용(수렴)해야 한다는 내용인데요. 이 이야기를 보면서 우리가 발산과 수렴을 위한 최적의 환경은 무엇일까? 라는 생각을 하게 되었어요. 그리고 자연스레 앞서 살펴본 팀 별 리뷰를 따로 진행한다는 디자이너의 이야기를 떠올렸어요.

물론 전체 리뷰와 개별 리뷰의 장단은 존재하겠지만, 각자의 상황과 입장을 고려하고 동일한 기준에 따라 의견을 집중해서 낼 수 있다면 발산과 수렴의 과정에 우리가 더 집중할 수 있지 않을까 싶어요. 그 방법 중 하나가 팀에 따른 리뷰일 수 있고요!

뉴스레터에 질문에 대한 다양한 답을 모두 담긴 어려워요. 그래서 온라인/오프라인 등을 통해 뉴스레터 '주제'가 된 '질문'을 중심으로 더 깊은 이야기를 나눠보려 합니다. 아직 준비중인 단계라 어떤 식으로 진행이 되면 좋을지 의견을 나눠주세요. 곧, 함께 이야기 나눌 수 있는 자리를 주제에 따라 만들어볼게요! (아래 링크를 클릭해 의견을 남겨주세요!)

7월 27일 발행될 다음 뉴스레터 주제는 '실수와 실패'입니다. 우리가 어떤 기능을 적용했을 때, 늘 성공하는 것은 아닌데요. 업무를 함에 있어서 실수 역시 자주 하게 되고요. 이런 상황에서 메이커들은 어떤 방법으로 같은 실수를 방지하려 노력하는지, 실패를 어떻게 교훈 삼기 위해 노력하는지 자세히 살펴볼 예정입니다. 다음 주제도 많은 기대 부탁드려요!

📮 팁스터 멤버십 안내

멤버십 콘텐츠 여섯 번째 주제(7월)는 '운동'입니다. 안과 밖에서의 운동은 물론, 기록 등의 과정에서 어렵게 느끼거나 문제라고 생각하는 점들을 살펴보고, 이를 해결하기 위해 노력중인 서비스를 정리할 예정입니다. 또 서비스 담당자의 문제해결 방법에 대한 코멘트도 포함될 예정이에요. 멤버십 콘텐츠가 궁금하다면, 멤버십 소개 내용을 확인해주세요! 

오픈채팅방을 통해 뉴스레터로 다 소개하지 못한 정보를 확인해보세요!