Concept Hub

미메시스 엔지니어링

좋은 것을 따라 하라는 말은 너무 약하다.

AI에게 “잘 만들어줘”, “귀엽게 해줘”, “카카오톡 이모티콘 느낌으로 해줘”, “게임처럼 만들어줘”라고 말하면 결과는 대체로 평균으로 간다.

평균적인 귀여운 캐릭터. 평균적인 앱 UI. 평균적인 위젯 카드. 평균적인 방 꾸미기. 평균적인 알림 문구.

내가 실제 프로젝트에서 배운 것은 이것이다.

미메시스 엔지니어링은 AI에게 표면을 닮게 시키는 작업 방식이 아니다. 이미 시장, 연구, 제품, 커뮤니티, 오픈소스에서 검증된 원본의 작동 문법을 찾아서, 그것을 내 프로젝트의 객체, 상황, 화면, 보상, 감정, UX 흐름으로 다시 작동하게 만드는 운영 프레임이다.

현재 상태

항목상태
이 페이지public draft / live route verified
방법론내가 실제 AI-native 작업에서 쓰는 운영 프레임
공개 증거manifesto, prompt pack, artifact-level essay, QuantFlow -> Alpha Court directional case study, site modernization audit artifact, Alpha Court thesis-result-score contract artifact
아직 아닌 것업계 표준, 외부 고객 성과가 검증된 컨설팅 방법론, universal methodology
다음 proofAlpha Court의 실제 redacted thesis -> result -> score run과 외부/제품 표면별 proof contract 확장

정의 다시 쓰기

미메시스 엔지니어링의 잘못된 정의는 이렇다.

잘못된 정의

레퍼런스를 보고 비슷하게 만들어라.
카카오톡 이모티콘 느낌으로 만들어라.
귀엽게 만들어라.
위젯스럽게 만들어라.
게임처럼 만들어라.

이 요청은 AI에게 기준을 주는 것처럼 보이지만, 실제로는 추상어를 던지는 일에 가깝다. AI는 레퍼런스의 작동 구조를 가져오기보다 평균적인 귀여움, 평균적인 앱 UI, 평균적인 위젯 카드, 평균적인 방 꾸미기로 회귀한다.

올바른 정의

검증된 원본을 찾는다.
그 원본이 왜 작동하는지 분해한다.
그림체가 아니라 구조를 뽑는다.
구조를 내 프로젝트의 객체와 관계에 매핑한다.
반드시 해야 할 것과 절대 하면 안 되는 것을 명령화한다.
산출물 형식을 고정한다.
골든 예시와 검수 기준으로 오차를 줄인다.
기록하고 폐기하고 업데이트한다.

그래서 내가 지금 쓰는 정의는 더 좁고 더 실무적이다.

AI에게 “잘 만들어라”라고 시키는 것이 아니라, 이미 시장이나 연구, 제품, 커뮤니티에서 검증된 대상의 작동 문법을 찾아서 내 프로젝트의 객체, 상황, 화면, 보상, 감정, UX 흐름으로 변환하게 만드는 기술.

복사가 아니라 구조적 모방이다. 좋은 것을 따라 하라는 말이 아니라, 왜 좋은지 분해해서 내 시스템 안에서 다시 작동하게 만드는 일이다.

Current Proof Contract

Mimesis Engineering을 public working frame 이상으로 주장하려면, 각 공개 case는 최소한 아래 여섯 가지를 가져야 한다.

  1. 이름이 붙은 primary/original source card.
  2. 원본에서 배울 것과 절대 복사하면 안 되는 redline.
  3. target project의 객체와 관계로 옮긴 ontology mapping.
  4. AI가 따라야 할 output contract와 golden example.
  5. 실제 validation result.
  6. 이 결과로 주장할 수 있는 것과 아직 주장하지 않는 것의 claim boundary.

현재 공개 증거는 이 방법을 내 블로그와 AI-native 작업에 적용 중인 self-applied working frame으로 지지한다. 외부 outcome, 업계 표준, 검증된 컨설팅 상품이라는 주장은 아직 하지 않는다.

