Image generated by playground ai; Prompt - "software engineers learning new things in front of a monitor, but panicking and frustrated".

LLM의 등장 이후, NLP 소프트웨어 엔지니어들은 무엇을 할까요?

저는 운좋게 2022년 챗GPT가 출시되기 전부터 여러 LLM 프로젝트에 참여할 기회가 있었는데요. LLM을 여러 용도로 써보면서 느낀 점은, "NLP에 대해 배운 모든 것을 잊어버리고 다시 배울 때가 왔구나” 싶었습니다. (수년간 공부하고 연구해서 대학원까지 다녔는데도!)

몇몇 사람들은 모든 소프트웨어 엔지니어링이 결국 "프롬프트 엔지니어링"이 될거라고 우려합니다. 즉, 더 이상 코딩이 필요 없고 GPT에게 쓰는 영어 프롬포트만 잘 작성하기만 하면 된다는거죠.

정말로 모든 NLP 소프트웨어 엔지니어의 역할은 없어질까요? 지금부터라도 치킨집 창업을 고려해야 할까요..?

아뇨, 이제는 새로운 세계에 적응하고 LLM 엔지니어링에 대해 생각하기 시작해야 합니다!

이 포스트의 내용은 제 개인적인 의견이며 제 회사를 대변하지 않습니다. 공개되지 않은 정보를 공유하지 않습니다.

Google Bard와 함께 제 자신의 글을 번역 및 편집했습니다. (원문)

LLM API, NLP 판을 바꾸다

챗GPT의 출현은 NLP에 정말 큰 영향을 주었다는 건 누구도 부정할 수 없죠. 현재 최신 성능의 LLM (PaLM 또는 GPT 등)를 API를 통해 이용할 수 있게 되었습니다. 기본적인 코딩 기술만 있는 학생도 LLM을 통합하고 상당히 잘 작동하는 챗봇을 만들 수 있습니다.

예를 들어, 분류(Classification) 모델을 개발하려면 머신러닝 학습, 즉 파인튜닝(finetuning)의 과정이 필요했습니다. 그러나 이제는 누구나 이러한 전문 지식 없이 LLM 몇 가지 프롬프트에 예시를 시도해보면 꽤 나쁘지 않은 성능*의 모델을 만들 수 있습니다.

(“나쁘지 않은 성능*”은 전에 언급했듯이 몇 개 해보면 정말 완벽하게 작동하는 것처럼 보이는 것을 뜻합니다. 좀 더 철저한 평가를 해보면 부족한 경우가 많죠).

전에는 NLP 문제를 해결하려면 전문 지식이 필요했지만, 이제는 그렇지 않습니다. (이젠 너도나도 AI/NLP 전문가다!) 이로 인해 NLP 엔지니어링은 진입 장벽이 낮아져 특별하지 않은 분야가 되었고, NLP 엔지니어의 일자리가 위험에 처해 있다는 걱정이 들기도 합니다.

챗GPT가 처음 대중에게 공개되었을 때 저와 제 동료들은 우리 경력에 미칠 나비 효과를 미처 알지 못하고 그저 생각보다 높은 파급력에만 주목했었습니다.

떠오른 프롬프트 엔지니어링

프롬프트 엔지니어링은 LLM에 주는 인풋 텍스트를 작성하는 기술을 지칭하는 새로운 용어입니다. LLM은 입력 텍스트에 있는 지시 사항을 따르도록 학습되었기에, 사용자가 어떻게 프롬프트를 작성하냐에 따라 아웃풋 결과가 크게 바뀝니다.

LLM에 대한 프롬프트를 작성할 때 고려해야 할 점은, 어떤 예시를 포함할지, 어떤 포맷으로 나열할지, 어떻게 지시를 할지, 지시를 더 잘 따르도록 하기 위해 어떤 “트릭”을 써야할지 등 여러가지가 있는데요.

엄밀히 말하면, 프롬프트 엔지니어링에는 "엔지니어링”은 없습니다. 좀 더 입에 달라붙게 하기 위해 누군가가 잘 만든 용어죠. 그저 특정 LLM 모델에서 잘 작동하는 인풋 패턴을 파악해 지시 사항과 예시를 잘 쓰는 작업입니다. 따라서 엔지니어링보다는 프롬프트 라이팅(prompt writing)에 더 가깝습니다.

