Featured Post

AI 바이브 코딩할 때 Renovate를 붙여보니 의존성 업데이트 스트레스가 확 줄었습니다

작성자:
Renovate - 의존성 업데이트 관련 이미지

요즘 개발하는 방식이 정말 많이 바뀌었어요. 저도 20년 가까이 개발 일을 해오면서 별별 도구를 다 써봤는데, 솔직히 요즘처럼 “아, 개발이 다시 좀 재밌네?” 싶은 시기는 오랜만입니다. 예전에는 새 프로젝트 하나 시작하면 package.json 열어놓고 버전 맞추고, deprecated 경고 지우고, 의존성 충돌 잡느라 반나절이 훅 지나가곤 했거든요. 그런데 요즘은 AI 바이브 코딩으로 큰 흐름을 잡고, Renovate로 의존성 업데이트를 자동화해두니까 손이 정말 덜 갑니다.

특히 ChatGPT나 GitHub Copilot으로 코드를 빠르게 만들다 보면 이런 일이 자주 생겨요. “어? 이 코드 최신 문법 기준인데 우리 프로젝트 라이브러리 버전이 너무 낮네?” 하는 순간이요. 예전 같으면 바로 검색창 열고 changelog 뒤지고, npm 페이지 들어가서 버전 확인하고, 테스트 돌리고… 뭐랄까, 개발 흐름이 뚝 끊겼죠. 그런데 Renovate를 붙여두고 나서는 그 귀찮은 구간이 꽤 많이 사라졌습니다. 오늘은 제가 실제로 AI 바이브 코딩과 Renovate를 어떻게 같이 쓰고 있는지, 그리고 쓰면서 알게 된 소소한 꿀팁들을 편하게 풀어볼게요.

AI 바이브 코딩에 Renovate를 붙이면 왜 이렇게 편할까?

처음부터 Renovate를 엄청 신뢰했던 건 아니에요. 저도 처음엔 “의존성 업데이트는 Dependabot으로도 충분하지 않나?” 싶었습니다. GitHub에서 기본으로 잘 붙기도 하고, 간단한 프로젝트에서는 크게 불편함이 없으니까요. 그런데 팀 프로젝트나 AI 코딩을 많이 하는 프로젝트에서는 이야기가 조금 달라지더라고요.

AI가 만들어주는 코드는 생각보다 최신 생태계를 기준으로 나오는 경우가 많아요. 예를 들어 ChatGPT에게 “Vite + React 프로젝트에서 Tailwind CSS v4 기준으로 버튼 컴포넌트 만들어줘”라고 요청하면, 당연히 최신 문법이나 최신 패키지 흐름에 맞춰서 답을 줍니다. 그런데 내 프로젝트는 아직 Tailwind CSS v3에 머물러 있다? 그러면 복사해서 붙여 넣는 순간부터 삐걱거려요.

이게 은근히 사람을 지치게 합니다. 코드는 잘 나온 것 같은데 막상 실행하면 에러가 나고, 에러 메시지를 따라가다 보면 결국 라이브러리 버전 문제였던 거죠.

TypeError: Cannot read properties of undefined
Error: This API is only available in the latest version
Warning: deprecated option detected in config

이런 로그들, 익숙하시죠. 저도 너무 많이 봤습니다. 밤에 조용히 코딩하다가 이런 메시지 뜨면 괜히 커피 한 잔 더 마시게 돼요.

그래서 저는 Renovate를 설정할 때 기본 방향을 이렇게 잡았어요. patch와 minor 업데이트는 최대한 자동으로 처리하고, major 업데이트는 사람이 직접 본다. 이 선만 지켜도 꽤 안정적입니다. 개발 흐름은 유지하면서, 큰 사고가 날 만한 변경은 사람이 한 번 더 보는 구조니까요.

제가 자주 쓰는 기준은 이렇습니다.

