MCP·스킬 + 브랜드 컨텍스트

• 프로젝트 폴더를 Claude Code 또는 Codex에서 열고, 필요한 자료를 첨부한 뒤 요청문 옆 복사 버튼을 누릅니다

• 대괄호가 있는 요청은 내 내용으로 바꿔 붙여넣습니다

• 답변을 받은 뒤 안내된 파일이나 화면을 직접 확인합니다

• project-brief.md에서 정할 다섯 가지(이후 brand.md·workflow.md로 갈라지는 개인화 작업의 출발점):

• 만들 결과물

• 사용할 사람

• 현재 가진 자료

• 완료 기준

• 하지 않을 일

• 파일은 직접 채우지 않습니다:

• Claude Code에게 한 번에 한 질문씩 묻게 합니다. 순서대로 답만 하면 브리프가 완성됩니다.

• 답이 모호하면 예시 3개를 보여 달라고 요청해 그중에서 고릅니다.

• 완료 기준은 확인 가능한 문장으로 적습니다:

• 애매한 기준 — “결과물이 좋아 보인다”

• 확인 가능한 기준 — “A4 한 장, 고객 3유형, 금지 표현 5개가 들어간다”

• 확인할 수 없는 기준은 나중에 결과물을 두고 다시 논쟁하게 됩니다

• 실습: 아래 요청문을 복사해 붙여넣고 project-brief.md 인터뷰를 시작합니다

• 순서: project-brief.md 다음 단계
• brand.md의 다섯 질문
  • 대상 고객
  • 지금 겪는 문제
  • 남기고 싶은 인상
  • 자주 쓸 말과 쓰지 않을 말
  • 참고할 브랜드
• 파일은 직접 채우지 않습니다
  • project-brief.md를 먼저 읽게 하고, 다섯 항목을 한 번에 한 질문씩 물어보게 합니다.
  • 답이 끝나면 사실, 결정, 아직 모르는 것을 구분해서 정리해 달라고 요청합니다.
• 색과 폰트처럼 아직 정하지 않은 항목은 추측으로 채우지 않습니다
  • “미정”으로 남겨 두고, 다음 시각 탐색 단계에서 다시 결정합니다.
  • 모르는 것을 안다고 적어 두면 이후 모든 요청이 그 위에서 어긋납니다.

• 두 파일의 역할
  • design.md — 색·폰트·여백 같은 화면 규칙
  • image.md — 이미지에서 고정할 요소와 바꿔도 되는 요소
• 파일은 직접 채우지 않습니다
  • 기존 결과물과 참고 이미지를 먼저 보여주고, 한 번에 한 질문씩 인터뷰를 받습니다.
  • “감성적”, “세련된” 같은 형용사는 그대로 두지 않고 HEX 값, 폰트 이름, px처럼 관찰 가능한 값으로 바꿉니다. 형용사는 사람마다 다르게 읽지만 값은 누가 읽어도 같습니다.
• image.md의 두 갈래
  • 매번 유지할 요소 — 피사체, 구도, 광원, 팔레트
  • 바꿔도 되는 요소 — 장면, 소품
• 이 구분이 있어야 이미지를 여러 장 만들어도 같은 브랜드로 보입니다

다른 AI 도구에서도 같은 디자인 기준 사용하기

• DESIGN.md: 색·글꼴·여백 같은 디자인 규칙과 그 규칙을 쓰는 이유를 적는 문서 파일
• Google: 2026년 4월 21일 Stitch의 DESIGN.md 작성 규격 초안 공개
• 공식 규격 구성: 정확한 값을 적는 부분 + 적용 방법을 설명하는 본문
• 이 카드의 design.md는 같은 목적의 학습용 문서이며, Google 규격을 그대로 따르는지는 별도로 확인해야 합니다
• 이미 쓰는 파일이 있다면 그 이름을 유지하고, 대소문자만 다른 파일을 추가로 만들지 않습니다

기존 자료에서 기준 정리하기

