AI 시대의 마차 — 왜 대부분의 AI 앱이 실패하는가 (koomen.dev) ↗

• 대부분의 AI 앱은 “말 없는 마차(Horseless Carriage)” — 기존 소프트웨어 패턴을 그대로 복제하면서 AI의 고유한 강점을 활용하지 못하고 있음
• LLM의 진짜 능력은 텍스트 생성이 아니라 텍스트 변환. 기존 콘텐츠를 분류·요약·응답하는 것이 처음부터 생성하는 것보다 훨씬 유용
• 사용자에게 시스템 프롬프트 편집 권한을 줘야 AI가 제대로 작동함
• Pete Koomen 작성

Gmail Gemini의 실패 사례

• Gmail의 AI 이메일 작성 기능이 만드는 초안은 딱딱하고 장황한 공식 문체
• 실제 사용자의 자연스러운 스타일과 완전히 다름 — “피싱 메일처럼 보인다”
• 직접 쓰는 것보다 오히려 시간이 더 걸림
• 원인: 모델의 능력을 획일적인 인터페이스로 제약하고 있음

시스템 프롬프트 vs 유저 프롬프트

• 시스템 프롬프트 — 모델의 행동 방식을 정의하는 일반 지침. 개발자가 작성하고 반복 사용
• 유저 프롬프트 — 특정 작업에 대한 사용자 입력
• 기존 방식: 개발자가 시스템 프롬프트를 작성하고 사용자는 유저 프롬프트만 제공
• 문제: 에이전트가 사용자를 대신해 행동할 때(이메일, 회계 등), 자기 맥락을 가장 잘 아는 것은 사용자 본인
• 해결: 사용자가 시스템 프롬프트를 직접 편집할 수 있게 해야 함

더 나은 접근법: 이메일 읽기 에이전트

• Gmail의 AI는 이메일을 처음부터 생성하려 함 → 실패
• 더 나은 방식: 에이전트가 이메일을 읽고 분류·우선순위 지정·맥락에 맞는 답장 초안 작성
• 이 방식이 실제로 의미 있는 시간 절약을 만들어냄

개발자의 새로운 역할

• 프롬프트를 직접 작성하는 것이 아니라:
  • 에이전트 구축을 위한 도메인 특화 UI 제작
  • 프롬프트 템플릿과 부트스트래핑 에이전트 개발
  • 에이전트가 행동할 수 있는 안전한 도구(Tool) 구축
  • 텍스트 기반 프롬프트 보안이 아닌 코드 기반 도구로 경계 설정

”말 없는 마차” 비유

• 초기 자동차는 마차 디자인을 그대로 복제 — 나무 프레임, 서스펜션 없음 → 실패
• 현재 AI 앱도 동일한 실수: AI를 기존 소프트웨어의 기능 추가로 취급
• AI 네이티브 소프트웨어는 AI의 능력을 중심으로 처음부터 설계해야 함
• 핵심 원칙: “하기 싫은 일을 컴퓨터에게 가르쳐서, 하고 싶은 일에 시간을 쓸 수 있게 하는 것”

기존 소프트웨어에 AI를 추가하는 것과 AI 네이티브의 차이는?

기존 방식은 정해진 인터페이스에 AI를 끼워넣는 것. AI 네이티브는 사용자가 AI의 행동을 직접 커스터마이징할 수 있도록 시스템 프롬프트 수준의 제어권을 제공하는 것.

LLM이 생성보다 변환에 강하다는 것은 무슨 뜻인가요?

빈 상태에서 텍스트를 만들어내는 것보다, 이미 존재하는 텍스트를 읽고 분류·요약·변환하는 작업에서 LLM이 훨씬 높은 가치를 만든다는 의미. 이메일 작성보다 이메일 분류가 더 유용한 것이 대표적 사례.

---

관련: Sequoia Capital은 AI가 도구가 아닌 결과물을 직접 판매하는 오토파일럿 모델로 전환해야 한다고 분석합니다. Foundation Capital은 AI 에이전트의 의사결정 흔적이 차세대 플랫폼 기회라고 전망합니다.