데스크탑에서 보상 함수를 고친 뒤 노트북으로 돌아오면, 파일은 최신이어도 다음에 무엇을 검증해야 하는지는 최신이 아니었습니다. H1 보행의 reward v2가 어디서 바뀌었는지, G1 USD 변환이 아직 남아 있는지, RL 설정의 정본이 어느 파일인지 다시 찾는 일이 코드 수정보다 길어졌습니다. 이 문제는 Git이 해결해 주지 않습니다. Git은 무엇이 바뀌었는지는 보여 주지만, 작업을 멈출 때 어떤 의심이 남았는지까지 대신 적어 주지는 않습니다.
그래서 저는 이 워크스페이스에서 장비를 바꾸는 순간을 별도의 실험 단계로 봅니다. 데스크탑은 Isaac Sim과 Isaac Lab을 돌리고, 노트북은 코드·설계·노트를 다루는 역할이 다릅니다. 두 환경이 같은 저장소를 본다는 이유만으로 같은 작업 맥락을 공유한다고 가정하지 않기로 했습니다.
pull 뒤에 제일 먼저 읽는 파일
다른 장비에서 작업을 시작할 때는 저는 git pull 뒤에 ENVIRONMENTS.md 맨 위의 핸드오프 로그를 먼저 읽습니다. 여기에는 수행·다음·주의·커밋 네 항목만 남깁니다. 길게 회고하는 문서가 아니라, 다음 작업을 시작하기 전에 필요한 최소한의 상태입니다.
예를 들어 2026년 6월의 기록에는 노트북에서 FLAM 분석과 이론 지도 정리를 마쳤고, 데스크탑에서는 reward v2로 H1 재학습을 이어야 한다고 남아 있습니다. 같은 블록에는 RL 보상 설정의 정본이 sim/envs/<task>/<task>_env_cfg.py와 agents/*.yaml이며, 폐지된 training/configs/rl/ 파일을 고치면 코드가 읽지 않는다는 주의도 적혀 있습니다. 이 한 줄이 없으면 다음 작업자는 단순한 경로 정리 문제를 학습 실패로 오해할 수 있습니다.
네 줄을 남기는 방식
작업을 마칠 때는 새 블록을 로그의 맨 위에 추가합니다.
### YYYY-MM-DD · [노트북|데스크탑]
- 수행: 이번 세션에서 실제로 끝난 일
- 다음: 다른 환경에서 이어갈 한 가지 작업
- 주의: 미완 항목·충돌·환경 의존성
- 커밋: 대표 SHA 또는 범위이 형식에서 중요한 것은 ‘수행’보다 ‘다음’입니다. 완료한 일을 길게 써도 다음 판단이 없으면 다른 환경에서 다시 전체 저장소를 읽어야 합니다. 반대로 아직 끝나지 않은 작업을 분명하게 남기면, 중단은 실패가 아니라 다음 세션의 입력이 됩니다.
로그는 append-only로 유지합니다. 기존 블록을 고치면 당시의 판단과 현재의 판단이 섞이기 때문입니다. 머지 충돌이 생기면 한쪽을 고르는 대신 양쪽 블록을 보존하고 날짜 순서로 정렬합니다. 이 규칙은 문서를 예쁘게 유지하려는 것이 아니라, 데스크탑과 노트북에서 서로 다른 사실을 지우지 않기 위한 것입니다.
인수인계가 확인하는 경계
이 규칙으로 모든 문제가 해결되지는 않습니다. 체크포인트·데이터·Isaac Sim 캐시처럼 Git에 들어가지 않는 산출물은 여전히 각 환경에서 따로 확인해야 합니다. 그래서 핸드오프에는 “어디까지 확인했는가”와 “어느 환경에서만 가능한가”를 함께 적습니다. 당시 G1 USD 변환처럼 데스크탑의 Isaac Lab이 필요했던 작업을 노트북 할 일과 섞지 않는 이유도 여기에 있습니다.
실제로 가장 위험했던 것은 ‘정본이 아닌 설정’을 고치는 일이었습니다
H1 reward v2를 이어서 작업할 때 제가 특히 조심해야 했던 것은 비슷한 이름의 설정 파일이었습니다. 예전에 사용하던 training/configs/rl/ 경로가 남아 있어도 현재 Isaac Lab 태스크가 읽는 보상 정본은 sim/envs/<task>/<task>_env_cfg.py이고, PPO 설정은 agents/*.yaml입니다. 핸드오프의 주의 항목에 이 차이를 적지 않으면, 다음 환경에서 값을 바꾸고도 실행 결과가 달라지지 않는 일이 생길 수 있습니다. 그때는 보상 가설이 틀린 것이 아니라 실행 코드가 수정한 파일을 읽지 않은 것입니다.
이런 종류의 실패는 Git diff만 봐서는 늦게 발견됩니다. 변경 자체는 정확히 기록되기 때문입니다. 그래서 ‘주의’에는 단순한 미완 목록보다 실행이 실제로 읽는 파일, 환경에서만 재현되는 제약, 덮어쓰면 안 되는 산출물 경로를 우선 적습니다. M160a의 다음 runtime capture에서도 같은 원칙을 적용해 기존 결과와 분리된 no-clobber 경로가 계약에 들어가야 합니다.
체크포인트와 데이터는 존재 여부까지 인수인계합니다
Git에 들어가지 않는 파일은 커밋 SHA만으로 복구할 수 없습니다. 체크포인트를 다음 환경에서 쓸 계획이라면 모델 이름뿐 아니라 생성한 환경·iteration·평가 상태·실제 저장 위치를 남겨야 합니다. 데이터도 ID, 수집 조건, 변환 여부와 함께 기록해야 합니다. 파일을 복사하지 않았으면 그 사실도 적습니다. 그래야 ‘코드는 같은데 결과가 없다’는 상황을 새 학습 실패로 오해하지 않습니다.
결국 핸드오프 블록은 네 줄이지만, 그 네 줄이 가리키는 것은 다음 실행의 입력 계약입니다. 수행 항목은 관찰된 사실만, 다음 항목은 한 가지 행동만, 주의 항목은 잘못된 해석 가능성을, 커밋 항목은 재현 가능한 코드 상태를 붙잡습니다. 이 기준을 만족하지 못하면 길이가 짧아도 좋은 인수인계가 아닙니다.
다음에 환경을 옮길 때 제가 가장 먼저 확인할 것은 새 파일의 유무가 아니라, 로그의 ‘다음’ 항목이 현재의 Workspace 상태와 아직 맞는지입니다. 이 확인이 끝나야 다음 실험도 이전 실험의 연장선에서 시작할 수 있습니다.