Use This For

  • AI가 만든 제품, 글, 코드, 랜딩 페이지가 평균값으로 흐르는지 점검할 때.
  • 레퍼런스를 넣었는데 결과가 표면 스타일 복사로만 끝날 때.
  • 프로젝트의 캐릭터, 화면, 보상, 기록, 위젯, 알림 같은 객체를 하나의 시스템으로 묶어야 할 때.
  • “좋게 만들어줘” 대신 명령, 금지선, 산출물 계약, 검수 기준을 만들고 싶을 때.

빠른 길

  1. 원본을 찾는다. 가능한 한 공식 문서, 논문, 특허, 유지되는 오픈소스, 실제 제품, 플랫폼 문서, 공개 운영 자료를 먼저 본다.
  2. 원본의 표면이 아니라 작동 문법을 분해한다.
  3. 내 프로젝트의 객체와 관계로 번역한다.
  4. 반드시 해야 할 명령과 절대 하면 안 되는 금지선을 만든다.
  5. 산출물 계약과 골든 예시로 AI의 오차를 줄인다.
  6. 검수 결과와 폐기한 방향을 메모리에 남긴다.

한 문장

미메시스 엔지니어링은 AI에게 추상적 취향을 말하는 것이 아니라, 검증된 원본의 작동 문법을 분해하고, 그것을 내 프로젝트의 온톨로지, 명령, 금지선, 산출물 계약, 골든 예시, 검수, 메모리로 변환해 AI가 오차를 줄이며 실행하게 만드는 작업 프레임이다.

더 짧게 말하면:

좋은 것을 따라 하라는 게 아니라, 왜 좋은지 분해해서 내 시스템 안에서 다시 작동하게 만드는 일이다.

왜 이전 정의가 부족했나

처음에는 미메시스를 “전문가가 실제로 만든 산출물을 기준으로 삼는 방법”이라고 정의했다.

그 정의는 맞다. 하지만 직접 AI에게 일을 시켜보면 병목은 한 단계 더 구체적이었다.

좋은 레퍼런스를 넣어도 AI는 자주 표면을 평균낸다.

귀여운 캐릭터 레퍼런스
+ 카카오톡 이모티콘
+ 방 꾸미기 앱
+ 위젯 앱
+ 게임 보상 루프
= 정체가 흐린 귀여운 무언가

문제는 레퍼런스가 부족한 것이 아니라, 레퍼런스를 내 프로젝트의 언어로 번역하는 장치가 부족한 것이었다.

그래서 미메시스는 단순히 원본을 모으는 일이 아니다. 원본을 분해하고, 번역하고, 명령화하고, 검수하고, 기억하는 운영 방식이다.

약한 미메시스와 강한 미메시스

약한 미메시스강한 미메시스
비슷하게 만들어달라고 한다왜 작동하는지 분해한다
그림체, 색감, 말투를 따라 한다상황, 보상, 감정, 반복 행동을 가져온다
레퍼런스를 한 덩어리로 던진다레퍼런스를 역할별로 나눈다
결과물이 닮았는지 본다내 시스템 안에서 다시 작동하는지 본다
AI가 평균을 낸다AI가 계약을 따른다

강한 미메시스는 “A처럼 만들어줘”가 아니다.

강한 미메시스는 이렇게 묻는다.

A는 어떤 상황에서 쓰이는가?
사용자는 왜 다시 쓰는가?
작은 화면에서도 왜 읽히는가?
어떤 감정과 보상을 연결하는가?
어떤 요소는 절대 복사하면 안 되는가?
이 구조를 내 프로젝트의 어떤 객체와 화면으로 옮길 것인가?

핵심 공식

내가 실제 작업에서 쓰는 공식은 이렇다.

검증된 원본
-> 작동 문법 분해
-> 내 프로젝트 온톨로지에 매핑
-> 필수 명령화
-> 금지선 설정
-> 산출물 계약
-> 골든 예시
-> 검수
-> 메모리화

영어로 압축하면:

Reference
-> Decomposition
-> Translation
-> Command
-> Validation
-> Memory

