이런 방식으로 당신을 시험합니다

실전 · Demo에서 제품까지 · 7가지 핵심 질문

3장 학습을 마쳤으니 Demo와 제품 사이에 무엇이 있는지 알게 되었습니다. 이 7가지 질문은 세 가지 실제 시나리오에서 나왔습니다. 먼저 직접 소리 내어 답해본 뒤 프레임워크를 확인하세요.

이 페이지 활용법
각 질문에는 질문자가 표시되어 있습니다. 같은 지식을 묻지만 듣고 싶은 대답이 다릅니다.
🎙 면접관실제로 출시한 경험이 있는지, 아니면 Demo만 봤는지 확인하고 싶어합니다
👔 상사설명, 방안, 실행 가능한 약속을 원합니다
🛠 기술 동료얼마나 큰 그림을 그리는지, 비용을 얼마나 이해하는지 살펴봅니다
각 질문에는 세 가지 레이어가 있습니다: 무엇을 평가하는가 → 답변 프레임워크 → 보너스 포인트. 답하기 어려운 부분은 마지막에 있는 강좌 페이지를 클릭해 복습하세요.
Q1면접관
「팀이 하루 만에 이미지 생성 API를 연동했고 Demo도 잘 작동합니다. 실제 출시까지 얼마나 남았다고 생각하나요? 무엇이 부족한가요?」
🎯 무엇을 평가하는가
이것은 실제로 AI 기능을 출시한 경험이 있는지 판단하는 분수령 질문입니다. Demo만 해본 사람은 「조금만 다듬으면 출시할 수 있어요」라고 말하지만, 실제 출시 경험이 있는 사람은 API 연동은 10%에 불과하고 나머지 90%가 전부 제품화 작업이라는 것을 알고 하나하나 나열할 수 있습니다.
🧭 답변 프레임워크
  1. 먼저 결론부터: API 연동은 10%에 불과합니다. 실제 사례에서 연동부터 출시까지 3개월이 걸렸으며, 부족한 부분은 네 가지 차원으로 정리할 수 있습니다.
  2. 경험 레이어: 생성 진행 피드백, 실패 시 원클릭 재시도, 다중 결과 선택, 히스토리 조회. Demo에서는 사용자가 30초를 기다려도 됩니다만, 제품에서는 안 됩니다.
  3. 품질 및 엔지니어링 레이어: 품질은 Prompt 최적화(LLM으로 사용자의 자연어를 이미지 생성 모델이 이해할 수 있는 설명으로 변환)와 캐릭터 일관성 앵커링에 의존합니다. 엔지니어링은 다중 모델 폴백 체인, 타임아웃 재시도, 비용 상한, 결과 영속화에 의존합니다. 모델은 반드시 장애가 발생하며, 장애 후의 경험이 곧 제품입니다.
  4. 안전 레이어: 입출력 이중 콘텐츠 심사, 저작권 위험, 사용자 참조 이미지 개인정보 정책. Demo는 무방비 상태로 운영할 수 있지만, 제품이 그러면 사고가 납니다.
