ORIGINAL FICTION
제52화 — 줄을 세우는 법
지난 화 끝부분 다시 보기
고객이 여덟 곳을 넘기자 작업대기열이 보기 싫어졌다.
한 화면에 끝나던 큐가 스크롤을 요구했다.
대니얼은 그 화면을 싫어했다.
기다리는 시간이 눈에 보였기 때문이다.
“용량 늘립시다.”
첫 반응.
운영담당은 예상했다는 듯 말했다.
“어디를요?”
“전부.”
“그런 답 말고요.”
회의실에 웃음.
대니얼도 웃었다.
“좋습니다. 병목부터.”
팀은 실제 데이터를 꺼냈다.
평균 작업시간.
대기시간.
전처리.
가속기.
후처리.
파일 전송.
지원.
대니얼은 가속기 사용률부터 봤다.
의외로 100퍼센트가 아니었다.
70퍼센트 안팎.
“왜 놀고 있습니까?”
“가속기에 맞는 작업이 준비되길 기다립니다.”
“그럼 준비가 병목?”
“일부는요.”
전처리 단계.
고객 파일 확인.
환경 생성.
의존성.
여기에서 사람이 많이 붙었다.
대니얼이 말했다.
“자동화.”
지원담당이 고개를 끄덕였다.
“가장 효과 큽니다.”
A1 때는 하드웨어를 더 빠르게 만들려고 했다.
지금은 사람이 파일을 확인하는 시간을 줄이는 게 더 큰 효과였다.
팀은 작업 입구를 표준화하기 시작했다.
고객이 제출할 때 필요한 정보를 미리 확인.
파일 누락.
버전.
필요 메모리.
예상시간.
보안등급.
처음에는 고객이 싫어했다.
“왜 입력할 게 이렇게 많습니까?”
한 연구원이 불평했다.
Helioxen 지원담당이 설명했다.
“이걸 안 받으면 저희가 전화드려야 합니다.”
“그냥 파일 보면 안 돼요?”
“가능하지만 늦어집니다.”
연구원이 잠깐 생각했다.
“그럼 자동으로 읽을 수 있는 건 자동으로 해주세요.”
또 맞는 말.
Helioxen은 제출폼을 줄였다.
파일에서 읽을 수 있는 건 자동.
사람만 아는 것만 묻는다.
대니얼은 이 과정을 보며 묘하게 즐거웠다.
기술적으로 거대한 건 없었다.
그런데 총 처리시간이 계속 줄었다.
첫 달 평균.
7시간.
두 번째.
5시간 10분.
일부 표준작업은 3시간대.
장비는 거의 그대로.
이선이 말했다.
“이게 네가 좋아하는 기술혁신 맞냐?”
“요즘은 좋아합니다.”
“거짓말.”
“조금은.”
서비스가 커지면서 가격문제도 생겼다.
고객마다 작업크기가 너무 달랐다.
시간당 과금은 단순했지만 불공정해 보일 때가 있었다.
어떤 작업은 CPU를 많이 쓰고.
어떤 작업은 메모리를 먹고.
어떤 작업은 A1을 오래 점유한다.
재무담당이 말했다.
“자원단위 과금해야 합니다.”
대니얼의 눈이 빛났다.
“세분화합시다.”
이선이 바로 말했다.
“너무 복잡하게 하지 마.”
“정확해야죠.”
“고객이 계산서 이해 못 하면 정확한 게 의미 있냐?”
대니얼은 멈췄다.
결국 가격표는 세 단계로 단순화했다.
Standard.
Heavy.
Accelerated.
내부 원가계산은 복잡하게.
외부 가격은 단순하게.
대니얼은 그 차이가 중요하다고 느꼈다.
시스템 내부는 복잡해도.
사용자에게 복잡성을 떠넘길 필요는 없다.
그러던 어느 날.
첫 번째 우선고객이 긴급작업을 넣었다.
“내일 오전까지 필요합니다.”
운영팀이 계산했다.
가능.
서비스 등급을 도입한 뒤 첫 갈등도 생겼다.
한 고객이 일반요금으로 작업을 올린 뒤, 중간에 전화를 걸었다.
“이거 오늘 밤까지 꼭 필요합니다.”
지원담당이 말했다.
“현재 일반대기열 기준으로는 내일 오전입니다.”
“그럼 앞에 있는 거 좀 미뤄주세요.”
“우선서비스로 변경하실 수는 있습니다.”
고객이 불쾌해했다.
“돈 더 내라는 겁니까?”
“다른 고객 일정에 영향을 주기 때문에요.”
전화는 길어졌다.
결국 고객은 우선서비스로 바꾸지 않았다.
작업은 다음날 약속시간 안에 끝났다.
그리고 불만메일이 왔다.
대니얼은 처음에는 가격정책을 완화하려 했다.
“한두 번은 유연하게 해도 되지 않습니까?”
운영담당이 고개를 저었다.
“그러면 누가 가장 많이 전화하느냐가 우선순위가 됩니다.”
대니얼이 멈췄다.
정확했다.
규칙이 있는데 목소리 큰 고객만 예외를 받으면, 조용한 고객이 손해본다.
영업담당도 말했다.
“큰 고객이라고 예외 주기 시작하면 가격표 의미 없어집니다.”
대니얼은 불만메일에 직접 답하지 않았다.
지원팀이 정책을 설명했다.
대신 다음 계약갱신 때 긴급작업이 얼마나 자주 필요한지 물었다.
고객은 생각보다 자주 필요하진 않다고 했다.
결국 월 1회 우선작업이 포함된 새 요금제를 만들었다.
무조건 예외를 주는 게 아니라, 반복되는 필요를 상품구조로 만든다.
대니얼은 그 과정이 마음에 들었다.
불만은 단순히 ‘고객이 까다롭다’는 신호가 아니다.
새로운 수요일 수 있다.
다만 모든 불만을 바로 기능으로 만들면 제품이 복잡해진다.
얼마나 반복되는가.
다른 고객도 원하는가.
돈을 낼 의향이 있는가.
세 가지를 보기로 했다.
그날 서비스 개선목록에서 항목 열두 개가 삭제됐다.
“왜 지웁니까?”
대니얼이 물었다.
제품담당이 말했다.
“한 고객만 한 번 말한 것들입니다.”
“나중에 필요할 수도.”
“그럼 나중에 다시 들어옵니다.”
대니얼은 지워지는 목록을 보며 약간 불안했다.
잊어버리는 것 같아서.
제품담당은 완전히 지우지는 않았다.
`Not now`.
별도 보관.
대니얼이 웃었다.
“그건 마음에 드네요.”
하지 않는 것과 잊는 것은 다르다.
PROJECT 2046에도 그 구분이 필요했다.
지금 안 하는 기술.
절대 안 하는 기술.
나중에 다시 볼 기술.
모든 가능성을 현재 계획에 올려놓으면 우선순위가 무너진다.
서버 작업큐를 줄 세우던 일이 대니얼 자신의 미래계획까지 정리하기 시작했다.
다만 기존 일반작업 두 개가 늦어진다.
서비스 약속 범위 안.
운영담당이 결정을 내렸다.
작업 재배치.
대니얼에게 보고는 했지만 승인 요청은 아니었다.
그는 개입하지 않았다.
다음날.
긴급작업 완료.
일반작업도 약속시간 안.
운영담당이 말했다.
“큐가 시스템이 됐네요.”
대니얼은 그 말을 좋아했다.
줄이 있다고 시스템은 아니다.
누가 먼저 가고.
왜 먼저 가고.
무엇을 약속하고.
실패하면 어떻게 복구하는지.
그게 있어야 시스템이다.
오후에는 예상 못 한 문제가 나왔다.
한 대학 고객이 말했다.
“우리가 급행 안 사면 계속 뒤로 밀리는 거 아닙니까?”
합리적 의심.
운영팀은 통계를 보여줬다.
일반작업도 최대대기시간 보장.
급행이 들어와도 일정 이상은 밀리지 않는다.
“그럼 괜찮네요.”
투명한 규칙.
고객은 받아들였다.
대니얼은 생각했다.
시장도 조직도 비슷하다.
사람들은 항상 자기보다 누군가가 우선되는 것을 싫어하는 게 아니다.
왜 그런지 알고, 자기 약속도 지켜진다는 확신이 있으면 받아들인다.
그건 언젠가 훨씬 큰 자원배분에서 필요할 것이다.
행성방어.
대피.
발사슬롯.
전력.
모든 자원이 부족해질 순간.
그때 순서를 정해야 한다.
공정하게 느껴지는 규칙이 없으면 기술적으로 옳은 결정도 무너질 수 있다.
대니얼은 서비스 가격표 아래 작은 내부 원칙을 적었다.
Priority must be explainable.
이선이 읽고 말했다.
“이제 서버 줄 세우면서 정치 배우네.”
대니얼이 웃었다.
“필요하겠죠.”
“어디에?”
“회사 커지면요.”
이번에는 더 말하지 않았다.
2046년까지 갈수록.
줄을 세워야 할 것은 서버작업만이 아닐 테니까.
가격표를 단순화한 뒤 매출은 오히려 조금 늘었다.
영업담당이 이유를 설명했다.
“고객이 계산을 덜 합니다.”
“우리가 계산회사인데 계산을 덜 한다고요?”
“구매결정을요.”
이전 가격표는 자원단위가 너무 세분화돼 있었다.
고객이 자기 작업이 얼마 나올지 미리 계산해야 했다.
새 가격표는 대략적인 범위만 보면 됐다.
결정시간이 줄었다.
대니얼은 그걸 보고 또 하나 배웠다.
정확한 가격이 항상 좋은 가격은 아니다.
예측 가능한 가격이 더 중요할 수 있다.
고객도 자기 내부예산을 짜야 하니까.
그날부터 Helioxen은 견적 정확도뿐 아니라 견적 이해시간도 보기 시작했다.
테스트 고객에게 가격표를 보여주고 물었다.
“몇 분 안에 이해됐습니까?”
처음엔 다들 이상하게 봤다.
그래도 측정했다.
한 고객.
12분.
새 표.
4분.
대니얼은 웃었다.
“이것도 성능이네요.”
영업담당이 말했다.
“대표님 드디어 영업 성능도 인정하시네요.”
서비스가 커질수록 대니얼이 말하는 ‘성능’의 범위도 넓어졌다.
처리속도.
복구속도.
설치시간.
가격이해.
지원응답.
제품의 성능은 칩 하나가 아니라 고객이 겪는 전체 시스템의 속도였다.
읽은 화로 기록했습니다. 다음 화는 바로 이어집니다.