Cloud Native

12 Factor 는 PaaS 기업 Heroku 가 수천 개 앱 운영 경험에서 추출한 방법론으로, 컨테이너 시대에 와서 오히려 표준 교양이 됐습니다.

12 Factor App 은 Heroku 공동 창업자 Adam Wiggins 가 2011년 공개한 문서로, 수많은 애플리케이션의 개발·배포·운영을 지켜본 경험에서 “클라우드에서 잘 돌아가는 앱”의 공통 특성을 뽑아낸 것입니다(출처: The Twelve-Factor App — 소개). 발표 당시에는 특정 PaaS 를 위한 가이드처럼 보였지만, 컨테이너와 쿠버네티스가 보편화되면서 상황이 바뀌었습니다. 12가지 원칙이 요구하는 성질 — 환경과 분리된 설정, 무상태 프로세스, 빠른 기동과 우아한 종료 — 이 정확히 컨테이너 오케스트레이션이 애플리케이션에게 요구하는 성질이기 때문입니다.

달리 말해 12 Factor 를 지킨 앱은 별다른 수정 없이 쿠버네티스 위에서 확장·복구·이동이 자연스럽고, 지키지 않은 앱은 컨테이너에 담아도 스케일 아웃이 막힙니다. 클라우드 네이티브 4대 요소 가운데 컨테이너·CI/CD 가 인프라 쪽 준비라면, 12 Factor 는 애플리케이션 쪽 준비인 셈입니다.

컨테이너화는 성숙도의 첫 단계일 뿐입니다. 12 Factor 는 그 위에서 애플리케이션을 클라우드 네이티브 쪽으로 끌어올리는 축입니다.

클라우드 네이티브 전환의 성숙도는 네 단계로 나눠 보면 현재 위치가 분명해집니다. 컨테이너 이미지로 실행되는 상태가 Level 0 Cloud Ready, 구성 요소 간 결합을 느슨하게 풀고 12 Factor 원칙을 지키는 상태가 Level 1 Cloud Friendly, 장애를 고려한 설계와 중앙 집중 관측을 갖춘 상태가 Level 2 Cloud Resilient, API 기반 마이크로서비스로 재구성한 상태가 Level 3 Cloud Native 입니다(출처: Open Data Center Alliance, Architecting Cloud-Aware Applications). 눈여겨볼 대목은 12 Factor 원칙 준수가 Level 1 의 조건으로 명시되어 있다는 점입니다. 컨테이너에 담는 것만으로는 Level 0 이고, 거기서 한 칸 올라가는 조건이 곧 12 Factor 입니다.

많은 조직이 첫 단계에서 더 나아가지 못하는데, 그 원인은 대개 플랫폼이 아니라 애플리케이션에 있습니다. 설정이 이미지에 박혀 있고 상태가 프로세스 안에 남아 있으면, 그 위에 아무리 좋은 오케스트레이션을 얹어도 다음 단계로 넘어갈 수 없습니다.

애플리케이션 중심으로 설계 축을 그려 보면 12 Factor 의 자리가 더 분명합니다. 클라우드 퍼스트, 클라우드 네이티브, 마이크로 서비스가 동심원으로 겹쳐 있고 그 가장 안쪽 중심에 12 Factor 앱이 놓입니다(출처: Packt, Cloud Native Architectures). 바깥 고리는 안쪽 고리를 전제로만 성립합니다. 인프라를 클라우드로 옮기고 서비스를 잘게 쪼개도, 가장 안쪽 — 애플리케이션 코드가 지켜야 할 12가지 — 가 비어 있으면 바깥 세 고리는 형태만 남습니다. 그래서 12 Factor 는 “여유가 생기면 하는 정리 작업”이 아니라 성숙도 전환의 관문에 가깝습니다.

앞의 세 원칙은 “코드는 하나, 배포는 여럿”을 가능하게 만드는 분리 원칙입니다. 쿠버네티스에서는 ConfigMap·Secret 이 그 구현체입니다.

• I. 코드베이스(Codebase) — 앱 하나당 버전 관리되는 코드베이스는 하나, 배포는 개발·스테이징·운영 여러 개입니다. 같은 코드가 환경만 달리해 배포되어야 “운영에만 있는 코드” 같은 추적 불가능한 변형이 사라집니다.
• II. 의존성(Dependencies) — 앱이 필요로 하는 라이브러리를 명시적으로 선언하고 격리합니다. 시스템에 우연히 설치된 패키지에 기대지 않습니다. 컨테이너 이미지는 이 원칙의 극단적 구현입니다. 의존성 전체가 이미지 안에 선언적으로 담기기 때문입니다.
• III. 설정(Config) — 배포 환경마다 달라지는 값(DB 접속 정보, 외부 서비스 자격 증명)은 코드가 아니라 환경 변수에 둡니다(출처: The Twelve-Factor App — Config). 설정이 코드에 박혀 있으면 환경마다 빌드를 다시 해야 하고, 자격 증명이 저장소에 유출됩니다.

