Showing Posts From

기획

• 05 Jan, 2026
• • 인사이트

기획 안건이 거절되고 3개월 후 다시 올렸을 때

3개월 전 기획안 5월에 올렸던 기획안. "결제 플로우 개선안". 유저 인터뷰 15명 했다. 이탈률 데이터도 있다. 경쟁사 벤치마크도 붙였다. 결과는 반려. "우선순위 아니다." 이유 설명은 짧았다. 회의는 15분 만에 끝났다. 담당 임원이 물었다. "이거 개선하면 매출 얼마나 오르나요?" 정확한 수치 못 냈다. A/B 테스트 전엔 불가능하다고 했다. 표정이 굳었다. 기획안에 들어간 시간. 리서치 3주, 분석 2주, 문서화 1주. 6주였다. 발표는 15분. 퇴근길에 생각했다. '데이터가 부족했나.' '설득력이 약했나.' '유저 인터뷰를 더 했어야 했나.'3개월 동안 6월. 다른 프로젝트 했다. 마케팅팀 협업. 이벤트 페이지 기획. 큰 프로젝트는 아니다. 그런데 회의에서 들었다. CFO가 바뀌었다. 새 CFO는 "디지털 전환" 강조한다고. 전사 메일도 왔다. "고객 경험 개선에 투자" 7월. 마케팅 이벤트가 성공했다. 전환율 23% 올랐다. 팀장이 좋아했다. 전사 회의에서 사례 발표했다. 발표 후 임원 한 명이 물었다. "다른 개선 계획도 있나요?" "있습니다"라고 답했다. 8월. 조직 개편 소문 들었다. IT본부와 비즈니스본부 통합된다고. 실제로 8월 말 발표 났다. 보고 라인이 바뀌었다. 새 본부장은 전 아마존 출신이다. OKR 도입한다고 했다. Q3 목표에 "결제 전환율"이 들어갔다.같은 기획안을 다시 8월 말. 5월 기획안 다시 꺼냈다. 내용은 같다. "결제 플로우 개선안" 수정한 건 두 가지. 첫 페이지에 "Q3 OKR - 결제 전환율 개선" 추가했다. 예상 효과 부분에 "마케팅 이벤트 사례 참고"라고 넣었다. 데이터는 그대로다. 유저 인터뷰도 같은 내용이다. 분석도 똑같다. 9월 첫째 주 회의. 같은 임원들이다. 발표 시작했다. 5분 지나자 질문 들어왔다. "이거 언제부터 가능한가요?" "개발 리소스는요?" "A/B 테스트 기간은요?" 분위기가 다르다. 3개월 전엔 "왜"를 물었다. 지금은 "어떻게"를 묻는다. 회의 끝에 팀장이 말했다. "다음 주 개발팀이랑 일정 조율하세요." 통과였다. 회의실 나오면서 이상했다. 같은 기획안인데.배운 것 데이터는 중요하다. 근데 충분하지 않다. 같은 데이터도 맥락이 다르면 해석이 달라진다. 5월엔 "그냥 개선안"이었다. 9월엔 "OKR 달성 방법"이 됐다. 조직 상황을 읽어야 한다. CFO 교체, 조직 개편, OKR 도입. 이런 게 기획 통과에 영향 준다. 타이밍도 역량이다. 언제 올리느냐가 내용만큼 중요하다. 정치라고 생각했다. 처음엔 불편했다. "좋은 기획이면 언제든 통과돼야지" 그렇게 믿었다. 근데 9년 차 되니 안다. 조직은 기계가 아니다. 우선순위는 계속 바뀐다. 의사결정자 관심사도 바뀐다. UX 기획자 역할. 유저 리서치하고 데이터 분석하는 것. 맞다. 근데 전부는 아니다. 조직 흐름 읽기. 이해관계자 니즈 파악. 적절한 시점 판단. 이것도 역량이다. 학교에서 안 가르친다. 책에도 잘 안 나온다. 경험으로 배운다. 후배가 물었다 "왜 다시 올렸어요?" 후배가 물었다. 신입 2년 차다. "타이밍이 맞아서"라고 답했다. "조직 상황 보면서" 후배가 고개 갸웃했다. "그럼 처음부터 기다렸다가 올릴 걸 그랬잖아요" 설명했다. "5월엔 몰랐지. 8월에 조직 개편될 줄. OKR 도입될 줄" "그럼 우연이네요?" 후배가 말했다. "반은 맞아. 근데 나머지 반은 준비였어. 기획안 계속 들고 있었잖아. 타이밍 오면 바로 올릴 수 있게" 후배가 노트에 적었다. 성실한 친구다. "하나 더 알려줄까. 5월에 반려됐을 때 삐지지 마. 개인적으로 받아들이지 마. 조직 상황이 안 맞았던 거야. 기획이 나쁜 게 아니라" 후배가 고개 끄덕였다. "그래도 속상하지 않았어요?" "속상했지. 6주 날렸으니까. 근데 날린 게 아니더라. 3개월 후 쓸 수 있었잖아" 다음 기획안 책상에 기획안 3개 더 있다. 지난달 반려된 것들이다. 하나는 "검색 필터 개선안". 유저 불편 포인트 명확하다. 근데 개발 공수 크다고 반려됐다. 하나는 "온보딩 프로세스 개선". 신규 유저 이탈률 높은데. "지금은 MAU 유지가 우선"이라고 했다. 하나는 "마이페이지 재설계". 정보 구조 복잡하다. 근데 "터치하기 부담스럽다"고 했다. 버리지 않았다. 폴더에 정리해뒀다. "보류된 기획안" 언젠가 올릴 날 온다. 조직 목표가 바뀌거나. 경쟁사 이슈 생기거나. 새 서비스 런칭하거나. 그때 바로 꺼낸다. 데이터 업데이트하고. 첫 페이지에 맥락 추가하고. 다시 올린다. 타이밍 기다리는 것. 포기 아니다. 전략이다. 9년 차의 깨달음 신입 때는 몰랐다. "좋은 기획 = 통과"라고 생각했다. 3년 차 때도 답답했다. "왜 데이터 있는데 안 받아줘" 불평했다. 6년 차쯤 알았다. 조직 정치 존재한다는 거. 근데 여전히 싫었다. 9년 차 지금. 받아들였다. 정치가 아니라 현실이다. 조직은 생물이다. 우선순위 바뀐다. 의사결정자 바뀐다. 시장 상황 바뀐다. UX 기획자는 유저 대변한다. 맞다. 근데 조직 맥락도 읽어야 한다. 그래야 유저 니즈를 현실로 만든다. 데이터 분석, 유저 리서치. 기본기다. 근데 충분하지 않다. 타이밍 판단, 이해관계자 설득, 조직 흐름 읽기. 이것도 필요하다. 학교에서 안 가르친다. 현장에서 배운다. 3개월 기다리면서 배운다. 다음 회의 다음 주 회의 있다. 마이페이지 재설계안 올릴까 고민 중이다. Q4 목표 발표 나왔다. "고객 충성도 제고" 들어갔다. 마이페이지 관련 있다. 근데 개발팀 리소스 확인 필요하다. 다른 프로젝트 일정도 봐야 한다. 월요일에 개발 팀장이랑 커피 약속 잡았다. "요즘 어때요?" 물어볼 거다. 여유 있으면 기획안 슬쩍 꺼낸다. 없으면 다음 달 기다린다. 조급하지 않다. 기획안은 있으니까. 타이밍은 또 온다.좋은 기획도 때를 기다린다. 그게 9년 차가 배운 것이다.

