AI에게 개발해줘만 말하면 코드가 위험해지는 이유

AI 코딩 도구를 쓰면 기능 구현 속도는 빨라질 수 있습니다. 버튼 하나, API 하나, 인증 기능 하나가 예전보다 훨씬 빨리 만들어집니다. 하지만 속도가 곧 좋은 개발은 아닙니다.

AI에게 “유저 인증 구현해줘”라고 말하면 코드가 나올 수 있습니다. 그런데 그 안에는 사람이 직접 정해야 할 의사결정이 아주 많이 숨어 있습니다. 문제는 그 결정을 AI가 대신 고른 뒤, 개발자가 왜 그런 선택이 들어갔는지 모른 채 넘어갈 때 생깁니다. AI 코딩의 위험은 코드가 만들어진다는 사실이 아닙니다. 책임질 수 없는 선택이 너무 빠르게 쌓인다는 데 있습니다.

“개발해줘”는 너무 많은 결정을 생략합니다

“유저 인증 구현해줘”라는 요청은 짧습니다. 하지만 실제 개발에서는 이 문장 하나로 충분하지 않습니다. 인증 기능을 만들려면 먼저 어떤 저장소를 쓸지 정해야 합니다. 세션 기반으로 갈지, 토큰 기반으로 갈지도 정해야 합니다. 비밀번호 암호화는 어떤 방식으로 할지, 토큰 갱신은 어떻게 처리할지, 동시 로그인은 허용할지 제한할지, 로그아웃은 서버에서 어떻게 무효화할지도 결정해야 합니다.

예외 처리도 필요합니다. 잘못된 비밀번호, 만료된 토큰, 권한 부족, 이미 로그인된 상태, 탈퇴한 계정 같은 상황을 어떻게 구분할지 정해야 합니다. 에러 코드는 무엇으로 줄지, 로그는 어디까지 남길지, 보안 헤더와 CORS 설정은 어떻게 할지도 이어집니다. 사람이 “개발해줘”라고만 말하면 이 모든 결정이 사라지는 것처럼 보입니다. 실제로는 사라진 것이 아니라 AI가 임의로 고르는 것입니다.

맥락이 없으면 AI는 매번 다른 선택을 할 수 있습니다

AI는 요구사항을 모르면 빈칸을 채우려 합니다. 그래서 어떤 날은 JWT 기반으로 만들고, 어떤 날은 세션 기반으로 만들 수 있습니다. 어떤 곳은 bcrypt를 쓰고, 어떤 곳은 다른 방식의 암호화 코드를 제안할 수 있습니다. 각각의 선택이 항상 틀렸다는 뜻은 아닙니다. 문제는 선택 기준이 남지 않는다는 점입니다.

왜 JWT였는지, 왜 세션이 아니었는지, 토큰 만료 시간을 왜 그렇게 잡았는지, 리프레시 토큰을 어디에 저장하는지, 장애 상황에서는 어떻게 복구하는지 설명할 수 없다면 코드는 있어도 설계는 없는 상태가 됩니다.

AI가 코드를 만들었고 앱이 돌아간다고 해서 개발이 끝난 것은 아닙니다. 그 코드를 팀이 이해할 수 있어야 하고, 다음 변경에서도 같은 기준으로 이어갈 수 있어야 합니다.

비결정적 선택은 코드 일관성을 무너뜨립니다

프로젝트 안에 작은 임의 선택이 계속 쌓이면 코드가 중구난방이 됩니다. 한 모듈은 JWT를 기준으로 인증을 처리하고, 다른 모듈은 세션을 기준으로 처리합니다. 어떤 API는 공통 예외 형식을 쓰고, 어떤 API는 문자열 메시지만 반환합니다. 어떤 곳은 상세 로그를 남기고, 어떤 곳은 실패 원인을 남기지 않습니다. 처음에는 크게 티가 나지 않습니다. 기능은 돌아가기 때문입니다.

하지만 유지보수 단계에서는 다르게 보입니다. 버그가 났을 때 어디를 따라가야 하는지 알기 어렵고, 새 기능을 추가할 때 어떤 패턴을 따라야 하는지도 흐려집니다. 리뷰어는 “왜 이렇게 했는지”를 묻지만, 작성자는 “AI가 이렇게 만들었다”는 말밖에 못 하게 됩니다. 이 상태가 되면 AI가 만든 코드는 생산성이 아니라 부채가 됩니다.

많이 만든 코드보다 리뷰 가능한 코드가 먼저입니다

