(1/5) 바이브 코딩하는 사람, 뭘 물어야 하나 — 면접관을 위한 전체 그림과 판별 전략

August 6, 2026 13 분 소요

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

Summary

“개발자를 뽑는데, 이게 이 사람이 짠 코드인지 AI 가 짠 코드인지 모르겠어요.”

요즘 면접장에서 제일 자주 나오는 말이에요. 과제를 내면 다들 완성해 옵니다. 그것도 아주 깔끔하게요. README 도 좋고, 폴더 구조도 교과서 같고, 심지어 테스트도 있어요. 그런데 물어보면 자기 코드를 설명 못 하는 사람이 섞여 있습니다.

여기서 많은 면접관이 잘못된 대응을 해요. “그럼 AI 못 쓰게 하고 보면 되겠네” 라고요. 그건 자동차 운전기사를 뽑으면서 자전거를 태워보는 것과 같아요. 실제 업무에서는 AI 를 쓸 건데, AI 를 뺀 상태의 실력을 재는 건 그냥 다른 걸 측정하는 겁니다.

정확한 진단은 이거예요. 산출물과 실력 사이의 연결선이 끊어졌다. 예전엔 “이걸 만들었다 = 이걸 만들 줄 안다” 였는데, 이제는 아니에요. 그러면 신호를 다른 데서 찾아야 합니다. 다행히 판단의 흔적 은 아직 위조가 어려워요. 이 시리즈는 그 흔적을 캐내는 질문들을 정리한 글이에요.

💡 이 글에서 다루는 것

바이브 코딩이라는 말의 원래 뜻과 현업에서 쓰는 뜻 (이거 다릅니다)

왜 기존 면접 방식이 무너졌나 — 신호별로 하나씩

“AI 금지하고 보면 되죠” 가 왜 틀렸고, 대신 뭘 해야 하는지

후보자를 네 갈래로 먼저 가르기 — 증폭 · 확장 · 위임 · 수집

채점 3축 — 설명 가능성 · 검증 습관 · 사고 책임

GitHub · 포트폴리오 읽는 법 (커밋 크기를 보세요)

어느 포지션에나 통하는 공통 오프닝 질문 6개 + 채점 포인트

면접관이 하면 안 되는 것

1. 바이브 코딩이 뭐냐면

면접에서 이 단어가 나오면, 후보자가 어느 쪽 뜻으로 쓰는지부터 확인해야 해요. 두 뜻이 꽤 다르거든요.

원래 뜻 — “코드가 있다는 걸 잊는 것”

이 표현을 퍼뜨린 사람은 안드레이 카파시예요. 원래 뉘앙스는 이랬습니다.

자연어로 하고 싶은 걸 말하고, AI 가 짠 코드는 읽지 않고, 돌려보고 이상하면 다시 말한다. 코드가 존재한다는 사실 자체를 잊어버린다.

중요한 건 이게 주말 프로젝트, 버려도 되는 코드 를 두고 한 말이었다는 거예요. 원문 맥락에도 “진짜 일에는 이렇게 안 한다” 는 취지가 들어 있어요. 그러니까 원뜻 그대로의 바이브 코딩은 프로덕션에 넣으면 안 되는 방식 입니다.

현업에서 쓰는 뜻 — “AI 를 주 도구로 쓰는 개발”

그런데 말이 퍼지면서 뜻이 넓어졌어요. 지금 이력서나 면접에서 “바이브 코딩 합니다” 라고 하면 대개 이런 뜻이에요.

코딩 에이전트(Claude Code, Cursor, Copilot 등)에게 작업을 지시하고, 결과를 검토·수정해서 합치는 방식으로 개발한다.

이건 프로덕션에서도 정상적인 방식이고, 요즘 잘하는 팀들이 실제로 이렇게 일해요. 원뜻과는 읽느냐 안 읽느냐 에서 갈립니다.

이 시리즈에서의 정의

혼동을 막기 위해 이렇게 두고 갈게요.

바이브 코딩 — 코드를 직접 타이핑하는 시간보다, AI 에게 지시하고 그 결과를 판정하는 시간이 더 많은 개발 방식.

이 정의의 핵심은 “판정” 이에요. 지시는 누구나 합니다. 판정을 하느냐 안 하느냐가 실력이고, 이 시리즈의 질문들은 전부 그 판정 능력을 겨냥해요.

