넛지와 다크패턴의 차이: 여행 예약 서비스에서 PM은 어디까지 설계해야 할까

여행 예약 서비스 화면은 늘 바쁩니다. 지금 예약하지 않으면 가격이 오를 것 같고, 남은 객실이 얼마 없다는 문구는 사용자를 조급하게 만듭니다. 문제는 이런 장치가 모두 잘못은 아니라는 점입니다. 어떤 것은 합리적 선택을 돕는 넛지이고, 어떤 것은 사용자를 몰아붙이는 다크패턴입니다. 겉모습은 비슷하지만, 사용자가 느끼는 경험의 질은 전혀 다릅니다. 왜 여행 예약 서비스에서 넛지와 다크패턴의 차이가 중요할까여행 예약 서비스는 원래 사용자의 불안을 자극하기 쉬운 구조를 갖고 있습니다.항공권은 가격이 계속 변하고, 숙소는 재고가 한정돼 있으며, 취소 규정은 복잡합니다. 여기에 일정까지 정해져 있으면 사용자는 천천히 비교하기 어렵습니다. 바로 이 지점에서 넛지와 다크패턴의 경계가 흐려집니다. PM 입장에서는 전..

AI 에이전트 시대, PM이 이해해야 할 운영체계 설계의 핵심AI를 도입하는 팀이 빠르게 늘고 있습니다.하지만 많은 조직은 아직도 AI를 “좋은 모델을 붙이면 되는 기능” 정도로 이해합니다. 이 관점은 이제 부족합니다.실무에서는 모델 자체보다, 그 모델이 어떤 환경에서 일하고, 어떤 규칙 아래 움직이며, 어떤 검증을 거쳐 결과를 내는지가 훨씬 더 중요해졌기 때문입니다. 이 지점에서 등장한 개념이 바로 하네스 엔지니어링(Harness Engineering) 입니다. 하네스 엔지니어링은 AI 모델을 더 똑똑하게 만드는 기술이 아닙니다.이미 존재하는 모델이 실제 업무에서 안전하게, 일관되게, 검증 가능하게 일하도록 운영체계를 설계하는 일입니다. 이 개념은 특히 PM에게 중요합니다.왜냐하면 AI 에이전트가 일을..

의존, 착각, 책임의 문제 AI를 쓰는 PM이 늘면서,이제 질문은 “써야 할까 말아야 할까”가 아니다. 대신 이런 질문이 나온다. AI를 쓰면 PM의 실력이 떨어질까?어디까지 맡기고, 어디부터는 직접 해야 할까? 이 질문은 기술 문제가 아니라 역할과 책임의 문제다.그리고 이 경계를 제대로 그리지 못하면,AI는 레버리지가 아니라 리스크가 된다. AI가 만든 답을 검증하지 않을 때 생기는 문제 AI를 쓰다 보면 가장 위험한 순간은“그럴듯하다”는 감각이 들 때다. 문장은 매끄럽고논리는 정리돼 있고얼핏 보면 틀린 말이 없어 보인다 이 상태에서 검증을 건너뛰면, 문제가 생긴다. 전제 조건이 맞는지 확인하지 않고조직 맥락에 맞는지 점검하지 않으며실제 제약을 반영했는지 보지 않는다 AI는 틀린 답보다, 검증되지 않..

회의록, 액션 아이템, 이해관계자 정리 PM의 하루를 돌아보면,일하는 시간보다 회의에 쓰는 에너지가 더 크게 느껴질 때가 많다. 회의 자체가 문제는 아니다.문제는 회의가 끝난 뒤다. 무슨 이야기를 했는지 흐릿하고결정이 있었는지 애매하고다음에 무엇을 해야 하는지 정리되지 않는다 이 지점에서 AI는 꽤 명확한 역할을 할 수 있다.회의를 더 잘 하게 만드는 도구가 아니라,회의로 인한 소모를 줄여주는 도구다. 회의가 많은 PM에게 AI는 어떤 역할을 할 수 있을까? 회의가 많은 PM일수록모든 회의에서 적극적으로 말하려고 하면 빠르게 지친다. AI는 이 문제를 이렇게 바꾼다. 회의에서 모든 걸 기억하려 애쓰지 않아도 되고말로 정리하지 못한 내용을 나중에 구조화할 수 있고회의 이후 정리 작업을 혼자 떠안지 않아도..

PM의 하루는 문서로 시작해 문서로 끝난다.PRD, 정책 문서, 기획서, 공유용 정리 문서까지.문서의 양은 많고, 완성도에 대한 기대치는 항상 높다. 이때 많은 PM이 AI에게 묻는다.“이 문서, AI가 대신 써줄 수 있을까?” 짧게 답하면 이렇다.대신 써주면 위험하고, 함께 쓰면 강력하다. AI가 문서를 대신 써줄 수 있을까? AI는 문장을 만드는 데 매우 능숙하다.문법도 매끄럽고, 구조도 그럴듯하다.그래서 처음에는 이런 유혹이 생긴다. PRD를 통째로 써달라정책 문안을 완성본으로 만들어달라 문제는 결과물이 너무 그럴듯하다는 점이다.읽기에는 문제가 없어 보이지만,PM 문서에서 가장 중요한 것들이 빠져 있다. 왜 이 결정을 했는지어떤 선택지를 버렸는지이 조직에서만 존재하는 제약 조건 이건 AI가 알 수..

기획 초반은 늘 비슷한 어려움으로 시작한다.문제가 명확하지 않고, 정보는 흩어져 있으며,“어디서부터 생각해야 할지”가 가장 막막한 구간이다. 이 단계에서 AI를 잘 쓰는 PM과 그렇지 않은 PM의 차이는 분명하다.AI에게 답을 요구하느냐, 아니면 생각을 넓혀달라고 요청하느냐의 차이다. AI는 아이디어를 만들어줄 수 있을까? 결론부터 말하면,AI는 아이디어를 ‘만들어준다’기보다는 ‘늘려준다’. AI가 내놓는 아이디어 자체가바로 기획안이 되기는 어렵다.맥락이 없고, 조직 상황을 모르며, 제약 조건을 충분히 반영하지 못한다. 하지만 기획 초반에 가장 위험한 상태는아이디어가 부족한 게 아니라,아이디어가 너무 좁은 상태에서 출발하는 것이다. 이때 AI는 유용하다. 내가 떠올리지 못한 관점을 던져주고너무 익숙한 ..

AI는 자동화 도구가 아니라 ‘사고 확장 도구’다 PM이 AI를 쓰기 시작한 지는 그리 오래되지 않았지만,이미 팀마다 온도 차이는 꽤 벌어졌다. 어떤 PM은 “일이 훨씬 빨라졌다”고 말하고어떤 PM은 “써봤는데 별로 쓸모없다”고 말한다 이 차이는 툴 숙련도의 문제가 아니다.AI를 어떤 존재로 인식하느냐의 차이에 가깝다. AI를 ‘일 대신 해주는 도구’로 보면 실패한다 많은 PM이 AI를 처음 접할 때 이렇게 기대한다. 기획안을 대신 써주길 바라고정답 같은 결론을 내려주길 기대하고귀찮은 일을 대신 처리해주길 원한다 하지만 이런 기대를 전제로 하면,AI는 금방 “애매한 도구”가 된다. 왜냐하면 PM의 핵심 업무는문서 작성도, 조사도, 요약도 아니기 때문이다. PM의 본질은 판단이다. 무엇이 문제인지 정의하..

프로젝트가 끝나면 거의 자동처럼 회고를 한다.하지만 회고가 끝나고 나서도 비슷한 문제가 반복된다면, 그 회고는 기능하지 않은 것이다. 회고 문서는 남았는데 행동은 바뀌지 않고문제는 나열됐지만 책임은 흐려지고“다음엔 잘해보자”로 마무리된다 프로젝트 회고는 감정 정리가 아니라 조직 학습 장치다.이 글에서는 회고를 제대로 작동시키기 위한 접근 방식과, 회고 세션에서 PM의 역할, 그리고 가장 많이 쓰이는 KPT 회고 방식의 장단점을 정리한다. 1. 회고는 ‘평가’가 아니라 ‘재사용을 위한 정리’다 회고가 실패하는 가장 흔한 이유는 목적 설정이 잘못됐기 때문이다.회고를 평가나 반성의 자리로 만들어버리면, 사람들은 방어적으로 변한다. 좋은 회고의 목적은 명확하다. 무엇이 잘 작동했는지무엇이 반복되면 안 되는지무..

PM의 일정에는 유독 회의가 많은 날이 있다.하루 종일 회의에 들어갔는데, 정작 일이 하나도 진척되지 않은 날.캘린더는 꽉 찼지만, 결과물은 비어 있는 날이다. 이런 날의 문제는 단순하다.회의가 많아서가 아니라, 회의 이후를 관리하지 못했기 때문이다. 1. 회의가 많은 날은 ‘집중의 날’이 아니라 ‘소모의 날’이다 나는 개인적으로“사람마다 하루에 쓸 수 있는 말의 총량이 정해져 있다”는 말을 꽤 믿는 편이다.그리고 PM이지만, 나는 그 총량이 상대적으로 많지 않은 사람이라고 느낀다. 회의가 많은 날이면 이게 더 명확해진다. 말을 많이 하면생각할 힘이 먼저 고갈된다 회의가 연속으로 이어진 날,회의가 끝났는데도 머리가 멍한 이유는 게으름이 아니라 인지 소모다.이 상태에서 생산성을 기대하는 건 현실적이지 않..

PM에게 번아웃은 드문 일이 아니다.오히려 책임이 커질수록, 판단이 많아질수록 번아웃은 필연적으로 따라온다. 문제는 번아웃 자체가 아니라, 그것을 어떻게 다루느냐다. 나 역시 PM으로 일하면서 몇 차례 번아웃을 겪었다. 업무가 싫어진다기보다, 판단을 내리는 일 자체가 버거워졌던 시기였다. 그때마다 완벽한 해법이 있었던 건 아니다. 다만, 몇 가지 방식이 반복적으로 도움이 되었고, 지금 돌아보면 꽤 보편적인 해결 전략이었다. 1. 번아웃의 신호를 ‘의지 부족’으로 해석하지 않는다PM은 번아웃이 와도 일을 멈추지 않는다.대신 이렇게 해석한다. 내가 약해진 걸까집중력이 떨어진 것뿐 아닐까요즘 컨디션이 안 좋은 정도겠지 이 해석이 문제다. 번아웃은 의지 문제가 아니라 지속적인 판단 피로의 누적이다.특히 PM은..