중요한 것은 Translation이다. 원본을 그대로 복사하는 것이 아니라, 원본이 해결하던 역할을 내 제품의 객체와 관계로 옮겨야 한다.

예시: 왜 쉬어콩인가

아래 쉬어콩 예시는 이 방법론의 전체 proof가 아니다. 한 AI 작업에서 반복해서 드러난 실제 문제, 즉 “좋은 레퍼런스를 줬는데도 AI가 평균적인 귀여움으로 흐르는 현상”을 보여주는 작은 사례다.

사이트의 공개 proof stack은 Alpha Court, Mimesis Audit, Operator OS, MFH, Meta로 이어진다. 쉬어콩은 그중 캐릭터·방·기록·위젯·알림처럼 여러 객체가 동시에 묶이는 제품 문제를 설명하기 좋은 예시로 둔다.

1. 문제를 위치 단위로 고정한다

AI에게 “전체적으로 더 좋게 해줘”라고 말하면 AI는 전체적으로 흐려진다.

문제는 반드시 위치, 영향, 필요한 전문성으로 잘라야 한다.

[Problem Packet]

위치:
문제:
영향:
필요 전문가:
현재 결과물에서 보이는 증상:
원하는 체감:
절대 하면 안 되는 방향:

예를 들어 쉬어콩 작업에서는 이렇게 잡는다.

위치:
캐릭터 정체성

문제:
귀엽지만 콩보다 무, 동물, 일반 마스코트처럼 보인다.

영향:
쉬어콩이라는 이름과 형태가 붙지 않고, 캐릭터 IP감이 약해진다.

필요 전문가:
캐릭터 아트 디렉터 + 2D 캐릭터 애니메이션 디렉터

원하는 체감:
작은 크기에서도 한눈에 “쉬어콩”으로 보인다.

절대 하면 안 되는 방향:
강아지 귀, 토끼 귀, 클로버 몸체, 무처럼 긴 몸, 일반 마스코트화.

이렇게 쓰면 AI가 문제를 “귀여움 부족”으로 오해하지 않는다. 문제는 귀여움이 아니라 정체성이다.

2. 레퍼런스를 역할별로 나눈다

레퍼런스를 한꺼번에 주면 AI는 섞는다.

감정 리액션
+ 포즈
+ 방 꾸미기
+ 위젯
+ 스티커북
+ 알림
= 평균적인 귀여운 앱

그래서 레퍼런스는 역할별로 나눠야 한다.

REF-A: 감정 리액션 참고
REF-B: 포즈와 몸짓 참고
REF-C: 선, 질감, 축소 가독성 참고
REF-D: 짧은 문구 참고
REF-E: 미니 소품 참고
REF-F: 수집 UI 참고
REF-G: 방과 세계관 소품 참고
REF-H: 절대 복사 금지 사례

각 레퍼런스에는 반드시 아래 네 줄이 붙어야 한다.

배울 것:
절대 베끼면 안 되는 것:
내 프로젝트에 적용할 방식:
내 프로젝트에서 다르게 만들 점:

이 네 줄이 없으면 AI는 모방을 스타일 복사로 오해한다.

작은 source card 예시는 이렇게 생긴다.

[REF-WAI-APG-DIALOG]

이름:
WAI-ARIA APG Dialog Pattern

출처:
https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/

유형:
공식 접근성 패턴

배울 것:
dialog가 열리면 focus가 내부로 이동하고, Tab은 dialog 안에서 순환하며,
Escape로 닫히고, 닫힌 뒤 호출자에게 focus가 돌아가야 한다.

절대 복사 금지:
문서의 예시 DOM을 그대로 베끼지 않는다.
내 사이트의 command palette 역할과 구조에 맞게 필요한 keyboard contract만 옮긴다.

적용:
CommandPalette, SearchInput, ActionsList, ResultsList, CloseButton

검수 기준:
키보드만으로 열기, 이동, 실행, 닫기, 호출자 focus 복귀가 가능해야 한다.

3. 원본을 표면이 아니라 문법으로 분해한다

예를 들어 카카오톡 이모티콘을 참고한다고 하자.

나쁜 요청은 이렇다.

