BuildingHub TIL 4
로컬에서만 돌던 것을 공개 주소에 올렸다. 앞의 세 편이 만드는 동안의 이야기였다면 이건 내놓는 쪽의 이야기다. 여기서 내가 정해야 했던 것들을 남긴다.
남에게 보여준다는 것
내가 직접 눌러야 넘어가는 자리가 있었다
인터넷에 올리는 중에 멈췄다. 관리자가 올린 사진을 넣어 둘 R2(Cloudflare의 파일 저장소)를 만들어야 하는데, R2 자체가 내 계정에서 꺼져 있었다. 켜려면 Cloudflare 대시보드에 로그인해서 버튼을 눌러야 하고, 그건 계정 주인만 할 수 있다. 내가 들어가서 켤 때까지 작업이 그대로 서 있었다.
클라우드는 명령 몇 줄로 다 되는 줄 알았는데 아니었다. 결제 수단을 등록하거나, R2처럼 기능을 처음 켜거나, 이 도메인이 내 것임을 확인하는 일은 계정 주인이 직접 해야 한다.
그래서 일정을 볼 때 확인할 것이 하나 늘었다. 만드는 데 며칠 걸리느냐뿐 아니라, 중간에 나를 기다려야 하는 지점이 어디인가. 이런 건 한 번 켜 두면 그다음부터 안 걸리니, 미리 켜 두는 것만으로 대기가 통째로 없어진다.
구경만 되는 계정을 따로 만들었다
주소가 생기니 정할 것이 하나 생겼다. 담당자에게 링크를 보내면서 관리자 화면까지 보여주고 싶은데, 그러려면 아이디와 비밀번호를 같이 알려 줘야 한다. 그런데 있는 계정은 예약을 지우고 문구를 바꿀 수 있는 계정 하나뿐이었다.
비밀번호를 어렵게 바꾸는 걸로는 안 풀린다. 어차피 알려 줘야 볼 수 있으니까. 그리고 받은 사람이 나쁜 마음을 먹지 않아도, 이것저것 눌러 보다가 예약이 지워지면 다음 사람에게 보여줄 화면이 남지 않는다.
그래서 계정을 둘로 나눴다. 고칠 수 있는 계정과, 화면은 다 보이되 아무것도 바꾸지 못하는 계정이다. 링크와 함께 알려 주는 건 뒤엣것이다.
배운 건 비밀번호를 어떻게 관리하느냐가 아니다. 보여주기 위한 계정을 따로 만들어 둬야 한다는 것이다. 없으면 고를 수 있는 게 아예 안 보여주기와, 보여준 다음 망가진 걸 되돌리기 둘뿐이 된다.
링크만 받은 사람은 그 화면이 있는 줄 모른다
배포를 끝내고 나서야 물었다. 그래서 이걸 받은 사람은 어디부터 보게 되는가.
이 데모에서 제일 보여주고 싶은 건 운영자가 쓰는 관리 화면인데, 공개 사이트 어디에도 거기로 가는 길이 없었다. 주소를 직접 쳐야만 들어가진다. 링크를 받은 사람은 건물 소개 사이트를 한 바퀴 둘러보고 닫는다. 정작 만든 것의 절반은 존재도 모른 채로.
공개 사이트 푸터에 관리자 콘솔로 가는 링크를 넣고, 로그인 화면에 구경용으로 바로 들어가는 버튼을 뒀다. 두 번 누르면 콘솔 안이다.
가져갈 기준은 이렇다. 보여줄 목적이 있는 물건에서 제품은 기능이 아니라 그 기능에 닿는 경로까지다. 그리고 이건 만든 쪽에 물어봐야 안 나온다. 만든 사람은 경로를 알고 있어서 길이 없다는 걸 못 느낀다. 다 됐다는 말을 들은 뒤에 “링크만 받은 사람이 어디부터 보게 되나”를 처음부터 따라가 보는 시간이 따로 필요하다.
검색에 잡히면 안 되는 물건이 있다
가상 브랜드로 만든 데모라 검색에 걸리면 곤란하다. 실제 건물 정보인 줄 알고 찾아오는 사람이 생길 수 있다.
막는 방법이 두 가지라고 해서 둘 다 걸게 했다. 하나는 robots.txt — 사이트 맨 앞에 두는 파일로, 검색 엔진에게 “여기는 훑어 가지 말라”고 알린다. 다른 하나는 noindex 메타 태그 — 페이지마다 붙이는 표시로, “이 페이지는 검색 목록에 넣지 말라”는 뜻이다. 앞엣것을 지나쳐도 뒤엣것에 걸린다.
하나만 걸어도 대개 되는데, 검색에 한 번 올라가면 내리는 데 시간이 걸리고 그 사이에 본 사람은 어쩔 수 없다. 되돌리기 어려운 쪽으로 실패하는 일은 막을 수단이 둘 있으면 둘 다 쓴다. 아낄 자리가 아니다.
화면은 만든 사람이 못 본다
비어 있는 자리는 짚어 줘야 보인다
식당가 매장 카드가 눈에 걸렸다. 로고 자리가 전부 비어 있어서 아직 안 만든 화면처럼 보였다.
만든 쪽에서는 비어 있는 게 아니었다. 세상에 없는 가게라 로고 파일이 없으니 업종별 그림 마크를 넣어 뒀고, 그러니 처리는 끝난 상태였다. 그런데 그 마크가 작아서 카드 절반이 빈 공간으로 남았고, 보는 쪽에서는 “아직 안 채운 자리”로 읽혔다.
사진을 카드 폭 전체로 올리는 쪽으로 바꾸게 했다.
같은 일이 화면 아래 붙어 있는 배포 바에서도 있었다. 끝까지 내려도 마지막 내용이 바에 가려 있었는데, 오류가 나는 것도 아니고 무언가 잘못됐다는 표시도 없어서 짚기 전까지 그대로 있었다.
두 건에서 같은 걸 봤다. 처리가 끝났다는 것과 보기에 완성됐다는 것은 다른 이야기이고, 뒤엣것은 만든 쪽 판단으로는 안 나온다. 완성 보고를 받은 뒤 직접 열어 보는 시간을 일정에 넣어 둔다.
자동화를 미루는 판단
사람이 한 단계 남는 형태가 오히려 맞을 때가 있다
예약을 승인하고 반려해도 신청자에게는 아무것도 안 가고 있었다. 서버가 직접 메일을 보내려면 발신 도메인 인증 — “이 주소로 메일을 보내도 된다”고 도메인 소유자가 확인해 주는 절차 — 이 필요한데, 그건 이 단계에서 끝낼 수 있는 일이 아니었다.
완성될 때까지 미루는 대신, mailto: 링크로 담당자 컴퓨터의 기본 메일 앱을 여는 방식으로 지금 쓸 수 있게 하기로 했다. 예약을 열고 버튼을 누르면 받는 사람·제목·본문이 다 채워진 채로 메일 창이 뜬다. 담당자는 읽어 보고 보내기만 누른다.
미루기 싫어서 고른 절충안이었는데, 해 놓고 보니 이쪽이 나은 구석이 있었다. 반려 사유처럼 문장을 다듬어야 하는 메일은 나가기 전에 사람 눈을 한 번 거치는 편이 낫다. 그리고 이 방식은 보내는 사람이 그 컴퓨터에 로그인해 있는 담당자 본인이 된다. 인증이 필요 없는 이유가 거기 있고, 원래 그게 맞는 그림이기도 하다.
기준으로 남긴다. 자동화가 막혔을 때 반쪽짜리라고 미루기 전에, 사람이 한 단계 남는 형태가 오히려 제자리인지 본다. 나중의 완벽한 것보다 지금 쓸 수 있는 것이 이길 때가 있다.
남의 제품에 내 것이 새어 들어가는 자리
자동 발송으로 넘어갈 때 인증할 도메인 이야기가 나왔는데, 내 도메인이 후보로 올라와 있었다. 우리가 가진 것이니 인증도 우리가 하면 된다는 이야기였다.
그건 아니다 싶어 되물었다. 신청자가 받는 메일은 그 건물에서 온 메일로 보여야 한다. 발신 주소는 건물 운영사 것이어야 하고 인증도 그쪽 도메인으로 해야 맞다.
여기서 알게 된 게 이번에 제일 큰 수확이었다. 지금까지는 내가 쓸 것을 내 계정에 만들어 왔다. 도메인도 계정도 다 내 것이라 “이건 누구 이름으로 나가는가”라는 질문 자체가 없었다. 남의 것을 만들면 그 질문을 항목마다 해야 한다. 발신 주소, 도메인, 결제 계정, 저작권 표기, 문의 연락처가 전부 그런 자리다.
그리고 사람마다 값이 달라지는 항목은 코드에 박지 않고 설정으로 뺀다. 남에게 넘길 물건이면 처음부터 그렇게 잡는 편이 낫다.
남의 것을 만들어 넘긴다는 것
지금까지 내 것만 만들어 봐서 남에게 넘기는 절차를 아예 몰랐다. 알아보면서 정리한 것들이다.
요금을 누가 내느냐가 나머지를 정한다
납품 방식을 어떻게 잡아야 할지 막막했는데, 질문 하나로 정리됐다. 클라우드 요금이 누구에게 청구되는가.
- 고객 계정에 짓고 고객이 낸다 — 구축비를 받는다
- 우리 계정에서 돌리고 우리가 내고 청구한다 — 월 구독료를 받는다
- 소스만 넘기고 설치는 그쪽이 한다 — 구축비만 받는다
이 하나가 정해지면 계정 명의, 도메인 명의, 유지보수 형태, 받는 돈의 모양이 따라 나온다. 막연히 “어떻게 납품하지”를 굴리는 것보다 이 질문을 먼저 답하는 게 빨랐다.
회의실 예약처럼 고객의 운영 기록이 쌓이는 물건은 고객 계정에 짓는 쪽이 기본이다. 예약 기록이 그쪽 자산이고, 내가 손을 떼도 운영이 이어져야 한다.
계정은 처음부터 고객 명의로
내 계정에 만들어 두고 나중에 옮겨 주는 방법도 있다. 당장은 그게 편하다. 결제 수단 등록이니 도메인 구매니 하는 걸 고객에게 시키지 않아도 되니까.
그런데 이관이 번거로운 것보다 더 걸리는 게 있다. 관계가 틀어졌을 때 “데이터를 붙들고 있다”는 말이 나올 수 있는 구조가 된다. 그럴 생각이 없어도 구조가 그렇게 보이면 그걸로 문제다.
처음부터 고객 명의로 만들고 내가 작업 권한을 받는 쪽으로 정했다. 도메인도 같다. 내가 대신 사더라도 등록자 이름은 고객이어야 한다.
신뢰에 기대야 안전한 구조는 처음부터 만들지 않는다. 지금 사이가 좋아도 구조는 사이가 나빠졌을 때를 기준으로 잡는다.
넘기는 게 아니라 다시 짓는 것
올려 둔 것을 그대로 넘길 수는 없다. D1(데이터베이스)의 id나 R2 버킷 이름처럼 계정마다 달라지는 값이 있어서 고객 계정에서는 어차피 새로 만들어야 하고, 구경용 계정을 지우고 검색 차단을 풀고 데모 데이터를 그 건물의 실제 회의실과 요금으로 바꾸는 것도 그때 함께 한다.
실무적으로 중요한 건 이 작업이 공짜가 아니라는 점이다. “다 만들어 놨으니 넘기기만 하면 된다”고 말해 두면 그 시간이 견적에서 빠진다. 제안 자리에서 이걸 먼저 말해 두기로 했다.
계약에서 다투기 쉬운 지점
미리 꼽아 둔 항목이 넷이다.
- 소스코드 소유권 — 넘기는가 사용권만 주는가. 다른 건물에 재판매할 수 있는지가 여기서 갈린다
- 하자보수 기간 — 검수 후 몇 개월간 무상 수정. 기능 추가는 별도라는 선을 그어 둔다
- 유지보수 계약 — 이게 있어야 납품 후에 관계가 이어진다
- 클라우드 요금 부담 — 금액이 작아도 누가 내는지는 적어 둬야 한다
만들 줄 아는 것과 별개로 따로 배워야 하는 영역이 있다는 걸 알았다.
요약
- 클라우드에는 계정 주인이 직접 눌러야만 넘어가는 관문이 있다. 일정에 미리 꼽아 둔다
- 보여주려면 접근을 내줘야 하는데 내가 쓰는 접근을 그대로 내주면 보여줄 것 자체가 사라진다. 보여주기 위한 권한 등급을 따로 만든다
- 보여줄 목적이 있는 물건에서 제품은 기능이 아니라 그 기능에 닿는 경로까지다. 만든 사람은 경로를 알아서 이 결함을 못 느낀다
- 되돌리기 어려운 쪽으로 실패하는 일은 막을 수단이 둘 있으면 둘 다 쓴다
- 처리가 끝났다는 것과 보기에 완성됐다는 것은 다르다. 완성 보고를 받은 뒤 직접 열어 보는 시간을 일정에 넣는다
- 자동화가 막히면 사람이 한 단계 남는 형태가 오히려 제자리인지 본다. 나중의 완벽한 것보다 지금 쓸 수 있는 것이 이길 때가 있다
- 남의 것을 만들면 “이건 누구 이름으로 나가는가”를 항목마다 묻는다. 사람마다 달라지는 값은 코드가 아니라 설정에 둔다
- 납품 방식은 클라우드 요금을 누가 내느냐가 정한다. 계정 명의도 받는 돈의 모양도 거기서 따라 나온다
- 신뢰에 기대야 안전한 구조는 처음부터 만들지 않는다. 사이가 나빠졌을 때를 기준으로 잡는다
- 데모를 넘기는 게 아니라 고객 계정에 다시 짓는 것이고, 그 시간은 공짜가 아니다