터미널 AI 코딩 도구의 공통 구조 - 대화·도구·권한·맥락

이 장에서 배우는 것

터미널 AI 코딩 도구에 “이 함수를 고쳐 달라”고 요청하면 답변만 돌아오는 것은 아니다. 도구는 작업 폴더에서 파일을 찾고, 내용을 읽고, 수정안을 저장하고, 명령을 실행할 수 있다. 팀에서 이 도구를 쓰려면 답변의 문장뿐 아니라 답변이 만들어지는 실행 과정까지 이해해야 한다. 누가 변경을 제안했는지, 무엇이 실행을 허용했는지, 어떤 자료를 근거로 삼았는지를 구분하는 일이 출발점이다.

이 책에서 ‘Gemini’는 Google의 Gemini 계열 도구를 뜻한다. 2026년 10월 기준 예시로, 개인 사용 흐름은 Antigravity CLI를 중심으로 설명하고 Gemini CLI는 기업·API 키 사용자용 맥락에서 구분한다. 이 장은 설치나 옵션 설정 대신 세 도구를 이해하는 공통 구조를 다룬다.

• 모델, 도구 호출, 권한 확인, 작업 폴더, 지침 파일의 역할을 구분한다.
• 채팅형 도우미와 에이전트형 도구가 작업을 진행하는 방식을 비교한다.
• 한 번의 요청이 파일 읽기, 편집, 명령 실행, 결과 확인으로 이어지는 흐름을 추적한다.
• 외부 연결 없이 실행되는 Python 모형으로 요청과 실행 기록을 확인한다.
• 최종 답변을 실행 결과와 변경 내역에 대조하는 습관을 익힌다.

문제 상황

작은 개발팀이 주문 금액을 계산하는 저장소를 함께 관리한다. 팀원 한 명이 터미널 AI 코딩 도구에 다음과 같이 요청했다.

두 금액을 더하는 함수가 잘못 동작한다. 원인을 찾아 수정하고, 간단한 검증 결과와 변경 내용을 알려 달라.

도구는 곧 “수정했고 검증도 통과했다”고 답했다. 그런데 다른 팀원이 변경 내역을 열어 보니 예상했던 파일이 보이지 않는다. 도구를 실행한 위치가 다른 복사본이었기 때문이다. 별도의 작업에서는 테스트 실행이 권한 문제로 막혔는데도, 최종 답변만 읽은 팀원이 검증까지 끝났다고 받아들였다.

이 문제는 모델이 코드를 잘 쓰는지만 따져서는 해결되지 않는다. 어느 폴더를 대상으로 했는지, 모델이 어떤 파일 내용을 보았는지, 실행 요청이 실제로 허용되었는지, 검증 명령이 어떤 결과를 돌려주었는지를 함께 살펴야 한다. “수정했다”는 문장과 디스크에 저장된 변경은 서로 다른 증거다.

팀은 작업 요청을 받을 때 폴더를 먼저 확인하고, 수정 뒤에는 실행 결과와 diff를 함께 검토하기로 했다. 지침 파일에는 변경 범위를 적되, 지침을 적는 것과 운영체제 수준에서 접근을 제한하는 것을 구분하기로 했다. 이 장의 프로그램은 그 합의를 아주 작은 실행 모형으로 만든 것이다.

모델을 실행 도구와 구분한다

언어 모델(language model)은 주어진 요청과 자료를 바탕으로 다음 답변이나 행동을 제안한다. 파일을 읽겠다는 판단과 실제 파일 읽기는 별개의 단계다. 모델이 읽기 요청을 만들면, 실행을 담당하는 프로그램이 요청의 형식과 권한을 확인한 뒤 파일 내용을 가져온다. 모델은 반환된 내용을 다음 판단의 재료로 사용한다.

이처럼 모델 주변에서 대화와 도구 실행을 연결하는 프로그램을 실행 하네스(harness)라고 부른다. 이 책에서는 주로 ‘실행부’라고 쓴다. 실행부는 대화 기록을 유지하고, 사용 가능한 도구를 알려 주며, 모델이 요청한 작업을 실행하거나 거절한다. 터미널 AI 코딩 도구를 이해할 때는 모델의 판단 능력과 실행부가 제공하는 기능을 나누어 보아야 한다.

한 번의 작업을 구성하는 다섯 요소