⚠️ 면접 초반에 이걸 한 번 정리하고 가면 좋아요. “바이브 코딩이라고 하셨는데, 본인 기준으로 그게 뭘 뜻하나요?” 이 질문 하나로 벌써 갈립니다. “AI 가 짜주면 돌려보고 넘기는 거죠” 와 “지시하고 결과를 리뷰해서 합치는 거죠” 는 완전히 다른 사람이에요.

2. 왜 기존 면접 방식이 무너졌나

예전 면접은 산출물 = 실력 이라는 전제 위에 서 있었어요. 그 전제가 신호별로 어떻게 무너졌는지 정리하면 이렇습니다.

예전 신호	지금 왜 안 되나	대체 신호
코딩 테스트 (원격)	AI 가 대부분 풉니다. 변별력이 거의 0	코드를 준 뒤 설명·수정 시키기
포트폴리오 완성도	완성도는 이제 도구 성능의 함수	완성까지의 선택 이력
이력서 기술 스택	안 써봐도 이름은 다 압니다	“그중 직접 디버깅해본 건 뭔가요”
깔끔한 코드	기본값이 깔끔해요. 정렬·주석·타입 다 붙음	왜 이 구조인지 설명하는가
빠른 구현 속도	도구가 만든 속도인지 구분 불가	막혔을 때 멈추는 지점

한 줄로 줄이면 이래요. 만든 것으로는 못 가리고, 만들면서 내린 판단으로 가려야 합니다.

그리고 다행인 게 하나 있어요. 판단은 위조가 어렵습니다. 코드는 AI 가 대신 써주지만, “왜 이 방향으로 갔는지” 를 그 자리에서 앞뒤 맞게 설명하는 건 실제로 겪은 사람만 됩니다. 꼬리 질문 두세 번이면 거의 예외 없이 갈려요.

3. “AI 못 쓰게 하고 보면 되죠” 가 틀린 이유

가장 흔한 대응이고, 가장 손해 보는 대응이에요. 세 가지 이유가 있습니다.

① 측정하려는 것과 다른 걸 측정해요
입사하면 AI 를 쓸 거잖아요. 그러면 우리가 알고 싶은 건 “AI 를 쓰는 이 사람의 산출 품질” 이지 “AI 없는 이 사람의 산출 품질” 이 아니에요. 후자는 참고 자료는 될지언정 채용 기준은 못 됩니다.

② 좋은 후보자가 먼저 떠나요
AI 를 잘 쓰는 사람일수록 도구를 막는 조직을 경계합니다. “여기 들어가면 손발이 묶이겠구나” 라는 신호로 읽거든요. 면접은 양방향이에요. 특히 이 직군은 시장에서 후보자가 회사를 고르는 쪽에 가깝습니다.

③ 애초에 통제가 안 돼요
원격 과제라면 막을 방법이 사실상 없어요. 감시 도구를 붙이면 감시를 뚫는 데 시간을 쓰는 사람만 남습니다.

그럼 뭘 해야 하나 — “허용하되 관찰한다”

정답은 AI 를 쓰게 두고, 쓰는 과정을 보는 것 이에요. 실기를 낸다면 화면 공유를 켜고 함께 앉아서, 후보자가 어떤 순서로 시키고 / 어디서 멈춰서 읽고 / 뭘 버리는지 를 보면 됩니다. 5편에서 이 실기 설계를 통째로 다룰 거예요.

💡 딱 하나 예외는 있어요. AI 를 못 쓰는 상황이 실제 업무에 존재하는 경우 예요. 폐쇄망 안이거나, 장애 대응 중 판단이 급하거나, 규제 때문에 외부 모델에 코드를 못 올리는 조직이요. 그런 조직이라면 그건 별도 항목으로 봐야 합니다. 이 경우 온프렘 코딩 에이전트 같은 대안을 아는지도 같이 물어볼 만해요.

4. 후보자를 네 갈래로 먼저 가르기

“AI 로 개발 잘하는 사람” 이라는 말은 너무 뭉뚱그려져 있어요. 실제로 만나보면 확실히 네 부류로 갈립니다. 어느 갈래인지부터 정하고 나면 그다음 질문이 저절로 정해져요.

