이렇게 당신을 테스트합니다

Vibe Coding 방법론 · 30가지 핵심 질문

AI로 코드를 작성하는 것만큼 의구심을 불러일으키는 일도 없습니다. 이 30가지 질문은 세 가지 실제 시나리오에서 나왔으며, 대부분은 상사와 개발 동료에게서 옵니다. 프레임워크를 보기 전에 먼저 스스로 답해 보세요.

이 페이지 활용법
각 질문에는 질문자가 표시되어 있습니다. 모두 같은 AI 협업 가이드라인을 보고 있지만, 각자 듣고 싶은 내용은 다릅니다.
🎙 면접관실제로 사용해 봤는지, 아니면 글 몇 편만 읽었는지 확인하고 싶어 합니다
👔 상사품질, 책임, 사고를 걱정합니다
🛠 개발 동료엔지니어링을 이해하는지, 권한을 줄 만한지 탐색합니다
각 질문은 세 가지 레이어로 구성됩니다: 무엇을 테스트하는가 → 답변 프레임워크 → 가산점. 답하기 어려운 부분은 하단 링크된 강좌 페이지를 확인하세요.
Q1면접관
「이력서에 Vibe Coding이 능숙하다고 써 있네요. AI가 코드를 다 쓰는데, 왜 규칙을 잔뜩 세우는 건가요?」
🎯 무엇을 평가하는가
도입 정의 질문입니다. 사고로 말할 수 있는가를 테스트합니다. "가이드라인이 중요하다"만 말하는 사람은 공식을 암송하는 것이며, 실제로 문제를 겪은 사람은 즉시 구체적인 사고와 그에 대응하는 규칙을 말합니다. "AI가 가끔 실수하니 주의해야 한다"는 기술적으로 맞지만 아무것도 드러내지 않습니다.
🧭 답변 프레임워크
  1. Vibe Coding이 무엇인지 먼저 정의하세요: 자연어로 AI가 직접 코드를 생성하게 하는 개발 방식입니다. 문제는 항상 품질에 있으며, 빠르게 만드는 것은 실수의 속도만 증폭시킵니다.
  2. 네 가지 전형적인 사고를 제시하세요: 오해로 인한 재작업(7개 파일 수정 후에야 접근법이 잘못됐다는 걸 발견), 스택 드리프트(오늘은 Express, 내일은 Fastify), 선의의 파괴(리팩토링 중 유효한 코드 삭제), 영구 기술 부채(간이 로그인이 결코 업그레이드되지 않음).
  3. 공통 근본 원인을 짚어내세요: 네 가지 모두 같은 문제에서 비롯됩니다 — 제약이 컨텍스트에 들어가지 않은 것입니다. AI는 매 대화 턴마다 이전에 말한 것을 잊어버릴 수 있습니다.
  4. 해결책을 제시하세요: 제약을 Rule 파일에 작성하여 매 대화 시작 시 자동으로 로드되게 합니다. 대화에서 말한 것은 컨텍스트 창 밖으로 밀려나고, 문서에 쓴 것은 AI가 읽지 않을 수도 있으며, Rule만이 구조적으로 가장 안정적인 주입 채널입니다.
⭐ 가산점 규칙 생성 논리를 추가하세요: AI가 같은 실수를 반복할 때마다 그것을 규칙으로 만듭니다. 규칙의 가치는 각각이 실제 문제를 해결한다는 데 있으며, 조항을 쌓는 것 자체는 의미가 없습니다. 이것은 방법을 이해하고 있음을 보여주며, 암기할 가치가 있습니다.
이 강의 페이지로 답변을 구성하세요 → AI에게 규칙을 설정해야 하는 이유 규칙의 가치: 각각이 실제 문제를 해결
Q2상사
「AI가 코드를 다 작성하면, 버그가 생겼을 때 누구 책임인가요? AI인가요, 당신인가요? 품질에 대해 책임질 수 있나요?」
🎯 무엇을 평가하는가
상사는 명확한 책임 소재와 품질 메커니즘을 원합니다. "AI가 생성한 것은 모두 검토합니다"라는 답변은 메커니즘이 없는 것과 같으며, AI에게 책임을 돌리는 것은 더 나쁩니다 — 프로세스가 통제 불가능하다는 것을 인정하는 셈입니다. 상사가 듣고 싶은 것은: 책임은 사람에게 있으며, 구체적인 체크포인트가 그 책임을 실제로 질 수 있게 보장한다는 것입니다.
🧭 답변 프레임워크
  1. 먼저 책임을 받아들이세요: 버그는 항상 사람의 책임입니다 — AI는 도구입니다. 이 프레임워크의 목적은 모든 핵심 노드에서 사람이 승인할 기회를 주고, 문제 발생 시 어느 관문에서 통과시켰는지 추적할 수 있게 하는 것입니다.
  2. 사전 체크포인트를 제시하세요: 중단점은 코딩 시작 전에 설정됩니다. AI는 코드 작성 전에 요구사항을 다시 말하고, PRD를 작성하고, 명시적인 승인을 받아야 합니다; 3개 이상의 파일 변경은 수정 계획서를 먼저 제출해야 합니다. 오해는 첫 번째 코드 라인 작성 전에 차단됩니다.
  3. 납품 기준선을 제시하세요: 두 가지 필수 확인 사항. AI API를 사용하는 기능은 실제로 호출되어야 하며 Mock으로 우회하는 것은 금지됩니다; 핵심 로직 단위 테스트가 통과해야만 납품이 가능합니다.
  4. 사후 처리 프로토콜을 제시하세요: 실제 버그가 발생하면 추측성 수정은 금지됩니다. 먼저 로그를 추가하여 근본 원인을 파악하고, 수정 전에 세 가지 질문에 답하세요(완전한 비즈니스 플로우, 영향받는 모듈, 유사한 문제 유무), 수정 후 영향 범위를 선언하고 회귀 테스트 위치를 명확히 합니다.
⭐ 가산점 자발적으로 데이터 비교를 제시하세요: 추측성 수정 3라운드, 47줄 변경, 버그 여전히 존재; 로그 1라운드로 근본 원인 파악, 버그 해결. 로그 추가 2분이 3라운드 틀린 재작업을 대체합니다. 상사는 이 계산을 이해할 것입니다.
이 강의 페이지로 답변을 구성하세요 → 디버깅 철칙: 로그 먼저, 코드 수정은 나중에 4단계 프로세스: 복술·PRD·확인·코딩 AI에게 규칙을 설정해야 하는 이유
Q3개발 동료
「PM도 AI가 생성한 코드를 바로 merge하는 건가요? 한 번에 파일 십여 개를 바꾸면 누가 다 검토하나요?」
🎯 무엇을 평가하는가
개발 동료는 당신에게 프로세스 인식이 있는지를 탐색합니다. 진짜 두려워하는 것은 통제되지 않는 대규모 변경입니다. "AI는 이제 정말 강력해서 거의 실수 안 해요"라고 답하면 그들은 다시는 당신을 저장소 근처에 가게 하지 않을 것입니다; 구체적인 중단점 메커니즘으로 답하면 당신을 동료로 여기기 시작할 것입니다.
🧭 답변 프레임워크
  1. 먼저 전제를 수정하세요: "바로 merge"는 없습니다. AI가 시작하기 전에 4단계 프로세스를 거쳐야 합니다: 질문을 깊이 생각하고, 자신의 이해로 요구사항을 다시 말하고, PRD를 작성하고, 명시적인 승인을 받은 후에야 코딩합니다. 사람이 승인하지 않으면 코드는 생성되지 않습니다.
  2. 대규모 변경에 직접 답하세요: 3개 이상의 파일을 수정하면 먼저 수정 계획서를 제출해야 합니다 — 어떤 파일을, 각 파일에서 무엇을 변경하는지, 변경 간 의존성을 명확히 씁니다. 계획서를 검토하는 것이므로 양이 아무리 많아도 관리 가능합니다.
  3. 범위 제한 규칙을 추가하세요: 새 기능 추가 전에 프로젝트에 유사한 구현이 있는지 검색하여 중복 작업을 방지합니다; 새 컴포넌트는 먼저 PlayGround에서 독립 데모를 만들고, 동작 확인 후 메인 프로젝트에 통합합니다.
  4. 규칙이 명시적이어야 하는 이유를 설명하세요: "코딩 전에 이해를 확인해 주세요" 같은 모호한 지시는 효과가 없습니다 — AI는 "이해했다"고 자체 판단하고 진행합니다. "PRD 작성, 승인 대기" 같은 구체적인 행동을 명시해야 중단점이 실제로 존재합니다.
