Workspace IndexKnowledge Notes › Harness engineering — the agent's reliability lives in the environment around the model, not the model itself

#70PoC2026-09-19chat

Harness engineering — the agent's reliability lives in the environment around the model, not the model itself

Google Cloud Tech published a roughly 30-minute video, "Harness Engineering Explained: Inside the Stack Behind Antigravity, Claude Code & Cursor," a conversation with a Google engineer (given in the source summary as Ryan Leopoldo) plus code walkthroughs. The core claim: an AI agent is two separate things, an LLM (the "brain") and an agent harness (the "body and toolset") (00:44). An LLM only takes in text and emits more text — it cannot run a tool or change the filesystem by itself (01:37, 20:07). Everything that turns that text into action — interpreting intent, reading and editing files, running the terminal, searching the web, holding memory, controlling the loop — is the harness sitting outside the model. Gemini Flash is a model; Antigravity, Claude Code and Cursor are harnesses (00:44, 00:51). The talk organizes the engineer's philosophy around a "lazy prompter" stance, three harness design patterns, and a three-layer stack that says where leverage sits as models turn over.

For Jayverse this names something jay already built rather than something to adopt: CLAUDE.md rules, the alice memory files, the docs/topics/README.md conventions, frozen lockfiles plus CI, and Claude Code skills are the shift-left half of harness engineering, and the Auditor row is literally the harness layer's independent-verifier role under a different name.

Why

The habit this talk argues against is re-prompting after a failure — catching a bad output at the far right of the pipeline and typing a longer, more careful instruction next time. That doesn't scale past one person's memory of what went wrong last week, and it puts the correctness burden on whoever happens to be watching. The alternative — called "shift-left" here, borrowing the decades-old software-quality term — is to push the same guardrail earlier: into a document the model reads before acting, a linter or static check that runs before a tool call completes, a unit test or CI eval that catches the failure before a human ever sees it (05:14, 05:31, 06:05). The engineer describes himself as a "lazy prompter" (00:10): instead of writing the rule into every prompt, he writes it once into the environment — documentation, linters, tests — so the model can retrieve ("ground") it itself (04:28). The same idea explains why a team can eventually hand an agent something as large as a migration: small PRs plus an automated review loop build trust incrementally, and each cycle of trust expands the size of loop a human is willing to leave unsupervised (10:43, 11:38).

How it works

The two-part definition

An agent is model plus harness, not model alone. The model proposes; the harness is the only thing that can read a file, execute a command, or call an API, because the model itself has no hands (00:44, 01:37, 20:07).

Lazy prompter and shift-left

Write the constraint once, into something the model can look up on its own — a doc, a lint rule, a test — rather than into every prompt. Move validation as early in the pipeline as it will go: docs like agents.md, static verifiers, unit tests, CI evals (04:28, 05:31, 06:05).

Expanding the loop

Trust is built incrementally through small, reviewable units of agent work. Each successful small-PR-plus-automated-review cycle raises the size of task a human will delegate without watching every step, which is how an agent eventually earns a large, long-running job like a migration (10:43, 11:38).

Don't over-scaffold the harness itself

The base harness features — read a file, grep, run a shell — are close to standard across tools. The talk's advice is not to spend the engineering budget re-inventing the shell, but on the environment around it: tool quality and context quality, because that's what keeps paying off across model upgrades (14:49, 16:00, 16:28).

Three harness design patterns, shown in code

  1. Linear harness — read a file once, answer, stop. Fits deterministic, single-shot tasks (21:39).
  2. Closed-loop harness — edit, test, capture the failure, feed it back into memory, retry up to a fixed limit or until it passes; a self-healing loop (22:40, 23:11).
  3. Guardrail harness, built on Google's Agent Development Kit (ADK) — an interceptor blocks destructive actions (a DB drop, a forced delete, an unauthorized push) before they run, with automatic memory compaction built in (23:30, 24:02).

