X발 좀 천천히 하자고: 코딩 에이전트 시대에 대한 생각

게시일: 2026년 3월 31일 | 원문 작성일: 2026년 3월 25일 | 저자: Mario Zechner | 원문 보기

• • •

프로젝트를 통째로 빌드할 수 있는 코딩 에이전트가 등장한 지 대략 1년 됐어요. Aider나 초기 Cursor3 같은 선구자들이 있었지만, 그건 에이전트라기보다 어시스턴트에 가까웠죠. 새 세대는 확실히 매력적이에요. 우리 중 많은 사람들이 항상 만들고 싶었지만 시간이 없었던 프로젝트들을 쏟아내느라 여가 시간을 다 갈아넣었거든요.

그리고 저는 그게 괜찮다고 봐요. 여가 시간에 뭔가를 만드는 건 정말 즐거운 일이고, 대부분의 경우 코드 품질이나 유지보수성 따위 신경 쓸 필요도 없잖아요. 새로운 기술 스택을 배우고 싶을 때도 좋은 방법이고요.

크리스마스 연휴 기간에 Anthropic과 OpenAI 양쪽에서 중독성 있는 슬롯머신에 사람들을 끌어들이려고 무료 크레딧을 뿌렸어요. 많은 사람들이 에이전트 코딩의 마법을 처음 경험한 순간이었죠. 빠져드는 사람이 점점 늘어나고 있어요.

코딩 에이전트는 이제 프로덕션 코드베이스에도 투입되고 있어요. 12개월이 지난 지금, “진보”의 결과가 서서히 드러나기 시작했죠. 지금 제가 보고 있는 풍경을 이야기해볼게요.

• • •

다 망가지고 있다

전부 들은 얘기이긴 한데, 소프트웨어가 점점 부실해지고 있다는 건 확실히 체감돼요. 대형 서비스를 포함해서 98% 가용률이 예외가 아니라 일상이 되고 있거든요. 그리고 사용자 인터페이스에는 QA 팀이라면 당연히 잡았어야 할 정말 기괴한 버그들이 버젓이 살아있어요. 이런 현상 자체는 에이전트 이전부터 있었다는 건 인정하지만, 가속이 붙고 있는 건 분명해요.

회사 내부 사정을 알 수는 없죠. 그런데 가끔 뭔가가 기자한테 흘러나오잖아요. 이를테면 이 AI로 인한 AWS 장애 보도요. AWS는 즉각 “정정”을 발표했지만, 내부적으로는 90일간 코드 관리 리셋을 진행했죠.

Microsoft CEO 사티야 나델라는 Microsoft 코드의 상당 부분이 이제 AI로 작성된다고 공공연히 이야기해왔어요. 직접적인 증거는 없지만, Windows가 나락으로 가고 있다는 느낌은 확실히 있잖아요. Microsoft 스스로도 동의하는 것 같아요, 이 훌륭한 블로그 포스트를 보면요.

자기네 제품 코드가 100% AI로 작성됐다고 주장하는 회사들은 일관되게 상상 가능한 최악의 쓰레기를 내놓고 있어요. 누구를 콕 찍진 않겠지만, 기가바이트 단위 메모리 누수, UI 깨짐, 제대로 작동하지 않는 기능, 크래시. 이건 그 사람들이 생각하는 것과 달리 품질 인증이 아니에요. 그리고 에이전트한테 일을 다 맡기는 열병 같은 꿈의 좋은 광고도 확실히 아니죠.

업계 안쪽에서는 크고 작은 소프트웨어 회사 사람들한테서 에이전트로 코딩하다가 막다른 골목에 몰렸다는 얘기가 점점 더 많이 들려오고 있어요. 코드 리뷰 안 하고, 설계 결정은 에이전트한테 위임하고, 아무도 요청하지 않은 기능이 억만 개 생겨나고. 그러면 그렇게 되는 거예요.

• • •

에이전트와 이렇게 일하면 안 되는 이유

우리는 기본적으로 모든 규율과 주체성을 내려놓고, 최대한 짧은 시간에 최대한 많은 코드를 뽑아내는 게 최고 목표인 일종의 중독에 빠진 거예요. 결과가 어떻든 상관없이요.

