"인프라운영" 태그로 연결된 3개 게시물개의 게시물이 있습니다.

보안 공지를 확인하는 것과 대응을 마치는 것은 다르다.

MiWork Guard는 어디가 문제인지 찾고, 무엇부터 고칠지 정리하고, 조치 결과를 다시 검증한다. AI는 근거와 위험을 정리하고, 관리자는 필요한 대응을 판단한다. 그 과정은 신뢰할 수 있는 기록으로 남는다.¹²

제품의 목적을 표현한 삽화. 실제 화면은 아니다. 본문의 이미지를 클릭하면 원본을 볼 수 있다.

왜 지금 필요한가​

AI는 공격자가 보안의 약점을 찾아 악용하는 속도와 규모도 키울 수 있다. 새로운 위협에 대비하는 한편, 이미 알려진 위험을 줄이는 기본 관리가 중요해지는 이유다.³

최근 사례도 같은 과제를 남긴다.

• GitLab은 2026년 10월 12일 중요한 보안 문제의 수정본을 공개하고 빠른 업데이트를 권고했다.⁴
• LiteLLM의 10월 21일 배포물 침해 사건 조사에서는 과거 노출된 관리자 키가 폐기되지 않았던 사실이 드러났다.⁵

수정 방법이 나온 취약점은 보안 업데이트를 제때 적용하는 것만으로도 해당 공격 경로를 막을 수 있다. 다만 업데이트 외의 대응이 필요한 문제도 있다. NIST가 설명하는 ‘예방 정비’ 역시 필요한 수정본의 적용과 결과 확인을 포함한다.⁶

현실의 어려움은 그다음이다. 구매한 제품부터 오픈소스와 라이브러리까지, 공지와 적용 시점이 제각각이다. 우리 회사가 영향을 받는지, 누가 무엇을 처리했고 어떤 일이 남았는지 빠짐없이 따라가기는 쉽지 않다.

무엇을 먼저 고칠지 정리한다​

MiWork Guard는 서버에서 확인한 프로그램과 구성요소를 보안 정보와 대조해 할 일을 정리한다. 관리자가 보고서에서 찾는 답은 세 가지다.¹⁷

• 어디에 있는 프로그램이 문제인가 — 위치와 현재 버전
• 무엇부터 바꿔야 하나 — 목표 버전과 작업별 우선순위
• 바로 고칠 수 있나 — 수정판 유무와 실제 사용 여부를 확인할 항목

AI는 수집 자료를 검토하고 추가로 살펴볼 위험을 정리한다. 서버를 임의로 변경하는 것이 아니라, 관리자의 판단을 돕는 역할이다.¹

긴 경고 목록을 실제로 처리할 작업으로 바꾸는 것. 조치 계획과 작업 목록은 보고서나 엑셀에서 열 수 있는 파일로 저장해 담당자와 공유할 수 있다.⁷

실제 조치 계획 화면. 내부 식별 정보는 제외했다.

조치 결과를 다시 검증하고 기록한다​

점검의 ‘완료’가 업데이트의 완료를 뜻하지는 않는다. 담당자가 실제 조치를 수행한 뒤, MiWork Guard로 다시 점검해 변경이 반영됐는지와 앞서 발견한 문제가 남았는지 확인한다.¹⁷²

최초 점검 결과, 처리 내역, 재검증 결과를 연결하면 무엇을 발견했고 어떻게 대응했으며 이후 무엇이 달라졌는지 확인할 수 있다. 신뢰의 근거는 기록의 존재가 아니라, 조치 결과를 다시 검증했다는 데 있다.²

위변조 방지는 이렇게 확인한 기록을 보호한다. 남은 문제와 확인하지 못한 범위도 함께 남겨 다음 점검과 인수인계의 근거로 삼는다. 확인된 범위 밖의 안전까지 보장하는 것은 아니다.¹²

실제 작업 이력의 일부. 내부 식별 정보는 제외했다.

현재 점검 대상은 Linux 서버와 실행 중인 Docker 컨테이너다. 실제 업데이트는 담당자가 수행하며, 점검하지 못한 영역은 ‘부분 확인’이나 ‘미검사’로 구분한다.¹⁷

보안의 기본을 몰라서가 아니라, 챙겨야 할 것이 너무 많아 놓치는 일이 있다. 그 빈틈을 줄이고, 조치와 재검증까지 이어가는 것. MiWork Guard가 필요한 이유다.

---

참고 자료​

Footnotes​

1. MiWork Guard 공식 소개 및 FAQ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. 제품 담당자 제공 설명 — 현재 제공하는 처리 이력·증빙 통합 및 기록 위변조 방지. 2026년 11월 3일. ↩ ↩² ↩³ ↩⁴

3. NCSC — Frontier AI: what you need to know ↩

4. GitLab — Critical Patch Release 19.4.2, 19.3.5, 19.2.8 — 2026년 10월 12일. ↩

5. LiteLLM — The attack chain behind the v1.107.0 LiteLLM release — 사건일 2026년 10월 21일, 조사 발표일 10월 23일. ↩

6. NIST — Guide to Enterprise Patch Management Planning ↩

