AI 코딩 도구로 웹개발 한 달 해봤더니 반복된 실수들

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

버튼 하나를 만들어 달라고 했는데 그럴듯한 코드가 몇 초 만에 완성됐습니다. 처음에는 개발 속도가 두 배쯤 빨라졌다고 생각했지만, 한 달 뒤 커밋 기록에는 중복 함수와 누락된 예외 처리, 출처를 설명하기 어려운 코드가 차곡차곡 쌓여 있었습니다.

AI 코딩 도구가 나빠서 생긴 문제는 아니었습니다. 대부분은 답을 검증하지 않은 채 붙여 넣거나, 프로젝트의 맥락을 충분히 전달하지 않은 제 사용법에서 시작됐습니다. 빠르게 작성된 코드를 믿을 수 있는 웹개발 결과물로 바꾸려면 무엇을 하지 말아야 하는지부터 알아야 합니다.

첫 주에는 실행되는 코드만 보고 성공했다고 착각했습니다

화면이 뜬다는 사실은 품질 보증이 아닙니다

첫 번째 실패는 로그인 폼의 유효성 검사를 만들 때 발생했습니다. AI가 작성한 코드는 이메일 형식을 확인하고 비밀번호 길이도 검사했으며 브라우저에서 정상적으로 동작했습니다. 문제는 공백만 입력한 값, 한글 도메인이 포함된 주소, 연속 클릭으로 요청이 두 번 전송되는 상황을 전혀 고려하지 않았다는 점입니다.

코딩은 요구사항을 컴퓨터가 실행할 수 있는 형태로 표현하는 작업입니다. 코딩의 기본 개념을 떠올려 보면, 문법상 실행된다는 사실과 사용자의 목적을 충족한다는 사실은 분명히 다릅니다. 그런데 AI가 매끄러운 함수명과 주석까지 제시하면 우리는 완성도를 실제보다 높게 평가하기 쉽습니다.

이후에는 생성된 코드 옆에 정상 입력·경계값·실패 상황을 나누어 적었습니다. 예를 들어 비밀번호가 8자 이상이라는 조건이 있다면 7자, 8자, 9자를 각각 넣어 보고, 네트워크가 끊겼을 때 버튼 상태와 오류 문구가 어떻게 변하는지도 확인했습니다. 여러분의 코드가 지금 잘 작동하는 이유는 구현이 탄탄해서일까요, 아니면 아직 불편한 입력을 만나지 않았기 때문일까요?

• 하지 말아야 할 일: 브라우저에서 한 번 성공한 결과만 보고 코드를 병합합니다.
• 확인할 항목: 빈 문자열, 공백, 최솟값과 최댓값, 중복 요청, 느린 응답을 따로 시험합니다.
• 남겨야 할 기록: AI에게 준 요구사항과 사람이 추가로 판단한 예외 조건을 커밋 또는 이슈에 적습니다.
• 중단 신호: 코드의 특정 조건문이 왜 필요한지 설명할 수 없다면 적용을 보류합니다.

실행 성공은 검토의 끝이 아니라 시작입니다. AI가 만든 코드일수록 정상 경로보다 실패 경로를 먼저 열어 보세요.

맥락을 생략하니 프로젝트 안에 서로 다른 규칙이 생겼습니다

짧은 프롬프트가 만든 긴 유지보수 비용

둘째 주에는 상품 목록의 페이지네이션을 요청하면서 단지 “React로 페이지 이동 컴포넌트를 만들어 줘”라고 입력했습니다. 결과물 자체는 깔끔했지만 기존 프로젝트가 사용하는 라우팅 방식, 디자인 토큰, 접근성 규칙과 맞지 않았습니다. 이미 설치된 유틸리티 대신 비슷한 패키지를 새로 권했고, 버튼 색상은 하드 코딩했으며, 키보드 초점 표시도 빠져 있었습니다.

이 코드를 그대로 넣었다면 같은 프로젝트 안에서 페이지 이동 방식이 두 개가 됐을 것입니다. 당장의 생성 시간은 5분이었지만 동료가 구조를 파악하고 스타일을 고치며 의존성을 다시 검토하는 데에는 훨씬 긴 시간이 들었습니다. 프롬프트가 짧을수록 효율적이라는 생각은 작은 예제에서는 맞을 수 있어도 실제 웹개발 프로젝트에서는 위험했습니다.

