Warp 오픈소스 이후 로컬 LLM 지원 전 팀이 정할 프라이버시 체크리스트 2026

Warp는 2026년 4월 28일 클라이언트 코드를 공개했고, 공개 저장소는 AGPL v3와 일부 MIT 라이선스를 함께 사용한다. 이 사실 하나만으로 팀 도입 판단이 끝나지는 않는다. 오픈소스는 코드를 볼 수 있게 해준다. 하지만 코드가 보인다고 해서 모든 데이터 흐름이 로컬로 바뀌는 것은 아니다. 여기서 팀이 헷갈리기 시작한다. “오픈소스 됐으니 이제 우리 회사에서도 써도 되나?” “로컬 LLM 붙이면 프라이버시 문제는 사라지나?” “BYOK면 우리 키를 쓰니까 안전한가?” 질문이 다 맞는 방향인데, 순서가 살짝 아쉽다. 도구가 답하기 전에 팀 정책이 먼저 답해야 한다. 터미널은 원래 조용한 도구였다. 명령어 치고, 로그 보고, 파일 열고, 빌드 돌리는 그런 자리였다. 이제 AI 터미널은 조금 다르다. 파일을 읽을 수 있다. 명령을 실행할 수 있다. 프롬프트와 터미널 출력과 코드 조각을 모델 provider로 보낼 수 있다. 팀 워크플로와 공유 지식까지 품을 수 있다. 그러니까 이 글의 초점은 “Warp가 좋냐 나쁘냐”가 아니다. 초점은 더 현실적이다. 로컬 LLM 지원을 기다리는 동안 팀이 먼저 정해야 할 운영선이다. 정책 없는 AI 터미널은 편하다. 그리고 편한 도구가 제일 조용히 사고를 친다. 냉장고 문 열어놓고 전기요금 탓하는 느낌이다.

오늘 기준으로 확인한 것

작성 기준일은 2026년 5월 3일 KST다. Warp 공식 블로그는 2026년 4월 28일 클라이언트 오픈소스화를 발표했다. 공식 발표는 Warp client가 오픈소스라고 표현한다. GitHub 저장소 README도 Warp를 터미널에서 출발한 agentic development environment라고 설명한다. README 기준으로 warpui_core와 warpui 크레이트는 MIT 라이선스다. README 기준으로 나머지 저장소 코드는 AGPL v3다. 공식 FAQ는 더 중요한 경계를 말한다. Warp client는 오픈소스다. 서버는 이 저장소에 없다. Warp Drive backend도 이 저장소에 없다. Hosted authentication도 이 저장소에 없다. Oz orchestration도 이 저장소에 없다. 이 구분이 글 전체의 출발점이다. 오픈소스 공개는 감사 가능성을 높인다. 하지만 팀이 신경 쓰는 보안 질문은 여전히 남는다. 어떤 기능이 로컬에서 끝나는가. 어떤 기능이 Warp backend를 부르는가. 어떤 기능이 LLM provider를 부르는가. 어떤 기능이 회사 cloud account를 거치는가. 어떤 기능이 팀 관리자 정책으로 강제 가능한가. 어떤 기능은 개인 설정에 맡겨져 있는가. 이걸 먼저 표로 만들어야 한다. 감으로 승인하면 나중에 회의가 길어진다. 회의가 길어지면 사람은 커피를 마신다. 커피를 마시면 또 회의가 길어진다. 악순환이다.

한 문장 판단

Warp 오픈소스 이후 팀이 바로 정해야 할 것은 로컬 LLM 도입 여부가 아니라 “AI 기능을 켜도 되는 업무 범위, BYOK와 BYOLLM의 책임 경계, 그리고 AI를 끈 상태에서도 굴러가는 터미널 워크플로”다. 로컬 LLM은 좋은 방향이다. 하지만 로컬 LLM은 만능 방패가 아니다. 모델이 로컬이어도 터미널 출력에 비밀이 섞이면 위험하다. 모델이 로컬이어도 에이전트가 위험한 명령을 실행하면 위험하다. 모델이 로컬이어도 MCP 서버가 과한 권한을 가지면 위험하다. 모델이 로컬이어도 공유 워크플로에 운영 명령이 박히면 위험하다. 그래서 먼저 정할 것은 모델 이름이 아니다. 먼저 정할 것은 데이터 등급이다. 먼저 정할 것은 허용 명령이다. 먼저 정할 것은 저장 금지 정보다. 먼저 정할 것은 AI 비활성 상태의 기본 사용법이다. 이걸 정해두면 Warp를 쓰든, Copilot CLI를 쓰든, 다른 AI 터미널을 쓰든 팀이 덜 흔들린다. 도구는 바뀐다. 정책은 오래 간다.

오픈소스가 해결한 문제와 해결하지 않은 문제