업데이트 종류 처리 방식 제가 느낀 안정감
patch 자동 머지 대부분 문제 없음. 보안 패치나 버그 수정이라 편하게 맡김
minor CI 통과 후 자동 머지 가끔 확인은 하지만, 대체로 자동화해도 괜찮았음
major 직접 리뷰 후 머지 무조건 사람이 봐야 마음이 편함
React, Next.js 같은 핵심 패키지 수동 관리 프로젝트 전체에 영향이 커서 자동화하지 않음

사실 처음에는 “AI 코딩이랑 의존성 업데이트 자동화를 굳이 엮어야 하나?” 싶었어요. 그런데 해보니까 이 둘은 꽤 잘 맞습니다. AI는 코드를 빠르게 만들어주고, Renovate는 그 코드가 기대하는 라이브러리 환경을 따라갈 수 있게 도와줘요. 개발자는 그 사이에서 방향만 잡아주면 됩니다. 예전처럼 모든 걸 손으로 붙잡고 있지 않아도 되는 거죠.

제가 실제로 쓰는 Renovate 설정 예시

그럼 실제 설정을 하나 보여드릴게요. 아래 예시는 제가 Next.js 14 프로젝트에서 쓰고 있는 형태와 거의 비슷합니다. 이 프로젝트에서는 AI를 주로 서버 액션, Supabase 연동, 폼 검증 코드 작성에 많이 활용하고 있어요. 특히 Supabase 쪽은 패키지 변화가 은근 있어서 Renovate가 꽤 든든한 역할을 해줍니다.

프로젝트 루트에 둔 renovate.json

저는 저장소 루트에 renovate.json 파일을 두고 이렇게 관리합니다.

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:best-practices"],
  "schedule": ["before 9am on Monday"],
  "packageRules": [
    {
      "matchUpdateTypes": ["minor", "patch"],
      "matchCurrentVersion": "!/^0/",
      "automerge": true,
      "automergeType": "pr",
      "platformAutomerge": true
    },
    {
      "matchDepTypes": ["devDependencies"],
      "automerge": true
    },
    {
      "matchPackageNames": ["@supabase/supabase-js"],
      "groupName": "supabase packages",
      "groupSlug": "supabase"
    },
    {
      "matchPackageNames": ["react", "react-dom"],
      "enabled": false
    }
  ]
}

여기서 제가 꽤 신경 쓰는 부분이 몇 가지 있어요.

    • schedule을 월요일 아침 9시 전으로 잡았습니다. 주말에 PR 알림 오는 거, 저는 별로 안 좋아해요. 쉬는 날은 쉬어야죠.
    • minor와 patch 업데이트만 자동 머지되도록 했습니다. 작은 변경은 기계에게 맡기고, 큰 변경은 제가 봅니다.
    • React와 react-dom은 일부러 자동 업데이트 대상에서 뺐습니다. 이런 핵심 패키지는 잘못 올리면 프로젝트 분위기가 확 달라져요.
    • Supabase 패키지는 묶어서 하나의 PR로 보게 했습니다. 관련 패키지가 따로따로 올라오면 리뷰하기가 은근 귀찮거든요.

이렇게 해두면 흐름이 꽤 자연스러워집니다. 예를 들어 제가 ChatGPT에게 “Supabase에서 사용자 프로필을 가져오는 Next.js 서버 액션 만들어줘”라고 요청했다고 해볼게요. AI는 최신 @supabase/supabase-js 기준으로 코드를 만들어줄 가능성이 높습니다. 그런데 우리 프로젝트 버전이 낮다면? Renovate가 이미 업데이트 PR을 만들어두었거나, 다음 스케줄에 맞춰 PR을 올려줍니다.