쿠버네티스는 III 을 ConfigMap 과 Secret 으로 구현합니다. 기밀이 아닌 설정은 ConfigMap 에, 자격 증명은 Secret 에 두고 컨테이너에 환경 변수나 파일로 주입합니다(출처: Kubernetes 공식 문서 — 구성, 한국어). 같은 이미지가 개발 클러스터에서는 개발 DB 를, 운영 클러스터에서는 운영 DB 를 바라보게 되는 구조 — “빌드는 한 번, 배포는 어디든”이 여기서 완성됩니다.

가운데 세 원칙의 핵심은 무상태(Stateless)입니다. 상태를 프로세스 밖으로 밀어내야 인스턴스를 마음대로 늘리고 죽일 수 있습니다.

• IV. 백엔드 서비스(Backing Services) — DB·캐시·메시지 큐 같은 부속 서비스를 URL 로 접근하는 연결된 리소스로 다룹니다. 로컬 DB 든 관리형 DB 든 설정 값만 바꾸면 교체되는 구조입니다.
• V. 빌드, 릴리스, 실행(Build, Release, Run) — 빌드(코드→실행물), 릴리스(실행물+설정), 실행(프로세스 기동) 세 단계를 엄격히 분리합니다. 실행 중인 앱을 손으로 고치는 일을 원천 차단하는 원칙으로, CI/CD 파이프라인과 컨테이너 이미지 태그가 이 분리를 강제합니다. 이미지 태그를 어떻게 끊어 관리하느냐가 이 원칙의 실효를 좌우하는데, 그 운영 방식은 컨테이너 레지스트리 이미지 관리 방안 글에서 다룹니다.
• VI. 프로세스(Processes) — 앱은 무상태 프로세스로 실행합니다. 세션·업로드 파일 같은 상태는 프로세스 메모리나 로컬 디스크가 아니라 DB·오브젝트 스토리지·외부 캐시(Redis 등)에 둡니다. CNCF 용어집도 무상태 앱을 “이전 요청의 데이터를 저장하지 않고 각 요청을 독립적으로 처리하는 애플리케이션”으로 정의합니다(출처: CNCF Cloud Native Glossary — Stateless Apps).

무상태가 왜 핵심인지는 스케일 아웃 장면에서 드러납니다. 세션을 로컬 메모리에 든 앱은 인스턴스가 2개가 되는 순간 “어느 인스턴스로 가느냐”에 따라 로그인이 풀립니다. 상태를 밖으로 밀어낸 앱은 인스턴스가 1개든 100개든 어느 쪽이 요청을 받아도 동일하게 동작합니다. 쿠버네티스가 파드(Pod)를 자유롭게 죽이고 다시 띄울 수 있는 것도 이 전제 위에서입니다.

무상태 원칙이 실무에서 가장 자주 깨지는 지점 — 세션

12가지 원칙 중 현장에서 가장 먼저, 가장 자주 무너지는 항목이 VI 프로세스입니다. 원인은 대부분 세션입니다. 자바 웹 애플리케이션에서 로그인 상태는 관행적으로 WAS 프로세스의 힙 메모리에 놓이는데, 이 상태로 컨테이너에 담으면 파드가 종료되는 순간 세션이 함께 사라집니다. 쿠버네티스가 롤링 업데이트로 파드를 교체하거나 HPA 가 부하 감소에 따라 파드를 줄이는 것은 정상 동작인데, 그때마다 사용자가 로그아웃되는 셈입니다.

전통적인 해법이었던 WAS 내장 세션 클러스터링은 쿠버네티스 환경에서 특히 잘 맞지 않습니다. 멤버 탐색이 멀티캐스트에 의존하는 구조는 오버레이 네트워크 위에서 안정적으로 동작하기 어렵고, 전체 인스턴스에 세션 변경을 전파하는 복제 방식은 인스턴스를 늘릴수록 네트워크와 직렬화 비용이 함께 커집니다. 세션을 힙에 쌓아 두는 만큼 Full GC 로 인한 멈춤 위험도 올라갑니다. 확장하려고 도입한 구조가 확장을 막는 구조가 되는 것입니다. 이 한계를 사례로 짚은 내용은 Tomcat 세션 클러스터링의 진실 글에 정리되어 있습니다.