오픈소스가 해결한 첫 번째 문제는 투명성이다. 이제 Warp client 코드를 직접 볼 수 있다. 이건 작지 않다. 보안팀은 클라이언트 동작을 검토할 근거가 생긴다. 개발팀은 버그와 feature issue를 공개 흐름에서 볼 수 있다. 기여자는 GitHub issue와 PR 흐름으로 제품 방향에 참여할 수 있다. 공식 발표도 public GitHub issues를 feature tracking의 source of truth로 옮기겠다고 설명한다. 오픈소스가 해결한 두 번째 문제는 신뢰의 일부다. 닫힌 클라이언트보다 공개 클라이언트가 낫다. 특히 터미널처럼 민감한 도구는 더 그렇다. 명령어와 로그와 파일 경로가 오가는 자리니까 말이다. 하지만 오픈소스가 해결하지 않은 문제도 있다. 서버가 공개된 것은 아니다. Drive backend가 공개된 것은 아니다. Oz orchestration이 공개된 것은 아니다. Hosted authentication이 공개된 것도 아니다. 회사 입장에서는 이 차이가 중요하다. 클라이언트 코드 감사와 SaaS 기능 감사는 다른 일이다. 소스가 공개됐다는 말이 곧 “모든 데이터가 내 노트북 안에서만 돈다”는 뜻은 아니다. 여기서 착각하면 안 된다. AGPL도 운영 정책을 대신해주지 않는다. MIT도 보안 검토를 대신해주지 않는다. 라이선스는 법무의 언어다. 데이터 흐름은 보안의 언어다. 업무 허용선은 운영의 언어다. 팀 도입은 세 언어를 같이 번역해야 한다. 번역 안 하면 나중에 다들 자기 언어로 화낸다. 그 장면, 굳이 보고 싶진 않다.

로컬 LLM을 기다릴 때 제일 위험한 착각

제일 위험한 착각은 “로컬 LLM이 오면 프라이버시 검토는 끝난다”다. 아니다. 로컬 LLM은 프라이버시 설계의 한 조각이다. 끝판왕 버튼은 아니다. GitHub Copilot CLI 공식 문서는 자체 LLM provider를 쓰는 BYOK 흐름을 설명한다. 그 문서는 OpenAI-compatible endpoint, Azure OpenAI, Anthropic, 그리고 Ollama 같은 로컬 실행 모델을 언급한다. 또 offline mode도 설명한다. 다만 offline mode도 provider가 로컬 또는 격리 환경 안에 있을 때 의미가 있다고 경고한다. remote endpoint를 가리키면 프롬프트와 코드 context는 여전히 네트워크로 나간다. 이 문장이 중요하다. 오프라인이라는 단어는 네트워크 경로 전체를 봐야 성립한다. 환경변수 하나가 면죄부는 아니다. Warp 쪽도 비슷하게 봐야 한다. Warp는 공식 문서에서 BYOK를 제공한다고 설명한다. BYOK는 개인 사용자가 OpenAI, Anthropic, Google API 키를 넣는 방식이다. 공식 문서에 따르면 키는 로컬 기기에 저장되고 cloud로 sync되지 않는다. 하지만 BYOK는 Oz Cloud Agents에는 적용되지 않는다고 문서가 말한다. Cloud agent run은 Warp credits를 쓴다. 이것도 중요한 경계다. “내 키를 넣었다”와 “모든 AI 요청이 내 키로만 간다”는 같은 말이 아니다. Enterprise 쪽에는 BYOLLM도 있다. 공식 문서는 BYOLLM이 AWS Bedrock을 통해 조직 cloud infrastructure로 inference를 라우팅한다고 설명한다. BYOK는 개인 설정에 가깝다. BYOLLM은 admin/team 설정에 가깝다. BYOK는 API key 기반이다. BYOLLM은 cloud IAM 기반이다. BYOK는 provider infrastructure로 간다. BYOLLM은 조직 cloud infrastructure로 간다. 이 차이를 팀 문서에 적어야 한다. 안 적으면 “우리 BYOK 쓰니까 회사 통제 안에 있지?” 같은 말이 나온다. 그 말은 반은 맞고 반은 위험하다. 반만 맞는 말이 실무에서 제일 끈적하다.

먼저 정할 것 1: AI 사용 등급

첫 번째로 정할 것은 AI 사용 등급이다. 팀은 repository와 업무를 최소 4단계로 나누는 편이 좋다. 1등급은 AI 사용 금지 영역이다. 고객 원본 데이터가 보이는 작업이다. 프로덕션 secret이 출력될 수 있는 작업이다. 비공개 보안 사고 분석이다. 미공개 재무 정보다. 계약상 외부 전송 금지 자료다. 이 영역에서는 Warp든 Copilot CLI든 Claude Code든 AI 기능을 기본 금지로 둔다. 터미널만 허용할지 여부도 별도 검토한다. 2등급은 AI read-only 허용 영역이다. 코드를 읽고 요약하는 정도는 가능하다. 파일 수정은 금지한다. 명령 실행은 금지한다. 웹 검색도 금지하거나 승인제로 둔다. 로그는 샘플링하고 민감 문자열은 제거한다. 3등급은 AI edit 허용 영역이다. 테스트 코드 추가가 가능하다. 문서 수정이 가능하다. 작은 refactor가 가능하다. 하지만 배포 명령은 여전히 사람 승인이다. DB migration도 사람 승인이다. 권한 변경도 사람 승인이다. 4등급은 AI agent workflow 허용 영역이다. 에이전트가 계획을 세울 수 있다. 파일을 읽을 수 있다. diff를 만들 수 있다. 테스트를 실행할 수 있다. 허용된 read-only 명령은 자동 실행할 수 있다. 그래도 destructive command는 승인제로 둔다. 이 등급표는 Warp 전용 문서가 아니다. AI 개발 도구 공통 문서다. 도구별 설정은 이 문서에 붙는 구현 세부사항이다. 중심을 반대로 두면 도구 바뀔 때마다 정책을 다시 쓴다. 그건 문서 노동 지옥행 티켓이다.

