Codex Git worktree 사용법: 여러 AI 작업을 별도 폴더로 진행하기

AI에게 홈페이지를 만들라고 시켰는데, 다른 채팅에서는 같은 홈페이지의 로그인 화면을 수정하고 있다면 어떤 일이 생길까요? 두 채팅이 똑같은 프로젝트 폴더를 수정하면 한쪽 작업이 다른 쪽의 파일을 바꿔 놓을 수 있습니다. 나중에 “어느 수정이 누구 것인지” 구분하기도 어려워집니다. 이럴 때 알아 두면 좋은 것이 Git worktree(워크트리)입니다. 하나의 프로젝트를 완전히 새로 복제하지 않고도 작업별로 서로 다른 폴더와 브랜치를 마련하는 방법입니다.

OpenAI Codex의 데스크톱 앱에서도 이 방식을 활용해 별도 작업 공간에서 채팅을 진행할 수 있습니다. 이번 글에서는 왜 분리가 필요한지 → Codex에서 Worktree 시작하기 → Git 명령어로 직접 만들기 → 두 작업의 결과 확인하기 → 안전하게 정리하기까지 실전 예시로 설명하겠습니다. 이 글은 2026년 10월 16일 확인한 공식 문서를 바탕으로 작성했습니다. 사용자 컴퓨터에서 실제 프로젝트를 생성하거나 명령을 실행해 성공한 후기 형태는 아닙니다.

자체 제작 개념도 · EMFLS AI

이 글의 순서

• 1. 왜 AI 코딩 채팅마다 작업 공간을 분리해야 할까요?
• 2. Git 저장소·브랜치·worktree를 쉽게 구별하기
• 3. 언제 Worktree를 사용하면 좋을까요?
• 4. 방법 A: Codex 데스크톱 앱에서 Worktree 선택하기
• 5. 방법 B: Git 명령어로 Worktree 직접 만들기
• 6. Codex에게 다른 폴더를 맡길 때 기억할 규칙
• 7. 별도 Worktree라면 파일 충돌이 완전히 없어질까요?
• 8. 두 작업이 끝나면 어떻게 하나로 합치나요?
• 9. 작업이 끝난 Worktree는 어떻게 정리하나요?
• 10. Codex Worktree에서 자주 겪는 문제
• 11. Codex를 병렬로 사용할 때 추천하는 운영 규칙
• 자주 묻는 질문(FAQ)
• 마무리: AI 두 개보다 중요한 것은 작업 공간 두 개입니다

1. 왜 AI 코딩 채팅마다 작업 공간을 분리해야 할까요?

다음 상황을 생각해 보세요.

• 채팅 A: “로그인 화면에 이메일 입력칸을 추가해 줘.”
• 채팅 B: “홈페이지의 색상과 버튼 크기를 바꿔 줘.” 두 채팅이 같은 파일을 동시에 수정하면, A가 저장한 코드를 B가 다시 덮어쓰거나 서로의 변경 내용을 모른 채 다른 판단을 내릴 수 있습니다. 이 문제를 줄이는 방법은 각 채팅에 자기 작업 공간을 주는 것입니다. 집에서 한 책상을 두 사람이 동시에 사용하면 종이나 도구가 섞이기 쉽습니다. 반면 책상을 따로 주면 각자 작업한 뒤 결과물만 비교할 수 있죠. Git worktree도 비슷합니다. 같은 프로젝트의 기록을 공유하면서, 현재 작업 파일은 다른 폴더에서 다루도록 분리합니다. 다만 책상이 분리돼도 나중에 작업 내용을 하나로 합칠 때 의견이 충돌할 수 있습니다. worktree는 동시에 파일을 직접 덮어쓰는 위험을 줄여 주는 도구이지, 코드 병합 충돌을 영원히 없애 주는 마법이 아닙니다.

자체 제작 개념도 · EMFLS AI

2. Git 저장소·브랜치·worktree를 쉽게 구별하기

비슷하게 생긴 말이 많아서 처음에는 헷갈릴 수 있습니다. Git 저장소는 프로젝트의 코드 변경 기록을 관리하는 곳입니다. 브랜치는 같은 프로젝트에서 작업 방향을 나누는 이름표입니다. 예를 들어 로그인 개선을 맡는 feature/login, 디자인 변경을 맡는 feature/design을 만들 수 있습니다. Worktree는 그 브랜치에서 실제 파일을 열고 수정하는 별도 폴더입니다.

