우선순위 큐 버그로 멈춘 자동화 엔진을 되살린 기록

무엇이 문제였나 — 왜 자동화 엔진이 일을 안 했나

SGK Studio는 여러 사업 프로젝트를 한 사람이 동시에 운영하면서, 처리할 작업이 쌓인 프로젝트를 스스로 고르고 실행까지 맡기는 자동화 엔진을 만들어 붙였습니다. 프로젝트마다 진행 상황을 적어 두는 파일이 따로 있고, 엔진은 이 파일들을 읽어 어디에 미완료 작업이 쌓여 있는지 파악한 뒤 그중 하나를 골라 실행합니다. 사람이 매번 어느 프로젝트부터 손댈지 고르는 수고를 없애려는 목적이었습니다.

이 엔진에 기대한 값은 두 가지였습니다. 하나는 시간입니다 — 사람이 매번 여러 프로젝트를 오가며 우선순위를 다시 판단하는 시간을 줄이는 값입니다. 다른 하나는 실행률입니다 — 켜 둔 시간만큼 실제로 작업이 진행되는 값입니다. 그런데 12일을 켜 둔 뒤 돌아보니 실행률 쪽 숫자가 이상했습니다. 실패율이 조금 높은 정도로는 설명이 안 될 만큼, 대부분의 시도가 시작도 못 하고 끝났습니다.

그런데 앞서 나온 두 차례 보고는 자동화 엔진이 숙련된 수준의 판단 패턴을 구현했다는 근거로 코드가 존재한다는 사실만 들었습니다. 실행 로그를 실제로 세어 본 적은 없었습니다.

코드가 존재한다는 이유만으로 결과를 냈다고 주장하는 거 아니냐. 결과 중심으로 측정해야 한다.

맞는 지적이었습니다. 실행 로그를 세어 보니 이 엔진은 켜져 있던 12일 동안 사람이 대신 들인 시간만큼의 값을 내지 못했습니다. 무엇이 문제였는지는 실행 로그를 직접 열어야 알 수 있었습니다.

코드가 존재한다는 말은 위험한 보고 방식이었습니다. 코드가 배포됐다는 사실과 그 코드가 의도한 결과를 낸다는 사실은 서로 다른 주장인데, 첫 번째만 확인하고 두 번째를 확인한 것처럼 보고하면 다음에도 같은 착각이 반복됩니다. 이번에 실행 로그를 직접 연 것은 그 반복을 끊으려는 시도였습니다.

비용으로 보면 이야기는 더 단순합니다. 자동화 엔진을 켜 두는 것 자체는 추가 비용이 크지 않지만, 그 12일 동안 사람이 대신 프로젝트를 챙기는 시간은 고스란히 남았습니다. 엔진이 있는데도 사람이 직접 챙겨야 했다면, 그 12일은 자동화 이전과 실질적으로 다르지 않은 기간이었습니다.

이 착각은 새로운 것이 아니었습니다. 자동화 시스템을 만들 때는 만들었다와 작동한다 사이에 간극이 있다는 걸 알면서도, 급하게 결과를 보고해야 할 때는 그 간극을 건너뛰기 쉽습니다. 이번 사례가 남긴 절차는 간단합니다 — 실행을 주장하려면 실행 로그를 먼저 연다.

처음 잰 숫자 — 12일간 65%가 자동 중단됐다

측정 방법은 단순했습니다. 자동화 엔진이 남기는 실행 로그에서 판단 한 번을 실행 주기 하나로 세고, 그 주기가 실제 작업 실행으로 이어졌는지 조건 미달로 자동 중단됐는지를 전부 집계했습니다. 로그 한 줄이 주기 하나이므로 표본을 따로 고를 필요 없이 12일 치를 전부 셀 수 있었습니다.

실행 로그가 남기는 상태는 두 가지뿐입니다. 작업을 실제로 시작했다는 표시와, 조건 미달로 멈췄다는 표시입니다. 그 사이에 있는 중간 상태 — 이를테면 절반만 진행하다 멈췄다는 기록은 없습니다. 그래서 이번 집계는 둘 중 하나로 단순하게 나눠 셀 수 있었습니다.

