작업 환경 갖추기

“발행물은 여기, 임시 산출물은 저기, 원본은 건드리지 않는다”는 위치 규칙을 먼저 정합니다. 규칙이 없으면 매번 위치를 새로 지정해야 하고, 나중에 어디 있는지 찾는 것도 일이 됩니다.

SSoT(Single Source of Truth, 단일 진실 출처)를 정해 두는 이유도 같습니다.

• 같은 정보가 여러 파일에 흩어져 있으면 어느 쪽이 최신인지 매번 확인해야 합니다.
• 정본 파일 하나를 정하고 나머지는 그 파일을 가리키게 합니다.

마케터가 캠페인 자료를 만들 때 발행본과 초안이 같은 폴더에 섞여 있으면, 어느 파일이 최종본인지 매번 물어봐야 합니다.

• “최종”, “진짜최종”, “최종_수정2”처럼 파일명으로 버전을 구분하는 방식은 피합니다.
• 발행 폴더와 초안 폴더를 나누고 발행 폴더에 있는 것만 정본으로 취급하면, 파일명에 기대지 않아도 됩니다.
• 공개 범위도 구조에 포함됩니다. 외부에 나가도 되는 폴더와 내부용 폴더를 나눠 두면, 발행 작업을 맡길 때 비공개 자료가 실수로 섞여 나가는 일을 줄일 수 있습니다.

순서의 각 단계 아래 붙여넣기 예제가 있습니다. 위에서부터 하나씩 실행해 보세요.

파일이 직접 바뀌는 만큼, 무엇이 어떻게 달라졌는지 확인할 방법이 없으면 결과가 마음에 안 들어도 되돌리기 어렵습니다. Git이 그 방법입니다.

branch(작업 갈래)를 나눠 두면 실험적인 요청과 완성된 작업을 분리할 수 있습니다.

• 새 작업을 시작할 때 branch를 하나 만들고, 그 안에서 Claude에게 작업을 맡깁니다.
• 결과를 그대로 받아들이기 전에 diff(변경 내역 화면)를 봅니다.
• 어떤 줄이 지워지고 어떤 줄이 추가됐는지 보면, 의도와 다르게 바뀐 부분을 commit(기록) 전에 잡을 수 있습니다.

기획서 여러 장을 한 번에 고쳐 달라고 맡긴 뒤 diff를 보지 않고 그대로 commit하는 것은 피해야 할 습관입니다. 의도와 다르게 지워진 문단이 나중에야 발견됩니다.

• 뉴스레터 문구를 수정할 때도 마찬가지로, commit 전에 “무엇이 바뀌었는지 보여줘”라고 요청해 diff를 확인하면 커밋 전에 실수를 잡을 수 있습니다.
• commit은 확인이 끝난 상태를 기록하는 지점입니다. 문제가 있으면 commit 이전으로 되돌릴 수 있으므로, 큰 작업을 맡기기 전에 commit해 두면 안전망이 생깁니다.

순서의 각 단계 아래 붙여넣기 예제가 있습니다. 위에서부터 하나씩 실행해 보세요.

세 단어는 커밋 → 푸시와 브랜치 → 머지라는 두 흐름으로 이어집니다. 첫 저장에서는 커밋한 뒤 푸시하고, 나중에 작업을 따로 나누었을 때 머지를 사용합니다.

• 커밋(commit) — 블록 집을 사진으로 남기고 “여기까지 만들었습니다”라고 메모하는 것과 같습니다. 실제로는 지금까지 바꾼 파일을 내 컴퓨터에 기록 하나로 남깁니다.

아래 그림에서는 확인한 문서에 도장을 찍어 기록을 남깁니다.

• 푸시(push) — 사진첩을 인터넷 보관함에 올리는 것과 같습니다. 실제로는 내 컴퓨터의 커밋을 GitHub 저장소로 보냅니다. 커밋만 하고 푸시하지 않으면 GitHub 웹에는 아직 보이지 않습니다.

• 머지(merge) — 다른 책상에서 만든 창문을 완성할 블록 집에 붙이는 것과 같습니다. 실제로는 다른 브랜치에서 만든 변경을 main에 합칩니다.

아래 그림에서는 따로 만든 작업을 최종본에 합칩니다.

다음에 만나는 네 단어

• 브랜치(branch) — 변경 기록을 나눠 진행할 때 붙이는 이름입니다. 시안 복사본을 하나 더 만들어 실험하는 것과 비슷하게 사용할 수 있습니다.

아래 그림에서는 최종본을 그대로 둔 채 브랜치에서 실험합니다.

• main — 프로젝트가 기본으로 사용하는 브랜치 이름입니다. 확인을 마친 변경을 모으는 방식으로 운영할 수 있지만, Git이 완성본으로 정해 놓은 이름은 아닙니다.
• origin — 원격 저장소 주소에 붙이는 이름입니다. 흔히 GitHub 주소를 가리키지만 다른 서버도 가리킬 수 있습니다.
• 워크트리(worktree) — 같은 Git 저장소에 연결된 별도 작업 폴더입니다. 두 작업을 동시에 진행할 때 파일이 섞이지 않게 도와줍니다.

