AI 에이전트 엔지니어링의 이름이 바뀌는 속도가 점점 빨라지고 있다. 프롬프트에서 시작해 컨텍스트, 하네스, 루프를 거쳐 이제 그래프나 팩토리까지 왔다.
6주 만에 3번 바뀐 이 이름들은 단순한 유행이 아니라, 인간이 어디까지 물러나고 있는지를 보여주는 표식이다.
물론 오늘 막 나온 어떤 이름이 끝판왕이라는 뜻은 아니다. 이름은 앞으로도 계속 태어날 것이다.
6주 만에 3번 바뀐 이름
2026년 6월 7일, 개발자 피터 스타인버거가 X에 올린 짧은 글이 며칠 만에 650만 조회수를 넘겼다. 코딩 에이전트를 쓸 때 매번 프롬프트를 직접 입력하지 말고, 에이전트가 스스로 프롬프트를 만들고 실행하는 ‘루프’를 설계하라는 내용이었다. 이 글이 퍼지면서 ‘루프 엔지니어링’이라는 말이 그달 AI 업계의 가장 큰 화두가 됐다.
같은 주, 클로드 코드를 만든 앤트로픽의 보리스 체르니(Boris Cherny)도 비슷한 말을 했다. “나는 더 이상 클로드에 프롬프트를 직접 넣지 않는다. 프롬프트를 넣고 다음에 무엇을 할지 판단하는 루프가 있고, 내 일은 그 루프를 만드는 것이다.” 이는 한 개인의 취향이 아니라, 코딩 에이전트를 실제로 만드는 회사 안에서 이미 쓰이던 방식이라는 확인이었다.
그런데 정확히 6주 뒤인 7월 18일, 스타인버거 자신이 다시 물었다. “우리 아직도 루프 얘기를 하고 있나, 아니면 이미 그래프로 넘어갔나.” 이 질문은 몇 시간 만에 57만 5천 조회수를 넘겼다. 자신이 처음 띄운 용어의 유효기간을 스스로 의심한 셈이다.
곧바로 개발자 산티아고는 “Loop engineering is dead. Long live graph engineering.”라고 받았다. 반면 다른 쪽에서는 루이스 카타코라의 말을 빌려 “그래프는 워크플로를 얼마나 제대로 짜지 않았는지를 인정하게 만들 뿐”이라며 아직 이르다고 맞섰다.
6주 사이에 이름이 3번 바뀌었다. 용어를 처음 던진 사람조차 다음 이름 앞에서 한 박자 멈칫했다는 점이, 이 논쟁의 성격을 가장 잘 보여준다.
결국 인간의 자리는 점점 물러난다
프롬프트 엔지니어링이 쓰이던 2022–2023년, 인간의 일은 입력 문장 한 줄을 다듬는 것이었다. 2024년 컨텍스트 엔지니어링으로 넘어가면서 그 일은 한 단계 물러났다. 이제 인간이 할 일은 문서, 이전 대화 기록, 도구가 내놓은 결과 중에서 무엇을 모델에 넣어줄지 설계하는 것이 됐다.
2026년 초에는 ‘하네스 엔지니어링’이라는 말이 등장했다. 에이전트가 실제로 일을 수행할 때 필요한 도구, 검증, 감시 체계를 한꺼번에 짜는 작업이다. 여기에는 다섯 가지가 포함된다.
- 여러 도구를 순서대로 연결하는 일
- 결과가 맞는지 확인하는 검증 루프
- 컨텍스트와 메모리를 관리하는 일
- 잘못된 행동을 막는 가드레일
- 전체 과정을 지켜보는 관측 체계
프로덕션에서 일어나는 AI 실패의 65%는 모델 자체가 아니라 이 하네스의 결함에서 나온다. 대화가 길어지면서 이전 맥락을 놓치는 현상(컨텍스트 드리프트), 데이터 형식이 맞지 않는 문제, 상태가 점점 나빠지는 현상이 대표적이다. 인간의 일은 이제 한 번 실행하는 것이 아니라, 그 실행이 안전하게 반복될 수 있는 틀을 만드는 쪽으로 옮겨갔다.
루프 엔지니어링은 이 하네스를 한 걸음 더 밀어냈다. 에이전트가 스스로 할 일을 찾고, 하위 에이전트에게 넘기고, 결과를 확인한 뒤 다음 행동을 정하는 순환 구조로 바꾼 것이다. 인간은 그 순환이 언제 멈춰야 하는지를 정하는 자리로 밀려난다.
그래프 엔지니어링은 여기서 한 단계 더 올라간다. 루프 하나가 아니라, 서로 다른 루프를 도는 여러 에이전트를 의존 관계로 연결한 ‘조직도’를 설계하는 일이다. 마이크로소프트는 2026년 4월 AutoGen과 시맨틱 커널을 하나로 합친 ‘에이전트 프레임워크(Microsoft Agent Framework)’ 1.0을 정식 출시하면서, 여러 에이전트를 그래프 기반으로 조율하는 워크플로를 핵심 기능으로 넣었다. 순차·동시·핸드오프 같은 다중 에이전트 오케스트레이션을 그래프로 명시적으로 설계한다. 층의 이름이 업계에서 통용되기도 전에, 이미 대형 벤더의 제품 안에 그래프가 들어와 있던 셈이다.
한편 같은 시기, 다음 층을 ‘그래프’가 아니라 ‘팩토리(factory)‘로 부르는 흐름도 나왔다. 구글 크롬 개발자 경험 총괄 애디 오스마니(Addy Osmani)는 에이전트 공학의 축이 하네스에서 루프를 거쳐 팩토리로 옮겨가고 있다고 정리했다. 팩토리는 잘 도는 루프 하나를 규모 있게 굴리는 시스템이다. 그는 일을 안쪽 루프와 바깥쪽 루프로 나눈다. 안쪽 루프에서 에이전트가 조사하고, 구현하고, 검증하기를 반복한다면, 바깥쪽 루프에서 인간은 결정하고 검증하고 승인하며 방향을 틀고 그 결과를 책임진다. 시스템 안쪽은 능력의 영역이고 바깥쪽은 권한과 책임의 영역이며, 둘 사이의 경계를 관리하는 일이 핵심이라는 것이다.
이 구분은 층의 이름이 아무리 바뀌어도 인간이 어디에 남는지를 분명히 한다. 생성 속도가 빨라질수록 정작 희소해지는 자원은 검증과 유지보수, 그리고 인간의 판단이다. 엔지니어의 일은 작업을 직접 수행하는 데서, 제약을 설정하고 증거로 검토하며 결과를 소유하는 쪽으로 옮겨간다.
워딩이 주는 임팩트
이름이 바뀔 때마다 이익을 보는 쪽은 분명하다. 버즈워드(buzzword)는 시장의 많은 부분을 움직인다.
가트너는 2026년 에이전트 방식 AI 지출이 전년 대비 141% 늘어 2,019억 달러에 이를 것으로 전망했다. 2030년까지는 기업용 소프트웨어 지출 중 최대 2,340억 달러가 에이전트 방식으로 대체될 위험에 놓여 있다고 본다. 이 돈은 대부분 여러 도구와 에이전트를 조율하는 일, 검증, 관측 같은 ‘층’ 도구에 들어간다.
채용 시장도 같은 패턴을 이미 겪었다. ‘프롬프트 엔지니어’라는 단독 직함 공고는 2024–2025년 사이 40% 넘게 줄어 사실상 사라졌다. 그러나 프롬프트를 설계하는 능력 자체는 AI 관련 채용 공고의 78%에 필수 스킬로 들어갔다. 2024년 초만 해도 20% 미만이었다. 스킬은 사라지지 않고 직함만 바뀐 것이다.
인프라 분야에서도 비슷한 일이 있었다. 시스템 관리자가 데브옵스 엔지니어로, 다시 사이트 신뢰성 엔지니어와 플랫폼 엔지니어로 이름이 바뀌는 데 10여 년이 걸렸다. 업계 평가에 따르면, 상당수 조직은 실제 업무 내용이 크게 바뀌지 않은 채 직함만 새로 포장했다.
이름의 교체 주기가 6주까지 짧아진 지금, 같은 패턴이 반복되고 있다. 다만 더 빨라졌을 뿐이다.
끝은 있을까?
회의론의 핵심은 실용성이다. 발견하고 계획하고, 실행하고 검증하는 과정을 반복하는 단일 에이전트 루프 하나만으로도 대부분의 실무자가 실제로 필요한 일을 처리한다. 만들고 고치는 비용도 여러 에이전트를 연결한 복잡한 구조보다 훨씬 적다. 그래프가 다음 층이라는 선언과, 대다수에게는 아직 이르다는 현실이 동시에 성립하는 이유다.
기술적 반론도 있다. 그래프를 구성하는 각 노드가 부실하게 설계된 루프라면, 그 위에 아무리 정교한 조직도를 올려도 결과는 더 정교하게 실패하는 조직일 뿐이다. 하위 층을 건너뛰고 상위 층의 용어만 먼저 가져오는 것이 실무자가 가장 조심해야 할 함정이다.
그래서 순서가 남는다.
-
하네스와 루프부터 단단히 만든다.
그래프로 성급히 올라가기 전에, 대화가 길어지면서 이전 맥락을 놓치는 현상, 상태가 점점 나빠지는 현상, 데이터 형식이 맞지 않는 문제부터 해결해야 한다. 프로덕션 실패의 65%가 여기서 나온다면, 한 번의 실행이 안전하게 반복되는 틀을 먼저 확보하는 일이 순서상 앞선다.
-
단일 루프로 충분한지 냉정하게 판단한다.
대부분의 실무에서는 잘 설계된 단일 루프가 복잡한 다중 에이전트 구조보다 비용이 적고 고치기도 쉽다. 하위 루프가 부실한 채로 그래프만 얹으면 더 정교하게 실패할 뿐이다. 필요성을 과장하지 말고, 문제를 푸는 데 필요한 최소한의 구조만 고른다.
-
버즈워드의 변화에 휘둘리지 않는다.
6주 만에 3번 바뀐 이름은 투자 유치와 채용 시장을 움직이지만, 실제 업무 내용이 바뀌지 않은 채 포장만 바뀌는 경우가 대부분이다. 에이전트 엔지니어링이라는 큰 틀 안에서 관측, 검증, 상태 관리 역량을 내재화하는 데 집중하고, 이름을 따라가는 경쟁에서는 벗어난다.
‘다음은 그래프인가’라는 질문에는 이미 답이 나와 있다. 그래프는 미래 예측이 아니라, 이름이 뒤늦게 따라붙은 현재형이다.
다만 그래프도 마지막 정점은 아닐 것이다. 프롬프트에서 컨텍스트, 하네스, 루프, 그래프로 이어진 이동은 매번 인간이 개입하는 지점을 한 칸씩 위로 밀어 올렸을 뿐이다. ‘무엇을 실행할지’에서 ‘무엇을 성공으로 볼 것이며 어떻게 검증할지’로 옮겨갔을 뿐, 개입 지점 자체가 사라진 적은 없다.
그래프 다음 칸에 무엇이 오는지도 지금 그려볼 수 있다. 진화의 순서를 다르게 놓아 보면, 단일 에이전트 루프에서 여러 루프를 지휘하는 오케스트레이터로, 다시 루프를 도는 방식 자체를 조정하는 메타 루프로, 그리고 그것들을 의존 관계로 엮은 그래프로 이어진다. 그 다음 칸에는 아마 조직(organization)이 들어갈 것이다.
관계가 느슨하게 설계돼 서로 거의 분리된 그래프들의 집합을, 우리는 조직이라 부르게 될지 모른다. 그리고 그 조직 역시 결국 하나의 큰 그래프다.
이름이 무엇으로 바뀌든, 해야 할 일은 같다. 하네스와 루프를 탄탄히 다지고, 그래프가 정말 필요한지 냉정히 따져보고, 이름보다 역량에 투자하는 것이다.
다음 이름이 무엇이 되든, 새로운 엔지니어링 패러다임은 계속 나올 것이다. 그때 인간이 끝까지 쥐고 있어야 할 것은 이름이 아니라, ‘무엇을 성공으로 볼 것인가’라는 기준이다. 그 기준을 놓치면, 아무리 정교한 그래프도 빠르게 실패하는 기계가 될 뿐이다.