갈래	이런 사람	강점	위험
증폭형	원래 설계·디버깅이 되던 사람이 AI 로 빨라진 경우	판단이 살아 있고 속도까지 붙음	드묾. 몸값이 높음
확장형	경력은 짧은데 AI 덕에 다뤄본 범위가 넓은 경우	성장 여지가 큼. 겁이 없음	넓고 얕음. 깊이 있는 장애에 약할 수 있음
위임형	AI 산출물을 읽지 않고 그대로 넘기는 경우	겉보기 산출량 하나는 많음	가장 위험. 사고가 늦게, 크게 터짐
수집형	도구·모델 얘기는 술술 하는데 만든 건 얇은 경우	도구 도입 초기에 도움은 됨	유지보수 경험이 거의 없음

갈래별로 확인할 것

증폭형 — 진짜인지 확인하는 게 관건이에요. AI 를 빼고도 되던 사람인지 보려면 AI 이전 경력의 장애 이야기 를 물으면 됩니다. 2023년 이전에 겪은 문제 하나를 처음부터 끝까지 말하게 하면 금방 드러나요.

확장형 — 감점 대상이 아니에요. 오히려 요즘 가장 많이 뽑게 되는 유형입니다. 대신 깊이가 필요한 자리인지 를 먼저 정해야 해요. “넓게 여러 개 만들어야 하는 자리” 면 아주 좋고, “레거시 하나를 깊게 파야 하는 자리” 면 위험합니다.

위임형 — 이 갈래를 걸러내는 게 이 시리즈 전체의 목적이라고 해도 돼요. 무서운 건 산출물이 멀쩡해 보인다 는 거예요. 코드 리뷰를 대충 하는 조직에 들어가면 6개월쯤 뒤에 아무도 이해 못 하는 시스템이 남습니다. 판별법은 3편에서 자세히 다룰게요.

수집형 — 나쁜 사람은 아닙니다. 다만 “그 도구로 6개월 이상 유지보수한 게 뭐가 있나요?” 한 방이면 정리돼요. 데모는 많은데 운영 이력이 없으면 그 갈래예요.

5. 채점 3축 — 설명 · 검증 · 책임

기술 지식이 없어도 쓸 수 있는 세 축이에요. 이 시리즈의 모든 질문은 셋 중 하나를 겨냥합니다.

축 1. 설명 가능성

자기 저장소의 아무 줄이나 짚었을 때, 왜 그게 거기 있는지 말할 수 있는가.

이게 가장 기본이고 가장 강력해요. AI 가 짰든 본인이 짰든 상관없습니다. 중요한 건 지금 그 코드의 책임자가 본인인가 예요.

수준	이렇게 나옵니다
상	왜 이 방식인지, 다른 방식은 왜 안 했는지까지 말함
중	뭘 하는 코드인지는 정확히 말함. 대안은 못 댐
하	“AI 가 그렇게 짜줘서요” / 화면을 다시 읽기 시작함

축 2. 검증 습관

AI 가 준 것을 무엇을 근거로 믿는가.

“그냥 돌려봤어요” 도 검증이긴 해요. 다만 그게 유일한 방법이면 위험합니다. 잘하는 사람은 검증 수단을 여러 겹으로 갖고 있어요. 타입 검사, 린트, 테스트, 실제 실행, 리뷰, 스테이징 반영 같은 것들이요.

수준	이렇게 나옵니다
상	검증 단계가 자동화돼 있고, 그걸 만든 이유를 말함
중	직접 돌려보고 눈으로 확인. 테스트는 있을 때만
하	“돌아가면 됐죠” / 검증이라는 개념 자체가 없음

축 3. 사고 책임

AI 때문에 사고가 났을 때 어떻게 했는가.

이건 사람 됨됨이까지 같이 보는 축이에요. AI 를 오래 쓴 사람은 반드시 한 번은 당했습니다. 안 당했다고 하면 둘 중 하나예요. 안 써봤거나, 사고를 사고인 줄 몰랐거나.

수준	이렇게 나옵니다
상	사고를 구체적으로 말하고, 그 뒤에 뭘 바꿨는지 까지 말함
중	사고는 말하는데 재발 방지가 없음
하	“AI 가 잘못 짜서요” 로 끝. 주어가 계속 AI

