이제 코딩 에이전트에게 프롬프트만 치는 시대는 지나가고 있다(루프 엔지니어링)

루프 엔지니어링이라는 새로운 작업 방식

요즘 AI 코딩 도구를 쓰는 사람들 사이에서 자주 보이는 말이 있다.

“이제 에이전트에게 프롬프트를 치지 마라.”

처음 들으면 조금 이상하다.
AI 에이전트를 쓰려면 당연히 프롬프트를 입력해야 하는 것 아닌가?

그런데 여기서 말하는 핵심은 “프롬프트를 아예 쓰지 말라”는 뜻이 아니다.
매번 사람이 직접 한 줄씩 지시하고, 결과를 읽고, 다시 수정 지시를 내리는 방식에서 벗어나라는 말에 가깝다.

이 흐름을 설명하는 키워드가 바로 루프 엔지니어링(loop engineering)이다.

---

루프 엔지니어링이란 무엇인가

루프 엔지니어링은 간단히 말하면,
내가 에이전트에게 매번 프롬프트를 직접 치는 대신, 에이전트가 반복적으로 일할 수 있는 작업 루프를 설계하는 것이다.

기존 방식은 이랬다.

“이 기능 만들어줘.”
“이 오류 고쳐줘.”
“이 파일 다시 봐줘.”
“테스트 추가해줘.”
“리팩토링해줘.”

사람이 계속 핸들을 잡고 있어야 했다.

루프 엔지니어링에서는 이 흐름을 시스템으로 바꾼다.

예를 들면 이런 식이다.

에이전트가 정해진 시간마다 이슈를 확인한다.
작업할 브랜치나 워크트리를 따로 만든다.
프로젝트 규칙은 SKILL.md 같은 파일에서 읽는다.
코드를 수정한 에이전트와 검토하는 에이전트를 분리한다.
작업 결과와 남은 과제는 메모리 파일에 기록한다.
GitHub, Slack, DB 같은 실제 도구와 연결해 다음 행동까지 이어간다.

즉, 프롬프트 하나를 잘 쓰는 능력보다
에이전트가 반복해서 일할 수 있는 구조를 설계하는 능력이 더 중요해지고 있다.

---

왜 갑자기 이 말이 돌기 시작했을까

이 표현이 주목받은 배경에는 몇 가지 흐름이 있다.

먼저 Addy Osmani가 2026년 6월에 루프 엔지니어링이라는 개념을 정리하면서 이 말이 널리 퍼졌다.
또 Peter Steinberger는 “프롬프트를 치는 대신, 에이전트에게 프롬프트를 치게 만드는 루프를 설계하라”는 취지의 말을 했다.
Claude Code를 만든 Boris Cherny 역시 “이제는 클로드에게 직접 프롬프트를 치기보다 루프를 짠다”는 식으로 이 변화를 설명했다.

여기서 중요한 건 특정 인물의 발언 자체보다,
AI 코딩 도구를 쓰는 방식이 바뀌고 있다는 점이다.

예전에는 사람이 AI에게 계속 지시해야 했다.
이제는 에이전트가 일정한 맥락 안에서 스스로 발견하고, 분류하고, 수정하고, 검증하는 흐름을 만들 수 있다.

그래서 경쟁의 기준도 조금 달라졌다.

“어느 AI 코딩 도구가 제일 똑똑한가?”에서
“어떤 루프를 설계해야 더 안정적으로 일하게 만들 수 있는가?”로 옮겨가고 있다.

---

루프를 구성하는 핵심 요소들

루프 엔지니어링을 이해하려면 몇 가지 구성 요소를 보면 쉽다.

1. 자동화

사람이 매번 “이거 확인해줘”라고 말하지 않아도,
스케줄에 따라 에이전트가 할 일을 발견하고 분류하게 만드는 것이다.

예를 들어 매일 아침 열려 있는 이슈를 확인하고,
실패한 테스트를 찾아보고,
오래 방치된 PR을 정리하게 만들 수 있다.

핵심은 사람이 시작 버튼을 계속 누르지 않아도 된다는 점이다.

---

2. 워크트리

여러 에이전트가 동시에 작업하면 문제가 생긴다.
같은 파일을 건드리거나, 서로의 변경사항을 덮어쓸 수 있기 때문이다.

그래서 각 에이전트가 격리된 작업 공간에서 일하게 만든다.
Git worktree 같은 구조가 여기에 해당한다.

쉽게 말하면, 에이전트마다 따로 책상을 만들어주는 것이다.

---

3. 스킬

프로젝트마다 반복해서 설명해야 하는 규칙이 있다.

코딩 스타일, 폴더 구조, 배포 방식, 금지된 패턴, 테스트 기준, 문서 작성 방식 같은 것들이다.

이걸 매번 프롬프트에 적는 대신 SKILL.md 같은 파일에 정리해둔다.
에이전트는 작업할 때 이 파일을 읽고 프로젝트의 작업 방식을 따른다.

프롬프트가 일회성 지시라면,
스킬 파일은 프로젝트에 붙어 있는 장기 규칙에 가깝다.

---

