프로덕션 환경

프로덕션 환경은 실제 사용자가 쓰는 서비스를 돌리는 환경입니다. 개발자가 고친 코드는 여러 단계를 거쳐 마지막에 이곳에 닿습니다. 여기서 난 오류는 곧바로 사용자가 겪습니다. 실무에서는 줄여서 「프로덕션」이나 「운영 환경」이라고 부릅니다.

쉽고 빠른 이해

프로덕션 환경은 진짜 손님이 드나드는 서비스입니다. 쇼핑몰이라면 사람들이 실제로 주문하고 돈을 내는 그 서버들입니다.

왜 따로 떼어 두나. 만들다 만 코드를 손님이 쓰는 곳에서 시험하면 손님이 그 실수를 그대로 겪습니다. 그래서 시험하는 곳과 손님을 받는 곳을 나눕니다.

어떻게 도나:

1. 개발자가 코드를 고쳐 개발용 환경에서 돌려 봅니다
2. 프로덕션을 흉내 낸 시험장에 올려 한 번 더 확인합니다
3. 문제가 없으면 프로덕션에 올립니다

대가도 있습니다. 서버를 여러 벌 두니 돈과 손이 더 듭니다. 시험장이 프로덕션과 조금만 달라도 거기서 못 본 문제가 프로덕션에서 처음 터집니다.

상세

이 절은 프로덕션 환경이 무엇이고 왜 다른 환경과 떼어 두는지를 봅니다. 먼저 「환경」이라는 말부터 풉니다. 그다음 개발·스테이징·프로덕션 세 환경을 견줍니다. 그 뒤로 프로덕션을 다루는 규칙과 프로덕션에 변경을 안전하게 내보내는 방법을 봅니다.

연극을 떠올리면 가깝습니다. 배우는 연습실에서 같은 장면을 몇 번이고 되풀이합니다. 틀려도 다시 하면 됩니다. 객석에 관객이 앉은 본 공연에서는 대사를 틀리면 관객이 그 실수를 그대로 봅니다.

환경이라는 말

소프트웨어가 돌려면 코드만으로는 모자랍니다. 코드를 올릴 서버, 그 위의 운영체제, 코드를 실행해 주는 런타임, 접속할 데이터베이스, 접속 주소나 비밀번호 같은 설정값이 함께 있어야 합니다. 이것을 한 벌로 묶어 환경이라고 부릅니다.

같은 코드라도 어느 환경에 올리느냐에 따라 보는 데이터와 쓰는 사람이 달라집니다. 같은 주문 서비스 코드를 개발자만 쓰는 환경에 올리면 가짜 주문 몇 건을 봅니다. 프로덕션 환경에 올리면 실제 손님의 주문을 받습니다.

환경을 나누는 까닭

환경이 한 벌뿐이면 모든 실험이 곧 사용자의 일이 됩니다. 개발자가 새 기능을 확인하려고 코드를 올리는 순간 손님도 그 코드를 씁니다. 코드에 버그가 있으면 손님의 주문이 깨집니다.

그래서 환경을 여러 벌 둡니다. 사용자가 없는 환경에서 먼저 돌려 봅니다. 확인이 끝난 것만 프로덕션으로 보냅니다. 버그를 사용자보다 먼저 만나려는 것입니다.

개발·스테이징·프로덕션

흔한 구성은 세 벌입니다. 누가 쓰는지, 무슨 데이터를 담는지, 망가지면 누가 곤란한지가 서로 다릅니다.

스테이징 환경은 프로덕션 바로 앞의 시험장입니다. 서버 구성과 설정을 프로덕션과 되도록 같게 맞춥니다. 프로덕션에 올리기 직전에 「여기서 되면 저기서도 된다」를 확인하려는 환경이라서 그렇습니다.

변경은 이 순서로 앞 환경에서 뒤 환경으로 옮겨 갑니다. 옮길 때마다 확인하는 관문이 있습니다. 개발 환경을 떠날 때는 자동으로 도는 테스트를 통과해야 합니다. 스테이징을 떠날 때는 사람이 출시 전에 한 번 더 확인하고 승인합니다.

