Google Antigravity, /swarm 출시: AI 코딩이 단일 Agent 실행에서 다중 Agent 팀 협업으로 전환되며 나타난 4가지 역할 해설

作者按：이 글은 Google Antigravity의 공식 블로그와 사용 문서를 바탕으로, /swarm에서 여러 에이전트가 어떻게 역할을 나누고 협업하는지, 진행 상황을 어떻게 시각적으로 관리하는지, 그리고 어떤 한계가 있는지 정리했어요.

2026년 11월 10일, Gemini 4 Carbon이 정식으로 공개됐어요. 같은 날 Google Antigravity 팀은 /swarm 멀티 에이전트 협업 기능(Preview)도 내놓았어요. 이 명령어를 쓰면 대화 하나가 AI 엔지니어링 팀으로 바뀌어요. 작업을 쪼개는 에이전트, 코드를 작성하는 에이전트, 검수하는 에이전트, 진행이 막힌 곳을 찾아내는 에이전트가 각자 역할을 맡아요.

이 기능은 공개된 근거가 있어요. Antigravity 공식 블로그와 Swarm 사용 문서가 이미 올라와 있고, Google은 자사 엔지니어들이 약 5주 동안 내부에서 사용해 왔다고 밝혔어요. /swarm의 핵심은 채팅 창을 여러 개 동시에 띄우는 데 있지 않아요. 작업을 스스로 분해하고, 병렬로 실행하고, 진행 상황을 공유하고, 서로 검증하면서 문제를 계속 고쳐 나가는 협업 시스템을 만들려는 시도예요.

핵심 가치: 이 글을 읽으면 /swarm이 실제로 어떻게 실행되는지, 각 역할이 어떻게 맞물려 일하는지, 사용자가 진행 상황을 어떻게 보고 개입할 수 있는지, 그리고 할당량과 권한 면에서 어떤 현실적인 제약이 있는지 알 수 있어요.

알아두면 좋은 Google Antigravity /swarm 핵심 용어

/swarm에는 역할을 나타내는 용어가 여러 개 나와요. 먼저 이 개념들을 정리해 두면 뒤에 나오는 동작 방식을 훨씬 쉽게 이해할 수 있어요.

Google Antigravity /swarm이란? 핵심 정보 한눈에 보기

/swarm은 Gemini 4 Carbon의 정식 공개와 함께 발표됐지만, 둘은 서로 다른 것이에요. 전자는 Antigravity 안에서 동작하는 멀티 Agent 오케스트레이션 기능이고, 후자는 모델이에요. 아래 표는 지금까지 공식적으로 공개된 정보를 정리한 거예요.

단일 Agent가 대규모 엔지니어링 작업을 감당하기 어려운 이유

단일 Agent는 함수 하나, 버그 하나를 처리할 때는 꽤 잘 동작해요. 그런데 작업이 수십 개의 파일, 여러 모듈 간 의존성으로 넓어지거나 테스트를 반복해서 돌려야 하는 상황이 되면, Agent 하나가 같은 컨텍스트 안에서 모든 세부 사항을 기억해야 해요. 컨텍스트가 길어질수록 앞에서 정한 제약 조건이 뒤쪽의 실행 세부 내용에 밀려 사라지기 쉬워요.

작업 분배도 어려운 부분이에요. 단일 Agent는 순차적으로만 실행할 수 있어서, A 모듈 수정이 끝나지 않으면 B 모듈 조사는 기다려야 해요. 실제로는 병렬로 쪼갤 수 있는 엔지니어링 작업이 많아요. 예를 들어 서로 다른 패키지의 실패한 테스트를 각각 고치는 경우처럼요. 이런 작업을 직렬로 처리하면 시간이 낭비돼요.

가장 놓치기 쉬운 부분은 검증이에요. 코드를 작성한 Agent가 자기 코드를 점검하면 처음 세운 가정을 그대로 가져가기 쉬워서, 접근 방식 자체의 편차를 발견하지 못해요. 사람 팀에서는 다른 사람이 코드 리뷰를 하죠. /swarm은 이런 역할 분담 방식을 AI 코딩 흐름에 그대로 가져온 기능이에요.

Google Antigravity /swarm으로 Agent 팀을 시작하는 방법

