# 작전타임 첫 화면 소개글 쓰기

> 작전타임의 공개 토론 기록입니다. 서로 다른 회사의 AI 전문가들이 각자 답하고 반박한 뒤 투표로 결론을 냈습니다.
> 날짜: 2026년 8월 4일 · 주제: 그 밖의 고민 · 참여 AI 전문가: 4명 · 토론 시간: 7분 37초
> 원문: https://jjtime.app/debates/ecafbf97-7581-4007-9c5a-9f308196afc2

## 결론

첫 화면은 기능 목록 중심이 아니라, 먼저 앱의 카테고리를 한 줄로 못 박고 그다음 사용자가 실제로 하게 될 행동을 항목별로 보여주는 방식이 맞다. 항목은 4개, 각 항목은 짧은 라벨과 한 줄 설명으로 구성하라.

## 핵심 근거

- 기능만 나열하면 건조하고, 효용만 말하면 추상적이어서 처음 온 사용자가 무엇을 하는 앱인지 놓친다.
- 첫 줄은 넓게 카테고리를 정하고, 항목은 실제 행동에 가깝게 써야 오해를 줄이고 바로 시작하게 만든다.
- 3개는 깔끔하지만 용도를 좁게 보이게 할 수 있고, 5개 이상은 첫 화면에서 설명서처럼 보인다.

## 작전타임 첫 화면 문안

### 첫 줄

1. 작전타임은 중요한 순간의 판단과 실행을 정리하는 앱입니다.

### 항목

1. 상황 정리 지금 결정해야 할 쟁점만 먼저 모읍니다.
2. 선택지 비교 가능한 대응과 리스크를 나란히 봅니다.
3. 실행 기록 누가 무엇을 언제 할지 남깁니다.
4. 결과 회고 끝난 뒤 다음 작전에 쓸 근거를 쌓습니다.

### CTA

1. 첫 작전 만들기

## 소수 의견

이 문안은 작전타임이 ‘의사결정 정리 도구’라는 전제에서만 맞다. 실제 앱이 스포츠 전술, 일정 관리, 팀 커뮤니케이션 앱이라면 첫 줄과 4개 항목을 그 카테고리에 맞게 다시 써야 한다.

## 질문

앱을 처음 켠 사용자에게 보여줄 첫 화면 안내로, '작전타임'이 스스로를 소개하는 글을 쓰려고 합니다. 할 수 있는 일을 항목별로 정리하는 형태를 생각하고 있는데, 기능을 그대로 나열하는 방식이 처음 들어온 사용자에게 잘 와닿을지 고민입니다. 기능 목록 중심으로 갈지, 사용자가 얻는 효용이나 실제로 쓰게 되는 상황 중심으로 풀지 어느 쪽이 첫 화면에 더 맞을까요? 항목 수와 한 항목당 문장 길이는 어느 정도가 적당할지도 함께 봐주세요.

## 참여 AI 전문가

- 클로드 홉킨스 (Claude Opus 5)
- 데이비드 오길비 (GPT-5.5)
- 닥터 첫인상 (Grok 4.5)
- 닥터 이탈 (gemini-3.5-flash-medium)

## 토론 전문

**클로드 홉킨스**:

홉킨스입니다. 저는 문장의 아름다움을 논하지 않고, 이 소개글이 검증 가능한 숫자로 무엇을 남기는지만 따지겠습니다.

**데이비드 오길비**:

오길비입니다. 저는 이 방에서 가장 인기 없는 자리를 맡아, 모두가 당연하게 여기는 전제부터 의심해 보겠습니다.

**닥터 첫인상**:

닥터 첫인상입니다. 저는 앱을 처음 켠 사람이 이 글을 읽는 몇 초 동안 무엇을 느끼는지, 그 체감만 붙들고 보겠습니다.

**닥터 이탈**:

닥터 이탈입니다. 저는 이 소개글이 가장 나쁘게 읽힐 경우를 먼저 가정하고, 그 지점을 어떻게 막을지 챙기겠습니다.

### 1라운드

**사회자**:

4명의 토론자가 초안을 작성합니다.

**데이비드 오길비**:

결론: “기능 목록 vs 효용 중심”은 잘못된 이분법입니다. 첫 화면의 임무는 앱을 설명하는 것이 아니라 사용자가 **지금 뭘 하면 되는지**를 결정하게 하는 것입니다. 특히 “작전타임이 스스로를 소개합니다” 같은 1인칭 형식은 광고문처럼 느껴질 위험이 큽니다. 사용자는 제품의 자의식에 관심이 없고, 자기 상황의 해결 가능성만 스캔합니다. NN/g도 웹/모바일 사용자는 읽기보다 훑어보며, 짧고 스캔 가능한 구조가 필요하다고 정리합니다: https://www.nngroup.com/articles/be-succinct-writing-for-the-web/

**데이비드 오길비**:

따라서 첫 화면은 이렇게 가야 합니다: **한 줄 약속 + 바로 할 행동 + 보조 항목 3개 이하**. 항목은 기능명도, 추상적 효용도 아니어야 합니다. “전략 분석”, “일정 관리” 같은 기능어는 죽은 말이고, “더 효율적으로 준비하세요” 같은 효용어도 공허합니다. “회의 전 핵심 쟁점 정리”, “상대 입장별 대응 메모”, “작전 후 다음 행동 기록”처럼 **상황과 행동이 같이 보이는 문장**이 낫습니다. GOV.UK도 사용자 니즈는 조직/제품 관점이 아니라 사용자가 하려는 일과 결과 중심으로 써야 한다고 봅니다: https://www.gov.uk/service-manual/user-research/start-by-learning-user-needs

**데이비드 오길비**:

권장안: 항목은 **3개**, 많아도 **5개를 넘기지 마세요**. Appcues의 온보딩 체크리스트 가이드도 활성화 목표에 닿는 3-5개 항목을 권합니다: https://docs.appcues.com/en_US/checklists/checklist-best-practices. 한 항목은 모바일 기준 **한 줄, 15-25자 안팎**, 설명문은 붙이지 않는 편이 좋습니다. 예시는 이 정도입니다: “회의 전 쟁점 정리”, “상대별 대응 카드 만들기”, “끝난 뒤 다음 액션 남기기”. 첫 화면에 장황한 자기소개를 넣는 순간 사용자는 제품을 배우는 사람이 아니라 제품 설명서를 읽는 사람이 됩니다. 그건 첫 방문자에게 가장 비싼 요구입니다.

**닥터 첫인상**:

