2026년 6월 30일 Mistral AI에 미국 특허가 등록되면서, 익숙한 에이전트 기능 하나가 낯선 논쟁의 중심으로 들어왔습니다. US 12,670,045 B1의 제목은 Code implemented tool calls입니다. 첫 번째 청구항은 도구 호출을 감싼 코드를 만들고, 그 코드를 샌드박스에서 실행하며, 클라이언트에서 처리할 도구 호출이 나오면 멈췄다가 결과를 받은 뒤 다시 실행하고, 이후 결과를 언어 모델에 돌려주는 특정 흐름을 설명합니다.
이 소식을 Mistral이 모든 함수 호출을 특허 냈다고 요약하면 정확하지 않습니다. 더 실무적인 질문은 따로 있습니다. 내가 만든 에이전트 런타임의 구현이 이 청구항이 설명하는 순서와 얼마나 가까운가입니다.
청구항을 하나의 작업 흐름으로 읽기
청구항 1은 여러 단계가 연결된 방법을 전제로 합니다. 서버가 하나 이상의 도구 호출 요청을 받고, LLM이 도구 호출을 담은 코드 블록을 생성합니다. 서버는 그 코드를 샌드박스에서 실행합니다. 실행 중 클라이언트가 처리할 보류 도구 호출을 만나면 코드가 멈추고, 해당 호출이 클라이언트로 전달됩니다. 클라이언트가 결과를 반환하면 서버는 실행을 재개하고 그 결과를 대입한 뒤, 다른 결과를 LLM에 돌려줍니다.
특허가 설명하는 것은 서버의 오케스트레이션과 클라이언트 도구 실행 사이를 다시 이어주는 흐름입니다.
이 구조는 모델에 함수 하나를 연결한다는 일상적인 의미보다 구체적입니다. Mistral의 개발자 문서에서 함수 호출은 모델을 외부 도구에 연결하는 일반적인 기능으로 소개됩니다. 반면 특허가 집중하는 것은 오케스트레이션의 모양입니다. 여러 호출을 담는 코드, 샌드박스 실행, 클라이언트 경계에서의 중단, 재개 가능한 평가가 함께 등장합니다. 이 층위를 한데 묶어 모든 도구 호출이 갑자기 개발자에게 금지됐다고 말해서는 안 됩니다.
개발자 논쟁이 커진 이유
도구 호출은 대부분의 에이전트 SDK 아래에 놓인 기본 연결부입니다. 모델을 파일·브라우저·데이터베이스·API·로컬 장치와 이어주기 때문입니다. 오픈소스 런타임은 비슷한 시스템을 서로 호환되게 만들어야 하는 경우가 많습니다. 그래서 익숙한 실행 패턴이 특허와 연결될 수 있다는 소식은 구현 자유도, 라이선스, 장기 호환성에 대한 걱정을 불러옵니다.
공개된 특허 문서만으로는 어떤 오픈소스 프로젝트가 침해하는지, 청구항이 모든 유효성 공격을 견디는지, 특정 국가의 제품에서 실제로 어떻게 집행될지를 판단할 수 없습니다. 전체 청구항, 선행기술, 실제 구현, 관할권, 구체적인 분쟁의 경과가 필요한 법률·사실 판단이기 때문입니다. 특허 등록은 중요한 신호지만, 비슷해 보이는 모든 시스템에 대한 법원의 침해 판단은 아닙니다.
이 구분이 중요한 이유는 뜨거운 논의가 서로 다른 세 문장을 하나로 압축하기 쉽기 때문입니다. Mistral에 등록된 미국 특허가 있다는 것, 그 특허가 코드로 매개된 하나의 도구 호출 흐름을 설명한다는 것, 모든 함수 호출 구현이 위험해졌다는 것은 서로 다른 주장입니다. 앞의 두 가지는 특허 기록으로 확인되지만, 마지막 주장은 이 문서만으로 확정되지 않습니다.
일반적인 기능과 특정 구현을 나눠 보기
기능 호출의 가장 단순한 형태는 모델이 정해진 이름과 인자를 구조화된 데이터로 반환하고, 실행기가 그 함수를 호출한 뒤 결과를 다시 대화에 넣는 방식입니다. 코드 구현 방식은 여기에서 한 단계 더 나아가 여러 호출의 순서와 의존성을 코드 블록 안에 담을 수 있습니다. 어떤 작업은 병렬로 처리하고, 어떤 작업은 앞선 결과를 기다리게 만들며, 중간 결과를 모델에 모두 노출하지 않을 수도 있습니다. 둘 다 도구를 사용하지만 실행 책임이 놓이는 위치는 다릅니다.
특허 문서를 읽을 때는 제품 이름이나 기능 이름보다 청구항의 조합을 봐야 합니다. 이 특허에는 총 20개의 청구항이 있고, 청구항 1은 방법의 순서를, 다른 청구항들은 클라이언트 실행·재개 가능한 샌드박스·평가 스택·병렬 및 순차 실행·오류 정보 같은 세부를 확장합니다. 특정 기능 하나가 비슷하다는 이유만으로 전체 청구항과 같다고 볼 수 없고, 반대로 이름을 다르게 붙였다고 해서 구현 차이가 증명되는 것도 아닙니다.
실무에서는 각 단계를 표로 옮겨야 합니다. 코드 생성 주체가 LLM인지, 코드를 실행하는 서버가 있는지, 샌드박스가 중단과 재개를 지원하는지, 클라이언트 호출의 결과를 어떻게 대입하는지, 모델에 어떤 결과를 전달하는지를 기록하면 막연한 공포가 구체적인 비교 문제로 바뀝니다. 이 표는 법률 판단을 대신하지 않지만, 어떤 부분을 검토받아야 하는지 알려주는 설계 자료가 됩니다.
에이전트 팀이 확인할 것
첫 단계는 키워드를 찾는 대신 런타임을 그려보는 일입니다. 모델이 구조화된 일반 호출을 내보내는지, 여러 호출을 담은 실행 코드를 생성하는지 확인해야 합니다. 그 코드는 어디에서 실행되는지, 재개 가능한 샌드박스가 있는지, 서버와 클라이언트 사이를 호출이 오갈 수 있는지, 같은 실행 흐름으로 돌아오는지 살펴봐야 합니다. 모델이 중간 결과를 받는지 최종 결과만 받는지도 구분해야 합니다. 이런 세부 구현이 도구 호출이라는 넓은 이름보다 청구항에 더 가깝습니다.
두 번째는 설계의 출처를 남기는 일입니다. 런타임을 언제 도입했는지, 어떤 오픈소스 구성요소에 의존하는지, 어느 관할권에서 제품을 운영할지, 다른 구현을 검토했는지를 기록해 두는 편이 좋습니다. 특정 오케스트레이션 순서에 제품이 의존한다면 기술적 이유를 문서화하고, 상용 출시 전에 관련 청구항을 변호사에게 검토받아야 합니다. 이것은 개발을 멈추자는 뜻이 아니라 IP 검토를 마지막 단계로 미루지 말자는 뜻입니다.
세 번째는 구조를 바꿀 수 있게 만드는 일입니다. 모델 인터페이스와 실행 엔진을 분리하고, 도구 권한을 명시적으로 관리하며, 중단과 재개 경계를 교체 가능한 부분으로 두면 특허와 무관하게 보안성과 관찰성이 좋아집니다. 법률 검토에서 위험이 발견됐을 때 구현을 바꿀 여지도 커집니다.
구현이 바뀌는 순간을 기록하기
에이전트 런타임은 처음부터 완성된 형태로 만들어지지 않습니다. 프로토타입에서는 단순한 JSON 호출을 쓰다가, 호출 수가 늘면 코드 블록과 샌드박스를 추가할 수 있습니다. 운영 환경에서는 보안이나 비용 때문에 서버와 클라이언트의 경계를 다시 나누기도 합니다. 최종 코드만 남기고 이런 변화의 이유를 지우면, 나중에 특정 실행 패턴이 언제 들어왔고 어떤 대안을 검토했는지 설명하기 어려워집니다.
그래서 설계 문서에는 아키텍처 그림뿐 아니라 런타임 버전, 의존하는 오픈소스 구성요소, 도구 호출 방식, 중단과 재개가 발생하는 위치를 함께 남겨야 합니다. 특허를 읽은 날짜와 적용을 검토한 관할권도 기록하면, 몇 달 뒤 모델이나 실행기를 바꿀 때 같은 질문을 처음부터 다시 만들지 않아도 됩니다. 오픈소스 라이선스를 지키는 일과 특허 위험을 검토하는 일은 서로 대체되지 않습니다.
이 기록은 법무팀만을 위한 자료가 아닙니다. 운영자는 어떤 실행을 재현할지 알 수 있고, 보안 담당자는 권한 경계를 확인할 수 있으며, 개발자는 문제가 되는 부분만 교체할 수 있습니다. 특허 이슈가 실제 위험으로 이어지지 않더라도, 이런 분리는 에이전트 시스템의 유지보수 비용을 낮춥니다.
조금 불편하지만 유용한 결론은 분명합니다. 에이전트가 단일 JSON 호출을 넘어 코드 실행, 샌드박스, 클라이언트 위임, 재생으로 나아갈수록 런타임 자체가 기술적 제약과 법적 제약을 함께 가진 제품 표면이 됩니다. 개발자가 도구 사용이라는 아이디어를 Mistral이 소유한다고 가정할 필요는 없습니다. 대신 실제 청구항을 읽고, 설계 출처를 남기며, 뜨거운 커뮤니티 해석과 특허 기록이 말하는 사실을 분리해야 합니다.
