바이브 코딩 AI 개발 보안 및 해킹 주의보 | SSH 및 공유기 포트 개방은 절대 하지 않는다·API 키관리 주의 등

바이브 코딩·AI 보조 개발 환경에서 가장 먼저 지켜야 할 우선순위는 외부 포트 차단 → MFA → AI·외부코드 권한 제한 → 키 분리 → 오프라인 백업 순이다. Cursor·Claude Code·Copilot Agent처럼 터미널과 파일에 직접 손대는 도구를 쓰는 개인 개발자일수록, 공유기 포트 개방·개발 서버 노출·API 키 유출·계정 탈취가 한 번에 연쇄 사고로 이어질 수 있다. 아래 13가지 수칙과 사례·체크리스트는 CISA·Cloudflare·Docker·GitHub·OWASP·Tailscale·NCSC·VS Code 등 공식 권고를 바탕으로, 로컬·홈서버·NAS 환경에서 바로 적용할 수 있도록 정리했다.

1. 먼저 핵심 결론

가장 치명적인 사고는 대체로 다음 경로로 발생한다.

1. 외부에 열린 SSH·RDP·NAS·DB·개발 서버
2. 탈취된 이메일·GitHub·클라우드 계정
3. GitHub·npm·MCP·확장 프로그램을 통한 악성 코드 실행
4. AI 에이전트에 부여한 과도한 터미널·파일·클라우드 권한
5. 유출된 API 키와 운영 계정
6. NAS와 함께 삭제되는 가짜 백업

따라서 실무 우선순위는 다음과 같다.

외부 포트를 없애고 → 모든 계정에 MFA를 설정하고 → AI와 외부 코드의 권한을 제한하고 → 키를 분리하고 → 오프라인 백업을 확보한다.

포트·SSH·원격 관리를 인터넷에 열어두면 공격자가 24시간 자동으로 로그인 시도와 취약점 탐색을 할 수 있다. 「나중에 닫아야지」라고 미루다가 실제 침해로 이어지는 경우가 많다. 2차 인증(MFA)은 GitHub·Google·Microsoft·이메일·SNS 계정부터 무조건 설정하고, NAS·홈서버는 Tailscale 같은 승인 기기 기반 접속으로 전환하는 것이 안전하다.

그림 1. 우선순위 — 외부 포트 차단 → MFA → 권한 제한 → 키 분리 → 오프라인 백업

2. SSH·원격 접속을 외부에 개방하지 않는다

2.1. 왜 위험한가

SSH 자체가 무조건 취약한 프로토콜이라는 뜻은 아니다. 문제는 인터넷에 관리 인터페이스를 직접 노출하면 공격자가 24시간 자동으로 로그인 시도와 취약점 탐색을 할 수 있다는 점이다.

공격자는 다음을 노린다.

• 약하거나 재사용된 비밀번호
• 유출된 SSH 개인키
• 오래된 SSH·VPN·공유기 취약점
• 잘못 설정된 관리자 계정
• 비밀번호 로그인 허용
• 루트(root) 로그인 허용
• 패치되지 않은 원격 관리 프로그램

CISA(미국 사이버보안 인프라 보안국)도 인터넷에 노출된 SSH·RDP·관리 인터페이스를 위험 서비스로 분류하고, 불필요한 원격 서비스를 비활성화하도록 권고한다.

• CISA Edge Device Security
• CISA StopRansomware Guide

2.2. 현실적인 사고 사례

1. 홈서버에 SSH 포트를 개방한다.
2. 자동화된 공격 봇이 해당 IP와 포트를 발견한다.
3. 과거 다른 서비스에서 유출된 비밀번호를 대입한다.
4. 로그인에 성공하거나 취약한 계정을 확보한다.
5. .env, SSH 키, 브라우저 데이터, NAS 공유 폴더를 찾는다.
6. 클라우드 계정이나 다른 서버로 공격 범위를 넓힌다.

2.3. 실천 방법

• 공유기 포트포워딩을 사용하지 않는다.
• UPnP·NAT-PMP·공유기 원격 관리를 끈다.
• SSH뿐 아니라 RDP·VNC·NAS 관리 페이지도 외부에 열지 않는다.
• 외부 접속은 Tailscale 같은 승인 기기 기반 방식으로 바꾼다.
• 부득이하게 임시 개방했다면 작업 직후 반드시:
• 포트포워딩 삭제
• 방화벽 규칙 삭제
• SSH 서비스 중지 여부 확인
• 로그인 기록 확인
• 사용한 인증 키와 계정 점검

2.4. 표현상 주의

「공인 IP를 노출하지 않는다」는 말은 정확히는 서버의 원본 공인 IP와 관리 서비스를 인터넷에 공개하지 않는다는 뜻이다. 인터넷을 사용하는 이상 접속한 서비스에는 사용자의 출발지 공인 IP가 보일 수 있다. 완전히 IP를 없애는 개념은 아니다.

3. 개발 서버·NAS·DB 포트를 개방하지 않는다

3.1. 0.0.0.0과 127.0.0.1의 차이

• 127.0.0.1 또는 localhost → 현재 컴퓨터 안에서만 접속 가능
• 0.0.0.0 → 컴퓨터의 모든 IPv4 네트워크 인터페이스에서 접속을 받음

예를 들어 Vite 공식 문서도 0.0.0.0으로 설정하면 LAN 및 공용 주소를 포함한 모든 주소에서 연결을 받는다고 설명한다.

• Vite Server Options

