성장하는 과정 (피드백 루프) & 소스코드 유출 대응법

Plan (계획)
  → 목표를 설정하고 실행 방법을 계획한다
Do (실행)
  → 계획을 소규모로 실행한다
Check (확인)
  → 결과를 측정하고 기대와 비교한다
Act (조치)
  → 차이를 분석하고 개선 방안을 수립한다
  → 다음 Plan으로 이어진다

Observe (관찰)
  → 현재 상황을 있는 그대로 파악한다
Orient (지향)
  → 관찰한 정보를 기존 지식, 경험, 문화적 맥락과 결합하여 해석한다
Decide (결정)
  → 해석을 바탕으로 최적의 행동 방침을 결정한다
Act (행동)
  → 결정을 실행한다
  → 실행 결과가 다시 Observe 단계의 입력이 된다

목표 설정 (Goal)
  → 구체적이고 측정 가능한 목표를 잡는다
  → 예: "이번 분기에 TypeScript 타입 시스템 심화 학습"

실행 (Execute)
  → 매일 30분씩 학습하고, 실무에 적용한다
  → 소규모 프로젝트로 실험한다

측정 (Measure)
  → 학습 시간, 완료한 과제, 적용한 패턴 수를 기록한다
  → 정량적 지표가 중요하다

반성 (Reflect)
  → "무엇이 효과적이었나?"
  → "어디에서 막혔나?"
  → "왜 막혔나?"

조정 (Adjust)
  → 학습 방법을 변경한다
  → 목표를 수정한다
  → 새로운 사이클을 시작한다

Keep (유지할 것)
  → 잘 하고 있어서 계속할 것
  → 예: "데일리 스크럼에서 블로커를 빠르게 공유하는 문화"

Problem (문제점)
  → 개선이 필요한 것
  → 예: "코드 리뷰가 3일 이상 걸리는 경우가 많다"

Try (시도할 것)
  → 다음 스프린트에서 시도할 액션 아이템
  → 예: "리뷰 요청 후 24시간 내 첫 리뷰 규칙 도입"

Liked (좋았던 것)
  → 팀 분위기, 성취감 등 긍정적 경험
  → 예: "페어 프로그래밍으로 지식 공유가 잘 되었다"

Learned (배운 것)
  → 새로 알게 된 기술, 프로세스, 교훈
  → 예: "E2E 테스트의 중요성을 깨달았다"

Lacked (부족했던 것)
  → 리소스, 시간, 도구 등의 부족
  → 예: "QA 환경이 불안정해서 테스트가 지연되었다"

Longed for (바라는 것)
  → 앞으로 갖추고 싶은 것
  → 예: "스테이징 환경 자동 배포 파이프라인"

Start (시작할 것)
  → 새로 도입할 프랙티스
  → 예: "주간 기술 공유 세션"

Stop (중단할 것)
  → 비효율적이거나 해로운 관행
  → 예: "금요일 오후 배포"

Continue (계속할 것)
  → 효과가 입증된 관행
  → 예: "릴리스 노트 자동화"

// 나쁜 리뷰 코멘트
"이 변수 이름을 바꿔주세요"

// 좋은 리뷰 코멘트
"이 함수가 두 가지 책임을 가지고 있는 것 같습니다.
데이터 검증과 변환을 분리하면 테스트하기 쉬워질 것 같은데,
어떻게 생각하시나요?"

포스트모텀 구조:
1. 타임라인 (무엇이 일어났는가)
2. 영향 범위 (누구에게, 얼마나)
3. 근본 원인 분석 (왜 일어났는가)
4. 잘 된 점 (무엇이 피해를 줄였는가)
5. 개선점 (무엇이 부족했는가)
6. 액션 아이템 (구체적 + 담당자 + 기한)

Objective: 프론트엔드 성능 50% 개선
  KR1: LCP 2.5초 이하 달성 → 현재 3.1초 (진행률 60%)
  KR2: 번들 사이즈 30% 감소 → 현재 20% 감소 (진행률 67%)
  KR3: 코어 웹 바이탈 전 항목 Good → 2/3 달성 (진행률 67%)

리뷰 결과:
  → KR1은 이미지 최적화로 추가 개선 가능
  → KR2는 동적 임포트 확대 적용 필요
  → 전체 진행률은 순조로우나, 남은 기간 대비 집중 필요