카카오톡 이모티콘 느낌으로 귀엽게 만들어줘.

좋은 요청은 다르다.

카카오톡 이모티콘을 그림체 복사용으로 쓰지 마라.
감정 리액션 상품으로 분해해라.

분해 기준:
- 작은 크기에서 읽히는 실루엣
- 한 문장 이하의 감정 문구
- 대화 상황에서 바로 쓰이는 표정
- 반복 구매 가능한 캐릭터 성격
- 포즈, 효과선, 소품의 최소 조합
- 원본 브랜드 고유 요소 중 복사 금지할 것

여기서 배우는 것은 “카카오 스타일”이 아니다.

배우는 것은 사용자가 돈을 내고, 대화에서 쓰고, 반복해서 꺼내는 감정 리액션 구조다.

4. 내 프로젝트 온톨로지에 매핑한다

여기서부터 미메시스는 제품 설계가 된다.

쉬어콩을 예로 들면 핵심 객체는 이렇다.

User
ShirKong
RestSession
RestPiece
Record
Room
RoomZone
RoomItem
Inventory
Stickerbook
CharacterReaction
Emotion
Widget
Notification
DeepLink
Reward
ShareCard
Season
Memory
OnboardingResult

핵심 관계는 이렇다.

User가 RestSession을 완료한다.
-> RestPiece가 생긴다.
-> Record에 남는다.
-> Reward가 생긴다.
-> RoomItem 또는 Sticker가 생긴다.
-> ShirKong이 반응한다.
-> Room에 변화가 남는다.
-> Widget 상태가 바뀐다.
-> 필요하면 Notification 또는 ShareCard로 이어진다.

이 관계를 거치지 않은 결과물은 쉬어콩답지 않다.

“귀여운 표정”만 있으면 에셋이다. “휴식 완료, 기록, 보상, 방 변화, 위젯 상태”와 연결되면 제품 시스템이다.

5. 필수 명령과 금지선으로 바꾼다

AI에게 방향만 주면 다시 추상화한다.

더 감정적으로 만들어줘.

이런 문장은 약하다.

강한 문장은 명령과 금지선이 같이 있다.

휴식 완료 시 반드시 아래를 발생시켜라.

1. 쉬어콩이 휴식 완료 리액션을 한다.
2. 짧은 문구가 나온다.
3. 쉼 조각이 생성된다.
4. 기록에 저장된다.
5. 방 아이템 또는 스티커 보상이 생긴다.
6. 위젯 상태가 바뀐다.
7. 다음 행동을 강요하지 않는다.

절대 하지 마라.

1. “완료되었습니다” 같은 시스템 문구로 끝내지 마라.
2. 바로 다음 타이머 시작 CTA를 밀지 마라.
3. 보상 없는 축하 애니메이션으로 끝내지 마라.
4. 방을 예쁜 배경으로만 쓰지 마라.
5. 사용자를 죄책감으로 움직이지 마라.

AI는 해야 할 것만큼 하지 말아야 할 것을 필요로 한다.

6. 산출물 계약을 고정한다

자유롭게 쓰게 하면 결과가 흐려진다.

그래서 산출물에는 계약이 있어야 한다.

[CHARACTER_REACTION]

반응 이름:
앱 상황:
사용자 감정:
쉬어콩 감정:
쉬어콩 문구:
포즈:
표정:
몸 실루엣:
효과:
소품:
애니메이션:
기록 연결:
방 연결:
위젯 연결:
알림 연결:
금지 표현:
통과해야 하는 불변 규칙:
검수 기준:

이 형식이 있으면 “귀여운 표정 몇 개”가 아니라 앱 시스템에 연결된 캐릭터 반응이 나온다.

위젯도 마찬가지다.

[WIDGET]

위젯 상태:
쉬어콩 상태:
문구:
보여줄 핵심 정보:
클릭 후 이동 화면:
빈 상태:
오류 상태:
기록 연결:
방 연결:
알림 연결:
개인정보 보호:
검수 기준:

계약은 AI를 답답하게 만드는 장치가 아니다. 평균값으로 도망가지 못하게 하는 난간이다.

