gitlab·2026년 2월 26일원문

클로드와 함께하는 GitLab Duo Agent 플랫폼이 개발을 가속화합니다 (새 탭에서 열림)

GitLab Duo Agent Platform은 Anthropic의 Claude와 같은 외부 AI 모델을 GitLab 워크플로우에 직접 통합하여 소프트웨어 개발 전 과정을 자동화합니다. 기존 AI 도구들이 개발 워크플로우와 분리되어 발생했던 맥락 단절 문제를 해결하고, 프로젝트의 요구사항을 깊이 이해하여 코드 생성부터 파이프라인 구축까지 복잡한 다단계 작업을 자율적으로 수행합니다. 이를 통해 팀은 개발 속도를 획기적으로 높이는 동시에 코드의 일관성과 보안을 유지할 수 있는 강력한 협업 환경을 구축하게 됩니다. ### 아이디어에서 코드로의 전환 (From Idea to Code) * 프로젝트 이슈에 기재된 사양과 설명을 기반으로 외부 에이전트가 애플리케이션 개발 전체 프로세스를 주도합니다. * 에이전트는 프로젝트의 맥락을 분석하여 풀스택 Java 웹 애플리케이션, 비즈니스 로직, UI 컴포넌트를 생성하고 리뷰 준비가 완료된 병합 요청(Merge Request)을 자동으로 생성합니다. * 백엔드 Java 클래스, 프론트엔드 HTML/CSS/JS, 빌드 구성 파일이 포함된 결과물을 제공하며, 개발자는 자연어 대화를 통해 이를 즉시 테스트하고 반복적으로 개선할 수 있습니다. ### 자동화된 지능형 코드 리뷰 (Code Review) * 병합 요청 단계에서 에이전트를 호출하여 코드의 강점, 취약점, 우선순위별 개선 사항을 포함한 종합적인 분석 보고서를 제공받을 수 있습니다. * 보안 평가, 테스트 노트, 코드 메트릭 및 승인 상태 권장 사항을 포함하여 시니어 개발자가 아키텍처 결정과 같은 고차원적인 작업에 집중할 수 있도록 돕습니다. * 일관된 리뷰 기준을 적용함으로써 운영 환경에 배포되기 전 잠재적인 오류를 선제적으로 차단합니다. ### CI/CD 파이프라인 및 컨테이너화 자동화 (Pipeline Creation) * 배포 자동화가 설정되지 않은 환경에서 에이전트에게 요청하여 완전한 형태의 CI/CD 파이프라인 구성을 생성할 수 있습니다. * 프로젝트의 Java 버전에 최적화된 Dockerfile을 생성하고, GitLab 컨테이너 레지스트리에 이미지를 빌드 및 배포하는 단계를 자동으로 구성합니다. * 수동 설정 없이도 빌드, 이미지 생성, 레지스트리 푸시 단계가 포함된 파이프라인이 즉시 가동되어 배포 효율성을 극대화합니다. GitLab Duo Agent Platform은 AI를 단순한 보조 도구가 아닌, 조직의 표준을 준수하고 자율적으로 업무를 완수하는 '신뢰할 수 있는 협업자'로 격상시킵니다. 반복적인 수동 작업을 줄이고 개발 사이클 전반의 지능형 자동화를 구현하고자 하는 팀에게 이 플랫폼은 생산성 혁신을 위한 핵심적인 솔루션이 될 것입니다.

Docker & 컨테이너머신러닝CI/CD코드 리뷰+4

gitlab·2026년 2월 25일원문

GitLab 메트릭스 및 레지스트리 기능이 CI/CD 병목 현상을 줄이는 데 도움을 줍니다. (새 탭에서 열림)

GitLab이 새롭게 선보이는 CI/CD 작업 성능 메트릭과 컨테이너 가상 레지스트리 기능은 개발 및 운영 팀이 직면한 인프라 복잡성과 파이프라인 병목 현상을 직접 해결하는 데 중점을 둡니다. 별도의 타사 도구 없이도 GitLab 내부에서 작업별 성능 데이터를 분석하고 여러 외부 소스의 컨테이너 이미지를 통합 관리 및 캐싱함으로써, 전체적인 개발 워크플로우의 속도와 안정성을 동시에 개선할 수 있습니다. ## CI/CD 작업 성능 메트릭을 통한 병목 지점 시각화 그동안 파이프라인의 성능 저하나 실패 원인을 파악하기 위해 별도의 대시보드를 구축하거나 로그를 수동으로 분석해야 했던 번거로움이 해결되었습니다. * **성능 지표 제공**: 각 작업(Job)별로 중앙값(P50) 및 최악의 케이스(P95) 실행 시간을 제공하여, 평상시 속도와 비정상적으로 느려진 시점을 명확히 구분할 수 있습니다. * **실패율 추적**: 특정 작업의 실패 빈도를 파악하여 불안정한(flaky) 작업을 식별하고 파이프라인의 신뢰도를 높일 수 있습니다. * **통합 분석 대시보드**: 프로젝트 수준의 CI/CD 분석 페이지에서 지난 30일간의 데이터를 기반으로 작업 이름, 단계(Stage)별 정렬 및 검색이 가능합니다. * **기술적 요구사항**: GitLab Premium 및 Ultimate 티어에서 사용 가능하며, 셀프 호스팅 환경의 경우 ClickHouse가 구성되어 있어야 합니다. 향후 빌드, 테스트, 배포 단계별 그룹화 기능이 추가될 예정입니다. ## 컨테이너 가상 레지스트리를 활용한 이미지 관리 최적화 Docker Hub, Harbor, Quay 등 여러 레지스트리에 흩어져 있는 이미지를 개별적으로 관리하며 발생하는 인증 및 대역폭 비용 문제를 단일 엔드포인트를 통해 해결합니다. * **단일 엔드포인트 통합**: 여러 업스트림 레지스트리를 하나의 GitLab 가상 레지스트리 주소로 통합하여, 파이프라인 설정에서 번거로운 개별 인증 과정을 줄일 수 있습니다. * **풀스루 캐싱(Pull-through Caching)**: 첫 번째 호출 이후 이미지를 GitLab 내부에 캐싱하여 외부 네트워크 대역폭 비용을 절감하고 이미지 풀 속도를 향상합니다. * **지원 범위**: 현재 Docker Hub, Harbor, Quay 등 장기 토큰 인증을 사용하는 레지스트리를 지원하며, 향후 AWS ECR이나 Google Artifact Registry 같은 클라우드 기반 레지스트리로 확장될 계획입니다. * **운영 방식**: GitLab 18.9 버전부터 API를 통해 설정 가능하며, SaaS 사용자는 기능 플래그 활성화를 통해 베타 버전에 참여할 수 있습니다. 성능 저하로 고민하는 플랫폼 팀이라면 이번 베타 기능을 통해 파이프라인의 병목 구간을 우선적으로 점검해 보길 권장합니다. 특히 여러 외부 레지스트리를 혼용하는 환경에서는 가상 레지스트리를 도입함으로써 관리 포인트를 일원화하고 대역폭 비용을 효과적으로 줄일 수 있습니다. 해당 기능들은 커뮤니티 피드백을 바탕으로 개선되고 있으므로, 실제 도입 후 개선 제안을 공유하는 것도 좋은 방법입니다.

