룸톤 Roomtone TIL 9
시간대에 따라 바뀌는 재생
시각을 지키는 전환과 곡을 안 끊는 전환은 서로 다른 요구다
시간대마다 재생목록이 바뀌게 만들 때, 앞선 TIL 8에서 정한 대로 전환은 곡이 끝나는 자리에서만 하기로 돼 있었다. 곡을 중간에 끊으면 어색하니 그 하나면 될 줄 알았다.
그런데 블록마다 원하는 게 달랐다. 낮 시간대는 곡이 끊기지 않는 게 중요하고, 마감처럼 시각 자체가 의미인 블록은 9시면 9시에 분위기가 바뀌어야 한다. 곡이 5분짜리면 전환이 5분 밀리는데, 손님 있는 시간엔 그게 자연스럽고 마감엔 그게 어긋난다.
하나로 정하면 늘 한쪽이 아쉬운 구조라, 블록마다 고르게 두는 게 맞았다. 설정을 하나 늘리는 비용보다 두 요구를 다 만족시키는 값이 컸다.
여기서 가져갈 건 「옵션을 늘려라」가 아니다. 같은 기능처럼 보이는 요구가 사실 성격이 다른 둘인지를 먼저 확인하라는 것이다. 둘이면 기본값을 정하고 나머지를 예외로 열면 된다.
약관과 계약
강한 조항은 통째로 세우기보다 예외 하나를 막아 두는 편이 안전하다
구독은 완전 무환불로 가기로 했다. 그런데 「어떤 경우에도 환불 없음」을 그대로 두면, 우리 잘못으로 서비스를 못 준 기간까지 덮게 된다. 그 상태면 조항 전체가 불공정하다고 다퉈질 여지가 생긴다. 강하게 쓰려다 조항 자체가 흔들리는 셈이다.
그래서 무환불은 유지하되 「당사 귀책으로 서비스를 제공하지 못한 기간은 그만큼 구독 기간을 연장한다」를 붙였다. 돈을 돌려주는 게 아니라 기간으로 보전하는 거라 현금 흐름은 그대로다.
강한 조항일수록 구멍 하나를 미리 막아 두는 게, 조항 전체를 지키는 방법이다.
라이선스를 장소가 아니라 계정에 건다
처음엔 「계약한 매장 안에서만 재생」으로 적으려 했다. 뜻은 맞는데, 매장을 특정하는 표현이라 가게를 옮기거나 등록 정보를 고칠 때마다 계약을 손대야 한다.
「구독 1건 = 사업장 한 곳, 여러 곳이면 그 수만큼 구독」으로 바꾸니 목적은 그대로 살았다. 체인이 구독 하나로 여러 지점을 돌리는 걸 막는 게 원래 목적이었고, 그건 장소를 특정하지 않아도 표현된다.
막고 싶은 것이 「장소」인지 「동시에 쓰는 수」인지를 먼저 가리면, 계약 문구가 운영을 덜 붙잡는다.
매장에서 트는 것과 영상에 얹는 것은 값이 다르다
금지 목록을 적을 때 재배포·재판매·다운로드·계정 공유까지는 자연스럽게 나왔는데, 「2차 송출」은 빠져 있었다. 우리 음원을 유튜브나 팟캐스트 배경음악으로 얹는 경우다.
매장에서 트는 것과 콘텐츠에 실어 배포하는 것은 도달 범위가 달라 값도 달라야 한다. 같은 「재생」이라는 말에 묶여 있어서 한 덩어리로 보였을 뿐이다. 허용 범위를 적을 때는 「무엇을 하는가」보다 「얼마나 퍼지는가」로 나눠 보는 편이 빠진 걸 찾기 쉽다.
AI가 만든 곡은 재생권까지만 약속할 수 있다
음원은 생성 도구로 만들어 편곡을 얹은 것이다. 도구 약관상 다운로드본은 상업적으로 쓸 수 있지만, 동시에 「저작권이 성립한다고 보장하지 않는다」고 적혀 있다. AI 생성물은 저작권 자체가 안 설 수 있기 때문이다.
그래서 약관에는 「재생할 권리를 제공한다」까지만 적고, 곡의 저작권 귀속이나 독점은 보증하지 않는다는 면책을 넣었다.
재미있는 건 이 약점이 다른 쪽에서는 강점이 된다는 것이다. 저작권 신탁 단체에 맡겨진 곡이 아니라서, 매장이 이 음원을 틀 때 별도 공연사용료를 낼 필요가 없다. 라이브러리를 지키는 힘은 약해지지만, 파는 문구는 오히려 선명해진다. 약점과 강점이 같은 뿌리에서 나올 때는 둘 다 적어 두는 게 정직하고 안전하다.
어디서 파느냐가 값을 가른다
같은 결제사라도 앱 안에서 부르면 수수료가 붙는다
앱을 스토어에 올리기로 하면서, 쓰던 결제사가 무의미해지는 줄 알았다. 확인해 보니 반대였다. 정책이 바뀌어 외부 결제가 허용됐고 수수료도 내려갔다(정기구독 10%). 다만 앱에서 링크를 타고 나가 결제해도 그 수수료와 거래 보고 의무가 따라붙는다. 외부 링크가 공짜라는 뜻이 아니었다.
반면 앱 밖에서 팔면, 즉 웹에서 가입·결제하고 앱은 로그인해서 쓰기만 하면 스토어 결제 규칙에 걸리지 않는다.
그래서 결제사는 그대로 두고 구매 동선만 앱 밖으로 뺐다. 앱에는 누를 수 있는 결제 버튼을 두지 않고 안내 문구만 남겼다.
바뀐 건 「무엇으로 받느냐」가 아니라 「어디서 받느냐」였다. 수수료를 볼 때 결제 수단만 비교하면 절반만 본 것이다.
B2B는 세금계산서가 결제사를 정한다
수수료만 보면 스토어 결제도 나쁘지 않은 수준까지 내려왔다. 그런데 고객이 사업자면 이야기가 달라진다. 매장은 비용 처리를 위해 인보이스가 필요한데, 스토어 결제로는 그게 안 나온다.
판매 대행사 형태의 결제사를 고른 이유가 원래 그거였다는 걸 이 대목에서 다시 확인했다. 개인 대상 앱이면 수수료가 기준이 되지만, 사업자 대상이면 증빙이 먼저다. 고객이 개인인지 사업자인지가 결제 수단 선택을 바꾼다.
플랫폼을 하나 더 늘리는 비용은 코드가 아니라 배포 인프라다
같은 프레임워크로 만들었으니 다른 모바일 플랫폼도 코드는 거의 그대로 나온다. 그래서 「언젠가 같이 올리면 되지」라고 생각하기 쉬운데, 실제 비용은 코드가 아니었다.
연 단위 개발자 등록비가 따로 들고, 빌드와 제출에 특정 운영체제의 기계가 있어야 한다. 지금 쓰는 기계로는 아예 빌드가 안 된다. 심사도 별도고 스토어 등록물도 따로 만들어야 한다.
그래서 한쪽만 먼저 내기로 했다. 매장에 놓을 기기는 어차피 싼 태블릿 하나면 되니 제품 가치가 줄지도 않는다.
「코드가 공유되니 싸다」는 착각을 조심할 것. 플랫폼을 늘리는 비용은 대부분 코드 밖에 있다.
요약
- 같은 기능처럼 보이는 요구가 성격이 다른 둘이면, 기본값을 정하고 나머지를 예외로 연다.
- 강한 조항일수록 구멍 하나를 미리 막아 두는 게 조항 전체를 지킨다.
- 막고 싶은 게 장소인지 동시 사용 수인지 가리면 계약이 운영을 덜 붙잡는다.
- 허용 범위는 「무엇을 하는가」보다 「얼마나 퍼지는가」로 나눠야 빠진 걸 찾는다.
- 약점과 강점이 같은 뿌리에서 나오면 둘 다 적어 두는 편이 안전하다.
- 수수료는 결제 수단이 아니라 판매 위치가 가른다.
- 고객이 사업자면 수수료보다 증빙이 먼저다.
- 플랫폼을 늘리는 비용은 코드가 아니라 배포 인프라에 있다.