기획자 실전노트

서비스 기획에서 중요한 건 결국 “혼자 정답을 내는 능력”이 아니었다서비스 기획을 처음 할 때는좋은 아이디어를 내고, 논리적으로 맞는 방향을 정하면 일이 진행될 거라고 생각했다.그런데 실제로 일을 하다 보면기획의 핵심은 기능 자체보다도“여러 부서와 같은 방향으로 결론을 만드는 과정”에 더 가까웠다.특히 최근에는기획자가 단순히 화면을 설계하는 사람이 아니라,목적과 현실 사이에서 균형을 맞추는 역할이라는 걸 많이 느끼고 있다.기획은 “맞는 방향”보다 “움직일 수 있는 방향”을 만드는 일어떤 기능이나 정책은처음 의도만 보면 굉장히 명확하다.사용자 경험 개선운영 효율화특정 행동 유도서비스 신뢰도 강화그런데 실제로 적용하려고 하면예상하지 못했던 운영 이슈나 예외 상황들이 계속 나온다.그리고 이 시점부터는기획 혼자..

나에게만 좋은 기능, 과연 좋은 기능일까?서비스를 기획하다 보면 이런 순간이 온다.“이 기능 진짜 좋다.”“이거 있으면 운영 엄청 편해지겠다.”문제는,그 ‘좋다’의 기준이 사용자가 아니라 나 자신일 때다.기획자가 빠지기 쉬운 착각기획자는 서비스 구조를 누구보다 잘 안다.그래서 자연스럽게 이런 판단을 하게 된다.이 흐름이 더 효율적인데?이건 이렇게 묶는 게 관리하기 편한데?이 기능 있으면 일 처리 속도 빨라지는데?모두 맞는 말이다.하지만 여기에는 빠진 질문이 하나 있다.“그래서, 사용자 입장에서는 어떤데?”“운영에 좋은 기능” vs “사용자에게 좋은 기능”예를 들어, 특정 라벨을 붙이는 기능을 만든다고 가정해보자.운영 입장에서는→ “조건 맞으면 자동으로 라벨 붙이자”→ “관리 편하게 일괄 적용하자”여기까지..

서비스 기획에서 ‘건수 노출 정책’이 중요한 이유서비스를 기획하다 보면 거의 빠지지 않는 요구사항이 있다.바로 조회수, 문의수, 클릭수 같은 ‘건수 지표’를 화면에 보여주는 것이다.“이 매물 인기 있어 보이게 하고 싶어요”“판매자에게 활동 성과를 보여주고 싶어요”“구매자가 판단할 수 있는 기준이 필요해요”기획자 입장에서는 너무 자연스럽다.하지만 이 지표를 ‘실시간’으로 보여주기 시작하면 문제가 생긴다.실시간 집계가 서버에 부담이 되는 이유조회수나 문의수를 실시간으로 처리하려면,사용자 행동이 발생할 때마다 서버가 즉시 DB를 읽고 쓰는 구조가 된다.이 구조가 위험한 이유는 다음과 같다.트래픽이 몰리면 DB write가 폭증단순 새로고침만으로도 집계가 계속 발생봇, 크롤러, 악성 공격에 그대로 노출실제 사용..

서비스에서 영상 콘텐츠를 다루기 시작하면,기획자는 반드시 보관 정책을 함께 고민해야 한다.왜냐하면 영상은데이터 용량이 크고시간이 지날수록 누적되며그대로 두면 스토리지 비용이 기하급수적으로 증가하기 때문이다.특히 거래형 서비스(매물, 중고차, 커머스 등)의 경우이미 실효성이 사라진 영상을 무기한 보관할 이유는 없다.“언제까지, 어떤 상태의 영상을 보관할 것인가”이 질문에 답하지 않으면 운영비는 계속 쌓인다.문제 정의: 매물 영상 무기한 보관 이슈운영 중인 서비스에서는 매물 동영상을 무기한 보관하고 있었고,그 결과 스토리지 비용 증가 문제가 발생했다.이에 따라 먼저 운영 데이터를 확인했다.운영팀 확인 결과판매 완료 후 발생하는 클레임은 대부분 2주 이내 종료클레임까지 포함해도 최대 6주 내 이슈 종료즉, 영..

글로벌 바이어가 유입되는 서비스에서“이 사용자는 어느 국가에서 들어왔는가?” 는운영·세일즈·정책 설계 모두에 중요한 데이터다.이번에 GeoIP 서비스를 도입하면서단순히 API를 붙이는 수준이 아니라,트래픽 규모에 따라 확장 가능한 구조를 전제로 설계를 진행했다.왜 GeoIP를 도입했는가우리 서비스는로그인하지 않은 비회원도차량 조회 및 문의가 가능한 구조다.이로 인해 기존에는“어느 국가에서 문의가 발생했는지”를 정량적으로 파악하기 어려웠다.GeoIP를 통해 IP 기반 국가 정보를 수집하면,국가별 문의 비중 분석특정 국가 타겟 UX / 언어 전략 검토셀러·바이어 운영 정책 수립등에 활용할 수 있다고 판단했다.1차 설계: 비동기 로그 기반 GeoIP API 호출핵심 원칙국가 정보 수집은 중요하지만,문의 UX를..