• 브랜드 안내서나 기존 화면을 AI에 보여 주고 아래 요청문을 붙여넣습니다
• 웹사이트를 읽을 수 없는 도구: 화면 이미지나 파일을 첨부합니다
• 사진만 보고 글꼴·색을 확정하지 않도록, 확인된 값과 미정인 항목을 나눕니다

제가 제공한 브랜드 안내서, 기존 화면과 현재 폴더의 디자인 문서를 읽어 주세요. 이미 design.md 또는 DESIGN.md가 있다면 그 파일부터 확인해 주세요.

배경·본문·강조 색, 제목·본문 글꼴, 여백과 화면 폭을 정리하고 각 항목에 확인한 파일 또는 페이지를 적어 주세요. 각 색과 글꼴을 어디에 쓰는지도 설명해 주세요. 자료만으로 알 수 없는 값은 미정으로 남기고, 기존 기준과 충돌하는 항목은 제게 한 가지씩 질문해 주세요.

확인한 뒤 기존 디자인 문서에 추가할 내용을 보여 주세요. 파일이 없다면 design.md 초안을 작성해 주세요. 저장할 수 없는 도구라면 제가 내려받거나 복사해 저장할 수 있도록 문서 전문을 보여 주세요.

운영 중인 웹사이트에서 초안 받기

• 웹사이트가 이미 있다면 사이트 주소를 넣어 색·글꼴·간격을 읽어 오는 서비스로 DESIGN.md 초안을 먼저 받을 수 있습니다
• designmd.me: 주소를 넣으면 DESIGN.md와 HTML 미리보기를 만듭니다
  • 가격: 무료 크레딧은 한 번 생성할 만큼, 그 뒤로는 유료
• DESIGNMD by Hyperbrowser: Google 규격에 맞춘 파일을 뽑아 줍니다
  • 조건: Hyperbrowser API 키 필요
• 같은 종류의 서비스: 참고 사이트의 디자인 시스템 분류
• 받은 초안은 화면에서 읽어 낸 값이라 브랜드가 정한 값과 다를 수 있습니다
• 초안과 브랜드 안내서를 함께 첨부하고 아래 요청문으로 값을 대조한 뒤 기준 문서로 씁니다

첨부한 DESIGN.md는 우리 웹사이트 주소를 넣어 자동으로 뽑은 초안입니다. 함께 첨부한 브랜드 안내서와 비교해 색·글꼴·여백 값을 일치하는 항목, 다른 항목, 안내서에 없는 항목으로 나눠 표로 보여 주세요. 다른 항목은 어느 쪽 값을 따를지 제게 한 가지씩 질문하고, 답을 반영한 design.md 초안을 보여 주세요.

새 대화에서 읽었는지 확인하기

• 새 대화나 다른 AI 도구: 파일을 첨부하거나 파일이 있는 폴더를 연결합니다
• 아래 요청문으로 읽은 내용을 확인합니다
• 저장해 둔 것만으로 모든 도구가 자동으로 읽거나 이후 대화까지 기억한다고 가정하지 않습니다

첨부한 design.md 또는 현재 작업 폴더의 디자인 문서를 먼저 읽어 주세요. 실제로 읽은 파일 이름과 배경색, 본문 글꼴, 여백 기준을 요약하고 아직 미정인 항목도 알려 주세요. 파일이 보이지 않으면 추측하지 말고 필요한 파일을 요청해 주세요. 아직 화면이나 이미지는 만들지 마세요.

• AI가 답한 값과 문서의 값이 일치하는지 대조합니다
• 이후 결과물을 만들 때도 같은 문서를 함께 전달합니다
• 완성한 화면에서 색·글꼴·여백이 기준과 맞는지 확인합니다

공식 설명

• Google Labs의 DESIGN.md 공개 안내
• Google의 DESIGN.md 규격과 예제

• 클로드 디자인: claude.ai/design에서 열리는 디자인 도구
• 프롬프트를 넣으면 카드뉴스, 슬라이드, 웹 화면 시안을 만들어 줍니다
• Claude Code와의 역할 차이
  • Claude Code — 폴더에서 파일을 직접 만들고 고칩니다.
  • 클로드 디자인 — 결과 화면을 눈으로 보면서 고칩니다.
