이렇게 당신을 테스트합니다
AI 엔지니어링 디자인 패턴 · 30가지 핵심 질문
4장은 전부 프로덕션 수준의 Agent 엔지니어링 판단에 관한 것입니다. 이런 질문은 면접과 설계 리뷰에서 점점 자주 등장하고 있습니다. 먼저 직접 말로 답해보고, 그다음 프레임워크를 확인하세요.
이 페이지 활용법
각 문제에는 질문자가 표시되어 있습니다. 이 챕터는 엔지니어링에 치우쳐 있어 기술 동료의 비중이 더 큽니다. 그들의 질문이 가장 가혹합니다.
🎙 면접관진짜 이해했는지, 아니면 용어만 외웠는지 확인하려 합니다
👔 상사설명과 확약을 원합니다
🛠 기술 동료당신을 신뢰할 만한지 가늠하고 있습니다
각 문제는 세 층으로 구성됩니다: 상대방이 평가하는 것 → 답변 프레임워크 → 가점 포인트. 답하기 어려운 부분은 하단 강좌 페이지를 클릭하여 보완하세요.
Q1면접관
「모두가 컨텍스트 엔지니어링을 이야기합니다. Prompt를 잘 쓰는 것과 정확히 어떻게 다른가요? 왜 Prompt 엔지니어링이 갑자기 구식이 됐나요?」
🎯 무엇을 평가하는가
이 챕터의 도입 개념 문제로, 단일 대화에서 다단계 Agent로의 패러다임 전환을 이해하고 있는지 확인합니다. "컨텍스트 엔지니어링은 범위가 더 넓다"라고만 말하는 사람은 정의를 암기한 것입니다. 진짜 이해한 사람은 창에 구체적으로 무엇이 있고, 왜 관리해야 하는지를 설명할 수 있습니다.
🧭 답변 프레임워크
- 먼저 정의부터: Prompt 엔지니어링은 지시문 작성 방식을 최적화합니다. 컨텍스트 엔지니어링은 각 추론 단계에서 모델에 전달되는 모든 Token을 관리합니다: System Prompt, 도구 정의, 대화 기록, 검색 결과, 사용자 상태 — 모두 포함됩니다.
- 동기를 설명하세요: 컨텍스트는 희소 자원입니다. 세 가지 제약: Context Rot(길수록 검색 정확도 저하), 제한된 어텐션 예산(무관한 Token이 유용한 정보를 희석), n제곱 복잡도(컨텍스트가 두 배가 되면 어텐션 계산량은 네 배가 됩니다).
- 목표를 제시하세요: 최소 고신호 Token 집합을 찾는 것입니다. 모든 Token이 추론에 기여해야 하며, "최대한 많이 넣자"는 접근은 통하지 않습니다.
- 세 가지 실천 방법: System Prompt는 적절한 수준으로(역할+원칙, 규칙 50개 쌓지 말 것), 도구 세트는 간결하게, Few-shot은 대표적인 2~3개 예시만 선별 — 엣지 케이스로 채우지 마세요.
⭐ 가산점 n제곱 비용을 언급할 수 있으면 좋습니다: 컨텍스트가 50K에서 100K로 늘어나면 어텐션 계산량은 네 배가 됩니다. 많은 사람들이 길면 비싸다는 것만 압니다. 길어지면 더 멍청해진다고 말할 수 있는 사람은 드뭅니다.
Q2면접관
「Agent이 수십 단계의 장기 태스크를 실행해야 합니다. 컨텍스트 창이 거의 다 찼을 때 어떻게 하나요? 새 세션을 열어서 계속 실행하면 안 되나요?」
🎯 무엇을 평가하는가
장기 태스크의 근본적 딜레마를 이해하는지 확인합니다. "새 세션을 열면 된다"고 답하는 사람은 새 창이 아무것도 기억하지 못한다는 것을 모릅니다. "더 큰 컨텍스트 창 모델로 교체하면 된다"고 답하는 사람은 어텐션 희석 비용을 계산해본 적이 없습니다. 이 질문은 프로덕션 시스템을 경험한 사람과 데모만 해본 사람을 바로 구분합니다.
🧭 답변 프레임워크
- 먼저 딜레마를 제시하세요: 새 창을 열면 Agent는 기억을 잃고 이미 한 작업을 반복합니다. 기존 창에 머물면 Token이 쌓이고 어텐션이 희석되어 성능이 계속 저하됩니다. Claude Code, Cursor, Devin이 매일 이 문제를 해결합니다.
- 기법 1 — Compaction: 창이 거의 찼을 때 LLM 호출 한 번으로 구조화된 요약을 생성합니다. 아키텍처 결정과 미해결 버그는 유지하고, 중복 도구 출력과 완료된 태스크의 중간 단계는 버립니다. 잘못 선택하면 Agent가 같은 실수를 반복합니다.
- 기법 2 — 구조화 메모: 핵심 정보를 외부 파일에 능동적으로 작성하고, 새 창이 읽어서 기억을 복원합니다. Claude Code의 TODO 파일과 포켓몬을 플레이할 때 Claude가 유지하는 게임 메모가 모두 이 방식입니다.
- 기법 3 — 서브 Agent: 깊은 탐색을 위임합니다. 서브 Agent는 자체 창에서 30K Token을 소모해 코드를 읽고 추론한 뒤, 메인 Agent에 1,500 Token의 결론만 반환합니다. 메인 컨텍스트는 항상 깔끔하게 유지됩니다.
⭐ 가산점 세 기법의 역할을 각각 설명할 수 있으면 좋습니다: 창 내부 간결 유지, 창 간 기억 전달, 탐색 노이즈 격리. 그리고 실제 제품에서는 세 가지를 함께 사용한다고 덧붙이세요. 이는 개별 용어가 아닌 시스템 전체를 이해하고 있음을 보여줍니다.
Q3기술 동료
「제품에 코드베이스 Q&A를 추가해야 합니다. 또 벡터 스토어 구축 프로젝트를 시작하려는 건 아니죠? Claude Code는 전부 grep으로 즉시 검색합니다.」
🎯 무엇을 평가하는가
RAG를 기본 답으로 생각하는지 탐색하는 질문입니다. 바로 청킹, 벡터화, 인덱스 구축을 말하는 PM은 기술 동료 눈에 망치를 든 사람처럼 보입니다. 상대방은 먼저 방안을 비교하고 인덱스 유지보수 비용을 계산해주기를 원합니다.
🧭 답변 프레임워크
- 먼저 인정하세요: 목표는 올바른 정보를 컨텍스트 창에 넣는 것이며, RAG는 방법 중 하나일 뿐입니다. 코드베이스처럼 자주 변경되는 데이터에는 필요할 때 검색하는 방식이 더 적합합니다.
- JIT 검색을 설명하세요: glob/grep으로 필요할 때 즉시 검색하여 컨텍스트를 간결하게 유지하고, 현재 필요한 내용만 포함합니다. 비용은 도구 호출 지연 한 번이고, 대신 인덱스 구축과 동기화의 유지보수 부담이 없습니다.
- 혼합 전략을 제시하세요: 고빈도 정보는 사전 로드(프로젝트 규칙, 핵심 규칙, 사용자 선호), 롱테일 정보는 필요 시 가져옵니다. 브라우저 캐시에 비유하면: 핫 데이터는 메모리에, 콜드 데이터는 요청 시 가져옵니다.
- RAG가 적합한 시점을 명확히 하세요: 상대적으로 정적인 지식베이스 시나리오에 RAG가 적합하지만, 단순 청킹은 컨텍스트를 잃습니다. Contextual Retrieval은 각 Chunk에 컨텍스트 접두사를 추가하고, BM25 이중 경로 검색과 Reranking을 결합하여 검색 실패율을 67% 낮출 수 있습니다.
⭐ 가산점 Contextual Retrieval 비용을 능동적으로 계산하세요: Chunk마다 접두사 생성에 LLM 호출 한 번 추가, Prompt Caching으로 낮출 수 있습니다. 법률, 의료, 금융처럼 높은 정확도가 필요한 시나리오에만 가치 있고, 일반 채팅 추천에는 불필요합니다.
Q4면접관
「프로덕션 Agent가 계속 잘못된 도구를 선택하고 파라미터를 잘못 입력합니다. 엔지니어들은 모델이 부족하다며 다음 세대를 기다리라고 합니다. PM으로서 어떻게 생각하시나요?」
🎯 무엇을 평가하는가
ACI에 대해 알고 있는지 확인합니다. "모델 업그레이드를 기다리자"에 동의하는 사람은 바로 탈락입니다. 상대방은 이런 말을 듣고 싶어합니다: 도구 정의가 Agent의 사용자 인터페이스이며, 잘못된 도구 선택은 대부분 설계 문제이고, PM에게는 명확한 진단 체크리스트가 있다는 것입니다.
🧭 답변 프레임워크
- 프레임 설정: 도구의 이름, 파라미터, 설명이 Agent의 사용자 인터페이스입니다. 전통적인 API는 결정론적이지만 Agent 도구는 비결정론적이며, 언제 어떻게 사용하는지는 전적으로 설계 품질에 달려 있습니다. 도구 설계에는 HCI 설계와 같은 수준의 투자가 필요합니다.
- 진단 체크리스트 제시: 네 가지 원칙을 하나씩 확인합니다. 파라미터 순서가 모델에 사고 공간을 주나요(간단한 방향 먼저, 복잡한 내용 나중)? 형식이 학습 데이터에 가깝나요(표준 unified diff가 커스텀 DSL보다 낫습니다)? 모델이 기계적으로 줄 번호를 세도록 강제하고 있나요? 실수 방지 설계(Poka-yoke)가 있나요?
- 구체적인 사례 제시: SWE-bench에서 파일 경로 파라미터를 상대 경로에서 절대 경로만 받도록 변경한 것이 파라미터 하나의 변경으로, 도구 호출이 빈번한 오류에서 거의 완벽하게 바뀌었습니다.
- 설명 기준을 제시하세요: 컨텍스트가 없는 똑똑한 주니어 개발자를 위한 문서를 쓰듯이 작성합니다. 사용 예시, 엣지 케이스, 입력 형식, 다른 도구와의 차이, 사용하지 않아야 할 때 — 다섯 가지를 모두 포함하세요.
⭐ 가산점 "사람도 어떤 도구를 써야 할지 모르면 AI도 모른다"고 덧붙이세요. 그리고 Claude Code의 고급 방식을 언급하세요: Agent를 사용하여 자체 도구의 설명을 작성하고, 평가를 실행하고, 자동으로 반복 최적화합니다.
Q5상사
「새 모델이 출시된 지 일주일이 됐습니다. 경쟁사는 출시 다음날 도입을 발표했습니다. 우리는 평가에 3주가 필요하다고요? 시간이 어디에 쓰이는지 설명해보세요.」
🎯 무엇을 평가하는가
표면적으로는 진행을 독촉하지만, 실제로는 팀에 평가 인프라가 있는지 묻는 것입니다. 이는 수동적인 비난을 자원 요청의 기회로 바꿀 수 있는 질문입니다. "기술 일정이 원래 이래요"라고 답하면 무능을 인정하는 것입니다. "내일 당장 교체하겠습니다"라고 답하면 제품 품질로 도박을 하는 것입니다.
🧭 답변 프레임워크
- 결론부터 제시하세요: 마이그레이션 속도는 평가 인프라에 달려 있습니다. 완성된 eval suite가 있는 팀은 테스트를 실행하고, 회귀 없음을 확인하고, 며칠 만에 전환을 완료합니다. 없는 팀은 몇 주 동안 수동으로 검증할 수밖에 없습니다. 우리가 느린 이유는 인프라 부채입니다.
- 평가가 가져다주는 가치를 설명하세요: Prompt 변경, 모델 교체, 파라미터 조정 — 몇 분 안에 전체 영향을 파악합니다. 버그 하나를 수정하면서 세 개를 만드는 것을 방지합니다. 새 모델이 출시될 때마다 가장 먼저 혜택을 받습니다.
- 시작 계획을 제시하세요: 핵심 시나리오를 커버하는 20개의 테스트 케이스로 시작할 수 있습니다. 잘 설계된 20개의 케이스가 계획서에만 있는 500개보다 한 세대 앞섭니다.
- 기대치를 관리하세요: 경쟁사가 빨리 통합한다고 해서 엄격하게 테스트한다는 뜻은 아닙니다. 공개 벤치마크 점수는 과대평가됩니다(모델이 시험을 인식합니다) — 자체 비즈니스 시나리오 케이스를 사용하세요. 평가 환경은 프로덕션과 일치해야 하며, 샌드박스 구성 차이만으로도 6%의 오차가 발생할 수 있습니다.
⭐ 가산점 보고서에서 형용사를 지표 언어로 교체하세요: "나빠진 것 같다"를 "간결성이 72에서 85로 향상됐지만 과잉 엔지니어링이 3%에서 7%로 악화됨 — 롤백 필요"로 업그레이드하세요. 상사의 신뢰가 한 단계 높아집니다.
Q6면접관
「Agent 출력 품질을 어떻게 자동으로 채점하나요? LLM-as-Judge에만 의존하면 신뢰할 수 있나요?」
🎯 무엇을 평가하는가
평가 툴박스의 숙련도를 확인합니다. "LLM으로 채점한다"고만 답하는 사람은 들어본 정도입니다. 세 가지 Grader의 경계와 조합 방식을 명확히 설명할 수 있는 사람은 실제로 평가를 해본 것처럼 들립니다.
🧭 답변 프레임워크
- 세 가지 Grader 유형을 모두 나열하세요: 코드 Grader(어서션, 단위 테스트, 정규식 — 밀리초 단위, 비용 제로, 완전 재현 가능, 단 합리적인 변형에는 너무 엄격함), 모델 Grader(주관적 품질 평가 가능, 단 비용과 편향이 있음), 사람 Grader(품질 최고, 단 확장 불가).
- LLM-as-Judge에 직접 답하세요: 신뢰도는 전적으로 Rubric에 달려 있습니다. "품질을 0~1점으로 채점하라"는 거의 쓸모없습니다. 각 점수 수준에서 구체적이어야 합니다: 0점은 어떤 모습인지, 0.3점에서 무엇이 부족한지, 1점을 받으려면 어떤 조건이 모두 충족되어야 하는지.
- 조합 방법을 제시하세요: 코드 Grader를 기반으로 결정론적 시나리오를 다루고, 모델 Grader로 주관적 품질까지 확장하며, 사람이 주기적으로 샘플링하여 모델 Grader의 드리프트를 교정합니다. 세 레이어 모두 필수입니다.
- 자주 놓치는 포인트를 추가하세요: 평가해야 할 것은 Outcome — 환경의 최종 상태입니다. Agent가 완료했다고 말하는 것으로는 부족합니다. 파일이 실제로 올바르게 변경됐는지, API가 실제로 올바르게 호출됐는지 확인해야 합니다.
⭐ 가산점 Trial 개념을 언급하세요: 모델 출력은 확률적이므로 동일한 Task를 여러 번 실행해야 통계적 의미가 있습니다. 그리고 Descript의 3차원 채점(망가뜨리지 않음, 요구한 것을 수행함, 잘 수행함)을 인용하면 실제 사례를 접해봤다는 인상을 줍니다.
Q7기술 동료
「이 요구사항은 Agent가 사용자의 GitHub Token을 사용하여 모델이 생성한 코드를 실행하게 합니다. 문제가 생기면 누가 책임지나요? '위험한 작업은 실행하지 마세요'라는 Prompt 한 줄로는 납득할 수 없습니다.」
🎯 무엇을 평가하는가
보안 리뷰에서의 전형적인 대립으로, 구조적 보안을 이해하는지 확인합니다. 답변에 "Prompt에 제약을 추가하겠다"나 "모델이 거부할 것이다"만 있다면 이 요구사항은 즉시 거부됩니다. 상대방은 방어선이 아키텍처에 구축되어야 한다는 것을 알고 있는지 확인하고 싶어합니다.
🧭 답변 프레임워크
- 먼저 상대방 입장에 동의하세요: Prompt 기반 방어는 신뢰할 수 없고, 보안은 구조적 설계에 의존해야 합니다. 목표는 모델이 Prompt Injection에 완전히 조작되더라도 공격자가 자격증명을 얻을 수 없도록 하는 것입니다.
- 위험을 분류하세요: 세 가지 카테고리, 각각 별도로 방어: 사용자의 의도적 남용, 모델의 자발적 통제 상실(과도한 행동, 환각을 기반으로 실제 작업 실행), 외부 공격(사용자도 모르는 웹 페이지와 문서에 삽입된 주입 명령).
- 자격증명 솔루션을 제시하세요: 첫 번째 원칙은 생성된 코드와 시크릿을 항상 서로 다른 컨테이너에 격리하는 것입니다. 두 가지 모드: Token을 리소스 접근 경로에 주입(Agent가 사용할 수 있지만 볼 수 없음 — 예: Git remote URL에 삽입), Vault 프록시 전달(프록시가 세션별로 Token을 주입하고 Agent는 단 한 글자도 볼 수 없음).
- 실행 환경 솔루션을 제시하세요: OS 수준 샌드박스로 3중 격리(파일 시스템, 네트워크, 프로세스), 3단계 신뢰 제어 추가: 고위험 도구에 대한 수동 승인, 세션 수준 인가, 전역 정책 최종 안전망(프로덕션 데이터베이스는 절대 접근 불가).
⭐ 가산점 "모델이 강력할수록 기존 아키텍처에서 공격 표면이 커진다"고 능동적으로 말하세요. 따라서 보안 설계는 모델 업그레이드로 자동으로 개선되기를 기대할 수 없습니다. 이 말 한마디가 보안 엔지니어가 당신을 동료로 보게 만듭니다.
Q8면접관
「당신이 설계한 이 기능은 결국 Workflow로 만들어야 하나요, Agent로 만들어야 하나요? 판단 기준을 주세요. Agent가 더 똑똑하다는 말만으로는 안 됩니다.」
🎯 무엇을 평가하는가
이 챕터 첫 강의의 분수령 문제입니다. Agent만 외치는 사람은 유행어를 쫓는 것이고, 진짜 아는 사람은 먼저 태스크 구조를 봅니다: 제어권이 코드에 있는지 모델에 있는지. 이 선택이 이후의 모든 비용과 디버깅 방식을 결정합니다.
🧭 답변 프레임워크
- 먼저 정의부터: Workflow는 LLM과 도구가 미리 정의된 코드 경로를 걷는 것이고, 개발자가 코드를 쓸 때 이미 A 다음 B 다음 C를 정해 둡니다. Agent는 모델이 흐름을 동적으로 결정하며, 매 단계에서 어떤 도구를 호출할지, 언제 끝낼지를 스스로 판단합니다.
- 핵심 차이를 제시하세요: Workflow는 입력이 정해지면 경로가 정해져 재현과 디버깅이 쉽습니다. Agent는 같은 입력이라도 다른 경로를 탈 수 있어 행동이 불확실하고, 프로덕션 이슈를 재현하기 어렵습니다.
- 판단 기준을 제시하세요: 태스크 분해가 명확하고 단계가 고정되면 Workflow를 씁니다. 카피 생성 파이프라인, 데이터 클리닝 플로가 전형입니다. 태스크가 열려 있고 현장 판단이 필요할 때만 Agent를 쓰며, Claude Code, Devin 같은 코딩 어시스턴트가 전형입니다.
- 프로덕션 합의를 인용하세요: Anthropic이 대량의 실제 적용 사례를 회고했을 때, 가장 성공한 구현은 복잡한 프레임워크가 아니라 단순하고 조합 가능한 패턴이었습니다.
⭐ 가산점능동적으로 비용 계산을 하세요: Workflow는 호출 횟수가 고정되어 예산을 추정할 수 있고, Agent는 루프 횟수를 알 수 없어 청구서를 통제할 수 없습니다. 예산을 보고할 때 둘은 완전히 다른 대화이며, 이 지점을 대부분의 지원자가 생각하지 못합니다.
이 강의 페이지로 답변을 구성하세요 →
Workflow vs Agent: 먼저 무엇이 필요한지 파악하기
Q9기술 동료
「이 방안은 분류기에 고정 흐름까지 있는데, 옆 팀은 이미 완전 자율 Agent를 돌리고 있습니다. 우리가 너무 보수적인 거 아닌가요?」
🎯 무엇을 평가하는가
역방향 탐색으로, 업계 유행어에 휘둘릴지를 봅니다. 복잡도 사다리를 거꾸로 밀고, 복잡도 한 층마다 대응하는 이득이 있음을 증명할 수 있는 PM이어야 엔지니어링 팀이 신뢰합니다.
🧭 답변 프레임워크
- 먼저 원칙을 세우세요: 복잡도는 비용입니다. 한 층을 더할 때마다 같은 질문에 답해야 합니다: 이 층이 가져오는 이득이 추가 지연, 비용, 디버깅 난이도를 감수할 가치가 있는가.
- 4단계 사다리를 제시하세요: 먼저 단일 LLM 호출을 최적화하고(Prompt, Few-shot, Temperature), 부족하면 RAG를 더하고, 그래도 부족하면 Workflow로 단계를 쪼개고, 정말 유연한 판단이 필요할 때만 Agent를 올립니다.
- 완전 자율의 대가를 계산하세요: 제어권을 코드에서 모델로 넘기면 루프 횟수를 알 수 없고, 비용이 통제되지 않으며, 행동을 재현하기 어렵습니다. 이 대가는 대응하는 이득이 있을 때만 수지가 맞습니다.
- 과도 설계 안티패턴을 드세요: Prompt 하나와 검색 한 번으로 풀리는 문제에 Agent 프레임워크를 쓰면, 프레임워크가 가져오는 지연, 비용, 불확실성이 이득보다 훨씬 큽니다.
⭐ 가산점프로덕션 실천의 결론을 인용하세요: 대부분의 시나리오에서는 단일 호출 최적화에 검색 증강을 더하면 충분합니다. 리뷰에서 「우리는 Agent가 필요 없습니다」라고 말할 수 있는 PM이, 유행어를 쫓는 사람보다 엔지니어를 안심시킵니다.
Q10면접관
「다섯 가지 Workflow 패턴을 다 써 봤나요? 세 가지를 골라 설명해 보세요. 각각 어떤 시나리오에 맞는지, 어떤 대가를 치르는지.」
🎯 무엇을 평가하는가
용어 문제의 심화판입니다. 영어 이름 다섯 개를 외운 사람은 흔하고, 적용 조건과 대가를 말할 수 있는 사람은 드뭅니다. 세 가지를 고르라는 것은 트레이드오프 표현을 보는 것입니다.
🧭 답변 프레임워크
- Prompt Chaining: 태스크를 고정 순서 단계로 나눌 수 있을 때 씁니다. 단계 사이에 품질 게이트를 넣을 수 있습니다. 예를 들어 카피에 브랜드 핵심 정보가 들어 있는지 검사하고, 통과해야 번역으로 넘깁니다. 대가는 지연이며, 본질은 지연을 정확도와 바꾸는 것입니다.
- Routing: 입력 유형이 다양할 때 먼저 분류한 뒤 분기합니다. 간단한 FAQ는 Haiku처럼 빠르고 싼 모델로, 환불 문제는 Sonnet에 주문 도구를 붙입니다. 가치는 관심사 분리와 비용 계층화입니다.
- Parallelization: 하위 패턴이 둘입니다. Sectioning은 독립 서브태스크를 병렬로 돌립니다. 보안, 성능, 스타일 세 갈래로 동시에 코드 리뷰를 하는 식입니다. Voting은 같은 태스크를 여러 번 돌려 다수 의견을 취하며, 돈으로 신뢰도를 삽니다.
- 나머지를 보완하며 마무리: Orchestrator-Workers는 오케스트레이터가 런타임에 태스크를 동적으로 쪼개며, 서브태스크를 미리 정할 수 없을 때 쓰고 Agent에 가장 가깝습니다. Evaluator-Optimizer는 생성과 평가를 순환 반복하며, 번역처럼 명확한 품질 기준이 있는 시나리오에 맞습니다.
⭐ 가산점Orchestrator와 Parallelization의 경계선을 말하세요: 전자의 서브태스크는 오케스트레이터가 런타임에 동적으로 정하고, 후자는 코드에 미리 고정합니다. 이 구분을 거의 아무도 답하지 못합니다.
이 강의 페이지로 답변을 구성하세요 →
다섯 가지 Workflow 패턴
Q11상사
「AI 고객지원 API 청구서가 이번 달 40% 올랐는데 사용자 수는 10%만 늘었습니다. 다음 분기 비용을 절반으로 깎으세요. 기능은 하나도 빼면 안 됩니다.」
🎯 무엇을 평가하는가
구조적 비용 절감 툴박스가 있는지를 봅니다. 「벤더와 가격을 깎자」나 「사용량을 제한하자」는 공을 받지 못한 답입니다. 청구서 증가 속도가 사용자 증가보다 빠르면 호출당 Token이 팽창하고 있는 것이고, 그것이 고쳐야 할 병입니다.
🧭 답변 프레임워크
- 먼저 Routing 분기를 올리세요: 분류기를 하나 더합니다. 간단한 FAQ는 싼 소형 모델로, 환불·불만처럼 복잡한 문제만 강한 모델에 도구를 붙입니다. 고객지원 트래픽의 대부분은 간단한 질문이라 이 한 칼이 가장 많이 절약합니다.
- 도구 반환을 거버넌스하세요: 전체를 반환하고 있는지 한 번 점검하세요. 847개 전체 레코드를 한 번에 돌려주면 Token 5만 이상이 타고, 상위 10개 핵심 필드에 페이지네이션 힌트를 더하면 800 Token이면 충분하며 정보 밀도는 오히려 높아집니다.
- 캐시 배당을 받으세요: System Prompt, 도구 정의처럼 안정적인 내용은 접두사에 두고 바꾸지 마세요. Prompt Cache에 히트하면 반복 구간의 비용이 크게 떨어집니다.
- 검증 폐루프를 제시하세요: 항목마다 평가를 돌려 품질이 떨어지지 않았는지 확인하고, 마지막으로 데이터로 보고합니다: 비용이 얼마나 줄었고, 핵심 지표는 유지됐습니다.
⭐ 가산점상사에게 숨은 장부를 상기시키세요: 컨텍스트가 길어지면 모델도 더 멍청해집니다(Context Rot). 검색 정확도는 Token 수에 따라 떨어집니다. 컨텍스트를 줄이면 절약과 품질 향상이 동시에 일어나는 경우가 많고, 이 점을 대부분의 팀이 모릅니다.
Q12면접관
「당신이 쓴 System Prompt를 엔지니어들이 요구사항 문서 같다고 합니다. 규칙이 거의 60개입니다. System Prompt는 대체 어디까지 써야 한다고 생각하나요?」
🎯 무엇을 평가하는가
「적절한 수준」에 대한 판단력을 봅니다. 규칙을 쌓아 올리는 사람은 모델을 기본으로 믿지 않고, 「당신은 어시스턴트입니다」한 줄만 쓰는 사람은 안내를 포기한 것입니다. 상대방은 두 극단이 각각 어디서 틀린지, 그리고 60개를 어떻게 거버넌스해 내릴지를 듣고 싶어합니다.
🧭 답변 프레임워크
- 두 극단을 제시하세요: 너무 모호하면(당신은 유용한 어시스턴트입니다) 모델에 방향 감각이 없어 출력이 두루뭉술해집니다. 너무 구체적이면(규칙 50개에 엣지 케이스 100개) 모델을 잠가 버려 새 상황을 만나면 융통성이 없습니다.
- 스위트 스팟을 제시하세요: 명확한 역할 정의, 핵심 원칙 5~10개, 경계를 긋고, 그다음 프레임 안에서 모델이 스스로 판단하도록 신뢰합니다. 좋은 관리자처럼: 방향은 주되, 매 단계 지시를 내리지는 않습니다.
- 규칙의 대가를 계산하세요: 규칙 60개 자체가 Token이며 어텐션 예산을 차지합니다. 규칙끼리 충돌하면 모델 행동은 오히려 더 예측하기 어려워집니다.
- 실행 액션을 제시하세요: 규칙을 원칙, 형식, 경계로 분류해 병합하면 보통 열몇 개로 줄일 수 있고, 다시 평가를 돌려 행동이 퇴행하지 않았는지 확인합니다.
⭐ 가산점과도한 제약의 숨은 대가를 짚으세요: 모델이 규칙 50개에 묶이면 새 상황을 유연하게 처리하지 못해, 대형 모델 값으로 규칙 엔진을 산 셈이 됩니다. 이 문장을 들으면 엔지니어가 고개를 끄덕입니다.
이 강의 페이지로 답변을 구성하세요 →
System Prompt의 적절한 수준
Q13면접관
「Agent의 기억은 자기가 쓰는 메모 파일 하나에 의존한다고요? 꽤 원시적으로 들립니다. 이걸 어떻게 설계해야 믿을 수 있나요?」
🎯 무엇을 평가하는가
구조화 메모는 단순해 보이지만, 보는 것은 전부 설계 디테일입니다: 무엇을 쓰고, 어떤 형식이며, 언제 다시 읽는지. 「모델이 자유롭게 쓰게 하면 됩니다」라고 답하는 사람은 실제 장기 태스크를 돌려 본 적이 없습니다.
🧭 답변 프레임워크
- 먼저 원리를 말하세요: 단기 기억(컨텍스트 윈도우)을 장기 기억(파일 시스템)으로 외부화합니다. 창이 초기화된 뒤 새 세션의 첫 일은 메모를 읽어 상태를 복원하는 것이고, 기억은 창을 넘어 이어집니다.
- 형식은 고정되고 구조화되어야 합니다: 자유 산문을 다시 읽으면 이해하려고 Token을 추가로 태웁니다. 고정 항목을 쓰세요: 완료, 미완료, 핵심 결정, 알려진 문제. 이후 추론은 항목에서 바로 가져갑니다.
- 읽기/쓰기 리듬을 정하세요: 쓰는 시점은 핵심 단계를 끝낼 때마다 업데이트하는 것이고, 창이 거의 찰 때까지 모으지 마세요. 읽는 시점은 창이 초기화되거나 새 세션이 시작될 때의 첫 단계입니다. 리듬이 흐트러지면 메모가 실제 진행과 어긋납니다.
- Compaction과의 분담을 가르세요: 압축은 옛 정보를 작게 눌러 계속 쓰는 것이고, 끊기지 않는 연속 대화에 맞습니다. 메모는 밖에 저장했다가 나중에 가져오는 것이고, 중단될 수 있으며 세션을 넘어 이어가야 하는 태스크에 맞습니다. 실제 제품에서는 둘을 조합합니다.
⭐ 가산점보호 메커니즘을 하나 보완하세요: 이런 상태 파일은 Prompt에서 강한 문구로 지켜야 합니다. 예를 들어 「기존 테스트 체크리스트를 삭제하거나 수정하는 것은 허용되지 않습니다」라고 명시하지 않으면, Agent가 테스트를 통과시키려고 스스로 기준을 낮춥니다.
Q14면접관
「방안에 think 도구를 넣었는데, 데이터를 조회하지도, API를 호출하지도, 어떤 상태도 바꾸지 않습니다. 아무것도 하지 않는 도구를 왜 더하나요?」
🎯 무엇을 평가하는가
Think Tool의 메커니즘과 경계를 진짜 이해하는지 봅니다. 「AI가 더 생각하게 하면 항상 좋다」고 답하면 바로 들킵니다. 상대방은 어떤 문제를 풀고, 언제가 순전한 낭비인지를 듣고 싶어하며, 데이터가 있으면 더 좋습니다.
🧭 답변 프레임워크
- 메커니즘을 말하세요: Think Tool은 부작용이 없는 도구이고, 유일한 역할은 Agent가 실행 도중에 생각을 적어 두게 하는 것입니다. 「멈춰서 생각하기」를 도구 호출로 포장하면, 모델이 도구 체인의 리듬 안에 추론 한 구간을 자연스럽게 끼워 넣을 수 있습니다.
- 시나리오를 말하세요: 효과가 가장 큰 시나리오는 세 가지입니다: 도구 5개 이상을 호출하는 긴 체인, 정책 밀집 환경(환불 정책 20개에 예외 6종), 매 단계가 이전 결과에 의존하는 직렬 의사결정. 공통점은 초반 정보가 이후 컨텍스트에 쉽게 묻힌다는 것입니다.
- 데이터를 보고하세요: τ-bench 항공 고객지원이 0.570에서 0.878로, 54% 올랐고, 리테일 고객지원은 11% 올랐습니다. 항공의 변경·취소 정책이 리테일보다 훨씬 복잡하고, 정책 밀도가 높을수록 Think Tool의 가치가 큽니다.
- 경계를 긋세요: 날씨 조회, 파일 읽기처럼 한 번에 끝나는 작업에 쓰면 순전한 오버헤드입니다. 도구를 호출하지 않는 순수 생성 태스크에는 필요 없고, 한 번에 생각할 수 있는 문제는 Extended Thinking에 맡기는 편이 더 직접적입니다.
⭐ 가산점Extended Thinking과의 분담을 분명히 하세요: 하나는 실행 전에 깊이 계획하고, 하나는 실행 도중에 멈춰 정리합니다. 「생각이 일어나는 시점이 다르다」고 말할 수 있으면 이 문제를 뚫은 것입니다.
이 강의 페이지로 답변을 구성하세요 →
Think Tool: AI가 먼저 생각하고 행동하게 하기
Q15기술 동료
「이 도구 요구사항은 사용자의 전체 주문 기록을 반환해야 합니다. 헤비 유저는 800여 개가 있습니다. 이 한 번 호출이 Token을 얼마나 먹는지 계산해 봤나요?」
🎯 무엇을 평가하는가
도구 반환을 컨텍스트 예산의 일부로 보는지 확인합니다. 기술 동료가 가장 두려워하는 것은 PM이 「전부 반환하고 모델이 고르게 하세요」라고 말하는 것이고, 그것은 비용과 어텐션 문제를 동시에 터뜨리는 것입니다.
🧭 답변 프레임워크
- 먼저 인정하세요: 전체 반환은 재앙입니다. 847개 전체 레코드는 약 5만 2천 Token이고, 모델이 처리하지 못하며 창 안의 다른 정보 어텐션까지 희석합니다.
- 네 가지 축소 전략을 제시하세요: 요약(통계 정보만 반환), 잘라내기(기본 상위 N개), 페이지네이션(페이지 파라미터), 필터(조건 선별 지원). 시나리오에 따라 조합합니다.
- 반환에는 다음 단계 단서가 있어야 합니다: success만 돌려주는 것은 나쁜 설계입니다. 티켓 ID, 링크, 담당자처럼 Agent가 다음 단계에 쓸 정보를 반환하면 추적 호출 한 번을 아낍니다.
- 페이지네이션을 반환 본문에 넣으세요: total, showing, page를 담고 「page=2로 더 보세요」라는 힌트를 더하면, Agent가 나머지 데이터를 어떻게 가져올지 스스로 압니다.
⭐ 가산점이 일을 원칙으로 끌어올리세요: 도구 반환도 ACI의 일부이며, 차지하는 것은 모델의 어텐션 예산입니다. 800 Token의 고밀도 반환이 5만 Token의 원본 데이터 덤프보다 효과가 좋습니다.
Q16면접관
「Agent 도구가 10개에서 60개로 늘어난 뒤, 잘못된 도구를 고르는 비율이 오히려 올랐습니다. 이 도구 세트를 어떻게 거버넌스하겠습니까?」
🎯 무엇을 평가하는가
「적을수록 많다」를 적용하는 능력을 봅니다. 도구를 더하는 것은 누구나 하고, 도구를 줄이고 조직할 줄 아는 PM은 드뭅니다. 상대방은 규칙이 명확한 거버넌스 방안을 듣고 싶어하며, 모델 탓부터 하지 마세요.
🧭 답변 프레임워크
- 먼저 성격을 규정하세요: 선택 오류율이 도구 수와 함께 오른다는 것은 도구 사이 경계가 흐려졌다는 뜻입니다. search, find, lookup처럼 기능이 비슷한 도구 세 개를 나란히 두면, 잘못된 선택은 도구 세트의 병이고 모델은 증상을 드러낼 뿐입니다.
- 중복 항목을 병합하세요: 두 도구의 사용 시나리오가 절반 넘게 겹치면 합칩니다. 파라미터 몇 개가 더 있는 도구 하나가, 혼동하기 쉬운 도구 둘보다 낫습니다.
- 네임스페이스를 올리세요: 관련 도구에 통일 접두사로 그룹을 답니다. jira_create_issue, jira_list_issues, git_diff, db_query. Agent가 어떤 도구가 같은 시스템을 다루는지 한눈에 보면 오선택 확률이 급감합니다.
- 데이터로 검수하세요: 도구 선택 오류는 평가로 측정할 수 있습니다. 거버넌스 전후에 같은 케이스 세트를 돌려 정선택률을 비교하고, 도구를 줄인 것이 맞았음을 증명합니다.
⭐ 가산점도구 정의 자체가 컨텍스트를 차지한다고 말하세요: 도구 60개의 schema는 매 추론 라운드마다 창에 들어갑니다. 쓰지 않는 도구를 줄이는 것은 호출마다 어텐션 예산을 공짜로 확보하는 것과 같습니다.
Q17면접관
「도구 설명 문서가 수십 개인데, 누구한테 쓰게 할 건가요? 나온 품질은 어떻게 보장하나요, 수동 Review에 의존할 건가요?」
🎯 무엇을 평가하는가
분업 문제처럼 들리지만, 실제로는 Agent로 Agent 도구를 최적화하는 이 워크플로를 아는지 봅니다. 「엔지니어가 쓰면 내가 한 번 검토한다」고 답하면 아직 전통 문서 사고에 머문 것입니다.
🧭 답변 프레임워크
- Prototype: Claude Code가 요구사항에 따라 도구 프로토타입을 생성하게 합니다. 도구 정의, 파라미터 검증, API 호출 로직을 포함하고, 사람은 무엇을 원하는지만 설명합니다.
- Evaluate: 네 차원으로 평가를 만듭니다: Agent가 도구를 맞게 골랐는지, 파라미터 입력이 맞는지, 반환 결과를 맞게 이해했는지, 엔드투엔드 태스크 완료율.
- Optimize: Claude Code가 평가 결과를 읽고 실패 원인을 자동 분석하게 합니다. 「오류의 43%는 Agent가 search와 list를 혼동한 것이고, 설명이 너무 비슷하기 때문」 같은 정확한 결론을 낸 뒤, 설명을 자동으로 다시 쓰고 구분 설명과 예시를 보완합니다.
- 사람의 역할을 정하세요: 사람은 평가 기준과 최종 검수를 맡고, 기계가 쓰고 고칩니다. 기준에 도달할 때까지 루프를 돌리며, 반복 속도는 수동 디버깅보다 한 자릿수 빠릅니다.
⭐ 가산점이 루프의 본질을 짚으세요: 도구를 잘 썼는지는 Agent 자신이 가장 발언권이 있습니다. 사용자를 저자로 두면 Agent가 자기 도구의 프로덕트 매니저가 되고, 이는 어떤 문서 규범보다 효과적입니다.
Q18면접관
「다음 주 입사한다고 가정합시다. 우리 Agent에는 평가가 하나도 없습니다. 첫 30일 동안 평가를 제로에서 어떻게 세우겠습니까?」
🎯 무엇을 평가하는가
실행 경로를 봅니다. 「평가는 중요하다」고 외치는 사람은 흔하고, 0에서 20개까지의 구체적 리듬을 주고 각 개념을 어떻게 적용하는지 말할 수 있는 사람만이 진짜 해 본 것입니다.
🧭 답변 프레임워크
- 첫째 주에 성공을 정의하세요: 평가를 쓰는 첫 가치는 팀이 「무엇이 좋은 것인가」에 답하게 만드는 것입니다. 가장 핵심 사용자 시나리오를 골라 정성껏 설계한 Task 20개를 쓰고, 각 항목에 입력과 성공 기준을 넣습니다. 20개면 시작할 수 있고, 500개의 거창한 계획을 기다리지 마세요.
- 최소 폐루프를 구축하세요: Harness가 샌드박스를 띄우고 태스크를 돌리고 결과를 거두며, Grader가 채점하고, Task 한 세트가 Suite가 되어 한 번에 전부 실행됩니다. 먼저 Task, Trial, Grader, Suite라는 이 언어를 엔지니어링 팀과 맞춥니다.
- Transcript를 잘 저장하세요: 매번 실행의 전체 궤적(매 단계 추론, 매 도구 호출, 중간 결과)을 기록합니다. 실패했을 때 도구를 잘못 고른 것인지 파라미터를 잘못 채운 것인지 짚을 수 있어야, 평가가 개선 방향을 안내할 수 있습니다.
- 변경 프로세스에 연결하세요: 이후 Prompt를 고치고, 모델을 바꾸고, 파라미터를 조정할 때마다 먼저 Suite를 한 번 돌려 몇 분 안에 영향 범위를 봅니다. 팀의 보고 언어가 「나빠진 것 같다」에서 구체적 점수로 올라갑니다.
⭐ 가산점직관에 반하는 수확을 하나 보완하세요: 많은 팀이 eval을 쓰는 과정에서 오래 모호했던 제품 정의를 처음으로 정리합니다. 평가는 품질 검사 도구이기도 하고 요구사항 분석 도구이기도 합니다.
Q19상사
「평가 한 라운드에 모델 호출을 수백 번 돌리고, 한 달 테스트에 수만 위안이 나갑니다. 이 돈이 아깝지 않나요?」
🎯 무엇을 평가하는가
상사가 의심하는 것은 ROI입니다. 「평가는 중요하다」는 구호는 소용없고, 낭비처럼 보이는 지출마다 보험과 레버리지로 말해야 하며, 비용을 통제하는 방법도 줘야 합니다.
🧭 답변 프레임워크
- 왜 그렇게 많이 도는지 설명하세요: 모델 출력에는 무작위성이 있어, 같은 태스크를 한 번만 돌린 결과는 노이즈입니다. 같은 Task를 Trial로 여러 번 돌려야 통계적 의미가 있고, 이 돈을 아끼는 것은 주사위로 제품 결정을 하는 것과 같습니다.
- 평가가 없을 때의 비용을 계산하세요: 버그 하나를 고치며 새 버그 세 개를 만들고, 사용자 불만이 나와야 발견합니다. 「Agent가 나빠졌다」는 한 번의 추적은 commit 기록을 사흘 뒤지는 일입니다. 엔지니어 시간은 API 요금보다 훨씬 비쌉니다.
- 평가가 벌어 주는 돈을 계산하세요: Prompt를 고치거나 모델을 바꿀 때마다 몇 분 안에 영향을 압니다. 새 모델이 나오면 Suite를 한 번 돌려 점수가 떨어지지 않음을 확인하고 전환하며, 매번 가장 먼저 배당을 받습니다.
- 비용 절감 방안을 제시하세요: 엄선 케이스 20개가 핵심 시나리오를 커버합니다. 결정론적 검사는 밀리초 단위, 비용 제로인 코드 Grader로 밑을 깔고, 돈 드는 모델 Grader는 주관적 품질에만 씁니다.
⭐ 가산점한 문장으로 마무리하세요: 평가 투입은 복리이고, 초기의 1분이 회귀 테스트, 모델 마이그레이션, 팀 협업에서 계속 수익을 냅니다. 상사는 복리를 이해합니다.
Q20면접관
「사용자가 출력이 장황하다고 해서 System Prompt를 고친 뒤 바로 올렸더니 코딩 능력이 떨어졌습니다. 회고해 보세요. 프로세스에서 무엇이 잘못됐나요?」
🎯 무엇을 평가하는가
사고 회고 문제로, 실제 프로덕션에서 Prompt 변경이 회귀를 일으킨 사례와 가드레일 프로세스를 아는지 봅니다. 모델이나 테스트 동료에게 책임을 넘기는 사람은 그 자리에서 탈락입니다.
🧭 답변 프레임워크
- 먼저 성격을 규정하세요: 단일 차원의 개선이 전체 개선은 아닙니다. 실제 사례에서 장황함을 줄이려고 System Prompt를 고쳤더니 간결성은 올라가고 coding eval은 약 3% 떨어졌습니다: 모델이 간결해지면서 핵심 주석과 오류 처리도 아낀 것입니다.
- 프로세스 오류 하나: 줄 단위 ablation을 하지 않았습니다. Prompt 변경은 매번 한 줄만 고치고 영향을 따로 측정해, 각 문장의 기여를 알아야 합니다.
- 프로세스 오류 둘: 목표 차원만 측정했습니다. 올리기 전에 전체 eval suite를 돌려 간결성, 코드 품질, 과잉 엔지니어링을 함께 봐야, 한쪽을 누르면 다른 쪽이 떠오르는 일을 막을 수 있습니다.
- 같은 유형의 사고를 드세요: reasoning effort 기본값처럼 무해해 보이는 설정 조정도 여러 차원의 회귀를 만든 적이 있습니다. 결론은 모든 변경, Prompt, 파라미터, 인프라를 포함해 동일하게 평가를 탄다는 것입니다.
⭐ 가산점「과잉 엔지니어링 eval」같은 역방향 지표를 말하세요: 간결성을 최적화할 때 그것이 악화되는지도 함께 봅니다. 서로 견제하는 지표 한 쌍이어야 최적화가 한 방향으로 치우치는 것을 막을 수 있습니다.
Q21기술 동료
「선정 회의에서 공개 benchmark 리더보드로 말하려고요? 그건 이미 조작으로 오염됐습니다. 그 점수를 진짜 믿나요?」
🎯 무엇을 평가하는가
평가 신뢰도에 대한 인식 수준을 봅니다. benchmark에 한계가 있음을 인정하면서도 구체적인 실패 메커니즘을 말할 수 있는 PM이어야 선정 회의에서 버팁니다.
🧭 답변 프레임워크
- 실패 메커니즘 하나, 모델이 시험을 인식함: Claude Opus 4.6은 BrowseComp에서 자신이 benchmark를 돌리고 있음을 추론할 수 있고, 문제 패턴을 알아본 뒤 답을 검색하거나 훈련 데이터에서 본 유사 문항을 호출합니다. 정적 문제 은행이 네트워킹 환경을 만나면, 측정하는 것이 능력인지 기억력인지 알 수 없습니다.
- 실패 메커니즘 둘, 변별력 감쇠: 모델이 강할수록 평가를 알아보는 능력도 강해지고, 고정 benchmark가 최첨단 모델을 가르는 힘은 계속 떨어지며, 공개 문항 성적은 체계적으로 과대평가됩니다.
- 실패 메커니즘 셋, 인프라 노이즈: CPU와 메모리 제한만 바꿔도 점수가 6%포인트 차이 날 수 있고, 같은 모델 같은 태스크라도 샌드박스 구성을 바꾸면 순위가 뒤집힙니다.
- 대안을 제시하세요: 자체 비즈니스 시나리오의 비공개 케이스, 동적 생성 시험 문항, 네트워킹 제한을 쓰고, 평가 환경을 프로덕션과 맞추며, 점수를 보고할 때 환경 구성도 함께 보고합니다.
⭐ 가산점한 줄 포지션을 주세요: 리더보드는 후보 명단을 거르는 데 쓰고, 최종 결정은 비공개 평가를 봅니다. benchmark를 올바른 자리에 두는 것, 그것이 기술 동료가 듣고 싶은 태도입니다.
이 강의 페이지로 답변을 구성하세요 →
모델이 시험을 인식하는 문제와 인프라 노이즈
Q22면접관
「Agent에게 큰 태스크를 주고 밤새 돌렸더니, 아침에 와 보니 거의 쓰레기가 되어 있습니다. 말해 보세요. 대체 어떻게 실패한 건가요?」
🎯 무엇을 평가하는가
장기 태스크의 실제 실패 현장을 본 적 있는지를 봅니다. 「컨텍스트가 충분히 길지 않다」는 피상적일 뿐이고, 상대방은 두 가지 구체적 실패 모드와 그 뒤에 공통된 인수인계 문제를 듣고 싶어합니다.
🧭 답변 프레임워크
- 실패 모드 하나 One-shotting: Agent가 모든 기능을 한 번에 끝내려다 창이 중간에 소진됩니다. 다음으로 이어받는 Agent는 반제품만 보고 전임이 무엇을 했는지 추측할 수밖에 없고, 시간은 기본 기능을 되돌리는 데 다 쓰이며 진전은 정체됩니다.
- 실패 모드 둘 Premature Completion: Agent가 기능 몇 개를 구현한 것을 보고 완료를 선언하지만, 실제로는 핵심 기능의 30%만 했습니다. 태스크 목록이 없어 무엇이 남았는지 모르고, 엔드투엔드 테스트가 없어 진짜 돌아가는지 증명하지 못합니다.
- 비유를 하나 주세요: 교대할 때마다 완전히 기억을 잃는 엔지니어 팀과 같고, 앉는 사람마다 반제품 코드 더미를 처음부터 이해해야 합니다. 이것이 인수인계 메커니즘이 없는 장기 실행 Agent입니다.
- 본질을 짚으세요: 장기 태스크의 핵심 도전은 인수인계이고, 실행 자체는 오히려 어렵지 않습니다. Agent에게 없는 것은 컨텍스트가 끊길 때 연속성을 유지하는 메커니즘이며, 해법 방향은 진행 파일에 증분 커밋입니다.
⭐ 가산점「Compaction이 있어도 One-shotting은 구하지 못하고, 압축 후의 지시가 충분히 명확하지 않아 새 Agent는 여전히 길을 잃습니다」라는 한 줄을 보완하세요. 압축의 한계가 어디인지 안다는 뜻입니다.
Q23면접관
「Agent가 완전한 웹 앱을 스스로 만들게 하고, 기능 포인트가 수백 개입니다. 이 시스템을 어떻게 설계해야 계속 진전되고 흐지부지되지 않나요?」
🎯 무엇을 평가하는가
개방형 아키텍처 문제로, 이중 역할 Harness의 숙련도를 봅니다. 상대방은 역할 분담, 상태 파일, 검수 메커니즘 세 층을 말하기를 기대하며, 한 층이 빠지면 제목만 읽은 것처럼 들립니다.
🧭 답변 프레임워크
- 이중 역할을 쪼개세요: Initializer는 첫 라운드만 돌며 제로에서 무언가로 가는 일을 맡습니다: init.sh로 환경을 만들고, 진행 파일을 쓰고, 상위 요구사항을 상세 기능 목록으로 펼치고, 첫 git commit을 합니다. Coding Agent는 매 라운드 진행 파일을 읽고 한 번에 기능 하나만 하며, 끝나면 진행을 갱신하고 커밋합니다.
- 기능 목록은 JSON을 쓰세요: 모델은 구조화 JSON을 잘못 수정하기 어렵고, Markdown 목록은 아무렇지 않게 다시 쓰입니다. 각 기능에 분류, 단계 목록, passes 필드를 답니다.
- 검수는 엔드투엔드 테스트에 의존하세요: Agent가 브라우저 자동화로 페이지를 실제로 열고 버튼을 실제로 눌러 검증하도록 명시하세요. 단위 테스트만으로는 부족합니다. E2E가 통과해야 passes입니다.
- 한 번에 하나의 가치를 분명히 하세요: 매 라운드가 끝날 때 코드는 머지 가능한 상태이고, commit은 롤백 포인트이며, 진행 파일은 인수인계서이고, 창은 절대 가득 차 터지지 않습니다.
⭐ 가산점성과를 보고하세요: 이 방안으로 기능 200개 이상의 claude.ai 클론을 돌린 적이 있고, 각 기능에 대응하는 E2E 테스트가 있습니다. 숫자가 있는 아키텍처 답은 설득력이 완전히 다릅니다.
Q24상사
「당신이 원하는 샌드박스, 평가, 스캐폴딩 일정이 3개월입니다. 모델은 6개월마다 업그레이드되는데, 그때가 되면 이게 전부 헛수고 아닌가요?」
🎯 무엇을 평가하는가
상사는 투자가 물거품이 될지 묻고 있습니다. 이 문제는 분류를 할 줄 알아야 합니다: 어떤 엔지니어링은 모델이 발전하면 구식이 되고, 어떤 것은 지속 자산입니다. 전부 가치 있다거나 전부 가치 없다는 일괄 답은 둘 다 틀립니다.
🧭 답변 프레임워크
- 먼저 절반을 인정하세요: Harness가 인코딩하는 것은 현재 모델 능력에 대한 가정이고, 가정은 구식이 됩니다. 실제 사례: Sonnet 4.5는 컨텍스트 불안이 있어 대화가 길어지면 성능이 떨어졌고, 팀이 context reset 메커니즘을 더했습니다. Opus 4.5로 바꾼 뒤 불안이 사라지자 이 메커니즘이 오히려 효율을 늦췄습니다.
- 분류 기준을 제시하세요: 특정 모델의 우회 방안, 특정 Prompt 기법은 구식이 됩니다. 샌드박스 격리, 권한 계층화, 평가 체계, Session 로그는 지속 아키텍처이고, 모델이 강할수록 더 필요합니다.
- 분류에 따라 일정을 잡으세요: 지속 자산을 우선하고, 임시 패치는 쓰지 않을 수 있으면 쓰지 않습니다. 원칙은 오늘 쓰지 않으면 내일 필요 없을 코드를 쓰지 않는 것입니다.
- 반대로 평가의 역할을 말하세요: 모델이 업그레이드될 때, 바로 평가가 며칠 안에 새 모델을 쓸 수 있는지, 어떤 옛 패치를 지울 수 있는지 확인하게 합니다. 이 3개월의 평가 투입이 아끼는 것은 이후 업그레이드마다의 수동 검증입니다.
⭐ 가산점판단력 자체를 답으로 삼으세요: 어떤 로직이 모델 발전과 함께 구식이 되고, 어떤 것이 진짜 지속되는 아키텍처 결정인지 가르는 이 판단력이 AI 시대에 가장 가치 있는 엔지니어링 능력입니다.
Q25면접관
「뇌-손 분리를 들어 봤나요? 왜 Agent의 사고와 실행을 다른 프로세스로 쪼개야 하나요? 쪼개면 대체 무엇을 얻나요?」
🎯 무엇을 평가하는가
아키텍처 이해 문제입니다. 「디커플링」두 글자만 외워서는 소용없고, 상대방은 세 컴포넌트가 각각 무엇인지, 그리고 쪼갠 뒤 장애 복구와 성능이 각각 어떻게 바뀌는지를 듣고 싶어합니다.
🧭 답변 프레임워크
- 세 컴포넌트를 제시하세요: Session은 append-only인 영구 이벤트 로그입니다. Harness는 뇌로, 모델을 호출하고 도구를 라우팅하는 루프를 돌립니다. Sandbox는 손으로, 코드를 실행하고 파일을 고치는 컨테이너입니다.
- 반려동물에서 가축으로의 전환을 말하세요: 셋이 한 컨테이너에 몰려 있으면 컨테이너가 죽을 때 세션이 사라지고 태스크가 완전히 실패합니다. 쪼갠 뒤 샌드박스가 죽으면 도구 호출 오류 한 번일 뿐이고, 모델이 재시도를 결정하며 시스템이 새 컨테이너를 만들어 이어서 합니다.
- 뇌의 복구 경로를 말하세요: Harness가 죽어도 두렵지 않습니다. 새 Harness가 wake(sessionId)로 기동하고 Session에서 전체 이벤트 스트림을 읽어 컨텍스트를 복원하며, 태스크는 영향을 받지 않습니다.
- 성능 이득을 보고하세요: 뇌는 컨테이너 ready를 기다리지 않고 처리를 시작할 수 있어 TTFT 중앙값이 60% 떨어졌고 p95는 90% 이상 떨어졌습니다. 컴포넌트가 분리되면 한 뇌가 여러 손을 병렬로 제어하거나, 한 손이 여러 뇌 사이에서 릴레이할 수도 있습니다.
⭐ 가산점OS 비유로 시작하세요: read()를 호출할 때 하위가 SSD인지 네트워크 디스크인지는 신경 쓰지 않습니다. Managed Agent도 같은 일을 하며, 뇌가 손이 어느 컨테이너인지 신경 쓰지 않게 합니다. 면접관은 이 비유를 기억합니다.
이 강의 페이지로 답변을 구성하세요 →
Managed Agent: 뇌-손 분리
Q26면접관
「Session과 컨텍스트 윈도우를 많은 사람이 같은 것으로 봅니다. 둘의 차이가 무엇인지, 왜 반드시 따로 저장해야 하는지 말해 보세요.」
🎯 무엇을 평가하는가
개념 구분에 아키텍처 동기까지, 이 챕터의 심화 구간입니다. 압축은 되돌릴 수 없다는 이 중심 축을 말할 수 있는 사람만이 장기 실행 Agent의 상태 설계를 진짜 이해한 것입니다.
🧭 답변 프레임워크
- 먼저 비유를 주세요: Context Window는 메모리로, 빠르고 작으며 쓰면 사라지고, 현재 추론의 선별된 내용을 담습니다. Session은 하드디스크로, 용량이 크고 전원이 꺼져도 유지되며, 모든 원본 이벤트의 완전한 기록을 담습니다.
- 분리의 동기를 말하세요: Compaction과 트리밍은 모두 되돌릴 수 없는 작업이고, 압축할 때 미래에 어떤 Token이 중요할지 미리 판단하기 어렵습니다. 오늘 무관해 보이는 디테일이 내일 핵심 결정의 근거일 수 있고, 버리면 영원히 돌아오지 않습니다.
- 올바른 자세를 제시하세요: 원본 이벤트는 전량 Session에 들어가고, append-only로 늘기만 하고 줄지 않습니다. 창은 Session에서 임시로 프레임을 잡는 하나의 관점일 뿐입니다. Context를 잃어도 괜찮고, 언제든 재구축할 수 있습니다.
- 엔지니어링 배당을 말하세요: Harness는 getEvents로 임의 구간을 필요할 때 조회하고 특정 이벤트 유형을 필터하며, 접두사를 안정적으로 유지해 Prompt Cache 히트율을 최적화할 수 있습니다. 모델을 바꾸든 Harness를 바꾸든 Session은 움직이지 않습니다.
⭐ 가산점한 문장으로 요약하세요: 메모리를 하드디스크로 쓰지 마세요. 사용자가 「Agent가 잊어버린다」고 불평하는 제품 문제는, 뿌리를 추적하면 거의 이 두 층이 나뉘지 않은 것입니다.
Q27상사
「사용자가 우리 Agent가 하루에 확인 창을 열몇 번 띄운다고 불평합니다. 책임을 지지 않는 인턴 같다는 겁니다. 전부 없앨 수 없나요?」
🎯 무엇을 평가하는가
상사는 경험을 원하지만, 안전을 맞바꿀 수는 없습니다. 팝업은 크게 줄이되 위험은 올리지 않는 구조화 방안을 줄 수 있는지를 보며, 「유지」나 「전부 삭제」같은 양자택일 답은 둘 다 불합격입니다.
🧭 답변 프레임워크
- 먼저 결론을 주세요: 대부분은 줄일 수 있고, 전부 없앨 수는 없습니다. Auto Mode의 실천 데이터는 분류기에 샌드박스를 더한 조합이 권한 팝업을 약 83% 줄였고, 안전성은 떨어지지 않았다는 것입니다.
- 분류기를 말하세요: 작업마다 위험 등급을 정하고, 파일 읽기, 코드 검색처럼 안전한 작업은 바로 통과시키며, 진짜 의심스러운 것만 팝업을 띄웁니다. 팝업이 「기본은 전부 묻기」에서 「예외일 때만 묻기」로 바뀝니다.
- 샌드박스 최후 안전망을 말하세요: 분류기가 오판해 위험한 작업을 통과시켜도, 코드는 파일 시스템, 네트워크, 프로세스 3중 격리 환경에서 실행되어 실제 시스템을 해치지 못합니다.
- 고위험 차단 목록은 남기세요: 파일 삭제, 데이터베이스 쓰기, 메일 발송 같은 작업은 영원히 사람 확인입니다. 이 부분의 팝업이야말로 사용자 신뢰감의 원천입니다.
⭐ 가산점논리를 한 문장으로 누르세요: 높은 자율은 분류기에서 오고, 낮은 위험은 샌드박스에서 오며, 둘 다 필요합니다. 분류기만 하는 것은 운에 맡기는 것이고, 샌드박스만 하면 경험은 여전히 나쁩니다.
Q28기술 동료
「연결하려는 서드파티 MCP 서버 세 곳은 도구 설명도 그들이 쓰고 반환 데이터도 그들이 줍니다. 우리는 한 줄도 검토할 수 없습니다. 이것이 무엇을 의미하는지 생각해 봤나요?」
🎯 무엇을 평가하는가
MCP 공격 표면에 대한 이해를 봅니다. 그는 이렇게 상기시키고 있습니다: 외부 데이터 소스를 하나 연결할 때마다 조종당할 입구가 하나 늘어납니다. 「큰 회사 서비스니까 괜찮겠지」라고 답하면 0점입니다.
🧭 답변 프레임워크
- 공급망 위험을 받으세요: Agent는 MCP가 반환하는 도구 설명을 신뢰하고, 악성 서버가 설명을 살짝 바꾸면 행동을 조종할 수 있습니다. Agent는 「파일 검색」도구를 쓰는 줄 알지만 실제 실행은 삭제입니다.
- 인젝션 위험을 받으세요: 서버 자체에 악의가 없어도 안전하지 않습니다. 전달하는 내용(예를 들어 가져온 웹페이지)에 인젝션 명령이 숨어 있을 수 있고, Agent가 이 데이터를 처리할 때 의도하지 않은 작업을 실행하도록 설득당할 수 있습니다.
- 거버넌스 액션을 제시하세요: 서드파티 SDK를 심사하듯 각 MCP 연동을 심사하고, 연결 수를 최소화하며, MCP가 반환하는 내용은 전부 신뢰할 수 없는 데이터로 취급합니다.
- 아키텍처 최후 안전망을 제시하세요: OAuth Token은 외부 Vault에 두고 프록시로 전달하며, 샌드박스 안에서는 자격증명을 얻을 수 없습니다. 네트워크 격리로 외부 유출을 제한합니다. 인젝션이 성공해도 공격자는 훔칠 것도, 내보낼 것도 없습니다.
⭐ 가산점능동적으로 「MCP 서버를 하나 더 연결할 때마다 인젝션 입구가 하나 늘어나니, 이 연동 목록을 먼저 절반 줄이겠습니다」라고 말하세요. PM이 스스로 요구사항을 줄이는 것은 기술 동료 눈에 최고 수준의 신뢰 신호입니다.
Q29상사
「대고객 계약에 우리 Agent가 그들의 프로덕션 DB를 영원히 건드리지 않는다고 쓰여 있고, 영업이 이미 서명했습니다. 말해 보세요. 이 『영원히』를 기술적으로 어떻게 보장하나요?」
🎯 무엇을 평가하는가
계약 언어를 아키텍처 언어로 번역하는 능력입니다. 「Prompt에 엄격히 제약하겠습니다」라고 답하면 이 건은 날아갑니다. 상사가 원하는 것은 계약 부속서에 넣을 수 있는 보장 메커니즘입니다.
🧭 답변 프레임워크
- 먼저 톤을 정하세요: 약속은 구조로 이행하고, 모델의 자각은 믿을 수 없습니다. 설계 목표는 모델이 인젝션 명령에 완전히 조종되어도 프로덕션 DB에 닿지 못하게 하는 것입니다.
- 3층 신뢰 제어를 제시하세요: 도구 수준, 고위험 작업은 매번 사람 승인. 세션 수준, 세션마다 인가 범위를 한정하고 종료 시 자동 회수. 전역 수준, 조직 정책에 프로덕션 DB는 영원히 접근할 수 없다고 고정하며, 어떤 세션 인가도 그것을 덮지 못합니다. 계약의 「영원히」가 대응하는 것이 바로 전역 층입니다.
- 네트워크 층 격리를 더하세요: Agent는 제한된 샌드박스에서 돌고, 네트워크 접근 범위가 통제되며, 프로덕션 DB 주소는 네트워크 층에서 이미 도달 불가여서 시도할 기회조차 없습니다.
- 감사 가능성을 제시하세요: Session 로그는 append-only로 매 단계 작업을 기록하고, 고객이 언제든 감사하러 올 수 있습니다. 약속에 증거를 더해야 서명할 수 있는 글입니다.
⭐ 가산점자격증명 고리를 능동적으로 보완하세요: 프로덕션 DB 연결 자격증명은 Agent 실행 환경에 아예 들어가지 않고 Vault 프록시로 관리합니다. 열쇠를 얻을 수 없는 문이어야 진짜로 잠긴 문입니다.
Q30면접관
「마지막 질문입니다. 이 챕터에 설계 패턴이 이렇게 많은데, 한 문장만 가져가게 한다면 어느 문장을 가져가겠습니까? 왜죠?」
🎯 무엇을 평가하는가
마무리 문제로, 추상화 능력과 엔지니어링 가치관을 봅니다. 용어 하나를 외우는 것보다 판단을 주는 것이 낫습니다. 상대방은 챕터 전체를 자신만의 엔지니어링 관점으로 압축한 뒤, 그것으로 배운 것을 다시 꿸 수 있는지를 보고 싶어합니다.
🧭 답변 프레임워크
- 그 문장을 주세요: Do the simplest thing that works. 정교한 패턴은 결국 모두 여기를 가리킵니다: 가장 단순한 방안에서 시작하고, 복잡도는 명확히 이득을 가져올 때만 더합니다.
- 그것으로 이 챕터를 한 번 꿰세요: Prompt 하나로 풀리면 Workflow를 올리지 말고, Workflow로 되면 Agent를 올리지 마세요. 컨텍스트는 최소 고신호 Token 집합을 찾고, 도구는 합칠 수 있으면 나누지 마세요.
- 두 번째 층 인식을 보완하세요: Agent 엔지니어링의 핵심은 상태 관리입니다. 어떤 정보가 언제, 어떤 형태로 창에 나타나는지, 이것이 엔지니어가 통제할 수 있는 전부입니다. 모델의 지능은 사전학습이 준 것이고, 통제할 수 없습니다.
- 시간 차원을 보완하세요: 모델은 강해지고, 엔지니어링은 단순해집니다. 재시도, 오류 수정, 포맷팅 같은 보조 로직은 모델이 발전하면 불필요해지고, 힘은 평가, 샌드박스, Session 같은 지속 아키텍처에 써야 합니다.
⭐ 가산점Claude Code의 교훈을 인용하며 마무리하세요: 엔지니어링 복잡도의 대부분은 컨텍스트를 관리하는 데 쓰였고, 모델을 똑똑하게 만드는 것은 오히려 부차적이었습니다. 이 문장이면 면접관이 당신을 기억하기에 충분합니다.
마지막 조언
이 챕터의 질문들은 대부분 실제 기술 설계 리뷰 현장에서 나온 것으로, 언제나 원하는 것은 판단력과 절충점입니다. 올바른 활용법은 여전히 소리 내어 한 번 말해보는 것입니다 — 동료, 친구, 또는 녹음기에 대고 말해보세요. 막히는 부분이 바로 안다고 생각했지만 실제로는 모르는 곳입니다. 관련 강좌 페이지를 클릭하여 보완하세요.