AI 드리븐

지도 위치 : 2일차 · 구현과 검증 · 검증 | 이전: 13차시 검증 ① 코드·동작 점검 | 다음: 15차시 인프라 역할: 설정의 원칙 키워드 : 흔한 보안 사고 유형, 비밀값·개인정보 보호, 위반 차단 장치

이 차시를 다 읽으면

1. 흔한 보안 사고 일곱 가지 를 대고, 각각을 막는 법과 코드 없이 시험하는 법을 말할 수 있다.
2. 비밀값 을 유와 종차로 정의하고, 두지 않을 곳 다섯 군데와 이미 커밋했을 때 가장 먼저 할 일 을 말할 수 있다.
3. 개인정보 보호 원칙 다섯 가지를 클래스온에 적용할 수 있다.
4. 점검과 차단 을 구별하고, 차단 장치를 에이전트 · 커밋 · 자동 검사 세 단계에 배치할 수 있다.
5. 코드를 읽지 않고 할 수 있는 보안 행동 시험 네 가지 를 직접 수행할 수 있다.

---

0. 이 차시의 판별 축

이 차시가 답하는 질문은 "코드를 읽지 못하는 사람이 보안을 어떻게 지키는가" 입니다. 보안은 이 방식에서 가장 취약한 영역 입니다. AI가 만든 보안 구멍은 화면에 보이지 않고, 코드를 읽지 못하면 찾을 방법이 거의 없습니다. 그래서 답은 축 2의 오른쪽, 차단 입니다. 점검은 놓칠 수 있지만, 차단은 내가 몰라도 작동합니다. 앞에서 배운 강제 사다리(2차시)를 12차시의 데이터에 이어 이번에는 보안에 적용합니다.

---

1. 흔한 보안 사고 유형

보안 사고 — [서비스 사고]인데, [ 허락받지 않은 사람이 데이터를 보거나, 바꾸거나, 내 권한으로 행동하게 된다 ]는 점에서 기능이 틀리게 동작하는 일반 버그와 구별된다.

보안 사고 대부분은 고급 해킹이 아니라 흔하고 이름이 붙어 있는 실수 에서 납니다. AI는 "일단 돌아가게" 만드는 쪽으로 기울어 있어서, 아래 실수를 쉽게 만듭니다.

⚠️ 마지막 유형은 AI 시대에 새로 생긴 위험입니다. 그래서 README 9.4의 위험 신호에 "새 패키지를 추가했다" 가 들어 있습니다.

---

2. ⭐ 비밀값 보호

2.1 정의

비밀값 (Secret) — [설정값]인데, [ 노출되면 남이 내 권한으로 행동할 수 있다 ]는 점에서 노출되어도 괜찮은 일반 설정값(서버 주소, 공개 키)과 구별된다.

예: 결제 비밀 키, DB 비밀번호, 외부 API 키, 로그인 증표 서명 키.

2.2 두지 않을 곳과 둘 곳

원칙: 비밀값은 코드에도, Git에도, 화면에도, 로그에도, AI와의 대화에도 두지 않는다.

로컬:   .env 파일 (Git 제외) ← .env.example에는 이름만 (9차시)
배포:   배포 플랫폼의 비밀값 설정 또는 비밀값 관리 서비스 (15 · 21차시)
코드:   process.env.PG_SECRET_KEY 처럼 이름으로만 참조

🔍 읽는 포인트 : 첫 줄의 다섯 곳 이 금지 목록이고, 코드에는 이름만 나옵니다. 값이 보이면 사고입니다.

⚠️ AI에게 키를 보여 주지 마세요. 에이전트는 파일을 읽을 수 있으므로 .env를 읽으면 그 내용이 대화에 들어갑니다. 설정을 확인하고 싶으면 값 대신 "PG_SECRET_KEY라는 이름의 환경변수가 설정돼 있는지만 확인해줘" 라고 요청합니다(README 9.2의 "비밀값 입력은 내가 직접").

2.3 이미 커밋했다면 — 되돌릴 수 없다

0절 축 3의 오른쪽입니다. 유출된 값은 회수할 수 없으므로, 그 값을 쓸모없게 만드는 것 이 먼저입니다.

2.4 반례

---

3. 개인정보 보호

개인정보 — [데이터]인데, [ 살아 있는 특정 개인을 알아볼 수 있게 한다 ]는 점에서 클래스 제목 · 가격 같은 서비스 데이터와 구별된다. 클래스온에서는 수강생 이름 · 연락처 · 이메일이 해당합니다.

한국에서 서비스한다면 개인정보 보호법이 적용됩니다. 실제 출시 전에는 개인정보 처리방침과 법적 의무를 별도로 확인하세요. 개인정보를 대량으로 다루는 단계라면 처리 흐름을 전문가에게 한 번 확인받는 것을 권합니다(README 9.6).

