AI로 급하게 쌓아 올린 사내 시스템, '고칠까 다시 쓸까' 고민 커져

중국 개발자 커뮤니티 V2EX에 AI 코딩으로 만든 사내 시스템을 계속 고쳐야 할지, 처음부터 다시 써야 할지를 묻는 글이 올라와 댓글 67개가 달렸다. 작성자는 지난해 부품 공급업체 매장 시스템을 맡아 일정에 쫓겨 AI 코딩을 대량으로 활용해 출시했는데, 이후 크고 작은 문제가 끊이지 않아 지금은 손대기 어려운 상태에 가까워졌다고 설명한다.

구체적으로는 코드 리뷰를 제대로 하지 못한 채 배포한 탓에 수정에 드는 인력 비용이 커졌고, AI에게 고치게 하면 토큰 소모가 심한 데다 한 곳을 바꾸면 다른 기능이 함께 흔들린다. AI가 요구사항에 없던 예외 상황 방어 로직을 습관처럼 덧붙여 복잡도만 높이는 점도 문제로 꼽혔다. 작성자는 지난해보다 모델 성능이 크게 올라간 만큼 AI로 처음부터 다시 쓰는 편이 나은지, 아니면 기존 코드를 계속 덧대는 편이 나은지 판단을 구했다.

이 프로젝트는 애초에 보조 시스템 성격이었고 개발도 적당히 마무리하는 분위기였다. 그런데 현장에서 실제로 쓰이면서 주력 시스템으로 자리 잡았고, 그때부터 품질 부채가 부담으로 돌아왔다. 댓글에서는 AI 도구가 코드 부패 속도를 앞당겼을 뿐, 리뷰와 테스트 없이 굴러간 코드는 원래 그렇게 된다는 지적도 나왔다.

가장 많이 나온 조언은 재작성 여부를 정하기 전에 시스템을 문서화하라는 것이다. AI에게 프로젝트 전체를 읽히고 구조화된 위키 형태의 문서를 만들게 하면 초기 토큰 소모는 크지만 이후 수정 작업이 훨씬 수월해진다는 경험담이 이어졌다. 기능 단위로 폴더를 나누고 마크다운 문서를 상대 경로로 연결하는 방식이 예로 제시됐다. OpenAI의 하네스 엔지니어링 문서와 Codex 실행 계획 예시, AGENTS.md·feature_list·program.md 같은 규약 파일을 참고하라는 조언도 있었다.

품질 절차를 되살리라는 요구도 많았다. 제품 요구사항 문서를 git으로 관리하고, 그 문서를 기준으로 통합 테스트를 만들고, 모듈별로 리뷰를 반복하라는 식이다. Claude Code의 simplify·review 기능이나 별도 리뷰 도구를 돌려 코드를 검증하라는 제안도 나왔다. 비용 감각을 공유한 댓글에서는 첫 버전은 1000달러 안팎의 토큰으로 끝났지만 이후 버그 하나를 찾는 데만 100달러 이상이 들고 수정 기간도 예측하기 어려워졌다는 사례가 언급됐다.

재작성 쪽 의견은 조건부다. 데이터베이스 구조가 초기에 충분히 검토돼 지금까지 크게 바뀌지 않았다면 코드를 다시 쓰는 선택이 현실적이라는 것이다. 반대로 사람이 리팩터링으로 정리하지 못하는 코드는 AI로 다시 써도 비슷한 결과가 나온다는 반론도 만만치 않다. 모델 버전이 올라갈 때마다 이전 버전이 만든 코드를 새 모델로 다시 쓰는 일이 반복되면 재작성 자체가 새로운 부채가 될 수 있다는 경고도 있었다.

정리하면 이 사례의 교훈은 AI 코딩 자체가 아니라 그 앞뒤의 절차에 있다. 설계와 데이터 모델은 사람이 잡고, 리뷰·테스트·문서화를 AI 작업 흐름에 묶어 두지 않으면 생산성 이득은 유지보수 비용으로 되돌아온다. 다만 이 글은 한 개발자의 경험담과 댓글 반응을 정리한 것으로, 어떤 선택이 정답인지는 프로젝트 규모와 남은 수명에 따라 달라진다.