Permission과 보안 시스템 완벽 가이드

Claude Code의 Permission 시스템을 통해 보안을 관리하는 방법을 알아봅니다. 권한 모델, 파일 보호, 명령어 제어 등 실무에서 필요한 보안 개념을 쉽게 설명합니다.

---

목차

1. Permission_네임스페이스
2. allow_ask_deny_권한_모델
3. edit_권한과_파일_보호
4. bash_명령어_화이트리스트와_블랙리스트
5. plan_모드의_읽기_전용_권한
6. 외부_디렉토리_접근_제어

---

1. Permission 네임스페이스

김개발 씨는 처음으로 Claude Code를 회사 프로젝트에 도입하게 되었습니다. 그런데 AI가 마음대로 파일을 수정하거나 위험한 명령어를 실행하면 어떡하지?

하는 걱정이 들었습니다. 바로 이런 고민을 해결해주는 것이 Permission 네임스페이스입니다.

Permission 네임스페이스는 Claude Code의 모든 권한 설정을 담는 최상위 컨테이너입니다. 마치 회사의 보안 정책 문서처럼, 누가 어떤 작업을 할 수 있는지 한곳에서 관리합니다.

이 구조를 이해하면 AI 에이전트의 행동을 정밀하게 제어할 수 있습니다.

다음 코드를 살펴봅시다.

// Permission 네임스페이스의 기본 구조
interface Permission {
  // 파일 편집 권한 설정
  edit: EditPermission;
  // 터미널 명령어 권한 설정
  bash: BashPermission;
  // MCP 도구 권한 설정
  mcp: McpPermission;
  // 알림 설정
  notifications: NotificationSettings;
}

// 설정 파일 예시 (settings.json)
const permissionConfig = {
  "permissions": {
    "edit": { "fileProtections": [] },
    "bash": { "allow": [], "deny": [] }
  }
};

김개발 씨는 입사 2년 차 백엔드 개발자입니다. 최근 팀에서 Claude Code를 도입하기로 했는데, 팀장님이 보안 설정을 맡아달라고 요청하셨습니다.

"AI가 우리 서버 설정 파일을 건드리면 큰일 나잖아요. 확실하게 막아주세요." 김개발 씨는 걱정이 앞섰습니다.

AI 에이전트가 아무 제한 없이 코드를 수정하고 명령어를 실행할 수 있다면 정말 위험할 수 있습니다. 그때 옆자리 박시니어 씨가 다가왔습니다.

"Permission 네임스페이스부터 알아보면 돼요. 거기가 보안 설정의 시작점이에요." Permission 네임스페이스가 정확히 무엇일까요?

쉽게 비유하자면, 회사 건물의 출입 관리 시스템과 같습니다. 건물에 들어오는 모든 사람은 출입 카드를 찍어야 하고, 어떤 층에 갈 수 있는지가 카드에 설정되어 있습니다.

Permission 네임스페이스도 마찬가지로 Claude Code가 할 수 있는 모든 행동의 권한을 한곳에서 관리합니다. Permission 네임스페이스가 없던 시절에는 어땠을까요?

AI 도구들은 사용자가 허락한 모든 것을 그냥 실행해버렸습니다. 실수로 중요한 파일을 삭제하거나, 위험한 명령어를 실행하는 사고가 종종 발생했습니다.

바로 이런 문제를 해결하기 위해 체계적인 권한 관리 시스템이 등장했습니다. Permission 네임스페이스 안에는 크게 세 가지 영역이 있습니다.

edit는 파일 편집 권한을, bash는 터미널 명령어 권한을, mcp는 외부 도구 연동 권한을 담당합니다. 위의 코드를 살펴보면, Permission 인터페이스가 여러 하위 설정을 포함하고 있음을 알 수 있습니다.

각 영역은 독립적으로 설정할 수 있어서, 파일 편집은 자유롭게 허용하되 특정 명령어는 차단하는 식의 세밀한 제어가 가능합니다. 실제 현업에서는 프로젝트마다 다른 보안 정책이 필요합니다.

예를 들어 프론트엔드 프로젝트에서는 배포 스크립트 실행을 허용하지만, 데이터베이스 관련 명령어는 차단해야 할 수 있습니다. Permission 네임스페이스를 통해 이런 맞춤형 설정이 가능해집니다.

