환경

서버 한 대로 서비스를 굴리던 시절에는 코드를 고치면 그 서버에 바로 올렸습니다. 확인할 곳이 거기뿐이었기 때문입니다. 잘 돌아가면 다행이고 잘못되면 그 순간 화면을 보고 있던 사용자가 가장 먼저 알았습니다.

그래서 배포는 새벽 일이 됐습니다. 사람이 가장 적은 시간을 골라 올리고, 깨지면 급히 되돌리고, 아침에 무슨 일이 있었는지 정리하는 식입니다. 결제 화면을 고친 날에는 담당자가 회사에 남아 주문 건수가 평소만큼 들어오는지 새로고침하며 지켜봤습니다. 숫자가 뚝 떨어지면 그게 되돌리라는 신호였습니다.

문제는 확인하는 곳과 사용자가 쓰는 곳이 같다는 데 있었습니다. 환경은 그 둘을 떼어 놓으려고 만든 구분입니다. 사용자가 들어오지 않는 공간을 따로 두고, 같은 코드를 거기서 먼저 굴려 본 다음 통과한 것만 앞으로 내보냅니다. 실수의 값을 사용자가 아니라 팀이 치르도록 자리를 옮긴 것입니다.

기본은 세 구간입니다. 개발·스테이징·운영 순서로 놓이고, 뒤로 갈수록 실제 사용자와 가까워집니다.

1. 개발 환경 — 만드는 사람이 각자 쓰는 공간입니다. 보통 본인 노트북이고, 안에 들어 있는 자료도 직접 만들어 넣은 가짜입니다. 서버를 몇 번이고 껐다 켜도 아무 일이 일어나지 않습니다. 망가뜨려도 되는 곳이라는 점이 이 구간의 쓸모입니다.
2. 스테이징 환경 — 운영과 최대한 비슷하게 꾸며 둔 시험장입니다. 서버 구성과 연결된 바깥 서비스를 같은 모양으로 맞춰 두고, 실제 사용자 대신 팀이 들어가 눌러 봅니다. 결제처럼 돈이 오가는 기능은 카드사가 따로 내주는 시험용 창구에 연결해 두어 실제로는 돈이 빠져나가지 않습니다.
3. 운영 환경 — 실제 사용자가 들어오는 곳입니다. 진짜 자료가 쌓이고 진짜 결제가 일어납니다. 여기서만 접근 권한을 사람 단위로 조입니다. 개발 환경은 팀 누구나 들어가지만 운영 서버의 자료를 직접 열어 볼 수 있는 사람은 두세 명으로 묶어 둡니다.

세 구간을 가르는 기준은 넷입니다. 누가 들어오는지, 어떤 자료가 들어 있는지, 규모를 얼마나 갖췄는지, 잘못됐을 때 무엇을 잃는지입니다. 앞의 둘은 대체로 원본과 닮게 맞출 수 있지만 규모는 그러기 어렵습니다. 운영이 서버 12대로 도는 서비스라도 스테이징은 2대로 꾸리는 팀이 많습니다. 24시간 켜 두는 서버를 한 벌 더 유지하는 비용이 그대로 늘기 때문입니다.

앞 구간에서 뒤 구간으로 넘어갈 때마다 정해진 관문을 통과합니다. 관문은 둘입니다.

1. 개발에서 스테이징으로 — 고친 코드를 다른 사람이 읽고 승인하고, 기계가 돌리는 자동 시험이 전부 통과해야 합니다. 그다음 빌드가 성공해야 합니다. 빌드는 사람이 읽으라고 쓴 코드를 기계가 실행할 수 있는 형태로 바꾸는 과정인데, 여기서 나온 결과물 덩어리를 아티팩트라고 부릅니다.
2. 스테이징에서 운영으로 — 사람이 직접 들어가 주요 화면을 눌러 보고, 그 결과를 보고 내보낼지를 정합니다. 신규 가입부터 결제까지 한 바퀴 도는 순서를 미리 적어 두고 그대로 밟습니다.

