본문으로 건너뛰기
테마
폰트
크기
A A

Harness Engineering

하네스 엔지니어링(Harness Engineering)은 Antigravity AI 에이전트를 감싸는 외부 실행 프레임워크를 설계하고 운영하는 기술입니다. 에이전트 자체가 "무엇을 할지" 결정한다면, 하네스는 에이전트가 "어떤 환경에서, 어느 범위까지, 어떤 방식으로" 동작할지를 규정합니다. 보안 정책, 도구 접근 제어, 자동화 훅, 컨텍스트 주입까지 에이전트 주변의 모든 인프라가 하네스에 해당합니다.

에이전트 모드/설정 공식 문서 MCP 공식 문서 Rules & Workflows

하네스(Harness)란? #

핵심 개념
하네스(Harness)는 AI 에이전트를 안전하고 예측 가능하게 작동시키기 위한 외부 실행 환경 전체를 말합니다. 에이전트가 자동차 엔진이라면, 하네스는 엔진 제어 장치(ECU), 안전벨트, 속도 제한 장치를 모두 합친 것입니다.

Antigravity에서 하네스 엔지니어링은 다음 질문들에 답합니다.

  • 에이전트가 파일 시스템의 어느 경로를 읽고 쓸 수 있는가?
  • 터미널 명령 실행을 사용자 승인 없이 허용할 것인가, 아니면 매번 검토를 요구할 것인가?
  • 어떤 외부 URL에 브라우저로 접근할 수 있는가?
  • 에이전트 턴(turn)이 시작/종료될 때 자동으로 실행되어야 할 작업이 있는가?
  • 모든 대화에 공통으로 주입해야 할 컨텍스트(규칙, 지식)가 있는가?
  • 어떤 MCP 서버를 에이전트에게 노출할 것인가?
에이전트 vs 하네스
에이전트와 하네스의 역할 비교
구분담당예시
에이전트 (Agent)무엇을 할지 결정 (추론, 코드 생성)"이 버그를 수정하겠습니다"
하네스 (Harness)어떤 환경에서 작동할지 규정"src/ 만 쓸 수 있고, git push는 검토 필요"

하네스를 제대로 설계하면 에이전트에게 더 많은 자율성을 안전하게 줄 수 있습니다. 제약이 명확할수록 에이전트가 범위를 초과한 위험한 행동을 할 가능성이 낮아지기 때문입니다.

5분 만에 첫 하네스 만들기

하네스를 처음 접한다면 아래 최소 설정부터 시작하세요. 복잡한 설정 없이도 에이전트가 안전하게 동작합니다.

~/.gemini/settings.json (최소 하네스 예시) { "coreTools": { "fileSystem": { "writeAllowList": ["./src/**", "./output/**"], "readAllowList": ["./**"] }, "shell": { "allowList": ["python3", "pip3", "git"], "alwaysRequireApproval": true } } }
이 최소 설정이 하는 일: (1) 전체 프로젝트 읽기 허용 (2) src/output/에만 쓰기 허용 (3) 셸 명령은 허용 목록 내에서만 실행, 항상 사용자 승인 요구. 이 세 줄이 있으면 원본 데이터를 실수로 덮어쓰거나 위험한 명령이 무단 실행되는 사고를 방지할 수 있습니다.
하네스 설정 후 복잡도 경고: 하네스 설정이 너무 복잡해지면 에이전트가 모든 단계에서 승인 요청을 반복하여 생산성이 크게 떨어집니다. 초기에는 최소한의 제약을 설정하고, 실제로 문제가 발생하는 경우에만 제약을 추가하는 방식을 권장합니다. "일단 다 막고 필요한 것만 열자"는 접근보다 "기본은 열고 위험한 것만 막자"가 일반적으로 더 효율적입니다.
💬 프롬프트 예시 — 하네스 초기 설계 요청
  • 이 프로젝트의 하네스를 처음부터 설정해줘. src/ 폴더만 읽고 쓸 수 있게, 터미널 명령은 항상 내 승인을 받도록, GitHub MCP도 연결해줘.
  • 현재 .gemini/settings.json을 분석해서 하네스 설정 상태를 요약해줘. 어떤 경로에 접근 가능하고, 어떤 보안 정책이 적용되어 있는지 표로 정리해줘.
  • 내 프로젝트는 Python 데이터 분석 팀이야. 이 팀에 맞는 하네스 초안을 만들어줘. 원본 데이터는 건드리지 않고, 처리 결과만 저장 가능하게.

💡 하네스 설정을 처음 시작할 때는 프로젝트 성격(팀 규모, 언어, 민감도)을 함께 알려줄수록 더 정확한 초안이 나옵니다.

하네스 아키텍처 #

Antigravity의 하네스는 4개의 레이어로 구성됩니다. 각 레이어는 독립적으로 구성할 수 있으며, 아래에서 위로 순차적으로 적용됩니다.

Antigravity 하네스 아키텍처 (4 레이어) 레이어 4 · 도구 접근 (Tool Access Layer) MCP 서버 · 브라우저 서브에이전트 · 터미널 · 파일 시스템 접근 권한 🔧 레이어 3 · 컨텍스트 (Context / Knowledge Layer) GEMINI.md 전역 규칙 · 워크스페이스 규칙 · Knowledge Items · MCP 도구 주입 📚 레이어 2 · 보안 (Security Layer) 허용 목록 · 차단 목록 · 브라우저 URL 허용 목록 · 샌드박스 모드 · 위협 방어 🛡️ 레이어 1 · 설정 (Configuration Layer) settings.json · 4가지 정책 축 · 프리셋 구성 모드 · 훅(Hooks) 정의 ⚙️
레이어 적용 순서: 레이어 1(설정)이 기반이 되고, 그 위에 레이어 2(보안), 레이어 3(컨텍스트), 레이어 4(도구)가 쌓입니다. 설정 레이어의 정책이 나머지 레이어의 동작 방식을 결정합니다.
💬 프롬프트 예시 — 아키텍처 설계 질문
  • 우리 팀 하네스의 4개 레이어를 각각 어떻게 구성해야 할지 추천해줘. 스타트업 웹 서비스 팀이고, 개발 속도가 중요해.
  • 현재 하네스 설정에서 어떤 레이어가 가장 취약한지 분석해줘. 각 레이어별 위험도를 평가해서 표로 보여줘.
  • 보안 레이어와 도구 접근 레이어의 설정이 충돌하는 부분이 있으면 찾아서 정리해줘.

💡 레이어 간 상호작용을 먼저 이해하면 설정 충돌을 예방할 수 있습니다. 설계 단계에서 충분히 질문하세요.

레이어 1 · 설정 레이어 (Configuration Layer) #

설정 레이어는 하네스의 토대입니다. settings.json 파일(Agent Manager → Settings)에서 관리하며, 에이전트의 전반적인 동작 방식을 결정하는 4가지 정책 축(Policy Axis)을 포함합니다.

settings.json 위치 및 구조

settings.json (기본 구조)
{
  "agentSettings": {
    "coreTools": {
      "terminalTool": {
        "terminalExecutionMode": "REQUEST_REVIEW"
      },
      "readFileTool": {
        "allowedPaths": ["./src", "./tests", "./docs"]
      },
      "writeFileTool": {
        "allowedPaths": ["./src", "./tests"]
      },
      "browserTool": {
        "allowedDomains": ["docs.python.org", "github.com", "stackoverflow.com"]
      }
    },
    "mcpServers": {
      "github": {
        "httpUrl": "https://api.githubcopilot.com/mcp/",
        "headers": { "Authorization": "Bearer ${GITHUB_TOKEN}" }
      }
    },
    "hooks": {
      "postTurn": [
        { "command": "git add -A && git status" }
      ]
    }
  }
}

4가지 정책 축 (Policy Axis)

Antigravity 하네스 4가지 정책 축
정책 축 설정 키 옵션 설명
터미널 실행 terminalExecutionMode REQUEST_REVIEW / ALWAYS_PROCEED 명령 실행 전 사용자 승인 요구 여부
파일 읽기 readFileTool.allowedPaths 경로 배열 에이전트가 읽을 수 있는 경로 목록
파일 쓰기 writeFileTool.allowedPaths 경로 배열 에이전트가 수정/생성할 수 있는 경로 목록
브라우저 도메인 browserTool.allowedDomains 도메인 배열 브라우저 서브에이전트가 접근 가능한 도메인
REQUEST_REVIEW vs ALWAYS_PROCEED
REQUEST_REVIEW (긍정적 보안 모델)

