Instagram 창시자와의 대화: Anthropic, Fable 5 출시 — 수작업으로 코드를 작성하던 시대는 이제 끝났다
정리 및 번역: TechFlow
게스트: 마이크 크리거(Mike Krieger), 인스타그램 공동 창립자
진행자: 댄 쉽퍼(Dan Shipper)
팟캐스트 출처: Every
원제목: Mike Krieger Lets Fable 5 Code While He Sleeps
방송일: 2026년 6월 11일
핵심 요약
마이크 크리거는 인스타그램의 공동 창립자로서, 지난 20년간 인류 사회에서 가장 영향력 있는 소비자용 애플리케이션 중 하나를 직접 창조해냈습니다. 오늘날 그는 앤트로픽 랩스(Anthropic Labs)의 수장으로서 ‘AI-네이티브(AI-native)’ 제품 개발의 최전선에 서 있으며, 팀을 이끌고 궁극적인 질문에 도전하고 있습니다: 세계 최고 수준의 AI 모델을 진정한 개발자들에게 맡길 때, 기술의 능력 한계는 어디까지 확장될 수 있는가?
Fable이 정식 출시되기 5개월 전, 내부에서 처음으로 이 모델을 체험할 수 있었던 순간, 그는 지금도 생생하게 기억할 만큼 강렬한 충격과 실감나는 무력감을 경험했습니다. “됐다, 나는 다시 완전한 초보자가 된 것 같아.” 그는 당시 팀에게 이렇게 자조했습니다. 그는 자신이 수십 년간 쌓아온 생산성 향상, 개발 전략, 시간 관리 등 모든 경험 법칙이 이 순간에 완전히 무용지물이 되었음을 깨달았습니다. 모델의 진화 속도가 이미 그의 기존 워크플로를 완전히 따라잡지 못하고 멀리 뒤처져 버린 것이죠.
이 에피소드에서는 진행자와 마이크 크리거가 심층 대담을 나누며, Fable처럼 시대를 초월하는 하드코어 모델과 어깨를 나란히 하고 함께 소프트웨어를 구축하는 것이 어떤 경험인지 탐구합니다. 이러한 인간-기계 공생의 새로운 정상 상태 속에서, 어떤 새로운 개발 리듬, 엄중한 도전, 그리고 상상력을 자극하는 궁극적 가능성들이 탄생하고 있는가?
주요 통찰 요약
Fable이 마이크의 워크플로를 어떻게 완전히 재정의했는가
- “진정한 인지적 성장은 단 하루의 첫 체험보다는 몇 주간 집중적으로 지속해서 사용할 때 비로소 이루어진다. …… 시간이 지나면서 사람들은 갑자기 깨닫는다. ‘내가 이 모델을 아직 충분히 활용하지 못했다. 이제 한 걸음 더 나아가, 이 세대 모델의 실제 능력 한계가 어디까지인지 다시 생각해봐야 한다.’”
- “현재 올바른 접근법은, 보다 거시적이고 충분히 명확한 의도를 전달한 후, 완전히 맡겨두는 것이다. 이 모델은 단번에 놀라운 결과물을 제공할 뿐 아니라, 더욱 놀라운 점은 해당 기능의 향후 진화 방향과 전체 프로젝트의 전반적 맥락까지 이해한다는 점이다.”
- “제가 가장 감탄한 것은 바로 자동 닫힘(closed-loop) 능력이다. 예를 들어, 이런 식으로 사고한다. ‘마이크가 오늘 밤 복잡한 작업을 실행하라고 했지만, 원격 서버가 다운되어 막혔다. 그렇다면 우선 mock 백엔드를 스스로 작성해 임시로 대체하고, 문제를 문서에 기록한 다음 전체 프로세스를 먼저 완료하고 저장해 두었다가, 내일 서버가 복구되면 다시 수정하겠다.’ 이런 수준의 작업을 위임하고, 그 최종 산출물을 완전히 신뢰할 수 있다는 경험은 정말 충격적이었다.”
- “과거에는 이런 모델들을 ‘어시스턴트’ 혹은 ‘파트너’에 비유했지만, 지금은 진정한 책임을 질 수 있고 핵심 업무를 대량으로 수행할 수 있는 ‘강력한 팀원’에 가깝다.”
Sonnet은 언제, Fable은 언제 사용해야 하는가
- “완전히 다른 차원의 체감이다. 이는 초당 토큰 출력량과도 무관하다. 오히려 ‘이 문제를 해결하기 위해 얼마나 많은 뇌 용량을 동원해야 하는가’라는 근본적인 질문이다. 때때로 간단한 답변은 전혀 그런 깊이 있는 사고를 필요로 하지 않는다.”
- “대부분의 경우 제가 iOS 앱을 열어보는 건, Fable을 불러야 할 정도의 중대한 작업을 하려는 게 아니다. …… ‘이 문제는 Fable을 부르기에 너무 가볍다. Sonnet을 불러야겠다’는 미묘한 직관을 최근 실제로 느꼈다.”
- “Fable은 제가 지금까지 만난 모델 중 처음으로 ‘노력 정도(Reasoning Effort, 추론 강도)’를 스스로 조절하게 만든 모델이다. …… 과거 Opus를 사용할 때는 거의 조절하지 않았는데, 당시 모델의 유연한 범위가 지금처럼 넓지 않았기 때문이다. 그러나 Fable은 진짜로 매우 넓은 스펙트럼을 커버한다.”
Fable 5가 촉발한 에이전트-네이티브(Agent-native) 아키텍처
- “에이전트-네이티브 아키텍처란, 첫 단계로서 제품 내 모든 핵심 구성 요소와 데이터가 에이전트에 대해 완전히 개방되어야 하며, 각각에 대응하는 도구 호출 인터페이스가 있어야 한다는 것을 의미한다. 이는 소프트웨어 산업의 ‘생존선’으로 빠르게 자리 잡고 있다—비극적이게도 현재 시장에 존재하는 대부분의 소프트웨어는 이 기본 조건조차 충족하지 못한다.”
- “앱에서 채팅 버튼을 길게 누르면, 우리의 호스팅된 에이전트가 ‘코드 수정 지시’를 수신하도록 활성화된다. …… 아이들과 외부에서 놀다가 ‘iOS에서 이 플로팅 버튼 위치가 너무 아래에 있다’고 느꼈을 때, 저는 앱 안에서 바로 말만 하면, 에이전트가 스스로 뒷단에서 코드를 고쳐버린다.”
- “클로드(Claude)는 소프트웨어에 어떻게 통합되어야 할까? 단순히 ‘사용’ 수준에 머무르는 것이 아니라, 소프트웨어의 ‘구축’이라는 골수 속 깊이 침투해야 한다.”
구축 비용의 붕괴
- “인스타그램 V1 버전을 돌이켜보면—기능 면에서 제가 이번 주말에 만든 미디어 추적기보다는 조금 더 많긴 하지만, 절대적인 양적 차이는 없다. 그런데 당시 그 V1을 만들기 위해 케빈(Kevin)과 저는 연속 5박을 새워야 했다. …… 그런데 지금은? 구축 시간이 정말 경악스럽게 짧아졌다.”
- “‘의도’에서 ‘실행’으로 이어지는 그 깊은 협곡은, 코딩을 모르는 일반인들 사이에서도 이미 완전히 평탄화되었다. …… 제 인생에서 처음으로, 제 머릿속 생각과 현실 세계에 존재하는 것 사이에 전혀 거리가 없음을 느꼈다. 바로 그것을 만들어낼 수 있다.”
- “인간의 창의력은 무한하지만, 우리가 오늘날 가장 위대하게 해내고 있는 일은 바로 ‘머릿속 생각을 현실로 바꾸는 능력’을 갖춘 사람들의 범위를 무한히 확장하는 것이다.”
소프트웨어 엔지니어링은 죽었는가?
- “소프트웨어 엔지니어링의 본질은 완전히 바뀌었다. 이 분야는 천변지이의 격변을 겪고 있다. …… 순수한 코드 작성을 중심으로 한 장인 시대는 아마도 진정으로 끝났을 가능성이 높다.”
- “고급 엔지니어의 역할은 여전히 대체 불가능하다. 당신은 수년간의 사고 대응 경험을 바탕으로 절대적인 침착함을 유지하고, 로그 데이터를 전량 수집하며, 응급 조치를 시행한 후, 근본적인 장기 해결책을 도출해야 한다.”
- “과거 실리콘밸리에서는 ‘코드가 논쟁을 이긴다(Code wins arguments)’는 말이 유행했는데, 저는 개인적으로 이 말을 그리 좋아하지 않았다. 그 이면에는 ‘누가 코딩을 할 수 있느냐’가 곧 권력의 중심이라는 암묵적 전제가 있기 때문이다. 그러나 지금은 상황이 아주 흥미롭게 반전되고 있다. 때때로 제품의 방향성에 대해 의견이 분분할 때, 어느 날 코드를 작성하지 않는 PM이 다가와 ‘방금 제가 직접 데모 하나 만들어봤어요…’라고 말하는 경우가 종종 있다. 이 순간, 완전히 다른 차원의 고차원 대화가 시작된다.”
- “가장 눈에 띄는 특징은 끔찍할 정도의 개발 동시성과, 팀이 워크플로를 고차원적으로 추상화할 절대적 필요성이다. 다만 한 가지는 변함없이 유지된다—바로 인간이 제품에 대해 느끼는 ‘소유권과 책임감’이다.”
검증 메커니즘과 비용
- “오늘날의 ‘비용’ 개념은 이미 다차원적으로 진화했다—단순히 ‘한 번의 질문 비용’만 계산하는 것이 아니라, ‘한 가지 일을 완전히 처리하는 종합 비용’을 산정해야 한다. Fable이 저를 가장 놀라게 한 점은 바로 이 후자다: 이 모델은 항상 한 번에 일을 제대로 해내려고 하며, 제가 컴퓨터 앞에 앉아 여덟 아홉 차례나 반복해서 교정할 필요가 없다.”
- “이런 새로운 정상 상태에 적응하고, 어떻게 협업해야 하는지를 파악하는 것은 우리 모두가 배워야 할 과제다. …… 제가 무언가를 구축할 때마다, 클로드의 모든 PR이 사진이나 동영상과 함께 제공되도록 보장한다—iOS PR이든 UI 레이어 변경이든 간에 말이다. 이를 통해 상당한 신뢰를 얻을 수 있다.”
- “동영상은 클로드에게 아직 거의 활용되지 않은 극도로 강력한 도구다. 최근 저는 프로토타입을 하나 만들고 있는데, 클로드가 만든 것을 동영상으로 녹화해 전달하고 FFmpeg와 결합하여, 클로드가 프레임 단위로 분석하면서 ‘이 애니메이션이 끊기네요, 제가 고칠게요’라고 말하게 한다. 스크린샷은 절대 이를 포착할 수 없다. 왜냐하면 스크린샷은 그 순간을 놓치기 때문이다.”
동적 워크플로
- “이전 세대 모델의 ‘생존선’에서는 프로젝트에 ‘복잡도 천장’이 존재했다. 비즈니스 코드나 로직이 일정 규모 이상으로 쌓이면, 대규모 모델은 ‘머리만 보고 꼬리는 보지 못하는’ 상황에 빠지기 시작했다. …… 그런데 지금, 이 코드를 전혀 모르는 여성 동료가 Fable 수준의 모델을 활용해 자신의 시스템을 몇 달째 백그라운드에서 꾸준히 키우고 있다. 당신은 그 소프트웨어가 살아있는 유기체처럼, AI의 양분을 받아 끊임없이 성장하고, 또 성장하며 광속으로 진화하는 모습을 명확히 볼 수 있다.”
- “워크플로는 좋은 중간 지점이다. 당신은 챗을 통해 이를 편성하지만, 그것은 코드로 표현되며, 깔끔한 UI에서 실행된다. 각 단계가 무엇이 일어나는지를 명확히 보여준다. 앞으로 우리는 장기적 관점의 작업과 챗을 연결하기 위해 유사한 방식을 사용하게 될 것이다.”
Fable이 마이크의 워크플로를 어떻게 완전히 재정의했는가
진행자 댄 쉽퍼: 이 에피소드에 초대한 게스트는 앤트로픽 랩스의 책임자이자 인스타그램 공동 창립자인 마이크 크리거입니다. 마이크, 이 모델을 깊이 있게 사용한 후의 실제 체감을 듣고 싶습니다. 이렇게 강력한 모델이 출시될 때, 매일 이 모델을 집중적으로 사용하는 사람이 ‘어떤 부분에서 놀라울 정도로 강한지, 어떤 부분에서 워크플로를 실질적으로 바꿨는지, 또 어떤 부분에서는 사실 별반 다르지 않다’고 말한다면, 사람들이 기술을 자신의 일상생활에 어떻게 통합해야 할지 진정으로 이해할 수 있을 것입니다.
마이크 크리거:
그렇습니다. 이 경험 자체가 매우 흥미롭습니다. Fable이 정식 출시되기 몇 달 전, 우리 내부에서는 이미 몇 가지 Mythos 수준의 모델을 사용하고 있었습니다. 당시 저는 외부 개발자들이 이 모델로 무엇을 만들지 궁금해했지만, 말씀하신 대로 진정한 인지적 성장은 단 하루의 첫 체험보다는 몇 주간 집중적으로 지속해서 사용할 때 비로소 이루어집니다.
우리는 이전 모델들에서도 이러한 인지 재구성을 경험했습니다. 작년 12월 말부터 올해 1월 초까지, 모두가 Opus 4.5와 4.6을 집중적으로 사용했을 때, 시간이 지나면서 사람들은 갑자기 깨닫기 시작했습니다. “내가 이 모델을 아직 충분히 활용하지 못했다. 이제 한 걸음 더 나아가, 이 세대 모델의 실제 능력 한계가 어디까지인지 다시 생각해봐야 한다.”
진행자 댄 쉽퍼: 우리 Every 팀 내부에도 이미 일부 동료들이 사용하고 있습니다. 어떤 분은 ‘이 모델을 다루기 위해 완전히 새로운 기술 트리가 필요하다’고 말했습니다. 특히 기술 배경이 없는 지식 노동자들은 어찌해야 할지 감을 잡지 못하고 있습니다. 한편, 에이전트(Agent) 오케스트레이션을 담당하는 동료들은 ‘배워야 할 새 내용이 너무 많다’고 탄식했습니다.
마이크 크리거: “워크플로 전환”이라는 점을 언급해주셨는데, 이는 핵심을 찌릅니다—단순한 조작 절차를 넘어서 관념의 전환이 필요하다는 의미입니다. 우연히도 이 모델의 출현은 제가 업무 변화의 전환점을 맞이한 시기와 정확히 일치했습니다. 당시 저는 CPO(최고제품책임자)에서 랩스로 이동하며 다시 개발자 모드로 돌아갔습니다. 이전 역할에서 약 한 달 반에서 두 달 정도 지났을 때, 내부에서 처음으로 이 유형의 모델을 실행해 보았습니다. 저는 컴퓨터 앞에 앉아 생각했습니다. “됐다, 나는 다시 초보자가 된 것 같아.” 왜냐하면 제가 과거에 프롬프트를 작성하던 습관, 심지어 작업을 분해하는 사고방식조차 이 모델 앞에서는 완전히 무용지물이 되었음을 깨달았기 때문입니다.
당신의 시간 척도 감각과 상호작용 방식도 진화해야 합니다. 예전 같으면, 저는 이렇게 말했을 겁니다. “기능 아이디어가 있는데, 일단 첫 단계부터 시작해보자—”. 그러나 지금은 절대 그렇게 해서는 안 됩니다. 현재 올바른 접근법은 더 거시적이고 충분히 명확한 의도를 전달한 후, 완전히 맡겨두는 것입니다. 저는 3~4월경에 이미 이 모델이 보여준 능력에 충격을 받았습니다—단번에 놀라운 결과물을 제공할 뿐 아니라, 더욱 놀라운 점은 해당 기능의 향후 진화 방향과 전체 프로젝트의 전반적 맥락까지 이해한다는 점입니다.
그리고 이 진화는 전혀 멈추지 않고 있습니다. 오늘 아침에도 저는 비행기에서 일에 대해 이야기를 나누고 있었습니다—비행 중에 저는 “대부분의 업무는 사실 원격으로 처리할 수 있다”는 사실을 깨달았습니다. 저는 이제 Wi-Fi가 끊길지 걱정하지 않습니다. 왜냐하면 끊기기 전에 올바른 맥락과 명령(예: 반복 실행 명령)을 설정해두기만 하면, 클로드가 스스로 작업을 끝까지 관리해줄 것이기 때문입니다.
지난 두 달간, 저는 이런 하이라이트 순간을 자주 경험했습니다: 잠들기 전 클로드에게 안녕을 고하고 복잡한 작업을 맡겼는데, 다음 날 아침 눈을 떠보면 이미 모두 완료되어 있습니다—대부분은 자정 2시경에 주요 작업을 끝내고, 나머지 4시간은 디테일을 다듬는 데 쓰였습니다.
제가 가장 감탄한 것은 바로 자동 닫힘(closed-loop) 능력입니다. 예를 들어, 이런 식으로 사고합니다. “마이크가 오늘 밤 복잡한 작업을 실행하라고 했지만, 원격 서버가 다운되어 막혔다. 그렇다면 우선 mock 백엔드를 스스로 작성해 임시로 대체하고, 문제를 문서에 기록한 다음 전체 프로세스를 먼저 완료하고 저장해 두었다가, 내일 서버가 복구되면 다시 수정하겠다.” 이런 수준의 작업을 위임하고, 그 최종 산출물을 완전히 신뢰할 수 있다는 경험은 정말 충격적이었습니다.
물론 이후 반드시 결과물을 검토해야 합니다—이것은 검증 메커니즘의 완전한 체계를 의미하며, 곧 이에 대해 자세히 다룰 수 있습니다. 왜냐하면 이는 닫힘 루프의 결정적 단계이기 때문입니다. 그러나 이것은 저를 다시 생각하게 합니다: 이런 모델을 마주할 때, 도대체 무엇이 ‘효율적’이라는 것인가? 과거에는 이런 모델들을 ‘어시스턴트’ 혹은 ‘파트너’에 비유했지만, 지금은 진정한 책임을 질 수 있고 핵심 업무를 대량으로 수행할 수 있는 ‘강력한 팀원’에 가깝습니다.
진행자 댄 쉽퍼: 그렇다면 당신의 현재 일상 워크플로는 정확히 어떤 모습입니까? 제가 관찰한 바에 따르면, 거대한 작업을 던지고 길게 설명한 후, 몇 시간 또는 하룻밤 동안 스스로 실행하게 하면 이 모델의 성능이 가장 뛰어납니다. 그러나 일상적인 사소한 작업을 처리할 때는 너무 느리고 비싸서 사용하기가 꺼려집니다. 실제 업무에서는 어떻게 균형을 맞추고 있습니까? 이 모델은 당신의 기술 스택에서 어떤 위치를 차지하고 있습니까?
마이크 크리거:
저는 현재 이 모델을 주로 초기 아키텍처 계획 및 방안 조율에 사용합니다. 이는 매우 흥미로운 전환으로, 현재 모든 모델이 계속해서 해결해야 할 난제입니다.
이 점에서 저는 인스타그램 시절의 경험을 참으로 감사하게 생각합니다—로스앤젤레스 서버 한 대에서 최소한의 버전을 급히 구축했던 초기부터, 대규모 동시 접속 처리와 확장성 구축을 거쳐, 결국 페이스북 인프라로 통합되는 과정까지. 이 과정은 ‘프로젝트의 어느 단계에서 어떤 수준의 아키텍처 추상화와 복잡도를 적용해야 하는가’에 대한 직관을 키워줍니다.
그래서 저는 여전히 Fable과 빈번하게 상호작용합니다. 때때로 Fable이 완벽해 보이는 구현 방안을 제시하면, 저는 이렇게 말합니다. “저는 이 기능을 곧바로 출시할 계획입니다—단일 머신 이상의 처리 능력을 고려해야 합니다.” 이러한 양방향 상호작용은 매우 중요합니다. 그러나 아키텍처 계획 단계에서는, 보통 Fable에게 HTML 페이지를 생성해 우리 논의 내용을 시각화하도록 요청합니다. 이렇게 하면 팀과 공유하기 쉬워집니다. 마크다운 파일도 괜찮지만, 저는 그래프가 포함된 형태를 선호합니다.
이렇게 해서 흥미로운 패러다임이 형성됩니다: 함께 철저히 생각하고 계획한 후, 팀과의 조율을 위한 문서를 산출한다. 이제 프로토타입 구축 속도가 극도로 압축되었으므로, 사전 합의와 조율이 더욱 중요해졌습니다—설사 먼저 ‘작게 빠르게’ 데모를 만들어 보고, 이를 통해 더 엄밀한 시스템 아키텍처를 역도출하려는 경우라도, 초기 소통은 필수적입니다. 이 역시 인간의 사고와 협업이 여전히 전체 프로세스에 깊이 뿌리내린 부분입니다.
실행 단계에서는 밤 시간대나 하루 중 큰 시간 블록을 이용해 서로 다른 작업 모듈을 병렬로 처리하도록 Fable에게 지시함으로써, 저는 이전보다 훨씬 더 많은 동시 대화를 유지합니다. 저는 때때로 오랫동안 유지되는 클로드 코드 대화를 열어두고, 작업을 모두 백그라운드의 서브 에이전트에게 위임하여 메인 스레드가 언제든지 새로운 명령에 즉각 반응할 수 있도록 합니다. 또 때로는 브라우저에서 동시에 5~6개의 탭을 열어, 각각이 장기적 복잡 작업을 처리하도록 합니다.
이처럼 장기적 관점과 ‘걱정하지 마세요, 맡겨주세요. 시간이 좀 걸릴 수 있습니다’라는 운영 방식은 정말 큰 잠재력을 지니고 있습니다. 우리는 현재 제품 차원에서 이러한 경험을 더 잘 지원하기 위해 고민하고 있습니다—당연히 ‘즉각 응답’과 ‘장기 실행’ 두 상태를 모두 고려해야 하며, 이들 사이의 상호작용 방식은 매우 흥미롭습니다. 제 개인적 선호는, 최소한 하나의 고맥락·초고속 응답 클로드 창을 항상 유지하는 것입니다. 이는 ‘항상 대기 중이며, 한 마디만 하면 즉시 실행하거나 하위 작업을 파생시킬 수 있다’는 직관을 줍니다.
Sonnet은 언제, Fable은 언제 사용해야 하는가
진행자 댄 쉽퍼: 예를 들어, 길을 걷다가 갑자기 질문이 생기면, Fable을 꺼내겠습니까? 이 느낌이 마치 ‘모기 잡는 데 로켓총을 쓰는’ 것 같지 않습니까? 아니면 다양한 모델 사이를 자주 전환하나요?
마이크 크리거:
지난 한동안 저는 무슨 일이든 Fable을 사용했고, 그 체감은 말씀하신 그대로였습니다—화면을 응시하며, 그가 열심히 생각하는 모습을 지켜보는 것이죠.
지난주, 저는 NBA 파이널에 관한 다소 민망한 간단한 질문을 했습니다. 당시 저는 모바일 단말기의 Sonnet으로 전환했고, 즉시 깨달았습니다. “아, 맞다! 이런 빠른 질문은 예전부터 Sonnet을 썼었지.” 완전히 다른 차원의 체감입니다. 이는 초당 토큰 출력량과도 무관합니다. 오히려 이 문제를 해결하기 위해 얼마나 많은 뇌 용량을 동원해야 하는가라는 문제입니다. 때때로 간단한 답변은 전혀 그런 깊이 있는 사고를 필요로 하지 않습니다.
우리 제품팀에게도 이는 매우 흥미로운 질문입니다. 전반적으로, 우리는 사용자가 매일 프론트엔드에서 어떤 모델을 선택해야 할지 고민하게 하고 싶지 않습니다. 이상적으로는 장기적으로 이들을 매우 직관적이고 바로 사용 가능한 몇 가지 시나리오 버킷으로 통합하거나, 인터페이스를 기준으로 분류하는 것이 좋습니다—왜냐하면 대부분의 경우 제가 iOS 앱을 살펴보는 것은 Fable을 불러야 할 정도의 중대한 작업을 하려는 것이 아니기 때문입니다. 따라서 인터페이스 단에서 무감각한 모델 고정을 하는 것도 하나의 방안일 수 있습니다. 앞으로 이에 대해 제품 차원에서 무엇을 의미하는지 철저히 탐색해야 합니다. 그러나 ‘이 문제는 Fable을 부르기에 너무 가볍다. Sonnet을 불러야겠다’는 미묘한 직관은 최근 실제로 느꼈습니다.
말씀하신 대로, 고빈도·세밀한 상호작용 작업에서는 Fable이 자의적으로 깊이 생각하려는 경향이 있습니다. 사실, Fable은 제가 지금까지 만난 모델 중 처음으로 ‘노력 정도(Reasoning Effort, 추론 강도)’를 스스로 조절하게 만든 모델입니다—때때로 저는 이렇게 생각합니다. “단지 UI 스타일을 수정하려는 건데, 노력 정도를 ‘중간’으로 조절해 효과를 확인해보면 되겠군.” 과거 Opus를 사용할 때는 거의 조절하지 않았는데, 당시 모델의 유연한 범위가 지금처럼 넓지 않았기 때문입니다. 그러나 Fable은 진짜로 매우 넓은 스펙트럼을 커버합니다.
마이크가 주말에 만든 미디어 추적기가 에이전트-네이티브 아키텍처를 무엇을 드러내는가
진행자 댄 쉽퍼: 당신이 이 모델로 만든 것을 보여줄 수 있습니까?
마이크 크리거:
이번 신모델 출시 시, 우리는 팀원 전원이 개인 계정에서 이를 사용하도록 장려했습니다—특히 주말을 활용해 말입니다. 이는 꽤 흥미로운데, 앤트로픽 내부에는 많은 맞춤형 생산성 도구가 있기 때문에, 가끔씩 한 발 물러서 가장 순수한 상태로 돌아가는 것입니다. “순수한 클로드 코드만으로, 주말에 내가 즐길 수 있는 작은 재미를 만들어보자.” 이런 느낌은 정말 좋습니다.
진행자 댄 쉽퍼: 터미널 앱에서 실행하셨습니까, 아니면 데스크톱 앱에서 실행하셨습니까?
마이크 크리거:
좋은 질문입니다. 저는 대부분 터미널에서 작업합니다. 그러나 재미있는 건 제 아내인데, 그녀는 전문 엔지니어가 아니라 UX(사용자 경험) 디자이너와 PM(제품 매니저) 배경을 가진 사람입니다. 그녀는 오히려 데스크톱 앱을 통해 클로드 코드에 완전히 매료되었습니다. 데스크톱 앱이 그녀에게 저변의 고도화된 추상 개념을 많이 차단해 주었기 때문입니다. 그러나 제가 이 프로젝트를 진행할 때는 Ghostty와 터미널을 사용했습니다.
저는 완벽한 ‘미디어 진행도 추적기’를 원했습니다—평소 게임을 하거나 드라마를 보고, 친구들로부터 다양한 추천을 받는데, 제만의 수납 습관에 완벽히 부합하는 도구가 필요했습니다. 제 두 가지 핵심 기준은 다음과 같습니다. 첫째, 항목 추가가 매우 쉬워야 합니다. 클로드에게 음성이나 텍스트로 한마디만 하면, 스스로 전 세계를 검색해 정보를 보완하고 분류해 저장해줍니다. 둘째, 능동적 알림입니다. 새 시즌이나 게임 후속작이 나오면 자동으로 찾아옵니다.
대부분의 UI는 Fable이 단번에 완성했는데, 이만으로도 이미 대단합니다. 그러나 저는 올해 랩스에서 집중적으로 연구해온 한 가지 주제가 있습니다: 어떻게 소프트웨어 팀—지금 이 팀은 바로 클로드—를 소프트웨어 자체와 더 밀접하게 연결할 수 있는가?
그것은 토요일 아침이었습니다. 저는 주말 내내 아이들과 함께하는 일정으로 가득 차 있었고, 따라서 개발은 거의 ‘단절형’이었습니다: 아이들과 등산을 가고, 돌아와서 몇 줄 쓰고, 다시 외출했습니다. 등산 중에도 가끔씩 진행 상황을 확인하곤 했습니다—아이들과 함께할 때는 스마트폰을 보지 않아야 하지만, 스마트폰으로 원격으로 작업이 어디까지 진행되었는지 확인하는 느낌은 정말 좋았습니다.
그때 저는 한 가지 아이디어를 떠올렸습니다: 소프트웨어가 내부에서 스스로 수정되는 극단적인 실험을 해볼 수는 없을까?
저는 모바일 버전과 웹 버전 두 가지를 동시에 만들도록 했습니다. 이미 채팅 인터페이스를 만들었고, 클로드에게 “이 URL을 추적 목록에 넣어줘”라고 말하면 바로 작동합니다. 그러나 저는 모든 소프트웨어가 이런 능력을 갖추기를 원했습니다—더 이상 복잡한 메뉴 계층을 헤매며 기능을 찾을 필요가 없습니다.
Dan, 저는 여러 면에서 에이전트-네이티브 아키텍처를 가장 극단적인 경계까지 밀어붙이려는 시도를 하고 있습니다.
즉, 에이전트-네이티브 아키텍처의 첫 단계는, 제품 내 모든 핵심 구성 요소와 데이터가 에이전트에 대해 완전히 개방되어야 하며, 각각에 대응하는 도구 호출 인터페이스가 있어야 한다는 것입니다. 이는 소프트웨어 산업의 ‘생존선’으로 빠르게 자리 잡고 있습니다—비극적이게도 현재 시장에 존재하는 대부분의 소프트웨어는 이 기본 조건조차 충족하지 못합니다.
좋은 긍정적 사례가 있습니다: 얼마 전 누군가 브라질의 훌륭한 드라마를 추천해줬는데, 고이아니아의 방사능 누출 사건을 다룹니다. 이름이 매우 길고 어렵게 기억나지 않았는데, 저는 시스템에 애매하게 한마디만 했더니, 클로드가 즉시 검색해 정확히 분류해 주었습니다. 이 경험은 제가 직관적으로 구글에서 아무렇게나 검색하는 것보다 훨씬 좋았습니다.
그러나 제가 진정으로 몰입한 다음 단계는 모바일 환경에서 소프트웨어 내부에서 소프트웨어 자체를 직접 수정하는 것이 어떤 모습일지입니다.
제가 한 일—정확히 말하자면 제가 클로드에게 지시한 일—은 다음과 같은 상호작용입니다: 앱에서 채팅 버튼을 길게 누르면, 우리의 호스팅된 에이전트가 ‘코드 수정 지시’를 수신하도록 활성화됩니다. 그리고 Vercel의 실시간 미리보기(Live Preview) 기능을 활용해 바로 결과를 확인합니다. 전체 기능 모듈도 거의 단번에 실행되었고, 매우 멋졌습니다. 이후 저는 계속해서 새로운 아이디어를 추가했습니다. 하드코어 사용자라면, Diff(코드 차이) 보기로 들어가거나, 호스팅된 에이전트의 대화 기록을 클릭해 그것이 실제로 어떤 코드를 수정했는지 확인할 수도 있습니다—하지만 저는 거의 보지 않습니다. 왜냐하면 개인용 장난감 프로젝트에서는 장기적인 유지보수성은 전혀 중요하지 않기 때문입니다(웃음).
이걸 사용하는 건 정말 중독성 있습니다. 아이들과 외부에서 놀다가 ‘이 플로팅 버튼이 iOS에서 너무 아래에 있다’고 느꼈을 때, 앱 안에서 바로 말만 하면, 클로드가 스스로 뒷단에서 코드를 고쳐버립니다. Expo 개발 도구 체인과 결합하면, 클로드는 제 스마트폰에서 바로 핫 리로드(Hot Reload)를 수행하기까지 합니다. 그 순간의 경험은 정말 최고였습니다.
이것이 백만 명의 동시 사용자를 감당할 수 있는 프로덕션 수준이어야 합니까? 전혀 필요 없습니다. 그러나 이는 제게 뛰어난 통제감을 줍니다: 주말이 끝나고 컴퓨터를 닫는 순간에 프로젝트가 멈춰야 할 필요가 없습니다—이를 집중적으로 사용하면서도, 동시에 사용하는 과정에서 언제든지 개선할 수 있습니다. 이처럼 단말에서 단말까지 실시간으로 닫히는 루프는 무한한 반복 개선을 가능하게 합니다.
이는 단순히 Fable의 강력한 엔지니어링 구축 능력을 lucidly 보여주는 쇼케이스일 뿐 아니라, 우리가 계속해서 탐구해온 궁극적 질문의 축소판이기도 합니다: 클로드는 소프트웨어에 어떻게 통합되어야 할까? 단순히 ‘사용’ 수준에 머무르는 것이 아니라, 소프트웨어의 ‘구축’이라는 골수 속 깊이 침투해야 한다.
구축 비용의 붕괴
진행자 댄 쉽퍼: 저는 사람들이 이 같은 도구를 10년, 20년 전에도 만들 수 있었다는 사실을 인식시키고 싶습니다. 그러나 절대 이런 방식으로는 만들 수 없었습니다. 소프트웨어 구축 비용은 절벽처럼 붕괴되었습니다. 인스타그램 시대를 돌이켜보면, 이 정도 완성도의 프로젝트를 구현하려면 얼마나 많은 자원을 투입해야 했습니까? 지금은 얼마나 필요한가요? 이 시대의 격변을 정량적으로 설명해 주십시오.
마이크 크리거:
저는 자주 그 시절을 떠올립니다. 인스타그램 초기, 저는 효율적인 엔지니어라고 자부했습니다—모바일 개발에 대한 열정과 제품 방향에 대한 강한 직관을 지녔습니다. 그러나 그럼에도 불구하고, 머릿속 아이디어에서 완전한 구현까지는 여전히 최소 4~5번의 야근이 필요했습니다. 당시 야근은 제 일상이었습니다: 새벽 4시까지 코딩하고, 낮까지 자는—이 생활 패턴은 가정생활과 완전히 단절되었지만, 이것이 바로 제가 당시 ‘빌더(builder) 모드’였습니다.
인스타그램 V1 버전을 돌이켜보면—기능 면에서 제가 이번 주말에 만든 미디어 추적기보다는 조금 더 많긴 하지만, 절대적인 양적 차이는 없습니다. 그런데 당시 그 V1을 만들기 위해 케빈과 저는 연속 5박을 새워야 했습니다. 저는 프론트엔드와 백엔드를 모두 혼자 맡았고, 케빈은 초기 사진 필터를 담당했습니다. 그리고 이는 우리 둘 모두가 수년간의 iOS 개발 경험을 바탕으로 한 것이었습니다.
더욱 말할 것도 없이, 당시의 반복 주기는 얼마나 답답했는가. 제품이 한 번에 대박을 터뜨린 후, 우리는 무수한 새 아이디어를 머릿속에 담고 있었지만, 당시 모든 에너지는 대량 트래픽에서 서버가 다운되지 않도록 보장하는 데 쏟아졌거나, 미세한 기능 하나를 추가하기 위해 겨우 시간을 빼내는 데 소비되었습니다. 해시태그(Hashtag) 기능만 해도, 당시 저는 그것을 완성하는 데 일주일이 걸렸고, 손에 들려 있는 다른 천 가지 아이디어는 모두 일정표에 묶여 있었습니다.
따라서 이것은 단순히 시간이 단축된 것이 아닙니다—물론 구축 시간은 정말 경악스럽게 짧아졌습니다—더 중요한 것은 동전의 다른 면입니다: 지금 당신은 매우 매끄럽고 유동적인 방식으로, 이미 가지고 있는 것을 즉각적으로 반복 개선할 수 있습니다.
그리고 이 혜택은 이미 저 같은 전문 소프트웨어 엔지니어나 창업자 집단을 훨씬 넘어서 확산되고 있습니다. 과거에는 훌륭한 비즈니스 아이디어가 있지만 코드를 쓸 줄 몰랐다면, 당신의 선택지는 두 가지뿐이었습니다: 외주를 맡기는 것—이 과정에서 심각한 정보 왜곡과 부실한 산출물이 발생했거나, 아니면 미친 듯이 자금 조달을 시도하는 것이었습니다. 그러나 지금은, ‘의도’에서 ‘실행’으로 이어지는 그 깊은 협곡은, 코딩을 모르는 일반인들 사이에서도 이미 완전히 평탄화되었습니다.
며칠 전, 내부 동료로부터 핑(Ping)을 받았습니다. 우리는 그녀를 위해 내부 도구를 설정해 Fable의 기능과 내부 MCP(모델 맥락 프로토콜) 접근 권한을 연동시켰습니다. 그녀는 채용(HR) 담당자였고, 흥분해서 이렇게 말했습니다: “이것은 제 인생에서 처음으로, 제 머릿속 생각과 현실 세계에 존재하는 것 사이에 전혀 거리가 없음을 느낀 순간입니다. 바로 그것을 만들어낼 수 있습니다.”
그 순간对她而言, 절대적으로 이정표적인 충격적인 순간이었습니다. 만약 4~5년 전이었다면, 그녀가 전용 업무 도구를 원했다면, 기성 소프트웨어를 어설프게 조합해 쓰거나, 내부 도구 팀의 엔지니어에게 간청해야 했을 것입니다—그들의 Jira 요구사항 풀에는 이미 50개 이상의 우선순위가 더 높은 요청이 대기 중이었을 테니까요. 그러나 지금은? 그녀가 스스로 코드 세계에서 새로운 영토를 개척하며 즐기고 있습니다.
이것이 제가 미래에서 가장 기대하는 부분입니다: 인간의 창의력은 무한하지만, 우리가 오늘날 가장 위대하게 해내고 있는 일은 바로 ‘머릿속 생각을 현실로 바꾸는 능력’을 갖춘 사람들의 범위를 무한히 확장하는 것입니다.
소프트웨어 엔지니어링은 죽었는가?
진행자 댄 쉽퍼: 저는 당신의 관점을 완전히 동의합니다. 그러나 지금 많은 사람들이 마음속에 마지막 궁극적 의문을 품고 있을 겁니다. 방금 당신이 설명한 모든 것을 듣고, 소프트웨어 엔지니어링이라는 분야는 완전히 망해버린 것입니까?
마이크 크리거:
오히려 소프트웨어 엔지니어링의 본질이 완전히 바뀌었습니다. 이 분야는 천변지이의 격변을 겪고 있습니다.
인스타그램 시절에 제가 “소프트웨어 엔지니어링이란 무엇인가?”라고 물었다면, 저는 아마 이렇게 대답했을 것입니다: “꼬리에 꼬리를 무는 설계 난제를 철저히 고민하고, 시스템 아키텍처를 구축한 후, TextMate나 Xcode에서 엄청난 시간을 보내는 것.” Django ORM(객체 관계 매핑)의 저수준 세부 사항을 고치고, 배포하고, 버그를 고치느라 고생하는 것. 지금 이 프로세스의 대부분은 이미 뒤집혔으며, 제품 관리의 경계로 빠르게 이동하고 있습니다. 지금은 제품 매니저와 엔지니어 사이의 명확한 경계가 매우 흐릿해졌습니다. 이 점은 우리 자체 연구개발 팀에서도 매우 분명하게 나타납니다.
하지만 “소프트웨어 엔지니어링”이라는 너무 딱딱한 문자 그대로의 정의를 벗어나, 더 광범위한 “소프트웨어 생산” 또는 “소프트웨어 개발”—순수한 프로그래머의 코드 작성을 가리키는 좁은 범위가 아니라—를 바라본다면, 이 산업은 단지 살아남은 것이 아니라, 전례 없이 핵심적인 위치에 서 있습니다.
Fable의 등장은 제가 AI 모델에 대한 신뢰를 완전히 새로운 수준으로 끌어올렸습니다—이제 저는 이 모델에게 “완전 자동 닫힘 루프를 실행하거나, 합리적인 시스템 아키텍처 설계를 수행하라”고 맡기기 시작했습니다. 기술 실행 측면에서는 AI가 이미 매우 먼 길을 갔습니다. 그러나 “소프트웨어라는 기술의 영혼을 통제하는 것”—즉, 당신이 정확히 어떤 사용자 고통 포인트를 해결하고 있는가, 당신이 만든 것이 얼마나 놀라운 사용자 경험을 제공하는가—이러한 최상위 판단력은 여전히 순수하고, 기계로는 대체 불가능한 인간의 특성입니다.
물론, 이러한 고통스러운 전환은 많은 사람들에게 무통은 아닙니다.
이 세상에는 “순수한 수공예 코드 작성”에 깊이 매료된 사람이 너무 많습니다. 저도 예전에는 그랬습니다. “이 버그를 사흘 동안 고민하다가 오늘 정말 멋지게 해결했어!”라는 쾌감은 대체할 수 없습니다. 과거에는 꿈속에서도 코드와 씨름하기도 했습니다—그런 경험을 해보신 분이라면, 꿈속에 논리가 가득 차 있고, 잠에서 깨어나는 순간 갑자기 해결책이 떠오르는 것을 아실 것입니다. 이런 순수한 장인 시대는 아마도 진정으로 끝났을 가능성이 높습니다.
최근 저는 제가 아는, 업계 최고의 하드코어 엔지니어들과 대화를 나누었는데, 그들은 모두 강렬한 복합 감정을 표현했습니다: 한편으로는 전통적 장인 기술의 소멸을 목격하는 거대한 상실감, 다른 한편으로는 ‘천국이다, 내 동시 생산성은 정말 놀랍게 뛰어나다’는 극도의 흥분.
앤트로픽 엔지니어링 팀은 지금 어떻게 일하는가
진행자 댄 쉽퍼: 이 전제가 성립한다면—소프트웨어 엔지니어링은 단지 살아남은 것이 아니라, 오히려 매우 잘 살고 있다—그렇다면 앤트로픽 내부에서, 여러분의 연구개발 팀은 실제 일상에서 어떻게 업무를 수행하고 있습니까?
마이크 크리거:
이에 대해 몇 가지 매우 분명한 단서가 있습니다. 저는 전체 소프트웨어 생명주기와 제가 매일 보는 연구개발 현장을 바탕으로 설명하겠습니다.
첫째, 여전히 많은 ‘인간 대 인간 조율’이 있습니다. 팀은 회의실에 모여 Cowork의 다음 진화 방향에 대해 브레인스토밍하고, 그 청사진을 다양한 구성원의 책임 영역으로 분해합니다. 이 단계는 여전히 매우 중요합니다. 왜냐하면 현재의 클로드가 공중에서 감지할 수 없는 많은 전반적 맥락은 인간만이 이해할 수 있기 때문입니다—예를 들어, 이 제품의 실제 상업적 의도, 현재 진행 중인 개발 암선, 그리고 곧 종료될 예정이거나 매우 미묘한 방식으로 통합될 예정인 다른 제품 라인에 대한 정보 등입니다.
우리 팀원 각자에게는 여러 대의 클로드 타워가 배정되어 있지만, 관리 측면에서는 여전히 DRI(Directly Responsible Individual, 직접 책임자)라는 타이틀이 각자 머리 위에 걸려 있으며, 제품의 특정 모듈에 대해 책임을 집니다. 저는 이 메커니즘이 단기간 내 사라지지 않을 것이라고 생각합니다. 왜냐하면 “팀이 분산 협업하여 제품을 완벽하게 다듬는다”는 거시적 전략과 “오늘 내가 클로드에게 어떤 구체적인 작업을 실행하게 해야 할까”라는 미시적 실행 사이에는 본질적인 간극이 존재하기 때문입니다. 우리는 극소회의제를 적극적으로 추진하고 있지만, 이러한 사전 브레인스토밍과 조율 회의는 여전히 필수적입니다.
둘째, 많은 ‘비동기 위임’이 있습니다. 여기 많은 엔지니어들이 각자 개인 대시보드를 개조해, 자신의 클로드 군대가 무엇을 하고 있는지 모니터링합니다: “내 클로드 코드는 어디까지 왔을까?”, “어떤 것이 큐에 대기 중이며 내가 승인해야 할까?”, “어떤 PR이 다른 동료나 대규모 모델의 코드 리뷰에 의해 반려되어 내가 개입해야 할까?”
지금, 엔지니어들은 이러한 작업 유지에 많은 에너지를 쏟고 있습니다. 이 중 일부 협업 도구는 표준화를 추진 중이지만, 대부분은 강한 해커 개인주의를 유지하고 있습니다—과거 프로그래머들이 데스크톱 창을 개인화하듯이, 지금은 그들이 자신의 대규모 모델 워크플로를 개인화하고 있습니다.
셋째, 프로덕션 환경에서 코드가 실제로 어떻게 작동하는지 이해하는 것입니다. 이는 현재 대규모 모델이 집중적으로 공략하고 있는 또 다른 선두 분야입니다. Fable은 이 분야에서 상당한 진전을 보여주었지만, 아직 갈 길이 멀습니다: 예를 들어, 코드가 배포된 후 실제로 어떤 일이 일어나는지 깊이 이해하는 것. 시스템은 다운될 수 있고, 예측할 수 없는 이상 현상이 발생할 수 있습니다—솔직히 말해, 2012년부터 2016년까지 인스타그램의 몇 년간, 저는 대부분의 생명을 이러한 온라인 사고 대응과 아키텍처 확장에 바쳤습니다. 온라인 긴급 상황 대응 시, 고급 엔지니어의 역할은 여전히 대체 불가능합니다: 당신은 수년간의 사고 대응 경험을 바탕으로 절대적인 침착함을 유지하고, 로그 데이터를 전량 수집하며, 응급 조치를 시행한 후, 근본적인 장기 해결책을 도출해야 합니다.
마지막으로 강조하고 싶은 점은: ‘엔지니어링 프로토타입’이 오늘날 어떤 역할을 하는가입니다.
당신은 반드시 명확히 구분해야 합니다: 당신이 손에 쥔 이 것이 단순한 데모인지, 아니면 프로덕션에 배포될 준비가 된 코드인지. 과거 실리콘밸리에서는 “코드가 논쟁을 이긴다(Code wins arguments)”는 말이 유행했는데, 저는 개인적으로 이 말을 그리 좋아하지 않았습니다. 왜냐하면 이 말의 암묵적 전제는 ‘누가 코딩을 할 수 있느냐’가 곧 권력의 중심이라는 점 때문입니다. 그러나 지금은 상황이 아주 흥미롭게 반전되고 있습니다: 때때로 제품의 어떤 방향성에 대해 의견이 분분할 때, 어느 날 코드를 작성하지 않는 PM이 다가와 “방금 제가 직접 데모 하나 만들어봤어요. 물론 8가지 디테일에서 아직 거칠긴 하지만—보세요, 이 길은 분명히 통합니다!”라고 말하는 경우가 종종 있습니다. 이 순간, 완전히 다른 차원의 고차원 대화가 시작됩니다.
돌이켜보면, 우리의 거의 모든 연구개발 방식은 6개월 전과 비교해 완전히 달라졌습니다. 가장 눈에 띄는 특징은 끔찍할 정도의 개발 동시성과 팀이 워크플로를 고차원적으로 추상화해야 하는 절대적 필요성입니다.
그러나 유일하게 변하지 않은 한 가지는 인간이 제품에 대해 느끼는 “소유권과 책임감”입니다.
검증 메커니즘
진행자 댄 쉽퍼: Fable도 비쌉니다. 제가 테스트할 때, 마치 사탕가게에 들어선 아이처럼 흥분하며 “이거, 이거, 그리고 이거!”라고 외쳤습니다. 그러나 결제할 때가 되면, 매번 엔터를 누르기 전에 망설입니다. “이 한 번에 100달러 이상, 심지어 더 많이 나갈지도 모른다?” 저는 이 높은 가격이 실제로 ‘누가 이걸 사용할 수 있는가’, ‘무엇을 위해 사용할 수 있는가’에 무형의 문턱을 세우고 있다고 생각합니다. 당신은 이 상업적 성과비를 어떻게 보시는지요?
마이크 크리거:
전문 소프트웨어 엔지니어링 분야에서는 이 계산이 가장 명확하게 이루어집니다. 가격 책정에 대해서는 내부적으로 여러 차원의 고려가 있습니다. 이 모델은 분명히 Opus보다 훨씬 비싸지만, 단회 제공되는 놀라운 작업량을 고려한다면, 많은 상업적 측면에서 보면 거의 무료나 다름없다고 느낄 수도 있습니다. 물론, 각자의 경제적 계산은 다를 수 있습니다.
소프트웨어 팀 관점에서 보면, 첫 단계는 기업이 직원들에게 AI 프로그래밍을 받아들이도록 하는 것입니다—모델은 아직 초기 단계이며, 도구도 아직 준비되지 않았습니다. 두 번째 단계는 누가 가장 많이 사용하는지 보는 랭킹을 만드는 것으로, 이는 바람직하지 않은 인센티브 메커니즘을 유발할 수 있습니다. 세 번째 단계는 누가 가장 효과적으로 사용하는지를 파악하고, 이들이 최대한 많이 사용할 수 있도록 하되, 낭비를 방지하는 명확한 프로세스를 갖추는 것입니다.
Fable 수준의 모델은 이 세 번째 단계의 논리에 완벽히 부합합니다. 만약 당신이 지속적으로 하드코어 산출물을 내놓고, 사업에서 실제로 진짜 가치를 창출한다면, 기업 내부에서는 당신을 무한히 지원하는 긍정적인 피드백 루프 예산 메커니즘이 자연스럽게 형성될 것입니다.
개인 사용 측면에서는, 저는 테스트를 위해 개인 신용카드로 자사 서비스를 직접 구매합니다. 이때 당신은 정말 아껴쓰고, 더욱 신중해집니다. 그러나 흥미로운 점은, 제가 주말에 만든 미디어 추적기는 평소보다 약간 더 비쌌을 뿐이며, 개인용 장난감 프로젝트를 만들기 위해 수천 달러를 태우는 상황은 전혀 발생하지 않았다는 점입니다.
지금 실제로 가격 때문에 막힌 것은, 대기업의 보호를 받지 못하고 가격에 매우 민감한 오픈소스 애호가나 독립 개발자(Indie Hackers)들입니다. 제가 드리는 조언은: 망설이지 말고 실행해보세요. 무한한 ‘왕복 토론’ 없이, 이 모델이 단번에 얼마나 많은 것을 제공할 수 있는지 확인해보세요.
지금의 ‘비용’ 개념은 이미 다차원적으로 진화했습니다—단순히 ‘한 번의 질문 비용’만 계산하는 것이 아니라, ‘한 가지 일을 완전히 처리하는 종합 비용’을 산정해야 합니다. Fable이 저를 가장 놀라게 한 점은 바로 이 후자입니다: 이 모델은 항상 한 번에 일을 제대로 해내려고 하며, 제가 컴퓨터 앞에 앉아 여덟 아홉 차례나 반복해서 교정할 필요가 없습니다. “아니요! 그게 아니에요!”라고 절망적으로 외칠 필요가 없습니다.
진행자 댄 쉽퍼: 저를 가장 놀라게 한 점은, 거대한 작업을 맡기면, 제출할 때 모든 구석구석의 디테일까지 미리 예측해주는 것입니다. 이런 숨 막히는 섬세함은 이전의 어떤 모델에서도 경험하지 못했습니다. 훈련에 대한 내부 비밀을 조금 알려주실 수 있습니까? 도대체 무엇이 이처럼 놀라운 통찰력을 길러냈습니까?
마이크 크리거:
많은 면에서, 이는 팀의 막대한 작업의 연장선입니다—저는 우리의 사전 훈련 및 강화학습(RL) 팀을 존경합니다. 저에게 가장 뚜렷한 진화는 “현재 작업에 대한 인식”이 아니라 “전체 시스템에 대한 인식”입니다.
저는 종종 그의 신비로운 조작에 충격을 받습니다. 예를 들어, 그가 방금 코드를 작성한 후 갑자기 이렇게 말합니다. “대장님, 저는 실제 프로덕션 환경에서 여기 설정이 다를 수 있다는 걸 알고 있습니다. 그 기능 스위치는 켜져 있나요? 안 켜져 있다면, 제가 방금 작성한 이 코드는 배포되어도 작동하지 않습니다.”
또는 코드 리뷰 피드백에 대한 반응을 보세요—사람이든 다른 클로드든 간에—그는 단순히 “맞아요, 문제가 있네요. 고치겠습니다.”라고 말하지 않습니다. 그는 현재 충실도 수준에서 위험을 수용할지 여부를 진정으로 고민하거나, 다른 리뷰어—종종 또 다른 Fable 모델—를 반박하기도 합니다. “당신의 의도는 이해했습니다만, 저는 반박합니다. 제 생각에는 틀렸습니다.”
모델이 이런 판단력을 갖는 것은 매우 중요합니다. 제가 지적하고 싶은 가장 큰 진보는, 그가 즉각적으로 무릎 반사식으로 “맞아요, 고치겠습니다.”라고 말하지 않는다는 점입니다—그보다는 “잠시 생각해보겠습니다. 저는 여전히 동의하지 않습니다.”라는 능력입니다. 이 능력은 매우 유용합니다.
클로드 코드와 같은 제품이 시장에 존재하는 것은 매우 소중합니다. 왜냐하면 살아있는 제품이 있으므로, 사람들이 “이 모델은 여기서 잘하고, 여기서는 못한다”고 말할 수 있기 때문입니다. 우리는 Every의 동료들을 가장 높은 우선순위의 신뢰할 수 있는 피드백 출처로 매우 높은 위치에 배치하고 있습니다. 왜냐하면 그들이 모델을 여러 날에 걸쳐 집중적으로 고강도 작업에 사용하기 때문에, 다음 세대에서 무엇을 개선해야 할지를 생각하는 데 매우 중요하기 때문입니다.
진행자 댄 쉽퍼: 챗이 이 모델에 가장 적합한 인터페이스입니까? 이는 단순한 라운드식이 아니라, 누군가에게 일을 위임하는 것과 더 비슷합니다. 이는 당신이 어떻게 이 모델을 사용해야 하는지, 또는 이 인터페이스를 어떻게 바라봐야 하는지에 어떤 영향을 미칩니까?
마이크 크리거:
메시지 전송 및 수신이라는 기본 모델은 완전히 틀린 것은 아니지만, 우리는 몇 가지 방향으로 진화해야 합니다.
첫째: 노트북이 올바른 장소입니까? 바로 이전에 제가 모바일이 개인 프로젝트에 얼마나 좋은지 언급한 부분입니다. 클로드 코드의 창시자들은 이러한 모델이 어떻게 사용되는지 항상 반보 앞서 있습니다. 약 9개월 전, 제가 그와 대화했을 때 그는 “저는 클로드 코드 작업의 대부분을 모바일로 옮겼습니다.”라고 말했습니다. 저는 당시 의심스러웠지만, 특히 Fable 수준에 이르면, 대화를 유지할 수 있고, 앤트로픽에 원격 개발 머신이 있기 때문에 첫 번째 점은: 작업이 일어나는 장소와 제가 작업에 대해 논의하는 장소를 분리하는 것입니다.
두 번째는 제가 이전에 언급한 것과 연결됩니다: Fable이 논의하고 결정하고 제안한 모든 것을 어떻게 이해할 수 있도록 만들 수 있을까? 이는 우리가 현재 고민하고 있는 분야입니다. 그래프를 그리는 기능은 있지만, 현재의 챗 UI는 충분하지 않습니다. Fable은 때때로 엄청난 양의 텍스트를 제공하는데, 이를 이해하려면 산책을 나가야 할 정도입니다. 제가 시작한 한 가지는 “이 일에 대한 맥락은 제 것보다 훨씬 많습니다. 그럼, 복잡성에 대한 점진적 공개를 더 많이 해보는 건 어떨까요?”입니다.
세 번째는 다중 사용자 모드인데, 이 분야는 아직 초기 단계입니다. 어느 정도는, 우리가 DRI와 소유권 영역 구조를 갖고 있기 때문에, 중요한 작업은 보통 한 사람과 몇 대의 클로드 사이에서 흐릅니다. 그러나 어떤 경우에는 그렇지 않기도 합니다—예를 들어 사고 대응이나 여러 분야가 교차하는 프로젝트일 때입니다. 챗 공유는 일부 문제를 해결할 수 있지만, 저는 미래에 이런 수요가 있을 것이라고 생각합니다: 한 사람이 시작해 많은 작업을 수행한 독립적인 클로드가, 팀 내 다른 모든 작업과 동기화될 수 있는가? 이것은 다음 단계의 흥미롭고 아직 탐색되지 않은 선두 분야입니다. 흥미로운 점은, 모델이 이제 진정한 팀원이 될 수 있는 능력을 갖추었고, 우리는 단지 올바른 추상화가 부족해서 그 능력을 저해하고 있는 것뿐입니다.
진행자 댄 쉽퍼: 이 말을 듣고, 저는 대부분 이 모델을 개인적인 바이브 코딩(vibe coding) 프로젝트에 사용한다고 생각했습니다. 그러나 조직 내에서 사용할 때 한 가지 문제가 있습니다: 제가 모델이 방금 한 모든 부분을 정말로 이해하고 있습니까? 모델이 방금 완료한 작업의 맥락을 제 머릿속으로 옮기는 방법은 무엇입니까? 이것은 큰 병목입니다. ‘제가 정확히 얼마나 알아야 할까’라는 선을 어디에 그어야 하며, 충분한 맥락을 확보해 안심할 수 있도록 보장하는 방법은 무엇입니까?
마이크 크리거:
두 가지 큰 부분이 있습니다. 첫 번째는 검증입니다. 저는 올해 초에 검증에 완전히 설득당했습니다. 이는 제가 전직으로 코드를 작성할 때의 한 가지와 통합니다: 당신의 아이디어를 중심으로 가장 빠른 개발 루프를 찾는 것. 인스타그램 시절에는, 때때로 Xcode에서 새 빌드 대상을 만들고, 그 화면과 합성 데이터만 포함하여 그 루프만 반복하는 것을 의미했습니다. 저는 신입 엔지니어들에게 “제가 단 하나만 가르친다면, 바로 당신의 프로젝트에 이것을 만들어보는 것일 겁니다. 그러면 훨씬 빨라질 겁니다.”라고 조언했습니다.
현재 상황은 이렇습니다: 제가 무언가를 구축할 때마다, 클로드의 모든 PR이 사진이나 동영상과 함께 제공되도록 보장합니다—iOS PR이든 UI 레이어 변경이든 간에 말입니다. 이를 통해 많은 신뢰를 얻을 수 있습니다. Fable이 몇 시간 동안 작업을 하고 돌아와서 “완료했습니다.”라고 말하면, “여기 전체 UI의 스크린샷 갤러리입니다.”라고 말하는 것이 매우 유용합니다. 그러면 “스크린샷 8번의 오류 상태—저는 실제로 본 적은 없지만, 사용자가 마주쳤을 때 어떻게 될지 알 수 있습니다. 이것을 수정해주세요.”라고 말할 수 있습니다. 포괄적인 검증은 우리 내부에서 계속해서 강력히 추진하고 있는 일입니다.
두 번째는, 결국 당신이 당신이 한 작업에 대해 책임을 져야 한다는 점입니다. 많은 사람들이 매일 클로드를 사용하지만, 여전히 책임이 있습니다—“클로드가 코드를 작성했을지 모르지만, 당신은 어떤 거시적 결정을 내렸는지 이해해야 합니다.” 저는相当 많은 엔지니어들이 다음과 같은 실천을 시작하는 것을 보았습니다: 클로드가 작업을 완료한 후, 후속 대화를 통해 “당신이 한 모든 선택을 제가 철저히 이해할 수 있도록 보장할 수 있습니까?”라고 묻는 것입니다. 산출물이 어떤 작은 아티팩트든, 그것이 쉽게 이해될 수 있도록 만드는 것이 가치 있습니다.
회의 중에는 흥미로운 일이 벌어집니다—누군가 “이 PR 준비됐습니다.”라고 말하면, 다른 사람이 “X를 했습니까, Y를 했습니까?”라고 묻습니다. 그러면 순간적인 정적이 흐릅니다. “솔직히 말해, 저는 잘 모르겠습니다—병합 전에 확인해보겠습니다.” 이 새로운 정상 상태에 적응하고, 어떻게 협업해야 하는지를 파악하는 것은 우리 모두가 배워야 할 과제입니다.
진행자 댄 쉽퍼: 방금 언급하신 ‘검증 루프’는 상상력이 풍부합니다. 자동화된 스크린샷과 화면 공유 외에, 더 하드코어한 접근법을 탐색하고 계신가요?
마이크 크리거:
우리의 핵심 접근점은 다음과 같습니다: 정적 데이터를 주입하는 것이 아니라, 실제 프로세스를 실행하게 할 수 있는가? 시스템이 점점 더 복잡해짐에 따라, 이는 점점 더 어려워집니다. 예를 들어, 우리는 Fable이 만든 iOS 애플리케이션이 우리 시뮬레이션 환경에 한 번의 클릭으로 로그인할 수 있도록 해야 합니다. 사용되는 계정은 모두 가장 진실된 테스트 계정이며, 고충실도의 실제 스트림 데이터를 호출합니다. 그러나 동시에, 우리는 버튼 미세 조정 하나를 테스트할 때마다 매번 8단계의 번거로운 신규 사용자 등록 프로세스를 거치게 하고 싶지 않습니다. 따라서 우리는 AI 전용 특별 고급 권한 및 암호화된 공유 키 체계를 전문적으로 개발하여, AI가 사전 단계를 한 번의 클릭으로 건너뛰고, 가장 핵심적인 비즈니스 현장으로 바로 진입할 수 있도록 했습니다. 이를 통해 AI의 테스트 감각과 실제 사용자가 손에 쥔 경험을 픽셀 단위로 거의 완벽하게 일치시킵니다.
두 번째는 알려진 경로와 현재 변경 경로의 조합—전자는 회귀 테스트에 매우 가치가 있습니다. 우리는 이미 이상적인 워크플로를 텍스트로 표현했고, 클로드는 이를 반복적으로 검사할 수 있습니다. 또한 클로드는 현재 수행 중인 변경의 의도를 표현하는 데도 매우 뛰어나므로, 이 부분은 깊이 있게 연습됩니다. 이 두 가지의 조합은 매우 중요합니다.
시각적 검증도 매우 중요하며, 동영상은 클로드에게 아직 거의 활용되지 않은 극도로 강력한 도구입니다. 최근 저는 프로토타입을 하나 만들고 있는데, 클로드가 만든 것을 동영상으로 녹화해 전달하고 FFmpeg와 결합하여, 클로드가 프레임 단위로 분석하면서 ‘이 애니메이션이 끊기네요, 제가 고칠게요’라고 말하게 합니다. 스크린샷은 절대 이를 포착할 수 없습니다. 왜냐하면 스크린샷은 그 순간을 놓치기 때문입니다.
단말에서 단말까지 테스트하기 어려운 부분에 대해서는, 클로드가 신뢰할 수 있는 시뮬레이션 백엔드를 구축하거나 기존의 것을 사용하는 것도 매우 흥미롭습니다. 아티팩트 시대에는, 사전 LLM 시대에도 매우 포괄적인 테스트가 있었습니다. 모든 인프라스트럭처는 단위 테스트에서 빠르게 실행할 수 있는 훌륭한 메모리 구현을 갖추고 있었습니다. 지금은 이를 클로드 영역으로 확장합니다: 저는 상당히 견고한 백엔드를 가진 것을 만들고 있는데, 개발 서버에서 시작하기 어려웠지만, 클로드가 단번에 훌륭한 대체품을 만들어주었습니다. 시간이 지남에 따라, 이 대체품은 코드 자체의 진화와 함께 진화합니다. 과거에는 “이걸 동기화하는 게 너무 힘들다”고 말했을 것입니다. 지금은 “클로드가 변경 사항을 읽고, 대체품을 적응시켜 양쪽을 동기화할 수 있다. 끝.”이라고만 생각합니다.
진행자 댄 쉽퍼: 흥미로운 아키텍처가 있습니다: 버그를 받으면, 에이전트가 자동으로 고치고, 고객에게 ‘수정 완료’라는 메시지를 보냅니다. Fable에서 이러한 프로세스에 변화가 있습니까?
마이크 크리거:
몇 가지 측면에서 그렇습니다. 인간과 클로드의 측면에서, 제가 반복해서 보는 한 가지는 다음과 같습니다: 누군가 우리 Slack 피드백 채널에서 버그를 보고하면, 이 스레드가 클로드 코드 대화에 전달된다. Slack MCP 덕분에, 클로드는 실제로 그 스레드를 가져와 제 이름으로 이렇게 응답할 수 있습니다. “마이크의 클로드입니다. 수정했습니다. 여기 PR 링크입니다.” 그러나 이후 클로드는 이렇게 말합니다. “서두르지 마세요—아직 배포되지 않았습니다. 배포된 후 다시 알려드리겠습니다.” 몇 시간 후: “이 배포가 완료되었습니다. 수정이 되었는지 확인해보시겠습니까?” 이런 닫힘 루프 추적은 비교적 새로운 것입니다. 저는 제 이름으로 상호작용하는 장기 실행 클로드 코드 대화를 여러 개 가지고 있습니다. 그 안에는 면책 조항도 몇 가지 넣어두었습니다.
두 번째는 우리가 방금 논의한 취향과 판단으로 돌아갑니다. 한 측면은 ‘버그 보고가 있으니 고쳐야 한다’는 것이고, 다른 측면은 좋은 판단력입니다. 저는 주말에 이런 상황을 겪었습니다. 우리 내부 시스템이 오랜 시간 동안 재시작되지 않아 메모리 누수가 발생했습니다. 좋은 판단은 다음과 같습니다. “마이크, 지금은 주말입니다. 서버를 재시작하면 지금 당장 해결됩니다. 저는 비동기적으로 장기 수정을 위한 PR을 열겠습니다.” 클로드가 이런 버그-수정 프로세스에 개입하려면, 좋은 SRE나 엔지니어가 이해할 수 있는 것을 반드시 이해해야 합니다: 현재 문제를 해결하는 것, 그리고 플랫폼을 재구성할지 여부는 별도의 문제입니다. 이 균형을 이해하는 것이 매우 중요합니다.
사람들이 이 모델로 무엇을 구축해야 하는가
진행자 댄 쉽퍼: 이 세대 신모델이 가장 흥분되는 점은, 단순히 하한선을 높여서 아무 배경도 없는 일반인이 한 번의 클릭으로 자신만의 앱을 만들 수 있게 하는 것뿐만 아니라, 전문가의 천장을 완전히 뒤엎는 데 있습니다. 지금 당신이 전문 엔지니어이거나 창업 팀의 창립자라면, 이전에는 꿈도 꾸지 못했던 하드코어 프로젝트를 혼자서도 해결할 수 있습니다. 당신은 현재 사람들이 아직 깨닫지 못했지만, 이 세대 모델로 무작정 도전해볼 수 있는 선두 분야가 무엇이라고 보시는지요?
마이크 크리거:
몇 가지 아이디어를 제안해보겠습니다. 아마 재미있는 것부터 시작해보죠. 사람들은 자신의 세계의 복잡성을 표현하는 방법에 대한 창의적인 아이디어를 늘 가지고 있습니다. 각 분야에는 자신이 특히 잘 아
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
深潮TechFlow
