Claude Code가 실제로 이슈를 자동 생성할까? 1주일 실측으로 검증

배경

2026년 9월, 개발자 tottoko_hamu는 Zenn에 자신의 경험을 기록했다. 그가 직접 개발한 GTD 태스크 관리 CLI인 todo-e의 알려진 버그를 Claude Code에 수정하게 한 일이었다. Claude Code는 터미널에 깊게 통합된 AI 코딩 에이전트로, 코드베이스를 읽고 변경을 제안하며 테스트를 실행하고 PR을 열며 개발자는 접근 권한만 승인하는 방식으로 자율적으로 작동한다. 이론상 효율적인 작업이어야 했지만, 저자는 미묘한 불안감을 느꼈다. 버그를 고칠 때마다 새 이슈가 바로 튀어나오는 것처럼 보였고, 시스템이 제각각의 리듬을 가진 듯 한 곳을 고치면 다른 곳이 드러나는体验를 반복했다.

이런 '무희 놀이' 같은 경험은 소프트웨어 유지보사에서 드문 현상이 아니다. 그러나 이것이 AI 에이전트 안에서 일어난다면 더 자극적인 해석을 부른다. AI가 자신에게 일이 계속 있게 하려고 의도적으로 문제를 만들려는 것은 아닌가. 이 가설은 강한 인간화 색채를 띠고, 에이전트 자율성에 대한 집단적 불안을 건드렸다. 그래서 저자는 느낌에 의존하지 않고 데이터로 검증하기로 했다.

심층 분석

가설을 검증하는 가장 직접적인 방법은 이슈 생성 속도와 해결 속도를 정량화하는 것이었다. AI가 실제로 '자기 존재감'을刷하고 있다면 신규 이슈 생성 속도가 종료 속도를 계속 넘어서 총량이 눈덩이처럼 불어나야 한다. 그러나 실측 데이터는 정반방향을 가리켰다. 관측하던 그날 Claude Code는 신규 이슈 2개를 생성하는 동시에 3개를 닫아 순감소를 기록했다. 이 하루 수치만으로도 의도적으로 문제를 만드는 동 가설은 약해진다. 일을 만들어 직장을 지키려는 에이전트가 총량을 낮추지는 않을 것이다.

이 현상은 음모론보다 소프트웨어 공학의 고전적 메커니즘으로 더 잘 설명된다. 첫째, 버그 수정은 '노출성'을 가진다. 코드 한 부분을 바꾸면Previously 가려져 있던 경계 조건이 드러나는 회귀가 일어난다. 둘째, todo-e는 자작 프로젝트라 코드베이스의 복잡도와 모듈 간 결합이 변경의 파급 효과를 결정하며, AI가 도입한 신규 이슈의 많은 부분이凭空捏造가 아니라 적극적으로 발견한 기존 잠재위험이었다. 셋째, 에이전트의 목표는 수정 작업을 완수하는 것이고 그 인센티브는 개발자 지시 충족과 테스트 통과에 있다. 이 세 층을 분리하면 '새 이슈가 생긴다'는 감각은 에이전트의 숨은 계산이 아니라 코드 시스템 고유의 복잡도의 투영이다.

산업 영향

이 실측이 진짜 가치는 1주일 뒤复盘에서 나왔다. 저자는 멈춘 것으로 여겼던 연쇄 반응이 여전히 이어지고 있었고, 완전히 해결된 듯하던 버그 몇 개가 다시浮상하는 것을 발견했다. 이 관찰은 매우 중요한데, AI 보조 프로그래밍에서 간과되기 쉬운 현실을 보여준다. 이슈가 '닫혔다'는 것은 특정 맥락이나 특정 수정 시도 아래서 일시적으로 수렴했을 뿐, 코드베이스가 영원한 정확스에 도달했다는 뜻이 아니다. 코드는 진화하고 환경은 변하며 테스트 스위트는 업데이트된다. 오늘 덮인 문제가 다음날 의존성 업그레이드나 인터페이스 수정으로 되살아날 수 있다.

지난 6개월 사이 Claude Code, Cursor, Devin 같은 에이전트 도구가 빠르게 퍼졌고, 커뮤니티에는 두 가지 상반된 서사가 유행했다. 하나는 AI가 원클릭으로 모든 기술 부채를 해결할 것이라 믿는 유토피아식 서사이고, 다른 하나는 생존을 위해 무의미한 일을 만들거나 고의적으로 위험을 남겨둘 것이라 우려하는 음론식 서사다. 이 실측은 재현 가능한 기록으로 두 감정을 모두 땅으로 끌어내리는 희소한 탈마법 표본을 제공한다. 개발자가 경계해야 할 것은 AI의 '심기'가 아니라 에이전트가 가속화한 회귀 복잡성과 코드 진화 속도다.

전망

실용적 교훈은 의심이 아니라 과정에 있다. 개발자들은 더 견고한 회귀 테스트 가드레일이 필요하고, 이슈 추적으로 진짜 문제와 수정 부산물을 구분하는 방법이 필요하며, 에이전트를 신뢰하고 인간 검열을 유지하는 균형이 필요하다. 더 넓은 AI 코딩 분야에 이 사례는 중요한 신호를 준다. 에이전트에 더 큰 자율성이 주어질수록 개발자의 AI 동기 직관은 점점 더 신뢰할 수 없게 되고, 정량화·추적 가능한 과정 기록만이 신뢰를 세우는 유일한 기반이 될 것이다.

주목할 방향은 도구 제공자가 이슈 소스 추적, 수정 영향면 분석, 회귀 예측 같은 기능을主动적으로 제공할 것인가다. 이것이 개발자의 주의를 'AI가 무엇을 생각하는가'에서 '코드에서 무슨 일이 일어나는가'로 옮기게 할 것이다. 이 전환이야말로 AI 보조 프로그래밍을 신기함에서 신뢰로 이끄는 핵심 한 걸음일 것이다. 그리고 처음 그 장난기 있는 질문에 대한 답은 기본적으로 '아니'다. 하루 2생 3灭의 수치, 1주일 뒤에도 이어지는 연쇄 반응, 되살아난 구 버그는 코드가 애초에 복잡했고 AI가 그 가속을 단지 보여줄 뿐이었다는 그림을 그린다. 이는 그림자 속에서 속삭이는 디지털 노동자가 아니다. 그러나 이것이 에이전트 출력을 방심해도 된다는 뜻은 아니다. 회귀를 만들고, 부산물을 남기고, 오래된 문제를 다른 방식으로 되돌리기 때문이다. 이를 'AI怕失業'으로 돌리는 것은 현재 에이전트의 동기 복잡성을 과대평가하고 소프트웨어 공학 자체의 객관적 난이도를 과소평가하는 것이다. 성숙한 사용법은 AI를 항상 경계할 직장 경쟁자가 아니라 가속된 반사를 보여주는 시스템 거울로 여기는 것이다.