프롬프트 히스토리

ChatGPT Task가 릴리즈 되어 적용되었다는 소식을 듣고, 평소에 생각만 하던 기능을 1시간 만에 구현해서 사용해보았습니다. 매일 아침마다 프롬프트 엔지니어답게 프롬프트 엔지니어링 데일리 과제를 생성해서 받아보는 사이트를 구현하려다, 마침 Task를 활용하면 GPT 기반으로 잘 구현할 수 있겠다 싶어서 활용하기로 결정했습니다. ChatGPT Task 란? ChatGPT Task (GPT 작업)은 현재 ChatGPT에서 베타로 공개된 기능입니다. 이 기능을 활용하면 단일로, 혹은 정기적으로 GPT에 수행할 작업을 정의해서 수행하게 만들 수 있습니다. 특정 시간에 1회에 한하여 수행하게 할 수도, 매일 아침 9시와 같은 정기적인 시간에 수행하게 할 수도 있습니다. Task를 선택한다고 하여도, 채팅 인터페이스는 크게 변화하지 않습니다. 이전에 활용하던 채팅 인터페이스 그대로 활용할 수 있습니다. 여기서 프롬프트를 아래의 정보를 담아서 전달해주면, 임의로 테스크를 생성하여 일정에 추가하게 됩니다. 무엇을 할 것인지 작업의 구체적인 내용 언제 수행할 것인지 - 주기와 시간 (e.g. 매일 아침 9시 30분에) 아래와 같이 ChatGPT Task와 상호작용 할 수 있습니다. 우측에 보시는 것 처럼, 프롬프트를 통해 수행할 작업을 직접적으로 명령할 수 있습니다. Task는 여기에서 발견한 정보를 토대로 작업을 생성하고 수행하게 됩니다. 이 프롬프트와 같이 시간을 명확히 주고, [제목]과 [내용]을 명확하게 프롬프팅해서 제공하면 GPT Task는 이를 거의 그대로 가져가서 작업을 생성하게 됩니다. 정상적으로 작업이 생성되게 되었다면, 우측과 같이 생성된 작업에 대한 정보와 응답을 받을 수 있습니다. 생성된 작업의 옵션 버튼을 클릭하면 작업을 편집하거나 일시정지하거나, 수행하고 있는 모든 작업을 볼 수 있습니다.

어젯밤 The Game Awards 2024가 열렸습니다. 일을 하며 옆에 게임쇼를 틀고 있던 제가 한순간 멍하게 볼 수 밖에 없는 장면이 있었는데요. 제가 가장 좋아하는 게임인 '문명 시리즈'의 최신작인 '문명 7'의 테마곡이 발표된 것이었어요. 그것도 라이브로. 이번 문명 신작의 테마곡도 Christopher Tin이 참여했습니다. 이 양반은 정말 특이한 음악가 중 하나인데요. 정말 생전에 들어보지도 못한 외국어에서 비롯된 다양한 문학적 결과물들을 차용하고, 여기에 영감을 받아서 곡을 만듭니다. 스와힐리어의 주기도문을 따와서 곡을 만든 'Baba yetu'는 이제 너무 유명한 곡이 되었죠. 그 말고도 성경과 루바이야트, 인디언 기우제의 기도문과, 몽골의 고대 문헌, 레오나르도 다 빈치와 존 F 케네디의 연설문까지 종횡무진하면서 다양한 언어로 곡을 씁니다. 그리고 엘범을 관통하는 하나의 코드로 그 노래들을 묶어내죠. 특히 'Calling All Dawns'와 'Drop that Contained the Sea'는 제가 정말 좋아하는 엘범입니다. 좋아하는 음악가 자랑을 했으니... 이제 발표된 곡을 유튜브에서 감상하면서 발견한 점에 주목해봅시다. 발표한 곡의 가사가 모두 고대 언어를 사용 : 고대 그리스어, 고대 영어, 키체 마야어, 산스크리트어 발표된 곡의 가사의 모든 부분이 특정한 서사시와 작품을 출처로 함 : 일리아드, 베오울프, 포폴 부흐, 라마나야 소수언어도 있으며 오래된 언어이기에, DeepL과 같은 번역기로는 번역이 불가능하거나 정확도면에서 어려움. 영문 번역이 있지만, 영어 화자의 정서를 바로 느끼기 어려움 그렇다면 이걸 GPT에게 번역을 맡겨보면 어떨까요? 번역과 작사를 함께하기 인간 번역사의 입장에서, 번역과 작사는 함께 나란히 서기 너무 어렵습니다. 저도 학부 때 번역을 했지만, 연습했던 수업과 자료들 중에서는 문학작품 번역이 가장 까다로웠습니다. 정서를 만족해야하면서도, 운율이 있고 가사가 있다면 음운과 음절을 신경쓰면서 번역어를 고려해야 하죠. 랩과 같은 특정한 모음이나, 라자즈나 까사드와 같은 구조 자체가 정해진 정형시, 하이쿠와 같이 자연을 매개로 하는 시어가 필수적이라면 그 조건은 더더욱 까다로워집니다. 이 모든 조건을 만족하고도 도착어 화자에게 어색하면 버려지는 번역이 되지요. 이제 이걸 GPT o1에게 한 번 맡겨봅시다. 다행히 Christopher Tin의 공식 유튜브 영상에서 노래 가사를 영문으로 번역한 것을 병기한 텍스트가 있었습니다.

