“이 문서를 요약해 줘”라고 했을 때와 “이 프로젝트의 문제를 찾아 수정하고 테스트까지 실행해 줘”라고 했을 때, 두 요청에 응답하는 AI는 겉보기에는 비슷합니다.
하지만 실제로 하는 일은 꽤 다릅니다.
첫 번째 요청은 주어진 자료를 읽고 답을 만드는 작업에 가깝습니다. 두 번째 요청은 프로젝트를 탐색하고, 규칙을 확인하고, 작업을 여러 단계로 나누고, 파일을 수정하고, 테스트를 실행하고, 결과를 다시 확인해야 합니다. 중간에 문제가 생기면 계획을 바꾸기도 해야 합니다.
이 차이가 바로 챗봇과 에이전트 사이의 차이입니다.
에이전트는 마법처럼 한 번에 완성된 답을 꺼내는 존재가 아닙니다. 주어진 목표를 기준으로 현재 상태를 읽고, 다음 행동을 고르고, 도구를 실행하고, 결과를 관찰한 뒤, 목표에 도달했는지 다시 판단하는 실행 시스템에 가깝습니다.
오늘은 에이전트를 제품 이름이 아니라 실행 아키텍처로 읽어 보겠습니다.
1. 에이전트의 기본 단위는 답변이 아니라 실행 루프다
에이전트의 가장 단순한 형태는 다음 루프로 표현할 수 있습니다.
목표 이해
→ 현재 상태 관찰
→ 다음 행동 결정
→ 도구 실행
→ 결과 확인
→ 목표 달성 여부 판단
→ 필요하면 다시 실행
이를 흔히 Agent Loop라고 부릅니다. 이름은 제품마다 조금씩 다르고 구현도 다르지만, 핵심은 비슷합니다. 모델이 한 번 대답하고 끝나는 것이 아니라, 실행 결과를 다시 컨텍스트로 받아 다음 행동을 정한다는 점입니다.
예를 들어 “블로그 글을 작성해 줘”라는 요청을 받으면, 제대로 된 에이전트는 곧바로 문장부터 길게 쓰지 않습니다.
- 어느 프로젝트의 글인지 확인한다.
- 프로젝트의 작성 규칙과 기존 글을 읽는다.
- 주제와 날짜, 카테고리를 확인한다.
- 초안을 작성하고 파일에 저장한다.
- 프런트매터와 링크, 마크다운 구조를 점검한다.
- 필요한 빌드를 실행한다.
- 오류가 있으면 수정하고 다시 확인한다.
이 과정에서 각 단계의 결과가 다음 단계의 입력이 됩니다. 파일을 읽지 않고 기존 스타일을 안다고 가정하면 첫 루프부터 틀립니다. 빌드를 실행하지 않고 “완료했다”고 말하면 마지막 루프가 빠진 것입니다.
아키텍처 교훈 ①
에이전트의 실력은 첫 답변의 화려함보다, 행동 결과를 다시 읽고 다음 판단에 반영하는 능력에서 드러난다.
2. 목표는 ‘무엇을 만들까’보다 ‘어디까지 하면 끝인가’가 중요하다
사람에게 “이 글을 작성해 줘”라고 말하면 어느 정도 상식적인 범위를 기대할 수 있습니다. 하지만 에이전트에게는 완료 조건이 훨씬 중요합니다.
다음 두 요청은 비슷해 보이지만 범위가 다릅니다.
- “블로그 글 초안을 작성해 줘.”
- “블로그 글을 작성하고 빌드한 뒤 게시해 줘.”
두 번째 문장에는 외부 실행이 포함되어 있습니다. 초안 파일을 만드는 것과 원격 저장소에 푸시하거나 실제 게시하는 것은 위험도와 승인 기준이 다릅니다.
그래서 에이전트 작업을 시작할 때 저는 목표를 세 부분으로 나눠 보는 편입니다.
| 구분 | 질문 | 예시 |
|---|---|---|
| 결과 | 무엇을 만들어야 하는가? | 특정 날짜의 arch 포스트 2개 |
| 범위 | 어디까지 건드려도 되는가? | 해당 프로젝트의 _posts/arch/만 |
| 완료 조건 | 무엇을 확인해야 끝나는가? | 프런트매터 검사와 사이트 빌드 |
여기에 “하지 말아야 할 일”도 붙이면 더 선명해집니다.
- 사용자 승인 없이 커밋·푸시하지 않는다.
- 생성물 디렉터리를 직접 수정하지 않는다.
- 비밀정보를 읽거나 글에 넣지 않는다.
- 근거가 부족한 기능이나 수치를 사실처럼 쓰지 않는다.
이런 조건은 에이전트의 자유를 빼앗는 장벽이 아니라, 자유롭게 움직여도 되는 공간의 모양을 정해 주는 안전선입니다.
3. 규칙 파일은 에이전트의 ‘작업 매뉴얼’이다
에이전트에게 매번 같은 설명을 반복하다 보면 언젠가는 그 내용을 파일로 옮기고 싶어집니다. 프로젝트 구조, 실행 명령, 금지된 경로, 글의 형식, 테스트 방법 같은 것들입니다.
Claude Code의 CLAUDE.md나 여러 코딩 에이전트가 읽는 AGENTS.md 같은 파일은 이런 지속적인 작업 맥락을 전달하는 역할을 합니다. 여기에는 “이 프로젝트는 무엇이고, 어떤 규칙을 지켜야 하며, 완료 후 무엇을 확인하는가”를 적어 둘 수 있습니다.
다만 규칙 파일이 있다고 해서 에이전트가 절대로 실수하지 않는 것은 아닙니다. 규칙은 대체로 에이전트가 행동을 선택할 때 참고하는 컨텍스트입니다. 강제로 막아야 하는 권한이나 명령은 별도의 설정과 실행 환경에서 제한해야 합니다.
저는 규칙 파일을 다음 세 층으로 나누어 생각합니다.
항상 알아야 하는 규칙
프로젝트의 목적, 디렉터리 구조, 기본 빌드 명령, 금지된 생성물 수정, Git 브랜치처럼 매 작업에 필요한 내용입니다.
특정 작업에서만 필요한 규칙
상표 검색 보고서 형식, 특정 API의 호출 방식, 이미지 제작 절차처럼 모든 대화에 넣으면 오히려 컨텍스트를 차지하는 내용입니다. 이런 것은 별도 가이드나 스킬로 분리하는 편이 낫습니다.
시스템이 강제해야 하는 제한
비밀정보 접근 차단, 외부 배포 승인, 특정 명령 금지처럼 “에이전트가 알아서 지키기를 기대하면 안 되는” 내용입니다. 권한 정책, 샌드박스, 훅, 호스팅 설정 등 더 낮은 계층에서 다루어야 합니다.
아키텍처 교훈 ②
규칙 파일은 에이전트에게 방향을 알려 주고, 권한 정책은 실제로 넘어가면 안 되는 선을 막는다. 둘을 같은 것으로 보면 안 된다.
4. Skills는 반복 업무를 ‘작업 방식’으로 묶는다
규칙이 “항상 지켜야 할 프로젝트의 헌법”이라면, Skills는 특정 업무를 수행하는 방법에 가깝습니다.
예를 들어 다음과 같은 작업은 한 번의 자연어 지시로도 가능하지만, 반복되면 절차를 고정하고 싶어집니다.
- 특정 형식의 보고서 만들기
- 문서에서 표와 핵심 주장 추출하기
- 테스트·빌드·검증 결과를 하나의 보고서로 정리하기
- 이미지 파일을 확인하고 정해진 위치에 저장하기
- 커밋 전 점검 항목을 순서대로 실행하기
이런 절차를 스킬로 만들면 에이전트는 매번 “무엇부터 하지?”를 새로 고민하지 않아도 됩니다. 필요한 경우에만 상세 지침을 불러오므로, 모든 작업 규칙을 처음부터 한꺼번에 넣는 것보다 컨텍스트를 아낄 수도 있습니다.
다만 스킬을 많이 만든다고 좋은 것은 아닙니다. 비슷한 스킬이 여러 개 생기면 어느 것을 적용해야 할지 혼란이 생기고, 오래된 절차가 남아 있으면 서로 충돌합니다.
스킬 하나를 만들기 전에 다음을 먼저 묻는 편이 좋습니다.
- 이 작업이 실제로 반복되는가?
- 작업 순서와 완료 조건이 안정적으로 정해져 있는가?
- 다른 사람이 같은 결과를 재현해야 하는가?
- 프로젝트 전체 규칙에 넣기에는 범위가 좁은가?
네 질문에 대부분 “예”라면 스킬로 묶을 가치가 있습니다. 아직 매번 달라지는 실험이라면 기록이나 초안으로 남기는 편이 더 가볍습니다.
5. Subagents는 분업이고, Hooks는 체크포인트다
에이전트의 일을 더 쪼개면 Subagents와 Hooks라는 개념이 등장합니다. 둘은 모두 자동화를 돕지만 역할은 다릅니다.
Subagents: 큰 일을 작은 전문 작업으로 나누기
하나의 요청 안에 서로 독립적인 조사나 검토가 있다면, 각각을 별도의 작업자로 보내고 마지막에 결과를 합칠 수 있습니다.
예를 들어 긴 프로젝트에서 다음 세 가지를 동시에 살펴볼 수 있습니다.
- 문서 구조와 규칙 확인
- 코드 변경 가능 지점 조사
- 테스트와 배포 설정 점검
각 작업자가 자기 컨텍스트에서 자료를 살펴본 뒤 요약을 돌려주면, 주 에이전트의 대화창에 원문과 로그가 한꺼번에 쏟아지는 일을 줄일 수 있습니다.
하지만 모든 일을 병렬로 나누면 좋은 것은 아닙니다. 앞 단계의 결과를 알아야 다음 단계로 갈 수 있는 작업, 서로 같은 파일을 수정하는 작업, 최종 판단에 긴밀한 조율이 필요한 작업은 분리할수록 오히려 복잡해집니다.
Hooks: 특정 순간에 자동으로 끼어들기
Hooks는 도구 호출 전후나 세션 시작·종료처럼 정해진 시점에 실행되는 체크포인트로 생각할 수 있습니다.
- 도구를 실행하기 전에 경로와 명령을 검사한다.
- 파일이 변경된 뒤 포맷이나 보안 점검을 실행한다.
- 세션이 시작될 때 필요한 환경 정보를 준비한다.
- 작업이 멈출 때 테스트 결과나 변경 목록을 남긴다.
Subagent가 누가 어떤 일을 맡을지에 관한 분업이라면, Hook은 언제 어떤 검사를 자동으로 끼울지에 관한 통제입니다.
둘을 표로 놓으면 더 분명합니다.
| 구성요소 | 핵심 질문 | 적합한 역할 |
|---|---|---|
| 주 에이전트 | 전체 목표를 어떻게 완주할까? | 계획·조율·최종 판단 |
| Skill | 이 반복 업무는 어떤 순서로 할까? | 표준 절차·전문 작업 |
| Subagent | 어떤 하위 문제를 따로 맡길까? | 독립 조사·전문 검토 |
| Hook | 어느 순간 자동으로 확인할까? | 사전 차단·사후 검사·기록 |
| MCP | 어떤 외부 시스템을 연결할까? | 도구·데이터·API 접근 |
이 구분을 해 두면 “에이전트가 알아서 다 하게 만들자”는 막연한 요구가 조금 더 설계 가능한 언어로 바뀝니다.
6. MCP는 에이전트에게 손과 눈을 제공하지만, 책임까지 넘기지는 않는다
에이전트가 프로젝트 파일만 읽는다면 할 수 있는 일에는 한계가 있습니다. 검색 서버, 데이터베이스, GitHub, 캘린더, 메일, 사내 지식 저장소와 연결되면 더 넓은 업무를 수행할 수 있습니다.
MCP는 이런 외부 도구와 데이터 소스를 AI 애플리케이션에 연결하기 위한 표준적인 통로 중 하나입니다. 구조적으로 보면 AI 애플리케이션이 호스트가 되고, 호스트가 각 MCP 서버와 연결해 필요한 컨텍스트와 기능을 얻습니다.
하지만 MCP를 붙였다고 해서 에이전트가 갑자기 책임 있는 담당자가 되는 것은 아닙니다. 에이전트에게 다음과 같은 능력이 생길 뿐입니다.
- 외부 시스템에서 자료를 조회할 수 있다.
- 정해진 도구를 호출해 작업을 준비할 수 있다.
- 경우에 따라 외부 시스템의 상태를 바꿀 수 있다.
마지막 항목이 특히 중요합니다. 검색과 메일 발송은 모두 “도구 호출”이지만, 실패 비용은 전혀 다릅니다. 그래서 MCP 서버를 연결할 때에는 기능 목록보다 먼저 다음을 확인해야 합니다.
- 읽기 전용인가, 쓰기 작업도 가능한가?
- 어떤 계정과 권한으로 실행되는가?
- 입력 데이터가 외부 서버로 이동하는가?
- 호출 내용과 결과를 나중에 확인할 수 있는가?
- 외부 실행 전에 사람의 승인을 넣을 수 있는가?
에이전트에게 손과 눈을 주는 일은 강력합니다. 그렇기 때문에 손이 닿는 범위와 눈으로 볼 수 있는 범위를 먼저 정해야 합니다.
7. 실제 작업은 ‘자율성’보다 ‘관문’을 설계하는 문제다
에이전트 이야기를 하다 보면 자율성의 크기가 자주 화제가 됩니다. 몇 턴까지 알아서 실행하게 할지, 파일을 자동으로 수정하게 할지, 외부 서비스까지 연결할지 같은 질문입니다.
저는 자율성을 한 줄의 슬라이더보다 관문이 있는 흐름으로 보는 편이 실용적이라고 생각합니다.
자료 읽기
→ 계획·초안 작성
→ 로컬 파일 변경
→ 테스트·검증
→ 사람 승인
→ 외부 실행
앞쪽 단계는 비교적 자동화하기 쉽습니다. 결과를 되돌리기 쉽고, 사람이 diff나 로그를 확인할 수 있기 때문입니다. 뒤쪽 단계로 갈수록 승인 강도를 높여야 합니다.
제가 편하게 맡기는 일
- 파일 목록과 기존 문서 구조 확인
- 반복적인 형식 정리
- 초안 작성과 대안 제시
- 테스트 실행과 오류 요약
- 변경 전후의 차이 정리
사람이 반드시 확인하는 일
- 법적 결론과 외부 자문 의견
- 미공개 정보의 외부 전송 여부
- 고객이나 독자에게 전달되는 최종 문안
- 실제 게시·배포·발송
- 되돌리기 어려운 데이터 변경
이렇게 나누면 에이전트의 속도를 살리면서도 책임의 위치를 잃지 않을 수 있습니다. 자율성은 “얼마나 많이 맡겼는가”가 아니라, 어떤 관문 앞에서 멈추도록 설계했는가로 평가해야 합니다.
아키텍처 교훈 ③
에이전트에게 필요한 것은 무제한 자율성이 아니라, 빠르게 움직여도 되는 구간과 반드시 멈춰야 하는 구간이 표시된 작업 지도다.
8. 에이전트가 실패하는 방식은 어느 정도 예측할 수 있다
에이전트의 실패는 전부 모델의 지능 부족 때문은 아닙니다. 실행 환경의 설계가 애매해서 생기는 실패도 많습니다.
컨텍스트가 너무 많다
규칙·문서·도구 설명을 모두 한 번에 넣으면 에이전트가 중요한 조건을 놓칠 수 있습니다. 항상 필요한 규칙과 특정 작업에서만 필요한 지침을 분리해야 합니다.
범위가 모호하다
“전체를 정리해 줘”라는 말에는 프로젝트 전체를 뜻하는지, 현재 파일만 뜻하는지 드러나지 않습니다. 작업 경로와 수정 가능 범위를 먼저 정해야 합니다.
도구의 성공을 결과의 성공으로 착각한다
검색 API가 응답했다고 조사가 끝난 것은 아닙니다. 파일이 저장됐다고 문서가 완성된 것도 아닙니다. 도구 실행 성공과 업무 목표 달성은 별도로 확인해야 합니다.
오래된 정보를 현재 사실처럼 쓴다
제품 기능, 가격, 법령, 정책, 서비스 상태는 바뀔 수 있습니다. 현재성이 중요한 정보는 원문과 확인 날짜를 남기고, 불확실하면 보류 표시를 해야 합니다.
마지막 외부 행동까지 자동으로 이어 버린다
초안 작성과 게시, 코드 수정과 배포, 메일 작성과 발송은 서로 다른 단계입니다. 마지막 출구에 승인 관문이 없으면 작은 실수가 외부 상태로 굳어집니다.
이 실패 목록은 에이전트를 불신하기 위한 것이 아닙니다. 오히려 반복되는 실패를 규칙·스킬·훅·검증 절차로 승격시키기 위한 출발점입니다.
9. 제가 에이전트 작업을 시작할 때 확인하는 다섯 줄
복잡한 시스템을 처음부터 만들 필요는 없습니다. 저는 새로운 에이전트 작업을 시작할 때 다음 다섯 줄부터 적어 보려 합니다.
목표: 무엇을 만들어야 하는가?
범위: 어느 파일·시스템까지 접근해도 되는가?
도구: 어떤 자료를 어디에서 읽거나 바꿀 것인가?
검증: 무엇을 실행하거나 대조해야 하는가?
관문: 외부 실행 전에 누가 무엇을 승인하는가?
이 다섯 줄을 적으면 에이전트의 행동이 조금 덜 신비로워집니다. “알아서 해 줘”가 “이 범위에서 이 도구를 사용해 이 조건까지 확인해 줘”로 바뀌기 때문입니다.
그리고 작업이 반복되면 그 다섯 줄 중 변하지 않는 부분을 규칙 파일이나 Skill로 옮깁니다. 독립적인 하위 조사라면 Subagent로 분리하고, 매번 확인해야 하는 순간이 있다면 Hook을 붙입니다. 외부 자료나 시스템이 필요해지면 MCP를 연결하되, 권한과 출구를 먼저 점검합니다.
이것이 제가 생각하는 에이전트 아키텍처의 최소 단위입니다.
마치며
에이전트는 대화형 AI의 조금 더 똑똑한 버전이라고만 보기 어렵습니다. 에이전트가 들어오면 질문의 단위가 답변에서 행동으로 바뀌고, 행동의 단위가 작업에서 워크플로로 확장됩니다.
그래서 필요한 것도 달라집니다.
- 목표와 완료 조건
- 프로젝트 규칙과 작업 기억
- 반복 절차를 담은 Skill
- 독립 작업을 나누는 Subagent
- 실행 전후의 Hook
- 외부 도구와 지식을 연결하는 MCP
- 결과를 확인하는 테스트와 사람의 승인
이 구성요소들이 모두 필요한 것은 아닙니다. 작은 글 한 편에는 규칙 파일과 간단한 검증만으로 충분할 수 있습니다. 중요한 것은 업무가 복잡해질 때 어느 계층을 추가해야 하는지 알고 있는 것입니다.
에이전트에게 일을 맡긴다는 말은 결국 “AI가 사람을 대신한다”는 선언이라기보다, 일을 어떤 단위로 쪼개고 어디에 통제 지점을 둘 것인지 결정한다는 뜻에 가깝습니다.
앞으로도 저는 새로운 에이전트 기능을 볼 때마다 “얼마나 자율적인가?”만 묻지는 않으려 합니다. 무엇을 읽고, 어떤 규칙을 따르고, 어느 도구를 호출하며, 어디에서 멈추고, 결과를 어떻게 증명하는지를 먼저 보려고 합니다.
그 질문에 답할 수 있을 때, 에이전트는 신기한 데모를 넘어 운영 가능한 디지털 아키텍처의 한 구성요소가 됩니다.