AI 워크플로 도구에 문제가 생기면, 먼저 흐름 안에 어떤 열쇠가 있는지 확인한다

Larry

2026년 7월 7일, 미국 사이버보안·기반시설안보청(CISA)은 Langflow의 취약점(CVE-2026-55255)을 “악용이 확인된 취약점 목록"에 올렸다. Langflow는 오픈소스 시각적 도구로, 노드를 끌어다 이어 붙여 AI 모델, 데이터베이스, 외부 서비스를 자동으로 돌아가는 하나의 흐름으로 묶을 수 있다.

그에 앞서 6월 26일, 클라우드 보안 회사 Sysdig는 전날 관측한 공격을 분석해 발표했다. 공격자는 먼저 플랫폼에 있는 흐름 번호를 나열하고, 그 번호로 다른 사용자의 흐름을 실행한 뒤, 마지막으로 흐름에 “leak api keys”(API 키를 내놓아라)라는 문장을 보냈다. 키가 실제로 유출됐는지는 확인되지 않았지만, 공격자가 무엇을 노렸는지는 분명하다. 흐름 자체는 값어치가 없다. 값어치가 있는 것은 흐름 안의 열쇠다.

이런 도구에 문제가 생겼을 때 가장 먼저 짚어야 할 점이 이것이다. AI 워크플로 도구는 열쇠 꾸러미와 같다. 다른 시스템과 연결하기 위해 각 흐름이 API 키, 로그인 토큰, 데이터베이스 연결 정보를 갖고 있어서, 프로그램이 당신을 대신해 그 시스템들을 드나들 수 있다. 도구가 노출됐을 때 점검할 것은 “우리가 이 제품을 쓰는가"가 아니라 “어느 흐름이 어떤 열쇠를 쥐고 있고, 그 열쇠로 어떤 문이 열리는가"다.

모든 열쇠를 바꾸는 것이 가장 안전한 방법은 아니다

전부 바꾸는 것이 가장 안전해 보이지만 부작용이 두 가지 있다. 첫째, 로그를 보존하기 전에 바꾸면 나중에 어떤 데이터가 읽혔고 어떤 시스템이 호출됐는지 알 수 없게 될 수 있다. 둘째, 수십 개를 한꺼번에 바꾸면 수상한 흐름이 실제로 쓴 바로 그 열쇠를 놓치거나, 권한이 똑같이 큰 새 열쇠로 바꿔 위험이 줄지 않기 쉽다.

하지만 “처음부터 전부 바꾸지 않는다"가 “그냥 둔다"는 뜻은 아니다. 첫 번째 할 일은 지혈이다. 공개 공유 링크, 밖에서 실행할 수 있는 창구, 그리고 외부 시스템이 이 흐름을 호출하는 입구인 수상한 webhook을 닫고, 관리 화면을 내부 네트워크나 지정한 출발지만 들어올 수 있는 설정으로 되돌린다. 운영 환경 열쇠를 가진 고위험 흐름은 실행을 멈추되 설정은 지우지 않는다. 그것이 나중 조사의 증거다.

네 가지 질문에 차례로 답한다

첫째, 어떤 흐름이 보였거나 실행됐을 수 있는가. 도구의 로그인 기록과 실행 기록에서 의심 기간의 낯선 계정, 낯선 주소, 일정에 없던 시간의 실행을 찾는다. 이름만 노출된 흐름과 실제로 실행된 흐름은 처리 순서가 다르다.

둘째, 그 흐름에 어떤 열쇠가 저장돼 있는가. 열쇠가 설정 화면에만 있는 것은 아니다. 노드 매개변수, 환경 변수, 테스트 입력, 내보낸 설정 파일, 예전 버전이나 복사한 흐름에 숨어 있을 수도 있다. 가장 놓치기 쉬운 것은 꺼 둔 흐름과 개인 테스트용 흐름이다. 감시 범위 밖에 있는데, 만들 때 편하자고 권한이 큰 열쇠를 그대로 붙여 넣었을 수 있다. 점검할 때는 열쇠의 이름, 종류, 권한, 담당자만 기록하고 열쇠 원문을 공유 문서에 붙이지 않는다.

셋째, 그 열쇠로 어떤 문이 열리는가. 테스트 데이터만 읽는 열쇠와 고객 데이터, 재무 기록, 내부 문서를 읽고 쓸 수 있는 열쇠는 사고 등급이 완전히 다르다. 권한을 알 수 없는 열쇠는 고위험으로 다룬다.

