개발 slecs

팀 배포 권한을 명시적 허용 목록으로 체계화

목차

팀 멤버들의 push 권한을 체계적으로 관리할 수 있는 allowlist 체계를 구축했다. 이전엔 누가 실제로 배포 권한이 있는지 암묵적이거나 제대로 추적되지 않았는데, 이번 작업으로 명시적인 소유자 관리 구조를 도입할 수 있게 됐다.

문제: 암묵적 권한 관리의 위험성

배포/push 권한이라는 게 엄청 중요한데, 팀이 성장하면서 "누가 정말 push할 수 있는 사람인지"가 불명확해지기 쉽다. 온보딩 초기에 어떤 식으로든 권한을 주긴 하는데, 사람이 나가거나, 역할이 바뀌거나, 프로젝트에서 떠날 때 그 권한을 제때 회수하지 않을 수 있다. 특히 리소스나 자동화 파이프라인이 여러 사람의 계정으로 뒤얽혀 있으면, 누가 어디서 push 했는지 추적이 어렵고, 보안 사고 발생 시 책임 추적도 막힌다.

우리 팀 규모에서는 아직 그 정도 큰 문제가 터지진 않았지만, 조금 더 체계적으로 접근할 필요를 느꼈다. 특히 새 팀원이 들어오거나, 다른 팀에서 협력할 때 "이 사람이 정말 push 권한이 있는 건가?" 하는 의구심이 생기는 상황들이 반복됐다.

풀이: Allowlist 기반 명시적 관리

roster(명단) 체계를 도입해서 각 팀마다 push 가능한 owner들의 명시적 allowlist를 둔다. 이게 단순해 보이지만, 생각보다 영향이 크다:

관점 이전 이후
권한 추적 암묵적, 형식화되지 않음 명시적 allowlist (roster-store)
권한 변경 점검 미흡 CLI 명령어로 체계적 추가/제거
감시 누가 누구인지 불명확 팀별 owner 목록 명확
배포 검증 사후 추적 어려움 server 레벨 검증 가능

src/infrastructure/roster-store.ts 는 이 allowlist를 관리하는 저장소 계층이다. 메모리든 DB든 상관없이, 팀 → owner 리스트 매핑을 일관되게 제공한다. 나중에 저장소 구현을 바꿔도 인터페이스는 변하지 않게 설계했다.

src/interface/cli/commands/team.tssrc/interface/cli/index.ts 는 CLI 사용자가 roster를 관리할 수 있도록 노출한다. team add-owner, team remove-owner 같은 명령어를 통해 누가 언제 어떤 권한을 줬는지 명확히 남긴다. 비슷하게 Kubernetes의 kubectl 이나 Terraform 같은 IaC 도구들도 state 변경을 로깅하고 추적하는데, 우리도 그 방식을 따르려고 했다.

src/interface/server/server.ts 는 실제 push 요청이 들어왔을 때 이 allowlist를 참고해 검증한다. 요청한 사람이 팀의 owner list에 있는지 확인하고, 없으면 reject 한다. 이게 단순한 로직이지만, 여기서 "실행 시점"의 검증이 이루어진다는 게 중요하다. CLI로 권한을 줘도, 실제로는 server가 enforce 한다.

src/interface/server/team-usage.test.ts 는 이 검증 로직이 제대로 작동하는지 보장한다. roster가 비어있으면 아무도 push 못 하는지, owner가 있으면 그 사람만 push 되는지, 제거되면 즉시 반영되는지 같은 시나리오를 커버했다. 특히 "권한 관리" 같은 보안 관련 로직은 test 커버리지가 높아야 버그로 인한 피해가 덜하다.

회고: 점진적 권한 통제의 시작

이 작업이 거창한 RBAC(Role-Based Access Control) 시스템은 아니다. 그냥 "누가 push 할 수 있는가"라는 가장 기본적인 질문에 답할 수 있게 한 것이다. 하지만 경험상 이런 단순한 명시화가 나중에 얼마나 큰 도움이 되는지 안다.

팀이 커질수록, 또는 보안 요구사항이 강해질수록 이 roster 위에 추가 레이어를 얹을 수 있다. 예를 들어 "특정 브랜치에만 push 가능", "승인 후에만 가능", "특정 시간대에만 가능" 같은 규칙들도 이 allowlist를 기반으로 구현할 수 있다. 일종의 foundation 을 깔아둔 셈이다.

한 가지 배운 점은, 이런 접근 방식을 처음부터 너무 정교하게 설계하려고 하면 오버엔지니어링이 된다는 것. 우리는 "owner 있는가/없는가" 정도로 시작했고, 나중에 필요하면 extends 하는 전략을 택했다. 이 덕에 구현은 간단하고, review도 빨랐고, 테스트도 명확하게 작성할 수 있었다.

앞으로 새로운 팀원이 들어올 때, 또는 권한을 변경할 때 이제 CLI 명령어 한 줄로 처리할 수 있다. 그리고 언제든 "이 팀은 현재 누가 push할 수 있는가"를 조회할 수도 있다. 보안과 운영 편의성 사이에 괜찮은 균형을 찾은 것 같다.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.