큐에 넣는 쪽의 부재

수집 잡이 열세 개 있는데 데이터가 안 들어온다는 이야기가 있었다. 잡 코드부터 하나씩 읽었다.

Open Table of contents

전부 맞게 짜여 있던 잡

조회하고 파싱해서 저장하는 흐름이 각각 제대로 짜여 있었다. 열세 개를 다 봤지만 고쳐야 할 자리가 안 나왔다.

코드가 맞는데 결과가 없으면 코드 밖을 봐야 한다. 그래서 이 잡들을 누가 큐에 넣는지를 찾았다.

큐에 넣는 함수는 정의돼 있었고 이름으로 코드 전체를 검색했다. 결과가 정의부 한 줄뿐이었다.

열세 개 전부에 같은 검색을 돌려도 결과가 하나씩이었다. 정의만 있고 부르는 곳이 없으니 큐에는 아무것도 안 들어가고 있었다.

소비자는 큐를 계속 읽고 있고 큐가 비어 있으니 아무 일도 안 일어난다. 오류가 아니라 정상적인 대기 상태다.

잡을 하나씩 리뷰하면 전부 맞다는 결론이 나오는데 그 열세 개가 전부 도달 불가였다. 코드 품질과 도달 가능성은 다른 축이라 한쪽만 봐서는 다른 쪽이 안 드러난다.

소비자 쪽 주석에 이 반복문은 소비자일 뿐이고 주기 폴링을 거는 쪽은 범위 밖이라고 적혀 있었다. 코드가 스스로 미구현을 말하고 있었지만 그 주석으로 아는 것은 스케줄러가 없다는 것까지였다.

일부는 다른 경로로 걸릴 수도 있으므로 범위는 전수 검색 전까지 몰랐다. 검색 결과가 0개면 이름이 틀린 것이고 1개면 정의만 있는 것인데 결과가 나오니 있다고 보고 넘기기 쉬운 쪽이 1개였다.

이것으로 할 일의 순서가 바뀌어 개별 잡의 로직 개선보다 스케줄러 구현이 먼저가 됐다. 생산자 하나가 소비자 열세 개를 한꺼번에 살린다.

이후로 잡 관련 작업을 할 때 큐에 넣는 함수의 호출부가 실제로 있는지부터 확인하게 됐다. 정의됐지만 안 불리는 함수와 등록됐지만 안 걸리는 경로처럼 있다와 도달한다가 갈리는 구조가 흔하기 때문이다.