Software Mansion의 Agentic Engineering Guide 요약

이 기사는 riku-kobayashi.jp에 게재한 기사를 전재한 것입니다.

Software Mansion이 Agentic Engineering Guide라는 문서를 공개했습니다. AI 에이전트를 전문적인 소프트웨어 개발에 도입하기 위한 실천적인 지견을 정리한 것으로, 읽어보니 흥미로워서 포인트를 일본어로 정리해 보았습니다.

"Agentic engineering is professional software development with AI agents as active collaborators."

단순한 코드 보완이나 코드 생성이 아니라, AI 에이전트가 리포지토리(Repository)를 자율적으로 탐색하고, 도구를 사용하며, 여러 단계에 걸친 태스크(Task)를 완수하는 개발 스타일을 의미합니다.

중요한 전제로, "성과에 대한 책임은 항상 인간에게 있다"라는 원칙이 강조되고 있습니다. 에이전트에게 모든 것을 맡기는 것이 아니라, 리뷰 가능한 변경 사항, 명확한 프롬프트(Prompt), 품질 관리를 유지하는 것이 전제 조건입니다.

가이드는 두 가지 입구를 제시합니다.

패스 A — 신규 프로젝트

제로 베이스에서 에이전트와 함께 프로젝트를 시작합니다. 기술 스택에 대한 지식이 없어도 문제없으며, 아이디어 검증부터 초기 구현까지 일관되게 진행할 수 있습니다.

패스 B — 기존 프로젝트

이미 돌아가고 있는 코드베이스에 참여하는 경우입니다. 미지의 시스템을 빠르게 이해하고, 외과적인 변경을 가하는 용도로 활용합니다.

공통적으로 강조되는 점은 "읽는 것만으로는 습득할 수 없다"는 점입니다. 실제로 프롬프트를 작성하고, 차이(Diff)를 확인하며, 에이전트의 오류를 추적하고, 수정을 요청하는 사이클을 반복해야 비로소 몸에 익게 됩니다.

매일의 개발에서 에이전트를 능숙하게 다루기 위한 실천적인 패턴을 다룹니다. 가이드의 핵심이 되는 절입니다.

대화의 단위를 **스레드(Thread)**라고 부르며, 이상적인 1스레드는 5단계로 완결됩니다.

가이드가 꼽는 주요 제약 사항은 6가지입니다.

제약	내용
지식의 노후화	학습 시점 이후의 API 변경 등은 알지 못함
...

코드를 작성하게 하기 전에, 먼저 기획서를 만들게 합니다. 문제, 기대하는 결과, 하지 않을 것, 선택지, 미해결 의문점을 포함하는 짧은 문서입니다. 이를 통해 에이전트가 의도를 이해하고 있다는 착각을 방지할 수 있습니다.

답을 주는 것이 아니라, 에이전트가 스스로 결론에 도달할 수 있도록 질문을 던집니다. "이 가정은 항상 성립하는가?", "에지 케이스(Edge case)에서는 어떻게 되는가?"와 같은 질문이 유효합니다.

의도적으로 정보를 적게 줌으로써, 에이전트가 독자적으로 깊게 탐색하게 합니다. 문서의 누락을 발견하는 부수적인 효과도 있습니다.

채팅 이력에는 남지 않습니다. 사실이나 결정 사항은 AGENTS.md나 리포지토리 내의 Markdown에 기록하여 정보원으로서 기능하게 합니다.

테스트를 먼저 작성하여 실패를 확인한 뒤 구현하게 하는 사이클은, 불필요한 코드 생성을 줄이고 테스트 스위트(Test suite)를 견고하게 만듭니다.

계획을 Markdown 파일로 정리하여 커밋한 뒤 구현을 시작합니다. 실패했을 때 계획 단계로 돌아갈 수 있어 무의미한 재계획이 줄어듭니다.

압축 및 컴파일된 코드를 해석하는 것은 에이전트의 특기 분야입니다. 모방하고 싶은 웹사이트나 Android APK를 에이전트에게 전달하면, 필요한 도구를 스스로 선택하며 해석을 진행합니다.

여러 가지 해결책이 생각날 때, git worktree 등을 사용하여 여러 에이전트에게 동시에 구현하게 하여 비교합니다. 인터페이스 설계 등 창의적인 작업에 특히 유효합니다.

