"알아서 끝까지 해" — AI한테 이 말 하면 안 되는 순간이 있어요

Claude 쓰다 보면 한 번쯤 이런 생각 하잖아요.

"아 그냥 나한테 묻지 말고 알아서 끝까지 해줘."

저도 그랬거든요. 중간에 "이렇게 할까요, 저렇게 할까요" 물어볼 때마다 흐름이 끊기고, 매번 답해주는 게 귀찮아서 그냥 통째로 맡기고 싶었어요.

근데 이게 될 때가 있고, 진짜 안 되는 순간이 있더라고요.

---

AI는 틀리지 않았다, 잘못된 걸 완벽하게 실행했을 뿐

얼마 전에 해외 개발자 커뮤니티에서 화제가 된 이야기예요.

한 회사 VP가 AI 테스트 툴을 도입했어요. 3일 만에 테스트 케이스 3,000개 생성. 기존에 팀이 6년 동안 수작업으로 쌓은 400개랑 비교하면서 "이게 300배 효율이다, 수동 테스트 팀은 왜 존재하냐"며 팀 해체를 밀어붙였죠.

그리고 2주 뒤 새벽 1시 14분.

서버가 터졌어요.

핵심 트랜잭션 파이프라인 다운. 9시간 데이터 복구. 피해액 약 70만 달러.

원인이 뭔지 아세요?

AI가 테스트를 생성할 때 범위를 "과거 프로덕션 데이터 상위 90%"로 제한해뒀거든요. AI는 그 범위 안에서 완벽하게 일했어요. 3,000개 전부 통과. 근데 실제 장애는 그 90% 바깥에서 터졌어요. 트래픽이 특정 임계치를 넘었을 때 발생하는 데이터 레이스 조건이었는데, 설정 범위 밖이라 AI가 아예 테스트를 만들지 않은 거예요.

AI가 실수한 게 아니에요. 잘못된 지시를 완벽하게 실행한 것뿐이에요.

AI automation boundary error diagram

---

"계속 해" 가 잘 먹히는 경우 vs 위험한 경우

솔직히 말하면, "알아서 끝까지 해" 자체가 나쁜 명령은 아니에요.

작업 성격에 따라 완전히 다르거든요.

이런 건 그냥 맡겨도 돼요.

• 반복되는 형식 작업. 마크다운 변환, 번역, 요약, 코드 포맷팅처럼 기준이 명확한 것들.
• 이미 충분한 맥락을 줬을 때. 어떤 결과물이 나와야 하는지, 범위가 어디까지인지 다 알려줬다면 AI가 판단을 거의 안 해도 돼요.
• 중간 결과가 틀려도 쉽게 되돌릴 수 있을 때.

이런 건 AI를 멈춰야 해요.

• 구조적인 결정이 필요한 순간. DB 설계를 바꾼다든가, API 응답 형태를 수정한다든가 — 이런 건 나중에 파급 효과가 커요.
• 요구사항 해석이 갈리는 지점. "이 기능 어디까지 만들까?"처럼 맥락에 따라 답이 달라지는 건 AI가 알아서 정하면 안 돼요.
• 실제로 돌아가는 환경에 영향을 줄 때. 코드 실행이나 배포처럼 되돌리기 어려운 건 반드시 확인 단계가 있어야 해요.

---

그럼 어떻게 쓰면 되는 건데?

저도 쓰면서 조금씩 바꾼 게 있어요.

그냥 "끝까지 해" 대신, 경계를 같이 알려주는 거예요.

예를 들어 이렇게요.

"이 코드 리팩토링해줘. 기능 변경 없이 구조만 정리해. 파일 구조 바꿔야 할 것 같으면 그 시점에 한 번 물어봐."

혹은

"블로그 포스트 초안 써줘. 내용은 네가 채워도 되는데, 실제 사례나 수치가 필요한 부분은 빈칸으로 남겨놔."

이렇게 하면 흐름은 끊기지 않으면서, AI가 판단을 내리면 안 되는 지점만 표시가 되거든요.

핵심은 이거예요.

AI한테 "계속 해"를 시키려면, 내가 먼저 범위를 정해줘야 해요.

범위 없이 맡기는 건 AI한테 "알아서 판단해"를 허락하는 거거든요. 테스트 케이스 3,000개처럼, 그 판단이 전부 맞는 방향일 수도 있고 — 완전히 엉뚱한 곳만 전부 테스트하는 결과가 나올 수도 있어요.

사용자가 AI에게 작업 범위와 멈춤 조건을 지정하는 프롬프트 설계

---

결국 핵심은 하나예요

그 VP가 틀린 건 AI를 믿은 게 아니에요. AI한테 어디까지 맡길지를 정하지 않은 거예요.

저도 Claude 쓰면서 "알아서 해줘" 하고 싶은 순간이 많아요. 근데 그 전에 한 가지만 확인하게 됐어요.

"중간에 결정이 필요한 순간이 있나?"

있으면, 거기서 한 번 멈추게 해요. 없으면, 그냥 통째로 맡겨요.

이 기준 하나면 충분하더라고요.

AI를 잘 쓰는 건 많이 맡기는 게 아니에요. 어디까지 맡길지 아는 것이에요.