일은 먹고살기 위한 수단이다.
동시에, 나를 단단하게 만들어주는 과정이기도 하다.

일을 통해 사람을 만나고, 생각을 나누고, 결과를 만든다.
성과가 쌓이면 성취감을 느끼고, 좋은 동료를 만나면 동료애도 생긴다.
그 둘은 일할 때 느낄 수 있는 가장 큰 보상이다.

일은 언제나 쉽지 않다.
막막하고, 버겁고, 때로는 두렵다.
그럼에도 불구하고 해내야 한다.
일은 결국, 해내는 사람의 몫이다.

전 회사에는 사수도, 명확한 매뉴얼도 없었다.
그래도 어떻게든 시작했고, 어떻게든 굴러갔다.
일은 그런 식으로 배웠다.
정답은 없었지만, 길은 생겼다.

나는 아직 내가 어떤 일을 오래 하고 싶은지 모른다.
하지만 분명한 건, 일은 나를 바꾸고 있다는 것이다.
사람을 이해하는 방식, 문제를 대하는 태도, 나를 다루는 감정.
일은 그 모든 것에 영향을 준다.

앞으로는 다양한 사람들과 협업하게 될 것이다.
그 안에서 더 많은 선택을 하고, 더 많은 책임을 질 것이다.
그 과정을 통해,
나는 내가 어떤 방향을 향하고 싶은지 알게 될 것이다.

크고 멋진 말은 아직 없다.
하지만 분명히 말할 수 있는 건 하나다.
나는 일을 통해 나를 알아가고 있다.

그렇다.
일을 덜고 싶어 안 써본 도구가 없다. 자동화 툴, 협업 앱, 요즘은 AI까지. 하지만 대부분은 복잡하거나, ‘써야만 쓸 수 있는’ 느낌이다.

그런데 얼마 전부터 하나가 좀 다르게 다가왔다.
구글에서 만든 ‘NotebookLM’이라는 AI.
이름은 딱딱한데, 기능은 꽤 실용적이다. 문서를 읽고 요약하고, 질문을 던지면 알아서 맥락에 맞게 대답도 해준다. 말하자면, ‘자료 읽는 시간을 줄여주는 AI 파트너’쯤 된다.

직장인이라면 특히 유용한 기능이 몇 개 있다.
몇 달간 써보면서 “이건 진짜다” 싶었던 세 가지를 정리해봤다. 동료에게도 추천해봤고, 실제로 써먹힌 것들이다.


1. 문서 요약 + 브리핑 문서 자동 생성

기능 요약: 여러 자료를 한 번에 요약해서 브리핑 문서 형태로 정리해주는 기능.

이런 상황에서 쓴다:

  • 새로운 프로젝트 준비할 때
  • 외부 보고서나 리서치 자료를 빠르게 파악하고 싶을 때
  • 상사에게 전달할 보고서 초안을 뚝딱 만들고 싶을 때

어떻게 쓰냐면:

  1. NotebookLM을 켠다.
  2. ‘노트북’ 하나를 새로 만든다.
  3. 거기에 PDF든 구글 문서든 뉴스 기사든 원하는 자료를 드래그 앤 드롭으로 업로드한다.
  4. 아래처럼 프롬프트를 입력한다.
  5. “이 자료들을 기반으로 브리핑 문서를 작성해줘. 목적, 배경, 핵심 요약 중심으로.”

 

내가 실제로 써본 예:
사회 이슈 리서치, 정부 정책 자료, 경쟁사 캠페인 분석, 그 모든 걸 업로드하고 “팀장님께 보고할 요약 정리 부탁해요”라고 썼다.
5분 후, “요약·인사이트·핵심 데이터·결론 제안”이 포함된 문서 초안이 나왔다.

장점:

  • 자료를 다 안 읽어도 된다.
  • 요약 퀄리티가 생각보다 좋다.
  • 내 말투로 다시 정리하기만 하면 바로 보고 가능.

주의할 점:

  • 자료가 너무 많으면 초점이 흐려진다.
  • “누구에게 보고할 건지”를 꼭 말해야 함. (ex. 팀장용, 발표용 등)

요약하자면:
이건 요약 도구가 아니다. “브리핑 도우미”다.


2. 문서 기반 Q&A 정리 + 자동 FAQ 생성

기능 요약: 업로드한 문서를 기반으로 사람들이 자주 물을 법한 질문과 답변을 자동으로 뽑아주는 기능.

이런 상황에서 쓴다:

  • 팀 프로젝트에서 자꾸 같은 질문을 받는 상황
  • 매뉴얼이나 정책을 공유했는데도 슬랙에서 DM이 폭주할 때
  • 고객 대응용 FAQ를 만들 때

어떻게 쓰냐면:

  1. 기획안이나 가이드라인 같은 문서를 업로드한다.
  2. 이렇게 말한다.
  3. “이 문서에서 사람들이 자주 할 법한 질문과 그에 대한 답변을 정리해줘.”
  4. AI가 예상 질문과 응답을 리스트 형태로 정리해준다.

실제 예시:
내가 작성한 기획안을 팀에게 공유했을 때였다.
슬랙에서 이런 DM이 날아왔다.

  • “이 기능은 어디서부터 적용돼요?”
  • “A플랜이랑 B플랜은 어떤 기준으로 나눈 거예요?”

그래서 기획안을 NotebookLM에 업로드하고 위 요청을 했다.
FAQ 형식으로 정리된 문서가 나왔다. 질문도 적당히 날카롭고, 답변도 무난히 이해될 정도였다.
바로 복붙해서 팀 노션에 올렸다. DM은 그날로 줄었다.

특히 좋은 점:

  • ‘읽지 않아도 이해 가능한 문서’를 만들 수 있다.
  • “기획자의 머릿속”을 대신 설명해주는 효과.

활용 팁:

  • 질문 관점 설정이 중요하다.
    “신입 직원이 묻는다면?”, “고객 입장에서 보면?” 등 프롬프트를 구체화할수록 결과도 좋아진다.

요약하자면:
이건 질문 폭격을 미리 차단하는 방패다.
문서 공유 → 질문 대응 → 반복 설명 → 야근.
이 굴레에서 벗어나고 싶다면 추천한다.


3. 개념 정리 + 마인드맵 구조 생성

기능 요약: 업로드한 문서를 바탕으로 주요 개념과 그 관계를 시각적으로 구조화해주는 기능.

이런 상황에서 쓴다:

  • 아이디어가 흩어져 있고 정리가 안 될 때
  • 복잡한 개념을 팀에게 설명해야 할 때
  • 보고서나 기획서 뼈대를 잡고 싶을 때

어떻게 쓰냐면:

  1. 관련 자료를 NotebookLM에 올린다.
  2. 이렇게 말한다.
  3. “이 자료를 바탕으로 주요 개념과 관계를 시각적으로 정리해줘. 마인드맵 형태로.”
  4. 중심 주제 – 하위 항목 – 세부 내용의 형태로 정리된 구조가 나온다.

실제 사례:
BX 디자이너와 함께 ‘구독 서비스 기획’ 중이었다.
시장 조사 자료, 고객 인터뷰 요약본, 경쟁사 분석이 있었지만 뭔가 뒤죽박죽.
NotebookLM에 전부 넣고 마인드맵 요청을 했더니 아래처럼 정리됨.

  • 메인 주제: 여성 대상 라이프스타일 구독 서비스
    • 니즈: 루틴 유지, 비용 절감
    • 카테고리: 뷰티, 건강, 식사
    • 차별화 요소: 콘텐츠 기반, 정기 혜택

기획서 초안 목차가 그 자리에서 뚝딱 나왔다.
회의 때도 설명하기 쉬웠고, 자료 흐름을 말로 풀기 쉬웠다.

활용 팁:

  • 처음에는 자료 없이 “키워드 중심 마인드맵”도 가능.
  • 시각화 결과가 이미 충분히 PPT로 옮기기 좋은 구조로 나옴.

 

NotebookLM은 단순히 문서를 요약해주는 도구가 아니다.
자료를 읽고, 정리하고, 설명하고, 때로는 기획의 실마리까지 잡아주는—꽤 쓸 만한 동료다.

사람처럼 감은 없지만, 대신 빠르고 정확하다.
그리고 무엇보다 지치지 않는다.

직장인의 하루엔 늘 시간이 모자라다.
그 시간을 조금이라도 되찾을 수 있다면, 도구 하나쯤은 잘 써보는 게 맞다.

'AI' 카테고리의 다른 글

바이브 코딩은 기획자의 무기일까, 함정일까  (1) 2025.05.07

 