주의할 점도 있습니다. Permission 설정은 settings.json 파일에 저장되는데, 이 파일 자체의 보안도 신경 써야 합니다.

누군가 설정 파일을 수정해서 권한을 풀어버리면 무용지물이 되기 때문입니다. 김개발 씨는 박시니어 씨의 설명을 듣고 고개를 끄덕였습니다.

"아, 그러니까 Permission 네임스페이스가 보안 설정의 뿌리인 거군요!" 이제 구체적인 권한 모델을 알아볼 차례입니다.

실전 팁

💡 - Permission 설정은 프로젝트별로 다르게 구성할 수 있습니다

• 설정 파일은 버전 관리에 포함하여 팀 전체가 동일한 보안 정책을 사용하세요

---

2. allow ask deny 권한 모델

김개발 씨가 Permission 네임스페이스를 이해하고 나니, 이제 구체적인 권한 설정이 궁금해졌습니다. "파일마다, 명령어마다 일일이 설정해야 하나요?" 박시니어 씨가 미소 지으며 대답했습니다.

"세 가지 키워드만 기억하면 돼요. allow, ask, deny."

allow, ask, deny는 권한의 세 가지 상태입니다. allow는 자동으로 허용, ask는 매번 사용자에게 확인, deny는 무조건 차단입니다.

마치 스마트폰 앱의 권한 설정처럼 세밀하게 제어할 수 있습니다.

다음 코드를 살펴봅시다.

// 권한 모델의 세 가지 상태
type PermissionLevel = "allow" | "ask" | "deny";

// Bash 명령어 권한 설정 예시
const bashPermission = {
  // 자동 허용할 명령어 패턴
  "allow": [
    "npm:*",           // npm 명령어는 모두 허용
    "git status",      // git status만 허용
    "pnpm build:*"     // pnpm build로 시작하는 것 허용
  ],
  // 무조건 차단할 명령어 패턴
  "deny": [
    "rm -rf *",        // 위험한 삭제 명령어 차단
    "sudo:*"           // sudo 명령어 전체 차단
  ]
  // 나머지는 자동으로 "ask" 상태
};

김개발 씨는 매번 Claude Code가 뭔가를 실행할 때마다 확인 창이 뜨는 게 불편했습니다. "git status 같은 건 그냥 실행해도 되는데, 왜 매번 물어보는 거죠?" 박시니어 씨가 설명을 시작했습니다.

"기본 상태가 ask이기 때문이에요. 안전을 위해서 모든 동작은 일단 물어보도록 설계되어 있거든요.

하지만 자주 쓰는 안전한 명령어는 allow 목록에 넣으면 돼요." allow, ask, deny 모델은 마치 집의 현관문과 같습니다. deny는 절대 열어주지 않는 문단속 상태입니다.

ask는 초인종이 울리면 누군지 확인하고 열어주는 상태입니다. allow는 가족처럼 신뢰하는 사람에게는 자동으로 열리는 스마트 도어락 같은 상태입니다.

이런 3단계 모델이 왜 필요할까요? 모든 것을 allow로 설정하면 편하겠지만 위험합니다.

반대로 모든 것을 ask로 설정하면 안전하지만 매우 불편합니다. 균형을 찾는 것이 핵심입니다.

위의 코드를 보면 와일드카드 패턴을 사용할 수 있음을 알 수 있습니다. npm:*는 npm으로 시작하는 모든 명령어를 의미합니다.

이렇게 하면 npm install, npm run dev 등을 일일이 등록하지 않아도 됩니다. 중요한 점은 deny가 allow보다 우선한다는 것입니다.

만약 bash:*를 allow에 넣고 rm -rf *를 deny에 넣으면, rm -rf 명령어는 여전히 차단됩니다. 보안의 기본 원칙인 "허용보다 차단이 우선"을 따르는 것입니다.

실무에서는 팀의 개발 환경에 맞게 설정하는 것이 좋습니다. 예를 들어 프론트엔드 팀이라면 npm, pnpm 관련 명령어는 allow에, 데이터베이스 관련 명령어는 deny에 넣는 식입니다.

초보 개발자들이 흔히 하는 실수는 처음부터 너무 많은 것을 allow에 넣는 것입니다. 처음에는 최소한만 allow에 넣고, 필요할 때마다 추가하는 방식이 안전합니다.