요소	맡는 일	확인할 증거
모델	다음 답변이나 도구 호출을 제안한다.	어떤 행동을 요청했는가
도구	읽기·쓰기·명령 실행을 수행한다.	반환된 내용과 종료 상태
권한 확인	요청한 행동의 실행 여부를 결정한다.	허용·거절·승인 대기 상태
작업 폴더	파일 경로를 해석할 기준을 제공한다.	실제 접근 대상 경로
지침 파일	작업 규칙을 모델의 판단에 제공한다.	읽힌 규칙과 적용 범위

채팅형 도우미에서는 사용자가 코드를 붙여 넣고, 제안된 수정을 직접 적용하는 흐름이 흔하다. 에이전트(agent)형 도구에서는 모델이 도구 호출을 제안하고 실행 결과를 받아 후속 행동을 이어 간다. 다만 제품의 화면 모양만으로 둘을 나눌 수는 없다. 채팅 화면에도 실행 기능이 연결될 수 있다. 실무에서는 “이 대화에서 실제로 어떤 행동이 가능한가”를 확인하는 편이 유용하다.

그림에서 되돌아오는 실행 결과가 중요하다. 모델이 명령을 제안했다는 사실은 명령이 실행되었다는 뜻이 아니다. 실행되었다고 해도 성공했다는 뜻은 아니다. 성공 종료 상태가 있어도 검사 항목이 부족하면 결함이 남을 수 있다. 따라서 요청, 실행 여부, 실행 결과, 검증 범위를 구분해서 기록한다.

권한과 지침은 서로 다른 역할을 한다

지침 파일에 “현재 작업 폴더 안에서만 수정한다”라고 적으면 모델이 행동을 고르는 데 도움이 된다. 그러나 그 문장만으로 파일 접근이 차단되지는 않는다. 권한 확인은 요청된 경로와 실행 동작을 실제 규칙에 대조하는 단계다. 샌드박스(sandbox)는 파일 시스템이나 프로세스가 접근할 수 있는 범위를 실행 환경에서 제한하는 수단이다. 지침, 승인, 샌드박스는 함께 쓰이지만 같은 장치는 아니다.

승인을 받았다는 사실도 정확성을 보장하지 않는다. 승인은 특정 행동을 실행해도 되는지에 관한 결정이다. 계산 함수가 올바른지, 다른 기능을 깨뜨리지 않았는지는 실행과 테스트로 확인한다. 반대로 테스트가 통과했다는 사실이 허용되지 않은 파일 수정까지 정당화하지도 않는다.

2026년 10월 기준 예시: 도구 이름을 공통 구조에 대응하기

도구	지침 파일	이 장에서 볼 공통점
Claude Code	CLAUDE.md	모델의 도구 요청과 실행 권한을 구분한다.
Gemini CLI	GEMINI.md	작업에 필요한 자료와 규칙을 맥락으로 제공한다.
Antigravity CLI	파일 이름은 각 도구의 공식 문서에서 확인	작업 폴더와 실행 경계를 확인한다.
Codex CLI	AGENTS.md	파일 변경 뒤 실행 결과와 diff를 확인한다.

표는 제품의 기능 순위가 아니라 이 장의 개념을 연결하는 안내다. 모든 도구 사실은 2026년 10월 기준 예시다. 지침을 발견하고 적용하는 세부 규칙과 권한 설정 방법은 도구별로 확인해야 한다. 이 장에서는 특정 제품의 설정을 재현하지 않고, 읽기·쓰기·명령이라는 세 종류의 작업을 공통 모형으로 다룬다.

아래 모형은 사용자에게 승인을 묻는 화면을 만들지 않는다. 대신 미리 정한 좁은 규칙으로 허용과 거절을 판정한다. 파일은 임시 작업 폴더 안에서만 접근하고, 쓰기는 계산 파일 하나에만 허용한다. 명령 도구는 등록된 검증 명령 하나만 실행한다. 이 규칙은 원리를 드러내기 위한 것이며 운영체제 샌드박스를 구현한 것은 아니다.

맥락을 받아 행동하고 결과를 다시 읽는다

맥락(context)은 모델이 현재 판단에 사용할 수 있도록 전달받은 정보다. 사용자 요청, 지침 파일 내용, 읽은 코드, 앞선 도구 결과가 여기에 들어간다. 작업 폴더에 파일이 존재하는 것과 그 내용이 모델에 전달된 것은 다르다. 도구가 파일을 읽어 결과로 반환해야 그 내용이 다음 판단의 자료가 된다.