7. MiWork Guard 제품 화면 — 조사 보고서, 조치 계획, 취약점 정보 및 감사·작업 이력. 2026년 11월 3일 확인. ↩ ↩² ↩³ ↩⁴

핵심 요약 InfraManager와 미나는 인프라 알람이 발생했을 때 서버, DNS, 인증서, 컨테이너, 담당 정보를 따로 보지 않고 하나의 영향 관계로 묶어 보여주는 것을 목표로 합니다. 운영자에게 필요한 것은 메뉴 목록이 아니라 지금 무엇이 영향을 받는지에 대한 빠른 답입니다.

한밤중 휴대폰이 울립니다. "api.example.com 응답 없음." 잠에서 덜 깬 운영자가 머릿속에 떠올리는 질문은 늘 비슷합니다. 이게 어디 영향을 주는가, 누가 담당이었는가, 같은 일이 예전에 있었는가, 지금 손대도 되는가.

응급실에 환자가 들어왔을 때 의료팀이 가장 먼저 하는 트리아지(triage)와 비슷한 일입니다. 증상 하나로 영향 범위·우선순위·담당을 빠르게 묶어내는 일이죠. 이번 글은 클라우드 인프라가 흔들렸을 때 운영자가 무엇을 보는지 이야기합니다.

메뉴 다섯 군데를 도는 운영의 무게​

기존 운영 화면은 보통 메뉴별로 나뉩니다. 서버 목록, DNS 목록, 컨테이너 목록, 인증서 목록을 따로 봅니다. 각 화면은 잘 정리돼 있지만, 정작 운영자가 알고 싶은 건 그 사이의 관계입니다.

한 도메인이 멈추면 뒤이어 어떤 서비스가 영향받는지, 누가 담당인지, 과거에는 이걸 어떻게 풀었는지. 메뉴 하나하나에는 답이 흩어져 있고, 그걸 머릿속에서 엮는 게 운영자의 역할이었죠.

응급실에 비유하면, 환자 차트는 다 있지만 누가 트리아지를 해주진 않는 상태입니다. 의사는 차트를 한 장씩 펼쳐 가며 머릿속에서 그림을 그려야 하죠.

InfraManager가 묶어내는 운영 체인​

저희가 만들고 있는 InfraManager 는 이 흩어진 정보를 하나의 운영 체인으로 묶어 보여주는 운영 대시보드입니다.

도메인 → DNS → 프록시 → 컨테이너 → 서버 → 백업 → 담당팀 → 런북.

api.example.com 한 줄을 누르면, 시스템이 이 체인을 따라가며 연결된 모든 것을 한 화면에 펼쳐냅니다. 운영자는 이제 "어디 있더라"를 묻는 대신 "어떻게 할까"부터 시작합니다.

비용도 같은 방식으로 봅니다. 이번 달 청구서가 늘었다면, 어느 구독에서 얼마가 늘었고, 그 구독에 어떤 리소스가 매여 있고, 누가 그 리소스를 만들었는지를 함께 보여줍니다. 숫자 하나를 따라가다가 그 뒤에 누가 서 있는지까지 보이는 거죠.

미나 — 운영자의 질문을 받는 트리아지​

InfraManager 위에는 AI 인프라 직원 **미나(MiNa)**가 함께 동작합니다. 운영자가 자연어로 묻기만 하면, 미나는 필요한 도구를 골라 결과를 묶어 답합니다.

운영자가 실제로 던지는 질문은 대략 이렇습니다.

• "이 도메인이 죽으면 뭐가 영향받지?" — 미나는 DNS·프록시·서비스·서버·담당팀을 한 묶음으로 가져옵니다.
• "이번 달 비용은 왜 늘었지?" — 구독·리소스·변경 이력·정리 후보를 함께 보여줍니다.
• "백업 안 되는 서버가 있나?" — 백업 정책·실패 이력·복구 대상을 묶어 답합니다.
• "같은 장애가 예전에 있었나?" — 과거 이벤트·조치 내역·재발 여부를 가져옵니다.

응급실 트리아지가 환자의 증상 하나로 진료 흐름 전체를 결정하듯, 미나는 질문 하나로 운영자가 다음에 봐야 할 화면·자료·사람을 함께 묶어줍니다. 운영자는 메뉴를 다섯 군데 도는 대신 미나에게 먼저 묻고, 시스템이 실제 데이터를 확인하는 흐름이 만들어집니다.

왜 이 방향인가​

인프라 운영에서 가장 어려운 일은 "서버가 살아 있는지" 만 확인하는 게 아닙니다. 장애가 났을 때 영향 범위·담당·과거 사례·지금 손대도 되는지를 빠르게 묶어 다음 행동을 결정하는 일이죠.

이 일은 그동안 사람이 머릿속에 인프라를 외우고 있어야만 가능했습니다. 인프라가 커질수록, 담당자가 바뀔수록 이 방식은 흔들리기 쉽습니다. 시스템이 관계를 기억하고, AI가 그 관계를 운영자에게 답으로 묶어주는 쪽으로 무게를 옮기면, 운영의 부담이 사람의 기억력에서 벗어납니다.