1단계: 감정 분리
  → 피드백을 들었을 때 즉시 반응하지 않는다
  → "이 피드백은 나의 행동에 대한 것이지, 나라는 사람에 대한 것이 아니다"

2단계: 핵심 메시지 추출
  → 감정적 표현을 걷어내고 핵심만 본다
  → "코드가 엉망이다" → "이 코드의 가독성을 개선할 수 있다"

3단계: 구체적 질문
  → "어떤 부분이 특히 개선되면 좋을까요?"
  → "예시를 들어줄 수 있나요?"

4단계: 실행 계획 수립
  → 피드백을 구체적 액션 아이템으로 변환한다
  → 기한과 측정 기준을 정한다

5단계: 후속 공유
  → 개선 결과를 피드백 제공자와 공유한다
  → 피드백 루프를 완성한다

# 주간 성장 일지
## 날짜: YYYY-MM-DD ~ YYYY-MM-DD

### 이번 주 목표
- [ ] 목표 1
- [ ] 목표 2
- [ ] 목표 3

### 달성한 것
- 성과 1: 간략한 설명
- 성과 2: 간략한 설명

### 배운 것
- 기술적 학습: 무엇을 새로 배웠는가
- 소프트 스킬: 협업, 커뮤니케이션에서 배운 점

### 아쉬운 것
- 부족했던 점과 원인 분석
- 시간 관리, 집중도 등

### 다음 주 목표
- [ ] 목표 1 (우선순위 높음)
- [ ] 목표 2
- [ ] 목표 3

### 감사한 것
- 동료, 환경, 기회 등에 대한 감사

### 한 줄 회고
- "이번 주를 한 문장으로 요약하면?"

흔한 실수 패턴:
- .env 파일을 .gitignore에 추가하지 않음
- 프라이빗 레포를 퍼블릭으로 변경
- 포크한 레포에 내부 코드 커밋
- API 키, 데이터베이스 비밀번호를 하드코딩

공급망 공격 시나리오:
- 의존성 패키지에 악성 코드 삽입
- CI/CD 파이프라인 침입
- 개발 도구 플러그인을 통한 코드 탈취

즉시 격리 체크리스트:
- 유출된 저장소 또는 접근 경로 차단
- 관련 계정 비밀번호 즉시 변경
- VPN, SSH 키 등 접근 수단 폐기
- 유출 범위 초기 파악 (어떤 코드, 어떤 브랜치, 어떤 기간)

# 시크릿 회전 체크리스트
# 1. API 키 전체 재발급
# 2. 데이터베이스 비밀번호 변경
# 3. OAuth 클라이언트 시크릿 재생성
# 4. JWT 서명 키 교체
# 5. 암호화 키 로테이션
# 6. 서비스 계정 자격 증명 재발급
# 7. 환경 변수 전체 갱신

# BFG Repo-Cleaner를 사용한 민감 정보 제거
# 주의: 히스토리 재작성은 팀 전체에 영향을 미친다

# 특정 파일 제거 예시
bfg --delete-files credentials.json

# 텍스트 패턴 제거 예시
bfg --replace-text passwords.txt

# 정리 후 강제 푸시
git reflog expire --expire=now --all
git gc --prune=now --aggressive

영향 평가 항목:
- 유출된 코드의 범위와 민감도
- 포함된 비즈니스 로직의 가치
- 고객 데이터 노출 여부
- 보안 취약점 노출 여부
- 경쟁사에 미치는 영향
- 법적 의무사항 (개인정보 보호법 등)

영업비밀 3요건:
1. 비공지성: 공연히 알려져 있지 않을 것
2. 경제적 유용성: 독립적인 경제적 가치가 있을 것
3. 비밀 관리성: 합리적인 노력으로 비밀로 유지할 것

"비밀 관리성"이 법정에서 가장 자주 다투어지는 요건이다.
→ 접근 통제, 비밀 표시, NDA 등이 관리 노력의 증거가 된다.

가처분 신청 준비물:
1. 유출 사실의 증거 (스크린샷, 로그, 커밋 기록)
2. 영업비밀에 해당한다는 소명 자료
3. 비밀 관리 노력의 증거 (접근 통제 기록, NDA 등)
4. 긴급성의 소명 (사용이 계속되면 회복 불가능한 손해)
5. 담보금 (법원이 정한 금액)

