본문 바로가기
오픈소스2026년 8월 27일15분 읽기

구글, Gemma 4를 Apache 2.0로 공개하고 에이전트 개발 킷(ADK) 발표 — 오픈웨이트 생태계의 다음 수

YS
김영삼
조회 4
구글, Gemma 4를 Apache 2.0로 공개하고 에이전트 개발 킷(ADK) 발표 — 오픈웨이트 생태계의 다음 수

구글이 2026년 8월 오픈소스 블로그를 통해 Gemma 4를 Apache 2.0 라이선스로 공개하고, AI 에이전트를 만들고 조합·실행하는 오픈소스 프레임워크 에이전트 개발 킷(ADK)을 함께 발표했다.

핵심은 두 가지다. 하나는 가중치를 내려받아 자기 인프라에서 돌릴 수 있는 ‘오픈웨이트’ 모델을, 파생 모델과 상업 이용에 제약이 거의 없는 표준 오픈소스 라이선스(Apache 2.0)로 배포했다는 점. 다른 하나는 그 모델을 실제 애플리케이션으로 엮는 에이전트 계층까지 오픈소스로 내놓았다는 점이다. 개발자 입장에서 이 조합은 ‘API 호출’을 넘어 ‘소유와 통제’로 무게중심을 옮긴다.

Gemma 4
공개된 오픈웨이트 모델
Apache 2.0
적용된 라이선스
ADK
에이전트 개발 킷(오픈소스)
온프레
자체 인프라 실행 가능

무슨 일이 있었나

구글 오픈소스 블로그에 따르면, 이번 발표의 뼈대는 두 축이다. 첫째, 경량 오픈 모델 계열의 새 세대인 Gemma 4Apache 2.0 라이선스로 배포했다. 둘째, 대화형과 비대화형 AI 에이전트를 만들고 여러 개를 조합·오케스트레이션해 실행하도록 돕는 오픈소스 프레임워크/SDK인 에이전트 개발 킷(Agent Development Kit, ADK)을 함께 내놓았다.

여기서 용어를 먼저 정리해 두는 게 좋다. Gemma 4는 ‘오픈소스 모델’이라기보다 정확히는 오픈웨이트(open-weight) 모델이다. 즉 학습된 가중치 파일을 공개해 누구나 내려받아 실행·미세조정할 수 있게 했다는 뜻이지, 학습 데이터셋과 전체 학습 파이프라인까지 재현 가능하게 공개했다는 의미는 아니다. 이 구분은 뒤에서 다시 짚는다. 다만 이번에는 그 가중치에 Apache 2.0이라는, 소프트웨어 업계에서 가장 널리 통용되는 관대한(permissive) 라이선스를 얹었다는 점이 실질적인 변화다.

참고‘오픈웨이트’와 ‘오픈소스’는 자주 혼용되지만 같지 않다. 오픈웨이트는 실행 가능한 가중치를 공개한 것이고, 완전한 오픈소스(OSI 정의)는 소스·데이터·재현 방법까지 자유롭게 쓸 수 있어야 한다는 입장이 있다. Gemma 4는 전자에 가깝고, 여기에 Apache 2.0 라이선스가 결합된 형태다.

왜 Apache 2.0이 중요한가

모델을 ‘공개’했다는 사실보다, 어떤 조건으로 공개했는가가 개발자에게는 더 중요하다. 라이선스가 곧 ‘내가 이 모델로 무엇을 해도 되는가’를 규정하기 때문이다. Apache 2.0은 상업적 사용, 수정, 재배포, 파생물 생성, 사유(폐쇄) 소프트웨어에의 포함을 모두 허용하는 관대한 라이선스이며, 특허 라이선스 조항과 명확한 저작권 고지 요건을 갖추고 있어 기업 법무팀이 검토하기에도 부담이 적다.

