계정만 나눠주세요가 왜 견적을 키울까요 | 권한 7가지

“관리자 계정을 부서별로 좀 나눠주세요.”

기능 목록에서 이 요청은 한 줄이에요. 화면으로 봐도 계정 목록 하나에 체크박스 몇 개면 될 것 같고요. 그런데 견적서를 받아보면 이 한 줄이 예상보다 크게 잡혀 있어요.

값이 붙는 자리는 계정을 만드는 쪽이 아니에요. 누가 무엇을 어디까지 볼 수 있는지를 정하고, 그 기록을 남기는 쪽이에요. 백오피스든 관리자 페이지든 고객용 서비스든 성격은 같아요.

1. 계정 나누기가 왜 한 줄이 아닐까요

외주개발 견적을 받아보면 권한은 다른 기능과 성격이 다르다는 게 드러나요. 게시판이나 주문 관리는 화면을 만들면 끝이지만, 권한은 이미 만든 모든 화면에 다시 손이 가는 작업이거든요.

화면이 서른 개인 시스템에 역할을 세 개 만들면, 확인해야 할 경우가 아흔 개로 늘어요. 그중 하나만 빠져도 볼 수 없어야 할 사람이 목록을 보게 돼요. 그래서 권한은 개발 시간보다 확인 시간이 더 드는 항목이에요.

견적서에 ‘권한 관리 1식’이라고 적힌 항목을 열어보면 대체로 이 정도가 들어 있어요.

• 역할을 만들고 사용자에게 붙이는 화면
• 역할별로 메뉴를 보이거나 감추는 처리
• 관리자만 접근 가능한 화면 구분

여기까지는 대개 포함이에요. 아래부터가 자주 빠져요.

2. 권한은 화면이 아니라 조합이에요

권한을 정할 때 실제로 정해야 하는 건 세 가지예요. 이 셋이 곱해지면서 경우의 수가 만들어져요.

축	정해야 하는 것	예시
역할	사람을 몇 갈래로 나누나요	대표·팀장·담당자·외부 협력사
기능	각 화면에서 무엇을 할 수 있나요	보기·등록·수정·삭제·내려받기
데이터 범위	같은 화면에서 어디까지 보나요	전사·우리 팀·내가 담당한 건만

세 번째 줄이 값을 가장 크게 움직여요. 앞의 둘은 메뉴를 감추면 되지만, 데이터 범위는 데이터를 꺼내오는 방식 자체를 바꿔야 해요. 목록을 불러올 때마다 “이 사람이 볼 수 있는 것만”이라는 조건이 따라붙어야 하거든요.

실무에서 자주 나오는 요청 하나를 예로 들어볼게요. “팀장은 팀원 데이터를 다 보되, 다른 팀 건은 못 보게 해주세요.” 말은 한 문장인데, 조직도가 시스템 안에 들어와 있어야 하고 조직이 바뀌면 그 관계도 같이 바뀌어야 해요. 이 요청이 들어오는 순간 인사 정보와 연결하는 작업이 범위에 들어와요.

용어 하나 풀어둘게요. 실무에서는 역할 기반 접근 제어라고 부르는데, 사람마다 권한을 일일이 주는 대신 역할에 권한을 붙이고 사람에게 역할을 주는 방식이에요. 사람이 바뀔 때 역할만 갈아 끼우면 되니 관리가 줄어요. 견적서에 이 단어가 있으면 최소한 구조를 생각하고 잡은 값이에요.

3. 법이 요구하는 것이 따로 있어요

개인정보를 다루는 시스템이라면 협상 대상이 아닌 항목이 있어요. 개인정보보호위원회의 「개인정보의 안전성 확보조치 기준」이 정해둔 것들이에요.

접근 권한 쪽에서 요구하는 것

• 업무 수행에 필요한 최소한의 범위로 권한을 차등 부여할 것
• 인사이동이나 업무가 바뀌면 지체 없이 권한을 변경하거나 말소할 것
• 권한을 주고 바꾸고 없앤 내역을 전자적으로 기록하고 최소 3년 보관할 것
• 계정은 취급자별로 발급하고 다른 사람과 공유하지 않을 것

접속기록 쪽에서 요구하는 것

• 접속기록을 1년 이상 보관할 것
• 5만 명 이상의 정보주체 정보를 처리하거나 고유식별정보·민감정보를 처리하는 시스템이면 2년 이상
• 접속기록을 월 1회 이상 점검할 것

