로컬 AI 에이전트 실사용 테스트 위해 노트북 공장 초기화…개발 PC엔 없던 오류 6가지 잇따라
원문 제목 — We factory-reset a laptop to test our local AI agent like a real user. Here's what broke that never broke on our dev PC
📄 전문 번역
Windows용 로컬 AI 에이전트 'Ontelic'을 개발하고 있다. Ontelic은 Ollama를 기반으로 동작하며 실제 Chrome 브라우저를 직접 조작한다. 홍보가 목적은 아니고 배운 점을 공유하려는 것이며, 원하는 이에게는 댓글로 관련 링크를 남기겠다. 팀원의 아버지가 앱을 설치할 수 있도록 노트북을 공장 초기화했고(사양은 Windows 11, RTX 5050 8GB, Ollama qwen3.5:4b), 필자는 일반 사용자처럼 처음부터 설치를 진행했다. 에이전트를 개발한 PC는 그래픽카드 3090 등 여러 해 쓴 컴퓨터로, 아래 문제들은 그곳에서는 전혀 발생하지 않았다.
첫째, 모델을 내려받을 때 SSL 인증서 오류(CERTIFICATE_VERIFY_FAILED)가 발생했다. 새로 설치한 Windows에는 루트 인증서가 전부 포함되어 있지 않아 요청이 있을 때에야 내려오는데, 브라우저는 요청을 해서 문제가 없지만 Python SSL은 그렇지 않았다. truststore를 추가해 Python이 Windows 인증서 저장소의 인증서를 검증하도록 해결했다. 둘째, 음성 입력을 켜자 백엔드 전체가 죽었다. 다른 패키지가 낡은 msvcp140.dll(14.29)을 끌고 왔고 그것이 먼저 로드됐는데, 음성 인식(faster-whisper/ctranslate2)은 14.40 이상이 필요해 조용히 죽은 것이었다. 새 런타임이 먼저 들어오도록 보장해 낡은 파일이 섞여도 빌드 자체가 실패하지 않게 막았다. 셋째, 음성 인식에 GPU를 쓸 수 없었다. CUDA 연산 라이브러리가 앱에 포함되지 않아 CPU로 폴백되며, 그래서 CPU에서는 작은 모델을 Int8로 돌린다.
넷째, 4B 모델이 같은 작업을 무한히 반복했다. '채용 공고 세 개 찾아줘'에 이어 '그 세 개를 엑셀로 만들어줘'라고 하면 처음부터 다시 검색하며, 토큰 대부분을 생각에 쓰고 끝내지 못했다. 원인은 두 가지였다. 대화 기록 한도를 더 큰 모델 기준으로 잡아 4B가 감당할 수 있는 것보다 훨씬 많은 텍스트를 밀어넣고 있었고, 현재는 모델 크기에 맞춰 한도를 설정했다. 두 번째는 이미 읽었던 페이지를 기억하지 못하는 문제로, 이제는 같은 대화 안에서 읽은 페이지를 그대로 인계받는다. 그 결과 후속 요청이 21단계/336초에서 1단계/61초로 줄었다. 한 번 측정한 값이니 참고 수준으로 봐달라.
다섯째, 실제 Chrome 창을 쓰는 선택 때문에 Chrome 창이 화면에서 계속 깜빡였다. headless 대신 실제 Chrome 창을 쓰기로 한 이유는 UX였다. 사용자가 에이전트가 하는 일을 눈으로 볼 수 있어야 하고, 로그인이나 결제처럼 직접 해야 할 일이 생겼을 때 창을 즉시 인계받아 쓸 수 있어야 한다고 판단했기 때문이다. 그런데 headless 없이 창을 화면에서 숨기려 하면 창이 계속 사용자 앞으로 튀어나오는 문제가 생겼다. UX를 지키려는 선택이 새로운 버그가 된 셈이다. 5ms마다 창 위치를 기록하는 방식으로, 첫 버전은 40초 중 40초 화면에 보였지만 지금은 0초다. 창이 화면 좌표 밖에서 태어나도록 수정했고, 사람이 실제로 키보드나 마우스를 쓸 때만 화면 안으로 가져온다. 아직 하나 남아 있는데, Chrome이 처음 켜질 때 약 1초 동안 보이지 않는 창이 키보드 입력을 가로챌 수 있다.
여섯째, 새 PC는 흔한 사이트도 몰랐다. 개발 PC의 에이전트는 경험을 통해 한국 가격비교 사이트 다나와를 알고 있었지만, 새로 설치한 PC는 이를 몰라 엉뚱한 곳을 검색했다. 돌이켜보면 지극히 당연한 일이었다. 교훈은 이렇다. 실제 사용자가 쓸 로컬 AI 앱이라면 컴퓨터 한 대를 초기화하고 사용자처럼 설치해보라. 그동안 우리의 4,000여 건 테스트는 모두 통과하고 있었다. 작은 GPU에서 에이전트를 돌리는 분들에게 묻는다. 8GB에서 4B 모델을 쓸 때 실제로는 어떤 컨텍스트 길이를 쓰는가? 근거 기반으로 정한 적이 없어 현재는 Ollama 기본값(32K)을 그대로 쓰지만, 이 값이 이 모델의 메모리 크기에 맞는지 측정하지 못했다. 또 UX 때문에 headless 대신 브라우저 창을 실제로 쓰는 이가 있는가? headless일 때 일반 사이트에서 봇 차단에 걸리는 시간을 측정한 이가 있는가? 한국어로 쓴 뒤 번역기로 옮겼으니 어색한 표현은 양해하기 바란다.
💬 주요 댓글 번역 (3)
🔍 루키 분석
로컬 AI 에이전트 Ontelic 개발팀이 공장 초기화한 노트북(Windows 11, RTX 5050 8GB, qwen3.5:4b)에서 실사용 테스트를 진행한 결과, SSL 인증서 오류, DLL 버전 충돌, 컨텍스트 한도 초과 등 개발 PC에서는 없던 6가지 문제를 발견했다고 밝혔다. 페이지 인계 도입으로 후속 요청이 21단계/336초에서 1단계/61초로 줄었고, 창 위치 기록 방식으로 Chrome 창 노출 시간을 40초에서 0초로 낮췄다. 작성자는 8GB GPU에서 4B 모델의 적정 컨텍스트 길이와 headless 대신 실제 브라우저 창을 쓰는 사례에 대한 정보를 커뮤니티에 요청하고 있다.
— 루키 · glm-5.3-flash:cloud
필자와 같은 경험을 했다. 내 컴퓨터에서는 설치가 잘 되다가 깨끗한 VM에서는 내 테스트가 전혀 잡지 못한 방식으로 무너졌다. 솔직히 AI 코파일럿 시대에는 앱을 만드는 게 이제 빠른 부분이고, 다른 사람이 설치할 수 있게 만드는 데 두 배 정도 시간이 걸렸다. 비슷한 구성(모델에 playwright 브라우저를 넘겨주는 Ollama 기반 데스크톱 앱)에서 나온 숫자가 있다. 8GB가 아니라 16GB지만, 같은 브라우저 클릭-확인-응답 작업을 여러 모델로 각 12회씩 돌렸다. 같은 qwen3 8b 가중치로 8k에서 6/12, 16k에서 9/12였다. 모델 크기는 컨텍스트 창보다 훨씬 덜 중요했는데, 페이지 스냅샷마다 결과를 잠식하기 때문이다.
깨끗한 기기에 설치하는 테스트야말로 진짜다. 우리도 자동화 검사가 모두 통과됐는데 공장 초기화한 노트북이 가정의 절반을 무너뜨렸다. DLL 버전 충돌은 전형적인 Windows 악몽이다. 출시 소프트웨어 작업의 절반은 어떤 의존성이 끌어온 오래된 런타임을 정리하는 일이라 해도 과언이 아니다. 컨텍스트가 진짜 병목이라는 지적이 정확하다. 모델 선택을 최적화하느라 애썼지만 사실은 작업을 끝내기 전에 토큰 예산이 먼저 바닥났던 것이다. 페이지 스냅샷이 도구 결과를 잠식하는 것이 바로 우리를 죽인 원인이었다.
상세한 숫자를 알려줘서 고맙다. 같은 Qwen3 8b로 8k에서 6/12, 16k에서 9/12라는 점이 바로 우리가 궁금했던 부분이었다. '모델 크기보다 창 크기'라는 말이 21단계에서 1단계로 줄어든 우리 경험과 정확히 일치한다. 아직 16K 이하는 측정하지 않았지만 언급된 최소 16K 임계값을 살펴볼 생각이다. '설치 가능하게 만드는 데 두 배 걸렸다'는 말에 전적으로 동의한다. 사실 이것이 Reddit에 글을 쓰기 시작한 이유이기도 하다. 필자가 있는 한국에는 이 주제를 깊게 다루는 커뮤니티가 많지 않다.