자동 중단 412건 가운데 380건은 하나의 원인으로 모여 있었습니다 — 사람이 아직 답하지 않은 결정 항목이 하나 남아 있으면, 그 결정과 무관한 프로젝트까지 전부 실행을 멈추는 판정이었습니다. 나머지는 다른 조건 미달이었습니다.

숫자는 엔진이 신중하게 적게 실행했다는 그림과 맞지 않았습니다. 판단을 아예 못 하고 멈춘 비중이 3분의 2에 달했고, 5월 19일부터 25일까지 이레 동안은 단 한 번도 작업을 시작하지 못했습니다. 이 정도 구간이면 엔진이 신중한 게 아니라 무언가에 걸려 있다고 보는 편이 더 합리적이었습니다.

이 계측에서 빠진 것도 분명히 해 둘 필요가 있습니다. 실행 로그는 주기가 시작됐는지 멈췄는지만 남기고, 멈춘 뒤 사람이 대신 그 프로젝트를 얼마나 직접 처리했는지는 남기지 않습니다. 그래서 65%라는 수치는 엔진이 얼마나 안 돌았는지를 보여줄 뿐, 그 시간에 사람이 얼마나 더 일했는지는 별도로 세어야 알 수 있는 값입니다.

세운 가설 — 원인을 자율 판단의 한계로 봤다

처음 세운 가설은 이렇습니다. 정지 게이트가 촘촘하게 설계돼 있어서, 자율 판단이 신중할수록 실행 빈도가 낮아진다고 가정했습니다. 게이트가 자주 걸리는 건 위험한 실행을 잘 걸러내고 있다는 증거로 읽혔습니다.

이 가설은 나름 그럴듯했습니다. 자동화 시스템에서 실행 빈도가 낮다고 해서 반드시 결함은 아니고, 오히려 조건을 깐깐하게 본 결과일 때도 있기 때문입니다. 그래서 반증하기 전까지는 이 가설을 우선 순위에 놓고 접근했습니다.

이 가설대로라면 65%라는 수치는 고쳐야 할 결함이 아니라 안전장치가 일하고 있다는 신호입니다. 그래서 손을 대야 할 곳은 게이트의 판단 기준을 더 정교하게 다듬는 쪽이라고 봤습니다.

실행 빈도가 낮다고 해서 곧 결함은 아니라는 전제 자체는 지금도 유효합니다. 다만 그 전제를 확인하려면 어디서 낮은지, 왜 낮은지를 갈라 봐야 했는데, 처음에는 그 단계를 건너뛰고 전체 비율만 보고 결론을 냈습니다.

가설을 세운 이유는 하나 더 있었습니다. 12일 동안 여러 프로젝트가 섞여 후보로 올라왔고, 그중에는 우선순위가 낮아도 이상하지 않은 프로젝트도 있었습니다. 그런 프로젝트에서 게이트가 자주 걸리는 건 그림상 이상하지 않았고, 그래서 처음에는 걸리는 비중 자체를 의심하지 않았습니다.

가설이 틀린 지점 — 왜 국소적 결함으로 다시 봤나

가설을 검증하려고 자동 중단 412건을 원인별로 다시 갈라 봤습니다. 신중한 판단이라면 프로젝트마다 골고루 걸려야 하는데, 실제로는 세 지점에 집중돼 있었습니다.

먼저 확인한 것은 어느 프로젝트에서 자동 중단이 몰려 있는가였습니다. 프로젝트별로 나눠 세어 보니 중단이 골고루 퍼져 있지 않았고, 특정 몇 곳에 쏠려 있었습니다. 그다음 그 프로젝트들의 코드를 열어 셈이 맞는지, 순위가 맞는지, 정지 판정이 왜 걸리는지를 하나씩 확인했습니다.

