# 좋은 AI Agent란? Quality · Latency · Cost 세 축으로 설계하기

Author: Jaeho Shin / 신재호
Date: 2026-09-08
Updated: 2026-09-12
Category: Agents
Canonical: https://www.viberick.com/notes/what-makes-a-good-agent

System prompt, tools, skills, MCP, subagent를 어떻게 조합해야 실제 일을 끝내는가. Claude Code를 예로 보는 Agent 설계.

## Workflow overview

1. 맥락·목표
2. 도구·행동
3. 결과 관찰
4. 검증·중단

Agent 실행 루프. Skills는 절차, MCP는 연결, subagent는 분리된 작업이며 셋 다 모든 작업에 필요한 것은 아니다.


## Agent는 무엇인가

**Agent는 모델이 다음 행동을 선택하고, 도구의 실행 결과를 관찰하면서 완료 조건까지 반복하는 시스템이다.** 채팅 UI가 있다고 Agent가 되는 것은 아니다. 정해진 순서대로만 실행하는 워크플로가 더 적합한 일도 많다.

Anthropic은 미리 정한 경로를 따르는 workflow와 모델이 과정·도구 사용을 동적으로 결정하는 agent를 구분하고, 필요한 만큼만 복잡성을 더하라고 권한다. [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents).

고객에게는 용어보다 결과가 중요하다. 답변을 만들었는지, 예약을 조회했는지, 실제로 메시지를 발송했는지는 서로 다른 완료 상태다.

## 항상 세 축을 같이 본다

**Quality:** 정답, 근거, 실행 결과와 권한 준수. **Latency:** 사용자가 기다리는 시간과 업무가 끝나는 시간. **Cost:** 모델·도구·인프라·재시도·사람의 검수까지 포함한 비용.

CS에서는 첫 응답이 빠르고 확정된 안내가 정확해야 한다. 복잡한 개발에서는 조금 더 기다려도 재현 테스트를 통과하는 것이 중요할 수 있다. 야간 일괄 처리에서는 실시간 반응보다 전체 처리량과 실패 복구를 우선할 수 있다. 같은 모델 순위로 셋을 평가하지 않는다.

세 축 사이에 보편적인 승자는 없다. 품질 최소선을 먼저 정하고, 그 선을 지키는 선택지에서 지연과 비용을 비교한다. 이 글의 프레임워크는 VibeRick의 설계 기준이며 공급자 벤치마크 점수를 옮긴 것이 아니다.

## System prompt: 업무 계약

시스템 프롬프트에는 누구를 돕는지, 어떤 근거를 쓸지, 어디까지 행동할지, 무엇을 확인해야 끝인지 적는다. “세계 최고의 전문가처럼 행동해”보다 다음 규칙이 운영에 도움이 된다.

```text
확정된 FAQ와 현재 조회 결과만 근거로 답한다.
자료에 없는 가격·예약 가능 여부는 추측하지 않는다.
조회, 초안 작성, 외부 발송을 별도 행동으로 취급한다.
실행 도구가 성공을 반환하기 전에는 완료했다고 말하지 않는다.
```

프롬프트는 보안 장치의 대체재가 아니다. 다른 사업장에 접근할 수 없게 하는 것은 서버의 인증·권한 검사다. 모델이 실수해도 넘어갈 수 없는 경계를 코드로 만든다.

## Tools: 작고 확인 가능한 행동

좋은 도구는 입력·출력과 실패 상태가 명확하다. “사업장 업무 전부 처리”보다 “오늘의 확정 예약 조회”, “문의 초안 저장”, “승인된 메시지 발송”처럼 구분하는 편이 검수하기 쉽다.

조회 도구는 출처와 기준 시각을 반환한다. 변경 도구는 대상 ID, 승인 조건과 중복 실행 방지 키를 받는다. 타임아웃이 발생했을 때 실패인지, 실제 반영은 되었지만 응답만 사라졌는지도 확인할 경로가 필요하다.

도구를 많이 연결했다고 품질이 좋아지는 것은 아니다. 비슷한 이름의 도구가 여럿이면 잘못 선택할 여지가 커진다. 첫 버전은 가장 자주 쓰는 행동 몇 개로 시작한다.

## Skills와 MCP는 다른 층이다

