9 분 소요

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

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

Summary

앞의 네 편이 “무엇을 물을까” 였다면, 이 편은 “그래서 다음 주 면접을 어떻게 진행할까” 예요. 배경 설명은 없고, 그대로 가져다 쓸 수 있는 것들만 담았습니다.

핵심 원칙 하나만 다시 짚고 갈게요. AI 를 막지 말고, 쓰는 걸 옆에서 보세요. 이 원칙 하나가 실기 설계 전체를 결정합니다. 후보자가 AI 를 켜는 순간부터 우리는 정보를 얻기 시작하거든요. 어떤 순서로 시키는지, 어디서 멈추는지, 뭘 버리는지, 결과를 뭘로 확인하는지 — 전부 앉은 자리에서 보입니다.

💡 이 글에서 다루는 것

  • 실기 설계 원칙 6가지
  • 과제 A — 페어 바이브 코딩 (20~45분). 요구사항을 중간에 바꾸는 게 핵심이에요
  • 과제 B — 나쁜 PR 리뷰 (15~20분)
  • 과제 C — 장애 재현 디버깅 (30분)
  • 어떤 자리에 어떤 과제를 쓸지
  • 60분 · 90분 진행 시나리오 (분 단위 표)
  • 다섯 축 채점표 + 레벨별 기대치
  • 점수와 무관하게 탈락시켜야 하는 거부권 항목
  • 후보자의 역질문으로 보는 것, 그리고 레퍼런스 체크 질문
  • 시리즈 전체 요약 — 이것만 챙기면 됩니다



1. 실기 설계 원칙 6가지

① AI 를 허용하고, 화면을 공유받으세요
“쓰셔도 됩니다” 가 아니라 “평소 쓰시는 도구 그대로 쓰세요” 라고 명시하는 게 좋아요. 후보자가 눈치 보면서 안 쓰면 관찰할 게 없어집니다.

② 정답이 있는 문제를 내지 마세요
알고리즘 문제는 AI 가 즉시 풉니다. 대신 판단이 필요한 문제 를 내세요. 답이 여러 개이고, 어느 걸 고르는지가 정보가 되는 문제요.

③ 낯선 코드베이스를 주세요
빈 화면에서 시작하면 AI 가 다 해줍니다. 이미 있는 코드에 얹는 작업 이어야 읽는 능력이 드러나요. 우리 팀 코드의 축소판이면 가장 좋습니다.

④ 중간에 요구사항을 바꾸세요
이게 가장 강력한 장치 예요. 20분쯤 지났을 때 조건을 하나 추가하면, 지금까지 만든 걸 이해하고 있는 사람만 대응할 수 있습니다. 받아쓰기만 한 사람은 여기서 무너져요.

⑤ 시간 압박은 최소로
빨리 하는 걸 보려는 게 아니에요. 속도는 도구가 냅니다. 급하게 몰면 오히려 생각하는 과정을 안 보여주게 돼요.

⑥ 과제 결과물로 채점하지 마세요
완성 여부는 참고 자료일 뿐이에요. 채점은 과정과 그에 대한 설명 에서 합니다. 미완성인데 판단이 좋은 후보가, 완성했는데 설명 못 하는 후보보다 낫습니다.



2. 과제 A — 페어 바이브 코딩

가장 정보량이 많은 과제예요. 시간이 부족하면 20분으로 줄여도 됩니다.

준비물

  • 500~2000줄짜리 실제로 돌아가는 작은 서비스. 우리 팀 스택으로 만드세요
  • README 는 일부러 부실하게. 코드를 읽어야 알 수 있게 두세요
  • 테스트 몇 개, 그리고 일부러 남긴 미묘한 기존 동작 하나 (나중에 깨지는지 볼 용도)

과제 문장 (그대로 쓰셔도 됩니다)

“이 서비스에 주문 취소 기능을 추가해 주세요. 평소 쓰시는 AI 도구 그대로 쓰시면 되고, 화면 공유만 부탁드립니다. 완성이 목표가 아니라 어떻게 하시는지 를 보려는 거라 편하게 하시면 돼요. 중간중간 왜 그렇게 하시는지만 말씀해 주세요.”

진행 (45분 기준)

시간 하는 것 관찰 포인트
0~5분 후보자가 코드를
파악하는 시간
뭘 먼저 여는가.
AI 에게 구조를
정리시키는가
5~20분 구현 한 번에 시키는가
쪼개는가.
계획을 먼저 받는가
20분 요구사항 추가
(아래 참고)
지금까지 만든 걸
이해하고 있는가
20~40분 대응 되돌리는가,
얹는가, 판단 근거는
40~45분 설명 자기 코드를
설명할 수 있는가

