AI 코딩을 쓰면서 제일 많이 보는 착각이 있습니다. “일단 만들고 나중에 고치면 되지”라는 생각입니다. 사람 개발자만 있을 때도 위험한 말이었는데, AI가 붙으면 더 위험해집니다. 나중에 고칠 코드가 훨씬 빨리, 훨씬 많이 생기기 때문입니다.
SpecGuard 같은 도구가 주목받는 이유도 여기에 있습니다. AI가 코드를 못 짜서가 아닙니다. 애매한 요구사항을 너무 그럴듯하게 코드로 바꿔버리기 때문입니다. 사람이라면 회의에서 멈췄을 질문을 AI는 조용히 추측하고 지나갈 수 있습니다.
위험한 지점
AI는 빈칸을 싫어하지 않습니다. 오히려 빈칸을 자연스럽게 채웁니다. 문제는 그 추측이 코드가 되고, 코드는 나중에 운영 비용이 된다는 점입니다.

스펙 없는 코딩은 빠른 출발처럼 보여도, 나중에는 어두운 골목처럼 빠져나오기 어려워진다.
구현 전에 물어야 할 질문
내가 AI에게 구현을 맡기기 전에 최소한 확인하고 싶은 질문은 이런 것들입니다. 질문 자체는 지루하지만, 실제 서비스에서는 이런 질문들이 돈과 신뢰를 지킵니다.
- 이 기능은 누가 쓸 수 있나?
- 조직이나 계정이 바뀌면 접근 권한도 바뀌나?
- 같은 요청이 두 번 들어오면 중복 처리되나?
- 외부 API 실패 시 재시도하나, 그냥 실패하나?
- 사용자가 취소하거나 뒤로 가면 데이터는 어떻게 되나?
- 로그에 민감한 값이 남지는 않나?
이 질문들이 빠진 상태에서 “구현해줘”라고 하면 AI는 일단 만듭니다. 화면도 뜨고, 버튼도 눌리고, 설명도 붙습니다. 하지만 권한, 실패, 중복, 삭제 같은 운영 조건은 뒤늦게 드러납니다.
그럴듯한 코드가 더 오래 속인다
AI가 만든 코드는 처음 보면 차분합니다. 변수명도 괜찮고, 설명도 있고, 테스트까지 추가할 때도 있습니다. 그래서 더 쉽게 믿게 됩니다. 문제는 요구사항이 비어 있으면 그 빈칸도 차분하게 추측한다는 점입니다.
특히 권한, 결제, 파일, 알림, 웹훅, 동시성 같은 영역은 조심해야 합니다. 작은 예제에서는 다 잘 됩니다. 실제 운영에서만 터집니다. 그리고 운영에서 터지는 문제는 대개 “왜 이 경우를 생각 안 했지?”로 돌아옵니다.
AI에게 구현을 맡기기 전에 먼저 빈틈을 찾아달라고 시키는 습관이 필요합니다. “바로 구현하지 말고, 이 스펙에서 빠진 권한·실패·중복 처리 문제를 먼저 찾아줘.” 이 한 문장이 결과를 많이 바꿉니다.
AI 코딩의 위험은 느린 개발이 아니라 빠른 확신입니다. 속도는 분명 장점이지만, 스펙이 비어 있으면 그 속도는 부채를 찍어내는 기계가 됩니다.
스펙은 길게 쓰는 문서가 아니라 멈추게 하는 장치다
스펙이라고 하면 거창한 문서를 떠올리기 쉽습니다. 하지만 AI 코딩에서 필요한 스펙은 꼭 길 필요가 없습니다. 오히려 짧아도 명확해야 합니다. 누가 쓰는지, 무엇이 바뀌는지, 무엇은 바꾸면 안 되는지, 실패하면 어떻게 보이는지. 이 네 가지가 없으면 AI는 빈칸을 자기 방식으로 채웁니다.
| 사용자 | 이 기능을 누가 쓰는지 적습니다. 관리자, 일반 사용자, 비로그인 사용자를 섞으면 안 됩니다. |
| 성공 조건 | 무엇이 되면 성공인지 화면, API, 데이터 기준으로 적습니다. |
| 금지 조건 | 건드리면 안 되는 로직, 유지해야 하는 호환성, 삭제하면 안 되는 데이터를 적습니다. |
| 실패 조건 | 권한 없음, 중복 요청, 외부 API 실패, 입력 누락이 어떻게 처리되는지 적습니다. |
이 정도만 있어도 AI의 추측은 많이 줄어듭니다. 특히 금지 조건이 중요합니다. 사람은 “당연히 그건 안 건드리겠지”라고 생각하지만, AI에게 당연한 것은 없습니다. 말하지 않은 제약은 없는 제약처럼 처리될 수 있습니다.
AI에게 바로 코드보다 질문 목록을 먼저 받아야 한다
내가 실무에서 더 좋아하는 방식은 구현 전에 질문 목록을 받는 것입니다. “이 스펙으로 바로 구현하지 말고, 빠진 정책과 실패 케이스를 먼저 물어봐.” 이렇게 시키면 AI가 개발자처럼 행동하기 시작합니다. 코드를 쓰는 기계가 아니라 빈틈을 찾는 보조 리뷰어가 됩니다.
위험한 속도를 줄이는 문장
“구현 전에 빠진 권한, 실패, 중복, 삭제 조건부터 찾아줘.” AI 코딩을 시작할 때 이 문장을 먼저 던지면 사고 확률이 줄어듭니다.
내 결론은 단순합니다. AI에게 스펙 없이 코딩을 맡기면 빠르게 빚이 쌓인다. 구현이 빨라질수록 요구사항의 빈칸도 빨리 굳어집니다. 그래서 AI 코딩을 잘 쓰려면 코드를 많이 맡기는 것보다, 코드로 바뀌기 전의 모호함을 더 집요하게 잡아야 합니다.
'AI' 카테고리의 다른 글
| 노코드 AI 자동화 전에 먼저 정리해야 할 것들 (0) | 2026.06.17 |
|---|---|
| AI가 만든 UI가 묘하게 싼 티 나는 이유 (0) | 2026.06.17 |
| AI 메모리 도구가 많아진 진짜 이유 (0) | 2026.06.17 |
| 로컬 AI는 싸서가 아니라 덜 보내도 되니까 다시 중요해졌다 (0) | 2026.06.17 |
| Claude Code, 일 나누는 감각이 먼저다 (0) | 2026.06.17 |