에이전트가 터미널 명령을 실행하기 전에 사용자에게 승인을 요청합니다. 기본값이며 보안팀, 신규 프로젝트에 권장합니다. "허용된 것만 실행한다"는 긍정적 보안 모델입니다.

ALWAYS_PROCEED (부정적 보안 모델)

에이전트가 사용자 승인 없이 모든 터미널 명령을 실행합니다. 숙련된 사용자, 자동화 파이프라인에 적합합니다. 단, 차단 목록(denylist)을 반드시 구성해야 합니다.

💬 프롬프트 예시 — 설정 레이어 구성
  • .gemini/settings.json 파일을 만들어줘. 터미널은 REQUEST_REVIEW 모드, 읽기는 src/와 tests/와 docs/ 폴더, 쓰기는 src/와 tests/만 허용.
  • 지금 settings.json의 terminalExecutionMode를 ALWAYS_PROCEED로 바꾸고, 대신 차단 목록에 rm -rf와 git push --force를 추가해줘.
  • 현재 settings.json을 검토해서 보안 관점에서 개선할 점을 찾아줘. 특히 파일 쓰기 경로가 너무 넓게 설정된 부분이 있으면 지적해줘.
  • settings.json에 postTurn 훅을 추가해줘. 매번 black .으로 코드 포맷팅하고, pytest를 돌린 결과 마지막 10줄만 보여주도록.

💡 settings.json 수정 후 에이전트에게 "변경 사항을 요약하고 잠재적 위험이 있으면 알려줘"라고 추가 요청하면 실수를 방지할 수 있습니다.

레이어 2 · 보안 레이어 (Security Layer) #

보안 레이어는 에이전트가 수행할 수 있는 작업의 경계를 정의합니다. Antigravity는 두 가지 상호 보완적인 목록 기반 접근 방식을 제공합니다.

허용 목록 (Allowlist)

개념
허용 목록은 "이것만 허용"하는 방식입니다. 목록에 없는 모든 도구 호출은 자동으로 차단됩니다. 가장 강력한 보안 모델입니다.

허용 목록 설정 절차:

  1. Agent Manager를 열고 상단의 Settings 탭으로 이동합니다.
  2. Tool call allowlist 섹션에서 허용할 도구 호출을 추가합니다 (예: read_file, run_terminal_command, browser_navigate).
  3. 각 항목에 대해 선택적으로 경로 패턴이나 명령 패턴을 지정할 수 있습니다.
  4. 설정을 저장한 후 Antigravity를 재시작합니다. 허용 목록 변경은 재시작 전까지 적용되지 않습니다.
허용 목록 테스트: 설정 후 에이전트에게 목록에 없는 도구를 사용하도록 요청해보세요. 에이전트가 "이 도구는 현재 허용 목록에 없어서 실행할 수 없습니다"라고 응답하면 정상 작동입니다.

차단 목록 (Denylist)

개념
차단 목록은 "이것만 금지"하는 방식입니다. 목록에 없는 모든 도구 호출은 기본적으로 허용됩니다. 유연성이 높지만 보안은 상대적으로 낮습니다.

차단 목록 설정 절차:

  1. Agent Manager → SettingsTool call denylist 섹션으로 이동합니다.
  2. 차단할 도구 호출을 추가합니다 (예: delete_file, git push --force, rm -rf).
  3. 정규식 패턴을 사용하여 위험한 명령 패턴을 세밀하게 제어할 수 있습니다.
  4. 저장 후 Antigravity를 재시작합니다. 차단 목록도 재시작 없이는 적용되지 않습니다.
⚠️ 부정적 보안 모델의 위험성: 차단 목록만 사용하는 것은 "생각나지 않은 위험한 명령"은 모두 허용된다는 의미입니다. ALWAYS_PROCEED 모드와 함께 사용할 때는 반드시 충분한 차단 규칙을 구성하세요. 프로덕션 환경에서는 허용 목록(Allowlist) 방식을 권장합니다.

브라우저 URL 허용 목록

브라우저 서브에이전트의 접근 도메인을 제한합니다. settings.jsonbrowserTool.allowedDomains 배열에 허용할 도메인을 지정합니다.

브라우저 URL 허용 목록 예시
"browserTool": {
  "allowedDomains": [
    "docs.python.org",
    "developer.mozilla.org",
    "github.com",
    "stackoverflow.com",
    "pypi.org"
  ]
}
와일드카드 지원: "*.github.com"처럼 서브도메인 와일드카드를 사용할 수 있습니다. 단, 최상위 와일드카드("*")는 모든 도메인을 허용하므로 사용하지 마세요.

샌드박스 모드 (Sandbox Mode)

샌드박스 모드는 에이전트의 파일 시스템 접근을 현재 워크스페이스 디렉토리 내부로만 제한합니다. 외부 디렉토리(~/.ssh, /etc 등)에 대한 접근이 차단됩니다.

샌드박스 모드 활성화
"agentSettings": {
  "sandboxMode": true,
  "workspaceRoot": "./my-project"
}

4가지 주요 보안 위협

Antigravity 에이전트 4가지 주요 보안 위협
위협 유형 설명 방어 전략
프롬프트 인젝션 악성 콘텐츠(웹 페이지, 문서)가 에이전트에게 원치 않는 명령을 실행하도록 유도 브라우저 URL 허용 목록, 신뢰할 수 없는 소스의 콘텐츠 처리 시 주의
파일 시스템 남용 에이전트가 의도치 않게 중요 설정 파일이나 자격증명 파일을 수정/노출 샌드박스 모드, 파일 쓰기 허용 경로 제한
명령 인젝션 에이전트가 생성한 터미널 명령에 악성 코드가 포함되는 경우 REQUEST_REVIEW 모드, 차단 목록으로 위험 명령 패턴 차단
자격증명 노출 API 키, 비밀번호 등이 에이전트 출력이나 로그에 포함되는 경우 환경 변수 사용, .env 파일을 읽기 허용 목록에서 제외
💬 프롬프트 예시 — 보안 레이어 구성
  • 허용 목록을 설정해줘. read_file, write_file, run_terminal_command, browser_navigate 네 가지만 허용하고, 그 외 모든 도구 호출은 차단.
  • 차단 목록에 위험한 명령 패턴을 추가해줘: rm -rf, git push --force, DROP TABLE, curl | bash, chmod 777 패턴 포함.
  • 브라우저 허용 도메인을 설정해줘. Python 공식 문서, PyPI, GitHub, Stack Overflow만 접근 가능하게. 소셜 미디어와 외부 파일 다운로드 사이트는 모두 차단.
  • 샌드박스 모드를 활성화하고 workspaceRoot를 ./my-project로 지정해줘. 홈 디렉토리나 /etc 같은 시스템 경로에 절대 접근하지 못하도록.
  • .env 파일과 ~/.ssh 경로를 읽기 금지 목록(deniedPaths)에 추가해줘. API 키 노출 사고를 방지하고 싶어.

💡 허용 목록과 차단 목록을 동시에 사용할 때는 허용 목록이 우선 적용됩니다. 설정 후 반드시 Antigravity를 재시작하세요.

도구별 Glob 패턴 권한 설정 (요약)

도구 이름만이 아니라 도구 + 인자/경로 패턴까지 묶어 한 줄로 권한을 정의할 수 있습니다. 형식은 도구이름(패턴)이며, permissions.allow / permissions.deny 두 배열로 구분합니다.

settings.json — permissions 블록 최소 예시
{
  "permissions": {
    "allow": [
      "Read(**/*.md)",
      "Edit(**/*.py)",
      "Write(**/*.json)",
      "Bash(git diff:*)"
    ],
    "deny": [
      "Read(**/.env)",
      "Edit(**/secrets/**)"
    ]
  }
}
  • Read(**/*.md) — 모든 마크다운 파일 읽기 허용
  • Edit(**/*.py) — Python 파일 수정 허용 (생성은 별도 권한)
  • Bash(git diff:*)git diff로 시작하는 모든 명령 허용
  • deny 항목은 allow보다 우선**/.env는 어떤 패턴으로도 읽히지 않음
