첫 화면은 빨리 나오는데, 그다음이 어렵습니다
AI에게 아이디어를 설명하면 화면과 코드가 금방 나옵니다. 그런데 가입을 붙이고, 데이터를 보존하고, 실제 사용자에게 배포하려는 순간 같은 부분을 여러 번 고치게 됩니다. 시작은 쉬워졌지만 ‘작동하는 데모’와 ‘계속 쓸 수 있는 제품’ 사이의 일은 남아 있습니다.
아래는 서로 성격이 다른 네 가지 자료입니다. 개발자 설문, 실제 작업 시간을 잰 실험, GitHub 변경 요청 분석, 한 건의 운영 사고입니다. 이 자료들로 AI 개발 프로젝트의 전체 실패율을 계산할 수는 없습니다. 대신 어디서 작업이 막히는지 구체적으로 볼 수 있습니다.
사례 1. 그럴듯해서 늦게 발견되는 코드
2026년 Stack Overflow 개발자 설문은 지난 1년간 시간을 가장 많이 쓰게 한 AI 실수를 물었습니다. 응답자 13,648명 가운데 69.3%가 ‘그럴듯하지만 틀린 코드’를, 54.2%가 ‘검토하기 어려운 생성 코드’를, 49.3%가 ‘맥락 누락’을 선택했습니다. 여러 답을 고를 수 있는 자기보고 설문이므로 이 숫자는 프로젝트 실패율이 아닙니다.
흔한 장면은 로그인 화면이 잘 보이는데 새로고침하면 세션이 사라지는 경우입니다. 화면만 확인하면 완성처럼 보입니다. 브라우저를 닫았다 열고, 다른 기기에서 로그인하고, 오류 상태를 확인해야 비로소 빠진 조건이 드러납니다. 이 장면은 설문이 가리키는 문제를 설명하기 위한 예시이며 특정 조사 대상자의 사례는 아닙니다.
자료 Stack Exchange Inc. · Stack Overflow Developer Survey 2026
사례 2. 빨리 작성했지만 끝내는 시간은 길어진 작업
METR은 2025년 초 숙련된 오픈소스 개발자 16명이 실제 프로젝트의 작업 246건을 처리하는 시간을 비교했습니다. 이 실험에서 AI 사용이 허용된 작업은 평균 19% 더 오래 걸렸습니다. 참가자들은 작업 전후 모두 AI가 속도를 높였다고 예상했습니다. 코드 생성 속도와 작업 완료 시간은 다를 수 있다는 뜻입니다.
이 결과를 지금의 모든 개발자와 AI 도구에 적용할 수는 없습니다. METR은 2026년 후속 조사에서 최신 도구의 효과가 개선됐을 가능성을 제시했지만, 참여자와 작업 선택 편향 때문에 정확한 속도 효과를 판단하기 어렵다고 밝혔습니다. 여기서 가져올 교훈은 ‘AI가 느리다’가 아니라, 데모가 빨리 나온 감각만으로 생산성을 판단하지 말자는 것입니다.
사례 3. 한 번에 너무 많이 바꾼 변경 요청
2026년 연구진은 다섯 종류의 코딩 에이전트가 만든 GitHub PR 약 3만 3천 건을 분석했습니다. 병합되지 않은 PR은 병합된 PR보다 수정 파일과 코드량이 큰 경향이 있었고, CI 검사 실패도 더 잦았습니다. 별도로 검토한 PR에서는 중복 변경, 원치 않는 기능, 요구와 어긋난 구현도 발견됐습니다.
병합되지 않았다는 사실만으로 코드가 틀렸다고 단정할 수는 없습니다. 검토자가 참여하지 않거나 이미 같은 변경이 있던 경우도 포함됩니다. 그래도 ‘앱 전체를 한 번에 완성해줘’보다 작은 기능 하나를 만들고, 변경 범위와 테스트 결과를 확인하는 방식이 검토하기 쉽다는 실무적 시사점을 줍니다.
사례 4. 개발 작업이 운영 데이터에 닿았을 때
SaaStr의 Jason Lemkin은 2025년 Replit 에이전트로 만든 첫 앱에서 데이터베이스가 삭제된 일을 직접 공개했습니다. Replit은 당시 개발과 운영 데이터가 하나의 데이터베이스를 사용했다고 설명하고, 이후 두 환경을 분리하는 기능을 발표했습니다. 이 한 건을 모든 AI 도구의 동작으로 일반화할 수는 없습니다.
하지만 실제 데이터에 접근할 수 있는 권한을 가진 에이전트에게 ‘조심해’라고 말하는 것만으로는 충분하지 않다는 점은 분명합니다. 개발용 데이터와 운영 데이터를 분리하고, 되돌릴 수 있는 지점을 만들고, 파괴적인 변경은 실행 전에 확인하도록 해야 합니다.
사례마다 달라도 막히는 지점은 비슷합니다
자료를 함께 보면 세 가지 질문이 반복됩니다. 무엇을 만들면 끝나는지 합의했는가. AI가 만든 중간 결과를 원래 요구와 대조했는가. 실제 환경에서 확인한 사실과 아직 추정인 내용을 나눴는가. 이는 자료를 종합한 해석이지, 단일 연구가 모든 실패의 원인으로 입증한 공식은 아닙니다.
프롬프트를 더 길게 쓰는 것만으로 이 질문이 해결되지는 않습니다. 결과를 확인할 기준과 확인한 기록이 있어야 다음 수정이 제자리로 돌아오지 않습니다.
끝내기 위해 먼저 할 일
가입 기능이라면 완료 기준을 ‘확인 전 계정은 로그인 불가, 확인 후 로그인 가능, 새로고침 후 세션 유지, 잘못된 비밀번호에 오류 표시’처럼 사용자 동작으로 적을 수 있습니다. 화면이 열리는지만 보는 것보다 누락을 찾기 쉽습니다. 이 문장은 조사에 등장한 실제 프로젝트의 요구가 아니라 독자가 적용해 볼 수 있는 예시입니다.
이 기준을 통과한 다음에 다음 기능으로 넘어가세요. 작은 완성을 쌓으면 무엇이 아직 미완성인지도 선명해집니다.
- 이번 주에 완성할 사용자 동작 하나를 고릅니다. 예: ‘가입 후 다시 접속해도 내 기록이 보인다.’
- 그 동작의 완료 기준을 화면, 데이터, 오류 상황으로 나눠 적습니다.
- AI에는 한 번에 한 변경을 맡기고, 수정 파일과 실제 실행한 검사를 받습니다.
- 작동하는 화면뿐 아니라 새로고침, 재로그인, 실패 응답, 모바일 화면을 직접 확인합니다.
- 운영 데이터와 비밀키 접근을 분리하고, 배포 전에 되돌릴 방법을 확인합니다.
다음 세션에서 같은 실수를 반복하지 않으려면
AI 도구를 바꾸거나 새 세션을 시작하면 ‘왜 이렇게 고쳤는지’가 빠지기 쉽습니다. 검토한 산출물, 실제 통과한 검사, 남은 문제를 함께 남겨 두면 다음 작업의 출발점을 다시 만들 필요가 줄어듭니다.
Wellnote에는 Codex와 Claude Code에서 선택한 산출물과 프롬프트를 저장하고 다시 찾을 수 있습니다. 오늘 확인한 변경 하나와 그 이유를 기록해 보세요. 테스트 실행과 권한 설정은 실제 개발 환경에서 별도로 해야 합니다.