공식 사용 문서에 따르면 /swarm <task>를 실행하면 다음 순서로 진행돼요.

1. 현재 대화가 Coordinator로 전환돼요: 지금 대화 중인 Agent가 조율자가 되어 전체 작업을 파악해요.
2. 작업 내용을 분할해요: Coordinator가 작업 구조에 맞춰 여러 하위 작업으로 나눠요.
3. 독립된 Worker를 생성해요: 하위 작업마다 Worker가 하나씩 배정되고, 각 Worker는 독립된 컨텍스트와 공개된 작업 설명서를 받아요.
4. 실행과 검증을 해요: Worker는 코드를 수정하거나 조사를 진행해요. Verifier는 코드 변경 사항을 검토하고 테스트를 실행한 뒤, 문제가 있으면 해당 Worker에게 피드백을 전달해요.
5. 수정 루프를 돌아요: Worker가 피드백에 따라 수정하고, 수정한 결과는 다시 검증을 받아요.
6. 결과를 취합해서 보고해요: Coordinator가 각 구성원의 결과를 통합해 사용자에게 보고해요.

각 Worker의 컨텍스트는 서로 분리되어 있고, 자신이 맡은 작업의 정보만 담고 있어요. 그래서 긴 컨텍스트가 서로 오염되는 문제가 줄어들어요. 작업 설명서는 공개되어 있기 때문에 다른 구성원도 누가 무엇을 하고 있는지 알 수 있고, 역할의 경계도 분명해져요.

/swarm 팀 역할 분담: Coordinator, Worker, Verifier, Monitor

공식 문서에 따르면 Swarm 팀은 보통 네 가지 역할로 구성돼요. 다만 이건 공식 문서가 설명하는 전형적인 구성 방식일 뿐, 모든 작업에 똑같이 적용되는 고정 아키텍처는 아니에요. Worker를 몇 명 만들지, 추가 멤버가 필요한지는 Coordinator가 작업 내용에 따라 결정해요.

/swarm의 Verifier와 Monitor 메커니즘

공식 블로그는 Verifier를 “적대적 검증 Agent”라고 불러요. 이 Agent의 임무는 문제를 찾아내는 거예요. 다른 Agent가 수정한 내용을 검사하고, 테스트를 실행하고, 타당하지 않은 변경에는 의문을 제기해요. Worker는 피드백을 받아 수정한 뒤 다시 제출해 검사를 받아요. 이렇게 실행과 검증이 하나의 순환 구조를 이뤄요.

Monitor는 또 다른 종류의 위험을 다뤄요. 여러 Agent가 협업하다 보면 모든 멤버가 서로를 기다리기만 하고 아무도 앞으로 나아가지 않는 상황이 생길 수 있어요. Monitor는 평소에는 휴면 상태로 있다가, 팀 전체의 활동이 멈췄는데 작업이 끝나지 않았다는 걸 발견하면 관련 멤버를 깨워요. 덕분에 팀이 막혔을 때 사용자가 직접 개입하는 데만 의존하지 않아도 돼요.

/swarm에서는 역할마다 다른 모델을 쓸 수 있어요

Google은 공식 블로그에서 모든 Agent에 가장 비싼 모델을 쓰지 말고, 역할 특성에 맞게 모델을 배분하라고 제안해요.

• Gemini 4 Carbon 사용: 전체 아키텍처 설계, 작업 조율, 보안 검토, 복잡한 코드 감사
• 더 빠르고 가벼운 모델 사용: 일반적인 코드 구현, 병렬 파일 수정
• 전용 검증 Agent 사용: 자동 테스트 및 검증

공식 문서 예제에도 서로 다른 모델이 각각 코드 구현과 독립 검증을 맡는 사용법이 있어요. 비용과 성능의 균형을 맞추는 접근이에요. 복잡한 판단은 강력한 모델에, 대량의 실행 작업은 빠른 모델에 맡기는 거예요.

💡 선택 팁: 직접 구축하는 멀티 Agent 파이프라인에서도 역할별로 모델을 조합하고 싶다면, 먼저 APIYI(apiyi.com)에서 같은 API 키 하나로 여러 모델을 테스트해 보세요. 계획 수립, 구현, 검토 단계에서 각 모델이 어떤 성능을 보이는지 확인할 수 있어요. 역할별로 적합한 모델을 정한 뒤에 설정을 고정하면 되고, 모델을 바꿀 때는 model 파라미터만 수정하면 돼요.