프롬프트만 다듬는 것이 아니라, 에이전트를 둘러싼 도구, 지시, 컨텍스트(Context) 전체를 설계하는 접근 방식입니다. 가이드에서는 5가지 수단을 소개하고 있습니다.

리포지토리 내에서 에이전트를 조종하기 위한 가장 경량적인 방법입니다. 다음과 같은 내용을 작성하면 효과적입니다.

• 에이전트가 추측할 수 없는 Bash 명령어
• 테스트 러너(Test runner)의 설정 및 실행 방법
• 브랜치(Branch) 명명 등 리포지토리의 규칙
• 아키텍처상의 결정 사항이나 비자명한 동작

반대로 작성해서는 안 되는 것은, 코드에서 읽을 수 있는 정보나 변경 빈도가 높은 내용입니다.

Claude Code에서는 AGENTS.md가 기본적으로 읽히지 않습니다. Claude Code를 사용하는 경우에는 CLAUDE.md가 그에 해당하는 파일입니다. AGENTS.md는 OpenAI Agents SDK나 GitHub Copilot Workspace 등 다른 에이전트를 위한 관례입니다.

반복해서 사용하는 도메인 지식이나 워크플로우를 패키지화한 것. SKILL.md를 포함하는 디렉토리로 구현하며, 에이전트가 명시적으로 읽어들이는 방식으로 사용합니다. 복잡한 규칙 정의나 특정 툴체인(Toolchain)의 문서화에 적합합니다. 또한, 서드파티(Third-party) 스킬은 업데이트 시 반드시 소스를 리뷰해야 합니다(악의적인 변경이 혼입될 리스크가 있습니다).

외부 서비스(Linear, Figma, Slack 등)에 대한 인증된 액세스가 필요할 때 사용합니다. 다만, MCP(Model Context Protocol) 툴의 정보는 모두 시스템 프롬프트(System Prompt)에 주입되므로, 수가 너무 많아지면 에이전트의 능력이 저하됩니다. gh CLI로 대체할 수 있는 GitHub MCP 등, CLI로 충분한 경우에는 사용하지 않는 것이 상책입니다.

메인 에이전트가 제한적이고 병렬화 가능한 태스크를 다른 에이전트에게 위임하는 메커니즘입니다. 긴 대화에서 축적된 탐색 노트나 실패한 시도가 메인 스레드를 압박하는 것을 방지하고, 컨텍스트(Context)를 분리하는 것이 주요 목적입니다.

매번 반드시 실행해야 하는 로직은 모델에게 기억시키는 것이 아니라 훅(Hooks)에 맡깁니다. 코드 포맷팅(Code Formatting), 린터(Linter) 실행, 민감한 명령 실행 전의 승인 등이 전형적인 예입니다. 훅(Hooks)은 판단이 필요 없는 기계적인 처리에 사용하고, 판단이 필요한 것은 지시사항(Instruction)으로 작성하는 것이 설계의 기본입니다.

수단	사용 시점
AGENTS.md / CLAUDE.md	동일한 정보를 매번 프롬프트에 쓰고 있을 때
...

에이전트가 자율적으로 문제를 진단하고 수정할 수 있게 하려면, 적절한 피드백 루프(Feedback Loop)를 마련해야 합니다.

버그를 발견하면 먼저 재현 테스트를 작성한 뒤에 수정하게 하세요. 다만, 에이전트가 작성하는 테스트는 방금 막 수정한 버그만을 통과시키는 식의 너무 지엽적인 검증이 되기 쉽습니다. 겉보기에는 테스트가 늘어난 것 같아도, 다른 곳에서 동일한 문제가 발생했을 때 알아차리지 못할 수 있습니다. 그러한 허점이 있다는 점을 의식하며 리뷰해야 합니다.

앱의 로그를 *.log 파일로 출력하도록 설정해 두면, 에이전트가 런타임(Runtime) 동작을 확인할 수 있습니다. 또한 psql이나 sqlite3로 데이터베이스에 직접 액세스할 수 있는 환경을 갖춰 두면 에이전트의 조사 능력이 크게 향상됩니다.

에이전트는 CLI를 통해 환경을 조작합니다. 에이전트가 사용하기 좋은 CLI 설계 원칙은 다음과 같습니다.

