본문으로 건너뛰기

© 2026 Molayo

GeekNews헤드라인2026. 06. 11. 06:21

Mythos와 함께 일한다는 느낌

요약

본 글은 LLM 기반 개발의 핵심 과제가 '검증(Verification)'에 있음을 강조합니다. 모델이 생성한 코드 자체의 품질보다는, 소프트웨어가 의도대로 동작하는지 확인하고 유지보수할 수 있는 능력이 중요하다고 주장합니다. 궁극적으로는 모든 프로젝트를 낮은 위험도로 설계하여 LLM 활용도를 높이는 것이 핵심 요령입니다.

핵심 포인트

  • LLM 개발에서 가장 중요한 것은 코드의 품질보다 '검증' 능력이다.
  • 소프트웨어 엔지니어링은 이제 코드가 의도대로 동작하는지 확인하는 과정이 되었다.
  • LLM을 잘 쓰는 방법은 프로젝트를 낮은 위험도로 설계하는 것이다.
  • 모델 성능 향상에 따라, 코드 모양 자체는 중요하지 않게 될 수 있다.

이 글에서 생성된 코드의 품질과 매체에 대한 실질적인 내용이 거의 없다는 점이 흥미로움
코드에 문서와 테스트가 있는지, 이해·확장이 가능한지, 안전한지, 어떤 언어·프레임워크·데이터베이스를 썼는지 궁금함. 저자가 판단력과 취향을 말했는데, 실제 코드도 취향 있게 작성됐는지 모르겠음. 새 기능을 추가해 달라고 하면 모델이 전체 구조를 다시 짜면서 또 9.5시간어치 토큰을 쓰게 될지도 의문임. 연구 부분은 도메인 지식, 즉 여행 유형별로 시간을 어떻게 환산해 보기 좋게 만들었는지일 텐데, 저자가 이를 어떻게 검증했는지도 궁금함
이런 질문은 AI에만 해당하지 않음. 사람 에이전시에 돈을 주고 “작동한다”는 결과물을 받았다면 똑같이 물어볼 것임. 평가할 줄 모르면 평가할 사람을 고용했을 것임. LLM에서 가장 걸리는 부분은 검증임

이런 글은 소프트웨어 엔지니어가 쓰는 경우가 거의 없고, 대개 기술 임원, 은퇴한 엔지니어, VC가 씀
이 저자는 Wharton School of Management 교수인 듯함. 이런 사람들은 실제 제품을 출시하거나 유지보수할 필요가 없고, 그냥 사이드 프로젝트를 만드는 것에 가까움
제대로 된 소프트웨어 엔지니어링 관점은 Mitchell Hashimoto에게서 본 것이 거의 유일했음

LLM은 위험도가 낮은 프로젝트를 만드는 데 정말 강하다는 걸 깨닫기 시작함
위 질문들은 대체로 더 높은 위험도를 전제로 함. 소프트웨어가 오래 유지되고, 요구사항이 진화하며, 실수를 용납할 수 없다는 식임
소프트웨어에 LLM을 잘 쓰는 요령은 모든 프로젝트를 낮은 위험도로 만드는 법을 배우는 것 같음

지난 2년가량의 모든 LLM 논의가 이런 식이었음
실질적인 내용을 요구하면 “사람도 이걸 잘 못하잖아!”라는 말이 쏟아짐. 정량적 근거는 매우 적고, 순수한 수사만 많음

모델이 좋아질수록 코드가 어떻게 생겼는지는 정말 중요하지 않을 수도 있다는 생각을 하게 됨
소프트웨어의 관찰 가능한 동작이 좋다면 그 소프트웨어는 좋은 것임. 어떤 종류의 버그든 모델이 바이브 코딩된 코드베이스에서 고칠 수 있다면 고칠 수 있는 버그임. 악용 가능한 취약점이 없다면 안전한 코드이고, 성능이 충분하면 성능 좋은 코드임
바깥에서 해야 할 일을 하고, 안쪽에서 문제가 발견됐을 때 모델이 고칠 수 있다면 코드 모양은 중요하지 않음. 소프트웨어 엔지니어링은 그 어느 때보다 코드가 의도대로 동작하는지 확인하는 일이 됐음
설령 코드 모양이 중요하더라도, 그것도 모델에게 고치게 할 수 있음

예시 중 하나인 “뱀이 자의식을 갖고 이상한 일이 벌어지는 스네이크 게임”을 눌러 봤는데, 1~2분 해 보니 그냥 1980년대식 스네이크 게임이었음
뭘 놓친 건지 모르겠음. “자의식”이라는 게 화면 아래쪽의 웃긴 메시지 몇 개를 말하는 건가? “이상한 일”은 무엇인지도 모르겠음

