사내 시스템 공개 전 확인해야 할 운영 체크리스트 30가지

사내 시스템은 외부 고객 서비스보다 사용자가 적다는 이유로 공개 전 점검이 짧아지기 쉽다. 하지만 결재, 계약, 인사, 회계처럼 업무의 기준이 되는 시스템은 한 번의 권한 오류나 데이터 손실도 실제 업무 중단으로 이어진다.

공개 준비는 화면이 열리는지 확인하는 일이 아니다. 정상 경로와 실패 경로, 권한, 데이터 복구, 배포 취소, 장애 알림, 사용자 지원이 하나의 운영 흐름으로 이어지는지 확인하는 일이다.

아래 30개 항목은 20명에서 100명 안팎의 조직이 사내 시스템을 처음 공개하거나 큰 기능을 배포하기 전에 사용할 수 있는 기준이다. 각 항목에 담당자, 확인 증거, 결과, 미해결 조치와 완료 예정일을 함께 기록하면 체크 표시만 남는 일을 줄일 수 있다.

Supabase의 공식 Production Checklist도 운영 전 목표를 보안, 예상 부하 대응, 가용성으로 나누고 RLS, MFA, SSL, 네트워크 제한 등을 확인하도록 안내한다. Supabase Production Checklist

1. 업무 흐름과 상태

1. 실제 사용자의 정상 경로를 끝까지 실행했는가?

신청, 검토, 승인, 결과 확인처럼 업무 시작부터 종료까지 실제 역할별 계정으로 시험한다. 관리자 계정 하나로 모든 화면을 확인하면 일반 사용자의 권한 문제를 놓칠 수 있다.

2. 거절, 취소, 재시도와 재심 경로가 있는가?

정상 완료만 확인하지 않는다. 외부 연동 실패, 담당자 거절, 사용자 취소, 중복 요청, 재심 요청이 각각 올바른 다음 상태로 이동하는지 확인한다. 실패 액션이 불필요한 필수 입력값 때문에 막혀서도 안 된다.

3. 화면의 버튼과 실제 상태 변경이 일치하는가?

버튼 이름은 이동할 다음 상태를 구체적으로 알려야 한다. 결과가 확정되지 않았는데 완료나 승인으로 표시하지 않고, 취소 버튼이 최초 신청 화면으로 돌아가는 식의 모순이 없는지 본다.

4. 같은 요청이 두 번 들어와도 결과가 안전한가?

사용자의 연속 클릭, 네트워크 재전송, 작업 큐의 재시도로 같은 결재, 메일, 파일 변환이 두 번 실행될 수 있다. 업무 키나 멱등성 키로 중복을 감지하고 이미 끝난 작업을 다시 만들지 않게 한다.

5. 두 사람이 동시에 수정할 때 충돌을 알 수 있는가?

마지막 저장이 조용히 앞선 변경을 덮지 않도록 버전, 수정 시각, 잠금 중 하나를 사용한다. 충돌이 발생하면 누가 무엇을 다시 확인해야 하는지 알려 준다.

2. 계정, 권한과 보안

6. 모든 사용자 노출 테이블에 접근 정책이 있는가?

브라우저에서 접근 가능한 테이블은 RLS를 켜고 SELECT, INSERT, UPDATE, DELETE 권한을 역할별로 확인한다. RLS를 켰지만 정책이 없어서 모두 막히는 경우와, 정책 조건이 넓어 다른 부서 데이터가 보이는 경우를 함께 시험한다.

7. 관리자 키와 service role이 브라우저에 포함되지 않았는가?

Supabase의 secret 및 service role 키는 RLS를 우회하므로 서버에서만 사용한다. 빌드 결과, 클라이언트 환경 변수, 오류 로그, 소스 지도에 비밀값이 들어가지 않았는지 확인한다. Supabase 데이터 보호 지침

8. 관리자 계정에 MFA와 복구 수단이 있는가?

클라우드, DNS, 소스 저장소, DB 관리 계정에 다중 인증을 적용한다. 한 사람만 최고 권한을 가지고 있지 않도록 대체 소유자를 두고, 분실한 인증 수단을 복구하는 절차도 시험한다.

9. 환경별 비밀정보가 분리되고 교체 가능한가?

