끼어드는 게 제 일이에요

코딩 에이전트와 협업하는 방식은 크게 두 가지로 나뉩니다. 두 방식을 모두 수백 시간 이상 써보니 결과물의 차이가 손끝으로 분명하게 느껴집니다.

첫 번째 방식은 요구사항을 던져두고 알아서 하도록 내버려두는 것입니다. 구현하고 싶은 기능을 설명하고, 에이전트가 계획을 세우고, 코드를 작성하고, 테스트가 끝났다고 선언할 때까지 온전히 루프에 맡깁니다. 두 번째 방식은 출발은 같지만 실행 도중 사람이 적극적으로 끼어듭니다. 몇 턴 지나지 않아 실행을 잠시 멈추고, 태스크를 잘게 쪼개고, 모델이 어디를 가장 까다롭게 보는지 묻고, 그 계획을 함께 검토한 뒤에야 실제 코드 작성을 승인합니다.

두 방식이 만들어내는 결과물의 격차는 결코 작지 않습니다. 아예 다른 등급의 코드가 나옵니다.

2년 전이었다면 새로운 도구를 온전히 신뢰하지 못하는 개발자의 노파심으로 치부되었을지도 모릅니다. 하지만 그사이 기반 모델의 지능은 극적으로 향상되었고 하네스도 고도화되었습니다. 그런데도 격차는 여전히 그대로입니다. 이 글은 그 이유를 짚어보는 기록입니다.

사이드 프로젝트에서는 혼자 돌아가는 루프가 충분히 매력적입니다

토이 프로젝트를 주로 만드시는 분들이 왜 완전 자율 루프를 선호하시는지 잘 압니다. 주말의 저 역시 그런 개발자입니다. 명확하고 단순한 기능 하나를 던져두고 에이전트가 끝까지 달리게 두면 꽤 만족스러운 코드가 뚝딱 완성됩니다. 한때는 저 역시 이 경험을 바탕으로 “이제 에이전트가 소프트웨어 개발을 온전히 끝낼 만큼 똑똑해졌으니, 화면 앞에서 일일이 간섭하는 것은 과거의 집착에 불과하다”고 믿었던 적이 있습니다.

하지만 월요일에 출근해 프로덕션 코드베이스에서 똑같이 손을 놓고 있으면 결국 전체를 롤백하고 폐기해야 하는 코드가 쏟아져 나왔습니다.

이것은 모순이 아닙니다. 스탠퍼드 대학의 예고르 데니소프-블랑슈(Yegor Denisov-Blanch) 연구팀은 600개 이상 기업의 개발자 10만 명 이상을 대상으로 실제 프로덕션 저장소의 기능 납품량을 분석했습니다. 전체 생산성 향상치는 평균 15~20%로 집계되었습니다. 그런데 이 평균치는 작업 환경에 따른 극단적인 편차를 가리고 있습니다:

• 복잡도가 낮은 신규 프로젝트: 약 30~35% 향상
• 복잡도가 높은 신규 프로젝트: 약 10~15% 향상
• 복잡도가 낮은 기존 코드베이스: 약 15~20% 향상
• 복잡도가 높은 기존 코드베이스: 약 5~10% 향상

주말 사이드 프로젝트가 표의 왼쪽 상단이라면, 엔터프라이즈 업무는 오른쪽 하단입니다. 똑같은 도구를 정직하게 사용하면서도 작업 환경에 따라 서너 배에서 예닐곱 배까지 생산성 차이가 벌어집니다. 더 중요한 사실도 있습니다. 저 15~20%는 AI가 유발한 결함을 수정하는 재작업 비용을 이미 차감한 순수 결과입니다.

그러니 자율 루프로도 충분하다는 동료들의 말은 결코 틀리지 않았습니다. 다만 그들의 프로젝트가 아직 복잡성의 청구서를 발행하지 않았을 뿐입니다.

본질적인 문제는 모델의 지능이 아니라 스코프의 폭주입니다

