Codex CLI 실전 - exec·샌드박스·승인 정책·리뷰

이 장에서 배우는 것

앞 장에서 실행 모드와 터미널 제한을 살펴봤다. 이번에는 Codex CLI로 작업을 한 번 실행하고, 결과를 파일로 받고, 변경을 검토하는 흐름을 만든다. 핵심은 명령을 짧게 외우는 데 있지 않다. AI가 무엇을 할 수 있었는지와 사람이 무엇을 확인했는지를 구분해서 남기는 데 있다.

이 장의 도구 명령과 기능 설명은 모두 2026년 10월 기준 예시다. 아래 표와 명령 예시에도 이 기준이 적용된다. 실제 사용 전에는 설치된 버전에 맞는 Codex CLI 공식 문서에서 동작을 확인한다. 완성 코드는 Codex를 실행하지 않는 독립적인 Python 프로그램이다.

• codex exec의 실행 결과와 마지막 답을 구분해서 받는다.
• 샌드박스 세 단계와 승인 정책을 서로 다른 제한으로 설명한다.
• review와 resume을 작업 검증과 이어가기의 목적에 맞게 사용한다.
• 표준 입력 대기로 실행이 멈추는 상황을 예방한다.
• 권한 가정을 명시한 표 생성기를 만들고 결과를 검증한다.

문제 상황

작은 팀이 주문 내역을 정리하는 Python 저장소를 관리한다. 담당자는 낮에 AI에게 수정 방향을 물었고, 저녁에는 같은 요청을 비대화형 실행으로 넘겼다. 다음 날 확인하니 마지막 설명은 그럴듯했지만 수정 파일이 예상보다 많았다. 다른 실행은 결과 파일이 생기지 않은 채 계속 살아 있었다.

두 문제는 원인이 다르다. 첫 번째는 쓰기 범위와 변경 검토가 불명확했던 문제다. 두 번째는 입력을 더 기다리는 실행일 수 있다. “비대화형이면 알아서 끝난다”는 가정만으로는 어느 쪽도 설명할 수 없다.

팀은 실행 전에 세 가지를 적기로 한다. 작업 폴더, 허용할 자원 범위, 결과를 확인하는 방법이다. 요청문도 “고쳐 줘”에서 다음과 같이 바꾼다.

주문 합계 계산에서 빈 목록을 처리하는 경로를 조사하라. 먼저 관련 파일과 예상 원인을 설명하라. 변경이 필요한 경우에는 허용된 작업 폴더 안에서만 수정하고, 수행한 검증과 수행하지 못한 검증을 마지막 답에 구분하라.

요청문은 작업 의도를 전달한다. 파일 접근을 실제로 제한하는 역할은 실행 환경이 맡는다. 요청문에 적힌 “폴더 안에서만”을 보안 경계로 취급해서는 안 된다.

이 장에서는 그 차이를 눈으로 확인하기 위해 권한 표를 만든다. 표의 행은 파일 읽기, 작업 폴더 쓰기, 작업 폴더 밖 쓰기, 네트워크 접근이다. 열은 샌드박스 단계다. 프로그램이 실제 권한을 바꾸는 것은 아니다. 팀이 실행 전에 검토할 가정을 일정한 형식으로 출력한다.

exec의 결과를 받는 두 경로

2026년 10월 기준 예시에서 codex exec는 요청을 비대화형으로 실행한다. 대화 화면을 계속 지켜보는 대신 한 작업의 끝을 기다리고 결과를 받는 진입점이다. 그러나 비대화형이라는 말이 승인, 입력 대기, 실행 실패까지 없어진다는 뜻은 아니다.

codex exec "빈 주문 목록 처리 경로를 조사하고 검증 방법을 설명하라" < /dev/null