Three-layer stack

  • Model layer (e.g., "Gemini 3.8 Flash" per the summary) — an agent loop makes 20–60 tool calls per task, so a fast, cheap model matters more than a slower, heavier one; speed and cost are what let the loop iterate (25:43, 26:12, 26:43).
  • Harness layer (e.g., Antigravity's "Boost" mode per the summary) — one model split into a team: an orchestrator, parallel specialist sub-agents, and an independent auditor that checks the others' work (27:17, 27:32).
  • Knowledge layer (Google Skills) — around a hundred structured, open-source skills for things like GCP, Firebase and Flutter, loaded on demand so the model has exact context instead of guessing (28:48, 29:26).

Where it lands in Jayverse

  • Every repo: an AGENTS.md/CLAUDE.md is the shift-left artifact. Alice already carries this pattern in ~/.claude/CLAUDE.md (GitHub policy, history-logging rules, the English-check format) and in the per-project memory files under ~/.claude/projects/; the talk gives that convention a name and a reason — it's cheaper to write the rule into the doc the agent reads than to retype it in every prompt.
  • Rabbit: the destructive-command interceptor is the guardrail-harness pattern at tool-call level. Rabbit's EIP-7715 session-key mandate check — refusing a "send" action without a valid mandate — is functionally the same ADK-style interceptor the talk shows blocking a DB drop or a forced push; both stop the harness from executing an action the caller wasn't authorized to request.
  • CI: tests are the feedback loop, not just a gate. A closed-loop harness's edit-test-capture-retry cycle only works if the test output is legible to the agent; that's the same requirement CI has to meet for an agent-driven PR, and it is the concrete version of the boundary-file idea in Dark Horse (e).
  • The Auditor: this is literally the harness layer's independent verifier. The talk's auditor sub-agent — checking the orchestrator's and specialists' work against a rule, separate from the agent that did the work — is the Auditor row's job description; "what was checked, by which rule" is exactly what an auditor sub-agent has to log to be useful.
  • Eng: "what is an agent harness" is a fair 2026 interview question. It's a clean way to test whether a candidate distinguishes the model's capabilities from the surrounding system's — the same distinction a team-lead role needs when deciding what to build in-house versus what a harness like Claude Code already provides.

Verified and unverified

Verified on 2026-09-19: "harness" as the name for the runtime shell around a model is now standard usage — Claude Code, Cursor, Codex CLI and Google's Antigravity are all described as agent harnesses; Google's Agent Development Kit (ADK) is a real, documented agent framework whose callbacks can intercept tool calls before execution; "shift left" is a decades-old software-quality term for moving checks earlier in a pipeline; AGENTS.md/CLAUDE.md files are the de-facto convention for giving an agent standing instructions. Taken from the summary and not independently checked: the speaker's name and role as given (Ryan Leopoldo), the "Gemini 3.8 Flash" model name, the "Boost mode" name, the claimed count of roughly 100 Google Skills, and every timestamp above.

Sources: YouTube — Google Cloud Tech, "Harness Engineering Explained: Inside the Stack Behind Antigravity, Claude Code & Cursor" · related items: Tech #62 (agentic engineering writes the boundaries), Tech #97, the ontology item (agentic-systems-need-ontologies), the Pocock item (pocock-fundamentals-matter-more), Tech #101 (ADK voice).

Key expressions

Words and phrases from this page worth keeping, with the Korean meaning and the sentence they come from.

Expression뜻 · 쓰이는 자리
agent harness에이전트 하네스(모델을 둘러싼 실행 껍질: 도구 호출, 루프 제어 등) · 이 글 전체의 핵심 용어. "an AI agent is two separate things, an LLM ... and an agent harness"
LLMLarge Language Model(대형 언어모델) · 텍스트만 주고받을 뿐 행동은 못 하는 "두뇌" 쪽. "An LLM only takes in text and emits more text"
shift-left왼쪽으로 옮기기(검증·품질 관문을 파이프라인 앞단으로 당기는 것) · 오래된 소프트웨어 품질 용어. "push the same guardrail earlier"
lazy prompter게으른 프롬프터(규칙을 매번 프롬프트에 적지 않고 환경에 한 번만 적어 두는 태도) · 이 엔지니어가 자칭한 철학. "he writes it once into the environment"
grounding (v.)근거를 인출하다(모델이 답을 지어내지 않고 문서·환경에서 사실을 가져오는 것) · lazy prompter 철학의 목적어. "the model can retrieve (\"ground\") it itself"
guardrail가드레일(위험한 행동을 사전에 막는 안전장치) · 세 번째 하네스 패턴의 이름. "Guardrail harness ... an interceptor blocks destructive actions"
interceptor인터셉터(실행 전에 호출을 가로채 검사·차단하는 컴포넌트) · ADK 기반 가드레일 하네스의 핵심 부품. "an interceptor blocks destructive actions ... before they run"
closed-loop폐루프(결과를 다시 입력으로 되먹이는 구조) · 두 번째 하네스 패턴. "edit, test, capture the failure, feed it back into memory"
self-healing자가 치유(실패를 스스로 감지하고 재시도해 고치는 성질) · 폐루프 하네스를 요약하는 말. "a self-healing loop"
linear harness선형 하네스(한 번 읽고 답하고 끝나는 가장 단순한 패턴) · 결정론적 단발 작업용. "read a file once, answer, stop"
over-scaffold (v.)과잉으로 뼈대를 짜다(꼭 필요하지 않은 구조를 하네스에 덧붙이는 것) · 이 영상의 경고. "Don't over-scaffold the harness itself"
tool call도구 호출(에이전트가 하네스를 통해 파일 읽기·명령 실행 등을 요청하는 한 스텝) · 루프 횟수를 셀 때 쓰는 단위. "an agent loop makes 20–60 tool calls per task"
orchestrator오케스트레이터(다른 서브 에이전트들에 작업을 나눠 주고 조율하는 역할) · 하네스 계층 팀 구성의 한 축. "an orchestrator, parallel specialist sub-agents"
sub-agent서브 에이전트(오케스트레이터 아래에서 특정 작업을 맡는 하위 에이전트) · 병렬로 도는 전문가 역할. "parallel specialist sub-agents"
auditor (sub-agent)감사자(다른 에이전트의 작업을 규칙에 맞춰 독립적으로 검사하는 역할) · Jayverse의 Auditor 행과 직접 대응. "an independent auditor that checks the others' work"
ADKAgent Development Kit(구글의 에이전트 개발 프레임워크) · 콜백으로 도구 호출을 가로챌 수 있는 실제 프레임워크. "built on Google's Agent Development Kit (ADK)"
CIContinuous Integration(지속적 통합, 코드 변경마다 자동으로 빌드·테스트를 도는 체계) · shift-left 가드레일의 대표 예. "unit test or CI eval that catches the failure"
PRPull Request(코드 변경을 검토·병합 요청하는 단위) · expanding-the-loop 신뢰 구축의 기본 단위. "small PRs plus an automated review loop"
DBDatabase(데이터베이스) · 가드레일 하네스가 막는 파괴적 행동의 예. "a DB drop, a forced delete, an unauthorized push"
GCPGoogle Cloud Platform(구글 클라우드 플랫폼) · Google Skills 지식 계층이 다루는 대표 영역. "things like GCP, Firebase and Flutter"

← All Knowledge Notes · Workspace Index · Top ↑

하네스 엔지니어링 — 에이전트의 신뢰성은 모델 자체가 아니라 모델을 둘러싼 환경에 있다

Google Cloud Tech가 약 30분짜리 영상 "Harness Engineering Explained: Inside the Stack Behind Antigravity, Claude Code & Cursor"를 공개했다. 구글 엔지니어(원문 요약에는 Ryan Leopoldo로 표기)와의 대담에 코드 워크스루가 더해진 구성이다. 핵심 주장은 이렇다. AI 에이전트는 사실 두 개의 분리된 것, 즉 LLM("두뇌")과 에이전트 하네스("몸체와 도구망")로 이루어진다(00:44). LLM은 텍스트를 받아 다음 텍스트를 낼 뿐, 스스로 도구를 실행하거나 파일시스템을 바꾸지 못한다(01:37, 20:07). 그 텍스트를 실제 행동으로 바꾸는 모든 것 — 의도 해석, 파일 읽기·수정, 터미널 실행, 웹 검색, 메모리 유지, 루프 제어 — 이 모델 바깥에 앉아 있는 하네스다. Gemini Flash는 모델이고, Antigravity, Claude Code, Cursor는 하네스다(00:44, 00:51). 강연은 이 엔지니어의 철학을 "게으른 프롬프터" 태도, 세 가지 하네스 설계 패턴, 모델이 계속 바뀌어도 레버리지가 어디 있는지 말해 주는 3계층 스택으로 정리한다.

Jayverse에서 이것은 새로 도입할 무언가가 아니라, jay가 이미 만들어 둔 것에 이름을 붙여 준다. CLAUDE.md 규칙, alice의 메모리 파일들, docs/topics/README.md 컨벤션, 고정된 락파일과 CI, Claude Code 스킬들은 하네스 엔지니어링의 shift-left 절반이고, Auditor 행은 다른 이름으로 불리는 하네스 계층의 독립 검증자 역할 그 자체다.

이 강연이 반대하는 습관은 실패 이후의 재프롬프팅이다. 파이프라인 맨 끝에서 나쁜 결과를 잡아내고 다음번엔 더 길고 조심스러운 지시문을 치는 것. 이는 지난주에 무엇이 잘못됐는지 기억하는 한 사람의 머릿속을 넘어서 확장되지 않고, 정확성의 부담을 그때그때 지켜보는 사람에게 떠넘긴다. 대안은 여기서 "shift-left"라 불리는 것 — 수십 년 된 소프트웨어 품질 용어를 빌려 온 것 — 으로, 같은 가드레일을 더 앞으로 옮기는 일이다. 모델이 행동하기 전에 읽는 문서, 도구 호출이 끝나기 전에 도는 린터나 정적 검사, 사람이 보기 전에 실패를 잡는 단위 테스트나 CI 평가(05:14, 05:31, 06:05). 엔지니어는 스스로를 "게으른 프롬프터"라 부른다(00:10). 매 프롬프트에 규칙을 다시 적는 대신 문서, 린터, 테스트 같은 환경에 한 번만 적어 두어 모델이 스스로 그것을 인출(grounding)하게 한다(04:28). 같은 발상이 팀이 결국 마이그레이션 같은 큰 일을 에이전트에 맡길 수 있는 이유를 설명한다. 작은 PR과 자동 리뷰 루프가 신뢰를 점진적으로 쌓고, 그 신뢰의 사이클마다 사람이 매 단계를 지켜보지 않고 맡길 수 있는 루프의 크기가 커진다(10:43, 11:38).

동작 방식

두 부분으로 된 정의

에이전트는 모델 하나가 아니라 모델 더하기 하네스다. 모델은 제안하고, 파일을 읽거나 명령을 실행하거나 API를 호출할 수 있는 것은 하네스뿐이다. 모델 자체에는 손이 없기 때문이다(00:44, 01:37, 20:07).

게으른 프롬프터와 shift-left

제약을 매 프롬프트가 아니라 모델이 스스로 찾아볼 수 있는 곳 — 문서, 린트 규칙, 테스트 — 에 한 번만 적어 둔다. 검증을 파이프라인에서 갈 수 있는 만큼 앞으로 옮긴다. agents.md 같은 문서, 정적 검증기, 단위 테스트, CI 평가(04:28, 05:31, 06:05).

루프 확장하기

신뢰는 작고 검토 가능한 에이전트 작업 단위를 통해 점진적으로 쌓인다. 작은 PR과 자동 리뷰가 성공적으로 돌 때마다 사람이 매 단계를 지켜보지 않고 맡길 수 있는 작업 크기가 커지고, 이런 식으로 에이전트가 결국 마이그레이션 같은 크고 오래 걸리는 일을 맡게 된다(10:43, 11:38).

하네스 자체를 과잉 스캐폴딩하지 말 것

파일 읽기, grep, 셸 실행 같은 기본 하네스 기능은 도구마다 거의 표준화되어 있다. 강연의 조언은 엔지니어링 예산을 셸을 재발명하는 데 쓰지 말고, 그 주변의 환경 — 도구 품질과 컨텍스트 품질 — 에 쓰라는 것이다. 모델이 업그레이드되어도 계속 남는 레버리지는 거기 있기 때문이다(14:49, 16:00, 16:28).

코드로 보여준 세 가지 하네스 설계 패턴

  1. 선형(linear) 하네스 — 파일을 한 번 읽고 답하고 종료. 결정론적인 단발성 작업에 맞다(21:39).
  2. 폐루프(closed-loop) 하네스 — 수정 → 테스트 → 실패 캡처 → 메모리에 피드백 → 통과하거나 정해진 횟수까지 재시도하는 자가 치유 루프(22:40, 23:11).
  3. 가드레일(guardrail) 하네스 — 구글 Agent Development Kit(ADK) 기반. 파괴적 행동(DB drop, 강제 삭제, 무단 push)을 실행 전에 막는 인터셉터가 있고, 자동 메모리 압축(compaction)이 내장되어 있다(23:30, 24:02).

3계층 스택

  • 모델 계층 (요약에 따르면 "Gemini 3.8 Flash" 등) — 에이전트 루프 하나가 작업당 20~60회의 도구 호출을 돌리므로, 느리고 무거운 모델보다 빠르고 저렴한 모델이 더 중요하다. 속도와 비용이 루프의 반복 속도를 결정한다(25:43, 26:12, 26:43).
  • 하네스 계층 (요약에 따르면 Antigravity의 "Boost" 모드 등) — 모델 하나를 오케스트레이터, 병렬로 도는 전문 서브 에이전트들, 다른 둘의 작업을 검사하는 독립 검증자(auditor)로 이루어진 팀으로 구성한다(27:17, 27:32).
  • 지식 계층 (Google Skills) — GCP, Firebase, Flutter 등을 다루는 구조화된 오픈소스 스킬 약 100개를 필요할 때 로드해, 추측 대신 정확한 컨텍스트를 모델에 준다(28:48, 29:26).

Jayverse에서의 위치

  • 모든 레포: AGENTS.md/CLAUDE.md가 shift-left 산출물이다. alice는 이미 ~/.claude/CLAUDE.md(GitHub 정책, 히스토리 로깅 규칙, 영어 체크 포맷)와 ~/.claude/projects/ 아래 프로젝트별 메모리 파일에 이 패턴을 갖고 있다. 강연은 이 컨벤션에 이름과 이유를 붙여 준다. 매 프롬프트에 규칙을 다시 치는 것보다 에이전트가 읽는 문서에 한 번 적어 두는 쪽이 더 싸다.
  • Rabbit: 파괴적 명령 인터셉터가 곧 도구 호출 단위의 가드레일 하네스 패턴이다. Rabbit의 EIP-7715 세션 키 mandate 검사 — mandate 없이 "send" 액션을 거부하는 것 — 는 강연이 보여준, DB drop이나 강제 push를 막는 ADK 스타일 인터셉터와 기능적으로 같다. 둘 다 호출자가 요청할 권한이 없는 행동을 하네스가 실행하지 못하게 막는다.
  • CI: 테스트는 단순한 게이트가 아니라 피드백 루프다. 폐루프 하네스의 수정-테스트-캡처-재시도 사이클은 테스트 출력이 에이전트가 읽을 수 있게 되어 있어야만 작동한다. 이는 에이전트가 만드는 PR에서 CI가 만족해야 할 조건과 같고, Dark Horse (e)의 boundary-file 아이디어를 구체화한 버전이다.
  • Auditor: 이것이 문자 그대로 하네스 계층의 독립 검증자다. 강연의 auditor 서브 에이전트 — 작업을 한 오케스트레이터·전문가와 별개로, 규칙에 맞춰 그 작업을 검사하는 존재 — 가 바로 Auditor 행의 직무 설명이다. "무엇을 어떤 규칙으로 확인했는지"가 정확히 쓸모 있는 auditor 서브 에이전트가 기록해야 할 내용이다.
  • Eng: "에이전트 하네스가 무엇인가"는 2026년다운 정당한 면접 질문이다. 후보자가 모델의 능력과 그것을 둘러싼 시스템의 능력을 구분하는지 깔끔하게 테스트할 수 있다. 이는 팀 리드 역할이 무엇을 직접 만들고 무엇을 Claude Code 같은 기존 하네스에 맡길지 결정할 때 필요한 것과 같은 구분이다.

확인된 것과 미확인

2026-09-19 확인: 모델을 둘러싼 런타임 껍질을 "하네스"라 부르는 것은 이제 표준 용법이다 — Claude Code, Cursor, Codex CLI, 구글의 Antigravity 모두 에이전트 하네스로 불린다. 구글의 Agent Development Kit(ADK)는 실행 전에 도구 호출을 가로챌 수 있는 콜백을 가진 실제 문서화된 에이전트 프레임워크다. "shift left"는 검증을 파이프라인 앞단으로 옮긴다는, 수십 년 된 소프트웨어 품질 용어다. AGENTS.md/CLAUDE.md 파일은 에이전트에게 상시 지침을 주는 사실상의 표준 컨벤션이다. 요약에서 가져왔고 독립 확인하지 않은 것: 화자의 이름과 역할(Ryan Leopoldo), "Gemini 3.8 Flash"라는 모델명, "Boost 모드"라는 이름, 약 100개라는 Google Skills 개수, 그리고 위의 모든 타임스탬프.

출처: YouTube — Google Cloud Tech, "Harness Engineering Explained: Inside the Stack Behind Antigravity, Claude Code & Cursor" · 관련 항목: Tech #62(에이전틱 엔지니어링은 경계를 쓴다), Tech #97, 온톨로지 항목(agentic-systems-need-ontologies), Pocock 항목(pocock-fundamentals-matter-more), Tech #101(ADK voice).

핵심 표현

이 페이지의 영어 본문에서 배울 만한 단어와 표현, 뜻과 나온 자리.

Expression뜻 · 쓰이는 자리
agent harness에이전트 하네스(모델을 둘러싼 실행 껍질: 도구 호출, 루프 제어 등) · 이 글 전체의 핵심 용어. "an AI agent is two separate things, an LLM ... and an agent harness"
LLMLarge Language Model(대형 언어모델) · 텍스트만 주고받을 뿐 행동은 못 하는 "두뇌" 쪽. "An LLM only takes in text and emits more text"
shift-left왼쪽으로 옮기기(검증·품질 관문을 파이프라인 앞단으로 당기는 것) · 오래된 소프트웨어 품질 용어. "push the same guardrail earlier"
lazy prompter게으른 프롬프터(규칙을 매번 프롬프트에 적지 않고 환경에 한 번만 적어 두는 태도) · 이 엔지니어가 자칭한 철학. "he writes it once into the environment"
grounding (v.)근거를 인출하다(모델이 답을 지어내지 않고 문서·환경에서 사실을 가져오는 것) · lazy prompter 철학의 목적어. "the model can retrieve (\"ground\") it itself"
guardrail가드레일(위험한 행동을 사전에 막는 안전장치) · 세 번째 하네스 패턴의 이름. "Guardrail harness ... an interceptor blocks destructive actions"
interceptor인터셉터(실행 전에 호출을 가로채 검사·차단하는 컴포넌트) · ADK 기반 가드레일 하네스의 핵심 부품. "an interceptor blocks destructive actions ... before they run"
closed-loop폐루프(결과를 다시 입력으로 되먹이는 구조) · 두 번째 하네스 패턴. "edit, test, capture the failure, feed it back into memory"
self-healing자가 치유(실패를 스스로 감지하고 재시도해 고치는 성질) · 폐루프 하네스를 요약하는 말. "a self-healing loop"
linear harness선형 하네스(한 번 읽고 답하고 끝나는 가장 단순한 패턴) · 결정론적 단발 작업용. "read a file once, answer, stop"
over-scaffold (v.)과잉으로 뼈대를 짜다(꼭 필요하지 않은 구조를 하네스에 덧붙이는 것) · 이 영상의 경고. "Don't over-scaffold the harness itself"
tool call도구 호출(에이전트가 하네스를 통해 파일 읽기·명령 실행 등을 요청하는 한 스텝) · 루프 횟수를 셀 때 쓰는 단위. "an agent loop makes 20–60 tool calls per task"
orchestrator오케스트레이터(다른 서브 에이전트들에 작업을 나눠 주고 조율하는 역할) · 하네스 계층 팀 구성의 한 축. "an orchestrator, parallel specialist sub-agents"
sub-agent서브 에이전트(오케스트레이터 아래에서 특정 작업을 맡는 하위 에이전트) · 병렬로 도는 전문가 역할. "parallel specialist sub-agents"
auditor (sub-agent)감사자(다른 에이전트의 작업을 규칙에 맞춰 독립적으로 검사하는 역할) · Jayverse의 Auditor 행과 직접 대응. "an independent auditor that checks the others' work"
ADKAgent Development Kit(구글의 에이전트 개발 프레임워크) · 콜백으로 도구 호출을 가로챌 수 있는 실제 프레임워크. "built on Google's Agent Development Kit (ADK)"
CIContinuous Integration(지속적 통합, 코드 변경마다 자동으로 빌드·테스트를 도는 체계) · shift-left 가드레일의 대표 예. "unit test or CI eval that catches the failure"
PRPull Request(코드 변경을 검토·병합 요청하는 단위) · expanding-the-loop 신뢰 구축의 기본 단위. "small PRs plus an automated review loop"
DBDatabase(데이터베이스) · 가드레일 하네스가 막는 파괴적 행동의 예. "a DB drop, a forced delete, an unauthorized push"
GCPGoogle Cloud Platform(구글 클라우드 플랫폼) · Google Skills 지식 계층이 다루는 대표 영역. "things like GCP, Firebase and Flutter"

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