구분	쉬운 뜻	이번 예시
저장소	프로젝트 변경 기록	my-project
브랜치	작업 방향을 나타내는 이름	feature/login
worktree	실제로 파일을 수정하는 별도 폴더	my-project-login

일반적인 git clone은 저장소를 추가로 복제하는 방식입니다. Git 공식 문서에 따르면 Worktree는 하나의 Git 저장소에 연결된 추가 작업 폴더를 만드는 방법이므로 목적과 관리 방식이 다릅니다. 중요: worktree는 다른 컴퓨터나 완전히 격리된 보안 환경을 뜻하지 않습니다. 연결된 worktree는 Git의 객체·커밋 정보를 공유하고, 같은 외부 데이터베이스나 서비스에 접근할 수도 있습니다.

3. 언제 Worktree를 사용하면 좋을까요?

가장 활용하기 좋은 상황은 다음과 같습니다. 상황 A: 두 AI 채팅을 동시에 진행할 때. 로그인 기능과 디자인 개선을 별도 공간에서 작업합니다. 상황 B: 기존 코드가 작업 중인데 긴급 오류를 수정할 때. 현재 수정하던 파일은 그대로 두고 새로운 폴더에서 버그만 확인합니다. 상황 C: AI가 제안한 변경을 시험해 보고 싶을 때. 현재 정상 동작 중인 폴더를 유지하고 실험용 브랜치를 사용합니다. 상황 D: 새로운 기능을 검토할 때. Worktree에서 수정 결과를 보고 문제가 없다면 리뷰·병합합니다. 반대로 짧은 실습 하나만 진행하고 있고 병렬 작업이 전혀 없다면 꼭 Worktree부터 만들 필요는 없습니다. 기존 브랜치 하나로도 충분할 수 있습니다.

4. 방법 A: Codex 데스크톱 앱에서 Worktree 선택하기

명령어가 어렵다면 Codex 데스크톱 앱에서 작업 공간을 선택하는 방법이 이해하기 쉽습니다. Codex Worktrees 공식 안내는 Git 저장소로 관리되는 프로젝트에서 다음 흐름을 설명합니다. 1단계. Codex를 사용할 프로젝트를 선택합니다. 해당 폴더는 Git 저장소여야 합니다. 2단계. 새 Codex 채팅의 입력 영역 아래에서 Worktree를 선택합니다. 3단계. 작업을 시작할 기준 브랜치를 선택합니다. 예를 들어 기준 프로젝트의 main을 선택할 수 있습니다. 4단계. 채팅 A에 아래처럼 작업 범위를 명확히 지시합니다.

이 프로젝트의 로그인 화면만 개선해 줘.

작업 범위:
- 이메일 입력칸과 로그인 버튼 UI 개선
- 다른 페이지의 디자인은 변경하지 않기
- 변경한 파일 목록과 이유 보고하기
- 동작 검증 방법과 남은 위험 보고하기

현재 작업은 다른 기능 수정과 겹치지 않도록
이 Worktree 안에서만 진행해 줘.
변경 검토 전에는 main에 병합하거나 배포하지 마.

5단계. 다른 Codex 채팅을 열고 별도 Worktree에서 디자인 개선 작업을 진행합니다.

홈페이지 디자인만 개선해 줘.

작업 범위:
- 대표 색상과 버튼 간격 개선
- 로그인 기능의 동작 코드는 수정하지 않기
- 변경 파일 목록과 모바일 확인 항목 보고하기

이 Worktree에서만 작업하고,
main 병합이나 배포는 하지 마.

서로 다른 Worktree에서 작업하면 각 채팅이 자기 작업 폴더를 기준으로 파일을 수정할 수 있습니다. Codex의 관리형 Worktree는 기본적으로 detached HEAD(특정 브랜치에 직접 연결되지 않은 상태)에서 시작할 수 있습니다. 이 용어를 모른다면 “당장 브랜치 이름을 붙이지 않은 임시 작업 상태”라고 이해하면 됩니다. 작업 결과를 계속 보관하려면 공식 안내의 Create branch here를 통해 브랜치를 만들거나, Hand off로 로컬 작업 공간에 가져와 검토할 수 있습니다. 주의: Worktree라는 기능 이름과 일반 ChatGPT의 ‘Work 모드’는 같은 것이 아닙니다. 여기서 다루는 것은 Codex의 Git 작업 폴더 분리 기능입니다.

