업무 시스템 보안 단계적 도입: 1단계 기준선과 나중에 붙일 것

첫 고객의 업무 시스템을 만들기 시작하면 보안 항목 목록이 금세 길어집니다. MFA, 세션, 감사 로그, 백업, 접근 통제, SSO, 기기 인증, 로그 중앙화, 전용 네트워크. 목록을 다 채우고 시작하려 하면 업무 기능을 만들기 전에 인프라 설정으로 몇 주가 지나갑니다.

그렇다고 「일단 만들고 보안은 나중에」로 가면, 나중에 뜯어고치기 어려운 것부터 빠집니다. 중요한 것은 목록의 길이가 아니라 무엇을 처음에 넣고 무엇을 뒤로 미룰지의 기준입니다.

보안을 「수준」 하나로 보는 시각

보안을 한 덩어리로 보면 선택지가 둘뿐입니다. 엔터프라이즈급으로 다 하거나, 최소한만 하거나. 첫 사내 시스템에서는 둘 다 답이 아닙니다.

항목을 성격으로 나누면 다른 그림이 나옵니다.

성격	예	나중에 추가하면
구조에 박히는 것	인증 방식, 권한 모델, 데이터 격리(테넌트), 감사 로그, 백업	스키마와 코드 전반을 고쳐야 한다
설정으로 붙는 것	접근 IP 제한, SSO, 기기 인증, 로그 중앙화, 전용 네트워크	대체로 나중에 붙일 수 있다

단계적으로 간다는 것은 앞줄을 미룬다는 뜻이 아닙니다. 앞줄은 처음부터 제대로 만들고, 뒷줄만 필요할 때 붙이는 것입니다.

1단계: 첫 고객 운영 시작

첫 배포에 들어가는 기준선입니다.

직원 → HTTPS → Vercel(Firewall) → Next.js
                                    ↓
                          인증 (ID/PW + MFA)
                                    ↓
                          서버 권한 확인 (RBAC)
                                    ↓
                     PostgreSQL (행 수준 보안, RLS)

여기에 감사 로그, 자동 백업, 비밀값 관리를 더합니다.

Supabase 를 쓴다면 프로덕션 체크리스트가 같은 방향을 권합니다. 문서는 노출되는 모든 테이블에 RLS 를 켜라고 하면서, RLS 없이 합리적인 정책도 없는 테이블은 어떤 클라이언트든 데이터를 읽고 고칠 수 있다고 적습니다. 그리고 Supabase 계정 자체를 MFA 로 보호하라고 안내합니다. GitHub 로그인을 쓴다면 GitHub 에 2FA 를 켜라는 내용까지 포함돼 있습니다. 조직 차원의 MFA 강제도 검토하라고 덧붙입니다.

계정 보호가 목록에 있는 것이 중요합니다. 애플리케이션을 아무리 단단히 만들어도, 그 인프라를 관리하는 계정이 비밀번호 하나로 열리면 층이 무너집니다.

1단계에서 제가 반드시 확인하는 것은 넷입니다.

1. 모든 테이블에 RLS 와 정책이 있는가
2. 서버 함수와 데이터 접근 계층에서 인증·권한·소유를 확인하는가
3. 관리자 계정에 MFA 가 걸려 있는가 (앱과 인프라 양쪽)
4. 백업이 돌고 있는가, 그리고 복구를 한 번이라도 해 봤는가

2단계: 실제 업무에 쓰기 시작하면

고객이 매일 쓰기 시작하면 사용 패턴이 생깁니다. 그때 붙이는 것들입니다.

• 로그인과 비밀번호 재설정 경로에 속도 제한
• 세션 만료 정책 정리 (유휴·절대·갱신)
• 관리자에게 MFA 강제, 민감한 동작 전 재인증
• 데이터베이스 네트워크 제한
• 개발·스테이징·운영 환경 분리
• 백업 복구 테스트

Supabase 성숙도 모델 문서가 이 단계를 다룹니다. 문서는 프로토타이핑 때의 방식과 운영에서의 방식이 같으면 안 된다고 하면서, local → staging → prod 여러 환경을 운영하고, 운영 비밀번호를 팀과 공유하지 말고, 모든 변경을 버전 관리되는 마이그레이션으로 CI 를 통해 적용하라고 권합니다. GitHub Actions 를 쓴다면 승인 워크플로로 마이그레이션이 실수로 실행되는 것을 막으라는 내용도 있습니다. 그리고 운영 데이터베이스 접근을 네트워크 제한으로 좁히라고 합니다.

1인 개발이라 「팀과 공유하지 말라」는 항목이 남 얘기처럼 보일 수 있지만, 실제로는 내 노트북과 CI 가 서로 다른 주체입니다. 사람이 하나여도 경로는 여럿입니다.