Docker & 컨테이너CI/CDgitlabDevOps+4

datadog·2026년 2월 18일원문

Agent Go 바이너리 크기를 최대 77% 줄인 방법 (새 탭에서 열림)

Datadog은 에이전트 바이너리 크기가 5년 사이 3배 이상 비대해진 문제를 해결하기 위해, 기능 삭제 없이 Go 바이너리 크기를 최대 77% 줄이는 성과를 거두었습니다. 이들은 체계적인 의존성 감사, 코드 리팩토링, 링커 최적화 복원을 통해 1.22 GiB에 달하던 아티팩트를 5년 전 수준으로 되돌렸으며, 이 과정에서 발견한 Go 컴파일러의 특성을 활용해 Kubernetes 등 다른 대규모 오픈소스 프로젝트에도 기여했습니다. ### 데이터독 에이전트의 빌드 구조와 비대화 문제 * 데이터독 에이전트는 단일 제품처럼 보이지만, 실제로는 OS, 아키텍처, 환경(Docker, K8s, IoT 등)에 따라 수십 개의 서로 다른 빌드 구성을 가집니다. * 수백 개의 외부 라이브러리(Cloud SDK, 컨테이너 런타임 등)를 사용하며, Go 빌드 태그와 의존성 주입(Dependency Injection)을 통해 기능을 제어합니다. * 5년간의 기능 추가로 인해 Linux amd64 패키지의 압축 전 크기가 428MiB에서 1,248MiB로 약 192% 증가했으며, 이는 네트워크 비용 상승과 서버리스/IoT 환경에서의 사용 제약을 초래했습니다. ### Go 의존성 제거를 위한 전략적 접근 * **컴파일러의 패키지 처리 이해**: Go 컴파일러는 패키지 단위로 동작하며, 빌드 제약 조건에 맞는 파일 내에서 `main` 패키지로부터 전역적으로 도달 가능한(reachable) 모든 임포트를 포함합니다. * **빌드 태그 활용**: 불필요한 의존성을 포함하는 파일에 특정 빌드 태그(`//go:build`)를 추가하여, 해당 기능이 필요 없는 빌드에서는 컴파일 단계부터 제외되도록 구성했습니다. * **심볼 분리 및 리팩토링**: 무거운 의존성을 사용하는 특정 함수나 심볼을 별도의 패키지로 격리했습니다. 이를 통해 해당 기능이 꼭 필요한 바이너리에서만 해당 패키지를 임포트하도록 구조를 개선했습니다. ### 바이너리 분석 및 시각화 도구 활용 * **`go list`**: 특정 OS와 아키텍처, 빌드 태그 조합에서 포함되는 패키지 목록을 추출하여 의존성 현황을 파악했습니다. * **`goda`**: 패키지 임포트 관계를 그래프로 시각화하여, 특정 무거운 패키지가 어떤 경로를 통해 바이너리에 포함되었는지 추적했습니다. * **`go-size-analyzer`**: 바이너리 내부에서 각 의존성 패키지가 차지하는 실제 바이트 크기를 텍스트나 인터팩티브 웹 화면으로 분석하여 최적화 우선순위를 정했습니다. * **링커의 한계 파악**: 단순 임포트만으로도 `init` 함수 실행이나 전역 변수 초기화가 발생하여 링커가 해당 코드를 제거하지 못하는 경우가 있음을 확인하고 이를 관리했습니다. 대규모 Go 프로젝트에서 바이너리 크기를 줄이려면 단순한 코드 최적화를 넘어, `goda`나 `go-size-analyzer` 같은 도구로 의존성 그래프를 분석하고 빌드 태그를 활용해 패키지 간의 결합도를 낮추는 아키텍처적 접근이 필수적입니다. 특히 사용하지 않는 기능이 `init` 함수나 리플렉션(reflection)으로 인해 링커 최적화를 방해하지 않도록 주의 깊게 설계해야 합니다.

Docker & 컨테이너쿠버네티스Godependency-injection+4

gitlab·2026년 1월 14일원문

GitLab Duo Agentic Chat 시작하기 (새 탭에서 열림)

