GitHub 초보자 입문 가이드: 저장소, Commit, Fork에서 하루 1커밋까지

많은 사람이 처음 GitHub를 열면, 영어 버튼들이 한꺼번에 보여 지쳐 버린다: Repository, Commit, Branch, Pull Request, Fork, Star, Watch, Issue, Actions… 프로그래머만 쓰는 도구처럼 느껴진다.

하지만 GitHub는 한마디로 이렇게 이해하면 된다.

GitHub = 코드 보관, 변경 이력 기록, 협업 개발, 프로젝트 공개를 위한 웹사이트.

AI 도구, Claude Code, Codex, Cursor, Vercel, Next.js, Python 프로젝트를 공부한다면 GitHub는 거의 피할 수 없다. 많은 오픈소스 프로젝트가 GitHub에 있고, 많은 웹사이트 배포도 GitHub 저장소와 연결되어 있다.

이 글은 Git 명령어를 한 번에 다루려는 게 아니다. 먼저 GitHub 화면에서 가장 자주 보이는 개념과 버튼을 이해하는 데 초점을 둔다. 화면을 먼저 이해한 뒤에 명령어를 천천히 배우면 훨씬 가볍다.

1. Git와 GitHub는 같은 건가요?

아니다.

간단히 말하면:

Git는 도구이고, GitHub는 플랫폼이다.

컴퓨터에서 Git으로 코드를 관리할 수 있고, 코드를 GitHub로 푸시해서 저장·공개할 수도 있다. Git가 바탕이 되는 도구라면, GitHub는 Git 위에 만든 협업 플랫폼과 웹사이트다.

2. Repository: 저장소란?

Repository는 보통 repo라고 줄여 부르며, 한국어로는 “저장소”다.

저장소는 하나의 프로젝트 폴더라고 볼 수 있다. 예:

my-website/
├── README.md
├── package.json
├── src/
└── public/

GitHub에서 저장소에는 보통 다음이 들어 있다.

• 프로젝트 코드
• 프로젝트 문서
• 변경 이력
• Issue 토론
• Pull Request 협업 기록
• Actions 자동화 흐름

자신의 웹사이트, Python 도구, AI Agent 프로젝트를 보여주고 싶다면 GitHub 저장소를 만들 수 있다. 개인 학습자에게 저장소는 단순 백업 위치를 넘어 장기 포트폴리오가 된다.

3. README: 프로젝트 설명서

README.md는 GitHub 프로젝트에서 가장 중요한 설명 파일 중 하나다.

다른 사람이 저장소를 열면 GitHub는 보통 README 내용을 자동으로 보여 준다. README는 최대한 명확하게 아래를 설명해야 한다.

1. 이 프로젝트가 무엇을 하는지. 2. 설치 및 실행 방법. 3. 주요 기능은 무엇인지. 4. 어떤 기술을 썼는지. 5. 프로젝트 스크린샷이나 데모 링크가 있는지. 6. 작성자, 라이선스, 기타 안내 사항.

개인 프로젝트의 경우 README가 잘 정리돼 있으면 코드만 쌓아두는 것보다 남이 내 역량을 빠르게 이해하기 쉽다. 특히 이력서용, 포트폴리오용, 오픈소스 학습용 프로젝트에서는 README가 프로젝트의 얼굴이다.

4. Commit: 커밋이 뭐죠?

Commit은 “버전 저장”이라고 이해하면 된다.

작은 수정이 끝날 때마다 commit을 하나씩 만들어 현재 상태를 기록할 수 있다. 예:

첫 번째 commit: 프로젝트 초기화
두 번째 commit: 홈 레이아웃 추가
세 번째 commit: 검색 기능 버그 수정
네 번째 commit: README 문서 업데이트

Commit의 의미는 “그냥 임시 저장”이 아니라, 프로젝트의 변경 내역을 명확히 남기는 것이다. 나중에 특정 기능이 언제 추가됐는지, 버그가 어떻게 생겼는지 궁금할 때 commit 기록을 보면 된다.

좋은 commit 메시지는 다음처럼 간결하게 무엇을 했는지를 적는 것이다.

Add homepage layout
Fix broken search filter
Update README installation guide
Refactor API request logic

중국어 프로젝트라면 중국어로 적어도 된다.

홈페이지 레이아웃 추가
검색 필터 깨짐 수정
README 설치 가이드 업데이트
API 요청 로직 리팩터링

