Cleric이 tsnet을 사용하여 소프트웨어 작업을 안전하게 자동화하는 방법

Source: Tailscale Blog

번역할 텍스트를 제공해 주시면, 요청하신 대로 한국어로 번역해 드리겠습니다.

Cleric – 자율 AI 사이트 신뢰성 엔지니어 (SRE)

Cleric은 첫 번째 자율 AI SRE를 구축하여 소프트웨어 운영의 무거운 작업을 처리하고 있습니다. 우리의 AI는:

• 사고 조사
• 알림 분류
• 프로덕션 컨텍스트 캡처

이를 통해 엔지니어링 팀은 개발에 집중할 수 있고, AI가 운영상의 반복 작업을 담당합니다.

핵심 과제

효과적인 AI SRE는 인간 엔지니어가 접근할 수 있는 동일한 내부 도구, 데이터베이스 및 텔레메트리 제공자에 쿼리할 수 있어야 합니다. 주요 아키텍처 질문은 다음과 같습니다:

고객의 사설 리소스에 대한 안전하고 저지연 접근을 제공하면서, 고객의 플랫폼 및 보안 팀에 과도한 부담을 주지 않으려면 어떻게 해야 할까?

우리의 솔루션

우리는 Tailscale과 그 tsnet 라이브러리를 활용하여 보안 연결 계층을 만듭니다. 이 계층은:

• 고객이 쉽게 통합할 수 있음
• 우리에게 최소한의 운영 오버헤드만 요구함

Tailscale의 제로 트러스트 네트워킹과 가벼운 tsnet 클라이언트를 사용함으로써, AI SRE가 필요한 접근 권한을 확보하면서도 강력한 보안 보장을 유지합니다.

