직원마다 권한 나누기
아르바이트에게 매출 전체를 보여줄 이유는 없어요. 사람마다 할 수 있는 일을 잘라 두는 방법이고, 핵심은 메뉴를 숨기는 게 아니라 데이터를 내주는 창구에서 거절하는 거예요.
쉽게 말하면
가게 열쇠를 생각해 보세요. 알바에게는 출입문 열쇠만 주고, 금고 열쇠와 장부는 사장님이 갖죠. 열쇠를 나눠 주는 게 권한이에요. 그런데 여기서 한 가지가 더 있어요. 금고 문에 "직원 출입금지"라고 종이만 붙여 놓은 것과 자물쇠를 채운 것은 완전히 다른 일이에요. 화면에서 메뉴를 안 보이게 하는 건 종이를 붙인 것이고, 데이터를 내주는 창구에서 거절하는 게 자물쇠예요.
로그인과 인증은 "누구세요"를 확인하는 일까지예요. 여기서 다루는 건 그다음 문장이에요. 확인은 됐는데, 그걸 해도 되나요. 직원인 건 맞지만 금고는 못 여는 상태를 만드는 게 이 문서의 전부예요.
주소를 알면 그대로 열려요. 화면을 그리는 코드는 이미 그 사람 컴퓨터에 내려가 있어요.
메뉴가 보이는지와 무관하게 막혀요. 화면에서 숨기는 건 보기 좋게 하는 보조 장치예요.
왜 숨기는 것만으로는 안 되나
이유는 하나예요. 화면을 그리는 코드는 손님 컴퓨터에서 돌아가요. 사장님 서버에서 돌아가는 게 아니에요. 메뉴 이름·버튼·화면 주소가 전부 그 컴퓨터로 내려가서 거기서 조립돼요. 그러니 "안 보이게" 처리한 건 조립할 때 하나를 안 그린 것뿐이고, 재료는 여전히 그 사람 손에 있어요.
그래서 매출 숫자가 새는 경로는 해킹처럼 거창하지 않아요. 이 정도로 충분해요.
- 1사장님이 매출 화면을 열어 둔 컴퓨터를 알바가 한 번 봤어요. 주소창의 글자를 기억했거나, 브라우저 주소 자동완성에 남았어요.
- 2그 주소를 자기 계정으로 로그인한 상태에서 직접 입력해요. 메뉴가 없어도 주소는 살아 있어요.
- 3화면을 그리는 재료는 이미 내려와 있으니 매출 화면의 틀이 그려져요. 여기까지는 아직 숫자가 없어요.
- 4화면이 창구에 "이번 달 매출 주세요"라고 요청해요. 창구가 누가 요청했는지 안 따지면 그냥 내줘요. 숫자가 채워지고 끝이에요.
마지막 줄이 진짜 관문이에요. 그리고 하나 더 알아야 할 게 있어요. 요청을 보내는 쪽이 적어 보내는 말은 무엇이든 고쳐 쓸 수 있어요. "저는 사장입니다" 같은 표시를 요청에 담아 보내는 방식이면, 그 표시를 바꿔 보내면 통과돼요. 창구는 요청에 적힌 주장을 믿지 말고 자기 장부를 보고 판단해야 해요.
숨기지 말라는 뜻은 아니에요
둘 다 해요. 숨김은 실수 방지예요. 알바가 삭제 버튼을 잘못 눌러 곤란해지는 일을 막아 줘요. 창구 검사는 방어예요. 숨김만 있으면 방어가 없고, 창구 검사만 있으면 눌렀다가 거절당하는 불친절한 화면이 돼요.
나누는 방식은 네 가지고, 각각 값을 치러요
"권한 나눠 주세요"는 한 문장이지만 실제 방식은 여러 개고, 편한 것은 약하고 튼튼한 것은 손이 많이 가요. 무엇을 고르는지 알고 고르는 게 심화예요.
| 방식 | 어떻게 하는 것인가 | 치르는 값 | 언제 맞나 |
|---|---|---|---|
| 화면에서 숨기기 | 역할에 따라 메뉴·버튼을 안 그림 | 방어가 아니에요. 주소를 알면 뚫려요 | 실수 방지용 보조로만. 이것만으로 끝내면 안 돼요 |
| 사람마다 기능 하나하나 | 직원 목록에 기능별 체크칸을 두고 사람마다 켬 | 사람이 늘면 칸이 폭발해요. 새 기능이 생길 때마다 전원의 칸을 다시 만져야 하고, 빠뜨린 칸이 곧 구멍이에요 | 직원 세네 명, 기능도 적을 때 |
| 역할로 묶기 | 사장·매니저·알바처럼 자리를 만들고 자리에 권한을 붙임. 새 직원은 자리만 지정 | 예외를 담기 어려워요. "이 사람만 환불은 되게" 요청이 오면 자리가 계속 늘어나요 | 대부분의 가게에 맞는 기본값. 여기서 시작하세요 |
| 한 줄마다 주인 확인 | 주문·예약 같은 기록 한 줄마다 "이 줄의 주인이 지금 요청한 사람인가"를 창구가 확인 | 규칙을 데이터 창구에 걸어야 하고, 목록을 불러올 때 무거워져요 | 손님 데이터가 한 곳에 섞여 있는 서비스는 선택이 아니라 필수예요 |
셋째와 넷째는 고르는 게 아니에요
겹쳐 써요. 역할은 "직원이 어떤 기능을 쓰나" 를 정하고, 한 줄마다 주인 확인은 "그 기능으로 누구 데이터를 보나" 를 정해요. 질문이 다르니 하나로 다른 하나를 대신할 수 없어요. 매니저가 주문 조회를 쓸 수 있다는 것과, 매니저가 다른 지점 손님 주문까지 봐도 된다는 것은 별개의 결정이에요.
언제 나누면 안 되나
권한은 많이 나눌수록 안전한 게 아니에요. 규칙이 늘면 사람이 전체를 못 봐요. 전체를 못 보는 규칙에는 반드시 구멍이 있고, 구멍이 어디인지 아무도 몰라요. 그래서 안 해야 할 때를 아는 것이 하는 법보다 중요해요.
| 이럴 때는 나누지 마세요 | 왜 | 대신 이렇게 |
|---|---|---|
| 혼자 하는 가게에서 역할 여덟 개를 미리 만들기 | 쓰지 않는 규칙은 검증도 안 돼요. 나중에 직원이 오면 그 규칙이 맞는지 아무도 몰라요 | 사장 한 자리로 시작하고, 사람이 들어올 때 자리를 하나 만들어요 |
| 손님만 쓰는 서비스에 직원 역할표 만들기 | 필요한 건 역할이 아니라 한 줄마다 주인 확인 하나예요. 역할표는 헛수고고 관리 부담만 남아요 | 손님·사장 두 자리로 끝내고, 힘은 주인 확인에 쏟아요 |
| 며칠 도와주는 사람에게 새 역할 파기 | 그 역할이 끝나고도 남아요. 다음에 누가 그 자리에 붙는지 아무도 안 봐요 | 기간을 정한 계정을 주고, 끝나는 날을 캘린더에 적어요 |
| 급하다고 사장님 계정을 빌려주기 | 나눈 노력을 한 번에 무효로 만들어요. 게다가 사고가 나면 누가 했는지 영원히 알 수 없어요 | 필요한 일만 되는 자리를 하나 만들어 주는 게 늘 더 빨라요 |
| "임시로" 관리자 권한 올려 주기 | 회수 날짜가 없는 임시는 영구예요. 되돌리자고 말하는 사람이 아무도 없어요 | 기한이 적히지 않은 승격은 하지 않아요. 적을 수 없으면 그건 영구 권한이에요 |
무너지는 지점
권한 구조는 서서히 낡지 않고 어느 날 갑자기 관리가 안 되는 상태가 돼요. 정해진 숫자는 아니지만 신호가 있어요. 아래 중 하나가 왔으면 지금 방식이 한계에 온 거예요.
| 신호 | 무슨 일이 벌어지나 | 무엇으로 바꾸나 |
|---|---|---|
| 직원이 다섯 명을 넘는다 | 사람마다 체크칸을 맞추다 반드시 틀려요. 새로 온 사람 설정을 기존 직원에게서 복사하면서 필요 없는 권한까지 따라와요 | 자리(역할)를 만들고, 사람에게는 자리만 지정해요 |
| "이 사람만 예외" 요청이 셋을 넘는다 | 자리가 사람 수만큼 늘어나요. 그 시점부터 역할은 이름만 역할이고 실은 사람 목록이에요 | 자리 + 개별 추가 권한으로 층을 나눠요. 예외는 예외 칸에만 적어요 |
| 지점이 두 곳 이상 된다 | "무엇을 하나"에 "어디 것을"이 붙어요. 축이 두 개가 되면 자리 이름 하나로는 표현이 안 돼요 | 자리와 소속을 함께 확인하게 해요. 매니저이면서 A지점 소속일 때만 통과 |
| 목록 한 화면에 수천 줄이 뜬다 | 한 줄씩 자격을 따지면 조회가 무거워져요. 소속이나 주인 칸에 색인이 없으면 기록이 수만 줄로 늘 때부터 체감돼요 | 창구 규칙과 색인을 같이 걸어요. 규칙만 걸고 색인을 빼면 느려져요 |
| 퇴사자 계정이 아직 살아 있다 | 가장 흔한 실제 사고예요. 정교하게 나눈 가게가 이 한 줄로 무너져요 | 퇴사 처리를 계약 종료 절차에 넣어요. 사람 기억에 맡기지 않아요 |
마지막 줄을 다시 볼 필요가 있어요. 준 권한은 회수 절차가 있어야 완성이에요. 나누기만 하고 거두는 방법을 안 만들면, 시간이 지날수록 권한을 가진 사람 수가 한 방향으로만 늘어나요. 사고는 대개 여기서 나요.
사장님이 실제로 겪는 장면
장면 1 · 외주 개발자가 말했다
“알바 계정에서는 매출 메뉴가 안 보이게 처리했습니다.”
이 말로는 판단할 수 없어요. "안 보이게"는 숨김일 수도, 창구 거절일 수도 있어요. 되물을 문장은 하나예요. "메뉴를 안 그린 건가요, 그 주소로 직접 들어가도 데이터가 안 나오는 건가요?" 앞이라고 하면 아직 자물쇠가 없는 거예요.
장면 2 · 세무 담당에게 잠깐 권한을 줬다
“정산 자료를 뽑아야 한다고 해서 관리자로 올려 뒀는데, 보니까 반년이 지났어요.”
임시 권한에 회수 날짜가 없으면 영구 권한이에요. 그리고 필요했던 건 관리자 승격이 아니었어요. 정산 자료는 읽기만 되는 자리로 충분한 경우가 대부분이에요. 할 수 있는 일을 넓히는 대신 필요한 일만 되는 자리를 만드는 게 값이 더 싸요.
장면 3 · 손님이 남의 주문을 봤다
“주문 확인 페이지 주소 끝의 숫자를 하나 바꿔 봤더니 다른 사람 주문이 나왔어요.”
이건 역할 문제가 아니에요. 한 줄마다 주인 확인이 빠진 거예요. 창구가 "이 주문의 주인이 지금 요청한 사람인가"를 안 물었어요. 손님 정보 사고 중 가장 흔한 형태고, 직원 권한을 아무리 잘 나눠도 이건 따로 막아야 해요.
남에게 맡길 때 요구할 것
권한은 눈으로 확인이 안 되는 기능이에요. 화면만 보면 잘 만든 것과 종이만 붙인 것이 똑같이 생겼어요. 그래서 외주로 맡길 때는 요구할 것과 확인할 것을 미리 정해 두는 게 유일한 방법이에요.
- 1권한표를 문서로 받아요. 세로에 자리(사장·매니저·알바), 가로에 기능, 칸에 가능·불가를 적은 표요. 말로 합의하면 서로 다르게 기억해요.
- 2"표에 없는 것은 금지"를 못박아요. 앞으로 새로 생기는 기능이 자동으로 허용이 되면, 기능을 추가할 때마다 구멍이 하나 늘어요. 기본값이 금지여야 앞으로 생길 구멍 대부분이 막혀요.
- 3화면이 아니라 창구에서 막았다는 확인을 요구해요. "숨겼다"가 아니라 "요청을 거절한다"라는 답이 나와야 해요.
- 4검사가 한 곳에 모여 있는지 물어요. 화면마다 따로 적어 뒀으면 새 화면을 만들 때 반드시 하나를 빠뜨려요. 창구 앞에 검사대를 하나 두는 구조여야 해요.
- 5누가 언제 무엇을 했는지 기록을 남기게 해요. 권한을 나누는 이유의 절반은 사고가 났을 때 추적이에요. 기록이 없으면 나눈 효과가 반이에요.
- 6회수 절차까지 받아요. 직원이 나갈 때 어디서 무엇을 누르면 끝인지, 한 화면에서 되는지 확인해요.
사장님이 직접 할 수 있는 시험은 하나예요
알바 권한 계정으로 로그인한 다음, 사장님 화면 주소를 주소창에 그대로 붙여 넣어 보세요. 화면이 열리고 숫자가 보이면 아직 안 된 거예요. "권한이 없습니다"가 나와야 통과예요. 이 시험을 통과했는지 물어보면 대화가 아주 짧아져요.
자주 묻는 것
- Q. 직원마다 계정을 따로 만들면 요금이 더 나오나요?
- 쓰는 서비스마다 달라요. 사람 수로 받는 곳도 있어요. 정확한 금액은 그 서비스 요금 안내에서 확인해야 해요. 다만 계정 공유보다 비싼 경우는 드물어요. 사고 한 번이 훨씬 비싸니까요.
- Q. 퇴사자 계정은 지워야 하나요, 막아야 하나요?
- 먼저 막아요(로그인 불가). 지우면 그 사람이 남긴 기록의 작성자가 사라져서 나중에 추적이 안 돼요. 완전히 정리하는 시점은 보관 기간 규정을 따라야 하니 개인정보 쪽을 확인하세요.
- Q. 알바가 실수로 지운 걸 되돌릴 수 있나요?
- 권한과는 다른 문제예요. 1차 방어는 삭제 권한을 애초에 주지 않는 것이고, 2차는 백업이에요. 알바에게 삭제를 줄 이유는 거의 없어요. 취소나 숨김으로 충분해요.
- Q. 최고 권한 계정이 제 것 하나뿐인데 괜찮나요?
- 그 자체가 위험이에요. 폰을 잃어버리면 아무도 못 들어가요. 관리자를 두 명 두거나 복구 수단을 두 가지 준비하세요. 단 두 번째 관리자도 무엇을 했는지 기록이 남아야 해요.
- Q. 권한을 나눠 줄 권한도 따로 있나요?
- 네, 여기가 가장 자주 빠지는 칸이에요. 매니저에게 직원 관리를 맡겼는데 그 매니저가 자기 권한을 올릴 수 있으면 나눈 게 무의미해요. "권한을 바꿀 수 있는 사람" 은 별도 칸으로 두세요.
- Q. 화면에 안 보이는데 왜 위험하다는 거예요?
- 숨긴 메뉴의 이름과 주소는 손님 컴퓨터로 내려간 코드 안에 글자로 남아 있어요. 브라우저의 개발자 도구로 그 글자를 찾을 수 있어요. 숨김은 잠금이 아니라 정리예요.
- Q. 권한 사고가 이미 났으면요?
- 순서가 있어요. 그 계정을 먼저 막고, 그다음에 누가 무엇을 봤는지 기록을 확인해요. 손님 정보가 관련되면 신고 의무가 생길 수 있어서 사고 대응 쪽 절차를 따라야 해요.
확인해 보세요
개발자가 "알바 화면에서 매출 메뉴를 숨겼습니다"라고 했어요. 다음에 물어볼 한 문장은?
하나 더
세무 담당이 정산 자료를 뽑아야 한다고 해요. 가장 안전한 조치는?
마지막
손님이 주소 끝 숫자를 바꿔서 남의 주문을 봤어요. 무엇이 빠진 걸까요?
직접 해보기
권한 규칙은 화면이 아니라 이쪽에 걸려요
손님 데이터를 담는 곳을 연결하는 화면이에요. 한 줄마다 주인을 확인하는 규칙은 여기 연결된 쪽에 걸립니다. 지금 연결하지 않고 어떤 칸이 있는지 눈으로만 봐도 개발자와의 대화가 쉬워져요.
연결 센터 열기직접 해보기
만들 때부터 요청 문장에 넣어 보세요
나중에 붙이는 것보다 처음부터 넣는 게 훨씬 쉬워요. 이렇게 적으면 돼요. "직원 자리는 사장·매니저·알바 셋. 매출과 정산은 사장만, 환불은 매니저까지, 알바는 주문 접수만. 표에 없는 기능은 전부 금지. 화면 숨김이 아니라 데이터 요청 단계에서 거절."
스튜디오 열기더 깊이 (안 읽어도 괜찮아요)
"확인"과 "허용"은 다른 말이에요 · 개발자들은 누구인지 확인하는 일을 authentication, 그걸 해도 되는지 정하는 일을 authorization이라 부르고 둘 다 auth로 줄여 써요. 그래서 "auth 문제예요"라는 말은 두 가지 중 어느 쪽인지 알 수 없어요. 되물을 때 줄임말을 쓰지 말고 "확인이 안 되는 건가요, 확인은 됐는데 막힌 건가요"로 나눠 물으면 오해가 사라져요.
권한이 없을 때 뜨는 번호 · 권한이 없어서 막히면 창구는 보통 403이라는 번호를 돌려줘요. 아예 없는 주소는 404예요. 그래서 403이 떴다는 건 "그건 있는데 당신은 안 돼요"라는 뜻이고, 그 자체로 존재를 알려주는 정보가 돼요. 그래서 민감한 관리자 주소는 일부러 404로 돌려주는 방식을 쓰는 곳도 있어요. 번호 읽는 법은 에러 읽기에 있어요.
이름 붙은 자리 대신 조건식으로 정하는 방식 · 큰 조직은 "매니저" 같은 이름 대신 "본인이 담당한 지점의, 최근 30일 안의 주문만"처럼 조건으로 권한을 정해요. 훨씬 유연하지만 값을 치러요. 표로 그려지지 않는 권한은 나중에 아무도 검증하지 못해요. 가게 규모에서는 이름 붙은 자리가 거의 항상 더 나은 선택이에요.
기록이 권한의 나머지 절반이에요 · 누가 언제 무엇을 했는지 남기는 기록이 있으면, 권한을 조금 넓게 줘도 감당할 수 있어요. 반대로 기록이 없으면 권한을 아무리 좁혀도 사고가 났을 때 아무것도 못 밝혀요. 업체를 넘겨받을 때도 이 기록이 있는지가 물어볼 목록 위쪽에 있어야 해요.
이것만 기억하세요
- ·권한은 메뉴를 숨기는 일이 아니라 데이터 창구에서 거절하는 일이에요
- ·"표에 없는 것은 금지"가 기본값이어야 앞으로 생길 구멍이 막혀요
- ·이름 붙은 자리로 시작하고, 예외가 셋을 넘으면 층을 나눠요
- ·준 권한은 회수 절차까지 있어야 완성이에요. 퇴사자 계정이 가장 흔한 사고예요
- ·확인법은 하나예요. 알바 계정으로 사장님 화면 주소를 직접 열어 보기