4장: AI와 대화 전략

프롬프트를 잘 쓰는 것만큼, AI와 대화하는 방식도 결과에 큰 영향을 줍니다. 같은 작업을 시키더라도 어떤 순서로, 어떤 모드에서, 얼마나 많은 맥락을 주느냐에 따라 결과가 달라집니다.

한 번에 다 시키기 vs 단계별로 시키기

AI에게 일을 시키는 방식은 크게 두 가지입니다.

한 번에 다 시키기는 원하는 걸 한 프롬프트에 전부 담는 방식입니다.

투두 앱을 만들어줘.
할 일 추가, 완료 체크, 삭제 기능이 있고,
localStorage에 저장해서 새로고침해도 유지되게 해줘.
디자인은 흰 배경에 카드 스타일로.

범위가 명확하고 내가 원하는 게 확실할 때 빠릅니다.

단계별로 시키기는 하나씩 확인하면서 진행합니다.

먼저 투두 앱 화면 레이아웃만 만들어줘. 기능은 아직 넣지 마.

→ 결과 확인 →

좋아. 이제 할 일 추가 기능을 넣어줘.

→ 결과 확인 →

완료 체크와 삭제 기능도 추가해줘.

어떤 방식을 써야 할지 판단 기준은 이렇습니다.

작업 범위가 작고 명확하면 한 번에 시키세요. 여러 기능이 엮여 있거나, 중간 결과를 보면서 방향을 조정하고 싶거나, 잘못 만들어졌을 때 되돌리기 부담스러운 작업이면 단계별로 시키세요.

잘 모르겠으면 단계별이 안전합니다. 한 번에 많이 시킬수록 의도를 잘못 해석할 확률이 높아지고, 잘못된 결과를 되돌리는 데 시간이 더 듭니다.

Reverse Prompting — AI에게 먼저 질문하게 하기

보통은 내가 AI에게 지시합니다. Reverse prompting은 순서를 뒤집습니다. 내가 지시하기 전에, AI에게 먼저 질문하게 합니다.

중고 거래 플랫폼을 만들려고 해.
구현하기 전에 내가 뭘 빠뜨리고 있는지 확인하고 싶어.
물어봐줘.

그러면 AI가 이런 식으로 물어봅니다.

거래는 직거래인가요, 택배 거래인가요, 아니면 둘 다 지원하나요?

대답하면 다음 질문으로 넘어갑니다.

결제는 플랫폼 안에서 처리하나요, 아니면 사용자끼리 알아서 하나요?

이걸 몇 번 반복하면, 혼자서는 미처 생각하지 못했던 것들이 드러납니다. 직거래면 위치 기능이 필요하고, 플랫폼 결제면 에스크로가 필요하고, 둘 다 지원하면 분기 처리가 필요합니다. 질문에 답하다 보면 자연스럽게 요구사항이 정리됩니다.

언제 쓰면 좋은가

내가 뭘 원하는지 아직 정리가 안 됐을 때 씁니다. "이런 거 만들고 싶긴 한데…" 정도만 있고 세부 사항이 떠오르지 않을 때. 프롬프트 입력창 앞에서 뭘 써야 할지 막막할 때.

반대로, 원하는 게 이미 뚜렷하면 굳이 쓸 필요 없습니다. "버튼 색 빨간색으로 바꿔줘"에 reverse prompting을 붙이면 시간만 낭비합니다.

권한 모드 — AI에게 얼마나 맡길 것인가

Claude Code가 파일을 만들거나 명령어를 실행할 때 매번 "이거 해도 될까요?"라고 물어봅니다. 처음에는 이게 안전하게 느껴지지만, 작업에 집중하고 있을 때는 흐름이 끊깁니다.

권한 모드는 이 허락의 범위를 조절하는 설정입니다. "매번 물어봐"부터 "알아서 해"까지 단계가 있습니다.

바이브코더가 쓰는 네 가지 모드

