AI 시대 PM 면접에서 가장 자주 나오는 5가지 질문, 어떻게 답할까

저는 지난 2년 동안 PM을 꽤 많이 면접했고, 저도 남에게 면접을 봤습니다. 지금도 또렷이 기억날 만큼 눈에 띄는 패턴이 하나 있어요: AI 관련 질문만 나오면, 열에 여덟은 곧바로 개념을 외우기 시작합니다——RAG가 뭔지, 파인튜닝과 프롬프트가 뭐가 다른지, Transformer의 어텐션 메커니즘은 어떻게 돌아가는지……. 술술 이어질수록 제 마음은 점점 식었고, 이 사람은 안 뽑겠다고 거의 확정했습니다.

틀리게 외워서가 아닙니다. 이 질문들이 재는 건 당신이 뭘 외웠느냐가 아니라, 당신이 생각할 줄 아느냐이기 때문입니다. 입을 열자마자 정의부터 나오면, 그건 면접관에게 이렇게 말하는 셈이에요: 저는 이걸 지식 포인트로 외웠지만, 이걸로 실제 결정을 내려본 적은 없습니다.

AI PM이라는 이 자리가 전통적인 PM과 가장 다른 지점이 바로 여기입니다. 전통 소프트웨어는 한번 설계가 정해지면 대체로 그대로지만, AI는 그렇지 않아요——한 모델이 테스트에서는 놀라운 성능을 보이다가 배포하면 무너질 수 있고, 90%의 사람에게는 잘 통하다가 나머지 10%에게는 헛소리를 하며, 왜 틀렸는지 설명하기도 어렵고 패치 하나로 고칠 수도 없는 경우가 많습니다. 그래서 면접관이 진짜로 알고 싶은 건 당신이 이 용어들을 아느냐가 아니라, “틀리기도 하고, 설명도 어렵고, 고치기도 어려운” 물건을 앞에 두고 어떻게 제품 결정을 내리느냐입니다.

아래 5가지 질문은 제가 지난 2년 동안 가장 많이 듣고, 또 가장 많이 물어본 것들입니다. 저는 정답을 드리지 않을 거예요——AI 쪽 문제는 대부분 정답이 없고, 면접관이 평가하는 건 당신의 추론 과정이지 결론이 아닙니다. 저는 각 질문이 당신의 어느 부분을 저울에 올리는지, 저라면 어떻게 답할지, 그리고 가장 쉽게 무너지는 답이 어떤 건지만 이야기하겠습니다.

1. “이 AI 기능이 가끔 틀립니다. 배포해도 되는지 어떻게 판단하나요?”

이건 AI PM 면접의 거의 첫 번째 질문이자, 갈림길입니다.

이 질문이 재는 건: “AI는 반드시 틀린다”는 전제를 받아들일 수 있는지, 그러고도 책임 있는 결정을 내릴 수 있는지입니다. 전통 소프트웨어의 사고방식은 “버그가 있으면 버그가 없을 때까지 고친다”지만, AI 기능은 영원히 오류를 0으로 만들 수 없어요. 당신의 답에서 “정확도를 100%까지 끌어올린 다음 배포하겠다”는 냄새가 나면 거의 탈락입니다——아직 AI의 세계에 들어오지 못했다는 뜻이니까요.

저라면 이렇게 답하겠습니다: 저는 틀리지 않기를 바라지 않습니다. 저는 “틀렸을 때 그 대가를 제가 감당할 수 있기”를 바랍니다. 먼저 한 마디 묻습니다——이 기능이 틀리면, 최악의 경우 어떻게 되나?

사용자의 이메일 초안을 도와주는 AI라면, 틀려봐야 사용자가 조금 고치면 그만이라 대가가 아주 낮습니다. 그럼 80%의 정확도라도 저는 배포합니다. 나머지 20%는 사용자가 스스로 감당할 수 있으니까요. 하지만 사용자에게 자동으로 돈을 청구하거나, 의사에게 진단 제안을 주는 AI라면 한 번의 오류가 곧 사고입니다. 그럼 99%라도 배포하지 못하고, 사람의 재검토, 안전장치, “확신이 안 서면 하지 않는다”는 퇴로를 더해야 합니다. 같은 정확도라도 배포 여부는 오류의 대가에 달려 있지, 그 숫자 자체에 달려 있지 않습니다.

가장 쉽게 무너지는 답: 정확도라는 숫자만 붙들고 이야기하며, 틀렸을 때 어떻게 되는지는 말하지 않는 것. “AI가 좋으냐 나쁘냐”를 점수 문제로 보고, “최악의 상황을 내가 감당할 수 있느냐”는 제품 문제로 보지 않는 것——이건 2023년의 사고방식이고, 2026년의 면접관은 한 마디만 들어도 당신이 AI 기능을 실제로 배포해본 적이 없다는 걸 압니다.