이 정도만 알아도 70%는 커버됩니다. Glob 패턴 문법(**, *, 콜론 구분 인자), 도구별 패턴 형식(Read/Edit/Write/Bash/WebFetch), 우선순위 규칙, 실전 권장 프리셋 등 자세한 내용은 Permissions (권한 설정) 페이지에서 다룹니다.

훅(Hooks) & 자동화 #

📘 실전 활용은 별도 페이지에서: 이 섹션은 훅을 4-레이어 하네스 구조의 한 부분으로 다루는 아키텍처 맥락에 집중합니다. Antigravity는 별도 hooks 기능을 제공하지 않으므로 같은 효과를 얻는 실전 패턴(Rules·Workflows 기반 자동화, 활용 패턴 모음, 프롬프트로 자동화 파일 만들기, 트러블슈팅)은 Hooks (훅) — Antigravity 자동화 패턴 가이드에서 다룹니다.

훅(Hooks)은 에이전트 턴(turn)의 시작 전 또는 종료 후에 자동으로 실행되는 셸 명령이나 스크립트입니다. 반복적인 검증 작업을 자동화하거나 에이전트 출력에 대한 일관된 후처리를 적용할 때 사용합니다. 특히 데이터 분석 프로젝트는 데이터셋 상태 점검, 스키마 검증, 시각화 산출물 관리가 매 턴 반복되므로, 훅을 통한 자동 컨텍스트 주입과 검증 위임이 큰 효과를 발휘합니다.

훅의 2가지 유형
preTurn Hook (턴 시작 전)

에이전트가 응답을 생성하기 전에 실행됩니다. 컨텍스트 준비, 환경 검증, 최신 정보 수집 등에 활용합니다.

  • 현재 git 상태 조회 후 컨텍스트에 주입
  • 테스트 통과 여부 확인
  • 의존성 최신화 확인
postTurn Hook (턴 종료 후)

에이전트가 응답을 완료한 후에 실행됩니다. 린트, 포맷팅, 테스트 실행, 자동 커밋 등에 활용합니다.

  • 코드 자동 포맷팅 (black ., prettier --write)
  • 린트 검사 실행
  • 변경 사항 자동 git 스테이징

훅 설정 예시

settings.json — 훅 설정 예시 (Python 프로젝트)
{
  "agentSettings": {
    "hooks": {
      "preTurn": [
        {
          "command": "echo '=== Current Git Status ===' && git status --short",
          "description": "대화 시작 시 현재 git 상태를 에이전트에게 제공"
        }
      ],
      "postTurn": [
        {
          "command": "black . --check --quiet || black .",
          "description": "Python 코드 자동 포맷팅 (black)"
        },
        {
          "command": "flake8 src/ --max-line-length=88 --statistics",
          "description": "린트 검사 실행"
        },
        {
          "command": "git add -A && git status",
          "description": "변경 사항 스테이징 및 상태 확인"
        }
      ]
    }
  }
}
settings.json — 훅 설정 예시 (Node.js 프로젝트)
{
  "agentSettings": {
    "hooks": {
      "preTurn": [
        {
          "command": "node --version && npm --version",
          "description": "환경 버전 확인"
        }
      ],
      "postTurn": [
        {
          "command": "npx prettier --write \"src/**/*.{js,ts,jsx,tsx}\"",
          "description": "Prettier 코드 포맷팅"
        },
        {
          "command": "npm run lint 2>&1 | tail -5",
          "description": "ESLint 검사 (마지막 5줄만 출력)"
        },
        {
          "command": "npm test -- --passWithNoTests 2>&1 | tail -10",
          "description": "테스트 실행"
        }
      ]
    }
  }
}
훅 실행 실패 처리: 훅 명령이 실패(exit code ≠ 0)해도 에이전트 대화는 중단되지 않습니다. 에이전트는 훅의 stdout/stderr 출력을 컨텍스트로 받아 참고합니다. 따라서 훅 실패 메시지를 잘 작성해두면 에이전트가 자동으로 문제를 수정하도록 유도할 수 있습니다.

데이터 분석 프로젝트 훅 예시 (pandas / seaborn / pandera / ydata-profiling / koreanize-matplotlib)

데이터 분석 워크플로우는 매 턴마다 데이터셋 상태 확인 → 분석 코드 작성 → 시각화 → 검증이 반복됩니다. 아래 예시는 분석가가 자주 쓰는 스택을 훅으로 자동화한 구성입니다. preTurn은 데이터 메타와 직전 산출물을 컨텍스트에 주입하고, postTurn은 코드 포맷·스키마 검증·plot 아카이빙·프로파일 보고서를 한 번에 처리합니다.

settings.json — 훅 설정 예시 (데이터 분석 프로젝트)
{
  "agentSettings": {
    "hooks": {
      "preTurn": [
        {
          "command": "[ -f data/train.csv ] && python -c \"import pandas as pd; df = pd.read_csv('data/train.csv'); print(f'shape={df.shape} cols={list(df.columns)} mem={df.memory_usage(deep=True).sum()/1e6:.1f}MB null_rate={df.isnull().mean().mean():.2%}')\" || echo '⚠ data/train.csv 없음 — 경로를 프로젝트에 맞게 수정하세요'",
          "description": "현재 데이터셋의 shape·컬럼·메모리·결측치 비율을 컨텍스트에 주입 (파일 부재 시 안내 메시지만 출력)"
        },
        {
          "command": "ls -lt artifacts/ 2>/dev/null | head -5",
          "description": "최근 생성된 분석 산출물 5개를 컨텍스트에 노출"
        },
        {
          "command": "python -c \"import koreanize_matplotlib\" 2>/dev/null || true",
          "description": "한글 폰트 자동 설정(koreanize-matplotlib) — plot의 한글 깨짐 방지 (스타일은 분석 코드에서 자유롭게 지정)"
        }
      ],
      "postTurn": [
        {
          "command": "black notebooks/ src/ --quiet 2>&1 || true",
          "description": "분석 코드 자동 포맷팅 (black)"
        },
        {
          "command": "[ -f tests/test_data_schema.py ] && pytest tests/test_data_schema.py -x -q 2>&1 | tail -10 || echo '⚠ tests/test_data_schema.py 없음 — Pandera 스키마 작성 후 등록하세요'",
          "description": "Pandera 스키마 기반 데이터 무결성 테스트 실행 (테스트 파일 부재 시 안내)"
        },
        {
          "command": "mkdir -p artifacts/$(date +%F) && find . -maxdepth 2 -name '*.png' -newer .last_run -exec mv {} artifacts/$(date +%F)/ \\; 2>/dev/null && touch .last_run",
          "description": "이번 턴에 생성된 plot을 일자별 아카이브 디렉토리로 이동"
        },
        {
          "command": "[ -f data/train.csv ] && [ $(wc -l < data/train.csv) -lt 10000 ] && python -m ydata_profiling data/train.csv -o artifacts/profile.html --silent 2>&1 | tail -3 || true",
          "description": "행 10000 미만일 때만 ydata-profiling 보고서 생성 (파일 부재·대용량은 자동 스킵)"
        }
      ]
    }
  }
}
⚠️ 프로젝트 구조 가정 — 경로 커스터마이징 필요: 위 예시는 data/train.csv, tests/test_data_schema.py 같은 특정 프로젝트 구조를 가정한 템플릿입니다. 자신의 데이터 경로·테스트 위치에 맞게 settings.json을 반드시 수정하세요. 다행히 모든 명령은 [ -f 경로 ] 가드로 감싸져 있어 파일이 없어도 에러 없이 안내 메시지만 출력합니다 — 적용 직후 매 턴 에러로 작업이 막히는 상황은 발생하지 않습니다.
예: 자신의 프로젝트 경로로 치환
# 데이터가 datasets/raw_2024.csv 인 경우
"command": "[ -f datasets/raw_2024.csv ] && python -c \"...\""

# 테스트가 src/tests/schema_test.py 인 경우
"command": "[ -f src/tests/schema_test.py ] && pytest src/tests/schema_test.py ..."

대안 패턴: 헬퍼 스크립트로 범용화

