-->

논쟁의 풍경

팀 Slack 채널에 이런 메시지가 올라온다고 상상해보세요.

“이 PR에 미사용 함수가 여러 개 있네요. AI가 생성한 코드 같은데, 검토하고 올리셨나요?”

이 메시지에 뭔가 문제가 있을까요? 코드 품질을 챙기는 것은 당연합니다. 하지만 “AI가 생성한 코드 같다”는 표현에 함의가 있습니다. 신뢰하기 어렵다는 뉘앙스입니다.

GitHub Octoverse 2024 보고서에 따르면 오픈소스 설문 응답자의 73%가 이미 AI 코딩 도구를 사용하고 있습니다. JetBrains 개발자 설문(2024)에서는 응답자의 69%가 ChatGPT를 써봤고, 49%가 정기적으로 사용한다고 밝혔습니다. AI 코딩은 선택의 문제가 아니라 이미 현실이 된 이야기입니다.

그렇다면 논쟁의 포인트는 바뀌어야 합니다. “AI가 짠 코드라서 못 믿겠다”에서 “AI가 만든 결과물을 우리 팀이 어떻게 검증하고 관리할 것인가”로요.

이 글은 그 전환을 어떻게 만들지에 관한 이야기입니다.

두 가지 새로운 패러다임

‘바이브 코딩(vibe coding)’이라는 표현은 Andrej Karpathy가 2025년 2월에 처음 제안했고, 이후 한 arXiv 연구(2505.19443)가 Vibe Coding과 Agentic Coding을 두 축으로 체계적으로 정리했습니다. 이 둘은 AI를 활용하는 방식의 서로 다른 두 축을 잘 설명해줍니다.

Vibe Coding은 개발자가 Creative Director 역할을 맡고 AI가 고속 실행자 역할을 하는 방식입니다. 개발자는 어떤 방향으로 갈지, 어떤 느낌이어야 하는지를 결정합니다. AI는 그 방향을 빠르게 코드로 구현합니다. 빠른 프로토타이핑, 아이디어 탐색, MVP 검증 단계에서 특히 효과적입니다.

Agentic Coding은 개발자가 Strategic Supervisor 역할을 맡고 AI가 더 자율적으로 작동하는 방식입니다. 개발자는 목표와 제약 조건을 설정합니다. AI 에이전트가 그 안에서 세부 구현, 테스트, 반복 개선을 처리합니다. 반복적이고 명확한 규칙이 있는 작업에서 강점을 보입니다.

이 두 패러다임의 공통점은 개발자의 역할이 없어진다는 게 아니라 달라진다는 점입니다. 코드를 한 줄씩 타이핑하는 사람에서, 품질을 판단하고 방향을 제시하는 사람으로의 전환입니다.

Vibe Coding과 Agentic Coding 두 패러다임 비교: 개발자와 AI의 역할, 적합한 단계

문화 문제가 기술 문제보다 먼저다

새로운 도구를 도입할 때 가장 흔한 실수는 도구를 먼저 결정하고 사람을 나중에 생각하는 것입니다.

“Cursor 사용 의무화합니다”라는 공지는 도구 결정입니다. “Cursor를 써본 사람 있으면 다음 스프린트 회고에서 경험 공유해주세요”는 문화 접근입니다. 두 번째 방식이 훨씬 지속적인 변화를 만듭니다.

AI 코딩 도구 도입이 팀 문화와 충돌하면 세 가지 패턴이 나타납니다.

저항형: AI 코드를 쓴 사람을 공개적으로 지적하거나, 비공식적으로 “저 사람은 AI 없으면 못 한다”는 평가가 퍼집니다. 팀원들은 AI를 쓰고도 숨기게 됩니다. 사용은 늘지만 학습은 일어나지 않습니다.

맹신형: 검토 없이 AI가 생성한 코드를 그대로 올립니다. 미사용 함수, 엣지 케이스 누락, 보안 취약점이 쌓입니다. “AI 때문에 버그났다”는 말이 나오고, 결국 도구를 금지하는 방향으로 갑니다.