2. “이 요구사항, 프롬프트로 할래요, RAG로 할래요, 아니면 파인튜닝으로 할래요? 왜죠?”

이 질문이 나오는 빈도는 터무니없이 높습니다. 특히 대형 모델 관련 자리라면 프롬프트/RAG/파인튜닝 셋 중 하나를 고르라는 질문은 거의 필수입니다.

많은 사람이 이걸 기술 시험이라고 생각하지만, 사실 이건 당신이 트레이드오프를 할 줄 아는지를 재는 질문입니다. 면접관은 당신이 파인튜닝 코드를 손으로 짜기를 기대하지 않아요. 그가 보고 싶은 건: 요구사항 하나를 주면 비용, 효과가 나오는 속도, 통제 가능성을 기준으로 이 몇 가지 길에 순서를 매기고, 왜 이 길을 골랐고 저 길을 버리면 무엇을 감당해야 하는지 분명히 말할 수 있느냐입니다.

저라면 이렇게 답하겠습니다: 저는 반드시 가장 가벼운 방안부터 위로 올라갑니다. 프롬프트로 해결할 수 있으면 절대 파인튜닝까지 가지 않습니다. 프롬프트는 고치기가 가장 빠르고 비용이 가장 낮으며, 오늘 안 되면 내일 바로 조정할 수 있으니까요. RAG는 “답이 내 문서 뭉치에 기반해야 하고, 게다가 수시로 업데이트되어야 하는” 상황에 맞습니다. 파인튜닝은 가장 무겁습니다——학습에 돈이 들고 데이터가 필요하며, 한 번 바꾸는 주기가 길어요. 저는 “앞의 두 가지를 다 시도해봤는데도 효과가 부족하고, 게다가 이 능력이 그 비용을 쏟을 만한 가치가 있을” 때만 파인튜닝에 손을 댑니다.

핵심은 마지막 그 대목입니다——각 길이 무엇을 버렸는지를 말할 수 있어야 합니다. 프롬프트를 고르면 버리는 건 안정성입니다(같은 질문이라도 오늘은 맞고 내일은 틀리죠). 파인튜닝을 고르면 버리는 건 유연성입니다(행동 하나를 바꾸려면 다시 학습시켜야 하죠). “저는 A를 골랐고, 그 대가는 B를 잃는 것이지만, 이 요구사항에서는 그 대가가 값합니다”를 분명히 말할 수 있으면 이 질문은 만점입니다. 당신이 모델 코드를 단 한 줄도 못 짠다고 해도요.

가장 쉽게 무너지는 답: 대뜸 “그건 무조건 파인튜닝이죠, 효과가 제일 좋으니까”라고 하는 것. 입만 열면 가장 무거운 방안을 올리려는 사람을 보면, 면접관은 당신이 비용을 모르고 실제 프로젝트의 예산 때문에 고민해본 적이 없다고 단정합니다.

3. “AI를 ‘안 쓰기로’ 결정했던 경험을 하나 이야기해보세요.”

이 질문은 유난히 음흉하지만, 유난히 사람을 잘 걸러냅니다. 지난 2년 동안 온 세상이 AI를 외쳐대는데, PM이 단 한 번도 먼저 “여기엔 AI를 쓰면 안 된다”고 말해본 적이 없다면, 그 사람은 아마 유행을 좇는 것이지 제품을 만드는 게 아닙니다.

이 질문이 재는 건: 당신이 AI를 목적으로 보느냐, 도구로 보느냐입니다. 면접관은 확인하고 싶어 합니다. 당신이 “사장이 AI를 원해서” 혹은 “그래야 투자 유치 스토리가 좋아서” 같은 이유로, 애초에 필요 없는 곳에 AI 기능을 억지로 끼워 넣지는 않을 사람인지를요.

저라면 이렇게 답하겠습니다: 저는 구체적인 사례를 하나 이야기하겠습니다——예를 들어 어떤 기능에 다들 “스마트 추천”을 붙이고 싶어 했는데, 제가 막았던 일이요. 그 상황은 사용자에게 몇 개의 고정된 선택지밖에 없어서, 하드코딩한 규칙 하나면 빠르고 정확하고 틀리지도 않았거든요. 거기에 억지로 모델을 얹으면 느리고 비싸고 가끔 엉뚱하게 추천할 뿐, 순전히 AI를 위한 AI였습니다. 결국 우리는 가장 미련한 if-else로 해결했고, 저는 그게 그해 제가 내린 가장 옳은 결정 중 하나라고 생각합니다.