그래서 실무의 답은 새로운 기술이 아니라 표준입니다. 서블릿 표준의 <distributable/> 선언과 Spring Session 같은 외부 세션 저장소 연동은 이미 오래전에 자리 잡은 경로이고, 12 Factor 의 VI 프로세스 원칙을 그대로 구현한 형태이기도 합니다. 다만 어떤 저장소를 고르느냐는 별개의 결정입니다. 세션 저장소에 요구되는 일관성·재분배·장애 복구 요건을 기준으로 선택지를 비교한 내용은 Redis로 세션 관리? 엔터프라이즈급 서비스의 숨겨진 위험 글에서 확인할 수 있습니다.

이 세 원칙은 프로세스를 복제 가능한 부품으로 만듭니다. 쿠버네티스의 자동 확장과 자가 치유가 기대는 성질이 바로 이것입니다.

• VII. 포트 바인딩(Port Binding) — 앱은 자체적으로 포트를 열어 서비스를 노출합니다. 외부 웹 서버에 얹혀 실행되는 구조가 아니라, 그 자체로 완결된 실행 단위여야 합니다. 컨테이너의 포트 노출과 쿠버네티스 Service 추상화가 이 원칙 위에 서 있습니다.
• VIII. 동시성(Concurrency) — 처리량을 늘릴 때는 프로세스를 키우는 것(수직)이 아니라 프로세스 수를 늘리는 것(수평)으로 대응합니다. 쿠버네티스에서는 replicas 값을 올리거나 HPA(Horizontal Pod Autoscaler)가 부하에 따라 파드 수를 자동 조절하는 형태로 구현됩니다.
• IX. 폐기 가능성(Disposability) — 프로세스는 빠르게 시작하고 우아하게 종료(graceful shutdown)되어야 합니다. SIGTERM 을 받으면 처리 중인 요청을 마무리하고 새 요청은 받지 않으며 정리 후 종료하는 동작입니다.

IX 가 왜 까다로운지는 파드 종료 순서를 펼쳐 보면 드러납니다. 파드 삭제가 시작되면 쿠버네티스는 해당 파드를 Service 엔드포인트에서 빼는 작업과 컨테이너에 SIGTERM 을 보내는 작업을 함께 진행하고, 종료 유예 시간(terminationGracePeriodSeconds, 기본 30초)이 지나면 SIGKILL 로 강제 종료합니다(출처: Kubernetes 공식 문서 — 파드 생명주기). 애플리케이션이 SIGTERM 을 무시하도록 만들어져 있으면 처리 중이던 요청이 30초 뒤 그대로 끊깁니다. 무중단 롤링 업데이트가 되느냐 마느냐는 결국 이 신호를 앱이 받아 처리하도록 짜여 있는지에 달려 있습니다. 파드가 어떤 단계를 거쳐 뜨고 지는지는 쿠버네티스 Pod 완벽 가이드 글에서 자세히 다룹니다.

셋을 묶으면 “언제든 늘리고, 언제든 죽여도 되는 프로세스”가 됩니다. 인스턴스 하나하나를 아껴 돌보는 운영이 아니라, 부품을 갈아 끼우는 운영으로 넘어가는 조건입니다.

마지막 세 원칙은 개발과 운영의 간극을 줄이고, 로그를 이벤트 스트림으로 다루며, 일회성 작업까지 같은 환경에서 실행하게 합니다.

• X. 개발/운영 일치(Dev/Prod Parity) — 개발 환경과 운영 환경의 차이(시간·담당자·도구)를 최소화합니다. “개발은 SQLite, 운영은 PostgreSQL” 같은 백엔드 차이가 배포 후 문제의 단골 원인이기 때문입니다. 컨테이너는 같은 이미지를 어느 환경에서나 실행하게 해 이 원칙의 실현 비용을 크게 낮췄습니다.
• XI. 로그(Logs) — 앱은 로그 파일을 직접 관리하지 않고, 이벤트 스트림으로 표준 출력(stdout)에 흘려보냅니다(출처: The Twelve-Factor App — Logs). 수집·저장·검색은 실행 환경의 몫입니다. 쿠버네티스 환경에서는 컨테이너의 표준 출력을 Fluent Bit 같은 수집기가 모아 중앙 저장소로 보내는 구조가 표준입니다. 앱이 로컬 파일에 로그를 쓰면 파드가 사라질 때 로그도 사라집니다.
• XII. 관리 프로세스(Admin Processes) — DB 마이그레이션 같은 일회성 관리 작업도 본 앱과 같은 코드베이스·같은 설정·같은 환경에서 실행합니다. 쿠버네티스의 Job 리소스가 전형적인 구현입니다.

