Next-Token Prediction을 넘어서: Atlassian 워크플로 tool-use 에이전트를 위한 RLVR 개념 증명 (RLVR PoC for Atlassian Tool-Use)

Digest: LLM은 인터넷 규모 텍스트의 next-token likelihood로 최적화되었을 뿐 “특정 API 표면 안에서 행동하도록” 최적화된 적이 없다는 objective mismatch가 이 논문의 문제의식이다. 이 불일치는 enterprise SaaS 워크플로에서 필수 필드 누락, tool 이름 환각, 첫 read 직후 조기 종료 같은 silent failure로 드러난다. 핵심 통찰은 tool-use는 출력 자체가 구조화된 tool call이므로 인자 값과 호출 순서를 프로그램으로 직접 검사할 수 있고, 따라서 learned reward model 없이 RLVR을 대상 환경 안에서 바로 돌릴 수 있다는 것이다. 방법은 Jira REST v3와 Confluence v2 계약을 wire format 수준에서 모사한 합성 환경 5종(P1 schema fidelity·P2 stateful but resettable·P3 determinism·P4 verifiability)을 짓고, 보상을 R1 per-argument correctness + R2 validate–mutate–verify 구조 보너스 − R3 penalty로 분해해 tool-call trace만으로 $[0, 1]$ 스칼라를 뽑은 뒤 TRL의 GRPO로 학습하는 것이다. 실험은 prompted Qwen3-1.7B / Qwen3.5-4B baseline을 학습 때와 동일한 checker로 채점해 비교한다. 핵심 수치로 비퇴화 4개 시나리오에서 4B baseline 0.35–0.92가 RL 정책 0.95–1.00으로 올라가며, 최대 상승은 Confluence page creation 0.35 → 1.00(+0.65), 이어 labeling 0.52 → 0.95, sub-task creation 0.68 → 1.00, cross-product 0.92 → 1.00이다. 결정적 증거는 Appendix A의 rollout 대조로, read 두 번만 하고 끝나던 step 0 정책(0.00)과 parent를 문자열로 넣어 중복 create를 5회 반복하던 batch 2 정책(0.52)이 batch 53에서 중첩 인자까지 정확한 단일 create 쌍(1.00)으로 수렴한다. 함의는 live API 없이 sub-second checker만으로 소형 모델을 특정 API 표면에 정렬시킬 수 있다는 것. 한계는 시나리오당 프롬프트 6–12개에 held-out 평가가 전무하고, ticket-transition 보상은 호출당 +0.25에 상한 1.0이라는 결함으로 4B가 이미 포화하며, hand-crafted 보상이 Atlassian 전체 엔드포인트로 확장되지 않는다는 것이다.

먼저 이해하기

이 논문은 “LLM에게 Jira 티켓을 만들라고 시켰을 때 자꾸 필드를 빠뜨리거나 이상한 도구를 부르는 문제”를 강화학습으로 고칠 수 있는가를 작은 규모로 실증한 6쪽짜리 개념 증명이다. 핵심 장치는 진짜 Jira/Confluence 서버를 부르지 않고, 그 API의 모양만 똑같이 흉내 낸 가짜 서버를 파이썬 몇백 줄로 만들어 그 안에서 학습을 돌리는 것이다.

왜 가짜 서버냐면, RL 학습은 같은 프롬프트에 대해 수십 번 시도를 반복하면서 잘한 시도에 가점을 주는 방식이라 진짜 API를 쓰면 비용·rate limit·상태 오염이 감당이 안 되기 때문이다. 그리고 tool-use는 채점이 유난히 쉽다 — 모델이 뱉은 것이 자연어 문장이 아니라 create_issue(fields={"project": {"key": "ABC"}, ...}) 같은 구조화된 호출이므로, 정답 딕셔너리와 키 단위로 대조하면 “부분 점수”까지 기계적으로 계산된다. 사람이 라벨을 달 필요도, 다른 LLM에게 채점을 맡길 필요도 없다. 이것이 RLVR(Reinforcement Learning with Verifiable Rewards)이 수학·코드에서 성공한 이유이고, 이 논문은 그 레시피를 “기업용 SaaS API 호출”이라는 표면으로 옮긴다.

보상 설계는 세 덩어리다. (1) 정답 인자 하나 맞출 때마다 0.10~0.15씩 주고, (2) “먼저 읽고 → 그다음 쓰고 → 마지막에 확인”이라는 올바른 작업 순서를 지키면 보너스를 주고, (3) 필수 create를 빠뜨리거나 같은 걸 두 번 만들거나 존재하지 않는 도구 이름을 지어내면 감점한다. 이 셋을 더한 뒤 $[0, 1]$ 로 clamp한 스칼라가 GRPO의 보상이 된다.

왜 중요한가: 기존 agent RL 문헌의 벤치마크는 open web(WebArena), software engineering(SWE-bench), 혹은 광범위한 agentic suite(AgentBench, AppWorld)에 몰려 있다. 반면 “리소스를 확인한 뒤 그것을 변경한다”는 좁고 schema-heavy한 enterprise 패턴은 학계 관심을 거의 못 받았다. 이 논문이 올린 하한선은 성능 자체가 아니라 비용 구조다 — 환경이 파이썬 수백 줄, 보상 계산이 sub-second, 학습이 4B 모델 + GPU 2장 + 100 batch 이내라면, “그 API에 특화된 소형 정책을 그때그때 굽는다”는 접근이 현실적 선택지로 들어온다. 다만 저자들 스스로 이를 “preliminary step”이자 “proof of concept”으로 규정하며, 일반화 증거는 제시하지 않는다.