/swarm 여러 Agent가 서로 간섭하지 않고 협업하는 방법

공유 메시지 보드: Agent 간의 공개 소통

모든 Agent는 추가 전용(append-only) 공유 메시지 보드(Shared Message Board)를 함께 사용하며, 협업 과정과 작업 진행 상황이 이 보드에 기록돼요. 메시지는 추가만 가능하고 덮어쓸 수 없어서, 팀의 소통 이력을 처음부터 끝까지 추적할 수 있어요. Agent는 다른 팀원을 기다리는 동안 휴면 상태로 있다가, 입력이 필요할 때 다시 깨어나요. Google에 따르면 이렇게 대기하는 동안에는 토큰이 소모되지 않는다고 해요.

이런 설계는 Agent끼리 몰래 서로를 호출하는 방식보다 훨씬 투명해요. Verifier가 Worker에게 준 피드백이나 Coordinator의 스케줄링 결정이 모두 공개적으로 드러나기 때문에, 사용자가 나중에 복기할 때 어느 단계에서 문제가 생겼는지 분명하게 확인할 수 있어요.

공유 작업 공간과 독립 작업 복사본의 차이

이 부분은 공식 블로그와 사용 문서의 설명이 서로 달라서 잘못 쓰기 쉬워요. 블로그에서는 병렬 Worker가 격리된 Git Worktree에서 작업할 수 있어, 같은 디렉터리를 직접 수정하는 일을 피할 수 있다고 강조해요. 반면 사용 문서에는 더 세밀한 규칙이 나와 있어요.

• 기본 동작: Workers는 현재 작업 공간을 공유해요.
• 필요 시 격리: 여러 Worker가 동시에 프로젝트를 수정하거나 빌드해야 할 때, Coordinator가 각각에 독립된 코드 작업 복사본을 할당할 수 있어요.
• 제거하면 삭제: Worker를 제거하면 해당 Worker의 작업 복사본도 함께 삭제돼요. 그러니 먼저 결과물을 병합하거나 커밋해 두어야 해요.

따라서 정확하게 말하면, 시스템이 병렬 작업의 필요에 따라 격리된 작업 복사본을 배정하는 것이지, 모든 Agent가 기본적으로 완전히 독립된 Git Worktree를 갖는 것은 아니에요. 조사만 하고 파일은 수정하지 않는 작업이라면 공유 작업 공간으로 충분해요. 반면 여러 Worker가 동시에 코드를 수정하거나 빌드를 돌릴 때는 독립 복사본을 쓰는 편이 파일 충돌을 줄여 줘요.

Antigravity에서 /swarm 팀을 관찰하고 제어하는 방법

여러 Agent가 동시에 일할 때 가장 불안한 건 내부에서 무슨 일이 벌어지는지 알 수 없다는 점이에요. Antigravity는 이를 위해 세 가지 핵심 뷰를 제공하고, CLI에도 대응하는 단축 조작이 있어요.

사용자의 제어권은 결과를 확인하는 데서 끝나지 않아요. 이런 진입점을 통해 각 Agent의 작업 흔적을 살펴보고, 특정 Worker에 직접 들어가 개입하거나, Coordinator의 작업 요구 사항을 조정할 수 있어요. Alt + J와 Ctrl + K가 있다는 건 도구 호출 승인 권한이 여전히 사람에게 남아 있다는 뜻이에요. Agent는 민감한 작업을 실행해야 할 때 멈춰서 확인을 기다려요.

/swarm으로 해결할 수 있는 복잡한 엔지니어링 작업

Google이 공개한 내부 사용 사례는 크게 세 가지예요. 다중 패키지 마이그레이션, 서브시스템을 넘나드는 근본 원인 조사, 복잡한 소프트웨어 아키텍처 재설계죠. 공통점은 작업량이 많고, 나눌 수 있으며, 검증이 필요하다는 거예요.

공식 사용 문서에 나온 예시는 일상적인 개발에 더 가까워요.