모드	AI가 허락 없이 할 수 있는 것	언제 쓰나
Auto	작업에 맞는 권한을 AI가 선택	기본으로 쓰는 모드
Accept edits	파일 읽기 + 수정	조심스럽게 진행하고 싶을 때
Manual	파일 읽기만	처음 켜면 나오는 기본값
Plan	읽기 전용 탐색 (수정 없음)	큰 작업 전 계획을 먼저 볼 때
Bypass permissions	모든 것 (제한 없음)	완전 자동화가 필요할 때

Auto를 기본으로 쓰세요. AI가 작업 성격에 맞는 권한 수준을 스스로 판단합니다. 위험할 수 있는 작업은 자동으로 멈추고, 안전한 작업은 확인 없이 진행합니다. "이 기능 만들어줘"라고 하고 잠깐 자리를 비워도 됩니다.

Accept edits는 파일 수정까지 자동으로 진행하고, 명령어 실행(npm install 같은 것)만 허락을 구합니다. Auto보다 조심스럽게 보고 싶을 때 씁니다.

Manual은 파일을 읽는 것만 자동이고, 수정할 때마다 허락을 구합니다. 앱을 처음 켜면 이 모드입니다. 무엇이 바뀌는지 diff로 확인하고 승인할 수 있어서 처음에는 이 모드로 시작해보는 것도 좋습니다.

Plan은 코드를 직접 수정하지 않고 계획만 먼저 세웁니다. 다음 섹션에서 자세히 다룹니다.

Bypass permissions는 어떤 작업이든 확인 없이 바로 실행합니다. Auto와 달리 위험한 작업도 멈추지 않습니다. 확인 창 없이 완전히 자동으로 돌리고 싶을 때 선택할 수 있습니다.

모드 전환하기

프롬프트 창의 보내기 버튼 옆에 있는 모드 선택기에서 바꿉니다. Cmd+Shift+M(Windows는 Ctrl+Shift+M)을 눌러도 됩니다.

한 번 고른 모드는 폴더별로 기억합니다. Plan은 예외라서 지금 세션에만 적용됩니다.

Plan 모드

Plan 모드는 AI가 코드를 바로 작성하지 않고, 계획만 먼저 세우도록 하는 모드입니다. 복잡한 기능을 추가하기 전에, 또는 AI가 어떤 방향으로 접근할지 먼저 보고 싶을 때 유용합니다.

Plan 모드는 모드 선택기에서 Plan을 골라 전환합니다.

Plan 모드 실제 사용 흐름

(Plan 모드에서)
이 프로젝트에 Google 소셜 로그인을 추가하려고 해.
어떤 파일을 만들고 어떤 순서로 작업해야 하는지 계획을 세워줘.

AI가 코드 없이 계획만 작성합니다. 예를 들면 이런 식으로:

1. Google OAuth 연동 설정
2. 로그인 성공 후 처리
3. 로그인 버튼 UI
4. 로그인 안 한 사용자 접근 차단
순서: 1 → 2 → 3 → 4

Plan 모드는 복잡한 작업에 유용하지만, 작업 범위가 작고 명확할 때는 굳이 쓸 필요 없습니다. "버튼 색 바꿔줘" 같은 간단한 작업은 바로 시키는 게 빠릅니다.

ultrathink

프롬프트에 ultrathink를 포함하면 해당 요청에 한해서만 AI의 사고 깊이를 최대로 높입니다.

ultrathink. 이 인증 시스템의 보안 취약점을 찾아줘.

결제 로직에서 엣지 케이스가 뭐가 있을지 ultrathink해줘.

복잡한 아키텍처 결정, 잡기 어려운 버그, 트레이드오프 분석처럼 AI가 충분히 생각해야 하는 상황에서 씁니다. 그냥 쓰면 되고, 다음 요청부터는 다시 평소 수준으로 돌아옵니다.

세션 전체의 사고 깊이를 조정하고 싶으면 /effort를 입력합니다. low / medium / high 중 선택할 수 있습니다.

알아두면 좋은 슬래시 커맨드

Claude Code에는 /로 시작하는 명령어들이 있습니다. 대화 중 언제든 입력할 수 있습니다.

대화 관리:

/clear — 대화 내용을 전부 지우고 처음부터 시작합니다. 전혀 다른 작업을 시작할 때, 또는 AI가 같은 실수를 반복할 때 씁니다.