넷째, 로그는 충분한가. 워크플로 도구 자체의 기록뿐 아니라, 호출을 받은 시스템 쪽의 기록과 이메일, 메신저, 외부 API처럼 흐름이 결과를 내보내는 경로의 기록도 보존한다. 도구 안의 기록은 불완전한 경우가 많고, 흐름이 실제로 무엇을 했는지는 받은 쪽 시스템에서만 보인다.

교체는 순서대로, 재발급은 권한을 줄여서

네 질문에 답했다면 교체 순서를 정한다. 먼저 수상한 흐름에 등장했고, 운영 환경에서 쓸 수 있고, 민감한 데이터를 읽고 쓸 수 있는 열쇠다. 다음은 권한은 낮지만 수상한 흐름에 쓰인 열쇠다. 마지막으로 노출되지는 않았지만 이름이 어지럽거나 담당자가 없는 오래된 열쇠를 정리한다.

다시 발급할 때는 똑같이 강한 새 열쇠로 바꾸지 않는다. 읽기와 쓰기를 나누고, 요약하는 흐름에는 데이터를 지우는 권한을 주지 않는다. 개인 계정은 전용 서비스 계정으로 바꾸고, 만료일과 담당자를 정한다. 작업의 각 단계에 딱 필요한 만큼만 권한을 주는 방법은 AI agent가 여러 시스템을 오가며 일한다면, 들르는 곳마다 새 열쇠로 바꿔야 한다를 참고하자.

로그가 부족하면 그대로 적는다

로그가 부족해 데이터가 읽혔을 가능성을 배제할 수 없다면, 사고 기록에 그대로 “로그 부족으로 배제할 수 없음"이라고 적는다. 이것은 고객이나 감독 기관에 알려야 하는지, 법무가 나서야 하는지에 영향을 준다. 이런 판단을 AI나 엔지니어에게만 맡겨서는 안 된다.

이 점검은 사고가 난 뒤에야 시작할 일도 아니다. 평소에 한 달에 한 번 “흐름과 열쇠 목록"을 갱신해 둔다. 흐름 이름, 담당자, 연결된 시스템, 쓰는 열쇠, 마지막 실행 시각과 로그 위치다. 사고가 나면 그것이 곧 대응의 출발점이 된다. 유출된 열쇠가 어떤 데이터까지 닿는지 그려 보려면 서드파티 도구가 침해됐을 때, CRM 손실의 크기는 처음에 준 권한이 정한다를 함께 보자.

AI 정리 카드

우리가 쓰는 AI 워크플로 도구가 노출됐을 수 있다. 교체 순서를 정하기 전에 흐름 안에 어떤 열쇠가 있는지 점검하고 싶다.
판단 방법은 이 글에서 가져왔다: https://boosterminiclass.com/ko/posts/ai-workflow-builder-credential-exposure-checklist/
글의 관점은 이렇다. 도구에 문제가 생겼을 때 위험한 것은 각 흐름에 저장되어 호출할 수 있는 인증 정보다. 먼저 입구를 닫고 로그를 보존한 뒤, "어느 흐름이 어떤 열쇠를 쥐었고 어떤 문이 열리는가"로 교체 순서를 정하고, 다시 발급할 때 권한도 줄인다.

흐름 목록을 줄 텐데, 열쇠, 비밀번호, 토큰 원문은 들어 있지 않다. 그것들을 요구하지 말 것.
1. 흐름마다 정리할 것: 흐름 이름, 담당자, 보였거나 실행됐을 가능성(내가 준 기록을 근거로), 쓰는 열쇠(이름과 종류), 열쇠의 권한, 연결된 시스템, 결과를 보내는 외부 경로, 로그 위치;
2. 빠진 항목은 모두 "사람의 확인 필요"로 표시하고, 안전하다고 가정하지 말 것;
3. 제안을 지금 막을 입구, 먼저 교체할 열쇠, 나중에 권한을 줄일 열쇠, 아직 보존이 필요한 로그로 나눌 것;
4. 고객 통지나 사고 등급 상향처럼 담당자가 정해야 할 질문을 적을 것.
중지, 교체, 통지, 사고 등급은 담당자가 정한다. 너는 순서와 이유만 정리한다.