장애 대응 시 AI를 활용하여 '세간'의 정보를 조사하는 방법: 유사 사례 검색을 기능 확장으로 통합하기

시스템에서 장애가 발생하면, 먼저 로그를 확인하고 설정을 살펴보고 직전 변경 사항을 확인하며 네트워크나 권한을 의심합니다. 이것이 장애 대응의 기본입니다. 하지만 손안의 환경을 자세히 조사할 수 있다는 사실 때문에 빠지기 쉬운 함정이 있습니다. 바로 '원인은 이 환경 안에 있다'는 전제하에, 어느새 조사 범위를 한정해 버리는 것입니다.

필자 역시 Codex가 Git 작업을 정상적으로 수행하지 못하는 문제를 조사하는 과정에서 이 함정에 빠졌습니다. Codex 자체도 ChatGPT도 설정이나 권한, 샌드박스 등 로컬 환경 측면을 중심으로 조사하고, 원인 후보에 맞춰 설정 변경까지 진행한 결과, 복구 작업이 필요할 정도가 되었습니다. 그럼에도 불구하고 원래의 장애 원인은 명확히 파악되지 않았습니다. 이때 비로소 '애초에 같은 문제가 세간에서 발생하지 않았는지' 일반 공개 정보를 찾아보았고, Windows 버전 Codex의 샌드박스와 Git 작업과 관련된 유사 사례를 공식 GitHub Issues에서 여러 개 발견했습니다. 예를 들어, workspace-write로 .git/index.lock을 생성할 수 없는 사례나, 일반적인 PowerShell에서는 성공하지만 Codex Desktop 내에서는 .git/FETCH_HEAD에 대한 쓰기가 거부되는 사례가 공개되어 있습니다.

물론, 공개된 사례와 필자의 환경이 완전히 동일한 원인이었다고 단정할 수는 없습니다. 하지만 장애 대응 초기 단계에서 이러한 정보들을 파악하고 있었다면, '내 설정이 이상하다'는 가설뿐만 아니라 '제품 측의 알려진 문제나 구현상의 제약은 아닐까'라는 가설을 동시에 가질 수 있었습니다. 결과적으로 불필요한 설정 변경이나 되돌림(hand-back)을 줄일 수 있었을 가능성이 있습니다.

본고에서는 이 경험을 단순한 검색 부족이 아니라, AI를 통한 기능 확장으로서의 문제로 생각합니다. AI를 사용하면 인간이 손안의 로그를 분석할 뿐만 아니라, 공식 정보, Issue Tracker, 유사 오류, 과거 장애 보고까지 단시간에 가로지르며 조사할 수 있습니다. 장애 대응에서 AI의 가치는 답을 생각해 주는 것만이 아닙니다. 인간의 '보이는 범위' 자체를 넓히는 데 있습니다.

장애 대응에서는 구체적인 에러 메시지가 있으면 조사를 진행하기 쉽습니다. Permission denied라면 파일 권한을 조사하고, 이름 해석 오류라면 DNS를 확인하며, 인증 오류라면 자격 증명(credential)이나 토큰을 조사합니다. 각각 합리적인 행동입니다.

문제는 합리적인 조사를 계속하는 것과 올바른 장소를 조사하는 것이 동의어가 아니라는 점입니다.

예를 들어 Git이 .git/index.lock을 생성할 수 없는 경우, NTFS의 ACL, Git 리포지토리의 소유권, 프로세스의 실행 사용자 등을 조사하는 것은 의미가 있습니다. 하지만 Codex의 공식 GitHub Issues에는 Windows 버전의 샌드박스 환경에서 Git 작업을 할 때 .git/index.lock이 Permission denied가 되는 사례가 여러 개 보고되어 있습니다.

더 나아가 2026년 5월에는, 같은 사용자가 동일한 리포지토리를 일반 PowerShell에서 작업할 때는 성공하지만 Codex Desktop 내에서는 .git/FETCH_HEAD에 대한 쓰기가 거부된다는 구체적인 보고도 있습니다. 보고자 자신도 Issue 내에서 OneDrive, 안티바이러스, NTFS 소유권 등을 의심하며 조사하는 데 시간을 보냈다고 설명했습니다.

