Heremes 서버에 Open AI가 경고를 했을 때, 내가 먼저 멈춘 것들

AI 에이전트 서버에서 인증 오류가 떴을 때, 재시작 대신 범위 확인과 키 교체를 먼저 선택한 과정과 그 이유를 기록했습니다.

Hermes 서버에서 인증 오류 경고가 떴습니다. 익숙한 문제로 보여서 토큰을 다시 넣고 재시작하려던 순간, 다른 신호 하나가 발목을 잡았습니다. 그래서 가장 먼저 한 일은 복구가 아니라 무엇이 문제인지 확인하는 것이었습니다.

인증 오류, 익숙한 문제로 생각

AI 에이전트 서버에서 인증 오류 경고가 떴습니다. 처음에는 익숙한 종류의 문제로 보였습니다. 모델을 호출하는 인증 토큰이 없거나 만료됐고, 그래서 Gateway와 예약 작업 일부가 멈춘 상황이었습니다. 서비스 운영을 하다 보면 가장 먼저 떠오르는 대응은 대개 같습니다. 토큰을 다시 넣고, 프로세스를 재시작하고, 멈춘 작업을 다시 돌리는 일입니다.

그런데 이번에는 그 순서를 바로 밟지 않았습니다. 오류를 따라가던 중 인증 문제와 별개로, 민감한 설정과 인증 정보를 외부로 보내려는 것으로 의심되는 구성도 함께 확인했기 때문입니다. 인증 오류는 서비스 중단의 직접 원인이었지만, 그보다 더 중요한 질문은 따로 생겼습니다. "지금 이 서버에서 무엇이 바깥으로 나갈 수 있지?"였습니다. 보안 문제 입니다.

복구를 먼저 하지 않은 이유

AI 에이전트를 여러 개 붙여 운영하면, 대화형 AI를 쓸 때와는 다른 종류의 문제가 생깁니다. 모델 제공자 인증, Telegram 같은 메시징 채널, 콘텐츠 도구, 데이터베이스, 예약 작업, 플러그인과 MCP 서버가 하나의 운영 환경 안에서 연결됩니다. 각각은 생산성을 높여줍니다. 하지만 한 곳에 권한과 비밀값이 모일수록, 작은 설정 하나가 만들 수 있는 영향 범위도 넓어집니다.

그래서 문득 제가 확인을 한 것은 현재 서버가 갖고 있는 권한의 범위 확인이었습니다.

우선 어떤 기능이 실제로 멈췄는지 나눠 봤습니다. 대화 Gateway가 멈춘 것인지, Telegram 연결 자체가 끊긴 것인지, 예약 실행만 실패한 것인지 구분해야 했습니다. 당장 영향을 받는 채널과, 늦게 처리해도 되는 자동화를 분리해야 어떤 것을 우선 처리해야할지 판단할 수 있기 때문이죠.

"서버가 안 된다"로 단순화할 것이 아니라, 무엇이 어디까지 왜 멈췄는지부터 나눠야 다음 판단이 가능합니다.

두 문제를 하나로 묶지 않았다

인증 오류와 비정상적인 동작을 하나의 원인으로 보지 않았습니다. 인증 토큰 누락은 로그로 확인할 수 있는 직접 원인이었습니다. 반면 외부 전송을 시도한 것으로 의심되는 정황은 별도의 위험 신호였습니다. 장애가 한 번에 발생하면 우리는 하나의 설명으로 빨리 해결하고 싶어집니다. 하지만 서로 다른 문제를 하나로 취급하면, 복구는 빨라 보여도 원인을 놓칠 수 있습니다.

의심스러운 정황은 표면적으로는 별 문제가 없어보일 수도 있습니다. '동기화', '상태 확인', '헬스체크' 같은 이름은 안심을 주지만, 이름과는 달리 엉뚱한 기능을 수행하기도 했습니다. 새 플러그인이나 MCP를 설치할 때는 이름보다 실행 명령, 읽는 파일, 외부 통신 대상, 유지 주체를 먼저 봐야 한다는 점을 다시 배웠습니다. 자동화가 편리할수록 "무슨 일을 해주나"만큼 "무엇을 읽고 어디에 보내나"를 관리해야합니다.

API 키 관리부터 다시 시작

위험 가능성을 확인한 뒤에는, 사용하지 않는 API 키를 환경 파일에 계속 보관할 이유가 없다고 판단했습니다. 미사용 키를 정리하고, 노출 가능성을 배제할 수 없는 핵심 키는 새로 교체했습니다. 환경 파일의 접근 권한도 제한했습니다. 여기서 중요한 것은 키를 교체했다는 사실보다, 키를 보관하는 방식 자체를 다시 본 일입니다. 지금은 쓰지 않는 키라도 서버 안에 남아 있으면, 언젠가 누군가가 그것을 발견해 쓸 수 있는 것이 됩니다. 그리고 git에 올라가 있는 key는 없는지도 확인을 해야했죠.

