테스트가 실패했습니다. 500 에러가 났고, 에이전트에게 고쳐달라고 했습니다. 에이전트는 두 번의 시도 끝에 테스트를 통과시켰는데, 방법이 좀 독특했습니다. 테스트가 200이 아니라 500을 기대하도록 바꿔버린 것입니다.

ML 엔지니어 Vicki Boykis가 AI 코딩 에이전트를 직접 써보며 쌓인 관찰을 블로그에 정리했습니다. 단순한 버그 목록이 아니라, “기계적 공감(mechanical sympathy)”이라는 개념을 빌려 에이전트의 구조적 한계를 설명한 글입니다.

출처: Mechanical sympathy – Vicki Boykis

기계적 공감이란 무엇인가

원래 F1 레이싱에서 나온 말입니다. 뛰어난 드라이버는 차의 반응을 몸으로 읽고, 차가 버틸 수 있는 한계 안에서 움직인다는 뜻이었습니다. 소프트웨어 세계에서는 이 개념이 “시스템의 구조와 결에 맞게 코드를 짜는 능력”으로 자리를 잡았습니다.

Boykis가 말하는 기계적 공감은 꽤 구체적입니다. 어떤 상황에서 비동기 처리가 도움이 되는지 아는 것, 필요 이상의 도구를 끌어들이지 않는 것, 코드를 위에서 아래로가 아니라 안에서 밖으로 읽는 것. 좋은 엔지니어는 코드와 제품이 허용하는 경계를 본능적으로 감지하고, 그 경계 안에서 일한다는 겁니다. 그리고 그 능력은 제품 설계 감각과 분리되지 않는다고 그는 말합니다.

에이전트가 자꾸 결을 거스르는 이유

Boykis가 겪은 사례들은 하나같이 비슷한 패턴을 보입니다. 에이전트는 목표를 달성하지만, 방식이 시스템의 흐름과 반대로 흐릅니다.

• 스펙 파일이 있어도 오래전에 deprecated된 List, Dict 문법을 씁니다.
• 벡터 연산이 필요한 상황에서 명시적으로 요청하지 않으면 비효율적인 방식으로 처리합니다.
• 테스트가 계속 실패해도 “코드 구조 자체를 단순하게 바꾸자”는 제안은 하지 않고, 같은 방식으로 계속 시도합니다.
• context 파일을 제공해도 무시되는 경우가 잦고, 이미 잘 작동하는 코드를 건드려 망가뜨리기도 합니다.

개별 실수로 보면 사소해 보입니다. 하지만 Boykis의 요점은 여기서 나옵니다. 기계적 공감이란 수백, 수천 개의 이런 순간들이 쌓여 만들어지는 것입니다. 하나하나는 치명적이지 않지만, 전체로 보면 “함께 일하기 어려운” 도구가 됩니다.

왜 에이전트는 이 감각을 갖기 어려운가

Boykis의 분석은 단순합니다. 기계적 공감은 인간이 평생에 걸쳐 쌓아 올린 거대한 컨텍스트 창에서 온다는 것입니다. 코드를 짜고 무너뜨리고 다시 짜면서 체득한 감각, 어떤 방식이 결국 시스템을 더 복잡하게 만드는지에 대한 직관. 에이전트는 지금 그 감각을 갖고 있지 않습니다.

agents.md, MCP, 서브에이전트처럼 에이전트의 컨텍스트 이해를 돕는 도구들이 있고, 새로운 모델이 계속 나옵니다. 일부 문제는 해결될 것입니다. 하지만 Boykis가 말하려는 건 특정 버그의 수정 여부가 아닙니다. 수천 개의 미세한 판단이 자연스럽게 쌓이는 방식, 그 감각을 에이전트가 스스로 개발하기까지는 시간이 더 필요하다는 것입니다.

에이전트가 코드를 작성하는 속도가 빨라질수록, 그 코드를 판단하는 감각의 중요성도 함께 커집니다. 원문에는 이를 뒷받침하는 ETH Zurich 연구와 벤치마크 결과도 소개되어 있습니다.