실제 도구에서는 실행부가 일부 자료를 자동으로 제공하기도 한다. 여기서는 흐름을 눈으로 확인하기 위해 가짜 모델이 지침 파일부터 명시적으로 읽는다. 이후 계산 파일을 읽고, 수정한 내용을 쓰고, 검증 명령을 실행한다. 실행부는 각 결과를 대화 기록에 추가한다. 가짜 모델은 기록에 예상 결과가 있는지 확인한 뒤 다음 행동으로 이동한다.

모형의 지침 파일 내용: 작업 폴더 안에서 calc.py만 수정한다. 수정 뒤 검증 명령을 실행한다.

파일 이름은 제품의 지침 파일과 혼동하지 않도록 RULES.txt로 정한다. 자연어를 이해하는 기능은 없다. 가짜 모델의 행동과 수정 내용은 프로그램 안에 미리 적혀 있다. 따라서 이 예제는 모델의 추론 능력을 평가하지 않는다. 도구 호출이 어떻게 검사되고 기록되는지 관찰하는 장치다.

완성 코드는 전체 요청 처리 한 바퀴를 실행한 뒤 끝난다. 이때 한 바퀴란 도구 호출 한 번이 아니라, 사용자 요청을 받아 여러 도구 호출을 거쳐 최종 답변을 내는 과정이다. 수정 전후의 차이도 마지막에 출력한다. 실제 팀 작업에서는 이 증거를 토대로 사람이 변경 범위와 검증의 충분성을 판단한다.

완성 코드

다음 내용을 main.py로 저장한다. Python 3.12 이상 표준 라이브러리만 사용한다. 임시 폴더 경로나 실행 시간은 출력하지 않으므로 실행할 때마다 같은 결과가 나온다. 프로그램이 만드는 파일은 종료 시 함께 정리된다.

import difflib
import subprocess
import sys
import tempfile
from pathlib import Path

REQUEST = "두 금액을 더하는 함수를 수정하고 검증하라."
RULES = "작업 폴더 안에서 calc.py만 수정한다. 수정 뒤 검증 명령을 실행한다.\n"
BEFORE = "def add(a, b):\n    return a - b\n"
AFTER = "def add(a, b):\n    return a + b\n"
CHECK = (
    "import runpy; "
    "add = runpy.run_path('calc.py')['add']; "
    "cases = [(2, 3, 5), (-2, 3, 1), (0, 0, 0)]; "
    "ok = all(add(a, b) == expected for a, b, expected in cases); "
    "print('PASS: 3 cases' if ok else 'FAIL'); "
    "raise SystemExit(0 if ok else 1)"
)
STEPS = [
    {"tool": "read", "path": "RULES.txt"},
    {"tool": "read", "path": "calc.py"},
    {"tool": "write", "path": "calc.py", "text": AFTER},
    {"tool": "command", "name": "verify"},
]
EXPECTED = [RULES, BEFORE, "저장 완료", "PASS: 3 cases"]


def fake_model(history):
    results = [item["text"] for item in history if item["role"] == "tool"]
    if results != EXPECTED[:len(results)]:
        return {"answer": "예상과 다른 결과가 있어 작업을 중단했다."}
    if len(results) == len(STEPS):
        return {"answer": "calc.py를 수정했고 검증 3개를 통과했다."}
    return dict(STEPS[len(results)])


def local_path(root, name):
    path = (root / name).resolve()
    if not path.is_relative_to(root):
        raise PermissionError("작업 폴더 밖 접근")
    return path


def authorize(root, call):
    tool = call["tool"]
    if tool in {"read", "write"}:
        path = local_path(root, call["path"])
        if tool == "write" and path != root / "calc.py":
            raise PermissionError("쓰기 대상 제한")
    elif tool == "command":
        if call["name"] != "verify":
            raise PermissionError("등록되지 않은 명령")
    else:
        raise PermissionError("등록되지 않은 도구")


def execute(root, call):
    tool = call["tool"]
    if tool == "read":
        return local_path(root, call["path"]).read_text(encoding="utf-8")
    if tool == "write":
        local_path(root, call["path"]).write_text(
            call["text"], encoding="utf-8"
        )
        return "저장 완료"
    result = subprocess.run(
        [sys.executable, "-I", "-c", CHECK],
        cwd=root,
        capture_output=True,
        text=True,
        timeout=5,
        check=False,
    )
    output = result.stdout.strip()
    if result.returncode != 0 or output != "PASS: 3 cases":
        raise RuntimeError("검증 실패")
    return output


