[웹앱 실무 92] 배포 - 환경 분리, 개발과 운영

배포 이야기를 이어 가다 보면 자꾸 환경이라는 말이 나와요. 개발 환경에선 됐는데 운영 환경에선 안 된다, 검증 환경에서 먼저 확인하자 같은 식으로요. 이번 편에서는 이 환경을 나눈다는 게 대체 무슨 뜻인지, 왜 굳이 여러 개로 나누는지, 각 환경이 서로 어떻게 다른지를 차분히 풀어 볼게요. 배포의 밑바탕에 깔린 개념이라, 여기가 흐릿하면 뒤 이야기들이 자꾸 헷갈리거든요.

저는 처음 일을 배울 때 환경이 하나뿐인 곳에서 시작했어요. 코드를 고치면 곧바로 실제 사용자가 쓰는 곳에 반영됐죠. 그때는 그게 당연한 줄 알았는데, 실수 한 번에 사용자가 쓰던 서비스가 통째로 멈추는 걸 겪고 나서야 왜 환경을 나눠야 하는지 뼈저리게 알았어요. 그 경험을 여러분은 안 겪으셨으면 하는 마음으로, 이 편을 꾹꾹 눌러 담아 볼게요.

왜 환경을 굳이 나눠요?

환경을 나누는 가장 큰 이유는 실험과 실제를 갈라 놓기 위해서예요. 우리는 코드를 만들면서 수없이 시도하고 실패하고 고쳐요. 그런데 이 실험을 실제 사용자가 쓰는 곳에서 하면, 실패할 때마다 사용자가 그 실패를 고스란히 겪게 되거든요. 그래서 마음껏 실패해도 되는 연습장과, 절대 깨지면 안 되는 실전 무대를 따로 두는 거예요.

이걸 안 나누면 어떤 일이 벌어지냐면, 개발자가 뭔가 고칠 때마다 사용자가 인질이 돼요. 저장 버튼 하나 고치다 실수하면 사용자 결제가 막히고, 화면 색 하나 바꾸다 실수하면 사용자한테 깨진 화면이 그대로 나가죠. 개발자는 늘 조마조마하고, 그래서 겁이 나 변경을 미루게 돼요. 환경을 나누면 이 두려움이 사라져요. 연습장에서 실컷 깨 보고 확인한 것만 무대에 올리니까요.

제가 환경 하나뿐인 곳에서 겪은 사고도 딱 이랬어요. 사소한 문구 하나 고치려다 실수했는데, 그게 곧바로 사용자 화면에 나가 버렸거든요. 몇 분 만에 알아채고 되돌렸지만, 그 몇 분 동안 서비스를 쓴 분들은 깨진 화면을 봤죠. 그날 저는 실험할 곳이 따로 없다는 게 이렇게 위험하구나를 온몸으로 배웠어요. 그 뒤로 어떤 작은 프로젝트를 맡아도 연습장부터 먼저 마련하는 게 버릇이 됐어요.

또 하나 중요한 건, 환경 분리가 사용자 데이터를 지킨다는 점이에요. 실험을 실제 데이터로 하면, 잘못된 코드가 진짜 사용자의 정보를 망가뜨릴 수 있어요. 개발 환경엔 가짜 데이터를 두고 거기서 실험하면, 무슨 짓을 해도 실제 사용자는 안전하죠. 저는 이 데이터를 지킨다는 이유만으로도 환경 분리는 타협할 수 없다고 봐요.

환경을 나누면 협업도 훨씬 매끄러워져요. 여러 사람이 같은 실제 서비스를 두고 동시에 실험하면 서로의 변경이 뒤엉켜 누구 탓에 깨졌는지조차 모르게 되거든요. 각자 자기 연습장에서 만들고, 확인된 것만 공용 무대에 합치면, 남의 실험이 내 작업을 무너뜨리는 일이 없어요. 저는 팀이 커질수록 이 실험의 격리가 얼마나 소중한지 절감했어요. 환경 분리는 사람이 여럿일 때 특히 빛을 발하는 장치더라고요.

환경은 보통 몇 개로 나눠요?

가장 흔한 구성은 세 개예요. 개발자가 만들면서 쓰는 개발 환경, 배포 전에 확인하는 검증 환경, 실제 사용자가 쓰는 운영 환경이죠. 코드는 개발에서 태어나 검증을 거쳐 운영으로 승격해 가요. 마치 시험을 여러 단계 통과해야 실전에 나가는 것처럼요. 각 단계는 앞 단계보다 더 실제에 가깝고, 그만큼 더 조심스럽게 다뤄요.

개발 환경은 개발자 각자의 컴퓨터인 경우가 많아요. 여기선 뭐든 마음대로 바꾸고 껐다 켜도 아무도 신경 안 써요. 검증 환경은 운영이랑 똑 닮게 꾸민 곳이에요. 실제와 최대한 비슷하게 만들어 두고, 여기서 문제가 없으면 운영에서도 괜찮을 거라 믿는 거죠. 운영 환경은 진짜 무대라, 여기선 실험이 금지고 검증을 통과한 것만 올라와요.