⭐ 보너스 포인트 이 체크리스트의 범용성을 한마디로 언급하세요: 어떤 AI 기능이든 Demo에서 Production으로 가는 길은 경험, 품질, 엔지니어링, 안전의 네 가지 차원입니다. 방법론이 있다는 것을 들은 면접관은 목록을 암기한 것을 들은 것보다 훨씬 깊은 인상을 받습니다.
이 강좌 페이지로 답변을 구성하세요 → 이미지 생성 제품화 체크리스트 AI로 AI에게 Prompt 작성하기 모델 장애 발생 시, 그 다음은?
Q2상사
「사용자가 Agent가 30분이나 돌아가도 멈추지 않았고 결국 아무것도 돌아오지 않았다고 합니다. 무슨 일이었나요? 앞으로 이런 일이 다시 발생하지 않도록 어떻게 할 계획인가요?」
🎯 무엇을 평가하는가
상사는 근본 원인 설명과 예방 약속, 두 가지를 모두 원합니다. 「모델이 이상해졌어요」라고만 하면 들통납니다. 루프 패턴을 설명할 수도 없고, 스스로 멈추게 하는 메커니즘도 없다는 의미니까요. 「기술팀에 타임아웃 추가하라고 하겠습니다」는 절반 점수밖에 안 됩니다 - 그건 가장 거친 레이어일 뿐입니다.
🧭 답변 프레임워크
  1. 먼저 근본 원인 설명: 프로덕션 환경에서 Agent 루프에는 네 가지 전형적인 패턴이 있습니다: 동일 파라미터 무한 루프(같은 파라미터로 같은 도구를 반복 호출), 수익 감소(50라운드를 돌아도 모두 주변 행동), 텍스트 반복(컨텍스트가 너무 길어지면 같은 말을 반복), 도구 연속 실패 연쇄(하나의 도구 장애가 전체 체인을 끌어내림). 이번 케이스가 어떤 패턴인지 먼저 파악하세요.
  2. 예방 방안 제시: 실수 방지는 세 겹의 그물입니다. 하드 제한 안전망: 반복 상한, 총 타임아웃, 도구당 최대 호출 횟수 - 무조건적 브레이크. 탐지 및 경고: 동일 파라미터 탐지, 동일 도구명 탐지, 수익 감소 탐지 - 이상 패턴 발견 시 보고.
  3. 점진적 강등: 이상 감지 시 먼저 부드럽게 수정: 「이미 3번 반복했습니다, 다른 방법을 시도해주세요」라는 메시지 주입, 장애 도구 임시 비활성화, 현재 진행 상황을 강제 요약하고 반제품을 가지고 반환합니다. 사용자 입장에서 반제품이라도 가져오는 것이 빈손으로 돌아오는 것보다 훨씬 낫습니다.
  4. 경험 레이어 약속 추가: Agent가 긴 작업을 실행 중이라도 사용자는 진행 상황을 볼 수 있어야 하고, 현재 무엇을 하고 있는지 보여주며, 언제든지 수동으로 중지할 수 있어야 합니다. 사용자가 화내는 진짜 이유는 「30분을 기다렸는데 뭘 하고 있는지도 몰랐어요」입니다.
⭐ 보너스 포인트 한 마디 추가: 「사용자는 Agent가 루프에 빠졌다고 보고하지 않습니다. 그냥 이 AI 왜 이렇게 느리고 멍청하냐고만 하죠」. 기술적 장애를 사용자 관점으로 해석할 수 있다면 상사는 당신이 이 일을 책임질 수 있는 사람이라고 느낍니다.
이 강좌 페이지로 답변을 구성하세요 → Agent가 루프에 빠지는 이유 실수 방지 설계: 루프를 스스로 멈추게 하는 방법 스트리밍 UX: 사용자를 기다리게 하지 마세요
Q3면접관
「AI 어시스턴트의 대화가 길어질수록 비용도 늘고 성능도 떨어집니다. 컨텍스트 압축을 어떻게 설계하겠습니까? 삭제할 수 있는 것과 절대 건드릴 수 없는 것은 무엇인가요?」
🎯 무엇을 평가하는가
압축 결정 프레임워크가 있는지, 그리고 레드라인을 알고 있는지 테스트합니다. 「모델로 요약하면 되죠」라고 답하는 사람은 들통납니다: 요약 자체의 비용도 계산해보지 않았고, 잘못 삭제했을 때 사용자가 「분명히 말했는데 왜 잊어버렸어요?」라고 당장 알아채는 결과도 인식하지 못한 것입니다.
🧭 답변 프레임워크
  1. 왜 압축이 필요한지부터 설명: 매 대화 턴마다 전체 기록을 모델에 다시 전송합니다. 대화가 길수록 비용은 높아지고, 집중도는 분산되며, 컨텍스트 창 한계에 가까워집니다 - 세 가지 문제가 컨텍스트 관리를 강제합니다.
  2. 계층적 프레임워크 제시: 삭제 가능: 오래된 도구 호출 결과, 이미 처리된 중간 단계. 압축 가능: AI의 긴 답변, 검색 결과 - 한 문장 요약으로 압축. 절대 손대지 말 것: 사용자의 원본 메시지, System Prompt, 핵심 설정.
  3. 레드라인 명시: 사용자의 말은 신성불가침입니다. AI가 한 말 1000자를 삭제하더라도 사용자가 한 말 10자는 건드리지 마세요. 압축 우선순위 높음에서 낮음: 도구 출력, AI 답변 - 사용자 메시지는 절대 건드리지 않습니다.
  4. 각 방법의 비용 명확히 설명: 로컬 압축(자르기, 규칙 기반 교체)은 비용 없이 처리하지만 거칩니다. LLM 요약은 정확하지만 토큰 비용이 발생합니다. 올바른 순서는 무료 먼저 유료 나중: 로컬 방법으로 명백한 군더더기를 먼저 제거하고, 나머지에 LLM 요약을 고려합니다.