이 예시는 요청을 인자로 전달하고 표준 입력을 닫는다. macOS와 Linux에서 /dev/null을 표준 입력으로 연결하면 추가 입력이 없는 상태가 된다. 요청을 인자로 이미 전달하는 백그라운드 실행이나 스크립트에서는 이 처리가 불필요한 입력 대기를 예방한다. 의도적으로 표준 입력을 사용하는 다른 실행까지 무조건 닫는 규칙으로 확대하지 않는다.

2026년 10월 기준 예시에서 --json은 실행 중 이벤트를 출력하는 옵션이고, -o 또는 --output-last-message는 마지막 답을 파일로 저장하는 옵션이다. 이벤트는 진행 상황을 다루는 경로이고 마지막 답은 최종 설명을 받는 경로다. 두 결과를 같은 종류의 데이터라고 가정하지 않는다.

codex exec -o last-answer.txt "관련 파일과 검증 결과를 정리하라" < /dev/null

2026년 10월 기준 예시에서 결과를 받는 목적과 옵션

목적	사용 요소	확인할 점
진행 이벤트 받기	--json	마지막 답만 담긴 단일 객체라고 가정하지 않는다.
마지막 설명 저장	-o 또는 --output-last-message	파일 생성과 내용의 타당성을 따로 확인한다.
답의 구조 지정	--output-schema	구조가 맞아도 사실과 검증 결과는 확인한다.

2026년 10월 기준 예시에서 --output-schema에는 답 형식을 지정할 스키마 파일을 준다. 예를 들어 팀은 최종 답에 요약 문자열, 변경 파일 목록, 검증 설명 목록을 요구할 수 있다. 이 장에서는 스키마 자체의 작성 규칙을 확장하지 않고 역할만 구분한다.

codex exec --output-schema answer-schema.json -o answer.json "조사 결과를 지정된 형식으로 정리하라" < /dev/null

이 명령은 answer-schema.json을 미리 준비한 상황의 예시다. -o는 저장 위치를 정하고 --output-schema는 답의 구조를 정한다. 파일 확장자를 .json으로 붙이는 것만으로 형식 제약이 생기지는 않는다. 반대로 구조에 맞게 받은 답도 “테스트 통과”라는 문장의 근거까지 보장하지 않는다.

팀은 결과를 세 층으로 확인한다. 실행이 정상 종료했는지, 결과가 요구한 구조인지, 저장소의 실제 변경과 검증 결과가 설명에 부합하는지다. 이 장에서는 마지막 두 층을 혼동하지 않는 습관을 익힌다. 실행 결과를 다른 작업에 연결하는 자세한 구성은 다음 장에서 다룬다.

샌드박스와 승인은 별개의 경계다

샌드박스(sandbox)는 실행 과정이 접근할 수 있는 자원의 범위를 제한한다. 승인 정책은 도구가 어떤 상황에서 사람의 판단을 요청할지를 정한다. 2026년 10월 기준 예시에서 -s 또는 --sandbox로 read-only, workspace-write, danger-full-access를 선택하고, -a 또는 --ask-for-approval로 on-request, never 등의 정책을 지정한다.

두 설정은 한 줄에 함께 나타날 수 있지만 의미는 다르다. 승인을 요청하지 않는 never를 선택했다고 제한된 파일 쓰기가 허용되는 것은 아니다. 제한 때문에 실행하지 못하는 작업은 완료하지 못할 수 있다. 반대로 승인 요청이 있다는 이유만으로 실행 환경에 충분한 격리가 마련됐다고 판단해서도 안 된다.

2026년 10월 기준 예시의 샌드박스 단계와 해석 범위

단계	파일 작업의 기본 방향	별도로 확인할 조건
read-only	읽기 중심으로 조사하며 쓰기를 제한한다.	읽기 제한 경로와 네트워크 정책
workspace-write	허용된 작업 영역에 쓰기를 허용한다.	실제 쓰기 허용 경로와 네트워크 정책
danger-full-access	Codex 샌드박스의 접근 제한을 해제한다.	운영체제 권한과 외부 실행 환경의 제한

