온실 GreenHouse TIL 2
온실을 실제 주소에 올리고, 그 주소를 앱에 박고, 배너 열한 장을 채운 날. 만드는 것보다 “무엇을 나중에 바꿀 수 있고 무엇을 못 바꾸는가”를 가르는 일이 더 많았다.
되돌릴 수 있는 선택으로 시작한다
사이트 첫 주소로 들어가면 아무것도 없어서 오류 화면이 떴다. 이 사이트에서 실제로 쓰는 건 편집기 한 페이지뿐이라 첫 주소로 온 사람을 그리로 보내기로 했다.
그런데 이런 안내에는 영구와 임시 두 가지가 있다. 영구라고 표시하면 방문자 브라우저가 그 사실을 기억해 버려서, 나중에 첫 주소에 진짜 페이지를 만들어도 한 번 왔던 사람은 계속 딴 데로 간다. 임시로 두면 올 때마다 다시 물어보니 언제든 바꿀 수 있다.
지금은 편집기밖에 없지만 나중에 이 자리에 소개 페이지가 생길 수도 있다. 그래서 임시를 골랐다.
여기서 가져갈 건 리다이렉트 지식이 아니라 고르는 기준이다. 되돌리기 비용이 다른 선택지가 둘 있고 아직 확신이 없으면, 되돌릴 수 있는 쪽으로 시작한다. 영구는 진짜로 다시 안 바꿀 때만 고른다.
한 번 정하면 못 바꾸는 것을 먼저 꼽아 둔다
광고 목록이 있는 주소는 앱 안에 박힌다. 이미 설치된 앱은 그 주소만 보고, 다른 데를 볼 줄 모른다.
그래서 이 주소는 나중에 마음에 안 들어도 못 바꾼다. 바꾸려면 그 주소를 쓰는 앱을 전부 다시 만들어 배포하고 사용자가 업데이트할 때까지 기다려야 한다. 이건 설정이 아니라 계약에 가깝다.
프로젝트를 시작할 때 이런 항목을 먼저 꼽아 두니 속도가 붙었다. 못 바꾸는 것은 몇 개 안 되고 거기에만 시간을 들이면 되니까, 나머지는 빨리 정하고 나중에 고쳐도 된다. 반대로 이걸 안 가려 놓으면 모든 결정이 똑같이 무겁게 느껴져서 아무것도 못 정한다.
이번에 계약으로 분류한 건 배포 주소 하나였다. 배너 크기나 광고 문구, 도는 순서는 전부 나중에 바꿀 수 있는 쪽이라 일단 정하고 넘어갔다.
배포는 스위치가 아니라 물결이다
올리자마자 확인했더니 새 내용이 보였다 안 보였다 했다. 같은 주소를 새로고침하는데 어떤 때는 옛날 게 오고 어떤 때는 새것이 왔다.
사이트가 세계 곳곳의 서버에 복사돼 서비스되기 때문이다. 새로 올린 게 그 서버들에 닿는 시점이 조금씩 다르니, 몇 분 동안은 어느 서버가 응답하느냐에 따라 신구가 섞인다.
이걸 모르면 확인 결과를 두 방향으로 오해한다. 옛것을 보고 “배포가 실패했나” 하거나, 우연히 새것을 보고 “다 됐네” 하고 넘어간다. 두 번째가 더 위험하다 — 다 됐다고 알린 뒤에 남이 옛 화면을 볼 수 있다.
그래서 완료 기준을 바꿨다. 한 번 새것이 보이는 걸로는 끝이 아니고, 여러 번 연속으로 새것만 나올 때까지 기다린 뒤에야 됐다고 말한다. 여러 곳에 퍼져 있는 시스템에서는 “됐다”의 기준을 한 번의 성공이 아니라 연속된 성공으로 잡아야 한다.
여러 벌 만들어야 하면 만드는 법을 먼저 만든다
광고마다 배너 그림이 필요했다. 처음 세 장을 만들고 나란히 놓아 보니 배경이 다 같은 초록이라 어느 앱 배너인지 구분이 안 갔다. 앱마다 다른 색으로 갈아야 했다.
이때 배너를 그림 편집 프로그램에서 그렸다면 열한 장을 손으로 다시 칠해야 한다. 대신 배너를 작은 웹페이지로 만들고 그 화면을 사진 찍듯 저장하는 방식을 썼다. 그러니 색과 문구가 값 하나 바꾸는 일이 되고, 열한 장을 한 번에 다시 뽑는 것도 금방이었다.
물론 정교한 그래픽은 이렇게 못 만든다. 글자와 아이콘, 배경색 정도로 충분한 자리에만 쓸 수 있다.
일반화하면 이렇다. 같은 것을 여러 벌 만들어야 하는 일이 보이면 결과물을 만들기 전에 만드는 법부터 만든다. 한두 장이면 손으로 하는 게 빠르지만, 다시 만들 일이 생기는 순간 손으로 한 것은 전부 다시 손으로 해야 한다.
규약을 문서로 주면 질문이 오고, 코드로 주면 안 온다
처음에는 “이런 규칙으로 광고를 그려 달라”를 문서로 써서 앱 쪽에 넘겼다. 광고를 어떤 조건으로 걸러내고 몇 초마다 바꾸고 어떻게 그리는지를 적은 규약이다.
그랬더니 앱 쪽에서 되물어 왔다. 몇 초마다 바꾸나, 카드 위에 브랜드 이름을 붙이나, 실행할 때만 받아오나 계속 받아오나. 규칙을 문서로 주면 그걸 읽고 구현하는 쪽마다 같은 질문이 생긴다. 앱이 늘어날수록 같은 질문을 반복해서 받고, 앱마다 조금씩 다르게 구현될 여지도 남는다.
방식을 바꿨다. 카카오나 구글 광고가 하는 것처럼, 규칙이 다 들어 있는 코드 조각을 우리가 서비스하고 앱은 그걸 불러다 쓰기만 하게 했다. 앱이 하는 일은 광고를 놓을 자리를 알려 주고 링크를 열 방법을 넘기는 것, 두 줄이 전부다.
<script src="https://kimlog-greenhouse.pages.dev/houseAd.js"></script>
<script>
HouseAd.init({ el: "#adBox", platform: "native", open: openUrl });
</script>질문이 사라졌다. 답이 코드 안에 있으니 물어볼 게 없다. 몇 초마다 바꿀지를 나중에 고치고 싶으면 우리 쪽만 바꾸면 되고, 앱은 다시 만들지 않아도 다음 실행부터 바뀐 규칙으로 돈다.
대신 주는 쪽에 의무가 두 개 생겼다.
하나는 하위호환이 계약이 된다는 것이다. 앱은 다시 만들지 않고 새 코드를 받으므로, 부르는 방식을 바꾸면 남의 앱이 그날로 깨진다. 이제 부르는 방식은 늘릴 수만 있고 바꾸거나 뺄 수는 없다.
다른 하나는 계정 보안이 곧 앱 보안이 된다는 것이다. 이 주소를 쥔 사람은 그 코드를 받아 가는 모든 앱 안에서 코드를 실행시킬 수 있다. 광고 데이터만 주던 때보다 맡기는 게 커졌다. 그래서 실질적인 방어선은 코드에 무엇을 넣느냐가 아니라 계정에 2단계 인증이 걸려 있느냐다.
남에게 규칙을 지키게 해야 할 때 문서로 부탁할지 코드로 대신 해 줄지는 이렇게 갈랐다. 지킬 곳이 하나면 문서로 충분하고, 늘어날 것 같으면 코드로 준다. 대신 코드로 주는 순간 그 코드는 남의 물건 안에서 도는 것이라 함부로 못 바꾼다.
앱에 붙이는 쪽에서 배운 것은 소리꽃 KeyBloom TIL 14에 따로 있다.