개발/테스트/운영 환경 구분

Chapter 6. 회사 시스템 파악

"개발? 테스트? 운영?이 뭐지? "

팀장님이 슬랙으로 새로운 메시지를 보낸다.

"개발 환경, 테스트 환경, 운영 환경 각각의 URL과 접근 방법을 정리해두세요. 다음주부터 실제 배포도 해볼 거예요."

메시지를 읽고 잠시 멈춘다.

'개발 환경... 테스트 환경... 운영 환경? 이게 다 다른 건가? 아까 서버 계정 받을 때도 비슷한 얘기가 나왔던 것 같은데...'

슬랙 채널을 보면서 동료들의 대화를 듣는다.

"스테이징에 배포 완료했어요."

"운영 환경 로그 보면 에러가 안 보이는데..."

"개발계에서는 되는데 스테이징에서는 안 되는 거 봐요."

'스테이징? 개발계? 운영 환경?... 같은 서비스인데 환경이 여러 개인 거구나. 근데 왜?'

괜찮다. 걱정하지 마라. 회사의 여러 환경이 왜 존재하는지, 각 환경에 어떻게 접근하는지, 그리고 테스트 데이터까지 어떻게 관리되는지 여기서 차근차근 정리해보자.

환경이 왜 여러 개인가?

처음 회사에 들어오면 가장 혼란스러운 부분 중 하나가 바로 이거다. 서비스는 하나인데 환경이 여러 개다.

왜 그렇냐고? 간단히 말하면, 운영 환경에서 실험하면 안 되기 때문이다.

생각해보자. 운영 환경은 진짜 사용자들이 쓰는 곳이다. 실제 회원, 실제 주문, 실제 결제가 일어나는 곳이다. 여기서 실수로 잘못된 코드를 배포하면? 사용자들이 실제로 피해를 본다. 회사의 신뢰가 떨어진다. 심한 경우에는 법적 문제로도 갈 수 있다.

그래서 회사는 운영 환경과 동일한 구조의 환경을 따로 만든다. 여기서 먼저 테스트해본다. 문제가 없으면 그때 운영 환경에 배포한다.

이게 바로 개발 환경, 테스트 환경, 운영 환경이 나뉘는 이유다.

각 환경의 역할을 파악하기

회사에는 보통 최소 세 가지 환경이 있다. 각각의 역할을 한 번 정리해두면 앞으로 혼란이 훨씬 줄어든다.

로컬 환경 (Local)

내 노트북에서 직접 실행하는 환경이다. 앞서 "개발 환경 구축"에서 설정한 바로 그것이다. 아무리 실험해도 다른 사람에게 영향을 주지 않는다. 내가 코드를 잘못 돌려도, 서버를 여러 번 꺼켜도, 아무도 신경 안 쓴다. 왜냐하면 완전히 내 컴퓨터에만 존재하기 때문이다.

로컬 환경의 장점은 빠르다는 것이다. 코드를 수정하고 바로 결과를 볼 수 있다. 단점은 내 컴퓨터의 환경과 실제 회사 서버의 환경이 약간 다를 수 있다는 것이다. "내 컴퓨터에서는 되는데..."라는 말이 바로 여기서 나온다.

개발 환경 (Development / Dev)

여러 개발자들이 공동으로 사용하는 서버 환경이다. 로컬에서 완성한 코드를 여기에 배포해서 "다른 사람도 볼 수 있는 상태"로 만든다.

개발 환경은 자주 변한다. 오늘 오후에 배포한 코드가, 내일 아침에 다시 바뀌는 건 흔한 일이다. 그래서 개발 환경의 데이터도 불안정할 수 있다. 어제까지 있었던 테스트 회원이 오늘은 없는 경우도 있다.

"개발계가 불안정하다"는 말을 자주 듣는다. 그건 정상이다. 개발 환경은 실험 장소니까.

테스트 환경 (Staging / QA)

이 환경이 제일 중요한데, 제일 모르는 경우가 많다.

테스트 환경은 운영 환경과 거의 동일하게 구성된 환경이다. 같은 서버 스펙, 같은 설정, 같은 구조. 유일한 차이는 "실제 사용자가 없다"는 것이다.