“내가 AI를 거절했다”는 구체적인 이야기 하나가, RAG를 아무리 화려하게 설명하는 것보다 값집니다. 그것은 면접관이 가장 원하면서도 가장 재기 어려운 것을 증명하니까요: 당신에게 판단력이 있고, AI가 당신을 부리는 게 아니라 당신이 AI를 쓴다는 것.

가장 쉽게 무너지는 답: “그런 경우가 잘 떠오르지 않네요, AI는 대체로 다 경험을 개선한다고 생각해서요”라고 답하는 것. 이 한 마디로 당신은 “AI 신도” 부류로 분류됩니다——그리고 성숙한 팀치고, 언제 AI를 쓰면 안 되는지 구분하지 못하는 PM을 원하는 곳은 없습니다.

4. “비용과 지연(latency), 어떻게 균형을 잡나요?”

몇 년 전만 해도 이건 엔지니어링 문제로 취급됐습니다——token을 얼마나 쓰는지, 응답이 느리지 않은지, 그건 백엔드가 신경 쓸 일이라고요. 하지만 2026년의 기준은 바뀌었습니다: 비용과 지연은 AI PM 본인의 대시보드에, 품질·경험과 나란히 올라와 있고, 로드맵을 짤 때 명시적으로 꺼내어 저울질해야 하는 항목입니다.

이 질문이 재는 건: AI 기능이 진짜 돈을 호출 횟수만큼 태운다는 것, 그리고 1초 느려지면 사용자 한 무리를 잃을 수도 있다는 것을 아느냐입니다. 전통 소프트웨어는 다 만들고 나면 사용자 한 명이 더 써도 추가 비용이 거의 안 들지만, AI는 그렇지 않아요. 호출 한 번마다 돈을 쓰고, 많이 쓸수록 많이 태웁니다. 이 계산서를 안 보는 PM은 경험은 훌륭하지만 회사가 감당 못 하는 기능을 만들어냅니다.

저라면 이렇게 답하겠습니다: 저는 이걸 명확한 삼자 트레이드오프로 봅니다——품질, 비용, 속도, 보통 셋을 다 만족시키는 건 불가능하죠. 저는 이 기능이 대체 무엇으로 이기는지를 묻습니다: “정확하게 답하는 것”으로 이긴다면, 좀 느리고 좀 비싸도 괜찮으니 더 강한 모델을 씁니다. “손 가는 대로 바로 쓸 수 있는 것”으로 이긴다면, 값싸고 빠른 작은 모델을 골라 품질을 조금 희생하고 응답 속도와 비용을 얻습니다. 핵심은 제가 무엇으로 무엇을 바꾸고 있는지를 아는 것이지, 늘 가장 강하고 가장 비싼 모델을 기본값으로 올리지 않는 것입니다.

가장 쉽게 무너지는 답: “그건 기술에 맡겨서 최적화하면 되죠.” 비용과 지연을 엔지니어링에 떠넘기는 것——이게 바로 면접관이 기다리고 있는 오답입니다. 이 말이 나오는 순간 “이 사람은 AI 제품의 계산서를 모른다”는 딱지가 붙습니다.

5. “왜 AI PM을 하고 싶은가요?”

의례적인 오프닝 질문처럼 보이지만, 사실은 정직성 테스트입니다.

이 질문이 재는 건: 당신이 정말 이 위에서 손을 놀려봤는지, 아니면 유행과 연봉에 끌려와 대사 한 세트를 외워 온 건지입니다. 이어지는 모든 기술 추궁이 이 “왜”가 진짜인지를 검증하기 때문이에요.

저라면 이렇게 답하겠습니다: 저는 “AI가 미래니까, 대세니까” 같은 옳은 헛소리는 하지 않겠습니다——이런 말은 면접관이 하루에 스무 번은 듣기에, 안 한 것과 같아요. 저는 구체적인 작은 일 하나를 이야기하겠습니다: 오래 마음에만 담아두고 코드를 짤 줄 몰라 못 만들던 걸, AI로 어느 오후에 진짜로 만들어내고 클릭까지 되던 그 순간, “말 한마디로 이걸 실현시킬 수 있구나” 하던 그 충격을요. 진짜이고, 구체적이고, 조금 서툴렀던 첫 경험은, 웅장하고 옳은 판단 한마디보다 언제나 더 설득력이 있습니다.

가장 쉽게 무너지는 답: 업계 트렌드를 외우고, 큰 단어를 외우는 것. 말을 크고 옳게 할수록 면접관은 당신이 실제로 해본 적이 없다고 확신합니다——진짜 해본 사람은 입을 열면 구체적인 일이지, 근사한 판단이 아니거든요.