flowchart TD
    B["개발 환경"] -->|"자동 테스트 통과"| C["스테이징 환경"]
    C -->|"출시 전 확인 · 승인"| D["프로덕션 환경"]
    D -->|"문제가 나면 되돌린다"| R["롤백 · 이전 버전으로"]

새 코드를 환경에 올려 돌게 하는 일을 배포라고 합니다. 위 그림에서 환경을 옮겨 가는 화살표 하나하나가 배포입니다. 이 순서를 사람 손 대신 도구가 자동으로 밟게 만든 것을 배포 파이프라인이라고 부릅니다.

맨 아래 화살표는 롤백입니다. 프로덕션에 올린 버전에서 문제가 나면 그 전 버전으로 되돌립니다. 고치는 데 시간이 걸리는 동안 사용자를 문제 없는 버전으로 먼저 돌려보냅니다.

프로덕션에만 있는 것

스테이징을 아무리 프로덕션과 같게 맞춰도 옮겨 오지 못하는 것이 있습니다. 첫째는 트래픽입니다. 트래픽은 서비스로 들어오는 요청의 양입니다. 수많은 사용자가 동시에 보내는 요청은 시험장에서 흉내 내기 어렵습니다.

둘째는 실제 데이터입니다. 사용자가 몇 년에 걸쳐 쌓은 데이터에는 개발자가 예상하지 못한 값이 섞여 있습니다. 이름 칸이 비어 있거나 아주 오래된 형식으로 저장된 줄이 그렇습니다.

셋째는 결과의 무게입니다. 프로덕션에서 나간 결제는 실제 돈입니다. 보낸 메일은 실제 사람이 받습니다. 되돌릴 수 없는 일이 여기서 일어납니다.

그래서 어떤 문제는 프로덕션에서 처음 드러납니다. 「스테이징에서는 됐는데」라는 말이 나오는 까닭입니다. 두 환경이 서로 어긋나 생기는 이런 문제를 환경 차이라고 부릅니다.

프로덕션을 다루는 규칙

결과가 무겁기 때문에 프로덕션에는 다른 환경에 없는 규칙이 붙습니다. 첫째는 접근을 좁히는 것입니다. 프로덕션 서버와 데이터베이스에 들어갈 수 있는 사람을 소수로 줄입니다. 실수로 지운 한 줄이 실제 사용자의 데이터이기 때문입니다.

둘째는 변경을 정해진 길로만 들이는 것입니다. 서버에 직접 들어가 파일을 고치지 않습니다. 모든 변경이 배포 파이프라인을 거치게 하면 무엇이 언제 바뀌었는지 기록이 남습니다. 문제가 났을 때 어느 변경 탓인지 찾을 수 있습니다.

셋째는 설정을 코드 밖에 두는 것입니다. 데이터베이스 주소나 비밀번호는 환경마다 다릅니다. 이 값을 코드에 적어 두면 환경을 옮길 때마다 코드를 고쳐야 합니다. 그래서 환경 변수처럼 코드 바깥에서 환경이 넣어 주는 값으로 둡니다. 같은 코드가 어느 환경에 올라가든 그 환경의 값을 읽습니다.

넷째는 늘 지켜보는 것입니다. 프로덕션의 오류율과 응답 시간 같은 값을 쉬지 않고 재어 둡니다. 이 일을 모니터링이라고 합니다. 사용자가 신고하기 전에 이상을 먼저 알아채려고 합니다.

잰 값이 정해 둔 기준을 넘으면 사람에게 연락이 갑니다. 이 연락을 알림이라고 합니다. 알림을 받을 사람은 시간대마다 미리 정해 둡니다. 그 시간에 대응을 맡은 사람을 온콜 담당자라고 부릅니다.

프로덕션에 안전하게 내보내기

스테이징에서 모든 문제를 잡을 수는 없습니다. 새 버전을 프로덕션에 올릴 때도 한꺼번에 바꾸는 위험을 줄이는 방법이 쓰입니다. 길은 크게 둘입니다.