12가지 원칙 각각이 컨테이너·쿠버네티스 환경에서 어떤 수단으로 구현되는지 한 표로 정리하면 다음과 같습니다.

표를 보면 한 가지가 분명해집니다. 12가지 원칙 대부분이 쿠버네티스에서는 별도 발명 없이 기본 리소스로 구현된다는 점입니다. 원칙이 플랫폼에 내장되어 있으니, 남는 과제는 애플리케이션이 그 전제(설정 외부화, 무상태, 종료 신호 처리)를 지키도록 고치는 쪽입니다. 매핑표는 그 개선 작업의 점검표로 그대로 쓸 수 있습니다. 표에 등장하는 Service·HPA·Job 이 클러스터 안에서 각각 어디에 놓이는지는 쿠버네티스 아키텍처 완전 정복 글에서 확인할 수 있습니다.

같은 12라는 숫자로, 쿠버네티스 운영자 관점의 실천 항목을 정리한 버전도 있습니다. 마지막 항목이 인상적입니다.

Devoxx France 2018에서 발표된 「12 Factors Kubernetes」(Etienne Coutaud, OCTO Technology)는 원문 원칙을 쿠버네티스 운영 관점의 실천 항목으로 옮겨 놓은 정리입니다(출처: OCTO Technology 블로그 — The twelve factors Kubernetes). 파드는 한 개 또는 협력하는 여러 컨테이너의 묶음으로 설계할 것(사이드카·앰배서더·어댑터 패턴), 레이블을 기술적·관리적 기준 모두에 붙일 것, 인프라 정의도 코드로 보고 버전 관리할 것, 노출은 Service 로 할 것, 설정은 ConfigMap 과 Secret 으로 다룰 것, 리소스 Limits·Requests 를 지정할 것, 파드 수명은 Deployment 로 관리할 것, Liveness·Readiness 프로브를 설정할 것, latest 는 버전이 아니라는 것, 파드는 무상태로 둘 것, 볼륨은 분산 스토리지 위에 마운트할 것 — 여기까지가 열한 가지입니다.

그리고 열두 번째 항목이 “애플리케이션 코드 자체를 12 Factor 에 맞출 것”입니다. 플랫폼 쪽에서 할 수 있는 열한 가지를 모두 해도, 애플리케이션이 설정을 환경 변수로 읽지 않고 상태를 프로세스에 들고 있으며 종료 신호를 처리하지 않으면 앞의 열한 가지가 힘을 잃는다는 구성입니다. 쿠버네티스를 잘 쓰는 문제와 애플리케이션을 잘 설계하는 문제는 결국 같은 문제의 양면이라는 이야기이기도 합니다.

12 Factor 는 출발점이지 종착점이 아닙니다. API 우선, 텔레메트리, 인증·인가를 보태는 확장 논의가 이어지고 있습니다.

원문 발표 이후 15년 가까이 지나면서 보완 논의도 쌓였습니다. 대표적으로 Kevin Hoffman 의 「Beyond the Twelve-Factor App」(O’Reilly, 2016)은 원칙을 현대화하면서 API 우선 설계(API First), 텔레메트리(Telemetry), 인증·인가(Authentication/Authorization) 세 가지를 보탰습니다. 마이크로서비스 간 계약을 먼저 정의하고, 메트릭·트레이스 계측을 앱의 기본 기능으로 넣고, 보안을 나중에 붙이는 요소가 아니라 설계 요소로 다루자는 제안입니다. 이 가운데 텔레메트리는 XI 로그 원칙의 확장으로 볼 수 있는데, 로그·메트릭·트레이스를 하나의 표준 규격으로 계측하는 방법은 OpenTelemetry 란 무엇인가? 글에서 다룹니다.

주의할 점도 있습니다. 12 Factor 는 웹 앱·백엔드 서비스를 염두에 둔 원칙이라, 상태가 본질인 데이터베이스나 배치 중심 워크로드에 기계적으로 적용하면 맞지 않는 부분이 있습니다. 원칙을 체크리스트로 외우기보다 “왜 이 원칙이 필요한가”를 이해하고 우리 시스템에 맞게 적용하는 태도가 중요합니다. 기존 애플리케이션을 옮길 때 인프라만 바꾸는 방식과 애플리케이션까지 다시 설계하는 방식이 어떻게 갈리는지는 클라우드 네이티브 vs 클라우드 글에서 마이그레이션 방식 기준으로 비교합니다.

