AI에 과의존하면 설계 근육이 줄어든다: 내가 다시 되찾은 사고 루프

이 글은 고백으로 시작한다. 나는 한 시기에 AI에게 설계와 구현을 동시에 넘기면서 스스로 프로세스를 설계하는 힘이 약해지는 걸 직접 겪었다.

그때의 나는 “생산성"을 얻었지만, 문제가 터졌을 때 문제를 정의하는 능력을 잃고 있었다.

내가 경험한 경고 신호

아래 징후가 보이면 이미 과의존 단계였다.

• 요구사항을 스스로 구조화하지 못하고 바로 프롬프트를 연다.
• 실패 원인을 파악하기 전에 “AI에게 고쳐달라"고 먼저 요청한다.
• 코드의 의도와 제약을 설명하지 못한다.

특히 결제나 권한처럼 도메인 규칙이 많은 영역에서 이 패턴은 치명적이었다.

참고: Martin Fowler는 AI 코딩 실무에서 시간이 지날수록 유지보수 구조가 핵심 병목이 된다고 지적한다. Spec-Driven Development: Tools

내가 바꾼 루틴: AI 앞에 먼저 설계 노트를 쓴다

과의존을 끊기 위해, AI 호출 전에 아래 4문장을 반드시 작성했다.

1. 문제: 지금 어떤 실패를 막아야 하는가
2. 제약: 무엇을 절대 깨면 안 되는가
3. 선택: 이번 변경에서 채택할 구조는 무엇인가
4. 검증: 실패 시 어떤 로그/지표로 탐지할 것인가

이 4문장을 못 쓰면, 그 작업은 AI가 아니라 내가 먼저 설계를 더 해야 하는 작업으로 분류했다.

참고: Rich Sutton의 The Bitter Lesson은 계산 자원을 활용하는 일반적 방법의 힘을 강조한다. 내 해석은 “AI에 전부 맡기라"가 아니라 “사람은 목표와 검증을 더 정교하게 맡아야 한다"였다. The Bitter Lesson

효과

이 습관을 붙인 뒤부터 체감이 달라졌다.

• 프롬프트 길이는 줄었고, 결과 일관성은 올라갔다.
• 에이전트 수정 횟수는 줄었고, 코드 설명 가능성은 올라갔다.
• “AI 없이는 못 한다"는 불안이 줄고, 선택적으로 활용하게 됐다.

참고: METR 연구 역시 숙련 개발자 맥락에서 AI가 항상 속도를 높이지는 않는다고 보고한다. 체감 생산성과 실제 산출을 분리해서 보는 습관이 필요하다. Early-2025 AI Productivity Study

정리

AI를 잘 쓰는 사람은 AI를 많이 호출하는 사람이 아니라 AI가 틀릴 때 빠르게 잡아내는 사람이다.

나는 지금도 바이브 코딩을 한다. 다만 순서를 바꿨다.

먼저 생각을 쓰고, 그다음 AI를 쓴다. 이 단순한 순서가 설계 근육을 지켜줬다.