5. 방법 B: Git 명령어로 Worktree 직접 만들기

개발 도구를 사용해 보려는 독자라면 Git 터미널 명령어도 알아 두면 편리합니다. 이번에는 가상의 프로젝트를 사용합니다. 컴퓨터에 Git이 설치되어 있고, my-project가 Git 저장소이며, main 브랜치가 존재한다고 가정합니다.

1단계 — 먼저 현재 상태 확인

원본 프로젝트 폴더에서 다음 명령을 실행합니다.

git status
git branch --show-current
git worktree list

각 명령의 의미는 다음과 같습니다.

• git status: 아직 커밋하지 않은 변경 사항이 있는지 확인합니다.
• git branch --show-current: 현재 브랜치 이름을 확인합니다.
• git worktree list: 이미 연결된 작업 공간과 브랜치를 확인합니다. 중요: 이미 진행 중인 변경 사항이 있다면 먼저 작업 내용의 의미와 보존 방법을 확인하세요. 미완성 작업을 숨기거나 임의 삭제하기 위한 명령을 함부로 실행하지 않는 편이 좋습니다.

2단계 — 로그인 작업용 폴더 만들기

원본 my-project 폴더에서 다음 명령을 실행한다고 가정합니다.

git worktree add -b feature/login ../my-project-login main

여기서 각 부분이 의미하는 것은 다음과 같습니다.

• git worktree add: 새로운 작업 폴더를 연결합니다.
• -b feature/login: feature/login이라는 새 브랜치를 만듭니다.
• ../my-project-login: 원본 프로젝트 옆에 만들 새 폴더의 경로입니다.
• main: 작업을 시작할 기준 브랜치입니다. 이 명령이 유효한 저장소에서 정상 완료되면, 기존 my-project와 별개로 my-project-login 폴더가 만들어집니다. 같은 이름의 브랜치나 동일한 경로가 이미 있다면 명령이 실패할 수 있습니다. 초보자라면 강제로 덮어쓰는 옵션 대신 기존 worktree 목록과 이름을 먼저 확인하세요.

3단계 — 디자인 작업용 폴더 만들기

두 번째 기능에는 다른 브랜치와 폴더를 사용합니다.

git worktree add -b feature/design ../my-project-design main

그러면 예시는 다음과 같은 구조가 됩니다.

작업 폴더 예시
├─ my-project/          ← 원본 폴더, main
├─ my-project-login/    ← 로그인 수정, feature/login
└─ my-project-design/   ← 디자인 수정, feature/design

4단계 — 작업 폴더 목록 확인

git worktree list

Git은 각 worktree의 경로, 커밋, 브랜치 정보를 보여 줍니다. 현재 브랜치가 다른 worktree에서 이미 체크아웃되어 있다면 같은 브랜치를 두 폴더에서 동시에 사용할 수 없도록 기본적으로 제한합니다. 같은 브랜치를 두 Worktree에서 강제로 사용하지 마세요. 브랜치 충돌을 막는 Git의 기본 보호 장치를 우회하게 됩니다.

6. Codex에게 다른 폴더를 맡길 때 기억할 규칙

Worktree를 둘 만들었다면 채팅이 어느 폴더를 실제 작업 대상으로 사용하는지가 중요합니다. 로그인 작업을 맡는 채팅은 my-project-login을, 디자인 작업을 맡는 채팅은 my-project-design을 사용하도록 지정합니다. 처음 지시할 때 다음처럼 작성하면 실수를 줄일 수 있습니다.

현재 작업 대상 폴더와 브랜치를 먼저 확인해 줘.
내가 승인한 작업 범위만 수정해.

작업 시작 전:
1. 현재 폴더와 브랜치 보고
2. git status로 기존 수정 사항 확인
3. 어떤 파일을 변경할지 간단히 계획 제시

작업 종료 후:
1. 실제 변경 파일 목록과 diff 요약
2. 실행한 <a href="https://www.emfls.com/2026/10/ai-passfail.html">테스트</a>와 실행하지 못한 테스트 구분
3. 남은 오류·위험·검토 사항 설명

