프롬프트 엔지니어링과 CS146s_1

소위 바이브 코딩 (첫 수업에서 이 수업은 바이브 코딩을 가르치는 것이 아니라고 못박기는 한다) 을 가르친다는 CS146s 수업이 스탠포드에서 개설되었다는 소식을 듣고 궁금해서 찾아보았다.

AI가 점점 발전하고 코딩, 연구까지 대체하는 듯한 모습을 보며 점점 내 위치를 고민하게 된다. 그래서 이번 겨울방학 동안 이 수업을 한번 듣고 과제도 수행해볼 것이다. 이 강의가 그 답을 줄 수 있을지는 모르겠지만, 우선 AI한테 무지성으로 맡겨버리는 일은 줄어들지 않을까 기대하고 있다. ㅎ

1주차 Reading Materials에 있던 유튜브가 있었는데, 나는 영어가 많이 부족해서 ㅎㅎ 스크립트를 따고, Gemini로 번역하는 식으로 내용을 익혔다. 실제 AI 개발자는 프롬프트 엔지니어링을 어떻게 사용하고 있는지, LLM을 보다 잘 이용하기 위해서는 어떻게 해야 하는지 알 수 있었다. 꽤나 유익한 내용이었다.

인상 깊었던, 또 ‘오 이건 쓸만하겠다’ 싶었던 내용들을 공유한다.

1. 제 초기 프롬프트로 제가 하는 첫 번째 일 중 하나는, 프롬프트를 주고 나서 이렇게 말하는 것입니다. “이 지침을 따르지 마. 그냥 이 지침에서 불분명한 부분이나 모호한 점, 이해되지 않는 부분이 무엇인지 말해줘.” 항상 완벽하진 않지만, 시도해 볼 만한 가치가 있는 방법입니다.

   그리고 모델이 실수를 했을 때 사람들이 자주 하지 않는 일 중 하나가 모델에게 직접 물어보는 것입니다. 모델에게 “네가 틀렸어. 왜 틀린 것 같은지 생각해 봐. 그리고 다음번에는 틀리지 않도록 내 지침을 어떻게 수정하면 좋을지 써줄래?”라고 말하는 거죠. 그러면 많은 경우 모델이 제대로 잡아냅니다. “아, 네. 이 부분이 불분명했네요. 지침을 이렇게 고치면 좋겠습니다”라고 답하고, 그걸 적용하면 제대로 작동합니다.

   
   

2. “계속 갈아 넣다 보면 언젠가 완벽한 프롬프트가 나올 거야”라는 생각에 갇힌 사람들을 많이 봐요. 물론 프롬프트를 연마하면서 배우는 게 있으니 나쁜 건 아니지만, 그 끝을 알 수 없는 미지의 세계라는 게 무서운 점이죠.

   완벽한 프롬프트가 있다고 가정했을 때, 어떤 작업이 프롬프트만으로 가능한지 아닌지를 판단하는 여러분만의 휴리스틱(판단 기준)이 있나요?

   저는 보통 모델이 어느 정도 감을 잡고 있는지를 봐요. 프롬프트로도 해결 안 될 것 같은 것들은 조금 시도해 보면 금방 티가 나거든요. 갈피를 못 잡거나 근처에도 못 가고 있다는 게 명확해지면 더 이상 매달리지 않아요.

   맞아요. 모델에게 어떻게 생각하고 있는지, 왜 그렇게 생각하는지 물어봄으로써 “제대로 생각하고 있는가? 최소한 정답 근처(zip code)에는 와 있는가?”를 파악할 수 있어요. 그렇게 하면 조금씩 정답에 가까워지고 있다는 느낌을 받죠. 반면, 어떤 작업은 아무리 노력해도 사고 과정에 전혀 진전이 없어요.

   
   

3. 사람들은 일종의 ‘게으름의 지름길’을 택하는 경향이 있는 것 같아요. 저도 게으르고, 많은 사람이 그렇죠. 많은 사람이 프롬프팅을 할 때 자신이 정확히 무엇을 하고 있는지 아직 잘 모르는 것 같아요. 텍스트 박스를 보면 구글 검색창이라고 생각하고 키워드만 집어넣죠.

   
   

4. 모델에게 ‘탈출구(Outs)‘를 주는 것도 중요해요. 이건 사람들이 자주 잊어버리는 건데, 예외적인 케이스(Edge case)가 발생했을 때 모델이 어떻게 행동해야 할지 정해줘야 합니다. 말하지 않으면 모델은 단기 계약직 사원처럼 어떻게든 지시를 따르려고 무리수를 두거든요. 대신 이렇게 말해보세요. “만약 정말 이상한 게 들어오거나 어떻게 해야 할지 확신이 안 서면, 그냥 <unsure> 태그를 출력해.” 그러면 나중에 그 태그가 달린 결과물만 모아서 검토하면 됩니다.

   
   

5. 프롬프트를 많이 읽고, 모델의 출력을 많이 읽으세요. 저는 사내에서 누군가 쓴 좋은 프롬프트를 발견하면 아주 자세히 읽어봅니다. 이게 왜 작동하는지 분석해 보고 직접 테스트도 해보죠. 모델과 정말 대화를 많이 해보는 실험 정신이 중요합니다. 특히 내가 하는 일의 맥락을 전혀 모르는 사람에게요. (…)

   모델이 할 수 있는 능력의 ‘경계’를 탐색할 때 실력이 가장 많이 늡니다. (…) “불가능할 것 같은 어려운 작업”을 시도하고, 작업을 분해해서 에이전트처럼 단계별로 수행하게 만들어보세요. 그 경계에서 씨름하다 보면 모델이 어떻게 작동하는지 정말 많은 걸 배우게 됩니다. 설령 실패하더라도 그 과정에서 얻는 배움이 엄청나요. 가장 어려운 문제를 찾아 직접 부딪혀보세요.
   
   

6. 프롬프트 엔지니어링의 미래에 대해 한 가지 재미있는 전환점이 있을 것 같아요. 만약 모델이 특정 작업에서 인간 수준 혹은 그 이상의 능력을 갖게 된다면 어떨까요? 모델이 저보다 그 작업의 배경지식을 더 많이 알고 있다면요? 그때는 프롬프팅이 일종의 ‘상담’이 될 거예요. 제가 원하는 걸 설명하면 모델이 오히려 저에게 질문을 던지는 거죠.

   
   

7. 사실 제가 철학을 공부하며 배운 글쓰기 방식이 프롬프팅에 정말 큰 도움이 됐어요. 철학 논문은 ‘교육받은 일반인(Educated layperson)‘이 읽었을 때 모든 내용을 이해할 수 있도록 써야 하거든요. 상대가 아주 똑똑하지만 이 주제에 대해서는 아무것도 모른다고 가정하고, 극도로 복잡한 아이디어를 명확하게 설명해내는 훈련이죠. 프롬프팅도 똑같아요. (…) 결국 내 뇌 속에 있는 것을 분석해서 이해할 수 있는 형태로 외부화(Externalize)하는 것, 그것이 프롬프팅의 핵심입니다.