최신 LLM을 쓰면 개인 PC에서도 로봇 연구를 자동으로 진행할 수 있을까요? 저도 Claude Opus 계열과 Codex의 GPT-5.6 계열 모델을 사용하며 이 질문을 반복해서 확인했습니다. 결론부터 말하면 LLM은 논문·코드·실험 기록을 연결하는 데 강했지만, GPU에서 실행된 결과를 대신 만들어 주거나 실패한 보행을 성공으로 바꾸지는 못했습니다. 그래서 “가장 좋은 모델 하나”를 고르기보다, 사람·LLM·시뮬레이터가 각각 무엇을 책임질지 나누는 구조를 택했습니다.
이 글의 모델 이름과 기능은 2026년 7월을 기준으로 합니다. OpenAI 문서상 gpt-5.6 별칭은 주력 모델인 GPT-5.6 Sol로 연결되며, Claude Code에서는 opus 같은 최신 계열 별칭을 선택할 수 있습니다. 모델 이름과 가격은 빠르게 바뀌므로 특정 버전을 영구 추천하기보다 역할과 검증 기준을 중심으로 설명합니다. 새로 시작할 때는 각 회사의 공식 모델·제품 문서를 다시 확인해야 합니다.
Physical AI에서 LLM이 맡는 위치
Physical AI는 화면 안에서 답을 만드는 데서 끝나지 않고, 현실이나 시뮬레이션의 상태를 관측해 행동으로 이어지는 인공지능을 뜻합니다. 로봇 프로젝트에서는 논문 이해, 환경 구성, 데이터 준비, 정책 학습, 평가와 실행이 서로 연결돼야 합니다. LLM은 이 전체를 설명하고 코드를 수정할 수 있지만, 실제 물리 계산과 정책 최적화는 Isaac Sim·Isaac Lab·GPU가 수행합니다. 저는 이 차이를 흐리지 않기 위해 LLM을 “연구 보조 계층”으로 두었습니다.
논문·공식 문서
↓ 요약·비교·근거 추적
LLM 연구 보조
↓ 설계안·코드·검증 명령
로컬 워크스페이스
↓
Isaac Sim / Isaac Lab / GPU
↓ 실제 관측값·체크포인트·평가
LLM 검토 + 사람의 판단
↺ 다음 실험
LLM에게 맡기는 세 가지 역할
역할 1 — 흩어진 근거를 찾고 연결합니다. Physical AI는 로봇 모델, 물리 시뮬레이션, 강화학습, 제어와 논문이 서로 다른 폴더와 문서에 흩어지기 쉽습니다. 사람 혼자 모든 변경 이력을 매번 다시 읽는 데는 시간이 많이 듭니다. 저는 LLM에게 먼저 관련 파일과 공식 문서를 찾고, 어떤 주장에 어떤 근거가 연결되는지 표로 만들게 했습니다. 다만 검색 결과를 사실로 바로 채택하지 않고 원문과 실제 코드 위치를 확인하는 단계를 남겼습니다.
역할 2 — 구현안을 작게 나누고 코드를 수정합니다. 큰 목표를 “휴머노이드가 걷게 한다”라고만 주면 수정 범위와 성공 기준이 모호해집니다. 그래서 관측, 보상, 종료 조건, 학습 실행, 평가와 로그를 별도 계층으로 나누고 LLM에는 한 번에 하나의 검증 가능한 변경을 맡겼습니다. Claude Code와 Codex는 저장소 전체를 읽고 여러 파일의 연결을 추적하는 데 유용했지만, 생성한 코드가 Isaac Lab 버전과 맞는지는 실제 실행으로 확인해야 했습니다. 문법상 그럴듯한 코드와 동작하는 로봇 정책은 같은 결과가 아니었습니다.
역할 3 — 실행 결과를 읽고 다음 질문을 만듭니다. 학습 곡선이 올라가면 문제가 해결됐다고 착각하기 쉽습니다. 실제로는 보상이 높아져도 로봇이 한쪽 다리만 쓰거나, 짧은 구간만 버티거나, 평가 기준의 빈틈을 이용할 수 있습니다. 저는 LLM에게 체크포인트와 평가 파일의 신원을 맞추고, 낙상률·이동거리·양측 지지·관절 움직임처럼 서로 다른 지표가 같은 결론을 가리키는지 검토하게 했습니다. 결과가 기대와 다르면 더 오래 학습시키기보다 환경과 평가 계약을 먼저 다시 보게 했습니다.
가장 강한 모델을 오래 쓰면 보행이 생길까요
제 프로젝트에서는 최상위급 코딩 모델을 여러 주 동안 사용해도 원하는 보행 성과가 자동으로 나오지 않았습니다. 처음에는 더 많은 반복이 해결책처럼 보였지만, 실패가 이어지자 학습 루프의 구조와 성공 기준을 다시 감사했습니다. 보상 숫자만 개선하는 반복, 정확한 체크포인트를 묶지 않은 평가, 단측 움직임을 보행으로 오인할 수 있는 기준이 남아 있으면 LLM도 잘못된 목표를 성실하게 최적화할 뿐이었습니다. 모델의 추론 능력보다 실험 계약의 정확성이 먼저라는 점을 배웠습니다.
그래서 자동화 루프를 계획 검토, 학습과 배선 검증, 체크포인트에 묶인 평가와 결정 기록의 세 역할로 줄였습니다. 한 번의 계획은 하나의 가설과 자원 예산, 예상 지표 변화에 연결하고, 학습 결과는 실제 생성된 체크포인트 해시와 함께 평가합니다. 실패한 결과는 이름만 바꿔 다시 돌리지 못하도록 같은 실패 서명에 반복 예산을 묶었습니다. 이 구조는 LLM을 덜 쓰는 것이 아니라, LLM이 틀릴 수 있는 위치를 관찰 가능하게 만드는 방법이었습니다.
[계획 권한]
가설·부모 체크포인트·예산·통과 기준
↓ 승인된 한 건
[학습 + 배선 검증]
실제 업데이트·gradient·새 체크포인트 확인
↓ 동일 체크포인트
[평가 + 결정 기록]
주 지표 → 필요할 때만 상세 trace → 채택/기각
↺ 다음 가설
※ 실패한 평가를 통과로 바꾸기 위해 기준을 낮추지 않습니다.
개인 PC의 가장 현실적인 제약은 VRAM입니다. Isaac Lab이 수천 개 환경을 병렬로 학습하는 동안 로컬 LLM까지 같은 GPU에 올리면 메모리 부족으로 둘 다 불안정해질 수 있습니다. 저는 Claude와 Codex 같은 클라우드 기반 코딩 에이전트와, Ollama처럼 제 GPU에서 직접 추론하는 로컬 LLM을 구분했습니다. 16GB GPU 환경에서는 강화학습 중 로컬 대형 모델을 동시에 실행하지 않고, 분석과 학습 시간을 분리하는 편이 재현성이 좋았습니다.
처음 시작할 때 맡길 수 있는 작업과 권장 순서
- 문서 탐색: 설치 버전과 공식 예제를 찾아 출처와 함께 비교합니다.
- 구조 설명: 관측·행동·보상·평가가 어느 파일에서 연결되는지 지도를 만듭니다.
- 작은 구현: 한 변경과 한 검증 명령으로 범위를 제한해 코드를 수정합니다.
- 결과 검토: 로그와 체크포인트가 같은 실행에서 나왔는지 확인하고 실패 가설을 만듭니다.
- 기록 유지: 결정 이유, 실행 조건, 결과와 다음 행동을 Markdown과 Git에 남깁니다.
반대로 실제 로봇의 안전 판단, 비용이 큰 학습 실행 승인, 성공 기준 변경, 공개할 연구 정보의 범위는 사람에게 남겼습니다. LLM이 자신 있게 설명해도 시뮬레이터 실행과 평가 데이터가 없으면 구현 성공의 증거가 아닙니다. 최신 모델은 이 경계를 없애 주지 않지만, 경계를 문서화하고 반복해서 검사하는 비용을 크게 줄여 줍니다. 이것이 개인 PC 프로젝트에서 제가 얻은 가장 실용적인 이점이었습니다.
먼저 Git과 Markdown으로 로컬 워크스페이스를 만들고, Isaac Sim과 Isaac Lab의 최소 예제를 따로 통과시킵니다. 그다음 LLM에게 전체 프로젝트를 한 번에 만들게 하지 말고, 파일 지도 작성과 읽기 전용 감사부터 맡깁니다. 작은 코드 변경은 실행 결과와 함께 커밋하고, 실패 이유가 설명되지 않으면 다음 학습을 자동으로 이어 가지 않습니다. 이 순서를 지키면 모델이 바뀌어도 프로젝트의 근거와 검증 과정은 남습니다.
오늘의 결론은 최신 LLM이 개인 PC의 한계를 없애는 도구가 아니라, 제한된 자원 안에서 연구의 연결과 검증을 유지하는 보조자라는 점입니다. Claude Opus 계열과 GPT-5.6 Sol 같은 모델은 복잡한 저장소를 읽는 데 도움이 되지만, 좋은 결과는 명확한 실험 계약과 실제 실행 증거에서 나옵니다. 다음 글에서는 이 역할 분담을 사용해 Isaac Lab의 첫 환경을 읽고, 관측과 행동이 실제로 어떻게 흐르는지 따라가 보려 합니다.