[카테고리:] 생산성

85%. JetBrains가 4월에 발표한 글로벌 개발자 1만 명 대상 조사에서, “직장에서 AI 코딩툴을 정기적으로 쓴다”고 답한 비율이다. 1년 전 같은 조사에서는 52%였다. 12개월 만에 33%포인트가 올라갔다. 도입을 망설이는 시기는 사실상 끝났다는 뜻이다.

그런데 이 숫자보다 더 흥미로운 디테일이 안에 숨어 있다.

Copilot 1위, 그러나 멈췄다

여전히 1위는 GitHub Copilot이다. 직장 내 사용률 29%. 그런데 전년 대비 증가폭이 단 2%포인트에 그쳤다. 사실상 정체다. 이미 들어갈 만한 곳엔 다 들어갔고, 추가 성장 여지가 줄어든 시장 포화 상태로 해석된다. Copilot이 졌다는 얘기는 아니다. 다만 “AI 코딩툴을 처음 도입할 때 자동으로 Copilot을 고른다”는 시기는 지났다.

Claude Code, 6배라는 숫자

이번 조사에서 가장 충격적인 수치는 Claude Code 쪽이다. 직장 내 사용률이 6개월 사이 3%에서 18%로 뛰었다. 6배다. 단순 자동완성을 넘어 멀티파일 작업과 자율 에이전트 흐름이 가능하다는 점이 결정적이었던 것으로 보인다. 1년 전에는 거의 존재감이 없던 도구가, 지금은 Copilot 다음 자리로 단숨에 올라섰다.

이 변화는 단순한 시장 점유율 게임이 아니다. 개발자가 AI 도구에 기대하는 것 자체가 바뀌었다는 신호다. “한 줄 자동완성”에서 “한 작업 통째로 맡기기”로.

실제로 쓰는 다섯 가지 작업

조사에서 개발자들이 실제로 AI에게 시키는 일 상위 다섯 가지를 보면 변화의 방향이 더 분명해진다.

1. 코드 자동완성 (78%) — 가장 많이 쓰지만 더 이상 차별점이 아님
2. 코드 설명·문서화 (64%) — 레거시 코드 이해, 주석 자동 생성
3. 버그 수정 제안 (61%) — 에러 메시지 붙여 넣고 해결책 받기
4. 테스트 코드 생성 (54%) — 반복적인 단위 테스트 작성
5. 멀티파일 에이전트 작업 (31%) — 여러 파일을 한 번에 수정하는 자율 작업

5위에 들어간 멀티파일 에이전트 작업이 이미 3명 중 1명 수준이라는 게 핵심이다. 1년 전 조사에는 이 항목 자체가 없었다. 새 카테고리가 생긴 것 자체가 시장 변화를 보여 준다.

만족도와 도입 장벽

한 번 쓰기 시작한 사람들의 79%가 “없으면 불편할 것”이라고 답했다. 사실상 의존도다. 반면 아직 안 쓰는 15% 그룹의 절반 이상이 “회사 보안 정책”을 이유로 꼽았다. 개인 의지가 아니라 조직 정책이 막고 있다는 뜻이다. 한국 기업이라면 익숙한 풍경이다.

한국 개발자에게 의미

두 가지 결론이 분명해진다. AI 코딩툴은 더 이상 “쓸지 말지”의 문제가 아니라 “어떻게 조합할지”의 문제다. 그리고 자동완성 수준에 머무는 도구는 빠르게 차별점을 잃고 있다. Claude Code, Cursor Composer 같은 멀티파일·에이전트 기반 흐름을 손에 익히는 게 지금 시점의 가장 큰 격차 변수다.

국내 개발자 커뮤니티에서는 GitHub Copilot 사용자는 많지만 Claude Code는 상대적으로 낯선 경우가 적지 않다. 글로벌 추세를 감안하면 1년 안에 격차가 더 벌어질 가능성이 높다.

지금 할 일

Copilot만 쓰고 있다면 가장 먼저 해 볼 일은 claude.ai/code에서 개인 프로젝트로 Claude Code를 한두 시간 굴려 보는 것이다. 멀티파일 에이전트 작업이 어떻게 다른지 직접 손에 익혀야 비로소 이번 통계 안의 31%가 무슨 뜻인지 와닿는다. 회사 보안 정책으로 막혀 있다면 차단 사유를 정확히 확인해 보자. 코드 외부 전송이 문제라면 로컬 LLM(Ollama + Gemma 4 등) 기반 대안이 있고, 라이선스 문제라면 엔터프라이즈 플랜으로 해결되는 경우가 많다.

