개발 서버와 운영 서버 가이드

DUOLABS 가 만들고 운영하는 업무 시스템은 같은 프로그램을 여러 곳에 나눠 띄워 둡니다. 직원분들이 매일 쓰는 화면(운영 서버)은 그대로 두고, 새 기능은 다른 곳(개발 서버)에서 먼저 만들고 확인한 뒤에 옮깁니다. 이 문서는 그 구조가 어떻게 생겼는지, 왜 그렇게 하는지, 고객사가 알아 두실 것이 무엇인지 설명합니다.

데이터를 어떻게 나눠 두고 문제가 생기면 어떻게 되살리는지 더 자세한 기준은 「데이터 보호와 복구 가이드」에 있습니다.

한 줄 요약

새 기능은 「만드는 곳 → 확인하는 곳 → 실제로 쓰는 곳」 순서로 옮겨 가고, 실제로 쓰는 곳은 합의한 때에만 바뀝니다. 곳마다 데이터도 따로 둬서, 만들고 시험하는 동안 실제 업무 데이터는 건드리지 않습니다.

세 곳

	① 개발자 PC	② 개발 서버	③ 운영 서버
하는 일	기능을 만든다	실제와 같은 환경에서 확인한다	직원분들이 매일 쓴다
누가 보나	개발자	개발자, 필요하면 고객사 담당자	고객사 직원
데이터	시험용	시험용(가상 자료)	실제 업무 데이터
언제 바뀌나	수시로	기능을 올릴 때마다	고객사와 합의한 반영 때만

• ① 과 ② 에서는 몇 번이고 고치고 지우고 다시 만듭니다. 그래도 ③ 은 영향을 받지 않습니다.
• ② 의 주소는 시험용입니다. 실제 주문·거래처를 입력하지 마세요 — 그곳 데이터는 시험 중에 언제든 지워질 수 있습니다.

새 기능이 반영되는 순서

1. 요청과 범위 확인 — 무엇을 바꿀지, 계약 범위 안인지 정합니다.
2. 개발 — 개발자 PC 에서 만듭니다.
3. 개발 서버에 올려 확인 — 실제와 같은 환경에서 화면·속도·권한을 봅니다. 필요하면 고객사 담당자께 주소를 드려 미리 써 보시게 합니다.
4. 반영 일정 합의 — 업무가 몰리는 시간을 피해 언제 반영할지 정합니다. 데이터 구조가 바뀌는 반영이면 그 전에 백업을 뜨고, 되살릴 수 있는지까지 확인합니다.
5. 운영 서버에 반영 — 반영은 보통 몇 분 안에 끝납니다. 반영 뒤 주요 화면을 다시 확인합니다.
6. 안내 — 바뀐 화면은 시스템 안의 매뉴얼 「바뀐 것」에 적습니다.

문제가 생기면 반영 전 상태로 되돌립니다. 프로그램은 바로 앞 버전으로 되돌릴 수 있고, 데이터는 반영 직전에 뜬 백업이 있습니다.

새 기능을 확인받는 방법

바쁘신 업무 중에 시험까지 맡으시지 않도록, 시험은 저희가 끝내고 고객사께는 확인만 부탁드립니다.

1. 시험은 저희가 합니다 — 개발 서버에서 화면, 직원 역할별 권한, 휴대폰 화면까지 확인한 뒤에 연락드립니다.
2. 짧은 확인 자리를 정합니다 — 「화요일 오후 20분, 관리부 담당자분과 화면 공유로」처럼 사람과 시간을 정해, 반영할 내용을 한 번에 보여 드립니다.
3. 확인표를 드립니다 — 확인하실 것을 3~5줄로 정리해 드리고, 「예 / 아니오」로 답하시면 됩니다.
4. 현장 기능은 현장에서 — 휴대폰으로 쓰는 기능은 방문했을 때 쓰시는 분의 휴대폰으로 직접 눌러 보시게 합니다.
5. 확인 결과는 글로 남깁니다 — 메일이나 메시지로 「확인했습니다」를 받아 반영 기록에 붙입니다.

여기까지가 기본 형태입니다. 확인을 더 실제에 가깝게 하고 싶으시면 아래를 골라 더할 수 있습니다(고도화, 범위와 비용은 따로 정합니다).

• 귀사의 자료로 확인 — 개발 서버를 운영 자료의 가린 사본(연락처·금액을 가린 것)으로 채워, 귀사 거래처·제품이 보이는 화면으로 확인하십니다.
• 운영에서 먼저 몇 분께 열기 — 화면만 바뀌는 기능을 운영 서버에서 담당자 몇 분께만 먼저 열어 며칠 실제로 써 보시게 한 뒤 모두에게 엽니다. 데이터 구조가 바뀌는 반영은 모두에게 한꺼번에 적용되므로 이 방법 대신 사전 리허설로 확인합니다.
• 스테이징 — 반영 전 승인을 귀사가 직접 하셔야 할 때 둡니다(아래 「3단계와 4단계」).

개발 서버에 들어오실 때는 화면 맨 위의 「시험 서버」 표시를 확인해 주세요. 그곳에 입력한 자료는 실제 업무에 반영되지 않고, 언제든 지워질 수 있습니다.

데이터를 왜 따로 두나

개발 서버와 운영 서버가 데이터를 같이 쓰면 편해 보이지만, 운영을 지키려는 목적과 부딪힙니다.

