권한과 역할

로그인은 누구인지 확인하는 일이고, 권한은 그 사람이 무엇까지 할 수 있는지 정하는 일이에요. 알바에게 관리자 화면을 통째로 열어 주면 사고가 전부 사장님 책임이 돼요.

쉽게 말하면

가게 열쇠 꾸러미를 생각해 보세요. 사장님 꾸러미에는 정문·창고·금고 열쇠가 다 달려 있어요. 그런데 아침에 문을 여는 알바에게 그 꾸러미를 통째로 넘기는 사장님은 없죠. 정문 열쇠 하나만 복사해서 줘요. 권한은 딱 이 복사 열쇠예요. 같은 가게에 들어오지만 열 수 있는 문이 사람마다 다른 것, 그게 전부예요.

이 일이 헷갈리는 이유는 이름이 두 개라서예요. 로그인은 누구인지 확인하는 문이고, 권한은 들어온 뒤에 열리는 문의 개수예요. 로그인만 있고 권한이 없으면, 문을 통과한 사람 전부가 금고 앞에 서 있는 상태가 돼요.

많이 하는 방법

계정 하나를 같이 써요 · 아이디 admin, 비밀번호를 단톡방에 공유 · 알바도 사장님도 같은 화면 · 그만둔 사람도 그대로 알 수 있음

당장은 제일 편해요. 사고가 나기 전까지는요. 주문이 지워졌을 때 누가 지웠는지 물어볼 수 없고, 알바가 그만둬도 비밀번호를 바꾸기 전까지는 문이 열려 있어요.

값을 치른 방법

사람마다 계정, 계정마다 역할 · 알바는 주문 확인과 배송 입력만 · 매출과 손님 명단은 사장님만 · 그만두면 그 계정만 끔

만드는 데 반나절이 더 들어요. 대신 누가 무엇을 했는지 남고, 사람이 나갈 때 비밀번호를 전부 바꾸는 소동이 사라져요.

역할은 사람이 아니라 일에 붙여요

권한을 사람 이름으로 주기 시작하면 사람이 늘 때마다 처음부터 다시 정해야 해요. 그래서 순서를 뒤집어요. 일 묶음에 이름을 붙이고, 사람에게는 그 이름을 줘요. 이 이름 묶음이 역할이에요.

역할	볼 수 있는 것	할 수 있는 것	주면 안 되는 것
손님	자기 주문과 자기 정보	주문하기, 자기 글 고치기	남의 주문 화면. 주소만 바꿔서 열리면 그건 권한이 없는 거예요
알바	오늘 들어온 주문 목록	주문 상태 바꾸기, 송장 번호 넣기	손님 연락처 전체 내려받기, 가격과 할인 바꾸기
매니저	주문 전체와 재고	환불 처리, 상품 등록과 수정	정산 계좌 바꾸기, 다른 사람 권한 올리기
사장님	전부	전부, 특히 권한을 주고 뺏는 일	이 계정으로 일상 업무를 보는 것. 평소에는 매니저 계정을 쓰는 편이 안전해요
외주 개발자	코드와 오류 기록	고치고 올리기	진짜 손님 명단. 연습용 자료로 충분한 경우가 대부분이에요

네 번째 줄이 제일 자주 무너져요

사장님 계정으로 하루 종일 일하면, 그 창이 열린 노트북을 카페에 두고 화장실을 가는 순간 가게 전체가 열려 있어요. 사장님 계정은 권한을 바꿀 때만 꺼내 쓰는 열쇠로 두세요. 은행 도장을 지갑에 넣고 다니지 않는 것과 같은 이야기예요.

사고는 이런 순서로 나요

권한 사고는 해킹처럼 오지 않아요. 선의로 시작해서 아무도 잘못한 적이 없는 채로 커져요. 다섯 걸음이 거의 똑같이 반복돼요.

1바빠서 계정을 하나 더 만들지 않아요. "오늘만" 사장님 아이디를 알려 줘요. 여기까지는 아무 일도 안 생겨요.
2그 비밀번호가 단톡방에 남아요. 나중에 들어온 사람도 위로 스크롤하면 볼 수 있어요. 몇 명이 아는지 세는 것이 이때부터 불가능해져요.
3손님 명단이 한 번 내려받아져요. 관리자 화면에는 대개 전체 내보내기 버튼이 있어요. 파일이 어느 컴퓨터에 갔는지는 아무 데도 안 남아요.
4주문 하나가 사라져요. 지운 사람이 실수인지 고의인지 물어볼 수가 없어요. 계정이 하나라 누가 무엇을 했나 기록에 남는 이름도 하나예요.
5사람이 그만둬요. 비밀번호를 바꾸면 되지만, 그 계정으로 연결해 둔 결제·메일·통계까지 같이 끊겨요. 그래서 바꾸는 걸 미루게 되고, 문은 계속 열려 있어요.

이 다섯 걸음에서 사장님이 잃는 건 데이터만이 아니에요. 누구 책임인지 말할 근거를 잃어요. 손님 정보가 샜을 때 "직원이 그랬다"고 말하려면 그 직원이 한 일이 기록으로 남아 있어야 하는데, 계정이 하나면 기록에는 사장님만 찍혀 있어요.

