저는 방금 샌프란시스코에서 열린 AI Engineer World's Fair에서 3일을 보냈습니다. 7,000명의 엔지니어, 수십 개의 트랙, 그리고 여러분이 떠올릴 수 있는 모든 주요 브랜드 스폰서들이 있었습니다. 그 에너지는 엄청났습니다 — 마치 누군가 2021년의 암호화폐 컨퍼런스 하이프(hype)를 실제 작동하는 소프트웨어에 주입한 것 같았습니다.

그리고 솔직히 말하자면? 저는 복잡한 감정을 안고 집으로 돌아왔습니다.

한편으로는, 진전이 실재합니다. 에이전트(Agents)는 더 이상 데모용 소프트웨어가 아닙니다. Uber와 같은 기업들은 에이전트가 자율적으로 PR(Pull Request)을 검토하고, 테스트 스위트(test suites)를 실행하며, 엣지 케이스(edge cases)를 포착하고, 사람이 브랜치를 확인하기도 전에 수정 사항을 다시 커밋하는 내부 시스템인 uReview를 선보였습니다. 그것은 프로토타입이 아닙니다 — 실제 코드를 처리하는 프로덕션(production) 단계입니다.

다른 한편으로는, 컨퍼런스 현장은 어려운 질문들을 회피하는 데 있어 마스터클래스 수준이었습니다.

저는 복도와 브레이크아웃 세션(breakout sessions)에서 대부분의 시간을 보내며 단순한 질문을 던졌습니다: "실제로 무엇이 여전히 고장 나 있는가?" Anthropic, Google DeepMind, Vercel, 그리고 아직 들어보지 못한 수십 개의 스타트업 엔지니어들과 약 20번의 대화를 나눈 결과, 세 가지 패턴이 계속해서 나타났습니다. 그 누구도 이 중 어느 것에 대해서도 좋은 답변을 내놓지 못했습니다.

제가 배운 내용은 다음과 같습니다.

1. 프런티어 함정(The Frontier Trap) — 모두가 돈을 태우고 있으며 괜찮은 척하고 있다

📸 📸 Unsplash

박람회에서 가장 많이 논의된 토론은 에이전트나 샌드박스(sandboxes), 또는 오픈 모델(open models)에 관한 것이 아니었습니다. 그것은 바로 **루프(loops)**에 관한 것이었습니다 — 우리가 마침내 코딩 루프(coding loop)에서 인간을 제외하고 AI가 자율적으로 실행되도록 할 수 있는지에 대한 문제였습니다.

Latent Patterns의 Geoff Huntley는 이를 초기 Kubernetes 시절에 비유하며 그렇다고 주장했습니다. 처음에는 엉망이겠지만, 우리가 방법을 찾아내면 혁명적일 것이라는 논리였습니다. HumanLayer의 Dex Horthy는 인간을 제외했을 때 재앙으로 이어졌던 자신의 실험 데이터를 보여주며 아니라고 주장했습니다. 청중 투표는 막상막하였으나 "아직은 아니다" 쪽으로 기울었습니다.

하지만 그 토론에서 아무도 인정하지 않은 사실이 있습니다. 진정한 병목 현상(bottleneck)은 인간이 아닙니다. 바로 모델 선택(model choice)입니다.

제 워크숍 이후 제가 찾아낸 또 다른 참석자인 Ryan Swift는 직설적으로 말했습니다. "대부분의 엔지니어들은 일상적인 업무를 위해 최신이자 가장 강력한 프론티어 모델(frontier model) 이외의 다른 모델을 고려하기를 단순히 거부합니다. 저는 프론티어 모델이 항상 필요한 것은 아니라는 점을 사람들에게 설득하는 데 과도한 시간을 소비하고 있습니다."

그의 말이 맞습니다. 저는 어디에서나 그런 모습을 보았습니다.

날씨를 확인하기 위해 Claude Opus 4를 실행하는 팀들. 미세 조정(fine-tuned)된 8B 모델로 처리할 수 있는 작업에 GPT-5를 사용하며 하루에 2,000달러를 낭비하는 기업들. "어떤 모델을 쓸 것인가?"라는 질문에 대한 기본 답변은 언제나 "가장 큰 것"이었습니다.

