이렇게 당신을 테스트합니다
실전 · Demo에서 제품까지 · 30가지 핵심 질문
3장 학습을 마쳤으니 Demo와 제품 사이에 무엇이 있는지 알게 되었습니다. 이 30가지 질문은 세 가지 실제 시나리오에서 나왔습니다. 먼저 직접 소리 내어 답해본 뒤 프레임워크를 확인하세요.
이 페이지 활용법
각 질문에는 질문자가 표시되어 있습니다. 같은 지식을 묻지만 듣고 싶은 대답이 다릅니다.
🎙 면접관실제로 출시한 경험이 있는지, 아니면 Demo만 봤는지 확인하고 싶어합니다
👔 상사설명, 방안, 실행 가능한 약속을 원합니다
🛠 기술 동료얼마나 큰 그림을 그리는지, 비용을 얼마나 이해하는지 살펴봅니다
각 질문에는 세 가지 레이어가 있습니다: 무엇을 평가하는가 → 답변 프레임워크 → 보너스 포인트. 답하기 어려운 부분은 마지막에 있는 강좌 페이지를 클릭해 복습하세요.
Q1면접관
「팀이 하루 만에 이미지 생성 API를 연동했고 Demo도 잘 작동합니다. 실제 출시까지 얼마나 남았다고 생각하나요? 무엇이 부족한가요?」
🎯 무엇을 평가하는가
이것은 실제로 AI 기능을 출시한 경험이 있는지 판단하는 분수령 질문입니다. Demo만 해본 사람은 「조금만 다듬으면 출시할 수 있어요」라고 말하지만, 실제 출시 경험이 있는 사람은 API 연동은 10%에 불과하고 나머지 90%가 전부 제품화 작업이라는 것을 알고 하나하나 나열할 수 있습니다.
🧭 답변 프레임워크
- 먼저 결론부터: API 연동은 10%에 불과합니다. 실제 사례에서 연동부터 출시까지 3개월이 걸렸으며, 부족한 부분은 네 가지 차원으로 정리할 수 있습니다.
- 경험 레이어: 생성 진행 피드백, 실패 시 원클릭 재시도, 다중 결과 선택, 히스토리 조회. Demo에서는 사용자가 30초를 기다려도 됩니다만, 제품에서는 안 됩니다.
- 품질 및 엔지니어링 레이어: 품질은 Prompt 최적화(LLM으로 사용자의 자연어를 이미지 생성 모델이 이해할 수 있는 설명으로 변환)와 캐릭터 일관성 앵커링에 의존합니다. 엔지니어링은 다중 모델 폴백 체인, 타임아웃 재시도, 비용 상한, 결과 영속화에 의존합니다. 모델은 반드시 장애가 발생하며, 장애 후의 경험이 곧 제품입니다.
- 안전 레이어: 입출력 이중 콘텐츠 심사, 저작권 위험, 사용자 참조 이미지 개인정보 정책. Demo는 무방비 상태로 운영할 수 있지만, 제품이 그러면 사고가 납니다.
⭐ 가산점 이 체크리스트의 범용성을 한마디로 언급하세요: 어떤 AI 기능이든 Demo에서 Production으로 가는 길은 경험, 품질, 엔지니어링, 안전의 네 가지 차원입니다. 방법론이 있다는 것을 들은 면접관은 목록을 암기한 것을 들은 것보다 훨씬 깊은 인상을 받습니다.
Q2상사
「사용자가 Agent가 30분이나 돌아가도 멈추지 않았고 결국 아무것도 돌아오지 않았다고 합니다. 무슨 일이었나요? 앞으로 이런 일이 다시 발생하지 않도록 어떻게 할 계획인가요?」
🎯 무엇을 평가하는가
상사는 근본 원인 설명과 예방 약속, 두 가지를 모두 원합니다. 「모델이 이상해졌어요」라고만 하면 들통납니다. 루프 패턴을 설명할 수도 없고, 스스로 멈추게 하는 메커니즘도 없다는 의미니까요. 「기술팀에 타임아웃 추가하라고 하겠습니다」는 절반 점수밖에 안 됩니다 - 그건 가장 거친 레이어일 뿐입니다.
🧭 답변 프레임워크
- 먼저 근본 원인 설명: 프로덕션 환경에서 Agent 루프에는 네 가지 전형적인 패턴이 있습니다: 동일 파라미터 무한 루프(같은 파라미터로 같은 도구를 반복 호출), 수익 감소(50라운드를 돌아도 모두 주변 행동), 텍스트 반복(컨텍스트가 너무 길어지면 같은 말을 반복), 도구 연속 실패 연쇄(하나의 도구 장애가 전체 체인을 끌어내림). 이번 케이스가 어떤 패턴인지 먼저 파악하세요.
- 예방 방안 제시: 실수 방지는 세 겹의 그물입니다. 하드 제한 안전망: 반복 상한, 총 타임아웃, 도구당 최대 호출 횟수 - 무조건적 브레이크. 탐지 및 경고: 동일 파라미터 탐지, 동일 도구명 탐지, 수익 감소 탐지 - 이상 패턴 발견 시 보고.
- 점진적 강등: 이상 감지 시 먼저 부드럽게 수정: 「이미 3번 반복했습니다, 다른 방법을 시도해주세요」라는 메시지 주입, 장애 도구 임시 비활성화, 현재 진행 상황을 강제 요약하고 반제품을 가지고 반환합니다. 사용자 입장에서 반제품이라도 가져오는 것이 빈손으로 돌아오는 것보다 훨씬 낫습니다.
- 경험 레이어 약속 추가: Agent가 긴 작업을 실행 중이라도 사용자는 진행 상황을 볼 수 있어야 하고, 현재 무엇을 하고 있는지 보여주며, 언제든지 수동으로 중지할 수 있어야 합니다. 사용자가 화내는 진짜 이유는 「30분을 기다렸는데 뭘 하고 있는지도 몰랐어요」입니다.
⭐ 가산점 한 마디 추가: 「사용자는 Agent가 루프에 빠졌다고 보고하지 않습니다. 그냥 이 AI 왜 이렇게 느리고 멍청하냐고만 하죠」. 기술적 장애를 사용자 관점으로 해석할 수 있다면 상사는 당신이 이 일을 책임질 수 있는 사람이라고 느낍니다.
Q3면접관
「AI 어시스턴트의 대화가 길어질수록 비용도 늘고 성능도 떨어집니다. 컨텍스트 압축을 어떻게 설계하겠습니까? 삭제할 수 있는 것과 절대 건드릴 수 없는 것은 무엇인가요?」
🎯 무엇을 평가하는가
압축 결정 프레임워크가 있는지, 그리고 레드라인을 알고 있는지 테스트합니다. 「모델로 요약하면 되죠」라고 답하는 사람은 들통납니다: 요약 자체의 비용도 계산해보지 않았고, 잘못 삭제했을 때 사용자가 「분명히 말했는데 왜 잊어버렸어요?」라고 당장 알아채는 결과도 인식하지 못한 것입니다.
🧭 답변 프레임워크
- 왜 압축이 필요한지부터 설명: 매 대화 턴마다 전체 기록을 모델에 다시 전송합니다. 대화가 길수록 비용은 높아지고, 집중도는 분산되며, 컨텍스트 창 한계에 가까워집니다 - 세 가지 문제가 컨텍스트 관리를 강제합니다.
- 계층적 프레임워크 제시: 삭제 가능: 오래된 도구 호출 결과, 이미 처리된 중간 단계. 압축 가능: AI의 긴 답변, 검색 결과 - 한 문장 요약으로 압축. 절대 손대지 말 것: 사용자의 원본 메시지, System Prompt, 핵심 설정.
- 레드라인 명시: 사용자의 말은 신성불가침입니다. AI가 한 말 1000자를 삭제하더라도 사용자가 한 말 10자는 건드리지 마세요. 압축 우선순위 높음에서 낮음: 도구 출력, AI 답변 - 사용자 메시지는 절대 건드리지 않습니다.
- 각 방법의 비용 명확히 설명: 로컬 압축(자르기, 규칙 기반 교체)은 비용 없이 처리하지만 거칩니다. LLM 요약은 정확하지만 토큰 비용이 발생합니다. 올바른 순서는 무료 먼저 유료 나중: 로컬 방법으로 명백한 군더더기를 먼저 제거하고, 나머지에 LLM 요약을 고려합니다.
⭐ 가산점 사용자 경험 측면을 먼저 제시: 압축이 잘 되면 사용자는 전혀 인식하지 못합니다. 잘못되면 AI가 「기억상실」이라고 느낍니다. 압축을 단순한 비용 절감이 아닌 UX 지표로 측정하는 것 - 이 관점을 제시하는 사람은 거의 없습니다.
이 강의 페이지로 답변을 구성하세요 →
대화가 길수록 비용도 높아지고 더 멍청해집니다
압축은 트레이드오프의 예술입니다
사용자의 말을 삭제할 수 있을까요?
로컬 압축 vs LLM 압축
Q4면접관
「제품에 「AI가 사용자를 기억하게」하는 기능이 필요합니다. 이 기억 시스템을 어떻게 설계하겠습니까? 모든 대화를 저장하나요? 사용자가 마음을 바꾸면 어떻게 합니까?」
🎯 무엇을 평가하는가
연속 세 질문이 기억 시스템에 대한 완전한 설계 능력을 테스트합니다: 무엇을 저장하는지, 어떻게 업데이트하는지, 어떻게 사용하는지. 「기억」과 「컨텍스트」를 혼동하는 사람은 첫 마디에 들통납니다. 「전부 저장하고 나중에 조회」라는 사람은 비용과 노이즈 관문을 통과하지 못합니다.
🧭 답변 프레임워크
- 먼저 두 시스템을 구분: 컨텍스트 창은 화이트보드 - 가득 차면 지우고, 대화가 끝나면 초기화됩니다. 장기 기억은 노트북 - 기록한 내용은 다음에 열어도 남아 있습니다. 기억 기능을 구축하는 전제는 화이트보드가 신뢰할 수 없다는 것을 인정하는 것입니다.
- 게이트키퍼 설계: 사용자는 매일 수십에서 수백 개의 메시지를 보내는데 「응」「알겠어」「하하」가 대부분을 차지하며, 기억할 가치 있는 선호와 사실은 몇 개뿐입니다. 기록 전에 이 정보가 장기적 가치가 있는지 판단하는 필터링 레이어가 필요합니다.
- 기억 충돌 처리: 사용자가 지난달에는 커피를 좋아한다고 했고 이번 달에는 차로 바꿨다고 합니다. 시나리오에 따른 네 가지 전략: 명확한 교체 → 덮어쓰기 업데이트. 보완적 정보 → 병합 확장. 어느 것이 맞는지 알 수 없음 → 충돌로 표시해 확인 대기. 임시 상태(최근 너무 피곤해서 늦게 일어남) → 건너뛰고 저장하지 않음.
- 주입 비용 계산: 1000개를 저장했을 때, 매번 System Prompt에 전부 넣는 것은 간단하지만 비싸고 노이즈가 많습니다. 필요 시 검색은 비용을 절약하지만 누락될 수 있습니다. 기억 규모와 시나리오에 따라 주입 전략을 선택해야 하며, 이는 비용 결정입니다.
⭐ 가산점 「기억 시스템의 핵심 능력은 업데이트입니다. 추가만 할 줄 아는 기억 시스템은 두 달이면 소문 창고가 됩니다」라고 지적하세요. 대부분의 사람들은 쓰기만 설계하고 만료와 오류 수정은 설계하지 않습니다.
Q5기술 동료
「PRD에 다중 Agent 협업이 필요하다고 쓰고 멋진 아키텍처 다이어그램도 그렸는데요. 정말 그렇게 많은 Agent가 필요한가요? 하나로는 안 되나요?」
🎯 무엇을 평가하는가
기술 동료는 당신이 진짜 생각해봤는지 아니면 트렌드만 쫓는지 탐색하고 있습니다. 다중 Agent는 더 많은 조율 비용과 더 많은 오류 가능성을 의미하며, 그들이 이 복잡성의 비용을 지불해야 합니다. 「왜 하나의 Agent로는 안 되는가」를 답하지 못하면 이 요구사항은 반려될 가능성이 높습니다.
🧭 답변 프레임워크
- 기본 입장 인정: 기본 입장은 하나의 Agent로 충분합니다. 다중 Agent가 필요하다고 하는 많은 시나리오는 실제로는 Prompt가 잘 작성되지 않은 것입니다. 두 번째 Agent를 추가하기 전에 세 가지 질문을 거쳐야 합니다: 하나로는 정말 안 되는가? 복잡성이 가치 있는가? 더 간단한 방법은 없는가(예: 도구 병렬 호출)?
- 정말 필요한 세 가지 시나리오: 병렬 가속 - 5개 소스를 동시에 검색하면 직렬보다 5배 빠릅니다. 역할 분리 - Writer가 쓰고 Reviewer가 검토하는 역할 격리로 검토가 진정으로 효과적이 됩니다. 위험 격리 - 서브 Agent가 PDF 파싱에 실패해도 「이 파일에 문제가 있습니다」만 보고하고 주 태스크는 영향받지 않습니다.
- 시나리오 대입: PRD의 구체적인 시나리오로 돌아가 어떤 케이스에 해당하는지 설명하세요. 해당하면 유지하고, 해당하지 않으면 그 자리에서 삭제하세요 - 아키텍처 다이어그램을 고집하며 강변하는 것보다 훨씬 보기 좋습니다.
- 동시성 상식 시연: 다중 Agent를 사용하더라도 「읽기」는 병렬 가능하고 「쓰기」는 직렬화해야 한다는 것을 알아야 합니다. 작업의 동시 실행 가능 여부를 판단하는 핵심은 한 가지: 읽기 전용인가요?
⭐ 가산점 먼저 말하세요: 「이 세 가지 시나리오 중 하나도 해당하지 않는다면 단일 Agent로 되돌리겠습니다」. 기술 동료가 가장 두려워하는 것은 슬라이드 아키텍처 비용을 지불해야 하는 PM입니다 - 먼저 퇴로를 말하면 신뢰가 즉시 형성됩니다.
Q6면접관
「MCP가 요즘 매우 핫한데요. 일반 API 호출과 어떻게 다른지 말씀해주세요. 여러분 제품에는 어떤 의미가 있나요?」
🎯 무엇을 평가하는가
MCP에 대한 이해가 어느 레이어에서 멈추는지 테스트합니다. 「AI가 외부 도구를 호출하는 프로토콜」이라고만 답하는 사람은 입문 기사 한 편 읽은 사람과 다를 바 없습니다. 진정으로 이해한 사람은 양방향을 설명합니다: 제품이 남의 능력을 소비할 수도 있고, 자신을 남의 도구로 만들 수도 있다는 것을.
🧭 답변 프레임워크
- 첫 번째 레이어: Client로서 제품은 MCP를 통해 외부 기능을 소비합니다: 캘린더, 이메일, 데이터베이스, 브라우저 - 하나의 프로토콜에 연결하면 전체 생태계를 활용할 수 있어 API를 하나씩 연동하는 비용을 절약합니다.
- 핵심 두 번째 레이어: MCP는 양방향입니다. 제품이 Server로서 자신의 능력을 외부에 노출해 Cursor, Claude Desktop, 자동화 스크립트가 당신을 호출하게 할 수도 있습니다. 단방향 통합은 도구 호출일 뿐이지만, 양방향은 당신의 AI가 남의 도구가 될 수 있다는 것을 의미합니다.
- 제품적 의미 설명: 여러 Agent가 서로를 호출할 수 있을 때 생태계가 자연스럽게 형성됩니다. 이것은 도구에서 플랫폼으로의 핵심 도약이며, 제품 포지셔닝 결정으로서 PM이 내려야 합니다.
- 엔지니어링 상식 추가: 10개의 MCP 서비스에 연결할 때 시작 시 전부 연결하면? 3개가 다운되면 시작이 멈춥니다. 등록과 연결을 분리하고 필요할 때 연결하세요(지연 연결). 더 나아가 Agent가 실행 중에 도구가 없다는 것을 발견하면 스스로 새로운 MCP 연결을 발견하고 구성할 수 있습니다.
⭐ 가산점 한 마디로 마무리: 「MCP가 AI 제품에 가지는 의미는, 과거 오픈 플랫폼이 모바일 인터넷에 가졌던 의미와 유사합니다. 먼저 자신이 통합하는 쪽인지 통합되는 쪽인지 명확히 하세요.」 프로토콜 문제를 생태계 포지셔닝 문제로 격상시키면 면접관이 기억합니다.
Q7상사
「이번 달 API 청구서가 지난달보다 3배 늘었는데 사용자 수는 20%밖에 늘지 않았습니다. 돈이 다 어디로 갔나요? 다음 달에는 낮출 수 있을까요?」
🎯 무엇을 평가하는가
Agent 제품의 비용 구조를 이해하는지 테스트합니다. 비용이 메시지 수에 비례한다고 생각하는 사람은 청구서가 왜 사용자 수보다 빠르게 증가하는지 설명할 수 없습니다. 청구서를 턴과 컨텍스트 길이 레벨로 분해할 수 있는 사람만이 낮추는 방법을 이야기할 자격이 있습니다.
🧭 답변 프레임워크
- 먼저 측정 단위 수정: 사용자가 한 마디를 보내면 내부적으로는 10번 이상의 루프 반복과 수십 개의 API 메시지가 실행될 수 있으며, 매 반복마다 전체 기록을 다시 전송합니다. 비용은 태스크 복잡도와 연결되어 지수적으로 증가하므로 청구서가 사용자 수보다 빠르게 증가하는 것은 정상입니다 - 통제 불능이 문제입니다.
- 전형적인 비용 주범 찾기: 스케줄 태스크가 이전 세션을 재사용하면 컨텍스트가 계속 늘어나고, 이 하나의 선택이 월 청구서를 10배 차이 나게 할 수 있습니다. 루프에 갇힌 Agent가 공회전하며 돈을 낭비합니다. 긴 대화에 압축이 없으면 매 턴마다 오래된 기록 비용을 지불합니다.
- 비용 절감 조합 제시: 스케줄 태스크를 매번 새 세션 생성으로 변경. 루프 실수 방지를 배포해 공회전 차단. 컨텍스트 압축으로 재전송하지 않아야 할 토큰 제거. 사용자와 시간대별 비용 상한 설정, 이상 호출 모니터링.
- 약속 정량화 방법 제시: 태스크당 평균 비용 모니터링 대시보드를 구축하세요. 「다음 달에 낮출 수 있나요」를 「태스크당 비용 목표와 이상 호출 0건」으로 전환하고 주간 보고합니다.
⭐ 가산점 한 마디 추가: 「비용 증가의 다른 면은 너무 아끼면 더 멍청해지고, 압축이 지나치면 경험이 떨어집니다」. 비용과 경험의 트레이드오프를 먼저 테이블에 올려놓으면 제품 결정을 내리는 것이지 단순히 회계를 하는 것이 아님을 보여줍니다.
Q8면접관
「우리 제품에 이미지 생성 기능을 넣으려고 합니다. 텍스트→이미지와 이미지→이미지를 어떻게 고를 건가요? '둘 다 써볼게요'는 안 됩니다. 구체적인 시나리오를 몇 개 주세요.」
🎯 무엇을 평가하는가
이것이 이미지 생성 제품의 첫 번째 갈림길이라는 것을 아는지 봅니다. 텍스트→이미지와 이미지→이미지는 완전히 다른 두 가지 제품 전략입니다. 「어느 쪽이 잘 나오면 그걸 쓰죠」라고 답하는 사람은 실제 제품에서 이미지 생성 결정을 내려본 적이 없는 것입니다.
🧭 답변 프레임워크
- 먼저 핵심 차이부터: 텍스트→이미지는 무에서 유를 만드는 것이고, 모델이 매번 캐릭터를 다르게 상상합니다. 이미지→이미지는 참조 이미지를 앵커로 삼아 외모를 잠그고, 장면과 동작만 바꿉니다.
- 시나리오 대조를 주세요: 순수 배경, 음식·물건 클로즈업, 창의적 발산은 텍스트→이미지를 씁니다. 자유도가 높고 더 싸기도 합니다. 캐릭터 등장, 캐릭터 환복(얼굴은 그대로 옷만 변경), 다중 장면 시리즈 이미지는 반드시 이미지→이미지여야 합니다. 그렇지 않으면 사용자가 「왜 장마다 생김새가 다르지?」를 알아챕니다.
- 판단 기준을 주세요: 한 가지만 물으면 됩니다. 「이 이미지에 '반드시 같은 사람이어야 한다'는 제약이 있는가」. 있으면 이미지→이미지, 없으면 텍스트→이미지가 더 유연합니다.
- 제품 함의를 보완: 이미지→이미지를 고른다는 것은 먼저 표준 참조 이미지라는 소재 자산을 만들어야 한다는 뜻입니다. 일정에 넣어야 하는 제품 측 작업량입니다.
⭐ 가산점 「참조 이미지가 있는지가 완전히 다른 두 갈래 제품 전략을 결정한다」는 점을 짚으세요. 달라지는 것은 출도 품질만이 아니라, 소재 파이프라인 전체와 비용 구조입니다.
Q9면접관
「사용자가 「석양 아래 고양이를 그려줘」라고 입력했습니다. 이 문장을 이미지 생성 모델에 그대로 보내면 안 되나요? 왜 중간에 LLM을 한 번 더 거쳐 돈을 더 쓰나요?」
🎯 무엇을 평가하는가
이미지 생성 제품의 핵심 아키텍처, 즉 Prompt 재번역 레이어를 이해하는지 봅니다. 이 레이어는 쓸모없어 보이지만 사실 출도 품질의 급소입니다. 「왜 반드시 번역해야 하는가」를 말하지 못하는 사람이 만든 이미지 생성 기능은 가챠 기계입니다.
🧭 답변 프레임워크
- 먼저 결론부터: 사용자가 원하는 것과 이미지 생성 모델이 필요로 하는 것은 두 가지 언어입니다. 중간에 LLM이 번역해서, 한 문장을 수백 토큰의 정밀한 시각 설명으로 늘려야 합니다.
- 이유 세 가지: 사용자는 이미지 생성 Prompt를 쓰지 않습니다. 누가 먼저 golden hour lighting 같은 단어를 치겠습니까. 모델은 모호한 의도를 이해하지 못합니다. 「멍하니 있다」는 그것에게 화면이 아닙니다. 게다가 이미지 생성 모델마다 사투리가 다릅니다. Midjourney, DALL-E, Stable Diffusion의 취향이 제각각이라 목표 모델에 맞춰 커스터마이즈해야 합니다.
- 예시를 드세요: 「Alice가 발코니에서 멍하니 있다」가 번역 레이어를 거치면 자세, 표정, 조명, 헤어스타일, 상징적인 목걸이, 구도가 갖춰진 긴 영어 설명이 되고, 그때야 출도가 안정됩니다.
- 아키텍처 위치를 주세요: 이 번역 레이어는 이미지 생성 제품화 체크리스트에 들어가는 고정 아키텍처입니다. 빼서 아끼는 돈은 작고, 잃는 것은 출도 품질입니다.
⭐ 가산점 한 마디 더: 번역 레이어는 캐릭터 특징(헤어스타일, 목걸이 같은 앵커)을 일괄 주입하는 곳이기도 합니다. 캐릭터 일관성 전략과 원래 한몸입니다.
Q10기술 동료
「당신이 올린 버그 「IP 캐릭터가 생성할 때마다 생김새가 다르다」는, 온도만 조절하고 시드를 고정하면 되는 거 아닌가요? 큰일 아닙니다.」
🎯 무엇을 평가하는가
기술 쪽이 캐릭터 일관성을 파라미터 튜닝 문제로 보는지, 제품 설계 문제로 보는지 떠보고 있습니다. 고개를 끄덕이면 2주 뒤에 같은 버그가 그대로 돌아오고, 「파라미터는 이미 조정했습니다」라는 한 줄이 더 붙습니다.
🧭 답변 프레임워크
- 먼저 성격을 정하세요: 이것은 이미지 생성 제품에서 가장 어려운 문제 중 하나입니다. 파라미터를 만져서는 해결되지 않습니다. 순수 텍스트 설명으로 네 번 연속 생성하면 얼굴형, 헤어, 체형, 화풍이 전부 흘러갑니다. 텍스트로는 시각적 정체성을 잠글 수 없습니다.
- 방안을 주세요: IP를 위한 표준 캐릭터 참조표(Character Reference Sheet)를 만들고, 매번 생성할 때 참조 이미지를 함께 보내 모델이 「보고 그리게」 합니다. 이미지→이미지로 앵커링합니다.
- 무엇을 고정하는지 말하세요: 얼굴과 체형(이목구비 비율, 실루엣), 표정 스타일(여러 표정 변형을 미리 준비), 의상(상징적인 옷. 환복 장면에서는 옷만 바꾸고 얼굴은 바꾸지 않음).
- 경계를 보완: 폴백 체인의 일부 대체 모델은 이미지→이미지를 지원하지 않습니다. 그리로 전환하면 순수 텍스트→이미지로 떨어지고 일관성이 떨어집니다. 이 손실은 폴백 방안에서 미리 선언하고, 나중에 사고로 다루지 마세요.
⭐ 가산점 제품 측 작업량을 먼저 가져가세요: 참조 이미지 자산의 제작과 유지는 PM이 밀어야 하는 일입니다. 기술 쪽이 당신은 요구만 한다고 느끼게 하지 마세요.
Q11면접관
「이미지 생성이 서드파티 모델에 의존합니다. 어느 날 Gemini가 타임아웃되고 Seedream이 또 레이트 리밋에 걸리면, 제품은 어떻게 하나요? 폴백 설계를 말해 보세요.」
🎯 무엇을 평가하는가
「모델은 반드시 장애가 난다」는 엔지니어링 안전망 사고가 있는지 봅니다. 「복구될 때까지 기다리죠」나 「에러 메시지를 띄우죠」라고 답하는 사람은 새벽 알람 전화를 받아본 적이 없습니다.
🧭 답변 프레임워크
- 먼저 체인을 한 바퀴: 모델 A가 15초 타임아웃되면 서킷 브레이커가 동작해 자동으로 모델 B로 전환합니다. B가 레이트 리밋이면 C로 이어지고, C가 이미지를 냅니다. 사용자는 「그리는 중」만 보고, 뒤에서 모델 세 개가 바뀐 줄 모릅니다.
- 메커니즘 세 가지: 우선순위와 화이트리스트. 캐릭터 등장은 일관성이 가장 좋은 모델, 순수 배경은 싸고 빠른 모델. 헬스 체크. 각 모델 상태를 주기적으로 탐지해, 다운이 확인된 것은 건너뛰고 복구되면 자동으로 돌아옵니다. 이미지→이미지 폴백. 대체 모델이 이미지→이미지를 지원하지 않으면 텍스트→이미지로 내려가, 품질은 한 단계 낮아져도 이미지는 나옵니다.
- 전부 다운일 때의 안전망: 모든 모델이 죽으면 친근한 문구 「서비스가 혼잡합니다. 대기열에 넣었고, 완료되면 알려드릴게요」. 차가운 에러 페이지는 절대 주지 않습니다.
- 원칙 한 줄로 마무리: 사용자는 어떤 모델이 죽었는지 관심이 없습니다. 이미지가 나오느냐만 봅니다. 폴백 설계의 목표는 장애를 체감 손실이 가장 작은 대기로 번역하는 것입니다.
⭐ 가산점 폴백 체인의 검수 기준은 「최악 경험」이라고 말하세요. 잘 설계하면 최악도 몇 초 더 기다리거나 친근한 안내를 받는 것뿐입니다. 그게 제품화입니다.
Q12면접관
「이력서에 Agent에 익숙하다고 쓰셨네요. 그럼 Agent 루프를 말해 보세요. 「생각하고, 하고, 보고」 세 단계로 도는 거죠?」
🎯 무엇을 평가하는가
함정 질문입니다. 교과서를 외웠는지, 프로덕션을 봤는지를 봅니다. 고개 끄덕이며 「맞아요」라고 하는 사람은 바로 빠집니다. 면접관은 교과서가 생략한 부분을 당신이 꺼내 주기를 기다립니다.
🧭 답변 프레임워크
- 먼저 받아치세요: 교과서의 ReAct는 정말 Think, Act, Observe 세 단계입니다. 뼈대는 맞지만, 그것만으로는 한참 부족합니다.
- 그다음 펼치세요: 프로덕션에서 한 바퀴는 실제로 11단계 정도를 돕니다. 더 있는 것은 컨텍스트 트리밍과 토큰 예산 검사, 시스템 지시 주입, 권한 검증과 파라미터 적합성, 동시 스케줄링, 타임아웃 모니터링과 오류 안전망, 결과 회신, 보안 감사 로그입니다.
- 본질을 짚으세요: 더 있는 이 단계들이 엔지니어링 분량의 대부분입니다. Agent가 안정적이고 안전하고 쓸 수 있는지는, 바로 교과서에 없는 부분에 달려 있습니다.
- 하나를 골라 깊게: 권한 검증 한 단계가 이 도구를 현재 사용자가 호출할 수 있는지, 파라미터가 적법한지를 결정합니다. 이것이 빠지면 Agent 출시 첫날이 보안 사고입니다.
⭐ 가산점 일정 관점을 한 줄 더: 실제 Agent가 한 바퀴 돌 때 하는 일은 교과서보다 5배 많습니다. 작업량을 평가할 때는 11단계로 계산하세요. 3단계로 짠 일정은 반드시 터집니다.
Q13면접관
「도구 호출 하나가 백그라운드에서 30초 돌아갑니다. 이 30초 동안 사용자 화면에는 무엇이 있어야 하나요? 방안을 말해 보세요.」
🎯 무엇을 평가하는가
AI 제품 인터랙션 실력을 봅니다. 「로딩 애니메이션만 넣으면 됩니다」라고만 답하는 사람은 대기 경험을 고민해 본 적이 없습니다. 면접관이 듣고 싶은 것은 완전한 진행감 설계입니다.
🧭 답변 프레임워크
- 먼저 원칙부터: 사용자는 기다리는 것은 참을 수 있지만, 무엇을 기다리는지 모르는 것은 참지 못합니다. 진행감 3원칙: 과정을 보여 주고, 진행을 체감하게 하고, 출력을 점진적으로 나타나게 합니다.
- 수단 목록: 상태 문구(「검색 중」「분석 중」); 지금 호출 중인 도구 이름을 그대로 보여 주기; 토큰 단위 스트리밍 출력; 단계 표시(1단계 / 총 3단계); 중간 산출물을 먼저 주기, 예를 들어 아웃라인 먼저 내고 세부 채우기.
- 대비 화면: 똑같이 30초를 기다리는데, 한쪽은 빙글빙글 애니메이션뿐이라 사용자는 멈춘 줄 의심하고, 다른 쪽은 「결과 3건 찾음」「파일 2/5 분석 완료」가 흘러가 사용자는 읽고 있습니다. 체감은 완전히 다른 제품입니다.
- 통제감을 한 겹 더: 긴 작업에는 언제든 누를 수 있는 중지 버튼이 있어야 합니다. 멈출 수 있는 대기라야 불안하지 않습니다.
⭐ 가산점 「진행감 ≠ 진행 바」를 짚으세요. AI 작업 시간은 원래 정확히 예측할 수 없습니다. 핵심은 사용자가 AI가 진지하게 일하고 있다고 느끼게 하는 것이고, 스트리밍 출력 자체가 최고의 진행 바입니다.
Q14기술 동료
「PRD에 「단일 태스크 비용을 5센트 이내로」라고 쓰여 있습니다. 사용자가 「이 모듈 리팩터링해 줘」라고 한 마디 하면, 밑에서 실제로 토큰이 얼마나 타는지 아나요?」
🎯 무엇을 평가하는가
기술 쪽이 PRD의 비용 숫자가 계산한 것인지 감으로 찍은 것인지 떠보고 있습니다. 규모를 대지 못하는 PM이 쓴 비용 지표는 아무도 진지하게 보지 않습니다.
🧭 답변 프레임워크
- 규모를 바로 대세요: 날씨 조회 같은 단순 태스크는 2바퀴 루프, 메시지 6개, 약 1000 토큰, 비용 $0.003. PDF 분석은 6바퀴, 약 5700 토큰, $0.02. 코드 리팩터링은 12바퀴, 메시지 스무 개 남짓, 토큰 거의 8000, $0.08. 태스크 복잡도가 다르면 비용이 수십 배 차이 납니다.
- 비용의 큰 덩어리를 짚으세요: System Prompt는 매 턴 다시 보내집니다. 도구가 돌려주는 긴 텍스트(파일 전체, 검색 결과 한 페이지)는 눈에 안 띄는 대어입니다. 컨텍스트가 눈덩이처럼 불어, 뒤 턴마다 앞의 모든 메시지를 가져갑니다.
- 지표 쓰는 법을 고치세요: 비용 상한은 태스크 유형별로 나누고, 태스크당 비용 모니터링을 붙이세요. 숫자 하나로 자르지 마세요.
⭐ 가산점 Agent 비용에서 가장 직관에 반하는 점을 짚으세요: 턴이 늘수록 눈덩이처럼 불어 선형보다 빠르게 증가합니다. 전통적인 「한 번 호출, 한 번 과금」 API 직감과는 완전히 다릅니다.
Q15면접관
「사용자 피드백으로, AI가 뒤로 갈수록 더 멍청해지고 전에 말한 요구를 자꾸 잊는다고 합니다. 사용자 착각인가요, 아니면 메커니즘상 진짜 이유가 있나요?」
🎯 무엇을 평가하는가
긴 컨텍스트의 세 가지 대가를 아는지 봅니다. 「모델이 불안정해서일 수도 있죠」라고 답하는 사람은 컨텍스트 메커니즘을 이해하지 못한 것입니다. 이 책임은 모델이 지지 않습니다.
🧭 답변 프레임워크
- 먼저 결론부터: 착각이 아닙니다. 메커니즘 세 개가 겹칩니다. 비용 증가: 매 턴 전체 히스토리를 다시 보내, 8번째 턴의 단건 비용이 1번째의 20배가 될 수 있습니다. 어텐션 감쇠: 모델은 컨텍스트 양끝은 뜨겁고 중간은 차갑습니다. 3번째 턴에 말한 중요한 요구가 8번째에는 무시될 수 있습니다. 윈도우 오버플로: 128K 윈도우가 차면 가장 이른 메시지는 그냥 버려집니다. AI는 정말로 못 봅니다.
- 증상을 나누세요: 「멍청해짐」은 주로 어텐션 감쇠와 윈도우 오버플로에서, 「비싸짐」은 비용 증가에서 옵니다. 증상은 둘, 뿌리는 하나: 컨텍스트가 절제 없이 길어지는 것입니다.
- 액션을 주세요: 컨텍스트 관리는 필수 과제입니다. 압축 전략을 올리고, 사용자 선호 같은 핵심 정보는 따로 지켜, 긴 대화와 함께 희석되지 않게 하세요.
⭐ 가산점 가장 직관에 반하는 한 줄을 짚으세요: 사용자는 AI가 맨 처음 한 말을 잊었다고 생각하지만, 어텐션이 가장 낮은 곳은 대화 중반입니다. 중간 턴에 꺼낸 요구가 가장 위험합니다.
Q16기술 동료
「컨텍스트 압축은 모델을 하나 불러 요약하게 할 생각입니다. 어차피 효과가 좋으니까요. 매 턴마다 한 번씩 누르면 될까요?」
🎯 무엇을 평가하는가
망치를 든 사람에게는 모든 것이 못으로 보입니다. 압축은 파이프라인이고, 공짜를 먼저 쓰고 돈을 나중에 쓴다는 것을 아는지 봅니다. 순서가 바뀌면 돈으로 게으름을 사는 것입니다.
🧭 답변 프레임워크
- 두 수단의 장부를 펼치세요: 로컬 압축은 정규식, 자르기, 템플릿 치환으로 비용 0, 지연 1밀리초 미만이지만 거칠습니다. LLM 압축은 다른 모델이 읽고 요약을 쓰니 의미를 정확히 지키지만, 매번 API 돈과 1~5초 지연입니다.
- 올바른 순서: 4단계 파이프라인. 먼저 로컬로 자르고, 도구 출력을 지우고 너무 긴 JSON을 깎습니다. 그다음 템플릿 치환으로 반복 구조를 플레이스홀더로 바꿉니다. 그다음 윈도우를 아직 넘는지 확인합니다. 그래도 안 되면 마지막에야 LLM에게 정제을 맡깁니다.
- 내용별로 나누세요: 도구 출력, JSON 결과, 반복 내용은 로컬 압축으로 충분합니다. 멀티턴 대화 요약, 복잡한 컨텍스트 농축만이 LLM 돈을 쓸 가치가 있습니다.
- 결론: 매 턴 LLM 요약을 돌리는 것은 대화마다 고정세를 매기는 것과 같습니다. 두 수단은 파이프라인의 선후 단계이지, 둘 중 하나를 고르는 문제가 아닙니다.
⭐ 가산점 압축 우선순위를 상기시키세요: 먼저 도구 원본 출력을 지우고, 그다음 AI 자신의 답변을 누르고, 사용자 원문은 절대 건드리지 않습니다. 압축 수단이 아무리 싸도 사용자 말을 지운 것은 감점입니다.
Q17면접관
「기억 시스템에 사용자 기억이 1000개 있습니다. 대화할 때마다 이 1000개를 모델에 전부 넣나요, 아니면 어떻게 하나요?」
🎯 무엇을 평가하는가
기억 주입의 비용 장부를 계산해 봤는지 봅니다. 「전부 넣는 게 안전하죠」라고 답하는 사람은 돈을 안 세어 봤고, 노이즈가 모델을 익사시킨다는 것도 모릅니다.
🧭 답변 프레임워크
- 먼저 전량 주입을 잘라내세요: 기억이 적을 때만 가능합니다. 1000개를 system prompt에 전부 넣으면 호출마다 그 토큰 더미에 돈을 내고, 대부분은 지금 질문과 무관한 순수 노이즈라 AI가 오히려 초점을 못 찾습니다.
- 추천 체인을 주세요: 사용자가 메시지를 보낸 뒤 먼저 시맨틱 검색을 해, 기억 창고에서 가장 관련 있는 3~10개만 꺼내 system prompt에 넣고, 그다음 모델이 답하게 합니다.
- 핵심 원칙을 짚으세요: 기억의 가치는 매번 가장 관련 있는 몇 개를 꺼낼 수 있다는 데 있습니다. 몇 개를 저장했는지는 중요하지 않습니다. 기억이 늘수록 온디맨드 검색이 유일하게 확장 가능한 방안입니다.
- 비유로 마무리: 좋은 기억 시스템은 유능한 비서와 같습니다. 파일 캐비닛 전체를 회의실로 끌고 오지 않고, 오늘 쓸 서류 세 권만 미리 책상 위에 올려 둡니다.
⭐ 가산점 트레이드오프를 한 줄: 온디맨드 검색의 대가는 누락 가능이므로, 검색 파라미터는 제품이 조율하게 남겨 두세요. 두 개 더 꺼내더라도 사용자가 「지난번에 분명히 말했는데」를 발견하게 하지 마세요.
Q18면접관
「지금 System Prompt는 얼마나 긴가요? 누가 유지하나요? 한 문장을 고치면 전량 회귀 테스트가 필요한가요?」
🎯 무엇을 평가하는가
세 질문이 한곳을 가리킵니다: 당신의 System Prompt는 텍스트 덩어리인가, 엔지니어링인가. 구조를 말하지 못하는 사람은 제품이 조금만 복잡해져도 「한곳 고치면 세곳이 깨지는」 수렁에 빠집니다.
🧭 답변 프레임워크
- 먼저 구조부터: 프로덕션급 System Prompt는 네 층으로 관리합니다. 정체성 층은 내가 누구인지, 이름·성격·능력 경계, 거의 안 바뀝니다. 환경 층은 지금 상황, 사용자 언어·시스템 상태, 세션마다 다를 수 있습니다. 도구 층은 무엇을 쓸 수 있는지, 기능 이터레이션에 따라 늘고 줍니다. 행동 층은 어떻게 움직이는지, 출력 형식·결정 우선순위·안전 가드레일, 이터레이션이 가장 잦습니다.
- 계층화의 이득: 한 층을 고쳐도 다른 층은 안 건드립니다. 도구를 더하면 도구 층만, 스타일을 바꾸면 행동 층만. 제품·엔지니어링·운영이 각자 파일을 고치고, Git 머지가 충돌하지 않습니다.
- 회귀 질문에 답하세요: A/B 테스트는 행동 층만 바꾸고 나머지 세 층은 그대로 두어 변수를 하나로 만듭니다. 문제가 나면 층별로 봅니다. 페르소나가 틀렸는지, 환경이 낡은지, 도구 설명이 틀린지, 규칙이 충돌하는지, 한 층씩.
⭐ 가산점 빈도 차이가 계층화의 근거라고 짚으세요: 정체성 층은 몇 년 안 움직이고, 행동 층은 매주 바뀝니다. 변화 빈도가 다른 것을 한 파일에 섞는 것은, 안정적인 것을 손떨림 위험에 반복해서 노출하는 것입니다.
이 강의 페이지로 답변을 구성하세요 →
System Prompt는 텍스트 덩어리가 아닙니다
Q19기술 동료
「도구가 계속 늘어서 곧 100개가 됩니다. 도구 설명이 전부 System Prompt 안에 있어서, 요청 한 번에 설명만으로 토큰이 몇만 개입니다. 어떻게 하죠?」
🎯 무엇을 평가하는가
온디맨드 로딩이라는 해법을 아는지, 그리고 아끼는 것이 돈만이 아니라는 것을 아는지 봅니다. 도구가 많아지면 전량 주입은 토큰 청구서만이 아니라, 모델이 잘못된 도구를 고를 확률까지 올립니다.
🧭 답변 프레임워크
- 먼저 청구서를 확인: 강좌의 추산으로, 도구 100개를 전량 로드하면 약 3.4만 토큰, 온디맨드 로딩은 약 2800으로 90% 이상 절약합니다. 이 돈은 요청마다 나갑니다.
- 3단계 방안: 첫 턴에는 이름 목록만, 도구 이름과 한 줄 설명으로 AI가 이 능력이 있는지만 알게 합니다. AI가 호출을 결정하면 시스템이 전체 설명과 파라미터 형식을 동적으로 주입합니다. 쓰면 회수하고, 다음 턴은 다시 이름만 있는 상태로 돌아갑니다.
- 두 번째 이득을 짚으세요: AI도 사람과 같아서, 정보가 너무 많으면 초점을 못 찾습니다. 온디맨드 로딩은 돈을 아끼는 것 외에 도구 선택 정확도도 올립니다.
- 팀에 비유로: 회사 연락처에 모든 사람의 이력서 전체를 넣지 않습니다. 이름과 직함만 두고, 정말 협업할 때 상세를 봅니다.
⭐ 가산점 이 문제를 캐시와 이으세요: 도구 설명을 System Prompt 접두에 두고 자주 더하고 빼면 KV Cache까지 함께 망가집니다. 온디맨드 로딩은 일석삼조입니다.
Q20면접관
「System Prompt, Tool, Skill, 이 세 가지는 각각 무엇을 담당하나요? 왜 Skill 내용을 System Prompt에 그대로 쓰지 않나요?」
🎯 무엇을 평가하는가
Prompt 체계를 책임 경계로 말할 수 있는지 봅니다. 이 셋을 섞어 쓰는 제품은 행동을 이터레이션할 수도, 추적할 수도 없습니다. 면접관은 Prompt를 자산으로 관리하는 의식이 있는지 보고 있습니다.
🧭 답변 프레임워크
- 한 줄 분업: System Prompt는 내가 누구인지, 전역 정체성, 거의 안 고칩니다. Tool은 내가 무엇을 할 수 있는지, 능력 메뉴, 중빈도 변경. Skill은 어떤 일을 한 걸음씩 잘하려면, 특정 태스크의 프로세스 안내, 고빈도 이터레이션과 독립 버전.
- Skill 구조를 쪼개세요: 트리거 조건이 언제 로드할지 정합니다. 허용 도구 화이트리스트로 위험을 통제합니다. 실행 흐름은 요구 확인부터 전달까지 한 걸음씩 적습니다. 출력 형식 요구는 매번 산출 품질을 같게 만듭니다.
- 왜 System Prompt에 넣지 않는지: System Prompt는 전역이라 고치면 모든 시나리오에 영향을 줍니다. Skill은 온디맨드로, 맞는 태스크일 때만 주입되어 다른 태스크를 오염시키지 않습니다. 그리고 파일이 곧 설정이라, 누가 무엇을 바꿨는지 Git에서 한눈에 보입니다.
- 운영 가치로 구체화: Skill은 Prompt를 재사용·이터레이션·추적 가능하게 합니다. 파일을 고치는 것이 행동을 고치는 것입니다. Prompt를 코드처럼 관리하는 출발점입니다.
⭐ 가산점 라이프사이클 관점을 한 줄: 작성, 등록, 트리거, 이터레이션 네 단계, 태스크마다 파일 하나. 면접에서 이 루프를 그릴 수 있으면 명사 세 개를 외운 것보다 훨씬 강합니다.
Q21기술 동료
「Skill 내용을 System Prompt에 그냥 이어 붙였습니다. 구현이 제일 단순하니까요. 요즘 청구서가 좀 올랐는데, 이거랑 관련 있나요?」
🎯 무엇을 평가하는가
KV Cache의 접두 히트 규칙을 아는지, 그리고 구현 디테일을 청구서 상승에 걸 수 있는지 봅니다. PM이 엔지니어링 절감 포인트를 직접 짚을 수 있는 드문 기회입니다.
🧭 답변 프레임워크
- 먼저 규칙부터: 캐시는 System Prompt를 지문으로 봅니다. 접두가 한 글자라도 같아야 히트하고, 한 글자 다르면 전부 다시 계산합니다. 타임스탬프만의 문제가 아닙니다. 접두에 끼워 넣는 모든 동적 내용이 같습니다.
- 문제를 짚으세요: Skill을 System Prompt에 붙이면 Skill을 바꾸는 것이 접두를 바꾸는 것이라 캐시가 즉시 무효가 됩니다. 강좌 시뮬레이션에서 이런 주입 방식의 히트율은 약 20%입니다.
- 고치는 법: Skill을 System Prompt 뒤에 독립 메시지로 붙입니다. 접두는 영원히 안 바뀌고, 히트율은 약 90%까지 갈 수 있습니다. 사용자 ID, Session 표시처럼 변하는 것도 마찬가지, 전부 뒤로 보내세요.
- 원칙: 접두를 건드리지 마세요. 변할 수 있는 내용은 전부 System Prompt 뒤에 두고, 접두를 영원히 안정적으로 유지합니다.
⭐ 가산점 Harness 핵심편의 고전 반례와 이으세요: 동적 타임스탬프가 캐시를 깨는 것은 특례일 뿐입니다. 이 레슨의 결론은 더 넓습니다. 접두에 동적으로 주입하는 모든 내용이 캐시 킬러입니다.
Q22면접관
「멀티 Agent 시스템에서, 어떤 조작은 동시에 돌릴 수 있고 어떤 것은 줄을 서야 하나요? 실행할 수 있는 판단 규칙 하나를 주세요.」
🎯 무엇을 평가하는가
동시성이라는 엔지니어링 개념을 제품이 실행할 수 있는 규칙 한 줄로 압축할 수 있는지 봅니다. 규칙을 말하고 예외까지 말할 수 있어야 진짜 이해한 것입니다.
🧭 답변 프레임워크
- 그 규칙을 주세요: 이 조작이 끝나면 세계가 바뀌었는가? 안 바뀌었으면 병렬, 바뀌었으면 줄을 서야 합니다. 검색, 파일 읽기, API 조회는 읽기 전용이라 10개가 같이 돌아도 서로 영향이 없습니다. 파일 쓰기, 메일 발송, 결제는 외부 상태를 바꿉니다. 둘이 동시에 같은 파일을 고치면 데이터 덮어쓰기입니다.
- 이득을 계산: 강좌 예시로, 검색 3번과 쓰기 1번을 병렬 오케스트레이션하면 약 4초, 전부 직렬이면 약 8초. 검색은 병렬, 쓰기는 맨 마지막에 두면 시간이 절반입니다.
- 예외를 보완: 두 쓰기가 다른 것을 바꾸는 경우, 다른 파일, 다른 테이블이면 병렬도 됩니다. 충돌은 여러 조작이 같은 자원을 바꿀 때만 납니다.
- 설계 액션으로: 멀티 Agent 시스템을 설계하는 첫 단계는 도구를 읽기와 쓰기로 나누는 것입니다. 이 분류는 제품이 엔지니어링에 줘야 하는 입력입니다.
⭐ 가산점 규칙을 한 줄 기억 포인트로: 보기는 같이 보고, 고치기는 줄을 서서 고칩니다. 면접관이 기억하는 것은 대개 이 한 줄입니다.
Q23면접관
「AI 셋에게 같은 문제를 토론하게 하는 것과, 문제를 세 번 묻는 것은 다른가요? 브레인스토밍 기능을 만든다면, 자기기만이 아니게 어떻게 보장하나요?」
🎯 무엇을 평가하는가
브레인스토밍 모드의 핵심 메커니즘을 아는지 봅니다. 잘못하면 Agent 셋이 서로 맞장구만 쳐서, 한 번 물은 것과 산출이 같고 돈만 세 배가 됩니다.
🧭 답변 프레임워크
- 먼저 메커니즘부터: 같은 문제를 여러 Agent에게 던져, 각자 다른 역할에서 독립적으로 답하게 합니다. 예를 들어 제품 관점, 데이터 관점, 사용자 관점. 마지막에 사회자 Agent가 통합합니다.
- 철칙을 짚으세요: 각 Agent는 독립적으로 생각해야 하고, 남의 답을 보면 안 됩니다. 사람이 브레인스토밍할 때 「먼저 각자 쓰고, 그다음 같이 토론」하는 것과 같은 이치입니다. B가 A의 답을 보면 끌려가고, 브레인스토밍은 끝입니다. 이것이 세 번 묻는 것과 본질적으로 다른 점입니다. 세 번 묻는 것은 같은 컨텍스트에서 세 번 샘플링하는 것이고, 관점은 안 바뀝니다.
- 산출물을 말하세요: 사회자가 모으는 것은 합의만이 아니라 분기도 표시해야 합니다. 셋이 같으면 방향이 분명한 것이고, 분기가 있으면 더 깊게 토론할 가치가 있는 문제입니다. 분기 자체가 가치입니다.
- 효율 장부를 보완: 사고형 태스크는 원래 병렬이 됩니다. Agent 셋이 동시에 생각하면 총 소요는 가장 느린 것과 같습니다. 시간은 세 배가 안 되고 돈은 됩니다. 그래서 다관점이 필요한 문제에만 쓰세요.
⭐ 가산점 역할 설정이 제품 일이라고 짚으세요: 세 Agent에게 각각 어떤 페르소나를 쓰느냐가 관점 차이의 질을 결정합니다. 「몇 개 더 돌리기」보다 훨씬 중요합니다.
Q24상사
「AI가 한 시간마다 여론을 정리하게 했더니 기능은 좋은데, 이 항목 비용이 하루하루 높아지고 월말 청구서가 저를 놀래켰습니다. 어떻게 된 일인가요?」
🎯 무엇을 평가하는가
「하루하루 높아진다」가 핵심 단서입니다. 스케줄 태스크가 세션을 재사용하며 만드는 비용 눈덩이를 가리킵니다. 청구서 모양에서 구현 문제를 거꾸로 짚고, 바로 효과가 나는 고치는 법을 줘야 합니다.
🧭 답변 프레임워크
- 뿌리를 말하세요: 스케줄 태스크가 옛 세션을 재사용해, 컨텍스트가 매번 쌓입니다. 1회는 약 2000 토큰, 10회는 약 2만, 24회는 약 4.8만. 요청마다 전체 히스토리에 돈을 내니 청구서가 날마다 오릅니다.
- 고치는 법: 실행마다 새 세션을 만들어 제로에서 시작합니다. 24회의 비용이 1회와 똑같습니다. 강좌 대비로, 7일 동안 하루 24회면 세션 재사용은 약 50달러, 새 세션은 약 5달러, 10배 차이입니다.
- 왜 이렇게 바꿔도 되는지: 대부분의 스케줄 태스크는 기억이 필요 없습니다. 지금 여론을 정리하면 되고, 어제 무엇을 정리했는지는 몰라도 됩니다. 정말 이어가야 할 정보는 요약을 외부에 두고 다음에 가져오면 되지, 전체 히스토리를 끌면 안 됩니다.
⭐ 가산점 상사에게 점검 습관 하나를 주세요: 비용 곡선이 시간에 따라 위로 휘는 AI 기능은, 먼저 컨텍스트가 쌓이는지 보세요. 이 패턴은 한눈에 알아봅니다.
Q25면접관
「제품 속 AI의 권한은 어떻게 정하나요? 모든 기능이 한 기준인가요, 따로 정하나요? 근거는 무엇인가요?」
🎯 무엇을 평가하는가
권한을 스위치가 아니라 스펙트럼으로 설계하는지 봅니다. 「전부 확인받습니다」나 「AI를 믿습니다」라고 답하는 사람은 아직 입문 전입니다.
🧭 답변 프레임워크
- 먼저 스펙트럼 관점: 완전 자율부터 매 단계 승인까지가 스펙트럼이고, 가운데에도 여러 칸이 있습니다. 전부 맡기면 AI가 모든 것을 망가뜨릴 수 있고, 매 단계 승인이면 사용자가 미칩니다. 제품이 할 일은 조작 유형마다 스펙트럼 위 위치를 찾는 것입니다.
- 위치 잡는 차원 세 가지: 조작의 가역성, 메시지 발송은 되돌릴 수 없고 파일 읽기는 되돌릴 수 있습니다. 실수 대가, 데이터 삭제는 높고 검색은 낮습니다. 사용자 신뢰, 신규는 신중하고 오래된 사용자는 권한을 더 줍니다.
- 나누느냐에 답하세요: 같은 제품 안에서도 기능마다 권한 모드가 다릅니다. 캘린더 읽기는 자동 실행, 메일 발송은 확인. 이것이 정상 형태이고, 한칼로 자르는 것이 게으름입니다.
- 본질로: AI에게 얼마나 자유를 줄지는, 본질적으로 제품 질문 하나에 답하는 것입니다: 이 일이 잘못되면, 누가 책임지나?
⭐ 가산점 동적인 면을 한 줄: 권한 위치는 신뢰와 함께 진화할 수 있습니다. 세 달 쓰고 백 번 확인해도 사고가 없었으면, 「이런 종류는 앞으로 묻지 마세요」 옵션을 줄 수 있습니다.
Q26면접관
「사용자가 확인 팝업이 너무 많다고 해서 줄였더니, 이번엔 오삭제 사고가 났습니다. 팝업의 이 수위, 어떻게 잡나요?」
🎯 무엇을 평가하는가
위험 등급으로 「띄울까 말까」 이분법을 빠져나올 수 있는지 봅니다. Agent 제품에서 가장 흔한 경험 대 안전 충돌이고, 거의 모든 면접이 껍데기만 바꿔 한 번씩 묻습니다.
🧭 답변 프레임워크
- 문제를 깨세요: 문제는 등급이 없는 것입니다. 매 단계 띄우면 사용자가 허용을 5번 누르고 삭제하고 싶어집니다. 전부 안 띄우면 파일을 잘못 지워도 받아 줄 사람이 없습니다. 답은 저위험은 자동 실행, 고위험은 반드시 확인입니다.
- 등급 선을 주세요: 파일 읽기, 검색, 캘린더 조회처럼 상태를 바꾸지 않는 조작은 팝업 없음. 파일 삭제, 메시지 발송, 결제, 권한 변경처럼 되돌릴 수 없거나 영향이 큰 조작은 반드시 확인.
- 누가 등급을 정하는지: 선택지 셋. PM이 설계 단계에서 도구마다 위험 등급을 미리 정하는 것이 가장 흔합니다. AI가 컨텍스트를 보고 사람에게 물을지 판단하는 것은 더 유연하지만 정확하지 않을 수 있습니다. 사용자 커스텀은 가장 유연하지만 설정 비용이 있습니다. 조합해서 쓰고, 바닥 칸은 언제나 사람이 정합니다.
- 한 층 올리세요: 좋은 권한 설계는 팝업을 띄울지 말지의 이분법이 아니라, 언제 띄우고 무엇을 띄울지에 대한 세밀한 통제입니다.
⭐ 가산점 팝업 문구도 등급의 일부라고 언급하세요: 고위험 팝업은 이 조작이 되돌릴 수 없고 무엇을 건드리는지 말해, 사용자가 정보에 입각한 결정을 하게 해야 합니다. 짜증 나는 상자를 닫는 것은 거기에 해당하지 않습니다.
Q27상사
「사용자가 Agent가 백그라운드에서 3분을 돌고 나서야 결과가 나왔다고 합니다. 그 3분 동안 도대체 무엇을 했는지, 저에게 분명히 말해 줄 수 있나요?」
🎯 무엇을 평가하는가
상사는 한 번 묻지만, 뒤에 원하는 것은 이런 질문을 언제든 답할 수 있는 능력입니다. 답하지 못하면 제품이 블랙박스이고, 블랙박스는 비용을 최적화하거나 장애를 찾거나 경험을 개선할 수 없습니다.
🧭 답변 프레임워크
- 정직하게 성격을 정하세요: 오늘 정확히 답하지 못한다면 관측 가능성이 없는 것입니다. 이 3분에 도구를 몇 개 불렀는지, 루프를 몇 바퀴 돌았는지, 토큰을 얼마나 썼는지, 중간에 오류가 있었는지를 말하려면 이벤트 스트림과 실행 보고서가 필요하고, 짐작이 아닙니다.
- 무엇을 지을지: Agent에 대시보드를 달으세요. 실행 타임라인, 도구 호출 통계, 토큰 소비 분포, 태스크마다 실행 보고서 한 장.
- 양쪽 가치를 말하세요: 개발에게는 어느 단계에서 문제가 났는지, 무효 루프와 낭비 토큰을 찾게 합니다. 제품에게는 사용자의 실제 사용 경로를 이해하고, 기능마다 비용을 수치화하고, 다음 이터레이션에 데이터를 줍니다.
- 비유: 대시보드 없는 Agent는 계기판 없는 차와 같습니다. 기름도, 회전수도, 언제 설지도 모릅니다. 제품화의 기본기이지, 있으면 좋은 것이 아닙니다.
⭐ 가산점 이번 불만을 프로젝트 착수 이유로 바꾸세요: 이 3분 중 무효 루프가 30초뿐이어도, 호출량을 곱하면 진짜 청구서입니다. 관측 가능성 구축 비용은 스스로 벌어 돌아옵니다.
Q28기술 동료
「제품이 MCP 서비스 10개를 붙어야 해서, 시작 때 전부 한 바퀴 연결해 두고 언제든 쓰게 할 생각이었습니다. 요즘 사용자가 시작이 느려졌다고 하는데, 이거랑 관련 있나요?」
🎯 무엇을 평가하는가
지연 연결이라는 설계를 아는지, 그리고 「전부 한 바퀴」가 가용성에 남기는 위험을 볼 수 있는지 봅니다. 시작이 느린 것은 표면이고, 진짜 문제는 장애가 전염된다는 것입니다.
🧭 답변 프레임워크
- 먼저 인과를 확인: 서비스 10개를 시작 때 전부 연결하면, 몇 개만 타임아웃되어도 시작이 끌려갑니다. 강좌의 실제 데이터로, 시작 때 전량 연결은 30초, 지연 연결로 바꾸면 0.2초. 사용자 체감은 즉시 열림입니다.
- 원칙 세 가지: 등록은 연결이 아닙니다. 시작 때는 어떤 도구가 있는지만 선언하고 네트워크 연결은 만들지 않습니다. 처음 쓸 때 비로소 연결하고, 대부분의 도구는 하루 종일 안 쓸 수 있습니다. 장애 격리. 어떤 서비스가 죽어도 그 도구 하나만 영향받고 나머지는 그대로입니다.
- 제품 함의: 이것은 기술 최적화만이 아니라 안정성의 기본 설계입니다. 전량 연결 모드에서는 서드파티 서비스 하나만 문제가 나도 제품 전체가 끌려갑니다. 지연 연결은 폭발 반경을 도구 하나에 가둡니다.
⭐ 가산점 경험 디테일 하나: 연결되지 않는 도구는 사용자가 정말 쓸 때 분명한 안내와 재시도 입구를 주고, 시작 때 실패를 모든 사용자에게 펼쳐 보이지 마세요.
Q29상사
「데모를 봤는데, 사용자가 캘린더 좀 봐 달라고 하니 AI가 캘린더 도구가 없는 것을 알고 스스로 하나를 설치했습니다. 너무 똑똑한데요. 우리도 할 수 있나요? 위험은 없나요?」
🎯 무엇을 평가하는가
상사는 반은 흥분, 반은 걱정입니다. 양쪽을 다 받아야 합니다: 자체 설정의 메커니즘과 반드시 같이 가야 하는 안전 설계 네 가지를 말하고, 찬물을 끼얹지도, 무작정 추켜세우지도 마세요.
🧭 답변 프레임워크
- 먼저 메커니즘부터: 전통적인 방법은 지원하지 않는다고 에러를 내는 것입니다. 사용자는 설정 페이지에서 MCP 항목을 찾고 파라미터를 채우고 연결을 테스트해야 하고, 대부분은 아예 못 합니다. 자체 설정은 Agent가 필요에 맞는 후보 도구를 고르고, 사용자에게 한 번 물어 동의를 받은 뒤 설정을 자동으로 끝냅니다. 허들이 「설정할 줄 아는 것」에서 「말할 줄 아는 것」으로 내려갑니다.
- 안전 설계 네 가지: 능력 발견. Agent는 도구 레지스트리 또는 미리 정한 후보 목록에서만 고르고, 출처 불명은 설치하지 않습니다. 사용자 인가. 어떤 서비스에 연결할지 반드시 알리고 명시적 동의를 기다립니다. AI가 몰래 연결하면 안 됩니다. 이것이 신뢰의 바닥입니다. 즉시 반영. 설정이 끝나면 핫 로드되어 현재 대화가 끊기지 않습니다. 안전 경계. 데이터베이스 같은 민감 도구는 관리자가 수동으로 설정해야 하고, 자체 설정 범위에 넣지 않습니다.
- 결론: 할 수 있고, 할 가치가 있습니다. 자체 설정은 AI가 플러그인을 마음대로 깔게 하는 것이 아니라, 복잡한 설정 과정을 자동화하고 결정권은 사용자에게 남기는 것입니다.
⭐ 가산점 상사에게 한 줄: 최고의 도구 관리는 AI가 자기 도구함을 스스로 관리하는 것이지만, 사용자가 고개를 끄덕여야 합니다. 위험에 대한 답이 그 뒷문장에 있습니다.
Q30상사
「경쟁사가 2주 만에 AI 어시스턴트를 올렸는데, 우리는 두 달이 지나도 출시를 못 했습니다. 그들도 모델 하나 붙이고 채팅창 하나 넣은 것 아닌가요. 우리는 어디서 느린 건가요?」
🎯 무엇을 평가하는가
상사가 껍데기의 속도로 제품화의 가치를 압박하고 있습니다. 못 답하면 효율이 낮은 것이고, 잘 답하면 이번이 장 전체를 상사에게 묶어 말할 기회입니다.
🧭 답변 프레임워크
- 먼저 표면을 인정: 모델 하나와 채팅창은 정말 2주면 올릴 수 있습니다. 사용자가 보는 것은 빙산의 수면 위 한 귀퉁이, 채팅 UI와 똑똑한 답입니다.
- 그다음 수면 아래: 루프에 갇히면 어떻게 멈출지, 컨텍스트를 어떻게 누를지, 사용자 말을 지워도 되는지, 기억을 어떻게 걸러 낼지, 권한을 어떻게 등급 나눌지, Agent가 한 일을 볼 수 있는지, 서드파티 서비스가 죽으면 어떻게 할지. 이것이 수면 아래의 제품 결정이고, 껍데기 제품은 하나도 하지 않았습니다.
- 격차의 척도를 주세요: 채팅 껍데기와 진짜 Agent 제품 사이에 있는 것은, 사용자가 보지 못하는 곳에서 옳게 내린 제품 결정 수백 개입니다. 같은 Loop가 N가지 시나리오를 받치는 것이고, 차이는 코드가 아니라 결정입니다.
- 시간을 위험으로 바꾸세요: 경쟁사가 아낀 두 달은 출시 뒤에 루프 정지, 청구서 폭주, 오삭제 사고로 한 건씩 갚아집니다. 범위를 잘라 핵심 시나리오를 먼저 올릴 수는 있지만, 수면 아래의 바닥 결정은 아낄 수 없습니다.
⭐ 가산점 절충안을 먼저 내세요: 출시 전에 반드시 끝내야 하는 결정(안전, 비용, 안전망)과 출시 후 이터레이션할 수 있는 것(기억, 멀티 Agent)을 나눠, 「느림」을 우선순위 있는 체크리스트로 바꾸세요.
마지막 조언 하나
30가지 질문의 공통 밑바탕은 계산과 안전망입니다: 루프가 발생하면 어떻게 멈출지, 컨텍스트를 어떻게 압축할지, 청구서를 어떻게 통제할지. 이것들을 유창하게 설명할 수 있다면 Demo에서 제품까지의 길을 진정으로 걸어온 것입니다. 유창하게 설명하지 못하는 부분은 연결된 강좌 페이지를 클릭해 보완하세요.