Infrastructure as Code(IaC) 가 서버, 네트워크 등 인프라 자원을 코드로 관리하는 개념이라면,
Services as Code(SeC) 는 그보다 한 단계 위 — 서비스 단위의 설정, 정책, 운영 방식을 모두 코드로 정의하고 관리하는 방법론입니다.
쉽게 말해, "우리 서비스가 어떻게 동작해야 하는가"를 코드로 선언해두고, 시스템이 그 선언을 항상 유지하도록 만드는 것입니다.
| 특징 | 설명 |
|---|---|
| 자동화된 확장 | 서비스가 10개든 1,000개든 코드 한 줄로 일괄 정책 적용이 가능합니다. 사람이 일일이 설정하는 게 아니라 코드가 알아서 처리합니다. |
| 가시성 (Observability) | 서비스 간에 데이터가 어떻게 흐르는지 코드를 통해 한눈에 파악할 수 있습니다. 복잡한 마이크로서비스 환경에서 특히 빛을 발합니다. |
| 재현 가능성 | 똑같은 서비스 환경을 다른 지역(Region)에 몇 분 만에 그대로 복제할 수 있습니다. "우리 서버 미국에도 띄워줘"가 코드 몇 줄로 해결됩니다. |
| 자가 치유 (Self-healing) | 설정된 코드와 실제 상태가 다르면 시스템이 알아서 원래 설정으로 되돌립니다. 누군가 실수로 설정을 바꿔도 자동으로 원상복구됩니다. |
과거엔 서버 담당자가 직접 콘솔에 접속해서 하나씩 설정을 바꿨습니다.
이 방식은 규모가 커질수록 문제가 생깁니다:
SeC는 이 모든 문제를 코드로 해결합니다. 코드가 곧 문서이고, 코드가 곧 설정입니다.
"도커로 만들고, 쿠버네티스로 운영한다"
이 한 문장이 현대 클라우드 인프라의 핵심을 담고 있습니다.
도커는 애플리케이션과 그 실행 환경을 컨테이너(Container) 라는 독립된 패키지로 묶어주는 도구입니다.
비유하자면, 도커는 이삿짐 박스입니다.
# 도커 이미지 빌드 (박스 포장)
docker build -t my-app:latest .
# 컨테이너 실행 (박스 개봉 후 사용)
docker run -p 3000:3000 my-app:latest
수십, 수백 개의 컨테이너를 하나하나 사람이 관리하면 어떻게 될까요?
컨테이너가 죽으면 다시 살리고, 트래픽이 몰리면 컨테이너를 늘리고, 업데이트할 땐 순서를 조율하고...
이걸 자동으로 해주는 것이 쿠버네티스입니다.
| 역할 | 설명 |
|---|---|
| 자동 복구 | 컨테이너가 죽으면 즉시 새로 띄웁니다 |
| 자동 스케일링 | 트래픽이 갑자기 늘면 컨테이너 수를 자동으로 늘립니다 |
| 롤링 업데이트 | 서비스 중단 없이 새 버전을 순차적으로 배포합니다 |
| 로드 밸런싱 | 여러 컨테이너에 트래픽을 고르게 분산합니다 |
SeC 관점에서 보면, 쿠버네티스의 설정 파일(YAML)이 바로 "Services as Code"의 실제 구현체입니다.
# 이 YAML 파일 하나가 서비스의 모든 것을 정의합니다
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3 # 컨테이너 3개 항상 유지
selector:
matchLabels:
app: my-app
GSLB는 전 세계 또는 여러 지역(Region)에 분산된 서버들 중, 유저에게 가장 빠르고 안정적인 서버로 접속을 유도하는 지능형 DNS 체계입니다.
사용자가 URL을 입력하면 GSLB는 이런 것들을 고려해서 최적의 서버를 안내합니다:
사용자 (서울) → DNS 질의 → GSLB
→ "서울 IDC가 가장 가깝고 정상이네요"
→ 서울 서버 IP 반환
→ 사용자 ↔ 서울 서버 통신
GSLB가 없다면? 서울 사용자가 뉴욕 서버에 접속할 수도 있고, 장애 난 서버로 계속 요청이 가는 상황이 발생합니다.
CDN은 전 세계 곳곳에 서버를 분산 배치하여, 유저에게 가장 가까운 곳에서 데이터를 빠르게 전달해주는 서비스입니다.
원본 서버가 미국에 있고 한국 사용자가 이미지를 요청한다면?
지구 반 바퀴를 돌아 데이터를 받아와야 합니다. 느릴 수밖에 없습니다.
CDN은 한국 근처 서버에 이미지를 미리 복사(캐싱) 해두고, 한국 사용자가 요청하면 그 가까운 서버에서 즉시 응답합니다.
Before CDN:
한국 사용자 → 미국 서버 (왕복 200ms~)
After CDN:
한국 사용자 → 한국/일본 CDN 엣지 서버 (왕복 20ms~)
| GSLB | CDN | |
|---|---|---|
| 목적 | 어떤 서버로 보낼지 결정 | 콘텐츠를 가장 빠르게 전달 |
| 대상 | 동적 트래픽 포함 전체 | 주로 정적 콘텐츠 |
| 작동 방식 | DNS 레벨 라우팅 | 엣지 서버 캐싱 |
Post-Network & Server Node는 인프라 통합 관리 체계 중 하나로,
외부 인터넷망과 연결된 서버 집합군(서버팜) 구역을 의미합니다.
쉽게 말하면 "우리 회사의 핵심 서버들이 모여 있는 동네"입니다.
수많은 서버들을 한 공간에 모아놓은 시설입니다.
현대적 표현으로는 데이터센터(IDC: Internet Data Center) 라고도 합니다.
[인터넷]
↓
[방화벽 / 게이트웨이] ← 외부와의 경계
↓
[Post-Network & Server Node]
├── 웹 서버들
├── 애플리케이션 서버들
├── DB 서버들
└── 스토리지 (NAS 등)
이 구역에서 나가고 들어오는 트래픽을 중앙에서 관리하고, 보안 정책을 일괄 적용하는 것이 핵심입니다.
NAS는 쉽게 말해 "인터넷(네트워크)에 연결된 외장 하드" 입니다.
| 일반 외장 하드 | NAS | |
|---|---|---|
| 연결 방식 | USB 케이블로 직접 연결 | 네트워크(공유기)에 연결 |
| 접근 방법 | 연결된 PC에서만 | 어디서든 인터넷으로 |
| 동시 접근 | 1대만 가능 | 여러 사람이 동시에 가능 |
| 운영 방식 | PC가 켜져 있어야 함 | 24시간 독립 운영 |
회사 인프라에서 NAS는 단순한 파일 공유를 넘어 다음 역할을 합니다:
클라우드 스토리지(AWS S3 등)와의 차이: NAS는 직접 소유하고 관리하는 온프레미스(On-premise) 스토리지입니다. 초기 비용이 들지만 장기적으로는 더 저렴하고, 데이터가 외부로 나가지 않아 보안에 유리합니다.
오늘 배운 내용을 한 줄로 요약하면:
| 개념 | 한 줄 요약 |
|---|---|
| SeC | 서비스 운영을 코드로 선언하고 자동으로 유지하는 방법론 |
| Docker + k8s | 도커로 앱을 컨테이너에 담고, 쿠버네티스가 그것들을 관리 |
| GSLB | 전 세계 서버 중 최적의 서버로 사용자를 안내하는 지능형 DNS |
| CDN | 전 세계에 콘텐츠를 미리 복사해두어 빠르게 전달하는 서비스 |
| Post-Network & Server Node | 회사의 핵심 서버들이 모여 있는 구역 |
| NAS | 네트워크에 연결된 나만의 클라우드 스토리지 |
인프라 공부는 처음엔 낯선 단어들로 가득하지만, 각 개념이 서로 어떻게 연결되는지 보이기 시작하면 퍼즐 맞추는 재미가 있습니다. 계속 정리해가며 이어가겠습니다!