⭐ 가산점 임계값의 엔지니어링 판단을 말하세요: 파일 3개는 경험치 — 신중한 프로젝트는 1로 설정하고, 빠른 프로토타입은 5까지 완화합니다. 단순한 한 줄 변경은 AI가 스스로 PRD를 건너뛰도록 합니다; 규칙은 재작업 비용이 가장 높은 멀티파일 변경을 잡습니다. 임계값이 조정 가능하다는 것을 아는 것은 실제 프로젝트에서 사용했다는 증거입니다.
이 강의 페이지로 답변을 구성하세요 → 4단계 프로세스: 복술·PRD·확인·코딩 PlayGround: 컴포넌트 피팅룸
Q4상사
「AI가 간이 버전을 먼저 출시하면 이틀 안에 뭔가 보여줄 수 있다고 했어요. 실용적인 것 같은데, 왜 막는 건가요?」
🎯 무엇을 평가하는가
상사가 AI 편에 섰습니다 — 설득해야 할 것은 사람입니다. 이 질문은 기술 부채를 상사가 이해할 수 있는 비용 계산으로 번역할 수 있는지를 테스트합니다. "좋아요, 간이 버전 먼저 출시하죠"라고 동의하면 기술 부채의 공범이 됩니다; "기술 부채가 생길 것입니다"만 말하는 것은 너무 막연합니다 — 상사는 숫자를 원합니다.
🧭 답변 프레임워크
  1. 먼저 동기를 폭로하세요: AI가 "간이 버전 먼저"를 제안하는 것은 복잡도와 무관할 때가 많습니다 — 빠르게 실행 가능한 것을 주고 긍정적인 피드백을 얻으려는 것입니다. "임시 방안 사용", "일단 Mock으로", "간단하게 처리" — 모두 같은 패턴입니다.
  2. 비용 계산을 제시하세요: 출시 당일 완성하면 0.5× 비용; 30일 후 4개 모듈이 간이 API에 의존하면 완성 비용 3×; 90일 후 9개 모듈이 긴밀하게 결합되면 8× 비용이 전체 재작성을 초과합니다. "나중에 최적화"는 결코 오지 않습니다.
  3. 규칙을 제시하세요: 어떤 이유로도 구현을 단순화하는 것은 금지되며, AI가 단계별 납품이나 MVP를 자발적으로 계획하는 것도 금지됩니다. 모든 구현은 완전하고, 올바르고, 기술 부채가 없어야 합니다.
  4. 선택권을 상사에게 돌려주세요: 기능이 실제로 너무 복잡할 때, 올바른 행동은 AI에게 완전한 방안, 실제 작업량, 사전 결정 목록을 제시하게 하고 사람이 분할 여부와 방법을 결정하게 하는 것입니다. 분할은 사람의 결정이고, 다운그레이드는 AI의 독단입니다.
⭐ 가산점 역직관적인 현상을 지적하세요: "간이 버전 먼저" 패턴을 깨면 AI는 오히려 완전한 방안을 더 신중하게 분석합니다. 이 통찰은 실제 사용에서 나온 것이며, 말할 수 있으면 대부분의 후보자를 앞섭니다.
이 강의 페이지로 답변을 구성하세요 → 단계별 납품 불수용 4단계 프로세스: 복술·PRD·확인·코딩
Q5개발 동료
「지난달에 그 기능이 왜 지금처럼 바뀐 건지 아직 설명할 수 있나요? AI 대화를 닫으면 모든 의사결정이 사라지는 거 아닌가요?」
🎯 무엇을 평가하는가
이것은 Vibe Coding의 유지보수성에 대한 치명적인 질문입니다. 대화형 개발의 결정은 기본적으로 채팅 기록에 잠겨 있으며, 세 달 후 git log를 아무리 뒤져도 복구할 수 없습니다. "채팅 기록을 확인해 볼게요"라고 답하는 것은 보존 메커니즘이 없다는 것을 인정하는 것입니다; 문서 체계를 설명할 수 있어야 AI 협업을 진정한 엔지니어링으로 하고 있다는 것을 보여줄 수 있습니다.
🧭 답변 프레임워크
  1. 문제를 인정하고 메커니즘을 제시하세요: 결정은 실제로 대화 기록에 의존할 수 없으므로, AI에게 엄격한 템플릿으로 문서를 유지하게 하여 결정이 대화와 시간을 넘어 생존하게 합니다.
  2. 세 가지 문서와 역할을 말하세요: FEATURES는 "이 기능이 어떻게 현재 상태가 됐는가"에 답합니다 — 상태 전환과 이력, 변경 사항과 이유 모두 기록됩니다; CHANGELOG는 "이번 릴리스에서 무엇이 바뀌었는가"에 답합니다 — 근본 원인과 영향 범위; RELEASE_NOTES는 "사용자가 무엇을 받았는가"에 답합니다.
  3. 취향 보존 문서를 추가하세요: METHODOLOGY.md는 제품 원칙, 설계 결정, UX 선호도, 반패턴을 기록합니다. 사용자가 모달 팝업 방안을 거부하면 AI가 반패턴으로 기록하고, 새 대화에서 자동으로 상속되어 같은 제안이 두 번 나오지 않습니다.
  4. 저장소에 있어야 하는 이유를 설명하세요: Notion이나 Feishu에 쓴 결정은 AI가 읽을 수 없습니다. 프로젝트 저장소 내의 Markdown 파일만이 AI가 매번 자동으로 컨텍스트를 가져오게 합니다.
⭐ 가산점 쉽게 간과되는 두 가지 규칙을 추가하세요: CHANGELOG 작성 전에 시스템 시간을 읽어야 합니다 — 기억으로 타임스탬프를 채우거나 나중에 몰아서 쓰는 것은 금지됩니다; 코드 주석은 세 가지 요소(배경, 설계 의도, 핵심 제약)를 필요로 합니다 — 주석은 다음 대화의 AI를 위해 쓰는 것이기도 합니다.
이 강의 페이지로 답변을 구성하세요 → 세 가지 문서와 방법론 보존 주석 3요소와 코드 보호
Q6상사
「AI가 데이터베이스를 삭제한 뉴스를 본 적 있어요. 이렇게 하다가 언젠가 AI가 프로덕션 DB를 날려버리면 어쩌려고요?」
🎯 무엇을 평가하는가
상사는 안심감을 원합니다. "AI는 그런 짓 안 해요"는 최악의 답변입니다 — AI는 실제로 합니다: 선의의 정리, 릴리스에 섞인 임시 변경, 모두 실제 발생한 사고들입니다. 올바른 접근은 위험을 인정하고 관문을 하나씩 제시하는 것입니다.
🧭 답변 프레임워크
  1. 먼저 마스터 원칙을 제시하세요: 비가역적 작업의 안전감은 관문에서 옵니다. 데이터베이스, 설정, 배포 같은 작업은 모든 관문이 실행 전에 설정됩니다.
  2. 세 관문을 말하세요: 관문 1 — 백업: 백업 없이는 migrate, drop, alter, delete 어떤 것도 실행할 수 없으며, 백업은 타임스탬프와 함께 backups/ 디렉토리에 저장, 비용은 명령어 한 줄, 걸려 있는 것은 전체 DB. 관문 2 — 롤백: 실행 전에 복구 방법, 필요한 백업, 예상 복구 시간을 명확히 합니다. 관문 3 — 감사: 릴리스 전에 SubAgent가 실제 diff와 Release Notes를 비교 — 무관한 변경이 섞이면 릴리스 중단.
  3. 릴리스 규율을 추가하세요: 릴리스는 반드시 GitHub를 통해야 하며, 서버는 git pull 또는 CI/CD로 코드를 가져옵니다. 사용자가 명시적으로 확인하기 전에 tag 생성, push, 배포는 모두 금지됩니다 — AI는 자체적으로 릴리스할 권한이 없습니다.
  4. 자격 증명도 관리하세요: 모든 Key는 환경 변수나 secrets로 관리하며, 하드코딩은 금지됩니다. Key가 한번 git 기록에 들어가면 영구적으로 노출된 것과 같으며, 폐기하고 재발급해야 합니다.
⭐ 가산점 diff 감사의 설계 의도를 설명하세요: 전문 팀은 CI/CD와 PR review로 불량 릴리스를 차단하고, 독립 개발자는 종종 review를 건너뛰고 직접 push합니다. SubAgent가 reviewer 역할을 하는 것은 그 공백을 채우는 것입니다. 이 점을 설명할 수 있으면 규칙 이면의 엔지니어링 직관을 이해하고 있음을 보여줍니다.
이 강의 페이지로 답변을 구성하세요 → 파괴적 작업의 세 관문 환경 사실을 Rule에 기록하기
Q7면접관
「규칙을 Rule 파일에 쓴다고 하셨죠. 그 파일은 대체 어떻게 생겼나요? 내일 새 프로젝트를 연다면, 첫 단계에 무엇을 해야 하나요?」
🎯 무엇을 평가하는가
테스트하는 것은 실제로 직접 설정해 봤는지입니다. 이념만 말하고 파일 구조와 디렉터리 위치를 대지 못하는 사람은, 대체로 글을 읽고 배운 것입니다. frontmatter 필드와 세 파일의 역할 분담을 말할 수 있어야 진짜로 적용해 본 것입니다.
🧭 답변 프레임워크
  1. 파일 구조부터 말하세요:Rule 파일은 frontmatter를 달고, alwaysApply: true는 전역 코딩 규범에 쓰이며 모든 대화에 자동으로 적용됩니다; false로 둔 것은 작문 규범처럼 필요할 때 인용하는 파일이라, 코딩 대화의 컨텍스트를 오염시키지 않습니다.
  2. 세 파일을 말하세요:xs_vibe_rules는 모두 세 파일입니다. rule-opensource.mdc는 주 개발 규범으로, 14개 장이 전체 흐름을 덮습니다; writing-style.mdc는 중국어 작문 스타일을 담당하며 필요할 때 수동으로 인용합니다; secrets.mdc는 API Key와 자격 증명 템플릿이며, 플레이스홀더 형식입니다.
  3. 적용 3단계를 주세요:.mdc 파일을 프로젝트의 .cursor/rules/ 디렉터리에 넣으면 Cursor가 자동으로 인식합니다; 각 파일의 alwaysApply를 설정합니다; 모델 설정, 기술 스택, 포트 규칙을 자신의 선정으로 바꿉니다.
  4. 보안을 빼놓지 마세요:secrets 파일은 플레이스홀더를 채우고 git에서 제외합니다. Key가 한번 git 기록에 들어가면 영구적으로 노출된 것과 같으며, 폐기하고 재발급해야 합니다.