대표사진 삭제
  • 사진 편집
  •  
  • 작게문서 너비옆트임
  •  
  • 삭제

사진: UnsplashFlorian Olivo

프로그래밍을 배우지 않고도 웹앱 하나쯤 만들 수 있는 시대가 왔다. 기획자 입장에서 이보다 반가운 소식이 있을까.

예전엔 아이디어가 떠올라도, 개발자에게 상세 기획서를 전달하고 구현 가능성을 따져보며 몇 번의 커뮤니케이션을 거쳐야 했다. 그마저도 개발 우선순위에 밀리면 실현되기 어려웠다.

 

하지만 지금은 다르다. 생성형 AI 기술의 발전은 '말로 만드는 서비스'를 현실로 만들고 있다.

특히 요즘 자주 들리는 키워드, ‘바이브 코딩(Vibe Coding)’은 그 흐름의 상징처럼 언급된다.

타이핑보다 말이 빠르다는 어느 개발자의 고백, 프롬프트 한 줄로 앱 프로토타입을 뽑아내는 실험 결과들,

그리고 실제로 코딩을 몰라도 Cursor, Replit, Claude 같은 툴을 활용해 결과물을 만들어낸 사례들.

서비스 기획자는 더 이상 ‘화면을 그려주는 사람’에 머무르지 않는다. 이제는 직접 MVP를 만들어볼 수 있는 손을 갖게 된 셈이다.

텍스트만 잘 다루면 된다. 문제를 서술하고, 요구를 설명하고, 흐름을 조율하면, AI가 코드로 번역하고 결과로 보여준다.

기술의 진입장벽이 낮아질수록, 기획자의 영향력은 커질 수도 있다.

실행의 속도, 실험의 횟수, 설득의 과정 모두 달라질 수 있기 때문이다.

 

하지만 그럴수록 남는 질문도 있다.

이건 정말 기획자의 ‘무기’가 될 수 있을까? 아니면 '무기'를 가장한 '함정'일까?

 

 

바이브 코딩이 기획자에게 ‘무기’가 되는 순간들

출처 입력

 
사진 삭제

사진: UnsplashShoeib Abolhassani

1. 설명할 수 있는 아이디어가 손으로 만들어진다

 

왜 무기인가?

“아이디어 → 코드 → 결과물” 사이의 시간이 비약적으로 단축되기 때문이다.

기획자의 오래된 고민 중 하나는 ‘이걸 어떻게 보여줄까’다. 말로 설명하자니 감이 안 오고, 와이어프레임으로는 부족하다.

프로토타입을 만들고 싶지만, 툴도 낯설고 구현은 더더욱 어렵다.

 

하지만 지금은 다르다.

예를 들어,

“이메일을 입력받아서 DB에 저장하는 간단한 폼 만들어줘.”

라고 프롬프트를 던지면, Cursor 같은 툴은 HTML과 Firebase 연동 코드까지 덜컥 만들어낸다.

그 코드가 완벽하다는 뜻은 아니다. 하지만 이걸 실행해서 눈으로 보여줄 수 있다는 게 중요하다.

디자인 없이도, 스토리보드 없이도, 기획을 ‘보여주는’ 시대가 열린 셈이다.

 

실행물은 언제나 말보다 설득력이 있다.

기획서 없이 기획을 증명하는 것, 이것이야말로 속도와 신뢰의 결정판이다.

 

 

2. 사전 검증용 MVP를 스스로 만들 수 있다

 

왜 무기인가?

‘가설’이 실제 유의미한지, 개발 리소스를 쓰기 전에 미리 실험해볼 수 있기 때문이다.

기획자는 항상 선택과 집중의 문제에 부딪힌다.

‘이 기능이 정말 필요한가?’

‘우선순위를 어디에 둘 것인가?’

예전엔 A/B 테스트를 하려면 꽤 많은 리소스가 필요했다.

 

하지만 지금은,

“검색창 + 태그 필터 기능이 있는 이벤트 아카이브 페이지 만들어줘.”

라고 입력하면, HTML과 JS 코드가 자동으로 구현된다.

실제 데이터는 더미 JSON으로 채워서 인터랙션을 체험해볼 수 있다.

물론 이건 실서비스는 아니다. 하지만 MVP 수준의 체험은 가능하다. 반응을 테스트하고, 피드백을 받을 수 있다.

 

‘아이디어를 바로 실험할 수 있는 능력’은 이제 기획자에게도 가능한 일이 되었다.

그 자체로 ‘개발 요청 리스트’는 더 정제되고, 기획 우선순위는 더 명확해진다.

 

 

3. 기능 정의 능력 = 프롬프트 작성력

 

왜 무기인가?

기획자가 평소에 다져온 ‘요구 정리 능력’이 AI의 성능에 그대로 반영되기 때문이다.

AI에게 바라는 건 ‘센스’가 아니다.

프롬프트라는 입력값을 통해 조건을 명확히 설정하는 것이다.

 

예를 들어,

❌ “UX를 직관적으로 개선해줘” → AI는 ‘직관적’이 뭔지 모른다.

✅ “화면 크기 768px 이하일 때 사이드바를 접히는 토글 버튼으로 바꿔줘” → 명확하다.

기획자라면 이 차이를 직감적으로 안다.

정확한 요구, 조건화된 언어, 예외 사항까지 고려한 시나리오. 이런 역량은 프롬프트를 구성할 때 빛을 발한다.

 

즉, 기획을 잘하는 사람일수록 AI를 잘 다룬다. 이건 단순한 사용법의 문제가 아니라,

‘정확히 설명할 수 있는 사람’이 결과도 빠르고 정확하게 끌어낸다는 뜻이다.

 

 

4. 협업 언어로서의 ‘자연어’

 

왜 무기인가?

바이브 코딩은 개발자뿐 아니라 디자이너, 마케터와의 협업에도 유용한 인터페이스다.

예를 들어,

디자이너가 “이 인터랙션, 구현 가능해?”라고 물을 때,

기획자는 그 자리에서 AI에게 시켜 구현해볼 수 있다. 심지어 웹에서 바로 돌려보고, 필요하다면 GIF로 녹화해 보여줄 수도 있다.

이건 회신 속도를 단축시키는 것을 넘어, 팀 내 역할을 더 명확하게 만들고 커뮤니케이션의 허들을 낮춰주는 기능이다.

 

기획자는 원래도 팀의 중간자였다.

이제 그 역할을 더 빠르고 명확하게 할 수 있게 된 것이다.

자연어는 모두의 언어다. 바이브 코딩은 기술이 아니라, 협업을 위한 도구에 가깝다.

 


반대로, ‘함정’이 되는 순간들

출처 입력

1. 코드가 작동한다고 해서 ‘써도 되는 코드’는 아니다

 

왜 함정인가?

실행되는 것과 ‘서비스에 쓸 수 있는 것’은 다르기 때문이다.

AI가 만들어주는 코드는 겉보기에 완성형처럼 보인다. 로그인 화면도 만들고, 버튼도 눌리고, 데이터도 저장된다.

하지만 그게 진짜 ‘써도 되는 코드’일까?

예를 들어,

AI가 만들어준 로그인 기능에는 세션 처리가 없다.

입력값 검증도 빠져 있고, 아이디와 비밀번호가 암호화되지 않은 채 전송된다.

기획자는 실행된다는 이유만으로 안심하지만,

개발자가 코드를 검토하는 순간 말한다.

“이건 실제 서비스에서는 절대 쓰면 안 되는 코드예요.”

코드가 돌아간다고 해서 그게 곧 완성이라는 착각은,

기획자에게 치명적인 리스크다.

특히 보안, 성능, 확장성은 기획자가 쉽게 파악할 수 없는 부분이라 더 위험하다.

 

2. 프롬프트가 모호하면, 결과물은 더 엉망이다

 

왜 함정인가?

요구가 구체적이지 않으면, AI는 ‘알아서’ 이상한 선택을 하기 때문이다. AI는 사람처럼 “그 느낌 뭔지 알지?”를 모른다.

그래서 프롬프트가 모호하면, 엉뚱한 해석을 한다.

예를 들어,

“모던한 느낌으로 디자인 바꿔줘”라고 하면,

버튼은 커지고, 폰트는 고딕, 컬러는 온통 파란색으로 덮인다.

“뉴스 기사 페이지처럼 만들어줘”라고 하면,

헤드라인만 덜렁 뜨고 나머지는 없다.

 

기획자가 기대한 ‘구체적 구조’나 ‘레이아웃 기준’이 명시되지 않으면