먼저 알아둘 용어 표

원 용어	쉬운 설명
RLVR	사람 라벨이나 학습된 보상모델 대신, 프로그램으로 정오를 확인할 수 있는 보상으로 하는 RL
tool call / function calling	모델이 자연어 대신 `함수이름(인자=값)` 형태의 구조화된 호출을 출력하는 것
schema fidelity	가짜 환경이 진짜 API의 요청·응답 스키마(필드 이름·중첩 구조)를 그대로 따르는 성질
GRPO	한 프롬프트의 rollout 그룹 안에서 상대 우위를 계산해 critic 없이 정책을 갱신하는 RL 알고리즘
validate–mutate–verify	읽어서 존재 확인 → 변경 → 다시 읽어 확인, 이라는 enterprise 자동화의 표준 3단계
rollout	한 프롬프트에 대해 정책이 끝까지 생성한 하나의 tool-call 시퀀스
degenerate reward	보상 설계가 허술해 별 노력 없이 만점이 나오는 상태. 여기선 ticket-transition
silent failure	에러 없이 그럴듯한 호출을 하지만 필드가 틀려 실제로는 실패한 상태

섹션별 요약

Abstract

LLM은 다음 토큰을 예측하도록 학습되었지 특정 API 안에서 행동하도록 학습되지 않았다. 올바른 엔드포인트를 올바른 중첩 인자로 올바른 순서에 호출해야 성공인 niche enterprise SaaS 워크플로에서, 이 objective mismatch는 필수 필드 누락·tool 환각·첫 read 후 조기 종료 같은 silent failure로 나타난다. 저자들은 RLVR을 대상 환경 안에서 직접 적용해 이 격차를 메울 수 있는지 묻는다. Jira REST v3와 Confluence v2 API를 schema fidelity 수준에서 모사한 합성 환경 5종을 짓고, 보상을 전적으로 tool-call trace에서 계산한다 — live API 없음, learned judge 없음, human label 없음. prompted Qwen3-1.7B와 Qwen3.5-4B를 학습에 쓴 것과 동일한 checker로 채점했을 때, 보상이 비퇴화인 4개 시나리오에서 RL 학습 정책은 4B baseline 범위 0.35–0.92를 0.95–1.00으로 끌어올리며 최대 상승은 Confluence page creation의 0.35 → 1.00이다. 저자들은 이를 niche enterprise API용 소형 특화 모델을 향한 예비 단계로 위치시키고, workshop 독자가 유념해야 할 두 한계 — hand-crafted verifiable reward가 여기 보고된 소수 엔드포인트 너머로 확장되지 않는다는 점, 그리고 5개 시나리오 중 하나(ticket-transition)의 보상 형태가 포화적이라 prompted 4B가 이미 만점을 낸다는 점 — 을 전면에 내세운다.

키워드: reinforcement learning, tool use, verifiable rewards, GRPO, synthetic environments, agent evaluation, Jira, Confluence.

왜 이 연구를 하는가?

문헌의 공백이 두 겹이다. 첫째, tool invocation을 supervised fine-tuning이나 실제 API 상의 RL로 끌어내는 연구는 많지만, 공개된 RL 벤치마크는 open web(WebArena), software engineering(SWE-bench), 혹은 broad agentic suite(AgentBench, AppWorld)를 겨냥한다. “리소스를 확인한 뒤 변경한다”는 패턴이 지배하는 좁고 schema-heavy한 enterprise SaaS 워크플로는 상대적으로 방치되어 있다. 둘째, 더 깊은 문제는 목적함수 불일치다. 모델은 인터넷 텍스트의 next-token likelihood로 최적화되었으므로, Jira sub-task나 Confluence page를 만들라는 요청을 받으면 “호출의 대략적 모양”은 알지만 슬롯을 잘못 채우거나, 필수 필드를 빠뜨리거나, 첫 read 후 멈춘다. 이 행동들은 겉보기엔 유창하지만 정확성을 기준으로 채점하는 어떤 checker 아래서도 낮은 점수를 받는다(저자들은 §6의 prompted-baseline 점수가 이를 뒷받침한다고 명시).

RLVR은 여기서 자연스러운 대안이다. 보상 모델링을 프로그램적 checker로 대체하고, tool-use는 출력이 구조화된 tool call이라 인자 값과 순서를 직접 검사할 수 있으므로 특히 잘 맞는다. 저자들의 표현대로, “no live API, learned judge, or human label in the loop”인 합성 사본 안에서 outcome-level 보상으로 에이전트를 학습시키는 것이 연구 설계의 출발점이다.

Introduction

기여는 네 가지로 명시된다.

