AI 서비스를 기획할 때 기획자가 챙겨야 하는 영역들을 하나씩 짚어보고 있어요. 지난 편에서 AI에 브레이크를 다는 이야기를 했습니다. AI가 하면 안 되는 걸 못 하게 막는 가드레일이었죠. 이번 편은 정반대예요. AI가 무언가를 실제로 하게 만드는 이야기, 즉 손발을 붙여주는 이야기입니다.

1. AI는 '말'은 하는데 '일'은 못해요.

지난 편에서 우리는 AI 모델을 카페 직원에 비유했어요. 그런데 이 직원에게는 아주 큰 약점이 하나 있습니다. 말은 청산유수인데, 정작 일을 못 해요.

무슨 뜻이냐면, 지금의 AI(LLM이라고 부르는 언어 모델)는 본질적으로 글자를 만들어내는 일만 합니다. 질문을 이해하고, 그럴듯한 문장으로 답하는 건 기가 막히게 잘해요. 하지만 그 답을 넘어서 실제 세상에서 무언가를 하는 것, 예를 들면 메일을 보내거나, 예약을 잡거나, 결제하는 일은 직접 못 합니다.

이런 상황이에요. 아주 똑똑한 카페 직원이 있는데, 이 직원 앞에는 아무 장비가 없어요. 손님의 주문을 완벽하게 이해하고 "아, 그건 이렇게 해드리면 되겠네요"라고 설명까지 술술 해줘요. 그런데 정작 커피 머신도, 주문을 넣을 포스기도 없습니다. 그러니 말로 안내는 하는데, 실제로 커피 한 잔을 못 내려요.

그래서 우리는 이 직원에게 도구를 쥐여줍니다. 커피 머신, 포스기 같은 것들이요. "네가 말로 설명하는 데서 그치지 말고, 이 도구들로 실제로 주문까지 처리해줘"라고 하는 거죠. 이렇게 AI에게 쥐여주는 커피 머신, 포스기 같은 실행 수단, 그걸 업계에서 '도구(Tool)'라고 부릅니다.

2. 그 '일'은 사실, AI가 아니라 도구가 해요

여기서 기획자들이 가장 많이 오해하는 지점이 하나 있어요. 

"AI에게 도구를 쥐여줬다"고 하면, 보통 AI가 그 도구로 일까지 다 해낸다고 생각해요. 주문을 이해하는 것도, 실제로 처리하는 것도 전부 AI가 알아서 한다고요. 그런데 그렇지 않아요. AI가 하는 일은 딱 하나, "어떤 도구를 쓸지 고르는 것"까지예요. 실제로 그 도구를 돌려서 결과를 내는 건 AI가 아니에요.

카페를 떠올리면 금방 이해돼요. 우리 카페 직원은 바닐라 라떼 주문을 받으면, "샷은 에스프레소 머신으로 내리고, 우유는 스티머로 데운다"는 걸 알고 그렇게 선택해요. 하지만 정작 샷을 내리는 건 직원이 아니라 머신이에요. 원두를 갈아 샷을 뽑는 건 머신이 하는 일이죠.

즉, AI가 하는 건 "이 상황엔 이 도구를 써야 한다"고 고르는 판단이고, 실제로 돌아가서 결과를 내놓는 건 도구예요. 이 둘의 역할이 딱 나뉘어 있어요. 

비유는 잠깐 걷고 아래 시퀀스 다이어그램으로 실제로 누가 뭘 하는지 볼게요. 

AI는 고르고, 도구가 실행해요.

그런데 이런 질문이 들 수도 있어요.

왜냐하면 AI 모델은 우리 시스템에 손을 뻗을 수가 없기 때문이에요. 

AI 모델은 저 멀리 떨어진 곳에서 글자만 주고받는 존재예요. 우리 회사의 캘린더 서버, 회원 데이터베이스, 결제 시스템에 직접 연결되어 있지 않습니다. 애초에 접근 권한도, 연결 통로도 없어요. 우리 내부 시스템에 실제로 접속할 수 있는 건 우리가 만든 프로그램(시스템)뿐이에요.

그러면 이어서 이런 질문이 들 수도 있어요.

기술적으로는 열어줄 수 있어요. 하지만 그렇게 하면 안 돼요. 권한과 안전 때문이에요.