4. 커넥터와 플러그인

에이전트가 코드만 읽고 끝나면 할 수 있는 일이 제한적이다.
실제 업무는 GitHub, Slack, 데이터베이스, 배포 도구, 모니터링 시스템과 연결되어 있기 때문이다.

MCP 같은 표준은 에이전트를 이런 외부 도구와 연결하기 위한 방식으로 이해할 수 있다.

이 연결이 생기면 에이전트는 단순히 답변을 생성하는 존재가 아니라,
실제 개발 환경 안에서 행동하는 작업자가 된다.

---

5. 서브에이전트

중요한 포인트는 “만드는 에이전트”와 “검사하는 에이전트”를 분리하는 것이다.

코드를 작성한 에이전트가 자기 코드를 스스로 검토하면 놓치는 부분이 생길 수 있다.
그래서 한 에이전트는 구현을 맡고, 다른 에이전트는 리뷰와 테스트를 맡게 한다.

사람으로 치면 개발자와 리뷰어를 분리하는 구조다.

AI 에이전트 시대에도 이 원칙은 여전히 중요하다.

---

6. 메모리

가장 덜 멋있어 보이지만, 사실 가장 중요한 요소가 메모리다.

모델은 매번 실행될 때 이전 맥락을 완벽히 기억하지 못할 수 있다.
하지만 레포지토리 안의 파일은 남아 있다.

그래서 지금까지 무엇을 했고,
무엇이 실패했고,
다음에 무엇을 해야 하는지
파일로 남겨두는 것이 중요하다.

결국 루프의 척추는 거창한 자동화가 아니라,
작업의 기억을 보존하는 평범한 파일일 수 있다.

---

중요한 변화는 도구가 아니라 작업 방식이다

1년 전만 해도 이런 구조를 만들려면 bash 스크립트나 커스텀 자동화를 직접 짜야 했다.
하지만 이제 Claude Code나 Codex 같은 도구들이 이런 흐름을 점점 제품 안으로 가져오고 있다.

그래서 질문이 바뀐다.

“Claude Code가 좋냐, Codex가 좋냐?”
이 질문도 중요하지만, 더 본질적인 질문은 따로 있다.

“나는 어떤 루프를 설계할 것인가?”

같은 도구를 써도 루프를 어떻게 짜느냐에 따라 결과는 완전히 달라진다.

어떤 사람은 에이전트를 통해 자신이 이미 잘 아는 일을 더 빠르게 처리한다.
반대로 어떤 사람은 이해하지 못한 일을 에이전트에게 넘기고, 결과를 그대로 받아들이는 방식으로 쓴다.

겉으로는 둘 다 자동화처럼 보인다.
하지만 실제로는 완전히 다른 사용 방식이다.

---

루프가 강해질수록 검증은 더 중요해진다

루프 엔지니어링이 매력적인 이유는 분명하다.

반복 작업을 줄일 수 있다.
에이전트가 더 넓은 범위의 일을 처리할 수 있다.
사람은 더 상위 의사결정에 집중할 수 있다.

하지만 위험도 있다.

루프가 잘 돌수록 사람은 쉽게 방심한다.
에이전트가 만든 결과를 이해하지 않고 받아들이기 쉬워진다.
검증하지 않은 코드가 자연스럽게 쌓일 수도 있다.

그래서 루프의 핵심은 “사람이 생각하지 않아도 되는 구조”가 아니다.
오히려 반대다.

사람이 더 중요한 판단에 집중하기 위해,
반복적인 지시와 확인을 구조화하는 것이다.

루프는 일을 대신할 수 있지만,
무엇이 맞고 틀린지 판단하는 책임까지 대신해주지는 않는다.

---

결국 핵심은 엔지니어로 남는 것이다

루프 엔지니어링은 멋진 유행어처럼 보일 수도 있다.
혹은 토큰을 많이 쓸 수 있는 사람들의 새로운 자랑처럼 보일 수도 있다.

또한 프롬프트를 직접 치는 방식이 사라지는 것도 아니다.
여전히 단발성 작업, 빠른 실험, 간단한 수정에는 직접 프롬프트를 치는 방식이 충분히 유효하다.

다만 큰 흐름은 분명하다.

AI 코딩 에이전트를 손으로 계속 굴리는 방식에서,
에이전트가 반복적으로 일할 수 있는 환경을 설계하는 방식으로 이동하고 있다.

중요한 질문은 이것이다.

나는 루프를 설계하는 엔지니어로 남을 것인가.
아니면 생각하지 않기 위해 루프 뒤에 숨을 것인가.

루프는 그 차이를 모른다.
하지만 우리는 안다.

그래서 지금 필요한 건 새로운 명령어 하나를 더 외우는 것이 아니다.
내 작업을 어떤 반복 구조로 만들지,
어디까지 자동화하고 어디서 사람이 검증할지,
그 지도를 한 장 그려두는 것이다.

앞으로 코딩 에이전트의 경쟁은 단순히 모델 성능만의 싸움이 아닐 수 있다.
점점 더 “루프 설계 능력”의 싸움이 될 가능성이 크다.