먼저 정할 것 2: BYOK 사용 원칙

두 번째는 BYOK 사용 원칙이다. Warp BYOK는 유용하다. 개인 사용자가 자기 API key로 모델을 호출할 수 있다. Warp 문서는 이 키가 로컬에 저장되고 cloud로 sync되지 않는다고 설명한다. 또 Warp credits를 쓰지 않는다고 설명한다. 그런데 팀에서는 바로 질문이 생긴다. 개인 키를 허용할 것인가. 회사 발급 키만 허용할 것인가. 키 비용은 누가 부담할 것인가. 로그와 retention은 provider 계정 설정을 따르는가. 키가 퇴사자 노트북에 남으면 어떻게 회수할 것인가. BYOK로 보낸 요청은 회사 DLP 정책에서 보이는가. 팀 admin이 BYOK 사용을 강제하거나 공유할 수 있는가. Warp 공식 BYOK 문서는 현재 BYOK가 user level 설정이고 team/admin level 설정이 아니라고 설명한다. 팀 admin이 아직 API key를 강제하거나 공유할 수 없다고 문서가 말한다. 이 말은 실무에서 꽤 크다. 개인 BYOK를 허용하면 편하다. 하지만 중앙 통제가 약하다. 개인 BYOK를 막으면 관리가 쉽다. 하지만 개발자 경험이 불편해질 수 있다. 그래서 팀 정책은 이렇게 가는 편이 깔끔하다. 개인 실험 repository에서는 개인 BYOK 허용. 회사 내부 repository에서는 회사 승인 key만 허용. 민감 repository에서는 BYOK 금지. Enterprise 환경에서는 BYOLLM 또는 관리형 모델 routing 우선. 이렇게 단계별로 적어야 한다. “상식적으로 알아서”는 정책이 아니다. 그건 사고 후 회고록의 첫 문장이다.

먼저 정할 것 3: BYOLLM과 Bedrock 경계

세 번째는 BYOLLM 경계다. Warp 공식 문서 기준 BYOLLM은 Enterprise 기능이다. 조직의 AWS Bedrock을 통해 inference를 실행하는 흐름이다. 관리자가 routing policy를 정한다. 팀원은 AWS CLI와 IAM 인증을 사용한다. 긴 수명의 API key 대신 cloud-native IAM을 쓰는 구조다. 이건 보안팀이 좋아할 만한 부분이다. 하지만 BYOLLM도 만능은 아니다. Warp 공식 문서는 BYOLLM 사용 시 cloud account 설정이 data retention policy를 결정한다고 설명한다. Warp가 조직 infrastructure로 라우팅된 요청의 ZDR을 강제할 수 없다고 설명한다. 즉 AWS 계정의 logging, retention, region, quota, IAM 정책을 같이 봐야 한다. BYOLLM을 쓰면 질문이 바뀐다. 모델 provider를 믿을 수 있나에서 끝나지 않는다. 우리 AWS Bedrock 설정이 맞나로 이동한다. CloudWatch 로그에 무엇이 남는가. 어떤 region에서 inference가 도는가. 어떤 model ID가 허용되는가. 누가 IAM role을 부여받는가. 퇴사자 권한은 자동 회수되는가. quota 초과 시 fallback이 있는가. Auto model selection이 어떤 조건에서 동작하는가. Warp 문서는 직접 API 모델을 비활성화하면 Auto model selection 동작에도 영향이 있다고 설명한다. 이건 운영적으로 중요하다. 모델 routing은 비용 문제가 아니다. 데이터 경로 문제다. 비용은 카드값으로 온다. 데이터 경로 문제는 감사 메일로 온다. 감사 메일은 카드값보다 사람을 더 조용하게 만든다.

먼저 정할 것 4: AI 비활성 워크플로

네 번째는 AI 비활성 워크플로다. 이 글에서 제일 현실적인 부분이다. 팀은 “AI를 끄면 Warp를 어떻게 쓸 것인가”를 먼저 정해야 한다. Warp agents overview 문서는 AI 기능을 Settings > Agents > Warp Agent에서 global toggle로 비활성화할 수 있다고 설명한다. 이 설정이 있다는 건 좋은 일이다. 하지만 버튼이 있다는 것과 팀 워크플로가 있다는 것은 다르다. AI 비활성 모드에서 허용할 사용법을 적어야 한다. 터미널 emulator로만 사용한다. Warp Drive sync는 끈다. Agent Mode는 끈다. Active AI recommendations는 끈다. Generate와 AI autofill은 끈다. Web search는 끈다. Codebase Context indexing은 끈다. Session sharing은 끈다. 팀 prompts나 workflows 공유는 금지한다. 민감 repository에서는 이 모드를 기본값으로 둔다. 프로덕션 host 접속 시 이 모드를 기본값으로 둔다. 고객 데이터 로그 분석 시 이 모드를 기본값으로 둔다. 이런 문서가 있으면 개발자가 덜 불안하다. 개발자는 도구를 쓰고 싶다. 보안팀은 사고를 막고 싶다. AI 비활성 워크플로는 둘 사이의 완충재다. “아예 쓰지 마”보다 낫다. “그냥 알아서 조심해”보다도 낫다. 도구 사용을 금지하면 사람은 우회로를 찾는다. 우회로는 보통 문서화가 안 된다. 문서화 안 된 우회로는 나중에 신화가 된다. “누가 그랬대?”만 남는다.

