핫리로드가 결제된 작업을 세 번 중단시켰고, 고친 것은 코드가 아니었습니다

자사 영상 콘텐츠 프로젝트의 제작 도구를 만들면서, 첫 편을 실제로 뽑아 보는 날이었습니다. 이 도구는 외부 생성 모델에 그림·영상·목소리를 주문하고 결과를 기다리는 구조입니다. 작업 하나가 수십 초에서 수 분씩 걸리고, 그 주문은 보내는 순간 돈이 나갑니다.

개발 서버는 핫리로드(파일을 저장하면 서버가 알아서 다시 뜨는 개발 모드)로 띄워 뒀습니다. 도구를 하루 종일 고치는 날에는 당연한 선택입니다. 문제는 그 서버가 동시에 유료 작업을 돌리는 서버이기도 했다는 점입니다.

기다리는 김에 코드를 고쳤습니다

그날의 순서는 단순했습니다. 작업을 하나 보내고, 외부 모델이 그림을 그리는 동안 화면은 기다립니다. 기다리는 김에 방금 눈에 걸린 것을 고치고 파일을 저장합니다. 서버가 자동으로 다시 뜨고, 돌던 작업은 같이 멈춥니다.

같은 일이 하루에 세 번 났습니다. 멈춘 작업의 진행분은 21초 · 1분 36초 · 1분 36초였습니다. 세 번째 건은 영상 앞부분 프레임 값 0.03달러가 이미 결제된 뒤였습니다. 액수는 작지만 되돌아오지는 않습니다.

기록에 남은 종료 사유는 '서버 종료' 한 줄뿐이었습니다. 왜 서버가 종료됐는지는 적히지 않습니다. 제가 저장 한 번으로 만든 종료와 장애로 인한 종료가 같은 문구로 남으니, 기록만 보고는 세 번이 한 가지 패턴이라는 걸 알아볼 수 없었습니다. 세 번째에야 눈에 들어왔습니다.

작업 길이가 편집 간격과 겹칩니다

이 일이 세 번이나 가능했던 이유는 작업 길이에 있었습니다. 이 도구의 실측 길이는 아래와 같습니다.

사람이 코드 한 군데를 고치고 저장하는 간격이 대체로 이 구간 안에 들어옵니다. 즉 '지금은 안 돌고 있겠지'가 틀릴 확률이 상당히 높습니다. 밀리초짜리 요청만 도는 서버라면 같은 설정이 그냥 이득입니다.

덧붙이면, 이건 테스트가 잡아 주는 종류의 문제가 아닙니다. 같은 날 자동 테스트는 플러그인 265·266건, 서버 137·127건, 웹 225·238건이 전부 통과했습니다. 코드는 맞게 동작했고, 틀린 것은 제가 그 코드를 고친 시점이었습니다.

해결 후보는 셋이었습니다

셋째 줄(순서)을 택했습니다. '서버 코드를 고치기 전에 잡 큐를 본다'를 도구의 메모리에 규칙으로 남겼습니다. 사람 머리에만 두면 그날로 사라지는 종류의 규칙이라, 남기는 자리가 선택의 절반입니다.

화면도 같은 처방을 받았습니다

같은 날 화면 쪽에도 성격이 같은 고침이 하나 들어갔습니다. 두 화면이 서로 다른 것을 보고 있어서, 한 화면은 '그림 만드는 중'인데 다른 화면에는 '그림 만들기' 단추가 떠 있었습니다. 같은 것을 두 번 사는 자리입니다.

고친 방식은 사람 쪽과 다르지 않았습니다. 두 화면이 같은 원천인 잡 큐를 보게 바꿨습니다. 사람도 화면도 처방이 하나였습니다. 무엇이 지금 돌고 있는지를 보고 나서 움직입니다.

기다리는 동안 화면이 조용했던 것도 같이 고쳤습니다. 폴링이 1분마다 '기다리는 중 N분'을 남기고, 작업은 요청을 보내기 전에도 한 줄을 남깁니다. 중단됐을 때 요청이 나갔는지 안 나갔는지를 가리기 위해서입니다. 돈이 나가는 작업에서는 이 한 줄이 나중에 가장 비싼 기록이 됩니다.

편의 설정을 다시 보는 기준

핫리로드·파일 감시·자동 포맷·자동 커밋 훅은 전부 내 손을 덜자고 켠 것입니다. 이것들이 편한 이유는 제가 명령하지 않아도 움직이기 때문이고, 돌던 작업을 멈추는 이유도 똑같습니다. 그래서 기준을 설정 자체가 아니라 그 프로세스가 무엇을 들고 있는지에 둡니다.

순수한 웹 서버라면 재시작은 공짜에 가깝습니다. 같은 프로세스가 결제·전송·배포·배치를 들고 있으면 재시작은 공짜가 아닙니다

되돌릴 수 없는 행위를 하는 작업은 요청을 보내기 전에 한 줄을 남깁니다. 중단된 뒤에 나갔는지 안 나갔는지를 판단할 근거가 그것뿐입니다

종료 기록에 '서버 종료'만 남는다면 그건 사유가 아니라 증상입니다. 사람이 만든 종료와 장애로 인한 종료가 같은 문구면 다음에 같은 일을 또 합니다

처방을 고를 때 코드가 첫 후보일 필요는 없습니다. 대신 그 순서는 사람 머리가 아니라 기록에 남겨야 다음에도 삽니다

점검 항목

개발 편의 설정이 켜진 프로세스가 결제·발송·배포 중 하나라도 들고 있는지 확인합니다

그 프로세스가 돌리는 작업 한 건의 실측 길이를 적어 둡니다. 사람의 편집 간격과 겹치는 길이인지가 갈림선입니다

되돌릴 수 없는 작업의 로그가 요청을 보내기 전에 한 줄 남는지 확인합니다

종료·실패 기록에 사유가 구분돼 남는지 봅니다. 한 문구로 뭉쳐 있으면 같은 사고를 다시 덮습니다

규칙으로 풀기로 했다면 그 규칙이 사람 머리 밖 어딘가에 적혀 있는지 확인합니다

이 이야기가 성립하지 않는 자리

작업이 짧으면 이 이야기는 성립하지 않습니다. 돈이 걸리지 않으면 체감도 다릅니다. 무료 작업이라면 세 번 멈춰도 다시 돌리면 되는 일이고, 실제로 그게 합리적입니다. 이 사건이 규칙까지 간 이유는 결제가 되돌아오지 않아서입니다.

그리고 순서 규칙은 사람이 지켜야 삽니다. 기록에 남겼다고 안 깨지는 것은 아닙니다. 같은 일이 네 번째로 나면 그때는 작업이 도는 동안 재시작을 미루는 장치로 올라가는 것이 맞습니다. 규칙은 싸고, 장치는 확실합니다.

여러 사람이 쓰는 개발 서버라면 애초에 순서로 풀 수 없습니다. 남의 작업이 도는지는 제 편집 습관으로 알 수 없기 때문입니다. 1인 개발이라 순서가 통했고, 사람이 둘만 돼도 이 선택은 바뀝니다.