여러 코딩 에이전트를 한 화면에 모으면 무엇이 좋아지고, 무엇이 위험해지나

터미널 창을 여러 개 띄워 두고, Codex가 끝났는지 Claude Code가 승인을 기다리는지 번갈아 확인하는 장면은 이제 낯설지 않습니다. 에이전트를 하나 더 붙일 때마다 창도 하나씩 늘어납니다. 문제는 모델 성능이 아니라, 지금 어떤 작업이 어디까지 진행됐고 무엇을 승인해야 하는지를 놓치지 않는 일입니다.

T3 Code는 이 문제를 "제어면(control surface)"이라는 이름으로 풉니다. 모델을 새로 제공하는 서비스가 아니라, 이미 인증해 둔 코딩 에이전트들을 로컬 서버로 감싸 웹, 데스크톱, 모바일에서 조종하는 오픈소스 프로젝트입니다. Codex, Claude Code, Cursor, Grok Build, OpenCode, Google Antigravity를 지원합니다. MIT 라이선스입니다.

편리함은 분명합니다. 하지만 이 도구를 처음 켤 때 가장 먼저 봐야 할 것은 기능 목록이 아니라 권한 기본값입니다. T3 Code의 새 스레드 기본 권한은 Full access이고, 원격 페어링 토큰은 범위를 지정하지 않으면 접근 관리까지 포함한 모든 권한을 받습니다. 이 글은 공식 저장소와 문서를 기준으로 구조를 설명하고, 안전한 첫 실행 순서를 제안합니다.

T3 Code가 하는 일

T3 Code는 자신을 "에이전트 하네스 제어면"이라고 부릅니다. 정확히는 다음과 같은 구성입니다.

• 로컬에서 실행되는 Node WebSocket 서버가 provider CLI를 자식 프로세스로 감쌉니다.
• 웹 앱, Electron 데스크톱 앱, React Native 모바일 앱이 그 서버에 붙습니다.
• 사용자는 자신의 구독으로 인증한 에이전트를 그대로 씁니다. T3 Code가 모델 사용료를 대신 내는 구조가 아닙니다.
• 스레드, 프로젝트, 승인 요청, 체크포인트가 서버에 남습니다.

저장소는 2026년 2월 8일에 만들어졌고, 10월 19일 기준 별 28.6k, 포크 7.7k, 커밋 6,684개입니다. 최신 안정 릴리스는 0.1.0(10월 15일)이고, 0.1.1 프리뷰와 나이틀리 빌드가 그 위에서 테스트되고 있습니다. 프리뷰 빌드 중 하나는 유지보수자 테스트용으로 "설치하지 말 것"이라고 표시돼 있습니다. README는 "아주 초기 프로젝트이므로 버그를 예상하라"고 명시하고, 큰 기능 기여는 받지 않는다고 안내합니다. AGENTS.md에는 사용자 50만 명이라는 표현도 있지만, 이는 저장소의 자체 주장이지 독립적으로 확인한 수치는 아닙니다.

설치는 간단합니다.

curl -fsSL https://t3.codes/install.sh | sh
# 또는 설치 없이
npx t3@latest

macOS에서는 brew install --cask t3-code, Windows에서는 winget install T3Tools.T3Code 같은 패키지도 제공합니다. 최소 하나의 provider CLI를 설치하고 로그인해야 합니다. 예를 들어 Codex는 codex login, Claude Code는 claude auth login, OpenCode는 opencode auth login입니다.

구조: 왜 웹과 모바일에서 내 노트북의 에이전트를 조종할 수 있나

T3 Code의 핵심은 클라이언트가 모델과 직접 통신하지 않는다는 점입니다. 모든 요청은 호스트에서 실행 중인 서버를 거칩니다. 공식 AGENTS.md가 설명하는 흐름은 다음과 같습니다.

[클라이언트]  웹 / Electron / React Native
      │  typed WebSocket request
      ▼
[로컬 서버]
  Orchestrator: 명령을 직렬화하고 이벤트를 결정 (I/O 없음)
      │
      ▼
  Event sink: 이벤트, 프로젝션, 명령 영수증, outbox를 한 트랜잭션으로 커밋
      │
      ▼
  Effect worker: provider 턴 시작, 체크포인트 캡처 같은 부수 효과 실행
      │
      ▼
  Provider adapter → Codex / Claude Code / Cursor / Grok / OpenCode / Antigravity CLI
      │
      ▼
  각 턴 종료 시 hidden git ref로 체크포인트

