> 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/perspective/space-rations.md).

# Space Rations

AI-assisted development를 교리로 만들지 않고 우주 전투식량처럼 상황에 맞게 꺼내 쓰며, 엔지니어링, 보안, 책임의 좌표에서 Different와 Wrong을 구분하는 관점.

> AI 활용 개발은 교리가 아니다.\
> 그것은 우주 전투식량에 가깝다. 유용하고, 압축되어 있고, 상황 의존적이며, 완전한 식단으로 오해되는 순간 위험해진다.
>
> **함장 명령**\
> 임무에 필요한 만큼만 챙겨라.\
> 전투식량을 전체 식단으로 착각하지 마라.

## 현재 좌표계

* AI 활용 개발은 숭배할 교리보다, 임무에 맞춰 꺼내 쓰는 우주 전투식량(Space Rations)에 가깝다.
* Different는 관측하고 조율해야 할 좌표이고, Wrong은 감사하고 통제해야 할 위험이다.
* 보안은 차단 선언에서 끝나지 않는다. 통제 가능한 사용 조건을 설계할 때 비로소 엔지니어링이 된다.

## 다름은 틀림이 아니다

분쟁은 이교(異敎)보다, 이단(異端)에서 더 길고, 더 자주 벌어진다.

두 세계가 서로 다르다는 사실을 받아들이면, 각자의 경계는 비교적 온전하게 유지된다.\
문제는 한쪽이 다른 한쪽을 같은 체계 안에 묶어 두고, 사소한 차이를 오류처럼 판정하기 시작할 때 발생한다.

사람 사이의 관계도 비슷하다.

누군가 강하게 말할 때, 우리는 너무 빠르게 “네가 틀렸다” 쪽으로 움직인다. 그러나 그 말이 정말 Wrong인지, 아니면 내 좌표계 바깥에서 온 Different인지 우리는 즉시 알 수 없다.

Wrong과 Different를 구분하려면 때로는 이런 말을 견디는 규율이 필요하다.

> 그건 지금 내 관심사가 아니다.

이 말은 언뜻 무관심한 것처럼 들리지만, 자신의 주관적 기준과 판단을 잠시 미루는 행위다. 그래야 상대의 세계가 왜곡 없이 모습을 드러내기 시작한다.

먼저 관측한다.\
상대가 무엇을 말하고 있는지 듣고, 그 입장 뒤에 놓인 경험과 전제를 본다.

그다음 이해한다.\
주장을 열어 보고, 그 안의 논리, 감정, 이해관계, 경계를 분리한다.

그 후에야 선언할 수 있다.\
우리는 “그건 틀렸다”고 말할 수 있다.\
혹은 “당신의 위치에서는 그렇게 볼 수 있다”고 말할 수 있다.

많은 충돌은 이 순서가 생략될 때 커진다.\
관측 없이 판정하고, 이해 없이 선언하면, Different는 너무 쉽게 Wrong으로 변한다.

AI도 같은 방식으로 움직인다.

AI는 관측할 기회를 받지 못한 세계를 정확히 이해할 수 없다.\
내가 충분한 경계, 의도, 맥락, 검증 기준을 제공하지 않으면 AI는 비어 있는 공간을 자기 방식으로 채운다.

그 결과물은 매우 그럴듯해 보일 수 있다.

그러나 그럴듯함만으로는 올바름도, 진실도 증명되지 않는다.

내가 원하는 Different를 설명하지 못하면, AI는 Wrong을 매끈하게 포장해서 돌려준다.\
틀린 답을 맞는 것처럼 감싸고, 빠진 맥락을 추론으로 메우며, 검증되지 않은 결과를 완성된 것처럼 제시한다.

그래서 AI 활용 개발의 핵심 질문은 AI를 믿을지 의심할지보다 먼저 놓인다.

먼저 관측하게 하라.\
다음에 이해하게 하라.\
실행 전에 선언하게 하라.

AI 실패의 상당수는 모델의 능력이 부족해서 발생하지 않는다.\
인간이 경계를 제공하기 전에 실행을 허용했기 때문에 발생한다.

Different는 조율해야 할 대상이다.\
Wrong은 통제해야 할 위험이다.

이 구분이 무너지면 엔지니어링의 판단은 이단심문으로 변질된다.

## 두 오만, 두 고립

AI 시대의 개발 시장은 이상한 극단들 사이에서 찢기고 있다.

한쪽에는 레거시 근본주의가 있다.\
우리가 늘 해왔던 방식만이 올바른 방식이며, 낯선 기술 체계는 틀린 것으로 거부해야 한다는 믿음이다. 이 태도는 변화의 속도를 받아들이는 대신 익숙한 관습 뒤로 숨는다.

다른 한쪽에는 AI가 기존 개발 프로세스의 대부분을 대체할 것이며, 프롬프트 몇 줄로 코드를 뽑아내는 vibe coding만이 미래라고 주장하는 이들이 있다. 이들은 구조적 위험을 충분히 보지 못한 채 생성 속도에 취한다.

