누구를 위해 만들 것인가?
마케팅 SaaS 개발 과정에서 만나는 모든 관계자를 깊이 있게 분석하기
📑 목차
- 관계자란?
- 관계자 분석의 중요성
- 관계자의 3가지 계층
- 마케팅 SaaS의 모든 관계자
- 관계자 분석의 2단계
- 관계자 분석 방법 1: 사회기술 모형
- 관계자 분석 방법 2: 페르소나 모형
- 최종 정리
1. 관계자란?
정의
"제품/서비스에 직접 또는 간접적으로 영향을 받거나, 영향을 주는 모든 사람"
중요한 개념
관계자 = 사용자가 아닙니다!
❌ 잘못된 생각:
"관계자 = 제품을 직접 사용하는 사람"
이건 너무 좁은 정의입니다.✅ 올바른 생각:
"관계자 = 제품과 관련된 모든 사람"
직접 사용 → 주요 사용자
간접 영향 → 경영진, IT팀, 고객
의사결정 → 구매 담당자
...모두 관계자입니다!마케팅 SaaS의 관계자들
┌─────────────────────────────────────────────┐
│ 마케팅 SaaS의 관계자들 │
├─────────────────────────────────────────────┤
│ │
│ 직접 사용: │
│ • 마케팅 담당자 (신입, 경력) │
│ • 데이터 분석가 │
│ │
│ 간접 영향: │
│ • CEO (캠페인 결과 보는 사람) │
│ • 고객 (이메일 받는 사람) │
│ • 영업팀 (고객 관리) │
│ │
│ 운영/유지보수: │
│ • IT팀 (시스템 관리) │
│ • 보안팀 (데이터 보호) │
│ │
│ 의사결정: │
│ • 경영진 (구매 결정) │
│ • 구매담당자 (예산 관리) │
│ │
└─────────────────────────────────────────────┘2. 관계자 분석의 중요성
관계자 분석이 없을 때
개발팀: "뭐 좋은 기능 추가할까?"
디자이너: "걍 멋있게 만들자"
PM: "일단 빠르게 출시하자"
결과:
❌ 마케팅 신입은 너무 복잡해서 못 씀
❌ CEO는 필요한 리포트 기능이 없음
❌ IT팀은 보안 기능이 없어서 승인 안 함
❌ 고객은 스팸 메일을 자주 받음
→ 누구도 만족하지 않는 제품
→ 개발 비용 낭비
→ 고객 이탈관계자 분석이 있을 때
개발팀: "김지은(신입 마케터)은 초보자인데?"
디자이너: "그럼 UI는 단순해야겠네"
PM: "박준호(팀장)는 고급 기능을 원해"
팀장: "그럼 기본 모드와 고급 모드를 분리하자"
결과:
✅ 신입은 기본 모드로 쉽게 사용
✅ 팀장은 고급 모드로 깊이 있게 분석
✅ CEO는 한눈에 보는 대시보드 제공
✅ 고객은 스팸 필터 기능으로 보호
✅ IT팀은 보안 기능으로 승인
→ 모두가 만족하는 제품
→ 개발 효율성 높음
→ 고객 만족도 높음3. 관계자의 3가지 계층
모든 관계자가 같은 중요도는 아닙니다. 중요도에 따라 3가지로 분류합니다.
1️⃣ 필수 관계자 (Primary Stakeholders)
"제품 없이는 업무가 불가능한 사람"
마케팅 SaaS의 필수 관계자
필수 관계자 A: 마케팅 담당자
왜 필수인가?
• 직접 제품을 사용함
• 제품 없으면 이메일 캠페인을 못 만듦
• 매일 사용함
관계자 수: 회사 내 마케팅팀 전체
(신입 마케터 ~ 팀장)
만족 여부:
만족 → 제품 계속 사용, 입소문, 확대
불만족 → 다른 도구 찾아서 이동, 이탈
영향도: ⭐⭐⭐⭐⭐ (가장 높음)필수 관계자 B: 캠페인 수신자 (고객)
왜 필수인가?
• 이메일을 받는 사람
• 제품의 실제 효과를 느끼는 사람
• 스팸 신고하거나 구독 해제할 수 있음
관계자 수: 매우 많음 (수천~수백만)
만족 여부:
만족 → 계속 오픈, 클릭, 구매
불만족 → 스팸 신고, 구독 해제, 블랙리스트
영향도: ⭐⭐⭐⭐⭐ (매우 높음)2️⃣ 중요 관계자 (Secondary Stakeholders)
"영향을 받거나 중요한 결정을 내리는 사람"
마케팅 SaaS의 중요 관계자
중요 관계자 A: CEO / 경영진
왜 중요한가?
• 제품 구매 의사결정을 함
• 성과를 평가함
• 예산을 결정함
관계자 수: 소수 (1-5명)
일반적인 역할:
• 캠페인 결과 리포트를 받음
• "매출이 얼마나 증가했는가?" 관심
• ROI (투자수익률) 분석
만족 여부:
만족 → 계속 투자, 추가 기능 요청
불만족 → 투자 중단, 제품 폐기, 다른 도구 검토
영향도: ⭐⭐⭐⭐ (높음)중요 관계자 B: IT팀 / 보안팀
왜 중요한가?
• 시스템 안정성 관리
• 보안과 데이터 보호 책임
• 문제 발생 시 서비스 중단 가능
관계자 수: 소수 (2-5명)
일반적인 역할:
• 보안 감시
• 시스템 모니터링
• 데이터 백업
• 규정 준수 확인
만족 여부:
만족 → 승인, 지원 없이 운영
불만족 → 승인 거부, 서비스 중단, 감시 강화
영향도: ⭐⭐⭐⭐ (높음)중요 관계자 C: 데이터 분석가
왜 중요한가?
• 고급 기능 사용
• 캠페인 성과 분석
• 전략 수립에 영향
관계자 수: 중간 (3-10명)
일반적인 역할:
• A/B 테스트 분석
• 고객 세그멘테이션
• ROI 계산
• 예측 모델링
만족 여부:
만족 → 깊이 있는 분석, 전략 개선
불만족 → 수작업 증가, 분석 품질 저하
영향도: ⭐⭐⭐ (중간-높음)3️⃣ 그 후 관계자 (Tertiary Stakeholders)
"간접적인 영향을 받거나 보조적 역할을 하는 사람"
마케팅 SaaS의 그 후 관계자
그 후 관계자 A: 영업팀
역할:
• 마케팅 캠페인 결과로 리드 생성
• 고객에게 제안하는 데 사용
• 고객 데이터 관리
만족도 영향:
중간 (간접적)
예시:
"우리 SaaS로 이메일 캠페인으로
리드를 월 200명 생성하고 있어요"그 후 관계자 B: 고객 성공팀 (CS팀)
역할:
• 사용자 지원
• 문제 해결
• 사용자 교육
만족도 영향:
중간 (사용자 만족도 결정)
예시:
"사용자가 '캠페인 발송 안 되는데요?'라고 물어보면
우리가 해결해줘야 함"4. 마케팅 SaaS의 모든 관계자
전체 관계자 맵
마케팅 SaaS 프로젝트의 모든 관계자
필수 관계자:
├─ 마케팅 담당자
│ ├─ 신입 마케터
│ ├─ 경력 마케터
│ └─ 마케팅 팀장
└─ 캠페인 수신자 (고객)
중요 관계자:
├─ CEO / 경영진
├─ IT팀
├─ 보안팀
└─ 데이터 분석가
그 후 관계자:
├─ 영업팀
├─ CS팀
├─ 구매담당자
└─ 외부 파트너 (이메일 발송 서비스)각 관계자별 최우선 관심사
| 관계자 | 최우선 관심사 | 중요도 |
|---|---|---|
| 신입 마케터 | "쉽게 사용할 수 있나?" | ⭐⭐⭐⭐⭐ |
| 경력 마케터 | "고급 기능이 충분한가?" | ⭐⭐⭐⭐⭐ |
| 데이터 분석가 | "정확한 분석이 가능한가?" | ⭐⭐⭐⭐ |
| CEO | "매출이 증가하는가?" | ⭐⭐⭐⭐ |
| IT팀 | "시스템이 안정적인가?" | ⭐⭐⭐⭐ |
| 고객 | "스팸이 아닌 도움이 되는 이메일인가?" | ⭐⭐⭐⭐⭐ |
| 영업팀 | "리드 생성에 도움이 되나?" | ⭐⭐⭐ |
| CS팀 | "사용자 문제를 빠르게 해결할 수 있나?" | ⭐⭐⭐ |
5. 관계자 분석의 2단계
🔄 Stage 1: 준비 단계 - 관계자를 파악하고 우선순위 정하기
관계자 분석을 시작하기 전에, 누가 있고 누가 제일 중요한지 파악하는 단계입니다.
단계 1) 모든 관계자 파악하기
질문: "이 제품에 영향을 받거나 영향을 주는 사람이 누구인가?"
마케팅 SaaS를 생각해봅시다.
질문 분석:
1. 누가 직접 사용할까?
→ 마케팅 담당자, 데이터 분석가
2. 누가 결과를 볼까?
→ CEO, 영업팀
3. 누가 피해를 입을 수 있을까?
→ 고객 (스팸 받음), IT팀 (시스템 문제)
4. 누가 허락해줘야 할까?
→ CEO (구매), IT팀 (보안), 법무팀 (규정)
5. 누가 운영해야 할까?
→ IT팀, 보안팀
이렇게 모든 각도에서 생각하면
관계자가 하나도 빠지지 않습니다!단계 2) 관계자의 특성 파악하기
각 관계자가 어떤 사람인지, 뭘 원하는지 파악합니다.
신입 마케터 (김지은)
• 나이: 25세
• 경력: 1개월
• 기술 수준: 낮음
• 일일 업무: 이메일 쓰기, 발송
• 근무 시간: 9-18시
특징:
"처음 써봐요. 복잡하면 못 써요"
"실수하는 게 두려워요"
"빨리 배워야 해요"데이터 분석가 (이준호)
• 나이: 32세
• 경력: 8년
• 기술 수준: 높음
• 일일 업무: 분석, 리포트 작성
• 전공: 통계학, 데이터 과학
특징:
"기본 기능은 너무 단순해요"
"복잡한 분석이 필요해요"
"API가 필요해요"CEO (박상훈)
• 나이: 45세
• 경력: 20년
• 관심사: 매출, ROI
• 일일 업무: 경영진 보고, 의사결정
특징:
"결과가 좋아야 해요"
"한눈에 보는 대시보드 필요해요"
"복잡한 기능은 필요 없어요"단계 3) 관계자별 영향도 파악하기
각 관계자가 제품 성공에 얼마나 중요한가?
영향도 평가 기준:
1) 사용 빈도: 매일 사용? 가끔 사용? 안 함?
2) 영향 범위: 누가? 몇 명? 얼마나 오래?
3) 만족도: 불만족하면 뭐가 생기나?
4) 결정권: 이 사람 한 말이 제품 운명을 결정?
신입 마케터 (김지은):
• 사용 빈도: 매일 (높음)
• 영향 범위: 신입들에게 영향 (중간)
• 만족도 영향: 불만족 → 도구 포기, 회사 이동 (높음)
• 결정권: 직접 사용 (높음)
→ 영향도: ⭐⭐⭐⭐⭐ (최우선)
CEO (박상훈):
• 사용 빈도: 주 1-2회 (낮음)
• 영향 범위: 전사 전략 (높음)
• 만족도 영향: 불만족 → 투자 중단 (높음)
• 결정권: 구매 결정 (매우 높음)
→ 영향도: ⭐⭐⭐⭐⭐ (최우선)
영업팀:
• 사용 빈도: 월 1-2회 (낮음)
• 영향 범위: 리드 생성 (중간)
• 만족도 영향: 불만족 → 보조 도구로 사용 (중간)
• 결정권: 직접적 결정권 없음 (낮음)
→ 영향도: ⭐⭐⭐ (보조적)단계 4) 우선순위 정하기
제한된 리소스 내에서 누구를 먼저 만족시킬 것인가?
마케팅 SaaS의 관계자 우선순위:
1순위: 마케팅 담당자 (모두)
이유: 직접 사용자, 없으면 제품 쓸모 없음
2순위: CEO / 경영진
이유: 매출/ROI 중요, 투자 결정권 있음
3순위: IT팀 / 보안팀
이유: 시스템 안정성, 서비스 중단 가능
4순위: 데이터 분석가
이유: 고급 사용자, 깊이 있는 분석 필요
5순위: 고객 (이메일 수신자)
이유: 스팸 방지 필수, 장기 만족도
6순위: 영업팀 / CS팀
이유: 간접적 영향
7순위: 구매담당자 / 외부 파트너
이유: 운영 관련🔍 Stage 2: 분석 단계 - 관계자를 깊이 있게 분석하기
이제 각 관계자를 깊이 있게 분석합니다. 2가지 방법이 있습니다.
6. 관계자 분석 방법 1: 사회기술 모형 (Socio-Technical Model)
핵심 개념
"기술만으로는 부족하다. 사람, 조직, 프로세스를 모두 봐야 한다"
기술이 아무리 좋아도, 그것을 사용하는 사람, 조직의 문화, 업무 프로세스와 맞지 않으면 실패합니다.
4가지 요소
사회기술 모형은 이 4가지를 함께 봅니다:
1. 기술 (Technology)
└─ 시스템의 기술적 능력
2. 사람 (People)
└─ 사용자의 특성과 행동
3. 조직 (Organization)
└─ 회사의 문화와 구조
4. 프로세스 (Process)
└─ 실제 업무 흐름마케팅 SaaS의 사회기술 모형 분석
사례 1: 신입 마케터의 캠프인 발송
❌ 기술만 본 경우의 문제
시스템 설계자의 생각:
"우리 SaaS는 1초에 1,000명에게 이메일 보낼 수 있어요!"
현실:
신입 마케터는 평소에 1일 50명 정도만 보냄
왜?
→ 기술은 충분하지만, 실제 업무에는 필요 없음✅ 사회기술 모형으로 본 경우의 분석
기술 (Technology):
"1초에 1,000명 가능"
평가: ✅ 충분히 우수함
사람 (People):
"신입 마케터는 기술에 약해"
"복잡한 기능 못 씀"
평가: ⚠️ UI가 복잡하면 안 됨
조직 (Organization):
"회사의 마케팅 문화는?"
"일 잘하는 사람도 있고, 그렇지 않은 사람도 있음"
"보안과 준수가 엄격한 편"
평가: ⚠️ 모두를 포용하는 설계 필요
프로세스 (Process):
"실제 업무 흐름은?"
1. 아침 9시: CEO가 "이메일 보내" 지시
2. 10-11시: 콘텐츠 작성
3. 11시-12시: 상사 검수
4. 12시-1시: 오류 수정, 법무팀 확인
5. 1시: 발송
평가: ⚠️ 12시간 안에 끝내야 함
종합 분석:
❌ 기술만 보면: "빠르고 좋은 시스템"
✅ 사회기술 모형으로 보면:
"신입도 쓸 수 있게 UI 단순화 필요"
"단계별 가이드 필요"
"자동 저장 필수"
"검수 기능 강화"
"법무팀 협업 기능 추가"사례 2: CEO의 캠페인 결과 리포팅
❌ 기술만 본 경우의 문제
개발팀: "우리 시스템은 정교한 분석 리포트를 제공해요!"
CEO: "이게 뭐하는 거야?
숫자가 너무 많아서 이해가 안 돼"
CEO가 필요한 것:
"지난 달 캠페인 매출이 얼마나 증가했어?"
(딱 이것만!)
CEO가 받은 것:
- 클릭률: 3.2%
- 열람률: 12.5%
- 구독 해제: 0.1%
- 스팸 신고: 0.01%
- 전환율: 1.8%
- 평균 체류 시간: 2분 3초
... (계속)
결과:
→ CEO는 리포트를 읽지 않음
→ 의사결정 못 함✅ 사회기술 모형으로 본 경우의 분석
기술 (Technology):
"상세한 분석 데이터 제공 가능"
평가: ✅ 기술적으로 우수
사람 (People):
"CEO는 바빠"
"CEO는 숫자 분석을 모름"
"CEO는 '결과'만 봄"
평가: ⚠️ 간단한 리포트 필요
조직 (Organization):
"회사의 의사결정 문화"
"수치로 정당화하는 조직"
"신속한 의사결정"
평가: ⚠️ 한눈에 보는 대시보드 필요
프로세스 (Process):
"CEO의 일일 일정"
1. 아침 회의 (15분)
2. 리포트 확인 (5분!)
3. 의사결정
평가: ⚠️ 5분 안에 이해 가능해야 함
종합 분석:
❌ 기술만 보면: "모든 지표를 세세하게 제공"
✅ 사회기술 모형으로 보면:
"한눈에 보는 CEO 대시보드"
아래 정보만 표시:
- 📈 이번 달 매출 증가: +15%
- 🎯 캠페인 성공률: 8.2%
- 💰 ROI: 3.5배
- ⚠️ 주의: 스팸 신고 증가 추세사례 3: IT팀의 시스템 안정성
❌ 기술만 본 경우의 문제
개발팀: "우리 시스템은 99.9% 가용성을 보장해요!"
IT팀: "그래서 뭐? 어제 3시간 다운됐는데?"
현실:
- 시스템은 안정적
- 하지만 갑자기 트래픽 급증하면 다운
- 보안 업데이트 때문에 불안정
- 데이터 백업 때문에 느려짐✅ 사회기술 모형으로 본 경우의 분석
기술 (Technology):
"가용성: 99.9%"
평가: ✅ 기술적으로 우수
사람 (People):
"IT팀은 24/7 모니터링 중"
"문제 발생 시 책임 전가받음"
평가: ⚠️ 자동 복구, 미리 알림 필수
조직 (Organization):
"IT팀의 직책이 약함"
"문제 발생 시 CEO로부터 압박"
평가: ⚠️ 안정성 최우선 문화
프로세스 (Process):
"IT팀의 일주일"
- 월: 보안 업데이트
- 화: 데이터 백업
- 수: 패치 적용
- 목-금: 모니터링
평가: ⚠️ 언제든 다운될 수 있음
종합 분석:
❌ 기술만 보면: "안정적인 시스템"
✅ 사회기술 모형으로 보면:
"IT팀이 마음 놓을 수 있도록"
- 자동 복구 기능
- 이상 징후 자동 감지
- 실시간 알림
- 무중단 배포 가능
- 재해 복구 계획사회기술 모형의 결론
마케팅 SaaS 설계 시:
❌ 기술만 보고 설계 → 실패
✅ 기술 + 사람 + 조직 + 프로세스를 함께 보고 설계 → 성공
각 관계자별로:
신입 마케터:
기술: 빠른 시스템
사람: 초보자 친화적
조직: 회사 규정 준수 문화
프로세스: 빠른 검수 프로세스
→ "단순하면서도 규정을 지키는 UI"
CEO:
기술: 정확한 분석
사람: 바쁜 일정
조직: 수치 기반 의사결정 문화
프로세스: 5분 안에 판단해야 함
→ "한눈에 보는 대시보드"
IT팀:
기술: 안정적 시스템
사람: 24/7 모니터링 책임
조직: IT팀이 문제 책임
프로세스: 정기적 유지보수
→ "자동 복구, 실시간 모니터링"7. 관계자 분석 방법 2: 페르소나 모형 (Persona Model)
핵심 개념
"관계자를 구체적인 사람으로 만들기"
"신입 마케터" 같은 추상적인 표현보다, 김지은이라는 구체적인 사람으로 만들면 팀 전체가 그 사람을 이해하고 공감합니다.
페르소나 만드는 과정
Step 1: 관계자의 특성 수집 (어떤 사람들?)
신입 마케터 그룹의 공통 특성들:
• 나이: 23-28세
• 성별: 남/녀 모두
• 경력: 0-2년
• 교육: 마케팅 전공/비전공 섞임
• 기술 수준: 낮음 (엑셀 정도만)
• 급여: 초급 연봉
• 근무지: 회사 사무실
• 근무 시간: 9-18시 + 가끔 야근
• 성격: 신중함 (실수 두려움)
• 문제: "이게 뭐하는 건지 모르겠어"
• 기대: "쉬워야 한다"
• 주요 도구: 이메일, 엑셀, PowerPoint
• 급료: 연 2500-3000만원Step 2: 특성을 우선순위별로 정렬
어떤 특성이 제품 사용에 가장 영향을 미치는가?
신입 마케터의 특성 중 행동에 영향을 미치는 순서:
1순위 - 기술 수준 (⭐⭐⭐⭐⭐)
"낮음" → UI 복잡도에 직결
"높음" → 고급 기능 사용 가능
2순위 - 경력 (⭐⭐⭐⭐⭐)
"신입" → 가이드 필수
"경력" → 빠른 실행 중요
3순위 - 성격 (⭐⭐⭐⭐)
"신중함" → 확인 기능 필요
"대담함" → 빠른 액션 가능
4순위 - 일일 업무량 (⭐⭐⭐)
"많음" → 자동화 필요
"적음" → 수동 방식 가능
5순위 - 나이 (⭐⭐)
"젊음" → 신기술 수용 가능
"나이 많음" → 친숙한 방식 원함Step 3: 구체적인 페르소나 작성
이제 실제 "사람"으로 만듭니다.
📌 페르소나 1: 신입 마케터 김지은
╔═══════════════════════════════════════════╗
║ 기본 정보 ║
╚═══════════════════════════════════════════╝
이름: 김지은
나이: 25세
성별: 여성
직급: 마케팅 담당자 (신입)
근무처: 서울 강남역 본사, 마케팅팀
경력: 회사 입사 1개월
연봉: 2,800만원
╔═══════════════════════════════════════════╗
║ 배경 및 경험 ║
╚═══════════════════════════════════════════╝
대학 전공: 국어국문학 (마케팅 비전공)
이전 직업: 마케팅 에이전시 인턴 (3개월)
기술 수준: 낮음 (엑셀 기본만 가능)
사용 경험: 메일, 파워포인트, 구글 검색
진입 동기:
"새로운 직장, 열심히 배워서 좋은 평가 받고 싶어요"
현재 기술 도구:
• 엑셀: 기초 수준 (더하기 정도)
• 이메일: 일반 사용
• 디자인: 못함
• 프로그래밍: 완전히 못함
╔═══════════════════════════════════════════╗
║ 일일 업무 스케줄 ║
╚═══════════════════════════════════════════╝
09:00 - 메일 확인, 팀 회의
"오늘은 뭐 할 일 있나요?"
10:00 - CEO가 보내온 지시
"고객들에게 프로모션 이메일 보내줄래?"
11:00 - 콘텐츠 작성
단어 선택부터 고민
11:30 - 상사에게 검수 요청
"이거 맞나요?"
12:00 - 상사의 피드백 반영
여러 번 왕복
12:30 - "이제 보내도 되나요?"
신중함
13:00 - 발송 (긴장함)
14:00 - "뭔가 문제 없을까?" 불안해함
╔═══════════════════════════════════════════╗
║ 현재 느끼는 문제점 ║
╚═══════════════════════════════════════════╝
1. 도구가 복잡해요
"이 버튼이 뭐하는 거야?"
"이 탭은 왜 있는 거야?"
2. 실수가 두려워요
"내가 뭘 잘못하면 어쩌지?"
"회사에 폐를 끼치면 어쩌지?"
3. 배워야 할 게 너무 많아요
"매뉴얼이 50페이지네?"
"이걸 다 봐야 하나?"
4. 상사가 계속 바꿔요
"아, 근데 이건 다시"
"내가 한 게 쓸모 없네?"
5. 혼자 판단할 수 없어요
"이게 맞나요? 이게 맞나요?"
(계속 확인받음)
╔═══════════════════════════════════════════╗
║ 성공하고 싶은 것들 ║
╚═══════════════════════════════════════════╝
단기 목표 (1개월):
"빨리 도구를 배워서 혼자라도 이메일 보낼 수 있게"
중기 목표 (6개월):
"실수하지 않고, 상사가 만족하는 캠페인 만들기"
장기 목표 (1년):
"마케팅 기초를 다져서 팀에 도움이 되는 사원 되기"
┌─────────────────────────────────────────┐
│ 김지은을 위한 SaaS 설계 원칙 │
├─────────────────────────────────────────┤
│ │
│ 1) UI는 매우 단순하게 │
│ → 3개 탭 이상 금지 │
│ → 필요한 것만 보이기 │
│ │
│ 2) 자동 저장 필수 │
│ → 실수로 나갔을 때 복구 가능 │
│ → "2분 전 저장됨" 표시 │
│ │
│ 3) 가이드 항상 표시 │
│ → 각 단계마다 설명 │
│ → "도움말" 버튼 항상 있음 │
│ │
│ 4) 확인 단계 강화 │
│ → "정말 보낼거야?" 창 │
│ → "이렇게 보내요" 미리보기 │
│ │
│ 5) 실수 방지 │
│ → 취소 버튼은 멀리 배치 │
│ → "삭제한 항목 30일간 보관" │
│ │
│ 6) 성공 경험 │
│ → 발송 후: "성공!" 큰 메시지 │
│ → "다음 캠페인 만들기" 제안 │
│ │
└─────────────────────────────────────────┘📌 페르소나 2: 경력 마케터 박준호
╔═══════════════════════════════════════════╗
║ 기본 정보 ║
╚═══════════════════════════════════════════╝
이름: 박준호
나이: 35세
성별: 남성
직급: 마케팅 팀장
근무처: 서울 강남역 본사, 마케팅팀장
경력: 10년 (마케팅 5회사 경험)
연봉: 7,500만원
╔═══════════════════════════════════════════╗
║ 배경 및 경험 ║
╚═══════════════════════════════════════════╝
대학 전공: 마케팅
이전 직업: 글로벌 IT 회사 마케팅 이사
기술 수준: 높음 (프로그래머는 아니지만 협업 가능)
사용 경험: Salesforce, Google Analytics, Tableau, Python
진입 동기:
"효율적인 마케팅 자동화로 팀의 생산성을 높이고 싶다"
보유 기술:
• SQL: 기본 쿼리 작성 가능
• 데이터 분석: 통계 이해 가능
• API: 프로그래머와 협업 가능
• 대시보드: Tableau로 만들어본 경험
╔═══════════════════════════════════════════╗
║ 일일 업무 스케줄 ║
╚═══════════════════════════════════════════╝
09:00 - 팀 회의, 전략 수립
"어떤 캠페인을 할까? ROI는?"
10:00 - CEO와 분기 목표 논의
"올 분기 목표: 매출 20% 증가"
11:00 - 복잡한 고객 세그멘테이션 설계
"구매액 > 1M이고, 최근 3개월 활동 있는 사람..."
12:00 - 데이터 분석가와 협업
"이 지표가 맞나?" 기술적 논의
14:00 - A/B 테스트 결과 분석
"버전 A 클릭률 5.2% vs B 4.8%"
15:00 - CEO에게 결과 리포트
"이 캠페인으로 매출 15% 증가했어요"
16:00 - 신입 마케터 지도
"지은아, 이건 이렇게 해"
╔═══════════════════════════════════════════╗
║ 현재 느끼는 문제점 ║
╚═══════════════════════════════════════════╝
1. 제한된 기능
"제한된 필터로는 정교한 분석이 안 돼"
"이 데이터를 Excel로 내보내야 하나?"
2. 시간 낭비
"자동화 못 해서 수작업이 너무 많아"
"매번 수동으로 데이터 입력하고 있어"
3. 팀의 성장 한계
"신입들이 쉽게 배울 수 있는 도구 필요"
"고급 기능도 있으면 좋겠는데"
4. 경쟁사 대비
"다른 회사는 AI로 예측 분석하는데 우리는?"
"우리도 고도화되어야 하는데"
╔═══════════════════════════════════════════╗
║ 성공하고 싶은 것들 ║
╚═══════════════════════════════════════════╝
단기 목표 (1개월):
"복잡한 세그멘테이션을 UI에서 직접 할 수 있게"
중기 목표 (6개월):
"자동화로 팀의 수작업을 50% 줄이기"
장기 목표 (1년):
"마케팅 팀이 strategic한 일에만 집중하게"
┌─────────────────────────────────────────┐
│ 박준호를 위한 SaaS 설계 원칙 │
├─────────────────────────────────────────┤
│ │
│ 1) 고급 필터 제공 │
│ → AND, OR, NOT 조건 조합 │
│ → 복잡한 쿼리 가능 │
│ │
│ 2) 자동화 기능 │
│ → 반복되는 작업 자동화 │
│ → 스케줄 설정 가능 │
│ │
│ 3) API 제공 │
│ → 외부 시스템과 연동 │
│ → 커스텀 분석 가능 │
│ │
│ 4) 고급 분석 도구 │
│ → A/B 테스트 통계 분석 │
│ → 예측 모델링 제공 │
│ │
│ 5) 데이터 내보내기 │
│ → CSV, Excel, JSON 지원 │
│ → API로도 데이터 추출 │
│ │
│ 6) 커스텀 리포트 │
│ → CEO용 리포트 자동 생성 │
│ → 스케줄링 가능 │
│ │
└─────────────────────────────────────────┘📌 페르소나 3: CEO 이순신
╔═══════════════════════════════════════════╗
║ 기본 정보 ║
╚═══════════════════════════════════════════╝
이름: 이순신
나이: 45세
성별: 남성
직급: CEO
근무처: 서울 강남역 본사
경력: 20년 (CEO 5년, 마케팅 경험 있음)
연봉: 1억원 + 주식
╔═══════════════════════════════════════════╗
║ 배경 및 경험 ║
╚═══════════════════════════════════════════╝
대학 전공: 경영학
이전 직업: 글로벌 기업 마케팅 이사
성격: 수치 기반 의사결정, 빠른 판단
생활: 매우 바쁨 (회의, 투자자 미팅 등)
기술 수준:
• 개발 못함
• 하지만 기술 개념은 이해
• Excel 기본 사용 가능
• 전략적 사고 최강
╔═══════════════════════════════════════════╗
║ 일일 업무 스케줄 ║
╚═══════════════════════════════════════════╝
09:00 - 경영진 회의 (30분)
회사 전략, KPI 논의
09:30 - 투자자와 통화 (30분)
"이 분기 성장은?"
10:00 - 마케팅팀장 박준호와 미팅 (15분)
"지난 달 매출이 얼마야?"
10:15 - 이사진 회의 (1시간)
재정 상태, 예산 논의
11:30 - 고객 미팅 (1시간)
신규 계약 논의
12:30 - 점심 식사
14:00 - 전략 회의
"다음 분기 목표는 뭘로 할까?"
15:00 - 리포트 검토 (5분!)
마케팅팀의 결과 리포트
15:05 - 의사결정
"좋아, 이 방향으로 가자"
╔═══════════════════════════════════════════╗
║ 현재 느끼는 문제점 ║
╚═══════════════════════════════════════════╝
1. 리포트가 복잡해
"이 숫자가 좋은 건가 나쁜 건가?"
"결론이 뭐야?"
2. 시간이 없어
"상세 분석은 필요 없어. 결론만 줘"
"5분 안에 봐야 해"
3. 신뢰할 수 없어
"이 수치가 정말 맞나?"
"왜 이달은 매출이 떨어졌어?"
4. 투자 ROI 걱정
"마케팅에 이렇게 투자해서 효과 있어?"
"다른 회사는 더 효과 있는데"
╔═══════════════════════════════════════════╗
║ 성공하고 싶은 것들 ║
╚═══════════════════════════════════════════╝
단기 목표 (1개월):
"이 분기 목표 달성 가능한가 한눈에 보기"
중기 목표 (6개월):
"ROI 3배 이상의 마케팅 캠페인 지속"
장기 목표 (1년):
"마케팅이 회사 성장 엔진되기"
┌─────────────────────────────────────────┐
│ 이순신을 위한 SaaS 설계 원칙 │
├─────────────────────────────────────────┤
│ │
│ 1) CEO 대시보드 │
│ → 한눈에 보는 KPI │
│ → 목표 달성 현황 표시 │
│ │
│ 2) 간단한 시각화 │
│ → 숫자 아닌 차트/그래프 │
│ → 직관적으로 이해 가능 │
│ │
│ 3) 주요 지표만 │
│ → 매출 증가: +15% │
│ → 캠페인 성공률: 8.2% │
│ → ROI: 3.5배 │
│ (그 이상은 필요 없음) │
│ │
│ 4) 예측 정보 │
│ → 다음 달 예상 매출 │
│ → 위험 요소 미리 경고 │
│ │
│ 5) 자동 리포트 │
│ → 매주 월요일 아침 발송 │
│ → CEO가 버튼만 누르면 됨 │
│ │
│ 6) 투자 대비 효과 │
│ → "마케팅 비용 vs 매출" │
│ → "경쟁사 대비 우리는?" │
│ │
└─────────────────────────────────────────┘📌 페르소나 4: IT팀 담당자 정훈
╔═══════════════════════════════════════════╗
║ 기본 정보 ║
╚═══════════════════════════════════════════╝
이름: 정훈
나이: 32세
성별: 남성
직급: IT팀 시스템 관리자
근무처: 서울 강남역 본사, IT팀
경력: 8년 (시스템 관리 6년)
연봉: 4,500만원
╔═══════════════════════════════════════════╗
║ 배경 및 경험 ║
╚═══════════════════════════════════════════╝
대학 전공: 전산학
이전 직업: 벤처 회사 DevOps 엔지니어
성격: 꼼꼼하고 신중, 사후 대응보다 예방 선호
기술 스택:
• 서버 관리: AWS, Linux
• 모니터링: DataDog, Prometheus
• 보안: 방화벽, VPN 설정
• 자동화: Shell Script, Ansible
╔═══════════════════════════════════════════╗
║ 일일 업무 스케줄 ║
╚═══════════════════════════════════════════╝
09:00 - 시스템 상태 점검
"어제 문제는 없었나?"
09:30 - 보안 패치 검토
"적용해도 되나?"
10:00 - 사용자 문제 대응
"이메일 안 됐어요" 콜
11:00 - 서버 용량 분석
"트래픽이 이대로면 언제쯤 부족해질까?"
12:00 - 점심
13:00 - 보안 업데이트 적용
(신중하게, 천천히)
14:00 - 데이터 백업 확인
"정말 복구 가능한가?"
15:00 - 모니터링 대시보드 확인
24/7 준비 상태
16:00 - 내일 유지보수 계획
"토요일 새벽 3시 작업 예정"
╔═══════════════════════════════════════════╗
║ 현재 느끼는 문제점 ║
╚═══════════════════════════════════════════╝
1. 언제 다운될지 모름
"마케팅팀이 갑자기 1만 명에게 이메일 보내면?"
"서버 다운되는 건 아닐까?"
2. 지원 요청이 많아
"거의 매일 뭔가 문제가 생겨"
"야간 콜도 많고"
3. 보안 걱정
"고객 정보가 유출되면 큰일인데"
"보안 기능이 부족한 건 아닐까?"
4. 책임만 많아
"문제 생기면 나한테 다 온다"
"개발팀은 뭐하는 건지?"
╔═══════════════════════════════════════════╗
║ 성공하고 싶은 것들 ║
╚═══════════════════════════════════════════╝
단기 목표 (1개월):
"24시간 아무 문제 없이 운영하기"
중기 목표 (6개월):
"자동 복구로 문제 해결 시간 50% 줄이기"
장기 목표 (1년):
"아무도 신경 안 써도 되는 안정적 시스템"
┌─────────────────────────────────────────┐
│ 정훈을 위한 SaaS 설계 원칙 │
├─────────────────────────────────────────┤
│ │
│ 1) 무중단 배포 │
│ → 업데이트 중에도 서비스 운영 │
│ → 사용자가 느끼지 못하게 │
│ │
│ 2) 자동 복구 │
│ → 문제 발생 시 자동으로 대응 │
│ → 정훈이 대응할 필요 없음 │
│ │
│ 3) 실시간 모니터링 │
│ → 문제 예측 (미리 알림) │
│ → 조용한 심야도 안심 │
│ │
│ 4) 용량 관리 │
│ → 자동으로 확장 │
│ → 정훈이 신경 안 써도 됨 │
│ │
│ 5) 분석 접근 정보 보안 │
│ → 권한 기반 접근 제어 │
│ → 감시 로깅 (누가 뭘 했나) │
│ │
│ 6) 깨끗한 문서 │
│ → 문제 발생 시 원인 파악 쉽게 │
│ → 재해 복구 계획 명확 │
│ │
└─────────────────────────────────────────┘페르소나의 힘
페르소나가 있을 때 vs 없을 때
❌ 페르소나 없을 때:
개발팀: "사용자가 뭘 원하는 거야?"
디자이너: "그냥 기능 다 넣자"
PM: "만드는 게 먼저야"
회의 중:
"이 기능은 누가 쓸 건데?"
"글쎄... 누군가는 쓰겠지?"
결과:
→ 누구도 완벽히 만족하지 않는 제품
→ 나중에 수정 비용 2배 이상✅ 페르소나 있을 때:
개발팀: "김지은을 생각해보자"
디자이너: "김지은은 초보자네. UI는 단순해야겠다"
PM: "박준호는 고급 기능이 필요하네"
팀장: "그럼 기본 모드와 고급 모드를 분리하자"
회의 중:
"이 기능은 김지은도 사용할 수 있을까?"
"박준호는 만족할까?"
"정훈은 이 기능 때문에 일이 없어질까?"
결과:
→ 각 페르소나가 만족하는 제품
→ 개발 방향이 명확
→ 나중 수정 최소화8. 최종 정리
📊 마케팅 SaaS의 관계자 전체 구조
마케팅 SaaS의 모든 관계자와 특성
필수 관계자 (Primary):
├─ 신입 마케터 (김지은)
│ ├─ 특징: 기술 낮음, 신중함
│ ├─ 관심: "쉽게 배울 수 있나?"
│ └─ 영향도: ⭐⭐⭐⭐⭐
│
├─ 경력 마케터 (박준호)
│ ├─ 특징: 기술 높음, 효율성 중시
│ ├─ 관심: "깊이 있는 분석이 가능한가?"
│ └─ 영향도: ⭐⭐⭐⭐⭐
│
└─ 캠페인 수신자 (고객)
├─ 특징: 스팸 민감, 신뢰 중요
├─ 관심: "유용한 정보인가?"
└─ 영향도: ⭐⭐⭐⭐⭐
중요 관계자 (Secondary):
├─ CEO (이순신)
│ ├─ 특징: 바쁨, 수치 중심
│ ├─ 관심: "ROI는?"
│ └─ 영향도: ⭐⭐⭐⭐
│
├─ IT팀 (정훈)
│ ├─ 특징: 안정성 중시, 신중함
│ ├─ 관심: "안정적인가?"
│ └─ 영향도: ⭐⭐⭐⭐
│
└─ 데이터 분석가
├─ 특징: 기술 높음, 정밀함 중시
├─ 관심: "정확한 분석이 가능한가?"
└─ 영향도: ⭐⭐⭐
그 후 관계자 (Tertiary):
├─ 영업팀
├─ CS팀
├─ 구매담당자
└─ 외부 파트너🎯 관계자 분석 완료 체크리스트
1단계: 준비 단계
□ 모든 관계자를 파악했는가?
(필수, 중요, 그 후 관계자)
□ 각 관계자의 특성을 정리했는가?
(나이, 경력, 기술 수준, 업무 등)
□ 각 관계자의 관심사를 파악했는가?
(뭐가 가장 중요한가?)
□ 우선순위를 정했는가?
(누구를 먼저 만족시킬 것인가?)
2단계: 분석 단계
□ 사회기술 모형으로 분석했는가?
(기술 + 사람 + 조직 + 프로세스)
□ 페르소나를 만들었는가?
(각 관계자 그룹별로 구체적인 사람)
□ 각 페르소나의 니즈를 정리했는가?
- 일일 업무
- 현재 문제점
- 기대사항
- 성공 목표
□ 각 페르소나를 위한 설계 원칙을 정했는가?
(어떻게 만족시킬 것인가?)
최종 확인
□ 모든 관계자를 동시에 만족시킬 수 있나?
(김지은도, 박준호도, 이순신도...)
□ 우선순위 충돌은 없나?
(한쪽을 만족시키려고 한쪽을 포기하는 건 아닌가?)
□ 설계 방향이 명확한가?
(누가 봐도 이해 가능한 정도)💡 관계자 분석의 효과
관계자 분석을 통해:
✅ 개발 방향이 명확해집니다
- "뭘 만들 것인가?"가 아니라
- "누구를 위해 뭘 만들 것인가?"
✅ 팀 전체가 같은 목표를 봅니다
- 개발팀: "김지은도 사용 가능하게"
- 디자이너: "박준호도 만족하게"
- PM: "이순신도 ROI 달성하게"
✅ 사용자 만족도가 높아집니다
- 각자 다른 니즈가 모두 충족
- 결과: 완성도 높은 제품
✅ 개발 비용과 시간이 줄어듭니다
- 명확한 요구사항
- 후반 수정 최소화
- 효율적인 리소스 배분
🎓 핵심 메시지
"좋은 제품은 좋은 기능만으로는 만들어지지 않습니다."
관계자 분석이 없으면:
- 누군가는 필요하고, 누군가는 필요 없는 기능
- 누군가는 쉽게 쓰고, 누군가는 어렵게 쓰는 UI
- 누군가는 ROI가 있고, 누군가는 없는 결과
관계자 분석이 있으면:
- 모든 관계자가 만족하는 제품
- 각자의 방식으로 성공하는 제품
- 회사 전체의 목표를 달성하는 제품
당신의 마케팅 SaaS가 성공하려면, 개발 전에 충분한 시간을 들여서 모든 관계자를 이해하고, 페르소나를 만들고, 설계 원칙을 정하세요.
그것이 최고의 투자입니다! 🚀
참고:
이 가이드는 실제 프로젝트 경험과 HCI 이론을 바탕으로 작성되었습니다.
당신의 마케팅 SaaS 개발 과정에서 이를 실제로 적용해보세요.
질문이나 추가 상담이 필요하면 언제든지 물어봐주세요! 😊
passionism