세 번째 항목인 3년 기록이 견적에서 자주 빠져요. 권한 화면은 만들었는데 누가 언제 누구에게 무슨 권한을 줬는지 남기지 않는 경우예요. 나중에 붙이려면 이미 지나간 변경 이력이 없으니 그 기간은 복구가 안 돼요.

접속기록 점검도 마찬가지예요. 기록을 쌓는 것과 점검할 화면을 만드는 건 다른 일인데, 견적에는 대개 앞쪽만 들어가요. 점검 화면이 없으면 담당자가 매달 데이터베이스를 직접 열어야 해요.

4. 사람이 바뀔 때 진짜 모습이 드러나요

권한 기능이 잘 만들어졌는지는 오픈 직후가 아니라 첫 인사이동 때 드러나요. 그때 나오는 질문이 정해져 있어요.

퇴사자 계정은 지우나요 잠그나요. 지우면 그 사람이 남긴 기록의 작성자가 사라져요. 잠그면 계정 목록이 계속 길어져요. 대개는 잠그고 목록에서 감추는 쪽으로 정하는데, 이걸 정하지 않으면 개발자가 임의로 결정해버려요.

휴직자는 어떻게 하나요. 권한을 없앴다가 복직 때 다시 주려면 이전에 뭘 갖고 있었는지 기록이 있어야 해요.

부서가 통폐합되면요. 역할에 붙은 데이터 범위가 조직도를 참조하고 있으면 조직이 바뀔 때 같이 움직여야 해요. 안 그러면 없어진 팀의 데이터를 아무도 못 보는 상태가 돼요.

협력사 계정은 언제 끊나요. 프로젝트 단위로 들어오는 외부 인력에게는 만료일이 필요해요. 만료일 없이 준 계정은 대체로 몇 년씩 살아남아요.

운영사 Tip. 저희는 권한 항목을 볼 때 화면 수보다 “1년에 몇 번 사람이 바뀌나요”를 먼저 물어요. 조직이 자주 움직이는 회사일수록 자동으로 처리되는 부분이 있어야 하고, 그게 초기 견적을 올리는 대신 매달 나가는 담당자 시간을 줄여줘요.

5. 견적서에서 자주 빠지는 칸

권한 항목에서 실제로 자주 빠지는 것을 모아봤어요.

• 권한 변경 이력 — 3년 보관이 필요한데 기록 자체가 없는 경우
• 접속기록 점검 화면 — 쌓기는 하는데 볼 방법이 없는 경우
• 데이터 범위 규칙 — 메뉴는 감췄는데 주소를 직접 입력하면 열리는 경우
• 내려받기 통제 — 화면에서는 못 보는데 엑셀로는 전부 받아지는 경우
• 역할 추가 방법 — 새 역할이 필요할 때마다 개발사에 요청해야 하는 구조

네 번째가 특히 자주 새는 자리예요. 목록 화면에는 권한을 걸었는데 내보내기 기능에는 같은 조건을 안 걸어두는 경우가 실제로 많아요. 화면으로는 안 보이니 오픈 뒤에도 한동안 모르고 지나가요.

다섯 번째는 값이 아니라 시간의 문제예요. 역할을 관리자가 직접 만들 수 있게 하면 초기 비용이 올라가지만, 그렇지 않으면 조직이 바뀔 때마다 개발 요청을 넣게 돼요. 조직이 안정적인 회사라면 굳이 안 만들어도 되고, 자주 바뀌는 회사라면 넣는 편이 나아요.

6. 범위별로 어느 정도를 잡아야 할까요

권한만 따로 떼서 값을 매기기는 어려워요. 다른 기능에 얹히는 항목이라서요. 대신 범위가 어떻게 늘어나는지는 정리해볼 수 있어요.

자사 실무 기준 예시 — 범위가 커지는 순서

단계	무엇까지 하나요	확인 부담
1단계	관리자와 일반 사용자 구분, 메뉴 감추기	화면 수만큼
2단계	역할 3～5개, 기능별 보기·수정 구분	화면 수 × 역할 수
3단계	데이터 범위 분리(팀·담당 건)	목록마다 조건 추가
4단계	변경 이력·접속기록·점검 화면	별도 화면과 저장 설계

위 표는 저희가 프로젝트를 나눌 때 쓰는 실무 구분이지 시장 통계가 아니에요.

