프롬프트 엔지니어링은 종말을 맞이할까?
T
Two_Jay
Subscribe
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년이었습니다.
그러나 기술이 발전함에 따라, “프롬프트 엔지니어링은 종말을 맞이하고 있는가?”라는 질문을 받게되거나 마주치는 횟수가 많아지고 있습니다. 그러한 빈도가 늘어나고 있다는 것은 아래와 같은 몇 가지를 의미하지요. 예를 들어 :
'프롬프트 짜는 것도 일인데, 이런 거 해도 제대로 만들었다고 할 수 있을까?'
'어짜피 내가 원하는 일이 모델 좋아지고, 서비스가 좋아지니깐 그냥 어느정도 다 해주는데?'
'그냥 내가 쓰는 서비스를 어짜피 알아서 딸깍 해주면, 그냥 프롬프트 엔지니어링 안해도 되는 거 아닌가?'
'어짜피 내가 원하는 일이 모델 좋아지고, 서비스가 좋아지니깐 그냥 어느정도 다 해주는데?'
'그냥 내가 쓰는 서비스를 어짜피 알아서 딸깍 해주면, 그냥 프롬프트 엔지니어링 안해도 되는 거 아닌가?'
... 이런 생각들인 것이죠. 그럼 진짜 '프롬프트 엔지니어링'은 예전 '정보검색사'처럼 무가치한 것일까요? 개인적으로는 아니라고 생각하고, 앞으로도 얼마든지 발전할 수 있는 분야라고 생각합니다.
자라나는 거인의 어께 위에서
프롬프트 엔지니어링은 상당히 넓은 의미의 영역을 가지고 있습니다. 가장 저점에서는 프롬프트를 작성하고 ChatGPT와 같은 서비스에서 쓰는 방법을 시작으로, 그런 서비스의 뒷단에서 작동하는 프롬프트를 다듬고 매만져서 서비스의 품질을 고도화하는 엔지니어링의 영역까지. 넓은 영역에서 프롬프트는 다양한 사람들 손에서 활용되고 있습니다.
이 지점에서 우리는 크게 프롬프트를 가지고 소위 엔지니어링을 하는 두 개의 유저 페르소나가 있음을 알 수 있습니다. 한 쪽은 ChatGPT나 Perplexity와 같은 LLM 기반 서비스를 활용하는 '사용자'의 영역이고, 나머지 한 쪽은 이러한 서비스를 개발하는 '엔지니어'의 영역이지요. 사실 일정 부분은 이 둘이 교집합이 있지만, 최종적인 목표가 아예 다릅니다. '사용자로서의 프롬프트 엔지니어링'과 '엔지니어로서의 프롬프트 엔지니어링'은 그 관점이나 기준이 상이하여 다른 영역을 볼 수밖에 없습니다.
LLM 서비스에서 우리가 프롬프트를 이용해서 응답을 받을 때엔, 이미 그 서비스에 내장된 수많은 프롬프트와 파이프라인이 우리의 요청을 기다리고 있고, 이미 섬세하게 짜여진 프롬프트들이 유저가 임의적이거나 대충 던져놓은 요청이라도 온전하게 잘 처리할 준비를 마치고 기다리고 있습니다. 이를 처리하는 모델 또한 아주 점차 발전하고 있는 상황이구요.
그렇기에 ChatGPT나 Perplexity.ai 와 같은 LLM portal에서 우리가 프롬프트를 짜고 활용할 때에는 프롬프트 엔지니어링에 대해 큰 가치를 느끼지 못할 수도 있습니다. 그러기에 서비스를 이용하는 '사용자로서의 프롬프트 엔지니어링'에서는 다루고자 하는 영역이 결과물의 다양성에 집중합니다. 이를 위해 프롬프트를 어떻게 디자인하고, 어떤 방향성으로 얼마나 더 다양한 시도를 하고 성과를 만들어내느냐. 창발하는 아이디어로 어떻게 다양한 케이스에서 결과물을 만들어 낼 수 있느냐에 집중합니다. 즉, 엔지니어링으로 신뢰도 있는 프롬프트를 만들기보다는 내가 필요로 하는 컨텐츠를 만들어내는 데에 더 집중하는 것이지요. 확연하게 발전된 모델 위에서 넓은 시각으로 보면서 어떤 컨텐츠를 만들어 낼지 고민하게 되지요.
마치 '거인의 어께' 위에 서있는 것 같습니다. 그리고 그 거인은 시간이 흐를수록 점점 자라나죠. 예전에야 모델이 덜 똑똑했으니 같은 서비스를 사용했어도 미세한 프롬프트 엔지니어링이 필요했다면, 지금의 LLM 서비스에서는 그런 세심한 부분까지 적지 않더라고 적당하게 만족할 만한 출력을 주니깐, 필요성이 상대적으로 떨어졌을 수 있겠다 싶습니다. 24년 이후, 프롬프트 엔지니어링의 대중 강의의 대부분의 토픽이 'ChatGPT 잘 쓰는 법' 이었던 게 사실 그걸 보여주는 것 같습니다. 서두에서 언급한 '프롬프트 엔지니어링 무용론'을 이야기하는 입장도 '사용자로서' 드는 생각을 상응하고요. 그럼 이 '거인'을 지탱하는 프롬프트는 누가 만들었을까요?
Prompt Engineer는 뭘 하고 있나?
'엔지니어로서의 프롬프트 엔지니어링'은 이보다는 조금 더 다른 방향을 바라보고, LLM을 서비스 기능에 통합하여 개발하는 영역에서 실제적인 문제해결을 하고자 하는 방향성입니다. 여기에서는 기발한 프롬프트나, 창발성이나, 창의적이고 세상에 없던 프롬프트를 작성하려는 노력은 상대적으로 덜 중요합니다. 대신에 확연하게 검증된 전략과 방법론으로 좁은 범위로 '신뢰도 높은 강건한' 프롬프트를 작성하는 데에 집중합니다.
그래서 LLM 서비스를 위한 프롬프트 엔지니어링은 서비스에서 사용자로서 프롬프트를 작성할 때와는 다른 기준을 가져야하고, 기존에 도달할 필요성이 없었던 다른 기준을 요구받습니다. 서비스의 영역을 넘어서는 기발하고 신기한 컨텐츠를 생성하는 프롬프트보다는, 안정적이고 특정한 요구사항에 강건하게 동작하면서도, 서비스의 기획안과 기능 요구안을 만족하는 프롬프트가 더 중요하게 됩니다. 그러면서도 복잡한 추론과 서비스의 기능을 만족하기 위해 프롬프트 파이프라인을 설계하는 작은 아키텍쳐의 역할도 겸하게 되지요.
이에 더해 좋은 컨텐츠, 즉 좋은 프롬프트를 만들려면 실제로 유저들이 이를 어떻게 활용하는지 추적하고 개선해야 함을 빠뜨려서는 안됩니다. 서비스 개발은 컨텐츠에 대해서 강한 의도를 가지고 특정 기능에 대해서 집중하고자 하는 초점이 있고, 이를 유저들이 온전히 경험하는지를 중요시 합니다. LLM 서비스에서 프롬프트가 생성하는 것은 곧 그 서비스의 컨텐츠가 됩니다. 그러기에 프롬프트로 생성되는 콘텐츠가 어느정도 선으로 유저에게 잘 전달되고 있는지, 그 만족도를 정성적/정량적으로 파악하는 일도 중요합니다.
위의 목표들을 달성하기 위해선, 도메인과 서비스 요구사항에 알맞은 컨텐츠 기획 등의 기획 포지션에서 하던 일들과, 전통적인 SW 개발영역에서 사용하던 TDD와 로그 분석, 이를 위한 파이프라인과 시스템 구축 또한 필요한 영역입니다. 더 나은 경험을 위해 프롬프트 파이프라인의 구현을 변경하거나 업데이트가 자주 일어나기에, 프롬프트의 복잡도를 관리하는 방법, 다수의 수정에서도 프롬프트의 맥락을 잘 관리하는 방법, 개선과 롤백 전략 등의 버전관리 정책과 노하우도 필요하지요.
무엇보다 목표로 하는 성능을 달성할 수 있으면서, 수용 가능한 타협선에서 '가장 저렴한' 모델을 사용해야 합니다. LLM api를 이용해서 서비스를 구현할 시에는 그 코스트가 저렴하면 저렴할 수록 1회 호출시 원가가 낮아지고, 이는 곧 전체 서비스의 LLM 영업비용과 수익률에도 영향을 미치기 때문입니다. 프롬프트를 최적화하여 가볍게 만들어야함과 동시에, 모델 차원에서도 프롬프트 캐싱을 통한 비용절약을 꾀하고, 이에 맞추어 프롬프트를 디자인하고 작성하고자 한다면 큰 폭으로 LLM api 비용에 대해서 절감할 수 있겠죠.
또한 회사라면, 이런 작업이 '인수인계 가능할 정도로' 전달 가능한 문서화를 기반으로 진행되어야 합니다. 프롬프트 엔지니어링에서는 아직까지 개인의 경험이나 텍스트 작성이 상당히 강한 펙터로 결과물에 작용하기에, 다수가 협업하는 상황에서 의도가 충돌하거나 이 테스크를 맡은 개인이 사라지게 되어 경험이 휘발되는 경우도 생각해야하기 때문입니다.
이런 점에서 프롬프트 엔지니어링은 오히려 LLM을 적극적으로 활용하는 회사에서는 반드시 필요한 포지션이라고 말할 수 있습니다. 아직까지는 실제로 경험해보지 않은 사람은 알 수 없는, 실제로 유용한 기술이라고 생각합니다. 결국에 LLM을 이용한 서비스를 구현하는 과정에서 프롬프트 엔지니어링은 기술 내외적으로 문제를 해결하고 기여할 수 있는 역량이 있는 것이지요.
앞으로 나아갈 Prompt Engineering
위에서 엔지니어로서 요구받는 역량과 사용자로서의 요구받는 역량은 다르지만, 저마다의 지향점을 종합하고 특수화시키면 아래의 방향들이 프롬프트 엔지니어의 다음 스텝이지 않을까 생각합니다.
0.
당연히, 프롬프트 엔지니어링 그 자체의 역량은 중요합니다.
1.
프롬프트 엔지니어링 역량을 강화하면서, NLP/LLM 전반을 가져가거나, Web/App 스텍을 가져가면서 전천후로 LLM powered App을 스스로 만들 수 있는 개발자로 특성을 강화해갈 수 있습니다. 이 경우, "스스로 온전하게 프로덕트를 작게라도 만들어낼 수 있다"는 점이 중요합니다. LLM 생태계와 같이 아주 빠른 속도로 시장이 변하는 경우, 작게라도 MVP를 만들어서 시장에 내어놓아 유저의 반응을 살펴보고 피벗할지 지속할지 결정하는 것은 아주 중요합니다.
2.
계속 강조하는 바이지만 "프롬프트로 생성된 것이 곧 서비스의 컨텐츠입니다". Content에 대하여 결정할 수 있는 위치에 있다면, 서비스의 컨텐츠의 기준이나 기대사항 등을 정하여 스스로 프롬프트를 구현할 수도 있으며, 이런 Content Management쪽으로 뻗쳐나가서 기획레벨에서 프롬프트 엔지니어링을 겸하여 서비스의 컨텐츠를 전담하는 방향도 있습니다. 최근에는 Dify와 같이 좋은 인터페이스에서 프롬프트 작성에 집중할 수 있도록 도와주는 플랫폼도 있으니, 기획에서 프롬프트에 접근하여 실제로 개발을 진행할 수 있습니다.
3.
법률이나 의료, 혹은 다른 특수한 지식이나 시각, 경험이 필요한 도메인에서는 도메인 전문가가 이 일을 할 수도 있습니다. 도메인 전문가는 서비스에서 제공되는 컨텐츠의 퀄리티를 위해 이미 어떤 점을 신경써야 하고, Pain Point가 무엇인지 확실하게 아는 영역에 서있는 사람이기 때문입니다. 이런 시각과 경험, 지식을 가진 분이 LLM과 프롬프트 엔지니어링을 쥐었을 때, 그 서비스의 퀄리티가 자연스레 올라가는 것은 당연한 일입니다.
4.
프롬프트를 적용하는 방법론이나 연구는 이와 별개의 루트로 계속해서 발전하게 됩니다. LLM 프롬프트에서 연구하는 리서처의 논문이나 연구자료와 같은 검증된 자료와, 커뮤니티에서 개별적으로 활동하고 연구하는 프롬프트 개인 연구자들, 그리고 프롬프트를 적어나가고 개발에 적용하면서 경험하고 알게되는 노하우를 가진 모든 개인이 이 영역에 참여하게 됩니다.
물론 제가 보는 방향성은 이 정도이지만, 저만의 시각에서 이를 결정하는 건 아니기에 참고를 하는 정도로 보아주셨으면 좋겠습니다. 엔지니어의 입장에서는 가장 많이 의논하고 필요로하는 역량들이었고, 프롬프트 엔지니어링이 이런 일도 같이 손에 쥐고 있다면 시니어로써 특화된 역량을 가지면서 프롬프트 엔지니어링의 경계도 넓어질 수 있을 것이라 생각됩니다.
그래도 진짜 없어지게 된다면?
그래도 저는 프롬프트 엔지니어링이 언제든 없어질 수 있다는 입장이기도 합니다. 되려, 사실 RAG나 프롬프트 엔지니어링과 관련된 모든 일은 LLM 의존적인데다가, 비즈니스적 요구로 생태계가 형성된 케이스이기 때문에 LLM 모델이, 혹은 이를 제공하는 회사가 (데이터 프라이버시를 보장해준다던가) 그 이점을 제공하게 된다면 대상이 되는 생태계의 인기가 시들해지거나 옛기술로 전락할 수도 있다고 생각합니다. 이는 LLM 생태계만의 문제가 아니라, 기술 발전에서 보편적으로 일어나는 현상이기도 합니다.
그래도 진짜 프롬프트 엔지니어링이 없어진다면 어떻게 될까요? 저는 여기서 프롬프트 엔지니어링이 가지는 본업의 핵심을 두 가지로 분리하고 싶습니다.
•
하나는 우리가 수행하는 작업으로 "프롬프트를 퀄리티있게 적어내려가고 구현하는 행위"입니다.
•
다른 하나는 "프롬프트를 잘 구현하는데에 필요한, 사람과 AI 사이의 의사소통을 연구하는 경험과 인사이트"입니다.
이 둘을 분리하게 되면, 프롬프트 엔지니어링이 언젠가는 종말을 맞더라도 지향해야하는 바는 분명하다고 생각합니다. 프롬프트 엔지니어가 텍스트로 심혈을 기울여 실험하고 배열하는 일은 없어질 수 있습니다. 마치 개발자가 손수 코드를 구현하고, 연구자가 일일히 참고서적과 자료를 하나하나 읽어야 했던 일처럼요. 이렇게 프롬프트라는 텍스트 자체를 작성하는 일은 언젠가는 사라질 수 있습니다. 그렇게 된다면 프롬프트 엔지니어링에서 프롬프트를 작성한다는 가장 큰 일은 다른 형태로 변하거나 사라지게 되겠지요.
하지만 프롬프트가 가지는 본질은 그것이 '의사소통하기 위한 도구'라는 점입니다. 결과물을 작성하는 일은 사라져도, 그를 위해 쌓아올린 'AI와, LLM과, 무기물과 대화하는 것은 어떤 것이고, 그것을 어떻게 도움이 되는 방향으로 가져올 수 있을까?'라고 고민하는 인사이트와 경험은 쉽게 사라지지 않을 것입니다. 그렇게 된다면, 프롬프트 엔지니어링은 또 다른 방향으로 전환기를 맞이할 수 있을 것 입니다.
종종 저는 프롬프트 엔지니어링에 미래가 있느냐는 질문에 위와 같이 대답하곤 합니다. '인간이 인간이 아닌 무기물과 자연어로 대화하여 그 결과물이 사회에 유익하고 파급력있게 사용되어진 케이스'는 현재의 LLM이 역사 이래로 거의 최초이자 시작에 가깝고, 인간과 AI간의 의사소통을 연구한다는 점에서는 앞으로도 지속가능한 분야이기 때문입니다.
앞날을 예측하거나 미리 내다보는 일은 여전히 쉽지 않습니다. 중요한 것은 어떤 일을 선택함으로써 무엇을 남기고, 어떤 기회를 만들며, 어떤 경험을 쌓을 수 있는지를 판단하는 것입니다. 그런 점에서 프롬프트 엔지니어링에 도전한 것은 제게도 큰 도전이었습니다. 이 분야가 단순히 3년 정도 반짝 인기를 끌다가 사라질 가능성도 있기 때문이죠.
그럼에도 프롬프트 엔지니어링을 실제로 경험하면서, 이 분야가 결코 쉬운 영역이 아님을 깨달았습니다. 특히 제대로 해냈을 때 문제 해결의 파급력과 그로 인한 이익은 상당할 것이라 생각했습니다. 이를 통해 얻을 수 있는 통찰과 경험 또한 제게 큰 가치가 될 것이라고 확신했습니다. 그러하기에, 프롬프트 엔지니어링을 당장 없어진다고 생각하지 않고, 조금 더 넓게 그려보려고 합니다. 저는 그럴만한 가치가 있는 일이라고 생각합니다.
Subscribe to 'Two-Jay_prompt_engineer'
안녕하세요. Prompt Engineer TwoJay 입니다.
저를 구독하시면, 프롬프트를 짜오면서 제가 겪은 경험과 생각들을 나눌 때에 더 빠르게 소식을 아실 수 있습니다. 🥰
저를 구독하시면, 프롬프트를 짜오면서 제가 겪은 경험과 생각들을 나눌 때에 더 빠르게 소식을 아실 수 있습니다. 🥰
Subscribe
4