실무자가 말하는 ‘프롬프트 엔지니어링’이 과대평가된 부분

AI 도입이 잘 안 풀릴 때 가장 먼저 나오는 처방이 “프롬프트를 잘 쓰면 된다”이다. 이 글은 프롬프트 작성법을 다루지 않는다. 대신 프롬프트에 공을 들여야 하는 구간과 그래봐야 소용없는 구간을 나누는 기준을 다룬다. 조직에 AI를 붙이는 일을 하면서 성과를 가른 건 프롬프트의 정교함보다 그것이 재사용되는 구조였다는 판단에 이르렀다.

“프롬프트를 잘 써야 한다”는 통념이 놓치는 것

프롬프트 품질이 결과를 좌우하는 건 사실이다^[1]. 다만 그 명제는 한 사람이 한 번 쓰는 상황에서만 온전히 성립한다. 조직에서는 같은 작업을 여러 사람이 반복해서 한다. 이 조건이 붙는 순간 문제의 성격이 바뀐다.

잘 쓴 프롬프트가 한 사람의 메모장에만 있으면 조직 차원에서는 없는 것과 같다. 그 사람이 자리를 비우면 품질이 원래대로 돌아가고, 옆자리 동료는 같은 시행착오를 처음부터 다시 겪는다. 실무에서 흔히 보이는 패턴이 이거다 — 잘 쓰는 사람은 있는데 잘 쓰는 팀은 없는 상태.

성과를 가른 건 프롬프트가 아니라 재사용 구조였다

도입이 정착된 경우를 되짚어 보면 공통점이 프롬프트의 정교함이 아니었다. 같은 작업에 같은 입력 형식을 쓰기로 팀이 합의했는가였다. 합의가 있으면 프롬프트가 평범해도 결과의 편차가 줄고, 편차가 줄면 검토하는 사람이 무엇을 볼지 정할 수 있다.

반대로 각자 자기 방식으로 쓰면 결과물의 형식이 매번 달라진다. 그러면 검토자는 내용을 보기 전에 형식부터 파악해야 하고, 그 부담이 쌓이면 검토가 형식적으로 변한다. 검토가 형식적으로 변하는 순간 그 도구는 업무 흐름에서 빠지기 시작한다.

재사용 가능한 구조를 만드는 최소 조건

거창한 프롬프트 라이브러리가 필요한 건 아니다. 실무에서 효과를 본 최소 조건은 세 가지였다.

• 입력 형식 고정 — 무엇을 넣을지를 항목으로 정한다. “배경, 대상 독자, 하지 말아야 할 것” 정도의 골격만 있어도 결과 편차가 크게 준다.
• 출력 형식 고정 — 결과를 어떤 모양으로 받을지 정한다. 검토자가 매번 같은 자리에서 같은 항목을 확인할 수 있어야 검토가 유지된다.
• 보관 위치 하나 — 팀이 실제로 여는 문서 안에 둔다. 별도 도구에 모아두면 관리 대상이 하나 늘어날 뿐 실제로는 안 열린다.

세 가지 모두 프롬프트 자체의 문장력과는 상관이 없다. 오히려 문장이 화려할수록 다른 사람이 손대기 어려워져 재사용을 방해하는 경우가 있다.

형식을 고정한다는 게 실제로 어떤 모습인가

“입력 형식을 고정한다”는 말이 추상적으로 들리기 쉬운데, 실무에서는 문서 상단에 빈칸 몇 개를 두는 수준으로 시작한다. 예를 들어 회의록을 정리하는 작업이라면 회의 성격, 이 정리를 읽을 사람, 반드시 남겨야 할 항목, 빼도 되는 항목 정도다. 이걸 채우고 나면 그다음 문장은 거의 자동으로 정해진다.

출력 형식도 마찬가지다. 결론을 먼저 쓸지, 항목별로 나눌지, 미결 사항을 따로 뺄지를 정해두면 검토자가 매번 같은 자리를 본다. 이 ‘같은 자리’가 생기는 것이 핵심이다. 검토는 결국 습관이라, 볼 곳이 매번 바뀌면 유지되지 않는다.

구조가 무너지는 신호

만들어 둔 구조가 실제로는 안 쓰이는 경우가 있다. 무너지고 있다는 신호는 대체로 이런 형태로 나타난다.

• 결과물의 형식이 사람마다 다시 갈리기 시작한다 — 합의가 느슨해졌다는 뜻이다.
• “이건 예외라서”라는 단서가 붙은 사용이 늘어난다 — 예외가 잦으면 형식이 현실과 안 맞는 것이므로, 지키라고 압박할 게 아니라 형식을 고쳐야 한다.
• 검토 코멘트가 내용이 아니라 형식 지적으로 채워진다 — 검토자의 부담이 이미 한계에 왔다는 신호다.

세 신호 중 둘 이상이 보이면 프롬프트를 다듬을 때가 아니라 형식을 다시 협의할 때라고 판단한다. 이 구분을 놓치면 문장만 계속 고치면서 같은 자리를 맴돌게 된다.

덧붙이면, 이 구분은 도구가 바뀌어도 그대로 쓸 수 있다. 모델이 좋아질수록 개별 프롬프트의 중요도는 오히려 떨어지고, 무엇을 맡길지와 그 결과를 누가 어떤 기준으로 볼지가 남는다. 그래서 나는 새 모델이 나왔다는 소식보다 우리 팀이 쓰는 형식이 아직 유효한지를 먼저 확인한다.

다만 이 판단 기준에도 한계는 있다. 형식을 자주 고치면 고치는 일 자체가 비용이 되므로, 신호가 한 번 보였다고 곧바로 손대기보다 두어 주기를 두고 같은 신호가 반복되는지 확인한 뒤 움직이는 편이 낫다. 팀 규모가 작을수록 이 유예는 짧아도 되고, 관여하는 사람이 많을수록 길게 잡는 편이 안전했다.

그래서 프롬프트 엔지니어링이 정말 필요한 순간

과대평가됐다고 해서 불필요하다는 뜻은 아니다. 공을 들일 값이 확실한 구간이 있다.

첫째, 일회성이지만 실패 비용이 큰 작업이다. 외부에 나가는 문서나 되돌리기 어려운 판단이 걸린 경우엔 한 번을 잘 뽑는 것 자체가 목적이라 재사용 구조를 따질 이유가 없다.

둘째, 형식을 아직 못 정한 탐색 단계다. 어떤 출력이 쓸모 있는지 모를 때는 여러 방식으로 물어보며 감을 잡아야 하고, 이 구간에서는 프롬프트를 바꿔보는 것이 곧 요구사항을 정의하는 과정이다. 다만 이 단계가 끝나면 그 결과를 형식으로 고정하는 작업이 따라와야 한다. 탐색만 반복하면 조직에는 아무것도 남지 않는다.

정리하면 이렇다. 프롬프트를 잘 쓰는 것은 개인의 생산성 문제이고, 그것이 남는 것은 팀의 구조 문제다. 도입이 정체됐을 때 프롬프트부터 손보고 싶어지는데, 내가 먼저 확인하는 건 잘 쓴 프롬프트가 지금 어디에 저장돼 있는가다. 답이 “각자 알아서”라면 문장을 다듬어도 결과는 잘 바뀌지 않는다.

관련 글

• 매주 반복하는 보고서, ChatGPT로 절반 줄인 실제 과정
• AI 도입 첫 3개월, 우리 팀이 놓쳤던 것들

대표 이미지: Photo by StartupStockPhotos on Pixabay (https://pixabay.com/photos/man-write-plan-desk-notes-pen-593333/)