/compact — 지금까지의 대화를 요약해서 컨텍스트를 정리합니다. 같은 작업을 이어가는데 대화가 너무 길어졌을 때 씁니다. 요약 방향을 지정할 수도 있습니다.

/compact 인증 관련 변경 사항을 중심으로 요약해줘

/btw — 컨텍스트에 남기지 않고 잠깐 질문할 때 씁니다. 예를 들어 작업 중에 "아, 이 함수 이름이 뭐였더라" 같은 빠른 확인을 할 때 유용합니다. 답변이 대화 히스토리에 포함되지 않아 컨텍스트를 아낄 수 있습니다.

작업 관리:

/init — 프로젝트를 처음 시작할 때 씁니다. 프로젝트 구조를 분석하고 CLAUDE.md 파일을 자동으로 만들어줍니다. 5장에서 자세히 다룹니다.

/effort — thinking 깊이를 조정합니다. low / medium / high 선택.

되돌리기:

Esc — AI가 작업하는 도중에 멈춥니다. 맥락은 유지됩니다.

Esc 두 번 또는 /rewind — 되감기 메뉴가 열립니다. 이전 상태로 대화와 파일을 함께 되돌릴 수 있습니다. Claude Code는 작업할 때마다 체크포인트를 자동으로 저장하기 때문에, 여러 단계 전으로 돌아가는 것도 가능합니다.

정보 확인:

/cost — 현재 대화에서 사용한 토큰 수와 비용을 보여줍니다.

/help — 사용 가능한 모든 명령어 목록을 보여줍니다.

/model — 현재 사용 중인 모델을 바꿉니다.

AI가 틀렸을 때

AI는 틀립니다. 정상입니다. 중요한 건 어떻게 대응하느냐입니다.

에러 메시지가 나올 때

가장 간단한 방법은 에러 메시지를 그대로 붙여넣는 겁니다.

이런 에러가 나. 고쳐줘.

TypeError: Cannot read properties of undefined (reading 'map')
    at ProductList (/src/components/ProductList.jsx:12:20)

에러 메시지에는 어느 파일, 몇 번째 줄인지가 포함되어 있어서 AI가 정확하게 찾아서 수정할 수 있습니다.

결과가 원하는 것과 다를 때

화면을 캡처해서 붙여넣고 설명을 추가합니다.

[스크린샷 첨부]
버튼이 화면 오른쪽 끝에 붙어 있어. 가운데로 옮겨줘.

또는 구체적으로 어디가 다른지 말합니다.

메뉴가 모바일에서 겹쳐 보여.
화면 너비가 768px 이하일 때 햄버거 메뉴로 바뀌게 해줘.

같은 실수를 반복할 때

두 번 수정했는데도 같은 문제가 반복되면, 계속 요청을 추가하는 것보다 되돌리고 처음부터 다시 시작하는 게 나을 수 있습니다. 수정을 쌓을수록 코드가 복잡해지고, AI도 앞서 만든 것에 맞추려다 점점 꼬입니다.

1단계: Esc+Esc 또는 /rewind로 파일을 되돌립니다. 되감기 메뉴에서 작업을 시작하기 전 체크포인트를 선택하면 코드가 그 시점으로 돌아갑니다.

2단계: /clear로 대화를 초기화합니다. 오염된 맥락을 버리고 백지에서 시작합니다.

/clear

3단계: 이번에 파악한 것을 반영해서 더 구체적인 프롬프트로 다시 시작합니다.

상품 목록 페이지에서 상품이 없을 때 에러가 나.
데이터가 아직 안 불러와졌거나 비어있을 때도
에러 없이 빈 화면이 나오도록 처리해줘.

돌아가는 상태에서 다시 시작하는 것이 어설프게 고친 코드를 붙잡고 씨름하는 것보다 빠를 수 있습니다.

작업 중간에 멈추고 싶을 때

AI가 작업 중인데 방향이 잘못됐다 싶으면 Esc를 누릅니다. 대화 맥락은 유지되고 파일 수정만 멈춥니다.

"아, 이 방향이 아니었어"라고 생각했을 때 Esc+Esc 또는 /rewind로 되감기 메뉴를 열면 파일과 대화를 이전 상태로 되돌릴 수 있습니다.

