DEVOCEAN

데이터센터의 냉방 밸브는 전산 제어 신호가 끊어지는 순간 기계식 접점을 물고 버티도록 설계되고 있는 반면, 클라우드 호스팅 서비스에서는 중앙 시스템에 보관해 둔 암호화 환경 변수가 외부 공격자에게 노출되는 일이 벌어졌습니다.

물리 인프라 엔지니어링은 상위 소프트웨어와 제어 네트워크가 완전히 멈추더라도 물리 접점을 유지하는 방어선을 구축하고 있습니다. 반대로 클라우드 배포 환경에서는 편의를 위해 중앙 대시보드에 모아둔 비밀 정보가 한꺼번에 열리는 약점이 노출되었습니다. AI 모델과 워크로드가 커질수록 장애와 침해를 막는 마지막 방어선은 정교한 소프트웨어 로직이 아니라, 외부 제어 실패를 가정한 물리적 상태 보존과 시크릿 격리 구조에서 결정됩니다.

제어 신호가 꺼져도 상태를 유지하는 래칭릴레이

고밀도 인공지능(AI) 랙이 밀집한 데이터센터에서 냉방 장비가 1분만 멈춰도 서버 내부 온도는 한계치에 도달합니다. kt cloud 서동진 님의 분석에 따르면, 전산실 냉방 시스템 장애는 일반적인 전력 차단(정전)뿐만 아니라 PLC(Programmable Logic Controller, 프로그래머블 로직 제어기) 제어 신호의 소실로 인해서도 발생합니다.

일반적인 전자식 릴레이는 코일에 제어 전압이 계속 인가되어야 접점을 유지합니다. 만약 제어 장비인 PLC가 재부팅되거나 제어 버스 루프에 통신 단선이 발생하면 코일의 자력이 사라지고 접점이 열립니다. 이때 모든 냉방 펌프와 팬이 동시에 멈추는 동시 정지 현상이 일어납니다.

이를 방지하기 위해 사용되는 장치가 래칭릴레이(Latching Relay)입니다. 래칭릴레이는 영구 자석이나 기계적 걸쇠 메커니즘을 내장하고 있어, 접점을 켜거나 끌 때만 순간적인 펄스 전류를 소모합니다. 펄스 신호가 끝난 뒤 제어 전원이 끊어지거나 상위 제어기의 신호가 소실되어도 릴레이 접점은 직전 물리 상태를 유지합니다.

원문은 전산 장비의 전원 공급과 제어 신호 라인이 분리된 현대 데이터센터 환경에서 이 접점 유지 원리가 냉방 중단을 막는 방어선으로 동작한다고 설명합니다. 제어 네트워크가 침묵에 빠져도 냉수 밸브와 송풍 설비는 돌던 속도 그대로 동작을 이어갑니다.

이 분석에 대한 DEVOTEE의 판단은 '조건부로 유효하다'입니다. 고밀도 GPU 랙을 운영하는 데이터센터에서 PLC 신호 소실에 대비해 래칭릴레이로 물리 접점을 고정하는 방식은 하드웨어 단의 신뢰성을 확보해 줍니다. 다만 화재나 누수 같은 비상 정지(E-Stop) 상황에서 하드웨어 릴레이를 강제로 릴리스(해제)할 수 있는 이중화 차단 배선과 수동 절체 절차가 마련되어 있어야 합니다. 제어 신호가 끊겨도 설비가 계속 돈다는 특성은 정상 유지 상태에서는 안전장치이지만, 물리적 파손 국면에서는 위험 요인이 될 수 있기 때문입니다.

액체냉각과 모듈화가 요구하는 물리 경계

Tech Week Singapore 2026 현장 소식에서도 AI 데이터센터의 물리 인프라 변화가 보고되었습니다. 공랭식 냉각(공기 순환 방식)으로는 랙당 수십 킬로와트(kW)를 소모하는 고집적 AI 가속기 랙의 발열을 해소하기 어려워지면서, 배관을 칩셋에 직접 연결하는 액체냉각과 모듈형 전력 공급 구조가 현장 중심 기술로 자리 잡았습니다.

