# CPE Elements 101 : Prologue

그동안 생각만 하다 이제 좀 이야기해봐도 좋을 주제를 써봅니다.

 2년 전, 중순부터 프롬프트 엔지니어가 되고 싶어 준비하면서, 그리고 한 해 동안 실무에서 프롬프트 엔지니어링에 몸을 담으면서 '프롬프트 엔지니어링이란 무엇인가'를 고민했습니다. 그동안 사람들에게 프롬프트 엔지니어링을 어떤 정의로 생각하는지 들어보았을 때 여러가지 정의와 연관 컨텐츠를 볼 수 있었습니다. 

 정리해보면 몇 가지 카테고리로 나눌 수 있죠. 대개는 :

- ChatGPT와 같은 LLM Portal에 쓰이는 프롬프트 템플릿을 만드는 행위

- LLM에 사용되는 프롬프트에 대한 텍스트의 배치 및 템플릿의 디자인

- LLM API에 들어가는 프롬프트에 대한 정확성있는 제작 방법

- 그리고... 아직 정의되지 않은 무언가

![Image](https://upload.cafenono.com/image/slashpagePost/20250109/141311_fEN9bifJ7c8ZcRX43X?q=80&s=1280x180&t=outside&f=webp)

 하지만 '전문적인' 프롬프트 엔지니어링은 결이 많이 다릅니다. 위에 나와 있는 어느 하나만을 의미하지도 않고, 변화하는 환경에서는 위의 정의로는 아직도 부족하기도 하지요. 아직까지 위에 있는 피라미드에 무엇이 있는지는 실제로 해본 사람을 제외하고는 아는 사람이 거의 없지 않을까 합니다.

그렇다면 그냥 LLM에 들어갈 프롬프트만 쓰면 될 걸, 왜 무엇이 다른 걸까요? 아래의 요소들을 톺아보셔야 합니다.

- 회사에서 프롬프트 엔지니어로 프롬프트 엔지니어링을 하는 것은, 대개 '특정한 기능을 LLM을 사용하여 구현한다'는 의미입니다. 프롬프트의 모든 요구사항을 아는 나의 요구가 아니라, 생각을 공유하지 않는 타자의 요구를 반영해야 합니다. 잘 구현하기 위해서는, 요구사항에 대한 밀도있는 분석이 필요합니다.
- 

- 당연하게도, Robustness가 가장 중요합니다. 기능을 만족하면서, 어떤 입력값에도 흔들리지 않는 강건함이 중요합니다. 신뢰성 있고 강건한 프롬프트는 곧 LLM으로 구현한 기능의 강건성이기도 합니다. 이는 SW 품질과 직결됩니다. "생성된 것이 곧 콘텐츠이니까요." 이처럼 강건성이 중요하다면 비강건성에 대한 측정과 관측도 중요해집니다.
- 

- 로직이 명확한 코드와 달리, 프롬프트는 불명확성 안에서 최선의 결과를 구현해야 합니다. 프롬프트는 복잡계에 가깝고, 특정한 프롬프트가 작동할 때, 나오는 아웃풋이 어떤 연산을 거쳐서 나왔는지는 확실하게 알 수 없습니다. 하지만 신뢰성 있는 프롬프트 개발을 하고자 한다면 이런 혼란과 복잡계를 관측하고, 분석하고 대처할 방법들도 필요합니다.
- 

- 이를 위한 수단은 대부분 프롬프트 외적인 것입니다. 전통적인 SW에서 활용하던 방법론들과, 프롬프트의 특성, 그리고 관련 지식을 엮어서 방법을 고안하고 적용해야 합니다.
- 

- 그리고 끊임없이, 정말 끊임없이 변화하는 지형 위에서 이루어집니다. 새로운 패치와 업데이트, 새로운 변경사항, 아직 알지 못하는 엣지 케이스에 대한 발견과 수정, 기존 기능의 롤백, 세부적인 퀄리티, 버그, VoC의 컴플레인, 고객층이 바라는 것, 그리고 트렌드의 변화, 여기서 다 적어놓지 못하는 외부 요인들이 아주 끊임없이 생물처럼 개발 지형을 변화시킬 것입니다. 프롬프트도 그에 맞춰서 변화해야 합니다.
- 

이런 요인들이 생각 외로 프롬프트 엔지니어링에서 중요한 역할을 하고 있다는 걸 경험하고 느꼈습니다. 프롬프트 엔지니어링이 그저 '프롬프트 글적기'가 아니라 정말 엔지니어링의 한 분야로 인정받고자 한다면, 문제를 해결하면서 더불어 이렇게 필요한 키워드를 정립하고 언급하는 것도 중요한 것이라고 생각이 들었습니다. 경험은 명시적이어야 배우기 쉽고, 성문화 되면 공유가 가능하니깐요.

---

 그래서 그동안 이야기되지 않았던, 그리고 더 자세히 이야기해볼 만 한 프롬프트 엔지니어링에 대해서 중요하다고 여겨지는 요소들을 톺아보는 글을 적어보려고 합니다. 어떤 것은 익숙한 주제일 수도, 아닐 수도 있을 것입니다. 어떤 키워드는 손에 잡히는 분명한 구현체와 프로세스일 수 있지만, 손에 잡히지 않은 추상적인 개념과 방법론일 수도 있을 겁니다.

 하지만 지금에서야 기획하고 쓰면서 확신이 드는 것은, 오늘부터 이야기할 요소들을 다 아우른다면, 적어도 프롬프트 엔지니어링이 SW의 개발을 넘어 엔지니어링의 한 영역으로서 강고한 인정을 받을 수 있는 기초가 되지 않을까 싶습니다. 저도 이 글들을 실어 보내면서, 제가 실제로 겪은 경험들과 프롬프트, 이슈와 대응법을 최대한 많이 알려드리고자 합니다.

 개인적으로도 이 연작을 시작하면서 많은 도전이 됩니다. 생겨난 지 2년 된 직군의 1년 경력이 있는 사람으로 경험은 있지만, 저만의 경험이 정답은 아닐 것입니다. 제가 알지 못하는 환경과 특이한 개발 지형에서는 다른 방법론이 적용되어야 할 수 있을 것입니다. 어느 때는 시간이 지나 발전한 LLM으로 인해, 제가 이야기하는 것이 그저 지금의 포트란과 코볼과 같은 '과거에 그랬다더라'와 같은 콘텐츠가 될 수 있을 것입니다. 그렇지만 뭐 어떻습니까. 이렇게 계속 적어나가는 것은 의미 있는 일이고, 배움과 공유는 멈추지 말아야 합니다.

 그래서, CPE Elements 101을 시작합니다.

 그저 하나씩 잘 적어나가겠습니다.

---

---

---

글쓴이 주)

연구와 정리 및 제가 글을 떠올리고 적는 속도 대로 적고자 하기에 업로드 주기는 불규칙할 수 있습니다. 하지만 별 일이 없다면, 이 연작은 매주 월요일 아침 10시에 하나씩 올라갈 것입니다.

---

For the site tree, see the [root Markdown](https://slashpage.com/twojay-prompt-engineer.md).