연말에 회고하기로 마음먹었지만 푹 쉬어버렸다. 그래서 올해는 새해 목표를 설정하면서 2025년에 대해 회고하고자 한다.

1. 역할의 변화 — 나는 더 이상 ‘PM’만은 아니게 되었다

2025년의 가장 큰 변화는 역할이었다.

명함에 적힌 직함보다 더 중요한 변화는, 내가 맡고 있는 책임의 성격이 바뀌었다는 점이다.

나는 더 이상 하나의 제품이나 기능만을 고민하고, 단순 Sprint만 운영하는 PM이 아니었다.
PM, Product Designer, QA로 구성된 프로덕트 팀을 이끌며, 결정해야 하는 위치에 서게 되었다.

그리고 올해는 이 변화에 대해 가장 뼈저리게 고민하고,
성장통을 많이 겪었을거라고 생각한다.

이 과정에서 깨달은 사실이 하나 있다.

일을 잘하는 PM과, 결정하는 리더는 전혀 다른 역량이라는 것.

2025년의 나는 그 경계에 서 있었다.

“팀원들이 낙오되지 않도록 나는 얼마나 동기부여를 주었는가?”
“팀원들의 애로사항을 잘 F/U하고 해결하고 있는가?”
“주변 팀과의 관계에 있어서 원활한 협업이 되도록 앞장섰는가?”

이런 고민을 하면서 새삼 예전 무한도전의 유재석과 1박2일의 강호동이 얼마나 대단한 리더들인가를 자주 떠올리고 느끼게 되었다.

요즘은 유튜브를 보면서 어떤 상황에서도 멤버들을 이끄는 그들의 프로 정신이 예능의 재밌는 장면보다도 더 주목되는 것 같다.

2. 제품의 변화 — AI Native 서비스 하이퍼랩, ‘AI스러운 UX’를 설계하라

AI 서비스는 일반적인 서비스와 다른 경험을 사용자에게 제공한다.

그중 가장 대표적인 건 ‘상호작용’을 설계하여 최첨단 기술처럼 보이게 해야 한다는 것이다.

그렇기에 UX도 일반적인 서비스처럼 ‘클릭-로더-결과’ 형태가 아닌,
클릭(명령) 후 스스로 생각하는 과정 후에 만족스러운 결과까지 이어져야
사용자가 직접 AI와 소통하고 있다는 경험을 느끼게 된다.

지금은 AI assistant 기능만이 하이퍼랩에서 해당 UX를 제공하고 있지만,
하이퍼랩이 ‘AI-native’ 서비스로 성장하기 위해서는 제공하는 모든 AI 기능에 대해 플랫폼 내 전역에서 글로벌하게 ‘AI스러운 UX’를 계속 고민해야 할 것 같다.

3. 책임의 변화 — 전체 Product Life Cycle을 관리하다.

개인의 피드백이 Backlog가 되는 것부터 여러 공정을 거쳐 실제 사용자에게 공개되고 메시지로 나가기까지의 모든 프로세스를 주관하기 시작했던 한 해였다.

하나의 기능에 대해 신약개발, 연구본부, 프로덕트, 개발, 마케팅, 영업, 전략까지 모두 공동의 메시지를 Align하고 진행하는 목적으로 NPI(New Product Introduction) 프로세스를 꾸준히 시도해 왔다.

여전히 미스 커뮤니케이션이 발생은 하고 있지만,
그래도 확실하게 사전에 Align을 하고 나서는 커뮤니케이션의 효율성이 개선되었다.

무엇보다 더이상 제품에 대해 각 파트가 혼선이 되지 않는 부분이 가장 큰 효과라고 생각한다.

2025년 한 줄 평 : 넓어졌지만, 깊어지지는 못한 1년

2025년은 겉으로 보면 가장 많은 일을 했던 해였다.

역할은 커졌고, 다루는 제품은 복잡해졌으며, 책임져야 할 범위는 명확히 이전과 달라졌다.

그러다 보니, 깊이 있게 일하지 못했던 것 같다. 그래서 작년 대비 “잘하고 있다”라는 확신은 오히려 줄어들었다.

그렇다면 어떻게 살아갈 것인가?

이미 넓어진 업무를 혼자가 아닌 다 같이 깊어질 수 있도록 조율해야 한다.

2026년에는 2025년의 경험을 밑거름 삼아서 조금 더 적응을 완벽하게 하여 나만의 스타일로 업무를 펼쳐나가야 할 것 같다.

단순한 Product Manager가 아닌,
제품 전체를 책임지는 입장과 제품과 관련된 다양한 직군들까지 모두 동기화되어 동일한 목표를 향해 이루어나가고, 그 효과를 최대로 끌어내며,

그것이 결국 최대 매출로 이어질 수 있도록 하는 역할이 되어야 한다.

그에 맞춰서 이런 커리어적인 부분을 포함해서 나 스스로에 대한 컨디션 관리도 작년보다 더 성숙한 형태로 하는 것이 우선이 되어야 할 것 같다.

조금은 아쉬웠던 2025년을 이제 뒤로하고, 2025년을 해결하고 앞으로 나아가는 2026년이 되길 바란다.

때는 바야흐로 2023년 8월 7일,

신약 개발 및 의약 화학 지식이라고는 하나도 없는 PM이 ‘AI 신약 개발’이라는 죽을 때까지 만날 일 없는 도메인의 서비스를 자신 있다면서 히츠에 입사했다.

그렇게 2년이라는 시간이 지났고, 그 PM은 여전히 ‘AI 신약 개발 플랫폼, 하이퍼랩(HyperLab)’을 지지고 볶으면서 서비스와 함께 성공을 위해 동반 성장 중이다.

정말 벌써 2년이나 됐다.

오늘은 지나고 보니 순식간이었던 히츠에서의 2년에 대한 개인적인 회고가 아닌, 회상을 해보고자 한다.

여러 가지 작은 이벤트들은 많았겠지만, 대표적으로 2가지의 큰 레슨과 감사함이 있던 것 같다.

드디어, 레슨 Start 🗣️

👉 이건 첫 번째 레슨 : PM의 역할 정의하기

나는 운이 좋게도, 히츠의 첫 Product Manager로 입사를 하게 되었다.
연구원, 디자이너, 개발자로 구성되어 있던 조직에 PM이라는 신규 직업이 회사에 최초로 등장한 것이다.

최초의 PM이다 보니, PM이 해야 하는 업무 범위와 기대 역할 등을 모두 내 스스로 정의를 내려야만 했다.
하지만, 나에게는 스스로 체계를 수립하는 것에 대한 도전이 필요했던 시기였고, 정말 감사하게도 회사는 나에게 많은 자율성을 주었다.

그 결과, 고객의 관점을 100% 고려하기는 어려운 특수한 도메인을 가진 서비스에서 PM을 포함한 제품 개발 조직이 최대 효율로 최대 효과를 낼 수 있는 여러 가지 프로세스들을 고민하고 실행에 옮길 수 있었다.

💡대표 예시

📎 도메인 지식이 부족한 기획자가 회사에서 일하는 법

이러한 Product Manager의 정의는 매년 달라졌으며, 점점 확대되었다.

• 2023년에는 제품과 프로세스의 초기 단계를 원활하게 운영하기 위한 실질적인 Sprint 및 Product Life Cycle 운영 계획에 대해 초점을 맞췄다.
• 2024년에는 안정화된 Sprint를 기반으로 쌓여 있는 Backlog들을 우선순위에 맞게 처리하고, 제품에 대해 주도적으로 개선 방향성을 고민하고 이를 정량적인 데이터로 최대한 분석하여 가설을 검증하는 Market Fit에 집중했다.
• 2025년에 들어서는 제품의 더 먼 미래에 대한 로드맵을 세우고, 로드맵에 대한 상세 세부 개발 계획을 조정했다.
  또한, 단순 제품 개발 조직이 아닌 영업 & 마케팅과의 고객 전달 메시지를 통일하는 NPI 프로세스와 가격 정책까지 고려하며, 제품이 단순한 고객 문제 해결을 넘어서 장기 고객으로 전환될 수 있는 영역까지 업무 범위를 넓혔다.

Product Manager의 역할에 대한 정의가 점점 더 광범위하게 확장되면서 나 역시도 매년 성장하고, 더 넓고 멀리 볼 수 있는 인사이트를 갖게 되는 것 같다.

PM은 사실 사내 작은 CEO의 역할을 수행한다는 말에 대해 점점 더 깊게 체감하는 하루하루를 요즘은 보내는 것 같다.

👉 이건 두 번째 레슨 : 팀을 리드하고, 운영하기

히츠에 합류 후 나의 커리어에서 최초로 팀을 리드하는 상황을 맞이하게 되었다.

PM, 디자이너, QA 엔지니어로 구성된 프로덕트팀을 리드하면서, 조금 더 주도적으로 서비스의 방향성과 개선해야 할 부분들을 Action Item으로 삼고 실행에 옮겨보고 있다.

사실 서비스적인 고민은 굳이 팀을 리드하지 않아도 PM의 고유 업무 범위에 속하기에 팀을 리드한다고 해서 달라지는 부분은 없었다.

하지만, 고민이 필요했던 부분은 협업을 위주로 커뮤니케이션했던 팀원들에 대한 매니징이었다.

나 자신뿐만 아니라, 팀원들까지 포함해서 팀 전체가 성장할 수 있는 조직이 되도록 고민하고, 제품의 방향성을 고민하는 것처럼 팀의 방향성도 계속해서 고민 중이다.
그리고 팀원 개개인에 대한 헬스체크에 대한 관리도 꾸준히 노력하고 있다.

