글로벌 앱 출시 전, 에이전시가 먼저 해야 할 일: 고객 행동 관찰과 가설 설계
목차(6)
한줄 요약
새 시장 진출 시, 기능보다 먼저 고객 행동을 관찰하고 가설을 설계해야 프로젝트가 살아남는다.
본문
고객 행동 관찰(Customer Journey Shadowing)은 사용자의 실제 행동 흐름을 현장에서 추적해 숨겨진 문제를 발견하는 리서치 방법론이다. 에이전시 입장에서 이 방법이 중요한 이유는 단순하다. 클라이언트가 "이 기능을 만들어 달라"고 요청할 때, 그 기능이 실제 사용자 문제를 해결하는지 검증하지 않으면 납품 후 서비스가 외면받는다. 그 책임은 고스란히 에이전시 평판으로 돌아온다.
왜 에이전시가 리서치에 개입해야 하는가
많은 에이전시는 기획은 클라이언트가, 개발은 에이전시가 한다는 역할 분리를 당연하게 여긴다. 그런데 이 구조에는 치명적인 빈틈이 있다. 클라이언트가 넘겨주는 요구사항은 대부분 내부 회의와 경영진 판단에서 나온다. 실제 사용자를 직접 관찰한 결과가 아니다.
특히 새로운 시장, 새로운 타깃 사용자를 대상으로 하는 프로젝트라면 이 빈틈은 더 커진다. 기존 서비스에서 축적한 데이터가 새 시장에서는 참조 불가 수준으로 맥락이 다르기 때문이다. 동일한 기능이라도 사용자의 생활 방식, 디지털 습관, 문화적 기준이 다르면 완전히 다른 반응이 나온다.
에이전시가 단순 개발 용역사가 아니라 기술 파트너로 포지셔닝하려면, 기능 구현 이전에 "무엇을 만들어야 하는가"를 함께 정의하는 역할을 맡아야 한다. 고객 행동 관찰은 그 출발점이다.
고객 여정 관찰, 실제로 어떻게 적용하는가
프로세스 자체는 복잡하지 않다. 리서치 목표 설정 → 관찰 대상 정의 → 여정 단계 구성 → 현장 관찰 → 인사이트 도출 순서로 진행된다. 에이전시 맥락에서 핵심은 세 번째 단계, 즉 여정 단계를 어떻게 쪼개느냐에 있다.
예를 들어 배달 플랫폼 앱을 특정 지역 시장에 처음 출시하는 프로젝트라면, 여정을 '음식 탐색 → 가게 선택 → 메뉴 결정 → 결제 → 배달 대기 → 수령'으로 나눌 수 있다. 이 각 단계에서 사용자가 실제로 어떤 행동을 하는지, 어디서 멈추는지, 어떤 외부 도구(메신저, 검색, 주변인 추천 등)를 병행하는지를 관찰한다.
인터뷰로는 잡히지 않는 게 여기서 나온다. 사용자는 "리뷰를 꼭 본다"고 말하지만 실제로는 가게 이름만 보고 주문하거나, "앱이 편하다"고 말하면서 결제 직전에 이탈하는 패턴이 드러난다. 이 괴리가 바로 설계가 놓친 문제다.
관찰 결과를 가설로 전환하는 기준
관찰 자체는 데이터일 뿐이다. 에이전시가 클라이언트에게 가져가야 할 건 관찰 결과가 아니라, 그것을 기반으로 설계한 검증 가능한 가설이다.
가설의 품질을 판단하는 기준은 PMF(Product-Market Fit) 관점에서의 유의미성이다. 쉽게 말해, 이 가설을 검증했을 때 기능 우선순위나 서비스 방향이 바뀔 수 있는가를 따져야 한다. 바뀌지 않는다면 검증할 가치가 낮다.
구체적인 예를 들면, 관찰을 통해 '사용자가 결제 단계에서 앱을 이탈하고 다른 결제 수단으로 전환한다'는 행동 패턴을 발견했다고 하자. 이때 단순히 "결제 UI를 개선해야 한다"는 결론을 내리는 건 너무 이르다. 대신 "사용자는 앱 내 결제보다 이미 익숙한 외부 결제 수단을 신뢰하기 때문에, 외부 결제 연동을 기본 옵션으로 올리면 결제 전환율이 상승할 것이다"라는 형태로 가설을 구체화해야 한다. 그래야 A/B 테스트나 사용성 테스트로 검증 설계가 가능해진다.
에이전시가 이 방법론으로 얻는 실질적 이점
고객 행동 관찰을 프로젝트 초기에 도입하면 에이전시는 세 가지를 얻는다.
첫째, 요구사항 번복 리스크가 줄어든다. 클라이언트가 개발 중반에 방향을 바꾸는 가장 큰 이유는 "실제 사용자 반응이 예상과 달랐다"는 것이다. 관찰 기반 가설 설계는 이 리스크를 사전에 차단한다.
둘째, 납품 후 서비스 성과가 올라간다. 에이전시의 장기 레퍼런스와 재계약률은 결국 "우리가 만든 서비스가 잘 됐는가"에 달려 있다. 기능 완성도와 서비스 성과는 다른 문제다.
셋째, 클라이언트와의 대화 수준이 달라진다. "요청하신 기능을 구현했습니다"가 아니라 "이 가설을 기반으로 설계했고, 이렇게 검증할 수 있습니다"로 커뮤니케이션이 바뀐다. 이게 단순 외주사와 전략 파트너의 차이다.
자주 묻는 질문
Q.고객 행동 관찰은 대형 프로젝트에서만 가능한 것 아닌가요?
그렇지 않다. 규모보다 중요한 건 관찰의 밀도다. 사용자 5~10명의 행동을 구조적으로 관찰하고 기록해도 의미 있는 인사이트가 나온다. 오히려 초기 스타트업이나 중소 규모 프로젝트일수록, 잘못된 방향으로 개발 리소스를 쓰는 비용이 크기 때문에 초반에 작은 규모로라도 관찰을 도입하는 게 낫다. 비용 문제라면 현장 관찰 대신 사용자 화면 녹화나 행동 로그 분석으로 대체 가능한 부분도 있다.
Q.클라이언트가 리서치 비용을 따로 지불하려 하지 않으면 어떻게 하나요?
리서치를 별도 비용 항목으로 제안하기 어렵다면, 기획 단계 공수에 포함시키거나 킥오프 워크숍 형태로 구조화하는 방법이 있다. 핵심은 클라이언트에게 리서치의 ROI를 설명하는 것이다. "개발 후 방향을 바꾸는 비용"과 "개발 전 가설을 검증하는 비용"을 비교하면 설득력이 생긴다. 실제로 방향 번복이 한 번만 줄어도 리서치 비용은 충분히 회수된다.
Q.관찰한 행동 데이터를 가설로 바꾸는 과정에서 가장 흔한 실수는 무엇인가요?
가장 흔한 실수는 관찰한 현상을 그대로 솔루션으로 연결하는 것이다. 예를 들어 "사용자가 특정 버튼을 못 찾는다"는 관찰에서 곧바로 "버튼을 크게 만들자"로 가는 경우다. 이렇게 하면 표면만 건드린다. 가설은 반드시 '왜 그 행동이 발생하는가'라는 원인 분석을 거쳐야 하고, 그 원인에 대한 해결 방향이 실제 사용 패턴을 바꿀 수 있는지를 검증 지표와 함께 설계해야 한다.