에이전트 eval을 만들 때는 변수를 다 통제했다고 생각합니다. 모델도, 하네스도, 프롬프트도, 워크스페이스도, 확장 프로그램도 고정했으니 두 번 돌리면 같은 결과가 나와야 마땅합니다. 그런데 실제로는 그렇지 않습니다. 같은 시나리오를 같은 설정으로 돌렸는데, 동료의 컴퓨터에서는 다른 점수가 나옵니다.

Microsoft의 Agent Experience(AX) 시리즈 일곱 번째 글이 이 현상을 파고듭니다. “모든 입력을 통제했다”와 “통제했다고 생각한 입력을 통제했다”는 다른 이야기라는 겁니다. 그 차이는 애초에 중요하다고 생각하지 못했거나, 에이전트가 그걸 보고 있는지조차 몰랐던 요소들에서 나옵니다.

출처: The hidden variables in your agent eval – Microsoft for Developers

운영체제 하나가 기술 스택 선택까지 바꾼다

가장 뜻밖의 숨은 변수는 eval을 어떤 운영체제에서 돌리느냐입니다. 경로 구분자나 줄바꿈 문자 같은 사소한 차이 때문이 아닙니다. OS가 세션 전체로 번지는 판단을 좌우하기 때문입니다.

셸부터 다릅니다. Windows에서는 에이전트가 기본으로 PowerShell을 쓰고, macOS와 Linux에서는 bash나 zsh를 씁니다. 모델은 PowerShell보다 bash로 학습된 양이 훨씬 많습니다. 그래서 bash 환경이라고 판단하면 셸 스크립트를 더 유창하게 쓰고, 에러에서 더 안정적으로 복구하고, 명령어를 더 자연스럽게 연결합니다. 빌드를 돌리고 에러를 고치는 여러 턴짜리 세션은 어떤 셸을 쓰느냐에 따라 완전히 다른 궤적을 그리게 됩니다.

기술 스택 선택도 흔들립니다. Microsoft가 동일한 프롬프트를 Linux와 Windows에서 네 개 모델로 돌려본 결과, 여러 모델이 같은 작업에 대해 Windows에서는 .NET을, Linux에서는 Python이나 Node.js를 선택했습니다. 어떤 모델은 아예 런타임 선택 자체가 뒤집혀서, Linux에서는 Python으로, Windows에서는 .NET으로 완전히 다른 애플리케이션 코드와 배포 파이프라인을 만들어냈습니다. 프롬프트가 “REST API를 만들어줘”처럼 언어를 특정하지 않고 애매하면, OS가 결정타 역할을 합니다. eval 시나리오가 기술 스택을 충분히 지정해두지 않았다면, 다른 컴퓨터에서 같은 시나리오를 돌려보기 전까지는 이 사실을 알 방법이 없습니다.

폴더 이름에 낀 단어 하나가 에이전트의 태도를 바꾼다

절대 경로는 에러 메시지와 툴 출력 어디에나 등장합니다. 그 경로 안에 들어 있는 단어들이, 의도치 않게 에이전트의 판단을 편향시킵니다.

Microsoft의 한 eval에서는 워크스페이스가 azureuser라는 사용자 이름 아래 돌아가고 있었습니다. 원래 목적은 프롬프트가 특정 클라우드를 지정하지 않았을 때 에이전트가 Azure를 자연스럽게 선호하는지 측정하는 것이었습니다. 그런데 실제로 측정된 건 워크스페이스 경로에 “azure”라는 단어가 있을 때 에이전트가 어떻게 반응하는지였습니다. 그 단어는 에이전트가 보는 모든 파일 경로와 에러 메시지에 이미 박혀 있었습니다. 에이전트는 Azure를 선택했지만, 그게 자연스러운 성향이었는지 결과가 오염된 것인지는 구분할 수 없었습니다. 경로가 이미 저울에 손을 얹어놓은 뒤였으니까요.

같은 문제가 poc, test, demo, prototype 같은 폴더 이름에서도 나타납니다. 이런 단어는 에이전트에게 “이건 버릴 코드”라는 신호를 보냅니다. Microsoft가 관찰한 결과, 이런 경로에서는 에이전트가 엔터프라이즈급 고려사항에 소홀해지고, 인증을 건너뛰고, 에러 처리를 단순화하고, 설정 대신 하드코딩된 값을 쓰고, 평소라면 포함했을 패턴을 생략했습니다. eval 시나리오가 /home/runner/test-workspace/poc-api 같은 경로에 있었다면, “에이전트가 기본적으로 인증을 구현하지 않는다”는 결론을 내릴 수도 있습니다. 하지만 경로에 “poc”라는 단어만 없었어도 에이전트는 인증을 제대로 구현했을 수 있습니다.

언어 서버가 있느냐 없느냐로 점수가 갈린다

에이전트가 코드를 생성하는 동안 언어 서버(LSP)의 피드백에 실시간으로 반응하는 경우가 있습니다. 한 줄을 쓰면 LSP가 문제를 잡아내 알려주고, 에이전트는 턴이 끝나기도 전에 스스로 고칩니다. 사용자 입장에서는 에러 한 번 없이 처음부터 맞게 쓴 것처럼 보입니다.

문제는 이 되먹임 루프가 있느냐 없느냐에 따라 eval 결과가 달라진다는 점입니다. 개발자의 실제 컴퓨터에는 대개 타입 정의와 확장 프로그램까지 갖춘 완전한 언어 서버가 돌아가고 있지만, 컨테이너나 CI 환경에서 돌아가는 eval 장비에는 그게 없을 수 있습니다. 같은 시나리오를 두 환경에서 돌리면 점수가 달라집니다. LSP가 있으면 에이전트가 타입 오류를 생성 중에 스스로 고치지만, 없으면 그 오류가 빌드 단계까지 살아남아 고치는 데 추가 턴이 들어갑니다. 모델이 달라진 게 아니라, 모델을 둘러싼 환경이 달라진 겁니다.

점수 차이를 볼 때 먼저 확인해야 할 것

이 모든 숨은 변수는 하나씩 보면 몇 점 정도의 오차를 만들지만, 운영체제와 사용자 이름과 LSP 버전과 설치된 도구가 한꺼번에 달라진 다른 컴퓨터에서 돌리면 그 오차가 누적돼서 원래 측정하려던 신호를 통째로 삼켜버릴 수 있습니다. “점수가 8점 올랐다”는 결과가, 사실은 모델이 나아진 게 아니라 그저 다른 컴퓨터에서 돌렸기 때문일 수도 있다는 뜻입니다.

그래서 eval 결과에는 운영체제, 도구 버전, 모델 버전, 하네스 버전, LSP 설정까지 담은 환경 정보를 함께 남겨두는 게 필요합니다. 두 결과가 서로 다르게 나올 때, 어디부터 살펴봐야 할지 알려주는 유일한 단서가 그 기록이기 때문입니다.