GitLab Duo Agentic Chat은 단순한 질의응답을 넘어 소프트웨어 개발 수명 주기(SDLC) 전반에서 능동적으로 작업을 수행하는 자율형 AI 협업 파트너입니다. 이 플랫폼은 코드 수정, 병합 요청(MR) 생성, 보안 취약점 해결 등 실질적인 액션을 실행하며, 프로젝트의 컨텍스트를 완벽히 이해하여 개발자의 생산성을 극대화합니다. 사용자는 웹 UI와 IDE 내에서 최적화된 모델과 전용 에이전트를 선택함으로써 복잡한 워크플로우를 자동화하고 고품질의 소프트웨어를 빠르게 배포할 수 있습니다. **자율적인 AI 협업 파트너의 핵심 역량** * **능동적 작업 수행:** 질문에 답하는 수준을 넘어 파일을 생성 및 수정하고, 이슈를 트리아지(Triage)하거나 CI/CD 파이프라인의 오류를 직접 해결합니다. * **맥락 인식 능력:** 대화 기록은 물론 프로젝트 아키텍처, 코드베이스, 위키, GitLab 문서 및 보안 스캔 결과까지 광범위한 컨텍스트를 활용합니다. * **확장성 및 통합:** Model Context Protocol(MCP)을 통해 외부 서비스와 통합할 수 있으며, 목적에 따라 전문화된 멀티 에이전트 시스템을 지원합니다. **작업별 최적화를 위한 모델 및 에이전트 선택** * **유연한 모델 구성:** 대규모 언어 모델(LLM)마다 강점이 다르므로 작업 요구사항에 따라 적절한 모델을 선택할 수 있으며, 이는 그룹 또는 사용자 단위로 설정 가능합니다. * **전용 에이전트 활용:** 제품 관리를 위한 'Planner Agent', 보안 분석을 위한 'Security Analyst Agent' 등 특정 도메인에 특화된 에이전트로 전환하여 전문적인 도움을 받을 수 있습니다. * **간편한 접근성:** 웹 UI의 사이드바나 IDE 내의 드롭다운 메뉴를 통해 작업 흐름을 끊지 않고 에이전트와 모델을 즉시 변경할 수 있습니다. **실무 생산성 향상을 위한 주요 활용 사례** * **이슈 및 보안 관리:** 특정 라벨이 지정된 이슈 목록 추출, 에픽(Epic)의 세부 작업 분할, 보안 취약점 분석 및 이를 해결하기 위한 자동 수정 MR 생성이 가능합니다. * **코드 이해 및 온보딩:** 복잡한 코드베이스의 아키텍처 개요 파악, 특정 함수의 호출 위치 검색, 신규 팀원을 위한 로컬 개발 환경 설정 안내 등을 수행합니다. * **디버깅 및 품질 개선:** 실패한 파이프라인 로그를 분석해 원인을 진단하고, 기존 코드를 SOLID 원칙에 맞춰 리팩토링하거나 최신 프로그래밍 언어 버전으로 변환하는 작업을 지원합니다. * **기능 구현 및 테스트:** REST API 엔드포인트 생성, 유닛 테스트 코드 자동 생성, UI 구성 요소의 접근성 검토 등 개발 전 과정을 보조합니다. GitLab Duo Agentic Chat의 잠재력을 최대한 끌어내기 위해서는 작업의 성격에 맞는 전용 에이전트를 선택하는 것이 가장 중요합니다. 보안 분석이나 기획 단계 등 정밀한 컨텍스트가 필요한 작업일수록 일반 채팅보다는 특화된 에이전트를 활용할 것을 권장하며, 향후 출시될 CLI 지원을 통해 터미널 환경에서도 동일한 AI 협업 경험을 확장해 나갈 수 있습니다.

Docker & 컨테이너데이터베이스 설계AI 에이전트CI/CD+4

datadog·2025년 8월 12일원문

규모를 줄여 100배 향상한 실시간 프로세스 메트릭 효율성 (새 탭에서 열림)

Datadog은 프로세스 및 컨테이너 모니터링 시스템의 실시간 데이터 처리 방식을 '호스트 구독(Host Subscription)' 기반 모델로 전환하여 확장성 문제를 해결했습니다. 사용자가 현재 화면에서 보고 있는 특정 호스트(최대 50개)에 대해서만 2초 간격의 고빈도 수집을 활성화함으로써, 전체 트래픽 볼륨을 100배 줄이고 인프라 비용을 98% 절감하는 성과를 거두었습니다. 이 글은 불필요한 데이터 수집을 최소화하면서도 사용자 경험과 시스템 효율성을 동시에 개선한 기술적 여정을 다룹니다. ## 기존 실시간 데이터 수집의 한계 * **전체 활성화 방식의 비효율성:** 기존에는 테넌트 내 한 명의 사용자만 페이지를 조회해도 해당 테넌트 전체 인프라의 모든 호스트에서 2초 간격의 데이터 수집이 시작되었습니다. 이로 인해 초당 수백만 개의 프로세스 데이터가 유입되는 부하가 발생했습니다. * **수평적 확장 불가능:** 실시간 정렬 기능을 제공하기 위해 테넌트의 모든 데이터를 단일 서버의 메모리에 보관해야 했습니다. 이는 시스템을 수평적으로 확장하는 것을 불가능하게 만들었으며, 서버 사양을 높이는 수직적 확장에만 의존하게 했습니다. * **리소스 낭비:** 실제 사용자가 한 번에 확인하는 프로세스는 약 50개 내외임에도 불구하고, 보이지 않는 수만 개의 프로세스 데이터를 실시간으로 수집하고 처리하는 비효율이 존재했습니다. ## 사용자 가시성 중심의 설계 전환 * **실시간 수집 대상의 최소화:** 사용자가 보고 있는 화면에 노출된 프로세스가 실행 중인 호스트에 대해서만 실시간 모드를 활성화하도록 전략을 수정했습니다. * **데이터 용도 분리 및 정렬 로직 최적화:** 2초 간격의 실시간 데이터는 화면 갱신에만 사용하고, 10초마다 수행되는 정렬 작업에는 일반적인 10초 간격 데이터를 활용하도록 변경했습니다. * **시스템 단순화:** 실시간 뷰와 히스토리 뷰에서 동일한 정렬 로직을 사용할 수 있게 되어 시스템 복잡성이 줄어들었고, 고빈도 메트릭을 메모리에 상주시켜야 할 필요성도 사라졌습니다. ## 호스트 구독 모델 및 필터링 최적화 * **호스트 구독(Host Subscription) 도입:** 사용자가 현재 보고 있는 호스트 목록을 추적하고, 이 상태를 Kafka를 통해 인테이크(Intake) 서비스와 라이브 서버 간에 공유합니다. * **조기 필터링(Early Filtering):** 구독 정보를 바탕으로 데이터 수집 단계(Intake)에서부터 필요한 데이터만 선별하여 처리합니다. 이는 Datadog 에이전트와 백엔드 서버 모두의 부하를 줄이는 핵심 기여를 했습니다. * **성능 개선 결과:** 개념 증명(PoC) 단계에서 이미 라이브 데이터 서버의 메모리 사용량은 85%, CPU 사용량은 33% 감소했으며, 이는 시스템 전체의 안정성 향상으로 이어졌습니다. 대규모 인프라 모니터링 환경에서 모든 데이터를 실시간으로 수집하는 것은 막대한 비용과 확장성 문제를 야기합니다. 사용자의 가시성 범위 내로 수집 대상을 제한하고 데이터의 용도(갱신 vs 정렬)에 따라 수집 빈도를 이원화하는 접근 방식은 리소스 효율성을 극대화하면서도 고성능 실시간 뷰를 제공할 수 있는 실용적인 해결책이 됩니다.

Docker & 컨테이너데이터베이스 설계datadogApache Kafka+4

figma·2024년 8월 7일·4분 읽기큐레이션 요약

12개월 이내에 K8