0.0.0.0으로 실행했다고 곧바로 인터넷 전체에 공개되는 것은 아니다. 하지만 다음 조건이 겹치면 노출될 수 있다.

• OS 방화벽에서 허용됨
• 같은 와이파이 또는 사내 LAN에서 접근 가능
• 공유기에 포트포워딩이 설정됨
• UPnP가 자동으로 포트를 개방함
• IPv6 주소로 직접 접근 가능
• 클라우드 방화벽이나 보안 그룹이 전체 허용됨
• Docker가 호스트 포트를 외부 인터페이스에 게시함

그림 2. 혼자 개발하면 localhost(127.0.0.1)에 바인딩

3.2. 특히 위험한 서비스

• NAS 관리자 페이지
• SMB·FTP·WebDAV
• MySQL·PostgreSQL·MongoDB
• Redis
• Jupyter Notebook
• Vite·Next.js 등 개발 서버
• 디버그 콘솔
• Docker API 및 Docker socket

Docker 공식 문서는 호스트 주소를 지정하지 않고 포트를 게시하면 기본적으로 모든 호스트 주소에 게시되며, 외부에서 접근 가능해질 수 있다고 경고한다. 127.0.0.1에 게시하면 호스트 내부로 범위를 제한할 수 있다.

• Docker Port Publishing
• Docker Engine Security

Docker socket 접근 권한은 컨테이너 생성·호스트 파일 마운트 등으로 이어질 수 있기 때문에 사실상 강력한 관리자 권한으로 취급해야 한다.

3.3. 현실적인 사고 사례

1. AI가 개발 서버 접속 문제를 해결한다며 0.0.0.0으로 변경한다.
2. 개발자는 방화벽 상태를 확인하지 않는다.
3. 동일 네트워크의 다른 기기에서 개발 서버에 접근할 수 있게 된다.
4. 개발 서버가 소스맵·환경 설정·디버그 기능을 노출한다.
5. 공격자가 소스 코드나 내부 API 정보를 확보한다.

3.4. 실천 방법

• 혼자 개발한다면 기본적으로 127.0.0.1을 사용한다.
• Docker 포트도 호스트 주소를 생략하지 않는다. 예: -p 127.0.0.1:5432:5432
• DB는 로컬 또는 전용 내부망에서만 받는다.
• 개발 서버를 외부 공개용 웹서버처럼 사용하지 않는다.
• 외부 테스트가 필요하면 Cloudflare Access 같은 인증 계층을 둔다.
• 사용하지 않는 서비스는 단순히 방화벽만 막지 말고 종료한다.

4. Tailscale 등 승인된 기기만 접속하는 방식을 쓴다

4.1. 왜 직접 포트 개방보다 나은가

Tailscale은 서비스 포트를 인터넷 전체에 공개하는 대신, 인증된 사용자와 기기가 구성하는 사설 네트워크에서 접근하게 만든다.

이 방식의 장점은 다음과 같다.

• 원본 관리 포트를 인터넷 전체에 공개하지 않음
• 사용자·기기별 접근 통제 가능
• NAS·서버별 접근 범위 제한 가능
• 분실 기기 제거 가능
• 네트워크와 서비스 단위의 최소 권한 적용 가능

Tailscale Grants는 기본 거부와 최소 권한 원칙을 기반으로 사용자·기기·대상·포트별 접근 권한을 정의할 수 있다.

• Tailscale Grants

원격 코딩·NAS 접속 구조는 Tailscale 메시 VPN 원격 코딩 보안 위키에서도 다룬다.

그림 3. 열어두지 말고 승인 접속·터널로

4.2. Tailscale만 설치했다고 끝은 아니다

다음과 같이 설정하면 위험하다.

• 모든 기기가 모든 기기에 접근 가능
• 가족 PC·업무 PC·개발 서버·NAS가 모두 같은 권한
• 분실한 노트북을 제거하지 않음
• Tailscale 계정에 MFA가 없음
• 퇴출된 사용자 계정이 계속 유지됨

4.3. 권장 구조

• 개인 PC → NAS HTTPS만 허용
• 개발 PC → 개발 서버 포트만 허용
• 관리자 기기 → NAS 관리 페이지 허용
• 가족 기기 → 미디어 서비스만 허용
• 일반 기기 → SSH·DB·관리 페이지 접근 금지

즉, Tailscale은 「내부망이니까 전부 신뢰」가 아니라 연결된 뒤에도 필요한 기기만 필요한 서비스에 접근하도록 제한해야 한다. 시놀로지 NAS를 사용한다면 외부 포트 대신 Tailscale로 별도 기기를 등록하고, 불필요할 때는 NAS를 종료하거나 디스크를 분리해 두는 것도 한 방법이다.

5. Cloudflare Tunnel에는 반드시 Cloudflare Access를 붙인다

5.1. Tunnel이 해결해주는 것

Cloudflare Tunnel은 서버에서 Cloudflare로 아웃바운드(outbound) 연결을 만든다. 따라서 원본 서버에 직접 인바운드 포트를 열지 않고 서비스를 제공할 수 있다.

장점:

• 원본 IP 직접 노출 감소
• 공유기 포트포워딩 불필요
• 원본 서버로 직접 우회 접근하는 경로 감소
• Cloudflare 보안 기능 적용 가능

• Cloudflare Tunnel

그림 4. Tunnel만으로는 부족 — Access+MFA가 인증

5.2. 가장 흔한 오해

「Tunnel을 만들었으니 자동으로 비공개 서비스가 되겠지.」