그렇기에 저는 "프롬프트 엔지니어"가 길게 남을 직업 타이틀이라고 생각하지 않습니다. 오히려 프롬프트 라이팅은 소프트웨어 엔지니어, PM, 관리자 등 회사의 모든 사람 (특별한 기술이 아니라 그저 글을 쓸 수 있는 모두)가 하는 일반적인 작업이 될 것이라고 봅니다. 이미 많은 사람들이 그렇게 하고 있는 것 같습니다.

다만 프롬프트를 작성할 때 많은 시행 착오를 거쳐야 합니다. LLM은 블랙박스와 같기 때문에 어떤 인풋에 왜 그렇게 행동하는지 이해하기 어렵습니다. LLM은 학습 데이터와 학습 방법에 따라 아웃풋이 결정되는데, 대부분의 경우 사용자는 이에 대해 알 수 없겠죠. 또한, LLM은 확률 모델이므로 동일한 입력에도 여러 번 넣을 시 다른 출력이 나올 수 있습니다. 만일 모델가 업데이트된다면 이전에 써놓은 프롬프트에 영향을 미칠 수 있기에, 프롬프트 역시 정기적으로 업데이트해야 할지도 모릅니다.

이처럼 LLM을 사용하는 사람은 이러한 불안정성(instability)을 염두에 두어야 합니다. 이전 포스트에서 <ChatGPT로 프로덕트를 만들기 전 고려할 사항은?>를 참고하시길 바랍니다.

LLM 엔지니어링이란?

프롬프트 엔지니어링이 엔지니어링이 아니라면 LLM 엔지니어링(LLM engineering)이란 무엇일까요?

지난 글에서 LLM 엔진 자체는 리소스와 노하우를 갖춘 소수의 회사에서만 처음부터 학습될 가능성이 높다고 했죠. 따라서 대부분의 엔지니어는 엔진 자체를 구축하는 데 관여할 필요가 없습니다.

LLM 엔진 구축 이외에 좀 더 폭넓은 영역의 다양한 작업이 필요할 것이라고 생각합니다.

아마 모든 것을 커버할 수는 없겠지만 제가 중요하다고 생각하는 영역에 대해 써보려고 합니다. 지난 글에 이어 다시 한번 핵심 포인트는 "LLM은 엔진이고, 다른 구성 요소가 필요하다”입니다.

테스팅, 평가, 리스크 분석

소프트웨어의 안정성은 여러 가지 테스트가 보장하죠. 유닛 테스트(Unit testing)와 통합 테스트(Integration testing)가 있기에 우리 엔지니어들은 밤에 편하게 잘 수 있습니다.

하지만 LLM은 기존의 테스팅 패러다임을 바꿀 것 같습니다. LLM의 랜덤하고 확률적인 특성은 테스팅을 훨씬 더 어렵게 만듭니다. LLM은 환각(hallucination)과 의도하지 않은 편향(unintended bias)과 같은 단점이 있는 것으로도 잘 알려져 있죠.

LLM 엔진을 사용하는 소프트웨어 시스템은 이 특성을 고려해야 합니다. “시스템이 의도한대로 작동하는지 어떻게 보장할 수 있을까?” 업데이트된 LLM이 이전 버전보다 더 잘 작동하는지 어떻게 알까?”

이러한 핵심 질문은 평가(Evaluation) 과정에서 해결해야 합니다. 이 과정의 엔지니어링은 이제 데이터 셋을 구축하는 것뿐만 아니라, 평가를 효율적으로 돌리기 위한 데이터 파이프라인과 시스템도 포함합니다. 평가를 하는데 너무 오래 걸리면 모델 업데이트 주기가 느려지거나, 제대로 된 평가 및 테스팅 없이 시스템을 배포하는 위험한 상황이 생길 수도 있습니다. 이처럼 LLM 시스템에서 평가 과정에 많은 엔지니어링 노력이 필요합니다.

평가 데이터 셋에는 실제 사용자가 입력할 만한 인풋 뿐만 아니라 안전성에 관련이 있거나 실패하면 큰일날 수 있는 경우 같은 하이 리스크 데이터를 포함해야 합니다. (그리고 가장 중요한 것은 평가 데이터 셋과 학습 데이터 셋이 겹치지 않아야 합니다.)

궁극적으로 이러한 평가 과정을 통해 나의 LLM 시스템의 리스크와 이득을 파악하려는데 있습니다. 아래와 같은 그래프를 그려볼 수 있으면 제일 좋겠습니다.

