메타 설명

바이브코딩으로 Google Sheets, Supabase, Firebase를 연결하고 전자결재나 개인정보 관리 시스템을 만드는 사례가 늘고 있습니다. 작은 업무도구가 개인정보 DB로 발전할 때 발생할 수 있는 보안 위험과 소규모 조직이 확인해야 할 대응 방법을 정리했습니다.

이전 글에서 다뤘던 AI 개인정보 보호와도 연결됩니다

이번 글은 제가 이전에 작성했던 AI와 보안 관련 글들의 연장선이기도 합니다.

「생성형 AI 개인정보 보호 가이드」에서는 ChatGPT·Gemini 같은 AI에 개인정보를 입력할 때 확인해야 할 부분과 Google Sheets, Supabase, Firebase 등을 AI와 연결할 때의 데이터 접근 범위를 다뤘습니다. 특히 데이터베이스를 연결할 때 데이터 목록화, 등급 분류, 최소 접근, 테스트 데이터 분리, 로그와 보존·파기 기준 등을 확인할 필요가 있다는 내용을 정리했습니다.

「구글 SAIF 쉽게 이해하기」에서는 AI 시대의 보안을 기존의 비밀번호나 백신만의 문제가 아니라 AI 시스템, 데이터, 외부 연결, 권한까지 포함하는 문제로 살펴봤습니다.

그리고 「바이브 코딩 보안 가이드」에서는 회사와 비영리조직에서 직원이 AI로 직접 프로그램을 만들 때 특히 중요한 최소권한 원칙을 정리했습니다.

이번 글은 그다음 단계라고 볼 수 있습니다.

단순히 AI에 개인정보를 넣을 것인가의 문제가 아니라,

AI로 직접 만든 프로그램에 조직의 개인정보를 계속 저장해도 되는가?

라는 문제입니다.

Google 스프레드시트·Supabase·Firebase로 업무시스템을 만들기 전에 확인해야 할 것

최근 바이브코딩을 이용해 업무용 프로그램을 직접 만드는 사람이 크게 늘고 있습니다.

ChatGPT, Claude, Codex 같은 생성형 AI를 이용하면 개발 경험이 많지 않아도 신청자 관리, 직원관리, 실적관리, 데이터베이스, 전자결재 같은 시스템까지 비교적 짧은 시간 안에 만들 수 있습니다.

저 역시 바이브코딩을 적극적으로 활용하고 있고, 작은 조직이 자신의 업무에 맞는 프로그램을 직접 만들 수 있다는 점은 상당히 긍정적으로 보고 있습니다.

그런데 최근 보안 관련 자료를 계속 살펴보면서 한 가지는 조금 다르게 생각하게 됐습니다.

AI는 프로그램을 만드는 비용만 낮추고 있는 것이 아닙니다. 공격자가 시스템을 조사하고 공격하는 비용도 낮추고 있습니다.

그리고 이 변화는 오히려 보안 전문인력이 부족한 작은 기업, 복지기관, 비영리기관, 교육기관 등에 더 중요할 수 있습니다.

특히 Google 스프레드시트를 데이터베이스처럼 사용하거나, Supabase·Firebase 같은 DB를 연결하거나, 바이브코딩으로 전자결재까지 직접 만들어 실제 개인정보를 저장하고 있다면 이제는 “잘 작동하는가?”뿐 아니라 “이 데이터를 넣어도 안전한가?”를 함께 확인해야 할 시점이라고 생각합니다.

최근 개인정보 유출과 해킹 사고가 크게 늘고 있습니다

먼저 최근 상황부터 살펴볼 필요가 있습니다.

개인정보보호위원회에 따르면 2025년 개인정보 유출 신고는 447건으로 전년 307건보다 45.6% 증가했습니다. 개인정보위는 특히 랜섬웨어 등 해킹에 의한 유출 증가를 지적하면서 보안 업데이트, 백업, 접근통제, 암호화 등의 안전조치를 강조했습니다.

잘 알려진 대규모 사고도 잇따랐습니다.

SK텔레콤에서는 약 2,324만 명의 휴대전화번호, IMSI, USIM 인증키 등 25종의 정보가 유출됐습니다. 개인정보위 조사에서는 방화벽 설정 미흡, 서버 계정정보 관리 부실, 암호화 미실시 등의 문제도 확인됐고, 약 1,347억 원의 과징금이 부과됐습니다.

