DEVOCEAN

전체 Tor 출구 릴레이 약 3,000개 가운데 10%가 넘는 333개 출구 노드가 2026년 10월 2일부터 SSH 연결을 가로채고 평문 데이터를 수집하다 적발되었습니다. 공격자는 22번 포트로 유입되는 SSH 연결을 12개의 가로채기 서버로 우회시켰습니다. 여기서 연결을 시도하던 수많은 클라이언트는 "호스트 키가 변경되었습니다"라는 런타임 경고를 무시하고 비밀번호를 입력해 계정 정보를 그대로 넘겨주었습니다.

시스템 장애와 침해 사고는 대개 화려한 공격 기법보다 사소한 경고를 무시하거나, 로컬 디스크와 실행 프로세스를 묵인하는 안일한 인프라 관리에서 발생합니다. CI/CD(지속적 통합 및 배포) 파이프라인에서 빌드 이력이 쌓여 디스크가 가득 차는 순간 배치가 멈추는 일이나, 실기기 테스트 환경에서 특정 디바이스의 응답 지연으로 전체 검증 파이프라인이 멈춰 서는 일도 본질적으로 다르지 않습니다. 상태를 투명하게 격리하지 않고 런타임 환경의 기본 동작에 의존할 때 엔지니어링 조직은 예측할 수 없는 비용을 치릅니다.

오늘 엔지니어링 현장에서 마주한 소식 중 세 가지가 이 문제를 서로 다른 계층에서 다루고 있습니다. 젠킨스 배치 220개를 Temporal로 이전하며 프로세스 상태를 격리한 여정, 실기기 BVT(빌드 검증 테스트) 병목을 풀어낸 테스트 프레임워크 전환기, 그리고 SSH 호스트 키 검증 누락으로 300개가 넘는 Tor 출구 노드가 악용된 보안 사고입니다. 런타임 묵인과 의존성을 걷어내고 명시적인 상태 제어를 확립하는 실무적 해법을 정리합니다.

단일 디스크의 한계: 젠킨스 배치 220개를 템포럴로 전환한 이유

수많은 조직이 배치 작업과 주기적인 워크플로를 관리하기 위해 여전히 Jenkins(젠킨스)를 사용합니다. 설정이 간편하고 플러그인 생태계가 넓기 때문입니다. 하지만 작업 수가 늘어나고 작업 간 의존성이 복잡해지면 단일 서버 기반의 실행 환경은 한계를 드러냅니다.

Jenkins 배치 220개를 Temporal로 옮기며 고민한 것들에 따르면, 배치 작업이 실행되지 않아 점검한 결과 원인은 젠킨스 인스턴스의 디스크 고갈이었습니다. logRotator(빌드 이력 보존 설정) 같은 보정 장치를 두더라도 로그와 빌드 산출물이 급증하거나 외부 API 호출이 멈추면 디스크는 순식간에 잠깁니다. 젠킨스는 워크플로 오케스트레이션 엔진이 아니라 본래 CI 빌드 러너로 설계된 도구이기 때문에, 수백 개의 장기 실행 배치를 추적하고 재시도하는 상태 머신 역할을 감당하기 어렵습니다.

여기서 Temporal(템포럴, 코드 기반의 분산 워크플로 오케스트레이션 엔진)로의 전환이 등장합니다. 템포럴은 워크플로 상태를 로컬 파일 시스템에 저장하지 않습니다. 모든 이벤트 히스토리를 데이터베이스 백엔드(PostgreSQL, Cassandra 등)에 이벤트 소싱 방식으로 영속화합니다. 작업자 노드(Worker)가 디스크 장애나 메모리 부족으로 강제 종료되더라도, 다른 노드가 정확히 멈춘 지점부터 작업을 이어받습니다.

실무에서 배치를 템포럴로 옮길 때 가장 큰 변화는 재시도(Retry) 정책과 멱등성(Idempotency, 연산을 여러 번 실행해도 결과가 달라지지 않는 성질)의 선언적 관리입니다. 쉘 스크립트나 젠킨스 파이프라인 내부에서 try-catch와 슬립(sleep)으로 때우던 복구 로직을 엔진 차원의 정책으로 위임할 수 있습니다.

// Temporal 워크플로 작업 정의 예시
import { proxyActivities } from '@temporalio/workflow';
import type * as activities from './activities';

// 실패 시 지수 백오프(Exponential Backoff)를 적용한 재시도 정책 정의
const { fetchSettlementData, processDailyBatch, notifyTeam } = proxyActivities<typeof activities>({
  startToCloseTimeout: '30 minutes',
  retry: {
    initialInterval: '5 seconds',
    maximumInterval: '1 minute',
    backoffCoefficient: 2,
    maximumAttempts: 5,
    nonRetryableErrorTypes: ['InvalidParameterError'], // 영구적 결함은 재시도 제외
  },
});

