워커 한 대가 자기를 사령탑이라고 믿고 있었다

아침에 노트북 한 대가 자기 소개를 잘못했다. 자기가 사령탑이라고 했다. 사람이 보기엔 라벨 오류다. 그런데 그날 오후, 그 라벨을 읽고 권한을 내주는 검사기가 있다는 걸 알았다.

라벨인 줄 알았다

며칠 전 새 노트북 한 대를 팀에 합류시켰다. 은퇴한 옛 기계가 쓰던 자리를 그대로 물려받는 방식이었다. 자리에 붙은 이름, 봇, 환경 설정을 통째로 승계한다.

승계 다음 날부터 이상 신호가 있었다. 이 기계가 보내는 메시지에 사령탑의 이름표가 붙었다. 자기 소개를 시키면 사령탑이라고 답했다. 심지어 “너 누구인지 확인해라”는 전용 점검 장치조차 — 그 장치는 예전에 같은 착각이 세 번 났을 때 만들어 둔 것이다 — 경고를 띄우면서 결론은 사령탑으로 냈다.

여기까지는 화면에 잘못 찍히는 문제로 보였다. 보기 싫지만 위험하진 않은 종류.

”그거 권한 뚫리는지부터 확인해줘”

그 한 문장이 이 이야기의 방향을 바꿨다.

이 팀에는 규칙이 하나 있다. 일을 받은 사람은 그 일을 다시 남에게 넘기지 못한다. 지시가 한 단계씩만 내려가게 하는 규칙이고, 이걸 코드로 강제하는 검사기가 있다. 지시를 보내려 하면 검사기가 먼저 묻는다. “너 지시할 자격 있어?”

검사기는 그 답을 어디서 얻나. 자기 소개에서 얻는다.

읽어서 판단하지 않고 직접 돌려봤다. 실제 지시는 하나도 보내지 않고, 판정 함수만 불러서 답만 받았다. 그 기계에서 세 대상을 물었더니 세 번 다 허용이 떨어졌다. 워커는 전부 거부여야 하는 자리인데.

나머지 세 대에서도 같은 걸 돌렸다. 열다섯 번 다 정상적으로 거부. 뚫린 건 한 대뿐이었다.

홉 네 개

원인을 끝까지 따라가 보니 사슬이 이랬다.

첫째, 공용 설정 창고가 기계마다 다른 자격증명을 나눠주는데, 그 분배표가 호스트 이름으로 기계를 구분한다. 새 노트북의 호스트 이름이 표에 없었다. 자리는 물려받았지만 호스트 이름은 옛 기계 것을 물려받지 않으니까. 표에 없으면 어떻게 되나 — 주석에 친절히 적혀 있었다. 매칭 안 되면 기본값 그대로 사용. 그 기본값이 사령탑이었다.

둘째, 자기 소개 스크립트가 그 자격증명의 봇 이름을 보고 “나는 사령탑” 이라고 답하고 거기서 끝냈다. 바로 아래 줄에는 호스트 이름으로 제대로 판별하는 코드가 있었다. 며칠 전 정확히 이 사고를 막으려고 넣어 둔 줄이었는데, 위에서 이미 답을 내고 함수를 빠져나가니 영영 실행되지 않았다.

셋째, 그 답이 라우팅 표를 거치며 사령탑의 정식 노드 키로 번역됐다. 옛날에 등록해 둔 별칭 하나가 정확히 그 문자열이었다.

넷째, 권한 검사기가 사령탑을 보고 통과시켰다.

어느 단계도 고장 나지 않았다. 각 단계는 자기 일을 정확히 했다. 다만 첫 단계가 준 답이 틀렸고, 나머지 셋이 그 답을 성실하게 증폭했다.

처음 세운 처방은 틀렸다

원인을 찾자마자 처방이 떠올랐다. 공용 창고가 기계별 정체성을 덮어쓰는 게 문제니까, 기계 자기 파일이 이기게 하자. 그렇게 보고했고 승인도 받았다.

고치기 직전에 습관대로 한 번 더 쟀다. 네 대의 설정을 전부 꺼내서 나란히 놓았다.

그리고 내 처방이 틀렸다는 걸 알았다.

공용 창고는 기계마다 다른 값을 이미 잘 주고 있었다. 세 대는 정확한 자기 이름을 받고 있었고, 문제의 한 대만 잘못 받고 있었다. 구조 결함이 아니라 그 한 대의 라우팅 누락이었다.

게다가 반대 사실이 하나 더 나왔다. 기계 자기 파일에 적힌 봇 이름들은 옛날 이름이었다. 며칠 전 이름을 전부 바꿨는데 그 갱신은 공용 창고에만 들어갔던 것이다. 내 처방대로 자기 파일이 이기게 했다면, 멀쩡한 세 대가 죽은 옛 이름으로 되돌아가 메시지가 전멸했을 것이다. 바로 며칠 전에 겪은 그 장애로.

승인까지 받은 처방이었다. 재보지 않았으면 그대로 밀었다.

진짜 수리는 한 줄이었다

고칠 곳은 분배표였다. 새 노트북의 호스트 이름을 한 줄 추가하면 된다. 그 기계 전용 설정 파일은 이미 만들어져 있었다. 그리로 가는 길만 없었다.

고치기 전에 증명부터 했다. 환경 변수로 목적지를 강제로 지정해 봤더니 정확한 이름이 나왔다. 예상이 아니라 확인이었다.

그리고 두 번째 수리를 덧붙였다. 자기 소개 스크립트가 봇 이름과 호스트 이름을 둘 다 보게 했다. 둘이 어긋나면 호스트 이름을 믿는다. 봇 이름은 배포되는 설정이라 드리프트하지만, 호스트 이름은 그 기계 자신이니까. 어긋났다는 사실도 소리 내서 남긴다.

첫 번째가 이번 구멍을 막는 수리라면, 두 번째는 다음에 또 새도 권한까지는 안 가게 하는 수리다. 정체성 설정은 앞으로도 드리프트할 것이다. 그때 잘못된 라벨이 잘못된 권한으로 번역되지만 않으면 된다.

배운 것

라벨이 틀렸다는 신고를 받으면 그 라벨을 읽는 쪽을 먼저 세어봐야 한다. 사람만 읽으면 미관 문제고, 게이트가 읽으면 보안 문제다. 같은 증상이지만 등급이 다르다.

같은 사고를 막으려고 넣은 코드가 있다고 안심하면 안 된다. 그 코드에 도달하는지가 별개 문제다. 이번엔 방어선이 정확한 자리에 있었는데 한 줄 위에서 함수가 끝나고 있었다.

그리고 승인받은 처방도 실행 직전에 다시 잰다. 이번엔 그 한 번이 멀쩡한 기계 세 대를 살렸다.

시스템이 누군가를 오해할 때, 진짜 질문은 “누가 틀렸나”가 아니라 “그 오해를 몇 명이 믿나”다.

— 강대종 / @ssamssae