“AI가 회의실을 예약해 줬습니다.” 이런 말을 들으면 AI가 예약 시스템에 들어가 직접 버튼을 누른 것처럼 느껴집니다. 그런데 Function calling처럼 AI에 앱의 기능을 붙이는 방식에서는(이 글에서 함수는 앱이 미리 만들어 둔 기능 하나를 뜻하고, 도구와 같은 말로 씁니다), 실제로 예약을 실행하는 쪽이 AI가 아니라 앱입니다.
가상의 사내 도우미 앱을 하나 생각해 보겠습니다. 직원이 “내일 오후 3시에 회의실 잡아 줘”라고 쓰면 앱이 예약까지 마쳐 줍니다. 겉으로는 AI가 한 번에 처리한 것처럼 보이지만, 안에서는 AI와 앱이 일을 나눠 맡습니다. 누가 무엇을 맡았는지 모르면, 예약이 잘못됐을 때 어디를 고쳐야 할지도 알기 어렵습니다.
OpenAI API의 Function calling을 예로 들어 그 분업을 살펴보겠습니다. Function calling은 개발자가 앱을 만들 때 쓰는 기능입니다. 다만 AI가 예약·조회·등록 같은 일을 대신 처리해 주는 서비스를 쓰거나 검토하는 분이라면, 같은 구분으로 “누가 실행했나”를 물어볼 수 있습니다. 끝까지 읽으면 회의실 예약 기능 하나로 이 분업을 점검표에 채워 볼 수 있습니다.
모델은 함수를 부르지 않고, 불러 달라고 요청합니다
OpenAI의 Function calling 가이드는 이 기능을 모델이 외부 시스템과 연결되고, 학습 데이터 밖의 정보에 접근하는 방법이라고 소개합니다. 이름에 ‘함수 호출’이 들어 있지만, 모델이 함수를 직접 실행한다는 뜻은 아닙니다.
여기서 모델은 앞에서 말한 AI, 즉 질문을 읽고 답을 만드는 언어 모델을 가리킵니다. 앱은 그 모델을 불러 쓰는 프로그램입니다. 가이드가 정의하는 도구 호출(tool call)은 모델이 내놓는 특별한 형태의 응답입니다. 모델은 질문을 살펴보고, 지시를 따르려면 앱이 알려 준 도구 중 하나가 필요하다고 판단하면 “이 함수를 이 값으로 불러 달라”는 응답을 돌려줍니다. 실행은 그 응답을 받은 앱이 합니다. 가이드는 이 흐름을 다섯 단계로 설명합니다.
- 앱이 부를 수 있는 도구 목록과 함께 모델에 요청을 보냅니다.
- 모델이 도구 호출을 돌려줍니다.
- 앱이 그 호출에 담긴 값으로 자기 쪽 코드를 실행합니다.
- 앱이 실행 결과를 담아 모델에 다시 요청합니다.
- 모델이 최종 답을 돌려줍니다. 도구 호출을 더 돌려줄 수도 있습니다.
회의실 예시에 대입하면 이렇습니다. 앱은 처음에 ‘회의실 예약’ 함수가 있다고 모델에 알려 줍니다. 모델은 직원의 문장을 읽고 날짜, 시각, 회의실 같은 값을 채워 그 함수를 불러 달라고 요청합니다. 예약 시스템에 실제로 기록을 남기는 것은 앱의 코드입니다.
형식이 맞는 요청도 값은 다시 봐야 합니다
모델이 돌려주는 호출에는 함수 이름과 인자, 즉 함수에 넘길 값이 들어 있습니다. 가이드에 따르면 인자는 JSON 형식의 문자열(‘이름: 값’ 쌍을 정해진 문법으로 적은 글자)로 오고, 앱이 이를 읽어 들여 씁니다. 함수마다 어떤 값을 받는지는 개발자가 JSON 스키마로 정해 둡니다. 스키마는 ‘날짜는 이런 형식, 회의실은 이 목록 중 하나’처럼 값의 모양을 정한 규칙입니다.
가이드는 strict 설정을 켜면 호출이 이 스키마를 안정적으로 따르게 된다고 설명합니다. 가이드의 표현으로는, 이 설정이 없으면 최선을 다해 맞추는 수준(best effort)입니다. 다만 스키마가 정하는 것은 값의 모양입니다. 날짜 칸에 날짜 형식이 들어오는 것과, 그 날짜가 직원이 말한 ‘내일’과 같은 날인지는 다른 문제라고 저는 봅니다. 형식 검사를 통과한 요청이어도 회의실 이름이나 시각이 사용자의 뜻과 맞는지는 앱이 따로 확인해야 합니다. 모델이 사용자의 뜻을 잘못 읽었을 수 있으니, 모델이 채운 값을 사람에게 보여 주고 확인받는 방법이 있습니다. 이 방법은 다음 PART에서 다룹니다.
가이드의 함수 정의 모범 사례에도 같은 방향의 조언이 있습니다. 함수 이름과 인자 설명을 명확하고 자세하게 쓰고, 정해진 목록(열거형, enum)을 써서 애초에 있을 수 없는 값이 들어오지 않게 하라고 권합니다. 회의실을 자유 입력 대신 ‘3층 회의실, 5층 회의실’ 같은 목록에서 고르게 하는 식입니다. 앱이 이미 아는 값은 모델에게 채우게 하지 말라는 조언도 있습니다. 예약하는 직원이 누구인지는 로그인 정보로 앱이 알고 있으니, 모델이 문장에서 추측하게 둘 이유가 없습니다.
실행할지, 그 사람에게 권한이 있는지는 앱이 확인합니다
모델의 요청을 받은 뒤 실제로 실행할지는 앱의 코드가 결정합니다. 요청이 왔다고 해서 그대로 실행해야 하는 것은 아닙니다. 회의실 예약이라면 그 직원이 예약할 권한이 있는지, 그 시간이 비어 있는지는 예약 시스템이 이미 아는 사실입니다. 이런 확인은 모델의 판단에 맡기기보다 앱의 코드에서 하는 편이 정확합니다.
예약처럼 되돌리기 번거로운 일은 실행 전에 사용자에게 한 번 더 보여 주는 단계를 넣을 수도 있습니다. “내일 10월 4일 오후 3시, 3층 회의실로 예약할까요?”처럼 모델이 채운 값을 사람이 확인하게 하는 방식입니다. 가이드는 이런 확인 절차를 따로 다루지 않습니다. 그래서 이 단계는 앱을 기획하는 쪽이 정해야 할 부분입니다.
모델이 도구를 언제 쓰게 할지도 앱이 조절합니다. 가이드의 tool_choice 설정은 기본값이 모델이 알아서 판단하는 것이고, 아예 부르지 못하게 막을 수도 있습니다. 회의실 예시라면 직원이 “회의실 예약은 어떻게 해요?”처럼 방법만 물을 때는 함수를 부르지 않고 설명만 하는 게 맞습니다. 기본값에서는 그 판단을 모델이 하므로, 함수 설명에 언제 부르는지를 분명히 적어 두는 편이 좋습니다. 가이드도 함수를 언제 쓰고 언제 쓰지 말아야 하는지 지시문에 적으라고 권합니다.
실행 결과는 앱이 돌려줘야 답이 됩니다
앱은 실행을 마친 뒤 결과를 모델에 다시 보냅니다. 가이드에 따르면 이 결과는 function_call_output이라는 항목으로 보내고, 모델의 어느 호출에 대한 결과인지 call_id로 짝을 지어 줍니다. 결과는 보통 문자열이고, 형식은 JSON이든 오류 코드든 일반 문장이든 개발자가 정합니다.
이 단계가 중요한 이유는 모델이 최종 답을 쓸 때 앱이 돌려준 결과를 보고 쓰기 때문입니다. 예약이 이미 찬 시간이라 실패했다면, 앱은 실패했다는 사실을 결과에 담아 보내야 합니다. 모델은 앱이 돌려준 결과를 보고 답을 쓰기 때문에, 실패를 알리지 않으면 예약이 됐다는 답을 만들 수도 있습니다. 이 부분은 가이드의 흐름에서 끌어낸 필자의 해석입니다. 반대로 앱이 결과를 정직하게 돌려주면, 모델은 “그 시간은 이미 예약돼 있습니다. 4시는 비어 있습니다”처럼 다음 선택지를 안내할 수 있습니다.
그래서 “AI가 예약했다”는 답을 받았다면, 확인할 곳은 대화창이 아니라 실행 기록입니다. 사용자라면 예약 시스템의 내 예약 목록을, 앱을 만드는 쪽이라면 실행 로그를 봅니다. 실제로 기록이 남았는지, 남은 값이 사용자가 말한 날짜와 시각인지 봅니다. AI 기능을 기획한다면 함수마다 네 가지를 한 줄씩 적어 보시길 권합니다. 모델이 채울 값, 앱이 이미 아는 값, 실행 전에 사람이 볼 것, 실패했을 때 돌려줄 문장입니다. 이 네 칸이 정해지면 모델이 할 일과 앱이 책임질 일이 나뉩니다. 이 글의 회의실 예약 함수로 채우면 이렇습니다.
| 칸 | 회의실 예약 함수 |
|---|---|
| 모델이 채울 값 | 날짜, 시각, 회의실 |
| 앱이 이미 아는 값 | 예약하는 직원(로그인 정보) |
| 실행 전에 사람이 볼 것 | “내일 10월 4일 오후 3시, 3층 회의실로 예약할까요?” |
| 실패했을 때 돌려줄 문장 | 그 시간은 이미 예약돼 있다는 사실 |
이 글은 AI의 도움을 받아 작성했습니다.
참고 자료
이 글의 기능 설명은 2026년 10월 3일 공식 문서 기준입니다.
- OpenAI Function calling: https://developers.openai.com/api/docs/guides/function-calling