늘 언제나 매니징을 하는 것은 참으로 어렵지만 정말로 중요한 부분이라고 생각한다.

그래서 참 어렵다.

매번 회고하고, 스스로 결산을 하면서 느끼지만, 아직 부족한 점이 많기에 스스로 “좋은 People Manager인가?”에 대한 질문을 스스로에게 던지면서 성장하는 중인 것 같다.

그렇게 질문에 대해 혼자 정리한 내용들은 노션에 정리하면서 열심히 초보 팀장의 길을 걸어 나가는 중이다.

사실 내가 팀장으로 잘하고 있는지에 대한 평가는 주변의 사람들이나 우리 팀원들이 제일 잘 알고 있을 것이다. (이렇게 이야기하니까 걱정되기는 한다)

앞으로 더 성장한 모습의 팀장이 되어야 하고, 될 수 있도록 지금보다 더 노력해야 한다.

👉 나머지 레슨 : 아주 즐거운 히츠에서의 생활

그리고 어쩌면 내가 회사를 열심히 다니고 있는 이유 중 가장 큰 이유는 히츠의 멤버들 때문일 것이다.

일할 때는 물론이며, 놀 때도 모두가 한마음 한뜻으로 누구 하나 빠짐없이 최선을 다하는 사람들이다.

서비스에 대해서 누구나 열심히 고민하고, 아이디어를 제시하며 정말 PM으로서는 혼자 고민하는 상황들에 대해 다 같이 고민해 주는 사람들이 있어서 너무나도 감사한 히츠 멤버들이다.

서비스를 고민하다가 수능 영어 입시까지 고민해 주는 열정 넘치는(?) 멤버들이다.

🎠 레슨을 마무리하며 : 아직 가야 할 길이 멀다.

지금까지 히츠에서의 2년을 되돌아봤지만, 역시나 히츠에서의 2년은 힘든 순간도 분명 있었겠지만, 후회 없는 2년을 보냈다고 생각한다. 그렇기에 아직도 가야 할 길도 멀고, 해야 할 일도 많은 것 같다.

그래서 앞으로는 더 지금처럼, 또는 지금보다 더 최선을 다해 달려야 한다. 그리고 또 2년이 지나고 이 글을 보았을 때, 다시 또 후회 없는 2년을 보냈구나라는 생각이 들 것 같다.

마지막으로,

“하이퍼랩을 정상에 올려놓겠습니다.” — PM 김OO

어떤 PM이 2023년 히츠 송년회에서 건배사로 외친 말이었다.
그리고 그는 이 말을 지키기 위해 이 글을 쓰는 지금도 열심히 고민하고, 노력하는 중이다.

가능한 최선을 다해서, 앞으로도 스스로에게 응원을 보낸다.

AI, 이제는 거스를 수 없어

업무를 하는 데 있어서 이제는 더 이상 AI는 피하려야 피할 수가 없게 되었다.

그렇다고 해서 AI가 우리의 직업을 아예 대체할 것이라는 걱정은 할 필요가 없다. 오히려 이제는 AI를 잘 활용해야 하는 것이 능력이 되어가는 세상이다.

소프트뱅크, 전 직원에 AI 업무 의무화…”1인 100개 앱 만들라”

소프트뱅크의 경우, 오히려 전 직원에 AI 업무를 의무화하고 AI 활용 능력을 높이는 파격적인 선택을 했다.

앞으로는 채용 시 JD에 있어서 AI 활용 능력 자격증이 필수적으로 생겨날지도 모른다.

PM 역시도 AI를 적극적으로 업무에 활용하여 업무의 효율성과 생산성을 극대화하는 전략을 취해야 한다.

그래서 오늘은 내가 업무에 활용하고 있는 AI 서비스들을 소개하고자 한다.

💡 Chat GPT : 그중에서도 ‘프로젝트와 Context 기능’

사실 GPT 자체를 소개하는 것은 이제는 진부할 정도로 지친다. 그래서 GPT에서 내가 유용하게 쓰는 일부 기능들을 소개한다.

프로젝트 기능

GPT의 SNB를 확인하면, ‘새 프로젝트’라는 메뉴가 있고, 여기 하위로 여러 가지 프로젝트들을 생성할 수 있다.

사실 프로젝트의 개념은 고도화된 AI의 기능보다는 내가 자주 사용하는 채팅들을 그룹 지어서 관리할 수 있는 기능이다.

개별 프로젝트에는 각각의 채팅들의 리스트를 세부적으로 관리할 수 있고, ‘상단의 지침’을 통해서 각 채팅에서 가져야 할 공통적인 답변 정책을 설정하여 관리할 수 있다.

나는 주로, 기획이나 문구를 작성할 때 일관된 톤앤매너를 가져가기 위해서 GPT를 활용해서 2차 검증을 하는 과정을 거치고 있는데, 이때 공통의 지침이 설정되어 있으면 최대한 일관성을 유지한 UX Writing 정책을 가져갈 수 있는 장점이 있다.

앱과 연동되는 Context 기능

아마 커서를 사용하는 사람들이나 일반적인 LLM을 활용할 줄 아는 사람들은 모두 편리하게 사용하고 있을 기능일 것이다.

GPT에서 연동을 제공하는 앱을 연동하여 해당 앱의 내용을 GPT에 붙여 넣지 않아도 연계를 통해서 리소스로 바로 활용할 수 있는 기능이다.

개인적으로 Notion에 문서를 많이 두고 사용하는 입장에서는 상당히 편리한 기능이다. 다만 현재는 일부 앱만 제공되고, Jira나 Confluence까지 제공이 되면 PM 입장에서는 완전히 필수적인 기능으로 자리 잡을 것으로 보인다.

💡 Figma Make : 힘들게 그리지 말고, 먼저 테스트 후 디자인으로 넘어가자

내가 PM을 하면서 AI에 큰 충격을 받았던 적이 한 2번 정도 있다.

첫 번째는 ‘Cursor’였다.

PRD만 있어도 내가 원하는 서비스를 조금의 지식만 있으면 구현을 할 수 있다는 것이었다.
내가 원하는 대로 서비스를 MVP 정도로 구현은 할 수 있었고, 제품의 테스트도 충분히 가능한 수준이었기 때문에 세상이 발전했음을 느꼈다.

그리고 두 번째는 ‘Figma Make’다.

무엇이 얼마나 미쳤는가?

이 녀석은 그냥 미쳤다.

Cursor를 하면서 아쉬운 점이 있었다고 하면, UI에 있어서는 완전히 일반적인 화면이 아니면 디테일하게 구현하기 어려운 부분이 있었다. 그래서 사실 당연하다고 생각했고, 이런 부분은 역시 아직은 사람의 고민이 더 많이 들어가야 하는구나 라고 생각했다.

하지만 이런 생각을 Figma Make가 부숴버렸다.

정말 PRD와 설명을 자세하게 작성한다면, 개발 코드나 구조적으로는 최적화가 되지 않더라도 기획자에게 있어서는 내가 머릿속으로 상상한 화면을 거의 그대로 만들어서 보여준다.

물론, 일반적인 플랫폼이나 통상적으로 많이 쓰이는 UI는 그럴 수 있다고 생각하지만, 흔하지 않은 ‘AI 신약 개발 플랫폼’도 대화만 잘한다면 내가 생각하는 구현 방식을 Figma Make가 거의 80%이상은 구현해 준다.

활용 방법 : 디자인 전에 UX를 검증할 수 있게 된다.

그리고 내가 생각했던 Flow와 IA를 최대한 유지하면서 만들어주다 보니, 디자이너에게 작업을 요청하기 전에 UX 적으로 문제가 있는 부분들을 사전에 고민할 수 있는 단계가 추가되었다.

오히려 대대적인 개선이 있으면, 디자이너와 Figma Make를 활용해서 이런저런 고민을, 명령을 통해서 해결하고, 디벨롭할 수 있는 새로운 아이디어와 아젠다를 얻기도 한다.

기획자와 디자이너가 서로의 리소스는 최소화하면서 효과는 최대한으로 끌어올릴 수 있는 업무의 단계가 Figma Make로 해결이 된 것이다.

그리고 놀라운 건, Figma가 Figma Make에 대한 AI Beta 기간을 1년간 무료로 제공한다는 점이다.

이 1년 사이에 얼마나 많은 업무 효율이 올라갈 수 있을지 기대가 되면서도, 사실 무섭기도 하다.

💡 Google NotebookLM : 나만의 도서관이자 연구실

Chat GPT 등의 일반적인 LLM은 채팅 안에서 외부 검색 등을 활용해서 정확한 답변을 얻는 데에 집중한다면, Google의 NotebookLM은 지금까지 내가 작성한 문서들을 통해 나의 생각과 문서를 정리하는 것에 집중이 되어 있는 기능이다.

생각을 정리하기에 최적화된 구조

정리하고 싶은 생각과 연관된 문서들을 모두 ‘출처’ 영역에 업로드 후 가운데 채팅 영역에서 대화를 진행할 수 있다. 이때 답변은, 정해진 출처를 기반으로 답변이 제공되기에 생각이 적절하게 정리된다.

답변을 저장하고 싶은 경우에는 저장하여 오른쪽 노트에 아카이빙이 가능하고, 타임라인과 브리핑 문서 등의 생성을 요청할 때 일반적인 텍스트 기반이 아닌 마인드맵 형태로도 확인할 수 있다.

이 외에도 NotebookLM은 더 다양한 활용 방법이 있는데, 잘 사용하기 위해서는 조금의 학습이 필요한 허들이 존재하는 서비스라고 볼 수 있다.

