AI 코딩에서 살아남는 법: 모래성 이론과 실전 생존 전략

3단계 워크플로우(리서치 → 계획 → 구현)만 알면 AI 코딩이 완벽해질까? 아니다. 실전에서는 예상 못 한 상황이 끊임없이 발생한다. AI가 엉뚱한 코드를 짜고, 컨텍스트가 터지고, 세션을 나눌지 이어갈지 고민하게 된다. 이 글에서는 현장에서 바로 쓸 수 있는 생존 전략을 정리한다.

1. 모래성 이론: 잘못된 코드 위에 절대 쌓지 마라

AI 코딩에서 가장 많은 시간을 잡아먹는 것은 잘못된 방향의 코드를 점진적으로 고치려는 시도다. 이것을 모래성 이론(Sandcastle Theory)이라 부른다.

전형적인 실패 패턴

AI가 만든 코드가 기대와 다를 때, 대부분의 개발자는 이렇게 한다.

AI가 엉뚱한 코드를 짬
    ↓
"이 부분 고쳐줘" (패치 1)
    ↓
"아, 여기도 문제야" (패치 2)
    ↓
"이것도 바꿔야 하네" (패치 3)
    ↓
"왜 전체가 더 망가졌지?!" 😱
    ↓
결국 처음부터 다시 ...
    ↓
총 소요 시간: 3시간+ (원래 30분이면 끝날 일)

이것이 바로 모래성 위에 벽돌을 쌓는 것이다. 기초가 모래인데, 아무리 벽돌을 예쁘게 올려도 결국 무너진다. 패치 1이 패치 2를 꼬이게 하고, 패치 2가 원래 있던 코드를 망가뜨리며, 3~4번 패치를 거치면 원본보다 더 엉망인 코드가 탄생한다.

올바른 대응법: 통째로 되돌리기

잘못된 방향을 감지하는 즉시, Git을 사용해 통째로 되돌려라.

# 방법 1: 마지막 커밋 이후의 모든 변경사항 취소
git checkout -- .

# 방법 2: 특정 커밋으로 리셋
git reset --hard HEAD~1

# 방법 3: 특정 커밋만 되돌리기
git revert abc1234

그리고 문제의 범위를 좁혀서 다시 시작한다.

❌ "전체 인증 시스템을 구현해줘"
   → 범위가 너무 넓어 방향을 잃기 쉽다

✅ "기존 세션 테이블을 활용해서 OAuth 콜백 핸들러만 먼저 구현해줘"
   → 범위가 좁고, 기존 코드와의 접점이 명확하다

판단 기준: 고칠 것인가, 되돌릴 것인가

상황	판단
오타, 변수명, 포맷팅 등 사소한 수정	✅ 패치
접근 방식은 맞지만 세부 구현이 다른 경우	✅ 패치
아예 잘못된 라이브러리나 패턴을 사용	🔄 되돌림
기존 코드 구조를 무시한 구현	🔄 되돌림
2번 이상 패치했는데 계속 문제가 생김	🔄 되돌림

경험 법칙: 2번 패치해도 안 잡히면, 3번째 패치를 시도하지 말고 되돌려라. 3번째 패치가 성공할 확률보다 되돌리고 다시 하는 것이 더 빠를 확률이 훨씬 높다.

2. 세션은 나누지 마라: 하나의 긴 세션 전략

"컨텍스트 윈도우가 차면 AI 성능이 떨어지니까 세션을 자주 나눠야 한다"는 미신이 있다. 결론부터 말하면 — 대부분의 경우 세션을 나누는 것이 더 나쁘다.

세션을 나누면 생기는 문제

세션 1: 리서치 단계
  "auth 모듈을 깊이 분석해서 research.md 작성해"
  → 30분 동안 코드를 읽고 분석하고 문서 작성
  → ✅ 완료

세션 2: 계획 단계 (새 세션)
  "research.md를 참고해서 plan.md 작성해"
  → AI: "research.md를 읽어보겠습니다..."
  → ⚠️ 세션 1에서 직접 코드를 읽으며 쌓은 이해도가 사라짐
  → 파일만 읽고, 행간의 맥락은 유실됨

세션을 나누면 AI가 이전 세션에서 코드를 직접 읽으며 쌓아올린 암묵적 이해가 통째로 사라진다. research.md에 적힌 명시적 정보는 남아있지만, 파일 구조를 탐색하며 느낀 "이 모듈은 이런 의도겠구나" 같은 문맥적 이해가 없어진다.

컨텍스트 압축(Auto-Compaction)을 믿어라

Claude Code는 세션 내 대화가 길어지면 오토 컴팩션(자동 압축)을 통해 오래된 대화를 요약한다. 이 메커니즘 덕분에 하나의 긴 세션에서도 맥락을 꽤 잘 유지한다.

