> 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/the-burden-of-plain-speech.md).

# The Burden of Plain Speech

프롬프트의 모호성, 명료한 말, 그리고 구조화된 지시가 AI-assisted work를 통제하는 재사용 가능한 artifact로 바뀌는 과정을 다룬 운영 좌표.

> 항법 로그

## 현재 좌표계

* 프롬프트는 일회성 요청이기보다 오래 유지되는 설계된 artifact이다.
* 명료한 말은 깊은 사고에서 출발하고, 반복 가능한 지시 패턴으로 확장되며, 인간이 이해하고 책임질 수 있는 언어로 끝난다.
* 좋은 지시는 AI가 움직일 수 있는 세계를 정의해 드리프트(Drift)를 줄인다.

## 지시는 실행되기 전에 해석된다

지시는 실행되기 전에 해석된다.

이것이 우리가 먼저 받아들여야 할 첫 번째 차가운 현실이다.

AI는 인간의 문장을 복사하듯 순서대로 처리하지 않는다.

문장 안에서 목표를 찾는다.\
빠진 정보를 스스로 추론한다.\
모호한 빈칸을 자신이 학습한 패턴으로 채운다.\
서로 충돌하는 조건 사이에서 우선순위를 저울질한다.\
불확실한 지점은 그럴듯한 확신으로 이어 붙인다.

그래서 지시가 모호할 때도 AI는 멈추지 않는다.

대부분의 경우 질문도 하지 않는다.

그저 하나의 경로를 고른다.

그리고 그 경로는 사람이 원래 의도한 항로와 전혀 다른 방향으로 뻗어 나갈 수 있다.

“깔끔하게 정리해 줘”라고 말할 때, 시스템이 반드시 유지해야 할 핵심 요소는 무엇인가?

“단순하게 만들어 줘”라고 말할 때, 추상화의 하한선은 어디인가?

“자연스럽게 다듬어 줘”라고 말할 때, 원문의 날카로운 의도는 어디까지 살려야 하는가?

“좋게 만들어 줘”라고 말할 때, 그 “좋음”은 어떤 기준으로 측정되는가?

이 질문들이 지시 안에 고정되지 않으면 AI는 스스로 답의 형태를 만든다.

그 답은 표면적으로는 그럴듯할 수 있다.

하지만 당신에게 필요했던 답과는 다른 결과일 수 있다.

이 현실을 받아들이는 순간, 프롬프트는 단순한 문장 쓰기의 영역을 넘어선다.

프롬프트는 의도, 제약, 맥락, 판단 기준, 금지 사항, 검증 조건을 함께 묶는 설계된 artifact가 된다.

좋은 지시의 기준은 길이로 판가름되지 않는다.

좋은 지시는 실행에 필요한 자율성은 남기되, 위험한 오해의 공간을 좁힌다.

프롬프트를 잘 쓴다는 것은 기계 앞에 말을 많이 쏟아 붓는 기술보다도, AI가 다르게 해석해서는 곤란한 경계선을 고정하는 일에 가깝다.

## 같은 문장, 다른 지시

같은 프롬프트도 서로 다른 결과로 갈 수 있다.

겉으로는 완전히 같은 문장처럼 보일 수 있다.

같은 단어를 쓰고, 같은 요구사항을 담고, 같은 목표를 향해 움직이는 것처럼 보일 수 있다.

그러나 그 문장이 AI 시스템 안으로 들어가는 순간, 고정된 명령의 성질은 흔들린다.

그 문장은 해석을 기다리는 불안정한 signal이 된다.

같은 표현도 맥락에 따라 전혀 다르게 읽힌다.

이전 대화의 희미한 잔여물이 문장에 달라붙을 수 있다.

주변 파일 구조가 지시의 방향을 비틀 수 있다.

모델의 추론 경로가 예측하기 어려운 방식으로 다른 결론을 밀어 올릴 수 있다.

“이걸 정리해 줘”라는 단순한 요청은 어느 경우에는 요약이 되고, 어느 경우에는 파괴적인 재구성이 되며, 또 다른 경우에는 의도하지 않은 삭제로 이어질 수 있다.

“개선해 줘”라는 모호한 요청은 가벼운 문장 수정이 될 수도 있고, 거대한 구조 변경이 될 수도 있으며, 전체 계획의 방향을 흔드는 재작성으로 번질 수도 있다.