장면 1 · 외주 개발자가 작업을 시작하며 말했다

“관리자 계정 하나만 주시면 제가 보면서 고칠게요.”

거절할 필요는 없어요. 대신 되물을 게 하나 있어요. "진짜 손님 자료가 꼭 필요한 작업인가요." 화면을 고치는 일이면 연습용 자료로 충분한 경우가 많아요. 진짜 자료가 필요하면 기간을 정해서 주고, 끝나는 날 그 계정을 끄세요. 계약서에 "작업 종료 시 접근 회수" 한 줄을 넣는 것까지가 외주 맡기기의 기본이에요.

화면에서 숨기는 것은 권한이 아니에요

여기가 이 문서에서 가장 중요한 한 가지예요. AI에게 "알바에게는 매출 메뉴를 숨겨 줘"라고 하면 대개 버튼만 안 보이게 만들어요. 그런데 그 화면의 주소를 아는 사람은 주소창에 직접 쳐서 들어갈 수 있어요.

창고 문에 "관계자 외 출입 금지" 종이를 붙인 것과 문을 잠근 것은 다르죠. 종이는 읽는 사람에게만 통해요. 버튼을 숨기는 건 종이고, 서버에서 막는 것이 자물쇠예요. 손님 화면은 종이만 붙어 있어도 대부분 조용하지만, 돈과 명단이 있는 문은 반드시 자물쇠여야 해요.

막는 자리	무엇을 하나	이것만으로 충분한가
화면에서 메뉴 숨기기	권한 없는 사람에게 버튼을 안 보여줘요	아니에요. 보기 편하게 하는 장치일 뿐이에요
주소로 들어오면 돌려보내기	권한 없는 주소를 열면 로그인 화면으로 보내요	아직 아니에요. 화면을 안 거치고 데이터만 부르면 통과해요
서버에서 요청마다 확인하기	누가 보낸 요청인지 보고 자격이 없으면 거절해요	이것이 진짜 자물쇠예요. 나머지는 이걸 도와주는 장치예요
데이터 자체에 주인 표시	이 주문은 누구 것인지 표에 적어 두고 대조해요	함께 쓰면 가장 튼튼해요. 남의 주문 번호를 넣어 보는 시도를 막아요

그래서 AI에게 주문할 때 문장을 바꿔야 해요. "숨겨 줘"가 아니라 "서버에서 막아 줘"예요. 이 두 단어 차이가 실제로 만들어지는 코드를 바꿔요.

직접 해보기

역할 세 줄을 먼저 적어 보세요

코드보다 종이가 먼저예요. 알바가 볼 것 · 매니저가 볼 것 · 사장님만 볼 것, 이렇게 세 줄이면 시작해요. 그다음 스튜디오에서 만들고 있는 것에 이렇게 말해 보세요. "직원 계정에 역할을 두고, 매출과 손님 연락처는 사장 역할만 볼 수 있게 해 주세요. 화면에서 숨기는 것 말고 서버에서 막아 주세요." 마지막 문장이 핵심이에요.

스튜디오에서 말해 보기

확인해 보세요

알바 계정으로 로그인하면 매출 메뉴가 안 보이게 만들었어요. 지금 상태를 뭐라고 봐야 할까요?

헷갈리기 쉬운 것

Q. 로그인만 잘 만들면 권한은 따로 안 해도 되지 않나요?: 다른 일이에요. 로그인은 문 앞에서 신분을 보는 것이고, 권한은 안에서 어느 문이 열리는지예요. 로그인만 있으면 가입한 사람 전부가 같은 문을 다 열 수 있어요. 손님만 쓰는 서비스면 그래도 한동안 괜찮지만, 직원이 한 명이라도 생기면 그날부터 다른 이야기가 돼요.
Q. 직원이 두 명뿐인데 이게 필요한가요?: 필요한 기준은 사람 수가 아니라 돌이킬 수 없는 것이 화면에 있는가예요. 손님 연락처 전체 내려받기, 환불, 가격 변경, 정산 계좌. 이 넷 중 하나라도 관리자 화면에 있으면 두 명일 때 나누는 게 열 명일 때 나누는 것보다 훨씬 싸요.
Q. 역할을 몇 개나 만들어야 하나요?: 처음에는 둘이면 충분해요. 사장 역할과 직원 역할이에요. 역할을 다섯 개로 시작하면 누가 무슨 역할인지 아무도 기억을 못 해서 결국 전부 사장 역할이 돼요. 실제로 "이 사람은 이건 되고 저건 안 돼야 한다"는 상황이 생겼을 때 하나씩 늘리세요.
Q. 권한이 있으면 [[audit-log|기록]]은 따로 안 남겨도 되나요?: 짝으로 다녀요. 권한은 사고를 막는 쪽이고 기록은 사고가 난 뒤 밝히는 쪽이에요. 권한을 아무리 잘 나눠도 매니저가 자기 권한 안에서 환불을 잘못하면 막을 방법이 없어요. 그때 남는 게 기록이에요.
Q. 관리자 화면 주소를 아무도 모르게 해 두면 안전하지 않나요?: 주소를 감추는 건 잠그는 것이 아니에요. 주소는 브라우저 기록·즐겨찾기·화면 공유·문자에 남고, 한 번 새면 되돌릴 수 없어요. 감추는 건 보태는 장치로만 쓰고, 자물쇠는 서버 확인과 2단계 인증에 맡기세요.
Q. 사람이 그만두면 무엇부터 하나요?: 그 사람 계정을 끄는 게 먼저예요. 비밀번호를 바꾸는 게 아니라 계정 자체를 끄는 거예요. 그다음 그 사람이 알고 있던 공용 비밀번호와 API 키가 있으면 바꿔요. 순서를 반대로 하면 끄는 걸 잊어버려요.