AI는 ‘자기만의 기준’으로 결과를 생성한다. 결국 기획자는 결과물을 다시 수정해야 하고, 처음부터 정확하게 전달했으면 없었을 소통 비용이 반복된다. AI와의 협업은 오히려 더 고도로 정제된 언어 능력을 요구한다.

 

 

3. 문제 생기면 ‘아무것도 못 한다’

 

왜 함정인가?

AI가 만들어준 코드를 이해하지 못하면, 에러 발생 시 손쓸 방법이 없기 때문이다.

코드가 잘 돌아갈 때는 문제없다.

하지만 작은 이슈라도 생기면, 진짜 고비는 그때부터다.

예를 들어,

버튼을 눌렀는데 아무 동작이 없다.

콘솔에는 오류 메시지가 계속 뜨는데, 이게 무슨 뜻인지 도무지 모르겠다. 결국 기획자는 다시 개발자에게 요청할 수밖에 없고,

“이건 제가 만든 건데…”라는 민망한 상황도 생긴다. 기획자가 직접 만든 코드인데, 고칠 수는 없다면

그건 자율이 아니라 ‘의존’이다. 이런 상황이 반복되면, 팀 내 신뢰나 속도 모두 손해를 본다.

 

4. 완성물을 ‘관리’할 수 없다

 

왜 함정인가?

처음엔 빨리 만들어지지만, 유지보수는 불가능에 가깝기 때문이다.

AI는 빠르게 코드를 만들어주지만,

그 구조가 실무에서 유지하기 좋은 방식인 경우는 거의 없다.

예를 들어,

기능이 5개 들어간 페이지를 만들었는데, 코드가 전부 한 파일에 뒤엉켜 있다.

기획자는 “여기 이 기능만 수정하면 되겠지” 싶지만,

실제로는 전체를 다시 짜야 할 상황이 벌어진다. 모듈화도 없고, 네이밍도 직관적이지 않다.

심지어 예외 처리나 사용자 대응 흐름도 정리되어 있지 않다. 결과적으로 초기 구현 속도는 빠를 수 있어도,

실제 운영 단계에서 발생하는 문제를 감당할 수 없다. 서비스는 ‘만드는 것’보다 ‘관리하는 것’이 더 어렵다는 걸 잊지 말아야 한다.

 

 

 

정리하자면

  • 0열 선택0열 다음에 열 추가
  • 1열 선택1열 다음에 열 추가
  • 2열 선택2열 다음에 열 추가
  • 0행 선택0행 다음에 행 추가
  • 1행 선택1행 다음에 행 추가
  • 2행 선택2행 다음에 행 추가
  • 3행 선택3행 다음에 행 추가
  • 4행 선택4행 다음에 행 추가
셀 전체 선택
열 너비 조절
행 높이 조절
기준
무기
함정
목적
아이디어 검증, 실험
배포 가능한 결과물로 착각
태도
AI를 ‘보조 도구’로 인식
AI를 ‘완결된 개발자’로 착각
역할
구조를 설계하고, 결과를 평가
의도를 전달하고 결과에 무조건 수용
결과
빠른 프로토타입, 협업 증진
낮은 품질, 의존성 증가, 반복된 재요청
  • 셀 병합
  • 행 분할
  • 열 분할
  • 너비 맞춤
  • 삭제

 

그래서 기획자는 어떻게 대비해야 하나?

 

바이브 코딩은 기획자에게 분명 기회다.

하지만 그것이 곧바로 ‘실무 생산성’으로 이어지려면, 몇 가지 준비와 분별이 필요하다.

기획자는 더 이상 단순히 ‘아이디어를 설명하는 사람’이 아니다.

이제는 ‘기술을 다루는 기획자’가 되어야 한다.

그렇다면, 구체적으로 어떻게 준비해야 할까?

 

1. 코드를 ‘읽는 능력’부터 키운다

직접 짜는 것보다 먼저, 이해하고 해석할 수 있는 능력이 중요하다.

HTML/CSS/JS의 기초 구조 정도는 ‘구문 분석’할 줄 알아야 한다.

코드 한 줄의 의미를 알고 있어야, AI가 무슨 실수를 했는지도 파악할 수 있다.

  • 최소한 콘솔 에러 메시지를 읽고, 키워드를 검색할 수 있어야 한다.
  • ChatGPT에게 오류 로그를 붙여넣을 수 있을 정도의 ‘이해력’만 있어도 괜찮다.

이건 개발자가 되자는 말이 아니다. 기획자도 구글링이 가능해야 한다는 뜻이다.

 

2. 프롬프트를 ‘기획서처럼’ 쓴다

프롬프트는 요청이자 설계다.

기획자가 평소 쓰는 기획안처럼, 프롬프트도 조건, 예외, 목적이 명확해야 한다.

❌ "깔끔한 디자인으로 바꿔줘"

✅ "배경은 흰색, 텍스트는 검정, 버튼은 원형으로 파란색이며 hover 시 그림자 효과 추가"

  • 문장으로 기획서를 쓰는 연습이 필요하다.
  • 구체화하는 습관이 프롬프트의 질을 바꾼다.

AI는 센스를 보완해주는 도구가 아니다. 센스를 구조화하는 도구다.

 

3. ‘테스트 환경’을 일상화한다

기획자가 만든 코드가 실제 서비스에 바로 쓰일 일은 드물다.

하지만 ‘실험실’에서는 얼마든지 써볼 수 있다.

테스트 공간을 만드는 습관이 기획자의 실험력을 높인다.

  • Replit, CodePen, Vercel 같은 툴로 테스트 페이지를 직접 띄워보자.
  • 가상의 데이터를 활용해 가설을 시각화해보는 연습을 하자.

한 줄 코드가 아닌, ‘시나리오 단위’로 결과물을 점검하는 눈이 생긴다.

 

4. ‘실무로 쓸 수 없는 코드’를 구분하는 감각

AI가 만들어준 코드는 빠르고 편하지만,

보안, 성능, 구조 측면에선 실무 투입이 어렵다.

  • 로그인/회원가입처럼 민감한 기능은 ‘개발자 리뷰 필수’로 명시하자.
  • 입력값 검증, 인증 처리 등은 ‘검토 체크리스트’를 만들어 놓는 것이 좋다.

기획자에게 필요한 건 완벽한 구현이 아니다. “이건 실무에서 검토가 필요하다”는 판단 기준이다.

 

5. 개발자와의 역할 구분을 재정의한다

바이브 코딩을 잘하는 기획자는 개발자를 대체하지 않는다.

오히려, 더 정제된 질문과 더 정확한 명세서를 전달하게 된다.

  • “이거 되나요?” 대신 → “여기까지 AI로 만들었고, 이 부분에서 API 연동이 필요해요”
  • “이렇게 구현해주세요” 대신 → “이건 AI가 만든 코드인데 리뷰 부탁드려요”

즉, 바이브 코딩은 ‘개발자의 영역을 침범하는 도구’가 아니라, ‘더 나은 협업을 위한 브리프’다.

 

 
사진 삭제

사진 설명을 입력하세요.

바이브 코딩은 기획자에게 새로운 역할을 부여한다.

예전처럼 ‘기획서만 잘 쓰는 기획자’로는 부족하다.

실행해보고, 실험해보고, 구조를 판단할 수 있는 기획자가 필요한 시대다.

그리고 그 변화는, 지금 이 글을 읽고 있는 기획자부터 시작될 수 있다

 

'AI' 카테고리의 다른 글

직장인을 살리는 AI 도구, NotebookLM  (0) 2025.05.07

요즘 회의에서 가장 자주 들리는 말 중 하나다.
“이번 분기 KPI 어떻게 잡을까요?”

사실 'KPI'라는 단어만 들어도 속이 뻐근해지는 사람이 적지 않다.
기획자는 막연한 수치에 방향을 잃고, 에디터는 “조회수만이 전부는 아니잖아요”라고 말한다.
개발자는 “그건 결과일 뿐인데요…”라는 말을 꾹 참고 넘긴다.

모두가 KPI를 말하지만, 정작 같은 언어를 쓰고 있는 건 아닐지도 모른다.
특히 이곳, 미디어라는 독특한 업계 안에서는 더더욱.


1. KPI는 ‘성과’보다 ‘시선’을 위한 도구다

 

KPI는 흔히 ‘성과를 측정하는 수치’로 정의된다.
하지만 미디어 업계에서 KPI를 이렇게 단순하게 다루다 보면, 우리는 금세 ‘조회수의 노예’가 된다.