실제로 이런 일이 있었어요. 제가 ChatGPT로 서버 액션 코드를 만들었는데, @supabase/ssr 패키지 버전 차이 때문에 쿠키 처리 방식이 살짝 안 맞았습니다. 예전 같으면 문서 찾아보고, GitHub issue 뒤지고, “내가 뭘 잘못했나?” 하고 한참 헤맸을 거예요. 그런데 Renovate PR에 변경 내용과 릴리즈 노트가 같이 붙어 있어서 금방 원인을 찾았습니다. 그때 속으로 살짝 감탄했어요. “아, 이거 그냥 버전 관리 봇이 아니라 내 옆자리 동료 같네” 싶더라고요.

AI가 만든 코드와 Renovate PR이 만나는 실제 흐름

최근에 있었던 일 하나를 더 이야기해볼게요. 제가 ChatGPT에게 이렇게 물었습니다.

Next.js App Router에서 zod를 사용해서 폼 검증하는 예제 코드를 만들어줘.
서버 액션과 함께 쓸 수 있게 작성해줘.

ChatGPT는 꽤 그럴듯한 코드를 만들어줬어요. 그런데 문제는 그 코드가 zod v3 기준이었다는 겁니다. 우리 프로젝트는 아직 zod v2를 쓰고 있었고요. 그래서 그대로 붙여 넣으니 타입 에러가 나더라고요.

Property 'safeParse' does not exist on type ...
Type error: Argument of type ... is not assignable ...

처음엔 “AI가 또 대충 만든 건가?” 싶었는데, 막상 확인해보니 AI가 틀렸다기보다 프로젝트 의존성이 오래된 쪽에 가까웠습니다. 이럴 때 Renovate가 있으면 정말 편해요. 이미 zod 업데이트 PR이 올라와 있었거든요. 저는 그 PR을 열어서 릴리즈 노트를 보고, CI 결과 확인하고, 테스트 한 번 돌린 다음 머지했습니다.

흐름을 조금 정리해보면 이런 느낌입니다.

상황 제가 한 일 도구
폼 검증 코드가 필요함 AI에게 zod 기반 예제 요청 ChatGPT / GitHub Copilot
생성된 코드가 현재 프로젝트와 맞지 않음 에러 로그를 보고 라이브러리 버전 차이 확인 IDE / 터미널
zod 업데이트 PR이 이미 존재함 Renovate PR의 릴리즈 노트와 CI 결과 확인 Renovate
문제 없어 보임 PR 머지 후 로컬 테스트 GitHub / pnpm test
AI 코드 적용 폼 검증 로직 반영 후 정상 동작 확인 개발자

이 흐름이 익숙해지면 꽤 기분이 좋습니다. AI가 코드를 던져주고, Renovate가 환경을 맞춰주고, 저는 중간에서 판단만 해요. 물론 모든 걸 자동으로 믿고 맡기면 안 됩니다. 그래도 “내가 진짜 집중해야 하는 일”과 “도구에게 맡겨도 되는 일”이 점점 분리되는 느낌이 들어요. 이게 제가 생각하는 좋은 의미의 AI 바이브 코딩입니다.

Renovate를 쓰면서 진짜 도움 됐던 설정들

인터넷에 Renovate 설정 예시는 정말 많습니다. 그런데 막상 팀에 적용해보면 예쁜 설정과 오래 살아남는 설정은 조금 다르더라고요. 저는 너무 복잡한 설정은 오래 못 간다고 봅니다. 팀원이 이해하기 어렵고, 나중에 누군가 수정하려고 할 때 겁부터 나거든요. 그래서 저는 단순하지만 안전한 쪽을 좋아합니다.

자동 머지는 하되, CI는 꼭 통과하게 만들기

automerge를 켜면 정말 편합니다. 그런데 이 편함이 살짝 위험할 때도 있어요. 테스트가 부실한 프로젝트에서 자동 머지를 너무 넓게 열어두면, 어느 날 아침 출근했는데 빌드가 깨져 있는 경우가 생깁니다. 별로 유쾌한 아침은 아니죠.