복잡한 시스템에서 에이전트를 방치했을 때 마주하는 실패는 구문 오류를 내며 멈추는 모습이 아닙니다. 반대로 지나치게 많이 만들어내는 오버엔지니어링입니다. 요구하지도 않은 추상화 계층을 도입하고, 간단한 패치를 거대한 다계층 리팩터링으로 키우며, 성능 벤치마크도 없이 불필요한 캐시 레이어를 얹고, 영원히 쓰이지 않을 엣지 케이스를 위한 설정 옵션들을 만듭니다. 커밋 하나하나는 그럴싸해 보이지만 합쳐놓고 보면 누구도 유지보수하고 싶지 않은 기형적인 코드가 탄생합니다.

이 현상은 학술적으로도 뚜렷하게 관측됩니다. 홍콩과기대(HKUST)의 2026년 7월 연구에 따르면, 명세가 다소 모호한 현실적 지시를 주었을 때 에이전트가 요구된 범위를 벗어나 불필요한 수정을 가하는 비율(OverScope rate)이 모델과 프레임워크에 따라 24.9%에서 44.4%에 달했습니다. 행동을 취한 실행 중 절반 이상이 경계를 하나 이상 침범했습니다. 에이전트는 모호한 지시문 앞에서도 멈추지 않습니다. 스스로 가정을 날조한 뒤 그대로 실행에 옮겨버립니다.

코드 diff에서도 비대화는 뚜렷합니다. CMU·스탠퍼드·프린스턴·UIUC의 공동 연구에 따르면 에이전트가 생성한 패치는 인간 기준 패치보다 일관되게 길었습니다. 15% 이상의 케이스에서는 기준 코드량의 1.5배를 초과하는 군더더기 코드가 포함되었습니다. 중요한 것은 이 비대화가 높은 태스크 성공률 뒤에 가려져 지속된다는 점입니다. 벤치마크는 성공했다고 판정하지만 실제 변경점은 필요한 코드의 두 배를 품고 있습니다.

그리고 늘어난 코드량 그 자체가 시스템의 독이 됩니다. 콩코디아 대학(Concordia) 연구에서 코드 라인 수와 아키텍처 스멜 간의 상관계수는 무려 ρ = 0.94에 달했습니다. 연구진은 이를 ‘코드량–품질 역법칙’이라 명명했습니다. 코드 줄 수가 늘어나는 것 자체가 소프트웨어의 아키텍처 붕괴를 사실상 완벽하게 예측한다는 뜻입니다. 더 충격적이게도 지능이 높은 최신 프론티어 모델일수록 코드를 더 방대하고 복잡하게 엮어냅니다. 몇 줄의 프롬프트 기교로는 이 고유의 비대화 경향을 교정할 수 없었습니다.

소프트웨어 컨설팅 기업 소트웍스(Thoughtworks)의 에릭 되른부르크(Erik Doernenburg) 역시 맥용 CI 도구에 GitLab 연동을 추가하던 평범한 개발 과정을 기록으로 남겼습니다. 에이전트는 아무도 원하지 않는 캐시를 추가하고, 존재하지 않는 예외 상황을 위한 복잡한 방어 로직을 짰으며, 이미 존재하는 유틸리티를 무시하고 URL 조합 함수를 중복 생성했습니다. 그의 결론은 현업 개발자들의 심경을 대변합니다. “AI 에이전트를 그대로 내버려두었다면 코드베이스를 확실히 망쳐놓았을 것이며, 그 문제를 짚어내는 데는 숙련된 엔지니어의 안목이 필수적이었다.”

에이전트는 스스로 멈추지 않습니다

제 작업 방식을 결정적으로 바꾼 데이터가 있습니다.

스탠퍼드와 NYU 연구팀이 실제 오픈소스 개발 세션 6,000건(프롬프트 63,000건, 툴 호출 355,000건)을 분석한 SWE-chat 데이터셋입니다.

이 관측 데이터에는 놀라운 비대칭이 드러납니다:

에이전트가 작업 도중 능동적으로 명확성을 묻는 턴은 전체의 1.4%에 불과한 반면, 개발자가 피드백을 주며 개입하는 턴은 44%에 달했습니다.

