[arXiv 2606.20236] MAMO: 다중 에이전트가 보상 가중치를 학습하는 제약 최적화

A Multi-Agent system for Multi-Objective constrained optimization

https://arxiv.org/abs/2606.20236

Federica Filippini | University of Milano-Bicocca | AAMAS 2026 OptLearnMAS 워크숍 | arXiv:2606.20236 | 2026년 6월 18일 제출

---

1. 서론: 보상 가중치를 누가 정할 것인가

1.1 비용 최소화와 성능 제약이 충돌하는 문제

컴퓨팅과 네트워킹 시스템의 많은 의사결정 문제는 비용을 낮추면서 성능 제약을 만족해야 하는 최적화 문제로 나타난다. 클라우드 자원 사용료, 에너지 소비, 실행 시간, 함수 복제본 생성 비용은 낮추고 싶지만, deadline, 처리량, 응답 시간, 거절 확률 같은 QoS 조건은 지켜야 한다. MAMO가 겨냥하는 지점은 바로 이 충돌이다.

논문이 특히 강조하는 배경은 computing continuum이다. 클라우드, 엣지, 포그, 단말 자원이 함께 움직이면 workload, bandwidth, resource availability가 계속 바뀐다. 설계 시점에 한 번 푼 offline optimization은 운영 중 금방 낡고, 정교한 queueing model이나 deterministic model만으로 모든 상태 전이를 설명하기 어렵다. 그래서 runtime에서 경험으로 정책을 고치는 reinforcement learning이 자연스러운 후보가 된다.

하지만 RL을 constrained optimization에 넣는 순간 흔한 타협이 등장한다. 원래 문제는 “비용은 최소화, 제약 위반은 금지 또는 제한”이라는 구조인데, RL agent는 보통 하나의 scalar reward를 받아 학습한다. 그래서 비용과 제약 위반을 weighted sum으로 합쳐 $r(s,a,s')=1-C(s,a,s')$ 같은 형태를 만든다. 이때 가중치가 곧 시스템의 가치 판단이 된다.

가중치를 사람이 정하면 문제가 단순해 보이지만, 실제로는 매우 불안정하다. 거절 확률 penalty를 크게 두면 agent는 replica를 많이 띄워 QoS를 지키지만 비용을 크게 쓴다. 반대로 비용 항을 크게 두면 replica를 줄여 값싸게 운영하지만 요청 거절이 늘어난다. 논문의 핵심 질문은 이 trade-off를 사람이 고정하지 말고 agent가 학습하게 만들 수 있는가다.

1.2 MAMO의 핵심 아이디어

MAMO, 즉 Multi-Agent system for Multi-Objective constrained optimization은 문제 해결 agent와 보상 설계 agent를 분리한다. 낮은 층의 Task-Execution agent는 환경에서 실제 행동을 고르고, 높은 층의 Weight-Adaptation agent는 TE agent가 사용할 reward weight를 고른다. 행동을 직접 통제하는 agent와 “무엇을 중요하게 볼지”를 조절하는 agent를 다른 시간축에 놓는 구조다.

이 분리는 실용적으로 중요하다. 기존 RL 구현은 scalar reward만 있으면 DQN, policy gradient, actor-critic 등 익숙한 알고리즘을 그대로 쓸 수 있다. MAMO는 이 장점을 버리지 않는다. TE agent는 여전히 weighted reward를 최적화한다. 대신 그 weight가 더 이상 수작업 hyperparameter로 머물지 않고, WA agent가 장기 성능 지표를 보고 선택하는 학습 대상이 된다.

논문은 이 구조를 edge-FaaS replica scaling 예제로 보여 준다. function request rate가 변하고, edge node 자원이 제한되며, 너무 적은 replica는 rejection을 만들고, 너무 많은 replica는 cold-start와 resource cost를 만든다. MAMO는 이 환경에서 평균 거절 확률을 tolerance 아래로 유지하면서 비용을 낮추는 weight를 찾는 방향으로 작동한다.

1.3 논문의 위치

이 연구는 대규모 benchmark 논문이라기보다는 초기 framework 제안과 proof-of-concept에 가깝다. 실험은 single-function FaaS scaling으로 단순화되어 있고, baseline도 offline optimizer, noisy workload, 고정 weight 선택과의 비교 중심이다. 그 대신 문제 설정이 명확하다. reward engineering 자체를 또 하나의 sequential decision problem으로 보고, 이를 명시적 multi-agent architecture로 푼다.

중요한 메시지는 “reward weight는 부차적인 튜닝값”이라는 습관을 깨는 데 있다. constrained optimization에서 weight는 cost와 QoS 사이의 운영 정책을 압축한다. 따라서 weight를 고정하면 정책의 유연성이 제한되고, non-stationary condition에서는 trade-off가 쉽게 어긋난다. MAMO는 이 압축된 정책 선택을 runtime adaptation problem으로 다시 열어 둔다.

2. 배경 및 관련 연구: weighted reward와 objective adaptation의 접점

2.1 Computing continuum과 edge-FaaS scaling

Computing continuum에서는 cloud data center처럼 자원이 사실상 풍부한 장소와 edge node처럼 자원이 제한된 장소가 함께 쓰인다. 지연에 민감한 처리는 edge에 두고, 무거운 처리는 cloud로 넘기는 식의 분산 운영이 가능하지만, 그만큼 workload와 resource 상태가 빠르게 바뀐다. 논문은 이 상황을 constrained cost minimization의 대표 사례로 본다.

Function-as-a-Service 환경에서는 애플리케이션이 stateless function으로 쪼개지고, 요청이 들어오면 function instance가 만들어져 실행된다. 요청이 많아지면 replica 수를 늘려야 queueing과 rejection을 줄일 수 있다. 그러나 edge node는 memory와 compute capacity가 제한되어 있고, 새 replica를 띄우는 과정에는 cold-start overhead가 있다. 따라서 replica 수 $n_f$는 응답성과 자원 효율 사이의 결정을 담는다.

cloud-only autoscaling과 edge autoscaling의 차이는 over-provisioning 가능성에서 두드러진다. cloud에서는 replica를 넉넉히 띄워 latency를 낮추는 전략이 종종 가능하지만, edge에서는 과한 복제가 곧 자원 고갈과 성능 저하로 이어진다. 그래서 edge-FaaS scaling은 “load가 늘면 replica를 늘린다”는 단순 규칙을 넘어, 제약 조건을 보면서 비용을 최소화하는 동적 제어 문제가 된다.

2.2 Weighted reward와 Lagrangian식 사고

constrained optimization을 RL로 옮길 때 흔한 방식은 제약 위반을 penalty로 바꿔 reward 안에 넣는 것이다. 예를 들어 실행 비용 항과 rejection probability 항을 더해 cost function을 만들고, reward를 $1-C$로 정의한다. 이 방식은 Lagrangian relaxation과 유사한 사고를 따른다. hard constraint를 직접 다루기 어렵다면, 위반 정도에 가중치를 붙여 목적함수에 포함하는 것이다.

문제는 이 가중치가 고정되면 agent의 행동 양식도 고정된다는 점이다. $w$가 rejection penalty에 크게 걸리면 agent는 보수적으로 행동하고, $w$가 작으면 비용 절감에 치우친다. non-stationary workload에서는 같은 $w$도 시간에 따라 의미가 달라진다. workload 변동이 작을 때 적절했던 weight가 갑자기 queueing risk를 키울 수 있다.

MAMO는 weighted scalar reward를 버리지 않는다. 오히려 weighted reward가 구현상 편하고 기존 RL 알고리즘과 잘 맞는다는 점을 활용한다. 차이는 weight selection을 외부 설계자의 직감에서 WA agent의 학습 정책으로 옮긴다는 데 있다. 이 때문에 MAMO는 reward shaping, multi-objective RL, bi-level learning 사이에 걸쳐 있다.

2.3 관련 연구 흐름과 MAMO의 차이

