인공지능(AI)이 핵심 개발 도구가 된 이래, 생성형 AI를 다루는 방식은 단순했다. 프롬프트를 입력하고, 답을 받고, 필요하면 다시 고쳐 입력하는 식이었다. 이 지시문을 더 잘 쓰는 요령, 이른바 '프롬프트 엔지니어링'이 AI 활용의 핵심 역량으로 꼽힌 이유다.
최근 이 공식이 깨지기 시작했다. AI 코딩 에이전트가 사람의 개입 없이 몇 시간, 길게는 하루 넘게 스스로 작업을 이어갈 만큼 똑똑해지면서, 병목 지점이 '모델의 능력'에서 '그 능력을 어떻게 반복 실행시킬 것인가'로 옮겨간 것이다. 이와 관련해 '루프 엔지니어링'이라는 개념이 부상하기 시작했다.
◇프롬프트 한 줄에서 '스스로 도는 시스템'으로
루프라는 용어를 대중화한 인물은 구글 크롬 엔지니어링 리드 애디 오스마니다. 그가 지난 6월 이 개념을 정리해 발표하자 한 주 만에 소셜미디어에서 수천 건의 게시물이 쏟아질 정도로 업계 관심이 집중됐다.
업계에서 통용되는 흐름을 보면 AI 활용 방법론은 네 단계를 거쳐왔다. 사람이 던지는 한 번의 질문을 다듬는 프롬프트 엔지니어링, 대화가 길어질 때 어떤 정보를 기억하고 어떤 정보를 버릴지 관리하는 '컨텍스트 엔지니어링', 에이전트가 쓸 도구·권한·실행 환경 전체를 설계하는 '하네스 엔지니어링'을 거쳐, 이제는 그 위에서 에이전트가 스스로 언제 멈추고 언제 다시 시도할지까지 결정하는 순환 구조, 즉 '루프'를 설계하는 단계까지 왔다.
루프 엔지니어링은 하네스 엔지니어링의 상위 개념이자 완성형에 가깝다. 하네스 설계가 에이전트에게 '어떤 도구를 줄 것인가'를 정하는 작업이라면, 루프 엔지니어링은 그 도구들을 '언제, 몇 번, 어떤 순서로 쓸 것인가'까지 프로그램으로 만드는 작업이다.
핵심은 에이전트가 스스로 '할 일을 찾고 → 실행하고 → 결과를 검증하고 → 기억한다'는 순환 구조를 사람이 매번 개입하지 않아도 되도록 시스템으로 만드는 것이다. IBM은 이를 “개발자의 역할을, 에이전트에게 매번 지시문을 입력하는 사람에서, 에이전트에게 일을 맡기고 결과를 점검하고 방향을 조정하는 자동화 시스템을 설계하는 사람으로 바꾸는 작업”이라고 정의했다.
실제로 루프 엔지니어링을 통해 AI가 사람 개입 없이 홀로 작업을 이어가는 시간은, 숙련된 전문가가 수일에 걸쳐 처리하던 작업 분량에 맞먹는 수준까지 늘어났다. 스스로 코드를 작성하고 오류를 찾아 고치는 것은 기본이고, 필요하면 다른 에이전트를 불러 작업을 나눠 맡기는 수준까지 발전했다.
◇루프에서 답 찾는 AI 공룡
AI 기업은 이 개념이 관심을 받기 이전부터 루프 엔지니어링을 적용해 왔다. 앤트로픽의 클로드 코드는 독립된 대화 맥락·권한·지시문을 가진 보조 AI를, 본체 AI가 필요에 따라 동시에 여러 개 불러 쓰는 구조를 갖추고 있다. 최근에는 AI가 직접 코드로 작업 순서를 짜서, 최대 1000개에 이르는 보조 AI를 한꺼번에 운용하는 '다이내믹 워크플로' 기능까지 붙었다.
도구를 실행하기 전후, 작업을 시작하거나 끝낼 때 등 여러 지점에서 미리 정해둔 규칙을 끼워 넣을 수 있는 '훅' 기능을 통해 “테스트를 통과해야만 멈춘다”는 식의 조직 내부 규칙도 강제할 수 있다. 앤트로픽은 이런 루프 설계 원칙을 '루프 시작하기(Getting Started with Loops)'라는 공식 안내 문서로 정리해두기도 했다.
오픈AI의 '코덱스'도 비슷하다. 정해진 주기로 저절로 작업을 시작하는 '오토메이션' 기능과, 목표 조건이 충족될 때까지 스스로 반복하는 '/goal' 명령을 지원한다. 오픈AI는 지난 1월 자사 블로그에 '코덱스 에이전트 루프 뜯어보기'라는 글을 올려 루프 설계 과정에서 얻은 경험을 일부 공개하기도 했다. 실제 한 실험에서는 코덱스가 25시간 동안 중단 없이 혼자 작업을 이어가며 약 3만 줄의 코드를 생성한 사례도 보고됐다.
구글도 마찬가지다. 이미 '에이전트 개발 키트(ADK)'라는 오픈소스 기본 틀을 통해 여러 AI를 함께 조율하는 방식(오케스트레이션)의 표준화에 나섰다.
이런 상황에서 딥시크는 한층 더 과감한 승부수를 던졌다. 클로드 코드와 코덱스는 루프의 '뼈대'는 문서로 공개했지만, 그 뼈대를 실제로 움직이는 내부 소스코드와 판단 로직 자체는 비공개다. 개발자는 앤트로픽과 오픈AI가 정해놓은 명령어와 설정값 안에서만 루프를 조정할 수 있다. 구글의 ADK도 여러 AI를 조율하는 틀 자체는 열려 있지만, 루프를 모델·세션·실행 공간과 동급의 교체형 부품으로 완전히 분리해 소스 단위로 열어놓지는 않았다.
반면 딥시크의 dsh는 '코디스'라는 플러그인 기반 뼈대 프로그램에 기반해, 모델·도구·기능·대화 세션·실행 공간은 물론 루프와 화면(UI)까지 에이전트를 구성하는 모든 요소를 독립된 부품으로 분리해 오픈소스로 공개했다. 언제 작업을 멈출지, 도구 호출이 실패하면 어떻게 다시 시도할지 같은 규칙을 개발자가 직접 코드 단위로 들여다보고 자기 방식대로 다시 짤 수 있다는 뜻이다. 모든 실행 기록을 그대로 남기고 재현할 수 있게 한 점도 앤트로픽·오픈AI 제품에는 없는 특징이다.
◇사라지는 코더, 부상하는 도메인 전문가
루프 엔지니어링이 주목받는 이유는 파급력에 있다. 당초 개발자 사이에서 언급되는 개념이었지만 지금은 전 산업에 영향을 미칠 것으로 주목받는다. 루프 엔지니어링으로 인해 AI를 다룰 줄 아는 사람의 범위가 코드를 짤 줄 아는 사람에서 문제를 정의할 줄 아는 사람으로 넓어지고, AI가 실제로 풀어낼 수 있는 문제의 폭과 깊이도 함께 커지고 있기 때문이다.
지금까지 소프트웨어 개발의 병목은 개발자였다. 아무리 좋은 문제의식이 있어도 이를 구현할 프로그래밍 역량이 없으면 결과물로 이어지지 못했다. 루프 엔지니어링은 이런 문제를 해소했다. 에이전트가 코드 작성부터 검증, 재시도까지 스스로 도는 순환 구조를 갖추면서, 사람의 역할은 '어떻게 짤 것인가'에서 '무엇을 풀 것인가'로 바뀌었다.
이 때문에 현재 변화의 최대 수혜자는 특정 산업의 도메인 지식과 기술 스택에 대한 이해를 함께 갖춘 사람들이 될 가능성이 크다는 전망이 나온다. 금융, 제조, 의료 등 각 분야의 문제를 정확히 정의할 줄 아는 사람이 루프를 설계하고 에이전트를 감독하는 역할만 맡아도, 과거라면 개발팀 전체가 매달려야 했을 문제를 훨씬 짧은 시간에 풀어낼 수 있다. 코드를 얼마나 빨리, 얼마나 많이 짜느냐가 아니라 문제를 얼마나 정확히 정의해 루프에 던지느냐가 결과물의 질을 가르는 시대가 되는 셈이다.
단순 구현 역량 중심의 개발자 수요는 줄어드는 대신, 도메인 지식과 시스템 이해를 겸비한 인력에 대한 수요는 커질 것이라는 관측에도 힘이 실린다.
최호 기자 snoop@etnews.com