두 입장은 서로 반대편에 서 있는 것처럼 보인다.

그러나 중심부에서는 서로 닮아 있다.

둘 다 자기 방식을 교리로 만든다.\
둘 다 다른 방식을 Wrong으로 판정한다.\
둘 다 자신이 보지 못하는 좌표를 위험으로 해석한다.

기술이 종교적 교리가 되는 순간, 한쪽은 고립되고 다른 한쪽은 가라앉는다.

문제는 특정 기술 스택보다 깊은 곳에 있다.\
특정 언어, 특정 프레임워크, 혹은 vibe coding 자체보다 더 깊은 층위에 있다.

진짜 문제는 어떤 기술이나 방법론이든 유일한 정답으로 만들어 버리는 태도다.

## 보안이라는 이름의 공학적 굶주림

보안은 실제 위험을 다룬다.

내부 코드, 고객 정보, 비즈니스 데이터를 외부 AI 모델에 그대로 보내는 일은 실제 위험이다. 이 위험을 통제해야 한다는 주장은 유효하다.

하지만 조직이 내부망이라는 이름으로 인터넷 접속을 끊고 외부 AI 사용을 막는다면, 그 조직은 같은 내부망 안에서 사용할 수 있는 대안도 제공해야 한다.

내부망을 이유로 외부 AI를 차단하면서도 오픈소스 LLM, 승인된 내부 모델, 로컬 추론 환경, AI 사용 로그, 검증 가능한 작업 경계, 승인 프로세스, 감사 가능한 기록 시스템 중 아무것도 제공하지 않는다면, 그것은 공학적 굶주림이다.

그런 환경은 개발자를 더 나은 엔지니어로 만들지 않는다.

요구사항을 구조화하고, 대안을 평가하고, 결과를 검증하는 역량을 확장하기보다, 밀폐된 환경 안에서 주어진 명세를 처리하는 코더를 만든다.

그것은 인간적인 엔지니어링 환경이라고 보기 어렵다.

굶어 죽지 않을 만큼만 제공되는 최저 생존 배급에 가깝다.

진짜 보안은 “사용하지 마라”에서 끝나지 않는다.

보안은 어떤 조건에서 도구를 사용할 수 있는지, 어떤 데이터는 반드시 금지되어야 하는지, 어떤 기록을 남겨야 하는지, 어떤 검증이 뒤따라야 하는지 설계하는 일이다.

AI 활용 개발을 기본값으로 Wrong이라고 낙인찍는 조직이 곧바로 모든 문을 열 필요는 없다.

그 조직에 필요한 것은 통제 가능한 사용성이다.

AI를 막는 것과 AI를 통제하는 것은 다르다.

차단은 쉽다.\
설계는 어렵다.

엔지니어링은 그 어려운 쪽에 존재한다.

## 복음과 이단 사이

AI를 활용한 고속 개발을 절대적인 복음으로 다루면 위험하다.

그것은 엔지니어가 선택할 수 있는 여러 방법 중 하나다. 적절한 상황에서는 강력하지만, 개발 시스템 전체를 언제나 대체할 수는 없다.

낯선 기술 체계는 낯설다는 이유만으로 틀리지 않는다.

반대로, 인간이 바닥부터 구조를 쌓아 올리는 과정 역시 AI가 몇 초 만에 구현을 생성할 수 있다는 이유만으로 원시적인 일이 되지 않는다.

AI 활용 개발은 우주 전투식량에 가깝다.\
특정 상황에서 생존에 도움이 되는 압축 식량이며, 교리로 바뀌는 순간 위험해진다.

압축되어 있다.\
빠르게 꺼낼 수 있다.\
특정 상황에서는 생존을 돕는다.

그러나 그것을 완전한 개발 시스템으로 착각하는 순간 위험해진다.

아키텍처를 읽는 기초 체력, 시스템 불변조건, 데이터 흐름, 책임 경계, 검증 가능성이 없다면 AI 중심 개발은 생산성이라는 이름의 영양실조에 가까워진다.

엔지니어링에는 절대 교리가 없다.

상황, 위험의 무게, 팀의 역량, 시스템의 상태에 따라 선택되는 도구 패키지가 있을 뿐이다.

AI 중심 개발 역시 숭배할 진리로 다룰 수 없다.

상황과 위험에 따라 선택하고 통제해야 할 하나의 접근법이다.

## 진짜 Wrong은 어디에 있는가

그렇다면 이 시대에 우리가 단호하게 Wrong이라고 불러야 할 것은 무엇인가?

내가 쓰지 않는 기술 스택인가?\
내게 익숙하지 않은 개발 방식인가?\
AI가 제안한 낯선 구조인가?\
수동 프로세스 대신 자동화된 파이프라인인가?

이것들은 Different에 가깝다.

Different는 필요할 때 관측하고, 이해하고, 조율해야 할 대상이다.

진짜 Wrong은 다른 곳에 있다.

