내부 도구용 권한 매트릭스 설계: 역할과 범위

권한 매트릭스가 해결하는 문제

내부 도구는 팀이 일상적으로 비즈니스를 운영할 때 사용하는 소프트웨어입니다. 관리자 패널, 운영 대시보드, 고객 지원 콘솔, 재무 검토 화면, 승인·데이터 수정·고객 대응을 돕는 작은 앱들이 여기에 포함됩니다.

이런 도구들은 민감한 데이터와 강력한 동작을 다룹니다. 지원 담당자는 고객 프로필을 봐야 하지만 전체 결제 정보를 보지 못해야 합니다. 재무 담당자는 세금계산서를 내보낼 수는 있지만 계정 설정을 바꾸면 안 됩니다. 운영 리드는 자신의 지역에서 두 가지를 모두 할 수 있을지 모릅니다.

내부 도구는 계층적으로 성장하면서 권한이 금방 복잡해집니다. 새 역할이 생기고 기존 역할이 나뉘며 일회성 예외가 늘어납니다: “Maria에게 환불 권한 허용”, “계약직은 노트 접근 차단”, “팀 리드는 최대 $500까지만 승인”. 규칙이 사람 머릿속(또는 흩어진 티켓)에만 있으면 화면과 API 엔드포인트가 일치하지 않게 되고, 보안 구멍이 생깁니다.

권한 매트릭스 설계는 누가 어떤 데이터에 어떤 조건으로 무엇을 할 수 있는지에 대한 단일 공유 지도를 만듭니다. 이 매트릭스는 UI 결정을 위한 진실의 근원(어떤 화면·버튼·필드를 보여줄지)이며 백엔드 결정(사용자가 UI를 우회하더라도 서버가 실제로 허용하는 것)의 근거가 됩니다.

이는 개발자 전용 문서가 아닙니다. 좋은 매트릭스는 제품, 운영, 개발자가 함께 합의할 수 있는 실무 문서입니다. AppMaster 같은 노코드 플랫폼으로 빌드할 때도 매트릭스는 필수적입니다. 역할을 설정하고, 리소스를 정의하며, 시각적 화면과 생성된 엔드포인트를 일치시키는 지침이 됩니다.

간단한 매트릭스는 다음을 돕습니다:

• 빌드 전에 규칙을 명확히 함
• 특수 사례로 인한 혼란 감소
• UI와 API 권한 정합성 유지
• 추후 액세스 변경을 추적 가능하게 함

핵심 용어: 역할(roles), 리소스(resources), 액션(actions), 범위(scopes), 예외(exceptions)

좋은 권한 매트릭스 설계는 공통된 용어에서 시작합니다. 팀이 이 용어들을 동일하게 사용하면 나중에 규칙이 복잡해지는 것을 피할 수 있습니다.

A role(역할) 은 보통 같은 접근이 필요한 사람들의 직무 기반 그룹입니다. Support, Finance, Ops, Manager 등이 예시입니다. 역할은 누군가의 직급보다는 일상 업무를 설명해야 합니다. 한 사람이 여러 역할을 가질 수 있지만 드물게 유지하세요.

A resource(리소스) 는 보호하려는 대상입니다. 내부 도구에서는 고객, 티켓, 세금계산서, 리포트, 통합, 설정 등이 흔한 리소스입니다. 리소스는 명사로 이름을 붙이세요. 이렇게 하면 규칙을 화면과 API 엔드포인트로 옮길 때 도움이 됩니다.

An action(액션) 은 리소스에 대해 누군가가 할 수 있는 동작입니다. 동사를 일관되게 유지하면 매트릭스가 읽기 쉬워집니다. 일반적인 액션은 다음과 같습니다:

• view
• create
• edit
• delete
• approve
• export

A scope(범위) 는 “어떤 레코드인가?”에 답합니다. 범위는 추가 역할을 만들지 않고 안전한 접근과 위험한 접근을 구분합니다. 흔한 범위는:

• own (본인이 생성했거나 할당된 레코드)
• team (소속 팀)
• region (지역)
• all (모든 것)

An exception(예외) 은 정상적인 역할·범위 규칙을 깨는 오버라이드입니다. 예외는 임시(교대 근무를 커버), 사용자별(특정 전문가가 하나의 추가 액션 필요), 레코드별(특정 VIP 고객 레코드 차단)일 수 있습니다. 예외는 통제된 부채로 취급하세요: 누가 승인했는지, 왜 필요한지, 언제 만료되는지 기록하십시오.

