무슨 일이 있었나요
Trigger.dev가 공식 블로그에서 보안 사고를 공개했어요. 고객들의 환경 변수(environment variables)가 노출됐다는 내용이에요.
Trigger.dev를 처음 들어보는 분도 있을 테니 먼저 짚고 갈게요. 이건 TypeScript로 백그라운드 작업(background job)을 짜고 실행하게 해주는 플랫폼이에요. 이메일 대량 발송, 영상 변환, AI 에이전트 실행처럼 오래 걸리는 일을 웹 서버 요청 안에서 처리하면 타임아웃이 나거든요. 그래서 이런 일은 따로 떼어서 “큐에 넣어두고 나중에 돌리는” 구조로 만드는데, Trigger.dev는 그걸 코드 몇 줄로 해줘요. 오픈소스로도 공개돼 있고, 클라우드 버전을 쓰면 작업이 Trigger.dev 인프라에서 돌아가요.
문제는 여기서 생겨요. 남의 인프라에서 작업을 돌리려면 그 작업에 필요한 비밀값을 플랫폼에 맡겨야 하거든요. 데이터베이스 접속 주소, OpenAI API 키, Stripe 시크릿 키, AWS 액세스 키 같은 것들이요. 이번에 노출된 게 바로 그 환경 변수들이에요.
> 정확한 경위, 영향 범위, 타임라인은 Trigger.dev 공식 공지에 나와 있으니 쓰고 계신다면 원문을 꼭 직접 확인하세요. 이 글은 이런 사고가 왜 치명적인지, 그리고 우리가 뭘 해야 하는지에 집중할게요.
환경 변수 유출이 유독 무서운 이유
환경 변수는 쉽게 말해 “애플리케이션의 열쇠 꾸러미”예요. 코드는 유출돼도 당장 큰일이 안 나는 경우가 많아요. 그런데 환경 변수는 달라요. DATABASE_URL 하나만 있으면 누구든 우리 프로덕션 DB에 그대로 접속할 수 있어요. 클라우드 키가 있으면 우리 계정으로 GPU 인스턴스 수백 대를 띄워 채굴을 돌릴 수도 있고요.
게다가 백그라운드 작업 플랫폼에 들어가는 시크릿은 대체로 권한이 큰 편이에요. 결제 처리, 데이터 동기화, 외부 API 호출 같은 “진짜 일”을 하는 작업이니까요. 읽기 전용 키보다는 쓰기 권한이 있는 키가 들어 있을 가능성이 높아요.
지금 바로 해야 할 일
Trigger.dev를 쓰고 있다면, 영향 대상인지와 상관없이 이 순서로 점검해 보세요.
1. 공지 확인: 공식 안내와 이메일을 보고 내 프로젝트가 영향 범위에 들어가는지 확인하세요.
2. 시크릿 로테이션(교체): 플랫폼에 등록된 키를 전부 새로 발급하고, 기존 키는 폐기하세요. “로테이션”이 어렵게 들릴 수 있는데, 그냥 자물쇠를 바꾸는 일이에요. 누가 열쇠를 복사했을지도 모르면 열쇠를 다시 깎을 게 아니라 자물쇠를 갈아야 하잖아요. 새 키 등록 → 배포 → 정상 동작 확인 → 옛 키 폐기, 이 순서가 안전해요.
3. 접근 로그 확인: DB, 클라우드, 결제 서비스의 접근 로그에 낯선 IP나 평소와 다른 호출이 없는지 보세요. AWS라면 CloudTrail, GCP라면 Cloud Audit Logs부터 보면 돼요.
4. 비용 알림 설정: 클라우드 키가 털리면 제일 먼저 청구서에 티가 나요. 예산 알림을 꼭 걸어두세요.
업계 맥락: 계속 반복되는 “플랫폼 시크릿” 사고
이건 Trigger.dev만의 문제가 아니에요. 2023년 1월 CircleCI는 직원 노트북이 악성코드에 감염되면서 고객 시크릿이 유출됐을 수 있는 사고를 겪었고, 모든 고객에게 시크릿을 교체하라고 권고했어요. 2022년에는 공격자가 Heroku와 Travis CI에 발급된 GitHub OAuth 토큰을 훔쳐서 npm을 포함한 여러 조직의 비공개 저장소를 내려받았고요. 2024년에는 MFA가 꺼져 있던 Snowflake 고객 계정들이 탈취된 자격증명으로 대거 침해됐어요.
공통점은 분명해요. CI/CD, 백그라운드 잡, 데이터 플랫폼처럼 “우리 대신 코드를 실행해주는” 서비스는 구조상 시크릿이 한곳에 모일 수밖에 없어요. 그래서 공격자에게는 아주 매력적인 표적이에요. 한 곳만 뚫으면 수많은 회사의 열쇠를 한꺼번에 손에 넣을 수 있으니까요.
한국 개발자에게 주는 시사점
이번 일을 계기로 “외부 플랫폼에 시크릿을 어떻게 맡길까”를 다시 생각해 보면 좋겠어요.
- 최소 권한 키 쓰기: 백그라운드 작업에 관리자 키를 넣지 마세요. 그 작업에 딱 필요한 권한만 가진 키를 따로 발급하는 게 좋아요.
- 단기 자격증명 활용: 오래 쓰는 고정 키 대신 OIDC 기반 임시 자격증명을 쓸 수 있는지 보세요. GitHub Actions에서 OIDC로 AWS에 붙으면 장기 키를 아예 저장하지 않아도 돼요. 이런 키는 유출돼도 금방 만료돼서 쓸모가 없어져요.
- 시크릿 매니저 경유: 플랫폼에는 AWS Secrets Manager나 Vault에 접근하는 제한된 권한만 주고, 실제 값은 실행할 때 가져오는 방법도 있어요.
- 셀프호스팅 검토: Trigger.dev는 오픈소스라 직접 호스팅할 수도 있어요. 운영 부담은 늘지만, 민감한 데이터를 다루는 팀이라면 따져볼 만해요.
- 로테이션 연습: 사고가 터진 뒤에야 “이 키 어디서 쓰더라?”를 찾기 시작하면 늦어요. 평소에 시크릿 목록과 교체 절차를 문서로 정리해 두세요.
마무리
한 줄 정리: 남이 내 코드를 실행해준다면, 내 열쇠도 거기 있다는 걸 잊지 마세요.
여러분 팀은 외부 SaaS에 등록한 시크릿 목록을 정확히 알고 있나요? 지금 당장 모든 키를 바꿔야 한다면 몇 시간 안에 끝낼 수 있을지, 경험을 나눠주세요.
🔗 출처: Hacker News