먼저 정할 것 5: 텔레메트리와 crash report

다섯 번째는 telemetry와 crash report다. Warp enterprise security overview는 telemetry table, Network Log, opt-out controls를 강조한다. 공식 문서는 Settings > Privacy에서 Help improve Warp와 Send crash reports를 끌 수 있다고 설명한다. Business와 Enterprise plan에서는 data collection이 기본적으로 disabled라고 설명한다. Free tier와 paid teams의 기본값은 다를 수 있다. 여기서 팀 정책이 필요하다. 개인 설치를 허용할 것인가. 팀 plan으로만 설치할 것인가. telemetry opt-out을 개인에게 맡길 것인가. admin policy로 enforce할 것인가. crash report를 허용할 것인가. 허용한다면 어떤 repository에서만 허용할 것인가. Network Log 검토를 pilot 절차에 넣을 것인가. 민감 작업 중에는 crash reporting을 꺼야 하는가. telemetry data가 수집될 경우 retention은 어떻게 보는가. Warp 문서는 telemetry data가 수집될 경우 analytics와 debugging 목적으로 indefinitely retained된다고 설명한다. 이 문장은 꼭 체크해야 한다. 보안팀이 싫어할 수도 있다. 법무팀이 질문할 수도 있다. 그럼 좋은 일이다. 질문이 도입 전에 나오면 회의다. 질문이 도입 후 사고에서 나오면 사건이다. 둘은 맛이 다르다. 전자는 씁쓸한 커피고 후자는 식은 피자다. 둘 다 먹을 수는 있지만 굳이 후자를 고를 필요는 없다.

먼저 정할 것 6: 코드와 파일이 언제 나가는지

여섯 번째는 코드와 파일 전송 조건이다. Warp enterprise security overview는 code and files가 기본적으로 기기에 머문다고 설명한다. 단, 명시적으로 전송하는 기능을 쓰면 달라진다. 예시는 Codebase Context indexing, session sharing, Warp Drive team resources다. Codebase Context는 indexing 중 code가 Warp server로 보내져 embedding을 생성한다고 설명한다. 문서는 raw code는 저장하지 않고 resulting embeddings만 retained된다고 설명한다. 이건 팀마다 판단이 갈릴 수 있다. 일반 오픈소스 repo라면 괜찮을 수 있다. 상용 핵심 알고리즘 repo라면 안 될 수 있다. 고객별 customization repo라면 더 조심해야 한다. 팀은 기능별로 허용표를 만들어야 한다. Codebase Context 허용 여부. Session sharing 허용 여부. Warp Drive team resources 허용 여부. Block sharing 허용 여부. Prompt 공유 허용 여부. Workflow 공유 허용 여부. 외부 URL context 첨부 허용 여부. 이미지 첨부 허용 여부. 파일 첨부 허용 여부. 이걸 repository 등급과 연결해야 한다. 예를 들어 public repo에서는 indexing 허용. internal repo에서는 승인 후 허용. restricted repo에서는 금지. production incident repo에서는 금지. 이런 식이다. 기능 이름만 적으면 부족하다. 업무 등급과 붙여야 한다. 보안 정책은 혼자 있으면 외롭다. 업무 분류와 결혼시켜야 오래 간다.

먼저 정할 것 7: secret redaction

일곱 번째는 secret redaction이다. Warp enterprise security overview는 API keys, tokens, passwords, SSH keys, certificates, custom secret patterns를 redaction 대상으로 설명한다. 팀이 확인할 것은 세 가지다. 첫째, 이 기능이 현재 팀 plan에서 어떻게 동작하는가. 둘째, custom secret pattern을 admin이 강제할 수 있는가. 셋째, redaction 전 단계에서 어떤 데이터가 화면이나 로그에 남는가. secret redaction은 좋은 안전망이다. 하지만 안전망이 있다고 해서 10층 창문에서 춤추면 안 된다. 터미널에는 secret이 쉽게 나온다. env 출력. CI log. terraform output. cloud credential helper. database connection string. SSH private key 일부. Kubernetes secret decode 결과. Sentry DSN. Webhook URL. 이런 것들이 생각보다 자주 보인다. 팀 정책은 secret 출력 자체를 줄여야 한다. AI에게 secret이 보이면 안 된다는 말은 당연하다. 더 좋은 말은 shell에 secret이 보이지 않게 하자는 것이다. 예를 들어 production command alias는 masking을 기본으로 둔다. debug log에는 credential field를 출력하지 않는다. runbook에는 secret 값을 직접 붙이지 않는다. prompt에는 token을 넣지 않는다. workflow에는 secret을 plain text로 저장하지 않는다. Warp Drive가 secret plain text 저장을 막는다고 해도 팀 runbook 자체가 깨끗해야 한다. 도구의 redaction은 마지막 방어선이다. 첫 번째 방어선은 습관이다. 습관이 제일 싸고 제일 고치기 어렵다.