이 포스트에서 올린 프롬프트는 가장 초안 버전의 프롬프트입니다. 사용하실 때에는 각각의 프로젝트에 맞추어서 알맞게 업데이트해서 사용하시길 바랍니다. 이전 프로젝트에서 PPT 슬라이드 생성과 발표자 노트를 자동화시켜 보았습니다. 그 이후 각 커리큘럼마다 복습 문제를 만들어야 했는데, 이 또한 자동화를 시켜보기로 합시다. 테스크 : 문제 생성 각 PPT의 복습과 진도 확인을 위해 복습 문제를 생성할 것 복습문제의 범위는 PPT 20 여 개에서 전체를 커버할 것 반드시 그 내용은 '언급되거나 배운 내용에 한할 것' 복습문제의 수량은 100개 이상 문제의 형태는 사지선다 하나의 유형으로 통일 작업 시간은 10시간, 인력은 1명 사실 이번 문제는 그냥 너무 쉽습니다 (...). 일반적으로 프롬프트만 짜면 LLM이 잘해주는 문제고, 그냥 찍어내면 되니깐요. 그런데 정말 쉬울까요? 항상 우리는 '그게 끝일까?' 라는 질문은 해봐야 합니다. 아무리 쉬운 테스크도 질문을 거듭하여 안정적이면서 좋은, 그러면서도 만족스러운 결과로 발전시키는 것은 쉽지만은 않지요. 이번 문제 생성 자동화도 그렇습니다. 문제 생성만 후다닥 해봅시다 일단 문제 생성만 빠르게 해봅시다. 이전 포스트에서 보시다시피, 키워드 하나에서 발표자 스크립트와 PPT 내용까지 확장해 보았습니다. 일단 우리에게는 PPT 내용과 스크립트가 있으니깐 이를 먼저 이용하는 쪽으로 가봅시다.