예시: Support 담당자는 범위 "team"으로 "티켓 보기" 권한은 있지만, 한 사건 조사 때문에 단기간 "티켓 내보내기" 예외를 받을 수 있습니다. AppMaster로 만든 도구에서는 역할·리소스·액션·범위를 처음부터 일관되게 이름 지으면 이런 규칙을 유지하기가 훨씬 쉬워집니다.

매트릭스를 그리기 전에 내려야 할 결정들

먼저 무엇을 보호하는지 합의하세요. 내부 도구의 영역을 화면이 아니라 리소스로 나열하세요. 하나의 화면에 "주문(Orders)", "환불(Refunds)", "고객(Customers)"이 같이 보여도, 각 항목은 서로 다른 리소스이며 위험도가 다릅니다.

권한을 쓰기 전에 액션 동사 표준을 정하세요. 작은 단어 차이가 나중에 중복 규칙을 만듭니다(예: edit vs update, remove vs delete, view vs read). 짧고 공통된 집합을 골라 모든 리소스에 일관되게 사용하세요. 대부분의 내부 도구에는 view, create, update, delete, approve, export 같은 간단한 집합이 충분합니다.

범위는 회사의 구조와 맞아야 합니다. 너무 많은 범위는 매트릭스를 읽기 어렵게 하고, 너무 적으면 예외가 늘어납니다. 조직 구조에 맞는 작은 집합을 목표로 하세요. 예:

• own (본인이 생성한 레코드)
• team (팀 레코드)
• location (지점 또는 지역)
• all (모든 레코드)
• none (접근 불가)

또한 "없음(no)"에 대한 명확한 규칙을 결정하세요. 명시적으로 금지할 것인지, 암묵적으로 거부할 것인지 정해야 합니다. 명시적 허가 외에는 거부(implicit deny)는 더 안전하고 단순합니다. 반면 광범위한 접근이 필요한 상황에서는 특정 액션을 명시적으로 금지(explicit forbid)하는 것이 유용합니다(예: "Finance는 모든 세금계산서에 접근하지만 삭제는 금지").

마지막으로 컴플라이언스 민감 액션을 초기에 표시하세요. 내보내기, 삭제, 지급, 역할 변경, 개인 데이터 접근 등은 추가 검토·로깅·승인 절차가 필요합니다. 예를 들어 지원 리더는 고객 프로필을 업데이트할 수 있지만, 지급(payout) 생성이나 내보내기(export)는 재무 승인 후에만 가능하도록 할 수 있습니다.

AppMaster로 빌드하면 이러한 결정은 이후 백엔드 엔드포인트와 Business Process 로직에 깔끔하게 매핑되지만, 먼저 매트릭스가 명확해야 합니다.

단계별: 권한 매트릭스를 처음부터 만드는 방법

사람들이 하는 일(업무)에서 시작하세요. 화면으로 시작하면 오늘의 UI를 복제하게 되고 실제 규칙(예: 누가 환불을 승인할 수 있는지, 또는 락된 고객 레코드를 누가 편집할 수 있는지)을 놓치게 됩니다.

권한 매트릭스 설계는 작업을 접근으로 매핑한 지도처럼 다루고, 그 후 앱으로 전환하는 방식이 실용적입니다.

실무적 구축 순서

1. 업무를 평이한 언어로 나열하세요. 예: "환불 처리하기", "고객 이메일 변경", "지난달 세금계산서 내보내기". 짧고 현실적으로 적으세요.

2. 업무를 리소스와 액션으로 바꾸세요. 리소스는 명사(Invoice, Ticket, Customer), 액션은 동사(view, create, edit, approve, export). 각 리소스에 대한 오너(예외와 경계 사례를 설명할 수 있는 담당자)를 지정하세요.

3. 안정적인 팀을 기반으로 역할을 정의하세요. Support, Finance, Operations, Team Lead 같은 그룹을 사용하세요. 직급(Senior, Junior)처럼 자주 바뀌는 이름은 가능한 피하세요.

