자리를 물려줬더니 이름표가 안 따라왔다

기계 하나가 은퇴하고 새 기계가 그 자리를 물려받았다. 자리에는 이름이 있고, 봇이 있고, 권한이 있다. 설정 파일에서 한 줄을 바꾸면 승계가 끝나는 줄 알았다.

승계는 한 줄이었다

낡은 노트북 한 대를 정리했다. 팀에는 그 기계가 앉아 있던 자리가 있고, 자리에는 이름과 역할이 붙어 있다. 새로 산 노트북을 그 자리에 앉혔다.

라우팅 설정에서 그 자리의 상태를 ‘은퇴’에서 ‘현역’으로 바꾸고, 어느 기계가 앉아 있는지를 갱신했다. 커밋 하나. 끝.

그날부터 나흘에 걸쳐 청구서가 날아왔다.

다음 날 아침, 배차 스크립트가 이상하게 굴었다. 스크립트에는 “자기 자신한테 지시를 보내지 마라”는 안전장치가 있는데, 이 장치가 기계 이름을 보고 판단한다.

새 노트북의 기계 이름이 하필 사령탑과 같은 계열이었다. 둘 다 맥북이니까. 안전장치가 넓은 패턴으로 걸러내고 있어서 새 노트북까지 사령탑으로 잡혔다.

패턴을 좁혀서 고쳤다. 같은 날, 그 자리가 ‘은퇴 상태’라고 적혀 있던 테스트들도 줄줄이 어긋난 걸 발견해서 함께 고쳤다.

며칠 뒤, 작업 기록을 모으는 절차에서 이 자리의 기록이 통째로 빠져 있는 게 발견됐다.

문서에 이렇게 적혀 있었다. 이 노드는 은퇴 전 세션 아카이브 — 과거 날짜에만 포함.

틀린 문장은 아니었다. 옛 하드웨어의 은퇴는 사실이다. 다만 그 문장이 하드웨어의 은퇴와 자리의 은퇴를 한 덩어리로 뭉개고 있었고, 자리는 이미 승계돼 현역이었다. 그래서 승계 이후 이 기계가 한 모든 일이 기록에서 사라지고 있었다.

능력 기반으로 일을 나누는 표가 있다. 어떤 자리는 어떤 종류의 작업을 못 한다고 적혀 있다.

그 표에서 이 자리는 앱 개발 계열 작업이 제외돼 있었다. 옛 윈도우 노트북 기준으로는 맞는 이야기였다. 그런데 지금 그 자리에 앉은 건 맥북이고, 앱 개발이 오히려 주력이다.

그리고 오늘, 같은 뿌리에서 가장 큰 게 나왔다.

자격증명을 나눠주는 창고가 있다. 기계마다 다른 열쇠를 줘야 하니까 기계 이름으로 구분한다. 그 구분표에 새 노트북이 없었다. 자리는 물려받았지만 기계 이름은 물려받지 않으니까.

표에 없으면 어떻게 되나. 코드 주석에 친절히 적혀 있었다. 매칭 안 되면 기본값 그대로 사용. 그리고 그 기본값이 사령탑의 열쇠였다.

여기서 끝났으면 이름표 문제다. 그런데 자기 소개 스크립트가 그 열쇠의 봇 이름을 읽고 “나는 사령탑”이라고 답했고, 지시 권한을 검사하는 게이트가 그 답을 믿었다.

워커 한 대가 사령탑의 권한을 갖고 있었다. 직접 재보니 지시 대상 셋 다 허용이 떨어졌다. 다른 세 대는 열다섯 번 다 정상적으로 거부.

여기가 이 이야기의 핵심이다.

네 사건 모두 각각 발견돼서 각각 고쳐졌다. 배차 가드를 고치고, 문서를 고치고, 라우팅 표를 고치고, 오늘 자격증명 분배표를 고쳤다. 네 번 다 “아 이것도 있었네” 하면서.

같은 실패 계열이라는 걸 알아본 건 세 번째쯤이었다. 그때 티켓을 하나 냈다 — “승계 시 따라오지 않는 노드 전제” 스윕 게이트. 자리를 옮길 때, 그 자리를 언급하는 모든 코드를 기계적으로 찾아내는 장치.

그 티켓은 아직 대기 중이다. 그리고 대기하는 동안 네 번째가 터졌다.

자리와 기계는 다른 것이다. 자리를 옮기는 건 설정 한 줄이지만, 그 자리를 언급하는 코드는 저장소 전체에 흩어져 있다. 하드코딩된 전제는 승계를 따라오지 않는다.

그리고 “매칭 안 되면 기본값” 은 그 기본값이 무엇이냐에 따라 등급이 완전히 달라진다. 기본값이 빈 값이면 조용한 실패고, 기본값이 가장 권한이 센 대상이면 보안 구멍이다. 이번 건은 후자였다.

마지막으로 — 같은 계열 사고가 세 번 났을 때 스윕 게이트 티켓을 낸 건 맞는 판단이었다. 다만 그 티켓을 대기열에 넣어둔 것이 틀렸다. 세 번 반복된 실패 계열은 네 번째가 오기 전에 닫아야 했다.

이름표는 자리에 붙어 있지만, 코드는 기계를 보고 있었다.

— 강대종 / @ssamssae