LLM은 모방을 잘한다.
문제는 무엇을 모방하느냐다.
문체를 모방하면 그럴듯한 글이 나온다. UI를 모방하면 그럴듯한 화면이 나온다. 경쟁사를 모방하면 그럴듯한 제품 설명이 나온다.
하지만 결과만 닮은 것은 위험하다. 판단 구조가 없으면 모방은 검증이 아니라 포장이 된다.
그래서 나는 이 작업 방식을 미메시스 엔지니어링이라고 부른다.
업데이트: 이 선언문은 초기 프레임이다. 현재의 미메시스 엔지니어링은 “외부 기준으로 비교한다”에서 한 단계 더 나아가, 검증된 원본의 작동 문법을 내 프로젝트의 온톨로지, 명령, 금지선, 산출물 계약, 골든 예시, 검수, 메모리로 번역하는 방식으로 정리하고 있다.
1. AI는 결과를 흉내 낸다
AI는 전문가처럼 보이는 문장과 결과물을 빠르게 만든다.
이 능력은 유용하다. 초안, 비교표, 프로토타입, 코드 골격을 만드는 속도는 이미 인간 혼자보다 빠른 영역이 많다.
하지만 AI가 결과를 빠르게 흉내 내는 능력은 인간에게 착시를 준다. 결과물이 자연스러우면 판단 과정도 자연스러웠을 것처럼 느껴진다.
2. 인간은 그 흉내를 이해로 착각한다
결과가 매끄러울수록 인간은 판단 루프가 제대로 작동했다고 믿기 쉽다.
이 착각이 이해의 부채를 만든다. 내가 설명할 수 없는 코드, 내가 검증하지 않은 주장, 내가 원본과 대조하지 않은 시장 판단이 쌓인다.
AI-native 작업에서 위험한 순간은 결과가 나쁠 때가 아니다. 결과가 너무 좋아 보이는데 검증 루프가 비어 있을 때다.
3. 약한 미메시스 vs 강한 미메시스
| 약한 미메시스 | 강한 미메시스 |
|---|---|
| 결과를 흉내 낸다 | 판단 구조를 흉내 낸다 |
| 문체를 복제한다 | 검증 방식을 복제한다 |
| 전문가처럼 말한다 | 전문가처럼 실패를 감지한다 |
4. 판단 구조 모방
좋은 작업자는 결론만 내지 않는다. 무엇을 모르는지, 어떤 증거가 필요한지, 어디서 멈춰야 하는지 판단한다.
강한 미메시스는 이 구조를 가져오려는 시도다.
- 어떤 원본을 먼저 봐야 하는가.
- 어떤 경쟁자를 비교해야 하는가.
- 어떤 실패 사례를 반례로 넣어야 하는가.
- 어떤 구현은 그대로 쓰고, 어떤 구현은 버려야 하는가.
- 어떤 증거가 없으면 공개 주장으로 올리면 안 되는가.
내 생각을 더 잘 도와주는 AI보다, 내 생각을 더 잘 검증하는 AI가 필요하다.
5. 검증 루프 모방
좋은 작업자는 output을 낸 뒤 증거로 닫는다. 테스트, 로그, source reconciliation, claim boundary가 필요하다.
그래서 미메시스는 항상 하네스와 붙어야 한다. 하네스 없는 미메시스는 “근거 있어 보이는 말투”가 되기 쉽다.
미메시스가 모방해야 하는 것은 결과물이 아니라 다음 루프다.
원본 확인
→ 구조 분해
→ 작동 문법 추출
→ 내 프로젝트 온톨로지에 매핑
→ 명령과 금지선 작성
→ 산출물 계약과 골든 예시 작성
→ 검수와 실패 모드 점검
→ 증거로 주장 제한
→ 메모리와 changelog에 남김
6. 하네스와 결합하지 않은 미메시스는 위험하다
결과 모방은 convincing한 overclaim을 만들 수 있다. 그래서 미메시스는 evidence gate와 함께 있어야 한다.
LLM에게 “최고 사례를 참고해서 우리 제품 전략을 짜줘”라고 말하면 꽤 설득력 있는 답이 나온다. 하지만 그 답이 실제 시장 구조, 사용자 전환, 비용 구조, 기술 제약, 법적 경계, 배포 증거와 연결되지 않으면 설득력 있는 추측일 뿐이다.
그래서 나는 미메시스를 다음 세 장치와 같이 쓴다.
- Claim boundary: 어디까지 주장하고 어디서 멈출지 정한다.
- Evidence gate: 테스트, 로그, 원본 대조, 사용자 반응으로 닫는다.
- Understanding debt ledger: 내가 아직 설명하지 못하는 부분을 부채로 남긴다.
7. Operator OS는 미메시스의 인프라다
Operator OS는 프롬프트를 넘어 역할, 맥락, 하네스, 증거, 승인 경계를 묶는다. 미메시스는 그 위에서 좋은 판단 루프를 재현하려는 시도다.
내가 만들고 있는 AI-native Operator OS는 AI가 실행하는 작업을 검증 가능한 운영 단위로 묶는다. Mimesis Engineering은 그 운영 단위에 외부 기준을 넣는다.
즉:
Operator OS = 실행과 검증을 운영 체계로 묶는다.
Mimesis Engineering = 검증된 원본의 작동 문법을 내 시스템으로 번역한다.
Proof = 어디까지 주장 가능한지 증거와 경계를 남긴다.
8. 현재 claim boundary
이 선언문은 업계 표준을 선언하는 문서가 아니다.
내가 LLM과 agent 시스템을 운영하며 정리한 작업 방법론의 공개 버전이다. 강한 주장은 Proof & Claim Boundaries에서 증거가 붙을 때만 올린다.
현재 주장할 수 있는 것은 여기까지다.
- 미메시스 엔지니어링은 내 블로그와 Operator OS 작업의 방법론이다.
- 아직 검증된 업계 표준이라고 주장하지 않는다.
- prompt pack과 case study는 공개했지만, 외부 사용자 검증은 다음 증거물이다.
결론은 한 문장이다.
LLM 시대의 좋은 모방은 베끼기가 아니라 검증이다.