‘좋은 콘텐츠 = 많이 본 콘텐츠’가 아니라는 걸 우리는 잘 안다.
그런데도 왜 KPI는 늘 UV, PV, 전환율 같은 정량 지표로만 채워질까?

 

답은 단순하다.
보여줄 수 있는 수치가 있으면, 안심되기 때문이다.

 

KPI는 분명 성과의 지표지만, 미디어 팀에게는 오히려 ‘조직의 시선’을 정렬하는 장치에 가깝다.
이 팀이 지금 무엇을 가장 중요하게 여기고 있는가를 보여주는 도구 말이다.

그래서 KPI를 세우기 전엔,
숫자를 정하기보다 먼저 이 질문을 던져야 한다.
“우리는 지금 어디를 보고 있는가?”


현장에서 써먹을 수 있는 미디어형 KPI 예시

막연한 KPI 대신, 지향점을 담은 수치를 고민해봤다.
기획자의 관점에서 바라본, ‘쓸 만한’ 지표들이다.

 

콘텐츠팀

  • 조회수 상위 10% 콘텐츠의 평균 이탈 구간 분석 완료율 100%
    → 숫자보다, 왜 읽다 나갔는지를 아는 것이 ‘편집력’이다
  • 기획 의도와 실제 댓글 키워드의 일치도 70% 이상
    → 독자의 반응이 메시지에 닿았는지를 측정하는 정성 기반 지표

프로덕트팀

  • 모바일 홈 진입 후 기사 탐색 평균 깊이 3단계 이상 (ex. 홈 → 리스트 → 상세 → 관련기사 클릭)
    → ‘길’이 아니라 ‘길들’이 보이는 구조를 만들었는가?
  • AI 추천 콘텐츠 클릭률보다 직접 탐색 콘텐츠 클릭률 비중 50% 이상
    → 레코멘드보다 사용자의 ‘의도적 탐색’이 일어나는 경험 설계

브랜드 마케팅팀

  • 자사 콘텐츠 저장/스크랩 비율 상위 콘텐츠 내 브랜드 언급률 80% 이상
    → ‘좋아서 저장’한 콘텐츠가 브랜드 이미지와 얼마나 연결되어 있는가
  • SNS 콘텐츠 중, 댓글 내 브랜드 자발적 언급 발생 콘텐츠 비율 30% 이상
    → 단순 도달이 아닌, 기억에 남는 콘텐츠였는지를 보는 시선

KPI는 이렇게 써야 한다.
수치 자체보다, 그 수치가 왜 중요한지를 설명할 수 있어야 한다.
그게 바로 기획자의 KPI다.

 


2. KPI가 팀을 무너뜨리는 순간

KPI를 못 세워서 무너지는 경우보다,
잘못 세워서 방향을 잃는 경우가 훨씬 많다.

  • “월간 PV 1,000만 달성”이라는 KPI는 자극적인 제목을 부르고
  • “전환율 10%”라는 KPI는 억지스러운 유도문구를 낳고
  • “시청시간 5분 이상”이라는 KPI는 불필요하게 긴 영상으로 이어진다

숫자 그 자체가 전략이 되면, 팀은 결국 의미 없는 숫자만 쌓게 된다.

그래서 KPI를 만들 땐, 반드시 이 질문이 필요하다.
“이 수치를 달성하면, 우리가 진짜 원하는 걸 얻을 수 있는가?”

만약 대답이 “그건 아닌 것 같은데요…”라면, 그 KPI는 다시 짜야 한다.

 

 


 

3. 기획자의 KPI는 전략의 언어다

솔직히 말해, KPI라는 단어는 어딘가 좀 구리게 들린다.
낡았고, 부담스럽고, 자칫하면 관료적인 냄새가 난다.
숫자가 사람을 평가하는 것 같고, 창의성을 억제하는 틀처럼 느껴지기도 한다.

하지만 기획자는 KPI를 피할 수 없다.
왜냐하면 KPI는 단순한 수치가 아니라,
조직의 전략을 숫자로 번역한 언어이기 때문이다.

예를 들어보자.

KPI 단순 수치 의미 기획자의 본질적 질문 점검해야 할 기획 요소
뉴스레터 클릭률 5% 이상 수신자 중 5%가 콘텐츠를 클릭함 우리 콘텐츠는 사람들에게 ‘눌러볼 만큼 가치 있어 보이나?’ 제목 구성, 발신 타이밍, 채널 전략, 콘텐츠 포맷과 타겟 매칭
탐색률 2페이지 이상 유지 사용자 1인당 평균 2페이지 이상 콘텐츠를 탐색함 첫 진입 이후, 두 번째 클릭으로 이어질만한 흐름이 존재하는가? 정보 구조(IA), 콘텐츠 배치, UX 플로우, 관련 콘텐츠 추천 알고리즘 설계
전환율 3% 이상 방문자의 3%가 구매, 신청 등 목표 행동을 완료함 이 CTA(Call To Action)는 지금 이 고객 여정에 적절한가? 광고 집행 전략, 랜딩페이지 메시지와 톤, CTA 위치 및 문구, 유입 여정의 자연스러움

 

 

결국 문제는, 숫자를 싫어하는 게 아니다. 숫자에 아무 전략도 담기지 않았을 때, 그게 진짜 문제다. KPI는 무서울 게 없다.
오히려 KPI가 없으면, 팀은 각자 다른 방향을 바라보며 일하게 된다.

좋은 KPI는 팀의 방향을 정렬시키고, 의사결정 과정에서 던지는 “이게 맞는 선택이었을까?”라는 질문에 기준을 준다.

누군가는 ‘체류시간’을,
누군가는 ‘구독자 수’를 말할 수도 있다.
하지만 결국 우리는 같은 질문에 답하고 있어야 한다:

“우리는 지금, 진짜 중요한 것을 보고 있는가?”

 

마무리하며: KPI는 ‘일 잘함’의 증거가 아니다

좋은 KPI를 세웠다고 해서, 일을 잘한 건 아니다.
그저, 좋은 질문을 던졌다는 증거일 뿐이다.

우리가 지금 제대로 가고 있는지,
그 길을 팀 모두가 알고 있는지,
그리고 그 숫자 뒤에 진짜로 ‘사람’이 있는지를 확인하는 질문.

KPI는 숫자가 아니다.
우리 팀이 추구하는 ‘가치’가 어떤 모습이어야 하는지에 대한 정의다.

그러니 기획자는 오늘도 조용히 이 질문을 던진다.

“지금 이 KPI, 우리가 진짜 원하는 걸 보여주고 있나요?”

'기획 > PM' 카테고리의 다른 글

기획자에게 필요한 데이터 능력 3가지  (2) 2023.12.26

최근 송길영 작가님의 '시대예보'라는 책을 재밌게 읽고 있다.

책의 소주제인 '언어 습관이 조직의 운명을 바꾼다'  내 업무과 연관도를 가지고 있다고 생각해서 짧게 글을 기록해본다.

 

책에서 이야기하는 소주제 아래 두 가지 습관을 내 경험에 빗대어

PM에게 중요한 언어 습관 2가지로 이야기 해보고자한다. 


 

a. 관점의 재정의 


 

내가 근무해왔던 조직은 '효율성'을 선으로 생각해왔던 조직이었다.

책에 따르면 '집단주의적 사고가 힘을 얻는 이유는 효율이 최고의 기준' 이었기 때문이라고 하는데

틀린 말이 아니었다. 집단의 효율을 위해 '우리팀'은 다같이 같은 시간 일을 하고 다 같이 야근을 하고

심지어 점심마저도 '우리팀' 모두가 함께하고 커피까지 마시고 다같이 일을 시작하는 공장 같은 일과를 보냈었다.

 

이런 일과가 반복되다보니 팀의 의견을 모으는 시간은 비약적으로 줄일 수 있었는데

'우리팀'이 할 수 있는 업무 능력을 모두가 알고 있었고 '우리팀'에서 쓰이는 단어, 커뮤니케이션 채널도 일원화했기 때문이었다.

 

팀의 효율성은 극한으로 올릴 수 있었지만 '우리팀'은 머지않아 한계에 도달했다.

사회는 다양해지고 사용자를 포함한 클라이언트의 요구 역시 다양해졌다.

'우리'라는 테두리안에서 '우리가 아닌 사람들'을 배척했던 팀은 점차 도태했고 성장은 거기서 멈추었다.

 

이제와서 나는 그런 생각을 해본다.

'우리'의 범주를 조금 더 넓게 확장했다면?

'우리'라는 관점을 협업사까지 생각해봤다면?

'우리'라는 단어에는 오히려 한계가 없었던 걸지도 모른다. 관점을 바꾸고 바라봤다면..

 

 