NotebookLM도 현재는 Pro 버전이 한 달 무료로 체험할 수 있는 것으로 제공되고 있어서 체험해 보면 좋을 것 같다.

수많은 AI들 속에서 살아남으려면, 일단 많이 써봐야한다.

유용한 AI는 더 많이 있지만, 앞으로는 더 많은 AI 서비스가 우리의 업무를 대체하기 위해서 계속해서 생겨날 것이다.

사실 AI로부터 안전한 직업은 없다.

다만, 스스로가 AI를 더 잘 활용하려고 마음을 먹는다면 상생하면서 본인의 업무 역량도 성장할 수 있는 전환점이 될 수 있다는 생각이 든다.

자주 쓰겠다고 늘 다짐하지만, 분기 때마다 간신히 결산과 회고로만 돌아오는 사람.

그렇다. 또 이렇게 글을 쓴다는 건, 분기가 지났다는 것이다.

💡 2025년 상반기 : 해냈지만, 아쉬웠던 1분기와 개선해 나가는 중인 2분기

1분기 회고 글에서도 언급했듯, 2025년 1분기는 HyperLab의 대규모 업데이트하고, 사용자들에게 공개하기 위해 모두가 집중했던 시기였다.

대규모 업데이트는 성공적으로 마무리했지만, 그 과정에서 개인적으로도 팀 자체로도 개선해야 할 부분들이 존재했다.

그렇게 2025년 2분기는 1분기에 아쉬웠던 부분들을 개선해 나가기 위한 목표로 진행이 되었다.

📅 더 이상의 급한 개발과 업데이트는 없다! — 안정적인 로드맵 수립

가장 먼저 개선해야 할 부분은 제품의 Sprint 주기였다.
기획 → 디자인 → 개발 → QA까지 차례대로 이어지는 주기를 고수하기 위해 제품의 로드맵과 그에 따른 세부 개발 계획을 간트차트 형태로 세웠다.

간트차트를 세울 때는 2가지 기준을 세웠다.

1. 기획, 디자인, 개발의 Lock Down 기간이 안정적으로 확보될 것

2. 개발 조직뿐만 아니라 회사 내 모두가 쉽게 일정과 진행 상태를 확인할 수 있도록 작성될 것

2가지 기준을 통해서 작성된 간트차트는 회사에서 진행되는 정기 배포 일정과 로드맵에 대한 불필요한 커뮤니케이션이 감소하였다.

PM 입장에서는 또 하나의 관리 포인트가 증가한 것이기는 하지만, 커뮤니케이션의 효율성과 일정에 대한 체크를 이곳에서만 진행해도 된다는 장점은 나머지의 단점들을 모두 상쇄시킨다.

📮 고객이 어디서 어떤 글을 읽든 간에 똑같이 이해하도록 — NPI 프로세스 도입

고객마다 우리 제품을 다르게 이해하고 있다면, 우리부터 고객에게 동일한 메시지로 모두가 전달하고 있는지 확인하고 개선해 보기로 했다.

고객에게 메시지를 전달하는 PM, 마케팅, 영업이 모두 서비스와 그의 세부적인 기능들에 대해서 동일하게 고객에게 전달하고 있는가를 점검하고, 이를 프로세스화한 것이 ‘NPI(New Product Introduction)’ 프로세스다.

프로세스를 간단히 설명하면 다음과 같다.

PM은 PRD를 기반으로 제품 또는 신규 기능에 대한 전반적인 설명과 VP(Value Proposition), USP(Unique Selling Proposition) 등을 마케팅과 영업에 공유한다.

이후, 마케팅과 영업은 PM과 협업하여 고객에게 전달할 채널에 VP와 USP를 기준으로 고객이 동일한 가치로 이해할 수 있는 메시지 전략을 수립하는 형태다.

NPI 프로세스에 대한 효과는 아직 2분기부터 차근차근 수립한 프로세스대로 걸음마를 떼는 중이라 아직 확실한 성과는 보이지는 않은 상태지만, 분명 좋은 결과를 나올 것이라고 기대하고 확신한다.

이 부분에 있어서는 점차 안정적으로 자리를 잡으면 별도의 포스팅으로 공유하고자 한다.

🧭 2025년 하반기 : 좋은 제품이라는 가설을 증명해 내야 한다

2025년 상반기 동안은 대규모 업데이트와 이에 대한 개선을 위해서 꾸준히 노력했다.

HyperLab은 신약 개발 지식을 보유한 사용자 또는 내부 연구팀에 의해 제시된 Backlog 기반으로 성장해 왔다. 어쩌면 지금까지는 ‘좋은 제품을 만들기 위한 과정’이었다.

그렇다면 이제는 이 제품을 직접 만들고, 운영하는 사람들이 ‘좋은 제품을 증명’해야 하는 시간이 왔다고 생각한다.

📊 목표 1 : 데이터를 측정하고, 가설을 검증해야 한다

대규모 업데이트를 진행했고, 이를 지금까지 해왔던 데이터수집보다 더 심층적으로 측정해야 할 필요성이 있다.

분명 지금까지도 데이터를 분석하는 프로세스를 진행해왔지만, 우선순위 높은 Backlog들을 먼저 개선하고 새로운 기능으로 탑재하는 과정이 주로 진행되었기 때문에 데이터보다는 고객의 니즈에 집중해 왔다.

고객의 니즈가 어느 정도 반영된 지금,
그동안 HyperLab 서비스에 탑재된 기능들이 어떤 방식으로 사용되고,
우리가 Backlog 상에서 세웠던 가설들을 확인하고,

문제가 있다면 새로운 가설들을 다시 수립하고 개선하는 방식으로 진행하고자 한다.

이를 위해 팀 내에서 PM과 디자이너가 각각의 제품의 성공 지표를 측정하는 프로세스를 수립하였고, 이 프로세스에 의해서 검증하는 과정을 2025년 3분기부터 본격적으로 진행할 예정이다.

💰 목표 2 : 매출 극대화를 목표로 하는 다각화 전략 실행

좋은 제품임을 증명해 내고 있다면 좋은 제품을 어떻게 팔 것인가도 직접적으로 조금 더 고민해 봐야 한다.

제품은 계속해서 업데이트하고 신규 기능을 출시하겠지만, 더 적합하고 더 많은 고객에게 서비스를 제공하고 매출로 전환할 수 있는 고민도 해야 한다.

그래서 이 부분은 조금 더 구체화를 해봐야겠지만, 단순한 PM의 업무 범위가 제품을 잘 만드는 것에서 더 나아가 사용자를 직접적으로 유치하는 간접적인 영업의 역할도 필요하다면 수행해야 한다는 의미에서 시작되었다.

매출 극대화에 대한 목표 후기는 아마도 2025년 3분기 회고 때 그 후기를 아마 알 수 있지 않을까 싶다.

회고를 정리하며

2025년 상반기에 대한 회고를 간단히 해보았다.

이것 말고도 개인적으로도 고민은 있지만, 사실 상반기의 가장 핫한 이슈는 바로 아래의 내용이었다.

😢 리더가 되고 첫 팀원을 떠나보냈다.

그리고 PM은 QA를 잃어버렸고, 서비스의 품질이 걱정되기 시작했다.

팀의 리더가 되고 처음으로 팀원을 떠나보내는 순간을 경험했다.
그리고 PM인 나에게는 의지하던 QA 엔지니어를 떠나보내는 순간이기도 했다.

누군가에게는 QA 엔지니어가 서비스의 라이프 사이클에 있어서 중요도가 낮다고 판단할 수도 있지만, 나는 스스로 QA의 중요성을 강하게 주장하는 편이다.

HyperLab을 담당하면서 그동안 서비스의 품질은 크게 걱정한 적이 단 한 번도 없었다. 바로 QA 엔지니어가 있었기 때문이다.

기획자, 디자이너, 개발자가 QA의 역할을 수행할 수는 있지만 완전히 대체하는 것은 불가능하다.

자신이 작업한 결과물을 자신이 검증하는 것은 사람에 따라 다를 수는 있지만 리뷰에 가깝지, 타인의 시선으로 검증하는 것이 아니기 때문에 시선과 사고방식이 어느 순간 고이기 마련이다.

그렇게 되면, 알 수 없는 오류들이 잡히지 않은 상태로 배포가 이루어지고 사용자는 그런 케이스들을 스스로 직면하게 되는 상황이 발생한다.

기획자, 디자이너, 개발자가 본질은 제품을 잘 만드는 것에 집중한다면, QA 엔지니어는 제품을 안전하게 만드는 것이 본질이라고 생각한다.
이것이 QA 엔지니어가 존재하는 이유라고 나는 생각한다.

그만큼 의지했던 QA 엔지니어였기에 더 좋은 미래를 향해 나아가는 것은 응원해 줘야 하는 것이 맞지만, 나 역시도 아쉬움이 많이 남기에 이런 것도 내 커리어에 있어서 성장해 나가는 과정이라고 생각한다.

현재 QA 엔지니어를 새로 채용하고 있으니, 좋은 분이 오셔서 HyperLab을 함께 좋은 퀄리티의 제품으로 함께 만들어 나가길 기대해 보려고 한다.

🏃‍♂️ 진짜 회고를 정리하며 2025년 하반기를 위해

늘 회고할 때마다 여러 가지 후회와 반성 그리고, 새로운 목표가 반복되면서 여러 가지 감정이 드는 것 같다.

그래서 더욱 회고는 다음 분기를 또 나아가야 할 스스로에게 숙제를 주는 것 같기도 하다.

그리고 마지막으로, 2025년 하반기에는 지금보다 더 열심히 블로그 포스팅을 하고 좋은 내용을 공유할 수 있도록 노력해야겠다.