• 비대화형화(Non-interactive) — 모든 입력을 플래그(Flag)로 전달할 수 있도록 함
• 도움말 강화 — 서브 커맨드에 실행 예시를 포함하는 --help를 충실히 제공함
• stdin 수용 — 파이프라인(Pipeline)에서 사용할 수 있도록 함
• 빠른 실패(Fail Fast) — 에러 메시지를 명확히 함
• 멱등성(Idempotency) 유지 — 동일한 명령을 몇 번 실행해도 결과가 변하지 않도록 함
• 파괴적 작업의 사전 확인 — --dry-run을 준비하여 파괴적인 조작을 미리 확인할 수 있게 함
• 확인 프롬프트 스킵 — --yes 플래그를 통해 확인 프롬프트를 건너뛸 수 있게 함
• 일관된 구조 — resource + verb와 같은 패턴을 준수함

프론티어 모델(Frontier Model)은 브라우저 조작도 능숙합니다. Cursor Browser나 Claude in Chrome 등의 도구를 사용하면 UI QA를 에이전트에게 맡길 수 있습니다. 여러 에이전트를 병렬로 구동할 경우에는 인스턴스마다 서로 다른 포트(Port)를 할당하십시오.

시뮬레이터를 사용한 모바일 앱 테스트도 자동화할 수 있습니다. Argent(Software Mansion 제작)나 Radon AI 등의 도구가 이를 지원합니다.

에이전트를 실용적으로 만드는 도구군(파일 액세스, 코드 실행, 네트워크 통신)은 제어가 불충분할 경우 데이터 유출이나 악의적인 조작의 통로가 될 수 있습니다. 능력을 배제하는 것이 아니라, 능력을 적절히 관리하는 것이 에이전트 보안의 기본적인 사고방식입니다.

하나의 에이전트가 다음 세 가지를 동시에 가지면 공격 표면(Attack Surface)이 단번에 넓어집니다.

조건	구체적인 예
프라이빗 데이터에 대한 액세스	독자적인 코드베이스나 로컬 시스템
...

이 중 하나만 제거해도 리스크는 크게 줄어듭니다. 다만, 코딩 에이전트는 현실적으로 이 세 가지 중 적어도 두 가지를 갖는 경우가 많아 완전한 격리는 어렵습니다. 또한, 공격자는 외부인에 국한되지 않습니다. 부주의한 동료나 방치된 프로세스도 동일한 리스크입니다.

• 공격자가 작성한 Issue가 과도한 권한을 가진 AI 워크플로우를 실행하여 캐시 포이즈닝 (Cache Poisoning) 2와 악의적인 패키지 공개로 이어짐
• 승인 없이 Terraform 명령어를 실행할 수 있는 상태의 에이전트가 프로덕션 인프라를 삭제함
• 악의적인 리포지토리의 Issue가 에이전트를 유도하여, 자동 생성된 풀 리퀘스트 (Pull Request)를 통해 프라이빗 데이터가 유출됨

퍼미션 (인간의 승인 게이트)

쓰기, 네트워크 호출, 파괴적인 작업에 대해 인간의 승인을 거치도록 한다. 읽기는 기본적으로 자유롭게 허용한다. 다만 패턴 매칭의 한계가 있으며, 사용자 경험(UX) 측면에서 마찰이 발생할 수 있다.

신뢰할 수 있는 워크스페이스 (Trusted Workspace)

에이전트를 세이프 모드 (Safe Mode)로 실행하여, 프로젝트 레벨의 설정 파일이나 잠재적으로 악의적인 설정의 로드를 거부한다.

샌드박스 (Sandbox)

OS/런타임 레벨에서 경계를 설정하여, 파일 시스템 쓰기를 워크스페이스 디렉토리로 제한하고, 민감한 경로를 보호하며, 프로세스 실행을 제한한다.

네트워크 액세스 제한

기본적으로 네트워크를 비활성화하고, 라이브 브라우징 대신 캐시된 검색 결과를 사용하여 프롬프트 인젝션 (Prompt Injection) 3에 대한 노출을 줄인다.

Hooks

프로젝트 고유의 보안 정책을 Hooks로 구현한다. 예를 들어 특정 셸 (Shell) 명령어를 차단하는 방식이다.

이러한 보호 조치들은 모두 무효화할 수 있다 (이른바 YOLO 모드 4). 권장되는 접근 방식은 먼저 기본 보호 기능을 활성화한 상태에서 시작하고, 워크플로우의 요구사항과 위협 평가에 따라 선택적으로 조정해 나가는 것이다. 보안과 편의성은 트레이드오프 (Trade-off) 관계이지만, 기본 보호 상태를 유지하며 작업할 수 있다면 이를 유지하는 것이 현명하다.