PM으로서 갖춰야할 언어 습관 중 하나는 '관점의 재정의' 이다.

관점을 재정의한다면 크게 3가지 장점이 있다.

 

1. 문제 해결과 창의성 촉진: 관점의 재정의함으로써 문제를 다른 각도에서 바라보고 새로운 아이디어를 도출할 있다.

PM 프로젝트 진행 발생하는 예상치도 못한 다양한 문제를 해결해야 하는데 이때 기존의 관점에 갇혀있지 않고 다른 시각에서 문제를 바라보고 해결책을 찾을 있다면 창의적이고 혁신적인 아이디어를 도출할 있다.

 

2. 다양한 이해관계자와의 원활한 커뮤니케이션: PM은 조직구성원을 포함한 다양한 이해관계자들과의 커뮤니케이션이 필수적인데 이때, 관점의 재정의는 다른 이해관계자들의 의견과 관점을 이해하고 수용할 있는 능력을 의미한다. 프로젝트의 성공을 위해서는 이해관계자들과의 협력과 이해를 도모할 있는 관점의 재정의가 필수적이다.

 

3. 갈등 관리와 협업 강화: 프로젝트 진행 갈등은 웬만해서는 일어난다고 봐야한다. 하지만 관점의 재정의는 갈등 상황에서도 상대방의 의견과 관점을 이해하고 수용할 수 있게 해준다. 관점을 재정의함으로서 갈등을 조정하고 협업 관계를 강화하고 팀원들과의 원활한 협업을 이루어내고 프로젝트의 성공적으로 마무리할 수 있게한다.

 

 

 

 

 

 

 

b. 언어의 현행화


 

책에 따르면 언어의 현행화를 게을리하면 다음 세대의 혐오를 받는다고 한다.

대상을 타자화시키지 않도록 계속 사유해야 한다고 한다.

 

언어는 본인이 경험해온 환경에서 비롯된 습관이라고 생각한다.

따라서 습관을 벗어난 언어는 사용하기는 생각보다 굉장한 노력이 필요하다.

하지만 PM은 항상 시대와 시장에 적합한 언어를 찾고 사용해야하는 숙명을 지녔다.

이 단어는 사용자들에게 혐오감을 조장하지는 않는지 익숙하게 쓰이는 단어인지.

늘상 쓰이던 단어도 다시 한번 주기적으로 확인할 필요가 있다.

 

"관행적 표현과 차별적 인식을 형성할 수 있는 언어를 새로운 표현으로 대체해야 합니다."

 

PM으로서 갖춰야할 언어 습관 중 두번째는 '언어의 현행화' 이다.

언어의 현행화 장점 역시 3가지가 있다.

 

1. 효과적인 의사 소통: 언어의 현행화는 현재의 트렌드와 업계에서 사용되는 용어, 관용구 등을 파악하고 적절하게 활용하는 능력으로 이를 통해 팀원들과의 의사 소통에서 오해나 혼란을 방지하고, 명확하고 효과적인 메시지를 전달할  있다.

 

2. 업무 효율성 향상: PM은 다양한 문서와 보고서를 작성하고 리뷰해야 한다. 언어의 현행화는 문서 작성 최신 용어와 산업 표준을 따르는 것을 의미하는데 언어를 현행화함으로서 문서의 질을 향상시키고, 읽는 이들에게 쉽게 이해되고 효과적으로 전달될 있다.

 

3. 전문성과 신뢰도 강화: PM 프로젝트 팀과 이해관계자들에게 전문성과 신뢰도를 보여줘야 한다. 언어의 현행화는 최신 동향과 업계 용어에 대한 이해를 반영하는 것으로, 전문성을 강화할 있는 요소로 업계에서 사용되는 용어와 표현을 정확하게 사용하면 전문성을 인정받고 신뢰도를 높일 있다.

 

 

 

 

 

 

 

저는 향수를 좋아하는 편입니다. 지갑 사정이 넉넉하지 않기에 1년에 여름 - 가을/겨울 2번 구입을 하고는 하는데요.

향수를 뿌린지도 어언 12년이 넘었고 사용해본 향수도 15개가 넘기때문에 일반적인 남자치고는 다양하게 써봤다고 할 수 있죠.

 

사람을 기억하는 다양한 방법이 있지만 저는 향 역시 내 이미지를 만드는데 크게 일조한다고 생각하기에 너무 흔한 향수를 뿌리고 싶지는 않더라고요. 흔하지 않을 수 있으나 호불호가 갈릴수도 있다고 생각하기때문에 시향을 꼭 해보고 구매하시는 것을 추천드립니다.

그렇다고 힙스터분들처럼 전문적이지는 않으니 큰 기대는 마시고 지극히 제 코에 좋은 남자 향수 5가지를 추천해보고자합니다.

 

제가 탑노트는 어떻고, 미드노트는 어떻고 전문적으로 향을 설명하기에는 배움이 짧기에

어떤 느낌이고 어떤 분들이 잘어울리는지 느낌적인 느낌 위주로 말씀드리도록 하겠습니다.

 


01. 메종 마르지엘라 어텀 바이브

 

 

메종 마르지엘라라는 브랜드를 스티치 갬성쓰로 옷으로는 많이 보셨을거에요. 

'선데이 모닝'이라는 향수가 마르지엘라의 '시그니처' 처럼 많은 분들이 사용하시고는 하는데요.

분명 깨끗하고 좋은 향인데 누군가 뿌렸던 것 같아서 저까지 뿌리고 싶지는 않더라고요.

 

제가 추천하는 마르지엘라 향수는 어텀 바이브라는 향입니다. 

이름에서부터 알 수 있듯이 가을이 연상되는 향이기때문에 사계절 보다는 가을/겨울에 어울리는 향수입니다.

처음에 맡아지는 냄새는 약간 자연 후추?..냄새가 나는데요. 후추 냄새뒤에는 약간 단풍나무 냄새가 부드럽게 나는 느낌이에요.

페퍼향이 처음엔 거부감이 들 수 있는데 시간이 지날수록 세련된 가을향으로 바뀌는 매력적인 향수입니다.

 

이 향수의 정수는 2-3시간 뒤부터 나오는 잔향이라고 확실하게 말씀드릴 수 있습니다.

첫 향만 맡고 절대로 향수를 판단해서는 안돼!!!

 

가격 (100ml 기준)  : 185,000원 

지속력 : 상

추천 계절 : 가을/겨울

별점 : 8/10 (가을-겨울 한정)

잘어울리는 스타일 : 미니멀 / 단정한데 멋부리는 스타일  _ 바라쿠타 자켓이 잘어울릴 것 같음

직업 : 비즈니스 캐주얼 가능한 직장인, 마케터, 작가

떠오르는 연예인 : 서강준, 규현

 

 

 

02. 크리스챤 디올 스파이시 블렌드

 

   

 

두 번째 추천은 크리스챤 디올의 스파이시 블렌드 입니다.

앞서 '어텀 바이브' 와 유사하게 스파이시 우디 계열의 향수인데요.

조향사분이 쿠바 여행을 다니면서 영감을 받아 만든 향수라고 합니다.

그래서 그런지 쿠바 석양을 보면서 마시는 '모히토' 같은 향수 였어요. 

모히토의 상큼함과 함께 시나몬 향기와 후추의 향기가 달콤맵맵하게 느껴지는 매력적인 향수라고 말씀드릴 수 있습니다.

스파이시한 향이 '어텀 바이브'같은 경우 처음에는 조금 튄다는 느낌이 지배적으로 들 수 있는데 스파이시 블렌드는 조화롭게 어울리는 느낌이 들었습니다. 시간이 지나면서 스파이시함보다는 상쾌함과 흑설탕향이 덕분에 부드러운..상큼함이 느껴지는 향수입니다.

 

조화로운 스파이시 우디.

쿠바에서 부드러운 모히또를 상상할 수 있다면 이 향수를 추천합니다.

 

가격 (125ml 기준)  : 410,000원 (비싸긴 함)

지속력 : 중

추천 계절 : 가을/겨울/초봄

별점 : 8/10 

잘어울리는 스타일 : 남친룩, 캐주얼

직업 : 신입 사원, SSF 마케팅팀 주임 느낌 

떠오르는 연예인 : 최우식, 주우재

 

 

03. 바이레도 발 다프리크

 

 

 

니치 향수를 하면 떠오르는 3총사 조말론,딥디크,바이레도에서 바이레도를 맡고있습니다.

바이레도 남자향수라고 하면 '집시워터'같은 걸 떠올리실텐데 제가 추천하는 향수는 발 다프리크입니다.

