← Back to NOTES 🌰 ← 프론트가 서버까지 확장될 때 생기는 비용 (RSC 이슈를 보며)

← 4. 프론트 기준으로 “리스크가 늘었다”를 판단하는 예시

앞에서 말한 attack surface / trust boundary / 입력 해석 비용 같은 것들은, “알고 있다”로 끝나기 쉽다. 그래서 나는 도입 판단을 ‘원칙’이라기보다, 실무에서 흔들리지 않게 해주는 가드레일(질문 목록)로 만들어 둔다. 이 가드레일의 목적은 멋을 포기하자는 게 아니라, 도입 속도와 운영 체력을 같이 맞추자는 쪽에 가깝다.

5-1) 기본값: 보수적으로 시작한다

신기능은 기본적으로 작은 범위에서, 옵트인으로, 되돌릴 수 있게 시작한다. 이건 “안 쓴다”가 아니라 “확장 순서를 늦춘다”는 의미다.

• 적용 범위를 좁힐 수 있는가? (특정 라우트/특정 페이지/특정 모듈)
• 끄는 스위치가 있는가? (기능 플래그, 설정, 빌드 옵션, 우회 경로)
• 롤백이 가능한가? (버전 롤백, 경로 분리, 배포 단위 분리)

여기서 하나라도 “없다”면, 도입 속도는 자동으로 느려져야 한다.

5-2) 시간 대신 ‘시장 검증 신호’를 본다

나는 “몇 년 지나면 안전” 같은 말은 별로 믿지 않는다. 대신 이 기술/생태계가 실제 사건을 겪었을 때 어떻게 수습하는지, 그리고 그 경험이 문서/도구/프로세스에 반영됐는지를 본다.

도입 쪽으로 기우는 신호

• 영향 범위가 명확하게 정리된다
• 패치 버전과 업그레이드 경로가 현실적이다
• 빠른 점검/업데이트 도구가 있다
• 사건 이후 문서와 기본값이 개선된다

보류 쪽으로 기우는 신호