하나 더

새로 온 알바에게 무엇부터 주는 게 맞을까요?

더 알아두면 좋은 것

장면 2 · 알바가 퇴근하면서 말했다

“주문 하나 잘못 눌러서 취소된 것 같은데, 되돌리는 버튼이 없네요.”

이 말은 권한 설계가 한 칸 틀렸다는 신호예요. 실수를 되돌릴 수 없는 일은 직원 역할에 두면 안 돼요. 두 가지 중 하나로 고쳐요. 취소를 사장 역할로 올리거나, 지웠지만 남겨두기로 바꿔서 되살릴 수 있게 만들어요. 되돌릴 수 있으면 권한을 넓게 줘도 되고, 되돌릴 수 없으면 좁혀야 해요. 이 한 문장이 역할을 가르는 기준이에요.

더 깊이 (안 읽어도 괜찮아요)

권한을 두 번 확인해야 하는 이유 · 화면과 서버가 각자 확인해요. 겹쳐 보이지만 하는 일이 달라요. 화면 쪽은 보기 좋게 하는 일이에요. 못 누를 버튼이 회색으로 남아 있으면 직원이 매번 눌러 보고 실패해요. 서버 쪽은 막는 일이에요. 화면을 거치지 않고 데이터를 직접 부르는 방법이 늘 있기 때문이에요. 그래서 둘 다 필요하고, 둘 중 하나만 남긴다면 남길 것은 서버 쪽이에요.

공용 계정이 특히 비싼 순간 · 손님 정보가 샜을 때예요. 이때는 언제·누가·무엇을 꺼냈는지 정리해서 알려야 하는 의무가 따라와요. 계정이 하나면 그 답을 만들 수가 없어요. 조사에 쓸 시간이 "기록이 없다"를 확인하는 데 다 들어가요. 개인정보와 손님 정보 다루기에서 이야기하는 준비의 절반은, 사실 사고 전에 계정을 나눠 두는 일이에요.

역할을 늘리기 전에 두는 중간 단계 · 역할을 새로 만들기 전에 기간을 정한 권한을 먼저 생각해 보세요. 세무 정리를 도와줄 사람에게 한 달만 매출 조회를 열어 주는 식이에요. 역할을 늘리면 그 역할은 영원히 남고, 몇 달 뒤에는 왜 만들었는지 아무도 기억하지 못해요. 기간이 붙은 권한은 스스로 사라지기 때문에 정리할 일이 안 쌓여요. 다만 끄는 날짜를 달력에 적어 두는 것까지가 이 방법이에요.

만들 때 미리 정해 두면 편한 세 칸 · 직원 표를 만들 때 칸 세 개를 같이 넣어 두면 나중이 훨씬 쉬워요. 역할, 계정 사용 여부, 마지막 접속 시각이에요. 역할이 있어야 권한을 붙이고, 사용 여부가 있어야 그만둔 사람을 지우지 않고 끌 수 있고, 마지막 접속이 있어야 몇 달째 안 쓰는 계정을 찾아낼 수 있어요. 나중에 칸을 더하는 것보다 처음에 비워 두는 편이 훨씬 싸요.

분기에 한 번, 명단만 훑어요

권한은 만들 때보다 정리를 안 해서 위험해져요. 석 달에 한 번 계정 목록을 열고 한 줄씩 물어보세요. "이 사람 아직 일하나요. 이 권한 아직 쓰나요." 대부분 5분이면 끝나고, 그만둔 사람 계정 하나를 찾는 것만으로 그날 값을 다 해요.

이것만 기억하세요

·로그인은 누구인지 확인하는 일이고, 권한은 무엇까지 할 수 있는지 정하는 일이에요
·권한은 사람이 아니라 역할에 붙여요. 처음에는 사장 역할과 직원 역할 둘이면 충분해요
·버튼을 숨기는 것은 잠그는 것이 아니에요. 돈과 명단이 있는 문은 서버에서 막아야 해요
·되돌릴 수 있는 일은 넓게, 되돌릴 수 없는 일은 좁게. 이것이 역할을 가르는 기준이에요
·사람이 그만두면 비밀번호를 바꾸는 게 아니라 그 계정을 끄는 것부터 해요