전문가가 추천하는 조립PC
프롬프트를 조금만 더 잘 쓰면 결과가 확 달라질까? AI를 쓰다 보면 결과가 마음에 들지 않을 때 가장 먼저 떠오르는 해결책은 프롬프트 수정이다. 설명을 더 붙이고, 조건을 추가하고, 역할을 다시 지정해보는 식이다.
하지만 여러 작업을 반복하면서 느낀 체감은 단순하지 않았다. 프롬프트를 고쳤을 때와 거의 고치지 않았을 때의 차이는, 결과물 자체보다 작업을 진행하는 방식에서 더 크게 벌어졌다. 이 글은 그 차이를 비교 정리한 기록이다.
비교는 동일한 유형의 작업을 대상으로 진행했다. 프롬프트 방식만 달리했을 뿐, 작업 목적과 입력 자료는 모두 동일하게 유지했다.
차이는 오직 프롬프트 작성 방식이었다.
먼저 결과만 놓고 보면, 상세 프롬프트가 유리한 경우가 많았다. 답변은 비교적 안정적이었고, 의도와 크게 어긋나는 경우도 적었다.
반면 최소 프롬프트에서는 결과 편차가 더 컸다. 한 번에 쓸 수 있는 답이 나오기도 했지만, 맥락이 빗나간 답변이 나오는 비율도 높았다.
다만 체감 품질을 수치로 정리해보면 차이는 생각보다 크지 않았다.
상세 프롬프트: 만족도 약 70%
최소 프롬프트: 만족도 약 65%
프롬프트 길이에 비례해 결과가 좋아진다는 느낌은 아니었다.
체감 차이가 가장 크게 드러난 지점은 작업 흐름이었다.
상세 프롬프트를 쓰면, 프롬프트 작성과 수정이 하나의 작업 단계처럼 느껴졌다. 결과를 확인한 뒤 “조건을 더 넣어야 하나?”라는 고민이 반복되면서, AI와 대화하는 시간이 길어졌다.
반대로 최소 프롬프트에서는 결과를 빠르게 판단하게 됐다. 쓸 수 있으면 쓰고, 아니면 버리는 식으로 결정 속도가 빨라졌다.
이 방식에서는 AI 결과를 완성품이라기보다 참고 자료처럼 다루게 됐다.
프롬프트를 고치지 않아도 됐던 경우에는 공통점이 있었다.
이 경우에는 프롬프트를 다듬는 10분보다, 결과를 직접 손보는 5분이 더 효율적으로 느껴졌다.
반대로 프롬프트가 분명히 의미 있었던 경우도 있다.
이때 프롬프트는 결과를 통제하는 도구라기보다, 생각을 흔들어보는 설정값에 가까웠다.
비교를 반복하면서 가장 크게 달라진 인식은 이것이다.
결과가 마음에 들지 않았던 이유가 항상 프롬프트 때문은 아니었다.
실제로는 AI에 맡기기엔 적합하지 않은 작업이었거나, 사람의 판단이 먼저 필요한 단계인 경우가 많았다.
AI를 실제로 활용했을 때의 차이는 조건에 따라 달랐다. 프롬프트를 잘 쓰는 기술보다 먼저 필요한 것은, 이 작업을 AI에 맡길 만한지 판단하는 기준이었다.
프롬프트는 만능 해결책이 아니라, 대화를 시작하기 위한 입력값에 가깝게 느껴졌다.
다음 글에서는 어떤 작업이 왜 AI와 맞지 않았는지, 그 기준을 조금 더 구체적으로 정리해보려 한다. 이제 그 판단이 궁금해질 시점이지 않을까.
