EHS 클라우드 전환 로드맵, 단계마다 무엇을 확인할까
“서버를 클라우드로 옮기는 일정은 잡았는데, 현장 업무까지 언제 정상화되는지 모르겠습니다.”
“결재와 ERP가 연결돼 있는데, 무엇부터 옮겨야 업무가 끊기지 않을까요?”
EHS 클라우드 전환은 현황 진단, 목표 설계, 시범 운영, 본 전환, 안정화 순서로 진행하되, 각 단계의 완료 조건을 먼저 정해야 합니다. 다음 단계로 넘어가는 기준은 서버 이전 여부가 아니라 현장 업무와 기록이 이어지는지입니다.
저는 크로플에서 EHS 사업 파트장과 개발 팀장을 맡아 제조 현장의 업무 설계, 기존 시스템 연동, 클라우드 아키텍처 검토를 함께 다루고 있습니다. 이 글에서는 보안 설정 항목을 나열하기보다 현장 담당자, IT 담당자, 경영진이 같은 기준으로 전환 진행 상황을 판단하는 방법에 집중하겠습니다.
1. 현황 진단에서는 무엇까지 파악해야 하나요?
서버와 프로그램 목록에 더해, 누가 어떤 기록을 만들고 어느 시스템을 거쳐 업무를 끝내는지까지 확인해야 합니다. 진단의 완료 조건은 이전 대상과 의존 관계를 담당자들이 함께 확인한 상태입니다.
애플리케이션의 연동 관계와 데이터 의존성을 파악한 뒤 이전 단위를 정하는 것은 클라우드 전환 순서를 설계하는 기본 절차입니다. 이를 생략하면 함께 이동해야 할 기능을 분리하거나, 남겨 둔 시스템의 연결을 놓칠 수 있습니다.
EHS에서는 화면 이름보다 실제 업무 한 건을 따라가 보는 편이 명확합니다. 작업허가 신청을 예로 들면 신청자 계정, 협력사 정보, 결재자 조직, 첨부파일, 알림 발송까지 확인합니다. 어느 하나가 빠져도 화면은 열리지만 업무는 끝나지 않을 수 있습니다.
진단표에는 다음 항목을 남깁니다.
- 업무 책임자와 실제 사용자
- 입력 데이터, 첨부파일, 출력 양식의 보관 위치
- 그룹웨어, ERP, 출입 시스템 등 연결 대상과 관리 주체
- 사용이 집중되는 시간과 업무 중단을 허용할 수 있는 범위
- 유지할 기능, 정리할 기능, 추가 확인이 필요한 기능
오래된 기능도 사용 빈도만 보고 제외하지 않습니다. 연간 특정 시기에만 사용하는 업무인지 현장 담당자에게 확인해야 합니다. 반대로 아무도 쓰지 않는 기능을 그대로 옮기면 이후 운영 범위까지 불필요하게 커집니다.
이 단계에서는 모든 문제를 해결할 필요가 없습니다. 다만 모르는 항목을 빈칸으로 남겨 두지 말고, 확인 책임자와 결정 시점을 지정해야 합니다.
2. 목표 설계는 인프라 구성도로 끝내도 될까요?
목표 설계에는 클라우드 구성뿐 아니라 업무별 데이터 기준, 연동 책임, 장애 시 대응 주체까지 들어가야 합니다. 각 연결을 누가 개발하고 검증하며 운영할지 합의돼야 다음 단계로 넘어갈 수 있습니다.
예를 들어 조직 정보가 바뀌었을 때 EHS의 결재선도 함께 바뀌어야 하는지, 이미 진행 중인 문서는 기존 결재선을 유지해야 하는지 결정해야 합니다. 서버 구성도만으로는 이런 업무 조건이 드러나지 않습니다.
TCC STEEL 포항과 서울 사업장의 통합 EHS 구축에서 저는 메인 개발을 맡았습니다. 그룹웨어 결재와 조직, ERP, 출입과 방문 시스템, 문자와 메일 알림 등의 연동 구조는 고객사 IT 계열사와 함께 설계했습니다. EHS 화면 내부의 기능만으로 업무가 완성되지 않기 때문에 시스템 경계를 함께 맞추는 과정이 필요했습니다.
이 사례는 통합 EHS 구축 경험이며, 그 자체를 클라우드 이전 사례로 설명하는 것은 아닙니다. 다만 여러 시스템 사이의 책임을 먼저 나눠야 한다는 판단은 클라우드 전환 설계에도 적용할 수 있습니다.
설계 회의에서는 연결마다 다음 질문에 답을 남겨 보세요.
“어느 시스템의 값이 기준인가?”, “전송에 실패하면 어디에서 확인하는가?”, “재처리는 누가 하는가?”
이 답을 EHS 담당자, 사내 IT 담당자, 구축 담당자가 서로 다르게 이해한다면 설계는 아직 끝난 것이 아닙니다. 클라우드와 사내 서버 중 어떤 방식을 선택하더라도 같은 확인이 필요합니다.
3. 시범 운영은 어떤 업무부터 시작해야 하나요?
시범 운영은 화면 하나가 아니라 입력부터 승인, 기록 확인까지 끝낼 수 있는 업무 단위로 구성하는 편이 좋습니다. 연동과 예외 처리를 확인할 수 있으면서도 문제가 생겼을 때 대응 가능한 범위로 한정합니다.
가장 단순한 화면만 골라 시험하면 실제 사용 단계의 문제가 드러나지 않습니다. 반대로 사업장 전체 업무를 한꺼번에 시범 운영하면 문제가 발생한 지점을 구분하기 어렵습니다.
안전점검 업무를 대상으로 한다면 점검표 작성, 사진 첨부, 개선 요청, 조치 결과 등록, 담당자 확인까지 한 흐름으로 확인합니다. 정상 입력뿐 아니라 담당자 변경, 반려, 잘못된 첨부파일 교체처럼 실제로 발생할 수 있는 상황도 시험 항목에 넣습니다.
통합 EHS 구축 당시에는 종이 점검표를 템플릿으로 전환하고, 담당자가 화면에서 직접 수정할 수 있도록 구현했습니다. 기능을 짧은 주기로 개발해 안전환경팀과 반복 확인하면서 현장 양식과 시스템 사용 흐름을 맞췄습니다. 처음 정한 화면을 그대로 완성하는 것보다 담당자가 실제 기록을 만들어 보는 과정이 중요했습니다.
클라우드 전환에서도 기존 기능이 새 환경에서 열린다는 확인과 사용자가 업무를 끝낼 수 있다는 확인을 구분해야 합니다. 시범 운영의 결과물은 단순한 오류 목록이 아닙니다. 해결한 문제, 남은 문제, 본 전환 전에 반드시 수정할 문제를 나눈 판단 기록이어야 합니다.
4. 본 전환 직전에는 무엇을 검증해야 하나요?
데이터가 제대로 옮겨졌는지, 연결된 업무가 동작하는지, 실패하면 어떻게 복귀할지를 함께 검증해야 합니다. 본 전환의 승인 조건에는 중단 여부를 판단할 담당자와 시점도 포함합니다.
데이터 이관 검증과 전환 리허설을 수행하고, 전환 실패 시 되돌릴 조건과 절차를 사전에 정하는 것은 이전 위험을 관리하는 실무 방법입니다. 다만 전환 뒤 새로 입력된 데이터가 있으면 단순 복귀가 어려울 수 있어 별도 처리 방안이 필요합니다.
EHS 데이터는 행 수만 맞는다고 검증이 끝나지 않습니다. 점검 결과와 첨부파일이 연결되는지, 진행 중인 결재 상태가 유지되는지, 과거 기록을 권한에 맞게 조회하고 출력할 수 있는지도 확인해야 합니다.
전환 리허설은 다음 순서로 구성할 수 있습니다.
- 시험 이관을 수행하고 소요 시간과 오류를 기록합니다.
- 업무 담당자가 대표 기록의 내용, 첨부파일, 승인 이력을 대조합니다.
- 조직과 계정, 결재, 알림 등 외부 연동을 실제 사용 흐름으로 확인합니다.
- 최종 변경분 반영과 기존 시스템 입력 중단 시점을 맞춥니다.
- 전환 중단 조건, 복귀 절차, 전환 후 신규 데이터 처리 방법을 확인합니다.
특히 병행 운영을 한다면 어느 쪽을 기준 기록으로 삼을지 정해야 합니다. 두 시스템에 각각 수정이 발생하면 나중에 어떤 값이 맞는지 판단하는 작업이 남습니다.
본 전환 승인서는 “이관 완료”보다 “남은 문제를 알고도 운영할 수 있는가”에 답해야 합니다. 중요 업무를 막는 문제가 남아 있다면 일정과 별도로 전환 여부를 다시 판단해야 합니다.
5. 안정화는 언제 끝났다고 판단하나요?
안정화는 문의가 줄었다는 이유만으로 종료하지 않습니다. 주요 업무가 정상 수행되고, 장애 감지와 복구, 운영 인수인계를 담당 조직이 수행할 수 있을 때 종료를 검토합니다.
운영 전환 시 모니터링, 백업과 복구 검증, 장애 대응 절차, 운영 책임과 인수인계 자료를 확인하는 것은 운영 준비도를 점검하는 주요 방법입니다. 필요한 검증 수준은 업무 중요도와 허용 가능한 중단 범위에 따라 달라집니다.
TCC STEEL 통합 EHS 구축은 2025년 4월 착수해 2026년 1월 오픈했고, 이후 2026년 4월까지 안정화와 고도화를 이어 갔습니다. 오픈과 운영 정착을 별도 구간으로 다룬 경험입니다. 이 기간을 다른 기업의 클라우드 전환 일정에 그대로 대입할 수는 없습니다.
자사 로드맵에는 안정화 기간의 확인 항목을 미리 적어 두는 편이 좋습니다. 주요 업무의 실패와 미처리 연동, 사용자 권한 문제, 반복 문의를 구분해 기록하고 각각의 담당자와 처리 상태를 관리합니다. 사용법 문의를 개발 오류와 같은 목록에만 넣으면 무엇을 수정하고 무엇을 교육해야 하는지 흐려집니다.
매일 쓰는 기능이 정상이어도 월 마감이나 분기 업무는 아직 검증하지 못했을 수 있습니다. 이런 항목은 안정화 종료 시점에 없애지 말고 후속 점검 일정과 담당자를 남깁니다. 운영팀이 알림을 받고 문제를 확인하며 필요한 경우 복구를 요청할 수 있어야 인수인계가 끝난 것입니다.
결론
EHS 클라우드 전환 로드맵은 단계별 완료 기준과 승인 책임자를 함께 정해야 실행 가능한 계획이 됩니다. 현황 진단에서는 범위를, 설계에서는 연결 책임을, 시범 운영에서는 업무 완결성을 확인합니다. 본 전환에서는 이관과 복귀 가능성을, 안정화에서는 운영 조직의 대응 능력을 확인해야 합니다.
전환 계획서를 검토하고 있다면 각 단계 옆에 세 칸을 추가해 보세요. ‘완료를 판단할 증거’, ‘확인할 담당자’, ‘통과하지 못했을 때의 조치’입니다. 이 세 칸이 채워져야 경영진의 일정 판단과 현장의 운영 판단이 같은 기준 위에 놓일 수 있습니다.
자주 묻는 질문
클라우드 전환과 화면 개편을 한 번에 해도 되나요?
가능하지만 기존 기능 이전과 업무 변경의 검증 범위를 분리해야 합니다. 오류가 발생했을 때 환경 변경 때문인지 새 업무 규칙 때문인지 구분할 수 있어야 합니다. 전환에 필수인 변경과 이후 개선할 항목을 먼저 나눠 보세요.
전체 전환 기간은 어떻게 산정하나요?
연동 수, 데이터 품질, 수정 범위, 업무 중단 가능 시간, 사용자 검증 일정에 따라 산정해야 합니다. 현황 진단 전에는 단일 확정일보다 가정과 미확인 항목을 포함한 일정 범위를 제시하는 편이 판단에 도움이 됩니다.
경영진은 전환 진행 상황을 무엇으로 보고받으면 좋을까요?
기능 개발률과 함께 단계별 완료 조건의 충족 여부를 보고받으면 좋습니다. 미해결된 중요 문제, 현장 검증 결과, 다음 단계 승인에 필요한 결정이 드러나야 실제 진행 상태를 판단할 수 있습니다.
제 도움이 필요하시다면
기존 EHS를 어디까지 옮길지 불명확하거나 연동과 운영 책임이 나뉘어 있다면, 현황 진단과 단계별 완료 기준부터 함께 정리할 수 있습니다.
크로플 EHS에서는 제조 현장 업무에 맞춘 구축 경험을 바탕으로 이전 대상 업무와 데이터 범위 검토, 그룹웨어와 ERP 등의 연동 설계, 보안과 운영 조건에 따른 클라우드 구성 검토를 도울 수 있습니다.
구축 방향을 논의할 때는 현재 사용 중인 시스템 목록과 대표 업무 흐름을 먼저 정리해 주세요. 업무 맞춤형 통합 EHS 구축과 전환 검토 방향은 크로플 EHS 공식 웹사이트에서 확인할 수 있습니다.
