강의

멘토링

로드맵

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

딩코딩코

2026. 06. 01. 17:25

수정됨

AI에게 "유저 인증 만들어주세요"라고 요청하면 코드가 나옵니다. 로그인 API, 토큰 발급, 비밀번호 검증까지 빠르게 생길 수 있습니다. 문제는 그 요청 안에 숨은 결정이 너무 많다는 점입니다. 세션을 쓸지 JWT를 쓸지, 토큰 만료는 어떻게 할지, 로그아웃은 어떻게 처리할지, 실패 로그는 어디까지 남길지 모두 사람이 책임져야 할 선택입니다.

짧은 요청은 의사결정을 숨깁니다

"개발해주세요"라는 말은 편하지만 개발 요구사항으로는 부족합니다. 실제 기능 하나에는 데이터 모델, 예외 처리, 보안 정책, 운영 로그, 테스트 범위가 따라옵니다. 이 빈칸을 사람이 채우지 않으면 AI가 채웁니다. 어떤 선택은 괜찮을 수 있지만, 선택 기준이 남지 않으면 다음 수정 때 문제가 됩니다.

같은 프로젝트 안에서 어떤 기능은 JWT, 다른 기능은 세션, 또 다른 기능은 임시 토큰으로 만들어지면 일관성이 무너집니다. 리뷰어는 코드보다 숨은 결정을 추적하느라 시간을 씁니다.

짧은 구현 요청 뒤에 숨은 결정 카드가 쏟아지는 2컷 만화

장면 요약: 짧은 요청은 짧은 일이 아니라 숨은 결정을 접어둔 것입니다.

AI 코드의 속도보다 소화 가능성이 중요합니다

AI가 만든 코드가 많아질수록 사람이 이해할 양도 늘어납니다. 빨리 만들어진 코드라도 팀이 읽고 고칠 수 없다면 속도는 부채가 됩니다. 특히 인증, 결제, 권한, 데이터 삭제처럼 위험한 영역에서는 "돌아갑니다"가 완료 기준이 될 수 없습니다. 어떤 위협 모델을 봤는지, 어떤 예외를 막았는지, 어떤 테스트로 확인했는지 남겨야 합니다.

AI 코딩의 핵심은 코드를 더 많이 받는 것이 아니라, 사람이 책임질 수 있는 선택만 코드로 확정하는 것입니다.

요청을 이렇게 바꿔야 합니다

막연한 요청은 작업 지시서로 바꾸는 편이 좋습니다.

Before

  • 유저 인증 개발해주세요.

After

  • 세션 기반 인증을 사용합니다.

  • 비밀번호는 bcrypt로 해시합니다.

  • 로그인 실패는 공통 에러 형식으로 반환합니다.

  • 로그아웃 시 서버 세션을 무효화합니다.

  • 인증 API에는 성공, 실패, 만료 테스트를 추가합니다.

  • 구현 뒤 선택한 보안 기준과 남은 리스크를 문서화합니다.

막연한 요청이 검토 가능한 기준 카드로 바뀌는 2컷 만화

장면 요약: AI에게 줄 것은 긴 소원이 아니라 검토할 기준입니다.

이 정도만 적어도 AI가 임의로 채울 공간이 줄어듭니다. 리뷰할 기준도 생깁니다.

코드가 나온 뒤 반드시 확인할 것

AI가 구현을 끝냈다고 말하면 바로 병합하지 말고, 먼저 숨은 선택 목록을 뽑게 해야 합니다. 어떤 라이브러리를 골랐는지, 어떤 기본값을 사용했는지, 어떤 예외를 처리하지 않았는지 확인해야 합니다.

그다음 사람이 봐야 할 것은 테스트와 운영 흔적입니다. 실패 케이스 테스트가 있는지, 보안 관련 로그가 과하게 남지 않는지, 장애가 났을 때 원인을 추적할 수 있는지 봐야 합니다. AI 코딩은 생성 속도보다 사후 검토 루프가 붙어 있을 때 실무에 가까워집니다.

작은 팀일수록 이 루프가 더 중요합니다. 리뷰어가 적다면 AI가 만든 선택을 문서화하게 하고, 사람이 위험도가 높은 결정부터 확인해야 합니다. 이 습관이 있어야 빠른 생성이 팀의 장기 속도를 해치지 않습니다.

바로 적용할 체크리스트

AI에게 기능 구현을 맡기기 전에는 아래 항목을 먼저 채워보세요.

  • 기능의 목적과 제외 범위를 한 문장으로 적습니다.

  • 이미 정한 기술 선택과 절대 바꾸면 안 되는 규칙을 적습니다.

  • 예외 처리와 로그 기준을 적습니다.

  • 테스트로 증명해야 할 동작을 세 가지 이상 적습니다.

  • 구현 뒤 AI가 내린 숨은 선택을 목록으로 뽑게 합니다.

  • 다음 작업자를 위해 결정 이유를 문서에 남깁니다.

AI는 코드를 빠르게 만들 수 있습니다. 하지만 그 코드의 책임은 여전히 사람에게 있습니다. 좋은 AI 코딩은 더 짧은 프롬프트가 아니라 더 명확한 선택 기준에서 시작합니다.