권한 설계 실패가 브랜드 데이터를 망친다

시즌 마감 재고 실사를 돌렸는데, 숫자가 맞지 않습니다. 창고 담당자는 "저는 건드린 게 없다"고 하고, 영업팀은 "저도 모르겠다"고 합니다. 시스템 로그를 뒤져보면 누군가 입고 수량을 수정한 흔적이 있는데, 누가 언제 왜 바꿨는지 추적이 안 됩니다. 이 상황, 낯설지 않으시죠?

많은 패션 브랜드가 ERP나 재고 시스템을 도입할 때 기능 구현에 집중합니다. 발주가 되는지, 입출고가 잡히는지, 매출이 집계되는지. 그런데 정작 "누가 어디까지 볼 수 있고, 무엇을 바꿀 수 있는가"—즉 권한 설계는 마지막에 대충 처리하거나, 아예 건너뜁니다. 그 결과는 데이터 오염, 보안 사고, 그리고 의사결정 실패로 돌아옵니다.

권한 설계 실패가 만드는 실제 피해

데이터가 조용히 망가진다

권한이 제대로 설계되지 않은 시스템에서 가장 먼저 나타나는 증상은 데이터 신뢰성 붕괴입니다. 누구나 수정할 수 있으면, 아무도 책임지지 않습니다.

예를 들어볼까요. 매장 수가 15개인 브랜드에서 영업팀 직원이 실수로 특정 SKU의 재고를 200개에서 20개로 수정했습니다. 창고는 여전히 200개를 보유하고 있는데, 시스템상 재고는 20개입니다. 본사 MD는 재고 부족으로 판단해 긴급 추가 생산을 지시합니다. 그 생산 비용이 최소 1,500만 원. 나중에 실사를 해보니 창고에 재고가 넘쳤습니다. 이런 사고가 분기에 한 번씩 반복된다면, 연간 손실은 쉽게 5,000만 원을 넘습니다.

민감한 정보가 전사에 열린다

패션 브랜드에서 민감한 데이터는 생각보다 많습니다. 원가 정보, 거래처별 매입 단가, 인플루언서 계약 조건, 시즌 신상품 출시 일정. 이 정보들이 권한 구분 없이 전 직원에게 열려 있는 경우를 저희는 실제로 자주 목격합니다.

특히 문제가 되는 건 퇴사자 계정 관리입니다. 직원이 퇴사했는데 계정이 살아있는 경우, 또는 협력업체 직원에게 임시로 준 접근 권한을 회수하지 않은 경우. 중소 패션 브랜드에서 IT 전담 인력이 없다면 이런 관리는 사실상 방치 상태가 됩니다.

감사 추적이 불가능해진다

세 번째 문제는 사고가 났을 때 원인을 찾을 수 없다는 겁니다. 누가 언제 무엇을 바꿨는지 기록이 없으면, 재발 방지도 책임 소재 파악도 불가능합니다. 감사 로그 없는 시스템은 사고 이후에도 같은 사고를 반복합니다.

패션 브랜드에 맞는 권한 설계 원칙

권한 설계는 개발자의 영역이 아닙니다. 오히려 운영 책임자가 먼저 그림을 그려야 개발자가 제대로 구현할 수 있습니다. 다음 세 가지 원칙을 기준으로 생각해보세요.

원칙 1: 역할 기반으로 설계한다 (Role-Based)

사람 단위로 권한을 주면 관리가 불가능해집니다. 직원이 바뀔 때마다 권한을 새로 설정해야 하고, 누락이 생깁니다. 대신 역할(Role) 단위로 권한을 묶어야 합니다.

패션 브랜드 기준으로 역할을 나눠보면 이렇습니다:

• MD/기획팀: 상품 등록, 원가 열람, 발주 승인 가능 / 재고 수량 직접 수정 불가
• 물류·창고팀: 입출고 처리 가능 / 원가·매입단가 열람 불가
• 영업·매장팀: 자기 매장 재고·매출 열람 가능 / 타 매장 데이터 열람 불가
• 경영진: 전체 열람 가능 / 직접 수정은 제한 (수정은 담당자가)
• 외부 협력사: 지정된 거래 데이터만 열람, 수정 권한 없음