먼저 정할 것 8: agent permission 기본값

여덟 번째는 agent permission 기본값이다. Warp agent permissions 문서는 Read files, Create plans, Execute commands 같은 permission type을 설명한다. 또 command allowlist와 denylist도 설명한다. MCP server 접근도 Agent decides, allowlist, denylist 방식으로 조정할 수 있다고 문서화되어 있다. 팀은 기본값을 보수적으로 둬야 한다. Read files는 repository 등급에 따라 다르게 둔다. Create plans는 대부분 허용 가능하다. Execute commands는 기본 승인제로 둔다. Read-only command allowlist를 따로 둔다. 예를 들어 pwd, ls, git status, git diff, git log, rg, find 같은 명령은 후보가 될 수 있다. 다만 find도 범위가 넓으면 민감 파일을 긁을 수 있다. 그래서 working directory 제한이 필요하다. 명령어 이름만으로 안전하다고 보면 안 된다. cat ~/.ssh/id_rsa는 cat이 문제라기보다 대상 파일이 문제다. denylist도 필요하다. rm -rf. sudo. chmod -R. chown -R. kubectl delete. terraform apply. terraform destroy. aws iam. aws s3 sync 중 민감 bucket. git push --force. docker system prune. psql production connection. 이런 명령은 기본 승인이다. production credential이 필요한 명령도 승인이다. 배포 명령은 승인이다. DB migration은 승인이다. 권한 변경은 승인이다. 에이전트가 똑똑해져도 책임자는 사람이다. “AI가 했어요”는 RCA 문서에서 가장 힘없는 문장이다.

먼저 정할 것 9: MCP와 외부 도구 연결

아홉 번째는 MCP와 외부 도구 연결이다. AI 터미널의 진짜 위험은 모델 하나가 아니다. 모델이 만지는 도구 묶음이다. Warp agent permissions 문서는 MCP allowlist와 denylist 흐름을 언급한다. 이건 꼭 정책으로 끌어와야 한다. MCP server는 편하다. GitHub를 붙일 수 있다. Jira를 붙일 수 있다. Slack을 붙일 수 있다. filesystem을 붙일 수 있다. database를 붙일 수 있다. cloud provider를 붙일 수 있다. 편해질수록 권한 면적이 커진다. 팀은 MCP server registry를 만들어야 한다. 허용 server 이름. 허용 version. 설치 source. 권한 scope. 사용 가능 repository. 사용 가능 사용자 그룹. 로그 위치. 승인자. 검토 주기. 삭제 기준. 이 정도는 있어야 한다. 특히 filesystem MCP는 범위를 좁혀야 한다. home directory 전체를 열면 안 된다. workspace root도 넓을 수 있다. project directory 단위로 제한한다. database MCP는 read-only credential부터 시작한다. Slack MCP는 private channel 접근을 막는다. GitHub MCP는 issue read와 PR comment부터 시작한다. cloud MCP는 production 계정 금지부터 시작한다. 이건 Warp만의 문제가 아니다. AI coding workflow 전체의 문제다. Warp는 그 문제를 더 편한 UI 안에 넣어줄 수 있다. 편한 UI 안에 들어가면 위험도 편해진다. 위험이 편해지는 순간이 제일 무섭다.

먼저 정할 것 10: Copilot CLI local model 흐름과 비교

열 번째는 비교 기준이다. GitHub Copilot CLI 공식 문서는 자체 provider를 환경변수로 지정하는 흐름을 설명한다. OpenAI-compatible endpoint를 쓸 수 있다. Azure OpenAI를 쓸 수 있다. Anthropic을 쓸 수 있다. Ollama 같은 로컬 모델도 언급한다. model requirement로 tool calling과 streaming 지원을 요구한다. 권장 context window도 언급한다. offline mode는 GitHub server 접촉을 막기 위한 설정으로 설명된다. 하지만 provider endpoint가 remote이면 prompt와 code context가 그 provider로 간다고 문서가 경고한다. 이 비교가 Warp 팀 도입에 도움이 된다. 왜냐하면 “로컬 모델 지원”의 의미를 쪼갤 수 있기 때문이다. 첫째, 모델 binary가 노트북에서 도는가. 둘째, endpoint가 localhost인가. 셋째, 도구가 vendor backend를 호출하지 않는가. 넷째, auth와 entitlement check가 어떻게 되는가. 다섯째, tool calling과 streaming이 되는가. 여섯째, agent가 실행하는 command 권한을 제한할 수 있는가. 일곱째, offline mode가 진짜 network isolation을 보장하는가. 여덟째, telemetry와 crash report가 따로 꺼지는가. 이 기준으로 보면 로컬 LLM은 단어 하나가 아니다. 여러 조건의 묶음이다. Warp가 앞으로 ACP나 더 넓은 local endpoint 지원을 제공하더라도 이 질문은 그대로 남는다. 그래서 지금 정해야 한다. 나중에 기능이 오면 그때 정책 만들자는 말은 달콤하다. 달콤한 말은 보통 마감 직전에 이를 아프게 한다.

실무 체크리스트: 도입 전 30문항