다른 Worktree나 main 브랜치에는
사전 승인 없이 변경하거나 병합하지 마.

여기서 “검사한 것”과 “검사하지 못한 것”을 구분하는 문장이 중요합니다. AI가 “완료”라고 답했다고 해서 여러 운영체제와 모바일 화면에서 실제로 정상 동작했다는 뜻은 아닙니다.

7. 별도 Worktree라면 파일 충돌이 완전히 없어질까요?

아닙니다. 작업 중인 폴더가 다르다는 것과 최종 코드 변경사항이 자동으로 합쳐진다는 것은 다릅니다. 예를 들어 채팅 A는 로그인 버튼의 텍스트를 바꾸고, 채팅 B는 같은 버튼에 다른 디자인을 적용할 수 있습니다. 두 수정은 서로 다른 폴더에 안전하게 저장되지만, 나중에 두 브랜치를 하나로 합치면서 같은 코드 구간을 다르게 수정했다면 병합 충돌이 생길 수 있습니다. 또한 다음 항목은 worktree로 분리해도 공유될 수 있습니다.

• 같은 원격 저장소: 두 작업이 같은 원격 브랜치에 임의로 push하면 충돌 가능.
• 같은 데이터베이스: 테스트 중 실제 데이터를 함께 수정할 수 있음.
• 같은 서버 포트: 두 개발 서버가 같은 포트를 사용하면 하나가 실행되지 않을 수 있음.
• 같은 API 키·비용 계정: 각각 호출해도 사용량·비용이 누적될 수 있음.
• 같은 외부 파일·서비스: 작업 폴더 밖의 데이터는 여전히 영향을 주고받을 수 있음. 따라서 worktree는 파일 작업 공간을 분리하는 수단이고, 배포 환경·데이터베이스·권한까지 격리하는 완전한 보안 환경은 아닙니다.

자체 제작 개념도 · EMFLS AI

8. 두 작업이 끝나면 어떻게 하나로 합치나요?

이제 로그인 기능과 디자인 수정을 마쳤다고 가정하겠습니다. 첫째, 각 작업 폴더에서 git status로 수정 사항을 확인합니다. 둘째, 변경된 파일을 검토하고 필요한 테스트를 수행합니다. 예를 들어 로그인 버튼 동작, 디자인의 모바일 화면, 관련 테스트 실행 여부 등을 확인합니다. 셋째, 승인한 변경을 각자의 브랜치와 커밋으로 정리합니다. Codex 관리형 Worktree라면 먼저 브랜치 생성이나 Handoff가 필요할 수 있습니다. 넷째, 원격 저장소에 올릴 준비가 됐다면 별도의 Pull Request(PR)로 검토하는 방식을 사용할 수 있습니다. 다섯째, 리뷰와 자동 검사를 통과한 변경만 main에 차례대로 반영하고, 두 기능을 합친 상태에서 다시 테스트합니다. 단계별로 정리하면 다음과 같습니다.

단계	확인 내용	주의할 점
1. 개별 확인	각 worktree의 파일·브랜치·상태	미완성 변경을 빠뜨리지 않기
2. 개별 테스트	로그인/디자인 기능 검증	실제 미실시 테스트를 통과했다고 쓰지 않기
3. 변경 검토	커밋·diff·PR	비밀키·개인정보가 포함되지 않았는지 확인
4. 병합	충돌 해결 뒤 main 반영	독립 작업의 변경이 서로 양립하는지 확인
5. 통합 검증	두 기능을 함께 실행	각각 성공해도 조합에서 오류 가능

별도 worktree를 만들었다는 사실만으로 main에 변경이 자동 반영되지는 않습니다. 이번 글은 worktree를 안전하게 나누고 관리하는 방법이 목적이므로 PR의 모든 버튼이나 병합 방식은 후속 안내에서 자세히 다룰 수 있습니다.

9. 작업이 끝난 Worktree는 어떻게 정리하나요?

연습이 끝났다고 해서 파일 탐색기에서 관련 폴더를 바로 삭제하지 마세요. 먼저 해당 폴더의 변경 사항을 확인합니다.

git status

수정 내용이 남아 있다면 보관해야 할 파일과 커밋을 먼저 정리하세요. 필요한 변경 사항을 안전하게 보존했는지 확인한 뒤 원본 저장소에서 worktree를 제거합니다.

git worktree list
git worktree remove ../my-project-login