이 구조를 먼저 문서로 정의하고, 개발팀에 전달해야 합니다. 시스템이 먼저 만들어지고 나중에 권한을 끼워 맞추려 하면, 구조 자체를 뜯어고쳐야 하는 상황이 생깁니다.

원칙 2: 최소 권한 원칙을 지킨다

"일단 다 열어두고 나중에 막자"는 접근은 틀렸습니다. 처음부터 업무에 필요한 최소한의 권한만 부여하고, 필요할 때 추가하는 방식이 맞습니다.

실무에서 흔히 보는 실수가 있습니다. 신규 입사자에게 "일단 편하게 쓰라고" 관리자 권한을 주는 것. 또는 특정 기능을 테스트하려고 임시로 높은 권한을 준 뒤 회수하지 않는 것. 이런 관행이 쌓이면 시스템 전체의 권한 체계가 무너집니다.

원칙 3: 모든 변경에 로그를 남긴다

권한 설계의 완성은 감사 추적(Audit Trail)입니다. 누가, 언제, 어떤 데이터를, 어떻게 바꿨는지 자동으로 기록되어야 합니다. 이 로그는 사고 수습뿐 아니라 일상적인 데이터 품질 관리에도 필수입니다.

로그가 있으면 "이 재고 수치가 왜 이상하지?"라는 질문에 5분 안에 답할 수 있습니다. 로그가 없으면 전 직원을 불러 모아 회의를 해도 답이 안 나옵니다.

시스템 구축 전에 반드시 물어야 할 질문들

새 시스템을 도입하거나 기존 시스템을 개편할 때, 개발사 또는 내부 담당자에게 다음을 반드시 확인하세요.

"역할별 권한을 어떻게 설정하나요?"

역할 기반 권한 관리(RBAC)가 지원되는지, 역할을 몇 단계까지 세분화할 수 있는지 확인하세요. "그냥 관리자/일반 사용자 두 단계"만 있는 시스템은 패션 브랜드 운영에 적합하지 않습니다.

"데이터 수정 이력이 자동으로 기록되나요?"

로그가 저장되는지, 얼마나 보관되는지, 누가 열람할 수 있는지 확인하세요. 로그가 없다면 감사 추적이 불가능합니다.

"퇴사자 계정은 어떻게 처리되나요?"

계정 비활성화 프로세스가 있는지, HR 시스템과 연동되는지 확인하세요. 수동으로 처리해야 한다면 반드시 담당자와 프로세스를 명문화해야 합니다.

"매장별, 거래처별로 데이터 접근 범위를 분리할 수 있나요?"

전국 매장을 운영하는 브랜드라면 특정 매장 담당자가 타 매장 데이터를 볼 수 없어야 합니다. 이 기능이 없으면 데이터 유출 리스크가 상시 존재합니다.

권한 설계는 운영 철학이다

권한 설계를 "IT 보안 설정"으로만 보면 놓치는 게 있습니다. 사실 권한 설계는 조직이 데이터를 어떻게 다루는가에 대한 운영 철학입니다.

누가 어떤 정보를 볼 수 있는지, 누가 무엇을 바꿀 수 있는지, 그 변경이 어떻게 기록되는지. 이 구조가 명확한 브랜드는 데이터를 신뢰하고 빠르게 의사결정합니다. 이 구조가 없는 브랜드는 데이터가 있어도 믿지 못해서, 결국 경험과 감에 의존합니다.

연매출 50억 원 규모의 브랜드가 잘못된 재고 데이터 때문에 연간 5,000만 원 이상을 낭비한다면, 그건 시스템 문제가 아니라 설계 문제입니다. 그리고 설계는 처음부터 제대로 해야 나중에 고치는 비용이 없습니다.

시스템을 새로 만들든, 기존 것을 고치든—권한 설계를 마지막 항목이 아니라 첫 번째 의제로 올리는 것. 그게 데이터를 자산으로 만드는 시작점입니다.

권한 설계가 제대로 된 시스템은 기능이 아니라 신뢰를 파는 것—지금 운영 중인 시스템의 권한 구조가 걱정된다면, 진단부터 시작해보세요. → 문의하기