• 데이터 구조가 먼저 바뀐다 — 개발 중인 기능이 데이터 구조(칸)를 바꾸면, 아직 옛 프로그램으로 도는 운영 화면이 그 순간 깨질 수 있습니다.
• 시험이 실제 기록이 된다 — 개발 서버에서 눌러 본 시험 주문·삭제가 그대로 실제 업무 데이터와 기록에 남습니다.
• 되돌리기가 어렵다 — 시험 중의 실수를 되돌리려면 운영 데이터를 통째로 되살려야 하고, 그사이의 실제 입력도 함께 사라집니다.

그래서 개발 서버에는 가상 자료를 씁니다(기본 형태). 실제와 비슷한 자료로 확인하는 고도화를 고르시면 운영 백업을 복사하되 연락처는 가리고 금액은 숨긴 뒤에 씁니다.

3단계와 4단계

위의 세 곳(개발자 PC → 개발 서버 → 운영 서버)이 기본입니다. 여기에 스테이징을 하나 더 두는 4단계 구성도 있습니다.

	3단계 (기본)	4단계 (+ 스테이징, 고도화)
구성	개발자 PC → 개발 서버 → 운영	개발자 PC → 개발 서버 → 스테이징 → 운영
맞는 경우	개발자 1~2명, 반영 시점을 한 사람이 정함	고객사가 반영 전에 직접 확인·승인(시험 사용), 여러 기능이 동시에 다른 속도로 나감
장점	관리할 곳이 적고 빠르다	「만드는 중」과 「나갈 후보」가 섞이지 않는다
단점	고객사가 확인하는 동안 개발 서버를 함부로 바꾸기 어렵다	관리할 곳·비용이 하나만큼 는다

• 스테이징은 운영에 나갈 묶음을 운영과 같은 조건에서 마지막으로 확인하는 곳입니다.
• 정답이 정해져 있지 않습니다. 시작은 3단계로 하고, 고객사가 반영 전 승인을 해야 하는 일이 생기면 4단계로 늘립니다. 3단계에서도 데이터 구조를 바꾸는 반영은 직전 백업을 뜨고 되살아나는지 확인한 뒤에만 나갑니다.

운영 데이터를 지키는 장치

• 백업은 「되살아나는지」까지 확인합니다 — 파일을 떠 두는 것으로 끝내지 않고, 빈 데이터베이스에 실제로 되살려 표와 건수가 맞는지 봅니다.
• 데이터 구조를 바꾸는 반영은 백업 확인 없이는 나가지 않습니다 — 반영 절차가 그 단계에서 멈추게 되어 있습니다.
• 지우지 않고 끕니다 — 업무 기록은 실제로 지우는 대신 「취소」·「숨김」·「비활성」으로 둡니다. 실수로 지운 기록이 되살릴 수 없게 사라지지 않게.
• 누가 무엇을 바꿨는지 남습니다 — 시스템 안의 감사 기록에 사람·시각·바뀐 값이 남고, 화면에서 지울 수 없습니다.
• 접근은 필요한 만큼만 — 운영 데이터베이스에 직접 손대는 일은 최소로 하고, 할 때는 백업 → 범위 확인 → 기록 순서를 지킵니다.

고객사께 부탁드리는 것

• 반영 일정 — 반영 시간을 정할 때 업무가 몰리는 시간을 알려 주세요.
• 확인 자리 한 번 — 반영 전에 20분 남짓 확인 자리를 내어 주세요. 확인표에 「예 / 아니오」로 답해 주시면 됩니다.
• 개발 서버 주소는 시험용 — 미리 써 보실 때 실제 주문·거래처는 입력하지 마세요.
• 이상하면 바로 알려 주세요 — 숫자가 맞지 않거나 화면이 이상하면, 손으로 「맞춰 두지」 말고 화면을 찍어 보내 주세요. 기록이 꼬이지 않게 원인부터 찾습니다.
• 계정은 사람마다 하나 — 비밀번호를 함께 쓰면 누가 무엇을 했는지 기록이 의미를 잃습니다.

자주 묻는 질문

개발 서버에 올렸는데 왜 아직 우리 화면에는 안 보이나요?
개발 서버는 확인하는 곳입니다. 운영 서버에는 합의한 반영 때 옮깁니다.

개발 서버에서 입력한 것이 운영으로 넘어오나요?
아니요. 두 곳은 데이터를 따로 씁니다. 개발 서버의 자료는 시험용이라 언제든 지워질 수 있습니다.

반영하다 문제가 생기면요?
프로그램은 바로 앞 버전으로 되돌리고, 데이터는 반영 직전 백업으로 되살립니다. 데이터 구조를 바꾸는 반영은 이 백업이 있어야만 진행됩니다.

스테이징이 없으면 위험하지 않나요?
규모가 작을 때는 개발 서버가 그 역할을 겸하고, 데이터 구조를 바꾸는 반영은 백업 확인 없이는 나가지 않습니다. 반영 전 고객사 승인이 필요해지면 스테이징을 따로 둡니다.

기본 형태와 고도화 형태는 어떻게 고르나요?
기본 형태로 시작해 필요해질 때 더하시기를 권합니다. 어떤 장치가 어느 쪽인지는 「데이터 보호와 복구 가이드」 맨 앞 표에 있습니다.