(2/5) 도구를 어떻게 굴리나 — 컨텍스트 · 규칙 파일 · 계획, 그리고 질문

August 6, 2026 10 분 소요

🧪 바이브 코딩 면접 가이드 — 면접관을 위한 배경 지식과 질문 5부작 — “이 사람이 짠 코드인지 AI 가 짠 코드인지 모르겠어요.” 이제 거의 모든 면접에서 부딪히는 문제예요. AI 를 못 쓰게 막고 보는 건 답이 아니고, 그렇다고 완성된 산출물을 믿을 수도 없고요. 이 시리즈는 면접관 입장에서 필요한 것만 골라 담았습니다. 각 편은 ① 5분이면 따라오는 배경 설명 → ② 실제로 던질 질문 → ③ 답을 못 알아들어도 쓸 수 있는 채점 포인트 순서로 이어져요. 전체 그림과 판별 전략을 먼저 잡고(1편), 도구 운용(2편), 검증·리뷰·디버깅(3편), 보안·비용·규정(4편), 실기 과제와 60분 진행 시나리오(5편)까지 갑니다. 전체 5편.

뭘 물어야 하나 — 전체 그림과 판별 전략
도구를 어떻게 굴리나 — 컨텍스트 · 규칙 파일 · 계획 ← 지금 글
AI 코드를 뭘로 믿나 — 검증 · 리뷰 · 디버깅
사고는 여기서 난다 — 보안 · 비용 · 라이선스 · 사내 규정
실기 과제 + 60분 진행 시나리오 + 채점표

Summary

바이브 코딩 면접에서 가장 많이 나오는 오답이 있어요. 후보자에게 “AI 를 어떻게 쓰세요?” 라고 물었을 때 나오는 이런 답이요.

“프롬프트를 구체적으로 씁니다. 역할을 주고, 예시를 넣고, 단계별로 생각하게 시켜요.”

틀린 말은 아닌데, 2023년에 멈춰 있는 답 이에요. 요즘 코딩 에이전트는 문장을 예쁘게 써서 성능이 갈리지 않습니다. 갈리는 건 모델이 무엇을 보고 있느냐 예요. 같은 문장을 던져도, 관련 파일을 제대로 물려준 사람과 저장소 전체를 뭉텅이로 던진 사람의 결과가 완전히 다릅니다.

그래서 이 편은 맥락 관리 를 봅니다. 면접관이 알아야 할 배경은 생각보다 적어요. 다섯 개 정도만 알면 후보자 말이 다 들립니다.

💡 이 글에서 다루는 것

5분이면 되는 배경 — 토큰 · 컨텍스트 창 · 모델은 기억을 못 한다는 것

컨텍스트 오염 — 긴 세션이 왜 갑자기 멍청해지는가

규칙 파일(CLAUDE.md · AGENTS.md) — 개인 메모인지 팀 자산인지가 갈림

계획과 실행의 분리, 그리고 작업을 쪼개는 습관

MCP · 서브에이전트 · 병렬 작업 — 붙인 이력보다 뗀 이력

모델 선택과 비용 감각 (맛보기, 자세한 건 4편)

실제로 던질 질문 10개 + 채점 포인트

이 영역의 레드 플래그 5가지

1. 배경 — 5분이면 되는 최소 지식

토큰과 컨텍스트 창

모델은 글자를 토큰 이라는 조각 단위로 읽어요. 한글은 대략 한 글자가 1~2 토큰, 영어는 한 단어가 1 토큰 언저리라고 보면 됩니다. 코드는 좀 더 잘게 쪼개져요.

컨텍스트 창 은 모델이 한 번에 볼 수 있는 총량이에요. 요즘 코딩용 모델은 대략 20만~100만 토큰을 봅니다. 감을 잡자면 20만 토큰이면 중간 규모 저장소의 상당 부분 이 들어가요. 넉넉해 보이지만, 실무에서는 금방 찹니다.

모델은 기억을 못 합니다

이게 면접관이 꼭 알아야 할 지점이에요. 모델은 매번 백지에서 시작 합니다. “아까 말했잖아요” 가 통하는 건, 도구가 이전 대화를 매번 통째로 다시 보내주기 때문이에요. 진짜 기억이 아니라 매 요청마다 다시 읽히는 것 입니다.