이는 이번 교훈을 잘 보여줍니다.

로그를 깊이 읽으면 로컬 환경 안에는 얼마든지 조사 대상이 눈에 띕니다. Windows에서 ACL을 조사하면 SID, 상속(inheritance), 소유자(owner), Allow/Deny ACE 등 확인할 항목은 방대합니다. 네트워크라면 DNS, 프록시, 방화벽, 인증서, Credential Manager 등으로 확장될 수 있습니다. 조사 능력이 높을수록 얼마든지 깊이 파고들 수 있습니다.

하지만 장애의 원인이 제품 측에 있다면, 그것들을 100개 항목 확인해도 근본 원인에는 도달하지 못합니다.

장애 대응에서는 '어디까지 깊이 조사할 수 있는가'뿐만 아니라, **'애초에 어떤 탐색 공간을 조사해야 하는가'**를 주기적으로 재검토할 필요가 있습니다.

일반 공개 정보를 조사한다고 하면 단순한 웹 검색을 상상하기 쉽습니다. 하지만 장애 대응에서 정말 가치가 있는 것은 검색 결과 그 자체가 아닙니다. 나 혼자서는 떠올릴 수 없었던 원인 가설을 얻는 것입니다.

장애 발생 시, 인간은 어쩔 수 없이 관측할 수 있는 범위 내에서 가설을 세웁니다. 설정 변경 직후라면 설정을 의심하고, Permission denied라면 권한을 의심하며, 통신에 실패하면 네트워크를 의심합니다. 경험이 풍부한 엔지니어일수록 후보는 늘어나지만, 그럼에도 알고 있는 사상(事象)의 범위에서 완전히 자유로워질 수는 없습니다.

그래서 외부 정보를 추가합니다.

이번 Codex의 예시라면, 로컬 환경만 보고 있을 때는 'Git 권한 설정이 이상하다', 'Windows ACL이 이상하다', '보안 설정을 너무 엄격하게 했다'와 같은 가설이 중심이 됩니다. 하지만 공식 Issue를 검색해 보면, 'Codex의 Windows 샌드박스 자체가 .git에 대해 Deny ACE를 설정하고 있을 가능성', 'Codex 측의 샌드박스 설정 업데이트가 ACL 조작으로 실패하고 있을 가능성', '샌드박스 내부와 일반 PowerShell에서 Git 작업 결과가 다를 가능성'과 같은 다른 가설이 들어옵니다. 실제로 2026년에도 Windows 버전 Codex에 대해 ACL이나 sandbox setup과 관련된 여러 Issue가 보고되었습니다.

여기서 중요한 것은, 검색 결과를 그대로 원인으로 단정하지 않는 것입니다.

유사 Issue가 10건 발견되었다고 해도, 자신의 장애가 동일한 원인이라고는 할 수 없습니다. OS 버전, Codex 버전, sandbox mode, 리포지토리 배치, 인증 방식 등이 다르면 다른 문제일 가능성이 있습니다.

따라서 외부 정보는 '정답'이 아니라, 가설 생성기로 취급합니다.

여기서 AI를 사용하는 방법이 중요해집니다.

장애 발생 시 '이 에러의 원인을 알려줘'라고 AI에게만 묻는다면, AI 역시 주어진 로그나 현재 대화에서 원인을 추측합니다. 그 결과, 가장 그럴듯한 원인 후보를 하나 골라 깊게 파고들기 쉽습니다.

이는 AI에게 '판단'을 요청하는 상태입니다.

반면, AI를 기능 확장(機能拡張)으로 이용할 때는 역할이 다릅니다. 인간이 원래 혼자 짧은 시간에 할 수 없는 작업을 증폭시킵니다.