연결성 문제 {#the-connectivity-problem}

우리 고객들의 환경은 운영하는 서비스만큼이나 다양합니다. 우리는 다음과 같은 경우들을 모두 접합니다:

• AWS‑only shops – 엄격한 VPC 요구사항을 가진 경우
• Identity‑perimeter setups – 모든 서비스가 IdP를 통해 인증되는 경우
• VPN‑dependent environments – 내부 접근을 위해 터널이 필요한 경우
• Multi‑cloud architectures – 복잡한 피어링 모델에 의존하는 경우

Cleric의 연결 레이어를 구축할 때, 우리는 세 가지 절대 타협할 수 없는 원칙을 정의했습니다:

1. Security – 최소 권한 원칙을 따릅니다. 고객이 명시적으로 허용하지 않은 네트워크 엔드포인트에 절대 접근해서는 안 됩니다.
2. Ease of Use – 고객이 Cleric을 시험해 보기 위해 라우팅 테이블을 설정하고 보안 검토를 몇 주 동안 진행해야 한다면, 우리는 이미 고객을 잃은 것입니다.
3. Scalability – 개별 고객마다 고유하고 맞춤형 네트워킹 스택을 유지할 수 없습니다.

왜 전통적인 방법이 부족한가

Tailscale을 선택하기 전에, 사설 인프라에 연결하는 “표준” 방식을 평가했습니다. 각 옵션마다 결국 받아들일 수 없는 트레이드‑오프가 있었습니다.

리버스 프록시

고객에게 인증된 리버스 프록시를 설정해 특정 내부 엔드포인트를 우리 에이전트에 노출하도록 요청할 수 있었습니다. 겉보기엔 합리적으로 보이지만, 실제로는 모든 관계자에게 악몽이 됩니다:

• 고객에 미치는 영향 – 유지해야 할 추가 인프라와 높은 마찰을 가진 보안 검토.
• 우리에게 미치는 영향 – 각 고객의 프록시 구성에 맞춘 맞춤 로직을 유지해야 하므로 “구현 부채”가 발생합니다.

클라우드‑네이티브 연결 (VPC 피어링 & PrivateLink)

AWS VPC 피어링이나 Azure VNet 피어링과 같은 솔루션은 견고하지만, 상당한 조정이 필요합니다:

• CIDR 블록이 겹치지 않도록 해야 합니다.
• 라우팅 테이블을 수동으로 업데이트해야 합니다.
• 교차 계정 권한을 부여해야 합니다.

멀티‑클라우드 제공업체로서, 공급자별 연결 메커니즘이 뒤섞인 이질적인 구성을 관리하는 것은 우리 팀에게 곧 운영 병목이 될 것입니다.

Tailscale로 개인 오버레이 구축하기 {#building-a-private-overlay-with-tailscale}

우리는 실제로 필요한 것이 고객 네트워크에 대한 직접 연결이 아니라 프라이빗하고 프로그래머블한 오버레이 네트워크라는 것을 깨달았습니다.
노출되는 엔드포인트를 정확히 제어하고, 고객 기존 네트워크 구성에 아무런 변경도 가하지 않기를 원했습니다.

Tailscale는 완벽한 기반을 제공했습니다. Tailscale의 WireGuard™ 기반 메쉬를 사용하면 에이전트와 고객 리소스 간에 위치에 관계없이 암호화된 피어‑투‑피어 연결을 설정할 수 있습니다.

우리에게 큰 전환점이 된 것은 tsnet, 즉 Tailscale을 Go 바이너리 안에 직접 임베드할 수 있게 해 주는 Tailscale 라이브러리였습니다.

작동 원리: 네트워크 가상화 {#how-it-works-virtualizing-the-network}

고객에게 게이트웨이나 바스천 호스트에 VPN 클라이언트를 설치하도록 요구하는 대신, 우리는 간단한 바이너리 또는 Helm 차트를 제공합니다. 이 Cleric Connector는 Tailscale tailnet 상의 장치(또는 여러 장치) 역할을 합니다.

구현 개요

• 엔드포인트 모델링 – 각 고객 리소스(데이터베이스, Prometheus 인스턴스 등)를 내부 아키텍처 내에서 별개의 “디바이스”로 모델링합니다.
• tsnet 장점 – tsnet을 사용해 이러한 디바이스들을 하나의 프로세스로 가상화합니다. 에이전트는 복잡한 서브넷 구조 대신, 권한이 부여된 서비스들의 평탄하고 안전한 네임스페이스를 보게 됩니다.
• Zero‑config 배포 – 고객 입장에서는 “드롭‑인” 방식입니다. 고객은 노출하고자 하는 내부 엔드포인트 목록을 Connector에 제공하면, Tailscale이 NAT 트래버설과 암호화 터널링을 자동으로 처리합니다. 방화벽 구멍도, 공용 IP도, 라우팅 테이블 관리도 필요 없습니다.

설계 단계의 보안: 바스천을 넘어 {#security-by-design-beyond-the-bastion}

이 모델의 가장 큰 장점 중 하나는 기존 VPN이 갖는 “전부 혹은 전무” 함정을 피한다는 점입니다.

전통적인 VPN이나 바스천 호스트 모델에서는 “내부”에 들어가면 사설 네트워크 전체에 대한 가시성이 넓게 제공됩니다. 내부 방화벽 규칙이 잘못 설정되면 외부 에이전트가 해당 서브넷의 모든 리소스에 접근할 수 있게 됩니다.

Cleric + Tailscale 모델에서는 측면 이동이 불가능합니다:

• 각 엔드포인트는 고유한 디바이스입니다.
• 에이전트는 명시적으로 접근 권한이 부여된 엔드포인트만 볼 수 있습니다.
• IP 범위가 아니라 정체성을 기반으로 연결합니다.

Connector에 명시적으로 설정되지 않은 리소스는 Cleric 에이전트 입장에서 존재하지 않는 것입니다.

보안 팀 입장에서는 이 모델이 매우 감사하기 쉬운 구조를 제공합니다: Connector에 설정된 엔드포인트 목록만 검토하면 됩니다. Cleric은 그 목록에 없는 프라이빗 엔드포인트에 전혀 접근할 수 없습니다.

The Result {#the-result}

Tailscale을 기반으로 구축함으로써 복잡한 인프라 장벽을 경쟁력으로 바꾸었습니다. 이 솔루션은 현재 몇 달 동안 운영 중이며, 가치 실현 시간을 크게 단축시켰으며, 경우에 따라 몇 주에 달하던 프로세스 시간을 없앴습니다.

우리는 네트워크 토폴로지에 대한 고민을 멈추고, 우리가 가장 잘하는 일에 집중하고 있습니다: 자율 운영의 미래를 구축하는 것.