Msty Go · 글 22편Msty Go
  1. Msty Go 시작하기 — 설치부터 첫 실행 검증까지
  2. Msty Go 에이전트 만들기와 관리
  3. Msty Go Working Styles — 다섯 가지 작업 방식 고르기
  4. Msty Go 모델 제공업체 설정과 Model Assignments
  5. Msty Go Managed Services — 로컬 AI와 부가 서비스를 앱이 대신 준비하기
  6. Msty Go 보안 설정 — 발신자, 폴더, 네트워크, 승인
  7. Msty Go Airlock — 에이전트가 접속할 웹사이트 정하기
  8. Msty Go 도구 설정 — MCP 서버, 웹 검색, Skills Hub, Computer Use
  9. Msty Go Context Scout — 보내기 전에 관련 파일 찾아 붙이기
  10. Msty Go Extensions — 확장 기능 찾기, 설치, 만들기, 공유
  11. Msty Go Mission Control — 도우미 에이전트와 승인을 한곳에서 보기
  12. Msty Go Pulse — 일을 시작하기 전에 받는 브리핑
  13. Msty Go Side Chat — 주 대화를 건드리지 않고 짧게 묻기
  14. Msty Go Memory Bank — Working Brief와 Memory Pack으로 맥락 이어 가기
  15. Msty Go 작업 공간 프로필 파일 — SOUL.md, IDENTITY.md, USER.md
  16. Msty Go Playbooks — 잘된 실행을 반복 가능한 절차로 만들기
  17. Msty Go Tasks — 프롬프트, 알림, 감시, Playbook 예약하기
  18. Msty Go Shortcuts — 자주 쓰는 지시를 슬래시 명령으로 만들기
  19. Msty Go Rules — 이벤트에 따라 안내하고, 막고, 점검하기
  20. Msty Go 채널 — Discord, Telegram, WhatsApp, 모바일로 에이전트와 주고받기
  21. Msty Go Cloud Sync — 기기 간 암호화 동기화와 휴대전화 연결
  22. Msty Go General Settings — 앱 전체 기본값 정하기

이 글에서 다루는 것에이전트의 웹 접근을 호스트 단위로 허용·차단하는 Airlock의 쓰임새, 사전 조건, 설정 흐름, 정책 설계와 검증 점검표를 설명합니다.

Airlock이란

Airlock은 Go에서 웹사이트 접근을 다루는 정책 층입니다. 에이전트가 접속해도 되는 호스트와 항상 막아야 하는 호스트를 정해 둡니다.

에이전트에게 인터넷이 필요하지만, 어디까지 접속하는지를 분명하고 나중에 점검할 수 있게 해 두고 싶을 때 씁니다. 프롬프트에 “이 사이트만 봐”라고 적는 것은 부탁일 뿐이고, Airlock은 정책으로 강제한다는 점이 다릅니다.

예를 들어(필자가 든 예입니다) 법령 조사 에이전트를 만들면서 국가법령정보센터와 소속 기관 누리집만 허용 목록에 넣고 나머지는 막아 두는 식입니다.

언제 쓰는가

  • 에이전트가 웹에서 조사하거나 자료를 가져올 때
  • 나가는 접근을 승인된 도메인으로 제한해야 할 때
  • 그때그때 프롬프트로 지시하는 것보다 강한 통제가 팀에 필요할 때

Airlock은 다른 통제를 대신하지 않습니다. 발신자 정책, 폴더 경계, 승인과 함께 쓰는 보완 수단입니다.

사전 조건

조건 설명
Docker 또는 Podman 설치되어 있고 정상 동작해야 합니다
OrbStack (macOS) Docker 호환 OrbStack 런타임을 쓰는 경우
컨테이너 실행 방식 정책으로 강제되는 웹 접근이 필요하면 에이전트의 실행 방식을 Container로 설정합니다
네트워크 접근 작업에 필요할 때만 에이전트의 네트워크를 켭니다

컨테이너 런타임이 없다면 Managed Services의 런타임 설정을 먼저 마칩니다. Managed Services 문서는 Airlock을 한 번에 설정할 수 있는 1-click 서비스 가운데 하나로 들고 있습니다.