위 표는 2026년 10월 기준 예시의 개념 요약이다. 실제 읽기 범위, 쓰기 예외, 네트워크 가능 여부를 단계 이름 하나만으로 확정하지 않는다. 특히 danger-full-access는 운영체제의 파일 권한이나 외부 방화벽까지 없애는 기능이 아니다. 셸에서 원래 접근할 수 없는 자원이 이 이름 때문에 접근 가능해지는 것은 아니다.

2026년 10월 기준 예시에서 작업 폴더는 -C 또는 --cd로 지정할 수 있다. 작업의 기준 경로를 명시하면 상대 경로 해석을 이해하기 쉽다. 다만 작업 폴더 지정과 접근 제한은 다른 개념이므로 -C만 보고 쓰기 범위를 판단하지 않는다.

codex exec -C ./order-tool -s read-only -a never -o investigation.txt "빈 주문 목록 처리 경로를 조사하라" < /dev/null

이 예시는 먼저 조사 결과를 받는 용도다. 수정 단계에서는 2026년 10월 기준 예시의 workspace-write를 검토할 수 있다. 접근 범위를 넓힐 때는 실패를 없애기 위해서가 아니라 필요한 파일 변경이 무엇인지 설명할 수 있어야 한다.

완성 코드에서는 실제 제품의 모든 설정을 복제하지 않는다. 추가 허용 경로가 없고 네트워크를 허용하지 않는 제한 모드를 교육용 가정으로 둔다. 읽기 대상은 작업 폴더의 일반 파일이고, 작업 폴더 밖 쓰기는 추가로 허용하지 않은 경로다. 보호된 경로와 심볼릭 링크 같은 예외도 모델 범위에서 제외한다.

이에 따라 제한 모드의 네트워크 행은 “기본 차단”으로 출력한다. 이는 프로그램에 명시한 가정이지 설치 환경에서 측정한 결과가 아니다. danger-full-access의 네트워크는 “환경 의존”으로 출력한다. Codex의 제한이 풀려도 외부 환경의 연결 가능 여부는 남기 때문이다.

review로 확인하고 resume으로 이어간다

2026년 10월 기준 예시에서 review 하위 명령은 변경 검토에 사용한다. 수정한 도구의 마지막 설명만 읽고 끝내지 말고, 실제 변경에 대한 검토를 별도로 수행한다. 검토 대상 범위의 세부 지정 방법은 설치된 버전의 공식 문서에서 확인한다.

codex review

검토 의견도 검증해야 할 주장이다. “빈 목록에서 예외가 발생한다”는 의견이 나왔다면 해당 입력으로 실행해 본다. “이 파일은 바꿀 필요가 없다”는 의견이 나왔다면 요청 범위와 diff를 비교한다. 의견을 읽었다는 기록과 문제를 재현했다는 기록은 구분해서 남긴다.

2026년 10월 기준 예시에서 resume 하위 명령은 이전 작업을 이어가는 진입점이다. 앞선 대화 맥락을 활용할 수 있지만 저장소가 당시 상태로 되돌아가는 기능으로 이해해서는 안 된다. 세션 선택과 세부 사용법은 설치된 버전의 공식 문서에서 확인한다.

codex resume

이어가기 직전에는 현재 브랜치와 변경 내역을 확인한다. 다른 사람이 수정했거나 자신이 수동으로 고쳤다면 이어지는 요청에 그 사실을 전달한다. 이전 대화에서 “이 파일은 바뀌지 않았다”고 설명했더라도 현재 파일은 달라졌을 수 있다.

앞선 조사 이후 빈 목록 테스트를 추가했다. 현재 파일과 변경 내역을 다시 확인한 뒤 남은 수정만 수행하라. 이전 설명과 현재 코드가 다르면 현재 코드를 근거로 판단하라.

팀의 완료 기준은 설명의 길이가 아니다. 요청한 동작이 실행으로 확인되고, diff에서 변경 범위를 설명할 수 있으며, 검토 의견을 처리했는지가 기준이다. 여러 실행을 동시에 배치하는 방법은 여기서 확장하지 않는다. 먼저 한 번의 실행을 검증 가능한 단위로 끝내는 흐름을 고정한다.

