[슬기로운 AI 활용 생활 ⑥] 개떡같이 물어도 찰떡같이 답하는 AI는 없다

‘요즘은 챗GPT한테 대충 물어도 잘만 대답하던데, 프롬프트 엔지니어링의 가치가 아직도 유효할까?’

강수진 더프롬프트컴퍼니(TPC) 대표에게 인터뷰를 요청한 건, 이 질문에 대한 답을 듣고 싶어서였다. 강 대표는 언어학 박사 출신으로, 국내 최고의 프롬프트 엔지니어로 꼽히는 인물이다.

사실 나는 ‘프롬프트 엔지니어링’이라는 작업에 대해 약간의 의구심이 좀 있었다. 지금은 생성형 AI라는 기술이 등장한지 얼마 되지 않은 초창기라서, 기술의 이상과 현실을 메우기 위해 잠시 등장한 기법이 아닐까, 생각했다. 새로운 기술이 등장하면 잠시 생겼다가 사라지는 직군이 있곤 했기 때문이다.

일례로 인터넷이 처음 등장했을 때 ‘인터넷 정보 검색사’라는 자격증이 있었다. 고백하자면 나는 그 자격증을 땄었다. 하지만 지금은 인터넷에서 정보를 검색할 때 필요한 전문 기술이나 기법이 있다고 생각하는 사람은 없다.

내가 이해하기로 ‘프롬프트‘란 사람이 챗GPT와 같은 AI에게 던지는 질문의 다른 표현일 뿐이고, ‘엔지니어링’은 과학이나 기술을 활용해 주어진 과제를 해결하는 일이다. 이 두 단어가 합성되는 전문분야라는 건 어딘가 어색하게 느껴졌다.

강 대표는 이 질문에 가장 좋은 답을 줄 수 있는 인물이라고 생각했다. 그는 국내에서 보기 드문 전문 프롬프트 엔지니어로, 단순히 문장을 잘 쓰는 ‘프롬프트 라이터’가 아니라 프롬프트를 통해 AI의 기능을 설계하고, 정확성과 일관성을 확보하며, 비용 효율까지 달성하는 미션을 수행하는 것으로 알려져 있다.

강 대표는 인터뷰에서 프롬프트는 “AI와 상호작용하는 자연어 도구”이며 프롬프트 엔지니어링은 “컴퓨터와 효율을 높이며 대화하는 기술”이라고 설명했다. 어떤 단어를 어떤 순서로 넣느냐에 따라 AI의 응답은 전혀 달라지고, 같은 질문이라도 모델에 따라, 문장에 들어가는 ‘기호’에 따라 품질이 천차만별이라고 한다. 이 차이를 이해하고 다듬는 것이 바로 프롬프트 엔지니어의 역할이라고 강 대표는 설명했다.

프롬프트 엔지니어링에 대한 나의 의구심을 없앤 강 대표의 이야기를 들어보자.

프롬프트 엔지니어링에 대한 이야기를 나누기 전에, 먼저 정의부터 내려야 할 것 같습니다.

프롬프트에 대한 정의를 먼저 하자면, 프롬프트는 AI랑 대화하는 ‘자연어 도구’라고 말할 수 있습니다. AI와의 대화창에 “안녕”이라고 넣으면, 이것도 프롬프트입니다. 그다음에 ‘엔지니어링’이라는 건 효용을 극대화하는 작업이라고 말할 수 있습니다. 그래서 저는 프롬프트 엔지니어링을 “컴퓨터(AI)와 상호작용 하면서 효율을 높이는 일”이라고 정의를 해요.

효율을 높인다는 게 어떤 의미인지, 예를 들어 설명해 주시겠어요?