⭐ 보너스 포인트 사용자 경험 측면을 먼저 제시: 압축이 잘 되면 사용자는 전혀 인식하지 못합니다. 잘못되면 AI가 「기억상실」이라고 느낍니다. 압축을 단순한 비용 절감이 아닌 UX 지표로 측정하는 것 - 이 관점을 제시하는 사람은 거의 없습니다.
이 강좌 페이지로 답변을 구성하세요 → 대화가 길수록 비용도 높아지고 더 멍청해집니다 압축은 트레이드오프의 예술입니다 사용자의 말을 삭제할 수 있을까요? 로컬 압축 vs LLM 압축
Q4면접관
「제품에 「AI가 사용자를 기억하게」하는 기능이 필요합니다. 이 기억 시스템을 어떻게 설계하겠습니까? 모든 대화를 저장하나요? 사용자가 마음을 바꾸면 어떻게 합니까?」
🎯 무엇을 평가하는가
연속 세 질문이 기억 시스템에 대한 완전한 설계 능력을 테스트합니다: 무엇을 저장하는지, 어떻게 업데이트하는지, 어떻게 사용하는지. 「기억」과 「컨텍스트」를 혼동하는 사람은 첫 마디에 들통납니다. 「전부 저장하고 나중에 조회」라는 사람은 비용과 노이즈 관문을 통과하지 못합니다.
🧭 답변 프레임워크
  1. 먼저 두 시스템을 구분: 컨텍스트 창은 화이트보드 - 가득 차면 지우고, 대화가 끝나면 초기화됩니다. 장기 기억은 노트북 - 기록한 내용은 다음에 열어도 남아 있습니다. 기억 기능을 구축하는 전제는 화이트보드가 신뢰할 수 없다는 것을 인정하는 것입니다.
  2. 게이트키퍼 설계: 사용자는 매일 수십에서 수백 개의 메시지를 보내는데 「응」「알겠어」「하하」가 대부분을 차지하며, 기억할 가치 있는 선호와 사실은 몇 개뿐입니다. 기록 전에 이 정보가 장기적 가치가 있는지 판단하는 필터링 레이어가 필요합니다.
  3. 기억 충돌 처리: 사용자가 지난달에는 커피를 좋아한다고 했고 이번 달에는 차로 바꿨다고 합니다. 시나리오에 따른 네 가지 전략: 명확한 교체 → 덮어쓰기 업데이트. 보완적 정보 → 병합 확장. 어느 것이 맞는지 알 수 없음 → 충돌로 표시해 확인 대기. 임시 상태(최근 너무 피곤해서 늦게 일어남) → 건너뛰고 저장하지 않음.
  4. 주입 비용 계산: 1000개를 저장했을 때, 매번 System Prompt에 전부 넣는 것은 간단하지만 비싸고 노이즈가 많습니다. 필요 시 검색은 비용을 절약하지만 누락될 수 있습니다. 기억 규모와 시나리오에 따라 주입 전략을 선택해야 하며, 이는 비용 결정입니다.
