LLM은 무엇을 요청할지 결정해야 하며, 비즈니스 로직을 비밀리에 실행해서는 안 된다
요약
LLM이 자체적인 비즈니스 로직으로 작동하는 위험성을 지적하며, 대신 함수 호출(Function Calling) 방식을 사용해야 한다고 강조합니다. 이는 LLM의 해석 능력과 실제 실행을 분리하여, 개발자가 정의한 좁고 타입화된 엔드포인트만을 통해 결정론적이고 감사 가능한 결과를 얻는 방법입니다.
핵심 포인트
- LLM은 요청할 것을 결정하고, 사용자 코드가 실행해야 합니다 (해석/실행 분리).
- 함수 호출을 사용해 비즈니스 로직을 서버 측에 유지하고 타입화된 엔드포인트를 노출하세요.
- 도구 정의 시 인증(auth), 감사 추적(audit trails), 재시도 등 안정성을 확보해야 합니다.
- 자유 형식 생성 대신 명확한 설명서가 있는 레고 세트처럼 사용해야 합니다.
LLM은 무엇을 요청할지 결정해야 하며, 비즈니스 로직을 비밀리에 실행해서는 안 된다
지난달 저는 사용자가 영수증 사진을 찍으면 지출 요약 내역을 즉시 확인할 수 있는 핀테크 앱에 깊이 빠져 있었습니다. LLM은 이미지를 읽고 숫자를 추출하여 저희 원장(ledger)에 기록하는 것이 임무였습니다. 그런데 모델이 갑자기 “자신만의 비즈니스 로직”을 수행하기 시작했습니다. 이상하게 반올림하기도 하고, 할머니 스타일의 할인도 적용하고, 심지어 직감만으로 거래를 사기로 플래그 지정까지 했습니다. 마치 셰프에게 팬 하나를 건네주고 그가 몰래 신비한 향신료를 추가하는 것을 지켜보는 기분이었습니다.
문제는 명확했습니다. 저는 자유 형식 생성(free-form generation)을 스위스 군용 칼처럼 사용하며 모델이 작업 방식 자체를 결정하도록 내버려 두었던 것입니다. 그 결과는 무엇이었을까요? 비결정론적 출력, 감사 지옥(audit nightmares), 그리고 “AI가 왜 저렇게 했나요?”라는 티켓 더미였습니다.
여기서 함수 호출(function calling)이 등장합니다. 이것을 공손한 웨이터에 비유해 보세요. 당신은 모델에게 “숫자가 필요하면 extract_amount(image) 함수를 호출하세요. 제가 float 값을 드릴게요.”라고 말하는 것입니다. 모델은 자신의 뇌 속에서 마법처럼 계산할 수 없습니다. 반드시 당신이 타이핑한 정확한 조각을 요청해야 합니다. 당신의 서비스가 무거운 작업을 처리하고, 인증 확인(auth checks)을 하며, 모든 요청을 기록하고, 실패 시 재시도하며, 결정론적 결과(deterministic result)를 반환합니다. 이것이 바로 OpenAI의 Function Calling과 “Tools” 기능이 하는 일입니다. 즉, 좁고 타입화된 엔드포인트(typed endpoints)를 노출하고 비즈니스 로직을 서버 측에 유지하는 것입니다.
간단한 비유를 들자면 이렇습니다. 자유 형식 생성은 아이에게 3D 프린터를 주고 “장난감 하나 만들어줘”라고 말하는 것과 같습니다. 아이는 공룡, 우주선, 또는 바나나를 인쇄할 수도 있습니다. 반면 함수 호출은 명확한 설명서가 있는 레고 세트를 건네주는 것과 같습니다. 아이는 설명서가 허용하는 것만 만들 수 있으며, 추가되는 모든 조각을 셀 수 있습니다.
저희 핀테크 사례에서는 세 가지 도구(tool)를 정의했습니다:
extract_amount(image_bytes) → float<br>record_transaction(user_id, amount, category) → bool<br>check_fraud(user_id, amount) → bool
이제 LLM은 “이 영수증에서 금액을 추출해야 해 – extract_amount를 호출해”라고 말하고, 우리는 깔끔한 숫자를 얻습니다. API에 문제가 생기면 재시도하고, 모든 과정이 기록되며, 감사자들은 무엇이 요청되었고 무엇이 반환되었는지 정확히 확인할 수 있습니다. 숨겨진 할인은 없습니다.
교육 기술(edutech) 분야에서는 수학 문제를 답변할 수 있는 튜터링 봇을 만들었지만, 공식에 대해 환각 현상(hallucinate)을 일으키게 하고 싶지 않았습니다. 그래서 solve_linear(a, b) → float 함수를 노출했습니다. 모델은 이제 “2x+3=7에서 x는 무엇인가요? solve_linear를 a=2, b=-4로 호출하세요.”라고 요청합니다. 답변은 항상 정확하고 추적 가능하며, 선생님들은 로그를 감사할 수 있습니다.
핵심 요약 사항(Key take-aways)
- 해석(LLM이 무엇을 물어볼지 결정)과 실행(사용자 코드가 어떻게 할지를 수행)을 분리하세요.
- 도구는 좁게 유지하고 매개변수는 타입을 지정하세요. 자유 형식의 JSON 블롭은 안 됩니다.
- 도구 측면에서 인증(auth), 감사 추적(audit trails), 재시도, 오류 처리를 구현하세요.
- 비즈니스 로직을 모델의 상상 속에 숨기지 말고 코드 내에서 결정론적으로 유지하세요.
따라서 다음에 LLM이 전체 레시피를 작성하도록 유혹받는다면, 기억하세요. 그 모델은 비밀 요리사가 아니라 영리한 웨이터여야 합니다. 여러분의 스택에 추가하고 싶은 좁은 도구는 무엇인가요? 댓글을 남겨 아이디어를 교환해 봅시다!
기술적인 작업과 아키텍처 설계에 관심이 있다면, 제 경험을 바탕으로 더 자세한 내용을 이곳에서 공유했습니다: https://github.com/SalmonJoy/My_guide_for_building_AI_systems/blob/main/Function_calling_vs_free-form_generation.md
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기