IssueSticker이 문서가 필요한 경우
- 여러 팀과 서비스가 하나의 조직 안에서 이슈를 남깁니다.
- 운영, 스테이징, 내부 도구 도메인을 구분해야 합니다.
- 외부 도구로 넘기는 필드와 권한 범위를 프로젝트별로 통제해야 합니다.
끝나면 확인할 것
- 워크스페이스와 프로젝트 경계를 조직 운영 단위로 정했습니다.
- 도메인 승인, 멤버 권한, 연동 범위를 프로젝트별로 나눴습니다.
- 내부 QA는 Extension, 제품 안 피드백은 SDK Widget으로 나누는 기준을 정했습니다.
무엇이 번거로운가요
큰 조직에서는 피드백 수집보다 운영 기준을 맞추는 일이 더 어렵습니다. 어떤 도메인에서 쓸 수 있는지, 누가 프로젝트를 볼 수 있는지, 외부 도구에는 어떤 필드까지 보낼지 정해야 합니다.
이슈스티커로 줄어드는 일
이슈스티커는 프로젝트, 도메인, 멤버 권한을 나눠 관리합니다. SDK는 승인된 origin에서만 초기화되고, Extension도 연결된 도메인에서만 캡처 기능이 켜집니다.
Jira와 Notion 연동은 프로젝트별로 설정합니다. 필요한 필드만 노출하면 QA 리포트는 충분히 자세하게 남기되, 팀이 관리하지 않는 정보까지 밀어 넣지 않을 수 있습니다.
어떤 제품이 맞나요
내부 QA와 운영 검수는 Extension을 기준으로 잡습니다. 고객이나 내부 사용자에게 제품 안에서 피드백을 받는 흐름은 SDK Widget으로 나눕니다.
도입 초반에는 모든 팀에 한 번에 열기보다 대표 프로젝트 하나에서 필드, 권한, 연동 흐름을 검증한 뒤 확장하는 편이 안정적입니다.
바로 해볼 다음 단계
- 워크스페이스와 프로젝트 기준을 먼저 정합니다.
- 운영, 스테이징, 내부 도구 도메인을 분리해 등록합니다.
- 프로젝트별 관리자와 멤버 권한을 정합니다.
- Jira 또는 Notion 연동을 프로젝트별로 붙입니다.
- SDK를 쓰는 프로젝트는 public key scope와 만료 정책을 정합니다.