⭐ 보너스 포인트 「기억 시스템의 핵심 능력은 업데이트입니다. 추가만 할 줄 아는 기억 시스템은 두 달이면 소문 창고가 됩니다」라고 지적하세요. 대부분의 사람들은 쓰기만 설계하고 만료와 오류 수정은 설계하지 않습니다.
이 강좌 페이지로 답변을 구성하세요 → 컨텍스트 ≠ 기억 기억할 가치 있는 것과 없는 것 기억 충돌: 사용자가 마음을 바꾸면 기억 주입의 비용 문제
Q5기술 동료
「PRD에 다중 Agent 협업이 필요하다고 쓰고 멋진 아키텍처 다이어그램도 그렸는데요. 정말 그렇게 많은 Agent가 필요한가요? 하나로는 안 되나요?」
🎯 무엇을 평가하는가
기술 동료는 당신이 진짜 생각해봤는지 아니면 트렌드만 쫓는지 탐색하고 있습니다. 다중 Agent는 더 많은 조율 비용과 더 많은 오류 가능성을 의미하며, 그들이 이 복잡성의 비용을 지불해야 합니다. 「왜 하나의 Agent로는 안 되는가」를 답하지 못하면 이 요구사항은 반려될 가능성이 높습니다.
🧭 답변 프레임워크
  1. 기본 입장 인정: 기본 입장은 하나의 Agent로 충분합니다. 다중 Agent가 필요하다고 하는 많은 시나리오는 실제로는 Prompt가 잘 작성되지 않은 것입니다. 두 번째 Agent를 추가하기 전에 세 가지 질문을 거쳐야 합니다: 하나로는 정말 안 되는가? 복잡성이 가치 있는가? 더 간단한 방법은 없는가(예: 도구 병렬 호출)?
  2. 정말 필요한 세 가지 시나리오: 병렬 가속 - 5개 소스를 동시에 검색하면 직렬보다 5배 빠릅니다. 역할 분리 - Writer가 쓰고 Reviewer가 검토하는 역할 격리로 검토가 진정으로 효과적이 됩니다. 위험 격리 - 서브 Agent가 PDF 파싱에 실패해도 「이 파일에 문제가 있습니다」만 보고하고 주 태스크는 영향받지 않습니다.
  3. 시나리오 대입: PRD의 구체적인 시나리오로 돌아가 어떤 케이스에 해당하는지 설명하세요. 해당하면 유지하고, 해당하지 않으면 그 자리에서 삭제하세요 - 아키텍처 다이어그램을 고집하며 강변하는 것보다 훨씬 보기 좋습니다.
  4. 동시성 상식 시연: 다중 Agent를 사용하더라도 「읽기」는 병렬 가능하고 「쓰기」는 직렬화해야 한다는 것을 알아야 합니다. 작업의 동시 실행 가능 여부를 판단하는 핵심은 한 가지: 읽기 전용인가요?
⭐ 보너스 포인트 먼저 말하세요: 「이 세 가지 시나리오 중 하나도 해당하지 않는다면 단일 Agent로 되돌리겠습니다」. 기술 동료가 가장 두려워하는 것은 슬라이드 아키텍처 비용을 지불해야 하는 PM입니다 - 먼저 퇴로를 말하면 신뢰가 즉시 형성됩니다.
이 강좌 페이지로 답변을 구성하세요 → 언제 여러 Agent가 필요한가 동시성의 비용: 누가 동시에 실행될 수 있는가 브레인스토밍: 여러 AI가 토론하게 하기
Q6면접관
「MCP가 요즘 매우 핫한데요. 일반 API 호출과 어떻게 다른지 말씀해주세요. 여러분 제품에는 어떤 의미가 있나요?」
🎯 무엇을 평가하는가
MCP에 대한 이해가 어느 레이어에서 멈추는지 테스트합니다. 「AI가 외부 도구를 호출하는 프로토콜」이라고만 답하는 사람은 입문 기사 한 편 읽은 사람과 다를 바 없습니다. 진정으로 이해한 사람은 양방향을 설명합니다: 제품이 남의 능력을 소비할 수도 있고, 자신을 남의 도구로 만들 수도 있다는 것을.
🧭 답변 프레임워크
  1. 첫 번째 레이어: Client로서 제품은 MCP를 통해 외부 기능을 소비합니다: 캘린더, 이메일, 데이터베이스, 브라우저 - 하나의 프로토콜에 연결하면 전체 생태계를 활용할 수 있어 API를 하나씩 연동하는 비용을 절약합니다.
  2. 핵심 두 번째 레이어: MCP는 양방향입니다. 제품이 Server로서 자신의 능력을 외부에 노출해 Cursor, Claude Desktop, 자동화 스크립트가 당신을 호출하게 할 수도 있습니다. 단방향 통합은 도구 호출일 뿐이지만, 양방향은 당신의 AI가 남의 도구가 될 수 있다는 것을 의미합니다.
  3. 제품적 의미 설명: 여러 Agent가 서로를 호출할 수 있을 때 생태계가 자연스럽게 형성됩니다. 이것은 도구에서 플랫폼으로의 핵심 도약이며, 제품 포지셔닝 결정으로서 PM이 내려야 합니다.
  4. 엔지니어링 상식 추가: 10개의 MCP 서비스에 연결할 때 시작 시 전부 연결하면? 3개가 다운되면 시작이 멈춥니다. 등록과 연결을 분리하고 필요할 때 연결하세요(지연 연결). 더 나아가 Agent가 실행 중에 도구가 없다는 것을 발견하면 스스로 새로운 MCP 연결을 발견하고 구성할 수 있습니다.
