[작성자:] kevin

  • GPT-5.4 Thinking 활용법: 사고 도중 끼어들기로 ChatGPT 결과물 2배 정확하게

    GPT-5.4 Thinking 활용법: 사고 도중 끼어들기로 ChatGPT 결과물 2배 정확하게

    회의실에서 발표자를 끊는 사람을 떠올려 보자

    회의에서 가장 도움이 되는 사람은 누구일까. 발표가 끝난 다음에 정중한 피드백을 주는 사람? 아니다. 발표자가 잘못된 방향으로 가기 시작한 그 순간, 짧고 정확한 한마디로 흐름을 잡아 주는 사람이다. GPT-5.4 Thinking이 처음으로 가능하게 만든 게 바로 그것이다.

    OpenAI는 이 기능을 Mid-Response Steering이라고 부른다. 모델이 한창 사고 중인 도중에 채팅창에 추가 지시를 던질 수 있고, 모델은 그 지시를 받아 답변 방향을 즉시 조정한다. 응답이 다 나올 때까지 기다렸다가 “아니, 그게 아니라…”라고 정정하는 시대가 끝났다는 뜻이다.

    왜 이게 단순한 기능 추가가 아닌가

    이전 모델까지의 한계는 묘했다. 사고 도중에 “지금 어디까지 했어?”라고 물으면 사고가 처음부터 다시 시작됐다. 시간도 토큰도 두 배가 들었다. 더 큰 문제는 잘못된 가정으로 5분 동안 깊이 들어간 다음에야 그 사실을 알 수 있다는 거였다. 5분짜리 작업이 10분짜리 작업이 됐다.

    GPT-5.4 Thinking은 사고를 시작하기 전에 preamble(사전 계획)을 먼저 보여 준다. “이 작업은 A → B → C → D 순서로 처리할게요.” 사용자는 이 계획을 1~2초 안에 훑고, 마음에 들지 않으면 그 자리에서 끼어든다. “C부터 깊게, A는 건너뛰어.” 모델은 처음부터 다시 시작하지 않는다. 받은 지시를 반영해 그대로 진행한다.

    OpenAI 내부 BrowseComp(에이전트 브라우징) 벤치 점수가 65.8%에서 82.7%까지 뛰어오른 데에는 이런 구조 변화가 깔려 있다.

    실무에서 끼어들기가 가장 빛나는 순간

    가장 먼저 떠오르는 건 긴 리서치 작업이다. “경쟁사 5곳의 1분기 매출 트렌드를 분석해 줘”라고 던졌을 때, 모델이 preamble에서 “A → B → C → D → E 순으로 분석할게요”라고 보여 준다. D사가 가장 중요한데 알파벳 순서로 처리하려 한다면? 즉시 “D사부터 가장 깊게, 다른 4사는 비교 표만”이라고 한 줄을 끼워 넣으면 된다. 한 번의 채팅으로 원하는 결과물에 도달한다는 뜻이다.

    40슬라이드짜리 재무 덱처럼 통째로 시키는 작업에서는 이 차이가 더 커진다. 잘못된 가정 하나가 결과물 전체를 다시 만들어야 하는 상황으로 번지는 게 그동안의 패턴이었다. preamble 단계에서 가정값과 출력 구조를 검토하고 수정만 해도 재작업 시간이 80% 이상 줄어든다.

    법무·계약서 비교 분석도 비슷하다. 모델이 어느 조항을 핵심으로 잡았는지 사전 계획에서 확인하고 우선순위를 재배치한다. “준거법 조항보다 손해배상 한도부터 비교해” 같은 식이다. 사용자가 도메인 지식을 갖고 있을수록 끼어들기의 정확도는 높아진다.

    코딩 쪽에서도 의미가 있다. 코드베이스 전체를 리팩토링시킬 때 모델이 어디부터 손댈지 보여 주는 단계에서 “이 모듈은 건드리지 마, 외부 의존성 있어”라고 제약을 추가한다. Claude Code나 Cursor 3 같은 코딩 에이전트와 다른 점은 분명하다. GPT-5.4 Thinking은 실행 전 계획 단계에서 개입할 수 있다.

    1M 컨텍스트와 결합되면 진짜다

    GPT-5.4는 컨텍스트 윈도가 400K에서 1M으로 확장됐다. 이전엔 긴 흐름 안에서 초반에 잡은 기준이 흐려지는 경향이 있었지만, 1M과 Mid-Response Steering이 결합되면서 한 세션 안에서 일관성을 유지하면서도 중간에 방향을 바꿀 수 있게 됐다. 책 한 권 분량의 자료를 던져 두고 작업을 시킨 뒤, 중간중간 미세 조정하는 워크플로가 처음으로 실제로 가능해진 셈이다.

    요금제는 어디서 쓸 수 있나

    ChatGPT에서는 Plus·Team·Pro·Enterprise 사용자가 모델 선택기에서 GPT-5.4 Thinking을 직접 고를 수 있다. 가장 강력한 작업이 필요한 경우 GPT-5.4 Pro가 별도로 제공된다. ChatGPT for Excel·NotebookLM 같은 OpenAI의 후속 제품들이 모두 이 모델을 두뇌로 쓴다는 점에서, 5.4 Thinking은 사실상 OpenAI 제품 라인업 전체의 기준선이다.

    그래서 — 새로운 핵심 스킬은 ‘끼어드는 능력’이다

    지금까지 ChatGPT 사용자의 능력 차이는 첫 프롬프트를 얼마나 잘 쓰느냐에서 갈렸다. 5.4 Thinking 이후에는 한 가지가 더 추가된다. 모델이 사고 중일 때 정확한 타이밍에 정확한 한마디로 끼어드는 능력. 이건 글로 배우는 것보다 손으로 익히는 게 빠르다. 회의에서 발표를 끊는 사람이 그렇듯, 처음에는 어색하지만 한두 번 해 보면 감이 잡힌다.

    지금 할 일

    ChatGPT Plus 이상이라면 자주 쓰는 작업의 기본 모델을 GPT-5.4 Thinking으로 바꿔 둔다. 다음으로 긴 작업을 시킬 때 응답 시작 전 preamble을 1~2초 안에 훑는 습관을 만든다. 마지막으로 자주 쓸 끼어들기 멘트 두세 개를 미리 만들어 두자. “X부터 깊게”, “Y는 건너뛰고”, “Z 형식으로 출력” 같은 짧은 지시문이면 충분하다.

    관련 글

    출처

  • MCP 완전 입문 가이드: 9,700만 다운로드 AI 에이전트 표준, 한국 개발자가 지금 알아야 할 것

    MCP 완전 입문 가이드: 9,700만 다운로드 AI 에이전트 표준, 한국 개발자가 지금 알아야 할 것

    USB-C 케이블이 등장하기 전까지, 노트북마다 충전 포트가 다 달랐다. 어댑터 가방을 챙겨 다녀야 했고 새 기기를 살 때마다 케이블도 같이 사야 했다. 어느 시점부터 그게 사라졌다. 표준 하나가 자리를 잡으면 산업 전체의 비용이 한 번에 떨어지는 일이 일어난다. AI 에이전트 영역에서 지금 그 일이 진행 중이다. 이름은 MCP — Model Context Protocol.

    숫자로 보면 더 분명해진다. SDK 누적 다운로드 9,700만 건. React가 npm 1억 건에 도달하는 데 3년이 걸렸는데 MCP는 16개월이었다. OpenAI, Google, Microsoft, AWS가 모두 채택했고 운영은 Linux Foundation으로 넘어갔다. “AI 인프라의 HTTP”라는 말이 더 이상 마케팅 멘트가 아닌 단계다.

    그래서 정확히 뭘 하는 표준인가

    MCP는 Anthropic이 2024년 말 오픈소스로 푼 인터페이스 규약이다. AI 모델이 외부 툴이나 데이터(파일시스템, DB, API, SaaS 서비스)에 접근하는 방법을 통일했다. 핵심 아이디어가 USB-C와 같다. 한 번 표준에 맞춰 만든 어댑터(MCP 서버)는 어떤 AI(MCP 클라이언트)에서도 그대로 동작한다.

    구조 자체는 단순하다. 한쪽은 MCP 서버 — 특정 데이터나 툴을 AI가 쓸 수 있게 노출하는 작은 프로그램(GitHub 서버, Slack 서버, PostgreSQL 서버 같은 식). 다른 한쪽은 MCP 클라이언트 — 그 서버를 호출해 쓰는 AI 애플리케이션(Claude Code, Cursor, Claude Desktop). GitHub 위에 공개돼 있는 MCP 서버가 이미 1만 3천 개를 넘었다. Slack, Figma, Linear, Notion, Postgres, Google Drive — 자주 쓰는 거의 모든 서비스에 누군가가 이미 만들어 놨다.

    Claude Code에서 5분 만에 붙여 보기

    가장 쉬운 진입은 Claude Code다. 프로젝트 루트의 .claude/settings.json에 MCP 서버 정의를 추가한다.

    {
      "mcpServers": {
        "github": {
          "command": "npx",
          "args": ["-y", "@modelcontextprotocol/server-github"],
          "env": {
            "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxx"
          }
        },
        "postgres": {
          "command": "npx",
          "args": ["-y", "@modelcontextprotocol/server-postgres",
                   "postgresql://localhost/mydb"]
        }
      }
    }

    저장하고 Claude Code를 재시작하면 끝이다. 이제 자연어로 “내 GitHub 이슈 중 라벨이 bug인 것만 보여 줘”나 “users 테이블에서 최근 가입자 10명 뽑아줘”라고 시킬 수 있다. 코드 한 줄 안 써도 된다.

    사내 시스템을 직접 노출하고 싶다면

    유명 서비스는 이미 다 있지만, 진짜 효과가 큰 건 사내 전용 시스템을 MCP로 만드는 쪽이다. TypeScript SDK가 가장 손쉽다.

    npm install @modelcontextprotocol/sdk
    // my-mcp-server.ts
    import { Server } from "@modelcontextprotocol/sdk/server/index.js";
    import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
    
    const server = new Server({ name: "my-server", version: "1.0.0" });
    
    server.setRequestHandler("tools/list", async () => ({
      tools: [{
        name: "get_user_info",
        description: "사용자 정보 조회",
        inputSchema: {
          type: "object",
          properties: { userId: { type: "string" } }
        }
      }]
    }));
    
    server.setRequestHandler("tools/call", async (req) => {
      if (req.params.name === "get_user_info") {
        // 내부 API 호출 로직
        return { content: [{ type: "text", text: JSON.stringify(userData) }] };
      }
    });
    
    const transport = new StdioServerTransport();
    await server.connect(transport);

    이렇게 만든 서버를 settings.json에 등록하면 Claude Code가 즉시 그 도구를 인식한다. 사내 API에 추가 코드를 넣을 필요도 없다. MCP 서버가 wrapper 역할만 해 준다.

    진짜 의미 — 한 번 만들면 모든 AI에서 동작

    가장 큰 변화는 재활용성이다. 사내 시스템 위에 MCP 서버 하나를 올려 두면 그게 Claude뿐 아니라 ChatGPT, Cursor, 그리고 1년 뒤에 나올 새 에이전트에서도 그대로 동작한다. 특정 벤더에 종속되는 코드를 짤 필요가 사라진다는 뜻이다. 반대로 외부 서비스 쪽도 마찬가지다. Jira나 Confluence를 AI에게 읽히고 싶다면 직접 통합 코드를 짤 게 아니라 이미 공개된 MCP 서버를 그냥 가져다 꽂으면 된다.

    지금 할 일

    가장 빠른 진입은 github.com/modelcontextprotocol/servers에 들어가 공식 서버 목록을 한 번 훑는 것이다. 이미 본인이 자주 쓰는 서비스(GitHub, Notion, Slack 등)가 있을 가능성이 높다. 그중 하나를 골라 위 settings.json 예시처럼 Claude Code에 붙여 보고, 가장 자주 묻고 싶었던 질문을 한 번 던져 보자. 그 다음 단계는 사내 시스템 차례다. 회사 동료가 AI에게 가장 자주 묻는 정보가 무엇인지 떠올려 보고, 그걸 노출하는 작은 MCP 서버를 만들어 보면 사내 도입의 첫 사례가 된다.

    관련 글

    출처

  • Meta Muse Spark 완전 분석: Llama를 버린 이유와 GPT-5·Claude 대비 성능 비교

    Meta Muse Spark 완전 분석: Llama를 버린 이유와 GPT-5·Claude 대비 성능 비교

    3년이었다. Meta가 Llama 1, 2, 3 시리즈를 차례로 무료 공개하면서 “AI 민주화”라는 메시지를 외쳐 온 세월. 그 메시지가 공식적으로 끝난 날이 4월 8일이다. 같은 날 Meta는 Llama가 아닌 완전히 새로운 폐쇄형 모델 Muse Spark를 공개했다. 가중치 다운로드 없음, 자체 호스팅 없음, 오직 API로만 접근 가능. 오픈소스 진영에 등을 돌렸다는 해석이 즉각 나왔다.

    그렇다고 충동적인 결정은 아니었던 것으로 보인다. 모델의 성능과 그 뒤에 선 사람을 보면 의도가 분명히 읽힌다.

    처음부터 4위권으로 들어왔다

    Muse Spark는 Meta Superintelligence Labs(MSL)에서 만들었다. Scale AI CEO 출신 Alexandr Wang이 이끄는 조직이고, 기존 FAIR(Meta의 전통적 AI 연구팀)와는 별도로 운영된다. 연구 중심이 아니라 제품 경쟁력을 목표로 신설된 팀이라는 게 차이의 핵심이다.

    Intelligence Index v4.0 기준 점수를 보면 위치가 분명해진다.

    모델 Intelligence Index 점수
    GPT-5.4 / Gemini 3.1 57
    Claude Opus 4.6 53
    Meta Muse Spark 52
    이전 세대 모델들 47 이하

    처음 공개한 모델이 바로 4위권. 이건 흔치 않다. Meta가 그동안 쌓아 둔 인프라와 데이터가 어느 정도 수준이었는지를 역으로 보여 주는 숫자이기도 하다.

    왜 Llama를 버렸나 — 추론 가능한 세 가지 이유

    Meta는 공식 입장을 내놓지 않았다. 하지만 업계가 대체로 동의하는 해석은 세 가지다.

    가장 자주 언급되는 건 경쟁 구도다. Llama를 오픈소스로 풀면 중국의 GLM, DeepSeek 같은 팀이 그 위에 자기 개선을 얹는다. Meta의 연구비가 경쟁사의 자산이 되는 구조다. 두 번째는 수익 경로 문제. 무료로 푸는 모델은 Meta에 직접 돈을 만들어 주지 않는다. API 기반 폐쇄 모델은 토큰당 과금이 가능하다. 세 번째가 가장 결정적인데, Alexandr Wang의 전략 색깔이다. Scale AI를 키운 그는 데이터 품질과 모델 차별화로 경쟁하는 방식에 익숙하다. “최고 품질의 유료 서비스”가 그의 본능에 더 가깝다.

    오픈소스 진영의 빈자리

    Llama는 단순한 모델 하나가 아니라 사실상 오픈소스 LLM 생태계의 기반이었다. Ollama의 Llama 계열, Hugging Face에 올라가 있는 Llama 기반 파인튜닝 모델 수천 개, llama.cpp 생태계 전체가 거기에 기대고 있었다. Meta가 빠진 자리를 누가 채울 것인가는 당장의 화두다.

    대안이 아예 없는 건 아니다. Google의 Gemma 4, Mistral, GLM-5.1, Qwen 계열이 빈자리를 메우려 한다. 하지만 Meta 수준의 자원으로 밀어붙이는 오픈소스 기반 모델이 사라진다는 건 분명한 공백이다. 이 공백이 메워지는 데 얼마가 걸리느냐에 따라 오픈소스 AI의 경쟁력 자체가 영향을 받는다.

    한국 사용자 입장에서 본 변화

    먼저 일반 사용자 쪽. Meta AI 챗봇이 인스타그램 DM, WhatsApp, Facebook 안에 들어가 있는데, 이 백엔드가 Muse Spark로 교체된다. 한국에서 인스타그램 DM의 AI 답장 기능이나 Meta AI 챗봇 응답 품질이 직접적으로 좋아질 수 있다는 뜻이다.

    개발자 쪽은 다른 의미다. 4위권 모델이 OpenAI·Anthropic과 경쟁적인 가격으로 API로 풀린다면, 그건 비용 절감 옵션이 하나 더 늘어난다는 얘기다. Meta AI API의 출시 일정과 가격 정책을 지켜볼 가치가 있다. 단, 로컬 LLM을 운영하던 팀이라면 더 이상 새로운 Llama를 기다릴 수 없다는 사실은 받아들여야 한다. 마이그레이션 시나리오를 고민할 시점이다.

    지금 할 일

    meta.ai에서 Muse Spark 기반 Meta AI 챗봇을 직접 체험해 보고 평소 쓰는 Claude나 ChatGPT와 같은 질문을 던져 비교해 보면 모델 성격이 빨리 잡힌다. 개발자라면 developers.facebook.com/products/meta-ai에서 API 출시 알림을 신청해 두자. 기존 Llama 기반 로컬 LLM을 운영 중이라면 Gemma 4와 GLM-5.1 중 어느 쪽으로 옮길 수 있는지 미리 확인해 두는 게 안전하다.

    관련 글

    출처

  • Microsoft MAI-Transcribe-1 완전 분석: Whisper 넘어선 음성인식 API 가격·성능·사용법

    Microsoft MAI-Transcribe-1 완전 분석: Whisper 넘어선 음성인식 API 가격·성능·사용법

    $0.36/시간. 25개 언어. Whisper-large-v3보다 낫다는 주장. 4월 2일 Microsoft가 Azure AI Foundry를 통해 공개한 음성인식 모델 MAI-Transcribe-1이 내건 숫자다. 자체 발표인 만큼 그대로 믿기 어려운 부분도 있지만, 가격대만 놓고 보면 무시하기 힘든 카드가 등장했다는 건 분명하다.

    같은 날 Microsoft는 OpenAI에 의존하지 않는 자체 모델 3종을 한꺼번에 공개했다. 음성합성 MAI-Voice-1, 이미지 생성 MAI-Image-2, 그리고 오늘의 주인공 MAI-Transcribe-1. 이 중 STT 쪽이 가장 빠르게 실무 영향이 가능한 영역이다.

    핵심 주장 세 줄

    MAI-Transcribe-1은 Azure AI Foundry 위에서 돌아가는 음성인식(STT) API다. Microsoft가 내세우는 키 메시지는 단순하다. 25개 언어 — 그중 한국어 포함 — 전 영역에서 OpenAI Whisper-large-v3를 앞선다는 것. 기존 경쟁 모델 대비 GPU 비용 50% 절감. 그리고 시간당 $0.36, 분당으로 환산하면 약 $0.006다.

    한국어 WER(단어 오류율)이 Whisper 대비 낮다는 게 자체 벤치마크 결과인데, 이건 독립 검증 전까지는 어디까지나 마케팅 숫자다. 실제 한국어 콜센터 녹음, 회의 음성 같은 실전 데이터로 직접 돌려 봐야 진짜 차이가 보인다.

    경쟁사와 단순 비교

    서비스 가격 한국어 특징
    MAI-Transcribe-1 $0.36/시간 O 실시간+배치, Azure 통합
    OpenAI Whisper API $0.006/분 ($0.36/시간) O 배치 전용
    Google STT v2 $0.016/분 ($0.96/시간) O 스트리밍
    AWS Transcribe $0.024/분 ($1.44/시간) O AWS 통합
    네이버 CLOVA 별도 문의 한국어 특화 한국어 최적화

    표만 보면 결론은 분명하다. Google과 AWS 대비 가격이 압도적으로 싸다. Whisper API와는 가격이 같은데 성능이 정말로 더 높다면, STT 워크로드를 옮길 이유가 생긴다. 키 포인트는 “정말로”다.

    실제 사용 — Azure 계정 있으면 5분

    Azure 구독이 있다면 AI Foundry에서 MAI-Transcribe-1 엔드포인트를 바로 배포할 수 있다. Python SDK 기준 코드는 군더더기가 없다.

    from azure.ai.inference import AudioTranscriptionClient
    from azure.core.credentials import AzureKeyCredential
    
    client = AudioTranscriptionClient(
        endpoint="https://[your-resource].services.ai.azure.com",
        credential=AzureKeyCredential("[API-KEY]")
    )
    
    with open("audio.mp3", "rb") as f:
        response = client.transcribe(
            body={"file": f, "language": "ko"}
        )
    
    print(response.text)

    기존에 Azure Cognitive Services STT를 쓰고 있던 환경이라면 엔드포인트와 모델명만 갈아 끼우면 된다. 마이그레이션 부담이 사실상 없다는 뜻이다.

    나머지 두 모델 짧게

    같은 발표에 끼어 나온 MAI-Voice-1은 텍스트 → 음성 변환 모델이다. 감정과 억양을 자연스럽게 표현하는 게 핵심 자랑거리고, 가격은 아직 공개 전, Azure AI Foundry 베타로 접근 가능하다. OpenAI TTS와 정면 충돌 포지션이다. MAI-Image-2는 이미지 생성 쪽이다. DALL-E 3 대비 사실적 인물 묘사와 텍스트 렌더링이 개선됐다는 주장이고, Microsoft Designer와 통합 예정이다. 둘 다 STT만큼 즉시 효과를 내는 영역은 아니지만, Microsoft가 OpenAI 의존도를 줄이려는 큰 그림은 분명히 보인다.

    그래서 — 옮길 가치가 있는가

    이미 Azure 위에 인프라가 올라가 있는 한국 기업이라면, MAI-Transcribe-1은 즉시 파일럿할 만하다. 콜센터 녹음 분석, 회의록 자동화, 자막 생성 — STT 워크로드가 매월 수백 시간을 넘어가는 팀이라면 Google·AWS 대비 비용 차이가 분기 단위 예산에서 체감된다. 다만 한 가지를 잊지 말자. Microsoft가 발표한 벤치 숫자는 자기 측정값이다. 한국어 실전 데이터로 Whisper API와 직접 WER을 비교해 본 다음에 결정하는 것이 안전하다.

    지금 할 일

    Azure 계정이 있다면 ai.azure.com에 들어가 MAI-Transcribe-1 엔드포인트를 1시간 안에 띄울 수 있다. 평소 자주 다루는 한국어 음성 파일 5~10개를 골라 Whisper API와 같은 조건으로 돌려 비교해 보자. WER 차이가 5% 이상 나면 옮길 가치가 있고, 1~2% 차이라면 가격 우위만으로 결정 근거가 충분하다.

    관련 글

    출처

  • ChatGPT 앱스토어란 무엇인가: Tubi 사례로 보는 AI 슈퍼앱 생태계 완전 정리

    ChatGPT 앱스토어란 무엇인가: Tubi 사례로 보는 AI 슈퍼앱 생태계 완전 정리

    퇴근 후 소파에 앉아 휴대폰을 켠다. ChatGPT를 열고 한 줄을 친다. “@Tubi 오늘 밤 볼 만한 90분짜리 스릴러 있을까?” 답이 돌아온다. 추천 목록 세 편, 그 자리에서 재생 버튼. 다른 앱을 열 필요는 없다. 4월 8일, 무료 스트리밍 서비스 Tubi가 ChatGPT 앱스토어 최초의 스트리밍 네이티브 앱을 띄운 날이 만들어 낸 풍경이다.

    이게 단순한 신기능 발표가 아닌 이유가 있다. ChatGPT가 운영체제처럼 작동하기 시작했다는 신호다.

    ‘챗봇 안의 챗봇’에서 ‘챗봇 안의 진짜 앱’으로

    OpenAI는 2024년 말 GPT 스토어를 열었지만, 그건 사실상 프롬프트 컬렉션에 가까웠다. 누가 만든 GPT를 골라 들어가도 결국 텍스트 응답이 전부였다. 2025년 말 등장한 네이티브 앱(Native Apps) 개념부터 분위기가 달라졌다. 핵심 차이는 액션(Actions)에 있다. 이전 GPT는 말을 만들어 냈고, 네이티브 앱은 행동을 한다. 예약, 결제, 재생, 구매 같은 실제 동작이 ChatGPT 창 안에서 끝난다.

    왜 하필 Tubi가 첫 타자였나

    흥미로운 건 Netflix도, Disney+도 아니고 Tubi였다는 점이다. Fox Corporation 산하의 무료 광고 기반 스트리밍 서비스. 30만 편 넘는 영화와 TV 프로그램을 무료로 푼다. 유료 구독 모델인 거대 OTT들은 ChatGPT를 통한 재생이 자기 앱 수익 구조를 위협한다고 본다. 반대로 Tubi는 광고 모델이라 노출이 늘어날수록 이득이다. 이해관계가 정확히 일치하는 첫 후보가 Tubi였던 셈이다.

    사용자 흐름은 단순하다. ChatGPT 대화창에서 @Tubi를 멘션하고 자연어로 요청하면, 모델이 Tubi 콘텐츠 DB를 조회하고 추천 목록을 보여 준다. 마음에 드는 작품을 누르면 그대로 Tubi 플레이어가 열린다. 이 한 사이클이 ChatGPT 한 화면에서 끝난다는 게 핵심이다.

    개발자 입장에서 본 진입 장벽

    네이티브 앱은 OpenAI의 Actions와 Plugin Manifest 구조 위에서 돌아간다. 기술적으로 보면 OpenAPI 스펙(openapi.yaml)을 따르는 REST API만 있으면 된다. 이 스펙을 OpenAI Developer Portal에 등록해 두면, ChatGPT가 사용자의 요청을 보고 언제 어떤 API를 호출할지 스스로 판단한다. 서버 쪽 코드는 일반적인 REST API 개발과 다를 게 없다.

    현재는 OpenAI 심사를 거쳐야 등록이 가능하고, 노출 대상은 ChatGPT Plus·Team·Enterprise 구독자다. Free 플랜으로의 확대는 예정 단계다. 진입 장벽이 그렇게 높지 않다는 점이 의미 있다. 이미 외부 서비스 API를 운영 중인 팀이라면 며칠이면 프로토타입을 띄울 수 있다.

    한국 사용자에게 진짜 의미

    지금 당장 한국 서비스의 ChatGPT 앱이 있는 건 아니다. 하지만 Tubi가 만든 선례 위에서 두 가지 길이 보인다. 하나는 글로벌을 노리는 한국 스타트업에게 새로 열린 배포 채널이다. App Store와 Play Store 외에 ChatGPT 안이 또 다른 진입점이 됐다. 다른 하나는 사내 도구 쪽이다. 사내 GPT를 따로 만들 필요 없이 회사 시스템 API를 ChatGPT 앱으로 등록하면, 직원들이 평소 쓰는 ChatGPT 안에서 그대로 사내 시스템에 접근할 수 있다. 두 시나리오 모두 지금 시점에 실험할 가치가 있는 영역이다.

    지금 할 일

    ChatGPT Plus 구독이 있다면 사이드바의 Explore GPTs에서 현재 어떤 앱이 올라와 있는지 한 번 둘러보는 게 첫 단계다. 개발자라면 platform.openai.com/docs/actions에서 Actions 개발 가이드를 훑어 두자. 자기 서비스에 맞는 연동 방식을 결정하려면 OpenAI Actions와 Anthropic 진영의 MCP가 어떻게 다른지 비교해 두는 것이 도움이 된다.

    관련 글

    출처

  • Claude Mythos & Project Glasswing: Anthropic이 최강 모델 배포를 거부한 이유

    Claude Mythos & Project Glasswing: Anthropic이 최강 모델 배포를 거부한 이유

    4월 7일, Anthropic이 보기 드문 발표를 했다. 자사 역사상 가장 강력한 모델을 만들었는데, 일반 사용자에게는 풀지 않겠다는 결정. 이름은 Claude Mythos. 그리고 그 모델에 접근할 수 있는 좁은 문의 이름은 Project Glasswing이다. AI 회사가 자기 모델 출시를 스스로 막은 사례는 업계에서 이례적이다.

    이번 결정을 어떻게 봐야 하는지, 경쟁 구도 안에서 어떤 의미인지 정리한다.

    Mythos가 어떤 모델인가

    공식 파라미터 수는 공개되지 않았다. 업계에서는 10조(10T) 파라미터 수준으로 추정한다. 단, 숫자 자체보다 중요한 건 포지셔닝이다. 기존 Claude 라인업은 글쓰기·코딩·분석을 두루 잘하는 범용 모델이었지만, Mythos는 다르게 설계됐다. 특정 영역의 추론 능력을 극단까지 끌어올린 전문 모델이다. Anthropic 내부 평가로는 같은 분야에서 GPT-5.4, Gemini Ultra를 앞선다.

    이 능력이 양날의 검이라는 게 출시 거부 결정의 핵심 근거다. 같은 추론 능력이 방어에도, 공격에도 쓰일 수 있기 때문이다. Anthropic은 이 모델을 무제한으로 풀면 의도와 정반대의 결과로 이어질 수 있다고 판단했다.

    Project Glasswing — 좁고 명확한 문

    대신 선택한 게 Glasswing이라는 제한 배포 프레임워크다. Apple, Microsoft, Amazon, Google을 포함한 40개 파트너사에만 접근권을 주고, 사용 목적과 범위를 사전에 심사한다. 단순한 API 키 발급 프로그램이 아니다. 참여 기업은 다음과 같은 조건을 충족해야 한다.

    • 해당 분야 전문 인력 보유 인증
    • 모델 출력물의 사용 목적 사전 신고
    • 발견 결과의 책임 있는 공개 절차 서약
    • Anthropic의 정기 감사 수용

    특히 Apple과의 협력이 주목할 만하다. WWDC 2026에서 발표된 시리 2.0의 일부 기능이 Mythos 기반으로 알려졌다. 아이폰·맥에 들어가는 온디바이스 모델이 아니라, 클라우드 측 추론 레이어에서 Mythos가 활용되는 구조다.

    경쟁 구도 안에서 본 의미

    가장 흥미로운 해석은 “안전성을 경쟁 우위로 만들 수 있다”는 점이다. OpenAI는 GPT-5.4를 가능한 한 빠르게 풀어 시장 점유율을 가져가는 전략을 쓴다. Anthropic은 정반대 카드를 꺼냈다. “우리는 너무 강력한 모델은 일부러 안 푼다”는 메시지를 던지면서 신뢰를 차별점으로 만든다. 규제 리스크가 큰 산업이나 정부 계약 시장에서는 이게 결정적인 차이가 될 수 있다.

    또 다른 해석은 영업 차원이다. Glasswing 파트너십에 들어가는 40개사는 모두 Anthropic의 가장 큰 잠재 고객이다. 일반 API로 풀었다면 누구나 쓸 수 있었을 모델을 한정 공급으로 만들면서 가치가 더 올라갔다. 선택지를 줄이는 게 오히려 협상력을 키우는 사례다.

    한국 사용자에게 의미

    당장 일반 사용자가 Mythos를 직접 쓸 수는 없다. 다만 두 가지 변화는 곧 체감될 가능성이 높다. 먼저 Glasswing 파트너로 들어간 글로벌 대기업들의 제품에 Mythos 기반 추론이 점점 들어간다. Apple, Microsoft 제품을 한국에서도 쓰는 만큼 간접적인 영향을 받는다. 두 번째는 한국 대기업의 파트너십 신청 가능성이다. 현재는 글로벌 40개사 제한이지만 점차 확대될 가능성이 있다. 보안과 컴플라이언스가 핵심인 금융, 통신, 공공 부문이라면 검토해 볼 카드다.

    지금 할 일

    일반 사용자라면 우선 anthropic.com/glasswing에서 공식 발표 내용을 직접 확인해 보는 게 시작이다. Anthropic의 안전 정책 방향성이 다른 AI 회사와 어떻게 다른지 비교해 보면 모델 선택 기준 자체가 명확해진다. 기업 보안·컴플라이언스 담당자라면 Glasswing 파트너십 조건이 자기 조직과 맞는지 검토하고, 향후 확대 시점을 대비해 사전 협의 채널을 열어 두는 것도 의미 있다.

    관련 글

    출처

  • GLM-5.1 완전 분석: 오픈소스가 드디어 Claude·GPT-5 꺾었나

    GLM-5.1 완전 분석: 오픈소스가 드디어 Claude·GPT-5 꺾었나

    “오픈소스 모델이 드디어 Claude를 꺾었다.” 4월 7일 HackerNews 5위에 오른 GLM-5.1 발표 글의 헤드라인이었다. 중국 스타트업 Z.ai가 칭화대와 함께 만든 코딩 특화 LLM. SWE-Bench Pro 1위를 자처하면서 Apache 2.0이 아닌 자체 라이선스로 풀었다. 진짜라면 Claude Code나 Cursor Pro를 끊고 무료로 같은 수준 코딩 AI를 쓸 수 있다는 얘기다.

    그런데 1위 주장은 항상 한 박자 늦게 검증된다. 오늘은 어디까지 사실이고 어디부터가 마케팅인지 따져 본다.

    모델 자체 사양

    GLM-5.1은 754B 파라미터 MoE(Mixture of Experts) 구조다. 전체 파라미터를 한 번에 활성화하지 않고 입력 종류에 따라 필요한 전문가 네트워크만 깨우는 방식이라, 전체 사이즈 대비 추론 비용이 낮다. 핵심 자랑거리는 코딩 능력이다. SWE-Bench Pro에서 1위, 그리고 8시간짜리 자율 코딩 태스크를 중단 없이 돌릴 수 있다는 점. 단일 프롬프트 응답이 아니라 1,700 스텝 규모의 에이전트 실행도 지원한다는 게 Z.ai의 주장이다.

    벤치마크 비교 — 표 위에서만 보면

    모델 SWE-Bench Pro 비용 오픈소스
    GLM-5.1 1위 (자체 측정) 무료(로컬) / API 저렴 O
    Claude Opus 4.6 상위권 $15/1M 토큰 X
    GPT-5.4 상위권 $10/1M 토큰 X
    MiniMax M2.7 SWE-Pro 56.22% $0.30/1M 토큰 X

    표 위에서만 보면 결정은 쉽다. 그런데 1위 주장의 근거가 자체 측정값이라는 점을 잊지 말아야 한다. 외부 검증이 나오기 전까지는 마케팅 숫자에 가깝게 보는 게 안전하다. 한국어 성능, 장기 컨텍스트 안정성, 실제 한국 회사 코드베이스에서의 동작은 자기 손으로 돌려 봐야 답이 나온다.

    실제로 쓰는 세 가지 길

    가장 빠른 시작은 z.ai 웹 플랫폼이다. 계정 만들고 채팅 인터페이스에서 바로 쓴다. API도 제공하는데, OpenAI 호환 포맷이라 기존 코드와 쉽게 붙는다. 이게 첫 번째 길이다.

    두 번째는 로컬 실행이다. 754B 풀 모델은 일반 PC로 무리지만, Z.ai는 경량화한 32B와 9B Distilled 버전을 같이 풀었다. 32B는 RTX 4090급 24GB VRAM이 있으면 돌고, 9B는 16GB로도 충분하다. Ollama가 설치돼 있다면 한 줄이다.

    ollama pull glm5.1:32b
    ollama run glm5.1:32b

    세 번째는 기존 코딩 에이전트와 연결이다. Cursor의 Custom Model 설정이나 Continue.dev에서 Base URL만 갈아 끼우면 된다. OpenAI 호환이라 생각보다 매끄럽다.

    Base URL: https://api.z.ai/v1
    Model: glm-5.1
    API Key: [Z.ai에서 발급]

    월 20달러 vs 베타 가격

    Claude Code Pro나 Cursor Pro에 매달 20달러 이상을 쓰고 있는 개발자라면 GLM-5.1은 검토할 만한 카드다. API는 베타 기간 파격 가격을 제공 중이고, 로컬 Distilled 버전은 초기 셋업이 끝나면 추가 비용이 0이다. 단, 코딩 에이전트 생태계와의 통합 성숙도가 Claude·GPT 수준은 아직 아니다. 익스텐션 지원, 한국어 품질, 장기 컨텍스트 안정성 — 이 세 가지는 직접 쓰면서 판단해야 한다.

    지금 할 일

    가장 비용이 적은 검증 방법은 z.ai에서 무료 계정을 만들어 평소 작업하던 코드 일부를 그대로 던져 보는 것이다. 한국어로 된 주석이 섞인 파일, 회사 코드 스타일이 들어간 함수 — 벤치마크 숫자가 아니라 본인이 매일 쓰는 데이터로 비교해야 한다. 16GB VRAM 이상 GPU가 있다면 9B 로컬 버전도 1시간이면 띄운다. 결과가 마음에 들면 Continue.dev 연결로 넘어가서 실제 업무 한 사이클을 돌려 보는 게 다음 단계다.

    관련 글

    출처

  • 2026 개발자 AI 코딩툴 실사용 순위: JetBrains 1만 명 조사 결과 분석

    2026 개발자 AI 코딩툴 실사용 순위: JetBrains 1만 명 조사 결과 분석

    85%. JetBrains가 4월에 발표한 글로벌 개발자 1만 명 대상 조사에서, “직장에서 AI 코딩툴을 정기적으로 쓴다”고 답한 비율이다. 1년 전 같은 조사에서는 52%였다. 12개월 만에 33%포인트가 올라갔다. 도입을 망설이는 시기는 사실상 끝났다는 뜻이다.

    그런데 이 숫자보다 더 흥미로운 디테일이 안에 숨어 있다.

    Copilot 1위, 그러나 멈췄다

    여전히 1위는 GitHub Copilot이다. 직장 내 사용률 29%. 그런데 전년 대비 증가폭이 단 2%포인트에 그쳤다. 사실상 정체다. 이미 들어갈 만한 곳엔 다 들어갔고, 추가 성장 여지가 줄어든 시장 포화 상태로 해석된다. Copilot이 졌다는 얘기는 아니다. 다만 “AI 코딩툴을 처음 도입할 때 자동으로 Copilot을 고른다”는 시기는 지났다.

    Claude Code, 6배라는 숫자

    이번 조사에서 가장 충격적인 수치는 Claude Code 쪽이다. 직장 내 사용률이 6개월 사이 3%에서 18%로 뛰었다. 6배다. 단순 자동완성을 넘어 멀티파일 작업과 자율 에이전트 흐름이 가능하다는 점이 결정적이었던 것으로 보인다. 1년 전에는 거의 존재감이 없던 도구가, 지금은 Copilot 다음 자리로 단숨에 올라섰다.

    이 변화는 단순한 시장 점유율 게임이 아니다. 개발자가 AI 도구에 기대하는 것 자체가 바뀌었다는 신호다. “한 줄 자동완성”에서 “한 작업 통째로 맡기기”로.

    실제로 쓰는 다섯 가지 작업

    조사에서 개발자들이 실제로 AI에게 시키는 일 상위 다섯 가지를 보면 변화의 방향이 더 분명해진다.

    1. 코드 자동완성 (78%) — 가장 많이 쓰지만 더 이상 차별점이 아님
    2. 코드 설명·문서화 (64%) — 레거시 코드 이해, 주석 자동 생성
    3. 버그 수정 제안 (61%) — 에러 메시지 붙여 넣고 해결책 받기
    4. 테스트 코드 생성 (54%) — 반복적인 단위 테스트 작성
    5. 멀티파일 에이전트 작업 (31%) — 여러 파일을 한 번에 수정하는 자율 작업

    5위에 들어간 멀티파일 에이전트 작업이 이미 3명 중 1명 수준이라는 게 핵심이다. 1년 전 조사에는 이 항목 자체가 없었다. 새 카테고리가 생긴 것 자체가 시장 변화를 보여 준다.

    만족도와 도입 장벽

    한 번 쓰기 시작한 사람들의 79%가 “없으면 불편할 것”이라고 답했다. 사실상 의존도다. 반면 아직 안 쓰는 15% 그룹의 절반 이상이 “회사 보안 정책”을 이유로 꼽았다. 개인 의지가 아니라 조직 정책이 막고 있다는 뜻이다. 한국 기업이라면 익숙한 풍경이다.

    한국 개발자에게 의미

    두 가지 결론이 분명해진다. AI 코딩툴은 더 이상 “쓸지 말지”의 문제가 아니라 “어떻게 조합할지”의 문제다. 그리고 자동완성 수준에 머무는 도구는 빠르게 차별점을 잃고 있다. Claude Code, Cursor Composer 같은 멀티파일·에이전트 기반 흐름을 손에 익히는 게 지금 시점의 가장 큰 격차 변수다.

    국내 개발자 커뮤니티에서는 GitHub Copilot 사용자는 많지만 Claude Code는 상대적으로 낯선 경우가 적지 않다. 글로벌 추세를 감안하면 1년 안에 격차가 더 벌어질 가능성이 높다.

    지금 할 일

    Copilot만 쓰고 있다면 가장 먼저 해 볼 일은 claude.ai/code에서 개인 프로젝트로 Claude Code를 한두 시간 굴려 보는 것이다. 멀티파일 에이전트 작업이 어떻게 다른지 직접 손에 익혀야 비로소 이번 통계 안의 31%가 무슨 뜻인지 와닿는다. 회사 보안 정책으로 막혀 있다면 차단 사유를 정확히 확인해 보자. 코드 외부 전송이 문제라면 로컬 LLM(Ollama + Gemma 4 등) 기반 대안이 있고, 라이선스 문제라면 엔터프라이즈 플랜으로 해결되는 경우가 많다.

    관련 글

    출처

  • Junie CLI 완전 정리: Claude Code 대신 어떤 LLM도 쓸 수 있는 코딩 에이전트

    Junie CLI 완전 정리: Claude Code 대신 어떤 LLM도 쓸 수 있는 코딩 에이전트

    코딩 에이전트는 이미 충분히 많다. Claude Code, Cursor, Codex, Aider, Windsurf — 손가락 두 손으로도 다 안 꼽힌다. 그런데 JetBrains가 3월 베타로 푼 Junie CLI는 그 사이에 또 하나의 자리를 만들었다. 이유는 단순하다. 모델을 묶지 않는다.

    Claude Code는 Anthropic 모델만 돈다. Cursor는 IDE 안에서만 살아 있다. Junie는 두 제약을 동시에 푼다. BYOK(Bring Your Own Key) 방식으로 OpenAI, Anthropic, Google, xAI, 로컬 Ollama까지 — 어떤 모델이든 갈아 끼우면서 터미널·IDE·CI/CD 어디서든 굴린다.

    Claude Code와의 차이를 한 표로

    구분 Claude Code Junie CLI
    사용 모델 Anthropic 전용 모든 LLM (BYOK)
    실행 환경 터미널 터미널 + IDE + CI/CD
    비용 구조 Claude 구독 필요 사용 모델 API 비용만
    GitHub 통합 제한적 GitHub/GitLab Actions 직접 연결
    멀티 에이전트 단일 병렬 에이전트 실행 지원

    설치는 한 줄

    npm 한 줄이면 설치가 끝난다.

    npm install -g @jetbrains/junie-cli

    처음 한 번은 어떤 LLM 제공자를 쓸지 정해 줘야 한다.

    junie init
    # 제공자 선택: OpenAI / Anthropic / Google / xAI / Ollama(로컬) 등
    # API 키 입력
    # 기본 모델 설정

    이후엔 프로젝트 디렉토리 안에서 자연어 한 줄로 작업을 던진다.

    cd my-project
    junie "로그인 API에 JWT 갱신 로직 추가해줘"

    실전에서 빛나는 세 가지 시나리오

    Junie의 진가는 모델 교체 자유도에서 나온다. 첫 번째 시나리오는 비용 최적화다. 복잡한 아키텍처 설계는 Claude Opus 4.6에 맡기고, 단순 반복 코드 생성은 GLM-5.1 API나 로컬 Ollama로 돌리도록 작업 종류별로 모델을 분리할 수 있다. 같은 한 달 동안 비용을 절반 이하로 줄이는 게 어렵지 않다.

    두 번째는 CI/CD 파이프라인 통합이다. GitHub Actions에서 Junie를 트리거하면 PR이 올라올 때마다 자동으로 코드 리뷰, 테스트 보완, 문서 업데이트를 실행할 수 있다.

    # .github/workflows/junie-review.yml
    - name: Junie Code Review
      run: junie review --model claude-opus-4-6 --pr ${{ github.event.pull_request.number }}

    세 번째 시나리오가 가장 중요할 수 있다. 회사 보안 정책으로 외부 API 사용이 막힌 환경. Ollama와 연결해 완전히 오프라인 상태에서 에이전트 코딩이 가능하다. 코드를 사외로 보낼 일이 0이 된다. 이게 한국 대기업·금융권에서 의미가 큰 이유다.

    아직 베타라는 점은 잊지 말 것

    장점만 있는 도구는 없다. 복잡한 멀티파일 리팩토링에서는 Claude Code 대비 컨텍스트 유지력이 떨어진다는 사용자 피드백이 있다. JetBrains IDE(IntelliJ, PyCharm 등)와의 통합은 매끄럽지만 VS Code 쪽은 별도 설정이 필요하다. 베타 단계임을 감안하고 작은 작업부터 시작하는 게 안전하다.

    한국 개발자에게 의미

    Anthropic 모델에 종속되고 싶지 않거나, 모델별로 비용·성능을 직접 조정하고 싶은 개발자에게 Junie CLI는 실질적인 카드다. 특히 Java·Kotlin·Python을 주로 쓰면서 JetBrains IDE를 일상으로 쓰는 환경이라면 통합 완성도가 가장 높다. 비용에 민감한 스타트업·프리랜서, 그리고 외부 API가 막힌 보안 조직 — 이 세 그룹이 가장 빠르게 효과를 본다.

    지금 할 일

    일단 설치한 다음 평소에 자주 하던 작업 하나를 던져 본다. 같은 작업을 OpenAI 모델, Anthropic 모델, 그리고 GLM-5.1 같은 저가 모델로 차례차례 돌려 보면 자기 워크플로에 어떤 모델 조합이 맞는지 한 시간이면 감이 잡힌다. 그 다음 단계는 GitHub Actions에 PR 리뷰 자동화 한 줄을 붙여 보는 것. 이게 Junie가 다른 도구들과 가장 크게 차이 나는 지점이다.

    관련 글

    출처

  • Google Scion 완전 정리: 여러 AI 에이전트를 동시에 돌리는 멀티 에이전트 오케스트레이션

    Google Scion 완전 정리: 여러 AI 에이전트를 동시에 돌리는 멀티 에이전트 오케스트레이션

    지난 1년의 코딩 에이전트 발전사는 한 줄로 요약된다. “한 명의 슈퍼 에이전트를 어떻게 더 똑똑하게 만들까.” Claude Code, Cursor, Codex가 그 방향이었다. 그런데 4월에 Google이 오픈소스로 푼 Scion은 다른 질문을 던진다. “왜 한 명만 써야 하지?”

    Scion은 Google Cloud Platform이 GitHub에 공개한 멀티 에이전트 테스트베드다. 핵심 개념은 단순하다. Claude Code, Gemini CLI, OpenAI Codex 같은 서로 다른 코딩 에이전트를 각자의 컨테이너에서 동시에 띄우고, 그 결과물을 위에서 조율하는 레이어를 제공한다. 일부 개발자가 “에이전트의 하이퍼바이저”라고 부르기 시작한 이유가 여기에 있다.

    왜 굳이 여러 명을 쓰나

    단일 에이전트의 한계는 두 가지다. 첫째, 한 명이 백엔드 API 수정 → 프론트엔드 컴포넌트 업데이트 → 테스트 코드 작성을 순차로 처리하면 시간이 그대로 누적된다. 둘째, 각 작업에 가장 잘 맞는 모델이 다르다. 코드 리뷰는 Claude Opus 4.6의 추론 깊이가 좋고, 단순 코드 생성은 GLM-5.1이 비용 대비 효율적이고, 테스트 작성은 Gemini Flash로도 충분하다. 한 모델이 모든 영역에서 최적인 경우는 거의 없다.

    멀티 에이전트는 이 두 한계를 동시에 푼다. 작업을 나눠 병렬로 돌리고, 작업별로 최적 모델을 매칭한다. 시간도 비용도 줄어든다.

    구조 — 컨테이너 단위 격리

    Scion Orchestrator
    ├── Agent Container A (Claude Code)
    │     └── 담당: 백엔드 API 설계 + 구현
    ├── Agent Container B (Gemini CLI)
    │     └── 담당: 테스트 코드 + 문서화
    └── Agent Container C (Codex)
          └── 담당: 프론트엔드 컴포넌트

    각 컨테이너는 독립된 파일시스템과 환경변수를 갖는다. 같은 코드베이스를 동시에 수정하면서도 충돌이 안 나는 이유는 Scion이 내부적으로 git 브랜치 전략을 관리하기 때문이다. 작업이 끝나면 머지 충돌을 해결하고 통합한다.

    실제 실행

    설치는 GitHub 클론 + Docker Compose다.

    git clone https://github.com/GoogleCloudPlatform/scion
    cd scion
    cp .env.example .env
    # .env에 각 에이전트 API 키 설정
    docker compose up

    워크플로는 YAML로 선언한다. 어떤 에이전트가 무엇을 담당하고, 어떤 작업이 어떤 작업에 의존하는지 단순한 문법으로 적어 두면 된다.

    workflow:
      - agent: claude-code
        task: "백엔드 /api/users 엔드포인트 구현"
        branch: feat/backend
      - agent: gemini-cli
        task: "위 엔드포인트 단위테스트 작성"
        depends_on: claude-code
        branch: feat/tests

    아직 실험 단계라는 점

    Google 스스로 “experimental”이라고 표시해 둔 프로젝트다. 에이전트 간 컨텍스트 공유는 아직 제한적이고, 대형 코드베이스에서는 머지 충돌 해결 품질이 들쑥날쑥하다. 프로덕션 도입보다는 실험과 학습 목적으로 보는 게 정확하다. 단, 멀티 에이전트 협업이 1~2년 안에 표준이 될 가능성이 높은 만큼, 지금 손에 익혀 두는 가치는 크다.

    한국 개발자에게 의미

    Scion 자체를 당장 회사 인프라에 올리기는 이르다. 하지만 이 방향성은 분명하다. 머지않아 여러 에이전트를 조율하는 오케스트레이션 레이어가 개발 워크플로의 기본 인프라가 된다. 지금 Scion을 손으로 굴려 보는 건 그 흐름을 미리 익히는 작업이다. 비교 학습 대상으로 Paperclip AI나 LangGraph 같은 다른 오케스트레이션 프레임워크를 같이 봐 두면 멀티 에이전트 아키텍처에 대한 감이 더 빠르게 잡힌다.

    지금 할 일

    가장 가벼운 시작은 GitHub에서 Scion 레포를 클론해 Docker Compose 데모를 한 번 띄워 보는 것이다. 처음부터 4개 에이전트를 동시에 굴리지 말고 Claude Code + Gemini CLI 두 명만으로 단순한 분리 작업(예: 백엔드 함수 + 그 함수의 단위 테스트)을 돌려 보면 멀티 에이전트의 감이 가장 빠르게 잡힌다. 그 다음 단계로 Paperclip이나 LangGraph 같은 대안과 어떤 차이가 있는지 비교해 두면 자기 워크플로에 맞는 도구를 고르는 기준이 생긴다.

    관련 글

    출처