관련 연구는 크게 네 갈래로 정리할 수 있다. 첫째, optimal reward design은 agent 내부 reward를 외부 성능을 높이는 설계 변수로 본다. 둘째, meta-learning intrinsic reward는 meta-gradient나 population-based method로 학습 신호를 조정한다. 셋째, bi-level reward shaping은 내부 learner와 외부 reward parameter update를 nested optimization으로 다룬다. 넷째, multi-objective RL은 vector reward와 preference 또는 scalarization weight를 다룬다.

MAMO의 차별점은 자유로운 reward network를 학습하지 않고, 해석 가능한 저차원 scalarization weight만 조정한다는 것이다. 또한 WA agent는 TE agent의 parameter update를 미분하지 않는다. TE training horizon이 끝난 뒤 평균 비용과 평균 rejection probability 같은 summary를 보고 다음 weight를 고른다. 이는 coarser control이지만, inner solver가 DQN이든 다른 RL이든 상대적으로 붙이기 쉽다.

연구 흐름	일반적인 목표	MAMO와의 관계	해석 포인트
Optimal reward design	내부 reward parameter를 조정해 외부 성능 향상	reward가 설계 대상이라는 관점을 공유	MAMO는 풍부한 reward function 대신 weight vector에 집중
Meta-learned intrinsic reward	meta-gradient나 reward network로 학습 신호 변경	학습 신호를 동적으로 바꾼다는 점이 유사	MAMO는 더 구조화되고 해석 가능한 형태
Bi-level / meta-gradient RL	inner learner를 고려해 outer parameter update	TE-WA 구조가 bi-level 형식과 맞닿음	MAMO는 inner learner를 미분하지 않는 model-free outer loop
Multi-objective RL	여러 objective와 preference vector를 다룸	scalarization weight를 다룬다는 점이 공통	MAMO는 preference를 외생값으로 고정하지 않고 WA action으로 둠
Multi-agent intrinsic reward	여러 agent의 reward를 나눠 coordination 개선	reward signal을 agent별로 다룬다는 점이 연결	MAMO의 WA는 환경 행동자와 달리 objective-design supervisor

3. 방법론: TE와 WA로 분리한 계층형 보상 설계

3.1 기준 문제: replica scaling의 정식화

논문은 function 집합을 $\mathcal{F}=\{1,\dots,F\}$로 두고, function $f$에 대해 선택할 replica 수를 $n_f$로 둔다. incoming workload는 $\lambda_f$, replica 생성 비용은 $c_f$, 최대 replica 수는 $N_f$, 요청 거절 확률은 $p(\lambda_f,n_f)$로 표기한다. 목표는 replica 비용을 줄이되, rejection probability가 tolerance $tol$보다 커지지 않게 하는 것이다.

