수집이 끝났는지 확인하고 나서야 지급한 일

포인트를 나누기 전에

모의투자를 하는 리워드 앱이었다. 사용자가 시장이 열리기 전에 투자해 두면, 시장이 닫힌 뒤 실제 등락을 기준으로 결과를 계산해 포인트를 나눠 주었다. 포인트가 일정 기준을 넘으면 실제 보상으로 바꿀 수 있었다. 이 글에서 지급이라 부르는 것은 그날의 투자 결과에 따른 포인트 분배다.

하루의 순서는 투자, 시장 데이터 수집, 계산, 분배로 이어졌다. 여러 나라의 주식을 다뤘기 때문에 데이터를 가져오는 방식도 시장마다 달랐다. 한 출처에서 데이터를 받지 못하면 사용할 보조 경로도 두었다.

나는 시세를 수집하고 받아들이는 처리와 함께, 수집 완료를 확인하고 미완료 데이터를 다시 요청하며 정체를 알리는 부분을 맡았다. 계산 정책에는 동료의 작업도 있었고, 나는 그 계산으로 넘어가기 전에 필요한 데이터가 들어왔는지 확인하는 흐름을 연결했다.

시간이 됐다고 계산을 시작할 수는 없었다

수집이 끝나지 않았으면 분배를 진행하지 않았다. 데이터가 빠진 채 순위를 계산하면 그 결과로 포인트를 나누게 된다. 이미 분배한 뒤에 잘못된 데이터를 발견하면 그 결과도 다시 살펴야 한다. 지급 시각이 됐다는 이유만으로 앞 단계를 건너뛸 수 없었다.

수집과 계산 배치를 나누고 그 사이에 완료 확인을 두었다. 배치는 일정한 작업을 묶어서 실행하는 프로그램이다. 수집 배치가 데이터를 가져오고, 확인 단계가 아직 끝나지 않은 대상을 살펴본 뒤, 계산과 분배로 이어지는 식이었다. 끝나지 않은 데이터는 다시 요청했고, 정해진 시간이 지나도 진행되지 않으면 알림이 갔다.

한 출처에서 빈 데이터가 오면 다른 경로로 다시 가져오는 보조 기능도 만들었다. 다른 제공자의 데이터를 쓰기도 했고, API에서 받지 못한 값을 웹에서 가져오는 경로도 있었다. 둘 이상의 출처를 항상 대조해 값이 맞는지 검증한 방식과는 다르다. 우선 필요한 데이터를 가져올 길을 더 둔 것이었다.

수집이 늦는 동안 해당 분배는 기다렸고, 다음 시장은 이어서 시작했다. 필요한 데이터의 수집 완료를 확인하면 대기하던 분배도 이어졌다. 지급이 늦어진 날은 여러 번 있었다. 기억하는 한 잘못된 지급은 없었지만, 지연 없이 처리한 시스템이라고 말할 수는 없다.

무엇이 있어야 끝났다고 할까

지금 돌아보면 ‘수집 완료’라는 말 안에 무엇을 확인했는지가 들어 있어야 한다. 수집 프로그램이 실행을 끝낸 것인지, 필요한 데이터가 모두 들어온 것인지, 계산에 써도 되는 값인지에 따라 다음에 할 일이 달라진다.

다시 살펴볼 기준을 예로 들어보자. 오늘 분배에 필요한 종목 목록은 있는데 그중 일부의 값만 도착했다면, 받은 값이 비어 있지 않다는 검사만으로는 충분하지 않다. 예상한 목록과 실제로 받은 목록을 대조해야 한다. 모든 종목의 값이 있더라도 날짜가 지난 시장의 데이터라면 이번 계산에 사용할 수 있는지 다시 확인해야 한다.

데이터 품질 검사에서도 값이 비어 있는지와 얼마나 최근 데이터인지를 따로 다룬다. 예를 들어 AWS Glue의 완전성 검사는 열에 null이 아닌 값이 얼마나 있는지를 보고, 신선도 검사는 날짜 값과 현재 시각의 차이를 본다. 값의 완전성, 데이터 신선도

이 검사를 통과했다고 계산 결과까지 맞는 것은 아니다. 값이 들어 있고 최근 것이라도 다른 종목의 값일 수 있고, 시장별 영업일과 마감 시각에 맞지 않을 수도 있다. ‘최근’이라는 조건도 그 업무에서 필요한 날짜와 같지는 않다. 어떤 데이터가 필요한지를 정하는 쪽과 실제로 받은 데이터를 검사하는 쪽이 같은 기준을 보고 있어야 한다.

여기서 중요하게 보고 싶은 것은 검사 항목의 수보다 다음 단계로 넘어가는 조건이다. 데이터가 없어서 기다리는 경우와, 값이 맞지 않아 확인해야 하는 경우를 구분하면 무엇을 다시 요청하고 무엇을 사람이 살펴야 할지도 달라진다.

기다림에도 다음 동작이 필요하다

이 흐름을 다시 정리한다면 상태와 조건으로 표현해볼 수 있겠다. ‘수집 중’, ‘확인 필요’, ‘계산 가능’처럼 현재 위치를 구분하고, 조건을 만족했을 때만 다음으로 옮기는 방식이다. 이 이름들은 설명을 위한 예시다. 예를 들어 Step Functions의 Choice 상태는 조건을 평가해 다음 단계를 고른다. 다만 도구는 정해 준 조건을 따를 뿐, 데이터가 업무상 충분한지를 대신 정해주지는 않는다. 조건에 따른 다음 단계 선택

기다리게 하는 것만으로도 끝나지 않는다. 무엇이 빠졌는지 모르거나 알림 뒤에 할 일이 없다면 계속 대기할 수 있다. 당시에는 미완료 데이터를 다시 요청하고, 보조 경로를 두고, 정체를 알리는 일을 함께 넣었다. 앞으로 같은 흐름을 살핀다면 대기하는 이유가 남는지, 다음 확인이나 재요청으로 이어지는지도 같이 보고 싶다.

지금 만드는 수집 서비스에서도 완료 조건을 다시 생각한다. 그때 포인트를 늦게 나누는 일은 실제로 생겼다. 필요한 결과가 아직 없는데 지급부터 끝낼 수는 없었다. 기다리기로 한 판단과, 그 기다림이 끝나도록 만든 확인·재요청·알림을 함께 기억하고 싶다.