끼어드는 게 제 일이에요

코딩 에이전트와 일하는 방식은 두 가지예요. 둘 다 오래 해봤고, 이제는 차이가 손끝으로 느껴져요.

하나는 태스크를 넘기고 그냥 돌리는 거예요. 원하는 걸 설명하고, 계획을 세우게 하고, 다 했다고 할 때까지 루프를 돌게 둬요. 다른 하나는 같은 자리에서 중간에 끊는 거예요. 몇 턴 지난 뒤 멈춰 세우고, 더 작게 쪼개고, 제일 어려운 부분이 뭐냐고 묻고, 그 답에 반박한 뒤에야 코드를 쓰게 해요.

둘의 차이는 작지 않아요. 결과물의 급이 달라요.

2년 전이라면 도구를 못 믿는 사람 이야기로 넘길 수 있었어요. 그런데 모델도 하네스도 그동안 훨씬 좋아졌고, 그런데도 차이는 남아 있어요. 설명하고 싶은 건 그 부분이에요.

동의 안 하실 텐데, 그쪽 프로젝트에선 맞는 말이에요

개인 프로젝트 위주로 만드는 분들에게 이 말이 어떻게 들릴지 알아요. 주말의 제가 바로 그 사람이에요. 저도 루프를 돌려요. 간단한 요구사항 하나 던지고 끝까지 두면 결과는 괜찮아요. 한동안은 그걸, 모델과 하네스가 처음부터 끝까지 해낼 만큼 좋아졌다는 증거로 받아들였어요.

그리고 월요일에 같은 습관으로 일하면 버려야 할 결과물이 나왔어요.

이제는 모순이라고 생각하지 않아요. 루프를 돌리는 분들이 자기 경험을 틀리게 말하는 것도 아니고요. 스탠퍼드의 Yegor Denisov-Blanch 팀은 10만 명 이상, 600개 이상 회사의 프라이빗 저장소에서, 커밋 수가 아니라 실제로 전달된 기능을 기준으로 이걸 측정해 왔어요. 평균 상승폭은 15~20%인데, 그 평균이 이야기를 통째로 가려요. 일의 종류로 쪼개면 이렇게 갈려요.

• 복잡도 낮은 신규 코드: 약 30~35%
• 복잡도 높은 신규 코드: 약 10~15%
• 복잡도 낮은 기존 코드베이스: 약 15~20%
• 복잡도 높은 기존 코드베이스: 약 5~10%

주말 프로젝트는 왼쪽 위 칸, 제 직장 일은 오른쪽 아래 칸이에요. 같은 도구를 쓰고 둘 다 솔직하게 말하는 두 사람 사이에 3~6배 차이가 있는 셈이에요. 게다가 15~20%는 재작업 비용을 뺀 숫자예요. AI가 만든 문제를 고치는 시간이 이미 포함돼 있어요.

그래서 루프로 충분하다는 말에 저는 틀렸다고 하지 않아요. 아직 그 프로젝트가 청구서를 보내지 않았을 뿐이에요.

능력이 아니라 스코프가 문제예요

에이전트를 그냥 돌려놓으면 실패하지는 않아요. 대신 과하게 만들어요. 아무도 요청하지 않은 추상화를 꺼내고, 설명한 것보다 두 단계 큰 기능을 계획하고, 측정 없이 캐시를 넣고, 생기지 않을 케이스를 위한 설정을 만들어요. 하나씩 보면 변호할 수 있는 결정이지만, 합치면 떠안고 싶지 않은 시스템이 돼요.

이건 측정돼요. HKUST의 2026년 7월 연구는 현실적이지만 명세가 덜 된 지시를 주고 경계 밖 행동을 셌어요. 필요한 범위를 넘어 행동한 비율은 모델과 하네스에 따라 24.9%에서 44.4% 사이였어요. 행동한 실행의 55.8~67.8%가 최소 한 번 경계를 침범했고, 올바른 대상에 올바른 행동을 한 비율은 15.5~36.8%에 그쳤어요. 에이전트는 애매한 작업을 거절하지 않았어요. 추측하고 실행했어요.

