에이전트는 루프로 일한다

위 일곱 가지가 아래에서 말하는 체크리스트다.

어제 같은 오후에도 창이 여러 개 열려 있었다. 하나는 테스트 중이고, 하나는 승인 문구에서 멈춰 있고, 하나는 이미 끝난 줄 알았는데 로그만 보면 아직 돌고 있었다. 그때 필요한 건 더 좋은 지시문이 아니라, 무엇이 돌고 무엇이 나를 기다리는지를 밖에서 판별하는 일이었다.

AI 에이전트의 성과는 프롬프트보다 루프를 어떻게 설계했는가에서 갈린다.

좋은 프롬프트는 한 번의 답을 개선한다. 하지만 실제 일은 한 번에 끝나지 않는다. 에이전트는 현재 상태를 읽고, 작업 범위를 정하고, 결과를 검증하고, 실패하면 다시 시도해야 한다. 적절한 때에 멈추고 다음 실행을 위한 기록도 남겨야 한다.

그래서 에이전트를 잘 운영한다는 것은 멋진 지시문을 만드는 일보다 반복 가능한 작업 구조를 만드는 일에 가깝다.

프롬프트만으로는 작업의 앞뒤가 비어 있다

단발 지시는 무엇을 만들지 설명할 수 있지만, 작업을 언제 시작하고 어디서 멈출지는 충분히 설명하지 못한다.

예를 들어 “이 이슈 마무리해줘”라는 문장은 목표는 알려준다. 그러나 어느 세션에서 할지, 원격에 올려도 되는지, 테스트는 뭘로 볼지, 승인 창이 뜨면 어떻게 할지, 같은 실패가 반복되면 언제 사람에게 넘길지는 비어 있다.

이 빈칸을 에이전트의 판단에 전부 맡기면 결과의 편차가 커진다. 반대로 시작 조건과 작업 경계, 검증 기준과 종료 조건을 미리 정하면 프롬프트가 조금 부족해도 실패의 범위는 작아진다.

좋은 에이전트는 한 번에 정답을 내는 에이전트가 아니라, 틀렸음을 발견하고 다시 수렴할 수 있는 에이전트다.

AI를 쓰는 것과, AI를 전제로 일하는 것

차이는 “AI를 써봤는가”에서 나지 않는다. 막힐 때 질문하고, 에러를 붙여 넣고, 초안을 맡기는 방식은 기존의 일하는 흐름 위에 AI를 얹은 형태에 가깝다.

AI를 전제로 일하면 시작 시점부터 자리가 달라진다. 문제를 정리할 때, 방향을 비교할 때, 구현을 나누고 결과를 검토할 때 AI가 들어올 위치를 같이 잡는다. 도구처럼 필요할 때만 꺼내기보다, 일의 흐름 안에 계속 두는 쪽에 가깝다.

나는 그걸 프롬프트를 더 다듬는 쪽으로만 풀지 않았다. 쓰는 에이전트마다 스킬과 도구를 따로 맞춰 주던 일을 줄이고, 한곳에서 규칙을 두고 여러 세션이 같은 판을 물게 만들었다. 다음에 창을 열면 이미 맥락과 도구가 깔려 있다. 모델이 규칙을 기억하길 바라지 않고, 환경이 반복하게 둔 셈이다.

여러 세션이 동시에 돌 때는 창을 하나씩 들여다보는 대신, 돌아가는 것·멈춘 것·나를 기다리는 것을 한눈에 보게 했다. 사람이 매번 개입하는 게 아니라, 막힌 곳만 깨우는 쪽에 가깝다.

이때 사람의 역할도 같이 움직인다. 코드를 직접 얼마나 잘 짜는지가 전부가 아니라, AI가 일할 판을 깔고 검증할 구조를 남기는 일이 커진다. 컨텍스트를 주고, 작업을 작게 나누고, 테스트와 리뷰로 안전장치를 만들고, 반복되는 일을 워크플로우로 정리하는 능력이다. 기본기가 덜 중요해지는 게 아니라, 결과를 판단하려면 기본기가 더 필요해진다.

루프는 세 겹으로 돌아간다

에이전트의 반복 작업은 하나의 원으로 설명하기보다 세 겹으로 나눌 때 이해하기 쉽다.

1. 바깥 루프는 일감을 발견한다. 스케줄, 이벤트, 세션 상태 감시가 지금 처리할 일을 찾고 실행을 시작한다. 승인 대기가 보이면 사람에게 넘긴다.
2. 안쪽 루프는 목표에 수렴한다. 완료 기준에 도달할 때까지 작은 작업과 검증을 반복한다. 조건이 맞을 때까지 기다렸다가 다음 단계로 넘어가기도 한다.
3. 개선 루프는 다음 실행을 바꾼다. 지난 실패와 성공을 보고 스킬, 훅, 검증 기준을 고친다.

바깥 루프가 일감을 가져오면 안쪽 루프가 해결한다. 그 결과는 개선 루프를 거쳐 다음 실행의 입력이 된다. 세 루프는 서로 다른 방법론이 아니라 같은 시스템의 다른 시간대다.

좋은 루프에는 일곱 가지가 필요하다

루프를 설계한다는 것은 에이전트를 무한히 반복시키는 일이 아니다. 다음 일곱 가지에 답하는 일이다.

