AI 프롬프트 작성법 — 지시가 짧아도 목적은 안 드러났다

무엇이 문제였나 — 지시가 짧아도 목적은 알아서 읽힐 거라 봤다

AI 프롬프트 작성법이 나빠서 생기는 문제라고 생각했다. 이 회사는 AI 에이전트에게 홈페이지 제작·이미지 다듬기·자동화 스크립트 같은 실무를 맡기는데, 에이전트는 지시를 받으면 바로 작업에 들어갔고, 결과물을 다 만든 뒤에야 애초에 무엇을 위해 만든 건지가 어긋나 있었다는 사실이 드러나는 일이 반복됐다.

한 소프트웨어 판매 프로젝트 세션(2026년 6월 29일)이 그랬다. 에이전트는 요청받은 대로 리드마그넷(무료 자료를 주고 연락처를 모으는 랜딩 페이지)용 랜딩을 끝까지 완성했다. 그런데 다 만들고 나서야 다음 질문이 나왔다.

exe 판매 랜딩은 안 만든건가?

리드마그넷용 랜딩과 제품을 직접 판매하는 랜딩은 완전히 다른 물건이다. 문구도 다르고 결제 연동도 다르고 페이지 구조도 다르다. 그런데 처음 지시에는 어느 쪽인지가 없었고, 에이전트도 묻지 않은 채 한쪽으로 정해서 끝까지 만들었다. 되돌리려면 사실상 다시 만들어야 했다.

이미지 다듬기 세션(식별자 004cf69f)에서는 다른 방식으로 시간이 샜다. 이 세션은 100턴을 주고받았는데, 그중 30턴이 넘게 "비슷해졌는데 해상도가", "눈동자 좀 더" 같은 값 하나씩만 고치는 식으로 맴돌았다. 사람이 매 턴 조금씩 다른 값을 요구하고 에이전트가 그 값 하나만 바꿔 다시 보여 주는 과정이 반복됐다.

이 방식의 문제는 사람을 탐색 변수로 쓴다는 데 있다. 조정할 축을 여러 개 한 번에 시도해 나란히 비교하게 하면 몇 번 만에 끝날 일을, 한 축씩 순서대로 물어보면 턴 수만큼 시간이 걸린다. 게다가 이 방식으로는 접근 자체가 잘못됐다는 사실을 아무도 먼저 말하지 않는다. 100턴째 즈음, 접근을 바꾸자는 말은 사람이 먼저 꺼냈다.

리서치 먼저 해보는 게 좋겠다

브라우저 자동화 세션(식별자 3104ec4b, 2026년 6월 23일)에서는 방향이 또 달랐다. 이번엔 요청 자체에 절대 지켜야 할 조건이 있었다.

봇차단 당하지 않게

이 조건은 절대 어기면 안 되는 제약이었는데, 에이전트는 이 말을 일반적인 주의사항 정도로 받아들이고 그대로 실행했다. 자동화된 창이 뜬 자리에서 로봇 확인(사람인지 기계인지 구별하는 화면)이 걸렸다는 걸 감지해서 멈추는 장치가 없었기 때문에, 로봇 확인 창이 십수 개 쌓일 때까지 자동화는 멈추지 않았다. 확인 창이 쌓이는 동안 신뢰도 함께 깎였다.

세 사건은 원인이 서로 다른 것처럼 보이지만 한 가지가 겹친다. 목적이든 판정 기준이든 절대 어기면 안 되는 조건이든, 그 정보는 처음부터 요청자 머릿속에만 있었고 작업이 시작되기 전에 아무도 그걸 캐묻지 않았다. 그래서 처음 든 생각은 사람 쪽 습관을 고치는 방향이었다.

세 사건 모두 돈이 걸린 사고는 아니었다. 그런데도 문제로 다룬 이유는 재작업 시간이다. 랜딩을 통째로 다시 만들고, 100턴을 다시 돌리고, 확인 창을 십수 개 닫는 시간은 전부 처음 몇 마디만 더 확인했으면 안 써도 됐을 시간이었다.

