AI가 몇 분 만에 만들어 준 화면이나 문서를 보면 마음이 놓입니다. 제목도 있고, 흐름도 있고, 당장 실행되는 것처럼 보입니다. 그런데 “완성됐다”는 말은 조금 더 늦게 써야 합니다. GeekNews가 소개한 글1의 원문을 쓴 Anuradha Weeraman은 프로토타입과 제품 사이에 운영·보안·데이터·지원의 일이 남는다고 짚습니다.2 한 개발자의 경험담이지만, 그 목록은 완성도를 점검할 때 참고할 만합니다.
초안이 잘하는 일
초안은 속도에 강합니다. 빈 화면을 채우고, 가능한 구조를 제안하고, 사용자가 무엇을 더 물어야 할지 보이게 합니다. 코드라면 화면과 데이터 흐름을 세우고, 보고서라면 목차와 문단을 만듭니다. 이 단계의 AI는 꽤 유용합니다. 시작을 미루게 만드는 부담을 줄여 주기 때문입니다.
하지만 초안이 잘하는 일과 완성물이 책임져야 할 일은 다릅니다. 작동하는 첫 버전은 정상 입력만 받았을 때의 모습일 수 있습니다. NIST의 보안 소프트웨어 개발 프레임은 설계부터 취약점 대응까지 개발 수명주기 전체의 관리를 요구합니다.3 AI가 만든 코드라고 해서 일반 소프트웨어의 보안 기준에서 벗어나는 것은 아닙니다.
완성 전 점검표
완성 여부를 보려면 질문을 바꿔야 합니다. “그럴듯한가”가 아니라 “어디서 깨지는가”를 물어야 합니다. 처리하지 못하는 입력은 무엇인지, 예외 상황에서는 어떤 문장이 나오는지, 근거를 요구하면 어디까지 설명하는지, 실제 독자에게 맞게 어조가 조정됐는지를 봐야 합니다.
이 점검은 개발자에게만 필요한 절차가 아닙니다. AI가 만든 강의 활동지는 깔끔해 보여도 학생 수준이나 수업 시간에 맞지 않을 수 있습니다. 코드라면 지연, 트래픽, 오류, 자원 포화처럼 운영 중에 볼 신호가 있어야 한다는 Google SRE의 기준도 참고할 수 있습니다.4 모든 작은 프로젝트가 구글식 운영 체계를 갖출 필요는 없지만, “실행됐다”와 “운영 상태를 알 수 있다”가 다르다는 점은 같습니다.
무료로 갈 수 있는 데까지
대부분의 1차 검토는 무료 범위에서도 가능합니다. 반례를 넣어 보고, 예외 입력을 던져 보고, 같은 요구를 한 번 더 시켜 보는 정도는 별도 도구 없이도 할 수 있습니다. 대량 데이터로 확장성을 재거나 보안 취약점을 체계적으로 점검하는 일은 다른 환경이 필요할 수 있습니다. 그렇다고 처음부터 유료 점검으로 넘어갈 필요는 없습니다. 무료로 확인한 것과 아직 확인하지 못한 것을 나누어 적어 두면 됩니다.
AI 코딩 보조를 쓴 이용자가 더 취약한 코드를 만들면서도 더 안전하다고 느낄 수 있다는 실험 연구도 있습니다.5 특정 모델과 과제의 결과를 모든 AI 코드에 일반화할 수는 없지만, 자신감이 검증을 대신하지 못한다는 경고는 남습니다. 초안이 빠르게 나왔다는 사실과 완성물이 책임질 준비가 됐다는 사실은 다릅니다.
각주
-
AI가 작동하는 제품까지 만들어주지는 않는다, 그건 여전히 당신의 일이다 — news.hada.io, 2026-08-01 발행, 2026-08-02 접속 확인. ↩
-
The Prototype Isn’t the Product — Anuradha Weeraman. GeekNews가 소개한 원문이며, 개인 에세이의 범위로 인용했다. ↩
-
Secure Software Development Framework Version 1.1 — NIST SP 800-218, 2022. AI 전용 기준은 아니며 일반 소프트웨어의 보안 개발 원칙으로 연결했다. ↩
-
Monitoring Distributed Systems — Google SRE Book. 운영 관측의 대표 기준으로만 사용했다. ↩
-
Do Users Write More Insecure Code with AI Assistants? — ACM CCS 2023. 특정 모델과 실험 조건의 연구이므로 모든 AI 코드에 일반화하지 않았다. ↩
