복제당해도 살아남는 에이전트의 조건
복제당해도 살아남는 에이전트의 조건
경쟁사가 당신의 에이전트를 복제했다. 프롬프트도 같고, 모델도 같고, 기능도 같다. 그런데 사용자가 안 떠났다. 왜?
1. 복제를 막는 건 질문이 아니다
에이전트 시장에서 프롬프트 복제는 놀라울 정도로 쉽다. 시스템 프롬프트를 추출하는 기법은 이미 널리 알려져 있고, 같은 모델 API를 호출하는 데 진입장벽이란 없다. 경쟁사가 당신의 에이전트를 분석하고, 비슷한 프롬프트를 작성하고, 동일한 모델 위에 올리는 데 걸리는 시간은 길어야 며칠이다. 기능 하나를 출시하면 2주 안에 비슷한 것이 세 개는 나온다.
그래서 많은 사람이 “어떻게 복제를 막을까”를 고민한다. 프롬프트를 암호화하거나, 독점 모델을 파인튜닝하거나, 특허를 걸거나. 하지만 이 질문 자체가 함정이다. 방어벽을 세우는 데 드는 에너지는 크고, 그 벽은 결국 뚫린다. 소프트웨어 역사가 반복적으로 증명해온 사실이다 — 기능은 복제된다.
진짜 질문은 다른 데 있다. “복제를 어떻게 막을까”가 아니라, **“복제된 후에도 왜 사용자가 남아 있는가”**다.
기능 차별화가 해자(moat)가 될 수 없는 이유는 단순하다. 에이전트의 기능이란 결국 프롬프트와 모델과 도구 호출의 조합이고, 이 세 가지는 모두 공개된 재료다. ChatGPT 플러그인이 나왔을 때, 수백 개의 “PDF 요약 에이전트”가 쏟아졌다. 기능은 동일했다. 살아남은 것과 사라진 것의 차이는 기능이 아니었다.
그렇다면 무엇이 차이를 만드는가? 복제품과 원본 사이에 사용자가 체감하는 간극은 어디서 오는가? 이 글은 그 구조를 파고든다. 결론을 먼저 말하자면 이렇다 — 복제를 막으려 하지 마라. 복제해도 소용없는 구조를 만들어라.
2. “이미 나한테 맞춰져 있으니까”
단골 카페가 있다. 문을 열면 바리스타가 고개를 들고 “오늘도 아이스 아메리카노요?”라고 묻는다. 나는 고개만 끄덕이면 된다. 메뉴판을 볼 필요도, 사이즈를 말할 필요도, 얼음 양을 설명할 필요도 없다. 그 한마디가 줄여주는 건 5초의 시간이 아니다. “여기는 나를 아는 곳”이라는 감각이다.
어느 날 집 앞에 새 카페가 열었다고 해보자. 인테리어도 깔끔하고, 원두도 같은 브랜드고, 가격도 비슷하다. 메뉴판은 사실상 동일하다. 그런데 막상 가보면 미묘하게 불편하다. 내가 원하는 걸 처음부터 설명해야 한다. “아이스 아메리카노, 톨 사이즈, 얼음 적게요.” 틀린 건 아니다. 다만 이걸 매번 반복해야 한다는 사실이 피로감이 된다. 결국 발길은 단골집으로 돌아간다. 커피 맛이 더 좋아서가 아니라, 거기가 더 편해서.
에이전트에서도 정확히 같은 일이 일어난다.
경쟁사가 당신의 에이전트를 복제했다. 프롬프트 구조도 가져왔고, 동일한 모델을 쓰고, 기능 목록도 빠짐없이 맞췄다. 겉으로 보면 구별이 안 된다. 그런데 사용자가 실제로 써보면 뭔가 다르다. 원본 에이전트는 내가 코드 리뷰를 요청하면 diff 형식으로 핵심만 짚어줬는데, 복제품은 장황한 설명부터 시작한다. 원본은 내가 “짧게”라고 말하지 않아도 이미 짧게 답하는 법을 알고 있었다. 복제품은 모른다.
이 차이는 프롬프트에서 오지 않는다. 맥락의 축적에서 온다.
에이전트가 사용자와 상호작용하면서 쌓이는 것들이 있다. 이 사용자는 bullet point를 선호하는지 문장형을 선호하는지. 설명이 길면 짜증을 내는지, 상세할수록 좋아하는지. 코드를 줄 때 주석을 원하는지, 깔끔한 코드만 원하는지. 이런 것들은 명시적으로 프롬프트에 적히지 않는다. 사용자 본인도 자기 선호를 정확히 설명하지 못한다. 하지만 쓰다 보면 에이전트 쪽에 그 패턴이 쌓인다.
Claude Code를 예로 들어보자. 처음 쓸 때는 내가 일일이 지시해야 했다. “한국어로 답해줘”, “파일 전체를 보여주지 말고 수정할 부분만 보여줘”, “커밋 메시지는 영어로.” 한 달쯤 지나니 CLAUDE.md에 이런 선호들이 정리되어 있었고, 에이전트는 내가 말하기 전에 이미 내 방식대로 움직였다. 누군가 내 CLAUDE.md를 복사해 갈 수는 있다. 하지만 그 파일이 만들어지기까지의 시행착오 — 내가 “이건 아니야”라고 수정하고, “이게 낫다”라고 확인해준 수십 번의 피드백 — 는 가져갈 수 없다. 파일은 복제되지만, 그 파일이 나에게 맞는 이유는 복제되지 않는다.
이것이 첫 번째 해자의 핵심이다. 프롬프트는 복제 가능하지만, 맥락은 복제 불가능하다.
맥락이란 단순히 “사용자 프로필”같은 정적 데이터가 아니다. 살아 있는 적응의 기록이다. 이 사용자가 지난주에 어떤 실수를 했고 이번 주에는 뭘 더 확인해줘야 하는지, 특정 라이브러리를 쓸 때 반복하는 패턴이 있어서 비슷한 요청에 그걸 먼저 제안해야 하는지. 이런 맥락은 시간이 흘러야 쌓이고, 상호작용을 통해서만 형성된다. 경쟁사가 코드를 통째로 가져가도, 이 부분은 빈 칸으로 남는다.
새 에이전트는 나를 모른다. 똑같은 엔진을 달고 있어도, 나를 모르는 도구는 범용적으로 행동할 수밖에 없다. 범용적이라는 건 틀리지 않는다는 뜻이지만, 딱 맞지도 않는다는 뜻이다. 사용자가 “이건 내 도구”라고 느끼는 순간은, 틀리지 않을 때가 아니라 딱 맞을 때다.
결국 사용자가 떠나지 않는 첫 번째 이유는 단순하다. 떠날 이유가 없어서가 아니라, 다시 설명하기 귀찮아서. 새 에이전트에게 나를 처음부터 가르치는 비용 — switching cost — 이 생각보다 크다. 그리고 이 비용은 원본을 오래 쓸수록 커진다. 시간이 해자가 된다.
3. 피드백 플라이휠 — 시간이 만드는 해자
앞에서 맥락이 복제 불가능하다는 것을 확인했다. 그렇다면 그 맥락은 대체 어떻게 쌓이는가? 저절로 생기는 게 아니다. 거기에는 구조가 있다. 그 구조를 flywheel이라 부른다.
플라이휠의 루프는 단순하다. 에이전트가 출력을 낸다 → 사용자가 반응한다(수정, 승인, 혹은 무시) → 에이전트가 그 반응에서 패턴을 학습한다 → 다음 출력이 개선된다. 이 사이클이 한 바퀴 돌 때마다 에이전트는 조금씩 더 정확해지고, 사용자는 조금씩 더 적게 설명하게 된다. 바퀴가 빨라질수록 마찰은 줄어든다. 이것이 flywheel이 “관성”을 가진다고 말하는 이유다.
여기서 흔히 혼동되는 개념이 있다. 대화 히스토리와 피드백 플라이휠은 다르다. 대화 히스토리는 세션에 묶여 있다. 창을 닫으면 끝이다. 다음에 새 대화를 열면 에이전트는 다시 백지 상태가 된다. 반면 플라이휠이 만들어내는 축적은 세션을 넘어 존재한다. 어제의 피드백이 오늘의 출력을 바꾸고, 지난달의 실패 패턴이 이번 달의 판단을 교정한다. 히스토리가 단기 기억이라면, 플라이휠이 쌓는 것은 장기 기억이다.
구체적으로 이 축적은 어떤 형태를 띠는가? 사용자별 선호 모델이 있다 — 이 사람은 간결한 답을 좋아하고, 저 사람은 근거를 함께 보고 싶어 한다. 도메인 판단 이력이 있다 — 이 코드베이스에서는 ORM 대신 raw SQL을 쓰는 것이 팀 컨벤션이고, 에러 처리는 항상 early return 패턴을 따른다. 실패와 성공의 패턴 DB가 있다 — 지난번에 이 접근으로 테스트가 깨졌고, 저번에는 이 방식으로 리뷰를 통과했다. 이것들이 모이면 단순한 “설정”이 아니라 하나의 프로파일이 된다. 그 사용자, 그 팀, 그 도메인에 최적화된 판단 체계.
세 가지 사례로 이 구조가 실제로 어떻게 작동하는지 살펴보자.
Claude Code의 memory. “테스트 코드에서 DB를 목킹하지 마, 실제 테스트 DB를 사용해”라고 한번 말한다. 그러면 이후 모든 세션에서 에이전트는 테스트를 작성할 때 실제 DB 연결을 기본값으로 삼는다. 한번 더 말할 필요가 없다. 여기에 “커밋 메시지는 영어로”, “TypeScript strict 모드 기준으로 타입 체크해줘”, “PR 설명에는 변경 이유를 먼저 써줘” 같은 피드백이 하나둘 쌓인다. 수백 개가 되면 그것은 더 이상 설정 파일이 아니다. 그 사용자만의 개발 스타일 프로파일이다. 코드를 어떻게 구조화하는지, 어떤 패턴을 싫어하는지, 리뷰에서 무엇을 중요하게 보는지까지 담긴다. 새 경쟁 도구가 나와서 “저희도 memory 기능 있어요”라고 말할 수 있다. 기능은 같을 수 있다. 하지만 빈 memory와 6개월치 피드백이 축적된 memory는 전혀 다른 물건이다.
Spotify의 Discover Weekly. 매주 월요일, Spotify는 사용자별로 30곡의 플레이리스트를 만들어준다. 추천 알고리즘 자체는 논문으로 공개되어 있고, 비슷한 collaborative filtering을 구현하는 건 어렵지 않다. 실제로 Apple Music, YouTube Music, Tidal 모두 유사한 추천 기능을 갖고 있다. 그런데 Spotify에서 다른 서비스로 옮긴 사람들이 공통적으로 하는 말이 있다. “추천이 너무 뻔해졌다.” 알고리즘이 나빠서가 아니다. 7년 넘게 축적된 청취 이력 — 어떤 곡을 30초 만에 스킵했고, 어떤 곡을 반복 재생했고, 어떤 장르를 금요일 밤에만 듣는지 — 이 데이터가 없기 때문이다. 새 서비스의 추천은 “신입 수준”으로 리셋된다. 기술은 복제할 수 있지만, 시간이 만든 데이터는 복제할 수 없다.
GitHub Copilot의 코드베이스 학습. 팀이 6개월간 Copilot을 쓰면서 쌓인 것들이 있다. 이 레포에서는 axios 대신 ky를 쓴다는 것, 에러 타입은 항상 커스텀 AppError 클래스를 상속한다는 것, 테스트 파일 네이밍은 *.spec.ts가 아니라 *.test.ts라는 것. Copilot은 코드베이스의 패턴과 팀 컨벤션을 학습한 상태에서 제안을 내놓는다. 이제 경쟁 도구가 등장해서 “코드 자동완성 정확도 95%“를 주장한다고 해보자. 팀이 실제로 전환해 보면, 제안되는 코드가 미묘하게 팀 스타일과 맞지 않는다. axios를 import하고, Error를 직접 throw하고, 파일명을 .spec.ts로 만든다. 하나하나 고칠 수는 있다. 하지만 이 교정을 또 6개월간 해야 한다는 사실이 전환을 주저하게 만든다. 기능의 우열이 아니라, 축적의 차이가 사용자를 붙잡는다.
세 사례의 공통점이 보인다. Claude Code는 개인 개발자의 스타일을, Spotify는 소비자의 취향을, Copilot은 팀의 컨벤션을 축적한다. 도메인은 다르지만 구조는 동일하다. 출력 → 반응 → 학습 → 개선, 이 루프가 반복될수록 대체 비용은 올라간다.
경쟁사가 오늘 같은 걸 만들어도, 6개월치 축적 데이터는 돈으로 살 수 없다. 서버를 더 사도, 모델을 더 크게 해도, 엔지니어를 더 뽑아도, 시간을 압축하는 방법은 없다. 플라이휠은 느리게 시작하지만 한번 돌기 시작하면 점점 빨라지고, 그 관성 자체가 해자가 된다. 기능은 하룻밤에 복제되지만, 플라이휠이 만든 관성은 하룻밤에 복제되지 않는다.
4. 깊은 통합 — 교체의 고통이 만드는 해자
플라이휠이 “시간”이 만드는 해자라면, 여기서 이야기할 것은 “깊이”가 만드는 해자다. 성격이 다르다. 시간의 해자는 축적이 만들고, 깊이의 해자는 연결이 만든다.
에이전트가 하나의 도구(tool)로 존재할 때를 생각해보자. 채팅창에 질문을 넣으면 답이 나온다. 유용하다. 그런데 어느 날 더 좋은 에이전트가 나타났다. 뭘 해야 하는가? 북마크를 바꾸면 된다. 기존 채팅창을 닫고, 새 채팅창을 연다. 끝이다. 교체 비용은 거의 제로에 가깝다. 데이터도 없고, 연결도 없고, 끊어야 할 것이 없으니까. 도구는 독립적으로 존재하고, 독립적으로 교체된다.
이제 다른 상황을 상상해보자. 에이전트가 더 이상 채팅창이 아니다. 워크플로우의 **연결 조직(connective tissue)**이 되어 있다.
구체적인 시나리오가 있다. 팀원이 Slack에 메시지를 남긴다 — “결제 모듈에서 타임아웃 에러가 간헐적으로 발생합니다.” 에이전트가 이 메시지를 감지한다. 내용을 파싱해서 Jira에 버그 티켓을 자동 생성한다. 우선순위는 과거 유사 이슈의 패턴을 보고 P2로 설정한다. 관련 코드 영역을 식별해서 담당 개발자에게 코드 리뷰를 트리거한다. 개발자가 수정 PR을 올리면, 에이전트가 변경 사항을 요약하고 테스트 결과와 함께 원래 Slack 스레드에 회신한다 — “수정 완료. 타임아웃 임계값을 3초에서 10초로 조정. 테스트 통과.” 이 흐름은 하나의 기능이 아니다. Slack, Jira, GitHub, CI/CD를 관통하는 하나의 파이프라인이다. 에이전트는 그 파이프라인의 중심에서 각 시스템을 이어붙이는 접착제(glue) 역할을 한다.
이 상태에서 “더 좋은 에이전트”가 나타났다고 해보자. 자연어 이해 능력이 20% 더 뛰어나고, 응답 속도가 2배 빠르다. 교체하고 싶다. 그런데 교체하려면 무엇을 해야 하는가? Slack 연동을 새로 설정해야 한다. Jira 프로젝트별 티켓 생성 규칙을 다시 정의해야 한다. 코드 리뷰 트리거 조건을 옮겨야 한다. CI/CD 파이프라인과의 연결을 재구성해야 한다. 알림 채널과 멘션 규칙을 다시 매핑해야 한다. 그리고 이 모든 것이 기존처럼 매끄럽게 돌아가는지 검증해야 한다. 검증 기간 동안 팀의 워크플로우는 불안정해진다. 티켓이 누락되고, 알림이 엉뚱한 곳으로 가고, 리뷰가 트리거되지 않는 빈틈이 생긴다.
교체의 대가가 “불편함” 수준이 아니라 “업무 마비” 수준이 된다. 그래서 안 옮긴다. 20% 더 똑똑한 에이전트가 있어도, 이미 네 개의 시스템을 관통하며 팀의 일상을 지탱하고 있는 접착제를 뜯어내는 고통이 더 크기 때문이다.
여기서 도구(tool)와 접착제(glue)의 차이가 선명해진다. 도구는 한 지점에서 가치를 만든다. “질문하면 답한다”, “코드를 넣으면 리뷰한다.” 접착제는 지점과 지점 사이에서 가치를 만든다. 시스템 A의 출력을 시스템 B의 입력으로 변환하고, 그 결과를 시스템 C에 전달한다. 도구의 가치는 그 도구 자체의 품질에 달려 있지만, 접착제의 가치는 연결된 시스템의 수와 깊이에 달려 있다. 도구는 더 좋은 도구가 나오면 교체된다. 접착제는 더 좋은 접착제가 나와도 떼어내기가 어렵다 — 붙어 있는 면적이 너무 넓으니까.
그래서 에이전트 제품을 만드는 사람에게 해줄 수 있는 가장 실용적인 조언은 이것이다. 기능이 아니라 접착제(glue)를 만들어라. 하나의 일을 잘하는 에이전트를 만드는 건 시작일 뿐이다. 그 에이전트가 사용자의 기존 시스템들 사이에 끼어들어, 없으면 흐름이 끊기는 존재가 되어야 한다. 연결이 깊어질수록 교체 비용은 기하급수적으로 증가한다. 한 시스템과 연결된 에이전트의 교체 비용이 1이라면, 네 시스템을 관통하는 에이전트의 교체 비용은 4가 아니라 4의 제곱에 가깝다 — 연결 사이의 의존성까지 함께 옮겨야 하기 때문이다.
플라이휠이 사용자 개인의 맥락을 쌓아 이탈을 막는다면, 깊은 통합은 조직의 워크플로우를 감싸 안아 이탈을 막는다. 한쪽은 “나를 다시 가르치기 싫어서” 못 떠나고, 다른 한쪽은 “이걸 다시 연결하기 싫어서” 못 떠난다. 두 해자가 동시에 작동할 때, 복제는 진짜로 의미를 잃는다.
5. 두 해자가 만나면 — 복제 불가능의 완성
지금까지 두 가지 해자를 따로 살펴봤다. 피드백 플라이휠이 만드는 시간의 해자, 깊은 통합이 만드는 깊이의 해자. 각각만으로도 강력하다. 그런데 이 둘이 별개로 존재할 때와, 하나의 시스템 안에서 결합될 때는 완전히 다른 이야기가 된다.
결합의 구조는 이렇다. 플라이휠이 돌수록 에이전트는 사용자의 워크플로우를 더 깊이 이해하게 된다. 어떤 상황에서 어떤 시스템으로 작업이 넘어가는지, 어느 단계에서 병목이 생기는지, 팀원 간 커뮤니케이션이 어떤 패턴으로 흐르는지. 이 이해가 축적되면 에이전트는 단순히 “연결된” 수준을 넘어 “더 깊은 통합”을 제안할 수 있게 된다. “Slack에서 이런 유형의 메시지가 오면 Jira 티켓을 만드는 게 아니라, 먼저 관련 PR이 있는지 확인하고, 이미 수정 중이면 Slack에 상태를 회신하는 게 어떨까요?” 같은 제안이다. 이 제안은 워크플로우를 오래 관찰한 에이전트만 할 수 있다. 신규 도구에는 불가능하다.
반대 방향도 작동한다. 통합이 깊을수록 에이전트가 접하는 맥락 데이터는 풍부해진다. 채팅창 안에서만 사용자를 관찰하는 에이전트는 “이 사람이 뭘 물어보는지”만 안다. 하지만 여러 시스템을 관통하며 접착제로 기능하는 에이전트는 “이 사람이 어떻게 일하는지”를 안다. 이 데이터가 플라이휠에 공급되면 학습의 속도와 정밀도가 모두 올라간다. 플라이휠이 가속된다.
정리하면 이런 순환이다. 플라이휠 → 워크플로우 이해 심화 → 더 깊은 통합 제안 → 더 풍부한 맥락 수집 → 플라이휠 가속. 선순환이다. 시간이 지날수록 해자는 넓어지기만 한다. 여기서 핵심적인 비대칭이 생긴다 — 경쟁사가 오늘 당장 더 좋은 모델과 더 빠른 응답 속도를 들고 나타나도, 이 순환이 만든 축적을 따라잡으려면 같은 시간을 투자해야 한다. 기술 격차는 자본으로 좁힐 수 있지만, 시간 격차는 시간으로만 좁힐 수 있다.
그렇다면 이 두 해자 중 하나만 가진 경우는 어떨까? 현실의 반례를 보자.
데이터만 있고 통합이 없는 경우 — 노션 AI. 노션은 사용자의 데이터를 방대하게 보유하고 있다. 회의록, 프로젝트 문서, 개인 메모, 팀 위키. AI 기능은 이 데이터를 기반으로 꽤 똑똑하게 작동한다. 사용자가 노션에 더 많이 쓸수록, AI는 더 정확한 답을 할 수 있다.
문제는 통합의 부재다. 노션 AI는 노션 안에서만 동작한다. 문서 안에서 질문하고, 문서 안에서 답을 받는다. 에이전트가 Slack으로 알림을 보내거나, Jira 티켓을 만들거나, GitHub PR을 트리거하지 않는다. 워크플로우의 접착제가 아니라, 하나의 앱 안에 갇힌 보조 기능이다. 그래서 사용자가 노션 문서를 Confluence로 옮기기로 결정하면, export 버튼 하나로 데이터는 빠져나간다. AI가 쌓아온 맥락? 함께 사라진다. 노션 밖에서는 아무것도 끊기지 않으니까. 연결된 것이 없으면, 끊을 것도 없다. 데이터가 아무리 풍부해도, 그 데이터가 워크플로우의 여러 지점을 관통하지 않으면 사용자를 잡아두는 힘은 약하다.
통합만 있고 학습이 없는 경우 — 초기 Zapier AI. Zapier는 통합의 왕이다. 수천 개의 앱을 연결하고, 워크플로우 자동화에 있어서 이만큼 깊이 들어간 서비스도 드물다. “Gmail에 특정 제목의 메일이 오면 → Slack 채널에 알림 → Google Sheets에 기록 → Trello에 카드 생성.” 이런 파이프라인이 수십 개 얽혀 있는 팀에서 Zapier를 걷어내는 건 상당한 고통이다. 깊이의 해자는 확실히 있다.
그런데 초기 Zapier AI에는 플라이휠이 없었다. 사용자별 학습이 부재했다. 같은 종류의 자동화를 반복 설정해도, AI가 “지난번에 이렇게 하셨으니 이번에도 이 패턴으로 할까요?”라고 제안하지 않았다. 매번 처음부터였다. 그래서 더 똑똑한 자동화 도구 — make.com이나 n8n의 AI 기능 — 가 나타났을 때, 사용자들은 마이그레이션의 고통을 감수하고서라도 옮길 동기가 생겼다. 통합의 해자가 전환을 어렵게 만들었지만, “여기 더 있어봤자 더 나아지지 않는다”는 인식이 전환의 결심을 가능하게 했다. 오래 쓴다고 더 좋아지지 않는 도구에 대한 충성심은 한계가 있다.
두 사례가 보여주는 것은 명확하다. 데이터만으로는 사용자를 가둘 수 없다 — 통합이 없으면 데이터는 쉽게 빠져나간다. 통합만으로는 사용자를 붙잡을 수 없다 — 학습이 없으면 더 좋은 대안 앞에서 교체 고통을 감수할 이유가 생긴다. 해자가 진짜 해자가 되려면 두 축이 모두 필요하다. 시간이 쌓을수록 더 정확해지는 학습, 그리고 그 학습이 워크플로우 곳곳에 스며들어 떼어낼 수 없게 만드는 통합. 이 둘이 합쳐질 때 비로소 복제 불가능의 구조가 완성된다.
6. 복제를 막으려 하지 마라
다시 처음의 질문으로 돌아가자. 경쟁사가 당신의 에이전트를 복제했다. 프롬프트도 같고, 모델도 같고, 기능도 같다. 그런데 사용자가 안 떠났다. 왜?
답은 한 문장이다. 복제품에는 시간이 없고, 연결이 없기 때문이다.
프롬프트는 텍스트 파일이다. 복사하는 데 1초면 된다. 모델은 API다. 키를 발급받으면 누구나 호출할 수 있다. 기능은 코드다. 충분한 엔지니어가 있으면 재현된다. 하지만 6개월간 사용자와 주고받은 피드백이 빚어낸 판단 체계는 복사할 수 없다. 네 개의 시스템을 관통하며 팀의 일상에 스며든 연결 조직은 키 하나로 대체되지 않는다. 복제품은 기능적으로 동일하지만 구조적으로 텅 비어 있다. 빈 껍데기가 6개월치 관성을 이기는 일은 일어나지 않는다.
그래서 역설적인 결론에 도달한다. 복제를 막는 데 에너지를 쓰지 마라. 프롬프트를 암호화하고, 코드를 난독화하고, 특허를 출원하는 데 들이는 시간은 해자를 만들지 않는다. 그 에너지를 다른 곳에 써라. 사용자가 쓸수록 더 정확해지는 플라이휠을 설계하고, 에이전트가 워크플로우의 접착제가 되도록 통합의 깊이를 넓혀라. 복제를 막는 벽은 결국 뚫리지만, 복제해도 소용없는 구조는 뚫을 필요 자체가 없다. 공격자가 성벽을 넘었는데, 성 안에 아무것도 없는 셈이다 — 진짜 가치는 벽 안의 물건이 아니라 성 안에서 흐르는 시간과 관계에 있으니까.
개발자든 창업자든, 에이전트 제품을 만들고 있다면 스스로 물어야 할 질문은 하나다. 당신의 에이전트는 사용할수록 나아지는가? 사용자의 워크플로우에 스며들어 있는가? 둘 다 아니라면, 당신의 해자는 없다.