이번에 강의 컨텐츠 작성/감수 업무를 하면서 생각하고 있던 강의 PPT, Script 자동화를 구현해 보았습니다. 기존에 손수 대본과 피피티를 만들고, 검수하려고 계획되었던 업무를, 생성형 AI를 이용해서 구현하는 쪽으로 바꾸었습니다. 이렇게 생각한 이유가 몇 가지 있었는데 다음과 같았습니다. 7일의 시간 동안 3-4 명의 인원으로 60개 ppt의 700여 슬라이드와 슬라이드 각각의 대본을 손수 작업해야하는 (정말 말도 안되는) 작업량. 전문적 내용을 담는 것이 아니라, 특정 대상층에 맞는 컨텐츠의 배치를 고려해야 했음. 즉, 전체 테스크에서 산출해야 하는 컨텐츠의 정보 수준이 항상 동일해야 했음. 클라이언트가 요구하는, 컨텐츠 정보의 수준이 깊지 않았음. 입출력 정의 전체 작업의 과정은 초안 레벨의 PPT와 대본을 만들고, 이를 도메인 전문가가 검토하는 식으로 정했습니다. 0to1 작업은 LLM을 이용해서 빠르게 진행하고, 이후 검수 작업에서 퀄리티를 늘려가면서 결과물을 만들어내는 것으로 잡았습니다. 그러면 강의 하나를 PPT로 만들기 위해서는 어떻게 생성형 AI를 적용시킬 수 있을까요? 일단 실행 인터페이스는 간단하게 다음과 같이 잡았습니다. 아주 간단한 데이터에서 시작해봅시다. 1. 강의의 대주제가 될 키워드 1개 : "딥러닝", "머신러닝" 등. 2. 청중의 주된 특성을 적은 txt 파일 하나 그 다음 우리가 결과로 나올 때에 산출하는 데이터는 다음과 같습니다. 1. 강의의 PPT 초안 2. 강의 슬라이드 별 대본 그러면 이제 좀 그림이 아래와 같이 정리되겠죠. 우리는 이제 아래에서 어떤 로직을 채워넣을 지 고민하면 됩니다.

이 프로젝트는 문화체육관광부와 한국문화예술위원회가 지원한 "2024년 메타버스 예술활동 지원사업"의 일환으로 재직한 회사인 DNSoft 와 서울대학교 HCID랩, 우박 스튜디오가 공동으로 진행한 프로젝트입니다. 개발과 관련되어 업로드된 내용에 대해서는 모두 업로드 전에 사전 검토를 받은 컨텐츠임을 명시합니다. 들어가며 회사 내에서 올해 맡은 프로젝트 중에 하나에 대한 후기를 써보고자 합니다. 전체 개발과정에서 프롬프트 엔지니어링 파트를 맡았고, 검수와 피드백에 대한 대응을 꾸준히 진행해왔고 하는 중이기도 합니다. 그러고 11월 공개시연을 앞두고 있습니다. 개인적으로는 유니티에서 어떤 식으로 llm API 연동을 할 수 있는지 궁금증을 해소할 수 있었고, llm → Image Gen AI를 이용한 파이프라인을 다시금 한 번 짜본 프로젝트였습니다. 개요 용량 조절을 위해 배속이 과하게 적용되었습니다. 프로젝트의 요구사항과 플로우는 주어진 상황이었고, 기획된 컨텐츠에 맞추어 구현만 하면 되는 과정이었습니다. 어플리케이션에서 요구하는 챗봇의 주된 대화 요구사항은 다음과 같았습니다. 꿈에 대해서 대화를 나누고, 이에 맞는 이미지 생성. 생성된 꿈 이미지 중 선택을 한 뒤, 이를 이용해 더 깊은 감정에 대한 대화. 이끌어낸 대화를 바탕으로 반영하여 선택한 꿈 이미지 리랜더링. 실제 삶에서 꿈에 대해 연상되는 것이나 사건을 물어보고, 반추할 수 있도록 대화를 이끔 → 별도의 연상, 삶 이미지 생성 마지막에 꿈의 내용을 반영한 랜드스케이프 배경 이미지 생성 후 이미지와 대화 저장 LLM 모델은 전반적으로 gpt-4o를 사용할 것. Image Gen AI는 DALL-e 3.0 사용. 랜드스케이프 배경에 대해서는 Blockade API 사용. 플랫폼은 VR. 따라서 유니티를 이용한 클라이언트 개발이 요구됨. 복잡해보이지만 곰곰히 생각해보면 아주 간단한 플로우였습니다.

