부록

부록

개요

이 섹션은 프로젝트의 본론을 대체하지 않는다. 부록의 목적은 overview -> harness -> enforcement를 읽고 난 뒤, 실무에서 자주 필요한 보조 질문과 상세 배경을 따로 정리하는 것이다.

즉 부록은 철학이 아니라 보조 문서 층이다.appendix

왜 부록이 필요한가

본론은 다음 질문에 집중한다.

  • 시스템은 왜 무너지는가
  • 어떤 우회 표면이 반복되는가
  • 어떻게 그 우회를 실패로 만들 것인가

하지만 실제 적용 단계에서는 더 실무적인 질문이 생긴다.

  • 설계 결정을 어떻게 rule과 validator로 번역할 것인가
  • 어떤 구조여야 하네스를 붙일 수 있는가
  • 합법 경로를 어떻게 더 짧게 만들 것인가
  • 실패 메시지는 어떻게 설계해야 하는가
  • 도입 비용과 트레이드오프는 어떻게 볼 것인가
  • AI 코딩의 상세 배경을 어디에 따로 정리할 것인가

이 질문들은 중요하지만, 메인 흐름 한가운데 두면 본론의 초점을 흐리기 쉽다. 그래서 별도 부록으로 다룬다.

현재 포함된 섹션

AI 코딩 상세 분석

transition이 압축해서 말한 prompt/context 논의를 더 깊게 푸는 상세 배경 층이다.

  • prompt 상세
  • context 정의
  • context 범위와 선택
  • context 한계

통제 설계

설계 결정을 rule, validator, enforcement로 연결하는 중간 설계층을 다룬다.

  • rule lifecycle
  • rule design
  • validator design

하네스 친화적 아키텍처

하네스를 가능하게 하는 아키텍처 조건과 도입 판단을 다룬다.

  • 어떤 구조가 하네스 친화적인가
  • 어떤 우회 원천이 구조를 약하게 만드는가
  • validator와 enforcement를 붙일 준비가 되었는가
  • 레거시 구조는 어떤 순서로 손대야 하는가

합법 경로 중심 API 설계

합법 경로를 우회보다 짧게 만드는 API 설계를 다룬다.

  • 합법 경로를 먼저 설계하는 원칙
  • 진입점과 표면을 좁히는 방법
  • 계약 형태와 결과 형태 설계
  • 편의를 제공하되 우회를 만들지 않는 방법

실패와 피드백 설계

실패 메시지와 피드백 루프를 설계하는 방식을 다룬다.

  • 실패를 가능한 한 빨리 드러내는 기준
  • validator 출력을 수정 인터페이스로 만드는 방법
  • 런타임 가드 실패를 복구 가능한 신호로 만드는 방법
  • 반복 실패를 rule, API, harness 개선으로 환류시키는 방법

도입 전략과 트레이드오프

하네스를 실제로 도입할 때의 비용, 범위, 강도, 예외 정책을 다룬다.

  • 도입 비용의 실제 원천과 숨은 유지 비용
  • 어디부터 묶어야 효과가 큰지 보는 범위 선택
  • 규칙과 enforcement 강도를 단계에 맞게 조절하는 방법
  • 예외를 허용하되 구조 붕괴로 굳지 않게 관리하는 방법

이 여섯 섹션은 본론을 다시 설명하지 않고, 본론을 실제 설계 판단과 운영 마찰 감소의 언어로 번역하는 역할을 한다.

본론과의 관계

부록은 본론과 병렬로 경쟁하는 섹션이 아니다. overview, transition, harness, enforcement에서 다룬 핵심 논지를 실무 설계와 도입 판단 쪽으로 확장하는 참조층이다.

따라서 이 섹션의 문서들은 메인 흐름을 다시 반복하기보다, 도입 비용, 설계 번역, 운영 마찰처럼 본론 밖에서 길게 다루기 어려운 문제를 받아낸다.

요약

부록은 본론을 대신하는 층이 아니라, 본론에서 길게 다루기 어려운 설계 번역과 도입 판단을 받아내는 참조층이다. appendix/ai-coding은 transition의 상세 배경을, 나머지 섹션은 하네스 설계, 도입 비용, 운영 마찰을 실무 언어로 정리한다.