여기서 두 가지가 따라 나와요.

대화가 길어질수록 매 요청이 비싸지고 느려집니다. (그래서 비용 이야기가 따라붙어요)
대화가 길어질수록 초반 내용이 잘려나가거나 희석됩니다.

컨텍스트 오염 — 긴 세션이 갑자기 멍청해지는 이유

실무에서 제일 자주 겪는 현상이에요. 두 시간쯤 한 세션을 굴리면 어느 순간 결과가 눈에 띄게 나빠집니다. 원인은 대개 이 셋이에요.

원인	무슨 일이 생기나
틀린 시도가 쌓임	실패한 코드와 잘못된 가설이 대화에 남아 계속 참고됨
압축(요약)이 일어남	도구가 오래된 대화를 요약해서 줄이는데, 중요한 세부가 날아감
관련 없는 파일이 너무 많이 들어옴	신호 대비 잡음이 커져서 엉뚱한 곳을 고치기 시작

대처법은 의외로 단순해요. 새 세션을 시작하는 겁니다. 지금까지의 결론만 요약해서 넘기고 나머지는 버리는 거죠. 그래서 이런 질문이 성립합니다.

💡 “작업하다 보면 AI 답이 점점 이상해지는 순간이 오잖아요. 그때 뭘 하세요?”

이게 이 편에서 가장 가성비 좋은 질문 이에요. 실제로 하루 종일 굴려본 사람만 이 현상을 알거든요. “세션을 새로 팝니다” 또는 “지금까지 정리해서 새로 시작해요” 가 나오면 진짜로 매일 쓰는 사람입니다. “그런 적 없는데요” 는 짧게만 써봤다는 뜻이에요.

왜 파일 검색 방식까지 봐야 하나

에이전트는 저장소에서 필요한 파일을 스스로 찾아 읽어요. 이때 어떻게 찾는지 에 따라 정확도가 크게 달라집니다. 텍스트로 긁는 방식(grep)과 코드 구조를 이해하는 방식은 결과가 달라요.

📎 이 차이가 궁금하면 LSP vs grep — AI 에이전트의 코드 탐색 편에 정리해뒀어요. 면접에서는 여기까지 알 필요는 없지만, 후보자가 이 얘기를 꺼내면 꽤 깊게 판 사람입니다.

2. 배경 — 규칙 파일

이게 뭐냐면

프로젝트 루트에 두는 “이 저장소에서 일할 때 지켜야 할 것” 문서 예요. 도구마다 이름이 다릅니다.

도구 계열	파일 이름
Claude Code	`CLAUDE.md`
범용 · 다중 도구	`AGENTS.md`
Cursor	`.cursor/rules`
GitHub Copilot	`.github/copilot-instructions.md`

내용은 대개 이런 것들이에요. 빌드·테스트 명령, 코딩 컨벤션, 건드리면 안 되는 디렉터리, 배포 절차, 커밋 규칙.

면접에서 이게 왜 중요하냐면

규칙 파일은 개인 실력이 팀 자산으로 바뀌는 지점이에요.

혼자 쓰는 사람은 규칙 파일이 없거나, 있어도 개인 취향 메모예요. 팀으로 굴려본 사람은 규칙 파일을 git 에 넣고, 리뷰하고, 사고가 날 때마다 갱신 합니다. 이 차이가 협업 경험을 아주 정확하게 드러내요.

특히 좋은 신호가 하나 있어요. “사고 나서 규칙 파일에 한 줄 추가했다” 는 이야기예요. 예를 들면 이런 것들이요.

“운영 DB 에는 절대 직접 붙지 말 것” (한 번 붙었다가 데인 거죠)

“마이그레이션 파일은 사람이 직접 검토” (자동 생성으로 사고 난 거고요)

“이 폴더는 외부 테마 원본이라 수정 금지” (덮어써서 날린 적 있는 거예요)

이런 줄이 있는 저장소는 AI 를 운영에 실제로 태워본 팀 입니다. 이력서 열 줄보다 이 한 줄이 정확해요.

3. 배경 — 계획과 실행을 나누는 습관

한 번에 다 시키기 vs 쪼개서 시키기