---

4. ⭐ 점검과 차단

4.1 정의와 경계

차단 장치 — [보안 장치]인데, [ 위반이 일어나기 전에 시스템이 그 행동 자체를 거부한다 ]는 점에서 일어난 위반을 나중에 찾아내는 점검과 구별된다.

4.2 세 단계에 배치하기

① 에이전트 단계 — 권한으로 비밀 파일 접근 차단

// .claude/settings.json
{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

🔍 읽는 포인트 : deny 목록에 .env가 있는지 만 보면 됩니다. 있으면 에이전트는 그 파일을 읽으려 해도 거부당합니다.

② 커밋 단계 — 비밀값 스캔 (18차시)

• gitleaks 같은 도구를 커밋 직전 검사로 실행해, 키 모양의 문자열이 있으면 커밋 자체를 거부

③ 자동 검사 단계 — 의존성 · 코드 스캔 (19차시)

• 변경 요청(PR)마다 취약점 스캔, 통과하지 못하면 병합 불가

④ 저장소 설정 — 남이 대신 감시

• GitHub 저장소의 Settings → Code security에서 비밀값 스캔(secret scanning)과 Dependabot 알림을 켜면, 코드를 읽지 않아도 GitHub가 감시하고 알려 줍니다. (메뉴 위치는 바뀔 수 있으니 공식 문서 확인)

앞으로 다시 만납니다 — ②는 18차시에서 커밋 전 검사로, ③은 19차시에서 자동 검사 관문으로 실제로 설치합니다. 이 차시에서는 어느 단계에 무엇을 둘지 만 정합니다.

4.3 점검 역할 — 그래도 찾아야 하는 것

차단은 알려진 모양 만 막습니다. 인가 누락처럼 모양이 일정하지 않은 문제는 점검으로 찾습니다.

# .claude/agents/security-reviewer.md
tools: Read, Grep, Glob
점검: 1절 표의 일곱 유형 전부. 특히 하드코딩된 키 모양 문자열, 인가 확인 없는 조회,
      문자열로 조립한 SQL, 로그에 찍히는 개인정보, 새로 추가된 패키지의 실재 여부.
보고: [심각도 | 파일:줄 | 유형 | 공격 시나리오 한 줄 | 수정 제안]

🔍 읽는 포인트 : tools:에 Write · Edit가 없음 = 읽기 전용. 13차시의 리뷰어와 같은 원칙입니다.

공격자 역할 시키기 — 점검을 "읽고 판단"에서 "시도하고 결과 보기"로 바꾸는 방법입니다.

너는 이 서비스를 공격하려는 사람이다. 방금 만든 기능에서 돈을 덜 내거나,
남의 정보를 보거나, 데이터를 망가뜨릴 방법을 3가지 찾아줘.
각각 로컬에서 실제로 시도해 보고 [방법 | 시도한 명령 | 결과 | 막혔나?] 표로 보고해줘.

💡 비유는 마지막에 — 점검은 경비원의 순찰 , 차단은 잠긴 문 입니다. 순찰은 놓칠 수 있지만 잠긴 문은 경비원이 졸아도 잠겨 있습니다. 둘 다 두되, 먼저 문을 잠급니다.

---

5. 클래스온에 적용하면 — 위험 지도

---

6. 실습 — 맡기고 검수하기

지시

1. .claude/settings.json에 4.2의 deny 규칙을 넣고, 설정 파일의 변경 전후 차이를 보여줘.
   그다음 .env를 읽으려고 시도해 보고, 거부된 메시지 원문을 붙여줘.
2. security-reviewer 역할로 1절의 일곱 유형을 점검하고 [심각도 | 파일:줄 | 유형 | 공격 시나리오] 표로 보고해줘.
3. 지금까지 추가된 패키지 전체를 [이름 | 이유 | 공식 페이지 주소] 표로 보여줘.
4. 공격자 역할로 4.3의 지시를 수행해줘.
키 값은 어떤 경우에도 출력하지 말고, 환경변수는 "이름이 설정돼 있는지"만 확인해.

받을 증거

• deny 설정 변경 전후 차이와 .env 읽기 거부 메시지 원문
• 점검 표, 패키지 표(공식 주소 포함), 공격 시도 표와 각 시도의 실행 출력

내가 직접 확인할 것

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 14차시 노트만 근거로 6문제를 내줘. 비전공자 기준으로.
"흔한 보안 사고 유형", "비밀값을 커밋했을 때의 순서(되돌릴 수 없음)", "점검과 차단의 차이", "코드 없이 하는 보안 행동 시험"은 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.