4. 각 역할이 업무를 완료하는 데 필요한 최소 접근을 매트릭스에 기입하세요. 예를 들어 Support는 질문 응대를 위해 세금계산서만 볼 필요가 있다면 기본적으로 "export" 권한을 주지 마세요. 권한을 추가하는 건 나중에 가능하지만, 제거하면 습관이 깨질 수 있습니다.

5. 범위는 필요한 곳에만 추가하세요. 단일 "edit" 권한 대신 "edit own", "edit assigned", "edit all" 같은 범위를 명시하면 50개의 역할을 만들지 않고도 규칙을 명확히 할 수 있습니다.

예외는 매트릭스와 분리된 테이블에 기록하세요. 각 예외에는 명확한 이유(컴플라이언스, 사기 위험, 직무 분리)와 승인 담당자가 필요하며 만료일을 두세요.

이 작업이 끝나면 AppMaster 같은 도구로 매트릭스를 보호된 엔드포인트와 관리자 화면으로 전환하기가 훨씬 쉬워집니다.

매트릭스를 읽기 쉽게 구조화하는 방법

매트릭스는 사람들이 빠르게 읽을 수 있을 때만 유용합니다. 셀로 가득한 거대한 표가 되면 팀은 사용을 중단하고 권한은 원래 의도에서 벗어납니다.

먼저 도메인별로 매트릭스를 분리하세요. 모든 것을 한 시트에 넣지 말고 Customers, Billing, Content처럼 비즈니스 영역별로 탭을 나누세요. 대부분의 역할은 몇몇 도메인만 다루므로 검토가 빨라지고 실수로 변경할 가능성이 줄어듭니다.

탭 전반에 걸쳐 일관된 명명 패턴을 사용하세요. Resource.Action.Scope 같은 단순한 형식은 각 권한이 무엇을 의미하는지 한눈에 알 수 있게 하고, 같은 의미인데도 서로 다르게 보이는 중복을 방지합니다. 예: Invoice.Approve.Department는 Customer.Edit.Own처럼 읽힙니다.

엣지 케이스가 생기면 새 역할을 만들고 싶은 유혹을 참으세요. 셀 옆에 짧은 메모로 예외와 적용 시점을 적으세요. 예: Support는 고객 확인 후에만 세금계산서를 볼 수 있다. 메모는 필요하다면 추가 UI 단계를 가리킬 수 있고, 역할 모델을 바꾸지 않습니다.

고위험 권한은 리뷰 시 눈에 띄게 표시하세요. 환불, 승인, 내보내기, 데이터 삭제 같은 액션이 여기에 해당합니다. 셀을 표시하고 필요한 추가 확인 절차(예: 2인 승인, 매니저 확인)를 적어 두세요.

매트릭스를 유지보수 가능하게 하려면 다음을 버전 관리하세요:

• v1, v2 등과 날짜
• 오너(한 명의 책임자)
• 간단한 변경 요약
• 변경을 촉발한 이유(새 워크플로우, 감사 결과 등)

매트릭스가 안정되면 AppMaster에서 화면과 엔드포인트를 빌드하기가 훨씬 쉽습니다. 모든 버튼과 API 액션이 명확한 권한 이름에 매핑되기 때문입니다.

매트릭스를 화면과 엔드포인트로 전환하기

권한 매트릭스는 API와 UI 두 곳에서 실제 규칙이 될 때만 유용합니다. 매트릭스의 각 리소스(예: Tickets, Invoices, Users)를 엔드포인트 그룹으로 다루세요. 액션은 매트릭스의 동사와 일치하게 유지합니다: view, create, edit, approve, export, delete.

API 측면에서는 모든 요청에서 권한을 강제하세요. UI 검사만으로는 보안이 되지 않습니다. 숨겨진 버튼은 직접 API 호출을 막지 못합니다.

매트릭스를 API 권한으로 번역하는 간단한 방법은 권한 이름을 일관되게 지정하고 액션이 발생하는 경계(boundary)에 부착하는 것입니다:

• tickets:view, tickets:edit, tickets:export
• invoices:view, invoices:approve, invoices:delete
• users:view, users:invite

그런 다음 동일한 권한 이름을 UI 게이트(메뉴 항목, 페이지 접근, 버튼, 필드)에도 사용하세요. 예: Support 담당자는 티켓 목록을 보고 티켓을 열 수 있지만, invoices:approve 권한이 없으면 "환불" 필드는 읽기 전용으로 표시됩니다.