Fable에 내가 손으로 검증하던 모델들을 넣어 봤음
대략 Opus에게 시나리오를 모델링하게 하고, 수학을 보여 달라고 한 뒤, 고치고 반복하고, 마지막으로 코드가 모델 논리와 맞는지 다시 확인하는 방식임. Fable은 내가 찾은 오류를 거의 다 찾아냈고, 추가 변수에 대한 흥미로운 제안도 했음
다만 사용량 한도를 90년대 말 Hummer처럼 태워 버렸음

Max 5x 구독 중인데, Fable이 40분짜리 코드 리뷰 세션에서 주간 한도의 16% 를 써 버렸음
리뷰를 끝내지도 못했고, 정작 Fable이 필요했던 중요한 메모리 안전성 부분에서는 Opus 4.8로 되돌아갔음
곧 이런 모델들을 가격 때문에 못 쓰게 될 것 같은 느낌임. 6월 22일까지 Fable을 최대한 뽑아먹어야 할 듯함

가장 중요한 질문은 이것임: 여기서 투자 대비 수익은 얼마나 나오나?

오늘 Fable로 개인 프로젝트를 해 봤는데 꽤 탄탄해 보이지만 4.8과 아주 멀리 떨어져 있지는 않음
같은 환각, 같은 유형의 버그, 큰 프로젝트에서 요청한 것만 하고 그게 건드리거나 깨뜨리거나 영향을 줄 수 있는 부분은 무시하는 경향도 같음. 처음에는 테스트를 돌리지만 맥락이 커지면 “나중에 돌리겠다”고 하고, 욕을 섞어 지시하지 않는 한 결국 끝까지 안 돌림
계속 쓰긴 하겠지만 지금 보기에는 점진적 개선이지, “OMG OMG OMG Mythos가 왔다!” 수준은 아님

내 경험은 반대임. Fable은 모든 걸 예상하고 묻지 않아도 다 해 주는 것처럼 보였음
매우 인상적이고 같이 일하기 좋았음
이상한 현상은 아닌 게, 처음 구독했을 때 Opus도 딱 이랬음. Anthropic이 용량 부족 때문에 Opus를 약화시켰다는 밈이 널리 퍼져 있는데 사실인지는 모름. 다만 Fable도 같은 운명을 맞을지 궁금함

내 프로젝트에서는 4.8이 놓친 것들을 Fable이 즉시 명확히 봤음
하지만 그 문제들을 계단식으로 넘어가며 크게 감탄하게 만든 뒤 얼마 지나지 않아, 평소처럼 뭔가를 하기보다 말만 계속하는 무한 루프에 빠졌고, 가끔 멈춰서 내가 다시 재촉해야 했음
그래서 AGI는 아님. 그래도 확실한 개선은 맞음

글의 이 짧은 문장이 무서움: “하지만 소프트웨어 엔지니어가 내가 빠르게 찾지 못한 남은 잠재적 버그를 다듬을 것이다”
모든 소프트웨어 개발자는 이게 매우 위험하고 비현실적인 가정이라는 걸 앎

이건 사실상 모든 진짜 작업을 손쉽게 넘겨 버리는 작은 문장임

저자가 “AI가 만든 가장 정교한 학술 사회과학 논문”이라고 부른 글의 첫 몇 단락을 읽어 봤는데 기대만큼 인상적이지 않았음
“시장 수요에 대한 사후 믿음은 순전히 기준점 의존적이다. 모금액을 일정하게 유지하면, 창업자가 스스로 정한 목표 대비 성과만 추적한다. 임계값에서 표준편차 절반만큼 뛰고, 그 이후 첫 10점에는 가파르게 반응하며, 이후 평평해진다” 같은 식임
사람은 보통 데이터를 이런 식으로 말로 풀지 않음. 요약 문서도 꽤 내용이 부풀려진 느낌임

문제가 가장 완벽하게 드러나는 지점임
저자는 모든 데이터가 실제이고 검증돼야 한다고 프롬프트를 넣은 뒤, 그냥 그렇다고 믿어 버렸음. 데이터 기반 프로젝트에서조차 그랬음. 사람들은 무수히 많은 일, 심지어 중요한 일에서도 똑같이 할 것임

살면서 더 일찍 알았으면 좋았을 텐데, 아무도 확인하지 않을 거라면 훨씬 더 많이 그럴듯하게 꾸며낼 수 있었음