최적화 문제는 다음처럼 압축된다. 목적함수는 $\min \sum_{f\in\mathcal{F}} c_f n_f$이고, 제약은 $0 \leq n_f \leq N_f$와 $p(\lambda_f,n_f) \leq tol$이다. RL 환경에서는 이를 scalar cost로 바꾸어 $C(s,a,s')=\sum_{f\in\mathcal{F}}(w_f^0 c_f n_f/N_f + w_f^1 p(\lambda_f,n_f))$처럼 사용한다. 모든 weight는 $[0,1]$ 범위이고 $\sum_{i,f} w_f^i=1$이다.

구성 요소	논문 표기	의미	MAMO에서의 역할
Function set	$\mathcal{F}=\{1,\dots,F\}$	edge node에 배치 가능한 function 집합	실험에서는 단일 function으로 단순화
Decision variable	$n_f$	function $f$의 replica 수	TE agent의 action으로 선택됨
Objective	$\min \sum_f c_f n_f$	replica 초기화 비용 최소화	cost 항으로 reward에 포함
Capacity constraint	$0 \leq n_f \leq N_f$	최대 replica 수 제한	TE action space의 범위 결정
QoS constraint	$p(\lambda_f,n_f) \leq tol$	요청 거절 확률 제한	WA feedback의 핵심 성능 지표
Scalar reward	$r=1-C$	비용과 penalty를 하나로 합친 reward	WA가 $w$를 바꾸면 TE의 학습 목표가 바뀜

3.2 MAMO architecture: TE와 WA의 분업

MAMO는 두 agent가 서로 다른 관찰과 action을 갖는다. TE agent는 매 control period마다 workload 같은 현재 상태를 보고 replica 수를 선택한다. TE는 선택된 weight가 고정된 동안 weighted reward를 최적화하는 일반 RL agent처럼 행동한다. 반면 WA agent는 환경에 replica action을 직접 보내지 않는다. WA는 TE 학습 결과를 요약한 평균 비용과 평균 거절 확률을 보고 다음 weight를 고른다.

Figure 1: MAMO architecture

Figure 1은 MAMO의 가장 중요한 구조적 선택을 보여 준다. TE agent는 환경과 빠르게 상호작용하며 정책을 갱신하고, WA agent는 그 결과를 한 단계 위에서 해석해 reward weight를 바꾼다. 따라서 WA는 직접 replica를 늘리거나 줄이지 않고, TE가 어떤 비용 항을 더 중요하게 학습할지를 조절한다. 이 구조 덕분에 task solving과 objective design이 명시적으로 분리되며, reward engineering이 별도 control loop로 올라간다는 논문 주장이 한 장에 압축된다.

항목	Task-Execution agent	Weight-Adaptation agent	왜 나누는가
시간축	control step마다 환경과 상호작용	TE training horizon 뒤에 weight 선택	행동 학습과 보상 조정을 안정적으로 분리
관찰	현재 system state와 workload	평균 비용, 평균 rejection probability	WA가 장기 지표를 보도록 함
action	replica 수 $n_f$ 선택	reward weight $w_f^i$ 선택	행동 policy와 objective policy를 분리
보상	weighted cost 기반 scalar reward	QoS 만족 여부와 비용 summary 기반 피드백	수작업 penalty tuning을 줄임
해석 가능성	선택된 weight 아래의 control policy	cost-QoS trade-off를 나타내는 weight policy	learned reward design을 수치로 관찰 가능

3.3 두 단계 반복 workflow

MAMO의 반복 과정은 단순하다. 첫 번째 단계에서 WA agent가 weight를 하나 고르고, 그 weight를 일정 training horizon 동안 고정한다. 이 동안 TE agent는 환경과 상호작용하면서 weighted reward를 최적화한다. 두 번째 단계에서 TE 학습이 끝나면, WA agent는 TE가 낸 평균 비용과 평균 거절 확률을 관찰하고 weight 선택의 품질을 평가한다. 이후 WA는 다음 weight를 고르고 새 TE training phase가 시작된다.

이 구조는 reward shaping을 매우 직접적인 control problem으로 바꾼다. WA의 action은 “다음 episode에서 어떤 weight를 쓸 것인가”이고, WA의 state는 “이전 weight로 TE가 어떤 평균 성능을 냈는가”다. 따라서 WA는 TE의 action sequence를 micromanage하지 않고, TE가 학습할 objective landscape를 조절한다.

논문에서 single-function 실험은 더 단순한 형태를 쓴다. rejection probability 항에 weight $w$를 곱하고, cost 항에는 $1-w$를 곱한다. 즉 $w$가 커질수록 QoS 위반 회피가 더 중요해지고, $w$가 작아질수록 replica 비용 절감이 더 중요해진다. WA action space는 $0.01$ 간격으로 discretize되어 있어, WA는 해석 가능한 scalar weight를 선택한다.

3.4 WA의 state와 피드백

WA agent가 보는 정보는 TE의 raw trajectory 전체를 모두 펼친 기록이 아니라 summary다. 실험에서는 TE agent evaluation의 마지막 300 step에서 평균 execution cost와 평균 request rejection probability $\overline{p}$를 계산한다. $\overline{p}$가 tolerance $0.05$를 넘으면 해당 weight는 제약을 만족하지 못한 것으로 취급되어 좋지 않은 선택이 된다. 반대로 QoS 조건을 만족하면 cost가 낮은 선택이 선호된다.

흥미로운 점은 논문이 per-function hard constraint를 실험 구현에서는 observation window 평균으로 완화했다는 점이다. 원래 수식은 각 function마다 $p(\lambda_f,n_f) \leq tol$을 요구하지만, 구현에서는 평균 rejection probability를 본다. 저자도 이 검사가 덜 엄격하다고 설명한다. 그럼에도 TE의 전체 행동이 QoS 요구를 어느 정도 만족하는지 보는 high-level indicator로는 의미가 있다.

4. 실험 설정: edge-FaaS scaling에서 trade-off를 고립시키기

4.1 단일 function edge-FaaS 환경

실험은 MAMO의 weight adaptation 효과를 분리해서 보기 위해 single function $f$만 고려한다. 따라서 weight도 rejection probability에 곱해지는 단일 $w$로 줄어든다. workload $\lambda_f$는 diurnal pattern을 흉내 내는 sinusoidal trace를 따른다. TE agent의 action은 현재 control step에서 replica 수 $n_f$를 고르는 것이고, 최대 replica 수는 $N_f=10$으로 설정된다.

저자는 OpenFaaS community edition에서 legacy scaling 기본 상한이 $N_f=5$라는 점을 언급하면서, action space를 넓히기 위해 추가 5개 replica를 더해 $10$으로 둔다. cold execution time은 $1.0s$, warm execution time은 $0.1s$이며, idle replica는 $60s$ 동안 비활성 상태이면 종료된다. 이 설정은 cold-start 비용과 over-provisioning 비용을 동시에 드러내기 위한 단순 환경이다.

실험 조건	설정값	논문 내 목적	해석
Function 수	1개	weight adaptation 효과 분리	다중 function 우선순위 문제는 아직 제한적
Workload trace	sinusoidal $\lambda_f$	diurnal non-stationarity 모사	분석 가능하면서도 시간 변화가 있음
Replica limit	$N_f=10$	TE action space 확보	OpenFaaS CE의 5개 제한보다 넓게 둠
Cold / warm time	$1.0s$ / $0.1s$	replica 생성 overhead 반영	cost-QoS trade-off를 더 분명하게 만듦
Idle timeout	$60s$	비활성 replica 종료	과도한 scaling을 장기 cost로 연결
QoS tolerance	$tol=0.05$	거절 확률 제한	WA가 만족해야 할 핵심 threshold

4.2 비교 절차와 평가 trace

실험은 네 단계로 진행된다. 먼저 Gurobi 12.0.2로 각 $\lambda_f$ 값에 대해 offline optimization을 풀어 perfect knowledge 아래의 낮은 비용 기준선을 만든다. 평가 trace 길이는 600 step이다. 다음으로 workload를 uniform noise $[0.9,1.1]$로 perturb하여, 기대 workload에서 계산한 solution이 실제 noisy load에서는 어떤 rejection probability를 내는지 본다.

그다음 TE agent를 fixed weight 두 개, $w=0.99$와 $w=0.1$로 따로 학습·평가한다. 이 비교는 manual weight가 policy를 얼마나 극단적으로 바꾸는지 보여 주는 장치다. 마지막으로 full MAMO를 실행한다. 초기 weight는 $w=0.99$이고, TE training phase는 현재 weight 아래에서 15k iteration 동안 지속된다. WA는 마지막 300 step의 평균 $\overline{p}$와 평균 cost를 관찰한다.

이 평가 설계의 장점은 offline optimum, noisy evaluation, fixed-weight baseline, adaptive-weight MAMO가 같은 toy scenario 위에서 놓인다는 점이다. 단점은 workload와 function 수가 단순해 real edge platform의 heterogeneity를 충분히 담지 못한다는 것이다. 따라서 결과는 MAMO가 가능성을 보였는가에 가깝고, production-grade autoscaler를 완성했다는 주장으로 읽으면 안 된다.

4.3 DQN 구현과 하이퍼파라미터

두 agent는 RL4CC를 사용해 학습되며, RL4CC는 Ray RLlib 기반의 open-source library다. TE와 WA 모두 Deep Q-Learning으로 구현된다. neural network는 fully connected 3-layer 구조 $[256,128,256]$을 사용하고, discount factor는 $\gamma=0.7$, learning rate는 $5\times10^{-4}$다. prioritized replay buffer capacity는 10240이며 target network는 1000 step마다 갱신된다.

하이퍼파라미터	설정	적용 대상	해석
Algorithm	Deep Q-Learning	TE, WA	discrete action space와 잘 맞음
Network	$[256,128,256]$ fully connected	TE, WA	간단한 환경에 충분한 근사기
Discount factor	$\gamma=0.7$	TE, WA	장기 보상보다 가까운 feedback을 비교적 크게 봄
Learning rate	$5\times10^{-4}$	TE, WA	논문이 명시한 공통 학습률
Replay buffer	prioritized, capacity 10240	TE, WA	중요 transition 재사용
Target update	1000 step마다	TE, WA	DQN 학습 안정화
Exploration	$\varepsilon$-greedy piecewise schedule	TE, WA	15k MAMO cycle과 동기화
WA action grid	0.01 step	WA	해석 가능한 weight search 공간

WA action space를 $0.01$ 단위로 나눈 선택은 이 논문에서 특히 중요하다. continuous control을 쓰지 않아도, $w=0.80$, $0.85$, $0.90$ 같은 값의 의미를 사람이 읽을 수 있다. MAMO가 내놓은 결과가 단순 black-box policy가 아니라 어느 정도의 penalty weight가 적절한지라는 운영적 언어로 변환되기 때문이다.

4.4 평가 설계에서 읽어야 할 세부 조건

평가 trace가 600 step이라는 점은 결과 해석에 중요하다. TE agent는 학습 중의 return만 보는 것이 아니라, 별도의 evaluation trace에서 replica 수와 rejection probability를 관찰한다. 이 분리는 training noise와 policy quality를 어느 정도 나누는 장치다. 다만 600 step은 다양한 seasonal pattern과 burst pattern을 모두 덮기에는 짧을 수 있다. 따라서 결과는 sinusoidal workload 주변의 local robustness를 보여 준다고 보는 편이 안전하다.

또한 noise를 $[0.9,1.1]$ uniform multiplier로 주는 방식은 workload uncertainty를 단순하고 대칭적으로 만든다. 실제 edge workload는 갑작스러운 flash crowd, long-tail request gap, 지역 이벤트, network jitter, upstream failure처럼 비대칭적인 변동을 가질 수 있다. MAMO가 이런 heavy-tailed regime에서도 같은 방식으로 weight를 찾을지는 별도 검증이 필요하다. 현재 실험은 controlled non-stationarity에서 architecture가 작동함을 보이는 수준이다.

그럼에도 이 단순화는 장점도 있다. workload pattern을 너무 복잡하게 만들면 WA가 weight를 잘못 골랐는지, TE가 state-action mapping을 잘못 배웠는지, 환경 모델 자체가 지나치게 어렵기 때문인지 구분하기 힘들다. 논문은 먼저 weight adaptation이 policy behavior에 어떤 영향을 주는지 고립시킨다. 이 점에서 실험은 production benchmark보다 mechanism demonstration에 가깝다.

평가 설계 요소	논문 선택	장점	주의점
Evaluation length	600 step	fixed trace에서 policy 비교가 쉬움	장기 seasonal change 검증은 부족
Noise model	$U(0.9,1.1)$ multiplier	expected workload와 actual workload 차이를 명확히 만듦	burst와 tail risk는 약하게 표현
Single function	하나의 $w$만 학습	weight 의미가 투명함	function priority와 vector weight 문제는 제외
Offline oracle	Gurobi solution	비용 하한 기준선 제공	perfect information 가정 때문에 runtime policy와 직접 동등하지 않음

5. 주요 실험 결과: 고정 weight의 한계와 MAMO의 중간 지대

5.1 Offline optimizer와 noisy workload

offline optimization은 perfect knowledge의 기준선 역할을 한다. 각 workload 값에 대해 Gurobi가 문제를 풀면, tolerance $0.05$를 만족하는 최소 replica 수를 알 수 있다. 그러나 실제 운영에서는 expected workload와 observed workload가 같지 않다. 논문은 $\lambda_f$를 $[0.9,1.1]$ uniform noise로 perturb하여, 기대값 기반 solution이 평균적으로는 괜찮아 보여도 순간적인 violation을 만들 수 있음을 보인다.

Figure 2: offline optimization으로 얻은 replica 수 $n_f$

Figure 2는 expected workload를 알고 있을 때 필요한 replica 수가 시간에 따라 어떻게 움직이는지 보여 준다. 이는 TE agent가 도달해야 할 이상적인 정책의 낮은 비용 기준선에 가깝다. 하지만 이 곡선은 noise가 없는 정보를 기반으로 하므로 실제 운영의 불확실성을 모두 흡수하지 못한다. 그래서 이 결과는 “offline oracle이 보는 최소 복제 패턴”으로 읽어야 하며, runtime adaptation의 필요성이 사라졌다는 뜻은 아니다.

Figure 3: offline solution의 rejection probability

Figure 3은 같은 offline solution을 실제 perturb된 workload에서 평가했을 때의 거절 확률을 보여 준다. 평균적으로는 tolerance 근처를 유지하더라도 일부 구간에서 constraint violation 위험이 생길 수 있다. 이 그림은 “모델을 한 번 풀어 둔 해”가 dynamic edge 환경에서 충분하지 않다는 점을 강조한다. MAMO의 runtime weight adaptation은 바로 이 틈을 줄이려는 시도다.

5.2 고정 weight가 만드는 극단적 정책

논문은 TE agent를 $w=0.99$와 $w=0.1$로 따로 학습시켜 weight의 의미를 보여 준다. single-function 설정에서 $w$는 rejection probability penalty에 걸린다. $w=0.99$는 QoS 위반을 매우 강하게 벌하는 설정이고, $w=0.1$은 rejection penalty보다 replica cost를 더 중시하는 설정이다. 두 결과는 manual weight tuning이 세부 설정을 넘어 정책 자체를 바꾸는 decision임을 보여 준다.

Figure 4: $w=0.99$로 학습한 TE agent

Figure 4의 $w=0.99$ 조건은 rejection penalty가 큰 경우를 나타낸다. TE agent는 QoS violation을 피하기 위해 더 보수적인 replica 선택을 하는 방향으로 학습된다. 이 경우 거절 확률을 낮추는 데는 유리하지만, replica 수와 execution cost가 올라갈 수 있다. 따라서 이 그림은 고정 weight가 안전해 보이는 정책을 만들 수는 있어도, edge 환경에서 중요한 자원 효율을 쉽게 희생한다는 점을 보여 준다.

Figure 5: $w=0.1$로 학습한 TE agent

Figure 5의 $w=0.1$ 조건은 반대로 replica cost를 더 강하게 의식하는 정책을 만든다. TE agent는 replica를 덜 쓰는 쪽으로 움직일 수 있고, 그 결과 cost는 낮아지지만 rejection probability가 tolerance를 넘을 위험이 커진다. 두 fixed-weight 결과를 나란히 보면, 수작업 weight 선택이 과보수와 과공격 사이에서 쉽게 흔들린다는 문제가 분명해지며, WA agent가 중간 weight를 학습해야 하는 동기가 생긴다.

5.3 MAMO의 수렴: $w=0.8$에서 $0.9$ 사이

full MAMO에서는 WA agent가 TE training phase마다 weight를 다시 고른다. 논문은 WA training이 진행되면서 TE 평가에서 관찰되는 평균 rejection probability $\overline{p}$가 $0.05$ 근처로 접근하고, weight가 $0.8$에서 $0.9$ 사이 값으로 수렴한다고 보고한다. 이는 MAMO가 $w=0.99$처럼 지나치게 보수적이지도, $w=0.1$처럼 제약을 자주 어기는 방향도 아닌 중간 지대를 찾았다는 뜻이다.

Figure 6: WA training 동안의 평균 rejection probability

Figure 6은 WA agent가 training cycle을 거치며 weight 선택을 조정하는 과정을 요약한다. 검은 horizontal line으로 표시된 TE 평가 결과가 tolerance $0.05$에 가까워지는 패턴은, WA가 단순히 penalty를 크게 키우는 대신 threshold 근처의 비용 효율적인 구간을 찾고 있음을 시사한다. 이 결과는 MAMO의 핵심 주장인 learned trade-off를 가장 직접적으로 보여 준다.

Figure 7: 대표 scenario에서 $w=0.85$일 때의 상세 solution

Figure 7은 MAMO가 찾은 weight 영역을 대표하는 $w=0.85$ scenario의 세부 행동을 보여 준다. replica 수는 offline perfect-knowledge solution보다 약간 높을 수 있지만, noisy workload에서도 rejection probability를 $0.05$ 아래로 일관되게 유지하는 방향으로 움직인다. 따라서 MAMO의 이득은 최저 비용 자체보다 불확실성 아래의 안정적인 QoS 만족에서 나온다.

비교 대상	주요 설정	관찰 결과	해석
Offline optimizer	Gurobi, perfect expected workload	낮은 replica cost 기준선 제공	noise가 있으면 violation 대응이 필요
Noisy evaluation	$\lambda_f\times U(0.9,1.1)$	평균 성능은 유지되어도 구간별 risk 존재	non-stationarity를 반영한 adaptation 필요
Fixed $w=0.99$	rejection penalty 매우 큼	QoS에는 유리하나 비용 증가 가능	과보수 정책의 사례
Fixed $w=0.1$	cost 절감을 상대적으로 중시	rejection probability 위반 위험 증가	과공격 정책의 사례
MAMO	WA가 $w$를 학습적으로 선택	$w=0.8$~$0.9$ 근처로 수렴, $\overline{p}\approx0.05$	비용과 QoS 사이의 adaptive compromise

핵심 결과는 숫자 하나보다 방향성에 있다. MAMO는 manual weight를 없애지는 않지만, weight search를 system feedback에 닫힌 loop로 만든다. 사람이 “어느 정도 penalty가 좋을까”를 미리 정하는 대신, WA가 TE 성능 summary를 보고 weight를 조정한다. 이 때문에 MAMO는 reward tuning을 offline 설계 업무에서 online control 업무로 바꾸는 접근으로 읽힌다.

6. 추가 분석 및 Ablation Study: weight sensitivity와 정보 병목

6.1 논문에서 사실상 ablation 역할을 하는 비교

논문이 대규모 ablation table을 제공하지는 않는다. 대신 fixed weight $w=0.99$와 $w=0.1$, offline optimum, noisy evaluation, full MAMO의 비교가 사실상 ablation 역할을 한다. 여기서 제거되는 요소는 WA의 adaptive weight selection이다. WA 없이 $w$를 고정하면, 같은 TE agent라도 reward weight에 따라 정책이 크게 달라진다.

이 비교는 MAMO의 필요조건을 보여 준다. 만약 모든 weight가 비슷한 정책을 만들었다면 WA agent를 둘 이유가 약하다. 하지만 논문은 extreme weight가 서로 다른 비용-QoS profile을 만든다는 점을 먼저 보여 준다. 그다음 WA가 중간 weight 영역으로 수렴한다는 결과를 제시한다. 구조적으로 보면 weight가 중요하고, 따라서 weight를 학습할 가치가 있다는 논리다.

분석 축	변경 또는 비교	관찰되는 효과	MAMO 주장에 주는 의미
Weight sensitivity	$w=0.99$ vs $w=0.1$	보수/공격 정책의 차이	manual tuning이 정책을 좌우함
Noise robustness	expected workload solution을 noisy load에서 평가	offline solution의 violation risk	runtime adaptation 필요성 강조
WA outer loop	fixed weight 대신 learned weight	$0.8$~$0.9$ 구간으로 weight 이동	objective design을 agent policy로 다룰 수 있음
Observation window	마지막 300 step 평균 cost와 $\overline{p}$	WA state가 coarse summary로 제한	sample-efficient하지만 세부 violation은 가려질 수 있음
Training horizon	TE phase 15k iterations	WA action 후 충분한 TE 적응 시간 부여	두 시간축 분리의 실험적 구현

6.2 $w$가 크다는 것과 작다는 것

single-function setting에서 $w$는 rejection probability 항의 중요도다. $w$가 크면 constraint violation을 피하는 방향으로 TE reward landscape가 바뀐다. 이는 QoS-sensitive application에는 안전하지만, edge resource가 부족하거나 비용이 비싼 환경에서는 낭비를 만들 수 있다. $w$가 작으면 cost minimization이 강해져 replica를 줄이지만, queueing과 request rejection risk가 커진다.

MAMO가 $0.8$~$0.9$ 사이에 수렴했다는 사실은 이 toy environment에서 QoS penalty가 꽤 커야 한다는 신호다. 다만 $0.99$처럼 거의 전부를 QoS에 주는 것은 필요 이상으로 보수적일 수 있다. 따라서 learned weight는 “수학적으로 절대적인 최적 weight”라기보다, workload model, noise level, cost definition, tolerance가 주어진 상태에서 찾은 운영 compromise로 해석해야 한다.

6.3 두 시간축 분리의 효과

MAMO에서 가장 흥미로운 ablation 관점은 TE의 빠른 제어 시간축과 WA의 느린 objective 조정 시간축이 분리된다는 점이다. TE는 매 step action을 고르며 local state에 반응한다. WA는 15k iteration 단위의 결과를 보고 global weight를 바꾼다. 이 느린 조정은 noisy single-step feedback에 과하게 반응하지 않도록 해 준다.

반대로 이 구조는 적응 속도 한계도 만든다. 환경 regime이 급격히 바뀌면 WA가 15k iteration을 기다리는 동안 TE는 부적절한 weight 아래에서 학습할 수 있다. 따라서 future work에서는 WA cycle length, observation window, abrupt workload shift에 대한 sensitivity를 봐야 한다. 현재 논문은 이 부분을 깊게 탐색하지 않는다.

6.4 보이지 않는 ablation: 더 필요한 비교

추가로 보고 싶은 비교는 세 가지다. 첫째, random search나 grid search로 $w$를 고르는 전략과 MAMO의 sample efficiency 비교다. 둘째, Bayesian optimization이나 dual-decomposition 방식과의 비교다. 셋째, WA가 평균값만 보는 경우와 percentile, max violation, per-function violation을 보는 경우의 차이다. 저자도 향후 연구로 dual-decomposition, Bayesian optimization, Optimistic Linear Support 같은 multi-policy algorithm과의 비교를 제안한다.

특히 constrained optimization에서는 평균 $\overline{p}$만 만족해도 tail violation이 클 수 있다. 서비스 운영자는 평균 rejection probability보다 peak-time violation을 더 중요하게 볼 수 있다. 따라서 MAMO의 다음 단계는 WA reward를 어떤 risk measure로 정의할지다. reward weight adaptation만큼이나 outer reward design 자체도 중요한 설계 문제가 된다.

6.5 WA state representation이 만드는 정보 병목

WA가 보는 state를 평균 cost와 평균 rejection probability로 줄이면 학습은 쉬워진다. state dimension이 낮고, weight action의 결과를 한눈에 비교할 수 있기 때문이다. 그러나 이 요약은 temporal structure를 버린다. 같은 평균 $\overline{p}=0.04$라도 모든 step이 고르게 안정적인 policy와, 대부분은 0에 가깝다가 특정 peak에서 크게 튀는 policy는 운영 의미가 다르다. 평균 summary는 이 둘을 구분하지 못한다.

따라서 MAMO를 더 강하게 만들려면 WA state를 약간 더 풍부하게 만드는 방향이 필요하다. 예를 들어 최근 window의 maximum rejection, 95th percentile rejection, cost variance, scale-up frequency, cold-start count, replica churn 같은 지표를 추가할 수 있다. 이 지표들은 WA가 “비용은 낮지만 불안정한 policy”와 “조금 비싸지만 안정적인 policy”를 구분하게 만든다. 다만 state가 복잡해질수록 WA sample complexity도 늘어난다.

이 trade-off는 MAMO의 본질적인 설계 문제다. WA가 너무 많은 정보를 보면 outer loop 자체가 또 하나의 복잡한 RL 문제가 되고, 너무 적은 정보를 보면 제약 위반의 중요한 패턴을 놓친다. 논문은 첫 단계로 가장 단순한 summary를 선택했지만, 실제 적용에서는 WA state abstraction이 성능과 안전성을 동시에 좌우할 가능성이 크다.

6.6 비용 항의 의미도 domain마다 달라진다

실험에서 cost는 replica 초기화와 실행 부담을 단순화한 값으로 쓰인다. 하지만 domain이 바뀌면 cost의 의미도 달라진다. public cloud에서는 monetary cost가 중요할 수 있고, private edge cluster에서는 energy consumption이나 thermal budget이 더 중요할 수 있다. telco edge에서는 radio access network 상태와 backhaul congestion이 cost에 포함될 수 있다. 따라서 MAMO의 weight adaptation을 다른 domain에 옮기려면 cost term 자체를 다시 정의해야 한다.

이 점 때문에 MAMO는 reward weight만 자동으로 찾는 도구라기보다, objective decomposition을 전제로 하는 framework다. 사람이 먼저 cost와 constraint violation을 측정 가능한 항으로 분해해야 하고, WA agent는 그 항들 사이의 scalarization을 학습한다. 즉 MAMO는 목표 항목의 발명을 자동화하지 않는다. 이미 정의된 목표 항목의 상대적 중요도를 runtime에서 조정한다.

6.7 운영 평가 프로토콜로 다시 보면

MAMO 결과를 운영 시스템 관점에서 읽으려면, 단순히 최종 weight가 어느 값에 수렴했는지보다 weight가 바뀌는 동안 어떤 검증 절차가 필요한지를 먼저 봐야 한다. WA agent는 평균 비용과 평균 rejection probability를 보고 다음 weight를 제안하지만, production autoscaler라면 이 제안이 바로 적용되기 전에 별도의 검증 구간을 거치는 편이 안전하다. 예를 들어 candidate weight를 shadow policy로 실행해 실제 action은 내보내지 않고, 같은 workload trace에서 어떤 replica 결정을 냈을지 기록할 수 있다. 이 기록을 현재 production policy와 비교하면 비용 감소분, rejection 증가분, scale-up 빈도, cold-start 증가분을 동시에 측정할 수 있다.

이 관점에서 WA agent의 출력은 “최종 제어 명령”보다 새로운 reward configuration 제안에 가깝다. TE agent가 실제 replica 수를 고르는 빠른 경로에 있다면, WA는 운영 정책을 바꾸는 느린 경로에 있다. 느린 경로는 더 넓은 관찰과 검증을 거쳐야 한다. 논문 실험에서는 15k iteration cycle과 300-step summary가 이 역할을 맡지만, 실제 시스템에서는 cycle을 시간 단위, request volume 단위, 또는 regime change detection 단위로 정의할 수 있다. 중요한 것은 WA update가 너무 잦으면 noise에 흔들리고, 너무 느리면 workload 변화에 뒤처진다는 점이다.

또한 MAMO를 운영에 붙이려면 evaluation trace를 하나로 고정하기보다 여러 trace family로 나누는 편이 좋다. 정상 diurnal trace, 저녁 peak trace, sudden burst trace, edge node 자원 감소 trace, cold-start가 길어지는 trace를 따로 두고, WA가 제안한 weight가 각각에서 어떤 실패 양상을 내는지 확인해야 한다. 논문은 sinusoidal workload와 uniform perturbation으로 첫 단계를 보여 주지만, 실제 검증에서는 이보다 다양한 stress case가 필요하다.

운영 검증 항목	MAMO에서 연결되는 값	확인해야 할 이유	권장 측정 방식
Cost delta	평균 execution cost	WA가 비용을 낮췄는지 확인	기존 weight 대비 window별 상대 변화
SLA violation	$\overline{p}$와 $tol$	평균 기준 만족 여부 확인	평균, 최대, 95th percentile 동시 기록
Replica churn	TE action sequence	잦은 scale-up/down이 cold-start와 불안정성을 만들 수 있음	단위 시간당 replica 변경 횟수
Regime robustness	WA policy의 weight 선택	특정 trace에만 맞춘 weight인지 확인	여러 workload family에서 shadow evaluation

6.8 WA reward 설계와 risk metric의 선택

MAMO에서 가장 조심해야 할 부분은 WA reward다. TE reward는 비용과 rejection probability를 weighted sum으로 합친다. WA reward는 그 weight 선택이 좋았는지를 판단한다. 따라서 MAMO에는 reward 설계가 두 번 등장한다. 첫 번째는 TE가 보는 scalar reward이고, 두 번째는 WA가 보는 outer feedback이다. 논문은 outer feedback을 단순하게 두어 framework를 명확히 보여 주지만, 실제 시스템에서는 이 outer reward가 전체 안전성을 좌우할 수 있다.

예를 들어 WA가 평균 rejection probability만 본다면, 짧은 peak violation을 충분히 벌하지 못할 수 있다. 반대로 maximum violation만 강하게 벌하면, TE가 필요 이상으로 많은 replica를 유지해 비용이 커질 수 있다. 그래서 WA reward는 평균과 tail을 함께 보아야 한다. 평균 $\overline{p}$, 95th percentile, max violation, violation duration, 연속 violation 길이 같은 지표를 조합하면 service operator가 실제로 신경 쓰는 위험에 더 가깝게 맞출 수 있다.

이 지점은 Lagrangian식 penalty tuning과도 연결된다. 고전적인 constrained optimization에서는 multiplier가 constraint violation을 반영해 조정된다. MAMO의 WA agent는 그 multiplier 조정을 RL policy로 바꾸는 셈이다. 그러나 multiplier가 올라가거나 내려가는 규칙이 안정적이지 않으면, TE는 계속 바뀌는 objective 아래에서 학습해야 한다. 따라서 WA reward의 scale, clipping, update frequency, exploration schedule이 모두 중요한 안정화 장치가 된다.

결국 MAMO의 핵심 난점은 “TE agent가 좋은가”만으로 닫히지 않는다. WA가 어떤 실패를 실패로 인식하는가가 더 근본적인 질문이다. 서비스 운영에서는 비용 초과와 SLA 위반의 비대칭성이 크다. 비용을 조금 더 쓰는 것은 허용되지만, 짧은 시간의 대량 rejection은 큰 장애로 이어질 수 있다. 따라서 MAMO의 후속 연구는 WA reward를 risk-aware objective로 확장하는 방향이 자연스럽다.

6.9 Multi-function으로 확장할 때 생기는 문제

논문은 단일 function 설정으로 시작한다. 이 선택은 weight 의미를 깨끗하게 만든다. $w$ 하나만 보면 cost와 rejection penalty 사이의 균형을 바로 해석할 수 있다. 그러나 실제 edge-FaaS 플랫폼에는 여러 function이 함께 올라간다. 각 function은 memory footprint, cold-start time, request distribution, business priority가 다르다. 이 경우 weight는 scalar 하나가 아니라 function별 cost weight와 violation weight를 포함하는 vector가 된다.

vector weight가 되면 WA action space가 빠르게 커진다. function이 $F$개이고 각 function마다 cost와 rejection penalty가 있으면, 단순 grid search는 거의 불가능해진다. WA가 정책을 학습해야 하는 이유는 여기서 더 강해진다. 다만 action space가 커지면 DQN 기반 discrete action만으로 충분한지도 다시 봐야 한다. continuous actor-critic, parameterized action, low-rank weight factorization 같은 방법이 필요할 수 있다.

또 하나의 문제는 function 간 priority다. 어떤 function은 사용자-facing API라 rejection을 거의 허용할 수 없고, 다른 function은 batch preprocessing이라 약간의 delay가 괜찮을 수 있다. WA가 모든 function의 평균 rejection만 보면 높은 priority function의 실패를 낮은 priority function의 성공이 가릴 수 있다. 따라서 multi-function MAMO에서는 per-function SLA와 service class를 함께 넣어야 한다.

이 확장은 MAMO를 PCMA와 다시 연결한다. PCMA가 agent별 preference coordination을 다루듯, multi-function MAMO는 objective component별 preference coordination을 다룬다. 차이는 여전히 TE와 WA의 역할 분리다. TE는 각 function의 replica action을 고르고, WA는 function별 weight vector를 조정한다. 이런 구조가 가능하려면 WA state가 function별 summary를 충분히 보존하면서도 학습 가능한 크기로 압축되어야 한다.

6.10 재현성 관점에서 필요한 기록

MAMO 같은 계층형 RL 실험은 재현성 기록이 특히 중요하다. TE agent의 random seed, WA agent의 exploration schedule, workload perturbation seed, evaluation trace, DQN replay buffer 설정이 모두 결과에 영향을 줄 수 있다. 논문은 주요 하이퍼파라미터를 제시하지만, 후속 연구에서는 cycle별 selected weight, 평균 cost, 평균 rejection probability, TE evaluation return을 table이나 artifact로 함께 공개하면 더 좋다.

특히 WA가 $0.8$~$0.9$ 사이로 수렴했다는 결과는 강한 메시지를 갖지만, 그 수렴 경로가 얼마나 안정적인지는 seed별 분포를 봐야 한다. 어떤 seed에서는 $0.82$ 근처, 다른 seed에서는 $0.91$ 근처로 안정화된다면 운영자는 이를 tolerance band로 받아들일 수 있다. 반대로 seed마다 전혀 다른 weight를 선택한다면 WA policy의 안정성에 의문이 생긴다. 따라서 mean curve뿐 아니라 confidence interval 또는 seed별 trajectory가 필요하다.

또한 offline optimizer와 RL policy의 비교는 정보 조건이 다르다. Gurobi solution은 workload knowledge를 가진 기준선이고, TE는 noisy runtime 관찰 아래에서 행동한다. 두 결과를 같은 표에 둘 때는 “oracle lower bound”, “fixed-weight learned policy”, “adaptive-weight learned policy”처럼 정보 접근 수준을 명확히 구분해야 한다. 이 구분이 있어야 MAMO가 oracle을 이기지 못했다는 사실보다, uncertainty 아래에서 제약을 지키려는 방법이라는 핵심이 더 정확히 전달된다.

7. 한계점 및 향후 연구 방향: toy scenario를 넘어서는 검증 과제

7.1 실험 규모와 일반화의 한계

가장 큰 한계는 실험 규모다. single function, sinusoidal workload, 단일 edge node를 쓰는 단순 scenario에서는 MAMO의 구조적 가능성을 확인할 수 있지만, multi-function priority, heterogeneous resource, bursty traffic, real cold-start distribution, network contention까지 포함한 현실 문제와는 거리가 있다. 따라서 논문의 결과를 “MAMO가 모든 constrained optimization 문제에서 우월하다”로 읽으면 과하다.

또한 TE와 WA 모두 DQN을 사용했기 때문에 action space가 discrete인 설정에 자연스럽게 맞춰져 있다. 실제 시스템에서는 replica 수 외에도 CPU share, memory limit, placement, batching, admission control처럼 continuous 또는 combinatorial action이 섞일 수 있다. MAMO architecture 자체는 inner solver 독립성을 주장하지만, 그 주장은 더 다양한 solver와 domain에서 검증되어야 한다.

7.2 WA reward와 constraint 평가 방식

WA가 평균 execution cost와 평균 rejection probability만 본다는 점도 한계다. 이는 state dimension을 낮춰 학습을 쉽게 만들지만, 세부적인 violation pattern을 숨길 수 있다. 예를 들어 평균은 $0.05$ 아래인데 특정 workload peak에서 rejection이 크게 튀는 policy는 실제 SLA 관점에서 받아들이기 어렵다. per-window maximum, percentile, CVaR 같은 risk-aware summary를 넣는 확장이 필요하다.

또 하나의 미묘한 지점은 WA feedback의 부호와 scale이다. 논문은 rejection probability가 tolerance를 넘으면 reward를 zero로 두고, 만족하면 execution cost를 사용한다고 설명한다. 비용은 낮을수록 좋은 quantity이므로, 실제 구현에서 이를 어떻게 maximize-compatible signal로 바꾸는지 명확한 표현이 더 필요하다. 후속 논문에서는 WA objective를 수식과 코드 수준에서 더 투명하게 제시하는 편이 좋다.

7.3 향후 비교와 확장

저자는 향후 연구로 다른 application domain 평가와 weight-selection baseline 비교를 제안한다. 특히 dual-decomposition, Bayesian optimization, Optimistic Linear Support 같은 방법은 MAMO의 위치를 더 정확히 잡는 데 필요하다. MAMO가 좋은 결과를 내려면 단순히 “adaptive”라는 장점만으로는 부족하고, 같은 sample budget에서 더 빠르게 좋은 trade-off를 찾는다는 근거가 필요하다.

한계	현재 논문 상태	필요한 후속 실험	중요한 이유
Domain scale	single-function FaaS toy scenario	multi-function, multi-node, real trace	실제 edge operation에 가까워짐
Baseline breadth	offline optimizer와 fixed weight 중심	Bayesian optimization, dual methods, MORL baselines	MAMO의 상대적 효율 검증
Constraint metric	평균 rejection probability	tail risk, per-function SLA, peak violation	운영 SLA와 더 잘 맞음
Timescale	TE 15k iteration cycle	cycle length sensitivity, abrupt shift response	non-stationary 환경에서 적응 속도 확인
Solver diversity	TE와 WA 모두 DQN	actor-critic, constrained RL, model-based TE	architecture의 solver-agnostic 주장 검증

8. 내 해석: reward governance 계층으로 본 MAMO

8.1 PCMA와의 연결: preference coordination과 시간축 분리

이 논문은 이전에 정리한 [[entities/papers/learning-coordinated-preference-for-multi-objective-multi-agent-reinforcement-learning-2606-14693]]의 PCMA와 나란히 놓고 보면 더 잘 보인다. PCMA는 multi-objective multi-agent reinforcement learning에서 agent별 preference를 어떻게 조율할지에 초점을 둔다. 즉 여러 environment-acting agent가 각자의 preference를 가진 상태에서 coordination을 학습하는 문제에 가깝다.

반면 MAMO는 task execution과 reward-weight adaptation을 두 시간축으로 분리한다. TE agent는 현재 objective 아래에서 행동 policy를 학습하고, WA agent는 느린 주기로 objective weight를 바꾼다. 그래서 PCMA가 “여러 agent의 preference를 어떻게 맞출 것인가”를 묻는다면, MAMO는 “하나의 task-solving agent가 어떤 reward trade-off 아래에서 학습해야 하는가를 누가 어떻게 고를 것인가”를 묻는다.

이 차이는 multi-agent라는 단어의 의미를 바꾼다. PCMA에서 multi-agent는 주로 환경에서 함께 행동하는 agent들의 coordination 문제다. MAMO에서 multi-agent는 환경 행동자와 objective designer를 분리한 계층적 역할 분담이다. 따라서 MAMO의 WA agent는 teammate라기보다 supervisor 또는 reward architect에 가깝다.

8.2 Reward engineering을 운영 제어로 바꾸는 접근

MAMO의 가장 좋은 점은 reward engineering을 “실험자가 notebook에서 튜닝하는 일”에서 벗어나 “운영 중 관찰 가능한 feedback으로 닫힌 제어 loop”로 바꾼다는 점이다. 많은 RL 시스템에서 reward weight는 논문 부록의 하이퍼파라미터처럼 취급된다. 하지만 constrained optimization에서는 그 숫자가 서비스의 비용 정책과 SLA 정책을 동시에 담는다. 따라서 weight가 학습 가능한 정책이 되는 것은 자연스러운 확장이다.

물론 모든 reward tuning을 agent에게 맡기면 위험하다. WA의 outer objective가 부정확하면, TE가 더 잘 학습할수록 잘못된 방향으로 최적화될 수 있다. 그래서 MAMO는 “보상 설계를 자동화하면 끝”이라는 수준에 머물지 않고, 보상 설계 문제를 더 명시적으로 모델링하자는 제안으로 읽어야 한다. 명시적으로 모델링하면 어떤 summary를 보고, 어떤 threshold를 만족하며, 어떤 cost를 줄이는지 따져 볼 수 있다.

8.3 왜 multi-agent framing인가

단순히 $w$를 outer loop에서 grid search하면 되지 않을까라는 의문이 생길 수 있다. toy scenario에서는 실제로 grid search나 Bayesian optimization도 강한 baseline이 될 수 있다. MAMO가 multi-agent framing을 택하는 이유는 weight selection을 repeated decision으로 보기 때문이다. 환경이 변하고, TE policy가 weight에 따라 달라지며, WA가 과거 성능 summary를 보고 다음 weight를 선택한다면 이는 sequential decision problem의 형태를 갖는다.

이 framing의 장점은 확장 가능성이다. function이 여러 개가 되고, 각 function마다 cost와 rejection penalty weight가 생기며, workload regime이 바뀌면 단일 scalar grid search는 빠르게 복잡해진다. WA agent는 performance summary에서 weight vector로 가는 policy를 학습할 수 있으므로, 장기적으로는 adaptive scalarization policy로 확장될 여지가 있다.

8.4 실무적으로 중요한 질문

실무 관점에서 MAMO가 바로 던지는 질문은 세 가지다. 첫째, 우리 시스템에서 비용과 violation의 weight는 누가 정하는가. 둘째, 그 weight는 workload 변화에 따라 자동으로 바뀌어야 하는가. 셋째, weight를 자동으로 바꾼다면 어떤 guardrail이 필요한가. MAMO는 이 세 질문에 “WA agent”라는 답을 제시하지만, guardrail 설계까지 완전히 해결하지는 않는다.

따라서 적용한다면 WA action range, update frequency, rollback rule, SLA hard limit, human override가 함께 필요하다. 예를 들어 WA가 비용 절감을 위해 $w$를 낮추더라도, peak rejection이 특정 상한을 넘으면 즉시 conservative weight로 되돌리는 안전장치가 있어야 한다. MAMO architecture는 이런 운영 정책을 붙일 수 있는 틀로는 좋지만, 안전성 자체를 보장하는 알고리즘은 아니다.

해석 축	PCMA 관점	MAMO 관점	내가 보는 차이
Preference의 위치	환경에서 행동하는 agent별 preference	TE reward 안의 scalarization weight	PCMA는 agent 간 조율, MAMO는 objective 설계 조율
Multi-agent 의미	여러 행동 agent의 coordination	TE와 WA의 계층적 분업	MAMO의 WA는 supervisor에 가까움
시간축	preference coordination이 policy 학습과 얽힘	TE 빠른 학습, WA 느린 weight adaptation	MAMO의 핵심은 timescale separation
운영 의미	복수 agent의 multi-objective coordination	cost와 QoS 사이 reward tuning 자동화	MAMO는 autoscaling reward governance에 가까움
확장 위험	agent 간 preference conflict	WA objective misspecification	둘 다 alignment 문제가 다른 층에 나타남

8.5 운영 배포 관점의 설계 패턴

MAMO를 실제 시스템에 붙인다면 WA agent는 production control plane의 일부가 된다. TE agent는 data plane에 가까운 빠른 action을 만들고, WA는 control plane에서 reward configuration을 조정한다. 이 구분은 observability와 auditability에도 도움이 된다. replica action이 이상해졌을 때 “TE policy가 문제인가, WA가 weight를 잘못 줬는가”를 나눠 추적할 수 있기 때문이다.

특히 cloud와 edge 운영에서는 정책 변경의 설명 가능성이 중요하다. 사람이 만든 autoscaling rule은 threshold와 cooldown을 읽으면 대략 이해할 수 있다. RL policy는 그렇지 않다. MAMO는 적어도 outer level에서 $w$라는 해석 가능한 숫자를 제공한다. 운영자는 $w$가 올라가면 QoS penalty를 더 중시하고, 내려가면 cost 절감을 더 중시한다고 해석할 수 있다. 이 interpretable control knob이 MAMO의 실무적 장점이다.

다만 해석 가능한 숫자가 있다고 해서 안전한 것은 아니다. $w=0.85$가 어떤 workload regime에서 안전하더라도, traffic burst가 훨씬 커지면 같은 값이 부족할 수 있다. 따라서 WA policy에는 drift detection, anomaly detection, emergency fallback이 결합되어야 한다. MAMO의 outer loop는 정책을 바꾸는 권한을 갖기 때문에, 권한이 큰 만큼 guardrail도 강해야 한다.

좋은 배포 형태는 WA가 바로 production weight를 바꾸는 방식보다 shadow mode에서 먼저 candidate weight를 평가하는 방식에 가깝다. 예를 들어 현재 production TE policy를 유지하면서, offline simulator나 canary environment에서 WA가 제안한 weight를 평가하고, SLA 위반 위험이 낮을 때만 점진적으로 적용한다. 이렇게 하면 MAMO의 adaptation 장점을 살리면서도 sudden policy shift의 위험을 줄일 수 있다.

배포 설계 요소	권장 방향	MAMO와의 연결	실패 시 위험
Shadow evaluation	WA weight를 simulator나 canary에서 먼저 평가	outer action의 안전성 검증	검증 없이 적용하면 SLA 위반 가능
Fallback policy	peak violation 때 conservative weight로 복귀	WA exploration의 위험 완화	나쁜 weight가 장시간 유지될 수 있음
Audit log	weight, summary metric, TE outcome 기록	objective adaptation의 추적 가능성 확보	장애 원인 분석이 어려워짐
Human override	운영자가 WA action range를 제한	learned policy와 운영 정책의 접점	business priority를 반영하지 못함

결국 MAMO의 실무적 가치는 “RL이 알아서 잘한다”는 주장보다, objective adaptation을 독립된 계층으로 떼어 내어 관찰하고 제어할 수 있게 만든다는 데 있다. reward weight가 바뀌면 비용, latency, rejection이 어떻게 바뀌는지 기록할 수 있고, 운영자는 그 기록을 바탕으로 WA의 action space와 reward를 다시 조정할 수 있다. 이 feedback loop 자체가 중요한 설계 자산이다.

9. 결론: 수작업 penalty tuning에서 학습 가능한 objective policy로

9.1 논문이 보여 준 것

MAMO는 constrained optimization에서 reward weight를 수작업으로 고정하는 관행을 비판하고, 이를 학습 가능한 decision으로 바꾼다. TE agent는 기존 RL 방식대로 scalar weighted reward를 최적화하고, WA agent는 TE의 장기 성능 summary를 보고 weight를 선택한다. 이 단순한 계층 구조만으로도 edge-FaaS toy scenario에서 cost와 rejection probability 사이의 균형을 자동으로 찾을 수 있음을 보인다.

실험적으로는 MAMO가 $w=0.8$~$0.9$ 근처에 수렴하고, noisy workload에서도 평균 rejection probability를 tolerance $0.05$ 아래로 유지하는 방향을 학습한다는 결과가 핵심이다. fixed $w=0.99$는 과보수적이고, fixed $w=0.1$은 constraint violation 위험이 크다. MAMO는 이 둘 사이에서 QoS를 지키며 비용을 과하게 쓰지 않는 compromise를 찾는다.

9.2 무엇을 아직 증명하지 못했나

다만 이 결과는 preliminary다. single function과 sinusoidal workload에서의 성공은 real-world edge autoscaling으로 곧장 확장되지 않는다. strong baseline과의 정량 비교, 다양한 workload regime, multi-function priority, tail SLA, 다른 RL solver와의 조합이 아직 필요하다. 따라서 MAMO의 현재 가치는 완성된 optimizer보다 objective adaptation architecture의 출발점에 있다.

그럼에도 논문의 방향은 설득력이 있다. constrained RL에서 reward weight는 성능을 좌우하는 핵심 정책 변수인데, 이를 사람이 한 번 정해 놓고 끝내기에는 환경이 너무 동적이다. MAMO는 이 문제를 agent architecture로 드러내고, weight 선택을 관찰 가능한 feedback에 연결한다. 이 점이 이 논문의 가장 큰 기여다.

10. 요약 정리: reward weight adaptation으로 읽는 MAMO의 핵심

• 문제 설정: MAMO는 비용 최소화와 QoS 제약이 함께 존재하는 constrained optimization에서 weighted reward의 가중치를 사람이 정해야 하는 부담을 다룬다. 특히 edge-FaaS scaling처럼 workload와 자원 상태가 계속 바뀌는 환경에서는 고정 weight가 쉽게 과보수 또는 과공격 정책을 만든다.
• 핵심 아이디어: Task-Execution agent는 replica 수 같은 실제 action을 고르고, Weight-Adaptation agent는 TE가 학습할 reward weight를 느린 주기로 조정한다. 이 분업은 task solving과 objective design을 분리해 reward tuning을 관찰 가능한 학습 문제로 바꾼다.
• 방법론적 위치: MAMO는 optimal reward design, meta-reward learning, bi-level RL, multi-objective RL과 연결되지만 자유로운 reward network를 만들지 않는다. 대신 해석 가능한 scalarization weight를 조정하므로 운영자가 weight 변화의 의미를 읽을 수 있다.
• 실험 환경: 논문은 single-function edge-FaaS scaling을 사용해 효과를 고립한다. $N_f=10$, cold execution time $1.0s$, warm execution time $0.1s$, idle timeout $60s$, tolerance $0.05$ 조건에서 sinusoidal workload와 noisy perturbation을 평가한다.
• 주요 결과: fixed $w=0.99$는 QoS를 강하게 지키지만 비용이 커질 수 있고, fixed $w=0.1$은 비용을 줄이나 rejection 위험을 키운다. MAMO의 WA agent는 $w=0.8$~$0.9$ 부근의 중간 영역으로 이동하며 평균 rejection probability를 tolerance 근처 또는 아래로 유지하는 방향을 찾는다.
• 해석 포인트: 이 논문의 기여는 완성된 autoscaler를 제시하는 데보다 reward weight를 운영 정책 변수로 드러내는 데 있다. weight가 바뀌면 TE policy의 비용·QoS 균형이 바뀌므로, MAMO는 objective adaptation을 별도 계층으로 관찰하고 조정하는 설계 패턴으로 읽힌다.
• PCMA와의 연결: PCMA가 다중목표 다중에이전트 RL에서 agent별 preference coordination을 다뤘다면, MAMO는 환경 행동자와 reward-weight supervisor를 나누는 timescale separation을 다룬다. 두 논문 모두 preference와 objective가 정책 학습을 좌우한다는 사실을 다른 구조에서 보여 준다.
• 한계: 현재 실험은 single function, sinusoidal workload, 평균 rejection probability 중심의 toy scenario다. multi-function priority, bursty workload, tail SLA, risk-aware WA reward, Bayesian optimization이나 dual-decomposition 같은 강한 baseline과의 비교가 필요하다.
• 후속 방향: MAMO를 실제 시스템에 붙이려면 shadow evaluation, conservative fallback, audit log, human override가 함께 필요하다. WA agent는 production weight를 직접 바꾸는 권한을 갖기 때문에, 학습 가능한 objective policy와 운영 guardrail을 한 묶음으로 설계해야 한다.