diff에서도 같은 게 보여요. CMU·스탠퍼드·프린스턴·UIUC의 포지션 페이퍼에 따르면 에이전트의 패치는 사람의 레퍼런스보다 일관되게 길고, 테스트한 모든 모델에서 15% 이상의 패치가 1.5배 넘게 부풀어 있었어요. 중요한 건 이게 성공률이 높은데도 남는다는 점이에요. 벤치마크는 성공이라 말하고, diff는 필요한 양의 두 배를 썼다고 말해요.

그리고 문제는 그 양이에요. Concordia 대학 연구에서 코드 라인 수와 아키텍처 스멜의 상관계수는 ρ=0.94로 나왔어요. 저자들은 이걸 ‘양–품질 역법칙’이라고 불러요. 그 정도면 코드 양이 아키텍처 부패를 거의 완벽하게 예측한다는 뜻이에요. 두 번째 발견은 더 나빠요. 뛰어난 모델일수록 덜이 아니라 더 부풀고 얽힌 코드를 만들었어요. Long Method는 가장 강한 모델에서 11~13건, 사람 기준선에서 1건이었어요. few-shot 프롬프팅으로도 고쳐지지 않았고, 스멜은 “정체되거나 오히려 나빠졌”고요.

마지막 문장에 밑줄을 긋고 싶어요. 프롬프트를 더 잘 쓰는 걸로 오버엔지니어링이 해결됐다면, 이 글은 에세이가 아니라 프롬프트 템플릿이었을 거예요.

특별한 이야기도 아니에요. Thoughtworks의 Erik Doernenburg가 1월에 평범한 사례를 기록했어요. 맥용 CI 앱에 GitLab 지원을 붙이는 작업에서, 에이전트는 필요 없는 캐시를 제안했고, 존재하지 않는 문제를 위한 로직을 짰고, 이미 있는 함수를 두고 URL 조립을 중복해 만들었어요. 그의 결론은 제 결론과 같아요. “AI 에이전트를 그대로 두었다면 코드베이스를 더 나쁘게 바꿔놨을 명백한 사례이고, 그걸 알아채는 데는 경험 있는 개발자가 필요했다.”

에이전트는 멈춰 주지 않아요

생각을 다시 정리하게 만든 건 이 결과예요.

스탠퍼드와 NYU의 SWE-chat은 오픈소스 개발자의 실제 코딩 세션 6,000건을 모은 데이터셋이에요. 사용자 프롬프트 63,000개, 툴 콜 355,000개. 벤치마크가 아니라 사람들이 실제로 일하는 동안 남은 기록이에요.

두 숫자가 나란히 있어요.

에이전트가 멈춰 확인 질문을 하는 건 전체 턴의 1.4%, 사용자가 되받아치는 건 44%. 끝난 뒤의 수정 지시가 39%, 실행 중 강제 중단이 3.3~6%예요.

그 비대칭의 대가는 이래요. 에이전트가 만든 코드 중 커밋까지 살아남는 건 44%뿐이에요. 절반 넘게 버려져요.

저자들의 해석도 같아요. 에이전트는 언제 물어야 하는지를 배우는 속도보다 자율성을 얻는 속도가 빠르고, 그 차이를 사용자가 떠안아요. 에이전트에게 설정은 하나뿐이고, 계속 진행이에요. 명세가 얇으면 조용히 빈칸을 채우고 그대로 가요. 얇은 명세와 크고 자신감 있는 diff 사이를 막는 건, 끊고 들어가기로 결심하는 사람 하나예요.

그래서 저는 끼어드는 걸 워크플로의 마찰로 보지 않게 됐어요. 루프 전체에서 스코프가 실제로 정해지는 지점은 거기뿐이니까요.

끊고 들어가면 얻는 것

개입의 비용은 효과에 비해 싸요.

확인 질문 단계를 넣는 것만으로 ClarifyGPT 연구에서 GPT-4의 MBPP-sanitized pass@1이 70.96%에서 80.80%로 올랐어요. 먼저 물었다는 것만으로 10점이에요. 문제는 모델이 이걸 스스로 하지 않는다는 점이에요. ClarifyCodeBench는 지금 LLM이 무엇이 빠졌는지 알아채고 좋은 질문을 던지는 데 여전히 약하다고 보고해요. 질문은 다시 사람 몫으로 돌아오고, 질문의 품질이 결과물의 구조를 떠받쳐요.

