이렇게 당신을 테스트합니다
Grok Build 해부 · 30가지 핵심 질문
6장은 실제 소스 코드를 해부합니다. 이 장의 질문들이 가장 핵심적입니다. Coding Agent를 안다고 말한다면, 이 30문제가 리트머스 테스트입니다 — 먼저 소리 내어 답해 보고, 그다음 프레임워크를 확인하세요.
이 페이지 활용법
각 문제에는 질문자가 표시되어 있습니다. 이 장은 저수준 엔지니어링에 치중하며, 기술 동료의 비중이 가장 크고 그들의 질문도 가장 냉정합니다.
🎙 면접관진짜 이해하는지, 아니면 용어를 암기했는지 확인하려 합니다
👔 상사설명과 확약을 원합니다
🛠 기술 동료당신을 신뢰할 수 있는지 시험합니다
각 문제는 세 층으로 구성됩니다: 출제 의도 → 답변 프레임워크 → 가점 포인트. 답하지 못한 부분은 마지막의 강좌 페이지 링크를 클릭하여 복습하세요.
Q1기술 동료
"매일 Coding Agent 얘기를 하시는데, 루프 한 사이클에서 실제로 무슨 일이 일어나나요? PPT 버전은 됐습니다."
🎯 무엇을 평가하는가
Agent를 블랙박스로 취급하는지, 아니면 런타임을 진정으로 이해하는지 시험합니다. "LLM + 도구 루프 아닌가요?"처럼 한 문장으로 답하면 바로 탄로납니다. 질문자는 호출 체인을 따라가며 핵심 컴포넌트의 역할을 명확히 설명해 주기를 원합니다.
🧭 답변 프레임워크
- 진입점에서 시작: Grok Build를 예로 들면, 실제 진입점은 main()이며 실행 브랜치(headless, stdio, leader, 대화형 TUI)로 분기된 뒤 동일한 Agent 호스트로 수렴됩니다.
- 세 Actor의 역할 분담: SessionActor는 턴 편성(명령 수신·대기 중인 턴 시작·완료 알림 처리)을 담당하고, ChatStateActor는 대화 상태를 독점하며, SamplerActor는 스트리밍 모델 요청을 처리합니다.
- 격리 단위: 각 Session은 독립된 OS 스레드에서 자체 current-thread Tokio runtime과 LocalSet을 가지고 실행됩니다. 세션은 자연적으로 격리되어 한 세션이 멈춰도 다른 세션에 영향을 주지 않습니다.
- 종료 메커니즘: 사용자가 정지를 누르면 CancellationToken을 통한 협력적 종료가 이루어지고 각 Actor가 순차적으로 종료됩니다. 이것이 취소 경계입니다.
⭐ 가산점 "대화 상태는 ChatStateActor가 메시지 큐를 통해 직렬로 독점하므로 공유 락이 필요 없다"고 말할 수 있다면, 기술 동료는 당신이 진짜로 아키텍처를 읽었다는 것을 바로 알아차리고 협력 태도가 달라질 것입니다.
Q2면접관
"Coding Agent는 쉽게 수십 턴을 실행해 컨텍스트가 금방 꽉 찹니다. 프로덕션 수준 제품은 어떻게 버팁니까?"
🎯 무엇을 평가하는가
컨텍스트 예산에 대한 공학적 이해를 검증합니다. "히스토리를 압축하면 되죠"라고만 말하는 사람은 바로 탄로납니다. 질문자는 트리거 임계값, 판단 로직, 예산 제어 같은 실현 가능한 메커니즘을 듣고 싶어합니다 — 이것이 데모와 프로덕션의 분기점입니다.
🧭 답변 프레임워크
- 트리거 메커니즘부터 시작: Grok Build를 예로 들면, 기본적으로 컨텍스트 사용률이 85%에 달하면 자동 압축이 허용됩니다. 판단 공식은 used × 100 >= context_window × threshold_percent — 순수 정수 비교입니다.
- 압축 자체도 시간 제한이 필요: 단일 압축은 300초의 wall-clock 예산을 가집니다. 압축은 세션을 살리기 위한 것인데, 압축 자체가 시간을 초과하면 본말이 전도됩니다.
- 선택적 기능 설명: memory flush와 two-pass는 기본적으로 비활성화됩니다. two-pass를 활성화하면, 임계값에 근접할 때 백그라운드에서 투기적으로 히스토리 접두어를 요약하고, 공식 압축 시 그 요약과 최근 말미를 합쳐 최종 요약합니다.
- 한 단계 더 올라가기: 이 모두가 CompactionPolicy라는 하나의 명시적 설정 객체에 담겨 있으며, 임계값·압축 모델·예산이 모두 조정 가능합니다. 프로덕션 시스템은 정책을 설정으로 만들고, 데모는 코드에 하드코딩합니다.
⭐ 가산점 Token 사용량은 추정값이고, 임계값 비교는 오버플로 방지를 위해 포화 곱셈을 사용하며, 윈도우가 0일 때 바로 false를 반환한다고 지적하세요. 이런 에지 케이스 처리를 설명할 수 있다면 실제 구현을 읽었다는 증거이며, PM 중에서는 극히 드문 능력입니다.
Q3면접관
"Coding Agent의 도구 세트를 설계한다면, 수십 개의 도구를 어떻게 관리하겠습니까? 어떤 것은 바로 실행 가능하고, 어떤 것은 사용자 승인이 필요한가요?"
🎯 무엇을 평가하는가
도구 시스템 설계 역량을 검증합니다. "각 도구마다 권한을 하나씩 설정하면 되죠"라고 말하는 사람은 바로 탄로납니다 — 수십 개의 도구에는 그 방법이 통하지 않습니다. 질문자는 분류 체계, 기본 시맨틱, 계층적 제어라는 체계적 접근을 듣고 싶어합니다.
🧭 답변 프레임워크
- 분류 체계부터 시작: Grok Build는 ToolKind 열거형으로 도구에 시맨틱 카테고리를 부여합니다. 파일 읽기, 검색, 웹 스크래핑 등의 카테고리는 기본적으로 읽기 전용이며, 편집, 삭제, 명령 실행 등은 기본적으로 부작용이 있습니다.
- 기본값은 재정의 가능: is_read_only()는 카테고리 수준의 기본 시맨틱일 뿐이며, 개별 도구는 자체 메타데이터로 재정의할 수 있습니다 — 카테고리와 개체가 분리됩니다.
- 핵심 경계 명확히: 읽기 전용 카테고리가 "자동 실행"을 의미하지는 않습니다. 최종 승인은 명령 규칙, 샌드박스, Hook, 사용자 인터랙션 승인이라는 여러 계층을 거칩니다 — 카테고리는 의사결정의 첫 번째 입력일 뿐입니다.
- 등록 메커니즘 추가: 내장 도구는 정적 레지스트리를 사용하고, 외부 Toolset은 프로세스 레벨 Preset 등록을 사용하며, MCP 도구는 런타임에 동적으로 발견됩니다. 세 가지 소스가 단일 지점으로 수렴되어 관리 비용이 폭발하지 않습니다.
⭐ 가산점 Task를 반례로 드세요: 서브 태스크는 무해하게 들리지만, 소스 코드는 이를 비읽기 전용으로 표시합니다 — 자식 Agent가 쓰기 작업을 실행할 수 있기 때문입니다. 이런 경계 케이스를 설명할 수 있다면 분류 표를 실제로 검토했다는 증거입니다.
Q4기술 동료
"Agent의 기억이란 결국 채팅 기록을 파일에 저장해 두고 필요할 때 grep 하는 거 아닌가요?"
🎯 무엇을 평가하는가
도발적인 질문으로, 검색 엔지니어링에 대한 이해를 시험합니다. "비슷하죠"라고 동의하면 함정에 빠집니다. 질문자는 리콜 파이프라인, 폴백 전략, 랭킹 세부사항을 듣고 싶어합니다 — 이것들이 기억 시스템의 실용성을 결정합니다.
🧭 답변 프레임워크
- 전제 수정부터: 프로덕션급 기억은 검색 파이프라인입니다. Grok Build를 예로 들면, 쿼리 전에 더티 파일을 동기화합니다: watcher가 Markdown 변경을 모니터링하고 검색 시작 시 해당 인덱스를 재빌드하여 외부 수정이 누락되지 않도록 합니다.
- 이중 경로 리콜: FTS5 BM25 키워드 검색은 항상 사용 가능하며, 임베딩이 가능할 때 벡터 KNN(sqlite-vec)이 추가됩니다. 임베딩 실패 시 경고만 기록하고 자동으로 FTS-only로 폴백되어 검색이 정상적으로 반환됩니다.
- 랭킹에 세심함이 필요: 두 경로의 점수는 각각 정규화한 후 가중 합산되고, 시간 감쇠(session 기억은 반감기로 감쇠, global과 workspace는 상록으로 취급)·소스 가중치·접근 부스트가 곱해집니다.
- 선택적 다양성: MMR 재랭킹은 기본적으로 비활성화되며, 활성화 시 관련성과 스니펫 다양성으로 그리디 재랭킹을 수행한 후 max_results로 절단합니다.
⭐ 가산점 추가로 말하세요: "백그라운드에는 Dream 메커니즘도 있습니다 — 유휴 상태 게이팅으로 트리거되고, DreamLock으로 동시성을 방지하며, 백그라운드에서 기억을 정리해 다시 씁니다." 이는 기억 시스템에 읽기와 쓰기 유지보수 모두 있다는 것을 보여줍니다 — 완전한 폐쇄 루프를 보고 있는 것입니다.
Q5상사
"전사적으로 Coding Agent를 도입하겠다고요? 코드베이스를 삭제하거나 소스 코드가 유출되면 누가 책임을 집니까?"
🎯 무엇을 평가하는가
기대 관리와 메커니즘 이해를 검증합니다. "절대 안전합니다"라고 가슴을 치는 사람이 가장 위험하고, "샌드박스가 있습니다"만으로도 부족합니다. 질문자는 계층적 방어의 구체적인 방안과 솔직하게 한계를 인정할 용기가 있는지를 듣고 싶어합니다.
🧭 답변 프레임워크
- 결론부터 제시: 위험은 관리 가능합니다 — 핵심은 커널 수준 샌드박싱입니다. Grok Build에는 내장된 다섯 가지 Profile이 있습니다: workspace(기본), devbox, read-only, strict, off — 각각 파일 읽기/쓰기 및 서브프로세스 네트워크 기능 집합을 정의합니다.
- 메커니즘 설명: 제약은 OS 레벨에서 적용됩니다 — macOS는 Seatbelt, Linux는 Landlock을 사용합니다. 실제 경계는 파싱된 기능 집합으로 결정되며, Profile 이름은 방향 제시일 뿐입니다.
- 롤아웃 방안 제시: 역할별로 Profile을 할당하세요. 코드 리뷰에는 read-only, 고민감 저장소에는 strict, custom profile로 ~/.ssh 같은 디렉토리를 추가로 deny할 수도 있습니다. 프로젝트 설정은 동일 이름의 전역 정책을 몰래 재정의할 수 없습니다 — 보안 기준선은 관리자의 손에 있습니다.
- 솔직한 한계 인정: 플랫폼이 지원하지 않거나 적용에 실패하면, 샌드박스는 경고를 기록하고 계속 실행됩니다. 따라서 권한 승인과 Hook 감사를 추가하여 계층적 방어를 구성해야 합니다 — 단일 은총알은 없으며, 책임은 제도와 메커니즘을 통해 공동으로 집니다.
⭐ 가산점 두 계층을 명확히 구분하세요: Hook은 fail-open 방식이라 Hook 자체가 충돌해도 도구는 계속 실행됩니다 — 따라서 알림과 감사에만 적합합니다. 강제적인 보장은 반드시 권한 레이어와 샌드박스에 배치해야 합니다. 이 두 계층을 명확히 설명할 수 있는 사람은 매우 드뭅니다.
Q6기술 동료
"MCP Server 연동은 그냥 설정 두 줄 추가하면 되지 않나요? 왜 이걸 한 이터레이션으로 잡으신 거죠?"
🎯 무엇을 평가하는가
에코시스템 통합 공수에 대한 판단력을 역방향으로 시험합니다. "프로토콜만 연결되면 끝이라고" 생각하는 PM은 반드시 일정이 무너집니다. 질문자는 프로토콜 주변의 지저분한 작업들을 듣고 싶어합니다 — 구체적일수록 일정에 설득력이 생깁니다.
🧭 답변 프레임워크
- 역할 정렬부터: Grok Build는 MCP 클라이언트로, stdio와 Streamable HTTP 두 가지 전송 방식을 동시에 지원해야 하며, OAuth도 추가됩니다: 자격 증명은 로컬 JSON 파일에 저장되고, 파일 잠금과 원자적 쓰기로 다중 프로세스 충돌을 방지합니다.
- 네이밍과 충돌: 도구 등록명은 server__tool 형식으로, 이중 언더스코어가 정확히 한 번 나타납니다. 두 서버에 동일한 이름의 도구가 있을 때, 각각 다른 ToolId를 받아 모델 측에서 충돌이 없습니다.
- 가시성 라우팅: 도구가 많으면 모두 Prompt에 넣을 수 없습니다. 비활성화된 것, UI 전용, 모델 가시 세 경로로 처리하며, 스냅샷과 BM25 인덱스로 모델이 필요에 따라 도구를 검색할 수 있습니다.
- 재연결 복구: 상태 이벤트는 50ms 윈도우 내에 병합되고, stdio 재시작은 1초·4초·16초 백오프 방식으로 진행됩니다. client_id 가드레일로 이전 연결의 단절 이벤트가 새 연결을 실수로 삭제하는 것을 방지합니다.
⭐ 가산점 한 문장으로 마무리하세요: "MCP 통합의 공수는 프로토콜 주변에 집중되어 있으며, 네이밍·가시성·신원·상태 병합·복구 전략이 연결의 장기적 안정성을 결정합니다." 이것이 한 이터레이션을 잡는 이유이며, 기술 동료는 이를 듣고 자발적으로 세부 사항을 보완해 줄 것입니다.
Q7면접관
"Grok Build 소스 코드를 연구하셨다고요? 그럼 말해 보세요. xAI는 왜 Rust를 골랐습니까? 확정된 답을 주세요."
🎯 무엇을 평가하는가
이 문제에는 함정이 있습니다. "확정된 답"은 애초에 존재하지 않습니다. 질문자는 당신에게 증거 경계 인식이 있는지, 합리적인 설명을 공식 사실처럼 포장하는지를 봅니다. 입만 열면 xAI의 동기를 대변하는 사람은, 경쟁 제품 분석도 반드시 물을 탑니다.
🧭 답변 프레임워크
- 먼저 규칙을 세우세요: 결론을 "소스 코드 사실"과 "강의 추론" 두 가지 라벨로 나눕니다. 소스 코드가 증명하는 것: edition을 2024로 설정, Tokio 1에서 full feature 활성화, xai-grok-pager라는 네이티브 bin target, release-dist의 LTO와 panic 설정.
- 그다음 추론을 주세요: 네이티브 바이너리는 CLI와 런타임을 함께 배포하기 쉽고, 소유권과 Send 경계는 멀티스레드 세션 관리에 도움이 되며, 강한 타입은 복잡한 프로토콜과 상태 전환에 맞습니다. 이는 코드 형태에 기반한 설명이며, 추론임을 명시해야 합니다.
- 바로 깨세요: 선정 뒤의 조직 동기는 소스 코드에 쓰여 있지 않습니다. "xAI가 성능 때문에 Rust를 골랐다"는 말은 저장소 증거를 댈 수 없으니, 저는 말하지 않습니다.
- 한 단계 더 올라가기: 이 장의 대조표는 4단계 증거 등급을 씁니다: 소스 코드, 저장소 문서, 공식 공개 문서, 로컬 스냅샷 관찰. 증거가 부족한 칸은 빈칸으로 두고, 추측으로 메우지 않습니다.
⭐ 가산점 면접관이 원하는 것은 바로 3단계입니다. 압박 속에서도 "이 문제는 소스 코드가 답할 수 없습니다"라고 말할 용기가, 멋진 답을 지어내는 것보다 훨씬 값집니다. 이것이 PM의 증거 소양입니다.
Q8기술 동료
"Rust로 Agent를 짜서 무슨 이득이 있습니까? 컴파일에 반나절이고, 채용도 어렵습니다. 저라면 TypeScript로 2주면 대충 하나 만듭니다."
🎯 무엇을 평가하는가
당신이 유행을 따라 Rust를 띄우는지, 아니면 검증 가능한 엔지니어링 이득을 말할 수 있는지를 떠봅니다. 동시에 대가를 인정할 용기가 있는지도 봅니다. 칭찬만 하고 트레이드오프를 말하지 못하는 PM에게 기술 팀은 진심으로 협력하지 않습니다.
🧭 답변 프레임워크
- 먼저 인정하세요: 컴파일 시간, 라이프타임 제약, 학습 허들은 모두 진짜 대가입니다. 소스 코드 강의도 그렇게 표시했고, 고집할 필요는 없습니다.
- 검증 가능한 이득을 주세요: 각 Session은 독립 OS 스레드와 current-thread runtime으로 돌아가고, 소유권과 Send 경계 덕분에 멀티스레드 세션 상태를 사람의 자각에 맡기지 않습니다; enum과 Result가 Agent, Session, Sampler의 도메인 경계를 타입 위에 세웁니다.
- 확실한 예를 드세요: ALL_TOOL_KINDS에는 컴파일 타임 어서션이 있어, 길이와 ToolKind 열거형 개수가 맞지 않으면 바로 컴파일이 실패합니다. 도구 종류를 추가하면 권한 분기 결정을 다시 통과해야 하며, 이런 제약은 code review만으로는 막기 어렵습니다.
- 마무리: 네이티브 바이너리는 CLI와 런타임을 함께 배포하므로 사용자가 의존성을 설치할 필요가 없습니다. 2주 만에 대충 만든 것은 demo이고, 이 세트는 제품입니다.
⭐ 가산점 한 마디 보태세요. "멀티스레드가 반드시 더 빠르다" 같은 말은 저장소 증거가 부족하며, 표시해야 할 추론입니다. 기술 동료는 당신이 자기 입장의 증거 경계까지 지킨다는 것을 보면 태도가 바로 달라집니다.
Q9면접관
"같은 파일 읽기 도구인데, 코드에 구현이 여러 벌이나 있습니다. 이것도 아키텍처입니까? 버그 하나 고치려면 몇 번을 고쳐야 합니까?"
🎯 무엇을 평가하는가
멀티 프로토콜 호환의 코드 조직을 봅니다. 질문자는 일부러 "구현 패밀리"를 중복 코드라고 말하며, 이것이 네임스페이스 격리인지, 그리고 도구 하나가 정의에서 실행까지 가는 완전한 파이프라인을 설명할 수 있는지를 봅니다.
🧭 답변 프레임워크
- 먼저 이름을 바로잡으세요: 이는 프로토콜별로 나눈 구현 패밀리입니다. xai-grok-tools 안에 grok_build 메인 제품 패밀리, grok_build_concise 간결 패밀리, grok_build_hashline, codex와 opencode 호환 패밀리가 나란히 있고, memory, lsp, skills는 능력별로 모듈을 따로 쪼개며, namespace 열거형에는 런타임 외부 도구를 위한 MCP도 있습니다.
- 조립에는 파이프라인이 있습니다: ToolRegistryBuilder가 구현 선택과 파라미터 이름 변경을 맡고, finalize(config, context)가 FinalizedToolset을 만듭니다. 그 안에는 definitions, resources, dispatch가 들어 있습니다.
- 세션은 한 입구로 접속합니다: ToolBridge가 registry를 들고 도구 정의를 모델에 제공하며, 호출 결과는 ToolOutput으로 세션에 돌려줍니다. MCP 도구는 런타임에 register_mcp_tools로 같은 registry에 등록되어 내장 도구와 실행 채널을 공유합니다.
- 반론에 답하세요: 다른 harness와 호환하는 것은 구현 패밀리 하나를 바꾸는 설정 문제입니다. 모든 프로토콜이 코드 한 벌을 공유하면, 호환 로직이 도구마다 if 숲을 만들고, 그때야 버그 하나 고치려고 여러 번 고치게 됩니다.
⭐ 가산점 계층을 한 문장으로 정리하세요: 구현 패밀리는 여러 프로토콜의 코드 조직을 풀고, registry는 조합과 런타임 등록을 맡으며, ToolBridge는 세션을 연결합니다. 세 층이 각자 한 일을 맡으므로, 프로토콜 패밀리를 새로 추가해도 실행 체인은 한 줄도 건드리지 않습니다.
Q10상사
"연 구독료가 수만 위안인데, 차라리 우리가 Coding Agent를 직접 짜는 게 어때요? 평가해 보세요. 두 달이면 출시할 수 있습니까?"
🎯 무엇을 평가하는가
공수 판단과 기대 관리를 봅니다. 가슴을 치며 된다고 하거나 단칼에 거절하는 것 모두 불합격입니다. 상사가 원하는 것은 숫자, 차원, 대안이 있는 평가입니다.
🧭 답변 프레임워크
- 먼저 규모를 주세요: Grok Build는 Cargo Workspace 멤버만 79개이고, 그중 62개가 codegen 디렉터리에 있습니다. 이것이 xAI가 프로덕션급까지 만든 실제 체적입니다. 두 달 안에 나올 수 있는 것은 demo뿐입니다.
- 아홉 차원을 쪼개세요: 종강 워크벤치는 9차원 의사결정을 나열합니다: 진입점, 상태 동시성, 모델 스트림, 도구 계약, 컨텍스트 기억, 보안, 복구, 관측 가능성, 확장 생태계. 각 차원마다 계약, 장애 경로, 검증 방식을 내놓아야 합니다.
- 판단 기준을 주세요: 다섯 가지 하드 제약 중 두 가지를 자신에게 물으세요. 충돌 후에 설명 가능하게 복구할 수 있습니까? 민감 데이터의 저장 위치를 말할 수 있습니까? 답하지 못하면 출시하면 안 됩니다.
- 제안을 주세요: 먼저 성숙한 제품으로 반년을 운영하며 우리의 실제 권한, 감사, 복구 수요를 축적한 뒤, 어느 층을 자체 개발할지 평가하세요. 풀스택 자체 개발은 수지가 맞기 어렵고, 한 층의 자체 개발은 가치가 있을 수 있습니다.
⭐ 가산점 Grok Build 저장소가 Apache 2.0이라 연구와 빌드에 쓸 수 있다고 먼저 말하세요. 다만 내부 monorepo에서 정기적으로 단방향 동기화하고 외부 PR을 받지 않으니, 완성된 커뮤니티 기반으로 보지 마세요.
Q11면접관
"당신들 제품의 system prompt는 어떻게 관리합니까? 온라인에서 이상한 행동이 나오면, 어느 지시가 화를 불렀는지 어떻게 조사합니까?"
🎯 무엇을 평가하는가
Prompt의 엔지니어링 관리를 봅니다. "큰 문자열 템플릿 하나를 유지합니다"라고 답하는 사람은 아직 수공업 단계에 머물러 있습니다. 질문자는 구조화되고, 검사 가능하며, 재생 가능한 방안을 듣고 싶어합니다.
🧭 답변 프레임워크
- 구조화된 답을 주세요: Grok Build는 PromptContext 구조체로 렌더링 입력을 전부 저장하며, Serialize와 Deserialize derive가 있어 통째로 직렬화해 검사할 수 있습니다. 조사 대상이 데이터이면 추측 성분이 줄어듭니다.
- 필드를 세 그룹으로: 버전과 템플릿(version, prompt_mode, audience, build_timestamp_utc), 설정과 신원(agents_md_files, persona_summaries, role_instructions, memory_enabled), 사용자 런타임 환경(os_name, shell_path, working_directory, current_date).
- 렌더링 분담: TemplateOverride가 기본 템플릿을 정하고, ToolBridge가 도구 상태와 설명을 제공하며, TemplateRenderer가 각 section을 합성해 최종 system prompt를 출력합니다.
- 업데이트 경계: Agent 구축 후 소스 코드 주석은 "effectively immutable"이라고 하지만, finalize_prompt라는 명시적 진입점을 남겨 빌드 타임스탬프를 갱신한 뒤 다시 렌더합니다.
⭐ 가산점 "직렬화 가능한 렌더링 입력"이 Prompt 사고를 조사하는 핵심이라고 짚으세요. 어떤 세션의 Prompt든 구조화 데이터 한 부로 복원할 수 있어, 재생과 diff 모두 손잡이가 있습니다.
Q12면접관
"메인 세션용 Prompt 한 벌, 자식 Agent용 한 벌, 게다가 다른 집 도구 형식과도 호환해야 합니다. 템플릿 체계를 어떻게 설계해야 통제가 안 무너집니까?"
🎯 무엇을 평가하는가
멀티 템플릿의 제품화 방안을 봅니다. "템플릿 파일을 몇 개 더 쓰면 됩니다"라고 답하는 사람은 통제 불능을 생각하지 못한 것입니다. 질문자는 유한 열거에 비상구를 더한 수렴 설계를 듣고 싶어합니다.
🧭 답변 프레임워크
- 열거형을 주세요: Grok Build의 TemplateOverride는 변형이 셋뿐입니다: None, Codex, Custom(String). 기본값은 None입니다. 템플릿 선택이 열거 필드 하나로 수렴됩니다.
- None에도 두 벌이 있습니다: Primary 세션은 표준 base template을 쓰고, Subagent는 대응하는 컴팩트 템플릿을 써서 자식 세션의 Token을 아낍니다.
- Codex는 호환 슬롯입니다: 소스 코드 주석은 apply-patch profile 템플릿으로 정의하며, codex 구현 패밀리의 apply_patch, read_file, list_dir 같은 호환 구현과 맞춰 다른 도구 프로토콜을 서비스합니다.
- Custom은 비상구입니다: 호출 측이 완전한 템플릿 문자열을 직접 제공해, 열거형이 커버하지 못하는 장면을 덮습니다.
⭐ 가산점 템플릿과 도구는 세트로 전환된다고 깨세요. Codex 템플릿으로 바꾸는 동시에 도구도 대응하는 호환 구현으로 바꿉니다. Prompt 한쪽만 바꾸면, 호환 결과는 짜깁기 괴물이 됩니다.
Q13기술 동료
"문서대로 커스텀 toolset preset을 등록했는데, 현재 세션에서 아무리 해도 안 보입니다. 이 플랫폼 설계에 버그가 있는 거 아닙니까?"
🎯 무엇을 평가하는가
책임 전가형 질문입니다. 레지스트리의 타이밍 시맨틱과 가시성 설계를 아는지, 상대 눈의 "버그"를 이유가 분명한 설계로 설명할 수 있는지, 그리고 조사 경로를 내놓을 수 있는지를 봅니다.
🧭 답변 프레임워크
- 먼저 구조를 주세요: 레지스트리는 프로세스 레벨이며, OnceLock과 Mutex가 HashMap을 감싸고, "이름에서 빌더 함수와 가시성"으로의 매핑을 저장합니다. builder는 ToolServerConfig를 반환하는 fn() 함수 포인터이며, 해석 시점에야 호출되어 설정을 만듭니다.
- 타이밍을 설명하세요: 이미 해석된 설정은 다시 쓰이지 않습니다. 세션 설정 해석이 끝난 뒤에 등록하면 이 세션은 새 preset을 보지 못하고, 그 이후 새로 해석된 설정만 찾습니다. 소스 코드 주석은 첫 해석 전에 등록을 마치라고 분명히 권합니다.
- 가시성을 확인하세요: register_toolset_preset이 등록하는 것은 Public이라 preset_names 공개 열거에 들어갑니다. register_internal_toolset_preset은 Internal이라 이름으로만 해석되고 열거에는 보이지 않습니다. 열거로 Internal preset을 검증하면 "등록이 안 됐다"고 오판합니다.
- 결론을 주세요: 이는 시작 일관성 설계입니다. 늦은 등록이 이미 해석된 세션 설정을 몰래 바꿀 수 있다면, 그때가 진짜 버그입니다.
⭐ 가산점 조사 요령을 바로 주세요: 먼저 어느 등록 함수를 호출했는지 확인하고, 등록이 설정 해석 전인지 후인지를 확인하세요. 열에 아홉은 이 두 곳에서 납니다. 기술 동료는 "당신이 나보다 더 잘 안다"는 답변을 가장 좋아합니다.
이 강의 페이지로 답변을 구성하세요 →
Toolset Preset 레지스트리
Q14면접관
"도구마다 파라미터 이름이 제각각입니다. file_path, path, directory가 섞여 있습니다. 도구를 가로지르는 표시와 데이터 분석을 하려면 어떻게 합니까?"
🎯 무엇을 평가하는가
정규화 계약을 설계하는 능력을 봅니다. "매핑 표를 하나 쓰면 됩니다"는 시작일 뿐입니다. 질문자는 안정 투영과 원본 데이터가 어떻게 역할을 나누는지, 그리고 계약이 어떻게 진화하는지를 듣고 싶어합니다.
🧭 답변 프레임워크
- 방안을 주세요: Grok Build는 소수의 안정 시맨틱을 x.ai/tool 메타데이터로 투영합니다. canonical fields는 여덟 개뿐입니다: path, offset, limit, command, description, cwd, directory, pattern.
- 계약을 주세요: CanonicalToolMeta는 일곱 필드입니다: version, name, kind, namespace, label, read_only, input. TOOL_META_VERSION은 숫자 1입니다. 표시, 텔레메트리, 크로스 도구 분석이 이 어휘를 공유합니다.
- 경계를 말하세요: input은 투영이라 필드가 빠지거나 통째로 생략될 수 있습니다. grep flags, replace_all 같은 비공유 필드는 버려지고, 편집 전후 텍스트 같은 큰 필드는 투영에 넣지 않으며, 완전한 데이터는 raw_input에 남습니다.
- 트레이드오프를 말하세요: 투영 층은 안정과 가벼움을 추구하므로, 필드를 줄이더라도 시맨틱이 도구를 가로질러 같게 만듭니다. 전체가 필요하면 raw_input으로 돌아가 가져옵니다.
⭐ 가산점 version 필드는 계약 진화를 위한 문입니다. 오늘은 1이고, 필드 시맨틱이 나중에 바뀌면 소비 측이 버전별로 나눠 처리할 수 있습니다. 이는 데이터 계약의 기본기이며, 말하는 순간 차원 차이로 압도합니다.
Q15면접관
"85%가 되어야 압축이 트리거됩니다. 한 턴의 도구 출력이 컨텍스트를 바로 터뜨리면요? 예산 메커니즘은 무엇으로 최후를 막습니까?"
🎯 무엇을 평가하는가
임계값 너머의 경계 사고를 봅니다. 85%라는 숫자만 기억하는 사람은 이 문제에 답하지 못합니다. 질문자는 여유 공간, 추정 출처, 방어적 세부사항을 듣고 싶어합니다.
🧭 답변 프레임워크
- 먼저 프리미티브 셋을 주세요: xai-token-estimation은 usage_percentage(total이 0이면 0을 반환, 결과는 100에서 상한), exceeds_threshold(정수 교차 곱, used × 100 >= window × percent, 등호에서도 트리거), exceeds_threshold_with_headroom을 제공합니다.
- headroom이 최후 방어입니다: 퍼센트 임계값 앞에 고정 Token 공간을 미리 남겨 둡니다. 윈도우 100,000, 임계값 85%, headroom 4,000이면 트리거 지점이 85,000에서 81,000으로 앞당겨져 큰 출력에 버퍼를 줍니다.
- 추정 출처는 두 갈래입니다: 요청 전에는 로컬 대략 추정으로 UTF-8 바이트 수를 4로 나누고, 저해상도 이미지 한 장은 고정 765 Token입니다. 요청 완료 후에는 서버 usage로 보정합니다. 퍼센트 함수는 출처를 따지지 않고, 호출 측이 넘긴 숫자만 계산합니다.
- 방어적 세부사항: 곱셈은 포화 곱셈으로 오버플로를 막고, headroom 뺄셈은 saturating_sub를 쓰며, 윈도우가 0이면 예외 없이 false를 반환합니다.
⭐ 가산점 그 자리에서 손으로 계산하세요. 윈도우 128,000, 임계값 85%, headroom이 없으면 가장 빨라야 108,800에서 트리거되고, headroom 4,000이면 104,800으로 앞당겨집니다. 계산이 나오면 질문자는 당신이 이 공식을 진짜 안다고 믿습니다.
Q16면접관
"Agent의 장기 기억은 쌓일수록 지저분해집니다. 언제 정리할 생각입니까? 스케줄 작업을 만들어 한밤중에 한 바퀴 돌릴 겁니까?"
🎯 무엇을 평가하는가
백그라운드 유지보수 작업의 엔지니어링 설계를 봅니다: 트리거 조건, 동시성 제어, 멱등, 실패 복구. "스케줄 작업으로 한 바퀴"는 가장 쉽게 사고 나는 답입니다.
🧭 답변 프레임워크
- 트리거를 정확하게: Grok Build의 Dream은 최근 session 로그와 MEMORY.md를 합쳐 장기 기억으로 만듭니다. 진입점은 셋입니다: 세션 종료, /dream 수동 명령, 선택적 주기 검사. check_interval_secs 기본값은 None이라 주기 검사는 기본으로 켜지지 않으며, "유휴면 반드시 자동 실행"이라고 말하면 안 됩니다.
- 문 세 개: enabled 기본값은 true이지만 자식 Agent 세션은 바로 건너뜁니다. min_hours 기본값은 4이며 락 파일 mtime으로 마지막 성공 시각을 기록합니다. min_sessions 기본값은 3이며 마지막 정리 이후 수정된 session 파일을 세고 현재 세션은 제외합니다.
- 동시성과 예산: DreamLock은 .dream-lock에 PID를 저장하는 best-effort 락이며, 소스 코드 주석은 엄격한 상호 배제를 보장하지 않는다고 명시하므로 정리 과정은 중복을 견뎌야 합니다. 입력은 32K에서 자르고, 모델 호출은 30분 타임아웃입니다.
- 실패 복구: 모델이 빈 값을 반환하거나 Markdown 제목이 없으면 쓰지도 지우지도 않습니다. MEMORY.md 쓰기에 실패하면 rollback으로 옛 락 상태를 복구하고, 쓰기에 성공한 뒤에야 session을 정리하며, 5분 안에 아직 활성인 파일은 건너뜁니다. 인덱스는 진짜 지운 경로만 제거합니다.
⭐ 가산점 "성공 경계가 정리 경계를 결정한다"를 한 문장으로 정리하세요. 쓰기 성공을 확인하기 전에는 원본 session을 하나도 지우지 않아, 실패 후에도 언제든 다시 할 수 있습니다. 이는 모든 백그라운드 정리 작업의 공통 설계 기준입니다.
Q17상사
"지난주에 Agent에게 돌린 그 리팩터가 중간에 끊겼습니다. 다시 하면 또 돈과 시간입니다. 이어서 하면 안 됩니까?"
🎯 무엇을 평가하는가
복구 메커니즘에 대한 제품 이해와 기대 관리를 봅니다. 상사가 원하는 것은 "이어받을 수 있는지, 어떻게 이어받는지, 어떤 경우 불가능한지" 세 단락입니다. "되기는 할 겁니다"라고 모호하게 말하면, 다음에 사고가 나도 당신이 책임을 집니다.
🧭 답변 프레임워크
- 먼저 결론을 주세요: 이어받을 수 있습니다. 자식 Agent는 완료된 작업에서 복구를 지원하며, ContextSource::Resumed가 원본 transcript와 도구 상태를 복사하고, 반쯤 고친 worktree를 우선 재사용합니다. 디렉터리가 지워져도 괜찮습니다. snapshot_ref가 있으면 지속 git ref에서 다시 만들 수 있습니다.
- 신원 보호를 말하세요: 복구에는 검증이 있어 subagent_type이 원래와 같아야 하고, Persona를 명시하면 그것도 같아야 합니다. 모델은 원래 모델로 바로 pin되며, 중간에 모델을 바꾸라는 요청은 소프트하게 무시되어 컨텍스트가 어긋나지 않습니다.
- 이어받을 수 없는 경우를 말하세요: 원본 transcript가 목표 모델 컨텍스트 윈도우의 80%를 넘으면 복구를 거부합니다. transcript 복사 실패도 실패 종료되며, 시스템이 복구한 척하는 세션을 주지 않습니다.
- 기대를 관리하세요: plan 상태와 신호는 복사 범위에 없어, 이어받은 뒤 계획은 다시 확인해야 합니다. 이는 신뢰할 수 있는 재개이지, 끊김 없는 이어보기가 아닙니다.
⭐ 가산점 80% 상한의 의도를 설명하세요. 복구해서 계속 일해야 하는데 컨텍스트가 처음부터 거의 가득이면, 두 턴 만에 또 압축해야 해서 경험이 오히려 나빠집니다. 거부는 작업 품질을 지키는 것입니다.
이 강의 페이지로 답변을 구성하세요 →
자식 Agent 네 가지 격리 차원
Q18면접관
"자식 Agent의 격리는 몇 단계입니까? 낮음, 중간, 높음?"
🎯 무엇을 평가하는가
함정 문제입니다. "몇 단계입니까"를 따라가면 집니다. 질문자는 당신이 직교하는 차원을 하나의 축으로 뭉개는지를 봅니다. 소스 코드를 진짜 읽은 사람은 질문 자체부터 바로잡습니다.
🧭 답변 프레임워크
- 먼저 모델을 바로잡으세요: 격리는 네 개의 직교 차원이며, "낮음·중간·높음" 축 하나로는 담을 수 없습니다. 컨텍스트 출처, 신원 연속성, 작업 디렉터리, 파일 변경 공간을 나눠 판단해야 합니다.
- 하나씩 열거하세요: 컨텍스트는 ContextSource의 New 또는 Resumed입니다. 변경 공간은 SubagentIsolationMode의 None 또는 Worktree이며, 열거형에 "sandbox"라는 멤버는 없습니다. 작업 디렉터리는 worktree, override, 부모 디렉터리 우선순위로 해석합니다.
- 조합 반례를 드세요: Resumed에 None은 완전히 합법이며, 컨텍스트는 상속하되 부모 워크스페이스를 씁니다. New라고 해서 독립 파일 공간이 나오지도 않으며, 새 세션은 기본으로 부모 cwd에서 파일을 고칩니다.
- 경계를 보완하세요: 공개 열거형은 New와 Resumed뿐이며, shell 내부에는 부모 세션에서 컨텍스트를 미러링하는 Forked 분기가 따로 있습니다. 이를 공개 열거 멤버라고 말하면 안 됩니다.
⭐ 가산점 가장 흔한 혼동을 깨세요. None이 묘사하는 것은 파일 워크스페이스이며 대화 역사와 무관합니다. None 모드의 자식 Agent도 컨텍스트 윈도우는 여전히 독립입니다. 이 두 가지를 가릴 수 있는 사람은 매우 드뭅니다.
Q19면접관
"spawn 파라미터, role 기본값, persona 기본값이 모두 모델을 설정할 수 있습니다. 마지막에는 누구 말을 듣습니까?"
🎯 무엇을 평가하는가
설정 병합에 대한 정확한 이해를 봅니다. 모호한 전체 우선순위 정렬을 내놓는 순간 탄로납니다. 실제 설계는 필드별 캐스케이드이며, 그 필드가 해당 구조에 존재하는지도 먼저 확인해야 합니다.
🧭 답변 프레임워크
- 캐스케이드 순서를 주세요: 필드별 캐스케이드입니다. spawn의 명시적 override가 가장 높고, 그다음 role 기본값, 그다음 persona 기본값이며, 모두 없으면 None을 남겨 부모가 상속합니다.
- "필드별"을 강조하세요: 이 우선순위는 필드마다 따로 갑니다. model은 spawn을 듣는 동시에 reasoning_effort는 persona에서 올 수 있습니다. 필드가 존재하는지도 먼저 물어야 합니다. persona는 capability_mode를 제공하지 않습니다.
- 결과 구조를 주세요: 해석 산물은 EffectiveRuntimeConfig이며, 필드에는 model, reasoning_effort, capability_mode, persona, persona_instructions, role_prompt, isolation 등이 있습니다. 소스 코드에는 temperature, max_tokens, tools 필드가 없습니다.
- fallback을 보완하세요: 해석이 끝난 뒤 shell에 한 층이 더 있습니다. reasoning_effort가 여전히 비어 있으면 AgentDefinition.effort를 읽습니다. model의 완전한 순서는 runtime override, per-agent pin, AgentDefinition.model, 부모 모델 상속입니다.
⭐ 가산점 방법론을 말로 꺼내세요. "필드별 우선순위를 묻기 전에, 필드가 존재하는지를 먼저 묻는다." 많은 사람이 전체 정렬 한 벌을 외웠다가, capability가 어디서 오는지 되물으면 그 자리에서 탄로납니다.
이 강의 페이지로 답변을 구성하세요 →
AgentDefinition과 Persona 병합
Q20기술 동료
"위험한 명령을 막으려고 PreToolUse hook을 넣었는데, 어제 스크립트가 스스로 죽었습니다. 그런데 명령은 그대로 돌았습니다! 이 안전 메커니즘은 장식입니까?"
🎯 무엇을 평가하는가
fail-open 시맨틱을 봅니다. 이것이 의도된 트레이드오프임을 설명하고, 차단의 정확한 조건을 말하며, 강제 보장은 어느 층에 두어야 하는지를 내놓아야 합니다. 서둘러 사과하는 PM은 시스템을 모른다고 판정됩니다.
🧭 답변 프레임워크
- 먼저 시맨틱을 말하세요: 이는 설계된 fail-open입니다. Hook이 충돌하거나, 타임아웃되거나, 종료 코드가 0도 2도 아니거나, stdout이 무효이면 dispatcher는 경고를 기록한 뒤 통과시킵니다. 소스 코드 주석은 Hook 장애가 도구 가용성을 깨면 안 된다고 분명히 요구합니다.
- 차단 경로는 두 갈래뿐입니다: 유효한 JSON을 반환하고 decision이 deny이거나, 유효한 JSON은 없지만 종료 코드가 2인 경우입니다. JSON이 우선임에 주의하세요. 유효한 JSON이 allow를 썼다면 종료 코드가 2여도 막지 못하고, 충돌 경고만 한 줄 기록합니다.
- 올바른 용법을 주세요: Hook은 알림, 감사, 복구 가능한 사전 검사에 맞습니다. 강제 보장이 필요하면 규칙은 권한 층에 두고(deny > ask > allow), 시스템 경계는 샌드박스에 두세요. 이 두 층은 fail-open을 쓰지 않습니다.
- 조사를 도우세요: 15개 이벤트 중 is_blocking이 참인 것은 PreToolUse뿐입니다. matcher는 정규식에 호환 별칭을 더하며, 설정에 Bash를 쓰면 내부 이름 run_terminal_command에 맞습니다. matcher가 진짜 맞았는지를 먼저 확인하세요.
⭐ 가산점 한 마디 되묻으세요. "Hook 장애 때 모든 도구를 차단하면, 잘못 쓴 스크립트 하나가 전사 Agent를 멈출 수 있습니다. 어느 장애 모드를 고르겠습니까." 양쪽 리스크를 테이블에 올리면, 상대는 이것이 트레이드오프임을 스스로 이해합니다.
Q21면접관
"Persona 파일을 읽지 못하면 spawn이 바로 중단됩니다. role의 prompt 파일을 읽지 못하면 계속 돌아갑니다. 왜 다르게 대합니까?"
🎯 무엇을 평가하는가
초세부 문제입니다. 실패 시맨틱의 차이 설계를 읽었는지를 봅니다. 기능 목록만 외운 사람은 이 두 경로가 있는지도 모릅니다. 설계 이유를 말할 수 있어야 진짜 꿰뚫은 것입니다.
🧭 답변 프레임워크
- 사실을 주세요: Persona를 요청한 뒤 찾지 못하거나, 내용이 비어 있거나, 파일 읽기에 실패하면 persona_error가 기록되고, spawn 측은 오류를 보고 생성을 바로 중단하며 실패 종료합니다.
- role과 대조하세요: role의 prompt_file 읽기 실패는 role_prompt_warning만 만들고, model, reasoning, capability, isolation은 그대로 해석되며 소프트 다운그레이드입니다.
- 설계 이유를 말하세요: Persona는 사용자가 명시적으로 지명한 행동 계약이며 instructions와 입출력 계약을 갖습니다. 조용히 버리면 다른 페르소나로 일하게 되어 리스크가 큽니다. role prompt는 타입 층의 강화 지시이며, 없어도 자식 Agent는 그 타입 그대로입니다.
- 병합 세부사항을 보완하세요: Persona의 inline instructions는 파일 내용 앞에 합쳐지고, 최종적으로 persona 블록으로 Prompt에 들어갑니다.
⭐ 가산점 이식 가능한 방법론으로 추상화하세요. 실패 시맨틱은 사용자 의도 강도를 따라가야 합니다. 명시적으로 지정한 것의 실패는 소리를 내야 하고, 기본 폴백의 실패는 부드럽게 가도 됩니다. 이 한 문장은 당신 제품의 어떤 리뷰에도 쓸 수 있습니다.
이 강의 페이지로 답변을 구성하세요 →
AgentDefinition과 Persona 병합
Q22면접관
"메인 세션 아래에 자식 Agent 열몇 개를 달아 병렬로 돌립니다. 그들의 생애와 결과는 어떻게 관리합니까?"
🎯 무엇을 평가하는가
멀티 Agent 조율 층의 구체적 메커니즘을 봅니다. "여러 개 열면 됩니다"는 소비자 관점입니다. 질문자는 라이프사이클 등록, 결과 대기, 취소 경로라는 생산자 관점을 듣고 싶어합니다.
🧭 답변 프레임워크
- 컴포넌트를 주세요: Grok Build에는 실제 조율 컴포넌트 SubagentCoordinator가 있습니다. start_subagent_coordinator는 drain task를 한 번만 시작하고, 모든 조율 이벤트는 한곳으로 수렴됩니다.
- 이벤트 면을 주세요: SubagentEvent에는 Spawn, Query, Cancel, ListActive, Completions, Outstanding이 있습니다. 각 Spawn은 각자의 spawn_local 비동기 태스크로 handle_subagent_request를 호출하고, 코디네이터는 pending, active, completed 세 상태를 등록합니다.
- 결과와 취소: Query는 즉시 스냅샷을 가져올 수도 있고, block wait slot을 등록해 완료를 기다릴 수도 있습니다. Completions는 알림 대기 중인 완료 항목을 drain하고 suppress_ids로 필터합니다. Cancel은 subagent ID 또는 parent prompt ID를 지원하며, 만료된 completed 기록은 도태됩니다.
- 조직 전략으로 올리세요: 병렬 능력은 비동기 태스크에서 옵니다. 단일 Agent, 메인 세션에 subagents를 더한 형태, 다중 멤버 공유 작업 중 무엇을 고를지는 태스크 그래프를 봅니다: 병렬 이득, 의존 관계, 컨텍스트 복사 비용, 파일 충돌, 요약 책임.
⭐ 가산점 패턴을 정리하세요. "코디네이터는 이벤트 구동의 단일 수렴점이다." 생애 상태의 owner는 하나뿐이고, 조회와 취소는 모두 메시지로 가므로, 여러 곳에서 상태를 바꾸는 레이스 컨디션을 뿌리부터 피합니다.
Q23기술 동료
"권한 검사는 첫 명령만 보면 되는 거 아닙니까? 제가 ls && rm -rf를 한 방에 쓰면, 그 세트가 막습니까?"
🎯 무엇을 평가하는가
반 농담 반 도발입니다. 명령 파싱의 깊이를 봅니다. 구간별로 검사한다는 것을 아는 사람도 많지 않고, 파서와 보수적 폴백을 말할 수 있는 사람은 더 적습니다. 잘 답하면 이후로는 이런 문제로 당신을 놀리지 않습니다.
🧭 답변 프레임워크
- 정면으로 받으세요: 막습니다. Grok Build는 tree-sitter-bash로 안전하게 분해할 수 있는 스크립트를 plain command 하나씩으로 쪼개 &&, ||, 세미콜론, 파이프를 인식합니다. setup이 아닌 각 구간은 안전 명령, 정책 또는 인가 검사를 독립적으로 통과해야 하므로, ls를 통과시켜도 뒤의 rm은 구하지 못합니다.
- wrapper도 계산합니다: 파싱은 래퍼 층을 재귀적으로 벗겨 실제 명령을 얻으며, 위험 접두 명단에 rm, chmod, chown, kill, git push가 있습니다.
- 분해할 수 없으면 보수적으로: 명령 치환, 복잡한 제어 흐름처럼 신뢰 가능하게 분해할 수 없는 스크립트는 통째로 보수적 prompt에 들어가, 사용자가 완전한 스크립트를 한 번 확인합니다.
- 후속 수단을 보완하세요: 실행을 승인해도 샌드박스의 능력 집합은 남아 있습니다. read-only profile에서는 workspace가 쓸 수 없어, rm이 운영체제 층에 가도 쓰지 못합니다.
⭐ 가산점 이 설계에서 가장 쉽게 저평가되는 지점을 짚으세요. 스크립트 구조로 권한 결정을 합니다. 정규식으로 명령 문자열을 매칭하는 방안은 shell 문법 앞에서 구멍이 가득이고, 구문 트리 파싱이 정답입니다.
Q24면접관
"사용자가 rm을 한 번 승인하면, 이 세션 이후로는 파일을 마음대로 지울 수 있습니까? 당신들의 인가 모델을 완전히 설명해 주세요."
🎯 무엇을 평가하는가
인가 체인 전체와 두 층 경계를 봅니다. "팝업 확인"만 답하는 사람의 보안 이해는 UI 층에 머물러 있습니다. 질문자는 의사결정 입력, 규칙 우선순위, 샌드박스 최후 방어가 어떻게 겹치는지를 듣고 싶어합니다.
🧭 답변 프레임워크
- 질문 자체에 먼저 답하세요: 승인은 이번 요청만 통과시킵니다. 인가 결정의 입력은 AccessKind이며, 도구 입력은 Read, Edit, Bash, MCPTool처럼 구체 경로와 명령을 담은 접근 의도로 해석되어 ToolKind보다 더 세밀합니다.
- 체인을 한 바퀴 도세요: plan gate가 먼저 편집을 막고, PreToolUse hook이 명시적으로 deny할 수 있으며, 그다음 permission manager가 병합된 규칙을 평가합니다. 규칙 우선순위는 deny > ask > allow이며, 설정 출처 순서와 무관합니다.
- 결정 패스트 패스는 순서가 있습니다: 관리 정책의 deny가 먼저 숏서킷되고, 그다음 yolo pin, session grants, Auto 판정, sandbox Bash auto, 읽기 전용 안전 항목 차례이며, 결론이 없을 때만 팝업으로 사용자에게 묻습니다.
- 두 번째 층을 보완하세요: 권한 층의 Allow는 운영체제 능력을 넓히지 않습니다. 샌드박스가 active이면 프로세스는 여전히 능력 집합과 서브프로세스 네트워크 정책에 묶입니다. 권한 층은 "시도할 수 있는지"를 정하고, 샌드박스 층은 "할 수 있는 것"을 제한하며, 겹쳐야 완전한 경계입니다.
⭐ 가산점 널리 퍼진 말을 먼저 바로잡으세요. "샌드박스 안 쓰기 작업은 전부 자동 승인"은 틀렸습니다. sandbox fast path는 Bash만 검사하며, policy_forced_prompt와 auto_forced_prompt 제약도 받습니다.
Q25면접관
"보안 팀은 전사 샌드박스 정책을 통일하고 싶어하고, 프로젝트 팀은 규칙을 직접 더하고 싶어합니다. 설정 시스템을 어떻게 설계해야 싸우지 않습니까?"
🎯 무엇을 평가하는가
설정 계층 거버넌스를 봅니다: 누가 무엇을 바꿀 수 있는지, 충돌 시 누구 말을 듣는지, 프로젝트 팀이 보안 기준선을 몰래 완화하지 못하게 하는 방법. 이는 엔터프라이즈 제품이 피할 수 없는 설계 문제입니다.
🧭 답변 프레임워크
- 병합 규칙을 주세요: Grok Build는 먼저 전역 ~/.grok/sandbox.toml을 읽고, 그다음 프로젝트 .grok/sandbox.toml을 읽으며, 병합은 entry.or_insert를 씁니다. 프로젝트는 profile 이름만 새로 추가할 수 있고, 전역과 같은 이름의 profile을 선언해도 전역 정의가 유지되어 프로젝트가 바꿀 수 없습니다.
- 확장 방식을 주세요: 프로젝트 커스텀은 custom profile로 가며, 기본은 workspace에서 출발하고, extends는 workspace, devbox, read-only, strict 네 내장 베이스만 고를 수 있으며, read_only, read_write, deny를 베이스 위에 추가합니다.
- 금지 두 가지를 주세요: off와 none을 extends할 수 없고, 다른 custom을 extends할 수도 없습니다. 체인 상속을 막아 보안 감사가 한 줄로 최종 능력을 볼 수 있게 합니다.
- 기본값을 상기시키세요: custom이 서브프로세스 네트워크를 제한하려면 restrict_network를 true로 명시해야 하며, 베이스에서 당연히 상속된다고 여기면 안 됩니다.
⭐ 가산점 entry.or_insert 한 줄이 곧 거버넌스 모델이라고 짚으세요. 먼저 로드한 쪽이 이깁니다. "전역 우선"을 병합 시맨틱으로 만드는 것이 승인 제도로 만드는 것보다 훨씬 믿을 만하며, 프로세스를 메커니즘으로 대체한 모범입니다.
이 강의 페이지로 답변을 구성하세요 →
다섯 가지 샌드박스 Profile
Q26상사
"팀이 플러그인 마켓에서 커뮤니티 플러그인을 잔뜩 깔아 효율을 내고 싶어합니다. 안에 악성이 숨어 우리 코드를 몰래 빼가면 어떻게 합니까?"
🎯 무엇을 평가하는가
플러그인 생태계의 신뢰 설계를 봅니다. "깔기 전에 심사하면 됩니다"만 말하는 사람은 되묻기를 버티지 못합니다. 상사는 시스템 층에 게이트가 몇 개인지, 그리고 게이트가 실패했을 때 무엇이 일어나는지를 듣고 싶어합니다.
🧭 답변 프레임워크
- 문 셋을 주세요: 설치했다고 실행되는 것은 아닙니다. 첫 번째는 출처와 경로입니다. MarketplaceRelativePath는 절대 경로와 상위 디렉터리 탈출을 거부하고, 원격 항목은 git ref 또는 SHA로 내용을 잠글 수 있습니다. 두 번째는 활성화 상태입니다. 프로젝트와 사용자 범위에서 발견한 플러그인은 기본으로 disabled 목록에 들어갑니다. 세 번째는 실행 신뢰입니다. 플러그인 루트 디렉터리별로 인가하며, 기록은 ~/.grok/trusted-plugins에 씁니다.
- 미신뢰의 대우를 말하세요: skills와 agents는 메타데이터만 드러내고, hooks는 로드하지 않으며, MCP server는 시작하지 않고, scripts는 실행하지 않습니다. 가장 위험한 실행면이 전부 눌립니다.
- 실패 시맨틱을 주세요: 플러그인 루트 디렉터리 canonicalize 실패는 바로 미신뢰로 처리하는 실패 종료이며, 경로에 문제가 있어도 잘못 통과시키지 않습니다.
- 프로세스에 적용하세요: 고위험 플러그인은 먼저 read-only 샌드박스에서 내용을 검토한 뒤 신뢰를 주고, 원격 설치는 SHA로 버전을 고정해 업스트림이 몰래 패키지를 바꾸지 못하게 합니다.
⭐ 가산점 상사가 기억할 한 문장 요약을 주세요. 발견, 설치, 실행은 세 층이고, 층마다 독립 허들이 있습니다. 악성 플러그인은 세 관문을 연속으로 넘어야 하고, 세 번째 관문은 기본이 닫혀 있습니다.
Q27면접관
"사용자가 MCP 도구 수백 개를 붙였습니다. 전부 Prompt에 넣으면 컨텍스트가 바로 터집니다. 어떻게 설계합니까?"
🎯 무엇을 평가하는가
도구 규모화 방안을 봅니다. "스위치를 만들어 사용자가 덜 켜게 하면 됩니다"는 사용자에게 책임을 넘기는 것입니다. 질문자는 지연 발견이라는 시스템 해법을 듣고 싶어합니다.
🧭 답변 프레임워크
- 핵심 생각을 주세요: 도구 메타데이터는 ToolMetadataSnapshot(tools, servers, mcp_initialized 세 필드)에 들어가 BM25 인덱스를 갖추며, 수백 개 정의가 Prompt에 상주하지 않게 합니다.
- 안정 진입점 둘을 주세요: 모델 측에는 SearchTool과 UseTool만 노출합니다. SearchTool은 키워드로 검색하며 파라미터는 query와 limit(기본 5)이고, 결과는 server별로 그룹되어 설명과 input_schema를 답니다. UseTool은 tool_name과 tool_input을 받아, 발견한 schema에 따라 분배 실행합니다.
- 안정성 이득을 말하세요: 모델의 도구 목록이 턴을 가로질러 바뀌지 않아, 수백 개 도구의 증감이 컨텍스트를 쓸어버리지 않고 Prompt 캐시에도 친화적입니다.
- 분배 세부사항을 보완하세요: UseTool이 적합한 도구 이름을 받으면 InnerDispatch 또는 managed gateway로 MCP를 호출합니다. 모델의 용법은 먼저 input_schema를 검색한 뒤 schema에 맞춰 tool_input을 만들고 호출하는 것이며, 발견과 실행이 완전히 분리됩니다.
⭐ 가산점 mcp_initialized라는 작은 필드를 꺼내세요. 능력 발견이 끝나지 않았을 때 검색 층은 "검색 결과 없음"과 "아직 준비되지 않음"이 다른 일임을 알아, 모델에 잘못된 빈 결과를 주지 않습니다. 세부사항이 이 층까지 가면 더 이상 의심하지 않습니다.
Q28상사
"xAI가 소스 코드를 공개했으니, 우리가 fork해서 내부 버전으로 고치면 처음부터 짤 필요가 없습니다. 됩니까?"
🎯 무엇을 평가하는가
오픈소스 거버넌스 경계에 대한 판단을 봅니다. license만 보고 릴리스 모드를 보지 않는 사람은 회사를 함정에 빠뜨립니다. 상사가 원하는 것은 "무엇을 할 수 있는지, 대가는 무엇인지"의 완전한 계산입니다.
🧭 답변 프레임워크
- 가능한 부분부터 주세요: Apache 2.0 허가라 읽기, 빌드, 내부 개조 모두 공간이 있고, README도 소스 빌드 진입점을 줍니다.
- 경계 셋을 주세요: 저장소는 xAI 내부 monorepo에서 정기적으로 단방향 동기화되어 공개 트리가 내부 트렁크보다 뒤처질 수 있습니다. CONTRIBUTING은 외부 PR을 받지 않는다고 명시하므로 우리가 고친 것은 업스트림에 합칠 수 없습니다. 루트 Cargo.toml은 생성된 읽기 전용 파일이라 직접 고치면 다음 동기화에 덮이고, 고치려면 각 crate 자신의 매니페스트를 고쳐야 합니다.
- 플랫폼 계산을 주세요: 지원되는 빌드 호스트는 macOS와 Linux이며, Windows는 best-effort이고 현재 이 소스 트리에서는 테스트되지 않았습니다. 회사가 Windows 개발 머신 위주라면 비용을 다시 평가해야 합니다.
- 결론을 주세요: fork는 가능하지만 "장기적으로 포크 하나를 유지한다"로 값을 매겨야 하며, 업스트림 동기화마다 병합 비용이 붙습니다. 제품을 공짜로 줍는 것과는 다른 일입니다.
⭐ 가산점 로컬 스냅샷에 .git 메타데이터가 없어 "우리가 받은 것이 어느 commit인지"조차 대조할 수 없다고 한 마디 보태세요. 기술 실사에 "확인할 수 없음"을 사실대로 쓰면, 이 엄밀함을 상사는 오래 기억합니다.
Q29면접관
"당신이 면접관이라면, 남이 제출한 Coding Agent 설계안을 어떻게 채점합니까?"
🎯 무엇을 평가하는가
역방향 평가입니다. 당신의 리뷰 기준이 당신 자신의 지식 구조를 드러냅니다: 무엇을 중시하고, 무엇을 무시하며, 체계가 있는지. 기능 흠만 집어내는 사람의 채점 체계는 되묻기 세 번을 버티지 못합니다.
🧭 답변 프레임워크
- 채점표를 주세요: 종강 리뷰의 100점 가중치를 씁니다. 경계와 ADR 20점, 계약과 상태 머신 20점, 보안과 복구 25점, 테스트와 관측 가능성 20점, 데모와 증거 15점. 보안과 복구 가중치가 가장 높습니다.
- 거부 항목을 주세요: 한 표 거부 네 가지입니다. 민감 데이터 저장 위치를 설명하지 않음, 고위험 도구에 권한 경로가 없음, 충돌 후 복구 가능하다고 하면서 테스트가 없음, 소스 코드를 인용하면서 파일 경로를 대지 못함. 점수가 높아도 밟으면 탈락입니다.
- 검사 방법을 주세요: 9차원 의사결정 카드를 한 바퀴 도세요. 진입점, 상태 동시성, 모델 스트림, 도구 계약, 컨텍스트 기억, 보안, 복구, 관측 가능성, 확장. 각 차원에 명확한 결정, 계약, 장애 경로, 검증 방식이 있어야 합니다.
- 가중치 이유를 말하세요: 기능은 평소에도 보이고, 보안과 복구는 사고가 나야 보입니다. 리뷰는 가중치를 "사고가 나야 보이는" 곳에 눌러야 합니다.
⭐ 가산점 리뷰 철학 한 줄을 인용해 마무리하세요. 각 설계 결정은 실제 실패 분기로 돌아갈 수 있어야 합니다. 실패 기본값(정지, 다운그레이드, 아니면 사용자에게 묻기)을 말하지 못하는 설계는 아직 PPT 단계에 머물러 있습니다.
이 강의 페이지로 답변을 구성하세요 →
Coding Agent 설계 워크벤치
Q30상사
"남의 집 소스 코드를 파고드는 데 시간을 이렇게 썼습니다. 가장 값진 수확이 무엇입니까? 한 문장으로 주세요."
🎯 무엇을 평가하는가
정제 능력을 봅니다. 2만 줄 세부사항에서 재사용 가능한 제품 판단을 꺼내야 이 투자가 보답이 됩니다. 기술 명사만 나열하면 헛공부했음을 인정하는 것입니다.
🧭 답변 프레임워크
- 먼저 한 문장을 주세요: 프로덕션급 Agent와 demo의 격차는 모델 호출이 아니라 실패 시맨틱에 있습니다. 이 소스 코드는 층마다 "여기가 망가지면 어떻게 하는가"에 분명히 답합니다.
- 예 셋을 펼치세요: Hook 장애는 fail-open으로 도구 가용성을 지키고, Persona 부재는 실패 종료로 사용자 의도를 지키며, 플러그인 경로 해석 실패는 미신뢰 처리로 보안을 지킵니다. 실패 세 가지에 답 세 가지이며, 전부 리스크에 따라 고른 것이지 일률 적용이 아닙니다.
- 두 번째 수확: 정책은 전부 명시적 설정 객체로 만듭니다. CompactionPolicy는 기본값이 있는 다섯 필드이고, 샌드박스는 해석 가능한 Profile이며, 임계값, 예산, 압축 모델이 모두 조정 가능합니다. demo는 정책을 코드에 하드코딩하고, 제품은 정책을 설정에 맡깁니다.
- 자신의 업무에 적용하세요: 앞으로 어떤 Agent 기능을 리뷰하든 필수 질문 둘을 더합니다. 이 기능의 실패 기본값은 무엇입니까? 이 정책을 바꾸려면 배포가 필요합니까?
⭐ 가산점 구체 숫자로 마무리하세요. 85% 압축 임계값, 300초 압축 예산, 1초 4초 16초 재연결 백오프. 이 수치들은 전부 설정과 상수에 누워 있어 언제든 조회하고 조정할 수 있습니다. 매직 넘버가 감사 가능하다는 것 자체가 엔지니어링 성숙도의 표시입니다.
이 강의 페이지로 답변을 구성하세요 →
Coding Agent 설계 워크벤치
Compaction 85% 임계값
Hooks: 명시적 deny만 차단
Plugin Marketplace 및 신뢰
마지막 조언
이 30문제를 올바르게 활용하는 방법은 소리 내어 말해 보는 것입니다 — 동료, 친구 혹은 녹음을 향해서라도 말하세요. 이 장의 질문들은 진짜 이해 여부를 가장 잘 드러냅니다: 세부 사항을 말할 수 있다면 진정한 이해이고, 말할 수 없다면 결론을 암기한 것입니다. 막히는 부분은 연결된 강좌 페이지를 클릭하여 복습하세요.