⭐ 가산점시작 수를 한 줄 보태세요: 이 저장소는 MIT License 오픈소스이며, 올바른 자세는 Fork한 뒤 자신의 기술 스택에 맞게 삭제·수정하는 것입니다. 그렇게 나온 것이 당신의 첫 번째 AI 협업 규범이고, 처음부터 쓰는 것보다 출발점이 훨씬 높습니다.
이 강의 페이지로 답변을 구성하세요 → AI에게 규칙을 설정해야 하는 이유 규칙의 가치: 각각이 실제 문제를 해결
Q8개발 동료
「채팅창 버그 봤어요: 중국어 입력기에서 엔터를 누르면 반쪽 병음이 그대로 나갑니다. AI가 쓴 거죠? 다음에 또 안 하게 어떻게 보장하나요?」
🎯 무엇을 평가하는가
AI 사각지대에 대한 인식의 깊이를 테스트합니다. isComposing이라는 구체 API를 말하고, AI가 왜 이 함정을 반드시 밟는지 설명할 수 있는 사람은, 진짜로 현장에서 AI가 쓴 프론트엔드를 고쳐 본 사람입니다. 「AI에게 고치라고 하면 된다」만 말하는 사람은, 다음 프로젝트에서도 또 밟습니다.
🧭 답변 프레임워크
  1. 근본 원인부터 주세요:중국어 입력기가 후보 단어를 확정할 때도 Enter가 발생합니다. 코드는 e.key === 'Enter'만 보고 isComposing을 검사하지 않아, 후보 확정 엔터가 전송으로 처리됐습니다.
  2. 표준 작성을 주세요:Enter, Shift 아님, !e.nativeEvent.isComposing 세 조건이 동시에 만족될 때만 전송합니다. isComposing이 true면 입력기가 조합 중이라는 뜻이고, 이때 엔터는 후보만 확정하며 전송을 트리거하지 않습니다.
  3. AI가 왜 범하는지 설명하세요:AI 훈련 데이터에서 isComposing 커버리지가 높지 않아, Rule에 쓰지 않으면 반드시 잊습니다. 규칙 원문은 아주 단호합니다: e.key === 'Enter'만 보고 isComposing을 검사하지 않는 것은 금지입니다.
  4. 수정 방법으로 끌어올리세요:이 버그 자체도 「로그 먼저, 코드 수정은 나중에」의 교과서 사례입니다. e.key와 isComposing을 찍는 Log 한 줄로 한 라운드에 근본 원인을 잡고, 4줄로 깨끗이 고칩니다; 추측 경로로는 세 라운드에 47줄을 고치고도 고치지 못했습니다.
⭐ 가산점!e.shiftKey를 슬쩍 언급하세요: 표준 작성은 Shift+엔터를 줄바꿈에 남겨 두며, 이런 디테일도 AI가 자주 빠뜨립니다. 완전한 판단 조건을 외울 수 있는 사람은, 듣자마자 이 함정을 고쳐 본 사람입니다.
이 강의 페이지로 답변을 구성하세요 → 환경 사실을 Rule에 기록하기 디버깅 철칙: 로그 먼저, 코드 수정은 나중에
Q9면접관
「컴포넌트는 모두 PlayGround에서 먼저 맞춘 뒤 통합한다고 하셨죠. 프론트엔드 쪽에는 이미 Storybook이 있는데, 왜 그걸 안 쓰나요?」
🎯 무엇을 평가하는가
엔지니어링 판단력을 테스트합니다: 업계 표준 방안을 아는지, 그리고 자신의 장면에서는 왜 더 가벼운 쪽을 골랐는지. 「Storybook을 못 들어봤다」고 답하면 시야가 좁다는 것이 드러나고, 「Storybook이 더 전문이니 써야 한다」고 답하면 비용을 계산하지 못한다는 것이 드러납니다.
🧭 답변 프레임워크
  1. 접근이 같은 뿌리임을 먼저 인정하세요:PlayGround는 단순화한 Storybook 발상이며, 각 UI 요소에 독립 demo가 있고, 맞춘 뒤에야 정식 페이지에 통합합니다.
  2. 차이는 비용입니다:Storybook은 업계 표준이지만 설정이 너무 무거워, AI 보조의 빠른 프로토타입 프로젝트에는 overkill입니다. PlayGround는 정적 페이지 하나에 모든 컴포넌트 demo를 늘어놓으며, 비용은 거의 제로입니다.
  3. 무엇을 얻었는지 말하세요:양방향 격리. 컴포넌트를 고쳐도 비즈니스 로직에 영향이 없고, 비즈니스 로직을 다뤄도 컴포넌트 스타일을 흐트러뜨리지 않습니다. 페이지에 바로 쓰면, 버튼 하나를 보려면 페이지 전체를 띄우고 로그인, 데이터 로드, 상태 전환을 한 뒤에야 한 번 볼 수 있으며, 모서리를 키우면 옆 레이아웃이 밀릴 수도 있습니다.
  4. 트리거 조건을 주세요:규칙에 명시되어 있습니다. 페이지 모션이 관련되면 반드시 먼저 정적 페이지 PlayGround를 만들고, 자유롭게 조정·테스트한 뒤에야 정식 페이지에 쓸 수 있습니다.
⭐ 가산점납품 디테일을 하나 보태세요: demo에서 맞춘 파라미터는 정식 컴포넌트에 그대로 복사할 수 있고, 통합 시점에는 이미 완성품입니다. 피팅룸에서 고친 뒤에 무대에 오르면, 재작업이 일어날 수 없습니다.
이 강의 페이지로 답변을 구성하세요 → PlayGround: 컴포넌트 피팅룸
Q10상사
「지난번 데모는 괜찮아 보였는데, 올리자마자 문제가 가득했어요. 나중에야 AI 인터페이스가 아예 안 통하고, 페이지는 전부 가짜 데이터였다는 걸 알았죠. 이런 일을 어떻게 막나요?」
🎯 무엇을 평가하는가
상사는 가짜 데모에 당한 적이 있어, 원하는 것은 납품 라인의 강제 메커니즘입니다. 「앞으로 더 자세히 검사하겠습니다」라고 답하면 메커니즘이 없다고 인정하는 것이고, 다음에 또 일어납니다. 프로세스에 박아 넣은 관문을 내놓아야 합니다.
🧭 답변 프레임워크
  1. 금령을 주세요:AI 모델 호출이 관련된 기능은, 납품 전에 인터페이스가 정말 접근 가능한지 확인해야 하며, 하드코딩된 가짜 응답이나 로컬 시뮬레이션으로 실제 호출을 우회하는 것은 금지입니다.
  2. 원천에서 막으세요:사용자가 API Key를 주지 않으면 AI는 멈춰서 요청해야 하며, 스스로 Mock으로 이어서 쓰면 안 됩니다. Key가 도착하면 먼저 테스트 요청을 한 번 보내 가용성을 검증한 뒤 개발을 계속합니다. 「인터페이스가 안 통한다」는 최대 리스크가 개발 첫 단계에서 드러납니다.
  3. 두 번째 선을 갖추세요:핵심 비즈니스 로직 단위 테스트가 통과하지 않으면 납품할 수 없습니다. 두 강제 검사가 함께 납품 라인을 이룹니다.
  4. 동기를 폭로하세요:「일단 Mock」과 「임시 방안을 먼저」, 「간단하게 처리」는 같은 패턴입니다. AI는 빠르게 실행 가능한 것을 주어 긍정 피드백을 받으려 합니다. 이런 멘트는 규칙에서 같은 조항으로 명시 금지됩니다.