기본적으로 Git은 수정하거나 추적하지 않는 파일이 남은 worktree를 제거하려는 시도를 거부할 수 있습니다. 이는 실수로 작업을 잃지 않도록 돕는 안전장치입니다. 작업이 완전히 정리된 것인지 확신이 없다면 --force를 사용하지 않는 것이 좋습니다. Worktree가 제거된 뒤에도 기능 브랜치를 별도로 삭제할지는 보관 정책과 병합 상태를 확인한 다음 결정해야 합니다. Codex의 관리형 Worktree는 앱이 정리하는 방식과 영구 Worktree가 다를 수 있습니다. 앱에서 제공하는 관리 기능을 우선 확인하세요.

10. Codex Worktree에서 자주 겪는 문제

Q. “This branch is already checked out” 같은 오류가 나요

같은 브랜치가 다른 worktree에서 이미 사용 중일 수 있습니다. git worktree list로 확인하고 새 브랜치를 만들거나 작업을 다른 곳으로 가져오는 방법을 검토하세요. 동일 브랜치를 억지로 중복 체크아웃하지 마세요.

Q. 새 폴더에 .env가 없어요

Git이 무시하는 .env 같은 로컬 설정 파일은 새 worktree에 자동으로 복사되지 않을 수 있습니다. Codex의 로컬 관리형 Worktree에는 .worktreeinclude라는 별도 설정이 있지만, 일반 Git worktree 명령에 자동 적용되는 규칙은 아닙니다. 또한 비밀키 파일을 복사하면 사용 범위가 넓어질 수 있습니다. 회사의 비밀관리 정책을 따르고, 불필요한 키 사본은 만들지 마세요.

Q. 패키지가 설치되지 않았다고 나와요

새 worktree는 별도 프로젝트 파일 폴더입니다. 프로젝트에 따라 필요한 종속성을 그 폴더에 설치해야 할 수 있습니다. 모든 작업에 똑같은 준비가 필요하다고 단정하지 말고 해당 프로젝트의 설정 안내를 확인하세요.

Q. 개발 서버를 두 개 실행했는데 하나가 꺼져요

둘 다 같은 포트 번호를 사용했을 수 있습니다. 프로젝트의 개발 서버 설정을 확인하고 테스트 환경이 서로 간섭하지 않도록 조정하세요.

Q. Worktree를 만들었는데 Codex가 다른 폴더를 수정해요

실제 Codex 채팅이 어떤 작업 폴더에서 시작됐는지 확인해야 합니다. Git 명령으로 폴더를 만들었다고 해서 이미 열린 모든 AI 채팅의 작업 디렉터리가 자동으로 바뀌지는 않습니다.

Q. 두 브랜치의 파일을 합치려는데 충돌이 나요

두 채팅이 같은 영역을 각각 수정했을 가능성이 있습니다. 각 변경을 비교하고 어떤 내용이 최종 사양에 맞는지 사람이 결정해야 합니다. Worktree는 병합 충돌 가능성을 없애 주는 기능이 아닙니다.

11. Codex를 병렬로 사용할 때 추천하는 운영 규칙

두 개 이상의 AI 채팅을 함께 운영한다면 작업을 나누는 규칙이 중요합니다.

• 주제 분리: 로그인/디자인처럼 역할을 분명하게 정합니다.
• 공간 분리: 각각 다른 worktree 또는 관리형 Codex 작업 공간에 연결합니다.
• 범위 제한: 변경을 허용한 파일과 금지한 파일을 지시합니다.
• 작업 기록: 시작 브랜치, 변경 파일, 테스트, PR 번호를 남깁니다.
• 보안 점검: API 키, 개인정보, 배포 권한과 비용을 별도로 관리합니다.
• 통합 검수: 두 작업 결과를 모으기 전에 사람이 diff와 테스트를 확인합니다. 특히 같은 프로젝트에서 AI를 여러 개 실행할 때는 “열심히 작업해 줘”라는 넓은 지시보다 “이 공간에서 이 기능만, 검증 후 보고”처럼 작업 단위를 줄이는 것이 유리합니다. 중요한 원칙 하나를 기억하세요. 작업을 분리할수록 더 쉽게 병렬로 진행할 수 있지만, 최종 품질은 합치는 과정에서 결정됩니다.

자주 묻는 질문(FAQ)