Figma는 ECS에서 Kubernetes(EKS)로 이전해 플랫폼의 기능과 확장성을 높이기로 결정했고, 핵심 서비스 대부분을 12개월 이내에 안전하게 옮겼습니다. ECS의 StatefulSet·Helm 지원 부족과 운영상의 불편, CNCF 생태계 활용 한계가 주요 전환 이유였습니다. 특히 Figma는 수천 개의 마이크로서비스를 운영하는 구조가 아니었기 때문에 대규모 마이그레이션의 범위를 현실적으로 통제할 수 있었습니다. ## 기존 Figma의 컴퓨트 플랫폼 - 2023년 초 Figma의 모든 서비스는 이미 컨테이너화되어 있었고, AWS ECS에서 실행되고 있었습니다. - ECS는 컨테이너 워크로드를 빠르게 운영하기에 좋은 플랫폼이었지만, 장기적으로 필요한 기능을 확장하기에는 한계가 있었습니다. - Figma는 모든 기능을 별도 마이크로서비스로 분리하지 않았습니다. - 성능이나 격리가 필요한 경우에만 새 서비스를 만들었습니다. - 대부분의 제품 기능은 기존 핵심 서비스에 로직을 추가하는 방식으로 구현했습니다. - 따라서 Kubernetes 전환 대상 서비스 수가 수천 개에 달하지 않았고, 이전 작업의 범위를 관리할 수 있었습니다. ## ECS에서 겪은 기능적 한계 - **StatefulSet 부재** - ECS에는 Kubernetes의 StatefulSet처럼 파드에 지속적인 식별자와 네트워크 정체성을 제공하는 기능이 없었습니다. - Figma는 ECS에서 etcd 클러스터를 운영하기 위해 컨테이너 시작 시 클러스터 멤버십을 동적으로 갱신하는 커스텀 코드를 작성했습니다. - 이 방식은 취약하고 유지보수가 어려웠습니다. - Kubernetes에서는 StatefulSet을 이용해 etcd 인스턴스의 안정적인 네트워크 정체성을 제공할 수 있습니다. - **Helm 차트 활용 부족** - Temporal 같은 오픈소스 소프트웨어를 도입하려면 ECS 환경에 맞게 각 서비스를 Terraform으로 직접 포팅해야 했습니다. - Kubernetes에서는 Helm 차트를 통해 관련 서비스와 설정을 표준화된 방식으로 설치하고 관리할 수 있습니다. - **노드 장애 대응의 불편** - ECS on EC2에서 문제가 있는 EC2 인스턴스 하나를 우아하게 종료하는 작업이 복잡했습니다. - EKS에서는 노드를 cordon 처리한 뒤 API 서버가 파드를 다른 노드로 이동시키도록 할 수 있습니다. - 이 과정에서 파드의 정상 종료 절차도 준수할 수 있습니다. ## CNCF 생태계 활용 - ECS를 계속 사용하면 Kubernetes와 함께 발전한 CNCF 오픈소스 생태계를 충분히 활용하기 어려웠습니다. - Figma가 특히 관심을 가진 영역은 자동 확장이었습니다. - 당시 컨테이너 서비스에 자동 확장을 적용하지 않아, 야간이나 주말처럼 트래픽이 낮은 시간에도 최대 부하를 감당할 자원을 미리 provision해야 했습니다. - 그 결과 불필요한 인프라 비용이 발생했습니다. - Kubernetes 생태계의 KEDA는 다음과 같은 기준으로 자동 확장을 지원합니다. - CPU 사용률 - AWS SQS 큐 길이 - Datadog의 커스텀 메트릭 - ECS에도 일부 자동 확장 기능은 있지만, Figma는 Kubernetes 생태계의 성숙한 오픈소스 도구를 활용하는 편이 장기적으로 유리하다고 판단했습니다. ## 서비스 메시와 트래픽 처리 - Figma는 서비스 간 트래픽을 AWS ALB와 NLB를 통해 라우팅하고 있었습니다. - NLB에서 새 대상을 등록하거나 기존 대상을 제거하는 데 몇 분이 걸려 긴급 배포와 장애 복구가 느려지는 문제가 있었습니다. - Figma는 이미 주요 서비스 앞에 독립적인 Envoy 프록시 클러스터를 운영하고 있었습니다. - 장애 상황에서 부하를 줄이는 커스텀 필터를 적용하기 위한 목적이었습니다. - 장기적으로는 전체 서비스에 Envoy 기반 서비스 메시를 도입할 가능성이 있다고 보았습니다. - EKS에서는 Istio 같은 서비스 메시 솔루션을 활용할 수 있지만, ECS에서는 이런 생태계를 직접 구축하거나 많은 부분을 커스텀 구현해야 했습니다. ## 전환을 결정한 기준 - 단순히 새로운 기술을 도입하는 것이 아니라, 다음 세 가지를 종합해 판단했습니다. - 현재 ECS에서 발생하는 운영 및 개발 비용 - 자동 확장과 서비스 메시 등 미래 요구사항 - 마이그레이션을 합리적인 기간 안에 완료할 수 있는지 여부 - Figma는 대규모 작업이 플랫폼을 실제로 개선하고, 사용자에게 다운타임을 유발하지 않으면서 완료될 수 있어야 한다는 원칙을 강조했습니다. - 결론적으로 Kubernetes는 StatefulSet, Helm, 자동 확장, 서비스 메시 등 Figma가 필요로 하던 기능을 더 자연스럽게 제공하는 기반으로 평가되었습니다. Figma와 유사하게 컨테이너 기반 서비스를 운영하면서 ECS의 기능적 한계가 커지고 있다면 Kubernetes 전환을 검토할 수 있습니다. 다만 서비스 수와 운영 복잡도를 먼저 평가하고, 자동 확장·상태 저장 워크로드·트래픽 관리처럼 실제로 필요한 기능을 기준으로 이전의 효과를 판단하는 것이 바람직합니다.

원문 읽기(새 탭에서 열림)

Docker & 컨테이너쿠버네티스Terraformhelm+4

figma·2023년 10월 23일·3분 읽기큐레이션 요약

서버 측 샌드박싱