개발, 시험, 운영 환경이 같은 API 키와 DB 자격 증명을 공유하지 않게 한다. 키의 소유자와 용도, 마지막 교체일을 기록하고 유출 시 폐기 순서를 문서화한다.

10. 로그인과 공개 API의 남용을 제한했는가?

로그인, 비밀번호 재설정, 초대, 파일 업로드, 대량 조회에 속도 제한과 용량 제한을 둔다. 반복 실패와 비정상 사용량을 알림으로 연결하고, 잠금이 정상 사용자를 영구적으로 막지 않도록 복구 경로를 마련한다.

3. 데이터, 파일과 기록

11. DB 변경이 마이그레이션 파일로 재현되는가?

운영 DB를 대시보드에서 직접 수정하지 않는다. 스키마 변경을 버전 관리하고 빈 DB와 시험 데이터에서 처음부터 적용해 본다. 이전 애플리케이션과 잠시 공존할 수 있도록 추가, 전환, 제거 순서로 나눈다.

12. 백업을 새 환경에 실제로 복원했는가?

최근 백업 시각만 보지 않는다. DB, 파일, 권한 정책을 빈 환경에 복원하고 로그인과 핵심 업무를 실행한다. 측정한 복구 시간이 업무의 목표 시간 안에 들어오는지도 확인한다. 백업보다 중요한 복구

13. 보존, 휴지통과 영구 삭제 기준이 있는가?

업무 기록과 첨부 파일을 언제까지 보관할지 정한다. 사용자 삭제, 관리자 복구, 보존 기간 종료, 백업에서 사라지는 시점이 서로 다를 수 있으므로 화면 문구와 실제 동작을 맞춘다. 법적 보존 기간은 해당 조직의 전문가와 별도로 확인한다.

14. 파일 업로드가 서버와 저장소의 제한을 지키는가?

허용 확장자, 실제 파일 형식, 크기, 악성 파일 검사, 중복 이름, CORS를 확인한다. 큰 파일은 서명된 URL로 객체 저장소에 직접 올리고, 업로드 후 서버가 객체를 다시 검증한다. 대용량 파일 직접 업로드 설계

15. 감사 로그가 필요한 변경을 남기는가?

권한 변경, 승인, 삭제, 내보내기, 관리자 열람에 행위자, 대상, 시각, 결과와 필요한 범위의 변경 전후 값을 남긴다. 비밀번호, 토큰, 전체 개인정보는 로그에 기록하지 않고 로그 열람 권한과 보존 기간을 제한한다.

4. 배포, 장애와 복구

16. 개발, 시험, 운영 환경이 구분돼 있는가?

운영 데이터로 기능을 시험하지 않는다. 환경마다 DB, 저장소, 외부 연동, 비밀정보를 분리하고 화면에서 현재 환경을 구분할 수 있게 한다. 시험 메일이나 메시지가 실제 고객에게 발송되지 않게 수신 대상을 제한한다.

17. 배포 전에 자동 검증이 실행되는가?

타입 검사, 정적 분석, 테스트, 빌드, DB 마이그레이션 검증을 배포 조건으로 둔다. 공개 URL 목록, 메타데이터, 끊어진 내부 링크처럼 시스템에 맞는 검증도 추가한다.

18. 운영 배포의 권한과 동시 실행을 통제했는가?

허용된 브랜치만 운영에 배포하고 중요한 변경에는 승인 절차를 둔다. 같은 환경에 두 배포가 동시에 실행되지 않도록 concurrency를 적용한다. GitHub Actions environment는 승인, 브랜치 제한과 환경별 비밀정보를 연결할 수 있다. GitHub Actions 배포 환경

19. 직전 정상 버전으로 돌아갈 수 있는가?

이전 이미지나 배포 ID, 환경 설정, 롤백 권한과 실행 순서를 보존한다. DB 변경은 이전 코드와 호환되게 설계하고 시험 환경에서 실제 전환 시간을 잰다. 5분 안에 되돌리는 배포 운영법

20. DNS, HTTPS와 핵심 health check가 정상인가?

운영 도메인, 리디렉션, 인증서 자동 갱신, 보안 헤더를 확인한다. 홈 화면만 보는 health check 대신 로그인, 핵심 조회, DB 연결, 큐 상태처럼 실제 의존성을 점검하되 민감정보는 응답하지 않게 한다.

5. 관측, 알림과 비용

21. 서비스 밖에서 가용성을 확인하는가?

