Feedback Loop Engineering은 2026년 1월 다니엘 데멜(Daniel Demmel)이 AI 코딩 에이전트의 품질을 높이는 핵심을 “검증 가능한 반복 구조”로 설명하면서 제시한 개념이다.
이후 2026년 2월 OpenAI는 Codex 활용 사례를 통해 하네스 엔지니어링(Harness Engineering)이라는 표현을 사용하며, 에이전트가 안정적으로 일할 수 있도록 실행 환경·검증 체계·피드백 구조를 설계하는 접근을 소개했다.
두 개념은 별개라기보다, Feedback Loop Engineering이 “무엇을 반복해야 하는가”를 설명하고 하네스 엔지니어링(Harness Engineering)이 “그 반복이 가능하도록 어떤 환경을 설계해야 하는가”를 설명한다고 볼 수 있다.
많은 사람들이 “프롬프트를 잘 쓰는 것”이라고 생각한다.하지만 최근 흐름은 다르다. “스스로 검증하고 개선할 수 있는 구조를 만드는 것”이다.
프롬프트 중심에서는 결과가 프롬프트 품질에 크게 의존하며 사람이 계속 개입해야 한다. Feedback Loop Engineering은 완전히 다른 방향을 제시한다. AI가 스스로 결과를 개선하는 구조를 통하여, 결과 품질이 프롬프트가 아니라 테스트와 검증에 의해 결정되도록 만든다. 이러한 구조에서는 사람이 모든 과정을 직접 통제할 필요가 없다. AI는 실행 결과와 오류를 기반으로 스스로 수정하고, 반복적으로 품질을 높여간다.
결국 중요한 것은 더 정교한 질문이 아니라, 잘못된 결과를 빠르게 발견하고 수정할 수 있는 피드백 루프를 설계하는 것이다.
결정적으로 최근 Codex에서 지원하기 시작한 “Computer Use”, “Browser Use” 기능을 직접 경험하면서 생각이 완전히 바뀌었다.
그동안은 좋은 프롬프트, 정교한 스킬, 다양한 서브에이전트를 만드는 것이 핵심이라고 생각했다.
하지만 실제로는 전혀 다른 결과를 보게 되었다.
단순한 명령만으로도
- 테스트 후 수정하고
- 서버를 재시작하고
- 브라우저에서 직접 화면을 확인하고
- 테스트 결과를 바탕으로 다시 수정하는
전체 작업 흐름을 AI가 스스로 수행하는 경험을 하게 되었다. 이 과정에서 느낀 것은 명확했다.
중요한 것은 프롬프트가 아니라 “일을 할 수 있는 환경”이었다.
프롬프트를 아무리 잘 작성해도 AI가 실행하고, 확인하고, 실패를 인지하고, 다시 수정할 수 없다면
결국 사람이 계속 개입해야 한다. 반대로, 환경만 제대로 갖추어지면 아주 간단한 명령만으로도 AI는 스스로 작업을 이어가고 결과를 개선해 나간다.
이 경험은 정말 충격적이었다.
![]() |
| 에이전트가 테스트하고 수정하고 벡엔트 파트 작업는 이슈로 등록 |
![]() |
| 에이전트가 이슈를 확인해서 처리하고 서버를 재시작해서 확인 |
결국 중요한 것은 질문을 잘하는 능력이 아니라, AI가 스스로 실행하고 검증하며 반복할 수 있도록 프로젝트와 환경을 설계하는 것이다.


댓글 없음:
댓글 쓰기