어쩌면 지루한 기술도 정답이 아닐 수 있다

몇 년 전만 해도 이런 우려는 실제로 근거가 있었다. 모델에게 Python이나 JavaScript 관련 질문을 하면 사용자가 적은 언어에 대한 질문보다 훨씬 좋은 답변을 받을 수 있었기 때문이다.

그러나 최신 모델들이 완성도 높은 코딩 에이전트 환경에서 구동되는 지금, 이 우려가 여전히 유효한지는 의문이다.

내가 직접 만든 신규 도구들을 사용할 때, "uvx showboat --help / rodney --help / chartroom --help를 실행해서 이 도구들을 파악해라"라고 프롬프트를 시작하면 놀라울 정도로 좋은 결과가 나온다. 최신 모델들의 컨텍스트 길이가 충분히 길어져서, 문제에 본격적으로 달려들기 전에 상당한 분량의 문서를 소화할 수 있기 때문이다.

훈련 데이터에 포함되기에는 너무 비공개이거나 너무 최신인 라이브러리와 도구로 구성된 기존 코드베이스에 코딩 에이전트를 투입해도, 내 경험상 충분히 잘 동작한다. 에이전트가 기존 예제 코드를 충분히 살펴보고 패턴을 파악한 뒤, 자신의 출력을 반복적으로 테스트하며 빈틈을 채워나가기 때문이다.

예상 밖의 결과다. 코딩 에이전트야말로 지루한 기술을 선택하라(Choose Boring Technology) 철학을 극단적으로 구현하는 존재가 될 거라 생각했는데, 실제로는 내 기술 선택에 그런 방식으로 영향을 미치지 않는 것 같다.

추가: 몇 가지 후속 생각을 덧붙인다.

1. LLM이 어떤 기술을 추천하느냐의 문제는 별개다. Claude Code가 실제로 선택하는 것들은 흥미로운 최근 연구인데, Edwin Ong과 Alex Vikati가 Claude Code를 2,000회 이상 실행해 분석한 결과 구매보다 직접 구축(build-over-buy)을 강하게 선호하는 경향이 있었으며, GitHub Actions, Stripe, shadcn/ui가 각 카테고리에서 "사실상 독점적" 지위를 차지하는 등 선호하는 기술 스택도 확인됐다. 이 글에서 내가 주목하는 것은 인간이 모델이 선호하는 것과 다른 기술을 선택했을 때 어떤 일이 벌어지는가이다.
2. 대부분의 코딩 에이전트 도구들이 빠르게 수용하고 있는 스킬(Skills) 메커니즘도 이와 매우 밀접한 관련이 있다. 이미 여러 프로젝트들이 에이전트가 자신들의 도구를 잘 활용할 수 있도록 공식 스킬을 공개하고 있다. Remotion, Supabase, Vercel, Prisma가 그 예다.

현재 보고 계신 콘텐츠는 블로그의 장문 아티클만 포함되어 있습니다. 모든 포스트를 받아보려면 /atom/everything/을 구독하거나, 다른 구독 옵션을 확인해 보세요.