안녕하세요. 다름아니라 혹시 개발/테스트/운영 서버를 각각 나누는 이유가 있을까요?
보안상 문제가 되서 저렇게 나눈 건지 아니면 소스코드 유출 방지를 위해 나누는 것인지 궁금합니다.
그리고 개발이나 테스트 서버가 외부 통신이 된다면 무슨 문제가 있을까요?
(개인정보가 없다는 전재아래 외부 통신을 말씀드립니다)
점점 알아가야될 것은 많아지는데 하나하나 쉽지 않네요. 조언부탁드립니다.
익명 사용자
2023-02-22 (수)
조회수 622
11개의 댓글이 있습니다.
많은 회사들이 3단계로 구분해서 관리를 하고 있습니다.
Dev / Staging / Product 로 나누고 있습니다.
3단계로 나누는 이유는 서비스의 안정성을 위해서라고 보시면 됩니다.
Dev는 개발자들이 개발 결과를 검증하고 테스트하는 용도로 사용하고요.
Staging은 기획자라든가, QA라든가 등등 사용자들을 위한 테스트 용도로 사용 합니다.
Product는 당연히 최종 사용자를 위한 시스템이 되겠고요.
이처럼 나누는 이유는 서비스의 안정적인 제공을 위한 다양한 테스트를 진행 하기 위함 입니다.
3단계로 나눠도 꼼꼼하게 테스트 하지 않으면 문제는 발생하게 됩니다.
보안적이 측면, 운영적인 측면에서 이유를 찾을 수 있겠네요.
한대로 다 운영할 수 도 있지만 이렇게 되면 각각에 목적에 맞게 운영하기 불가능하고
보안적인 측면에서도 매우 취약해지죠.
서비스 안정성도 무시 못하구요
글로벌 대형 밴더도 수없이 테스트 하고 라이브 배포 해도 패치 문제로 롤백하는 경우가 있습니다.
내부 업무용도 단순 조회 기능이 아닌 core 부분은 연계된 기능이 많기때문에
운영 서버에서 바로 적용했을때 문제가 되는 경우가 많기때문에
운영/개발/테스트 환경을 구분하고 장비만의 구분이 아니라 망까지도 구분합니다.
최종적으로는 서비스의 안정성 때문이죠...
운영 되고 있는 시스템에 소스를 변경 하거나, 구성 변경 등 때문에 서비스가
다운 되면 문제가 되거나, 비용이 발생이 되기 때문에
개발 서버를 두게 되고, 이를 테스트 하기 위해서 테스트 서버를 두게 되고...
모든게 서비스의 지속성과 안정성 때문이라고 보시면 됩니다.
결국은 비지니스의 안정성을 위해서 나누어 개발하고 테스트 하고 최종 경과를 반영 하는 구조 일거라고 봅니다.
개발은 보통 개발자 pc로 합니다.
개발자 본인이 맘대로 멈추고 가동하고 수정하고 삭제하고 다 해도 됩니다. 개발과정에서 오류로 가동이 안되는 경우도 빈번합니다.
테스트는 개발자 각각이 개발한 소스를 본인들과 여러툴을 통해서 1차 검증한 소스를 모아서 개별 혹은 통합테스트를 진행합니다. 보통 불완전한 소스는 필터가되어 올라오기 때문에 임의로 중단하지 않고 계획에 의해 운영됩니다. 그래서 더 안정적인 테스트가 가능합니다.
테스트에서 최종적으로 이상이 없다고 판단되는 부분을 운영에 배포합니다. 실제 서비스에 반영됩니다.
개발, 테스트를 외부에서 차단하는 것은 공사장에서 완공전까지 외부인을 출입을 통제하는 이유와 비슷합니다
안녕하세요. 다름아니라 혹시 개발/테스트/운영 서버를 각각 나누는 이유가 있을까요?
-> 운영 서버에 배포하기 전 여러 업데이트와 서비스 변경에 대한 사전 테스트 등을 하기 위함으로 사용했었습니다. (연동 서버 구성 변경, 보안 업데이트 등등 많죠!)
보안, 소스코드 유출 방지도 모두 포함되기도 하구요 !
그리고 개발이나 테스트 서버가 외부 통신이 된다면 무슨 문제가 있을까요?
-> 개발,테스트 등 내부의 어떤 서버든 외부와 통신하는 건 보안 상 문제가 될 수 있죠 !
하지만 부서 및 근무 환경 마다 외부와 통신이 되야하니 어쩔 수 없이 허용을 할 수 밖에 없는데
그래서 보안 정책 등을 운영하고 유관 부서와 협의해서 최소한만 허용한다던지 하고 있습니다 !
개발이나 test 서버를 외부통신을 하게되면
개발했던 중요 데이터가 외부 유출 될수 있겠죠
Test시 필요할때 부분적으로 통신되게 하면서
진행해야 하죠
개발이나, 테스트용 서버는 검증되지 않은 다양한 시도를 해 보게 됩니다.
검증되지 않은 다양한 시도라는 것은 서버에 큰 스트레스를 줄 수도 있고, 시스템에 심각한 장애를 유발할 가능성도 있는 것이고요.
서버에 문제가 생겨서 재 부팅해 봐야 하는 경우도 종종 발생하게 되는 것이고요.
운영 서버라는 것은 업무용으로 안정성이 최우선입니다.
365일 24시간 계속 작동하면서 안정적인 서비스를 하는 것을 목표로 하는 것이 운영 서버입니다.
운영서버와 개발, 테스트 서버를 함께 사용한다는 것은 검증되지 않은 시도로 문제가 발생할 수 있어 운영 서버로서는 치명적인 상황이 빠질 수 있기 때문에 별도 운영하게 됩니다.
개발 서버와 테스트 서버는 분리해서 사용할수도 있고, 개발 환경에 따라 함께 사용할 수도 있겠지만, 운영 서버는 가능한 별도로 해서 최대한의 안정성을 보장해 주는 것이 맞습니다.
보안적인 문제도 일부 있을 수 있으나 보안 문제보다는 안정성의 문제라고 보는게 더 맞을 것 같습니다.
기본적으로는 규모의 문제가 있습니다.
개발서버는 말 그대로 개발을 하기 때문에 잦은 수정과 변경 로그가 발생하게 될 거고 여기서 어느정도 이상의 사용성 확보 및 실제 데이터들이 돌아가며 생기는 문제에 대해 체크하는게 테스트서버가 되겠죠.
실제 운영서버는 테스트서버에서 해당 코드의 수정부분이 안정화가 되어 문제가 없다고 판단될 때 최종적으로 올려지는 개념입니다. 당연히 갑자기 재부팅이 된다거나 서비스종료 재시작이 발생하는데는 한계가 있게 되겠죠.
개발인원이 적을수록, 테스트하는 인원도 몇명 안되고 데이터도 적을 수록, 최종 시스템의 사용자수가 적을수록 3가지가 나눠질 필요성이 적을 수 있습니다.
하지만 데이터가 많아질 수록, 최종적인 운영시스템의 사용자 수가 많을 수록 의도되지 않은 동작으로 인한 문제에 대한 해결방법이 요원해집니다.
게임으로 치자면, 게임을 개발하는 과정에서 수치에 대해 이렇게도 저렇게도 넣어보며 하다가 코드가 꼬이거나 여러 문제가 생기면 바로 서비스를 종료하고 재시작등을 하거나, 재시작을 해야만 반영되는 수치들에 대해서 자유로이 처리가 가능합니다. 개발서버에서 뭘 하는 사용자는 보통 내부인력이고 내부적인 소통을 통해 잠시 정리가 가능하죠.
테스트서버쯤 되면 이제 개발인원이 아닌 테스트인원이 일부 들어갈 수 있을겁니다. 이때 수치가 마구 바뀌는게 아니고 타겟으로 세팅된 수치를 반영시켜 실제 돌아갈 때 생길 수 있는 문제점들에 대한 결과값을 볼 수 있습니다. 여기서 문제가 되거나 너무 밸런스에 문제가 있겠다 싶으면 롤백, 괜찮으면 운영서버에 반영이 되겠죠.
운영서버로 들어가 그 반영된 로직이 돌기 시작했는데, 미처 발견하지 못한 버그가 있다면? 그래서 그걸 기반으로 게임 내 경제라던지 뭔가의 반사이익을 얻은 인원들이 발생했다면? 몇명 없고 상황에 따라 처리가 가능하다면 해당 계정들 정도만 롤백을 하면 문제가 없을겁니다. 하지만 아이템이 계속 나오고 그게 유저간 거래가 되기 시작해서 수도없이 돌아버렸다면? 결국 백섭을 해야 한다는 이야기인데 게임서비스사 기준에서 백섭이라는 말 만큼 치욕스러운 이야기는 없을겁니다.
게임이 아닌 비즈니스에서도 백섭이라는 상황이 나와서는 아니될 것이고, 그에 따른 단계적 절차라는건 그래서 필요합니다.
테스트서버와 개발서버가 외부통신이 되는것에 대해선 소스코드나 DB쪽 연결통로 열어주는거 아닌 이상 실제론 심각한 문제를 끼칠 일은 없을겁니다. 대신 접근에 대해선 깔끔한 관리를 해야 할 필요가 있겠죠.
말씀하신 것처럼 개발 및 테스트 서버가 외부와 통신이 된다면 보안적인 측면이 가장 크죠
대표적으로 SAP를 예를 들겠습니다. PRD 서버의 경우 내부적인 프로세스 서버를 거쳐서 최종적으로 국세청으로 전송이 되게 됩니다.
내부적으로 결제 프로세스가 변경되거나 UI가 변경될 시 개발 혹은 Test 서버에 Test를 할 시 계속 국세청으로 필요 없는 계산서 정보가 전송되게 된다면 큰일이겠죠?
그에 반해 개발 서버 및 Test 서버는 자유롭게 시스템을 조작하고 운용 가능함으로 사고를 줄일 수 있는 게
큰 차이점입니다.