초보와 숙련자가 가장 크게 갈리는 지점이에요.

초보 — “로그인 기능 만들어줘” 하고 15분 기다린 뒤, 나온 결과를 통째로 받거나 통째로 버립니다.
숙련자 — 먼저 계획만 시킵니다. 어떤 파일을 어떻게 고칠 건지 목록을 받고, 그걸 읽고 고친 다음, 그 계획대로 실행시켜요.

왜 이게 중요하냐면, 틀린 방향으로 500줄을 짜고 나면 되돌리는 비용이 크기 때문 이에요. 계획 단계에서 잡으면 문장 두 줄 고치는 걸로 끝납니다. 요즘 도구들이 계획 모드(plan mode)를 따로 두는 이유가 이거예요.

작업 크기 감각

숙련자는 한 번에 시키는 작업 크기가 일정 해요. 대략 “리뷰 가능한 크기” 로 자릅니다. 이건 사실 AI 이전의 좋은 습관(작은 PR)과 정확히 같은 얘기예요.

💡 “한 번에 얼마나 큰 단위로 시키세요?” 라고 물어보세요. 답이 “제가 읽고 판단할 수 있는 만큼” 계열이면 좋은 신호예요. “그냥 다 시키고 안 되면 다시 시킵니다” 는 위임형(1편) 신호고요.

멈추는 지점이 있는가

가장 미묘하지만 가장 중요한 신호예요. 잘하는 사람은 작업 중간에 반드시 멈춰서 직접 읽는 지점 이 있어요. 대개 이런 곳입니다.

데이터베이스 스키마가 바뀔 때
권한·인증 로직을 건드릴 때
돈·개인정보가 지나가는 경로
삭제가 일어나는 코드
운영 환경에 나가는 설정

이 목록을 묻지도 않았는데 후보자가 먼저 말하면, 그건 실제로 사고를 겪고 만든 방어선이에요.

4. 배경 — 도구 확장 (MCP · 서브에이전트 · 병렬)

여기부터는 “쓰면 좋은 것” 이지 필수는 아니에요. 모른다고 감점하지 마세요. 다만 안다면 어느 정도 깊이인지는 봐야 합니다.

MCP

에이전트에 외부 도구를 붙이는 표준 방식 이에요. 사내 위키, 티켓 시스템, 데이터베이스, 사내 API 같은 걸 AI 가 직접 조회하게 만드는 겁니다.

면접에서 볼 지점은 하나예요. 직접 만들어봤는가, 아니면 남이 만든 걸 붙여만 봤는가. 만들어봤다면 인증과 권한 이야기가 자연스럽게 나옵니다.

📎 MCP 서버 로컬로 만들기와 원격 HTTP · 인증 붙여 만들기 편을 훑어두면 후보자 답의 깊이를 재기 쉬워요.

⚠️ 그리고 이건 꼭 물어보세요. “MCP 붙였다가 뗀 적 있나요?” 도구를 많이 붙이면 컨텍스트를 잡아먹어서 오히려 성능이 떨어집니다. 뗀 이력이 있는 사람이 진짜 굴려본 사람 이에요. 붙인 개수 자랑만 하면 수집형(1편) 신호입니다.

서브에이전트

큰 작업을 여러 에이전트에게 나눠 맡기는 방식이에요. 조사 담당, 구현 담당, 리뷰 담당으로 나누는 식이요. 잘 쓰면 컨텍스트 오염을 막는 데 효과적입니다 — 조사하느라 지저분해진 맥락이 본 대화에 안 섞이거든요.

병렬 작업

여러 작업을 동시에 굴리는 겁니다. 이때 같은 폴더에서 두 개를 동시에 돌리면 서로 파일을 덮어써서 엉망이 돼요. 그래서 작업마다 폴더를 분리하는데, git 에서는 이걸 worktree 라고 합니다.

이 얘기를 하는 후보자는 꽤 깊게 들어간 사람이에요. 다만 여기서 물어야 할 건 속도가 아니라 합치는 비용 입니다.

💡 “동시에 여러 개 돌리면 나중에 합칠 때 충돌 안 나요?” — 이 질문에 실감 나는 답이 나오면 진짜예요. 병렬로 굴리면 속도는 빨라지는데 합치는 데서 시간을 다시 뱉습니다. 그걸 겪어본 사람은 “충돌 날 만한 건 애초에 같이 안 돌려요” 처럼 답해요.