• 여러 API Handler를 각각 수정하고, Handler마다 테스트 구성하기
• CLI 시작이 느린 근본 원인을 병렬로 조사하기
• 대형 프로젝트에서 실패한 테스트를 패키지별로 묶어 서로 다른 Agent에게 수정 맡기기
• 코드 구현과 독립적인 검증을 서로 다른 모델이 나눠서 맡기기

Google은 공식 데모도 하나 선보였어요. Antigravity의 멀티 Agent 협업을 활용해 Carbon이 공개된 도시 계획 PDF 7개를 처리하고, 엔지니어링 도면 뷰 206개를 추출해 약 906,000개의 삼각형 면으로 이뤄진 인터랙티브 Three.js 건축 모델을 만들어 냈어요. 이 과정은 야간 반복 작업 10라운드에 걸쳐 진행됐어요. 이건 Google의 공식 사례일 뿐 독립적인 제3자 검증은 아니지만, 장기간 이어지는 작업에서 멀티 Agent가 역할을 어떻게 나누는지는 엿볼 수 있어요.

/swarm의 비용, 권한, 그리고 Preview 제한

멀티 에이전트의 할당량 소모

대기 중인 에이전트는 토큰을 소모하지 않아요. 하지만 그렇다고 /swarm이 비용을 아껴 주는 건 아니에요. Worker 하나하나가 독립된 에이전트라서, 여러 멤버가 동시에 작업하면 전체 할당량이 단일 대화보다 눈에 띄게 빨리 줄어들어요. Google도 이 점을 직접 안내하고 있어요.

또 하나 자주 걸려 넘어지는 함정이 있어요. 어떤 Worker가 할당량을 모두 쓰면 작업이 일시 중지되는데, 나중에 할당량이 회복되더라도 자동으로 작업을 이어 가지 않아요. 사용자가 직접 처리해야 해요. 오래 걸리는 대형 작업을 시작하기 전에는 할당량이 충분한지 먼저 가늠해 보는 게 좋아요.

Swarm 기능 권한 ≠ Carbon 모델 권한

가장 헷갈리기 쉬운 부분이에요. /swarm을 쓸 수 있다고 해서 Swarm 안에서 Carbon까지 쓸 수 있는 건 아니에요.

정리하면, Pro 사용자도 Swarm의 협업 방식을 체험해 볼 수는 있어요. 다만 에이전트가 어떤 모델을 쓸 수 있는지는 각자의 구독이 허용하는 모델 권한에 따라 달라져요.

영향 분석: /swarm이 AI 코딩을 어시스턴트에서 팀 단위로 바꾼다

개발자에게 미치는 영향

• 역할의 변화: 개발자는 “모델에게 질문하는 사람”에서 “AI 팀을 꾸리는 사람”으로 바뀌어요. 작업을 얼마나 잘 쪼개고 검수 기준을 어떻게 세우느냐가 결과에 곧바로 영향을 줘요.
• 검증이 앞단으로: Verifier 메커니즘 덕분에 테스트와 리뷰가 워크플로의 기본 단계로 자리 잡아요. 코드를 생성한 뒤에 뒤늦게 수습하는 작업이 아니게 되는 거예요.
• 비용 관리가 중요해짐: 여러 Worker가 병렬로 돌아가기 때문에 사용 한도, 모델 조합, 작업 단위의 크기까지 신경 써야 해요. 단일 대화에서 느끼는 경험만 봐서는 안 돼요.

업계에 미치는 영향

• 멀티 모델 협업이 배포 방향으로 부상: 강력한 모델은 계획과 리뷰를 맡고, 빠른 모델은 대량 실행을 맡는 이런 역할 분담을 참고하는 Agent 프레임워크가 점점 늘어날 거예요.
• 경쟁의 초점이 작업 완수로 이동: 모델 경쟁이 단일 턴 질의응답 점수에서 벗어나, 장기 작업의 계획·실행·검증·완수 능력으로 옮겨 가고 있어요.

API로 /swarm 멀티 에이전트 방식 재현하기: 최소 예제

“조율자가 작업을 쪼개고, 작업자가 실행한다”는 방식을 내 프로젝트에서 시험해 보고 싶다면 OpenAI 호환 인터페이스로 최소 프로토타입을 만들어 볼 수 있어요. 아래 코드는 협업 구조만 보여 주는 예제이며, Antigravity /swarm의 실제 구현이 아니에요. 모델 이름은 본인 계정에서 사용할 수 있는 모델로 바꿔 주세요.