Environments — 흔한 자동화 흐름에서 쓰이는 Jira REST v3 / Confluence v2 엔드포인트를 모사한 합성 환경. issue read/create, page read/create, transition, label을 다루며 stateful parent–child 제약과 per-batch reset을 갖춘다(§3).
Verifiable reward functions — per-argument correctness, validate–mutate–verify 패턴에 대한 structural bonus, 환각·중복 호출에 대한 penalty로 분해되며 전부 tool-call trace에서 계산 가능하다(§4).
Prompted baselines — Qwen3-1.7B와 Qwen3.5-4B를 HuggingFace Inference Router로 실행해 학습 시와 동일한 reward checker로 채점(§6).
End-to-end RLVR 레시피 — TRL 구현의 GRPO를 Qwen3 계열에 적용하고 convergence 기반 early-stopping callback을 붙여, 비퇴화 시나리오 전부에서 수십~수백 generation batch 안에 평균 보상 $\geq 0.95$ 에 도달. 최대 절대 상승은 schema-heavy creation 과제에서 나온다(Confluence page creation +0.65).

저자들은 결론부에서 “the recipe works on this cheap substrate”라는 proof-of-concept 성격을 명시하고, §7이 아직 확립하지 못한 것을 전면화한다고 밝힌다.

Methods

환경 설계 원칙(§3.1).

(P1) Schema fidelity — tool signature와 응답 payload가 공개 Jira REST v3 / Confluence v2 계약을 그대로 따른다. 예: sub-task 생성 시 POST /rest/api/3/issue가 fields.project.key, fields.parent.key, fields.issuetype.id="10003"을 기대한다. 여기서 학습된 정책은 실서비스와 같은 wire format을 말한다는 것이 논거.
(P2) Stateful but resettable — 각 환경이 issue·page의 mutable resource pool을 노출해 create_* 호출이 후속 get_*로 관측 가능한 side effect를 낳는다. 매 보상 계산 전에 reset_synthetic_data() hook이 pristine state를 복원해 rollout 간 상태 오염을 막는다.
(P3) Determinism — 환경에 무작위성이 없어 동일한 tool-call 시퀀스는 동일한 응답을 낳는다. 보상 귀속이 정확해지고 substrate 자체가 regression fixture가 된다.
(P4) Verifiability — 프롬프트별 ground truth가 기대 인자 값의 작은 딕셔너리라, 보상 함수가 oracle LLM을 부르거나 live service를 칠 필요가 없다.

모든 시나리오는 공통 상호작용 패턴을 공유한다: 리소스 존재를 read로 검증 → write로 상태 변경 → 마지막 read로 결과를 선택적으로 확인.

보상 함수(§4). rollout의 tool-call 리스트를 $[0, 1]$ 스칼라로 사상하는 dense 보상을 세 그룹으로 분해한다.

(R1) Per-argument correctness — gold 딕셔너리의 기대 인자마다 일치 시 작은 상수(cross-product 0.10, single-product creation은 slot당 0.10–0.15)를 준다. 지배적 신호다. sub-task 시나리오는 summary·parent.key·project.key·assignee·issuetype.id 다섯 필드가 각 0.10씩 기여해 correctness 상한이 0.50. Confluence page labeling에서는 R1이 per-label recall 항으로 바뀌어 추가된 gold label마다 0.10.
(R2) Structural bonuses — validate–mutate–verify 패턴 보상: create_* 앞의 get_*, 올바른 write, create 뒤 선택적 get_*. cross-product는 단계당 0.05, single-product creation은 per-argument 상한이 작으므로 더 높게(0.05–0.20) 튜닝해 구조 신호만으로도 학습이 일어나게 한다. 보너스는 per-platform “valid state” predicate로 gate되어, 쓸 만한 mutation 없이는 얻을 수 없다.
(R3) Penalties — 실제 API에 비용이 크거나 파괴적일 행동을 감점한다: 필수 create_* 누락, invalid payload shape, 중복 create, 환각된 tool 이름, 시나리오별 예산 초과 호출. 크기는 시나리오별 튜닝(cross-product missing create −0.25, sub-task −0.30)이고 최종 보상은 $[0, 1]$ 로 clamp된다.

학습 설정(§5). ticket transition은 Qwen3-1.7B, 나머지는 Qwen3.5-4B를 TRL 구현 GRPO로 학습한다. 프롬프트당 4–16 generation(프롬프트 예산이 큰 시나리오 4, distinct prompt가 적은 ticket-transition·labeling 16), batch당 optimisation iteration 2회, BF16, gradient accumulation 4, max completion length 2048–4096 token. reward-convergence callback이 epoch 평균 보상 delta 0.01 미만에서 patience window(5–10 epoch) 후 학습을 멈추고 체크포인트는 최근 2개만 rotate 보존한다. Hardware는 1.7B 1장 / 4B 2장(Nvidia RTX PRO 6000 Blackwell)으로, “small on-prem or single-node cloud budget”을 의도적으로 겨냥한 크기다. Baseline은 학습 때와 동일한 보상 함수로 채점하며 HuggingFace Inference Router(temperature 0.7, 25-turn cap)로 실행하고, 매 과제 사이 state reset과 tool-call 인자 dict 정규화로 직접 비교 가능하게 만든다.

발견 (Findings)

