이슈스티커이 문서가 필요한 경우
- “안 돼요” 같은 리포트만 받고 재현 정보를 다시 요청하는 일이 잦습니다.
- 콘솔 에러, 네트워크 실패, 브라우저 환경을 리포트 단계에서 같이 받고 싶습니다.
- SDK Widget이나 Headless API를 제품 코드에 붙일지 검토합니다.
끝나면 확인할 것
- 디버깅에 필요한 URL, 브라우저, 콘솔, 네트워크 정보가 어디에 붙는지 확인했습니다.
- 내부 검수는 Extension, 제품 내 피드백은 SDK Widget으로 나누는 기준을 이해했습니다.
- Headless API는 runtime 이벤트용이지 직접 제출 API가 아니라는 점을 확인했습니다.
무엇이 번거로운가요
“안 돼요”라는 리포트만으로는 바로 고치기 어렵습니다. 어떤 페이지였는지, 어떤 브라우저였는지, 콘솔 에러가 있었는지, API가 실패했는지 다시 확인해야 합니다.
이 과정이 길어지면 버그 수정 시간보다 재현 확인 시간이 더 길어집니다.
이슈스티커로 줄어드는 일
이슈스티커 이슈에는 화면과 기술 정보가 함께 들어옵니다. URL, 브라우저 정보, 콘솔 로그, 네트워크 로그가 붙어 있으니 처음부터 확인할 단서가 많습니다.
녹화가 붙은 이슈는 재현 단계도 짧게 확인할 수 있습니다. QA나 고객에게 “한 번만 다시 보여주세요”라고 묻는 횟수를 줄이는 것이 목표입니다.
어떤 제품이 맞나요
개발자가 직접 검수하거나 운영 이슈를 확인한다면 Extension이 편합니다. 앱 내부에서 고객이 남기는 피드백을 개발팀이 바로 받아야 한다면 SDK Widget을 붙입니다.
UI 없이 SDK 상태만 앱 흐름에 연결하려면 Headless API를 확인하세요.
다만 Headless API는 이슈 제출 UI를 대체하지 않습니다. 실제 고객 피드백을 받는 화면이 필요하면 SDK Widget을 붙이고, 이벤트만 앱 로깅 흐름에 연결할 때 Headless를 검토하세요.
바로 해볼 다음 단계
- 개발 환경이나 스테이징 도메인을 프로젝트에 연결합니다.
- 네트워크 실패가 나는 화면에서 이슈를 남깁니다.
- 저장된 콘솔/네트워크 로그를 확인합니다.
- Jira나 Notion 필드와 실제 이슈 처리 흐름이 맞는지 조정합니다.