퇴사가 어느 정도 확정되어서, 후기를 조금 빨리 쓴다. 후기는 큰 이벤트가 있을 때마다 써야한다는 생각이 있는 편이다. 감정이나 생각과, 배움이 생생할 때 적어놓는 것이 낫겠다 싶었다. 첫 회사이고, 나에게는 프롬프트 엔지니어링을 실무레벨에서 경험해 볼 수 있었던 회사이다. 이번에 회사를 나오기로 결정하면서, 짧은 9개월 동안에 해왔던 일을 정리해보았다. 부끄러운 일도 있고, 모자란 내용도 있다. 스스로에 대한 자랑도 있을 것이다. 하지만 그 내용이 어떠하든, 글로써 정리하는 것이 가장 중요하다. 어떻게 오게 되었나? 처음에 이 곳에 오게 될 때는, 그렇게 큰 동기가 없었다. 프롬프트 엔지니어라는 직무가 있다는 걸 알고, 작년에 백엔드 개발자에서 AI로 넘어왔다가, 프롬프트 엔지니어 직무로 희망직무를 변경하게 되었다. 신생 직군이다보니, 정말 공고가 없었다. 12월부터 1월까지 쭉 공고를 보다가, 몇 군데에 원서를 넣었다. 그 때 생각으로는 "빠르게 시작해야 하니, 처음 붙여주는 곳으로 가자"는 쪽이었다. 다행히도, 정말 감사하게도 회사에서 면접을 보고, 대표님이 하시고 싶었던 프로젝트에 설득되었다. 지금도 하고 있는 프로젝트인데... 결과적으로는 중간에 매듭짓지 못하고 나오게 되었다. 하지만 해당 프로젝트의 주제로 혼자서, 그리고 팀과 함께 PoC만 3번이나 완주했기에, 얻은 게 아주 없지는 않았다. 뭐, 나야, 다음 달에 고향에 내려가서 밭가는 정도로 나락을 안 가게 되었으니 더 좋았다. 상황이 너무 맞아 떨어져서 1월에 입사를 하게 되었다. 무엇을 했었나? 프롬프트 엔지니어링의 모든 파트를 담당했다. 회사에서 진행하는 신규 프로젝트와, 외주, 자체 서비스에서 LLM과 프롬프트가 개입되는 거의 모든 문제를 다루었다. 처음 제작한 신규 프로젝트는 1인으로 진행해서 혼자서 프론트/백엔드를 개발하고, 프롬프트 기반으로 Agent를 구현하여 LLM 로직을 넣었다. 다행히도 좋은 사람들이 들어오고 팀이 커져서 부담이 많이 줄었지만, 그 줄었던 시간은 프롬프트 엔지니어링을 사내에서 더 투여하는 데 사용되어졌다. 처음에는 프롬프트 제작과, 이에 대한 테스팅만이 업무로 있는 상황이었다. 점차 프롬프트를 작성하는 데에 있어서 기획 PM 분과 계속 소통하면서 일을 진행했었고, 이에 대한 평가 피드백이나, 제작에서 프롬프트만으로 힘들었던 부분에 대해 나누고 기능 업데이트 시 기획에 반영되었다. 스스로 개발은 할 줄 알았기에, 프롬프트 엔지니어링 테스팅에 필요한 로직이나 파이프라인은 즉석에서 프로젝트의 요구사항에 맞게 작성하면서 테스팅을 진행했다. 프롬프트 제작과 테스팅에서도 단순히 프롬프트 제작 이외에, streamlit과 같은 도구를 통해 기획에서 제시한 로직에 따라 테스트 어플리케이션을 만들고 서빙했다. 이를 통해 서비스하는 환경과 별도의 테스팅이 가능하게 했고, 이전에 전임자가 진행한 ChatGPT 포털에서 테스트를 진행하던 방식과는 달리 실제 API를 활용한 기능의 출력에 맞게 테스팅을 진행할 수 있었다. 무엇을 잘했다고 생각하나? 회사는 LLM 관련 직무를 처음 채용한 상황이었다. 내 앞에 기획자가 프롬프트 엔지니어링을 한 명 하고 있었지만, 그 분이 하는 방식이 지금 와서 되돌아보면 효율적인 방식이지는 않았고, 성능에 대한 평가도 어림짐작에 가까웠다. 처음 들어와서, 그런 체계를 세워보고 싶었고, 어느 정도는 이해를 공유하는 데에는 도달한 것 같다.