TL;DR

• 태스크 관리 AI의 출력은 문장이 아니라
  orderedTasks / excludedTasks / violations

로 나눕니다. - 우선순위는 스코어(Score)만으로 결정하지 않고, 의존 관계(Dependency)와 blocked를 먼저 처리합니다.

• Node.js v24.14.0 고정 테스트에서는 스코어 방식이 의존 위반 2건, 제약 우선 방식이 0건이었습니다. 7개 항목의 테스트는 모두 통과했습니다.

「그럴듯한 순서」가 가장 탐지하기 어렵다

태스크를 그대로 AI에게 전달하며, "마감 기한과 중요도를 보고 나열해줘"라고 부탁합니다. 답변은 대개 읽기 편하고 이유도 자연스럽습니다.

문제는 자연스러운 설명이 실행 가능성(Feasibility)을 보장하지 않는다는 점입니다. 이번 고정 데이터(Fixed data)를 스코어만으로 나열하면 다음과 같은 순서가 됩니다.

청구서 송부 → 릴리스 작업 → 리뷰 → 원고 확정 → 차기 조사

언뜻 보면 중요하고 마감 기한이 가까운 업무부터 나열되어 있습니다. 하지만 릴리스 작업은 리뷰에 의존하고, 리뷰는 원고 확정에 의존합니다. 두 곳에서 순서가 뒤바뀌어 있습니다.

태스크 관리 AI에 필요한 것은 더 설득력 있는 이유 문장이 아닙니다. **실행할 수 없는 순서를 기계적으로 거부할 수 있는 계약(Contract)**입니다.

참고로 Zenn의 현행 가이드라인도 일반 지식의 요약이 아닌, 구체적인 시행착오와 재현 조건을 포함하는 기술 기사를 권장하고 있습니다. 따라서 이번에는 실제 모델을 연결하지 않고, 동일한 입력을 몇 번이고 검증할 수 있는 결정론적인(Deterministic) 원형에 집중했습니다.

우선순위에 사용하는 6개 항목을 Task Schema에 넣기

자유 형식의 태스크 명칭만으로는 정렬에 필요한 조건이 부족합니다. ID와 타이틀 외에, 우선순위 판단에는 다음 6개 항목을 사용했습니다.

태스크 1건은 다음과 같은 형태입니다.