왜 이런 환경이 필요냐고? 개발 환경에서 테스트한 코드가 반드시 운영에서도 잘 작동하는 것은 아니다. 환경이 다를 수 있기 때문이다. 테스트 환경은 운영과 거의 동일하므로, 여기서 제대로 작동한다면 운영에서도 작동할 확률이 높다.

QA 팀이 주로 이 환경에서 테스트한다. 개발자가 "스테이징에 배포했어요"라고 말하면, QA 팀이 여기서 기능을 꼼꼼히 확인하는 거다.

운영 환경 (Production / Prod)

진짜 사용자들이 사용하는 환경이다. 절대로 함부로 건드리면 안 된다.

신입 개발자로서 운영 환경에 직접 접근할 수 있는 권한을 받는 경우는 드물다. 대부분의 회사에서는 신입에게 개발 환경까지만 접근 권한을 준다. 운영 환경은 시니어나 팀장 이상에서만 접근 가능한 경우가 많다.

이건 보안상 당연한 조치이다. 신입이 실수로 운영 환경에서 잘못된 쿼리를 실행하면... 그 피해는 단순한 "실수"로 끝나지 않는다.

운영 환경에 실수로 접속했던 날

신입때 였다. 버그를 수정하고 테스트하려는데, DBeaver에 DB 연결이 여러 개 저장되어 있었다. dev, staging, prod. 나는 dev를 클릭한다고 생각했는데, 아래로 한 칸 더 내려간 거였다.

쿼리를 실행했다. SELECT 문이었다. 결과가 나왔는데, 숫자가 엄청났다. 개발 환경에서는 회원이 보통 수십 명이었는데, 여기는 수백만 명이었다.

'우와 개발 환경에도 회원이 많구나!?'

그런데 쎄한 기분에 위로 올려보니 연결 이름이 "production"이었다.

심장이 쿵 내려앉았다.

다행히 SELECT 문이었다. 데이터를 읽기만 한 것이었으니 아무 피해 없었다. 하지만 그 순간의 기분은 지금도 생생하다. 마우스를 잘못 클릭한 것 하나로, 내가 운영 환경에 접속했다는 사실.

그날 이후로 나는 쿼리를 실행하기 전에 반드시 세 가지를 확인한다. 연결 이름이 무엇인지, 스키마 이름이 무엇인지, 그리고 어떤 환경인지. 세 번 확인한 후에야 엔터를 누른다.

각 환경의 URL과 접근 방법

각 환경의 URL은 회사마다 다르지만, 패턴은 비슷하다.

URL 패턴 확인하기

회사에서 환경별 URL을 관리하는 곳은 보통 정해져 있다. 사내 위키에 "환경 정보" 또는 "서버 정보"로 검색해보면 나온다. 없다면 팀장이나 선배에게 "각 환경의 URL은 어디에 정리되어 있나요?"라고 물어보면 된다.

일반적으로 회사의 URL은 이런 패턴을 따른다:

개발 환경: dev.company.com 또는 development.company.com

테스트 환경 (스테이징): staging.company.com

운영 환경: www.company.com 또는 company.com

하지만 이건 예시일 뿐이다. 회사마다 다르다. "dev-internal.company.com"이거나 "qa.company.com"인 경우도 있다. 반드시 회사 문서를 확인하자.

접근 방법은?

각 환경에 접근하는 방법도 환경마다 다를 수 있다.

개발 환경과 테스트 환경은 보통 회사 내부 네트워크에서만 접근 가능하다. 외부에서 접근하려면 VPN을 켜야 한다. "접근 안 되는데?"라면 제일 먼저 VPN 연결을 확인하자.

운영 환경은 공개 URL이므로 VPN 없이도 접근할 수 있다. 하지만 개발자 권한 페이지(예: 관리자 패널, 내부 API)에는 여전히 VPN이 필요할 수 있다.

실전 팁

각 환경의 URL과 접근 방법을 한 곳에 정리해두자. 메모장이든, 노트북 PDF든, 찾기 쉬운 곳에. "접근 안 되는데요?"라는 질문은 가장 시간을 낭비하는 질문 중 하나이다.

