최근 조직 안에서 “바이브 코딩”을 하는 직원들이 늘어나고 있습니다.

바이브 코딩은 개발자가 아니더라도 ChatGPT, Claude, Cursor, GitHub Copilot, Replit, Lovable, Windsurf 같은 AI 도구를 활용해 업무용 프로그램을 빠르게 만드는 방식을 말합니다.

예전에는 개발자나 외주업체가 필요했던 간단한 신청서, 재고관리, 일정관리, 보고서 자동화, 구글 스프레드시트 기반 대시보드 등을 이제는 실무자가 직접 만들 수 있게 되었습니다.

이 변화는 분명히 유용합니다. 특히 일반 회사, 복지기관, 교육기관, 비영리단체처럼 개발 인력이 충분하지 않은 조직에서는 작은 업무 도구를 빠르게 만들 수 있다는 점이 큰 장점입니다.

문제는 속도만 빨라졌을 뿐, 보안 기준은 아직 따라오지 못하고 있다는 점입니다.

실제로 조직 안에서는 다음과 같은 상황이 쉽게 발생할 수 있습니다.

• 간단한 업무 프로그램을 만든다면서 Google Workspace 관리자 권한을 요구함

• Google Drive 전체 접근 권한을 요청함

• Gmail 전체 읽기 권한을 요구함

• 개인정보가 포함된 스프레드시트를 그대로 AI 코딩 도구에 업로드함

• API Key, 토큰, 비밀번호를 코드에 직접 입력함

• 테스트용으로 만든 앱이 실사용 데이터와 연결된 채 배포됨

• 누가 어떤 데이터를 조회하고 수정했는지 로그가 남지 않음

• 만든 사람이 퇴사하면 시스템 구조를 아무도 알 수 없음

이제 조직은 “AI를 써도 되는가?”가 아니라 “AI로 개발할 때 어디까지 허용할 것인가?”를 정해야 합니다.

이 글은 그 기준을 정리한 글입니다. 핵심은 단순합니다.

AI로 빠르게 만들되, 권한은 최소로 한다.
개인정보는 적게 수집하고, 민감정보는 분리한다.
Google Sheets는 편리하지만 만능 데이터베이스가 아니다.
관리자 권한이 필요한 개발은 일반 바이브 코딩이 아니다.
AI가 만든 코드는 사람이 검토한 뒤 배포한다.

또한 이 글은 전체 기준을 설명하는 “원칙편”입니다. 이후 후속 게시글에서는 신청서, 재고관리, 예약관리, CRM, 상담관리 보조, HR, 지출관리, 자동화 봇, 대시보드, 전자결재 등 실제 사례별로 AI 코딩 도구에 넣어 사용할 수 있는 Skills.md 템플릿을 따로 정리해 공유할 예정입니다.

1. 왜 지금 바이브 코딩 개발 기준이 필요한가

바이브 코딩은 업무 혁신의 도구입니다. 하지만 동시에 정보보호와 개인정보보호의 영역이기도 합니다.

특히 업무용 프로그램은 개인 취미 프로젝트와 다릅니다. 신청자 이름, 연락처, 직원 정보, 이용자 정보, 상담 기록, 후원자 정보, 회계자료, 내부 문서가 연결될 수 있습니다.

이때 권한을 잘못 설계하면 작은 자동화 프로그램 하나가 조직 전체의 보안 위험이 될 수 있습니다.

예를 들어 재고관리 앱을 만든다고 가정해 보겠습니다.

이 앱에 필요한 권한은 특정 재고관리 스프레드시트의 읽기·쓰기 권한입니다. 하지만 개발자가 Google Workspace 관리자 권한, Google Drive 전체 접근 권한, Gmail 전체 읽기 권한을 요구한다면 명백히 과도합니다.

Google은 생성형 AI 시대에 AI를 책임감 있게 구축하고 배포하기 위한 보안 표준으로 Secure AI Framework, 즉 SAIF를 제시하고 있습니다. SAIF는 AI/ML 모델의 보안, 개인정보 보호, 위험 관리를 강조하는 프레임워크입니다. NIST의 AI Risk Management Framework 역시 AI 시스템의 신뢰성, 안전성, 위험관리 요소를 반영하기 위한 자발적 프레임워크로 제시되어 있습니다.

결국 바이브 코딩도 “업무 효율화”만의 문제가 아닙니다.

조직의 신뢰, 개인정보 보호, 내부통제, 보안 책임이 함께 걸린 문제입니다.

2. 바이브 코딩 개발의 핵심 원칙은 최소 권한이다

바이브 코딩 가이드라인의 가장 중요한 기준은 최소 권한 원칙입니다.

최소 권한이란 프로그램, 사용자, 외부 서비스, AI 도구가 업무 수행에 꼭 필요한 데이터와 기능에만 접근하도록 제한하는 원칙입니다.

업무 프로그램이 필요로 하는 권한은 넓을수록 좋은 것이 아닙니다. 오히려 권한이 넓을수록 사고가 났을 때 피해 범위도 커집니다.

잘못된 권한 요구 예시

안전한 권한 요구 예시

Google Apps Script는 사용자 데이터에 접근하거나 사용자를 대신해 작업할 때 OAuth scope를 사용합니다. Google은 공개 앱이나 애드온에서 가능한 한 가장 제한적인 scope를 사용하라고 안내하고 있으며, Apps Script가 자동으로 넓은 권한을 잡는 경우에는 명시적으로 제한된 scope로 바꾸는 것이 필요할 수 있습니다.

따라서 조직 내 기준은 명확해야 합니다.

간단한 업무 프로그램 개발에 Google Workspace 관리자 권한은 필요하지 않다.

관리자 권한이 필요한 경우는 조직 전체 계정 관리, 보안 정책, SSO, 감사 로그, 도메인 설정처럼 명백히 관리자 업무에 해당하는 경우뿐입니다.

신청서, 재고관리, 업무일지, 보고서 자동화, 대시보드, 일정 알림, 파일 정리 자동화에는 최고 관리자 권한이 필요하지 않습니다.

3. Google Workspace에서 쉽게 허용하면 안 되는 권한

직원이 AI로 만든 앱이나 외주 개발사가 만든 간단한 프로그램이 다음 권한을 요구한다면 반드시 보류해야 합니다.

특히 Google Drive와 Gmail 권한은 매우 신중하게 봐야 합니다.

많은 업무 자동화는 특정 Sheet, 특정 Form, 특정 Calendar만 접근해도 충분합니다. 그런데 앱이 Drive 전체, Gmail 전체, 조직 전체 사용자 목록을 요구한다면 목적에 비해 과도한 권한일 가능성이 큽니다.

Google Workspace for Nonprofits를 사용하는 비영리기관이라면 더더욱 “기존 구독 안에서 안전하게 해결할 수 있는지”를 먼저 봐야 합니다. Google은 자격을 갖춘 비영리단체에 Google Workspace for Nonprofits를 제공하며, 이 버전에는 조직용 이메일, Calendar, Drive, Docs, Sheets, Forms, Sites 등 협업 도구와 100TB 공유 스토리지, 최대 2,000명 사용자 추가 기능이 포함된다고 안내하고 있습니다.

4. Microsoft 365에서도 같은 기준이 필요하다

Microsoft 365 환경에서도 원칙은 동일합니다.

Microsoft Graph 권한은 크게 Delegated permissions와 Application permissions로 나눌 수 있습니다.

Delegated permissions는 로그인한 사용자를 대신해 접근하는 방식입니다. 앱은 사용자가 원래 접근할 수 있는 범위 안에서 작동합니다.

반면 Application permissions는 사용자가 로그인하지 않아도 앱 자체가 조직 데이터에 접근할 수 있는 방식입니다. 일반적으로 관리자 동의가 필요하고, 접근 범위가 넓어질 수 있으므로 훨씬 신중하게 검토해야 합니다.

Google Workspace든 Microsoft 365든 기준은 같습니다.

사용자가 할 수 있는 범위 안에서, 필요한 데이터만, 필요한 기능만 접근하게 해야 합니다.

5. 직원이 만드는 내부 프로그램의 보안 등급을 나누자

모든 프로그램을 같은 수준으로 통제할 필요는 없습니다. 중요한 것은 데이터의 민감도와 권한 범위에 따라 등급을 나누는 것입니다.

핵심 원칙은 다음과 같습니다.

1~2등급은 실무자 중심으로 빠르게 만들 수 있습니다.
3등급부터는 개인정보 검토가 필요합니다.
4등급은 Google Sheets만으로 처리하지 않는 것이 안전합니다.
5등급은 직원 개인의 바이브 코딩 영역이 아닙니다.

이 등급표는 조직 내부에서 바이브 코딩 요청을 검토할 때 기준표로 사용할 수 있습니다.

예를 들어 “회의실 예약 앱”은 보통 2등급입니다. 하지만 그 예약 사유에 상담 내용, 건강정보, 민감한 방문 사유가 들어가면 3~4등급으로 올라갈 수 있습니다.

즉, 프로그램 이름보다 중요한 것은 어떤 데이터를 다루는가입니다.

6. 회사와 비영리기관에서 많이 만드는 프로그램별 추천 기술스택

바이브 코딩으로 내부 업무 프로그램을 만들 때는 “어떤 도구가 유명한가”보다 비용, 보안, 권한관리, 유지보수 가능성을 함께 봐야 합니다.

특히 비영리기관, 복지기관, 교육기관은 일반기업과 비용 조건이 다를 수 있습니다. Google Workspace for Nonprofits를 사용할 수 있는 조직이라면 Forms, Sheets, Apps Script, Sites, Looker Studio, AppSheet Core 등을 먼저 검토하는 것이 현실적입니다. Google은 AppSheet Core 라이선스가 대부분의 Google Workspace 에디션에 포함되며 Google Workspace for Nonprofits도 포함 대상이라고 안내하고 있습니다.

따라서 비영리조직이라면 무조건 유료 SaaS부터 검토하기보다 다음 순서로 판단하는 것이 좋습니다.

1단계: 기존 Google Workspace 또는 Microsoft 365 안에서 해결 가능한가?
2단계: Google Forms, Sheets, Apps Script, AppSheet Core로 충분한가?
3단계: 담당자별 권한 분리가 필요해 Airtable, AppSheet, Supabase, Firebase가 필요한가?
4단계: 상담·인사·회계·후원자 정보처럼 민감도가 높아 공식 시스템 또는 보안 검토가 필요한가?

기술스택을 5개 층으로 나누어 보기

7. 비용 기준으로 먼저 나누기

도구를 선택할 때 가장 먼저 볼 것은 “무료인가, 유료인가”가 아니라 조직 전체가 쓸 때 비용이 얼마나 커지는가입니다.

Airtable은 편리하지만 비용 측면에서는 신중해야 합니다. Airtable 공식 가격 기준으로 Team 플랜은 연간 결제 시 사용자당 월 20달러, Business 플랜은 연간 결제 시 사용자당 월 45달러입니다. Airtable의 비영리 할인은 자격 조직에 대해 월간 Team 플랜 기준 50% 할인을 제공하며, 할인 후 사용자당 월 12달러 수준이라고 안내되어 있습니다.

따라서 Airtable은 조직 전체 직원에게 모두 계정을 주는 도구라기보다 CRM, 협력기관 관리, 후원자 관리처럼 Airtable의 장점이 분명한 업무에 제한적으로 쓰는 도구로 보는 것이 현실적입니다.

8. 도구별 보안 수준 이해하기

도구 자체가 안전하냐보다 중요한 것은 어떤 데이터에, 어떤 권한으로, 어떻게 연결하느냐입니다.

Supabase는 PostgreSQL의 Row Level Security, 즉 RLS를 활용할 수 있습니다. Supabase는 RLS가 데이터베이스에 직접 접근하는 환경에서도 데이터 보호를 강화하는 방어 계층이며, Supabase Auth와 결합해 브라우저부터 데이터베이스까지 사용자별 접근 제어를 구성할 수 있다고 설명합니다.

Firebase는 Security Rules를 통해 Cloud Firestore, Realtime Database, Cloud Storage의 데이터 접근을 제어할 수 있습니다. 다만 규칙은 직접 설계하고 테스트해야 하며, 규칙이 넓게 열리면 데이터가 노출될 수 있습니다.

9. 프로그램 유형별 추천 기술스택

9-1. 신청서·접수 관리

교육 신청, 행사 접수, 상담 예약, 물품 신청처럼 가장 자주 만드는 유형입니다.

가장 현실적인 기본 조합은 Google Forms + Google Sheets + Apps Script입니다. 신청을 받고, 응답을 시트에 저장하고, 담당자에게 알림을 보내는 수준이라면 추가 비용 없이도 충분히 운영할 수 있습니다.

신청 후 담당자 배정, 처리상태, 승인·반려, 모바일 확인이 필요하다면 AppSheet + Google Sheets가 적합합니다.

Airtable은 신청자 관리, 상태관리, 보기 화면 구성은 편하지만 사용자당 과금이므로 담당자가 많아지는 순간 비용이 커질 수 있습니다. 따라서 신청자 수가 많은 경우보다 관리 담당자가 소수이고, 상태·메모·이력 관리가 중요한 경우에 적합합니다.

9-2. 재고관리·자산관리·물품대여

재고관리, 비품관리, 교구관리, 장비대여, 차량키 관리 등은 바이브 코딩에 비교적 적합합니다. 개인정보가 적고 업무 흐름이 명확하기 때문입니다.

가장 추천하는 구성은 AppSheet + Google Sheets입니다. 재고 입출고, QR코드 스캔, 사진 첨부, 모바일 입력, 담당자 확인까지 빠르게 만들 수 있습니다.

단순 수량표라면 Google Sheets만으로 충분합니다. 하지만 모바일에서 입출고를 기록하거나 담당자별 권한을 나누려면 AppSheet가 더 적합합니다.

9-3. 일정관리·예약관리

회의실 예약, 차량 예약, 상담 예약, 장비 예약, 교육 일정 관리에 해당합니다.

회의실 예약 앱이면 조직 전체 캘린더 권한이 아니라 회의실 예약용 캘린더 하나만 접근하면 됩니다.

상담 예약도 개인 캘린더 전체가 아니라 상담 예약 전용 캘린더 또는 예약 전용 Sheet를 사용하는 것이 안전합니다.

일정관리 앱이 Gmail 전체 읽기 권한을 요구한다면 과도한 권한입니다. 일정 알림을 위해 메일 전체를 읽을 필요는 없습니다.

9-4. 업무 체크리스트·진행상황 관리

사업 일정, 월간 업무, 평가 준비, 실적 제출, 부서별 마감 관리처럼 내부 업무 진행상황을 관리하는 유형입니다.

이 유형은 Google Sheets로 시작하기 좋습니다. 마감일, 담당자, 진행상태, 제출 링크 정도를 관리하는 수준이면 추가 비용이 거의 들지 않습니다.

Slack, Google Chat, 이메일과 연결해 마감 알림을 보내려면 Apps Script 또는 n8n을 사용할 수 있습니다. 다만 Slack Bot Token, Webhook URL, API Key는 코드에 직접 넣지 않고 별도 비밀값 저장소에 보관해야 합니다.

9-5. CRM·후원자·협력기관 관리

후원자, 자원봉사자, 사업체, 협력기관, 기업 담당자 정보를 관리하는 유형입니다. 단순 주소록처럼 보이지만 개인정보와 관계 이력이 포함되므로 3등급 이상으로 보는 것이 안전합니다.

Airtable은 CRM에 적합합니다. 기관명, 담당자, 연락 이력, 다음 연락일, 후속 조치, 태그, 상태값을 관리하기 쉽습니다.

하지만 비용 구조상 전체 직원이 모두 쓰는 시스템으로 확장하면 부담이 커질 수 있습니다. 따라서 Airtable은 소수 담당자가 관리하는 협력기관·사업체·후원자 관리에 적합합니다.

개인정보가 많고 담당자별로 볼 수 있는 데이터가 달라야 한다면 Supabase가 더 적합합니다. Firebase는 모바일 앱, 실시간 동기화, 푸시 알림 중심 서비스에 적합합니다. Firebase는 Spark 무료 플랜과 Blaze 종량제 플랜을 제공하며, 무료 사용량 이후에는 사용량 기반 비용이 발생할 수 있습니다.

9-6. 상담관리·사례관리·직업지원 기록

장애인복지기관, 사회복지기관, 상담기관에서 가장 신중해야 하는 영역입니다.

상담관리, 사례관리, 직업평가, 취업지원 기록, 사후관리 기록은 단순 업무 데이터가 아니라 이용자의 민감한 생활 정보와 권리 정보가 포함될 수 있습니다.

저같은 경우도 관련 시스템인 JJSS를 제작할 때 데이터는 자체 PC에 저장하고 인공지능이 처리할 때는 익명처리를 하게 하였습니다.

이 영역은 바이브 코딩으로 원본 시스템을 새로 만드는 것을 권장하지 않습니다.

특히 Google Sheets에 상담 원문을 저장하거나, AI 코딩 도구에 실제 상담 기록을 업로드하는 방식은 피해야 합니다.

다만 바이브 코딩을 완전히 배제할 필요는 없습니다. 원본 민감정보를 다루는 것이 아니라 기존 시스템에서 나온 비식별 통계나 업무 보조 기능을 만드는 용도로는 충분히 활용할 수 있습니다.

허용 가능한 보조 기능은 다음과 같습니다.

• 월별 실적 집계

• 비식별 통계 대시보드

• 상담 일정 알림

• 제출 마감 알림

• 보고서 서식 자동 생성

• 개인정보 제거 후 문장 다듬기

• 담당자 업무 체크리스트

• 누락 서류 확인표

주의해야 할 기능은 다음과 같습니다.

• 상담 원문 저장

• 장애진단명·건강정보 저장

• 가족관계·소득정보 저장

• 사례회의록 원문 업로드

• AI 도구에 실제 이용자 기록 입력

• 담당자 외 전체 열람 가능 구조

• 접근 로그 없는 조회 시스템

9-7. HR·인사·근태 관리

근태, 연차, 교육 이수, 직원 명단 정도는 내부 자동화로 만들 수 있습니다. 하지만 급여·평가·징계·건강정보가 포함되는 순간 고위험 영역이 됩니다.

HR 앱은 “직원 정보니까 내부에서 보면 괜찮다”라고 생각하기 쉽지만 실제로는 민감도가 높습니다.

특히 급여, 평가, 징계, 병가 사유, 건강정보는 일반 업무용 시트로 관리하지 않는 것이 안전합니다.

9-8. 비용·지출·예산 관리

지출결의, 영수증 확인, 예산 잔액, 사업별 집행현황 관리에 해당합니다.

금액 정보와 증빙자료가 포함되므로 최소 3등급 이상으로 보는 것이 좋습니다.

비용관리 앱은 업무 효율화 효과가 큽니다. 하지만 회계자료는 감사와 직접 연결되므로 “나중에 설명 가능한 구조”가 중요합니다.

단순 예산 잔액표는 Google Sheets로 충분하지만, 증빙파일, 승인 절차, 변경 이력, 담당자별 권한이 필요하면 AppSheet나 Airtable을 검토할 수 있습니다.

회계시스템과 직접 연결해야 한다면 바이브 코딩보다 공식 회계시스템 연동을 우선해야 합니다.

9-9. 업무 자동화·알림 봇

Slack Bot, Google Chat Bot, 이메일 알림, 마감 리마인더, 보고서 자동 생성, 파일 정리 자동화에 해당합니다.

자동화 도구는 편리하지만, 한 번 연결하면 여러 시스템을 동시에 움직일 수 있기 때문에 권한 검토가 매우 중요합니다.

예를 들어 마감 알림 봇은 특정 업무관리 Sheet와 특정 Slack 채널 권한만 있으면 됩니다. Gmail 전체 읽기 권한이나 Google Drive 전체 접근 권한은 필요하지 않습니다.

n8n은 자체 운영이 가능해 통제력을 높일 수 있지만, 서버 보안과 업데이트 책임이 조직에 생깁니다. Make와 Zapier는 빠르게 만들기 좋지만 외부 SaaS를 거치므로 개인정보와 민감정보 자동화에는 신중해야 합니다.

9-10. 내부 대시보드·보고서 자동화

실적 현황, 사업 진행률, 월별 통계, 이용자 수, 예산 집행률, 업무 처리현황을 시각화하는 유형입니다.

대시보드는 원본 데이터를 그대로 보여주는 것이 아니라 집계 데이터 중심으로 만드는 것이 안전합니다.

특히 개인정보가 포함된 원본 Sheet를 직접 연결하면 권한이 넓어질 수 있으므로, 별도의 집계용 Sheet 또는 View를 만들어 연결하는 것이 좋습니다.

9-11. 전자결재·승인 시스템

휴가 신청, 지출결의, 문서 승인, 사업계획 승인, 내부 검토 흐름에 해당합니다.

전자결재는 단순 입력폼보다 운영 책임이 큽니다.

누가 언제 승인했는지, 어떤 문서가 변경되었는지, 반려 사유가 무엇인지 기록이 남아야 합니다.

소규모 승인 흐름은 AppSheet나 Airtable로 만들 수 있지만, 인사·회계·계약·법무 문서까지 포함된다면 기존 그룹웨어나 공식 전자결재 시스템을 우선해야 합니다.

10. 도구별 최종 평가표

11. 바이브 코딩 개발 전 의사결정 트리

개발을 시작하기 전에 다음 질문에 답해 보면 됩니다.

1단계: 개인정보가 있는가?

• 없다 → 1~2등급, 빠른 개발 가능

• 이름·연락처 정도 있다 → 3등급, 접근권한 검토 필요

• 건강·장애·상담·소득·가족·인사 정보가 있다 → 4등급, 보안검토 필요

2단계: 외부 AI 도구에 데이터를 넣어야 하는가?

• 아니다 → 개발 가능

• 샘플 데이터만 넣는다 → 가능

• 실제 개인정보를 넣어야 한다 → 중단

• 상담 원문·HR 자료를 넣어야 한다 → 중단

3단계: 어떤 권한을 요구하는가?

• 특정 파일 접근 → 적정

• 특정 폴더 접근 → 검토

• Drive 전체 접근 → 위험

• Gmail 전체 접근 → 고위험

• 관리자 권한 → 원칙적 금지

4단계: 삭제·수정·발송 기능이 있는가?

• 조회만 한다 → 위험 낮음

• 수정한다 → 로그 필요

• 삭제한다 → 백업·승인 필요

• 외부 발송한다 → 테스트·승인 필요

5단계: 담당자가 바뀌어도 유지 가능한가?

• 문서화되어 있다 → 가능

• 코드와 권한 설명이 없다 → 보완 필요

• 만든 사람만 안다 → 운영 금지

12. AI 코딩 도구 사용 기준

Cursor, Claude Code, GitHub Copilot, Windsurf, Replit, Lovable 같은 도구는 개발 생산성을 크게 높여줍니다.

그러나 조직 기준 없이 사용하면 코드와 데이터가 외부 도구로 흘러갈 수 있습니다.

AI 코딩 도구에 입력해도 되는 정보

• 샘플 데이터

• 가상의 이름과 연락처

• 비식별화된 업무 흐름

• 공개 가능한 UI 요구사항

• 개인정보가 제거된 오류 메시지

• 민감정보가 없는 코드 구조

• 테스트용 스프레드시트 구조

AI 코딩 도구에 입력하면 안 되는 정보

• 실제 이용자 이름, 연락처, 주민등록번호

• 장애유형, 진단명, 건강정보, 상담기록

• 직원 인사정보, 급여, 평가자료

• 후원자 명단, 계좌정보

• Google OAuth Client Secret

• API Key, Slack Token, Webhook URL

• 기관 내부 비밀번호

• 비공개 계약서, 법무자료

• 외부 공개가 금지된 회계·감사자료

AI 코딩 도구를 사용할 때는 다음 원칙을 적용해야 합니다.

1. AI에게 실데이터를 주지 않는다.

2. AI에게 관리자 권한을 주지 않는다.

3. AI가 만든 코드를 바로 배포하지 않는다.

4. AI가 요청한 OAuth 권한을 사람이 검토한다.

5. AI가 만든 삭제·수정·발송 기능은 별도 테스트한다.

6. 운영 데이터와 테스트 데이터를 분리한다.

7. 배포 전 로그, 백업, 권한, 오류처리를 확인한다.

13. 조직 배포용 Skills.md가 필요한 이유

바이브 코딩을 조직에서 안전하게 사용하려면 말로만 “조심하자”라고 해서는 부족합니다.

AI 코딩 도구에 매번 같은 기준을 반복해서 설명해야 하고, 개발자가 아닌 직원도 동일한 보안 기준을 적용할 수 있어야 합니다.

이때 유용한 것이 Skills.md입니다.

Skills.md는 AI 코딩 도구에 제공하는 프로젝트별 개발 지침 파일로 사용할 수 있습니다. 반드시 공식 표준 파일명은 아니지만, Cursor, Claude Code, Codex, GitHub Copilot, Windsurf 같은 도구에 프로젝트 맥락을 설명하는 문서로 활용할 수 있습니다.

조직에서는 다음과 같은 방식으로 사용할 수 있습니다.

즉, 이 글이 “왜 기준이 필요한가”를 설명하는 글이라면, 후속 게시글은 실제로 복사해서 사용할 수 있는 Skills.md 예시를 제공하는 글이 될 예정입니다.

후속 글에서는 다음 사례를 중심으로 다룰 수 있습니다.

14. 조직 공통 Skills.md 초안

아래 내용은 조직 내부에서 AI 코딩 도구에 기본 지침으로 넣을 수 있는 공통 Skills.md 초안입니다.

# 조직 내 바이브 코딩 안전 개발 기준

## 1. 기본 원칙

이 프로젝트는 조직 내부 업무 효율화를 위한 보조 프로그램 개발을 목적으로 한다.

AI 코딩 도구는 개발을 보조할 수 있지만, 최종 책임은 담당자와 조직에 있다.

모든 개발은 다음 원칙을 따른다.

1. 최소 권한 원칙을 지킨다.
2. 개인정보와 민감정보를 AI 도구에 입력하지 않는다.
3. 운영 데이터와 테스트 데이터를 분리한다.
4. 관리자 권한은 요구하지 않는다.
5. 특정 파일, 특정 폴더, 특정 API 범위만 사용한다.
6. 배포 전 권한, 로그, 백업, 오류처리를 점검한다.
7. 삭제, 발송, 대량 수정 기능은 반드시 확인 절차를 둔다.
8. 개발 내용은 담당자가 바뀌어도 이해할 수 있게 문서화한다.

## 2. 데이터 처리 기준

다음 데이터는 AI 도구에 입력하지 않는다.

- 주민등록번호
- 장애진단명
- 건강정보
- 상담 원문
- 사례관리 기록
- 급여·평가·징계 정보
- 계좌번호
- 카드번호
- 후원자 상세정보
- 비밀번호
- API Key
- OAuth Client Secret
- Slack Token
- Webhook URL

개발과 테스트에는 반드시 샘플 데이터를 사용한다.

예시:

- 홍길동 → 사용자001
- 010-1234-5678 → 010-0000-0000
- 실제 상담내용 → 상담요약 샘플
- 실제 사업체명 → 사업체A

## 3. Google Workspace 권한 기준

원칙적으로 다음 권한은 요구하지 않는다.

- Google Workspace 최고 관리자 권한
- 조직 전체 Google Drive 접근
- Gmail 전체 읽기·쓰기
- 전체 사용자 계정 조회·수정
- Domain-wide Delegation
- 모든 스프레드시트 접근

가능한 권한은 다음과 같다.

- 특정 Google Sheet 읽기·쓰기
- 특정 Google Form 응답 조회
- 특정 Google Calendar 접근
- 특정 Google Drive 파일 접근
- 현재 문서 또는 현재 스프레드시트 접근
- 사용자 이메일 확인 범위

OAuth scope는 항상 가장 좁은 범위를 사용한다.

## 4. Microsoft 365 권한 기준

Microsoft Graph 사용 시 기본적으로 Delegated permission을 우선한다.

Application permission은 관리자 검토 없이는 사용하지 않는다.

금지 또는 제한 권한:

- Directory.ReadWrite.All
- User.ReadWrite.All
- Mail.ReadWrite
- Mail.Read.All
- Files.Read.All application permission
- Sites.FullControl.All

## 5. Google Sheets 사용 기준

Google Sheets는 소규모 업무 데이터 저장소로만 사용한다.

허용 가능:

- 신청번호
- 처리상태
- 담당자
- 업무일자
- 재고수량
- 비식별 ID
- 통계 데이터

주의 또는 금지:

- 주민등록번호
- 장애·건강정보
- 상담 원문
- 계좌번호
- 비밀번호
- API Key
- 첨부파일 원본 링크

개인정보가 포함된 Sheet는 다음 기준을 따른다.

- 링크가 있는 모든 사용자 공개 금지
- 편집자 최소화
- 보기 권한과 편집 권한 분리
- 다운로드 가능 여부 검토
- 보호된 범위 사용
- 접근자 목록 정기 점검
- 퇴사자 권한 제거

## 6. UI/UX 원칙

내부 업무 프로그램은 화려함보다 명확성이 중요하다.

1. 한 화면에는 한 가지 주요 작업만 둔다.
2. 저장, 삭제, 발송 버튼은 명확히 구분한다.
3. 삭제 버튼은 확인창을 둔다.
4. 처리상태는 색상과 텍스트를 함께 사용한다.
5. 모바일에서도 입력 가능해야 한다.
6. 접근성을 고려해 글자 크기와 대비를 확보한다.
7. 장애인복지기관 업무에서는 쉬운 문장과 명확한 버튼명을 사용한다.

## 7. 로그 정책

다음 행위는 로그를 남긴다.

- 로그인
- 데이터 조회
- 데이터 생성
- 데이터 수정
- 데이터 삭제
- 파일 다운로드
- 외부 발송
- 관리자 설정 변경

로그에는 다음을 포함한다.

- 일시
- 사용자
- 작업 유형
- 대상 데이터 ID
- 성공 또는 실패 여부
- 오류 메시지

단, 로그에 민감정보 원문을 저장하지 않는다.

## 8. 테스트 기준

배포 전 다음을 확인한다.

- 샘플 데이터로 전체 기능 테스트
- 권한 없는 사용자의 접근 차단 확인
- 삭제 기능 복구 가능 여부 확인
- 대량 수정 기능 테스트
- 외부 메일·Slack 발송 테스트
- 모바일 화면 테스트
- 오류 발생 시 안내문 확인
- 백업 파일 생성 여부 확인

## 9. 배포 기준

다음 조건을 만족해야 운영 배포할 수 있다.

- 목적이 명확하다.
- 수집 데이터가 최소화되어 있다.
- OAuth 권한이 최소화되어 있다.
- 개인정보 포함 여부를 검토했다.
- 관리자 권한을 요구하지 않는다.
- 테스트 데이터와 운영 데이터가 분리되어 있다.
- 담당자 외 1명이 구조를 이해할 수 있다.
- README 또는 운영 문서가 있다.
- 백업과 복구 방법이 있다.

## 10. AI 활용 기준

AI에게 요청할 수 있는 것:

- 코드 초안 작성
- 오류 원인 분석
- UI 개선 제안
- 테스트 케이스 작성
- README 작성
- 샘플 데이터 생성
- 보안 점검 체크리스트 작성

AI에게 요청하면 안 되는 것:

- 실제 개인정보 분석
- 상담 원문 요약
- 실제 계정정보 입력
- 관리자 권한 부여
- 운영 서버 직접 수정
- 실사용 데이터 삭제
- 승인 없는 외부 API 연결

15. 배포 전 최종 체크리스트

데이터 체크

• 실제 개인정보를 AI 도구에 입력하지 않았는가?

• 민감정보를 Google Sheets에 저장하지 않았는가?

• 샘플 데이터와 운영 데이터가 분리되어 있는가?

• 불필요한 컬럼은 삭제했는가?

• 보관기간과 삭제 기준이 있는가?

권한 체크

• 관리자 권한을 요구하지 않는가?

• Google Drive 전체 접근을 요구하지 않는가?

• Gmail 전체 접근을 요구하지 않는가?

• 특정 파일 단위 권한으로 제한했는가?

• 퇴사자와 외부자의 접근을 차단했는가?

보안 체크

• API Key가 코드에 직접 들어가 있지 않은가?

• 토큰과 비밀번호가 스프레드시트에 저장되어 있지 않은가?

• 외부 공개 저장소에 비밀값이 올라가지 않았는가?

• Webhook URL이 노출되지 않았는가?

• 삭제·수정 기능에 확인 절차가 있는가?

운영 체크

• 누가 관리자인지 명확한가?

• 장애 발생 시 복구 방법이 있는가?

• 백업이 가능한가?

• 로그가 남는가?

• 담당자가 바뀌어도 운영 가능한가?

• 사용 설명서가 있는가?

16. 결론: 바이브 코딩은 막을 것이 아니라 기준을 세워야 한다

바이브 코딩은 분명히 조직에 큰 기회를 줍니다.

특히 일반 회사, 복지기관, 교육기관, 비영리단체처럼 개발 인력이 충분하지 않은 조직에서는 실무자가 직접 작은 업무도구를 만들 수 있다는 점이 큰 장점입니다.

그러나 기준 없는 바이브 코딩은 위험합니다.

간단한 프로그램을 만든다면서 관리자 권한을 요구하거나, Google Drive 전체 접근을 요청하거나, 개인정보가 담긴 스프레드시트를 AI 도구에 그대로 넣는 순간 조직은 보안과 개인정보 보호 측면에서 큰 위험을 안게 됩니다.

따라서 조직의 기준은 명확해야 합니다.

AI로 빠르게 만들되, 권한은 최소로 한다.
개인정보는 적게 수집하고, 민감정보는 분리한다.
Google Sheets는 편리하지만 만능 데이터베이스가 아니다.
관리자 권한이 필요한 개발은 일반 바이브 코딩이 아니다.
AI가 만든 코드는 사람이 검토한 뒤 배포한다.

앞으로 조직의 AI 활용 역량은 단순히 “누가 더 빨리 만드는가”가 아니라 누가 더 안전하게 운영 가능한 구조로 만드는가에서 결정될 것입니다.

바이브 코딩의 핵심은 개발 속도가 아닙니다.

조직의 신뢰를 해치지 않으면서, 실무자가 안전하게 문제를 해결할 수 있도록 돕는 것입니다.

그 출발점이 바로 최소 권한 원칙과 조직 공통의 Skills.md입니다.

이 글에서는 전체 기준을 다루었습니다. 이어지는 후속 게시글에서는 신청서, 재고관리, 예약관리, CRM, 상담관리 보조, HR, 지출관리, 자동화 봇, 대시보드, 전자결재 등 실제 사례별로 바로 복사해 사용할 수 있는 Skills.md 템플릿을 하나씩 정리해 공유할 예정입니다.