여러 데이터 분석 프로젝트에 같은 훅 설정을 재사용하고 싶다면, 데이터 경로를 settings.json에 직접 쓰지 않고 CSV 파일을 자동 탐지하는 헬퍼 스크립트를 두는 것이 효율적입니다. settings.json은 짧아지고, 데이터 경로가 바뀌어도 settings.json을 건드릴 필요가 없습니다.

scripts/dataset_meta.py — CSV 자동 탐지 헬퍼
"""data/ 또는 프로젝트 루트의 CSV 파일을 자동 탐지해 메타정보를 출력."""
import sys, glob
import pandas as pd

candidates = sorted(glob.glob('data/*.csv') + glob.glob('*.csv'))[:3]
if not candidates:
    print('데이터 파일 없음 — data/ 폴더에 CSV를 두거나 경로를 수정하세요')
    sys.exit(0)

for path in candidates:
    try:
        df = pd.read_csv(path, nrows=10000)  # 큰 파일 가드
        null_rate = df.isnull().mean().mean()
        mem = df.memory_usage(deep=True).sum() / 1e6
        print(f'{path}: shape={df.shape} cols={list(df.columns)[:8]} mem={mem:.1f}MB null_rate={null_rate:.2%}')
    except Exception as e:
        print(f'{path}: 읽기 실패 ({type(e).__name__})')
settings.json — 헬퍼 스크립트 사용 (간소화 버전)
{
  "agentSettings": {
    "hooks": {
      "preTurn": [
        {
          "command": "python scripts/dataset_meta.py 2>/dev/null || true",
          "description": "프로젝트 내 CSV 파일을 자동 탐지해 메타정보를 컨텍스트에 주입"
        }
      ]
    }
  }
}
두 패턴 비교:
  • 패턴 A (단순 가드) — settings.json 한 파일만 수정. 빠르게 적용 가능. 데이터 경로가 자주 바뀌면 매번 settings.json을 수정해야 함.
  • 패턴 B (헬퍼 스크립트)scripts/dataset_meta.py 추가 필요. settings.json은 짧고 안정적. 한 번 작성해두면 어떤 데이터 분석 프로젝트에도 그대로 복사 가능.

시작은 패턴 A로 빠르게, 같은 훅을 2개 이상 프로젝트에서 재사용하게 되면 패턴 B로 리팩토링하는 흐름을 권장합니다.

⚠️ 한글 폰트 설정 — 사전 설치 필수: 위 settings.json의 preTurn 훅에서 사용하는 koreanize_matplotlib은 별도 설치가 필요합니다. 미설치 상태에서 plot에 한글이 포함되면 네모(□) 또는 빈 글자로 깨져서 출력됩니다.
한글 폰트 라이브러리 설치 (1회)
# pip 사용
pip install koreanize-matplotlib

# uv 사용 (권장)
uv add koreanize-matplotlib

# 설치 확인
python -c "import koreanize_matplotlib; print('OK')"

동작 원리: import koreanize_matplotlib 한 줄로 OS별(Windows·macOS·Linux) 사용 가능한 한글 폰트를 자동 탐지하여 matplotlib rcParams에 등록합니다. 이후 모든 matplotlib·seaborn plot이 한글을 정상 렌더링합니다.

중요: import 순서가 반드시 koreanize_matplotlibseaborn/matplotlib 순이어야 합니다. 반대로 하면 일부 환경에서 폰트 적용이 안 될 수 있습니다.

preTurn 데이터 메타 주입의 효과: 매 대화마다 별도 명령 없이 에이전트가 현재 데이터셋의 크기·컬럼·결측치 패턴을 자동 인지합니다. 사용자는 "결측치 처리 방안 제안" 한 줄만 입력해도 에이전트가 데이터 특성에 맞춘 답변을 제공합니다. 또한 postTurn의 pandera 스키마 검증은 분석 코드가 데이터 컬럼·dtype·범위 가정을 깨뜨리는 변경을 즉시 감지합니다.

실용적인 훅 패턴

실용적인 훅 패턴 목록
패턴 훅 유형 명령 예시 효과
코드 품질 자동화 postTurn black . && isort . 에이전트 코드 생성 후 항상 일관된 포맷 유지
테스트 자동 실행 postTurn pytest tests/ -x -q 에이전트 수정 후 즉시 테스트 피드백 제공
Git 상태 주입 preTurn git log --oneline -5 최근 커밋 히스토리를 에이전트 컨텍스트에 포함
빌드 검증 postTurn npm run build 2>&1 | tail -20 코드 변경 후 빌드 가능 여부 즉시 확인
보안 스캔 postTurn bandit -r src/ -ll -q 생성된 Python 코드의 보안 취약점 자동 스캔
문서 자동 생성 postTurn pdoc src/ -o docs/ 코드 변경 시 API 문서 자동 업데이트
DataFrame 메타 주입 데이터 분석 preTurn python -c "import pandas as pd; print(pd.read_csv('data/train.csv').info())" 매 대화 시작 시 데이터셋 구조·dtype·메모리를 자동 컨텍스트화
Pandera 스키마 검증 데이터 분석 postTurn pytest tests/test_data_schema.py -x -q 분석 코드 변경 후 데이터 컬럼·dtype·범위 위반을 즉시 감지
ydata-profiling 자동 보고서 데이터 분석 postTurn python -m ydata_profiling data.csv -o artifacts/profile.html EDA 결과물(분포·상관·결측 패턴)을 HTML로 자동 생성
한글 폰트 설정 데이터 분석 preTurn python -c "import koreanize_matplotlib" plot의 한글 깨짐 방지 (pip install koreanize-matplotlib 사전 설치 필요). 스타일은 분석 코드에서 자유롭게 지정
Plot 일자별 아카이빙 데이터 분석 postTurn mkdir -p artifacts/$(date +%F) && mv *.png artifacts/$(date +%F)/ 이번 턴에 생성된 시각화 산출물을 날짜별로 자동 정리
분석 진행 로그 자동 기록 데이터 분석 postTurn echo "$(date +%F\ %H:%M) - Turn complete" >> analysis_log.md 분석 진행 이력을 마크다운 로그로 자동 기록 (재현 가능성 확보)

데이터 분석 훅을 활용한 프롬프트 구성 방법

훅이 자동으로 컨텍스트를 주입하거나 결과를 검증해주므로, 프롬프트에서 그만큼의 지시를 생략할 수 있습니다. 아래 3가지 패턴을 익히면 짧고 정확한 프롬프트로 깊이 있는 분석을 끌어낼 수 있습니다.

패턴 1 · 컨텍스트 주입형 (preTurn 활용)

훅이 데이터셋 메타를 자동 주입하므로, 프롬프트에서 "데이터를 먼저 살펴봐"라고 지시할 필요가 없습니다. 분석 목표 한 줄로 충분합니다.

  • 변경 전: "data/train.csv를 읽어서 구조를 파악하고 결측치 패턴을 분석한 뒤, 처리 방안을 제안해줘."
  • 변경 후: "결측치 처리 방안 제안" — preTurn 훅이 이미 shape·결측치 비율을 컨텍스트에 주입했으므로 에이전트가 데이터 특성에 맞춘 답변 제공
패턴 2 · 검증 위임형 (postTurn 활용)

postTurn 훅이 자동 검증하므로, 프롬프트는 "코드 작성"에만 집중합니다. 검증 실패 시 에이전트는 다음 턴에서 자동으로 수정 시도를 합니다.

  • 변경 전: "이상치 제거 함수를 작성하고, 단위 테스트를 만들고, pandera 스키마와 일치하는지 확인해줘."
  • 변경 후: "IQR 기준 이상치 제거 함수 작성" — postTurn pytest가 자동 검증, 실패 시 다음 턴에서 에이전트가 수정 시도
패턴 3 · 반복 분석형 (preTurn 산출물 노출)

preTurn 훅이 직전 산출물을 컨텍스트에 노출하므로, "이전 결과를 기반으로 ~~"라는 명시적 참조 없이도 에이전트가 직전 분석을 인지합니다.

  • 변경 전: "어제 만든 회귀 모델 결과 artifacts/2026-04-30/regression_summary.txt를 다시 보고, 잔차 분석을 추가로 해줘."
  • 변경 후: "잔차 분석 추가" — preTurn 훅이 artifacts/ 최신 파일 5개를 자동 노출하므로 직전 컨텍스트를 자동 인지