초보자는 처음부터 엄격한 commit 규칙을 지킬 필요는 없다. 다만 aaa, test, 아무렇게나 바꾸기처럼 의미를 알 수 없는 메시지는 피하는 게 좋다.

5. Git commit의 정체성은 누가 결정하나요?

많은 초보가 오해한다.

VS Code에서 GitHub로 로그인했으니 commit 작성자도 그 GitHub 계정이다.

이건 완전히 맞지 않는다.

Git commit의 작성자 정체성은 주로 로컬 Git 설정으로 정해진다. 즉:

git config user.name
git config user.email

현재 프로젝트의 Git 정체성을 보려면 터미널에서 입력:

git config user.name
git config user.email

전체 계정 기본값을 설정하려면:

git config --global user.name "Your Name"
git config --global user.email "your-email@example.com"

유의할 점:

VS Code / GitHub 로그인: 주로 push, pull, 원격 저장소 접근을 위해 사용.
Git commit 작성자: 주로 git config의 user.name과 user.email로 결정.

그래서 GitHub 계정을 바꾼 뒤에는 로컬 Git 설정을 꼭 확인해 이전 이름/이메일이 그대로 남아 commit에 표시되지 않게 해야 한다.

6. Main과 Branch: 주력 라인과 브랜치란?

여기가 GitHub 초보자가 제일 막히는 부분이다.

main, branch, merge, pull request를 보면 처음엔 서로 다른 폴더인 줄 알거나, branch가 프로젝트 전체의 복사본이라고 오해하곤 한다.

더 정확한 이해는 이렇다.

main = 프로젝트의 주 라인 버전. 보통 가장 안정적이고 공식적인 코드.
branch = 특정 시점에서 갈라져 나온 수정 경로. 실험이나 기능 개발을 안전하게 진행.

GitHub 공식 문서에서 새 저장소는 기본 브랜치를 가진다고 한다. 누군가 저장소를 열어보거나 코드를 확인·클론할 때 기본으로 보이는 것도 보통 이 브랜치다. 최근 새 프로젝트는 기본 브랜치명이 main인 경우가 많고, 일부 오래된 프로젝트는 여전히 master일 수 있다.

1. 일상적인 비유로 먼저 이해하기

한 편의 진행 중인 글을 상상해 보자.

main은 정식 발행본이다:

FinalArticle.docx

어떤 장을 크게 바꾸고 싶지만 본문을 망칠까 봐 직접 수정하지 않고, 사본 초안을 만들어 작업한다:

FinalArticle.docx
SecondChapterDraft.docx

초안에서 마음껏 수정한다. 잘 되면 본문으로 병합하고, 못 미더우면 초안을 버리면 된다. 본문은 영향이 없다.

Git에서 이런 “초안 경로”를 branch라고 부른다.

다만 주의할 점: Git branch는 폴더를 통째로 무겁게 복제하는 게 아니다. Git 공식 설명에서 git branch는 새 branch head를 만들고 이를 현재 HEAD 또는 지정 지점으로 가리키는 것으로 설명한다. 초보자는 이렇게 이해하면 된다.

branch는 프로젝트를 완전 복사하는 것이 아니라, 특정 commit에서 시작해 새로운 수정 경로를 기록하는 것이다.

2. 왜 branch가 필요한가요?

실제 프로젝트에서는 여러 일이 동시에 벌어진다.

메인 코드는 안정적으로 유지
새 기능을 개발해야 함
누군가는 버그를 수정 중
또 다른 사람이 README를 다시 작성
운영 중 급한 장애를 긴급 처리해야 함

모든 사람이 직접 main을 건드리면 프로젝트가 쉽게 어지러워진다. 한 사람의 실수가 전체에 영향을 준다.

그래서 더 안전한 방식은:

main은 안정 유지
신규 기능은 feature 브랜치
버그 수정은 fix 브랜치
문서 수정은 docs 브랜치
문제없음이 확인되면 main으로 다시 병합

예:

main
├── feature/search-page
├── fix/mobile-layout
└── docs/update-readme

이건 마치 메인 도로 옆으로 몇 개의 공사 레인을 내는 것과 같다. 공사 레인에서 개조·실험·재작업을 한 뒤, 끝나면 본선으로 다시 연결한다.

