LLM에게 바로 “이거 만들어줘”라고 말하면 모델은 내 생각을 너무 잘 도와준다.
문제는 내 생각이 틀렸을 때다.
그래서 프로젝트 시작 전에는 내 아이디어보다 먼저 검증된 원본, 선행 사례, 실패 사례, 시장 구조를 넣어야 한다.
나는 이 방식을 미메시스 엔지니어링이라고 부른다.
업데이트: 이 글의 10개 프롬프트는 미메시스의 1단계, 즉 field/source/failure scan에 가깝다. 현재 기준의 미메시스는 여기서 멈추지 않고
ontology map -> command/redline -> output contract -> golden example -> validation -> memory까지 가야 한다.
쓰는 순서
아래 프롬프트는 한 번에 다 던지는 것이 아니다. 순서대로 쓴다.
- field를 펼친다.
- 공식 문서, 논문, 특허, 유지되는 오픈소스, 실제 제품 같은 원본을 찾는다.
- 선행자와 실패자를 찾는다.
- 구조를 분해한다.
- 내 프로젝트 온톨로지에 매핑한다.
- 명령, 금지선, 산출물 계약으로 바꾼다.
- 검증 가능한 다음 행동과 메모리 업데이트로 닫는다.
각 프롬프트에서 {} 안의 값만 바꾸면 된다.
1. Field map
내가 만들려는 것은 {아이디어}다.
바로 개선안을 내지 말고, 먼저 이 문제가 속한 field를 맵핑해줘.
반드시 나눠서 정리해라.
- 이미 이 문제를 푼 제품
- 비슷한 문제를 푼 오픈소스/프레임워크
- 관련 논문/특허/공식 문서/표준
- 실패했거나 사라진 접근
- 내가 착각하기 쉬운 시장 구조
각 항목마다 "왜 봐야 하는지"와 "내 아이디어에 주는 압박"을 적어라.
목적은 내 아이디어를 바로 키우는 것이 아니라, 내가 서 있는 판을 먼저 보는 것이다.
2. Predecessor scan
{아이디어}의 선행자를 찾아라.
블로그 요약이나 2차 해설이 아니라 원본에 가까운 source class만 우선순위로 둬라.
- 공식 문서
- GitHub repository / issue / PR
- 논문
- 특허
- 창업자/제작자 원문
- 제품의 실제 onboarding / pricing / docs
각 선행자에 대해 다음을 정리해라.
1. 어떤 문제를 풀었나
2. 어떤 제약 아래에서 풀었나
3. 내가 그대로 가져오면 안 되는 점은 무엇인가
4. 내가 반드시 배워야 할 구조는 무엇인가
좋은 선행자 분석은 “나도 이렇게 만들자”가 아니라 “이 사람들은 왜 이렇게 만들 수밖에 없었나”를 본다.
3. Failure scan
{아이디어}와 비슷한 접근이 실패하는 대표 이유를 찾아라.
성공 사례보다 실패 사례를 먼저 봐라.
다음 형식으로 정리해라.
| 실패 모드 | 왜 발생하는가 | 초기에 보이는 신호 | 내 프로젝트에서 막는 방법 |
마지막에는 "이 아이디어를 지금 중단해야 한다면 가장 강한 이유 3개"를 써라.
LLM은 아이디어를 살리는 말을 잘한다. 그래서 일부러 죽이는 프롬프트가 필요하다.
4. Structure cloning
다음 선행 사례를 결과물이 아니라 구조로 분해해라.
선행 사례: {제품/논문/오픈소스/프레임워크}
분해 기준:
- 핵심 객체
- 입력과 출력
- 사용자가 반복하는 행동
- 검증 루프
- 실패 처리
- 권한/승인 경계
- 비용 구조
- 유지보수 구조
마지막에는 내 프로젝트에 이식 가능한 구조와 이식하면 위험한 구조를 분리해라.
이 프롬프트의 핵심은 visual copy를 막는 것이다. 버튼, 색, 말투가 아니라 구조를 가져와야 한다.
5. Anti-copy check
내가 {선행 사례}를 너무 얕게 따라 하고 있는 부분을 찾아라.
다음 네 가지로 비판해라.
1. 결과만 따라 한 부분
2. 맥락이 달라서 복사하면 위험한 부분
3. 내가 이해하지 못한 채 가져온 부분
4. 실제로는 내 문제에 필요 없는 부분
각 항목마다 제거/수정/검증 중 하나의 처방을 붙여라.
미메시스는 베끼기가 아니다. 얕은 복사를 끊어내는 장치다.
6. Market structure prompt
{아이디어}가 속한 시장 구조를 분석해라.
기능 목록이 아니라 힘의 구조를 봐라.
- 누가 돈을 내는가
- 누가 전환 비용을 부담하는가
- 누가 신뢰를 잃으면 치명적인가
- 어떤 기존 workflow가 바뀌어야 하는가
- 어떤 규제/보안/평판 리스크가 있는가
- 어떤 distribution channel 없이는 작동하지 않는가
마지막에는 "제품 문제가 아니라 시장 구조 문제일 가능성"을 평가해라.
좋은 제품이 망하는 이유 중 상당수는 제품 내부가 아니라 시장 구조에 있다.
7. Claim boundary prompt
내가 {아이디어}에 대해 지금 주장하고 싶은 문장은 다음과 같다.
주장: {강한 주장}
이 주장을 proof boundary로 나눠라.
| 지금 주장 가능 | 아직 주장 불가 | 필요한 증거 | confidence |
과장된 문장은 더 약하지만 정확한 문장으로 바꿔라.
강한 포장은 가능하다. 검증되지 않은 완료 주장은 금지한다.
8. Open-source reuse prompt
{아이디어}를 처음부터 만들기 전에 재사용 가능한 공개 구현을 찾아라.
우선순위:
1. 유지되는 오픈소스 라이브러리
2. 공식 framework/plugin
3. reference implementation
4. 표준 도구
5. 직접 구현
각 후보마다 다음을 평가해라.
- 유지보수 상태
- 라이선스 리스크
- 내 요구사항과 맞는 부분
- 맞지 않는 부분
- 직접 구현보다 나은 이유
- 버려야 하는 이유
이미 세상이 푼 문제는 다시 풀지 않는다. 대신 내 문제에 맞게 흡수한다.
9. Understanding debt prompt
{아이디어/코드/설계}에서 내가 이해하지 못한 채 넘어갈 위험이 있는 부분을 찾아라.
다음 표로 정리해라.
| 영역 | 왜 어려운가 | 모르면 어떤 위험이 생기는가 | 상환 방법 | 상환 전 금지할 주장 |
특히 AI가 만든 결과를 내가 이해한 것처럼 착각할 수 있는 부분을 강하게 지적해라.
이 프롬프트는 속도를 늦추기 위한 것이 아니다. 나중에 무너지는 시간을 줄이기 위한 것이다.
10. Ship / stop prompt
지금까지의 분석을 기준으로 {아이디어}를 다음 셋 중 하나로 판정해라.
1. ship: 작게 내보내고 검증한다
2. revise: 구조를 바꾼 뒤 다시 검증한다
3. stop: 지금은 중단한다
판정 근거를 증거 중심으로 써라.
반드시 다음을 포함해라.
- 가장 강한 계속 이유
- 가장 강한 중단 이유
- 7일 안에 확인할 수 있는 proof artifact
- 이 proof artifact가 실패하면 무엇을 바꿀지
좋은 미메시스는 결론을 내는 것이 아니라 다음 검증 단위를 만든다.
내 기본 루프
나는 보통 이렇게 쓴다.
field map
→ verified source scan
→ predecessor / failure scan
→ operating grammar decomposition
→ ontology map
→ command / redline compiler
→ output contract
→ golden example
→ validation checklist
→ claim boundary
→ memory update
→ ship / revise / stop
프로젝트가 작으면 30분이면 된다. 큰 프로젝트면 이 루프 자체가 기획 문서가 된다.
중요한 건 LLM에게 바로 실행을 맡기지 않는 것이다.
먼저 세계를 보여주고, 그 세계를 기준으로 내 생각을 흔들게 해야 한다.