완성 코드

다음 프로그램을 main.py로 저장한다. Python 3.12 이상에서 표준 라이브러리만 사용한다. 도구 호출, 파일 생성, 네트워크 연결 없이 메모리에 선언된 규칙으로 표를 만들고 종료한다. 실제 파일 접근을 시도하지 않으므로 어디서 실행해도 출력은 같다.

판정 문자열은 세 가지다. “허용”은 이 모델이 해당 동작을 허용한다는 뜻이고, “차단”은 허용하지 않는다는 뜻이다. 네트워크에는 가정을 드러내기 위해 “기본 차단”과 “환경 의존”을 사용한다. 이 표를 실제 환경의 보안 점검 결과로 제출해서는 안 된다.

from dataclasses import dataclass
from enum import Enum


class Action(Enum):
    READ = "파일 읽기"
    WRITE_WORKSPACE = "작업 폴더 쓰기"
    WRITE_OUTSIDE = "밖 쓰기"
    NETWORK = "네트워크"


@dataclass(frozen=True)
class Policy:
    name: str
    read: bool
    write_workspace: bool
    write_outside: bool
    network: str


POLICIES = (
    Policy("read-only", True, False, False, "기본 차단"),
    Policy("workspace-write", True, True, False, "기본 차단"),
    Policy("danger-full-access", True, True, True, "환경 의존"),
)


def judge(policy: Policy, action: Action) -> str:
    if action is Action.NETWORK:
        return policy.network

    permissions = {
        Action.READ: policy.read,
        Action.WRITE_WORKSPACE: policy.write_workspace,
        Action.WRITE_OUTSIDE: policy.write_outside,
    }
    return "허용" if permissions[action] else "차단"


def check_model() -> None:
    expected = (
        ("허용", "차단", "차단", "기본 차단"),
        ("허용", "허용", "차단", "기본 차단"),
        ("허용", "허용", "허용", "환경 의존"),
    )
    actual = tuple(
        tuple(judge(policy, action) for action in Action)
        for policy in POLICIES
    )
    if actual != expected:
        raise RuntimeError("권한 표가 교육용 가정과 다르다")

    write_counts = tuple(
        sum(
            judge(policy, action) == "허용"
            for action in (
                Action.WRITE_WORKSPACE,
                Action.WRITE_OUTSIDE,
            )
        )
        for policy in POLICIES
    )
    if write_counts != (0, 1, 2):
        raise RuntimeError("쓰기 범위의 단계 구분이 잘못되었다")


def render_table() -> str:
    rows = [
        "| 동작 | " + " | ".join(p.name for p in POLICIES) + " |",
        "| --- | --- | --- | --- |",
    ]
    for action in Action:
        values = [judge(policy, action) for policy in POLICIES]
        rows.append("| " + " | ".join([action.value, *values]) + " |")
    return "\n".join(rows)


def main() -> None:
    check_model()
    print("Codex 샌드박스 판정표")
    print("교육용 가정: 추가 허용 경로 없음, 제한 모드 네트워크 차단")
    print("읽기 대상: 작업 폴더의 일반 파일")
    print(render_table())
    print("검증: 12개 판정과 쓰기 범위 단계 확인")
    print("주의: 실제 권한을 탐지하거나 변경하지 않는다.")


if __name__ == "__main__":
    main()

줄별 해설

첫 두 import 문은 데이터 클래스와 열거형을 가져온다. 외부 패키지는 사용하지 않는다. Action은 사람이 읽을 표의 행 이름과 프로그램 내부의 동작 구분을 함께 정의한다. 문자열을 여러 곳에 직접 적는 대신 Action.WRITE_OUTSIDE처럼 같은 이름을 사용하므로 오타가 판정 분기를 바꾸는 일을 줄인다.