📎 이 주제는 여러 Claude 세션을 git worktree 로 격리하기와 병렬 PR 충돌 오케스트레이션 편에서 실제로 부딪힌 기록을 볼 수 있어요. 병렬 에이전트를 본격적으로 굴린 이야기는 Orca 전체 그림 편에 있고요.

모델 선택

같은 도구에서도 모델을 골라 쓸 수 있어요. 잘하는 사람은 작업마다 다른 모델 을 씁니다. 단순 변환은 싼 모델, 설계나 어려운 디버깅은 비싼 모델처럼요.

이건 비용 감각과 직결되는데, 자세한 건 4편에서 다룰게요.

5. 던질 질문 10개

앞의 배경을 다 안 읽어도 이 질문들은 그대로 쓸 수 있어요. 채점 포인트를 같이 붙였습니다.

Q1. 새 저장소에서 처음 작업을 시작할 때, 첫 30분에 뭘 하세요?

왜 묻나 — 맥락을 만드는 습관을 봅니다. 이게 이 편에서 가장 강력한 오프닝 이에요.
👍 좋은 답 — 구조를 먼저 파악시키고, 규칙 파일을 만들거나 갱신하고, 빌드·테스트가 도는지 확인합니다. “AI 한테 이 저장소 구조를 먼저 정리시켜요” 도 좋아요.
⚠️ 걸리는 답 — “바로 시킵니다.” 작은 프로젝트만 해본 사람이에요.

Q2. 규칙 파일(CLAUDE.md 같은 것)을 쓰시나요? 거기 뭐가 적혀 있어요?

왜 묻나 — 개인 작업인지 팀 작업인지가 여기서 갈립니다.
👍 좋은 답 — 파일이 있고, 사고 때문에 추가된 줄 이 있어요. git 에 커밋해서 팀이 같이 쓴다면 더 좋습니다.
⚠️ 걸리는 답 — “그런 거 안 씁니다” 또는 “예시 그대로 두고 있어요.” 후자는 만들고 관리를 안 한 거예요.

Q3. 작업하다 AI 답이 이상해지기 시작하면 어떻게 하세요?

왜 묻나 — 컨텍스트 오염을 겪어봤는지. 하루 종일 굴려본 사람만 압니다.
👍 좋은 답 — 세션을 새로 시작하고 결론만 옮깁니다. “요약을 직접 써서 넘겨요” 면 더 좋아요.
⚠️ 걸리는 답 — “계속 다시 시켜요” 또는 “그런 적 없어요.”

Q4. 한 번에 시키는 작업 단위가 어느 정도예요?

왜 묻나 — 작업 분할 감각. 리뷰 습관과 직결됩니다.
👍 좋은 답 — 기준이 있어요. “제가 읽을 수 있는 만큼”, “파일 서너 개 넘어가면 쪼갭니다” 같은.
⚠️ 걸리는 답 — “기능 하나 통째로요” 만 반복. 3편(검증)에서 더 파보세요.

Q5. 시키기 전에 계획을 먼저 받아보시나요?

왜 묻나 — 되돌리는 비용을 아는지 봅니다.
👍 좋은 답 — 계획을 먼저 받고 고쳐서 실행시킵니다. “계획 단계에서 틀린 걸 잡는 게 훨씬 싸요” 같은 말이 나오면 좋아요.
⚠️ 걸리는 답 — 계획 없이 바로 실행. 또는 계획을 받긴 하는데 안 읽어요.

Q6. AI 한테 절대 안 맡기는 작업이 있나요? 왜요?

왜 묻나 — 경계 감각. 1편 Q6 과 같은 질문인데, 여기서는 이유의 구체성 을 봅니다.
👍 좋은 답 — 영역이 명확하고 이유가 경험에서 나와요. “마이그레이션은 직접 읽어요, 한 번 데였거든요.”
⚠️ 걸리는 답 — “다 맡깁니다” 또는 이유가 막연해요.

Q7. 모델을 바꿔가며 쓰시나요? 어떤 기준으로요?