관련 글

• Claude Code 처음 시작하는 법: 설치부터 실전까지 2026 완전 가이드
• Kiro vs Cursor vs Claude Code 2026 AI 코딩툴 3파전 비교
• Gemini Code Assist 무료: Cursor vs Windsurf vs Gemini 3파전

출처

• JetBrains Research — Which AI Coding Tools Do Developers Actually Use at Work?

매달 청구되는 Claude Code 구독비, Cursor Pro, OpenAI API 토큰 영수증을 보면서 이런 생각을 한 번쯤 해 봤을 것이다. “이걸 그냥 내 노트북에서 돌릴 수는 없나?” 4월 2일 Google이 Apache 2.0 라이선스로 푼 Gemma 4가 그 가능성을 현실로 만들었다. 코드는 사외로 나가지 않고, 매달 청구서는 0이 되며, 코딩 에이전트는 평소처럼 동작한다. 이 글은 실제로 어떻게 구성하는지 단계별로 정리한 것이다.

먼저 모델 고르기

Gemma 4는 네 가지 사이즈로 나온다. 핵심 추천은 26B-A4B(MoE)다. 파라미터는 26B이지만 MoE 구조라 추론 시 실제 활성화되는 건 3.8B에 불과하다. 8~14GB VRAM 노트북·데스크탑 GPU에서 26B급 품질을 낼 수 있는 이유다.

모델	최소 VRAM	추천 대상
E4B (4B)	6GB	RTX 3060 / 입문 테스트
26B-A4B (MoE)	8~14GB	RTX 3080·4070 / 실무 추천
31B Dense	20GB+	RTX 4090 / 최고 품질

맥북 사용자에게도 좋은 소식이 있다. M4 Pro(통합 메모리 48GB) 기준 26B-A4B가 51 토큰/초를 낸다. 컨텍스트는 최대 256K까지 늘릴 수 있지만 풀 컨텍스트를 쓰려면 VRAM 여유가 추가로 필요하다.

Step 1 — Ollama로 30초 만에 띄우기

로컬 LLM 진입의 가장 짧은 길은 Ollama다. 설치 후 명령어 두 줄이면 된다.

# 설치: ollama.com에서 다운로드
ollama pull gemma4:26b      # 8~14GB VRAM 권장
ollama pull gemma4:e4b      # 6GB VRAM 입문용
ollama run gemma4:26b

Ollama는 localhost:11434에서 자동으로 OpenAI 호환 API를 노출한다. 이 한 가지 사실 때문에 다음 단계가 전부 쉬워진다. OpenAI SDK를 쓰는 모든 코딩 에이전트가 BaseURL만 바꾸면 그대로 동작하기 때문이다.

VRAM이 빠듯하다면 양자화 버전(gemma4:26b-q4)을 추천한다. 메모리 60% 절약, 성능 손실은 2~5% 수준이다. 일상적인 코딩 작업에서는 체감하기 어렵다.

Step 2 — 에이전트 연결

Continue.dev (VS Code · JetBrains)

Continue.dev 확장을 설치한 뒤 ~/.continue/config.json에 모델 정의를 추가한다.

{
  "models": [{
    "title": "Gemma 4 26B",
    "provider": "ollama",
    "model": "gemma4:26b"
  }],
  "tabAutocompleteModel": {
    "title": "Gemma 4 E4B",
    "provider": "ollama",
    "model": "gemma4:e4b"
  }
}

자동완성에는 빠른 E4B, 채팅과 코드 생성에는 품질 좋은 26B를 분리해서 쓰는 게 가장 효율적인 조합이다.

Cursor (Custom Model)

Settings → Models → OpenAI에서 “Override Base URL”을 켜고 http://localhost:11434/v1을 입력한다. Cursor의 멀티파일 에이전트 기능(Composer)도 그대로 작동한다.

Claude Code에서 Gemma 4 쓰기

Ollama 또는 LM Studio Headless를 서버로 띄운 뒤 환경변수로 엔드포인트를 지정하면 Claude Code도 로컬 Gemma 4와 연결된다.

ANTHROPIC_BASE_URL=http://localhost:11434/v1 \
ANTHROPIC_API_KEY=local \
claude --model gemma4:26b

또는 ~/.claude/settings.json에 baseURL을 고정으로 박아 두면 매번 환경변수를 칠 필요가 없다.

