나는 보통, 새로운 현상을 이해할 때 굳이 예전 세계의 비유를 끌어다 붙이는 습관을 좋아하지 않는다. 그럼에도 지금 딱 그 잘못을 저지르려 하니 조금만 양해해 주길 바란다. 왜 프롬프트 작성을 프롬프트 디자인 이라고 부르고, 웹 디자인에 비유해야 하는지 그 이유를 설명해 보겠다.

나는 프롬프트 작성을, 시간적 여유가 거의 없는 인간과의 커뮤니케이션으로 본다. LLM 특유의 기법들(가장 대표적으로 chain-of-thought 같은 것)은 물론 유용하지만, 성능을 끌어올리는 가장 좋은 방법 중 하나는 그냥 지극히 명확하고 고품질의 지시를 주는 것이라는 걸 깨달았다. 마치 실제 사람에게도 명확하고 간결한 설명이 이해를 돕는 것처럼 말이다.

명확한 커뮤니케이션으로서의 프롬프트 작성은 프롬프트 작성을 글쓰기와 비슷하게 들리게 만든다. 하지만 내가 실제로 하고 있는 프롬프트 작성의 상당 부분은 매개변수화되어 있다. 입력 변수들이 여러 개 있고, 그에 맞춰 프롬프트를 동적으로 조정해야 한다.

따라서, 동적 입력을 포함한 명확한 커뮤니케이션으로서의 프롬프트 작성이 가장 정확한 특징 묘사처럼 느껴진다.

그렇다면, 동적인 입력을 전제로 명확하게 소통하는 다른 분야는 무엇일까? 웹 디자인이다.

이제 유사점을 하나씩 나열해 보자. 프롬프트 작성과 웹 디자인은 둘 다:

1. 명확성이 필요하고, 커뮤니케이션이 1차적인 목표이며,

2. 글쓰기나 잡지 지면 구성과 달리, 동적인 콘텐츠에 대응해야 하고,

3. 서로 다른 크기에 맞게 콘텐츠를 조정해야 한다 — 웹 디자인에서는 화면 크기, 프롬프트 작성에서는 컨텍스트 윈도우 크기.

내가 프롬프트 작성과 웹 디자인을 둘 다 해 본 경험상, 두 영역에서의 개발자 선호도도 비슷하다는 점을 발견했다:

1. 실제 프롬프트를 눈으로 보는 것이 매우 중요하다. 마찬가지로 렌더링된 웹사이트를 직접 보는 것도 매우 중요하다. 나는 HTML과 CSS 렌더링 과정을 머릿속으로만 시뮬레이션해야 한다면 웹사이트를 디자인할 수 없다. 비슷하게, 모든 입력 변수가 채워진 상태에서 렌더링된 프롬프트를 보지 않고 좋은 프롬프트, 명확한 프롬프트를 작성하는 것은 정말 어렵다.

2. 예를 들어, "Hi ${username} ${message}"라는 프롬프트는 얼핏 보면 그럴듯해 보이지만, 실제로 렌더링해 보면 사용자 이름이 메시지와 뒤섞여 보인다는 것을 깨닫게 된다.

3. 컴포저블 컴포넌트는 프롬프트 작성과 웹 디자인 모두에서 유용하다.

4. 두 경우 모두, 선언형 방식이 명령형 방식보다 더 낫다. 모든 HTML 요소를 document.createElement 호출로 만드는 식의 웹사이트는 변경하기가 정말 어렵다. 마찬가지로, 긴 str += "..." 시퀀스로만 이뤄진 프롬프트를 읽고 수정하는 일도 금방 감당하기 어려워진다.

5. 둘 다, 때로는 “픽셀 단위의 완벽함(pixel perfection)”을 추구하고 싶을 때가 있다. 성능이 낮은 모델(GPT-3.5 이하)에 프롬프트를 줄 때는, 불필요한 줄바꿈이나 다른 종류의 어설픈 포매팅이 전혀 없도록 정말 신경 쓰고 싶고, 웹사이트를 디자인할 때도 픽셀 하나하나가 중요한 순간이 있다.

LLM 에이전트의 경우, 이 비유를 더 멀리까지 확장할 수도 있다. 에이전트 프롬프트 작성은, 에이전트들을 위해 대화형 웹사이트를 만드는 것처럼 볼 수 있다. 에이전트는 함수를 호출함으로써 “버튼을 클릭”하고, 함수 호출에 따라 프롬프트가 다시 렌더링되는데, 이는 웹사이트가 버튼 클릭에 반응해 다시 렌더링되는 것과 같다.

물론, 프롬프트 디자인과 웹 디자인 사이에는 차이점도 있다:

1. 프롬프트 작성은 오직 텍스트만을 다룬다(적어도 지금은!).

2. 캐싱 방식이 다르다. 특히 에이전트의 경우, 프롬프트의 뒷부분만 바꾸어 다시 렌더링 비용을 줄이도록 해야 한다. 웹에서도(웹사이트도 캐시 최적화가 필요하다) 비슷한 비유를 억지로 가져올 수는 있겠지만, 근본적으로는 꽤 다른 종류의 과제라고 생각한다.