김개발 씨는 이제 어떤 명령어를 allow에 넣을지 생각하기 시작했습니다. "빌드 명령어랑 테스트 명령어는 안전하니까 allow에 넣고, 배포 관련은 ask로 유지해야겠네요!"

실전 팁

💡 - 처음에는 최소한의 allow만 설정하고, 필요에 따라 점진적으로 추가하세요

• 와일드카드(*)를 사용할 때는 의도치 않은 명령어가 포함되지 않는지 확인하세요

---

3. edit 권한과 파일 보호

다음 날, 김개발 씨에게 아찔한 일이 벌어졌습니다. Claude Code가 코드를 리팩토링하다가 환경 설정 파일까지 수정해버린 것입니다.

다행히 git으로 복구했지만, 앞으로는 이런 일을 막아야 했습니다. "특정 파일은 절대 못 건드리게 할 수 없나요?"

edit 권한은 파일 편집에 대한 제어를 담당합니다. fileProtections 설정을 통해 특정 파일이나 패턴을 보호할 수 있습니다.

마치 워드 문서의 "보호 모드"처럼, 중요한 파일을 실수로 수정하는 것을 방지합니다.

다음 코드를 살펴봅시다.

// edit 권한 설정 구조
interface EditPermission {
  fileProtections: FileProtection[];
}

interface FileProtection {
  pattern: string;      // 파일 경로 패턴 (glob 지원)
  permission: "ask" | "deny";  // 보호 수준
  reason?: string;      // 보호 이유 (선택)
}

// 설정 예시
const editConfig = {
  "edit": {
    "fileProtections": [
      { "pattern": ".env*", "permission": "deny" },
      { "pattern": "*.config.js", "permission": "ask" },
      { "pattern": "package-lock.json", "permission": "deny" },
      { "pattern": "src/core/**", "permission": "ask" }
    ]
  }
};

김개발 씨의 팀에서는 환경 변수 파일(.env)에 데이터베이스 비밀번호와 API 키가 들어 있습니다. 이 파일이 잘못 수정되면 서비스 전체가 멈출 수 있습니다.

박시니어 씨가 말했습니다. "이런 파일은 fileProtections로 보호해야 해요." fileProtections는 마치 금고와 같습니다.

금고 안에 넣은 것은 특별한 절차 없이는 꺼낼 수 없습니다. edit 권한에서 fileProtections에 등록된 파일은 Claude Code가 함부로 수정할 수 없게 됩니다.

설정 방법은 간단합니다. pattern에 보호할 파일 경로를, permission에 보호 수준을 지정합니다.

"deny"로 설정하면 아예 편집이 불가능하고, "ask"로 설정하면 편집하기 전에 사용자 확인을 받습니다. 위의 코드에서 .env* 패턴을 보세요.

별표(*)는 와일드카드로, .env, .env.local, .env.production 등 모든 환경 변수 파일을 한 번에 보호합니다. 이렇게 glob 패턴을 지원하기 때문에 효율적인 설정이 가능합니다.

실무에서 꼭 보호해야 하는 파일들이 있습니다. 환경 변수 파일(.env)은 당연하고, package-lock.json이나 yarn.lock 같은 잠금 파일도 중요합니다.

이 파일들이 잘못 수정되면 의존성 충돌이 발생할 수 있기 때문입니다. 디렉토리 단위로도 보호할 수 있습니다.