상승폭은 schema-heavy creation 과제에 집중된다. Confluence page creation 0.35 → 1.00(+0.65), Confluence labeling 0.52 → 0.95(+0.43), Jira sub-task creation 0.68 → 1.00(+0.32). 반면 baseline이 이미 강한 cross-product는 0.92 → 1.00(+0.08)로 잔여 꼬리만 닫는다.
cross-product의 +0.08은 평균이 가리는 의미가 있다. 저자들은 이 상승이 “12개 평가 프롬프트 중 8개만 완벽하던 것이 12개 전부 완벽해지는” 변화라고 명시한다. 즉 평균 보상 관점의 작은 개선이 성공률 관점에서는 67% → 100%다.
개선이 reward hacking이 아니라 behavioural이라는 증거를 call sequence로 제시한다. Appendix A가 pre-training 실패 모드 둘(read 후 조기 종료 / 잘못된 중첩 parent 뒤 중복 create_issue 연쇄)과 수렴한 trace를 대조하는데, 수렴 정책은 쓰기 전에 읽고, 중첩 인자를 정확히 만들고, 환각·중복 호출 없이 멈춘다 — 스칼라와 독립적으로 call sequence 자체에서 확인 가능하다는 것이 저자 주장.
저자 스스로 한 시나리오를 무효화한다. ticket-transition 보상은 tool call당 +0.25를 주고 1.0에서 clamp하되 과잉·환각 호출에 penalty가 없어 prompted 4B가 이미 1.00에 포화한다. 한 rollout은 transition_issue를 아홉 번 부르고도 만점을 받았다. 게다가 별개의 type bug가 gold transition id를 정수로 두고 string 스키마와 비교해, 스키마를 지킨 1.7B가 4B는 챙기는 보너스를 잃는다. 저자들은 이 시나리오를 헤드라인 주장에서 제외하고 “transparency control”로만 남긴다.
수렴은 빠르다. from-scratch 3개 시나리오가 100 generation batch 미만에서 $\geq 0.95$ 에 도달하고, 네 곡선 모두 $\leq 100$ batch 안에 0.95를 넘는다. Confluence page-creation 곡선은 warm-start된 stability trace로 16 batch에 걸쳐 1.0 근처에 평평하다.

Results

주 결과(Figure 2, 아래 표 1): 시나리오별 평균 보상을 prompted 1.7B / prompted 4B / RLVR-trained 3자로 비교하며, 학습 정책은 비퇴화 4개 시나리오 전부에서 prompted 4B를 앞선다.
모델 크기 효과: prompted baseline만 놓고 보면 1.7B → 4B 상승도 있다(page creation 0.25 → 0.35, labeling 0.16 → 0.52, sub-task 0.59 → 0.68). 그러나 RL 학습 4B가 도달한 0.95–1.00은 어느 prompted baseline보다도 높다.
학습 동역학(Figure 3): generation-batch index 대비 average group reward. 실선은 5-batch moving average, shaded band는 4-generation 그룹의 per-batch min/max다. band는 학습이 진행되며 수축하며, 저자들은 이를 정책이 low-reward rollout을 더 이상 뱉지 않게 되는 신호로 읽는다. ticket-transition은 logging schema가 거칠어 제외되었다.
정성 증거(Appendix A, Listing 1–3, 아래 표 4): 동일 cross-product 프롬프트에서 step 0(0.00) → batch 2(0.52) → batch 53(1.00)으로 이어지는 rollout 대조. 수렴 trace에는 시스템 프롬프트에 명시되지 않은 issuetype.id="10003" sub-task discriminator까지 정확히 들어간다.

Discussion

이론적 의의

이 논문의 이론적 주장은 소박하지만 명확하다: “보상을 검증 가능하게 만들 수 있는 표면에서는, 모델 규모를 키우는 대신 환경 안에서 post-training objective를 바꾸는 것이 더 큰 이득을 준다.” 근거는 두 대비다. 첫째, prompted baseline만 놓으면 1.7B → 4B라는 2.4배 규모 증가가 page creation에서 0.25 → 0.35(+0.10)를 사는 데 그친다. 반면 같은 4B에 RLVR을 적용하면 0.35 → 1.00(+0.65)로 6.5배 큰 이득이 나온다. 둘째, 상승폭이 과제 성질과 체계적으로 상관한다 — 중첩 스키마를 정확히 채워야 하는 creation 과제일수록 baseline이 낮고 RL 이득이 크며(page creation 0.35/+0.65), 순서만 맞추면 되는 과제일수록 baseline이 이미 높고 이득이 작다(cross-product 0.92/+0.08). 이는 objective mismatch가 “무엇을 해야 하는지 모르는 문제”가 아니라 “특정 API의 인자 문법을 pretrain 분포에서 배우지 못한 문제”라는 §1의 진단과 일관된다.

동시에 이 주장은 저자들이 스스로 그은 선 안에서만 성립한다. “our prompted baselines hold the base model fixed, isolating the post-training objective; they are a controlled test, not a claim that RL is the only route”라는 문장이 §7에 명시되어 있고, SFT on successful traces나 ReAct-style scaffolding, frontier model + Python REPL 같은 더 강한 대조군은 미래 과제로 남는다. 즉 이 논문이 보인 것은 “RL이 최선”이 아니라 “RL이 이 substrate에서 작동한다”이다.

Discussion Points

