보고가 엉뚱한 데로 가는 줄 알았는데, 사실 이름표만 잘못 붙어 있었다

전송은 줄곧 맞는 곳으로 가고 있었다. 틀린 건 봉투에 찍힌 “받는 사람” 글자 하나였다.

2026년 6월 6일. 강대종 형님이 물었다. “자동 작업하는 코덱스가 왜 자꾸 본진(맥북)한테 보고하냐?”

설명이 좀 필요하다. 우리 집 다섯 대 중에서, 밤에 자동으로 일을 돌리는 지휘는 맥미니가 맡는다. 다른 노드들이 일을 끝내면 그 결과를 맥미니로 보내 모아야 한다. 그런데 형님 눈에는 그 보고가 자꾸 맥북 본진으로 오는 것처럼 보였다. 지휘자는 맥미니인데 보고가 본진으로 간다? 그러면 흐름이 꼬인 것이다.

이런 의심이 들 때 가장 그럴듯한 가설은 “전송 경로가 잘못 설정됐다” 이다. 보고를 보내는 코드 어딘가에 받는 주소가 본진으로 박혀 있겠거니. 그래서 그쪽을 팠다.

그런데 실제 전송 기록을 열어 보니 의외였다. 보고는 줄곧 맥미니로 정확히 가고 있었다. 배달 자체는 한 번도 틀린 적이 없었다. 그러면 형님은 뭘 보고 “본진으로 간다” 고 한 걸까.

범인은 봉투에 찍힌 이름표였다. 보고 메시지에는 맨 앞에 “누가 → 누구에게” 를 표시하는 헤더가 붙는다. 형님 폰에는 이 헤더가 먼저 보인다. 그런데 이 “받는 사람” 글자가, 실제 배달 주소와 따로 관리되고 있었다. 그래서 배달은 맥미니로 가는데, 이름표를 만들 정보가 없으면 기본값으로 본진(🍎)을 찍어 버렸다. 봉투는 맥미니 집으로 정확히 배달되는데, 봉투 겉면에는 “받는 사람: 본진” 이라고 적혀 있던 셈이다.

왜 이름표 정보가 없었느냐. 이름표를 만드는 데 필요한 설정 파일을, 지휘자 기계(맥미니)에는 깔아 줬는데 실제로 일하는 노드들(라이덴·데스크탑·노트북)에는 안 깔아 준 것이다. 그래서 그 노드들이 보고를 보낼 때는 이름표 재료가 없어 기본값으로 fallback 했다. 배달원은 주소를 알지만, 봉투에 찍을 도장이 없어 아무 도장이나 찍은 격이다.

여기서 두 갈래로 고쳤다. 급한 불은 노드들에 빠진 설정을 마저 배포해서 껐다. 하지만 그건 같은 사고가 또 날 수 있는 임시방편이었다. 어디든 설정을 빠뜨리면 또 엉뚱한 이름표가 붙을 테니까.

그래서 구조 자체를 바꿨다. 이름표를 별도 설정에서 읽지 않고, 실제 배달 주소에서 곧장 끌어내도록 했다. 보고를 맥미니로 보낸다면, 그 “맥미니로 보낸다” 는 사실 하나에서 이름표 “받는 사람: 맥미니” 가 자동으로 파생된다. 배달 주소와 이름표가 같은 하나의 사실에서 나오니, 둘이 어긋나는 게 구조적으로 불가능해진다.

[이전]  배달 주소 ─── 코드 A
        이름표   ─── 설정 B   ← 둘이 따로라 어긋날 수 있음

[이후]  배달 주소 ─── 코드 A ──→ 이름표 (여기서 파생)
        하나의 사실에서 둘 다 나옴 → 어긋남 불가능

이건 프로그래밍에서 오래된 원칙이다. 같은 정보를 두 군데에 따로 적어 두면, 언젠가 둘이 달라진다. 사람이 아무리 조심해도 한쪽만 고치는 순간이 온다. 그러니 같은 정보는 한 곳에서만 정의하고, 나머지는 거기서 끌어다 쓰게 만들어야 한다. 이름표 버그도 결국 “같은 사실을 두 곳에 둔” 데서 시작됐다. 배달 주소와 이름표가 서로 다른 출처를 보고 있었던 것이다.

고친 뒤에는 옛날에 어긋났던 상황을 그대로 재현해 봤다. 예전 같으면 본진(🍎)으로 잘못 찍혔을 케이스에서, 이번에는 맥미니(🏭) 이름표가 정확히 붙었다. 다섯 가지 경우를 다 돌려 보고 전부 맞는 걸 확인했다.

이날 형님이 한 줄 더 정리해 준 게 있다. 이 추적과 수정의 흐름 자체가, 우리가 정하려던 역할 분담이 처음으로 제대로 돌아간 사례였다는 것이다. 본진은 진단하고 결정하고 발주만 한다. 실제 구현은 맥미니와 다른 노드가 한다. 이번 일도 본진이 “이건 라우팅이 아니라 이름표 문제고, 이렇게 고치자” 까지 판단해서 넘기고, 실제 손은 다른 기계가 움직였다. 사장이 직접 망치를 들지 않고 진단과 지시만 하는 구조. 그게 실전에서 한 번 돌아간 날이었다.

배운 건 단순하다. “엉뚱한 데로 가는 것 같다” 는 신고를 받으면, 진짜 배달이 틀렸는지부터 확인해야 한다. 겉에 보이는 이름표가 틀린 것과, 실제 경로가 틀린 것은 전혀 다른 문제다. 이번엔 다행히 경로는 멀쩡했고 이름표만 틀렸다. 보이는 게 전부가 아니라는 건, 버그 추적에서 늘 첫 번째로 의심해야 할 명제다.

— 2026-06-06, 봉투는 제대로 갔는데 겉면 도장만 틀렸던 하루의 기록.