요즘 모든 이들이 자신들이 프로덕션 소프트웨어 (production software)를 인도할 능력이 있다고 믿습니다. 이것이 실제적인 파괴적 혁신입니다. 이는 코드에 관한 것이 아니라, 사람들이 갖는 확신에 관한 것입니다.

Pieter Levels는 X에 바이럴이 된 게시물을 올렸습니다. 그는 그 글에서 AI가 어떻게 소프트웨어를 범용화 (commodity)하고 있는지 언급하며, 대신 AI를 사용하여 자신을 위한 작은 맞춤형 솔루션들을 구축하는 대신 수많은 SaaS 구독을 취소해 왔다고 공유했습니다. 그 게시물에 대한 반응은 번개와 같았습니다. 전 세계의 인디 해커 (Indie hackers)들이 갑자기 중얼거리기 시작했습니다: 잠깐, 내가 왜 정확히 저것에 비용을 지불하고 있지? 그냥 내가 직접 만들 수도 있는데.

이는 타당한 질문입니다. 또한 위험한 질문이기도 합니다.

데모는 쉬운 부분이다

AI는 무언가를 작동하게 만드는 것을 터무니없이 쉽게 만들었습니다. 아이디어에서 기능적인 프로토타입 (functional prototype)까지 오후 한나절 만에 도달할 수 있습니다. 그것은 진정으로 놀라운 일입니다.

문제는, "기능적인 프로토타입"과 실제로 프로덕션 (production)에 투입할 수 있는 것은 완전히 다른 이야기라는 점입니다. 그리고 AI는 모든 사람에게 그 협곡의 가장자리로 향하는 질주를 시작할 수 있게 해 주었습니다.

Figma의 실체

잠시 Figma를 생각해 봅시다. 그것은 단순한 "디자인 도구" 그 이상입니다. 그것은 불안정한 네트워크 환경에서의 실시간 협업을 위한 수많은 예외 사례 (edge cases)를 해결해 온 수년의 시간을 포함하고 있습니다. 두 사람이 동일한 프레임을 편집할 때의 충돌 해결 (conflict resolution)입니다. 접근성 준수 (accessibility compliance), 엔터프라이즈 SSO, 실제로 작동하는 버전 히스토리 (version history), 그리고 수천 개의 통합 기능을 가진 플러그인 생태계입니다.

당신은 주말 동안 디자인 도구 데모를 만들 수 있습니다. 하지만 Figma를 만들 수는 없습니다. 그 두 가지 사이의 간극은 수년의 시간과 수백 명의 엔지니어들로 측정됩니다.

Salesforce도 같은 상황입니다. 모두가 그것을 싫어합니다. 모두가 그것을 대체할 무언가를 만들 수 있다고 믿습니다. 시도해 본 사람 중 그 과정이 간단하다고 생각하며 돌아온 사람은 아무도 없습니다. 제품은 UI가 아닙니다. 그것은 모든 드롭다운 메뉴에 녹아 있는 10년 치의 워크플로우 예외 사례들입니다.

AI 생성 코드가 실제로 깨지는 지점

제가 계속해서 목격하고 있는 패턴은 다음과 같습니다. AI가 생성한 코드는 고립된 환경에서는 아주 잘 작동합니다. 하나의 API, 하나의 데이터베이스, 하나의 해피 패스 (happy path). 🎉

그 이후, 여러분은 두 번째 시스템과 연결을 설정합니다. 이어서 세 번째 시스템도 연결하죠. 곧이어 재시도 (retrying) 관리, 부분적 충돌 (partial crashes), 인증 토큰 (auth tokens) 만료, 속도 제한 (rate limitations), 서비스 간 데이터 일관성 (data consistency) 보장뿐만 아니라, 알 수 없는 이유로 화요일에만 XML을 반환하는 벤더의 API를 처리해야 하는 상황에 직면하게 됩니다.

AI가 생성한 코드는 이러한 복잡한 다중 시스템 통합 (multi-system integrations) 상황에서는 여전히 작동하지 않을 수 있습니다. 이는 모델의 성능이 나빠서가 아닙니다. 모델들은 고립된 문제에 대해서는 무서울 정도로 뛰어나니까요. 하지만 현실 세계의 소프트웨어는 고립된 문제가 아닙니다. 그것은 에러 처리 (error handling)와 기도 (prayers)로 덕테이프를 붙여 이어 붙인 수천 개의 고립된 문제들의 집합체입니다.

이제 확신 (Confidence)이 실제 제품이다

실제로 어떤 일이 일어났는지에 대한 저의 해석은 이렇습니다. AI가 실제로 소프트웨어를 만들기 더 쉽게 만든 것은 아닙니다. 단지 소프트웨어 개발이 더 쉬워지고 있다는 인상을 주었을 뿐입니다.

이것은 필수적이며, 매우 중요합니다.

매력적인 데모를 비용 없이 만들어낼 수 있게 되면서, 사람들은 데모 '이후'에 투입되는 노력들을 인정하기 어려워졌습니다. 매력적이지 않은 작업들 말이죠. 모니터링 (monitoring), 마이그레이션 (migrations), 그리고 "일본의 고객이 결제 주소의 더블 바이트 문자 (double-byte characters)에서만 발생하는 버그를 발견했다"와 같은 종류의 작업들 말입니다.

데모와 실제 제품 사이의 간극은 항상 존재해 왔습니다. AI는 단지 그 간극을 한 번도 건너본 적 없는 사람들에게 보이지 않게 만들었을 뿐입니다. 😅

그래서 우리는 실제로 무엇을 해야 하는가?

AI 도구가 부정적이라는 뜻을 내포하려는 것은 아닙니다. 사실 저도 항상 AI 도구에 의존합니다. AI는 제가 진심으로 좋아하는 방식으로 제 업무 방식을 변화시켰습니다.

하지만, 서사 (narrative)의 변화를 관찰했습니다. 사람들은 "작동하는 무언가를 만들었다"를 "제품을 만들었다"와 동일시하고 있습니다. 이 두 문장은 동일하지 않습니다.

지금 가장 중요한 기술은 프롬프팅 (prompting)이나 바이브 코딩 (vibe-coding)이 아닙니다. 그것은 바로 자신이 무엇을 모르는지 아는 것 — 즉, 여러분의 작동하는 데모가 실제 문제의 5%에 불과하다는 것을 인식하는 것입니다.

→ 데모는 개념을 증명합니다.
→ 제품은 당신이 엣지 케이스 (edge cases)를 이해하고 있음을 증명합니다.
→ 비즈니스는 무언가 고장 났을 때 새벽 3시에도 이를 유지 관리할 수 있음을 증명합니다.

AI는 첫 번째 단계(개념 증명)를 범용화(commodity)했지만, 나머지 두 단계는 여전히 그 어느 때보다 비용이 많이 듭니다.

데모와 실제 프로덕션 (production) 버전 사이에서 여러분이 목격한 가장 큰 격차는 무엇인가요? 여러분의 고군분투담(war stories)을 듣고 싶습니다.