// 이 파일이 하는 일: "기술 리더십과 ADR — 결정을 설계하고 기록하는 사람" 코스 — 특급 과정의
// 마무리. 연차가 쌓이면 산출물이 코드에서 '결정'으로 바뀐다는 관점 전환에서 출발해,
// 좋은 결정의 조건, ADR(아키텍처 결정 기록), 설계 문서와 리뷰, 트레이드오프 커뮤니케이션,
// 기술 부채의 리더십, 주니어 성장 사다리, 그리고 수료 프로젝트까지 8개 섹션으로 안내한다.
// 프레이밍은 "Lv4 전 과정이 사실 결정 연습이었다" — CAP, 푸시/풀, 서비스 분리 같은 앞선
// 강좌의 선택들을 이번엔 '기록하고 설득하는 기술'로 다시 본다.
// 학습 포인트: API 호출이 없는 '내용 고정' 페이지다. 스타일은 styles/global.css의
// 가이드 전용 클래스(step-card, code-block, tip 등)를 재사용하고 색은 var(--*)만 쓴다(하드코딩 금지).
// 예제 코드는 JSX 중괄호/백틱 충돌을 피하려고 파일 상단의 백틱 문자열 상수로 정의한다.

import { Link } from 'react-router-dom';

// ── 예제 코드 상수들 ──

const CODE_OUTPUT_SHIFT = `주니어 ──────────── 미들 ──────────── 시니어/리드
"내 코드"           "우리 모듈"          "팀의 결정"

산출물: PR, 기능      산출물: 설계, 리뷰     산출물: 결정, 문서, 사람
성공지표: 머지 수      성공지표: 장애 감소     성공지표: 팀 전체의 속도

핵심 전환: 연차가 쌓일수록 '내가 짠 코드'보다
'내가 내린(그리고 기록한) 결정'이 조직에 더 오래 남는다.
결정은 코드보다 수명이 길다 — 코드는 리팩터링되지만,
"왜 이렇게 갔는가"는 3년 뒤 신규 입사자의 첫 질문이 된다.`;

const CODE_DOORS = `결정을 내리기 전에 먼저 물을 것: "이 문은 몇 방향인가?"

양방향 문 (two-way door)          일방향 문 (one-way door)
─────────────────────           ─────────────────────
되돌리기 쉽다                     되돌리기 어렵다/비싸다
예: 라이브러리 선택,              예: DB 엔진 교체, 공개 API 계약,
   내부 함수 시그니처,               데이터 스키마의 대규모 변경,
   feature flag 뒤의 실험            서비스 경계(모노리스→MSA)

→ 빠르게 결정하고 시도한다         → 문서 쓰고, 대안 비교하고,
  틀리면 되돌리면 된다               리뷰 받고, 천천히 통과한다

흔한 실수: 모든 결정을 일방향 문처럼 다뤄 팀이 느려지거나,
일방향 문을 양방향 문처럼 통과해 3년짜리 부채를 만드는 것.`;

const CODE_ADR = `# ADR-007: 실시간 시세 배포를 Valkey Pub/Sub으로 결정

## 상태 (Status)
승인됨 (2026-05-02)

## 맥락 (Context)
- 시세 틱은 초당 수백 건, 구독자(SSE 커넥션)는 수천 개까지 예상.
- 유실 허용: 틱 하나를 놓쳐도 다음 틱이 0.5초 안에 온다(최신값만 의미 있음).
- 이미 감사 이벤트용으로 Kafka가, 캐시용으로 Valkey가 스택에 존재.

## 결정 (Decision)
시세 fan-out은 Valkey Pub/Sub 채널(market.ticks)로 나른다.
market 서비스가 발행하고, 각 인스턴스의 스트림 서비스가 구독해
SSE로 클라이언트에 흘린다. 같은 데이터를 Kafka로 중복 발행하지 않는다.

## 기각한 대안 (Alternatives Considered)
1. Kafka 토픽으로 배포
   - 장점: 재생(replay) 가능, 유실 없음, 이미 운영 중.
   - 기각 이유: 시세는 재생이 무의미(옛 가격은 가치 없음)하고,
     컨슈머 그룹 리밸런싱 지연이 실시간성에 불리. 과잉 보장.
2. 서비스 간 직접 HTTP 콜백
   - 장점: 인프라 추가 없음.
   - 기각 이유: 구독자 수만큼 연결 관리 코드가 늘고,
     인스턴스 증설 시 라우팅이 지옥이 됨.

## 결과 (Consequences)
- (+) 지연 최소, 코드 단순, 인프라 재사용.
- (-) Valkey 재시작 시 그 순간의 틱은 유실 — 감내하기로 함.
- (-) "유실 감내"라는 전제가 깨지는 데이터(주문 체결 등)에는
  이 채널을 절대 재사용하지 말 것. → 그건 Kafka로.`;

