Mythos와 함께 일한다는 느낌
Mythos와 함께 일한다는 느낌
Ethan Mollick(우든 경영대학 교수)이 대중에게 공개된 최초의 Mythos급 AI 모델인 Claude 5 Fable을 미리 사용해 본 경험을 기록한 글이에요. GeekNews에서 번역된 버전과 Hacker News 커뮤니티의 반응을 함께 분석했어요.
한 줄 요약
Claude 5 Fable은 최대 12시간 동안 스스로 다단계 작업을 수행하는 Mythos급 AI 모델로, 사용자의 역할은 '직접 작업하는 마법사'에서 '결과를 의뢰하고 판정하는 후원자(patron)'로 바뀌고 있다는 걸 보여줘요. 하지만 토큰 비용, 가드레일 제한, 블랙박스화되는 의사결정 과정 같은 한계도 명확해요.
원문 핵심 내용
1. Claude 5 Fable이 무엇인가
Claude 5 Fable은 Anthropic이 공개한 첫 'Mythos급' AI 모델이에요. Mythos급 모델이라는 건 단순히 더 똑똑한 모델이 아니라, 다단계 사양서를 받아 스스로 최대 십수 시간 동안 작업을 수행할 수 있는 차원의 차이를 의미해요. 단일 프롬프트와 한 차례 피드백만으로 정교한 사회과학 논문, 모든 단어가 's'로 시작하는 10페이지 운율시까지 생성했어요.
2. 등시선 지도 제작 사례 — 실제 작업의 깊이
저자가 Fable에게 요청한 작업 중 하나는 등시선 지도(isochrone map) 제작이에요. 등시선 지도는 '주어진 시간 안에 이동 가능한 거리'를 보여주는 지도로, 첫 사례는 1881년에 런던 출발 이동 시간을 보여주기 위해 만들어졌어요. 이전 모델들은 이런 지도를 절반이라도 유용하게 만들지 못했어요. 수천 개의 잠재 이동 거리 조사와 많은 작은 판단이 필요했기 때문이에요.
Fable은 이 작업을 이렇게 수행했어요:
- 도시 선택과 공항·기차·도보·운전을 반영한 실제 데이터 기반의 고유 디자인 지도를 제작
- 1881년 원본 스타일로 제작할 것을 제안하고, 동의 후 작업 시작
- 여러 시간에 걸친 빌드 세션에서 다수의 다른 AI(주로 저렴한 Claude Sonnet)를 직접 실행
- TGV부터 Shinkansen까지의 철도 시간표, 여러 학술 논문 기반 국가별 도로 속도, 2,200건 이상의 구체적 항공편 데이터 확보
- 조사 에이전트가 도는 동안 코딩을 시작하고, 코드 검증을 위한 추가 에이전트와 테스트를 실행
- Greenland 같은 원격지가 정확한 수치 대신 추정치만 담고 있어 실제 이동 시간을 확보하도록 수정 지시
- 이번에는 연구하고 서로 결과를 검증하는 적대적 에이전트 그룹(adversarial groups) 워크플로 실행
- Pacific의 Pitcairn Island로 배가 운항하는 빈도, Ottawa에서 Grise Fjord까지 가는 경로 산출
사용자가 한 일은 야심 찬 지시와 약간의 피드백뿐이었어요. 모델이 수백 개의 작은 판단을 직접 내렸고, 그 선택을 이해하거나 개입할 기회는 없었어요.
3. Concord — 인간·AI 응답 보정 소프트웨어
가장 야심 찬 프로젝트는 Concord라는 소프트웨어였어요. 인간이 만들어내는 지저분한 답변을 적절히 분류하는 연구 과업이에요. 아이디어가 얼마나 혁신적인지, 사람들이 왜 특정 책을 좋아하는지 등을 판단하는 거죠. 기존에는 인간 연구자가 판단을 내리고 다른 답변과 통계적으로 비교해 데이터 신뢰도를 확인했어요.
Fable에게 19페이지 복잡한 설계 문서를 주고, Fable은 이를 가지고 9시간 30분 동안 작업했어요. 결과물은 다중 데이터셋을 입력받아 인간·AI 응답을 보정하고 복잡한 데이터 분석을 수행하는 소프트웨어였어요. 완벽하진 않았고 전문가 입장에서 일부 오류와 누락을 발견해 수정 지시를 전달했지만, 전달 범위는 이전에 본 어떤 것도 넘어섰어요.
4. 한계와 제약
토큰 비용: Fable은 Opus 대비 2배 비싸고, 프로덕션 비용은 "상당히 많은(a lot)" 수준으로 토큰을 빠르게 소진해요. 다만 저렴한 모델로의 영리한 위임이 실제 비용을 상당히 낮출 가능성이 있어요.
가드레일: 보안 문제의 아주 미세한 기미에도 가드레일이 작동해 성능이 낮은 Claude 4.8 Opus로 전환되며, 이런 일이 지나치게 자주 발생해요. Mythos 논의는 주로 소프트웨어 보안 영향에 집중되었으나, Fable의 가드레일은 사이버보안 용도 사용을 사실상 차단해요.
들쭉날쭉한 프런티어(jagged frontier): 산출물과 진행 보고서에 특유의 "Claudism" 식 문체가 남아 있어요.
5. 마법사에서 후원자로 — 인간 역할의 변화
작년에는 이 경험을 '주문을 외우면 무언가 일어나는' 마법사(wizard)에 비유했어요. Fable에서는 주문이 충분히 강력해져 사용자 스스로가 마법사라기보다 후원자(patron)에 가까워졌어요. 원하는 것을 묘사하고, 비용을 지불하고, 결과를 판정 — 실제 작업(conjuring)은 볼 수 없는 곳에서 수백 개의 작은 선택을 통해 진행돼요.
작업이 과정에서 결과로 이동하고, 더 이상 조종(steer)하지 않고 의뢰(commission)하게 돼요. 저자는 두 가지 가능성을 제시해요:
- 인터페이스가 따라잡지 못한 일시적 현상일 수 있으며, 모델 동작을 들여다보고 중간에 조종하는 더 나은 방법이 나올 가능성
- 반대로 모델이 유능할수록 인간이 의미 있게 할 일이 줄고 블랙박스가 그 능력의 대가일 가능성
후자가 더 크다고 봐요. 명백한 의미의 통제 상실은 아니며, 여전히 조종 가능하고 지시를 매우 잘 따르지만, 지시가 야심 찰수록 결과가 더 좋아져요. 그러나 조종은 더 이상 직접 수행과 같지 않으며, 모델이 자체 에이전트를 띄워 조사·작성·상호 검증을 끝내 완성본을 돌려줘요. 후원자가 한 명의 예술가에게 의뢰하는 것이 아니라, Fable은 작업 현장에 발도 들이지 않은 채 최종 결과만 승인하는 스튜디오 전체에 가까운 형태예요.
Hacker News 커뮤니티 반응
코드 품질과 검증에 대한 회의적 시각
가장 많이 언급된 주제는 "생성된 코드의 품질과 매체에 대한 실질적인 내용이 거의 없다"는 점이에요. HN 사용자들은 코드에 문서와 테스트가 있는지, 이해·확장이 가능한지, 안전한지, 어떤 언어·프레임워크·데이터베이스를 썼는지 궁금해했어요. 저자가 판단력과 취향을 말했는데, 실제 코드도 취향 있게 작성됐는지 모르겠다는 지적이었어요. 새 기능을 추가해 달라고 하면 모델이 전체 구조를 다시 짜면서 또 9.5시간어치 토큰을 쓰게 될지도 의문이라고 했어요.
한 사용자는 "이런 질문은 AI에만 해당하지 않음. 사람 에이전시에 돈을 주고 '작동한다'는 결과물을 받았다면 똑같이 물어볼 것임. 평가할 줄 모르면 평가할 사람을 고용했을 것임. LLM에서 가장 걸리는 부분은 검증"이라고 요약했어요.
저자의 배경에 대한 비판
"이런 글은 소프트웨어 엔지니어가 쓰는 경우가 거의 없고, 대개 기술 임원, 은퇴한 엔지니어, VC가 씀"이라는 지적이었어요. 저자는 Wharton School of Management 교수로, 실제 제품을 출시하거나 유지보수할 필요가 없고, 그냥 사이드 프로젝트를 만드는 것에 가깝다는 평가였어요. 제대로 된 소프트웨어 엔지니어링 관점은 Mitchell Hashimoto에게서 본 것이 거의 유일했다고 했어요.
LLM 코딩의 새로운 전략 — '모든 프로젝트를 낮은 위험도로 만드는 법'
흥미로운 통찰이 나왔어요. "LLM은 위험도가 낮은 프로젝트를 만드는 데 정말 강하다는 걸 깨닫기 시작함. 소프트웨어에 LLM을 잘 쓰는 요령은 모든 프로젝트를 낮은 위험도로 만드는 법을 배우는 것 같음. 지난 2년가량의 모든 LLM 논의가 이런 식이었음."
계속해서 "모델이 좋아질수록 코드가 어떻게 생겼는지는 정말 중요하지 않을 수도 있다는 생각을 하게 됨. 소프트웨어의 관찰 가능한 동작이 좋다면 그 소프트웨어는 좋은 것임. 어떤 종류의 버그든 모델이 바이브 코딩된 코드베이스에서 고칠 수 있다면 고칠 수 있는 버그임. 악용 가능한 취약점이 없다면 안전한 코드이고, 성능이 충분하면 성능 좋은 코드임."
"소프트웨어 엔지니어가 버그를 다듬을 것이다" — 위험한 가정
"하지만 소프트웨어 엔지니어가 내가 빠르게 찾지 못한 남은 잠재적 버그를 다듬을 것이다"라는 짧은 문장이 무서웠다고 했어요. 모든 소프트웨어 개발자는 이게 매우 위험하고 비현실적인 가정이라는 걸 알아. 이건 사실상 모든 진짜 작업을 손쉽게 넘겨 버리는 작은 문장이라고 지적했어요.
실제 사용 경험 — 극명한 양극화
Fable의 실제 사용 경험은 프로젝트마다 극명하게 갈렸어요:
긍정적 입장: "내 프로젝트에서는 4.8이 놓친 것들을 Fable이 즉시 명확히 봤음. 매우 인상적이고 같이 일하기 좋았음." "Fable은 모든 걸 예상하고 묻지 않아도 다 해 주는 것처럼 보였음."
부정적 입장: "오늘 Fable로 개인 프로젝트를 해 봤는데 꽤 탄탄해 보이지만 4.8과 아주 멀리 떨어져 있지는 않음. 같은 환각, 같은 유형의 버그, 큰 프로젝트에서 요청한 것만 하고 그게 건드리거나 깨뜨리거나 영향을 줄 수 있는 부분은 무시하는 경향도 같음. 계속 쓰긴 하겠지만 지금 보기에는 점진적 개선이지, 'OMG OMG OMG Mythos가 왔다!' 수준은 아님."
두 입장 모두 공통적으로 언급한 점: Fable은 분명히 Opus 4.8보다 나아졌지만, 무한 루프에 빠지거나 맥락이 커지면 테스트를 포기하는 등 근본적인 문제는 아직 남아있어요.
데이터 검증 문제 — "믿어 버리는 함정"
"저자는 모든 데이터가 실제이고 검증돼야 한다고 프롬프트를 넣은 뒤, 그냥 그렇다고 믿어 버렸음. 데이터 기반 프로젝트에서조차 그랬음. 사람들은 무수히 많은 일, 심지어 중요한 일에서도 똑같이 할 것임."
이 지적은 AI 모델이输出的한 데이터를 사용자가 검증 없이 믿는 문제를 보여줘요. AI가 "이건 검증된 데이터예요"라고 말하면, 사용자는 실제로 검증하지 않고 믿어버리는 경향이 있다는 거예요.
비용 문제 — "6월 22일까지 최대한 뽑아먹어야 할 듯"
"Max 5x 구독 중인데, Fable이 40분짜리 코드 리뷰 세션에서 주간 한도의 16%를 써 버렸음. 리뷰를 끝내지도 못했고, 정작 Fable이 필요했던 중요한 메모리 안전성 부분에서는 Opus 4.8로 되돌아갔음. 곧 이런 모델들을 가격 때문에 못 쓰게 될 것 같은 느낌임."
작업 시간에 대한 재고
"내 고객들은 현재 에이전트 응답 시간을 85초에서 20초 아래로 낮추라고 요구하고 있음. 동시에 업계가 에이전트를 통한 한 시간 이상짜리 작업 흐름으로 향하는 걸 보면 매우 부조화하게 느껴짐."
또 다른 관점: "19쪽짜리 설계 문서에서 Concord 같은 걸 9.5 근무시간 안에 만들 수 있는 단일 개발자는 모름. 예전처럼 상사가 왜 앉아만 있냐고 묻는 시절로 돌아갈 것임. 다만 '컴파일 중입니다' 대신 'Claude 기다리는 중입니다'라고 말하게 될 뿐임."
시 프롬프트의 문학적 기원
Fable에게 "모든 단어가 s로 시작하는 이발에 관한 시"를 작성하게 한 프롬프트가 무엇인지 궁금해하던 HN 사용자 중 한 명이, 이 아이디어가 폴란드 작가 Stanislaw Lem의 SF 우화집 "The Cyberiad"에서 나왔다고 지적했어요. 한 이야기에서 로봇 제작자 Trurl이 시 쓰는 기계를 만들고, 경쟁자 Klapaucian이 그 기계에게 "이발에 관한 시! 여섯 줄, 모든 단어가 s로 시작해야 한다!"고 요구한 장면이 원형이에요.
새로운 시각
1. '검증의 위임' 문제 — AI 시대의 새로운 신뢰 위기
이 글에서 가장 중요한 통찰은 '검증'이에요. 저자가 Fable이 생성한 데이터를 프롬프트에서 "검증된 데이터여야 한다"고 지시했지만, 실제로는 검증하지 않고 믿어 버렸어요. 이는 AI 시대의 새로운 신뢰 위기를 보여줘요. 과거에는 인간이 만든 결과물을 검증하는 게 중요했다면, 이제는 AI가 '검증했다'고 주장하는 것을 어떻게 검증할지가 핵심 문제가 돼요. AI가 스스로 검증을 수행한다고 해도, 그 검증 과정 자체가 블랙박스라면 우리는 결국 AI의 주장을 맹신하는 상황이 돼요.
2. '낮은 위험도 프로젝트' 전략 — LLM 시대의 소프트웨어 공학 패러다임 전환
HN 댓글에서 나온 "모든 프로젝트를 낮은 위험도로 만드는 법"이라는 통찰은 매우 중요해요. 전통적인 소프트웨어 엔지니어링은 높은 신뢰도를 요구하는 프로젝트(의료, 항공, 금융 등)를 중심으로 발전했어요. 하지만 LLM 시대에는 오히려 프로젝트를 낮은 위험도로 설계하는 것이 더 효율적이에요. 왜냐하면 LLM이 만든 코드를 검증하고 유지보수하는 비용이 프로젝트의 위험도에 비례하기 때문이에요. 낮은 위험도 프로젝트라면 LLM이 만든 코드를 그대로 사용하고, 문제가 생기면 LLM에게 고치게 하면 돼요. 이는 소프트웨어 공학의 근본적인 패러다임 전환을 의미해요.
3. '후원자' 메타포의 역사적 맥락
후원자(patron) 메타포는 르네상스 시대를 연상시켜요. 메디치 가문이 예술가들을 후원했듯, 미래의 지식 노동자는 AI 스튜디오에 아이디어를 의뢰하고 결과를 승인하는 역할로 축소될 수 있어요. 하지만 르네상스 후원자들도 단순한 의뢰인이 아니라, 예술적 비전을 가지고 방향을 제시했어요. AI 시대의 '후원자'도 단순히 지시만 하는 게 아니라, 무엇을 의뢰할지, 어떤 결과가 진정한 가치인지 판단하는 안목이 더 중요해질 거예요.
4. 응답 시간 vs 작업 시간의 부조화
고객들은 에이전트 응답 시간을 85초에서 20초 아래로 낮추라고 요구하는 반면, 업계는 한 시간 이상짜리 작업 흐름으로 향하고 있어요. 이는 AI 개발의 방향성과 실제 사용자의 니즈가 괴리되어 있음을 보여줘요. 대부분의 업무는 빠른 피드백 루프가 중요한데, Mythos급 모델이 제공하는 건 긴 작업 시간 끝에 나오는 완성본이에요. 두 가지 모두 가치 있지만, 어떤 상황에 어떤 접근이 적합한지 명확히 구분하는 기준이 필요해요.
자녀와 미래에 대한 시사점
아인, 석현, 은한이 자라나는 세상에서 이 글이 주는 시사점은 명확해요:
- 검증 능력의 중요성: AI가 만들어낸 결과물을 맹신하지 않고, 어떻게 검증할지 아는 능력이 핵심 경쟁력이 될 거예요. 아인이 사회과학을 공부한다면 데이터 검증 방법론을, 석현·은한이 공학을 공부한다면 시스템 검증 프레임워크를 배우는 게 중요해요.
- '후원자'로서의 사고력: 직접 모든 것을 수행하는 능력보다, 무엇을 의뢰할지, 어떤 결과가 가치 있는지 판단하는 안목이 더 중요해질 거예요. 이는 단순한 기술력이 아니라 비판적 사고와 도메인 전문성의 조합이에요.
- 낮은 위험도 프로젝트 설계 능력: LLM을 효과적으로 활용하려면 프로젝트를 낮은 위험도로 설계하는 능력이 필요해요. 이는 공학적 사고의 새로운 형태예요.
- 비용 인식: AI 모델 사용이 막대한 토큰 비용을 발생시킨다는 사실을 이해해야 해요. 효율적인 AI 활용은 단순히 '무엇을 할 수 있는가'가 아니라 '얼마나 효율적으로 할 수 있는가'도 포함해요.