“9시간 반 동안 작업했다”는 대목과 “완벽하진 않았다. 전문가로서 몇 가지 오류와 누락을 발견했고 AI에게 고치게 했다”는 부분이 눈에 띄었음
하루에 한 문제에 그렇게 오래 쓸 거라고 기대하지도 않고, 핵심 보상 루프가 몇 시간짜리인 결과물을 다시 고치는 데 그렇게 오래 쓰리라고도 기대하지 않음
내 고객들은 현재 에이전트 응답 시간을 85초에서 20초 아래로 낮추라고 요구하고 있음
동시에 업계가 에이전트를 통한 한 시간 이상짜리 작업 흐름으로 향하는 걸 보면 매우 부조화하게 느껴짐

Claude를 변호하자면, 믿기지 않지만 변호하게 되는데, 19쪽짜리 설계 문서에서 Concord 같은 걸 9.5 근무시간 안에 만들 수 있는 단일 개발자는 모름
예전처럼 상사가 왜 앉아만 있냐고 묻는 시절로 돌아갈 것임. 다만 “컴파일 중입니다” 대신 “Claude 기다리는 중입니다”라고 말하게 될 뿐임

이 시점에서는 돈을 훨씬 더 주면 내가 하겠음

내 Opus 4.8은 사소하지 않은 단일 코딩 요청에도 정기적으로 10분 이상 작업함

작업 시간은 그다지 가치 있는 측정치가 아님
보통은 과정을 직접 코드로 정의하고, 그 코드가 작업 덩어리를 모델들에게 위임하게 하는 편이 낫음. 유일한 실제 문제는 제공업체의 구독 할인을 활용하기 어려워진다는 점임
반대로 직접 모델 라우팅을 하기는 쉬워짐. 일반 챗봇이 며칠·몇 주 단위의 작업 흐름에서 일관성을 유지하는 방법은 아직 보지 못했음

QWEN 모델들이 나왔을 때 이미 시그모이드 구간에 들어갔다고 봄
프로젝트를 제대로 구조화하면 원하는 확장 지점을 가리키고 30분 정도 돌려 기능을 확장하게 할 수 있음. 전체 코드를 대상으로 ‘신 모드’를 효과적으로 수행하진 못하지만, 신중한 관찰자이자 코드 전문가로서 128GB VRAM 이상이 꼭 필요하진 않음
최신 모델 비대화가 이렇게 멀리 온 게 놀라운데, 중국이 이런 모델용 실리콘을 찍기 시작하면 끝낼 것 같음