잊지 마세요, 진짜 시험은 꼬리 질문에 있습니다

위의 모든 질문은 첫 라운드를 답했다고 끝난 게 아닙니다. AI PM 면접에서 진짜 실력이 드러나는 곳은, 면접관이 이어서 툭 던지는 그 가벼운 “그래서요?”입니다.

당신이 “이 기능은 정확도 80%면 저는 배포합니다”라고 하면, 그는 물을 겁니다: “그럼 그 20%는 구체적으로 어떻게 감당하죠?” “배포 후에 실제로는 70%밖에 안 나온다는 걸 알게 되면, 어떻게 할 건가요?” 당신이 “저는 파인튜닝 말고 프롬프트를 골랐습니다”라고 하면, 그는 물을 겁니다: “그럼 프롬프트를 아무리 조정해도 효과가 60%에서 막혀 있으면, 언제 마음을 바꿔 파인튜닝으로 갈 건가요? 그 선을 어디에 긋죠?”

그는 당신을 곤란하게 하려는 게 아니라, 확인하고 있는 겁니다: 당신의 그 근사한 결론이 대체 생각해낸 것인지, 외워 온 것인지. 외워 온 건 두 겹만 파고들어도 밑천이 드러납니다——외운 답에는 다음 층이 없어서, 덩그러니 결론 하나만 있고 “상황이 바뀌면 나는 어떻게 조정하겠다”를 못 내놓거든요. 생각해낸 건 아무리 파고들어도 이야기가 됩니다. 머릿속에서 이 길을 진짜로 끝까지 걸어봤으니까요.

그러니 준비할 때, 답만 준비하지 말고 자기 자신에게 “그래서?”를 한 번 더 물으세요: 이 결정이 틀리면 나는 어떻게 수습하나, 조건이 바뀌면 언제 마음을 바꾸나, 나는 무엇을 근거로 이 선을 긋나. 꼬리 질문을 스스로 먼저 한 바퀴 돌려보면, 정작 면접에서 그 “그래서요?”는 더 이상 걸림돌이 아니라, 당신이 진짜 실력을 보여줄 기회가 됩니다.

결국, 재는 건 같은 하나입니다

이 5가지 질문을 이어서 보면, 면접관이 반복해서 저울에 올리는 게 사실 같은 하나라는 걸 알게 됩니다: 당신 손에 구체적인 이야기가 있느냐——하나의 진짜 결정, 한 번의 진짜 트레이드오프, 이왕이면 숫자까지 딸린.

정확도가 얼마면 배포하겠는지, 왜 파인튜닝 말고 프롬프트를 골랐는지, 어느 때 AI 기능을 막았는지, 품질을 비용과 바꿨는지 비용을 속도와 바꿨는지, 처음 AI에 충격받은 게 무엇 때문이었는지——이 다섯 질문에서 잘 답하는 사람은 전부 자기가 진짜 해본 일을 이야기하고, 못 답하는 사람은 전부 정의와 트렌드를 외웁니다. 공허한 이야기는 오퍼를 잃고, 구체적인 이야기는 오퍼를 얻습니다. 이 말은 AI PM이라는 자리에서, 다른 어떤 자리보다도 독하게 적용됩니다.

그러니 이런 면접을 준비하고 있다면, 제 조언은 문제은행을 외우라는 게 아닙니다. 돌아가서 당신이 진짜 해본 AI 관련 일들을 하나하나 꺼내어, 각각을 분명히 정리하는 겁니다: 그때의 결정은 무엇이었고, 무엇을 버렸고, 결과는 어땠고, 숫자가 있었는지. 이런 이야기를 대여섯 개쯤 모아두면, 위의 질문들이 아무리 변형되어 나와도 당신에게는 들려줄 진짜가 있습니다.

저도 지금까지 계속 곱씹고 있는 게 하나 있어서, 겸사겸사 던져봅니다: AI가 “무언가를 만들어낸다”는 문턱을 이렇게까지 낮춰버리면, 면접에서 “당신은 무엇을 해봤나요”류의 질문은 점점 답하기 쉬워질 겁니다——누구나 뭔가를 만들어낼 수 있게 됐으니까요. 그럼 그때가 되면, 사람의 우열을 진짜로 갈라놓는 질문은 무엇으로 바뀔까요? 제 짐작으로는 “당신이 안 한 게 무엇이고, 왜 안 했는지” 쪽으로 갈 것 같습니다. 하지만 이건 어디까지나 제 짐작일 뿐, 저도 아직 답을 보지는 못했습니다.