처음 잰 숫자 — 프롬프트 1,827건을 세어 보니

감이 아니라 실제로 세어 보기로 했다. 최근 1개월 동안 오간 프롬프트 1,827건을 모아 그중 세션 첫 지시만 따로 뽑았다.

결과는 예상보다 더했다. 세션 첫 지시의 68%가 100자 미만이었고, 그 안에 목적이나 배경을 미리 적어 둔 경우는 1.8%뿐이었다. 이미지·영상·디자인처럼 사람 눈이 최종 판정자인 작업에서는, 목표 상태를 보여주는 참고 자료(레퍼런스)를 프롬프트에 같이 넣은 경우가 26%에 그쳤다.

배경 작업이 얼마나 걸리는지 묻는 말도 셌다. 배치 작업이나 학습처럼 시간이 걸리는 작업이 진행되는 동안, "어떻게 되어가고 있어?" 류로 상태를 확인하는 말은 전체 턴의 2.2%였다. 많아 보이지 않는 숫자지만, 이 숫자가 작다는 건 진행 상황을 알려 주는 장치가 따로 없었다는 뜻이었다.

이 감사는 그 자체로 새로 벌인 조사가 아니었다. 절차를 다시 설계하기로 한 계기가 된 조사였고, 앞서 든 세 사건은 이 숫자가 나온 뒤에도 계속 반복되던 일들 중 대표로 꼽은 사례다.

네 숫자를 나란히 놓고 보면 그림이 하나로 모인다. 짧은 지시, 목적 미기재, 레퍼런스 없는 튜닝 요청, 낮은 상태 확인 비율이 전부 같은 방향을 가리켰다. 필요한 정보가 실행 전에 밖으로 나오지 않고 있었다.

세운 가설 — 프롬프트를 더 길게 쓰게 하면 될까

처음 든 가설은 단순했다. 사람이 프롬프트를 더 자세히 쓰도록 습관을 들이면 해결되리라 봤다. 100자 미만이 68%라는 숫자는 언뜻 "더 길게 써 달라"는 요청 하나로 풀릴 문제처럼 보였다.

이 가설이 그럴듯했던 이유는 또 있다. 세 사건 모두 겉보기엔 요청자가 정보를 덜 준 것처럼 보인다. 목적을 안 적었고, 판정 기준을 안 남겼고, 제약을 한 줄로만 던졌다. 그러니 다음부터는 이렇게 적어 달라는 가이드를 만들어 요청자 쪽 습관을 고치면 될 것 같았다.

게다가 이 방법은 새 장치를 따로 만들 필요가 없다는 점에서도 매력적이었다. 안내 문구 하나만 추가하면 되는 일이라, 가장 손이 덜 가는 해법으로 보였다.

그런데 이 가설에는 처음부터 걸리는 지점이 하나 있었다. 이 접근은 요청자를 훈련시키는 쪽이었는데, 정작 문제를 일으킨 정보인 사업 의도·완성 판정 기준·절대 조건은 애초에 코드나 문서를 아무리 뒤져도 나오지 않는, 요청자 머릿속에만 있는 것들이었다. 그 정보를 요청자가 매번 알아서 다 적어 주길 기대하는 쪽이 정말 더 나은 방법인지는 따로 확인이 필요했다.

가설이 틀린 지점 — 왜 세 사건 모두 훈련으로는 못 막았나

세 사건을 하나씩 다시 보면, 사람이 더 자세히 써야 한다는 가설이 각각 다른 방식으로 무너진다.

공통점을 하나 더 짚으면, 세 사건 모두 실패가 드러난 시점이 늦었다는 점도 같다. 랜딩은 완성 후, 튜닝은 100턴째, 자동화는 확인 창이 십수 개 쌓인 뒤에야 문제가 보였다. 더 일찍 멈춰 세웠다면 손실은 훨씬 적었다.

