💡 이번주 뉴스레터에는 이런 내용을 담았어요!

• 프롬프트에서 루프까지 AI 활용 방법론이 어떻게 발전했는지 소개했습니다.
• Prompt·Context·Harness·Loop Engineering의 차이와 역할을 정리했습니다.
• 왜 지금 AI 업계가 Loop Engineering에 주목하는지 살펴봤습니다. 

그렇다면 하네스(Harness)란 정확히 무엇을 의미할까요? 하네스는 원래 말과 마차를 연결하는 마구를 뜻합니다. 이때 마구는 단순히 말을 묶어두는 것이 아니라, 강력한 힘을 원하는 방향으로 안전하게 활용하도록 만듭니다. AI에서도 의미는 비슷합니다. 언어모델의 능력을 그대로 쓰면서, 어떤 도구를 사용할 수 있는지, 작업 결과를 어떻게 검증할지, 오류가 발생했을 때 어떻게 복구할지, 작업 상태를 어떻게 관리할지를 설계하는 것이 모두 하네스 엔지니어링의 범위에 포함됩니다.

앞서 언급했던 루프 엔지니어링이 여기에서 등장합니다. (Anthropic의 시니어 엔지니어가 최근 공개한 Loop Engineering Playbook을 중심으로 정리했습니다.)

에이전트가 충분히 똑똑해지고, 스케줄링과 자동 실행 환경이 갖춰지며, 반복 실행에 대한 비용도 크게 낮아지면서 업계도 자연스럽게 루프 엔지니어링으로 옮겨가기 시작했습니다. 이제는 AI에게 한 번 잘 시키는 것보다, AI가 스스로 계속 일하도록 만드는 구조를 설계하는 것이 더 중요한 문제가 된 것이죠.

루프 엔지니어링은 작업이 끝날 때마다 사람이 다시 지시해야 했던 기존 구조를 뒤집어, 사람이 매번 개입하지 않아도 AI가 스스로 작업을 찾고, 실행하고, 검증하며 다음 작업으로 이어지도록 만드는 운영 구조를 설계하는 방식입니다. 루프라고 하면 같은 자리를 맴도는 것처럼 느껴질 수 있지만, 실제로는 단순히 작업을 반복하는 것이 아니라, 한 번의 실행이 다음 실행의 출발점이 되는 구조를 만드는 것입니다.

이 다섯 단계 가운데 특히 강조되는 것은 Discovery와 Verification입니다. 아무리 뛰어난 에이전트라도 잘못된 일을 열심히 수행한다면 아무 의미가 없기 때문입니다. 따라서 루프는 단순히 주어진 작업을 수행하는 것이 아니라, 무엇을 해야 하는지 스스로 발견하는 것에서 시작합니다.

플레이북에서는 한 엔지니어의 아침 루틴을 예로 들어 Discovery가 어떻게 이루어지는지 설명합니다. 매일 아침 자동으로 실행된 에이전트는 어제 실패한 CI 테스트, 새로 등록된 이슈, 최근 커밋 내역을 살펴본 뒤, 그 중 지금 처리해야 할 일과 단순한 노이즈를 구분합니다. 이 과정에서 엔지니어는 매번 우선순위를 정해주거나 새로운 지시를 내리지 않습니다. 에이전트는 미리 정의된 기준(SKILL.md)과 프로젝트 지식을 바탕으로 스스로 우선순위를 판단하고 다음 작업을 결정합니다.

반대로 아무리 적절한 일을 선택했더라도 결과를 제대로 검증(Verification)하지 못하면 루프는 쉽게 무너집니다. 저자는 AI가 자신이 만든 결과를 스스로 평가하면 지나치게 관대한 판단을 내리는 경향이 있다고 설명합니다. 코드를 작성할 당시의 맥락과 의도를 이미 알고 있기 때문에, 결과 자체를 객관적으로 보기보다 '왜 이렇게 만들었는지'를 다시 납득하는 방향으로 판단하기 쉽기 때문입니다.

그래서 최근에는 생성(Generator)과 평가(Evaluator) 역할을 분리하는 구조가 널리 사용됩니다. 결과를 만든 에이전트가 스스로를 평가하는 대신, 별도의 평가 에이전트가 다른 역할과 프롬프트를 바탕으로 결과를 검증하는 것이죠. 이때 반드시 다른 모델을 사용할 필요는 없습니다. 같은 모델이라도 생성 당시의 맥락을 이어받지 않은 새로운 평가자로 동작하도록 만드는 것이 핵심입니다.

