이렇게 당신을 테스트합니다
LLM 기초 · 반드시 답해야 할 7가지 질문
1장을 다 배웠지만, 이해하는 것과 실전에서 말로 설명할 수 있는 것 사이에는 간격이 있습니다. 이 7가지 질문은 세 가지 실제 시나리오에서 나왔습니다 — 프레임워크를 보기 전에 먼저 소리 내어 답해보세요.
이 페이지 활용 방법
각 문제에 질문자가 표시되어 있습니다. 같은 지식을 테스트하지만, 각자가 듣고 싶은 것은 다릅니다.
🎙 면접관진짜 이해했는지, 아니면 용어만 외웠는지 확인하고 싶어합니다
👔 상사설명과 약속을 원합니다
🛠 기술 동료당신을 믿을 수 있는지 탐색하고 있습니다
각 문제에 세 가지 레이어가 있습니다: 상대가 테스트하는 것 → 답변 프레임워크 → 가산점. 답하지 못하는 부분은 하단의 관련 강의 페이지를 클릭해서 복습하세요.
Q1면접관
「당신 자신의 말로 설명해 주세요 — ChatGPT 같은 LLM은 어떻게 답변을 생성하나요? 실제로 생각하는 건가요?」
🎯 테스트하는 것
시작 질문 — 이후 모든 질문의 깊이를 결정합니다. 확률적 다음 Token 예측을 쉬운 말로 설명할 수 있는지 테스트합니다. 용어를 외운 사람은 "Transformer, 어텐션 메커니즘"을 쌓아 올리고, 진짜 이해한 사람은 예시를 통해 메커니즘을 명확히 설명합니다.
🧭 답변 프레임워크
- 본질부터: LLM은 초대형 확률 예측 기계입니다. 한 번에 한 가지만 합니다: 기존 모든 Token을 바탕으로 다음 Token의 확률 분포를 예측하고 하나씩 생성합니다.
- 훈련과 추론 구분: 훈련은 방대한 텍스트에서 통계적 패턴을 학습합니다. 대화할 때는 파라미터가 이미 고정되어 있어 — 학습하는 것이 아니라 계산하는 것입니다.
- 생각하는 문제에 직접 답변: 인간적 의미의 생각은 없지만, 충분한 규모에서는 실제로 추론과 유사한 능력을 보입니다. 따라서 신격화도, 단순 자동완성으로 격하도 하지 마세요.
- 예시로 마무리: 「오늘 날씨가 정말」을 입력하면 모델은 좋다 62% / 나쁘다 18% / 춥다 9% 같은 분포를 출력하고 확률에 따라 샘플링합니다. 전체 답변은 이 동작을 수백 번 반복한 것입니다.
⭐ 가산점 대화 ≠ 학습, 파라미터가 고정되어 있다는 것을 자발적으로 언급하세요. 많은 PM이 모델이 사용자 대화에서 지속적으로 학습한다고 생각하는데, 이 오해를 바로잡으면 제대로 이해했다는 것을 보여줍니다.
Q2면접관
「분명히 채팅 제품인데 왜 OpenAI API는 chat/completions(완성)라고 부르나요? 멀티턴 대화는 어떻게 구현되나요?」
🎯 테스트하는 것
실제로 API를 다뤄봤는지 판단하는 분기점 문제입니다. ChatGPT 웹 버전만 사용한 사람은 답할 수 없습니다. message list 메커니즘을 이해하는 사람은 이후 컨텍스트, 비용, Agent 관련 질문도 잘 처리할 수 있습니다.
🧭 답변 프레임워크
- 핵심 밝히기: 모델은 기본적으로 텍스트 완성 기계입니다. 「대화」란 대화 기록 형식으로 히스토리를 패키징하고 모델이 어시스턴트의 다음 턴을 완성하게 하는 것입니다.
- 멀티턴의 실체: 모델에는 메모리가 없습니다. 매 턴마다 전체 message list(system + 이전 모든 user/assistant 턴 + 현재 질문)를 처음부터 다시 보냅니다.
- 엔지니어링 레이어 추가: 모델이 대화 형식을 이해하는 것은 Chat Template + SFT 지시 파인튜닝 덕분입니다 — Base 모델이 「말하는 법」을 배우는 핵심 단계입니다.
- 한 레벨 높이기: 모든 AI Harness 작업(RAG, 메모리, Agent)은 근본적으로 이 message list를 조작하는 것입니다. 이를 이해하면 모든 솔루션의 입구를 찾은 것입니다.
⭐ 가산점 자연스럽게 비용 의미로 전환하세요: 매 턴마다 전체 히스토리를 다시 보내기 때문에 멀티턴 대화는 할수록 비용이 증가합니다. 모든 후속 비용 최적화 솔루션이 이 문제를 해결하기 위한 것입니다.
Q3상사
「우리 AI 고객 서비스가 어제 또 존재하지 않는 환불 정책을 만들어냈어요. 왜 그런지 설명해 주고, 언제 완전히 고칠 수 있나요?」
🎯 테스트하는 것
이 문제는 지식이 아니라 기대치 관리를 테스트합니다. 「완전히 고칠 수 없습니다」라고 말할 용기가 있나요? 그 후에 상사를 안심시킬 수 있는 계획과 정량적 약속을 즉시 제시할 수 있나요? 「기술팀에 물어보겠습니다」는 최악의 답변입니다.
🧭 답변 프레임워크
- 결론부터, 회피 없이: 환각은 확률적 예측 메커니즘의 불가피한 부산물입니다. 완전히 제거할 수 없지만, 엔지니어링으로 비즈니스에서 허용 가능한 수준으로 줄일 수 있습니다.
- 근본 원인 설명: 두 가지 원인: 파라미터 지식 오류(훈련 데이터가 잘못되었거나 오래됨), 그리고 컨텍스트 오해(모델은 항상 가장 가능한 연속을 선택하는데, 「가장 가능」 ≠ 「가장 정확」).
- 복합 솔루션 제시: 실제 환불 정책 문서를 RAG로 주입 + Prompt 제약 「문서에만 근거해 답변」 + Temperature 낮추기 + 평가 Harness 및 인간 검토를 안전망으로.
- 정량적 약속 방법 제시: 환각율 지표 정의(샘플 검토), 주별 수렴 상황 보고, 「언제 고쳐지나」를 「지표가 얼마나 되면 되나」로 전환.
⭐ 가산점 「환각을 완전히 제거할 수 있다고 약속하는 공급업체는 과장하는 겁니다」를 추가하세요. 상사가 전체 업계에 대한 올바른 기대를 갖도록 돕는 것은 AI PM의 핵심 가치 중 하나입니다.
Q4면접관
「환각을 완화하는 방법을 어떤 것을 알고 있나요? 리소스가 제한적이라 하나만 먼저 배포할 수 있다면 어떤 것을 선택하고 왜 그런가요?」
🎯 테스트하는 것
앞 문장은 지식의 폭을 테스트하고, 뒷 문장이 핵심: 의사결정 능력과 비용 인식. 표준 답안이 없습니다. 바로 답변하는 사람은 불합격, 먼저 「어떤 시나리오인가요?」라고 반문하는 사람이 합격합니다.
🧭 답변 프레임워크
- 네 가지 방법 모두 나열: Prompt 제약(가장 저렴), RAG(지식 환각에 가장 효과적이나 비용 있음), Temperature 낮추기(무작위성만 줄임, 지식 공백은 채우지 못함), 평가 + 인간 검토(외부 안전망).
- 먼저 시나리오 질문: 환각이 주로 사실 날조인가, 표현이 불안정한가? 지식 베이스가 변하는가? 예산은?
- 조건부 답변 제시: 지식 환각(정책 날조, 데이터 날조) → RAG; 표현 불안정 → Prompt 제약 + 낮은 Temperature, 거의 비용 없이 먼저 배포.
- 원칙 추가: 어떤 것을 선택하든, 평가 먼저. 평가 없이는 효과를 측정할 수 없어 — 헛된 노력입니다.
⭐ 가산점 실제 프로젝트에서는 네 가지 모두 조합하고 단계적으로 배포해야 한다고 언급하세요 — 단일 선택은 면접에서만 존재합니다. 「먼저 Prompt와 Temperature로 출혈을 막고, 그 다음 RAG로 근본 원인을 해결한다」는 템포를 말할 수 있는 사람은 드물고 인상적입니다.
Q5기술 동료
「제품에 우리 최신 내부 제품 매뉴얼을 연동해야 하는데, 설마 모델을 다시 훈련하려는 건 아니죠?」
🎯 테스트하는 것
기술 동료의 반쯤 농담인 도전 — 실제로는 당신이 훈련과 추론의 경계를 이해하는지 탐색하는 것입니다. 틀리게 답변하면(예: 「네, 훈련하면 안 되나요?」) 기술팀의 신뢰가 즉시 떨어집니다. 올바르게 답하면 이후 협업이 훨씬 원활해집니다.
🧭 답변 프레임워크
- 농담 받아치기: 재훈련 불필요합니다. 파라미터가 고정되어 있어도 지식을 넣을 수 없다는 뜻이 아닙니다 — 컨텍스트 윈도우가 지식의 입구입니다.
- 솔루션 제시: RAG 사용. 매뉴얼을 청크로 나누고 벡터 인덱스를 만들어, 사용자가 질문할 때 관련 단락을 검색해 컨텍스트에 주입합니다. 매뉴얼 업데이트는 인덱스 재구성만 필요 — 하루 안에 반영, 재훈련보다 수 배 저렴합니다.
- 파인튜닝의 올바른 용도 설명: 파인튜닝은 행동 스타일(어조, 형식, 도메인 어휘)을 변경합니다 — 시효성 있는 지식 주입에는 적합하지 않습니다. 지식이 가중치에 들어가면, 업데이트할 때마다 다시 훈련해야 합니다.
- 비용 인식 보여주기: RAG도 비용이 있습니다: 매 요청마다 더 많은 Token, 지연 시간 증가. 캐싱, 라우팅, 정밀한 청크 분할로 최적화가 필요합니다.
⭐ 가산점 RAG의 트레이드오프와 최적화 전략(의미론적 캐싱, 키워드 트리거, 모델 라우팅)을 말할 수 있으면 실제로 계산해봤다는 것을 보여줍니다. 「RAG 사용」은 누구나 외울 수 있습니다.
Q6면접관
「Temperature와 Top-P란 무엇인가요? 제품에서는 어떻게 설정하시겠어요?」
🎯 테스트하는 것
실제로 파라미터를 조정해봤는지 테스트합니다. 뒷 문장 「제품에서」는 시나리오별 답변을 기다리고 있습니다. 고정 값을 즉시 말하는 사람(「0.7로 설정하면 됩니다」)은 거의 확실히 실제로 튜닝해본 적이 없습니다.
🧭 답변 프레임워크
- 메커니즘 설명: Temperature는 확률 분포의 가파름을 제어합니다 — 낮을수록 더 결정적, 높을수록 더 분산. Top-P는 샘플링 후보 풀 크기를 제어합니다. 함께 출력 무작위성을 결정합니다.
- 시나리오별 설정 제시: 고객 서비스 / 사실 Q&A / 데이터 추출 → 낮게(0~0.3). 창의적 카피 / 브레인스토밍 → 높게(0.7 이상).
- 경계 명확히: 이것은 표현적 무작위성만 완화할 뿐 — 지식 공백은 해결하지 못합니다. 낮은 Temperature에서도 모델은 자신 있게 잘못된 정보를 말할 수 있습니다.
- 검증 방법 제시: 파라미터 값은 평가 세트로 A/B 테스트해서 검증해야 합니다. 직관으로 전체 제품에 하나의 값을 정하는 것은 나쁜 관행입니다.
⭐ 가산점 무작위성 환각과 지식 환각을 자발적으로 구분하세요: Temperature는 전자만 치료합니다. 많은 사람들이 이 경계를 명확히 설명하지 못합니다.
이 강의 페이지로 답변 구성 →
Temperature & Top-P 인터랙티브 데모
Q7면접관
「컨텍스트 윈도우가 무엇인가요? 이제 모델이 1M Token까지 되었는데 — 크면 클수록 좋은 건가요?」
🎯 테스트하는 것
앞 문장은 개념 문제이고, 뒷 문장이 함정입니다. 「당연히 클수록 좋죠」라고 동의하면 함정에 빠집니다. 비용 인식과 긴 컨텍스트의 실제 한계를 아는지 테스트합니다.
🧭 답변 프레임워크
- 개념 명확히: 윈도우 = 모델이 한 번에 볼 수 있는 총 Token 수(입력 + 출력). 이를 초과하는 것은 잘려 — 모델 입장에서는 존재하지 않는 것과 같습니다.
- 함정 밝히기: 더 큰 윈도우는 더 큰 청구서를 의미합니다. Token은 양으로 과금되어 모든 것을 넣으면 비용이 선형으로 증가합니다.
- 기술적 한계 추가: 긴 컨텍스트는 「lost in the middle」 문제가 있습니다: 정보가 많을수록 어텐션이 희석되어, 중간 부분의 콘텐츠 재현율이 현저히 낮아집니다.
- 올바른 방법 제시: 큰 윈도우는 능력의 상한선일 뿐입니다. 올바른 방법은 컨텍스트 엔지니어링: 검색, 압축, 필터링 — 윈도우에 들어가야 할 것만 넣습니다.
⭐ 가산점 주류 모델의 윈도우 규격을 인용하고(Qwen 1M / Claude 200K / GPT 128K) 윈도우 크기가 아키텍처 결정에 영향을 미친다고 언급하면 업계에 정통하다는 것을 보여줍니다.
마지막 조언
이 7가지 문제를 올바르게 활용하는 방법은 소리 내어 말하는 것입니다 — 동료, 친구, 또는 녹음을 향해. 그냥 읽는 것은 충분하지 않습니다. 막히는 곳이 바로 이해했다고 생각했지만 아직 이해하지 못한 곳입니다 — 관련 강의 페이지를 클릭해서 복습하세요.