핵심 정리와 모듈 마무리

섹션 하나당 핵심 하나씩, 모듈 전체를 한 줄기로 묶어 정리합니다. 각 정리는 앞선 레슨에서 다룬 판단을 다시 짚는 것이라, 개별 레슨으로 돌아가기 전에 전체 그림을 확인하는 데 쓰면 좋습니다.

1. 1

   권한 모드는 속도가 아니라 위험을 기준으로 정합니다

   Claude Code의 권한 모드는 매번 확인을 받는 쪽부터, 아예 묻지 않는 쪽까지 폭이 넓습니다. 어떤 모드를 고를지는 프롬프트를 덜 받고 싶은 편의보다, 그 작업과 환경의 위험 수준에 맞추는 편이 안전합니다. 개발 워크스테이션에서 실제 코드베이스를 상대로 확인 없이 실행하는 모드를 켜면, 에이전트와 파일 사이의 점검이 전부 사라집니다. 손대면 안 되는 경로에는 프로젝트나 엔터프라이즈 수준에서 거부 규칙(deny rule)을 걸어 두면, 모드만으로는 막지 못하는 구멍을 메울 수 있습니다.

2. 2

   AI 코드 리뷰는 그대로 적용할 판정이 아니라, 살펴볼 발견 목록입니다

   리뷰가 눈앞의 변경(diff)에서 직접 증명할 수 있는 지적 — 빠진 null 검사나 닫히지 않은 자원 같은 것 — 은 믿을 만하고, 리뷰가 가리키는 줄에서 바로 확인할 수 있습니다. 반면 런타임 동작이나 다른 시스템에 대한 주장은 검증해 볼 가설로 다루는 편이 좋습니다. 리뷰가 그 주장을 뒷받침할 증거 없이 내놓은 것이기 때문입니다. 사람이 확인하는 지점은 발견이 되돌리기 어려운 행동으로 바뀌는 자리에 두고, 리뷰가 짐작으로 메우던 프로젝트 관례를 미리 알려 주면 정확도가 올라갑니다.

3. 3

   스킬은 이식할 수 있지만, "어디서나 동작한다"는 설계가 필요합니다

   같은 SKILL.md 파일이라도 Claude Code, Messages API, Agent SDK에서 모두 실행할 수 있습니다. 다만 로딩·샌드박스 방식은 환경마다 다릅니다 — Claude Code는 파일 시스템에서 찾아 읽고, API는 베타 헤더와 코드 실행 컨테이너를 쓰며, SDK는 settingSources로 지정합니다. 설명이 명확하고 특정 환경을 가정하지 않는 스킬은 깔끔하게 옮겨 가지만, 처음 작성한 터미널 환경을 전제한 스킬은 그렇지 않습니다. 그리고 어느 환경에서든 서브에이전트는 빈 상태에서 시작합니다. 스킬을 자동으로 미리 불러오지 않습니다.

4. 4

   지속 컨텍스트는 관심사마다 맞는 장치가 따로 있습니다

   CLAUDE.md는 세션 사이에도 남는 프로젝트 메모리지만, 내용이 커질수록 규칙이 희석됩니다. 규칙 파일(rules file)은 지침이 적용될 위치로 범위를 좁혀 줍니다. 훅(hook)은 확률이 아니라 정해진 방식으로 가드레일을 강제합니다. 서브에이전트는 탐색 작업을 메인 컨텍스트 밖에서 처리합니다. 이 네 가지는 각각 다른 문제를 풀기 때문에, 전부 CLAUDE.md 하나에 몰아넣으면 오히려 관리하기 어렵고 무시되기 쉬운 파일이 됩니다.

5. 5

   공유할 설정은 이식 가능한 구성요소로 이루어져야 합니다

   작성자의 홈 디렉터리를 절대 경로로 가리키는 플러그인은 그 사람 기기에서는 설치되지만 다른 기기에서는 전부 실패합니다. 공유할 스킬·훅·플러그인 구성요소는 프로젝트 루트를 기준으로 한 상대 경로를 쓰고, 필요한 환경 변수는 설치 시점에 문서로 안내하거나 검사하도록 만드는 것이 좋습니다. 배포하기 전에 아무것도 설정되지 않은 깨끗한 기기에서 설치를 한 번 시험해 봅니다.

6. 6

   전송 방식과 범위는 따로 정하지만, 결과는 서로 맞물립니다

   stdio는 내 컴퓨터에서 실행되는 서버에 쓰고, HTTP는 원격에 올려 두었거나 여러 개발자가 함께 접근하는 서버에 씁니다. 로컬 범위는 서버를 개인용으로 두고, 프로젝트 범위는 .mcp.json에 담아 저장소 전체와 공유합니다. 이 조합은 배포 의도와 맞아야 합니다. 팀이 함께 쓰는 서버라면 HTTP 전송에 프로젝트나 엔터프라이즈 범위가 필요합니다. stdio 서버를 .mcp.json에 넣어 두면 공유되는 것처럼 보이지만 실제로는 공유되지 않습니다.

7. 7

   엔터프라이즈 통합은 배포 전에 보안 요건부터 확인합니다

   규제를 받는 고객은 신원 확인, 데이터 보관 위치, 접근 기록, 설정 통제를 묻습니다. 각각에 대한 답은 대체로 정해져 있습니다 — 사용자 신원이 필요한 서비스에는 OAuth, 서비스 자격 증명에는 환경 변수, 감사 로그에는 PostToolUse 훅, 설정을 잠그는 데는 엔터프라이즈 관리 설정입니다. 어느 것도 구현이 특별히 어렵지는 않지만, 실서비스 배포가 보안 검토에서 막힌 뒤에 소급해서 넣기는 모두 어렵습니다. 그래서 배포 전에 요건을 짚어 두는 편이 좋습니다.

모듈에서 나온 핵심 용어 아홉 개를 알파벳 순서로 모았습니다. 제목을 누르면 풀이가 펼쳐집니다. 각 정의는 앞 레슨의 설명을 한자리에 정리한 것이니, 헷갈리는 용어만 골라 다시 확인하는 데 쓰면 좋습니다.

여기까지가 모듈 3입니다. 원문 코스는 모듈 3의 점검 여덟 개를 모두 통과한 지점을 모듈 완료로 표시합니다. 아래 지도는 개발자 경로의 다섯 모듈 전체이고, 지금 위치는 세 번째입니다.

DEVELOPER PATH — 다섯 모듈 지도

다음은 모듈 4 — 프로덕션 엔지니어링, 평가, 보안입니다. Claude Code 통합이 규모가 커져도 제대로 동작하는지 측정하는 법, 평가 하니스(eval harness)를 만드는 법, 프로덕션 수준의 안전 가드레일을 설계하는 법을 살펴봅니다. 이 모듈에서 익힌 권한 모드·훅·인증 패턴이 그 평가들이 검증하는 토대가 됩니다.

핵심 정리 일곱 가지를 문제로 다시 짚어 봅니다. 정답을 먼저 떠올려 본 뒤 골라 보세요. 맞히면 설명이 나옵니다.