> 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/codex-as-an-execution-layer.md).

# Codex as an Execution Layer

관측과 판단은 인간이 책임지고, Codex는 선언된 경계 안에서 실행하도록 배치한 개인의 AI 활용 개발 운영 방식.

> 항법 로그

## 현재 좌표계

* 좋은 도구는 내 작업 방식과의 적합성을 기준으로 선택한다.
* 이 운영 체계에서 ChatGPT는 생각과 질문을 정제하고 문서화하는 공간이며, Codex는 프로젝트 안에서 실제 변경을 수행하는 실행 계층이다.
* AI의 도움으로 판단을 정밀하게 다듬는다. 무엇을 만들고 어디까지 위임할지, 결과를 어떻게 수용할지는 인간이 책임진다.
* 실행에 앞서 목표, 맥락, 제약 조건, 완료 기준을 작업의 좌표로 남긴다.

## 왜 Codex인가

좋은 도구는 지금 떠나는 항해에 얼마나 잘 들어맞는가로 판가름 난다.

**성능, 비용, 작업 흐름.** 나는 이 세 가지를 함께 본다.

ChatGPT는 2023년 무렵부터 사고 정리, 질문 정제, 개발 문제 검토, 문서 작성에 활용해 온 익숙한 작업 도구다. 익숙함에 더해, 실제 작업에서의 역할도 분명해졌다.

내 작업에서는 코드를 작성하기 전에 긴 대화가 선행된다. 고객의 요구를 해석하고 문제를 좁히며, 보존할 영역과 변경할 범위를 정한다. 그다음 저장소를 읽고 파일 수정과 명령 실행을 담당할 도구가 필요해진다.

그래서 **ChatGPT에서의 대화**와 **Codex에서의 프로젝트 실행**으로 역할을 구별했다.

이 글에서 Codex는 프로젝트 맥락을 읽고 파일 수정 및 명령 실행을 담당하는 환경을 뜻한다. 내가 이 도구를 실행 계층에 배치한 이유와 작업 방식을 기록한다.

## 함교에서 결정할 일

개발은 코드를 입력하기 훨씬 전부터 시작된다.

“검색 화면을 간단하게 해 달라”는 요청을 받으면, 먼저 불편이 생기는 지점을 찾는다. 입력 과정인지, 결과의 가독성인지, 응답 속도인지에 따라 해결책이 달라진다. 그 과정에서 무엇을 줄이고 무엇을 남길지도 결정한다.

내가 사전에 결정할 사항은 다음과 같다.

* 해결할 문제와 화면이 도달할 최종 목표
* 이번 작업의 포함 범위와 제외 범위
* 유지해야 할 기존 시스템의 동작과 경계
* AI에게 허용할 제안 범위와 직접 결정할 사항
* 결과 수용 기준과 실패했을 때 돌아갈 지점

AI는 질문을 던지고 대안을 비교하며 빠진 조건을 짚어준다. 나는 그 도움으로 판단을 더 정밀하게 다듬고, 고객의 실제 요구와 맞춰 본다.

**함교에서 좌표를 정하는 책임은 내게 있다. Codex는 그 좌표 안에서 움직이는 실행 계층이다.**

## 실행 전에 좌표를 남긴다

> Pre-AI: code without docs.\
> Post-AI: docs without code.

AI가 코드를 작성할 수 있을수록 **인간은 실행을 이끌 판단의 기록을 먼저 남겨야 한다.**

여기서 문서는 실행의 입력값이다. “깔끔하게 고쳐 줘”라는 요청에 앞서, 왜 바꾸는지와 보존할 구조, 허용할 변경 범위를 명시한다.

한 번의 작업 지시에는 적어도 네 가지 좌표가 필요하다.

| 좌표          | 확인할 질문                      |
| ----------- | --------------------------- |
| Goal        | 무엇이 달라져야 하는가?               |
| Context     | 어떤 사용자 요구와 기존 구조를 이해해야 하는가? |
| Constraints | 무엇을 보존하고, 어디까지 수정할 수 있는가?   |
| Done when   | 무엇을 확인해야 완료라고 부를 수 있는가?     |

이 네 가지는 Codex가 자의적인 추론으로 메워야 할 빈칸을 줄여 주는 경계다.