서비스 기획을 하다 보면의외로 자주 듣는 질문이 있다.“요즘 문의가 늘었나요?”막연하게는 느껴지지만,정확한 수치를 근거로 답하기는 쉽지 않다.최근 이 문제를 해결하기 위해문의 이벤트 로그를 수집하는 기획을 진행했고,그 과정에서 고민했던 내용을 기록으로 남겨본다.문의 로그를 왜 수집하려고 했을까기존에는 문의와 관련해 아래 정도만 파악하고 있었다.운영팀의 체감특정 기능 배포 이후의 추측일부 정성적인 피드백하지만 이런 방식으로는문의가 정말 늘었는지어떤 변화가 영향을 미쳤는지개선이 효과가 있었는지를 명확히 설명하기 어려웠다.그래서 최소한 다음은 알고 싶었다.하루 기준 문의 발생 건수특정 UI/정책 변경 전후 문의 변화문의 버튼 클릭 대비 실제 문의 완료 비율이를 위해 가장 기본적인 단계로문의 이벤트 로그 수집을..

9월 2주차 회고 (KPT)K: Keep – 잘하고 있는 것상세 기획안 작성하기본부장님 요청에 따라 이전부터 제대로 했어야 했던 기획서 작성을 다시 상세하게 적는걸 하고 있다.wbs부터 어떤 요구사항으로 진행할지 세세히 적고 그에따른 기능정의도 구체적으로 적는 연습중.기획서는 상세하고 한치의 중의적 표현이 없어야한다.물론 완벽할 수는 없지만 그동안 너무 간단히 적는 바람에 개발자들이 피보는 일도 있었고 나 조차 당당할 수 없었다. 언제 누가봐도 충분히 이해할 수 있는 기획안인지 생각하고 적어보자.P: Problem – 문제라고 생각하는 것우선순위에 따른 뇌활용뇌과학자에 의하면 아침 9-11시가 가장 뇌가 활발하게 생각하는 시간이라고 한다. 그 말인 즉슨, 효율이 엄청나게 높다는 것이다. 이를 토대로 황금..

매주 회고하는 주간 회고 툴을 공유합니다.주간 단위로 나뉘고 회고하는 날짜를 선택하면 해당 주간별로 나뉘어 표시되어요. KPT 회고는 Keep : 유지할 것 / Problem: 반성할 것/ Try: 시도해 볼 것을 기준으로 구성된 회고방법이며, 회고는 주기적으로 하고 복기해보는데에 큰 의미가 있습니다. 노션 공유https://trite-hawthorn-705.notion.site/work-review-25e3a66f1eba8012b40fefa6f9675596?source=copy_link work review | NotionMade with Notion, the all-in-one connected workspace with publishing capabilities.trite-hawthorn-705...

KPT로 매주 회고를 진행중이다. 아주 짧게라도 적고 지난 회고를 돌이켜 보고 있다. 이제 꽤 경력이 쌓였음에도, 제대로 경력을 쌓지 못하고 물경력이 된 느낌이 낭낭하다.이제라도 배운다고 생각하고 더 꼼꼼히 여러 경우의 수를 생각하는 기획자가 되고 싶다.문서로 소통하는 업이기에 더욱 꼼꼼해야 한다. 8월 3주차 회고 (KPT) K: Keep – 잘하고 있는 것깊이 생각하기요청사항을 단순히 처리하지 않고 여러 경우의 수를 고려하며 기획하고 있음. 예전처럼 급하게 마무리하는 대신 시간을 들여 탄탄하게 다듬는 과정이 점점 익숙해지고 있음.P: Problem – 문제라고 생각하는 것업무 중 집중력 저하집중하기 싫을 때 다른 일에 손을 대는 습관이 있음. 한 번 흐트러지면 다시 몰입하는 데 시간이 오래 걸려 효..

📱 안드로이드 앱 등록, 생각보다 까다롭다?비공개 테스트부터 정책 심사까지, 실무에서 겪은 생생 후기안녕하세요.서비스 기획자로서 최근 내부 프로젝트 앱을 Google Play에 등록하면서,**“안드로이드 앱 등록이 예전 같지 않다”**는 걸 실감했습니다.특히, 비공개 테스트 요건 강화는 개발팀뿐만 아니라 기획자에게도 꽤 중요한 이슈로 다가왔습니다.이번 글에서는 실무에서 직접 겪은 내용을 정리해 공유드립니다.🔐 1. 앱 등록 전, 비공개 테스트 14일 의무화과거엔 앱을 개발한 후 APK나 AAB만 준비되면 바로 등록이 가능했지만,2023년 후반부터 Google은 신규 앱에 대해 비공개 테스트를 요구하고 있습니다.✔️ 실제 정책 요약테스트 기간: 최소 14일테스터 수: 20명 이상테스터 유지 조건: 테스..