Prompt → Context → Harness → Mimesis

프롬프트 엔지니어링은 시작이었다. 하지만 긴 AI-native 작업을 해보면 곧 알게 된다. 좋은 질문만으로는 부족하다.

질문이 좋아도 재료가 나쁘면 답은 좁아진다. 재료가 좋아도 실행을 붙잡는 구조가 없으면 작업은 흘러나간다. 실행을 붙잡아도 비교 기준이 내 머릿속에만 있으면 AI는 내 생각을 너무 잘 도와주다가 같이 틀린다.

그래서 내 작업 방식은 네 단계로 이동했다.

1. Prompt Engineering: 잘 말하기

프롬프트 엔지니어링은 AI에게 원하는 결과를 선명하게 말하는 기술이다.

짧은 작업과 단일 출력에는 여전히 강하다. 이메일, SQL 초안, UI 카피, 작은 함수처럼 목표가 이미 좁혀져 있을 때 프롬프트 품질은 바로 결과 품질로 이어진다.

한계는 긴 프로젝트에서 나온다. 기억, 검증, 승인 경계가 프롬프트 밖으로 흘러나간다. 한 번의 좋은 문장으로는 며칠짜리 작업의 목표, 실패 사례, 테스트 조건, 공개 주장 수위를 계속 붙잡을 수 없다.

컨텍스트 엔지니어링은 AI가 판단할 세계를 구성하는 기술이다.

문서, 스펙, 코드, 제약, 히스토리, 원본 자료를 배치한다. 좋은 컨텍스트는 AI의 답변 범위를 바꾼다. 같은 질문도 어떤 원본을 보여주느냐에 따라 전혀 다른 결과가 나온다.

하지만 컨텍스트도 충분하지 않다. AI가 재료를 봤다고 해서 반드시 지키는 것은 아니다. 긴 작업에서는 중요한 제약이 희미해지고, 그럴듯한 방향 전환이 발생한다.

하네스 엔지니어링은 AI 실행이 목표와 검증에서 벗어나지 못하게 붙잡는 외부 구조다.

spec, plan, status, state, hook, verification command로 작업을 통제한다. AI의 기억력보다 외부 파일과 검증 명령을 믿는다.

하네스는 “완료했다”는 말을 테스트, 로그, diff, evidence로 닫게 만든다. 내 AI-native Operator OS에서 MFH가 맡는 역할도 여기에 가깝다.

한계도 있다. 하네스는 실행을 붙잡지만, 무엇과 비교해야 하는지는 자동으로 정해주지 않는다. 내 아이디어 자체가 좁으면 하네스는 좁은 목표를 성실하게 달성하게 만들 뿐이다.

미메시스 엔지니어링은 여기서 시작한다.

결과물이 아니라 판단, 검증, 수정 루프를 모방한다. 전문가처럼 말하게 만드는 것이 아니라, 전문가처럼 실패를 감지하고 되돌리는 구조를 만든다.

핵심 질문은 이것이다.

이 문제를 이미 풀었거나 실패한 사람들은 어떤 구조로 판단했는가?

그래서 미메시스는 경쟁자, 선행 사례, 실패 사례, 시장 구조, 검증된 오픈소스를 컨텍스트에 넣는다. LLM이 내 생각을 도와주기 전에 외부 기준으로 내 생각을 반박하게 만든다.

결과 모방은 빠르다. “Stripe처럼”, “Linear처럼”, “Bloomberg처럼”이라고 말하면 AI는 분위기를 잘 만든다.

하지만 좋은 제품과 좋은 판단은 다르다. 결과를 닮았다고 해서 그 결과를 만든 제약, trade-off, 실패 감지 루프까지 닮은 것은 아니다.

미메시스는 강한 말이다. 그래서 더 조심해야 한다.

내가 지금 주장하는 것은 “업계 표준 방법론을 만들었다”가 아니다. 내가 LLM과 agent 시스템을 운영하며 쓰는 공개 작업 프레임을 정리했다는 것이다.

강한 주장은 Proof & Claim Boundaries에서 증거와 함께만 올린다.