🤖
0 in / 0 out / 0 total tokens
AI 평가는 이제 “모델이 똑똑한가”보다 “현장에서 버티는가”를 묻는 방향으로 가고 있다.
🔥 핫 토픽
RoboDojo: 범용 로봇 조작 정책을 위한 Sim-and-Real 벤치마크
RoboDojo는 범용 로봇 조작 정책을 더 종합적으로 평가하기 위한 벤치마크다. 기존 로봇 벤치마크가 짧은 작업, 단순한 환경, 특정 스킬 위주로 제한되는 경우가 많았다는 문제의식에서 출발한다. 특히 sim과 real을 함께 다룬다는 점이 중요하다. 시뮬레이션에서만 잘하는 정책은 게임 AI로 치면 테스트 맵에서는 완벽한데 라이브 서버에서 프레임 드랍과 네트워크 지연을 만나자마자 무너지는 봇과 비슷하다.
개발자 관점에서는 이 논문이 “평가 환경도 제품의 일부”라는 말을 다시 떠올리게 한다. UE5에서 물리 기반 상호작용을 만들 때도 에디터 안에서는 멀쩡한데 실제 빌드, 다른 FPS, 다른 입력 장치에서 엉키는 일이 많다. 로봇 정책도 마찬가지로 짧고 예쁜 데모보다 긴 작업 흐름, 실패 복구, 환경 차이에 대한 내성이 더 중요해진다.
이게 왜 중요한지: 로봇 AI가 데모 장난감에서 실제 자동화 시스템으로 넘어가려면, 모델 성능보다 먼저 평가 기준이 더 빡세져야 한다.
📰 뉴스
Teaching LLMs a Low-Resource Language: Pharo 코드 완성 강화
이 논문은 LLM이 Pharo 같은 저자원 프로그래밍 언어에서 코드 완성을 더 잘하게 만드는 문제를 다룬다. 요즘 코드 완성 도구는 대부분 LLM을 기반으로 하지만, Python, JavaScript, C++처럼 데이터가 많은 언어에 비해 마이너 언어는 지원 품질이 떨어지기 쉽다. 결국 “AI 코딩 도구가 모든 개발자를 돕는다”는 말은 데이터가 충분한 생태계에서만 절반쯤 맞는 말이다.
게임 개발자로 보면 꽤 현실적인 문제다. UE C++도 표준 C++과 다르게 매크로, 리플렉션, UObject 생명주기, GC 규칙, 빌드 시스템 같은 문맥이 강하다. LLM이 문법은 맞히는데 엔진 관례를 틀리면 실전에서는 도움이 아니라 디버깅 비용이 된다. Pharo처럼 데이터가 적은 언어를 개선하는 연구는 결국 “특정 도메인의 코드 감각을 모델에 어떻게 먹일 것인가”라는 질문으로 이어진다.
이게 왜 중요한지: AI 코드 완성의 다음 병목은 더 큰 모델이 아니라, 작은 언어와 특수한 코드베이스의 맥락을 얼마나 잘 학습시키느냐다.
📄 논문 관점 메모
두 논문은 분야가 다르지만 같은 문제를 보고 있다. 하나는 로봇 조작에서 평가 기준의 빈틈을 찌르고, 다른 하나는 코드 완성에서 데이터 편향의 빈틈을 찌른다. AI가 범용 도구처럼 보이기 시작할수록 실제로는 벤치마크, 데이터셋, 도메인 적응 같은 지저분한 엔지니어링 문제가 더 크게 튀어나온다.
나도 사이드프로젝트에서 LLM 기능을 붙일 때 제일 많이 삽질하는 지점이 여기다. 프롬프트 몇 줄로는 데모가 나오지만, 사용자가 이상한 입력을 넣고, 컨텍스트가 길어지고, 비용 제한이 생기면 바로 시스템 설계 문제가 된다. 서버 아키텍처에서 캐시, 큐, 타임아웃, 장애 복구를 챙기듯이 AI 기능도 평가와 운영 설계를 같이 봐야 한다.
AI의 실전 성능은 모델 카드보다 평가 환경과 도메인 데이터에서 먼저 갈린다.