From Prompt Engineering to Programmatic Prompting: Toward a Software Engineering Discipline for Large Language Models

초보자용 해설

요즘 많은 서비스가 인공지능 모델을 직접 다루지만, 정작 프롬프트는 메모장이나 채팅창에서 즉흥적으로 작성되는 경우가 많습니다. 이 논문은 'AI와 대화하며 좋은 답을 끌어내는 기술'과 '소프트웨어 시스템 안에 프롬프트를 설계하고 관리하는 공학'을 구분해야 한다고 주장합니다. 전자는 프롬프트 엔지니어링, 후자는 프로그래매틱 프롬프팅이라고 부릅니다. 프롬프트를 코드처럼 버전 관리하고 테스트하지 않으면, 서비스가 깨지거나 예측할 수 없는 오류가 쌓이는 '프롬프트 부채'가 생긴다고 경고합니다. 초보 개발자는 이 논문을 통해 '프롬프트 하나를 잘 쓰는 것'이 끝이 아니라, 이를 안정적으로 운영하는 시스템을 짜야 한다는 관점을 얻을 수 있습니다.

실무자 관점 요약

이 논문은 거대 언어 모델(LLM)이 실험적 도구에서 운영 소프트웨어의 핵심 구성 요소로 자리 잡은 배경을 짚으며, 기존의 '프롬프트 엔지니어링' 담론이 상호작용 기법(HCI)에 머무르고 있다고 비판합니다. 저자는 프롬프트 엔지니어링을 인간과 모델 간의 상호작용 기술로 보고, 프로그래매틱 프롬프팅을 소프트웨어 시스템과 언어 모델 사이의 행동 인터페이스를 다루는 공학 분야로 정의합니다. 즉, 프롬프트를 단순한 문자열이 아니라 버전 관리, 구성, 테스트, 유지보수가 필요한 일급 소프트웨어 아티팩트로 다뤄야 한다는 것입니다. 논문의 세 가지 기여는 프로그래매틱 프롬프팅 정의, 프롬프트 엔지니어링·프롬프트 튜닝·파인튜닝·일반 LLM 애플리케이션 개발과의 체계적 구분, 그리고 '프롬프트 부채' 개념 도입입니다. 특히 프롬프트 부채를 코드에서 직접 측정 가능한 자기 고백 부채와 사고로만 드러나는 침묵 부채로 나누어 경제적 원인을 분석한 점은 인상적입니다. 장점은 개념적 명확성입니다. 팀 내부에서 '프롬프트 수정'을 어떤 맥락에서 이야기하는지 구분할 수 있게 해줍니다. 반면 한계도 명확합니다. 공개된 코드가 없고, 구체적인 구현 프레임워크나 벤치마크가 없어 '어떻게 시작해야 하는지'에 대한 실무적 가이드는 부족합니다. 또한 기존의 프롬프트 관리, CI/CD 파이프라인 관행을 새로운 패러다임처럼 과대 포장할 위험이 있습니다. 실무 적용을 고려한다면, 프롬프트 템플릿을 저장소에 두고 변경 이력을 추적하며, 출력 품질에 대한 회귀 테스트를 자동화하는 인프라를 구축하는 것이 우선입니다. 이 논문은 툴을 만들기 전 가져야 할 사고 모델을 제공한다는 점에서 가치가 있습니다.

왜 지금 봐야 하나요?

LLM 기능을 실제 서비스에 올린 개발자라면 '잘 쓴 프롬프트 하나'만으로는 충분하지 않다는 경험을 해봤을 것입니다. 이 논문은 프롬프트를 코드처럼 관리해야 하는 이유를 개념적으로 정리해 줍니다. AI 제품을 안정적으로 운영하고 싶은 개발자와 팀이 읽기에 적합합니다.

직접 구현해볼 아이디어

프롬프트 변경 이력 및 출력 회귀 테스트 대시보드

서비스 아이디어로 바꾸면

B2B AI 제품 팀을 위한 프롬프트 배포 파이프라인과 출력 모니터링 SaaS: 서비스 팀이 프롬프트 변경으로 인한 장애를 추적하고 롤백할 수 있게 한다.