오픈소스의 챔피언이 특허를 냈다: 미스트랄 '코드로 도구 호출' 특허 논란

AI 업계에서 특허는 오랫동안 촌스러운 단어였습니다. 논문을 arXiv에 먼저 올리고, 가중치를 허깅페이스에 풀고, 그걸로 인재를 끌어모으는 게 지난 몇 년의 문법이었죠. 그런데 그 문법을 누구보다 열심히 지켜온 미스트랄이 AI 에이전트의 가장 기본적인 동작 방식에 특허를 받았습니다. 오픈소스 커뮤니티가 술렁이는 이유입니다.

솔직히 말씀드리면 이 사안이 아직 크게 번진 건 아닙니다. 최근 30일 기준으로 레딧에서 쓸 만한 스레드를 찾기 어려웠습니다. 그래도 특허 문서 자체와 그 배경이 되는 흐름은 짚어볼 만해서, 오늘은 커뮤니티 반응 대신 구조 쪽 이야기를 해보겠습니다.

문제의 특허, 도대체 뭘 보호한다는 걸까

특허의 핵심은 “code implemented tool calls”, 우리말로 옮기면 “코드로 구현된 도구 호출"입니다. 이름만 봐서는 감이 안 오실 텐데, 요즘 AI 에이전트를 만들어본 사람이면 다 아는 그 방식입니다.

기존 도구 호출은 이렇게 굴러갑니다. 모델이 JSON을 하나 뱉습니다. {"tool": "search", "args": {"query": "날씨"}} 같은 형태로요. 실행 환경이 그걸 파싱해서 함수를 부르고, 결과를 다시 모델에게 넘겨줍니다. 도구를 세 번 써야 하면 이 왕복도 세 번입니다.

코드 기반 도구 호출은 다릅니다. 모델이 JSON 대신 파이썬 코드를 씁니다.

results = search("서울 날씨")
temps = [r.temp for r in results]
if max(temps) > 30:
    send_alert("폭염 주의")

검색하고, 반복하고, 조건 따지고, 알림 보내는 것까지 한 번에 끝납니다. 왕복이 한 번으로 줄어드니 토큰도 아끼고 지연 시간도 짧아집니다. 반복문과 조건문이 공짜로 딸려오니 표현력도 낫고요. 요즘 에이전트 프레임워크가 앞다퉈 이쪽으로 갈아타는 이유입니다.

문제는 이게 미스트랄만의 발명이 아니라는 겁니다.

선행기술 이야기를 안 할 수가 없습니다

특허가 유효하려면 신규성이 있어야 합니다. 이미 세상에 공개된 기술이면 특허를 받을 수 없죠. 이걸 선행기술이라고 부릅니다. 그런데 코드로 도구를 호출한다는 아이디어는 계보가 꽤 두껍습니다.

Toolformer는 2023년 2월 메타 AI가 발표한 논문입니다. 모델이 스스로 API 호출 위치를 학습하게 만드는 접근이었죠. PAL과 Program of Thoughts도 비슷한 시기에 나왔습니다. 추론을 자연어 말고 실행 가능한 프로그램으로 쓰자는 아이디어였습니다.

가장 직접적인 건 CodeAct입니다. 2024년 초 일리노이대 연구진이 발표한 논문인데, 제목부터가 “Executable Code Actions Elicit Better LLM Agents"입니다. 에이전트의 행동을 JSON이 아니라 실행 가능한 코드로 쓰면 성능이 더 좋다는 걸 벤치마크로 보여줬습니다. 코드도 공개했고, 오픈핸즈 같은 프로젝트의 뿌리가 됐습니다.

허깅페이스의 smolagents는 아예 이 철학을 라이브러리로 만들었습니다. 기본 에이전트 클래스 이름이 CodeAgent입니다. 문서 첫 페이지에서 “코드로 액션을 작성하는 게 JSON보다 낫다"고 대놓고 설명합니다. 아파치 2.0 라이선스로 전부 공개돼 있고요.

이만한 계보가 있는 기술에 특허가 붙었으니 커뮤니티가 불편해할 만합니다.

그럼에도 특허가 나온 이유

여기서 오해를 하나 풀어야 합니다. 특허는 “아이디어"에 주는 게 아니라 청구항에 줍니다. 특허 문서 앞부분의 설명은 배경 지식이고, 법적으로 힘을 쓰는 건 뒤쪽 청구항 문장입니다.

미국 특허청 심사관은 청구항을 하나하나 선행기술과 대조합니다. 그래서 실제로 등록되는 청구항은 대개 아주 좁습니다. “코드로 도구를 호출하는 모든 것"이 아니라, “이러이러한 방식으로 샌드박스를 구성하고, 저러저러한 순서로 상태를 관리하며, 특정 조건에서 재시도하는 방법” 같은 식으로요.

