앤트로픽 엔지니어가 알려준 진짜 되는 AI 에이전트 설계법

AI 에이전트라는 말을 들으면 뭔가 거창하게 느껴집니다.

스스로 계획하고, 도구를 쓰고, 코드를 고치고, 테스트하고, 결과까지 보고하는 AI.

멋있습니다. 그런데 실무에서는 여기서 한 가지 함정이 생깁니다.

"에이전트니까 최대한 자율적으로 만들면 좋은 거 아닌가?"

꼭 그렇지는 않습니다.

Anthropic의 엔지니어링 글과 공식 강연에서 반복해서 나오는 메시지는 오히려 반대에 가깝습니다.

처음부터 복잡한 자율 시스템을 만들기보다, 작고 검증 가능한 흐름부터 만들라는 것입니다.

이 글에서는 Anthropic의 에이전트 설계 원칙을 바탕으로, 개발자와 실무자가 오늘 바로 써먹을 수 있는 방식으로 정리해보겠습니다.

핵심 흐름은 단순합니다.

고르기 → 만들기 → 검증 → 검수

무엇을 에이전트로 만들지 고르고, 최소 구성으로 만들고, 실제 결과를 검증하고, 안 될 때는 로그와 궤적을 다시 검수하는 흐름입니다.

참고 영상

아래 영상은 Anthropic의 Barry Zhang이 효과적인 에이전트를 어떻게 만드는지 설명한 자료입니다. 이 글을 읽기 전이나 후에 함께 보면 흐름을 잡는 데 도움이 됩니다.

AI 에이전트란 무엇인가요?

AI 에이전트는 단순히 답변만 하는 챗봇이 아닙니다.

목표를 받고, 필요한 단계를 나누고, 도구를 사용하고, 중간 결과를 확인하면서 일을 진행하는 시스템에 가깝습니다.

예를 들어 Claude Code에게 이렇게 말할 수 있습니다.

현재 프로젝트에서 로그인 오류 원인을 찾아줘.
관련 파일을 확인하고, 수정 계획을 먼저 보여줘.
내가 승인하면 코드를 고치고 테스트까지 실행해줘.

이 경우 Claude Code는 단순히 설명만 하지 않습니다. 파일을 읽고, 원인을 추정하고, 수정 전략을 세우고, 필요하면 코드를 바꾸고, 확인까지 합니다.

이런 흐름이 에이전트적인 작업 방식입니다.

하지만 모든 일을 AI에게 통째로 맡기는 것이 에이전트는 아닙니다. 오히려 좋은 에이전트 설계는 사람이 어디서 개입하고, AI가 어디까지 진행할지 정하는 데서 시작합니다.

에이전트, 다 만들지 마세요

AI 자동화를 고민할 때 가장 먼저 던질 질문은 이것입니다.

이 일을 결정 트리로 그릴 수 있나?

결정 트리란 if-then 흐름입니다.

예를 들어 이런 일은 굳이 에이전트가 아니어도 됩니다.

• 메일 제목에 "영수증"이 있으면 회계 라벨 붙이기
• 문의 유형이 "비밀번호"면 비밀번호 재설정 안내 보내기
• 새 신청서가 들어오면 담당자에게 알림 보내기

이런 일은 워크플로우가 더 잘 맞습니다. 순서가 정해져 있고, 판단 기준도 분명하기 때문입니다.

반대로 이런 일은 에이전트가 더 잘 맞을 수 있습니다.

• 고객 문의 맥락을 읽고 환불 가능성을 판단하기
• 테스트 실패 원인을 찾아 수정 계획 세우기
• 여러 문서를 읽고 누락된 요구사항 찾기
• 화면을 보면서 다음 클릭 위치를 판단하기

중간에 LLM의 판단이 꼭 필요할 때 에이전트를 고려하면 됩니다.

도입 전 4가지 체크

에이전트를 만들기 전에 아래 4가지를 먼저 확인해보세요.

1. 복잡도: 단순 트리로는 안 되는가?

규칙 몇 개로 해결되는 일이라면 에이전트가 필요하지 않을 수 있습니다.

처음에는 자동화하고 싶은 일을 종이에 그려보세요.

조건 A면 1번 처리
조건 B면 2번 처리
조건 C면 사람에게 넘기기

이 정도로 끝나면 워크플로우가 더 안전합니다.

2. 가치: 실행 비용을 낼 만큼 중요한가?

AI 에이전트는 공짜가 아닙니다.

모델 호출 비용도 있고, 실행 시간도 있고, 결과를 검수하는 사람의 시간도 들어갑니다.

한 번 실행할 때 작은 비용처럼 보여도, 매일 수백 번 실행하면 꽤 커집니다. 그래서 물어봐야 합니다.