롯데카드에서는 온라인 간편결제 시스템 해킹으로 약 297만 명의 개인신용정보가 유출됐고, 이 가운데 약 45만 명의 주민등록번호도 포함된 것으로 확인됐습니다. 개인정보위는 결제 로그에 주민등록번호 등 개인정보가 평문으로 기록된 점 등을 확인해 과징금 96억 2천만 원을 부과했습니다.

제가 이번 글에서 특히 눈여겨본 사례는 패스트캠퍼스를 운영하는 데이원컴퍼니의 개인정보 유출 사고입니다.

회사 공지에 따르면 사용 중이던 GitHub 서비스의 마스터 계정 키값이 탈취됐고, 이를 통해 2026년 5월 9일 최초 서비스 침입이 이루어진 것으로 파악됐습니다. 이후 이름, 이메일, 전화번호, 암호화된 비밀번호뿐 아니라 일부 이용자의 주소, 직무·직급, 결제 및 환불 관련 정보 등의 노출 가능성도 확인됐습니다.

이 사례가 바이브코딩 시대에 특히 의미가 있다고 생각하는 이유가 있습니다.

요즘 개발에서는 GitHub, Google Cloud, Supabase, Firebase, Netlify, Vercel 등 여러 서비스를 연결합니다. 서비스를 연결하기 위한 인증정보와 권한 관리가 잘못되면 단순히 코드 하나가 노출되는 문제가 아니라 연결된 데이터와 시스템 전체로 공격 범위가 확대될 수 있기 때문입니다.

하지만 여기까지만 보면 여전히 이렇게 생각할 수도 있습니다.

“저건 큰 회사 이야기 아닌가?”

그런데 최근 자료를 보면 꼭 그렇지만도 않습니다.

“우리 같은 작은 조직을 누가 해킹하겠어?”가 위험해지는 이유

2026년 1월 한국인터넷진흥원(KISA)은 국내 웹사이트를 대상으로 정보 탈취 공격이 이어지는 가운데 비영리 협회, 대학, 중소병원 등에서도 개인정보 유출 정황이 다수 발견됐다고 별도로 보안 강화를 요청했습니다.

4월에는 더욱 직접적으로 ‘국내 중소기업 대상 신규 랜섬웨어 범죄 확산’에 대한 보안 권고를 발표했습니다.

공문, 이력서, 견적서 등으로 위장한 악성메일을 보내거나 IT 서비스 업체를 사칭해 권한을 탈취하고 서버에 침입한 뒤 랜섬웨어를 설치하는 방식 등이 실제 사례로 제시됐습니다.

즉, 해킹을 대기업이나 금융회사만의 문제라고 생각하기 점점 어려워지고 있습니다.

그리고 저는 여기에 AI가 상당히 중요한 변수가 될 것으로 생각합니다.

AI는 개발 비용과 함께 해킹 비용도 낮추고 있습니다

생성형 AI가 등장하면서 프로그램 개발 속도가 크게 빨라졌습니다.

예전에는 검색하고, 문서를 읽고, 코드를 작성하고, 오류를 수정하는 데 많은 시간이 필요했지만 이제는 AI가 이 작업의 상당 부분을 보조할 수 있습니다.

그런데 공격자도 같은 기술을 이용할 수 있습니다.

IBM이 2026년 발표한 데이터 유출 비용 관련 분석에서는 AI가 정찰, 취약점 탐색, 피싱 콘텐츠 작성, 악성코드 조정, 익스플로잇 테스트 등을 자동화하면서 정교한 공격을 실행하는 비용과 복잡성을 실질적으로 낮추고 있다고 설명합니다. IBM 조사에서는 악의적인 침해사고 네 건 중 한 건에서 AI가 활용된 것으로 나타났습니다.

이 변화가 중요한 이유는 단순합니다.

과거에는 공격자가 작은 기관 하나를 공격하기 위해 직접 홈페이지를 살펴보고, 서버를 분석하고, 취약점을 찾는 데 상당한 시간이 들어갔습니다.

얻을 수 있는 이익이 크지 않다면 굳이 공격할 이유가 없었을 수도 있습니다.

하지만 이런 과정의 일부를 자동화할 수 있다면 상황이 달라집니다.

수십 개가 아니라 수천 개의 인터넷 서비스를 조사하면서 설정이 잘못된 시스템이나 오래된 프로그램, 잘못 열린 데이터베이스, 취약한 로그인 페이지 등을 빠르게 찾아낼 수 있습니다.