컨텍스트 관리

컨텍스트란 AI가 현재 기억하고 있는 정보입니다. 지금까지 나눈 대화, AI가 읽은 파일, 실행한 명령어의 결과가 모두 포함됩니다.

AI는 코드는 읽지만 맥락은 모른다

Claude Code는 CLAUDE.md를 읽고, 필요하면 파일을 직접 열어서 프로젝트 구조를 파악합니다. 기술 스택이 뭔지, 어떤 파일이 있는지는 스스로 확인합니다.

하지만 이 작업을 왜 하는지, 어떤 제약이 있는지, 지금 어떤 상태인지는 코드를 읽어도 알 수 없습니다. 그건 여러분만 알고 있습니다.

"결제 버튼 추가해줘"라는 요청에서 AI가 코드를 아무리 읽어도 알 수 없는 것들이 있습니다. 이게 무료 플랜 사용자에게만 보여야 하는지, 특정 조건에서 비활성화돼야 하는지, 지금 있는 버튼을 교체하는 건지 새로 추가하는 건지. 이런 것들이 맥락입니다.

맥락이 결과의 질을 결정한다

같은 요청이라도 어떤 맥락을 주느냐에 따라 결과가 완전히 달라집니다.

에러 디버깅 예시를 보겠습니다.

맥락 없는 버전:

에러 고쳐줘.

맥락 있는 버전:

결제 완료 후 주문 내역 페이지로 리다이렉트가 안 돼.
결제 성공 콜백에서 router.push('/orders')를 호출하는데
아무 반응이 없어. 에러 메시지는 없고 그냥 결제 페이지에 머물러 있어.

첫 번째는 AI가 "어떤 에러인가요?"부터 되물어야 합니다. 두 번째는 바로 원인을 찾습니다.

기능 추가 예시도 비교해봅니다.

맥락 없는 버전:

검색 기능 만들어줘.

맥락 있는 버전:

일감 목록 페이지에 검색 기능을 추가하려고 해.
클라이언트명과 프로젝트명을 기준으로 실시간 필터링되게 해줘.
서버 요청 없이 이미 불러온 데이터 안에서 필터링하면 돼.

두 번째는 어느 페이지인지, 어떤 기준으로 검색하는지, 어떤 방식으로 동작해야 하는지를 알려줬습니다. AI가 코드를 확인한 뒤 바로 원하는 방향으로 만들 수 있습니다.

맥락으로 챙겨야 할 것은 세 가지입니다. 지금 어떤 상황인지(현재 상태), 왜 이걸 하는지(목적), 어떻게 동작해야 하는지(제약과 방향). 기술 스택이나 프로젝트 배경은 AI가 직접 파악합니다.

컨텍스트에는 한계가 있습니다. 대화가 너무 길어지면 처음에 한 말을 잊거나, 관련 없는 정보에 혼동을 일으키기 시작합니다.

한 대화에 하나의 작업

대화 하나에 기능 하나, 또는 버그 수정 하나를 담는 게 좋습니다.

대화가 길어질수록 AI의 성능이 떨어집니다. 로그인 기능을 만들고 나서 같은 대화에서 결제 기능까지 이어서 만들면, 앞쪽 대화와 맥락이 섞이면서 응답 품질이 낮아집니다.

다른 목적의 작업을 시작할 때는 /clear로 새 대화를 시작합니다.

현재 컨텍스트가 얼마나 찼는지는 /context로 확인할 수 있습니다. 전체 용량 대비 사용량을 보여주므로, 대화를 이어갈지 정리할지 판단할 때 유용합니다.

컨텍스트를 아끼는 방법

관계없는 작업 사이에 /clear를 씁니다. 투두 앱 작업을 마치고 이제 전혀 다른 랜딩 페이지를 만들 거라면, 이전 투두 앱 대화가 컨텍스트에 남아있을 이유가 없습니다.

같은 작업을 이어가는 중에 대화가 길어지면 /compact를 씁니다. AI가 지금까지의 대화를 요약해서 중요한 내용만 남기고 정리합니다.

