Alicia in Beta

고독 속에서 길 찾기 - 제29화. 리더로서 혼자 감당해야 하는 순간을 지나며

Alicia in Beta — Mon, 20 Apr 2026 03:45:24 GMT

리더의 자리는 사람들 사이에 있지만, 판단의 순간은 늘 혼자였다. 하루 종일 팀과 이야기하고, 끊임없이 의견을 듣고, 같이 고민하고 결정하는 것처럼 보여도 막상 방향을 정해야 하는 순간에는 결국 혼자 남는다. 누군가 대신 결정해주지 않고, 누군가 확신을 보태주지도 않는다. 의견은 참고가 되지만, 결정은 언제나 내 몫이다. 처음엔 이 감각이 낯설었다기보다

두려움과 불안을 다루는 법 - 제28화. 감정을 구분해서 바라보는 연습하기

Alicia in Beta — Sat, 18 Apr 2026 05:06:34 GMT

리더로 일한다는 건 겉으로는 아무렇지 않은 척하면서도 속으로는 끊임없이 불안을 안고 가는 일에 가깝다. 결정은 내가 내리는데, 그 결과는 팀과 회사 전체에 영향을 미친다. 잘되면 당연한 일처럼 받아들여지고, 잘못되면 그 책임은 분명해진다. 그래서 리더의 자리에는 늘 두려움이 함께 따라온다. 처음에는 그 감정을 인정하지 않으려 했던 것 같다. 리더라면 흔

AI 제품 우선순위 결정의 차이 - 무엇을 만들지보다, 어디에 적용할지를 먼저 결정한다

Alicia in Beta — Tue, 14 Apr 2026 05:00:08 GMT

AI 제품에서는 우선순위를 결정하는 기준이 달라진다. 기존 제품에서는 무엇부터 먼저 만들 것인지가 우선순위의 핵심이다. 백로그 리스트나 기능 리스트 안에서 비즈니스 임팩트와 개발 난이도를 기준으로 순서를 정한다. 즉, 중요한 우선순위는 무엇부터 만들 것인가에 대한 결정이다. 하지만 AI 제품에서는 이 질문으로 시작할 수 없다. AI 제품에서는 우선순위가

AI 제품 UX 설계의 차이 - AI 제품에서는 기능과 UX가 분리되지 않는다

Alicia in Beta — Fri, 10 Apr 2026 05:00:05 GMT

AI 제품을 만드는 Product Manager 관점의 글 AI 제품에서는 UX 설계의 관점이 달라진다. 기존 제품에서는 UX가 이미 정의된 기능을 사용자에게 전달하는 역할을 한다. 예를 들어 파일 업로드 기능을 만든다면 업로드 버튼 위치, 파일 선택 창, 진행 상태 표시, 완료 메시지 등을 설계한다. 즉, 기능이 먼저 정의되고 UX는 이를 이해하기

AI 제품 테스트 방식의 차이 - AI 제품에서는 정답이 없다

Alicia in Beta — Thu, 09 Apr 2026 08:00:06 GMT

AI 제품을 만드는 Product Manager 관점의 글 AI 제품에서는 테스트 방식 자체가 달라진다. 기존 제품에서는 기능이 명확하게 정의되어 있고 그 기능이 의도대로 동작하는지를 확인하면 된다. 예를 들어 로그인 기능을 생각해보면, 올바른 아이디와 비밀번호 입력 → 로그인 성공 잘못된 비밀번호 입력 → 로그인 실패 비로그인 상태에서 접근 → 로그인

데이터가 언제나 정답일까 - 제27화. 생존이 달린 상황에서 배운 의사결정의 균형

Alicia in Beta — Wed, 08 Apr 2026 05:41:10 GMT

AI 제품을 직접 만들면서 데이터의 중요성을 다시 한 번 체감하게 됐다. 모델 성능을 비교할 때, 사용자 경험을 개선할 때, 프롬프트를 바꿀 때 등 결국 판단 기준은 데이터였다. 감이 아니라 근거로 이야기할 수 있다는 점에서 데이터는 강력한 언어였다. 이제는 일상에서도 수면 시간이나 식단, 운동 기록까지 가능한 것들을 데이터로 남기고 패턴을 보려는 습관

AI 제품 요구사항의 가장 큰 차이 - AI 제품의 요구사항에는 하나가 더 있다

Alicia in Beta — Tue, 07 Apr 2026 07:00:03 GMT

AI 제품을 만드는 Product Manager 관점의 글 AI 제품에서는 요구사항을 쓰는 방식 자체가 달라진다. AI 제품을 만들기 시작하면 기존 방식으로는 요구사항이 어딘가 부족하다는 느낌을 받게 된다. 그 이유는.. AI 제품에서는 요구사항이 하나 더 필요하기 때문이다. 기존 제품에서 요구사항은 시스템이 어떻게 동작하는지를 정의하는 단계에서 주로