크라우드소싱 평가 (Human Evaluation)

많은 연구자들은 NLP 작업의 평가를 빠르게 진행하기 위해 자동 지표(automatic metric)를 개발해 왔습니다. 종종 분류(classification) 또는 회귀(regression) 데이터 셋에는 정답(gold label)이 함께 제공됩니다. 그러나 LLM 시스템을 평가는 항상 정답이 있지 않기에 꽤 어렵습니다.

마치 학생이 작성한 에세이 글을 평가하는 것과 비슷합니다. 에세이가 잘못될 수 있는 방법은 여러 가지가 있죠. 주제에서 벗어나다거나, 논리적이지 않다거나, 문법에 맞지 않다거나, 진실이 아닌 정보를 포함할 수도 있습니다. 그러나 이러한 기본적인 기준을 통과하고 나면, 글이 얼마나 잘 쓰였는지 절대적이고 평가하는 객관적인 숫자는 없습니다. 그렇기 때문에 채점자는 다른 학생들의 글과 비교하여 상대평가를 하고는 합니다. 한 글이 다른 글보다 더 나은지 말하는 것이 절대적인 숫자 점수를 매기는 것보다 약간 더 쉽습니다.

LLM도 비슷한 상대 방식으로 평가됩니다. 서로 비교하여 어느 것이 더 좋은 글을 썼는지 평가합니다.

이러한 평가 방식에 가장 어려운 점은 수많은 인간 크라우드워커(crowd workers), 즉, Human computation(HCOMP)이 필요하다는 점입니다. 이러한 Human Evaluation 프로젝트는 비쌀 뿐만 아니라 업체 관리, 품질 검사, 비용 분석과 같은 작업도 같이 따라옵니다.

어떤 사람들은 이러한 작업이 소프트웨어 엔지니어어의 일이 아니라 프로젝트 관리자의 일이라고 주장할지도 모르지만, 저는 소프트웨어 엔지니어도 이러한 프로세스를 이해해야 프로젝트 매니저와 협력할 수 있다고 봅니다. 또는 규모가 작은 회사에서 일한다면 엔지니어가 이러한 작업을 직접해야 하는 경우가 많죠.

또한 Human Evaluation의 결과를 해석하는 것 역시 간단하지 않습니다. Crowdworker의 판단은 꽤나 에러가 많을 수도 있거든요. 데이터 사이언스 역량이 있다면 이러한 결과를 분석하는 데 큰 도움이 됩니다.

리스크에 대처하기

LLM을 사용할 때는 개인 정보 유출, 보안, 안전성 등 다양한 리스크가 함께 옵니다. 특정 평가 데이터 셋 (ex. 안정성), 레드 티밍 등의 방법을 준비하여 이러한 리스크를 가늠하기 위한 전략이 필요합니다.

리스크가 파악되었다면 이를 줄이기 위한 전략도 개발해야 하죠. LLM 엔진 자체를 업데이트할 수도 있지만, 앞서 말했듯이 엔진을 바꾸는 것은 항상 가능한 것은 아닙니다. 그러한 경우에는 위험성이 있는 인풋과 아웃풋을 감지하고 별도로 처리하는 등의 방법 사용해야 할 수 있습니다 (예: 필터링).

LLM의 리스크를 관리하는 것은 단순한 엔지니어링 문제만이 아닙니다. 많은 사용자 경험(UX) 사고가 필요하다고 생각합니다. 사용자로부터 랜덤함과 리스크가 있는 시스템에 대한 신뢰를 어떻게 얻을지, 위험한 결과가 발생할 때 어떻게 피해를 최소화할 수 있는지, 어떻게 사용자를 화나게 하지 않고 위험한 케이스를 신고할 수 있게 할 것인지 등 여러 가지 문제가 산재해있습니다.

데이터 엔지니어링

LLM은 데이터 없이는 만들어질 수 없죠. Pretraining 단계에서 이미 어마어마한 양의 데이터가 학습에 사용되지만, LLM 엔진을 사용자 역시도 자체적으로 많은 양의 데이터를 관리해야 합니다.

특히 중요한 데이터는 평가 데이터 셋이고, 나중에 개선을 위한 데이터(예: fine-tuning 데이터)도 있을 수 있습니다. LLM 시스템은 또한 엄청난 로깅 데이터를 생성할 것입니다.