목록(list)과 상세(detail) 접근을 구분하는 데 주의하세요. 팀은 어떤 항목이 존재한다는 것만 알아야 하고 레코드 자체는 보지 못해야 할 수 있습니다. 이 경우 제한된 컬럼으로 목록 결과를 허용하고, 상세 보기는 별도의 권한 또는 "본인 할당(assigned to me)" 같은 범위 체크를 요구하세요. 미리 결정하지 않으면 목록 화면에서 민감한 데이터가 유출될 수 있습니다.

마지막으로 감사 로깅(audit logging)을 중요한 액션에 매핑하세요. 내보내기, 삭제, 승인, 역할 변경, 데이터 다운로드는 누가, 무엇을, 언제, 어떤 대상에 대해 했는지 기록해야 합니다. AppMaster로 빌드한다면 엔드포인트 로직과 Business Process 흐름에서 같은 규칙이 액션과 감사 항목을 동시에 트리거하도록 반영할 수 있습니다.

흔한 실수와 함정

권한 매트릭스를 망치는 가장 빠른 방법은 UI를 모델링하는 것입니다. 하나의 화면에 여러 항목이 표시될 수 있고 같은 항목이 여러 화면에 나타날 수 있습니다. 화면마다 별도의 리소스로 모델링하면 규칙이 중복되고 엣지 케이스를 놓치며 명명 규칙에 대해 논쟁만 하게 됩니다.

또 다른 흔한 함정은 역할 확산(role sprawl)입니다. 팀은 계속 역할을 추가합니다(예: Support Level 1, Support Level 2, Support Manager 등). 더 작은 역할 집합과 명확한 범위가 있으면 대부분의 경우 문제를 해결할 수 있습니다. "own team", "assigned region", "accounts you manage" 같은 범위가 새 역할보다 차이를 더 잘 설명합니다.

실제 내부 도구에서 자주 보이는 몇 가지 실수:

• "view"와 "edit"만 정의하고 export, bulk edit, refund, impersonate, "change owner" 같은 액션을 잊음.
• 예외를 장기 패치로 사용함(예: "Sam에게 1주일 동안 Finance 접근 부여"). 일회성 권한이 영구화되기 쉽습니다.
• UI에서 버튼을 숨기고 시스템이 안전하다고 가정함. API는 여전히 요청을 거부해야 합니다.
• 누군가의 범위가 바뀔 때(팀 이동, 지역 변경) 어떻게 처리할지 결정하지 않음. 권한은 예측 가능하게 업데이트되어야 합니다.
• "admin"을 무제한으로 취급함. 관리자도 종종 분리가 필요합니다(예: "사용자 관리 가능"하지만 "지급 승인 불가").

예외는 특별히 주의해야 합니다. 임시 상황에 유용하지만 만료되거나 검토되어야 합니다. 예외가 계속 늘면 역할이나 범위 매핑이 깔끔하지 않다는 신호입니다.

간단한 예: 지원(Support)과 재무(Finance) 도구에서 Support는 고객 프로필을 보고 티켓을 만들 수 있고, Finance는 세금계산서를 내보내고 환불을 처리할 수 있습니다. 페이지 보안만 하면 Support 담당자가 직접 export 엔드포인트를 호출해 버릴 수 있습니다. 커스텀 코드로 빌드하든 AppMaster 같은 플랫폼으로 백엔드를 생성하든, 규칙은 UI뿐 아니라 서버 측에 존재해야 합니다.

빌드하기 전에 빠르게 점검할 체크리스트

권한 매트릭스는 명확하고 집행 가능한 규칙으로 전환될 때만 유용합니다. 첫 화면이나 엔드포인트를 만들기 전에 아래 체크리스트를 확인하세요. 이렇게 하면 새 역할이나 엣지 케이스가 나타날 때 깨지는 "거의 안전한(Almost secure)" 설정을 피할 수 있습니다.

규칙을 먼저 만들고, UI를 만드세요

기본적으로는 "기본 거부(default deny)" 태도를 적용하세요: 명시적으로 허용되지 않은 것은 모두 차단합니다. 이것이 안전한 기본값이며, 새 기능을 추가할 때 의외의 접근을 방지합니다.

권한의 단일 진실 소스(싱글 소스 오브 트루스)를 확보하세요. 문서, 데이터베이스 테이블, 노코드 설정 등 어디에 있든 팀 모두가 현재 규칙이 어디에 있는지 알아야 합니다. 스프레드시트와 앱이 서로 다르면 버그가 발생합니다.