3단계: 규모나 요구가 커질 때

다음 조건이 생기면 접근 통제를 앞단으로 넓힙니다.

• 사용자가 50~100명 규모로 늘어난다
• 개인정보, 회계 자료, 민감한 생산 정보가 쌓인다
• 고객사가 보안 감사나 점검 항목을 요구한다

이때 검토하는 것이 SSO, 기기 기반 접근 통제, IP 제한, 로그 중앙화, 시점 복구(PITR), 운영 전용 관리 계정입니다.

여기서 플랜 제약을 먼저 확인해야 합니다. Vercel 문서에 따르면 Trusted IPs는 Enterprise 플랜 기능이고, 허용되지 않은 IP 의 요청에는 배포 URL 이 404 No Deployment Found 를 돌려줍니다. Password Protection은 Pro 와 Enterprise에서 쓸 수 있습니다.

「IP 로 막으면 되지 않나」가 계획에 들어 있었다면, 그 기능이 지금 플랜에 있는지부터 봐야 합니다. 없다면 그 자리를 앱 쪽 통제나 다른 앞단 서비스로 채워야 하고, 그것은 3단계가 아니라 1단계 설계에 영향을 줍니다.

미루면 비싸지는 것과 그렇지 않은 것

단계를 나눌 때 쓰는 기준을 표로 정리하면 이렇습니다.

항목	단계	미뤘을 때의 비용
테넌트 격리 (모든 테이블의 tenant 열과 정책)	1	나중에 넣으면 전 테이블 마이그레이션과 전 쿼리 검토
권한 모델 (역할과 확인 위치)	1	화면과 서버 코드 전반을 다시 훑어야 한다
감사 로그	1	소급이 불가능하다. 안 남긴 기간은 영영 비어 있다
백업	1	사고가 나면 그때 없다
MFA	1~2	사용자에게 다시 등록을 요청해야 한다
세션 정책	2	설정 변경으로 대체로 가능
속도 제한, 네트워크 제한	2	설정으로 추가
SSO, 기기 인증, 로그 중앙화	3	붙이는 비용은 들지만 구조는 유지된다

감사 로그가 1단계인 이유가 눈에 띄는 대목입니다. 다른 항목은 늦게 넣어도 그때부터 효력이 생기지만, 로그는 남기지 않은 기간을 되살릴 수 없습니다. 사고 조사에서 필요해지는 시점은 항상 사후입니다.

첫 프로젝트를 템플릿으로 남기기

이 구조가 한 번 만들어지면 다음 고객부터는 업무 기능만 만들면 됩니다. 그래서 첫 프로젝트에서 1단계에 해당하는 부분을 재사용 가능한 템플릿으로 떼어 두는 것이 값을 합니다. 인증, 역할과 권한, 테넌트 열과 정책, 감사 로그 테이블, 백업 설정, 비밀값 관리 규칙입니다.

여기서 주의할 점이 하나 있습니다. 템플릿에 들어가는 것은 구조이고, 정책의 세부 내용은 고객마다 다르다는 것입니다. 역할 이름, 승인 단계, 보관 기간은 그 회사의 업무 규칙입니다. 구조를 재사용하되 규칙은 매번 확인하는 편이 맞다고 봅니다.

단계를 나누는 기준 한 줄

각 항목을 놓고 이렇게 물으면 단계가 정해집니다. 지금 넣지 않으면, 나중에 넣을 때 스키마나 코드 전반을 고쳐야 하는가.

그렇다면 1단계입니다. 설정 화면에서 켜면 되는 것, 플랜을 올리면 생기는 것, 서비스를 하나 더 붙이면 되는 것은 뒤로 미뤄도 됩니다. 각 층이 무엇을 막는지에 대해서는 업무 시스템 보안 구성에 따로 정리했습니다.

여기까지가 확실한 부분

노출 테이블에 RLS 를 켜라는 권고, Supabase 계정과 GitHub 계정의 MFA·2FA 안내, 조직 차원 MFA 강제 검토는 Supabase 프로덕션 체크리스트 기준입니다. 여러 환경 운영과 버전 관리되는 마이그레이션, CI 승인 워크플로, 네트워크 제한 권고는 Supabase 성숙도 모델 문서 기준입니다. Trusted IPs 가 Enterprise 플랜이고 차단 시 404 No Deployment Found 를 돌려준다는 점, Password Protection 이 Pro 와 Enterprise 에서 제공된다는 점은 Vercel 문서 기준입니다. 플랜과 요금은 바뀌므로 도입 시점에 다시 확인해야 합니다. 어느 단계까지가 「충분한지」는 다루는 데이터와 고객의 요구에 따라 달라지므로, 이 글은 순서에 대한 판단까지만 적었습니다.