💡 축 3 의 하 수준에서 나오는 말버릇이 하나 있어요. 주어가 계속 AI 인 것. “얘가 자꾸 이상하게 짜요”, “모델이 멍청해서” 같은 표현이 반복되면, 이 사람은 자기 코드의 주인이 아니라고 스스로 말하고 있는 거예요. 도구 탓은 누구나 할 수 있지만, 탓하고 끝나는지 고쳐놓는지 가 갈립니다.

6. GitHub · 포트폴리오 읽는 법

면접 전에 30분만 쓰면 질문의 절반이 나와요. 코드를 읽을 필요는 없고, 커밋 이력만 보세요.

커밋 크기 분포

가장 정보량이 많은 신호예요.

한 커밋에 1000줄 넘는 변경이 연달아 있으면 → AI 출력을 통째로 넣는 흐름일 확률이 높아요. 그 자체로 나쁜 건 아닌데, 그렇다면 리뷰를 어디서 했는지 를 물어야 합니다.
50~300줄짜리가 촘촘하면 → 작업을 쪼개서 굴리는 사람이에요. 좋은 신호입니다.
커밋이 거의 없고 초기 커밋 하나가 전부면 → 만들고 끝낸 프로젝트예요. 유지보수 신호가 없습니다.

커밋 메시지

메시지가 전부 같은 톤에 같은 이모지 형식이면 자동 생성이에요. 이건 감점 사유가 아닙니다 — 요즘 많이들 그렇게 씁니다. 볼 건 “왜” 가 적혀 있는가 예요. fix login bug 만 100개 있는 것과 fix: 세션 만료를 서버 시각 기준으로 변경 (클라이언트 시계 오차로 조기 로그아웃) 이 섞여 있는 건 다릅니다.

되돌린 흔적

revert, rollback, 리팩터링 커밋이 보이면 좋은 신호 예요. 자기가 넣은 걸 다시 판단해봤다는 뜻이거든요. 모든 커밋이 앞으로만 가는 저장소는 대개 아무도 안 쓰는 코드입니다.

의존성 목록

package.json, requirements.txt 를 열어서 안 쓰는 패키지가 잔뜩 있는지 보세요. AI 가 중간에 넣었다가 방향을 바꿨는데 정리를 안 한 흔적입니다. 여러 개 보이면 “여기 이 라이브러리는 어디에 쓰세요?” 라고 물어보면 돼요.

테스트 디렉터리

있는지 없는지보다 내용이 의미 있는지 가 중요해요. assert True 만 잔뜩이거나, 테스트가 구현을 그대로 베낀 형태(같은 계산식을 테스트에서 한 번 더 쓰는 것)면 통과를 위한 테스트예요. 3편에서 이 이야기를 자세히 할게요.

💡 면접 전 준비는 이거 하나면 됩니다. 후보자 저장소에서 파일 하나를 골라 “이 파일 왜 이렇게 됐어요?” 를 던질 준비. 3분이면 끝나는 준비인데, 축 1(설명 가능성)을 정면으로 잽니다.

7. 공통 오프닝 질문 6개

어느 포지션이든 통하는 질문이에요. 면접 앞 20분에 쓰세요. 각 질문마다 왜 묻는지 와 채점 포인트 를 같이 적었습니다.

Q1. 지금 쓰시는 도구 구성 전체를 알려주세요

에디터, CLI, 모델, 규칙 파일, 확장까지 다요.

왜 묻나 — 갈래를 가르는 첫 질문이에요. 그리고 이후 모든 질문의 기준선이 됩니다. 그리고 여기서 손에 익었는지 가 티가 나요. 실제로 매일 쓰는 사람은 자기 구성을 이유와 함께 말합니다.
👍 좋은 답 — 구성이 구체적이고, 각 도구를 왜 그 자리에 뒀는지 말해요. “설계 잡을 땐 IDE 에서 보면서 하고, 반복 작업은 CLI 로 돌립니다” 처럼요. 도구를 바꿔본 이력 이 있으면 더 좋습니다.
⚠️ 걸리는 답 — 도구 이름만 나열하고 끝나거나, 반대로 30분간 도구 자랑만 합니다. 후자는 수집형 신호예요.

📎 도구 지형이 낯설면 AI 코딩 CLI 3종 비교와 AI IDE · Claude Code 하이브리드 셋업 편을 훑어두면 후보자 말이 훨씬 잘 들려요.

