목차06
수정
결과가 마음에 들지 않으면 처음에는 요청을 바꾼다.
더 자세히 말하고, 하지 말아야 할 일을 적고, 예시도 붙여본다. 잘되는 경우가 있다. 그런데 그렇게 해도 같은 문제가 반복되는 일도 있었다.
내 설명이 부족한 것일까?
어떤 일은 그렇다. 하지만 어떤 일은 설명의 문제가 아니었다. 필요한 자료가 없거나, 자료가 있어도 확인하지 않거나, 확인할 기준 자체가 없었다.
나는 이 문제들을 구분하며 작업 방식을 바꿔왔다. 프롬프트, 컨텍스트, 하네스, 미메시스라는 말을 사용한 이유도 그 차이를 설명하고 싶어서였다.
1. 내가 원하는 것이 무엇인지 말한다
프롬프트에서 먼저 해야 할 일은 원하는 결과를 분명히 하는 것이다.
‘좋은 글을 써줘’라고 말하면 어떤 글이 좋은지부터 정해지지 않았다. 누구에게 쓰는지, 무엇을 전하고 싶은지, 어떤 사실을 쓸 수 있는지 알려주면 요청이 달라진다.
여기서 나는 내가 아직 결정하지 않은 부분도 발견할 수 있다.
AI가 이해를 못 하는 게 아니라, 나도 원하는 것을 정하지 못한 상태일 수 있다. 그럴 때 문장을 더 강하게 쓰는 것만으로는 해결되지 않는다.
먼저 생각을 구체화해야 한다.
2. 판단할 재료를 준다
요청이 분명해도 작업에 필요한 정보가 없을 수 있다.
회사에 관한 글을 쓰려는데 실제 제품 정보가 없고, 고객을 이해해야 하는데 이전 반응이 없고, 기능을 수정해야 하는데 기존의 결정이 보이지 않는다면 어떨까?
모델은 빈 부분을 일반적인 설명으로 채울 수 있다. 문장은 자연스럽지만 우리 일과는 맞지 않는 결과가 나온다.
나는 컨텍스트를 이런 재료의 문제로 생각한다. 작업에 필요한 사실, 이전 결정, 제약과 원문이 들어 있어야 한다.
그렇다고 자료를 많이 넣는 것만이 답은 아니다.
오래된 계획과 최신 결정이 같은 무게로 놓이면 오히려 혼란이 생긴다. 무엇이 지금 기준인지 알 수 있어야 하고, 필요한 때 다시 찾을 수 있어야 한다.
자료의 양만큼 관계와 상태가 중요하다.
3. 실제로 지켜졌는지 확인한다
자료를 줬다고 그대로 사용했다는 보장은 없다.
그래서 작업의 바깥에서 확인하는 장치가 필요했다. 목표와 완료 조건을 남기고, 검사를 실행하고, 어떤 결과가 나왔는지 기록하는 방식이다. 나는 이런 실행 환경을 하네스라는 말로 설명했다.
예를 들어 ‘테스트해라’라는 문장이 있는 것과, 정해진 검사가 실제로 실행되어 결과가 남는 것은 다르다.
하지만 검사에도 범위가 있다. 실행한 검사가 통과했다고 사용자의 모든 문제가 해결된 것은 아니다. 검사하지 않는 부분은 여전히 남는다.
하네스를 붙일 때는 무엇을 막고 싶은지도 함께 정해야 한다. 장치가 많아졌다는 사실로 안심하지 않으려 한다.
4. 좋은 결과의 기준을 배운다
여기까지 정리해도 내가 처음부터 좁은 목표를 잡았다면 어떨까?
내가 원한 대로 만들어졌고, 검사도 통과했는데, 실제로는 쓸 이유가 없는 제품일 수 있다. 보기 좋은 화면인데 어떤 행동을 해야 하는지 모를 수도 있다.
그래서 내 생각 밖의 기준을 가져오고 싶었다.
이미 비슷한 문제를 다룬 제품과 문서, 오픈소스를 보고, 어떤 조건에서 어떤 선택을 했는지 분해하는 일이다. 내가 미메시스 엔지니어링이라고 부른 작업 방식이 여기에 있다.
이때 참고할 것은 결과의 분위기만이 아니다.
무엇을 먼저 보여주는지, 무엇을 생략했는지, 실패하면 어떻게 되돌아가는지. 그중 내 상황에 맞는 것을 고르고, 맞지 않는 것은 버려야 한다.
다른 사람의 답을 그대로 가져오는 것으로 끝내고 싶지는 않았다. 내가 더 나은 질문을 만들 수 있었으면 했다.
요구 · 재료 · 실행 확인 · 비교 기준은 각각 다른 질문이다.
- 프롬프트 · 요구가 흐릿하다
- 원하는 결과는 무엇인가?글이라면 누구에게 무엇을 전할지 먼저 정한다.
- 컨텍스트 · 재료가 없다
- 판단에 필요한 정보가 있는가?쓸 수 있는 사실, 이전 결정, 제약과 원문을 제공한다. 최신 기준도 구분한다.
- 하네스 · 실행이 확인되지 않았다
- 정한 조건을 실제로 지켰는가?검사를 실행하고 결과를 남긴다. 검사하지 않은 부분까지 해결된 것은 아니다.
- 미메시스 · 기준 자체가 좁다
- 처음 세운 기준으로 충분한가?실제 제품·문서·오픈소스의 선택을 보고 내 상황에 맞는 기준을 배운다.
네 단계를 모두 거쳐야 하는 것은 아니다
처음에는 이 흐름을 하나의 발전 순서처럼 설명했다.
지금은 조금 다르게 본다. 서로 다른 문제를 다루는 장치에 가깝다.
짧은 문장 하나를 다듬는데 복잡한 운영 체계가 필요한 것은 아니다. 이미 충분히 구체적인 기능을 구현할 때 새로운 레퍼런스를 계속 찾을 필요도 없다.
반대로 자료가 없는 문제에 프롬프트만 고치거나, 중요한 검사가 빠진 작업에 예쁜 사례만 더 넣어도 해결되기 어렵다.
지금 무엇이 부족한지를 먼저 구분해야 한다.
내 요구가 흐릿한가. 필요한 정보가 없는가. 실행이 확인되지 않았는가. 아니면 내가 세운 기준 자체가 좁은가.
공부한 것을 다음 일로 가져가기
내 관심은 이 네 단어를 잘 설명하는 데서 끝나지 않는다.
실제 일을 하면서 필요한 것을 배우고, 사용해보고, 다음 작업에서 다시 꺼낼 수 있었으면 한다. 경영과 기획에서 배운 방식도, 개발에서 알게 된 확인 방법도 내 일에 맞게 연결하고 싶다.
ballast와 superapp을 만들며 계속 생각하는 부분이다.
다만 문서와 규칙이 늘어났다는 것을 성장으로 착각하지 않으려 한다. 다음 작업이 더 정확하게 이어지는지, 같은 판단을 덜 반복하는지, 내가 무엇을 해야 할지 더 잘 보이는지가 중요하다.
새로운 용어를 알게 되면 해결책을 찾은 기분이 든다.
하지만 그 말을 붙이기 전과 후에, 실제 일이 어떻게 달라졌는지까지 봐야 한다.
미메시스의 초기 생각은 선언문에, 직접 사용할 질문은 프롬프트 10개에 남겨두었다. 이 글은 당시의 분류를 2026년 9월의 작업 관점에서 다시 정리한 것이다.