공식 외부 기준 — 인건비 참고선

구분	값	출처
응용SW개발자 월 평균임금	약 775만 원	KOSA 2026 SW기술자 평균임금

ERP 개발 비용처럼 규모가 큰 프로젝트일수록 3단계와 4단계 사이에서 값이 가장 크게 벌어져요. 3단계까지는 기능 개발이지만 4단계는 저장 구조와 운영 절차가 함께 붙거든요. 그래서 견적을 비교할 때 세 곳이 각각 몇 단계까지를 잡았는지부터 맞춰보셔야 해요. 단계가 다르면 총액 비교가 의미가 없어요.

7. 견적서에서 볼 7가지

개발 견적서에서 권한 항목을 받았다면 이 일곱 가지가 적혀 있는지 보세요.

1. 역할 수와 이름 — 몇 개를 만들고 각각 무엇을 하나요
2. 데이터 범위 규칙 — 같은 화면에서 사람마다 다르게 보이나요, 규칙이 몇 줄인가요
3. 권한 변경 이력 — 부여·변경·말소를 기록하고 3년 보관하나요
4. 접속기록 — 몇 년 보관하고 월 점검 화면이 있나요
5. 계정 정책 — 개인별 발급인가요, 퇴사·휴직·만료 처리가 정해져 있나요
6. 내려받기 통제 — 목록 권한과 같은 조건이 걸리나요
7. 역할 추가 방식 — 관리자가 직접 만드나요, 개발 요청인가요

일곱 항목 중 3번과 4번은 협상 대상이 아니에요. 개인정보를 다룬다면 공개된 기준이 요구하는 것이고, 나중에 붙이면 지나간 기간의 기록은 되살릴 수 없어요. 나머지 다섯 개는 오픈 시점에 어디까지 할지 정하고 단계적으로 늘려도 괜찮아요.

8. 자주 묻는 질문 (FAQ)

권한 관리 기능 개발 비용은 얼마나 잡아야 하나요?

역할을 몇 개로 나누느냐가 아니라 조합이 몇 개 나오느냐로 갈려요. 둘로 나누고 메뉴를 감추는 수준이면 화면 한두 개면 돼요. 부서별로 보이는 데이터가 다르고 권한 변경 기록까지 남겨야 하면 작은 프로젝트 하나가 돼요. ‘권한 관리 1식’이라고만 적혀 있다면 역할 수와 데이터 범위 규칙이 몇 줄인지 확인하세요.

직원마다 계정을 따로 만들어야 하나요?

개인정보를 다루는 시스템이라면 그래야 해요. 안전성 확보조치 기준이 계정을 개인정보취급자별로 발급하고 공유하지 않도록 하고 있어요. 팀에서 계정 하나를 함께 쓰면 사고가 났을 때 누가 무엇을 했는지 확인할 방법이 사라져요.

접속기록은 얼마나 보관해야 하나요?

기본은 1년 이상이고, 5만 명 이상의 정보주체 정보를 처리하거나 고유식별정보·민감정보를 다루면 2년 이상이에요. 월 1회 이상 점검하도록 하는 조항도 있어요. 견적 관점에서는 저장 공간보다 점검 화면이 문제예요.

9. 정리하며

권한은 만들기 어려운 기능이 아니에요. 어려운 건 빠진 자리를 찾는 일이에요. 화면 서른 개에 역할 세 개면 확인할 곳이 아흔 곳인데, 그중 하나가 새면 기능이 잘 도는 것과 상관없이 사고가 돼요.

저희는 권한 항목을 볼 때 역할 수보다 조직이 1년에 몇 번 움직이는지를 먼저 봐요. 10년 넘게 50개가 넘는 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해오면서, 권한 설계가 결국 사람이 바뀔 때 값을 청구한다는 걸 계속 확인했거든요. 롯데·캐논 같은 곳과도 함께해 왔고요.

권한을 어디까지 넣고 무엇을 다음으로 미룰지 정리가 필요하시면, 지금 조직도와 화면 목록만 들고 오셔도 단계부터 같이 나눠볼 수 있어요 →

함께 보면 좋은 글이에요.

• 백오피스, 왜 화면보다 비용이 클까요
• 로그인 하나에 얼마가 붙나요 | 소셜·본인인증 6가지
• 관리자 페이지는 왜 비용 차이가 크게 날까요