제가 만든 기능 중에 한 줄로만 프롬프트를 만드는 서비스를 했던 사례가 있어요. 질의 토큰 수를 줄여도 고품질을 답을 만들 수 있다면, 비용 면에서 확실히 절감이 가능하죠. 특히 B2C 서비스를 하는 플랫폼의 경우에는 엄청난 비용 절감이 가능해집니다. 이런 게 프롬프트 엔지니어링의 힘이라고 말할 수 있어요.

 LLM이 처음 나왔을 때는 원하는 답을 얻는 게 쉽지 않아서 프롬프트 엔지니어링이라는 작업이 중요하다고 했었는데, 요즘은 챗GPT 같은 걸 써보면 대충 물어도 척척 답을 하더라고요. 그럼, 프롬프트 엔지니어링이 점점 필요 없어지는 것 아닐까 하는 생각도 듭니다.

GPT 3.5 터보 시절에는 안 되는 게 너무 많았어요. 요즘은 춘추전국시대라고 부를 정도로 모델이 많이 나오는데, 여전히 안 되는 게 많아요. 문제 해결을 위해 모델을 미세조정(Fine Tuning)하고, 다시 학습시키고 하는 것도 하겠지만, 자연어 질의를 잘 구축하면 시간과 가격, 효율 면에서 훨씬 좋다고 생각해요.

미국 같은 곳에서는 모델 개발사에서 프롬프트 엔지니어링 연구자나 기술자를 뽑아요. 미세조정보다 프롬프트 엔지니어링을 먼저 하는 게 작업 수순이 되어 가고 있어요. 그런데 국내에서는 프롬프트 엔지니어를 단순히 프롬프트 라이터(writer)라고 생각하는 경향이 있어요.

 저도 프롬프트 엔지니어를 프롬프트 쓰는 사람이라고 생각했었는데, 많이 다른가요?

절대 그렇지 않습니다. 저희 고객사 중에 AI 모델을 만드는 곳이 있어요. 모델을 만들어 놓고 해결 못 하던 문제 해결을 위해 프롬프트 엔지니어링 작업을 저희에게 의뢰하고 있어요.

모델이 안 되는 건 대표적으로 4개예요. 할루시네이션, 정확도가 떨어지는 것, 맥락을 이해 못 하는 것, 일관성이 떨어지는 것입니다. 예를 들어 법률 특허 AI 모델을 만든다고 해보죠. LLM에 100%는 불가능하다손 치더라도, 97% 98%까지 완전성을 보장해 줄 수 있는 기술이 프롬프트 엔지니어링이라고 보고 있어요.

이용자가 질문을 넣으면 프롬프트 엔지니어링 단계에서 그 질문을 최적화시킨 질문으로 교체한 다음에 LLM에 던지는 건가요?

그런 작업도 물론 하고요. 이용자는 그냥 일상적으로 질문을 하고, 백단에서 좋은 답변을 받을 수 있게 하는 작업도 물론 하지만, 아예 기능 자체를 만드는 일을 많이 해요. 예를 들어서 법률 모델이라면 프롬프트만으로 소견서를 완벽하게 작성해 주는 거, 세무사라면 연말 소득 정산을 완벽하게 해주는 계산기를 만들어 주는 거를 하는 거죠. UI는 웹페이지가 되겠지만 뒷단에 어떤 시스템 코드가 자연어로 들어갑니다.

조금 더 구체적으로 설명해 주세요.

챗GPT를 보면 이용자는 대화창 하나를 보지만, 뒤에는 이용자가 어떤 질문을 하든 오픈AI 정책에 맞게끔 답변하게 하는 시스템 프롬프트라는 게 있어요. 예를 들어 사용자가 정치적으로 위험한 발언을 하면 이렇게 답하라는 가이드라인 같은 게 있죠. 또 이용자의 질문 의도를 분석해서 실시간 검색이 필요한 한 질문 유형이라면 검색을 통해 답을 뽑게끔 하기도 하죠.

또 챗GPT가 질문마다 답하는 스타일이 다르잖아요? 어떤 질문에는 큰 제목-하위 이런 식으로 나오고 어떤 건 줄글로 나오기도 하죠. 이런 것도 다 프롬프트로 커스터마이징하는 거예요.

이용자는 모르는 프롬프트 엔지니어링이라는 레이어가 있다고 생각하면 되는 거죠?

