코드 다 짰다, 이제 AI한테 리뷰 맡기면 되겠다 — 저도 그렇게 생각했어요.
Discord 봇 프로젝트 하나 마무리하면서 AI 코드리뷰를 돌렸는데, 결과가 꽤 충격적이었어요. 버그를 고쳐줬는데, 그 고침이 새 버그를 만들고, 그 버그를 또 고치고, 또 새 버그가 나오고… 이게 4라운드 동안 반복됐거든요. 그것도 전부 try/except 블록 하나를 둘러싸고요.
오늘은 그 경험을 날것 그대로 풀어볼게요. AI 코드리뷰가 나쁘다는 게 아니라, 무지성으로 믿으면 어떤 일이 생기는지 이야기하고 싶어요.
발단: Discord 봇에 AI 코드리뷰를 붙였더니
제가 만들던 건 개인 블로그 포스팅을 자동화하는 Discord 봇이었어요. 글 업로드하면 봇이 받아서 처리하고, 로그 남기고, 완료 메시지 보내주는 구조였죠.
기능은 다 동작했어요. 근데 “혹시 놓친 게 있을까?” 싶어서 AI 코드리뷰를 돌렸어요. 취준생 입장에서 코드 품질도 신경 써야 하니까요.
첫 리뷰 결과가 나왔고, 저는 별 생각 없이 “오, 맞네” 하면서 수정했어요. 그리고 다시 리뷰를 돌렸죠. 이게 실수의 시작이었어요.
라운드 2: 첫 번째 수정, 그리고 새 문제
AI가 라운드 2에서 찾아낸 건 이거였어요.
ctx.send("업로드 중...")이try블록 안에 있어서, Discord에서 에러가 나면 실제 업로드는 안 됐는데 fail 처리가 돼버린다.
솔직히 들었을 때 “맞는 말이네” 싶었어요. 그래서 ctx.send를 try 블록 밖으로 꺼냈어요. 코드가 좀 더 깔끔해진 느낌도 났고요.
여기까지는 괜찮았어요. 문제는 이 수정이 새로운 순서 문제를 만들어냈다는 거예요.
→ 이 라운드의 교훈: 수정 하나가 끝이 아니라 시작일 수 있어요.
라운드 3: 수정했더니 또 문제가 생겼다
라운드 3에서 AI가 또 뭔가를 찾아냈어요.
finish_run("success")가ctx.send보다 먼저 실행되고 있다. Discord 에러가 나면 사용자는 모르는데 success로 처리된다. 재시도하면 중복 업로드 위험 있다.
이것도 들어보면 맞는 말이에요. “사용자가 모르게 success 처리된다”는 건 분명히 이상한 동작이니까요. 저는 또 수정했어요. 실행 순서를 바꿨죠.
근데 이때부터 뭔가 이상하다는 느낌이 살짝 들기 시작했어요. 계속 비슷한 영역에서 문제가 나오고 있었거든요. try/except 블록이랑 실행 순서 주변에서만 계속 뱅뱅 돌고 있는 느낌이랄까요.
→ 이 라운드의 교훈: 같은 자리에서 문제가 계속 나온다면, 근본 원인을 봐야 해요.
라운드 4: 또? 진짜로 또?
라운드 4에서 AI가 찾아낸 건 이거였어요.
log_agent와log_post가 같은try블록 안에 있다.log_agent가 실패하면log_post가 아예 실행 안 된다.
이번엔 저도 멈칫했어요. “어… 이게 맞긴 한데, 이게 내 개인 블로그봇에서 진짜로 문제가 되는 상황이 얼마나 자주 생기지?”라는 생각이 든 거예요.
AI는 해결책도 같이 제시했어요. log_agent와 log_post를 독립적인 try 블록으로 분리하면 된다고요. 틀린 말은 아니에요. 근데 그렇게 했다가 또 뭔가 새로운 엣지케이스가 나올 것 같은 예감이 들었어요.
실제로 그 예감이 맞았어요. 수정하고 나서 AI를 또 돌렸더니, 이번엔 분리된 try 블록들 사이의 에러 처리 일관성 문제를 지적하더라고요.
→ 이 라운드의 교훈: AI는 끝없이 엣지케이스를 찾아요. 멈추는 건 사람이 해야 해요.
왜 이런 일이 생겼나: 근본 원인은 따로 있었다
4라운드 돌고 나서 코드를 처음부터 다시 봤어요. 그랬더니 패턴이 보이더라고요.
관계없는 작업들이 하나의 try 블록에 묶여 있었던 거예요.
메시지 보내기, 업로드 완료 처리, 로그 남기기 — 이 세 가지는 성격이 달라요. 하나가 실패했을 때 나머지에 어떤 영향을 줘야 하는지도 다르고요. 근데 이걸 그냥 한 덩어리로 묶어놨으니까, AI가 매번 “이 순서 이상하다”, “이 범위 이상하다”를 지적하는 루프에 빠진 거예요.
AI 코드리뷰는 이걸 직접 말해주지 않았어요. 매 라운드마다 “이전 수정이 만들어낸 새 엣지케이스”를 찾아서 고쳐줬지만, “애초에 왜 이런 구조가 됐냐”는 한 번도 짚지 않았어요.
여러분도 이런 경험 있으시죠? 뭔가 계속 고치는데 근본적으로 나아지는 느낌이 없는 그 느낌이요.
→ AI는 현재 코드 상태에서 문제를 찾아요. 설계 자체가 문제인지는 잘 못 봐요.
AI 코드리뷰가 못 하는 것: “이게 실제로 중요한가”
이 경험에서 제가 배운 게 딱 하나 있어요.
AI 코드리뷰는 엣지케이스를 정말 잘 찾아요. 솔직히 저 혼자였으면 log_agent 실패 시 log_post 미실행 케이스는 못 찾았을 거예요.
근데 AI가 못 하는 게 있어요. “이게 이 프로젝트 규모에서 실제로 중요한가”를 판단하는 거예요.
제 봇은 개인 블로그 자동화예요. 하루에 몇 번 쓰지도 않아요. log_agent가 가끔 실패한다고 해서 log_post가 날아가도… 솔직히 그렇게 치명적이지 않아요. 로그 하나 빠지는 거잖아요.
근데 AI는 그걸 몰라요. 코드만 보고, 코드에서 발생할 수 있는 모든 케이스를 동등하게 위험하다고 봐요. 그래서 “10만 명이 쓰는 서비스에서 절대 일어나면 안 되는 버그”랑 “개인 프로젝트에서 1년에 한 번 날지도 모르는 엣지케이스”를 같은 무게로 다뤄요.
라운드 1~2에서 사람이 “잠깐, 이게 내 프로젝트에서 진짜 문제가 되나?”를 판단했더라면 라운드 3, 4는 없었을 거예요.
→ AI는 무엇이 문제인지는 찾아요. 얼마나 중요한 문제인지는 사람이 판단해야 해요.
그래서 지금은 이렇게 쓰고 있어요
이 경험 이후로 AI 코드리뷰 쓰는 방식을 바꿨어요.
첫째, 리뷰 결과를 받으면 바로 수정하지 않아요. 일단 다 읽고, “이게 내 프로젝트에서 실제로 터질 수 있는 상황인가?”를 먼저 생각해요.
둘째, 같은 영역에서 두 번 이상 지적이 나오면 수정보다 설계를 먼저 봐요. 이번처럼 try/except 주변에서 계속 문제가 나오면, 그 블록 자체의 설계가 잘못된 거일 가능성이 높아요.
셋째, “이 수정이 새 문제를 만들 수 있나”를 제가 직접 생각해요. AI는 현재 코드 기준으로만 봐요. 수정 후 상태를 예상하는 건 사람이 해야 해요.
마치며: AI는 도구예요, 심판이 아니라
AI 코드리뷰 쓰지 말라는 게 아니에요. 저도 계속 쓸 거고, 실제로 도움이 많이 돼요.
근데 비전공자 취준생으로서 솔직히 말하면, 처음엔 AI가 뭔가 지적하면 무조건 맞는 말인 줄 알았어요. “나보다 AI가 코드를 더 잘 아는데” 싶었거든요.
근데 AI는 내 프로젝트가 뭔지 몰라요. 누가 쓰는지, 얼마나 자주 쓰는지, 어디까지 완성도가 필요한지를 몰라요. 그걸 아는 건 저뿐이에요.
AI 코드리뷰는 “이런 케이스도 있어요”를 알려주는 도구예요. “이걸 반드시 고쳐야 해요”를 판단하는 건 결국 저예요.
4라운드 뱅뱅 돌고 나서 배운 거, 이게 다예요.