하나의 버그를 고치려다 AI가 만들어낸 버그들 때문에 일주일을 허비했습니다

나는 에이전트(agent)에게 한 가지를 고쳐달라고 요청했습니다.

작은 버그였고, 하나의 함수였으며, 범위(scope)가 명확했습니다. 에이전트는 1분도 채 되지 않아 깔끔한 변경 사항과 자신감 넘치는 요약과 함께 결과물을 가져왔습니다. 버그는 사라졌습니다. 나는 다음 작업으로 넘어갔습니다.

이틀 후, 몇 주 동안 건드리지 않았던 기능 하나가 작동을 멈췄습니다.

그 원인을 추적하는 데 거의 하루를 다 썼습니다. 원인은 바로 그 동일한 변경 사항이었습니다. 내가 지목한 하나의 함수를 고치는 동안, 에이전트는 그 주변의 다른 네 가지 사항을 조용히 수정했고, 그 수정 사항 중 하나가 아무도 보고 있지 않던 경로(path)를 망가뜨린 것이었습니다.

다음은 내가 댓글에서도 고수할 의견입니다.

코드를 타이핑하는 것은 소프트웨어 개발에서 결코 비용이 많이 드는 부분이 아니었습니다. AI는 저렴한 부분을 무료로 만들었고, 가장 비용이 많이 드는 부분 전체를 나에게 남겨두었습니다.

변경 사항을 작성하는 것은 저렴합니다. 그 변경 사항이 정확하다는 것을 아는 것, 그리고 당신이 지켜보고 있지 않던 무언가를 조용히 망가뜨리지 않았다는 것을 아는 것이 비용이 발생하는 부분입니다.

수년 동안 이 두 가지 비용은 함께 움직였습니다. 당신이 코드를 작성했다면, 작성하는 동안 최소한 주변 로직을 머릿속에 담고 있었을 것입니다. 작성하는 것은 곧 추론(reasoning)이기도 했습니다. 당신은 한 번의 과정에서 두 가지 비용을 모두 지불했습니다.

에이전트는 이 둘을 분리합니다.

에이전트는 작성 비용을 몇 초 만에 지불합니다. 하지만 추론 비용은 전혀 지불하지 않습니다. 왜냐하면 에이전트는 볼 수 없는 것을 볼 수 없기 때문입니다. 에이전트는 당신이 명시한 작업에 최적화됩니다. 당신이 명시하지 않은 변경 사항의 폭발 반경(blast radius)에 대한 실제 모델을 가지고 있지 않습니다.

따라서 에이전트는 당신이 지목한 버그를 고치고, 그 과정에서 주변 요소들을 건드리지만, 그 요소들 중 어떤 것이 다른 세 가지 기능에 조용히 의존하고 있는지는 전혀 알지 못합니다.

그것이 함정이며, 그 함정은 속도의 모습을 하고 있습니다.

모든 것이 작아 보입니다. 짧은 디프(diff). 자신감 넘치는 요약. 작동하는 데모(demo). 왜냐하면 그 데모는 당신이 이미 생각하고 있던 경로를 실행하기 때문입니다. 당신이 빠르다고 느끼게 만드는 모든 신호가 존재합니다.

결여된 것은 예전에 공짜로 따라왔던 부분입니다. 시스템의 나머지 부분이 무사히 살아남았다는 증명 말입니다.

파손(Breakage)은 diff(차이점)에 나타나지 않습니다. 그것은 두 파일 떨어진 곳에서, 혹은 당신이 존재를 잊어버린 기능에서, 아니면 다른 코드 경로가 마침내 실행되는 다음 주 화요일에 표면 위로 드러납니다. 그때가 되면 원인과 증상 사이의 거리는 엄청나게 멀어져 있으며, 당신은 당신이 변경한 것과 전혀 관련 없어 보이는 무언가를 디버깅(debugging)하게 됩니다.

저는 이 패턴의 형태를 이름 붙일 수 있을 정도로 충분히 많이 목격해 왔습니다.

당신은 한 가지를 고칩니다.