이번 2025년 분기는 내가 PM이라는 직업을 가진 이래로 가장 순식간에 지나간 3개월이었던 것 같다.

순식간에 지나간 1분기였지만, 그만큼 너무나도 많은 일들이 지났던 3개월이었기에 오랜만에 회고하고자 한다.

🎯 3개월 업무 요약 = HyperLab, 대규모 업데이트 진행

3개월 간 정신이 없었던 이유는 담당하는 서비스인 ‘HyperLab’의 대규모 업데이트가 있었기 때문이다. https://hyperlab.ai/

HyperLab은 이제 ‘Ver 2.0’

특히, 이번 HyperLab의 업데이트는 기존 HyperLab을 1.0 버전에서 2.0 버전으로 업데이트가 되는 수준의 기능들이 새롭게 추가되었다.

새롭게 추가되는 기능을 통해서 HyperLab은 기존 AI 기능의 예측 강화와 더불어 사용자의 신약 개발 프로세스에 있어서 더 넓은 범위의 프로세스까지 HyperLab에서 사용할 수 있게 되었다.

점점 HyperLab 안에서 사용자가 할 수 있는 것들이 많아지면서 플랫폼 생태계를 더 넓혀가고 있다는 좋은 의미이기도 하다.

기적에 가까운 업데이트 일정

2024년 12월부터 2025년 4월 10일에 Production에 배포가 있기까지 HyperLab을 다 같이 만드는 HITS의 모든 구성원들이 밤낮을 가리지 않고, 열심히 만들어서 목표하고자 하는 일정에 무사히 릴리즈 할 수 있었다.

어제 드디어 3개월 간의 대장정을 막을 내리기 위한 Jira 버전을 릴리즈하려고 보니, 이슈의 개수가 너무나도 많아서 캡쳐해서 팀원들에게 공유했던 Slack 메시지를 가져왔는데, 개수만 봐도 쉽지 않은데 이걸 어떻게 해냈을까 하는 생각이 자꾸만 들었다.

다시 한 번 이를 무사히 마무리 할 수 있게 모두 협력해 준 HITS의 구성원들에게 감사하다.

🕹️ Continue = Product Management 본연의 업무에 집중하다

이번 대규모 업데이트를 하면서 나의 업무 프로세스에 변화가 있었다면, Sprint 관리와 기능 기획에 조금 집중되어 있었던 PM 업무의 커버리지가 ‘Product 자체에 대한 관리’ 영역까지로 더 넓어졌다는 점이다.

Product의 가격 정책, 프로모션 전략, Unique Selling Point들까지 직접 문서화를 하고 팀원들에게 공유하는 등의 직접적인 관여를 하면서 조금 더 제품이 사용자에게 어떻게 인식되고, 포지셔닝되어야 하는가에 대한 부분들도 관여하고 고민할 수 있는 계기가 되었다.

이러한 부분들이 사실 앞으로의 커리어에 있어서도 중요한 경험이 될 것으로 생각하던 찰나에 이런 계기가 와서 좋았지만, 쉽지 않은 고민들이 있어서 수많은 시행착오를 조금 더 겪어보면서 연습해 봐야 할 것 같다.

P.S. 이로 인해 Slack에 더 자주 나타나는 공지쟁이가 되었다.
(마을 이장님 수준)

🎢 Stop = 수많은 우선순위 간의 외줄타기

3개월간 HyperLab의 대규모 업데이트에 집중하기는 했지만, 계속해서 그다음 Step에 대한 우선순위를 끊임없이 고민하고, 미리 준비를 해왔다.

새로운 기능 vs 사용성 강화

우선순위를 설정하는 데 있어서 가장 중요한 부분은 ‘사용자의 문제를 얼마나 해결하는가, 그리고 얼마나 만족시키는가’의 관점이다.

그리고 이 관점을 해결하는 2가지의 가장 큰 방법은 ‘새로운 기능’ 그리고 ‘기존 사용성 강화’가 있다.

내가 담당하는 HyperLab은 ‘새로운 기능’의 업데이트에 계속해서 초점을 맞추고 서비스를 발전시켜 왔다. 이런 부분이 틀리거나 잘못됐다는 것은 아니다. 새로운 기능을 통해 더 많은 고객을 만족시키고, 더 많은 매출을 가져올 수 있기 때문이다.

하지만, 새로운 기능들이 계속해서 추가되는 시점에 맞춰서 기존의 사용성도 계속 뒤돌아보면서 사용자가 잘 쓰고 있는지, 어딘가 이탈하는 부분이 발생하고 있지는 않은지 체크하면서 개선해야 한다.

더욱이 HyperLab이 목표로하는 ‘플랫폼 생태계’라는 것을 생각한다면 이런 부분들이 필요한 부분이다.

항상 그 사이에서도 우선순위에 고통 받는 위태로운 외줄타기를 스스로부터 그만둬야 한다는 생각이 강하게 들었다.

두 마리 토끼를 다 잡는 것이 어렵겠지만, 상황에 맞춰서 적절히 우선순위를 정하는 것이 나의 역량이라고 생각이 들었고 방법은 있을 것으로 생각하고 2분기를 해쳐 나아가야겠다.

📈 Start = 제품 / 팀 / 커리어 모두 우상향하기

1분기를 팀원들과 결산하면서 각자의 올해 동안 달성할 개인적인 업무 목표, KPI 등을 점검하는 시간을 가지면서 내 스스로도 고민을 했다.

간단하게 정리하면 이전 2024년의 회고에서도 그랬듯 2025년에는 제품, 팀, 그리고 나의 커리어까지 모두 잘 관리해서 ‘모두 우상향’할 수 있도록 하는 것이 목표다.

제품의 우상향을 위해서 Stop에서 외쳤던 것처럼 새로운 기능, 사용성 강화, 그리고 매출까지 꾸준히 고민하면서 발전시켜야 한다.

팀의 우상향을 위해서는 팀원들이 지치지 않고, 개인의 목표를 달성하고, 업무를 하는 데 있어서 문제가 있지 않도록 존중하고 서포트해 주어야 한다.

마지막은 내 커리어의 우상향을 위해서는 위의 2가지 제품과 팀의 목표를 달성하고, 개인적으로는 방황하지 말고, 지치지 않아야 한다.

2025년 1분기 종료, 새로운 분기를 맞이하며

회고 내용이 길어지다 보니 결론은 짧은 게 좋겠다.

너무 정신없이 흘러갔다.
잘 버텨 온 나 자신에게 칭찬하며, 2분기는 더 잘 해냈으면 좋겠다.

2024년 결산은 아래 링크를 확인 바란다.

👉 2024년 결산, ‘나’라는 제품의 PM을 담당하다.

1. 잘했다고 생각한 것

1.1. 채용 인터뷰

결산에서도 이야기했듯, 나를 되돌아보는 계기와 뿌듯함을 느끼게 된 계기가 되었다. 주기적으로 타인의 시선을 통해 나를 돌아보는 건 자기 객관화에서도 좋은 부분이지 않을까 생각이 든다.

1.2.Slack 내부 릴리즈 공지

하이퍼랩을 정기 릴리즈를 하고 나면, Slack을 통해 히츠 내부 구성원들에게도 릴리즈 소식을 알려주는 공지를 진행하고 있다. 이러한 공지를 하고 나면, 너무 뜨거운 반응과 댓글을 달아주시는데, 이러한 반응을 통해서 매번 릴리즈 때마다 용기와 응원을 얻고, 다음 릴리즈 준비도 잘해야겠다고 다짐하는 계기가 된다.

그리고 나만 그런지는 모르겠는데, PM들은 다 이런 반응들로 먹고사는 사람들이 아닌가 싶다.

1.3. 멤버들과의 비공개 회고

이번에 개인적으로 업무 시간을 활용해서 비공개 회고를 진행했었다.
정말 공식적으로 말하기 힘들었던, 일하면서 발생했던 일들에 대한 본인들의 비공식적인 이야기들을 들었다.

‘비공개’라는 단어가 주는 힘은 생각보다 엄청나게 강력했다.
하고 싶은 이야기를 자유롭게 쓰고, 본인들의 진심을 회고 시간에 꾸밈없이 이야기를 해주었다.
그것 또한 사실 나라는 사람에 대한 신뢰가 있어서 말해주는 것이라는 것을 알기에 더더욱 그들의 이야기를 나에게 해주어서 고마웠다.

그들의 이야기를 통해서 더더욱 멋진 케미스트리를 위해 노력해야 하는 PM이 되려는 연습을 열심히 하고자 한다.

1.4. 여행 브이로그 만들기

👉유튜브 링크 바로가기

올해부터 영상으로 여행을 기록하고 개인 채널에 업로드를 해보고 있다.

사진은 사실 당시의 순간을 바로 공유하고, 구경하는 데에는 좋지만 결국 나중에 시간이 지나서 그 여행의 생생함은 느껴지지 않다 보니 자주 찾아보지 않게 되는 것 같다.

그러나 브이로그는 내가 그때 무슨 생각을 하면서 영상을 촬영했고, 그때의 상황과 날씨가 어땠는지의 대한 내용들이 모두 포함되어 있어서 더 추억에 잠길 수 있었다.

그리고 가장 중요한 점은 여행을 다녀오고 나서 다시 업무에 지쳐갈 때, 다시 힐링하고 일할 수 있는 힘을 주는 요소가 내게 하나 더 생겼다는 것이다.

2. 아쉬웠다고 생각한 것

2.1. Sketch 문서

