“코드 90%를 AI가 작성했다”…보안기업 Proton 내부서 벌어진 충돌

스위스의 프라이버시 기업 Proton이 인공지능(AI)을 이용한 개발 속도를 크게 높이는 과정에서 내부 갈등을 겪고 있다는 보도가 나왔다. 미국 기술매체 404 Media는 10월 30일 Proton 경영진이 직원들에게 AI 사용을 강하게 요구했고, 회사 최고기술책임자(CTO)가 회의에서 “10월 코드의 90%가 AI로 작성됐다”고 말했다고 전했다.

이 숫자는 Proton의 공식 감사보고서로 확인된 통계가 아니다. 404 Media가 확보한 회의 녹음과 내부 자료에 근거한 보도다. 더 중요한 쟁점도 ‘90%’ 자체보다 따로 있다. 암호화 이메일과 가상사설망(VPN)을 만드는 회사가 개발 속도를 높이면서도 보안 검토를 충분히 유지할 수 있느냐는 문제다.

Summary

Proton은 Mail·VPN·Drive·Pass 등을 운영하며 1억 개 이상 계정과 10만 개 이상 조직 고객을 내세우는 유럽의 대표적인 프라이버시 기업이다.
404 Media는 Proton 경영진이 AI 코딩을 빠르게 확대하는 과정에서 보안 점검과 조직문화에 대한 직원들의 우려가 커졌다고 보도했다. Proton은 설명이 부족했고 표현이 지나치게 직설적이었다고 답했다.
AI가 코드를 썼다고 그 AI가 자동으로 해킹 방법까지 아는 것은 아니다. 실제 위험은 취약한 코드, 검토 부족, 가짜 소프트웨어 패키지, 기밀정보 노출, AI 도구의 과도한 권한에서 생긴다.

Proton은 어떤 회사인가

한국에서는 Proton이라는 이름이 낯설 수 있다. Proton은 2014년 유럽입자물리연구소(CERN)에서 만난 과학자들이 시작한 스위스 기업이다. 미국 정보기관의 대규모 감시가 드러난 에드워드 스노든 사건 이후, 누구나 쉽게 쓸 수 있는 암호화 이메일을 만들겠다는 목표로 출발했다.

대표 제품은 Proton Mail이다. 이메일 내용을 암호화해 회사조차 이용자의 받은편지함을 읽을 수 없도록 설계했다고 Proton은 설명한다. 이후 인터넷 접속 경로를 감추는 Proton VPN, 암호화 클라우드 저장소 Proton Drive, 비밀번호 관리도구 Proton Pass, 일정관리 Proton Calendar로 사업을 넓혔다. 최근에는 문서·스프레드시트·화상회의와 개인정보 보호형 AI 비서 Lumo까지 추가했다.

주요 제품	하는 일	보안상 중요한 이유
Proton Mail	암호화 이메일	메시지와 첨부파일 보호
Proton VPN	인터넷 연결 암호화·IP 주소 보호	접속 기록과 위치 노출 완화
Proton Drive	암호화 파일 저장	문서·사진 등 민감정보 보호
Proton Pass	비밀번호·로그인 정보 관리	계정 탈취 방지
Calendar·Docs	일정·문서 협업	업무정보와 메타데이터 보호
Lumo	개인정보 보호형 AI 비서	대화 저장·학습 이용을 최소화한다고 회사가 주장

회사는 현재 1억 개 이상 계정과 10만 개 이상 조직 고객이 서비스를 이용한다고 밝히고 있다. 2024년에는 직원 수가 500명이라고 공개했다. 유럽에서 구글 워크스페이스나 마이크로소프트 365를 대신할 수 있는 ‘프라이버시 우선 업무도구’로 자리 잡으려는 회사다.

