Richard MacManus의 **「5 Trends That Defined AI Engineering at World’s Fair 2026」**은 AI Engineer World’s Fair 2026에서 반복해서 등장한 주제를 다룬다. 2023년의 관심사가 LLM이 자율적으로 행동할 수 있는지 증명하는 일이었다면, 이제는 에이전트를 신뢰할 수 있는 제품과 조직 시스템으로 운영하는 일이 중심이 되었다.
원문: 5 Trends That Defined AI Engineering at World’s Fair 2026
1) 에이전트보다 에이전트를 둘러싼 시스템이 중요해진다
초기의 에이전트 논의는 모델이 계획을 세우고 도구를 사용해 목표를 달성할 수 있는지에 집중했다. AutoGPT, BabyAGI 같은 프로젝트는 자율성의 가능성을 보여주는 실험이었다. 그러나 실제 운영 환경에서는 모델의 한 번의 능력보다 어떤 컨텍스트를 주고, 어떤 도구와 권한을 열어주며, 결과를 어떻게 평가하고, 상태를 어떻게 보존하는가가 더 큰 차이를 만든다.
이 주변 시스템을 하네스라고 부른다. 하네스는 워크플로, 컨텍스트, 권한, 평가, 영속 상태, 개선 과정을 관리한다. 따라서 AI 엔지니어링은 좋은 프롬프트를 만드는 일을 넘어, 모델이 반복해서 일할 수 있는 실행 환경을 설계하는 일로 이동했다.
이 변화는 하네스 엔지니어링 의 핵심과도 맞닿아 있다. 모델이 아무리 강해져도 실행 범위와 검증 루프가 없으면 운영 가능한 시스템이 되지 못한다.
2) 루프 엔지니어링이 새로운 통제 계층이 된다
AIEWF 2026에서 자주 등장한 단어는 루프였다. 에이전트가 한 번 답하고 끝나는 것이 아니라, 계획·실행·관찰·수정을 반복하기 때문이다. 문제는 자율성이 커질수록 무엇을 자동화하고 어디에서 사람이 개입해야 하는지가 불분명해진다는 데 있다.
가장 실용적인 구분은 내부 루프와 외부 루프다.
- 내부 루프: 에이전트가 사용자를 상대하고 도구를 호출하며 실제 작업을 수행하는 과정이다.
- 외부 루프: 사람이 목표와 방향을 정하고, 평가 기준을 만들고, 실패 사례를 분석해 시스템을 개선하는 과정이다.
에이전트에게 내부 실행 루프를 더 많이 맡길 수는 있다. 하지만 외부 루프까지 모두 포기하면 에이전트는 잘못된 목표를 빠르게 반복할 수 있다. 결국 사람의 역할은 모든 작업을 직접 수행하는 것이 아니라, 에이전트가 달리는 선로와 멈춰야 할 지점을 설계하는 쪽으로 이동한다.
이 관점은 루프 엔지니어링 에서 다룬 것처럼, 자율성 자체보다 피드백과 통제 구조가 중요하다는 뜻이다. 특히 자동화 수준이 높아질수록 평가 데이터, 승인 조건, 실패 시 복구 방법을 먼저 정해야 한다.
3) AI 엔지니어링이 기업 안으로 들어간다
기업에서 에이전트를 도입하는 일은 도구 하나를 설치하는 것으로 끝나지 않는다. 기존 데이터와 업무 시스템을 연결하고, 여러 팀이 만든 기능을 조정하며, 자동화해도 되는 단계와 사람이 확인해야 하는 단계를 나눠야 한다.
이 과정에서 주목받은 역할이 FDE(Forward Deployed Engineer)다. FDE는 고객 조직 가까이에서 에이전트와 자동화를 실제 업무에 배치하고, 떠난 뒤에도 조직이 계속 사용할 수 있는 구조를 만든다. 성과 기준도 단순한 데모 완성이 아니라 실제 ROI와 지속 가능한 운영이다.
소프트웨어 팩토리라는 표현도 같은 흐름을 가리킨다. 여러 에이전트가 긴 시간 동안 개발 생명주기의 일부를 수행하고, 사람은 저장소·자동화 범위·코드 리뷰·고위험 변경 승인 지점을 선택한다. 조직마다 코드베이스와 위험 허용도가 다르므로 완전 자동화가 보편적인 답은 아니다.
기업 도입의 또 다른 병목은 컨텍스트다. 조직의 데이터가 공용 지식 계층으로 들어가고, MCP·API·검색을 통해 에이전트와 애플리케이션으로 흘러나오는 경로를 설계해야 한다. 데이터가 연결되지 않은 에이전트는 똑똑해도 조직의 실제 업무를 이해하지 못한다.
4) 코딩 에이전트가 새로운 개발자 인터페이스가 된다
2023년의 AI 코딩은 주로 다음 코드 몇 줄을 예측하는 자동완성이었다. 이제 Claude Code, Codex, Gemini CLI, Cursor, Warp 같은 코딩 에이전트는 더 넓은 목표를 받아 저장소를 탐색하고, 여러 파일을 수정하고, 테스트를 실행하고, 실패를 고친 뒤 결과를 제출한다.
이는 IDE의 기능 하나가 추가된 정도가 아니다. 개발자가 소프트웨어와 상호작용하는 단위가 파일과 함수에서 목표와 작업 루프로 바뀌는 현상이다. 개발자는 코드를 한 줄씩 작성하는 대신, 에이전트가 탐색할 문제 공간과 검증 기준을 정의하고 결과를 평가한다.
다만 에이전트는 일반 애플리케이션보다 출력이 예측하기 어렵다. 따라서 샌드박스, 장시간 실행 작업, 권한 분리, 테스트, 감사 로그 같은 기반 시설이 중요해진다. 사람의 통제권을 유지하면서도 여러 에이전트를 조율해야 하므로, 개발자는 점점 오케스트라의 지휘자와 비슷한 역할을 수행하게 된다.
5) 모든 에이전트 플랫폼이 스킬을 중심으로 만들어진다
스킬은 선임 엔지니어가 사용하는 워크플로, 품질 게이트, 모범 사례를 에이전트가 재사용할 수 있는 형태로 인코딩한 것이다. 거대한 오케스트레이션 코드를 직접 작성하는 대신, 마크다운과 선언적 파일로 에이전트의 능력을 확장할 수 있다.
스킬의 장점은 이식성이다. 특정 모델이나 플랫폼에 종속되지 않고, 필요한 순간에 업무 지식을 불러올 수 있다. 개발뿐 아니라 디자인, 영업, 고객 지원, 재무 같은 업무 절차도 스킬로 표현할 수 있다. 이때 엔지니어의 역할은 스킬이 아직 처리하지 못하는 일을 직접 맡고, 스킬 자체를 계속 개선하는 일로 확장된다.
그러나 스킬이 많아진다고 시스템이 자동으로 좋아지는 것은 아니다. 스킬이 서로 겹치거나 지나치게 크면 에이전트가 어떤 규칙을 따라야 할지 혼란스러워진다. 새 모델이 출시될 때마다 같은 스킬이 동일한 효과를 내지도 않는다. 따라서 작은 단위로 작성하고, 목적과 입력·출력·검증 기준을 분명히 하며, 모델이 바뀔 때 다시 평가해야 한다.
스킬은 에이전트의 능력을 키우는 교과서와 같다. 하지만 교과서가 많다고 학습이 잘되는 것은 아니다. 스킬 설계 에서 다룬 것처럼, 적은 수의 명확한 스킬과 실제 실패 사례를 반영하는 품질 관리가 더 중요하다.
결론 및 시사점
한 줄 결론: AI 엔지니어링의 경쟁력은 더 자율적인 에이전트를 만드는 데서 끝나지 않고, 에이전트가 안전하게 반복·개선·확장되는 시스템을 설계하는 데서 결정된다.
AIEWF 2026이 보여준 변화는 에이전트가 유행하는 도구를 넘어 소프트웨어 개발의 기본 단위가 되어가고 있다는 점이다. 이제 중요한 질문은 “어떤 모델이 가장 똑똑한가?”만이 아니다.
- 에이전트가 어떤 컨텍스트와 권한을 가져야 하는가
- 내부 실행 루프와 외부 감독 루프를 어떻게 나눌 것인가
- 조직의 데이터와 업무 흐름을 어떻게 연결할 것인가
- 자동화와 사람의 승인 사이 경계를 어디에 둘 것인가
- 반복 가능한 절차를 어떤 스킬로 만들고 어떻게 평가할 것인가
이 질문에 답하지 않은 채 에이전트 수만 늘리면 자동화가 아니라 혼란이 커진다. 반대로 하네스, 루프, 컨텍스트, 스킬을 함께 설계하면 AI 엔지니어링은 개인 생산성 도구를 넘어 조직의 운영 시스템이 될 수 있다.