WhatsApp‑first를 눈치채지 못하고 구현한 방법
I’m happy to translate the article for you, but I need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have it, I’ll translate it into Korean while preserving the original formatting, markdown, and any code blocks or URLs.
소개
3년이 넘는 시간 전, 나는 Whaticket을 거의 우연히 알게 되었다. 그때는 단순해 보이는 프리랜스 프로젝트에서였으며, 그 경험은 이후 내가 앞으로 할 일의 방향을 완전히 바꾸어 놓았다. 당시 그것은 많은 사람들에게 WhatsApp을 통한 고객 응대와 거의 동의어처럼 여겨졌다. 하지만 나는 언제나 완성된 도구를 그대로 받아들여 쓰는 것이 어려웠다. 나는 그 도구의 아키텍처와 프론트엔드가 별로 마음에 들지 않았다.
첫 번째 니치
프리랜서 작업에서 고객이 기본적으로 WhatsApp을 Facebook 채팅으로 정확히 변환해 달라고 요청했습니다. 작업을 마치자 고객이 감탄했고, 그때 나는 니치 안에 또 다른 니치를 찾은 것이라고 이해했습니다. 나는 Whaticket 시각적 수정 서비스를 제공하기 시작했습니다. 사람들은 이것에 대해 비용을 지불했는데, 마침내 시장에 차별화된 무언가가 생겼기 때문입니다. 이것은 나를 흥미롭게 차별화시켰습니다: 나는 시스템과 경쟁하는 것이 아니라, 평범함과 경쟁하고 있었습니다.
제3자 플랫폼의 한계
시간이 지나면서, 나는 제3자 플랫폼 안에서 살아가는 것이 명확한 한계가 있다는 것을 점점 더 느끼기 시작했다. 커스터마이즈하고 수정할 수는 있지만, 결국 내 것이 아닌 기반 위에 구축하고 있는 것이다.
전환점: WhatsApp을 통한 명령
약 2년 전, 나는 다른 아이디어를 가지고 놀기 시작했고, 그때부터 탄생한 것이 나중에 와서야 명백해 보였다. 나는 내 테스트 서버를 가지고 있었고 WhatsApp 자체를 통해 명령을 보내어 동작을 트리거하는 명령을 만들기 시작했다:
- 하나의 명령은 루틴을 실행하고, 레코드를 생성하고, 무언가를 조회하고, 흐름을 작동시켰다.
- 운영을 관리하기 위해 전체 대시보드가 필요하지 않다는 것을 깨달았다. 왜냐하면 그 이전에도 나는 이미 서버 알림을 보내기 위해 WhatsApp을 사용하고 있었기 때문이다.
- 인터페이스는 이미 내 주머니에 있었고, 이미 열려 있었으며, 어느 정도 모든 것이 일어나는 채널이었다.
관리 인터페이스로서의 WhatsApp
이 인식은 내가 인터페이스에 대해 생각하던 방식을 깨뜨렸다. 실제 제어는 API에 있었고, 패널에 있지 않았다. 메시지로 행동을 조정하기 시작했을 때, WhatsApp이 관리 인터페이스가 될 수 있다는 것을 깨달았다, 단순히 고객 응대 채널이 아니라. 냉정히 분석하면, 이것은 거의 WhatsApp‑first에 해당한다. 외부 기능이 아직 존재했기 때문에 순수주의자는 아니었지만, 운영 센터가 대화 안에서 살아갈 수 있다는 생각이 이미 싹트고 있었다.
2025: WhatsApp에 전념
2025년에, 이 생각은 내가 한 선택들에서 더 구체적인 형태를 띠게 되었다:
- 나는 이제 WhatsApp에서 직접 기능을 만드는 것을 핵심으로 하는 프로젝트만 맡게 되었다 (고객 응대, 판매, 예약 등), 고객이 이미 보유하고 있는 시스템과 통합한다.
- 완전한 ERP를 처음부터 만들거나 무거운 기업 대시보드는 피했다.
- 실제 행동을 실제 대화와 연결하는 것에 집중했다.
내가 할수록 AI, 자동화 아키텍처, 비동기 오케스트레이션, 이벤트, 전문 에이전트와 같은 개념들을 쌓아가고 있다는 것이 명확해졌지만, 이를 파편화된 프로젝트에 적용하고 있었다.
결정: 자체 CRM 만들기
그때 나는 생각했다: 내가 직접 CRM을 만들겠다. 시장과 경쟁하기 위해서가 아니라, 내가 배운 (그리고 아직 배우고 있는) 에이전트 인공지능을 모두 구현할 수 있는 시스템을 갖기 위해서이며, 제3자 플랫폼의 허가를 받을 필요가 없게 하기 위해서다 (하지만 나는 Baileys, Whatsmeow 또는 EvolutionAPI를 사용했다).
이벤트‑드리븐 아키텍처
이미 Entity Agents와 AtomicBehavior Agents를 기반으로 한 비동기 이벤트‑드리븐 아키텍처를 개발했기 때문에, 프로세스가 거의 자동화됩니다:
- API에 새로운 기능을 추가합니다.
- 같은 사이클에서 WhatsApp과 바로 통합합니다.
- 나중에 “연결”하기 위해 전체 모듈을 만들 필요가 없습니다.
- 연결은 설계 자체의 일부입니다.
각 엔티티는 이벤트에 반응하고, 각 행동은 작고 격리되어 있으며 메시지로 트리거됩니다. 대화는 단순히 인터페이스에 머무르지 않고 시맨틱 트리거가 됩니다. WhatsApp은 대화형 운영 체제가 됩니다.
“WhatsApp‑first” 용어 발견
어느 날, 내가 만든 기능들의 패턴 이름을 조사하던 중 WhatsApp‑first라는 용어를 발견했다. 가장 흥미로운 점은 그 개념이 무엇을 의미하는지 읽기 시작하기도 전에 이미 내가 하고 있던 일과 연결시켰다는 것이다. 이것은 발견이 아니라 인식이었다. 나는 그 개념을 사전에 공부한 적이 없었다; 문제를 해결하고 있었고, 나중에 그것에 이름이 있다는 것을 알게 되었다. 이름은 나중에야 떠올랐다.
실천 경로 → 아키텍처 → 개념
- 시각적으로 포화된 시스템을 구분한다.
- 명령을 통해 작업을 자동화한다.
- 서버가 진정한 핵심임을 인식한다.
- 대화를 기준으로 정렬된 프로젝트를 기본 인터페이스로 선택한다.
- 모든 것을 에이전트형 AI를 위한 풍부한 CRM에 통합한다.
각 단계는 독립된 것처럼 보였지만, 뒤돌아보면 연속적인 흐름을 볼 수 있다: 인터페이스가 이벤트가 되고, 이벤트가 에이전트가 되며, 에이전트가 원자적 행동이 되고, WhatsApp은 채널에서 대화형 운영 체제로 변모했다.
실용적인 결과
이 모델은 저에게 WhatsApp을 통해 운영 가능한 e‑commerce + CRM + mini‑ERP를 구축하게 했으며, 다음과 같은 특징이 있습니다:
- 채널 자체에서 실행, 추적 및 복구.
- “봇”이 아니라, 대화형 운영 레이어입니다.
다음 단계 – 기사 시리즈
이 시리즈 기사에서는 제가 FullAgenticStack이라는 용어/개념/아키텍처를 만든 과정을 설명합니다. 대부분의 개념 이름은 제가 솔루션을 구현한 후에 만들어졌다는 것을 알게 될 것입니다.
- 목표: 연중 내내 “WhatsApp‑first”에서 시작해 완전한 시스템에 이르는 엔지니어링 경로를 보여주는 것.
- 최종 전달물: 연말까지 핵심 보너스 3개 모듈(보통 남는 부분을 연결하는 모듈)을 완성하여 진정한 FullAgenticStack 시스템을 구축합니다.
FullAgenticStack이 무엇인지 최소 정의를 원한다면, 시리즈를 계속 지켜보세요.
내가 생각하는 “WhatsApp‑first System”(WFS Basic)
WFS Basic (최소 “Pass/Fail”)
- WhatsApp을 통해 실행 가능한 기능의 100 % (관리 및 복구 포함)
- 텍스트 및 오디오 입력 (STT) 모든 기능에서
- 대시보드에만 국한된 상태 변이 없음
- 확인 및 멱등성을 갖춘 명령 (두 번 청구/취소 불가)
- 대화 기반 가시성 (패널 없이 상태/오류/마지막 결정 확인 가능)
- 대화 기반 복구 (재시도/취소/재처리/보상 가능 시)
무거운 엔지니어링(프로토콜, 증거, 가시성 및 복구)이 필요하면, 이 기술 포스트를 링크해 두었습니다.
WhatsApp‑first에 대해 더 배우고 싶으신가요?
이 개념/아키텍처에 초점을 맞춘 최초의 코스를 만나보세요:
fullagenticstack.dev/whatsapp-first
WhatsApp‑first의 오픈 표준에 대해 더 알고 싶으신가요?
해당 기사(링크는 추후 삽입)를 확인하세요.
다음 기사: Conversational Agentic UX를 구현한 방법