AI는 코드를 빠르게 많이 만들 수 있습니다. 그래서 팀은 이전보다 더 많은 변경분을 보게 됩니다. 그런데 사람이 그 코드를 읽고, 이해하고, 검증하지 못하면 속도는 의미가 줄어듭니다. 코드가 1천 줄이든 1만 줄이든, 핵심 의사결정과 위험 지점을 사람이 파악할 수 있어야 합니다. 리뷰 가능한 코드는 단순히 줄 수가 적은 코드가 아닙니다.

왜 이 구조인지, 어떤 대안을 버렸는지, 어떤 테스트로 확인했는지, 장애가 나면 어디를 보면 되는지가 남아 있는 코드입니다. AI가 작성했더라도 이 정보가 남아 있으면 팀이 이어받을 수 있습니다. 반대로 이 정보가 없으면 코드는 빠르게 쌓이지만 소화되지 않습니다.

코드는 AI가 써도 책임은 사람이 집니다

AI 코딩 도구가 코드를 제안할 수는 있습니다. 하지만 프로덕션 데이터, 보안 사고, 장애 대응, 고객 영향은 도구가 책임지지 않습니다. 결국 배포 버튼을 누르는 사람, 리뷰를 승인하는 사람, 장애를 복구하는 사람은 개발자입니다.

그래서 AI 코딩을 쓸 때는 “얼마나 빨리 만들었는가”보다 “이 선택을 내가 설명할 수 있는가”를 먼저 봐야 합니다. 설명할 수 없는 코드는 운영 중 문제가 생겼을 때 대응하기 어렵습니다.

AI가 만든 코드도 사람이 작성한 코드와 같은 기준으로 봐야 합니다. 요구사항을 만족하는지, 기존 구조와 맞는지, 보안상 위험은 없는지, 테스트가 충분한지, 로그와 예외 처리가 운영 가능한 수준인지 확인해야 합니다.

AI에게는 맥락을 줘야 합니다

좋은 AI 코딩 요청은 단순한 명령이 아니라 개발 조건에 가깝습니다. 예를 들어 “유저 인증 구현해줘”보다 다음처럼 요청하는 편이 낫습니다.

• 기존 인증 방식은 JWT입니다.

• 비밀번호는 bcrypt 기준으로 처리합니다.

• 액세스 토큰은 짧게, 리프레시 토큰은 서버 저장소에 기록합니다.

• 실패 응답은 기존 공통 에러 포맷을 따릅니다.

• 로그에는 계정 식별자 원문을 남기지 않습니다.

• 기존 테스트 스타일에 맞춰 단위 테스트와 통합 테스트를 추가합니다.

• 구현 후 선택한 방식과 버린 대안을 짧게 문서화합니다.

이렇게 주면 AI는 빈칸을 임의로 채우는 대신 정해진 제약 안에서 움직입니다. 사람도 결과를 검토하기 쉬워집니다.

선택을 확인하고 문서화해야 합니다

AI 코딩의 결과물에는 코드만 남기면 부족합니다. 어떤 선택이 들어갔는지도 남겨야 합니다. 작업이 끝난 뒤에는 다음 질문을 확인해야 합니다.

• AI가 새로 정한 의사결정은 무엇인가요?

• 기존 프로젝트 규칙과 충돌하는 부분은 없나요?

• 보안, 데이터, 장애 대응 관점에서 위험한 부분은 없나요?

• 사람이 리뷰해야 할 핵심 파일은 어디인가요?

• 다음 작업자가 이해할 수 있는 기록이 남았나요?

이 과정을 거치면 AI가 만든 코드는 단순 산출물이 아니라 팀이 이어받을 수 있는 변경분이 됩니다.

AI 시대의 개발자는 도구를 다루는 사람입니다

AI가 코드를 쓸 수 있다는 사실은 개발자의 역할을 없애지 않습니다. 오히려 역할을 바꿉니다. 앞으로 더 필요한 사람은 막연히 “개발해줘”라고 말하는 사람이 아닙니다. 문제의 맥락을 정리하고, 요구사항을 구체화하고, AI가 고른 선택을 검증하고, 코드에 책임질 수 있는 사람입니다. AI는 도구입니다.

도구가 빠를수록 사용하는 사람의 판단은 더 선명해야 합니다. 맥락 없이 생성된 코드는 빨리 쌓이지만, 맥락과 검증이 있는 코드는 팀의 속도로 남습니다. AI에게 개발을 맡길수록 개발자는 더 많이 결정하고, 더 명확히 검증하고, 더 잘 기록해야 합니다.