로그스톤 샵 LogStone Shop TIL 7
배포마다 있었다 없었다 하는 화면이 있다면, 우리가 밖에 무언가를 기대고 있다는 뜻이다.
밖에 기대면 남의 사정을 따라간다
조용히 꺼지는 의존은 오래 안 들킨다
제품이 셋인데 업데이트 내역을 만드는 방식이 둘로 갈려 있었다.
- 두 제품 — 버전별 내용을 적은 파일을 사이트 저장소 안에 두고 배포할 때 읽는다. 코드 저장소가 비공개라 밖에서 가져올 방법이 없어 이렇게 했다
- 나머지 한 제품 — 코드 저장소가 공개라 배포할 때마다 깃허브 릴리스 API(
api.github.com/repos/…/releases)로 버전 목록을 받아 온다. 릴리스만 올리면 사이트가 알아서 따라가니 이쪽이 편해 보였다
문제는 편해 보이던 쪽에서 났다. 깃허브 API는 인증 없이 부르면 시간당 60번으로 제한되는데, 그 한도가 우리 계정이 아니라 요청이 나가는 IP 기준이다. 배포는 우리 컴퓨터가 아니라 호스팅의 빌드 서버에서 도는데, 그 서버 주소는 여러 고객이 함께 쓴다.
즉 우리가 몇 번 배포했는지와 상관없이 막힐 수 있었다. 게다가 실패하면 그 부분을 통째로 감추도록 돼 있어서, 화면에 아무 흔적이 남지 않았다. 배포가 돌 때마다 있었다 없었다 했고 언제부터 없었는지도 몰랐다.
두 가지를 배웠다. 밖에서 받아 오는 것은 남의 사정으로 언제든 끊기고, 그 실패를 감추는 설계는 알아챌 방법까지 같이 지운다.
실패했을 때 아무도 모르는 상태로 두지 않는다
목록을 받아 오지 못하면 그 부분을 통째로 감추고 넘어가게 짜여 있었다. 방문자에게 오류 화면을 보이지 않으려는 의도였고, 그 자체는 나쁜 결정이 아니다.
문제는 감추고 나서 아무 데도 남기지 않은 것이다. 화면에는 흔적이 없고 배포는 성공으로 끝나니, 업데이트 내역이 없어졌다는 걸 알아챌 방법이 없었다. 실제로 사이트를 보다가 “어, 이거 어디 갔지”로 발견했다.
이럴 때 고를 수 있는 길은 셋이다.
- 실패를 어딘가에 남긴다 — 화면에는 안 보이더라도 배포 기록에 경고를 띄워서, 빠졌다는 걸 사람이 알게 한다
- 실패하면 배포를 멈춘다 — 빠진 채로 나가는 걸 아예 막는다. 대신 외부 서비스가 막히면 아무 배포도 못 한다
- 실패할 자리를 없앤다 — 밖에서 받아 오지 않고 필요한 내용을 저장소 안에 직접 둔다
세 번째를 골랐다. 나머지 두 제품이 이미 그렇게 하고 있었으니 새로 만들 것도 없었다. 셋이 같은 방식이 되면서 배포가 몇 번을 돌아도 결과가 같아졌고, 확인할 것도 하나 줄었다.
대신 자동으로 채워지던 것이 사라졌다. 새 버전이 나와도 저절로 붙지 않고 사람이 내용을 넣어야 한다. 손이 조금 더 가는 대신 결과가 흔들리지 않는 쪽을 택한 것인데, 하루에 몇 번씩 버전이 나오는 규모라면 반대로 골랐을 것이다.
방식을 바꿨으면 그걸 쓰던 쪽에 알린다
프로젝트마다 담당이 나뉘어 있어서, 앱을 내는 쪽과 사이트를 고치는 쪽이 다르다. 이 건에서는 소리꽃 KeyBloom 담당이 새 버전을 릴리스하고, 샵 담당이 사이트에 반영한다.
전에는 앱 담당이 릴리스를 올리고 “배포 한 번 해 주세요”라고만 하면 사이트가 알아서 목록을 받아 왔다. 방식을 바꾼 뒤로는 그렇게 하면 아무 일도 일어나지 않는다. 이제는 버전 내용을 요청함에 적어 보내야 사이트에 붙는다.
이 변경에서 제일 위험했던 건 코드가 아니라 여기였다. 방식이 바뀌면 그 방식에 기대던 쪽의 절차도 바뀌어야 하는데, 바꾼 쪽이 알리지 않으면 상대는 예전처럼 하고 아무도 잘못한 게 없는 상태로 결과가 안 나온다. 그래서 바꾸자마자 무엇이 달라졌는지, 앞으로 무엇을 해야 하는지를 요청함에 적어 보냈다.
확인하는 방법
값이 아니라 구조를 확인한다
재배포한 뒤 페이지에서 버전 숫자를 찾아보고 반영됐다고 알렸다. 그런데 그때 이미 그 부분이 통째로 빠져 있었고, 숫자는 다른 자리에서 걸린 것이었다.
확인해야 할 것은 값이 아니라 있어야 할 구조였다. 값은 다른 자리에도 있을 수 있지만 구조는 그 자리에만 있다.
문서 쪽에서는 이미 “있어야 할 문장과 없어야 할 문장”을 함께 보고 있었는데, 배포 확인에는 그 습관이 옮겨져 있지 않았다. 확인 기준은 한 곳에서만 엄격하면 소용이 없다.
저장소 밖에 있는 값은 문서에 박아 둔다
스토어 콘솔의 개발자 연락처, 광고 인증 통과 여부, 검색 콘솔 제출 여부는 코드에서 확인할 방법이 없다. 확인할 수 없으니 물어보게 되고, 물어본 걸 기록하지 않으면 다음에 또 묻는다.
확인이 끝난 값은 날짜와 함께 프로젝트 문서에 확정 사실로 적는다. 같은 질문을 반복하는 것도 비용이고, 반복해서 묻는 쪽이 일을 하고 있다는 인상을 주지도 않는다.
스토어에 내는 문서
양식이 요구하면 문서에 그 문장이 있어야 한다
데이터 신고 양식에 “이용자가 삭제를 요청할 방법을 제공하는가”라는 항목이 있다. 여기에 그렇다고 답하면 방침 주소를 함께 낸다. 심사는 그 페이지에서 삭제 방법이 실제로 적혀 있는지 본다.
그래서 방법을 문장 속에 흘려 쓰지 않고 번호를 매겨 나란히 뒀다. 사람이 훑든 심사자가 훑든 눈에 걸리게 만드는 게 목적이다. 양식과 문서는 따로 존재하는 게 아니라 서로를 가리킨다.
같은 기능이라도 플랫폼이 다르면 문장이 달라진다
두 제품이 같은 회사의 클라우드 저장을 쓰는데, 한쪽은 앱 안에서 연결을 끊을 수 있고 다른 쪽은 그 기능 자체가 없다. 쓰는 서비스의 방식이 달라서 앱이 할 수 있는 일이 다르다.
앞선 TIL 6에서 방침에는 앱이 실제로 할 수 있는 일만 적어야 한다고 했다. 이번엔 그게 조항을 재사용할 때 걸렸다. 앞서 쓴 조항을 그대로 옮겼다면 이용자에게 “앱에서 해제하세요”라고 안내하는데 그런 버튼이 없는 방침이 나왔을 것이다. 조항을 재사용할 때 옮겨야 하는 건 문장이 아니라 사실관계다.