AI 트렌드 ·

AI가 코드를 써줘도 비전공자가 끝까지 확인해야 하는 것

먼저 답부터

AI 코딩 도구는 자연어 요청을 코드로 바꾸고 파일 수정과 테스트를 도울 수 있지만, 원하는 기능이 맞는지와 개인정보·비용·보안 문제가 없는지까지 자동으로 보장하지는 않습니다. 비전공자도 목표와 완료 조건을 적고 변경 파일을 확인하며 작은 테스트와 공개 화면 검증을 거쳐야 합니다.

AI가 코드를 써줘도 비전공자가 끝까지 확인해야 하는 것 대표 이미지

“문의 버튼을 누르면 이메일을 보내는 페이지를 만들어줘”라고 입력하면 AI 코딩 도구가 여러 파일을 만들고 몇 분 안에 화면을 보여줄 수 있습니다. 예전보다 시작은 쉬워졌습니다. 그렇다고 결과를 이해하지 않아도 되는 것은 아닙니다.

내비게이션이 길을 알려줘도 운전자가 목적지와 도로 상황을 확인해야 하는 것처럼, AI는 코드를 제안하지만 무엇을 만들고 어디까지 공개할지는 사용자가 정합니다. 개발 용어를 모두 외우기 전에 목표, 변경 범위, 완료 조건, 위험한 정보부터 구분하면 첫 작업의 실수를 크게 줄일 수 있습니다.

AI 코딩 도구가 실제로 돕는 일

AI 코딩 도구는 설명을 바탕으로 새 파일을 만들고 기존 코드를 수정하며 오류 메시지를 풀어줄 수 있습니다. 프로젝트 안의 관련 파일을 읽고 테스트 명령을 실행하는 도구도 있습니다. GitHub의 Copilot 안내도 목표를 넓게 설명한 뒤 구체적인 요구를 붙이고, 복잡한 작업은 작은 단계로 나누라고 권합니다.

하지만 AI는 내가 머릿속으로만 생각한 조건을 알 수 없습니다. “예쁘게”, “안전하게”, “회원 기능도” 같은 말은 사람마다 뜻이 다릅니다. 사용할 기기, 입력값, 성공 화면, 실패했을 때 보여줄 말처럼 눈으로 확인할 수 있는 조건을 적어야 합니다.

기능보다 사용자의 한 장면을 먼저 말한다

“로그인 기능을 만들어줘”보다 누가 언제 무엇을 하려는지 설명하면 범위가 선명해집니다. 예를 들어 “휴대전화에서 이메일을 입력한 사용자가 로그인 링크를 받고, 링크가 만료되면 다시 요청할 수 있게 해줘”라고 시작합니다.

그 다음 완료 조건을 붙입니다.

  • 이메일이 비어 있으면 전송하지 않고 쉬운 안내를 보여준다.
  • 올바른 주소를 입력하면 같은 화면에서 전송 결과를 알려준다.
  • 전송 버튼을 연속으로 눌러도 같은 요청이 여러 번 생기지 않는다.
  • 링크가 만료되면 새 링크를 요청할 길을 보여준다.
  • 390픽셀 너비에서 입력칸과 버튼이 화면 밖으로 나가지 않는다.

이 목록은 전문적인 설계서가 아니라 결과를 확인할 약속입니다. AI가 만든 코드가 길어도 이 다섯 가지를 만족하지 않으면 작업은 끝난 것이 아닙니다.

한 번에 작은 변경만 부탁한다

회원가입, 결제, 관리자 화면, 알림을 한 요청에 묶으면 수십 개 파일이 바뀔 수 있습니다. 문제가 생겼을 때 어느 변경이 원인인지 찾기 어렵습니다. 먼저 정적인 로그인 화면, 다음에는 입력 검사, 그 다음에는 실제 인증 연결처럼 나눕니다.

각 단계가 끝날 때 바뀐 파일 목록과 변경 요약을 요청합니다. 새 패키지를 설치했다면 이름과 필요한 이유를 확인합니다. 이해할 수 없는 삭제나 설정 변경이 있으면 그대로 진행하지 말고 원래 상태와 비교하도록 요청합니다.

목표: 로그인 화면의 빈 이메일 안내 추가
바꿀 범위: 로그인 화면과 해당 테스트만
바꾸지 말 것: 결제, 회원 데이터, 배포 설정
완료 확인: 빈 값 전송 차단과 정상 값 전송 유지

코드 전체보다 변경된 부분을 읽는다

모든 문법을 이해하지 못해도 변경 비교 화면은 읽을 수 있습니다. 초록색 줄은 추가, 빨간색 줄은 삭제로 보이는 경우가 많습니다. 요청하지 않은 파일이 바뀌었는지, 이메일이나 비밀키가 코드에 직접 들어갔는지, 기존 안내 문구가 사라졌는지부터 찾습니다.