Policy는 한 단계의 규칙을 담는다. frozen=True는 생성한 정책 객체의 필드를 실수로 바꾸는 것을 막는다. 이 설정은 프로그램 내부 데이터의 변경을 제한할 뿐 운영체제의 파일 권한에는 관여하지 않는다.

read, write_workspace, write_outside는 참과 거짓으로 나타낼 수 있다. network는 문자열로 둔다. 이번 모델에서는 네트워크를 단순 허용으로 표현하면 실제 연결까지 보장하는 것으로 오해할 수 있기 때문이다. “환경 의존”은 판정이 빠졌다는 뜻이 아니라 모델 밖의 조건이 남았다는 표시다.

POLICIES에는 세 단계를 순서대로 넣는다. 출력 순서는 이 튜플의 순서에 따라 정해진다. 각 단계의 파일 읽기는 참으로 두지만 이것은 본문에 적은 작업 폴더의 일반 파일을 대상으로 한 가정이다. 모든 경로를 읽을 수 있다는 선언으로 확대하면 안 된다.

judge 함수는 정책과 동작 하나를 받아 판정 문자열 하나를 돌려준다. 네트워크는 별도로 처리하고 나머지 동작은 permissions 사전에서 찾는다. 표시용 문장과 판정 규칙을 분리했기 때문에 표의 열 제목을 바꿔도 판정 로직을 수정할 필요가 없다.

check_model의 expected는 검토 기준을 고정한다. 실제 판정 열두 개를 이 기준과 비교하므로 네트워크 문구나 한 단계의 쓰기 허용이 바뀌면 실행을 멈춘다. 이는 실제 Codex 권한을 시험하는 테스트가 아니다. 이 프로그램이 책에서 선언한 표를 출력하는지 확인하는 검사다.

이어지는 write_counts는 각 단계에서 허용되는 쓰기 종류의 수를 센다. 읽기 전용은 0개, 작업 폴더 쓰기는 1개, 전체 접근은 2개여야 한다. 개별 셀 검사와 별도로 단계 간 차이를 확인한다. 두 검사 모두 실패 시 예외를 발생시키므로 잘못된 표를 정상 결과처럼 출력하지 않는다.

render_table은 제목 행, 구분 행, 데이터 행을 차례로 만든다. Action과 POLICIES의 선언 순서를 그대로 사용한다. 파일 목록이나 현재 시각처럼 환경에 따라 달라지는 자료를 읽지 않으므로 표의 순서와 내용이 고정된다.

main은 검사를 먼저 수행한 뒤 가정과 표를 출력한다. 가정을 표 위에 출력하는 이유는 결과만 복사해 공유했을 때도 해석 범위가 남도록 하기 위해서다. 마지막 진입점 조건은 파일을 직접 실행했을 때 main을 호출한다. 다른 Python 파일에서 가져오더라도 표를 즉시 출력하지 않는다.

실행 결과

실행 전에 다음 명령으로 문법 컴파일을 확인한다. 정상이라면 별도 출력 없이 끝난다. 이 명령은 캐시 파일을 만들 수 있으므로 쓰기 가능한 예제 폴더에서 수행한다.

python3 -W error -m py_compile main.py

이어서 다음 명령으로 실행한다. 여기서 실행하는 것은 권한 표 생성기이며 Codex CLI가 아니다.

python3 main.py

Codex 샌드박스 판정표
교육용 가정: 추가 허용 경로 없음, 제한 모드 네트워크 차단
읽기 대상: 작업 폴더의 일반 파일
| 동작 | read-only | workspace-write | danger-full-access |
| --- | --- | --- | --- |
| 파일 읽기 | 허용 | 허용 | 허용 |
| 작업 폴더 쓰기 | 차단 | 허용 | 허용 |
| 밖 쓰기 | 차단 | 차단 | 허용 |
| 네트워크 | 기본 차단 | 기본 차단 | 환경 의존 |
검증: 12개 판정과 쓰기 범위 단계 확인
주의: 실제 권한을 탐지하거나 변경하지 않는다.