그리고 이 소통 부재의 대가는 혹독합니다: 에이전트가 작성한 코드 중 실제 최종 커밋까지 살아남은 비율은 44%에 불과했습니다. 에이전트가 쏟아낸 코드의 절반 이상이 쓰레기통으로 직행했습니다.

연구진은 이렇게 분석합니다. 에이전트가 자율성을 확보하는 속도가 사람에게 언제 질문해야 하는지 학습하는 속도보다 훨씬 빠르기 때문에 그로 인한 비용을 온전히 사용자가 떠안고 있습니다. 에이전트의 기본값은 무조건적인 ‘전진’입니다. 명세가 부족하면 스스로 빈틈을 상상력으로 채우고 무작정 코드를 칩니다. 모호한 요구사항과 거대한 쓰레기 diff 사이를 가로막는 유일한 방파제는 중간에 끼어들기로 결단하는 인간 개발자뿐입니다.

에이전트의 실행을 끊는 일은 작업을 방해하는 일이 아닙니다. 프로젝트의 스코프가 비로소 제자리를 찾는 핵심 순간입니다.

중간 개입이 가져다주는 압도적인 레버리지

적절한 중간 개입은 투입되는 에너지 대비 엄청난 품질 향상을 이끌어냅니다.

단순히 질문 단계를 추가하여 에이전트가 모호한 부분을 먼저 묻도록 유도한 것만으로도 ClarifyGPT 연구에서 GPT-4의 문제 해결률(pass@1)이 70.96%에서 80.80%로 10포인트 상승했습니다. 하지만 ClarifyCodeBench가 지적하듯, 현재의 모델들은 스스로 빠진 맥락을 파악해 날카로운 질문을 던지는 능력이 여전히 부족합니다. 결국 무엇을 짚고 넘어가야 할지 묻는 쪽은 인간이어야 합니다.

작업을 세분화하는 것도 마찬가지입니다. IBM 연구팀이 거대한 단일 프롬프트를 검증 단계를 거치는 작은 하위 태스크들로 재구성하자, 재시도 비용이 최대 51.7%까지 절감되었습니다. 에이전트를 잠시 멈추고 “이 단계까지만 먼저 구현하자”고 통제하는 직관적인 개입이 낭비되는 리소스를 절반으로 줄여줍니다.

전문 개발자 45명을 대상으로 한 CentaurEval 실험에서도 완전 자율 AI의 성공률은 0.67%, 인간 단독은 18.89%였습니다. 반면 인간과 AI가 능동적으로 조율하며 협업했을 때는 31.11%로 급등했고 작업 완료 속도 역시 가장 빨랐습니다.

방향을 조율하는 일의 현실적인 고단함

개입과 조율이 만병통치약이라고 미화하고 싶지는 않습니다. 조율을 계속하는 데는 명백한 인지적 비용이 따릅니다.

태스크를 잘게 쪼개는 것은 방향 이탈을 막아줍니다. 하지만 잘게 쪼개진 계획들을 일일이 검토하는 과정 자체가 결코 가볍지 않습니다. 에이전트가 세운 실행 계획에서 스코프 왜곡이나 은밀한 결함을 찾아내려면 그 계획을 직접 설계할 때에 준하는 높은 시스템 이해도가 요구됩니다. 하루에도 수십 번씩 이 검토를 반복하다 보면 피로감이 상당히 쌓입니다.

이 피로는 개인의 역량 부족 때문이 아닙니다. 학계와 산업계가 자율성 극대화에만 연구를 집중하느라 상호 조율성(steerability)과 실시간 검증 인터페이스를 제대로 마련하지 못한 탓에 생긴 공백의 비용입니다.

이 조율 작업은 분명 고도의 전문 엔지니어링 역량입니다. 진정한 레버리지는 탄탄한 도메인 지식에 기반한 날카로운 질문에서 나옵니다. 우리 시스템에서 어느 모듈이 하중을 견디고 있는지, 어떤 예외 상황이 진짜 위험이고 어떤 것이 기우인지, 기존 코드베이스의 어떤 자산을 재활용해야 하는지 꿰뚫어 보는 안목입니다. 이것은 프롬프트 말장난이 아니라, 기존의 소프트웨어 설계 판단력을 한 단계 높은 추상화 층위에서 발휘하는 일입니다.