Sketch 문서는 기획 문서를 도메인 전문가 ↔ 기획자 ↔ 메이커(디자이너, 개발자, QA)와의 문제점과 해결 방안에 대한 Sync가 되지 않는 문제를 해결하기 위해 고안해 냈던 프로세스였다.

처음에는 효과적이라고 생각했다. 1 Paper로도 PRD와 기획서가 모두 합쳐지고 개발의 시작점도 앞당길 수 있다는 점이 목표였기에, 실제로 그러한 방향으로 타임라인이 진행됐기 때문이다.

하지만 점점 신규 기능의 규모가 커지고, 필요로 하는 기능의 양과 함께 도메인에 대한 내용이 점점 심화된 내용으로 흘러가면서 Sketch는 효력을 잃기 시작했다.

기존 Sketch의 내용을 요약하면 ‘왜 만들어야 하는가?’, ‘어떤 기능인가?’, ‘어떻게 만들어야 하는가?’의 3가지에 대한 내용이 포함되어 있다. 하지만 점점 ‘어떤 기능인가?’에 대한 설명이 복잡해지다 보니, ‘어떻게 만들어야 하는가?’는 뒷전이 되고, 메이커들을 이해시키기에 바빴다.

결국 ‘어떤 기능인가?’를 쉽게 설명할 수 있으면, ‘어떻게 만들어야 할까?’는 기획자가 작성하지 않아도 메이커들이 스스로 감을 잡고 작업을 할 수 있지 않을까?

라는 생각이 들게 되었고, 2025년부터는 이러한 방향성으로 Sketch 문서를 작성하는 프로세스를 개선해 보고자 한다.

👉 이전 Sketch 문서 관련 글이 궁금하다면?

혼돈의 기획 문서 통일하기 (1) 빈틈 & Sync 줄이기 (Sketch의 탄생)

2.2. 미처 파악하지 못했던 회고의 순간들, 그리고 매니징

이해관계자와의 커뮤니케이션과 매니징은 내게 아쉬운 1년이었다.

우선순위 조정에 대한 아쉬운 매니징

늘 언제나, 여러 이해관계자의 중간에서 모든 입장을 고려해야 하다 보니, 한쪽에서 불만이 계속 나오는 것에 대한 컨트롤이 어려웠다.

특히 히츠의 경우, 메이커들과의 관계에 더 나아가서 고객의 입장을 대변하는 히츠 내부의 연구하시는 분들과의 입장 조율도 어려웠던 순간들이 있었다.

아마도 가장 주된 이해관계는 우선순위였을 것 같다.
(사실 이게 모든 것의 가장 근본적인 문제일 것이다.)

누구나 자신의 업무와 관계가 높은 것들을 높은 우선순위로 가져갔으면 하는 마음에서 발생하기 때문에 PM으로써 이 역할을 충실히 해내지 못했던 것 같은 아쉬움이 많이 남는다.

개인의 인내심 성장 필요

개인적으로는 인내심이 부족했던 한 해였던 것 같다. 몰아치는 일이 많았다 보니, 사실 일을 해치는 것을 급급하게 처리했던 것 같았던 순간들이 있다. 그렇기 때문에 기존보다도 인내심의 한계점도 짧아지고, 스스로 속으로 화도 자주 났었던 것 같습니다.

그러고 나서 매일 혼자 밤에 생각을 통해서 정리를 하지만, 조금 더 감정을 절제하고, 이성적으로 판단하려는 생각을 계속해야 할 것 같다는 반성을 했다.

회고를 조금 더 빨리했다면

좋았던 순간이 비공개 회고였다면, 아쉬웠던 순간 중에서도 회고가 있다.

1년을 돌아보면서 회고를 더 잘했다면, 조금 더 문제를 빨리 파악할 수 있었던 시간들이 있었던 것 같다. 분명 문제가 커지기 전에 PM으로써 더 빠르게 회고를 하고, 속 깊은 대화를 나눌 수 있었다면 더 큰 문제로는 이어지지는 않았을까 생각이 들었다.

이러한 순간들을 내년에는 아쉬워하지 않기 위해서 이 회고가 완벽한 해결책이 되지는 않겠지만, 그래도 문제가 더 커지는 경우의 수를 최소화하기 위해서 시도해 보면 좋을 것 같다.

2.3. 기획 문서의 Notion과 Confluence 병행

현재 팀에서는 기획 문서를 Notion과 Confluence를 문서 유형에 따라 병행해서 사용하면서 두 개 채널의 기획문서의 Sync가 불일치하는 문제 및 한 쪽을 기획 이후에 방치해버리는 형태가 되어 버리고 있다.

Notion 프로세스 vs Confluence 프로세스

이러한 이유는 기획/디자인/개발/QA 이외의 Jira와 Confluence를 사용하지 않는 도메인 관련해서 소통해야 하는 커뮤니케이션 관계자들이 있기 때문이다.
Notion을 통해서 소통하는 이유는 그들이 사용하는 주요 채널이 Notion이기 때문이다.

그래서 기획의 프로세스 채널은 Backlog부터 기획의 초안인 Sketch를 작성하는 단계까지는 메이커들과 소통하는 단계가 아닌, 개발 조직 이외의 도메인 전문가와 소통하기 때문에 Notion에서 기획 문서를 작성한다.

이후 본 기획을 진행할 때는 메이커, QA와 소통이 원활한 Confluence로 채널을 옮겨서 기획 문서를 작성한다.

Sync하거나, 한쪽은 포기하거나

물론 프로세스에 따른 소통 관계자가 완벽하게 분리되어 있다면, 채널 역시 분리되는 것도 크게 문제가 되지는 않는다. 하지만, 문제는 수정 사항이 발생했을 때, 수정 사항에 대한 Sync를 맞추는 작업에서 발생한다.

모든 기획 문서의 Sync를 맞추는 것이 기본이기에 처음엔 Notion과 Confluence의 기획서 모두를 수정했지만, 결국 이것이 비효율적으로 공수가 드는 상황에서는 급하게 Confluence 문서만 지속적으로 수정하고 업데이트를 진행했다.

결국 그럼 모든 히스토리는 Confluence에만 남게 되고, PRD는 초기 버전의 형태만 유지된 채로 더 이상 갱신되지 않고 업데이트가 이루어지지 않는 참사가 계속 이어져 왔다.

해결책 : Wiki의 역할과 실제 기획 문서의 역할로 분리하자

문제를 해결하기 위해서는 Sketch 문서에 대한 프로세스와 PRD 문서가 분리되어 있는 문제, Sketch 문서와 일부 기획서의 역할이 겹치는 문제까지 모두 동시에 함께 해결해야 한다.

따라서 이 문제는 전반적인 기획 프로세스에 영향을 미치는 부분이므로, 내년 1분기가 지나가기 전에 올바르게 바로 잡아야 하는 우선순위 Highest로 개선할 예정이다.

그리고 아직 구체화 되지 않았지만, 결국 해결 방안은 Notion은 PRD의 역할만 수행하고, 모든 기획 문서는 Confluence에서 통합하여 관리하는 형태로 가려고 한다. 이 부분은 추후 개선하고, 다른 콘텐츠로 작성하도록 하겠다.

3. 내년에 해보고 싶은 것들

3.1. 세트 효과 : 팀 케미스트리 만들기

내년부터 팀을 매니징하는 데 있어서 가장 해보고 싶은 ‘이상적인 소설’이 하나 있다면, 팀의 케미스트리를 만드는 것이다.

흔히 게임에서 동일한 이름을 가진 장비를 착용하면 세트 효과라는 것이 발동되는 것처럼 우리 팀도 다 모여서 각자 맡은 일을 다할 때 더 효과가 커지는 그런 케미스트리를 만들어보고 싶다.

어떻게 이 케미스트리를 만들지는 고민해 봐야겠지만, 우선 내 나름대로의 방향성을 갖고 팀원들도 그것에 동의할 수 있도록 팀의 2025년의 방향성을 설정하는 것부터 시작해야 하지 않을까 싶다.

3.2. Career Book 만들기

‘커리어 북’이라는 것을 만들어 보려고 한다.

누군가는 이것을 이력서 또는 포트폴리오라고도 생각할 수도 있다. 하지만 내가 생각한 ‘커리어 북’은 이력서보다는 나만의 ‘커리어 연대기’에 가깝게 생각하고 있다.

아직 구체적으로 정해진 사항은 없지만, PM 커리어를 시작한 이래로 매년 또는 어떤 특정 순간마다 커리어에 있어서 어떤 중요한 결정을 했고, 어떤 중요한 결과를 낳았는지를 적어 놓은 형식으로 써보려고 한다.

3.3. 머리를 비우는 법에 익숙해지기

요즘 굉장히 중점적으로 생각하고 있는 주제다.

열심히 살고, 부지런히 생각하면서 사는 건 생산적인 인생을 사는 것이라고 생각이 들었다. 그러나 어느 순간부터 꼭 굉장히 열심히 산다고, 열정적으로 일한다고 결과가 바뀌지는 않았을 것 같다는 생각이 들었다.

오히려 생각을 계속 멈추지 않고 살아가니까, 성격이 예민해지고 불안해지는 것 같은 느낌이 들었다. 그래서 내년부터는 머리를 주기적으로 비우고, 리프레시를 할 수 있는 방법을 찾아보려고 한다.

현재는 여행이 유일한 리프레시의 방법이었는데, 주기가 거의 분기별로 이기 때문에 조금 더 자주 생각을 비울 수 있는 방법을 찾아야 할 것 같다.

이 도전은 앞으로 나의 커리어를 더 롱런할 수 있도록 지지할 뒷받침이 되는만큼 열심히 해보려고 한다.

2024년을 마무리 지으며