3. main이 뭐죠?

main은 보통 저장소의 기본 브랜치이자 프로젝트의 주 브랜치다.

main은 이렇게 이해하면 된다:

이 프로젝트가 현재 외부에 공개되는 주요 버전.

흔한 상황:

• 누군가 내 GitHub 저장소를 열면 기본으로 보통 main이다.
• 누군가 저장소를 clone하면 로컬 기본으로 main을 가져온다.
• Vercel 같은 배포 플랫폼은 main 브랜치 변경을 감시하는 경우가 많다.
• 팀 프로젝트에서는 main을 실행 가능하고 배포 가능한 상태, 즉 비교적 안정적인 상태로 유지하라고 요구하는 경우가 많다.

그래서 초보자는 이런 습관을 들이면 좋다:

main에서 함부로 큰 변경을 하지 않는다.

작은 개인 학습 프로젝트는 main에서 직접 바꿔도 큰 문제는 없다. 하지만 공식 프로젝트면 새 브랜치로 작업하는 편이 좋다.

4. branch가 뭐죠?

branch는 한국어로 “분기”다.

다음처럼 이해하면 된다.

main의 어떤 버전에서 갈라져, 별도로 한 덩어리의 변경을 진행한다.

예를 들어 현재 main은 안정적이라고 하자:

main: 홈 안정, 글 목록 페이지 안정, 검색 안정

댓글 기능을 추가해 보고 싶은데 페이지를 망칠지 모르겠다면 새 브랜치를 연다.

feature/comment-system

이 브랜치에서 댓글 기능을 개발한다. 이때:

main은 그대로 유지
feature/comment-system에서는 과감히 수정

검증이 끝나면 다시 main으로 병합한다.

5. branch는 fork가 아니다

branch와 fork를 혼동하기 쉽다.

예:

내 저장소에서 feature/search-page를 만드는 건 branch.
남의 프로젝트를 내 계정으로 복사하는 건 fork.

따라서:

branch는 저장소 내부의 분기
fork는 저장소 간 복제

6. 가장 단순한 분기 워크플로우

초보자는 이 흐름만 기억하면 충분하다.

1. main은 안정 버전
2. main에서 새 branch 생성
3. branch에서 파일 수정
4. commit으로 수정 저장
5. GitHub로 push
6. Pull Request 생성
7. 문제없으면 merge로 main에 반영
8. 완료한 branch 삭제

실제 상황에 대응하면:

main
→ feature/update-homepage 새로 생성
→ 홈 수정
→ commit: Update homepage layout
→ push
→ Pull Request
→ merge into main

병합되면 main에 이 새 기능이 포함된다.

7. 자주 쓰는 브랜치 이름

브랜치 이름은 무엇을 하고 있는지 드러내는 게 좋다.

일반적인 형태:

feature/login-page
feature/search-function
fix/mobile-navbar
docs/update-readme
refactor/api-client

대략적 규칙은 다음과 같다.

초보자가 이름 규칙에 과하게 집착할 필요는 없지만, test1, newnew, final-version처럼 의미가 안 보이는 이름은 피하는 편이 좋다.

8. 한마디로 main과 branch 정리

이렇게 외우면 된다:

main은 주선, branch는 지선.
main은 안정적 공개 상태를 담당하고, branch는 안전한 수정 작업을 담당한다.
branch에서 완료되면 Pull Request로 main에 합친다.

개인 프로젝트라면 처음엔 main에 바로 커밋해도 된다. 하지만 프로젝트가 커지거나 사이트를 건드릴 때 오류가 걱정되면 branch를 쓰는 쪽이 좋다.

7. Pull Request: PR이 뭐예요?

Pull Request는 PR로 줄인다. 다음과 같이 보면 된다.

제가 일부를 고쳤으니 확인해 주세요. 괜찮으면 메인 프로젝트에 병합해 주세요.

PR은 팀 협업과 오픈소스 프로젝트에서 흔히 쓰인다.

예를 들어 다른 사람 프로젝트를 fork한 뒤 bug를 고쳐 PR을 보낼 수 있다. 원저자는 변경을 확인하고 토론하고 수정 요청을 한 뒤 병합 여부를 결정한다.

PR은 단순 “코드 업로드”가 아니라, 코드 리뷰·토론·병합의 협업 과정이다. GitHub 공식 문서도 Pull Request를 변경 제안, 피드백 수집, 충돌 처리, 병합 진행 메커니즘으로 설명한다.