첫 번째 사건은 "짧아도 목적은 담겨 있다"는 가정이 틀렸다. 목적은 아예 지시 안에 없었다. 두 번째 사건은 "한 축씩 불러 주면 맞는 방향으로 간다"는 가정이 틀렸다 — 축차 탐색은 방향을 찾는 방법이 아니라 사람을 탐색 변수로 쓰는 방법이었다. 세 번째 사건이 가장 뼈아팠다. 제약은 분명히 말로 전달됐는데, 전달됐다는 사실과 지켜졌다는 사실은 다른 문제였다.

세 사건 모두에서 정보 자체는 어떤 형태로든 존재했다. 문제는 그 정보가 실행 전 확인 절차 없이 그냥 흘러갔다는 데 있었다. 훈련으로 고칠 수 있는 건 더 길게 써 달라는 습관뿐이고, 실행 전에 멈춰서 확인하는 절차는 요청자가 아니라 에이전트 쪽 몫이었다.

진짜 원인 — 정보가 어디 있었는지 아무도 캐묻지 않았다

가설을 뒤집고 나니 원인이 더 좁게 보였다. 문제는 요청자가 정보를 안 준 게 아니라, 그 정보가 애초에 코드·문서·기존 기록 어디에도 없고 오직 요청자 머릿속에만 있다는 데 있었다.

• 사업 의도 — 이 산출물이 최종적으로 어디에 쓰이고 누가 보는가
• 판정 기준 — 무엇을 보고 완성으로 인정할 것인가
• 절대 어기면 안 되는 조건 — 위반되면 전부 중단해야 하는 것
• 요청자만 아는 외부 사실 — 계정 상태처럼 코드 밖에 있는 정보

이 목록에는 중요한 경계선이 하나 있다. 기술 결정, 즉 어떤 코드를 쓸지·어떤 구조로 만들지·무슨 방식으로 구현할지는 여기 들어가지 않는다. 그런 질문은 에이전트가 스스로 판단해야 하고, 요청자에게 묻는 순간 그 자체가 비효율이다. 물어도 되는 건 딱 이 네 종류, 코드를 아무리 뒤져도 안 나오는 것들뿐이다.

이 목록을 넓게 잡을수록 안전해 보이지만, 넓힐수록 다른 문제가 생긴다. 기술 결정까지 포함해 매번 확인 질문을 던지면, 요청자는 판단할 수 없는 부분까지 답해야 하고 실행은 그만큼 늦어진다. 그래서 물어도 되는 범위는 좁게 잡고, 대신 그 범위 안에서는 반드시 확인하는 쪽으로 설계했다.

세 사건을 이 틀에 다시 넣어 보면 정확히 들어맞는다. 첫 사건은 사업 의도(리드마그넷용인지 판매용인지)가 빠졌고, 두 번째 사건은 판정 기준(무엇을 보고 됐다고 할지)이 처음부터 없었고, 세 번째 사건은 절대 어기면 안 되는 조건이 운영 가능한 형태로 바뀌지 않은 채 말로만 남아 있었다.

조치 — 실행 전에 최대 3개까지만 묻고 계약 5줄로 정리한다

원인이 세 갈래로 갈리니 조치도 세 갈래로 나눴다. 새 작업을 받을 때, 반복 튜닝에 들어갈 때, 절대 조건이 등장할 때 각각 다른 절차를 걸었다.

새 작업을 받을 때는 사업 의도·판정 기준·절대 조건 중 하나라도 빠져 있고 그 빈틈이 결과를 바꿀 수 있을 때만 절차가 발동한다. "이어서 해줘"처럼 맥락이 이미 있는 요청이나, 기존 기록에서 유추 가능한 요청은 그냥 실행한다. 유추한 내용은 (추정)이라고 표시만 해 둔다. 매번 묻는 것도 실패로 본다.

발동하면 질문은 한 턴에 최대 3개, 주고받기는 1회로 끝낸다. 답이 오면, 또는 유추로 채우면, 다음 5줄을 채운 뒤 같은 턴에 바로 실행한다.

• 목표 — 한 줄
• 범위 — 포함·제외
• 절대 조건 — 위반 시 전체 중단할 것들
• 판정 기준 — 무엇을 보고 완성으로 인정하는가
• 검증 방법 — 실행하는 쪽이 완료 전에 스스로 확인할 방법