AI 제품 설계의 가장 큰 차이 - AI PM은 기능보다 해결 방식을 설계한다

Alicia in Beta — Mon, 06 Apr 2026 06:00:06 GMT

AI 제품을 만드는 Product Manager 관점의 글 AI 제품을 만들기 시작하면 가장 먼저 달라지는 것은 기능이 아니라 문제를 해결하는 설계 방식 자체다. 기존 제품이 기능을 나눠 문제를 해결한다면, AI 제품은 문제 해결 과정을 하나의 흐름으로 설계한다. 예를 들어 사용자가 긴 문서를 빠르게 이해해야 하는 상황을 생각해보자. 기존 제품이라면

<AI PM/PO 바이블> 강의를 만들었다 - AI PM에게 필요한 역량을 다시 생각하다 (패스트캠퍼스 강의 소개)

Alicia in Beta — Mon, 19 Jan 2026 13:26:19 GMT

<AI PM/PO 바이블> 강의를 오픈하며 요즘은 혼자서도 AI를 활용해 아이디어를 바로 구현하고, 제품으로 출시할 수 있는 시대가 되었습니다. 이전에는 디자이너나 개발자가 없으면 (혹은 그에 준하는 기술 역량이 없으면), PM 개인이 아이디어를 실제 제품으로 만들어보는 것 자체가 쉽지 않았죠. 하지만 지금은 다릅니다. AI를 활용하면 직무와 상관없이

불확실성을 마주하는 법 - 제26화. 확신을 기다리지 않고 판단하는 법

Alicia in Beta — Tue, 13 Jan 2026 06:00:07 GMT

불확실성을 없앨 수는 없지만, 그 안에서 결정할 기준은 만들어 갈 수 있다. 스타트업에서 리더로 일한다는 건 대부분의 시간을 모르는 상태로 보내는 일에 가깝다. 정보는 늘 부족했고, 상황은 빠르게 변했고, 결정이 필요한 순간은 예고 없이 찾아온다. 하지만 이 때문에 리더는 마냥 기다릴 수 없다. 가보지 않은 길, 해보지 않은 결정, 누구도 확신 없는

신뢰를 얻는 리더의 태도 - 제25화. 말보다 먼저 드러나는 기준들

Alicia in Beta — Mon, 12 Jan 2026 10:24:49 GMT

조직에서 신뢰는 말로 설명되기보다, 함께 일해보면 자연스럽게 판단되는 감각에 가깝다. 이 사람을 믿어도 되는지, 이 사람의 판단을 따라도 되는지. 그 판단은 대개 몇 가지 반복되는 태도에서 만들어진다. 1. 일에 대한 몰입과 집중 직급/역할을 앞세우기보다 지금 이 일이 왜 중요한지, 어떻게 하면 되게 할 수 있는지를 누구보다 깊이 고민하고 직접 파고드

성과를 드러내는 리더의 책임 - 제24화. 보상과는 다른, 인정의 언어

Alicia in Beta — Thu, 08 Jan 2026 06:41:14 GMT

성과 관리는 리더의 의무지만, 보이지 않는 기여를 인정하는 건 리더의 태도다. 팀을 이끌면서 생각보다 오래 고민하게 된 주제 중 하나는 성과를 어떻게 드러내고, 누구를 어떻게 인정해야 하는가였다. 보상은 비교적 명확했다. 연봉, 인센티브, 직급, 역할...처럼 회사 차원의 제도와 기준이 있었다. 하지만 '인정'은 달랐다. 어디까지를 성과로 볼 것인지

AI 앞에서 스스로를 의심하게 될 때 - “이 모든 게 내 문제일까?”라는 질문 앞에 선 PM에게

Alicia in Beta — Wed, 07 Jan 2026 03:25:27 GMT

작년에 AI 관련 글을 쓴 이후, 생각보다 많은 연락을 받았다. 커피챗으로, 자문과 코칭, 컨설팅으로 이어지기도 했다. 그런데 그 과정에서 아주 무거운 이야기들을 많이 들었다. 반복해서 들었던 질문은 비슷했다. AI를 다루는 이 일이, Product Manager라는 직무 자체가 나에게 안 맞는 걸까? 내 역량이 부족한 걸까? 이렇게 개발하는 게 맞는 걸

리더가 좋은 사람으로 남고 싶을 때 - 제23화. 어려운 대화를 피하지 않는 법

Alicia in Beta — Tue, 06 Jan 2026 04:00:04 GMT

