조용히 무시되는 설정 키

메시지 브로커를 다른 인스턴스와 공유해 쓰게 되어 저장 공간을 논리적으로 분리해야 했다. 설정에 분리용 키를 넣고 띄웠다.

Open Table of contents

넣었는데 아무 일도 안 일어났다

오류도 경고도 없이 정상으로 기동했다. 그런데 확인해 보니 분리가 안 되어 있었고 기본 공간에 그대로 쓰고 있었다.

파싱은 되는데 어디서도 읽지 않는 키였다. 읽히지 않는다는 사실을 알려 주는 신호가 아무 데도 없었다.

문서와 소스를 뒤지니 비슷한 키가 셋이었다. 내가 쓴 것은 조용히 무시되고 옛 이름은 동작하되 폐기 경고가 나오고 중첩 구조로 쓰는 것이 현재 방식이었다.

옛 이름으로 넣었을 때 동작하니까 거기서 멈출 뻔했다. 경고가 나온 덕분에 더 봤고 그것이 없었으면 그대로 썼을 것이다.

셋을 나란히 놓으니 조용히 무시되는 것과 정상인 것이 겉으로 같았다. 둘 다 오류도 경고도 없고 기동도 정상이다.

그런데 하나는 되고 하나는 안 된다. 경고가 없다는 것이 맞다는 뜻이 아니었고 오히려 폐기 경고가 나오는 쪽이 신호가 있어서 나았다.

무시된 채로 뒀으면 기본 공간에 쓰게 되는데 거기에는 다른 데이터가 있다. 키 이름이 겹치면 덮어쓰고 안 겹쳐도 그쪽의 전체 비우기 작업에 우리 데이터가 함께 지워진다.

우리 쪽에서만 조용한 것이 아니라 남의 데이터까지 건드리는 결과가 된다. 조용한 오설정의 피해는 설정한 쪽이 아니라 옆에서 나타난다.

설정 스키마가 모르는 키를 거부하게 되어 있으면 넣는 순간 알 수 있다. 관대한 파서가 조용한 실패를 만드는 구조였다.

그래서 설정을 넣었으면 그것이 실제로 반영됐는지를 직접 조회해 보는 것을 절차로 뒀다. 이 경우에는 분리된 공간을 조회해 비어 있는지 보면 되는 것이었고 로그가 조용하다는 것을 근거로 삼지 않았다.