8.3에이전틱 커스터마이징

선택지를 먼저 정리합니다.

내장 툴 — 제공되는 기능을 켜서 씁니다. 웹 검색, 코드 실행 같은 것입니다. 만들 것이 없고 바로 씁니다. 대신 동작을 우리가 바꾸지 못합니다.

커스텀 툴 — 우리가 스키마를 정의하고 실행 코드를 씁니다. 사내 시스템에 붙을 때 유일한 방법입니다. 자유도가 가장 높고 손이 가장 많이 갑니다.

스킬 — 절차를 문서로 적어 두고 필요할 때 모델이 참조합니다. 코드 실행이 아니라 방법을 알려 주는 것입니다. 여러 도구를 조합하는 순서나 사내 규칙을 담기 좋습니다.

MCP — 도구를 서버로 분리해 여러 클라이언트가 공유합니다. 같은 도구를 여러 애플리케이션에서 써야 할 때 값을 합니다.

가장 자주 헷갈리는 것이 커스텀 툴과 스킬입니다. 툴은 실행하고, 스킬은 설명합니다. "청구서를 조회한다"는 툴이고, "청구 분쟁을 처리하는 순서"는 스킬입니다.

순서대로 물어 보면 대개 답이 나옵니다.

1. 이미 있는 기능으로 되는가? → 내장 툴.
2. 코드 실행이 필요한가, 설명이면 되는가? → 실행이 필요하면 툴, 설명이면 스킬.
3. 여러 애플리케이션에서 같은 것을 쓰는가? → 그렇다면 MCP로 분리.
4. 한 곳에서만 쓰는가? → 커스텀 툴로 직접.

여기서 자주 하는 실수가 처음부터 MCP로 만드는 것입니다. 한 곳에서만 쓸 도구를 서버로 분리하면 배포와 버전 관리 부담만 생깁니다. 두 번째 사용처가 생겼을 때 옮겨도 늦지 않습니다.

반대 실수도 있습니다. 절차 설명을 커스텀 툴로 만들려는 경우입니다. "이 순서로 처리하라"는 실행할 것이 없으므로 툴이 될 수 없고, 시스템 프롬프트에 넣으면 항상 로드되어 컨텍스트를 씁니다. 가끔 쓰는 긴 절차는 스킬이 맞습니다.

실무에서는 넷을 섞어 씁니다. 전형적인 구성이 있습니다.

• 사내 데이터 조회는 커스텀 툴 또는 MCP
• 공개 정보 조회는 내장 웹 검색
• 계산과 데이터 처리는 내장 코드 실행
• 업무 절차와 규칙은 스킬

이렇게 나누면 각자 잘하는 자리에 놓입니다. 사내 데이터를 웹 검색으로 찾을 수는 없고, 계산 로직을 커스텀 툴로 다시 만들 필요도 없습니다.

스킬이 툴을 부르는 구성이 특히 유용합니다. 스킬에 "먼저 A로 조회하고, 결과가 비어 있으면 B를 쓰고, 그다음 C로 기록한다"고 적어 두면, 모델이 도구 조합 순서를 매번 새로 판단하지 않아도 됩니다. 도구 설명만으로는 이런 순서를 전달하기 어렵습니다.

스킬 문서 예시
---
제목: 환불 요청 처리

1. search_orders 로 고객의 최근 주문을 확인한다.
2. 주문이 30일 이내이면 refund_order 를 호출한다.
3. 30일이 지났으면 환불 대신 create_ticket 으로 상담을 접수한다.
4. 어느 경우든 고객에게 결과와 근거를 함께 안내한다.

확장은 붙이기는 쉽고 떼기는 어렵습니다. 시간이 지나면 쓰지 않는 도구가 쌓입니다.

부작용이 분명합니다.

• 도구 정의가 매 요청에 실려 컨텍스트를 먹습니다.
• 선택지가 많아 오호출이 늘어납니다.
• 무엇이 무엇을 하는지 사람도 파악하기 어려워집니다.

정기적으로 점검하는 항목을 정해 둡니다. 최근에 호출된 적 있는지, 설명이 여전히 정확한지, 다른 도구와 역할이 겹치지 않는지입니다.

# 호출 기록으로 사용되지 않는 도구를 찾는다
unused = [t["name"] for t in tools
          if call_counts.get(t["name"], 0) == 0]

역할이 겹치는 도구는 특히 문제가 됩니다. 비슷한 두 도구가 있으면 모델이 매번 고민하고, 어느 쪽을 골랐는지에 따라 결과가 달라집니다. 합치거나 이름과 설명에서 차이를 분명히 해야 합니다.