이 구조의 장점은 상태와 자격 증명이 호스트에 남는다는 것입니다. 모바일 앱은 얇은 클라이언트이고, 실제 파일과 provider 인증은 서버가 있는 머신에 있습니다. 반대로 말하면, 서버에 접근할 수 있는 클라이언트는 그 머신의 파일과 에이전트를 조종할 수 있습니다. 편의와 위험이 같은 구조에서 나옵니다.

체크포인트도 눈여겨볼 부분입니다. 각 턴이 끝나면 숨겨진 git ref가 만들어져, 앱에서 diff를 보고 복원할 수 있습니다. 이는 실수를 되돌리는 데 유용하지만, 보안 경계는 아닙니다. 에이전트가 실행한 명령과 파일 변경 자체를 격리하지는 않습니다.

권한 모드: 편의와 통제의 교환

T3 Code는 스레드마다 네 가지 권한 모드를 제공합니다.

문서에 따르면 새 스레드의 초기 기본값은 Full access입니다. 기존 스레드와 드래프트에서 고른 모드는 유지됩니다. 프로젝트별로 환경 기본값을 덮어쓸 수 있습니다.

provider마다 권한 집행 방식도 다릅니다. Auto 모드는 Codex, Claude, Cursor, Grok에서 자동 검토를 쓰고, OpenCode와 Antigravity처럼 동등한 기능이 없는 provider는 질문으로 돌아갑니다. Grok은 Auto-accept edits를 제공하지 않고, Muse Code는 Supervised와 Full access만 제공합니다. Antigravity는 Full access에서도 네이티브 승인 요청을 보낼 수 있습니다.

팀 단위 코드 리뷰와 승인 흐름은 Claude Code 팀 코드 리뷰에서 더 다룹니다.

여기서 실무적인 판단이 필요합니다. 여러 에이전트를 병렬로 돌리는 환경일수록 승인 피로가 커집니다. 그래서 Full access로 두고 싶은 유혹이 생깁니다. 하지만 Full access는 "에이전트가 실수해도 된다"는 뜻이 아니라 "실수를 막는 장치를 끈다"는 뜻입니다. 테스트 저장소가 아니라면, 첫 스레드는 Supervised로 시작하는 편이 안전합니다.

원격 접근: 페어링 링크는 비밀번호다

T3 Code의 원격 기능은 세 가지 경로를 제공합니다.

• T3 Connect: 라우터 포워딩 없이 계정으로 환경을 연결하는 터널
• LAN/사설망 페어링: 같은 네트워크에서 QR 코드나 링크로 연결
• Tailscale HTTPS, SSH: 기존 네트워크·키 관리 체계를 활용

문서가 반복해서 강조하는 것은 페어링 URL과 인증 코드를 비밀번호처럼 다루라는 것입니다. 스크린샷, 로그, 버그 리포트에 넣지 말라고 합니다. 이유는 단순합니다. 링크를 가진 사람이 환경에 접근할 수 있기 때문입니다.

권한 범위도 명시적으로 지정해야 합니다. 문서에 따르면 --scope를 지정하지 않은 페어링 토큰과 발급된 bearer 세션은 접근 관리와 T3 Connect 관리까지 포함한 모든 권한을 받습니다. 예를 들어 읽기 전용으로 쓰고 싶다면 다음과 같이 범위를 좁힙니다.

npx t3 pair --scope orchestration:read --scope relay:read

terminal:operate와 orchestration:operate는 특히 강한 권한입니다. 터미널과 에이전트 실행을 직접 다룰 수 있기 때문입니다. 접근 관리 권한을 주고 싶지 않은 클라이언트는 이 두 범위도 빼야 합니다. filesystem:read와 filesystem:write, source-control:write도 각각 파일 접근과 Git 변경 범위를 나눕니다.

세션을 회수하는 방법도 알아 두어야 합니다. 호스트에서 Settings → Connections로 클라이언트 세션을 취소할 수 있고, 명령줄에서는 t3 auth session list와 t3 auth session revoke <id>를 씁니다. 페어링 링크를 취소하는 것과 기존 세션을 취소하는 것은 다릅니다. 링크를 막아도 이미 연결된 세션은 남을 수 있습니다.

브라우저 탭도 호스트에서 실행됩니다. 첫 탭은 약 120MB의 헤드리스 Chrome을 내려받고, 여러 기기에서 같은 탭을 봅니다. 오디오는 기기로 재생되지 않고, 다운로드는 탭을 닫을 때까지 호스트에 남습니다. 원격 환경에서는 이 점을 기억해야 합니다. 민감한 페이지를 열어 두면 호스트에 흔적이 남습니다.