⭐ 가산점손실을 상사가 듣도록 번역하세요: 가짜 데이터의 해악은 리스크를 출시 그날까지 숨겼다가 터뜨린다는 것입니다. 규칙은 검증을 Key가 도착한 그 순간으로 옮깁니다. 리스크가 일찍 드러날수록 처리 비용은 낮아집니다.
이 강의 페이지로 답변을 구성하세요 → 디버깅 철칙: 로그 먼저, 코드 수정은 나중에 단계별 납품 불수용
Q11면접관
「하시는 것은 AI 대화 제품이죠. Prompt 한 줄을 조율할 때마다 비즈니스 플로우 전체를 돌려야 하나요? 평소 Prompt는 어떻게 조율하나요?」
🎯 무엇을 평가하는가
AI 제품의 디버깅 인프라 인식을 테스트합니다. Prompt는 AI 제품의 핵심 자산인데, 전용 디버깅 환경을 대지 못하면 제품이 아직 「돌아가기만 하면 된다」에 머물러 있고, 이터레이션을 말할 수 없습니다.
🧭 답변 프레임워크
  1. 강제 요구를 주세요:프로젝트에 AI 대화 기능이 있으면, PlayGround에 간단한 대화 테스트 페이지를 반드시 구현해, 완전한 비즈니스 플로우에서 벗어나 대화 한 라운드만 따로 조율할 수 있어야 합니다.
  2. Prompt를 펼치세요:이 페이지에는 프로젝트가 쓰는 모든 Prompt를 반드시 나열해야 합니다. Prompt가 코드 문자열에 숨으면 디버깅할 수 없고, 페이지에 펼쳐야 빠르게 비교하고 조정할 수 있습니다.
  3. 본질을 찌르세요:Prompt는 AI 제품의 핵심 자산이므로, 컴포넌트를 다루듯 전용 피팅룸을 주고, 맞춘 뒤에야 비즈니스 플로우에 넣습니다.
⭐ 가산점유지 규칙을 보태세요: PlayGround의 demo는 추가·수정만 하고 삭제하지 않으며, 요구가 취소돼도 해당 demo는 남깁니다. 설계 과정의 역사 아카이브이며, 미래 요구가 되살아나면 바로 집어 씁니다.
이 강의 페이지로 답변을 구성하세요 → PlayGround: 컴포넌트 피팅룸
Q12면접관
「AI가 쓴 주석을 본 적 있어요, 함수 이름을 다시 말할 뿐이죠. 여러분의 코드를 석 달 두면, 왜 이렇게 썼는지 스스로 이해할 수 있나요?」
🎯 무엇을 평가하는가
「주석을 잘 쓰라」는 빈말을 실행 가능한 구조로 바꿀 수 있는지를 테스트합니다. 「주석을 잘 쓰라」는 네 글자를 AI는 실행하지 못합니다. 고정 구조, 예시, 판단 기준을 말할 수 있는 사람만이, 진짜로 AI의 코드 품질을 관리하고 있는 것입니다.
🧭 답변 프레임워크
  1. 문제부터 인정하세요:코드는 「무엇을 했는가」만 표현할 수 있습니다. 왜 존재하는지, 왜 이렇게 구현했는지, 호출 시 무엇을 주의해야 하는지는, 주석에 써야 시간을 넘어 남습니다.
  2. 세 요소를 말하세요:배경(어떤 비즈니스 문제를 푸는지, 어떤 장면에서 호출되는지), 설계 의도(왜 이 방안을 골랐는지, 어떤 대안을 버렸는지 — git log에는 이것이 없습니다), 핵심 제약(부작용, 의존 관계, 경계 조건 등 호출 측이 알아야 할 것).
  3. 보호 규칙을 더하세요:리팩터링 때 「주석이 너무 길다」「코드가 스스로 설명한다」「겸사겸사 정리」를 이유로 배경과 설계 의도 주석을 지우는 것은 금지입니다; 구현이 바뀌어 주석이 부정확해지면 내용을 반드시 동기화 업데이트해야 합니다.
  4. 판단 기준을 주세요:단 하나입니다. 미래에 이어받는 사람이 이 주석이 없어도, 당초에 왜 이렇게 했는지 이해할 수 있는가?
⭐ 가산점강좌의 그 예시를 드는 것이 가장 설득력 있습니다: merge_chat_history의 세 요소 주석은 「서버 기록을 권위로 삼고, 로컬 고유 메시지만 추가하며, system 메시지는 일률적으로 버린다」를 적어 두었고, 이런 결정 정보는 코드 자체만 읽어서는 전혀 나오지 않습니다.
이 강의 페이지로 답변을 구성하세요 → 주석 3요소와 코드 보호
Q13개발 동료
「지난주에 제가 쓴 구 데이터 형식 호환 코드가, 당신 AI가 리팩터링하면서 지워졌어요. 이 일 알고 있나요?」
🎯 무엇을 평가하는가
개발 동료는 책임을 묻고 있으며, 당신의 프로세스가 그의 코드를 보호할 수 있는지도 탐색합니다. 이 문제를 잘못 답하면 협력 신뢰가 바로 제로가 됩니다. 핵심은 「선의의 파괴」 같은 사고의 방지법입니다.
🧭 답변 프레임워크
  1. 사고 유형부터 인정하세요:이것을 선의의 파괴라고 합니다. AI가 리팩터링 때 불필요하다고 본 코드를 정리하고, 뒤에야 쓸모가 있었음을 발견하는 것으로, 네 가지 전형 사고 중 하나입니다.
  2. 선언 규칙을 주세요:기존 기능 코드를 삭제하기 전에 사용자에게 명확히 알리고 이유를 설명해야 하며, 「겸사겸사 정리」「쓸모없어 보인다」를 이유로 조용히 지우는 것은 금지입니다.
  3. 표준 동작을 주세요:AI가 어떤 코드를 제거해야 한다고 보면, 먼저 // TODO: 제거 제안 - 이유: xxx로 표시하고, 명확한 허가를 받은 뒤에 지웁니다. 「쓸모없어 보인다」는 삭제 이유가 되지 않습니다.
  4. 프로세스 관문을 보태세요:이런 파괴는 대량 리팩터링에서 자주 일어납니다. 파일 3개 이상을 수정하면 반드시 먼저 수정 계획서를 내고 파일마다 무엇을 바꾸는지 써야 하며, 「겸사겸사」한 무관 정리는 계획을 심사하는 이 관문에서 드러납니다.
⭐ 가산점다른 샛길도 막으세요: 통째로 주석 처리해 제자리에 쌓아 두는 것도 마찬가지로 틀린 것이며, 규칙은 이런 방법을 권장하지 않습니다. 본질은 여전히 파괴입니다. 올바른 경로는 단 하나입니다: 표시, 알림, 허가 대기.
이 강의 페이지로 답변을 구성하세요 → 주석 3요소와 코드 보호 4단계 프로세스: 복술·PRD·확인·코딩
Q14면접관
「프로덕션에서 장애가 났는데 로그를 뒤져도 아무것도 없었고, 결국 오류가 전부 catch에 잡혀 조용히 삼켜진 것을 발견했어요. 오류 처리에 제약이 있나요?」
🎯 무엇을 평가하는가
품질 하한이 구문 수준까지 내려가 있는지를 테스트합니다. 「무엇이 조용히 삼키는 오류인가」의 구체 목록을 말할 수 있으면 규칙이 진짜로 코드 층까지 실행된 것이고, 「우리는 오류를 진지하게 처리합니다」는 규칙이 없다는 뜻입니다.
🧭 답변 프레임워크
  1. 금령을 주세요:빈 catch는 금지입니다. 모든 try/catch와 오류 분기는 실질적 처리가 있어야 합니다.
  2. 삼키기를 정의하세요:console.log(e)만 하기, pass, // ignore는 모두 조용히 삼키는 오류이며, 일률적으로 허용하지 않습니다.
  3. 합격 기준을 주세요:로그 기록에 더해 사용자가 볼 수 있는 오류 안내, 또는 합리적인 다운그레이드 로직, 적어도 하나를 차지해야 합니다.
  4. 로그 면을 갖추세요:백엔드는 터미널에 상세 로그를 찍고, 프론트엔드는 브라우저 Console에 로그를 찍습니다. 삼키기와 로그 부재는 같은 병이며, 문제가 나면 「로그 먼저 찍어 근본 원인을 잡기」가 손쓸 수 없게 됩니다.