Proton은 비상장사다. 매출액과 영업이익을 담은 감사 재무제표를 대중에게 공개하지 않는다. 따라서 외부의 매출 추정치를 확정된 숫자처럼 사용할 수 없다. 수익은 무료 이용자를 유료 구독자가 지원하는 방식에서 주로 나온다. 회사는 수익성 있는 사업을 유지해야 독립성을 지킬 수 있다고 설명하며, 여건이 허락할 때 매출의 1%를 비영리 Proton Foundation에 배정한다고 밝히고 있다.

404 Media가 보도한 내부 갈등

404 Media는 현직 직원 8명과 전직 직원 1명을 인터뷰하고, 내부 Slack 대화와 회의 녹음, CTO가 작성한 AI 선언문을 검토했다고 밝혔다.

보도에 따르면 Proton 경영진은 직원들에게 AI를 더 많이 사용하라고 요구했다. 회사 컴퓨터에 AI가 작성한 코드의 비중을 추적하는 도구를 설치했고, 직원들이 업무에서 AI를 어떻게 쓰는지 다시 면접하는 절차도 진행했다. Proton의 바트 버틀러 CTO는 한 회의에서 10월에 작성된 코드의 90%가 AI로 만들어졌다고 말했다고 404 Media는 전했다. 여러 직원은 주로 Anthropic의 Claude를 사용한다고 설명했다.

갈등은 속도와 검증 사이에서 커졌다. 한 직원이 새 코드를 배포하기 전 며칠간 침투시험을 하자고 제안하자, 앤디 옌 최고경영자(CEO)가 이를 거칠게 비판했다고 보도됐다. 침투시험은 공격자의 입장에서 시스템을 시험해 약점을 찾는 절차다.

Proton 대변인은 404 Media의 상세 질문에 “일부 직원이 회사의 방향에 불만이 있거나 이를 오해하고 있고, 많은 사람이 불안해한다”며 “빠르게 움직이려는 과정에서 표현이 지나치게 직설적이었거나 설명이 늦었던 때가 있었다”고 답했다. 다만 이번 보도는 내부 의사결정과 문화에 관한 조사다. Proton 제품에서 실제 보안 사고나 새로운 취약점이 발견됐다는 뜻은 아니다.

AI가 코드를 쓰면 해킹 방법도 자동으로 아는가

결론부터 말하면 그렇지 않다. AI가 특정 코드를 생성했다는 사실만으로 그 AI가 비밀 통로를 기억하거나, 나중에 자동으로 그 제품을 해킹할 수 있는 것은 아니다. 일반적인 코드 생성 모델은 개발자의 질문을 바탕으로 그럴듯한 코드를 만들 뿐이다.

다만 두 가지는 구분해야 한다.

첫째, 회사의 실제 소스코드나 비밀번호·API 키 같은 기밀을 외부 AI 서비스에 입력하면 정보 노출 위험이 생길 수 있다. 서비스 제공업체가 입력을 얼마나 오래 보관하는지, 모델 학습에 사용하는지, 기업용 계약에서 어떤 보호를 제공하는지를 따져야 한다.

둘째, 공격자도 AI를 쓸 수 있다. AI는 많은 코드를 빠르게 읽고 반복되는 실수를 찾거나, 취약점을 시험하는 프로그램을 만드는 데 도움을 줄 수 있다. 그러나 이는 ‘코드를 작성한 같은 AI가 정답을 알고 있다’기보다, 공격과 방어 양쪽의 분석 속도가 모두 빨라지는 문제에 가깝다.

보안기업에서 AI 코딩이 더 민감한 네 가지 이유

1. AI는 틀린 코드를 자신 있게 제시할 수 있다

AI는 정답을 계산하는 기계가 아니라 다음에 올 코드를 예측하는 모델이다. 학습 자료에는 좋은 코드와 나쁜 코드가 함께 들어 있다. 2022년 발표된 GitHub Copilot 연구에서는 보안 취약점이 자주 발생하는 89개 상황에서 만든 1,689개 프로그램 가운데 약 40%가 취약한 것으로 평가됐다. 이 수치는 당시 모델과 실험조건의 결과이므로 오늘날 모든 AI 코드에 그대로 적용할 수는 없다. 그래도 AI 출력물을 검증 없이 믿어서는 안 된다는 경고는 남는다.