환경별 DB가 분리되어 있는지 확인

이건 반드시 확인해야 할 중요한 것이다.

환경별 DB 분리란, 각 환경이 각각 다른 데이터베이스를 사용하는다는 뜻이다.

대부분의 회사는 환경별 DB를 분리한다. 즉, 개발 환경의 DB와 운영 환경의 DB는 완전히 다른 서버, 다른 테이블, 다른 데이터이다.

왜 중요냐고? 만약 분리되어 있지 않다면, 개발자가 실험하는 중에 운영 데이터가 지우어질 수 있다. 이건 단순한 가정이 아니다. 실제로 이런 사고가 일어난 적이 있다.

DB 연결 정보 파악하기

각 환경의 DB 연결 정보는 사내 위키에 정리되어 있거나, 팀장이나 인프라팀에서 별도로 전달받는 경우도 있다. "환경별 DB 정보"를 검색해보거나, 앞서 받은 "DB 조회 권한 신청" 과정에서 받은 정보를 다시 확인해보자.

연결 정보를 받으면 반드시 이것만 확인하자: 연결 이름에 환경 이름이 표시되는지. DBeaver나 DataGrip에서 연결 목록을 볼 때, "dev-database", "staging-database", "production" 같은 이름이 명확하게 보여야 한다. 이름이 구분되지 않는다면 선배에게 "연결 이름에 환경명을 표시할 수 있을까요?"라고 요청하자.

실전 팁

DB 클라이언트에서 연결 색깔을 구분하면 더 안전하다. DBeaver나 DataGrip은 연결마다 색깔을 지정할 수 있다. 예를 들어 개발 환경은 파란색, 테스트 환경은 노랑색, 운영 환경은 빨간색으로 설정하면, 어떤 환경에 연결되어 있는지 한눈에 보인다.

테스트 데이터 생성 방법

각 환경에 있는 데이터도 다르다. 운영 환경에는 진짜 회원, 진짜 주문이 있지만, 개발 환경에는 테스트용 데이터가 있다. 이 테스트 데이터를 어떻게 만드는지 파악해야 한다.

테스트 데이터가 왜 필요한가?

새 기능을 만들었을 때, "이 기능이 제대로 작동하는지" 확인해야 한다. 그런데 아무 데이터가 없으면 테스트할 수가 없다. 예를 들어 "주문 목록 페이지"를 만들었는데, 주문 데이터가 하나도 없으면 테스트를 할 수가 없는 것이다.

그래서 개발 환경에는 테스트용 데이터를 미리 만들어두는 것이다.

회사마다 테스트 데이터 관리 방법이 다르다

방법 1: 세딩 스크립트 (Seeding Script) 가장 흔한 방법이다. 프로젝트 안에 테스트 데이터를 자동으로 생성하는 스크립트가 있다. 개발자가 명령어를 실행하면, 회원 50명, 주문 100건, 상품 200건 같은 테스트 데이터가 자동으로 생긴다.

방법 2: 사전 준비된 테스트 계정 팀에서 미리 만든 테스트 계정이 있다.

"dev@test.com", " admin@test.com"

같은 계정으로 로그인하면 테스트할 수 있다. 이 계정의 비밀번호는 사내 위키에서 찾거나, 선배에게 받아야 한다.

방법 3: 직접 생성 자신이 직접 테스트 데이터를 만드는 경우도 있다. DB에 INSERT 문을 실행하거나, 서비스에서 직접 회원가입하여 테스트 회원을 만드는 것이다.

테스트 데이터 생성할 때 주의할 것

개발 환경에서 테스트 데이터를 만들때는 반드시 개발 환경 DB에만 작업하자. 운영 환경에 테스트 회원을 만드면, 그 회원이 실제로 회사 서비스에 등장한다. 이건 서비스 품질 문제가 된다.

그리고 테스트 계정의 이메일에 진짜 개인 이메일을 쓰지 말자. "test@gmail.com"이거나, 회사에서 제공한 테스트 이메일을 사용하자.