Warp를 terminal emulator로만 쓸 repository를 정했나.
Warp AI 기능을 허용할 repository를 따로 정했나.
AI 금지 repository 목록이 있나.
고객 데이터가 보이는 작업에서 AI 기능을 끄는 절차가 있나.
production host 접속 시 AI 비활성 모드가 기본인가.
BYOK 개인 사용 허용 범위가 정해졌나.
회사 승인 API key만 허용하는 영역이 정해졌나.
BYOK 비용 부담 주체가 정해졌나.
BYOK provider retention 설정을 확인했나.
BYOLLM이 필요한 팀과 필요 없는 팀을 나눴나.
AWS Bedrock region과 model allowlist를 정했나.
CloudWatch logging과 retention을 확인했나.
telemetry와 crash report 기본값을 정했나.
Business 또는 Enterprise admin enforcement 가능 여부를 확인했나.
Network Log 확인 절차를 pilot에 넣었나.
Codebase Context indexing 허용 범위를 정했나.
Warp Drive 사용 가능 정보 등급을 정했나.
session sharing 허용 범위를 정했나.
block sharing 허용 범위를 정했나.
secret redaction 설정과 custom pattern을 확인했나.
terminal output에 secret을 찍지 않는 runbook을 만들었나.
agent read file permission 기본값을 정했나.
agent execute command 기본값을 승인제로 뒀나.
read-only command allowlist를 만들었나.
destructive command denylist를 만들었나.
MCP server allowlist를 만들었나.
MCP server별 scope와 credential을 최소화했나.
audit log를 누가 보는지 정했나.
incident 발생 시 Warp 사용 중지 절차가 있나.
AI 비활성 워크플로로도 하루 업무가 가능한지 테스트했나.
이 30문항이 답이 되면 pilot은 꽤 안전해진다. 답이 없으면 pilot이 아니라 분위기 테스트다. 분위기 테스트도 필요할 때가 있다. 다만 회사 노트북으로 하는 분위기 테스트는 이름을 정직하게 붙여야 한다.

팀 정책 초안 예시

아래는 그대로 복붙하라는 뜻이 아니다. 팀 wiki에 넣고 자기 환경에 맞게 줄이라는 뜻이다. 제목은 “AI 터미널 사용 기준” 정도면 충분하다. 정책 1. 민감 repository에서는 Warp를 terminal-only mode로 사용한다. 정책 2. 민감 repository에서는 Warp Agent, Active AI, Generate, AI autofill, web search, Codebase Context indexing, session sharing을 비활성화한다. 정책 3. 일반 internal repository에서는 AI read-only와 plan creation을 허용하되 command execution은 승인제로 둔다. 정책 4. 개인 BYOK는 개인 sandbox와 public repo 실험에만 허용한다. 정책 5. 회사 업무 repository에서는 회사 승인 key 또는 Enterprise model routing만 사용한다. 정책 6. BYOLLM 사용 시 AWS Bedrock region, model, IAM role, log retention을 보안팀이 승인한다. 정책 7. production host와 production credential이 필요한 작업에서는 AI 기능을 끈다. 정책 8. 에이전트 command allowlist는 read-only 중심으로 시작한다. 정책 9. 배포, 삭제, 권한 변경, data migration 명령은 항상 사람 승인을 요구한다. 정책 10. MCP server는 allowlist 방식으로만 추가한다. 정책 11. filesystem MCP는 project directory 밖 접근을 금지한다. 정책 12. cloud MCP는 production account 접근을 금지한다. 정책 13. secret은 prompt, workflow, Drive resource, shared session에 넣지 않는다. 정책 14. telemetry와 crash report 설정은 plan별 기본값을 확인하고 admin policy로 강제 가능한 경우 강제한다. 정책 15. 도입 첫 2주는 Network Log와 provider usage log를 샘플링 검토한다. 정책 16. 도구 업데이트 후 AI 기능 기본값이 바뀌었는지 확인한다. 정책 17. 사고가 발생하면 Warp AI 기능을 먼저 비활성화하고 session 공유와 model routing log를 보존한다. 정책 18. 이 정책은 Warp뿐 아니라 AI terminal, CLI agent, editor agent에도 적용한다. 짧아 보여도 이 정도면 팀 대화가 쉬워진다. 정책이 없으면 모두가 감으로 말한다. 감은 빠르다. 감은 로그가 없다. 로그 없는 감은 회고에서 힘이 약하다.

도입 파일럿은 이렇게 작게 시작하자

