이렇게 시험할 것입니다

AI 엔지니어링 디자인 패턴 · 7가지 핵심 질문

4장은 전부 프로덕션 수준의 Agent 엔지니어링 판단에 관한 것입니다. 이런 질문은 면접과 설계 리뷰에서 점점 자주 등장하고 있습니다. 먼저 직접 말로 답해보고, 그다음 프레임워크를 확인하세요.

이 페이지 활용법
각 문제에는 질문자가 표시되어 있습니다. 이 챕터는 엔지니어링에 치우쳐 있어 기술 동료의 비중이 더 큽니다. 그들의 질문이 가장 가혹합니다.
🎙 면접관진짜 이해했는지, 아니면 용어만 외웠는지 확인하려 합니다
👔 상사설명과 확약을 원합니다
🛠 기술 동료당신을 신뢰할 만한지 가늠하고 있습니다
각 문제는 세 층으로 구성됩니다: 상대방이 평가하는 것 → 답변 프레임워크 → 가점 포인트. 답하기 어려운 부분은 하단 강좌 페이지를 클릭하여 보완하세요.
Q1면접관
「모두가 컨텍스트 엔지니어링을 이야기합니다. Prompt를 잘 쓰는 것과 정확히 어떻게 다른가요? 왜 Prompt 엔지니어링이 갑자기 구식이 됐나요?」
🎯 상대방이 평가하는 것
이 챕터의 도입 개념 문제로, 단일 대화에서 다단계 Agent로의 패러다임 전환을 이해하고 있는지 확인합니다. "컨텍스트 엔지니어링은 범위가 더 넓다"라고만 말하는 사람은 정의를 암기한 것입니다. 진짜 이해한 사람은 창에 구체적으로 무엇이 있고, 왜 관리해야 하는지를 설명할 수 있습니다.
🧭 답변 프레임워크
  1. 먼저 정의부터: Prompt 엔지니어링은 지시문 작성 방식을 최적화합니다. 컨텍스트 엔지니어링은 각 추론 단계에서 모델에 전달되는 모든 Token을 관리합니다: System Prompt, 도구 정의, 대화 기록, 검색 결과, 사용자 상태 — 모두 포함됩니다.
  2. 동기를 설명하세요: 컨텍스트는 희소 자원입니다. 세 가지 제약: Context Rot(길수록 검색 정확도 저하), 제한된 어텐션 예산(무관한 Token이 유용한 정보를 희석), n제곱 복잡도(컨텍스트가 두 배가 되면 어텐션 계산량은 네 배가 됩니다).
  3. 목표를 제시하세요: 최소 고신호 Token 집합을 찾는 것입니다. 모든 Token이 추론에 기여해야 하며, "최대한 많이 넣자"는 접근은 통하지 않습니다.
  4. 세 가지 실천 방법: System Prompt는 적절한 수준으로(역할+원칙, 규칙 50개 쌓지 말 것), 도구 세트는 간결하게, Few-shot은 대표적인 2~3개 예시만 선별 — 엣지 케이스로 채우지 마세요.
⭐ 가점 포인트 n제곱 비용을 언급할 수 있으면 좋습니다: 컨텍스트가 50K에서 100K로 늘어나면 어텐션 계산량은 네 배가 됩니다. 많은 사람들이 길면 비싸다는 것만 압니다. 길어지면 더 멍청해진다고 말할 수 있는 사람은 드뭅니다.
이 강좌 페이지로 답변을 구성하세요 → Prompt 엔지니어링에서 컨텍스트 엔지니어링으로 컨텍스트의 세 가지 핵심 기법
Q2면접관
「Agent이 수십 단계의 장기 태스크를 실행해야 합니다. 컨텍스트 창이 거의 다 찼을 때 어떻게 하나요? 새 세션을 열어서 계속 실행하면 안 되나요?」
🎯 상대방이 평가하는 것
장기 태스크의 근본적 딜레마를 이해하는지 확인합니다. "새 세션을 열면 된다"고 답하는 사람은 새 창이 아무것도 기억하지 못한다는 것을 모릅니다. "더 큰 컨텍스트 창 모델로 교체하면 된다"고 답하는 사람은 어텐션 희석 비용을 계산해본 적이 없습니다. 이 질문은 프로덕션 시스템을 경험한 사람과 데모만 해본 사람을 바로 구분합니다.
🧭 답변 프레임워크
  1. 먼저 딜레마를 제시하세요: 새 창을 열면 Agent는 기억을 잃고 이미 한 작업을 반복합니다. 기존 창에 머물면 Token이 쌓이고 어텐션이 희석되어 성능이 계속 저하됩니다. Claude Code, Cursor, Devin이 매일 이 문제를 해결합니다.
  2. 기법 1 — Compaction: 창이 거의 찼을 때 LLM 호출 한 번으로 구조화된 요약을 생성합니다. 아키텍처 결정과 미해결 버그는 유지하고, 중복 도구 출력과 완료된 태스크의 중간 단계는 버립니다. 잘못 선택하면 Agent가 같은 실수를 반복합니다.
  3. 기법 2 — 구조화 메모: 핵심 정보를 외부 파일에 능동적으로 작성하고, 새 창이 읽어서 기억을 복원합니다. Claude Code의 TODO 파일과 포켓몬을 플레이할 때 Claude가 유지하는 게임 메모가 모두 이 방식입니다.
  4. 기법 3 — 서브 Agent: 깊은 탐색을 위임합니다. 서브 Agent는 자체 창에서 30K Token을 소모해 코드를 읽고 추론한 뒤, 메인 Agent에 1,500 Token의 결론만 반환합니다. 메인 컨텍스트는 항상 깔끔하게 유지됩니다.
⭐ 가점 포인트 세 기법의 역할을 각각 설명할 수 있으면 좋습니다: 창 내부 간결 유지, 창 간 기억 전달, 탐색 노이즈 격리. 그리고 실제 제품에서는 세 가지를 함께 사용한다고 덧붙이세요. 이는 개별 용어가 아닌 시스템 전체를 이해하고 있음을 보여줍니다.
이 강좌 페이지로 답변을 구성하세요 → 컨텍스트의 세 가지 핵심 기법 Agent가 장기 태스크를 처리하지 못하는 이유 Session ≠ Context Window
Q3기술 동료
「제품에 코드베이스 Q&A를 추가해야 합니다. 또 벡터 스토어 구축 프로젝트를 시작하려는 건 아니죠? Claude Code는 전부 grep으로 즉시 검색합니다.」
🎯 상대방이 평가하는 것
RAG를 기본 답으로 생각하는지 탐색하는 질문입니다. 바로 청킹, 벡터화, 인덱스 구축을 말하는 PM은 기술 동료 눈에 망치를 든 사람처럼 보입니다. 상대방은 먼저 방안을 비교하고 인덱스 유지보수 비용을 계산해주기를 원합니다.
🧭 답변 프레임워크
  1. 먼저 인정하세요: 목표는 올바른 정보를 컨텍스트 창에 넣는 것이며, RAG는 방법 중 하나일 뿐입니다. 코드베이스처럼 자주 변경되는 데이터에는 필요할 때 검색하는 방식이 더 적합합니다.
  2. JIT 검색을 설명하세요: glob/grep으로 필요할 때 즉시 검색하여 컨텍스트를 간결하게 유지하고, 현재 필요한 내용만 포함합니다. 비용은 도구 호출 지연 한 번이고, 대신 인덱스 구축과 동기화의 유지보수 부담이 없습니다.
  3. 혼합 전략을 제시하세요: 고빈도 정보는 사전 로드(프로젝트 규칙, 핵심 규칙, 사용자 선호), 롱테일 정보는 필요 시 가져옵니다. 브라우저 캐시에 비유하면: 핫 데이터는 메모리에, 콜드 데이터는 요청 시 가져옵니다.
  4. RAG가 적합한 시점을 명확히 하세요: 상대적으로 정적인 지식베이스 시나리오에 RAG가 적합하지만, 단순 청킹은 컨텍스트를 잃습니다. Contextual Retrieval은 각 Chunk에 컨텍스트 접두사를 추가하고, BM25 이중 경로 검색과 Reranking을 결합하여 검색 실패율을 67% 낮출 수 있습니다.
⭐ 가점 포인트 Contextual Retrieval 비용을 능동적으로 계산하세요: Chunk마다 접두사 생성에 LLM 호출 한 번 추가, Prompt Caching으로 낮출 수 있습니다. 법률, 의료, 금융처럼 높은 정확도가 필요한 시나리오에만 가치 있고, 일반 채팅 추천에는 불필요합니다.
이 강좌 페이지로 답변을 구성하세요 → JIT Context vs 사전 로드 Contextual Retrieval: 더 나은 RAG
Q4면접관
「프로덕션 Agent가 계속 잘못된 도구를 선택하고 파라미터를 잘못 입력합니다. 엔지니어들은 모델이 부족하다며 다음 세대를 기다리라고 합니다. PM으로서 어떻게 생각하시나요?」
🎯 상대방이 평가하는 것
ACI에 대해 알고 있는지 확인합니다. "모델 업그레이드를 기다리자"에 동의하는 사람은 바로 탈락입니다. 상대방은 이런 말을 듣고 싶어합니다: 도구 정의가 Agent의 사용자 인터페이스이며, 잘못된 도구 선택은 대부분 설계 문제이고, PM에게는 명확한 진단 체크리스트가 있다는 것입니다.
🧭 답변 프레임워크
  1. 프레임 설정: 도구의 이름, 파라미터, 설명이 Agent의 사용자 인터페이스입니다. 전통적인 API는 결정론적이지만 Agent 도구는 비결정론적이며, 언제 어떻게 사용하는지는 전적으로 설계 품질에 달려 있습니다. 도구 설계에는 HCI 설계와 같은 수준의 투자가 필요합니다.
  2. 진단 체크리스트 제시: 네 가지 원칙을 하나씩 확인합니다. 파라미터 순서가 모델에 사고 공간을 주나요(간단한 방향 먼저, 복잡한 내용 나중)? 형식이 학습 데이터에 가깝나요(표준 unified diff가 커스텀 DSL보다 낫습니다)? 모델이 기계적으로 줄 번호를 세도록 강제하고 있나요? 실수 방지 설계(Poka-yoke)가 있나요?
  3. 구체적인 사례 제시: SWE-bench에서 파일 경로 파라미터를 상대 경로에서 절대 경로만 받도록 변경한 것이 파라미터 하나의 변경으로, 도구 호출이 빈번한 오류에서 거의 완벽하게 바뀌었습니다.
  4. 설명 기준을 제시하세요: 컨텍스트가 없는 똑똑한 주니어 개발자를 위한 문서를 쓰듯이 작성합니다. 사용 예시, 엣지 케이스, 입력 형식, 다른 도구와의 차이, 사용하지 않아야 할 때 — 다섯 가지를 모두 포함하세요.
⭐ 가점 포인트 "사람도 어떤 도구를 써야 할지 모르면 AI도 모른다"고 덧붙이세요. 그리고 Claude Code의 고급 방식을 언급하세요: Agent를 사용하여 자체 도구의 설명을 작성하고, 평가를 실행하고, 자동으로 반복 최적화합니다.
이 강좌 페이지로 답변을 구성하세요 → ACI: Agent-Computer Interface Agent를 사용하여 Agent의 도구 최적화하기 도구 세트는 간결하게
Q5상사
「새 모델이 출시된 지 일주일이 됐습니다. 경쟁사는 출시 다음날 도입을 발표했습니다. 우리는 평가에 3주가 필요하다고요? 시간이 어디에 쓰이는지 설명해보세요.」
🎯 상대방이 평가하는 것
표면적으로는 진행을 독촉하지만, 실제로는 팀에 평가 인프라가 있는지 묻는 것입니다. 이는 수동적인 비난을 자원 요청의 기회로 바꿀 수 있는 질문입니다. "기술 일정이 원래 이래요"라고 답하면 무능을 인정하는 것입니다. "내일 당장 교체하겠습니다"라고 답하면 제품 품질로 도박을 하는 것입니다.
🧭 답변 프레임워크
  1. 결론부터 제시하세요: 마이그레이션 속도는 평가 인프라에 달려 있습니다. 완성된 eval suite가 있는 팀은 테스트를 실행하고, 회귀 없음을 확인하고, 며칠 만에 전환을 완료합니다. 없는 팀은 몇 주 동안 수동으로 검증할 수밖에 없습니다. 우리가 느린 이유는 인프라 부채입니다.
  2. 평가가 가져다주는 가치를 설명하세요: Prompt 변경, 모델 교체, 파라미터 조정 — 몇 분 안에 전체 영향을 파악합니다. 버그 하나를 수정하면서 세 개를 만드는 것을 방지합니다. 새 모델이 출시될 때마다 가장 먼저 혜택을 받습니다.
  3. 시작 계획을 제시하세요: 핵심 시나리오를 커버하는 20개의 테스트 케이스로 시작할 수 있습니다. 잘 설계된 20개의 케이스가 계획서에만 있는 500개보다 한 세대 앞섭니다.
  4. 기대치를 관리하세요: 경쟁사가 빨리 통합한다고 해서 엄격하게 테스트한다는 뜻은 아닙니다. 공개 벤치마크 점수는 과대평가됩니다(모델이 시험을 인식합니다) — 자체 비즈니스 시나리오 케이스를 사용하세요. 평가 환경은 프로덕션과 일치해야 하며, 샌드박스 구성 차이만으로도 6%의 오차가 발생할 수 있습니다.
⭐ 가점 포인트 보고서에서 형용사를 지표 언어로 교체하세요: "나빠진 것 같다"를 "간결성이 72에서 85로 향상됐지만 과잉 엔지니어링이 3%에서 7%로 악화됨 — 롤백 필요"로 업그레이드하세요. 상사의 신뢰가 한 단계 높아집니다.
이 강좌 페이지로 답변을 구성하세요 → 평가가 훈련보다 중요한 이유 평가의 함정: 노이즈, 치팅, 회귀
Q6면접관
「Agent 출력 품질을 어떻게 자동으로 채점하나요? LLM-as-Judge에만 의존하면 신뢰할 수 있나요?」
🎯 상대방이 평가하는 것
평가 툴박스의 숙련도를 확인합니다. "LLM으로 채점한다"고만 답하는 사람은 들어본 정도입니다. 세 가지 Grader의 경계와 조합 방식을 명확히 설명할 수 있는 사람은 실제로 평가를 해본 것처럼 들립니다.
🧭 답변 프레임워크
  1. 세 가지 Grader 유형을 모두 나열하세요: 코드 Grader(어서션, 단위 테스트, 정규식 — 밀리초 단위, 비용 제로, 완전 재현 가능, 단 합리적인 변형에는 너무 엄격함), 모델 Grader(주관적 품질 평가 가능, 단 비용과 편향이 있음), 사람 Grader(품질 최고, 단 확장 불가).
  2. LLM-as-Judge에 직접 답하세요: 신뢰도는 전적으로 Rubric에 달려 있습니다. "품질을 0~1점으로 채점하라"는 거의 쓸모없습니다. 각 점수 수준에서 구체적이어야 합니다: 0점은 어떤 모습인지, 0.3점에서 무엇이 부족한지, 1점을 받으려면 어떤 조건이 모두 충족되어야 하는지.
  3. 조합 방법을 제시하세요: 코드 Grader를 기반으로 결정론적 시나리오를 다루고, 모델 Grader로 주관적 품질까지 확장하며, 사람이 주기적으로 샘플링하여 모델 Grader의 드리프트를 교정합니다. 세 레이어 모두 필수입니다.
  4. 자주 놓치는 포인트를 추가하세요: 평가해야 할 것은 Outcome — 환경의 최종 상태입니다. Agent가 완료했다고 말하는 것으로는 부족합니다. 파일이 실제로 올바르게 변경됐는지, API가 실제로 올바르게 호출됐는지 확인해야 합니다.
⭐ 가점 포인트 Trial 개념을 언급하세요: 모델 출력은 확률적이므로 동일한 Task를 여러 번 실행해야 통계적 의미가 있습니다. 그리고 Descript의 3차원 채점(망가뜨리지 않음, 요구한 것을 수행함, 잘 수행함)을 인용하면 실제 사례를 접해봤다는 인상을 줍니다.
이 강좌 페이지로 답변을 구성하세요 → 세 가지 Grader 유형: 코드, 모델, 사람 평가의 핵심 개념
Q7기술 동료
「이 요구사항은 Agent가 사용자의 GitHub Token을 사용하여 모델이 생성한 코드를 실행하게 합니다. 문제가 생기면 누가 책임지나요? '위험한 작업은 실행하지 마세요'라는 Prompt 한 줄로는 납득할 수 없습니다.」
🎯 상대방이 평가하는 것
보안 리뷰에서의 전형적인 대립으로, 구조적 보안을 이해하는지 확인합니다. 답변에 "Prompt에 제약을 추가하겠다"나 "모델이 거부할 것이다"만 있다면 이 요구사항은 즉시 거부됩니다. 상대방은 방어선이 아키텍처에 구축되어야 한다는 것을 알고 있는지 확인하고 싶어합니다.
🧭 답변 프레임워크
  1. 먼저 상대방 입장에 동의하세요: Prompt 기반 방어는 신뢰할 수 없고, 보안은 구조적 설계에 의존해야 합니다. 목표는 모델이 Prompt Injection에 완전히 조작되더라도 공격자가 자격증명을 얻을 수 없도록 하는 것입니다.
  2. 위험을 분류하세요: 세 가지 카테고리, 각각 별도로 방어: 사용자의 의도적 남용, 모델의 자발적 통제 상실(과도한 행동, 환각을 기반으로 실제 작업 실행), 외부 공격(사용자도 모르는 웹 페이지와 문서에 삽입된 주입 명령).
  3. 자격증명 솔루션을 제시하세요: 첫 번째 원칙은 생성된 코드와 시크릿을 항상 서로 다른 컨테이너에 격리하는 것입니다. 두 가지 모드: Token을 리소스 접근 경로에 주입(Agent가 사용할 수 있지만 볼 수 없음 — 예: Git remote URL에 삽입), Vault 프록시 전달(프록시가 세션별로 Token을 주입하고 Agent는 단 한 글자도 볼 수 없음).
  4. 실행 환경 솔루션을 제시하세요: OS 수준 샌드박스로 3중 격리(파일 시스템, 네트워크, 프로세스), 3단계 신뢰 제어 추가: 고위험 도구에 대한 수동 승인, 세션 수준 인가, 전역 정책 최종 안전망(프로덕션 데이터베이스는 절대 접근 불가).
⭐ 가점 포인트 "모델이 강력할수록 기존 아키텍처에서 공격 표면이 커진다"고 능동적으로 말하세요. 따라서 보안 설계는 모델 업그레이드로 자동으로 개선되기를 기대할 수 없습니다. 이 말 한마디가 보안 엔지니어가 당신을 동료로 보게 만듭니다.
이 강좌 페이지로 답변을 구성하세요 → 세 가지 위험 유형: 남용, 통제 상실, 외부 공격 샌드박스와 자격증명 격리
마지막 조언
이 챕터의 질문들은 대부분 실제 기술 설계 리뷰 현장에서 나온 것으로, 언제나 원하는 것은 판단력과 절충점입니다. 올바른 활용법은 여전히 소리 내어 한 번 말해보는 것입니다 — 동료, 친구, 또는 녹음기에 대고 말해보세요. 막히는 부분이 바로 안다고 생각했지만 실제로는 모르는 곳입니다. 관련 강좌 페이지를 클릭하여 보완하세요.