Ryan이 세션에서 공유한 실제 데이터가 보여주는 내용은 다음과 같습니다:

• Sonnet 4.6은 코딩 작업의 90%에서 Opus 4.1과 대등한 성능을 보임
• Gemini Flash 3.5는 Gemini Pro 3.1과 경쟁 가능함
• GPT-5.4 Mini는 모든 일반적인 벤치마크(benchmark)에서 GPT-5.1과 일치함
• 빠른 모델들은 비용이 515배 저렴하며 속도는 38배 더 빠름

수치는 명확합니다. 하지만 엔지니어들은 이를 신뢰하지 않습니다. 그들은 드라이버가 필요한 상황에서도 차라리 대형 망치를 사는 쪽을 택합니다. 단 한 번이라도 잘못 선택하는 것이 천 번을 과다 지불하는 것보다 더 나쁘게 느껴지기 때문입니다.

진짜 문제: 특정 작업에 어떤 모델이 충분한지 '증명'할 수 있는 툴링(tooling)을 만든 사람이 아무도 없다는 점입니다. 팀들은 직관(vibes)에 기반하여 결정을 내리고 있습니다. 이는 그들이 이미 버렸다고 주장하는 바로 그 "바이브 기반 엔지니어링(vibe-based engineering)"과 같습니다. "당신의 쿼리에는 Opus가 아니라 Sonnet이 필요합니다"라고 입증 가능한 확신을 가지고 말할 수 있는 자동화된 라우팅 시스템(routing systems)이 구축되기 전까지, 우리는 필요하지도 않은 작업에 프론티어 모델을 사용하며 계속해서 현금을 낭비하게 될 것입니다.

2. 평가의 격차(The Evaluation Chasm) — 바이브 체크(Vibe Checks)는 끝났지만, 이를 대체할 것은 없다

📸 📸 Unsplash

DEV의 창립자인 Ben Halpern는 박람회를 돌아다니며 정확히 이 현상을 기록했습니다. 그의 결론은 다음과 같습니다: "분위기 기반 엔지니어링(vibe-based engineering)은 끝났다." 몇 개의 출력물을 검토하고, 그것이 합리적으로 보인다고 판단하여 프로덕션(production)에 배포하는 방식은 더 이상 용납되지 않습니다.

그가 작성한 바에 따르면, 새로운 표준은 격리된 가상 환경(isolated virtual environments) — 모의 데이터베이스(mock databases)와 네트워크 액세스 권한을 가진 임시 샌드박스(sandboxes) — 을 구축하고 에이전트(agent)가 복잡한 작업을 시도하도록 하는 것입니다. 이 프레임워크는 스타일을 채점하지 않습니다. 대신 작업이 완료되었는지 확인하고, 단계(steps)를 카운트하며, 보안 프로토콜(security protocols)이 위반되지 않았는지 검증합니다.

훌륭하게 들립니다. 하지만 박람회에 참석한 거의 누구도 실제로 이를 구현하지는 못했습니다.

저는 자금력이 풍부한 한 AI 스타트업 팀과 이야기를 나누었는데, 그들은 여전히 "시니어 엔지니어가 20개의 출력물을 읽고 상대 평가(grade them on a curve)를 통해 에이전트를 평가하고 있다"고 인정했습니다. Fortune 500대 기업의 또 다른 팀은 출력된 JSON이 유효한지 확인하는 단순한 합격/불합격(pass/fail) 스크립트를 사용한다고 말했습니다. 그게 전부입니다. 파싱(parse)만 되면 배포합니다.

"우리가 해야 한다고 알고 있는 것"과 "누군가가 실제로 구축한 것" 사이의 간극은 엄청납니다. 그 이유는 다음과 같습니다:

좋은 평가(evals)는 비용이 많이 듭니다. 모든 에이전트 상호작용에 대해 마이크로 샌드박스(micro-sandbox)를 가동하는 것은 컴퓨팅 자원과 시간을 소모합니다. 수백만 개의 요청을 처리하는 채팅 애플리케이션의 경우, 모든 응답에 대해 전체 평가 파이프라인(evaluation pipeline)을 실행하는 것은 재정적으로 불가능합니다.