Q2. 최근 한 달 동안 AI 로 만든 것 중 가장 규모가 컸던 걸 숫자로 설명해 주세요

파일 수, 줄 수, 사용자 수, 걸린 기간 아무거나요.

왜 묻나 — 규모를 재는 질문이에요. 그리고 이 답이 이후 질문의 난이도를 정합니다. 혼자 쓰는 스크립트만 만들어본 사람에게 팀 협업 질문을 하는 건 의미가 없어요.
👍 좋은 답 — 숫자가 나오고, 그 숫자들이 서로 앞뒤가 맞아요. 다른 사람이 그걸 쓰고 있다 는 말이 나오면 아주 좋습니다.
⚠️ 걸리는 답 — “많이 만들었어요” 로 끝납니다. 또는 규모는 큰데 사용자가 본인뿐이에요.

Q3. 그중에 본인이 직접 손으로 쓴 부분은 어디였나요

왜 묻나 — 이게 가장 가성비 좋은 질문 이에요. 잘하는 사람은 이 경계를 정확히 압니다. AI 에게 맡기는 부분과 직접 잡는 부분이 나뉘어 있거든요. 경계를 못 그리는 사람은 전체를 던져놓고 받아쓴 사람이에요.
👍 좋은 답 — 경계가 뚜렷하고 이유가 붙어요. “데이터 모델하고 권한 로직은 직접 잡았고, 화면이랑 테스트는 거의 맡겼습니다.” 여기서 직접 잡은 게 시스템의 급소 라면 판단이 좋은 사람입니다.
⚠️ 걸리는 답 — “다 같이 했죠” / “구분이 안 되는데요”. 또는 직접 한 게 변수명 바꾸기 수준이에요.

Q4. AI 가 만든 코드를 그대로 넣었다가 문제가 생긴 적 있나요

왜 묻나 — 축 3(사고 책임)을 정면으로 겨냥합니다. 그리고 이 질문은 솔직함 도 같이 봐요.
👍 좋은 답 — 구체적인 사고가 나오고, 그 뒤에 뭘 바꿨는지 까지 말합니다. “그 뒤로 마이그레이션은 무조건 제가 직접 읽어요” 같은 식으로 습관이 바뀐 흔적이 있으면 최고예요.
⚠️ 걸리는 답 — “없습니다.” 이건 안 써봤거나, 사고를 사고로 인식 못 한 거예요. 한 번 더 편하게 물어보세요. “작은 것도 좋아요, 시간 날린 것도요.”

Q5. AI 가 끝까지 못 고친 문제가 있었나요. 그때 어떻게 하셨어요

왜 묻나 — 여기가 진짜 실력이 드러나는 지점 이에요. AI 는 대부분을 해결하고, 못 하는 나머지가 남습니다. 그 나머지를 처리하는 능력이 이 사람의 바닥 실력이에요.
👍 좋은 답 — 문제를 좁혀 들어간 과정이 나와요. 로그를 봤다, 최소 재현을 만들었다, 라이브러리 소스를 열었다, 이분 탐색으로 커밋을 좁혔다 같은. AI 를 끄고 직접 본 순간 이 나오면 아주 좋습니다.
⚠️ 걸리는 답 — “다른 모델로 바꿔봤어요” 만 반복하거나, “결국 그 기능을 뺐습니다” 로 끝나요. 후자도 때로는 맞는 판단이지만, 그 판단의 근거를 못 대면 그냥 포기한 거예요.

Q6. AI 에게 아예 안 시키는 일이 있나요

왜 묻나 — 경계 감각을 봅니다. 도구를 오래 쓴 사람은 안 맡기는 영역 이 반드시 생겨요. 그게 없다는 건 아직 크게 데어본 적이 없다는 뜻입니다.
👍 좋은 답 — 영역이 구체적이고 이유가 있어요. “권한 체크 로직”, “돈 계산”, “DB 마이그레이션”, “운영 환경에 직접 나가는 명령” 같은. 이유가 사고 경험에서 나왔으면 더 좋습니다.
⚠️ 걸리는 답 — “없어요, 다 시킵니다” 또는 반대로 “중요한 건 다 제가 해요” (그러면 도구를 안 쓰는 거예요).

8. 면접관이 하면 안 되는 것

이 주제에서 특히 빠지기 쉬운 함정들이에요.