남자가 뿌리기에는 약간 여성스럽다고 느껴지실 수도 있겠지만 중성적인 매력을 혹은 반전 매력을 보여주는게 또 플러팅 기술아니겠습니까?

 

발 다프리크의 향을 표현하자면,, 몰타 같은 휴양지에서 불어오는 달달한 바람냄새 같다고 할까요?

흔하게 맡아본 향기는 아니지만 그렇다고 너무 낯선 느낌의 향기는 아니에요.

앞서 추천 했던 '어텀바이브' 나 '스파이시 블렌드' 와는 상반되게 오히려 달달하고 깨끗한 냄새가 매력적으로 다가오는 향수입니다.

 

익숙하면서 낯선 오묘한 매력을 가진

깨끗하고 달달상쾌한 향기

 

가격 (100ml 기준)  : 320,000원 

지속력 : 중~상

추천 계절 : 가을/겨울/초봄

별점 : 9/10 

잘어울리는 스타일 : 남친룩, 캐주얼, 어쩌면 슈트

직업 : 외국계 회사 직원, 공항 승무원

떠오르는 연예인 : 옛날 송중기, 아이돌

 

 

말하고 싶은 향수는 아직 서너개가 더 남았지만 

혹시나 반응이 있다면 조금 더 적어보도록 하겠습니다.

 

이만 안녕

 

 

서비스 기획자이면서 '레퍼런스'와 '감'으로만 기획을 하는 사람은 없을 것이라고 생각한다.
(실제로 필자는 콘텐츠 마케터로서 근무했을 당시 플랫폼의 인게이지먼트만 보고 근무를 해봤다. )

최근에는 데이터를 쉽게 확인할 수 있는 툴들을 어렵지않게 찾을 수 있고 규모가 있는 회사라면 관련 인력을 배치하기도 한다.

(우리팀에도 데이터를 뽑아주시는 분이 있는데 항상 고마울따름이다..)

 

오늘은 딱 내가 아는 선에서만 기획자에게 필요한 데이터 능력 3가지를 말해보고자 한다.

 

 

기획자가 데이터를 다룬다는 것은 어떤 의미일까?

: 획득한 데이터를 정재-해석하여 서비스 및 프로젝트에 올바른 의사결정을 하도록 도와주는 수단으로 활용한다.

 

데이터 전문가 혹은 외부에서 획득한 데이터를 분석/활용하여 서비스나 프로젝트의 목표에 도달할 수 있도록

의사결정의 '수단'으로 쓰는 것이 내가 생각하는 기획자의 데이터 활용법이다.(기획자가 데이터 테이블을 설계한다면 더할 나위없이 좋겠지만 나란놈은 아직까지 그럴 역량이 되지 못한다.) 방점은 여기서 '수단' 이라는 것이다. 절대로 데이터를 맹신하지는 말자. 과거의 현상을 보여주는 것이 데이터이지 데이터를 위한 기획을 하는 것이 아니다. 우리는 서비스 및 프로젝트의 목표 달성을 위해 기획한다. 


 

기획자에게 필요한 데이터 능력은 무엇이 있을까?

: 기획자에게 필요한 데이터 능력은 크게는 데이터 분석 / 시각화 / 활용  라고 생각한다.

능력에 관해 간략하게 소개를 해보고자 한다.

1. 데이터 분석 능력

: 기획자는 데이터 분석가 혹은 개발자 등으로부터 얻은 넓고 산발적인 데이터로부터 정재된 인사이트를 뽑을 수 있어야한다.

데이터 리터러시라고 하여 데이터를 이해하고 해석하는 능력이 우선되어야 한다고 생각한다.

통계를 했다면 더욱 데이터를 쉽게 뽑을 수 있겠지만 우리에겐 갓구글이 있기때문에 필요한 함수를,쓰윽 검색해보자,

(이 과정에서 데이터 애널리스트,사이언티스트 분들이 큰 도움이 되신다.. 항상 친하게 지내도록 하자)  

 

개인적으로 내가 데이터를 분석하는 방법은 아래와 같다. (대체로 이런 패턴으로 일한다는 뜻)

 

a. 데이터의 패턴을 분석하고

b. 과거 데이터와 비교하고

c. 시장의 데이터와 비교하고 (가능하다면)

d. 최고/최저/평균 수치를 확인하고

e. 인사이트에 부합하는 수치들을  페이퍼에 인덱스 식으로 정리한다.

 

물론 이런 분석 방법은 실무자 사이에서 서비스 발전을 위해 쓰이며

윗분들은 이런 데이터 분석이 하루정도면 뚝딱 나온다고 생각하는 경우가 종종 있다..

따라서 이런 수치는 최대한 뒤로미루고 앞장에 목표 수치와 예상 수익을 크게,크게 보이게 보고하는 경우가 많다...

 

 

 

2.데이터 시각화

데이터 시각화가 기획자의 큰 역량 차이가 될 것이라고 생각은 한다만 나는 아직 잘 못한다.

ableau, Power BI, matplotlib 등의 도구를 활용할 수도 있지만 우리 서비스는 PPT를 선호하기에 PPT에 

필요한 데이터를 선,막대,원형 차트로 내 최대한의 노력으로 예쁘게 만들어서 보고를 한다.

* 개인적으로 데이터 시각화의 특징은 잘 보이고, 잘 보이고, 잘 보이는 것이라고 생각한다.

내가 강조하고자 하는 숫자를 뽱!! 컬러로 톽!! 잘표현한다면 그것이 시각화이지 않을까 생각한다.

 

 

 

 

3. 데이터 활용 (의사결정, 커뮤니케이션 등)

 

그래 데이터를 잘 분석해서 인사이트도 뽑았고, 시각화도 나름 잘했다면 이제 무엇을 하면 될까?

기획자의 제1덕목 '커뮤니케이션'을 하면 되겠다. 당장 팀내 인원을 설득하고 타부서, 직책에 따라서는 C레벨을 설득하면 되겠다.

앞서 말했듯 데이터는 '수단'일뿐 절대적인 것이 아니다. 그렇기에 "데이터에 답이 있어요!" 라는 태도는 기획자로서 가질 태도는 아니라고 본다. 획득한 데이터로 도출한 결론 혹은 인사이트에 시장 환경과 소비자 반응 등의 추가 데이터로 논리적 근거를 더하고 회사 인력 상황, 사내 자산, 인력 베이스 등 다양한 환경을 빗대어가며 설득이 이루어져야한다.

 

다시 한번 말한다. 데이터는 의사결정을 위한 '수단'이다.

 

 

 

너무 가볍게 다룬 것 같지만 틀린 말은 아닐거라고 생각한다.

다음에는 심화편을 다룰 수 있으면 다뤄보도록 하겠다.

 

'기획 > PM' 카테고리의 다른 글

KPI는 싫지만, KPI를 잘 쓰고 싶다  (0) 2025.04.09

화면기획서는 최대한 자세하게 적는게 좋을까요? 단순하게 핵심만 적는게 좋을까요?

오늘도 가불기 입니다. "환경에 맞춰서" 

저는 기획자는 "자세하게"가 숙련된 후에 "단순하게"로 넘어가는 것이 좋다고 생각이 듭니다.

함께 일했던 개발자/디자이너 분들 역시 가독성이 좋으면 좋겠지만

가독성 이전에 필요한 내용이 다 들어가 있는 것을 더 선호한다고 하시고요.

 

01. 초보 기획자일수록 자세하게 적어보세요.

기획서뿐만아니라 글을 쓸 때는 생각나는 필요한 내용을 전부 적어보고

말의 중복, 선후 관계 등 여러 기준으로 글을 요약하고 줄여가는 과정이 좋은 글을 쓰는 연습이자 경험이라고 생각합니다.

초보 기획자에게 자세하게 적어보라고 말씀드리는 이유는 자세하게 적을수록 기획을 더 깊게 생각하기 쉽기때문이죠.

처음부터 개발자와 호흡 맞춰보지도 않은 상태에서 선배들의 기획서만 참고해서 약식으로 적다보면

생각의 뎁스가 깊어지기 힘들다고 생각해요.

 

그리고 결정적으로 무언가 빠트릴겁니다.

빠트린 부분은 개발자/디자이너가 채워주는 것도 한 두번이지 매번 같은 걸로 반복하면 기획자로서 '신뢰'를 잃고 말아요.

 

저는 그래서 나름의 기획 체크리스트를 작성하고 개발자에게 화면 기획서를 넘기기 전 확인을 하고 넘어가고는 했습니다.

 

 

