• Anthropic 해커톤 우승자 ykdojo의 팁 Repo과 Anthropic DevRel Ado Kukic의 Advent of Claude 에서 소개된 팁을 묶어서 정리/번역
• 각 팁마다 실제로 사용할 수 있는 명령어, 스크립트, 설정 파일을 제공

Part 1: 에이전틱 개발자의 사고방식

• 1.1. 큰 문제 정복의 첫걸음: 분해하고 정복하라 (ykdojo #3)
• 1.2. 계획 모드 vs. 욜로 모드 (Ado #18, #19)
• 1.3. 컨텍스트: AI의 기억력을 지배하는 기술 (ykdojo #5, #8, Ado #15)
• 1.4. 올바른 추상화 수준 선택 (ykdojo #32)
• 1.5. 미지의 영역에서 더 용감하게 (ykdojo #35)

Part 2: 기초부터 탄탄하게 – 환경 설정과 필수 명령어

• 2.1. 커스텀 상태 라인으로 모든 것을 한눈에 (ykdojo #0)
• 2.2. 필수 슬래시 명령어 마스터 (ykdojo #1, Ado #4, #16, #17)
• 2.3. CLAUDE.md: AI를 위한 프로젝트 설명서 (Ado #1, #2, ykdojo #30)
• 2.4. 터미널 별칭으로 빠른 접근 (ykdojo #7)
• 2.5. 세션 관리: 대화를 잃지 않는 법 (Ado #9, #10, #11, #12)

Part 3: 생산성을 극대화하는 핵심 기술

• 3.1. 음성으로 코딩하기 (ykdojo #2)
• 3.2. 터미널 출력 추출의 기술 (ykdojo #6)
• 3.3. Cmd+A/Ctrl+A: 전체 선택의 힘 (ykdojo #10)
• 3.4. 마크다운과 Notion 활용 (ykdojo #19, #20)
• 3.5. 키보드 단축키 완전 정복 (Ado #5, #6, #7, #8, ykdojo #38)
• 3.6. Vim 모드로 프롬프트 편집 (Ado #13)
• 3.7. 입력 박스 탐색 및 편집 (ykdojo #38)

Part 4: 컨텍스트 관리의 예술

• 4.1. 선제적 컨텍스트 압축 (ykdojo #8)
• 4.2. 터미널 탭으로 멀티태스킹 (ykdojo #14)
• 4.3. 대화 복제 및 반복제 (ykdojo #23)
• 4.4. /context로 X-Ray 비전 (Ado #15)
• 4.5. realpath로 절대 경로 얻기 (ykdojo #24)

Part 5: Git과 GitHub 워크플로우 완전 정복

• 5.1. Git과 GitHub CLI 프로 활용 (ykdojo #4)
• 5.2. Git worktrees로 병렬 브랜치 작업 (ykdojo #16)
• 5.3. 대화형 PR 리뷰 (ykdojo #26)
• 5.4. 승인된 명령어 감사 (ykdojo #33)

Part 6: 고급 기능 – MCP, Hooks, Agents

• 6.1. MCP: 외부 세계와의 연결 (Ado #22, #23, #24, #25)
• 6.2. Hooks: 규칙의 강제 (Ado #26)
• 6.3. Skills: 재사용 가능한 지식 (Ado #27)
• 6.4. Agents: 전문화된 서브에이전트 (Ado #28)
• 6.5. Plugins: 기능 번들 (Ado #29)
• 6.6. CLAUDE.md vs Skills vs Slash Commands vs Plugins (ykdojo #25)

Part 7: 시스템 최적화와 자동화

• 7.1. 시스템 프롬프트 슬림화 (ykdojo #15)
• 7.2. 장시간 작업을 위한 수동 지수 백오프 (ykdojo #17)
• 7.3. 백그라운드에서 bash 명령 및 에이전트 실행 (ykdojo #36)
• 7.4. 자동화의 자동화 (ykdojo #41)
• 7.5. Headless 모드로 CI/CD 통합 (Ado #30)

Part 8: 컨테이너와 샌드박스

• 8.1. 컨테이너로 위험한 작업 격리 (ykdojo #21)
• 8.2. Sandbox 모드와 권한 관리 (Ado #20)
• 8.3. YOLO 모드: 위험을 감수할 때 (Ado #20)

Part 9: 브라우저 통합과 웹 자동화

• 9.1. 네이티브 브라우저 통합 (Ado #21)
• 9.2. Playwright MCP (Ado #22)
• 9.3. Gemini CLI를 대체 수단으로 (ykdojo #11)

Part 10: 실전 활용 사례

• 10.1. 작성-테스트 사이클 완성 (ykdojo #9)
• 10.2. 자신만의 워크플로우에 투자 (ykdojo #12)
• 10.3. 대화 기록 검색 (ykdojo #13)
• 10.4. 글쓰기 도우미로 활용 (ykdojo #18)
• 10.5. 연구 도구로 활용 (ykdojo #27)
• 10.6. 출력 검증 방법 마스터 (ykdojo #28)
• 10.7. DevOps 엔지니어로 활용 (ykdojo #29)
• 10.8. 범용 인터페이스로 활용 (ykdojo #31)
• 10.9. 테스트 많이 작성 (TDD) (ykdojo #34)
• 10.10. 복잡한 코드 단순화 (ykdojo #40)

Part 11: 고급 패턴과 철학

• 11.1. 계획과 빠른 프로토타이핑의 균형 (ykdojo #39)
• 11.2. 개인화된 소프트웨어 시대 (ykdojo #37)
• 11.3. 사용이 최고의 학습 (ykdojo #22)
• 11.4. 지식 공유 및 기여 (ykdojo #42)
• 11.5. 계속 학습하기 (ykdojo #43)

Part 12: 고급 기능과 SDK

• 12.1. Extended Thinking (Ado #19)
• 12.2. LSP 통합 (Ado #31)
• 12.3. Claude Agent SDK (Ado #31)
• 12.4. 팀 설정과 공유 워크플로우 (Ado #30)

Part 13: 학습 로드맵과 다음 단계

• 13.1. 초급자를 위한 로드맵 (1-3개월)
• 13.2. 중급자를 위한 로드맵 (3-12개월)
• 13.3. 고급자를 위한 로드맵 (1년 이상)
• 13.4. 필독 참고 자료

• AI가 모든 소프트웨어를 작성하는 시대에는 토큰(추론 비용)을 절약하는 소프트웨어가 진화론적 선택 압력을 통해 살아남게 될 것
• 생존 비율 공식을 통해 소프트웨어의 적합도를 측정하며, 인지 절약이 인지 비용을 넘어서는 경우(1을 초과)에만 생존 가능
• Git, grep 같은 도구는 통찰 압축과 기판 효율성 덕분에 AI가 다시 만들어 쓰기에는 비용이 터무니없이 큰 사례
• 에이전트가 도구를 채택하려면 인지도(Awareness) 와 마찰 최소화(Friction) 가 필수적이며, Desire Paths 설계가 효과적
• AI 중심의 시대에도 인간 계수(Human Coefficient) 가 작동해, 인간의 개입과 선호가 직접적인 가치를 만드는 영역은 계속 살아남게 될 것

배경: AI 시대의 소프트웨어 예측

• 2024년 6월 Death of the Junior Developer, 10개월 전 오케스트레이터 도래 예측, Gas Town 프로젝트 등을 통해 AI 발전 곡선을 지속적으로 맞혀옴
• 2023년 코드 자동 완성 → 2024년 대화형 인터페이스 → 2025년 초 에이전트 → 2026년 초 오케스트레이션으로 이어지는 흐름을 외삽해 Gas Town 개발
• 모든 예측의 근거는 지수적 발전 곡선을 그대로 믿는 태도에 있음
• Dario Amodei와 Andrej Karpathy가 소프트웨어의 미래에 대해 말해온 방향을 전적으로 신뢰함
• Gas Town은 이러한 외삽이 실제로 작동함을 보여준 사례로, 2025년 말 모델과 다수의 임시적 보완을 통해 간신히 성립하는 형태를 먼저 확인

위협받는 소프트웨어 생태계

• SaaS 기업에 대한 압력이 증가하며, 구매 대비 구축(build)의 비용 구조가 바뀌어 비즈니스 부서가 직접 바이브 코딩(vibe coding) 으로 자체 SaaS를 만드는 사례 확산
• 불과 3년 전 GPT-3.5가 단일 함수 작성도 버거웠던 것과 달리, 현재는 소규모지만 실질적 가치가 있는 SaaS를 직접 생성 가능
• Stack Overflow와 Chegg가 초기 타격을 받았고, 이후 Tier-1 고객 지원 소프트웨어, 로우코드·노코드 시스템, 콘텐츠 생성 도구, 각종 생산성 도구로 압박이 확산
• IDE 벤더들 역시 Claude Code 등장 이후 경쟁 압력을 체감하기 시작
• AI 연구자들의 예측이 약 40 년간 높은 정확도를 보여왔다는 점에서, 모든 소프트웨어 영역이 위협받을 가능성을 전제로 대비 필요

선택 압력 모델(Selection Argument)

• 추론에는 토큰이 필요하고, 토큰 소비는 에너지 사용으로 이어지며, 에너지는 곧 비용으로 환산됨
• {토큰, 에너지, 돈}은 동일한 자원 제약으로 취급 가능하며, 항상 제한된 상태로 존재
• 인지 비용을 줄이는 소프트웨어가 살아남는다는 단순한 규칙이 소프트웨어 생태계 전반을 형성
• 제한된 자원 환경에서 더 효율적으로 자원을 사용하는 개체가 그렇지 못한 개체를 밀어내는 진화론적 선택 압력과 동일한 구조

생존 비율(Survival Ratio) 공식

• Survival(T) ∝ (Savings × Usage × H) / (Awareness_cost + Friction_cost)
• Savings: 도구를 사용함으로써 절약되는 인지 비용, 즉 동일한 기능을 처음부터 합성할 때 대비 절감되는 토큰량
• Usage: 도구가 다양한 상황에서 반복적으로 사용될 수 있는 빈도와 적용 범위
• H (Human Coefficient): 효율성과 무관하게 인간이 만든 것에 가치를 두는 수요를 반영하는 계수
• Awareness_cost: 에이전트가 해당 도구의 존재를 알고, 기억하고, 적절한 순간에 선택하는 데 드는 에너지
• Friction_cost: 실제 사용 과정에서 발생하는 오류, 실패, 재시도, 오해로 인해 소모되는 에너지
• 생존을 위한 최소 비율은 1이며, 경쟁이 존재하는 환경에서는 이보다 훨씬 높은 비율 요구
  • 예: 생존 비율이 1.2인 도구는 2.5를 기록하는 경쟁 도구에 의해 밀려날 수 있음

레버 1: 통찰 압축(Insight Compression)

• 소프트웨어 산업이 오랜 시간에 걸쳐 축적해 온 다시 발견하기에 지나치게 비싼 지식을 재사용 가능한 형태로 압축
• Git 이 대표 사례로, 커밋 DAG, 포인터로서의 참조(ref), 인덱스, reflog 등은 수십 년간의 시행착오가 응축된 구조
  • AI가 이를 처음부터 재구현하려면 동일한 지적 역사를 다시 밟아야 하므로 경제적으로 전혀 합리적이지 않음
• 데이터베이스, 컴파일러, 운영체제, 워크플로우 엔진, 모니터링 시스템 전반에 동일한 원리 적용
• Kubernetes 는 설계가 복잡해서가 아니라, 분산 시스템 자체가 본질적으로 복잡하기 때문에 복잡함
• Temporal 은 멱등성 재시도와 함께 saga 패턴을 직접 구현하는 일이 사실상 연구 프로젝트에 가깝기 때문에, 이를 대신하는 내구성 실행(durable execution) 을 제공
• 강한 소프트웨어의 공통된 특성은 다시 합성하려는 시도 자체가 터무니없게 느껴질 정도의 통찰 밀도
• Gas Town에서의 캐릭터 역할 모델이나 gt sling 같은 동사 역시, 복잡한 개념을 짧고 기억하기 쉬운 표현으로 압축한 사례

레버 2: 기판 효율성(Substrate Efficiency)

• grep 은 재발명이 사실상 미친 짓에 가까운 또 하나의 사례
• Ken Thompson이 오후 한나절에 만들 정도로 단순하지만, CPU 기반 처리를 통해 막대한 인지 비용을 절약
• 텍스트 패턴 매칭에서는 CPU가 GPU를 여러 자릿수 차이로 압도
• LLM의 곱셈 방식은 패턴 매칭을 조합해 “대략 94쯤”을 먼저 추정하고, 이후 기억된 룩업 테이블로 자릿수를 보정하는 형태
  • 이 계산이 모두 GPU 추론 단계라는 극도로 비효율적인 기판 위에서 수행됨
• 계산기, 파서, ImageMagick 같은 복잡한 변환 도구, 다수의 Unix CLI 유틸리티가 이 레버를 적극 활용
• 좋은 알고리듬을 적용하거나, 계산을 CPU·인간 등 더 저렴한 기판으로 이동시켜 토큰과 에너지 소비를 절약

레버 3: 광범위한 유용성(Broad Utility)

• 생존 비율 모델에서 Usage 항목에 해당
• 사용 범위가 넓을수록 인지도 비용이 분산되고, 개별 사용 시 요구되는 토큰 절약 임계값이 낮아짐
• 진정으로 범용적인 토큰 절약 도구는 AI가 이론적으로 재구현할 수 있더라도, 이미 어디에나 존재하고 널리 쓰이는 선택지가 우선됨
• Temporal 은 상대적으로 높은 인지도 비용과 마찰 비용에도 불구하고 PostgreSQL 만큼 범용적인 워크플로우 모델 제공
  • 공격적인 통찰 압축, 계산 기판의 능숙한 활용, 광범위한 유용성이라는 세 가지 레버를 모두 보유
• Dolt 는 Git으로 버전 관리되는 데이터베이스로, 8년간 유지되어 온 오픈소스 프로젝트
  • 에이전트 기반 프로덕션 및 DevOps 워크플로우에서 뒤늦게 킬러 앱을 발견
  • 에이전트가 프로덕션 환경에서 실수하더라도 Git의 전체 기능을 활용해 롤백·롤포워드 가능
• 코드 검색 엔진은 LLM이 기존 대비 10배에서 100배 더 많은 코드를 생성하면서 중요성이 급격히 상승
  • grep이 감당할 수 없는 규모의, 이른바 “너무 커서 grep으로는 안 되는 영역” 이라는 대규모 범용 틈새 형성
  • 발견하기 어려운 엣지 케이스가 많은 비자명한 문제를 해결하고, 저렴한 계산 기판을 사용하며, 범용적 적용이 가능한 점에서 세 가지 레버를 모두 충족

레버 4: 홍보(Publicity)

• 인지 비용 절약만으로는 충분하지 않으며, 인지도 문제, 즉 사전 선택 단계에서의 문제 해결 필요
• Dolt는 레버 1~3을 모두 갖췄지만, 초기에는 레버 4가 부족해 널리 사용되지 못한 사례
• 인지도 비용을 지불하는 방법은 여러 가지 존재
  • 훌륭한 제품을 만들고 인기를 얻은 뒤, 커뮤니티를 통해 자연스럽게 훈련 데이터에 포함되기를 기다리는 방식
  • 또는 비용을 투입해 에이전트용 문서화에 투자하거나 광고 집행
• 보다 직접적인 방법으로, OpenAI, Anthropic, Google 같은 프론티어 랩의 담당자와 협력해 모델 훈련 과정에 도구를 포함
  • 유료 서비스 형태로, 도구의 올바른 사용과 오용을 모두 보여주는 eval을 제작한 뒤 연구자들이 훈련을 조정
• 에이전트를 위한 SEO 개념이 본격적으로 등장 중
• 대규모 예산을 투입하기 어렵다면, 사후 선택 단계에서의 에너지, 즉 레버 5에 의존해야 하며, 이를 위해 도구를 최대한 에이전트 친화적으로 설계 필요

레버 5: 마찰 최소화(Minimizing Friction)

• 인지도가 사전 선택 단계의 문제라면, 제품 마찰은 사용 이후 단계의 문제
• 에이전트는 항상 시간에 쫓기는 것처럼 행동하며, 무언가 막히면 즉시 우회 경로를 시도
• 마찰이 조금만 있어도 판단이 바뀌어, 더 효율적인 도구 대신 덜 효율하지만 익숙하고 예측 가능한 방법으로 후퇴
• 반대로 취향에 정확히 맞게 설계된 도구는 에이전트가 집요할 정도로 반복 사용
• 문서화 접근법은 훈련 단계가 아닌 추론 시점까지 인지 비용을 미루는 방식
  • 도구가 무엇을 잘하는지, 언제 왜 써야 하는지, 빠른 시작 가이드와 후속 문서 경로를 컨텍스트에 직접 주입
• 그러나 더 나은 해법은 에이전트에게 직관적으로 느껴지는 도구 자체를 만드는 것
• Desire Paths 설계 사례로, Beads 는 4개월간 100개가 넘는 하위 명령과 다수의 하위-하위 명령, 별칭, 대체 문법을 거치며 CLI가 진화
  • 이 복잡한 CLI는 인간이 아니라 에이전트의 사용 패턴을 위해 설계됨
  • 에이전트가 시도하는 방식을 관찰해 환각을 실제 기능으로 구현, 이제는 거의 모든 추측이 그대로 동작
• 환각 스쿼팅(Hallucination Squatting) 은 LLM이 자주 환각하는 도메인 이름을 역으로 추적해 등록하고, 해당 주소에 아티팩트를 올려 실제로 다운로드하게 만드는 기법
  • 국가 단위의 해커 집단조차 Agent UX를 이해하고 활용한다는 점이 드러남
• Agent UX는 결정적으로 중요하지만 아직 대부분의 도구에서 간과되고 있음
• 이상적인 도구는 에이전트가 이미 익숙한 다른 도구와 닮아 있거나, 문제를 에이전트가 사고하고 싶어하는 방식 그대로 풀어주는 구조

레버 6: 인간 계수(Human Coefficient)

• 토큰 효율성과 무관하게, 인간이 개입했다는 사실 자체로 가치를 얻는 소프트웨어 존재
• 인간 큐레이션, 사회적 증거, 창의성, 물리적 존재감, 승인 같은 요소에서 가치가 파생
• 인간이 고른 플레이리스트는 품질이 동등하고 에너지 효율이 더 높은 AI 생성 플레이리스트를 이길 수 있음
• 게임 분야에서는 실제 인간이 있는 환경이 대체로 승리하며, 명백히 인간보다 강한 AI와만 플레이하고 싶어하는 경우는 드묾
• 에이전트를 배제하는 소셜 네트워크가 오히려 매력적으로 인식될 가능성
• AI가 최고의 교사가 되더라도, 일부 사람들은 의도적으로 인간 교사를 선택할 것
• 높은 Human Coefficient를 가진 영역에서도 경쟁은 치열함
  • Karpathy가 그리는 세계에서 에이전트는 누구에게나 무엇이든 될 수 있고, 본질적으로 강한 중독성을 가짐
• 결과적으로 극단적으로 비효율적이지만 H 값이 매우 높은 소프트웨어가 다수 존재하게 될 가능성

희망의 근거

• 인간과 AI 사이를 중개하거나, AI가 곧 직접 수행할 수 있게 될 “똑똑한 척하는 역할” 을 맡은 소프트웨어는 구조적으로 위험
• 그럼에도 불구하고 작성되어야 할 소프트웨어의 양은 사실상 무한
  • 모든 질병 치료, 모든 단백질의 거동 모델링, 모든 행성 탐사 시나리오가 여전히 대상
• 인간의 야망은 항상 가용한 인지 능력을 초과하며, 토큰 비용이 하락하더라도 우리는 곧바로 더 먼 프론티어로 이동
• 주의 집중 문제는 인쇄 매체, 인터넷, 소셜 미디어, 실시간 광고, 애그리게이터를 거치며 이미 여러 차례 해결된 경험 보유
• Desire Paths 설계가 실제로 효과적이며, OpenAI 같은 곳의 대규모 훈련 예산 없이도 에이전트가 자연스럽게 쓰고 싶어하는 도구를 만들 수 있음
• 인간 계수는 분명히 존재하며, 사람들은 이미 에이전트 냄새가 짙은 것에 피로감을 느끼기 시작
  • 인간 간의 연결과 창의성을 중심에 두고 설계하면, 결국 문제는 다시 전통적인 마케팅과 브랜딩의 영역으로 수렴
• 여섯 가지 레버가 제공하는 다양한 생존 경로가 존재
• 다시 만들려는 시도 자체가 미친 짓처럼 느껴지는 것을 구축하고, 발견하기 쉽고 사용하기 쉽게 만든다면 충분히 견고한 가능성 확보

[출처] https://news.hada.io/topic?id=26413 

• 200개의 AI 스타트업을 리버스 엔지니어링한 결과, 다수의 기업이 자체 기술을 보유했다고 주장하면서 실제로는 외부 API를 호출하는 형태로 운영됨
• 조사된 기업 중 73%가 OpenAI나 Claude API를 그대로 사용하며, 여기에 단순한 UI나 기능을 덧붙인 수준으로 확인됨
• 자사 “고유 LLM” 을 내세우는 스타트업 상당수가 실제로는 api.openai.com에 요청을 보내는 GPT-4 래퍼에 불과했고, 단순 시스템 프롬프트만 얹은 구조로 수십~수백 배 마진을 붙여 판매하고 있음
• RAG 아키텍처를 강조하는 서비스 대부분도 OpenAI text-embedding-ada-002 · Pinecone/Weaviate · GPT-4를 조합한 표준 40줄짜리 스택을 “고유 인프라”로 포장하고 있었으며, 1M 쿼리 기준 월 약 3만 달러 비용에 15만~50만 달러 매출로 80~94% 마진 구조를 보이는 상황
• 반대로 전체의 27% 는 “Built on GPT-4”처럼 스택을 투명하게 밝히는 래퍼 회사, 실제로 자체 모델을 학습하는 빌더, 멀티모델 투표·에이전트 프레임워크 등 실제 기술적 차별점을 가진 팀들로 구성됨
• 조사 결과, 많은 AI 스타트업이 API 기반 서비스 비즈니스임에도 “고유 AI 인프라”를 내세우는 구조가 드러났고, 투자자·고객·개발자 모두가 DevTools로 네트워크 탭만 열어도 검증 가능하다는 점을 강조하며 AI 생태계에 정직한 기술 공개가 필요하다는 걸 강조

개요

• 외부 투자를 받은 AI 스타트업 200곳의 웹 애플리케이션을 대상으로, 네트워크 트래픽·코드·API 호출을 추적해 마케팅 주장과 실제 기술 스택의 차이를 분석함
  • 출발점은 “고유 딥러닝 인프라”를 주장하는 한 회사가 실제로는 OpenAI API만 콜하고 있다는 의심에서 시작
  • 이 회사는 4.3M 달러 투자를 받았고, “근본적으로 다른 인프라를 구축했다”는 스토리로 자금 조달을 진행한 상태였음
• 조사 결과 73% 회사에서 주장하는 기술과 실제 구현 간에 의미 있는 괴리가 발견되었고, 상당수가 서드파티 모델 API를 단순 래핑한 구조였음
  • 조사 대상은 YC·Product Hunt·LinkedIn “We’re hiring” 포스트 등에서 수집한 AI 스타트업 200곳이며, 설립 6개월 미만 회사는 제외했고 외부 자금 유치와 구체적 기술 주장이 있는 곳에 집중함
  • 조사 방식은 패시브한 브라우저 개발자 도구 수준에서 이뤄졌으며, 비공개 시스템 접근·인증 우회·TOS 위반 없이 진행되었음

조사 방법(Methodology)

• Playwright·aiohttp 등을 이용해 자동화된 분석 파이프라인을 구성하고, 각 스타트업 사이트에 대해 공통적으로 세 가지를 수집함
  • capture_network_traffic(url)로 네트워크 헤더와 요청 패턴을 캡처
  • extract_javascript(url)로 JS 번들 디컴파일 및 분석
  • monitor_requests(url, duration=60)으로 60초 간 API 호출 패턴을 추적
• 각 사이트별로 다음 정보를 구조화해 기록함
  • claimed_tech: 마케팅 카피·웹 문구에 나타난 기술 주장
  • actual_tech: HTTP 헤더·JS 번들·API 호출로 확인한 실제 스택
  • api_fingerprints: 호출 도메인·헤더·지연 시간 등으로 추출한 서드파티 API 지문
• 크롤링 기간은 3주였으며, 모든 패턴은 공개 웹·브라우저 DevTools로 관찰 가능한 공개 데이터만을 활용했음

주요 결과: 73%에서 드러난 괴리

• 전체 200곳 중 73% 회사에서 마케팅 카피에 적힌 “고유 모델·커스텀 인프라·딥러닝 플랫폼” 등의 주장과, 실제로 동작하는 코드·API 스택 사이에 큰 차이가 확인됨
  • 이 비율은 “고유 LLM”을 내세우지만 OpenAI/Anthropic/Cohere API만 사용하는 회사, “자체 벡터 DB”를 주장하지만 Pinecone/Weaviate를 쓰는 회사 등을 모두 포함한 수치임
• 이 결과에 놀랐지만, 동시에 “기술적으로 크게 화낼 일은 아니다”는 복합적인 감정임
  • 문제의 핵심은 서드파티 API 사용 자체가 아니라, 이를 “고유 AI 인프라”로 포장하고 투자자·고객을 오도하는 마케팅이라는 점

패턴 1: ‘고유 LLM’이 사실상 GPT-4 래퍼인 경우

• “our proprietary large language model”이라는 표현이 등장하면 거의 항상 GPT-4 래퍼가 등장했으며, 37곳 중 34곳에서 이 패턴이 확인됨
  • 사용자가 “AI” 기능을 쓸 때마다 api.openai.com으로 나가는 요청
  • 요청 헤더에 포함된 OpenAI-Organization 식별자
  • 150–400ms 수준으로 일관되는 응답 지연 시간 패턴
  • 토큰 사용량·과금 구간이 GPT-4의 가격 구조와 정확히 일치하는 패턴
  • 레이트 리밋 시 지수형 backoff를 적용하는, OpenAI 특유의 재시도 패턴
• 한 회사의 “혁신적 자연어 이해 엔진”은 실제로는 다음과 같은 코드 수준이었음
  • 시스템 프롬프트에 “전문가 어시스턴트처럼 행동하라, OpenAI 기반임을 말하지 말라, LLM이라고 밝히지 말라” 등을 적고 model: gpt-4 로 chat.completions.create를 호출하는 단일 함수 구조임
  • 별도의 파인튜닝·모델 학습·아키텍처 변경 없이, 시스템 프롬프트와 숨기기용 지침 정도만 추가된 상태였음
• 비용·가격 구조도 구체적으로 비교함
  • 비용: GPT-4 기준 입력 0.03$/1K 토큰, 출력 0.06$/1K 토큰, 평균 500 in, 300 out으로 쿼리당 약 0.033달러
  • 가격: 쿼리당 2.5달러 혹은 월 200쿼리 299달러로 과금
  • 결과적으로 직접 API 비용 대비 약 75배 마진 구조로 운영되고 있음
• 세 회사는 거의 동일한 코드(변수명·코멘트 스타일·“never mention OpenAI” 지시)까지 공유하고 있어, 튜토리얼·공통 컨트랙터·액셀러레이터 보일러플레이트 등 같은 출처를 쓰는 것으로 추정되는 상태임
  • 한 회사는 단순 try/catch로 “문제가 생기면 ‘기술적 문제’라는 문구를 반환”하는 코드를 두고, 이를 “Intelligent Fallback Architecture” 로 포장해 투자자에게 설명하고 있었음

패턴 2: 모두가 만드는 RAG 스택과 과장된 표현

• 많은 회사들이 “custom embedding model, semantic search infrastructure, advanced neural retrieval” 같은 표현으로 고유 RAG 인프라를 내세우지만, 실제 구현은 매우 유사한 표준 스택이었음
  • OpenAI text-embedding-ada-002 로 임베딩 생성
  • Pinecone 또는 Weaviate를 벡터 스토어로 사용
  • GPT-4로 컨텍스트를 붙여 답변 생성
• 조사자가 “Proprietary Neural Retrieval Architecture”라는 이름으로 소개된 코드를 디컴파일해 본 결과, 약 40줄짜리 Python 코드로 위 세 단계를 그대로 호출하는 구조였음
  • 질문을 임베딩으로 변환
  • 벡터 DB에서 top-k 문서 검색
  • 검색된 텍스트를 이어 붙여 GPT-4에 system 메시지로 전달
  • 사용자 질문을 user 메시지로 함께 보내 답변을 생성
• 비용·가격 구조 역시 매우 큰 차이를 보임
  • OpenAI 임베딩: 1K 토큰당 0.0001달러
  • Pinecone 쿼리: 호출당 0.00004달러
  • GPT-4 completion: 1K 토큰당 0.03달러
  • 합산 시 쿼리당 약 0.002달러 수준 비용
  • 실제 고객 과금은 쿼리당 0.5~2달러로, API 비용 대비 250~1000배 마진이 발생하는 구조임
• 42개 회사가 이와 거의 동일한 스택과 코드 구조를 사용했고, 추가 23개 회사는 90% 이상 비슷한 패턴을 공유함
  • 차이점은 주로 Pinecone vs Weaviate 선택 여부, 변수명, Redis 캐시 추가 여부 정도였음
  • Redis 캐시를 붙이고 이를 “optimization engine”, 재시도 로직을 붙이고 이를 “Intelligent Failure Recovery System” 같은 이름으로 마케팅하는 사례도 등장
• 월 100만 쿼리 수준의 스타트업 경제성도 계산해봄
  • 비용: 임베딩 약 100달러, Pinecone 호스팅 약 40달러, GPT-4 completion 약 3만 달러, 총 약 3만140달러/월
  • 매출: 15만~50만 달러/월
  • 80~94% 수준의 높은 매출 총이익률을 갖는 비즈니스 구조

패턴 3: ‘우리가 직접 파인튜닝했다’의 실제 의미

• “우리가 직접 모델을 파인튜닝했다”는 표현을 쓰는 회사들에 대해 인프라를 추적한 결과, 크게 두 부류로 나뉨
  • 소수(약 7%)는 실제로 AWS SageMaker, Google Vertex AI 등을 통해 자체 학습 잡을 돌리고, S3 버킷에 모델 아티팩트를 저장한 뒤, 별도 인퍼런스 엔드포인트와 GPU 인스턴스 모니터링을 운영하고 있는 경우임
  • 다수는 OpenAI의 fine-tuning API를 사용하고 있었고, 사실상 “OpenAI에 예시 데이터와 프롬프트를 넘겨 저장하는 수준”에 가까운 구조였음
• 전자(실제 자체 학습)는 학습 인프라와 배포 파이프라인이 브라우저에서 관찰되는 수준으로도 어느 정도 드러나지만, 후자는 대부분 단일 OpenAI 엔드포인트 호출로 표현되는 차이가 있음

래퍼 회사를 빠르게 구분하는 방법

• 네트워크 트래픽 패턴

  • 브라우저에서 DevTools(F12) → Network 탭을 열고, 서비스의 AI 기능을 사용하는 동안 나가는 요청을 보면 간단한 구분이 가능
    • api.openai.com
    • api.anthropic.com
    • api.cohere.ai
    • 등과 같은 도메인이 직접 등장하면, 기본적으로 서드파티 모델 API 래퍼로 볼 수 있음
  • 응답 지연 시간도 지문 역할을 함
    • 특히 OpenAI API의 경우 200~350ms 구간에 응답이 몰리는 특유의 레이턴시 패턴이 있어, 이를 통해 백엔드 모델을 추정할 수 있음

• 자바스크립트 번들과 키 노출

  • 페이지 소스 및 JS 번들 검색에서 다음 키워드를 찾아보는 것도 간단한 방법
    • openai, anthropic, claude, cohere, sk-proj-(OpenAI 프로젝트 키 프리픽스) 등
  • 조사 과정에서 12개 회사가 API 키를 프런트엔드 코드에 그대로 포함한 채 배포하고 있었고, 이에 대해 제보 메일을 보냈지만 어떤 회사도 답하지 않았음

• 마케팅 언어 매트릭스

  • 마케팅 카피에 나타나는 언어와 실제 기술 구현 간의 패턴을 표 형태로 정리해 “Marketing Language Matrix”라고 표현
    • “GPU 인스턴스 유형, 서빙 아키텍처, 모델 크기” 등 구체적인 기술 용어가 등장하는 경우, 실제로 어느 정도 독자적인 인프라를 갖고 있을 가능성이 더 높았음
    • 반대로 “advanced AI”, “next-gen intelligence”, “proprietary neural engine”처럼 추상적 버즈워드만 반복될수록, 내부는 서드파티 API 래퍼일 가능성이 높았음

인프라 현실 지도와 AI 스타트업 지형

• 글에서는 여러 다이어그램을 통해 현재 AI 스타트업의 인프라 현실 지도를 정리함
  • 다수의 스타트업이 OpenAI·Anthropic·Cohere 등 모델 제공자 위에 얇은 애플리케이션 레이어를 얹은 형태로 존재하는 구조
  • 각 레이어 위에 “워크플로우·UX·도메인 데이터·파이프라인” 등에서 차별화를 시도하는 서비스들이 쌓여 있는 구조임
• 이러한 구조를 바탕으로, AI 스타트업의 상당 부분이 실질적으로는 서비스/플랫폼 비즈니스이며, “고유 AI 인프라 기업”이라는 자기 인식과 괴리가 있는 상태

왜 이 문제를 신경 써야 하는가

• “잘 동작한다면 상관없지 않냐”는 질문에 대해, 조사자는 네 가지 이해관계자 관점에서 이유를 정리함
  • 투자자: 현재 상당수 회사에 투자되는 자금은 AI 연구·모델 개발이 아니라, 실질적으로는 프롬프트 엔지니어링과 워크플로우 레이어에 투입되고 있음
  • 고객: 실제 API 비용에 10배 이상 프리미엄을 얹은 가격을 내고 있으며, 비슷한 기능을 주말 프로젝트 수준으로 직접 구현할 수 있는 경우가 많음
  • 개발자: 겉으로 보이는 “AI 스타트업”의 화려함에 비해, 실제로는 낮은 진입 장벽의 래퍼 서비스인 경우가 많아, 스스로도 비슷한 것을 단기간에 만들 수 있음을 인식할 필요가 있음
  • 생태계: “AI 회사”의 73%가 기술을 과장·오도하는 상황은, 전체적으로 버블에 가까운 상태를 의미하며 건강하지 않은 인센티브를 만듦

래퍼 스펙트럼: 모든 래퍼가 나쁜 것은 아님

• “Wrapper Spectrum”이라는 도표를 통해, 래퍼 회사에도 질적으로 다른 층위가 있음을 설명함
  • 한쪽 끝에는 단순히 서드파티 API에 얇은 UI만 입힌 수준의 래퍼가 있음
  • 다른 한쪽 끝에는 도메인 특화 워크플로우·우수한 UX·모델 오케스트레이션·가치 있는 데이터 파이프라인 등을 제공하는 고급 래퍼가 있음
• 핵심 메시지는 “래퍼인지 여부”가 아니라 정직성·가치 제공 방식에 있음
  • 서드파티 API를 쓰면서도 이를 투명하게 공개하고, 문제 해결·경험·데이터에서 차별화를 만드는 회사는 긍정적으로 평가됨

제대로 하고 있는 27%

• Category 1: 투명한 래퍼(Transparent Wrappers)

  • 이 그룹의 회사들은 홈페이지에 “Built on GPT-4” 같은 문구를 명시적으로 적고, 자신들이 판매하는 것은 워크플로우·UX·도메인 지식이라는 점을 분명히 함
    • 예: GPT-4 + 법률 템플릿 조합으로 법률 문서 자동화를 제공하는 서비스
    • 예: Claude 기반으로 고객 지원 티켓 라우팅에 특화한 서비스
    • 예: 여러 모델과 휴먼 리뷰 프로세스를 결합한 콘텐츠 워크플로우 서비스

• Category 2: 실제 빌더(Real Builders)

  • 이 그룹은 실제로 자체 모델을 학습하고 있는 회사들임
    • 의료 분야에서 HIPAA 준수를 위해 셀프 호스팅 모델을 운영하는 헬스케어 AI
    • 금융 분석에 커스텀 리스크 모델을 학습·운영하는 서비스
    • 산업 자동화에서 특수한 컴퓨터 비전 모델을 개발·배포하는 서비스

• Category 3: 혁신적 조합(Innovators)

  • 여기에는 서드파티 모델을 사용하지만, 그 위에 실질적으로 새로운 구조를 쌓은 회사들이 포함됨
    • 여러 모델의 출력을 조합해 투표 기반 정확도 향상을 구현한 시스템
    • 메모리·에이전트 프레임워크를 만들어 복잡한 태스크를 수행하는 시스템
    • 새로운 형태의 리트리벌 아키텍처를 도입한 사례 등
  • 이들 회사는 자신들의 아키텍처를 자세히 설명할 수 있으며, 실제로 스스로 구축한 구조를 가지고 있다는 공통점이 있음

배운 점: 스택보다 문제, 그리고 정직성

• 3주간의 조사 결과, 다음과 같이 요약 가능
  • 기술 스택 자체보다 해결하려는 문제가 더 중요하며, 실제로 가장 뛰어난 제품들 중 상당수는 “단지 래퍼”라고 부를 수 있는 구조였음
  • 다만, 정직함은 별도의 차원으로 중요하고, 스마트한 래퍼와 사기성 래퍼의 차이는 투명성에 있음
  • AI 골드러시는 “고유 AI”를 요구하는 투자자·고객의 기대 때문에 거짓된 주장을 하도록 압박하는 인센티브를 만들고 있음
  • 그리고 API 위에서 구축하는 것 자체는 부끄러운 일이 아니며, 문제는 이를 숨기고 “고유 신경망 아키텍처”로 포장하는 행위임

평가 프레임워크와 실질적 조언

• 48시간 복제 가능성 테스트

  • 모든 “AI 스타트업”을 평가하는 간단한 기준을 제안함
    • “그들의 핵심 기술을 48시간 안에 복제할 수 있는가?”
    • 그럴 수 있다면, 기술적으로는 래퍼에 해당하며,
      • 스택을 솔직하게 밝힌다면 괜찮은 회사
      • “고유 AI 인프라”를 주장하며 숨긴다면 피해야 할 회사로 봐야 한다는 구조임

• 창업자를 위한 조언

  • 창업자에게는 다음과 같은 원칙을 제안함
    • 스택에 대해 정직하게 공개할 것
    • UX·데이터·도메인 전문성으로 경쟁할 것
    • 만들지 않은 것을 만들었다고 주장하지 않을 것
    • “Built with GPT-4”는 약점이 아니라 정직한 설명이라는 점을 받아들일 것

• 투자자를 위한 조언

  • 투자자에게는 다음과 같은 검증 포인트를 제시함
    • 아키텍처 다이어그램을 요구할 것
    • OpenAI·Anthropic 등 API 청구서를 요청해 실제 의존도를 확인할 것
    • 래퍼 회사는 래퍼 회사로서 적절히 가치평가할 것
    • 정직하게 스택을 공개하는 팀을 인센티브로 보상할 것

• 고객을 위한 조언

  • 고객에게는 아래와 같은 실천 항목을 제안함
    • 브라우저에서 네트워크 탭을 열고 나가는 요청을 확인할 것
    • 인프라와 모델 사용 방식에 대해 직접 질문할 것
    • API 호출에 불필요한 10배 이상의 마크업을 내고 있지 않은지 검토할 것
    • 기술 주장보다 실제 결과와 문제 해결 능력 기준으로 평가할 것

‘AI 스타트업’의 실체 한 줄 요약

• “대부분의 ‘AI 스타트업’은 직원 비용 대신 API 비용을 쓰는 서비스 비즈니스에 가깝다”
  • 이는 잘못된 비즈니스 모델이 아니라, 그 자체로 인정하고 정직하게 설명해야 할 현실

조사 이후 전개와 반응

• 1주 차: 원래는 20~30% 정도가 서드파티 API를 사용할 것이라고 예상했으나, 결과가 훨씬 컸음을 언급함
• 2주 차: 한 창업자는 조사자에게 “어떻게 우리 프로덕션 환경에 들어왔냐”고 물었고, 조사자는 브라우저 네트워크 탭만 본 것이라고 설명함
• 3주 차: 두 회사는 조사 결과를 내려달라고 요청했지만, 기사에서는 특정 회사 이름을 공개하지 않았고 지금도 그 상태를 유지 중이라고 밝힘
• 어제: 한 VC가 다음 이사회 전에 포트폴리오 회사들을 감사(audit) 해 달라고 요청했고, 조사자는 이를 수락했다고 언급함

데이터·도구 공개 계획

• 이번 연구를 바탕으로 방법론과 도구를 공개할 계획임

• GitHub에 공개 예정인 내용(무료)

  • 완전한 스크래핑 인프라 코드
  • API 지문(fingerprint)을 추출하는 기법들
  • 누구나 실행해볼 수 있는 감지 스크립트
  • 주요 AI API별 응답 시간 패턴 모음

• 심화 분석(멤버 전용)

  • 월 3,300만 달러 가치평가를 받은 “AI 유니콘” 이 실제로는 월 1,200달러 OpenAI 비용만 쓰고 있는 케이스
  • “1억 파라미터 모델”이라고 소개하면서 실제로는 시스템 프롬프트 3개로 구성된 구조
  • 공개적으로 서빙되는 프로덕션 코드(클라이언트 측, 익명화된 스니펫)
  • 래퍼를 즉시 드러내는 5가지 질문 프레임워크
  • 투자자 프레젠테이션과 실제 인프라를 비교한 사례 연구들

마지막 메시지와 ‘정직한 AI 시대’ 필요성

• 조사는 회사 이름을 공개하지 않고 패턴만 공유하는 방식으로 진행되었으며, 시장은 결국 투명성을 보상할 것이라는 믿음을 강조함
• 실제로 18개 회사는 진정한 의미에서 새로운 기술을 만들고 있는 것이 확인되었고,
  • 이들에 대해서는 “당신들은 스스로 누구인지 알고 있다, 계속 만들라” 는 응원의 메시지를 보냄
• 조사 이후 7명의 창업자가 개인적으로 연락을 취했으며,
  • 일부는 방어적이었고, 일부는 감사해했고, 세 명은 “proprietary AI”에서 “best-in-class APIs 위에 구축”으로 마케팅 전환을 돕는 방법을 요청함
  • 한 창업자는 “우리가 거짓말한다는 걸 알고 있었다, 투자자들이 그걸 기대했고, 다들 그러고 있다, 이제 어떻게 멈춰야 하느냐”라고 털어놓았다고 전함
• 기사 말미에서, AI 골드러시는 끝나지 않겠지만 정직의 시대가 시작돼야 한다는 메시지를 재차 강조하며, 누구나 DevTools의 Network 탭(F12) 만 열어보면 스스로 진실을 확인할 수 있다고 정리

[출처] https://news.hada.io/topic?id=24586&utm_source=weekly&utm_medium=email&utm_campaign=202548