이 일을 자동화했을 때 절약되는 시간과 품질 개선이 비용보다 큰가?

가치가 작다면 먼저 수동 체크리스트나 간단한 워크플로우부터 시작하는 편이 좋습니다.

3. 역량: 마지막 20%를 고칠 수 있는가?

에이전트는 데모에서는 잘 돌아가 보일 수 있습니다.

하지만 실무에서는 마지막 20%가 어렵습니다.

예외 상황, 애매한 입력, 엉뚱한 도구 호출, 실패한 테스트, 권한 문제 같은 것들이 나옵니다.

이 마지막 부분을 고칠 역량이 없다면, 완성도는 80%가 아니라 0%에 가까워질 수 있습니다. 실제 업무에 넣을 수 없기 때문입니다.

4. 에러 비용: 틀려도 피해가 작은가?

AI 에이전트는 틀릴 수 있습니다.

그래서 처음에는 틀려도 피해가 작은 일부터 시작해야 합니다.

좋은 시작점은 읽기 전용 작업입니다.

• 문서 요약
• 로그 분석
• 코드 리뷰 초안
• 원인 후보 정리
• 체크리스트 생성

반대로 결제, 삭제, 배포, 고객 발송처럼 되돌리기 어려운 일은 사람 확인을 먼저 넣어야 합니다.

에이전트는 결국 3개가 전부입니다

처음부터 복잡한 구조를 만들 필요는 없습니다.

좋은 에이전트는 크게 3가지로 나눌 수 있습니다.

1. 환경: 어디서 일할 것인가?

환경은 에이전트가 일하는 공간입니다.

예를 들어 Slack, Notion, GitHub, 로컬 프로젝트, 브라우저, 사내 관리자 페이지가 될 수 있습니다.

환경이 분명해야 에이전트가 무엇을 보고, 어디까지 접근할 수 있는지 정할 수 있습니다.

2. 도구: 무엇을 쓸 수 있는가?

도구는 에이전트의 눈과 손입니다.

파일 읽기, 검색, 코드 수정, 테스트 실행, 브라우저 클릭, 문서 작성 같은 기능입니다.

도구는 많을수록 좋은 것이 아닙니다.

처음에는 꼭 필요한 3~5개만 주는 편이 좋습니다. 도구가 많아질수록 잘못된 도구를 고를 가능성도 커집니다.

3. 시스템 프롬프트: 무엇을 해야 하고, 무엇을 하면 안 되는가?

시스템 프롬프트는 에이전트의 목표와 금지선입니다.

예를 들어 이렇게 정할 수 있습니다.

너는 고객 문의를 분류하는 에이전트다.
환불 승인 여부는 직접 결정하지 않는다.
환불 가능성이 있으면 반드시 사람 검토로 넘긴다.
확실하지 않은 경우 추측하지 말고 "검토 필요"로 표시한다.

이 3가지만 명확해도 에이전트의 품질이 크게 올라갑니다.

에이전트는 지금 눈 감고 클릭 중입니다

에이전트를 만들 때 사람은 자주 착각합니다.

"AI가 화면을 봤으니까 다 알겠지."

하지만 실제로는 그렇지 않습니다.

브라우저나 앱을 조작하는 에이전트는 제한된 정보만 봅니다. 스크린샷 한 장을 보고, 클릭하고, 다시 화면을 보고, 다음 행동을 고르는 식입니다.

사람처럼 계속 화면 전체를 자연스럽게 이해하는 것이 아닙니다.

그래서 환경 정보를 자세히 줘야 합니다.

• 현재 화면의 목적
• 성공 조건
• 클릭하면 안 되는 버튼
• 시간대와 날짜 기준
• 권한 제한
• 실패했을 때 멈출 조건

예를 들어 한국 서비스를 다룬다면 시간대도 중요합니다.

모든 날짜와 시간은 Asia/Seoul 기준으로 판단해줘.
오늘, 내일, 어제 같은 표현은 실제 날짜로 바꿔서 확인해줘.

엉뚱한 행동은 모델이 멍청해서가 아니라, 필요한 정보가 부족해서 생기는 경우가 많습니다.

실무에 바로 쓰는 5가지 패턴

복잡한 에이전트 프레임워크를 몰라도 됩니다. 아래 5가지만 익혀도 대부분의 업무 자동화와 Claude Code 작업 품질이 크게 좋아집니다.

1. 프롬프트 체이닝: 큰 일을 작은 단계로 나누기

프롬프트 체이닝은 하나의 큰 요청을 여러 단계로 나누는 방식입니다.

이 방식의 장점은 중간에 방향을 바꿀 수 있다는 점입니다.