“스케일해 줘”라는 명령은 어떤 AI에게는 성능 최적화로 읽히고, 다른 AI에게는 인프라 확장으로 읽히며, 또 다른 AI에게는 문서를 더 길고 화려하게 만드는 일로 해석될 수 있다.

프롬프트는 돌에 새겨진 불변 명령처럼 작동하기 어렵다.

프롬프트는 비결정적 해석 시스템 안으로 던져지는 불안정한 signal이다.

따라서 같은 문장을 보냈다는 사실만으로 같은 지시가 전달되었다고 볼 수 없다.

핵심은 문장을 보냈다는 사실보다 더 깊은 곳에 있다.

**핵심은 그 문장이 기계에게 얼마나 넓고 위험한 해석 공간을 열어 주었는가에 있다.**

## 더 깊게 생각하라

명료하게 말하려면 먼저 더 깊게 생각해야 한다.

처음부터 단순해 보이는 말은 대개 정제된 단순함보다 누락에 가깝다.

중요한 전제를 빠뜨린다.

위험한 엣지 케이스를 빠뜨린다.

시스템이 무너졌을 때의 복구 경로를 빠뜨린다.

책임의 경계를 빠뜨린다.

그 작업이 왜 존재해야 하는지에 대한 근본적인 이유도 빠뜨린다.

그 결과 프롬프트는 짧아진다.

그러나 지시는 종이 벽처럼 약해진다.

AI에게 “이 기능 구현해 줘”라고 말하는 일은 쉽다.

하지만 그 짧은 문장 안에는 비어 있는 공간이 너무 많다.

이 기능은 왜 필요한가?

어떤 사용자 페르소나를 위한 기능인가?

어떤 입력은 단호하게 거절해야 하고, 어떤 오류는 반드시 포착해야 하는가?

실패했을 때 시스템은 어떤 상태로 롤백되어야 하는가?

레거시 구조 중 절대 건드리면 안 되는 부분은 어디인가?

결과가 올바르다는 사실은 어떤 파이프라인을 통해 검증되는가?

이 질문들을 해부하지 않은 채 던져진 프롬프트는 해석 권한을 기계에게 지나치게 많이 넘겨준다.

얕은 사고는 짧은 프롬프트를 만든다.

그 짧음은 명료함처럼 보이지만 실제로는 진공이다.

고전적인 컴퓨팅 시대의 법칙은 단순했다.

*Garbage In, Garbage Out.*

나쁜 입력은 나쁜 출력, 눈에 보이는 오류, 혹은 곧바로 깨지는 시스템을 만들었다.

생성형 AI 시대에는 이 법칙이 더 위험한 형태로 바뀐다.

약한 입력도 그럴듯하고, 매끈하고, 아름답게 구조화된 환상으로 변환될 수 있다.

얕은 프롬프트는 때로 결함을 감춘다.

때로는 **우아한 쓰레기**를 만든다.

깊은 사고는 프롬프트의 길이보다 경계의 정확도를 바꾼다.

명시해야 할 것과 걷어내야 할 것을 분리한다.

핵심 제약을 보존한다.

장식적인 소음을 제거한다.

검증 기준을 앞으로 끌어낸다.

AI가 넘어서는 안 되는 경계선을 그린다.

그러므로 “더 깊게 생각하라”는 말은 철학적 장식을 넘어선다.

그것은 런타임 안전장치다.

생각이 깊어질수록 지시는 덜 떠내려간다.

## 생각을 확장하라

좋은 생각을 개인의 머릿속에만 머물게 해서는 의미가 없다.

그 생각은 확장되어야 한다.

나만 겨우 알아볼 수 있는 지시는 취약하다.

현재 모델 버전만 간신히 이해하는 지시도 취약하다.

현재 세션의 임시 맥락 안에서만 작동하는 지시 역시 취약하다.

단단한 지시는 시간을 견딘다.

전혀 다른 모델이 읽어도 핵심 구조를 보존한다.

몇 달 뒤 다시 읽어도 이 구조가 왜 설계되었는지 드러난다.

동료가 읽어도 같은 판단 기준과 같은 위험 매트릭스를 추적할 수 있다.

