하네스

하네스는 우회가 어디서 시작되는지 보는 계층이다. 막는 것은 실행 통제가 한다.

하네스 전이에서 정리한 것처럼, 문제는 경로가 열려 있다는 데 있다. 프롬프트도, 컨텍스트도, 실행도 — 어느 것도 경로를 고정하지 못한다. 그래서 먼저 필요한 것은 어떤 경로가 열려 있는지 식별하는 것이다.

이 파트는 두 개의 실제 프로젝트와, 그 프로젝트에서 AI를 함께 쓰면서 생긴 경험을 기록한다. 하네스 개념을 추상적으로 설명하지 않고, 각 환경에서 실제로 어떤 우회가 발생했는지를 예시로 보여준다.

먼저 실제 단면을 본다

하네스의 보상은 추상 이론이 아니다. 코드가 어디를 통과해야 하는지가 앞에서부터 고정되기 시작한다.

// Atlas 우회
return File.ReadAllText(path);

// Atlas 합법 경로
return await _workspaceFileService.ReadTextAsync(docId);

// Glif 우회
import { HeroBlock } from "@/ui/blocks/HeroBlock";

// Glif 합법 경로
return renderBlock(block);

위 두 줄 차이는 미학이 아니라 통제의 위치 차이다. 앞의 경로는 구조를 건너뛰고, 뒤의 경로는 analyzer, runtime guard, 테스트가 같은 경계를 공유하게 만든다.

이 흐름은 코드 밖의 AI 운영에도 그대로 이어진다. 범위가 열린 작업 대신 작업 계약과 Acceptance Gate로 루프를 닫아야 한다.

각 단면의 실제 사례는 다음 문서로 이어진다.

• Atlas: UI 직접 파일 접근
• Glif: 컴포넌트 레지스트리 우회
• AI 작업자: 작업 계약, 정본 예시, Acceptance Gate

하네스가 주는 실익은 단순한 엄격함이 아니라, 다음 작업에서도 같은 진입점과 같은 실패 형식을 재사용할 수 있게 만드는 안전한 속도다.

세 환경

프로젝트는 두 개였다. 하지만 하네스를 분리한 축은 세 개다.

Atlas — .NET 데스크탑 앱

C# / .NET으로 작성된 데스크탑 애플리케이션. 레이어드 아키텍처, Roslyn Analyzer 기반 정적 강제. 이 환경에서는 레이어 경계, 인터페이스 계약, 상태 변경 경로, 검증 절차에서 우회가 두드러졌다.

→ Atlas 하네스

Glif — 웹 앱

React / TypeScript로 작성된 웹 애플리케이션. 컴포넌트 중심 아키텍처, ESLint 기반 정적 강제. 이 환경에서는 컴포넌트 연결 경로, 렌더링 계약, 상태-UI 바인딩, 표현 정합성에서 우회가 두드러졌다.

→ Glif 하네스

AI 작업자

두 프로젝트 모두에서 AI 코딩 에이전트를 많이 사용했다. 사람이 만드는 우회와 AI가 만드는 우회는 패턴이 달랐다. AI는 더 빠르게, 더 일관되게, 더 넓게 우회를 복제했다. 그래서 AI 특화 통제 계층이 별도로 필요했다.

→ AI 작업자 하네스

왜 환경별로 분리했는가

처음에는 하나로 정리하려 했다. 하지만 두 환경의 우회 패턴이 너무 달랐다.

Atlas에서는 레이어를 건너뛰거나 인터페이스 계약을 무시하는 우회가 반복됐다. Glif에서는 컴포넌트를 직접 import하거나 레지스트리를 우회하는 우회가 반복됐다. 강제 도구도 달랐다 — Roslyn Analyzer와 ESLint는 작동 방식이 근본적으로 다르다.

같은 추상 언어로 합치면 각 환경에서 실제로 어떻게 나타나는지가 흐려진다. 그래서 환경별로 분리했다.

공통 기준

환경이 달라도 우회를 식별하는 질문은 같다. 개별 사례를 읽을 때는 항상 이 다섯 질문으로 돌아온다.

합법 경로 — 허용된 경로가 정의되어 있는가

우회를 막기 전에, 무엇이 합법 경로인지 먼저 정의해야 한다. 합법 경로가 흐리면 금지 목록이 아무리 많아도 소용없다. 사람도 AI도 더 짧은 경로를 계속 추측한다.

이 작업을 위한 허용된 경로는 정확히 어디인가?

단일 진입점 — 경로가 하나로 수렴하는가

같은 목적지에 도달하는 경로가 여러 개이면 구조는 빠르게 흔들린다. 단일 진입점은 취향 문제가 아니다. 우회와 예외가 두 번째 표준으로 굳는 것을 막는 최소 조건이다.

진입점이 하나로 고정되어 있는가? 아니면 여러 경로가 사실상 같은 역할을 하고 있는가?

상태 분리 — 값만 바뀌는가, 경로도 실행되는가

많은 붕괴는 값이 변경되는 것 자체가 아니라, 값이 어떤 절차를 통과했는지가 사라질 때 발생한다. 상태는 단순한 저장 값이 아니라 의미와 절차가 붙은 경로다. 전달 과정에서 이 의미가 변형되면 시스템은 점진적으로 붕괴된다.

값만 바뀌는가, 아니면 정해진 의미 경로도 함께 실행되는가?

정본 — canonical path가 하나인가

정본이 하나가 아니면 우회는 빠르게 표준처럼 보이기 시작한다. old path와 new path가 공존하거나, editor와 preview가 다른 데이터를 보거나, 테스트 전용 경로가 가장 가까운 예시가 되는 순간 정본이 사라진다.

어떤 경로가 canonical path인가? 그것이 실제로 하나인가?

실패 신호 — 위반이 즉시 드러나는가

우회를 단순 금지하는 것과, 위반이 즉시 신호가 되게 만드는 것은 다르다. 실패가 느리거나, 추상적이거나, 어디서 발생했는지 알 수 없으면 — 규칙은 다시 설명으로 퇴행한다. 실패는 빠르고, 국소적이고, 합법 경로를 가리켜야 한다.

위반은 어디서 실패하는가? 그 실패는 빠르고, 국소적이고, 합법 경로를 가리키는가?

반복되는 우회 패턴

어떤 환경에서도 우회는 다섯 패턴 중 하나로 수렴한다. 이 패턴은 외울 필요 없다. 어떤 기준이 무너지는지 보이면 충분하다.

강제와의 관계

하네스는 식별한다. 강제는 차단한다.

각 사례 문서 안에 강제 지점이 명시되어 있고, 강제 구현의 상세는 실행 통제 파트에서 다룬다.

읽는 순서

처음 읽는다면: 이 페이지 → Atlas 또는 Glif 중 익숙한 환경 → AI 작업자

특정 우회 패턴을 찾는다면: 위 테이블에서 패턴을 찾고 해당 환경 파트로 직접 이동

두 환경을 모두 읽을 필요는 없다. 본인 환경과 가까운 것부터 시작하면 된다.