AI에게 우리 결제 시스템, 회원 데이터베이스, 서버에 직접 손댈 권한을 통째로 넘긴다는 건, 매장 금고 열쇠와 포스기 관리자 비밀번호를 신입 직원에게 몽땅 쥐여주는 것과 같아요. AI는 확률적으로 답을 만들어내는 존재라, 가끔 엉뚱한 판단도 해요. 그런 AI가 시스템에 직접 연결돼 있으면, 한 번의 실수가 '잘못된 답변'이 아니라 '잘못된 결제'로 곧장 이어져버려요. 되돌릴 수 없는 사고가 나는 거죠.

그래서 일부러 사이에 우리가 만든 프로그램을 한 겹 세워두는 거예요. AI는 "이 도구를 이렇게 써 달라"고 요청만 하고, 그 요청이 진짜 실행되어도 되는지는 우리 코드가 결정해요. 

3. 도구 하나가 쓰일 때, 뒤에서 오가는 세 가지

AI가 도구를 선택하고 백엔드 시스템이 실행한다는 건 알겠는데, 기획자는 여기서 대체 뭘 설계해야 할까요?

기획자는 서비스에 필요한 최소한의 도구 세트를 골라주고, AI가 판단할 수 있도록 도구 설명을 정교하게 적어주며, 승인이 필요한 행동이나 모호한 값이 들어왔을 때의 처리 기준을 정해야 합니다.

이 업무가 무엇인지 정확하게 이해하려면, 도구 하나가 작동할 때 뒤에서 순서대로 작성되는 세 가지 문서인 Tool Spec, Tool Call, Tool Response 개념에 대해서 알아야 합니다.

⚡️ 한눈에 보는 Tool Use 3단계 문서

1) Tool spec = 메뉴판 (빈 양식)

AI에게 "이런 도구가 있고, 쓰려면 이런 칸을 채워야 해"라고 미리 알려주는 설명서예요. 한 번 정의해두면 고정입니다. 예를 들어 '일정 등록' 도구의 설명서는 이렇게 생겼어요.

{
 "name": "register_event",
 "description": "사용자의 캘린더에 새 일정을 등록할 때 사용한다",   // ← AI가 이걸 읽고 '언제 쓸지' 판단
 "parameters": {
   "date":  { "type": "string", "description": "일정 날짜 (예: 2026-08-02)" },
   "time":  { "type": "string", "description": "시작 시각 (예: 15:00)" },
   "title": { "type": "string", "description": "일정 제목" }
 },
 "required": ["date", "time", "title"]                  // ← 반드시 채워야 하는 칸
}

핵심은 여기엔 아직 아무 값도 없다는 거예요. "date", "time" 같은 칸 이름만 있고 실제 값은 비어 있죠. 비유하자면 메뉴판에 "바닐라 라떼"라고 적혀 있지만, 아직 아무 손님도 주문하지 않은 상태와 같아요.

2) Tool call = 주문서 (AI가 값을 채운 것)

AI가 손님 말을 듣고, 메뉴판(Tool spec)의 빈 칸에 실제 값을 채워서 건넨 요청서예요. 손님 말이 들어올 때마다 새로 만들어집니다. "내일 3시 회의 잡아줘"라는 말은 이렇게 바뀌어요.

{
 "name": "register_event",       // ← 메뉴판에 있던 그 도구를
 "arguments": {
   "date":  "2026-08-02",        // ← 빈 칸이 실제 값으로 채워짐
   "time":  "15:00",
   "title": "회의"
 }
}

메뉴판의 빈 칸이 실제 값으로 채워졌죠. 즉 Tool spec은 빈 틀, Tool call은 그 틀에 값을 넣은 결과예요. 비유하자면 손님이 "바닐라 라떼, 디카페인으로요" 하고 주문서를 낸 것과 같아요.

3) Tool response = 주방에서 돌아온 결과 (실행 결과)

주문서(Tool call)를 받아 실제 우리 백엔드 시스템이 실제로 실행한 뒤, 그 결과를 AI에게 되돌려주는 것이에요. 성공했는지, 실패했는지도 알려줘요.

// 성공했을 때
{ "status": "success", "event_id": "evt_8842", "message": "일정이 등록되었습니다" }


// 실패했을 때
{ "status": "error", "reason": "그 시간에 이미 다른 일정이 있습니다." }

비유하자면 주방에서 "바닐라 라떼 나왔습니다” 또는 “디카페인은 현재 없어요"라고 알려주는 것과 같아요. AI는 이 결과를 읽고 나서야 손님에게 할 마지막 말("내일 3시에 회의 넣어뒀어요!")을 만들어냅니다.