프롬프트 구성 원칙: 훅이 자동화한 부분은 프롬프트에서 빼고, "무엇을 분석할지" + "어떤 형식으로 출력할지"만 남깁니다. 예: "X의 시계열 분해 후 잔차의 정상성을 ADF 테스트로 검정. 결과는 표 형식." — 데이터 로딩·검증·plot 저장은 모두 훅이 처리.
💬 프롬프트 예시 — 훅 설정 및 자동화
  • Python 프로젝트용 postTurn 훅을 settings.json에 추가해줘. black으로 포맷팅, flake8로 린트, pytest로 테스트 순서대로 실행. 각 결과는 마지막 5줄만 출력.
  • 대화를 시작할 때마다 현재 git 브랜치, 최근 5개 커밋 로그, 수정된 파일 목록을 자동으로 보여주는 preTurn 훅을 만들어줘.
  • postTurn 훅에서 테스트가 실패하면 에이전트가 자동으로 실패 원인을 분석하고 수정 시도를 할 수 있도록 훅 출력 메시지를 개선해줘.
  • Node.js 프로젝트에 맞게 훅을 업데이트해줘. prettier로 포맷팅, eslint로 린트, jest로 테스트. 실행 시간이 30초를 넘으면 타임아웃 처리.
  • 현재 postTurn 훅이 너무 느려. 각 명령의 실행 시간을 측정하고 가장 느린 것부터 최적화 방법을 제안해줘.
  • 시나리오 — 엑셀이나 CSV를 분석할 때마다 "데이터 몇 행이야?", "컬럼 이름 뭐야?", "빈 값은 얼마나 있지?"를 매번 직접 확인하기 번거롭다.
    프롬프트 — "data 폴더의 CSV 파일을 자주 분석해. 대화를 시작할 때마다 행 개수·컬럼 이름·빈 값 비율을 자동으로 알려주는 훅을 settings.json에 추가해줘. 파일이 없으면 에러 대신 안내 메시지가 나오게."
  • 시나리오 — 데이터 전체를 한눈에 볼 수 있는 요약 리포트가 매번 필요한데, 데이터가 크면 보고서 만드는 데 시간이 너무 오래 걸려서 작업이 느려진다.
    프롬프트 — "분석이 끝날 때마다 데이터 분포·상관·결측치를 보여주는 자동 HTML 리포트를 만들어줘. 라이브러리는 ydata-profiling을 사용하고, 데이터가 1만 행 이상이면 시간이 너무 걸리니 건너뛰게 해줘."
  • 시나리오 — 협업하다 보면 누가 컬럼 이름을 바꾸거나 타입이 변해서 분석 코드가 갑자기 깨지는 일이 잦다. 변경을 매번 수동으로 알아채기 어렵다.
    프롬프트 — "내 데이터의 컬럼이 age, salary, department인지, age는 0~100 사이의 정수인지 매번 자동으로 검사하게 해줘. Pandera 라이브러리로 스키마를 정의하고, 분석 코드를 수정할 때마다 이 검사가 자동으로 돌아가도록 settings.json도 같이 설정해줘."
  • 시나리오 — 그래프에 한글이 □ 로 깨져 보이고, 색이나 배경이 매번 달라서 분석 보고서 일관성이 없다.
    프롬프트 — "그래프에 한글이 깨지지 않게 자동 설정해줘. koreanize-matplotlib 라이브러리를 쓰면 된다고 들었어. 그래프 스타일은 분석할 때 코드에서 직접 지정할 거니까 훅에서는 강제하지 마. 설치 명령은 README에도 추가해줘."
  • 시나리오 — 머신러닝 모델을 만든 뒤 결과(그래프·점수)를 팀에 공유할 때마다 폴더 만들고, 파일 정리하고, 결과를 정리한 글을 쓰는 게 매번 번거롭다.
    프롬프트 — "회귀 모델을 만들 때마다 결과 그래프(예측 vs 실제, 잔차 분포 등)를 artifacts/오늘날짜/ 폴더에 자동 저장해줘. 그리고 그 결과를 팀 PR에 붙이기 좋게 마크다운 표 형식으로 정리해주는 명령도 함께 만들어줘."

💡 훅 명령이 실패해도 에이전트 대화는 멈추지 않습니다. 실패 출력을 명확하게 작성하면 에이전트가 다음 턴에서 자동으로 문제를 감지합니다. 데이터 분석에서는 훅이 처리하는 부분을 프롬프트에서 빼는 것이 핵심 — 짧을수록 정확해집니다.

레이어 3 · 컨텍스트 레이어 (Context Layer) #

컨텍스트 레이어는 에이전트가 모든 대화에서 자동으로 참고하는 지식과 규칙을 정의합니다. 한 번 설정하면 매 대화마다 동일한 컨텍스트가 에이전트에게 제공됩니다.

GEMINI.md — 전역 규칙

GEMINI.md는 에이전트의 전역 행동 지침을 정의하는 마크다운 파일입니다. 모든 대화와 모든 워크스페이스에 적용됩니다.

~/.gemini/GEMINI.md (전역 규칙 예시)
# 전역 에이전트 규칙

## 코딩 스타일
- 모든 주석은 한국어로 작성한다
- Python: PEP 8 준수, 타입 힌트 필수
- 함수 길이는 50줄 이하로 유지
- 변수명은 snake_case, 클래스명은 PascalCase

## 응답 방식
- 코드 변경 전에 변경 계획을 먼저 설명한다
- 파일을 수정하면 수정 요약을 마지막에 제공한다
- 불확실한 경우 가정 사항을 명시한다

## 보안
- API 키와 비밀번호는 코드에 하드코딩하지 않는다
- .env 파일을 절대 커밋하지 않는다
- SQL 쿼리는 파라미터화된 방식으로 작성한다

워크스페이스별 규칙

프로젝트 루트의 GEMINI.md는 해당 워크스페이스에서만 적용되는 프로젝트별 규칙을 정의합니다. 전역 규칙 위에 추가로 적용됩니다.

./GEMINI.md (워크스페이스별 규칙 예시)
# 프로젝트별 규칙 - my-data-project

## 프로젝트 구조
- 데이터: data/raw/, data/processed/
- 분석 코드: src/analysis/
- 시각화: src/visualization/
- 테스트: tests/

## 데이터 처리 규칙
- DataFrame 변수명은 df_ 접두사 사용
- 원본 데이터(data/raw/)는 절대 수정하지 않는다
- 모든 분석 결과는 data/processed/에 저장한다
- pandas 대신 polars를 우선 사용한다

## 의존성
- Python 3.11+
- 주요 패키지: polars, matplotlib, seaborn, pytest
- 패키지 추가 시 requirements.txt 업데이트 필수

Knowledge Items (지식 항목)

Knowledge Items는 에이전트가 특정 주제에 대해 항상 참고할 수 있도록 등록해두는 구조화된 지식 단위입니다. 기술적으로는 아티팩트(Artifact)와 별개지만 동일하게 취급됩니다.

Knowledge Items 유형별 활용 예시
Knowledge 유형 내용 활용 예시
API 명세 내부 API 엔드포인트, 파라미터, 응답 형식 에이전트가 올바른 API 호출 코드 자동 생성
데이터 스키마 DB 테이블 구조, 컬럼 설명, 타입 정보 정확한 SQL 쿼리 작성, ORM 모델 생성
아키텍처 문서 서비스 구조도, 컴포넌트 간 관계 새 기능 추가 시 일관된 아키텍처 유지
팀 컨벤션 코드 리뷰 체크리스트, PR 템플릿 일관된 PR 설명 자동 생성
에러 카탈로그 알려진 에러와 해결 방법 동일 에러 재발 시 즉시 해결
Knowledge Items 등록 방법: Agent Manager 좌측 패널의 Knowledge 탭에서 추가합니다. 마크다운, 텍스트, 코드 스니펫 형태로 등록하면 에이전트가 관련 대화에서 자동으로 참고합니다.
GEMINI.md 컨텍스트 크기 가이드: GEMINI.md에 너무 많은 내용을 넣으면 매 대화에서 컨텍스트 토큰을 낭비하고, 에이전트가 중요한 규칙을 놓칠 수 있습니다.
  • 권장 크기: 전역 GEMINI.md는 200~500줄 (약 4,000~8,000자) 이내가 이상적입니다. 초과하면 에이전트가 모든 규칙을 실제로 따르지 않기 시작합니다.
  • 우선순위화: 가장 중요한 규칙을 파일 상단에 배치하세요. 에이전트는 긴 파일에서 초반 내용을 더 잘 따릅니다.
  • 크기 확인: wc -l ~/.gemini/GEMINI.md로 줄 수를 확인하고, 500줄을 초과하면 Rules 파일로 분리를 검토하세요.
  • 유효성 테스트: 주기적으로 "현재 적용된 GEMINI.md 규칙을 모두 나열해줘"라고 에이전트에게 요청해서 규칙이 제대로 인식되고 있는지 확인하세요.