쪼개기도 들이는 품에 비해 효과가 커요. IBM 팀은 하나의 거대한 프롬프트를 중간 결과가 검증되는 작은 서브태스크로 재구성해 재시도 비용을 최대 51.7% 줄였어요. 제가 에이전트를 멈춰 세우고 “이 부분만 먼저”라고 말할 때 손으로 하는 게 정확히 그거예요.

CentaurEval은 전문 개발자 45명으로 직접 비교했어요. 완전 자율 AI 0.67%, 사람 단독 18.89%, 사람과 AI가 함께 31.11%였고, 그러면서 양쪽보다 빨랐어요. 다만 느슨하게 받아들이는 편이 좋아요. 과제를 협업이 필요하도록 설계했기 때문에, 격차의 크기는 벤치마크의 성질이에요. 방향만은 나머지 증거와 같아요.

깔끔하게 만들지 못한 부분

여기서부터는 아직 못 푼 이야기예요.

잘 조종하는 일은 비싸요. 태스크를 작게 쪼개는 건 확실히 도움이 되지만, 그러고 나면 그 쪼갠 결과를 제가 리뷰해야 해요. 만만치 않은 일이에요. 스코프 문제를 잡아낼 만큼 계획을 읽으려면, 그 계획을 직접 쓰는 것과 비슷한 수준의 이해가 필요해요. 태스크마다 곱하면 몇 시간씩 들어가요. 에이전트와 빠르게 합을 맞추는 반복 가능한 방법을 저는 아직 찾지 못했어요.

그걸 제 실패로 보지 않게 된 이유는, 이 분야도 아직 못 풀었기 때문이에요. 앞의 포지션 페이퍼의 논지가 바로 그거예요. 코딩 에이전트 연구가 자율성 극대화로 수렴하면서 조종 가능성(steerability), 검증, 태스크 정렬은 거의 만들어지지 않은 채 남았어요. HKUST 연구가 이걸 구체적으로 보여줘요. 같은 모델이 어떤 하네스에서는 31.8%의 확률로 확인 질문을 했고, 다른 하네스에서는 10.5%였어요. 후자에서는 ‘멈춤’이 조용한 드라이런으로 뭉개졌고요. 조종할 기회를 받기라도 하는지가 지금은 모델이 아니라 도구의 성질이에요.

그러니 그 몇 시간은 제가 굼떠서 쓰는 시간이 아니에요. 아직 아무도 만들어 놓지 않은 단계를 손으로 메우는 값이에요.

말할 수 있는 건, 이게 결국 숙련의 문제라는 점이에요. 레버리지는 실제 도메인 지식을 깔고 좋은 질문을 던지는 데서 나와요. 이 시스템에서 어디가 하중을 받는지, 어떤 엣지 케이스가 실재하고 어떤 게 상상인지, 이미 있는 코드가 어디서 같은 일을 하는지 아는 것. 프롬프트 기술이 아니라, 원래 갖고 있던 엔지니어링 판단을 다른 고도에서 쓰는 일이에요. 저는 조종 단계를 학습의 기회로 취급해요. 에이전트의 계획을 제 문제 모델과 나란히 놓고 읽는 순간에, 둘 중 누가 헷갈리고 있는지 드러나니까요.

밀고 가는 방향은 거의 항상 같아요. 더 단순한 아키텍처, 더 적은 코드. 코드가 적으면 테스트할 것도 리뷰할 것도 적어요. 하지만 그것만이 이유는 아니에요. 앞의 ρ=0.94 때문이에요. 적은 코드를 향해 조종하는 건 취향이 아니라, 코드베이스가 썩는 것과 가장 강하게 상관된 변수에서 멀어지는 일이에요.

루프가 괜찮아 보이다 무너지는 이유

경험만으로 배우기 어려운 이유는, 실패하는 순간에 아무 신호도 뜨지 않기 때문이에요.

