CPE Elements 101

CPE Elements 101의 첫글은 '프롬프트'입니다. 프롬프트는 텍스트로 주어진 질문, 명령 또는 지시로, 우리가 의도하는 특정한 결과를 이끌어내기 위해 설계된 텍스트입니다. 이를 통해 LLM을 기반으로 명시적이거나 암시적인 의도에 맞추어 작업을 수행합니다. 프롬프트는 간단한 질문 형태일 수도 있고, 복잡한 시뮬레이션이나 무언가를 요구하는 상세한 지침일 수도 있습니다. 사실 여기서 프롬프트가 무엇이고 간단한 유래를 다루거나 할 수 있지만, 그에 대해서는 대강 건너뛰고 가고 싶네요. 그렇다고 아무것도 이야기하진 않을 수 없으니 간단하게 우리가 다룰 '프롬프트'라는 것의 특징을 알고 건너가는 게 좋을 것 같습니다. 여기서 다룰 특성들은 이후에 다루게 될 포인트들을 반영하기 때문입니다. 프롬프트는 본질적으로 텍스트이다. 프롬프트는 텍스트상에서 나타나는 표현과 형식이 있고, 이를 함의하는 의미와 방향성을 가지고 있다. 프롬프트는 개별 기능을 대표한다. 프롬프트가 가진 텍스트 크기가 클 수록, 프롬프트의 복잡성 또한 올라간다. 오늘은 이 중에서 프롬프트의 의도와 개선에 대해서 이야기해보고자 합니다. 숨어있는 의도 드러내기 프롬프트는 본질적으로 텍스트입니다. 프롬프트의 작동 원리와 결과는 종종 코드와 비슷한 구조를 가질 수 있습니다만, 어찌되었든 프롬프트는 줄글로 된 텍스트이고, 주된 기능을 구현할 때에도 이에 대한 여러 줄의 표현이나 설명, 지시와 형식이 복잡스레 들어갑니다. 이러한 표현들은 특정한 기능을 더 잘 동작시키기 위한 목표를 가지고 심혈을 기울여 배치됩니다. 그렇다면 이를 어떻게 하면 바로 시인성있게 파악할 수 있을까요? 시인성있게 파악할 수 있어야 무얼 하는 프롬프트인지 명확하게 파악할 수 있고, 전체 프로젝트에서 프롬프트 사이사이에 놓치는 부분이 없이 엔지니어링이 가능합니다. 그런 면에서 코드와 프롬프트는 얼핏 비슷해보이지만, 가장 두드러지는 차이는 바로 "의도의 명확성"을 어떤 수단으로 드러내는가에서 두드러집니다. 코드에는 주석이라는 개념이 있습니다. 프로그래밍에서는 주석을 남김으로, 코드와는 명확히 다른 방식의 표현으로 자연어로 된 화자의 의도를 직접적으로 남길 수 있습니다. 아래와 같은 예제로, 코드는 주석을 새김으로 동작에 관여하지 않지만, 명백한 의도를 설명할 수 있는 텍스트를 남길 수 있습니다.

그동안 생각만 하다 이제 좀 이야기해봐도 좋을 주제를 써봅니다. 2년 전, 중순부터 프롬프트 엔지니어가 되고 싶어 준비하면서, 그리고 한 해 동안 실무에서 프롬프트 엔지니어링에 몸을 담으면서 '프롬프트 엔지니어링이란 무엇인가'를 고민했습니다. 그동안 사람들에게 프롬프트 엔지니어링을 어떤 정의로 생각하는지 들어보았을 때 여러가지 정의와 연관 컨텐츠를 볼 수 있었습니다. 정리해보면 몇 가지 카테고리로 나눌 수 있죠. 대개는 : ChatGPT와 같은 LLM Portal에 쓰이는 프롬프트 템플릿을 만드는 행위 LLM에 사용되는 프롬프트에 대한 텍스트의 배치 및 템플릿의 디자인 LLM API에 들어가는 프롬프트에 대한 정확성있는 제작 방법 그리고... 아직 정의되지 않은 무언가 하지만 '전문적인' 프롬프트 엔지니어링은 결이 많이 다릅니다. 위에 나와 있는 어느 하나만을 의미하지도 않고, 변화하는 환경에서는 위의 정의로는 아직도 부족하기도 하지요. 아직까지 위에 있는 피라미드에 무엇이 있는지는 실제로 해본 사람을 제외하고는 아는 사람이 거의 없지 않을까 합니다. 그렇다면 그냥 LLM에 들어갈 프롬프트만 쓰면 될 걸, 왜 무엇이 다른 걸까요? 아래의 요소들을 톺아보셔야 합니다. 회사에서 프롬프트 엔지니어로 프롬프트 엔지니어링을 하는 것은, 대개 '특정한 기능을 LLM을 사용하여 구현한다'는 의미입니다. 프롬프트의 모든 요구사항을 아는 나의 요구가 아니라, 생각을 공유하지 않는 타자의 요구를 반영해야 합니다. 잘 구현하기 위해서는, 요구사항에 대한 밀도있는 분석이 필요합니다. 당연하게도, Robustness가 가장 중요합니다. 기능을 만족하면서, 어떤 입력값에도 흔들리지 않는 강건함이 중요합니다. 신뢰성 있고 강건한 프롬프트는 곧 LLM으로 구현한 기능의 강건성이기도 합니다. 이는 SW 품질과 직결됩니다. "생성된 것이 곧 콘텐츠이니까요." 이처럼 강건성이 중요하다면 비강건성에 대한 측정과 관측도 중요해집니다. 로직이 명확한 코드와 달리, 프롬프트는 불명확성 안에서 최선의 결과를 구현해야 합니다. 프롬프트는 복잡계에 가깝고, 특정한 프롬프트가 작동할 때, 나오는 아웃풋이 어떤 연산을 거쳐서 나왔는지는 확실하게 알 수 없습니다. 하지만 신뢰성 있는 프롬프트 개발을 하고자 한다면 이런 혼란과 복잡계를 관측하고, 분석하고 대처할 방법들도 필요합니다. 이를 위한 수단은 대부분 프롬프트 외적인 것입니다. 전통적인 SW에서 활용하던 방법론들과, 프롬프트의 특성, 그리고 관련 지식을 엮어서 방법을 고안하고 적용해야 합니다. 그리고 끊임없이, 정말 끊임없이 변화하는 지형 위에서 이루어집니다. 새로운 패치와 업데이트, 새로운 변경사항, 아직 알지 못하는 엣지 케이스에 대한 발견과 수정, 기존 기능의 롤백, 세부적인 퀄리티, 버그, VoC의 컴플레인, 고객층이 바라는 것, 그리고 트렌드의 변화, 여기서 다 적어놓지 못하는 외부 요인들이 아주 끊임없이 생물처럼 개발 지형을 변화시킬 것입니다. 프롬프트도 그에 맞춰서 변화해야 합니다. 이런 요인들이 생각 외로 프롬프트 엔지니어링에서 중요한 역할을 하고 있다는 걸 경험하고 느꼈습니다. 프롬프트 엔지니어링이 그저 '프롬프트 글적기'가 아니라 정말 엔지니어링의 한 분야로 인정받고자 한다면, 문제를 해결하면서 더불어 이렇게 필요한 키워드를 정립하고 언급하는 것도 중요한 것이라고 생각이 들었습니다. 경험은 명시적이어야 배우기 쉽고, 성문화 되면 공유가 가능하니깐요.