유명한 개발자 유튜버이자 창업자인 Theo Browne(@t3dotgg)이 AI Engineer 컨퍼런스에서 진행한 키노트 강연 “What do we build now?” 요약 및 해석입니다.
최근 AI 모델의 추론 지형과 오케스트레이션(Orchestration) 기능이 진화함에 따라, 개발자가 코드를 구상하고 조립하며 제품을 정의하는 방식의 근본적인 티어(Tiers)가 어떻게 허물어지고 있는지에 관한 날카로운 비판과 미래 비전을 제공합니다.
핵심 클립 및 해석
1. AI 정신병(AI Psychosis)과 세 가지 AI 시대
“…kind of going through some AI psychosis. Who here would classify how they feel right now as some form of AI psychosis? … Sonnet 3.5 is the tool call era … Opus 4.5 … do much longer running tasks … Mythos is another jump to orchestration. It feels to me like it’s the first model that doesn’t just understand your code base, but it understands itself. And it knows how to spawn additional models and break up work”
연사는 강연을 시작하며 급격하게 발전하는 AI 속도를 따라잡으려다 겪는 AI 정신병(AI Psychosis)을 언급합니다. AI 모델이 진화하면서 개발 방식은 크게 세 개의 시대로 세분화되었습니다.
첫 번째는 Sonnet 3.5 시대로, 모델이 코드베이스 안에서 안정적으로 도구를 호출(Tool Calling)하기 시작한 단계입니다. 두 번째는 Opus 4.5 시대로, 단순히 일회성 도구 실행을 넘어 코드를 직접 테스트하고 오랜 시간(수 시간 단위) 동안 문맥을 잃지 않고 작업을 지속하는 장기 실행(Long-running task)의 단계입니다. 세 번째는 Mythos/Fable 시대로, 단순한 실행을 넘어 모델이 스스로를 메타 인지적으로 이해하고, 필요한 서브 모델을 직접 생성하여 작업을 분배하고 검증하는 오케스트레이션(Orchestration)의 시대입니다. 모델이 스스로의 지능과 행동을 조율하기 시작했다는 점이 핵심적인 도약입니다.
2. 스큐어모피즘(Skeuomorphism)을 넘어 실용성(Utility)의 시대로
“We’re currently in our skeuomorphic phase as software developers. … We’re pretending our terminals are the ultimate interface when they’re not even good interfaces. And I’m saying this as someone who loves their terminal deeply. Natural language has no place in a terminal, but we pretend it does because the terminal’s familiar.”
초기 iPhone의 iOS는 책장이나 나침반 모양을 있는 그대로 흉내 낸 스큐어모피즘(Skeuomorphism) 디자인을 사용했습니다. 이는 기기 사용을 친숙하게 만들기 위한 설득 단계였으며, 사용자들이 기기에 완벽히 익숙해진 iOS 7에 이르러서야 순수한 디지털 유틸리티 형태로 레이아웃이 탈바꿈했습니다.
연사는 현재의 개발 환경도 스큐어모피즘 단계에 갇혀 있다고 경고합니다. 터미널은 텍스트를 다루는 강력한 유산이지만, AI 에이전트와 자연어로 소통하기 위한 궁극적인 인터페이스는 아닙니다. 우리는 단지 익숙하고 편하다는 이유로 터미널에 에이전트를 가두고 있습니다. 개발 도구의 형태와 Git에서의 환경 설정 파일(.env) 비공유 규칙 등은 모두 옛 아날로그 관성이 디지털과 AI 협업 환경에 그대로 투영된 스큐어모피즘에 불과하며, 이제는 순수한 유틸리티와 도구의 본질적 유용성에 집중하는 방식으로 전환해야 합니다.
3. 무너진 소프트웨어 티어: 스타트업은 사이드 프로젝트가 되고, 서비스는 마크다운 파일이 된다
“Now that the models are bigger, the tiers have shifted. Everything is now one tier lower. … It’s the G brain tier. It’s a markdown file. Do you know how many companies are at this event where their whole product could just be a markdown file?”
모델의 연산과 추론 능력이 급성장함에 따라, 기존 소프트웨어의 복잡도 티어(Tiers)가 전부 한 단계씩 아래로 격하되었습니다.
과거에는 여러 명의 엔지니어와 투자가 필요했던 스타트업 규모의 파이프라인이 이제는 1인 개발자가 주도하는 사이드 프로젝트 수준으로 하락했습니다. 더 나아가, 과거의 사이드 프로젝트 급 서비스(예: 풀 리퀘스트 자동 리뷰, 분류 및 배포 자동화 시스템 등)는 이제 마크다운 지침 파일 한 장과 크론(Cron) 조합으로 손쉽게 가동할 수 있는 마크다운 티어(Markdown Tier) 혹은 G-Brain 계층으로 대체되었습니다. 마크다운으로 설계 명세와 파이프라인 지침을 세부적으로 적어두면 에이전트가 이를 그대로 로드하여 실제 프로세스로 동작시키기 때문입니다. 수많은 스타트업의 껍데기 제품들이 사실상 마크다운 한 장짜리 지침 파일의 가치로 수렴하고 있는 충격적인 현상입니다.
4. 깊이(Depth)가 아닌 넓이(Breadth)의 설계
“It’s time to think wider. … Breadth and depth to any piece of software. … All of a sudden, that range is viable in a way that it never was before… you can build a database platform into your product in a day or two of work with enough prompting and enough effort.”
전통적인 스타트업의 경쟁 구도는 특정 서비스의 깊이(Depth)를 얼마나 정교하게 구현하느냐였습니다. Vercel이 대표적인 예로, AWS보다 제공하는 기능 스펙트럼은 좁지만 프론트엔드 배포라는 버티컬 도메인에서 극한의 깊이를 자랑했습니다.
그러나 AI 오케스트레이션이 실현된 오늘날에는 한 명의 엔지니어가 데이터베이스 플랫폼, 사용자 인증 시스템, 프론트엔드를 통틀어 더 넓은 범위(Breadth)의 구조를 이틀 만에 조립해 내는 것이 가능해졌습니다. 넓은 스펙트럼을 제공하되, 사용자가 특정 도메인의 세부적인 엣지 기능(Edge features)을 직접 채워 넣고 연동할 수 있도록 제품 아키텍처를 유연하게 만드는 것, 즉 생태계와 유연성(Extensibility)을 갖춘 넓은 아키텍처를 그리는 전략이 강력한 생존 모델이 됩니다.
5. “어리석어 보이지 않는 아이디어는 충분히 크지 않다”
“If your idea doesn’t feel stupid, it’s cuz your idea’s not big enough. That’s all I have to say.”
연사는 AWS에 정면으로 도전하는 데이터베이스 아키텍처를 새로 고치거나, Salesforce를 직접 대체하려는 시도처럼 남들이 보기에 어리석고 무모해 보이는 아이디어를 가질 것을 독려합니다. AI 지능의 공급 한계가 무너진 환경에서는 개발 주기가 압축되기 때문에, 과거의 기준으로 설계된 ‘적당히 현실적인’ 아이디어는 이미 에이전트의 개발 지평 안에서 trivial한 문제로 전락해 버리기 때문입니다. 바보 같아 보일 정도로 거대하고 넓은 시야를 품어야만 비로소 의미 있는 아키텍처를 설계할 수 있습니다.
내 생각 (My Thoughts)
Theo Browne이 강연에서 쏟아낸 관점들은 현재 이 블로그를 배포하고, 독서록과 비디오 노트를 정비하는 데 활용하는 하네스 엔지니어링(Harness Engineering) 패러다임과 근본적인 궤를 같이합니다.
특히 가장 깊이 공감되는 지점은 “소프트웨어 티어의 붕괴”와 “마크다운 실행 계층(Markdown Tier)”의 부상입니다. 우리는 이미 SKILL.md, task.md와 같은 단순한 마크다운 파일들의 조합으로 복잡한 번역 파이프라인이나 유튜브 자막 연동 엔진을 가동하고 있습니다. 개발자가 수천 줄의 코드로 하드코딩하던 시스템 오케스트레이션이, 이제는 정교하게 정돈된 마크다운 선언문 한 장과 이를 루프 안에서 해석하고 수정할 수 있는 에이전트 환경(Antigravity 등)으로 완전히 압축되었습니다. 지침서(Specification)가 곧 런타임 파일이 된 셈입니다.
또한 개발자 터미널을 향한 스큐어모피즘 비판도 의미심장합니다. 우리는 여전히 검은 화면의 CLI 프롬프트에서 자연어 명령어 블록을 던지고 가두는 것을 고수하지만, 진정한 AI 협업은 터미널을 넘어 상태 보존 가시성(State Visibility)이 확보된 리치 캔버스(Rich Canvas), 그리고 사람과 에이전트의 바운디드 콘텍스트(Bounded Context)를 정밀하게 격리하고 동기화하는 도구의 형태로 점차 확장되어야 할 것입니다.
결국 “무엇을 더 깊이(Depth) 짜낼 것인가”의 고민보다, “AI 협업 계층을 이용해 이종의 다양한 인프라를 얼마나 넓게(Breadth) 통합하고 유연한 통제권을 사람에게 줄 것인가”의 설계 감각이 앞서는 시대가 되었습니다. 이러한 오케스트레이션 흐름을 우리가 설계하는 하네스 컴포넌트의 유기적인 분해와 결합, 그리고 투명한 승인 루프(Human-in-the-loop) 구조 설계에 지속적으로 투영해 나가야 합니다.
댓글
GitHub 계정으로 의견을 남길 수 있습니다. 댓글은 GitHub Discussions에 저장됩니다.