그동안 많은 ‘오픈’ 모델은 자체 커뮤니티 라이선스나 별도의 사용정책(AUP)을 달고 나왔고, 사용자 규모 제한이나 ‘다른 모델 학습에의 사용 금지’ 같은 조건이 붙는 경우가 있었다. 그런 조건은 스타트업이나 사내 도입 팀이 법무 검토에서 걸리는 지점을 만든다. 표준화된 Apache 2.0으로 넘어온다는 것은 그 마찰을 크게 줄인다는 뜻이다. 개발자가 얻는 실질적 자유를 정리하면 다음과 같다.

  • 온프레미스/프라이빗 배포 — 가중치를 자체 GPU, 사내 서버, 규제 환경(의료·금융·공공)에 두고 외부로 데이터를 내보내지 않고 추론할 수 있다.
  • 파인튜닝과 파생 모델 — 도메인 데이터로 미세조정하거나 증류(distill)해 만든 파생 모델을 만들고, 그것을 다시 배포할 수 있다.
  • 상업 이용 — 제품에 내장해 판매해도 되고, 사유 소프트웨어에 포함해도 된다. 라이선스 요건(고지·NOTICE 유지 등)만 지키면 된다.
  • 벤더 종속 완화 — API 가격·정책 변경이나 모델 폐기(deprecation)에 인질로 잡히지 않는다. 내려받은 가중치는 그대로 남는다.
주의‘가중치가 Apache 2.0’이라는 것과 ‘출력물의 책임’은 별개다. 모델이 만들어내는 콘텐츠의 저작권·안전·규제 책임은 여전히 배포자·운영자에게 있다. 상표(‘Gemma’ 이름 사용)나 브랜드 가이드는 라이선스와 별도로 적용될 수 있으니, 실제 도입 전에 배포 페이지의 정확한 고지 문구를 직접 확인하는 것이 안전하다.

ADK: 모델 위에 얹히는 에이전트 계층

모델 하나로는 제품이 되지 않는다. 실제 애플리케이션은 ‘모델에게 도구를 쥐여 주고, 여러 단계를 계획하게 하고, 다른 에이전트나 시스템과 협력시키는’ 층을 필요로 한다. ADK(에이전트 개발 킷)가 겨냥하는 지점이 여기다. 구글은 ADK를 대화형·비대화형 AI 에이전트를 만들고, 여러 에이전트를 조합·오케스트레이션해 실행하도록 돕는 오픈소스 프레임워크로 소개했다.

여기서 ‘대화형’은 사용자와 주고받는 챗봇·어시스턴트류를, ‘비대화형’은 사람과의 대화 없이 백그라운드에서 트리거·스케줄·이벤트로 도는 자동화 에이전트(예: 문서 처리 파이프라인, 배치 분석)를 가리킨다. 프레임워크가 제공하려는 가치는 대체로 공통적이다. 즉 도구 호출 규약, 상태·메모리 관리, 다중 에이전트 오케스트레이션, 실행/평가 흐름을 표준화해 매번 밑바닥부터 짜지 않게 하는 것이다.

# ADK 스타일의 에이전트 정의 개념 예시 (구조 이해용 의사코드)
from adk import Agent, tool

@tool
def search_docs(query: str) -> str:
    """사내 문서에서 관련 구절을 찾아 반환한다."""
    return vector_store.search(query, top_k=5)

# 대화형 에이전트: 도구를 쥐여 주고 목표를 준다
assistant = Agent(
    model="gemma-4",            # 오픈웨이트 모델을 로컬/자체 서빙
    tools=[search_docs],
    instructions="사내 지식으로만 근거 있게 답하라. 모르면 모른다고 말하라.",
)

# 비대화형 오케스트레이션: 여러 에이전트를 조합
result = assistant.run("온프레 배포 시 라이선스 고지 요건을 정리해줘")
print(result.output)

위 코드는 특정 API를 그대로 옮긴 것이 아니라 ‘에이전트 프레임워크가 무엇을 표준화하는가’를 보여주기 위한 개념 예시다. 핵심은 모델 교체 가능성이다. 오픈웨이트 모델과 오픈소스 에이전트 계층이 함께 있으면, 추론 백엔드를 클라우드 API에서 자체 서빙으로 바꾸거나, 비용·지연·규제 요건에 따라 모델을 갈아끼우는 일이 애플리케이션 코드를 크게 건드리지 않고 가능해진다.

에이전트 프레임워크라는 큰 흐름

ADK는 진공에서 나온 것이 아니다. 2024~2026년에 걸쳐 ‘에이전트’는 업계 공통의 관심사가 되었고, 각 진영이 프레임워크와 상호운용 규약을 쏟아냈다. 함수/도구 호출의 표준화, 외부 도구·데이터에 모델을 연결하는 프로토콜, 에이전트끼리 통신하는 규약, 그리고 여러 에이전트를 감독·평가하는 오케스트레이션 계층이 각각 성장하는 중이다. ADK는 그 흐름 속에서 구글이 내미는 오픈소스 카드로 읽는 것이 정확하다.