from openai import OpenAI

client = OpenAI(api_key="YOUR_API_KEY", base_url="https://api.apiyi.com/v1")

def ask(model, prompt):
    resp = client.chat.completions.create(
        model=model, messages=[{"role": "user", "content": prompt}]
    )
    return resp.choices[0].message.content

plan = ask("STRONG_MODEL", "把“修复 3 个 API Handler 的失败测试”拆成独立子任务，每行一个")
for task in [t for t in plan.splitlines() if t.strip()]:
    print(ask("FAST_MODEL", f"完成这个子任务并给出补丁：{task}"))

import concurrent.futures as cf
from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # APIYI OpenAI 호환 인터페이스
)

COORDINATOR_MODEL = "STRONG_MODEL"   # 계획 수립 및 취합용, 추론 능력이 뛰어난 모델로 교체
WORKER_MODEL = "FAST_MODEL"          # 일괄 실행용, 빠르고 가벼운 모델로 교체
VERIFIER_MODEL = "REVIEW_MODEL"      # 독립 검토용, Worker와 다른 모델을 권장
board = []                           # 추가 전용(append-only) 공유 메시지 보드

def ask(model, system, prompt):
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "system", "content": system},
                  {"role": "user", "content": prompt}],
    )
    return resp.choices[0].message.content

def worker(task, max_rounds=3):
    patch = ask(WORKER_MODEL, "你是 Worker，只负责分配给你的子任务。", task)
    for i in range(max_rounds):
        review = ask(VERIFIER_MODEL,
                     "你是 Verifier，检查补丁问题。没有问题只回复 PASS。",
                     f"任务：{task}\n补丁：\n{patch}")
        board.append(f"[Verifier] {task[:20]}... 第{i+1}轮：{review[:60]}")
        if review.strip().startswith("PASS"):
            return patch
        patch = ask(WORKER_MODEL, "根据审查意见修复补丁。",
                    f"任务：{task}\n原补丁：{patch}\n意见：{review}")
    return patch + "\n# 未通过验证，需人工检查"

goal = "为 users、orders、payments 三个 API Handler 补充输入校验并修复失败测试"
plan = ask(COORDINATOR_MODEL, "你是 Coordinator，把目标拆成互不重叠的子任务，每行一个。", goal)
tasks = [t.strip() for t in plan.splitlines() if t.strip()]
board.append(f"[Coordinator] 拆分为 {len(tasks)} 个子任务")

with cf.ThreadPoolExecutor(max_workers=4) as pool:
    results = list(pool.map(worker, tasks))

summary = ask(COORDINATOR_MODEL, "汇总各 Worker 结果，列出完成情况与风险。",
              "\n\n".join(results))
print("\n".join(board))
print(summary)

🚀 빠른 시작: 이런 멀티 역할 프로토타입을 만들 때는 APIYI(apiyi.com)에서 API 키와 신규 가입자용 무료 테스트 크레딧을 받아 보세요. OpenAI 호환 인터페이스를 제공하기 때문에 코드 한 벌로 OpenAI, Claude, Gemini 등 여러 모델을 호출할 수 있어요. “강한 모델은 계획, 빠른 모델은 실행, 이기종 모델은 검토”라는 조합이 내 프로젝트에 맞는지 편하게 확인해 볼 수 있답니다.

자주 묻는 질문 FAQ

Google Antigravity /swarm 핵심 요약 Key Takeaways

• 실행 방식: /swarm <task>를 입력하면 현재 대화가 Coordinator가 되어 작업을 쪼개고, 독립적인 Worker를 만들어요
• 대표적인 역할 분담: Coordinator, Worker, Verifier, Monitor로 나뉘며, 보통 Worker 2~4개당 Verifier 하나를 둬요
• 협업 방식: 추가 전용(append-only) 공유 메시지 보드에서 공개적으로 소통하고, 대기 중인 Agent는 토큰을 소모하지 않아요
• 작업 공간 규칙: 기본적으로 작업 공간을 공유하고, 병렬로 수정할 때는 필요에 따라 독립된 작업 복사본을 할당해요
• 시각적 제어: Board, Members, Graph 세 가지 뷰와 /swarm board, /agents 같은 CLI 명령을 함께 쓸 수 있어요
• 현실적인 한계: 아직 Preview 단계라서 Worker를 여러 개 돌리면 할당량이 빠르게 줄어들고, Swarm 권한이 곧 Carbon 권한은 아니에요
• 직접 구현해 보기: APIYI(apiyi.com)의 통합 인터페이스로 여러 모델을 조합하면 나만의 멀티 역할 프로토타입을 만들 수 있어요