💬 프롬프트 예시 — 컨텍스트 레이어 구성
  • 전역 GEMINI.md 파일을 만들어줘. 모든 주석은 한국어, Python 타입 힌트 필수, 코드 수정 전에 항상 변경 계획을 먼저 설명하도록 지시 포함.
  • 이 데이터 분석 프로젝트의 워크스페이스 GEMINI.md를 작성해줘. data/raw/는 절대 수정 금지, 분석 결과는 data/processed/에만 저장, DataFrame 변수명은 df_ 접두사 사용.
  • 우리 팀 PostgreSQL 스키마를 Knowledge Item으로 정리해줘. users, orders, products 테이블의 컬럼 이름, 타입, 관계를 명확하게 문서화.
  • 내부 REST API 명세를 Knowledge Item으로 등록할 수 있도록 정리해줘. 각 엔드포인트, HTTP 메서드, 필수 파라미터, 응답 형식을 포함.
  • 전역 GEMINI.md와 프로젝트별 GEMINI.md가 충돌하는 규칙이 있으면 찾아서 정리해줘. 어느 쪽이 우선 적용되는지도 설명해줘.

💡 GEMINI.md는 길수록 좋지 않습니다. 에이전트가 모든 규칙을 실제로 따르는지 주기적으로 테스트하고, 무시되는 규칙은 제거하거나 재작성하세요.

레이어 4 · 도구 접근 레이어 (Tool Access Layer) #

도구 접근 레이어는 에이전트가 사용할 수 있는 외부 도구와 서비스를 정의합니다. MCP(Model Context Protocol) 서버, 브라우저 서브에이전트, 터미널, 파일 시스템 도구가 여기에 포함됩니다.

MCP 서버 구성

MCP 서버는 에이전트에게 외부 서비스 접근 능력을 부여합니다. settings.jsonmcpServers 블록에 등록합니다.

settings.json — MCP 서버 구성 예시
{
  "agentSettings": {
    "mcpServers": {
      "github": {
        "httpUrl": "https://api.githubcopilot.com/mcp/",
        "headers": {
          "Authorization": "Bearer ${GITHUB_TOKEN}"
        }
      },
      "filesystem": {
        "command": "npx",
        "args": ["-y", "@modelcontextprotocol/server-filesystem", "./src"]
      },
      "postgres": {
        "command": "npx",
        "args": ["-y", "@modelcontextprotocol/server-postgres"],
        "env": {
          "POSTGRES_URL": "${DATABASE_URL}"
        }
      },
      "custom-internal-api": {
        "httpUrl": "https://internal.mycompany.com/mcp",
        "headers": {
          "X-API-Key": "${INTERNAL_API_KEY}"
        }
      }
    }
  }
}
MCP 서버 연결 방식 비교
연결 방식 설정 키 적합한 경우
HTTP (원격) httpUrl + headers GitHub, Jira 등 클라우드 서비스
로컬 프로세스 command + args 파일 시스템, 로컬 DB 등
환경 변수 env 자격증명을 코드와 분리할 때

브라우저 서브에이전트 (Browser Sub-agent)

브라우저 서브에이전트는 에이전트가 실제 브라우저를 제어하여 웹 탐색, 정보 수집, 자동화된 웹 작업을 수행할 수 있게 합니다. Cmd+I(에디터와 터미널 모두에서)로 빠르게 접근할 수 있습니다.

브라우저 서브에이전트 보안: 브라우저 서브에이전트는 인증된 세션(쿠키, 저장된 비밀번호)에 접근할 수 있습니다. browserTool.allowedDomains를 반드시 설정하여 에이전트가 접근 가능한 도메인을 제한하세요.

파일 시스템 도구

파일 읽기/쓰기 도구의 허용 경로를 세밀하게 제어할 수 있습니다. 경로 패턴은 glob 형식을 지원합니다.