AI가 처음부터 끝까지 틀린 방향으로 달리는 일을 줄일 수 있습니다.

2. 라우팅: 요청을 알맞은 처리 방식으로 보내기

라우팅은 들어온 요청을 종류별로 나누는 방식입니다.

이 이슈가 버그 수정, 리팩터링, 문서 작업, 기능 추가 중 어디에 가까운지 먼저 분류해줘.
분류한 이유와 다음 작업 흐름을 제안해줘.

라우팅을 넣으면 AI가 무조건 코드를 고치려고 달려들지 않습니다. 먼저 일의 종류를 파악하게 됩니다.

3. 병렬 처리: 여러 후보를 동시에 만들기

AI에게 하나의 답만 요구하면 선택지가 좁아집니다.

이 기능을 구현하는 방법을 3가지 제안해줘.
각 방법의 장점, 단점, 변경 범위, 테스트 난이도를 비교해줘.
아직 코드는 수정하지 마.

이 패턴은 중요한 결정을 앞두고 특히 좋습니다. AI에게 정답 하나를 맡기는 것이 아니라, 판단 재료를 만들게 하는 방식입니다.

4. 평가자 패턴: 만든 결과를 다시 검토하기

AI가 만든 결과는 그럴듯해 보일 수 있습니다. 그래서 검토 단계가 필요합니다.

수정한 코드를 리뷰어 관점에서 검토해줘.
버그 가능성, 테스트 누락, 기존 동작 변경 가능성을 우선순위로 정리해줘.

처음에는 작성자, 다음에는 검토자로 역할을 바꾸는 것이 핵심입니다.

5. 오케스트레이터-작업자: 큰 목표를 작은 작업자에게 나누기

오케스트레이터는 전체 흐름을 관리하는 역할입니다. 작업자는 작은 일을 처리합니다.

Claude Code로 개발할 때는 이렇게 나눌 수 있습니다.

• 원인 분석
• 수정 계획
• 코드 변경
• 테스트 실행
• 변경 요약

처음부터 모든 것을 한 번에 맡기지 말고, 각 단계의 결과를 확인하면서 다음 단계로 넘기면 안정성이 올라갑니다.

Claude Code에 적용하는 방법

Claude Code에게 일을 맡길 때는 목표, 범위, 멈춤 조건, 확인 기준을 같이 줘야 합니다.

버그 수정 요청

로그인 후 대시보드로 이동하지 않는 문제를 해결해줘.
먼저 관련 파일을 찾아 원인 후보를 정리해줘.
아직 코드는 수정하지 마.

정리할 때는 다음 형식으로 알려줘.
1. 원인 후보
2. 확인한 파일
3. 수정 계획
4. 예상 위험
5. 확인할 테스트

작은 기능 추가 요청

게시글 목록에 카테고리 필터를 추가하고 싶어.
기존 UI 스타일을 유지해줘.
먼저 구현 계획과 수정할 파일 목록을 알려줘.
내가 승인하면 구현하고, 마지막에 확인 방법을 알려줘.

리팩터링 요청

이 컴포넌트의 중복 로직을 줄이고 싶어.
동작, props 이름, 화면 구조는 바꾸지 마.
먼저 중복되는 부분과 리팩터링 전략을 설명해줘.
수정 후에는 기존 동작이 유지되는지 확인 방법을 알려줘.

코드 리뷰 요청

현재 변경사항을 코드 리뷰 관점에서 봐줘.
칭찬보다 문제 가능성을 먼저 알려줘.
버그, 보안, 성능, 테스트 누락 순서로 정리해줘.
파일과 위치를 함께 알려줘.

안 될 때는 Claude에게 Claude를 검수하게 하세요

에이전트가 기대와 다르게 움직일 때는 증상별로 봐야 할 곳이 다릅니다.

• 엉뚱한 방향으로 가면 시스템 프롬프트를 봅니다.
• 도구를 잘못 쓰면 도구 설명을 봅니다.
• 마지막 단계에서 무너지면 실행 궤적을 봅니다.
• 같은 실수를 반복하면 실패 로그를 봅니다.

여기서 실행 궤적이란 에이전트가 실제로 어떤 생각과 행동을 거쳤는지 남긴 기록입니다.

검수할 때는 설명을 너무 많이 덧붙이지 않는 편이 좋습니다. 에이전트가 실제로 본 입력, 실제로 호출한 도구, 실제 결과 로그를 그대로 주는 것이 좋습니다.

아래는 에이전트가 실제로 본 입력과 실행 로그야.
왜 실패했는지 원인을 찾아줘.

1. 시스템 프롬프트 문제인지
2. 도구 설명 문제인지
3. 정보 부족 문제인지
4. 작업 순서 문제인지