동일 checker로 baseline과 학습 정책을 채점하는 프로토콜은 공정성과 순환성 사이에 있다. 같은 함수로 재는 것은 비교를 직접적으로 만들지만, 보상 함수 자체가 학습 대상이므로 “학습 정책이 보상 함수를 잘 만족한다”는 결과는 부분적으로 동어반복이다. held-out 프롬프트가 없는 상태에서 이 순환을 끊어 줄 유일한 장치는 Appendix A의 call-sequence 정성 검사인데, 저자들도 정확히 그 이유로 그 부록을 배치한 것으로 읽힌다.
ticket-transition의 실패는 논문의 신뢰도를 오히려 올리는 서술 선택이다. 호출당 +0.25에 상한 1.0, 과잉 호출 무벌점이라는 설계는 전형적인 reward-hacking 취약점이고, transition_issue 9회 호출 rollout이 만점을 받았다는 사례를 저자가 직접 보고한다. 다만 “per-scenario reward-hacking audit은 미완”이라는 문장은 나머지 4개 시나리오의 보상도 유사한 결함을 가질 가능성을 열어 둔다 — 특히 R2 structural bonus가 단계당 0.20까지 올라가는 single-product creation 보상은 감사 대상 1순위로 보인다.
“12개 중 8개 → 12개 전부”라는 서술과 평균 0.92는 산술적으로 조금 어긋난다. 8개가 완벽(1.00)이고 4개가 부분 점수라면 평균 0.92를 맞추려면 나머지 4개가 평균 0.76이어야 하는데, 이는 §6의 실패 서술(wrong nested key, dropped required fields, early stop)이 함의하는 심각도보다 후하다. dense 보상 구조상 불가능하지는 않지만, 평균 보상이 실패 심각도를 체계적으로 과소 표현할 수 있음을 보여 준다.
환경이 결정적(P3)이라는 점은 학습 효율의 원천이자 전이의 최대 장애물이다. 저자들이 §7에서 인정하듯 wire format 충실성은 rate limit·eventual consistency·permission error·partial response에 대한 강건성을 보장하지 않는다. 제안된 해법(record–replay, 429/403 fault injection, 저볼륨 sandbox-tenant canary)은 합리적이지만 그 순간 P3가 깨지고 보상 귀속도 흐려지므로 현재 레시피를 그대로 옮길 수는 없다. 반대로 가장 흥미로운 후속은 저자들이 지목한 OpenAPI-driven reward synthesis로, R1은 스키마의 required 필드에서 R3는 type/enum 제약에서 기계적으로 유도하고 손으로 남는 것은 R2뿐이라는 분해다.

실험 결과 상세

표 1 — 시나리오별 prompted baseline vs RLVR-trained 평균 보상 (Figure 2)

시나리오	Prompted Qwen3-1.7B	Prompted Qwen3.5-4B	RLVR-trained	4B 대비 상승
Jira ticket transition*	0.87	1.00	1.00	+0.00 (퇴화)
Jira sub-task creation	0.59	0.68	1.00	+0.32
Confluence page creation	0.25	0.35	1.00	+0.65
Confluence page labeling	0.16	0.52	0.95	+0.43
Cross-product (Jira+Confluence)	0.87	0.92	1.00	+0.08

* ticket-transition은 보상 형태가 포화적이라 저자들이 헤드라인 주장에서 제외하고 transparency control로만 유지한다(§7).

표 2 — 합성 Atlassian 스위트의 5개 시나리오 구성 (Table 1)

시나리오	Tools	State / 제약	보상 신호
Jira ticket transition	`get_issue_summary_and_description`, `get_transitions`, `transition_issue`	issue 6개, 각각 named transition 3개와 target final state	올바른 transition id + tool 순서
Jira sub-task creation	`get_issue`, `create_issue`	parent issue 2개, user 3명; `create_issue`가 parent와 project 검증	summary·parent·project·assignee·issuetype의 필드별 정확도
Confluence page creation	`get_page`, `create_page`	3개 space에 걸친 root page 3개; `create_page`가 parent-in-space 검증	title·parentId·spaceId·body의 필드별 정확도
Confluence page labeling	`get_page_content`, `get_page_labels`, `add_labels`, `search_pages`	현실적 technical/HR/ops 본문을 가진 page 6개, 수작업 gold label set	기대 label의 recall + 워크플로 순서
Cross-product (Jira+Conf.)	`get_issue`, `create_issue`, `get_page`, `create_page` 전부	병합된 state pool; 단일 프롬프트가 sub-task와 page를 모두 요구	플랫폼별 정확도 + cross-platform 완료 보너스

시나리오당 hand-written ground-truth 인자를 가진 프롬프트 6–12개가 synthetic data layer에 있다. Tool은 OpenAI 호환 function-calling 인터페이스로 모델에 노출된다.

표 3 — Cross-product 보상 분해 (Table 2)

구성요소	값
Jira per-arg correctness (5 × 0.10)	+0.50
Confluence per-arg correctness (4 × 0.10)	+0.40
Jira structure: get-before-create, verify-after	+0.15
Confluence structure: get-before-create, verify-after	+0.15
Cross-platform completion bonus (양쪽 모두 gate)	+0.15
Missing `create_issue` / `create_page`	−0.25 each
Invalid Jira / Confluence payload	−0.25 each
Duplicate `create_issue` / `create_page`	−0.15 each
Hallucinated tool name	−0.15 each
Excess calls beyond budget (> 6)	−0.05 each

최대 양의 예산은 clamp 전 1.35이고, penalty를 뺀 뒤 $[0, 1]$ 로 clamp한다. 즉 완벽한 rollout에는 0.35만큼의 여유가 있어, 일부 구조 보너스를 놓쳐도 1.00을 받을 수 있다.

표 4 — 학습 전후 rollout 대조 (Appendix A, Listing 1–3, cross-product 시나리오)

