// 개발자의 뇌에서 벌어지는 일

interface DeveloperBrain {
  currentStack: 'React';
  satisfactionLevel: number;    // 시간이 지나면서 하락
  noveltyBias: number;          // 새로운 것에 대한 편향 (항상 높음)
  grassIsGreenerEffect: number; // 남의 떡이 커 보이는 효과
}

// 시간에 따른 만족도 변화:
// Month 1: "React 최고! SPA 만세!" → 만족도 95%
// Month 6: "음 React도 좀 불편한 점이 있네" → 만족도 75%
// Month 12: "React 진짜 보일러플레이트 많다" → 만족도 55%
// Month 18: "Svelte 좋아 보이는데...?" → 만족도 40%
// Month 24: "Vue 3도 괜찮아 보이고..." → 만족도 30%
// Month 24 + Hacker News 글 하나: "리라이트 합시다!" → 만족도 0%

// 새 프레임워크를 도입하면:
// Month 1: "와 이거 진짜 혁명이다!" → 만족도 99%
// ... (위 사이클 반복)

2006: "jQuery 쓰세요. DOM 조작이 너무 쉬워요!"
      → 모든 프로젝트가 jQuery로 리라이트됨

2010: "Backbone.js가 MVC를 브라우저에 가져왔어요!"
      → jQuery 앱들이 Backbone으로 리라이트됨

2012: "AngularJS가 진짜 프레임워크에요. 양방향 바인딩!"
      → Backbone 앱들이 Angular로 리라이트됨

2015: "React가 Virtual DOM으로 성능을 해결했어요!"
      → Angular 앱들이 React로 리라이트됨

2016: "Angular 2는 완전히 새로 만들었어요! (하위호환 없음)"
      → AngularJS 팀: "??????"

2019: "Vue 3가 Composition API로..."
      → 일부가 React에서 Vue로 리라이트 시도

2020: "Svelte는 컴파일러예요! 런타임이 없어요!"
      → 일부가 React에서 Svelte로 리라이트 시도

2021: "Next.js가 풀스택 프레임워크의 미래에요!"
      → React 앱들이 Next.js로 리라이트됨

2023: "Next.js App Router가 패러다임을 바꿨어요!"
      → Next.js Pages Router 앱들이 App Router로 리라이트됨

2024: "Astro가 아일랜드 아키텍처로..."
      → 또 리라이트?

2025: "React Server Components가 진짜 미래에요!"
      → 아직 이전 리라이트도 안 끝났는데?

2012: Grunt → "태스크 러너의 시대!"
2014: Gulp → "스트림 기반이 더 빠르다!"
2015: Webpack → "번들러가 답이다!"
2018: Parcel → "제로 설정이 미래다!"
2020: Snowpack → "ESM 네이티브가 미래다!"
2021: Vite → "Snowpack보다 이게 더 빠르다!"
2022: Turbopack → "Rust로 짰으니까 더 빠르다!"
2023: Rspack → "Webpack 호환이면서 Rust니까..."
2024: Farm → "진짜 이번엔..."

// 개발자: (webpack.config.js를 세 번째 리라이트하는 중)
// "이번에는 설정이 간단하다고 했잖아..."
// (vite.config.ts 100줄 작성 중)

// 리라이트 비용 계산기

interface RewriteCost {
  // 직접 비용 (눈에 보이는 것)
  developerHours: number;
  opportunityCost: number;  // 리라이트하는 동안 못 만드는 기능
  testingHours: number;     // 전체 QA 다시 해야 함
  migrationHours: number;   // 데이터 마이그레이션

  // 간접 비용 (눈에 안 보이는 것)
  bugIntroduction: number;  // 리라이트 과정에서 생기는 새 버그
  knowledgeLoss: number;    // 기존 코드에 녹아있던 비즈니스 로직 유실
  teamMorale: number;       // "또 리라이트?" 에 의한 사기 저하
  userDisruption: number;   // 리라이트 중 기능 프리즈로 인한 사용자 불만
}