학습형: AI를 쓰면서 생긴 실수를 팀이 공유하고, 거기서 더 나은 프로세스를 만들어갑니다. “이런 경우에 AI가 틀렸다, 이렇게 프롬프트를 바꾸니까 더 나았다”는 대화가 일상이 됩니다.

세 번째 패턴을 만드는 것이 문화 전환의 목표입니다.

실전 문화 전환 전략

PR 프로세스를 바꿔라

코드 리뷰에 “AI 활용 여부” 항목을 추가하는 것이 좋습니다. 이것의 목적은 감시가 아닙니다. AI가 어떻게 활용됐는지를 명시하면 리뷰어가 더 효과적으로 검토할 수 있습니다. “이 부분은 AI가 생성했고 내가 로직을 검토했다”는 표시가 있으면, 리뷰어는 그 부분의 엣지 케이스를 더 주의 깊게 볼 수 있습니다.

PR 템플릿에 넣을 수 있는 간단한 섹션 예시입니다.

## AI 활용 정보
- 사용 도구: (예: Cursor / GitHub Copilot / ChatGPT)
- 주요 활용 부분: (예: 유틸리티 함수 생성, 테스트 케이스 작성)
- 직접 검토한 부분: (예: 비즈니스 로직, 보안 관련 코드)

처음에는 불필요한 절차처럼 느껴질 수 있습니다. 팀이 AI 활용 패턴에 익숙해지면 자연스럽게 생략되거나 단순화될 것입니다.

자동화 품질 게이트를 강화하라

AI가 생성한 코드에서 특히 자주 나타나는 문제들이 있습니다. 미사용 코드, 과도한 추상화, 엣지 케이스 누락입니다. CI/CD 파이프라인에 이런 항목을 자동으로 체크하는 스텝을 추가하면, 코드 리뷰 전에 기계적으로 걸러낼 수 있습니다.

# CI 파이프라인에 추가 가능한 체크
jobs:
  quality-gate:
    steps:
      - name: 미사용 코드 탐지
        run: npx ts-unused-exports tsconfig.json

      - name: 보안 취약점 스캔
        run: npm audit --audit-level moderate

      - name: 테스트 커버리지 확인
        run: npm test -- --coverage --coverageThreshold='{"global":{"lines":80}}'

이런 자동화의 가치는 AI 코드에만 있지 않습니다. 모든 코드에 일관된 기준을 적용하면, “AI가 생성했기 때문에 더 의심해야 한다”는 이분법이 줄어듭니다. 검증 기준은 코드의 출처가 아니라 코드의 품질이어야 합니다.

Vibe Coding 문화 구축: 팀 안에서 어떻게 만드나

아이디어 탐색 세션

주 1회, 1시간 정도의 팀 Vibe Coding 세션을 운영해보세요. 특정 기능 구현이 목표가 아닙니다. “이 문제를 AI와 함께 어떻게 접근할 수 있을까”를 실험하는 시간입니다.

한 사람이 화면을 공유하고 AI와 대화하면서 코드를 만들어갑니다. 나머지는 “그 프롬프트를 이렇게 바꾸면 어떨까”, “이 부분은 다른 방식을 써보자”라고 실시간으로 코멘트합니다. 결과물이 프로덕션에 가는 게 아니라, 팀이 함께 AI 활용 패턴을 학습하는 게 목적입니다.

프롬프트 라이브러리 만들기

팀에서 효과가 좋았던 프롬프트 패턴을 공유 문서에 모아두는 것이 생각보다 효과적입니다. “React 컴포넌트 생성할 때 이 패턴으로 프롬프트를 쓰면 타입스크립트 오류가 적게 난다”, “API 에러 핸들링 코드는 이 형식으로 요청하면 된다” 같은 것들입니다.

이 라이브러리는 팀의 집단 지식이 됩니다. 새로 합류한 팀원이 AI 도구를 빠르게 학습할 수 있는 리소스가 되고, 기존 팀원도 서로의 패턴에서 배울 수 있습니다.