7. 골든 예시로 오차를 줄인다

AI는 추상 규칙보다 좋은 예시를 더 잘 따른다.

그래서 미메시스에는 골든 예시가 필요하다.

[Golden Example: 휴식 완료]

상황:
사용자가 3분 휴식을 완료했다.

쉬어콩 반응:
쉬어콩이 쿠션 위에서 몸을 말랑하게 풀고 작은 숨결 효과가 나온다.

문구:
잘 쉬었어

생기는 것:
- 쉼 조각 1개
- 기록에 오늘의 쉼 저장
- 스티커북에 작은 쉼 스티커 추가
- 방에 작은 쿠션 해금
- 위젯 상태가 “잘 쉬었어”로 변경

절대 금지:
- 완료되었습니다
- 목표 달성
- 타이머 성공
- 바로 다음 세션 시작 CTA

이 예시는 캐릭터, 기록, 보상, 방, 위젯을 한 루프로 묶는다.

이게 미메시스가 표면 모방에서 시스템 설계로 넘어가는 지점이다.

불변 규칙이 필요하다

프로젝트가 길어질수록 AI는 다시 평균으로 돌아가려 한다.

그래서 반복 작업에는 불변 규칙이 필요하다.

쉬어콩에서라면 예를 들면 이런 규칙이다.

[INV-001]
쉬어콩은 한눈에 콩이어야 한다. 무, 강아지, 토끼, 클로버, 감자, 떡처럼 보이면 실패다.

[INV-002]
쉬어콩의 새싹은 시그니처 포인트지만, 새싹이 캐릭터의 정체성을 잡아먹으면 안 된다.

[INV-003]
쉬어콩은 장식 캐릭터가 아니라 모든 핵심 행동에 반응하는 존재여야 한다.

[INV-004]
모든 휴식 완료는 기록, 캐릭터 반응, 방 변화, 보상, 위젯 중 최소 3곳에 남아야 한다.

[INV-005]
방은 배경이 아니라 사용자가 직접 꾸미고 소유하는 공간이어야 한다.

[INV-006]
모든 방 소품은 얻은 이유, 감정, 방 구역, 쉬어콩 반응을 가져야 한다.

[INV-007]
기록 화면은 타이머 시작 화면이 아니라 내가 쉬어온 시간을 보는 공간이어야 한다.

[INV-008]
기록 화면의 주 CTA는 타이머 시작이 아니라 쉼 조각 남기기, 지난 쉼 보기, 방 변화 보기여야 한다.

[INV-009]
위젯은 앱 밖의 쉬어콩 상태여야 하며, 클릭 시 정확한 맥락 화면으로 이동해야 한다.

[INV-010]
알림은 앱 열기 유도가 아니라 쉬어콩이 보내는 작은 편지여야 한다.

[INV-011]
사용자를 죄책감으로 움직이면 안 된다.

[INV-012]
뽀모도로/타이머는 제품 정체성이 아니라 쉬어콩 세계 안의 행동 중 하나다.

[INV-013]
카카오톡식 레퍼런스는 그림체 복사용이 아니라 감정 리액션 구조 학습용이다.

[INV-014]
모든 캐릭터 반응은 문구, 감정, 상황, 포즈, 표정, 효과, 앱 위치를 가져야 한다.

[INV-015]
모든 외부 진입점, 즉 위젯과 알림은 홈이 아니라 맥락 화면으로 딥링크해야 한다.

[INV-016]
세계관은 설명글이 아니라 화면 변화, 쉬어콩 반응, 방 소품, 기록, 위젯, 알림으로 보여야 한다.

[INV-017]
레퍼런스는 표면 복제가 아니라 구조 변환으로 사용해야 한다.

[INV-018]
AI가 추상적 산출물을 만들면 실패다. 모든 산출물은 객체, 위치, 상황, 연결 시스템, 검수 기준을 가져야 한다.

불변 규칙은 취향 선언이 아니다. 반복되는 AI 작업에서 정체성이 깨지는 지점을 막는 검수 장치다.

실제 입력 포맷

앞으로 어떤 작업이든 이 형식으로 시작하면 된다.