LLM 시스템을 개발 및 관리하려면 정말 많은 데이터가 생성되기에, 데이터 저장(storage), 버전 관리(version control), 분석 도구(analysis), 품질 관리(quality management), 로그 마이닝(log mining)과 같은 여러 중요 데이터 엔지니어링 과제가 파생됩니다.

소프트웨어 시스템 설계

주로 시니어 엔지니어들은 시스템 설계를 담당합니다. 이는 LLM 세계에서도 변하지 않을 것으로 보입니다만, 전통적인 소프트웨어 엔지니어링의 틀을 벗어나서 생각해야 하지 않을까 싶습니다.

• LLM 엔진을 기존 시스템에 어떻게 통합할까,
• 랜덤함을 가진 LLM 엔진을 중심으로 어떻게 안정적인 시스템을 구축할까,
• 데이터는 각 구성 요소 사이 어떻게 흐를 것인가,
• 랜덤함을 고려한 테스트는 어떻게 설계할 수 있을까

ML/NLP 소프트웨어 시스템 설계는 저 역시 더 많이 배우고 경험하고 싶네요!

문제를 정의하는 능력

마지막으로 저는 좋은 엔지니어는 문제를 해결할 뿐만 아니라, 새로운 문제를 찾고 정의할 수 있어야 한다고 생각합니다. 강력한 엔진이 발명되었지만 우리는 어디에 사용할 수 있을까요?

챗봇은 LLM의 가장 직관적이고 많은 사람들이 개발하고 있는 응용 사례이지만, LLM은 그 이상으로 사용할 수 있지 않을까요? 예를 들어, 기존에 돌아가고 있는 NLP 시스템을 대체한다거나, 더 작은 모델을 학습하는 데 사용하는 합성 데이터를 생성할 수 있다거나, 아직 실험되지 않은 아이디어가 많을 것 같습니다. 기존의 모든 자동화 흐름을 리뷰해서 LLM 엔진을 사용하여 개선할 수 있는지 생각해볼 필요가 있습니다.

가장 흥미롭게 보고 있는 사례 중 하나는 LLM이 직접 어떠한 의사 결정을 내리고 어떠한 액션을 취할 수 있는 에이전트가 되는 방식인데요. 이러한 방법은 기존 소프트웨어에 있는 복잡한 제어 흐름(control flow)의 엔지니어링 비용을 크게 줄일 수 않을까 생각됩니다. Langchain과 같은 라이브러리를 사용하면 프로토타입을 쉽게 만들 수 있으므로 관심있으면 직접 사이드 프로젝트를 해보아도 재밌을 것 같습니다!

LLM의 포텐셜을 더 터뜨리려면 우리 엔지니어들이 틀을 깨고 다른 분야의 사람들과 대화하기 시작해야 하지 않을까요? 여기에는 PM, UX 디자이너 및 연구자, 프로그램 관리자, 비즈니스 개발자와 같은 다른 테크 롤뿐만 아니라 다른 분야의 사람들도 포함된다고 봅니다.

누구나 API를 통해 LLM에 액세스할 수 있는 세상이 되었기에, 단순히 기술 역량에 집중하는 방식(vertically)은 개인적인 좋은 시간 투자는 아닐꺼 같다는 느낌이 듭니다. 반면에 좀 더 수평적으로 생각하면 (horizontally) 더 많은 혁신과 기회를 얻을 수 있지 않을까요? 의료, 교육, 제조, 유통 등 다른 분야 역시 생산성 향상을 위해 LLM과 같은 기초 모델을 사용하고 싶어할 것 같습니다. 점점 더 다양한 분야에 LLM 엔진으로 풀 수 있는 문제를 정의할 수 있는 소프트웨어 엔지니어가 더 많이 필요할 것입니다.

두 개의 글을 통해 LLM 엔지니어링이라는 토픽에 대한 제 생각을 공유했습니다. NLP 엔지니어로 살기에는 무섭기도 신나기도 한 시간인 것 같습니다. 우리 모두 좀 더 새로 나오는 기술들을 배우고 실험해보는 것에 시간을 많이 쏟아야 할 것 같습니다. 저도 좀 더 이것저것 직접 실험할 수 있는 시간이 많았으면 좋겠네요!

피드백, 질문, 의견 공유는 언제든 댓글로 환영합니다!