AGENTS.md 같은 지침 파일은 여러 작업에 걸쳐 유지할 프로젝트 규칙을 보존한다. 개별 작업의 목표와 완료 기준은 그 위에 쌓는다. 이렇게 지시를 나누어 기록하면 작업의 맥락과 결정 근거를 나중에도 읽고 검토할 수 있다.

## 기계실에서 실행하고, 증거를 남긴다

좌표가 정해지면 Codex는 실제 프로젝트 안에서 움직인다.

파일과 맥락을 읽고 코드를 수정하며, 필요한 명령과 테스트를 실행한다. 그리고 사람이 결과를 판단할 수 있도록 변경 내역과 실행 결과를 남긴다.

나는 다음을 확인한다.

* 선언된 범위를 지켰는가?
* 요구한 동작이 검증되었는가?
* 실행하지 못한 검사와 남은 위험이 드러났는가?
* 결과에 문제가 생겼을 때 변경 경로를 추적해 복구할 수 있는가?

생성 속도가 빨라질수록 결과를 관측하고 복구하는 기록이 중요해진다. 실행은 Codex에 맡기고, **완료 판정은 결과와 증거를 대조해 직접 내린다.**

## 분리는 비용에 관한 운영 결정이다

상위 단계에서 깊이 생각하는 시간은 하위 단계의 반복 작업과 복구 비용을 줄이기 위한 투자다.

요구를 좁힌 뒤 실행하면 첫 결과가 나오기까지 시간이 더 들 수 있다. 대신 변경 범위와 검증 기준이 명확해져 검토, 재지시, 회귀 확인, 복구에 쓰는 비용을 관리할 수 있다. 나는 코드 생성 시간과 함께 이 비용도 본다.

도구를 고를 때는 모델의 성능뿐 아니라 사고를 정리하는 공간과 프로젝트 실행 공간의 연결 방식, 사용량과 비용 구조까지 살펴본다. 가격과 이용 한도는 바뀌더라도 **판단을 충분히 정제한 뒤 실행에 넘긴다**는 운영 원칙은 유지된다.

이 작업 흐름이 내 방식에 맞기 때문에 Codex를 선택했다.

## 도구가 바뀌어도 경계는 남는다

ChatGPT와 Codex의 분리는 현재 내가 선택한 배치다. 다른 에이전트를 쓰더라도 작업의 경계를 설계하는 질문은 같다.

무엇을 읽어야 하는가? 어디까지 움직일 수 있는가? 어떤 결정에는 사람의 확인이 필요한가? 무엇으로 완료를 검증하고 언제 멈춰야 하는가?

도구가 계획과 검토까지 더 많이 수행하게 되면 위임할 수 있는 작업의 범위도 넓어진다. **작업은 위임하고, 그 범위와 결과에 관한 책임은 명확하게 남긴다.**

## 결론 (Conclusion)

Codex는 내가 정한 항로를 따라 기계실에서 동력을 밀어주는 실행 엔진이다.

먼저 관측하고, 요구를 번역하며, 경계를 선언한다. Codex는 그 안에서 구현과 검사를 맡아 흔적을 남긴다. 나는 결과가 처음 요구와 맞는지 판단하고, 필요하면 좌표를 수정해 다시 출발한다.

AI가 더 빠르게 구현할수록 인간은 더 선명하게 관측해야 한다.

**그래서 Codex를 사용한다. 도구란 그래야 한다.**

⛵

## 이웃 좌표계

* [Ride, Don’t Race](/cosmic-horizon/kr/perspective/ride-dont-race.md) — AI와 경주하는 대신 고삐를 쥐는 관점.
* [AI-Assisted Development Models](/cosmic-horizon/kr/operating-system/ai-assisted-development-models.md) — 관측 시스템과 개발 모델을 통해 이 작업 방식을 더 넓게 배치하는 지도.
* [The Burden of Plain Speech](/cosmic-horizon/kr/operating-system/the-burden-of-plain-speech.md) — 모호한 의도를 실행 가능한 지시로 번역하는 문제.
* [FTL-Bound Agents](/cosmic-horizon/kr/operating-system/pattern-ftl-bound-agents.md) — 에이전트 지침을 지속적인 작업 경계로 만드는 패턴.
* [The Gravity Behind Market Language](/cosmic-horizon/kr/perspective/the-gravity-behind-market-language.md) — 도구의 이름 뒤에서 구조·비용·위험·책임을 읽는 관점.

***

> **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/codex-as-an-execution-layer.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.