METR의 2025년 실험이 가장 깔끔한 증명이에요. 숙련된 개발자들이 실제로는 19% 느렸는데, 본인들은 20% 빨라졌다고 추정했어요. 스톱워치와 체감 사이 39포인트 차이예요. 다만 조심해서 써야 해요. METR은 2026년 2월에 그림을 수정했어요. 이후 실험에서 기존 참가자는 −18%(−38%~+9%), 신규 참가자는 −4%(−15%~+9%)였고, 선택 편향을 인정하며 설계를 다시 하고 있어요. 헤드라인 숫자는 살아남지 못했어요. 그런데 인식의 격차는 살아남았고, 제가 신경 쓰는 건 그 부분이에요. 작업이 얼마나 잘됐는지에 대한 감각은, 자신이 생각하는 걸 측정하고 있지 않아요.

장기 버전은 더 나빠요. 중산대학교와 알리바바의 SWE-CI는 실제 저장소 히스토리로 100개 과제를 만들었어요. 과제 하나가 평균 233일, 71개의 연속 커밋에 걸쳐 있어요. 여기에 에이전트를 유지보수 루프로 돌리자 모델의 75% 이상에서 회귀율이 가속됐어요. 루프가 길어질수록 통과하던 테스트를 더 자주 깨면서도, 눈앞의 과제는 계속 통과시켰다는 뜻이에요. 세션 안에서는 보이지 않는 실패예요. 매 단계가 성공을 보고하고, 추세는 내려가요.

조직 규모에서는 불안정성으로 드러나요. DORA 2025는 AI 도입이 처리량과는 양의 상관을 보이지만 배포 안정성과는 여전히 음의 상관이라고 보고해요. 변경 실패와 재작업이 늘어나요. 보고서의 표현대로 AI는 증폭기여서, 좋은 프로세스는 더 좋아지고 나쁜 프로세스는 더 나빠져요. GitClear의 2026년 리포트는 그 잔여물에 숫자를 붙여요. 중복 81% 증가, 리팩터링성 라인 이동 70% 감소, 파일 간 재사용 35% 감소. ‘AI 코드 2배’ 지시를 추적한 종단 연구는 정작 병목이 생성이 아니라 리뷰 용량이고, 그건 함께 늘지 않는다고 결론지어요.

이 비용들은 모두 만들어진 세션보다 나중에 도착해요. 루프가 기분 좋게 느껴지는 이유예요.

솔직하게 덧붙일 것

조종을 과대 포장하고 싶지는 않아요. 반대로 미는 결과가 하나 있어요.

메타의 SWE-Together는 실제 세션 11,260건에서 재현 가능한 과제 109개를 만들고, 모델별로 필요한 교정 피드백의 양을 쟀어요. 교정 횟수는 모델 능력과 강한 음의 상관을 보였어요(pass@1 대비 r = −0.92). 좋은 모델일수록 덜 조종해도 됐다는 뜻이에요. 그런데 최고 성능 에이전트와 사람 레퍼런스 사이의 약 15포인트 격차는, 교정 피드백을 줘도 남았어요.

솔직하게 읽으면, 조종은 천장을 올리기보다 분산을 줄이고 나쁜 궤적을 일찍 끊는 쪽에 가까워요. 그리고 필요한 양은 모델이 좋아질수록 줄고 있어요.

그러니 이건 언젠가 쓸모가 줄어들 스킬이에요. 괜찮아요. 엔지니어링 스킬은 대부분 그래요. 다만 그 시점은 아직 오지 않았고, “모델이 충분히 좋아져서 확인을 그만뒀다”와 “모델이 충분히 좋아져서 확인할 필요가 없다” 사이의 틈에 비싼 실수가 살아요. 지금 이 시점, 실제 코드베이스 위에서 에이전트는 여전히 멈추지 않고, 과하게 만들고, 필요한 것보다 많은 코드를 내놔요.

그래서 저는 끼어들어요. 도구가 나빠서가 아니라, 끊고 들어가는 그 지점이 제 몫의 일이 일어나는 곳이라서요.