Young Log

[1] LLM 호출
    ↓
[2] LLM이 "파일 X의 23번째 줄 수정" 같은 지시 생성
    ↓
[3] 에이전트 프로그램이 실제 파일 수정
    ↓
[4] 터미널에서 테스트 실행
    ↓
[5] 결과 다시 LLM에 전달
    ↓
[6] 반복

Tool Calling

{
  "tool": "run_command",
  "command": "mvn test"
} // 모델이 생성한 의사결정 결과

LLM은 텍스트 대신 “이 도구를 이 인자로 호출해”라는 구조화된 요청을 만들어낸다.

에이전트는 그걸 실제로 실행 후 결과를 다시 모델에게 전달

도구 정의(스키마 제공)

에이전트가 쓸 수 있는 도구 목록
name, description, parameters(JSON Schema)

{
  "name": "run_command",
  "description": "Run a shell command",
  "parameters": {
    "type": "object",
    "properties": {
      "command": { "type": "string" }
    },
    "required": ["command"]
  }
}

모델 호출
1. 유저 요청 + 도구 목록
모델이 tool call 생성
1. 모델의 판단으로 도구가 필요한 상황이라면 → 도구 name + 인자(JSON) 생성
에이전트 실행
1. 에이전트가 파일 수정 및 mvn test 같은 명령 실행하거나 DB/API 호출
tool 결과를 모델에게 전달
1. 실행 결과(표준출력, 에러 로그, 파일 diff 등) 전달 후 다음 행동 진행
refeat

즉, 모델은 OS를 직접 건드는 것이 아니라, 호출 요청을 만든다.
실제 권한은 에이전트가 가진다.
그래서 보안 설정 중요. → 모델 신뢰 금지, 에이전트로 항상 검증하기

LLM = 의사결정 엔진
Agent Runtime = 실행 엔진
Tool Schema = 행동 가능 범위
Loop = 자율성

MCP(Model Context Protocol)와의 차이

에이전트가 외부 도구 혹은 데이터에 연결하는 방식을 표준화한 프로토콜

구성

MCP Client: Claude Code 같은 에이전트/IDE/챗봇
MCP Server: GitHub, DB, 파일시스템, Jira 같은 “툴/데이터”를 제공하는 서버

Tool Calling이랑 MCP 모두 도구 호출하지만 초점이 다름

Tool Calling(함수 호출):

“내 앱 안에서 내가 정의한 함수/도구”를 모델이 호출하게 만드는 방식 (앱-모델 중심)
MCP:

“툴/데이터 연결을 표준 프로토콜로 만들어서”

에이전트가 서버만 바꿔 끼우면 다양한 툴을 쉽게 붙이게 해주는 생태계 방식 (클라이언트-서버 표준)
Tool Calling은 내가 만든 도구를 모델이 호출하게 하는 기능
MCP는 도구/데이터 연결을 ‘플러그 규격’처럼 표준화한 것

모델은 어떻게 도구 필요 여부를 결정하는가?
1. 모델은 확률적으로 판단
  1. 도구 목록과 설명을 프롬프트로 받게 되면, 모델은 이걸 설명으로 끝낼지, 실행이 필요할지 고민 → 모델에게 이런 학습 패턴이 이미 존재
  2. “테스트 돌려서 실패 원인 고쳐줘”
    1. 수정 필요 OK
    2. 테스트 실행 OK
    3. 텍스트로는 해결 불가 → Tool call 생성
  3. 그런데 잘못 판단한다면?
    1. 에이전트 설계의 중요성
    2. 제어 방법
      1. 화이트리스트: 허용된 명령어만 실행
        
        rm 금지
        
        네트워크 호출 제한
        
        특정 디렉토리만 수정 가능
      2. 승인 모드: 실행 전에 물어봄
      3. 루프 제한: 최대 반복 횟수 제한
      4. 결과 검증 레이어
그래서 멀티 에이전트가 필요한 이유?
1. 단일 에이전트
```
생각 → 실행 → 결과 → 생각 → 실행
```
  생각과 구조 섞임, 테스트 논리 꼬임, 맥락과 순서 손실
2. 멀티 에이전트
```
Planner → 설계
Coder → 구현
Tester → 검증
Reviewer → 품질 체크
```
  사고 분리, 병렬 가능, 역할 전문화
  
  고비용, 복잡도 업, 디버깅 어려움