AI 요청서 분류대 제작 로그

좋은 프롬프트보다 덜 뭉친 요청서가 먼저였다

AI 요청서 분류대는 AI에게 줄 요청 메모를 다섯 칸으로 보내는 Play다. 해야 할 일, 상황/대상, 예시, 답 모양, 지킬 선. 처음에는 좋은 프롬프트를 만드는 게임처럼 보일 수 있었다. 하지만 그렇게 두면 문장 기술을 맞히는 화면이 된다. 내가 원한 것은 멋진 프롬프트 문장이 아니라, 내가 AI에게 넘기기 전에 무엇을 정하지 않았는지 보는 작은 서류함이었다.

AI에게 바로 "이거 만들어줘"라고 쓰면 시작은 빠르다. 그런데 목적이 흐리거나, 대상이 없거나, 답 모양이 없거나, 건드리면 안 되는 선이 없으면 결과는 다시 돌아온다. 답이 나쁜 것처럼 보이지만, 사실은 요청서가 한 덩어리였던 경우가 많다.

그래서 이 Play는 AI가 좋은 답을 하게 만드는 주문서가 아니다. 요청 메모를 찢어 칸에 붙이는 분류대다. 사용자는 현재 문장이 해야 할 일인지, 상황 설명인지, 예시인지, 답 모양인지, 지킬 선인지 나눠본다. 그 분리가 먼저 되어야 다음 검수도 덜 흔들린다.

보관 메모를 하나로 묶으면

두 짧은 archive 메모는 프롬프트를 잘 쓰자는 말보다 앞뒤 검수 루틴에 가까웠다. 하나는 AI 답을 받은 뒤 실제 파일과 화면을 다시 열어보자는 메모였고, 하나는 AI에게 넘기기 전에 사람이 먼저 정해야 할 조건을 적자는 메모였다. `prompt-cleanup`에서는 이 둘을 요청서 분류 루프 안으로 접었다.

두 메모는 서로 다른 단계처럼 보인다. 하나는 답을 받은 뒤 다시 보는 습관이고, 하나는 맡기기 전에 먼저 정하는 습관이다. 하지만 실제로는 붙어 있다. 맡기기 전에 지킬 선과 확인 방법을 안 적으면, 답을 받은 뒤에도 무엇을 검수해야 하는지 흐려진다.

AI 요청서 분류대는 이 앞단을 다룬다. 나중에 검수할 근거가 남으려면, 처음 요청서에 목적과 맥락과 제약이 나뉘어 있어야 한다. "좋게 고쳐줘"보다 "한국어 모바일 사용자가 첫 5초 안에 누를 수 있게, 기존 입력창 모양은 유지하고, 답은 표로 먼저 보여줘"가 낫다. 길어서가 아니라 칸이 나뉘어 있어서다.

그래서 대표 로그에서 남길 핵심은 프롬프트 문장 예쁘게 고치기가 아니다. 요청서에 무엇을 남기고, 무엇을 지우고, 어디까지 사람이 먼저 판단해야 하는지 정리하는 일이다. AI 답변을 받은 뒤 확인할 기준까지 앞에 적어두면, 결과가 왔을 때도 "좋아 보인다"에서 멈추지 않고 파일, 화면, 명령, 금지선을 차례로 다시 볼 수 있다.

다섯 칸은 같은 무게가 아니었다

처음에는 다섯 칸이 너무 많아 보였다. 해야 할 일, 상황/대상, 예시, 답 모양, 지킬 선. 세 칸으로 줄이고 싶었다. 하지만 줄이면 서로 다른 재료가 다시 섞인다.

특히 답 모양과 지킬 선은 쉽게 섞인다. "표로 보여줘"는 답 모양이다. "인증 코드는 건드리지 마"는 지킬 선이다. "첫 5초 안에 사용자가 무엇을 눌러야 하는지 보여야 해"는 성공 기준이면서 지킬 선에 가깝다. 이 차이를 나누면 AI에게 맡긴 뒤에도 무엇을 봐야 하는지 남는다.

프롬프트 정리는 자동화를 줄이는 일이다

이 Play를 만들면서 조심한 점이 있다. 프롬프트를 잘 쓰면 AI가 알아서 해결한다는 느낌을 만들고 싶지 않았다. 요청서를 잘 나누는 이유는 AI에게 모든 결정을 넘기기 위해서가 아니다. 사람이 먼저 정해야 할 것을 밖으로 꺼내기 위해서다.

• - 해야 할 일은 AI가 처리할 작업을 좁힌다.
• - 상황/대상은 답이 실제 사용자와 화면을 벗어나지 않게 한다.
• - 예시는 원하는 톤과 피할 톤을 말로만 설명하지 않게 한다.
• - 답 모양은 결과를 다시 정리하는 시간을 줄인다.
• - 지킬 선은 건드리지 말 것과 성공 기준을 앞에 둔다.

이 다섯 칸이 있어도 검수는 필요하다. 오히려 검수할 기준이 더 선명해진다. 요청서에 "인증 코드는 건드리지 마"라고 썼다면 diff에서 인증 파일이 바뀌었는지 볼 수 있다. "표로 먼저 보여줘"라고 썼다면 결과가 그 순서를 지켰는지 볼 수 있다. 좋은 요청서는 검수를 없애는 것이 아니라 검수할 지점을 만든다.

화면에서 확인한 기준

대표 제작 로그로 남길 글이라면 화면 확인 기준도 같이 있어야 한다. 나중에 카테고리 색이나 문구를 바꿀 때도 이 기준이 깨지면 Play가 흔들린다.

이 표가 중요한 이유는 점수보다 기준이 오래 남아야 하기 때문이다. 사용자가 한 번 틀렸더라도 "아, 이건 답 모양이 아니라 지킬 선이구나"라고 느끼면 다음 요청서를 더 선명하게 쓸 수 있다.

대표 글로 올리는 이유

짧은 메모 두 개를 따로 공개 목록에 두면 "AI 답을 바로 믿지 말자", "맡기기 전에 정하자"라는 방향만 남는다. 맞는 말이지만 그 자체로는 얇다. AI 요청서 분류대 제작 로그로 묶으면 그 방향이 실제 Play 규칙으로 바뀐다.

이 Play는 프롬프트 문장 기술을 과시하는 화면이 아니다. 작은 프로젝트에서 AI에게 일을 맡기기 전에 무엇을 사람이 먼저 갈라야 하는지 보여주는 서류함이다. 해야 할 일, 상황/대상, 예시, 답 모양, 지킬 선. 이 다섯 칸이 나뉘면 답변이 틀렸을 때도 어디서 다시 열어볼지 보인다.

다음에 더 본다면 카테고리 수를 줄이기보다 각 칸의 문장을 먼저 볼 것이다. 예시와 답 모양이 헷갈리지는 않는가. 지킬 선이 금지 문구처럼만 보이지는 않는가. 상황/대상이 너무 넓어져서 실제 사용자와 화면을 흐리지 않는가. 이 질문이 남아 있으면 `prompt-cleanup`은 프롬프트 팁 글이 아니라, AI 작업을 시작하기 전에 손으로 재료를 나누는 작은 연습으로 남을 수 있다.