이제 프롬프트보다 중요한 건 루프다

Lead: AI를 잘 쓰는 사람과 못 쓰는 사람의 차이가 “프롬프트 문장력”이라고 생각하기 쉽다. 그런데 2026년의 흐름은 조금 다르다. 진짜 차이는 AI가 멈춰야 할 때 멈추고, 틀리면 다시 고치고, 결과가 검증될 때까지 반복하는 루프를 설계할 수 있느냐에서 나온다.

TL;DR

• 에이전트의 기본 루프는 단순하다. model → tools → context → repeat다.
• 어려운 것은 프롬프트가 아니라 언제 멈출지, 무엇을 검증할지, 어떤 컨텍스트를 버릴지다.
• 앞으로의 AI 유틸리티는 “한 번 답하는 도구”보다 “목표가 충족될 때까지 검증하며 도는 작은 루프”가 더 강하다.
• invoice, email, SEO, 문서 처리 같은 유틸은 verifier gate를 붙일 때 단순 생성기에서 작업 루프로 진화한다.

프롬프트의 시대가 끝났다는 뜻은 아니다

프롬프트는 여전히 중요하다. 문제는 프롬프트만으로 제품을 만들 수 있는 시기가 빠르게 지나가고 있다는 점이다.

초기 AI 사용법은 대체로 이랬다.

좋은 질문을 쓴다 → 좋은 답을 받는다

하지만 실제 업무는 이렇게 끝나지 않는다.

목표를 정한다 → 도구를 실행한다 → 실패를 본다 → 고친다 → 다시 검증한다 → 통과하면 멈춘다

이 차이가 바로 loop engineering의 핵심이다.

프롬프트는 한 번의 요청을 좋게 만든다.
루프는 일이 끝날 때까지 시스템이 스스로 움직이게 만든다.

에이전트 루프는 생각보다 단순하다

클리핑 자료에서 소개된 기본 구조는 거의 여섯 줄짜리다.

while True:
    response = model(context)
    if response.has_tool_calls():
        results = run_tools(response.tool_calls)
        context += results
    else:
        break

모델이 컨텍스트를 읽고, 도구를 부르고, 결과가 다시 컨텍스트에 들어간다. 이걸 반복한다.

여기까지는 어렵지 않다. 대부분의 에이전트 프레임워크가 비슷한 구조에 도달한다. 그래서 경쟁력은 while True 자체가 아니라 그 바깥에서 생긴다.

• 어떤 도구를 줄 것인가
• 언제 멈추게 할 것인가
• 실패를 어떻게 감지할 것인가
• 컨텍스트가 썩기 전에 무엇을 압축하거나 버릴 것인가
• 최종 결과를 누가 검증할 것인가

이게 제품의 실력이 된다.

가장 흔한 실패: 턴이 끝났는데 일을 끝냈다고 착각한다

에이전트가 답변을 멈췄다고 해서 일이 끝난 것은 아니다.

코딩 에이전트를 예로 들면 더 분명하다.

• 파일을 수정했다.
• 테스트를 조금 돌렸다.
• 뭔가 나아진 것 같다.
• “완료했습니다”라고 말한다.

그런데 전체 테스트는 아직 깨져 있을 수 있다. 빌드는 실패할 수 있다. 실제 페이지는 200을 반환하지만 홈페이지 fallback일 수 있다.

블로그 게시 작업만 봐도 이 원칙은 분명하다. 워크플로에 게시 요청을 넣었다고 해서 게시가 끝난 게 아니다. 실제 live URL의 HTML/DOM에 제목이나 slug가 있어야 하고, 블로그 인덱스에 카드가 보여야 한다.

에이전트의 종료 메시지는 task completion이 아니라 turn completion이다.

그래서 좋은 루프에는 항상 completion check가 필요하다.

나쁜 완료 조건: 에이전트가 완료했다고 말함
좋은 완료 조건: 테스트 통과, 빌드 통과, live DOM 검증, 콘솔 에러 0, 소스 링크 렌더링

verifier가 없으면 그냥 AI를 믿는 것이다

요즘 좋은 agent workflow에는 점점 verifier가 붙는다.

builder가 코드를 만들고, checker가 테스트와 lint를 돌린다. writer가 초안을 만들고, reviewer가 구조·출처·SEO·톤을 확인한다. publisher가 배포하고, watchdog이 live DOM을 본다.

이 구조가 중요한 이유는 간단하다.

생성자는 낙관적이고, 검증자는 냉정해야 한다.

하나의 모델에게 “만들고 스스로 검증해”라고 시킬 수도 있다. 하지만 시스템으로 보면 역할을 분리하는 편이 더 안정적이다.

역할	해야 할 일	실패하면
Builder	결과물을 만든다	빠르게 수정한다
Verifier	기준에 맞는지 본다	거절하고 증거를 요구한다
Orchestrator	다음 행동을 정한다	scope를 줄이거나 사람에게 올린다

이게 작은 팀처럼 돌아가는 에이전트 운영의 기본형이다.