단계	Reward	tool-call 시퀀스 요지	실패 원인
Pre-training, step 0	0.00	`get_issue("XYZ-456")` → `get_page("100")` → 턴 종료	early stop: 필수 write 호출 2개를 전혀 내지 않음
Pre-training, batch 2	0.52	`get_issue("ABC-123")` → `get_page("789")` → `create_issue(parent="ABC-123")` → `create_page(...)` → `create_issue` 4회 추가 재시도	`parent`를 bare string으로 전달(Jira v3는 `{"key": ...}` 기대) → payload-shape 실패 → 대안 형태 반복 → duplicate-create penalty
Post-training, batch 53	1.00	`get_issue("ABC-123")` → `get_page("789")` → `create_issue(parent={"key":"ABC-123"}, issuetype={"id":"10003"}, ...)` → `create_page(spaceId="PAY", parentId="789", ...)`	없음. 읽고-쓰고 정확한 중첩 인자, 환각·중복 없이 종료

프레임워크 다이어그램

flowchart TD
    A["User prompt<br/>시나리오당 6~12개"] --> B["Qwen3 policy<br/>1.7B 또는 4B, BF16"]
    B -->|tool call| C["Synthetic API<br/>Jira REST v3 + Confluence v2"]
    C -->|response| B
    C --> D["Tool-call trace<br/>호출 이름 + 인자 dict"]
    D --> E1["R1 per-argument correctness<br/>gold dict 슬롯당 0.10~0.15"]
    D --> E2["R2 structural bonus<br/>validate mutate verify 단계당 0.05~0.20"]
    D --> E3["R3 penalties<br/>누락 중복 환각 과잉호출"]
    E1 --> F["Verifiable reward<br/>합산 후 0~1로 clamp"]
    E2 --> F
    E3 --> F
    F -->|scalar reward| G["GRPO update<br/>프롬프트별 rollout 그룹 상대우위"]
    G -->|parameter update| B
    C --> H["reset synthetic data<br/>매 보상 계산 전 상태 복원"]
    H --> C
    F --> I["평가 단계<br/>동일 checker로 prompted baseline과 직접 비교"]
    I --> J["비퇴화 4개 시나리오<br/>4B 0.35~0.92 → RL 0.95~1.00"]

재현성 및 신뢰도 평가

종합등급: Evidence C / Reproducibility C

근거(Evidence C): 5개 시나리오 × 3개 조건(1.7B baseline, 4B baseline, RL 정책)이라는 매트릭스는 6쪽 workshop 논문 치고 성실하고, Appendix A의 rollout 대조는 “이득이 reward hacking이 아니라 behavioural”이라는 주장을 스칼라와 독립적으로 뒷받침한다. 저자들이 ticket-transition의 보상 설계 결함과 type bug를 자진 보고하고 헤드라인에서 제외한 서술 규율도 신뢰를 높인다. 그러나 등급을 C로 두는 이유가 넷이다. (1) held-out 평가가 전혀 없다 — 학습 프롬프트 6–12개 위에서의 수렴만 측정하며 저자들도 “does not measure generalisation to unseen prompts”라고 명시한다. (2) baseline과 학습 정책을 동일한 보상 함수로 채점하므로, 최적화 대상과 평가 지표가 분리되지 않는다. (3) 모든 수치가 단일 런 점 추정이며 신뢰구간·시드별 분산이 없다. (4) 대조군이 prompted base model뿐이라 SFT, ReAct scaffolding, frontier model 같은 자명한 대안이 비교되지 않았다(저자들도 §7에서 인정).
근거(Reproducibility C): 보상이 tool-call 리스트의 결정적 함수이고(P3), 환경이 재설정 가능하며, Table 1–2와 §3.3·§5·Appendix A가 substrate를 “at the level needed to reimplement it” 기술한다는 저자 주장은 방향은 타당하다. 그러나 코드·환경 저장소 URL이 논문에 없다(§7 Reproducibility 문단은 재구현 지침만 언급). 또 (a) learning rate·KL 계수·GRPO clip 등 핵심 최적화 하이퍼파라미터가 없고, (b) generations per prompt(4–16), max completion length(2048–4096), penalty·R2 보너스 크기(0.05–0.20)가 전부 범위로만 주어져 시나리오별 실제 값을 특정할 수 없으며, (c) random seed와 학습 epoch 수가 없고, (d) single-product 3개 시나리오의 보상 분해표가 없다. 결정적 환경이라는 장점에도 정확한 수치 재현은 불가능하다.

주장별 신뢰도

