🚀 [Project] AI 내 직원 만들기: Function Calling으로 실현하는 품질의 표준화

🎨 AI의 재능은 '창작'이지 '정답'이 아니다

우리가 흔히 잊는 사실이 있습니다. AI는 본질적으로 '창의성'과 '확률적 생성'에 특화되어 있다는 점입니다.

• AI의 특징: 같은 질문에도 매번 다른 답을 내놓으며, 때로는 '할루시네이션(환각)'이라는 이름의 콩트를 선보이기도 합니다.

• 전통적 코딩의 특징: Try-Except 구문으로 100% 예측 가능한 결과를 보장합니다.

만약 비즈니스에서 균질한 결과물이 필요하다면, AI에게 모든 것을 맡기기보다 기존 알고리즘의 비중을 높이는 것이 유리합니다. 그래서 저는 감히 말합니다. AI 시대일수록 코딩을 더 깊게 알아야 한다고요. 인간만이 고려할 수 있는 '비즈니스 로직'과 '심리적 변수'를 알고리즘에 녹여내는 것은 여전히 개발자의 몫이기 때문입니다.

---

 

🔄 전략적 우회: MCP 대신 Function Calling을 먼저 택한 이유

MCP 서버 구축 중 fastapi-mcp 마운트 오류라는 벽에 부딪혔습니다. 참고 자료도 부족하고, 심지어 Gemini조차 MCP를 '마인크래프트'의 무언가로 오해하는 상황이었죠. 여기서 저는 '선수비 후역습'의 자세로 Function Calling을 먼저 도입하기로 했습니다.

MCP vs Function Calling, 무엇이 다를까?

• MCP: AI가 도구함에서 스스로 도구를 선택해 과업을 수행합니다. 유연하지만 결과의 품질이 가변적일 수 있습니다.

• Function Calling: 개발자가 정의한 함수를 AI가 호출하고, 그 결과값(JSON)을 바탕으로 답변을 구성합니다. 시스템 리소스 사용에 있어 개발자가 설정한 제약 내에서만 활동하므로 훨씬 안전하고 균질한 품질을 기대할 수 있습니다.

이번 작업을 통해 TradeNPU_AI를 전면 리팩토링하며, 향후 MCP 서버를 받아들일 수 있는 'MCP 클라이언트'로서의 기반을 80% 이상 완성했습니다.

---

 

🛠️ 실전 기록: Function Calling 통합 과정의 3가지 핵심 인사이트

직접 코드를 씹고 뜯으며 얻은 뼈아픈 실무 팁들을 더 깊이 있게 공유합니다.

1. "AI의 가스라이팅을 주의하라": SDK 버전과 공식 문서의 괴리

AI 기술의 발전 속도는 AI 자신의 학습 데이터 속도조차 추월하곤 합니다.

• 문제: Gemini에게 라이브러리 활용법을 물어보면, 이미 Deprecated된 옛날 방식의 클래스나 메서드를 알려주는 경우가 많습니다. "나는 이 함수가 맞다고 믿어!"라는 AI의 확신에 찬 답변에 속아 수 시간을 허비할 수 있습니다.

• 해결: 결국 '공식 문서(Docs)'라는 성경으로 돌아가야 합니다. 특히 Python SDK는 마이너 업데이트에서도 호출 규격이 변하는 경우가 잦으니, AI의 답변은 가이드로만 삼고 실제 구현 시에는 최신 SDK 문서를 옆에 띄워두는 '교차 검증'이 필수입니다.

2. "복잡성의 임계점": 스트림, 비전, 메모리의 오케스트레이션

단순한 텍스트 챗봇을 넘어선 '진짜 AI 직원'을 만드는 과정은 일종의 오케스트라 지휘와 같습니다.

• 통합의 난제: 답변을 실시간으로 쏘아주는 Streaming, 이미지를 읽어내는 Vision, 과거 대화를 기억하는 Chat History, 그리고 이를 서버에 남기는 DB Logging까지... 이 모든 로직이 한 번의 API 호출(generate_content) 안에 녹아들어야 합니다.

• Great Leap: 특히 이미지 인식 여부에 따라 모델 스위칭 로직이 들어가고, Function Calling의 결과값까지 다시 스트리밍 응답에 태우는 과정에서 코드의 복잡도는 기하급수적으로 증가합니다. 이번 리팩토링으로 기반은 닦았지만, 향후 동영상 인식이나 STT/TTS가 추가될 때를 대비해 비즈니스 로직을 원자 단위로 분리하는 설계 역량이 핵심임을 깨달았습니다.

3. "도구함의 정돈": Gemini 특유의 Tool 구성 전략

OpenAI와 Gemini는 Function Calling을 대하는 문법 자체가 다릅니다. 특히 Gemini는 도구 등록 과정이 다소 까다롭습니다.

• 구조적 차이: 단순히 JSON 스키마를 던져주는 OpenAI와 달리, Gemini는 function_declarations를 정의한 후 이를 다시 types.Tool 객체로 래핑하여 리스트로 전달해야 합니다.

• 실무적 팁: 도구가 늘어날수록 main 코드는 지저분해집니다. 저는 도구의 JSON 스키마와 실제 파이썬 함수를 별도의 독립 파일로 분리하여 관리하는 방식을 택했습니다.

  • 장점: 새로운 도구 추가 시 기존 로직을 건드리지 않고 파일만 추가하면 되며, Git을 통한 버전 관리와 협업(혹은 나중에 AI에게 코드를 수정시킬 때) 시에도 훨씬 깔끔한 가독성을 보장합니다.

---

 

🧭 마치며: 복잡성이라는 파도를 넘어서

텍스트 생성부터 이미지 이해, Function Calling까지 뒤섞인 거대한 함수가 완성되었습니다. 코드의 가독성은 잠시 내려놓았지만, TradeNPU_AI의 능력은 비약적으로 상승했습니다.

다음 과제는 이미지 생성과 동영상 인식의 통합입니다. 더 복잡해질 아키텍처를 어떻게 정돈할지, 머리는 아프지만 멈출 수는 없습니다. '내 직원'이 점점 똑똑해지고 있으니까요.

 

---

💡 안내: 이 포스팅은 기존 네이버 블로그의 9~11회차 연재분을 통합 및 재구성한 글입니다. MCP 서버 구축 과정에서의 시행착오를 뒤로하고, 왜 지금 'Function Calling'에 집중해야 하는지, 그리고 그 과정에서 얻은 기술적 교훈을 담았습니다.

---

---

---