자율 에이전트 대군을 지휘하려고 오케스트레이션 레이어를 구축하고 있잖아요. Beads4를 깔았는데, 사실상 삭제 불가능한 멀웨어라는 걸 전혀 모르면서요. 인터넷이 그러래서요. 이렇게 해야 된다고, 아니면 낙오한다고. 루프에 구역질을 하고 있죠. 보세요, Anthropic이 에이전트 떼로 C 컴파일러를 만들었어요. 좀 망가져 있긴 한데, 다음 세대 LLM이 분명 고쳐줄 거예요. 세상에, Cursor가 에이전트 대대를 동원해서 브라우저를 만들었어요. 네, 물론 제대로 작동하는 건 아니고 가끔 인간이 옆에서 손잡이를 돌려줘야 했지만요. 다음 세대 LLM이 분명 고쳐줄 거예요. 새끼손가락 걸고 약속! 분산하고, 분할하고 정복하고, 자율성, 무인 공장, 소프트웨어는 6개월이면 해결되는 문제. SaaS는 죽었고, 우리 할머니가 방금 Claw로 자기만의 Shopify를 만들었다고요!

다시 말하지만, 이런 방식이 본인 포함해서 거의 아무도 안 쓰는 사이드 프로젝트에서는 통할 수 있어요. 그리고 어쩌면 어딘가에 이 방식을 제대로 적용해서 폐기물 더미가 아닌, 실제 사용자가 진지하게 쓰는 소프트웨어 제품을 만들어내는 사람이 있을 수도 있죠.

그런 분이시라면, 진심으로 응원해요. 다만 적어도 제 주변 동료들 사이에서는 이런 식이 실제로 통한다는 증거를 아직 못 찾았어요. 어쩌면 우리 모두 실력 문제인 걸 수도 있지만요.

배움 없이 뻘짓만 쌓이고, 병목도 없고, 고통은 한참 뒤에 온다

에이전트의 문제는 에러를 낸다는 거예요. 뭐 그 자체는 괜찮아요, 인간도 에러를 내니까요. 단순 정확성 에러일 수도 있죠. 식별하고 고치기 쉬운 종류요. 보너스로 회귀 테스트까지 추가하면 금상첨화고요. 아니면 린터가 못 잡는 코드 스멜5일 수도 있어요. 여기 쓸데없는 메서드 하나, 저기 말이 안 되는 타입 하나, 중복된 코드. 이런 것들은 개별적으로 보면 무해해요. 인간도 이런 뻘짓은 하거든요.

하지만 기계는 인간이 아니에요.6 인간은 같은 실수를 몇 번 하다 보면 결국 안 하게 돼요. 누군가한테 혼이 나서든, 진짜 배움의 과정에 있어서든요.

에이전트한테는 그런 학습 능력이 없어요. 적어도 기본 상태에서는요. 같은 에러를 계속 반복할 거예요. 훈련 데이터에 따라서는 서로 다른 에러들의 화려한 새 조합을 만들어내기도 하죠.

에이전트를 가르치려고 시도할 수는 있어요. AGENTS.md7에 그 뻘짓 다시 하지 말라고 써놓는 거죠. 가장 복잡한 메모리 시스템을 고안해서 이전 에러와 모범 사례를 참조하게 만들 수도 있어요. 특정 카테고리의 에러에 대해서는 효과가 있을 수 있죠. 하지만 그러려면 여러분이 실제로 에이전트가 그 에러를 저지르는 걸 관찰해야 해요.

기계와 인간 사이에 훨씬 더 중요한 차이가 있어요. 인간은 병목이에요. 인간은 몇 시간 만에 2만 줄의 코드를 쏟아낼 수가 없거든요. 인간이 높은 빈도로 뻘짓을 저지르더라도, 하루에 코드베이스에 도입할 수 있는 뻘짓의 양에는 한계가 있어요. 뻘짓은 아주 천천히 쌓이죠. 보통 뻘짓으로 인한 고통이 너무 커지면, 고통을 싫어하는 인간이 시간을 들여서 뻘짓을 정리해요. 아니면 그 인간이 짤리고 다른 사람이 정리하거나요. 어쨌든 고통은 해소돼요.

에이전트 대군을 오케스트레이션하면 병목이 사라지고, 인간의 고통도 사라져요. 하나하나는 작고 무해했던 뻘짓들이, 병목이 사라지니 갑자기 감당 불가능한 속도로 쌓이기 시작해요. 여러분은 루프에서 빠져나온 상태니까, 그 순진한 뻘짓들이 합쳐서 괴물 같은 코드베이스를 만들고 있다는 것조차 몰라요. 고통을 느낄 때는 이미 너무 늦은 거예요.

그러다 어느 날 새 기능을 추가하려고 돌아보는데, 아키텍처가 이 시점에서 대부분 뻘짓 덩어리가 돼 있으니, 에이전트 대군을 풀어봐야 제대로 작동하는 코드가 나올 리 없어요. 아니면 최신 릴리스에서 뭔가가 깨져서 사용자 데이터를 삭제했다고 사용자들이 난리를 치죠.