간단한 사전 빌드 체크리스트:

• 기본 거부가 모든 곳에서 적용됨(UI 버튼, API 엔드포인트, 내보내기, 백그라운드 작업 포함).
• 각 액션에 명확한 범위 정의(own, team, region, all, 혹은 명명된 하위 집합).
• 관리자 권한은 비즈니스 액션과 분리됨(역할 관리는 환불 승인과 같지 않음).
• 민감한 액션은 더 강한 제어(승인 단계, 로깅, 이상 활동 알림 등)를 요구함.
• 예외는 오너와 만료일을 가짐(임시 접근이 영구화되지 않도록).

그다음 현실적인 한 시나리오로 규칙을 점검하세요. 예: "Support 담당자는 주문을 보고 해당 지역에 메모를 추가할 수는 있지만 가격을 수정하거나 환불을 발행할 수는 없다. Finance는 환불을 발행할 수 있지만 매니저 승인 후에만 가능하고 모든 환불은 로깅된다." 한두 문장으로 설명할 수 없다면 범위와 예외가 아직 명확하지 않은 것입니다.

AppMaster로 빌드한다면 이 항목들을 화면과 비즈니스 로직의 요구사항으로 다루세요. 버튼으로 동작을 숨길 수 있지만 진짜 강제는 백엔드 규칙입니다.

예시 시나리오: Support와 Finance를 위한 내부 도구

중간 규모 회사가 Support와 Finance가 사용하는 내부 도구를 하나 운영한다고 가정하세요. 동일한 데이터베이스에 Customers, Tickets, Refunds, Payouts, Settings(템플릿·통합 등)가 있습니다. 단순 로그인 확인으로는 부족한 유형의 앱입니다.

초기에 다음 역할을 정했습니다:

• Support Agent: 한 큐(queue)에서 티켓 처리
• Support Lead: 여러 큐를 돕고 특정 액션 승인 가능
• Finance: 금전 관련 업무 담당
• Ops Admin: 접근 제어 및 시스템 설정 담당

실용적인 권한 매트릭스는 리소스별 액션을 작성하고 범위로 세분화하는 것으로 시작합니다.

티켓의 경우 Support Agent는 자신에게 할당된 큐의 티켓만 조회·업데이트할 수 있습니다. 메모를 추가할 수 있지만 티켓 소유자는 변경할 수 없습니다. Support Lead는 Support Agent의 모든 권한에 더해 같은 지역 내에서 티켓 재할당이 가능합니다.

환불의 경우 Finance는 환불 생성과 승인 권한을 가지되 일정 금액 한도가 있을 수 있습니다. Support는 환불 요청을 생성할 수 있지만 승인할 수는 없습니다. 환불 승인(approve)은 생성(create)과 별개의 액션으로 매트릭스에 명시되어 우연히 권한이 부여되지 않도록 합니다.

Payouts와 Settings는 엄격하게 관리됩니다: Payouts는 Finance만 조회 가능하고 Settings는 Ops Admin만 변경할 수 있습니다. Support는 이러한 화면을 보지 못하게 하여 유혹과 실수를 줄입니다.

예외 규칙을 하나 추가해보세요: Support Lead가 2주 동안 다른 지역을 커버합니다. Ops Admin 같은 광범위한 역할을 주는 대신 매트릭스에 임시 범위 확장(예: Support Lead + Region B, 만료 날짜 기재)을 추가하세요. 이 한 가지 예외가 역할 복제보다 안전합니다.

AppMaster로 빌드하면 같은 매트릭스가 UI에 표시되는 페이지와 백엔드가 허용하는 동작을 안내하므로 누군가가 Payouts나 Settings의 엔드포인트를 추측해도 접근할 수 없습니다.

권한을 테스트하고 시간 경과에 따라 유지하는 방법

권한 문제는 보통 사소하고 지루한 방식으로 발생합니다: 한 화면이 버튼을 숨기지 않거나, 한 엔드포인트가 체크를 빠뜨리거나, 범위 규칙이 너무 넓게 매칭되는 식입니다. 매트릭스를 반복 가능한 테스트와 간단한 유지보수 루틴으로 전환하면 훨씬 더 유용해집니다.