⭐ 가산점이 조항을 주석 보호, 삭제 선언과 같은 블록(품질 하한, AI의 게으름을 전문적으로 막는 곳)에 넣을 수 있으면, 머릿속에 규칙의 전경이 있다는 뜻이고, 답하는 각 조항이 체계 안에서 어디 있는지 안다는 뜻입니다.
이 강의 페이지로 답변을 구성하세요 → 주석 3요소와 코드 보호 디버깅 철칙: 로그 먼저, 코드 수정은 나중에
Q15상사
「팝업 쓰지 말라고 몇 번을 말했는데, 대화 AI를 바꾸면 또 팝업이 뜹니다. 이런 요구를 기억하게 할 수는 없나요?」
🎯 무엇을 평가하는가
상사는 반복해서 설명하는 비용을 불평하고 있습니다. 원하는 것은 취향 보존 메커니즘입니다: 선호를 한 번 말하면, 이후 모든 대화에 적용됩니다. 「매번 서두에 AI를 상기시킵니다」라고 답하면 비용을 제자리에 두는 것입니다.
🧭 답변 프레임워크
  1. 메커니즘을 주세요:METHODOLOGY.md. AI가 대화 속의 제품 사고, 결정 로직, 취사 선호를 능동적으로 식별해 정제 후 바로 쓰고, 새 대화가 자동으로 상속합니다.
  2. 팝업 일의 귀착을 말하세요:사용자가 팝업 방안을 거부하고 이유를 주면, AI가 그것을 「안티패턴」에 기록하고, 이후 같은 방안은 두 번 나오지 않습니다.
  3. 네 단락 구조를 말하세요:제품 원칙(반복해서 나타나는 핵심 신념), 설계 결정 기록(날짜와 이유 포함), 사용자 경험 선호(UI/UX 취향과 미적 기준), 안티패턴(명확히 거부한 방안에 거부 이유를 붙임).
  4. 쓰기 원칙을 말하세요:본질을 정제하고, 동류를 합치고, 새 항목에 날짜를 달며, 대화 원문을 그대로 옮기지 않습니다; 기술 구현 디테일과 일회성 임시 결정은 기록하지 않습니다. AI가 식별하면 바로 쓰고, 쓴 뒤 간단히 알리며, 매번 허가를 구할 필요는 없습니다.
⭐ 가산점네 가지 트리거 시점을 외우세요: 사용자가 「왜 이렇게 하는지」를 설명했을 때, 방안을 거부하고 이유를 줬을 때, 명확한 UI/UX 선호를 표현했을 때, 복기에서 경험을 정리했을 때. 이 네 순간에 AI가 자동 기록하며, 상사의 취향이 이렇게 한 줄씩 매뉴얼이 됩니다.
이 강의 페이지로 답변을 구성하세요 → 세 가지 문서와 방법론 보존
Q16면접관
「석 달 전 어떤 기능이 A 방안에서 B 방안으로 바뀌었습니다. 지금 당초에 왜 바꿨는지 말하라면, 무엇을 뒤지나요?」
🎯 무엇을 평가하는가
기능 단위 추적 가능성을 테스트합니다. 「commit을 뒤진다」고 답하는 사람은 결정 정보와 코드 정보가 다른 일임을 모릅니다: git log는 코드가 어떻게 바뀌었는지만 기록하고, 왜 바꿨는지는 기록하지 못합니다.
🧭 답변 프레임워크
  1. 답을 바로 주세요:docs/FEATURES.md를 뒤집니다. 기능 포인트의 유일한 사실 원천이며, 각 기능에 「이력」이 붙어 초기 요구, 방안 변경과 이유, 최종 구현을 기록합니다.
  2. 상태 전환을 말하세요:🟡 기획 중, 🔵 개발 중, 🟢 완료, ⚪ 취소. 상태 변경, 방안 조정마다 날짜가 있는 기록을 추가합니다.
  3. 세칙을 짚으세요:취소된 기능도 지우지 않고 ⚪로 표시하고 이유를 적습니다; 날짜는 반드시 시스템 현재 시간을 읽어야 하며 기억으로 채우면 안 됩니다; 방안이 바뀌지 않았어도 「초기 요구」 한 줄은 써야 합니다.
  4. git log가 왜 부족한지 말하세요:「검색 기능이 성능 문제로 A 방안에서 B 방안으로 바뀌었다」는 이 이유는, commit에서는 변경 자체만 보입니다. 이력이 답하는 것이 바로 「당초에 왜 A 방안을 버렸는가」입니다.
⭐ 가산점관통하는 철학을 짚으세요: FEATURES의 「취소해도 삭제하지 않음」과 PlayGround의 「demo는 추가만 하고 삭제하지 않음」은 같은 일이며, 잘린 요구도 설계 과정의 역사 아카이브이고, 미래에 되살아나면 바로 집어 옵니다.
이 강의 페이지로 답변을 구성하세요 → 세 가지 문서와 방법론 보존 PlayGround: 컴포넌트 피팅룸
Q17면접관
「업데이트 공지에 『메시지 렌더링 모듈을 리팩터링했다』고 쓰여 있는데, 사용자가 이해하나요? CHANGELOG와 RELEASE_NOTES는 어떻게 분담하나요?」
🎯 무엇을 평가하는가
문서의 독자 인식을 테스트합니다. 두 문서의 언어 스타일은 완전히 다릅니다. 하나는 개발자용, 하나는 사용자용이며, 섞어 쓰면 각자 누구에게 보여 줄지 생각하지 않았다는 뜻입니다.
🧭 답변 프레임워크
  1. 분담을 한 줄로:CHANGELOG는 「이번에 무엇을 바꿨는가」에 답하며 개발자에게 보여 줍니다; RELEASE_NOTES는 「사용자가 무엇을 얻었는가」에 답하며 실제 사용자에게 보여 줍니다.
  2. CHANGELOG의 격:시간 역순이며, 각 항목은 표로 문제/요구, 근본 원인/방안, 변경 범위, 영향면, 상태를 기록하고, 유형 태그는 BUG / FEAT / REFACTOR / PERF / DOCS로 나눕니다. 쓰기 전에 반드시 시스템 시간을 읽어야 하며, 기억으로 타임스탬프를 채우거나 적체해 몰아 쓰는 것은 금지입니다.
  3. RELEASE_NOTES의 레드라인:디버깅 기능, 기술 구현 디테일(모듈명, 파일 경로, 리팩터링), 사용자가 감지하지 못하는 변경은 쓰지 않습니다. 「메시지 렌더링 모듈 리팩터링」은 외부 행동이 변하지 않으므로, 공지에 아예 나와서는 안 됩니다.
  4. 합격 작성을 주세요:각 항목이 「이것이 나에게 무슨 소용인가」에 답할 수 있어야 합니다. 새 기능은 사용자가 무엇을 새로 할 수 있는지 한 줄로, 수정은 이전 문제와 지금 해결을 쓰며, 각 항목은 3문장을 넘지 않고, 버전 번호는 SemVer를 따릅니다.
⭐ 가산점같은 일로 분담을 시연하세요: 입력기 오전송 수정은, CHANGELOG에는 근본 원인이 isComposing을 판단하지 않은 것, 유형은 BUG; RELEASE_NOTES에는 「중국어 입력 시 더 이상 잘못 보내지 않습니다」만 씁니다. 한 정보, 두 문서가 각자 필요한 것을 가져갑니다.
이 강의 페이지로 답변을 구성하세요 → 세 가지 문서와 방법론 보존
Q18개발 동료
「브랜치를 받아 돌려 보니 axios가 없고 전부 fetch로 바뀌어 있더군요. 이런 일도 한마디 없이 하나요?」
🎯 무엇을 평가하는가
의존성 거버넌스를 테스트합니다. 의존성 변경은 프로젝트 전체의 빌드와 실행 환경을 흔들며, 조용한 교체는 팀 협업의 큰 금기입니다. 대응하는 선언 메커니즘이 있는지, 아니면 AI 기분에 맡기는지 알고 싶어 합니다.
🧭 답변 프레임워크
  1. 먼저 성격을 정하세요:이것은 의존성 변경 선언을 위반한 것입니다. package.json, requirements.txt의 어떤 변경도 조용히 설치하거나 제거하는 것은 금지입니다.
  2. 세 가지를 말하세요:손대기 전에 무엇을 추가하거나 제거했는지, 왜 필요한지, 버전 선택 이유를 능동적으로 설명해야 합니다.
  3. 왜 엄한지 말하세요:기능이 동등한 교체라도 영향면은 전혀 동등하지 않을 수 있습니다. 강좌의 실제 사례는 axios를 0.27.2에서 1.6.0으로 올린 것으로, 메이저 버전에 파괴적 변경이 있어 모든 네트워크 요청에 파급될 수 있습니다.
  4. 릴리스 면의 최후 방어를 보태세요:선언을 빠뜨려도, 릴리스 전 diff 심사가 한 번 더 막습니다. Release Notes에 없는 의존성 변화는 SubAgent가 리스크로 표시하고 릴리스를 일시 중지합니다.