const CODE_SUPERSEDE = `# ADR은 불변 기록 — 뒤집을 때의 규칙

잘못된 방법:
  ADR-007 파일을 열어 내용을 고쳐 쓴다  ✗
  → "그때 왜 그렇게 판단했는지"라는 역사가 증발한다.

올바른 방법:
  1. 새 파일 ADR-019를 쓴다: "시세 배포를 XXX로 변경"
  2. ADR-019의 맥락에 "무엇이 달라져서 재검토하는지"를 적는다
     (예: 구독자 10배 증가, 유실 허용 전제가 깨짐)
  3. ADR-007의 상태만 바꾼다:
     승인됨 → 대체됨 (Superseded by ADR-019)

이렇게 하면 저장소에 '결정의 지층'이 쌓인다.
git log가 코드의 역사이듯, ADR 디렉터리는 판단의 역사다.`;

const CODE_DESIGN_DOC = `# 디자인 독(Design Doc) 표준 골격

## 1. 배경 (Background)
  왜 지금 이 문제인가. 읽는 사람이 사전지식 없이도 따라오게.

## 2. 목표 / 비목표 (Goals / Non-Goals)
  목표: 이번에 해결할 것.
  비목표: 일부러 안 하는 것 ← 여기가 진짜 중요.
  "다국어 지원은 이번 범위에서 제외한다"라고 적어 두면
  리뷰가 산으로 가는 걸 막고, 나중의 오해도 막는다.

## 3. 제안 (Proposed Design)
  아키텍처 다이어그램, 데이터 흐름, API 계약, 스키마.

## 4. 대안 (Alternatives)
  최소 1~2개. "대안이 없다"는 대개 "안 찾아봤다"는 뜻.

## 5. 리스크와 완화 (Risks & Mitigations)
  실패 모드, 마이그레이션 경로, 롤백 계획.

리뷰의 목적: 승인 도장이 아니라 '결함을 싸게 찾는 것'.
코드가 되기 전의 결함은 문장 몇 줄 고치면 끝나지만,
배포된 뒤의 결함은 장애 대응 + 마이그레이션 비용이 된다.`;

const CODE_TRANSLATE = `상황: 경영진에게 "리프레시 토큰 저장 방식 개선"을 설득해야 한다

개발자의 언어 (전달 실패)
  "localStorage 대신 httpOnly 쿠키로 옮기고
   토큰 로테이션을 도입해야 합니다. XSS에 취약해서요."
  → 듣는 사람: (XSS가 뭐지... 급한 건가?)

리스크·비용·시간의 언어 (전달 성공)
  "지금 구조에선 악성 스크립트 하나가 유출되면
   고객 계정 전체가 탈취될 수 있습니다.        ← 리스크
   금융 데이터 서비스라 사고 시 계약 해지 사유가 되고요.
   고치는 데 개발 2주, 사용자 영향은 재로그인 1회입니다.  ← 비용·시간
   출시 전인 지금이 가장 싸게 고칠 수 있는 시점입니다."

번역 공식: 기술 용어 → 그것이 실현됐을 때의
사업적 결과(돈, 신뢰, 시간)로 바꿔 말한다.`;

const CODE_DEBT = `기술 부채 = 대출. 문제는 빚 자체가 아니라 '이자율 관리'다.

의도적 부채 (전략적 대출)              무지성 부채 (카드 돌려막기)
──────────────────────              ──────────────────────
"출시가 8월 말이라 지금은               "그냥 몰라서 / 귀찮아서
 ddl-auto: update로 가고,               테스트 없이 복붙했다.
 Flyway는 출시 후 1순위로 도입한다"      기록도 없다."

- 무엇을 미뤘는지 안다                 - 미뤘다는 인식조차 없다
- 갚을 시점이 로드맵에 있다             - 어느 날 장애로 청구서가 온다
- ADR/이슈로 기록돼 있다               - 원인 추적에 며칠을 쓴다

부채 상환을 로드맵에 올리는 법 — 사업 언어로 이자 증명:
  "이 모듈 때문에 기능 하나당 이틀씩 더 듭니다.
   분기당 개발 3주치가 이자로 나가는 셈입니다.
   2주 투자하면 이 이자가 사라집니다."`;

