본문으로 건너뛰기
Menu
AIMarketingNewsToolsAbout

AI

AI로 사이트는 만들었는데, Git·GitHub·Vercel은 뭐가 다를까?

발행일:

사이트는 만들어서 쓰고 있는데, Git이 정확히 뭐냐고 하면 설명이 막힌다. 오늘 AI와 대화하다가 내 이야기가 딱 그렇다는 걸 알았다. 코드를 고치고 사이트가 바뀌는 과정은 거쳤지만, 그 사이에서 어떤 도구가 무엇을 하는지는 또렷하게 구분하지 못하고 있었다.

출발은 GitHub의 Dynamic Workflows라는 기능이었다. AI에게 맡길 일을 나누고 순서를 정한다는 설명을 듣다가, 기존 도구에서도 하던 일과 무엇이 다른지 궁금해졌다. 그러다 GitHub는 협업하는 곳인지, Git은 프로그램을 작성하는 곳인지까지 질문이 이어졌다. 새 기능 하나를 알아보려다가 평소 들어온 이름들부터 다시 짚게 된 것이다.

AI로 사이트는 만들었는데, Git·GitHub·Vercel은 뭐가 다를까? · VECTORLOG 썸네일

먼저 짧게 정리하면

  • 코드는 편집기에서 작성하고, Git은 그 코드가 어떻게 바뀌었는지 기록한다
  • GitHub는 코드와 변경 이력을 온라인에서 관리하고 협업하는 플랫폼이며, Vercel은 코드를 실제 서비스로 배포하는 데 쓰인다
  • Copilot은 개발을 돕는 AI 도구이고, Dynamic Workflows는 AI가 참여할 작업의 순서와 조건을 코드로 정하는 기능이다

목차

  1. Git은 코드를 작성하는 프로그램일까?
  2. GitHub는 오픈소스만 모아놓는 곳일까?
  3. Vercel은 코드를 어떻게 실제 사이트로 바꿀까?
  4. GitHub Copilot은 여기서 무엇을 할까?
  5. Dynamic Workflows는 무엇이 다를까?
  6. 자주 묻는 질문

Git은 코드를 작성하는 프로그램일까?

Git은 파일의 변경 이력을 관리하는 버전 관리 도구다. 어느 부분을 어떻게 바꿨는지 비교하고, 기록해둔 이전 상태를 찾아볼 수 있다. 코드를 작성하는 편집기와는 역할이 다르다. Git 공식 설명

문서 파일을 ‘최종’, ‘최종수정’, ‘진짜최종’으로 나눠 저장하는 상황을 떠올리면 쉽다. 파일이 많아지면 무엇이 바뀌었고 어느 쪽을 써야 하는지 헷갈린다. Git을 쓰면 변경 내용을 이력으로 남기고 비교할 수 있다. 이때 변경 내용을 하나의 기록으로 확정하는 것이 커밋(commit)이다. Git과 변경 이력

GitHub 공개 저장소의 Commits 화면에 날짜별 변경 설명, 작성자와 짧은 커밋 ID가 나열된 모습

Git으로 남긴 커밋 이력을 GitHub에서 본 예시다. 변경 설명과 작성자, 날짜, 커밋 ID가 기록별로 남는다. 기록을 만드는 Git과 그 기록을 보여주는 GitHub의 역할을 함께 볼 수 있다.

출처: GitHub octocat/Hello-World 커밋 이력, 2026-10-02 직접 캡처

이미지 원문: GitHub 커밋 이력

예를 들어 사이트의 버튼 색을 바꾼다고 해보자. 색을 바꾸는 코드는 편집기에서 수정한다. Git으로는 그 수정 내용을 기록한다. 내가 직접 수정했든 AI가 수정했든, 파일을 바꾸는 작업과 그 변화를 기록하는 작업을 구분하면 된다.

오늘 내가 먼저 정리한 것도 이 차이였다. Git이라는 이름이 개발 과정에 계속 등장한다고 해서, 그 안에서 코드를 작성한다고 이해하면 다음 설명도 꼬인다. Git은 바뀐 내용을 관리하는 역할로 기억하는 편이 분명했다.

GitHub는 오픈소스만 모아놓는 곳일까?

GitHub는 Git으로 관리하는 프로젝트를 온라인에 올려 보관하고 협업하는 플랫폼이다. 프로젝트의 코드와 파일, 변경 이력을 담는 단위를 저장소(repository)라고 한다. Git을 변경 이력을 남기는 도구로 생각했다면, GitHub는 그 작업물과 이력을 함께 보며 협업하는 온라인 공간으로 이해할 수 있다. GitHub 저장소 설명

