[TIL] 내일배움캠프 251210 - 기술 블로그를 읽을 때도, 문제 발견 → 문제 정의 → 가설 수립 → 액션 → 검증 결과를 적용하자

 

오늘 강의 중,
기술 블로그를 볼 때,
문제 발견 - 문제 정의 - 가설 수립 - 액션 - 검증 결과
이 로직으로 글을 보면 좀 더 도움이 될 거라 하셨는데
내가 어제 여러 기술 블로그 글들로 인해 복잡해지고 헷갈린다고 느꼈었고 이 방법이 도움이 될 것 같다!

그리고.. 스터디를 하면서는 어쩔 수 없이 가설 수립까지만 하게 되고 검증을 할 수가 없는데
역시 실시간으로 움직이는 지표들을 보는 게 재밌는 것 같다.
그걸 살 떨리는 내 사업이 아닌 회사에서 해 볼 수 있다니
그런 기회가 있을 때 더 활용하고 열심히 하자....

어제 궁금했던 게 있어서 오늘 저녁 튜터님께 찾아가 여쭤 봤다!
난 무턱대고(?) 이렇게 하는 걸 어떨 땐 아주 잘 하고 어떨 땐 아주 못 하는데
더 열심히 '고민이 있어요' 해 보자
게다가 기술 블로그 쓰신 분께 직접 들을 수 있다니 얼마나 좋은 기회인가?

 

---

와이어프레임에서 화면을 기획할 때, 유저는 한 화면에 고정되어 있지 않다.
여러 화면을 넘나드는`맥락의 흐름`을 함께 설계해야 한다.
- 예시 : 결제 완료 안내 페이지
    - 목표행동 “결제가 완료되었음을 안내한다”
        - 유저플로우 생각 하지 않은 경우 : "`결제 완료 메시지`만 보여주면 되겠지?”
        - 유저 플로우를 생각한 경우 : “결제 완료 화면에 이런 정보들이 필요하겠다”

결제 화면에 있는 모든 정보가 그 화면 이전, 이후의 유저 플로우를 고려한 설계라고 생각하니 의미가 있다.

---

 

초등학생처럼 도형 그리기를 하며 피그마 강의를 수강하고 있다. 재미있다.

PM으로서 기본적인 UXUI 지식을 함양하는 것도 필요하고.. PM은 정말 알야아 할 게 얕고 넓게 많구나...!

모쪼록 피그마는 정말 세련되고 편리한 도구이자 좋은 협업툴이다!

 

---

 

목표 수립 - 문제 정의 - 가설 수립 및 검증

이 사고의 흐름에서 본 푸시 클릭률 6배를 만든 고객집중 29cm 케이스가 마케터로서도 본 것이라 반가웠다. 근데 이게 그로스마케터 분이 쓰신 건데 PM이랑 무슨 상관이지 라고 잠깐 생각했다가, 아 [목표 수립 - 문제 정의 - 가설 수립 및 검증] 이 프레임 워크가 결국 중요하다는 건가? 라고 깨달았다. 근데 이 부분 그래도 다시 튜터님께 여쭤봐야겠다. → 여쭤봄

그리고 같은 맥락에서, 기술 블로그 글들을 볼 때

문제 발견

문제 정의
가설 수립
액션
검증 결과

이 로직으로 글을 보면 좀 더 도움이 될 거라 하셨는데

내가 어제 여러 기술 블로그 글들로 인해 복잡해지고 헷갈린다고 느꼈고 이게 도움이 될 것 같다!

 

 

(근데 번외로 29cm글에서...) 관심 브랜드와 실시간 연결되는 푸시 로직을 설계하셨구나.
우리는 그 브랜드에 관심있을만한 사용자를 임의로 정하고(감도가 비슷한 브랜드 혹은 큰카테고리)를 코호트를 추출해서 일일이 연결해줬는데..! 암튼 정말 몇몇개를 제외하고는 그 수많은 개인화 푸시를 이렇게 실험으로 정리해두진 못 했지만,.... 그것도 PM 사고 흐름에 도움이 되었으려나 싶다...! 

---

 

푸시나 인앱메시지, 프로모션 페이지에서는 A/B테스트 많이 했지만.. 앱 화면 자체는 어떻게 A/B테스트 하는 건지 궁금해서 GPT한테 물어봤다. 아직 100% 이해는 못 함...

 

앱 화면(UI) A/B 테스트는 어떻게 하는가?

앱 화면을 A/B 테스트하려면 푸시 테스트처럼 단순히 메시지만 나누는 방식으로는 불가능합니다.
앱 내부에 A 화면과 B 화면을 모두 포함해 두고,
서버에서 특정 사용자에게 어떤 화면을 보여줄지 제어하는 방식을 사용합니다.
이걸 일반적으로 Feature Flag(실험 플래그) 방식이라고 합니다.

실험을 위해 배포가 필요한 이유

앱은 서버에서 어떤 지시를 내리더라도
단말에 B 화면 코드가 실제로 존재해야 B 화면을 그릴 수 있습니다.

따라서:

1. A 화면 + B 화면이 포함된 앱 버전을 개발
2. 이 버전을 앱스토어에 배포
3. 사용자가 업데이트하면 그때부터 서버가 화면 노출을 제어하여 A/B 테스트 가능

즉, A/B 테스트 시작 전 최소 1번은 앱 배포가 필요합니다.

“사용자가 업데이트 안 하면?”

업데이트하지 않은 사용자는 단말에 B 화면 코드가 없으므로
B 화면을 볼 수 없습니다.

그런 사용자는 A/B 테스트 후보군에서 자동 제외됩니다.

그래서 실제 서비스들은:

• 앱 업데이트율이 충분히 올라온 뒤 실험 시작
• 실험군 배정 시 “앱 버전 ≥ B 화면이 포함된 버전” 조건을 추가
  (업데이트한 사용자만 실험 참여 가능)

최종 요약

• 앱 화면 A/B 테스트는 서버가 UI 버전을 제어하는 구조로 진행한다.
• A/B 두 화면은 앱 안에 미리 포함되어 있어야 하므로 초기 배포는 필수다.
• 사용자가 업데이트하지 않으면 B 화면 실험 대상이 될 수 없다.
• 실제 서비스들은 업데이트율을 보고 적절한 시점에 실험을 시작한다.

---