감시 대상과 다른 장애 영역에서 운영 URL과 핵심 API를 주기적으로 호출한다. DNS, 인증서, 프록시 문제까지 발견하고 연속 실패 기준을 사용해 일시적인 흔들림과 장애를 구분한다.

22. 오류가 배포 버전과 요청 흐름에 연결되는가?

오류 추적 도구에 배포 버전, 추적 ID, 기능 영역을 남긴다. 같은 오류를 묶어 영향 사용자를 파악하고, 요청 본문과 개인정보는 수집 전에 제거하거나 가린다.

23. DB, 저장소와 작업 큐의 업무 지표를 보는가?

CPU와 메모리만 보지 않는다. DB 연결과 느린 쿼리, 저장량 증가, 대기 작업 수, 가장 오래된 작업의 나이, 업무 성공률을 확인한다. 오래 걸리는 작업은 API에서 분리해 실패와 재시도를 관측 가능하게 만든다. 백그라운드 작업과 작업 큐

24. 긴급 알림마다 담당자와 첫 행동이 정해져 있는가?

알림에는 서비스, 시작 시각, 영향, 확인할 대시보드와 실행 문서를 넣는다. 담당자가 응답하지 않을 때의 대체 연락과 사용자 공지 기준을 정하고 시험 알림을 실제 채널로 보내 본다. 소규모 서비스 모니터링 구성

25. 예산과 사용량 증가에 대응할 수 있는가?

월 총액, 서비스별 사용량, 비정상 증가에 알림을 둔다. 알림이 청구를 자동 중지하는지 여부를 구분하고, 한도 도달 시 핵심 업무를 유지하면서 파일 변환이나 AI 기능처럼 비용이 큰 부가 기능을 제한할 방법을 마련한다. 클라우드 예산과 사용량 알림

6. 사용자와 운영 인계

26. 모바일, 키보드와 보조 기술로 핵심 업무가 가능한가?

화면 크기와 확대 배율을 바꾸고 키보드만으로 탐색한다. 포커스가 숨겨진 요소에 남지 않는지, 아이콘 버튼에 구체적인 이름이 있는지, 오류가 색상만으로 전달되지 않는지 확인한다.

27. 사용자가 현재 상태와 다음 행동을 이해할 수 있는가?

제목, 설명, 버튼, 알림에서 같은 개념을 같은 말로 부른다. 오류 메시지는 무엇이 잘못됐고 사용자가 무엇을 할 수 있는지 알려 준다. 처리 결과가 확정되지 않았다면 성공이나 완료라고 표현하지 않는다.

28. 입사, 부서 이동과 퇴사 절차가 준비됐는가?

계정 생성, 역할 변경, 업무 이관, 세션 종료, API 키와 SSH 키 폐기를 한 흐름으로 만든다. 퇴사자의 소유 문서와 예약 작업이 사라지지 않도록 새 담당자에게 이전한다.

29. 장애와 문의를 받을 창구가 분명한가?

사용자가 문제를 신고할 연락처와 필요한 정보, 예상 응답 시간을 안내한다. 운영자는 문의를 사건, 사용법, 개선 요청으로 분류하고 긴급 장애가 일반 문의함에 묻히지 않게 한다.

30. 공개 당일과 공개 후 점검 계획이 있는가?

공개 시간, 담당자, 중단 기준, 공지 문구와 롤백 결정을 미리 정한다. 공개 직후 핵심 흐름과 지표를 확인하고 24시간, 1주일 뒤에 오류, 문의, 사용량, 비용과 미완료 조치를 다시 검토한다.

체크리스트를 완료하는 기준

30개를 모두 예라고 답하는 것이 목표는 아니다. 공개를 막아야 할 위험, 제한적으로 공개할 수 있는 위험, 공개 후 일정 안에 고칠 항목을 구분하는 것이 중요하다. 예외를 허용할 때는 영향, 임시 보호 조치, 책임자와 완료일을 기록한다.

듀오랩스가 보는 공개 준비의 기준은 기능 개수가 아니다. 실패했을 때 상태를 회복할 수 있고, 권한이 업무 역할과 맞으며, 문제가 생기면 사용자가 신고하기 전에 발견하고 되돌릴 수 있는가이다. 이 체크리스트가 반복 가능한 배포 기준이 되면 다음 프로젝트의 준비 시간도 줄어든다.