왜 묻나 — 비용·성능 감각과 도구 이해도.
👍 좋은 답 — 작업 성격에 따라 나눕니다. 실패했을 때 올리는 경로도 있고요.
⚠️ 걸리는 답 — “제일 좋은 거 하나만 씁니다” 는 중립이에요(팀 정책일 수도 있으니 감점 X). “싼 게 좋아서 싼 것만” 인데 품질 얘기가 없으면 걸립니다.

Q8. 도구를 붙였다가 뗀 적 있나요?

왜 묻나 — 수집형 판별. 뗀 이력이 진짜 사용자의 증거예요.
👍 좋은 답 — 구체적인 이유가 나와요. “컨텍스트만 잡아먹고 실제로 안 쓰더라고요”, “느려져서 뺐어요.”
⚠️ 걸리는 답 — 붙인 것만 잔뜩 나열하고 뗀 적은 없어요.

Q9. 여러 작업을 동시에 굴려보신 적 있나요? 합칠 때 어떠셨어요?

왜 묻나 — 병렬 경험의 진위. 속도가 아니라 합치는 비용 을 물어야 해요.
👍 좋은 답 — 충돌 이야기가 나옵니다. 충돌 날 만한 작업은 애초에 분리한다는 판단이 있으면 아주 좋아요.
⚠️ 걸리는 답 — “동시에 10개 돌립니다” 만 자랑하고 합치는 얘기가 없어요. 안 합쳐본 거예요.

Q10. 팀원한테 이 방식을 전파해본 적 있나요?

왜 묻나 — 시니어·리드 후보라면 이게 핵심이에요. 혼자 빨라지는 것과 팀을 빠르게 만드는 건 다른 능력입니다.
👍 좋은 답 — 규칙 파일 공유, 사내 가이드 작성, 페어 세션 같은 구체적 행동이 나와요. 반발이 있었다 는 이야기가 나오면 진짜입니다.
⚠️ 걸리는 답 — “다들 알아서 쓰죠.” 전파를 시도해본 적이 없는 거예요.

6. 이 영역의 레드 플래그 5가지

신호	왜 걸리나
프롬프트 문장 기법 얘기만 함	2023년에 멈춰 있어요. 맥락 관리 경험이 없습니다
컨텍스트가 길어질 때 생기는 문제를 모름	짧게만 써본 거예요
도구를 붙인 이력만 있고 뗀 적 없음	실사용이 아니라 수집일 확률이 높아요
규칙 파일이 없거나 기본 예시 그대로	팀으로 안 굴려봤습니다
병렬 자랑은 하는데 충돌 얘기가 없음	합쳐본 적이 없어요

⚠️ 반대로 감점하면 안 되는 것 도 짚을게요. MCP 를 모른다, 서브에이전트를 안 써봤다, 병렬을 안 해봤다 — 이건 전부 필수가 아니에요. 조직 정책상 못 쓰는 경우도 많고요. 필수는 Q1~Q6 이고, Q7~Q10 은 위쪽 등급을 가르는 데 쓰세요.

7. 정리

이 편을 한 문장으로 줄이면 이거예요.

프롬프트를 잘 쓰는 사람이 아니라, 모델이 뭘 보고 있는지를 관리하는 사람을 찾으세요.

그리고 질문 하나만 챙긴다면 Q3 입니다. “AI 답이 이상해지기 시작하면 뭘 하세요?” — 이 질문은 실제 사용 시간을 거의 정확하게 재요. 하루에 30분 쓰는 사람과 하루 종일 쓰는 사람이 여기서 갈립니다.

일단 오늘은 여기까지…..
다음 글에서는 검증을 파볼게요. AI 가 그럴듯하게 틀린 코드를 줬을 때 그걸 어떻게 잡아내는지, 테스트를 AI 가 짜면 뭐가 문제인지, 그리고 “읽지 않은 코드” 를 들고 있는 후보자를 어떻게 걸러내는지까지 정리해 보겠습니다.

이전 글 ←: (1/5) 뭘 물어야 하나 — 전체 그림과 판별 전략
다음 글 →: (3/5) AI 코드를 뭘로 믿나 — 검증 · 리뷰 · 디버깅

X Facebook LinkedIn Bluesky