개발자 관점에서 중요한 변화는 ‘프롬프트 한 번 → 답 한 번’의 사고에서 ‘목표 → 계획 → 도구 호출 → 관찰 → 재시도 → 종료 판단’의 루프로 옮겨가는 것이다. 이 루프를 손으로 짜면 상태 관리, 도구 실패 처리, 무한 루프 방지, 관측(observability)이 전부 숙제가 된다. 프레임워크의 존재 이유는 이 반복 작업을 규격화하는 데 있다.

관점클로즈드 모델 + API오픈웨이트 + 오픈 에이전트 계층
데이터 위치외부 API로 전송자체 인프라 내 유지 가능
비용 구조토큰당 과금(가변)인프라 고정비 + 운영 부담
커스터마이즈제한적(프롬프트/일부 튜닝)파인튜닝·증류·개조 자유
벤더 종속가격·폐기 정책에 노출내려받은 가중치 영구 보유
운영 난이도낮음(관리형)높음(서빙·GPU·모니터링 자담)
최전선 성능대체로 앞섬격차 좁아지는 중, 용도별로 충분

표에서 보듯 ‘무조건 오픈이 낫다’가 아니다. 관리형 API는 운영 부담이 낮고 최전선 성능에서 앞서는 경향이 있다. 오픈웨이트는 통제권·비용 예측성·규제 대응에서 강하지만, GPU 확보와 서빙·모니터링이라는 운영 비용을 스스로 진다. 선택은 ‘성능 대 통제’의 트레이드오프를 자기 상황에 대입하는 문제다.

오픈 모델 생태계의 경쟁 구도

이번 발표는 오픈 모델 진영의 경쟁이라는 큰 맥락 위에 있다. 지난 몇 년간 여러 기업·연구소가 오픈웨이트 계열(예: 메타의 Llama 계열, 미스트랄, 각종 중국·유럽 연구소의 공개 모델 등)을 내놓으며 ‘접근성 있는 강한 모델’ 시장을 키웠다. 구글의 Gemma 계열은 그중에서도 상대적으로 가벼운 크기와 온디바이스/단일 GPU 친화성을 강조해 온 라인이다. 여기에 표준 Apache 2.0을 얹고 에이전트 계층(ADK)까지 함께 제공하는 것은, 단순한 모델 릴리스가 아니라 ‘모델 + 개발 도구 + 배포 경로’를 묶은 플랫폼 전략으로 볼 수 있다.

플랫폼 사업자에게 오픈 모델을 푸는 동기는 명확하다. 개발자 저변을 넓히고, 그 생태계가 자사의 클라우드·툴링·상용 대형 모델로 자연스럽게 이어지는 ‘깔때기’를 만든다. 오픈웨이트는 진입 장벽을 낮추고, 관리형 서비스는 규모가 커질 때의 수익원을 남긴다. 개발자는 이 역학을 이해하면 ‘공짜니까 좋다’를 넘어 ‘이 무료가 나를 어디로 끌고 가는가’까지 계산할 수 있다.

한 가지 균형 잡힌 관찰. 이번 브리핑에서 확인된 사실은 ‘Gemma 4를 Apache 2.0로 공개’와 ‘ADK 발표’라는 두 축이다. 구체적 벤치마크 점수나 파라미터 세부 사양 같은 수치는 이 글에서 단정하지 않는다. 도입을 검토한다면 성능 수치는 반드시 구글의 공식 모델 카드와 자체 평가로 직접 확인해야 한다. 마케팅 문구가 아니라 자기 워크로드에서의 실측이 판단 기준이 되어야 한다.

개발자에게 무슨 의미인가

정리하면, 이번 발표가 실무자에게 주는 함의는 세 가지다. 첫째, 라이선스 마찰의 감소다. Apache 2.0은 법무·컴플라이언스 검토를 단순화하고, 상업 제품에 모델을 내장하는 결정을 쉽게 만든다. 둘째, 아키텍처 선택지의 확대다. 데이터 주권이 중요한 조직은 온프레 추론을, 비용 예측성이 중요한 조직은 자체 서빙을 진지하게 검토할 수 있다. 셋째, 에이전트 개발의 표준화다. ADK 같은 오픈 프레임워크는 도구 호출·오케스트레이션·평가라는 반복 작업을 규격화해, 팀이 비즈니스 로직에 집중하게 한다.

