AI Engineer World's Fair 2026 · 클로징 키노트
에이전트가 만들어 내는 코드의 양이 사람이 읽어 낼 수 있는 양을 넘어섰다. 애디 오스마니는 이 지점에서 엔지니어를 다시 정의한다. 코드를 쓸 줄 아는 사람이 아니라, 무엇이 만들어질 가치가 있는지 고르고 그 결과에 답할 수 있는 사람이다.
2026년 6월 29일부터 7월 2일까지 샌프란시스코 모스코니 웨스트에서 열린 AI Engineer World's Fair는 6천 명이 넘는 참가자와 300명 이상의 발표자를 모았다. 행사의 마지막 발표를 맡은 사람은 애디 오스마니였다. 그는 구글에서 14년을 보내며 크롬 개발자도구와 라이트하우스, 코어 웹 바이탈스를 만든 팀을 이끌었고, 최근 몇 년은 구글 클라우드 AI의 디렉터로 제미나이의 개발자 경험을 담당했다. 키노트 2주 전인 6월 중순 그는 구글을 떠났다.
발표의 제목은 바깥 루프를 소유하라였다. 그가 잡은 출발점은 아키텍처가 아니라 사람이다. 미래의 엔지니어는 무엇이 할 만한 일인지 고를 수 있는 사람이며, 점점 더 자동화되는 작업에 대해 증거와 이해와 평결을 함께 소유하는 사람이라는 것이다.
오스마니는 세 단어를 구분한다. 품질은 시스템을 풀어놓기 전에 설치하는 모든 검사다. 검사는 증거를 만든다. 평결은 그 증거를 놓고 내리는 생산 결정이다. 내보낼 것인가, 막을 것인가, 방향을 틀 것인가, 범위를 좁힐 것인가, 가드레일을 붙일 것인가, 아니면 거절할 것인가. 설명 책임은 누군가 물었을 때 왜 그렇게 했는지 설명할 수 있다는 보증이다.
품질은 증거를 만들고, 평결은 책임을 배정한다. 그리고 설명 책임이 있어야 그 평결 뒤에 설 수 있다. 모델이 문장을 썼더라도 평결은 내 것이다. 내 이름으로 나가는 팀의 결과물은 내가 결정하기 전에는 의존 시스템으로 들어가지 않는다.
이 구분은 말장난이 아니다. 에이전트에게 레버리지가 생기면 그 레버리지는 의무를 만든다. 무엇이 바뀌었고, 왜 안전했으며, 틀렸을 때 무슨 일이 벌어지는지 누군가는 정확히 설명할 수 있어야 한다. 그러지 못하면 그 행동은 정당화되지 않고, 애초에 조직이 그런 에이전트를 들일 이유도 없어진다.
지난 1년 동안 논의의 중심은 모델에서 하니스(harness)로, 하니스에서 루프로 옮겨갔다. 오스마니의 정의는 이렇다. 에이전트는 모델에 파일과 도구, 기억, 스킬, 샌드박스, 권한, 관측성, 복구 수단을 붙인 것이다. 모델이 엔진이라면 하니스는 그 엔진 둘레에 만들어 붙이는 차체다. 지능을 위임 가능한 무언가로 바꾸는 것이 하니스다.
루프는 그 하니스를 조사·구현·검증·반복이라는 반복 주기로 감싼 것이다. 한 번 잘 돌아간 실행을 다시 믿고 돌릴 수 있는 절차로 바꾸는 장치다. 여기서 중요한 조건이 하나 있다. 작업이 끝났는지를 판정하는 것은 모델 자신의 주장이 아니라 독립적인 검사여야 한다.
그리고 그 루프를 여러 개 동시에 돌리면 소프트웨어 공장이 된다. 안쪽에서는 에이전트가 일을 실행하고, 경계에서는 사람이 결정을 소유한다.
공장의 핵심은 안과 밖을 가르는 경계다. 안쪽에서는 입력이 모인다. 제품 팀의 의도, 이미 출시된 작업에 대한 지식, 최근 장애 이력, 사용자 피드백이 들어가고, 에이전트 루프가 과제를 조사하고 계획을 구현하고 결과를 검증한다. 그다음 증거가 경계를 넘는다. 의존 시스템을 소유한 사람이 그 증거를 보고 진행 여부를 결정한다.
경계를 넘어오는 것은 코드 자체가 아니다. 디프와 테스트 결과, 로그, 근거, 트레이스, 궤적, 스크린샷처럼 그 작업이 요구하는 형태의 증거다. 그리고 거기서부터 엔지니어링이 시작된다. 그 일이 할 만한 가치가 있었는지 판단하고, 증거가 충분한지 검증하고, 승인하거나 방향을 돌리거나 생산에 도달하는 것을 소유한다.
오스마니는 이 경계를 두고 흔한 오해 하나를 지적한다. 경계는 사람이 AI의 출력물을 들여다보는 지점이 아니다. 경계는 증거와 책임이다. 에이전트를 몇 개 돌리든 수천 개를 돌리든 이 구분은 같다.
코드 품질 도구 회사 소나(Sonar)가 전 세계 개발자 1,100여 명을 대상으로 실시해 올해 1월 공개한 조사 결과다. AI 코딩 도구를 써 본 개발자의 72%가 매일 쓰고 있고, 커밋되는 코드의 42%는 AI가 만들었거나 상당 부분 도왔다. 응답자들은 이 비중이 2027년에는 65%에 이를 것으로 봤다.
문제는 그다음 숫자다. 96%가 AI 생성 코드의 기능적 정확성을 온전히 신뢰하지 않는다고 답했는데, 커밋 전에 항상 확인한다는 응답은 절반이 되지 않았다. 38%는 AI가 쓴 코드를 검토하는 일이 동료가 쓴 코드를 검토하는 것보다 더 많은 노력을 요구한다고 답했다. 35%는 회사가 승인한 계정이 아니라 개인 계정으로 AI 도구를 쓰고 있었다. AWS 최고기술책임자 베르너 포겔스는 이 상태를 검증 부채라고 불렀다.
오스마니의 정리는 간결하다. 개발자들이 순진해서가 아니라 대역폭이 없어서 생긴 문제다. 불신은 있는데 그 불신을 검증 절차에 넣을 여력이 없다. 그래서 안전은 검증을 더 싸고 더 명확하고 더 건너뛰기 어렵게 만드는 데서 온다.
개인이 아니라 조직 단위로 시선을 옮기면 문제는 거버넌스로 바뀐다. 깃랩이 지난 6월 내놓은 조사에 따르면 리뷰와 검증이 현재의 병목이고, 더 걱정스러운 것은 거버넌스가 대체로 코드 생성 이후에 붙는다는 점이다. 위험을 이미 수용하고 소유권을 잃은 뒤에야 규칙이 도착한다. 이렇게 되면 답하기 어려운 질문이 남는다. 이 파일에 모델이 손을 댔는가. 어떤 제약 아래에서 작업했는가. 어떤 증거가 만들어졌는가. 누가 위험을 수용했고 누가 결과를 소유하는가.
같은 회사의 다른 연구가 흥미로운 각도를 더한다. 연구진은 같은 애플리케이션을 담고 같은 테스트를 통과하며 의존성도 동일하되 내부 구조만 다른 저장소를 여섯 쌍 만들었다. 세 쌍은 깨끗한 코드베이스를 일부러 어지럽혔고, 세 쌍은 자연스럽게 지저분해진 코드베이스를 정리했다. 33개 과제를 각 쪽에서 열 번씩, 모두 660회 실행했다.
통과율은 양쪽 모두 92% 근처로 사실상 차이가 없었다. 코드가 깨끗하다고 에이전트가 더 똑똑해지지는 않았다는 뜻이다. 차이는 다른 데서 나타났다. 깨끗한 쪽에서 입력 토큰이 약 7%, 출력 토큰이 약 8% 줄었고, 이미 수정한 파일을 다시 읽는 횟수가 34% 줄었다. 모듈 경계를 둘 이상 넘어야 하는 작업에서는 입력 토큰 10.7%, 파일 재방문 50.8%로 격차가 더 벌어졌다. 깨끗한 이음매에서는 에이전트가 경계를 넘고 계속 갔고, 지저분한 이음매에서는 되돌아왔다.
유지보수성이 능력을 올리지는 않지만 비용을 내린다는 결론이다. 읽기 좋은 코드가 다음 사람을 돕는다는 오래된 명제에, 다음 에이전트를 돕는다는 항목이 하나 추가된 셈이다.
인지적 부채는 문제를 푸는 방법에 대한 이해와 기억이 침식되는 것이다. 코드로 좁히면 저장소에 존재하는 코드의 양과 팀의 누군가가 실제로 설명할 수 있는 코드의 양 사이의 간격이다. 빌드는 통과하고 PR은 병합할 수 있는데, 팀은 자기가 생산에 올리고 있는 시스템을 설명하는 능력을 잃어 갈 수 있다.
앤트로픽이 올해 1월 공개한 무작위 대조 시험이 이 간격을 수치로 보여 준다. 주로 주니어급인 엔지니어 52명에게 아무도 써 본 적 없는 파이썬 비동기 라이브러리 Trio를 주고, 절반에게는 AI 조수를 붙이고 나머지 절반은 문서와 웹 검색만으로 작업하게 했다. 그리고 몇 분 전에 방금 쓴 개념을 묻는 퀴즈를 냈다. AI 그룹은 평균 50점, 손으로 짠 그룹은 67점이었다. 17%p 차이이며 통계적으로 유의했다. 작업 시간은 AI 그룹이 평균 2분가량 빨랐지만 그 차이는 유의성 기준을 넘지 못했다. 격차가 가장 크게 벌어진 문항은 디버깅이었다. 코드가 언제 왜 틀렸는지 알아보는 능력, 다시 말해 AI 코드를 검증할 때 정확히 필요한 능력이다.
다만 이 실험은 채팅형 도구를 기준으로 했다. 연구진 자신이 에이전트형 도구에서는 영향이 더 뚜렷할 것이라고 덧붙였다. 그리고 AI를 쓴다고 반드시 점수가 낮아지지도 않았다. 코드를 뽑는 데 그치지 않고 후속 질문을 하고 설명을 요구하며 개념을 되묻는 방식으로 쓴 참가자들은 이해도가 높았다.
여기에 위임 깊이가 겹친다. 30초짜리 실행은 상호작용처럼 느껴지지만 한 시간이나 하루 단위로 이어지는 과제는 하나의 작업 흐름이다. 에이전트가 사람이 실을 놓칠 만큼 오래 시스템 안에 머무를 수 있게 된 것이다. 그런 과제를 여러 개 병렬로 돌린다면 리뷰는 마지막에 한 번 훑어보는 일이 될 수 없다. 통제 시스템이 되어야 한다.
두 번째는 AI가 준 답을 검토 없이 받아들이는 것이다. 위임과 항복은 다르다. 위임은 일을 하고 내가 판단할 수 있을 만큼의 증거를 보이라는 요구이며, 판단은 여전히 내가 한다. 항복은 내가 의견을 만들기 전에 상대의 답을 내 답으로 삼는 것이다.
와튼스쿨의 스티븐 쇼와 기디언 네이브가 올해 1월 내놓은 연구가 경고등을 켠다. 참가자 1,372명에게 논리·추론 문제를 주고 챗봇을 쓸 수 있게 하되, 챗봇이 맞는 답을 줄지 자신 있게 틀린 답을 줄지를 연구진이 몰래 통제했다. 챗봇이 틀린 답을 준 시행에서 참가자의 80%가 결국 틀린 답으로 끝났다. 그 가운데 73%p는 스스로 답을 구성해 보지도 않고 그대로 받아들인 경우였고, 7%p는 뒤집으려다 실패한 경우였다. 나머지 20%만이 AI를 넘어서 스스로 맞혔다. 그리고 참가자들은 AI 없이 푼 사람들보다 자기 답에 대한 확신이 11.7% 높았다. AI가 맞을 때 정확도는 기준선보다 25%p 올랐지만, 틀릴 때는 기준선보다 15%p 내려갔다. 도움이 없느니만 못한 상태가 된 것이다.
쇼와 네이브는 이 현상에 인지적 항복이라는 이름을 붙였다. 실패 양식은 AI를 쓰는 것 자체가 아니라 빌려온 확신이다. 위험한 것은 이 항복이 정당한 오프로딩처럼 위장한다는 점이다. 계산기를 쓸 때 우리는 자신이 무엇을 넘겼는지 안다. 대부분의 경우 AI의 답이 맞기 때문에, 넘긴 것이 계산이 아니라 판단이라는 사실을 알아차리기 어렵다.
세 번째는 병렬화의 착시다. 에이전트를 더 많이 돌린다고 내가 여럿이 되지는 않는다. 인지 대역폭은 병렬화되지 않는다. 루프를 하나 더 만들 때마다 라우팅하고 병합하고 검증하고 통합해야 할 결정이 늘어난다. 최악의 거동으로부터 에이전트를 돌려세우는 일, 쏟아진 결과물 가운데 주의가 필요한 것을 골라내는 일, 위험한 가정을 먼저 확인하는 일은 자동화되지 않는다.
해법은 에이전트 수를 줄이는 것이 아니라 자기 주의를 하나의 시스템처럼 설계하는 것이다. 어디서 개입할지, 무엇을 요구할지, 무엇을 재사용할지를 의도적으로 정한다. 워크트리와 스코프와 증거를 써서 초기 계획과 실제로 나온 작업 사이의 결합을 줄이고, 해결되지 않는 단계에는 시간 상자를 씌우고, 소프트웨어의 변경은 명시적으로 허용된 것만 가능하게 만든다.
브라운필드 시스템에서 이 세금은 특히 무겁다. 감사해야 할 시스템 거동이 코드에 적혀 있지 않고 흉터에 남아 있기 때문이다. 운영 이력, 마이그레이션 기록, 릴리스와 예산 주기, 말해지지 않은 가정, 엣지 케이스, 데이터의 기묘함, 런북의 절차가 모두 그 시스템의 일부다.
오스마니가 쓰는 품질의 다른 이름은 백프레셔다. 에이전트에게 행사할 수 있는 최대한의 자율성을 주지 않는다는 뜻이다. 멈추게 하고 속도를 조절하고 결과를 검사할 수 있을 만큼의 저항이 남는 선까지만 준다.
평범한 엔지니어링은 이미 그런 신호를 잔뜩 갖고 있다. 타입 검사, 테스트, 훅, 샌드박스 한계, 감사 로그, 모니터가 그것이다. 에이전트가 같은 신호를 내보내는 한, 기존의 엔지니어링 체계가 필요한 저항을 만들어 준다. 시스템을 신뢰한다는 것이 사람을 루프에서 빼도 된다는 뜻은 아니다. 다만 사람이 있어야 할 곳이 안쪽 루프가 아닐 뿐이다.
제약 루프 — 어떤 입력과 아키텍처, 지시, 불변식을 걸어 둘 것인가.
표집 루프 — 산출물 가운데 얼마를 뽑아서 볼 것인가.
감사 루프 — 어떤 증거를 남기고, 그 기록이 실제로 쓸모 있게 만들 것인가.
소유 루프 — 생산 경계의 어느 부분을 내가 소유할 것인가.
긴 시간 지평을 가진 에이전트에서 설명 책임이 특히 중요해지는 이유도 여기 있다. 한 시간 단위로 내려진 판단들은 전부 기록되지 않으며 입력 토큰까지 거슬러 추적할 수도 없다. 결과만 믿고 넘어가면, 나중에 그 결정의 사슬을 복원하는 데 수백에서 수천 시간이 든다. 그래서 설명 책임은 사후의 미덕이 아니라 시스템 설계의 요소여야 한다.
커리어를 이야기하면서 오스마니는 두 단어를 꺼낸다. 알파는 오늘 내가 할 수 있는 것과 현재 모델이 할 수 있는 것 사이의 간격이다. 감쇠는 그 간격에 걸린 시계다. 나를 특별하게 만드는 것이 하나의 능력이라면, 프론티어는 결국 그 능력을 가지러 온다.
목록을 놓고 보면 감쇠는 이미 진행 중이다. 속도는 오래전에 넘어갔고, 기억은 하니스가 가져갔다. 검증도 평가 세트와 정적 검사, 모델 비평의 형태로 하니스 쪽으로 이동하는 중이다. 남는 후보가 테이스트다.
폴 그레이엄의 논지는 누구나 무엇이든 만들 수 있게 되면 무엇을 만들지 고르는 일이 중요해진다는 것이다. 오스마니는 여기에 동의하면서도 경계한다. 테이스트는 아직 설명하고 싶지 않은 부분을 덮는 주문이 되기 쉽기 때문이다. 그가 더 쓸모 있다고 본 정의는 하시코프 창업자이자 터미널 에뮬레이터 Ghostty를 만든 미첼 하시모토가 지난 6월 말 내놓은 것이다. 테이스트란 아직 객관적 지표가 존재하지 않는 곳에서 일관되게 높은 수준의 질적 판단을 내리는 능력이다. 이 정의의 미덕은 테이스트를 벤치마크보다, 그리고 시장의 투표보다 앞에 놓는다는 데 있다. 새 모델을 써 보고 그것이 만드는 사용자 경험에 감각이 있는지 없는지, 사람이 채워야 할 빈틈이 어디인지 우리는 대체로 알아본다.
그러나 테이스트도 알파다. 다만 더 느리게 감쇠할 뿐이다. 모델이 예시와 선호를 학습하면서 기준선은 다시 설정된다. 판단조차 벽이 아니라 경사면이다. 그래서 전략은 하나의 능력을 붙드는 것이 아니라 자기 경계를 한 단계씩 위로 옮기는 것이 된다. 어떤 일을 하는 것에서, 그것을 가르치는 것으로, 체계화하는 것으로, 언제 해야 하는지 결정하는 것으로, 그리고 결과를 소유하는 것으로.
테이스트를 신비주의로 두지 않으려면 운용 가능한 형태로 바꿔야 한다. 옮기고 싶은 감각에 이름을 붙이고, 비평과 예시로 연습하고, 왜 그렇게 판단했는지 근거를 명시한다. 그러면 팀과 시스템이 거기서 배울 수 있다.
채용에서 자주 쓰이는 하이 에이전시라는 말을 오스마니는 이렇게 다시 정의한다. 결과를 능동적으로 소유하는 것, 언제 위임하고 언제 들여다보고 언제 멈추고 언제 결과에 이름을 걸지 아는 것이다. 내가 전부 직접 한다는 판본은 확장되지 않으며, 바쁘게 보이는 연기도 아니다. 판단이 붙어 있는 소유다.
사다리의 맨 위가 해결이 아니라 분별이라는 점이 이 그림의 핵심이다. 에이전트가 가능한 경로를 더 많이 열어 줄수록, 에이전시는 모든 경로를 쫓아가는 일이 아니라 어떤 경로가 내 소유와 주의를 받을 자격이 있는지 결정하는 일이 된다.
컴퓨터로 무언가를 하게 만들 수 있는 사람의 수는 어느 때보다 많다. 만드는 사람의 시장은 이보다 컸던 적이 없다. 오스마니는 이 확장을 반긴다. 다만 그렇기 때문에 엔지니어라는 단어가 조금 더 엄격해져야 한다고 본다. 엔지니어는 코드를 짜서 무언가를 존재하게 만드는 사람이 아니라, 시스템을 놓고 추론하고 제약을 고려하고 트레이드오프를 방어하고 위험을 관리하며 무언가 무너지기 시작할 때 연락이 닿는 사람이다.
역할의 재편도 같은 방향으로 간다. 앤트로픽에서 Claude Code를 만든 보리스 체르니는 지난 6월 말 자기 팀을 관찰한 결과를 다섯 개의 원형으로 정리했다. 아이디어를 대량으로 쏟아 내되 대부분 출시되지 않는 프로토타이퍼, 그것을 빠르게 프로덕션 등급으로 바꾸는 빌더, 정리하고 단순화하고 걷어 내고 성능을 다듬는 스위퍼, 만들어진 제품을 시장에 맞춰 키우는 그로어, 성숙한 시스템을 안전하고 안정적으로 유지하는 메인테이너다. 그는 이 원형들이 직무와 묶여 있지 않다는 점을 강조했다. 디자이너 중에도, 엔지니어 중에도, PM과 데이터 사이언티스트 중에도 각 유형이 있다.
오스마니는 이 분류를 인용하면서 질문을 하나 바꾼다. 희소한 것은 작업을 수행하는 능력이 아니라, 지금 이 제품에 어떤 모드가 필요한지, 어떤 품질 기준이 적용되는지, 결국 누가 결과를 소유하는지 아는 일이다. 직함이 무엇이냐가 아니라 시스템의 어느 부분을 소유할 수 있느냐가 질문이 된다.
발표 후반부의 운영 규칙은 한 줄이다. 설명할 수 없으면 내보내지 않는다. 사람이 모든 줄을 타이핑하거나 읽어야 한다는 뜻이 아니라, 누군가는 그 작업을 방어할 수 있을 만큼 이해하고 있어야 한다는 뜻이다.
큰 코드베이스에는 특정 디렉터리에 대해 책임지는 사람을 적어 두는 소유자 파일이 있다. 오스마니는 같은 방식으로 생각하라고 말한다. 우리 아키텍처의 이 부분은 누가 책임지는가. 모델이 코드를 쓸 수는 있다. 질문은 여전히 에이전트가 내보내는 그 변경을 내가 설명할 수 있는지, 증거를 갖고 있는지, 위험을 이해하고 있는지다.
변경을 받아들일 때 이해된 점검 목록, 그 결정에 들어간 증거, 누가 책임을 졌는지, 그리고 변경 이후 또는 차단 이후 시스템이 어떤 상태인지. 코드베이스마다 이런 계약이 하나씩 있어야 한다는 것이 그의 제안이다.
여기서 커리어 계산법이 나온다. 우위의 반감기는 한 번의 모델 릴리스지만, 서명의 반감기는 경력 전체다. 서명이란 작업에 붙은 이름이다. 출시된 것 뒤에 서는 사람, 팀, 기관이다. 기술은 레버리지를 얻게 하고, 설명 책임은 그 레버리지를 신뢰로 바꾼다.
그래서 그가 분명히 긋는 선이 있다. 에이전트는 고를 수 있고, 라우팅할 수 있고, 병합할 수 있고, 에스컬레이션할 수 있고, 정책 안에서 작동할 수 있다. 많은 시스템에서 그렇게 해도 되고 그렇게 해야 한다. 그러나 실행과 책임은 다른 것이다. 에이전트는 런북을 따를 수는 있어도 결과를 물려받지는 못한다. 무언가 실패했을 때 남는 질문은 누가 그 정책을 이해했는가, 누가 위험을 수용했는가, 누가 폭발 반경을 소유하는가다.
발표는 낙관으로 끝난다. 소프트웨어를 쓰기 쉽게 만들 때마다 우리는 세상이 소프트웨어를 덜 필요로 하게 될 것이라고 예측했다. 고수준 언어가 나왔을 때, 프레임워크가 나왔을 때, 클라우드와 로우코드가 나왔을 때 모두 그랬다. 매번 반대의 일이 벌어졌다. 비용이 내려가면 그동안 만들 만하지 않다고 여겨졌던 아이디어들, 억눌려 있던 수요가 풀려나온다.
에이전트도 같은 일을 할 것이다. 엔지니어링 작업을 없애는 것이 아니라 병목을 옮긴다. 이것을 만들 수 있는가에서 이것이 존재해야 하는가, 그리고 우리가 그것에 답할 수 있는가로.
자동화는 바닥을 올리고, 엔지니어링은 한 단계 위로 올라간다. 새로 생기는 일은 루프를 설계하는 일, 증거를 설계하는 일, 그리고 오래된 시스템을 돌보는 일이다. 키보드를 덜 두드린다고 앞으로 몇 년간 엔지니어링이 줄어들지는 않는다. 테이스트와 검증과 소유와 돌봄이 필요한 표면적이 늘어난다는 뜻이다.
이 발표에서 가장 실용적인 문장을 하나만 고른다면 경계에 대한 정의다. 사람과 AI의 경계는 사람이 AI의 출력물을 들여다보는 지점이 아니라 증거와 책임이 교환되는 지점이다. 이 정의는 도구를 하나 더 도입할지 말지를 묻는 대신 다른 질문을 하게 만든다. 우리 팀에서 지금 생산으로 나가는 변경에 대해, 무엇이 바뀌었고 왜 안전했으며 틀렸을 때 무엇을 할지 설명할 수 있는 사람이 누구인지. 그 이름을 댈 수 없다면 에이전트를 몇 개 돌리고 있는지는 중요한 문제가 아니다.