“비퇴화 4개 시나리오에서 RL 정책이 4B baseline 0.35–0.92를 0.95–1.00으로 올린다” — 신뢰도 높음. Abstract, §6.1 본문, Figure 2 막대값이 세 곳에서 일치하며(0.68→1.00, 0.35→1.00, 0.52→0.95, 0.92→1.00), 채점 프로토콜(동일 checker, state reset, 인자 dict 정규화)이 §6.1에 명시된다. 단, “동일 checker” 자체가 최적화 대상이라는 한계는 별개 문제.
“최대 상승은 Confluence page creation 0.35 → 1.00” — 신뢰도 높음. Abstract·§1 기여 목록·§6.1·Figure 2에서 반복되며 +0.65라는 차분도 일치.
“이득이 reward hacking이 아니라 behavioural이다” — 신뢰도 중간. Appendix A의 세 rollout(0.00 / 0.52 / 1.00)이 강한 정성 증거지만, cross-product 시나리오 하나의 프롬프트에서 뽑은 대표 사례일 뿐 통계가 아니다. 저자들 스스로 “per-scenario reward-hacking audits as unfinished work”라 남긴 상태이므로, 나머지 시나리오에 대해서는 검증되지 않았다.
“레시피가 held-out 프롬프트로 일반화된다” — 논문이 주장하지 않음. §7 첫 항목이 명시적으로 부인한다. 이 논문에서 “성능”으로 읽히는 모든 수치는 학습 분포 내 수렴 지표임을 유의해야 한다.
“네 시나리오 모두 ≤100 generation batch 안에 0.95를 넘는다” — 신뢰도 중간. Figure 3 캡션에 명시되고 §6.2 본문과 일치하지만, 시나리오별 정확한 batch 수는 그림에서만 읽히고 표로 제시되지 않는다. 또 Confluence page-creation 곡선은 from-scratch가 아니라 warm-started stability trace(16 batch 동안 1.0 근처 평탄)라 다른 세 곡선과 성격이 다르며, 이 경우 “수렴 속도”로 해석하면 오독이 된다.

추가 확인 사항

논문에 코드 저장소 URL이 없다. §7 Reproducibility는 “Tables 1–2, Sections 3.3 and 5, and the Appendix A rollouts specify the substrate at the level needed to reimplement it”이라고만 쓴다. Appendix A는 rollout 출처를 atlassian_rollouts.json이라는 파일명으로 언급하지만 공개 위치는 [위치 미확인].
ticket-transition의 type bug는 gold transition id를 정수로 두고 string 스키마와 비교해 “schema-compliant 1.7B가 4B는 챙기는 보너스를 잃는다”고 서술된다. 즉 Figure 2의 ticket-transition 1.7B 값 0.87은 모델 능력이 아니라 checker 결함을 반영한 값이므로 다른 시나리오의 1.7B 값과 같은 층위에서 비교하면 안 된다.
single-product 3개 시나리오(sub-task, page creation, labeling)의 보상 분해표가 없다. Table 2는 cross-product만 다루고, single-product 보상은 “같은 R1/R2/R3 템플릿을 시나리오별 크기로 따른다”고만 서술된다. sub-task correctness 상한 0.50과 missing-create penalty −0.30은 §4 본문에서 확인되지만 나머지 항목은 [위치 미확인].
Figure 2·Figure 3의 수치는 PDF 그림에 인쇄된 막대 라벨과 §6.1 본문 서술을 교차 대조해 재구성했다. Figure 3의 시나리오별 최종값과 정확한 batch 수는 그림에서만 읽히므로 표 1에 옮기지 않았다.
venue 표기: arXiv 제출은 cs.AI 2026-07-01이고 본문이 “a workshop reader”를 언급하므로 KDD26 본회의가 아닌 workshop track으로 추정된다. 정확한 workshop 명칭은 [위치 미확인].

연구	환경 성격	보상 출처	학습 여부	핵심 차별점
본 논문 (RLVR on Atlassian)	합성 Jira/Confluence, schema-faithful, 결정적	tool-call trace의 hand-designed checker	GRPO 학습	좁은 enterprise API 표면에 특화, 파이썬 수백 줄 substrate + sub-second 보상
τ-bench - A Benchmark for Tool-Agent-User Interaction in Real-World Domains	합성 retail/airline 도메인 + 시뮬레이션 사용자	최종 DB state 비교 + 규칙 준수	평가 전용	다중 턴 사용자 상호작용과 정책 준수를 함께 재는 벤치마크, 학습 루프 없음
WebArena - A Realistic Web Environment for Building Autonomous Agents	실제로 렌더링되는 웹 사이트 복제	기능적 정답 판정	평가 전용	시각·DOM 표면의 open-web 과제, 본 논문과 정반대로 넓고 얕음
SWE-bench - Can Language Models Resolve Real-World GitHub Issues	실제 GitHub 저장소	테스트 통과 여부(verifiable)	평가 전용	검증 가능 보상이라는 점은 같으나 표면이 코드이고 실제 실행 비용이 큼
AgentBench - Evaluating LLMs as Agents	8개 이질적 환경 묶음	환경별 성공 판정	평가 전용	broad agentic suite. 본 논문이 “학습 효율을 위해 좁혔다”고 대비하는 대상
DeepSeek-R1 - Incentivizing Reasoning Capability in LLMs via Reinforcement Learning	수학·코드 문제	정답 일치 / 컴파일·테스트	GRPO 학습	RLVR + GRPO 레시피의 원류. 본 논문은 이를 API 인자 검사로 이식

원자적 인사이트 (Zettelkasten)