export async function DailySettlementWorkflow(batchDate: string): Promise<void> {
  const rawData = await fetchSettlementData(batchDate);
  await processDailyBatch(rawData);
  await notifyTeam(`배치 완료: ${batchDate}`);
}

DEVOTEE의 판단: 배치 수가 100~200개를 넘어가고 재시도 로직과 장애 복구가 중요한 팀이라면 젠킨스 탈피는 지금 써볼 만합니다. 단, 템포럴 클러스터를 자체 운영할 수 있는 인프라 역량이나 관리형 서비스 도입 예산이 전제되어야 합니다. 워크플로 코드 내에 결정론적이지 않은 API 호출(예: Math.random(), 시스템 시간 직접 조회)을 두면 템포럴의 리플레이(Replay) 과정에서 결함이 발생하므로 활동(Activity)과 워크플로 경계를 엄격히 나누는 설계 훈련이 필요합니다.

실기기 병목을 끊어내는 배포 검증 테스트의 분산 실행

백엔드 파이프라인의 상태가 정돈되었다면 그다음 병목은 클라이언트 배포 검증 단계로 넘어옵니다. 모바일 앱과 웹 프론트엔드 배포 직후 수행되는 BVT(Build Verification Test, 새 빌드의 핵심 기능이 정상 동작하는지 확인하는 테스트)는 사용자가 겪을 치명적인 결함을 사전에 차단하는 필수 관문입니다.

빠른 기기가 왜 기다려야 하지?에서는 무신사 Automation QE팀이 테스트 자동화 프레임워크 3.0으로 전환하면서 실기기 검증의 유휴 시간을 없앤 과정을 다룹니다. 앱 빌드나 웹 프론트엔드 배포가 끝날 때마다 실제 모바일 디바이스 팜(Device Farm)에서 실기기 테스트를 실행하고 결과를 Slack과 TMS(Test Management System)로 전송하는 환경을 다룹니다.

과거의 실기기 테스트 파이프라인은 종종 순차 실행이나 고정된 기기 할당 방식에 묶여 있었습니다. 예를 들어 5대의 단말기에 테스트 스위트를 배분했을 때, 최신 고성능 기기가 2분 만에 테스트를 끝마쳐도 저사양 단말기나 네트워크가 지연된 단말기가 10분 동안 실행 중이라면 전체 배포 파이프라인은 대기해야 했습니다. "빠른 기기가 느린 기기를 기다려야 하는" 동기화 병목이 발생한 것입니다.

이를 해결하기 위해서는 테스트 스위트 단위의 정적 분할을 걷어내고, 큐 기반의 동적 태스크 분배(Dynamic Task Dispatching)를 도입해야 합니다. 대기 중인 실기기 노드가 중앙 큐에서 독립된 테스트 시나리오를 하나씩 가져와 실행하고 완료 즉시 다음 시나리오를 당겨오는 풀(Pull) 기반 구조입니다.

여기부터는 DEVOTEE의 해석입니다. 테스트 자동화 프레임워크 3.0 전환의 핵심은 단순히 실행 속도를 올린 것이 아닙니다. 실패한 시나리오만을 선별하여 정상 기기에 재할당하는 '실패 격리성'을 확보한 점입니다. 단말기 자체의 OS 팝업이나 일시적 연결 유실로 인한 결함(Flaky Test)을 파이프라인 전체의 실패로 전파하지 않음으로써, 개발자가 CI 결과를 신뢰할 수 있게 만듭니다.

DEVOTEE의 판단: 실기기 디바이스 팜을 운영 중인 모바일 중심 프로덕트 팀에게 동적 태스크 큐 방식의 테스트 프레임워크 고도화는 지금 써볼 만합니다. 기기별 성능 차이가 큰 안드로이드 생태계와 OS 파편화가 심한 환경일수록 빌드 통과 시간 단축 효과가 명확하게 드러납니다.

10%의 노드가 변조되었을 때: SSH 호스트 키 검증을 묵인한 대가

분산 워크플로와 자동화 테스트 환경을 안정화하더라도, 원격 노드와 클러스터 간의 통신 경계에서 신뢰성을 검증하지 않으면 심각한 침해 사고가 일어납니다.

Tor 출구 노드 300개 이상을 퇴출시킨 과정에 따르면, 10월 2일부터 전체 Tor 출구 노드의 약 10%에 달하는 333개 노드가 감염되어 SSH 트래픽을 탈취했습니다. 공격자는 22번 포트 연결을 악의적인 가로채기 서버로 우회시킨 뒤 중간자 공격(MitM)을 시도했습니다.

이 사고에서 가장 주목해야 할 점은 기술적 우회 기법이 아니라 개발자와 시스템 관리자들의 대응 방식이었습니다. 공격 서버는 당연히 정상 대상 서버의 개인키(Private Key)를 가지고 있지 않았으므로, 클라이언트 터미널에는 "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!"(원격 호스트 식별자가 변경되었습니다)라는 표준 경고 메시지가 출력되었습니다. 하지만 다수의 사용자가 호스트 키 핑거프린트를 교차 확인하지 않고 무심코 연결을 수락했습니다. 그 결과 계정 로그인 자격 증명이 고스란히 공격자에게 평문으로 넘어갔습니다.

