AI 코딩 도구를 실무에 도입해 본 개발사의 솔직한 평가

AI 코딩 도구에 대한 이야기는 양극단으로 갈립니다. "개발자가 필요 없어진다"는 쪽과 "실무에선 못 쓴다"는 쪽. 저희는 실제 프로젝트에 도구를 붙여 쓰면서 두 쪽 모두 과장이라는 결론에 도달했습니다. 이 글은 그 중간 지대의 기록입니다.

확실히 잘 통하는 곳

패턴이 분명한 코드. 목록 화면, 등록·수정 폼, API 엔드포인트처럼 프로젝트마다 반복되는 구조는 AI가 가장 잘하는 영역입니다. 기존 코드의 관례를 보여 주고 같은 방식으로 만들게 하면, 사람이 직접 칠 때보다 빠르고 오타도 적습니다.

테스트 코드 초안. 테스트는 중요하지만 밀리기 쉬운 작업의 대표였습니다. AI 는 함수 하나를 주면 정상 케이스와 경계 케이스 초안을 순식간에 뽑아 줍니다. 그대로 쓰기보다 "빠뜨린 케이스를 사람이 추가하는" 출발점으로서 가치가 큽니다.

낯선 기술의 탐색. 처음 다루는 라이브러리나 오래된 시스템의 설정 파일을 읽어야 할 때, AI 는 훌륭한 안내자입니다. 검색으로 30분 걸리던 "이 옵션이 뭐지"가 대화 몇 번으로 끝납니다.

문서화. 코드 설명, 변경 이력 정리, 운영 매뉴얼 초안. 문서가 부실한 프로젝트는 이제 시간 탓을 할 수 없게 됐습니다.

기대만큼 안 통하는 곳

우리 회사만의 맥락. AI 는 세상의 평균적인 코드를 학습했지, 이 프로젝트가 3년 동안 쌓아 온 결정들을 알지 못합니다. 왜 이 테이블은 정규화를 포기했는지, 왜 이 API 는 이상한 응답 형식을 유지하는지 - 이런 맥락을 모른 채 만든 코드는 그럴듯하지만 시스템과 어긋납니다.

도메인 규칙. 정산 마감일이 공휴일이면 어떻게 되는지, 요양 급여 청구에서 어떤 항목이 병산 불가인지 같은 업무 규칙은 코드 문제가 아니라 지식 문제입니다. 이 지식이 없는 AI 의 코드는 컴파일은 되지만 업무적으로 틀립니다.

아키텍처 판단. "이 기능을 어디에 두어야 3년 뒤에도 관리가 되는가"는 AI 가 답을 주는 척은 하지만, 그 답의 책임은 지지 않는 질문입니다.

예상 못 했던 부작용

가장 조심해야 할 것은 그럴듯한 오답입니다. 사람의 실수는 대개 티가 나는데, AI 의 실수는 자신감 있고 매끈합니다. 리뷰하는 눈이 낮으면 그대로 통과됩니다. 그래서 AI 도입 후 코드 리뷰의 부담은 줄어든 것이 아니라 오히려 늘었습니다 - 검토해야 할 코드의 총량이 늘었기 때문입니다.

주니어 개발자의 성장 문제도 실재합니다. 직접 부딪히며 배울 기회가 도구에 흡수되는 만큼, 의식적으로 "왜 이 코드가 맞는지 설명하게 하는" 과정을 넣지 않으면 실력이 고이지 않습니다.

우리가 정한 운영 원칙

정리하면 세 가지입니다. 첫째, 생성은 자유, 병합은 리뷰 통과 후. AI 가 쓴 코드라는 이유로 검증을 면제받는 일은 없습니다. 둘째, 맥락을 먼저 준다. 프로젝트의 규칙과 기존 코드를 보여 주고 시작하면 결과물의 품질이 완전히 달라집니다. 셋째, 판단이 필요한 일에는 이름을 남긴다. 설계 결정은 사람이 내리고 기록합니다. 문제가 생겼을 때 "AI 가 그랬다"는 답이 되지 않기 때문입니다.

AI 시대의 개발 전반에 대한 관점은 대표 글 AI 시대의 SI 개발 - 무엇이 바뀌고 무엇이 남는가에서 이어집니다.