팀 뷰 기능을 라이선스로 계층별 접근 제어한 과정

팀 뷰 기능을 라이선스 기반으로 게이팅하고 패키지 설명을 정정한 작업이다. 단순해 보이지만 제품 정책과 코드 구조가 만나는 지점에서 꽤 생각할 게 많았던 변경이다.

라이선스 게이팅의 필요성

내부 정책상 팀 뷰(team view) 기능은 특정 라이선스 이상의 사용자에게만 노출되어야 한다. 이건 단순한 UI 숨김이 아니라 접근 제어(access control)의 문제다.

예전에는 기능이 충분히 성숙하지 않았거나, 아니면 정책이 나중에 정해진 경우가 많다. 그래서 이런 류의 게이팅은 처음부터 고려하지 못했다가 나중에 추가하게 되는데, 그럼 코드를 여기저기 散재(산재)시킨 체크들을 정리하면서 동시에 일관성 있게 구조화해야 한다.

무엇을 게이팅했나

변경된 파일들을 보면:

결국 팀 뷰는 여러 계층(CLI, 웹 대시보드, 백엔드 API)에서 노출되므로, 각 계층에서 독립적으로 라이선스를 검증해야 한다는 뜻이다.

게이팅 구현의 고민

라이선스 체크를 어디에 걸까가 관건이었다. 보통 세 가지 접근이 있다:

1. 진입점 (CLI index, 서버 라우팅) → 빠르지만 누락하기 쉬움
2. 기능 함수 내부 → 안전하지만 여러 곳에서 반복
3. 미들웨어/인터셉터 → 체계적이지만 과할 수 있음

이 경우엔 CLI와 웹 서버의 구조가 다르므로, 각각에 맞는 수준의 게이팅을 했을 거 같다. CLI면 커맨드 등록 단계에서, 웹 서버면 라우팅 미들웨어에서. 테스트가 추가된 것도 이 검증이 정상 작동하는지 확인하기 위함이다.

패키지 설명도 고쳤다

commit 메시지에 "fix package description"도 있다. package.json의 description 필드가 부정확했거나, 팀 뷰 추가로 제품 설명이 변해서 그걸 반영한 것 같다. 작은 변경이지만 의미 있다. 왜냐면:

• npm 레지스트리나 깃허브에서 처음 보는 사람들이 읽는 부분
• 버전 업 시 고객이 보는 메타 정보
• 내부 문서나 마케팅 자료와 일관성 유지

부실한 설명은 기능 추가보다 더 먼저 눈에 띈다.

회고: 계층별 검증의 중요성

이 작업을 하면서 배운 건, 같은 기능이 여러 인터페이스(CLI, API, 웹UI)로 노출될 때는 각 인터페이스의 진입점마다 독립적으로 검증해야 한다는 점이다.

한 곳에서만 체크하고 나머지는 생략하면, 누군가는 다른 경로로 기능에 접근할 수 있다. 특히 라이선스 같은 정책 조건은 "어차피 한 군데서 걸리겠지" 같은 낙관적 사고가 가장 위험하다. 그래서 team-usage.test.ts 같은 테스트가 중요한 거다. 라이선스 없는 사용자가 실제로 팀 뷰에 접근할 수 없는지, 명시적으로 검증해야 한다.

또 하나, 이런 정책 변경이 생기면 README나 CHANGELOG에도 반영되어야 하는데, 이미 다른 부분에서 처리했을 가능성이 높다. 작은 것처럼 보이는 게이팅 작업도, 실제로는 제품 정책 문서, 테스트, 코드 구조 전반에 영향을 미친다.

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

• 기계식키보드 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

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