8. Fork: 복제/파생이란?

Fork는 다음처럼 이해하면 된다.

다른 사람의 GitHub 저장소를 내 계정 아래에 한 번 복사한다.

Fork 후에는 내 복사본에서 자유롭게 수정해도 원본 프로젝트엔 영향이 없다.

전형적인 흐름:

오픈소스 프로젝트를 본다
→ Fork 클릭
→ 내 fork 저장소에서 수정
→ commit
→ Pull Request 시작
→ 원 프로젝트에 병합 요청

초보자에게 fork는 두 가지 용도가 흔하다.

1. 다른 사람 프로젝트 구조를 배우기. 2. 다른 사람 오픈소스 프로젝트를 기반으로 2차 개발.

단, fork가 저작권을 넘겨 주는 건 아니다. 남의 프로젝트를 쓰기 전 라이선스를 확인해 복제/수정/상업적 사용/재배포가 가능한지 봐야 한다.

9. Star: 저장/좋아요는?

Star는 GitHub의 북마크 또는 좋아요다.

가치 있다고 생각한 프로젝트는 Star를 눌러 나중에 다시 찾기 쉽게 할 수 있다.

Star 수는 프로젝트의 인기도를 대략 가늠할 때 쓰이기도 하지만, 유일한 기준은 아니다. Star가 많다고 반드시 나에게 맞는 프로젝트는 아니고, Star가 적다고 가치가 없는 것도 아니다.

AI, Agent, 프론트엔드, Python을 공부하는 사람에게는 Star를 오픈소스 프로젝트 즐겨찾기로 쓰면 좋다.

10. Watch: 프로젝트 알림 받기

Watch는 저장소 업데이트 알림을 구독하는 것이다.

Watch한 프로젝트의 경우 GitHub가 Issue, PR, Release 같은 동향을 알림으로 보낼 수 있다.

초보자는 너무 많은 프로젝트를 Watch하지 않는 것이 좋다. 너무 많은 알림이 올 수 있다.

간단히 정리하면:

11. Issue: 문제, 제안, 토론

Issue는 프로젝트 내의 “문제 티켓” 또는 “토론 글”로 보면 된다.

일반적 용도:

• 버그 보고
• 새 기능 제안
• 할 일 목록 기록
• 프로젝트 토론
• 사용 질문

예:

버그: 모바일에서 검색이 작동하지 않음
기능 요청: 다크 모드 추가
질문: API 키는 어떻게 설정하나요?

내 프로젝트에도 Issue를 써서 할 일을 관리할 수 있다. 예를 들어 개인 사이트에서 다음 같은 Issue를 생성하면 된다: 모바일 스타일 수정, SEO 설명 보강, 글 검색 추가, README 정리. 이렇게 하면 프로젝트가 산만한 파일 묶음이 아니라 실제 프로젝트처럼 보인다.

12. Actions: 자동화 흐름

GitHub Actions는 GitHub 기본 제공 자동화 도구다.

push 후 자동으로 다음을 실행할 수 있다.

• 자동 테스트
• 자동 빌드
• 자동 배포
• 코드 스타일 검사
• 릴리스 발행

예를 들어 많은 Vercel, Next.js, Python 프로젝트가 GitHub Actions 또는 다른 배포 플랫폼과 함께 자동화를 구성한다.

초보자가 처음부터 Actions를 급하게 배울 필요는 없다. 다만 버튼을 보면 자동화와 관련 있다는 정도만 알면 충분하다. commit, push, branch, PR를 익힌 뒤에 Actions를 배우면 훨씬 자연스럽다.

13. Code 버튼: 저장소 주소 복사와 다운로드

GitHub 저장소 페이지에서 초록색 Code 버튼은 중요하다.

클릭하면 보통 다음을 볼 수 있다.

• HTTPS 주소
• SSH 주소
• GitHub CLI 주소
• Download ZIP

일반적인 명령:

git clone https://github.com/username/project-name.git

원격 GitHub 저장소를 로컬 컴퓨터로 내려받는 뜻이다.

Git을 쓰지 않고 코드만 보고 싶다면:

Download ZIP

버튼을 눌러 프로젝트 전체를 압축 파일로 받을 수 있다.

14. Push, Pull, Clone의 의미