02. 화면 기획 체크리스트 

아래 체크리스트가 모든 도메인과 모든 기능의 적용되는 것이 아니니 본인 서비스 환경에 맞춰서 필요한 부분은 차용해서 적용해보세요

순서 역시 내용과 무관합니다. 

 

1 정렬 순서 (최신순,인기순,높은가격순,낮은가격순,내림차순,오름차순,가나다순)
2 기능 디폴트값
3 상태 디폴트값
4 액션 전 상태
5 액션 후 상태
6 액션 취소 상태
7 페이지 이동 시 랜딩 페이지 상태
8 페이지 이동 시 화면 ID
9 팝업 정의
10 스크린 문구 정의
11 상태에 따른 액션 정의 ( ~한 경우 A 실행 ) 
12 환경에 따른 액션 정의 (~ 페이지 진입 시 액션A)
13 (필수) / (선택) 사항 기재
14 MO의 경우 액션명 정확히 기재 (롱프레스,더블탭,스와이핑 등)
15 권한에 따른 액션 정의 (사용자에 따른 액션 정의)
16 수정이 이루어진 경우 티커 및 수정 식별이 가능한 마킹
17 공통 정의 경우 공통 정의 넘버
18 클릭 ID
19 버튼 상태 
20 입력 필드 상태
21 컴포넌트 상태 
22 활성화 / 비활성화
23 예외 시나리오 (예외 케이스)
24 기획 히스토리
25 논의가 필요한 사항
26 DB 불러오는 형태 / 저장 형태 (사전에 이야기가 된 부분에만 적용)
27 최대 / 기본 / 최소값 정의
28 0개 일 때 정의
29 타 페이지와 연관 관계
30 정책 내용 일부 (이해도 재고를 위해 필요 시 작성)
31 노출 되는 화면 정의
32 오류 케이스 정의 (예외가 아닌 오류)
33 출력되는 DB 형태 
34 날짜 (YYYY.MM.DD 
35 마스킹 정의
36 글자수 제한
37 프로세스 (필요 시)
38 액션 없는 상태
39 세션 종료 상태
40 쿠키 / 캐쉬 (필요 시)
41 디자인 규격 (필요 시)
42 자동 / 수동 
43 노출 방식 (전환 방식)
44 말줄임
45 백 버튼 정의
46 시스템 팝업 / 시스템 백버튼 (필요 시)
47 컬러 정의
48 이미지 노출 방식
49 개인정보보호 등 법적 특이 사항
50 장차법

 

50개 정도의 체크리스트를 개인적으로 적어보고 일해왔지만 필요한 부분은 더 채워보고 일하시는 것도 좋을 것 같습니다.

 

다음 시간에는 조금 더 디테일한 화면 설계 작성법에 대해 알아보도록 하겠습니다. 

 

그럼 안녕

오늘부터 갓 들어온 신입분에게 설명하는 느낌으로 글을 적어보려고 합니다.

실제로 후배와 사이가 가까워진다면 해당 블로그를 오픈하고 전달할 예정입니다.

 

그만큼 조금은 친밀하고 막연한 말투로 글을 작성할테니 넓은 아량으로 이해부탁드립니다.

 

화면 기획을 시작 할 때. 우리는 상위기획  / IA / 정책서 를 참고합니다. 

앞서 상위기획 / IA / 정책서에 참여했으면 가장 베스트지만 해당 실무를 참여하지 않아도

해당 문서를 참고로 화면 기획을 바로 진행해야할 수도 있습니다.

 

[기획]이라는 분야는 '신뢰'가 중요한 분야라고 거듭 생각이 드는데요.

이해관계자의 '신뢰' 득하기 위해서 체계적으로 화면설계서를 작성할 필요가 있습니다.

일단 적으면서 추가하자는 마인드로 설계를 치다보면 숭숭 뚫린 기획서를 만들 수 있습니다~

이러면 이해관계자의 '신뢰'와 동시에 내 밥벌이도 잃을 수 있겠죠.

 

체계적인 화면 기획의 시작은 01.화면 기획서의 순서 정하기입니다.

 


01. 화면 기획서의 순서

화면기획서의 순서. 기획자마다 스타일이 조금씩은 다를 수 있겠지만

일반적으로 저와 제 동료 기획자들이 써왔던 순서를 말씀드리겠습니다.

오늘은 간단하게 설명드리고 추후에 자세하게 단계마다 설명드리도록 할게요.

 

0. 요약

표지 > 버전 히스토리 > 약식 정책서 > 서비스 구성 기능 요약 > 서비스 주요 프로세스(시나리오) > 공통 영역 > 메인 기획 1 > 서브 기획1 ......

 

1. 표지

버전과 작성자 최종 작성일자를 기입합니다.

SI 업체의 경우 주관부서/유관부서 담당자의 싸인 등을 받고는 합니다.

 

2. 버전 히스토리

보통은 테이블로 작성하고는 하는데요. 

버전 / 작성일자 / 작성자 / 내용 / (비고) 정도 작성하시면 됩니다.

히스토리는 약식으로 간단하게 작성해주시면 되지만 필수로 작성해주어야 하는 중요한 요소입니다.

버전 작성일자 작성자 내용 페이지
3.1 2012.12.12 미어캣 변경된 예외케이스 추가  P12

 

3. 정책서(약식)

전체 정책서를 화면 기획서에 넣을 필요는 없겠죠.

화면 기획서에서는 서비스의 기본적인 용어 합의와 UX합의가 필요한 사항이나 개발 기본 사항이 포함된 정도의 약식 정책서가 포함됩니다.

뭐,,일반적으로느 기능 / 주요 페이지별로 정책서 내용을 발췌해 일단 얹어 놓고는 합니다. 왜냐면...

<<기획에 영원한 건 절대 없어. 결국에 정책도 변했지..>> 정책은 화면 기획 중에도 변경 될 수 있기때문에 앞서 정책의 정석 처럼 픽스를 해놓을 필요는 없다고 생각합니다.

 

4. 서비스 기능 요약

페이지별 기능 및 콘텐츠를 테이블 형태로 단순 기입해놓습니다.

화면 기획이 상세히 작성되지 않은 상태에서 대략적인 기능 배치를 구상해볼 수 있는 페이지고 추후 화면 기획서를 작성하면서 채워가시는 페이지일수도 있습니다.
기능의 상세한 디스크립션이 아닌 정말 기능. 예를 들어 본문 메뉴 - 책갈피 - 설정/해제  딱 이정도 수준의 기능 작성입니다.

해당 페이지가 필수는 아니지만 일단 적어놓으면 기획자 입장에서 화면 기획을 쓸 때 일단 용이합니다.

중복 기능이나 콘텐츠가 있던 페이지로 넘어가서 디스크립션을 복사해올 수도 있고,,, 껄껄

개괄적으로 서비스의 기능을 확인할 수 있어 IA보다는 더 자세한 조망도라고 보실 수도 있습니다. 

IA 혹은 메뉴트리가 전국 특별광역시가 기입된 대한민국 지도라면 해당 페이지는 중대형 소도시가 전부 기입된 지도라고나 할까요.

필수는 아니지만 유용한 페이지 정도라고 생각하시면 될 것 같습니다.

 

5. 주요 프로세스 (시나리오)

서비스의 주요 프로세스를 기입합니다.

세부 프로세스는 각 화면 기획의 앞단에 작성하시고 주요 프로세스 혹은 플로우 차트는 앞서 작성하고는 합니다.

기획서를 처음 읽는 이들에 이해를 돕기 위함이라고나 할까요? 앞선 커뮤니케이션을 위함이라고나 할까요.?

자주 확인해야하는 부분이라 검색의 용이성을 위함이라고나 할까요?... 앞선 배치의 쓰임은 다양합니다.

 

프로세스 작성 방법은 추후 자세하게 다뤄보도록 하겠습니다.

 

6. 공통 영역

공통 영역에 대한 정의가 이루어지는 페이지입니다.

페이지 공통 컴포넌트인 GNB , 하단 네비게이션, 햄버거 버튼 메뉴 등 을 기입하고

입력 필드나 영역 가이드 등을 기입하기도 합니다.

저 같은 경우 공통 팝업이나 스크린 문구 등을 작성해 놓기도 합니다. 

 

TIP. 최대한 공통 요소를 다 정리해 놓으셔야 추후 . 공통00 확인/참고 등으로 디스크립션을 줄일 수 있습니다.

ex) 공통08. 스크린문구_09 출력 등

 

7. 메인/서브 등등.

실제 화면들에 대한 설계가 이루어지는 페이지입니다.

