FunctionGemma 엔지니어링 2

지난 글

https://zeroact.tistory.com/41

FunctionGemma 엔지니어링 1

 

FunctionGemma는 Google에서 공개한 Gemma3 모델이다. 근데 이제 Function Calling을 곁들인.

공식문서에서 말하고 있는 것처럼 그냥 쓰면 별 볼일 없는 모델이다.

근데 파인튜닝을 한다면 270m 라는 매우매우 작은 크기로도 Function Calling에 있어서는 매우 강력한 성능을 낼 수 있다.

 

Function Calling

https://huggingface.co/datasets/google/mobile-actions

해당 데이터셋은 도구 리스트, 유저 질문,  정답 도구 호출 스펙 총 세개로 구성되어 있다.

각각의 예시를 보면 단번에 Function Calling 을 이해할 수 있다.

도구 리스트
- name: show_map, description: 지도 보여주기, parameter: location (위치)
- name: open_wifi_settings, description: wifi 설정 열기, paramter: -
- name: create_calendar_event, description: 달력 이벤트 생성하기, parameter: title (제목), datetime (일시)

유저 질문
- 2025년 12월 27일 저녁 6시에 채현이와 저녁 약속 알람 맞춰줘.

정답 도구 호출 스펙
- { "name": "create_calendar_event", "arguments": { "title": "채현 저녁 약속", "datetime": "2025-12-27T18:00:00", ... }

 

LLM은 도구 리스트와 유저 질문을 입력으로 받고 필요한 도구 호출 스펙을 출력할 수 있는 능력이 있다.

이는 어디에 프로그래밍 되어 있는 것이 아니라 도구 호출 스펙도 텍스트(자연어)이기 때문에 구조화된 포맷으로 텍스트를 출력하게끔 학습하면 되는 것이다.

이 능력(?)은 tool calling, structured output, function calling 등 다양한 이름으로 불리는데 구글은 Function Calling이라는 용어를 쓰기로 한 것 같다.

 

공식문서에 있는 다음 그림을 보면 더 자세히 알 수 있다.

TURN1: DEVELOPER

- 도구를 언제 써야하는지 무슨 파라미터들이 있는지가 설명된 프롬프트를 준다.

TURN2: USER

- 사용자의 요청을 입력 받는다.

TURN3: MODEL

- 필요한 도구 호출 스펙을 출력한다.

(APPLICATION LOGIC: System)

(- 도구 호출 스펙으로 실제 API 혹은 함수를 호출한다.)

TURN4: DEVELOPER

- 프롬프트에 도구 호출 결과를 삽입한다.

TURN5: MODEL

- TURN2, TURN4 각각의 요청과 도구 호출 결과를 사용해 응답을 생성한다.

 

실제 도구 호출이 어떤 타이밍에 어떻게 동작하는지 잘 이해할 수 있게 설명된 그림인 것 같다.

MCP를 사용하는 챗봇들도 다 이런 흐름으로 동작한다.

 

FunctionGemma

구글에서 발표한 FunctionGemma는 일반 대화를 위한 Gemma3 270M과 완벽하게 동일한 모델이지만 Function Calling 을 위해 학습된 모델이다.

모델 크기가 매우 작기때문에 대화까지 잘 하면서 Function Calling 까지 잘 하기는 어렵다.

때문에 의도적으로 용도를 분리한 것 같고 매우 효율적이며 미래 지향적 접근법인 것 같다.

(오히려 이걸 보여주려고 270M 모델을 출시한 것이 아닌가 하는 합리적 의심이 든다.)

 

공식 문서에서도 볼 수 있듯 General한 성능이 뛰어나지는 않다.

다만, 파인튜닝을 한다면 개인 디바이스에도 쉽게 올릴 수 있는 크기의 훌륭한 모델이 탄생한다.

google/mobile-actions 데이터 셋 평가 결과

 

 

아직 multi-step, multi-turn 등 모델 크기에서 오는 한계점들이 몇가지 있는데, 정말 순식간에 (어쩌면 2026년 상반기에) 다 해결될 문제들이기에 다루지 않겠다.

 

Conclusion

최근 Dify, n8n, Flowise 같은 Agent 생성 도구들을 다루고 있는데, 쿼리를 보고 Flow를 분기해야하는 경우나 내부 API 호출을 해야할 때 크기가 큰 일반 대화용 모델을 사용하는 것이 큰 걸림돌이었다.

비용적인 문제로 여러가지 모델을 올릴 수 없는 상황에 이런 용도로 다른 모델을 쓰자니 여전히 무겁고, gpt-oss 같은 성능 좋은 reasoning 모델을 쓰기에는 시간이 너무 오래걸리고 호환성도 떨어졌다.

 

Function Calling은 무한한 가능성이 있는 LLM 활용 방법이다.

예시처럼 휴대폰 API를 호출해서 정말 똑똑한 빅스비나 siri를 만들수도 있고,

레거시 서비스의 API 문서를 학습시켜 손쉽게 Agentic AI 를 실현할 수도 있고,

더 나아가 로봇 팔 제어 도구의 스펙을 학습시켜 팔을 움직이게 할 수도 있다.

 

1편에서 말한 것처럼 단순한 AI 활용에서 AI 엔지니어링으로 전환되는 중요한 시기인 것 같다.

다음 3편에서는 FunctionGemma 를 위한 커스텀 데이터 생성부터 직접 파인튜닝까지 해볼 예정이다.