예를 들어, 로컬 로그에서 특징적인 에러 문자열을 추출하고, 제품명, OS, 버전과 조합하여 검색하는 것입니다. 공식 문서를 Issue Tracker와 동시에 조사합니다. 발견된 10건의 Issue에서 공통 조건을 추출합니다. 자 환경과 일치하는 조건 및 불일치하는 조건을 비교합니다. 기지(既知) 문제인지, 설정 문제인지, 아직 판단할 수 없는 것인지를 정리합니다. 이러한 처리는 인간만으로도 가능하지만 시간이 걸립니다.

AI를 사용하면 조사 범위 자체를 넓힐 수 있습니다.

이는 이전에 정리했던 AI에 의한 업무 개선의 생각 방식에서 말하는 '기능 확장'과 유사한 활용입니다. 단순히 작업 시간을 단축하는 것만을 의미하지 않습니다. 원래라면 시간이나 지식의 제약 때문에 조사할 수 없었던 범위까지 확인할 수 있게 되는 것에 가치가 있습니다.

장애 대응에서는 특히 효과적입니다. 제품 고유의 Issue Tracker, 영어권 정보, 과거 버전의 결함, GitHub Discussions, 릴리스 노트 등, 인간이 하나하나 조사하면 부하가 큰 정보원을 AI로 교차 검증할 수 있기 때문입니다.

다만, 여기서도 AI에게 '원인을 결정해 달라고' 하기보다는,

'조사 가능한 범위를 넓혀 달라고'

생각하는 것이 안전합니다. AI가 찾은 정보를 근거로 인간 또는 AI가 자 환경과의 일치 조건을 재검증합니다. 이 순서라면, AI를 사용함으로써 조사 속도뿐만 아니라 조사 폭(幅)도 넓힐 수 있습니다.

이번 경험을 통해, 장애 대응의 초동 단계에서는 조사를 직렬로 진행하기보다 3개의 레인을 병렬로 시작하는 것이 효율적이라고 생각합니다.

첫 번째는 로컬 조사입니다. 로그, 발생 시각, 직전 변경 사항, 재현 조건, 환경 차이점을 확인합니다.

두 번째는 공식 정보입니다. 공식 문서, Status, 릴리스 노트, 공식 Issue Tracker를 조사합니다.

세 번째가 일반 정보입니다. 같은 제품, OS, 버전, 에러 메시지로 유사 사례를 검색합니다.

중요한 것은 '로컬 조사가 끝난 후에 외부를 조사하는' 것이 아니라는 점입니다.

최소한의 재현 조건과 특징적인 에러가 확보되는 시점에서 외부 조사를 시작해야 합니다.

예를 들어 이번 같은 문제라면, Codex,
Windows,
.git/index.lock

、Permission denied

와 같은 식별성이 높은 구문을 조합하면, 적어도 유사한 이슈가 초기 단계에서 존재하는지 확인할 수 있습니다.

따라서 동종의 보고서가 발견되지 않는다면, 로컬 환경 고유의 문제일 가능성을 높게 추정하고 설정을 더 조사해 보는 것이 좋겠습니다.

반대로 같은 제품, 같은 OS, 같은 에러가 다수 보고되었다면, 제품 측의 문제를 가설 상위로 이동시킵니다.

이 시점에서도 원인이 확정된 것은 아닙니다.

자신의 환경에서 A/B 테스트를 진행합니다.

이번 경우라면, 통상적인 PowerShell에서는 성공하는지, Codex 내에서만 실패하는지. 샌드박스 모드를 변경하면 현상이 바뀌는지. 신규 리포지토리에서도 재현되는지. Codex의 버전을 이슈에 기재된 환경과 비교해 보면 어떤지 등 확인합니다.

이 '외부 정보를 통해 가설을 늘리고, 자신의 환경에서 재검증하는' 왕복 과정이 중요합니다.

반대로 위험한 것은, 가설이 충분히 정리되기 전에 설정 변경으로 나아가는 것입니다.

장애 대응에서는, 변경할수록 관측 대상이 늘어납니다. ACL을 변경하면 '원래 상태'와 '변경 후'의 차이점이 발생하고, 방화벽을 변경하면 네트워크 조건이 바뀝니다. 조사를 위한 변경이 새로운 장애를 만들면, 원래 문제와의 분리가 더욱 어려워집니다.

