AI를 써먹기 위한 최소 지식 6편: Tool Calling과 Agent

Tool Calling과 Agent의 차이, 개발 자동화에서 tool 권한을 나누는 방법, 실행 로그와 승인 흐름을 정리합니다.

목차

지난 글에서는 AI가 필요한 문서를 찾아 참고하는 RAG 흐름을 정리했습니다.

이제 한 단계 더 나아가보겠습니다.

AI가 답변만 하는 게 아니라 실제로 도구를 호출한다면 어떻게 될까요?

예를 들어:

- 파일 검색
- 파일 읽기
- 코드 수정
- 테스트 실행
- 빌드
- 배포
- 외부 알림 전송

이런 일을 AI가 직접 할 수 있다면 단순한 챗봇이 아니라 작업 에이전트에 가까워집니다.

Tool Calling은 함수 호출에 가깝다

Tool Calling은 모델이 외부 도구를 호출할 수 있게 하는 구조입니다.

예를 들어 이런 tool이 있다고 해보겠습니다.

{
  "name": "read_file",
  "description": "Read a file from the repository",
  "inputSchema": {
    "type": "object",
    "properties": {
      "path": { "type": "string" }
    },
    "required": ["path"]
  }
}

모델은 답변을 생성하다가 "이 파일을 읽어야겠다"고 판단하면 tool을 호출합니다.

{
  "path": "src/index.js"
}

그리고 tool 실행 결과를 다시 받아 다음 판단에 사용합니다.

흐름은 대략 이렇습니다.

사용자 요청
-> 모델이 필요한 tool 선택
-> tool 실행
-> 결과를 모델에 전달
-> 다음 답변 또는 다음 tool 호출

중요한 건 tool이 모델의 말과 다르다는 점입니다.

모델의 설명은 텍스트지만, tool 호출은 실제 외부 작업입니다.

Agent는 여러 tool을 묶어 목표를 수행한다

Tool Calling 하나만으로도 유용합니다.

하지만 Agent는 보통 여러 tool을 연속으로 사용합니다.

예를 들어 "문서 사이트의 한 페이지를 업데이트해줘"라는 목표가 있으면:

1. 대상 Markdown 파일 읽기
2. 필요한 메타데이터 수정
3. 한국어/영어 파일 모두 확인
4. 검토용 preview 생성
5. 공개 대상 파일만 포함됐는지 확인
6. 배포 실행
7. 운영 URL 200 확인
8. 결과 보고

이건 단일 함수 호출이 아니라 작업 흐름입니다.

Agent의 핵심은 이 흐름을 계획하고, 중간 결과에 따라 다음 행동을 고르는 데 있습니다.

모든 tool의 위험도는 같지 않다

AI에게 tool을 열어줄 때 가장 중요한 건 권한 구분입니다.

모든 tool을 같은 수준으로 보면 위험합니다.

그래서 tool 설계에서는 "무엇을 할 수 있는가"만큼 "어디까지 허용할 것인가"가 중요합니다.

예를 들어 비공개 검토 환경 반영은 허용하더라도, 공개 발행은 별도 승인 후 하게 만들 수 있습니다.

개발 자동화에서는 tool을 작게 나누는 편이 낫다

처음에는 do_everything 같은 tool 하나로 끝내고 싶어질 수 있습니다.

{
  "name": "publish_page_update",
  "description": "Review, generate, deploy, and publish a page update"
}

편해 보이지만, 운영 관점에서는 별로 좋지 않습니다.

이 tool 하나 안에 파일 수정, 검증, 배포, 공개 발행이 모두 들어가면 문제가 생겼을 때 어디서 잘못됐는지 추적하기 어렵습니다. 더 위험한 건 "검토만 해줘"라고 했는데 내부적으로 공개 반영까지 실행될 수 있다는 점입니다.

그래서 저는 이런 식으로 쪼개는 쪽이 더 낫다고 봅니다.

read_page
update_draft
generate_preview
run_checks
deploy_preview
publish_page
notify_result

이렇게 나누면 각 tool의 위험도가 보입니다.

read_page는 거의 안전하지만, publish_page는 공개 상태를 바꾸는 작업입니다. 둘을 같은 권한으로 취급하면 안 됩니다.