function calculateRewriteCost(project: Project): RewriteCost {
  // 낙관적 추정 (리라이트 주장자가 제시하는 숫자)
  const optimistic = {
    developerHours: 480,     // "2명이 3개월이면 돼요"
    testingHours: 80,        // "테스트 코드도 같이 옮기니까 금방이에요"
    bugIntroduction: 5,      // "아키텍처가 좋으니까 버그도 적을 거예요"
  };

  // 현실적 추정 (실제로 걸리는 시간)
  const realistic = {
    developerHours: 1920,    // 4명이 6개월 (2배가 아니라 4배)
    testingHours: 480,       // QA 전체 사이클 2번 (회귀 테스트 포함)
    bugIntroduction: 47,     // 리라이트 과정에서 새로운 버그 대량 발생
  };

  // 실제 걸린 시간은 낙관적 추정의 3-5배가 국룰
  return realistic;
}

// "이 코드 왜 이렇게 되어있지?" → 비즈니스 로직의 유실

// 리라이트 전 코드:
function calculateDiscount(order: Order): number {
  let discount = 0;

  // 2019년 프로모션 이벤트 때 추가된 로직
  // 당시 마케팅팀 요청으로 VIP 고객에게 추가 할인
  if (order.customer.isVIP && order.total > 100000) {
    discount += 0.05;
  }

  // 2020년 법률 변경으로 인한 세금 계산 수정
  // 국세청 가이드라인 제2020-15호 참고
  if (order.region === 'domestic' && order.includesTax) {
    discount = Math.min(discount, 0.10); // 세금 포함 상품은 최대 10% 할인
  }

  // 2021년 버그 수정: 음수 할인 방지
  // JIRA-4521 참고 (고객이 돈을 더 내는 버그였음)
  discount = Math.max(0, discount);

  return discount;
}

// 리라이트 후 코드:
function calculateDiscount(order: Order): number {
  // "깔끔하게 다시 짰습니다!"
  return order.customer.isVIP ? 0.05 : 0;
}

// 결과:
// - 세금 관련 로직 유실 → 법적 문제 가능
// - 음수 할인 방지 로직 유실 → 같은 버그 재발
// - 지역별 할인 제한 유실 → 과도한 할인 발생
// - 3년간의 엣지 케이스 처리 경험 전부 증발

// "깔끔한 코드" ≠ "올바른 코드"
// 레거시 코드가 지저분한 데는 이유가 있음

// 새 기술 도입 전 물어볼 질문 7가지

interface TechAdoptionChecklist {
  // 1. 현재 기술의 문제가 명확한가?
  currentPainPoints: string[];
  // "그냥 좀 불편함" ← 이건 리라이트 근거가 안 됨
  // "메모리 릭으로 매주 서버 재시작" ← 이건 근거가 됨

  // 2. 새 기술이 그 문제를 해결하는가?
  newTechSolvesProblems: boolean;
  // "DX가 좋아요" ← 이건 근거가 약함
  // "빌드 시간이 10분에서 30초로 줄어듦" ← 이건 근거가 됨

  // 3. 새 기술이 가져올 새로운 문제는?
  newProblems: string[];
  // 모든 기술은 트레이드오프. 해결하는 문제보다 새로 생기는 문제가
  // 더 크면 의미 없음.

  // 4. 팀이 새 기술을 학습할 여유가 있는가?
  teamLearningCapacity: boolean;
  // 마감 3개월 전에 새 프레임워크 도입 = 자살 행위

  // 5. 생태계가 충분히 성숙한가?
  ecosystemMaturity: 'bleeding-edge' | 'early-adopter' | 'early-majority' | 'mainstream';
  // bleeding-edge에서 프로덕션 서비스를 운영하면...
  // 스택오버플로우에 질문해도 답이 없음

  // 6. 점진적 마이그레이션이 가능한가?
  incrementalMigration: boolean;
  // 빅뱅 리라이트 = 실패 확률 70%
  // 점진적 마이그레이션 = 실패 확률 30%

  // 7. 3년 후에도 이 기술이 살아있을까?
  longevity: 'uncertain' | 'likely' | 'very-likely';
  // npm 패키지 3만 개 중 1년 후 유지보수되는 비율: 30% 미만
}

흥분도
  ^
  |     *
  |    * *        리라이트러가
  |   *   *       뛰어드는 시점
  |  *     *         ↓
  | *       *     *  *
  |*         *   * *   *
  |           * *       *  ← 실제로 안정적인 시점
  |            *         *     (여기서 도입하는 게 현명)
  |                       *****
  +--------------------------------→ 시간
      과대   환멸기  계몽기  안정기
      광고기

  과대광고기: "이거 쓰면 생산성 10배!!" → 트위터 바이럴
  환멸기: "이거 쓰면 안 되는 거 100가지..." → 블로그 포스트 폭증
  계몽기: "이런 상황에서는 유용함" → 현실적인 가이드 등장
  안정기: "그냥 쓰면 됨" → 스택오버플로우 답변 충분