반대로 ‘언제 쓰지 말아야 하는가’도 분명하다. 트래픽이 아직 작고 팀에 MLOps 역량이 없다면, 오픈웨이트 자체 서빙은 관리형 API보다 총소유비용이 더 클 수 있다. 최고 수준의 추론 품질이 제품의 사활을 가르는 경우라면, 오픈 모델의 편의보다 최전선 모델의 성능이 우선일 수 있다. 프레임워크 역시 만능이 아니다. 요구가 단순한 단일 프롬프트 수준이라면 에이전트 루프는 과설계다. 도구는 문제의 크기에 맞춰 고르는 것이다.

자주 묻는 질문

Gemma 4가 ‘오픈소스’ 모델이라는 말은 정확한가?

엄밀히는 ‘오픈웨이트’ 모델에 Apache 2.0 라이선스를 적용한 형태로 보는 것이 정확하다. 학습된 가중치를 공개해 내려받아 실행·미세조정할 수 있게 했다는 의미이며, 완전한 오픈소스(학습 데이터·파이프라인까지 재현 가능)와는 구분해서 이해하는 편이 오해가 적다. 다만 라이선스가 관대한 Apache 2.0이라는 점에서, 사용·수정·상업화의 자유는 실질적으로 넓다.

Apache 2.0이면 상업 제품에 그냥 넣어도 되나?

Apache 2.0은 상업적 사용, 수정, 재배포, 사유 소프트웨어 포함을 허용한다. 다만 저작권/라이선스 고지 유지, NOTICE 파일 보존 같은 요건이 있고, 상표(‘Gemma’ 명칭) 사용이나 모델 특유의 사용정책이 별도로 적용될 여지가 있다. 실제 배포 페이지의 정확한 문구를 도입 전에 직접 확인하는 것이 안전하다.

ADK는 정확히 무엇을 해주나?

ADK(에이전트 개발 킷)는 대화형·비대화형 AI 에이전트를 만들고, 여러 에이전트를 조합·오케스트레이션해 실행하도록 돕는 오픈소스 프레임워크/SDK다. 도구 호출, 상태·메모리 관리, 다중 에이전트 실행 흐름 같은 반복 작업을 규격화해, 개발자가 밑바닥부터 루프를 짜지 않도록 하는 것이 목적이다.

ADK는 Gemma 4에서만 쓸 수 있나?

에이전트 프레임워크의 일반적 설계는 특정 모델에 고정되지 않고 여러 백엔드를 갈아끼울 수 있게 하는 방향이다. 다만 실제 지원 범위와 연동 방식은 프레임워크 문서에 따르므로, 특정 모델·서빙 백엔드 조합의 지원 여부는 공식 문서로 확인하는 것이 정확하다. 이 글은 브리핑에서 확인된 사실 범위를 넘어 특정 호환성을 단정하지 않는다.

온프레미스로 돌리면 비용이 정말 절감되나?

경우에 따라 다르다. 트래픽이 크고 지속적이면 자체 서빙의 고정비가 토큰 과금보다 유리해질 수 있다. 반대로 트래픽이 적거나 변동이 크면, GPU 확보·서빙·모니터링 인력까지 포함한 총소유비용이 관리형 API보다 클 수 있다. 데이터 주권·규제 요건처럼 비용 외의 요인이 결정적일 때 온프레의 가치가 커진다.

지금 당장 무엇부터 하면 되나?

먼저 자기 워크로드로 작은 파일럿을 돌려 품질과 지연·비용을 실측하라. 성능 수치는 마케팅이 아니라 공식 모델 카드와 자체 평가로 확인한다. 라이선스 요건(고지·NOTICE·상표)을 법무와 미리 검토하고, 에이전트가 필요할 만큼 흐름이 복잡한지부터 판단한 뒤 ADK 같은 프레임워크 도입을 결정하는 순서가 안전하다.

출처

댓글 0

아직 댓글이 없습니다.
Ctrl+Enter로 등록