이 단어들은 정말 자주 나온다.

기본 흐름:

clone로 프로젝트를 로컬로 받기
→ 파일 수정
→ commit으로 변경 기록
→ push로 GitHub에 업로드

다른 사람이 원격 저장소를 수정했다면:

pull로 최신 내용 가져오기
→ 이어서 수정
→ commit
→ push

15. 하루 1커밋이란?

많은 사람이 말하는 “하루 1커밋”은 보통 하루에 GitHub에 유의미한 기여를 한 번 해, 기여 그래프를 연속으로 유지하는 것을 뜻한다.

GitHub 프로필에는 초록색 기여 그래프가 있어 날짜별 기여 현황을 보여준다. 기여에는 commit, pull request, issue, discussion 같은 활동이 포함될 수 있지만, 어떤 활동이 그래프에 계산되는지 규칙이 있어 모든 동작이 모두 들어가지는 않는다.

초보자가 기억할 점:

하루 1커밋은 초록칸을 채우기 위한 행위가 아니라, 꾸준히 프로젝트를 개선하는 습관을 만드는 것이다.

건전한 방법은 매일 하나의 작고 실제적인 변경을 하는 것:

• README의 한 단락 수정
• 작은 버그 하나 고치기
• 작은 기능 하나 추가
• 프로젝트 디렉터리 정리
• 학습 노트 하나 보강
• 한 화면 스타일 최적화
• 테스트 케이스 하나 추가

무의미한 커밋(예: 매일 공백 하나만 수정)은 성장이나 포트폴리오에 별 이득이 없다.

16. 초보자를 위한 하루 1커밋 연습법

무엇을 커밋할지 모르면 이런 리듬으로 해보자.

1. 1일차: 저장소 만들기

새 저장소를 만든다. 예:

github-learning-notes

README를 추가해 이 저장소가 GitHub 학습 노트를 정리하는 용도임을 쓴다.

2. 2일차: GitHub 핵심 용어 보강

README에 추가:

Repository = 저장소
Commit = 커밋
Branch = 브랜치
Pull Request = 병합 요청
Fork = 복제 / 파생

3. 3일차: 명령줄 노트 추가

새 파일 추가:

command-line-basics.md

ls, cd, mkdir, pwd 같은 명령을 기록한다.

4. 4일차: Git 명령 노트 추가

새 파일 추가:

git-basics.md

기록:

git status
git add .
git commit -m "Update notes"
git push

5. 5일차: 디렉터리 구조 정리

노트를 이렇게 정리:

github-learning-notes/
├── README.md
├── notes/
│   ├── command-line-basics.md
│   └── git-basics.md
└── resources.md

6. 6일차: 참고 자료 추가

resources.md를 추가해 GitHub Docs, Git 공식 문서, 훌륭한 오픈소스 프로젝트 링크를 기록한다.

7. 7일차: 주간 정리

README에 다음 내용을 보강:

이 일주일에 무엇을 배웠나?
아직 뭐가 모호한가?
다음으로 뭘 하고 싶은가?

이 방식이 기계적으로 커밋만 반복하는 것보다 가치 있다. 마지막엔 실제 학습 과정을 보여주는 프로젝트가 된다.

17. 초보자 필수 Git 명령어

VS Code를 쓰면 그래픽 인터페이스로도 많은 작업을 할 수 있다. 그래도 아래 명령은 이해하는 게 도움 된다.

현재 상태 확인:

git status

변경을 스테이징 영역에 추가:

git add .

변경을 커밋:

git commit -m "Update README"

GitHub로 푸시:

git push

GitHub에서 최신 내용 가져오기:

git pull

커밋 히스토리 보기:

git log --oneline

이 5개는 먼저 익히고, 복잡한 명령은 처음부터 외우려 할 필요 없다. 실제 프로젝트를 하다 보면 브랜치 전환, 충돌 해결, 버전 되돌리기 같은 시나리오가 자연스럽게 온다.

18. 초보자가 가장 자주 오해하는 부분

1. GitHub 로그인은 commit 정체성과 다르다

GitHub 로그인은 주로 원격 저장소 접근 권한을 위한 것이다. commit에 표시될 이름과 이메일은 Git 설정을 본다.

2. Fork는 다운로드가 아니다