어려운 말을 하지 않는 건 배려가 아니라, 책임을 미루는 선택일 수 있다. 리더가 되면 대부분 좋은 사람이 되고 싶어진다. 소리를 지르거나, 권위로 찍어 누르거나, 이유 없이 비난하는 상사가 되기 싫어서다. 나 역시 그랬다. 초반에는 어려운 말을 꺼내는 게 특히 힘들었다. 괜히 관계를 망치는 건 아닐지, 지금 꼭 말해야만 하는지 스스로를 자주 검열하고

동료와 친구 사이의 경계 - 제22화. 친밀한 태도와 분명한 기준 사이

Alicia in Beta — Mon, 05 Jan 2026 02:00:11 GMT

친근함은 태도, 기준은 책임 스타트업에서 일하다 보면 동료와 친구의 경계가 쉽게 흐려진다. 수많은 시간을 함께 야근하고, 위기를 넘기고, 성과와 실패를 나란히 겪다 보면 관계는 자연스럽게 가까워진다. 또래가 많고, 팀이 작을수록 그 속도는 더 빠르다. 나 역시 동료들과 수평적인 관계 안에서 일하고 싶었다. 권위나 위계를 앞세우기보다는, 설명하고 납득시키

리더가 갈등을 다루는 태도 - 제21화. 일과 연결되는 순간부터 리더의 책임

Alicia in Beta — Sun, 04 Jan 2026 08:21:45 GMT

갈등을 해결하려 들기보다, 일이 멈추지 않게 다루는 태도. 팀으로 일하다 보면 갈등은 늘 존재한다. 사람이 모이면 생각도, 방식도, 감정도 달라진다. 그래서 갈등 자체는 문제가 아니다. 하지만 진짜 문제는 갈등이 일로 번질 때다. 내가 갈등을 인식하게 되는 순간은 대부분 비슷했다. 일이 느려지고, 협업이 끊기고, 대신 뒷얘기가 늘어날 때. 회의에서는

리더는 왜 다시 시작할 수 있어야 하는가 - 제20화. 끝을 견디는 힘보다, 방향을 바꿀 수 있는 결단

Alicia in Beta — Wed, 31 Dec 2025 04:00:06 GMT

나 조차 확신이 없을 때는 언제든 다시 시작할 수 있도록 리더로 일하다 보면, 겉으론 아무 일 없는 것처럼 흘러가지만 속으로는 이미 몇 번이고 마음이 무너지는 순간들이 있다. 회의를 마치고 혼자 남았을 때, 같은 문제가 반복되는데 해결의 실마리가 보이지 않을 때, 이게 맞나?라는 질문에 더 이상 확신 있게 답할 수 없을 때. 처음엔 그런 질문 자체를

시간이 쌓여야만 보이는 것들 - 제19화. 단기 성과만으로는 증명되지 않는 무언가

Alicia in Beta — Tue, 30 Dec 2025 02:12:56 GMT

리더십의 진짜 증거는 결과 뿐만 아니라, 시간 위에 남은 흔적이다. 스타트업에서 일할 때, 나는 늘 속도의 언어로 살았다. 얼마나 빠르게? 이번 달 성과는? 다음 분기까지 가능할까? 시간은 언제나 쫓아가야 하는 대상이었고, 축적이라는 단어는 늘 지나고 나서야 비로소 의미를 갖곤 했다. 많은 시간이 흐르고 나서야 깨달았다. 빠름으로 얻는 건 성과지만,

(수정)Gen AI 제품 개발 프로세스 - PO/PM 기준. 크게 보면 같지만, 과연 무엇을 다르게 챙겨야할까?

Alicia in Beta — Wed, 03 Dec 2025 02:47:01 GMT

Note 1. 제품의 성격과 단계, 적용하려는 AI의 유형, 팀별 개발 프로세스에 따라 달라질 수 있습니다.Note 2. PO가 챙겨야 하는 공통 프로세스 기준으로 전체적인 내용을 수정하였습니다.(2025/12/12) 1. Product Vision & AI Strategy Alignment 제품 비전과 AI 활용 방향 정리, High-level 가설 단

잠시 멈출 수 있는 팀 - 제18화. 회복이 만들어내는 지속 가능한 성장

Alicia in Beta — Tue, 14 Oct 2025 07:44:23 GMT

리더의 역할은 팀을 움직이게 하는 것만큼, 회복하게 하는 것도 포함된다. 스타트업에서 '쉼'은 늘 사치처럼 여겨졌다. 속도는 생존의 조건이었고, 멈춤은 곧 뒤처짐처럼 느껴졌다. 나 역시 쉬는 법을 모르는 리더였다. 덜 바쁜 날엔 불안했고, 팀이 잠시 느슨해지는 걸 보면 초조했다. "지금 이 순간에도 누군가는 더 빠르게 가고 있을 텐데"라는 생각이 늘 머