에이전트를 사용해 나의 문어 프롬프트를 실행하기: 모든 실행을 나란히 비교하고 최고의 문어를 갤러리에 전시합니다

여기 코딩 에이전트가 Three.js를 사용하여 하나의 HTML 파일에서 내부에서 병뚜껑을 돌리는 절차적(procedural) 문어를 만들게 하는 프롬프트가 있습니다. 여러분이 사용하는 어떤 에이전트로든 실행해보고 세션 기록을 보내주세요. 여러분은 세 가지 것을 얻게 됩니다:

여러분의 실행 결과와 다른 사람들의 결과를 나란히 비교할 수 있습니다. 동일한 프롬프트에 대해 다양한 에이전트, 모델, 설정으로 시간, 버그 발생 여부, 사람이 개입해야 했던 지점, 토큰 비용 등을 비교합니다. 하나의 어려운 과제에서 '내 설정이 실제로 더 나은지'에 대한 공정한 답을 얻을 수 있습니다.
갤러리에 전시할 기회입니다. 결과 게시물에는 모든 문어들이 전시될 것입니다. 독자들이 최고의 작품을 선정하고, 그 실행 기록은 게시물의 최상단에 올라갑니다.
여러분의 이름이 소개 글에 실리며, 여러분의 실행 결과가 가장 깔끔했든 가장 재미있는 실패였든 링크와 함께 언급됩니다.

지난주에는 제가 직접 네 가지 모델로 이 프롬프트를 실행해보고 각 모델이 무엇을 잘못 했는지 작성했습니다. 댓글 반응이 게시물보다 더 좋았습니다. Arhan과 Kartik 모두 모델 하나당 한 번의 실행만으로는 아무것도 증명할 수 없다고 지적했습니다. 그래서 이번에는 모두가 직접 실행합니다.

네 가지 실행 결과는 여기서 나란히 비교할 수 있습니다. 따라서 여러분의 결과가 어디에 놓일지 미리 볼 수 있습니다.

관심이 있다면 아래 질문을 참고하세요

네 가지 실행 기록에서, 자신이 장면을 일찍 확인할 수 있는 방법을 구축한 에이전트(애니메이션 단계를 단계별로 진행하며, 뚜껑 각도를 읽는 등)들이 아무것도 고장 나지 않은 결과물을 만들었습니다. 반면, 확인 작업을 늦게 한 경우는 콘솔 경고와 함께 배포되었습니다.

네 번의 실행 기록만으로는 '이 모델이 신중하다'는 것과 '이 실행이 우연히 일찍 확인했기 때문'이라는 것을 분리할 수 없습니다. Arhan은 해결책을 제안했습니다. 잠시 모델에 대한 생각은 접고, 각 실행이 실제로 검사를 수행한 시점을 기록하여, 모든 사람의 실행 결과 전반에 걸쳐 초기 검사가 더 적은 버그를 의미하는지 확인해 보는 것입니다.

진정한 테스트를 위해 실행 중 절반에는 프롬프트에 '사전 점검(check up front)'을 요청하는 추가 단락이 포함됩니다. 만약 그 단락이 어떤 모델을 선택했는지보다 더 중요하다면, 그것이 드러나야 합니다.

참여 방법

태어난 날짜에 따라 프롬프트를 고르세요. 홀수일 경우: 프롬프트 A. 짝수일 경우: 프롬프트 B. 이렇게 하면 사람들이 이길 것이라고 생각하는 것을 선택하는 것을 방지할 수 있습니다.
평소 사용하는 어떤 에이전트와 어떤 모델이든 사용하세요: Claude Code, Codex, Cursor, Pi 등 다른 것도 좋습니다.
새롭고 빈 폴더에서 시작하고 (오래된 실행 기록이 있는 폴더는 에이전트가 해당 파일을 편집한다는 의미입니다), 프롬프트를 작성된 대로 정확히 붙여넣은 후 작동하도록 두세요. 도와주지 마세요. 개입해야 할 상황이라면 괜찮습니다. 손으로 직접 고치지는 마세요.
세션을 전송하세요. Claude Code에서는 KeepPlain 플러그인을 사용하여 /keepplain:build를, Codex에서는 $keepplain:build를, 또는 어떤 터미널에서도 keepplain build를 사용하세요. 플러그인이 없나요? keepplain.com/new에서 세션 파일을 업로드하세요. 아무것도 기기 밖으로 나가기 전에 미리보기를 볼 수 있으며, 키와 토큰은 로컬에서 마스킹됩니다. 그런 다음 게시하세요.