아니다. 공개 호스트명을 연결하고 Access 정책을 적용하지 않으면 서비스가 인터넷에 공개될 수 있다.

Cloudflare Access는 애플리케이션 앞에서 사용자를 인증하고, Allow 정책과 일치하는 사용자만 접근시킨다. Access 애플리케이션은 기본 거부 방식으로 설정할 수 있다.

• Cloudflare Access 자체 호스팅 애플리케이션

5.3. 반드시 확인할 것

• Access 애플리케이션이 실제 호스트명에 적용됐는가
• 허용 이메일·조직·사용자가 제한됐는가
• MFA가 요구되는가
• 세션 유효기간이 너무 길지 않은가
• 로그아웃 상태나 시크릿 창에서 접속이 차단되는가
• 원본 서버에 직접 접근할 수 있는 다른 포트가 남아 있지 않은가
• Access 토큰 검증이 적용됐는가

5.4. 현실적인 사고 사례

1. 로컬 관리자 페이지를 Tunnel에 연결한다.
2. URL이 복잡하므로 아무도 모를 것이라고 생각한다.
3. Access 인증을 적용하지 않는다.
4. URL이 브라우저 기록·로그·채팅·검색엔진 등을 통해 노출된다.
5. 관리자 페이지 자체의 취약점이나 약한 인증이 공격받는다.

URL을 모르게 만드는 것은 인증이 아니다.

6. API 키·비밀번호를 철저히 관리한다

6.1. .env는 보안 금고가 아니다

.env는 비밀정보를 코드와 분리하기 위한 편의 수단이다. 다음 상황에서는 그대로 유출될 수 있다.

• 실수로 Git에 커밋
• AI 에이전트가 읽음
• 악성 패키지가 환경변수를 읽음
• 화면 공유나 스크린샷에 표시
• 터미널 로그에 출력
• 백업·동기화 서비스에 저장
• 개발 서버 설정 오류로 파일이 제공됨

6.2. 최소 권한이 중요한 이유

예를 들어 Cloudflare 전체 관리자 토큰이 유출되면 공격자가 DNS 변경, 도메인 트래픽 탈취, Tunnel 설정 변경, 보안 정책 해제 등을 수행할 수 있다. 반면 특정 Zone의 DNS 레코드 수정만 가능한 토큰이라면 피해 범위가 제한된다.

• Cloudflare API Token Permissions
• GitHub API 자격증명 보안

6.3. 실천 방법

• Proton Pass 등 신뢰할 수 있는 패스워드 관리자를 사용한다.
• 서비스별로 완전히 다른 비밀번호를 생성한다.
• API 키는 용도별·환경별(개발·테스트·운영)로 분리한다.
• 읽기 전용으로 충분하면 쓰기 권한을 주지 않는다.
• 전체 계정 권한 대신 특정 프로젝트만 허용한다.
• 가능한 경우 만료일을 설정한다.
• 장기 키보다 임시 자격증명이나 역할 기반 인증을 사용한다.
• GitHub Push Protection과 Secret Scanning을 활성화한다.

• GitHub Push Protection

API 키·비밀번호·세션 토큰·개인키는 코드·AI 채팅·GitHub·스크린샷에 올리지 않는다. AI에게 .env 내용을 그대로 붙여넣는 행위도 동일한 유출 경로다.

7. AI 코딩 도구에 전체 권한을 주지 않는다

7.1. 기존 자동완성과 AI 에이전트는 다르다

일반 자동완성은 코드를 제안하는 수준이지만, AI 에이전트는 다음을 직접 수행할 수 있다.

• 파일 읽기·수정·삭제
• 터미널 명령 실행
• 패키지 설치
• 웹페이지 읽기
• Git push
• 클라우드 API 호출
• DB 수정
• 배포
• MCP 도구 호출

VS Code 공식 문서도 에이전트가 현재 사용자 권한으로 명령을 실행하고, 클라우드 리소스 변경이나 배포·결제 작업까지 수행할 수 있다고 설명한다.

• VS Code AI Agent Security

그림 5. 웹 읽기·.env·자동승인·운영 로그인을 동시에 주지 말 것

7.2. 가장 위험한 조합

다음 네 가지를 동시에 주면 특히 위험하다.

1. 인터넷에서 외부 콘텐츠를 읽을 수 있음
2. .env와 홈 폴더를 읽을 수 있음
3. 터미널 명령을 자동 승인함
4. 운영 클라우드·DB 자격증명이 로그인돼 있음

웹페이지나 README에 숨겨진 프롬프트 인젝션이 에이전트 행동을 바꾸면, 로컬 비밀정보를 읽고 외부로 전송하려 시도할 수 있다.

OWASP는 AI 에이전트의 주요 위험으로 프롬프트 인젝션, 도구 악용, 데이터 유출, 과도한 자율성 및 고위험 작업의 무승인 실행을 제시한다.

• OWASP AI Agent Security Cheat Sheet

Orca 병렬 위키 포스팅처럼 여러 에이전트를 동시에 돌릴 때는 권한 범위를 더 좁혀 두는 것이 안전하다.

7.3. 실천 방법

