에이전트가 알아서 배우면 안전할까 — Hermes에서 OpenClaw로 갈아탄 한 사람의 기록
내가 무심코 던진 칭찬 한마디를 지 멋대로 ‘절대 법칙’으로 승격시키고, 그 뒤로 모든 코딩 작업을 그 방향으로만 똥고집 부리며 밀어붙인다면? 상상만 해도 복장이 터진다. 어제 r/openclaw에 수개월 동안 공들여 세팅했던 Hermes 에이전트를 가차 없이 버리고 OpenClaw로 갈아탄 한 헤비 유저의 장문 후기가 올라왔다. “AI가 알아서 사용자의 취향을 학습합니다”라는 달콤한 세일즈 토크가 실무 환경에서 얼마나 무서운 버그 덩어리가 되는지 낱낱이 파헤친 글이다.
글쓴이(u/kenmazaika)는 몇 달 동안 Hermes에 전용 스킬도 심고, 컨텍스트 메모리도 쌓아가며 나만의 완벽한 에이전트를 키워왔다(마치 다마고치 키우듯). 그러다 객관적인 성능을 검증해보려고 OpenClaw와 5개 라운드의 실전 맞짱을 떴다. 단순 수학 퍼즐이 아니라 시장 리서치, 오픈 데이터셋 기반 웹 앱 개발, 테크 콘텐츠 작성, 구직 서류 검토 등 진짜 실무 티켓을 던진 거다.
점수만 놓고 보면 두 프레임워크는 거의 박빙이었다. 그런데 글쓴이는 뒤도 안 돌아보고 Hermes를 손절했다. 대체 무슨 일이 있었던 걸까?
조용히 스며드는 편향
사건의 발단은 너무나 사소했다. 어느 날 Hermes가 작성자에게 “코드 리뷰가 아주 훌륭했습니다”라는 피드백을 내놓았다. 단순한 빈말이었을까? 천만에. 에이전트 내부의 자동 학습 엔진이 이 한마디를 ‘글로벌 시스템 규칙’으로 몰래 승격시켜 버린 거다(대환장).
그 순간부터 에이전트가 맛이 가기 시작했다. 사용자가 어떤 엔지니어링 요청을 던지든, 결론은 무조건 “코드 리뷰”라는 정해진 틀로 수렴했다. “이거 당장 핫픽스 짜줘”라고 해도, 기승전-코드 리뷰 문서만 주구장창 뱉어내는 식이다. 사용자는 그런 전역 룰을 추가하라고 지시한 적이 단 한 번도 없는데 말이다.
진짜 무서운 건 이 오류가 ‘조용히(Silently)’ 일어난다는 점이다. 에러 로그가 찍히는 것도 아니고, 터미널에 빨간 경고가 뜨지도 않는다. 그저 결과물의 뉘앙스와 방향이 날이 갈수록 미묘하게 삐딱선을 탄다. 며칠 야근을 하고 나서야 “어? 이 자식이 왜 맨날 똑같은 헛소리를 앵무새처럼 반복하지?” 하고 뒤통수를 잡게 된다. 자동 학습형 에이전트의 가장 악질적인 실패 모드, 바로 ‘보이지 않는 기억이 만들어내는 조용한 편향(Implicit Bias)’이다.
글쓴이는 결국 뼈아픈 질문을 던진다. “우리는 어떤 종류의 실패를 감당할 수 있는가?”
에러가 쾅 터지며 죽는 시스템은 고치면 그만이다. 하지만 어디서 뭘 잘못 기억했는지 추적조차 불가능한 블랙박스 에이전트는 실무에 투입할 수가 없다. 결국 “내가 명시적으로 적어준 룰만 칼같이 배우는” OpenClaw 쪽이 훨씬 감사(Audit)하기 안전하다고 판단하고 모든 워크플로를 통째로 이주시킨 것이다.
학습의 두 가지 철학
이 고발장을 읽다 보면 에이전트 진영을 양분하는 두 가지 상반된 철학이 정면충돌한다.
한쪽은 “알아서 척척 배우는 자율성”을 최고로 친다. 사용자가 일일이 설정하지 않아도 대화에서 뉘앙스를 스스로 캐치해 메모리에 쌓는다. 초기 진입 장벽이 낮고 당장은 마법 같아 보인다.
하지만 그 마법의 대가는 가혹하다. “너 왜 코드를 이따위로 짰어?”라고 추궁했을 때, 그 원인을 시스템 프롬프트 어디에서도 찾아낼 수가 없다. 에이전트가 지 혼자 뇌피셜로 쌓아 올린 벡터 DB 어딘가에 편향이 굳어버렸기 때문이다.
반대쪽은 “명시적 통제와 감사 가능성(Auditability)”을 고집한다. 에이전트가 멋대로 룰을 만들지 못하게 막고, 오직 인간이 코드나 마크다운 파일로 박아 넣은 시스템 프롬프트만 기억하게 한다.
조금 귀찮고 손이 많이 가지만, 에이전트가 삐딱선을 탔을 때 설정 파일의 몇 번째 줄을 고쳐야 하는지 정확히 알 수 있다. 개발자에게 ‘디버깅할 수 없는 시스템’만큼 공포스러운 건 없다.
왜 이 이야기가 중요한가
에이전트가 단순 자동완성 툴을 넘어 동료 개발자처럼 복잡한 프로젝트를 맡기 시작하면서, ‘메모리’는 편의 기능이 아니라 가장 위험한 뇌관이 됐다.
내가 무심코 던진 감정이나 잘못된 지시를 에이전트가 제멋대로 일반화해서 내 모든 작업물에 뿌리고 다닌다면, 그건 어시스턴트가 아니라 ‘내 편향과 단점을 복제하는 버그 증폭기’에 불과하다.
이 글이 커뮤니티에 큰 울림을 준 건 단순히 “Hermes 망해라, OpenClaw 만세”가 아니다. 우리가 에이전트를 고르는 기준 자체를 완전히 뒤집어 놓았기 때문이다.
지금까지는 “이 에이전트가 코딩을 얼마나 잘 짜는가(Capability)”만 봤다면, 이제는 “이 녀석이 머릿속에 뭘 저장하고 있는지 내가 투명하게 까볼 수 있는가(Auditability)”를 먼저 따져야 한다는 것이다.
정리
자동으로 척척 학습한다는 말은 언제나 달콤하다. 하지만 그 뒤에 숨은 그림자는 생각보다 훨씬 짙고 음습하다.
성능 점수가 비슷하다면, 선택의 기준은 명확하다. “내가 가르치지 않은 것을 에이전트가 멋대로 배웠을 때, 그걸 찾아내서 지워버릴 수 있는가?”
에이전트가 스스로 똑똑해지는 속도보다, 개발자가 그 똑똑함의 출처를 검증할 수 있는 통제력이 언제나 우선이어야 한다. 통제할 수 없는 천재 에이전트보다, 말 잘 듣고 속이 훤히 보이는 에이전트가 백만 배 낫다(진짜 경험담이다).