LLM이 처음 대중에게 선보인 2023년 이후에 우리의 삶에 깊이 자리 잡으며, 프롬프트 엔지니어링(prompt engineering)은 초기부터 LLM의 활용의 핵심적인 역할을 해왔습니다. 프롬프트 엔지니어링은 LLM에 입력으로 주어지는 프롬프트를 조정하여, LLM의 출력을 조정하여 원하는 범위와 정도로 컨텐츠가 나오도록하는 방법론의 총체를 이르는 단어입니다. 저는 다음에 이어지는 호칭들을 좋아하지는 않지만, 프롬프트 엔지니어링을 이르는 호칭들이 달랐을 뿐이지 이전부터 유행하는 방법들이 공통적으로 가지는 방향의 골자는 같았죠. : 'GPT 길들이는 방법', 'ChatGPT 잘 쓰는 프롬프트 작성법', 'ChatGPT의 할루시네이션을 막아주는 마법의 단어들'... 시간이 지나면서 LLM 기반의 기능을 구현해서 제공하는 플랫폼이나 서비스, 기능들이 생겨나고, 프롬프트 엔지니어링에 검색 솔루션을 적용한 RAG가 업계의 주목을 받으면서 독자적인 생태계를 거대하게 구축하는 등 산업계의 수요를 중심으로 여러가지 변화가 있었습니다. 변화가 빠른 LLM 생태계인 만큼, 모델 또한 발전했지요. Scailing Laws 에 기대어 모델의 사이즈를 키워가면서 업데이트를 한 것은 물론이고, o1과 같은 추론모델의 등장으로 또 다른 돌파구를 만들어내었습니다. 그러면서 SW개발 영역에서도 다양한 Use Cases 들이 등장했었구요. 프롬프트 엔지니어링도 마찬가치로 이에 맞춰서 지난 2년간 각자의 필드에서 많은 변화를 가져왔었습니다. 프롬프트 자체에 대한 텍스트 작성 및 프롬프트 전략은 물론이고, 요약이나 추론에서 어떤 방법을 활용하여 정보를 통제하고 관리하며 생성할 지에 대한 많은 연구들이 있었습니다. In-Context Leaning을 기반으로 시작한 CoT와 Few-Shots Prompting 부터 시작해서 수많은 전략과 방법론들이 뜨고 지는 2년이었습니다. 그러나 기술이 발전함에 따라, “프롬프트 엔지니어링은 종말을 맞이하고 있는가?”라는 질문을 받게되거나 마주치는 횟수가 많아지고 있습니다. 그러한 빈도가 늘어나고 있다는 것은 아래와 같은 몇 가지를 의미하지요. 예를 들어 :