2023년 ACM 보안학회에 발표된 사용자 연구에서도 AI 코딩 도우미를 사용한 참가자들이 그렇지 않은 참가자보다 덜 안전한 코드를 작성했다. 그런데 AI를 쓴 참가자들은 자신의 코드가 더 안전하다고 믿는 경향도 보였다. 이를 ‘자동화 편향’이라고 한다. 기계가 만든 답이라는 이유로 사람이 의심을 덜 하는 현상이다.

2. AI가 쓰고 AI가 검토하면 같은 실수를 놓칠 수 있다

사람이 쓴 코드를 다른 사람이 검토하는 이유는 관점이 다르기 때문이다. 반면 비슷한 모델과 비슷한 지시문으로 코드를 만들고 검토하면 같은 가정과 같은 오류를 반복할 수 있다.

특히 암호화, 로그인, 비밀번호 저장, 권한 관리 코드는 작은 실수 하나가 큰 사고로 이어진다. 정상 작동한다는 것과 안전하다는 것은 다르다. 테스트를 통과해도 예상하지 못한 입력, 오래된 라이브러리, 잘못된 권한 설정 때문에 공격 통로가 생길 수 있다.

3. 존재하지 않는 소프트웨어 패키지를 추천할 수 있다

AI는 실제로 없는 패키지 이름을 만들어내기도 한다. 개발자가 이를 믿고 설치하려 하면, 공격자가 같은 이름의 악성 패키지를 저장소에 먼저 등록해 침투할 수 있다.

USENIX Security 2025에 공개된 연구는 16개 모델이 만든 57만6,000개 코드 샘플을 분석했다. 상용 모델이 추천한 패키지 가운데 평균 최소 5.2%, 오픈소스 모델은 21.7%가 존재하지 않는 이름이었다. 이 역시 특정 실험의 결과지만, AI 코딩이 소프트웨어 공급망 위험과 연결될 수 있음을 보여준다.

4. AI 에이전트에 너무 많은 권한을 주면 피해가 커진다

최근 코딩 AI는 답만 제시하지 않는다. 파일을 고치고, 명령어를 실행하고, 테스트를 돌리고, 배포까지 할 수 있다. 이때 AI가 읽기만 하면 되는 시스템에서 삭제·수정 권한까지 갖고 있으면 실수나 악성 지시의 피해가 커진다.

OWASP는 이를 ‘과도한 권한’ 위험으로 설명한다. 외부 문서나 웹페이지에 숨은 지시가 AI의 행동을 바꾸는 ‘프롬프트 인젝션’도 문제다. 안전한 운영을 위해서는 AI가 접근할 수 있는 저장소와 명령을 최소화하고, 중요한 변경은 사람이 승인해야 한다.

Proton에 더 높은 기준이 필요한 이유

일반 쇼핑 앱의 오류도 문제지만, Proton의 제품은 이메일·비밀번호·파일·VPN 접속처럼 이용자의 가장 민감한 정보를 다룬다. 고객은 Proton이 구글이나 마이크로소프트보다 개인정보를 더 신중하게 다룰 것이라고 믿고 서비스를 선택한다. 이 회사에서 보안은 기능 하나가 아니라 상품 자체다.

Proton은 모든 앱을 오픈소스로 공개하고 독립 보안감사를 받는다고 설명한다. 외부 전문가가 코드를 확인할 수 있다는 점은 중요한 방어 장치다. 그러나 공개 코드와 외부 감사가 빠른 내부 개발과 배포 과정의 모든 위험을 자동으로 없애지는 않는다. 감사 범위, 시행 시점, 배포 후 변경량이 다를 수 있기 때문이다.