실전 팁

테스트 데이터 생성 하는 방법은 많지만 반드시 팀에게 먼저 물어보자. "테스트 데이터를 새로 만들어야 하는데 어떤 방법을 쓰나요?"라고 하면 된다. 팀에서 사용하는 방법이 있을 거다. 그냥 직접 DB에 INSERT 문을 실행하는 경우도 있지만, 세딩 스크립트를 쓰는 경우도 있고, 특별한 도구를 사용하는 경우도 있다. 팀 규칙을 따라야 한다.

운영 환경에 테스트 회원을 만들었던 실수

3년 차였던가? 회원가입 기능을 테스트하려는데, 개발 환경에서 회원가입 페이지에 접속하는데 500 에러가 계속 나왔다. 30분을 씨름하다가, 이렇게 생각했다.

'운영 환경에서는 돼야 하는데...'

운영 환경 URL로 바꿔서 테스트 회원을 가입시켰다. "test_user_1234@test.com". 가입 자체는 성공했다. '아, 여기서는 되네. 그럼 개발 환경에서 뭐가 잘못된 거지?'

그때 팀장님이 슬랙으로 메세지를 보냈다.

"혹시 운영 환경에서 테스트 회원 생성하셨나요?"

"아... 테스트 회원만 만들었어요. 아무 영향 없을 것 같아서..."

팀장님은 단호하게 답장을 보냈다.

"운영 환경에 테스트 회원이 생겼잖아요. 이제 그 회원 삭제 요청을 DBA팀에 보내야 해요. 운영 DB는 개발자가 직접 삭제할 수 없으니까요." 부끄러웠다. DBA팀에 "실수로 운영 환경에 테스트 회원을 생성했습니다. 삭제 요청드립니다"라는 메일을 보내는 건 정말 기분 좋지 않은 일이었다.

그날 이후로 나는 URL을 바꾸기 전에 반드시 확인한다. "지금 내가 접속한 곳이 어떤 환경인지." 그리고 가능하면 URL 막대의 환경명을 한눈에 확인할 수 있도록 브라우저 탭 이름도 주의 깊게 본다.

체크리스트: 개발 환경을 파악해보자.

다음 주 안에 아래 항목들을 하나씩 체크해보자.

환경 정보 파악

개발 환경 URL을 확인했는가

테스트 환경 (스테이징) URL을 확인했는가?

운영 환경 URL을 확인했는가?

각 환경의 접근 방법 (VPN 여부)을 파악했는가?

DB 파악

각 환경의 DB가 분리되어 있는지 확인했는가?

DB 클라이언트에서 환경별 연결 이름이 구분되어 있는가?

테스트 데이터 생성 방법을 팀에게 물어봤는가?

실제 접속 확인

개발 환경에 직접 접속해서 서비스를 사용해본 적이 있는가?

테스트 환경에 접속해본 적이 있는가?

운영 환경 URL에 접속하여 실제 서비스를 한 번 봐본 적이 있는가?

환경을 구분하면, 일하는 방식이 달라진다

첫 주에 "개발 환경", "테스트 환경", "운영 환경"이라는 단어를 듣었을 때는 그냥 이름일 것 같다고 생각했다.

그런데 실제로 일하면서는 이 구분이 매일 다음과 같은 질문의 답이 된다.

"지금 이 버그가 개발 환경에서만 나오는 건가, 아니면 운영에서도 나오는건가?"

"테스트 환경에서 확인한 거 자신감이 있나?"

"운영 환경에 배포할 준비가 돼 있나?"

이 세 질문에 답할 수 있게 되면, 당신은 이미 회사 시스템을 이해한 사람이다.

환경을 구분하는 건 단순히 URL 세 개를 외우는 일이 아니다. 코드가 어떤 여정을 거쳐 사용자에게 도달하는지를 이해하는 것이다. 로컬에서 만든 코드가, 개발 환경으로 가고, 테스트 환경에서 검증을 받고, 드디어 운영 환경에 배포되는 그 여정.

그 여정을 한 번 눈에서 따라가면, 앞으로 일하는 방식 전체가 달라진다.