• 16 Dec, 2025
• • UX기획

UX 기획 vs 서비스 기획, 경계가 모호할 때 나는

UX 기획 vs 서비스 기획, 경계가 모호할 때 나는 9년 차인데도 설명 못 하는 것 회의실에서 누가 물었다. "그래서 UX 기획이랑 서비스 기획이 뭐가 달라요?" 9년 차다. 대답 못 했다. "음... UX는 유저 중심이고, 서비스는 비즈니스 중심?" 말하면서도 애매했다. 상대방 표정이 더 헷갈려했다. 퇴근하면서 생각했다. 내가 하는 일이 뭐지. 유저 인터뷰하고, 페르소나 만들고, 플로우 그리고, 와이어프레임 그리고. 그런데 경쟁사 분석도 하고, BM 회의도 참여하고, KPI 설정도 같이한다. 어디까지가 UX고 어디서부터 서비스 기획인가. 명함엔 'UX 기획자'라고 써있다. 그런데 하는 일을 보면 서비스 기획자 같기도 하다. 아니, 둘 다인가. 아니면 둘 다 아닌가. 경력 9년인데 내 직무 정의를 못 한다는 게 웃겼다.회사마다 다른 정의 전 직장에서는 명확했다. UX팀은 리서치와 UI 설계. 서비스 기획팀은 BM과 전략. 경계가 뚜렷했다. 지금 회사는 다르다. UX 기획자가 서비스 전략 회의에 들어간다. 매출 목표도 공유받는다. 'UX가 왜 매출 신경 써요?' 라는 질문은 없다. 당연하다는 듯이. 지난주에 신입이 물었다. "선배님, 여기서 UX 기획자는 뭐 하는 거예요?" "음... 유저 리서치하고, 기획도 하고, 전략도 좀 하고..." 말하면서 이상했다. 다 한다는 건가. 동기는 다른 회사에 있다. 스타트업. 거기선 UX 기획자가 그로스도 한다. A/B 테스트 직접 돌리고, 지표 보고, 가설 세우고. "여긴 UX 기획이랑 그로스 매니저 경계가 없어" 라고 했다. 또 다른 친구는 외국계. 거긴 UX Research와 UX Design이 완전 분리다. 리서치는 인사이트까지만. 디자인은 솔루션부터. 서비스 기획은 PM이 따로 있다. 역할이 칼같이 나뉜다. 회사마다 다르다. 조직 구조마다 다르다. 프로젝트마다 다르다. 그러니까 '정답'이 없다. 그게 문제다.실제로 하는 일을 나열하면 월요일. GA4 대시보드 확인. 이탈률이 높다. 어디서 이탈하나. 왜 이탈하나. 이건 UX 기획 일이다. 그런데 이탈률 개선하려면 BM을 바꿔야 한다. 수익 모델 자체가 문제니까. 그럼 이건 서비스 기획 일 아닌가. 화요일. 유저 인터뷰. "이 기능 왜 안 쓰세요?" 물었다. "필요 없어서요." 대답이 명확했다. 인사이트 정리. '기능 자체가 유저 니즈와 안 맞음.' 이건 UX 리서치. 그런데 회의에서 말했다. "이 기능 빼고 다른 거 넣어야 해요." PM이 물었다. "뭘 넣죠?" "이런 거요." 대안 제시. 기능 우선순위 재조정. 이건 서비스 기획 아닌가. 수요일. 와이어프레임 그렸다. 플로우 설계. 터치포인트 정의. 인터랙션 디테일까지. UX 기획 맞다. 그런데 PM이 물었다. "이거 개발 공수 얼마 나와요?" 개발팀 찾아가서 협의. "2주 걸립니다." "그럼 일정 조정 가능해요?" 일정 협의. 리소스 배분. 이건 프로젝트 매니징 아닌가. 목요일. 경쟁사 분석. 비슷한 기능을 어떻게 구현했나. UX 패턴은 뭔가. 플로우는 어떤가. 벤치마킹. 이건 UX 기획. 그런데 "경쟁사는 프리미엄 모델로 수익화 해요" 라고 보고했다. BM 분석까지 들어간다. 이건 서비스 기획 아닌가. 금요일. 회의가 4개. 오전: UX 개선 회의. 유저 테스트 결과 공유. 점심: 신규 서비스 전략 회의. 타겟 정의, 포지셀닝 논의. 오후: 개발팀 스프린트 회의. 백로그 우선순위 조정. 저녁: 임원 보고. 서비스 로드맵 발표. 어떤 회의가 UX 기획이고 어떤 게 서비스 기획인가. 전부 다 섞여 있다. 내가 하는 일을 카테고리로 나누기 불가능하다. 경계가 없다. 아니, 경계를 긋는 게 무의미하다. 팀원들도 헷갈린다 후배가 물었다. "선배님, 저 UX 기획 지원했는데 왜 BM 공부하래요?" 대답 못 했다. 나도 모르겠으니까. "일단 해봐. 필요하더라." 라고만 했다. 설득력 제로. 다른 후배는 이력서를 봐달라고 했다. 경력 기술서에 "유저 리서치, 페르소나 설계, IA 설계, 와이어프레임, 프로토타입, 서비스 전략 수립, BM 설계, KPI 관리" 다 들어가 있었다. "이거 UX 기획 맞아요?" 후배가 물었다. "응. 맞아." 대답했다. 확신은 없었다. "그럼 서비스 기획 이력서랑 뭐가 달라요?" "음..." 할 말이 없었다. 실제로 서비스 기획 JD 찾아봤다. "유저 니즈 파악, 서비스 전략 수립, 기능 기획, 와이어프레임 작성, 데이터 분석, KPI 관리" UX 기획 JD도 찾아봤다. "유저 리서치, 페르소나 설계, 서비스 기획, IA/UI 설계, 프로토타입, 데이터 분석" 겹친다. 거의 80%. 차이가 뭔가. '유저 리서치'가 강조되면 UX고, '비즈니스 전략'이 강조되면 서비스인가. 그것뿐인가. 채용공고만 봐도 모호하다. 회사도 헷갈리는 거다.9년 차의 결론은 없다 결론 내렸다. 경계는 없다. 아니, 경계를 굳이 그을 필요가 없다. UX 기획이냐 서비스 기획이냐는 '무엇을 하느냐'보다 '어떤 관점으로 접근하느냐'의 차이 같다. 유저 관점에서 출발하면 UX 기획. 비즈니스 관점에서 출발하면 서비스 기획. 그런데 결국 둘 다 필요하다. 유저 없이 비즈니스 없고, 비즈니스 없이 유저도 못 모은다. 그래서 요즘은 섞인다. 융합된다. UX 기획자가 BM 이해해야 하고, 서비스 기획자가 유저 리서치 할 줄 알아야 한다. 직무명은 중요하지 않다. 명함에 뭐라고 써있든, 하는 일은 비슷해진다. 다만 차이가 있다면 '강점'이다. 나는 유저 리서치가 강하다. 정성 데이터 분석, 인터뷰 설계, 인사이트 도출. 여기서 출발해서 서비스 전략으로 확장한다. 서비스 기획자는 반대일 수 있다. 시장 분석이 강하고, BM 설계가 강하다. 거기서 출발해서 유저 니즈로 좁혀온다. 출발점이 다를 뿐. 결국 만나는 지점은 같다. 그래서 9년 차의 답은 이거다. "UX 기획과 서비스 기획은 다르다. 그런데 같다. 경계는 모호하다. 그게 정상이다." 명확한 답은 아니다. 그런데 이게 현실이다. 그럼 나는 뭐라고 소개하나 명함엔 'UX 기획자'라고 써있다. 그런데 소개할 땐 "유저 중심으로 서비스 만드는 사람"이라고 한다. 직무명보다 '뭘 하는 사람인지'가 더 중요하다. 최근 컨퍼런스에서 발표했다. 제목은 "UX 리서치 기반 서비스 전략 수립 사례" UX인가 서비스인가. 둘 다다. 섞여 있다. 구분 안 한다. 청중 중 한 명이 질문했다. "그럼 선배님은 본인을 UX 기획자라고 생각하세요, 서비스 기획자라고 생각하세요?" 대답했다. "둘 다요. 경계에 서 있는 사람이요." 어색하지 않았다. 9년 동안 깨달은 거다. 경계가 내 위치다. 조직마다 다른 이유 왜 회사마다 정의가 다를까. 생각해봤다. 조직 구조 때문이다. PM이 있는 회사: UX 기획자는 리서치와 UI 설계에 집중. 서비스 전략은 PM이. PM이 없는 회사: UX 기획자가 PM 역할까지. 전략부터 실행까지 다. 디자이너가 강한 회사: UX 기획자는 리서치와 IA까지. UI는 디자이너가. 디자이너가 약한 회사: UX 기획자가 픽셀 단위 디자인까지. 스타트업: 역할 구분 없다. 다 한다. UX든 서비스든 그로스든. 대기업: 역할 명확하다. 그런데 협업 과정에서 섞인다. 조직이 직무를 정의한다. 직무가 조직에 맞춰진다. 그래서 '표준 정의'는 없다. 있을 수가 없다. 다만 트렌드는 있다. 요즘은 UX 기획자한테 비즈니스 이해를 요구한다. 서비스 기획자한테 유저 리서치 역량을 요구한다. 경계가 흐려지는 중이다. 융합되는 중이다. 5년 후엔 구분 자체가 무의미해질 수도 있다. 'Product Manager'로 통합되거나, 아니면 완전히 새로운 직무명이 생기거나. 헷갈릴 때마다 하는 것 경계가 모호할 때마다 묻는다. "이 일이 유저한테 도움이 되나?" "이 일이 서비스 성장에 기여하나?" 둘 다 예스면 한다. 직무명은 상관없다. 지난달에 BM 개편 프로젝트 참여했다. "이거 UX 기획 일 아니지 않아요?" 누가 물었다. "유저 이탈을 줄이는 일이니까 UX 기획 맞지 않나요?" 반문했다. 더 이상 질문 없었다. 직무 경계보다 임팩트가 중요하다. 유저에게, 서비스에게. 그걸 만들어내는 게 내 일이다. UX 기획자든 서비스 기획자든. 명함에 뭐라고 써있든 상관없다. 중요한 건 결과다. 후배들한테 하는 말 요즘 후배들이 많이 묻는다. "UX 기획 커리어 쌓으려면 뭐 해야 해요?" 대답한다. "유저 리서치 잘하면 된다. 그게 기본이다." "그런데 비즈니스도 이해해야 한다. 안 그러면 리서치가 액션으로 안 이어진다." "서비스 기획으로 전환 가능해요?" "가능하다. 근데 UX 기획 계속해도 결국 비슷한 일 한다." "어떤 게 더 유망해요?" "직무명 말고 역량을 키워라. 유저 이해 + 비즈니스 이해. 둘 다 있으면 어디든 간다." 직무 경계 고민하는 시간에 역량 키우는 게 낫다. 9년 차 조언이다. 나도 여전히 헷갈린다. 그런데 헷갈리는 게 정상이다. 경계에 있는 게 오히려 강점이다. 양쪽을 다 본다. 유저도 보고 비즈니스도 본다. 그게 요즘 시대에 필요한 거다. 결국 9년 차도 모른다 명확한 답은 여전히 없다. UX 기획과 서비스 기획의 경계는 모호하다. 회사마다 다르고, 프로젝트마다 다르고, 사람마다 다르다. 9년 차인데도 설명 못 한다. 그런데 그게 정답인 것 같다. 경계가 없다는 게 답이다. 구분하려고 하지 말고, 필요한 걸 하면 된다. 유저를 이해하고, 비즈니스를 이해하고, 그 사이에서 최선의 솔루션을 만든다. 그게 내 일이다. 직무명은 중요하지 않다.내일도 회의실에서 누가 물을 거다. "UX 기획이랑 서비스 기획 차이가 뭐예요?" 여전히 명확한 답은 못 할 거다. 그런데 괜찮다. 10년 차가 돼도 모를 거다. 그게 이 일이다.