요소	정해야 하는 것
Trigger	무엇이 실행을 시작하는가
Context	시작 전에 무엇을 읽어야 하는가
Boundary	한 번에 어디까지 바꿀 수 있는가
Verification	성공을 어떤 신호로 판단하는가
Stop	완료·실패·예산 초과 시 언제 멈추는가
State	다음 실행에 무엇을 남길 것인가
Improve	반복 결과로 어떤 규칙을 개선할 것인가

이 중 하나라도 빠지면 루프가 불안정해진다. 맥락이 없으면 매번 처음부터 추측하고, 경계가 없으면 작은 문제가 큰 수정으로 번진다. 검증이 없으면 결과가 맞는지 알 수 없고, 종료 조건이 없으면 같은 실패를 오래 반복한다. 상태가 없으면 배운 것을 다음 실행에서 다시 잃는다.

내가 채운 빈칸은 대략 이렇다. Trigger는 승인 대기나 “이 일 해줘” 한 줄이고, Context는 세션을 열 때 이미 물리는 규칙·도구다. Boundary는 브랜치 안·원격 밖으로 안 나가기, Verification은 자기신고가 아니라 테스트와 종료 코드, Stop은 타임아웃과 사람 호출, State는 다음에 읽을 메모와 이벤트, Improve는 실패가 반복되면 훅이나 규칙으로 승격하는 일이다. 세 겹 루프는 이 일곱을 시간축으로 나눈 렌즈일 뿐이다.

경계를 문구에만 맡겨 본 적

“원격에 올리지 마”를 프롬프트에 적고, 위험 명령을 문자열로 가로막는 훅도 겹쳐 봤다. 평범한 push는 막혔다. 하지만 에이전트는 훅 경로를 비우는 한 줄로 겹쳐 둔 차단을 동시에 뚫었다. 스크립트 파일 안에 명령을 숨기거나, 토큰을 쪼개 우회하는 방식도 같았다.

그때 배운 건 단순했다. 금지 목록을 키우는 일과 구조적으로 못 나가게 막는 일은 다르다. 에이전트가 “막았다”고 말하는 것보다, 실제로 원격 HEAD가 그대로인지·훅 로그에 뭐가 찍혔는지가 증거다. 클라이언트 쪽 훅만으로는 한계가 있고, 마지막에 남는 건 서버측 거절이거나 권한 자체를 주지 않는 일이다.

자율로 맡겨도 브랜치 밖으로 나가지 않게 하고, 외부 액션은 아예 목표에서 빼 두는 이유도 같다. 경계는 문구가 아니라 blast radius다.

그래서 지금은 클라이언트 금지만 믿지 않는다. 애초에 원격 push 권한을 주지 않거나, 서버에서 거절되게 닫는다. 금지 문장을 늘리는 대신 나가지 못하는 판을 만든다. 다만 감시는 여전히 허술해서, 신호가 애매하면 가끔은 그냥 창을 연다.

에이전트가 똑똑해서 안전한 것이 아니라 실수해도 크게 번지지 않는 구조라서 안전한 것이다.

판단까지 전부 위임하지는 않는다

루프는 실행량을 늘려주지만 무엇을 남길 가치가 있는지까지 자동으로 결정하지 않는다.

에이전트가 만든 코드나 문서는 동작 여부와 별개로 사람이 설명할 수 있어야 한다. 변경 범위는 작아야 하고, 취향과 품질 기준은 테스트와 체크리스트로 표현해야 한다. 특히 장기간 유지할 코드라면 API, 타입, 실패 처리, 통합 경계는 사람이 직접 소유해야 한다.

검증도 가능하면 생성과 분리하는 편이 낫다. “끝났다”는 자기신고보다, 프로세스 exit code나 테스트 통과처럼 밖에서 관측되는 신호로 완료를 판정하는 쪽이 덜 흔들린다. 코드를 만든 에이전트의 설명을 그대로 성공 신호로 쓰지 않고, 빌드·테스트·실제 화면처럼 독립적인 결과로 판단해야 한다.

같은 이유로, 매번 “상태 올려줘”를 프롬프트에 넣기보다 도구 호출 순간에 상태가 갱신되게 훅을 심어 두기도 한다. 기억에 기대지 않고 설치물에 맡기는 일이다. 한두 번 좋은 답을 얻는 것과 계속 안정적으로 좋은 결과를 얻는 것은 다르다. 후자에는 문서, 테스트, 되돌릴 수 있는 구조가 필요하다.

사람은 지시자에서 루프 설계자로 이동한다

에이전트 활용이 발전할수록 사람이 매번 개입해야 하는 지점은 줄고, 대신 처음에 설계해야 하는 기준은 선명해진다.

1. 사람이 매번 프롬프트한다.
2. 사람이 목표를 주면 에이전트가 도구를 사용한다.
3. 사람이 완료 기준을 주면 에이전트가 반복해서 수렴한다.
4. 사람이 루프를 설계하면 루프가 일감을 발견하고 처리한다.

마지막 단계에서 사람의 역할은 일을 하나씩 지시하는 사람에서, 검증 가능한 시스템의 방향을 정하는 사람으로 바뀐다. 나는 창마다 따라다니기보다, 여러 세션을 쓸고 막힌 신호만 받는 쪽에 더 기대게 됐다.

결국 좋은 에이전트는 오래 일하는 에이전트가 아니다. 스스로 틀렸음을 발견하고, 적절한 순간에 멈추며, 다음에는 같은 실수를 덜 하도록 기록하는 에이전트다. 프롬프트는 그 루프 안에서 중요한 입력이지만, 루프 자체를 대신할 수는 없다.