const CODE_LADDER = `주니어 성장 사다리 — 관찰에서 소유로

1단계  코드 리뷰 받기        → 피드백을 '받는' 훈련
2단계  코드 리뷰 하기        → 남의 코드에서 의도를 읽는 훈련
3단계  온콜 섀도잉           → 장애 대응을 '옆에서' 경험 (책임 없이)
4단계  설계 리뷰 참관        → 결정이 만들어지는 현장을 구경
5단계  작은 설계 소유        → 디자인 독을 직접 쓰고 리뷰 받기
6단계  온콜 주인공 + 백업     → 책임을 지되, 뒤에 안전망이 있게

위임의 기술: 답이 아니라 '결정 프레임'을 준다.
  나쁜 위임: "그건 network-first로 하세요." (답 제공 → 성장 0)
  좋은 위임: "이 데이터는 유실돼도 되나요? 최신성과 정확성 중
             뭐가 더 중요하죠? 그 답에 따라 전략이 갈립니다."
             (프레임 제공 → 다음엔 스스로 결정한다)`;

const CODE_PORTFOLIO = `수료 프로젝트: 나의 아키텍처 포트폴리오

① ADR 묶음 (Lv4 전 과정 소급 정리)
   - 최소 3편: 시세 배포 채널, 서비스 경계, 캐시 전략 등
   - 각 ADR에 기각한 대안 2개 이상 + 기각 이유 필수
   - 형식: 맥락 → 결정 → 대안 → 결과

② 가상 신규 서비스 디자인 독 1편
   - 예: "알림 집계 서비스", "백테스트 잡 러너"
   - 배경 / 목표·비목표 / 제안 / 대안 / 리스크 골격 준수
   - 동료(또는 멘토)에게 리뷰 세션 1회 — 코멘트를 문서에 반영

③ 다음 성장 방향 한 쪽짜리 회고
   - 도메인 깊이 vs 폭? IC 트랙 vs 리드 트랙?
   - 정답 없음. 단, '왜'를 스스로 설명할 수 있을 것.

제출물은 전부 markdown — 코드 한 줄 없는 과제지만,
이것이 시니어의 산출물이 어떤 모양인지에 대한 첫 경험이다.`;

// ── 이 페이지 안에서만 쓰는 작은 부품들 ──
// 학습 포인트: 같은 모양이 반복되면 컴포넌트로 뽑는다. props만 바꿔 재사용.
function Section({ n, title, sub, children }) {
  return (
    <section className="step-card" id={`sec-${n}`}>
      <div className="step-head">
        <span className="step-num">{n}</span>
        <div>
          <h3>{title}</h3>
          {sub && <span className="step-sub">{sub}</span>}
        </div>
      </div>
      <div className="step-body">{children}</div>
    </section>
  );
}

function Code({ children }) {
  return <pre className="code-block"><code>{children}</code></pre>;
}

const SECTIONS = [
  { n: 1, label: '코드에서 결정으로' },
  { n: 2, label: '좋은 결정의 조건' },
  { n: 3, label: 'ADR' },
  { n: 4, label: '설계 문서와 리뷰' },
  { n: 5, label: '트레이드오프 설득' },
  { n: 6, label: '부채의 리더십' },
  { n: 7, label: '주니어 키우기' },
  { n: 8, label: '수료 프로젝트' },
];