⭐ 가산점경계를 못 박으세요: commit message에 한 줄 적는 것은 설명이 아닙니다. 선언은 손대기 전에 일어나야 하며, 코드를 지우기 전 TODO를 달고 허가를 기다리는 것과 같은 「먼저 선언, 나중에 착수」 패턴입니다.
이 강의 페이지로 답변을 구성하세요 → 주석 3요소와 코드 보호 파괴적 작업의 세 관문
Q19면접관
「AI가 생성한 코드에 테스트를 돌리나요? 테스트도 AI가 스스로 쓴 거죠? 그럼 자기끼리 속이는 것 아닌가요?」
🎯 무엇을 평가하는가
납품 라인의 강제 정도를 테스트합니다. 디렉터리, 명명, 커버 범위를 말할 수 있는 사람은 테스트가 진짜로 프로세스 안에 있는 것이고, 「시간 되면 돌려 본다」는 사람은 테스트가 장식일 뿐입니다. 뒷문장에는 회의도 묻혀 있어, 받아쳐야 합니다.
🧭 답변 프레임워크
  1. 강제 선을 주세요:핵심 로직 단위 테스트가 통과하지 않으면 납품할 수 없습니다. 이것은 납품 전 두 강제 검사 중 하나이며, 다른 하나는 실제 AI 인터페이스 검증입니다.
  2. 커버 범위를 말하세요:핵심 비즈니스 로직, API 인터페이스, 데이터 처리 함수, 경계 조건을 모두 커버해야 합니다.
  3. 규범 디테일을 말하세요:테스트 파일은 tests/ 디렉터리에 통일하고, 이름은 test_{모듈명}.py이며, Python 프로젝트는 pytest를 씁니다. 디버깅용 임시 스크립트는 쓰고 스스로 삭제하며, 테스트 자산과 디버깅 쓰레기를 따로 관리합니다.
  4. 회의를 받아치세요:테스트는 마지막 관문일 뿐이고, 앞에는 PRD 확인이 이해 편차를 막고, 수정 계획이 범위 확산을 막습니다. 여러 관문이 서로를 보완하며, 어느 하나만으로는 부족합니다.
⭐ 가산점경계 인식을 한 줄 보태세요: 테스트가 막는 것은 구현 층의 회귀입니다. AI가 요구를 잘못 이해하면 테스트는 그대로 전부 초록이고, 그래서 중단점은 코딩 전에 두어야 하며, 이것이 바로 4단계 프로세스가 존재하는 이유입니다.
이 강의 페이지로 답변을 구성하세요 → 디버깅 철칙: 로그 먼저, 코드 수정은 나중에 4단계 프로세스: 복술·PRD·확인·코딩
Q20면접관
「규칙이 AI의 MVP 제안을 금지하나요? 제품은 먼저 MVP로 요구를 검증하는 것이 기본기인데, 상식에 어긋나지 않나요?」
🎯 무엇을 평가하는가
개념 분별 문제로, 사람이 결정한 분할과 AI가 독단으로 한 다운그레이드를 가릴 수 있는지를 테스트합니다. 둘을 한몫으로 보는 사람은, 좋은 규칙을 교조로 쓰거나, 아예 쓰지 못하게 됩니다.
🧭 답변 프레임워크
  1. 경계를 먼저 그으세요:규칙이 금하는 것은 AI가 능동적으로 단계별 납품, MVP, 1·2·3단계를 기획하는 것이며, 사람이 MVP 결정을 하는 것을 금지한 적은 없습니다. 분할은 사람의 결정이고, 다운그레이드는 AI의 독단이며, 둘의 차이가 이 규칙의 핵심입니다.
  2. 올바른 흐름을 주세요:기능이 정말 복잡할 때 AI의 올바른 동작은 완전한 방안, 실제 작업량, 사전 결정 목록을 내는 것이며, 나눌지와 어떻게 나눌지는 사람이 결정합니다.
  3. 경계 사례를 드세요:한 기능에 정말 2000줄이 필요하면 한 번에 다 쓰는 것은 비현실적입니다. 이때 AI에게 완전한 방안과 작업량을 보고하게 하고, 사람이 작업량을 보고 두 개의 PR로 나눕니다. 이것은 분할이며, 다운그레이드와 무관합니다.
  4. 강제 규칙 하나를 보태세요:결함이 알려진 방안은 올바른 버전을 바로 주고, 대충인 것을 먼저 만들지 마세요.
⭐ 가산점인증 시스템 예시로 마무리하세요: AI가 완전한 방안 약 3일, 복잡도는 OAuth 콜백과 멀티 엔드 세션에 있다고 보고하고, 사전 결정 3개(휴대폰 번호 로그인 여부, 공급자 몇 곳, 세션 유효 기간)를 더 나열하면, 사람은 수십 초 만에 결정할 수 있고, 완전판이 한 번에 자리 잡습니다.
이 강의 페이지로 답변을 구성하세요 → 단계별 납품 불수용
Q21면접관
「Agent 도구 호출은 반드시 XML을 쓰라고 규정했나요? 지금은 다들 JSON을 쓰는데, 이 규칙은 어디서 왔나요?」
🎯 무엇을 평가하는가
형식 선정 뒤의 엔지니어링 이유를 테스트합니다. escape hell과 LLM이 Token 단위로 생성할 때의 오류 패턴을 말할 수 있으면, 이해가 생성 메커니즘 층까지 닿은 것이고, 규칙에 적용 경계가 있다는 것도 아는 것입니다.
🧭 답변 프레임워크
  1. 삼분법을 말하세요:Agent 도구 호출은 XML, 설정 파일과 데이터 저장은 YAML, 대외 REST API는 JSON. 세 형식이 각 영역을 맡고 섞지 않습니다.
  2. XML의 이유를 말하세요:JSON 문자열 안에 다시 JSON을 넣으면 escape hell이고, 중첩마다 백슬래시가 두 배가 되며, LLM이 Token 단위로 생성할 때 괄호와 따옴표를 매우 쉽게 맞추지 못합니다. XML 태그 닫힘은 직관적이라 모델 오류율이 더 낮습니다.
  3. 나머지 둘을 말하세요:설정 파일을 읽고 쓰는 주체는 사람이며, YAML은 괄호·따옴표 노이즈가 없고 주석을 지원해 「이 값을 왜 이렇게 두었는가」를 바로 옆에 씁니다; REST API에 JSON을 쓰는 것은 업계 표준이며, 대외 인터페이스의 원칙은 호출 측을 괴롭히지 않는 것입니다.
  4. 예외를 말하세요:GPT 계열만 쓰는 프로젝트는 도구 호출을 JSON으로 되돌릴 수 있으며, 그 function calling은 원래 JSON입니다. 「Agent는 XML」은 멀티 모델 혼용 장면의 최대공약수이고, Claude 계열 모델은 XML에서 더 안정적입니다.
⭐ 가산점YAML도 호출 프로토콜에서 제외하세요: 들여쓰기로 계층을 표현하므로 LLM 생성 때 들여쓰기가 매우 쉽게 밀리고, 한 칸 차이로 트리 전체가 기울어집니다. 세 형식의 탈락 이유를 모두 말할 수 있어야 삼분법을 진짜 아는 것입니다.
이 강의 페이지로 답변을 구성하세요 → 환경 사실을 Rule에 기록하기
Q22면접관
「이미지 생성 기능을 올리자마자 대규모 타임아웃이 났고, 결국 타임아웃 설정 문제였습니다. 이런 초급 함정을 어떻게 막나요?」
🎯 무엇을 평가하는가
환경 사실의 관리 방식을 테스트합니다. 이런 함정의 특징은 AI가 반복해서 밟는다는 것입니다: 이번에 고치면, 다음 대화에서 기본값으로 돌아갑니다. Rule로 한 번에 해결한다는 것을 아는지, 그리고 구체 숫자를 말할 수 있는지를 봅니다.
🧭 답변 프레임워크
  1. 함정의 모양을 말하세요:이미지 API는 기본 30초 타임아웃 때문에 자주 실패하고, AI는 같은 잘못된 설정을 반복 시도하며, 고치면 한 번 맞고 잊으면 한 번 틀립니다.
  2. 숫자를 주세요:이미지 생성용 HTTP 클라이언트 타임아웃은 최소 120에서 180초로 두고 Rule에 쓰면, 매 대화에 자동으로 들어가 한 번에 해결됩니다.
  3. 같은 족 규칙을 말하세요:네트워크 요청 실패 시 반드시 먼저 프록시 재시도를 하고(기본 127.0.0.1:7890), 그래도 실패해야 사용자에게 보고하며, 프록시를 건너뛰고 바로 오류를 내는 것은 금지입니다; 프론트엔드에 보이는 모든 대형 모델 응답은 Streaming으로 반환해야 하고, 백엔드 내부 호출만 비스트리밍을 허용합니다.
  4. 메커니즘으로 끌어올리세요:이것들은 모두 환경 사실입니다. Rule에 쓰는 것은 AI에게 미리 채운 .env 설명서를 주는 것과 같아, 새 대화에서 설명하지 않아도 어떤 모델을 호출하고 타임아웃을 얼마로 둘지 바로 압니다.
