Mega Lecture: Reinforcement Learning, Agents & OpenEnv

강의의 출발점. SFT 와 DPO/APO 가 이미 거의 saturate 된 시점에서, 다음 step 의 능력 (수학 · 코드 · 도구 사용 · 멀티턴 추론)은 환경 안에서 직접 학습해서 얻는다. 단순 preference 가 아니라 실제로 풀린 문제 / 실제로 실행된 코드 의 reward 가 신호가 된다. 그 environment 를 표준화하는 것이 OpenEnv 의 미션.

이 mega lecture 의 의도는 한 자리에 여러 진영 을 모은다는 점이다. Meta 의 OpenEnv 코어, HuggingFace 의 TRL (GRPO 학습 루프), Unsloth 의 sample efficiency 트릭, 그리고 그 위에서 도는 agent 프레임 — 한 사람이 만들어 한 사람이 쓰는 게 아니라, layer 가 잘 분리된 stack 이 어떻게 조립되는지가 전체 그림.

OpenEnv 의 디자인을 이해하려면 그 위에 깔린 역사를 짧게 본다. reset/step 이라는 두 함수의 인터페이스는 거의 그대로다 — 그러나 “step 한 번에 무엇이 통신되는가” 는 시대마다 바뀌었다.

• OpenAI Gym (2016) — env.reset(), env.step(action). observation 은 numpy array, action 은 discrete 또는 continuous. RL 의 lingua franca.
• Gymnasium (2022, 포크) — Gym 의 유지보수가 멈추자 Farama Foundation 으로 이전. terminated / truncated 분리, type stub 추가. 현대 RL 의 표준.
• LLM agent 시대 (2023–24) — observation 이 더 이상 array 가 아니라 구조화된 dict (도구 호출 결과 · 멀티턴 메시지). action 도 자연어 + 구조화 호출. Gym 인터페이스가 그대로는 안 맞는다.
• OpenEnv (2025) — Action, Observation, StepResult 를 강타입 dataclass 로. WebSocket / async 가 1차 시민. Docker/K8s 격리 표준화.

그리고 강의에서 강조되는 점 — “Gymnasium-style”이라는 표현. OpenEnv 는 새 패러다임이 아니다. 같은 정신의 새 구현체. 이 결정은 학습 곡선을 낮춘다 — 기존 RL 코드를 OpenEnv 로 옮기는 게 며칠 단위.

OpenEnv repo 의 README 가 강조하는 단순함. 새 environment 를 짠다는 건 — Action, Observation 두 개의 dataclass 를 정의하고, server 안에서 reset(), step(action), state() 셋을 구현하는 일이 전부.

# server 측 — Environment 정의
from dataclasses import dataclass
from openenv import Environment, StepResult

@dataclass
class EchoAction:
    text: str

@dataclass
class EchoObservation:
    last_text: str
    turn: int

class EchoEnv(Environment):
    def reset(self):
        self.turn = 0
        return EchoObservation("", 0)

    def step(self, action: EchoAction):
        self.turn += 1
        obs = EchoObservation(action.text, self.turn)
        reward = 1.0 if action.text else 0.0
        done = self.turn >= 5
        return StepResult(obs, reward, done)

# client 측 — async 가 1차 시민
from openenv import EnvClient

async def rollout():
    async with EnvClient(
        base_url="ws://localhost:9000"
    ) as client:

        obs = await client.reset()

        for _ in range(5):
            action = policy(obs)         # 정책
            result = await client.step(action)
            obs, r, done = (
                result.observation,
                result.reward,
                result.done,
            )
            if done: break

이 짧은 코드 안에 OpenEnv 의 디자인 결정 4가지가 다 보인다.

1. typed dataclass — observation 의 schema 가 코드에서 검증됨. tool 의 결과가 dict 로 넘어가다가 누락되는 사고를 줄임.
2. async 가 default — 한 episode 가 쇼핑몰 API · 코드 실행 · 검색 같은 외부 호출을 포함. blocking 이면 GPU 가 비어 있음. async-first 가 throughput 에 결정적.
3. WebSocket — REST 의 round-trip 비용을 피한다. 멀티턴이 길어지면 길수록 차이가 커진다.
4. StepResult 가 dataclass — observation/reward/done/info 를 한 객체로. Gym 의 5-tuple 의 후예지만 검증 가능한 형태.

강의의 가장 시각적인 부분. environment 가 표준화돼도 — 그 위에서 어떤 action 을 만들지의 정책 코드는 별도. 자주 쓰이는 4가지 패턴.

그리고 강의에서 자주 짚는 점 — “같은 environment 위에서 다른 agent 패턴을 갈아 끼울 수 있어야 한다”. agent 와 env 가 분리돼야 ablation 이 가능. ReAct 와 Direct 가 같은 env 의 같은 reward 위에서 비교 가능해야 “정책 코드가 진짜 도움이 되는가” 의 답이 나온다.

supervised 학습이 “모든 GPU 가 같은 일” 이라면, RL 은 본질적으로 disaggregated 하다. 한 학습 step 의 안을 들여다보면 세 역할이 동시에 돈다.

강의에서 강조되는 disaggregation 결정.

• rollout 전용 GPU — 학습 가능 model 과는 별도 GPU 위에서 vLLM 으로 빠른 inference. PagedAttention · continuous batching 의 이점을 그대로.
• learner GPU — backward 가 도는 자리. FSDP 또는 DeepSpeed ZeRO. memory 가 가장 많이 필요.
• reference model — frozen. learner 와 같은 노드에서 weight share, 또는 별도 GPU.
• weight sync — 매 학습 step 후 새 weight 를 sampler 로. NVLink/IB 위 collective 또는 RDMA 직접 transfer.