파일 시스템 도구 경로 제어 예시
"coreTools": {
  "readFileTool": {
    "allowedPaths": [
      "./src/**",
      "./tests/**",
      "./docs/**",
      "./README.md"
    ],
    "deniedPaths": [
      "./.env",
      "./.env.*",
      "./secrets/**"
    ]
  },
  "writeFileTool": {
    "allowedPaths": [
      "./src/**",
      "./tests/**"
    ]
  }
}
💬 프롬프트 예시 — 도구 접근 레이어 구성
  • settings.json에 GitHub MCP 서버를 추가해줘. 토큰은 환경 변수 GITHUB_TOKEN으로 처리하고, httpUrl은 공식 엔드포인트로 설정.
  • 로컬 PostgreSQL 데이터베이스에 연결하는 MCP 서버를 설정해줘. 접속 URL은 환경 변수 DATABASE_URL로 처리.
  • 파일 읽기 경로를 세밀하게 제어해줘. src/**와 tests/**는 읽기 가능, .env와 .env.* 파일 및 secrets/ 폴더는 완전 차단, 쓰기는 src/**만 허용.
  • 브라우저 서브에이전트를 사용해서 docs.python.org에서 asyncio.gather() 공식 문서를 읽어와줘.
  • 현재 mcpServers 설정에서 사용하지 않는 서버나 잘못된 URL이 있으면 찾아서 정리해줘. 각 서버가 실제로 연결 가능한지도 확인해줘.

💡 MCP 서버 추가 후 "GitHub에서 내 레포 목록 가져와줘"처럼 실제 작업을 요청해서 연결이 잘 되는지 바로 확인하세요.

워크스페이스 격리 (Workspace Isolation) #

Antigravity는 여러 프로젝트를 독립적인 워크스페이스로 관리할 수 있습니다. 각 워크스페이스는 고유한 설정, 규칙, Knowledge Items, MCP 서버 구성을 가집니다.

워크스페이스 디렉토리 구조

워크스페이스 디렉토리 구조
~/projects/
├── web-app/                    # 워크스페이스 1
│   ├── GEMINI.md               # 이 프로젝트 전용 규칙
│   ├── .gemini/
│   │   └── settings.json       # 프로젝트별 하네스 설정
│   └── src/
├── data-pipeline/              # 워크스페이스 2
│   ├── GEMINI.md               # 다른 규칙 세트
│   ├── .gemini/
│   │   └── settings.json       # 다른 MCP, 다른 보안 정책
│   └── src/
└── ml-research/                # 워크스페이스 3
    ├── GEMINI.md
    ├── .gemini/
    │   └── settings.json
    └── notebooks/

멀티 워크스페이스 하네스 설계 원칙

멀티 워크스페이스 하네스 설계 원칙
원칙 설명 구현 방법
최소 권한 각 워크스페이스는 필요한 최소한의 도구와 경로만 접근 프로젝트별 allowedPaths, mcpServers 명시
격리된 컨텍스트 워크스페이스 간 Knowledge Items, 규칙이 교차 오염되지 않음 각 프로젝트 루트에 별도 GEMINI.md 작성
공통 기반 재사용 전역 규칙은 ~/.gemini/GEMINI.md에 한 번만 정의 전역 파일에 팀 공통 규칙, 워크스페이스 파일에 프로젝트 규칙
환경 분리 개발/스테이징/프로덕션 설정을 별도 워크스페이스로 관리 환경별 settings.json과 다른 MCP 서버 구성 사용
💬 프롬프트 예시 — 워크스페이스 격리 설정
  • web-app, data-pipeline, ml-research 세 프로젝트의 독립된 .gemini/settings.json과 GEMINI.md를 각각 생성해줘. 서로 다른 언어(TS, Python, Python+Jupyter)를 사용해.
  • data-pipeline 워크스페이스에는 data/raw/ 쓰기를 완전히 차단하고, ml-research에는 notebooks/ 폴더만 쓰기 가능하게 설정해줘.
  • 개발 환경과 스테이징 환경의 MCP 서버 설정이 다르게 되도록 두 개의 settings.json 파일을 만들어줘. 개발은 로컬 DB, 스테이징은 원격 DB 연결.
  • 각 워크스페이스의 GEMINI.md가 전역 규칙을 올바르게 상속하는지 확인하고, 프로젝트별로 추가해야 할 규칙을 제안해줘.

💡 "워크스페이스 이름 + 주요 기술 스택 + 보안 요구 수준"을 함께 알려주면 각 프로젝트에 맞는 설정을 한 번에 생성할 수 있습니다.

팀 하네스 표준화 #

팀 전체가 동일한 하네스 구성을 사용하면 에이전트 동작의 일관성이 보장되고, 개인이 임의로 보안 정책을 완화하는 것을 방지할 수 있습니다.

Git으로 하네스 구성 공유

하네스 설정 파일을 Git 저장소에 포함시켜 팀 전체가 동일한 구성을 사용하도록 합니다.

팀 하네스 Git 구조
my-project/
├── .gemini/
│   └── settings.json           # Git에 커밋 (민감 정보 제외)
├── GEMINI.md                   # 프로젝트 규칙 (Git에 커밋)
├── .gemini.env.example         # 환경 변수 템플릿 (Git에 커밋)
├── .gemini.env                 # 실제 환경 변수 (Git 제외 — .gitignore)
└── .gitignore
.gemini/settings.json (팀 공유 설정 — 민감 정보 환경 변수 처리)
{
  "agentSettings": {
    "coreTools": {
      "terminalTool": {
        "terminalExecutionMode": "REQUEST_REVIEW"
      },
      "readFileTool": {
        "allowedPaths": ["./src", "./tests", "./docs"],
        "deniedPaths": ["./.env", "./.env.*"]
      },
      "writeFileTool": {
        "allowedPaths": ["./src", "./tests"]
      }
    },
    "mcpServers": {
      "github": {
        "httpUrl": "https://api.githubcopilot.com/mcp/",
        "headers": {
          "Authorization": "Bearer ${GITHUB_TOKEN}"
        }
      }
    },
    "hooks": {
      "postTurn": [
        { "command": "npm run lint --silent 2>&1 | tail -5" },
        { "command": "npm test -- --passWithNoTests 2>&1 | tail -5" }
      ]
    }
  }
}
환경 변수 처리: ${GITHUB_TOKEN}처럼 환경 변수 참조를 사용하면 토큰이 settings.json에 평문으로 저장되지 않습니다. 팀원 각자는 .gemini.env 파일에 자신의 토큰을 설정합니다.

팀 하네스 온보딩 절차

  1. 저장소 클론: git clone <repo-url>.gemini/settings.jsonGEMINI.md가 자동으로 포함됨
  2. 환경 변수 설정: .gemini.env.example을 복사하여 .gemini.env 생성 후 개인 토큰 입력
  3. Antigravity 재시작: 새 설정이 적용되도록 재시작
  4. 하네스 검증: 아래 "디버깅 & 검증" 체크리스트 실행

팀 온보딩 체크리스트

신규 팀원이 Antigravity 하네스 환경을 처음 설정할 때 사용하는 체크리스트입니다.

팀 온보딩 체크리스트
단계작업확인 방법
1 저장소 클론 및 최신 main 브랜치 Pull git status로 작업 디렉토리 확인
2 .gemini.env.example.gemini.env로 복사 후 개인 토큰 채우기 cat .gemini.env로 값이 올바른지 확인
3 .gemini.env.gitignore에 포함되어 있는지 확인 git status에서 .gemini.env가 "untracked"로 표시되지 않아야 함
4 Antigravity 실행 및 settings.json 로드 확인 에이전트에게 "현재 terminalExecutionMode가 뭐야?"라고 물어보기
5 MCP 서버 연결 확인 에이전트에게 "연결된 MCP 서버 목록을 보여줘"라고 요청
6 훅 동작 확인 코드 한 줄 수정 후 에이전트 응답에 훅 출력이 포함되는지 확인
7 Rules/Skills/Workflows 인식 확인 "사용 가능한 규칙, 스킬, 워크플로우 목록을 알려줘"라고 요청
주의: .gemini.env는 반드시 .gitignore에 추가해야 합니다. 개인 API 토큰이 원격 저장소에 노출되면 심각한 보안 사고로 이어집니다.
💬 프롬프트 예시 — 팀 하네스 표준화
  • 팀 전체가 공유할 표준 .gemini/settings.json 파일을 만들어줘. 민감 정보는 모두 환경 변수 참조(${}), 터미널은 REQUEST_REVIEW, GitHub MCP 포함.
  • .gemini.env.example 파일을 만들어줘. 팀원이 어떤 환경 변수를 설정해야 하는지 주석으로 설명하고, 실제 값 대신 플레이스홀더로 채워.
  • .gitignore에 .gemini.env를 추가하고, 혹시 이미 커밋된 .env 파일이 있으면 git history에서 제거하는 방법도 알려줘.
  • 신규 팀원이 하네스 환경을 5분 안에 구성할 수 있도록 README에 온보딩 섹션을 작성해줘. git clone 이후 해야 할 단계를 번호 순으로.
  • 현재 settings.json에서 개인 토큰이나 민감 정보가 하드코딩된 부분을 찾아서 환경 변수로 변환해줘.

💡 팀 하네스는 "의심스러우면 더 제한적으로"가 기본 원칙입니다. 개발 속도가 필요하면 개인 로컬 설정에서 완화하되, 공유 설정은 항상 보수적으로 유지하세요.

하네스 디버깅 & 검증 #

하네스를 새로 구성하거나 변경한 후에는 반드시 각 레이어가 의도대로 작동하는지 검증해야 합니다. 다음 체크리스트를 활용하세요.

하네스 검증 체크리스트

하네스 검증 체크리스트
레이어 검증 항목 테스트 방법 기대 결과
설정 settings.json 문법 cat .gemini/settings.json | python3 -m json.tool JSON 파싱 오류 없음
보안 허용 목록 동작 목록에 없는 도구 실행 요청 "허용 목록에 없어서 실행 불가" 응답
보안 차단 목록 동작 차단된 명령 실행 요청 에이전트가 실행 거부
보안 파일 경로 제한 허용되지 않은 경로 파일 읽기 요청 접근 거부 메시지
postTurn 훅 실행 간단한 코드 수정 후 에이전트 응답 확인 훅 명령 출력이 응답에 포함
컨텍스트 GEMINI.md 규칙 적용 규칙 위반 요청 (예: 영어 주석) 에이전트가 규칙대로 한국어 주석 사용
도구 MCP 서버 연결 "GitHub에서 내 레포 목록 가져와줘" GitHub MCP를 통한 정상 응답

일반적인 하네스 오류 해결

하네스 오류 유형과 해결 방법
오류 증상 원인 해결 방법
허용 목록 변경이 반영 안 됨 Antigravity 재시작 누락 설정 변경 후 반드시 재시작
MCP 서버 연결 실패 환경 변수 미설정 또는 URL 오류 echo $GITHUB_TOKEN으로 토큰 확인, URL 검토
훅이 실행되지 않음 JSON 문법 오류, 명령 경로 문제 JSON 문법 검증, 명령을 터미널에서 직접 실행하여 테스트
GEMINI.md 규칙 무시됨 파일 위치 오류 또는 인코딩 문제 프로젝트 루트에 파일 존재 확인, UTF-8 인코딩 확인
샌드박스 모드에서 파일 접근 불가 workspaceRoot 경로 오류 절대 경로 대신 상대 경로(./) 사용
💬 프롬프트 예시 — 하네스 디버깅 & 검증
  • 현재 하네스 설정 전체를 검토하고 보안 취약점이나 설정 오류를 찾아서 레이어별로 보고해줘.
  • 허용 목록이 제대로 작동하는지 테스트해줘. 차단되어야 할 도구 호출을 시도해보고 결과를 알려줘.
  • postTurn 훅이 실행되지 않는 것 같아. settings.json 문법을 검증하고, 각 훅 명령을 터미널에서 직접 실행해서 오류를 찾아줘.
  • GEMINI.md 규칙이 무시되는 것 같아. "모든 변수명을 영어로"라고 규칙을 정했는데 에이전트가 한국어 변수명을 씀. 원인을 진단해줘.
  • MCP 서버 연결 상태를 확인해줘. 각 서버에 간단한 요청을 보내서 응답이 오는지, 오류가 있으면 원인을 알려줘.
  • .gemini/settings.json을 JSON 문법 검증해줘. 파싱 오류가 있으면 정확한 위치와 수정 방법을 알려줘.

💡 "테스트해줘"라는 말만으로도 에이전트가 단계별 검증을 진행합니다. 어떤 레이어를 확인할지 구체적으로 지정하면 더 빠르게 문제를 찾을 수 있습니다.

프리셋 구성 모드 (Preset Modes) #

Antigravity는 4가지 사전 정의된 하네스 구성 프리셋을 제공합니다. 프리셋은 일반적인 사용 시나리오를 위한 권장 설정 조합입니다.

Antigravity 4가지 프리셋 구성 모드
프리셋 터미널 모드 파일 접근 적합한 상황
보안 모드
(Security Mode)
REQUEST_REVIEW 허용 목록만 민감한 프로젝트, 프로덕션 코드베이스, 보안 감사 필요 환경
검토 기반 개발
(Review-Based Dev)
REQUEST_REVIEW 워크스페이스 내 전체 팀 협업, 코드 리뷰 중심 개발, 주니어 개발자 포함 팀
에이전트 주도 개발
(Agent-Led Dev)
ALWAYS_PROCEED 워크스페이스 내 전체 빠른 프로토타이핑, 숙련된 개발자, 격리된 개발 환경
커스텀 구성
(Custom Configuration)
사용자 정의 사용자 정의 특수 요구사항, 세밀한 제어가 필요한 경우

프리셋별 권장 훅 구성

보안 모드 / 검토 기반 개발 — 권장 훅
"hooks": {
  "postTurn": [
    { "command": "git diff --stat" },
    { "command": "git status --short" }
  ]
}

변경 사항을 항상 사용자가 확인할 수 있게 하는 최소한의 훅. 자동 커밋 없음.

에이전트 주도 개발 — 권장 훅
"hooks": {
  "postTurn": [
    { "command": "npm run lint --silent" },
    { "command": "npm test -- --passWithNoTests" },
    { "command": "git add -A && git status" }
  ]
}

린트, 테스트, 스테이징까지 자동화. 에이전트 턴이 끝날 때마다 즉시 피드백.

💬 프롬프트 예시 — 프리셋 선택 & 적용
  • 보안 모드 프리셋으로 settings.json을 초기화해줘. 허용 목록만 사용하고, 터미널은 REQUEST_REVIEW, 읽기/쓰기 경로는 src/와 tests/만.
  • 에이전트 주도 개발 프리셋을 적용해줘. ALWAYS_PROCEED 모드지만 rm -rf, git push --force, DROP TABLE은 반드시 차단 목록에 추가해줘.
  • 현재 settings.json이 4가지 프리셋 중 어느 것에 가장 가깝고, 어디서 벗어났는지 분석해줘.
  • 검토 기반 개발 프리셋에서 시작해서, 우리 팀에 맞게 커스터마이징해줘. 데이터 분석 팀이라 notebooks/ 폴더 접근이 추가로 필요해.
  • 현재 프리셋에 맞는 최적의 훅 구성을 추천하고 settings.json에 바로 적용해줘.

💡 프리셋은 시작점입니다. "보안 모드에서 시작하고, 불편한 점이 생기면 하나씩 완화하는" 방식이 가장 안전합니다.

실전 하네스 구성 예시 #

예시 1: 데이터 분석 팀 하네스

.gemini/settings.json — 데이터 분석 팀
{
  "agentSettings": {
    "coreTools": {
      "terminalTool": {
        "terminalExecutionMode": "REQUEST_REVIEW"
      },
      "readFileTool": {
        "allowedPaths": ["./data", "./src", "./notebooks", "./docs"],
        "deniedPaths": ["./data/raw", "./.env"]
      },
      "writeFileTool": {
        "allowedPaths": ["./data/processed", "./src", "./notebooks"]
      },
      "browserTool": {
        "allowedDomains": [
          "docs.python.org", "pandas.pydata.org",
          "scikit-learn.org", "matplotlib.org",
          "kaggle.com", "huggingface.co"
        ]
      }
    },
    "hooks": {
      "preTurn": [
        { "command": "python --version && pip list | grep -E 'pandas|numpy|sklearn'" }
      ],
      "postTurn": [
        { "command": "black src/ --check --quiet || black src/" },
        { "command": "pytest tests/ -q --tb=short 2>&1 | tail -10" }
      ]
    }
  }
}

예시 2: 웹 서비스 개발 팀 하네스

.gemini/settings.json — 웹 서비스 개발 팀
{
  "agentSettings": {
    "coreTools": {
      "terminalTool": {
        "terminalExecutionMode": "ALWAYS_PROCEED"
      },
      "readFileTool": {
        "allowedPaths": ["./src", "./tests", "./public", "./package.json"],
        "deniedPaths": ["./.env", "./.env.*", "./node_modules/.cache"]
      },
      "writeFileTool": {
        "allowedPaths": ["./src", "./tests", "./public"]
      },
      "browserTool": {
        "allowedDomains": [
          "developer.mozilla.org", "react.dev",
          "nextjs.org", "tailwindcss.com",
          "vercel.com", "github.com"
        ]
      }
    },
    "mcpServers": {
      "github": {
        "httpUrl": "https://api.githubcopilot.com/mcp/",
        "headers": { "Authorization": "Bearer ${GITHUB_TOKEN}" }
      }
    },
    "hooks": {
      "postTurn": [
        { "command": "npx prettier --write 'src/**/*.{ts,tsx,js,jsx}' --log-level warn" },
        { "command": "npx eslint src/ --max-warnings 0 2>&1 | tail -5" },
        { "command": "npm test -- --passWithNoTests --silent 2>&1 | tail -5" }
      ]
    }
  }
}
하네스 설계 원칙 요약:
  1. 처음에는 보안 모드로 시작하고, 필요에 따라 완화한다.
  2. 파일 쓰기 경로는 읽기 경로보다 더 엄격하게 제한한다.
  3. 환경 변수로 모든 자격증명을 처리한다.
  4. 훅은 빠르게 실행되도록 구성한다 (30초 미만 권장).
  5. 설정 파일은 Git으로 버전 관리하여 팀 전체가 동일한 하네스를 사용한다.
