대부분의 엔지니어링 워크플로우는 LLM(대규모 언어 모델)을 상태가 없는(stateless) 계산기로 취급합니다. 프롬프트를 입력하고, 스니펫을 복사하고, 탭을 닫아버리는 식이죠. 세션이 종료되면 컨텍스트(context)는 증발하며, 모델의 반복적 추론 능력(iterative reasoning capacity) — 아마도 모델의 가장 강력한 기능일 것 — 은 완전히 활용되지 못한 채 버려집니다.

이는 낭비입니다. 일회성 답변을 위해 사용하는 동일한 모델을 — 잘 설계된 프롬프트 하나만으로 — 목표를 분해하고, 단계별로 수행하며, 자신의 출력을 평가하고, 사용자가 다시 키보드를 만질 필요 없이 스스로 경로를 수정하는 에이전트(agent)로 재구성할 수 있습니다. 프레임워크 설치도 필요 없고, API 오케스트레이션(orchestration)도 필요 없습니다. 단지 모델을 단일 패스 생성(single-pass generation)에서 자기 수정 루프(self-correcting loop)로 전환하는 프롬프트 아키텍처(prompt architecture)만 있으면 됩니다.

이 가이드는 해당 에이전트를 처음부터 구축하는 과정을 안내합니다. 15분, ChatGPT 또는 Claude 창 하나, 그리고 코드 한 줄 없이 가능합니다.

여기서 "자율 실행(Self-Running)"이 실제로 의미하는 것

용어를 정확하게 짚고 넘어갑시다. AI 에이전트 분야는 모호한 마케팅 용어들로 넘쳐나고 있기 때문입니다.

이 문맥에서 "자율 실행(self-running)" AI 에이전트란, 일반적인 프롬프트가 하지 못하는 세 가지를 수행하는 프롬프트 기반 시스템을 의미합니다. 즉, 목표를 하위 작업(sub-tasks)으로 **분해(decomposes)**하고, 해당 하위 작업들을 순차적으로 **실행(executes)**하며, 각 단계 이후 자신의 출력을 **평가(evaluates)**하여 결과가 미흡할 경우 접근 방식을 수정합니다.

이것이 유일한 차이점입니다. 표준 프롬프트는 사용자의 요청에 대해 단 한 번의 패스(pass)를 수행합니다. 에이전트 프롬프트는 계획(plan), 실행(act), 평가(evaluate), 조정(adjust)이라는 루프(loop)를 가집니다. 이 루프가 바로 에이전트가 자율적으로 느껴지게 만드는 핵심입니다.

이것이 작동하기 위해 외부 도구는 필요하지 않습니다. 에이전트는 모델 자체의 컨텍스트 윈도우(context window) 내부에서 실행됩니다. 웹을 브라우징하거나 이메일을 보내지는 않습니다 (도구 통합을 명시적으로 제공하는 플랫폼을 사용하지 않는 한). 에이전트가 수행할 일은 복잡한 목표를 받아 체계적으로 밀고 나가는 것입니다. 이를 통해 사용자가 수동으로 네다섯 번의 프롬프트 과정을 거쳐야 했을 결과물을 만들어냅니다.

기초: 최소한의 에이전트 프롬프트

핵심 구조는 다음과 같습니다. 이는 ChatGPT (GPT-4 또는 그 이후 버전), Claude, Gemini, 또는 충분한 추론 능력 (reasoning capability)을 갖춘 모든 모델에서 작동합니다.

당신은 자율적인 AI 에이전트입니다.

## 미션 (Mission)
...

이것이 전부입니다. 단 열 줄뿐입니다. [STATE YOUR GOAL HERE] 플레이스홀더(placeholder)는 실제 목표를 삽입하는 곳이며, 해당 목표의 구체성이 출력 품질의 80%를 결정합니다.

저자의 코멘트: 저는 사람들이 이를

2025년에 출시되었거나 대폭 업데이트된 상위 5개의 오픈 소스 (open-source) AI 에이전트 프레임워크를 식별하세요. 각 프레임워크에 대해 다음을 기록하세요:
(1) 수행하는 역할을 한 문장으로 설명,
...

차이점을 주목하세요. 두 번째 버전은 다음을 명시합니다:

• 범위 (Scope): 상위 5개, 오픈 소스 (open-source), 2025년
• 구조 (Structure): 프레임워크당 4개의 데이터 포인트
• 형식 (Format): Markdown 비교 표
• 종료 조건 (Terminal condition): 5개의 행이 모두 채워지면 표가 완성됨

이제 모델은 정확한 목표를 갖게 되었습니다. 이에 따라 모델의 작업 분해 (task decomposition) 또한 그만큼 정밀해질 것입니다.

실제적인 함정 (Practical pitfall): 주제 (topic)와 미션 (mission)을 혼동하지 마세요. "마케팅 전략"은 주제입니다. 반면 "엔지니어링 매니저를 대상으로 하는 B2B SaaS 제품을 위해, 주간 주기, 채널별 예상 소요 시간, 채널당 추적할 KPI 1개를 포함한 3개 채널 콘텐츠 배포 계획을 수립하라"는 미션입니다. 만약 당신의 목표 문장이 Wikipedia 문서 제목으로도 쓰일 수 있다면, 그것은 너무 광범위한 것입니다.

2단계: 프롬프트를 붙여넣고 분해하게 두기 (2분)

선호하는 모델을 엽니다. 미션이 채워진 전체 프롬프트를 붙여넣으세요. 엔터를 누릅니다.

그다음에 일어나는 일은 계획 (planning) 단계입니다. 모델은 미션을 번호가 매겨진 하위 작업 (sub-tasks)으로 나눌 것이며, 복잡도에 따라 보통 3개에서 8개 사이가 됩니다. 각 하위 작업에는 짧은 근거 (왜 중요한지)와 의존성 노트 (이 단계가 실행되기 전에 무엇이 선행되어야 하는지)가 부여됩니다.

이 단계를 방해하지 마세요. 무엇인가를 평가하기 전에 모델이 전체 분해 과정을 마칠 때까지 기다리세요. 계획 중간에 방해하면 모델이 구조를 포기하고 대화형 응답 패턴으로 돌아가는 경우가 일반적입니다.

다음의 특정 동작을 관찰하세요: 모든 하위 작업을 나열한 후, 프롬프트가 잘 작성된 에이전트는 즉시 작업 1 (Task 1)을 실행하기 시작할 것입니다. 모델은 "계속 진행할까요?"라고 묻지 않을 것입니다. 왜냐하면 지침에 "미션이 완료될 때까지 계속하라"고 명시되어 있기 때문입니다. 만약 모델이 계획을 세운 후 멈춰서 허락을 구한다면, 당신의 미션 문장이 실행을 시작할 만큼 확신을 줄 정도로 구체적이지 않을 가능성이 높습니다.

Step 3: 평가 및 개선 루프(Evaluate-and-Improve Loop) 작동 관찰하기 (5분)

이 단계가 바로 에이전트 프롬프트가 제값을 하는 지점입니다.

모델이 각 하위 작업(sub-task)을 실행한 후, "결과 평가(evaluate results)" 및 "전략 자동 개선(improve the strategy automatically)" 지침이 작동합니다. 모델이 다음과 같은 출력을 생성하는 것을 볼 수 있습니다:

→ 자기 평가(Self-Evaluation): Framework 3의 데이터는 Framework 1 및 2보다 덜 상세합니다. 최신이 아닐 수 있는 파라미터 지식(parametric knowledge)에 의존하고 있습니다. 이 행을 낮은 신뢰도로 표시하고 Framework 4로 진행합니다. 나중에 다시 검토하겠습니다...

이것이 바로 에이전트를 단순한 리스트 생성기(list-generator)와 구분 짓는 동작입니다. 모델은 자신의 출력을 읽고, 품질을 평가하며, 어떻게 진행할지에 대한 전략적 결정(strategic decisions)을 내립니다. 때로는 이전 답변을 수정하기도 하고, 때로는 불확실성을 표시하고 다음으로 넘어가기도 합니다. 두 동작 모두 생산적입니다.

저자의 의견: 자기 평가(self-evaluation) 단계는 에이전트가 실제로 추론(reasoning)을 하고 있는지, 아니면 단지 추론하는 '척'을 하고 있는지를 진단할 수 있는 지점이기도 합니다. 일반적인 평가("현재까지 출력 결과가 좋아 보입니다")와 구체적인 평가("이 데이터 포인트는 출처가 부족합니다")를 구분해서 살펴보세요. 구체적인 평가는 모델이 자신의 작업을 진정으로 비판하고 있음을 나타냅니다. 일반적인 평가는 루프는 돌아가고 있지만 가치를 창출하지 못하고 있음을 의미합니다. 만약 너무 많은 일반적인 평가가 나타난다면, 작업별 지침(per-task instructions)에 다음 문구를 추가하세요: 평가 시 구체적이어야 합니다 — 무엇이 누락되었는지, 약한지, 또는 불확실한지 정확히 식별하세요.