⭐ 가산점검증 방법을 주세요: 새 대화를 열고 아무 설명 없이 AI에게 프로젝트의 기술 스택과 모델 설정을 물으세요. 답할 수 있어야 진짜로 Rule에 쓴 것입니다. 이것은 강좌의 수업 실습이며, 해 본 사람은 주저 없이 답합니다.
이 강의 페이지로 답변을 구성하세요 → 환경 사실을 Rule에 기록하기
Q23개발 동료
「SubAgent를 여러 개 동시에 열어 코드를 고친다고 들었어요? 두 Agent가 같은 파일을 고치면, 나중에 고친 쪽이 먼저 고친 것을 덮어쓰는데 어떻게 하나요?」
🎯 무엇을 평가하는가
멀티 Agent 병렬의 일관성 인식을 테스트합니다. 이것은 새로 나타난 엔지니어링 문제이며, 답할 수 있는 사람은 진짜로 멀티 Agent로 일하고 있는 것이고, 답하지 못하면 병렬이 당신에게는 데모일 뿐입니다.
🧭 답변 프레임워크
  1. 규칙을 주세요:여러 SubAgent 또는 여러 편집이 같은 파일을 다룰 때, 이후 수정은 반드시 먼저 파일의 현재 상태를 다시 읽어야 하며, 캐시나 기억 속의 옛 내용을 바탕으로 편집하는 것은 금지입니다.
  2. 비유를 주세요:이것이 멀티 Agent 시대의 「낙관적 락」입니다. 쓰기 전에 파일의 최신 상태를 확인해야, 남의 변경이 무심코 덮이지 않습니다.
  3. 목표 일관성을 갖추세요:병렬 중에 사용자가 목표를 바꿨을 수 있습니다. 목표를 복술할 때는 가장 최근 것을 기준으로 하고 변경을 명확히 표시해, 신·구 목표가 섞이고 두 Agent가 제각각 하는 일을 피합니다.
  4. 병렬의 긍정적 용법을 설명하세요:규칙은 병렬 조사를 권장합니다. 버그 수정 전의 세 질문 자체 점검도, SubAgent를 우선 띄워 영향 범위를 병렬 조사한 뒤, 안전을 확인한 다음 착수하라고 제안합니다.
⭐ 가산점두 규칙의 공통점을 찌르세요: 긴 대화와 병렬 작업에서 손에 든 정보는 모두 만료됩니다. 핵심 동작 전에 먼저 새로고침하는 것(파일 다시 읽기, 목표 복술)이, 사후에 조사하는 것보다 훨씬 쌉니다.
이 강의 페이지로 답변을 구성하세요 → 긴 대화 앵커링과 작문 규범 디버깅 철칙: 로그 먼저, 코드 수정은 나중에
Q24면접관
「AI가 데이터베이스를 SQLite에서 PostgreSQL로 바꾸자고 했고, 이유도 조목조목입니다. 바꾸나요, 안 바꾸나요?」
🎯 무엇을 평가하는가
선정 결정권의 귀속을 테스트합니다. AI를 따라 바꾸는 사람은, 프로젝트가 조만간 선정 드리프트에 빠집니다. 듣고 싶은 답은 「잠근다」와, 잠그는 구체 방법입니다.
🧭 답변 프레임워크
  1. 태도부터 주세요:바꾸지 않습니다. 기술 스택 선정은 사람의 결정이며, 한 번 정하면 대체 방안을 더 이상 논의하지 않습니다. AI의 직무는 확정된 스택 안에서 코드를 잘 쓰는 것입니다.
  2. 드리프트의 모양을 말하세요:잠그지 않으면 다른 대화에서 AI가 다른 프레임워크를 고릅니다. 오늘은 Express, 내일은 Fastify, 데이터베이스는 어느 순간 MongoDB, 어느 순간 PostgreSQL이 되어, 프로젝트가 드리프트 속에서 일관성을 잃습니다.
  3. 잠글 내용을 말하세요:선정을 Rule에 박아 넣습니다. 강좌의 예시는 백엔드 FastAPI, 프론트엔드 React + Tailwind + Vite, 데이터베이스 SQLite, 벡터 라이브러리 Chroma입니다.
  4. 포트 디테일을 보태세요:포트는 5000을 피하고 8000에서 9000 사이를 무작위로 할당해, 여러 프로젝트를 같이 열어도 충돌하지 않습니다. 이 조항을 말할 수 있으면 Rule을 디테일까지 읽었다는 뜻입니다.
⭐ 가산점「어떻게 바꿔야 맞는지」를 보태세요: 정말 라이브러리를 바꾸려면, 입구는 사람이 Rule의 기술 스택 선언을 고치는 것(적응 네 동작 중 「교체」)이고, AI는 새 스택 안에서 일합니다. 선정은 바뀔 수 있지만, 변경 입구는 사람 손에 있으며, AI의 제안에 있는 적이 없습니다.
이 강의 페이지로 답변을 구성하세요 → 환경 사실을 Rule에 기록하기 AI에게 규칙을 설정해야 하는 이유
Q25상사
「지난 버전 사고는 기억합니다: 릴리스에 미완성 코드가 섞여 들어갔어요. 심사를 더했다고 했는데, 구체적으로 어떻게 심사하나요? 문제를 찾으면 어떻게 하나요?」
🎯 무엇을 평가하는가
상사가 원하는 것은 단계 단위 프로세스 디테일입니다. 「우리는 심사합니다」라는 네 글자는 이미 질렸고, 각 단계에서 무엇을 하는지, 문제를 찾으면 누가 결정하는지를 쪼개 듣기를 원합니다.
🧭 답변 프레임워크
  1. 프로세스 3단계를 말하세요:완전한 diff를 가져오고, 파일마다 대조하고, 분류 처리합니다. SubAgent가 실제 diff와 Release Notes의 편차를 독립적으로 분석하게 합니다.
  2. 무엇을 심사하는지 말하세요:Release Notes에 쓴 것은 예상 변경이고, 실제 commit에는 무관 조정이나 잘못된 삭제까지 섞일 수 있습니다. 강좌 사례: 릴리스 주제는 야간 모드인데, diff에는 메시지 파싱 함수 개작과 axios 0.27.2에서 1.6.0 의존성 업그레이드가 섞여 있고, 공지에 없는 것이 리스크입니다.
  3. 처리를 주세요:리스크가 나오면 릴리스를 멈추고 사용자 확인을 기다립니다. 확인 전에 tag 생성, push, 배포는 전부 금지이며, AI에게 자체 릴리스 권한은 없습니다.
  4. 게시 채널을 보태세요:게시는 반드시 GitHub를 통해야 하며, 서버는 git pull 또는 CI/CD로 코드를 가져옵니다. 긴급 핫픽스는 예외가 될 수 있으나, 사후에 반드시 commit을 보완해 동기화해야 합니다.
⭐ 가산점심사의 가치를 한 줄로 요약하세요: 「내가 바꿨다고 생각한 것」과 「내가 실제로 바꾼 것」을 쪼개 대조하면, 둘의 차이가 사고의 출처입니다. 상사는 이 한 줄을 듣고 당신이 생각했다는 것을 압니다.
이 강의 페이지로 답변을 구성하세요 → 파괴적 작업의 세 관문
Q26면접관
「AI와 30라운드를 이야기하다 갑자기 처음에 정한 데이터베이스를 바꿔 버립니다. 이런 일을 겪어 봤나요? 어떻게 다스리나요?」
🎯 무엇을 평가하는가
긴 대화 드리프트의 원인 이해를 테스트합니다. 「몇 번 더 상기시킨다」는 아직 입문 전입니다; 윈도우 절단 메커니즘과 주기적 앵커를 말할 수 있는 사람만이 긴 대화의 진짜 사용자입니다.
🧭 답변 프레임워크
  1. 원인부터 말하세요:컨텍스트 윈도우 절단에 더해 긴 텍스트 말미 어텐션 감쇠입니다. 1라운드에 말한 「PostgreSQL을 쓴다」는 30라운드가 되면 이미 윈도우 밖으로 미끄러졌고, AI는 보이는 정보 안에서 「합리적인」 추론을 한 것뿐이라 SQLite로 바꾸자고 합니다.
  2. 규칙을 주세요:10라운드를 넘긴 뒤, 코드 수정, 설정 수정, 배포 같은 핵심 조작 전에 AI는 반드시 먼저 현재 목표와 핵심 제약을 회고하고 복술해야 합니다.
  3. 형식을 주세요:복술에 고정 형식 「📌 현재 목표: XXX | 핵심 제약: YYY」가 있어, 사람이 한눈에 벗어났는지 확인할 수 있습니다.
  4. 경계 인식을 보태세요:200K Token 모델이라도 긴 텍스트 말미의 어텐션 감쇠는 실제로 존재합니다. 앵커링은 긴 윈도우 모델에도 마찬가지로 필요하며, 큰 모델로 바꾼다고 이 병은 낫지 않습니다.
