TL;DR — 처리할 일이 한꺼번에 쏟아질 때, AI 에이전트는 무엇부터 해야 할까요? 우선순위 설정은 여러 작업을 기준 정의 → 평가 → 스케줄링 → 재우선순위화의 흐름으로 줄 세우는 설계입니다. 핵심 통찰은 하나 — 긴급한 것이 곧 중요한 것은 아니다. 긴급도·중요도·의존성·비용효과를 가중하는 MCDM, 긴급-중요 2축의 Eisenhower Matrix로 P0~P3을 가르고, 상황이 변하면 실시간 재조정하며, SLA가 걸린 일은 남은 시간에 따라 긴급도를 비선형으로 끌어올립니다. 응급실 트리아지처럼, 먼저 온 순서가 아니라 위중한 순서로.
1. 왜 우선순위인가 — 측정했다면, 이제 줄을 세울 차례
지난 편에서 우리는 에이전트에 계기판을 달았습니다(평가·모니터링). 그런데 계기판을 보다 보면 경고등이 한꺼번에 켜집니다 — 알림 10개, 이슈 20개, 처리 대기 50건. 사람도 그렇지만, 자율 에이전트도 똑같은 질문에 부딪힙니다. "이걸 다 할 수는 없는데, 무엇부터 하지?" 이번 편이 그 답입니다.
순진한 접근은 FIFO(먼저 온 순서)입니다. 하지만 현실은 그렇게 굴러가지 않죠. 5분 뒤 만료되는 VIP 계약 건과, 다음 주까지 해도 되는 문서 정리가 같은 줄에 서면 안 됩니다. 우선순위 설정은 작업을 명시적 기준(긴급도·중요도·의존성·비용효과)으로 점수화하고, 상황 변화에 맞춰 동적으로 재조정하는 설계입니다.
🚑 응급실 트리아지(Triage) 비유 — 교재의 핵심 비유입니다. 응급실에 환자 10명이 동시에 도착하면, 먼저 온 순서가 아니라 긴급도(생명 위험)·중증도·치료 자원 가용성을 종합해 치료 순서를 정합니다. 그리고 심정지 환자가 새로 들어오면 그 순간 우선순위를 재조정하죠. AI 우선순위 설정도 똑같습니다 — 정적인 줄서기가 아니라, 끊임없이 다시 재는 동적 시스템입니다.
이는 6편(플래닝)·11편(목표 설정)·16편(자원 인식)이 만나는 지점입니다. 계획이 무엇을 할지를, 목표가 어디로 갈지를 정한다면, 우선순위는 한정된 자원 안에서 무엇을 먼저 할지를 정합니다. 자율 에이전트가 진짜 '판단'을 한다는 것의 절반은, 결국 이 우선순위 결정 능력입니다.
2. 개념과 오해 — 긴급한 것이 곧 중요한 것은 아니다
📌 한 줄 정의 — 우선순위 설정은 AI 에이전트가 여러 작업·목표·행동 중 가장 먼저 수행할 것을, 명시적 평가 기준(긴급도·중요도·의존성·자원·비용효과)과 동적 적응 능력으로 스스로 선택하게 만드는 설계 패턴입니다.
교재는 우선순위 결정을 4가지 핵심 구성요소의 흐름으로 정리합니다. 한 번 정하고 끝이 아니라, 마지막 단계(재우선순위화)가 다시 처음으로 돌아오는 순환이라는 점이 중요합니다.
현장에서 가장 자주 보는 세 가지 오해를 짚습니다.
3. Eisenhower Matrix — 긴급과 중요를 두 축으로 가른다
오해 ①을 푸는 가장 고전적인 도구가 Eisenhower Matrix입니다. 긴급도와 중요도를 직교하는 2축으로 놓으면 사분면이 생기고, 각 분면에 행동 원칙이 붙습니다. 교재는 이 사분면을 그대로 P0~P3에 매핑합니다.
그래서 우선순위 레벨은 대응 시간으로 구체화됩니다 — P0(Critical, 즉시 — 시스템 장애·보안), P1(High, 4시간 내 — 중요 버그·VIP), P2(Medium, 24시간 내 — 일반 기능), P3(Low, 1주일 내 — 문서화·기술부채). "언제까지 해야 하는가"가 곧 우선순위의 언어인 셈입니다.
4. 가중 MCDM — 여러 기준을 한 점수로 합친다 LangChain
Eisenhower가 직관적이지만 정량적이진 않습니다. 실무에서는 여러 기준에 가중치를 매겨 한 점수로 합치는 가중 다중기준 의사결정(Weighted MCDM)을 씁니다. 이 저장소의 구현(01_priority_based_task_manager.py)은 이를 Strategy Pattern으로 만들어, 고객마다 다른 우선순위 정책을 런타임에 갈아끼웁니다.
점수가 나오면 ≥0.8→P0, ≥0.6→P1, ≥0.4→P2, 그 외 P3으로 레벨을 할당합니다. 여기에 카테고리 보너스(incident +0.15, bug +0.05, maintenance −0.05)와 고객등급 보너스(VIP +0.15, premium +0.08)를 더하죠(01번 기준 — 파일·교재마다 보너스 값에 미세 차이가 있습니다). 가중치를 코드 밖으로 빼서 정책화하는 것, 그것이 우선순위 설계의 첫 단추입니다.
5. P0~P3과 동적 재우선순위화 — 줄은 끊임없이 다시 선다 LangGraph
오해 ②(정적 우선순위)를 푸는 핵심이 동적 재우선순위화입니다. LangGraph 워크플로(02_langgraph_priority_workflow.py)는 작업을 처리한 뒤 rebalancing 노드로 돌아가 순위를 다시 계산합니다.
| 레벨 | 대응 시간 | 예시 | 동적 부스트(마감 임박) |
|---|---|---|---|
| P0 Critical | 즉시 | 시스템 장애·보안 | <2h: +0.3 <8h: +0.15 <24h: +0.05 대기 1h당 +0.01(최대 +0.1) |
| P1 High | 4시간 내 | 중요 버그·VIP | |
| P2 Medium | 24시간 내 | 일반 기능 개발 | |
| P3 Low | 1주일 내 | 문서화·기술부채 |
또 하나의 미묘한 함정 — 기아 현상(Starvation)입니다. P3 작업이 영원히 P0·P1에 밀려 처리되지 않으면, 그건 우선순위가 아니라 방치입니다. 그래서 01번 구현은 72시간 이상 대기한 작업에 min(0.2, age_hours/500)만큼 우선순위를 자동 상향합니다. "오래 기다린 일에는 가산점을 준다" — 낮은 우선순위도 언젠가는 처리되도록 보장하는 안전장치죠. 이 모든 상태는 LangGraph의 Annotated[List, operator.add]로 누적 병합되어, 8편(메모리)의 체크포인터처럼 이력을 유지합니다.
6. 우선순위 큐와 분기 — 점수가 곧 길을 가른다 LangGraph
점수를 매겼으면 가장 높은 것을 먼저 꺼내야 합니다. 자료구조 교과서의 우선순위 큐(heapq)가 정확히 이 일을 합니다. Python의 heapq는 Min-Heap(최솟값이 먼저)이라, 점수가 높은 것을 먼저 꺼내려면 __lt__에서 부등호를 뒤집는(self.score > other.score) 트릭을 씁니다 — Min-Heap을 Max-Heap처럼 쓰는 거죠.
LangGraph에서는 선택된 작업의 레벨에 따라 조건부 엣지(Conditional Edges)로 길을 가릅니다 — 2편(라우팅)의 분기가 우선순위 도메인에서 재등장합니다.
처리가 끝나면 should_continue가 재조정(rebalancing)으로 갈지, 다음 작업 선택으로 갈지, 끝낼지를 정합니다 — 5절의 동적 재우선순위화가 그래프 구조로 실현되는 셈이죠. 동시성 환경에서는 threading.Lock으로 큐를 보호해 여러 작업이 동시에 들어와도 순위가 꼬이지 않게 합니다.
7. SLA 기반 우선순위 — 시간이 가까울수록 가팔라진다 순수 Python · Gemini
ITSM·고객지원 현장은 SLA(서비스 수준 약정)가 우선순위를 지배합니다. SLA 기반 매니저(04_sla_based_priority_manager.py)는 고객 등급 4종 × 심각도 4종 = 16개 SLA 정책을 정책 레지스트리로 관리합니다.
| 등급 \ 심각도 | Critical | High | Medium | Low |
|---|---|---|---|---|
| Platinum | 15분/1h | 30분/2h | 1h/8h | 2h/24h |
| Gold | 30분/2h | 1h/4h | 2h/12h | 4h/48h |
| Silver | 1h/4h | 2h/8h | 4h/24h | 8h/72h |
| Bronze | 2h/8h | 4h/12h | 8h/48h | 12h/1주 |
핵심은 Time-to-SLA 비선형 긴급도입니다. 마감까지 남은 시간이 줄어들수록 긴급도가 가파르게 오릅니다 — 선형이 아니라 계단형으로. SLA 점수는 이 시간 긴급도(40%) + 고객등급(25%) + 심각도(25%) + 에스컬레이션 보너스(10%)로 합산됩니다.
8. 에스컬레이션 — 위반하기 전에 위로 올린다
SLA가 곧 깨질 것 같으면, 가만히 두지 않고 위로 올려야 합니다. 04번 구현은 남은 시간을 기준으로 3단계 자동 에스컬레이션을 트리거합니다 — 13편(휴먼 인 더 루프)의 에스컬레이션이 SLA 도메인에서 시간 기반으로 정교해진 형태죠.
티켓 자체의 상태도 4단계로 추적합니다 — ON_TRACK(50%+ 남음) → AT_RISK(25~50%) → CRITICAL(<25%) → BREACHED(위반). 핵심은 위반 예측과 선제적 알림입니다 — 사고가 난 뒤 보고하는 게 아니라, 사고가 나기 전에 손을 드는 것. 19편(모니터링)이 드리프트를 예고했듯, 여기서는 SLA 위반을 예고합니다.
9. Google ADK 스케줄링 — 평가·스케줄·재조정의 24/7 사이클 Google ADK
우선순위 결정을 여러 전문 에이전트의 협업으로 풀 수도 있습니다. Google ADK 구현(03_google_adk_priority_scheduler.py)은 4개 전문 에이전트 — PriorityAssessor → TaskScheduler → ExecutionMonitor → DynamicRebalancer — 를 SequentialAgent로 잇고, 전체를 LoopAgent로 감싸 지속적인 사이클로 돌립니다(7편 멀티 에이전트의 협업 구조).
각 에이전트는 output_key로 세션 상태를 공유합니다 — 평가 결과가 스케줄러로, 스케줄이 모니터로, 모니터 결과가 재조정으로 흐르죠(8편 메모리). SequentialAgent는 1편(체이닝), LoopAgent는 4편(리플렉션)의 반복 구조가 우선순위 도메인에서 재조립된 형태입니다.
10. 하이브리드 엔진 — 규칙으로 빠르게, LLM은 애매할 때만
모든 작업을 LLM에 물어 우선순위를 정하면 느리고 비쌉니다. 그래서 적용 전략 문서는 3단계 하이브리드 엔진을 제시합니다 — 18편(가드레일)·19편(평가)의 "싼 것 먼저, 비싼 것은 애매한 것만"이 또 등장합니다.
대부분의 작업은 1~2단계에서 끝납니다. "VIP + Critical + SLA 5분"처럼 명백한 P0은 규칙으로 즉시 결정되죠. LLM은 "고객이 화는 났지만 요청 자체는 사소한" 같은 맥락적 판단이 필요한 소수에게만 투입됩니다. LLM 호출 시 temperature를 0.1~0.3으로 낮춰 일관성을 확보하는 것도 공통 패턴입니다.
11. 엔터프라이즈 적용 — CRM·ERP·Groupware와 ROI
우선순위 설정은 대량의 일이 한정된 자원과 만나는 모든 현장에 적용됩니다. 적용 전략 문서는 세 시스템에 각 구현을 매핑합니다.
| 시스템 | 활용(구현) | 대표 기대효과 |
|---|---|---|
| CRM | 리드 스코어링·문의 분류(01 MCDM) | 리드 전환율 5%→6.5%(+30%)·생산성 +50% |
| ERP | 주문 처리 우선순위(02 LangGraph) | SLA 위반 50→2건/월(−96%)·긴급비용 −80% |
| Groupware | IT 헬프데스크 티켓 배정(04 SLA) | 해결시간 −62.5%·잘못된 배정 25%→5% |
ROI 시나리오는 중규모 기업(연매출 500억) 기준입니다 — 투자 2.9억, 절감 11억(리드 2억 + SLA 벌금 5억 + 물류비 3억 + 인건비 1억), 순이익 8.1억.
가장 큰 효과는 SLA 위반 −96%에서 나옵니다 — 위반 시 벌금이 큰 ERP/제조에서 우선순위 자동화는 직접적인 비용 방어입니다. 다만 적용 전략 문서는 AI-ERP 도입 실패의 32%가 조직적 관성과 스킬 갭에서 비롯된다고 경고합니다. 기술보다 변화 관리가 더 어려운 법이죠.
12. 케이스 스터디 — '긴급' 태그가 70%인 헬프데스크
우선순위 설계의 대표적 실패, 우선순위 인플레이션을 한 시나리오로 봅니다. 어느 IT 헬프데스크 — 들어오는 티켓의 70%에 '긴급' 태그가 붙어 있는데, 실제로 긴급한 건 10% 미만입니다. 모두가 '긴급'을 외치니, '긴급'은 아무 의미가 없어졌죠.
이 시나리오가 이번 편의 축소판입니다. 다중 기준(4절 MCDM)으로 점수화하고, 내용 분석(10절 하이브리드 엔진)으로 가짜 긴급을 거르고, P0 quota로 인플레이션을 막습니다. 좋은 우선순위는 곧 "진짜 중요한 소수를 가려내, 그것에 자원을 몰아주는" 설계입니다.
13. 베스트 프랙티스 — 5원칙과 안티패턴
교재는 우선순위 설계의 5가지 원칙을 제시합니다. 모두 한 방향을 가리킵니다 — 투명하고, 적응적이고, 추적 가능하게.
특히 우선순위 인플레이션을 경계하세요 — 모든 작업이 P0이면 우선순위 체계 자체가 무너집니다. P0 quota(P0 비율 상한)를 두고, '긴급' 태그가 아니라 실제 내용으로 판정하며, 가중치와 부여 근거를 감사 로그에 남기세요. 그리고 기아 방지로 낮은 우선순위도 언젠가는 처리되게 보장해야 합니다 — 우선순위는 '버리는 것'이 아니라 '순서를 정하는 것'이니까요.
순서대로 쪼개고(체이닝), 갈래를 나누고(라우팅), 병렬로 돌리고(병렬화), 스스로 비평하고(리플렉션), 도구를 쥐고(도구 사용), 계획하고(플래닝), 팀을 이루고(멀티 에이전트), 기억하고(메모리), 배우고(학습), 표준으로 연결되고(MCP), 스스로 채점하고(목표 설정), 넘어져도 일어서고(예외 처리), 사람을 부르고(휴먼 인 더 루프), 근거로 말하고(RAG), 협업하고(A2A), 비용을 설계하고(자원 인식), 깊이 생각하고(추론 기법), 안전하게 말하고(가드레일), 스스로를 측정하던(평가·모니터링) 에이전트 — 이번엔 무엇을 먼저 할지 줄 세우는 법(우선순위 설정)을 배웠습니다. 긴급과 중요를 가르고(Eisenhower), 여러 기준을 가중하고(MCDM), 상황에 맞춰 재조정하고(동적 재우선순위화), SLA로 시간을 다스리는(Time-to-SLA) 트리아지죠. 그런데 지금까지의 모든 패턴은 "주어진 문제를 잘 푸는" 것이었습니다. 마지막 질문은 다릅니다 — "풀어야 할 문제 자체를, AI가 스스로 찾아낼 수는 없을까?" 다음 편은 시리즈의 종착점, 탐색·발견(Exploration & Discovery): 가설을 생성하고, 토론하고, 진화시키며, '질문에 답하는 AI에서 질문을 찾아내는 AI로' 나아가는 법입니다.
- Python 공식 문서 — heapq (우선순위 큐)
- LangGraph 공식 문서 — StateGraph·조건부 엣지·MemorySaver
- Google ADK 공식 문서 — Workflow Agents(Sequential·Loop)
- Atlassian — SLA(Service Level Agreement) 개념 가이드
- Antonio Gulli, Agentic Design Patterns — Ch.20 Prioritization
'Agentic AI Design Patterns' 카테고리의 다른 글
| CH18-똑똑한 AI일수록 위험하다 — 에이전트에 '안전벨트'를 채우는 가드레일 설계 (0) | 2026.06.17 |
|---|---|
| CH21-질문에 답하는 AI에서, 질문을 찾아내는 AI로 — AI 자율 탐색·발견 설계 (시리즈 완결) (0) | 2026.06.15 |
| CH19-AI 에이전트 평가 3수준과 LLM-as-a-Judge — 정확도부터 Trajectory·드리프트 탐지까지 Python·LangGraph·ADK로 (1) | 2026.06.14 |
| CH17-AI가 답하기 전에 '생각'하게 만드는 법 — 추론 기법 CoT·ToT·ReAct 완전 해부 (0) | 2026.06.13 |
| CH16-가장 비싼 모델이 항상 정답은 아니다 — AI 에이전트 비용을 설계하는 자원 인식 최적화 (0) | 2026.06.12 |