한 명의 인간이 여러 에이전트를 병렬로 제어하는 것이 생산성 향상의 핵심이다. git worktree를 사용하여 각 에이전트에게 독립적인 체크아웃 (Checkout)을 부여하면 충돌을 방지할 수 있다.

"모델은 태스크 완료 시 보상을 얻도록 훈련되어 있으며, 장기적인 아키텍처 책임을 지지 않는다"는 인식이 중요하다. 이에 대한 대책은 다음과 같다:

• 작고 경계가 명확한 모듈 설계— 「인증·DB·비즈니스 로직·UI」를 각각 독립된 모듈로 나누어, 에이전트가 하나의 태스크에서 다루는 범위를 제한한다. 거대한 utils.ts에 모든 것이 혼재되어 있으면, 에이전트는 무관한 함수까지 수정하려 드는 경향이 있다.
• 타입과 테스트를 통한 불변 조건 강제— 예를 들어 UserId를 string이 아니라 type UserId = string & { _brand: "UserId" }와 같이 브랜드 타입 (Branded Type)으로 설정해 두면, 에이전트가 실수로 생 문자열을 전달했을 때 컴파일 에러를 통해 인지할 수 있다. 테스트도 마찬가지로 "이 함수는 반드시 X를 반환한다"라는 사양을 테스트로 명문화해 두면, 에이전트가 망가뜨렸을 때 즉시 탐지할 수 있다.
• 에이전트용 린터 (Linter)와 CI— ESLint나 Biome의 규칙을 CI에 포함시켜, 에이전트의 PR이 머지 (Merge)되기 전에 자동으로 체크되는 메커니즘을 만든다. 에이전트는 CI를 통과하면 완료되었다고 판단하므로, CI가 엄격할수록 품질이 안정된다.
• 리포지토리 내 지식 관리— AGENTS.md나 docs/decisions/에 아키텍처상의 결정 사항이나 금지 사항을 적어둔다 (예: "이 프로젝트에서는 클래스를 사용하지 않는다", "외부 API 호출은 반드시 src/lib/api/를 경유한다"). 에이전트는 매번 처음부터 문맥을 읽으므로, 코드보다 먼저 이 파일들을 읽도록 지시하면 일관성을 유지할 수 있다.

구현과 병행하여 리뷰를 실행하면 인간 리뷰어의 부담을 줄일 수 있다. 다만 완전 자동화가 아니라, 적절한 컨텍스트 (Context)를 제공하는 것이 핵심이다.

1. 한 스레드에 여러 책임을 부여하지 말 것

스레드에는 하나의 태스크만 부여하자. 책임이 늘어날수록 집중력이 분산된다.

2. 모델의 기억력을 신뢰하지 말 것

모델은 학습 데이터에 의존한다. 관련 문서나 소스 코드를 그때마다 제시하자.

3. 가정을 쌓아 올리지 말 것

각 단계를 확인하며 진행하자. 인간이 실행하지 않은 코드와 마찬가지로 위험하다.

4. 묵묵히 따르는 것을 허용하지 말 것

에이전트에게 "의문이 있으면 질문하기", "이상하다고 생각되면 지적하기" 권한을 부여하자.

5. 스레드가 망가질 때까지 계속 사용하지 말 것

새로운 태스크는 새로운 스레드에서 시작하는 것이 성능이 저하된 스레드를 디버깅하는 것보다 항상 비용이 적게 듭니다.

6. 질문에 해결책을 포함시키기

"〇〇하는 방법을 알려줘"가 아니라 "여러 가지 접근 방식을 탐색해줘"라고 지시한 뒤, 그 후에 선택지를 평가하게 하세요.

7. 첫 번째 안을 최종안으로 간주하지 말 것

여러 번의 시도와 인간의 리뷰를 전제로 하세요.

더 깊은 멘탈 모델(Mental Model)과, 에이전트를 조직 및 자동화 규모로 운용하기 위한 발전적인 주제를 다룹니다. 옵션 사항이지만, 규모를 확장하고 싶은 사람에게는 특히 참고가 됩니다.

여기까지는 한 명의 엔지니어가 하나의 에이전트를 조작하는 맥락이었습니다. 가이드의 후반부에서는, 여러 에이전트를 동시에 실행하는 단계로의 전환을 다룹니다. 질문이 "에이전트에게 무엇을 시킬 것인가"에서 "어떻게 에이전트 군단을 관리할 것인가"로 바뀝니다.

