하네스 친화적 아키텍처

개요

모든 시스템이 같은 정도로 하네스 친화적인 것은 아니다. 어떤 아키텍처는 하네스를 붙이기 쉽고, 어떤 아키텍처는 하네스를 붙이려는 순간부터 구조적 저항이 크다.

이 섹션은 하네스를 가능하게 하는 아키텍처 조건을 정리한다. 핵심 질문은 단순하다.

어떤 구조여야 우회를 식별하고, 합법 경로를 좁히고, 위반을 실패로 만들 수 있는가

이 섹션의 위치

이 섹션은 새로운 thesis를 추가하지 않는다. 이미 본론에서 정리한 내용을, 실제 설계 판단의 언어로 다시 배치하는 역할만 한다.

즉 여기서 보는 것은 다음이다.

• 좋은 아키텍처가 무엇인가
• 보다는
• 하네스를 붙일 수 있는 아키텍처 조건이 무엇인가

핵심 질문

하네스 친화적 아키텍처를 보려면 다음 질문을 던지면 된다.

• 경계가 충분히 명시적인가
• 합법 진입점이 좁고 분명한가
• 내부 구현이 충분히 숨겨져 있는가
• fallback과 shortcut이 우회 통로가 되고 있지 않은가
• validator와 enforcement를 붙일 수 있는 지점이 있는가
• 테스트와 개발 환경도 같은 경계를 따르는가

이 질문들은 미학적 설계를 가리는 기준이 아니라, 통제 가능성을 가리는 기준이다.

이 섹션의 구성

boundary-shape ^{경계 형태}

경계, 합법 진입점, 캡슐화, 계약이 왜 중요한지 본다.

shortcut-sources ^{우회 원천}

fallback, singleton, helper, test shortcut이 왜 우회 통로가 되는지 본다.

enforcement-readiness ^{강제 준비도}

validator, build-time check, runtime guard, 관찰 가능성이 어떤 구조를 요구하는지 본다.

retrofit-order ^{도입 순서}

레거시 구조에 하네스를 도입할 때 어디부터 손대야 하는지 본다.

checklist ^점검표

실제 프로젝트를 빠르게 점검하기 위한 압축 체크리스트다.

읽는 순서

이 섹션은 다음 순서로 읽는 편이 좋다.

1. boundary-shape
2. shortcut-sources
3. enforcement-readiness
4. retrofit-order
5. checklist

이 순서는 구조를 보고, 약한 지점을 찾고, 강제 가능성을 판단하고, 실제 전환 순서를 잡는 흐름이다.

요약

좋은 아키텍처란 예쁘게 분리된 아키텍처가 아니다.

• 우회가 어디서 시작되는지 보이고
• 합법 경로가 좁고 분명하며
• 위반을 실패로 바꿀 수 있는 지점이 있고
• 구조를 테스트와 운영 모두에서 유지할 수 있는 아키텍처

즉 이 섹션이 말하는 것은 하네스를 설명하는 아키텍처가 아니라, 하네스를 실제로 가능하게 만드는 아키텍처다.