• 시안을 만들기 전에 기준을 먼저 넣습니다
  • design.md를 첨부하면, 클로드 디자인이 그 색·폰트·여백에 맞춰 화면을 만듭니다.
  • 피그마 디자인 시스템이 있으면 .fig 파일로 등록해 둘 수도 있습니다.
  • 기준 없이 “만들어 줘”라고만 하면 어디서 본 듯한 평균적인 화면이 나옵니다. design.md로 잡아 둔 기준이 여기서 그대로 쓰입니다.
• 시안은 3가지 방향으로 받아 나란히 놓고 고른 다음, 채팅으로 색·문구·배치를 고칩니다
• 조건: Pro 이상 구독. 무료 계정에서는 화면이 나타나지 않습니다
• 첫 시안: 순서 아래 요청을 claude.ai/design 입력창에 붙여넣습니다

• voice.md와 swipe.md의 역할:

• voice.md — 어미·어휘·금지 표현 같은 규칙

• swipe.md — 승인된 실제 문장을 출처와 함께 쌓는 기록

• 파일은 직접 채우지 않습니다:

• 최근 실제로 발행한 글과 마음에 드는 문장을 먼저 보여주고, 한 번에 한 질문씩 인터뷰를 받습니다.

• 규칙은 실제 문장과 짝을 이룰 때 작동하므로, 승인 예시와 거절 예시를 함께 넣습니다.

• swipe.md는 발행할 때마다 좋은 문장을 한 줄씩 쌓는 파일입니다:

• 출처를 모르는 외부 문장은 인용하지 않습니다.

• 확인되지 않은 수치와 성과는 쓰지 않습니다.

• 실습: 아래 요청문을 복사해 붙여넣고 voice.md 인터뷰를 시작합니다

• workflow.md는 project-brief.md 다음에 만듭니다

• 실제 업무 흐름을 정리하는 다섯 항목:

• 입력 — 일이 시작될 때 들어오는 자료

• 판단 — 사람이 결정해야 하는 기준

• 실행 — 반복해서 하는 단계

• 출력 — 마지막에 나와야 하는 결과

• 예외 — 자동으로 처리하면 안 되는 경우

• project-brief.md를 먼저 읽게 하고, 실제로 하는 일을 인터뷰하게 합니다

• 다섯 항목을 한 번에 한 질문씩 구분해서 묻게 합니다

• 결제, 발송, 삭제, 공개처럼 되돌리기 어려운 단계는 자동 실행 대상으로 두지 않습니다. 먼저 사람이 확인하는 승인 지점으로 표시해 둡니다.

• 마지막에는 현재 흐름과 개선 후보를 분리해서 정리합니다. 지금 하는 일과 나중에 자동화할 일이 섞이지 않습니다.

• 실습: 아래 요청문을 복사해 붙여넣고 workflow.md 인터뷰를 시작합니다

• 매번 “이모지 빼고, 존댓말로” 같은 규칙을 다시 적으면 요청이 길어지고, 빠뜨린 요청만 규칙에서 벗어난 결과가 나옵니다

• CLAUDE.md: 세션이 시작될 때 자동으로 읽히는 규칙 파일

• 폴더 구조, 금지 사항, 톤, 자주 쓰는 명령어처럼 매번 설명하던 내용을 적어 둡니다. 이후 요청에서는 생략할 수 있습니다.

• 빈 프로젝트라면 /init을 실행해 코드와 문서를 분석한 초안을 먼저 받습니다.

• 파일은 두 층입니다

  • 프로젝트 루트의 CLAUDE.md — 그 프로젝트에서 함께 일하는 사람과 공유하는 규칙
  • 사용자 홈 폴더의 ~/.claude/CLAUDE.md — 어떤 프로젝트를 열어도 항상 적용되는 개인 규칙

• 같은 내용이 두 파일에 있으면 프로젝트 파일이 우선 적용됩니다