정답(Ground truth)이 불분명합니다. 문서를 작성하는 에이전트에게 "성공"이란 어떤 모습일까요? 혹은 코드베이스를 리팩터링(refactor)하거나 고객 이메일에 답장하는 에이전트라면 어떨까요? 우리는 평가 기준에 합의조차 하지 못하고 있으며, 자동화는 말할 것도 없습니다.

회귀 테스트(Regression testing)는 초기 단계에 머물러 있습니다. 한 엔지니어는 자신의 평가 프레임워크를 보여주었는데, 그것은 서로 느슨하게 연결된 40개의 Python 스크립트 모음처럼 보였습니다. 각 스크립트는 서로 다른 에이전트 기능을 테스트하며, 그 주에 시간이 나는 사람이 유지보수하는 방식이었습니다. 새로운 모델이 출시되면, 그들은 스크립트를 수동으로 실행하고 스프레드시트에서 수치를 비교했습니다.

이것이 현재 업계의 현주소입니다. 우리는 "느낌이 괜찮은가?"의 단계를 넘어섰지만, 아직 "제대로 작동하는가?"라는 단계에 도달하지는 못했습니다. 그리고 이러한 불확실한 상태(limbo)는 위험합니다. 팀들은 컴퓨터 과학(CS) 전공 1학년의 프로젝트 테스트 스위트(test suite)조차 통과하지 못할 수준의 평가 프레임워크(evaluation frameworks)를 가지고 에이전트 시스템(agentic systems)을 프로덕션 환경에 배포하고 있습니다.

3. 신뢰의 천장 — 에이전트는 당신에게 안전하다는 확신을 주는 것만 빼고 모든 것을 할 수 있다

에이전트에게 코드를 작성하고, 파일을 수정하며, 터미널 명령어를 실행할 권한을 부여하는 것은 대부분의 팀이 이제 막 이해하기 시작한 위험을 초래합니다.

업계 표준은 **마이크로 샌드박스(micro-sandboxes)**로 모이고 있습니다. 이는 E2B나 Docker와 같은 제공업체의 가볍고 일시적인 마이크로 VM(micro-VMs)으로, 밀리초 단위로 실행되어 특정 계산을 처리한 후 즉시 파괴됩니다. 설계 단계부터 보안이 고려되었으며(Secure by design), 컨테이너 탈출(Container escape) 위험을 최소화하고 파일 시스템 변조(File system tampering)를 무력화합니다.

하지만 보안이 진짜 신뢰의 문제는 아닙니다. 신뢰의 문제는 더 깊은 곳에 있습니다.

한 주요 클라우드 제공업체의 시니어 엔지니어가 저에게 남긴 말은 매우 인상적이었습니다. "우리는 에이전트를 기술적으로 안전하게 만들 수 있습니다. 하지만 우리가 할 수 없는 것은 엔지니어가 에이전트를 사용할 때 안전하다고 느끼게 만드는 것입니다."

안전한 것(being safe)과 안전하다고 느끼는 것(feeling safe) 사이에는 차이가 있습니다. 그리고 AI 업계는 후자(느끼는 것)에 매우 취약합니다.

이번 컨퍼런스에서는 자격 증명 마스킹(credential masking)에 대해 광범위하게 다루었습니다. 예를 들어 AAuth와 같은 프로토콜은 에이전트가 원본 API 키를 전혀 보지 않고도 도구를 호출할 수 있도록 임무 범위 내의 권한(mission-bounded authority)을 부여합니다. 이는 프롬프트 인젝션(prompt injection) 유출을 무력화합니다. 이는 훌륭한 엔지니어링입니다. 하지만 개발자가 에이전트가 프로덕션 인프라를 자율적으로 수정하는 것을 지켜볼 때, 질문은 "자격 증명이 안전한가?"가 아닙니다. 질문은 "이 녀석이 내 데이터베이스를 삭제하지 않을 것이라고 믿을 수 있는가?"입니다.

그 질문에는 아직 기술적인 정답이 없습니다. 신뢰는 신뢰성(reliability), 예측 가능성(predictability), 그리고 시간 — 현재의 AI 엔지니어링 사이클이 제공하지 못하는 이 세 가지를 통해 얻어지는 것이기 때문입니다.