마치며​

저희는 InfraManager와 미나를 사내 인프라 운영에 직접 쓰면서, 한밤중 알람을 받았을 때 운영자가 머릿속 대신 시스템에게 먼저 묻는 흐름을 만들어가고 있습니다.

다음 글에서는 미나가 실제로 어떤 도구를 골라 어떤 답을 묶어내는지, 그 안쪽 흐름을 풀어보겠습니다.

핵심 요약 미나가 가장 먼저 구분해야 하는 것은 사용자가 조회만 원하는지, 실제 인프라 변경을 원하는지입니다. 읽기 작업과 변경 작업을 분리해야 AI 운영 도구가 빠르면서도 안전하게 동작할 수 있습니다.

지난 글에서 미나(MiNa)가 운영자의 질문을 받아 영향 범위·담당·과거 사례를 한 묶음으로 답한다는 이야기를 했습니다. "이 도메인이 죽으면 뭐가 영향받지?"에 미나가 DNS·프록시·서비스·서버·담당팀을 가져다 주는 식이었죠.

그런데 운영자가 던지는 질문이 늘 조회만은 아닙니다. "이 컨테이너 좀 지워줘", "GPU 작업 중지해줘", "이 사용자 계정 묶어줘" 같은 손대는 질문도 섞여 있죠. 같은 미나에게 묻는데 답이 같은 식으로 나오면 위험합니다.

이번 글은 미나가 묻는 한 가지 질문 — "조회만 할 거예요, 손대실 거예요?" 이야기입니다.

같은 응급실, 두 가지 모드​

응급실에서 의료팀이 하는 일은 두 갈래입니다. 환자 차트를 펼쳐 보는 일과, 약을 처방하거나 시술을 결정하는 일. 둘은 같은 의사가 하지만 절차가 완전히 다릅니다. 차트는 일단 빠르게 펼쳐도 환자에게 변화가 없죠. 처방은 잘못되면 환자에게 즉시 영향이 갑니다.

미나가 운영자의 질문을 받았을 때 가장 먼저 하는 일도 이 갈림입니다. "이건 보기만 하는 질문인가, 손대는 질문인가." 같은 미나가 묻고 답하지만, 둘은 다른 길을 탑니다.

빠른 길 — 조회만 묻는 질문​

조회는 빠르게 가도 됩니다.

• "서버 목록 보여줘"
• "GPU 누가 쓰고 있어?"
• "DNS 레코드 어디로 연결돼?"
• "이 도메인 담당팀이 누구야?"

이런 질문에 미나는 깊게 추론하지 않고 곧장 필요한 도구를 호출해 결과를 가져옵니다. 응급실로 치면 차트를 즉시 펼쳐 보여주는 동작이죠. 답이 빨라야 운영자가 다음 판단을 빨리 할 수 있습니다.

신중한 길 — 손대는 질문​

변경 질문은 같은 속도로 가면 안 됩니다. 미나는 다음 세 단계를 거칩니다.

1. 영향 범위 먼저 답하기 (dry-run)

"이걸 지우면 이게 같이 영향받습니다" 를 먼저 보여줍니다. 컨테이너 하나 지우는 요청에도, 그 컨테이너가 떠받치는 사이트·연결된 프록시·로그 보관 정책까지 함께 보여줍니다. 실제로는 아무것도 건드리지 않은 상태죠.

2. 담당팀 확인

"이 영역은 인프라팀입니다", "이건 데이터팀 권한이에요" 처럼 책임 소재를 함께 답합니다. 운영자가 자기 권한 밖 작업을 무심코 진행하지 않도록 보호하는 단계입니다.

3. 명시 승인 대기

운영자가 "OK, 진행해" 를 명시적으로 누르기 전까지 미나는 실행하지 않습니다. 응급실에서 위험한 시술 전에 동의서를 받는 단계와 같습니다.

왜 두 길을 굳이 나누나​

빠른 길만 있으면 위험합니다. 손대는 질문이 들어왔는데 미나가 빠르게 처리해 버리면, 운영자가 영향 범위를 모르는 채 인프라가 바뀌어 버립니다.

신중한 길만 있으면 답답합니다. 단순 조회까지 매번 "정말로 보시겠습니까?" 를 묻기 시작하면, 운영자가 미나에게 묻지 않고 메뉴를 직접 도는 옛 방식으로 돌아갑니다.

빠른 트리아지 + 신중한 처치 — 응급실이 잘 굴러가는 이유와 같은 모양으로, 인프라 운영도 두 트랙이 함께 있어야 합니다.

마치며​

미나는 답을 묶어내는 능력만큼 언제 멈춰서 운영자에게 다시 물을지 아는 능력도 중요합니다. 빠른 답이 필요한 곳에선 빠르게, 신중해야 할 곳에선 한 번 멈춰서 묻는 미나가 저희가 사내 인프라에 매일 함께 쓰고 있는 동료입니다.

다음 글에서는 미나가 따라가는 운영 체인 — 도메인 한 줄에서 시작해 어떻게 백업과 담당팀까지 따라가는지 — 그 안쪽 흐름을 풀어보겠습니다.