GitHub octocat/Hello-World 공개 저장소에 master 브랜치, README 파일과 3 Commits 링크가 표시된 화면

GitHub의 공개 예제 저장소 화면. 파일 목록과 README, 브랜치, 커밋 이력을 한곳에서 확인할 수 있다. 화면의 Public 표시는 이 저장소가 공개 상태라는 뜻이다.

출처: GitHub octocat/Hello-World, 2026-10-02 직접 캡처

이미지 원문: GitHub 공개 예제 저장소

GitHub에는 공개 프로젝트가 많지만 비공개 저장소도 만들 수 있다. 공개 저장소는 누구나 볼 수 있고, 비공개 저장소는 권한이 있는 사용자만 접근할 수 있다. 따라서 GitHub에 코드를 올렸다는 사실만으로 모든 코드가 공개되는 것은 아니다.

협업할 때 자주 나오는 말도 여기서 연결된다. 브랜치(branch)는 기존 작업과 나눠서 변경을 진행하는 갈래다. 풀 리퀘스트(pull request)는 그 변경을 다른 갈래에 합치자고 제안하고 검토하는 절차이며, 실제로 합치는 작업을 머지(merge)라고 한다. 저장소에서 쓰는 용어

여기서 하나 더 구분해야 한다. 내 작업 환경에서 커밋했다고 GitHub에 자동으로 올라가는 것은 아니다. 그 기록을 GitHub 같은 원격 저장소에 보내는 작업을 푸시(push)라고 한다. ‘변경을 기록했다’와 ‘그 기록을 온라인 저장소에 올렸다’는 서로 다른 상태인 셈이다. Git과 GitHub의 연결

Vercel은 코드를 어떻게 실제 사이트로 바꿀까?

Vercel은 코드를 실제로 접속할 수 있는 서비스로 배포하고 운영하는 플랫폼이다. GitHub에 코드를 보관하는 것만으로 방문자가 보는 사이트가 곧바로 바뀌지는 않는다. 코드를 실행할 수 있게 준비하고 서비스 환경에 반영하는 과정이 더 필요하다.

지금 읽고 있는 VECTORLOG와 내가 운영하는 FINDVALUE도 GitHub 저장소와 Vercel 배포를 사용한다. 사이트의 코드를 관리하는 곳과 실제 서비스가 실행되는 곳이 연결되어 있는 구조다. 내 사이트에 등장하는 도구들의 이름을 이 흐름에 놓으니 각각의 역할을 구분하기 쉬웠다.

앞의 버튼 색 변경을 끝까지 이어보면 이렇다. 편집기에서 색을 바꾸고, Git으로 변경을 커밋한 뒤, GitHub 저장소에 푸시한다. 연결된 Vercel은 설정에 따라 그 코드를 빌드하고 배포한다. 빌드는 코드를 실행하거나 제공할 수 있는 형태로 준비하는 과정이라고 이해하면 된다. Vercel의 Git 연동 배포

여기에는 검토용 미리보기 배포와 실제 서비스에 반영하는 운영 배포를 나누는 방식도 있다. 그래서 푸시가 끝났어도 미리보기만 바뀌었거나, 빌드가 실패해 운영 사이트에는 반영되지 않을 수 있다. 방문자가 보는 버튼까지 바뀌었는지는 해당 버전의 운영 배포가 성공했는지 확인해야 한다.

Vercel의 Promote to Production 확인 창에 운영 배포로 전환할 대상과 연결 도메인이 표시된 공식 예시

Vercel 공식 문서의 운영 배포 전환 화면. 미리보기 배포를 운영 환경으로 전환할 때 연결될 도메인과 대상을 확인한다. 공식 예시 이미지이며, 실제 내 사이트의 배포 기록은 아니다.

출처: Vercel Docs, Promoting Deployments

이미지 원문: Vercel 공식 배포 전환 안내

이렇게 따라가니 ‘수정 완료’라는 말도 조금 다르게 들렸다. 코드 파일을 고친 것인지, GitHub에 올린 것인지, 실제 사이트에 반영한 것인지에 따라 끝난 작업이 달랐다. 앞으로는 어디까지 완료됐는지 나눠서 확인할 수 있겠다.

GitHub Copilot은 여기서 무엇을 할까?

GitHub Copilot은 코드 작성과 이해, 수정 같은 개발 작업을 돕는 AI 도구다. 편집기에서 코드를 제안받거나 질문할 수 있고, 에이전트에게 여러 단계의 개발 작업을 맡길 수도 있다. GitHub 저장소와 연결해 쓸 수 있지만, Git이나 GitHub의 다른 이름은 아니다. Copilot 사용 환경과 역할

