자동화를 몇 개 만들어두면 언젠가는 n8n 워크플로우를 밖으로 꺼낼 일이 생깁니다. 혹시 몰라 JSON으로 내려받아 백업해두거나, 동료에게 "이거 그대로 가져다 쓰면 돼" 하고 파일을 넘기거나, 블로그나 깃허브에 예시로 올리기도 하죠. 그때 거의 항상 따라오는 찜찜함이 하나 있습니다. "여기 물려 있던 API 키도 같이 딸려 나가는 거 아닌가?"
결론부터 말하면 파일 쪽은 생각보다 안전하고, 정작 신경 써야 할 곳은 다른 데 있습니다. 2026년 8월에 공개된 조사 하나가 그 지점을 꽤 선명하게 보여줬거든요. 이 글은 본 글 작성 시점(2026년 8월) 기준으로, 내보내기 파일에 실제로 무엇이 남는지와 진짜 새는 통로가 어디인지를 정리합니다.
내보낸 n8n 워크플로우 JSON에는 무엇이 남을까
먼저 오해부터 풀고 가죠. n8n에서 워크플로우를 내보내면 자격증명(Credentials)의 실제 값은 파일에 들어가지 않습니다. API 키나 비밀번호 같은 알맹이는 빠지고, 그 자격증명의 이름과 ID만 참조로 남습니다. 워크플로우가 "어떤 자격증명을 쓰는지"는 알아야 하니 껍데기만 남겨두는 구조입니다.
이건 n8n이 자격증명을 다루는 방식과 이어집니다. 사용자가 키를 입력해 저장하면 n8n은 그 값을 암호화해서 데이터베이스에 넣고, 화면에는 실제 값 대신 가려진 표시만 보여줍니다. 워크플로우가 돌 때만 뒤에서 진짜 값을 꺼내 쓰죠. 그러니 노드 화면에 키가 안 보인다고 해서 이상한 게 아니라, 원래 그렇게 설계된 겁니다.
다만 파일에도 빈틈이 두 군데 있습니다.
- 자격증명 이름 — ID 자체는 민감하지 않지만, 이름은 어떻게 지었느냐에 따라 민감할 수 있습니다. "회사이름_운영서버_관리자계정" 같은 작명은 그 자체가 내부 정보를 흘립니다.
- cURL로 붙여넣은 HTTP Request 노드 — 이게 실질적으로 가장 흔한 사고 지점입니다. cURL 명령을 그대로 가져와 만든 노드에는 인증 헤더가 노드 설정 안에 텍스트로 박혀 있을 수 있습니다. 자격증명 기능을 거치지 않았으니 암호화 대상이 아니고, 내보내면 그대로 따라 나갑니다.
n8n 공식 문서도 내보내기·가져오기 안내에서 이 부분을 짚으며, 공유 전에 해당 정보를 지우거나 익명화하라고 권합니다. 정리하면 "자격증명에 제대로 넣은 키는 안전하고, 노드에 직접 타이핑한 키는 위험하다"가 됩니다.
진짜 새는 통로는 파일이 아니라 인스턴스였다
파일보다 훨씬 크게 뚫린 쪽은 인스턴스 자체입니다. 2026년 8월 보안 업체 GitGuardian이 공개한 조사가 이걸 보여줬습니다. 연구진은 공개된 깃허브 커밋에 노출된 n8n API 토큰을 모아 검증했는데, 수집된 토큰은 4,576개, 함께 딸려 나온 호스트명은 1,255개였습니다.
여기서 실제로 접속이 되는 인스턴스가 896곳이었고, 그중 321곳이 유출된 토큰을 여전히 그대로 받아들였습니다. 도달 가능한 인스턴스의 약 36%죠. 이 숫자에서 눈여겨볼 대목은 따로 있습니다. 보도에 따르면 이건 소프트웨어 취약점을 뚫은 게 아니었습니다. CVE도 없었고요. 유효한 키 하나면 API 경계를 그냥 넘어갔습니다.
토큰이 통과하면 워크플로우, 실행 기록, 변수, 그리고 저장된 자격증명에 관한 정보까지 들여다볼 수 있습니다. 워크플로우 하나가 아니라 그 인스턴스가 연결해둔 서비스 전체가 사정권에 들어가는 셈입니다. 자동화는 원래 여러 서비스를 한데 묶는 도구라, 한 곳이 열리면 뒤에 달린 것들이 줄줄이 따라옵니다.
암호화 키가 지켜주는 범위
셀프호스팅을 쓴다면 암호화 키도 알아둘 만합니다. n8n은 자격증명을 DB에 저장하기 전 암호화하는데, 이때 쓰는 키를 첫 실행 때 자동으로 만들어 ~/.n8n 폴더에 저장합니다. 직접 정하고 싶으면 N8N_ENCRYPTION_KEY 환경변수로 지정하면 되고, 큐 모드로 워커를 여러 개 띄운다면 메인과 모든 워커가 같은 값을 공유해야 합니다.
중요한 건 이 키의 한계입니다. 암호화 키는 DB 파일이 통째로 새어 나갔을 때를 막아주는 장치이지, 정상적인 API 요청을 걸러주지는 않습니다. 유효한 토큰으로 들어온 요청은 n8n 입장에서 그냥 정상 사용자니까요. 위의 321곳이 뚫린 이유가 정확히 이겁니다.
공유·백업 전에 점검할 4가지
| 점검 항목 | 확인할 것 |
|---|---|
| HTTP Request 노드 | cURL로 만든 노드에 인증 헤더가 남아 있는지 |
| 자격증명 이름 | 이름만 봐도 내부 정보가 드러나지 않는지 |
| API 토큰 | 코드·설정 파일에 적어둔 채 커밋하지 않았는지 |
| 인스턴스 노출 | 주소가 외부에 공개된 적이 있는지 |
1. 키는 반드시 자격증명으로 넣으세요. 급하다고 노드 필드에 직접 타이핑하면 암호화 대상에서 빠지고, 내보내기·스크린샷·화면 공유 모두에서 그대로 노출됩니다. cURL 임포트로 만든 노드는 특히 한 번 더 열어보세요.
2. 내보낸 JSON은 열어서 훑어보세요. 파일을 넘기기 전에 에디터로 열고 Authorization, api_key, token, Bearer 정도만 검색해봐도 큰 사고는 대부분 걸러집니다. 30초면 끝나는 일입니다.
3. API 토큰을 코드에 적어두지 마세요. 위 조사에서 토큰이 새어 나온 경로가 바로 공개 깃허브 커밋이었습니다. 실수로 커밋했다가 나중에 지워도, 커밋 기록에는 남습니다. 이미 올라간 적이 있다면 지우는 것보다 토큰을 새로 발급받아 갈아끼우는 편이 확실합니다.
4. 인스턴스 주소를 아무 데나 흘리지 마세요. 토큰과 주소가 함께 노출되면 그 조합만으로 접근이 가능해집니다. 굳이 외부에서 접속할 일이 없다면 공개 노출 자체를 줄이는 게 가장 단순한 방어입니다.
정리
n8n 워크플로우를 공유할 때 파일 자체는 꽤 잘 막혀 있습니다. 자격증명에 제대로 넣은 키라면 내보내기 파일에 실제 값이 들어가지 않으니까요. 문제가 생기는 지점은 늘 그 규칙을 우회한 자리 — 노드에 직접 적어둔 키, 그리고 코드에 남겨둔 API 토큰입니다.
이번 조사에서 확인된 321곳도 정교한 공격을 당한 게 아니라, 어딘가에 적어둔 키가 공개된 곳에 남아 있었을 뿐이었습니다. 자동화가 편리한 만큼 한 번 열리면 뒤에 묶인 서비스가 함께 노출된다는 점도 같이 기억해둘 만합니다.
오늘 만들어둔 워크플로우 중 하나만 골라 JSON으로 내보낸 뒤 Authorization으로 한 번 검색해보세요. 아무것도 안 나오면 그대로 두면 되고, 뭔가 나온다면 지금이 고칠 때입니다.
댓글 없음:
댓글 쓰기