팀이 크거나 서비스가 복잡하면 환경을 더 잘게 나누기도 해요. 여럿이 각자 실험할 여러 개의 미리보기 환경을 두거나, 실제 트래픽 일부만 새 버전에 흘려 보는 부분 운영 환경을 두기도 하죠. 반대로 아주 작은 프로젝트는 개발이랑 운영 둘만으로 시작하기도 해요. 중요한 건 개수가 아니라, 실험하는 곳과 실전인 곳이 확실히 갈려 있느냐예요.

저는 환경 개수를 정할 때 이 환경이 정말 제 몫을 하는가를 물어요. 이름만 있고 아무도 안 쓰는 환경, 운영이랑 너무 달라 확인 의미가 없는 환경은 오히려 관리 부담만 늘리거든요. 환경 하나를 늘리면 그만큼 설정도, 데이터도, 돌봐야 할 것도 늘어나요. 그러니 필요해서 나누는 거지, 남들이 세 개 쓰니까 우리도 세 개 쓰는 건 아니에요. 각 환경이 뚜렷한 쓸모를 갖게 두는 게 좋아요.

환경마다 뭐가 달라요?

환경이 다르다는 건, 같은 코드가 서로 다른 설정으로 돈다는 뜻이에요. 앞 편에서 말한 한 번 빌드하고 여러 번 배포한다는 원칙 기억나시죠. 산출물은 하나인데, 그게 개발에선 개발용 설정으로, 운영에선 운영용 설정으로 도는 거예요. 코드는 같지만 바라보는 데이터베이스가 다르고, 연결하는 바깥 서비스가 다르죠.

구체적으로 뭐가 달라지냐면, 우선 데이터베이스 주소가 달라요. 개발은 가짜 데이터가 든 연습용 데이터베이스를, 운영은 진짜 사용자 데이터가 든 데이터베이스를 봐요. 바깥 서비스도 마찬가지예요. 결제 같은 건 개발에선 돈이 실제로 안 오가는 시험용을, 운영에선 진짜 결제가 되는 것을 연결하죠. 이걸 헷갈리면 개발하다 진짜 결제가 나가는 사고가 터져요.

이 설정들을 코드 안에 직접 박아 두면 절대 안 돼요. 산출물은 하나여야 하니까, 설정은 코드 밖에서 환경마다 다르게 주입해야 하거든요. 그래서 환경 변수라는 걸 쓰는데, 이 이야기는 바로 다음 편에서 깊이 다룰 거예요. 지금은 코드는 같고 설정만 환경별로 갈아 끼운다는 그림만 확실히 붙잡아 두세요.

설정 말고 또 달라지는 게 겉으로 얼마나 떠드느냐예요. 개발 환경에선 무슨 일이 벌어지는지 시시콜콜 기록을 잔뜩 남기고 오류도 자세히 화면에 보여 줘요. 개발자가 문제를 빨리 찾아야 하니까요. 반대로 운영에선 그런 자세한 속사정을 사용자한테 안 보여줘요. 오류 내용에 서비스의 속살이 담기면 그게 공격의 실마리가 되거든요. 같은 코드라도 개발에선 수다스럽게, 운영에선 입을 다물게 설정으로 조절하는 거죠.

검증 환경은 왜 그렇게 중요해요?

세 환경 중에 저는 검증 환경을 특히 아껴요. 개발이랑 운영 사이에서 마지막 안전망 역할을 하거든요. 여기서 걸러 내지 못한 문제는 곧바로 사용자한테 가니까, 검증 환경이 얼마나 운영이랑 닮았느냐가 배포의 안전도를 크게 좌우해요. 검증이 운영이랑 딴판이면, 검증을 통과해도 운영에서 깨질 수 있죠.

그래서 검증 환경은 운영이랑 최대한 비슷하게 만드는 게 핵심이에요. 서버 종류도 비슷하게, 데이터 양도 어느 정도 비슷하게, 연결하는 바깥 서비스도 같은 구조로요. 저는 예전에 검증엔 데이터가 몇 개뿐이라 빨랐는데, 운영엔 데이터가 수백만 개라 같은 화면이 한참 느렸던 일을 겪었어요. 검증이 운영의 규모를 안 닮았던 탓이죠.

물론 검증을 운영이랑 완전히 똑같이 만드는 건 비용이 만만치 않아요. 그래서 현실에선 중요한 부분만 닮게 하는 타협을 해요. 데이터 양이 성능에 크게 영향을 주는 서비스면 데이터 규모를 비슷하게, 바깥 연동이 자주 문제면 그 연동을 진짜처럼 흉내 내는 식이죠. 어디서 사고가 자주 나는지를 보고, 그 부분을 집중해서 닮게 하는 게 요령이에요.