네 가지로 나눠서 진단해줘.

이렇게 하면 문제를 감으로 고치는 것이 아니라, 원인별로 좁혀갈 수 있습니다.

좋은 에이전트 설계 체크리스트

AI 에이전트를 만들거나 Claude Code에게 일을 맡기기 전에 아래 체크리스트를 확인해보세요.

• 이 일을 결정 트리로 그릴 수 있나요?
• 워크플로우가 아니라 에이전트가 꼭 필요한가요?
• 한 번 실행할 비용과 시간을 낼 만큼 가치가 있나요?
• 틀렸을 때 피해가 작은가요?
• 처음에는 읽기 전용으로 시작할 수 있나요?
• 에이전트가 일할 환경이 분명한가요?
• 도구는 꼭 필요한 3~5개로 제한했나요?
• 시스템 프롬프트에 목표와 금지선이 있나요?
• 사람이 확인할 멈춤 지점이 있나요?
• 실패했을 때 볼 로그가 남나요?

하나라도 애매하면 바로 자동화하지 말고, 먼저 사람이 확인하는 흐름을 넣으세요.

내가 그래서 뭘 할 수 있을까?

이 글을 읽고 바로 할 수 있는 일은 거창한 에이전트 만들기가 아닙니다.

오늘 하는 일 하나를 골라서 AI에게 더 잘 맡겨보는 것입니다.

예를 들어 이런 일부터 시작해보세요.

• 회의록을 액션 아이템으로 바꾸기
• 블로그 초안을 SEO 목차로 정리하기
• README 초안 만들기
• 실패하는 테스트 원인 분석하기
• 코드 리뷰 체크리스트 만들기
• 고객 문의를 유형별로 분류하기
• 반복되는 업무 순서를 자동화 흐름으로 정리하기

처음부터 완벽한 자동화를 만들 필요는 없습니다.

먼저 내가 반복해서 하는 일을 하나 고릅니다. 그리고 AI에게 이렇게 말해보세요.

이 일을 자동화 가능한 단계로 나눠줘.
각 단계에서 필요한 입력, 출력, 사람이 확인할 지점을 정리해줘.
그리고 Claude Code나 ChatGPT에 바로 넣을 수 있는 프롬프트로 바꿔줘.

이 프롬프트 하나만으로도 막연한 업무가 꽤 선명해집니다.

복붙 프롬프트: 내 첫 AI 에이전트 설계하기

아래 프롬프트는 Claude, ChatGPT, Gemini에 그대로 붙여 넣고 쓸 수 있습니다.

빈칸만 채워보세요.

[역할]
너는 나랑 같이 내 첫 AI 에이전트를 설계하는 파트너야.

내가 자동화하고 싶은 일: ____________

[1단계: 질문]
아래 4개를 하나씩만 물어봐.
내 답을 들은 뒤 다음 질문으로 넘어가.

1. 이 일은 if-then 순서도로 딱 떨어져?
   아니면 중간에 판단이 필요해?
2. 한 번 실행할 비용과 시간이 아깝지 않을 만큼 가치 있어?
3. 손발이 될 도구나 연결은 뭐가 필요해?
   예: 메일, Notion, Slack, 검색, 로컬 파일, GitHub
4. 잘되면 어떤 결과가 나오고,
   틀리면 피해는 얼마나 커?

[2단계: 설계]
답을 다 들으면 아래 4개로 정리해줘.

1. 무대: 에이전트가 일할 공간
2. 도구: 꼭 필요한 3~5개 도구와 한 줄 설명
3. 지침: 목표와 금지선을 담은 시스템 프롬프트
4. 함정: 가장 깨지기 쉬운 지점과 막는 방법 하나

[3단계: 점검]
마지막으로 정보가 제한된 에이전트 입장에서
뭐가 부족한지 짚어줘.
어려운 말은 빼고 쉽게 설명해줘.

마무리

AI 에이전트의 핵심은 복잡함이 아닙니다.

스스로 움직이는 것처럼 보이게 만드는 것도 아닙니다.

핵심은 일을 작게 나누고, 각 단계의 결과를 확인하고, 필요한 순간에 사람이 판단할 수 있게 만드는 것입니다.

단순하게 시작하세요.

작은 업무 하나를 고르세요.

AI에게 목표, 범위, 멈춤 조건, 확인 기준을 주세요.

그리고 이렇게 말해보세요.

바로 실행하지 말고, 먼저 계획을 보여줘.

이 문장 하나가 AI를 그냥 답변 도구가 아니라, 함께 일하는 실무 파트너로 바꾸는 출발점이 됩니다.

자주 묻는 질문