이를 위해 지시에는 구조가 필요하다.

명확한 목표가 필요하다.

충분한 맥락이 필요하다.

단단한 제약이 필요하다.

성공과 실패를 구분할 검증 지표가 필요하다.

엄격한 금지 사항이 필요하다.

이것이 생각을 확장한다는 뜻이다.

확장된 생각은 크기보다 반복 가능성으로 판별된다.

반복 가능하고, 다른 맥락으로 이식 가능하며, 다른 사람이 실행해도 원래 방향을 보존해야 한다.

AI에게 한 번 던지고 사라지는 소모품을 넘어, 엔지니어링을 위한 영속적인 좌표가 된다.

프롬프트가 이 단계를 통과하는 순간, 그것은 일회성 대화를 벗어난다.

artifact가 된다.

지시는 기록될 수 있다.

버전 관리될 수 있다.

비교될 수 있다.

재사용될 수 있다.

그리고 무엇보다 감사(audit)될 수 있다.

확장된 사고가 없으면 AI 협업은 즉흥적인 도박 수준의 코드 가챠가 된다.

확장된 사고가 있으면 AI 협업은 통제 가능한 인프라가 된다.

## 마지막에는 명료하게 말하라

마지막 단계에서야 우리는 명료하게 말해야 한다.

쉽고 평이한 언어는 깊은 사고가 끝까지 압축된 결과여야 한다.

명료한 말은 엔지니어링의 복잡한 현실을 정면으로 통과해 만들어진다.

명료한 말은 극단적인 복잡도를 인간의 판단이 실제로 소화할 수 있는 최종 형태로 압축하는 고도 추상화다.

좋은 지시의 힘은 인상적인 전문용어나 유행어 장식에서 나오지 않는다.

좋은 지시는 실행자가 무엇을 해야 하는지 즉시 이해하게 만드는 문장이다.

좋은 설명은 정제되지 않은 복잡도를 그대로 노출하는 대신, 그 복잡도를 내포한다.

독자가 핵심 구조를 잃지 않도록 본질만 남긴다.

AI는 거의 무한한 양의 결과물을 만들어낼 수 있다.

그러나 인간은 이해할 수 없는 결과물에 책임을 질 수 없다.

AI는 수만 줄의 기계 로그를 만들 수 있다.

그러나 인간이 해석할 수 없는 로그는 결정으로 번역되기 어렵다.

AI는 놀라울 만큼 복잡한 리팩토링을 수행할 수 있다.

그러나 그 변경의 의도를 평이한 언어로 설명할 수 없다면, 그 코드는 팀의 신뢰를 얻지 못한다.

그래서 명료한 말은 단순한 친절 그 이상이다.

그것은 책임을 감당하기 위해 요구되는 엔지니어링 의무다.

작업의 의도는 평이한 언어로 설명될 수 있어야 한다.

모듈 변경의 근거는 평이한 언어로 정당화될 수 있어야 한다.

검증 지표는 평이한 언어로 제시될 수 있어야 한다.

시스템이 깨졌을 때 가장 먼저 들여다볼 지점도 평이한 언어로 짚을 수 있어야 한다.

명료한 말은 복잡한 사고가 검증과 확장의 필터를 통과한 뒤 남는 최종 형태다.

더 깊게 생각하라.

그 생각을 확장하라.

그리고 마지막에는 명료하게 말하라.

이 세 단계는 하나의 정밀한 파이프라인으로 묶여 있다.

## 프롬프트 디자인 패턴은 자산이 된다

깊게 생각하고, 그 생각을 명료한 언어로 옮기는 고통스러운 과정을 반복하면 이상한 일이 일어나기 시작한다.

수많은 문장 사이에서 반복되는 지시 패턴이 드러난다.

장식적인 표현과 특정 구현의 조각들을 걷어내고 나면, 매번 바뀌지 않는 핵심 제약과 메타 규칙이 뼈대처럼 모습을 드러낸다.

이 반복 지시는 단순한 재사용 문구보다 더 큰 의미를 갖는다.

그것은 인간 의도의 추상화된 컴포넌트다.

이 컴포넌트들은 인간 operator에게 가장 강력한 자산이 된다.

기계에게 지시할 때는 위험한 드리프트를 줄이는 단단한 가드레일(guardrail)이 된다.