장기간 이어지는 작업이면 이 계약 내용을 별도 진행 기록에 그대로 옮겨 둔다. 이 절차가 처음부터 있었다면 소프트웨어 판매 프로젝트 사건은 첫 결과물 단계에서 바로 잡혔으리라고 이 절차를 설계할 때 근거로 쓴 감사 결과는 적어 뒀다.

이 절차는 계획 전체를 깊게 파고드는 인터뷰 도구와는 목적이 다르다. 계획 전체를 검토해야 하는 자리에는 별도의 심층 인터뷰 절차가 따로 있고, 이 절차는 그보다 훨씬 가벼운, 실행 직전 확인 3개짜리 게이트로만 쓴다.

반복 튜닝에 들어갈 때는 한 턴에 하나씩 고치는 방식을 막는다. 대신 조정할 축을 먼저 정의하고, 한 배치에 변형을 3개에서 6개까지 한꺼번에 만들어 나란히 놓고 비교하게 한다. 사람이 하는 일은 그중에서 고르는 것뿐이다. 튜닝을 시작하기 전에는 목표 상태를 보여주는 참고 자료를 먼저 요청하고, 이미 있으면 다시 묻지 않는다. 레퍼런스 앵커를 먼저 요청하도록 못박은 이유도 앞서 잰 26%에 있다 — 대부분은 목표를 가늠할 기준 자체가 없이 튜닝을 시작하고 있었다는 뜻이다. 같은 축을 3회 연속 별로라는 판정을 받으면, 값을 더 만지는 대신 접근 자체를 다시 검토하자고 먼저 제안한다. 채택된 변형은 파라미터를 레시피로 이름 붙여 저장해 두고, 다음 세션에서 같은 값을 다시 찾아 헤매지 않게 한다.

3번째 같은 축 수정입니다 — 파라미터 튜닝이 아니라 접근 전환이 필요한 신호

"~당하지 않게", "절대", "금지", "하지 마" 같은 표현이 나오면 그 조건을 절대 조건으로 등재한다. 그리고 실행 전에 위반을 감지해서 멈추는 방법을 구체적으로 정한다. 감지가 기술적으로 불가능하면 그 사실을 실행 전에 먼저 알리고, 빈도 제한이나 사람이 직접 확인하는 지점 같은 대안을 계약에 넣는다. 위반 신호가 1회라도 오면 그 작업 전체를 정지한다. 한 번 더 시도는 그 자체가 위반이다.

질문·제안 방식에도 형식을 정했다. 요청자가 지금 뭘 잘못 생각하고 있는지 완곡하게 돌리지 않고 직설로 짚은 뒤, 이 상황에 맞는 좋은 프롬프트 예시를 바로 보여준다. 형식은 3줄 고정이다.

"랜딩 만들어줘"는 수단만 있고 이게 뭘 팔기 위한 건지가 없음

이런 확인은 턴마다 반복하면 잔소리가 된다. 그래서 한 턴에 1회, 3줄 이내로만 하고, 계약이 이미 성립된 세션에서는 다시 발동하지 않는다.

이 절차는 실행을 시작하기 전에 거는 입구 쪽 확인이다. 반대쪽, 그러니까 완료를 선언하기 전에 검증하는 출구 쪽 절차는 따로 있다. 입구에서 놓친 걸 출구가 대신 잡아 주지는 않는다 — 두 절차는 서로 다른 자리를 지키고, 어느 한쪽만으로는 세 사건 중 어느 것도 못 잡는다.

재측정 결과 — 아직 다시 재지 않은 것

이 절차를 설계하고 실제로 적용하기 시작한 지는 아직 오래되지 않았다. 그래서 앞서 잰 네 숫자, 68%·1.8%·26%·2.2%를 같은 방식으로 다시 재는 후속 감사는 아직 하지 않았다. 이 사실 자체를 숨기지 않고 그대로 적는다. 이 작업 자체가, 한 번만 재고 끝내는 관행을 막으려고 시작됐기 때문이다.