2024년을 한마디로 정리하면, ‘부지런했다’라고 표현할 수 있을 것 같다.

부지런히 일했고, 부지런히 생각하고, 부지런히 사람들을 만났으며, 부지런히 여행도 다녔다. 그리고 부지런히 개인적으로 브이로그도 만들고, 달력도 만들었을 정도로 기억에 남는 순간이 많은 1년이었다.

그러나 반대로 부지런히 아팠고, 부지런히 스트레스도 받았기에 뒷감당할 것들도 많았던 1년이기도 하다.

내년은 올해보다는 조금은 여유 있게, 조금은 덜 불안한 마음으로 2025년을 살아가 보려고 한다.

2024년의 마무리와 동시에, 2025년을 맞이하기 위한 글로 내가 현재 인스타그램에 주기적으로 포스팅하고 있는 위로 글 중 하나를 가져와서 회고를 마무리 지으려고 한다.

2025년도 2024년과 크게 다르지 않을 테니, 너무 걱정하지는 말고 내년의 나에게 맡기길.

나뿐만이 아닌, 이 글을 읽는 모든 사람들이 그러한 마음으로 2025년을 살아가길.

어느덧, 벌써 OO 때가 되었다.라고, 계속 쓰는 것이다.

그만큼 내가 블로그의 글을 포스팅하는 주기가 최소 1분기 이상이 되어, 계절이 바뀌고 우리가 입는 옷들이 바뀐다는 뜻이다. (조금 더 자주 쓰려고 노력해야 할 것 같다.)

이렇게나 혼자서 체감하는 시간의 변화도 크지만, 회사에서의 1개의 분기는 비즈니스적, 또는 회사의 생존 여부에 있어서도 엄청나게 거대한 시간이다. 하지만 1개의 분기들도 4번의 분기가 지나면 1년이 된다.

이렇게 보면 1년은 엄청나게 소중한 시간인 셈이다.
오늘은 2024년의 4개의 분기가 지났으니, 1년에 대한 결산을 해보고자 한다.

1. Only Hyper Lab : 하나의 서비스만 오롯이 담당했던 1년

이전 회사의 경험과 다르게, 올 한 해는 다른 프로젝트나 서비스를 함께 담당하지 않고, 하이퍼랩(Hyper Lab)’ 1개만 담당하고 집중했던 시기였다.
그만큼 다른 곳에 정신 팔리지 않고, 담당한 서비스의 발전을 위해서만 고민하고, 개선하려고 노력했던 것 같다.

팀원들과 2024년을 돌이켜보려고 여러 가지 결산을 위한 데이터를 찾아보다 보니, 올해 하이퍼랩은 공식 릴리즈를 17번을 진행했다.
Changelog를 기준으로 통계를 냈기 때문에, Hotfix 등을 생각하면 더 많은 릴리즈가 이루어진 셈이다.

특히 17번의 릴리즈를 하는 동안, 롤백을 하거나 배포를 연기하는 등의 이슈 상황도 없어서 꾸준히 Sprint 기간과 릴리즈 계획을 온전히 지켜준 디자이너, QA, 개발자들에게도 너무나도 고마운 한 해이기도 하다.

하지만 그렇기에 실수도 많았고, 아쉬움도 많았다.

고객 데이터가 충분하지 않았고, 편향적인 고객의 의견에 무게가 쏠리는 기획이 나와서 모두가 방향성에 대해 동의하지 않는 부분의 개발이 이루어지기도 했었다.
그 가운데서 방향을 잘 잡고 나아가야 하는 사람이 PM인 것을 알면서도 정신없이 치고 들어오는 업무량에 나도 하나의 기획을 쳐내는 공장처럼 일해버리는 태도가 나왔기에 아쉬운 상황들이 발생했다고 생각한다.

그래서 더욱 내년에는 PM으로써, 제품을 담당하는 사람으로서 아쉬운 상황을 만들어내지 않도록 노력해야겠다는 다짐이 아니라, 해내야 한다고 생각했다.

2. Who am I : Product Manager로써의 나를 되돌아보다

올해는 공적인 공간과 타인의 시선을 통해서 PM의 커리어를 쌓아가고 있는 나를 되돌아볼 수 있는 계기가 많았다.

첫 번째는 링크드인이다.

나는 기존에는 링크드인에 열심히 포스팅하던 사람이 아니었다.
하지만 올해 하반기가 지나서는 링크드인에 열심히 포스팅하고 있다.
그것은 바로 ‘정제된 글쓰기’ 능력을 습득하기 위해서다.

링크드인은 개인적인 나의 일상이 아닌, 공적으로 나의 일상이 보이는 곳으로 내게는 인식된다. 그렇기 때문에 조금 더 커리어적인 글과 정돈된 생각으로 글을 포스팅하게 되는 것 같다.

이러한 태도로 링크드인을 대하는 나의 관점은 나의 PM 커리어 중니어 시기에 있어서 새로운 영감을 주게 되었다.
단순히 누군가의 기술과 서비스 관점을 무작정 따라 하는 것이었다면, 이제는 스스로 서비스를 대하는 태도와 철학을 수립할 수 있도록 도와줬고, 그것은 현재 내가 담당하는 서비스 하이퍼랩(Hyper Lab)에도 적용의 대상이 되었다.

두 번째는 나의 PM 직군에 대한 인터뷰였다.

히츠 PM 인터뷰 | 신약개발 도메인에서 최초이자 최고인 서비스를 만들고 싶어요

목적은 나와 함께 현재 재직 중인 ‘히츠(HITS)’에서 나와 함께 일할 PM을 찾기 위해 홍보용으로 사용될 채용 인터뷰였다.

하지만, 이 인터뷰가 나의 커리어를 한 번 되돌아보는 계기가 되었다.
살면서 타인의 시선으로 나의 커리어를 바라본 적이 없었는데, 누군가의 시선으로 작성된 글로 나의 커리어를 바라보니 어떤 모르는 PM의 이야기처럼 느껴지는 것도 신선했고, 그래도…”아직 잘하고 있구나”라고 보람이 느껴졌던 순간이었다.

그리고 주변 사람들이 응원해 주는 글도 나에게 아주 큰 힘이 되었다.

특히, 이 글을 작성해 주신 히츠의 윤하님의 인터뷰 후기 글이 나에게는 인상적이었다.
사실 다른 PM도 많이 만나보고, 인터뷰도 많이 해보셨을 텐데 그래도 본인이 생각하는 PM의 재능을 가진 사람에 부합한다는 말이 참 좋았다.

이렇게 좋은 글을 작성해 주신 윤하님께 늘 감사하다.
(아직도 가끔 고민이 많아질 때 찾아가서 읽는다.)

3. 떠나야 살겠더라 : 주기적으로 떠난 여행

올해의 나는 어느 때보다 여행을 많이 다녔다.

제주도, 호주, 일본 등으로, 거의 분기별로 여행을 다녔다. 제주도는 올해만 벌써 3번을 다녀왔다.

사실 여행을 갔다고 해서 온전히 ‘Slack’을 끊지는 않았다.
이건 PM의 숙명과도 같아서 카카오톡보다 더 쉽지 않은 마약이다.
‘자꾸 봐야 할 것 같고, 읽어야 할 것 같고, 답장해야 할 것 같고’…ㅎㅎ

그럼에도 여행을 가서 Slack을 보는 건 스트레스가 아니었던 것 같다.
어쩌면 내 눈에 보이는, 내가 현재 느끼고 있는 이 장소가 나에게 즐거움을 주기 때문이 아닐까 하는 생각이 들었다.

작년에도 물론 그랬지만, 올해도 어김없이 여행은 번아웃이 찾아올 때쯤 나에게 유일한 탈출구가 되어주었다. 그리고 그러한 여행을 통해서 매년 만들고 있는 나의 2025년 달력도 완성되었다.

2024년의 결산을 마무리하며

2024년과 결산과 회고를 하나의 포스팅으로 마무리하려고 했는데, 작성하다 보니 2024년에 대한 결산에 대해서 하고 싶은 이야기가 많았던 것 같다.

다음 포스팅에서 정말로 회고를 하면서 2024년보다 더 나은 2025년을 보내기 위한 생각을 정리하고자 한다.

2024년도 어느덧 3분기가 지나고, 4분기가 시작되었다. 3분기가 지났다는 것은 벌써 어느덧 히츠에 합류한 지 1년이 넘었다는 말이다. 3개월 단위로 커리어가 극적으로 변화하지는 않지만, 서비스와 일하는 방식은 실시간으로 변화하는 것 같은 느낌이 든다.

그래서 오늘은 2024년 3분기의 이야기를 떠올려보고자 한다.

- Liked & Keep -

기획 문서를 뒤집어 엎다 → 모든 사람과 원활한 소통을 위한 기획 문서 만들기 대작전

일반적인 서비스 기획서로는 IT 직군 이외의 사람들 및 신약 개발 연구원들과 소통하기 힘들다. 하지만 모든 사람과 하나의 문서로 소통하는 규칙은 필요하다. 그래서 PRD와 서비스 기획서의 중간 단계인 ‘스케치(Sketch)’ 문서라는 것을 만들었다.

작성은 빠르게, 상세 기획은 최소 조건으로, 소통은 모두가 이해하기 쉬운 언어로, 문서의 길이는 최대한 짧게.

이에 대한 성과 및 후기도 하나의 콘텐츠로 발행할 예정이지만, 간단히 말하면 ‘Sketch만으로도 개발을 시작할 수 있게 되다’라고 할 수 있겠다.

