# 늦은 피드백 : prompt engineer가 되고 싶은 이에게 ### 시작하기 전에 : 사실 이 글의 주인은 따로 있다. 이제부터 이 글의 원래 주인을 A라고 할 것이다. 얼마 전 우리 회사는 3개월 계약직인 프롬프트 엔지니어를 채용했었다. 이 글의 원래 주인인 A는 그 때 지원자 중 한 분 이었다. 처음 프롬프트 엔지니어링을 시작하는 A는 정성스럽게 프롬프트 전략을 정리해온 포트폴리오까지 만들어서 가져왔다. 아쉽게 떨어지고 난 뒤, A는 나에게 개인적으로 피드백을 요청했다. 하지만, 회사 일에 쫓기던 나는 제 때 피드백을 드리지 못했다. 바빴던 일을 2~3주 동안 쳐내고 돌아와서 보니 온데간데 없었던 A였다. 피드백을 드리고 싶었지만, 연락이 닿지 않아 드리지 못했다. 그렇게 썼던 수신인 잃은 피드백의 초안은 잠들었어야 했다. 시간이 지나 다시 꺼내어보니 처음 프롬프트 엔지니어를 시작하는 분들에게 어떻게 시작해야 할 지 알려주는 좋은 글감이 될 수 있어 보이기에 편지글 형식으로 각색했다. --- 지원자 A님에게. 면접의 결과를 늦게나마 전달해드려서 정말 죄송하다는 말씀을 드립니다. 피드백은 신속성이 생명인데, 그러지 못하여서 가치가 떨어질지도 모른다고 생각이 들었어요. 하지만 제가 기억하고 있는 A님의 말과 도전을 되짚고 생각해보고 최대한 떠올려 이 글에 실어 보냅니다. 보내어주신 포트폴리오의 노력과, 실습과제에서의 떨림을 기억합니다. 면접에서 제가 난해하고 고민이 필요한, 어쩌면 짖궂은 질문을 던져도 조리있게 노력하여 말씀하시던 모습도 기억납니다. 그 기억을 되짚어서, 질문을 주신 내용인 피드백과 어떻게 앞으로 하시면 좋을지, 그렇게 해서 어떻게 좋은 엔지니어로 시작할 수 있는지 알려드리고 싶습니다. . . . ## 서슴없이 시도하기 --- 면접 때 실습과제에서 무엇을 해보아야 할 지 망설여졌던 모습을 먼저 되짚어보고 싶습니다. 누구에게나 나의 결과물을 작성하고 공개한다는 것은 쉽지 않은 일입니다. 그것이 평가받는 자리라면 더욱 그렇고, 내가 작성한 결과물이 빠른 피드백을 받는 상황이라면 더더욱 그렇습니다. 하지만, 프롬프트 엔지니어라면, 으레 익숙한 상황이고, 또한 그렇게 익숙해져야 하는 상황입니다. 면접에서 실습과제를 작성하게 했던 것은 "**프롬프트를 익숙하게, 혹은 익숙하지 못하더라도 과감하게 작성하고 시도할 수 있는 사람인지**"를 알아보고 싶었던 저의 생각의 반영이었습니다. GPT와 클로드와, 세상에 수많은 LLM이 나왔지만, 우리는 아직까지 그 LLM이 어떻게 단어를 예측하는지 원리는 알아도 결과를 완전히 예상할 수 없습니다. 완전한 블랙박스 안에서 프롬프트 엔지니어는 항상 LLM을 마주하면서도, 스스로 작성한 프롬프트로 어떤 결과물이 나올지 예측은 하여도 예지할 수는 없습니다. 그렇기에 프롬프트 엔지니어에게 가장 처음으로 요구되는 덕목은 생각한 바 그대로 시도할 수 있는 **용기와 무모함**입니다. 처음 LLM을 다루어보고, 처음 프롬프트 엔지니어링을 다루어본다면, 무작정 넣어보고 어떻게 답변이 나오는지 관찰해보세요. 다른 사람의 질문과 프롬프트도 넣어보다가, '이렇게 하면 되지 않을까?' 라는 지점이 보이면 과감하게 고쳐서 시도해보세요. 시도는 경험을 낳고, 경험이 쌓이면 감각이 됩니다. 그래서 처음 배울 때에, 아무리 기상천외한 것이라도 일단은 넣어보고 결과를 보는 것이 낫습니다. 그러다보면 새로운 것을 발견하게 될 지를, 누가 알까요? ## 프롬프트 전략을 배우기 --- 한참 시도를 하고난 다음이면, 크게 두 가지가 생각날 겁니다. "다른 사람의 프롬프트를 보니깐 이렇게 하더라" 혹은 "생각한 것 만큼 안나오는데, 좋은 방법 없을까" 이 때 즈음에 많은 이야기들이 지나가게 됩니다. "예제를 넣으면 좋아진다더라" 혹은 "'단계적으로 생각해!'라고 넣으면 좋아진다더라"와 같은 이야기들 말입니다. 혹자는 테크닉이라고 하기도 하고, 누구는 'GPT 혼내는 법'이라고도 하지만, 우리는 이걸 **프롬프트 전략**이라고 부릅니다. 정리하고 오신 포트폴리오에서도 이런 전략들이 잘 정리가 되어 있었습니다. 처음 배울 때에는 이런 전략들이 도움이 됩니다. 하나 둘 알아두면 써 먹을 곳도 많고, 저도 기억 속에서 잊고 있다가 번뜩 떠올라 문제를 해결한 적도 한 두 번이 아니지요. 그만큼 알아두면 유용합니다. 개인적으로 추천드리는 소스는 Nextra에서 운영하는 프롬프트 엔지니어링 가이드입니다. 하지만, 여기 나와있는 프롬프트 전략에서 보여주는 프롬프트 텍스트에만 집중해서는 안됩니다. 어떤 맥락에서 사용되고, 어떤 의도로 사용했는지 알아보는 것이 중요합니다. 영어가 낯설지 않다면, 함께 있는 논문도 읽어보시길 바랍니다. 그렇다면 여러가지 프롬프트 전략이 왜 세상에 나왔고, 어떤 의도와 맥락에서 쓰이는지 더 잘 알 수 있습니다. [프롬프트 엔지니어링 가이드 – Nextra](https://www.promptingguide.ai/kr) 여기까지 오게 되었다면, 살면서도 LLM을 가까이 하는 단계가 되었을 것이라고 생각합니다. 이제 알게 되면 써먹어야 한다고, 내가 궁금해 하는 질문에도 프롬프트 전략을 적용해서 LLM에게 요청해보는 건 어떨까요? 실제로 써먹어보고, 내가 사용한 전략이 사용하지 않았을 때와 비교해서 어떤 차이가 있는지 검토해보세요. ## 프롬프트 전략을 잊기 --- "이렇게 전략들을 다 배우게 되면 프롬프트 엔지니어가 될 수 있나요?" 라고 묻는다면, 저는 이 시점에서는 과감하게 프롬프트 전략을 잊으라고 말씀드리고 싶습니다. 물론 까먹으라고 노력하고 학습을 게을리 하라는 이야기가 아닙니다. **프롬프트 전략이 곧 프롬프트 엔지니어링의 전부이자 본질이 아니라는** 이야기가 하고 싶은 것입니다. 프롬프트 엔지니어링의 본질은 **LLM에게 어떤 질의를 던졌을 때, 결과물이 잘 나올 수 있는 구조를 만드는 일**입니다. 우리가 작성하는 프롬프트는 도구로서는 전부지만, 과정으로서는 부분입니다. 프롬프트 엔지니어라면, 프롬프트를 작성할 때 오히려 자신의 결과물에서 한 걸음 물러서서 스스로에게 되물어보아야 합니다. "내가 의도한 바 대로 결과물이 잘 나오는가?" "내가 담은 텍스트가 프롬프트와 전체 과정에서 어떤 의미를 가지나?" "오히려, 내가 발전시키고자 하는 프롬프트의 방향이 결과물을 저해하고 있지 않나?" 우리는 무언가를 만들 때 몰입해서 만들기 때문에 되려 이런 큰 그림을 껴안는 질문에서 멀어질 수 있습니다. 프롬프트 전략을 신나게 붙혀가면서 프롬프트를 만들고 있는 상황이라면 더더욱 그렇습니다. 작성되는 프롬프트가 길어지면 길어질 수록 대단한 것을 할 수 있을 것 같고, 무언가 완성이 되어가는 것처럼 보입니다. 어쩌면 신나지만, 핵심인 질문을 망각한 위험한 상황이기도 합니다. 프롬프트 전략을 잊으라는 말은 그런 의미입니다. 프롬프트 전략에만 치중하다가, 가장 중요한 생성의 결과물인 '컨텐츠'를 놓는 일은 없어야 한다는 뜻입니다. 이 단계를 실제로 잘 다루는 사람들의 공통점은 프롬프트를 **"결과물에 맞게"** 잘 정의합니다. 이를 연습하기 위해서는 특정한 결과물이나 도움을 제공하는, 아주 정확도가 높은 프롬프트를 작성해보는 것이 좋습니다. 더욱이 개인적으로는 이 단계에서 간단한 '챗봇'을 만들어보는 것이 도움이 되었습니다. GPTs 와 같은 도구들이 처음 시작하는 데에 큰 도움이 될 것입니다. ## 자신이 서 있는 바닥을 알기 --- 이제 여기까지 오게 되었다면, 호기심의 초점은 프롬프트가 아니라 프롬프트가 돌아가는 LLM에 맞춰지게 될 것입니다. 여기서부터 LLM이 어떤 물건인지 알아보고, 가능하다면 원리까지 알아보세요. 우리는 항상 LLM을 자연어로 다룹니다. 하지만 그 원리를 알고나면, LLM은 우리가 만든 자연어를 일련의 숫자로 바꾸고, 그것을 연산하여 특징들을 추출한 뒤, 우리가 입력한 프롬프트 이후에 올 응답을 확률에 기반해 연산하는 생성형 모델임을 알 수 있습니다. 복잡한 수학 공식을 알 수 있다면 'Attention is all you need'와 같은, 초기 원리가 담긴 논문을 뜯어보아도 좋습니다. 다만 그런 상황이 모두에게 적용되지 않음을 알고 있습니다. 그렇다고 해도 어떻게 작동하는지는 대략적으로라도 알고 있으면 좋습니다. CoT와 같은 프롬프트 전략이 어떤 원리로 작동하는지와 같은 앎들이 이를 기반으로 합니다. 다행히 세상은 넓고, 알 수 있는 소스들은 많습니다. 아래와 같은 영상이 그 예입니다. 찾아보고, 파헤쳐보고, 이해해보시길 바랍니다. ## 더 깊고, 더 넓게 --- 여기까지 오게 된다면, 이미 훌륭한 주니어 프롬프트 엔지니어라고 할 수 있습니다. 프롬프트를 만들라고 하면 곧 잘 할테고, 무엇을 선택하고 버릴지도 결정할 수 있는 단계입니다. 모델의 원리도 어느 정도는 알고, 그 원리를 반영한 프롬프트 전략을 선택하거나 스스로 만들어 낼 수도 있습니다. 그렇다고, 여기서 끝은 아닙니다. 명색의 엔지니어만큼 더 배워야 할 것들이 남아있습니다. 이 시점에서 배워야 하는 것은 크게 두 가지로 나뉩니다. 첫 번째는, 기술적인 영역입니다. LLM과 그 원리에 조금 더 관심이 있다면, 데이터를 이용해 파인튜닝과 같은 방법을 시도하거나, 외부의 데이터를 검색해서 찾아오는 RAG를 적용하고 싶어할 수도 있습니다. 개발을 알지 못했던 분은 파이썬을 이용한 프로그래밍에 관심이 생길 수도 있습니다. 어쩌면 Agent와 같은 한 발 더 나아간 기술에 관심이 생길 수도 있습니다. 이런 기술들을 익히면, 내가 구현할 수 있는 서비스의 폭이 넓어집니다. 두 번째는, 도메인의 영역입니다. 세상은 넓고, 아직도 우리의 도움을 필요로 하는 곳이 있습니다. 우리가 미처 알지도 못하는 분야에서는 LLM으로 효과적으로 문제를 해결할 수 있는 분야들이 이미 존재하고, 아직 발견되지 못하고 기다리고 있을 수도 있습니다. 이 분야들의 문제와 마주하면서, 어떤 분야를 잘 다듬어보고 꿰뚫어볼 수 있는 지식과 시각을 길러보세요. 이런 시각을 익히면, 내가 구현할 수 있는 컨텐츠의 깊이가 깊어집니다. 물론 프롬프트 엔지니어링에 대해서도 만족하지 않고 역량을 기르는 것도 필요합니다. 모델은 주기적으로 업데이트 되며, 발전하고, 이 분야의 지형은 달마다 날마다 바뀌고 있으니, 항상 시각을 열어놓고 있어야 합니다. 작성하는 프롬프트의 더 완벽한 퀄리티를 위해 기획과 설계, 테스팅에 대해서도 알아보고 자신의 프로세스에 적용하는 것 또한 필요합니다. . . . "면접을 잘 보았는지에 대한 피드백과 함께, 처음 프롬프트 엔지니어링을 하는데 어떻게 하면 되는지 알려달라"는 질문에 시간을 내어 글을 적어보았습니다. 만족스러운 피드백이었는지 모르겠습니다. 저는 이렇게 걸어왔지만, A님에게는 제 길이 정답은 아닐 수도 있겠지요. 그러나 다른 이의 경험을 가져와서 자신의 돌로 쌓는다면, 그보다 더 할 나위 없겠습니다. 9월 어느 밤에 적는 글을 이만 줄이며, 처음 시작하는 이에게 행운이 있기를 바라봅니다. For the site tree, see the [root Markdown](https://slashpage.com/twojay-prompt-engineer.md).