같은 버튼 수정 예시로 돌아가면 구분이 쉽다. Copilot 같은 AI 도구는 어떤 코드를 바꿔야 하는지 찾고 수정을 도울 수 있다. 그 변경을 Git으로 기록하고 GitHub에서 검토한 뒤 Vercel로 배포하는 흐름은 별도로 이어진다. 한 화면에서 여러 작업이 이루어져도 각각의 역할까지 같아지는 것은 아니다.

Dynamic Workflows는 무엇이 다를까?

이제 처음 궁금했던 기능으로 돌아올 수 있다. Dynamic Workflows는 작업의 단계와 조건, 결과를 넘기는 방법을 코드로 정의하고 그 안에 AI 에이전트의 작업을 넣는 방식이다. 순서대로 처리할 일과 동시에 진행할 일을 정하고, 중간 결과를 정해진 형식으로 받아 다음 단계에 넘길 수 있다. GitHub 공식 개념 문서

예를 들어 코드 변경을 검토하는 절차를 만든다고 해보자. 먼저 변경된 파일을 모으고, 서로 독립적인 부분은 나눠 검토한 뒤, 발견한 문제를 한곳에 모은다. 마지막에는 검토 결과를 확인하도록 멈추는 지점을 둘 수 있다. 이는 작동 방식을 설명하기 위한 예시이며 직접 실행해본 결과는 아니다.

작업을 나누거나 AI 여러 개를 쓰는 개념 자체가 이번에 처음 생긴 것은 아니다. 이 기능에서 주목할 점은 순서와 조건을 코드에 담아 다시 쓸 수 있다는 것이다. 다만 같은 절차를 실행한다고 AI의 답변까지 매번 같아지는 것은 아니다.

현재 Dynamic Workflows는 공개 프리뷰이며, Copilot CLI에서는 실험 기능을 활성화해야 한다. 구체적인 사용 조건은 적용할 때 다시 확인할 필요가 있다. 공식 발표와 이용 조건

자주 묻는 질문

  • GitHub 없이 Git만 사용할 수 있나요?

    가능하다. Git은 로컬 환경에서도 변경 이력을 관리할 수 있다. GitHub는 그 프로젝트를 온라인에서 관리하고 협업할 수 있는 플랫폼 중 하나다. Git 공식 설명

  • AI로 코딩하려면 이 개념을 전부 익혀야 하나요?

    모든 기능과 명령어를 먼저 공부해야 한다는 뜻은 아니다. 다만 코드 수정, 변경 기록, 검토, 배포가 각각 무엇인지는 구분해두는 편이 좋다. AI의 작업 설명을 이해하고 어느 결과를 확인해야 하는지 판단하는 데 도움이 된다.

결과물을 만드는 것에서 과정을 이해하는 것으로

오늘은 새 AI 기능을 알아보려다가 이미 쓰고 있던 도구들의 역할부터 다시 배웠다. Git은 변경을 기록하고, GitHub는 프로젝트를 관리하며 협업을 돕고, Vercel은 서비스를 배포한다. Copilot은 그 과정의 개발 작업을 돕고, Dynamic Workflows는 AI가 참여하는 작업 절차를 정의한다.

사이트를 만들어봤다는 사실만으로 이 관계를 모두 이해하고 있지는 않았다. 하지만 역할을 나누고 나니 AI가 작업을 설명할 때 무엇을 뜻하는지 알아들을 기준이 생겼다. 코드를 고쳤다는 말에 바로 끝났다고 생각하지 않고, 변경이 기록됐는지, 저장소에 올라갔는지, 운영 사이트에 배포됐는지 구분할 수 있게 된 것이다. 오늘 배운 개념은 다음에 내 사이트를 고칠 때부터 쓸 수 있다.

AI를 쓰면서 하나씩 이해해가는 과정을 함께 살펴보고 싶다면 VECTORLOG LETTER 구독 안내를 확인해 주세요.

CONTINUE READING

이 기록에서 이어서 보기

VECTORLOG LETTER

다음 기록도 받아보고 싶다면 구독을 연결해 주세요.

LETTER 구독 안내 →

WORK TOGETHER

함께 일해볼까요?

AI 활용, 웹사이트·콘텐츠, 디지털 마케팅에 관한 프로젝트나 협업 이야기, 편하게 연락 주세요.

카카오톡으로 문의이메일로 문의LinkedIn으로 연결