3시간, 6명의 개발자, 30,000명의 실종자

부에노스아이레스에 있는 한 베네수엘라 프로그래머는 6명으로 구성된 팀과 쏟아지는 실종자 보고를 마주했습니다. AI가 없었다면 빌드(build)에 약 24시간이 소요되었을 것입니다. 하지만 Claude Opus를 사용하여 단 3시간 만에 끝냈습니다. 해당 사이트 — Desaparecidos Terremoto Venezuela — 는 누구나 사진을 업로드할 수 있게 했고, 실종자 데이터베이스를 대상으로 얼굴 인식 (facial recognition)을 실행하여 몇 초 만에 사람들을 매칭했습니다. 앱도 필요 없고, 회원가입도 필요 없는 WhatsApp 링크 방식이었습니다. 이틀째 되는 날, 사이트는 30,000건 이상의 제출물을 흡수했습니다.

그로부터 4시간 후, 캘리포니아의 한 개발자는 Replit을 통해 Ayuda en Camino을 출시했습니다. 이 서비스는 물자(의약품, 담요, 운송 수단)를 필요 사항과 매칭했으며, 웹사이트를 불러올 수 없는 연결 상태의 사람들을 위해 WhatsApp 어시스턴트가 문의 사항을 처리했습니다.

두 번의 지진으로 인해 베네수엘라 북부 전역의 병원들이 파괴되었고 광섬유 및 이동통신 타워가 끊겼습니다. 국가는 대응이 느렸습니다. 통신 백본 (telecom backbone)은 조각나 있었습니다. 디아스포라 개발자들이 가장 먼저 움직였습니다.

이 역전 현상이 바로 핵심적인 이야기입니다. 단순히 "AI가 위기 상황을 구했다"는 식의 이야기는 게으른 프레임입니다. 진짜 이야기는, 도메인 지식과 절박함을 가진 사람들이 어떤 개발자의 노트북에 있는 소비자용 AI를 휘둘렀을 때, 비상 예산보다 더 빠르게 움직였다는 점입니다. 이를 가능하게 한 도구들 — Claude Opus, Replit, WhatsApp — 은 모든 시니어 엔지니어의 컴퓨터에 설치되어 있는 것들과 동일했습니다. 국가에는 예산이 있었지만, 개발자들에게는 낮은 지연 시간 (latency)이 있었습니다.

메커니즘: 3시간이 실제로 만들어낸 것

Desaparecidos가 가장 깔끔한 사례입니다. 이 사이트는 네 가지 기능을 수행합니다: 사진 업로드, 실종자 데이터베이스를 통한 얼굴 매칭, 중복 제거 (deduplication), 그리고 공개 조회 흐름 (public lookup flow)입니다. 각각의 기능만으로도 주말 프로젝트가 될 수 있는 것들입니다. 하지만 이를 정교한 UI와 함께 결합하면, 하나의 스프린트 (sprint)가 됩니다.

Claude Opus는 이 스프린트 (sprint)를 단 한 오후로 압축해 버렸습니다. 이 기사는 AI 없이 구축할 경우 "휴식 없이 대략 24시간"이 걸릴 작업을 AI와 함께라면 "3시간" 만에 끝낼 수 있다고 추정합니다. 이는 8배의 압축이며, 이는 단순한 자동 완성 (autocomplete) 덕분이 아닙니다. 전체 아키텍처 (architecture)를 컨텍스트 (context)에 유지하고, 일치하는 로직 (logic)을 초안 작성하며, 중재 규칙 (moderation rules)을 작성하고, 그렇지 않았다면 처음 6시간을 잡아먹었을 보일러플레이트 (boilerplate)를 배포하는 모델 덕분입니다.

Ayuda en Camino는 두 번째 패턴입니다. Replit의 협업 런타임 (collaborative runtime) 덕분에 부에노스아이레스, 산티아고, 마이애미, 샌프란시스코에 흩어져 있는 디아스포라들은 아무런 프로비저닝 (provisioning) 없이도 동일한 코드베이스 (codebase)를 공동 편집할 수 있습니다. 아이디어에서 프로덕션 URL (production URL)까지 단 4시간이 걸렸습니다. 두 번째 역전 현상은 "AI가 코드를 더 빨리 작성한다"가 아닙니다. 바로 "AI + 호스팅된 런타임 (hosted runtime)이 배포 과정을 제로 (zero)로 압축한다"는 것입니다.

