Codex ‘항상 승인’ 없이 반복적인 개발 작업을 자동화할 수 있을까?

1편에서 Codex의 Auto-review를 적용한 뒤 승인 알림 때문에 멈추는 빈도가 줄었다고 적었습니다. 하지만 Android 앱을 개발하면서 비슷한 승인 창이 다시 나타났습니다.

Gradle 테스트를 실행하고, Debug APK를 빌드하고, 코드를 조금 더 수정한 뒤 테스트를 다시 실행하는 동안 반복해서 승인을 요청한 것입니다.

승인 화면에는 '항상 승인'이라는 선택지가 있었습니다. 이것을 누르면 당장의 중단은 줄일 수 있었겠지만, 제가 원하는 해결책은 조금 달랐습니다.

비슷한 검증 작업은 자동으로 이어가되, Release 서명이나 운영 배포까지 함께 허용하지 않는 방법을 찾고 싶었습니다.

세 번의 승인 요청, 하나의 질문

당시 화면에 나타난 작업은 대체로 다음과 같았습니다.

요청	실제 목적	왜 확인이 필요했을까?
`git diff --check && ./gradlew test`	변경 검사와 전체 테스트	외부 캐시 쓰기·Release 작업 의존성
`./gradlew assembleDebug`	Debug APK 빌드	당시 실행 환경의 추가 권한 요청
`git diff --check && ./gradlew test`	수정 뒤 같은 테스트 반복	같은 원인이 다시 나타남

승인 창이 발생했다는 사실만으로 모든 요청의 정확한 기술적 원인이 동일했다고 단정할 수는 없습니다. 다만 전체 test 명령의 반복 중단은 재현할 수 있었습니다.

처음에는 Auto-review의 허용 기준을 조정해야 한다고 생각했습니다. 하지만 gradlew로 시작하는 명령을 전부 승인하면 빌드뿐 아니라 더 넓은 작업도 실행할 수 있습니다. 따라서 그렇게 하지 않기로 했습니다.

Codex에 '권한을 늘리지 말고 원인을 찾으라'고 요청했다

이번 과정에서 중요한 변화는 프롬프트의 목표를 바꾼 것이었습니다.

처음에는 승인 요청을 줄이고 싶다는 불편함을 전달했습니다. 이후에는 다음과 같이 검증할 조건을 명확히 요청했습니다.

현재 설정과 실제 승인 원인을 먼저 확인한다. 로컬 검증은 가능하면 기존 샌드박스 안에서 실행한다. bash, gradlew, npm, git 전체를 자동 허용하지 않는다. 위험한 작업을 실제로 실행하지 않은 채 정책을 검토한다. 원인이 승인 정책이 아니면 설정을 바꾸지 않는다.

Codex는 설정부터 고치지 않았습니다. 실제 명령을 실행하는 환경을 확인했고, 결과적으로 두 가지 원인을 찾았습니다.

원인 ① Gradle 캐시가 작업 공간 밖에 있었다

당시 Gradle은 사용자 홈의 전역 캐시 디렉터리에 잠금 파일을 만들려고 했습니다. 하지만 Codex는 작업 공간에 쓰기 권한이 제한된 workspace-write 샌드박스에서 실행하고 있었습니다.

따라서 테스트를 실행하는 과정에서 작업 공간 외부에 쓰기를 시도했고, 읽기 전용 파일 시스템 오류가 발생했습니다.

여기서 필요한 것은 샌드박스를 해제하는 것이 아니라 캐시를 프로젝트 내부에서 사용하도록 실행 환경을 바꾸는 것이었습니다.

원인 ② 전체 테스트가 Release 서명 작업까지 끌어왔다

캐시 위치를 바꾸자 테스트가 더 진행됐지만, 이번에는 전체 test 태스크가 프로젝트의 Release 관련 빌드 작업에 의존하면서 서명 키가 필요해졌습니다.

그때 확인하려던 것은 Debug 단위 테스트였습니다. 서명된 Release APK를 생성하려던 작업이 아니었으므로, 전체 test 태스크가 반드시 필요한 것은 아니었습니다.

범위를 좁혀 다음과 같이 실행하자 테스트가 성공했습니다.

GRADLE_USER_HOME="$PWD/.gradle-user-home" \
ANDROID_USER_HOME="$PWD/.android-user-home" \
./gradlew :app:testDebugUnitTest \
  --no-daemon --max-workers=1

이 단계에서 BUILD SUCCESSFUL을 확인했습니다. 그러나 명령 한 번 성공했다고 문제가 영구적으로 해결된 것은 아닙니다. 다음 Codex 대화에서 다시 기존 명령을 실행하면 같은 중단이 반복될 수 있기 때문입니다.