당신이 전혀 건드리지 않은 무언가가 망가집니다.

당신은 에이전트(agent)에게 그것을 고치라고 요청합니다.

에이전트는 확신에 차서 원래 수정 사항의 일부를 되돌려 버리고, 이제 당신에게는 두 개의 망가진 것과 두 가지 모두 해결했다고 믿는 모델이 남게 됩니다.

그 루프(loop)가 바로 비용입니다. 타이핑이 아니라, 루프 그 자체가 비용입니다.

한 가지 관점의 전환이 실제로 저에게 도움이 되었는데, 그것은 작고 화려하지 않은 것이었습니다.

AI는 저를 더 빠르게 만들어주지 않았습니다. 그것은 제 업무를 작성(writing)에서 검증(verifying)으로 옮겨 놓았습니다. 그리고 검증은 작업의 더 어려운 절반이며, 예전에는 부분적으로 공짜로 얻었던, 이제는 의도적으로 수행해야만 하는 절반입니다.

그래서 저는 도구가 아니라 저의 태도를 바꾸었습니다.

에이전트가 만드는 모든 변경 사항은 주변 동작이 여전히 살아있음이 증명될 때까지 유죄로 간주됩니다. 변경 사항이 존재한다는 것이 그것이 올바르다는 증거는 아닙니다. 해피 패스(happy path)에 대한 통과하는 데모가 나머지 부분이 살아남았다는 증거는 아닙니다.

저는 이제 diff가 아니라 폭발 반경(blast radius)을 관찰합니다. 이 변경 사항이 무엇을 건드릴 수 있는가. 그것이 수정한 것에 무엇이 의존하고 있는가. 이것들을 믿기 전에 내가 다시 실행해 보아야 할, 예전에 작동했던 것은 무엇인가.

실제로 테스트하지 않은, 녹색(pass)으로 보이는 변경 사항은 요란한 충돌(crash)보다 더 위험합니다. 충돌은 눈에 띕니다. 조용하고, 그럴듯하며, 확신에 찬 변경 사항이 프로덕션(production)에 도달합니다. 왜냐하면 아무도 이미 완료된 것처럼 보이는 작업을 다시 확인하지 않기 때문입니다.

이 모든 것이 에이전트 사용을 반대하는 것은 아닙니다. 저도 매일 사용합니다. 제 요점은 더 좁으며, 실제 작업이 어디로 이동했는지, 그리고 얼마나 적은 사람들이 그 이동을 알아차리는지에 관한 것입니다.

생성(Generation) 비용은 저렴해졌습니다. 하지만 판단(Judgment) 비용은 그렇지 않았습니다. 에이전트(Agent)는 몇 초 만에 변경 사항을 전달할 것이고, 대부분의 경우 그것은 정확할 것입니다. 하지만 그것이 틀렸을 때 발생하는 비용은 당신이 눈치채지 못하는 곳에서 지불됩니다. 즉, 당신의 하루 중 가장 저렴해 보이는 부분이 사실은 가장 비용이 많이 드는 부분이라는 뜻입니다.

지쳐버리는 팀들은 속도가 빠르다고 느끼며 차이점(diff)을 배포해버린 팀들입니다.

정신 건강을 유지하는 팀들은 완료된 것처럼 보이는 작업에 대해 의심하는 법을 배웠고, 절약한 시간을 에이전트가 결코 대신 답해줄 수 없는 단 하나의 질문에 사용하는 법을 배웠습니다.

"그 외의 나머지 부분은 무사한가?"

당신의 차례

AI는 분명히 고쳤다고 장담했지만, 당신에게는 무엇이 망가졌었나요?

이 내용이 유용했다면

저는 성공과 정체(freeze)를 모두 포함한 과정을 공개적으로 진행하며, 주로 LinkedIn과 YouTube를 통해 공유합니다. 공개적으로 빌드하는 실제 과정이 당신에게 유용하다면, 그곳에서 확인하실 수 있습니다. LinkedIn, YouTube 및 X는 Mirza Iqbal이며, 작업물은 next8n.com에서 볼 수 있습니다.