출력이 예상과 같다는 사실은 모델 구현을 확인한다. 실제 도구가 같은 제한을 적용한다는 증거는 아니다. 팀에서는 이 출력과 실제 실행 설정을 나란히 검토한다. 쓰기 허용 경로가 추가됐거나 네트워크 정책이 다르면 표의 가정부터 수정해야 한다.

AI가 이 코드를 작성했다면 문법 검사, 직접 실행, diff 검토를 모두 수행한다. 예를 들어 “표 정렬만 개선했다”는 설명과 달리 POLICIES의 거짓 값이 참으로 바뀌었다면 권한 의미가 달라진 변경이다. 설명보다 변경 내용을 근거로 판단한다.

실무에서 자주 틀리는 것

표준 입력이 열린 채로 끝나기를 기다린다

2026년 10월 기준 예시에서 백그라운드나 스크립트의 codex exec는 표준 입력이 열려 있으면 입력을 기다리며 멈출 수 있다. 요청을 인자로 전달하는 상황이라면 입력 종료도 명시한다. 아래는 Python 코드가 아니라 잘못된 명령과 수정한 명령의 비교다.

잘못된 예: codex exec "변경 내용을 요약하라"

수정한 예: codex exec "변경 내용을 요약하라" < /dev/null

모든 정지가 입력 대기 때문인 것은 아니다. 요청 인자와 입력 종료를 확인한 뒤 실행 상태와 결과 기록을 살펴본다. 입력 종료 처리를 했다는 이유로 실패 분석을 끝내지 않는다.

승인하지 않으면 접근 제한도 사라진다고 생각한다

2026년 10월 기준 예시의 never는 승인 요청 정책이다. 다음과 같이 승인 정책 문자열에서 파일 쓰기 가능 여부를 계산하는 코드는 두 경계를 섞는다. 아래 두 Python 예제는 각각 독립적으로 실행할 수 있다.

잘못된 코드에서는 승인 요청 여부만 보고 쓰기를 허용한다.

approval = "never"
can_write = approval == "never"
print(can_write)

고친 코드는 교육용 모델의 샌드박스 단계에서 작업 폴더 쓰기 여부를 판단한다. 실제 적용에는 실행 환경의 추가 제한도 확인해야 한다.

sandbox = "read-only"
can_write = sandbox in ("workspace-write", "danger-full-access")
print(can_write)

첫 코드는 True, 두 번째 코드는 False를 출력한다. 이 차이는 승인 질문을 생략하는 것과 파일 쓰기를 허용하는 것이 서로 다른 결정임을 보여 준다.

구조가 맞는 답을 검증 완료로 취급한다

2026년 10월 기준 예시의 --output-schema는 답 형식을 지정한다. “검증을 통과했다”는 문자열의 사실성을 확인하는 옵션은 아니다. 다음 예시는 도구 호출 없이 잘못된 해석 방식을 보여 준다.

잘못된 코드는 답 안의 문자열만 보고 완료로 표시한다.

answer = {"verification": "passed"}
done = answer["verification"] == "passed"
print(done)

고친 코드는 실제로 수행한 동작 검사 결과를 완료 조건에 포함한다. 여기서는 설명 문자열을 판정 근거에서 제외한다.

def total(values):
    return sum(values)


empty_ok = total([]) == 0
normal_ok = total([2, 3]) == 5
done = empty_ok and normal_ok
print(done)

두 코드 모두 True를 출력하지만 근거는 다르다. 실무에서는 실행한 테스트와 실제 diff 검토까지 연결해야 한다. 같은 출력이라고 같은 수준의 확인을 거친 것은 아니다.

이어간 대화가 현재 파일 상태도 알고 있다고 가정한다

2026년 10월 기준 예시의 resume을 사용할 때 이전 설명을 현재 저장소의 사실로 취급하면 수정 범위를 놓칠 수 있다. 다음은 코드가 아니라 이어가기 요청의 잘못된 예와 수정한 예다.

