에이전틱 엔지니어링의 부상: 프롬프트 부채
평범한 영어로 프롬프트를 작성하는 것은 마법처럼 느껴집니다. 원하는 것을 입력하면 프로토타입이 나타나니까요. 하지만 장기적인 시스템 구축에 있어 이 마법은 함정이 됩니다.
여러분은 아마도 프롬프트 부채(prompt debt)를 쌓아가고 있을 것입니다.
프롬프트 부채는 정밀한 엔지니어링 대신 자연어를 사용하여 모델을 제어할 때 발생합니다. 이는 세 가지 거대한 문제를 야기합니다:
- 반복 작업이 느려집니다. 오류 하나를 고치기 위해 텍스트를 더 추가하지만, 그 텍스트가 다른 무언가를 망가뜨립니다. 곧 프롬프트는 반복되는 지시사항들로 엉망이 됩니다.
- 팀이 통제력을 잃습니다. 대문자 경고와 예외 케이스로 가득 찬 프롬프트는 동료가 읽거나 관리하기가 불가능합니다.
- 특정 모델에 종속됩니다. 한 모델에 맞춰 튜닝된 프롬프트는 더 새롭고 성능이 좋은 버전에서 실패하는 경우가 많습니다. 팀은 시스템이 망가질까 두려워 오래되고 비용이 많이 드는 모델에 머물게 됩니다.
이는 여러분이 가중치(weights)와 싸우고 있기 때문에 발생합니다. 모델이 지시를 거부하면, 여러분은 지시를 반복합니다. 반복되거나 강조된 모든 지시사항은 흉터 조직(scar tissue)과 같습니다. 이는 모델의 학습 내용이 여러분의 의도와 충돌하고 있음을 보여줍니다.
자연어는 엔지니어링을 하기에 너무 부정확합니다. 단어 선택의 작은 변화가 모델의 동작을 뒤집을 수 있습니다. 프롬프트 내의 관련 없는 사실조차 모델의 응답 방식을 바꿀 수 있습니다.
어떻게 해결해야 할까요?
프롬프트를 수동으로 작성하는 것을 멈추고, 측정 가능한 수치로 동작을 명시하기 시작해야 합니다.
- 프롬프트는 모델이 따르기를 바라는 문단입니다.
- 메트릭(metric)은 모델이 반드시 충족해야 하는 계약입니다.
엔지니어링의 미래는 "프롬프팅"에서 "프로그래밍"으로 이동하고 있습니다. DSPy나 GEPA와 같은 도구를 사용하면 목표와 메트릭을 정의할 수 있습니다. 그러면 시스템이 해당 목표를 달성하기 위한 최적의 프롬프트를 찾아냅니다.
이를 통해 프롬프팅은 컴파일된 아티팩트(compiled artifact)가 됩니다. 더 저렴한 새 모델이 등장해도 당황할 필요가 없습니다. 단순히 새 모델에 대해 메트릭을 실행하고 프롬프트를 다시 생성하면 됩니다.
엔지니어들이 어셈블리 언어에서 컴파일러로 넘어갔듯이, AI 엔지니어들도 문자열을 수동으로 튜닝하는 것에서 메트릭을 최적화하는 것으로 넘어가야 합니다.
마법의 단어로 모델을 달래는 일을 멈추십시오. 측정 가능한 사양(specifications)을 바탕으로 구축을 시작하십시오.
Optional learning community: https://t.me/GyaanSetuAi