네, 하지만 사용자가 볼 수 있는 공간도 있어요. 예를 들어 클로드에 제너레이터(Generator)라는 기능이 있어요. 사용자가 프롬프트를 너무 못 쓰니까 사용자가 뭘 넣으면 우리(클로드)가 초안을 생성해 주자라는 컨셉이에요. 프롬프트 템플릿을 자동으로 생성해 주는 도구를 만들었어요. 이것도 프롬프트로 바꾸는 겁니다.

사용자가 ‘주식 분석을 위한 프롬프트 써줘’라고 하면 프롬프트를 만들어줍니다. 이 뒷단에는 이거를 잘하게 하기 위한 시스템 프롬프트가 작업을 하는 식입니다. 시스템 프롬프트 작업을 했기 때문에 이걸 복사해서 클로드에서 채팅창에 넣으면 더 길고 좋은 답변을 받습니다.

프롬프트 엔지니어링을 위해 프로그래밍 관련 코드는 몰라도 되나요?

아뇨. 사실 코드로 하는 작업이 더 중요해요. 예를 들어 챗GPT-4 미니의 성능이 4o 같은 추론 모델에 비해 그렇게 좋지 않아요. 그런데 추론 모델은 너무 비싸거든요. 기업들은 API 단위로 비용을 지불해야 하기 때문에 예산이 풍족하지 않은 기업들은 추론모델을 사용하기에 부담이 됩니다. 그래서 저렴한 모델로 추론 모델 수준의 답변을 이끌어 달라는 요청이 저희에게 들어와요.

그런 걸 프롬프트 엔지니어링으로 할 수 있는 거예요?

그런 요구를 받으면 프롬프트 엔지니어링하는 사람은 머리가 아프죠. 그래서 제가 ‘경험의 과학’이라는 말을 요즘 많이 합니다. 또 저희가 작업한 것 중에 퍼플렉시티처럼 관련 질문을 만들어 주는 게 있는데요. 이런 기능을 프롬프트 엔지니어링으로 만들었습니다. 프롬프트랑 코드를 맞물려서 기능이 작동하도록 하는 겁니다.

또 도메인 특화 답변을 할 때도 프롬프트 엔지니어링을 할 수밖에 없어요. 같은 ‘A’라는 단어라도 특정 도메인에서는 다른 느낌으로 사용하는 경우가 있잖아요.

좋은 프롬프트란 어떤 거라고 보세요?

1번은 항상 정확하게 나오는 프롬프트입니다. 생성형 AI는 어떤 때는 잘 나오고 어떤 때는 잘 안 나와요. 이건 잘못 만든 프롬프트입니다. 100만 명이 쓰더라도 그 답변이 항상 일관적이고 오류가 없어야 해요.

2번은 비용을 절감해야 돼요. 사실 비용을 절감하는 게 쉽지 않습니다.

저의 경우는 전공(대화 분석)도 도움이 많이 돼요. 어떤 단어를 사용해서 질문하느냐에 따라 결과가 달라집니다. 뭔가를 알고 싶다고 영어로 요청할 때 ‘want’라는 단어와 ‘like’라는 단어는 유의어니까 둘 다 사용해도 의미는 비슷하죠. 그런데 프롬프트에 ‘want’를 쓰는 것보다 ‘like’를 쓰면 결과가 확실히 더 좋아져요. 시대에 따라 사용하는 단어가 달라지는데 현대 미국 영어에서는 want보다 like를 더 많이 사용했던 거예요. 저는 이런 종류의 테스트 툴을 만들어서 사용하고 있어요. 프롬프트가 과학이라고 생각합니다. 단어 하나만 잘 써도 진짜 결과가 달라지고 문장 순서만 바꿔도 달라져요.

프롬프트 엔지니어링은 과학이다?

네, 객관적이고 과학적이라고 입증할 수 있는 게 되게 많은데, 안타깝게도 국내에서는 연구하시는 분도 많이 없어요. 해외에는 이런 걸 연구하는 집단들이 있습니다.