Step 4: 무한 루프 방지를 위한 가드레일(Guardrail) 추가 (2분)

자기 개선 에이전트(self-improving agents)에서 발생하는 실제 실패 모드 중 하나는 에이전트가 가끔 갇혀버리는 현상입니다. 모델이 특정 섹션을 수정하고, 평가하고, 여전히 불완전하다고 판단하여 다시 수정하고, 다시 평가하는 과정을 반복하며 수렴(converging)하지 못한 채 무한히 루프를 돌 수 있습니다.

Step 1에서 만든 구조화된 프롬프트에는 이미 해결책이 포함되어 있습니다: 반복적 개선(Iterative Improvement) 라인에 작업당 최대 2회 반복(max 2 iterations per task)이라는 문구가 들어 있습니다. 만약 더 단순한 자연어 변형(natural-language variant)을 사용하고 있다면, 작업별 지침 블록에 다음 문구를 추가하세요:

• 작업당 자기 개선(self-improvement)을 최대 2회 반복으로 제한하세요.

이 단 하나의 제약 조건이 에이전트에게 명확한 종료 조건(hard exit condition)을 제공합니다. 만약 두 번의 시도 내에 문제를 해결할 수 없다면, 에이전트는 해당 문제를 표시하고 다음 단계로 넘어갑니다.

하지만 무한 루프를 방지하는 것만이 이 제약이 중요한 유일한 이유는 아닙니다. 각 평가 및 재작성(evaluation-and-rewrite) 사이클은 토큰을 소비하며, 종종 반복당 수백 개의 토큰이 소모됩니다. 6개의 하위 작업(sub-tasks)이 포함된 미션의 경우, 반복 횟수 제한을 없애면 토큰 지출이 쉽게 3배까지 늘어날 수 있습니다. 그리고 더 미묘한 문제가 있습니다. 에이전트가 스스로 생성한 텍스트가 컨텍스트 윈도우(context window)에 쌓이면서, 원래 프롬프트에 포함된 중요한 지침들이 모델의 활성 주의 영역(active attention zone)에서 점점 멀어지게 됩니다. "Lost in the Middle" 현상 (Liu et al., 2023)에 관한 연구에 따르면, LLM은 컨텍스트의 시작과 끝 부분에 있는 콘텐츠에 가장 강력하게 주의를 기울이며, 중간에 묻혀 있는 정보에 대해서는 성능이 크게 저하되는 것으로 나타났습니다. 제한 없는 평가 루프는 정확히 이러한 실패 모드(failure mode)를 가속화합니다. 즉, 에이전트 자신의 장황한 자기 비판(self-critique)이 에이전트의 행동을 규정해야 할 미션 제약 조건들을 압도해 버리는 것입니다.

반복 횟수 제한은 단순한 안전장치가 아닙니다. 이는 모델의 주의(attention)를 마땅히 있어야 할 곳에 고정시키는 컨텍스트 위생(context hygiene) 조치입니다.

단계 5: 검토 및 재지시 (3분)

에이전트가 모든 하위 작업을 완료하면, 출력 결과 전체를 검토하세요. 다음 세 가지 사항을 확인해야 합니다.

구조적 완전성(Structural completeness). 에이전트가 미션에서 지정한 모든 구성 요소를 다루었습니까? 만약 5행 테이블을 요청했는데 4행만 생성되었다면, 이는 에이전트가 자기 평가(self-evaluation) 과정에서 잡아냈어야 할 공백입니다. 만약 잡아내지 못했다면, 미션 문구의 종료 조건(terminal condition)이 충분히 명시적이지 않았던 것입니다.

사실적 개연성 (Factual plausibility). 에이전트는 모델의 파라미터 지식 (parametric knowledge, 즉 학습 과정에서 배운 내용)을 바탕으로 작동합니다. 브라우징 기능이 활성화된 플랫폼을 사용하지 않는 한 인터넷 접속 권한은 없습니다. 별의 개수, 출시일, 가격과 같은 모든 "최신" 데이터는 대략적인 것으로 간주해야 하며 수동으로 검증해야 합니다. 에이전트의 역할은 구조화된 초안을 제공하는 것이지, 사실 관계가 확인된 보고서를 작성하는 것이 아닙니다.

