이렇게 물어볼 것입니다
Grok Build 해부 · 핵심 6문
6장은 실제 소스 코드를 해부합니다. 이 장의 질문들이 가장 핵심적입니다. Coding Agent를 안다고 말한다면, 이 6문제가 리트머스 테스트입니다 — 먼저 소리 내어 답해 보고, 그다음 프레임워크를 확인하세요.
이 페이지 활용법
각 문제에는 질문자가 표시되어 있습니다. 이 장은 저수준 엔지니어링에 치중하며, 기술 동료의 비중이 가장 크고 그들의 질문도 가장 냉정합니다.
🎙 면접관진짜 이해하는지, 아니면 용어를 암기했는지 확인하려 합니다
👔 상사설명과 확약을 원합니다
🛠 기술 동료당신을 신뢰할 수 있는지 시험합니다
각 문제는 세 층으로 구성됩니다: 출제 의도 → 답변 프레임워크 → 가점 포인트. 답하지 못한 부분은 마지막의 강좌 페이지 링크를 클릭하여 복습하세요.
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 통합의 공수는 프로토콜 주변에 집중되어 있으며, 네이밍·가시성·신원·상태 병합·복구 전략이 연결의 장기적 안정성을 결정합니다." 이것이 한 이터레이션을 잡는 이유이며, 기술 동료는 이를 듣고 자발적으로 세부 사항을 보완해 줄 것입니다.
마지막 조언
이 6문제를 올바르게 활용하는 방법은 소리 내어 말해 보는 것입니다 — 동료, 친구 혹은 녹음을 향해서라도 말하세요. 이 장의 질문들은 진짜 이해 여부를 가장 잘 드러냅니다: 세부 사항을 말할 수 있다면 진정한 이해이고, 말할 수 없다면 결론을 암기한 것입니다. 막히는 부분은 연결된 강좌 페이지를 클릭하여 복습하세요.