⭐ 가산점두 방어선을 이으세요: 선정 드리프트 자체가 네 가지 전형 사고 중 하나이며, 기술 스택 잠금은 대화 밖에서 막고(Rule이 매 라운드 주입), 앵커링은 대화 안에서 막습니다(주기적 복술). 이중 보험입니다.
이 강의 페이지로 답변을 구성하세요 → 긴 대화 앵커링과 작문 규범 AI에게 규칙을 설정해야 하는 이유
Q27면접관
「제품 카피도 AI에게 쓰게 하나요? 솔직히, AI 맛은 한눈에 보이고 사용자도 압니다. 사람 말처럼 나오게 어떻게 보장하나요?」
🎯 무엇을 평가하는가
「자연스럽고 유창하다」는 주관적 요구를 엔지니어링화할 수 있는지를 테스트합니다. 「몇 번 더 고치겠습니다」는 방법이 없는 사람이고, 금지 목록과 자체 점검 흐름을 말할 수 있는 사람은 납품 품질이 안정적입니다.
🧭 답변 프레임워크
  1. 빈말이 왜 소용없는지 찌르세요:「자연스럽고 유창한 중국어로 작성해 주세요」는 소용이 없습니다. AI가 생각하는 자연과 당신이 생각하는 자연은 완전히 다를 수 있습니다. 구체 금지어와 금지 구문 목록을 줘야 AI가 정확히 실행합니다.
  2. 금지 패턴을 드세요:writing-style.mdc 목록에는 전각 대시, 전각 말줄임표, 「A가 아니라 B이다」 같은 대비 구문, 웹소설식 감정 단어, 타인을 평가하는 말, 해석을 앞에 두는 깔개, 영어 굽은 따옴표가 포함됩니다.
  3. 자체 점검 흐름을 주세요:납품 전에 금지 패턴을 항목마다 검색하고, 한 곳 발견하면 한 곳 고치며, 끝나면 자체 점검을 마쳤다고 명시합니다. System Prompt 안의 금지 구문도 마찬가지로 고쳐야 합니다.
  4. 설정 디테일을 주세요:작문 규범은 독립 파일이며, frontmatter는 alwaysApply: false로 두고, 카피나 Prompt를 쓸 때만 수동 인용해 코딩 대화의 컨텍스트를 오염시키지 않습니다.
⭐ 가산점목록 방법의 본질을 말하세요: 금지 패턴은 검색 가능하며, AI가 방금 쓴 원고를 항목마다 스캔할 수 있어, 주관적 취향이 기계 검사가 됩니다. 앵커링은 망각에 대항하고, 목록은 모호함에 대항하며, 공통점은 모호한 기대를 실행 가능한 동작으로 바꾸는 것입니다.
이 강의 페이지로 답변을 구성하세요 → 긴 대화 앵커링과 작문 규범 AI에게 규칙을 설정해야 하는 이유
Q28면접관
「첫 화면이 전부 emoji 버튼이었죠, AI의 손이죠? 디자인 취향 같은 것도 규칙으로 세울 수 있나요?」
🎯 무엇을 평가하는가
취향을 규칙화할 수 있는지를 테스트합니다. 대다수는 규칙이 프로세스와 보안만 다룬다고 생각하며, 디자인 층의 구체 조항을 들 수 있으면, 이 규칙 세트의 커버 범위가 어디까지인지 이해한다는 뜻입니다.
🧭 답변 프레임워크
  1. 조항을 주세요:emoji를 버튼 아이콘으로 쓰는 것은 금지이며, 아이콘은 반드시 SVG여야 합니다.
  2. 선정 방법을 주세요:제품 톤에 따라 아이콘 세트를 고릅니다. SaaS는 Lucide, 따뜻한 톤은 Tabler Icons.
  3. 엔지니어링 디테일을 주세요:아이콘은 로컬로 내려받아 쓰며, CDN에 의존하지 않습니다.
  4. 「가능한가」에 답하세요:가능합니다. 이런 취향 결정은 isComposing과 같이 「문서와 디자인 규범」 장에 들어갑니다. 취향이 규칙으로 굳으면 AI가 생성할 때마다 지키므로, 매 버전을 사람이 직접 고를 필요가 없습니다.
⭐ 가산점취향의 두 층을 가리세요: Rule은 공통 하한(emoji 금지, SVG 사용)을 맡고, METHODOLOGY의 「사용자 경험 선호」는 이 프로젝트의 구체 선호를 맡습니다. 예를 들어 확인 버튼은 오른쪽 아래에 고정, 브랜드색을 쓰는 것. 두 층이 맞아야 취향이 완전합니다.
이 강의 페이지로 답변을 구성하세요 → 환경 사실을 Rule에 기록하기 세 가지 문서와 방법론 보존
Q29면접관
「이 규범에 14장이 있다고 했죠. 지금 60초를 줄 테니, 뼈대를 명확히 말해 보세요.」
🎯 무엇을 평가하는가
전체 관점과 정제 능력을 테스트합니다. 전경을 외우지 못하는 사람은 대개 그중 두세 조항만 써 본 것이고, 블록 구분과 기저 로직을 말할 수 있는 사람만이 방법론을 이야기할 자격이 있습니다.
🧭 답변 프레임워크
  1. 다섯 블록을 말하세요:프로세스 제어(중단점을 코딩 전에 둠), 품질 하한(완전한 구현, 대충 불수용), 문서 보존(결정이 대화를 넘어 남음), 환경과 보안(환경 사실을 한 번에 박아 넣음), 소통과 작문(앵커링과 자체 점검).
  2. 각각 대표 조항 하나를 주세요:파일 3개 초과 수정은 먼저 계획을 씀; 추측성 수정 금지; 세 문서가 각 차원을 맡음; 백업, 롤백, diff 심사 세 관문; 10라운드 초과 시 목표 복술.
  3. 공통 기저에 모으세요:모호한 기대를 실행 가능한 구체 동작으로 바꿉니다. 「품질에 주의하라」는 실행되지 않고, 「코드를 삭제하기 전에 반드시 명시적으로 선언하라」는 실행됩니다. 14장 각 장이 이 번역을 하고 있습니다.
⭐ 가산점장 번호를 맞출 수 있으면 더 셉니다: 환경과 보안 한 블록에 모델 설정, 데이터 형식, 기술 스택, 배포 네 장이 들어갑니다. 구조 안의 구체 장을 말할 수 있으면 규칙 원문을 읽었다는 증거이며, 60초에 말하는 것은 소화한 것입니다.
이 강의 페이지로 답변을 구성하세요 → 규칙의 가치: 각각이 실제 문제를 해결
Q30면접관
「내일 이 규칙을 회사 저장소에 그대로 옮기고 전원이 실행한다고 가정합시다. 지지하나요?」
🎯 무엇을 평가하는가
마무리 함정 문제입니다. 「지지합니다」라고 답하면 빠집니다: 이 규칙에는 저자 프로젝트의 환경 사실이 들어 있어, 그대로 옮기면 반드시 사고 납니다. 적응 방법론이 있는지를 보며, 답에는 취사가 있어야 합니다.
🧭 답변 프레임워크
  1. 먼저 막으세요:그대로 옮기는 것은 권하지 않습니다. 규칙에는 저자 프로젝트의 기술 스택, 포트, 형식 선정이 박혀 있고, 이 환경 사실은 여러분 회사와 맞지 않습니다. 14장을 그대로 옮기는 것보다 5장을 정선하는 편이 낫습니다.
  2. 네 동작을 주세요:삭제(중국어 콘텐츠 창작을 하지 않으면 작문 규범을 .cursor/rules/에서 빼 무관 컨텍스트를 줄임), 교체(기술 스택 선언을 회사 선정으로 바꿈), 조정(「파일 3개 초과 수정은 먼저 확인」의 임계값을 프로젝트에 맞게 조정, 신중한 프로젝트는 1, 빠른 프로토타입은 5까지 완화), 보완(팀이 AI가 반복해서 저지르는 오류를 새 규칙으로 씀).
  3. 검증 주기를 주세요:실제 프로젝트에서 일주일 가득 쓰고, 어떤 규칙이 트리거됐는지, 어떤 것은 한 번도 적용되지 않았는지 기록합니다. 한 번도 적용되지 않은 것은 지우고, 새로 밟은 함정을 새 규칙으로 씁니다.
  4. 이유를 말하세요:규칙은 코드와 같아, 유지하는 사람이 없으면 썩습니다. 들여오는 것은 시작일 뿐이고, 길러야 비로소 쓰는 것입니다.
⭐ 가산점폐루프를 완성하세요: 삭제·교체·조정·보완을 마친 버전은 오픈소스할 수 있고, 원 저장소 자체가 MIT License이며 Fork해 개조한 뒤 자신의 버전을 게시하도록 권장합니다. 여기까지 말할 수 있으면, 규칙을 지속 이터레이션할 수 있는 자산으로 본다는 뜻입니다.
이 강의 페이지로 답변을 구성하세요 → 규칙의 가치: 각각이 실제 문제를 해결 4단계 프로세스: 복술·PRD·확인·코딩
마지막 조언
이 30가지 질문을 준비하는 가장 좋은 방법은 실제 프로젝트에 적용해 보는 것입니다: xs_vibe_rules를 프로젝트에 넣고 2주 동안 사용해 보세요. 사고와 규칙이 모두 당신 자신의 이야기가 됩니다. 이야기가 있는 답변과 프레임워크를 암송하는 답변의 차이는 면접관이 순식간에 알아챕니다.