그리고 production-scale RL 에 진입할 때 만나는 디테일 — weight sync 의 비용. 70B 모델의 weight 를 매 step transfer 하는 건 비싸다. 보통 N step 마다 sync 하거나, LoRA delta 만 sync 하는 식으로 줄인다. RL 의 throughput 병목은 매번 다른 자리에 옮겨 다닌다 — 처음엔 rollout, 다음엔 weight sync, 그 다음엔 reward model 의 latency.

강의에서 가장 강조되는 점 중 하나 — RL 알고리즘의 차이보다 reward signal 의 품질이 결과를 더 크게 바꾼다. 2025년 trend 는 reward 가 점점 verifiable 해지는 방향.

강의에서 짚는 reward 디자인의 함정 — length hacking. reward 가 출력 길이와 양의 상관이 있으면, 모델이 길게만 쓰는 쪽으로 발산. 해결책: length-normalized reward, 또는 kl 페널티 강화.

기존 LLM 평가는 “정답이 있는 정적 dataset” 위에서. agentic 시대의 평가는 “환경 안에서 실제로 작동하는가”. 이 둘은 다른 인프라가 아니어야 한다 — environment 라는 같은 추상 위에서.

• 같은 env, 다른 모드 — 학습 시는 reward 를 학습 신호로, 평가 시는 reward 를 metric 으로. 코드 한 줄 바꾸지 않음.
• seed isolation — eval 시 사용하는 seed/instance 를 학습 데이터에서 제외. environment 가 instance 단위 split 을 native 지원.
• 환경 버전 고정 — 같은 환경의 새 버전이 reward 를 미세하게 바꾸면 모든 비교가 깨진다. Hub 위 environment 는 SHA 기반 immutable 버전.
• cross-env transfer — 한 env 에서 학습한 모델을 다른 env 에서 평가. 진짜 능력의 transfer 가 일어나는가의 질문.

OpenEnv repo 의 README 가 자랑스럽게 보여주는 부분 — 이미 여러 RL framework 가 OpenEnv 인터페이스를 지원한다.

강의에서 던지는 질문 — “왜 이렇게 많은 framework 가 같은 contract 를 채택하는가”. 답은 OpenEnv 자체가 가벼운 인터페이스라는 점. 새 framework 가 OpenEnv 를 추가로 지원하는 비용이 며칠 단위. 그러면서 얻는 이득은 — HF Hub 위 모든 environment 에 즉시 접근.

강의의 마지막 섹션은 미래에 대한 질문. RL training 이 실제 production 에서 흔해지면 — environment 의 품질, 보안, 거버넌스가 1차 문제가 된다.

• environment 의 reproducibility: 같은 env 의 같은 instance 가 1년 후에도 같은 reward 를 줘야. 외부 API 가 있는 env 는 이 보장이 어려움.
• cost of an env: agent 가 코드를 실행하는 env 는 GPU/CPU 비용이 든다. “env 를 누가 비용을 내는가” 가 새 질문. HF Spaces 의 paid tier 가 자연스러운 후보.
• security: agent 가 임의 코드를 실행하는 env 는 sandboxing 이 핵심. Docker 격리는 1차 방어선.
• open vs closed: 회사 내부의 production env (실제 고객 데이터 위) vs 공개 env (Hub 위). 같은 contract 위에서 둘 다 가능해야.
• environment 의 진화: env 자체가 학습되는 단계 — 더 어려운 task 를 자동 생성, curriculum 자동화.

실습 시퀀스

1. EchoEnv 구현 — OpenEnv repo 의 cookbook 에서 EchoEnv 를 따라 짠다. openenv init 로 scaffolding 생성, server 띄우고 client 로 연결.
2. 2048 env 학습 — Unsloth Colab notebook 으로 GPT-OSS-20B 를 2048 env 위에서 GRPO 학습. 처음 RL 을 굴리는 가장 짧은 길.
3. BlackJack + torchforge — torchforge 의 BlackJack 예제 실행. agent loop 안의 ReAct 패턴이 어떻게 코딩되는지 직접.
4. verifiable math env — TRL + math env 로 GRPO. reward 를 정답일치(1/0) 로 두고 학습. length hacking 이 어떻게 일어나는지 관찰.
5. weight sync 비용 측정 — N step 마다 weight sync 의 시간을 wandb 로 로깅. 어느 step 부터 sync 가 dominant 가 되는지 그래프.

• 스피커 명단 확인 필요 — mega lecture 형식이라 여러 스피커가 등장했을 가능성. transcript 가 복원되면 명단 갱신.
• OpenEnv 의 정확한 추상 — repo 의 현재 README 기준으로 본 노트를 작성. 강의 시점의 API 와 약간 다를 가능성.
• weight sync 의 구체 패턴 — 강의에서 어떤 방식(NCCL collective vs RDMA vs file sync)을 강조했는지 영상에서 직접 확인.
• reward design 의 디테일 — verifiable vs PRM 의 trade-off 가 강의에서 어떻게 정리됐는지 미확인.
• cost analysis — RL 학습이 SFT 대비 몇 배 비싼지의 구체적 비교 — 강의에서 숫자가 등장했을 수 있음.
• OpenEnv 의 미래 — multi-agent: 한 env 안에서 여러 agent 가 상호작용하는 setting. 강의 시점에 다뤘는지 확인.