"느려도 사람이 직접 확인하는 게, AI가 자기 작업을 자기가 통과시키는 것보다 안전하다"
방화벽 문제를 해결한 뒤에도 한 가지 의문이 남았습니다. 이번 네트워크 차단이 Codex의 원래 설계인지, 아니면 이번 세션에서만 우연히 발생한 문제인지가 불분명했습니다. 예전에 사용하던 다른 도구(Antigravity)에서는 같은 문제가 없었다는 점 때문에 원인을 다시 확인해볼 필요가 있었습니다.
OpenAI Codex CLI의 공식 문서를 검색해 확인한 결과, 샌드박스가 기본적으로 네트워크 접근을 차단하는 것이 의도된 기본 설계라는 것을 확인했습니다. network_access = true 설정으로 이를 열 수 있다는 것도 함께 확인했습니다.
다만 열지 않기로 결정했습니다. 네트워크를 열면 Codex의 자체 검증 결과(예: "로그인 성공했습니다")를 그대로 신뢰해야 하는 구조가 되어 Reviewer 역할이 약해질 수 있고, 프롬프트 인젝션 등을 통한 보안 노출 위험도 함께 커진다고 판단했습니다. 속도보다 검증 가능성을 우선하기로 한 것입니다.
이 판단을 바탕으로 "Codex는 코드 작성과 정적 검사까지, 네트워크가 필요한 확인은 사용자가 직접"이라는 역할 분담을 명문화했습니다. 이후 모든 작업 지시 프롬프트(TASK-01-001A 포함)에 "npm run dev를 실행하지 마라"는 제약이 기본으로 포함되기 시작했습니다. 이 결정 자체가 실제로 이후 작업들에서 얼마나 효과적이었는지는, 이 시점에서는 아직 검증되지 않은 부분입니다.
네트워크를 열면 두 가지 위험이 생긴다고 판단했습니다. 하나는 Codex의 자체 네트워크 검증 결과를 그대로 신뢰해야 하는 구조가 되어 Reviewer 역할이 무력화되는 것이고, 다른 하나는 프롬프트 인젝션 등으로 인한 보안 노출입니다. 속도를 얻는 대신 검증 가능성을 잃는 거래라고 봤고, 이번 프로젝트에서는 검증 가능성 쪽에 우선순위를 뒀습니다. 공식 문서로 기본 설계 의도를 먼저 확인한 뒤 판단한 것도, 추측이 아니라 근거 기반으로 정책을 정하기 위해서였습니다.
관련 프로젝트
프로젝트 개요 비즈니스 프로세스 트랜스포메이션(BPR)을 지원하는 한국어 기반 웹 애플리케이션. 컨설팅 프로젝트의 AS-IS 프로세스 분석부터 TO-BE 설계, Blueprint 승인까지의 전체 워크플로우를 디지털화하는 플랫폼으로, EPIC 단위로 구조화된 백로그를 기반으로 개발 중. 역할 및 워크플로우 PM / Architect / Reviewer 역할 수행 Codex(구현 담당)에게 Task 단위 구현 프롬프트 설계 Codex 구현 결과를 git log, git grep, git status로 직접 검증 후 승인 승인 전에는 Codex가 commit하지 않는 엄격한 게이팅 프로세스 운영 한 번에 하나의 Backlog Task만 진행, Task 완료 전 다음 Task 착수 금지 기술적 의사결정 및 성과 워크스페이스/프로젝트 접근 권한을 DB 레벨(복합 FK, SECURITY DEFINER 트리거)과 애플리케이션 레벨(Server Action 권한 검증)의 이중 방어 구조로 설계 Hard Delete 미구현 원칙 하에 배열 필드 전체교체(replace)를 단일 트랜잭션 RPC로 처리하는 패턴 확립 및 재사용 AS-IS 프로세스 그래프의 순환 참조 탐지에 Tarjan SCC 알고리즘 적용, 차단 오류(Error)와 경고(Warning)를 분리한 이중 Validator 아키텍처 설계 도메인 규칙 위반을 커스텀 Postgres 에러 코드 체계(SIA0104)로 문서화하여 거버넌스 문서와 코드베이스 간 정합성 유지 AI 생성 데이터와 사람이 검증한 데이터를 구분하는 generatedbyai / verified 메타데이터 패턴을 여러 도메인 테이블에 일관되게 적용 진행 상태 ✅ EPIC-01 (인증 / 워크스페이스 / 프로젝트 접근) ✅ EPIC-02 (조직 / 산업 / 프로젝트) 🚧 EPIC-03 (AS-IS 프로세스 그래프) — 그래프 검증, Input/Output 스키마, Business Rule 스키마 구현 완료