중요도가 높은 순서부터 치는 경우도 있고 IA 설계를 했던 순서대로 내려오는 경우도 있죠.

 


02.  화면 기획서 양식

양식은 회사마다, 도메인 마다 다르게 작성할 수는 있겠지만 저는 사용해오던 양식을 대체로 재활용해서 사용하고는 합니다.

제가 사용하는 양식이 정석은 아닐 수 있으나 적어도 제가 작성한 양식의 내용정도는 들어가야 한다고 참고하시면 될 것 같습니다.

 

아차차 저는 화면기획서의 툴로 figma 와 ppt를 이용하고는 합니다.

(액슈어 같은 경우 분명 화면 기획서를 그리기에는 매우 유용한 툴이라고 생각은 드나 개발자나 디자이너분에게 넘길때 그 분들이 적응하는데 시간이 걸렸기때문에 폭2..)

 

PC / MO 기획서를 나눠서 보여드릴게요.

먼저 PC 웹 기획서 같은 경우 PPT 로 작성한 양식입니다.

 

 

02.1.  PC 기획서

- 기존 기획서에서 내용을 대부분 날리니 빈껍데기가 되었네요. (추후 내용 채우기는 말씀드릴 예정이니 걱정마세요)

뭐 하여튼 전체 화면을 모두 써서 PC화면을 설계한다는 느낌적인 느낌만 참고하시고. 저희는 양식에 집중해보죠.

상단에 [화면명] [화면경로] [화면 ID] 가 보이실까요?

그리고 우측면에 [디스크립션[이 보이실까요?

여기 정보에 걸맞는 화면을 저희는 기획해주시면 되는거에요.

 

화면명 : 화면에 대한 정보 (화면 타이틀)
EX) 로그인 페이지 


화면 경로 : 이 화면에 도달하는 경로
EX) 로그인 -> 약관동의 -> 14세미만 보호자 동의


화면 ID : 화면 ID  

ex) mk_ma_01 = 미어캣_메인_1번페이지

 

 


 

 

02.2. MO 기획서 

모바일 기획서는 조금 더 신경써서 피그마로 그린 기획서를 가져와봤습니다.

양식이랄게 PC / MO 크게 다르지는 않아요. PC화면을 그려놨던 왼쪽 영역에 모바일 화면을 그리면 되는거죠~

 

Page path (화면 경로)

Page ID (화면 ID)

Page Name (화면명)

+

작성일

 

정도로 PC와 동일한 구성을 가지는데 [작성일] 같은 경우 구축보다는 운영 서비스단에서 기입을 하고는 합니다.

운영의 일부 서비스는 변경이 잦다보니 작성일 작성이 필수인 경우도 있어요.

이건 서비스 성격마다 다르니 현재 자신이 맡은 서비스/도메인 성격을 고려해서 양식을 작성해보도록 하세요.

 

 

 

 

오늘은 뭐 사실 화면 기획서의 일반적인 작성 순서와 양식 정도만 말씀드렸습니다.

사실 별거 아니기도 한 내용이지만 시작은 늘 중요한 법이니까요.

사수없이 화면기획서를 그려야하는 일부 기획자입장에서는 이런것도 도움이 될 수 있을 것 같아 글을 적어보았습니다.

다음에는 조금은 더 유익한 내용을 말씀드려보겠습니다.

 

 

그럼 안녕

기획자로 일하다보면 UXUI기획이 주가 아니더라도 당연한 업무처럼 주어지는 것 같다.

사실 정책을 만들고, 로직을 설계하는 일만큼이나 화면 기획을 자주하게 되는 것 같다.

 

오늘은 'UX원칙 UXer를 위한 101가지 원칙' 책에 나온 몇 가지 기초 UX 상식을 적어본다.


1.
06장. 줄임표를 사용해서 다음 단계가 있다는 것을 알려라.

 

유독 IT업계에서는 mac 을 사용하시는 기획자분이 많으신 것 같다.

이전에 마케팅 에이전시에서 근무할 때는 95%가 윈도우 유저였는데 IT업계로 넘어오면서 상당수가 MAC을 사용하시는 것 같다.

MAC 이야기로 시작한 이유는 줄임표를 사용해서 다음 단계가 있다는 것을 알리는 대표적인 예가 MAC의 메뉴이기때문이다.

 

MAC OS의 기본 메뉴바

 

예시 이미지와 같이 '시스템 환경설정....' 'App store...' '재시동...' 등은 기능 선택 후 즉각 기능이 실행되지않고 허브역할을 하거나 완료까지 몇차례 단계가 있다.

우리가 글을 쓸 때 말줄임표는 '하고싶은 말은 더 있지만 이만 줄인다' 라는 용법으로 쓰이고는 하는데 

UX에서 줄임표도 같은 형식으로 쓰일 수 있음을 알 수 있다. 꽤나 그럴싸하고 이해가 가는 UX임에도 불구하고 국내 웹&앱에서는 찾아보기 힘든 케이스이다.

굳이 말줄임표를 쓰는 경우는 콘텐츠에서 말줄이기, 버튼명이 긴 경우 말줄이기 등에서 볼 수 있는데

: 사용자가 직관적으로 몇번의 쓰임으로 이해할 수 있는 UX는 널리쓰이는 게 맞다고 생각한다.


2.
14장. 옵션이 많지 않다면 드롭다운 메뉴를 사용하지 마라.

 

우리가 흔히 자주 사용하는 앱만하더라도 어느정도 완성도가 있어 이런 기본적인 실수를 하지는 않지만

기능이 단순한 쉽게 만들었다 싶은 앱을 몇개만 찾아봐도  드롭다운과 라디오 버튼, 체크박스,토글의 쓰임을 이해하지 못한 경우가 많다.

 

  • 드롭다운 : 일반적으로 드롭다운은 메뉴가 아주 많은 경우에 적합한 컴포넌트이다. EX)국가 선택, 직업 선택
  • 라디오 버튼 : N개 이하의 선택지 중 하나만 선택 하는 경우에 쓰인다. EX) 연령대 선택, 혈액형 선택?
  • 체크박스 : N개 항목의 다중 선택 및 단일 선택을 지원하는 경우에 쓰인다 EX) 취향 선택
    *스포티파이 or 유튜브 뮤직 온보딩 과정에 좋아하는 음악 장르나 가수를 선택하는 화면도 체크박스의 일종이라고 볼 수 있다.
  • 토글 : 두 가지 선택지 중 하나를 선택하는 경우 쓰인다 EX) ON/OFF , 밤/낮

드롭다운 메뉴를 사용하는 경우에는 검색 or 필터 컨트롤을 추가 개발하는 것을 추천하는데 예를 들어 국가를 선택하는 드롭다운 메뉴 시

S를 입력하면 south korea 등의 영역으로 포커스 되는 케이스를 이야기한다.

 

갓 기획자로 처음 진입했을 때 드롭다운 메뉴를 무분별하게 사용한 적이 있었는데 그때 나를 위해 설득하고 고생한 퍼블리셔 분에게 제대로 사과를 하고 싶다.

드롭다운 예시. 모바일의 경우 체크박스나, 라디오버튼으로 6개 이상의 메뉴를 담을 경우 공간을 많이차지하기때문에 통신사를 대게 드롭다운 혹은 모달 팝업으로 처리하는 것 같다.

 


 

3.

25장. 메뉴 항목을 하위 섹션으로 나눠서 사용자가 긴 목록을 기억할 필요가 없게 하라.

 

카테고리’ ‘그룹핑’ 모든 기획 분야에서 중요한 요소이다.

특히 이커머스의 상품카테고리나 금융상품의 항목을 보여줄때는 그룹핑이 매우 중요한데

무역 관공서 웹사이트를 보다보면 상품카테고리 그룹핑이 최소화된 매우 안좋은 예시를 확인할 수 있다.
캡쳐로 첨부한 파일은 빙산의 일각일뿐 물론 저렇게 다양하게 메뉴를 분리한 이유가 있을터이지만 사용성은 매우 최악이라고 할 수 있다.

 

겹치지않도록 최대한 묶어보자. 그룹핑하지 않을 이유는 매우 적다.

 

 

 

책에서 다루는 원칙은 총 101가지

소개하지 못한 여러가지 UX원칙을 시간이 된다면 또 작성해보고자 한다.

 

원칙은 저자의 견해일 뿐. 중요한 건 내 서비스-도메인과 적합한 지 판단해야한다.

기본적인 원칙을 어느정도 따르면서 내 도메인에 대해 깊게 고민하는 기획자가 되고자한다.

+ Recent posts