AI가 버그를 찾고 수정하는 데 정말 능숙할까, 아니면 그냥 시키니까 계속 문제를 만들어내는 걸까?

가끔 앱의 설계가 잘못되어 버그가 많은 부분이 있어. AI한테 그냥 버그를 찾아서 고치라고 하면, 거기서 버그를 찾아내고는 수정하면서 코드를 좀 더 복잡하게 만들거나 새로운 버그를 도입할 수도 있지. 필요한 건 아키텍처 문제를 제대로 해결하는 거야.

보통은 좋은 에러 로깅을 갖추고, AI가 코드를 검색해서 버그를 찾게 하거나 직접 앱을 테스트해서 버그를 찾게 하는 게 좋아. 그 다음에 AI가 찾은 내용을 검토하고 어떻게 처리할지 결정하는 게 합리적이지.

버그 찾는 건 믿어도 되지만, 수정하는 과정은 단계별로 직접 확인해. 꽤 잘 고치긴 하는데 코드를 너무 많이 추가할 수도 있고, 네가 필요한 게 뭔지에 따라(나 같은 경우엔 속도) 이미 잘 작동하는 것까지 과하게 수정하거나 바꿔버릴 수도 있거든.

문제를 더 잘 설명하고, LLM이 문제를 찾을 수 있게 더 많은 세부 정보(실제로 무슨 일이 일어났는지 보여주는 성능 추적 같은 것)를 줄수록 문제의 정확한 위치를 찾는 데 더 능숙해질 거야.

Sol 6.1은 미친 듯이 과잉 엔지니어링을 할 거야. 네가 정확히 어떻게 고쳐야 하는지 말해주지 않으면 버그를 고치면서 새로운 버그 2개를 더 만들어낼 가능성이 커. 심지어 그렇게 말해줘도 6.1이나 6은 과잉 엔지니어링을 할걸. 5.6이 훨씬 훨씬 더 나아.

하지만 맞아, 계속 버그를 찾으라고 하면 계속 찾아낼 거야. 문제는 자세히 보면 그게 진짜 버그가 아닌 경우가 많다는 거지. 그냥 코드를 제대로 이해하지 못했거나, 충분히 자세히 보지 않았거나, 엉뚱한 곳을 본 거야. 다시 말하지만, 특히 6이랑 6.1은 게을러서 5.6보다 이런 문제를 더 자주 일으켜.

몇 주 동안 머지하기 전에 AI 리뷰어가 모든 작업을 검토하게 하고 나중에 로그를 세어본 적이 있어. 약 80번의 리뷰 중에 딱 한 번 커밋을 멈췄는데, 주석에 있는 오래된 링크 때문이었어. AI한테 뭔가를 찾으라고 하면, 어떻게든 뭔가를 찾아내.

복잡해질수록 이런 방식은 잘 안 먹힐 거야. 리뷰를 요청하고 그 결과를 이해하려고 해봐. 이해가 안 되면 실질적인 결과와 시나리오를 포함해서 설명을 요구해.

그 다음에 네가 능동적으로 뭘 고칠지 결정하는 거야. 확실하게 하고 싶으면 여러 모델이 리뷰하게 해. 다시 보고 싶지 않은 '허용된 엣지 케이스'가 있다면 어딘가에 적어두고. 이게 어렵다면, 네가 쓸 수 있는 최고의 모델들을 활용해.

난 일관된 내용(추가된 아키텍처 평가 같은 것)과 형식을 얻으려고 코드 리뷰 스킬을 직접 작성했어.

아, 그리고 기능/커밋/브랜치 단위로 리뷰를 받아. 앱 전체를 검사하는 건 너무 무작위적이야. 아주 작은 앱이라면 괜찮을지도 모르겠지만.

구체적이어야 해. 버그라는 건 모호한 용어거든. 전문 개발자한테 네 코드에서 버그를 찾으라고 하면 시간만 충분히 주어지면 언제든 새로운 버그를 찾아낼 수 있어.

컴파일 오류나 엔진 경고 등을 구체적으로 찾으라고 하면 유한한 응답을 받을 거야. 잠재적인 런타임 엣지 케이스를 찾으라고 하면 유한한 결과를 얻을 수도 있고, 아니면 점점 더 모호하고 관련 없는 엣지 케이스를 계속 찾아낼 수도 있지.

문제는 더 심해. 완벽하게 잘 짠 코드 조각을 스택 오버플로우에 올려서 어떻게 개선할지 물어보면, 누가 최고의 해결책인지 서로 싸우는 100개의 댓글이 달릴걸.

버그 찾는 건 잘해. 그리고 "이런 문제를 못 본 거 아니야?"라고 물어보면 더 잘하더라고.

그 루프는 네가 시킨 대로 하고 있는 거야. 실패 사례에 대한 관찰 없이 "버그 찾아서 고쳐"라고 하면 끝도 없이 탐색하게 되니까, 다음 패스에서는 뭐라도 내놓으려고 점점 더 말도 안 되는 문제를 지어내는 거지. 진짜 버그는 입력값, 기대 결과, 실제 결과라는 세 가지 요소가 있어야 해. 모델이 네가 재현할 수 있는 실행 결과로부터 이 세 가지를 작성하지 못한다면, 그건 그냥 스타일 지적이거나 가상의 문제일 뿐이야. 그걸 적용하면 잘 쓰던 뷰어 앱이 갑자기 이상하게 작동하기 시작하는 거지.

매시간 자동 실행하는 건 당장 멈춰. null이 들어올 리가 없는데 'null일 수도 있음' 같은 소리만 반복하면 거기서 끝내야 해. 그 이후로는 코드 고정하고 실제로 앱 쓰다가 버그 터지면 그때 고쳐. 굳이 스케줄링을 하고 싶다면, 아까 말한 세 가지 요소랑 현재 코드에서 실패하는 테스트 케이스를 보고하게 만들어. 자동 커밋은 절대 하지 말고. 마지막에 안전 제한 걸린 건 프롬프트가 앱을 공격하는 방향으로 변질됐기 때문인데, 그건 네가 앱 쓰면서 겪을 버그랑은 전혀 다른 작업이야.

버그는 있어.

AI는 변경 사항이 생길 때마다 뒤처리를 제대로 안 해서 버그를 만드는 데 아주 능숙해.