동일한 프롬프트의 실행 기록들은 사이트에서 자동으로 서로 연결되므로, 게시된 모든 실행 기록이 다른 것들 옆에 표시됩니다. 이것은 프롬프트가 변경되지 않은 채 붙여넣어졌을 때만 작동합니다. 만약 여러분의 문어(octopus)에 대한 라이브 링크(GitHub Pages, CodePen 등 무엇이든)를 공유한다면, 댓글에 추가하세요.

그런 다음 에이전트, 모델, 노력 설정과 함께 댓글에 링크를 남기세요.

본인의 환경에 대하여

이 글을 올리기 전에 제가 생각해 봐야 했던 것이 있습니다. 여러분의 에이전트는 깨끗한 방(clean room)이 아닙니다. Claude Code는 전역 CLAUDE.md, 기억하는 모든 메모리, 플러그인 및 훅을 읽습니다. Codex는 전역 AGENTS.md를 읽습니다. 같은 모델을 사용하는 두 사람은 동일한 것을 실행하고 있지 않습니다.

저는 그게 숨겨야 할 문제가 아니라고 생각합니다. 사람들이 실제로 일하는 방식이고, 중요한 것은 실제 환경에서 무슨 일이 벌어지냐는 것입니다. 하지만 만약 '항상 먼저 테스트하기'와 같은 전역 지침(global instructions)이 있다면 댓글로 언급해 주세요. 한 가지는 중요합니다: 이 정확한 프롬프트의 이전 실행 기록을 찾을 수 있는 메모리입니다. 에이전트가 KeepPlain 또는 다른 세션 메모리에 연결되어 있다면, 해당 실행을 위해 그것을 분리하세요. 그렇지 않으면 다른 사람들의 문어가 어떻게 했는지 찾아보고 그들의 실수를 건너뛸 수도 있습니다. KeepPlain의 개인 규칙(personal rules)도 마찬가지입니다: keepplain.com/rules에서 그것들을 끄세요. 이 규칙들은 과거 세션으로부터 배운 내용을 추가합니다.

프롬프트 A

Build a single self-contained HTML file: a real-time 3D scene of an octopus escaping from a glass jar by unscrewing the lid from the inside.

## Scene
...

프롬프트 B

프롬프트 A를 단어 하나 틀리지 않고 그대로 사용하되, 맨 끝에 다음 내용을 추가했습니다:

## Before you build the scene
Build a way to check it first: expose the current phase, lid angle, lid height and which tentacles are gripping on window, and add a way to jump to any phase on demand. Use it to step through the whole sequence in a real browser before you call it done.
Only that paragraph differs, so if B runs end up cleaner, that's the reason.
...

실행 결과로 할 일

저는 모든 최종 파일을 열어 동일한 것들을 테스트하는 작은 검사기(checker)를 작성할 것입니다. 뚜껑이 절대 역방향으로 돌아가지 않는지, 뚜껑이 분리되는지, 촉수가 문어 자신의 몸통을 감싸지 않는지, 콘솔이 깨끗한지를 말입니다. 이 검사기는 어떤 에이전트에게도 보여지지 않을 것입니다. 그리고 한 차트를 만들 것입니다: 버그에 대한 첫 번째 실제 점검 시점(A와 B)을 서로 다른 색상으로 표시하고 모든 모델을 통합하여 비교하는 시간표를 말입니다.

충분한 실행 결과가 나와서 무언가를 말할 수 있게 되면, 제가 추측이 틀렸다는 것을 보여주는 실행 결과들을 포함하여 여기에 게시할 것입니다.

저의 자체 실행 결과도 동일한 규칙에 따라 포함될 것입니다.

만약 세션을 공개하고 싶지 않다면, 여전히 실행하여 무슨 일이 일어났는지 댓글로 알려주시면 됩니다. 그것 역시 무언가 가치가 있습니다. 다만 차트에는 반영되지 않습니다.