BuildingHub TIL 3
미뤄 둔 것들을 처리한 날의 판단이다. 넷으로 묶인다. 제약을 만났을 때 어디를 보는가, 보여주는 것이 사실과 달라질 때, 부수 기능이 본 기능을 잡아먹지 않게 하는 선, 그리고 기준을 하나로 두는 문제.
제약을 만났을 때 어디를 보나
서버가 못 하면 브라우저에 시킨다
관리자가 올린 사진을 원본 그대로 저장하고 있었다. 4000×3000짜리를 올리면 그대로 들어간다. 서버 쪽에서 줄이려니 막혔다. 이 서버는 Cloudflare Workers라는 가벼운 실행 환경에서 도는데 거기엔 이미지를 열어 볼 수단(디코더) 자체가 없고, Cloudflare가 파는 이미지 변환 기능(Cloudflare Images)은 돈을 더 내야 하는 부가 상품이었다.
여기서 바로 지갑을 여는 대신 질문을 바꿨다. “서버에서 어떻게 줄이나”가 아니라 “이 일을 할 수 있는 데가 서버 말고 또 있나”. 브라우저에는 캔버스(canvas) — 그림을 그려 놓고 그걸 다시 이미지 파일로 뽑아낼 수 있는 요소 — 가 원래 들어 있다. 관리자 화면에서 올리기 직전에 줄이게 하니 273KB짜리가 11KB로 들어갔다.
덤이 하나 더 붙었다. 서버에서 줄였다면 큰 원본을 일단 다 올린 뒤에 줄였을 텐데, 이 방식은 원본이 아예 네트워크를 타지 않는다. 제약을 우회한 결과가 원래 방식보다 나은 경우가 있다.
대신 계산에 넣을 게 있다. 클라이언트가 하는 일은 클라이언트를 믿는 만큼만 안전하다. 크기를 줄여 보내니 서버는 그 이미지를 열어 볼 수단이 없어서 가로·세로 값도 클라이언트가 알려 주는 걸 받는다. 그래서 검증까지 클라이언트에 넘기지는 않았다. 편의는 넘기고 판정은 안 넘긴다.
예외도 정해 뒀다. 벡터 이미지는 건드리지 않고, 변환 결과가 원본보다 크면 원본을 쓴다. 최적화라고 붙인 게 손해를 보는 경우를 막는 안전장치는 최적화와 세트다.
보여주는 것이 사실과 달라질 때
축약은 괜찮고 축약을 숨기는 게 문제다
대회의실은 154석이다. 좌석을 154개 다 찍으면 화면이 검게 뭉쳐서 정작 “어떤 배치인가”가 안 읽힌다. 형태가 보일 만큼만 그리는 게 맞다.
그런데 “154석 기준”이라고 써 놓고 70개만 그리면 그림이 거짓말을 한다. 보는 사람은 그림을 세어 보지 않고 캡션을 믿는다. 그래서 그린 수와 실제 수가 다르면 캡션이 그 사실을 밝히게 했다.
이건 도면에만 해당하는 얘기가 아니다. 제안 자료·요약·데모 화면은 전부 축약이다. 축약 자체는 필요하고 정직하다. 문제는 축약했다는 사실이 안 보일 때 생긴다. 보여주는 것이 실제와 다르면 그 차이를 같은 화면에 적는다.
있어야 할 것이 없는 상태는 눈으로 못 잡는다
배치도의 라벨 하나가 흰 바탕에 흰 글씨로 얹혀 안 보였다. 화면에서는 그냥 빈 자리로 보인다.
잘못 그려진 것은 눈에 띄는데 안 그려진 것은 안 띈다. 뭔가 틀리면 “어색하다”는 신호가 오지만, 없는 건 애초에 시선을 안 끈다. 그래서 빠짐은 사람 검수로 잡기 제일 어려운 종류다.
이런 건 사람이 아니라 기계가 보게 해야 한다. 글자 색이 배경색과 같은지 같은 건 재면 바로 나온다.
부수 기능이 본 기능을 인질로 잡지 않게
기록은 운영을 돕는 장치이지 운영의 조건이 아니다
관리자 조작 이력을 남기기로 하면서 정해야 할 게 있었다. 기록이 실패하면 그 조작도 같이 실패하게 둘 것인가.
이력 테이블에 문제가 생겼다고 회의실 예약 승인이 막히면 곤란하다. 이력은 나중에 “누가 이걸 승인했나”를 답하려고 있는 것이지, 승인 자체를 위해 있는 게 아니다. 기록 실패는 삼키고 본 작업은 통과시켰다.
일반화하면 이렇다. 부수 기능을 붙일 때 “이게 고장 나면 본 기능이 멈추는가”를 반드시 묻는다. 로깅·통계·알림처럼 도우려고 붙인 것이 본 기능을 인질로 잡는 구조는 의외로 쉽게 만들어진다.
무엇을 남길지도 판단이었다. 사람이 한 행위만 남기고 조회는 남기지 않았다. 조회까지 남기면 표가 금세 불어나고, 정작 찾고 싶은 게 그 안에 묻힌다. 다 남기는 건 안 남기는 것과 비슷한 결과를 낸다.
추측이 어려운 것은 잠금이 아니다
사업자등록증 첨부를 어떻게 지킬지 정해야 했다. 파일 이름이 내용의 SHA-256 해시라 추측은 사실상 불가능하다. 그것만 믿고 열어 둘 수도 있었다.
그런데 추측이 어려운 것과 막힌 것은 다르다. 주소가 한 번 새면 그대로 끝이고, 새는 경로는 많다. 링크를 붙여 넣거나, 화면을 공유하거나, 브라우저 기록이 넘어가거나.
판단 기준을 이렇게 잡았다. 이 자산이 새면 곤란한가. 곤란하면 확인을 건다. 담당자이거나, 예약번호와 연락처가 함께 맞아야 열리게 했다.
같이 알게 된 게 하나 더 있다. 공개 자산에는 캐시를 최대한 길게 걸었는데 비공개 자산에는 아예 안 걸었다. 권한이 나중에 바뀌어도 브라우저에 남아 있으면 곤란해서다. 같은 저장소를 쓰더라도 공개와 비공개는 캐시 정책이 정반대다.
기준은 하나로 두고 표시에서 갈라진다
아홉 시간이 어긋난 이유
이력 화면의 시각이 실제보다 아홉 시간 이르게 보였다. 저장은 세계 표준시로 되고 있었는데 그대로 화면에 뿌린 것이다.
고치는 길이 둘이었다. 저장을 우리 시간대로 바꾸거나, 저장은 두고 보여줄 때 바꾸거나. 앞엣것이 당장은 간단해 보이는데, 표시 기준이 하나 더 생기는 순간 저장까지 손봐야 한다. 기준이 여럿일 수 있는 건 표시 쪽이고 저장은 하나여야 한다.
날짜·통화·단위처럼 지역마다 다른 값은 전부 같은 모양이다. 하나의 기준으로 담고 보여주는 자리에서 갈라진다.
검사끼리도 자원을 다툰다
첨부 검사가 실패했는데 첨부와 무관한 이유였다. 앞선 검사가 이미 그 회의실의 그 시간대를 잡고 있었다. 중복 차단이 정상 동작한 것이고, 검사가 자리를 잘못 고른 것이다.
검사끼리 부딪히는 방식이 이제 셋이 됐다. 지난번 실행이 남긴 데이터에 걸리거나, 돌리는 요일에 걸리거나, 같은 실행 안에서 앞뒤 검사가 같은 자리를 잡거나. 검사가 늘어날수록 검사 묶음 자체가 서로 영향을 주고받는 하나의 시스템이 된다.
그래서 새 검사가 왜 그 자리를 골랐는지를 주석으로 남겼다. 안 적으면 다음에 같은 자리를 또 고른다. 이유가 안 적힌 선택은 반복해서 다시 발견된다.
요약
- 제약을 만나면 돈으로 풀기 전에 “이 일을 할 수 있는 데가 여기 말고 또 있나”를 먼저 본다. 우회한 결과가 원래 방식보다 나은 경우가 있다
- 편의는 클라이언트에 넘기고 판정은 넘기지 않는다
- 최적화가 손해를 보는 경우를 막는 안전장치는 최적화와 세트다
- 축약은 정직하고 필요하다. 축약했다는 사실이 안 보일 때만 문제가 된다
- 잘못 그려진 것은 눈에 띄고 안 그려진 것은 안 띈다. 빠짐은 사람 검수로 잡기 제일 어렵다
- 부수 기능을 붙일 때 “이게 고장 나면 본 기능이 멈추는가”를 묻는다
- 다 남기는 건 안 남기는 것과 비슷한 결과를 낸다. 찾고 싶은 게 묻힌다
- 추측이 어려운 것은 잠금이 아니다. 새면 곤란한 자산에는 확인을 건다
- 공개 자산과 비공개 자산은 캐시 정책이 정반대다
- 기준이 여럿일 수 있는 건 표시 쪽이고 저장은 하나여야 한다
- 검사가 늘어날수록 검사 묶음 자체가 서로 영향을 주고받는 시스템이 된다
- 이유가 안 적힌 선택은 반복해서 다시 발견된다