그럼에도, 이런 유사점들 덕분에 나는 프롬프트 작성을 프롬프트 디자인이라고 부르고, 프롬프트 엔지니어링이라고 부르지 말아야 한다는 쪽으로 확신이 섰다. 프롬프트를 쓰는 행위는 정말로 웹사이트를 디자인하는 느낌이고, 그렇다면 이름도 그에 맞게 붙여야 한다.

이 프롬프트 디자인 관점 덕분에 나는 React와 비슷한 JSX 기반 프롬프트 디자인 라이브러리인 Priompt를 만들게 되었다.

#Priompt v0.1: 프롬프트 디자인 라이브러리를 향한 첫 시도

Priompt는 현대 웹 디자인 원칙에서 영감을 받아 만든 프롬프트 디자인 라이브러리에 대한 첫 시도입니다. 우리는 Cursor 내부에서 이를 사용하고 있으며, 꽤 마음에 들어 합니다.

모든 추상화가 완전히 정확하다고는 생각하지 않지만, 적어도 JSX가 문자열 템플릿보다 프롬프트를 작성하기에 훨씬 더 편리한 방식이라는 점에는 확신이 있습니다. 프롬프트의 일부를 간단히 주석 처리했다가 되돌릴 수 있다는 아주 단순한 기능만으로도, 반복적인 개선 사이클이 훨씬 빨라집니다.

Priompt에는 (매우 급하게 만든) 프리뷰 웹사이트도 함께 제공되어, 실제 데이터를 기반으로 프롬프트를 미리 볼 수 있습니다. 애플리케이션을 개발할 때, 각 요청마다 컴포넌트로 들어오는 직렬화된 props를 로그로 남길 수 있습니다. 그런 다음 예상치 못한 동작을 발견하면, Priompt 프리뷰로 이동해 정확히 어떤 프롬프트가 생성되었는지 확인하고, 소스 코드를 수정한 뒤 실제 요청과 동일한 props로 프롬프트가 어떻게 업데이트되는지 볼 수 있습니다. 우리는 이것이 프롬프트를 반복적으로 개선하는 작업을 훨씬 쉽게 만들어 준다는 것을 발견했습니다.

사용해 보신다면, 꼭 의견을 알려 주세요! 비슷한 방향의 더 많은 아이디어를 보게 되어도 좋고, 아니면 제가 완전히 틀렸고 프롬프트 디자인이 바보 같은 짓이라는 말을 들어도 좋습니다 :).

#주의사항

모델은 매우 빠르게 변하고, 그에 따라 프롬프트 기법도 함께 변해야 합니다. 이런 점을 감안할 때, prompt design이라는 표현에는 몇 가지 짚고 넘어갈 점이 있다고 생각합니다:

1. 픽셀 단위까지 똑같이 맞춘 정밀한 디자인은 GPT-4에서는 그다지 중요하지 않고, GPT-4.5 이상 모델에서는 아예 의미가 없어질 가능성이 큽니다.

2. 최근의 장문 컨텍스트 모델 트렌드를 그대로 연장해서 생각해 보면, 컨텍스트 윈도우 제약은 사라질 수도 있습니다. 다만 여기에 대해서는 저는 확신이 없습니다.

3. OpenAI는 개발자가 프롬프트를 세밀하게 제어할 수 있는 권한을 점점 줄이는 방향으로 가는 것처럼 보입니다. 어쩌면 1년 후에는 더 이상 프롬프트라는 개념 자체가 없고, API 호출 시 단순히 원시 입력값과 지시만 전달하게 될 수도 있습니다. 이런 통제권 축소 흐름은 채팅(chat) 형식에서 시작됐고, 최근 발표된 function calling에서도 이어지고 있습니다.

4. 캐싱이 프롬프트 작성에서 가장 중요한 요소 중 하나일 수도 있고, 그런 경우 프롬프트 작업은 디자인이라기보다는 점점 엔지니어링에 가까운 일처럼 들리기 시작합니다.

5. 어쩌면 prompt design은 너무 저수준의 문제라, 더 고수준의 프레임워크나 컴파일러(예: langchain)에 맡기는 편이 나을지도 모릅니다. 이 말이 맞을 수도 있지만, LLM이 워낙 빠르게 변하기 때문에, 개인적으로 저는 가능한 한 모델의 원시 인터페이스에 최대한 가까운 쪽에 머무르는 것을 선호합니다.

#마지막으로 꼭 적어야 할 한마디

...왜냐하면 여러분과 함께 일하고 싶기 때문입니다: Cursor에서는 AI를 중심에 둔 코드 에디터 Cursor를 만들고 있습니다. 프롬프트 디자인, 코딩을 위한 LLM, 혹은 아름다운 제품 만들기에 설레신다면 arvid@cursor.com으로 이메일을 보내 주세요. 저희는 샌프란시스코에 있는 5명으로 이루어진 팀이고, 모든 동료들이 뛰어난 분들이며, 앞으로의 코딩 환경을 함께 만들어 갈 뛰어난 개발자와 디자이너를 몇 분 더 모시고 싶습니다.