GoalEnv에서 목표를 다른 값으로 바꿔 학습 경험을 만들 때는 새 목표와 보상, 종료 신호가 같은 조건을 가리켜야 합니다. 보상만 다시 계산하고 기존 목표나 종료 플래그를 남겨 두면, 하나의 전이 안에 서로 다른 과제의 정보가 섞일 수 있습니다. 그렇다고 목표를 바꿀 때마다 모든 종료 플래그가 반드시 달라지는 것은 아닙니다.
Hindsight Experience Replay, 줄여서 HER은 실제로 도달한 결과 등을 다른 목표로 삼아 경험을 다시 활용하는 방법입니다. 여기서는 어떤 HER 알고리즘이 더 좋은지보다, Gymnasium Robotics의 GoalEnv를 이용해 목표를 치환할 때 지켜야 할 데이터 관계를 살펴봅니다. 모방학습과 보상 기반 학습의 기본 구분은 로봇 모방학습과 강화학습 차이에서 먼저 확인할 수 있습니다.
같은 이동도 목표가 달라지면 다른 학습 신호가 된다
로봇이 위치 A를 목표로 움직였지만 위치 B에 도달한 가상 전이를 생각해 보겠습니다. 원래 과제에서는 A와의 관계로 보상을 계산합니다. 이 경험을 ‘B에 도달하는 과제’의 학습 자료로 바꾸면 실제 이동은 그대로지만, 평가할 목표가 B로 달라집니다.
이때 입력 관측에는 여전히 A가 목표로 들어 있는데 보상만 B 기준으로 바꾸면 문제가 생깁니다. 학습기는 A를 요청받은 행동에 B 기준의 점수가 붙은 데이터를 받게 됩니다. 목표를 조건으로 쓰는 현재·다음 관측을 포함해, 그 학습 구현이 목표를 읽는 위치에 동일한 대체 목표를 반영해야 합니다.
반면 achieved_goal을 임의로 원하는 값에 맞춰 바꾸는 것은 목표 치환과 다릅니다. 그것은 그 전이에서 실제로 도달한 결과를 표현합니다. 이 예시에서는 도달 결과 B를 보존하고, 무엇을 달성하도록 요청한 경험으로 해석할지를 바꾸는 것입니다.
GoalEnv는 세 재계산 함수를 따로 제공한다
Gymnasium Robotics의 Multi-goal API는 관측에 observation, desired_goal, achieved_goal을 요구합니다. 또한 달성한 목표, 원하는 목표, info를 받아 보상과 두 종료 신호를 계산하는 함수를 각각 제공합니다. 문서의 예시도 대체 목표에 대해 세 함수를 따로 호출합니다.
아래는 그 관계만 보여주는 의사코드입니다. goal_env는 해당 목표 환경의 API를 가리키며, 래퍼를 포함한 전체 저장 로직이나 실행 검증을 마친 HER 구현은 아닙니다.
reward_new = goal_env.compute_reward(achieved, goal_new, info)
terminated_new = goal_env.compute_terminated(achieved, goal_new, info)
truncated_new = goal_env.compute_truncated(achieved, goal_new, info)
세 함수를 부르는 이유는 세 결과가 모두 바뀌어야 해서가 아닙니다. 각각이 새 목표에서도 같은 의미로 유효한지 확인하기 위해서입니다. 환경에 따라 목표 달성이 곧 에피소드 종료일 수도 있고 그렇지 않을 수도 있습니다. 보상을 성공에 가까운 값으로 바꿨다는 이유만으로 terminated=True를 만들어서는 안 됩니다.
info도 빈 사전으로 임의 교체하면 안 됩니다. 공식 API는 목표와 무관한 추가 상태를 보상이나 종료 판정에 활용할 수 있도록 이 인자를 둡니다. 선택한 환경이 무엇을 요구하는지에 따라 필요한 정보를 보존해야 합니다. 다만 이전 목표에 대한 성공 판정을 캐시한 필드가 있다면, 새 목표와 맞지 않는 값을 그대로 쓰지 않는지도 별도로 살펴야 합니다.
시간 제한은 목표 치환으로 사라지지 않는다
여기서는 기반 환경과 바깥 래퍼를 구분해야 합니다. Gymnasium의 TimeLimit 문서에 따르면 이 래퍼는 최대 스텝 수에 도달하면 truncated를 발생시킵니다. 기반 환경의 종료와는 다른 원인입니다.
예를 들어 해당 실행이 시간 제한에 도달한 시점의 전이를 재사용한다고 합시다. 목표를 B로 바꿨다는 이유만으로 이미 소모한 스텝이 줄어들지는 않습니다. 기반 GoalEnv의 compute_truncated 결과가 거짓이어도, 바깥 TimeLimit에서 발생한 중단 사실까지 사라진 것은 아닐 수 있습니다.
따라서 재라벨링할 때는 기반 환경에서 재계산하는 값과 래퍼가 부여한 종료 정보를 나눠 확인해야 합니다. 사용한 래퍼의 규칙에 맞게 최종 신호를 구성하고, 학습 코드가 시간 제한 중단을 어떻게 처리하는지도 맞춰야 합니다. 모든 래퍼에 통하는 결합식을 가정하거나 기반 환경의 함수 호출 하나로 전체 환경의 중단 원인을 복원했다고 보아서는 안 됩니다.
이 구분을 놓치면 반대 방향의 오류도 생깁니다. 새 목표에서는 기반 환경의 종료 조건이 달라졌는데 기존 플래그를 무조건 유지하면, 새 과제와 맞지 않는 전이가 됩니다. 필요한 것은 ‘항상 유지’나 ‘항상 변경’ 규칙이 아니라 종료 원인별 처리입니다.
한 전이를 대조해 볼 때
목표 치환 처리를 검토한다면 먼저 원래 목표를 그대로 넣어 보상과 기반 환경의 신호를 재계산하는 사례를 마련하는 편이 좋습니다. 그 결과가 환경의 규칙과 맞는지 확인한 뒤, 대체 목표를 넣었을 때 바뀌어야 하는 부분과 그대로여야 하는 부분을 비교합니다. 실제 step 결과와 대조할 때는 앞서 설명한 래퍼의 영향도 함께 고려해야 합니다.
그다음에는 학습에 전달되는 한 샘플을 읽어 보세요. 현재·다음 관측의 목표, 달성 결과, 재계산한 보상, 기반 환경의 종료 정보와 외부 중단 정보가 같은 해석을 가리켜야 합니다. 성공처럼 보이는 새 보상 하나만 확인하면 나머지 불일치를 놓칠 수 있습니다.
이 글의 A·B 위치 예시는 개념 설명이며 로봇 실험 결과가 아닙니다. 2026년 10월 15일 확인한 공식 API와 래퍼 문서를 근거로 작성했으며, 특정 GoalEnv나 HER 라이브러리를 직접 실행해 호환성을 검증한 것은 아닙니다.