• 규칙은 쌓기보다 관리합니다

  • 온갖 규칙을 한 파일에 계속 이어 붙이면 필요한 기준을 찾기 어려워집니다.
  • 안 쓰는 규칙은 지우고, 자주 어기는 규칙은 눈에 잘 띄는 위치로 옮깁니다.

• /context: 현재 세션이 불러온 CLAUDE.md 파일 확인

• /memory: 메모리 파일 위치를 열어 관리

• CLAUDE.md의 문장은 판단에 참고할 규칙입니다

• 특정 단어가 있는 파일 저장을 반드시 막으려면 Hooks — 자동 검수에서 PreToolUse Hook으로 같은 조건을 검사합니다

• 붙여넣기 예제: 순서의 각 단계 아래. 위에서부터 하나씩 실행합니다

• 여러 날에 걸친 프로젝트에서는 지난번에 정한 값이 어디에도 안 남는 일이 생깁니다
• 대화는 끝나면 사라집니다
• 기획서에는 정하기 전의 값이 그대로 적혀 있습니다

무엇을 적나요

• 한 항목에 네 칸

• 버린 안을 적어 두면 몇 주 뒤 같은 안이 다시 올라와도, 안 쓰기로 한 이유가 남아 있어 다시 검토하지 않습니다

새 항목은 맨 위에

• 파일 끝에 붙이면 최신을 보려고 매번 끝까지 내려가야 합니다
• 맨 위에 넣으면 파일을 여는 순간 최신이 보입니다

기획서와 다를 때

• 기획서·제안서·초안은 그 시점의 스냅샷입니다
• 값이 바뀌어도 문서는 자동으로 고쳐지지 않으므로, 원장과 다르면 원장을 따릅니다
• 밀려난 문서는 지우지 않고 머리에 한 줄 붙입니다

> 폐기 2026-08-13: 색 기준은 decisions.md 최신 항목을 따릅니다.

• 지우지 않는 이유: 그때 그렇게 정한 까닭이 남아 있으면 다음 결정이 쉬워집니다

요청할 때 같이 붙입니다

• 색 고르기, 문구 쓰기, 화면 구조 만들기 전에 원장을 같이 읽게 합니다
• CLAUDE.md에 “시각·문구 작업 전 decisions.md 최신 항목을 먼저 읽는다”를 한 줄 넣으면 매번 말하지 않아도 됩니다

확정은 내가 합니다

• AI가 대화 중에 스스로 확정이라고 적지 않게 합니다
• 원장에 들어가는 것은 내가 정한 것뿐입니다
• 후보 뽑기와 후보를 확정으로 올리기는 다른 단계입니다

• research-brief.md는 project-brief.md 다음에 만듭니다

• 조사 기준 다섯 항목: 질문, 출처, 최신성, 범위, 형식

• project-brief.md를 먼저 읽게 하고, 알아내야 하는 것을 인터뷰하게 합니다

• 한 번에 한 질문씩 구분해서 물을 항목:

• 이 조사로 답하려는 질문

• 인정할 출처와 인정하지 않을 출처

• 언제 이후 자료만 쓸지

• 조사에서 뺄 범위

• 결과를 어떻게 정리해 받을지

• 출처 기준은 조사 주제마다 다릅니다:

• 공식 발표와 원문만 쓸지, 업계 기사까지 인정할지, 커뮤니티 글은 참고로만 둘지 미리 정해 두면 결과를 받아 놓고 다시 걸러 내지 않아도 됩니다.

• 기준 날짜도 함께 정합니다. 날짜를 정하지 않으면 몇 해 전 자료가 지금 상황처럼 섞여 들어옵니다.

• 가장 자주 어긋나는 곳: 수치와 인용. 출처가 없어도 문장은 그럴듯하게 채워집니다

• 수치와 인용에는 링크를 함께 달게 하고, 몇 개는 직접 열어 확인합니다

• 찾지 못한 항목은 사실로 적지 않고 확인하지 못한 것으로 따로 빼 둡니다

• 실습: 아래 요청문을 복사해 붙여넣고 research-brief.md 인터뷰를 시작합니다