• YOLO·Autopilot·Bypass Approvals·Skip Permissions를 상시 사용하지 않는다.
• sudo 명령은 자동 승인하지 않는다.
• 파일 삭제·DB 변경·배포·DNS 변경은 직접 확인한다.
• 홈 폴더 전체가 아니라 프로젝트 폴더만 열어준다.
• .env, 개인키, 인증서 파일은 수동 승인 대상으로 지정한다.
• 가능한 경우 에이전트 샌드박스나 Dev Container를 사용한다.
• 운영 자격증명이 없는 별도 개발 계정으로 실행한다.
• AI가 만든 변경 사항은 diff로 확인한다.
• 웹 검색과 고권한 터미널 실행을 무제한으로 동시에 허용하지 않는다.

8. 출처 불명 MCP·확장 프로그램을 설치하지 않는다

8.1. MCP와 확장은 단순한 프롬프트가 아니다

MCP(Model Context Protocol) 서버와 에디터 확장은 실제 로컬 프로그램으로 실행될 수 있다. 권한에 따라 다음이 가능하다.

• 로컬 파일 접근
• 환경변수 접근
• 명령 실행
• 브라우저 및 외부 서비스 접근
• GitHub·Slack·DB·클라우드 API 호출
• 데이터를 외부 서버로 전송

VS Code 공식 문서는 확장 프로그램과 MCP 서버가 로컬 시스템의 파일에 광범위하게 접근하고 임의 코드를 실행할 수 있다고 경고한다.

• VS Code AI Agent Security

MCP 공식 보안 지침도 도구 호출을 코드 실행 표면으로 보고, 승인·샌드박싱·최소 권한이 필요하다고 설명한다.

• MCP Security Best Practices

8.2. 실천 방법

• 제작자와 배포 경로를 확인한다.
• 실제 설치 및 실행 명령을 확인한다.
• 요구하는 파일 경로와 네트워크 권한을 확인한다.
• GitHub·DB·브라우저·파일시스템 MCP를 한꺼번에 연결하지 않는다.
• 읽기 작업에는 읽기 전용 토큰을 사용한다.
• 사용하지 않는 MCP 서버는 중지·삭제한다.
• 설정이 변경되면 다시 검토한다.
• 가능하면 MCP 서버를 샌드박스 안에서 실행한다.

8.3. curl | bash가 위험한 이유

원격 서버에서 받은 내용을 확인하지 않고 즉시 셸에 실행시키는 구조다.

• 서버가 침해됐을 수 있음
• 다운로드 내용이 이후 변경됐을 수 있음
• OS·홈 폴더·환경변수에 접근할 수 있음
• sudo까지 붙이면 시스템 전체 변경 가능

최소한 다운로드한 파일, 공식 배포처, 서명·체크섬을 검증해야 한다. 출처 불명의 curl | bash 명령은 실행하지 않는다.

9. 운영 환경과 개발 환경을 분리한다

9.1. 왜 분리해야 하나

개발 중에는 다음과 같은 실수가 흔하다.

• AI가 테이블을 초기화함
• 테스트 코드가 전체 데이터 삭제 쿼리를 실행함
• 개발 로그에 개인정보가 출력됨
• 잘못된 API 주소로 운영 서비스에 요청함
• 테스트 메일이나 알림이 실제 고객에게 전송됨
• 운영 관리자 키가 악성 패키지에 노출됨

운영 키와 개발 키가 같으면 로컬 PC의 작은 사고가 운영 전체 사고로 이어진다.

그림 6. 개발·운영 키·DB·계정을 분리한다

9.2. 분리해야 할 것

• 프로젝트
• 계정
• API 키
• 데이터베이스
• 스토리지 버킷
• 결제 시스템
• 이메일 발송 서비스
• DNS·도메인 권한
• 클라우드 조직과 역할
• 로그 및 분석 데이터

OWASP도 운영 비밀정보와 개발 비밀정보를 분리하고 운영 비밀정보 접근 범위를 줄이도록 권고한다.

• OWASP Secrets Management Cheat Sheet

9.3. 권장 구조

• 개발 환경: 가짜 데이터, 제한된 키, 삭제 가능한 DB
• 스테이징: 운영과 유사하지만 실제 고객정보 없음
• 운영 환경: 별도 계정, 별도 키, 수동 승인 배포

개발용 계정에는 다음 권한을 주지 않는 것이 좋다.

• 운영 데이터 전체 삭제
• 결제 실행
• DNS 변경
• 사용자 계정 삭제
• 백업 삭제
• 로그 삭제

실제 개인정보 대신 가짜·마스킹 데이터를 사용하고, 운영 API 키·DB를 로컬 개발에 연결하지 않는다.

10. 업데이트와 백업을 미루지 않는다

10.1. 업데이트가 중요한 이유

공격자는 반드시 새로운 취약점만 사용하는 것이 아니다. 이미 패치가 공개된 취약점을 계속 악용한다.

특히 우선 업데이트할 것:

• 공유기
• NAS DSM 및 패키지
• VPN·Tunnel 클라이언트
• Docker
• 브라우저
• 에디터와 확장 프로그램
• 패키지 관리자
• 인터넷에 닿는 서버
• 지원 종료된 장비

CISA는 실제 악용이 확인된 취약점 목록을 운영하며, 인터넷에 노출된 시스템의 패치를 우선 적용하도록 권고한다.

• CISA Known Exploited Vulnerabilities Catalog

10.2. NAS 한곳에 있는 백업은 충분하지 않다

PC 파일을 NAS에 복사해도 다음 조건이면 같이 털릴 수 있다.

• NAS 공유 폴더가 항상 마운트돼 있음
• PC 계정이 백업 삭제 권한을 가짐
• NAS 관리자 계정이 탈취됨
• 랜섬웨어가 NAS 공유 폴더까지 암호화함
• 동일 계정으로 클라우드 백업도 삭제 가능함