그렇다면 공격자 입장에서는 반드시 큰 기업 한 곳을 오랫동안 분석할 필요가 없습니다.

취약한 작은 시스템을 여러 개 찾아내는 방식도 경제성을 가질 수 있습니다.

따라서 앞으로는

“우리 조직이 얼마나 큰가?”보다 “인터넷에 연결된 취약한 시스템이 있는가?”가 더 중요해질 수 있습니다.

사용자가 보내주신 박세준 티오리 대표의 AI 해킹 관련 영상 역시 이런 변화에 대해 생각해볼 만한 사례들을 소개하고 있습니다. 영상에서 등장하는 실험 사례를 곧바로 “AI가 알아서 모든 시스템을 해킹한다”는 의미로 확대해석할 필요는 없지만, AI가 취약점 탐색과 반복적인 공격 시도를 빠르게 수행할 수 있다는 방향성은 충분히 주목할 필요가 있다고 생각합니다.

그런데 동시에 작은 조직도 직접 ‘개발자’가 되고 있습니다

여기에서 바이브코딩 문제가 연결됩니다.

예전에는 작은 기업이나 비영리기관, 복지기관에서 자체 업무시스템을 만드는 것이 쉽지 않았습니다.

개발업체를 선정해야 했고 서버와 데이터베이스를 구축해야 했습니다. 비용도 상당했습니다.

하지만 이제 상황이 달라지고 있습니다.

AI에게

“신청자 관리 프로그램을 만들어줘.”

“구글 스프레드시트에 저장되게 해줘.”

“관리자 화면 만들어줘.”

“결재자가 승인할 수 있게 해줘.”

“Supabase에 연결해서 데이터를 저장해줘.”

라고 요청하면서 상당한 수준의 업무시스템을 직접 만들 수 있습니다.

개발의 진입장벽이 크게 낮아진 것입니다.

저는 이것을 상당히 긍정적인 변화라고 생각합니다.

문제는 다른 곳에 있습니다.

프로그램을 만드는 기술적 장벽은 낮아졌지만 개인정보 보호와 보안의 난이도까지 낮아진 것은 아닙니다.

오히려 과거 개발자가 맡았던 서버, DB, 인증, 권한, 백업, 로그관리까지 일반 직원이 직접 결정해야 하는 상황이 생길 수 있습니다.

특히 흔한 것이 Google 스프레드시트를 데이터베이스처럼 사용하는 방식입니다

작은 조직에서 가장 쉽게 시작할 수 있는 방법 가운데 하나가 Google 스프레드시트를 데이터베이스처럼 이용하는 것입니다.

처음에는 매우 단순합니다.

웹페이지에서 신청서를 작성하면 Google Sheets에 저장합니다.

여기에 Google Apps Script를 조금 사용하거나 AI에게 코드를 만들어 달라고 하면 조회와 수정 기능을 붙일 수 있습니다.

조금 더 발전시키면

신청 → 저장 → 조회 → 수정 → 승인 → 통계 → 알림

까지 하나의 업무시스템처럼 구현할 수 있습니다.

문제는 프로그램이 편리하면 계속 기능을 추가하게 된다는 것입니다.

처음에는 이름과 전화번호 정도였을 수 있습니다.

그런데 주소가 들어갑니다.

직원정보가 들어갑니다.

근무기록을 저장합니다.

결재 기능을 추가합니다.

첨부파일이 들어갑니다.

업무 특성에 따라 상담내용, 장애정보, 건강정보, 급여정보, 계좌정보까지 추가될 수 있습니다.

이쯤 되면 Google Sheet는 더 이상 단순한 문서가 아닙니다.

사실상 조직의 개인정보 데이터베이스가 된 것입니다.

그런데 이용하는 사람의 인식은 여전히

“그냥 구글시트인데?”

에 머무를 수 있습니다.

저는 이 부분이 작은 조직에서 발생할 수 있는 중요한 보안 위험이라고 생각합니다.

Google Sheets 자체가 위험한 것은 아닙니다

여기에서 한 가지는 분명히 할 필요가 있습니다.

Google 스프레드시트 자체가 보안에 취약하다는 이야기가 아닙니다.

Google Workspace의 계정과 공유권한을 적절하게 관리하고 다중인증 등을 사용한다면 충분히 유용하게 사용할 수 있습니다.

