문의 이메일 대신 공개 저장소를 연결한 이유
코딩은 AI에게 맡겼습니다 · 시즌 1 / 7
첫 개인정보처리방침을 만든 직후 문의 주소를 저장소의 이슈 페이지로 바꿨습니다. 코드 변화는 한 줄뿐이었습니다. 그러나 1인 개발 제품에서 사용자의 질문을 어디로 받을지는 기능만큼 오래 영향을 주는 결정입니다.
먼저 보는 핵심
지원 채널은 많이 만드는 것보다 실제로 확인하고 답할 수 있는 곳 하나를 정하는 것이 중요합니다. 공개 이슈는 같은 문제의 중복 문의를 줄이지만, 개인정보가 포함될 수 있는 질문을 위한 별도 경로도 필요합니다.
왜 이메일을 바로 공개하지 않았나
개인 이메일은 시작하기 쉽지만 제품 문의와 개인 메일이 섞입니다. 해결 과정이 다른 사용자에게 보이지 않아 같은 질문에 반복해서 답하게 됩니다. 스팸과 민감한 첨부 파일을 처리하는 문제도 생깁니다.
공개 저장소의 이슈 페이지는 다음 장점이 있었습니다.
- 버그와 기능 요청을 제목별로 관리할 수 있다.
- 이미 보고된 문제를 사용자가 검색할 수 있다.
- 수정 커밋과 문의를 연결할 수 있다.
- 해결 상태와 우회 방법을 공개할 수 있다.
- 별도의 고객지원 시스템을 운영하지 않아도 된다.
반면 모든 질문을 공개 이슈로 받으면 안 됩니다. 메모 내용, 계정 정보, 결제 정보처럼 민감한 자료가 포함되는 제품이라면 비공개 연락 경로가 필요합니다.
AI가 정해 주지 못한 운영 문제
AI는 문의 문구와 이슈 양식을 만들 수 있습니다. 하지만 실제로 얼마나 자주 확인할지, 어떤 언어로 답할지, 답변 시간을 약속할 수 있는지는 운영자가 정해야 합니다.
지원 채널을 선택할 때 다음 질문을 사용했습니다.
| 질문 | 결정 기준 |
|---|---|
| 사용자가 계정 없이 접근할 수 있는가 | 대상 사용자의 GitHub 사용 여부 확인 |
| 공개해도 안전한 문의인가 | 개인정보 포함 가능성 구분 |
| 내가 꾸준히 확인하는 곳인가 | 새 알림 시스템을 늘리지 않기 |
| 해결 기록이 다른 사람에게 도움이 되는가 | 공개 검색 가치 확인 |
| 서비스가 커져도 옮길 수 있는가 | 데이터 내보내기와 링크 구조 확인 |
한 줄 수정도 제품 결정이다
커밋 기록만 보면 URL 하나를 바꾼 사소한 작업입니다. 하지만 사용자는 문제가 생겼을 때 그 한 줄을 따라옵니다. 링크가 끊기거나 관리되지 않으면 개인정보처리방침 전체의 신뢰도도 낮아집니다.
AI 개발에서는 코드가 많이 바뀐 커밋에 시선이 가기 쉽습니다. 실제 운영에서는 한 줄짜리 연락처, 버전, 권한 설명이 더 중요한 경우가 있습니다. 변경 줄 수와 제품 영향은 비례하지 않습니다.
다음 편
문의 경로를 고친 뒤 정책 문서를 전면 보강했습니다. 다음 편에서는 26줄 문서가 135줄 규모로 늘어난 이유와, 길이보다 중요했던 내용을 정리합니다.
댓글
댓글 쓰기