AI에 코드 의존도가 높아질 때 생기는 5가지 부작용
2026.04.25"이거 내가 짠 코드 맞나?"
지난주에 6개월 전에 짠 함수에 버그가 났다. 코드를 열어보니 내가 짠 게 아니었다. 정확히는 AI가 짠 걸 내가 OK 누른 코드였다. 그래서 어떻게 동작하는지 모르고 있었다.
버그는 결국 30분 만에 고쳤다. 다만 그 30분 동안 내가 한 일은 "AI에게 코드 분석 시키고, 그 분석을 검증하고, 수정 제안 받고, 또 검증"이었다. 직접 코드를 읽고 디버깅하는 시간이 거의 없었다.
이게 AI 의존의 부작용이라는 걸 그날 알았다. 1년 가까이 AI 코딩 도구를 쓰면서 누적된 변화 5가지를 정리한다. 부정적인 글은 아니다. 다만 알고 있어야 할 변화들이다.
부작용 1: 디버깅 능력의 약화
가장 명확한 부작용. 디버깅을 AI에게 맡기는 횟수가 늘면서 나 혼자 디버깅하는 근육이 약해졌다.
예전에는 에러 로그를 보면 "이건 race condition이겠네", "여기 null 체크가 빠졌겠네" 같은 직관이 빠르게 들었다. 지금은 같은 로그를 봐도 일단 AI에게 보내고 싶은 충동이 든다.
어떻게 다루는가
일주일에 한 번씩 AI 없이 디버깅한다. 의식적으로. 작은 버그라도 일부러 AI를 끄고 추적한다. 처음에는 답답하다. 1주일만 지나면 다시 직관이 살아난다.
또 한 가지: AI에게 디버깅을 시킬 때도 결과만 받지 않고 과정을 같이 본다. "이 변수를 추적하니 이런 패턴이 나왔다"라는 추론 과정을 따라가면, 디버깅 절차 자체를 학습한다.
부작용 2: 검증 부담이 늘어난다
AI가 코드를 빠르게 만든다. 1초당 토큰이 수십 개씩 쏟아진다. 문제는 그 코드를 사람이 검증하는 속도는 그대로라는 것이다.
생산되는 코드량과 검증할 수 있는 코드량의 격차가 점점 벌어진다. 결국 검증을 대충하게 된다. "동작하면 됐다"로 합리화한다.
어떻게 다루는가
생산량을 의식적으로 줄인다. 큰 작업을 한 번에 시키지 말고 작은 단위로 끊는다. Plan Mode가 이 자리에 답이다. 코드를 받기 전에 계획을 검증하면, 코드 자체의 검증 부담이 가벼워진다.
또: 큰 PR은 ultrareview 같은 자동 리뷰를 한 번 더 돌린다. 검증 부담을 사람만 지지 않는다.
부작용 3: 코드 이해도 하락
이 글의 시작 일화 같은 케이스. 6개월 전 AI가 짠 코드를 내가 이해 못 했다.
이건 단기 효율을 위해 장기 비용을 낸 거다. 빨리 짜고 빨리 OK 누른 결과, 그 코드의 maintainer로서의 능력이 떨어진다.
어떻게 다루는가
AI가 코드를 만들면 그 자리에서 두 가지를 한다.
- "왜 이렇게 짰지?"를 묻는다. AI 페어 프로그래밍 실수 글에서 다뤘듯, 이유를 안 묻는 게 가장 비싼 실수다.
- 핵심 의도를 한 줄 코멘트나 커밋 메시지로 남긴다. 미래의 내가 다시 만질 때 단서가 된다.
이 두 단계만 추가해도 코드 이해도가 유지된다. 시간은 30초 더 든다. 6개월 후에 30분을 아낀다.
부작용 4: 라이브러리/언어 기능 무지
AI가 적절한 라이브러리를 자동으로 추천하니, 내가 직접 라이브러리 생태계를 탐색하는 시간이 줄었다. 결과적으로 내가 쓰는 라이브러리에 대해 점점 모른다.
예: 한 달 전에 AI가 추천한 form 라이브러리를 쓰고 있는데, 그 라이브러리의 다른 기능 80%를 모른다. AI가 필요할 때만 그 부분을 알려주니까 굳이 안 본다.
어떻게 다루는가
한 달에 한 번 "쓰고 있는 라이브러리 정독" 시간을 둔다. 30분~1시간. 자주 쓰는 라이브러리의 공식 문서를 처음부터 끝까지 훑는다.
빠르진 않다. 그래도 그 시간이 직관을 만든다. "이 작업에는 라이브러리 X의 Y 기능이 어울리겠다"는 직관은 책 한 권보다 깊이 있는 한 시간 정독에서 나온다.
부작용 5: 코드 리뷰 피로
AI가 짠 코드를 사람이 리뷰하는 게 점점 힘들어진다.
- 양이 많다
- 패턴이 일관적이지 않다 (모델/세션마다 약간씩 다른 스타일)
- 명백한 실수는 적지만, 미묘한 함정은 많다
리뷰어가 정신적으로 더 피곤해진다. 같은 1,000줄을 봐도 사람이 짠 코드 리뷰보다 AI 코드 리뷰가 더 무겁다.
어떻게 다루는가
리뷰 부담을 분산한다. 두 가지 방법.
- AI가 짠 코드라도 PR 만들기 전에 작성자가 한 번 더 검토한다. 사람의 손이 한 번 가서 "내가 짠 것"으로 만든다.
- AI 자동 리뷰를 사람 리뷰 앞에 둔다. 명백한 이슈는 AI가 거른 다음 사람이 본다.
이 두 가지로 사람 리뷰어의 피로가 절반 가까이 줄었다.
부작용 정리
5가지 부작용을 한 줄씩.
- 디버깅 능력 약화 → 주 1회 AI 없이 디버깅
- 검증 부담 증가 → 작업 단위를 작게, Plan Mode 적극 사용
- 코드 이해도 하락 → 코드를 받을 때 "왜?"를 묻기
- 라이브러리 무지 → 월 1회 라이브러리 문서 정독
- 리뷰 피로 → 작성자 자기 검토 + AI 자동 리뷰 추가
그래서 AI를 그만 써야 하나
아니다. 부작용이 있다고 해서 도구를 버리는 건 과잉 반응이다. 부작용을 알고 의식적으로 다루는 것이 답이다.
같은 도구를 어떻게 쓰느냐에 따라 효과가 갈린다. AI 코딩 도구를 잘 쓰는 사람은 위 5가지 부작용을 의식하고 우회한다. 잘못 쓰는 사람은 부작용을 모른 채 누적시킨다.
내 결론은 AI는 가속기지 자율주행이 아니다. 운전대는 사람이 잡는다. 가속만 AI에게 맡겼는데 운전대까지 놓으면 사고가 난다.
1년 후의 내가 다시 본다면
이 글을 1년 후의 내가 다시 본다면 어떤 부분이 추가될까. 추측해본다.
- 새로운 부작용 — 아직 안 보이는 어떤 패턴
- 위 5가지 중 일부는 AI 도구 발전으로 자동 해결됐을 가능성
- "AI 시대의 코딩 능력"에 대한 정의가 변했을 가능성
그래서 이 회고는 매년 한 번씩 갱신할 가치가 있다. 도구가 변하면 부작용도 변한다.
정리
AI 코딩 도구는 강력하다. 그래서 부작용도 명확하다. 사람이 일하는 방식이 변하면 잘 해야 할 일도 변한다.
지금 잘 해야 하는 일은 코드를 빠르게 짜는 게 아니다. AI가 짠 코드를 잘 검증하고, 의도를 기록하고, 디버깅 직관을 유지하는 것이다. 도구는 빨라졌지만 이 세 가지 능력은 여전히 사람의 일이다.
5가지 부작용 중 어느 하나라도 자기 모습 같다면, 한 번쯤 의식적으로 다뤄볼 가치가 있다. 부작용은 한 달 만에는 안 드러나지만, 1년 누적되면 분명히 코드 품질에 나타난다.