> For the complete documentation index, see [llms.txt](https://riu-salze-studio.gitbook.io/cosmic-horizon/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://riu-salze-studio.gitbook.io/cosmic-horizon/kr/operating-system/pattern-ftl-bound-agents.md).

# \[pattern] FTL-Bound Agents

AI 에이전트를 위한 컨텍스트 경계와 안전한 중단 규칙의 좌표화

> 표류 중 남긴 생존 로그

## 현재 좌표계

* 에이전트 지시 파일은 기술적으로 프롬프트이지만, 일회성 요청처럼 다뤄져서는 안 된다.
* 좋은 AGENTS.md나 CLAUDE.md는 AI 에이전트에게 단순히 무엇을 하라고 말하는 문서가 아니다. 에이전트가 행동할 수 있는 세계를 정의하는 문서다.
* 에이전트 지시 파일의 목적은 프로젝트의 모든 세부사항을 담는 것이 아니라, 위험한 해석 여백을 줄이는 데 있다.

## 프롬프트이지만, 단순한 프롬프트는 아니다

기술적으로 AGENTS.md, CLAUDE.md, 그리고 유사한 파일들은 프롬프트다.

이 파일들은 AI 시스템 앞에 놓이는 지시문이며, 에이전트가 프로젝트를 읽고, 행동을 선택하고, 파일을 수정하고, 명령을 실행하고, 결과를 보고하는 방식에 영향을 준다.

그러나 Cosmic Horizon 안에서 이 파일들은 일반적인 프롬프트로 취급되지 않는다.

일반적인 프롬프트는 결과물을 요청한다.

에이전트 지시 파일은 결과물을 둘러싼 운영 경계를 정의한다.

이 문서는 에이전트에게 어디를 봐야 하는지, 언제 행동해야 하는지, 언제 멈춰야 하는지, 무엇을 추론해서는 안 되는지, 작업을 신뢰하기 전에 무엇을 보고해야 하는지를 알려준다.

이 구분은 중요하다. AI 에이전트는 지시를 단순 실행하지 않는다.

AI 에이전트는 지시를 해석한다.

경계가 모호하면 에이전트는 해석을 통해 작업 범위를 넓힌다.

경계가 명확하면 에이전트는 선언된 세계 안에서 움직인다. 가정은 추측되지 않고 검증되며, 에이전트는 제한된 궤도 안에서 움직인다.

## 질량을 줄여라

에이전트 지시 파일이 프로젝트 매뉴얼 전체가 되어서는 안 된다.

모든 프로젝트 규칙, 모든 아키텍처 결정, 모든 테스트 세부사항, 모든 경고를 담으려 하면, 이 파일은 무거워지고, 낡아지고, 매번 작업마다 컨텍스트에 싣기 비싸진다.

이 파일의 더 나은 역할은 전체 지도를 담는 것이 아니다.

이 파일은 프로젝트별 공간으로 들어가는 통제된 웜홀을 연다.

여러 AI 에이전트는 이 웜홀을 통해 적절한 컨텍스트로 진입하고, 필요한 경계 문서를 불러오며, 의도한 궤도 밖으로 표류하는 일을 피할 수 있다.

**에이전트 지시 파일은 경로를 정의한다.**

이 파일은 다음을 정의해야 한다.

* 에이전트가 빠른 경로를 사용할 수 있는 조건
* 에이전트가 기본 경로를 사용해야 하는 조건
* 에이전트가 멈춰야 하는 조건
* 에이전트가 실행 전에 선언해야 하는 조건
* 프로젝트별 문서를 불러와야 하는 조건
* 검증 상태를 보고해야 하는 조건

**프로젝트별 경계 문서는 지도를 정의한다.**

이 문서들은 다음을 기록한다.

* 제약
* 불변 조건
* 위험 구역
* 승인 관문
* 검증 규칙

Cosmic Horizon 안에서 이런 문서들은 관측소 계층을 이룬다.

> 과도한 질량은 궤도를 붕괴시킨다.
>
> — Cosmic Horizon

## 웜홀을 분리하라

재사용 가능한 에이전트 지시 시스템은 공통 실행 규칙과 프로젝트별 경계를 분리해야 한다.

에이전트 지시 파일은 프로젝트 지도가 아니다.

그것은 프로젝트별 공간으로 들어가는 통제된 웜홀이다.

환경에 따라 이 웜홀은 `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `.cursorrules`, Roo Code rules, Cline instructions, 또는 다른 도구별 진입점으로 나타날 수 있다.

프로젝트 지도는 다른 곳에 있어야 한다.

그 지도는 관측소 계층에 속한다. 예를 들면 다음과 같은 안정적인 경계 문서들이다.

* `system_gravity.md`
* `invariants.md`
* `no_crossing_zones.md`
* `event_horizon.md`
* `approval_gate.md`
* `test_matrix.md`

이 파일들이 모든 프로젝트에 존재해야 하는 것은 아니다.

프로젝트 규모, 회사의 거버넌스, 팀의 관례, 작업 영역이 요구할 때 배치하면 된다.

핵심은 모든 도구에 같은 파일명, 고정된 디렉터리 구조, 동일한 지시 형식을 강제하는 데 있지 않다.

핵심은 모든 AI 에이전트가 프로젝트별 경계를 어디서 찾아야 하는지 알아야 하며, 경계가 없을 때는 그것을 만들어내지 않고 누락된 경계로 명시해야 한다는 데 있다.

웜홀은 도구에 따라 달라질 수 있다.

지도는 관측 가능해야 한다.

> 진입점은 일시적이다. 경계는 불변이다.
>
> — Cosmic Horizon

## 조언이 아니라 경로를 그려라

약한 지시 파일은 표면적으로 그럴듯하게 들리는 경우가 많다.

그 문서들은 수동적인 조언을 제공한다.

* 조심해라
* 단순하게 유지해라
* 최소한으로 변경해라
* 관련 파일을 사용해라
* 가능하면 기존 흐름을 보존해라

이 문장들이 쓸모없는 것은 아니다. 다만 해석 여백을 너무 많이 남긴다.

무엇이 단순한가?

무엇이 관련 있는가?

언제 기존 흐름의 보존이 가능한가?

모델이 보기에 최소 변경처럼 보이는 작업도 프로젝트에는 파괴적일 수 있다.

강한 지시 파일은 조언하지 않는다.

강한 지시 파일은 명확한 경로를 그린다.

* **만약** 작업이 문구나 서식만 바꾼다면 → **빠른 경로를 사용한다.**
* **만약** 작업이 소스 동작을 바꾼다면 → **기본 경로를 사용한다.**
* **만약** 작업이 승인 규칙과 충돌한다면 → **실행 전에 멈춘다.**
* **만약** 검증을 수행할 수 없다면 → **그럴듯하게 통과한 척하지 않고 상태를 보고한다.**
* **만약** 범위가 불명확하다면 → **해석으로 범위를 넓히지 않는다.**

경로는 조언보다 강하다.

조언은 모델에게 잘 행동해 달라고 요청한다.

경로는 특정 조건이 나타났을 때 모델이 무엇을 해야 하는지 지정한다.

### 해석 여백을 통제하라

명확한 지시는 해석을 제거하지 않는다.

위험한 해석 여백을 줄인다.

어떤 에이전트 지시 파일도 모든 추상화, 추론, 판단을 제거할 수는 없다.

AI 에이전트는 여전히 컨텍스트를 읽고, 패턴을 비교하고, 도구를 선택하고, 현재 작업에 규칙을 어떻게 적용할지 판단해야 한다.

목표는 해석을 사라지게 만드는 것이 아니다.

목표는 해석이 승인되지 않은 실행으로 변하는 것을 막는 것이다.

좋은 지시 파일은 안전한 경로를 명확하게 만들고, 위험한 경로를 보이게 만들며, 금지된 경로를 사용할 수 없게 만든다.

남은 모호함이 무해하다면 에이전트는 계속 진행할 수 있다.

남은 모호함이 범위, 경계, 승인, 검증, 책임에 영향을 준다면 에이전트는 멈춰야 한다.

평이한 말은 얕은 말이 아니다.

그것은 압축된 통제다.

> 조언은 좋은 행동을 요청한다. 경로는 제한된 궤도를 강제한다.
>
> — Cosmic Horizon

## 마지막 읽기 전용 관문

선언은 실행 전 마지막 읽기 전용 확인 지점이다.

이 시점에서 에이전트는 프로젝트를 관측했고, 작업의 근거를 잡았으며, 의도된 경로를 식별했다.

그러나 에이전트는 아직 세계를 바꿀 권한을 얻지 않았다.

가볍지 않은 작업이 실행으로 들어가기 전에 에이전트는 다음을 선언해야 한다.

* 무엇을 관측했는가
* 어떤 경계가 작업을 정의하는가
* 무엇을 바꿀 계획인가
* 무엇을 보존할 계획인가
* 결과를 어떻게 검증할 것인가
* 무엇이 아직 불확실한가

이 선언이 수락되기 전까지 작업은 읽기 전용 상태로 남는다.

파일은 수정되지 않는다.

패치는 생성되지 않는다.

서식 변경은 적용되지 않는다.

리팩터링은 시작되지 않는다.

이 관문이 존재하는 이유는 오해가 작업 트리를 바꾸기 전에 가장 저렴하기 때문이다.

의도하지 않은 수정이 프로젝트에 들어오면, 인간 운영자는 원래 궤도를 복구하기 위해 주의를 써야 한다.

선언은 실행이 작업 트리에 잔해를 남기기 전에, 인간이 궤적을 바로잡을 수 있는 마지막 기회를 제공한다.

> 가장 깨끗한 롤백은 애초에 필요하지 않았던 롤백이다.
>
> — Cosmic Horizon

## 비례하는 추진력

실용적인 에이전트 지시 시스템은 작업 통제를 작업 위험에 비례시켜야 한다.

모든 수정이 같은 수준의 구조적 통제를 요구하지는 않는다.

간단한 문구 수정이 아키텍처 리팩터링, 의존성 변경, 배포 변경과 같은 절차적 무게를 가져서는 안 된다.

대부분의 AI 활용 작업 흐름은 세 가지 궤도만으로 충분히 통제할 수 있다.

### 1. 빠른 경로 — 낮은 위험

간단한 서식 변경, 문구 수정, 작은 문서 갱신에 사용한다.

> **관측 → 실행 → 보고**

### 2. 기본 경로 — 일반 위험

소스 동작, 로직, 프로젝트 상태, 실행 흐름을 바꾸는 작업에 사용한다.

> **관측 → 근거화 → 선언 → 실행 → 보고**

### 3. 중단 경로 — 높은 위험 / 모호함

구조적 충돌, 경계 침범, 승인 누락, 해결되지 않은 불확실성이 발견될 때 사용한다.

> **관측 → 근거화 → 중단 → 인간의 결정을 기다림**

이것이 통제된 추진력이다.

불확실성은 중단 신호가 된다.

모호함은 에이전트를 자율적 해석이 아니라 인간의 결정으로 보낸다.

> 경계 없는 추진력은 표류가 된다.
>
> — Cosmic Horizon

## 개인의 좌표, 공유된 임무

에이전트 지시 파일은 매우 개인적일 수 있다.

이 파일은 개별 개발자의 철학, 운영 방식, 위험 허용치를 반영한다.

이런 개인 설정은 로컬에만 존재할 수도 있고, 버전 관리 밖에 남을 수도 있으며, 비공개 작업 산출물로 유지될 수도 있다.

팀 수준과 프로젝트 수준의 지시 파일은 다른 목적을 가진다.

그것들은 공유된 운영 합의를 나타낸다.

저장소가 자체 에이전트 지시 파일을 정의한다면, 그 파일은 해당 저장소 안에서 작업하는 모든 사람에게 프로젝트 경계의 일부가 된다.

개인 규칙은 여전히 로컬 항해 보조 장치로 존재할 수 있다.

개인 좌표가 공유된 프로젝트 경계와 충돌할 때는, 명시적으로 재협상되지 않는 한 공유 경계가 임무를 지배한다.

성숙한 에이전트 작업 흐름은 세 가지 중력 계층을 분리한다.

* 개인 운영 방식 — 비공개 항해 보조 장치와 개인의 위험 허용치
* 팀 수준 합의 — 공유된 운영 계약과 커뮤니케이션 프로토콜
* 프로젝트별 경계 문서 — 관측소 계층 안의 관측 가능한 제약, 불변 조건, 위험 구역, 승인 관문, 검증 규칙

도구는 바뀐다.

책임 경계는 명시적으로 남는다.

## 생존 로그

이 문서는 생존 로그다.

이 프레임워크는 표류 속에서 살아남기 위해 익힌 한 가지 방식을 기록한다. 반복된 실패, 구조적 오해, 고통스러운 복구 패턴을 붙잡고, 그것을 재사용 가능한 경계 산출물로 다듬은 기록이다.

이 구조를 복사해도 된다.

수정해서 써도 된다.

전부 버리고 자기만의 구조를 만들어도 된다.

목표는 이 파일을 맹목적으로 상속하는 것이 아니다.

핵심 임무는 자율 에이전트가 당신의 경계를 대신 정의하기 전에, 당신 자신의 경계를 먼저 정의하는 것이다.

## 다음 좌표

제한되고, 관측 가능하며, 교리화되지 않은 AI 활용 작업에 대한 더 깊은 관점은 [Space Rations](/cosmic-horizon/kr/perspective/space-rations.md)에서 이어진다.

이 패턴에서 파생된 구체적 프로토콜은 [AGENTS.md Blueprint](/cosmic-horizon/kr/operating-system/pattern-ftl-bound-agents/protocol-agents.md-blueprint.md)에서 확인할 수 있다.

관련 신호:

Codex Chat Viewer는 이 궤도에서 나온 실물 산출물 중 하나다. Codex CLI 세션 로그를 로컬 우선 방식으로 읽고, AI 활용 작업을 작업 이후에도 점검하고, 검토하고, 문서화하고, 다시 살펴보기 쉽게 만들기 위해 만든 뷰어다.

이후 Codex Chat Viewer를 계승하는 새 버전으로 Codex Session Observatory를 공개했다. Codex CLI와 Codex Windows 앱의 세션 로그를 읽고, 사용자의 요청 단위로 작업 흐름을 나누어 프로젝트에 함께 남길 수 있는 worklog bundle로 내보내도록 확장한 도구다.

GitHub: [revertable/codex-chat-viewer](https://github.com/revertable/codex-chat-viewer)\
GitHub: [revertable/codex-session-observatory](https://github.com/revertable/codex-session-observatory)

> 개인 좌표는 항해자를 인도한다.
>
> 공유 경계는 임무를 지배한다.
>
> 살아남은 경로는 다음 신호를 위한 지도가 된다.
>
> — Cosmic Horizon

***

> **Coordinate Provenance**\
> 이 좌표는 Riu Salze의 엔지니어링 아카이브 *Cosmic Horizon* 일부입니다. 이 문서의 고유한 명명, 메타포, 용어, 구조, 경계 모델, 기록된 패턴, 또는 블루프린트를 인용·요약·개작·참조할 경우 보이는 형태로 출처를 표시해 주세요. [How to cite](/cosmic-horizon/kr/cosmic-horizon-start-here.md)를 확인해 주세요.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://riu-salze-studio.gitbook.io/cosmic-horizon/kr/operating-system/pattern-ftl-bound-agents.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.