AI 작업이 늘수록 정신없는 이유: 판단할 일을 대기열에 남기기

코딩 에이전트의 응답을 기다리며 다른 작업을 열었는데, 잠시 뒤 여러 창에서 동시에 질문이 돌아온다. 이때 개발자에게 필요한 것은 각 작업의 맥락을 다시 읽고 다음 행동을 정할 수 있는 기록이다. 판단할 일을 한곳에 모으고, 결정이 끝나면 다음 담당자에게 돌려놓는 방식으로 그 기록을 구성해 볼 수 있다.

Sergey Kuhne가 2026년 11월 8일 쓴 How I’m fighting the AI Brain Fry는 이런 문제를 다룬 개인 실험이다. 저자는 순서와 맥락을 관리하려고 Git에 Markdown 작업 카드를 저장한다. 에이전트가 작업을 진행하고, 사람이 판단해야 할 항목은 하나의 받은편지함에 모인다. 검토 화면은 Git에서 다시 만들며 결정도 카드에 기록한다. 저자는 한 항목을 판단한 뒤 대기열에 돌려놓는 과정에서 산만함이 줄었다고 설명한다. 운영 배포는 자신이 맡는다.

이는 피로 감소나 생산성 향상을 수치로 검증한 연구가 아니다. 아래에서는 이 아이디어를 개발 작업에 적용하는 방법을 독립적인 가상 예시로 살펴본다. 카드 형식과 상태 구분은 원저자의 구현을 재현한 것이 아니라 이 글의 제안이다.

응답이 도착한 순서와 판단할 순서는 다르다

검색 화면 수정, 사용 안내문 정리, 오래된 파일 정리를 각각 맡겼다고 하자. 검색 작업에서는 동작 기준에 관한 질문이 왔다. 안내문은 수정이 끝났고, 파일 정리는 삭제 후보만 준비됐다.

세 창에 모두 새 메시지가 있지만, 다음 행동은 서로 다르다.

메시지 도착 순서대로 창을 열면 질문, 결과 검토, 실행 허가를 번갈아 처리한다. 각 창에서 “왜 이 작업을 시작했지?”부터 복구해야 한다면, 짧은 답을 쓰는 데도 앞선 대화를 다시 읽게 된다.

판단 대기열은 이 세 요청을 같은 목록에 놓되, 무엇을 결정해야 하는지 드러내는 방식이다. 검색 동작을 정해야 후속 검사가 가능하다면 그 질문을 먼저 처리할 수 있다. 파일 정리는 허가 전까지 멈춰 두고, 안내문은 별도의 검토 시간에 읽을 수 있다. 우선순위에는 다른 작업을 막는 정도나 실제 기한 같은 이유가 있어야 한다. 알림이 늦게 왔다는 사실만으로 판단을 뒤로 미룰 필요는 없다.

작업 카드에는 대화 대신 재개 조건을 남긴다

검색 작업을 다시 열었을 때 필요한 것은 모든 대화의 복사본이 아니다. 기대 동작, 현재 확인한 사실, 남은 질문과 다음 행동을 찾을 수 있어야 한다. 다음은 그 정보를 모은 가상 카드다.

작업: 검색어를 지웠을 때 화면 동작 정리
상태: 결정 대기
목표: 입력이 비었을 때 화면이 어떻게 바뀌는지 일관되게 만든다.

현재 근거:
- 기존 결과가 남는 동작을 재현했다.
- 빈 입력에 대한 기대 동작은 아직 정하지 않았다.

결정할 질문:
- 검색어를 지우면 결과도 비울 것인가?
- 뒤로 가기로 복원한 검색어와 결과는 유지할 것인가?

다음 담당자: 요구사항을 정하는 사람
결정 후 행동: 에이전트가 승인된 동작을 구현하고 관련 검사를 실행한다.
완료 조건: 빈 입력과 뒤로 가기 복원 동작을 각각 확인한다.