① “AI 쓰셨죠?” 를 추궁조로 묻기
가장 흔한 실수예요. 이렇게 물으면 후보자가 방어 태세로 들어가고, 그때부터 정보가 안 나옵니다. AI 를 쓴 건 잘못이 아니에요. 물어야 할 건 “어디를 맡기고 어디를 직접 보셨어요?” 입니다. 같은 걸 묻는데 답의 질이 완전히 달라져요.

② 화이트보드 암기 테스트 부활
“AI 없이 보려면 종이에 시키자” 는 유혹이 강한데, 이건 2015년으로 돌아가는 거예요. 검색하면 나오는 걸 못 외웠다고 감점하면, 실제 업무 능력과 상관없는 걸 재는 데다 좋은 후보자가 회사를 낮게 평가합니다.

③ 도구 이름으로 채점하기
“우리는 Cursor 쓰는데 이 사람은 다른 걸 쓰네” 같은 판단이요. 도구는 한 달이면 갈아탑니다. 봐야 할 건 도구 이름이 아니라 그 도구로 뭘 어떻게 굴렸는지 예요.

④ 완성도로 채점하기
과제를 냈을 때 “완성했으니 합격” 은 이제 의미가 거의 없어요. 완성은 기본값입니다. 채점은 완성된 것을 설명하는 자리 에서 해야 해요.

⑤ 면접관이 AI 를 한 번도 안 굴려보고 들어가기
이게 사실 제일 큽니다. 코딩 에이전트를 한 번이라도 직접 써보면, 후보자가 하는 말이 진짜인지 아닌지가 감으로 잡혀요. 반나절이면 충분합니다. 자주 쓰는 명령어 모음 정도만 보고 작은 프로젝트 하나 굴려보고 들어가세요.

⑥ 못 알아들었는데 고개만 끄덕이기
모르는 답이 나왔을 때 쓸 수 있는 만능 되묻기 세 개예요. 어떤 기술 답변 뒤에도 붙일 수 있고, AI 지식이 없어도 답의 질을 판단할 수 있게 해줍니다.

“그걸 AI 한테 안 맡기고 직접 하셨다면 뭐가 달라졌을까요?” — 도구의 기여를 스스로 분리하게 만듭니다.

“그게 잘못됐다는 건 어떻게 아셨어요?” — 축 2(검증)를 정확히 겨냥해요.

“지금 다시 한다면 똑같이 하실 건가요?” — 판단을 되돌아본 적 있는지 드러납니다.

진짜 해본 사람은 셋 다 구체적으로 답하고, 받아쓰기만 한 사람은 두 번째에서 반드시 막혀요.

9. 다음 편부터의 로드맵

여기까지가 공통 도구예요. 이제 영역별로 들어갑니다. 각 편은 똑같이 배경 설명 → 질문 → 채점 포인트 순서라서, 면접 직전에 해당 편 하나만 읽고 들어가도 돼요.

편	다루는 것	이럴 때 읽으세요
2편	컨텍스트 · 규칙 파일 · 계획 · MCP · 병렬 작업	팀에 AI 개발 방식을 정착시켜야 할 때
3편	테스트 · 코드 리뷰 · 디버깅 · 읽지 않은 코드	코드 품질에 책임질 사람을 뽑을 때
4편	시크릿 · 프롬프트 인젝션 · 토큰 비용 · 사내 규정	규제 산업이거나 보안 리뷰가 있을 때
5편	실기 과제 3종 + 60분 시나리오 + 채점표	당장 다음 주에 면접이 잡혔을 때

시간이 없으면 1편(지금 글)과 5편 만 봐도 면접은 굴러갑니다. 5편에 채점표와 레드 플래그 정리를 붙여뒀어요.

📎 비슷한 포맷으로 AWS 전문가 면접 가이드 5부작도 써뒀어요. 클라우드 쪽 면접관이 되어야 한다면 같이 보시면 됩니다.

일단 오늘은 여기까지…..
다음 글에서는 도구 운용을 파볼게요. 컨텍스트가 뭔지부터 시작해서, 규칙 파일과 계획 습관, 그리고 “프롬프트 잘 쓰는 법” 만 말하는 후보자를 어떻게 걸러내는지까지 면접관 눈높이로 정리해 보겠습니다.

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

X Facebook LinkedIn Bluesky