AI에게 바로 시키지 말고, 사각지대부터 찾아라

요즘 모델은 꽤 똑똑하다. 그래서 오히려 실패 원인을 모델 탓으로만 돌리기 어려워졌다.

긴 작업이 엉뚱하게 돌아오면, 모델이 부족해서라기보다 내가 모르는 것을 제대로 꺼내지 않은 경우가 많다. 요구사항의 빈칸을 사람이 정리하지 않으면 AI가 그 빈칸을 자기 방식으로 채운다.

예를 들어 “인증 기능 만들어줘”라고 하면 AI가 알아서 판단해야 할 것이 너무 많다.

빠진 질문	왜 중요한가
어떤 로그인 방식인가	구현 구조가 달라진다
토큰 만료 시간은 얼마인가	보안과 사용성이 달라진다
기존 DB 구조는 어떤가	마이그레이션 방식이 달라진다
예외 처리는 어디까지인가	테스트와 사용자 흐름이 달라진다
화면 흐름은 어떻게 이어지는가	백엔드 설계까지 영향을 준다

이런 것을 정하지 않고 바로 구현시키면, 결과물은 그럴듯하지만 내 의도와 어긋날 수 있다.

먼저 사각지대를 찾게 한다

복잡한 작업을 맡길 때 첫 지시는 구현이 아니라 탐색이어야 한다.

바로 구현하지 말고, 내가 놓친 사각지대와 결정해야 할 질문부터 정리해줘.
아키텍처에 영향 큰 질문부터 하나씩 물어봐.
답이 정리되면 계획을 세우고, 구현 중 계획에서 벗어나는 부분은 기록해.
마지막에는 테스트나 스크린샷으로 제대로 됐는지 증명해줘.

이렇게 하면 AI가 단순 작업자가 아니라, 내가 놓친 조건을 드러내는 파트너가 된다.

네 가지 unknown

AI 작업에서 문제를 만드는 빈칸은 대략 네 종류다.

구분	의미	대응
known knowns	알고 있고 적어둔 것	그대로 지시한다
known unknowns	모른다는 것을 아는 것	질문으로 정리한다
unknown knowns	당연해서 안 쓴 것	예시와 레퍼런스로 드러낸다
unknown unknowns	생각조차 못 한 것	AI에게 사각지대 탐색을 시킨다

실력 차이는 여기서 난다. AI를 잘 쓰는 사람은 프롬프트를 길게 쓰는 사람이 아니라, 이 빈칸을 빨리 좁히는 사람이다.

말보다 프로토타입이 빠른 영역

UI, 디자인, 사용 흐름처럼 “보면 아는데 말로는 설명하기 어려운 것”은 바로 완성시키지 않는 편이 낫다.

먼저 간단한 HTML 시안이나 화면 방향을 몇 개 뽑아보고, 그중 맞는 방향을 고르는 게 싸다. 구현이 깊어진 뒤 “이 느낌이 아닌데”를 발견하면 되돌리는 비용이 커진다.

끝났다는 증거를 요구한다

AI는 “완료했습니다”라고 쉽게 말한다. 하지만 실제 완료 여부는 증거로 확인해야 한다.

작업	완료 증거
코드 수정	테스트 결과
UI 변경	스크린샷
긴 구현	변경 요약과 검증 로그
사용 흐름	짧은 데모 또는 재현 절차
설계 변경	결정 기록과 남은 리스크

완료 조건이 없으면 에이전트는 어디서 멈춰야 하는지 흐릿해진다. 그래서 테스트, 스크린샷, 데모, 리뷰용 문서처럼 닫는 기준을 미리 줘야 한다.

한 줄 정리

AI에게 일을 잘 시키는 핵심은 더 멋진 프롬프트가 아니다.

먼저 내가 뭘 모르는지 드러내고, 그 빈칸을 AI와 같이 줄이는 것이다.