환경 이름은 코드에 있는 걸 쓴다

시험 환경 컨테이너의 환경 값이 코드에는 없는 새 이름으로 잡혀 있었다. 테스트 환경이라 그렇게 붙인 것으로 보였는데 그 값이 어떻게 처리되는지 확인해야 했다.

Open Table of contents

코드에 없는 환경 이름

이름 자체는 자연스럽고 사람이 읽기에도 뜻이 충분히 분명한 값이었다. 다만 그 문자열이 코드 어디에도 나오지 않는다는 점이 문제가 됐다.

환경 값은 사람이 읽는 라벨이 아니라 코드 분기에 들어가는 입력이다. 분기가 그 값을 모르면 그 환경은 어느 갈래에도 제대로 들어가지 못한다.

프레임워크는 이 값에 아무 제약을 두지 않고 임의 문자열을 그대로 받는다. 환경을 조회하는 함수도 받은 문자열을 그대로 돌려줄 뿐이었다.

특정 이름을 테스트 모드로 인식하는 내장 동작이 없으므로 분기는 전적으로 앱 코드의 문자열 비교에 달려 있다. 그래서 그 비교가 어디에 몇 개 있는지를 전수로 찾았다.

찾아낸 자리를 비교하는 방식에 따라 나눠 보니 다섯 종류로 갈렸다. 실서버일 때만 동작하는 것과 실서버가 아니면 테스트로 가는 것은 새 이름에서도 의도대로 동작했다.

문제가 되는 것은 특정 이름 목록에 있을 때만 가짜 응답을 내주는 갈래였다. 새 이름은 그 목록에 없으므로 시험 환경에서 실제 외부 호출이 나가고 오류는 나지 않는다.

여기서 두 비교 방식이 새 값에 대해 정반대 성질을 갖는다는 것이 드러났다. 실서버가 아니면이라는 조건은 새 값이 들어와도 안전한 쪽으로 보내고 특정 목록에 있으면이라는 조건은 위험한 쪽으로 보낸다.

한 코드베이스에 두 방식이 섞여 있으면 새 환경 값에서 일부는 안전하고 일부는 안 안전한데 안 안전한 쪽이 조용하다. 오류가 나지 않으므로 실호출이 나가고 있다는 것을 알아챌 방법이 없다.

목록에 새 이름을 추가하는 대응은 그 갈래 하나를 막을 뿐이고 다른 갈래와 앞으로 추가될 분기까지 매번 확인해야 한다. 그래서 환경 값을 코드에 실제로 존재하는 문자열 중에서 고르기로 했다.

코드에 이미 존재하는 이름을 쓰면 대부분의 갈래가 의도대로 동작한다. 철자가 다른 자리가 하나 있었는데 그것은 환경 목록에 넣지 않고 오타로 기록했으며 새 환경을 추가할 때 분기별로 어디로 가는지 표를 만드는 절차를 남겼다.