지라 프로젝트 권한 설정하는 법은 사용자에게 권한을 하나씩 주는 방식보다 그룹과 프로젝트 역할을 먼저 만들고 연결하는 방식이 안전하다. 팀원별 접근 범위는 프로젝트 접근 권한과 이슈 열람 범위를 분리해서 설계해야 한다. 이 구조를 잡지 않으면 퇴사자 계정 정리나 외부 협업자 권한 회수가 매번 수작업이 된다.
핵심은 세 층이다. 전사 단위의 그룹으로 계정 묶음을 관리하고, 프로젝트 역할로 업무 책임을 나누며, 민감 이슈만 이슈 보안 수준으로 한 번 더 잠근다. 짧게 말하면 그룹은 소속, 역할은 행동, 보안 수준은 열람 대상이다.
지라 프로젝트 권한 설정하는 법의 구조
지라에서는 프로젝트에 들어올 수 있는 사람과 이슈를 수정할 수 있는 사람, 설정을 바꿀 수 있는 사람이 같을 필요가 없다. 오히려 같지 않아야 한다. 예를 들어 개발자는 이슈 생성과 상태 변경이 필요하지만 워크플로우나 권한 체계 변경까지 맡을 이유는 없다.
관리 화면 이름은 Jira Cloud와 Data Center, 회사에서 쓰는 프로젝트 유형에 따라 조금씩 다르다. 보통 프로젝트 설정에서 사람 또는 액세스 메뉴를 열어 역할을 배정하고, 권한 구성표에서는 역할이나 그룹별 세부 행동을 연결한다. 이미 여러 프로젝트가 같은 권한 체계를 공유한다면 수정 범위를 먼저 확인해야 한다. 공용 권한 구성표 하나를 바꾸면 관계없는 프로젝트까지 함께 영향을 받을 수 있기 때문이다.
| 구분 | 무엇을 정하나 | 활용 예시 |
|---|---|---|
| 그룹 | 조직상 소속 | 개발팀, 운영팀, 외부협력사 |
| 프로젝트 역할 | 프로젝트 내 책임과 행동 | 관리자, 담당자, 열람자 |
| 권한 구성표 | 생성·수정·댓글·삭제 같은 행위 | 담당자만 이슈 전환 허용 |
| 이슈 보안 수준 | 특정 이슈의 열람 대상 | 인사·사고 대응 이슈 제한 |
프로젝트 관리자 권한은 가장 좁게 둔다. 이 권한을 가진 사람은 구성원 관리나 일부 프로젝트 설정을 바꿀 여지가 있어서 업무상 필요한 책임자에게만 배정하는 편이 낫다. 운영 편의를 이유로 전원에게 관리자 역할을 주면 나중에 변경 이력을 읽기도 어려워진다.
팀원별 접근 범위를 설계하는 순서
- 업무 인원을 네 부류로 적는다. 프로젝트 관리자, 실행 담당자, 협업 참여자, 열람 전용 사용자 정도면 시작하기 좋다. 직급이 아니라 실제 업무 행동을 기준으로 나눈다.
- 역할별 허용 행동을 정한다. 이슈 보기, 생성, 수정, 할당, 상태 전환, 댓글, 첨부파일 추가, 삭제, 내보내기를 따로 확인한다. 삭제와 권한 변경은 별도 통제로 남긴다.
- 그룹을 만든 뒤 역할에 연결한다. 예를 들어 개발팀 그룹을 프로젝트의 담당자 역할에 넣고, 협력사 그룹은 열람자 역할에 넣는다. 사람 한 명이 이동해도 그룹만 옮기면 된다.
- 예외 이슈를 선별한다. 장애 원인, 고객 계약, 인사 정보, 보안 사고처럼 제한이 필요한 항목은 이슈 보안 수준을 쓴다. 프로젝트 전체를 막아 업무를 멈추게 하기보다 필요한 이슈만 잠그는 방식이다.
- 테스트 계정으로 검증한다. 각 역할을 대표하는 테스트 계정으로 로그인해 이슈 검색, 열람, 생성, 전환, 댓글, 첨부파일 다운로드까지 확인한다. 설정 화면에서 보이는 권한과 실제 사용자 화면은 다를 때가 있다.
여기서 흔한 실수는 권한 구성표에 개별 사용자 계정을 직접 계속 추가하는 일이다. 처음에는 빠르다. 인원이 늘면 누가 왜 접근하는지 설명하기 어렵고, 프로젝트 이동이나 계약 종료 때 계정이 남는다. 예외가 생겨도 먼저 기존 역할로 처리할 수 있는지 확인하고 정말 필요한 경우에만 별도 그룹을 만든다.
권한 항목은 이 순서로 확인한다
열람 권한부터 본다. 이슈 보기 권한이 넓으면 댓글, 설명, 첨부파일, 이슈 링크에 담긴 내부 정보도 함께 노출될 수 있다. 다음은 생성과 수정이다. 외부 협업자가 요청 등록은 해야 하지만 본문 변경은 하면 안 되는 상황도 많다. 상태 전환과 할당 권한은 업무 흐름을 바꾸므로 담당 역할로 제한하는 편이 관리하기 쉽다.
삭제, 일괄 변경, 내보내기 권한은 한 단계 더 보수적으로 검토한다. 특히 CSV 내보내기는 검색 결과에 포함된 이슈 정보를 한꺼번에 가져갈 수 있으므로 조직의 데이터 반출 기준과 맞춰 볼 필요가 있다. 민감한 첨부파일을 다루는 프로젝트라면 첨부 권한만이 아니라 이슈 열람 권한, 외부 공유 방식, 보존 정책까지 함께 점검해야 한다.
프로젝트 역할 예시는 단순하게 시작하면 된다. 관리자에게는 구성 관리와 이슈 관리 권한을, 담당자에게는 생성·수정·전환·댓글 권한을, 참여자에게는 생성·댓글·열람 권한을, 열람자에게는 보기 권한만 준다. 실제 워크플로우에서 승인자가 상태를 바꿔야 한다면 승인자 역할을 별도로 두는 편이 담당자 권한을 불필요하게 넓히는 것보다 낫다.
운영 중 권한이 무너지지 않게 하는 방법
권한 검토 주기를 정해 둔다. 분기마다 한 번 또는 프로젝트 단계가 바뀔 때 구성원 목록과 역할을 대조하면 충분한 경우가 많다. 최소한 외부 협업 종료, 부서 이동, 퇴사 처리 시점에는 그룹과 프로젝트 역할을 함께 회수하는 절차를 둔다.
요청 기록도 남긴다. 누가 언제 어떤 업무 때문에 어느 역할을 요청했고, 누가 승인했는지 티켓이나 내부 기록으로 남기면 나중에 예외 권한의 이유를 확인하기 쉽다. 권한 부여와 검토를 한 사람이 모두 처리하지 않도록 업무를 나누면 실수를 줄이는 데 도움이 된다.
설정을 바꾸기 전에는 현재 권한 구성표 이름과 연결된 프로젝트 목록을 기록한다. 테스트 프로젝트나 제한된 그룹에서 먼저 적용한 뒤 운영 프로젝트에 반영한다. 되돌릴 기준도 준비한다. 변경 전 화면 캡처나 설정 내보내기 기능을 활용해 복구 단서를 남겨 두면 긴급 상황에서 판단이 빨라진다.
FAQ
팀원 한 명에게만 예외 권한을 줘도 되나?
가능한 환경도 있지만 반복되는 예외라면 개인 계정 직접 부여보다 목적이 드러나는 별도 그룹을 만드는 편이 낫다. 단기 지원처럼 종료일이 분명한 예외는 요청 사유와 회수 날짜를 기록하고, 종료 시점에 제거 여부를 확인한다.
프로젝트 역할과 그룹 중 무엇을 먼저 만들어야 하나?
조직 소속을 반영한 그룹을 먼저 정하고 프로젝트 안에서는 역할로 연결하면 된다. 개발팀이라는 소속은 여러 프로젝트에서 유지되지만, 한 프로젝트에서 개발팀이 담당자인지 열람자인지는 프로젝트마다 달라질 수 있다.
민감한 이슈만 숨기려면 프로젝트를 분리해야 하나?
항상 분리할 필요는 없다. 제한 대상이 일부 이슈라면 이슈 보안 수준이 더 관리하기 편할 수 있다. 다만 프로젝트 전체가 다른 보존 기준이나 참여자 집합으로 움직인다면 별도 프로젝트가 더 명확할 때도 있으므로 운영 책임자와 보안 담당 부서가 함께 판단해야 한다.
외부 협력사에 댓글만 허용하려면 어떻게 하나?
외부 협력사 그룹을 만들고 프로젝트의 제한된 역할에 연결한 뒤, 해당 역할에 이슈 보기와 댓글 추가 권한만 부여하는 방식부터 검토한다. 이슈 생성, 수정, 첨부, 내보내기 권한이 함께 열려 있지 않은지 테스트 계정으로 반드시 확인한다.
권한을 바꿨는데 팀원이 계속 이슈를 보면 왜 그런가?
다른 그룹이나 프로젝트 역할을 동시에 받고 있거나, 이슈 보안 수준에서 별도 열람 대상으로 지정됐을 수 있다. 계정의 모든 그룹 소속과 프로젝트 역할, 권한 구성표, 이슈 보안 수준을 순서대로 확인하면 원인을 좁히기 쉽다.
관련 글
이 글은 일반적인 정보 제공과 참고 목적으로 작성되었으며, 법률 자문·보안 컨설팅·컴플라이언스 판단을 대체하지 않습니다. 소개하는 설정과 절차는 소프트웨어 버전이나 조직 환경에 따라 다르게 동작할 수 있으며, 어떤 보안 조치도 완전한 안전을 보장하지는 않습니다. 실제 적용 전에는 반드시 소속 조직의 정책과 담당 부서(보안·IT·법무)의 확인을 거치고, 중요한 시스템에는 백업과 사전 테스트 후 적용하시기 바랍니다. 규제 해석과 합법·불법 여부는 사안과 시점마다 달라질 수 있으므로 공식 규정과 전문가 상담으로 확인이 필요합니다. 본 사이트는 내용의 정확성과 최신성을 보장하지 않으며, 이 글의 내용을 적용하여 발생하는 어떠한 결과에 대해서도 책임을 지지 않습니다.