컨텍스트는 양동이가 아니라 예산이다

긴 에이전트 세션은 똑똑해지기보다 종종 멍청해진다. 이유는 context rot이다.

처음에는 필요한 정보만 있다. 그런데 시간이 지나면 다음이 쌓인다.

• 오래된 로그
• 실패한 시도
• 다시 볼 필요 없는 검색 결과
• 지나치게 긴 터미널 출력
• 이미 폐기된 가설

모델은 이 모든 것을 읽고 다음 결정을 내려야 한다. 그러면 판단이 흐려진다.

그래서 loop engineering은 context engineering과 붙어 있다. 좋은 루프는 정보를 무한히 보관하지 않는다.

• 큰 출력은 파일로 빼고 필요한 slice만 읽는다.
• 탐색 작업은 subagent에게 맡기고 요약만 받는다.
• 오래된 시도는 압축한다.
• 검증 기준은 짧고 선명하게 유지한다.

Claude Code의 subagent 글이 말하는 핵심도 여기에 있다. 메인 세션에 모든 grep/find/log를 쌓지 말고, 별도 창에서 조사한 뒤 깨끗한 결론만 가져오는 것이다.

실전 활용 팁: 유틸은 계산기에서 루프로 진화한다

AI 유틸을 만들 때 당장 중요한 것은 거창한 AI 플랫폼을 만드는 게 아니다.

작은 유틸 하나하나에 이런 질문을 넣는 것이다.

이 도구의 완료 조건은 무엇인가?
사용자가 믿어도 되는지 어떻게 검증할 것인가?
실패했을 때 어떤 다음 행동을 제안할 것인가?
반복 사용 이유가 있는가?

예를 들어 invoice generator는 단순히 invoice를 만드는 데서 끝나지 않는다.

• 필수 필드 누락 검사
• 세금/통화 형식 검증
• PDF 다운로드 확인
• 이메일 문구 생성
• 결제 요청 follow-up reminder 생성

이메일 유틸도 마찬가지다.

• 답장 초안 생성
• 톤 검사
• 빠진 질문 체크
• action item 추출
• follow-up 일정 제안

SEO 유틸이라면 이런 루프가 가능하다.

• 제목 생성
• SERP 의도와 맞는지 검사
• meta description 길이 확인
• 중복 keyword stuffing 감지
• 최종 publish checklist 제공

이건 거대한 SaaS가 아니어도 된다. 오히려 작은 유틸에서 더 빨리 테스트할 수 있다.

바로 해볼 실험

이번 주 바로 만들 수 있는 실험은 세 가지다.

1. “AI 결과 검증 체크리스트”를 모든 유틸 하단에 붙이기

결과만 주지 말고, 사용자가 직접 확인할 수 있는 3~5개 체크를 제공한다.

Before you use this result:
- 금액/날짜/통화를 확인했나요?
- 상대방 이름이 맞나요?
- 법적/세무 조언이 필요한 부분은 전문가에게 확인해야 하나요?

2. Repo Preflight Checker 만들기

오늘 GeekNews의 가짜 VC 공격 사례와도 연결된다. 낯선 저장소를 실행하기 전에 다음을 체크하는 개발자 유틸이다.

• postinstall script
• patch-package
• lockfile 이상 변경
• binary/blob 파일
• 난독화된 코드
• env exfiltration 의심 패턴

이건 개발자 대상 SEO 키워드도 좋고, “신뢰 유틸” 포지션에도 잘 맞다.

3. Goal-based utility UX 테스트

폼 버튼을 Generate가 아니라 Generate and check로 바꿔본다.

작은 문구지만 제품 철학이 달라진다.

Generate → 한 번 만들어줌
Generate and check → 쓸 수 있는 상태까지 확인함

리스크 / 반론

물론 모든 유틸을 루프로 만들 필요는 없다.

간단한 계산기나 변환기는 빠른 응답이 더 중요하다. 루프를 억지로 넣으면 느리고 복잡해진다.

그래서 기준은 이렇다.

• 결과가 틀리면 사용자가 손해를 보는가?
• 사용자가 반복적으로 수정해야 하는가?
• 검증 기준을 자동화할 수 있는가?
• 결과를 다음 행동으로 이어줄 수 있는가?

이 네 가지 중 두 개 이상이 맞으면 loop형 유틸로 업그레이드할 가치가 있다.

결론

AI 제품의 다음 경쟁력은 더 화려한 답변이 아니다.

일을 끝내는 구조다.

프롬프트는 시작점이고, 컨텍스트는 연료이며, 도구는 손발이다. 하지만 루프가 없으면 AI는 한 번 말하고 멈춘다. verifier가 없으면 맞는지 모른다. completion check가 없으면 끝났는지 모른다.

AI 유틸리티가 2026년에 더 강한 제품이 되려면, 작은 도구들부터 이 철학을 심어야 한다.

좋은 AI 유틸은 답을 생성하지 않는다.
사용자가 믿고 다음 행동을 할 수 있는 상태까지 데려간다.