시 프롬프트가 무엇이었는지 몹시 궁금함
아이디어가 익숙해서 파고들다 보니 14년 전 reddit의 시를 찾았음: [https://www.reddit.com/r/RedditDayOf/comments/tjjw2/may_12_a...]
저자가 공유한 것만큼 길지는 않지만 같은 아이디어임
이건 폴란드 작가 Stanislaw Lem의 SF 우화집 “The Cyberiad”에서 나온 것임. 한 이야기에서 로봇 제작자 Trurl이 시 쓰는 기계를 만들고, 질투심 많은 경쟁자 Klapaucian이 그 기계에게 “이발에 관한 시! 하지만 숭고하고, 고귀하고, 비극적이고, 영원하며, 사랑과 배신, 응징, 조용한 영웅주의, 확실한 파멸 앞에서의 시! 여섯 줄, 영리하게 운율을 맞추고, 모든 단어가 s로 시작해야 한다!”고 요구함
컴퓨터는 이렇게 답함:
“Seduced, shaggy Samson snored.
She scissored short. Sorely shorn,
Soon shackled slave, Samson sighed.
Silently scheming,
Sightlessly seeking
Some savage, spectacular suicide”
저자는 Fable/Mythos에 도전 과제를 던질 때 이 장면을 참조했을 수밖에 없어 보임. 정확한 프롬프트가 궁금함

흥미로운 점은 이게 영어 번역의 난도라는 것임
영어 번역은 폴란드어 원문과 다른 시작 글자와 다른 단어를 씀:
Cyprian cyberotoman, cynik, ceniąc czule
Czarnej córy cesarskiej cud ciemnego ciała,
Ciągle cytrą czarował. Czerwieniała cała,
Cicha, co-dzień czekała, cierpiała, czuwała...
... Cyprian ciotkę całuje, cisnąwszy czarnulę!!
번역가의 일을 LLM과 비교해 볼 수 있음. 둘 다 파생 작업이고, 제약 속에서 일하지만 창의성을 발휘할 여지가 있음

저자가 그 장면을 참조한 게 아니라, Anthropic이 reddit 댓글 라이선스를 받았으니 학습 데이터에서 빨아들였을 수도 있음

한 시간도 안 써 봤으니 새 기술에 흥분한 상태라는 점을 감안해야 함
내 프로젝트(https://github.com/tsz-org/tsz) 같은 경우, 모델들이 충분히 조사하지 않고 다른 상황을 고려하지 않는 데 계속 좌절했음. 모델은 한 가지를 고치는 코드를 만들고, “관련 없어 보이는” 테스트 두 개를 깨뜨리는 일을 반복했음
Fable은 작업이 훨씬 오래 걸리는 것 같고 아직 Fable 세션에서 풀 리퀘스트를 본 적은 없지만, 세션 기록을 읽어 보면 돌 하나도 빠뜨리지 않으려는 방식으로 옳은 일을 하고 있는 게 보임
글에서도 말하듯 이런 모델의 “느낌”은 프로젝트마다 너무 달라 전달하기 어렵지만 공유해 봄

그건 프로젝트가 기능을 점진적으로 추가하기 쉬운 구조가 아닐 수도 있다는 신호 아닌가?

다들 Mythos와 Opus 사이에서 그렇게 큰 차이를 느낄 만큼 뭘 작업하고 있는지 궁금함
나도 꽤 고급 작업을 한다고 생각하는데, Deepseek만으로도 충분할 때가 더 많음. 여기 있는 사람들은 왜 다 천재인 건가?

무엇을 작업하느냐에 달렸음
Hades나 Baazar 같은 괜찮은 인디 게임 수준의 비디오 게임을 만들고, 유기적·상호작용적·애니메이션 느낌의 UI 요소, 시각 효과, 복잡한 셰이더 등을 만들려 하면 어떤 모델도 쉽게 끝낼 만큼은 전혀 충분하지 않음. 상위 3% 게임에서 나오는 문제의 상당수는 단순 프롬프트로는 어떤 모델에도 정말 어려움
개인적으로는 직접 코딩하고 배우는 걸 좋아해서 별로 신경 쓰지 않고, DeepSeek Flash 정도면 충분함. 그래도 최고 모델들이 전혀 가까이 가지 못하는 벤치마크를 많이 만들기는 아주 쉽고, 그런 문제로 모델이 얼마나 좋아지는지 테스트하는 걸 좋아함
참고로 Fable 5는 4.8보다 확실히 조금 더 나음

새 노트북이 발표되면 직원들이 갑자기 모두 업그레이드가 필요하다고 하는 것과 비슷함
실제로는 90%가 Macbook Neo로도 충분히 버틸 수 있을 텐데도 그럼

최근 Rust로 흔한 웹 인프라 유형의 프로젝트를 구현하고 있음
rustls, Tokio 같은 Rust의 좋은 기본 요소를 많이 써서 메모리 안전하거나 그에 가까운 nginx 대체품을 만들려는 시도임
이 작업의 일부로 고품질 Lua in Rust 저장소도 만들고 있음. gpt 5.5와 Opus 4.8이 막혔던 내 Lua 인터프리터의 성능 문제를 Mythos로 고치고 있음
Mythos가 이걸 풀 수 있을지는 모르겠지만, 몇 시간째 실행 중이고 꽤 유망한 결과가 있음
궁금하면 성능 차트는 여기 있음: https://github.com/ianm199/lua-rs

직접 프로그래밍 언어를 만들고 있음
기여할 만한 오픈소스 프로젝트도 둘러보고 있음. 취미 개발자에서 전문가로 전환하는 데 도움이 될 만한 무언가를 찾는 중인데, 요즘 시대에 그런 게 가능한지도 모르겠음
Fable 5는 코드 리뷰에서 Opus 4.8이 놓친 문제를 꽤 많이 찾았음. 멍청한 사이버보안 관련 제한 때문에 모델이 낮아졌는데도 그랬음. 더 말하긴 어려운 게 Max 5x에서 5시간 창마다 세션 하나만 받을 수 있음. 지금까지 세션 두 번만 돌렸음

요구 수준을 계속 올리면 어떤 모델이든 한계까지 몰아붙이는 건 어렵지 않을 것임
극단적으로 프롬프트가 “기능이 완전하고 완성도 높은 Facebook 클론을 만들어라”라고 해 보자. Facebook은 복잡하지만 기술적으로 아주 난해하진 않을 가능성이 큼. 그래도 상당한 토큰을 태우고 나면, 그 프롬프트에 대한 여러 모델의 결과물에서 여러 측면의 상당한 차이를 보게 될 것임
물론 위 요청은 실제로 유용하진 않음. 하지만 한계에 가까워질 때까지 더 큰 덩어리를 맡기지 못할 이유가 뭐가 있나? 어느 시점에는 경계에 닿고, 차이가 분명해질 것임

AI 자동 생성 콘텐츠

본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0