AI 뉴스를 수업이나 뉴스레터로 정리할 때

• 소셜 게시물에서 소재를 찾았다면 공식 발표로 이동해 기능·이용 조건·발표일을 확인합니다
• 발표 당시 날짜와 내가 확인한 날짜를 함께 적습니다
• 업체가 제시한 최대 효과를 내 작업의 실측 결과로 쓰지 않습니다

이 뉴스 링크를 검토해 주세요: [링크]
공식 원출처, 발표일, 확인일, 확인한 사실, 이용 조건, 아직 모르는 점을 나눠 적어 주세요.
내 작업은 [업무 한 개]입니다. 시험할 행동 하나와 결과를 확인할 방법을 제안해 주세요.
기존 수업과 겹치면 보강 위치를 알려 주세요. 원출처를 못 찾은 수치는 발행 초안에서 제외해 주세요.
문서 작성까지만 진행하고 설치·결제·반복 수집·실제 발송은 하지 마세요.

• 뉴스레터 초안에 담을 것: 짧은 설명, 공식 출처, 내 작업에서 해볼 일, 연결할 학습 자료
• 강사가 사실과 링크를 확인한 뒤 발송 대상으로 넘깁니다

GPT-6 Astra로 공개 페이지 조사하기

• 2026년 9월 6일 확인한 OpenAI 발표: Astra의 브라우저·프로그램 조작 기능과 순차 제공 안내

• 모델 이름만 선택했다고 화면 조작 도구까지 연결되지는 않습니다

• 사용하는 앱에서 모델 접근 권한과 브라우저 도구의 연결 상태를 확인합니다

• 실습 내용: 공개 상품 페이지를 읽고 비교표 만들기

• 완료 기준: 표를 완성한 뒤 출처를 다시 열어 숫자와 문구를 대조

• 제외: 실제 상품 구매, 페이지 수정

1. 대상과 읽을 범위를 정합니다

• 준비: 로그인 없이 볼 수 있는 상품 페이지 세 개, 조사 기준 문서
• 기록할 값: 상품명, 표시 가격, 가격의 단위, 출처 주소. 배송비처럼 별도로 표시된 금액은 나눠 적습니다
• 화면 조작을 쓸 수 없으면 직접 읽은 문구와 화면 이미지를 전달해 자료 정리만 연습합니다

2. 읽기와 표 작성을 요청합니다

• 아래 주소 세 곳을 실제 페이지 주소로 바꿉니다
• 조사 기준 문서가 있으면 함께 첨부합니다

다음 공개 상품 페이지 세 곳을 조사해 주세요.
[주소 1]
[주소 2]
[주소 3]

첨부한 조사 기준 문서를 먼저 읽고 조사 범위를 요약해 주세요.
연결된 브라우저를 사용할 수 있는지 확인한 뒤 시작해 주세요.
읽기와 링크 이동만 허용합니다. 로그인, 수정, 제출, 구매, 메시지 발송은 하지 마세요.

상품명, 표시 가격, 통화와 판매 단위, 별도 비용, 근거 문구, 출처 주소를 표로 정리해 주세요.
실제로 연 페이지와 확인 날짜를 남기고, 열지 못한 페이지나 보이지 않는 값은 미확인으로 표시해 주세요.
가격을 추측하거나 서로 다른 용량의 상품을 같은 조건처럼 비교하지 마세요.

3. 출처를 다시 열어 결과를 확인합니다

• 표의 세 출처를 직접 열어 상품명·가격·단위를 대조합니다

• 틀린 값이 있으면 해당 행과 원문을 함께 전달해 수정합니다

• 확인하지 못한 항목은 빈칸 대신 이유를 남깁니다

• 비교표를 디자인할 때는 비주얼 기준 문서 카드에서 만든 파일을 첨부합니다

• 아래 요청은 원문 확인이 끝난 뒤 사용합니다

확인한 비교표와 첨부한 디자인 문서를 읽어 주세요.
배경색, 본문 글꼴, 여백 기준과 아직 미정인 값을 먼저 요약해 주세요.
확인한 상품 정보와 출처를 유지한 비교 문서 초안을 만들어 주세요.
새로운 가격이나 근거 없는 순위를 추가하지 마세요.