액체냉각 시스템은 냉수 분배 장치(CDU, Cooling Distribution Unit)와 펌프 압력, 냉매 유량이 일정하게 유지되어야 냉각 효율이 나옵니다. 상위 제어 스택의 지연이나 소프트웨어 예외로 인해 밸브 구동 신호가 왜곡되면 국소 부위의 냉매 온도가 치솟아 서버 셧다운으로 이어집니다.

여기부터는 DEVOTEE의 해석입니다. 액체냉각과 모듈형 전력 인프라가 결합할 때 시스템 엔지니어가 점검해야 하는 부분은 관제 소프트웨어와 물리 하드웨어의 결합도입니다. 소프트웨어 제어 계층은 최적화와 계측을 담당하고, 실제 냉매 순환과 밸브 구동은 상위 네트워크 단선 시에도 직전 유량을 강제로 밀어붙이는 기계식 보존 장비에 맡겨져야 합니다.

Tech Week Singapore 2026에서 논의된 모듈형 설계와 액체냉각 기술에 대한 DEVOTEE의 판단은 '지금 써볼 만하다'입니다. 랙당 전력 밀도가 40kW 이상으로 올라가는 고밀도 AI 연산 클러스터를 준비 중인 팀이라면 기존 공랭 덕트 확장보다 액체냉각 모듈을 검토하는 것이 불가피합니다. 단, 시설(Facility) 전력과 냉각 설비 배관 제어에 투입되는 엔지니어링 역량이 확보되지 않은 상태에서 무리하게 시설 전환을 감행하면 배관 누수와 접점 제어 결함이라는 이중 부담을 안게 됩니다.

클라우드 중앙 대시보드에 보관한 환경 변수의 누출

물리 인프라가 제어 실패에 대비해 접점을 보존하는 설계를 강화하는 반면, 애플리케이션 배포 계층에서는 정반대로 중앙화된 저장 방식의 허점이 노출되었습니다.

Railway의 보안 사고 공개 내용에 따르면, 고객 환경 변수를 저장하는 내부 시스템에서 비정상 활동이 탐지되었습니다. 조사 결과 인가받지 않은 제3자가 암호화된 상태의 고객 환경 변수 데이터베이스에 접근했으며, 일부 환경 변수는 복호화된 내용까지 확보되었을 가능성이 확인되었습니다.

노출된 환경 변수에는 서드파티 API 키, 데이터베이스 접속 자격 증명, 프라이빗 컨테이너 레지스트리 토큰 등 서비스 운영에 필요한 비밀 정보가 다수 포함되어 있었습니다. 개발자가 편의를 위해 PaaS(Platform as a Service) 콘솔의 환경 변수 입력창에 기입해 둔 설정 값들이 한꺼번에 외부로 노출될 위험에 처한 것입니다.

이 사고가 보여주는 문제는 PaaS 플랫폼이 제공하는 저장소에 암호화된 시크릿을 한곳에 모아두는 모델의 취약점입니다. 플랫폼 자체 계정이 침해되거나 내부 복호화 키 관리 계층에 이상이 생기면, 개별 애플리케이션의 격리 수준과 상관없이 인프라 전체의 기밀 정보가 동시에 열립니다.

Railway 보안 사고에 대한 DEVOTEE의 판단은 '지금 즉시 조치가 필요한 사안'입니다. PaaS 대시보드에 데이터베이스 마스터 패스워드나 결제 API 시크릿을 평문 환경 변수 형태로 등록해 두는 관행을 중단해야 합니다. 플랫폼 내부 저장소는 언제든 접근 침해가 발생할 수 있다는 전제 아래, 시크릿 관리와 호스팅 런타임을 논리적으로 분리해야 합니다.

시크릿 주입 파이프라인의 격리와 단절 대응

Railway 사고와 같은 위험을 줄이기 위해 실무에서는 배포 플랫폼의 환경 변수 관리 기능에만 의존하지 않고, 독립된 비밀 관리 시스템을 런타임에 직접 연결하는 구조를 택합니다.

아래 코드는 애플리케이션 부트스트랩 시점에 플랫폼 환경 변수 대신 전용 시크릿 관리 서비스로부터 임시 자격 증명을 직접 받아오는 격리 예시입니다. 배포 플랫폼 콘솔에는 비밀 값 본체가 아니라 오직 시크릿 저장소에 일회성으로 접근할 수 있는 토큰 교환 키만 남겨둡니다.