CISA는 중요 데이터의 오프라인·암호화 백업을 유지하고 실제 복원 테스트를 수행하도록 권고한다. 접근 가능한 백업은 랜섬웨어가 함께 암호화하거나 삭제할 수 있기 때문이다.

• CISA StopRansomware Guide

10.3. 최소 백업 구조

• 원본 데이터
• NAS 또는 별도 저장장치 백업
• 평소 연결되지 않은 오프라인 백업 또는 삭제 방지(불변) 백업

그리고 반드시 복원 테스트를 해야 한다.

백업 파일이 있다는 것과 실제로 복구할 수 있다는 것은 다르다.

11. 노출됐다고 판단되면 키부터 폐기한다

11.1. 왜 Git에서 삭제만 하면 안 되는가

이미 push된 비밀정보는 다음 위치에 남을 수 있다.

• Git 커밋 기록
• 다른 사람의 clone
• fork
• Pull Request
• CI/CD 로그
• 캐시
• 검색 인덱스
• AI 대화 기록
• 빌드 결과물

GitHub 공식 문서도 비밀번호·토큰 같은 비밀정보가 노출됐다면 저장소 기록을 지우기 전에 먼저 해당 비밀정보를 폐기하거나 교체해야 한다고 명시한다.

• GitHub 저장소에서 민감정보 제거

11.2. 사고 대응 순서

1. 노출된 키·토큰·비밀번호 폐기
2. 새 키 발급
3. 기존 로그인 세션 종료
4. MFA 및 계정 복구 수단 확인
5. 로그인·API·배포·결제 로그 확인
6. Git 기록 및 CI 로그 정리
7. 영향받은 서비스와 데이터 범위 확인
8. 키 권한을 더 작게 재설계
9. Secret Scanning과 Push Protection 적용

「비공개 저장소였으니 괜찮다」거나 「몇 분 만에 지웠으니 괜찮다」거나 「아무도 못 봤겠지」라고 가정하면 안 된다.

12. GitHub 코드도 무조건 의심하고 검증한다

12.1. 정확히 언제 위험해지는가

단순히 Git 저장소를 clone하거나 pull하는 행위만으로 일반적으로 프로그램이 자동 실행되는 것은 아니다.

위험은 주로 다음 순간 발생한다.

• 에디터에서 신뢰된 Workspace로 열 때
• 확장 프로그램이 프로젝트 설정을 읽을 때
• 패키지를 설치할 때
• postinstall 등 설치 스크립트가 실행될 때
• 빌드·테스트·Make 명령을 실행할 때
• Docker 이미지를 빌드하거나 실행할 때
• 개발 컨테이너를 실행할 때
• MCP 설정을 승인할 때
• 프로젝트 태스크·디버그 설정을 실행할 때
• Husky 같은 도구가 Git hook을 구성할 때

VS Code Workspace Trust의 Restricted Mode는 낯선 프로젝트의 자동 코드 실행, 태스크, 디버깅 및 에이전트 실행을 제한한다.

• VS Code Workspace Trust

12.2. 스타가 많으면 안전한가

아니다. 스타와 포크 수는 참고 자료일 뿐 보안 인증이 아니다.

가능한 위험:

• 유지관리자 계정 탈취
• 악성 업데이트 배포
• 이름이 유사한 가짜 패키지
• 의존성 탈취
• 잠복 후 특정 사용자만 공격
• 광고·검색 결과를 이용한 가짜 저장소
• 과거에는 정상이었지만 이후 소유권이 바뀐 프로젝트

GitHub는 직접 의존성뿐 아니라 그 의존성이 사용하는 간접 의존성도 공급망에 포함되며, 악성 코드와 취약점이 프로젝트까지 영향을 줄 수 있다고 설명한다.

• GitHub Supply Chain Security

12.3. 실행 전 확인할 것

• 저장소 주소와 제작자가 정확한가
• 공식 웹사이트가 연결한 저장소가 맞는가
• 최근 소유자나 유지관리자가 바뀌지 않았는가
• 최근 릴리스와 커밋이 비정상적이지 않은가
• package.json 설치 스크립트
• Dockerfile·Compose 파일
• .vscode 설정
• Dev Container 설정
• Makefile과 셸 스크립트
• MCP 설정
• GitHub Actions
• 새로 추가된 의존성
• 난독화된 코드 또는 외부 전송 코드

README에 적힌 명령도 그대로 복붙하지 않는다. 스타·포크 수가 적은 신규 프로젝트는 특히 주의하고, 유명한 프로젝트도 계정 탈취·공급망 공격 가능성이 있으므로 검증한다.

12.4. 도구로 보완

• Dependabot Alerts 활성화
• Dependency Review 사용
• lockfile 커밋
• Secret Scanning 활성화
• Push Protection 활성화
• 설치 전 패키지 이름·제작자·다운로드 경로 확인

단, 자동 스캐너가 「문제 없음」이라고 해도 악성 코드가 없다는 보장은 아니다.

13. 브라우저·클라우드 관리자 권한을 분리한다

13.1. 브라우저가 중요한 이유

브라우저에는 다음 정보가 집중돼 있다.

• 로그인 세션
• Google·Microsoft 계정
• GitHub
• 클라우드 콘솔
• 결제 서비스
• 이메일
• SNS
• 비밀번호 관리자
• OAuth 연동 권한