기계 산출물을 검증할 때는 안정적인 감사 지표가 된다.

새로운 맥락이 들어올 때는 이동 가능한 평가 도구가 된다.

이제 매번 모든 문장을 처음부터 즉흥적으로 만들어낼 필요가 줄어든다.

인간 operator는 검증된 지시 자산들을 조합하면서 더 큰 메타 시스템을 통치하기 시작한다.

명료한 말을 끝까지 밀어붙이는 잔혹한 훈련은 결국 오래 남는 엔지니어링 자산을 만든다.

이 아이디어의 다음 좌표는 [FTL-Bound Agents](/cosmic-horizon/kr/operating-system/pattern-ftl-bound-agents.md)에 있다. 재사용 가능한 지시 자산을 AI-assisted work의 경계 시스템으로 바꾸는 패턴이다.

## 결론 (Conclusion)

AI 시대의 지시는 단순한 명령 목록보다 더 무겁다.

지시는 기계에 의해 해석된다.

해석은 필연적으로 드리프트를 일으킨다.

그리고 드리프트한 해석은 시스템 전체의 결과를 바꿀 수 있다.

그러므로 인간은 프롬프트를 가볍게 던지고 결과를 기다리는 관객의 자리에 머물 수 없다.

> **기도메타는 결코 운영모델이 될 수 없다.**

인간은 의도 자체를 설계하는 아키텍트가 되어야 한다.

우리는 진짜 원하는 것이 무엇인지 더 깊게 파고들어야 한다.

그 생각이 반복 가능하고 감사 가능한 프레임워크로 확장될 수 있도록 인프라를 세워야 한다.

그리고 마지막 이정표에서, 그 거대한 복잡도를 인간이 이해하고 책임질 수 있는 언어로 다시 번역해야 한다.

명료하게 말한다는 것은 통제의 고도화다.

통제하기 어려운 복잡도를 판단 가능한 구조로 번역하는 일이다.

AI가 기계의 언어로 수많은 가설을 생성한다면, 인간은 가능성의 소음 한가운데에서 명확한 가치의 프레임을 선언해야 한다.

좋은 프롬프트의 가치는 화려한 한 문장에서 나오지 않는다.

좋은 프롬프트는 기계가 드리프트할 공간을 좁히는, 해석 가능한 세계를 정의한다.

그리고 반복을 통과한 좋은 지시는 기계 루프를 통치하기 위한 오래 남는 가드레일(guardrail)이 된다.

좋은 설명은 단순 요약보다 더 엄격한 행위다.

그것은 복잡한 의도를 인간이 자신의 이름을 걸고 책임질 수 있는 형태로 축소하는 일이다.

> **명료한 말은 깊은 사고가 규모와 검증을 통과한 뒤 남는 최종 형태다.**

🧭

## 이웃 좌표계

* [AI-Assisted Development Models](/cosmic-horizon/kr/operating-system/ai-assisted-development-models.md)를 읽고, 명확한 지시 설계를 AI-assisted development의 더 큰 운영 모델 안에 배치합니다.
* [The Asymmetry of Friction](/cosmic-horizon/kr/operating-system/case-the-asymmetry-of-friction.md)를 읽고, AI의 기본 응답 기준과 사용자의 working criteria가 반복적으로 어긋날 때 교정 비용이 감정 비용과 운영 비용으로 증폭되는 과정을 살펴봅니다.
* [The Paradox of the Human Auditor](/cosmic-horizon/kr/operating-system/the-paradox-of-the-human-auditor.md)를 읽고, 모호한 지시가 검증 부담을 어떻게 키우는지 확인합니다.
* [Why We Study](/cosmic-horizon/kr/perspective/why-we-study.md)를 읽고, AI 산출물을 판단하고 다듬고 책임지기 위해 필요한 문해력과 명료한 언어의 관계를 연결합니다.
* [FTL-Bound Agents](/cosmic-horizon/kr/operating-system/pattern-ftl-bound-agents.md)를 읽고, 재사용 가능한 지시 자산이 AI-assisted work의 boundary system으로 확장되는 방식을 살펴봅니다.

***

> **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 dynamically 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/the-burden-of-plain-speech.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 `build a script that syncs our docs to a CMS` 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.