정리하자면 이래요.

4. 그래서 기획자는 뭘 해요?

그렇다면 Tool Use를 설계할 때 기획자는 구체적으로 무엇을 정해야 하는지를 좀 더 구체적으로 설명해 볼게요.

1) 어떤 도구를 쥐여줄지 정합니다. 

직원에게 세상의 모든 장비를 다 안겨준다고 좋은 게 아니에요. 오히려 장비가 너무 많으면 뭘 써야 할지 헷갈려 엉뚱한 걸 집어 들죠.

그래서 "우리 서비스에서 AI가 할 수 있어야 하는 행동" 을 정의하고, 그걸 해낼 최소한의 도구 세트를 골라주는 게 기획자의 첫 일이에요. "이 서비스에서 AI가 예약은 잡되 결제는 못 하게 한다" 같은 경계를 긋는 거죠. 

2)도구를 '언제' 쓸지 판단 기준을 써줍니다.

범위가 정해졌다면 Tool spec에 나와있는 도구의 설명(description)을 작성합니다. AI는 이 설명을 읽고 도구를 쓸지 말지 판단해요.

그래서 이 설명이 사실상 기획 문서예요. 설명이 애매하면 AI는 엉뚱한 도구를 집어요. "이 도구는 이럴 때 쓰고, 이럴 땐 쓰면 안 된다"를 언어로 또박또박 정의해 주는 것이 바로 기획 문서의 핵심입니다.(앤트로픽도 🔗 공식 가이드 문서에서 "도구가 뭘 하고 언제 써야 하는지 상세히 쓰라"고 안내해요.)

3) 값이 모호할 때 어떻게 할지 정합니다.

AI가 주문서(Tool call)를 쓰려는데 필수 정보(required 파라미터)가 빠져있거나 모호할 때가 있어요. 예를 들어 "엄마한테 메시지 보내줘"라고 했을 때, AI는 '엄마'가 연락처의 누구인지 몰라 주문서의 칸을 못 채울 수 있어요.

그럴 때 되물을지("어머니 성함이 어떻게 되세요?"), 추측할지, 아니면 멈출지 — 이 정책을 기획자가 정해줘야 합니다. 모호함을 방치하면 엉뚱한 사람에게 메시지가 날아가요. (이건 다음 편 주제인 HITL과 곧바로 이어져요.)

4) '확인'이 필요한 도구를 가려냅니다.

같은 도구라도 무게가 달라요. 날씨 조회나 메뉴 안내는 그냥 실행해도 됩니다. 하지만 결제, 환불, 삭제, 메시지 전송처럼 한 번 하면 되돌리기 어려운 행동은, Tool call이 되어서 주문서가 완성되었더라도 실제 실행 전 손님에게 "이대로 진행할까요?"라고 확인하는 승인 단계를 설계해야 합니다.

어떤 도구가 "바로 실행"이고 어떤 도구가 "확인 필수"인지 분류하고, 그 확인 과정을 설계하는 게 기획자 일이에요.

5. AI의 '손발'은 어떻게 진화해 왔을까요?

사실 도구를 다루는 방식은 지난 3년간 계속 발전해왔어요. 도구가 진화해 온 맥락을 알면, 개발팀에 AI 도구 연결을 어떤 방식으로 요청해야 효율적인지 판을 짜는 눈이 생깁니다. 

2023년, Function Calling — 도구를 부르는 공통 문법 등장

처음엔 AI에게 "이런 도구를 써"라고 알려주려는데 문제가 있었어요. '도구를 어떻게 설명해줄 것인가'에 정해진 양식이 없었던 거죠. 회사마다, 개발자마다 제각각이었죠.

그러다 OpenAI가 2023년에 "도구를 이런 JSON 양식으로 정의하고, AI는 이런 JSON으로 호출한다"는 방식을 내놨고, 이게 사실상 업계 공통 문법이 됐어요. 이 AI와 도구가 주고받는 기본 문법을 'Function Calling'이라고 불러요. 우리가 앞서 본 Tool spec, Tool call, Tool response 정의가 바로 이 방식이에요. 

2024년, MCP — 한 번 만든 도구를 여기저기 쓸 수 있는 규격 등장

Function Calling으로 도구는 붙이게 됐는데, 새 불편함이 생겼어요. 양식이 회사마다 조금씩 달라서, 같은 도구도 AI가 바뀌면 매번 다시 만들어야 했거든요. '일정등록' 도구를 A사 AI용으로 만들고, B사 AI용으로 또 만들고… 도구 하나에 연결 코드를 몇 벌씩 짜야 했죠.

