프롬프트 엔지니어링에 대한 논의가 있을 때마다 반복적으로 나타나는 혼란을 발견했는데, 그 혼란은 언어 모델을 사용하는 두 가지 전혀 다른 방식에서 비롯된다고 생각한다. 바로 인터랙티브 프롬프팅과 트랜잭셔널 프롬프팅이다. 프롬프트 엔지니어링은 본질적으로 트랜잭셔널 프롬프팅에 관한 것이며, 누군가 이를 인터랙티브 프롬프팅에 적용하려 할 때 상당한 혼란이나 부정적인 반응이 생겨난다.

인터랙티브 프롬프팅은 ChatGPT처럼 언어 모델과 일종의 대화를 나누는 방식의 프롬프팅이다. 모델이 모호한 응답을 내놓으면 기존 맥락을 활용해 추가 설명을 하거나 모델을 올바른 응답으로 이끌 수 있다. 또한 인터랙티브 프롬프팅은 주로 사람이 직접 주도한다.

트랜잭셔널 프롬프팅은 언어 모델을 프로그래밍 언어의 함수처럼 다룬다. 입력을 주고 원하는 출력을 얻는 방식이다. 단일 프롬프트에만 국한되지 않으며, 프롬프트를 연결하거나 소위 ‘에이전트’와 같은 동작을 수행할 수도 있다. 핵심은 매우 구체적인 문제를 위해 언어 모델을 트랜잭션 방식으로 다루며, 대개 대량으로, 소프트웨어에 의해 구동된다는 점이다.

프롬프트 엔지니어링에 대한 지식은 이론상 스타일에 관계없이 모델로부터 원하는 결과를 더 효과적으로 얻도록 도와주기 때문에 두 방식 모두에 도움이 될 수 있다. 하지만 프롬프트 엔지니어링의 가장 큰 효용은 트랜잭셔널한 사용 사례에 있다고 본다.

프롬프트 엔지니어링은 언어 모델로부터 가장 높은 정확도와 가장 낮은 비용으로 원하는 결과를 얻어내는 것에 관한 것이다. 이러한 목표는 트랜잭셔널 사용 사례에 더 잘 부합한다.

객관성 vs. 주관성

과정이 인터랙티브한지 트랜잭셔널한지라는 구분만으로는 프롬프트 엔지니어링의 가치를 깔끔하게 나누기에는 미묘함이 부족하다. 또 다른 차원으로 나눌 수 있는 기준은 객관성과 주관성이다.

객관적으로 옳은(혹은 ‘대체로 옳은’이라고 해도 좋을) 출력을 만들어낼 수 있는 입력이 있다면 프롬프트 엔지니어링을 성공적으로 적용할 수 있다. 객관적으로 옳은 결과를 내는 문제의 예로는 정보 추출, 분류, 제한적인 형태의 코드 생성 등이 있다.

반면 주관적으로 옳은 무언가를 만들어내는 입력이라면 프롬프트 엔지니어링의 효용은 훨씬 떨어진다. 주관적 결과의 가장 대표적인 예는 예술 생성, 글쓰기, 시맨틱 검색과 같은 창의적인 작업이다.

예술을 객관적으로 좋다거나 나쁘다고 ‘엔지니어링’할 수 없는 것과 마찬가지로, 주관적인 작업에 대해 LLM을 ‘프롬프트 엔지니어링’해서 객관적으로 좋고 나쁨을 가리는 것도 불가능하다. 주관적인 작업에 프롬프트 엔지니어링을 적용해 결과물이 주관적으로 수용될 가능성을 높일 수는 있지만, 객관적인 작업에서와 같은 수준의 확실성이나 정확도를 가질 수는 없다.

물론 주관적인 작업에서도 원하는 결과에 도달하는 데 도움이 되는 널리 알려진 ‘프롬프트 템플릿’이 많이 존재한다는 점을 지적할 수도 있다. 예를 들어 특정 스타일의 이미지를 안정적으로 생성하기 위한 템플릿이 존재한다. 하지만 이러한 프롬프트 템플릿에 도달하는 과정은 엔지니어링이나 과학적 실천이라기보다는 창의적인 글쓰기 과정에 가깝다.

나는 ‘코드 생성’을 객관적 작업이자 주관적 작업의 예로 본다. 이론적으로 코드 생성은 객관적으로 옳을 수 있다. 소프트웨어의 동작에 대해 충분히 정확한 명세가 있다면, 그 소프트웨어가 명세를 통과하는지 실패하는지를 객관적으로 말할 수 있기 때문이다. 하지만 현실에서는 거의 어떤 소프트웨어도 그 수준의 구체성을 갖추지 못한다. 따라서 코드 생성 작업이 클수록 더욱 주관적이 되고, 반대로 작업이 작을수록 테스트 케이스나 입력 언어를 정확하게 명세할 가능성이 높아지며 더욱 객관적이 된다¹.

객관적이고 트랜잭셔널한 프롬프팅

일반적으로 프롬프트 엔지니어링에 대한 지식은 당면한 작업이 무엇이든 언어 모델에서 원하는 정보를 추출하는 데 있어 누구에게나 더 효과적이 되도록 만든다. 다만 인터랙티브 프롬프트를 위한 프롬프트 엔지니어링은 능숙한 ‘구글러’(Google 검색 사용자)가 되는 것에 가깝다면, 트랜잭셔널 프롬프트를 위한 프롬프트 엔지니어링은 데이터 사이언티스트가 되는 것에 가깝다.

프롬프트 엔지니어링은 LLM을 결제, 프로세스 내 함수 호출, SaaS 호출 등 프로그램이 연동하는 다른 API와 같은 객관적이고 예측 가능하며 트랜잭셔널한 API로 만들려는 시도다. 물론 언어 모델은 결정론적이고 100% 신뢰할 수 있는 기계가 아니므로, 그 효용과 사용 사례는 달라야 한다.

결론적으로 프롬프트 엔지니어링은 언어 모델과의 모든 프롬프트 상호작용에 적용되는 것은 아니다. 더 창의적이고 데이터 기반이거나 체계적이지 않은 상호작용도 존재한다. 하지만 마찬가지로 언어 모델 중에는 엔지니어링 방법론을 적용해 최상의 결과를 얻을 수 있는 사용 사례도 있다. 두 가지는 서로를 부정하지 않고 공존한다.