20분에 던질 요구사항 변경 (하나만 고르세요)

  • “아, 취소는 결제 완료 후 30분 안에만 되게 해주세요.” → 시간 조건, 타임존, 엣지 케이스
  • “취소하면 재고를 되돌려야 하는데, 그 사이에 다른 사람이 주문했을 수도 있어요.” → 동시성, 트랜잭션
  • “부분 취소도 돼야 해요.” → 데이터 모델을 건드려야 함
  • “취소 이력이 감사 로그에 남아야 합니다.” → 3편 패턴 ⑥ 과 연결

채점 (이 과제만의 포인트)

관찰
시작 방식 기존 코드를
먼저 파악
바로 시킴
작업 단위 리뷰 가능한
크기로 쪼갬
통째로 던짐
읽는 지점 데이터·권한 쪽은
직접 읽음
아무 데도 안 읽음
요구사항 변경 영향 범위를
먼저 말함
그냥 다시 시킴
검증 테스트를 돌리거나
직접 확인
코드가 나오면 끝
왜 그렇게 하는지
계속 설명
침묵. 화면만 봄

💡 가장 결정적인 순간은 요구사항을 바꿨을 때예요. 좋은 후보자는 즉시 “그러면 여기랑 여기가 영향을 받겠네요” 라고 말합니다. 코드를 이해하고 있다는 증거예요. 반대로 아무 말 없이 AI 에게 새 요구사항을 그대로 던지면, 지금까지 만든 걸 모르고 있다는 뜻입니다.



3. 과제 B — 나쁜 PR 리뷰

3편에서 자세히 설명한 과제예요. 여기서는 진행표만 정리할게요.

한 줄 요약 — 흠을 일부러 심은 100~150줄짜리 PR 을 주고 “승인하시겠어요?” 라고 묻습니다.

시간 하는 것
0~5분 PR 을 읽습니다
5~15분 리뷰. AI 사용 권장
15~20분 발견한 것을 심각도 순으로 정렬

심을 흠은 3편의 여섯 가지 패턴에서 고르세요. 특히 조용한 삭제(기존 감사 로그 호출이 사라진 것)를 하나 넣으면 변별력이 좋습니다.

이 과제의 장점 — 준비 비용이 낮고(한 번 만들면 계속 씁니다), 시간이 짧고, AI 로 쉽게 통과되지 않아요. 시간이 딱 하나만 낼 수 있으면 이걸 하세요.



4. 과제 C — 장애 재현 디버깅

시니어 이상, 또는 운영 책임이 있는 자리에 쓰세요.

준비물

  • 돌아가는 서비스 + 가끔만 재현되는 버그 하나
  • 예: 특정 타임존 사용자에게만 날짜가 하루 밀림 / 동시 요청일 때만 카운터가 어긋남 / 캐시가 살아 있는 동안만 옛 값이 나옴

과제 문장

“사용자 문의가 들어왔어요. ‘어제 등록한 게 오늘 목록에 안 보인다’ 고요. 재현이 잘 안 됩니다. 30분 드릴게요, 원인을 찾아주세요. AI 쓰셔도 됩니다.”

채점

관찰
첫 행동 재현 조건을
좁히려고 함
코드부터 읽기
시작
가설 세우고 버립니다 하나에 매달림
AI 사용 정보 수집·가설 검증에
“고쳐줘” 만 반복
질문 로그·환경·사용자
정보를 요구함
안 물어봄
못 찾았을 때 어디까지 좁혔는지
정리해서 말함
그냥 못 찾음

💡 못 찾아도 됩니다. 이 과제의 목적은 정답이 아니라 접근 방식 이에요. 30분 안에 원인을 특정 못 해도, “여기까지는 아닌 걸 확인했고 남은 후보는 이 둘입니다” 라고 정리하면 상위 점수를 주세요. 실무에서 딱 그렇게 일하거든요.



5. 어떤 자리에 어떤 과제를 쓸까

자리 추천 조합 이유
주니어 B(20분) 리뷰 능력이
성장 가능성의 지표
미들 A(20분) + B(15분) 만드는 것과
보는 것을 둘 다
시니어 A(45분) 또는
B + C
판단과 디버깅
리드 B(15분) + 대화 실기보다
팀 전파·규칙 경험
시간 없음 B 만 가성비 최고



6. 60분 진행 시나리오

실기 없이 대화로만 60분을 채우는 버전이에요. 준비 비용이 가장 낮습니다.