• 매출을 담당하는 프로젝트 하나가 작업 목록 집계에서 통째로 0개로 잡혔습니다 — 판단이 신중해서가 아니라 셈이 안 됐을 뿐입니다.
• 순위 상위에 오른 프로젝트들은 매출과 무관한 부수 프로젝트였고, 매출 담당 프로젝트는 순위 10위 밖이었습니다 — 판단 기준이 아니라 정렬 축 자체가 틀렸습니다.
• 미해결 결정 1건이 관련 없는 다른 프로젝트의 실행까지 전부 멈췄습니다 — 신중함이 아니라 정지 범위를 프로젝트 단위가 아니라 전체 단위로 설계한 오류입니다.

이 세 가지를 확인하는 데 쓴 수단은 실행 로그와 코드 두 가지뿐이었습니다. 로그에서 어떤 프로젝트가 후보로조차 오르지 못했는지 프로젝트별로 나눠 세고, 후보 순서를 매긴 함수를 코드에서 직접 읽어 확인했습니다.

이 확인에는 새로운 계측 도구가 필요하지 않았습니다. 이미 남아 있는 로그와 코드 두 곳만으로 세 지점을 특정할 수 있었고, 그래서 원인을 찾는 절차 자체는 길지 않았습니다.

셋 다 더 신중해서로 설명되지 않았습니다. 특정 조건에서 재현되는, 이름을 붙일 수 있는 결함이었습니다. 그래서 원인을 자율성의 한계가 아니라 배선 결함 3개로 다시 정의했습니다.

진짜 원인 — 우선순위 큐를 막은 배선 결함 3개

세 결함을 하나씩 열어 보면 전부 무엇을 세고, 어떻게 줄 세우고, 언제 멈추는가라는 우선순위 큐 로직 안에 있었습니다.

세 결함은 서로 다른 계층에 있었지만 결과는 같았습니다. 우선순위 큐가 실제 작업 목록을 제대로 읽지도, 매출 기준으로 줄 세우지도, 필요한 범위만 멈추지도 못했습니다.

세 결함 중 어느 하나만 고쳤어도 65%라는 수치는 크게 움직이지 않았을 가능성이 큽니다. 매출 담당 프로젝트가 보이게 되더라도 정렬 기준이 그대로면 여전히 순위 밖에 머물렀을 가능성이 크고, 정렬을 고쳐도 전역 정지 게이트가 그대로면 다른 프로젝트의 미해결 결정에 다시 발목을 잡혔을 가능성이 큽니다. 세 곳을 동시에 고쳐야 서로를 가리던 결함이 걷혔습니다.

세 결함에는 공통된 실수가 하나 있었습니다. 셋 다 지금 있는 형식·기준·범위가 앞으로도 계속 유효하다고 가정하고 짠 코드였습니다. 진행 상황 파일은 체크박스 하나로만 쓰일 거라는 가정, 우선순위는 항목 개수만으로 충분히 드러날 거라는 가정, 결정 하나가 막히면 그 프로젝트만 멈추면 된다는 가정이 전부 실제 운영에서 깨졌습니다.

이 가정들이 왜 처음부터 코드에 박혀 있었는지도 짚을 만합니다. 진행 상황 파일 형식은 프로젝트가 하나뿐이던 시절에 정한 규칙이었고, 항목 개수 정렬은 그때는 프로젝트 수가 적어 개수만으로도 충분히 구별됐습니다. 정지 범위를 전체로 잡은 것도 처음에는 결정 하나가 곧 전체 방향을 좌우했기 때문입니다. 프로젝트 수가 늘어나면서 세 가정 모두 더 이상 성립하지 않게 됐는데, 코드는 그 변화를 따라가지 못했습니다.

조치 — 무엇을 어떻게 고쳤나

고치는 방법을 정하기 전에 더 급진적인 대안 두 가지를 먼저 검토하고 기각했습니다.