질문을 잘하는 게 무슨 ‘엔지니어링’이야? 라고 생각할 수도 있을 거 같아요.

프롬프트도 계속 테스트하면서 최적화해야 합니다. 질문 순서에 따라 답이 어떻게 달라지는지, 모델별로도 어떻게 달라지는지, 어떤 모델의 조합이 가장 좋은 답을 내놓는지 계속 테스트하면서 더 좋은 답이 나올 때까지 보는 거죠. 굉장히 반복적인 작업이에요.

또 프롬프트 파인튜닝도 합니다. 프롬프트로 모델을 미세조정을 하는 값들이 있어요. 어떤 단어는 페널티를 먹여서 못 나오게 하거나, 구가 반복되면 페널티를 먹이는 것도 있어요. 프롬프트 엔지니어링은 언어에 굉장히 민감해야 해요.

프롬프트 엔지니어링으로 어디까지 해봤니? 뭐 이런 질문을 한다면 어떤 예시가 있을까요?

요즘 Character.AI를 시발점으로 페르소나형 AI가 많아지고 있어요. 페르소나 AI는 대부분 멀티턴(대화를 여러 차례 주고받는 방식)이에요. 대화를 오래 하면 AI가 앞에 나왔던 내용을 날려 먹는 문제가 있어요. 내가 분명히 커피 싫어한다고 앞에서 했는데 뒤에서 그 내용을 까먹는 바보 같은 현상이 발생해요.

그래서 프롬프트 엔지니어링으로 이 사용자에 대한 메모리를 가질 수 있도록 하기도 합니다. 어떤 걸 저장하고, 어떤 걸 저장하지 않을지 프롬프트로 하는 거죠. 사용자가 저장한 내용을 언급하면 그걸 불러와서 좋은 대화를 할 수 있도록 합니다.

 저는 AI와 대화를 할 때 까먹지 말라고 앞에서 한 얘기 다시 하기도 하는데 그럴 필요가 없겠네요. 이용자가 굳이 언급하지 않아도 숨겨진 프롬프트에서 필요한 키워드를 넣어 준다는 건가요?

네, 채팅 과정에서 쌓인 데이터 중에 가져와서 프롬프트에 넣어주는 거예요.

흥미롭네요. 다른 예시도 있으면 좀 소개해 주세요.

저는 기업의 보고서 자동화를 진짜 많이 했어요. 이용자가 주제를 던지면 사내 스타일에 맞게 AI가 보고서를 생성해 주는 거죠. 쓰는 분들은 템플릿이라고 부릅니다. 사내 스타일에 맞는 보고서가 나오도록 프롬프트를 짜는 거죠.

프롬프트로 할 수 있는 게 생각보다 정말 많군요. AI 모델 수준이 좀 떨어져도 프롬프트로 해결 가능한가요?

모델의 힘이 더 크냐, 프롬프트 엔지니어링의 힘이 더 세냐를 두고 힘겨루기를 한다고 표현합니다. 아무래도 모델 사이즈가 작을수록 모델의 힘이 더 세요. 특히 파인튜닝이 끝난 모델은 그 모델을 말랑말랑하게 바꾸기가 어려워요. 그런 경우는 프롬프트 엔지니어링이 실패할 수밖에 없어요. 그래서 저는 작업을 의뢰받을 때도 파인튜닝이 어떻게 되어 있는지, 데이터를 어떻게 넣었는지를 꼼꼼하게 물어보고 결정하는 편이에요.

모델이 작으면 프롬프트 엔지니어링이 할 일이 더 많을 것 같은데, 반대로 모델이 커야 더 자유롭군요?

모델이 크면 데이터가 많고 어떤 가능성의 경우의 수가 훨씬 많으니까, 자유자재로 이것저것 해볼 수 있어요. 모델이 작다는 거 대체로 특정 도메인에 맞춰져 있는 경우가 많거든요. 예를 들어 통신사가 우리는 통신사 사용자를 위한 전화 걸기 예약 서비스만 만들 거야, 라고 모델을 만들 수 있는데 이런 모델로는 할 수 있는 게 별로 없어요.