정리

Google Antigravity /swarm의 핵심은 다음과 같아요.

1. 병렬 처리에서 협업으로: /swarm의 가치는 병렬 실행 자체보다, 작업 분할 → 독립 컨텍스트 → 적대적 검증 → 진행 상황 모니터링으로 이어지는 하나의 완전한 순환 구조에 있어요.
2. 필요할 때만 격리: 공유 작업 공간과 독립 작업 복사본을 작업 성격에 맞게 전환해서 쓰고, 사용자는 결과를 언제 병합할지 신경 써야 해요.
3. 능력과 비용이 함께 올라가요: 멀티 Agent는 복잡한 엔지니어링 작업을 처리하는 능력을 높여 주지만, 그만큼 할당량 소모가 커지고 리소스 관리도 복잡해져요. 지금은 아직 Preview 단계예요.

개발자 입장에서 /swarm은 일하는 방식이 바뀌고 있다는 신호예요. 모델에게 질문만 던지는 게 아니라, 역할을 나누고 실행하고 검증하고 결과물을 내놓는 AI 팀을 꾸리는 셈이죠. 당장 Antigravity를 쓰지 않더라도 “역할별로 모델을 배정하고, 검증은 실행과 분리한다”는 발상은 직접 만드는 Agent 시스템에도 그대로 적용할 수 있어요. 여러 모델 조합의 효과를 빠르게 확인해 보고 싶다면 APIYI(apiyi.com)를 추천해요. 무료 테스트 할당량과 여러 모델을 한 번에 쓸 수 있는 통합 인터페이스를 제공해요.

📚 참고 자료

1. Google Antigravity Swarm 공식 문서: /swarm 실행 메커니즘, 역할 구성, 작업 사본과 CLI 조작
2. 링크: antigravity.google/docs/swarm

3. 설명: Coordinator, Verifier, Monitor의 세부 동작과 Board / Members / Graph 뷰에 관한 1차 자료

4. Google Antigravity 공식 블로그: Gemini 4 Carbon in Google Antigravity

5. 링크: antigravity.google/blog/gemini-4-carbon-in-google-antigravity

6. 설명: /swarm 출시 정보, 멀티 에이전트 아키텍처, 모델 역할 배분 가이드

7. Google 공식 발표: Gemini 4 Carbon is now available

8. 링크: blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-carbon-now-available

9. 설명: Carbon 정식 공개 범위와 /swarm 프리뷰 출시 배경

10. Google AI 구독 혜택 페이지: AI Pro와 Ultra의 모델 권한

11. 링크: one.google.com/about/google-ai-plans

12. 설명: 구독 등급별 Carbon 모델 접근 권한 구분

13. The Verge 출시 보도: Google releases Gemini 4 Carbon with agent swarm feature

14. 링크: theverge.com/ai-artificial-intelligence/1030787/google-gemini-4-carbon-public-rollout
15. 설명: 독립 매체 시각에서 본 출시 배경과 접근 제한

작성자: APIYI 기술팀
기술 교류: 멀티 에이전트 실무 이야기를 나누고 싶다면 APIYI apiyi.com 홈페이지에서 연락 주세요. 더 많은 연동 자료는 docs.apiyi.com 문서 센터에서 확인할 수 있어요.

관련 글

• Gemini 4 Carbon 출시 분석: 59점으로 Opus 5.5 역전, 17개 항목 중 15개에서 이겼지만 호출은 불가: Gemini 4 Carbon은 Artificial Analysis 종합 지능 지수에서 59점으로 1위를 차지하고 공식 비교 17개 항목 중 15개에서 승리했지만 API 모델 ID와 공개 일정은 없으며, 이 글에서는 점수 산정 기준과 현재 호출할 수 없는 이유, 중국 개발자가 우선 gemini-4-argon을 사용할 수 있는 방법을 설명합니다.