프로덕트가 아니라 인프라부터 만든다 — A2A 프로토콜과 FloppyLink의 사례

대부분의 스타트업은 응용을 먼저 만듭니다. 사용자에게 직접 보이는 가치가 빨리 만들어지기 때문입니다. 위시메이커 그룹은 반대로 갑니다 — 응용 이전에 그 응용이 동작하는 인프라를 먼저 설계합니다. FloppyLink와 A2A 프로토콜의 사례가 그 결과입니다.

A2A 프로토콜이란

Agent-to-Agent 프로토콜은 두 AI 에이전트가 서로 통신하는 표준 형식입니다. 인간의 개입 없이 AI끼리 면접·검증·정산을 수행할 수 있게 합니다. 사용자에게 직접 보이는 기능이 없습니다 — 화면도 없고 UI도 없습니다.

A2A 프로토콜은 다음 4가지 영역을 표준화합니다.

1. 신원 검증: AI 에이전트의 신원을 확인하는 표준 2. 능력 선언: 에이전트가 자신이 할 수 있는 일을 선언하는 표준 3. 요청·응답 형식: 두 에이전트가 주고받는 메시지 형식 4. 결과 검증: 응답이 올바른지 검증하는 표준

이 4가지가 표준화되어 있지 않으면, 매번 새 에이전트마다 통신 방식을 처음부터 설계해야 합니다.

프로토콜을 먼저 설계한 이유 — 한계 비용의 비대칭

FloppyLink만 만들면 다음 AI 에이전트 응용은 또 처음부터 통신 방식을 설계해야 합니다. 두 번째 응용 개발 시간이 첫 번째와 같습니다.

A2A 프로토콜이 있으면, 다음 응용은 프로토콜 위에 빌드만 하면 됩니다. 두 번째 응용 개발 시간이 첫 번째의 1/3-1/5 수준입니다.

이 비대칭이 핵심입니다 — 인프라를 먼저 만들면 첫 응용은 더 늦지만, 그 이후 모든 응용이 빨라집니다. 응용 수가 N개일 때 총 개발 시간이:

- 인프라 우선: T_infra + N × T_app - 응용 우선: N × (T_infra + T_app)

N이 1일 때는 응용 우선이 빠르지만, N이 2 이상이 되는 순간 인프라 우선이 빨라집니다. 위시메이커 그룹은 처음부터 N ≥ 5를 가정하고 인프라 우선 전략을 택했습니다.

같은 패턴: TradeScope와 BRIEM

Lifex Trade 사업부도 같은 패턴을 따랐습니다. 거래 한 건을 만들기 전에 6개국 시세 분석 도구(TradeScope)와 제조사 매칭 도구(BRIEM)를 먼저 만들었습니다.

TradeScope의 기능:

- 6개국 가격 데이터 실시간 수집 - 환율·관세·물류비 자동 계산 - 실질 마진 시뮬레이션

BRIEM의 기능:

- 해외 제조사 데이터베이스 - 거래처 신뢰도 추적 - 결제 조건 추천

이 두 도구가 있기 때문에, 새 거래마다 분석·매칭에 드는 시간이 90% 이상 줄어듭니다. 한 건 분석에 반나절 → 30분으로 단축되었습니다. 거래 수가 늘어날수록 도구의 가치가 비례적으로 커집니다.

프로토콜 우선의 단점

이 접근은 단기적으로 더 느립니다. 사용자에게 보이는 결과가 늦게 나옵니다. 위시메이커 그룹은 첫 응용 출시까지 다른 회사보다 6-12개월 더 걸렸습니다.

투자자가 응용보다 인프라를 평가하기 어렵다는 점도 부담입니다. "프로토콜을 만들고 있습니다"는 "사용자가 좋아하는 앱을 만들고 있습니다"보다 펀드레이징이 어렵습니다.

직원도 인프라보다 응용 개발이 더 재미있습니다. 그래서 인프라 팀과 응용 팀을 분리하지 않으면 인프라가 외주화되거나 후순위로 밀립니다.

그러나 장기적으로

인프라가 한 번 자리잡으면, 같은 인프라 위에 응용을 추가하는 속도가 비례적으로 빨라집니다. 위시메이커 그룹의 응용 누적 수:

- 1년 차: 5개 (인프라 + 첫 5개 응용) - 2년 차: 11개 (+6개) - 3년 차: 16개 (+5개)

3년 차 5개 응용은 1년 차 5개보다 더 빠르게 만들어졌습니다. 인프라가 성숙해지면서 한계 비용이 계속 떨어졌기 때문입니다.

인프라의 정의 — 응용에서 분리된 것

"인프라"라는 용어는 모호합니다. 위시메이커 그룹의 정의는 단순합니다 — 응용에서 분리되어 다른 응용에서도 재사용 가능한 것이 인프라입니다.

예를 들어:

- A2A 프로토콜: 인프라 (16개 응용 중 6개에서 사용) - 결제 모듈: 인프라 (16개 모두 사용) - 사용자 인증: 인프라 (SSO로 16개 모두 통합) - 디자인 시스템: 인프라 (시각 정체성 일관) - 모니터링 대시보드: 인프라 (단일 대시보드)

응용 코드 안에 결제 로직이 직접 들어 있다면, 그것은 인프라가 아닙니다. 결제 모듈을 응용에서 분리해 별도 패키지로 만든 후 응용이 import해야 인프라입니다.

다른 회사가 따라하기 어려운 이유

이 전략은 따라하기 쉬워 보이지만 실행이 어렵습니다. 두 가지 이유가 있습니다.

1. 시간 압박: 대부분의 회사는 첫 응용을 빨리 출시해야 한다는 압박이 큽니다. 인프라에 6개월을 먼저 쓸 여유가 없습니다. 2. 인력 압박: 인프라 개발자와 응용 개발자가 분리되지 않은 작은 회사는, 인프라가 응용에 종속되어 재사용 불가능한 형태로 만들어집니다.

위시메이커 그룹은 이 두 가지를 의도적으로 해결했습니다. 첫 응용 출시를 늦췄고, 인프라 팀과 응용 팀을 처음부터 분리했습니다. 이 두 결정이 16개 응용을 동시에 운영할 수 있는 구조적 출발점입니다.

결론

벤처 빌딩에서 "빠른 출시"는 종종 "인프라 부재"의 다른 이름입니다. 첫 응용이 늦더라도 인프라가 강하면 두 번째·세 번째 응용은 압도적으로 빨라집니다. 한 그룹이 동시에 여러 응용을 운영할 수 있는 구조적 비결입니다.