Q1. Git worktree는 Git clone과 같은가요?

아닙니다. clone은 다른 저장소 복제본을 만들고, worktree는 기존 저장소에 연결된 추가 작업 폴더를 마련하는 방식입니다.

Q2. Codex를 사용하면 worktree를 직접 만들 필요가 없나요?

데스크톱 앱의 Codex Worktree 기능을 사용하면 앱이 관리형 작업 공간을 만들어 줄 수 있습니다. 다만 CLI·Git 명령으로 직접 관리하는 방식도 있어 사용 환경에 맞게 선택하면 됩니다.

Q3. Codex Worktree와 ChatGPT Work 모드는 같나요?

아닙니다. 이 글의 Worktree는 Git 파일 작업 공간을 분리하는 기능이며, ChatGPT에서 긴 업무를 위임하는 Work 모드와 구분됩니다.

Q4. 두 worktree에서 같은 브랜치를 사용할 수 있나요?

Git은 일반적으로 같은 브랜치의 동시 체크아웃을 차단합니다. 각 작업마다 다른 브랜치를 사용하거나 별도 detached HEAD 상태를 활용해야 합니다.

Q5. worktree를 나누면 서로의 코드가 완전히 보이지 않나요?

그렇게 단정할 수 없습니다. Git 기록을 공유하고 같은 컴퓨터에서 운영될 수 있습니다. 개인정보 격리나 보안 샌드박스와는 다른 개념입니다.

Q6. 다른 채팅의 수정 내용이 main에 자동으로 들어가나요?

아닙니다. 별도 브랜치나 작업 공간의 변경을 검토한 뒤 커밋·병합해야 합니다.

Q7. 같은 파일을 두 worktree에서 수정하면 안전한가요?

작업 중 각자의 폴더 파일을 직접 덮어쓰는 위험은 줄어듭니다. 하지만 나중에 브랜치를 병합하면서 충돌이 생길 수 있습니다.

Q8. worktree를 삭제하면 브랜치도 사라지나요?

일반 Git의 git worktree remove는 연결 작업 폴더를 제거하는 명령입니다. 브랜치 정리는 별도 판단 대상입니다. Codex 관리형 Worktree는 앱의 정리 정책이 따로 있을 수 있습니다.

Q9. 이미 커밋하지 않은 변경이 있어도 만들 수 있나요?

상황에 따라 가능하지만, 먼저 현재 작업이 어떤 상태인지 확인하세요. 새 작업 공간에 기존 변경이 어떻게 반영되는지는 일반 Git 명령과 Codex 관리형 Worktree에서 다를 수 있습니다.

Q10. Worktree를 사용하면 GitHub PR이 없어도 되나요?

반드시 PR이 필요한 것은 아니지만, 팀 협업이나 배포를 앞둔 코드라면 리뷰와 자동 테스트가 중요합니다. Worktree는 개발 공간, PR은 변경을 검토·통합하는 절차입니다.

마무리: AI 두 개보다 중요한 것은 작업 공간 두 개입니다

여러 AI 채팅을 동시에 사용하는 일이 많아질수록 서로의 파일을 건드리지 않게 만드는 구조가 필요합니다. 처음에는 Git 프로젝트 하나에 로그인 작업용 Worktree와 디자인 작업용 Worktree를 따로 마련하는 흐름부터 익혀 보세요. ① 현재 Git 상태 확인 → ② 작업별 별도 폴더와 브랜치 생성 → ③ 채팅마다 작업 범위 지정 → ④ 변경·테스트 확인 → ⑤ 검토 후 통합 → ⑥ 안전하게 Worktree 정리. 이 방법은 모든 충돌을 없애지는 못하지만, 어느 AI가 어떤 변경을 했는지 구분하고 실수를 조기에 발견할 수 있도록 돕는 기본 구조가 됩니다. 실제 프로젝트에서는 작업 시작 전 상태 확인과 최종 병합 검수를 반드시 수행하세요.

공식 참고 자료

• Git 공식 git-worktree 안내
• Codex Worktrees 공식 안내
• Codex 환경 선택 공식 안내

함께 읽으면 좋은 글

• 코덱스(Codex)란? — Codex가 프로젝트 파일을 다루는 기본 개념
• 코드란 무엇일까? — 코드와 HTML·CSS·JavaScript의 기본 개념