구간을 옮길 때 코드를 다시 빌드하지 않는 것이 규칙입니다. 스테이징에서 확인한 아티팩트를 그대로 운영으로 옮깁니다. 구간마다 새로 빌드하면 확인한 물건과 올라가는 물건이 달라져, 스테이징을 통과한 사실이 아무것도 보장하지 않게 됩니다.

그러면 같은 물건이 구간마다 다르게 굴러야 하는 부분은 어떻게 하느냐가 남습니다. 그 자리를 환경 변수가 맡습니다. 어느 주소의 데이터베이스를 볼지, 시험용 결제 창구를 볼지 진짜 창구를 볼지를 코드 바깥에서 꽂아 줍니다. 그중에서도 새면 안 되는 값은 시크릿 관리로 따로 금고에 넣어 두고 실행되는 순간에만 꺼냅니다.

구간끼리 조금씩 벌어지는 것은 시간이 지나면 저절로 생깁니다. 운영에만 급하게 서버 설정을 하나 바꿔 두고 스테이징에는 반영하지 않는 식입니다. 코드형 인프라로 서버 구성을 코드에 적어 두면 같은 파일에서 세 구간을 만들게 되므로 이 틈이 줄어듭니다.

"로컬에서는 되는데 운영에서만 안 됩니다."

내 노트북과 운영 서버 사이에 설정이나 버전 차이가 있다는 뜻이고, 그 차이를 찾는 것이 다음 할 일이라는 말입니다.

"그거 스테이징에 먼저 올려 주세요. 제가 내일 오전에 보겠습니다."

바로 사용자에게 내보내지 말고 확인할 시간을 달라는 요청입니다.

"지금 스테이징이 운영이랑 많이 달라져서 거기서 통과해도 믿기 어렵습니다."

시험장이 원본과 벌어져 관문 노릇을 못 하고 있으니 먼저 맞춰야 한다는 말입니다.

페이지덱에서는 새 기능이 파이프라인을 타고 세 구간을 차례로 지납니다. 태오가 코드를 합치면 기계가 빌드와 시험을 돌리고, 통과한 아티팩트가 스테이징에 올라갑니다. 지현과 민서는 그 주소에 들어가 화면을 눌러 보고, 문구가 어색하거나 동작이 어긋나면 그 자리에서 적어 둡니다. 여기서 걸린 문제는 사용자가 겪지 않습니다.

운영으로 넘기는 결정은 스테이징 확인이 끝난 뒤에 이뤄집니다. 기업 고객이 쓰는 기능이면 수아가 미리 공지할 시간을 달라고 요청해 하루이틀 늦추기도 합니다. 이때도 다시 빌드하지 않고 스테이징에 있던 그 아티팩트를 그대로 올립니다.

스테이징을 통과하면 운영에서도 똑같이 돌아간다고 믿는 경우가 많습니다. 두 곳을 비슷하게 맞춰 두었으니 자연스러운 기대입니다. 하지만 비슷하게 맞추는 것은 구성이지 규모와 자료가 아닙니다. 스테이징에는 자료가 200건 들어 있고 운영에는 200만 건이 쌓여 있으면, 목록을 불러오는 데 스테이징에서 0.1초 걸리던 화면이 운영에서는 8초가 걸립니다. 이 차이를 모른 채 넘기면 문제를 사용자가 먼저 발견하고, 되돌리는 동안 그 기능은 켜졌다 꺼졌다를 반복합니다.

환경을 서버 대수 이야기로 읽는 것도 흔합니다. 스테이징이 노트북에 띄운 화면 하나면 충분하다고 보는 시각인데, 환경을 가르는 것은 대수가 아니라 자료와 권한입니다. 같은 서버에 폴더만 나눠 두고 두 구간이라고 부르면 개발 중인 코드가 운영 자료를 건드릴 수 있습니다. 실제로 사고가 나는 자리는 대부분 여기입니다. 시험 삼아 돌린 자료 정리 스크립트가 운영 데이터베이스를 보고 있었던 식입니다.