[MIMESIS TASK]

작업명:
위치:
문제:
영향:
필요 전문가:

사용할 레퍼런스:
- REF-001:
- REF-002:
- REF-003:

이 레퍼런스에서 배울 것:
-
-
-

절대 복사하면 안 되는 것:
-
-
-

내 프로젝트 온톨로지에서 영향받는 객체:
-
-
-

반드시 지켜야 할 불변 규칙:
-
-
-

이번 작업에서 반드시 해야 할 것:
1.
2.
3.

이번 작업에서 절대 하면 안 되는 것:
1.
2.
3.

산출물 형식:
-

검수 기준:
-

이 포맷의 목적은 AI에게 친절하게 설명하는 것이 아니다.

AI가 평균적인 좋은 답을 내는 대신, 내 프로젝트의 구조 안에서 답하게 만드는 것이다.

작업 전 Ontology Impact Map

복잡한 작업은 시작 전에 먼저 영향 지도를 출력하게 한다. 이것은 기획 문서가 아니라 AI가 어디를 건드리는지 스스로 묶게 만드는 안전장치다.

[Ontology Impact Map]

이번 작업:
영향받는 핵심 객체:
영향받는 시스템:
사용할 레퍼런스:
레퍼런스에서 배울 것:
절대 복사하면 안 되는 것:
관련 불변 규칙:
관련 화면:
관련 캐릭터 반응:
관련 방 변화:
관련 기록 변화:
관련 위젯 변화:
관련 알림 변화:
깨지면 안 되는 것:
이번 작업에서 절대 하면 안 되는 것:

이 지도를 통과하지 못한 결과물은 보류한다. 아직 “무엇을 만들지”가 아니라 “무엇에 영향을 주는지”조차 정리되지 않았기 때문이다.

레퍼런스 카드

레퍼런스는 링크 모음이 아니라 카드여야 한다.

[REF-001]

이름:
출처:
유형:
감정 리액션 / 포즈 / 문구 / 소품 / 수집 UI / 위젯 / 방 / 알림 / 온보딩

검증 근거:
실제 판매 / 실제 사용 / 공식 문서 / 논문 / 특허 / 유지되는 오픈소스 / 플랫폼 심사 / 커뮤니티 반복 사용

배울 것:
이 레퍼런스에서 구조적으로 배울 점

절대 복사 금지:
캐릭터 형태:
문구:
색상:
포즈:
특정 장식:
구도:

적용 방식:
내 프로젝트의 어떤 객체, 화면, 상황에 변환할지

적용 대상:
Character / Room / Record / Widget / Notification / Stickerbook / Item / Onboarding

검수 기준:
이 레퍼런스를 제대로 변환했는지 확인할 질문

이 카드가 있어야 원본과 내 작업 사이에 경계가 생긴다.

무엇을 배울지와 무엇을 베끼면 안 되는지가 동시에 있어야 미메시스가 표절이나 얕은 카피로 무너지지 않는다.

문서 체계

미메시스는 한 번의 프롬프트가 아니라 프로젝트 메모리로 남아야 한다.

실제 프로젝트라면 최소한 아래 문서가 필요하다.

/project-memory
  00_PROJECT_INDEX.md
  01_CURRENT_STATE.md
  02_PRODUCT_ONTOLOGY.md
  03_MIMESIS_ENGINEERING.md
  04_REFERENCE_LIBRARY.md
  05_REFERENCE_DECOMPOSITION.md
  06_DO_NOT_COPY_REDLINE.md
  07_GOLDEN_EXAMPLES.md
  08_INVARIANT_RULES.md
  09_CHARACTER_SYSTEM.md
  10_WORLD_SYSTEM.md
  11_ROOM_SYSTEM.md
  12_RECORD_SYSTEM.md
  13_WIDGET_NOTIFICATION_SYSTEM.md
  14_COMPONENT_SYSTEM.md
  15_PROMPT_LIBRARY.md
  16_DEPRECATED_ARCHIVE.md
  17_CHANGELOG.md

특히 중요한 것은 네 개다.