첫 주에는 terminal-only mode로 시작한다. 개발자 3명에서 5명 정도면 충분하다. 민감하지 않은 repository를 고른다. AI 기능은 끈다. Warp 기본 사용성만 본다. shell integration. block model. navigation. diff view. settings file. 팀원이 기존 터미널에서 잃는 것이 있는지 본다. 둘째 주에는 AI read-only를 켠다. 파일 읽기와 plan creation만 허용한다. command execution은 승인제로 둔다. Codebase Context indexing은 아직 켜지 않는다. session sharing도 아직 켜지 않는다. 이 단계에서는 prompt에 어떤 정보가 들어가는지만 본다. 셋째 주에는 제한된 command allowlist를 만든다. git status. git diff. rg. ls. pwd. 이 정도부터 시작한다. 팀마다 추가해도 된다. 하지만 추가할 때마다 이유를 적는다. 넷째 주에는 BYOK 또는 BYOLLM을 검토한다. 개인 BYOK를 먼저 열지 않는다. 회사 통제 모델을 먼저 검토한다. Enterprise 팀이면 BYOLLM이 실제 요구사항에 맞는지 본다. AWS Bedrock quota와 region도 본다. 다섯째 주에는 MCP를 하나만 붙인다. 여러 개 붙이면 원인 분석이 어렵다. GitHub issue read-only 정도가 적당하다. 여섯째 주에는 승인 여부를 결정한다. 승인. 제한 승인. 보류. 이 세 가지 중 하나면 된다. 멋진 도입 보고서보다 명확한 상태값이 낫다. 상태값 없는 보고서는 슬라이드만 예쁘다. 슬라이드는 예쁘고 운영은 운다.

개발자에게 안내할 말

개발자에게는 겁주는 문서보다 행동 기준이 필요하다. 이렇게 말하면 된다. Warp를 써도 된다. 다만 repository 등급을 먼저 확인해라. 민감 repository에서는 AI를 꺼라. production host에서는 AI를 꺼라. secret이 보이는 terminal output은 AI에게 넘기지 마라. 개인 BYOK는 sandbox에서만 써라. 회사 업무에서는 승인된 model routing을 써라. 에이전트가 실행하려는 명령은 읽어보고 승인해라. 자동 실행 allowlist는 read-only 중심으로 둬라. MCP server는 임의로 붙이지 마라. prompt에 고객 데이터와 secret을 넣지 마라. 문제 생기면 session과 logs를 삭제하지 말고 보안팀에 알려라. 이 정도면 충분히 현실적이다. 너무 긴 정책은 아무도 안 읽는다. 너무 짧은 정책은 아무것도 못 막는다. 좋은 정책은 읽을 수 있을 만큼 짧고, 사고를 줄일 만큼 구체적이다. 말이 쉽다. 그래서 템플릿이 필요하다. 사람은 원래 바쁠 때 문서를 안 읽는다. 그러니 바쁘기 전에 짧은 문서를 만들어야 한다.

보안팀에게 물어볼 질문

보안팀에는 다른 질문이 필요하다. Warp client 오픈소스 검토를 누가 맡을 것인가. AGPL v3 사용이 단순 사용과 수정 배포에서 어떻게 달라지는가. WarpUI MIT crates 재사용 가능성은 별도로 볼 것인가. Warp backend와 Drive backend는 vendor review에서 어떻게 다룰 것인가. BYOK를 개인 단위로 허용할 것인가. BYOLLM을 Enterprise 표준으로 볼 것인가. ZDR 요구사항은 provider account 기준인가, vendor 계약 기준인가. telemetry opt-out을 개인 설정에 맡길 것인가. admin enforcement가 필요한가. crash report에 민감 정보가 들어갈 가능성을 어떻게 볼 것인가. Codebase Context embeddings retention을 허용할 것인가. session sharing을 허용할 것인가. Network Log 검토를 누가 할 것인가. MCP server 검토 기준은 무엇인가. agent command approval log를 어디에 남길 것인가. production incident 중 AI 도구 사용을 허용할 것인가. 이 질문들은 약간 딱딱하다. 하지만 딱딱한 질문이 나중에 부드러운 운영을 만든다. 처음부터 말랑말랑하면 나중에 젤리처럼 잡히지 않는다.

법무와 구매팀에게 물어볼 질문

법무와 구매팀도 초반에 들어와야 한다. Warp client는 AGPL v3다. WarpUI crates는 MIT다. 단순 사용과 수정 배포는 다르다. 회사 내부 fork를 만들 계획이 있는지 확인해야 한다. modified client를 사내에 배포할 계획이 있는지도 봐야 한다. hosted derivative를 만들 계획이 있으면 더 조심해야 한다. 공식 FAQ는 회사에서 terminal이나 development environment로 사용하는 것 자체가 AGPL network 또는 distribution obligation을 trigger하지 않는다고 설명한다. 그래도 법무 확인은 필요하다. 라이선스 문장은 블로그가 대신 서명해줄 수 없다. 구매팀은 plan별 control 차이를 봐야 한다. Free tier. Paid teams. Business. Enterprise. 각 plan에서 telemetry 기본값과 admin enforcement가 다르다. BYOK availability도 확인해야 한다. BYOLLM은 Enterprise 기능이다. SSO와 RBAC와 admin policy도 plan에 따라 다를 수 있다. 가격만 보면 안 된다. 제어권도 가격표의 일부다. 싼 도구가 나중에 운영비를 비싸게 만들 수 있다. 이건 모든 SaaS 구매의 오래된 농담이다. 웃기지만 안 웃긴 농담이다.

FAQ

Warp가 오픈소스가 됐으면 이제 완전히 로컬 도구인가?

아니다. 공식 FAQ 기준으로 Warp client는 오픈소스지만 server, Warp Drive backend, hosted authentication, Oz orchestration은 공개 저장소에 없다. 일부 기능은 로컬에서 동작하고, Drive sync, hosted-model agents, team features 같은 기능은 backend가 필요하다고 FAQ가 설명한다. 그래서 정확한 표현은 “Warp client가 오픈소스가 됐다”다. “Warp 전체가 완전히 로컬 오픈소스 도구가 됐다”는 표현은 과하다.