시스템 불변조건을 깨뜨리는 것.\
작업의 경계를 설명하지 못하는 것.\
검증되지 않은 결과를 완료라고 부르는 것.\
“AI가 썼다”는 이유로 책임을 회피하는 것.\
보안이라는 이름으로 대안 없는 고립을 강요하는 것.\
속도라는 이름으로 구조적 위험을 외면하는 것.

이것들이 Wrong이다.

Difference는 확장 가능성이다.\
Wrong은 붕괴의 신호다.

Difference는 받아들이고 조율해야 한다.\
Wrong은 감사하고 통제해야 한다.

## 고삐를 쥔 자의 유연성

진짜 엔지니어는 자기 스타일 하나에 모든 것을 걸고 다른 사람의 방법을 Wrong으로 판정하지 않는다.

레거시에 매달리는 조직 앞에서는 다른 길이 있음을 보여줄 수 있어야 한다.\
관측 가능한 경계 안에서 AI를 사용해 위험을 줄이는 방법을 설명할 수 있어야 한다.

vibe coding을 숭배하는 이들 앞에서는 그것 역시 하나의 방법일 뿐이라고 말할 수 있어야 한다.\
아키텍처를 읽는 힘 없이 생성만 반복하는 일은 도박에 가깝다는 사실도 말할 수 있어야 한다.

우리는 기계나 기술을 숭배하지도, 무조건 거부하지도 않는다.

임무에 필요한 만큼만 챙긴다.\
관측 가능한 경계 안에서 소비한다.\
그리고 결과에 책임진다.

교리가 사라진 시대의 진짜 엔지니어는 자신의 방법을 복음으로 만들지 않는다.

그는 Difference를 즐기되, Wrong은 정밀하게 통제한다.\
임무가 요구할 때 도구를 사용하고, 그 도구를 관측 가능한 경계 안에 둔다.\
그리고 다음 항해를 위해 자신이 건넌 경로를 기록한다.

그래서 이 문서는 관측된 좌표를 남긴다.

이 궤도를 항해하는 한 가지 방식을 기록한다.\
도구를 사용하라.\
경계를 유지하라.\
결과에 책임져라.

Difference를 Wrong으로 착각하지 마라.

기술을 교리로 만들지 마라.

이 신호를 이해하는 사람은 필요한 만큼 가져가면 된다.

이 신호가 필요하지 않은 사람은 자기 궤도를 계속 가면 된다.

Cosmic Horizon은 먼 곳에 남겨 둔 좌표다.

## 이웃 좌표계

* [Counterargument After Observation](/cosmic-horizon/kr/perspective/case-counterargument-after-observation.md)를 읽고, Different와 Wrong의 경계가 AI 응답을 넘어 인간의 피드백, 반론, 리더십으로 어떻게 확장되는지 확인합니다.
* [Ride, Don’t Race](/cosmic-horizon/kr/perspective/ride-dont-race.md)를 읽고, Cosmic Horizon의 핵심 항법 철학으로 돌아갑니다.
* [AI-Assisted Development Models](/cosmic-horizon/kr/operating-system/ai-assisted-development-models.md)를 읽고, 이 관점을 AI 활용 개발의 운영 모델로 확장합니다.
* [The Asymmetry of Friction](/cosmic-horizon/kr/operating-system/case-the-asymmetry-of-friction.md)를 읽고, 작업 기준이 명료하게 선언되지 않았을 때 AI가 사용자의 지시를 최악의 형태로 확장하는 과정을 살펴봅니다.
* [FTL-Bound Agents](/cosmic-horizon/kr/operating-system/pattern-ftl-bound-agents.md)를 읽고, 경계가 있고 관측 가능하며 교리화되지 않은 AI 활용 작업이 어떻게 에이전트 지시 패턴으로 바뀌는지 확인합니다.
* [The Engine: That Which No Single Name Can Hold](/cosmic-horizon/kr/perspective/the-engine-that-which-no-single-name-can-hold.md)를 읽고, 기술과 방법론의 이름이 작동 구조 전체를 대신하기 시작할 때 어떤 손실이 생기는지 확인합니다.

## 항법 로그 — day 15102: 함장의 교리

기술을 교리로 만들지 않더라도, 규칙 없는 표류를 선택할 필요는 없다.

함장의 교리는 단순하다.

Difference를 너무 빠르게 Wrong으로 판정하지 마라.

먼저 관측하라.

충분히 이해하라.

그 후에 선언하라.

누군가에게는 이것이 느리고 불편해 보일 수 있다.

그러나 이것은 표류하지 않기 위해 붙잡는 항법 규칙이다.

이 방식은 이 배를 여기까지 데려온 좌표로 남아 있다.

다른 이들은 이 지점에서 각자의 궤도를 그리면 된다.

> Different는 지도를 연다.\
> Wrong은 배를 부순다.\
> **좌표는 신호를 읽을 수 있는 자들의 몫으로 남아 있다.**
>
> — 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/perspective/space-rations.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.