아래의 글을 먼저 읽고 오면 글의 제목과 맥락을 이해하기 쉽습니다. eval()? eval() 함수는 다양한 스크립트 언어에서 제공하는 기능으로, 문자열 형태로 작성된 코드를 실행할 수 있는 함수입니다. JavaScript, Python, PHP, Ruby 등에서 공통적으로 존재하며, 문자열을 그대로 가져와서 코드로 실행이 가능한 만큼 강력한 도구이지요. 하지만 그동안 eval은 위의 레퍼런스에서처럼 사악한 사술로 비추어졌습니다. python에서는 단일식만 처리가 가능한 eval()과 여러 문의 코드를 처리하는 exec()이 구분됩니다. 하지만, 이 글에서는 같은 맥락의 함수로 여기겠습니다. eval() is evil? 이렇게 강력한 도구가 왜 위험한 것을 넘어서, 사용하는 것 자체에도 '사악하다'는 오명이 붙었을까요? 가장 큰 문제는 보안 취약점입니다. eval()은 문자열로 전달된 내용을 그대로 실행하는 함수입니다. 그렇기에 입력이 정확하게 통제되어야 안전한 사용임을 전제로 하지요. 이런 함수가 문제가 되는 상황은 어떤 상황일까요? 외부에서 임의로 입력된, 신뢰할 수 없는 데이터를 실행하는 경우입니다. 이런 특성은, '사용자를 절대로 믿지말라'고 가르치는 웹 개발에서 특히 문제가 됩니다. 임의의 유저가 어떤 입력을 가져올 지 모르는 일이고, 이를 그대로 믿어서는 안되니깐요. 예를 들어, 사용자가 입력한 문자열을 그대로 eval()로 처리하면, 공격자는 이를 악용해 시스템 명령어를 실행하거나 데이터를 탈취할 수 있습니다. XSS이나 RCE 같은 심각한 공격에 노출될 위험도 있죠. 문자열로 받은 코드를 실행하기에 생기는 문제도 있습니다. 그대로 실행하기엔 사전에 성능 평가나, 디버깅도 어렵습니다. 문제가 생긴다면, 이를 잘 캐치할 수 없죠. 이를 보면, eval() 자체의 문제이기보다는 eval() 함수가 사용되는 환경을 둘러싼 문제에 가깝지 않으신가요? eval() 자체는 강력한 도구이지만, 런타임에서 항상 불안함을 가지고 있던 eval()이었고, 비교적 개방적인 웹 생태계였기에 이런 분위기가 형성된 것이라고 봅니다.

(앞 생략) 그래서, 저희가 서비스를 개발할 때에는 할루시네이션이 기본적으로 에러가 아닌, 기능이라는 관점을 가지고 접근을 했습니다. (이하 생략) 이게 무슨 소리지? 싶었습니다. 아마 그 시점으로부터 2-3개월만 앞으로 당겼어도 말도 안된다면서 고개를 내저었을지도 몰랐죠. 그때의 저는 특정 데이터에 기반해서 문제를 내고 개념을 가르치는 교사 Agent를 개발하고 있었으니깐요. 그렇다면 지금은? 지금은 확실히 다릅니다. 위의 이야기를 이해하고 나니, LLM으로 하는 창의적인 작업에 대해서 경계가 한꺼풀 허물어지고 구현에서 자유함을 경험할 수 있었습니다. 형식을 탈피하고, 스스로 설정한 구현의 경계라는 억압에서 해방되었죠. 사실 위의 대사는 제가 한 말이 아니고, 'Zeta'를 서비스하고 있는 스캘터랩의 김종윤 대표님의 이야기입니다. SK AI Summit 2024에서 가장 저에게 충격적인 멘션이고, 지금도 여운이 남는 멘션이었습니다. 현상이 에러가 되기 위해서는 할루시네이션은 항상 모든 케이스에서 에러와 이어지는가? 사실 거의 모두가 곧잘 그렇게 생각합니다. ChatGPT에서 세종대왕이 맥북을 던지기 시작한 이래로, '사실과 틀리고, 말이 안되는 정보'를 출력하는 현상은 LLM의 대표적인 문제점이 되었습니다. 주어진 문제에서 얼마나 말이 안되는 말을 하는지가 LLM 성능의 척도가 되었고, 말이 안되는 응답은 웃음거리가 되기도, AI포비아의 근거가 되기도, 아니면 고소장의 주요 요인이 되기도 했죠. 이를 극복하기 위한 수단으로써 RAG가 독립적이면서 확고한 기술 스텍으로 성장한 계기가 되었구요. 하지만 돌이켜보면 할루시네이션이 문제라고 지적하는 맥락에서는, 몇 가지 전제가 있었습니다. 첫째, LLM이 생성하는 콘텐츠는 사실적이고 정확해야 한다는 기대가 있었습니다. ChatGPT 출시 이후부터 지금까지 LLM이 지속적으로 발전하면서, 생성하는 콘텐츠는 인간이 작성한 것과 동일하거나 그 이상의 정확성과 신뢰성을 가져야 한다는 기대감도 함께 커졌습니다.