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

📌 오늘의 안건
작전타임 첫 화면 소개글 쓰기

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

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

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

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

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

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

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

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

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

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

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

• 기대 불일치 방지를 위한 '상황 트리거' 중심 설계

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

• 인지 부하 차단을 위한 '3개 항목, 1줄' 제약

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

• 오해를 방어하는 '[상황] + [행동]' 결합 공식

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

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

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

첫 화면은 읽히는 화면이 아니라 통과되는 관문이다. 숫자가 그렇게 말한다. 온보딩 완료율은 30일 기준 글로벌 8.4%, 평균 19.2%, 상위권만 40~50%이고, 가치 도달 전 화면이 하나 늘 때마다 완료율이 10~15%씩 깎인다(Setgreet 벤치마크[1]), Businessofapps[2], Chameleon 2025 리포트[3]). 즉 이 화면의 존재 자체가 비용이므로, "기능이 이만큼 있다"는 정보는 비용을 정당화하지 못한다.

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

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

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

길이 규격:

• 항목 헤드라인: 한국어 12자 이내 명사구(영문 A/B 기준 3~6단어·30자 미만 헤드라인이 우세)
• 항목 본문: 1문장, 공백 포함 40자 이내, 능동태·현재형, 8학년 수준 문장(NN/g 가독성 가이드[3])
• 화면 전체: 헤드라인 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[4]). 표본이 안 나오는 규모라면 A/B 대신 신규 사용자 20명 대상 5초 테스트로 "이 앱이 뭘 해주는가"를 회상시켜 정답률을 세라 — 그것도 숫자다.

Sources:

• What the Numbers Actually Say About Mobile App Onboarding — Setgreet[5])
• App Onboarding Rates 2025 — Businessofapps[6]
• Chameleon User Onboarding Benchmark Report 2025[7]
• NN/g — How Little Do Users Read?[8]
• SplitMetrics — A/B Testing for ASO[9]
• Apptweak — Ultimate Guide to Screenshots A/B Testing[10]
• Laws of UX — Miller's Law[1]
• Stéphanie Walter — Your menu doesn't need Miller's 7±2 rule[2]
• Onboardics — A/B Test Onboarding Flows[4]
• 작전타임 서비스 소개(축구·풋살 라인업/전술판)[11]

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

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

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

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

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

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

첫 화면 구조

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

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

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

피해야 할 문장

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

더 나은 방향

• “회의 전 쟁점만 먼저 정리”
• “상대 입장별 대응 메모”
• “끝난 뒤 다음 액션 기록”

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

결론

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

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

---

다른 초안 비평 · 흡수

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

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

---

권장 형태 (체감 기준)

1. 한 줄 정체성 — 언제 켜는지 한 호흡. 1인칭·브랜드 선언 금지.

예: “경기 전·중, 라인업을 빨리 맞출 때” / “회의 앞두고 쟁점만 고를 때” (실제 제품 맥락에 맞게)

2. 항목 3개(절대 4 초과 금지) — 각 한 줄, 공백 포함 15~25자, 설명문 없음.

공식: [그때] + [하는 일/얻는 결과]

• O: “급한 일만 골라 오늘 끝낸다”
• O: “경기 중 3분 안에 라인업 공유”
• X: “우선순위 태그·타이머 연동” (기능)
• X: “더 효율적으로 준비하세요” (공허 효용)
• 바로 할 행동 하나 — “지금 시작”, “첫 작전 만들기”처럼 다음 탭만. 소개를 더 쓰지 마라.

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

---

왜 이 조합이 첫 화면에 맞나

• 첫 감정은 학습이 아니라 기대·부담·의심이다. 기능 목록은 학습 숙제를 주고, 과장 효용은 의심을 키운다.
• 상황 한 조각이 보이면 “나랑 맞는 순간인가?”가 먼저 풀리고, 행동이 보이면 “지금 뭘 하면 되지?”가 풀린다. 그 둘이 첫 화면의 전부다.
• 항목이 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 온보딩 벤치마크[1]) · Businessofapps[2] · Chameleon 2025[3] · NN/g How Little Do Users Read?[4] · NN/g Be Succinct[5] · SplitMetrics[6] · Apptweak[7] · Laws of UX — Miller's Law[8] · Stéphanie Walter[9] · GOV.UK Service Manual[10]

최종 결론: 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. 만장일치는 증거가 아니라 상관된 사전확률이다

넷이 같은 결론에 도달한 건 독립 검증이 아니라 같은 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로 결정할 문제이지 회의에서 합의할 문제가 아니다. 지금 이 방이 만장일치로 밀고 있는 것의 정체는 그것이다.

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

최종 수정안

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

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

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

1. 상황 정리

지금 결정해야 할 쟁점만 먼저 모읍니다.

2. 선택지 비교

가능한 대응과 리스크를 나란히 봅니다.

3. 실행 기록

누가 무엇을 언제 할지 남깁니다.

4. 결과 회고

끝난 뒤 다음 작전에 쓸 근거를 쌓습니다.

CTA:

첫 작전 만들기

원칙

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

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

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

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

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

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

---

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

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

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

최종 수정안

입장 조정 (한 줄)

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

---

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

① 카테고리 1줄 (필수)
임무: “이게 뭐 하는 앱인가”만. 감성·약속·1인칭 자랑 금지.

• 공식: [대상/장면 명사] + [하는 일 동사구]
• O: “경기 전·중, 작전을 맞추고 공유하는 앱”
• X: “작전타임이 소개합니다” / “더 스마트한 준비”

② 항목 3~4개, 각 2층

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

※ 위 표는 구조 예시. 실제 제품 이벤트가 축구 라인업·회의 쟁점 등이면 라벨·설명만 그 생활 장면으로 교체. 카테고리 줄이 틀린 상태에서 상황만 구체화하지 말 것 — 빗나간 상황은 “나 아님”으로 읽힌다(약점 공략 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 하나.
문장의 일은 설명서가 아니라 “지금 내 순간에 열 만하고, 다음에 뭘 누르면 되는지” 안도이다.