모두가 자신의 작업에 대해서 이해할 수 있는 수준으로만 최소한의 기획서를 작성하고, 그 기반으로 sync를 맞추는 미팅을 진행하며 그 자리에서 자신들이 Sketch 기반으로 작업할 때 추가로 필요한 궁금증들을 Direct로 질문하고 얻어간다. Q&A를 통해 나온 부분들은 PM이 한 번 더 Sketch 문서에 업데이트하고, 다시 공유한다.

모든 이해관계자에게 후기를 물어본 것은 아니지만, 누군가는 훨씬 이해하기 쉬워졌다는 의견이 있었다. 어떻게 보면 기획을 두 번 하는 일이 될 수 있겠지만, 그만큼 커뮤니케이션에 소모되는 비용이 줄어든다면 그 가치가 문서를 두 번 작업하는 것보다 더 높다고 생각한다. 적어도 도메인이 특수한 서비스를 만드는 사람의 입장에서는 말이다.

고객 데이터를 낱낱이 파헤치다 → 수집하고 있는 모든 데이터 쿠킹, Dashboard 만들기

신약 개발을 위한 SaaS라고 해서 언제까지 신약 개발에 필요한 기능 중심으로 Waterfall 형태로 일하기는 어려웠다. 어떤 도메인이든 간에 SaaS이면서 플랫폼이라면, UX를 고민하고 사용자가 서비스 안에서 헤매지 않도록 쉽게 만들어 놓아야 한다.

그러기 위해서는 절대적으로 실제 사용자의 이야기가 필요하다. 내부의 고객이 있더라도 그들은 실제 ‘돈을 내고 사용하는 고객’이 될 수 없다.

그래서 진짜 고객들은 왜 이 서비스에 접근하고, 어떤 것을 기대했고, 하이퍼랩은 기대치를 얼마나 충족시키고 있는지, 어떤 Painpoint를 갖고 있는가에 대한 데이터를 모두 모았다. 그리고 그 데이터를 기반으로 아직은 세상에 공개될 수는 없지만, Dashboard를 구축하고 있다.

이 기반으로 아직은 미약하지만, 조금씩 Backlog를 쌓아나가고 있고 Sprint 운영과 계획에 참고하고 있다. 앞으로는 더 자세한 데이터를 수집하면서 고도화할 예정이다.

- Lacked -

깊게, 오랜 시간 고민하지 않았던 일부 기획들

매니징, 프로세스 개선 등에 집중하다 보니 전반적으로 ‘서비스 기획’이라는 것에 대한 퀄리티가 부족했던 것 같다는 생각이 들었다. PRD를 다른 이해관계자가 작성하고, 다음에 시작되는 Sprint에 개발이 시작될 수 있도록 기획 문서를 준비해 두어야 하니, PRD에서 크게 변화하지 않은 상태로 기획을 진행했던 순간들이 있었다.

이런 스노우볼은 결국 개발하면서 잦은 수정으로 이어지고, 작업자들에게도 반가운 상황으로 이어지지는 않는다. 이러한 악순환을 방지하기 위해서는 기획을 할 때 최대한 많은 사항을 고려하고, 부족한 시간에 억지로 기획하지는 않아야 한다. 하지만, 늘 그렇듯 기획에 쏟는 물리적인 시간과 서비스가 발전하는 시간을 앞당겨야 하는 PM의 딜레마는 끝없이 이어질 것 같다.

- Try -

곧 새로운 PM이 합류한다 → PM 고유 프로세스 수립하기

다행히도(?) 새로운 PM이 10월 중으로 합류한다. 그동안은 혼자 일하고, 이해관계자들과의 협업 프로세스에 집중하고 개선해 나갔다면, 새로운 PM이 왔을 때의 PM 간의 프로세스를 어떻게 정리하고 개선할지에 집중하고 있다.

- 총평 -

현재 커리어의 포지션에 대해서 고민을 많이 해 본 시기

이번 3분기 동안은 많이 고민하고, 커리어에 대해서 많이 고민해 본 시기인 것 같다. 지금까지 쌓아온 커리어를 돌아보고, 앞으로 더 나아가고 발전하기 위해서는 어떤 유형의 PM으로 포지션을 가져가야 할지 고민을 많이 했다. 이 글을 쓰고 있는 지금도 계속해서 고민하는 중이다. (제주도의 어느 카페에서 비가 추적추적 내리는 성산일출봉의 모습을 바라보면서 말이다.)

조금 더 주도적으로 개선에 대해 고민해 봤던 시기

개인적인 커리어 성장으로 보았을 때는 위의 2가지 좋았던 점을 포함해서 조금 더 주도적으로 개선에 대해 고민해 봤던 시기였던 것 같다. 더 많은 사람들과 효과적으로 협업하기 위한 방법을 고민했고, 개인적으로는 나만의 방식을 프로세스화 하기 위한 노력도 하고, 그런 프로세스들을 연마하고 있는 과정이라고도 생각이 든다. 그렇게 해서 갈고 닦아 나라는 PM을 완성하고, 누군가에게 긍정적인 영향을 주지 않을까 하는 생각도 든다.

주니어 시절에는 일하는 능력이 필요했고
중니어 시절에는 모든 상황에 대한 기록과 매니징, 처리가 필요했다.
그러고 나서 시니어를 보니 중요한 순간들에 대한 확실한 의사결정과 책임이 필요했다.

그리고 나는 이제 중니어 정도에 접어들었고, 이번 분기는 이런 또 다른 성장통을 겪고 있다는 결론으로 회고를 마무리하고자 한다.

세상에 기획 문서의 종류는 너무나도 많다.

PM이라는 업무를 수행하면서 가장 많이 하는 일은, ‘문서 정리’다.

수많은 문서를 정리하지만, 그중에서도 가장 빈번하게 정리하는 문서는 바로 ‘기획 문서’가 아닐까 싶다.

동일한 Backlog에 대해서도 관련된 기획 문서가 다양하게 발생한다. PRD, Flow chart, IA부터 정책서, 기능 정의서, Wireframe, 알림 등의 문서를 골고루 작성하게 된다.

각각의 문서는 서비스를 개발하는 데 있어서 분명한 목적을 기반으로 작성이 되는 건 맞지만, 그에 비해 이러한 문서를 관리하는 PM의 입장에서는 문서가 점점 쪼개질수록 문제점이 발생한다.

그래서 이러한 문제를 해결하기 위해 기획 문서 및 프로세스를 통일하는 과정을 업데이트하려고 한다.

나 말고 다른 사람들은 모든 종류의 문서를 보지 않는다.

사건은 다가와 아오에, 거세게 커져가 아오에

쓰읍…슬프지만 사실이다.

서비스를 만들기 위해서는 어떤 Backlog와 관련해서 작성된 모든 기획 문서를 읽고 만드는 것이 이상적이다. 하지만, 안타깝게도 대부분의 메이커들은 자신에게 필요한 문서만 골라서 보고 작업을 시작한다.

긍정적으로 생각하면 ‘발췌독’이라고 하면 될 것 같다.

그렇게 누구에게는 기능 정의서가 가장 메인이 되는 문서고, 또 누군가에게는 Wireframe이 가장 메인이 되는 문서가 된다.

Su su su Super 누락…

그렇다 보니, 각각의 문서에서 발생하는 부가적인 커뮤니케이션에서 문서의 수정 사항과 버전이 조금씩 달라지고, 이렇게 벌어진 버전 차이의 간격은….기획 문서에서 더 나아가, 디자인이나 개발의 결과에 차이가 발생하는 참사를 낳게 되어버렸다.

물론, 기획서의 버전관리를 명확하게 하지 못하고 계속되는 커뮤니케이션을 누락되지 않도록 모든 기획서에 업데이트를 동시에 완벽하게 하지 못한 나의 잘못도 있긴 하지만…계속되는 문제를 개선해야 할 필요성이 있었다.

문제는 기획 초반에 잡지 못했던 Sync

그렇다고 해서 마냥 메이커들에게 다짜고짜 ‘작성된 기획 문서를 다 봐주세요!’ 라고 외치자니, 나의 기획 문서 작성 방식이나 커뮤니케이션 프로세스에 있어서 문제점이 있는지를 먼저 점검해 보고자 했다.

기획이 완성된 이후에 진행이 되었던 기획 Review

전체적인 프로세스에 대해 정리한 결과, 현재 담당하는 ‘하이퍼랩’ 서비스의 기획 전후의 프로세스는 위와 같이 이루어지고 있었다. 도메인 지식이 필요한 PRD를 신약 개발 연구원이 작성하면, 해당 문서를 기반으로 해당 PRD 내용을 개발하는 데 필요한 기획 문서를 한 번에 작업하였다. 그렇게 작업한 문서는 개발 및 디자인 작업이 시작되기 전에 ‘기획 Review’ 단계를 진행 후 바로 개발 & 디자인 작업을 시작하였다.

이 프로세스의 가장 치명적인 문제는 ‘기획이 모두 완료된 이후에 Review’를 진행한다는 점이다. 모든 기획이 이미 정해진 상태에서 Review가 진행되고, 그 상태에서 메이커들의 의견을 수렴하여 다시 수정하고, 바로 개발과 디자인 작업 진행되다 보니, 진행되면서 발생하는 커뮤니케이션도 누적되어 증가하게 된다.

이러한 악순환의 과정에서 이미 완성되어 각각의 문서의 목적에 맞게 파편화 되어버린 기능들을 일일이 찾아서 수정하게 되면, 완벽하게 업데이트했다 할지라도 누락된 부분들이 발생하고 이러한 Snowball이 개발과 디자인, QA까지 영향을 끼치게 되어 혼란을 야기하게 되었다.