• 자동화 엔진을 폐기하고 새로 짠다 — 기각. 결함 3개가 전부 국소적이고 실행 로그로 정확히 특정됐습니다. 전면 재작성은 이미 작동하는 부분까지 다시 위험에 노출시킵니다.
• 정지 게이트를 아예 없앤다 — 기각. 게이트 자체는 유효한 안전장치입니다. 문제는 게이트가 있다는 사실이 아니라 정지 범위가 프로젝트 전체로 잡혀 있었다는 점입니다.
• 여러 프로젝트의 작업 목록 형식을 체크박스 하나로 통일한다 — 기각. 실제로 쓰고 있는 작업 목록 형식을 파서 편의를 위해 뜯어고치는 건 본말전도입니다. 파서가 현실을 읽어야 합니다.

그래서 세 결함을 각각의 자리에서 고쳤습니다. 항목을 세는 함수에 번호·굵은 글씨 서식을 읽는 경로를 추가하고 완료 표시가 붙은 항목은 제외했습니다. 정렬 기준은 매출 담당 프로젝트를 최우선으로 두고, 그다음 별도로 지정한 프로젝트, 나머지 순으로 바꿨습니다. 정지 판정은 프로젝트 단위로 따로 확인하도록 고쳐서, 막힌 프로젝트는 건너뛰고 다음 후보로 넘어가게 했습니다.

코드 수준에서 바뀐 대목은 세 함수뿐입니다. 그런데 이 세 함수가 우선순위 큐 전체의 입력·정렬·정지 판정을 맡고 있었고, 그래서 작은 수정 세 개가 65%라는 중단율의 원인 대부분을 설명했습니다.

막힌 프로젝트를 건너뛸 때는 그 사실을 기록으로 남기도록 했습니다. 특정 프로젝트가 계속 건너뛰어지고 있다면, 그 자체가 다시 확인해야 할 새로운 신호이기 때문입니다.

여기서 '별도로 지정한 프로젝트'는 매출 담당은 아니지만 따로 태그를 달아 계속 지켜보기로 한 프로젝트군을 말합니다. 매출 담당 프로젝트가 후보에 없을 때만 그다음 순서로 넘어가도록 정렬 기준을 3단으로 나눴습니다.

재측정 결과 — 후보 14개에서 17개로

세 결함을 고친 뒤 다시 집계했습니다. 실행 후보로 잡히는 항목은 14개에서 17개로 늘었고, 매출 담당 프로젝트는 비가시 상태(0개)에서 순위 1위(미완료 항목 7개)로 올라왔습니다. 트레이딩 자동화 프로젝트가 2위였습니다.

이전에는 매출 담당 프로젝트가 후보 목록에 아예 없어서, 사람이 직접 그 프로젝트의 작업을 챙겨야 했습니다. 지금은 후보 1순위로 올라와 있어서, 엔진의 정지 신호만 풀리면 그 프로젝트부터 시도합니다.

정지 게이트는 현재 전부 통과하고 있고, 남은 절차는 정지 신호를 내리는 일 하나뿐입니다. 그 신호를 내리면 곧바로 도는 상태라는 뜻입니다. 다만 돌면 쓸모 있는 결과를 낸다는 주장은 아직 증명되지 않았습니다. 앞선 두 차례 보고가 코드의 존재만으로 성과를 주장했던 실수를 반복하지 않으려고 이 문장을 그대로 남깁니다.

정지 신호를 당장 풀지 않고 남겨 둔 이유도 여기 있습니다. 배선을 고친 뒤 곧바로 완료라고 표시하면, 이번 글이 반복하지 않으려던 바로 그 실수 — 코드가 존재한다는 사실만으로 결과를 주장하는 실수를 또 반복하게 됩니다.

지금 단계에서 확인 가능한 범위는 막혀 있던 구조가 뚫렸다는 사실까지입니다. 뚫린 구조가 실제로 매출 담당 프로젝트의 작업을 꾸준히 처리하는지는 이후 며칠을 더 지켜봐야 압니다. 그래서 이번 수정을 최종 완료가 아니라 관측 구간 진입으로 표시해 뒀습니다.