• 적용 예: 기획자는 경쟁사 상품 비교, 마케터는 공개 행사 안내의 조건 정리, 디자이너는 참고 화면의 문구와 링크 확인
• 결과에 남길 것: 사용한 도구, 확인한 페이지, 미확인 항목, 직접 대조한 결과
• 화면 조작 없이 첨부 자료만 읽었다면 그 방법을 그대로 적습니다

뉴스와 함께 읽습니다

• 한국어 Astra 활용 사례: 소재를 찾는 참고 자료
• 계정별 이용 조건: 공식 발표에서 확인
• 이 실습은 학습용 절차이며, 특정 계정에서 실행한 성능이나 시간 절감 결과를 뜻하지 않습니다

• 브랜드 기준값 파일(brand.json): 콘텐츠 생성기가 읽는 브랜드의 값 목록
• 들어가는 값: 색 코드, 글꼴 이름, 제품 사실, 쓸 수 있는 주장과 쓰지 않을 주장
• 출처 대장(sources.md): 그 값을 어디서 언제 확인했는지

• 조사 기준: 직접 연 페이지
• 검색 결과 요약에서 가져온 값은 직접 확인한 값과 구분해 적습니다
• 의료·효능처럼 근거 없이 쓰면 문제가 되는 주장은 쓰지 않을 주장으로 따로 적습니다
• 이후 채널별 문구 검사가 그 목록을 그대로 씁니다

• 위치 규칙을 먼저 정합니다. 예: “발행물은 여기, 임시 산출물은 저기, 원본은 건드리지 않는다”

• 규칙이 없으면 매번 위치를 새로 지정해야 하고, 나중에 찾는 것도 일이 됩니다

• 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에도 올라간 상태입니다
• 저장소 주소는 파일을 보는 주소입니다. 방문자에게 사이트를 보여 주려면 빌드와 배포가 별도로 필요합니다

• MCP(Model Context Protocol): Claude가 Notion·Slack 같은 다른 서비스의 자료를 복사·붙여넣기 없이 직접 읽고 쓰게 해 주는 연결 규격
• 연결 후에는 “Notion의 회의록 페이지를 읽고 요약해 줘”처럼 문장으로 요청합니다
• Claude는 내 계정 권한으로 접근하므로, 연결할 때 어떤 페이지까지 공유할지 함께 정합니다

• Claude 웹·데스크탑 앱의 챗과 코워크에서는 같은 연결을 커넥터라고 부릅니다. 추가 위치: Customize > Connectors

• 이 카드는 Claude Code에서 연결하는 순서를 다룹니다

• MCP: Claude Code가 외부 서비스와 대화하는 표준 통로

• 추천 목록의 MCP를 모두 연결할 필요는 없습니다. 선택 기준: 스킬·플러그인·MCP 구분 카드

• 이 카드의 범위: Notion 공식 MCP 하나를 연결하고 지정한 페이지를 수정하지 않은 채 읽기

• 연결 목록에 이름이 보이는 것으로 끝내지 않고 실제 페이지 조회와 공유 범위를 함께 확인합니다

• 설정 파일을 직접 만질 필요는 없습니다. “Notion 연결해 줘” 같은 요청으로 설치와 인증 과정을 Claude Code에게 맡길 수 있습니다.

• 연결이 끝나면 Notion 페이지 검색·조회·작성 같은 요청을 문장으로 할 수 있습니다.

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

• 같은 도구를 다른 폴더에서도 쓰려면 그 폴더에서 다시 연결해야 합니다.

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

• 실습: 순서 아래 실행 요청을 붙여넣어 지금 연결된 외부 도구부터 확인합니다

• 이미지·영상 생성이 필요하면 이 실습 뒤 Higgsfield 연결 카드로 이어갑니다

• 그 연결은 생성 전에 잔여 크레딧과 한 건의 예상 비용부터 확인합니다

• 서브에이전트: 별도 맥락에서 작업하고 결과만 본 대화로 돌려주는 워커