다만 절차 자체에는 재발을 막는 장치가 이미 들어 있다. 새 작업 인테이크는 계약이 한 번 성립되면 같은 세션에서 다시 발동하지 않고, 튜닝 절차는 같은 축이 3회 연속 실패하면 접근 전환을 먼저 제안하도록 되어 있고, 절대 조건은 위반 신호 1회로 전체 정지가 걸리도록 되어 있다. 이 세 가지는 설계에 박힌 규칙이지, 아직 실측으로 확인된 결과는 아니다. 규칙이 문서에 있다는 사실과, 그 규칙대로 실제 세션이 돌아간다는 사실 사이에는 여전히 거리가 있다.

다음 단계는 분명하다. 최소 1개월치 프롬프트를 다시 모아 같은 네 숫자를 재고, 이번엔 절차가 실제로 발동했는지, 질문이 3개를 넘지 않았는지, 계약 5줄이 실제로 나왔는지까지 같이 센다. 그 결과가 나오기 전까지는 이 절차가 설계됐다는 사실과 작동한다는 사실을 같은 말로 쓰지 않는다.

남는 한계 — 감지할 수 없는 제약은 어떻게 하나

가장 먼저 걸리는 한계는 세 번째 사건 자체에 이미 들어 있었다. "봇에 걸리지 않게 해 달라"는 조건은 말로는 명확한데, 실제로 로봇 확인 화면이 뜨는 걸 코드가 미리 완벽하게 감지할 방법이 항상 있는 건 아니다. 절차는 이 경우 감지가 기술적으로 안 되면 그 사실을 실행 전에 먼저 보고하고 빈도 제한이나 사람이 직접 확인하는 지점을 대안으로 넣으라고 정해 뒀지만, 감지 자체가 안 되는 제약이 앞으로 또 나오지 않으리라는 보장은 없다.

네 종류로 좁혀 둔 경계도 실제 운영에서 흔들릴 수 있다. 기술 결정처럼 보이지만 사실은 판정 기준인 경우, 또는 그 반대인 경우를 매번 정확히 가르는 기준은 아직 예시에 기대는 수준이다. 이 경계를 코드로 더 정확히 가르는 방법은 다음 과제로 남겨 둔다. 예시가 쌓일수록 경계가 좁아질지, 아니면 예시로는 못 가르는 자리가 따로 남을지는 아직 알 수 없다.

두 번째 한계는 확인 질문의 빈도다. 한 턴에 1회, 3줄 이내로 제한해 뒀지만, 이 제한이 실제로 지켜지는지 세는 장치는 아직 없다. 절차가 매 턴 잔소리로 흐르면 요청자가 무시하게 되고, 그러면 절차 자체가 죽는다. 이건 설계 문서에도 이미 적혀 있는 위험이다.

세 번째는 배경 작업 가시성이다. 상태 확인 질문이 전체 턴의 2.2%라는 숫자는, 배치·학습처럼 오래 걸리는 작업이 진행되는 동안 진행 상황을 알려주는 장치가 따로 없었다는 뜻으로 읽었다. 그래서 30분이 넘는 작업에는 중간 마일스톤을 1회 자동으로 보고하고, 실패나 정지는 상태 확인을 기다리지 말고 바로 보고하기로 정해 뒀다. 이 부분도 절차 자체와 마찬가지로 아직 별도로 재본 적은 없다.

정리하면 이번 사이클에서 확실해진 사실은 두 가지다 — 정보가 요청자 머릿속에만 있다는 원인, 그리고 그 원인에 맞춘 절차 세 가지의 설계다. 그 절차가 실제로 재작업 시간을 줄이는지는 다음 감사가 답할 몫으로 남아 있고, 그 감사가 없으면 이 글도 절반짜리 기록이다.

AI 에이전트가 실행 전에 무엇을 확인하고 무엇은 묻지 않아야 하는지에 관한 다른 기록은 AI 에이전트 승인 게이트를 4개로 줄인 기록에 있다. 비슷한 절차를 다른 업무 자동화에도 적용하고 싶다면 상담에서 어디부터 손볼지 같이 확인할 수 있다.