AI에게 각 변경을 비전공자 말로 설명하고 위험한 줄을 표시해 달라고 할 수 있습니다. 다만 그 설명도 검증의 한 부분일 뿐입니다. GitHub는 AI 코드 리뷰가 문제를 제안할 수 있지만 제안을 적용하고 확인하는 작업은 여전히 필요하다고 안내합니다. AI가 만든 코드를 다른 AI가 검토했다는 사실만으로 안전이 증명되지는 않습니다.

테스트는 버튼을 눌러보는 순서로 시작한다

테스트는 개발자만 쓰는 어려운 코드가 아닙니다. 사용자가 실제로 할 행동과 기대 결과를 적고 반복 확인하는 일부터 시작할 수 있습니다. 정상 입력 하나만 확인하지 말고 빈 값, 잘못된 값, 연속 클릭, 느린 연결도 시험합니다.

로그인 화면 예시라면 다음 순서로 확인합니다.

  1. 빈 이메일로 버튼을 눌러 전송되지 않는지 본다.
  2. 이메일 모양이 아닌 값을 넣어 이해할 수 있는 안내가 나오는지 본다.
  3. 정상 주소로 한 번 전송하고 성공 문구를 확인한다.
  4. 버튼을 빠르게 두 번 눌러 중복 요청이 생기지 않는지 본다.
  5. 새로고침 뒤에도 이전 사용자의 이메일이 남지 않는지 본다.
  6. 휴대전화 크기와 키보드만으로 사용할 수 있는지 본다.

자동 테스트가 통과했다면 공개 주소에서도 같은 흐름을 다시 확인합니다. 개발 컴퓨터의 성공과 실제 배포의 성공은 서로 다른 상태입니다.

비밀값과 실제 데이터는 대화에 넣지 않는다

API 키, 비밀번호, 결제 정보, 고객 명단을 AI 대화에 붙여넣지 않습니다. 예시가 필요하면 이름과 이메일을 가짜 값으로 바꾸고 주문번호 일부를 지웁니다. 프로젝트의 비밀값은 환경 변수처럼 코드와 분리된 저장소를 사용합니다.

AI가 “문제를 확인하려면 키를 보내달라”고 해도 실제 키를 공유하지 않습니다. 오류 메시지에 비밀값이 섞였는지 먼저 읽습니다. 이미 공개 저장소에 키를 올렸다면 줄만 지우는 것으로 끝내지 말고 해당 서비스에서 키를 폐기하고 새로 발급해야 합니다.

되돌릴 지점을 만들고 공개한다

작업 전 현재 화면을 캡처하고 변경 전 파일 상태를 버전 관리에 남깁니다. Git의 커밋은 특정 시점의 변경 묶음을 기록하는 방법입니다. 한 기능만 담은 작은 커밋은 문제가 생겼을 때 무엇을 되돌릴지 찾기 쉽습니다.

결제, 삭제, 전체 데이터 수정처럼 되돌리기 어려운 작업은 연습용 자료와 테스트 계정에서 먼저 확인합니다. 공개 배포 전에는 주소, 화면 제목, 개인정보 입력, 모바일 화면, 오류 안내를 직접 봅니다. “배포 완료”라는 도구의 메시지 대신 실제 주소에서 새 결과가 보이는지 확인해야 합니다.

첫 연습은 문구 한 줄로 충분하다

이미 있는 작은 웹 프로젝트에서 버튼 안내 문구 하나만 바꿔봅니다. 먼저 현재 문구와 원하는 문구, 바꿀 화면, 모바일에서도 보여야 한다는 완료 조건을 적습니다. AI에게 관련 파일만 찾고 변경 전에 계획을 설명하도록 요청합니다.

수정 뒤에는 바뀐 파일을 보고 화면을 직접 열어봅니다. 예상하지 않은 변경이 있으면 취소하고 범위를 더 좁힙니다. 이 작은 흐름을 익힌 뒤 입력 검사, 자료 저장, 로그인처럼 위험이 큰 기능으로 넘어가면 AI가 빠르게 쓰는 코드와 내가 책임질 결과의 경계를 이해하기 쉬워집니다.

확인한 자료

함께 읽기

  • 온디바이스 AI는 빠르지만 먼저 기기 한계를 확인해야 한다

    온디바이스 AI는 사진이나 음성 같은 입력을 서버로 보내지 않고 휴대전화나 컴퓨터 안의 모델로 처리하는 방식입니다. 인터넷 없이 빠르게 반응하고 데이터 전송을 줄일 수 있지만, 모델 크기와 기기 성능, 배터리, 업데이트 부담이 생기므로 작은 기능부터 실제 기기에서 시험해야 합니다.

  • 코딩 요청은 기술 이름보다 완료된 화면을 먼저 설명해야 한다

    좋은 코딩 요청은 긴 기술 용어가 아니라 사용자가 할 행동과 기대 결과를 분명히 적는 데서 시작합니다. 현재 화면과 오류, 관련 파일을 보여주고 바꿀 범위와 바꾸지 않을 범위, 예시 입력과 완료 조건을 붙인 뒤 작업을 작은 단계로 나눠 변경 내용과 테스트 결과를 확인합니다.