게다가 우리의 워크플로우에서는 research.md와 plan.md가 영구적으로 프로젝트에 남아 있다. AI가 초반 대화를 잊더라도, 이 문서들을 다시 읽으면 된다. 이것이 채팅 기반이 아니라 문서 기반으로 작업하는 진짜 이유다.

긴 세션에서의 흐름:

초반 대화 (리서치)
  ↓
[자동 압축됨] ← 세부 내용은 요약되지만...
  ↓
research.md ← 리서치 결과는 파일로 영구 보존
plan.md     ← 계획도 파일로 영구 보존
  ↓
후반 대화 (구현)
  "plan.md 읽고 구현해" ← 문서가 있으므로 맥락 유실 없음

세션을 나눠야 하는 예외 상황

물론 세션을 나눠야 하는 경우도 있다.

상황	세션 판단
리서치 → 계획 → 구현이 하나의 흐름	✅ 하나의 세션
완전히 다른 기능을 새로 시작	🔄 새 세션
AI가 명백하게 혼란에 빠져 횡설수설	🔄 새 세션
이전 작업 결과물이 문서로 완벽하게 남아있음	🔄 새 세션도 가능

핵심은 "세션을 나누면 도움이 되는가?"를 기계적으로 판단하지 말고, "이전 세션의 이해도를 얼마나 보존할 수 있는가?"를 기준으로 판단하는 것이다.

3. 마법의 프롬프트는 없다

SNS에서 "이 프롬프트 하나면 완벽한 코드가 나옵니다!"라는 게시물을 본 적이 있을 것이다. 단언컨대 — 그런 것은 없다.

프롬프트 엔지니어링의 한계

❌ 사람들이 기대하는 것:
"완벽한 프롬프트" → 완벽한 결과물

✅ 실제로 작동하는 것:
"보통의 프롬프트" + 체계적인 워크플로우 → 완벽한 결과물

프롬프트의 표현에 집착하는 것은 나무를 보고 숲을 놓치는 것이다. "다음 지시를 단계별로 수행하세요"와 "아래 작업을 순차적으로 실행하세요"의 차이가 결과물을 좌우하지 않는다.

결과물을 좌우하는 것은 프롬프트 문구가 아니라 프로세스다.

진짜 차이를 만드는 것

차이를 만들지 않는 것	차이를 만드는 것
"역할을 부여하라" 패턴	코드를 짜기 전에 리서치 문서
"단계별로 사고하라" 패턴	계획을 검토하고 피드백하는 루프
프롬프트에 이모지 넣기	Git 되돌림 판단 기준
길고 구조화된 프롬프트	세션을 나누지 않는 전략

프롬프트 하나하나의 표현에 에너지를 쏟는 대신, "생각하는 것(기획)과 타이핑하는 것(코딩)을 분리하는 규율"에 에너지를 투자하라. 이 규율이 10개의 마법 프롬프트보다 낫다.

4. 실전 체크리스트: AI에게 일을 시키기 전에

매번 AI 코딩 세션을 시작하기 전, 이 체크리스트를 확인하라.

시작 전 체크리스트

□ 작업할 영역의 기존 코드를 AI가 리서치했는가?
□ 리서치 결과가 문서(research.md)로 남아있는가?
□ 구현 계획이 문서(plan.md)로 작성되었는가?
□ 계획 문서를 내가 직접 검토하고 피드백했는가?
□ "아직 구현하지 마"를 명시했는가?
□ 계획이 최종 승인되었는가?
□ Git 현재 상태가 깨끗한가? (되돌릴 수 있는가?)

작업 중 체크리스트

□ AI가 계획에 없는 파일을 건드리고 있지 않은가?
□ 패치가 2회를 넘기고 있지 않은가?
□ 방향이 잘못되었다면 즉시 되돌릴 준비가 되어 있는가?
□ 피드백은 구체적이고 짧은가? (스크린샷 활용)

작업 후 체크리스트

□ 계획 문서에 완료 표시가 되어있는가?
□ 빌드/테스트가 정상 통과하는가?
□ 기존 코드와의 일관성이 유지되는가?
□ 불필요한 중복 코드가 생기지 않았는가?

📝 요약 (치트시트)

전략	핵심 포인트
모래성 이론	잘못된 코드 위에 패치하지 마라. 2번 패치 실패 → 즉시 Git 되돌림
세션 관리	리서치→계획→구현은 하나의 세션. 문서가 컨텍스트 유실을 방지
프롬프트 진실	마법의 프롬프트는 없다. 기획과 코딩의 분리라는 규율만이 진짜 차이를 만든다
체크리스트	시작 전·중·후 체크리스트로 삽질 방지

한 줄 요약: AI 코딩의 적은 AI 성능이 아니라 인간의 규율 부족이다. 모래성 위에 쌓지 말고, 세션을 쪼개지 말고, 마법의 프롬프트를 찾지 마라. 대신 리서치하고, 계획하고, 검토하라. 지루하지만 — 이것만이 작동한다.