// 리라이트를 정당화하는 조건들

const 리라이트_필요_신호 = {
  // 기술적 한계
  "프레임워크 EOL": "Angular.js는 더 이상 보안 패치가 안 나옴",
  "성능 한계": "현재 아키텍처로는 10만 동시접속을 처리 못 함",
  "보안 취약점": "의존성의 보안 패치가 더 이상 불가능",

  // 비즈니스 요구
  "근본적 요구사항 변경": "SPA였던 게 SSR이 필요해짐",
  "규모 변화": "5명 팀 코드를 50명이 개발해야 하는 상황",

  // 인력 요인
  "채용 불가": "CoffeeScript 개발자를 더 이상 못 구함",
  "온보딩 비용": "새 팀원이 코드 이해하는 데 6개월 걸림",
};

// 리라이트가 합리적이지 않은 신호
const 리라이트_불필요_신호 = {
  "DX가 별로임": "불편하지만 동작은 함",
  "코드가 못생김": "못생겨도 올바르게 동작하면 됨",
  "기술이 오래됨": "오래됐지만 안정적이면 장점임",
  "남들 다 쓴다": "남들이 뭘 쓰든 내 프로젝트와는 무관",
  "이력서에 쓰고 싶어서": "... 솔직한 건 좋지만 회사 돈으로 하면 안 됨",
  "새 거 배우고 싶어서": "사이드 프로젝트에서 하셈",
};

// 빅뱅 리라이트 vs 점진적 마이그레이션

// 빅뱅 리라이트 (위험)
// 1. 새 코드베이스 생성
// 2. 기존 기능 전부 재구현
// 3. 특정 날짜에 한번에 전환
// 위험: 전환일에 폭발 가능성 높음

// 점진적 마이그레이션 (안전)
// Strangler Fig Pattern 적용

// Phase 1: 새 기능만 새 기술로
// /new-feature → New Framework
// /* → Legacy Framework

// Phase 2: 기존 기능을 하나씩 이전
// /new-feature → New Framework
// /users → New Framework (마이그레이션 완료)
// /* → Legacy Framework

// Phase 3: 레거시 코드 점점 줄어듦
// /settings → Legacy Framework (마지막 남은 레거시)
// /* → New Framework

// Phase 4: 완전 전환
// /* → New Framework
// Legacy Framework 제거

// 이 방법의 장점:
// - 언제든 멈출 수 있음 (예산 부족 시)
// - 문제 발생 시 영향 범위가 제한됨
// - 기존 서비스는 계속 운영됨
// - 팀이 새 기술을 점진적으로 학습할 수 있음

// 기술 FOMO 해소 전략

// 1. 현재 기술 스택을 깊이 파기
// "React 안다" → state 관리, 성능 최적화, 서버 컴포넌트, 컴파일러
// 넓이보다 깊이가 커리어에 훨씬 도움됨

// 2. 새 기술은 읽기/관망 모드로
// Hacker News 읽기 → 좋음
// 바로 프로덕션 적용 → 나쁨
// "알고 있되 쓰지 않는" 상태가 가장 이상적

// 3. "기술 레이더" 만들기
interface TechRadar {
  adopt: string[];     // 적극 사용: ["TypeScript", "React", "Next.js"]
  trial: string[];     // 시험적 사용: ["Bun", "RSC"]
  assess: string[];    // 평가 중: ["Solid.js", "Effect-TS"]
  hold: string[];      // 보류: ["Angular", "jQuery"]
}

// ThoughtWorks Tech Radar 처럼
// 기술을 4단계로 분류하고 분기마다 업데이트
// 충동적 도입 방지 + 체계적 기술 탐색

2015년의 진짜: React
2017년의 진짜: TypeScript
2020년의 진짜: Next.js
2023년의 진짜: ???
2026년의 진짜: ???

5년 후에 살아남은 게 진짜 "진짜"임.
나머지는 Hacker News의 한때의 추억.