이상인

AI-Native Product BuilderProduct Generalist

서비스 기획을 기반으로 디자인, 개발, 마케팅과 실험을 연결해 아이디어를 실제 제품으로 만듭니다.

채널과 연락처

About

서비스 기획으로 시작했습니다.

사용자 조사를 통해 문제를 찾고, 서비스 흐름과 정책을 설계하고, 여러 직군과 협업해 출시까지 연결하는 법을 배웠습니다. Trippixel에서는 9인 팀과 AI 여행 조율 플래너를 공개 출시했고, 이후 GA4와 사용자 인터뷰, VOC를 살펴보며 실제 사용과 기획 사이의 차이도 확인했습니다.

기획서에 머물고 싶지는 않았습니다.

아이디어를 직접 확인하려고 디자인과 코드를 익혔고, 마케팅과 게임 개발, AI 시스템과 개발자 도구까지 만드는 범위를 넓히고 있습니다. 여러 분야를 얕게 다루는 것이 목적은 아닙니다. 해결하려는 문제에 필요한 역할을 직접 연결하고, 가능한 데까지 실제 결과물로 만들어 보는 것이 제 방식입니다.

만들고 판단한 과정을 남깁니다.

그래서 저를 AI-Native Product Builder이자 Product Generalist라고 소개합니다. AI는 대신 판단해 주는 존재보다 조사하고 설계하고 만들고 검증하는 과정을 넓혀 주는 도구에 가깝습니다. onebuilderlog에는 완성된 결과뿐 아니라 그 과정에서 내린 판단과 실패, 새로 배운 것들도 함께 남깁니다.

Profile snapshot

4개사용자 조사 기반 프로젝트

1개공개 출시 경험

2개단독 PM 프로젝트

8-9인크로스펑셔널 협업 규모

Education

서울사이버대학교

컴퓨터공학과 재학

2026.03 - PRESENT

제주한라대학교

사회복지학과 졸업

2018.03 - 2023.02

Training

구름 × 카카오 프로덕트 매니지먼트 부트캠프

수료

2025.09

Credentials

GAIQ

Google Analytics Individual Qualification

2026.02

What I can contribute

문제 탐색

사용자 조사, 인터뷰, VOC를 문제와 가설로 정리합니다.

제품 설계

서비스 흐름, 정책, 우선순위를 실행 가능한 단위로 만듭니다.

측정과 판단

GA4와 사용자 피드백을 다음 제품 판단에 연결합니다.

직접 구현

Astro, TypeScript, Python, Codex로 검증 가능한 제품 표면을 만듭니다.

Now learning

컴퓨터공학

서비스를 직접 구현하기 위한 기술 기반을 공부하고 있습니다.

제품 기획과 PM

문제 정의와 우선순위 설정, 출시 이후의 운영 판단을 더 깊게 공부하고 있습니다.

데이터 기반 의사결정

사용자 행동과 제품 지표를 분석해 다음 판단으로 연결하는 방법을 익히고 있습니다.

AI 제품과 개발자 도구

사람과 AI가 함께 일하는 제품과 도구를 직접 만들며 검증하고 있습니다.

Interests

01
제품은 어떻게 실제 사용까지 이어지는가
02
AI에게 어디까지 일을 맡겨야 하는가
03
서로 다른 역할은 하나의 제품으로 어떻게 연결되는가
04
개인은 AI와 함께 어디까지 만들 수 있는가

Selected work

문제를 찾고, 직접 검증한 네 개의 프로젝트

공개 출시2025.11 - 2026.05

Trippixel

AI 여행 조율 플래너

Why: 성향이 다른 여행자들이 여행 전 정보 수집과 의견 조율에 큰 부담을 느끼는 문제에서 시작했습니다.
Core problem: 장소 저장, 의견 공유, 일정 확정이 여러 도구에 흩어져 계획을 주도하는 사람에게 조율 부담이 집중됐습니다.
Role: 단독 기획/PM · 9인 팀
Evidence: 설문 64명 · 인터뷰 5명 · 2026.03.18 웹 공개 출시 · GA4 사용자 65명/세션 시작 91회
What remains: 반복 사용으로 이어지는 핵심 순간은 추가 검증 중입니다.

실서비스 열기

미출시 프로토타입2025.08 - 2025.09

모여행

실시간 공동 편집 여행 대시보드

Why: 동행자가 많아질수록 여행 계획 주도자에게 정보 정리와 의사결정 부담이 집중되는 문제를 줄이려고 만들었습니다.
Core problem: 장소 수집, 의견 조율, 일정 정리가 여러 도구에 분산되어 함께 계획하기 어려웠습니다.
Role: 단독 PM · 8인 팀
Evidence: 설문 87명 · 인터뷰 11명 · 사용자 테스트

케이스 자료 요청

프로토타입 검증2025.07 - 2025.08

배달의민족 1인 가구 경험 제안

비공식 제품 개선 사례 연구