서버 측 샌드박싱은 악성 입력을 처리하는 애플리케이션의 취약점이 전체 인프라로 확산되는 것을 막는 방어 계층이다. 이미지·데이터 처리 라이브러리처럼 메모리 안전성이 낮고 취약점이 반복적으로 발견되는 소프트웨어를 완전히 제거하거나 재작성하기는 현실적으로 어렵기 때문에, VM·컨테이너·seccomp 등을 이용해 실행 환경과 접근 가능한 자원을 제한해야 한다. 중요한 것은 특정 기술 하나를 선택하는 것이 아니라 보안성, 운영 복잡도, 성능, 격리 수준 사이의 트레이드오프를 workload 특성에 맞게 평가하는 것이다. ## 사용자 입력을 처리할 때 발생하는 위험 - 이미지 처리, 파싱, 압축, 썸네일 생성은 SaaS 애플리케이션에서 흔히 필요한 작업이다. - 이러한 기능은 C++ 같은 메모리 비안전 언어로 작성된 라이브러리에 의존하는 경우가 많다. - 해당 라이브러리는 원래 악의적인 입력을 처리하도록 설계되지 않았으며, 메모리 손상 취약점이 반복적으로 발견되어 왔다. - 대표적인 사례가 2016년 ImageMagick에서 발견된 **ImageTragick**이다. - 사용자가 제공한 이미지를 서버에서 처리하는 서비스가 원격 코드 실행 공격에 노출될 수 있었다. - 모든 버그와 취약점을 사전에 제거하는 것은 사실상 불가능하므로, 취약점이 발생하더라도 피해 범위를 제한하는 방어책이 필요하다. ## 서버 측 샌드박싱의 역할 - 샌드박싱은 애플리케이션이나 작업을 제한된 환경에서 실행하는 **workload isolation** 기법이다. - 공격자가 취약한 작업을 장악하더라도 다음과 같은 접근을 제한하는 것이 목표다. - 다른 작업의 사용자 데이터 - 운영 환경의 내부 서비스 - 파일 시스템과 네트워크 자원 - 추가 시스템으로의 lateral movement - Figma는 C++로 작성된 서버 측 렌더링 시스템인 RenderServer와 사용자 생성 그래픽 데이터를 처리하는 서드파티 라이브러리를 사용한다. - 이러한 작업을 인프라 내부에서 직접 실행하면 단 하나의 심각한 버그가 다른 사용자 데이터나 운영 시스템 침해로 이어질 수 있다. - 모든 unsafe 코드를 메모리 안전 언어로 다시 작성하고 정적 분석으로 정확성을 증명하는 방법도 있지만, 비용과 시간이 크며 완벽한 보안을 보장하지도 않는다. - 따라서 취약점 예방과 함께, 취약점이 악용되었을 때 영향 범위를 줄이는 격리 전략을 병행한다. ## VM, 컨테이너, seccomp - 글에서는 서버 측 샌드박싱의 대표적인 구현 방식으로 다음 세 가지를 소개한다. - **가상 머신(VM)**: 하이퍼바이저 위에서 각 게스트 운영체제를 실행한다. 인프라와 작업 사이에 하이퍼바이저 및 게스트 OS 계층이 존재한다. - **컨테이너**: 호스트 운영체제의 기능과 커널을 공유하면서 컨테이너 엔진을 통해 작업을 분리한다. VM보다 가볍게 실행할 수 있지만 격리 특성이 다르다. - **seccomp**: 프로세스가 호출할 수 있는 시스템 콜을 제한하는 Linux 보안 기능이다. - 각 방식은 격리 강도, 실행 비용, 성능, 시작 시간, 운영 편의성, 설정 복잡도 등에서 서로 다른 특성을 가진다. - 실제 환경에서는 단일 기술만 사용하기보다 workload의 신뢰 수준과 필요한 권한에 따라 여러 샌드박싱 primitive를 조합할 수 있다. ## 샌드박싱 선택 시 고려할 점 - 샌드박싱은 보안 취약점을 없애는 기술이 아니라, 취약점이 발생했을 때 공격의 범위와 피해를 제한하는 방어 계층이다. - 선택 과정에서는 다음을 함께 검토해야 한다. - 처리 대상이 사용자 입력인지, 내부에서 신뢰할 수 있는 데이터인지 - 작업이 필요한 파일·네트워크·시스템 콜의 범위 - 강한 격리에 필요한 성능 및 비용 - 샌드박스의 생성·폐기와 패치·모니터링 운영 부담 - 샌드박스 자체의 탈출 가능성과 호스트에 미치는 영향 - 샌드박싱 기술은 과거보다 안정적이고 실용적으로 발전했지만, 여전히 보안 연구와 운영 경험이 중요한 분야다. 악성 입력을 처리하는 기능은 메모리 안전 언어로의 전환만으로 보호하려 하기보다, 최소 권한과 강한 실행 격리를 함께 적용하는 것이 현실적이다. 특히 사용자 데이터를 다루는 고위험 작업은 VM이나 컨테이너 격리를 검토하고, 불필요한 시스템 콜은 seccomp로 추가 제한하는 접근이 유용하다.

원문 읽기(새 탭에서 열림)

Docker & 컨테이너webassemblyc++application-security+3

figma·2023년 10월 23일·3분 읽기큐레이션 요약

서버 측 샌드박싱

