그럼에도 여전히 알아야 할 것들

객체에 책임과 데이터를 묶어 협력시키는 패러다임 — 상속·조합 균형이 장기 유지보수성을 가른다.

파티션이 일어났을 때 일관성을 지킬지 가용성을 지킬지, 도메인이 어느 쪽 실패를 덜 견디느냐의 결정

외부 의존이 죽었을 때 내 자원이 묶이지 않게 어디서 끊고 어디서 격리할지의 우선순위 판단.

모듈 간 의존(결합)과 모듈 내 책임 밀집(응집) 사이의 긴장이 변경 한 건의 파급 범위를 결정한다

최신성을 즉시 보장할지, 시간이 지나 수렴시킬지 사이의 선택 문제다.

계층 분리의 유지보수 이점과, 중간 계층이 전달만 하다 의미를 잃는 싱크홀 사이의 트레이드오프.

하나의 구성요소가 무너지면 전체가 같이 멈추는 지점 — 가용성 설계의 출발점이자 끝점이다.

완료 대기 방식과 제어권 반환은 서로 다른 축이라, 묶어서 설명하면 I/O 모델 선택이 흔들린다.

현재 상태가 아니라 변경 이벤트를 저장하고 재생해 상태를 복원하는 모델과 그 대가 사이의 트레이드오프.

조건문으로 누적되던 분기를 객체로 분리하는 패턴 — 변화 축을 어디에 두느냐의 문제다.

웹 코드 재사용 속도와 네이티브 수준의 성능·보안·OS 접근 사이의 선택 문제다.

공통 로직을 서블릿 컨테이너 경계에서 끊을지, Spring MVC 핸들러 맥락에서 다룰지를 가르는 비교

순수 함수와 불변성을 기본값으로 두고, 부수 효과를 가장자리로 모아 관리하는 사고 방식이다.

여러 백엔드를 클라이언트가 직접 부르는 부담과 BFF 한 층을 더 운영하는 비용 사이의 선택

테스트 격리성과 행위 검증 사이에서 어떤 종류의 더블을 언제 쓸지 가르는 기준

객체를 누가 만들어 넣어주는가 — 생성 책임을 사용 책임에서 떼어내는 설계 원칙

테스트가 실행한 범위(숫자)와 결함 탐지력(실질) 사이의 간극을 어떻게 다룰지의 문제

변경에 흔들리지 않고 결합도를 낮추는 객체지향 설계의 다섯 가지 기준.

여러 패키지를 한 저장소에서 공유하는 편의와 빌드·권한·릴리즈가 함께 엮이는 운영 비용 사이의 선택이다.

공유 인스턴스의 편의성과 전역 상태로 인한 테스트·결합도 비용 사이의 트레이드오프

사용자 피해를 빨리 끊을 것인가, 근본 원인을 끝까지 따라갈 것인가 사이의 우선순위 판단.

null 분기를 줄여주는 단순화 효과와 실패가 가려지는 위험 사이에서 적용 기준을 가르는 판단.

요청이 라우트에 닿기 전 한 번 끼는 전단 레이어에 무엇까지 떠맡기고 어디서 라우트 내부로 내릴지의 책임 경계 문제

배포 주기·QA 게이트·자동화 성숙도에 따라 갈리는 브랜치 운영 모델 사이의 선택 문제다.

명령 모델과 조회 모델을 따로 둘 가치가 있는지, 두 벌 동기화 비용까지 감당할지의 문제

Next.js 도입은 라우팅·렌더링·번들링 자동화 이득과 프레임워크 락인·러닝커브 비용 사이의 트레이드오프다.

알고리즘 뼈대를 상위에 고정하고 변하는 단계만 하위에서 채우는 상속 기반 설계의 트레이드오프

DispatcherServlet이라는 단일 진입점에서 반환 타입에 따라 뷰 렌더링 경로와 메시지 변환 경로로 갈린다.

컬렉션을 감싼 전용 타입에 _불변식과 규칙_을 모아 도메인 일관성을 강제하는 패턴이다.

전역 스토어 + 심볼릭 링크로 가는 pnpm과 node_modules 자체를 걷어내는 Yarn Berry PnP, 어느 쪽 해석 모델을 택할 것인가의 문제다.

정적 응답과 네트워크 처리에 강한 웹 서버, 애플리케이션 로직을 실행하는 WAS의 책임 분리.

모듈 그래프를 "브라우저가 빠르게 실행할 형태"로 다시 그려 주는 빌드 도구.