def main():
    with tempfile.TemporaryDirectory() as folder:
        root = Path(folder).resolve()
        (root / "RULES.txt").write_text(RULES, encoding="utf-8")
        (root / "calc.py").write_text(BEFORE, encoding="utf-8")
        history = [{"role": "user", "text": REQUEST}]
        print("요청 접수")
        for step in range(1, 9):
            call = fake_model(history)
            if "answer" in call:
                print("최종 답변:", call["answer"])
                break
            target = call.get("path", call.get("name"))
            print(f"{step}. 모델 요청: {call['tool']} {target}")
            history.append({"role": "assistant", "call": call})
            try:
                authorize(root, call)
                print("   권한: 허용")
                result = execute(root, call)
            except PermissionError as error:
                result = f"권한 거절: {error}"
            except (OSError, RuntimeError, subprocess.SubprocessError):
                result = "실행 실패"
            history.append({"role": "tool", "text": result})
            print(f"   도구 결과: {result.strip()!r}")
        else:
            raise RuntimeError("호출 횟수 제한 초과")

        after = (root / "calc.py").read_text(encoding="utf-8")
        diff = difflib.unified_diff(
            BEFORE.splitlines(),
            after.splitlines(),
            fromfile="before/calc.py",
            tofile="after/calc.py",
            lineterm="",
        )
        print("변경 내역:")
        for line in diff:
            print(line)
        print("기록 항목:", len(history))


if __name__ == "__main__":
    main()

줄별 해설

가져오기와 상수 선언. difflib는 변경 내역을 만들고, subprocess는 별도 Python 프로세스를 실행한다. tempfile은 입력 파일을 둘 임시 폴더를 마련한다. BEFORE와 AFTER를 분리했으므로 수정 전후의 기준이 명확하다. CHECK는 외부 프로그램 설치 없이 현재 Python 실행 파일로 수행할 검증 내용이다.

검증 데이터. 양수끼리의 덧셈, 음수가 포함된 덧셈, 영을 더하는 경우를 검사한다. 세 경우를 모두 통과해야 성공 문구를 출력하고 정상 종료한다. assert를 사용하지 않으므로 Python의 최적화 설정에 따라 검사문이 사라지는 문제도 피한다. 다만 세 경우가 모든 입력의 정확성을 증명하지는 않는다.

STEPS와 EXPECTED. STEPS는 가짜 모델이 제안할 네 번의 도구 호출이다. EXPECTED는 그 호출에서 받아야 할 결과다. 읽기와 쓰기, 명령 실행을 데이터로 표현하여 행동 제안과 행동 수행을 분리했다. 여기서 명령 이름 verify는 이 모형의 내부 이름이며 실제 제품의 하위 명령이 아니다.

fake_model 함수. 대화 기록에서 도구 결과만 꺼내 기대한 순서와 비교한다. 첫 호출에서는 결과가 없으므로 지침 읽기를 제안한다. 결과가 하나씩 추가되면 다음 행동을 반환한다. 거절이나 실패가 기록되면 기대한 결과와 달라져 중단 답변을 반환한다. 성공과 실패를 모두 같은 기록 경로로 전달한다는 점이 핵심이다.

local_path 함수. 상대 경로를 임시 작업 폴더와 결합한 뒤 실제 경로로 해석한다. 그 결과가 작업 폴더 내부인지 경로 구조로 확인한다. 단순 문자열 접두사 비교는 비슷한 이름의 다른 폴더를 내부로 오인할 수 있다. 다만 검사 직후 다른 프로세스가 경로를 바꾸는 경쟁 상황까지 막는 설계는 아니다.

authorize 함수. 읽기와 쓰기에는 경로 검사를 적용하고, 쓰기는 calc.py 하나로 좁힌다. 명령은 verify라는 등록 이름만 허용한다. 알 수 없는 도구도 거절한다. 지침 문장을 해석해서 권한을 만든 것이 아니라 실행부의 코드가 별도로 경계를 정했다는 점을 확인한다.

execute 함수. 허용된 요청을 실제 작업으로 바꾼다. 명령 요청은 임의 문자열을 셸에 전달하지 않고 고정된 인자 목록으로 실행한다. 현재 Python 실행 파일을 사용하고 작업 폴더도 명시한다. 격리 모드를 뜻하는 Python의 -I는 사용자 환경의 일부 영향을 줄이지만 운영체제 샌드박스를 대신하지 않는다.

명령 결과 처리. 종료 상태와 표준 출력이 모두 기대와 일치해야 성공을 반환한다. 표준 오류는 수집하지만 정상 출력에는 넣지 않는다. 실패 시 자세한 원인을 보존하는 부분은 실제 운영에서 보강해야 한다. 여기서는 임시 경로가 섞인 오류 대신 일정한 실패 결과를 기록하여 모형의 출력 조건을 단순하게 유지한다.