AI 브라우저 에이전트나 악성 확장 프로그램이 관리자 세션과 같은 브라우저 프로필에서 동작하면 피해 범위가 커진다.

13.2. 권장 분리

일반 프로필

• 검색
• SNS
• 일반 웹서핑

개발 프로필

• GitHub
• 개발 문서
• 개발용 서비스
• 개발 계정

관리자 프로필

• AWS·GCP·Cloudflare
• 도메인 등록기관
• 결제
• 운영 DB
• 조직 관리자 계정

관리자 프로필은 평소 닫아두고, 필요한 작업 때만 사용한다. AWS·GCP·Cloudflare·GitHub 관리자 토큰을 로컬 프로젝트에 저장하지 않는다.

13.3. 주의

브라우저 프로필 분리는 편리한 경계일 뿐 완전한 보안 샌드박스는 아니다. 운영체제 계정이 탈취되거나 악성 프로그램이 실행되면 다른 프로필 데이터도 위험할 수 있다.

더 강한 분리가 필요하면 별도 OS 사용자, 별도 VM, 별도 관리자 기기, 하드웨어 보안키를 사용한다.

14. 모든 로그인 서비스에 2차 인증을 무조건 설정한다

2차 인증(MFA)은 「중요한 서비스만」이 아니라 로그인 가능한 모든 서비스에 설정한다. 특히 Google·Microsoft·이메일·SNS 계정은 다른 계정의 비밀번호 초기화 통로이므로 최우선으로 보호한다.

그림 7. 패스키·보안키 우선, 이메일이 마스터 계정

14.1. 적용 대상

개발과 연결된 모든 로그인 계정에 적용한다.

• Google
• Microsoft
• Apple
• GitHub
• GitLab
• Supabase
• Turso
• Vercel
• Cloudflare
• AWS·GCP·Azure
• 도메인 등록기관
• 이메일 발송 서비스
• 결제 서비스
• Proton Pass 등 패스워드 관리자
• Tailscale
• NAS 계정
• Discord·Slack
• SNS 계정

CISA는 이메일·파일 저장소·원격 접속·관리자 계정을 포함해 가능한 모든 서비스에 MFA를 적용하고, 특히 관리자와 민감정보 접근 계정에는 피싱 저항성 MFA를 사용하도록 권고한다.

• CISA MFA 가이드
• CISA Protect Our World with MFA

14.2. MFA 방식의 권장 순서

대체로 다음 순서로 강하다.

1. 패스키 또는 하드웨어 보안키
2. 인증 앱의 숫자 일치 방식
3. 인증 앱 TOTP 일회용 코드
4. SMS 또는 이메일 코드

CISA는 보안키를 피싱에 가장 강한 방식으로 안내하고, 문자나 이메일 코드는 더 강한 방법을 사용할 수 없을 때 쓰는 가장 약한 방식으로 분류한다.

14.3. 왜 SMS보다 패스키가 나은가

SMS 코드는 다음 공격에 상대적으로 약하다.

• 가짜 로그인 사이트에 코드 입력
• SIM 스와핑
• 전화번호 탈취
• 문자 가로채기
• 사회공학을 통한 통신사 계정 탈취

패스키와 FIDO 보안키는 접속한 사이트의 도메인을 암호학적으로 확인하기 때문에, 가짜 로그인 사이트에 인증정보를 넘기는 피싱에 더 강하다.

14.4. Google·Microsoft·이메일 계정이 최우선인 이유

이메일은 다른 서비스의 비밀번호 초기화 통로다. 이메일 계정이 털리면 공격자는 다른 서비스의 비밀번호 재설정 메일 수신, 보안 알림 삭제, 가입된 서비스 목록 파악, 사용자를 사칭한 지인 공격, GitHub·클라우드 계정 복구 시도, Google·Microsoft 소셜 로그인을 통한 연쇄 접근 등을 할 수 있다.

영국 NCSC도 이메일 계정이 탈취되면 공격자가 다른 계정의 비밀번호를 재설정할 수 있으므로 이메일에 고유한 비밀번호와 2단계 인증을 적용해야 한다고 권고한다.

• NCSC 이메일 계정 보안

Google이나 Microsoft 계정으로 여러 서비스에 소셜 로그인했다면 해당 계정은 사실상 통합 마스터 계정이다.

14.5. SNS에도 MFA가 필요한 이유

SNS 계정은 단순한 게시용 계정이 아니다. 지인을 사칭한 금전 요구, 악성 링크 배포, 개발자·회사 신뢰도 악용, 계정 복구용 개인정보 수집, GitHub나 이메일 피싱에 활용, 광고 계정과 결제수단 악용 등으로 이어질 수 있다.

14.6. 복구 수단도 함께 준비해야 한다

MFA를 켰지만 휴대폰을 잃어버리면 본인도 계정에 들어가지 못할 수 있다.

• 복구 코드를 다운로드한다.
• 패스워드 관리자나 암호화 저장소에 보관한다.
• 가능하면 종이로 출력해 안전한 곳에 둔다.
• 보안키를 2개 등록해 하나는 예비로 보관한다.
• 복구 이메일과 전화번호가 최신인지 확인한다.
• 이전 휴대폰과 사용하지 않는 인증 수단을 제거한다.
• 사용하지 않는 로그인 세션·연동 앱·기기는 정기적으로 제거한다.

• GitHub 2FA 복구 방법
• Google 백업 코드

15. 실제로 자주 발생할 수 있는 연쇄 사고 예시