BYOK를 쓰면 회사 데이터가 Warp를 거치지 않나?

그렇게 단순하지 않다. Warp BYOK 문서는 사용자 API key가 로컬에 저장되고 cloud로 sync되지 않는다고 설명한다. 또 선택한 provider로 agent request를 직접 route한다고 설명한다. 하지만 BYOK는 Oz Cloud Agents에는 적용되지 않는다고 문서가 말한다. 그리고 provider 계정의 ZDR이나 retention 설정은 별도로 확인해야 한다.

BYOLLM은 BYOK보다 안전한가?

상황에 따라 다르다. BYOLLM은 조직 AWS Bedrock과 IAM을 쓰기 때문에 팀 통제에는 더 맞을 수 있다. 하지만 Warp 문서는 BYOLLM 요청의 retention은 조직 cloud account 설정에 달려 있고 Warp가 이를 강제할 수 없다고 설명한다. 즉 BYOLLM은 “회사 cloud로 라우팅한다”는 장점이 있지만 AWS 설정 검토가 필수다.

로컬 LLM 지원을 기다리면 지금 검토를 미뤄도 되나?

미루면 안 된다. 로컬 LLM은 모델 실행 위치를 바꿀 수 있지만 agent permission, command execution, secret exposure, MCP scope, telemetry 같은 문제를 자동으로 없애지 않는다. 지금 정해야 나중에 local endpoint가 들어와도 안전하게 붙일 수 있다. 정책 없이 기능만 기다리면 기능이 온 날부터 다시 싸운다.

GitHub Copilot CLI의 local model 문서가 왜 비교 대상인가?

GitHub Copilot CLI 공식 문서는 Ollama 같은 locally running model, OpenAI-compatible endpoint, offline mode를 설명한다. 또 offline mode도 provider가 remote endpoint이면 prompt와 code context가 네트워크로 나간다고 경고한다. 이 문서는 “local model 지원”이 정확히 무엇을 의미하는지 쪼개는 데 도움이 된다. Warp 자체 기능을 평가할 때도 같은 기준을 쓰면 좋다.

Warp AI를 완전히 꺼도 쓸 이유가 있나?

있을 수 있다. Warp는 terminal에서 출발한 ADE이고, AI를 끈 상태에서도 터미널 사용성, block model, UI, 설정 파일, diff view 같은 경험이 팀에 맞을 수 있다. 다만 민감 repository에서는 AI 비활성 워크플로를 먼저 검증해야 한다. AI를 켜야만 쓸 수 있는 도구처럼 운영하면 선택지가 줄어든다.

가장 먼저 해야 할 팀 액션은 무엇인가?

repository 등급표를 만드는 것이다. AI 금지, AI read-only, AI edit, AI agent workflow 허용 영역을 나눠라. 그다음 BYOK, BYOLLM, telemetry, secret redaction, agent permission, MCP allowlist를 붙이면 된다. 순서를 바꾸면 도구 설정이 정책을 끌고 간다. 정책이 도구 설정을 끌고 가야 한다.

공식 출처

마무리 판단

Warp 오픈소스는 좋은 변화다. 클라이언트 코드가 공개됐고, 팀은 더 많은 것을 직접 확인할 수 있다. 하지만 팀 도입에서 더 중요한 질문은 여전히 남아 있다. AI 요청은 어디로 가는가. 키는 어디에 저장되는가. 모델은 누가 고르는가. 로그는 어디에 남는가. 에이전트는 어떤 명령을 실행할 수 있는가. 민감 작업에서 AI를 끄면 업무가 계속 되는가. 이 질문에 답하면 로컬 LLM 지원이 왔을 때 팀은 빠르게 움직일 수 있다. 답이 없으면 새 기능 하나가 올 때마다 회의가 열린다. 회의는 죄가 없다. 하지만 회의를 줄이는 문서는 선행이다. 지금 필요한 것은 Warp 찬반 투표가 아니다. 지금 필요한 것은 팀의 AI 터미널 운영선이다. BYOK는 개인 편의의 문제로만 보지 말자. BYOLLM은 Enterprise 체크박스로만 보지 말자. AI 비활성 워크플로는 보수적인 팀의 핑계로 보지 말자. 이 셋은 같은 문제의 다른 얼굴이다. 어떤 데이터가 나가도 되는가. 어떤 명령을 AI가 만져도 되는가. 어떤 상황에서는 AI가 없어도 일이 굴러가야 하는가. 이걸 정한 팀은 Warp를 더 잘 쓸 수 있다. 안 쓰기로 해도 더 잘 안 쓸 수 있다. 둘 다 성숙한 결정이다. 제일 별로인 결정은 아무도 정하지 않았는데 다들 쓰고 있는 상태다. 그건 도입이 아니라 확산이다. 확산은 빠르다. 수습은 느리다. 그러니 2026년 5월 현재 팀이 먼저 할 일은 명확하다. Warp를 열기 전에 팀 정책 문서를 열자. 터미널보다 문서가 먼저라니 재미없다. 근데 운영은 원래 재미없는 쪽이 오래 간다. 재미는 도구에서 챙기고, 안전은 정책에서 챙기자.