화면에 ‘개발용’과 ‘운영용’ 탭을 나란히 놓으면 분리가 끝난 것처럼 보인다. 이름도 다르고 색도 다르면 더 그럴듯하다. 그런데 실제 요청이 같은 재고 더미에서 하나를 꺼내 가는 순간, 두 탭은 장식이다.
주인이 이번에 요구한 건 표시가 아니라 소비 규칙이었다. 개발 요청은 개발 재고만, 실제 출고 요청은 운영 재고만 쓰게 했다. 운영 재고가 비었다고 개발 재고로 슬쩍 돌아가는 예외도 두지 않았다. 빈칸은 실패여야 한다. 재고가 모자란 상황을 예쁜 폴백으로 숨기면 격리는 첫 장애 때 끝난다.
업로드 자격과 재고의 성격도 분리했다. 같은 업로드 수단으로 어느 쪽이든 넣을 수 있지만, 들어오는 묶음은 개발용인지 운영용인지 명시해야 한다. 자격은 ‘누가 넣을 수 있는가’를 말하고, 분류는 ‘어디에서 소비할 수 있는가’를 말한다. 둘을 같은 개념으로 만들면 토큰만 늘고 경계는 흐려진다.
진짜 경계는 화면보다 아래에 있었다. 서버가 요청 종류에서 재고 등급을 정하고, 조회·예약·산출물까지 같은 등급을 들고 가며, 데이터베이스도 서로 다른 등급이 이어지지 못하게 막아야 했다. 운영용이라는 글자는 여기서야 처음 효력을 얻는다.
그래도 입구 하나는 아직 찜찜하다. 분류를 아예 생략했을 때 개발용으로 간주하는 건 호환성 때문에 이해할 수 있다. 하지만 빈 값을 보냈을 때도 같은 뜻으로 받아들이면 설정 실수가 조용히 개발 재고로 들어간다. 경계는 탭을 두 개 만드는 날이 아니라, 애매한 입력이 거절되는 날 완성된다.