그래서 저는 Renovate 브랜치에는 브랜치 보호 규칙을 꼭 걸어둡니다. 예를 들면 renovate/* 브랜치에서 올라오는 PR은 CI가 통과해야만 머지되게 하는 식이에요. 그리고 가능하면 squash merge로 정리합니다. 나중에 히스토리를 볼 때도 깔끔하고요.

    • Renovate 브랜치 prefix는 renovate/로 고정
    • CI 통과 전에는 자동 머지 금지
    • patch, minor 업데이트만 자동 머지
    • 핵심 런타임 패키지는 수동 리뷰

이 정도만 해도 안정감이 꽤 올라갑니다. 자동화를 하더라도 안전벨트는 매야 합니다. 개발 오래 하다 보면 이런 건 거의 본능이 돼요.

.nvmrc 같은 파일도 regexManagers로 챙기기

회사 프로젝트에서는 꼭 npm 패키지만 버전 관리 대상이 되는 게 아니잖아요. Node.js 버전을 .nvmrc에 적어두기도 하고, Dockerfile 안에 특정 이미지 태그를 박아두기도 하고, GitHub Actions workflow에 액션 버전을 적어두기도 합니다.

이런 것까지 Renovate가 봐주게 하려면 regexManagers를 쓰면 됩니다. 예를 들어 .nvmrc에 Node.js 버전을 명시하고 있다면 이런 식으로 설정할 수 있어요.

"regexManagers": [
  {
    "fileMatch": ["\\.nvmrc$"],
    "matchStrings": ["(?<currentValue>\\d+\\.\\d+\\.\\d+)"],
    "depNameTemplate": "node",
    "datasourceTemplate": "node"
  }
]

이렇게 해두면 Node.js 새 버전이 나왔을 때 .nvmrc 업데이트 PR도 올라옵니다. 별거 아닌 것 같지만, 팀 전체 개발 환경을 맞추는 데 꽤 도움이 됩니다. 특히 AI가 만들어준 코드가 최신 Node.js API를 은근슬쩍 쓰는 경우가 있거든요. 그때 런타임 버전이 낮으면 또 이상한 에러를 만나게 됩니다.

예전에 한 번은 로컬에서는 잘 되는데 CI에서만 깨지는 일이 있었어요. 알고 보니 제 로컬 Node.js는 최신이고, CI는 오래된 버전이었습니다. 이런 문제는 정말 사람 피곤하게 해요. 그래서 저는 런타임 버전도 가능하면 Renovate 관리 대상에 넣는 편입니다.

major 업데이트는 AI에게 마이그레이션 가이드를 먼저 읽히기

major 업데이트는 자동으로 넘기면 안 됩니다. 이건 제 나름의 원칙이에요. React 18에서 19로 넘어간다든지, Next.js 큰 버전이 바뀐다든지, Tailwind CSS 설정 방식이 확 달라진다든지. 이런 건 단순히 버전 숫자 하나 바뀌는 문제가 아니더라고요.

저는 major 업데이트 PR이 올라오면 바로 머지하지 않고, 먼저 릴리즈 노트와 마이그레이션 가이드를 AI에게 던집니다. 이런 식으로요.

이 라이브러리의 v3에서 v4 마이그레이션 가이드를 읽고,
우리 프로젝트에서 영향 받을 만한 부분을 체크리스트로 정리해줘.
Next.js App Router 기준으로 봐줘.

이렇게 물어보면 AI가 꽤 쓸 만한 체크리스트를 만들어줍니다. 물론 그대로 믿지는 않고 제가 다시 확인합니다. 그래도 시작점이 생긴다는 게 중요해요. 예전에는 문서 처음부터 끝까지 읽으면서 “어디가 우리 프로젝트랑 관련 있지?”를 직접 골라야 했는데, 이제는 초벌 정리를 AI가 해줍니다. 이 차이가 꽤 큽니다.

    • deprecated API 목록 확인
    • 설정 파일 변경 여부 확인
    • 빌드 옵션 변경 여부 확인
    • 테스트 코드 수정 필요 여부 확인
    • 배포 환경 변수 영향 확인

이런 식으로 체크리스트를 뽑아두면 리뷰할 때 마음이 훨씬 편합니다. 특히 팀원이 같이 보는 PR이라면 더 좋아요. “이거 그냥 올려도 되나요?”가 아니라 “이 항목들은 확인했고, 이 부분만 수정하면 됩니다”라고 이야기할 수 있으니까요.

업데이트 스케줄은 팀 리듬에 맞춰야 오래 갑니다

Renovate를 켜두면 PR이 생각보다 자주 올라옵니다. 처음엔 신기하고 좋죠. 그런데 어느 순간부터 알림이 너무 많아지면 팀원들이 슬슬 무시하기 시작합니다. 이게 제일 위험해요. 좋은 자동화도 사람을 피곤하게 만들면 오래 못 갑니다.

저희 팀은 스프린트를 2주 단위로 돌리는 편인데, 스프린트 중간에 의존성 업데이트 PR이 우르르 올라오면 흐름이 깨지더라고요. 그래서 업데이트 스케줄을 스프린트 리뷰 다음 날 오전으로 맞췄습니다. 예를 들어 화요일에 스프린트가 끝나면 수요일 오전에 Renovate PR이 올라오게 하는 식입니다.

팀 상황 추천 스케줄 이유
월요일 오전 회의가 많은 팀 화요일 오전 월요일 정신없는 시간대를 피할 수 있음
2주 스프린트 운영 팀 스프린트 리뷰 다음 날 개발 흐름을 덜 방해함
소규모 사이드 프로젝트 주 1회 월요일 오전 관리 부담이 적고 루틴 만들기 좋음
배포가 잦은 서비스 팀 주 2회 정해진 오전 시간 보안 패치 대응 속도를 높일 수 있음

저는 개인 프로젝트에서는 월요일 오전을 선호합니다. 주말에 여행을 다녀오거나 쉬고 나서 월요일 아침에 커피 마시면서 Renovate PR을 훑어보는 루틴이 나쁘지 않더라고요. 회사 프로젝트에서는 팀 리듬이 더 중요하고요. 도구는 결국 사람이 편하려고 쓰는 거니까요.

제가 Renovate와 AI 코딩을 같이 쓰면서 정한 작은 원칙

도구가 좋아질수록 오히려 기준이 더 필요하다는 생각을 자주 합니다. AI가 코드를 만들어주고 Renovate가 버전을 올려준다고 해서, 개발자가 손을 놓아도 된다는 뜻은 아니거든요. 저는 이 조합을 쓰면서 몇 가지 원칙을 정해뒀습니다.

    • AI가 만든 코드는 반드시 현재 프로젝트 버전과 맞춰본다. 최신 문법이라고 무조건 좋은 건 아닙니다.
    • Renovate PR은 릴리즈 노트를 한 번이라도 읽는다. 자동 머지 대상이 아니면 특히 더요.
    • major 업데이트는 절대 감으로 머지하지 않는다. 문서, 테스트, 마이그레이션 체크가 필요합니다.
    • 테스트가 없는 프로젝트에서는 automerge 범위를 좁힌다. 테스트 없는 자동화는 꽤 무섭습니다.
    • 팀원이 이해할 수 있는 설정만 남긴다. 혼자만 아는 고급 설정은 나중에 부채가 됩니다.

사실 이건 Renovate만의 이야기는 아닌 것 같아요. AI 도구도 마찬가지입니다. 잘 쓰면 정말 생산성이 올라가지만, 기준 없이 쓰면 프로젝트가 묘하게 산만해져요. 코드 스타일도 들쭉날쭉해지고, 라이브러리도 이것저것 섞이고, 어느 순간 “이거 누가 만든 구조야?” 싶은 상태가 됩니다. 무섭죠. 대개 그 누군가는 과거의 나입니다.

그래서 저는 AI에게 코드를 시킬 때도 항상 프로젝트 맥락을 같이 줍니다.

우리 프로젝트는 Next.js 14 App Router를 사용하고 있어.
TypeScript strict mode가 켜져 있고,
폼 검증은 zod를 쓰고 있어.
현재 zod 버전은 package.json 기준으로 맞춰서 코드 작성해줘.

이렇게만 말해도 결과물이 훨씬 좋아집니다. 여기에 Renovate가 최신 버전 PR을 꾸준히 올려주면, 프로젝트가 너무 뒤처지지 않으면서도 안정적으로 굴러갑니다. 저는 이 균형이 꽤 중요하다고 봐요.

이 조합은 이런 분들에게 특히 잘 맞습니다

지금도 제 옆 모니터에서는 Renovate PR 하나가 CI를 돌고 있고, 다른 창에서는 ChatGPT가 Rust 예제 코드를 만들어주고 있습니다. 가끔은 좀 웃겨요. 예전에는 밤새 문서 보면서 삽질하던 일을 이제는 도구들이 옆에서 나눠 맡아주는 느낌이라서요. 물론 여전히 개발자는 필요합니다. 아니, 오히려 판단하는 개발자가 더 중요해진 것 같아요.

AI 바이브 코딩과 Renovate 조합은 이런 분들에게 특히 추천하고 싶습니다.

    • ChatGPT나 GitHub Copilot을 자주 쓰는데 라이브러리 버전 차이 때문에 자주 막히는 분
    • 의존성 업데이트를 매번 수동으로 하다가 귀찮아서 미뤄두는 분
    • 팀 프로젝트에서 패키지 업데이트 정책을 좀 더 안정적으로 만들고 싶은 분
    • Next.js, React, Supabase, zod처럼 변화가 빠른 생태계에서 개발하는 분
    • 자동화는 하고 싶지만 major 업데이트까지 무작정 맡기기는 불안한 분

처음 설정하는 데는 30분에서 1시간 정도 걸릴 수 있습니다. 그런데 한 번 자리를 잡아두면 그 뒤로는 정말 손이 덜 가요. 저는 그 시간이 꽤 소중하다고 생각합니다. 남는 시간에 테스트를 하나 더 짜도 되고, 코드 리뷰를 더 꼼꼼히 해도 되고, 아니면 그냥 다음 여행지 숙소를 찾아봐도 됩니다. 저는 가끔 후자를 선택합니다. 사람이 계속 개발만 하고 살 수는 없잖아요.

Renovate는 의존성 업데이트를 대신해주는 도구이고, AI는 코딩 속도를 끌어올려주는 도구입니다. 둘을 같이 쓰면 귀찮은 반복 작업은 줄고, 개발자는 설계와 판단에 조금 더 집중할 수 있어요. 저는 이 방향이 꽤 마음에 듭니다. 너무 과하게 믿지만 않으면, 정말 괜찮은 동료들이에요.

AI 코딩을 이미 하고 있는데 의존성 업데이트 때문에 자주 발목 잡힌다면, Renovate를 한 번 붙여보세요. 처음엔 작은 프로젝트에 가볍게 적용해보는 걸 추천합니다. patch와 minor만 자동화해보고, major는 직접 리뷰하면서 감을 잡아보면 됩니다. 그렇게 조금씩 팀이나 개인 프로젝트에 맞춰가면, 어느 순간 “아, 이거 없으면 불편하네” 하는 날이 올 거예요.

궁금한 점이 있으면 편하게 물어보셔도 좋습니다. 제가 겪어본 선에서는 최대한 나눠드릴게요. 오늘도 에러는 적고, 커밋은 기분 좋게 쌓이는 하루 되시길 바랍니다.

댓글

댓글 쓰기