박람회에 나온 모든 에이전트 프레임워크 (agent framework)에는 "인간 참여 (human in the loop)" 폴백 (fallback) 장치가 있었습니다. 단 하나도 빠짐없이 말이죠. 왜냐하면 벤더 (vendor), 플랫폼 팀 (platform teams), 심지어 가장 낙관적인 루프 옹호자들조차도 에이전트가 프로덕션 (production) 환경에서 완전히 자율적으로 실행되는 것을 실제로 신뢰하지 않기 때문입니다. 폐막 세션에서의 논쟁은 "인간이 참여해야 하는가?"가 아니었습니다. 그것은 "결국 그들을 제거할 수 있는가, 그리고 언제인가?"였습니다.

이것이 2026년 중반 AI 엔지니어링 (AI engineering)의 솔직한 상태입니다. 우리는 거의 무엇이든 할 수 있는 에이전트를 구축했습니다. 단지 그것들을 혼자서 하게끔 신뢰할 수 없을 뿐입니다.

공지: 이 기사의 일부 링크는 제휴 링크입니다. 이를 통해 구매하시면 귀하에게 추가 비용 부담 없이 저에게 소정의 수수료가 지급될 수 있습니다. 저는 진심으로 유용하다고 생각하는 제품만을 추천합니다.

이것이 실제로 의미하는 바

저는 컨퍼런스를 비난하기 위해 이 글을 쓰는 것이 아닙니다. AI 엔지니어 월드 페어 (AI Engineer World's Fair)는 진심으로 인상적이었습니다. 그 에너지, 기술적 깊이, 그리고 실제로 무언가를 구축하고 있는 엄청난 수의 사람들까지 말이죠. 결함이 있는 부분에만 집중하다 보면, 지금이 2007년 이후 소프트웨어를 구축하기에 가장 흥미로운 시기라는 점을 놓치기 쉽습니다.

하지만 하이프 사이클 (hype cycle)은 어려운 문제들을 덮어버리는 경향이 있으며, 제가 여기서 제시한 세 가지 문제는 실제 엔지니어링 (engineering)과 데모용 소프트웨어 (demo-ware)를 구분 짓는 요소가 될 것입니다.

현재 이 분야에서 작업하고 계신 분들을 위한 저의 솔직한 조언은 다음과 같습니다:

프런티어 모델 (frontier models)을 기본값으로 사용하는 것을 멈추세요. 주말을 내어 실제 워크로드 (workload)에 대해 더 작고 빠른 모델을 벤치마크 (benchmark)해 보십시오. 절감된 비용만으로도 평가 인프라 (eval infrastructure)를 구축할 자금을 마련할 수 있습니다.

먼저 형편없는 평가 (eval) 체계라도 만드세요. 완벽한 프레임워크 (framework)를 기다리지 마십시오. 가장 흔한 에이전트 작업들을 대표하는 5가지 테스트 케이스 (test cases)를 작성하고, 이를 자동화하며, 시간이 지남에 따라 통과율 (pass rates)을 추적하십시오. 정교화는 나중에 해도 됩니다.

당신의 에이전트가 충분히 안전하지 않다고 가정하세요. 샌드박싱 (sandboxing), 자격 증명 격리 (credential isolation), 그리고 킬 스위치 (kill switches)에 과도할 정도로 투자하십시오. 에이전트가 실수로 파괴적인 행동을 하는 날 — 이는 '만약'의 문제가 아니라 '언제'의 문제입니다 — 당신은 당신이 취했던 모든 예방 조치에 감사하게 될 것입니다.

세계 박람회에서도 아무도 해결하지 못한 3가지 AI 엔지니어링 문제는 저절로 해결되지 않을 것입니다. 하지만 해결 가능합니다. 다만, 단순한 과장(hype)만으로는 불가능합니다.

저는 7월 2일부터 4일까지 샌프란시스코에서 열린 AI Engineer World's Fair 2026에 참석했습니다. 정직한 이들을 보호하기 위해 일부 이름은 생략되었습니다.