자동화 스크립트나 CI/CD 파이프라인에서도 유사한 취약점이 빈번하게 작성됩니다. SSH 접속 시 발생하는 키 확인 프롬프트를 넘기기 위해 엔지니어들이 관습적으로 StrictHostKeyChecking=no 플래그를 넣는 사례입니다.

# 위험한 설정: 호스트 키 불일치 경고를 무시하고 알려지지 않은 호스트를 무조건 신뢰
# 중간자 공격(MitM)에 완전히 무방비 상태가 됩니다.
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@remote-host.internal

# 안전한 설정: 사전 배포된 신뢰 호스트 키 목록만 허용하고, 불일치 시 즉각 접속 차단
ssh -o StrictHostKeyChecking=yes -o UserKnownHostsFile=/etc/ssh/known_hosts_provisioned user@remote-host.internal

원격 인프라 배포 자동화 파이프라인에서 호스트 키 검증을 비활성화하는 것은, 앞서 살펴본 젠킨스의 디스크 고갈 징후를 무시하거나 테스트 실패를 단순히 무시하도록 넘기는 것보다 훨씬 치명적입니다. 외부 프록시, VPN, 또는 오버레이 네트워크를 거쳐 명령을 전달하는 러너(Runner)일수록 호스트 키 핑거프린트의 정적 고정(Pinning)은 보안의 기본 전제입니다.

DEVOTEE의 판단: StrictHostKeyChecking=yes 강제와 중앙 관리형 known_hosts 배포는 조건부로 유효한 것이 아니라 모든 프로덕션 인프라에 즉시 적용해야 할 기본 조치입니다. 자동화 편의를 핑계로 키 검증을 끄는 행위는 네트워크 경로 상의 어떤 중간 노드도 신뢰할 수 없는 분산 환경에서 침해의 문을 직접 열어주는 것과 같습니다.

도입 전 확인할 것: 런타임 제어권 회수를 위한 체크리스트

시스템의 규모가 커질수록 자동화된 파이프라인의 '조용한 실패'는 조직의 엔지니어링 속도를 갉아먹습니다. 오늘 다룬 세 가지 사례는 인프라 런타임의 기본값에 끌려다니지 않고 제어권을 개발자의 선언 영역으로 가져와야 함을 명확히 보여줍니다. 팀의 워크플로를 점검할 때 다음 세 가지 기준을 확인해 보시기 바랍니다.

1. 상태 보존과 프로세스 수명 분리: 현재 운영 중인 배치 파이프라인(Jenkins, Cron 등)이 로컬 파일 시스템의 디스크 용량이나 단일 JVM(자바 가상 머신)의 안정성에 묶여 있지 않습니까? 영속화 계층과 워커 프로세스가 물리적으로 분리되어 있는지 점검해야 합니다.
2. 테스트 큐의 동적 디스패치: 모바일 실기기나 분산 빌드 러너 환경에서 느린 노드 하나 때문에 전체 테스트 단계가 블로킹되고 있지 않습니까? 정적 작업 분할 대신 완료된 노드가 다음 태스크를 능동적으로 가져가는 풀 구조로 전환 가능한지 확인하세요.
3. 원격 호스트 키 검증의 엄격성: CI/CD 배포 스크립트나 관리자 도구 안에 StrictHostKeyChecking=no나 InsecureSkipVerify 같은 검증 무력화 플래그가 하드코딩되어 있지 않은지 리포지토리 전체를 정적 스캔해 보시기 바랍니다.

그 밖의 소식

• MicroG: Google 독점 사용자 공간을 오픈소스로 재구현 — Google Play Services 독점 API를 AOSP 기반 ROM에서 실행할 수 있게 재구현한 자유 소프트웨어 라이브러리입니다.
• 네이버클라우드, 보안 특화 AI 파운데이션 모델 사업 선정 및 자가진단 사이트 오픈 — 에이전트 도입에 따른 보안 점검을 지원하는 자가진단 도구를 공개했습니다.
• OpenIntelligentUI: 오픈소스 대화형 인텔리전트 UI — 텍스트뿐만 아니라 표, 차트, 다이어그램을 상황에 맞춰 동적으로 렌더링하는 UI 프로젝트입니다.
• Voxtral 3: 50개 이상 언어를 지원하는 음성 인식 모델 및 SDK — 음성 전사, 실시간 추론, 도구 호출을 단일 스트리밍 파이프라인으로 묶은 프레임워크입니다.
• 데이터센터 내진·면진·제진 공법의 차이와 내진등급 기준 — 내진등급이 높아도 지진 후 전산 장비 가동은 보장되지 않는다는 물리 인프라 분석입니다.