💬 프롬프트 예시 — 실전 하네스 구축 (처음부터 끝까지)
  • 데이터 분석 팀 하네스를 처음부터 구축해줘. Python + polars + pytest 환경이야. data/raw/는 읽기만, data/processed/는 쓰기 가능, 브라우저는 Python/pandas 문서만. postTurn 훅은 black + pytest.
  • TypeScript 웹 서비스 팀용 하네스 전체를 설정해줘. ALWAYS_PROCEED 모드, ESLint + Prettier + Jest 훅, GitHub MCP 연결, src/**만 쓰기 가능. .env 파일은 완전 차단.
  • 현재 하네스 설정을 기반으로 "운영 환경 배포 전 체크리스트"를 만들어줘. 보안, 훅 동작, MCP 연결, GEMINI.md 규칙 적용 여부를 모두 포함.
  • 이 하네스 설정으로 실제 작업을 해보자. auth.py 파일을 만들어줘. JWT 토큰 검증 함수 포함. 훅이 자동으로 실행되는지 확인하고 싶어.
  • 지난 한 달간 이 프로젝트에서 에이전트가 어떤 작업을 했는지 요약해줘. 훅 실패 빈도, 자주 수정된 파일, 보안 경고가 발생한 사례를 분석해줘.

💡 하네스를 구축한 후 실제 작업을 요청하면서 "이 작업이 하네스 정책에 맞게 수행됐는지 확인해줘"라고 추가하면 실전 검증이 됩니다.

오늘코드 Antigravity 튜토리얼 — Google Antigravity 공식 문서 기반 한국어 학습 가이드

이 튜토리얼은 비공식 학습 자료입니다. 공식 문서: antigravity.google/docs

오늘코드