main 함수의 반복문. 준비 단계에서 입력 파일을 만들고 사용자 요청을 기록한다. 이후 모델 요청을 기록하고, 권한을 검사하고, 실행 결과를 기록한다. 반복 횟수에는 상한을 두었다. 실제 모델이 같은 실패를 계속 반복하는 상황에서도 실행부가 작업을 끝낼 수 있어야 하기 때문이다.

마지막 변경 내역. 최종 답변을 받은 뒤 디스크에서 파일을 다시 읽는다. 모델이 제시한 수정 문자열만 보고 성공을 판단하지 않는다. 기록은 사용자 요청 한 개, 모델의 도구 요청 네 개, 도구 결과 네 개로 총 아홉 항목이다. 이 모형에서는 최종 답변은 출력만 하므로 기록 개수에 포함하지 않는다.

실행 결과

macOS나 Linux의 터미널에서 다음 명령을 실행한다. 명령은 입력 예시이므로 인용으로 표시하고, 그 아래에 프로그램 출력을 제시한다.

python3 main.py

요청 접수
1. 모델 요청: read RULES.txt
   권한: 허용
   도구 결과: '작업 폴더 안에서 calc.py만 수정한다. 수정 뒤 검증 명령을 실행한다.'
2. 모델 요청: read calc.py
   권한: 허용
   도구 결과: 'def add(a, b):\n    return a - b'
3. 모델 요청: write calc.py
   권한: 허용
   도구 결과: '저장 완료'
4. 모델 요청: command verify
   권한: 허용
   도구 결과: 'PASS: 3 cases'
최종 답변: calc.py를 수정했고 검증 3개를 통과했다.
변경 내역:
--- before/calc.py
+++ after/calc.py
@@ -1,2 +1,2 @@
 def add(a, b):
-    return a - b
+    return a + b
기록 항목: 9

도구 결과는 줄바꿈을 알아보기 쉽도록 문자열 표현으로 출력한다. 따라서 계산 파일의 두 줄은 출력에서 역슬래시와 n으로 보인다. 원래 기록에는 파일에서 읽은 줄바꿈이 그대로 남아 있다.

검토할 증거는 세 가지다. 쓰기 요청이 허용되어 저장 완료 결과가 나왔고, 별도 프로세스의 검증이 성공했으며, diff에는 뺄셈을 덧셈으로 바꾼 한 줄만 나타난다. 이 세 증거가 최종 답변을 뒷받침한다. 다만 검증 범위는 코드에 적힌 세 입력에 한정된다. 실제 저장소에서는 기존 테스트와 변경 영향도 함께 확인한다.

실무에서 자주 틀리는 것

모델이 요청했으니 바로 실행한다

다음은 틀린 구조다. 코드는 실행되지만 요청과 권한 사이의 경계가 없다.

def execute():
    return "실행됨"


requested = True
if requested:
    print(execute())

고친 구조에서는 허용 여부를 별도로 판정한다. 아래의 집합은 설명을 위한 최소 규칙이며, 완성 코드에서는 경로와 명령 이름도 검사한다.

def execute():
    return "실행됨"


tool = "write"
allowed_tools = {"read"}
if tool in allowed_tools:
    print(execute())
else:
    print("권한 거절")

모델의 제안은 실행 후보이며, 실행부의 검사를 통과해야 행동이 된다.

작업 폴더를 문자열 접두사로 검사한다

다음 코드는 비슷한 이름의 다른 폴더를 작업 폴더 안으로 잘못 판단한다.

root = "/tmp/team"
target = "/tmp/team-copy/calc.py"
print(target.startswith(root))

고친 코드는 경로 구성 요소의 포함 관계를 검사한다.

from pathlib import Path

root = Path("/tmp/team")
target = Path("/tmp/team-copy/calc.py")
print(target.is_relative_to(root))

앞 코드는 True, 뒤 코드는 False를 출력한다. 실제 접근 경계에서는 완성 코드처럼 resolve로 해석한 경로를 검사한다. 이 검사 하나만으로 악의적인 파일 교체나 실행된 프로그램의 다른 접근까지 통제한다고 생각해서는 안 된다.

프로세스가 끝났으면 검증 성공으로 기록한다

다음 코드는 실패 종료 상태를 갖고도 성공을 출력한다.

returncode = 1
print("검증 성공")