모델의 크기 이외의 다른 시스템적인 요소도 있잖아요. 예를 들어 RAG 같은 거. 조직이 한정된 자원을 투자해야 한다고 할 때 프롬프트 엔지니어링에 투자하는 것과 RAG 같은 기술에 투자하는 것, 어디에 방점을 두는 게 효과적일까요?

저는 현재까지 나온 모델들은 미성숙한 단계라고 보고 있어요. 아마 모든 기술이 어느 정도 자리 잡아가기까지는 프롬프트보다 중요한 게 많을 겁니다. 다만 이런 기술을 이용하는 중심점이 프롬프트라고 생각해요.

프롬프트가 쉬워 보이는 이유는 한국어로 말을 걸 수 있기 때문이에요. 진입이 쉬워 보여요. 하지만 제대로 만들려면 난이도가 완전히 제이(J)커브 모양이거든요. 하지만 RAG 같은 경우는 점점 더 로우코드/노코드로 되어 가고 있어요.

가장 어려운 건 사용자를 이해하는, 인문학적인 요소라고 생각해요. 도구는 계속 새로운 게 나오고 좋은 도구는 널려 있어요. 중요한 건 어떤 도구를 사용해서 무엇을 만들 것인가, 하는 기획이라고 생각합니다.

일반 이용자가 챗GPT 같은 기술을 이용할 때 좀 더 좋은 답을 얻고 싶을 때 사용하면 좋은 프롬프트 팁 같은 게 있을까요?

첫 번째는 ‘LLM이 좋아하는 구조로 바꿔라’입니다. 인간은 분류를 해서 질문을 한다고 생각하는 것도 컴퓨터 입장에서 보면 하나의 자연어 덩어리입니다. 기호를 사용하면 컴퓨터에 ‘이건 누락하지마’ ‘이건 중요한 거야’라고 알려줄 수 있습니다.

또 하나 비추론 모델의 경우 공손한 언어를 쓰면 좋은 답을 얻을 수 있다는 실험 결과가 있어요. 오픈AI 같은 모델 사에서 케냐의 노동자들을 고용해서 긍정 강화 기반 학습을 시켰기 때문이에요. 인간처럼 상호작용을 하게 한 거에 좋은 점수를 줘요. 영어로 예를 들며 ‘Please’ 이런 걸 붙이면 답변이 길어져요. 최근에 샘 올트먼 CEO가 챗GPT에 ‘Thank you’ 하지 말라는 기사가 있었는데, 이유가 있는 거죠.

하지만 추론 모델은 ‘Please, Thank you’ 한다고 좋은 답을 주지는 않아요. 추론 모델은 간결하게 지시를 해야 하고, 무엇을 요구하는지 단계별로 알려줘야 답변을 잘해요. 딥시크 같은 경우는 내적 독백을 해요. 그래서 추론의 여지를 주면, 이용자의 요구가 이게 맞나,라고 생각할 때 할루시네이션이 발생하거든요. 그래서 모델의 생각과 정답인 것을 구분해서 말하라고 요구하면 답이 확연히 달라져요.

요즘 챗GPT 같은 서비스는 검색 기반으로 답을 하잖아요. 근데 검색 소스가 나쁘면 답이 나쁘지 않나요?

사람의 할루시네이션이 가장 심하다고 얘기해요. 챗GPT의 경우 오픈소스로 크롤링해서 결과를 가져오기 때문에 누군가의 블로그, 브런치에서 다 가져오거든요. 그런 거 필터링하는 게 중요해요. 그래서 추론 모델이 아닐 때 무슨 토픽을 검색할지, 그 토픽 안에서 어디에서 검색할지 구조까지 명시해 주면 좋아요. 검색 키워드 조합을 ‘주제, 소스, 어디까지’ 세 단계로 명령을 해주죠.