컨테이너와 seccomp는 가상 머신보다 가볍게 서버 측 작업을 격리할 수 있지만, 기본 설정만으로 안전한 샌드박스가 되는 것은 아니다. 컨테이너 탈출 위험은 런타임 구현, 운영체제 커널 기능, 런타임 설정에 좌우되며, 침해된 컨테이너가 호스트나 다른 시스템에 미치는 영향까지 함께 제한해야 한다. Figma는 컨테이너의 OS 수준 격리 기능과 seccomp를 활용해 성능과 보안 사이의 균형을 맞추고 있다. ## 컨테이너와 가상 머신의 차이 - 가상 머신은 하이퍼바이저를 통해 운영체제 수준에서 격리한다. - 컨테이너는 호스트 OS의 커널 기능을 공유하며, 다음과 같은 기능을 이용해 격리한다. - Linux namespaces - cgroups - 권한 강등(privilege dropping) - seccomp - SELinux, AppArmor 같은 필수 접근 제어(MAC) - 컨테이너는 VM보다 가볍고 효율적이지만, 격리 수준을 사용자가 직접 세밀하게 설정해야 한다. - 설정 자유도가 높은 만큼 잘못된 구성으로 인해 보안 취약점이 발생할 가능성도 크다. ## 샌드박싱이 필요한 이유 - 이미지 처리와 데이터 파싱처럼 애플리케이션에 필수적인 기능은 외부 입력을 다루므로 취약점 위험을 포함한다. - 모든 보안 취약점을 사전에 제거하는 것은 비용이 많이 들고 현실적으로 어렵다. - 따라서 취약한 작업이 실행되더라도 호스트와 다른 시스템으로 피해가 확산되지 않도록 서버 측 샌드박싱, 즉 workload isolation을 적용한다. - 격리 설계에서는 두 가지 질문을 중심으로 보안성을 평가한다. - 악성 작업이 컨테이너에서 탈출해 호스트를 변경하거나 장악할 수 있는가? - 컨테이너를 탈출하지 못하더라도 컨테이너 권한으로 다른 시스템에 접근하거나 피해를 줄 수 있는가? ## 컨테이너에서 호스트로 이어지는 공격 표면 컨테이너 탈출 가능성은 컨테이너 자체보다 여러 구성 요소의 조합에 의해 결정된다. - 주요 공격 표면은 다음 세 가지다. - 컨테이너 런타임 구현의 버그 - 런타임이 사용하는 운영체제 커널 기능과 인터페이스 - 런타임 보안 설정 및 구성 오류 - Linux 환경에서 Docker는 일반적으로 runC 런타임을 사용한다. - runC와 Docker는 namespaces, cgroups, 권한 강등, seccomp, SELinux, AppArmor 등을 조합해 격리를 제공한다. - 커널 취약점이나 런타임 구현 오류, 잘못된 설정이 있으면 악성 작업이 다음과 같은 행위를 할 수 있다. - 호스트 파일 수정 - 호스트에서 코드 실행 - 컨테이너 탈출 - 컨테이너의 기본 설정이 과거보다 안전해졌더라도, 특정 샌드박싱 용도에 충분한지는 사용자가 직접 검증해야 한다. ## 침해된 컨테이너의 피해 제한 컨테이너 내부에서 작업이 침해되었다고 가정하고, 호스트뿐 아니라 주변 시스템에 대한 접근도 차단해야 한다. - 컨테이너 설정을 강화해 호스트 장악을 방지해야 한다. - 컨테이너에 다음 자원을 불필요하게 제공하지 않는 것이 중요하다. - 네트워크 장치 - 인증 자격 증명 - 다른 작업의 데이터 - 컨테이너를 별도의 격리된 네트워크에 배치할 수 있다. - 오케스트레이션 시스템을 사용해 입력은 통제된 채널로 전달하고, 출력도 검증·제한된 방식으로 수집한다. - 핵심은 “컨테이너가 침해되지 않을 것”이 아니라 “침해되더라도 피해 범위를 제한할 것”이라는 방어적 설계다. ## seccomp의 역할 - seccomp(secure computing mode)는 프로그램이 호출할 수 있는 시스템 콜을 제한하는 Linux 기능이다. - 시스템 콜을 허용 목록 또는 제한 정책으로 관리하면, 컨테이너 프로세스가 커널과 상호작용할 수 있는 범위를 줄일 수 있다. - 컨테이너 격리는 런타임, 커널 기능, 설정의 결합으로 구현되므로 seccomp 역시 다른 보안 기능과 함께 사용해야 한다. - 제공된 글 내용은 seccomp 보안 모델을 소개하는 부분에서 중단되어 있어, 이후 Figma의 구체적인 nsjail 구성과 운영 방식은 확인할 수 없다. 컨테이너를 서버 측 샌드박스로 사용할 때는 기본 설정을 그대로 신뢰하지 말고, 최소 권한·제한된 시스템 콜·격리된 네트워크·자격 증명 차단을 함께 적용하는 것이 좋다. 특히 컨테이너 탈출 방지와 침해 이후 피해 제한을 별개의 보안 목표로 보고 설계해야 한다.

원문 읽기(새 탭에서 열림)

Docker & 컨테이너seccompcgroupscontainer-sandboxing+4

datadog·2023년 5월 24일원문

2023-03-08 사건: 플랫폼 수준의 영향 깊이 살펴보기 | Datadog (새 탭에서 열림)

2023년 3월 8일 발생한 Datadog의 전사적 서비스 장애는 시스템 관리 데몬인 systemd의 동작 변경과 자동 보안 업데이트 설정이 결합되어 발생한 이례적인 사건입니다. Ubuntu 22.04 환경에서 systemd-networkd가 재시작될 때 기존 IP 라우팅 규칙을 모두 삭제하는 새로운 기본 동작이 활성화되었고, 이것이 전 지역 노드에 동시다발적인 자동 패치로 실행되면서 대규모 네트워크 중단으로 이어졌습니다. 이 사고는 인프라 전반에 걸친 자동화된 변경 관리와 점진적 배포 원칙이 보안 패치라는 예외 상황에서 어떻게 무력화될 수 있는지를 보여줍니다. **systemd-networkd의 IP 규칙 삭제 동작** * 2020년 12월 배포된 systemd v248부터 `systemd-networkd`는 시작 시 자신이 파악하지 못한 모든 IP 규칙(IP rules)을 삭제(flush)하는 동작을 도입했습니다. * 이후 v249에서 `ManageForeignRoutingPolicyRules` 설정을 통해 이 동작을 거부할 수 있는 옵션이 추가되었으나, 기본값은 여전히 기존 규칙을 삭제하는 방식이었습니다. * Datadog이 마이그레이션 중이던 Ubuntu 22.04는 이 위험한 기본 설정이 포함된 systemd v249를 사용하고 있었습니다. **보안 패치와 자동 업데이트의 결합** * 2023년 3월 7일, systemd의 CVE 취약점을 해결하기 위한 보안 패치가 Ubuntu 저장소에 업데이트되었습니다. * Datadog의 서버들은 Ubuntu의 기본 설정인 `unattended-upgrades`를 사용하고 있었으며, 이는 매일 특정 시간(06:00 UTC)에 보안 업데이트를 자동으로 수행하도록 설정되어 있었습니다. * 이 보안 패치가 설치되면서 `systemd-networkd` 서비스가 재시작되었고, 그 즉시 노드의 핵심적인 네트워크 라우팅 규칙들이 모두 삭제되었습니다. **점진적 배포 전략의 무력화** * Datadog은 평소 새로운 OS나 설정을 도입할 때 실험용 클러스터부터 시작해 스테이징, 소규모 리전, 대규모 리전 순으로 수주에 걸쳐 점진적으로 배포하는 엄격한 프로세스를 따릅니다. * 하지만 시스템 레벨의 자동 업데이트(unattended-upgrades)는 이러한 점진적 배포 통제를 우회하여 전 세계 모든 리전의 노드에 거의 동시에 적용되었습니다. * 결과적으로 전체 서버의 90% 이상을 차지하던 Ubuntu 22.04 노드들이 동시다발적으로 네트워크 불능 상태에 빠지게 되었습니다. **실용적인 교훈과 권장사항** 운영 환경에서 OS 배포판을 업그레이드할 때는 시스템 구성 요소(특히 systemd와 같은 핵심 데몬)의 기본 동작 변경 사항을 상세히 검토해야 합니다. 또한, 보안을 위한 자동 업데이트라 할지라도 인프라 전체에 동시에 적용되는 방식은 위험할 수 있으므로, 업데이트 주기를 리전별로 분산하거나 자체적인 패키지 미러를 통해 보안 패치 역시 점진적 배포 파이프라인의 통제하에 두는 것이 권장됩니다.