그 뒤부터 요청 앞부분에 기술 스택만 나열하지 않고 제약 조건을 함께 제공했습니다. “기존 라우터와 Button 컴포넌트를 재사용하고, 새 패키지를 추가하지 않으며, 모바일 360px에서도 줄바꿈이 깨지지 않아야 한다”처럼 결과를 판별할 기준을 적었습니다. AI는 프로젝트 전체를 자동으로 이해하는 동료가 아니라, 제공받은 범위 안에서 패턴을 조합하는 도구라는 전제가 필요합니다.

1. 관련 파일의 역할과 현재 데이터 흐름을 두세 문장으로 설명합니다.
2. 재사용해야 하는 컴포넌트, 함수, 디자인 토큰의 이름을 명시합니다.
3. 새 라이브러리 설치 가능 여부와 지원해야 할 브라우저 범위를 알려 줍니다.
4. 응답 형식을 “전체 파일”이 아니라 “변경 이유와 수정 부분”으로 제한합니다.
5. 완료 조건에 모바일 화면, 키보드 조작, 로딩 및 오류 상태를 포함합니다.

큰 파일 전체를 넘기는 습관도 피해야 합니다

맥락이 중요하다고 해서 환경 변수, 고객 데이터, 사내 주소가 포함된 파일 전체를 붙여 넣어서는 안 됩니다. 필요한 인터페이스와 축약한 예시 데이터만 제공하고, 토큰이나 개인 식별 정보는 가상의 값으로 바꿔야 합니다. 회사에서 승인한 도구와 데이터 처리 정책이 있다면 개인의 편의보다 그 기준을 먼저 따라야 합니다.

• 비밀 키와 세션 값은 REDACTED 같은 명확한 대체 문자열로 치환합니다.
• 오류 로그를 공유하기 전 이메일, 전화번호, 내부 도메인이 섞였는지 검색합니다.
• 프로젝트 규칙은 짧은 지침 파일로 관리하되 실제 비밀 정보는 넣지 않습니다.

그럴듯한 설명을 신뢰하자 보안과 성능 문제가 따라왔습니다

존재하지 않는 API와 낡은 사용법을 그대로 받아들였습니다

셋째 주의 가장 난감한 실패는 AI가 추천한 라이브러리 메서드가 현재 설치된 버전에 존재하지 않았던 일입니다. 함수명과 사용 예제가 너무 자연스러워 공식 문서를 확인하지 않았고, 빌드 오류가 난 뒤에야 다른 버전의 사용법이 섞였다는 사실을 알았습니다. 오류 메시지를 다시 AI에게 전달하자 또 다른 코드를 자신 있게 내놓았지만, 그것 역시 근본 원인을 설명하지 못했습니다.

프로그래밍의 의미와 구성처럼 개발은 단순한 코드 입력이 아니라 분석과 설계, 검증이 연결된 과정입니다. AI 답변은 그 과정에서 참고할 초안이지 공식 문서나 실제 실행 결과를 대신하지 않습니다. 특히 인증, 결제, 파일 업로드처럼 피해 규모가 큰 기능은 “보기에 안전한 코드”와 “검증된 코드”를 구분해야 합니다.

한 번은 검색 조건을 URL에 붙이는 코드에서 사용자 입력을 그대로 문자열로 결합한 답을 받았습니다. 또 다른 답변은 서버 권한 검사를 프론트엔드 버튼 숨김으로 대신했습니다. 이런 문제는 문법 검사만으로 잡히지 않으므로 입력 검증, 출력 인코딩, 서버 측 권한 확인, 의존성 출처를 사람이 별도로 살펴야 합니다.

• 처음 보는 패키지는 설치 전에 공식 출처와 라이선스를 확인합니다.
• 보안 관련 코드는 “취약점을 찾아 달라”는 질문을 추가하고 별도로 리뷰합니다.
• 성능 개선 답변은 추측으로 채택하지 않고 변경 전후 수치를 측정합니다.
• 버전이 중요한 문법은 현재 프로젝트의 잠금 파일과 공식 문서를 기준으로 검증합니다.

AI가 이유를 유창하게 설명해도 근거가 생기는 것은 아닙니다. 출처, 버전, 재현 절차 중 하나도 확인할 수 없다면 아직 검증되지 않은 제안입니다.

속도가 빨라져도 성과가 자동으로 늘지는 않습니다

AI 지원이 모든 조직에 같은 결과를 주지 않는다는 점은 AI 활용 성과 차이를 다룬 기사에서도 생각해 볼 수 있습니다. 도구를 도입했다는 사실보다 어떤 업무에 쓰고, 누가 결과를 검토하며, 실패를 어떻게 기록하는지가 실제 생산성을 좌우합니다.