문제는

Google Sheets를 데이터베이스처럼 사용하면서 데이터베이스처럼 관리하지 않는 것입니다.

예를 들어 담당 직원에게 필요한 것은 자신이 담당하는 이용자 20명의 정보뿐인데 원본 Sheet에는 1,000명의 이용자 정보가 있고 해당 직원에게 전체 편집권한을 줬다고 생각해 보겠습니다.

업무 화면에서는 담당자 자료만 보이도록 만들었더라도 직원이 원본 Sheet에 접근할 수 있다면 결국 1,000명의 자료를 모두 확인할 수 있습니다.

퇴사자의 Google 계정에 공유권한이 계속 남아 있을 수도 있습니다.

외부 협력기관 직원에게 잠시 공유한 권한을 회수하지 않았을 수도 있습니다.

‘링크가 있는 사용자’에게 접근권한이 열려 있을 수도 있습니다.

여러 직원이 하나의 Google 계정을 공동으로 사용한다면 누가 실제로 데이터를 확인하거나 수정했는지 파악하기도 어려워집니다.

결국 중요한 것은 사용하는 서비스의 이름이 아닙니다.

누가, 어떤 데이터에, 어느 범위까지 접근할 수 있는가가 중요합니다.

바이브코딩으로 만든 전자결재는 더 주의해야 합니다

제가 특히 조심해야 한다고 생각하는 것이 전자결재입니다.

전자결재 역시 바이브코딩으로 생각보다 쉽게 구현할 수 있습니다.

Google Sheets와 Apps Script를 이용하거나 Supabase 같은 데이터베이스를 연결해

문서 작성 → 결재 요청 → 승인·반려 → 결과 저장 → 알림

구조를 만들 수 있습니다.

화면도 상당히 그럴듯하게 만들 수 있습니다.

문제는 전자결재에 저장되는 정보입니다.

전자결재에는 출장, 근태, 연차, 인사정보, 급여, 지출결의서, 견적서, 계약서, 계좌정보 등이 포함될 가능성이 높습니다.

첨부파일까지 지원하면 조직의 중요한 자료가 한곳으로 모입니다.

그리고 전자결재에서 정말 중요한 것은 예쁜 결재화면이나 승인 버튼이 아닙니다.

예를 들어 결재자가 ‘승인’을 누르면 Google Sheet의 특정 셀이

대기 → 승인

으로 바뀌도록 프로그램을 만들었다고 해보겠습니다.

그런데 원본 Sheet에 편집권한이 있는 직원이 직접 셀을 수정해 ‘승인’으로 바꿀 수 있다면 어떻게 될까요?

프로그램 화면에서는 정상적으로 결재된 문서와 직접 수정된 데이터를 구분하지 못할 수도 있습니다.

따라서 전자결재에서는

누가 승인했는가, 언제 승인했는가, 승인 당시의 문서가 무엇이었는가, 이후 내용이 변경됐는가, 변경했다면 누가 변경했는가

를 확인할 수 있어야 합니다.

전자결재는 단순한 CRUD 프로그램이 아니라 권한과 기록의 신뢰성을 보장해야 하는 시스템입니다.

화면에서 관리자 메뉴를 숨겼다고 보안이 되는 것은 아닙니다

바이브코딩에서 특히 자주 혼동할 수 있는 부분입니다.

일반 직원으로 로그인하면 관리자 메뉴가 보이지 않도록 만들었다고 생각해 보겠습니다.

겉으로 보기에는 정상적인 권한관리처럼 보입니다.

하지만 사용자가 특정 API 주소를 직접 호출하거나 DB에 접근했을 때 관리자 데이터까지 가져올 수 있다면 실제 접근통제가 된 것이 아닙니다.

즉,

보이지 않는 것과 접근할 수 없는 것은 다릅니다.

Google Sheets에서도 마찬가지입니다.

웹앱 화면에서는 자신의 담당 이용자만 보여주면서 원본 Sheet 전체의 편집권한을 직원에게 제공했다면 실질적인 데이터 분리가 이루어진 것은 아닙니다.

Supabase·Firebase를 붙였다고 자동으로 안전해지는 것도 아닙니다

그렇다면 Google Sheets가 아니라 Supabase나 Firebase 같은 데이터베이스를 사용하면 안전할까요?

역시 자동으로 해결되지는 않습니다.

두 서비스 모두 강력한 보안 기능을 제공합니다.

중요한 것은 그 기능을 제대로 설정했느냐입니다.

예를 들어 직원 1,000명의 정보가 있다고 해보겠습니다.

일반 직원은 자신의 정보만 볼 수 있고, 팀장은 자신의 팀 정보만 보고, 인사담당자만 필요한 범위의 전체 정보에 접근할 수 있도록 해야 합니다.

Supabase에서는 대표적으로 RLS(Row Level Security)를 이용할 수 있고 Firebase에서도 Security Rules 등을 통해 데이터 접근범위를 설정할 수 있습니다.

그런데 바이브코딩을 하다 보면

“로그인이 되니까 보안도 된 거겠지.”

라고 생각하기 쉽습니다.

그렇지 않습니다.

인증(Authentication)과 권한(Authorization)은 다른 문제입니다.

로그인한 사용자 누구나 전체 이용자 데이터에 접근할 수 있다면 로그인 기능이 있다고 해서 개인정보가 안전한 것은 아닙니다.

왜 소규모 조직에서 이 문제가 더 중요할까요?

이 부분이 제가 이번 글에서 가장 이야기하고 싶은 내용입니다.

대기업이나 전문 IT기업에서는 새로운 시스템을 만들면 개발팀뿐 아니라 정보보안, 개인정보보호, 인프라 담당자 등이 검토할 가능성이 있습니다.

하지만 작은 기업, 복지기관, 교육기관, 비영리기관 등에서는 상황이 다를 수 있습니다.

프로그램을 만든 한 직원이 사실상

개발자 + 서버관리자 + 데이터베이스 관리자 + 개인정보 담당자 + 보안담당자

역할을 동시에 하게 될 수 있습니다.

더구나 그 직원의 원래 직무는 개발이나 보안과 전혀 관계가 없을 수도 있습니다.

업무를 편리하게 만들려고 AI를 이용했는데 몇 달 뒤에는 수백 명의 개인정보가 저장된 시스템을 운영하고 있는 상황이 만들어질 수 있는 것입니다.

특히 다음과 같은 과정이 상당히 자연스럽게 발생할 수 있습니다.

처음에는 개인적인 업무도구를 하나 만듭니다.

편리해서 팀원들과 같이 사용합니다.

그다음 Google Sheets를 붙입니다.

이용자 정보를 넣습니다.

통계 기능을 추가합니다.

로그인 기능을 붙입니다.

전자결재를 만듭니다.

파일 업로드를 추가합니다.

그리고 몇 달 뒤에는 이 프로그램이 없으면 업무를 하기 어려워집니다.

결국

프로토타입 → 개인 업무도구 → 팀 업무시스템 → 조직 핵심시스템

으로 발전한 것입니다.

그런데 보안 수준은 처음 프로토타입을 만들었을 때 그대로일 수 있습니다.

이것은 전형적인 Shadow IT 문제와도 연결될 수 있습니다. 조직의 공식적인 IT 관리절차 밖에서 만들어진 시스템이 실제 핵심업무를 담당하게 되는 것입니다.

개인 계정으로 시작했다면 또 다른 문제가 생길 수 있습니다

소규모 조직에서는 프로그램을 처음 만든 직원의 개인 Google 계정이나 GitHub 계정으로 프로젝트를 시작하기 쉽습니다.

Supabase 프로젝트도 개인 계정입니다.

Netlify나 Vercel도 개인 계정입니다.

도메인도 개인 이메일로 가입했을 수 있습니다.

처음에는 별 문제가 없어 보입니다.

하지만 프로그램이 조직의 핵심 시스템이 된 뒤 해당 직원이 퇴사한다면 어떻게 될까요?

Google Sheet의 실제 소유자는 누구인가?

GitHub 저장소는 누구 계정에 있는가?

데이터베이스의 최고 관리자 계정은 누구 것인가?

배포 서버를 중지하거나 수정할 권한은 누가 가지고 있는가?

도메인 갱신은 누가 하는가?

이 질문에 조직이 답하지 못한다면 데이터는 조직의 것인데 시스템 통제권은 한 개인에게 있는 상황이 될 수도 있습니다.

보안은 외부 해커만 막는 문제가 아닙니다.

시스템을 조직이 지속적으로 관리할 수 있는 구조를 만드는 것 역시 보안의 일부입니다.

“구글이니까 안전하다”도 정확한 생각은 아닙니다

Google, Microsoft, Supabase 같은 대형 서비스를 사용한다는 것과 내가 만든 시스템이 안전하다는 것은 같은 의미가 아닙니다.

클라우드 서비스 회사는 자신의 인프라를 보호합니다.

하지만 누가 내 Google Sheet를 볼 수 있는지, Supabase 테이블의 접근정책을 어떻게 설정했는지까지 대신 결정해주지는 않습니다.

Google의 서버가 아무리 안전해도 사용자가 파일을 외부에 공개해 놓으면 데이터가 노출될 수 있습니다.

Supabase의 인프라가 안전하더라도 데이터 접근정책을 지나치게 넓게 설정했다면 누구나 데이터를 볼 수 있는 시스템이 될 수 있습니다.

이를 흔히 클라우드의 공동 책임 모델(Shared Responsibility Model) 관점으로 이해할 수 있습니다.

즉 클라우드 서비스를 이용한다고 보안 책임까지 모두 외부 서비스 업체에 이전되는 것은 아닙니다.

해킹보다 더 어려운 것이 ‘무슨 일이 있었는지 모르는 상황’일 수도 있습니다

소규모 조직에서 제가 더 걱정하는 부분이 있습니다.

사고가 발생한 이후입니다.

어느 날 개인정보가 외부로 유출된 것으로 의심된다고 가정해 보겠습니다.

그렇다면 최소한 이런 질문에 답해야 합니다.

누가 접근했는가?

언제 접근했는가?

어떤 데이터를 조회했는가?

수정하거나 삭제한 정보는 있는가?

몇 명의 정보가 영향을 받았는가?

그런데 애초에 접근로그나 변경이력을 남기지 않았다면 알 방법이 없을 수도 있습니다.

단순한 Google Sheet와 바이브코딩 프로그램으로 시스템을 운영하면서 기능 구현에는 신경을 썼지만 로그 설계는 하지 않았다면 사고 발생 후 피해범위를 확인하는 것 자체가 어려울 수 있습니다.

백업도 마찬가지입니다.

백업이 없거나 운영 시스템과 동일한 계정 안에만 백업이 있다면 랜섬웨어나 계정 탈취가 발생했을 때 함께 영향을 받을 수 있습니다.

결국 보안은

“해킹당하지 않는 것”

만을 의미하지 않습니다.

문제가 발생했을 때 발견하고, 피해범위를 확인하고, 차단하고, 데이터를 복구할 수 있는 것까지 포함합니다.

2026년 개인정보 보호법 변화도 함께 볼 필요가 있습니다

이런 상황에서 2026년 9월 11일부터 개정 개인정보 보호법과 시행령이 시행됐습니다.

이번 제도 변화에서는 반복적이거나 고의·중과실에 의한 중대한 개인정보 유출 등에 대해 전체 매출액의 최대 10% 범위에서 징벌적 과징금을 부과할 수 있도록 했고, CEO와 CPO의 개인정보 보호 책임 및 관리체계를 강화했습니다.

또한 실제 유출이 완전히 확정되기 전이라도 일정 요건에서 개인정보 유출 가능성을 알게 된 경우 통지하는 제도가 신설됐으며, 랜섬웨어 등에 따른 개인정보의 위조·변조·훼손도 통지·신고 대상에 포함됐습니다.

물론 개인정보가 한 번 유출되면 모든 소규모 조직에 매출액 10% 과징금이 부과된다는 뜻은 아닙니다. 적용 요건과 조직 규모 등에 따른 구체적인 의무는 구분해서 볼 필요가 있습니다.

다만 제도 전체가 향하는 방향은 명확합니다.

사고가 난 뒤 대응하는 것보다 개인정보를 처리하는 조직이 사전에 안전한 시스템과 관리체계를 갖추도록 책임을 강화하는 방향입니다.

따라서 자체적으로 개인정보를 저장하는 업무시스템을 만드는 작은 조직에서도 이 문제를 예전보다 더 중요하게 볼 필요가 있습니다.

그렇다면 작은 조직에서는 어디까지 해야 할까요?

바이브코딩을 하지 말자는 것이 아닙니다.

오히려 저는 작은 조직일수록 바이브코딩을 적극적으로 활용할 가치가 있다고 생각합니다.

예산과 개발인력이 부족한 조직이 자신의 업무에 맞는 프로그램을 직접 만들 수 있다는 것은 상당히 큰 장점입니다.

다만 실제 개인정보를 넣기 전에 한 번 멈추고 확인하는 과정은 필요합니다.

다음 체크리스트는 Google Sheets, Apps Script, Supabase, Firebase 등을 이용해 작은 조직에서 업무시스템이나 전자결재를 만들었을 때 최소한 확인해 볼 내용을 정리한 것입니다.

이 가운데 제가 특히 중요하다고 생각하는 것은 공유범위, 사용자별 권한, DB 단계의 접근통제, 변경이력, 로그입니다.

많은 바이브코딩 프로그램에서 로그인 화면은 잘 만들어집니다.

하지만 더 중요한 질문은 로그인 이후입니다.

로그인한 사용자가 어디까지 볼 수 있는가?

자신과 관계없는 이용자 정보까지 조회할 수 있지는 않은가?

화면에는 보이지 않지만 API를 통해 접근할 수 있지는 않은가?

전자결재 결과를 원본 Sheet에서 직접 바꿀 수 있지는 않은가?

누군가 자료를 대량으로 열람해도 그 사실을 확인할 수 있는가?

이 질문에 답할 수 있어야 ‘동작하는 프로그램’에서 ‘실제 업무에 사용할 수 있는 프로그램’으로 넘어갈 수 있습니다.

특히 이런 업무라면 보안 수준을 한 단계 더 높여야 합니다

모든 바이브코딩 프로그램을 같은 수준으로 관리할 필요는 없습니다.

공개된 행사정보를 보여주는 홈페이지와 수백 명의 상담기록을 관리하는 프로그램을 동일하게 볼 필요도 없습니다.

결국 기준은 무슨 기술을 사용했느냐가 아니라 어떤 데이터를 저장하고 어떤 업무를 수행하느냐입니다.

공개 행사안내나 단순 체크리스트라면 상대적으로 자유롭게 바이브코딩을 활용할 수 있습니다.

이름과 연락처를 저장하는 신청 시스템이라면 개인정보의 수집 목적과 접근권한을 확인해야 합니다.

직원관리나 CRM이라면 사용자별 권한, 로그, 백업을 고려해야 합니다.

전자결재, 인사, 급여, 회계 시스템이라면 인증과 권한뿐 아니라 승인 이력과 데이터 무결성을 더 엄격하게 확인해야 합니다.

상담기록, 장애정보, 건강·의료 정보처럼 민감한 데이터를 다루는 시스템이라면 단순한 편의용 바이브코딩 시스템보다 기존의 검증된 시스템을 우선 검토하거나 전문적인 보안 검토를 받는 것이 더 적절할 수 있습니다.

랜섬웨어도 ‘파일을 잠그는 공격’에서 끝나지 않습니다

작은 조직에서 또 하나 생각해야 할 것이 랜섬웨어입니다.

랜섬웨어를 단순히

“컴퓨터 파일을 암호화하고 돈을 요구하는 공격”

으로만 이해하기 쉽습니다.

하지만 공격자가 데이터를 먼저 빼낸 뒤 돈을 지급하지 않으면 개인정보나 내부자료를 공개하겠다고 협박하는 이중 갈취(Double Extortion) 방식도 사용됩니다.

이런 상황에서는

“우리 기관 자료를 해커가 가져가서 어디다 쓰겠어?”

라는 생각도 위험할 수 있습니다.

공격자가 반드시 해당 정보를 판매해야만 돈이 되는 것은 아닙니다.

직원 인사기록, 이용자 상담기록, 고객 명단, 계약서, 급여자료 등이 공개됐을 때 그 조직이 얼마나 곤란해지는가 자체가 협박 수단이 될 수 있기 때문입니다.

KISA가 2026년 국내 중소기업을 대상으로 랜섬웨어 피해 확산을 별도로 경고한 것도 작은 조직에서 이 문제를 가볍게 볼 수 없는 이유입니다.

바이브코딩의 다음 단계는 ‘만드는 능력’보다 ‘운영하는 능력’이라고 생각합니다

앞으로 바이브코딩은 더 활성화될 가능성이 높습니다.

저 역시 이 흐름을 막는 것이 답이라고 생각하지 않습니다.

오히려 작은 조직에는 상당한 기회입니다.

지금까지 예산 때문에 만들지 못했던 시스템을 현장 직원이 직접 만들 수 있습니다.

자신의 업무를 가장 잘 아는 사람이 직접 프로그램을 설계하고 계속 개선할 수도 있습니다.

하지만 이제는 질문도 한 단계 발전해야 합니다.

지금까지는

“AI로 이것을 만들 수 있을까?”

가 중요한 질문이었다면 앞으로는

“이 프로그램에 실제 개인정보를 넣고 몇 년 동안 운영해도 괜찮을까?”

를 함께 물어야 합니다.

Google Sheets를 DB처럼 사용한다면 누가 원본 데이터에 접근할 수 있는지 확인해야 합니다.

Supabase나 Firebase를 사용한다면 로그인 화면뿐 아니라 실제 DB에서도 사용자별 권한이 제한되어 있는지 확인해야 합니다.

전자결재를 만들었다면 승인 버튼이 작동하는지만 볼 것이 아니라 승인기록의 신뢰성과 변경이력을 확인해야 합니다.

그리고 문제가 생겼을 때 누가 무엇을 했는지 확인할 수 있는 로그와 실제로 복구할 수 있는 백업도 있어야 합니다.

바이브코딩의 가장 큰 장점은 보통 사람도 자신의 업무에 필요한 프로그램을 만들 수 있게 됐다는 것입니다.

그런데 반대로 생각하면,

보안 전문가가 아니어도 수백 명, 수천 명의 개인정보를 보관하는 시스템을 만들 수 있게 됐다는 뜻이기도 합니다.

특히 AI로 공격의 비용과 진입장벽까지 낮아지고 있는 상황이라면 작은 조직이라고 해서 안심할 수는 없습니다.

그래서 저는 앞으로 바이브코딩에서 중요한 능력이 단순히 코드를 얼마나 빨리 만들어내느냐만은 아닐 것이라고 생각합니다.

내가 만든 프로그램이 어떤 데이터를 가지고 있는지 알고, 필요한 사람에게 필요한 만큼만 접근권한을 주고, 문제가 발생하면 확인하고 복구할 수 있도록 설계하는 능력.

이제는 그것까지 포함해서 바이브코딩이라고 생각해야 하지 않을까 싶습니다.

자주 묻는 질문

바이브코딩으로 만든 프로그램은 원래 보안에 취약한가요?

그렇다고 단정할 수는 없습니다. 바이브코딩은 개발 방식입니다. 다만 프로그램을 매우 빠르게 구현할 수 있기 때문에 인증, 권한, 로그, 백업, 개인정보 보관정책 같은 보안 요소를 충분히 검토하기 전에 실제 업무에 사용하게 될 가능성이 있다는 점을 주의해야 합니다.

Google 스프레드시트를 데이터베이스로 사용하면 안 되나요?

무조건 안 되는 것은 아닙니다. 간단하고 위험도가 낮은 업무에서는 매우 유용합니다. 다만 개인정보가 축적된다면 공유권한, 사용자별 접근범위, 계정관리, 로그, 보관기간 등을 함께 검토해야 합니다. 데이터의 민감도와 시스템 규모가 커질수록 전문적인 DB 사용을 고려하는 것이 좋습니다.

Supabase나 Firebase를 쓰면 Google Sheets보다 안전한가요?

데이터 접근통제 기능은 훨씬 세밀하게 설계할 수 있습니다. 하지만 서비스만 바꾼다고 자동으로 안전해지는 것은 아닙니다. Supabase의 RLS나 Firebase의 Security Rules 등 권한 정책을 제대로 설정하지 않았다면 여전히 문제가 발생할 수 있습니다.

바이브코딩으로 전자결재를 만들어도 될까요?

기술적으로는 충분히 가능합니다. 다만 실제 조직의 전자결재로 사용한다면 단순한 승인·반려 기능을 넘어 사용자 인증, 결재권한, 변경이력, 감사로그, 문서 무결성, 개인정보와 첨부파일 관리까지 검토해야 합니다.

작은 조직도 실제 해킹 대상이 될까요?

이미 KISA는 2026년 비영리 협회, 대학, 중소병원 등의 개인정보 유출 정황과 국내 중소기업 대상 랜섬웨어 피해 확산을 별도로 경고했습니다. AI와 자동화로 공격자가 많은 시스템을 조사하는 비용이 낮아질수록 조직 규모만으로 안전을 판단하기는 더 어려워질 가능성이 있습니다.