시간 하는 것 쓸 질문
0~5분 아이스브레이킹 +
면접관 솔직 고백
아래 대사 참고
5~15분 도구 구성과
최근 작업
1편 Q1 · Q2 · Q3
15~30분 검증과 디버깅 3편 Q1 · Q2 ·
Q9(못 고친 버그)
30~40분 도구 운용 2편 Q1 · Q3 · Q4
40~50분 경계와 사고 4편 Q3 · Q4 · Q12
50~55분 팀·전파
(시니어 이상)
2편 Q10 ·
4편 Q11
55~60분 후보자 역질문 아래 8장 참고

0~5분에 할 고백

이 대사 하나가 면접의 질을 크게 바꿔요.

“저는 AI 코딩을 매일 쓰는 사람은 아니에요. 그래서 오늘은 기술 퀴즈보다는 어떻게 일하시는지 를 여쭤보려고 합니다. 제가 못 알아듣는 게 있으면 되물을 테니, 최대한 쉽게 설명해 주시면 좋겠어요.”

이렇게 열면 설명 능력까지 덤으로 볼 수 있어요. 실제 업무에서 이 사람은 비개발자에게 기술 결정을 설명해야 할 겁니다. 그리고 후보자도 방어를 풀어요.

90분 버전 (실기 포함)

시간 하는 것
0~10분 오프닝 + 1편 Q1~Q3
10~30분 과제 A (20분 압축판.
요구사항 변경은 12분에)
30~45분 과제 B (PR 리뷰)
45~60분 실기에 대한 꼬리 질문
(“아까 여기서 왜…”)
60~75분 3편 · 4편 질문
75~85분 팀·전파
85~90분 역질문

💡 45~60분 구간이 진짜 채점 구간이에요. 실기 중에 본 장면을 그대로 되물으세요. “아까 여기서 AI 가 준 걸 바로 넣으셨는데, 읽어보신 건가요?” 같은. 실기는 질문거리를 만드는 장치 라고 생각하면 정확합니다.



7. 다섯 축 채점표

시리즈 전체를 다섯 축으로 압축했어요. 각 축을 4단계로 매기고, 자리 레벨에 따라 기대치를 다르게 두면 됩니다.

무엇을 보나 어디서 나오나
① 설명 자기 코드를
설명하는가
1편 축1 · 과제 A
② 검증 뭘 근거로
믿는가
3편 전체 · 과제 B
③ 분할 작업을
쪼개는가
2편 Q4 · 과제 A
④ 경계 안 맡기는 영역이
있는가
4편 전체
⑤ 협업 팀으로
굴려봤는가
2편 Q2 · Q10

4단계 기준

등급 ① 설명 ② 검증 ③ 분할 ④ 경계 ⑤ 협업
4 탁월 대안까지
설명
사다리
4층 이상
기준이
명확
사고 경험에서
나온 방어선
규칙을
만들고 전파
3 충분 뭘 하는지
정확히 설명
2~3층 쪼개서
진행
영역이
명확
규칙 파일을
팀과 공유
2 부족 대충
설명
돌려보기
+ 하나
가끔
쪼갬
막연함 혼자
1 위험 화면을
다시 읽음
돌려보기만 통째로
던짐
없음 없음

레벨별 기대치

레벨 ① 설명 ② 검증 ③ 분할 ④ 경계 ⑤ 협업
주니어 2+ 2+ 2+ 2+
미들 3+ 3+ 3+ 2+ 2+
시니어 3+ 4 3+ 3+ 3+
리드 3+ 3+ 3+ 3+ 4

⚠️ ①번 축에서 1등급이 나오면 다른 축이 아무리 높아도 재검토하세요. 자기 코드를 설명 못 하는 건 1편에서 말한 위임형이고, 그 사람이 만든 코드는 조직에 부채로 쌓입니다. 특히 리뷰 문화가 약한 팀이면 치명적이에요.



8. 거부권 항목 — 점수와 무관하게

아래 중 하나라도 나오면 총점과 관계없이 탈락으로 두는 걸 권합니다. 이건 실력이 아니라 위험 이라서요.

항목
회사 코드를 개인 계정에
올린 걸 아무렇지 않아 함
우리 회사에서도
똑같이 합니다
사고 책임을 전부
도구·모델에 돌림
권한을 줄 수 없어요
자기 대표 프로젝트를
전혀 설명 못 함
이력이 본인 것이
아닐 수 있습니다
실기 중 화면 공유를
거부하거나 회피
관찰이 불가능해요
전 직장·전 동료를
일방적으로 비난
AI 와 무관한
고전적 신호입니다

