이렇게 질문할 것입니다
Vibe Coding 방법론 · 6가지 핵심 질문
AI로 코드를 작성하는 것만큼 의구심을 불러일으키는 일도 없습니다. 이 6가지 질문은 세 가지 실제 시나리오에서 나왔으며, 대부분은 상사와 개발 동료에게서 옵니다. 프레임워크를 보기 전에 먼저 스스로 답해 보세요.
이 페이지 활용법
각 질문에는 질문자가 표시되어 있습니다. 모두 같은 AI 협업 가이드라인을 보고 있지만, 각자 듣고 싶은 내용은 다릅니다.
🎙 면접관실제로 사용해 봤는지, 아니면 글 몇 편만 읽었는지 확인하고 싶어 합니다
👔 상사품질, 책임, 사고를 걱정합니다
🛠 개발 동료엔지니어링을 이해하는지, 권한을 줄 만한지 탐색합니다
각 질문은 세 가지 레이어로 구성됩니다: 무엇을 테스트하는가 → 답변 프레임워크 → 가산점. 답하기 어려운 부분은 하단 링크된 강좌 페이지를 확인하세요.
Q1면접관
「이력서에 Vibe Coding이 능숙하다고 써 있네요. AI가 코드를 다 쓰는데, 왜 규칙을 잔뜩 세우는 건가요?」
🎯 무엇을 테스트하는가
도입 정의 질문입니다. 사고로 말할 수 있는가를 테스트합니다. "가이드라인이 중요하다"만 말하는 사람은 공식을 암송하는 것이며, 실제로 문제를 겪은 사람은 즉시 구체적인 사고와 그에 대응하는 규칙을 말합니다. "AI가 가끔 실수하니 주의해야 한다"는 기술적으로 맞지만 아무것도 드러내지 않습니다.
🧭 답변 프레임워크
- Vibe Coding이 무엇인지 먼저 정의하세요: 자연어로 AI가 직접 코드를 생성하게 하는 개발 방식입니다. 문제는 항상 품질에 있으며, 빠르게 만드는 것은 실수의 속도만 증폭시킵니다.
- 네 가지 전형적인 사고를 제시하세요: 오해로 인한 재작업(7개 파일 수정 후에야 접근법이 잘못됐다는 걸 발견), 스택 드리프트(오늘은 Express, 내일은 Fastify), 선의의 파괴(리팩토링 중 유효한 코드 삭제), 영구 기술 부채(간이 로그인이 결코 업그레이드되지 않음).
- 공통 근본 원인을 짚어내세요: 네 가지 모두 같은 문제에서 비롯됩니다 — 제약이 컨텍스트에 들어가지 않은 것입니다. AI는 매 대화 턴마다 이전에 말한 것을 잊어버릴 수 있습니다.
- 해결책을 제시하세요: 제약을 Rule 파일에 작성하여 매 대화 시작 시 자동으로 로드되게 합니다. 대화에서 말한 것은 컨텍스트 창 밖으로 밀려나고, 문서에 쓴 것은 AI가 읽지 않을 수도 있으며, Rule만이 구조적으로 가장 안정적인 주입 채널입니다.
⭐ 가산점 규칙 생성 논리를 추가하세요: AI가 같은 실수를 반복할 때마다 그것을 규칙으로 만듭니다. 규칙의 가치는 각각이 실제 문제를 해결한다는 데 있으며, 조항을 쌓는 것 자체는 의미가 없습니다. 이것은 방법을 이해하고 있음을 보여주며, 암기할 가치가 있습니다.
Q2상사
「AI가 코드를 다 작성하면, 버그가 생겼을 때 누구 책임인가요? AI인가요, 당신인가요? 품질에 대해 책임질 수 있나요?」
🎯 무엇을 테스트하는가
상사는 명확한 책임 소재와 품질 메커니즘을 원합니다. "AI가 생성한 것은 모두 검토합니다"라는 답변은 메커니즘이 없는 것과 같으며, AI에게 책임을 돌리는 것은 더 나쁩니다 — 프로세스가 통제 불가능하다는 것을 인정하는 셈입니다. 상사가 듣고 싶은 것은: 책임은 사람에게 있으며, 구체적인 체크포인트가 그 책임을 실제로 질 수 있게 보장한다는 것입니다.
🧭 답변 프레임워크
- 먼저 책임을 받아들이세요: 버그는 항상 사람의 책임입니다 — AI는 도구입니다. 이 프레임워크의 목적은 모든 핵심 노드에서 사람이 승인할 기회를 주고, 문제 발생 시 어느 관문에서 통과시켰는지 추적할 수 있게 하는 것입니다.
- 사전 체크포인트를 제시하세요: 중단점은 코딩 시작 전에 설정됩니다. AI는 코드 작성 전에 요구사항을 다시 말하고, PRD를 작성하고, 명시적인 승인을 받아야 합니다; 3개 이상의 파일 변경은 수정 계획서를 먼저 제출해야 합니다. 오해는 첫 번째 코드 라인 작성 전에 차단됩니다.
- 납품 기준선을 제시하세요: 두 가지 필수 확인 사항. AI API를 사용하는 기능은 실제로 호출되어야 하며 Mock으로 우회하는 것은 금지됩니다; 핵심 로직 단위 테스트가 통과해야만 납품이 가능합니다.
- 사후 처리 프로토콜을 제시하세요: 실제 버그가 발생하면 추측성 수정은 금지됩니다. 먼저 로그를 추가하여 근본 원인을 파악하고, 수정 전에 세 가지 질문에 답하세요(완전한 비즈니스 플로우, 영향받는 모듈, 유사한 문제 유무), 수정 후 영향 범위를 선언하고 회귀 테스트 위치를 명확히 합니다.
⭐ 가산점 자발적으로 데이터 비교를 제시하세요: 추측성 수정 3라운드, 47줄 변경, 버그 여전히 존재; 로그 1라운드로 근본 원인 파악, 버그 해결. 로그 추가 2분이 3라운드 틀린 재작업을 대체합니다. 상사는 이 계산을 이해할 것입니다.
Q3개발 동료
「PM도 AI가 생성한 코드를 바로 merge하는 건가요? 한 번에 파일 십여 개를 바꾸면 누가 다 검토하나요?」
🎯 무엇을 테스트하는가
개발 동료는 당신에게 프로세스 인식이 있는지를 탐색합니다. 진짜 두려워하는 것은 통제되지 않는 대규모 변경입니다. "AI는 이제 정말 강력해서 거의 실수 안 해요"라고 답하면 그들은 다시는 당신을 저장소 근처에 가게 하지 않을 것입니다; 구체적인 중단점 메커니즘으로 답하면 당신을 동료로 여기기 시작할 것입니다.
🧭 답변 프레임워크
- 먼저 전제를 수정하세요: "바로 merge"는 없습니다. AI가 시작하기 전에 4단계 프로세스를 거쳐야 합니다: 질문을 깊이 생각하고, 자신의 이해로 요구사항을 다시 말하고, PRD를 작성하고, 명시적인 승인을 받은 후에야 코딩합니다. 사람이 승인하지 않으면 코드는 생성되지 않습니다.
- 대규모 변경에 직접 답하세요: 3개 이상의 파일을 수정하면 먼저 수정 계획서를 제출해야 합니다 — 어떤 파일을, 각 파일에서 무엇을 변경하는지, 변경 간 의존성을 명확히 씁니다. 계획서를 검토하는 것이므로 양이 아무리 많아도 관리 가능합니다.
- 범위 제한 규칙을 추가하세요: 새 기능 추가 전에 프로젝트에 유사한 구현이 있는지 검색하여 중복 작업을 방지합니다; 새 컴포넌트는 먼저 PlayGround에서 독립 데모를 만들고, 동작 확인 후 메인 프로젝트에 통합합니다.
- 규칙이 명시적이어야 하는 이유를 설명하세요: "코딩 전에 이해를 확인해 주세요" 같은 모호한 지시는 효과가 없습니다 — AI는 "이해했다"고 자체 판단하고 진행합니다. "PRD 작성, 승인 대기" 같은 구체적인 행동을 명시해야 중단점이 실제로 존재합니다.
⭐ 가산점 임계값의 엔지니어링 판단을 말하세요: 파일 3개는 경험치 — 신중한 프로젝트는 1로 설정하고, 빠른 프로토타입은 5까지 완화합니다. 단순한 한 줄 변경은 AI가 스스로 PRD를 건너뛰도록 합니다; 규칙은 재작업 비용이 가장 높은 멀티파일 변경을 잡습니다. 임계값이 조정 가능하다는 것을 아는 것은 실제 프로젝트에서 사용했다는 증거입니다.
Q4상사
「AI가 간이 버전을 먼저 출시하면 이틀 안에 뭔가 보여줄 수 있다고 했어요. 실용적인 것 같은데, 왜 막는 건가요?」
🎯 무엇을 테스트하는가
상사가 AI 편에 섰습니다 — 설득해야 할 것은 사람입니다. 이 질문은 기술 부채를 상사가 이해할 수 있는 비용 계산으로 번역할 수 있는지를 테스트합니다. "좋아요, 간이 버전 먼저 출시하죠"라고 동의하면 기술 부채의 공범이 됩니다; "기술 부채가 생길 것입니다"만 말하는 것은 너무 막연합니다 — 상사는 숫자를 원합니다.
🧭 답변 프레임워크
- 먼저 동기를 폭로하세요: AI가 "간이 버전 먼저"를 제안하는 것은 복잡도와 무관할 때가 많습니다 — 빠르게 실행 가능한 것을 주고 긍정적인 피드백을 얻으려는 것입니다. "임시 방안 사용", "일단 Mock으로", "간단하게 처리" — 모두 같은 패턴입니다.
- 비용 계산을 제시하세요: 출시 당일 완성하면 0.5× 비용; 30일 후 4개 모듈이 간이 API에 의존하면 완성 비용 3×; 90일 후 9개 모듈이 긴밀하게 결합되면 8× 비용이 전체 재작성을 초과합니다. "나중에 최적화"는 결코 오지 않습니다.
- 규칙을 제시하세요: 어떤 이유로도 구현을 단순화하는 것은 금지되며, AI가 단계별 납품이나 MVP를 자발적으로 계획하는 것도 금지됩니다. 모든 구현은 완전하고, 올바르고, 기술 부채가 없어야 합니다.
- 선택권을 상사에게 돌려주세요: 기능이 실제로 너무 복잡할 때, 올바른 행동은 AI에게 완전한 방안, 실제 작업량, 사전 결정 목록을 제시하게 하고 사람이 분할 여부와 방법을 결정하게 하는 것입니다. 분할은 사람의 결정이고, 다운그레이드는 AI의 독단입니다.
⭐ 가산점 역직관적인 현상을 지적하세요: "간이 버전 먼저" 패턴을 깨면 AI는 오히려 완전한 방안을 더 신중하게 분석합니다. 이 통찰은 실제 사용에서 나온 것이며, 말할 수 있으면 대부분의 후보자를 앞섭니다.
Q5개발 동료
「지난달에 그 기능이 왜 지금처럼 바뀐 건지 아직 설명할 수 있나요? AI 대화를 닫으면 모든 의사결정이 사라지는 거 아닌가요?」
🎯 무엇을 테스트하는가
이것은 Vibe Coding의 유지보수성에 대한 치명적인 질문입니다. 대화형 개발의 결정은 기본적으로 채팅 기록에 잠겨 있으며, 세 달 후 git log를 아무리 뒤져도 복구할 수 없습니다. "채팅 기록을 확인해 볼게요"라고 답하는 것은 보존 메커니즘이 없다는 것을 인정하는 것입니다; 문서 체계를 설명할 수 있어야 AI 협업을 진정한 엔지니어링으로 하고 있다는 것을 보여줄 수 있습니다.
🧭 답변 프레임워크
- 문제를 인정하고 메커니즘을 제시하세요: 결정은 실제로 대화 기록에 의존할 수 없으므로, AI에게 엄격한 템플릿으로 문서를 유지하게 하여 결정이 대화와 시간을 넘어 생존하게 합니다.
- 세 가지 문서와 역할을 말하세요: FEATURES는 "이 기능이 어떻게 현재 상태가 됐는가"에 답합니다 — 상태 전환과 이력, 변경 사항과 이유 모두 기록됩니다; CHANGELOG는 "이번 릴리스에서 무엇이 바뀌었는가"에 답합니다 — 근본 원인과 영향 범위; RELEASE_NOTES는 "사용자가 무엇을 받았는가"에 답합니다.
- 취향 보존 문서를 추가하세요: METHODOLOGY.md는 제품 원칙, 설계 결정, UX 선호도, 반패턴을 기록합니다. 사용자가 모달 팝업 방안을 거부하면 AI가 반패턴으로 기록하고, 새 대화에서 자동으로 상속되어 같은 제안이 두 번 나오지 않습니다.
- 저장소에 있어야 하는 이유를 설명하세요: Notion이나 Feishu에 쓴 결정은 AI가 읽을 수 없습니다. 프로젝트 저장소 내의 Markdown 파일만이 AI가 매번 자동으로 컨텍스트를 가져오게 합니다.
⭐ 가산점 쉽게 간과되는 두 가지 규칙을 추가하세요: CHANGELOG 작성 전에 시스템 시간을 읽어야 합니다 — 기억으로 타임스탬프를 채우거나 나중에 몰아서 쓰는 것은 금지됩니다; 코드 주석은 세 가지 요소(배경, 설계 의도, 핵심 제약)를 필요로 합니다 — 주석은 다음 대화의 AI를 위해 쓰는 것이기도 합니다.
Q6상사
「AI가 데이터베이스를 삭제한 뉴스를 본 적 있어요. 이렇게 하다가 언젠가 AI가 프로덕션 DB를 날려버리면 어쩌려고요?」
🎯 무엇을 테스트하는가
상사는 안심감을 원합니다. "AI는 그런 짓 안 해요"는 최악의 답변입니다 — AI는 실제로 합니다: 선의의 정리, 릴리스에 섞인 임시 변경, 모두 실제 발생한 사고들입니다. 올바른 접근은 위험을 인정하고 관문을 하나씩 제시하는 것입니다.
🧭 답변 프레임워크
- 먼저 마스터 원칙을 제시하세요: 비가역적 작업의 안전감은 관문에서 옵니다. 데이터베이스, 설정, 배포 같은 작업은 모든 관문이 실행 전에 설정됩니다.
- 세 관문을 말하세요: 관문 1 — 백업: 백업 없이는 migrate, drop, alter, delete 어떤 것도 실행할 수 없으며, 백업은 타임스탬프와 함께 backups/ 디렉토리에 저장, 비용은 명령어 한 줄, 걸려 있는 것은 전체 DB. 관문 2 — 롤백: 실행 전에 복구 방법, 필요한 백업, 예상 복구 시간을 명확히 합니다. 관문 3 — 감사: 릴리스 전에 SubAgent가 실제 diff와 Release Notes를 비교 — 무관한 변경이 섞이면 릴리스 중단.
- 릴리스 규율을 추가하세요: 릴리스는 반드시 GitHub를 통해야 하며, 서버는 git pull 또는 CI/CD로 코드를 가져옵니다. 사용자가 명시적으로 확인하기 전에 tag 생성, push, 배포는 모두 금지됩니다 — AI는 자체적으로 릴리스할 권한이 없습니다.
- 자격 증명도 관리하세요: 모든 Key는 환경 변수나 secrets로 관리하며, 하드코딩은 금지됩니다. Key가 한번 git 기록에 들어가면 영구적으로 노출된 것과 같으며, 폐기하고 재발급해야 합니다.
⭐ 가산점 diff 감사의 설계 의도를 설명하세요: 전문 팀은 CI/CD와 PR review로 불량 릴리스를 차단하고, 독립 개발자는 종종 review를 건너뛰고 직접 push합니다. SubAgent가 reviewer 역할을 하는 것은 그 공백을 채우는 것입니다. 이 점을 설명할 수 있으면 규칙 이면의 엔지니어링 직관을 이해하고 있음을 보여줍니다.
마지막 조언
이 6가지 질문을 준비하는 가장 좋은 방법은 실제 프로젝트에 적용해 보는 것입니다: xs_vibe_rules를 프로젝트에 넣고 2주 동안 사용해 보세요. 사고와 규칙이 모두 당신 자신의 이야기가 됩니다. 이야기가 있는 답변과 프레임워크를 암송하는 답변의 차이는 면접관이 순식간에 알아챕니다.