1. 개요
실무자라면, 서비스나 제품을 개발하는 과정에서 여러 이슈가 발생했던 경험이 있을 것입니다. 여러 이슈들 중에 특히 커뮤니케이션 이슈는 개발 진행에 상당히 많은 영향을 줍니다. 개발, 테스트, 배포, 운영 과정에서 서비스가 어떠한 환경에서 개발됐고, 배포됐는지 확인은 필수일 것입니다. 그러나 이 과정에서 빈번하게 개발 및 배포 환경을 재확인을 하거나 커뮤니케이션 이슈가 발생하게 되면 불필요한 Overhead가 누적되어 서비스 개발 과정에서 피로도가 쌓이게 됩니다. 따라서 개발 과정에서 어떠한 환경에서 배포되어 테스트 할 것인가에 대해 명확한 정의가 필요합니다. 이번 포스트에서는 이러한 환경 중, 개발 환경에 대한 내용을 작성하여 공유하고자 합니다.
2. 개발환경 구분
서버 개발을 가정하게 되면 개발 환경은 Local, Development, Integration, QA, Stage, Production 으로 구분할 수 있습니다. 각각의 내용은 아래와 같습니다.
Local (로컬)
•
개발자의 개인 PC(or Laptop) 환경에서 구동하는 서비스
•
개발자 개인 환경이기 때문에 다른 환경과 상이할 수는 있음
Development (개발계)
•
개발이 완료되고 개발 내용을 테스트 하기 위한 환경에서 구동하는 서비스
•
때에 따라 Integration 환경처럼 쓰이기도 함
•
일반적으로 개발이 완료되고 소스코드를 개발계 브랜치(ex> development)에 병합(merge)될 경우 자동으로 배포되는 구조
Integration (통합 개발계)
컴포넌트(component)란 여러 개의 프로그램 함수들을 모아 하나의 특정한 기능을 수행할 수 있도록 구성한 작은 기능적 단위를 말한다. 컴포넌트를 이용하면 소프트웨어 개발을 마치 레고(Lego) 블록을 쌓듯이 조립식으로 쉽게 할 수 있다.
•
통합 개발 환경으로써, 여러 개의 컴포넌트를 동시 개발하는 프로젝트에서 여러 컴포넌트에 종속성(dependency)이 있을 수 있음
•
이때 컴포넌트를 통합 테스트 하는 환경을 의미함
QA(Quality Assurance)
•
QA 엔지니어에 의해 사용되는 환경으로, Short Release 주기에 따라 개발환경에서 QA 환경으로 배포됨
Stage (검증계)
•
개발 테스트가 완료되고, 운영 환경과 비슷하게 구성된 환경에서 테스트를 하기 위한 서비스
•
주로 보안, 성능, 장애 등의 크리티컬한 이슈가 있는지 여부를 검토하는 테스트 서버로써의 역할을 함
Production (운영계)
•
실제 운영 환경
3. 작은 단위의 개발 환경
크기가 작은 프로젝트의 경우 위와 같이 구분돼 있는 레이어를 모두 따라갈 필요는 없습니다. 특히 컴포넌트별로 구분되어 개발될 정도로 Repository가 별도로 분리돼 있지 않기 때문에 Integration 영역은 불필요합니다. 운영 환경에 맞추어 테스트할 Stage 영역 또한 현재 없는 경우다 많습니다. 따라서 단위가 크지 않은 서비스의 경우 경우 다음과 같이 레이어를 간소화하며, 아래와 같이 구분지어 커뮤니케이션이 이루어지도록 하는 것이 좋다고 생각합니다.
4. 환경 구성 예시
환경 구성의 경우 백엔드에서는 .env 파일 혹은 secret.json 파일을 이용하여 구분합니다. 더불어 Gunicorn 과 같이 로컬, 개발서버, 운영서버의 각 설정파일(python 파일) 역시 파일로 구분하여 각각 [환경].conf.py 와 같이 나누어 사용하기도 합니다. 이에 대한 네이밍 컨벤션을 정의하고자합니다.
Local 환경
로컬환경에서 쓸 파일은 및 설정의 경우 local 이라는 단어로 통일하도록 합니다.
•
local_secret.json
•
local.conf.py
•
settings/local.py
이외의 로컬 환경의 Docker Image, Container 등은 자유롭게 작성하여도 무방합니다.
Development 환경
개발계(Development, 이하 개발) 환경의 경우 development라는 단어로 통일하도록 합니다.
•
development_secret.json
•
development.conf.py
•
settings/development.py
이외의 개발 환경 AWS EC2 이미지 혹은 ECS 컨테이너의 경우 development라는 단어를 내포하여 구분하도록 합니다. 예를 들어 ECS 클러스터 이름의 경우 ecs-project-cluster-developement과 같이 구분할 수 있고, Security Group 또한 development를 내재하여 관리할 수 있도록 합니다.
Production 환경
운영계(Development, 이하 운영) 환경의 경우 development라는 단어로 통일하도록 합니다.
•
production_secret.json
•
production.conf.py
•
settings/production.py
이외의 운영 환경 AWS EC2 이미지 혹은 ECS 컨테이너의 경우 development라는 단어를 내포하여 구분하도록 합니다. 예를 들어 ECS 클러스터 이름의 경우 ecs-project-cluster-production과 같이 구분할 수 있고, Security Group 또한 production을 내재하여 관리할 수 있도록 합니다.
5. 마무리
이번 포스트에서는 개발 환경의 구분과 각 영역의 역할을 나열해보고, 작은 단위의 프로젝트의 경우 어떻게 개발 환경을 구성하면 좋을지 의견을 작성해보았습니다. 이번 글을 작성하면서 개발 환경에 대해 더 자세히 알게 됐으며, 큰 서비스(혹은 제품)의 경우 컴포넌트 단위로 나뉘어 하나의 큰 프로젝트를 구성하게 된다는 것도 알게 되었습니다.