두 패턴 모두 하나의 전제 조건을 공유합니다: 제품을 출시하는 사람들에게 _도메인 지식 (domain knowledge)_이 있었다는 점입니다. 그들은 베네수엘라 사람들이었습니다. 그들은 거리 수준에서 위기가 실제로 어떤 모습인지 알고 있었습니다. 그들은 다른 개발자들과 마찬가지로 동일한 모델 (models)에 접근할 수 있었습니다. 하지만 그들에게는 제도적 접근 권한이 없었습니다. FEMA (연방재난관리청)의 예산도 없었습니다. 그들에게는 Claude, Replit, 그리고 WhatsApp 번호가 있었습니다.

왜 이 역전 현상이 실제로는 모델에 관한 것이 아닌가

여기 불편한 진실이 있습니다. 만약 그 주에 Claude의 API가 다운되었거나, Replit에 지역적 장애가 발생했거나, 혹은 Anthropic이 화요일에 모델 ID (model id)를 변경했다면, Desaparecidos 사이트는 제때 출시되지 못했을 수도 있습니다. 30,000건의 보고는 여전히 Telegram 그룹, 스프레드시트 (spreadsheets), 수기 노트 속에 쌓여갔을 것입니다. AI는 팀에게 승수 (multiplier)를 제공했습니다. 하지만 그 승수는 팀이 통제할 수 없는 인프라 (infrastructure)에 의존하고 있습니다.

대부분의 "AI가 위기를 구했다"라는 프레임워크는 이 점을 놓칩니다. 모델은 변동성이 큰 레이어 (volatile layer)입니다. 프롬프트 (prompts), 아키텍처 (architecture), 실종자 보고를 위한 스키마 (schema), WhatsApp 온보딩 플로우 (onboarding flow) — 이것들이 바로 지속 가능한 레이어 (durable layer)입니다. 위기가 지나고 2주가 지나도 팀에는 여전히 스키마가 필요할 것입니다. 여전히 조회 UX (lookup UX)가 필요할 것입니다. 하지만 그들에게 Opus가 여전히 필요하지는 않을 수도 있습니다.

이는 현재 AI가 등장하고 있는 모든 영역에서 사실입니다. AI를 통해 오후 한나절 만에 출시할 수 있는 것은 빠릅니다. 하지만 모델의 변화(model churn) — 다음 가격 정책 변경, 다음 기능 폐지(deprecation), 다음 ID 순환(id rotation) — 속에서도 살아남는 것은, 이번 분기에 어떤 LLM을 호출하느냐에 의존하지 않는 토대 위에 구축되어야 합니다.

WhatsApp 제약 조건이 주는 진짜 교훈

대부분의 보도는 LLM을 앞세울 것입니다. 하지만 더 흥미로운 제약 조건은 WhatsApp 폴백(fallback)입니다. Samuel Mariña의 팀은 "사용자들의 연결 상태가 너무 약해 사이트를 불러올 수 없었기 때문에" WhatsApp 어시스턴트를 구축했습니다. 사용자가 200 kbps 속도의 2G 환경에서 배터리가 거의 방전되어 가고 있다면, 세상에서 가장 풍부한 모델도 무용지물입니다.

그 제약 조건은 위기 대응 소프트웨어의 모든 아키텍처 결정(architectural decision)을 형성합니다:

• 인터페이스는 풍부한 웹(rich web) → SMS → WhatsApp → 음성(voice) 순으로 우아하게 기능이 저하(degrade gracefully)되어야 합니다.
• 상태(state)는 사용자가 정보를 가져오기 위해 별도의 인증을 할 필요가 없는 곳에 존재해야 합니다.
• 매칭(matching)은 데이터베이스의 절반이 손상되거나 중복된 상태에서도 작동해야 합니다.

제품을 출시한 팀들은 이를 이해하고 있었습니다. 만약 UN 산하 기관에서 똑같은 것을 6개월 동안 만들려 했다면, 아마 WebGL 대시보드를 구축하고 그것을 혁신이라 불렀을 것입니다.

다음은 공개용 스키마(public-facing schema)가 감당해야 했던 대략적인 내용입니다:

// 모델보다 오래 살아남아야 하는 부분.
type MissingPersonReport = {
  id: string                          // 서버 생성, 불투명(opaque)
...

여기에 포함되지 않은 것들에 주목하십시오: 모델 ID, 프롬프트 템플릿(prompt template), 임베딩 차원(embedding dimension), 벡터 인덱스(vector index) 등입니다. 모델은 교체 가능합니다. 하지만 스키마는 그렇지 않습니다. 2년 후, 다음 지진이 발생하고 디아스포라가 다시 노트북을 열었을 때, 그대로 이어지는 것은 바로 이 스키마입니다.

이것이 우리에게 주는 것

베네수엘라 대응 사례에서 간직할 만한 세 가지 요소는 다음과 같습니다:

1. Consumer AI는 이제 위기 상황에서의 강력한 승수 효과 (force multiplier)를 발휘합니다. 모델이 마법 같아서가 아니라, 모든 노트북에 탑재되어 있으며 "프로덕션 URL (production URL)"에 도달하기까지의 지연 시간(latency)이 몇 달이 아닌 몇 시간 단위로 측정되기 때문입니다. 다음 재난 — 그리고 재난은 반드시 올 것입니다 — 상황에서도 디아스포라 개발자들은 다시 결과물을 내놓을 것입니다. 이것이 현재 세상의 특징입니다.

2. 지속 가능한 계층은 모델이 아니라 스키마 (schema)와 UX입니다. 이번 주에 재사용 가능한 실종자 스키마를 배포한 팀은 터키, 모로코, 또는 미얀마에서 다음 지진이 발생했을 때 90분 만에 Desaparecidos를 재구축할 수 있습니다. 재사용 가능한 조회 인터페이스를 배포한 팀은 사람들이 서로를 찾아야 하는 모든 위기 상황에서 동일한 작업을 수행할 수 있습니다. Claude 프롬프트 외에 아무것도 배포하지 않은 팀은 아무것도 배포하지 않은 것과 같습니다.

3. 제약 조건이 능력(capabilities)보다 아키텍처(architecture)를 더 강력하게 형성합니다. WhatsApp 우선, 가입 불필요, 사진 업로드 전용. 인터페이스는 모델이 무엇을 할 수 있느냐가 아니라 사용자가 무엇을 가지고 있느냐에 의해 결정됩니다. 이는 대부분의 AI 데모가 구축되는 방식과 정반대이며, 이 프로젝트가 실제로 작동했던 이유입니다.

[[CONCEPT: 스키마, 컴포넌트, 그리고 지속 가능한 인터페이스라는 두꺼운 계층 위에 놓인 얇은 LLM 호출 계층 — LLM은 교체 가능하지만, 그 아래의 계층은 교체 불가능함]]

소멸하지 않는 부분

Claude를 통해 3시간 만에 무언가를 배포할 때, 당신은 빌려온 시간(borrowed time) 위에서 배포하는 것입니다. 모델의 ID가 바뀝니다. 가격 정책이 바뀝니다. 속도 제한 (rate limits)이 바뀝니다. 2년 후 사이트를 유지 관리하는 팀은 특정 모델 스냅샷을 기준으로 작성된 위기 대응 인프라를 유지 관리하게 될 것입니다.

살아남는 조각들은 모델에 의존하지 않는 것들입니다:

• 웹과 모바일에서 동일한 UI를 렌더링하는 컴포넌트 계층 (Component layer), 따라서 사용자가 무엇을 손에 들고 있든 상관없이 조회(Lookup)가 작동합니다.
• 실종자 보고, 기부 경로 지정, 또는 물자 매칭을 위한 스키마 (Schema)를 보유하는 데이터 계층 (Data layer) — 버전이 관리되고, 이식 가능하며, LLM 없이도 읽을 수 있습니다.
• 전화번호와 얼굴을 가진 사람이 계정, 이메일, 또는 OAuth 흐름 없이도 검색될 수 있게 하는 인증 계층 (Auth layer).

이것들은 지루한 부분들입니다. 하지만 모델이 바뀔 때 변하지 않는 부분들이기도 합니다.

Claude를 사용하세요. Replit을 사용하세요. 3시간 만에 배포하세요. 그리고 변하지 않는 것 위에 변하지 않는 부분들을 구축하세요 — 하나의 API로부터 웹, iOS, Android에 동일한 UX를 전달하는 크로스 플랫폼 컴포넌트 계층, 스냅샷보다 오래 지속되는 스키마, 그리고 사용자가 가진 가장 최악의 연결 상태에서도 작동하는 인증 흐름 (Auth flow) 말입니다. 모델은 교체될 것입니다. 하지만 컴포넌트, 스키마, 그리고 전달 인터페이스 (Delivery surface)는 그대로 남습니다.