AI
REA가 보여 준 것, 앱을 통째로 복제하는 시대에 기획자는 무엇을 지켜야 할까
이번 주에 REA라는 오픈소스를 둘러싼 이야기가 많이 보였습니다.정식 이름은 Reverse Engineer Anything이고, 줄여서 REA라고 부릅니다.이미 만들어진 소프트웨어를 AI 에이전트가 뜯어보고, 같은 기능을 다시 만들어 주는 도구라고 소개되고 있어요.해외에서는 "소프트웨어는 끝났다"는 반응까지 나왔다고 합니다. 저는 개발자가 아니라 기획자라서, 이 소식이 신기하다는 마음과 걱정스럽다는 마음이 동시에 들었습니다.그래서 오늘은 기획자의 관점에서 이 도구가 무엇인지, 무엇이 걱정되는지, 그리고 그렇다면 무엇을 지켜야 하는지를 길게 정리해 보려고 해요.정리에는 REA의 GitHub README와 이 도구를 직접 써 보며 소개한 유튜브 영상(성공지식백과 채널)을 참고했습니다.저는 이 글을 쓰는 시점..
ChatGPT Intelligent UI 업데이트와 스팩브릿지, 화면이 달라지는 시대의 스펙
이번 주에 ChatGPT에 큰 업데이트가 있었습니다.Intelligent UI라는 이름의 기능이 GPT-6과 함께 공개되었다는 소식이었어요.저는 이 소식을 보면서 개인 프로젝트인 스팩브릿지와 자꾸 겹쳐서 생각하게 되었습니다.오늘은 이 업데이트가 무엇인지 정리하고, 스팩브릿지와의 관계, 그리고 앞으로의 생각을 적어 보려고 해요. 보도를 종합하면 핵심은 이렇습니다.ChatGPT가 글자로만 답하지 않고, 질문에 따라 차트, 버튼, 입력 폼, 계산기 같은 인터랙티브한 요소를 섞어서 답한다는 것이에요.어떤 형태로 보여 줄지는 질문을 보고 ChatGPT가 정한다고 합니다.예를 들어 여러 대상을 비교해 달라고 하면 나란히 비교해 주는 화면이 나올 수 있고, 간단한 질문에는 지금처럼 글자로 답하는 식이에요.필요하면 작..
에이전트가 잘하고 있는지 어떻게 확인할까, 평가 공부 노트
예약 시스템에 AI 에이전트를 붙이는 설계를 공부하다가 계속 같은 질문에서 막혔습니다."그래서 이 에이전트가 잘하고 있는지는 어떻게 알지?"데모를 몇 번 돌려보면 대체로 잘 되는 것처럼 보입니다.그런데 몇 번 잘 되는 것과 믿고 맡길 수 있는 것은 전혀 다른 이야기더라고요.그래서 평가(Eval)라는 주제를 따로 공부하고 정리해봤습니다.특정 도구나 벤치마크 이야기는 일부러 빼고, 기획자 입장에서 이해한 개념 위주로 적어요.틀린 부분이 있을 수 있어서 계속 고쳐 나갈 노트라고 생각해주세요. 기존 소프트웨어는 입력이 같으면 출력도 같습니다.그래서 "이 입력에는 이 결과가 나와야 한다"는 테스트를 한 번 써두면 됩니다.에이전트는 사정이 다릅니다.같은 질문에도 답이 조금씩 달라지고, 중간에 어떤 도구를 부를지도 ..
예약 서비스의 AI 기능, 어디까지 맡길지 자동화 수준 정하기
예약 서비스 기획을 하다 보면 AI 기능 이야기가 나올 때마다 같은 질문에 부딪힙니다."그래서 AI가 어디까지 알아서 하게 할 건가요?"라는 질문이에요.처음에는 이걸 "할 수 있다 / 없다"의 문제로 생각했어요.그런데 공부하고 정리하다 보니 진짜 질문은 "할 수 있느냐"보다 "알아서 하게 둬도 되느냐"에 가깝더라고요.모델이 예약을 바꾸는 일 자체는 기술적으로 어렵지 않아졌지만, 바꿔도 되는 일인지는 전혀 다른 문제입니다.이번 글은 AI 기능의 자동화 수준을 단계로 나눠 보고, 예약 서비스의 기능별로 어느 단계가 어울리는지 정리해본 메모입니다.실제로 만들어 운영한 결과를 쓰는 글은 아니고, 기획하면서 공부한 내용을 바탕으로 한 가설에 가깝습니다.예시에 나오는 업장과 숫자는 모두 설명을 위해 가정한 것이에요..
AI 시대, 사람만이 할 수 있는 기획의 영역
요즘 "AI가 PM을 대체할 것인가"라는 질문을 정말 자주 받습니다.콘퍼런스에서도, 사내 회의에서도, 심지어 이 블로그 방문자분들 댓글에서도 비슷한 질문이 계속 나와요.저는 이 질문에 매번 조금씩 다르게 답해왔는데, 이번 기회에 제 생각을 한 번 제대로 정리해보려고 합니다.결론을 먼저 말하면, 저는 "대체된다"보다는 "역할이 재배치된다"는 쪽에 가깝게 생각하고 있어요.다만 그 재배치가 어디서, 왜 일어나는지를 구체적으로 짚어보고 싶었습니다. 먼저 솔직하게 인정해야 할 게 있어요.요구사항 문서를 정리하고, 여러 대안을 나열하고, 회의록을 요약하고, 유사 사례를 조사하는 일 - 이런 건 이제 AI가 사람보다 빠르고, 어떤 경우엔 더 꼼꼼하게 해냅니다.저도 최근 몇 달간 PRD 초안을 AI한테 먼저 뽑아달라고..
AI 에이전트 시대, PM의 역할은 어떻게 바뀌나
요즘 "코드를 AI가 대신 짜주는 시대에 기획자는 뭘 하나요?"라는 질문을 자주 듣습니다.저도 같은 질문을 스스로에게 몇 번이나 던졌어요.저는 서비스 기획과 PM 일을 해왔고, 지금은 예약 시스템 기획을 하면서 AI 공부를 꾸준히 이어가고 있습니다.그 정도의 경험으로 업계 전체를 전망할 수는 없어서, 이 글은 예측보다는 제가 직접 느낀 변화를 중심으로 정리한 개인적인 생각입니다.틀릴 수 있다는 점을 먼저 말씀드리고 시작할게요. 가장 먼저 느낀 변화는 만들어보는 일의 문턱이 낮아졌다는 점입니다.예전에는 아이디어가 있어도 화면 하나 보여주려면 디자이너와 개발자의 시간이 필요했습니다.요즘은 코딩 도구에게 설명하고 작은 동작 예제를 만들어서, 말로는 전달하기 어려운 흐름을 바로 눈으로 보여줄 수 있습니다.저처럼..
MCP와 도구 호출, 서비스 기획자 관점으로 정리
AI 이야기를 따라가다 보면 요즘 "MCP"라는 단어를 자주 만납니다.도구 호출이라는 말과 함께 나오는 경우가 많은데, 처음에는 개발자들만 쓰는 용어 같아서 그냥 지나쳤어요.그런데 예약 시스템 기획을 하면서 "서비스의 기능을 AI가 쓸 수 있게 열어두면 어떨까?"라는 질문이 자꾸 나오다 보니, 기획자도 어느 정도는 이해하고 있어야겠다는 생각이 들었습니다.이번 글은 제가 이해한 만큼을 기획자 눈높이로 정리한 노트입니다.개발 세부 사항이나 특정 제품의 사양은 단정하지 않고, 개념과 기획할 때 필요한 판단 위주로 적었어요. 먼저 도구 호출부터 이야기해보겠습니다.언어 모델은 기본적으로 글을 받아서 글을 내놓는 존재입니다.그래서 "내일 오후 3시에 빈 자리 있어?" 같은 질문을 받아도, 실제 예약 시스템에 접속해..
예약 시스템에 AI 에이전트를 붙인다면, 설계 원칙
예약 시스템 기획을 하다 보면 "AI가 대신 예약해주면 되지 않나요?"라는 이야기를 자주 듣게 됩니다.말로 하면 간단한데, 막상 설계하려고 하면 따져볼 것이 한두 가지가 아니에요.이번 글은 예약 시스템에 AI 에이전트를 붙인다고 가정했을 때, 제가 기획자로서 지켜야 한다고 생각하는 설계 원칙을 정리한 것입니다.실제로 만들어서 운영한 경험을 쓰는 글은 아니고, 그동안 예약 도메인과 AI를 함께 공부하며 정리한 가설에 가깝습니다.그래서 확정된 정답이라기보다 "이런 선을 먼저 그어두면 좋겠다"는 메모로 읽어주시면 좋겠습니다. 에이전트를 붙인다고 하면 모든 걸 맡기고 싶은 마음이 먼저 듭니다.하지만 처음에는 할 일을 아주 좁게 정하는 것이 안전하다고 생각해요.예를 들어 가상의 반려동물 미용실이 있다고 해보겠습니..