Docker & 컨테이너쿠버네티스systemdubuntu+4

datadog·2022년 3월 25일원문

Dirty Pipe 취약점을 이용한 컨 (새 탭에서 열림)

리눅스 커널에서 발견된 Dirty Pipe 취약점은 권한이 없는 프로세스가 읽기 권한만 가진 파일에 데이터를 쓸 수 있게 허용하며, 이를 통해 컨테이너 환경에서 호스트 시스템의 루트 권한을 탈취할 수 있는 심각한 위협을 초래합니다. 특히 Kubernetes 환경에서 널리 쓰이는 컨테이너 런타임인 runC의 실행 바이너리를 페이지 캐시 수준에서 변조함으로써, 격리된 컨테이너를 탈출하여 호스트 시스템을 완전히 장악하는 시나리오가 가능합니다. 본 글에서는 이 취약점의 기술적 배경과 함께 실제 컨테이너 탈출이 이루어지는 공격 메커니즘을 상세히 설명합니다. **컨테이너 런타임과 runC의 구조적 취약성** - Kubernetes는 containerd나 CRI-O 같은 런타임을 통해 컨테이너를 관리하며, 실제 프로세스 생성은 OCI 규격을 준수하는 하위 레벨 런타임인 runC가 담당합니다. - runC는 컨테이너 내부 프로세스를 실행할 때 자신을 포크(fork)한 뒤 `execve` 시스템 콜을 호출하는데, 이때 `/proc/self/exe` 경로를 통해 호스트에 있는 runC 이진 파일에 대한 파일 서술자(File Descriptor)를 열어두게 됩니다. - 과거 CVE-2019-5736 취약점에 대한 대응으로 runC를 읽기 전용으로 마운트하는 방어책이 도입되었으나, Dirty Pipe는 커널의 페이지 캐시를 직접 수정하므로 이러한 파일 시스템 수준의 권한 제한을 무력화합니다. **Dirty Pipe를 이용한 컨테이너 탈출 과정** - 공격자는 먼저 취약한 웹 애플리케이션 등을 통해 권한이 제한된 일반 컨테이너에 침투한 뒤, 호스트의 runC 바이너리가 실행되기를 대기합니다. - 관리자가 `kubectl exec`와 같은 명령을 수행하여 컨테이너 내부에서 runC가 구동되는 순간, 공격 프로세스는 `/proc/<runC-pid>/exe`를 통해 호스트의 runC 실행 파일에 접근합니다. - Dirty Pipe 공격 프리미티브를 활용하여 페이지 캐시에 로드된 runC 바이너리 내용을 공격자의 악성 ELF 코드로 덮어씁니다. - 이렇게 변조된 runC는 호스트의 루트 권한으로 실행되므로, 공격자는 호스트 시스템에서 임의의 명령(예: 호스트 이름 확인, 루트 권한 쉘 실행 등)을 수행하며 컨테이너 격리를 완전히 무너뜨립니다. **메모리 기반 공격의 비영구적 특성** - Dirty Pipe를 통한 바이너리 변조는 디스크의 실제 파일을 직접 수정하는 것이 아니라 커널의 페이지 캐시 내에서 발생합니다. - 따라서 공격으로 인한 변조는 시스템이 재부팅되거나 커널 캐시가 드롭(drop)되기 전까지만 유지되는 비영구적 특성을 가집니다. - 하지만 단 한 번의 실행만으로도 호스트에 백도어를 설치하거나 권한을 상승시키기에 충분하므로 그 위험성은 매우 높습니다. Dirty Pipe 취약점은 리눅스 커널 수준의 결함이므로 이를 근본적으로 해결하기 위해서는 최신 보안 패치가 적용된 커널로 신속히 업데이트해야 합니다. 또한 컨테이너 환경에서는 최소 권한 원칙을 철저히 준수하고, 런타임 보안 모니터링 도구를 도입하여 `/proc` 파일 시스템에 대한 의심스러운 접근이나 시스템 이진 파일의 비정상적인 동작을 실시간으로 감지하고 차단하는 방어 전략이 필요합니다.

Docker & 컨테이너쿠버네티스Linuxcontainer-runtime+4

datadog·2021년 2월 10일원문

엔지니어링 스포트라이트: 마엘 니송 (새 탭에서 열림)