독립된 태스크를 여러 에이전트 세션에서 동시에 실행합니다. 각 에이전트는 git worktree를 통해 독립된 체크아웃(Checkout)을 가지며, 서로 간섭하지 않습니다. 인간은 각각의 세션을 실시간으로 모니터링하는 것이 아니라, 출력을 모아서 비동기적으로 리뷰합니다.

참고로 이는 서브 에이전트(Sub-agent, 부모 에이전트가 자식 에이전트를 생성하여 컨텍스트를 분할하는 메커니즘)와는 다른 개념입니다. 병렬 에이전트는 각각이 독립된 태스크를 가집니다.

병렬 에이전트 (인간이 관리)

서브 에이전트 (에이전트가 관리)

에이전트를 cron 잡(Job)이나 CI 파이프라인(Pipeline)처럼 정기적으로 실행할 수 있습니다. 전형적인 유스케이스는 다음과 같습니다.

• 매일의 Issue 트리아지 (Triage)
• CI 실패 요약 생성
• 릴리스 노트 초안 작성
• 회귀(Regression) 탐지

사람이 호출할 때만 작동하는 도구에서 스케줄에 따라 스스로 움직이는 프로세스로. 실행 결과는 자동으로 저장되거나, 리뷰 대기 상태로 알림이 전송됩니다.

AI가 Issue 보드를 감시하며, 관련 있는 Issue에 대해 자동으로 에이전트를 기동하는 패턴입니다. 에이전트는 CI 결과, PR 피드백, 복잡도 분석 등의 근거를 수집하여, 인간이 클로즈(Close)하기 전에 리뷰할 수 있는 형태로 제시합니다. 워크플로우 정의는 코드와 동일한 리포지토리(Repository)에서 버전 관리됩니다.

여러 에이전트의 협업에는 두 가지 주요 패턴이 있습니다.

Hub-and-spoke: 리드 에이전트(Lead Agent)가 워커(Worker)를 생성하고, 출력을 수집하여 집약합니다. 단순하지만, 중간의 상세 내용이 쌓이면서 리드의 컨텍스트가 저하될 위험이 있습니다.

협업 티밍 (Collaborative Teaming): 에이전트가 태스크 리스트를 공유하고, 각자가 독립적으로 태스크를 맡아 직접 통신합니다. 리드의 컨텍스트를 깨끗하게 유지할 수 있지만, 설계가 복잡해집니다.

협업의 깊이에 따라 구현은 3단계로 분류할 수 있습니다.

레벨	설명
1	독립된 워커가 호출 측에 출력을 반환
...
에이전트가 자율적으로 코드를 작성하여 풀 리퀘스트(Pull Request)를 열고, 다른 리뷰 에이전트가 기계적으로 검증하는 루프입니다.

중요한 주의사항으로, 품질 게이트(Quality Gate)가 견고하지 않다면 자동화하지 않는 편이 낫습니다. 조잡한 PR이 계속해서 자동 머지(Merge)되는 상황은 자동화가 없는 것보다 나쁩니다.

코드 팩토리(Code Factory) 패턴이 성숙해지면, 한 명의 엔지니어가 과거에는 팀 규모가 필요했던 업무를 해낼 수 있게 됩니다. 커뮤니케이션 플랫폼, 스케줄러, 외부 서비스와 연결된 에이전트 군단을 개인이 운용하는 형태입니다.

이러한 변화로 인해, 경쟁 우위는 "직접 코드를 쓰는 속도"보다 "에이전트 군단을 얼마나 잘 지휘할 수 있는가"로 이동하고 있습니다.

에이전트의 활약 무대는 코드 생성에 국한되지 않습니다. 프로젝트 관리나 운영 업무에도 폭넓게 사용할 수 있습니다. 이들 모두에 공통되는 원칙은 에이전트의 출력은 인간이 리뷰한 후에 실행 또는 공개한다는 점입니다.

Issue 트리아지 (Triage)

수신된 Issue의 태그 지정, 중복 탐지, 추가 질문 요청, 심각도에 따른 우선순위 부여를 자동화합니다. 스케줄 실행을 통해 새로운 Issue를 처리하며, 정말로 인간의 판단이 필요한 것만 에스컬레이션(Escalation)합니다.

고객 지원 (Customer Support)

