Deveoler Lee

gemma4 sglang 실행, 왜 중요한가 gemma4 sglang 실행 방법 은 단순한 모델 실행을 넘어, 고성능 LLM inference 파이프라인을 구축하는 핵심이에요. 최근 Google DeepMind가 공개한 Gemma 4는 멀티모달과 함수 호출을 기본 지원하는 고성능 오픈 모델로, 다양한 추론 엔진에서 활용 가능해요. According to Google AI 및 최신 기술 블로그 자료, Gemma 4는 vLLM, Transformers, SGLang 등 주요 inference 엔진과 호환되며 고성능 환경에서 특히 강점을 보여요. 문제는 단순 실행이 아니라 "효율"이에요. SGLang은 KV cache 재사용과 structured decoding 최적화를 통해 최대 6배 이상의 throughput 개선을 제공해요. 즉, gemma4를 SGLang으로 실행하면 단순 API 호출 대비 훨씬 높은 성능을 확보할 수 있어요. 이 글에서는 개발자 관점에서 실제 실행 방법과 구성 전략을 구체적으로 설명해요. SGLang + Gemma4 아키텍처 이해 SGLang이 필요한 이유 SGLang은 LLM 실행을 위한 프론트엔드 언어 + 런타임 구조로 설계되어 있어요. According to SGLang 논문, 다음과 같은 특징이 핵심이에요: RadixAttention 기반 KV cache 재사용 structured output decoding 최적화 multi-call 프로그램 실행 최적화 cache-aware scheduling Gemma4와의 궁합 Gemma4는 다음 특성 때문에 SGLang과 잘 맞아요: 함수 호출 및 JSON 출력 지원 멀티모달 입력 처리 MoE 구조로 높은 효율성 (26B 모델이 4B 수준 속도) According to 최신 Gemma 4 발표 자료, 일부 모델은 단일 GPU에서도 실행 가능하며, 효율적인 inference 엔진과 결합 시 성능이 크게 향상돼요. gemma4 sglang 실행 방법 (실전) 1. 환경 준비 b...

AI 코딩 에이전트 시대, 왜 가이드라인이 달라져야 할까요? 2026년 현재, 소프트웨어 엔지니어들이 직접 코드를 작성하는 비중은 빠르게 줄어들고 있어요. 대신 AI 코딩 에이전트 가 설계 의도에 따라 코드를 생성하고, 엔지니어는 설계·아키텍처·코드 리뷰에 집중하는 구조로 전환되고 있죠. 문제는 이 에이전트들이 기존 엔터프라이즈 코드베이스에 기여하려면 팀의 코딩 표준과 가이드라인을 정확히 따라야 한다는 점이에요. 주니어 개발자에게 문서 몇 개 던져주고 "알아서 배워"라고 할 수 있지만, 에이전트에게는 이 접근이 통하지 않아요. 에이전트는 빠르지만 코드의 맥락(Context)을 스스로 체득하지 못하고, 코드 스멜(Code Smell) 같은 암묵적 지식이 없기 때문이에요. 이 글에서는 AI 코딩 에이전트 와 사람 모두를 위한 효과적인 코딩 가이드라인을 어떻게 설계하는지 구체적으로 살펴볼게요. 에이전트용 코딩 가이드라인이 기존과 다른 이유 사람은 코드베이스를 탐색하면서 패턴, 스타일, 관행을 암묵적으로 학습해요. 특정 함수 네이밍 컨벤션이나 에러 처리 패턴을 반복적으로 보면서 "우리 팀은 이렇게 하는구나"를 자연스럽게 흡수하죠. 하지만 AI 코딩 에이전트 는 이 과정을 거치지 않아요. 프롬프트에 명시되지 않은 규칙은 존재하지 않는 것과 같아요. Heroku의 수석 아키텍트 Vish Abrams는 DRY(Don't Repeat Yourself)나 설정과 코드의 분리 같은 원칙조차 에이전트에게는 명시적으로 알려줘야 한다고 강조했어요. 예를 들어 "스네이크 게임을 만들어줘"라고만 하면 에이전트는 유지보수성을 전혀 고려하지 않은 코드를 생성할 수 있어요. 이런 차이 때문에 에이전트용 가이드라인은 다음 세 가지 특성을 가져야 해요: 명시적(Explicit) : 암묵적 가정을 모두 문서화해야 해요. 예시 중심(Demonstrative) : 올바른 패턴과 잘못된 패턴을 코드 예시로 보여줘야 해요. 명백함(Obvious...

왜 모놀리식 프롬프트는 한계가 있을까요? 대부분의 AI 에이전트는 시스템 프롬프트 하나에 모든 도메인 지식을 몰아넣는 방식으로 동작해요. 컴플라이언스 규칙, 스타일 가이드, API 레퍼런스, 트러블슈팅 절차까지 하나의 거대한 문자열로 연결하는 거죠. 태스크가 두세 개일 땐 문제없지만, 열 개 이상으로 늘어나면 매 LLM 호출마다 수천 토큰을 소비하게 돼요 — 사용자의 쿼리가 그 지식을 전혀 필요로 하지 않더라도요. Google의 ADK(Agent Development Kit) 는 이 문제를 프로그레시브 디스클로저(Progressive Disclosure)라는 아키텍처 패턴으로 풀어요. 필요한 컨텍스트를 필요한 시점에만 로드하는 구조인데, 이 글에서는 ADK의 SkillToolset 을 활용한 4가지 실전 스킬 패턴을 단계별로 살펴볼게요. ADK 스킬 스펙: 3단계 지식 로딩 구조 ADK 에이전트 스킬 의 핵심은 지식을 세 단계로 분리하는 데 있어요. L1 메타데이터 (~100 토큰/스킬) 스킬 이름과 설명만 포함하는 최소 정보예요. 에이전트가 시작될 때 모든 스킬의 L1을 로드해서, 어떤 스킬이 현재 쿼리에 관련 있는지 판단하는 메뉴 역할을 해요. L2 인스트럭션 (<5,000 토큰) 스킬의 전체 본문이에요. 에이전트가 특정 스킬을 명시적으로 활성화할 때만 API를 통해 로드돼요. L3 리소스 (필요 시) 스타일 가이드나 API 스펙 같은 외부 참조 파일이에요. 스킬의 인스트럭션이 요구할 때만 로드되죠. 이 구조 덕분에 10개 스킬을 가진 에이전트가 매 호출 시 약 1,000 토큰의 L1 메타데이터만 사용해요. 모놀리식 프롬프트 대비 약 90%의 컨텍스트 사용량 절감이 가능한 거예요. SkillToolset 클래스가 activate_skill , deactivate_skill , list_skills 세 가지 도구를 자동 생성해서 이 흐름을 관리해 줘요. 4가지 스킬 패턴 구현하기 패턴 1: 인라인 스킬 — 가장 단순한 시작점 파이썬 객체로 직접 정의...