저는 생성된 코드 줄 수 대신 리뷰에서 되돌아온 횟수, 수정 후 발생한 오류, 작업을 이해하는 데 걸린 시간을 기록했습니다. 그러자 단순 반복 UI와 테스트 데이터 생성에는 도움이 컸지만 복잡한 권한 설계와 원인 불명의 성능 문제에서는 오히려 질문과 검증 시간이 늘어난다는 차이가 보였습니다.

• 적합한 작업: 반복 구조 초안, 테스트 사례 후보, 문서 표현 개선, 작은 리팩터링입니다.
• 주의할 작업: 인증 구조, 개인정보 처리, 데이터 삭제, 결제 상태 전환입니다.
• 측정할 지표: 생성량보다 재작업 시간, 결함 수, 리뷰 통과율을 살펴봅니다.

한 달 뒤에도 남은 세 가지 나쁜 습관을 끊었습니다

복사, 과잉 수정, 책임 떠넘기기가 마지막 함정이었습니다

가장 자주 되풀이한 실수는 답변 전체를 한꺼번에 복사하는 행동이었습니다. 기존 함수 두 줄만 바꾸면 되는 작업인데 AI가 파일 전체를 다시 작성하면서 주석, import 순서, 오류 처리 방식까지 바꿨습니다. 변경 범위가 커지자 코드 리뷰에서 핵심을 찾기 어려웠고, 원래 잘 동작하던 모바일 이벤트가 사라진 적도 있었습니다.

두 번째 실수는 작은 경고를 해결하려다 관련 없는 리팩터링까지 맡긴 것입니다. AI는 요청받은 문제 주변의 코드를 “개선”하며 함수 이름과 데이터 구조를 넓게 바꾸기도 합니다. 그래서 지금은 한 번의 요청에 하나의 목적만 두고, 수정 파일과 허용 범위를 먼저 선언한 뒤 diff를 줄 단위로 읽습니다.

세 번째는 장애가 생겼을 때 “AI가 작성한 부분”이라고 책임을 분리한 태도였습니다. 저장소에 반영된 순간부터 그 코드는 승인한 개발자의 코드입니다. 설명할 수 없는 코드는 병합하지 않고, 문제가 발생하면 생성 도구가 아니라 입력 조건과 검토 과정, 테스트 누락을 회고 항목으로 남겨야 같은 실패를 줄일 수 있습니다.

1. 복사 전: 제안된 변경을 함수 단위로 나누고 기존 코드와 겹치는 부분을 찾습니다.
2. 적용 중: 관련 없는 이름 변경, 패키지 추가, 포맷 변경은 제거합니다.
3. 적용 후: 린트와 타입 검사뿐 아니라 사용자가 실제로 밟는 흐름을 실행합니다.
4. 리뷰 요청 전: 왜 이 접근을 골랐는지와 포기한 대안을 두세 문장으로 적습니다.
5. 배포 전: 되돌릴 커밋과 관찰할 오류 지표를 미리 정합니다.

프롬프트를 저장하면서 코드 검토를 생략하지 마세요

효과가 좋았던 요청문은 팀 문서에 저장하되 결과까지 정답처럼 고정하지 않았습니다. 프로젝트 버전과 요구사항이 달라지면 같은 프롬프트도 다른 위험을 만들기 때문입니다. 템플릿에는 목표, 제약, 완료 조건, 금지 사항만 넣고 매번 현재 코드와 대조했습니다.

여기서 마지막으로 피해야 할 행동이 세 가지 있습니다. 첫째, 긴 답변을 받았다는 이유로 문제를 깊이 분석했다고 착각하지 마세요. 둘째, 테스트 코드까지 AI가 만들었다고 해서 구현과 같은 오해를 공유하지 않는다고 믿지 마세요. 셋째, 시간에 쫓길수록 검증 단계를 없애지 말고 변경 범위를 더 작게 줄이세요.

• 설명할 수 없는 한 줄을 “일단 동작하니까” 남겨 두지 않습니다.
• 구현 코드와 테스트를 같은 요청 한 번으로 끝내고 독립 검증했다고 여기지 않습니다.
• 긴급 배포에서 AI에게 대규모 구조 변경을 맡기지 않습니다.
• 성공한 프롬프트를 모든 프로젝트에 그대로 재사용하지 않습니다.
• 생성 속도를 개발 실력이나 제품 품질과 동일시하지 않습니다.