이 카드의 “재현했다”는 가상 상황 안의 설정이며 실제 실행 보고가 아니다. 실제 작업에서는 변경 버전과 재현 절차, 검사 결과로 연결되는 경로도 붙여야 한다. 요약만 있고 원래 근거를 열 수 없다면 판단을 검증하기 어렵다.

카드를 읽는 사람은 빈 입력과 뒤로 가기를 별개의 조건으로 결정할 수 있다. 예를 들어 “직접 지운 입력은 결과도 비운다. 뒤로 가기는 이전 검색어와 결과를 함께 복원한다”라고 답한다. 그러면 다음 담당자는 구현할 두 경우를 알 수 있다. “알아서 자연스럽게 처리”라는 답보다 재개할 범위가 명확하다.

반대로 전체 대화만 저장하면 어떤 메시지가 최종 결정인지 다시 해석해야 한다. 기록의 양보다 현재 유효한 결정과 그 근거로 돌아갈 경로가 재개에 중요하다.

내 판단이 끝난 것과 작업이 끝난 것을 구별한다

검색 동작을 결정했다고 해서 구현과 검증까지 끝난 것은 아니다. 사람이 카드를 내려놓을 수 있으려면 다음 행동이 기록되고, 그 행동을 맡을 주체가 정해져야 한다.

이 예시에 필요한 상태는 다음처럼 구별할 수 있다.

앞의 결정을 카드에 적었다면 상태를 실행 대기로 바꾼다. 이제 사람은 다른 항목을 볼 수 있고, 에이전트는 정해진 범위에서 작업을 이어 간다. 수정 결과가 오면 검토 대기로 돌아온다. 이때도 “검사 통과”만 읽지 말고 빈 입력과 뒤로 가기를 각각 검사했는지 확인한다.

결정 대기 상태를 구별하지 않으면 반복이 생기기 쉽다. 에이전트가 같은 카드를 다시 읽어도 기대 동작은 여전히 없다. 추가 조사로 답을 찾을 수 있는 문제가 아니라면, 같은 질문을 다시 만드는 데 그칠 수 있다. 이를 막으려면 무엇을 기다리는지 적고, 그 조건이 바뀌기 전에는 실행 대상으로 다시 꺼내지 않는 규칙이 필요하다.

목록을 만들었다고 처리 능력이 늘지는 않는다

판단 대기열은 해야 할 일을 보이게 하지만, 사람이 검토할 시간을 만들어 주지는 않는다. 설명을 위한 가상 계산으로, 하루에 검토 요청이 6개 생기고 4개를 처리한다고 하자. 기존 대기 항목이 없고 취소되는 작업도 없다면 매일 2개씩 쌓여 닷새 뒤에는 10개가 남는다. 목록의 정렬을 개선해도 이 차이는 사라지지 않는다.

이 경우에는 새로 시작하는 작업을 줄이거나, 검토가 필요한 변경의 크기를 줄이는 선택이 필요하다. 승인받은 범위에서 스스로 끝낼 수 있는 작업을 매번 사람에게 되묻지 않도록 하는 것도 방법이다. 다만 검토량을 줄이려고 삭제 허가나 요구사항 결정을 생략하면 위험을 다른 곳으로 옮기게 된다.

조건을 바꿔 한 번에 작업 하나만 진행하고 맥락도 쉽게 복구할 수 있다면, 별도의 대시보드까지 만들 이유는 적다. 기존 이슈에 결정과 다음 행동을 남기는 정도로 충분할 수 있다. 여러 세션을 오가며 같은 질문을 재발견할 때부터 필요한 기록을 보완하는 편이 낫다.

처음 적용할 때는 현재 열려 있는 작업 하나를 골라 보자. 다른 대화창을 읽지 않아도 지금 기다리는 결정, 그 결정의 근거, 결정 후 움직일 담당자를 찾을 수 있도록 적는다. 다음에 그 작업으로 돌아왔을 때 어디서 재개할지 알 수 있다면, 기록이 맡아야 할 역할을 하고 있는 것이다.