Gemini 3.5 Flash가 바꾼 에이전틱 코딩 파이프라인

경량 모델이 OS 빌드를 끝냈다는 의미

코드를 한 번 생성하는 것과 빌드가 끝날 때까지 환경을 탐색하고 오류를 고치는 일은 전혀 다른 문제다. Google I/O 2026에서 공개된 Gemini 3.5 Flash가 주목받은 이유도 코딩 파이프라인 자율 실행과 OS 빌드 완료를 경량 아키텍처로 수행했기 때문이다.

2026년 AI 코딩 에이전트 시장에는 높은 추론 품질을 앞세운 Claude Opus, GPT-4o, Gemini Pro 계열과 속도·비용 효율에 무게를 둔 Claude Haiku, GPT-4o mini, Gemini Flash 계열이 공존한다. 멀티스텝 계획과 실행, 수정 루프가 필요한 작업에서는 경량 모델의 품질 저하를 피하기 어렵다는 인식이 있었지만, Gemini 3.5 Flash는 그 경계를 다시 설정한 모델로 포지셔닝되었다.

내부 벤치마크에 제시된 결과는 다음과 같다.

지표	결과
코딩 파이프라인 자율 실행 성공률	기존 Flash 대비 4배 향상
OS 빌드 완료 태스크	단독 완료 달성
추론 속도	Gemini Pro 대비 5배 빠름
API 비용	Gemini 2.0 Pro 대비 약 80% 절감
컨텍스트 윈도우	1M 토큰 유지

OS 빌드는 컴파일 오류를 읽고 의존성을 해결하는 데서 끝나지 않는다. 빌드 스크립트를 수정하고 다시 실행하는 과정까지 이어져야 한다. 이 작업을 단독으로 완료했다는 성과는 복잡한 에이전틱 작업에 반드시 플래그십 모델이 필요하다는 전제를 흔든다.

가벼운 모델에 계획 능력을 넣는 방법

Gemini 3.5 Flash의 설계 방향은 모델을 경량화하면서도 에이전틱 성능을 유지하는 데 있다. 기반이 되는 기법은 지식 증류(Knowledge Distillation)다. Gemini 3.5 Pro를 교사 모델로 사용하면서 코딩 파이프라인 실행 로그, 빌드 오류 수정 이력, CI/CD 자동화 시나리오를 대규모로 합성해 에이전틱 작업에 특화된 학습 데이터로 활용했다.

멀티스텝 작업에서는 앞선 단계의 결과를 정확히 찾아 쓰는 능력이 중요하다. 이를 위해 계층적 어텐션 구조를 적용하고, 장기 컨텍스트 안에서도 핵심 단계의 결과물에 선택적으로 높은 어텐션 가중치를 부여하도록 설계했다.

계획 없이 바로 코드를 생성하는 경량 모델의 약점은 Planning Token으로 보완한다. 요청을 먼저 분해하고 실행 순서를 세운 뒤 실제 작업에 들어가는 구조다. 이 계획 단계가 OS 빌드처럼 수십 단계가 이어지는 작업에서 방향을 유지하도록 돕는다.

⤢✕

Planning Token은 AI 계획 수립 이론의 STRIPS(Stanford Research Institute Problem Solver)와 연결해 볼 수 있다. 모델 경량화 관점에서는 지식 증류가 핵심이고, 실행 제어 관점에서는 명시적인 계획과 상태 참조가 중심에 놓인다.

생성보다 긴 코딩 파이프라인

자율 실행형 코딩 에이전트는 자연어나 스펙 문서에서 요구사항을 추출한 뒤 프로젝트 구조와 의존성을 준비한다. 이후 함수 단위 구현, 단위 테스트, 오류 수정을 반복하고 컴포넌트 간 통합 테스트로 넘어간다. 빌드와 패키징을 마치면 최종 결과물을 검증하고 완료 상태를 보고한다.

Linux 기반 OS 빌드는 이 흐름을 가장 복잡하게 확장한 사례다. 수천 개의 소스 파일을 컴파일하고 커널 모듈을 링킹하며 부트로더 설정을 순서대로 처리해야 한다. 어느 단계에서든 오류가 발생할 수 있으므로 에이전트는 로그를 읽고 관련 파일을 찾은 다음 수정과 재빌드를 이어가야 한다.

# Gemini 3.5 Flash 기반 OS 빌드 에이전트 구현 예시
import anthropic

client = anthropic.Anthropic()

def run_os_build_agent(build_config: dict) -> dict:
    tools = [
        {
            "name": "execute_shell",
            "description": "셸 명령을 실행하고 stdout/stderr를 반환",
            "input_schema": {
                "type": "object",
                "properties": {
                    "command": {"type": "string"},
                    "timeout": {"type": "integer", "default": 300}
                },
                "required": ["command"]
            }
        },
        {
            "name": "read_file",
            "description": "빌드 로그 또는 소스 파일 내용 읽기",
            "input_schema": {
                "type": "object",
                "properties": {"path": {"type": "string"}},
                "required": ["path"]
            }
        },
        {
            "name": "patch_file",
            "description": "소스 파일에 패치 적용",
            "input_schema": {
                "type": "object",
                "properties": {
                    "path": {"type": "string"},
                    "patch": {"type": "string"}
                },
                "required": ["path", "patch"]
            }
        }
    ]

    messages = [{"role": "user", "content": f"다음 빌드 설정으로 OS를 빌드하라: {build_config}"}]

    while True:
        response = client.messages.create(
            model="gemini-3.5-flash",  # Vertex AI 경유
            max_tokens=8192,
            tools=tools,
            messages=messages
        )

        if response.stop_reason == "end_turn":
            return {"status": "completed", "summary": response.content[-1].text}

        # 도구 호출 처리 후 messages에 추가
        tool_results = process_tool_calls(response.content)
        messages.append({"role": "assistant", "content": response.content})
        messages.append({"role": "user", "content": tool_results})