작은 테스트 사용자 집합으로 시작하세요. 여러 계정이 필요하지 않습니다. 역할별로 한 명씩, 그리고 일반적인 예외용 엣지 사용자(예: "환불 승인 권한이 있는 Support 담당자")를 만드세요. 이 계정들을 스프린트마다 재사용하세요.

그다음 매트릭스를 테스트 케이스로 바꾸세요. 각 규칙에 대해 허용 경로와 거부 경로를 하나씩 작성하세요. 거부 경로는 구체적으로 무엇이 일어나야 하는지(명확한 메시지, 데이터 변경 없음 등)를 적어 두세요.

• Role: Support Agent. Action: Refund. Expected: 거부(명확한 메시지, 데이터 변경 없음).
• Role: Finance. Action: Refund. Expected: 허용, 환불 레코드 생성, 행위자와 사유 로깅.
• Role: Manager. Action: View tickets. Scope: team only. Expected: 팀 티켓 조회 허용, 다른 팀 티켓 열람 불가.

동일한 규칙을 UI와 API 두 번 테스트하세요. UI가 차단하지만 API가 허용하면 사용자가 화면을 우회할 수 있습니다. AppMaster를 사용한다면 UI 로직과 백엔드 엔드포인트가 모두 규칙을 강제하는지 확인하세요.

범위는 실제 데이터를 사용해 테스트해야 합니다. 소유권, 팀, 지역별로 다른 테스트 레코드를 만들어 ID를 추측해 접근할 수 없는지 검증하세요.

마지막으로 민감한 액션(환불, 내보내기, 역할 변경)에 대해 무엇을 로깅할지 결정하세요. 누가, 무엇을, 언제, 어디서 했는지 기록하고, 로그를 정기적으로 검토하며 권한 편집이나 대량 내보내기 같은 드문 액션은 알림 규칙을 추가하세요.

다음 단계: 매트릭스에서 실제 내부 도구로 이동하기

권한 매트릭스를 문서에 묻어두지 말고 빌드 플랜으로 취급하세요. 가치 실현을 빠르게 하려면 데이터와 프로세스 오너들과 기본 사항을 확인하세요.

30분 정도의 짧은 워크숍(각 역할 대표 한 사람과 리소스 오너들)을 열고 역할·리소스·액션·범위를 검토하며 특별 사례를 적어보세요. 예외가 빈번하게 들리면 누락된 범위일 수 있습니다.

그다음 v1 매트릭스를 초안으로 만들고 리소스 오너와 함께 집중 리뷰를 하세요. 실용적으로 접근하세요: "Support가 세금계산서를 볼 수 있나?", "Finance가 고객 정보를 수정할 수 있나?" 누군가 주저하면 우선 평이한 문장으로 규칙을 적으세요. 나중에 형식화하면 됩니다.

v1 합의 후에는 한 도메인을 엔드투엔드로 먼저 빌드하세요. 데이터·로직·UI를 모두 건드리는 얇은 슬라이스(예: 티켓 시스템, 또는 세금계산서 승인)를 선택하세요. 누가 볼 수 있고, 누가 변경할 수 있으며, 시도할 때 무슨 일이 일어나는지 답할 수 있어야 합니다.

AppMaster를 사용한다면 매트릭스를 제품 요소에 매핑한 뒤에 생성하세요:

• Data Designer: 리소스를 엔티티(테이블)와 범위에 영향을 주는 주요 필드(team_id, region_id 등)와 정렬
• Business Processes: 변경이 일어나는 지점에서 규칙 강제(create, update, approve, export)
• UI 가시성 규칙: 사용자에게 할 수 없는 동작은 숨기고, 접근 거부 시 이유를 명확히 표시
• Endpoints: 각 역할에 필요한 것만 노출하고 관리자 전용 작업은 분리

간단한 예: 두 역할(Support 생성, Finance 승인)로 구성된 "환불 요청" 흐름을 만드세요. 그 흐름이 깔끔하게 작동하면 "Support는 30분 내에만 취소 가능" 같은 엣지 케이스를 추가하세요.

작은 내부 도구를 AppMaster로 만들어 역할과 흐름을 조기에 검증하고, 그 후 매트릭스에서 반복하세요. 목표는 화면이 20개가 되고 권한 수정이 쌓이기 전에 오해를 잡아내는 것입니다.