한 가지 강조하고 싶은 건, 검증 환경 데이터에 진짜 사용자 정보를 그대로 복사해 오면 안 된다는 거예요. 편하다고 운영 데이터를 통째로 검증에 갖다 두면, 검증 환경이 뚫렸을 때 진짜 개인정보가 새는 셈이 되거든요. 그래서 저는 운영 데이터를 검증에 쓸 땐 이름이나 연락처 같은 민감한 부분을 알아볼 수 없게 뭉개서 가져와요. 규모랑 형태는 실제를 닮되, 내용은 가짜로 바꾸는 거죠. 닮게 만들되 사용자를 위험에 빠뜨리지 않는 이 균형이 중요해요.

환경을 나눌 때 뭘 조심해요?

첫째로 조심할 건 환경끼리 데이터가 새는 거예요. 개발 환경이 실수로 운영 데이터베이스를 바라보게 설정돼 있으면, 연습하다 진짜 데이터를 망가뜨릴 수 있어요. 저는 이걸 막으려고 각 환경이 자기 것만 볼 수 있게 접근을 딱 갈라 둬요. 개발에선 운영 데이터베이스에 아예 손이 안 닿게 하는 거죠. 이 경계가 흐릿하면 언젠가 사고가 나요.

둘째는 환경마다 코드가 미묘하게 달라지는 거예요. 개발에서만 도는 특별한 코드, 운영에서만 켜지는 숨은 코드가 늘어나면, 검증한 것과 실제 도는 게 달라져요. 그러면 검증의 의미가 사라지죠. 저는 코드는 모든 환경에서 똑같이 돌게 하고, 다른 건 오직 설정뿐이게 만들려 애써요. 환경별로 코드가 갈리기 시작하면 관리가 지옥이 되거든요.

셋째는 환경이 방치돼 서로 멀어지는 거예요. 처음엔 검증이랑 운영이 닮았는데, 운영만 계속 손보고 검증은 내버려 두면 둘이 점점 달라져요. 그러다 어느 순간 검증이 운영이랑 딴 세상이 되어, 검증을 통과해도 못 믿게 되죠. 저는 운영을 바꿀 때 검증도 같이 챙기는 습관을 들여, 둘이 나란히 가게 관리해요. 환경 분리는 만들어 두고 끝이 아니라 꾸준히 돌봐야 하는 거예요.

넷째는 환경을 헷갈려 엉뚱한 곳에 배포하는 거예요. 개발에 올린다는 게 손이 미끄러져 운영에 올라가는 사고, 생각보다 흔해요. 저는 이걸 막으려고 각 환경을 눈에 확 띄게 다르게 꾸며 둬요. 운영 화면 한구석엔 조용히 있고, 검증 화면엔 여기는 검증입니다 하는 표시를 큼직하게 띄우는 식이죠. 배포 명령도 운영에 올릴 땐 한 번 더 확인을 묻게 만들어, 무심코 저지르는 사고를 막아요. 사람은 실수하니까, 실수해도 바로 알아채게 만드는 장치가 필요해요.

작은 팀도 환경을 나눠야 해요?

혼자 하거나 팀이 아주 작으면 환경 나누는 게 사치 아닌가 싶을 수 있어요. 저도 처음엔 그랬어요. 그런데 겪어 보니, 작을수록 오히려 최소한의 분리는 꼭 필요하더라고요. 혼자여도 실수는 하니까, 실수가 곧바로 사용자한테 가는 구조는 규모랑 상관없이 위험하거든요. 다만 작은 팀은 세 개를 다 갖출 필요 없이, 개발이랑 운영 둘만으로 시작해도 충분해요.

요즘은 작은 팀도 환경 분리를 쉽게 할 수 있게 도와주는 도구가 많아요. 앞서 말한 미리보기 배포가 대표적이죠. 운영은 그대로 두고, 새 변경만 담긴 임시 환경을 공짜에 가깝게 만들어 확인할 수 있으니까요. 저는 작은 프로젝트일수록 이런 가벼운 미리보기를 검증 환경 대신 적극 써요. 무겁게 갖추지 않고도 실험과 실전을 가르는 효과를 누릴 수 있거든요.

혼자 하는 분들한테 제가 꼭 권하는 최소한의 습관은, 적어도 운영에 직접 손대지 않는 것 하나예요. 운영 서버에 직접 들어가 코드를 고치는 유혹이 참 큰데, 그렇게 급하게 고친 건 기록에도 안 남고 검증도 안 거쳐서 나중에 반드시 사고로 돌아와요. 아무리 급해도 개발에서 고쳐 확인하고 정식 절차로 올리는 이 한 박자를 지키면, 혼자여도 사고가 확 줄어요. 환경 분리의 정신은 결국 실전을 함부로 건드리지 않는 마음가짐이거든요.

정리하면, 환경 분리는 실험과 실전을 갈라 사용자를 지키는 장치예요. 개발에서 만들고 검증에서 확인해 운영으로 승격하며, 코드는 같되 설정만 환경별로 갈아 끼우죠. 규모가 크든 작든 실수가 곧바로 사용자한테 가지 않게 하는 최소한의 경계는 꼭 필요해요. 다음 편에서는 이 환경별 설정을 실제로 어떻게 다루는지, 그중에서도 특히 조심해야 할 환경 변수랑 시크릿 이야기를 해 볼게요.