예를 들어, 평가 에이전트에게는 ‘이 코드는 이미 문제가 있다고 가정하고 시작하라’는 회의적인 관점을 부여하고, 생성 에이전트가 놓쳤을 수 있는 예외 상황이나 요구사항과 실제 동작이 일치하는지 하나씩 확인하게 합니다. 더 나아가 단순히 결과를 읽고 평가하는 것이 아닌, 실제 테스트를 실행하거나 프로그램을 직접 동작시켜 보는 행동 기반 검증(Action-based Verification)이 더욱 신뢰할 수 있는 방법으로 제시됩니다. 예를 들어 특정 페이지를 열어 버튼을 직접 클릭해 보거나, 화면을 스크린샷으로 기록하고 실제 출력 결과를 확인하는 방식입니다. 이러한 검증을 통과한 경우에만 다음 단계로 넘어가도록 루프를 설계합니다. 

이러한 구조는 이미 실제 산업 현장에서도 적용되고 있습니다. 미국 결제 기업 Stripe는 AI를 활용해 매주 1,300개 이상의 Pull Request를 머지(Merge)하는데, 그 중 사람이 직접 작성한 코드는 단 한 줄도 없다고 합니다. 흥미로운 점은 성능의 비결이 더 뛰어난 언어 모델이 아니라 역할을 나눈 시스템 설계에 있었다는 점입니다. 검색과 테스트, 린트 검사처럼 규칙으로 처리할 수 있는 일은 시스템이 담당하고, AI는 판단이 필요한 부분만 수행하도록 분리한 것이죠.

Stripe Minions의 작업 흐름. 사람이 Slack에서 작업을 요청하면(①), 시스템이 먼저 관련 자료를 수집하고 준비합니다(②).
이후 AI가 코드를 작성하고(③), 작성된 결과는 테스트와 린트 등 자동 검증을 거친 뒤(④), 필요하면 AI가 다시 수정합니다(⑤).
마지막으로 자동 커밋이 이루어지고(⑥), 사람은 최종 결과만 검토합니다(⑦).
즉, AI가 모든 과정을 수행하는 것이 아니라, 시스템과 사람이 앞뒤에서 이를 검증하고 관리하는 구조입니다.

 출처: Loop Engineering: The Anthropic Playbook for Designing Systems That Prompt Your Agents

하지만 이런 구조가 가능하다고 해서 모든 루프가 안전한 것은 아닙니다. 루프가 계속 돌아간다는 것은, 실수 역시 계속 누적될 수 있다는 뜻이기도 합니다. AI가 만들어낸 결과물이 쌓일수록 사람은 시스템이 어떤 과정을 거쳐 결론에 도달했는지 점점 파악하기 어려워지고, 결국 AI의 판단을 비판적으로 검토하기보다 그대로 받아들이게 될 위험이 커집니다. 이렇게 검증되지 않은 결과가 반복해서 다음 작업의 입력이 되면, 작은 오류 하나도 시간이 지날수록 더 큰 문제로 증폭될 수 있습니다. 따라서 ‘잘 설계된’ 루프는 자동화를 극대화하는 것이 아니라, 사람이 개입해야 할 지점까지 함께 설계해 신뢰할 수 있는 운영 구조를 만드는 데 있습니다.

이제 생성형 AI는 코드도, 문서도, 아이디어도 순식간에 만들어냅니다. 이렇게 생성은 점점 쉬워지고 있습니다. 생성보다 판단이, 실행보다 설계가 더 중요해지는 시대가 되어가는 것 같습니다. 기술은 계속 발전하겠지만, 그 변화 속에서도 사람에게 남는 역할은 분명해 보입니다. 오늘 뉴스레터는 플레이북의 한 문장을 인용하며 마무리하려 합니다.

"Build the loop, but build it like someone who intends to stay the engineer,
not just the one who presses go.”

루프를 만들어라. 하지만 그저 실행 버튼만 누르는 사람이 아니라,
끝까지 엔지니어로 남겠다는 자세로 설계하라.