AI가 조작까지 실행할 수 있는 환경에서는 이 문제가 더 커집니다.

그렇기 때문에, 검색과 분석은 과감하게, 환경 변경은 신중하게라는 역할 분담이 필요합니다.

AI에게 단순히 '원인을 조사해 줘'라고 요청하면, 현재 접근 가능한 환경을 중심으로 조사할 가능성이 있습니다. 따라서 장애 대응에서는 외부 대조(照合)를 처음부터 완료 조건에 포함하는 것이 좋습니다.

장애 원인을 조사해 주세요.
로컬 환경에만 원인을 한정하지 않고, 다음을 병렬적으로 확인해 주세요.
1. 손안의 로그, 설정, 버전, 재현 조건
...

핵심은, '웹도 검색해 주세요'라고 덧붙이는 것 이상의 것입니다.

외부 정보를 원인 가설을 업데이트하는 공식적인 입력 데이터로 취급하게 만드는 것입니다.

더 나아가, 이미 알려진 문제가 발견되었을 경우에도, 쉽게 '이것이 원인입니다'라고 결론 내리게 하지 않는 것이 중요합니다. 유사 사례와 자신의 환경의 차이점을 확인하고, 필요하다면 최소한의 재현 테스트를 진행해야 합니다.

AI로 인해 조사 능력이 높아진 만큼, 처음부터 탐색 범위를 넓게 설정해 둘 필요가 있습니다.

장애 대응이라고 하면, 기술력이 높은 사람일수록 로그를 읽고, 설정을 이해하고, 내부 구조를 추적하며, 원인을 깊이 파헤치는 모습이 상상됩니다.

물론, 그것들은 중요합니다.

하지만 이번 경험을 통해 다시 느낀 것은, 깊게 파는 능력만큼 '옆에도 구멍이 없는지 보는 능력'이 중요하다는 것입니다.

특히 현재는 GitHub Issues, 공식 문서, 릴리스 노트, 장애 정보, 기술 포럼 등 방대한 정보가 공개되어 있습니다. 인간이 그것들을 매번 모두 확인하는 것은 현실적이지 않습니다.

그래서 AI를 사용합니다.

AI에게 답을 결정하게 하는 것이 아닙니다.

인간 혼자로는 조사할 수 없는 범위까지 검색하고, 유사 사례를 모으고, 조건을 비교하며, 가설을 늘리기 위해 사용합니다.

이것은 단순한 노동력 절감이 아니라, 장애 대응 능력 그 자체의 기능 확장입니다.

이번 Codex 문제에서도, 초기에 '자신의 환경'과 '공식 정보'와 '세간의 유사 사례'를 병렬로 확인했더라면, 이후의 조사 방침은 상당히 달랐을 것입니다.

장애가 발생하면, 로그를 본다.

설정을 본다.

그리고 같은 타이밍에, 세간도 본다.

AI가 있는 지금, 이 세 번째 항목을 '시간이 나면 할 조사'로 남겨둘 이유는 상당히 줄어들지 않았을까요?

• OpenAI Codex GitHub Issue #16794「Windows app cannot perform git operations when sandbox settings are set to

from sandbox-induced orphan-SID Deny ACEs」。일반적으로 PowerShell에서는 성공하지만, Codex Desktop 내에서만 Git 작업이 실패하는 사례입니다.

https://github.com/openai/codex/issues/21304?utm_source=chatgpt.com - OpenAI Codex GitHub Issue #18918「Windows sandbox가 writable_roots의 .git 디렉터리에 DENY ACLs를 적용하여 git 커밋을 방해함」。Windows sandbox와
.git
하위의 ACL에 관한 보고입니다.

https://github.com/openai/codex/issues/18918?utm_source=chatgpt.com - OpenAI Codex GitHub Issue #46526「Windows: 승인된 .git 쓰기 권한이 여전히 비효율적임」。2026년 9월 시점에서도 Windows sandbox 환경에서
.git/index.lock을 생성할 수 없는 사례가 보고되고 있습니다.