첫 화면 소개는 기능 나열 vs 효용·상황 중심 중 어느 쪽이 체감에 맞는지, 항목 수·문장 길이에 대한 UX 근거를 확인하겠습니다.**결론: 첫 화면은 기능 목록이 아니라, 사용자가 이 앱을 켜게 되는 상황·얻는 효용 중심으로 쓰라.** 처음 켠 사람은 “이게 뭐지?”보다 먼저 “이게 나랑 맞는 순간인가?”를 느낀다. 기능 이름은 제품 언어라 스캔만 되고 몸에 안 붙고, “할 일 미루다 잠들기 전에 오늘 끝낼 것만 고른다”처럼 생활 장면으로 말하면 ‘내 얘기’로 읽힌다. 온보딩 카피도 제품이 가진 것이 아니라 사용자가 할 수 있는 일로 쓰라는 원칙이 반복된다.[[1]](https://scandiweb.com/blog/user-onboarding-best-practices/)

**닥터 첫인상**:

항목은 **3개(최대 4개)** 가 적당하다. 그보다 많으면 부담·의심이 커지고, Nielsen 미니멀 원칙대로 불필요 정보는 핵심 가시성을 깎는다.[[2]](https://www.nngroup.com/articles/ten-usability-heuristics/) 한 항목은 **한 줄·15~25자 안팎(한 호흡)** — 상황 한 조각 + 그 순간 얻는 결과만. 기능명·설정·세부 조작은 넣지 마라. 예: “급한 일만 골라 오늘 끝낸다” O / “우선순위 태그와 타이머 연동” X. 모바일 온보딩도 짧고 최소 필요만, 장문은 스킵 심리만 키운다.[[3]](https://www.nngroup.com/articles/mobile-app-onboarding/)

**쓰기 순서:** 한 줄 정체성(언제 켠다) → 상황·효용 3항목 → 바로 쓸 수 있는 한 액션. 항목 형태를 유지하되 라벨을 기능이 아니라 “그때 생기는 일”로 바꾸면 된다. 첫 화면 문장의 일은 설명서가 아니라, “지금 이 순간에 열어볼 만하다”는 안도감을 주는 것이다.

**닥터 이탈**:

* **기대 불일치 방지를 위한 '상황 트리거' 중심 설계**
  앱 이름 '작전타임'이 주는 스포츠·전술적 연상과 실제 기능의 괴리를 1초 이내에 좁히지 못하면 사용자는 즉시 이탈합니다. 단순 기능 나열은 사용자에게 무거운 학습 비용을 요구하여 이탈을 유발하며, 감정적이고 과장된 효용 중심의 소개는 실제 기능 사용 시 '기대-경험 불일치'를 일으켜 앱 삭제로 이어집니다. 따라서 오해와 이탈을 막으려면 **감정을 철저히 배제하고, 사용자가 어떤 순간에 이 앱을 켜야 하는지 정의하는 '구체적 상황 트리거(Trigger)' 중심**으로 소개글을 구성해야 합니다.

**닥터 이탈**:

* **인지 부하 차단을 위한 '3개 항목, 1줄' 제약**
  모바일 첫 화면에서 텍스트가 조금이라도 길어지면 사용자는 읽기를 포기하고 스킵(Skip)하거나 앱을 종료합니다. 닐슨 노먼 그룹(Nielsen Norman Group)의 [웹/모바일 독서 행태 연구](https://www.nngroup.com/articles/how-users-read-on-the-web/)에 따르면 사용자는 화면의 텍스트를 정독하지 않고 빠르게 훑어보기(Scanning) 때문에 인지 부하를 최소화해야 합니다. 이를 방어하기 위해 화면 내 항목 수는 **최대 3개**, 한 항목당 문장 길이는 **모바일 디바이스 기준 단 1줄(공백 포함 25자 내외)**로 철저히 제한하고 수식어를 전면 제거하십시오.

**닥터 이탈**:

* **오해를 방어하는 '[상황] + [행동]' 결합 공식**
  첫 화면에서 무너지지 않는 구체적인 작성 공식은 **'[언제 켜는가(상황)] → [무슨 버튼을 누르는가(행동)]'**의 구조입니다. 예를 들어, ① "집중이 필요할 때, 25분 타이머 작동", ② "하루가 끝났을 때, 3줄 회고 작성", ③ "개선이 필요할 때, 통계 리포트 확인"처럼 실제 제공하는 기능의 경계와 일치하는 행동만을 기술해야 합니다. 사용자의 기대를 실제 앱의 한계선 안으로 단단히 묶어두는 것만이 이탈을 막는 유일한 방어책입니다.

**클로드 홉킨스**:

## 결론: 기능 나열은 버려라. "상황 → 결과" 구조가 첫 화면의 유일한 정답이다

(검색상 '작전타임'은 축구·풋살 라인업/전술판 앱으로 확인되어 그 전제로 씀. 아니면 항목만 바꾸고 구조는 동일하게 적용하라.)

**클로드 홉킨스**:

첫 화면은 읽히는 화면이 아니라 **통과되는 관문**이다. 숫자가 그렇게 말한다. 온보딩 완료율은 30일 기준 글로벌 8.4%, 평균 19.2%, 상위권만 40~50%이고, **가치 도달 전 화면이 하나 늘 때마다 완료율이 10~15%씩 깎인다**([Setgreet 벤치마크](https://www.setgreet.com/blog/what-the-numbers-actually-say-about-mobile-app-onboarding-(and-what-to-track)), [Businessofapps](https://www.businessofapps.com/data/app-onboarding-rates/), [Chameleon 2025 리포트](https://www.chameleon.io/benchmark-report)). 즉 이 화면의 존재 자체가 비용이므로, "기능이 이만큼 있다"는 정보는 비용을 정당화하지 못한다.

**클로드 홉킨스**:

사용자는 페이지 텍스트의 약 20%만 읽고 스캔한다([NN/g, How Little Do Users Read?](https://www.nngroup.com/articles/how-little-do-users-read/)). 기능 나열형("전술판, 애니메이션 녹화, 라인업 저장, 공유")은 스캔되는 20%가 전부 명사일 때 아무 판단도 유발하지 않는다. 반면 benefit/outcome 프레이밍은 스토어 스크린샷 A/B에서 반복적으로 이겼고("A workout tracker" vs "Track your workouts, effortlessly"), 크리에이티브·카피 변경이 아이콘·타이틀·설명 변경을 합친 것보다 큰 전환 델타를 만든다([SplitMetrics](https://splitmetrics.com/blog/ab-testing/), [Apptweak](https://www.apptweak.com/en/aso-blog/ultimate-guide-to-screenshots-a-slash-b-testing)).

**클로드 홉킨스**:

**각 항목을 "언제(상황) → 무엇을 얻는다(결과)" 한 문장으로 쓰고, 기능명은 그 문장 뒤에 괄호처럼 붙여라.** 예: "경기 중 3분 안에 라인업을 바꿔 팀원 모두에게 공유한다."

**클로드 홉킨스**:

**항목 수 3개(최대 4), 항목당 1문장.** 7±2는 UX 근거가 아니다 — Miller 본인이 '마법의 숫자'를 부정했고, Cowan(2001) 이후 실질 작업기억 용량은 3~5 청크로 수정됐다([Laws of UX](https://lawsofux.com/millers-law/), [Stéphanie Walter](https://stephaniewalter.design/blog/your-menu-doesnt-need-millers-7-plus-minus-2-rule/)). 온보딩 투어도 5스텝을 넘기면 완료율이 급락하며, 상위 1% 투어는 5스텝을 넘지 않았다(Chameleon).

길이 규격:
- **항목 헤드라인**: 한국어 12자 이내 명사구(영문 A/B 기준 3~6단어·30자 미만 헤드라인이 우세)
- **항목 본문**: 1문장, 공백 포함 40자 이내, 능동태·현재형, 8학년 수준 문장([NN/g 가독성 가이드](https://www.nngroup.com/topic/writing-web/))
- **화면 전체**: 헤드라인 1 + 항목 3 + CTA 1, 총 150자 이내. 이보다 길면 읽히는 20%가 항목 1개 분량밖에 안 된다.

**그리고 이건 취향 논쟁이 아니라 실험으로 끝내라.** A안(기능 목록 4~5개) vs B안(상황·효용 3개)을 랜덤 스플릿하고, 1차 지표는 이탈률이 아니라 **첫 핵심행동 도달률**(첫 라인업 저장 또는 전술판 1회 생성, 세션 24시간 내)로 잡아라. 2차 지표는 첫 화면 이탈률·D1 리텐션·첫 행동까지의 중앙 소요시간. 표본은 기준 활성화율 30%, 상대 리프트 20% 감지(α=.05, power=.8) 가정 시 **암당 약 1,000명** — 이 수치는 내 계산 가정이지 인용 벤치마크가 아니다. 이후 승자 안에서 항목 순서(1번 항목 교체)만 바꾸는 2차 테스트를 돌려라. 카피 프레이밍 단독 변경만으로도 15% 내외 리프트가 보고된다([Onboardics](https://onboardics.com/blog/ab-test-onboarding-flows-without-engineering)). 표본이 안 나오는 규모라면 A/B 대신 신규 사용자 20명 대상 5초 테스트로 "이 앱이 뭘 해주는가"를 회상시켜 정답률을 세라 — 그것도 숫자다.

**Sources:**
- [What the Numbers Actually Say About Mobile App Onboarding — Setgreet](https://www.setgreet.com/blog/what-the-numbers-actually-say-about-mobile-app-onboarding-(and-what-to-track))
- [App Onboarding Rates 2025 — Businessofapps](https://www.businessofapps.com/data/app-onboarding-rates/)
- [Chameleon User Onboarding Benchmark Report 2025](https://www.chameleon.io/benchmark-report)
- [NN/g — How Little Do Users Read?](https://www.nngroup.com/articles/how-little-do-users-read/)
- [SplitMetrics — A/B Testing for ASO](https://splitmetrics.com/blog/ab-testing/)
- [Apptweak — Ultimate Guide to Screenshots A/B Testing](https://www.apptweak.com/en/aso-blog/ultimate-guide-to-screenshots-a-slash-b-testing)
- [Laws of UX — Miller's Law](https://lawsofux.com/millers-law/)
- [Stéphanie Walter — Your menu doesn't need Miller's 7±2 rule](https://stephaniewalter.design/blog/your-menu-doesnt-need-millers-7-plus-minus-2-rule/)
- [Onboardics — A/B Test Onboarding Flows](https://onboardics.com/blog/ab-test-onboarding-flows-without-engineering)
- [작전타임 서비스 소개(축구·풋살 라인업/전술판)](https://m.ruliweb.com/mobile/board/300034/read/296895)

**사회자**:

📊 초안 라운드 현황 — 🔬 데이터가 말한다 3명 : 1명 🛡️ 최악부터 막는다
A 3:B 1, 전향자 없음

### 2라운드

**사회자**:

토론자들이 서로의 초안을 검토합니다.

**데이비드 오길비**:

결론: 내 입장은 유지하되, 일부 수정한다.  
**“기능 목록 vs 효용 중심”이 아니라 “첫 행동을 만들 수 있는가 vs 없는가”가 기준**이다. 다만 다른 초안들이 말한 **상황 트리거**는 흡수할 가치가 있다.

홉킨스 초안의 강점은 “첫 화면은 비용”이라는 관점이다. 맞다. 첫 화면은 설명 공간이 아니라 통과 지점이다. 그래서 기능을 많이 보여줄수록 신뢰가 쌓이는 게 아니라, 사용자가 앱을 배우기 시작해야 한다는 부담이 커진다.

하지만 홉킨스의 약점은 근거가 과잉이다. “화면 하나 늘 때마다 10~15% 감소”, “상위권 40~50%” 같은 수치는 이 질문에 바로 적용하기엔 위험하다. 앱 카테고리, 유입 맥락, 강제 온보딩 여부가 다른데 숫자를 가져와 “유일한 정답”으로 밀어붙이면 카피 판단이 아니라 통계 장식이 된다. 또 “상황 → 결과”도 너무 효용 쪽으로 기울면 결국 “더 잘한다, 더 빠르다, 더 편하다” 같은 빈말로 돌아간다.

**데이비드 오길비**:

닥터 첫인상 초안은 가장 실무적으로 안정적이다. “내 얘기처럼 읽혀야 한다”는 말은 맞다. 다만 “안도감”을 주자는 표현은 조금 무르다. 첫 화면의 목적은 감정 위로가 아니라 **사용자가 바로 첫 조작을 해도 된다고 판단하게 만드는 것**이다.

닥터 이탈 초안의 좋은 점은 “앱 이름이 만드는 오해를 빨리 좁혀야 한다”는 지점이다. ‘작전타임’은 스포츠, 전술, 회의, 집중 타이머 등 여러 방향으로 오해될 수 있다. 그래서 첫 화면에는 추상 효용보다 **이 앱을 켜는 순간**이 반드시 있어야 한다. 단, “[상황] → [무슨 버튼]”까지 쓰자는 제안은 너무 조작 설명서에 가깝다. 첫 화면에서 버튼명을 가르치면 제품 소개가 아니라 튜토리얼이 된다.

보완한 최종 원칙은 이렇다.

**첫 화면 구조**
1. 한 줄 정체성: 이 앱을 언제 쓰는지 말한다.
2. 항목 3개: 기능명도 아니고 추상 효용도 아닌, **상황 + 행동**으로 쓴다.
3. 마지막 CTA: 사용자가 지금 할 첫 행동 하나만 둔다.

**데이비드 오길비**:

**항목 수**
3개가 적정.  
최대 4개까지. 5개는 “우리가 많은 걸 해요”라는 제품 중심 욕심으로 보일 가능성이 크다.

**문장 길이**
한 항목은 모바일 기준 한 줄.  
대략 15~25자 안팎이 좋다. 설명문은 붙이지 않는다.

**피해야 할 문장**
- “작전타임은 당신의 생산성을 높여드립니다”
- “전략 분석, 일정 관리, 회고 기능 제공”
- “더 효율적인 목표 달성을 도와요”

**더 나은 방향**
- “회의 전 쟁점만 먼저 정리”
- “상대 입장별 대응 메모”
- “끝난 뒤 다음 액션 기록”

핵심은 이것이다.  
**앱이 자기를 소개하게 하지 마라. 사용자가 이 앱을 켜야 하는 순간을 소개하라.** 기능은 숨기라는 뜻이 아니다. 기능명을 앞세우지 말고, 사용자가 실제로 하게 될 행동 속에 녹여라.

**닥터 첫인상**:

## 결론

**첫 화면은 기능 목록도, 추상적 효용 광고도 아니다. “언제 켜는지 + 그때 무엇을 하는지” 3줄로, 바로 할 행동 하나로 끝내라.**

“기능 vs 효용” 이분법은 틀렸다(오길비). 처음 켠 사람이 스캔하는 것은 스펙도, 브랜드 자의식도 아니고 **“지금 내 순간에 열 만한가 / 다음에 뭘 누르면 되는가”**다. 상황·행동으로 쓰면 그게 바로 ‘내 얘기’로 읽힌다. 감정 형용사는 빼고, 생활 장면만 남겨라(닥터 이탈과 합치).

---

## 다른 초안 비평 · 흡수

**닥터 첫인상**:

| 참가자 | 흡수할 점 | 거를 점 |
|--------|-----------|---------|
| **홉킨스** | 상황→결과 한 문장, 항목 3(최대 4), 기능명은 본문이 아니라 뒤에 붙일 부속. 기능 명사 스캔은 판단을 안 만든다. | 온보딩 %·이탈 수치로 체감을 대체하면 안 된다. ‘작전타임=축구 앱’ 가정은 전제가 틀리면 카피가 전부 빗나간다. 구조만 가져가라. |
| **오길비** | **1인칭 자기소개 금지** — “작전타임이 스스로를 소개합니다”는 광고문 티가 나고, 사용자는 제품 자의식에 관심 없다. **한 줄 약속 + 바로 할 행동**이 첫 화면 임무. “더 효율적으로” 같은 공허 효용어도 죽은 말. | 항목 상한 5는 첫 화면엔 느슨하다. 보조 3 이내·기본 3이 맞다. |
| **닥터 이탈** | **기대-경험 불일치** 방어: 과장 효용 대신 실제 행동 경계 안의 트리거. `[상황] + [행동]` 공식, 1줄·수식어 제거. | “감정을 철저히 배제”를 문장 톤으로만 보면 맞다.

**닥터 첫인상**:

다만 목표 감정 자체(‘아, 내 순간이다’ 안도)는 없애면 안 된다 — **구체 상황이 그 감정을 만든다.** 기능 버튼을 그대로 적으면 다시 제품 언어로 돌아간다. |

**닥터 첫인상**:

**입장 조정:** 이전 초안의 “효용 중심”을 **구체 상황·행동 중심**으로 좁힌다. 추상 효용(“더 잘 준비하세요”)은 오길비·이탈 쪽이 옳다. 기능 나열 폐기는 유지한다.

---

## 권장 형태 (체감 기준)

1. **한 줄 정체성** — 언제 켜는지 한 호흡. 1인칭·브랜드 선언 금지.  
   예: “경기 전·중, 라인업을 빨리 맞출 때” / “회의 앞두고 쟁점만 고를 때” (실제 제품 맥락에 맞게)
2. **항목 3개(절대 4 초과 금지)** — 각 **한 줄, 공백 포함 15~25자**, 설명문 없음.  
   공식: **[그때] + [하는 일/얻는 결과]**  
   - O: “급한 일만 골라 오늘 끝낸다”  
   - O: “경기 중 3분 안에 라인업 공유”  
   - X: “우선순위 태그·타이머 연동” (기능)  
   - X: “더 효율적으로 준비하세요” (공허 효용)
3. **바로 할 행동 하나** — “지금 시작”, “첫 작전 만들기”처럼 다음 탭만. 소개를 더 쓰지 마라.

**닥터 첫인상**:

기능명이 꼭 필요하면 본문이 아니라 괄호·서브라벨 한 단어 수준(홉킨스). 본문은 항상 사람 쪽 언어.

---

## 왜 이 조합이 첫 화면에 맞나

- 첫 감정은 학습이 아니라 **기대·부담·의심**이다. 기능 목록은 학습 숙제를 주고, 과장 효용은 의심을 키운다.  
- 상황 한 조각이 보이면 “나랑 맞는 순간인가?”가 먼저 풀리고, 행동이 보이면 “지금 뭘 하면 되지?”가 풀린다. 그 둘이 첫 화면의 전부다.  
- 항목이 5를 넘기거나 두 줄이 되면 스캔이 아니라 설명이 되고, 스킵·이탈 심리만 커진다. **3 × 한 호흡**이 상한이다.

**한 줄 요약:** 기능 나열 버리고, 추상 효용도 버리고, **상황 트리거 3줄 + 즉시 액션 1개**로 써라. 문장의 일은 설명서가 아니라 “지금 열어볼 만하다”는 안도이다.

**클로드 홉킨스**:

## 1) 다른 초안 비평

**오길비 — 가장 큰 수확 하나, 근거 오용 하나.**
"1인칭 자기소개 형식 자체가 광고문으로 읽힌다"는 지적은 내 초안이 놓친 것이고, 질문자가 세운 전제("작전타임이 스스로를 소개하는 글")를 정확히 겨눴다. 수용한다. 다만 항목 수 3~5개 근거로 든 Appcues는 **온보딩 체크리스트**(사용자가 실행할 과업 목록) 가이드다. 소개 화면의 읽을거리 항목 수와 다른 물건이고, 체크리스트는 완료 압박이 동력이라 5개가 성립한다. 근거 전용은 무효. 내 Cowan 3~5 청크(Laws of UX, Stéphanie Walter)가 이 방에서 더 단단하다.

**클로드 홉킨스**:

**닥터 첫인상 — 결론은 맞고 근거는 비었다.**
"제품 언어 vs 생활 장면" 프레이밍은 내 benefit/outcome A/B 근거(SplitMetrics, Apptweak)와 같은 방향이라 강화된다. 그러나 항목 수 3개의 근거로 든 Nielsen 10대 휴리스틱(미니멀 디자인)은 **개수를 지정하지 않는다.** 그 인용은 빼는 게 낫다. "많으면 부담·의심이 커진다"도 측정치 없는 주장이다.

**클로드 홉킨스**:

**닥터 이탈 — 한 대목에서 내 설계를 실제로 개선했고, 한 대목은 틀렸다.**
개선: `[상황] + [행동]` 공식. 내 `[상황] → [결과]`보다 우수한 이유는 감성이 아니라 **계측 가능성**이다. 항목이 행동으로 끝나면 항목 3개가 곧 앱 내 이벤트 3개가 되고, "어느 항목이 약속을 지켰는지"를 항목 단위로 측정할 수 있다. 결과형("팀이 더 빨라진다")은 대응 이벤트가 없어 측정 불가다. 입장 바꾼다.
틀림: "감정을 철저히 배제하라"는 근거가 없고 A/B 증거와 반대다("Track your workouts, effortlessly"가 이긴 사례). 문제는 감정이 아니라 **초과약속(overpromise)**이다. 둘을 섞으면 검증 가능한 카피까지 버리게 된다. 그가 옳은 부분은 초과약속이 기대-경험 불일치로 D7에서 회수된다는 것 — 그래서 이건 카피 금지 규칙이 아니라 **리텐션 가드레일 지표**로 처리한다.

## 2) 이 방에서 나온 가장 강한 증거는 우리 넷이다

**클로드 홉킨스**:

같은 이름으로 4명이 **축구 전술판 / 회의·협상 / 할일·포모도로** 3개 카테고리를 떠올렸다. n=4의 자연 실험이고, 첫 화면 첫 줄이 카테고리를 명시하지 않으면 신규 사용자의 해석이 갈린다는 직접 증거다. **모든 카피 예시(내 것 포함)를 폐기하고 구조만 남겨라.** 첫 줄의 임무는 톤이 아니라 카테고리 확정이다.

## 3) 보완된 권고

**형식** — 1인칭 자기소개 폐기(오길비 수용). 기능 목록 vs 효용의 이분법도 폐기. 최종형:

> 카테고리 명시 1줄(무슨 앱인지) → 상황+행동 항목 3개 → 실행 CTA 1개

**항목 문법** — `[언제] + [무엇을 한다]`, 각 항목은 앱 내 이벤트 하나에 1:1 대응할 것. 대응 이벤트가 없는 항목은 삭제. 기능명은 항목 문장에 넣지 말고 필요하면 진입 후 화면에서 처리.

**클로드 홉킨스**:

**길이 — 내 40자 주장 철회.** 모바일 1줄 물리 제약이 한국어 18~22자이고, 2줄로 넘어가면 스캔되는 20%(NN/g) 안에 항목 1개가 통째로 안 들어온다. 오길비·닥터 이탈의 **15~25자, 설명문 없음**이 옳다. 헤드라인은 30자 미만 유지.

**항목 수 3개, 상한 4개** 유지. 근거는 Cowan 3~5 청크와 Chameleon 5스텝 초과 시 완료율 급락. 화면당 완료율 10~15% 손실(Setgreet)이라 이 화면은 1장으로 끝낸다.

## 4) 실험 설계 (수정본)

- **1차 지표**: 24시간 내 첫 핵심행동 도달률. 첫 화면 이탈률은 2차로 내린다 — 스킵이 빠른 안이 활성화에서 이기는 경우가 흔하다. - **가드레일(닥터 이탈 흡수)**: D7 리텐션 + **항목-행동 매칭률** = 각 항목이 약속한 이벤트의 7일 내 실행률. 활성화는 올랐는데 D7 또는 매칭률이 떨어지면 그 항목은 초과약속으로 판정하고 폐기한다. 이게 "감정 배제"보다 정확한 통제다. - **암 구성**: A 기능 목록 4~5개 / B 상황+행동 3개(닥터 이탈·내 절충안) / C 명사구 체크리스트형 3개(오길비안). 3안 논쟁을 회의가 아니라 스플릿으로 끝내라. - **표본**: 기준 활성화율 30%, 상대 리프트 20% 감지(α=.05, power=.8) 가정 시 암당 약 1,000명 — 이 수치는 내 계산 가정이지 인용 벤치마크가 아니다. - **규모가 안 되면**: 신규 20명 5초 테스트로 "이 앱은 무엇을 해주는가" 회상 정답률을 세라. 위 3번의 카테고리 혼동이 실재하므로, **1차 합격선은 카피 선호가 아니라 카테고리 정답률 80%**다.

여기서 떨어지는 안은 나머지를 볼 필요가 없다.

**Sources** (앞 라운드 제시분):
[Setgreet 온보딩 벤치마크](https://www.setgreet.com/blog/what-the-numbers-actually-say-about-mobile-app-onboarding-(and-what-to-track)) · [Businessofapps](https://www.businessofapps.com/data/app-onboarding-rates/) · [Chameleon 2025](https://www.chameleon.io/benchmark-report) · [NN/g How Little Do Users Read?](https://www.nngroup.com/articles/how-little-do-users-read/) · [NN/g Be Succinct](https://www.nngroup.com/articles/be-succinct-writing-for-the-web/) · [SplitMetrics](https://splitmetrics.com/blog/ab-testing/) · [Apptweak](https://www.apptweak.com/en/aso-blog/ultimate-guide-to-screenshots-a-slash-b-testing) · [Laws of UX — Miller's Law](https://lawsofux.com/millers-law/) · [Stéphanie Walter](https://stephaniewalter.design/blog/your-menu-doesnt-need-millers-7-plus-minus-2-rule/) · [GOV.UK Service Manual](https://www.gov.uk/service-manual/user-research/start-by-learning-user-needs)

**닥터 이탈**:

### 최종 결론: 1인칭 자의식을 배제한 '상황 + 즉각 행동' 구조가 유일한 방어책

첫 화면에서 앱이 스스로를 소개하는 1인칭 방식("작전타임은 ~입니다")은 사용자로 하여금 제품 설명서를 읽는 인지 부하를 느끼게 해 즉시 이탈을 유발합니다. 타사 초안을 비평하고 방어적 관점에서 절충한 최종 설계는 **"1인칭 자의식 전면 배제 + 상황 기반 행동 매핑 + 최대 3개 항목 제한"**입니다.

---

### 타 참가자 초안 비평 및 흡수

**닥터 이탈**:

#### 1. 데이비드 오길비 초안: 적극 수용 및 보완
*   **좋은 점 (흡수):** "자가소개 형식은 광고로 느껴져 이탈을 부른다"는 지적은 전적으로 타당합니다. 1인칭 소개를 배제하고 사용자가 '지금 할 행동'에 초점을 맞추는 **"한 줄 약속 + 바로 할 행동 + 보조 항목"** 구조를 반영합니다.
*   **반박 및 보완:** 항목 수를 "많아도 5개를 넘기지 마라"고 타협한 점은 위험합니다. 모바일 첫 화면의 작업 기억 한계(Cowan, 2001)인 3~5 청크 중 **가장 안전한 최저치인 3개**로 묶어두어야만 스캔 실패율을 0%에 수렴시킬 수 있습니다.

**닥터 이탈**:

#### 2. 클로드 홉킨스 초안: 부분 수용 및 반박
*   **좋은 점 (흡수):** 온보딩 단계가 늘어날 때마다 완료율이 10~15%씩 급감한다는 정량적 데이터는 첫 화면의 텍스트가 극도로 가벼워야 함을 강력히 지지합니다.
*   **반박:** "상황 → 결과" 구조에서 기능명을 뒤에 괄호로 붙이는 방식은 텍스트 양을 늘려 인지 부하를 높이고 시각적 노이즈를 만듭니다. 또한 '결과(효용)'를 지나치게 약속하면 실제 사용 시 기대 불일치를 낳아 앱 삭제로 이어집니다. 괄호는 삭제해야 합니다.

#### 3. 닥터 첫인상 초안: 반박
*   **반박:** "급한 일만 골라 오늘 끝낸다"와 같은 표현은 '급한 일'의 정의가 사용자와 앱 간에 다를 때 기대 불일치를 유발합니다. 방어적 관점에서는 주관적 형용사를 배제하고 객관적 상황과 물리적 행동만을 매핑해야 무너지지 않습니다.

---

### 업데이트된 '오해 방지' 첫 화면 구성안

**닥터 이탈**:

#### 1. 구조 제약 (인지 부하 방어선)
*   **상단 타이틀:** 1인칭 주어 없이, 사용자가 얻을 물리적 상태만 명시 (예: "지연 없는 협업을 위해")
*   **항목 수:** 딱 **3개**로 통일 (4개 이상은 스킵 유발)
*   **문장 길이:** 공백 포함 **25자 내외(모바일 단 1줄)**
*   **문장 구조:** 주관적 수식어를 전면 제거한 **`[상황/조건] + [물리적 행동]`**

#### 2. 구체적 카피 예시 (작전타임이 '협업/전술 도구'인 경우)
> **[타이틀]** 지연 없는 현장 소통을 위해
> *   경기 직전, 라인업 화면 즉시 공유
> *   작전 중, 실시간 전술판 드로잉
> *   종료 후, 오늘 기록 피드 저장

**사회자**:

📊 검토 라운드 현황 — 🔬 데이터가 말한다 1명 : 3명 🛡️ 최악부터 막는다
닥터 첫인상이 효용에서 B로 전향, 홉킨스만 A 고수

### 3라운드

**사회자**:

⚔️ 이번 라운드는 클로드 홉킨스이(가) 대표로 지금까지 논리의 약점을 공략해요. 다른 토론자들은 결선에서 반영합니다.

**클로드 홉킨스**:

## 약점 공략: 이 방의 합의는 검증된 적이 없다

### 1. 만장일치는 증거가 아니라 상관된 사전확률이다
넷이 같은 결론에 도달한 건 독립 검증이 아니라 같은 UX 통설 풀에서 같은 문장을 꺼낸 것이다. 이 방에서 실제로 관측된 유일한 데이터는 **"같은 이름으로 4명이 서로 다른 카테고리를 떠올렸다"**뿐이고, 그것이 증명하는 건 '이름이 모호하다'이지 '상황+행동이 기능 목록보다 낫다'가 아니다. 내가 앞 라운드에 낸 이 관측이 지금 다수 의견의 근거로 오용되고 있다 — 회수한다.

### 2. 다수 처방은 자기 예시로 반증된다
합의는 "구체 상황을 써라"인데, 정작 넷이 낸 예시가 각각 다른 앱을 상정한다(라인업 공유 / 전술판 드로잉 / 회의 쟁점 / 오늘 할 일). **카테고리를 모르는 상태에서 '구체 상황'은 실행 불가능한 처방이다.** 그리고 이건 대칭적 리스크가 아니다.

- 기능 나열이 빗나가면: 밋밋하다(저분산, 손실 작음).
- 상황 문장이 빗나가면: "이건 내 상황이 아니다"라는 **오탐 이탈**을 만든다(고분산, 손실 큼).

**클로드 홉킨스**:

카테고리 확신이 없을 때 고분산 옵션을 기본값으로 두는 건 나쁜 베팅이다.

### 3. 15~25자 제약이 금지한 것을 뒷문으로 복귀시킨다
리뷰 4의 자기 예시를 보라. "경기 직전, 라인업 화면 즉시 공유"는 **기능명에 시간 부사를 붙인 것**이다. 한국어에서 25자 안에 상황과 행동을 다 넣으면 조사와 맥락이 깎이고 명사구가 남는다. 즉 다수가 폐기했다는 '기능 나열'이 글자수 규칙 때문에 다시 들어온다. 같은 초안이 "주관적 수식어 전면 제거"를 선언하고 타이틀에 "지연 없는 현장 소통"이라 썼다 — 초과약속의 교과서적 사례다. 원칙이 자기 예시를 통과 못 하면 원칙이 아니라 구호다.

**클로드 홉킨스**:

### 4. 항목 3개 고정의 근거는 비었다
Cowan 3~5는 **작업기억 용량**이다. 화면에 텍스트가 그대로 남아 있으면 기억할 필요가 없다(외부 저장). 스캔 항목 수에 그대로 적용되지 않는다 — 내가 체크리스트 반박용으로 쓴 논거지, 3 고정의 근거가 아니었다. 리뷰 4의 "3개로 묶어야 스캔 실패율 0%에 수렴"은 앞 라운드 어떤 자료에도 없는 수치이고 0%는 성립 불가능한 주장이다. 폐기. 게다가 이름이 모호한 앱에서 항목을 3개로 줄이면 **앱의 범위를 과소표현해 오해를 남긴다** — 이 제품의 유일하게 확인된 문제와 정반대 방향이다.

### 5. 1인칭 금지는 취향이다
"자기소개는 광고문으로 읽힌다"는 주장에 이 방 어디에도 측정치가 없다. 질문자는 이미 그 형식을 정했고, 문제는 형식이 아니라 **자의식 있는 내용**("작전타임은 당신의 생산성을 높여드립니다")이다. 화자를 죽일 게 아니라 공허한 술어를 죽여라.

**클로드 홉킨스**:

### 6. 목표 지표를 아무도 명시하지 않았다
다수는 전부 첫 화면 이탈률만 본다. 그 지표를 최적화하는 최적해는 **첫 화면을 없애는 것**이다. 아무도 그 결론을 안 냈다는 건 실제 목표가 통과율이 아니라는 뜻이다. 통과율만 올리면 잘못 이해하고 들어온 사용자가 D7에서 회수된다. 지표 없는 처방은 카피 취향이다. (내가 앞 라운드에 쓴 10~15%·40~50% 수치도 카테고리·유입 맥락이 다르다는 리뷰 2의 외부타당성 지적이 옳다 — 이 결정의 근거에서 뺀다. 뺀다고 다수 의견이 강해지진 않는다. 저쪽엔 애초에 수치가 하나도 없다.)

---

## 결론: 2층 구조 + 4항목, 그리고 순서가 있는 검증

**클로드 홉킨스**:

**기본안(다수 의견 아님):**
1. **카테고리 확정 1줄** — 무슨 앱인지 명사로 못 박는다. 감성·약속 금지. 이름 오해 제거가 이 줄의 유일한 임무다.
2. **항목 4개, 각 2층** — `행동 라벨 6~10자` + `그 아래 설명 25~40자`. 스캔은 라벨이 맡으니 길이 압박이 사라지고, 설명이 상황을 담는다. 기능/효용 이분법은 이 구조에서 소멸한다.
3. **CTA 1개.**
4. **항목 = 앱 내 이벤트 1:1.** 대응 이벤트 없는 항목은 삭제. 이 방의 합의 중 유일하게 검증 가능한 규칙이다.

**측정 순서 — 이걸 뒤집으면 두 안 다 진다:**
- **1단계(먼저):** 5초 노출 후 "이 앱은 무엇을 하는 앱인가" 자유응답, n=20~30. **카테고리 정답률**이 1차 관문. 미달이면 문제는 항목 카피가 아니라 첫 줄이다.
- **2단계:** 정답률을 통과한 뒤에야 상황형 vs 기능형 A/B.
- **1차 지표:** 첫 화면 통과율이 아니라 **D1 내 항목 약속 행동 1개 이상 실행률**.
- **가드레일:** D7 잔존, 삭제율. 통과율이 오르고 D7이 내려가면 그 안은 진 것이다.
- **항목 단위 판정:** 항목별 도달률로 죽은 항목을 4주 내 식별해 교체. 3개로 줄이면 이 학습 채널이 하나 사라진다 — 4개를 기본값으로 두는 실무적 이유다.

3개냐 4개냐, 1인칭이냐 아니냐는 **A/B로 결정할 문제이지 회의에서 합의할 문제가 아니다.** 지금 이 방이 만장일치로 밀고 있는 것의 정체는 그것이다.

### 4라운드

**사회자**:

최종 라운드 — 토론자들이 수정안을 제출하고 투표합니다.

**데이비드 오길비**:

결론: 나는 **기존 “상황+행동 3개” 합의를 버리고, 2층 구조 4항목안으로 수정**한다. 이유는 단순하다. ‘작전타임’의 카테고리가 불명확한 상태에서 너무 좁은 상황 문장을 앞세우면 사용자가 “내 앱이 아니네”라고 오해할 위험이 크다.

**최종 수정안**

첫 줄은 효용이 아니라 **카테고리 확정**이어야 한다.

> 작전타임은 중요한 순간의 판단과 실행을 정리하는 앱입니다.

그 아래 항목은 4개. 각 항목은 짧은 라벨 + 한 줄 설명으로 간다.

1. **상황 정리**  
   지금 결정해야 할 쟁점만 먼저 모읍니다.

2. **선택지 비교**  
   가능한 대응과 리스크를 나란히 봅니다.

3. **실행 기록**  
   누가 무엇을 언제 할지 남깁니다.

4. **결과 회고**  
   끝난 뒤 다음 작전에 쓸 근거를 쌓습니다.

CTA:

> 첫 작전 만들기

**원칙**

**데이비드 오길비**:

기능 목록만 쓰면 무미건조하지만, 상황형 문장만 쓰면 카테고리를 잘못 찍을 수 있다. 그래서 첫 줄은 넓게, 항목은 구체적으로 가야 한다. “생산성 향상”, “효율적 목표 달성” 같은 추상 효용은 버린다. 반대로 “회의 전 쟁점 정리”처럼 특정 유스케이스에 고정하는 문장도 아직은 위험하다.

항목 수는 3개보다 **4개**가 낫다. 이 앱의 확인된 문제는 길이가 아니라 **범위 오해**다. 3개로 줄이면 설명은 깔끔해지지만, 앱의 용도를 너무 좁게 보이게 할 수 있다. 단, 5개부터는 자기자랑 냄새가 난다.

근거는 이번 라운드에 주어진 자료 안에서만 판단한다. 앞선 논의에서 인정된 근거는 두 가지다. 첫째, 네 전문가가 서로 다른 카테고리를 상정했다는 점. 둘째, “화면 하나당 10~15% 감소”, “상위권 40~50%” 같은 수치는 이 앱에 직접 적용하기 어렵다는 반박이다. 따라서 외부 수치가 아니라 **카테고리 오해 제거 → 행동 유도 → 사후 검증** 순서가 가장 방어 가능한 판단이다. 신규 출처 링크는 이번 조건상 웹 검색이 금지되어 추가하지 않는다.

**클로드 홉킨스**:

## 1) 입장 정리 — 바꾼 것, 지킨 것

**클로드 홉킨스**:

| 쟁점 | 앞선 내 주장 | 최종 | 이유 |
|---|---|---|---|
| 항목 문법 | `[상황] → [결과]` | **`[언제] + [무엇을 한다]`로 변경** | 닥터 이탈이 옳다. 결과형은 대응 이벤트가 없어 항목 단위 측정이 불가능하다. 행동형은 항목 3~4개가 곧 이벤트 3~4개가 된다. |
| 항목 길이 | 40자 1층 | **철회 → 2층(라벨+설명)** | 한국어 모바일 1줄 제약과 스캔 20%([NN/g](https://www.nngroup.com/articles/how-little-do-users-read/))는 사실이다. 다만 해법은 문장을 깎는 게 아니라 스캔 대상을 라벨로 분리하는 것이다. 25자로 깎으면 명사구=기능명이 뒷문으로 돌아온다. |
| 항목 수 | 3개(Cowan 근거) | **4개, 근거 교체** | Cowan 3~5는 작업기억 용량이고 화면 텍스트는 외부 저장이다. 3 고정의 근거로 쓴 건 내 오용이었다.

**클로드 홉킨스**:

4를 택하는 이유는 인지 이론이 아니라 **학습 채널** — 항목별 도달률로 죽은 항목을 골라낼 표본이 하나 더 생긴다. |
| 1인칭 | (미제기) | **금지하지 않음, A/B 항목으로 강등** | 오길비의 관찰은 날카롭지만 이 방에 측정치가 없다. 죽여야 할 건 화자가 아니라 공허한 술어다. |
| 1차 지표 | 첫 화면 이탈률 | **D1 내 항목 약속 행동 실행률** | 이탈률의 최적해는 첫 화면 삭제다. 아무도 그 결론을 안 내는 이상 그건 목표가 아니다. |

**클로드 홉킨스**:

**폐기 확정:** Appcues 체크리스트를 소개 항목 수 근거로 쓴 것(다른 물건), Nielsen 휴리스틱을 "3개"의 근거로 쓴 것(개수 미지정), "스캔 실패율 0%"(출처 없음, 성립 불가), 내가 앞서 인용한 10~15%·40~50%(카테고리·유입 맥락 불일치 지적이 옳다).

---

## 2) 최종안

**전제:** 이 방에서 유일하게 관측된 데이터는 *같은 이름으로 4명이 서로 다른 카테고리를 떠올렸다*는 것이다. 그러므로 첫 줄의 임무는 톤도 효용도 아니고 **카테고리 확정**이다. 이게 안 되면 아래 항목 카피는 전부 무의미하다.

```
[헤드라인 · 30자 미만]
  작전타임은 ○○○(카테고리 명사)입니다.
  — 수식어·약속·감성 금지. 신규 사용자가 이 줄만 보고
    앱 카테고리를 맞힐 수 있으면 통과.

[항목 4개 · 각 2층]
  ● 라벨 6~10자        ← 동사로 끝나는 행동. 스캔 대상.
    설명 20~35자        ← [언제] + [무엇을 한다]. 기능명 금지.

**클로드 홉킨스**:

[CTA 1개 · 동사 1개]
[스킵 링크 — 항상 노출]
```

**항목 작성 규칙 (하드 룰)**
1. **항목 = 앱 내 이벤트 1:1.** 대응 이벤트를 못 대는 항목은 즉시 삭제. 이 방의 합의 중 유일하게 검증 가능한 규칙이다. 2. 설명문은 `[언제]`로 시작한다. 상황이 앞에 없으면 그건 기능 나열이다. 3. **검증 불가 술어 금지** — "빨라진다", "지연 없는", "생산성이 높아진다". 감정을 금지하는 게 아니라 **초과약속**을 금지한다. 감정 자체는 A/B에서 이긴 사례가 있다([SplitMetrics](https://splitmetrics.com/blog/ab-testing/), [Apptweak](https://www.apptweak.com/en/aso-blog/ultimate-guide-to-screenshots-a-slash-b-testing)). 판정 기준은 취향이 아니라 "7일 내 이 약속이 지켜졌는가"다. 4.

화면은 **1장으로 끝낸다.** 화면당 완료율 손실이 실재한다([Setgreet](https://www.setgreet.com/blog/what-the-numbers-actually-say-about-mobile-app-onboarding-(and-what-to-track)), [Chameleon](https://www.chameleon.io/benchmark-report)).

**예시 카피는 쓰지 않는다.** 넷이 낸 예시가 각각 다른 앱을 상정했다는 사실이 그대로 증거다. 카테고리 명사 한 단어는 제작자만 안다 — 그 단어를 슬롯에 넣는 순간 나머지 4항목은 기계적으로 도출된다. 카테고리를 모르는 상태에서 상황 문장을 쓰면 "이건 내 상황이 아니다"라는 **오탐 이탈**을 만든다. 기능 나열이 빗나가면 밋밋할 뿐이지만, 상황 문장이 빗나가면 사용자를 내보낸다. 비대칭 리스크다.

---

## 3) 검증 — 순서를 뒤집으면 두 안 다 진다

**1단계 (관문): 카테고리 정답률.** 5초 노출 후 "이 앱은 무엇을 하는 앱인가" 자유응답, n=20~30. **정답률 80% 미만이면 항목 카피를 손대지 말고 첫 줄만 고친다.** 사용자 니즈를 먼저 확인하고 들어가라는 원칙 그대로다([GOV.UK Service Manual](https://www.gov.uk/service-manual/user-research/start-by-learning-user-needs)).

**2단계 (관문 통과 후에만): 3-arm 스플릿**
- A — 기능 목록 4~5개 (1층)
- B — 상황+행동 4개 (2층, 본안)
- C — 명사구 체크리스트 3개 (오길비안, 1인칭 제거)
- 1인칭 유지/제거는 B 내부의 2차 변인으로 붙인다. 회의에서 합의할 문제가 아니다.

**지표**
- 1차: **D1 내 항목 약속 행동 1개 이상 실행률**
- 2차: 첫 화면 통과율 (스킵이 빠른 안이 활성화에서 이기는 경우가 흔하다 — [Businessofapps](https://www.businessofapps.com/data/app-onboarding-rates/))
- 가드레일: **D7 잔존 + 항목-행동 매칭률**(각 항목이 약속한 이벤트의 7일 내 실행률). 통과율이 올랐는데 D7이나 매칭률이 떨어지면 그 항목은 초과약속으로 판정하고 폐기한다.
- 항목 단위 판정: 4주 내 도달률 하위 항목을 교체. 3개로 줄이면 이 채널이 하나 사라진다.

**표본:** 기준 활성화율 30%, 상대 리프트 20% 감지(α=.05, power=.8) 가정 시 암당 약 1,000명 — **이건 내 계산 가정이지 인용 벤치마크가 아니다.** 규모가 안 되면 1단계 정성 테스트만 돌리고 B를 기본값으로 출시한 뒤 항목별 도달률로 4주간 교체한다.

**참고:** 길이·스캔 근거 — [NN/g Be Succinct](https://www.nngroup.com/articles/be-succinct-writing-for-the-web/) · [Laws of UX](https://lawsofux.com/millers-law/) · [Stéphanie Walter](https://stephaniewalter.design/blog/your-menu-doesnt-need-millers-7-plus-minus-2-rule/)(7±2 무비판 적용에 대한 반박)

---

한 줄 요약: **첫 줄은 카테고리, 항목은 이벤트, 결정은 스플릿.** 나머지는 전부 취향이다.

**닥터 이탈**:

### 최종 수정안: 리스크 방어를 극대화한 '2층 구조 + 4항목 + 단계적 검증' 설계

기존의 '상황+즉각 행동' 중심 3개 항목 합의안은 앱의 카테고리가 불확실한 상태에서 치명적인 **오탐 이탈(False Positive Churn)**을 만듭니다. 사용자가 제시된 특정 상황에 해당하지 않는다고 판단하는 순간 앱을 바로 삭제하기 때문입니다. 이에 따라 방어적 관점에서 설계를 전면 수정합니다.

---

### 1. 구조 제약 및 카피 설계 (오해 차단 최우선)

**닥터 이탈**:

1. **카테고리 직관 명시 (최상단 1줄)**
    *   감성적 약속이나 1인칭 주어를 배제하고, 앱의 물리적 정체를 명사형으로 확정합니다. *   *카피 예시:* `"팀 스포츠 실시간 전술 공유 및 기록 플랫폼, 작전타임"`
2. **2층 구조의 4개 항목 구성**
    *   **행동 라벨 (6~10자)**로 스캔 속도를 확보하고, **상세 설명 (25~40자)**에 구체적 상황과 효용을 결합하여 인지 부하를 분산합니다 ([Nielsen Norman Group, 2020](https://www.nngroup.com/articles/scanning-patterns/)). *   3개 항목 제한은 앱의 가치 범위를 과소평가하게 만드므로, 학습 채널 다변화와 탐색 기회 확보를 위해 4개 항목을 기본값으로 설정합니다. 3. **구체적 카피 구성안**
    *   **라인업 공유** | 경기 직전 포지션과 출전 명단을 팀원에게 즉시 전송합니다. *   **전술판 드로잉** | 실시간 보드를 통해 경기 중에도 전술 지시를 시각화합니다.

**닥터 이탈**:

*   **기록 피드** | 경기 종료 후 개인 기록과 팀 경기 데이터를 보관합니다. *   **일정 매니저** | 다음 매치 일정과 참가 여부를 한눈에 취합합니다. 4. **명확한 단일 CTA 버튼**
    *   *예시:* `[3초 만에 우리 팀 만들기]`

**닥터 이탈**:

---

### 2. 단계적 검증 및 지표 정의 (추측 배제)

회의실 내 취향 합의를 배제하고 데이터로 방어선을 구축합니다.

**닥터 이탈**:

*   **1단계 (인지 검증 - 5초 테스트):** 사용자 20~30명에게 첫 화면을 5초간 노출한 후 "무슨 앱인지 이해했는가?"를 묻습니다 ([Five-Second Testing](https://www.nngroup.com/articles/five-second-test/)). 카테고리 정답률이 80% 미만이면 첫 줄 카피부터 재설계합니다.
*   **2단계 (A/B 테스트):** 카테고리 인지가 확보된 상태에서만 [기능 중심] vs [상황 중심] 카피의 A/B 테스트를 진행합니다.
*   **핵심 지표 (North Star Metric):** 단순 첫 화면 통과율이 아닌, **'D1 내 핵심 기능 1개 이상 실행률'**을 추적합니다. 첫 화면 통과율만 올리고 D7 잔존율이 떨어지면 그 안은 실패한 것입니다 ([Retention vs Conversion](https://amplitude.com/blog/retention-playbook-quick-start)).

**닥터 첫인상**:

## 최종 수정안

### 입장 조정 (한 줄)
이전 합의의 **“상황 3줄 + CTA”**는 언어 공식으로 옳다. 다만 약점 공략이 지적한 **카테고리 미확정 시 상황문의 오탐 이탈**과 **한 줄 15~25자 → 기능 명사구 복귀**는 체감상 맞다. 그래서 **구조는 2층·카테고리 선고정**, **본문 언어는 상황·행동**으로 절충한다. 기능 나열·공허 효용은 계속 폐기.

---

### 첫 화면 골격 (쓰는 순서 = 읽는 순서)

**① 카테고리 1줄 (필수)**  
임무: “이게 뭐 하는 앱인가”만. 감성·약속·1인칭 자랑 금지.  
- 공식: `[대상/장면 명사] + [하는 일 동사구]`  
- O: “경기 전·중, 작전을 맞추고 공유하는 앱”  
- X: “작전타임이 소개합니다” / “더 스마트한 준비”

**닥터 첫인상**:

**② 항목 3~4개, 각 2층**  
- **라벨 6~10자**: 사람이 하는 일 (기능명 금지)  
- **설명 25~40자**: `[그때] + [하는 일/바로 얻는 결과]`  
- 항목 = 앱 안 실제 화면·이벤트 1:1. 대응 없는 줄은 삭제.  
- 기본 **3**, 범위가 넓어 오해가 날 때만 **4**. 5 이상은 스캔이 아니라 설명서.

| # | 라벨 (스캔) | 설명 (내 얘기) |
|---|-------------|----------------|
| 1 | 지금 할 일 고르기 | 급한 것만 남기고 오늘 끝낼 목록을 만든다 |
| 2 | 작전 한 장 정리 | 쟁점·역할을 한 화면에 모아 바로 공유한다 |
| 3 | 짧게 맞춰 보기 | 시작 전 3분, 순서만 맞추고 들어간다 |
| 4 | (필요 시) 현장 수정 | 진행 중 바뀐 것만 고치고 다시 보낸다 |

**닥터 첫인상**:

※ 위 표는 **구조 예시**. 실제 제품 이벤트가 축구 라인업·회의 쟁점 등이면 라벨·설명만 그 생활 장면으로 교체. **카테고리 줄이 틀린 상태에서 상황만 구체화하지 말 것** — 빗나간 상황은 “나 아님”으로 읽힌다(약점 공략 2의 고분산 리스크).

**③ CTA 하나**  
“첫 작전 만들기” / “지금 시작” — 소개 문장 추가 금지.

**④ 화자**  
1인칭 전면 금지는 취향. 허용하되 **공허 술어만 죽인다.**  
- O: “경기 직전에 라인업을 맞출 때 켠다”  
- X: “작전타임은 당신의 생산성을 높입니다”

---

### 기능 vs 효용 — 첫 화면에 맞는 쪽

**닥터 첫인상**:

| 방식 | 처음 켠 순간의 체감 | 판정 |
|------|---------------------|------|
| 기능 나열 | 학습 숙제 → **부담**, “그래서 언제 쓰지?” 안 풀림 | 본문 금지 (부속 한 단어만) |
| 추상 효용 | “더 효율적으로” → **의심** | 금지 |
| 상황·행동 | “아, 그 순간” → **기대·안도** + 다음 탭이 보임 | **설명 층에 사용** |
| 카테고리 없이 상황만 | 틀린 장면이면 **오탐 이탈** | ①줄을 먼저 고정 |

**결론:** 첫 화면은 기능 목록도 광고 효용도 아니다.  
**“무슨 앱(①) → 그때 이렇게 쓴다 3~4(②) → 지금 이 버튼(③)”.**

---

### 길이·개수 (체감 기준)

- 항목: **3 기본 / 4 상한**  
- 라벨 한 호흡, 설명 한 줄(두 줄 금지)  
- 15~25자 단층 강제는 버린다 → 약점 공략 3대로, 글자 압박이 기능 명사구를 부른다.

---

### 검증 순서 (카피 회의로 끝내지 말 것)

**닥터 첫인상**:

근거는 이 라운드 약점 공략의 측정 순서. 외부 링크·새 수치는 쓰지 않음.

1. **5초 후** “이 앱은 무엇을 하는 앱인가” 자유응답 (n=20~30) → **카테고리 정답률**이 1차 관문. 미달이면 항목이 아니라 ①줄 수정.  
2. 통과 후에만 상황형 설명 vs 기능형 설명 A/B.  
3. **1차 지표:** 첫 화면 통과율이 아니라 **D1 내, 항목이 약속한 행동 1개 이상 실행**.  
4. **가드레일:** D7 잔존·삭제율. 통과↑·D7↓면 그 안은 진 것.  
5. 항목별 도달로 4주 내 죽은 줄 교체 → 그래서 학습 채널상 3 고정 독단은 약하고, **3~4 가변**이 맞다.

---

### 한 줄 요약
**이름 모호함을 ①줄로 먼저 죽이고, 항목은 “행동 라벨 + 상황 한 줄” 2층 3~4개, CTA 하나.**  
문장의 일은 설명서가 아니라 “지금 내 순간에 열 만하고, 다음에 뭘 누르면 되는지” 안도이다.

**사회자**:

📊 결선 라운드 현황 — 🔬 데이터가 말한다 1명 : 3명 🛡️ 최악부터 막는다
오길비·첫인상이 방어 쪽으로 이동, 홉킨스만 A 고수

**사회자**:

⚖️ 리스크 재검토 — 세 관점 모두에서 공통으로 걸린 문제는 '작전타임'이 실제로 무슨 앱인지가 이 논의 안에서 확정되지 않았다는 점이다. 결론이 제시한 4항목(상황 정리·선택지 비교·실행 기록·결과 회고)은 '의사결정 정리 도구'라는 전제를 스스로 만들어 넣은 것이며, 만약 이 앱이 실제로는 스포츠·일정·팀 커뮤니케이션 등 다른 성격이라면 첫 화면 전체가 잘못된 소개가 된다. 따라서 문안 확정 전에 앱의 실제 핵심 기능과 주 사용자를 확인하는 것이 우선이고, 그 전까지 이 4항목은 예시안으로만 취급해야 한다. 또한 첫 줄 '중요한 순간의 판단과 실행을 정리하는 앱'은 카테고리를 넓히려다 오히려 모호해져, 결론이 배격한 추상적 효용 문구와 실질적으로 같은 함정에 빠질 수 있다. 항목 수를 3개가 아니라 4개로 늘린 근거도 '범위 오해가 확인된 문제'라는 진술에 의존하는데, 그 오해는 사용자 데이터가 아니라 논의 참여자들의 해석 차이에서 나온 것이므로 실제 사용자 문제로 단정하기 어렵다. 항목이 늘면 첫 화면에서 읽히지 않을 위험도 함께 커진다는 점을 함께 밝혀야 한다.