위협 모델을 표로 정리하면 다음과 같습니다.

안전한 첫 실행 체크리스트

T3 Code를 처음 도입한다면 다음 순서를 권합니다.

1. 테스트 저장소에서 시작합니다. 프로덕션 자격 증명과 고객 데이터가 있는 환경은 피합니다.
2. 첫 스레드의 권한을 Supervised로 바꿉니다. 기본값이 Full access라는 점을 먼저 확인합니다.
3. 가능하면 전용 OS 사용자나 격리된 VM/컨테이너에서 실행합니다. T3 Code는 샌드박스가 아닙니다.
4. 원격 페어링은 필요한 범위만 줍니다. --scope를 생략하지 않습니다.
5. 페어링 링크와 코드를 스크린샷, 이슈, 로그에 남기지 않습니다.
6. 공용 인터넷에 직접 노출하기보다 LAN, Tailscale, SSH를 우선합니다.
7. 사용이 끝나면 t3 auth session revoke로 세션을 회수합니다.
8. 각 턴의 체크포인트 diff를 확인한 뒤에만 변경을 받아들입니다.
9. 신뢰할 수 없는 저장소에서는 Full access로 실행하지 않습니다.
10. 프리뷰 빌드이므로 업데이트와 버그를 전제로 운영합니다.

이 체크리스트는 T3 Code를 쓰지 말자는 뜻이 아닙니다. 여러 에이전트를 병렬로 돌리는 팀일수록 "누가 무엇을 승인했는가"가 중요해지므로, 제어면을 관리자 콘솔처럼 다루자는 뜻입니다.

무엇을 기대하지 말아야 하나

T3 Code는 모델이 아닙니다. 모델 성능을 올려 주지 않습니다. 에이전트를 격리하는 샌드박스도 아닙니다. provider CLI가 할 수 있는 일은 T3 Code에서도 대체로 할 수 있습니다. 대신 스레드 관리, 승인 UI, 체크포인트, 다중 기기 접근이라는 운영 계층을 더합니다. 격리가 필요하다면 Copilot 로컬 샌드박스 가이드를 참고하십시오. 모델과 하네스의 차이는 모델 vs 하네스에서 더 다룹니다.

또한 초기 프로젝트입니다. README는 버그를 예상하라고 하고, 큰 기능 기여는 받지 않는다고 밝힙니다. 저장소에는 1,400개 이상의 이슈와 1,400개 이상의 PR이 열려 있습니다. 프리뷰 릴리스라는 점을 감안해야 합니다.

마지막으로, "한 화면"이 "한 권한"을 뜻하지는 않습니다. 여러 provider를 한 UI에 모으면 승인 흐름도 한곳에 모입니다. 그 편리함이 곧 공격 표면의 집중입니다. 기본 권한을 낮추고, 원격 범위를 좁히고, 세션을 회수하는 일이 기능만큼 중요합니다.

결론: 제어면은 편리함이 아니라 권한 설계다

여러 코딩 에이전트를 병렬로 돌리는 개발 환경에서 T3 Code의 가치는 분명합니다. 터미널을 전환하지 않고 작업 상태를 보고, 승인하고, 체크포인트를 비교할 수 있습니다. 웹·데스크톱·모바일에서 같은 환경을 본다는 점도 원격 작업에 유용합니다.

하지만 이 도구를 켜는 순간 당신은 작은 관리자 콘솔을 운영하게 됩니다. 기본값이 Full access이고, 범위 없는 페어링 토큰은 모든 권한을 받습니다. 첫 설정에서 바꿔야 할 것은 모델이나 테마가 아니라 권한입니다.

참고 자료

• pingdotgg/t3code (GitHub, MIT)
• T3 Code 공식 사이트
• T3 Code 권한 모드 문서
• T3 Code 원격 접근 문서
• T3 Code AGENTS.md (구조 설명)

이 주제를 직접 따라가며 배우고 싶다면

코딩 에이전트를 여러 개 굴릴수록 중요한 것은 모델을 바꾸는 일이 아니라, 프로젝트 규칙과 검증 기준을 작업 환경에 묶고 승인 지점을 설계하는 일입니다. Claude Code를 감으로 쓰지 않고 통제된 흐름으로 운영하는 방법을 다루는 강의가 이어집니다.

• 클로드 코드 제대로 사용하기 · 하네스 엔지니어링 강의 보기