{
"id": "review",
"title": "리뷰",
...

여기서 중요한 것은 importance와 deadline을 섞지 않는 것입니다. 중요도가 5라도 의존 대상이 미완료 상태라면 지금 착수할 수 없습니다. 마감 기한이 가깝더라도 blocked 상태라면 순위표가 아닌 제외 사유로 넘깁니다.

JSON 형태를 엄격하게 관리하려면 JSON Schema Draft 2020-12를 사용하여 입력과 출력을 별도로 정의할 수 있습니다. 본 글에서는 가독성을 우선하여 필요한 부분만 보여드립니다.

출력을 「순위」, 「제외」, 「위반」으로 나누기

출력 측은 배열 하나로 끝내지 않습니다.

{
"generatedAt": "date-time",
"orderedTasks": [{
...

reason을 문장으로만 작성하면 평가할 때마다 표현이 달라집니다. 따라서 비교용으로는 reasonCodes를 사용하고, 독자를 위한 설명 문구는 후단에서 생성하도록 설계했습니다.

requiresHumanReview는 추정 소요 시간(Estimated duration)을 합산한 결과가 마감 기한을 초과할 때 설정합니다. AI가 순서를 반환할 수 있더라도 오늘 시간 내에 들어오지 않는다면, 그것은 자동 확정이 아니라 재조정의 대상입니다.

스코어보다 먼저 의존 관계를 해결하기

구현 순서는 다음과 같습니다.

• ID, 일시, 중요도, 소요 시간, 의존 대상을 검증한다
• blocked 상태와 해당 태스크에 의존하는 업무를 제외한다
• 의존 대상이 완료된 태스크만 후보로 삼는다
• 후보 내에서 사람의 덮어쓰기(Manual override), 마감 여유, 중요도, 소요 시간을 비교한다
• 시작·종료 시각을 누적하여 마감 초과 여부를 사람에게 반환한다

핵심 부분은 의존 관계를 만족하는 후보만을 정렬하는 처리입니다.

while (remaining.size > 0) {
const candidates = [...remaining]
.map((taskId) => byId.get(taskId))
...

이 방법을 사용하면 모델이 높은 중요도를 부여하더라도 의존 순서를 건너뛰지 않습니다. 순환 의존(Circular dependency)과 존재하지 않는 의존 대상은 정렬 전에 에러로 처리하여 중단합니다.

사람의 덮어쓰기도 숨기지 않습니다. 이번 invoice에는 "송부 시각 합의 완료"라는 이유가 포함된 boost를 설정했습니다. 결과에는 MANUAL_OVERRIDE가 남기 때문에, AI의 판단과 사람의 판단을 나중에 구분할 수 있습니다.

고정 테스트 세트로 두 방식 비교하기

동일한 6개의 태스크를 스코어 방식과 제약 우선 방식에 전달했습니다.

제약 우선 방식의 결과는 다음과 같은 순서가 되었습니다.

송장 송부
→ 원고 확정
→ 리뷰
...

Node.js v24.14.0의 표준 test runner를 통해 다음 7개 항목을 확인하고 있습니다.

• 스코어 (Score) 방식이 의존성 위반 2건을 발생시킴
• 제약 우선 방식은 의존 순서를 준수함
• 사람에 의한 덮어쓰기 (Overwrite)가 reason code에 남음
• blocked 상태를 아무런 언급 없이 순위에 포함함
• 알 수 없는 의존 대상을 거부함
• 순환 의존 (Circular Dependency)을 거부함
• 동일한 입력에 대해 동일한 결과를 반환함

실행 결과는 tests 7 / pass 7 / fail 0

이었습니다. 이것은 AI 모델의 정밀도 평가가 아닙니다. 우선순위 로직과 출력 계약 (Output Contract)에 대한 회귀 테스트 (Regression Test)입니다.

실제 모델에 전달할 테스트 Prompt

모델을 연결할 때는 출력을 그대로 채택하지 않고 "후보"로 취급합니다. 다음은 그대로 고정 테스트에 사용할 수 있는 최소 Prompt입니다.

당신은 태스크 순서의 후보를 만드는 Planner입니다.
입력 Task Schema:
- id: 고유 문자열
...

모델 출력을 받으면, 본문의 validator에서 의존 관계, ID, blocked, 마감 기한 초과를 재검사합니다. 구조화된 출력 (Structured Output)은 validator의 대체재가 아니라, validator에 전달하기 쉬운 입력값입니다.

일상의 태스크 관리를 요구사항으로 바꾸기

Macaron이 공개한 personal assistant 설명에는 일상의 일정, 리마인더, 판단을 개인의 문맥과 함께 다루는 장면이 있습니다. 직접 제작하는 측에서 참조할 수 있는 것은 내부 방식이 아니라, "마감 기한뿐만 아니라 선호도나 제약 사항도 순서에 영향을 미친다"라는 사용자 측의 요구사항입니다.

본고에서는 그 요구사항을 manualOverride와 excludedTasks로 한정하여 대체했습니다. 제품의 동작을 그대로 재현한 것은 아닙니다.

이 프로토타입에 아직 없는 것

이번 구현은 한 사람이 태스크를 직렬로 처리한다는 전제하에 이루어졌습니다. 병렬 작업, 휴식, 회의 고정 시간, 견적 오차, 태스크 전환 비용 (Context Switching Cost)은 다루지 않았습니다.

또한, 소요 시간이 틀리면 올바른 순서라 하더라도 일정은 무너집니다. 다음에 추가한다면, 모델을 더 똑똑하게 만들기 전에 actualMinutes를 기록하여 견적 오차를 평가할 것입니다.

태스크 관리 AI의 실패는 이상한 답변뿐만이 아닙니다. 더 까다로운 것은 설명은 자연스러운데 실행할 수 없는 답변입니다.

먼저 위의 Schema와 Prompt를 복사하여, 동일한 고정 태스크에서 의존성 위반이 0건이 되는지 확인하십시오. 모델 비교는 그 이후에 해도 충분합니다.

참고 자료

AI／개인 개발／Node.js／태스크 관리／JSON Schema

Discussion