증거 보전 방법:
- 웹페이지 캡처 (공증 포함)
- Git 로그 및 커밋 기록 백업
- 접근 로그 보존 (서버, VPN, 저장소)
- 이메일, 메시지 등 통신 기록 보존
- 디지털 포렌식 전문가 확보

# GitHub Actions에서 시크릿 스캐닝 설정 예시
name: Secret Scanning
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Run GitGuardian scan
        uses: GitGuardian/ggshield-action@v1
        env:
          GITGUARDIAN_API_KEY: GITGUARDIAN_API_KEY_PLACEHOLDER

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.5.0
    hooks:
      - id: detect-private-key
      - id: check-added-large-files
        args: ['--maxkb=500']

  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.4.0
    hooks:
      - id: detect-secrets
        args: ['--baseline', '.secrets.baseline']

# Git 커밋 서명 설정
git config --global commit.gpgsign true
git config --global user.signingkey YOUR_GPG_KEY_ID

# 서명된 커밋 확인
git log --show-signature -1

DLP 적용 영역:
- 이메일 첨부파일 검사
- 클라우드 스토리지 업로드 모니터링
- USB 등 외부 저장장치 사용 제한
- 클립보드 복사 제한 (소스코드 관련)
- 화면 캡처 모니터링

접근 권한 관리 체크리스트:
- 역할 기반 접근 제어(RBAC) 적용
- 저장소별 접근 권한 분리
- 읽기 전용 vs 쓰기 권한 구분
- 프로덕션 코드 접근을 필요한 인원으로 제한
- 정기적 접근 권한 감사 (분기별)
- 임시 접근 권한의 자동 만료 설정

퇴사 체크리스트 (보안 관련):
1. 모든 저장소 접근 권한 즉시 폐기
2. SSH 키 및 개인 액세스 토큰 삭제
3. VPN 계정 비활성화
4. 이메일 및 메시징 계정 비활성화
5. 회사 기기 반납 및 초기화
6. 클라우드 서비스 접근 권한 제거
7. CI/CD 파이프라인 접근 차단
8. 퇴사 면담에서 기밀 유지 의무 재확인

NDA에 포함되어야 할 핵심 조항:
- 보호 대상 정보의 구체적 정의
- 비밀 유지 의무 기간 (통상 2-5년)
- 위반 시 손해배상 조항
- 경업 금지 조항 (해당되는 경우)
- 퇴사 후에도 지속되는 의무 명시

소스코드 유출 포스트모텀 템플릿:

1. 사건 개요
   - 발견 일시, 유출 경로, 영향 범위

2. 타임라인
   - 유출 시점 (추정)
   - 발견 시점
   - 각 대응 단계별 시간

3. 기술적 분석
   - 어떤 코드가 유출되었는가
   - 포함된 시크릿 목록
   - 취약점 노출 여부

4. 대응 평가
   - 잘 된 점
   - 개선할 점
   - 대응 시간 분석

5. 근본 원인
   - 기술적 원인
   - 프로세스 원인
   - 문화적 원인

6. 액션 아이템
   - 단기 (1주 내): 시크릿 교체, 접근 차단
   - 중기 (1개월): 보안 도구 도입, 프로세스 개선
   - 장기 (분기): 보안 문화 강화, 교육 프로그램

Phase 1 - 즉시 (1주):
  - 모든 시크릿 로테이션 완료
  - 취약 접근 경로 차단
  - 임시 모니터링 강화

Phase 2 - 단기 (1개월):
  - 시크릿 스캐닝 도구 도입
  - pre-commit 훅 전사 적용
  - 접근 권한 전수 조사

Phase 3 - 중기 (분기):
  - DLP 시스템 도입
  - 보안 교육 프로그램 시작
  - 정기 보안 감사 프로세스 수립

Phase 4 - 장기 (연간):
  - 보안 문화 정착
  - 자동화된 보안 테스트 파이프라인
  - 레드팀/블루팀 훈련

커뮤니케이션 대상별 메시지:
경영진: 비즈니스 영향, 법적 리스크, 대응 현황
개발팀: 기술적 상세, 즉시 해야 할 일, 변경 사항
법무팀: 증거 현황, 법적 대응 옵션, 타임라인
고객: 영향 여부, 보호 조치, 후속 계획 (필요시)