개요 – The Harness

개요

처음에는 다 괜찮아 보인다. 그래서 더 늦게 무너진다.

먼저 결과를 본다

하네스가 하려는 일은 복잡하지 않다. 우회가 가능하면 선택의 문제로 남고, 우회가 실패가 되면 구조의 문제가 된다.

// 우회: 값만 바꾼다
document.status = "published";
save(document);

// 합법 경로: 허용된 진입점만 통과한다
dispatch({ type: "publish", docId: document.id });

이 차이 하나로 다음이 달라진다.

빠르게 실체부터 보고 싶다면: 실행 통제 → 전이 통제 → 하네스

이 문서는 모든 시스템에 즉시 최대 강도의 하네스를 걸자는 얘기가 아니다. 초기 실험 코드, 레거시 정리 구간, 핵심 상태 전이 경계는 같은 방식으로 묶을 수 없다.

핵심은 완전주의가 아니라 safe velocity다. AI와 사람이 반복해서 사고를 내는 경계부터 닫고, 나머지는 단계적으로 조인다.

적용 범위와 강도 조절은 도입 전략과 트레이드오프에서 따로 다룬다.

노트 앱을 하나 만든다고 하자.

처음에는 잘 된다. 목록이 보이고, 문서가 열리고, 수정도 된다. 조금 더 욕심을 내서 검색을 붙이고, 태그를 넣고, 자동 저장까지 얹는다.

여기까지도 괜찮다.

문제는 그 다음이다.

같은 요청인데 결과가 조금씩 달라진다. 이전에 잡아둔 구조가 다음 수정에서 유지되지 않는다. 수정은 분명 한 군데만 했는데, 다른 쪽에서 균열이 생긴다.

처음에는 사소해 보인다. 나중에는 어디서부터 틀어졌는지조차 알 수 없어진다.

이건 드문 사고가 아니다. 오히려 아주 흔한 실패 방식이다.

시스템은 한 번에 무너지지 않는다. 조용히 어긋난다. 그리고 어느 순간, 이미 누더기가 된 뒤에야 그 사실을 알아챈다.

이런 상황에서 보통 먼저 의심하는 것은 코드의 품질이다.

물론 이런 요소들은 영향을 준다. 하지만 반복되는 실패를 설명하기에는 충분하지 않다.

문제는 대개 더 아래에 있다.

같은 상태를 여러 경로가 바꾸고, 같은 기능이 서로 다른 방식으로 확장되고, 기록되지 않은 의도는 전달 과정에서 증발한다.

남는 것은 동작하는 코드다. 하지만 그 코드가 왜 그런 모양이 되었는지, 어떤 경로를 통해 그렇게 되었는지는 더 이상 분명하지 않다.

이 문제를 해결하려고 사람들은 늘 비슷한 시도를 한다.

초반에는 효과가 있다. 실제로 잠깐은 나아진다.

하지만 오래 가지 않는다.

문제는 사라지지 않는다. 다만 다른 모양으로 다시 나타난다.

이유는 단순하다.

우리는 결과를 더 잘 만들려고 애쓰지만, 결과가 지나가는 통로 자체는 그대로 두기 때문이다.

통로가 열려 있으면, 결국 그 길은 다시 사용된다.

그래서 이 문서는 접근을 바꾼다.

코드를 더 잘 쓰게 만드는 방향이 아니라, 잘못된 경로로는 흘러갈 수 없게 만드는 방향으로 시선을 옮긴다.

문제를 “누가 실수했는가"가 아니라 “시스템이 무엇을 허용하고 있었는가"로 읽는다.

이 문서에서는 그 접근을 하네스라고 부른다.

하네스는 규칙을 더 많이 붙이는 방식이 아니다. 통제의 주권을 다시 시스템 쪽으로 가져오는 방식이다. 사람이든 AI든, 허용된 경로만 통과하게 만들고, 그 밖의 경로는 실패로 바꾼다.

이 문서는 다음 순서로 진행된다.

지금 필요한 것은 더 많은 팁이 아니라, 왜 기존 방식이 반복해서 같은 벽에 부딪히는지 보는 일이다.