⭐ 보너스 포인트 한 마디로 마무리: 「MCP가 AI 제품에 가지는 의미는, 과거 오픈 플랫폼이 모바일 인터넷에 가졌던 의미와 유사합니다. 먼저 자신이 통합하는 쪽인지 통합되는 쪽인지 명확히 하세요.」 프로토콜 문제를 생태계 포지셔닝 문제로 격상시키면 면접관이 기억합니다.
이 강좌 페이지로 답변을 구성하세요 → MCP는 단순히 「도구 호출」이 아닙니다 지연 연결: 필요할 때만 연결 AI가 스스로 도구를 추가
Q7상사
「이번 달 API 청구서가 지난달보다 3배 늘었는데 사용자 수는 20%밖에 늘지 않았습니다. 돈이 다 어디로 갔나요? 다음 달에는 낮출 수 있을까요?」
🎯 무엇을 평가하는가
Agent 제품의 비용 구조를 이해하는지 테스트합니다. 비용이 메시지 수에 비례한다고 생각하는 사람은 청구서가 왜 사용자 수보다 빠르게 증가하는지 설명할 수 없습니다. 청구서를 턴과 컨텍스트 길이 레벨로 분해할 수 있는 사람만이 낮추는 방법을 이야기할 자격이 있습니다.
🧭 답변 프레임워크
  1. 먼저 측정 단위 수정: 사용자가 한 마디를 보내면 내부적으로는 10번 이상의 루프 반복과 수십 개의 API 메시지가 실행될 수 있으며, 매 반복마다 전체 기록을 다시 전송합니다. 비용은 태스크 복잡도와 연결되어 지수적으로 증가하므로 청구서가 사용자 수보다 빠르게 증가하는 것은 정상입니다 - 통제 불능이 문제입니다.
  2. 전형적인 비용 주범 찾기: 스케줄 태스크가 이전 세션을 재사용하면 컨텍스트가 계속 늘어나고, 이 하나의 선택이 월 청구서를 10배 차이 나게 할 수 있습니다. 루프에 갇힌 Agent가 공회전하며 돈을 낭비합니다. 긴 대화에 압축이 없으면 매 턴마다 오래된 기록 비용을 지불합니다.
  3. 비용 절감 조합 제시: 스케줄 태스크를 매번 새 세션 생성으로 변경. 루프 실수 방지를 배포해 공회전 차단. 컨텍스트 압축으로 재전송하지 않아야 할 토큰 제거. 사용자와 시간대별 비용 상한 설정, 이상 호출 모니터링.
  4. 약속 정량화 방법 제시: 태스크당 평균 비용 모니터링 대시보드를 구축하세요. 「다음 달에 낮출 수 있나요」를 「태스크당 비용 목표와 이상 호출 0건」으로 전환하고 주간 보고합니다.
⭐ 보너스 포인트 한 마디 추가: 「비용 증가의 다른 면은 너무 아끼면 더 멍청해지고, 압축이 지나치면 경험이 떨어집니다」. 비용과 경험의 트레이드오프를 먼저 테이블에 올려놓으면 제품 결정을 내리는 것이지 단순히 회계를 하는 것이 아님을 보여줍니다.
이 강좌 페이지로 답변을 구성하세요 → 메시지 하나 뒤에 숨겨진 실제 비용 스케줄 태스크의 비용 함정 대화가 길수록 비용도 높아지고 더 멍청해집니다
마지막 조언 하나
7가지 질문의 공통 밑바탕은 계산과 안전망입니다: 루프가 발생하면 어떻게 멈출지, 컨텍스트를 어떻게 압축할지, 청구서를 어떻게 통제할지. 이것들을 유창하게 설명할 수 있다면 Demo에서 제품까지의 길을 진정으로 걸어온 것입니다. 유창하게 설명하지 못하는 부분은 연결된 강좌 페이지를 클릭해 보완하세요.