제목이 넓다고 권리 범위가 넓은 게 아닙니다. 헤드라인만 보고 “이제 CodeAct 못 쓰는 거냐"고 걱정할 일은 아니라는 거죠. 실제 위험도를 알려면 청구항 1번을 직접 읽어봐야 합니다.

반대로 안심하기도 이릅니다. 청구항이 좁아도 특허는 충분히 위협적입니다. 스타트업 입장에서 특허 소송은 이기고 지고를 떠나 변호사 비용만으로 회사가 흔들립니다. 실제로 침해하지 않아도 경고장 한 통이면 투자 유치가 밀립니다. 이걸 냉각 효과라고 부르죠. 특허의 진짜 힘은 소송이 아니라 소송의 가능성에 있습니다.

논문에서 특허로, 달라진 게임의 규칙

이 사건을 미스트랄 한 회사의 배신으로만 읽으면 그림을 놓칩니다. 더 큰 흐름이 있습니다.

2017년 구글이 트랜스포머 논문을 공개했을 때, 결과적으로는 자기를 위협할 경쟁자들에게 무기를 쥐여준 셈이 됐습니다. OpenAI도, 앤트로픽도, 미스트랄도 그 논문 위에서 태어났으니까요. 업계는 이 교훈을 아주 비싸게 배웠습니다.

그래서 최근 몇 년 프런티어 랩의 공개 방식이 눈에 띄게 달라졌습니다. 모델 카드는 여전히 나오지만 학습 데이터 구성은 안 밝힙니다. 성능 수치는 공개하면서 아키텍처 디테일은 흐릿하게 넘어가고요. 논문은 줄고 기술 보고서가 늘었습니다. 그 빈자리를 이제 특허가 채웁니다.

미스트랄의 사정은 더 절박합니다. 오픈 웨이트를 브랜드 정체성 삼아 성장한 회사니까요. 그런데 오픈 웨이트는 방어력이 없습니다. 가중치를 풀면 누구든 가져다 씁니다. 유럽의 오픈소스 대안이라는 서사만으로 미국 빅테크의 자본력을 당해낼 수도 없죠. 결국 다른 종류의 해자가 필요했을 겁니다. 특허는 오픈 웨이트와 같이 갈 수 있는 몇 안 되는 방어 수단입니다. 모델은 열되 방법론은 잠그는 거죠.

전략으로는 이해가 갑니다. 브랜드로는 손해가 큽니다. 오픈소스 진영의 신뢰는 한번 금이 가면 되돌리기 어렵습니다.

그래서 개발자는 뭘 해야 하나

당장 코드를 갈아엎을 일은 아닙니다. 다만 챙겨둘 건 있습니다.

실무자라면 지금 쓰는 프레임워크의 라이선스를 한 번 확인해두시면 좋습니다. 아파치 2.0에는 특허 라이선스 조항이 있어서 기여자가 자기 특허로 사용자를 공격하지 못하게 막습니다. MIT 라이선스에는 그 조항이 없습니다. 평소엔 신경도 안 쓰던 차이가 이럴 때 갈립니다.

스타트업이라면 방어적 특허 출원을 검토해볼 시점입니다. 남을 공격하자는 게 아니라, 협상 테이블에 올릴 카드를 만들어두자는 겁니다. 업계에서는 이걸 상호확증파괴라고 농담처럼 부릅니다.

커뮤니티 차원에서는 선행기술을 문서로 남기는 일이 중요해집니다. 논문 날짜, 커밋 히스토리, 블로그 게시일이 나중에 특허 무효 심판의 증거가 됩니다. 아이디어를 공개된 자리에 날짜와 함께 박아두는 습관이 곧 방어책인 셈입니다.

마무리

오픈소스는 원래 선물 경제였습니다. 내가 푼 코드를 남이 쓰고, 남이 푼 코드를 내가 쓰고. 그 순환이 지난 10년 소프트웨어 산업을 굴렸습니다. AI는 그 문법을 물려받아 폭발적으로 컸고요.

그런데 판돈이 커지니 규칙이 바뀝니다. 공개는 여전히 마케팅으로 유효하지만, 방어는 특허로 하는 이중 전략이 자리를 잡아가는 중입니다. 미스트랄의 이번 건은 그 전환이 어디까지 왔는지 보여줍니다.

궁금한 건 이겁니다. 오픈 웨이트를 풀면서 방법론에는 특허를 거는 회사를, 우리는 계속 오픈소스 기업이라고 불러야 할까요. 아니면 오픈소스라는 말의 뜻을 다시 정해야 하는 걸까요.