추론 품질 (Reasoning quality). 최종 출력물뿐만 아니라 자기 평가 (self-evaluation) 노트를 읽어보세요. 만약 에이전트가 자신의 분석에서 약점을 지적했다면, 이는 사용자가 수동으로 검토할 때 유용한 신호가 됩니다.

특정 섹션을 개선해야 한다면 프롬프트 전체를 다시 실행할 필요는 없습니다. 모델에게 다음과 같이 말하기만 하면 됩니다: "작업 3(Task 3)을 수정해줘. 프레임워크 2에 대해 나열된 한계점이 너무 일반적이야. 해당 프레임워크의 GitHub 이슈에 기록된 구체적인 기술적 제약 사항을 식별해줘." 그러면 에이전트는 그 지점부터 작업을 이어갈 것입니다.

지금 바로 실행할 수 있는 세 가지 미션

에이전트 프롬프트를 즉시 테스트하고 싶다면, 일관되게 강력한 결과를 생성하며 이 가이드의 부제에서 언급된 워크플로와 직접적으로 연결되는 네 가지 미션이 여기 있습니다:

미션 1 — 이메일 분류 (Email triage):

나는 하루에 약 40개의 업무 이메일을 받습니다. 수신된 이메일을 다음 네 가지 범주로 분류하는 분류 시스템을 설계하세요:
(1) 오늘 답장이 필요함,
...

미션 2 — 의사결정 분석 (Decision analysis):

새로운 웹 애플리케이션에서 사용자 인증을 구현하는 세 가지 접근 방식인 세션 기반 (session-based), JWT 기반 (JWT-based), 그리고 제3자 제공업체를 이용한 OAuth 2.0을 비교하세요.
...

에이전트의 출력물은 실제로 어떤 모습일까요? 실제 실행 결과에서 발췌한 요약된 스니펫(snippet)은 다음과 같습니다:

에이전트의 출력물은 실제로 어떤 모습일까요? 실제 실행 결과에서 발췌한 요약된 스니펫(snippet)은 다음과 같습니다:

[Task 2 — JWT 기반 인증 평가]
→ 근거: JWT는 상태 비저장형 API에 지배적인 접근 방식입니다. 이 트레이드오프를 이해하는 것이 세션(Session) 또는 OAuth 중 어떤 것이 이 사용 사례에 더 적합한지 결정합니다.
→ 설정 복잡도: 5점 만점에 3점 — 토큰 서명, 만료 로직, 그리고 리프레시 토큰 순환 전략을 구현해야 합니다. 서버 측 세션 저장소는 필요하지 않습니다.
→ 보안성: 토큰은 자체 포함적(self-contained)이므로, 손상된 토큰은 블랙리스트를 유지하지 않으면 서버 측에서 취소할 수 없습니다 — 이는 '상태 비저장형' 이점의 일부를 무력화합니다.
→ 확장성: 훌륭한 수평 확장성(공유 세션 상태 없음)을 가지지만, 임베딩된 클레임(claims)에 따라 토큰 크기가 커집니다.
→ 최적 시나리오: 중앙 집중식 세션 저장소 없이 서비스들이 독립적으로 신원을 검증해야 하는 마이크로서비스 아키텍처.
→ 자체 평가: 보안 분석은 장기간 유지되는 액세스 토큰의 특정 위험을 간과했습니다. 별도의 리프레시 토큰 흐름을 통해 액세스 토큰 TTL(Time To Live)이 15분 이하가 되어야 함을 명시하도록 수정합니다.

마지막 자체 평가에 주목하세요 — 에이전트가 스스로의 허점을 포착하고 Task 3으로 넘어가기 전에 수정한 것입니다. 이것이 바로 루프(loop)가 제 역할을 하는 방식입니다.

미션 3 — 주간 일정 최적화:

저는 반복되는 주간 회의가 6개 있고, 보호하고 싶은 깊은 집중 코딩 시간 2시간과 매일 이메일 처리를 위한 30분 슬롯을 가진 선임 엔지니어입니다. 최적화된 주간 일정 템플릿(월요일부터...)

미션 4 — 연구 합성: