비개발자가 안심하고 바이브 코딩하는 회사—AX하는 회사가 알아야 할 3단계 안전망 [크몽 AI-Native 전환기]

크몽은 전사 구성원이 AI를 기반으로 일하는 방식을 혁신하는 AI-Native 조직으로 전환하고 있습니다. 단순히 AI 도구를 유료 결제하는 것을 넘어 업무 프로세스 자체에 AI를 완전히 결합하여 생산성의 한계를 깨부수고 있죠. 이번 시리즈를 통해 크몽이 직면했던 현실적인 장벽들과 이를 해결하기 위해 구축한 기술적 안전망, 그리고 구성원들의 리얼한 성장기를 하나씩 공유합니다. 그 첫 번째 이야기입니다.

📍 핵심 요약

• 크몽은 비개발 직군에게 AI 도구 사용을 허가하기 전에 보안 교육과 가이드라인, 전용 샌드박스를 먼저 설계했습니다. 빠른 도입보다 안전한 도입이 먼저였습니다.
• 안전망은 3단계로 이루어집니다. 테스트용 더미 데이터 원칙 · 사내 패키지 관리 서버(구축 중) + GitHub 전사 관리 · API Key 중앙 관리와 실행환경 격리 — 각각 정보 유출, 공급망 공격, 공격 표면 확장이라는 실재 위협에 대응합니다.

크몽이 AI-Native 조직 전환을 선언한 뒤로, 마케터인 저도 Claude Code나 Cursor, 구글 안티그래비티 같은 AI 도구로 직접 업무를 자동화하기 시작했습니다. "이번 마케팅 캠페인 대상자 데이터를 요약해 슬랙으로 보고하는 봇을 만들어줘"라고 입력하면 1분 만에 파이썬 코드가 나옵니다. 제 손으로 업무를 자동화하는 '슈퍼 마케터'가 된 기분이었습니다.

보안 때문에 ‘회사에서 AI를 쓸 수 없다’고 말하는 회사가 많은데도 크몽이 자유롭게 AI를 쓸 수 있었던 이유가 있습니다. 바로 ‘달릴 수 있는 안전망’을 촘촘하게 짜주었기 때문입니다. 보안 교육 세션, 바이브 코딩 전용 샌드박스 구조까지 설계 했죠.

-

"실제 고객 정보가 담긴 파일은 프롬프트에 올리지 않습니다." 

"외부 API Key는 정해진 절차로 발급받고, 로컬 PC에 저장하지 않습니다." 

"AI가 추천한 라이브러리라도 검증 전에는 설치를 보류합니다."

-

솔직히 처음엔 'AI 시대에 속도가 생명인데 개발자는 왜 이렇게 깐깐할까' 싶었습니다. 하지만 CTO Aaron의 보안 교육 세션을 듣고 생각이 바뀌었습니다. 이 가이드라인은 도입 후에 사고를 겪고 만든 사후 대책이 아니라, 비개발자에게 도구를 열어주기 전에 미리 설계해 둔 안전망이었습니다. 덕분에 저는 보안을 깊이 몰라도 안심하고 자동화를 만들 수 있습니다. AI를 자유롭게 쓰면서도 위험을 막아주는 시스템 3가지를 소개합니다. AX 도입을 검토하는 회사라면 체크리스트로 그대로 쓰실 수 있게 정리해 드릴게요.

1단계: "이 파일, 왜 프롬프트에 넣으면 안 돼요?" : 코딩 단계에서의 데이터 유출 예방 메커니즘  

첫 번째 안전망은 "데이터는 실행 단계가 아니라 코딩 단계에서 이미 외부로 나간다"는 것을 이해해야 합니다. 비개발 실무자가 가장 흔히 하는 오해는 "프로그램을 실행할 때만 데이터가 전송된다"는 생각입니다. 그러다 보니 'AI에 데이터 좀 넣는 것쯤은 괜찮겠지' 하고 넘어가기 쉽습니다. 교육 세션에서 Aaron이 짚어준 동작 원리는 달랐습니다.

Aaron (크몽 CTO)

Claude Code나 Cursor 같은 에이전트 기반 AI 도구들은 코드의 전체 맥락을 이해하기 위해 사용자가 직접 프롬프트에 첨부하지 않은 주변 로컬 파일들까지 자동으로 탐색하고 스캔합니다. 이 과정에서 수집된 로컬 파일의 텍스트 데이터는 코드를 작성하는 과정에서 프롬프트 요청의 일부로 외부 AI 서버에 전송됩니다.

작업 폴더에 실제 회원 이메일이 적힌 엑셀이 있었다면, 프로그램을 개발하는 도중에도 개인정보가 외부 서버로 넘어갑니다. 정보 유출이 일어나는거죠. 

2. "이거 좋다던데 다운받아서 그냥 쓰면 안 돼요?" : 신뢰를 악용하는 오픈소스 공격망 공격 방지 

두 번째 안전망은 오픈소스 생태계의 신뢰 구조를 노리는 공급망 공격(Supply Chain Attack)에 대응합니다. 링크드인과 스레드에는 "이 클로드 스킬 좋다"는 추천이 매일 올라옵니다. 복사해서 설치하면 바로 작동하니 문제없어 보이지만, 현실은 달랐습니다. 해커가 파놓은 함정일 수 있기 때문입니다.

Aaron (크몽 CTO)

제품 개발환경에서도 다양한 오픈소스를 사용합니다. 오픈소스 재사용은 오픈소스 제작자와 공급망, 그리고 사용자 사이의 '신뢰'를 기반으로 합니다. 하지만 늘 그렇듯 '신뢰'를 악용하는 나쁜 사람들이 있죠. 오픈소스에 악성코드를 주입하려는 시도가 매우 많습니다. 공격자가 유명한 패키지에 악성코드 주입을 성공하고 사용자가 이를 무심코 설치하면, 사용자 PC뿐만 아니라 사내 인프라 전체가 침해될 수 있습니다. 이를 공급망 공격(Supply Chain Attack)이라고 부릅니다.

악성 라이브러리가 PC 한 대에 깔리면 백도어를 통한 PC 제어권 탈취, 회사 VPN·인트라넷을 타고 번지는 오염 확산, 침투 경로를 찾기 어려운 추적의 불가능성까지 이어집니다.

3단계 : "Slack API키 써도 되지 않나요? 유출 안되게 조심할게요." : 공격 표면의 확장 방지 

세 번째 안전망은 API Key가 만드는 공격 표면(Attack Surface)의 확장을 막습니다. 일반적으로 업무 자동화 프로그램에 외부 서비스(메시지 발송, 이미지 생성 등)를 연동하려면 API Key가 필요합니다. API Key는 단순한 접속 토큰이 아니라 ID와 Password가 결합된 인증서입니다. 이걸 각자 발급받아 코드 파일에 평문(Plain Text)으로 적어두면, 해커에게 마스터키를 복사해 주는 것이나 다름없습니다.

Aaron (크몽 CTO)

API Key는 추가적인 보안 계층이 없어서 유출 즉시 즉각적인 권한 탈취로 이어집니다. 모든 직원이 각자 PC에 API Key를 평문 파일로 저장하면 기업 전체의 공격 표면(Attack Surface)이 급격히 확장됩니다. 해커가 가장 취약한 단말기 한 대만 뚫어도 기업의 유료 API를 남용할 수 있고, 회사 데이터 탈취가 가능해집니다. 기존 개발자들은 개발할 때 API Key 발급을 최소화하고 중앙 Key 저장소에서 실행 시점에 주입하기 때문에 공격 표면이 최소화됩니다. 반면 모두가 개발자가 된 지금은 업무 자동화를 위한 API Key를 로컬 PC에 저장하려는 요구가 많아지면서, 침해 가능한 공격 표면이 증대하고 있습니다.

실제로 GitHub 같은 공개 저장소에 실수로 API Key를 올렸다가 불과 몇 분 만에 해커가 이를 탈취해, 수천만 원 상당의 유료 API를 무단 사용하는 과금 사고가 업계에서 심심치 않게 일어납니다. 

금지 목록이 선명한 회사가 오히려 빠르게 움직입니다.

비개발자 입장에서는 처음엔 조금 답답했지만 한 달이 지나며 정반대로 바뀌었습니다. 무엇이 안 되는지가 선명하니까, 그 안에서는 누구도 눈치 보지 않고 마음껏 만들 수 있었습니다. 매번 "이거 해도 되나요?"를 묻는 회사보다, 금지 목록이 명확한 회사의 실무자가 결국 더 빠릅니다.

이제 새 자동화 툴이나 AI 도구를 쓸 때 무작정 프롬프트부터 치지 않습니다. AI-Native 팀과 함께 정의한 3가지 기준을 먼저 떠올립니다.

✅ 고객 데이터를 쓰나요? → 실제 고객 개인정보나 민감한 회사 데이터를 다루나요? → 그렇다면 코딩 단계부터 더미 데이터를 사용합니다.

✅ 외부 API 호출? → 외부 서비스와 원격으로 통신하나요? → 그렇다면 개발팀과 보안팀의 가이드를 받아서, 위협 요소 여부를 확인하고 원격 요청을 최소화할 대안을 찾습니다.

✅ API Key? → 외부 서비스 연동을 위한 API Key가 필요한가요? → 그렇다면 코딩 단계에서는 테스트용 API Key를 쓰고, 실행할 때는 별도의 Key 관리 도구를 씁니다.

이 기준은 AI 전환이 필요한 다른 회사에도 적용 가능합니다.

많은 회사가 "전 직원이 AI를 씁니다"라며 생산성을 이야기합니다. 크몽이 AI-Native 전환은 다른 질문에서 시작했습니다. 

 "구성원이 안심하고 쓰려면, 무엇부터 설계돼 있어야 하는가?"

AI가 주는 폭발적인 생산성 뒤에는 개인정보 유출, 오픈소스 해킹 위험, API Key 남용 같은 현실적인 리스크가 따라옵니다. 이 리스크를 가장 먼저 인식하고, 구성원이 침해의 대상이 되거나 기업 자산이 위협 받지 않도록 안전망(정책과 체계)을 선제적으로 구축하는 것. 크몽이 정의하는 AI-Native 조직의 출발점입니다.

이 글에서 소개해드린 3가지의 안전망은 크몽 내부용으로 만들었지만, 업종과 무관하게 적용할 수 있습니다. 오늘 팀 회의에서 "우리 회사에서 바이브 코딩을 시작한 사람이 몇 명인지, 그들에게 어떤 가이드가 주어져 있는지"부터 점검해 보세요. 가이드가 비어 있다면, 도구 도입보다 안전망을 설계하는 것이 먼저입니다.

체계적인 기준과 안전망 위에서 혁신하는 것. 이것이 크몽이 만들어가는 AI-Native의 모습입니다. 계속 이어서 직군별 전환기와 세세한 팁을 소개해 드리겠습니다.

직원들과 함께 바이브코딩으로 다양한 시도를 하고 계시거나 이 글을 읽고도 AI-Native 전환이 고민이시라면 정식으로 AX 도입을 검토해 보세요. 전문가 플랫폼으로써 오랫동안 쌓아온 비즈니스 데이터를 기반으로 비즈니스부터 이해하는 크몽 AX팀이 무료 진단부터 도와드리겠습니다. 신청은 아래 링크에서 3분이면 가능합니다.

👉🏻 크몽 AX 무료 진단 신청하기