Cursor AI 실전 활용

Cursor를 팀이 사용한다면, 일관된 설정이 중요합니다. .cursorrules 파일을 팀 레포에 포함시키면 모든 팀원이 동일한 맥락에서 AI와 작업할 수 있습니다.

# .cursorrules 예시
system_prompt: |
  이 프로젝트는 TypeScript/React로 작성됩니다.
  
  코드 스타일:
  - 함수형 컴포넌트만 사용
  - props 타입은 항상 명시적으로 정의
  - 에러 처리는 반드시 포함
  - 미사용 변수는 생성하지 않음
  
  테스트:
  - 기능 구현 전에 테스트 케이스를 먼저 작성
  - 커버리지 80% 이상 유지

이 파일이 있으면 “AI가 우리 팀 코딩 스타일을 모른다”는 문제가 줄어듭니다.

Agentic Coding 거버넌스: 신뢰를 어떻게 쌓을까

AI 에이전트에게 더 많은 자율성을 주는 것은 자원 절약과 속도 향상을 가져옵니다. 하지만 아무 준비 없이 자율성을 주면 예상치 못한 결과가 나올 수 있습니다.

신뢰는 쌓아가는 것입니다. 처음에는 좁은 범위에서 시작합니다.

1단계: 에이전트가 코드 생성과 기본 테스트 작성을 합니다. 사람이 실시간으로 확인합니다.

2단계: 에이전트가 리팩터링과 문서화까지 맡습니다. 사람이 주기적으로 검토합니다.

3단계: 에이전트가 아키텍처 제안과 CI/CD 관련 작업까지 처리합니다. 사람이 중요한 결정에만 개입합니다.

이 단계를 빠르게 건너뛰면 안 됩니다. 에이전트의 성과를 측정하면서 신뢰를 쌓아야 합니다.

어떤 상황에서는 사람이 반드시 개입해야 합니다. 보안 관련 코드 변경, 데이터베이스 스키마 수정, 외부 API 계약 변경이 그것입니다. 이것들은 자동화의 편의성보다 실수의 비용이 훨씬 크기 때문입니다.

케이스 스터디: 스타트업의 문화 전환

한 스타트업 팀이 AI 코딩 도구를 팀 전체에 도입하기로 결정했습니다. 처음 한 달은 생각보다 어려웠습니다. 경험 많은 개발자들 중 일부는 “이게 정말 내 코드인가”라는 감각의 혼란을 경험했습니다. 주니어 개발자들은 반대로 너무 AI에 의존해 기본 원리를 이해하지 못한 채 기능을 완성하는 경우가 생겼습니다.

그 팀이 효과적이었다고 말한 변화는 이렇습니다.

우선 MVP 개발에서만 Vibe Coding을 명시적으로 허용했습니다. 아이디어가 시장에서 통하는지를 빠르게 검증하는 단계에서는 코드 품질보다 속도가 중요하다는 데 팀이 동의했습니다. 이 맥락 구분이 혼란을 줄였습니다.

다음으로 AI 활용 경험을 공유하는 비공식 채널을 만들었습니다. 잘 됐던 것, 안 됐던 것을 모두 올렸습니다. “이런 프롬프트로 냈더니 엣지 케이스를 다 빠뜨렸다”는 실패 경험이 팀 전체의 자산이 됐습니다.

MVP 개발 속도가 빨라진 건 수치로 나타났습니다. 하지만 팀원들이 더 의미 있게 여긴 변화는 “이전보다 재미있어졌다”는 것이었습니다. 반복적인 보일러플레이트 코드 작성에서 해방되고, 더 흥미로운 문제에 집중할 수 있게 됐습니다.

문화 전환 로드맵: 4단계

Phase 1: 인식 공유 (1~2개월)

목표는 팀이 같은 기준으로 AI 도구를 바라보게 하는 것입니다. 어떤 도구를 쓸지, 어떤 경우에 AI 결과를 믿고 어떤 경우에 더 검토할지를 함께 정합니다. 이 단계에서 중요한 건 규칙을 하향식으로 내려보내는 게 아니라, 팀이 함께 만드는 것입니다.