코드베이스를 더 이상 신뢰할 수 없다는 걸 깨달아요. 더 나쁜 건, 기계한테 시켜서 만들었던 수많은 유닛 테스트, 스냅샷 테스트, e2e 테스트도 똑같이 신뢰할 수 없다는 걸 깨닫는 거예요. “이게 작동하나”의 유일하게 신뢰할 수 있는 척도는 제품을 직접 수동으로 테스트하는 것뿐이에요. 축하해요, 자기 자신을(그리고 회사를) 조진 거예요.

복잡성 장사꾼들

여러분은 무슨 일이 벌어지고 있는지 하나도 모르는 상태예요. 모든 주체성을 에이전트한테 위임했으니까요. 자유롭게 풀어놓았는데, 에이전트들은 복잡성 장사꾼이에요. 훈련 데이터와 RL 학습 과정에서 수많은 나쁜 아키텍처 결정을 봐왔잖아요. 여러분이 애플리케이션 설계를 맡겼어요. 결과가 뭔지 맞춰보세요.

어마어마한 양의 복잡성, 끔찍한 카고 컬트식 “업계 모범 사례”의 혼합물을 너무 늦기 전에 제어하지 못한 거예요. 그런데 그것보다 더 심각한 게 있어요.

에이전트들은 서로의 실행을 보지 못해요. 코드베이스 전체도 못 보고, 변경을 가하기 전에 여러분이나 다른 에이전트가 내린 결정도 보지 못하죠. 그래서 에이전트의 결정은 항상 지역적이고, 위에서 설명한 바로 그 뻘짓들로 이어져요. 엄청난 양의 코드 중복, 추상화를 위한 추상화.

이 모든 게 복구 불가능한 복잡성 덩어리로 쌓여요. 인간이 만든 엔터프라이즈 코드베이스에서 볼 수 있는 바로 그 혼란이요. 인간 세계에서는 고통이 수많은 사람에게 분산되니까 그렇게 되는 거예요. 개인이 느끼는 고통이 “이거 고쳐야겠다”의 임계점을 넘지 못해요. 개인한테 고칠 수단이 없을 수도 있고요. 그리고 조직은 고통에 대한 내성이 엄청나게 높아요. 하지만 인간이 만든 엔터프라이즈 코드베이스는 그 상태에 도달하기까지 수년이 걸려요. 조직은 그 복잡성과 함께 서서히 진화하면서, 비뚤어진 공생 관계 속에서 그걸 다루는 법을 익히죠.

에이전트와 2명짜리 인간 팀이면, 몇 주 안에 그 복잡성에 도달할 수 있어요.

에이전트 코드 탐색은 재현율(recall)이 낮다

이제 에이전트가 그 난장판을 고쳐주길, 리팩토링 해주길, 깨끗하게 만들어주길 바라는데요. 에이전트도 더 이상 감당 못해요. 코드베이스와 복잡성이 너무 크고, 에이전트는 그 난장판의 일부만 볼 수 있으니까요.

컨텍스트 윈도우 크기나 100만 줄짜리 코드 괴물을 보고 롱 컨텍스트 어텐션이 무너지는 것만 말하는 게 아니에요. 그건 뻔한 기술적 한계죠. 문제는 그보다 더 교활해요.

에이전트가 난장판을 고치려면 먼저 변경이 필요한 코드와 재사용할 수 있는 기존 코드를 전부 찾아야 해요. 이걸 에이전트 코드 탐색이라고 부르죠. 에이전트가 어떻게 하느냐는 가진 도구에 달려 있어요. Bash 도구를 줘서 ripgrep으로 코드베이스를 뒤지게 할 수도 있고, 쿼리 가능한 코드베이스 인덱스, LSP 서버, 벡터 데이터베이스를 줄 수도 있어요. 결국 별 차이 없어요. 코드베이스가 커질수록 재현율은 떨어져요. 재현율이 낮다는 건 에이전트가 사실상 좋은 결과를 내기 위해 필요한 코드를 전부 찾지 못한다는 뜻이에요.

이게 바로 코드 스멜 뻘짓이 처음부터 생기는 이유이기도 해요. 에이전트가 기존 코드를 놓치고, 중복하고, 비일관성을 도입하죠. 그러면 그것들이 아름다운 똥꽃으로 활짝 피어나는 거예요.

이 모든 걸 어떻게 피할 수 있을까요?

• • •

에이전트와 이렇게 일해야 해요 (지금은요, 제 생각엔)

코딩 에이전트는 사이렌이에요. 코드 생성 속도와 들쭉날쭉한 지능으로 여러분을 유혹하죠. 간단한 작업은 높은 품질로 눈 깜짝할 새에 완성하거든요. 무너지기 시작하는 건 여러분이 이런 생각을 할 때예요: “세상에, 이거 진짜 대박이다. 컴퓨터야, 내 일 해줘!”