export default function Lv4TechLeadershipAdrPage() {
  return (
    <div>
      {/* 히어로: 이 코스가 어디서 출발해 어디까지 가는지 */}
      <div className="hero">
        <div className="eyebrow">Course · 특급 과정</div>
        <h1>🧭 기술 리더십과 ADR<br />— 결정을 설계하고 기록하는 사람</h1>
        <p>
          특급 과정의 마무리입니다. 지금까지 CAP과 파티셔닝, 푸시와 풀, 서비스를 쪼갤까 말까를
          배웠다면 — 사실 그 전부가 <strong>결정 연습</strong>이었어요. 이번 코스에선 그 결정을{' '}
          <strong>기록하는 법(ADR)</strong>, <strong>검증받는 법(설계 리뷰)</strong>,{' '}
          <strong>설득하는 법(트레이드오프 커뮤니케이션)</strong>을 익힙니다. 코드를 잘 짜는
          개발자에서, 팀을 움직이는 개발자로 넘어가는 마지막 다리예요.
        </p>
        <div className="chip-row">
          <span className="chip">예상 소요 70분</span>
          <span className="chip">실습: traderbox 결정 1개를 정식 ADR로</span>
          <span className="chip">대상: 대규모 시스템을 설계하는 실무 개발자</span>
        </div>
      </div>

      {/* 섹션 바로가기 */}
      <nav className="pill-nav">
        {SECTIONS.map((s) => (
          <a key={s.n} href={`#sec-${s.n}`}>
            <b>{s.n}</b>
            {s.label}
          </a>
        ))}
      </nav>

      <Section n={1} title="시니어의 일 — 코드에서 결정으로" sub="산출물이 바뀌는 순간을 알아차리기">
        <p>
          주니어 시절의 산출물은 명확해요. <strong>머지된 PR</strong>이죠. 그런데 연차가 쌓이면
          이상한 일이 생깁니다. 코드는 예전보다 덜 짜는데, 팀에 미치는 영향은 더 커져요.
          산출물이 코드에서 <strong>결정과 문서와 사람</strong>으로 바뀌기 때문입니다.
          "이 데이터는 어느 채널로 나를까", "이 서비스는 쪼갤까", "이 부채는 언제 갚을까" —
          이런 결정 하나가 주니어 다섯 명의 한 달을 좌우해요.
        </p>
        <Code>{CODE_OUTPUT_SHIFT}</Code>
        <p>
          여기서 흔한 오해 하나를 걷어냅시다. <strong>기술 리더십은 관리직이 아니에요.</strong>{' '}
          사람을 평가하고 일정을 관리하는 매니저 트랙과 별개로, 코드와 설계로 영향력을 넓히는{' '}
          <strong>IC(Individual Contributor) 트랙</strong>이 있습니다. 스태프·프린시펄 엔지니어가
          그 길이에요. 팀장이 되지 않아도, 좋은 결정을 내리고 그것을 팀이 따라올 수 있게 만드는
          사람은 이미 기술 리더입니다.
        </p>
        <p>
          그리고 눈치채셨겠지만 — <strong>Lv4 전 과정이 사실 결정 연습이었어요.</strong> CP를
          택할까 AP를 택할까(일관성 강좌), 푸시로 나를까 풀로 나를까(실시간 데이터 강좌),
          서비스를 쪼갤까 말까(MSA 강좌). 전부 "정답이 뭐냐"가 아니라 "이 제약에선 뭐가
          덜 나쁘냐"를 묻는 문제였죠. 이번 코스는 그 근육에 <strong>기록과 설득</strong>이라는
          마지막 두 동작을 붙입니다.
        </p>
        <div className="tip">
          <b>자기 점검</b> 최근 한 달간 내가 한 일 중, 코드가 아닌 산출물(리뷰 코멘트, 설계 제안,
          누군가의 질문에 답한 문서)이 몇 개였는지 세어 보세요. 0개라면 아직 기회를 못 만난 것이고,
          여러 개라면 — 이미 이 코스가 말하는 전환이 시작된 겁니다.
        </div>
      </Section>

      <Section n={2} title="좋은 기술 결정의 조건" sub="정답 찾기가 아니라 제약 아래의 선택">
        <p>
          학교 시험엔 정답이 있지만 아키텍처엔 없어요. 있는 건 <strong>제약</strong>(시간, 인원,
          트래픽, 돈)과 그 아래에서의 <strong>트레이드오프 선택</strong>뿐입니다. "Kafka가
          Valkey Pub/Sub보다 좋은가요?"는 성립하지 않는 질문이에요. "유실을 감내할 수 있고
          지연이 생명인 시세 틱에는 어느 쪽이 덜 나쁜가요?"가 성립하는 질문이죠.
        </p>
        <p>
          그렇다면 모든 결정에 똑같은 신중함을 쏟아야 할까요? 아니요. 결정을 나누는 유용한
          기준이 <strong>"이 문은 몇 방향인가"</strong>입니다.
        </p>
        <Code>{CODE_DOORS}</Code>
        <p>
          <strong>양방향 문</strong>(되돌리기 쉬운 결정)은 빠르게 통과하세요. 라이브러리 하나
          고르는 데 회의 세 번을 하는 팀은 그 자체로 병목입니다. 반대로 <strong>일방향 문</strong>
          (되돌리기 어려운 결정 — DB 교체, 공개 API 계약, 서비스 경계)은 문서를 쓰고 대안을
          비교하고 리뷰를 받으며 천천히 통과해야 해요. 결정의 무게에 맞는 절차를 고르는 것,
          그게 시니어의 감각입니다.
        </p>
        <p>
          하나 더 — <strong>'지금 규모'와 '3년 뒤 규모'를 분리해서 판단하세요.</strong> "나중에
          사용자가 100만이 되면 필요할 테니 지금 샤딩을 넣자"는 과잉 설계의 전형이에요. 3년 뒤
          규모는 3년 뒤의 팀이, 3년치의 데이터를 갖고 더 잘 결정합니다. 지금 할 일은 미래의
          확장을 <strong>막지 않는 구조</strong>(양방향 문으로 남겨 두기)까지지, 미래를 미리
          구현하는 게 아니에요.
        </p>
        <div className="tip">
          <b>우리 코드베이스에서</b> traderbox가 Flyway 없이 <span className="icode">ddl-auto:
          update</span>로 달리는 건 골격 단계의 <strong>의도된 선택</strong>이에요(빠른 반복이
          우선). 다만 이건 일방향 문에 가까워지는 중입니다 — 운영 데이터가 쌓일수록 마이그레이션
          도구 없는 스키마 변경의 위험이 커지니까요. "언제 이 결정을 재검토할 것인가"까지 정해
          두는 것이 좋은 결정의 마지막 조각입니다.
        </div>
      </Section>

      <Section n={3} title="ADR — 아키텍처 결정 기록" sub="결정보다 '기각한 대안'이 진짜 가치다">
        <p>
          <strong>ADR(Architecture Decision Record)</strong>은 중요한 기술 결정 하나를 짧은
          문서 하나로 남기는 관행이에요. 구조는 단순합니다. <strong>맥락(Context)</strong> —
          어떤 제약과 상황이었나 → <strong>결정(Decision)</strong> — 무엇을 하기로 했나 →{' '}
          <strong>결과(Consequences)</strong> — 이 선택으로 무엇을 얻고 무엇을 포기했나.
          여기에 <strong>기각한 대안과 그 이유</strong>를 더하면 완성이에요.
        </p>
        <p>
          traderbox의 실제 결정 하나를 ADR로 옮겨 볼게요. "시세는 Valkey Pub/Sub, 감사 이벤트는
          Kafka, 같은 데이터를 두 채널로 흘리지 않는다" — 지금은 컨벤션 문서에 한 줄로만 남아
          있는 이 암묵적 결정을, 정식 기록으로 소급해 보면 이렇습니다.
        </p>
        <Code>{CODE_ADR}</Code>
        <p>
          주목할 곳은 결정 부분이 아니라 <strong>기각한 대안</strong>이에요. "Kafka도 검토했지만
          시세는 재생이 무의미해서 기각했다"는 한 줄이, 3년 뒤 "왜 이거 Kafka로 안 했어요?"라고
          물을 신규 입사자의 하루를 아껴 줍니다. 결정만 적힌 문서는 결과물이고, 대안까지 적힌
          문서는 <strong>사고 과정의 재생 장치</strong>예요. 같은 논쟁을 반복하지 않게 해 주죠.
        </p>
        <p>
          그리고 ADR엔 중요한 규칙이 하나 있어요. <strong>불변 기록</strong>이라는 것.
          상황이 바뀌어 결정을 뒤집게 되더라도 옛 ADR을 고쳐 쓰지 않습니다.
        </p>
        <Code>{CODE_SUPERSEDE}</Code>
        <div className="tip">
          <b>실습 예고</b> 이 코스의 실습이 바로 이거예요. traderbox의 실제 결정 하나(시세 채널,
          스키마-퍼-서비스, 게이트웨이 없는 서비스별 JWT 검증 중 택 1)를 골라 <strong>대안
          2개와 함께</strong> 정식 ADR로 작성하고 팀 리뷰를 받습니다. 코드 0줄짜리 과제지만,
          아마 이 과정에서 가장 오래 고민하게 될 거예요.
        </div>
      </Section>

      <Section n={4} title="설계 문서와 설계 리뷰" sub="결함을 코드가 되기 전에, 싸게 찾는 장치">
        <p>
          ADR이 결정 하나의 기록이라면, <strong>디자인 독(Design Doc)</strong>은 결정에
          도달하기 위한 <strong>사전 문서</strong>예요. 만들기 전에 쓰고, 리뷰받고, 그 결론이
          ADR로 남는 흐름이죠. 표준 골격은 이렇습니다.
        </p>
        <Code>{CODE_DESIGN_DOC}</Code>
        <p>
          골격에서 가장 저평가되는 칸이 <strong>비목표(Non-Goals)</strong>예요. "이번에 안 하는
          것"을 명시하면 리뷰가 "그런데 다국어는요?" 같은 범위 밖 논쟁으로 새는 걸 막고,
          출시 후 "이거 왜 안 됐어요?"라는 오해도 막습니다. 범위를 좁힌 걸 사과하지 마세요 —
          좁힌 범위를 <strong>선언</strong>하는 게 좋은 설계 문서입니다.
        </p>
        <p>
          그리고 설계 리뷰의 본질. 리뷰는 <strong>승인 절차가 아니라 결함을 싸게 찾는
          장치</strong>예요. 문서 단계의 결함은 문장 몇 줄로 고치지만, 배포 후의 결함은 장애
          대응과 데이터 마이그레이션 비용으로 갚습니다. 리뷰어가 구멍을 찾아 줬다면 그건 공격이
          아니라 <strong>가장 싼 시점에 도착한 버그 리포트</strong>예요.
        </p>
        <p>
          좋은 리뷰어의 질문법도 있어요. <strong>"왜 안 했나"보다 "어떤 제약이 있었나"</strong>를
          물으세요. "왜 Kafka 안 썼어요?"는 심문처럼 들리지만, "시세 쪽에 어떤 제약이 있어서
          Pub/Sub으로 가셨어요?"는 작성자가 사고 과정을 펼쳐 보이게 합니다. 같은 정보를 얻으면서
          방어 대신 설명을 끌어내는 질문이 리뷰 문화를 만들어요.
        </p>
        <div className="tip">
          <b>리뷰 받는 쪽의 기술</b> 문서 첫머리에 "특히 봐 줬으면 하는 곳"을 두세 개 적어 두세요.
          "대안 2를 기각한 논리가 약한 것 같은데 검증 부탁", "마이그레이션 경로가 현실적인지" —
          리뷰어의 화력을 내가 불안한 곳에 집중시키는 것도 작성자의 역량입니다.
        </div>
      </Section>

      <Section n={5} title="트레이드오프를 설득하는 커뮤니케이션" sub="기술 용어를 리스크·비용·시간으로 번역하기">
        <p>
          아무리 옳은 결정도 <strong>전달에 실패하면 실행되지 않아요.</strong> 특히 듣는 사람이
          비개발자(경영진)라면, 기술 용어는 소음입니다. 통하는 언어는 셋뿐이에요 —{' '}
          <strong>리스크, 비용, 시간.</strong>
        </p>
        <Code>{CODE_TRANSLATE}</Code>
        <p>
          다음은 <strong>반대 의견 다루기</strong>입니다. 설계 리뷰에서 내 의견이 기각됐어요.
          이때의 프로토콜이 <strong>disagree and commit</strong>(반대하되 헌신한다)입니다.
          실제 작동은 이래요: 결정 <strong>전</strong>에는 반대 근거를 끝까지, 문서로 남기며
          주장합니다. 결정이 <strong>내려진 후</strong>에는 회의실 밖에서 "난 반대했는데"를
          반복하지 않고, 그 결정이 성공하도록 전력으로 돕습니다. 단, 내 반대 근거는 ADR의
          대안 칸에 남아 있죠 — 만약 예측대로 문제가 생기면 "거봐요"가 아니라 그 기록을 근거로{' '}
          <strong>재검토를 제안</strong>하면 됩니다. 반대가 기록되니 승복이 굴복이 아니게 돼요.
        </p>
        <p>
          마지막으로, 신뢰 자본 이야기. <strong>'모른다'와 '틀렸다'를 빨리 인정하는 사람이
          장기적으로 가장 설득력이 셉니다.</strong> 역설 같지만 원리는 단순해요 — 모르는 걸
          모른다고 말하는 사람의 "이건 확실합니다"는 액면가로 믿을 수 있거든요. 모든 질문에
          그럴듯한 답을 지어내는 사람은 어느 순간부터 맞는 말도 검증 대상이 됩니다. 인정의
          속도가 곧 다음 발언의 이자율이에요.
        </p>
        <div className="tip">
          <b>연습 문제</b> "SSE 경로에 gzip 압축을 켜면 안 됩니다"를 경영진 언어로 번역해
          보세요. 힌트: 압축·버퍼링이라는 단어 없이, "실시간 시세가 화면에서 멈추는 장애가
          납니다. 고객이 가장 먼저 알아채는 유형의 장애입니다"처럼 — 결과에서 출발하는 겁니다.
        </div>
      </Section>

      <Section n={6} title="레거시와 기술 부채의 리더십" sub="부채는 악이 아니라 이자율 관리 대상">
        <p>
          시니어가 되면 물려받는 것이 하나 있어요. <strong>남이 만든 부채</strong>입니다.
          여기서 첫 번째 관점 교정 — 기술 부채는 악이 아니에요. <strong>대출</strong>입니다.
          출시를 앞당기려고 미래의 시간을 당겨 쓰는 것, 사업에선 정상적인 금융 활동이죠.
          문제는 빚을 졌다는 사실이 아니라 <strong>이자율을 아무도 관리하지 않는 상태</strong>예요.
        </p>
        <Code>{CODE_DEBT}</Code>
        <p>
          핵심 구분은 <strong>의도적 부채 vs 무지성 부채</strong>입니다. "8월 말 출시가 우선이라
          Flyway는 출시 후 도입한다"는 의도적 부채예요 — 무엇을 미뤘는지 알고, 기록이 있고,
          갚을 시점이 로드맵에 있죠. 반면 몰라서·귀찮아서 쌓인 부채는 기록이 없어 <strong>어느 날
          장애라는 청구서</strong>로 돌아옵니다. 리더의 일은 부채를 0으로 만드는 게 아니라,
          모든 부채를 의도적 부채로 <strong>전환</strong>하는 것(찾아내고, 기록하고, 이자를
          측정하는 것)이에요.
        </p>
        <p>
          부채 상환을 로드맵에 올리려면 섹션 5의 번역 기술이 필요합니다. "리팩터링 하고
          싶어요"는 영원히 우선순위에서 밀려요. <strong>"이 모듈 때문에 기능 하나당 이틀씩
          더 듭니다 — 분기당 3주치 개발력이 이자로 나갑니다"</strong>는 로드맵에 올라갑니다.
          부채의 이자를 사업 언어(시간, 돈, 장애 위험)로 측정해 보여 주는 것, 그게 상환 예산을
          따내는 유일한 방법이에요.
        </p>
        <p>
          그리고 뜻밖의 부채 하나 — <strong>문서 드리프트</strong>. 문서가 현실과 어긋난 채
          방치되면, 읽는 사람마다 잘못된 판단을 하게 만드는 이자가 붙어요. 우리 저장소의
          CLAUDE.md가 "README·STRUCTURE는 서비스별 독립 repo를 전제하나 현재는 단일
          모노레포다"라고 <strong>불일치 자체를 기록해 둔 것</strong>은 그래서 가치 있는
          관행입니다. 문서를 다 못 고치더라도, "여기부터는 현실과 다르다"는 정직한 표지판
          하나가 이자를 크게 낮춰요.
        </p>
        <div className="tip">
          <b>이자 감각 기르기</b> 이번 주에 "이거 원래 이래요"라는 말을 들었다면 그게 부채
          후보예요. 왜 그런지 아무도 설명 못 하면 무지성 부채, 설명과 상환 계획이 있으면
          의도적 부채. 후보를 발견할 때마다 이슈 하나로 기록하는 습관이 이자율 관리의 시작입니다.
        </div>
      </Section>

      <Section n={7} title="주니어를 키우는 시니어" sub="답을 주지 말고 결정 프레임을 주기">
        <p>
          팀의 처리량을 두 배로 만드는 방법은 둘이에요. 내가 두 배로 일하거나(불가능),{' '}
          <strong>옆 사람이 성장하거나.</strong> 그래서 주니어를 키우는 건 시니어의 선택 과목이
          아니라 핵심 업무입니다. 관건은 성장을 우연에 맡기지 않고 <strong>사다리로 설계</strong>
          하는 거예요.
        </p>
        <Code>{CODE_LADDER}</Code>
        <p>
          사다리의 원리는 <strong>관찰 → 참여 → 소유</strong>의 점진적 이행이에요. 온콜을 예로
          들면, 처음부터 새벽 알람의 주인공을 시키는 게 아니라 <strong>섀도잉</strong>(책임 없이
          옆에서 대응 과정을 지켜보기)부터, 다음엔 백업이 있는 상태의 주인공으로. 설계도
          마찬가지 — 리뷰 <strong>참관</strong>으로 결정이 만들어지는 현장을 먼저 보여 준 뒤,
          작은 설계의 <strong>소유</strong>를 맡깁니다.
        </p>
        <p>
          위임할 때 가장 흔한 실수가 <strong>답을 줘 버리는 것</strong>이에요. "그건 이렇게
          하세요"는 당장 빠르지만 성장이 0이고, 다음에도 같은 질문이 돌아옵니다. 대신{' '}
          <strong>결정 프레임</strong>을 주세요 — "이 데이터는 유실돼도 되나요? 그 답에 따라
          전략이 갈려요." 프레임을 받은 사람은 다음번엔 스스로 결정합니다. 시간이 두 배 들지만,
          그 시간은 비용이 아니라 투자예요.
        </p>
        <p>
          이 모든 것의 토대가 <strong>심리적 안전감</strong>입니다. 질문했다고 "그것도 몰라요?"가
          돌아오고, 장애를 공유했다고 벌점이 되는 팀에선 사다리가 작동하지 않아요 — 모르는 것을
          숨기고, 사고를 늦게 보고하게 되니까요. 숨겨진 무지와 늦은 보고는 반드시 더 큰 장애로
          돌아옵니다. 시니어가 먼저 "이건 제가 모르겠네요", "이번 장애는 제 판단 미스였어요"라고
          말하는 팀에서만, 주니어도 안전하게 모르고 안전하게 실패할 수 있어요. 섹션 5의 신뢰
          자본이 여기서도 같은 원리로 작동합니다.
        </p>
        <div className="tip">
          <b>질문을 대하는 태도</b> 주니어의 질문 하나에 "좋은 질문이에요, 왜냐하면"으로 시작해
          보세요. 그 질문이 문서 부재를 드러냈다면(대개 그렇습니다) 답을 준 뒤 "이거 문서에
          없네요 — 같이 한 단락 추가할까요?"까지. 질문이 문서가 되는 순환이 만들어지면, 같은
          질문이 팀에서 두 번 소비되지 않습니다.
        </div>
      </Section>

      <Section n={8} title="과정 수료 프로젝트 — 나의 아키텍처 포트폴리오" sub="코드 0줄, 그러나 가장 시니어다운 과제">
        <p>
          특급 과정의 마지막 과제입니다. 이번엔 코드를 제출하지 않아요. 제출물은 전부{' '}
          <strong>문서</strong> — 섹션 1에서 말한 "시니어의 산출물"을 직접 만들어 보는 겁니다.
        </p>
        <Code>{CODE_PORTFOLIO}</Code>
        <p>
          <strong>① ADR 묶음</strong>은 Lv4 전 과정에서 만난 설계 결정들을 소급 기록하는
          작업이에요. 시세 배포 채널(이 코스의 예제를 그대로 쓰지 말고 본인의 언어로 다시
          쓰세요), 스키마-퍼-서비스, 서비스별 JWT 검증 — 어느 것이든 좋습니다. 채점 기준은
          하나예요: <strong>기각한 대안이 설득력 있게 적혔는가.</strong>
        </p>
        <p>
          <strong>② 디자인 독</strong>은 존재하지 않는 가상 서비스를 하나 설계하는 과제입니다.
          핵심은 완벽한 설계가 아니라 <strong>리뷰 세션</strong>이에요 — 동료의 코멘트를 받고,
          방어하고 싶은 마음을 누르고, 문서에 반영하는 그 한 사이클이 이 과제의 본체입니다.
        </p>
        <p>
          <strong>③ 성장 방향 회고</strong>엔 정답이 없어요. 한 도메인을 깊게 팔지(깊이) 여러
          도메인을 넘나들지(폭), IC로 남을지 리드로 갈지 — 지금의 답이 3년 뒤에 바뀌어도
          됩니다. 어차피 그 회고도 나중에 superseded 처리하고 새로 쓰면 되니까요. 중요한 건{' '}
          <strong>'왜'를 스스로 설명할 수 있는 상태</strong>로 다음 단계를 시작하는 것입니다.
        </p>
        <div className="tip">
          <b>이 과제가 어렵게 느껴진다면</b> 정상이에요. 코드는 컴파일러가 틀렸다고 말해 주지만,
          결정 문서는 아무도 정답을 확인해 주지 않거든요. 그 불확실함 속에서 근거를 쌓아 판단하고,
          기록을 남겨 검증 가능하게 만드는 것 — 그게 정확히 이 코스가, 그리고 특급 과정 전체가
          연습시키려던 능력입니다.
        </div>
      </Section>

      {/* 마무리 카드 */}
      <div className="step-card">
        <div className="step-body">
          <h3 style={{ marginBottom: 6 }}>🧭 특급 과정을 마치며</h3>
          <p className="muted">
            여기까지 오셨다면 이제 결정을 <strong>내리고(트레이드오프), 기록하고(ADR),
            검증받고(설계 리뷰), 설득하는(리스크·비용·시간의 언어)</strong> 한 사이클을 손에
            쥐었습니다. 대규모 시스템을 다루는 기술의 끝이 결국 사람과 기록의 문제로 수렴한다는
            것 — 그게 특급 과정이 마지막에 남기고 싶은 이야기였어요. 수료 프로젝트의 ADR 묶음을
            완성했다면, <Link to="/learn"><strong>학습 센터</strong></Link>로 돌아가 전체 과정을
            돌아보고 다음 성장 방향을 정해 봅시다. 축하합니다 — 이제 결정을 설계하는
            사람입니다.
          </p>
        </div>
      </div>
    </div>
  );
}
