오늘 타사 제품에 우리 제품의 핵심 기능과 유사한 기능이 구현된 모습을 보았다. 뭔가 분한 마음도 들었고, 이 기능이 더 이상 우리만의 차별점이 될 수 없다면 앞으로는 무엇으로 경쟁해야 할지 불안하기도 했다. 그러던 중 마침 pxd의 「AX, 차별화보다 해자」라는 글을 발견했다.
차별화는 복제될 수 있지만, 해자는 축적된다
글에서는 차별화와 해자를 구분한다. 차별화는 지금 다른 제품과 구별되어 보이게 만드는 기능이나 경험이다. 새로운 AI 기능을 먼저 제공하는 것도 차별화가 될 수 있다. 하지만 경쟁사 역시 같은 모델과 API를 사용하면 유사한 기능을 빠르게 구현할 수 있다.
반면 해자(Moat)는 경쟁사가 같은 기능을 구현하더라도 쉽게 가져갈 수 없는 구조적인 강점이다. 글에서는 AI 시대의 해자가 기술 자체보다 제품에 축적된 사용자의 데이터, 업무 방식, 의사결정 기준과 같은 맥락에서 만들어진다고 설명한다. 기능은 복제할 수 있지만, 사용자가 제품을 이용하며 쌓아온 맥락까지 한 번에 복제할 수는 없다. 새로운 제품으로 이동했을 때 그동안의 맥락을 다시 학습시켜야 한다면, 그것이 전환 비용이자 해자가 된다.

해자에 관한 이야기는 연초부터 팀에서도 꾸준히 나왔다. 다른 제품이 같은 기능을 만들더라도 사용자가 우리 제품에 남을 이유는 무엇인지, 우리 제품을 사용할수록 무엇이 축적되어야 하는지 여러 번 이야기했다. 그런데 중요성을 몰라서 시작하지 않은 것은 아니었던 것 같다. 문제는 ‘그래서 지금 무엇을 해야 하는가’라는 다음 단계가 잘 그려지지 않았다는 데 있었다.
해자를 경험 설계로 접근하기
특히 ‘사용자의 맥락을 축적한다’는 말을 들으면 자연스럽게 메모리나 데이터베이스 같은 기술적인 구조를 먼저 떠올렸다. 나는 메모리를 구현하는 개발자도 아니고, 데이터가 어떤 형태로 저장되어야 하는지 결정할 사람도 아니다. 그래서 해자를 만드는 일은 개발자가 기술적인 방법을 찾아야 비로소 시작할 수 있는 영역이라고 막연하게 생각했던 것 같다.
그러다 GPT와 대화하던 중 다음 문장을 만났다.
핵심은 개발자가 데이터베이스 구조를 떠올리기 전에, 디자이너가 아래 문장을 만드는 것입니다.
사용자가 [어떤 행동]을 할 때 [어떤 맥락]을 축적하여, 다음번 [어떤 순간]을 더 좋게 만든다.
이 문장을 보고 내가 먼저 고민할 수 있는 영역이 보이기 시작했다. 디자이너가 데이터 저장 구조까지 결정할 필요는 없다. 대신 사용자의 어떤 행동에 중요한 맥락이 담겨 있는지, 그것을 언제 자연스럽게 수집할 수 있는지, 다시 어떤 순간에 돌려줘야 사용자 경험이 좋아지는지를 설계할 수 있다. 예를 들어 사용자의 선택 자체보다 그 선택을 내린 이유가 다음 경험을 더 좋게 만드는 정보일 수 있다. 사용자가 반복해서 수정하는 내용이나 신뢰하지 않는 정보, 여러 결과를 비교할 때 사용하는 기준도 마찬가지다.
개발자는 이것을 어떤 데이터 구조로 저장하고 검색할 수 있는지 판단하고, 디자이너는 무엇을 축적해야 사용자에게 다시 가치가 되는지 정의한다. 해자는 특정 직군이 혼자 떠올려 구현하는 기능이라기보다, 사용자 행동과 기술 구조를 연결하며 함께 설계하는 것에 가까웠다.
막연했던 해자를 제품 위에 올려보기
이 문장을 출발점으로 Claude와 함께 실제 우리 제품을 기준으로 아이디어를 펼쳐보았다.
먼저 사용자가 제품 안에서 어떤 행동을 하는지 살펴보고, 그 순간에 축적할 수 있는 맥락과 다시 활용할 수 있는 순간을 연결했다. 단순히 개인화할 수 있는 기능을 찾는 데서 끝내지 않고, 경쟁사가 같은 기능을 구현해도 그동안 쌓인 맥락까지 가져갈 수 있는지, 사용할수록 결과가 실제로 더 좋아지는지를 함께 살펴봤다.
그렇게 나온 아이디어들을 다음 다섯 가지 기준으로 평가했다.
- 복제 저항: 경쟁사가 같은 기능을 만들어도 축적된 맥락은 가져가기 어려운가?
- 복리성: 사용할수록 데이터와 경험이 쌓이며 더 정확해지는가?
- 재사용 선명도: 축적한 맥락을 다시 돌려주는 순간이 구체적인가?
- 낮은 마찰: 사용자가 원래 하던 행동 안에서 자연스럽게 수집되는가?
- 구현 근접: 현재 제품의 데이터와 화면을 활용해 시작할 수 있는가?
복제 저항과 복리성에는 더 높은 가중치를 두었다. 지금 만들기 쉽다는 이유만으로 높은 우선순위를 주지 않기 위해 구현 근접도의 가중치는 가장 낮게 두었다.
[이미지 1: 순위를 매긴 기준]