아래 그림에서는 두 작업을 다른 폴더에 나란히 펼칩니다.

Codex나 Claude Code에는 “지금까지를 기록해 줘”, “GitHub에 올려 줘”, “따로 만든 작업을 main에 합쳐 줘”라고 말해도 됩니다. 작업이 끝난 뒤에는 커밋, 푸시, 머지 가운데 무엇을 했는지 확인합니다.

GitHub는 프로젝트 파일과 변경 기록을 함께 보관합니다. 계정이 없다면 GitHub 계정과 첫 저장소 만들기를 먼저 열고 가입을 마칩니다. 첫 저장에서는 웹에서 빈 비공개 저장소를 먼저 만들고, 올릴 파일과 제외할 파일을 확인합니다.

저장 전에 공개하면 안 되는 파일을 확인합니다

비밀번호, 토큰, API 키, .env 파일, 고객·직원 개인정보는 비공개 저장소에도 올리지 않습니다. GitHub가 비밀 값을 감지해 푸시를 막으면 차단을 넘기지 않고 파일에서 값을 제거합니다.

웹에서 파일과 커밋을 함께 확인합니다

명령이 성공했다는 답만으로 저장을 끝내지 않습니다. GitHub의 Code 화면에서 저장소 이름, main 브랜치, 최근 커밋, 프로젝트 파일을 확인합니다. 네 항목이 보이면 내 컴퓨터의 기록이 GitHub에도 올라간 상태입니다.

GitHub 저장소 주소는 파일을 보는 주소입니다. 완성한 사이트를 방문자에게 보여 주려면 빌드와 배포가 별도로 필요합니다.

Claude Code는 로컬 파일만 다루지 않습니다. Notion, Slack, 데이터베이스처럼 파일 시스템 밖에 있는 데이터를 매번 복사해 옮기면 서식이 깨지거나 최신 값을 놓치기 쉽습니다.

MCP는 Claude Code가 외부 서비스와 대화하는 표준 통로입니다. 추천 목록에 나온 MCP를 모두 연결할 필요는 없으며, 선택 기준은 스킬·플러그인·MCP 구분 카드에서 확인할 수 있습니다.

이 카드에서는 Notion 공식 MCP 하나만 연결하고 지정한 페이지를 수정하지 않은 채 읽어 봅니다. 연결 목록에 이름이 보이는 것만으로 끝내지 않고 실제 페이지 조회와 공유 범위를 함께 확인합니다.

• 설정 파일을 직접 만질 필요는 없습니다. “Notion 연결해 줘” 같은 요청으로 설치와 인증 과정을 Claude Code에게 맡길 수 있습니다.
• 연결이 끝나면 Notion 페이지 검색·조회·작성 같은 요청을 문장으로 할 수 있습니다.

기본 연결은 지금 열어 둔 폴더(프로젝트) 단위로 저장됩니다.

• 같은 도구를 다른 폴더에서도 쓰려면 그 폴더에서 다시 연결해야 합니다.
• 모든 폴더에서 공용으로 쓰고 싶으면 “이 연결을 모든 프로젝트에서 쓸 수 있게 해 줘”라고 요청하면 되고 이 경우 새 폴더를 열 때마다 다시 연결하지 않아도 됩니다.

순서 아래 실행 요청을 그대로 붙여넣어 지금 연결된 외부 도구부터 확인해 보세요.

이미지나 영상 생성이 필요한 사람은 이 실습을 마친 뒤 Higgsfield 연결 카드로 이어갑니다. 그 연결은 생성 전에 잔여 크레딧과 한 건의 예상 비용부터 확인합니다.

서브에이전트는 별도 맥락에서 작업하고 결과만 본 대화로 돌려주는 워커입니다. “서브에이전트로 조사해 줘”처럼 요청하면 Claude가 워커를 골라 위임합니다.

본 대화에서 직접 조사하면 중간 결과와 읽고 안 쓴 파일이 그대로 쌓입니다. 맥락이 무거워지면 이후 요청에서 처음 규칙을 놓칩니다.

• 파일 여러 개를 뒤지거나 같은 조사를 반복할 때 씁니다.
• 한두 줄로 끝나는 질문은 직접 답하는 게 빠릅니다.
• 위임한 작업은 끝나거나 막히면 스스로 보고합니다.

범위 밖의 일은 칩으로 떼어 두기

칩(chip)은 지금 범위 밖의 일을 별도 세션으로 미뤄 두는 방법입니다. “이건 새 칩으로 띄워 줘”라고 요청하면 화면에 칩이 생기고, 누르면 그 일만 다루는 세션이 열립니다. 지금 대화는 그대로 이어집니다.

아래 요청문을 복사해 붙여넣고 조사 하나를 서브에이전트에 맡깁니다.