AI 코딩 비중만으로 안전성을 판단해서도 안 된다. 90%가 AI 작성이어도 엄격한 테스트와 사람의 검토가 뒤따르면 위험을 낮출 수 있다. 반대로 AI 비중이 10%여도 민감한 인증 코드가 검증 없이 배포되면 위험하다. 중요한 숫자는 AI가 쓴 줄의 비율이 아니라, 고위험 코드 가운데 독립 검토와 침투시험을 거친 비율이다.

속도와 보안을 함께 잡으려면

Proton 같은 보안기업이 AI 코딩을 안전하게 확대하려면 다음 기준이 필요하다.

로그인·암호화·권한 관리 코드는 숙련된 보안 담당자가 반드시 검토한다.
AI가 만든 코드와 사람이 만든 코드를 같은 정적분석·동적분석·침투시험에 통과시킨다.
AI 도구에는 필요한 저장소와 명령만 허용하고, 운영 서버 배포는 사람이 승인한다.
소스코드·비밀키·고객정보를 외부 모델에 보내지 않도록 기술적 차단과 기업용 계약을 함께 둔다.
AI가 추천한 패키지는 실제 존재 여부, 작성자, 버전, 해시값을 자동 검증한다.
AI 생성 비율보다 취약점 발생률, 수정시간, 감사 통과율, 배포 후 사고를 공개한다.

미국 국립표준기술연구소(NIST)의 안전한 소프트웨어 개발 지침도 생성형 AI를 기존 보안 절차의 대체물이 아니라 별도로 관리해야 할 새로운 위험요소로 본다. 속도를 높이더라도 코드 출처, 변경 이력, 검증 책임을 추적할 수 있어야 한다.

보안산업 전체에 던지는 질문

이번 논란은 Proton 한 회사의 조직문화 문제로 끝나지 않는다. 많은 소프트웨어 회사가 AI로 개발 인력을 늘리지 않고도 더 많은 제품을 만들 수 있다고 기대한다. 투자자도 AI 도입률과 코드 생성량을 생산성 지표로 보기 시작했다.

그러나 코드 양은 품질과 같지 않다. AI가 하루에 열 배 많은 코드를 만들면 검토해야 할 코드도 열 배 늘 수 있다. 검토 인력을 줄이면서 생성량만 늘리면 보안 부채가 쌓인다. 지금은 빠르게 출시해 매출을 얻더라도, 나중에 취약점 수정·고객 보상·평판 회복 비용을 치를 수 있다.

반대로 AI가 항상 위험한 것도 아니다. 반복 코드를 줄이고, 테스트 사례를 만들고, 오래된 취약점을 찾는 데 쓰면 보안을 강화할 수 있다. 핵심은 AI 사용 여부가 아니라 누가 결과를 검증하고, 어떤 코드에 사람의 최종 책임을 남기느냐다.

Conclusion

Proton 내부 논란은 AI 코딩의 장점과 위험을 한꺼번에 보여준다. AI는 개발 속도를 높일 수 있지만, 보안기업의 신뢰까지 자동으로 만들어주지는 않는다.

AI가 자신이 작성한 코드의 해킹법을 비밀스럽게 알고 있는 것은 아니다. 더 현실적인 위험은 사람이 그럴듯한 AI 코드를 너무 빨리 믿고, 검토와 침투시험을 줄이며, 외부 모델이나 잘못된 패키지에 민감한 정보를 맡기는 데 있다.

Proton이 앞으로 공개해야 할 것도 ‘AI 코드 90%’ 같은 생산량이 아니다. 고위험 코드의 사람 검토율, 독립감사 범위, 침투시험 결과, 취약점 발견과 수정 속도다. 프라이버시 기업의 경쟁력은 얼마나 빨리 코드를 만들었는지가 아니라, 이용자가 얼마나 오래 믿을 수 있느냐에서 결정된다.