하나는 새 버전을 일부 사용자에게만 먼저 내보내는 것입니다. 문제가 나도 겪는 사람이 적습니다. 다른 하나는 옛 버전을 그대로 켜 둔 채 새 버전으로 넘어가는 것입니다. 문제가 나면 옛 버전으로 곧바로 돌아갈 수 있습니다.

흔히 쓰는 방식 셋을 견주면 이렇습니다. 방식마다 위험을 줄이는 길이 다릅니다.

카나리 배포와 기능 플래그처럼 새 버전을 만나는 사용자 비율을 단계마다 늘려 가는 방식을 통틀어 단계적 출시라고 부릅니다.

배포를 재는 지표의 기준 시점

DORA(DevOps Research and Assessment)는 팀이 소프트웨어를 얼마나 잘 내보내는지 연구해 온 조직입니다. 이 조직이 내놓은 지표 몇 가지가 팀의 배포 성적을 재는 데 널리 쓰입니다.

그 가운데 둘은 변경이 프로덕션에 닿은 때를 기준 시점으로 삼습니다. 하나는 배포 빈도입니다. 프로덕션에 배포한 횟수를 셉니다.

다른 하나는 변경 리드 타임입니다. 코드 변경을 저장소에 기록하는 일을 커밋이라고 합니다. 변경 리드 타임은 커밋한 때부터 그 변경이 프로덕션에서 돌기 시작할 때까지 걸린 시간을 잽니다.

스테이징에 올린 것은 여기에 세지 않습니다. 사용자에게 닿아야 변경이 가치를 내기 때문입니다. 스테이징에 몇 번을 올렸든 사용자가 쓰기 전까지 그 변경은 아직 출시되지 않은 것입니다.

환경을 몇 벌 두나

모든 서비스가 세 벌을 두지는 않습니다. 사용자가 적고 망가져도 피해가 작은 서비스는 개발 환경과 프로덕션 두 벌로 버티기도 합니다. 반대로 결제처럼 실수가 비싼 서비스는 스테이징 앞에 시험 담당자 전용 환경을 한 벌 더 둡니다.

환경을 늘리면 대가가 따릅니다. 서버 비용이 벌마다 붙습니다. 벌마다 설정을 프로덕션과 맞춰 두는 수고도 듭니다. 맞추기를 게을리하면 스테이징이 프로덕션과 어긋납니다. 그러면 스테이징에서 통과한 것이 프로덕션에서 깨집니다. 여러 환경을 같은 모양으로 찍어 내려고 서버 구성을 코드로 적어 두는 방법이 코드형 인프라입니다.

관련 항목

프로덕션 앞에 서는 환경

개발 환경 · 로컬 개발 환경 · 테스트 환경 · 스테이징 환경 · QA 환경

프로덕션으로 변경을 옮기는 과정

배포 · 릴리스 · 배포 파이프라인 · 지속적 통합 · 지속적 배포 · 커밋에서 배포까지 · 릴리스 엔지니어링

새 버전을 프로덕션에 안전하게 내보내는 배포 방식

카나리 배포 · 블루-그린 배포 · 단계적 출시 · 기능 플래그 · 다크 런치 · 롤링 업데이트

프로덕션 장애에 대응하는 수단

롤백 · 핫픽스 · 인시던트 · 온콜 · 포스트모템 · 서비스 복구 시간

프로덕션 상태를 지켜보는 도구

모니터링 · 관측성 · 로그 · 알림 · SLO · 트래픽

프로덕션에 닿은 때를 기준으로 재는 지표

DORA · 배포 빈도 · 변경 리드 타임 · 변경 실패율 · 배포 재작업률

환경마다 달리 주는 설정

환경 변수 · 설정 관리 · 비밀 관리 · 코드형 인프라 · 환경 차이 · 실행 환경

프로덕션 환경을 이루는 구성 요소

서버 · 운영체제 · 데이터베이스 · 웹 서버 · 애플리케이션 서버