import { createHmac } from 'crypto';

interface SecretPayload {
  databaseUrl: string;
  externalApiKey: string;
}

// 플랫폼 대시보드에는 장기 비밀 값 대신 시크릿 저장소 접속용 단기 식별자만 보관합니다.
const SECRET_MANAGER_ENDPOINT = process.env.SECRET_MANAGER_URL || 'https://example.com/api/v1/secrets';
const CLIENT_IDENTITY = process.env.SERVICE_IDENTITY_TOKEN;

export async function resolveApplicationSecrets(): Promise<SecretPayload> {
  if (!CLIENT_IDENTITY) {
    throw new Error('SERVICE_IDENTITY_TOKEN이 정의되지 않았습니다. 런타임 자격 증명을 로드할 수 없습니다.');
  }

  // 플랫폼 환경 변수에 저장된 마스터 암호 대신 원격 전용 저장소에 런타임 조회를 수행합니다.
  const response = await fetch(`${SECRET_MANAGER_ENDPOINT}/runtime-context`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'X-Client-Identity': CLIENT_IDENTITY,
    },
    body: JSON.stringify({
      requestTimestamp: Date.now(),
    }),
  });

  if (!response.ok) {
    // 시크릿 로드 실패 시 애플리케이션을 안전하게 중단하고 침묵 실패를 방지합니다.
    throw new Error(`시크릿 조회 실패: HTTP 상태 코드 ${response.status}`);
  }

  const payload = (await response.json()) as SecretPayload;
  return payload;
}

이와 같은 런타임 주입 구조를 구축하면 배포 호스팅 서비스의 메타데이터 데이터베이스가 침해되더라도 공격자가 확보할 수 있는 정보는 만료 주기가 짧은 단기 식별자에 그칩니다.

물리 데이터센터의 래칭릴레이가 '상위 제어 네트워크 단선'이라는 최악의 상태를 가정하고 기계 접점을 고정하듯, 소프트웨어 보안 아키텍처 역시 'PaaS 플랫폼 환경 변수 저장소의 유출'을 전제하고 자격 증명 조회 통로를 분리해야 합니다.

도입 전 확인할 세 가지 점검 항목

인프라의 물리적 안정성과 외부 배포 보안을 점검하고자 하는 엔지니어링 팀은 다음 세 가지 조건을 먼저 검토해야 합니다.

1. 냉각 제어 상실 시 릴레이 동작 상태: 사내 또는 위탁 데이터센터의 PLC 전원 리셋 시 송풍 밸브와 펌프 구동 접점이 즉시 단선(NC/NO 기본값 복귀)되는지, 래칭릴레이를 통해 기계적으로 회전 상태를 유지하도록 설계되어 있는지 설비 팀과 함께 회로도를 확인합니다.
2. PaaS 환경 변수 보관 시크릿 전수 점검: 호스팅 플랫폼 대시보드의 .env 설정에 결제 키, AWS IAM 영구 시크릿, 데이터베이스 루트 비밀번호가 평문으로 등록되어 있는지 전수 조사하고, 이를 키 롤링(교체) 대상에 포함합니다.
3. 독립된 시크릿 저장소와 런타임 토큰 분리: 배포 플랫폼과 비밀 정보 저장소를 단일 계정 체계로 묶지 말고, 플랫폼 침해 시에도 즉시 무효화할 수 있는 짧은 수명의 토큰 기반 시크릿 조회 파이프라인으로 전환할 수 있는지 검토합니다.

그 밖의 소식

• OpenAI 모델과 Codex, Google Cloud 도입 — geeknews
• Show HN: VoidAccess - 검색 질의에서 그래프까지, 오픈소스 다크웹 OSINT — geeknews
• 모델보다 먼저 고민한 데이터 — velopers
• Claude Duet - 업무를 맡아 처리하고 필요할 때 먼저 연락하는 개인 AI 에이전트 — geeknews
• LLM 추론 칩 검증 이야기 1편: 칩의 정답은 어디서 오는가 — hyper-accel