Replit, 바이브 코딩 스택의 모든 계층을 지키는 방어 전략

바이브 코딩이 확산되면서 핵심 질문은 “AI가 만들 수 있나”에서 “AI가 만든 것을 신뢰할 수 있나”로 바뀌었다. Replit은 이 답을 하나의 장치가 아니라 **아키텍처 전반의 방어 깊이(defense in depth)**에서 찾는다.

내부 인프라에는 Zero Trust 원칙을 적용한다. 서비스 간 통신은 단기 토큰으로 인증·인가하고, 기본 권한은 최소화하며, 중요한 서비스 묶음은 mTLS로 격리해 한 층이 무너져도 전체로 번지지 않게 설계했다.

개발 환경은 2016년부터 운영해 온 클라우드 샌드박스 위에서 돌아간다. 각 사용자 환경은 서로 분리된 Linux 컨테이너로 실행되며, seccomp-bpf와 추가 하드닝을 적용하고 커널 익스플로잇을 지속 감시한다. Replit은 과거 Dirty Pipe 취약점 1건만 인지했고, 그때도 사용자 영향 없이 대응했다고 밝힌다. 또한 전체 컨테이너 기반 인프라를 microVM으로 전환 중이며, 이는 공유 커널이 없다는 점에서 더 강한 격리를 제공한다.

Replit에서 만든 애플리케이션은 자연스럽게 프론트엔드와 백엔드 분리 구조를 따른다. 이는 단일 클라이언트 앱 뒤에 RLS만으로 접근 제어를 맡기는 방식보다 훨씬 안전하다고 본다. RLS는 PostgreSQL 애플리케이션의 방어 깊이에는 유효하지만, 충분한 컨텍스트를 가진 백엔드의 권한 검증을 대체할 수는 없다는 입장이다.

공급망 보안에는 Determinate Nix를 쓴다. 패키지와 의존성을 지속적으로 최신 상태로 유지해 알려진 취약 버전을 줄이는 방향이며, 애플리케이션 아래쪽의 소프트웨어 공급망 자체를 계속 패치하는 데 초점을 둔다.

개발과 운영도 강하게 분리한다. 애플리케이션마다 독립된 개발 데이터베이스를 제공하고, 파일시스템 스냅샷 기술을 이용해 fork, rollback, 반복 개선이 가능하도록 했다. 여기에 더해 모든 파일시스템은 최소 하루 1회 백업되며, 각 샌드박스에는 append-only git remote가 붙어 있어 .git이 사라져도 전체 히스토리를 복구할 수 있다.

데이터 접근은 기본적으로 스코프 제한이 걸린다. 다른 애플리케이션의 데이터에 접근하려면 Connectors 또는 Data Connectors를 통해 명시적으로 허용해야 하며, 비밀번호와 비밀값은 애플리케이션 코드가 직접 다루지 않도록 투명한 프록시를 거친다. MCP 통합도 동일하게 동작해, 에이전트는 MCP 서버와 직접 통신하지 않고 OAuth 헤더를 주입하는 프록시를 통해서만 오간다. 이 과정에서 prompt injection 계열 공격도 탐지·차단한다.

인증은 개발자가 직접 구현하다가 흔히 만드는 실수를 줄이기 위해 Clerk 기반의 턴키 auth를 제공한다. 빌드 중에는 코드 품질과 보안 문제를 계속 점검하는 shift-left 방식의 평가가 이뤄지고, 배포 직전에는 rule-based SAST/SCA와 LLM reasoning을 함께 쓰는 보안 스캐닝을 수행한다. 여기에 Semgrep과 HoundDog도 결합해 취약점, 공급망 위험, 개인정보 이슈를 넓게 찾는다.

프로덕션은 Google Cloud Platform 위에서 운영되며, 모든 고객에게 개별 GCP Project를 할당한다. 애플리케이션은 Cloud Run에서 실행되고, 모든 배포는 Google Cloud Armor로 DDoS와 WAF 보호를 받는다. Replit은 이 구성이 React2Shell 취약점 대응에도 중요했다고 설명한다.

운영 이후에도 보안 검증은 계속된다.

• HackerOne으로 버그 바운티와 신규 서비스 점검을 수행
• Trail of Bits와 함께 심층 보안 평가를 진행
• 내부 AI red-teaming 하니스로 소스코드를 지속 스캔하고 결과를 검증
• 발견된 루트 원인은 재발 방지용 하드닝으로 연결

결국 메시지는 단순하다. 하나의 계층이 아니라 모든 계층이 서로를 전제로 실패를 가정하는 구조여야 AI가 만든 코드와 플랫폼을 신뢰할 수 있다는 것이다.