• “서브에이전트로 조사해 줘”처럼 요청하면 Claude가 워커를 골라 위임합니다

• 본 대화에서 직접 조사하면 중간 결과와 읽고 안 쓴 파일이 그대로 쌓입니다

• 맥락이 무거워지면 이후 요청에서 처음 규칙을 놓칩니다

• 파일 여러 개를 뒤지거나 같은 조사를 반복할 때 씁니다.

• 한두 줄로 끝나는 질문은 직접 답하는 게 빠릅니다.

• 위임한 작업은 끝나거나 막히면 스스로 보고합니다.

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

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

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

• Claude에 기능을 더하는 확장은 이름이 비슷하지만 이름을 외울 필요는 없습니다
• 고를 것: 반복 절차를 저장하려는지, 외부 자료를 읽으려는지, 여러 기능을 한 번에 설치하려는지

처음에는 질문 세 개만 씁니다

• Claude 웹·데스크톱 앱의 챗·코워크: 로그인 화면으로 켜는 MCP 연결을 커넥터라고 부름
• Claude Code·Codex: 같은 종류의 연결을 MCP라는 이름으로 봄
• 첫 실습: 노션이나 구글 드라이브 중 실제로 쓸 서비스 하나만 연결하고 자료 한 건을 읽어 봅니다

세 가지를 구분합니다

• 스킬: 한 가지 작업을 잘하도록 만든 지침입니다. Claude가 읽고 그대로 따릅니다. (직원에게 건네는 업무 매뉴얼과 비슷합니다.)

• MCP(Model Context Protocol): Claude와 Notion·Figma 같은 외부 앱을 연결하는 규격입니다.

• 플러그인: 스킬·서브에이전트·훅·외부 연결을 묶은 패키지입니다.

• 플러그인은 배포 단위여서 안에 스킬과 MCP 설정이 함께 들어 있기도 합니다

• 이때도 외부 서비스에 실제로 접속하는 일은 그 안의 MCP가 맡습니다

나머지 둘까지 놓고 보면

• 데스크탑 앱 Code 탭: 입력창 옆 + 버튼의 Plugins에서 플러그인을 찾아 설치합니다

• 무엇이 늘어나는지로 보면 다섯 가지 확장이 세 갈래로 묶입니다:

• 서브에이전트: Claude가 일부 작업을 따로 떼어 맡기는 보조 실행자(일을 나눠 받아 결과만 돌려주는 보조 직원과 비슷)
• 훅: 정해진 시점에 자동으로 도는 명령(문을 닫으면 저절로 잠기는 자물쇠와 비슷)
• 둘은 남이 만든 것을 받는 대신 직접 만드는 쪽이라 뒤 단원에서 다룹니다
• 스킬은 Claude가 읽고 따르는 글이어서 지나칠 수 있지만, 훅은 정해진 시점에 자동 실행돼 지나칠 수 없습니다

MCP는 계정 권한을 사용합니다. 연결할 앱과 허용 범위를 먼저 확인합니다.

MCP는 내 작업으로 고릅니다

• 아래 다섯 MCP는 서로 다른 일을 맡으므로 모두 연결할 필요가 없습니다
• 고르는 때: 반복해서 쓰는 서비스가 있고 Claude가 그 서비스의 자료를 읽거나 작업해야 할 때 하나

• Notion: 문서 하나를 읽어 보는 첫 실습에 적합. Notion 연결 카드에서 페이지를 수정하지 않고 연결과 읽기 범위부터 확인합니다
• Higgsfield: Higgsfield 연결 카드에서 생성 전에 잔액과 예상 크레딧을 확인합니다
• Higgsfield 웹 요금제에 무료·무제한 생성이 포함되어 있어도 MCP로 생성하면 크레딧이 차감됩니다

웹 · 앱 · 터미널, 연결은 어디에 남나요

