AI 빌더의 최고 기능은 프롬프트를 얼마나 빨리 작동하는 코드로 바꾸느냐가 아닙니다. 얼마나 자주 그것을 거절하느냐입니다. 당신이 요청하는 것이라면 무엇이든 흔쾌히 연결해 주는 빌더 — 관리자 경로에 인증 없음, 멱등성 검사 없는 웹훅, "일단 돌아가게만 하자"는 이유로 클라이언트 측 JS에 그대로 붙여넣는 API 키 — 는 잘못된 5분을 최적화하고 있는 것입니다. 데모를 위한 최적화이지, 6주 뒤 그 경로가 스크래핑당하는 화요일을 위한 최적화가 아닙니다.
저는 내부에서 이런 일이 벌어지는 것을 충분히 여러 번 지켜봐서 이 패턴을 신뢰합니다. 거절되거나 다른 방향으로 유도되는 요청들은 거의 이색적이지 않습니다. 오히려 지루하고 흔한 것들이죠: 지금은 이메일 인증을 건너뛰자, 테스트용이니 비밀번호를 평문으로 저장하자, 부하 테스트를 더 빨리 하기 위해 요청 제한을 꺼두자, 권한을 나중에 신경 쓸 수 있게 이 엔드포인트에 데이터베이스 전체 접근 권한을 주자. 이 모든 것이 그 순간에는 완전히 합리적으로 원할 만한 것들입니다. 그리고 이 모든 것이 정확히 사후 보고서에 등장하는 바로 그 문장이기도 합니다.
거절이 실제로 치르는 비용
거절에는 실제 대가가 있습니다: 마찰입니다. 당신은 뭔가가 만들어지길 원했는데 대신 질문을 받거나, 더 안전한 기본값을 받거나, "이래서 안 됩니다, 대신 저는 이렇게 하겠습니다"라는 답을 받았습니다. 그것은 원래 추진력처럼 느껴져야 할 매체 — 채팅으로 빌드하는 방식 — 안에서의 방해입니다. 이곳을 포함한 모든 빌더 플랫폼은 "요청한 대로 배포한다"와 "결국 만족할 것을 배포한다" 사이의 긴장을 느낍니다. 순응 쪽으로 너무 기울면 초보 빌더에게 안전장치를 풀어놓은 총을 쥐여주는 도구가 됩니다. 신중함 쪽으로 너무 기울면 생일을 저장하는 것조차 논쟁하는 도구가 됩니다.
실수는 이것을 하나의 다이얼로 취급하는 것이다. 그렇지 않다. 빌더가 반대해야 할 이유는 최소 세 가지가 있으며, 각각은 완전히 다르게 다뤄져야 한다.
| 거부 유형 | 예시 프롬프트 | 중요한 이유 | 올바른 대응 |
|---|---|---|---|
| 보안 | "CSRF 검사를 꺼줘, 테스트 속도가 느려져" | 누군가 악용할 때까지 드러나지 않는 실제 취약점을 그대로 배포하게 됨 | 문자 그대로의 요청은 거부하고, 범위가 제한된 개발 모드 토글을 대신 제안 |
| 비용 / 안정성 | "이 엔드포인트가 성공할 때까지 계속 재시도하게 해줘" | 무제한 재시도는 API 호출 한 번의 실패를 청구서 폭탄과 연쇄 장애로 바꿔놓음 | 백오프와 상한을 적용해 구현하고, 변경 사항을 설명 |
| 정확성 | "카드를 결제한 다음 주문을 생성해줘" | 순서 버그: 두 단계 사이에 오류가 발생하면 주문은 사라지지만 결제는 남음 | 조용히 순서를 바꾸거나, 작성 전에 순서 관련 위험을 먼저 알림 |
| 데이터 노출 | "이 API에서 사용자 객체 전체를 그냥 반환해줘" | 비밀번호 해시, 내부 플래그, 다른 사용자의 데이터가 과도한 데이터 반환으로 유출됨 | 명시적인 필드 허용 목록으로 직렬화하고, 무엇을 제외했는지와 그 이유를 명시 |
보안 관련 거부는 방어하기는 쉽지만 제대로 하기는 가장 어렵다. 안전한 버전이 대개 요청받은 것과 단순히 다르게 보일 뿐, 완전히 없는 것처럼 보이지는 않기 때문이다. 비용과 안정성 관련 거부는 빌더의 지나친 낙관으로부터 그 자신을 지키는 문제다. 새벽 2시에 속도 제한이 걸린 API에 대해 재시도 루프가 4천 번 실행될 것을 예상하고 "성공할 때까지 재시도"를 요청하는 사람은 없지만, 문자 그대로 해석하면 그런 뜻이 된다. 정확성 관련 거부는 조용한 종류다. 오류도, 배포 시점의 경고도 없이, 아무도 테스트할 생각을 하지 못한 특정 실패 순서에서만 나타나는 버그가 있을 뿐이다.
한 창업자가 자신의 빌더가 해준 가장 유용한 일은 "테스트 중에 거슬린다"는 이유로 요청했던 대량 삭제 작업 전 확인 단계 제거를 거부한 것이었다고 말한 적이 있다. 3주 후, 팀원 한 명이 필터를 잘못 눌렀고, 그 확인 단계 덕분에 4만 개의 행이 여전히 남아 있게 되었다.
거부는 이해할 수 있어야만 의미가 있다
이 기능이 실제로 도움이 되는지 아니면 그저 사람을 짜증나게 하는지를 결정짓는 부분은 바로 이것이다. 이유 없는 거부는 고장 난 도구와 구분이 되지 않는다. 빌더가 요청한 것을 조용히 거부하거나 알리지 않고 다른 것을 만든다면, 당신은 다음 20분을 실제로는 본 적 없는 의도적 결정이었던 "버그"를 디버깅하는 데 쓰게 될 것이다. 이는 가드레일이 아예 없는 것보다 나쁘다. 이제 계획을 신뢰하지 못하고 자신의 앱조차 이해하지 못하기 때문이다. 좋은 거부는 매번 세 가지 요소를 담는다. 무엇을 요청했는지, 대신 무엇을 만들고 있는지, 그리고 그 이유 한 문장. 보안 이론을 잔뜩 늘어놓는 것이 아니라, 비개발자도 읽고 받아들이거나 반박할 수 있는 한 문장이어야 한다. 그리고 그것은 재정의가 가능해야 한다. 누군가 정말로 안전하지 않은 버전을 원한다면 — 일회성 프로토타입, 신뢰할 수 있는 사용자 세 명만 있는 내부 도구, 6시간 안에 사라질 해커톤 데모 — 빌더는 자신이 상대방보다 그 맥락을 더 잘 안다고 가정해서는 안 된다. 안전한 경로를 기본값으로 삼고, 위험을 명확히 알린 뒤, 상대방이 고집한다면 물러나야 한다.
비판자들의 말이 일리 있는 부분
정직한 반론은, 대부분의 AI 도구 속 "안전" 동작이 제대로 조율되지 않았다는 것이며, AI 빌더도 그 비판에서 예외가 아니라고 생각한다. 지나친 거부는 이론적인 것이 아니라 실제로 존재하는 실패 유형이다. 요청 세 개 중 하나꼴로 의문을 제기하는 도구는 사람들이 그것을 우회하도록 훈련시키며, 이는 그 우회 자체가 검토되지 않는다는 점에서 가드레일이 없는 것보다 더 나쁘다. 빌더가 전화번호 하나 저장하는 데 15줄짜리 개인정보 처리 강의를 늘어놓는다면, 당신은 그 강의를 읽지 않게 될 것이고, 정말 중요했던 그 한 번을 놓치게 될 것이다. 조율이야말로 핵심이며, 이는 정말 어렵다. 너무 느슨하면 취약점을 그대로 배포하게 되고, 너무 엄격하면 사람들이 도구를 아예 무시하도록 훈련시키게 된다.
해결책은 거부를 줄이거나 늘리는 것이 아니다. 구체성이다. 구체적이고 이름 붙일 수 있는 실패와 연결된 거부 — 이 웹훅은 고객에게 이중 청구될 수 있다, 이 라우트는 다른 테넌트의 데이터를 반환한다 — 는 빠르게 신뢰를 얻는다. 요청한 사람이 그 주장을 직접 확인하고 사실임을 볼 수 있기 때문이다. "모범 사례"를 막연히 가리키는 거부는 아무것도 얻지 못하며, 그래서도 안 된다. AI 빌더 중에서 선택하는 상황이라면, 실제 프로젝트를 맡기기 전에 시험해볼 만한 것이 바로 이것이다. 요청 안에 명백한 함정이 있는 무언가를 만들어보라고 시킨 뒤, 그것이 그냥 만들어버리는지, 아무 설명 없이 거부하는지, 아니면 더 안전한 버전을 보여주고 직접 검증할 수 있는 한 문장으로 정확히 그 이유를 알려주는지 살펴보라.