측정 지표: 팀원 80% 이상이 AI 도구를 한 번이상 실제 업무에 써봤는지.

Phase 2: 실험 (2~3개월)

샌드박스 환경에서 다양한 활용 패턴을 시도합니다. 무엇이 효과적이고 무엇이 기대보다 못한지를 기록합니다. 이 기록이 나중에 팀 표준이 됩니다.

측정 지표: 개발 속도 변화(15% 향상을 기대하되, 팀 상황에 따라 다를 수 있음), 코드 품질 지표 변화 추이.

Phase 3: 체계화 (3~4개월)

실험에서 효과적이었던 패턴을 표준화합니다. PR 템플릿 업데이트, 자동화 품질 게이트 강화, 팀 프롬프트 라이브러리 정리가 이 단계에서 이루어집니다.

측정 지표: AI 활용률, 버그 재발률, 코드 리뷰 시간 변화.

Phase 4: 지속 개선 (이후 계속)

새로운 AI 도구가 계속 나올 것입니다. 지금 만든 프로세스가 6개월 후에도 최선이 아닐 수 있습니다. 정기적으로 현재 방식을 검토하고 업데이트하는 루프가 필요합니다.

문화 변화를 어떻게 측정할 것인가

수치로 잡을 수 있는 것들이 있습니다.

  • AI 도구 채택률(팀원 중 실제로 쓰는 비율)
  • 코드 품질 지표(버그 재발률, 테스트 커버리지)
  • 개발 속도(배포 사이클 타임)
  • 온보딩 시간(새 팀원이 첫 PR을 올리기까지 걸리는 시간)

수치로 잡기 어렵지만 중요한 것들도 있습니다.

팀원들이 AI 활용 경험을 얼마나 자유롭게 공유하는가. 실패한 시도를 숨기지 않고 오히려 팀 학습의 소재로 쓰는가. AI 관련 결정을 내릴 때 팀에 심리적 안전감이 있는가.

월 1회 짧은 팀 회고에서 이 질문들을 다루는 것만으로도 문화 변화의 방향을 점검할 수 있습니다.

결론

AI 코딩 도구의 확산은 개발 문화에 질문을 던집니다. “AI가 짠 코드는 믿을 수 없다”는 반응과 “AI가 다 해주니까 괜찮다”는 반응 모두 잘못됐습니다. 둘 다 도구와의 관계를 제대로 설정하지 못한 것입니다.

건강한 문화는 이렇게 생겼습니다. AI 결과물을 비판적으로 검토하되, 그 검토가 도구에 대한 불신이 아니라 코드 품질에 대한 책임감에서 나옵니다. 실수를 했을 때 “AI 탓”이 아니라 “어떤 프로세스가 빠졌는가”를 묻습니다. 새로운 AI 도구가 나왔을 때 두려움보다 호기심으로 접근합니다.

이 문화는 선언으로 만들어지지 않습니다. 작은 실천들의 축적에서 나옵니다. 팀원 한 명이 AI 활용 실패 경험을 솔직하게 공유하는 것. 리더가 “나도 이 프롬프트로 했더니 이런 문제가 생겼다”고 말하는 것. PR 리뷰에서 “AI가 생성한 것 같은데”가 아니라 “이 부분 로직 한 번 더 확인해봐요”라고 말하는 것.

거창한 문화 혁신보다 이런 작은 변화들이 쌓이는 게 먼저입니다.

참고 자료

참고

GRPO에서 다시 PPO로: GLM-5.2가 IcePop으로 RL을 안정화한 방법

 

요즘 RL 포스트트레이닝의 대세는 critic을 버리는 GRPO 계열입니다. 그런데 GLM-5.2는 value model을 되살린 PPO로 돌아가고, IcePop으로 학습-추론 불일치를 잡았습니다. 이 선택의 근거와 ThakiCloud 훈련 인프라 관점의 시사점을 정리합니다.