15.1. 사례 A: GitHub 계정 하나로 전부 털리는 경우

1. GitHub 비밀번호를 다른 사이트와 재사용한다.
2. 다른 사이트의 비밀번호가 유출된다.
3. 공격자가 GitHub 로그인에 성공한다.
4. 저장소와 GitHub Actions Secret을 조사한다.
5. 악성 커밋이나 워크플로 변경을 시도한다.
6. 연결된 Vercel 배포까지 영향을 받는다.
7. 서비스 코드·환경변수·운영 데이터가 노출된다.

차단 방법: GitHub 패스키/MFA, 고유 비밀번호, 최소 권한 토큰, 브랜치 보호, Secret Scanning.

15.2. 사례 B: 이메일 탈취로 모든 계정이 연쇄 탈취되는 경우

1. 사용자가 Google 계정에 MFA를 설정하지 않는다.
2. 피싱 사이트에 비밀번호를 입력한다.
3. 공격자가 Gmail에 로그인한다.
4. GitHub·Vercel·Cloudflare 비밀번호 초기화를 요청한다.
5. 초기화 메일을 이용해 계정들을 차례로 탈취한다.
6. 보안 알림 메일을 삭제한다.
7. DNS와 배포 환경까지 변경한다.

차단 방법: Google·Microsoft 계정에 패스키 또는 보안키, 복구 수단 정리, 세션 점검.

15.3. 사례 C: AI 에이전트와 악성 README가 결합되는 경우

1. 출처 불명 GitHub 저장소를 내려받는다.
2. AI 에이전트에게 「README대로 설치해줘」라고 지시한다.
3. README나 설치 스크립트에 악성 명령이 들어 있다.
4. 에이전트가 자동 승인 상태로 패키지를 설치한다.
5. 설치 스크립트가 환경변수와 토큰에 접근한다.
6. 개발자의 GitHub·클라우드 키가 유출된다.

차단 방법: Restricted Mode, 자동 승인 해제, 샌드박스, .env 접근 차단, 설치 스크립트 검토.

15.4. 사례 D: NAS 백업까지 함께 암호화되는 경우

1. NAS의 SMB 포트가 외부에 공개돼 있다.
2. 계정 또는 NAS 취약점이 공격받는다.
3. 공격자가 NAS 관리자 권한을 확보한다.
4. PC 원본과 NAS 백업을 함께 암호화하거나 삭제한다.
5. 사용자는 백업이 있다고 생각했지만 복원할 데이터가 없다.

차단 방법: 외부 SMB 차단, Tailscale 사용, NAS MFA, 관리자 계정 분리, 오프라인·불변 백업.

16. 바로 적용할 최우선 체크리스트

16.1. 오늘 바로 할 것

• [ ] 공유기 포트포워딩 전체 확인
• [ ] UPnP·공유기 원격 관리 끄기
• [ ] SSH·RDP·NAS·DB 외부 포트 닫기
• [ ] 개발 서버를 127.0.0.1에 바인딩
• [ ] Google·Microsoft·이메일에 패스키/MFA 설정
• [ ] GitHub·Cloudflare·Vercel·Supabase 등에 MFA 설정
• [ ] MFA 복구 코드 별도 보관
• [ ] AI 자동 승인·YOLO 모드 끄기
• [ ] 사용하지 않는 MCP·확장 삭제
• [ ] 노출 가능성이 있는 API 키 폐기·재발급
• [ ] GitHub Push Protection·Dependabot 활성화
• [ ] NAS 외부 접속을 Tailscale 또는 Access 기반으로 변경
• [ ] Cloudflare Tunnel 앞에 Access 인증 적용
• [ ] 오프라인 또는 불변 백업 1개 확보
• [ ] 실제 백업 복원 테스트

그림 8. 오늘 바로 할 체크 — 포트·MFA·AI·키·백업

16.2. 절대 하지 말아야 할 것

• [ ] SSH·RDP·NAS 관리 포트를 인터넷에 상시 공개
• [ ] 개발 서버를 이유 없이 0.0.0.0으로 실행
• [ ] Cloudflare Tunnel을 무인증으로 공개
• [ ] AI 에이전트에 sudo와 자동 승인을 동시에 제공
• [ ] .env와 운영 키를 AI 대화에 첨부
• [ ] 출처 불명 MCP·확장·curl | bash 실행
• [ ] 운영 DB를 AI 에이전트에 직접 연결
• [ ] 이메일·GitHub·클라우드 계정을 비밀번호만으로 보호
• [ ] NAS 한곳만 믿고 백업 완료라고 생각
• [ ] 유출된 키를 Git에서만 삭제하고 계속 사용

최종 원칙: 외부에서 직접 들어오는 길을 없애고, 계정에는 MFA를 걸고, AI와 외부 코드는 최소 권한으로 격리하고, 키가 유출되면 즉시 폐기하며, 마지막에는 오프라인 백업이 살아 있어야 한다.

17. 마무리

앞에서 다룬 바이브 코딩·로컬 개발 보안의 핵심만 짧게 정리한다.