다만 키를 새로 발급했다고 이 일이 끝난 것은 아닙니다. 새 키를 적용하는 일과, 기존 키가 실제로 폐기됐는지 확인하는 일은 다릅니다. 다른 자동화나 다른 서버가 이전 키를 참조하고 있다면, 무작정 폐기했을 때 또 다른 장애를 만들 수 있습니다. 반대로 기존 키를 그대로 남겨두면 교체의 의미가 약해집니다. 그래서 지금은 각 서비스 콘솔에서 이전 키의 폐기 여부를 확인하고, 용도가 분명하지 않은 자격증명은 사용처부터 확인하는 단계를 남겨두고 있습니다.

'정상 작동'과 '안전 확인'은 다른 검증 항목입니다.

다시 정한 운영 원칙

앞으로 일정 기간 더 기다리며 볼 것도 있습니다. 의심스러운 외부 연결 시도가 다시 나타나지 않는지, 인증 만료가 재발했을 때 운영자에게 충분히 빠르게 알려지는지, 사용하지 않는 플러그인과 환경변수가 다시 쌓이지 않는지 확인해야 합니다. 서비스가 다시 응답한다고 해서 안전까지 자동으로 증명되는 것은 아닙니다.

이번 일에서 AI는 도움이 됐습니다. 로그를 읽고, 가능한 원인을 넓히고, 점검 항목을 구조화하는 데는 AI가 빠릅니다. 하지만 어떤 연결을 끊을지, 어떤 키를 교체할지, 언제 자동화를 다시 재개할지 결정하는 것은 AI에게 맡길 수 없었습니다. 잘못된 격리는 업무를 멈추게 할 수 있고, 성급한 복구는 더 큰 위험을 남길 수 있기 때문입니다.

그래서 앞으로의 운영 원칙을 조금 더 명확히 했습니다. 새 MCP나 플러그인은 설치 전에 실행 명령과 권한, 외부 통신 대상을 확인합니다. 환경변수에는 실제로 필요한 키만 둡니다. 인증 오류와 외부 통신 이상이 함께 보이면, 예약 작업 복구보다 격리와 영향 범위 확인을 먼저 합니다. 그리고 자동화가 내놓는 진단은 참고하되, 자격증명 교체와 서비스 재개 같은 판단은 사람이 최종 승인합니다.

AI 에이전트를 운영한다는 것은 일을 대신 처리하게 만드는 데서 끝나지 않습니다. 여러 도구가 움직이는 환경에서 어디까지 자동으로 맡기고, 어디서 사람이 멈춰야 하는지 경계를 설계하는 일에 더 가깝습니다. 불안한 상황이었지만 서버를 더 빨리 복구하는 것보다 먼저 멈춰야 할 순간을 알려줬습니다.

FAQ

Q. AI 에이전트 서버에서 인증 오류가 발생하면 가장 먼저 해야 할 일은 무엇인가요?
토큰 재발급이나 재시작부터 하기보다, 어떤 기능이 실제로 멈췄는지 범위를 먼저 나눠야 합니다. 동시에 다른 이상 신호가 없는지 로그를 함께 확인하는 것이 안전합니다.

Q. 의심스러운 외부 통신 구성을 발견했을 때 어떻게 대응해야 하나요?
'동기화', '헬스체크' 같은 이름만 보고 정상 기능으로 단정하지 않고, 실행 명령과 통신 대상을 직접 확인해야 합니다. 원인이 불확실하면 인증 오류와 별개 문제로 다뤄야 합니다.

Q. API 키를 교체한 뒤 기존 키는 바로 폐기해도 되나요?
다른 자동화나 서버가 기존 키를 참조하고 있을 수 있으므로, 폐기 전에 사용처를 먼저 확인해야 합니다. 새 키 적용과 기존 키 폐기 확인은 별개의 단계로 진행하는 것이 안전합니다.

Q. MCP나 플러그인을 설치할 때 무엇을 먼저 확인해야 하나요?
이름이 주는 안심과 별개로, 실행 명령, 읽는 파일, 외부 통신 대상, 유지 주체를 먼저 확인하는 것이 필요합니다.

Q. AI에게 보안 관련 판단까지 맡겨도 되나요?
로그 분석이나 점검 항목 구조화에는 AI가 도움이 되지만, 연결 차단·키 교체·서비스 재개처럼 되돌리기 어려운 결정은 사람이 최종 승인하는 것이 안전합니다.