Why: 1인 가구가 검증된 메뉴와 가게를 저장해 빠르게 재주문하려는 요구를 더 짧은 흐름으로 연결하려고 제안했습니다.
Core problem: 기존 재주문과 찜 흐름의 인지도가 낮고, 저장과 재방문 목적이 하나의 경험으로 연결되지 않았습니다.
Role: APM · PM 4인 팀
Evidence: 인터뷰·UT · 프로토타입 검증 2회

케이스 자료 요청

사용자 조사·프로토타입2025.06 - 2025.07

다정이

보호자 안심 신호 서비스

Why: 전화 미수신을 사고 가능성으로 받아들이는 보호자의 불안을 상시 감시 없이 줄이려고 만들었습니다.
Core problem: 반복 연락은 보호자에게는 불안을, 어르신에게는 사생활 침해와 관계 갈등을 만들었습니다.
Role: PM/팀장
Evidence: 보호자 인터뷰 6명 · 프로토타입 검증 4명

케이스 자료 요청

Independent AX workflow studies

업무 판단을 실행 가능한 규칙으로 바꾼 세 가지 사례

공개 자료를 문제의 출발점으로 삼아, 사람의 판단 경계·입력·규칙·검증을 직접 설계한 독립 사례입니다.

ARCHIVE STATUS이 페이지에는 직접 작성한 요약과 검증 범위만 싣습니다. 제3자 참고 캡처가 포함된 제출 PDF는 권리 검토 전 공개하지 않습니다.

01MyRealTrip

독립 연구 · 로컬 검증

취소 직후 노출 정책을 검수하는 규칙 기반 평가

정책 QA · 실험 준비성 2026.06

Problem boundary: 취소 직후의 대체 상품 노출은 기회이지만, 취소 사유 반복·가격 급등·예약 근거 부족을 놓치면 신뢰와 CS 리스크가 커집니다.
Operating model: 판정 시점 입력과 사후 성과를 분리하고, 6개 위험 규칙으로 후보를 expose · needs_review · suppress와 정책 전체 ship · revise · hold로 나눕니다.
Local proof: mock 시나리오와 공개 MCP 스냅샷을 대상으로 5/5 단위 테스트를 통과했습니다. 공개 상품 근거가 부족한 경우 전체 정책을 hold로 되돌렸습니다.
Source scope: 문제 범위는 마이리얼트립 공개 기술블로그와 API 문서에서 정했고, 고객·결제·내부 로그는 사용하지 않았습니다.
Not claimed: 마이리얼트립의 내부 추천 시스템, 운영 배포, 매출·재예약률 상승을 증명하거나 주장하지 않습니다.

02Musinsa

독립 연구 · 합성 fixture 검증

양쪽 데이터 경계를 드러내는 파트너 성장 병목 진단

양방향 진단 · 데이터 요청 루프 2026.07

Problem boundary: 브랜드 맥락은 브랜드에, 노출·전환 신호는 플랫폼에 나뉘어 있어 한쪽 데이터만으로는 성장 병목을 단정할 수 없습니다.
Operating model: brand packet과 platform packet을 상품 단위로 대조해 7개 병목·confidence·누락 데이터·하지 말아야 할 주장을 함께 반환합니다.
Local proof: 7개 병목과 진단 불가를 포함한 합성 fixture 8건에서 8/8 기대값을 맞췄고, 임계값과 관측값의 하드코딩 경계를 검사했습니다.
Source scope: 문제 맥락은 무신사 공개 조직·뉴스룸 자료에서 정했고, 실제 브랜드·플랫폼 데이터는 사용하지 않았습니다.
Not claimed: 무신사 데이터 접근, 파트너 도입, 실제 브랜드 성장 효과를 증명하거나 주장하지 않습니다.

03KakaoPay

독립 연구 · 데모 정책팩 검증

업무 매뉴얼을 승인 가능한 정책팩으로 고정하는 PR 리뷰

정책 거버넌스 · 근거 기반 검토 2026.07

Problem boundary: AI가 만든 변경이 빨라질수록, 문서와 담당자 경험에 흩어진 보안·개인정보·운영 기준을 일관되게 적용하는 검토가 병목이 됩니다.
Operating model: 매뉴얼 원문 인용과 행 번호를 가진 규칙 후보를 사람 승인 뒤 정책팩으로 고정하고, PR에서는 예외와 근거 부족만 human_review로 올립니다.
Local proof: 직접 작성한 4개 데모 규칙과 6개 fixture PR에서 규칙 커버리지·상태 정확도·재현율 1.000, 환각 규칙 0을 확인했습니다.
Source scope: 문제 맥락은 카카오페이 공개 기술자료와 GitLab 리서치에서 정했고, 정책팩과 fixture는 직접 작성한 데모입니다.
Not claimed: 카카오페이 내부 매뉴얼·코드·보안 기준 접근, 운영 도입, 실제 PR 품질 개선을 증명하거나 주장하지 않습니다.

GitHub archive