이후 평가 결과를 ‘해자의 깊이’와 ‘지금 시작할 수 있는 정도’를 기준으로 지도 위에 배치했다. 점수만으로 순위를 정하기보다, 오래 축적할 가치가 있으면서도 현재 제품 안에서 실험할 수 있는 아이디어가 무엇인지 한눈에 확인하고 싶었다.
[이미지 2: 해자 깊이와 착수 용이도로 정리한 지도]

물론 이 지도에 있는 점수와 순위가 정답은 아니다. 아직 사용자에게 실제 가치가 있는지 확인하지 않았고, 개발 과정에서 발견할 제약도 많다. 하지만 적어도 이전에는 ‘사용자의 맥락을 축적해야 한다’는 문장으로만 존재하던 이야기가, 어떤 행동에서 무엇을 수집하고 언제 돌려줄 것인지 논의할 수 있는 형태가 되었다.
연초부터 팀에서 꾸준히 이야기해왔지만 손에 잡히지 않았던 ‘우리 제품의 해자’가 오늘에서야 조금 실체를 갖게 된 것 같아 좋다. 기능이 복제된 모습을 보고 시작된 불안이, 오히려 우리가 앞으로 무엇을 축적해야 하는지 바라보는 계기가 되었다. 아직 해자를 만든 것은 아니지만, 적어도 어디서부터 삽을 들어야 할지는 처음으로 보이기 시작했다. 굿!
'Learn everyday > Product Design' 카테고리의 다른 글
| [9월 TIL #1] UT 회고: 사용자는 큰 것보다 익숙한 것을 먼저 본다 (0) | 2026.09.01 |
|---|---|
| [8월 TIL #6] UX Writing Skill 제작 회고 (0) | 2026.08.10 |
| [8월 TIL #1] pxd AI 라이팅 어시스턴트 Writone을 알아보며 (0) | 2026.08.03 |
| [7월 TIL #19] 추천 시스템에는 꼭 머신러닝이 필요할까: 규칙 기반 추천으로 시작하기 (0) | 2026.07.30 |
| [7월 TIL #17] 기능의 존재를 어떻게 알릴 것인가: 3가지 기능 노출 패턴 (Implicit, Contextual, Disruptive) (0) | 2026.07.28 |