tool-use는 RLVR을 적용하기 가장 쉬운 표면 중 하나다. 출력이 자연어가 아니라 함수명(인자dict)이므로 정답 딕셔너리와 키 단위 대조가 가능하고, 부분 점수(per-argument 0.10)까지 자연스럽게 정의된다. 수학의 최종 답 일치나 코드의 테스트 통과가 이진 신호인 데 비해, tool call은 dense 보상을 공짜로 얻는다. 보상 희소성이 RL 학습의 주 병목인 도메인에서 참고할 구조적 이점이다.
모델 규모보다 post-training objective가 더 큰 레버일 수 있다. Confluence page creation에서 1.7B → 4B(2.4배 규모)가 사는 이득은 +0.10인 반면, 같은 4B에 RLVR을 적용해 얻는 이득은 +0.65다. “이 API를 못 다룬다”는 문제는 용량 부족이 아니라 pretrain 분포에 없는 인자 문법의 문제이며, 그렇다면 해법도 규모가 아니라 환경 내 학습이다.
평균 보상은 성공률의 변화를 체계적으로 과소 표현한다. cross-product의 0.92 → 1.00은 +0.08로 보이지만 실제로는 “12개 중 8개 완벽 → 12개 전부 완벽”, 즉 성공률 67% → 100%다. dense 보상을 쓰는 agent 평가에서는 평균 스칼라와 all-or-nothing 성공률을 항상 함께 보고해야 한다.
잘 설계되지 않은 보상은 baseline을 포화시켜 실험 자체를 무효화한다. ticket-transition은 tool call당 +0.25에 상한 1.0, 과잉 호출 무벌점이라는 설계 때문에 transition_issue를 9번 부른 rollout도 만점을 받았고 prompted 4B가 이미 1.00에 도달했다. RLVR 연구에서 “baseline이 이미 만점”은 모델이 잘한 증거가 아니라 보상 설계 결함의 증거로 먼저 의심해야 한다.
환경의 determinism은 학습 효율과 실전 전이를 맞바꾼다. 무작위성이 없어야 보상 귀속이 정확하고 regression fixture로 쓸 수 있지만, 그 결정성은 rate limit·eventual consistency·permission error 같은 실제 실패 모드를 전부 제거한다. 저자들이 제안한 record–replay + fault injection + sandbox canary는 이 교환을 인정하고 값싼 inner loop와 작은 live validation loop로 분리하는 설계다.

핵심 용어 정리

용어	정의
RLVR (Reinforcement Learning with Verifiable Rewards)	학습된 보상모델이나 사람 라벨 대신, 출력에 대해 프로그램적으로 정오를 판정할 수 있는 checker를 보상으로 쓰는 RL
GRPO (Group Relative Policy Optimization)	한 프롬프트에 대한 rollout 그룹 내부의 상대 우위로 advantage를 계산해 critic 없이 정책을 갱신하는 알고리즘. 본 논문은 TRL 구현 사용
schema fidelity (P1)	합성 환경의 tool signature와 응답 payload가 실제 API 계약(예: `fields.project.key`, `fields.issuetype.id`)을 그대로 따르는 성질
stateful but resettable (P2)	`create_`의 side effect가 후속 `get_`로 관측되지만, 매 보상 계산 전 `reset_synthetic_data()`로 pristine state가 복원되는 성질
determinism (P3)	동일한 tool-call 시퀀스가 항상 동일한 응답을 낳아 보상 귀속이 정확해지는 성질
verifiability (P4)	ground truth가 기대 인자 값의 작은 딕셔너리라, oracle LLM이나 live service 없이 보상을 계산할 수 있는 성질
R1 / R2 / R3	per-argument correctness(슬롯당 0.10–0.15) / validate–mutate–verify structural bonus(단계당 0.05–0.20) / penalty(누락·중복·환각·과잉 호출)
validate–mutate–verify	`get_`로 리소스 존재 확인 → `create_`로 변경 → `get_*`로 결과 확인이라는 enterprise 자동화 표준 패턴
degenerate reward	보상 형태가 포화적이어서 학습 없이도 만점이 나오는 상태. ticket-transition이 해당(호출당 +0.25, 상한 1.0, 과잉 벌점 없음)
silent failure	형식은 그럴듯하나 필드 값·중첩 구조·순서가 틀려 실제로는 실패인 tool call. 본 논문이 표적으로 삼는 실패 모드
warm-started stability trace	이미 수렴한 체크포인트에서 이어 돌려 안정성만 확인하는 학습 곡선. Confluence page-creation 곡선이 해당(16 batch, 1.0 근처 평탄)

BibTeX

@article{vissa2026beyond,
  title   = {Beyond Next-Token Prediction: An {RLVR} Proof of Concept for Tool-Use Agents on {A}tlassian Workflows},
  author  = {Vissa, Karthikeya Aditya and Mane, Sankalp and Mantravadi, Ananya and Rajgarhia, Harshit and Mukherji, Abhishek},
  journal = {arXiv preprint arXiv:2607.01465},
  year    = {2026},
  eprint  = {2607.01465},
  archivePrefix = {arXiv},
  primaryClass  = {cs.AI},
  url     = {https://arxiv.org/abs/2607.01465}
}

Next-Token Prediction을 넘어서: Atlassian 워크플로 tool-use 에이전트를 위한 RLVR 개념 증명 (RLVR PoC for Atlassian Tool-Use)

Next-Token Prediction을 넘어서: Atlassian 워크플로 tool-use 에이전트를 위한 RLVR 개념 증명 (RLVR PoC for Atlassian Tool-Use)

먼저 이해하기

섹션별 요약

Abstract

왜 이 연구를 하는가?

Introduction

Methods

발견 (Findings)

Results

Discussion

이론적 의의

실험 결과 상세

프레임워크 다이어그램

재현성 및 신뢰도 평가

관련 연구 비교 매트릭스

원자적 인사이트 (Zettelkasten)

핵심 용어 정리

관련 연구

태그

BibTeX