고친 코드는 관찰한 상태를 결과에 반영한다.

returncode = 1
if returncode == 0:
    print("검증 성공")
else:
    print("검증 실패")

실제 검증에서는 종료 상태에 더해 어떤 검사들이 실행되었는지도 확인한다. 검증 프로그램이 아무 항목도 검사하지 않고 정상 종료하는 경우를 놓치지 않아야 한다.

최종 답변을 변경 증거로 대신한다

다음 코드는 요청한 변경이 디스크에 반영되었는지 확인하지 않는다.

answer = "수정 완료"
print(answer)

고친 예시는 기대한 변경과 현재 내용을 대조하는 최소 구조다.

expected = "return a + b"
actual = "return a - b"
if actual == expected:
    print("내용 일치")
else:
    print("내용 불일치")

실무에서는 파일 한 조각 비교를 넘어 diff로 전체 변경 범위를 살피고 테스트 결과를 함께 검토한다. 답변의 확신 정도보다 관찰 가능한 증거를 우선한다.

한눈에 보기

요청부터 검토까지 단계별로 확인할 것

단계	모형의 동작	팀의 확인 질문
요청 접수	사용자 요청을 기록한다.	수정 대상과 완료 조건이 분명한가
맥락 확보	지침과 계산 파일을 읽는다.	실제로 어떤 자료를 읽었는가
행동 제안	가짜 모델이 도구 요청을 만든다.	목표에 필요한 행동인가
권한 확인	경로와 쓰기 대상, 명령을 검사한다.	허용한 범위 안에 있는가
실행과 검증	파일을 쓰고 세 입력을 검사한다.	실행 상태와 검사 범위는 무엇인가
변경 검토	실제 파일의 diff를 출력한다.	요청 밖의 변경이 섞이지 않았는가

모형의 가짜 모델을 실제 모델로 바꾸더라도 질문의 순서는 유지된다. 판단에 쓰인 자료, 실행 경계, 실행 증거가 연결되어 있어야 팀원이 같은 변경을 이해하고 확인할 수 있다.

연습 문제

1. STEPS의 쓰기 대상을 notes.txt로 바꾸면 어떤 단계에서 거절되는지 설명한다. 최종 답변과 변경 내역이 어떻게 달라질지도 예상한다.
2. 지침 파일에 “작업 폴더 안에서만 수정한다”라고 적는 것만으로 접근 통제가 완성되지 않는 이유를 설명한다.
3. CHECK에 음수 두 개를 더하는 검증을 추가한다. 검사 개수에 관한 문자열을 어디서 함께 바꾸어야 하는지 찾는다.
4. 별도 파일을 읽지 않은 채 모델이 “설정 파일도 확인했다”고 답했다. 기록과 실제 변경을 바탕으로 무엇을 확인해야 하는지 세 가지 적는다.

정답과 해설

1. 세 번째 도구 요청에서 authorize가 쓰기 대상 제한으로 거절한다. 거절 결과가 기록에 들어가면 fake_model이 예상 결과와 다름을 감지하여 중단 답변을 반환한다. calc.py는 수정되지 않았으므로 변경 내역 제목 아래에 diff 본문이 나오지 않는다. 요청과 거절 결과도 기록되므로 기록 항목은 일곱 개다.
2. 지침은 모델의 판단 자료다. 실제 실행이 그 지침을 따르는지 검사하는 장치는 별도로 필요하다. 모형에서는 authorize가 경로와 대상을 검사한다. 운영 환경에서는 승인 정책과 실행 환경의 접근 제한까지 각 역할에 맞게 구성한다.
3. 예를 들어 입력 -2와 -3의 기대값 -5를 추가한다. CHECK의 성공 출력, EXPECTED의 기대 결과, execute의 성공 출력 비교, fake_model의 최종 답변을 네 개 기준으로 함께 바꾼다. 수정 후 직접 실행하여 출력과 검증 내용을 대조한다. 숫자가 여러 위치에 흩어진 구조를 개선하려면 검사 데이터에서 개수를 계산하도록 바꿀 수 있다.
4. 첫째, 해당 파일의 읽기 요청과 반환 내용이 기록에 있는지 확인한다. 둘째, 다른 실행 경로로 자료가 제공되었다면 그 출처를 확인한다. 셋째, 실제 파일과 diff를 살펴 관련 변경이 있는지 확인하고 필요한 검증을 실행한다. 기록에 읽기가 없다는 사실만으로 모든 경로의 접근을 단정하지 않되, 답변만으로 확인 완료를 인정하지 않는다.