문서나 과거 해결 사례를 바탕으로 반복되는 문의에 대응합니다. 환각(Hallucination) 방지를 위한 리플렉션(Reflection) 메커니즘을 반드시 포함할 것, 그리고 에이전트만으로 티켓을 클로즈하게 하지 말 것(최소한 이의 제기 수단은 남겨둘 것)이라는 점이 가이드에서 강조되고 있습니다.

회의록 작성

회의 녹취록으로부터 결정 사항, 미결 과제, 담당자가 지정된 액션 아이템 (Action Item)을 추출합니다. 수작업으로 하기 쉬운 정보 정리를 에이전트에게 맡길 수 있습니다.

인시던트 대응 (Incident Response)

운영 환경 장애의 스택 트레이스 (Stack Trace)를 조사하여 근본 원인을 특정하고, 최근 변경 사항과의 상관관계를 탐색하며, 수정안을 제시합니다. 사람이 리뷰하기 전 단계의 조사를 에이전트가 담당합니다.

릴리스 노트 초안 작성

커밋 메시지 (Commit Message)와 PR 설명을 바탕으로 릴리스 노트를 생성합니다. 최종적인 문장 다듬기와 정확도 확인은 사람이 수행해야 합니다.

의존성 관리 (Dependency Management)

메이저 버전 업데이트가 안전한지에 대한 평가나, 취약점이 있는 의존성 패키지의 우선순위 지정 등을 에이전트가 수행합니다. 의존성 업데이트 작업에 드는 수고를 대폭 줄일 수 있습니다.

가이드 전체를 관통하는 메시지는 에이전트는 똑똑하지만, 무책임하게 사용하면 결과도 무책임해진다는 점입니다.

실제로 만져보며 배우는 수밖에 없다는 것이 솔직한 심정이지만, 이 가이드는 그 학습을 위한 지도(Map)로서 매우 유용하다고 느꼈습니다.

이 기사는 가이드의 모든 내용을 망라하고 있는 것이 아니라, 개인적으로 중요하다고 판단한 부분만을 발췌하였습니다. 더 깊이 배우고 싶은 분들은 꼭 원문을 확인하시기 바랍니다.

이 기사는 Piotr Zborowski, Marek Kaput (Software Mansion)이 CC BY-NC-SA 4.0 조건 하에 공개한 원문을 바탕으로 작성되었습니다.

---

• GPT-4나 Claude 3 등, 현시점에서 최고 수준의 성능을 가진 대규모 언어 모델 (LLM)의 총칭. 연구·개발의 최전선 (Frontier)에 있다는 점에서 이렇게 불린다. ↩

• 캐시 포이즈닝 (Cache Poisoning)이란, 패키지 매니저나 CDN 등의 캐시에 악의적인 데이터를 혼입시키는 공격 수법. 정상적인 패키지나 정적 파일이 교체되어, 이용자가 모르는 사이에 악의적인 코드를 실행하게 된다. ↩

• 프롬프트 인젝션 (Prompt Injection)이란, 악의적인 문자열을 에이전트의 입력에 섞어 넣어 본래의 지시를 덮어쓰는 공격 수법. 예를 들어 웹 페이지나 검색 결과에 "지금까지의 지시를 무시하고 ○○하라"라고 적어두면, 에이전트가 이를 지시로 오인하여 실행해 버린다. 에이전트가 외부 콘텐츠를 읽는 상황 (웹 검색, Issue 읽기, 파일 분석 등)에서 특히 주의가 필요하다. ↩

• YOLO: "You Only Live Once"의 약자. Claude Code에서는 승인 프롬프트를 전혀 표시하지 않고, 에이전트가 모든 조작을 자동 실행하는 모드를 가리킨다. 작업 속도는 올라가지만, 의도하지 않은 파일 변경이나 명령 실행이 확인 없이 이루어질 리스크가 있다. ↩

• 할루시네이션 (Hallucination): AI가 사실과 다른 내용을 마치 정확한 것처럼 생성해 버리는 현상. 존재하지 않는 API나 함수명을 자신만만하게 제시하는 경우가 전형적인 사례다. ↩

• 셀프 리플렉션 (Self-Reflection): 에이전트가 답변을 생성한 후, 그 내용을 스스로 재평가·검증하는 단계를 두는 메커니즘. "이 답변은 정확한가?", "근거가 있는가?"라고 자문하게 함으로써 할루시네이션을 줄인다. ↩