Planning · PM/프로젝트 · PM

생성형 AI 저작권과 윤리, 공부하며 정리한 쟁점

생성형 AI를 공부하다 보면 기술 이야기만큼 자주 만나는 주제가 저작권과 윤리입니다.서비스에 AI 기능을 넣는다면 이 문제를 피해갈 수 없을 것 같아서, 기사와 공개된 논의를 읽으며 쟁점을 정리해보았습니다.먼저 분명히 해둘 점이 있습니다.저는 법률 전문가가 아니고, 이 글은 공부한 내용을 정리한 메모일 뿐 법률 자문이 아닙니다.이 분야는 아직 논의 중인 부분이 많아서, 실제 서비스에 적용할 때는 반드시 전문가의 검토와 최신 공식 안내를 확인해야 한다고 생각해요. 가장 먼저 눈에 띄는 쟁점은 모델이 무엇으로 학습했느냐입니다.이미지나 글을 생성하는 모델은 방대한 데이터로 학습하는데, 그 안에 창작자가 만든 작품이 들어 있을 수 있다는 점이 논란의 중심이에요.창작자 입장에서는 허락 없이 자신의 작품이 학습에 ..

Build-Measure-Learn, 작게 돌려보기

린 스타트업에서 가장 유명한 개념이 Build-Measure-Learn, 즉 만들고, 재고, 배우는 순환입니다.책으로 읽을 때는 당연한 이야기처럼 들리는데, 막상 제 아이디어에 적용하려고 하면 "그래서 일주일 동안 뭘 하라는 거지?" 싶었어요.그래서 이 루프를 1~2주 단위로 잘게 쪼개서 실제로 돌려본다면 어떻게 하는지, 가정 예시와 함께 정리해봤습니다. 이 순환은 Build에서 시작하는 것처럼 보이지만, 책에서도 계획은 거꾸로 세우라는 취지로 설명한다고 이해했습니다.먼저 배우고 싶은 것(Learn)을 정하고, 그걸 확인하려면 무엇을 재야 하는지(Measure) 정한 다음, 마지막으로 그걸 재기 위해 최소한 무엇을 만들면 되는지(Build)를 정하는 식입니다.저는 이 순서가 중요하다고 느꼈어요.만들고 나..

기능 우선순위 프레임워크 비교, 1인 프로젝트에 ICE·RICE·Kano 적용해보기

기능 우선순위를 정하는 방법은 예전부터 많이 읽어왔는데, 막상 혼자 작은 서비스를 만들어보려니 어디에 어떻게 써야 할지 감이 오지 않았어요.읽을 때는 다 이해한 것 같은데, 내 기능 목록 앞에 앉으면 결국 "이것도 필요할 것 같고 저것도 필요할 것 같고"로 끝나더라고요.그래서 이번에는 대표적인 세 가지 방법(ICE, RICE, Kano)을 같은 기능 목록에 하나씩 적용해보고, 어떤 차이가 나는지 정리해봤습니다. 예시로 쓸 서비스는 실제로 만들고 있는 것이 아니라, 연습을 위해 가정한 것입니다.동네 독서모임 운영자가 모임 일정을 정할 때 단체 대화방에서 날짜를 일일이 묻는 게 번거롭다고 가정해볼게요.그래서 일정 후보를 올리면 참석자들이 투표하고, 가장 많이 가능한 날짜가 자동으로 정리되는 작은 웹서비스를 ..

MVP 범위 자르기 - 기능을 어디까지 빼야 하나

MVP(Minimum Viable Product)라는 말은 창업 책을 읽으면 어디서나 나옵니다.그런데 막상 내 아이디어에 적용하려고 하면, "최소"가 어디까지인지가 가장 어려웠어요.기획자로 일할 때 범위를 줄이는 일을 자주 해봤다고 생각했는데, 내 아이디어 앞에서는 전혀 다른 문제가 되더라고요.기능 하나하나가 다 소중해 보이니까요.이번 글에서는 범위를 자르는 순서와, 제가 여러 번 빠졌던 함정을 적어봅니다. 기능 목록을 쓰기 전에 먼저 하는 일이 있습니다.이 서비스가 고객에게 주는 핵심 가치를 한 문장으로 쓰는 것입니다.예를 들어 소규모 업장용 예약 서비스를 가정해볼게요."전화나 메신저로 받던 예약을 놓치지 않고 한곳에서 확인할 수 있다."이 정도가 한 문장의 예입니다.이 문장에는 "놓치지 않는다"와 "..