이 구현은 빌드 성공이나 복구할 수 없는 오류를 만날 때까지 도구 호출 결과를 대화에 추가하며 반복한다. Gemini 3.5 Flash는 컴파일 오류 메시지를 해석하고 관련 소스 파일을 찾아 수정한 뒤 재빌드하는 과정을 사람의 개입 없이 수행하는 것으로 보고되었다.

반복 실행을 버티는 에이전트 설계

모델만 Flash로 바꾼다고 자율 파이프라인이 완성되지는 않는다. 작업을 명시적인 소태스크로 나누고, 긴 빌드 로그는 필요한 오류 컨텍스트만 남도록 압축해야 한다. 장시간 실행되는 파이프라인이라면 각 단계의 완료 상태를 체크포인트로 저장해야 하며, 서로 독립적인 모듈 작업은 병렬 실행 대상으로 분리할 수 있다.

전략	설명	적용 시나리오
태스크 분해 프롬프팅	복잡한 작업을 명시적으로 소태스크로 분해 요청	OS 빌드, 대규모 리팩토링
오류 컨텍스트 압축	긴 빌드 로그를 요약하여 컨텍스트 절약	컴파일 오류 수정 루프
체크포인트 저장	각 스텝 완료 시 상태 저장 후 재시작 가능	장시간 파이프라인
병렬 스텝 감지	독립적 작업은 병렬 실행으로 속도 향상	멀티 모듈 빌드

실패 복구는 같은 요청을 되풀이하는 재시도와 구분해야 한다. 네트워크나 리소스 문제처럼 일시적인 오류인지, 코드 버그나 설정 문제처럼 논리적인 오류인지 먼저 분류한다. 이어서 실패 지점 이후의 컨텍스트를 다시 구성하고, 같은 목표에 도달할 대안 경로를 탐색한다. Flash가 해결할 수 없는 작업은 Gemini Pro로 에스컬레이션하는 경로도 필요하다.

체크포인트와 재시작은 장애 복구(Fault Recovery) 및 내결함성(Fault Tolerance) 설계를 에이전트에 적용한 형태다. 완료 상태를 저장하는 방식은 트랜잭션 관리의 Savepoint 개념과도 닮아 있다.

Flash와 Pro를 나누는 경계

Gemini 3.5 Flash는 반복적이고 구조가 분명한 작업에 맞는다. CI/CD 자동화, 테스트 실행, 문서와 주석 생성처럼 실행 패턴이 정해진 작업에서는 속도와 비용 효율을 활용할 수 있다. 반면 창의적인 설계나 아키텍처 결정, 복잡한 디버깅, 보안 감사와 취약점 분석은 Gemini 3.5 Pro에 배정하는 구성이 적합하다.

에이전틱 작업 선택 기준:
- 반복적·구조화된 작업 + 비용 민감 → Gemini 3.5 Flash
- 창의적 설계·아키텍처 결정 필요 → Gemini 3.5 Pro
- 코드 리뷰·복잡한 디버깅 → Gemini 3.5 Pro
- CI/CD 자동화·테스트 실행 → Gemini 3.5 Flash
- 문서 생성·주석 작성 → Gemini 3.5 Flash
- 보안 감사·취약점 분석 → Gemini 3.5 Pro

이 구분은 하나의 모델에 전체 파이프라인을 맡기는 대신, Flash가 반복 실행을 담당하고 Pro가 고난도 판단을 처리하는 하이브리드 전략으로 이어진다.

경량 에이전틱 모델 사이의 선택

2026년 기준 Gemini 3.5 Flash, Claude Haiku 4.5, GPT-4o mini의 특성은 다음과 같이 비교된다.

항목	Gemini 3.5 Flash	Claude Haiku 4.5	GPT-4o mini
출시	2026.05 (I/O 2026)	2026.03	2025.12
컨텍스트	1M 토큰	200K 토큰	128K 토큰
코딩 에이전틱 강점	OS 빌드·파이프라인 자율 실행	신중한 단계별 추론	다목적 범용
속도	최상급	빠름	빠름
API 비용 (입력 1M 토큰)	약 $0.075	약 $0.08	약 $0.15
API 비용 (출력 1M 토큰)	약 $0.30	약 $0.25	약 $0.60
멀티모달	텍스트·이미지·오디오·비디오	텍스트·이미지	텍스트·이미지
도구 사용	네이티브 지원	네이티브 지원	네이티브 지원
에이전틱 특화 훈련	코딩 파이프라인 특화	안전·신중 특화	범용

Gemini 3.5 Flash의 강점은 1M 토큰 컨텍스트와 코딩 파이프라인 특화 훈련이다. 대규모 코드베이스 전체를 한 번에 참조할 수 있다는 점은 OS 빌드처럼 작업 범위가 넓은 상황에서 이점으로 작용한다.

Claude Haiku 4.5는 안전하고 신중한 추론이 필요한 프로덕션 코드 수정이나 보안에 민감한 변경에서 선호되는 경향이 있다. GPT-4o mini는 범용성과 OpenAI 에코시스템 통합에 무게를 둔 팀의 선택지다.

Gemini 3.5 Flash가 보여준 변화는 경량 모델의 역할이 보조적인 코드 생성에 머물지 않는다는 데 있다. 지식 증류와 계획 구조, 실패 복구를 함께 설계하면 코딩 파이프라인 전체를 실행하는 에이전트로 확장할 수 있다. 운영 단계에서는 Flash와 Pro의 역할을 구분하고, 복구할 수 없는 판단을 상위 모델로 넘기는 경계를 명확히 두어야 한다.