• 같은 Notion 연결이라도 어디서 켰느냐에 따라 저장되는 곳이 둘로 갈립니다
• 웹·데스크톱 앱의 챗·코워크에서 켠 커넥터와 스킬: 내 Claude 계정에 남아 다른 컴퓨터와 휴대폰에서도 보임
• 터미널·데스크톱 앱 Code 탭에서 추가한 MCP·플러그인·스킬: 이 컴퓨터의 Claude Code 설정 파일에 남아 다른 컴퓨터에는 따라가지 않음

• 공식 문서: 데스크톱 앱 Code 탭과 터미널이 같은 설정 파일을 읽어 MCP 서버·스킬·설정이 양쪽에 그대로 적용됩니다

• 챗·코워크와 Claude Code에서 함께 쓸 서비스는 계정 커넥터로, 이 컴퓨터에서만 쓰는 도구는 터미널에서 추가합니다

• 플러그인을 설치하면 딸려 온 MCP도 이 컴퓨터에 등록되고, 로그인하지 않은 MCP는 연결되지 않은 채 목록에만 남으므로 쓰지 않는 플러그인은 꺼 둡니다

• 세 종류의 예시 보기

• 스킬(작업 지침 파일)·플러그인(여러 확장을 묶은 설치 꾸러미)·MCP(외부 서비스 연결)를 설치하면 Claude가 그 지침을 따르거나 연결된 서비스에 내 계정으로 접근합니다
• 남이 만든 확장은 내 컴퓨터에서 명령을 실행하거나 계정 권한을 쓸 수 있습니다
• 설치 전 확인: 지금 필요한지, 누가 만들었는지, 어떤 권한을 쓰는지

설치 전에 세 가지만 봅니다

• 필요성: 지금 할 일에 필요한 하나만 고릅니다.
• 출처: 제작자와 최신 안내를 살펴봅니다.
• 조건: 권한·비용·설치 위치를 확인합니다.

• 기본 설치 방법: 데스크탑 앱 Code 탭 채팅에 위 요청 문장으로 부탁
• 플러그인: 입력창 옆 + 버튼의 Plugins에서도 찾을 수 있습니다
• Claude 웹·데스크탑 앱의 커넥터(MCP): Customize > Connectors에서 연결
• 설치할 항목 고르기

작은 작업 하나로 확인합니다

• 요청: 원하는 결과를 한 문장으로 말합니다.

• 확인: 생성된 파일이나 앱 변경을 직접 엽니다.

• 판단: 다시 쓸 만하면 유지합니다. 권한이 과하면 제거합니다.

• 처음부터 끝까지 따라 할 사례: eli5로 설명 아티팩트 열기

MCP로 외부 앱을 바꿀 때는 읽기와 수정 범위를 구분합니다.

• Skill(스킬): 특정 작업의 절차와 규칙을 SKILL.md 파일에 정리해 둔 것

• 이름을 불러 실행하면 매번 설명했던 순서와 기준을 다시 적지 않아도 됩니다

• description(스킬 설명글)에 실제로 쓸 법한 표현을 적으면 Claude가 요청 맥락을 보고 스스로 스킬을 불러옵니다

• 설명이 부실하면 이름을 직접 불러야만 실행됩니다

• Plugin(플러그인): Skill·서브에이전트·Hook(정해진 시점에 자동 실행되는 규칙) 여러 개를 묶어 다른 프로젝트나 사람에게 그대로 옮기는 꾸러미

• 한 프로젝트에서 다듬은 조합을 다른 곳에도 쓸 때 이 단위로 옮깁니다

• 카피라이터가 매주 같은 형식으로 뉴스레터 초안을 뽑는다면, 그 절차를 스킬로 만들어 두고 다음부터는 이름만 불러 실행하면 됩니다.

• description에 “뉴스레터용”처럼 짧게만 적어 두면 실제 요청 문장과 맞아떨어지지 않아 자동으로 불려 오지 않습니다.

• 처음부터 완벽하게 만들 필요는 없습니다

• 반복하면 빠진 단계나 잘못된 가정이 드러나므로 실제로 쓰면서 다듬습니다

• 실습: 아래 요청문을 복사해 붙여넣고 반복 절차 하나를 스킬로 만듭니다