잠깐 확인이 필요할 때 /btw를 씁니다. 컨텍스트에 기록을 남기지 않으므로, 단순 질문을 하더라도 컨텍스트가 커지지 않습니다.

에러 메시지는 텍스트로 붙여넣습니다. 스크린샷은 텍스트보다 컨텍스트를 훨씬 많이 차지합니다. 터미널 에러나 콘솔 로그는 복사해서 텍스트로 전달하는 게 낫습니다. 스크린샷은 UI 레이아웃 확인처럼 시각 정보가 꼭 필요할 때 씁니다.

매번 반복하는 맥락은 CLAUDE.md에 적어둡니다. 새 대화를 시작할 때마다 "이 프로젝트는 Supabase를 쓰고, 포트는 3000이고…"라고 매번 설명하면 그만큼 컨텍스트를 소모합니다. 적어두지 않으면 AI가 매번 스스로 파악해야 하는데, 이 과정에서도 컨텍스트를 사용합니다. CLAUDE.md에 한 번 적어두면 /clear 후에도 AI가 자동으로 읽습니다. 자세한 내용은 5장에서 다룹니다.

컨텍스트가 꽉 찼을 때

Claude Code가 자동으로 대화를 압축합니다. 이때 중요한 코드와 결정 사항을 우선 보존합니다. 압축 방식에 대해 직접 지시를 줄 수도 있습니다.

/compact 지금까지 만든 기능 목록과 데이터베이스 구조는 반드시 보존해줘

바이브코딩에서 사람의 역할

AI가 코드를 쓴다면, 사람은 무엇을 하는 걸까요?

방향을 정합니다. 무엇을 만들지, 어떤 기능이 필요한지, 어떤 순서로 만들지를 결정하는 건 여러분입니다. AI는 지시받은 걸 만들 뿐, 무엇을 만들어야 하는지는 모릅니다.

결과를 확인합니다. AI가 만든 것을 직접 써봅니다. 화면을 열어보고, 버튼을 클릭해보고, 엣지 케이스를 테스트해봅니다. AI는 코드를 만들고 나면 그게 실제로 잘 동작하는지 관심이 없습니다. 확인하는 건 여러분의 몫입니다.

판단합니다. "이 디자인이 사용자에게 직관적인가?", "이 기능이 정말 필요한가?", "이 에러가 지금 고쳐야 하는 건가?" 이 판단은 AI가 내릴 수 없습니다.

코드를 쓰는 능력이 AI로 대체되면서, 오히려 무엇을 만들지 결정하는 능력과 만들어진 것을 검증하는 능력이 더 중요해졌습니다. 바이브코딩은 코딩 능력이 없어도 된다는 게 아니라, 코딩 능력보다 제품을 보는 눈이 더 중요해졌다는 뜻입니다.

할루시네이션과 검증

AI는 가끔 틀린 정보를 자신 있게 말합니다. 이걸 할루시네이션이라고 합니다.

코딩에서 할루시네이션은 이런 식으로 나타납니다.

존재하지 않는 npm 패키지를 설치하려 합니다. (npm install react-magic-form 같은 것)
없는 API를 호출합니다. (함수 이름이나 파라미터가 실제와 다릅니다)
특정 버전에서 동작하지 않는 문법을 씁니다.
자신이 이미 만들었다고 생각하는 기능이 실제로는 없습니다.

AI가 "이렇게 하면 됩니다"라고 자신 있게 말해도, 실제로 에러가 나는 경우가 있습니다.

다행히 해결법은 단순합니다. 실행해보면 됩니다.

코드를 실행했을 때 에러가 나면 그걸 AI에게 보여주면 됩니다. 에러 메시지가 없는데 동작이 이상하면 그 증상을 설명합니다. Claude Code 환경에서는 AI가 직접 실행하고 에러를 보기 때문에, 할루시네이션이 생기면 AI 스스로 발견하고 수정하는 경우가 많습니다.

완전히 막는 방법은 없습니다. "AI가 만든 것도 직접 확인해봐야 한다"는 습관 하나면 충분합니다.

참고자료

컨텍스트 윈도우란? AI의 작업대 이해하기