💡 세 번째 항목은 조심해서 적용하세요. 긴장해서 말이 안 나오는 것모르는 것 은 다릅니다. 한 번 더 편하게, 다른 각도로 물어보고 판단하세요. “천천히 하셔도 돼요, 아무 파일이나 하나 골라서 얘기해 주세요” 정도로요.



9. 후보자의 역질문으로 보는 것

마지막 5분은 정보량이 큽니다. 좋은 후보자는 이런 걸 물어요.

이런 질문을 하면 읽히는 것
“팀에서 AI 도구를
어떻게 쓰나요?”
들어와서 어떻게
일할지 그리고 있어요
“코드 리뷰는
어떻게 하세요?”
3편의 병목을
겪어본 사람
“규칙 파일 같은 게
있나요?”
팀 자산 감각이
있습니다
“AI 로 만든 코드에 대한
사내 규정이 있나요?”
4편의 경계 감각
아무것도
안 물어봄
관심이 없거나
이미 마음을 접었어요

⚠️ 그리고 이건 우리가 답할 준비를 해가야 하는 질문들 이기도 해요. 좋은 후보자일수록 여기서 회사를 평가합니다. “저희는 아직 정리 중이에요” 도 괜찮은 답이에요 — 솔직하면 됩니다. 나쁜 건 얼버무리는 거고요.



10. 레퍼런스 체크를 한다면

전 동료에게 물을 수 있는 상황이라면, 이 세 개가 가장 정확해요.

  • “그분이 만든 코드를 다른 사람이 이어받기 쉬웠나요?” — ①설명 축을 밖에서 검증합니다
  • “급할 때 그분이 넣은 코드 때문에 문제가 난 적 있나요?” — ②검증 축
  • “그분이 팀에 새로 들여온 방식이 있나요?” — ⑤협업 축

세 질문 다 “AI” 라는 단어가 안 들어가 있어요. 일부러 그렇습니다. 도구를 물으면 도구 얘기가 돌아오고, 결과를 물으면 실력 얘기가 돌아와요.



11. 시리즈 전체 요약

다섯 편을 한 장으로 줄이면 이렇습니다.

한 줄
1편 AI 를 썼는지 묻지 말고,
어떻게 썼는지 를 물어요
2편 프롬프트 문장력이 아니라
맥락 관리 가 실력이에요
3편 만든 양이 아니라
뭘 근거로 믿었는지 를 봐요
4편 속도는 가르쳐도
경계 감각 은 못 가르쳐요
5편 (지금) AI 를 막지 말고
쓰는 걸 옆에서 보세요

시간이 정말 없다면 이 세 개

전부 못 읽으실 걸 알아요. 딱 세 개만 챙기면 면접은 굴러갑니다.

  1. “AI 가 끝까지 못 고친 문제 하나만 처음부터 끝까지 얘기해 주세요” — 바닥 실력을 잽니다
  2. “어디까지 자동 승인해두고 쓰세요?” — 경계 감각을 잽니다
  3. 나쁜 PR 하나 주고 “승인하시겠어요?” — 검증 능력을 잽니다

여기에 되묻기 세 마디만 준비하면 돼요. “그게 잘못됐다는 건 어떻게 아셨어요?” / “그걸 직접 하셨다면 뭐가 달라졌을까요?” / “지금 다시 한다면 똑같이 하실 건가요?”

마지막으로

이 시리즈를 쓰면서 계속 마음에 걸린 게 하나 있어요. 면접관이 후보자를 의심하는 도구로만 읽힐까 봐서요. 그건 아니에요.

지금 바이브 코딩을 하는 사람들 대부분은 성실하게 새 도구를 익히고 있는 사람들이에요. 우리가 골라내야 하는 건 AI 를 쓰는 사람 이 아니라, 자기가 넣은 코드의 주인이 아닌 사람 입니다. 그 둘은 전혀 다르고, 앞의 다섯 편은 그 둘을 가르기 위한 도구예요.

그리고 이건 결국 새로운 이야기가 아니에요. 예전에도 우리는 “이 사람이 자기 코드에 책임을 지는가” 를 봤습니다. 도구가 바뀌었을 뿐, 질문은 그대로예요.

일단 오늘은 여기까지…..
면접 잘 보시고, 좋은 분 만나시길 바랄게요.


이전 글 ←: (4/5) 사고는 여기서 난다 — 보안 · 비용 · 라이선스 · 사내 규정

📎 비슷한 포맷의 면접관 가이드로 AWS 전문가 면접 5부작도 있어요. 클라우드 쪽 면접이 잡히면 같이 보시면 됩니다.