그래서 나는 이 부분을 가장 먼저 해결해야 한다고 생각했다.

본 기획을 시작하기 전에 Sketch 기획을 공유한다.

PRD 이후에 ‘Sketch 작업’이라는 단계와 해당 Sketch를 리뷰하는 ‘Sketch Review’라는 단계를 추가했다.

[Sketch 문서의 목적 및 정의]

1. PRD 내용과 간단한 정책, 필요한 필수 기능들에 대한 간략한 정의를 기반으로 최종 문서를 정리하기 전에 기획을 Review 하는 목적과 싱크를 하기 위한 부분으로 사용되는 문서

2. 미리 기획을 다 하고, 기획을 개발 / 디자인에 Review 하는 방식과 다르게 미리 스케치 형태로 어떻게 동작할 것인지, 대략 서술한 후 기술적으로 문제가 될 수 있는 부분을 본 기획 전에 논의하여, 기획서와 디자인이 번복되는 과정을 최소화하기 위한 목적

사실 PRD에 덧붙여서 작성하면 되지 않냐는 의견이 있을 수 있는 비슷한 문서가 될 위험성도 분명히 존재할 것 같다.

하지만, 우리의 서비스는 바로 ‘신약 개발 플랫폼 하이퍼랩(Hyper Lab)’.

PRD를 PM이 쓰지 않고 도메인 지식이 필요한 형태로 작성이 되기 때문에 한 번 더 PM이 해당 문서를 가공하는 작업이 반드시 발생한다.

그래서 Sketch의 목적은 다 같이 Sync도 맞추고, 신약 개발 연구원과 개발, 디자인, QA 파트와도 모두 처음으로 해당 Backlog에 대해 의견을 맞추기 위해 누구도 어렵지 않도록 Standard 하게 작성되어야 한다.

Sketch 문서에 중점과 양식

Sketch 문서에 작성되는 템플릿은 다음과 같다.

Notion에 작성된 Sketch 문서의 템플릿

쉽게 생각해 보면, 본 기획에서 작성되어야 할 문서들에 대해 가장 큰 틀을 아주 아주 핵심적인 내용만 담아 빠르게 작성하고 Sync 하기 위한 문서이다. 이렇게 해당 Sync를 Sketch 문서에서 맞추게 되면, 본 기획 시 각각의 기획 문서의 뼈대가 되는 틀도 쉽게 잡힐 수 있을 것이다.

빠르고, 간결하게

Sketch 문서의 또 다른 중심이 되는 부분은 ‘빠르고, 간결하게 작성한다.’이다. Sketch 문서는 간단하게 작성하고 합의점을 찾고, Sync를 하는 것이 목적이므로 이 문서의 작성 시간이 오래 걸리면 사실상 본 기획보다 불필요해지는 문서라고 생각한다.

그래서 Backlog의 내용에 따라 기획 난이도가 다르겠지만, 자신의 규칙으로 Sketch 문서의 최대 작성 시간은 2일 정도로 지정해 두었다.

얼마나 개선이 될 수 있을지는 모르지만, 해봐야 아는 거니까.

히츠에 합류한 지 어느덧 1주년이 지났다. 그만큼 나도 더 동일한 방식에 고이지 않도록 더 노력해야 하는 시기가 완서 이러한 기획 프로세스를 개선하고자 한다.

이제 기획 프로세스의 개선은 첫발을 내딛고 시작해 보려는 상태다. 위의 Sketch 문서도, 다른 협업하는 분들께 공유가 된 상태지만, 아직 시작한 지 얼마 되지 않아서 가설을 검증하기 전의 상태다.

다만 이런 우당탕탕의 검증 과정을 또 가져야 더 좋은 방향성으로 모두가 쉽게 기획을 이해할 방법으로 나아갈 수 있다고 생각한다. 그리고 이 Sketch 문서의 개선 이외에도 더 해야 할 일들이 많이 남아있고, 시도한 결과에 대한 사후 분석도 해봐야 할 것이다.

그래서 앞으로도 기획 문서에 대한 고민을 계속하고, 더 좋은 양질의 글로 돌아올 수 있도록 하겠다.

Jira를 사용하는 사용자라면 대부분 연관돼서 사용할 수밖에 없는 ‘컨플루언스(Confluence)’.
최근 들어 아틀라시안이 JPD(Jira Product Discovery)를 비롯해서 여러 가지 새로운 솔루션들을 내보내고 있는 중이다.

그중에서 이번에 컨플루언스에서 새로운 기능으로 ‘화이트보드’ 기능을 출시했다.
이 기능은 Figma의 ‘Figjam’과 유사한 역할을 수행하는 기능으로 Scrum이나 Flow 작성, 설계를 할 때 유용하게 쓰일 수 있다.

이제껏 주로 Figjam을 통해서 사용자 Flow나 전체적인 IA를 그렸던 사람으로서 컨플루언스의 ‘화이트보드’ 기능을 통해서 Flow 작성을 하고, 후기를 남겨보고자 한다.

장점 (1) Figjam과 유사한 UX

화이트 보드의 특징은 대부분의 기능이 Figjam과 유사하게 사용할 수 있다는 점이다.
Figjam에서 활용할 수 있는 다양한 템플릿도 동일하게 제공하며, 대부분의 단축키도 유사하게 동작한다.

장점 (2) 너무나도 좋은 ‘아틀라시안(Atlassian) 생태계’ 연동

Figma에서 Jira와 Confluence 문서를 붙여 넣기 위해 여러 가지 플러그인들을 테스트해 봤던 경험이 있을 것이다. 하지만 피그마에서는 온전히 아틀라시안의 문서를 완벽하게 활용할 수 없었다.

아틀라시안(Atlassian) 서비스들의 연동

이 부분이 아마 화이트 보드가 Figjam이 자리 잡았던 시장에서 가장 크게 우위를 점할 수 있는 부분이 아닐까 싶다.
Jira를 사용하고, 컨플루언스를 사용하다 보면 각각의 문서와 이슈들을 멘션하고 링크를 걸어 놓는 행위가 잦다.
간편하게 이슈 링크를 화이트보드에 붙여 넣기만 하면 자동으로 객체화가 되면서 활용할 수 있으니 이보다 더 간편한 활용도가 없다.

Jira에서 직접 이슈를 가져와서 활용할 수도 있다.
이 부분은 스크럼이나 회고를 화이트 보드에서 진행할 경우, 굉장히 간편하게 사용할 수 있을 것으로 보인다.

단점 (1) 완벽하게 자유롭지는 않은 도형 동작

기본적인 동작은 Figjam과 모두 유사하지만, 완벽하게 자유롭게 동작하지는 않는 것이 장점이라면 장점일 수 도 있지만, 단점인 것 같다.

• Flow를 그릴 경우, 화살표에다가 텍스트를 입력할 경우, 텍스트가 화살표 상에 표시되는 위치가 고정되어 있다.
  상황에 따라서 텍스트의 표시 위치를 바꿀 수 있는 Figjam과 달리 이 부분은 불편한 상황이 가끔 발생한다.
• 화살표의 모양 제어도, Flow에 따라서는 자유롭게 높이를 조절하거나, 휘어짐의 형태를 제어할 수 있어야 하는데, 화이트보드에서는 따로 사용자가 Custom 할 수 없이 고정되어 있다.

단점 (2) Flowchart를 그리기엔 제한적인 도형의 종류

Flowchart를 그리려면, 여러가지 도형과 로직에 맞는 모양이 필요한 경우가 많다.
Figjam은 이제 다양한 상황에 맞춰서 알맞은 도형을 선택할 수 있도록 선택지를 넓혀나가는 중이다.

하지만 아직 화이트 보드에서는 기본적인 도형만 제공하여 Flowchart를 Case에 맞춰서 전문적으로 그리기에는 조금 어려운감이 없지 않아 있다. 하지만 이 부분은 초기의 Figjam도 이랬으니 점차 개선되지 않을까 하는 생각이다.

결론

기획 문서의 파편화가 고민이라면, 충분한 가치가 있다.

PM의 고질적인 고민 중 하나는 ‘문서의 파편화’다.

매니징을 할 때에도, Sprint를 관리할 때에도, 기획 문서를 작성할 때에도 모두 커뮤니케이션의 대상이 누구인가, 작업의 목적이 무엇이냐에 따라서 사용하는 Tool과 작성하는 문서의 채널이 모두 다르기 때문에 문서를 전달할 때 각각의 링크들을 모두 정리해서 보여주는 게 큰 공수다.
이러한 부분에서 화이트 보드는 ‘컨플루언스’ 문서라는 점인 것과 더불어 다양한 아틀라시안 링크들과 연동을 가진다는 점이 굉장한 장점으로 차지하는 것 같다. 문서를 연동시켜서 한눈에 볼 수 있는 점은 굉장한 장점이다.

화이트보드의 작업 기능 자체만 놓고 보면, 간단한 Flowchart를 작성하거나, Scurm이나 회고를 위한 Agile 보드를 만들기 위한 용도로는 충분한 가치가 있는 부분이다. 다만 전문적인 Flowchart를 그리거나, Figma와의 연관성이 더 많은 작업을 해야 한다면 당연히 Figjam을 사용하는 것이 좋다.

그렇다면 화이트 보드가 Figjam을 넘을 수 있을 것이냐라는 근본적인 궁금증에 대한 나만의 결론은,

‘PM’의 입장에서는 충분히 Figjam보다 유리해질 수 있는 기능이 될 것이다’라고 결론을 지을 수 있다.

그래도 아직은 갈 길이 먼 것 같아서 Figjam을 보면서 점점 발전하는 컨플루언스의 화이트보드가 되길 기대한다.