제가 에이전트를 조율할 때 지향하는 방향은 언제나 하나입니다: 더 단순한 구조, 더 적은 코드. 코드가 적을수록 테스트할 대상도 줄고 검토 피로도 줄어듭니다. 코드 줄 수와 아키텍처 부패의 상관계수가 0.94에 달한다는 사실을 기억한다면, diff를 최소한으로 억제하는 조율이야말로 코드베이스가 썩어가는 것을 막는 가장 현실적인 방어선입니다.

루프가 편안하게 느껴지다 무너지는 이유

완전 자율 루프의 유혹에서는 벗어나기 어렵습니다. 실패가 발생하는 순간에는 아무런 위험 신호도 감지되지 않기 때문입니다.

METR의 2025년 개발자 실험은 이 간극을 생생하게 보여줍니다. 숙련된 개발자들은 AI 도구를 사용할 때 실제로는 19% 느려졌는데도 스스로는 20% 빨라졌다고 착각했습니다. 체감 속도와 객관적인 스톱워치 사이의 인지 격차는 무려 39포인트에 달했습니다.

장기적인 영향은 더 파괴적입니다. 중산대학과 알리바바가 실제 저장소 기록을 기반으로 장기 유지보수 루프를 시뮬레이션한 SWE-CI 연구에 따르면, 모델의 75% 이상에서 회귀 결함 발생률이 가속화되었습니다. 단기 세션 안에서는 매 단계가 테스트를 통과하며 순항하는 것처럼 보입니다. 하지만 루프가 길어질수록 과거의 정상 기능들을 망가뜨리는 빈도가 기하급수적으로 늘어납니다.

기업 차원에서도 마찬가지입니다. 구글 클라우드의 DORA 2025 리포트에 따르면 AI 도입은 코드 산출량과는 양의 상관관계를 보였지만 배포 안정성과는 지속적으로 음의 상관관계를 나타냈습니다. 변경 실패율과 재작업이 오히려 증가했습니다. AI는 훌륭한 프로세스는 더 단단하게 만들지만 취약한 프로세스는 더 빠르게 파괴하는 증폭기입니다.

이 모든 부채는 코드가 생성된 그 황홀한 순간에는 보이지 않다가 몇 주 혹은 몇 달 뒤 프로덕션 장애라는 청구서로 돌아옵니다.

현실적인 결론

인간의 조율이 영원히 필요한 절대적 규칙이라고 주장할 수는 없습니다. 메타의 SWE-Together 연구가 보여주듯, 모델의 추론 능력이 향상될수록 필요한 교정 피드백의 양은 뚜렷하게 감소하고 있습니다. 모델의 발전과 함께 개발자가 일일이 간섭해야 하는 번거로움도 서서히 줄어들 것입니다.

따라서 중간 개입과 조율 역시 기술의 과도기에 요구되는, 수명이 유한한 역량일지도 모릅니다. 하지만 적어도 지금 복잡한 현실의 소프트웨어를 지탱하는 현장에서는 이 역량이 여전히 치명적인 차이를 만들어냅니다. “모델이 충분히 좋아져서 감시를 멈추었다”는 방심과 “모델이 정말로 충분히 좋아져서 감시할 필요가 없어졌다”는 냉정한 현실 사이의 간극에서 값비싼 장애들이 싹틉니다.

오늘날의 에이전트는 여전히 멈추지 않고, 여전히 요구 이상으로 과하게 구현하며, 여전히 필요 이상의 복잡성을 코드베이스에 쏟아붓습니다.

그래서 저는 오늘도 실행 중간에 기꺼이 끼어듭니다. 도구를 불신해서가 아니라, 그 개입의 순간이야말로 엔지니어로서 제가 발휘해야 할 가장 가치 있는 일이기 때문입니다.