잘못된 예: 아까 확인한 상태 그대로이니 수정만 계속하라.

수정한 예: 앞선 조사 이후 수동 변경이 있다. 현재 파일과 diff를 다시 확인하고, 이전 판단 중 달라진 부분을 설명한 뒤 계속하라.

이 문제를 피하려고 이전 맥락을 모두 버릴 필요는 없다. 목표와 결정은 이어받되 파일 상태와 검증 결과는 다시 확인한다. 대화의 연속성과 저장소 상태의 동일성은 별개다.

한눈에 보기

2026년 10월 기준 예시의 실행 흐름과 사람의 확인 책임

단계	도구 또는 프로그램 요소	사람이 확인할 것
작업 시작	codex exec	요청 범위와 표준 입력 종료
접근 범위 설정	-s, -a, -C	샌드박스, 승인, 작업 경로의 구분
마지막 답 저장	-o	실행 종료와 결과 파일 내용
답 구조 지정	--output-schema	구조 적합성과 설명의 사실성
변경 검토	review	실제 diff와 재현 가능한 검증
작업 이어가기	resume	현재 파일과 이전 판단의 차이
권한 가정 공유	이 장의 표 생성기	가정과 실제 실행 환경의 일치 여부

팀에 남길 기록은 길 필요가 없다. 사용한 접근 범위, 변경 파일, 수행한 검사, 남은 불확실성을 분리하면 된다. 마지막 답은 이 기록을 돕는 자료다. 작업 완료를 판단하는 근거는 실행 결과와 변경 내용에서 찾아야 한다.

연습 문제

1. 완성 코드의 read-only 정책에서 write_workspace를 True로 바꾸면 어떤 일이 일어나는지 설명하라. 정상 표가 출력되는지도 답하라.
2. 작업 폴더 밖의 특정 경로를 추가로 허용한 환경을 표현하려면 “밖 쓰기” 행을 어떻게 바꾸는 것이 좋은지 설계하라. 이번 코드가 그 환경을 그대로 표현할 수 없는 이유도 설명하라.
3. 2026년 10월 기준 예시에서 -o로 답을 받았고 그 안에 테스트 통과라고 적혀 있다. 완료 전에 확인할 항목을 세 가지 적어라.
4. 팀원이 네트워크 행의 “환경 의존”을 “허용”으로 바꾸자고 제안했다. 이 변경이 정보 손실을 일으키는 이유와 유지해야 할 설명을 적어라.

정답과 해설

1. check_model에서 실제 판정과 expected가 달라져 RuntimeError가 발생한다. main은 검사 뒤에 출력을 시작하므로 정상 표는 출력되지 않는다. 실제 도구 권한을 탐지한 결과가 아니라 선언한 교육용 가정과 코드가 어긋났음을 발견한 것이다.
2. “추가 허용 경로 쓰기”와 “그 밖의 경로 쓰기”를 나누거나 판정 함수에 대상 경로를 전달하는 방식이 적합하다. 현재 write_outside는 참과 거짓 하나로 모든 외부 경로를 묶는다. 일부만 허용하는 규칙을 표현하려면 데이터 구조와 검사 기준을 함께 확장해야 한다.
3. 실행이 정상 종료했는지 확인하고, 실제 테스트를 실행해 결과를 확인하며, diff에서 요청 범위를 벗어난 변경이 없는지 검토한다. 답의 구조를 지정했다면 형식 확인도 필요하다. 마지막 답의 문장만으로 어느 확인도 대체하지 않는다.
4. “허용”은 실제 연결이 가능하다는 뜻으로 읽힐 수 있다. Codex의 샌드박스 제한이 없어도 운영체제 권한, 방화벽, 외부 실행 환경의 제한은 남을 수 있다. 따라서 “환경 의존”과 함께 이 표가 실제 연결을 시험하지 않았다는 설명을 유지한다.