프로그래밍 에이전트를 활용해 언어·도구·생태계의 품질과 개발 경험을 객관적으로 측정할 수 있다는 제안. 테스트 커버리지, 오류 보고, 생태계 안정성, 과도한 추상화의 축소, 성능과 사용자 친화성, 그리고 제대로 된 개발 환경이 인간과 에이전트 모두에게 중요하다는 지표를 제시한다.
이번 주 나는 친구들과 함께 에이전트를 마음껏 풀어놓고 24시간 안에 무엇을 만들 수 있는지(https://vibetunnel.sh/) 지켜봤다. 그 경험을 돌아보며 스스로를 위한 메모도 조금 남겼다. 또 하나의 vibecoding 글로 지루하게 하지는 않겠다. 대신 어떻게 됐는지는 Peter의 글(https://steipete.me/posts/2025/vibetunnel-turn-any-browser-into-your-mac-terminal)을 읽어볼 수 있다.
재미있었지만, 다른 면에서는 답답했고 그 방식도 충분히 예측 가능했다. 이 프로젝트에서 Xcode로 작업하는 걸 내가 얼마나 싫어했는지가 밈이 될 정도였다. 이 일로, 오랫동안 완전히 용납하기 어려운 경험이었음을 다시 생각하게 됐고, 프로그래밍 에이전트가 있으면 그 고통이 측정 가능해진다는 점을 깨달았다.
프로그래밍에 처음 빠져들었을 때 RTFM이라는 태도가 꽤 우스웠다. “왜 멍청한 질문을 하냐, 그냥 매뉴얼을 읽어라.” 불행하게도 현실은 매뉴얼이 아예 없거나 — 혹은 틀려 있다는 것이다. 사실 엔지니어인 우리는 서로에게 터무니없이 부실한 도구, 엉망이거나 없는 문서, 말도 안 되는 API 함정들을 거리낌 없이 강요하곤 한다. 예전에는 이를 “사용자 실수”라고 불렀고, 요즘엔 “실력 문제(skill issue)”라고 한다. 이는 사용자에게 책임을 돌리고, 적어도 잠시나마 만든 이를 면책한다. API에서는 함수를 잘못 쓰면 무작위로 크래시가 날 수 있고, 프로그램에서는 UI가 도저히 탐색 불가능하거나 오류 메시지가 부족할 수 있다. 인간이 막히는 방식은 정말 다양하다.
에이전트가 바꾸는 점은, 다른 개발자에게는 차마 요구하지 못할 것을 에이전트에게는 요구할 수 있다는 것이다. 바로 “측정”이다. 나는 현재 프로젝트의 언어를 고를 때 기본적인 평가를 돌려보고 결정했는데, 꽤 잘 맞았다. 그 과정에서 내 문제에 관해 객관적으로 더 낫거나 못한 언어가 있음을 알게 됐다. 선택은 AI가 학습 중에 그 언어의 예제를 얼마나 많이 본가뿐 아니라, 도구 체인, 언어의 고유 능력, 생태계의 변동성 같은 요소에도 달려 있다.
코드 품질을 측정하는 데 에이전트를 쓰는 건 좋다. 에이전트는 나를 평가하지 않지만, 자신이 쓰는 코드는 평가하기 때문이다. 모든 에이전트가 욕을 하진 않겠지만, 루프가 잘 안 풀리거나 포기할 때는 라이브러리에 대한 좌절감을 드러낸다. 이는 에이전트 성능이 아니라 프로젝트의 건강 상태를 계량화할 기회를 연다.
우리는 엔지니어링 팀이 얼마나 건강한지에 더 주의를 기울여야 하고, 그 출발점은 코드베이스다. 에이전트를 사용하면 인간에게는 어려운(혹은 매우 느리고 비싼) 방식으로 숫자를 붙일 수 있다. 우리가 만드는 것들을 에이전트가 얼마나 성공적으로 사용하는지, 비교적 객관적으로 파악할 수 있고, 이는 여러 면에서 인간이 그 코드와 함께 일할 때의 체감 경험을 대리 지표로 보여준다. 초보자들을 모아 튜토리얼이나 과제를 함께 진행하는 것은 힘들고 비용이 많이 든다. 반면, 코드베이스를 처음 보는 에이전트에게 라이브러리를 쓰게 하는 실험은 반복 가능하고, 비교적 저렴하고, 빠르며, 제대로 세팅하면 매우 객관적이다. 또한 감정을 배제할 수 있고, 실험을 여러 번 돌리기도 쉽다.
물론 에이전트와 함께 작성한 코드가 객관적으로 아름다운가, 혹은 에이전트의 툴 실행 방식이 올바른 유형의 도구를 만들어내는가에 대해서는 논쟁의 여지가 있다. 그 논쟁은 충분히 가치가 있다. 다만 지금 이 순간 프로그래밍 에이전트가 성공하는 데 필요한 것들은 인간에게 필요한 것들과 상당히 잘 맞물려 있다.
그래서 무엇이 더 잘 작동할까? 당장은 에이전트와 인간에게 공통으로 적용되는 기본 지표들이 있다:
좋은 테스트 커버리지: 미래의 코드 작성에 도움을 줄 뿐 아니라 회귀를 크게 방지한다. 새삼스러울 건 없을 것이다. 여기에 한 가지 더하자면, 이는 테스트만의 문제가 아니라 동작을 수동으로 검증할 수 있는 예제와 작은 도구들도 포함한다. 사용자와 에이전트가 직접 실행해 확인할 수 있어야 한다.
좋은 오류 보고: 좋은 오류 보고를 제공하지 않는 컴파일러, 도구, API는 나쁜 도구다. Sentry에서 일할 때도 줄곧 강조해 왔지만, 에이전트와 함께하면 이 투자가 얼마나 큰 효과를 내는지 더 분명해진다. 또한 오류는 발견될 수 있는 곳에 있어야 한다. 애매한 로그 깊숙이 숨어 있으면 인간도 에이전트도 찾지 못한다.
높은 생태계 안정성: 생태계가 자주 뒤바뀌고 API가 계속 변하면, 인간만 화나게 하는 게 아니라 에이전트도 느려진다. 에이전트는 구식 문서, 예제, 패턴을 발견해 헷갈리고, 속도가 떨어지며, 나쁜 코드를 쓸 것이다.
불필요한 추상화 최소화: 레이어가 많을수록 데이터 흐름과 리팩터링 비용이 커진다. 오늘날 (대부분의) ORM이 가져다주는 가치 자체를 의심해볼 시점일지도 모른다. 일들을 더 어렵게 만들 때가 많기 때문이다.
모든 것은 빠르고 사용자 친화적이어야 한다: 도구의 응답이 빠를수록(쓸모없는 출력이 적을수록) 좋다. 크래시는 참을 만하지만, ‘멈춤’은 문제가 된다. 예를 들어 Python에서 uv는 생태계의 그 어떤 것보다 훨씬 좋은 경험을 제공한다. 대부분의 생태계가 pip를 가리키고 있음에도 말이다. 에이전트는 uv에서 유용한 정보를 잘 받고 실패율이 낮기 때문에, 매우 기꺼이 — 그리고 계속 — uv를 쓴다.
좋은 개발 환경: 문제가 CI에서만 재현된다면 에이전트를 CI로 옮겨야 한다. 좋은 경험이 아니다. 에이전트가 로컬에서 Docker를 실행할 방법을 제공하라. 백엔드를 작성한다면 접근하고 내관(introspect)할 수 있는 데이터베이스를 마련하라. (형편없이) 그대로 목(mock)으로 때우지 마라. CI 흐름으로 미루는 건 답이 아니다. 또한 개발 환경이 깨진 것인지, 코드가 깨진 것인지가 분명해야 한다. 도구 체인이 제대로 갖춰지지 않으면 인간도 에이전트도 이를 구분하기 어렵다.
에이전트가 고생한다면, 인간도 그렇다. 객관적으로 좋지 않은 코드와 도구가 이유야 어떻든 지배적이 되어버린 경우가 많다. 기술 선택에 더 신경 쓰고 싶거나, 자신만의 라이브러리를 만들고 싶다면, 이제 에이전트를 사용해 개발자 경험을 평가할 수 있다.
사용자들도 똑같이 할 수 있기 때문이다. Xcode를 내가 싫어하는 건 나만이 아니라는 걸 자신 있게 말할 수 있다. 내 에이전트도 좌절을 드러낸다 — 게다가 계량 가능한 방식으로.