문서역할
02_PRODUCT_ONTOLOGY.mdAI가 제품을 객체와 관계로 이해하게 만든다
03_MIMESIS_ENGINEERING.md레퍼런스를 어떻게 분해하고 번역할지 정한다
04_REFERENCE_LIBRARY.md원본, 배울 것, 복사 금지, 적용 대상을 기록한다
07_GOLDEN_EXAMPLES.mdAI가 따라야 할 정답 예시를 저장한다

안 쓰는 것은 폐기하고, 현재 기준만 남긴다. 메모리는 많이 쌓는 것이 아니라 기준을 잃지 않게 정리하는 일이다.

검수 질문

미메시스 결과물은 “그럴듯한가”로 검수하면 안 된다.

아래처럼 물어야 한다.

이 결과물은 어떤 원본의 어떤 구조를 배웠는가?
그 구조는 내 프로젝트의 어떤 객체와 관계로 옮겨졌는가?
절대 복사하면 안 되는 원본 요소를 피했는가?
필수 명령과 금지선을 지켰는가?
산출물 계약을 모두 채웠는가?
골든 예시와 비교했을 때 무엇이 부족한가?
불변 규칙을 깨지 않았는가?
메모리에 남길 새 결정과 폐기할 방향은 무엇인가?

쉬어콩이라면 더 구체적으로 묻는다.

쉬어콩이 한눈에 콩으로 보이는가?
방이 배경이 아니라 내가 소유한 공간처럼 느껴지는가?
기록이 통계가 아니라 내가 쉬어온 시간처럼 느껴지는가?
위젯이 정보 카드가 아니라 앱 밖의 쉬어콩 상태처럼 보이는가?
알림이 앱 열기 유도가 아니라 작은 편지처럼 느껴지는가?

검수의 기준은 의도한 체감이 실제로 남는가다.

Prompt / Context / Harness / Mimesis

이 블로그에서 미메시스는 독립된 유행어가 아니라 AI-native 작업 운영의 한 층이다.

단계핵심 질문역할
Prompt Engineering어떻게 물어볼 것인가질문의 모호성 제거
Context Engineering무엇을 보여줄 것인가판단 재료 설계
Harness Engineering어떻게 벗어나지 못하게 할 것인가실행과 검증 경계 설계
Mimesis Engineering어떤 원본의 작동 문법을 옮길 것인가검증된 구조의 분해, 번역, 실행

프롬프트는 요청을 선명하게 만든다. 컨텍스트는 판단 세계를 만든다. 하네스는 실행과 검증 경계를 만든다.

미메시스는 그 위에 외부 원본의 작동 문법을 넣는다.

Proof Boundary

이 페이지는 업계 표준을 선언하는 문서가 아니다.

내가 LLM과 agent 시스템을 실제로 운영하며 정리한 작업 방법론의 공개 초안이다. 강한 주장은 Proof & Claim Boundaries에서 증거와 함께 업데이트한다.

현재 주장할 수 있는 것은 여기까지다.

  • 미메시스 엔지니어링은 이 블로그와 내 AI-native 작업의 프레임으로 정의 중이다.
  • 아직 검증된 universal methodology라고 주장하지 않는다.
  • 공개 case study, prompt pack, proof artifact가 쌓일수록 주장 범위를 넓힌다.

Operator OS 안에서의 위치

AI-native Operator OS는 AI 실행을 검증 가능한 운영 단위로 묶는 구조다.

Mimesis Engineering은 그 운영 단위에 외부 기준을 넣는 방법이다. AI가 내 취향과 말투만 따라오지 않게, 이미 더 오래 검증된 세계의 작동 문법을 분해하고 내 시스템으로 번역하게 만든다.

Proof & Claim Boundaries는 그 비교와 실행 뒤에 내가 어디까지 주장할 수 있는지 정리하는 신뢰 장치다.

Operator OS
= AI가 실행하는 운영 체계

Mimesis Engineering
= 검증된 원본의 작동 문법을 내 시스템으로 번역하는 방법론

Proof & Claim Boundaries
= 어디까지 주장하고 어디서 멈추는지 보여주는 신뢰 장치

관련 글