Host 방식으로 실행하는 에이전트에 Airlock이 어떻게 적용되는지는 공식 문서에 설명이 없습니다. 문서는 정책으로 강제되는 웹 접근에 컨테이너 실행이 필요하다고만 적습니다.

기본 설정 흐름

  1. Go에서 Airlock 설정을 열고, 대상 작업 흐름에 기능을 켭니다.
  2. 허용 호스트와 차단 호스트를 명시한 첫 정책 묶음을 만듭니다.
  3. 웹 접근이 필요한 에이전트나 작업 흐름에 정책을 적용합니다.
  4. 허용된 사이트 하나와 차단된 사이트 하나를 대상으로 통제된 검증 작업을 실행합니다.
  5. 동작을 확인하고, 넓게 쓰기 전에 정책을 더 좁힙니다.

좁은 정책으로 시작하고 필요가 증명될 때만 넓힙니다.

Airlock 설정 화면의 정확한 메뉴 경로와 버튼 이름은 이 문서 페이지에 적혀 있지 않습니다. General Settings 문서의 설정 검색을 쓰면 관련 영역을 찾기 쉽습니다.

정책을 설계하는 기준

  • 운영용 자동화에는 명시적인 허용 목록을 우선합니다.
  • 위험이 큰 범주는 기본적으로 막아 둡니다. 문서의 예는 인증 정보, 개인 정보, 출처를 알 수 없는 파일 호스트입니다.
  • 규칙을 작업 목적별로 묶어 담당자와 검토 범위를 분명히 합니다.
  • 문서로 남긴 예외가 아니라면 넓은 와일드카드를 피합니다.

문서의 기준 한 줄이 실용적입니다. 좋은 정책은 만든 사람이 아닌 다른 사람이 읽어도 이해할 수 있어야 합니다.

검증 점검표

확인 항목 기대하는 결과
허용 도메인 의도한 에이전트가 접속할 수 있다
차단 도메인 일관되게 거부된다
작업 결과 정책 제약 아래에서도 쓸 만하다
승인 기록과 활동 기록 정책이 어떻게 작용했는지 분명히 보인다

정책을 좁힌 뒤 결과 품질이 떨어지면 접근을 최소한으로 넓히고 다시 시험합니다.

운영과 유지

  • 정책 변경은 평소의 변경 관리 절차로 검토합니다.
  • 작업 흐름이나 통합 기능이 크게 바뀌면 규칙을 다시 검증합니다.
  • 오래된 예외를 정기적으로 지웁니다.
  • 정책 갱신과 사고 대응의 담당자를 정합니다.

여러 사람이 함께 쓰는 환경이라면 Airlock 정책 검토를 정기 보안 점검에 넣습니다.

다른 통제와 나누는 역할

무엇을 정하려는가 쓰는 곳
발신자, 폴더, 네트워크 전반의 방침 보안 설정
MCP와 검색 기능 관리 도구 설정
실행 방식과 권한 범위 에이전트

보안 설정의 Network Guard가 프리셋과 호스트 목록으로 나가는 네트워크 전반을 제한한다면, Airlock은 웹사이트 단위의 허용·차단을 맡습니다. 도구 문서는 둘을 에이전트 권한과 함께 겹쳐 쓰라고 안내합니다. 두 설정이 서로 어긋날 때 어느 쪽이 우선하는지는 공식 문서에 설명이 없습니다.

문제가 생겼을 때

증상 먼저 볼 것
Airlock을 켤 수 없다 Docker 또는 Podman이 설치되어 정상 동작하는지. macOS에서 OrbStack을 쓴다면 Docker가 OrbStack 컨텍스트를 쓰는지
허용한 사이트에 접속이 안 된다 에이전트의 네트워크가 켜져 있는지, 실행 방식이 Container인지
결과 품질이 떨어졌다 꼭 필요한 도메인이 허용 목록에서 빠지지 않았는지

이 표는 문서의 사전 조건과 검증 항목을 바탕으로 정리한 것입니다. 문서에 별도의 문제 해결 절은 없습니다.

참고한 문서