그래서 앤트로픽이 2024년 말에 MCP(Model Context Protocol) 를 내놨어요. 쉽게 말하면 도구를 꽂는 USB-C 규격이에요. 예전엔 기기마다 충전 단자가 달라 케이블을 따로 챙겨야 했지만, USB-C로 통일된 뒤엔 케이블 하나로 다 꽂히잖아요. MCP도 똑같아요. 도구를 MCP라는 표준 방식으로 한 번만 만들어두면, 어느 AI에든 USB 꽂듯 그대로 꽂아 쓸 수 있어요. 지금은 OpenAI, 구글도 지원할 만큼 사실상 표준이 됐고요.

MCP가 Function Calling을 없앤 게 아니에요. MCP 안에서도 도구는 Functional Calling과 동일한 방식으로 정의돼요. MCP는 그걸 '어떻게 꽂고 주고받을지'를 표준화했을 뿐입니다.

2025년, A2A — AI끼리 서로 일을 넘기는 협업 규칙 등장

여기서 한 발 더 나간 게 A2A(Agent2Agent)예요.

앞의 두 발전이 "AI ↔ 도구" 연결이었다면, A2A는 "AI ↔ 다른 AI" 연결이에요. 비유하자면 케이크 주문이 들어왔을 때 우리 카페 직원이 옆 가게 직원에게 "저희 손님이 케이크도 찾으시는데, 그쪽에서 하나 만들어 주실래요?"라고 직접 부탁하는 것과 같아요. 이때 각 AI는 자기가 뭘 할 수 있는지 적은 일종의 명함(Agent Card)을 주고받아, "쟤한테 이 일을 넘기면 되겠다"를 판단하죠.

말만 하던 챗봇에게 커피 머신과 포스기를 쥐여주는 순간 에이전트가 되고, 그 에이전트들이 서로 대화하기 시작한 게 지금의 AI예요.

결국 무엇을 하는 서비스가 될지는 '도구'가 정합니다

앞으로 우리가 만들 AI 서비스의 대부분은 결국 "어떤 도구를, 어떻게 쥐여줄 것인가"의 문제로 귀결돼요. 

예를 들어 '일정 등록' 도구 하나가 있을 땐 캘린더에 회의 추가하는 것 하나만 할 수 있었죠. 그러니까 "내일 3시 회의 잡아줘"만 처리할 수 있었어요. 그런데 여기에 도구를 하나씩 얹어볼게요.

똑같은 AI인데, 도구를 하나씩 붙일 때마다 서비스가 할 수 있는 일이 통째로 넓어집니다.

이렇게 "이 서비스가 무엇을 할 수 있는가"의 상한선은, 결국 "AI에게 어떤 도구를 쥐여줬는가"가 정합니다. 서비스의 상상력이 어디까지 뻗을 수 있느냐가, 사실은 "도구를 무엇으로, 몇 개나, 어떻게 열어줄 것인가"라는 설계에 달려 있는 거예요.

그래서 AI 서비스 기획은 점점 이 질문으로 수렴해요. "우리 서비스에서 AI가 실제로 '해낼 수 있어야 하는 일'은 무엇이고, 그걸 하려면 어떤 도구가 필요한가?" 이 질문에 답하는 게 바로 Tool Use 설계입니다. 그리고 판단은 기획자의 일이죠. 

그러니까 Tool Use는 "개발이 알아서 하는 기술"이 아니라, 기획자가 가장 깊이 관여해야 하는 설계 영역이에요. 여기서 서비스의 질이 갈려요. 똑똑하게 말만 하는 챗봇을 유능하면서도 미더운 '실행자'로 만드는 힘은, 결국 기획자의 정교한 도구 설계에서 나옵니다.

📮 다음 호 예고

[26호] 기획자를 위한 AI 설계 4부작 ③ Human-in-the-loop — AI가 사람에게 손 드는 순간

그런데 손발을 붙이고 나면 새로운 고민이 생겨요. AI가 값을 확신하지 못할 때, 혹은 되돌릴 수 없는 행동을 앞뒀을 때 — 그냥 AI에게 다 맡겨도 될까요? 아니죠. 중요한 순간엔 사람이 끼어들어야 합니다.

다음 편에서는 바로 그 이야기, AI가 사람에게 손을 드는 순간(HITL)을 다뤄볼게요.