AI.Engineer 컨퍼런스 강연 | 2026-07-09
계층 1: 영상 전체 핵심 주장 요약
Theo Browne(유튜버/개발자)은 AI 모델의 급격한 진화로 인해 소프트웨어 개발에 대해 우리가 알고 있던 모든 것이 근본적으로 바뀌었다고 주장한다. Sonnet 3.5(도구 호출 시대) → Opus 4.5(장기 작업 시대) → Mythos/Fable(오케스트레이션 시대)로 이어지는 모델 진화는 단순한 성능 향상이 아니라 패러다임 전환이다. 개발자들은 터미널, Vim, 특정 언어에 대한 집착 등 "스큐어모픽 사고"에 갇혀 있으며, iOS 7이 그랬듯 지금은 익숙한 것을 버리고 AI 시대에 맞는 새로운 인터페이스와 접근 방식을 수용해야 할 때다. 가장 중요한 변화는 스케일의 민주화: 과거에 스타트업 수준의 프로젝트였던 것이 이제는 부업이 되었고, "너무 크다"고 여겨졌던 것들(AWS 경쟁, Salesforce 도전)이 이제 현실적인 목표가 되었다. 개발자들은 자신이 중요하다고 여겨왔던 것들(언어 선택, 코드 보존, 도구 집착)에 의문을 품고 더 큰 야망을 가져야 한다.
계층 2: 섹션별 상세 내용
섹션 1: AI 정신병의 시작 — 모델 진화의 3단계
[초반부] Theo는 자신이 경험한 "AI 정신병(AI psychosis)"을 청중과 공유하면서 시작한다.
Sonnet 3.5 시대: 도구 호출(Tool Call)의 시작
- Sonnet 3.5는 최초의 Tool Call 모델이 아니었지만, 코드베이스 환경에서 일상 코딩 작업에 충분히 일관되고 안정적으로 도구 호출을 수행한 첫 번째 모델
- 이전과는 달리 엔드 투 엔드 작업을 완수할 수 있게 됨
- "여러 단계를 거쳐야 하는 실제 작업"을 수행할 수 있는 수준
Opus 4.5 시대: 장기 작업(Long Context) 처리
- 단계별로 유도하지 않아도 원하는 바를 말하면 대부분 알아서 처리
- 몇 분이 아닌 몇 시간이 걸리는 작업을 완료할 수 있는 수준
- "좋아요, 다음 부분 만들어주세요"가 필요 없어짐
- 이 시기(작년 11~12월)가 Theo의 "AI 정신병" 시작점
Mythos/Fable 시대: 오케스트레이션(Orchestration)
- 단순히 코드베이스를 이해하는 것을 넘어 스스로를 이해하는 최초의 모델
- 추가 모델 생성, 작업 분할, 완료 후 검증까지 자율적으로 수행
- 맞춤형 도구나 고급 시스템 없이도 "조금 더 진행하도록 유도"하는 것만으로 놀라운 결과
- 동일한 프롬프트에서는 이전 모델과 비슷해 보이지만, 올바른 접근 방식을 사용하면 차원이 다름
핵심 인사이트: "모델의 발전 속도가 우리보다 훨씬 빠르다. 우리가 반드시 더 나아질 수는 없다. 그래서 우리는 더 큰 규모로 나아가야 한다."
섹션 2: 스큐어모피즘의 함정 — iOS 7 비유
[중반부] 개발자들이 AI 시대에 맞는 새로운 패러다임을 받아들이지 못하는 이유를 설명
iOS 6 vs iOS 7: 패러다임 전환의 교훈
- iOS 6 이전(스큐어모픽 시대): 나침반 앱은 실제 나침반처럼 생겼어야 했음. 책 앱은 실제 책장과 페이지 넘김을 구현했음
- 이유: 디지털 기기가 물리적 도구를 대체할 수 있다고 사용자를 설득해야 했기 때문
- iOS 7의 전환: "설득"에서 "수용"으로. 애플이 이미 이겼기 때문에 더 이상 설득이 필요 없어짐
- iOS 7의 평면적 디자인은 "나빠 보였지만" 실제로는 훨씬 더 많은 정보를 더 명확하게 전달
개발자들의 스큐어모피즘
- 터미널: 최고의 인터페이스인 척하지만 사실 "훌륭한 인터페이스조차 아님". 자연어는 터미널에 설 자리가 없지만 익숙하기 때문에 있는 척 함
- Vim: 개발자들의 정체성이 되어버린 도구
- 언어 집착: "걔는 자바스크립트나 쓰네. 진짜 개발자가 아니야" — 이미 시니어 엔지니어들도 언어로 서로를 평가
- 환경 변수를 커밋할 수 없는 이유: Git은 특정 목적으로 만들어졌는데 업계 전체의 사고방식을 지배하게 됨
- 코드 삭제에 대한 두려움: 매몰 비용 오류. "죄책감으로 PR을 머지"하는 문화
핵심 메시지: "우리가 이렇게 하는 이유는 이것이 옳기 때문인가, 아니면 단지 늘 해오던 방식이기 때문인가?"
섹션 3: 스케일의 민주화 — 무엇이 가능해졌는가
[중후반부] Theo 자신의 프로젝트 3가지를 예시로 스케일 변화를 설명
프로젝트 분류의 변화
| 분류 | 예전 | 현재 |
|---|---|---|
| 사이드 프로젝트 | 개인 스크립트 | 스타트업 수준 제품 |
| 스타트업 | 중간 규모 | 부업(Side Project) 수준 |
| "너무 큰 것" | 불가능 | 점점 현실화 |
Theo의 실제 프로젝트 예시
-
Reddit Scraper (사이드 프로젝트, 2~3일)
- 레딧에서 프로그래밍 유머 인기 게시물을 모아 정리
- 트위터에 재게시하기 위한 자동화 도구
-
Ping (스타트업, Y Combinator 과정)
- "Zoom for Streamers" — OBS 소프트웨어 내에서 라이브 콘텐츠 제작자들의 고품질 협업 지원
-
풀스택 클라우드 (현재 작업 중)
- Vercel을 모든 방향으로 확장한 개념
- 내장 기능 + 데이터베이스 포함
PR 분류 마크다운 파일 예시
- "이 4개의 GitHub 저장소에서 열려있는 모든 PR을 살펴보고, 우선순위를 정하고, 끝나면 정적 HTML을 S3에 업로드 후 URL 알려줘"
- Cron으로 매일 오전 9시 실행 → 9시 15분에 그날의 할일 목록 생성
- 제품 전체가 마크다운 파일 하나: "이번 행사에 얼마나 많은 회사가 참가하는지"
섹션 4: 더 넓게 생각하기 — 새로운 기회의 지형
[후반부] 소프트웨어의 폭(Breadth)과 깊이(Depth) 스펙트럼
폭과 깊이의 트레이드오프
- Vercel 예시: AWS가 제공하는 모든 기능을 제공하지 않지만, 풀스택 프론트엔드 서버 분야에서 훨씬 심층적인 기능 제공
- 기존 전략: 범위를 줄이고 특정 영역에서 깊이 집중 (작은 팀이 대형 플랫폼과 경쟁하는 유일한 방법)
- AI 이후의 전략: 갑자기 범위도 이전에는 불가능했던 방식으로 실현 가능해짐
새로운 기회
- 하루 이틀 만에 데이터베이스 플랫폼을 제품에 추가 가능
- 사용자가 "전혀 예상하지 못했던 일들을 할 수 있도록" 설계할 수 있음
- Slack처럼 의도치 않게 에이전트 실행 플랫폼이 된 제품들
- AWS, Salesforce와 경쟁하는 것이 "바보 같은 소리"가 아닐 수 있음
마지막 메시지: "당신의 아이디어가 어리석게 느껴지지 않는다면, 그것은 당신의 아이디어가 충분히 크지 않기 때문입니다."
계층 3: 핵심 개념/용어 설명
스큐어모피즘(Skeuomorphism)
과거에 사용하던 물리적 제품의 외관을 디지털에서 재현하는 디자인 미학. iOS 6까지의 나침반 앱, 책 앱 등이 대표 사례. Theo는 개발자들이 터미널, Vim, 특정 언어에 집착하는 것이 현재 소프트웨어 개발의 스큐어모피즘이라고 지적.
AI 정신병(AI Psychosis)
AI 모델의 능력이 급격히 향상되면서 개발자들이 경험하는 인식 혼란 상태. "우리가 알고 있던 모든 것이 유효하지 않을 수 있다"는 깨달음에서 오는 불안과 흥분.
오케스트레이션(Orchestration)
Mythos/Fable 수준의 AI 모델이 가능케 한 새로운 패러다임. 단일 모델이 작업을 분할해 여러 모델에 배분하고, 각 서브 에이전트의 결과를 검증하며 통합하는 방식. 인간이 세밀하게 지시하지 않아도 자율적으로 복잡한 작업을 완수.
폭(Breadth)과 깊이(Depth)
- 폭: 소프트웨어가 다루는 도메인의 범위 (예: AWS는 폭이 매우 넓음)
- 깊이: 특정 도메인 내의 기능 수 (예: Vercel은 프론트엔드 배포 분야에서 깊이가 깊음)
- AI 등장 이전: 소규모 팀은 깊이로 승부. AI 이후: 폭과 깊이 모두 동시 추구 가능
매몰 비용 오류(Sunk Cost Fallacy)
이미 투자한 비용 때문에 최선의 선택을 하지 못하는 인지 편향. 코드 삭제 두려움, "죄책감 PR 머지" 등이 대표적 사례.
계층 4: 실행 포인트 & 시사점
즉시 실행 가능한 것들
-
"왜 이렇게 하는가?" 질문 습관화
- 매번 작업 전 "이것이 옳기 때문인가, 아니면 늘 해오던 방식이기 때문인가?" 자문
- 터미널 의존, 특정 언어/프레임워크 집착, 코드 보존 본능 등에 대한 비판적 사고
-
AI를 단계별 지시 방식이 아닌 오케스트레이터로 활용
- "1단계부터 시작하세요 → 이제 다음 부분을 만들어주세요" 방식 탈피
- 원하는 최종 결과를 설명하고 AI가 스스로 작업 분할하도록 유도
- 마크다운 파일 하나로 크론잡 + 코드 + 분석 모두 해결하는 방식 도입
-
야망의 스케일 재보정
- 과거에 "스타트업이 필요한 아이디어"였던 것을 이제 부업으로 시도
- "너무 크다"고 생각했던 것을 스타트업 수준으로 재고
- 아이디어가 어리석게 느껴지지 않으면 충분히 크지 않은 것
-
코드 삭제와 리셋에 대한 두려움 극복
- 매몰 비용 오류 인식하고 최선의 선택에 집중
- AI를 활용하면 재작성 비용이 극적으로 낮아졌음을 인지
전략적 시사점
-
폭과 깊이 동시 추구 전략 검토
- 기존 플랫폼(AWS, Salesforce 등)이 "폭"으로 지배하는 시장에서 AI를 통해 폭을 빠르게 확보
- 특정 영역에서 더 깊은 기능으로 차별화
-
"설득"에서 "수용"으로의 UX 전환
- 자연어 인터페이스가 터미널보다 나은 경우가 있음을 인정
- 사용자가 예상하지 못했던 방식으로 활용할 수 있도록 플랫폼 설계
-
Cron + 마크다운 + LLM 조합의 파워
- 복잡한 자동화 시스템을 마크다운 파일 하나로 구현하는 패턴 적용
- PR 분류, 뉴스 요약, 데이터 수집 등의 반복 업무 자동화
경고/주의사항
- 모델의 발전 속도 >> 개발자의 학습 속도: 현재의 접근 방식에 안주하면 뒤처짐
- 이전 Jira 티켓 대부분 = Opus 4.5로 쉽게 해결: 과거의 작업 방식으로는 AI의 잠재력을 활용 못 함
- Mythos 같은 모델은 동일한 프롬프트에서 차이를 못 느낌: 올바른 접근 방식(더 큰 목표, 오케스트레이션 활용)을 가져야만 차이를 경험
자막 기반 한국어 요약. 일부 표현은 의역됨.