인도양의 작은 섬 레위니옹에서 시작해 자바스크립트 생태계의 핵심 도구인 Yarn의 메인 유지보수자가 되기까지, Maël Nison의 여정은 끊임없는 호기심과 오픈소스에 대한 열정으로 가득 차 있습니다. 그는 페이스북 부트캠프를 통해 Yarn 프로젝트에 합류한 뒤, 단순한 기여자를 넘어 프로젝트를 TypeScript 기반의 모듈형 구조로 재설계하고 커뮤니티 주도형 프로젝트로 탈바꿈시키는 데 결정적인 역할을 했습니다. 현재 Datadog의 프론트엔드 플랫폼 팀에서 근무하면서도 Yarn의 비전과 로드맵을 이끄는 그는, 기술적 해결책을 모두와 공유하는 오픈소스 정신이 개인과 공동체를 어떻게 성장시키는지 잘 보여줍니다. **Yarn의 진화와 다각적인 리더십** * 페이스북 입사 초기, 신규 입사자 교육 프로그램인 '부트캠프'를 통해 Yarn 프로젝트를 접하고 업무 시간의 상당 부분을 오픈소스 기여에 투입하기 시작했습니다. * 초기 내부 도구 성격이 강했던 Yarn을 TypeScript로 완전히 재작성하고 아키텍처를 모듈화하여, 특정 기업에 종속되지 않는 진정한 커뮤니티 오픈소스 프로젝트로 발전시켰습니다. * 프로젝트를 관리하며 개발자 역할을 넘어 제품 매니저, 팀 리드, 고객 지원, 인프라 설계, 웹 디자인 등 다방면의 역할을 수행하며 '1인 CEO'와 같은 경험을 쌓았습니다. **DarkBASIC에서 시작된 프로그래밍의 기초** * 프랑스 툴루즈의 중학교 시절, 점심시간마다 모이던 프로그래밍 클럽에서 DarkBASIC이라는 게임 제작 언어를 배우며 개발의 세계에 입문했습니다. * 화면 위에서 물고기가 움직이고 거품을 쏘는 간단한 2D 게임을 만들며, 코드를 수정하면 즉시 결과가 바뀌는 논리적인 과정에 매료되어 평생의 직업으로 삼기로 결심했습니다. * 2000년대 초반 3G 네트워크와 펜티엄 III 프로세서가 표준이던 시절부터 PHP 웹사이트를 구축하고 SQL 취약점을 직접 경험하며 실전 기술을 익혔습니다. **워크플로우 최적화와 실용적 교육** * 깃허브(GitHub)가 없던 시절, 포럼을 통해 소스 코드를 공유하며 누구나 필요한 해결책을 사용할 수 있게 하는 오픈소스의 본질을 체득했습니다. * 기존 CMS(콘텐츠 관리 시스템)들의 복잡한 관리 페이지 구조에 의문을 품고, 게시물을 클릭해 즉시 수정하는 직관적인 워크플로우를 고민하며 '사용자 경험 최적화'에 대한 철학을 세웠습니다. * 이론보다 실무 중심의 프로젝트와 동료 평가를 중시하는 프랑스의 교육 기관 EPITECH에서 수학하며, 자기 주도적 학습 역량과 실용적인 엔지니어링 기술을 연마했습니다. Maël Nison의 사례는 단순히 기술적인 숙련도를 높이는 것을 넘어, 자신이 마주한 불편함을 해결하고 그 결과물을 커뮤니티와 공유하는 습관이 어떻게 세계적인 오픈소스 리더로 성장하는 밑거름이 되는지 보여줍니다. 새로운 기술을 익힐 때 단순히 사용법을 익히는 데 그치지 않고, 오픈소스 프로젝트에 작은 기여부터 시작해 보는 것은 커리어 개발과 기술적 통찰력을 동시에 얻을 수 있는 가장 확실한 방법입니다.

Docker & 컨테이너데이터베이스 설계오픈 소스TypeScript+4

datadog·2017년 8월 23일원문

Vagrant와 Terraform으로 지원 확장 (새 탭에서 열림)

Datadog의 솔루션 팀은 고객이 사용하는 다양한 기술 스택과 복잡한 인프라 환경에서 발생하는 문제를 정확히 재현하기 위해 Vagrant와 Terraform을 활용한 자동화된 샌드박스 시스템을 구축했습니다. 인프라 구축 과정을 코드화하여 팀 전체가 공유함으로써, 개별 엔지니어가 생소한 기술을 매번 처음부터 학습하고 설치해야 하는 비효율을 제거하고 문제 해결 속도를 획기적으로 높였습니다. 결과적으로 로컬 가상 머신과 클라우드 인스턴스를 자유롭게 오가는 유연한 디버깅 환경을 통해 팀 간 협업과 고객 지원의 품질을 극대화할 수 있었습니다. **Vagrant 프로비저닝을 통한 환경 구축 자동화** * 고객의 특정 OS, 커널 버전, 복잡한 통합 도구(Kafka, MS SQL, RabbitMQ 등)를 수동으로 설치하는 것은 시간이 많이 걸리고 오류가 발생하기 쉽습니다. * Vagrant의 '프로비저닝(Provisioning)' 기능을 활용하여, 인프라 설치 및 설정에 필요한 모든 명령어를 `setup.sh`와 같은 쉘 스크립트에 담아 자동화했습니다. * 한 번 작성된 프로비저닝 스크립트는 팀 공용 GitHub 저장소에 저장되어, 다른 팀원들이 동일한 이슈를 처리할 때 `vagrant up` 명령어 하나만으로 즉시 동일한 환경을 갖출 수 있게 합니다. **샌드박스 저장소의 구조화 및 유연성 확보** * 저장소는 운영체제와 배포판, 서비스 이름에 따라 계층적으로 디렉토리를 나누어 관리하며, 각 디렉토리에는 `Vagrantfile`, `setup.sh`, 그리고 설정 파일 등이 담긴 `/data` 폴더를 포함합니다. * 엔지니어 개인별로 달라야 하는 설정(호스트 이름, API 키, 태그 등)은 `.sandbox.conf.sh`라는 로컬 설정 파일에 분리하여 관리함으로써 스크립트의 범용성을 유지합니다. * 이를 통해 새로운 환경이 필요할 때 기존 템플릿을 복사하여 빠르게 변형할 수 있으며, 팀 내 기술적 노하우가 코드를 통해 자연스럽게 축적됩니다. **Terraform을 이용한 클라우드 확장 및 협업** * 로컬 가상 머신 사용 시 발생하는 RAM 자원 부족 문제를 해결하고 팀원 간 환경을 쉽게 공유하기 위해 Terraform을 도입하여 AWS EC2 인스턴스를 활용합니다. * Vagrant에서 사용하던 `setup.sh`와 `/data` 파일을 그대로 재사용하면서, 인스턴스 생성을 위한 `.tf` 파일만 추가하여 로컬과 클라우드 환경 간의 일관성을 유지합니다. * 클라우드 기반 샌드박스를 활용하면 여러 시간대의 팀원들이 동일한 원격 환경에 접속해 조사를 이어갈 수 있으며, 고객과의 실시간 상담 중에도 미리 준비된 환경을 즉시 배포하여 대응할 수 있습니다. **실용적인 결론** 반복적인 환경 구축이 필요한 기술 지원이나 개발 팀이라면 인프라를 코드로 관리(IaC)하는 것이 필수적입니다. Vagrant로 로컬에서 가볍게 시작하되, 동일한 프로비저닝 스크립트를 Terraform과 공유할 수 있도록 설계하면 로컬의 편의성과 클라우드의 협업 능력을 동시에 잡을 수 있습니다. 특히 `setup.sh`와 같은 범용 스크립트를 중심에 두면 도구가 바뀌어도 재사용성을 높일 수 있습니다.

Docker & 컨테이너PostgreSQLTerraformvirtual-machines+4