Amazon에서 23년 일한 사람이 주말에 CRM을 직접 만든 이유
핵심 요약 (TL;DR)
Amazon Worldwide Consumer 전 CEO Dave Clark이 주말 72시간에 자체 CRM과 고객 프로토타입, 피치덱 리워크를 끝낸 LinkedIn 게시물이 바이럴됐습니다. 23년차 운영 베테랑이자 비개발자인 그가 "기성 CRM은 우리 파이프라인이랑 안 맞아서"라고 답한 한 줄이 핵심입니다. 바이브코더의 다음 시장은 코더가 아니라 워크플로를 가장 잘 아는 비개발자 리더입니다.
23년 운영 베테랑이 주말에 만든 것
Dave Clark이라는 이름이 낯설 수 있는데, 이력서가 좀 무겁습니다. Amazon에서 23년을 일하며 마지막 5년은 Worldwide Consumer 부문 CEO를 지냈고, 이후 Flexport CEO를 거쳐 2024년 Auger를 창업해 시리즈A로 1억 달러를 모은 사람입니다. 코더가 아니라 운영의 사람인 거죠.
그런 사람이 어느 주말, LinkedIn에 "믿기지 않을 만큼 생산적인 주말이었다"는 글 한 편을 올렸습니다. 72시간 동안 만든 것이 세 가지인데 (1) end-to-end 고객 프로토타입 (2) 회사 피치덱 리워크 (3) 자체 CRM 시스템이었습니다. 그중 CRM은 "하룻밤과 다음 날 아침"에 끝냈다고 본인이 적었죠. 보통 회사라면 PM·디자이너·엔지니어 셋이 붙어 몇 달이 걸릴 일입니다.
게시물은 곧바로 'vibe coding이 진짜냐 환상이냐'는 논쟁의 도화선이 됐습니다. "왜 오픈소스 안 썼냐"는 반론에 Clark이 댓글로 단 답이 흥미롭습니다. "우리 영업 파이프라인이 일반적인 형태가 아니어서, 기성 CRM에 우리를 끼워 맞추는 게 더 비효율적이었습니다."
사용한 도구는 본인이 공개하지 않았습니다. 매체는 Cursor·Claude Code·Copilot 계열을 추정으로 언급할 뿐이라, 단정해서 받아들일 필요는 없습니다.
왜 이게 중요한 신호인가
바이브코딩 담론은 그동안 두 가지 캐릭터에 집중돼 있었습니다. 한쪽은 인디해커, 다른 한쪽은 개발자 출신 창업자. Clark의 사례는 그 사이를 깨버립니다. 코딩을 못 하는 23년차 운영자도 자기 회사의 워크플로 도구를 직접 만든다는 걸 보여줬거든요.
역사적으로 SaaS는 "우리 도메인을 잘 아는 사람이 도구를 못 만드니, 도구를 잘 만드는 회사가 도메인을 추측해서 만든 제품을 사오는" 구조였습니다. 그 추측 비용이 월 구독료에 녹아 있었고요. AI 코딩 도구가 "도메인 아는 사람이 직접 만든다"를 가능하게 만든 순간, SaaS 구독은 처음으로 진지한 질문을 받게 됩니다. 이걸 굳이 사야 할까요?
물론 Clark이 만든 CRM이 Salesforce를 대체한다는 뜻은 아닙니다. Auger 같은 작은 회사 영업 파이프라인을 위한 한 번 쓰고 마는 도구일 가능성이 큽니다. 하지만 핵심은 "한 번 쓰고 마는 도구"가 주말 안에 가능해졌다는 것 자체입니다.
비개발자 리더가 점검해야 할 3가지
현재 SaaS 스택 중 "우리 워크플로에 60%만 맞는" 도구가 있는가 — 풀로 안 맞는 도구는 직접 만들기 후보입니다. 100% 맞는 도구는 그대로 쓰는 게 합리적이고요.
그 도구의 데이터가 우리 회사 안에만 있는가 — 우리 영업·고객 데이터를 외부 SaaS에 넣을 필요 없이, 내부 DB·시트에서 바로 다루는 도구라면 진입장벽이 낮습니다.
주말 1회분 "가설 비용"을 감당할 수 있는가 — Clark의 핵심은 72시간 안에 던져보고 작동하면 쓰고, 안 되면 버리는 사이클입니다. 6개월짜리 IT 프로젝트가 아니에요.
FAQ
Q. 코딩 한 줄 안 해본 사람도 주말에 CRM을 만들 수 있나요?
Clark도 본인이 코더가 아니라고 못 박았습니다. 다만 23년간 Amazon 운영을 한 사람이라 "이 도구가 무엇을 해야 하는지"에 대한 사양 감각이 압도적입니다. 바이브코딩에서 가장 비싼 입력값은 결국 "무엇을 만들어야 하는가"에 대한 명확한 사양이거든요. 도메인 깊이가 코드 경험보다 중요한 영역입니다.
Q. 그래도 주말 한 번에 CRM이 나온다는 건 좀 과장 아닌가요?
Clark이 "하룻밤+아침"이라고 적은 건 본인 진술이라 검증이 어렵습니다. 운영 단계까지 다듬은 게 아니라 첫 작동 버전일 가능성이 큽니다. 하지만 "보통 몇 달 → 며칠"의 압축은 이미 여러 사례에서 반복적으로 보고되고 있어 대체로 신뢰 가능한 흐름입니다.
Q. 그럼 SaaS 구독은 다 해지하는 게 맞나요?
반대입니다. 우리 워크플로에 100% 맞는 SaaS는 직접 만들 이유가 없습니다. 노려야 할 건 "애매하게 안 맞는데 매달 돈 나가는 도구"입니다.
댓글 0
아직 댓글이 없습니다