12가지 원칙을 관통하는 정신은 하나입니다. 애플리케이션을 환경에 덜 묶이게 만들어, 어디서든 복제하고 어디서든 버릴 수 있게 하는 것입니다. 컨테이너와 쿠버네티스가 인프라를 그렇게 만들어 놓았으니, 이제 애플리케이션이 답할 차례입니다.

Q. 12 Factor App 이란 무엇인가요?

클라우드에서 확장·이식 가능한 애플리케이션을 만들기 위한 12가지 설계 원칙입니다. Heroku 가 2011년 공개했으며, 설정 분리·무상태 프로세스·로그 스트림 등 컨테이너·쿠버네티스 환경의 전제 조건과 맞물려 표준 교양으로 쓰입니다.

Q. 12가지 원칙 중 가장 먼저 적용할 것은 무엇인가요?

III 설정 분리와 VI 무상태 프로세스입니다. 설정을 환경 변수로 빼면 하나의 이미지로 모든 환경에 배포할 수 있고, 상태를 프로세스 밖으로 밀어내면 수평 확장이 가능해집니다. 이 둘이 막혀 있으면 나머지 원칙의 효과도 제한됩니다.

Q. 12 Factor 는 쿠버네티스 전용 원칙인가요?

아닙니다. 특정 플랫폼과 무관한 일반 원칙이며 발표 시점은 쿠버네티스 등장 이전입니다. 다만 ConfigMap·Secret(설정), HPA(동시성), Job(관리 프로세스)처럼 쿠버네티스가 각 원칙의 구현 수단을 기본 제공하므로, 쿠버네티스 환경에서 실천 비용이 가장 낮습니다.

Q. 기존 레거시 앱도 12 Factor 로 바꿀 수 있나요?

단계적으로 가능합니다. 설정 외부화 → 로그 표준 출력 전환 → 세션 등 상태 외부화 → 우아한 종료 구현 순으로 고치면, 전면 재작성 없이도 컨테이너 환경에서 운영 가능한 수준까지 도달할 수 있습니다.

Q. 세션을 쓰는 자바 웹 애플리케이션도 무상태로 만들 수 있나요?

가능합니다. 세션 자체를 없애는 것이 아니라 저장 위치를 프로세스 밖으로 옮기는 방식입니다. 서블릿 표준의 <distributable/> 선언과 외부 세션 저장소 연동을 쓰면 애플리케이션 코드를 크게 고치지 않고도 파드가 교체될 때 로그인이 풀리지 않는 구조를 만들 수 있습니다.

Q. 12 Factor 만 지키면 클라우드 네이티브 앱이 되나요?

필요 조건이지 충분 조건은 아닙니다. 12 Factor 는 애플리케이션 설계 쪽 준비이고, 컨테이너·오케스트레이션·CI/CD·관측성 같은 플랫폼 요소와 결합되어야 합니다. API 우선·텔레메트리·인증 같은 확장 논의도 함께 살펴보시기 바랍니다.

• The Twelve-Factor App 이란 무엇인가요? — 원문 12개 원칙의 정의와 등장 배경
• 클라우드 네이티브란? 개념·구성요소·도입 전략 가이드 — 상위 개념 정리
• 클라우드 네이티브 4대 요소 — 컨테이너·MSA·CI/CD·DevOps
• 클라우드 네이티브 vs 클라우드 — 마이그레이션 방식으로 보는 차이
• 쿠버네티스 Pod 완벽 가이드 — 파드 생명주기와 종료 처리
• 쿠버네티스 아키텍처 완전 정복 — Service·HPA·Job 이 놓이는 자리
• Tomcat 세션 클러스터링의 진실 — VI 프로세스 원칙이 깨지는 현장
• Redis로 세션 관리? 숨겨진 위험 — 외부 세션 저장소 선택 기준
• 컨테이너 레지스트리 이미지 관리 방안 — V 빌드·릴리스·실행 분리의 실무
• OpenTelemetry 란 무엇인가? — XI 로그를 넘어선 텔레메트리

• The Twelve-Factor App 공식 한국어 번역
• CNCF Cloud Native Glossary — Stateless Apps
• CNCF 클라우드 네이티브 용어집 — 클라우드 네이티브 앱(한국어)
• Kubernetes 공식 문서 — 구성: ConfigMap/Secret(한국어)
• Kubernetes 공식 문서 — 파드 생명주기(한국어)
• OCTO Technology — The twelve factors Kubernetes