Fork는 내 GitHub 계정 아래에 복제하는 것이고, Clone은 내 컴퓨터로 내려받는 것이다.

3. Commit는 Push가 아니다

Commit은 로컬 버전 저장, Push는 GitHub 업로드다.

4. Star는 Fork가 아니다

Star는 저장, Fork는 프로젝트 복제다.

5. Pull Request는 반드시 받아들여지지 않는다

PR은 원 프로젝트에 내 변경 병합을 요청하는 것일 뿐, 유지자가 수락·거절하거나 추가 수정을 요청할 수 있다.

6. GitHub 기여 그래프는 실제 역량과 같지 않다

기여 그래프는 지속성을 보여주지만 실력 전체를 대변하지는 못한다. 진짜 가치는 프로젝트 품질, 문서의 명확성, 실행 가능한 코드, 지속적 반복 기록이다.

19. 학습 순서 추천

초보자라면 이렇게 하는 게 좋다.

1. 먼저 저장소 화면을 읽는 법을 익히기: README, Code, Issues, Pull Requests, Actions. 2. Repository, Commit, Branch, Fork, Star, Watch 이해하기. 3. 이어서 git clone, git status, git add, git commit, git push 익히기. 4. 내 학습 노트 저장소를 만들어 일주일간 실제 커밋 유지. 5. 마지막으로 Pull Request, 오픈소스 기여, GitHub Actions를 공부한다.

처음부터 복잡한 협업을 몰두할 필요는 없다. 먼저 내 프로젝트를 올리고, 수정하고, 커밋하고, 보여주는 흐름을 완성하는 게 더 중요하다.

20. 마무리

GitHub 초보자에게 가장 중요한 건 모든 명령을 한 번에 다 아는 게 아니라, 핵심 동작을 먼저 이해하는 것이다.

저장소 생성
→ 파일 수정
→ commit
→ push
→ 프로젝트 공개

다른 프로젝트에 기여하고 싶다면 다음을 이해하면 된다.

Fork
→ 수정
→ Commit
→ Pull Request

GitHub 본질은 작품 기록, 역량 공개, 오픈소스 참여, 프로젝트 관리의 플랫폼이다. AI 도구와 웹 개발을 배우는 사람에게 GitHub는 단지 코드 저장소가 아니라 장기 포트폴리오다.

매일 조금씩 실제로 바꾸고, 꾸준히 기록하고, 꾸준히 커밋하고, 꾸준히 정리하는 것이 단기간에 복잡한 개념을 외우는 것보다 훨씬 중요하다.

자주 묻는 질문

이 글은 어떤 수준의 개발자에게 적합한가요?

본문의 “적용 대상” 설명을 참고하면 된다. 이 블로그의 프로그래밍 카테고리는 입문자부터 AI 프로그래밍 워크플로우까지 여러 수준을 다루며, 각 글마다 다른 사전 지식을 전제한다.

글의 도구나 명령은 운영체제별로 차이가 있나요?

있다. macOS, Linux, Windows의 터미널 환경, 경로 형식, 명령어 문법이 다르다. 글에서 특정 운영체제를 지정하지 않았다면 공식 문서를 보고 맞춤 설정하는 편이 좋다.

어떤 AI 도구를 함께 쓰면 좋은가요?

Claude Code와 Codex는 현재 실무에서 강한 코딩 AI로, 코드 해석, 로직 보완, 디버깅, 스크립트 생성에 쓸 수 있다. 관련 도구 소개는 CC Switch 도구 글과 Vibe Coding 면접 문제집을 참고하면 된다.

프로그래밍에서 가장 중요한 습관은?

실습이 이론 공부보다 중요하다. 가능한 한 빠르게 작은 실전 프로젝트라도 하나 잡고, 문제 생기면 이론만 보는 게 아니라 문서와 코드로 해결하는 연습을 하라.

참고 출처

• GitHub Docs: Hello World
• GitHub Docs: Changing the default branch
• GitHub Docs: Managing the default branch name for your repositories
• Git Documentation: git-branch
• GitHub Docs: Pull requests documentation
• GitHub Docs: Fork a repository
• GitHub Docs: Profile contributions reference
• GitHub Docs: Understanding GitHub Actions

Git 기본 조작에 익숙해졌다면 AI 도구를 워크플로우에 통합하는 내용도 이어서 보면 된다. Vibe Coding / Agentic Flow 면접 문제집.