비용 — 실제 숫자

방식	월 비용 (일반 개발자 기준)	특징
Claude Code Pro	$100+/월	최고 품질, 외부 전송
Cursor Pro	$20/월 + API 초과	멀티 모델, 외부 전송
Gemma 4 로컬	전기세 ~$2~5/월	무료, 코드 외부 전송 없음

RTX 3080 기준 하루 4~6시간 코딩 사용 시 전기세는 월 2~5달러 수준이다. 단점도 분명하다. GPU를 코딩 에이전트가 점유하기 때문에 게임이나 영상 렌더링 같은 다른 GPU 집약 작업은 동시에 하기 어렵다.

로컬이 잘 맞는 작업, 클라우드가 잘 맞는 작업

로컬 Gemma 4가 빛나는 영역은 속도와 보안이다. 코드 자동완성과 인라인 제안처럼 응답 속도가 중요한 작업, 외부 전송이 금지된 보안 민감 코드, 반복적인 보일러플레이트 생성, 개인 프로젝트의 잦은 소규모 편집 — 이 네 가지가 대표적이다.

반대로 클라우드 API가 여전히 우위인 영역도 있다. Claude Opus 4.6 수준의 추론이 필요한 복잡한 아키텍처 설계, 수만 줄짜리 코드베이스 전체 리팩토링, 8시간짜리 자율 에이전트 실행. 이 작업들은 글로벌 서버 자원과 최상위 모델이 필요하다. 둘을 함께 쓰는 하이브리드 구성이 현실적인 답이다.

한국 개발자에게 의미

월 구독비 부담이 있는 개인 개발자, 그리고 외부 AI API 사용이 막혀 있는 기업 환경 — 두 그룹이 가장 큰 수혜자다. Gemma 4 26B의 코딩 성능은 Claude Sonnet 3.5 수준으로 평가받고 있어, 일상적인 코딩 작업에서는 충분한 품질이 나온다.

지금 할 일

가장 빠른 시작은 ollama.com에서 Ollama를 설치하고 6GB VRAM이면 충분한 E4B 버전을 한 번 띄워 보는 것이다. 평소 자주 쓰는 코드 한 조각을 그대로 던져 봐서 응답 품질이 본인 작업에 맞는지 확인한 다음, 26B로 올리고 Continue.dev나 Cursor에 연결해 본다. 회사 코드를 외부로 보낼 수 없는 환경이라면 이 구성 자체가 새로운 개발 환경의 출발점이다.

관련 글

• 바이브 코딩 입문: Cursor·Replit·Bolt
• 바이브 코딩의 역습: AI 생성 코드 보안 취약점 2.74배
• AI 코딩툴 무료 플랜 총비교 2026

출처

• Google DeepMind 공식 — Gemma 4 발표
• HackerNews — Running Gemma 4 with Claude Code
• Ollama 공식 문서

2.74배. Veracode가 2026년 봄에 발표한 GenAI 코드 보안 보고서의 핵심 숫자다. AI가 작성한 코드의 취약점이 사람이 작성한 코드보다 평균 2.74배 더 많다는 측정값. 같은 시점에 Escape.tech가 5,600개 바이브 코딩 앱을 분석했더니 비밀키 노출 400건, 개인정보 노출 175건이 잡혔다. 같은 흐름의 다른 보고서가 비슷한 결론을 가리키고 있다.

이 글은 바이브 코딩을 그만두라는 주장이 아니다. 빠르고 편리한 도구를 어떤 조건 위에서 써야 안전한지를 정리한 것이다.

숫자가 말해 주는 풍경

구체 수치를 한 번 모아 보면 분위기가 더 분명해진다.

• 15개 바이브 코딩 앱을 정밀 감사한 결과, 69개 취약점 중 6개가 치명적이었다 — DB 무단 열람, 세션 탈취, root 권한 탈취가 가능한 수준
• 5,600개 앱 분석에서 취약점 2,000개 이상, 비밀키 노출 400건, 개인정보 노출 175건
• AI 코딩 도구로 협업한 커밋의 비밀키 유출 비율이 일반 코드의 두 배 수준(3.2%)
• 현재 새로 쓰이는 코드 중 AI가 생성하거나 보조한 비율은 약 42%, 2027년에는 50%를 넘을 전망

주의해서 읽을 점이 있다. 이 숫자들은 “바이브 코딩 = 위험”이 아니라 “검토 없이 배포된 AI 코드 = 위험”에 가깝다. 같은 보고서가 함께 강조하는 게 바로 그 부분이다. AI 생성 코드의 리뷰 비율이 60%에 머물러 있다는 통계.