• 외부 포트 차단이 1순위다. SSH·RDP·NAS·DB·개발 서버를 인터넷에 열어두면 자동화 공격 봇이 24시간 시도한다. 포트포워딩·UPnP·공유기 원격 관리를 끄고, 개발 서버는 127.0.0.1에 바인딩한다.
• MFA는 전 계정 필수다. Google·Microsoft·이메일·SNS부터 패스키·보안키를 설정하고, GitHub·Cloudflare·Vercel·Supabase·Tailscale·NAS까지 빠짐없이 적용한다. 복구 코드는 별도 보관한다.
• Tailscale·Cloudflare Tunnel은 포트 개방의 대안이지만, Tailscale Grants·Cloudflare Access·MFA 없이는 반쯤 열린 문과 같다.
• AI 에이전트·MCP·확장은 터미널·파일·브라우저·클라우드 API에 직접 손댄다. YOLO·자동 승인·sudo 동시 허용·홈 폴더 전체 접근·운영 DB 연결을 금지한다.
• 키와 환경 분리로 운영 사고를 막는다. .env는 금고가 아니며, 운영 키·DB·결제·DNS 권한을 개발 환경에 두지 않는다. 최소 권한·만료·용도별 토큰을 쓴다.
• GitHub·npm 공급망은 clone보다 설치·빌드·실행·MCP 승인 순간이 위험하다. Restricted Mode, 설치 스크립트 검토, Dependabot·Push Protection으로 보완한다.
• 백업은 오프라인·불변이어야 한다. NAS 한곳·항상 마운트된 공유 폴더만으로는 랜섬웨어·관리자 탈취 시 함께 잃을 수 있다. 복원 테스트까지 해야 「백업 완료」다.

「외부 포트를 없애고, 모든 계정에 MFA를 걸고, AI와 외부 코드는 최소 권한으로 격리하고, 키가 유출되면 즉시 폐기하며, 마지막에는 오프라인 백업이 살아 있어야 한다.」 — 바이브 코딩은 속도를 위해 보안 경계를 허물기 쉽지만, 위 순서대로 한 번만 정리해 두면 이후 개발 속도를 크게 희생하지 않고도 치명적 사고를 피할 수 있다. 공식 권고(CISA·OWASP·각 벤더 문서)는 환경이 바뀔 때마다 다시 확인하는 것이 좋다.

자주 묻는 질문

• 바이브 코딩할 때 제일 먼저 막아야 할 것은 뭔가요?

  인터넷에 열린 SSH·RDP·NAS·DB·개발 서버 포트입니다. 공유기 포트포워딩·UPnP·원격 관리를 끄고, 혼자 개발할 때는 127.0.0.1에 바인딩합니다. 외부 접속이 필요하면 Tailscale이나 Cloudflare Tunnel+Access처럼 승인·인증이 있는 경로로 바꿉니다.

• 0.0.0.0으로 개발 서버를 켜면 바로 해킹되나요?

  곧바로 전 세계 공개가 되는 것은 아닙니다. 하지만 모든 네트워크 인터페이스에서 접속을 받기 때문에, 같은 와이파이·사내 LAN·포트포워딩·UPnP·Docker 포트 게시가 겹치면 노출될 수 있습니다. 혼자 쓰면 기본을 127.0.0.1로 두는 편이 안전합니다.

• Cloudflare Tunnel만 만들면 비공개인가요?

  아닙니다. Tunnel은 원본 인바운드 포트를 줄이는 도구일 뿐, Access 정책을 안 붙이면 공개 호스트명이 인터넷에 열릴 수 있습니다. 허용 이메일·조직 제한과 MFA를 걸고, 시크릿 창에서 차단되는지까지 확인해야 합니다. URL을 어렵게 만드는 것은 인증이 아닙니다.

• AI 코딩 도구의 자동 승인·YOLO를 켜도 되나요?

  상시 사용은 비권장입니다. 에이전트는 파일 삭제·패키지 설치·배포·클라우드 API까지 실행할 수 있습니다. 웹 읽기·.env 접근·터미널 자동 승인·운영 계정 로그인이 동시에 있으면 특히 위험합니다. sudo·삭제·배포는 수동 확인하고, 프로젝트 폴더만 열어 주세요.

• Git에 올린 API 키는 커밋만 지우면 되나요?

  부족합니다. fork·clone·CI 로그·캐시에 남을 수 있으므로 먼저 키를 폐기·재발급하고 세션을 끊은 뒤 기록을 정리합니다. GitHub Push Protection·Secret Scanning을 켜 두고, 노출이 의심되면 ‘아무도 못 봤겠지’라고 가정하지 않습니다.

• MFA는 어떤 서비스에 꼭 켜야 하나요?

  개발과 연결된 모든 로그인 계정입니다. 특히 Google·Microsoft·이메일이 최우선입니다. 이메일이 털리면 비밀번호 재설정으로 다른 계정이 연쇄 탈취됩니다. 패스키·보안키를 우선하고, SMS보다 인증 앱·패스키를 권장합니다. SNS·GitHub·클라우드·Tailscale·NAS도 포함합니다.

• NAS에 백업해 두면 충분한가요?

  NAS 한곳만으로는 부족할 수 있습니다. 공유 폴더가 항상 마운트돼 있거나 관리자 계정이 탈취되면 원본과 백업이 같이 암호화·삭제될 수 있습니다. 평소 연결되지 않은 오프라인·불변 백업을 두고, 실제 복원 테스트까지 해야 합니다.

• GitHub 스타가 많은 프로젝트는 안전한가요?

  스타·포크는 참고일 뿐 보안 인증이 아닙니다. 계정 탈취·악성 업데이트·유사 이름 패키지·공급망 공격이 가능합니다. 위험은 clone보다 설치·빌드·실행·MCP 승인 순간에 큽니다. package.json 설치 스크립트·Dockerfile·hooks를 확인하고 Workspace Trust Restricted Mode를 씁니다.