AI가 코드를 잘못 짜는 경우는 생각보다 드물다. 더 흔한 실패는 다른 곳에서 온다. AI가 올바른 코드를 틀린 방향으로 만들어내는 상황이다. 프론트엔드 개발자로서 '빠른 프로토타이핑 → 검증 → 고도화' 사이클을 돌리다 보면, 이 조용한 실패가 가장 비싼 비용을 치른다는 걸 반복해서 경험하게 된다. 최근 세 편의 실무 관찰을 엮어보니, 실패 지점이 정확히 세 곳으로 수렴한다.
1. 범위: 말하지 않은 것이 경계가 되지 않는다
dev.to의 한 글(The Habit That Stops Your AI From Quietly Wrecking Your Plan)은 이 문제를 정확하게 짚는다. AI 에이전트는 빈 공간을 가정으로 채운다. 체크아웃 화면을 개선해달라고 했을 뿐인데, 에이전트는 자발적으로 Stripe 연동을 추가한다. 어드민 패널을 요청하지 않았는데 어느 날 생겨 있다. 에이전트가 고장 난 게 아니다. 당신이 문을 열어둔 것이다.
핵심 통찰은 Non-goals는 사람을 위한 메모가 아니라 미래 프롬프트를 위한 가드레일이라는 점이다. "v1에서 결제 없음"이라는 한 줄은 당신에게 아무것도 알려주지 않는다. 하지만 사흘 뒤 에이전트가 같은 맥락을 다시 읽을 때, 그 선이 경계를 유지한다. 경계는 명문화되어 있는 동안만 작동한다.
실행 방법은 간단하다. 계획 단계에서 에이전트에게 직접 물어보면 된다. "이 계획을 보고, 네가 추가하고 싶어할 것들 중 내가 요청하지 않은 것들을 나열해라." 에이전트는 정직하게 대답한다—오히려 본인이 무엇을 추가하려 했는지를 그대로 꺼내놓는다. 그걸 "이 버전에서 하지 않는다"는 규칙 목록으로 변환해 프로젝트 인스트럭션에 박아두면, 그 경계는 이후 모든 프롬프트와 함께 이동한다.
2. UI 정확도: 픽셀은 의도를 전달하지 못한다
두 번째 실패 지점은 더 조용하다. 에이전트에게 스크린샷을 넘기면, 에이전트는 픽셀에서 의미를 추론해야 한다. 비슷하게 생긴 버튼 여섯 개 중 어떤 걸 가리키는지 절반은 틀린다. 틀리면 다시 프롬프트한다. 그렇게 라운드트립 한 번과 수천 토큰이 사라진다.
dev.to의 다른 글이 제안하는 해법은 본질적으로 단순하다. 다음 독자가 기계라면, 이미지보다 구조화된 데이터가 더 정확하다. 같은 스크린샷이라도 "어떤 요소를, 어떤 의도로" 처리해달라는 구조화된 페이로드로 전달하면, 에이전트는 추론하지 않고 실행한다. 토큰 비용도 수천에서 수백으로 줄어든다. 이미지는 모든 것을 담지만 아무것도 신호하지 않는다—문제는 정보량이 아니라 신호 명확성이다.
이건 UI 컴포넌트 설계와 직결되는 문제이기도 하다. 에이전트가 UI를 다루는 빈도가 늘어날수록, 레이블·역할·영역 좌표 같은 접근 가능한 구조가 기계 가독성의 핵심이 된다. a11y를 위해 쌓아온 구조적 마크업이 사실은 AI 에이전트와의 협업 정확도를 높이는 인프라이기도 하다는 뜻이다.
3. 완성도: 작동하는 데모와 프로덕션 사이의 거리
세 번째 지점은 가장 보기 어렵다. 코드가 돌아가고, UI가 그럴듯해 보이고, 데모가 완성된 것처럼 느껴질 때다. 해커톤 심사 경험을 정리한 dev.to 글은 이 맹점을 날카롭게 포착한다. 심사 과정에서 패턴이 보였다. 아름다운 인터페이스지만 기술적 깊이가 없는 프로젝트, 강한 엔지니어링이지만 문서가 부실한 프로젝트—그리고 무엇보다, "흥미로운" 것과 "강한" 것의 차이는 항상 실행 명확도에서 갈렸다.
에러 핸들링, 사용자 온보딩, 관찰 가능성, 배포 준비 상태—이것들은 AI가 자발적으로 챙기지 않는 영역이다. 오히려 앞서 말한 Non-goals의 반대편 문제다. AI는 요청하지 않은 것을 추가하기도 하지만, 요청했을 때 암묵적으로 기대하는 것은 빠뜨리기도 한다. 보안 고려사항, 엣지 케이스 처리, 실제 사용 시나리오에서의 신뢰성—이것들은 명시적으로 요구하지 않으면 데모 수준에서 멈춘다.
해커톤 심사자의 관찰이 의미 있는 이유는, AI 도구가 보편화된 지금 AI 보조 개발을 얼마나 잘 쓰는지가 아니라 인간 판단을 어디서 발휘했는지가 프로젝트 수준을 가른다는 점을 보여주기 때문이다. AI가 보일러플레이트, 리팩토링, 반복 구현을 담당할 때 가장 성숙한 팀은 "AI가 뭘 했는가"가 아니라 "우리가 어떤 판단을 내렸는가"를 설명한다.
세 지점이 가리키는 하나의 원칙
범위 통제, UI 신호 명확성, 실행 완성도—세 문제는 표면적으로 달라 보이지만 같은 곳에서 출발한다. AI는 명시된 것에 반응하고, 명시되지 않은 것은 추론으로 채운다. 그 추론이 맞을 때는 마법처럼 느껴지고, 틀릴 때는 조용히 프로덕트 품질을 갉아먹는다.
프로토타이핑 단계에서는 이 조용한 실패가 보이지 않는다. 빠르게 움직이는 게 목적이니까. 문제는 그 다음이다. 검증 단계에서 범위가 이미 넘쳐 있고, UI 인터랙션이 의도와 다르게 연결되어 있고, 에러 케이스가 처리되지 않은 채 누적되어 있다면—고도화는 새 기능을 얹는 게 아니라 조용한 실패를 걷어내는 작업이 된다.
실행 가능한 체크포인트는 세 가지다. 첫째, 플래닝 시점에 Non-goals 목록을 만들고 에이전트가 항상 읽는 위치에 둔다. 둘째, UI 요소를 에이전트에게 전달할 때 픽셀이 아닌 구조화된 의도로 변환한다. 셋째, 데모가 완성된 것처럼 보이는 순간 에러 핸들링·온보딩·배포 준비 상태를 명시적으로 요청한다. 이 세 지점은 AI가 스스로 챙기지 않는다. 그리고 그걸 알고 있는 개발자가 AI를 도구로 쓰는 게 아니라 워크플로우로 설계하는 사람이다.