왜 AI 코드는 보안에 약한가

이유는 모델 능력 부족이 아니라 학습 환경과 사용 패턴의 조합에서 나온다. 첫째, 학습 데이터의 그늘. 인터넷에 공개된 코드에는 취약점이 포함된 코드가 적지 않다. 모델은 그 패턴을 그대로 흡수한다. 둘째, 시스템 전체 보안 흐름에 대한 맥락 부족. 모델은 개별 함수는 잘 만들지만 인증·세션 라이프사이클·권한 전파 같은 시스템 차원의 흐름을 추적하지 못한다. 셋째, 사용자 측의 검토 생략. 바이브 코딩의 매력 자체가 속도이기 때문에 코드 리뷰 단계가 자주 압축되거나 사라진다.

이 셋 중 가장 빠르게 고칠 수 있는 건 셋째다. 모델은 하루아침에 안 바뀌지만 검토 절차는 오늘부터 바꿀 수 있다.

HackerNews에서 불붙은 논쟁

4월 7일 HackerNews 상위권에 ‘The cult of vibe coding is dogfooding run amok’이라는 글이 443점을 받으며 화제가 됐다. 요지는 단순하다. 바이브 코딩 문화가 코드 품질보다 속도를 우선하는 풍조를 만들고 있다는 비판이다. 가장 공감을 많이 받은 댓글은 한 줄로 정리된다. “프로덕션에 바이브 코딩 결과물을 그대로 올리는 건 시한폭탄을 심는 것과 같다.”

해석은 갈린다. 개인 토이 프로젝트나 사내 도구 수준에서는 여전히 이득이 비용을 압도한다는 반론도 많다. 결국 핵심은 “어디까지 이 방식으로 가도 되는가”의 선을 어디에 긋느냐다.

가장 위험한 구간 네 곳

바이브 코딩으로 만든 결과물 중 보안 취약점이 가장 자주 발견된 구간은 일관된 패턴이 있다.

1. 인증·세션 관리 — 세션 토큰 저장, 만료, 재발급 흐름
2. DB 접근 계층 — 파라미터 바인딩 누락, 권한 분리 미흡
3. 비밀키·환경변수 처리 — 코드에 하드코딩, 로그 노출, 클라이언트 번들 포함
4. 외부 API 호출과 인증 헤더 — 리다이렉트 신뢰, CSRF 방어 누락

이 네 영역만 우선 점검해도 바이브 코딩 결과물의 치명적 취약점 대부분이 잡힌다.

그래서 — 쓰되, 배포 전에 한 번은 잡고 가자

바이브 코딩을 안 쓰는 건 현실적이지 않다. 이미 새 코드의 절반 가까이가 AI 손에서 나오는 시대다. 핵심은 외부에 노출되는 서비스로 가기 전에 한 번의 점검 단계를 끼워 넣는 것이다. 개인 토이나 사내 실험은 지금 흐름대로 쓰되, 외부 사용자가 닿는 코드는 검토 없이 배포하지 않는다 — 이 한 가지 원칙이 위 통계 대부분을 무력화한다.

지금 할 일

이미 바이브 코딩으로 만든 앱이 외부에 떠 있다면 가장 먼저 인증·세션·DB 접근 부분을 우선 점검한다. GitHub Actions에 무료 SAST 도구(Checkmarx 무료 플랜, Semgrep, GitHub Code Scanning 등)를 한 번 연결해 두면 푸시할 때마다 AI 코드가 자동으로 스캔된다. 마지막으로 환경변수와 API 키가 코드에 하드코딩돼 있지 않은지, .env 파일이 git에 들어가 있지 않은지 한 번 확인해 두자. 이 세 단계만 거쳐도 5,600개 앱 분석에서 잡힌 취약점 중 큰 비중이 사라진다.

관련 글

• 바이브 코딩 입문: 코드 없이 앱 만드는 2026년의 개발 방식
• Kiro vs Cursor vs Claude Code: 2026 AI 코딩툴 3파전 비교
• Claude Code 처음 시작하는 법: 설치부터 실전까지

출처

• Veracode — Spring 2026 GenAI Code Security Report
• Escape.tech — 바이브 코딩 취약점 분석 방법론
• HackerNews — The cult of vibe coding 토론

대표이미지 출처: Snyk 공식 블로그