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

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

• • •

들어가며

프로젝트를 통째로 빌드할 수 있는 코딩 에이전트가 등장한 지 대략 1년 됐어요. Aider나 초기 Cursor1 같은 도구들은 어시스턴트에 가까웠는데, 새 세대 에이전트들은 확실히 한 단계 다르죠. 특히 Anthropic과 OpenAI가 연휴마다 무료 크레딧을 뿌리면서 채택이 확 늘었고요.

여가 시간에 개인 프로젝트로 에이전트 돌려보는 건 솔직히 재밌어요. 새로운 기술 스택 배울 때도 좋고요. 그런데 프로덕션 코드베이스에 코딩 에이전트를 투입한 지 12개월이 지나니까, 꽤 걱정되는 패턴들이 눈에 띄기 시작했어요.

다 망가지고 있다

소프트웨어가 갈수록 부실해지고 있어요. 대형 서비스가 98% 가용률5로 돌아가는 게 예외가 아니라 그냥 일상이 됐잖아요. UI에는 프로 QA 팀이라면 당연히 잡았어야 할 이상한 버그들이 버젓이 살아있고요. 이 패턴 자체는 코딩 에이전트 이전부터 있었지만, 속도가 붙고 있다는 건 확실해요.

”AI가 AWS 장애를 일으켰다”는 보도가 나왔어요 (AWS는 부인했지만요). 그 뒤로 코드 관리 체계를 90일간 리셋하는 조치가 이어졌죠. Microsoft CEO 사티야 나델라는 “회사 코드의 최대 30%가 AI로 작성됐다”고 했는데, 정작 Windows 품질은 갈수록 나빠진다는 평가가 나오고 있거든요.

”코드 100% AI로 짰어요”를 자랑하는 회사들 보면, 메모리 누수에 UI 깨짐에 크래시 투성이인 제품을 내놓는 경우가 허다해요. 업계 안쪽에서는 팀들이 “에이전트로 코딩하다가 막다른 골목에 몰렸다”는 얘기가 돌고 있죠. 코드 리뷰는 안 하고, 설계 결정은 에이전트한테 맡기고, 아무도 안 원하는 기능이 우후죽순 생겨나는 게 원인이에요.

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

지금의 접근 방식은 에이전트를 알아서 척척 해내는 자율 부대처럼 쓰는 거예요. 이 패키지가 뭔지도 모르면서 일단 깔고, 다음 세대 LLM이 지금 문제를 다 고쳐줄 거라 믿고, 소프트웨어가 “6개월이면 해결되는 문제”라고 보는 사고방식이죠.

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

에이전트도 인간도 실수는 해요. 하지만 인간은 같은 실수를 반복하다 보면 피드백이든 대가든 뭔가를 통해 배우잖아요. 에이전트한테는 그런 학습 능력 자체가 없어요. 똑같은 삽질을 끝없이 반복하죠.

결정적으로, 인간은 병목이에요. 시간당 수천 줄의 코드를 쏟아낼 수가 없거든요. 에러가 천천히 쌓이고, 고통을 느끼니까 고치려는 동기도 생기죠. 에이전트를 대규모로 돌리면 이 병목이 완전히 사라져요. 하나하나는 별것 아닌 작은 에러들이 기계 속도로 찍혀 나오면, 개발자가 코드베이스의 퇴화를 알아채기도 전에 감당 불가능한 수준으로 쌓여버리는 거예요.

결과요? 시스템 전체를 신뢰할 수 없게 돼요. 테스트 스위트마저도요. 결국 수동 테스트에만 매달릴 수밖에 없게 되죠.

복잡성 장사꾼들

아키텍처 결정을 에이전트한테 맡기면 어마어마한 복잡성이 생겨나요. 에이전트는 훈련 데이터에서 주워온 아키텍처 패턴을 아무 제약 없이 들이붓거든요. 누가 감독하기도 전에 끔찍한 카고 컬트2식 “업계 모범 사례”가 코드에 박혀버리죠.

거기다 에이전트는 코드베이스의 일부분만 보고 있어요. 전체 시스템도, 이전에 내린 결정도 모르죠. 이런 근시안이 코드 중복, 쓸데없는 추상화, 일관성 없는 패턴을 만들어내요. 인간이 만든 엔터프라이즈 코드베이스는 조직이 변하면서 수년에 걸쳐 이런 복잡성에 도달하잖아요. 에이전트 지원 팀은 몇 주 만에 거기 도달해버려요.

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

코드베이스가 커지면 에이전트 기반 리팩토링은 사실상 불가능해져요. 관련 코드를 빠짐없이 찾아내지도 못하고, 재사용할 수 있는 기존 컴포넌트도 놓치거든요. 이런 탐색의 한계 때문에 같은 기능이 중복되고, 일관성 없는 코드가 양산되면서 복잡성이 눈덩이처럼 불어나는 거죠. 전형적인 코드 스멜3이에요.

• • •

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

에이전트가 잘하는 영역은 분명히 있어요. 범위가 딱 정해져 있어서 시스템 전체를 몰라도 되는 작업, 결과물을 바로 평가할 수 있는 작업, 핵심이 아닌 소프트웨어, 브레인스토밍 같은 탐색적 시나리오요. Andrej Karpathy4의 auto-research를 성능 최적화에 적용한 사례가 좋은 예시인데, 물론 그 결과물이 프로덕션에 쓸 만한지는 인간이 판단해야 하지만요.

핵심은 이거예요: 의도적으로, 확 느려지세요.

지금 뭘 만들고 있는지, 왜 만드는지 생각할 시간을 자신에게 주세요. 하루에 에이전트가 뽑아내는 코드량을 현실적으로 리뷰할 수 있는 만큼으로 제한하세요. 아키텍처 결정, API, 그리고 시스템을 정의하는 핵심 요소는 직접 쓰세요. 에이전트한테는 탭 완성이나 페어 프로그래밍 수준의 역할만 맡기고요.

직접 코드를 쓰거나, 한 단계씩 만들어지는 과정을 지켜보는 이 마찰이 진짜 이해를 만들어내요. “경험과 안목”은 여전히 인간만이 가진 대체 불가능한 역량이거든요. 지금 모델들로는 이걸 흉내 낼 수가 없어요.

의도적으로 느리게 가면 뭐가 좋냐고요?

• 유지보수 가능한 시스템
• 만족스러운 사용자 경험
• 선별적인 기능 개발
• 장애나 리팩토링 시 진짜 이해에 기반한 대응

시스템을 이해하고 있으면 에이전트 코드 탐색의 재현율 문제를 직접 메꿀 수 있고, 에이전트한테 더 나은 결과물을 뽑아낼 수도 있어요.

• • •

마치며

위기 상황에서 주도권을 잃지 않고, 시스템을 이해하고, 직접 개입할 수 있으려면, 결국 인간의 규율과 참여가 필요해요. 에이전트한테 알아서 하라고 던져놓는 게 아니라, 인간과 에이전트가 의도적으로 함께 일해야 하는 거예요.