작게 나눈 tool은 귀찮아 보이지만, 나중에 자동화가 커질수록 오히려 관리하기 편합니다. 어떤 단계에서 멈췄는지, 어느 단계에 승인이 필요한지, 어떤 결과를 로그로 남겨야 하는지가 분명해지기 때문입니다.

Agent에게 필요한 것은 자유가 아니라 경계다

Agent를 잘 쓰려면 무조건 많은 권한을 주는 게 답이 아닙니다.

오히려 경계가 명확해야 안정적으로 쓸 수 있습니다.

허용:
- 파일 읽기
- draft 글 작성
- 검토용 초안 생성
- 제한된 검토 환경 반영

승인 필요:
- published 전환
- 운영 DB migration
- main branch push
- 외부 공개 링크 추가

금지:
- 민감정보 출력
- unrelated file revert
- 사용자 변경사항 삭제

이런 경계가 있으면 AI가 할 수 있는 일과 사람이 결정해야 하는 일이 분리됩니다.

이건 불편한 제약이 아니라 운영 안전장치입니다.

tool 결과도 다시 확인해야 한다

Tool Calling을 쓰면 AI가 실제 결과를 받습니다. 하지만 tool 결과가 있다고 해서 항상 최종 판단까지 맞는 것은 아닙니다.

예를 들어 테스트 실행 tool이 성공했다고 해도, 실제로는 테스트 범위가 부족할 수 있습니다. 배포 tool이 성공했다고 해도, 운영 URL에서 CSS나 이미지가 깨질 수 있습니다. 파일 검색 tool이 결과를 반환했다고 해도, 더 중요한 파일을 놓쳤을 수도 있습니다.

그래서 Agent 흐름에서는 tool 실행 후에 항상 확인 단계가 필요합니다.

tool 실행
-> 결과 확인
-> 기대한 상태와 비교
-> 부족하면 추가 검색/수정
-> 위험하면 중단하고 보고

이 부분이 없으면 Agent는 "무언가를 실행하는 자동화"는 될 수 있어도, "믿고 맡길 수 있는 작업자"가 되기는 어렵습니다.

실행 로그는 반드시 남겨야 한다

Agent가 tool을 사용하면 로그가 중요해집니다.

그냥 "완료했습니다"만으로는 부족합니다.

최소한 아래 정보는 남기는 게 좋습니다.

{
  "time": "2026-05-10T12:05:00+09:00",
  "tool": "deploy.preview",
  "input": {
    "target": "preview-environment"
  },
  "result": {
    "status": "success",
    "versionId": "..."
  },
  "approval": "not_required"
}

이런 기록이 있으면 나중에 문제가 생겼을 때 추적할 수 있습니다.

특히 배포, 삭제, 공개 발행처럼 되돌리기 어려운 작업은 기록이 없으면 운영이 불안해집니다.

Agent 작업의 기본 루프

개발 작업에서 Agent는 보통 이런 루프로 움직입니다.

1. 계획
2. 필요한 파일/문서 검색
3. 관련 파일 읽기
4. 수정
5. 검증
6. 실패 시 원인 분석 후 재시도
7. 결과 보고

이 루프가 제대로 돌려면 각 단계에 tool이 필요합니다.

하지만 모든 단계를 자동으로 열어둘 필요는 없습니다. 위험한 단계는 승인이나 수동 확인을 끼워 넣는 편이 좋습니다.

정리하면

Tool Calling과 Agent는 AI를 "답변하는 도구"에서 "작업하는 도구"로 바꿉니다.

그만큼 설계가 중요해집니다.

1. Tool Calling은 모델이 외부 기능을 호출하는 구조다.
2. Agent는 여러 tool 호출을 묶어 목표를 수행하는 흐름이다.
3. tool마다 위험도가 다르므로 권한을 나눠야 한다.
4. Agent에게 필요한 것은 무제한 자유가 아니라 명확한 경계다.
5. 실행 로그와 승인 기록은 운영 안정성의 기본이다.

다음 글에서는 이렇게 실행한 결과를 어떻게 검증할지, Eval과 테스트 관점에서 정리해보겠습니다.