고전적인 해커의 방식을 적용해 조금 더 안전하게 바이브 코딩하기

^{source http://addxorrol.blogspot.com/2026/03/slightly-safer-vibecoding-by-adopting.html}

• Python 공급망 공격, 코딩 에이전트 프롬프트 인젝션, 개발 머신 자체가 뚫릴 수 있다는 걱정이 많이 나오는데, 나는 이 논의에서 전제가 좀 다르다는 걸 뒤늦게 깨달음

• 내가 쓰는 방식은 단순함

  • 실제 개발은 임대한 서버나 그 위 VM에서 하고, GitHub 키 포워딩을 켠 SSH로 접속한 뒤 screen이나 tmux 세션에 붙어서 계속 작업

• 예전에는 vim + 확장 위주였지만, 지금은 claude code 같은 코딩 에이전트도 같은 환경 안에서 돌리는 쪽

• 중요한 포인트는 개발 VM이나 서버 안에 secret key를 거의 두지 않는다는 점, 그래서 에이전트를 오래 돌려도 최악의 경우 피해 범위가 개발 VM 수준으로 묶임

• 물론 GitHub 키 포워딩이 악용되면 상위 메인 저장소까지 위험해질 수 있어서, 여기서는 저장소 분리가 필요

  • 메인 저장소와 별도로 개발용 저장소를 fork해 두고, 실제 작업은 개발 저장소에서만 진행

  • 작업이 끝나면 cross-repository pull request로 메인 저장소에 올리고, 사람 손으로 꼼꼼히 리뷰하는 흐름

• 이 리뷰 부담은 추가 비용이라기보다 원래 insider risk 대응 때문에도 필요한 절차라서, 전체 리스크 프로필이 크게 달라지진 않음

• 이렇게 운영하면 공급망 공격 때 가장 크게 잃는 비밀키는 Claude 자격 증명 정도로 좁혀지고, 프롬프트 인젝션 공포에 과하게 매달리기보다 코드 작성에 집중하기 쉬워짐

• 흥미로운 점은 SSH로 원격 머신에 붙고 screen 세션에 붙는 개발 방식이 원래 해커 문화권에서 퍼졌다는 것

  • 물리적으로 내가 가진 머신에 데이터를 두는 게 늘 좋은 선택은 아니었고, 법 집행이 쉽게 못 건드리는 먼 나라 서버를 쓰는 쪽이 더 안전한 시절이 있었음

  • 나는 원래 장시간 돌리는 연산이 자주 필요했고 이동도 많아서 이 방식을 택했는데, agent-first 개발이 늘면서 다시 힘을 받는 분위기