린 캔버스로 아이디어 검증하기

신규 아이디어가 나올 때마다 바로 기획서를 쓰기 시작하면, 절반은 중간에 방향이 바뀌고 절반은 그냥 흐지부지됩니다.저도 예전엔 아이디어가 나오면 바로 와이어프레임부터 그렸는데, 나중에 보면 "이게 정말 필요한 서비스인가"라는 근본적인 질문에 답을 못 하는 경우가 많았어요.그래서 요즘은 신규 아이디어가 나오면 제일 먼저 린 캔버스(Lean Canvas)를 채워보는 걸 습관으로 만들었습니다. 린 캔버스는 문제, 고객군, 고유의 가치 제안, 솔루션, 채널, 수익 구조, 비용 구조, 핵심 지표, 경쟁 우위까지 한 장에 정리하는 프레임워크예요.비즈니스 모델 캔버스와 비슷하지만, 스타트업 초기 아이디어 검증에 맞게 "문제"와 "솔루션"을 앞쪽에 배치한 게 특징입니다.저는 이 순서가 특히 마음에 들었어요.솔루션부터 ..

애자일 팀의 회고(Retrospective) 잘 하는 법

회고를 몇 년째 진행하다 보면, 어느 순간 회고 자체가 형식이 되어버리는 시기가 옵니다.저희 팀도 그랬어요.매 스프린트 끝나면 회의실에 모여서 포스트잇에 Keep, Problem, Try를 적고, 다 같이 붙이고, 몇 개 투표하고 끝내는 패턴이 반복됐습니다.그런데 어느 순간 팀원 한 명이 "우리 이거 3주 전에도 똑같이 얘기했던 것 같은데요"라고 말했고, 그 말에 다들 조용해졌던 기억이 있어요. 회고에서 나온 Problem이 다음 스프린트에 실제로 개선되지 않으면, 회고는 그냥 감정 배출구가 되어버립니다.저희가 겪었던 문제는 Try 항목이 "노력하자", "신경 쓰자" 수준의 다짐으로 끝나는 경우가 많았다는 거였어요."코드 리뷰를 더 꼼꼼히 하자"는 Try는 누가 언제 무엇을 다르게 할지가 없으니, 다음 ..

PM과 개발자 사이 커뮤니케이션 갭 줄이기

"이거 금방 되는 거 아니에요?"라는 말을 PM이 하는 순간, 개발자의 표정이 굳는 걸 몇 번이나 봤습니다.저도 예전에 이 말을 자주 했었고, 지금 생각하면 왜 그 말이 그렇게 문제였는지 뒤늦게 이해하게 됐어요.PM과 개발자 사이의 갭은 능력 차이가 아니라, 서로 보고 있는 정보의 종류가 다른 데서 시작되는 경우가 훨씬 많았습니다. PM은 화면과 사용자 경험을 기준으로 난이도를 가늠하고, 개발자는 코드 구조와 기존 시스템과의 연결을 기준으로 가늠합니다.저희 팀에서 있었던 일인데, "상품 상세 페이지에 최근 본 상품 목록 추가"라는 요청을 제가 "그냥 목록 하나 더 보여주는 거니까 간단하겠다"고 생각했어요.그런데 개발팀 입장에서는 최근 본 상품을 저장할 저장소를 정하고, 비로그인 사용자는 어떻게 처리할지,..

기능 우선순위, 이해관계자 설득하는 법

우선순위 회의만큼 감정 소모가 큰 회의가 없다고 느낄 때가 많습니다.영업팀은 "이 고객사가 요청한 기능을 안 하면 계약이 위험하다"고 하고, 디자인팀은 "지금 UI 부채를 안 갚으면 나중에 더 힘들어진다"고 하고, 개발팀은 "기술 부채부터 해결해야 신규 기능도 빨리 나온다"고 합니다.다 맞는 말이라서 반박하기도 어려운데, 결국 자원은 한정되어 있으니 뭔가는 뒤로 밀려야 해요.이 과정을 몇 년 겪으면서 제가 나름대로 정리한 설득 방법을 공유해봅니다. 가장 먼저 바꾼 건, 우선순위 논의를 "제 생각엔"으로 시작하지 않는 것이었습니다.예전엔 회의에서 "제가 보기엔 이게 더 급한 것 같아요"라고 말하곤 했는데, 이렇게 시작하면 상대방도 "저는 아닌 것 같은데요"로 맞받아치고, 결국 누구 목소리가 더 크냐의 싸움..