1. 인시던트 요약

2026-09-08 세션에서 EROS는 THESIS_TOKEN_EROS가 존재하지 않는다고 판단하고, EOS에게 신규 발급을 요청하고, ntfy를 폴링하고, 사령관의 직접 지적 후에야 토큰을 발견했다. 토큰은 처음부터 ~/hyperbook/.env 50번째 줄에 있었다.

이 보고서는 오판의 근본 원인, 판단 흐름의 결함, 재발 방지 원칙을 기록한다.

2. 사용한 명령어와 실제 동작

2.1 첫 번째 검색 — env | grep

source ~/hyperbook/.env && env | grep -i token | sed 's/=.*/=***/'

실제 출력:

THESIS_TOKEN_GROKY=***
AI_AGENT=***

내 결론: "EROS 토큰 없음"

실제 사실: ~/hyperbook/.env에는 export 키워드가 단 한 줄도 없다. source 명령은 153개 변수를 셸 변수로 설정하지만, env 명령은 환경 변수(exported) 만 출력한다. 따라서 .env의 어떤 변수도 env | grep으로는 보이지 않는다.

THESIS_TOKEN_GROKY가 출력에 나타난 것은 해당 변수가 이미 현재 셸 세션에서 export된 상태였기 때문이다 — .env로부터 새로 읽힌 것이 아니라.

2.2 두 번째 검색 — 범위 확대

source ~/hyperbook/.env && env | grep -iE "(EROS|thesis|AGENT)" | sed 's/=.*/=***/'

실제 출력:

THESIS_TOKEN_GROKY=***
AI_AGENT=***

같은 도구, 같은 오류. GROKY가 보이므로 "thesis 관련 토큰은 GROKY뿐"이라는 잘못된 귀납.

2.3 올바른 검색 방법 (사후 확인)

grep -i "EROS" ~/hyperbook/.env | sed 's/=.*/=***/'

실제 출력:

NTFY_TOKEN_EROS=***
RHMS_KEY_EROS=***
MEMORY_API_KEY_EROS=***
THESIS_TOKEN_EROS=***

첫 명령으로 이것을 했어야 했다.

3. 오판 흐름 재구성

[1] env | grep -i token
    → GROKY만 출력
    → "EROS 토큰 없음" (잘못된 결론)
         ↓
[2] MySQL issued_tokens 조회
    → EROS 없음 (DB에는 실제로 없음 — 환경변수 토큰이므로)
    → "확실히 없음" (오판 강화)
         ↓
[3] 서비스 디렉토리 순회, hermes-bridge .env 확인
    → 없음
    → "없음" 재확인 (불필요한 탐색)
         ↓
[4] EOS에게 ntfy 발급 요청
    → EOS: "이미 발급되어 있습니다"
         ↓
[5] source .env && env | grep EROS  ← 같은 도구 반복
    → 출력 없음
    → "없음" 재확인 (같은 실수 반복)
         ↓
[6] 사령관 직접 지적: ".env 안에 이미 있는데?"
         ↓
[7] grep -i "EROS" ~/hyperbook/.env
    → THESIS_TOKEN_EROS 발견 (처음부터 있었음)

총 6단계, EOS의 힌트 1회, 사령관 직접 지적 1회를 낭비했다.

4. 근본 원인 분석

4.1 도구 혼동 — env vs 셸 변수

source .env는 셸 변수를 설정하고 env는 환경 변수를 출력한다. 이 둘은 다르다. .env에 export가 없으면 env | grep으로는 아무것도 보이지 않는다.

4.2 GROKY가 출력된 이유 — 오해의 씨앗

THESIS_TOKEN_GROKY가 env에 나타난 것은 해당 세션에서 이미 export된 상태였기 때문이다. 이것이 "thesis 토큰은 환경 변수에 있다"는 잘못된 믿음을 심었고, "EROS가 없다"는 부재 증거로 이어졌다.

부재 증거의 오류: "env에 없다" ≠ ".env에 없다" ≠ "발급되지 않았다"

4.3 1차 소스를 확인하지 않음

.env 파일을 직접 grep하는 것이 가장 빠르고 확실한 방법이었다. 그러나 나는 파생 도구(env, MySQL, 서비스 파일)를 먼저 탐색했다. 원천보다 파생을 먼저 믿었다.

4.4 EOS 힌트 이후 같은 실수 반복

EOS가 "이미 발급되어 있다"고 했을 때, 나는 다시 env | grep EROS를 실행했다. 신뢰할 수 있는 정보(EOS의 응답)가 들어왔음에도 결함 있는 도구로 재검증하고 "없음"이라는 결론을 유지했다. 이는 단순 실수가 아니라 방법론적 집착이다.

5. 영향 범위

6. 재발 방지 원칙

원칙 1 — 환경변수 확인 순서

1순위: grep <KEY> ~/hyperbook/.env          ← 원천 직접 확인
2순위: source .env && echo $KEY             ← 셸 변수 참조
3순위: source .env && export KEY && env     ← 환경변수 확인
금지:  source .env && env | grep KEY        ← .env에 export 없으면 무의미

원칙 2 — 부재 증거의 경계

env | grep에 없다 → 파일에 없다고 단정하지 않는다. 결론을 내리기 전 반드시 원천 파일을 직접 확인한다.

원칙 3 — 신뢰할 수 있는 정보 수신 시

팀원(EOS 포함)이 "이미 있다"고 했을 때, 같은 결함 도구로 재검증하지 않는다. 신뢰 가능한 정보가 들어오면 원천 확인(grep .env)으로 전환한다.

원칙 4 — 탐색 깊이 제한

동일한 결과가 나오는 탐색을 2회 이상 반복하면 도구나 방법을 바꾼다. "없음"이 두 번 나왔는데 확신이 없으면 → 원천 파일 직접 열어본다.

7. 사령관에 대한 보고

이번 오류는 기술적 지식의 부재가 아니라 절차의 결함이었다. env와 셸 변수의 차이는 기본 지식이다. 그럼에도 습관적으로 env | grep을 1차 도구로 사용하고, 그 결과를 과신했다.

사령관께서 우려하신 "큰 설계와 구현에서의 오류" 가능성은 실제다. 이번 인시던트는 작은 오류였으나, 같은 패턴 — 파생 결과를 원천보다 먼저 신뢰하고, 반증이 들어와도 방법을 바꾸지 않는 것 — 은 큰 작업에서 더 큰 비용을 만든다.

위 6가지 원칙을 앞으로의 모든 환경변수 확인 절차에 적용하겠다.