포지셔닝 전략 STP: 시장 세분화부터 포지셔닝 맵, 전략기획서까지
회사 소개 사이트의 첫 화면에 흔히 이런 문장이 걸립니다. 「고객 중심의 신뢰할 수 있는 파트너」. 이 문장에서 회사 이름을 경쟁사 이름으로 바꿔 넣어 보면 틀린 데가 하나도 없습니다. 어느 회사에 붙여도 맞는 문장이라면, 그 문장은 아무 회사도 설명하지 못합니다.
이런 문장이 나오는 것은 포지셔닝을 「우리를 어떻게 소개할지 정하는 일」로 이해하기 때문입니다. 그렇게 보면 포지셔닝은 카피라이팅의 일이 되고, 좋은 말을 많이 넣을수록 나아 보입니다. 실제로는 반대입니다. 마이클 포터는 HBR에 실은 「What Is Strategy?」(1996)에서 이렇게 썼습니다.
Strategy is making trade-offs in competing. The essence of strategy is choosing what not to do.
전략은 경쟁에서 무언가를 포기하는 선택이다. 전략의 본질은 하지 않을 것을 고르는 데 있다.
웹사이트 기획의 두 번째 단계인 포지셔닝 전략은 이 포기를 처음으로 문서에 적는 단계입니다. 이 글은 그 포기를 어떤 순서로 정하고, 정한 것이 전략기획서의 어느 장까지 내려가는지를 다룹니다.
STP 세 단계가 각각 버리는 것
포지셔닝을 분석할 때 가장 널리 알려진 틀은 STP입니다. 시장을 나누고(Segmentation), 그중 핵심 고객을 고르고(Targeting), 그 고객의 머릿속에서 우리가 차지할 위치를 정합니다(Positioning). 시장을 나눈다는 생각 자체는 웬델 스미스가 1956년 『Journal of Marketing』(21권 1호)에 실은 「Product Differentiation and Market Segmentation as Alternative Marketing Strategies」까지 거슬러 올라갑니다. 지금은 마케팅 교과서마다 실리는 표준 틀이 됐습니다.
STP를 세 칸짜리 양식으로 보면 칸을 채우는 일이 됩니다. 저는 세 단계를 세 번의 포기로 읽는 편이 쓸모 있다고 봅니다.
| 단계 | 하는 일 | 이 단계에서 버리는 것 |
|---|---|---|
| S 시장 세분화 | 고객을 기준에 따라 나눔 | 「모든 고객」이라는 말 |
| T 핵심 고객 선정 | 나눈 고객 중 하나를 고름 | 고르지 않은 나머지 고객 |
| P 포지셔닝 | 고른 고객에게 무엇과 비교될지 정함 | 그 고객이 원하지만 우리가 하지 않을 것 |
이 표에서 마지막 열이 비어 있다면 STP를 한 것이 아니라 시장 조사를 한 번 더 한 것입니다.
시장 세분화 변수 네 가지와 웹사이트에서 쓰는 예
시장을 나누는 기준은 크게 네 가지 변수로 정리됩니다.
| 변수 | 무엇으로 나누나 | 웹사이트 기획에서 쓰는 예 |
|---|---|---|
| 인구통계적 변수 | 나이, 성별, 가구 형태, 소득, 직업 | 「1인 가구」, 「40대 자영업자」 |
| 지리적 변수 | 국가, 지역, 도시 규모, 기후 | 배송 가능 지역, 다국어 지원 범위 |
| 행동적 변수 | 사용 상황, 구매 빈도, 추구하는 이익, 충성도 | 「견적을 오늘 받아야 하는 사람」, 「한 달에 한 번 들르는 기존 고객」 |
| 심리적 변수 | 가치관, 생활 방식, 성격 | 「직접 해 보는 것을 즐기는 사람」, 「시간을 돈으로 사는 사람」 |
넷 중 어느 것이 더 나은 변수라고 정해져 있지는 않습니다. 다만 웹사이트 기획에서 화면 구성을 실제로 바꾸는 것은 대개 행동적 변수라고 저는 봅니다. 같은 30대라도 「견적을 오늘 받아야 하는 사람」과 「내년 예산을 짜려고 시세를 보는 사람」은 첫 화면에서 찾는 것이 다릅니다. 반대로 나이가 달라도 같은 상황에 있는 사람은 같은 버튼을 찾습니다.
고객이 바라는 이익으로 시장을 나누자는 주장은 러셀 헤일리가 1968년 『Journal of Marketing』(32권 3호)에 실은 「Benefit Segmentation」이 대표적입니다. 이 관점은 앞 단계와도 그대로 이어집니다. 현황 분석 편에서 고객을 나이보다 상황으로 먼저 보자고 했는데, 그 상황이 바로 여기의 행동적 변수입니다. 문의 메일과 검색어에서 찾아 둔 상황이 그대로 세분화 기준이 됩니다.
인구통계 변수가 쓸모없다는 뜻은 아닙니다. 인구통계 변수에는 다른 변수에 없는 장점이 하나 있습니다. 공식 통계로 크기를 잴 수 있다는 점입니다. 「평일 밤에 배달로 저녁을 해결하는 사람」이 몇 명인지는 어디에도 나와 있지 않지만, 성별·연령별 1인 가구 수는 KOSIS에서 바로 찾을 수 있습니다.
「혼자 사는 30대 남성」 다음에 한 번 더 좁히는 기준
핵심 고객은 「국내에 혼자 사는 30대 남성」처럼 구체적으로 특정할 수 있습니다. 이 정도로만 좁혀도 「20~40대 직장인」보다는 훨씬 낫습니다. 시장 규모를 통계로 확인할 수 있고, 광고를 어디에 걸지도 정해집니다.
그런데 이 고객을 두고 화면을 설계하려고 하면 금방 막힙니다. 혼자 사는 30대 남성 중에는 매일 요리하는 사람도 있고, 냉장고에 물만 있는 사람도 있습니다. 둘 다 핵심 고객이라고 하면 첫 화면에 무엇을 먼저 보여 줄지 정할 수 없습니다.
그래서 인구통계로 한 번 좁힌 다음, 행동으로 한 번 더 좁힙니다. 1인 가구용 식사 서비스를 기획한다면 이런 식입니다.
혼자 사는 30대 남성 중, 평일 저녁을 주 3회 이상 배달로 해결하고, 배달비가 아깝다고 느끼는 사람
이렇게 쓰면 화면이 정해지기 시작합니다. 첫 화면에는 조리 시간과 한 끼 가격이 먼저 나와야 하고, 레시피의 다양성은 뒤로 밀려도 됩니다. 처음 문장으로는 정할 수 없던 것들입니다.
여러 세분 시장 중 하나를 고를 때는 네 가지를 봅니다. 그 시장이 사업을 유지할 만큼 큰가, 그 고객에게 광고나 검색으로 닿을 수 있는가, 우리가 그 고객이 원하는 것을 경쟁사보다 잘할 수 있는가, 이미 그 고객을 강하게 잡은 경쟁자가 있는가. 앞의 둘은 현황 분석에서 모은 자료로 답하고, 뒤의 둘은 다음에 그릴 포지셔닝 맵으로 확인합니다.
핵심 고객을 하나로 고르는 것이 늘 맞는지는 저도 확신하지 않습니다. 작은 회사가 첫 고객을 하나로 좁히면 매출이 너무 작아질 수 있습니다. 다만 고객이 둘이면 화면을 설계할 때마다 어느 쪽 기준을 따를지 다시 정해야 합니다. 저라면 핵심 고객은 하나로 두고, 두 번째 고객은 「핵심 고객의 화면을 해치지 않는 범위에서만 받는다」고 적어 두겠습니다.
포지셔닝 맵: 두 축을 고르는 순간 정해지는 결론
목표 시장은 축 두 개로 이루어진 그래프 위에 그려 보면 더 분명해집니다. 포지셔닝 맵, 또는 지각도(perceptual map)라고 부르는 그림입니다. 앞의 식사 서비스를 예로 들면, 핵심 고객이 실제로 따지는 「준비 시간」과 「한 끼 가격」을 두 축으로 놓고 고객이 지금 쓰는 대안을 찍어 봅니다.
그림은 설명을 위해 만든 예시이고, 점의 위치는 실제 조사 결과가 아닙니다.
이 그림 한 장에서 두 가지를 볼 수 있습니다. 하나는 우리가 노리는 위치, 곧 「배달 앱보다 싸고 편의점 도시락보다 나은 한 끼를 15분 안에」가 이미 반찬 정기배송과 가깝다는 점입니다. 이 맵이 없으면 「밀키트 시장」 안에서만 경쟁자를 찾기 쉽습니다. 이 예에서 실제 경쟁자는 편의점과 배달 앱입니다.
다른 하나는 오른쪽 위의 빈 칸입니다. 포지셔닝 맵을 처음 그리면 아무도 없는 칸이 반가워 보입니다. 하지만 오래 걸리고 비싼 한 끼는 경쟁자가 놓친 기회가 아니라 원하는 사람이 없어서 비어 있는 칸입니다. 빈 칸을 찾았다면 그 칸을 원하는 고객이 있다는 근거를 현황 분석 자료에서 먼저 찾아야 합니다.
축을 고르는 데도 함정이 있습니다. 축을 회사가 고르면 대개 회사가 잘하는 쪽이 축이 됩니다. 「디자인 감각」과 「기술력」을 축으로 놓으면 그 회사는 늘 오른쪽 위에 찍힙니다. 축은 고객이 고를 때 실제로 따지는 기준이어야 합니다. 그 기준은 인터뷰와 문의 내용에서 고객이 직접 쓴 말에서 가져옵니다. 두 축이 서로 따라 움직이지 않는지도 봐야 합니다. 「가격」과 「품질」처럼 함께 오르내리는 두 축을 놓으면 점들이 대각선에 늘어설 뿐, 두 차원으로 나뉘지 않습니다.
이 그림을 회사 안에서 그린다는 사실도 잊으면 안 됩니다. 알 리스와 잭 트라우트가 1981년에 낸 책의 제목은 『Positioning: The Battle for Your Mind』입니다. 포지셔닝은 고객의 머릿속에서 일어나는 싸움이라는 뜻입니다. 우리가 맵에 찍은 점은 우리의 바람이고, 실제 위치는 고객의 머릿속에 있습니다. 둘이 맞는지는 출시 후 들어오는 문의가 알려 줍니다.
경쟁사 이름을 넣어 보는 포지셔닝 문장 시험
맵에서 위치를 정했다면 그 위치를 한 문장으로 적습니다. 저는 이런 틀을 씁니다.
[핵심 고객]이 [상황]에서 [지금 쓰는 대안] 대신 우리를 고르는 이유는 [우리만 하는 것]이다.
식사 서비스라면 「평일 저녁을 배달로 해결하던 1인 가구 30대 남성이, 배달비가 아까울 때, 배달 앱 대신 우리를 고르는 이유는 15분 안에 배달 앱의 절반 가격으로 한 끼를 해결할 수 있기 때문이다」가 됩니다.
이 문장을 다 쓰면 처음의 시험을 다시 해 봅니다. 회사 이름을 경쟁사 이름으로 바꿔도 문장이 성립하는지 봅니다. 성립한다면 [우리만 하는 것] 칸이 비어 있는 것입니다. 첫 화면 카피는 이 문장을 줄여서 만듭니다. 순서가 거꾸로 되면, 곧 카피를 먼저 쓰고 포지셔닝을 거기에 맞추면 처음의 「고객 중심의 신뢰할 수 있는 파트너」로 돌아갑니다.
전략기획서로 묶을 때 포지셔닝이 정하는 범위
포지셔닝이 끝나면 그 결정을 전략기획서로 묶습니다. 전략기획서는 회사 안의 경영진이 읽는 문서이고, 「어느 시장에서 어떻게 이길 것인가」에 답합니다. 여기에 들어가는 항목은 대개 이렇습니다.
| 항목 | 포지셔닝에서 넘어오는 것 | 답하는 질문 |
|---|---|---|
| 새 콘셉트 | 핵심 고객과 포지셔닝 문장 | 무엇을 새로 만들 것인가 |
| 동종 업계에서 이기는 방법 | 맵에서 고른 위치와 비교 대상 | 누구와 무엇으로 비교될 것인가 |
| 기존 서비스 개선 | 버린 고객 목록 | 무엇을 고치고 무엇은 그대로 둘 것인가 |
| 핵심 역량 | 포지셔닝 문장의 [우리만 하는 것] | 그것이 왜 남들이 따라 하기 어려운가 |
| 수익모델 | 고른 고객의 지불 방식 | 누가 어떤 방식으로 돈을 내는가 |
| 일정 산출 | 첫 출시에 넣을 기능의 범위 | 언제까지 무엇을 내놓는가 |
| 인력 구성 | 핵심 역량을 만드는 데 필요한 사람 | 누가 그 일을 하는가 |
새 콘셉트는 대개 브레인스토밍에서 나옵니다. 브레인스토밍은 많이 내는 것이 목적이라 좋은 아이디어와 우리 포지셔닝에 맞는 아이디어를 구분하지 않습니다. 그래서 나온 아이디어를 포지셔닝 문장에 하나씩 대 봅니다. 핵심 고객의 상황을 해결하지 못하는 아이디어는 아무리 좋아도 이번 기획서에서는 뺍니다.
「동종 업계에서 이기는 방법」과 「기존 서비스 개선」은 비슷해 보이지만 성격이 다릅니다. 포터는 같은 글에서 운영 효율(operational effectiveness)을 전략과 구분했습니다. 경쟁자와 같은 일을 더 잘하는 것은 운영 효율이고, 전략은 경쟁자와 다른 활동을 고르는 것입니다. 기존 서비스 개선은 대개 운영 효율 쪽입니다. 꼭 필요하지만, 경쟁자도 똑같이 할 수 있어서 시간이 지나면 차이가 사라집니다. 기획서에 개선 항목만 가득하다면 포지셔닝이 없는 기획서일 가능성이 큽니다.
핵심 역량은 포지셔닝 문장의 마지막 칸을 뒷받침합니다. 「15분 안에 절반 가격」이 우리만 하는 것이라면, 그 가격을 가능하게 하는 원가 구조나 조리 방식이 핵심 역량입니다. 그것을 설명하지 못하면 문장의 마지막 칸은 바람일 뿐입니다.
수익모델은 핵심 고객이 이미 돈을 내는 방식과 맞아야 합니다. 배달비가 아깝다고 느끼는 사람에게 월 구독료를 먼저 받으면 그 사람이 피하려던 고정비를 하나 더 얹는 셈입니다. 이 고객에게는 한 끼 단위 결제가 맞을 수 있습니다.
AI 도구를 넣은 일정 산출에서 엇갈리는 숫자
일정과 인력 구성은 요즘 기획서에서 가장 자신 있게 틀리기 쉬운 항목입니다. AI 코딩 도구를 쓰면 개발 기간이 얼마나 줄어드는지를 두고 연구 결과가 서로 엇갈리기 때문입니다.
자주 인용되는 숫자는 깃허브 코파일럿 실험입니다. Peng 외 연구진은 2023년 논문 「The Impact of AI on Developer Productivity」에서 개발자들에게 자바스크립트로 HTTP 서버를 구현하게 했습니다. AI 도구를 쓴 쪽이 55.8% 더 빨리 끝냈습니다.
반대 결과도 있습니다. 비영리 연구기관 METR은 2025년 7월 연구에서 대형 오픈소스 프로젝트의 숙련 개발자 16명에게 실제 이슈 246건을 처리하게 했습니다. AI 도구를 쓸 수 있게 했을 때 오히려 19% 더 오래 걸렸습니다. 더 눈여겨볼 대목은 개발자들의 체감입니다. 시작 전에는 24% 빨라질 거라고 예상했고, 끝난 뒤에도 20% 빨라졌다고 믿었습니다.
METR은 2026년 2월 후속 업데이트에서 2025년 말 도구로 다시 측정했습니다. 원래 참가자 10명은 18% 빨라진 것으로, 새로 모집한 참가자는 4% 빨라진 것으로 추정됐습니다. 다만 두 결과 모두 신뢰구간이 0을 포함하고, METR 스스로도 이 데이터가 실제 효과를 재기에는 믿기 어려운 신호라고 밝혔습니다. AI 없이 일하기를 원하지 않는 개발자와 과제가 실험에서 빠졌기 때문입니다. 그러면서도 지금의 개발자가 2025년 초보다 AI로 더 빨라졌을 가능성이 높다고 봤습니다.
세 결과를 나란히 놓으면 일정표에 쓸 수 있는 교훈이 나옵니다. 잘 정의된 새 코드를 짜는 일과, 큰 기존 코드베이스에서 이슈를 고치는 일은 AI의 효과가 다릅니다. 그리고 사람의 체감은 측정과 크게 어긋날 수 있습니다. 그래서 저는 일정표에 「AI로 30% 단축」 같은 할인율을 일괄로 적용하지 않습니다. 대신 일정을 작업 성격별로 나눕니다.
| 구간 | AI 도구의 효과 | 일정 산출 방식 |
|---|---|---|
| 기획·포지셔닝 결정 | 자료 정리는 빨라지지만 결정은 줄지 않음 | 사람 기준으로 잡음 |
| 새 화면·새 기능 구현 | 연구에서 단축 효과가 가장 크게 나온 쪽 | 단축을 반영하되 첫 2주 실측 후 다시 산출 |
| 기존 시스템 수정·연동 | 연구 결과가 엇갈림 | 단축을 반영하지 않음 |
| 검수·테스트 | 만들어진 코드가 많아질수록 오히려 늘 수 있음 | 구현 단축분의 일부를 검수로 옮김 |
마지막 줄은 측정 결과가 아니라 제 판단입니다. AI가 코드를 빨리 만들수록 그 코드를 읽고 확인하는 사람의 시간이 병목이 된다고 봅니다.
인력 구성도 같은 방향으로 바뀝니다. 구현 인력의 비중은 줄일 수 있지만, 그만큼 포지셔닝을 결정하고 지키는 사람, 요구사항을 정확한 문장으로 쓰는 사람, 결과물을 검수하는 사람의 비중은 오히려 커져야 한다고 저는 봅니다. AI는 「무엇을 만들지」가 분명할수록 잘 일합니다. 그 「무엇」을 정하는 것이 바로 이 글에서 다룬 포지셔닝입니다.
전략기획서 마지막 장에 남길 버린 고객 목록
전략기획서의 마지막 장에는 결론 대신 목록 하나를 남기기를 권합니다. 이번에 고르지 않은 고객, 이번에 하지 않기로 한 기능, 그리고 그렇게 정한 이유입니다.
이 목록은 기획서를 쓰는 날에는 쓸모없어 보입니다. 쓸모는 석 달쯤 뒤에 나타납니다. 영업에서 「이런 고객도 받으면 매출이 늘 텐데」라는 말이 나올 때, 개발에서 「이 기능도 넣으면 좋겠다」는 말이 나올 때, 그때 펼쳐 볼 문서가 이 목록입니다. 고른 것만 적힌 기획서는 범위가 늘어나는 것을 막아 주지 못합니다.
포터가 전략의 본질을 하지 않을 것을 고르는 일이라고 한 것은 그래서입니다. 포지셔닝은 무엇을 할지 정하는 단계처럼 보이지만, 나중에 실제로 꺼내 쓰게 되는 것은 하지 않기로 한 것들입니다.
함께 읽기
- 벤치마킹 종류와 경쟁사 분석: 웹사이트 기획에서 비교표를 만드는 방법웹사이트 기획서에는 「레퍼런스 사이트」라는 장이 자주 들어갑니다. 업계 상위 회사 다섯 곳의 첫 화면 캡처가 나란히 붙고, 그 아래에 「참고: 메인 비주얼 구성, 메뉴 구조, 색감」이라고 적힙니다. 이 장을 따라 만든 사이트는 대개 그 다섯 곳과 닮게 됩니다. 그리고 고객은 여섯 개의 비슷한 사이트 중에서 고르게 됩니다.
- 현황 분석 데이터 수집: 가설 하나로 시장조사·설문·FGI 범위를 정하는 법「지피지기면 백전백승」이라는 말은 손자병법에 없습니다. 모공편의 원문은 이렇습니다.
- 개발자가 SA 기획까지 하면 무엇이 달라질까?인쇄기 롤러를 만드는 제조사와 첫 협의를 했을 때 들은 요청은 두 가지였습니다. 견적 단계마다 영업사원이 직접 방문해야 해서 하루에 처리할 수 있는 건수가 막힌다는 것, 그리고 중국어와 독일어 대응이 필요하다는 것이었습니다.
- 테스트와 검수의 차이: 개발의 마지막 단계가 아니라 계약의 기준일정표에서 테스트는 보통 한 칸입니다. 구현 다음, 오픈 앞에 놓인 2주짜리 칸 하나. 그 칸 안에서 개발팀이 버그를 잡고, 같은 칸 안에서 고객이 화면을 눌러 보고, 문제가 없으면 오픈합니다.
- 스토리보드(화면 설계서): 화면이 아니라 상태와 분기를 적는 문서화면 설계서를 받아 보면 대부분 정상 흐름만 그려져 있습니다. 로그인 화면, 목록 화면, 상세 화면, 결제 완료 화면. 그림은 깔끔하고 흐름도 자연스럽습니다.