• 증명 조건 ⓐ — 7일 관측 후 야간 실행 중 매출 담당 프로젝트 비중이 50% 이상이어야 합니다.
• 증명 조건 ⓑ — 사람이 직접 입력하는 시간대의 내용 없는 조작 비중이 36.7%에서 25% 이하로 떨어져야 합니다.
• 두 조건을 못 채우면 다시 정지하고 원인을 처음부터 다시 셉니다.

남는 한계 — 자동화는 돌지만 증명은 안 됐다

엔진을 고치는 동안 곁가지로 하나 더 쟀습니다. 사람이 실제로 무엇을 입력하며 이 시스템을 운영해 왔는지입니다. 14일치 입력 기록 1,666건을 유형별로 나눠 봤습니다.

결과 하나가 눈에 띄었습니다. 여러 프로젝트를 사람이 수동으로 돌리며 정체됐던 이유는 할 일이 부족해서가 아니었습니다. 입력 1,666건 중 실제 아젠다는 16.4%(하루 19.5건)뿐이었고, 나머지 대부분은 내용 없는 조작과 교정·질문이었습니다. 하루 103건, 평균 63자짜리 입력 대다수가 판단이 아니라 반복이었다는 뜻이고, 자동화 엔진이 줄이려는 대상은 바로 이 나머지 몫입니다.

이 문제를 처음 삼았던 자리로 되짚어 보면, 자동화 엔진에 기대했던 두 가지 값 중 시간 쪽이 이미 여기서 새고 있었습니다. 실행률을 고치는 일과는 별개로, 사람이 쓰는 시간 대부분이 애초에 프로젝트 판단이 아니라 반복 조작이었다는 뜻입니다.

두 문제는 사실 하나로 이어져 있습니다. 엔진이 우선순위 큐를 제대로 못 돌리는 동안 사람은 그 자리를 손으로 메꿨고, 손으로 메꾸는 시간의 상당 부분이 실제 판단이 아니라 반복 조작이었습니다. 우선순위 큐를 고치는 일과 사람의 입력 구성을 바꾸는 일은 서로 다른 작업이지만, 하나가 안 풀리면 다른 하나도 안 풀리는 구조였습니다.

다만 이 글을 쓰는 시점까지 자동화 엔진이 고쳐진 뒤 실제로 쓸모 있는 결과를 냈는지는 검증되지 않았습니다. 배선 결함 3개를 고친 일과, 고친 엔진이 사람의 수작업 시간을 실제로 줄이는 일은 다른 주장입니다. 이 부분은 7일 관측이 끝나야 답할 수 있고, 지금은 그 관측이 끝나지 않은 상태입니다. 증명 조건 두 가지가 전부 채워질 때까지는 이 엔진을 완성으로 부르지 않습니다.

이번 사이클에서 배운 것은 결국 하나입니다. 자동화가 일을 안 하는 것처럼 보일 때, 먼저 의심해야 할 대상은 자동화의 한계가 아니라 배선입니다. 배선은 세 가지 질문으로 좁혀집니다 — 무엇을 세고 있는가, 무엇을 기준으로 줄 세우는가, 멈출 때 얼마나 넓게 멈추는가.

우선순위 큐라는 이름은 거창하지만, 실제로 필요했던 것은 세 질문에 정직하게 답하는 코드뿐이었습니다. 지금 있는 형식을 다 담고 있는가, 지금 있는 기준으로 정말 중요한 항목이 위로 오는가, 멈출 때 꼭 필요한 범위만 멈추는가 — 세 질문 중 하나라도 옛 가정에 머물러 있으면 나머지 둘이 맞아도 전체는 멈춥니다.

검사 지점을 늘릴수록 안전해질 거라 가정했다가 반증됐던 사례는 AI 에이전트 승인 게이트를 줄인 기록에도 비슷하게 정리해 뒀습니다. 여러 프로젝트를 동시에 운영하며 비슷한 자동화·측정 문제를 겪고 있다면 상담에서 구체적인 상황을 알려 주시면 됩니다.