로그스톤 샵 LogStone Shop TIL 3
샵을 여러 제품의 정책 허브로 만들면서 정한 것들.
문서가 합집합이 되는 문제
하나로 합친 문서는 제품이 늘수록 틀려진다
처음에는 개인정보처리방침과 이용약관을 완성된 문서 한 벌로 뒀다. 제품이 넷을 넘어가자 문제가 드러났다. 유료 도구를 산 사람이 게임 재화 조항을 읽고, 광고 없는 앱의 방침에 광고 문단이 있다. 어느 문장도 거짓은 아닌데 그 제품에는 해당하지 않는다.
그래서 문서를 통째로 쓰지 않고 조항 단위로 쪼갠 뒤, 각 조항에 “어느 제품에 붙는지”를 달았다. 페이지는 그 표시를 보고 자기 것만 골라 조립한다.
바뀐 것은 관리의 방향이다. 전에는 제품이 늘 때마다 문서를 고쳐 썼고, 지금은 조항을 하나 쓰고 어디에 붙일지만 정한다. 제품 추가 비용이 문서 다시 쓰기에서 태그 한 줄로 내려갔다.
공통 조항에 고유명사를 넣으면 새어 나간다
전 제품에 붙는 공통 조항에 결제 회사 이름을 적었더니, 결제가 없는 앱의 방침에도 그 회사 이름이 나왔다. 조각으로 나눈 다음에 생긴 새로운 종류의 실수다.
규칙으로 정리하면 이렇다. 공통 조항은 어떤 조합에서도 참인 문장만 담고, 구체적인 업체·기능은 제품 조항이 말하게 한다. 공통 조항에서는 “아래에서 설명하는 서비스”처럼 가리키기만 한다.
조립한 문서는 사람 눈으로 못 본다
제품이 일곱이면 방침과 약관을 합쳐 열네 장이다. 조항 하나를 고쳤을 때 어디에 붙고 어디에 안 붙는지 눈으로 확인하기 쉽지 않다.
그래서 페이지마다 “있어야 할 문장”과 “있으면 안 되는 문장”을 함께 대조하게 했다. 있어야 할 것만 확인하면 절반이다. 조립형 문서에서 진짜 사고는 남의 제품 조항이 딸려 들어가는 쪽에서 난다.
릴리스 노트에서 생긴 계약
한 글에 두 언어를 담는 규약
버전 설명을 언어별로 따로 관리하면 한쪽만 갱신되는 일이 생긴다. 그래서 한 글 안에 한국어를 쓰고 구분선을 하나 긋고 영어를 쓰기로 했다. 읽는 쪽이 구분선으로 갈라 해당 언어만 보여준다.
중요한 건 이게 쓰는 쪽과 읽는 쪽 사이의 계약이라는 점이다. 발행하는 세션이 구분선을 빼먹으면 화면이 어긋난다. 그래서 이런 규약은 코드에만 두지 말고 발행 절차 문서에도 같이 적어야 유지된다.
그 글을 누가 쓸 수 있는지가 안전을 가른다
버전 설명은 마크다운으로 쓴다. 목록이나 굵은 글씨가 화면에 나오려면 그걸 HTML로 바꿔 페이지에 끼워 넣어야 하는데, 이 변환은 위험한 코드를 걸러 주지 않는다. 글 안에 스크립트가 들어 있으면 방문자 브라우저에서 그대로 실행된다.
지금 이 방식이 안전한 이유는 버전 설명을 쓸 수 있는 사람이 저장소에 접근 권한이 있는 사람으로 한정돼 있어서다. 반대로 고객 후기나 댓글처럼 아무나 입력할 수 있는 내용을 같은 방식으로 넣으면, 누군가 스크립트를 적어 넣는 순간 그 사이트를 통해 다른 방문자가 공격당한다.
그래서 화면에 글을 넣을 때 묻는 건 “이 글이 어떻게 생겼나”가 아니라 “이 글을 누가 쓸 수 있나”다. 쓸 수 있는 사람이 정해져 있으면 그대로 넣어도 되고, 누구나 쓸 수 있는 자리면 걸러내는 단계가 반드시 하나 더 필요하다.
스토어에 제출하는 문서
정책 주소는 제품별로 나누는 게 낫다
앱 여러 개가 정책 주소 하나를 나눠 쓰면, 심사하는 쪽이 문서에서 그 앱 얘기를 찾아야 한다. 무관한 조항이 오해를 부르기도 한다.
제품별 주소를 제출하면 스토어의 데이터 신고 양식과 문서가 일대일로 맞는다. 대신 새 관리 항목이 생긴다. 조항을 고치면 어느 앱의 양식을 같이 고쳐야 하는지 기억해야 한다. 문서를 나눌수록 문서와 신고서 사이의 연동을 사람이 챙겨야 한다는 뜻이라, 이것도 절차로 적어 뒀다.