재발을 막기 위해 실행 절차를 프로젝트에 남겼다

그래서 두 번째 프롬프트에서는 단순 분석 보고로 끝내지 않고 재사용 가능한 검증 스크립트와 작업 지침을 실제로 만들도록 요청했습니다.

그 결과 Android 프로젝트에 다음 스크립트가 추가됐습니다.

scripts/verify-android.sh all

이 스크립트는 정해진 순서로 작업을 실행합니다.

순서	검증 항목	역할
1	`git diff --check`	변경사항의 공백·형식 검사
2	`app:testDebugUnitTest`	Android Debug 단위 테스트
3	`filter-engine:test`	필터 엔진 테스트
4	`app:assembleDebug`	Debug APK 빌드

Gradle 및 Android 사용자 데이터 경로를 프로젝트 내부로 지정하고, 해당 스크립트가 프로젝트의 기본 Debug 검증 방식임을 AGENTS.md에 기록했습니다. 메모리 사용량을 고려해 --no-daemon --max-workers=1도 유지했습니다.

전체 Release 빌드와 서명, 운영 배포는 이 절차에 포함하지 않았습니다. 이 구분이 이번 개선의 핵심입니다.

적용 결과: 승인 규칙을 추가하지 않고도 성공했다

최종 표준 검증 스크립트를 실행한 결과는 다음과 같았습니다.

확인 항목	결과
코드 변경 형식 검사	성공
Android Debug 단위 테스트	성공
필터 엔진 테스트	성공
Debug APK 빌드	성공
해당 실행 중 추가 승인 요청	없음
작업 공간 외부 쓰기	없음
Release 서명·운영 배포	실행하지 않음
기존 샌드박스와 승인 정책	변경 없음

Android Gradle Plugin이 사용자 홈의 일부 경로를 읽으려는 경고는 남았지만, 빌드 성공에는 영향을 주지 않았습니다. 새 스크립트와 프로젝트 작업 지침은 비공개 저장소에 반영해 재사용할 수 있도록 했습니다.

다만 새 Codex 세션을 열었을 때 AGENTS.md의 지침을 자동으로 따라 같은 결과가 나오는지는 아직 별도로 검증하지 못했습니다. 또한 Debug 테스트와 Debug APK 빌드가 성공했다고 해서 Release 서명이나 실제 기기 기능까지 검증된 것은 아닙니다.

'항상 승인'과 이번 개선은 어떻게 다른가?

'항상 승인'으로 해결	이번에 선택한 방법
특정 명령 패턴의 실행을 허용	추가 권한이 필요했던 원인을 수정
허용 규칙의 범위를 별도 관리	기존 샌드박스·승인 정책 유지
비슷한 이름의 위험 명령에 주의 필요	Debug 검증과 Release 작업을 절차상 분리
빠른 반복 승인 감소	검사 명령·캐시 경로·작업 지침을 표준화

물론 새 검증 스크립트도 내부에서 코드를 실행합니다. 프로젝트가 달라지거나 빌드 설정이 바뀌면 스크립트를 다시 검토해야 하고, 이것만으로 모든 보안 위험이 해결된다고 볼 수는 없습니다.

하지만 적어도 이번 프로젝트에서는 더 많은 권한을 주지 않고도 반복적으로 필요했던 검증을 진행할 수 있었습니다.

마무리: 자동 승인보다 먼저 점검할 것

처음에는 승인 정책을 더 느슨하게 만드는 것이 답이라고 생각했습니다. 그러나 실제 개선은 다른 곳에서 시작됐습니다.

중단이 일어난 명령과 실행 환경을 확인했습니다.
원인을 캐시 위치와 테스트 범위로 분리했습니다.
샌드박스를 유지하면서 Debug 전용 검증 명령으로 바꿨습니다.
같은 실수를 반복하지 않도록 스크립트와 작업 지침을 저장했습니다.
실제로 테스트와 APK 빌드를 승인 없이 완료했습니다.

이 경험을 통해 배운 것은 단순합니다.

승인 권한을 넓히기 전에, 지금 허용된 범위에서 제대로 실행할 수 있는 방법을 찾아보는 것.

AI에게 일을 맡길 때도 마찬가지입니다. '자동으로 다 허용해 줘'보다 '왜 멈췄는지 확인하고, 보안을 유지하면서 반복되지 않게 고쳐 줘'가 더 좋은 요청일 수 있습니다.

1편: Codex 승인 알림 때문에 개발이 계속 멈춘다면?

함께 읽으면 좋은 글

이 글은 ONSEMO에서 실제 수행한 점검과 검증 결과를 바탕으로 AI의 작성 보조를 받아 정리했습니다.