예를 들어 src/core/** 패턴은 핵심 비즈니스 로직이 담긴 폴더 전체를 보호합니다. 이 폴더의 파일을 수정하려면 항상 확인을 거쳐야 합니다.

주의할 점이 있습니다. 너무 많은 파일을 deny로 설정하면 Claude Code의 활용도가 떨어집니다.

정말 중요한 파일만 deny로, 나머지는 ask로 설정하는 것이 좋습니다. 김개발 씨는 바로 설정 파일을 열어 fileProtections를 추가했습니다.

".env 파일이랑 config 파일들은 deny로, 그리고 core 폴더는 ask로 설정해야겠어요." 이제 실수로 중요한 파일이 수정될 걱정은 없어졌습니다.

실전 팁

💡 - .env, 잠금 파일(lock), 설정 파일은 deny로 보호하세요

• 핵심 비즈니스 로직 폴더는 ask로 설정하여 리뷰 기회를 확보하세요

---

4. bash 명령어 화이트리스트와 블랙리스트

김개발 씨가 보안 설정을 하던 중 문득 걱정이 들었습니다. "Claude Code가 rm -rf / 같은 명령어를 실행하면 어떡하죠?" 박시니어 씨가 웃으며 말했습니다.

"그래서 bash 명령어도 따로 제어할 수 있어요. 화이트리스트와 블랙리스트를 설정하면 됩니다."

bash 권한에서는 allow(화이트리스트)와 deny(블랙리스트)를 설정할 수 있습니다. 화이트리스트에 등록된 명령어는 자동으로 실행되고, 블랙리스트에 등록된 명령어는 무조건 차단됩니다.

두 목록에 없는 명령어는 실행 전 사용자 확인을 요청합니다.

다음 코드를 살펴봅시다.

// bash 권한 설정 구조
interface BashPermission {
  allow: string[];    // 화이트리스트 (자동 허용)
  deny: string[];     // 블랙리스트 (무조건 차단)
}

// 실무 설정 예시
const bashConfig = {
  "bash": {
    "allow": [
      "npm:*",              // npm 명령어 전체 허용
      "pnpm:*",             // pnpm 명령어 전체 허용
      "git status",         // 상태 확인만 허용
      "git diff:*",         // diff 관련 허용
      "jest:*",             // 테스트 실행 허용
      "curl:*"              // API 호출 허용
    ],
    "deny": [
      "rm -rf:*",           // 위험한 삭제 차단
      "sudo:*",             // 관리자 권한 차단
      "chmod 777:*",        // 위험한 권한 변경 차단
      "> /dev/sda:*",       // 디스크 직접 접근 차단
      ":(){ :|:& };:"       // 포크 폭탄 차단
    ]
  }
};

터미널 명령어는 양날의 검입니다. npm install처럼 유용한 명령어도 있지만, rm -rf /처럼 시스템을 파괴할 수 있는 명령어도 있습니다.

김개발 씨는 이 둘을 어떻게 구분해서 제어할지 고민했습니다. 박시니어 씨가 화이트보드에 그림을 그렸습니다.

"화이트리스트는 신뢰하는 손님 목록이에요. 이 목록에 있는 사람은 신분증 확인 없이 입장시켜요.

반대로 블랙리스트는 출입 금지 목록이에요. 이 목록에 있는 사람은 절대 들여보내지 않아요." bash 권한에서 allow 배열이 바로 화이트리스트입니다.

여기에 등록된 명령어는 Claude Code가 사용자 확인 없이 바로 실행할 수 있습니다. 개발 중에 자주 사용하는 안전한 명령어를 등록해두면 작업 효율이 올라갑니다.

deny 배열은 블랙리스트입니다. 절대로 실행되면 안 되는 위험한 명령어를 등록합니다.

rm -rf, sudo, chmod 777 같은 명령어가 대표적입니다. 이 명령어들은 시스템에 돌이킬 수 없는 피해를 줄 수 있기 때문입니다.

코드에서 **콜론(:)과 별표(*)**의 조합을 주목하세요. npm:*는 "npm으로 시작하는 모든 명령어"를 의미합니다.

이 패턴 문법 덕분에 npm install, npm run dev, npm test 등을 일일이 등록하지 않아도 됩니다. 중요한 규칙이 있습니다.

deny는 항상 allow보다 우선합니다. 만약 실수로 bash:*를 allow에 넣어도, deny에 있는 위험한 명령어는 여전히 차단됩니다.

이것은 보안 시스템의 기본 원칙인 "안전 우선"을 따르는 것입니다. 실무에서 권장하는 설정이 있습니다.

빌드 도구(npm, pnpm, yarn), 테스트 도구(jest, pytest), 버전 관리의 읽기 명령어(git status, git diff)는 allow에 넣어도 안전합니다. 반면 시스템 관리 명령어(sudo, rm -rf, chmod)는 반드시 deny에 넣어야 합니다.

김개발 씨가 물었습니다. "그럼 두 목록에 없는 명령어는요?" 박시니어 씨가 답했습니다.

"자동으로 ask 상태가 돼요. 실행하기 전에 사용자에게 확인을 요청하죠.

그래서 처음엔 allow를 최소한으로 시작하는 게 좋아요."

실전 팁

💡 - 빌드/테스트 명령어는 allow에, 시스템 관리 명령어는 deny에 등록하세요

• 새로운 명령어가 필요하면 ask 상태에서 검토 후 allow에 추가하세요

---

5. plan 모드의 읽기 전용 권한

김개발 씨가 큰 규모의 리팩토링을 앞두고 있었습니다. "먼저 계획을 세우고 싶은데, Claude Code가 계획 세우다가 실수로 파일을 수정하면 어떡하죠?" 박시니어 씨가 새로운 기능을 알려주었습니다.

"plan 모드를 사용하면 읽기만 가능해서 안전해요."

plan 모드는 Claude Code를 읽기 전용 상태로 전환합니다. 이 모드에서는 파일을 읽고 분석할 수 있지만, 수정이나 명령어 실행은 불가능합니다.

마치 도서관에서 책을 열람만 할 수 있고 가져갈 수는 없는 것처럼, 안전하게 탐색하고 계획을 세울 수 있습니다.

다음 코드를 살펴봅시다.

// plan 모드에서 사용 가능한 도구들
const planModeTools = {
  // 허용되는 도구 (읽기 전용)
  allowed: [
    "Read",           // 파일 읽기
    "Glob",           // 파일 패턴 검색
    "Grep",           // 내용 검색
    "WebFetch",       // 웹 페이지 읽기
    "WebSearch",      // 웹 검색
    "Task"            // 하위 에이전트 실행
  ],
  // 차단되는 도구 (쓰기/실행)
  blocked: [
    "Edit",           // 파일 편집 불가
    "Write",          // 파일 생성 불가
    "Bash",           // 명령어 실행 불가
    "NotebookEdit"    // 노트북 편집 불가
  ]
};

// plan 모드 진입 방법
// 1. EnterPlanMode 도구 사용
// 2. 복잡한 작업 전 자동 제안됨

큰 프로젝트를 리팩토링할 때, 먼저 전체 구조를 파악하고 계획을 세우는 것이 중요합니다. 김개발 씨도 마찬가지였습니다.

하지만 분석하다가 실수로 코드가 수정될까 봐 걱정이었습니다. 박시니어 씨가 말했습니다.

"plan 모드를 사용해보세요. 이 모드에서는 Claude Code가 읽기만 할 수 있어요.

마치 박물관에서 전시물을 눈으로만 보는 것처럼요." plan 모드는 의도적으로 기능을 제한합니다. Read, Glob, Grep 같은 읽기 도구만 사용할 수 있고, Edit, Write, Bash 같은 수정/실행 도구는 차단됩니다.

이렇게 하면 실수로 인한 사고를 원천적으로 방지할 수 있습니다. 이 모드가 유용한 상황이 여러 가지 있습니다.

첫째, 대규모 리팩토링 전 코드 구조를 파악할 때입니다. 둘째, 버그의 원인을 분석할 때입니다.

셋째, 새로운 프로젝트의 아키텍처를 이해할 때입니다. 모두 "보는 것"이 중요하고 "바꾸는 것"은 아직 이른 상황들입니다.

plan 모드에서는 ExitPlanMode 도구로 일반 모드로 돌아갈 수 있습니다. 계획을 충분히 세운 후에 일반 모드로 전환하여 실제 작업을 수행하면 됩니다.

이 과정에서 사용자의 승인이 필요하므로 이중 안전장치가 됩니다. 실무에서 plan 모드는 코드 리뷰에도 유용합니다.

팀원의 코드를 분석하고 피드백을 작성할 때, 실수로 코드를 건드릴 걱정 없이 자유롭게 탐색할 수 있습니다. 김개발 씨가 물었습니다.

"그럼 plan 모드에서 계획을 세우고, 나중에 실행하면 되는 거네요?" 박시니어 씨가 고개를 끄덕였습니다. "맞아요.

계획과 실행을 분리하는 거예요. 이게 안전한 개발의 기본이에요."

실전 팁

💡 - 대규모 작업 전에는 항상 plan 모드로 먼저 분석하세요

• plan 모드에서 작성한 계획을 문서화해두면 팀원과 공유하기 좋습니다

---

6. 외부 디렉토리 접근 제어

김개발 씨가 프로젝트 폴더에서 작업하다가 실수로 Claude Code에게 "시스템 폴더의 파일을 확인해줘"라고 요청했습니다. 그런데 Claude Code가 거부했습니다.

"왜 안 되는 거죠?" 박시니어 씨가 설명했습니다. "작업 디렉토리 밖은 기본적으로 접근이 제한되어 있어요."

Claude Code는 기본적으로 현재 작업 디렉토리 내에서만 동작합니다. 프로젝트 폴더 외부의 파일이나 시스템 디렉토리에 접근하려면 명시적인 허가가 필요합니다.

이것은 마치 아파트의 각 세대가 분리되어 있어 옆집에 마음대로 들어갈 수 없는 것과 같습니다.

다음 코드를 살펴봅시다.

// 작업 디렉토리 접근 제어 개념
interface DirectoryAccess {
  // 현재 작업 디렉토리 (자동 허용)
  workingDirectory: string;  // 예: /home/dev-cardnews

  // 외부 경로 접근 시 동작
  externalAccess: "ask" | "deny";
}

// 외부 디렉토리 접근 시나리오
const accessScenarios = {
  // 허용되는 접근 (작업 디렉토리 내)
  allowed: [
    "/home/dev-cardnews/src/components",
    "/home/dev-cardnews/package.json",
    "/home/dev-cardnews/.env.example"
  ],
  // 확인 필요한 접근 (작업 디렉토리 외)
  needsPermission: [
    "/home/other-project/config.js",
    "/etc/hosts",
    "~/.ssh/config"
  ]
};

김개발 씨는 처음에 이 제한이 불편하게 느껴졌습니다. "같은 컴퓨터인데 왜 다른 폴더는 못 보는 거죠?" 하지만 박시니어 씨의 설명을 듣고 나서 이해가 되었습니다.

"상상해봐요. AI가 아무 폴더나 접근할 수 있다면 어떻게 될까요?

다른 프로젝트의 비밀 정보를 읽을 수도 있고, 시스템 설정 파일을 건드릴 수도 있어요. 그래서 샌드박스 개념이 필요한 거예요." 샌드박스는 어린이 놀이터의 모래밭과 같습니다.

아이들이 모래밭 안에서는 자유롭게 놀 수 있지만, 밖으로 나가면 부모의 허락이 필요합니다. Claude Code도 마찬가지로 작업 디렉토리라는 샌드박스 안에서 자유롭게 동작하지만, 밖으로 나가려면 사용자의 허가가 필요합니다.

작업 디렉토리는 Claude Code를 실행한 위치입니다. 예를 들어 /home/dev-cardnews에서 시작했다면, 이 폴더와 그 하위 폴더가 자유 접근 영역이 됩니다.

src, components, lib 등 프로젝트 내 모든 경로에 자유롭게 접근할 수 있습니다. 하지만 /home/other-project나 /etc 같은 외부 경로에 접근하려면 확인 과정을 거칩니다.

Claude Code가 "이 경로에 접근해도 될까요?"라고 물어보고, 사용자가 허락해야만 접근할 수 있습니다. 이 제한이 특히 중요한 경우가 있습니다.

멀티 프로젝트 환경에서 일할 때입니다. 만약 A 프로젝트에서 Claude Code를 사용하다가 실수로 B 프로젝트의 파일을 수정하면 큰 문제가 될 수 있습니다.

디렉토리 격리가 이런 사고를 방지합니다. 시스템 디렉토리 보호도 중요합니다.

/etc, /usr, ~/.ssh 같은 폴더에는 시스템 설정이나 보안 키가 들어 있습니다. 이런 민감한 영역은 기본적으로 접근이 차단되어 있어 안전합니다.

김개발 씨가 고개를 끄덕였습니다. "아, 그러니까 프로젝트별로 경계를 만들어주는 거군요.

다른 프로젝트나 시스템에 영향을 주지 않도록요." 박시니어 씨가 미소 지었습니다. "맞아요.

보안의 기본은 최소 권한 원칙이에요. 필요한 만큼만 접근을 허용하는 거죠."

실전 팁

💡 - 여러 프로젝트를 다룰 때는 각 프로젝트 폴더에서 별도로 Claude Code를 실행하세요

• 외부 경로 접근이 자주 필요하다면, 해당 파일을 프로젝트 내로 복사하는 것이 안전합니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!