기호를 사용하는 게 좋다고 하셨는데, 그 기호들이 합의된 기호인가요, 아니면 임의대로 사용하는 기호인가요?

합의된 기호도 있고, 임의대로 사용하는 기호도 있어요. 모델 회사에서 제공하는 프롬프트 북이라는 게 있어요. “우리는 이런 기호로 트레이닝시켰으니 이런 기호를 써라”라고 하는 거죠. 오픈AI는 쌍따옴표 4개로 사용자 프롬프트를 시작한다는 지시를 하고요. 클로드 같은 경우는 XML로 훈련했다고 알려줘요. 이런 합의된 기호도 있고 저는 구분해 주는 기호를 제가 만들어서 사용하고 있어요. 일반 보고서에서 쓸 법한 기호를 사용해요.

임의대로 기호를 쓰면 모델이 알아서 이해를 하나요?

네, 더 잘 처리가 돼요. 제가 프롬프트만 33장짜리를 쓴 적 있거든요. 기업 맞춤형 보고서 타입을 만들 때 사용한 거예요. 거기를 보시면 기호가 많이 들어있어요. 맞춤형으로 답을 얻고 싶을 때는 컴퓨터 언어나 마크다운 문법도 사용하기도 합니다.

그냥 자연어로 하는 게 아니군요.

네, 그냥 질문만 한다고 원하는 대로 답을 뽑을 수 있는 게 아니에요. 기업에서 사용할 때는 몇백 명이 써도 일괄적인 결과가 나와야 하죠. 그래서 기호가 중요합니다.

요즘 프롬프트를 자동으로 만들어주는 서비스들도 있는데, 그런 건 어떻게 생각하세요?

그런 건 아직 별로 쓸모가 없습니다. 방향 자체는 맞다고 볼 수 있는데 사람이 진짜 봐야 하는 것들이 있습니다. AI 에이전트 시대가 되면서 에이전트를 컨트롤하는 게 더욱 중요해졌기 때문에 자동화할 수 있는 건 하더라도 사람이 더 면밀히 봐야 하는 게 더 필요해졌습니다.

코딩도 비슷한 거 같아요. ‘커서(Cursor)를 사용하면 개발자를 대체할 수 있는가’라고 묻는 경우가 많은데 저는 아직 어렵다고 봅니다. 코딩할 때도 자동화가 가능한 부분은 하더라도 인간만 할 수 있는 거는 직접 코드를 써야 합니다.

제가 처음에 인터뷰 요청을 드렸던 건 ‘프롬프트 엔지니어링이 필요 없는 거 아닌가’ 하는 생각 때문이었어요. 요즘 AI 모델이 너무 좋아져서 대충 질문을 해도 답을 잘해주니까요. 말씀을 듣다 보니 여전히 프롬프트 엔지니어링이 중요하구나, 하는 생각이 드는데요. 앞으로는 어떨까요? AI 모델이 훨씬 더 좋아질 미래에도 프롬프트 엔지니어링의 가치는 유효할까요?

네 앞으로도 굉장히 중요할 겁니다. 저는 MCP( Model Context Protocol)를 써보면서 프롬프트 엔지니어링이 또 중요해지겠구나, 생각했어요. 컴퓨터가 처리해야 할 일을 코드로 한다면 컴퓨터가 실수할 일이 없겠지만 이제는 다 자연어로 한단 말이죠. 자연어로 할 때는 얼마나 미세하게 설계하는지, 얼마나 명확하게 말하는지가 그 도구의 쓸모와 무쓸모를 구분 짓게 됩니다.

지금의 프롬프트 엔지니어링은 자연어와 코드의 중간의 상황이라고 볼 수 있어요. 앞으로는 다 자연어로 될텐데 그게 유토피아가 될지 디스토피아가 될지는 저희가 하기 나름인 것 같아요.

네, 말씀 잘 들었습니다. 시간내 주셔서 감사합니다.

감사합니다.

글. 바이라인네트워크
<심재석 기자>shimsky@byline.network