**Skill은 반복 업무를 수행하는 방법**이다. Claude Code에서는 `SKILL.md`에 절차와 참고 자료를 두고 필요한 작업에 연결할 수 있다. 매번 긴 지침을 다시 설명하는 대신 검증한 절차를 프로젝트에 남기는 것이다. [Claude Code Skills](https://code.claude.com/docs/en/skills).

**MCP는 외부 도구와 자료를 연결하는 규약**이다. 예를 들어 이슈 검색 도구를 연결할 수 있지만, 무엇을 검색하고 어떤 결과를 신뢰할지는 업무 설계의 문제다. MCP 서버를 추가하는 것만으로 권한·품질·안전성이 보장되지는 않는다. 신뢰할 서버와 최소 권한을 선택한다. [Claude Code MCP](https://code.claude.com/docs/en/mcp).

Skill이 절차이고 MCP가 연결이라면, 둘의 결과를 판단하고 다음 행동을 결정하는 것은 Agent의 실행 루프다. 세 가지를 동의어로 쓰지 않는다.

## Subagent: 독립된 일을 분리할 때

Subagent는 별도 컨텍스트와 역할로 일을 맡는 실행 단위다. Claude Code는 도구·모델·권한 등을 다르게 구성한 subagent를 지원한다. 독립 리서치나 제한된 리뷰를 분리할 수 있다. [Subagents](https://code.claude.com/docs/en/sub-agents).

병렬화가 항상 더 빠르거나 싸지는 않다. 같은 자료를 각각 읽으면 입력이 중복되고, 결과를 합치는 검수도 필요하다. 같은 파일을 동시에 고치거나 앞 작업 결과에 의존하는 일을 억지로 나누면 충돌이 늘 수 있다.

내 기준은 세 가지다. 독립적으로 완료 가능한가, 입력과 산출물이 명확한가, 합치는 사람이 검증할 수 있는가. 하나라도 불명확하면 단일 Agent로 먼저 만든다.

## Claude Code가 좋은 학습 사례인 이유

Claude Code는 파일을 읽고 수정하고 명령을 실행한 뒤 테스트 결과를 다시 관찰하는 과정을 보여준다. 모델만이 아니라 도구, 컨텍스트 관리와 실행 환경이 함께 있는 coding harness다. [작동 방식](https://code.claude.com/docs/en/how-claude-code-works).

여기서 배울 것은 특정 터미널 화면이 아니다. “읽기 → 행동 → 검증”의 반복이다. [InnerCoach](/work/innercoach)는 강의와 사용자 맥락, [몸톡](/work/bodiology)은 교재 페이지와 인용, [OpsDesk](/work/opsdesk)는 사업장 규칙과 이관 결과가 그 루프의 관찰 대상이 된다.

## 평가표는 배포 전에 만든다

[소담의 메일 CS 사례](/notes/inzeum-sodam-email-cs)에서는 메일 수집, 답변 초안, 담당자 연결과 최종 회신을 서로 다른 완료 단계로 구분했습니다. [자막 추출기](/notes/audio-subtitle-editing)는 전사·교정·정렬·분할을 나눠 검증합니다. 하나는 운영 에이전트이고 다른 하나는 처리 파이프라인이지만, 결과를 확인 가능한 단계로 나누는 원칙은 같습니다.

다음은 출발용 평가 설계다. 실제 점수나 운영 성과가 아니다.

- 정상 요청: 필요한 근거와 결과가 모두 있는가.
- 모르는 요청: 그럴듯하게 만들어내지 않고 확인·이관하는가.
- 도구 실패: 실패를 숨기거나 완료로 표현하지 않는가.
- 권한 밖 요청: 다른 고객 자료나 승인 없는 변경을 차단하는가.
- 반복 실행: 같은 발송·결제를 두 번 하지 않는가.
- 긴 대화: 초기 업무 조건을 잃거나 불필요한 도구 호출을 늘리지 않는가.

각 요청에 통과 조건, 전체 시간, 모델·도구 비용과 사람의 수정 여부를 붙인다. 스트리밍 첫 글자가 빨라도 실제 처리가 끝나지 않았다면 완료 지연은 줄지 않았다.

## 언제 더 복잡하게 만들까

단일 Agent의 평가에서 구체적인 실패가 보일 때 확장한다. 자료를 못 찾으면 검색을, 반복 절차를 잊으면 Skill을, 외부 시스템이 필요하면 도구 연결을, 독립 작업이 병목이면 subagent를 검토한다.

다음 기능 목록부터 만들지 말자. **어떤 실패를 줄일 것인지**가 다음 설계의 이유여야 한다. 첫 구축에서는 한 업무, 작은 도구 집합, 명시적인 승인과 평가표가 충분히 강한 출발점이다.