에이전트한테 작업을 맡기는 것 자체에 문제는 없어요, 당연하죠. 좋은 에이전트 작업에는 몇 가지 공통점이 있어요: 에이전트가 시스템 전체를 이해할 필요 없이 범위를 좁힐 수 있어요. 루프를 닫을 수 있어요, 즉 에이전트가 자기 작업을 스스로 평가할 방법이 있다는 뜻이에요. 결과물이 미션 크리티컬하지 않아요, 누구의 목숨이나 매출이 걸려 있지 않은 임시 도구나 내부 소프트웨어인 거죠. 아니면 아이디어를 튕겨볼 러버덕이 필요한 건데, 이건 기본적으로 인터넷과 합성 훈련 데이터에서 압축된 지혜에 아이디어를 던져보는 거예요. 이 중 하나라도 해당되면 에이전트한테 딱 맞는 작업을 찾은 거예요. 물론 여러분 인간이 최종 품질 게이트라는 전제하에요.

Karpathy8의 auto-research를 앱 시작 시간 단축에 적용한 것? 훌륭해요! 그 코드가 프로덕션에 쓸 수 있는 수준이 전혀 아니라는 걸 이해하는 한에서요. auto-research가 작동하는 이유는 에이전트한테 평가 함수를 주기 때문이에요. 시작 시간이나 loss 같은 메트릭으로 자기 작업을 측정할 수 있게 해주는 거죠. 하지만 그 평가 함수는 아주 좁은 메트릭만 포착해요. 에이전트는 평가 함수가 잡지 않는 메트릭, 예를 들어 코드 품질, 복잡성, 심지어 정확성까지도 기꺼이 무시할 거예요(평가 함수가 엉망이면요).

요점은 이거예요: 에이전트한테 지루한 일을 시키세요, 새로 배울 게 없는 일이나 시간이 없어서 시도 못 했을 다양한 접근법을 탐색하는 일이요. 그다음 에이전트가 내놓은 결과를 평가하고, 실제로 합리적이고 올바른 아이디어를 골라서 구현을 마무리하세요. 네, 물론 마무리 단계에도 에이전트를 쓸 수 있어요.

그리고 저는 X발 좀 천천히 하는 게 답이라고 제안하고 싶어요. 지금 뭘 만들고 있는지, 왜 만들고 있는지 생각할 시간을 자신에게 주세요. “아 X발 이건 필요 없어”라고 말할 기회를 자신에게 주세요. 하루에 기계가 생성하는 코드량을 여러분이 실제로 코드를 리뷰할 수 있는 능력에 맞춰 제한하세요.

시스템의 게슈탈트를 정의하는 것, 즉 아키텍처나 API 같은 것은 직접 쓰세요. 약간의 향수를 위해 탭 완성을 쓸 수도 있죠. 아니면 에이전트와 페어 프로그래밍을 하거나요. 코드 안에 있으세요. 직접 코드를 쓰거나 한 단계씩 만들어지는 과정을 지켜보면 마찰이 생겨요. 그 마찰 덕분에 뭘 만들고 싶은지, 시스템이 어떻게 “느껴지는지”를 더 잘 이해하게 되죠. 여기서 여러분의 경험과 안목이 빛을 발해요. 현재 최첨단 모델로는 이걸 대체할 수 없거든요. 그리고 X발 좀 천천히 하면서 약간의 마찰을 감수하는 게 바로 여러분을 배우고 성장하게 해주는 거예요.

최종 결과물은 유지보수가 계속 가능한 시스템과 코드베이스가 될 거예요. 적어도 에이전트 이전의 옛날 시스템만큼은요. 네, 그것들도 완벽하지는 않았어요. 여러분의 제품이 이제 슬롭이 아니라 기쁨을 주니까, 사용자들이 감사할 거예요. 기능은 더 적게 만들겠지만, 제대로 된 것만 만들게 돼요. “아니요”라고 말하는 법을 배우는 것 자체가 하나의 기능이에요.

무슨 일이 벌어지고 있는지 이해하고 있고, 주체성을 갖고 있다는 걸 알면서 편히 잘 수 있어요. 여러분이 코드를 이해하고 있으니 에이전트 코드 탐색의 재현율 문제를 보완해줄 수 있고, 결과적으로 기계 출력물의 품질이 올라가서 손질도 덜 필요해져요. 그리고 일이 틀어지면, 직접 들어가서 고칠 수 있어요. 아니면 초기 설계가 차선이었다면, 왜 차선인지 이해하고 있고, 어떻게 더 나은 것으로 리팩토링할 수 있는지 알아요. 에이전트가 있든 없든, 알 바 아니에요.

• • •