프롬프트는 실재하지 않는다

기업이 사용자에게 일을 대신해 주는 AI를 제공하기보다, 사용자가 가져온 AI가 접속할 인터페이스를 제공하는 미래를 바람. 기업의 도구를 쓰는 AI를 내게 주는 대신, 내 AI가 쓸 도구를 제공해 주면 좋겠음.
그러면 내 AI가 필요한 맥락과 설정, 선호를 모두 가져갈 수 있음. 수많은 AI를 오가며 내가 원하는 것과 일하는 방식을 매번 처음부터 설명하고 싶지는 않음.
이 방식은 글에서 다루는 문제도 피해 갈 수 있게 해 줌. 기업은 일관된 도구만 제공하면 되고, 사용자의 온갖 프롬프트나 AI의 이상 동작까지 해결할 필요는 없어짐.

더 나은 인터넷은 각자가 LLM으로 맞춤형 Chromium 같은 브라우저를 쓰고, 특히 전자상거래를 비롯한 웹사이트 90% 이상의 프런트엔드가 개인 LLM의 설정에 맞춰 생성되는 형태임.
기업은 더 이상 프런트엔드를 배포하지 않고, 대부분의 사용자가 무시할 테마 적용 컴포넌트 정도만 제공하게 될 것임. 페이지는 여러 출처에서 내가 관심 있는 내용을 모아 합성한 화면이 되고, 원하는 UI/UX는 개인 LLM이 만들어 줌. 모든 것이 API가 되는 셈임. 소비자에게 이롭더라도 기업에는 저항할 유인이 있으므로, 데이터 접근을 강제하는 규제가 필요할 가능성이 큼. 이미 규제가 많은 온라인 결제의 허용 요건에 이를 넣는 것이 비교적 쉬운 방법임. 전자상거래에 가까운 서비스를 운영하려면 소비자의 AI가 공개 API/MCP 엔드포인트만으로 기존 프런트엔드를 재구성할 만큼 충분한 접근 권한을 제공하도록 하는 것임.
이런 제도적 개입이 이뤄지면 개인정보, 페르소나, 계정 생성 같은 구현 과제는 상대적으로 해결하기 쉬워짐. 가상 신용카드는 이미 여러 판매자를 상대할 때 정보를 보호하고 위험을 줄이는 데 유용함. 개인 에이전트가 판매자마다 고유한 카드를 뒤에서 생성하면 되는데, 사용자가 직접 신경 쓸 이유가 있을까? 경쟁사의 돈 되는 나쁜 설계를 베낀 UI에 갇히지 않고, 모든 UI/UX가 실질적으로 내 것이 된다면 인터넷이 훨씬 나아질 것임.

화상회의 서비스끼리도 상호운용성이 없고, 원하는 화상회의 앱을 가져다 쓸 수도 없는데 AI는 왜 다를까? 통신사가 제공하지 않은 전화기를 전화망에 연결할 수 있게 만드는 데도 정부 규제가 필요했음. 누구의 도구든 연결할 수 있는 단순한 통로나 인터페이스만 제공하면 기업은 사용자와 사용 방식을 통제할 수 없게 됨.

이것이 기본적으로 MCP 서버의 동기라고 봄. 다만 앱 UI 안에 에이전트를 넣기로 한 기업 관계자들과 이야기해 보면, 지금 형태가 계속되리라고는 생각하지 않음. AI와 에이전트가 인터페이스의 주요 요소가 되겠지만, 현재의 앱마다 붙이는 Clippy는 에이전트를 전제로 설계하지 않은 앱과 AI 중심 제품이 되고 싶다는 욕구를 억지로 연결한 과도기적 형태에 가까움. 그런 앱은 사람에게도 제대로 설계되지 않은 경우가 많음.
지금까지 잘 맞아떨어진 분야는 분석, 대시보드, 손쉬운 데이터 조회용 소프트웨어처럼 원래부터 이런 UI에 적합한 앱이었음. 에이전트가 작성한 쿼리로 행동 근거를 확인할 수 있고, 화면이 수시로 바뀌고 맞춤화되는 것이 자연스러우며, 특정 데이터를 조회하는 탐색 자체가 많은 사용자에게 어려운 일이기 때문임. 이런 환경에서는 에이전트의 가치가 크고 행동도 이해하기 쉬움.
반면 탐색 메뉴에서 누르면 될 링크를 대신 보내 주거나, 더 나쁘게는 사용자를 낯선 페이지로 강제 이동시켜 현재 위치와 이동 경로를 알 수 없게 만드는 에이전트는 오래가지 못할 것 같음.

인터페이스를 문서화하고 AI 없이도 사용 가능하게 하며, 원하면 직접 소프트웨어를 작성할 수 있게 하는 편이 더 유용할 것 같음. AI를 쓰고 싶은 사람은 그대로 쓰되, 나머지 사람에게까지 강제할 필요는 없음.

LG에 외부 영상 입력을 자유롭게 연결하는 TV를 만들어 달라고 요구하는 것과 비슷함. 화면을 장악해서 벌 수 있는 돈이 그렇게 많은데, 기업 입장에서는 경제적으로 맞지 않는 선택임.

GEPA로 프롬프트를 최적화할 때 도구나 스킬을 각각 따로 다루는지 궁금함. 대규모 에이전트 시스템의 시스템 프롬프트는 어떻게 최적화하는지?
평가하려는 항목들이 겹치는 조합마다 여러 차례 최적화하겠지만, 시스템 프롬프트 때문에 모든 사례가 서로 의존하게 될 것 같음.
예전에는 시스템 프롬프트에서 브랜드 말투 같은 주관적 기준을 추출해 LLM 평가자에게 주고 개별 실행 기록을 평가했음. 하지만 이제는 그런 기준을 프롬프트에 넣는 방식 자체를 넘어서고 싶음.

고객에게 예측 가능하고 결정론적으로 동작하는 에이전트를 만들어 주고 싶지만, 이런 작업은 낭비가 많고 비싸며 재미도 없어 보임.
저자는 즐겁다니 다행이지만, 내게는 남들이 하니까 따라 하고 고객은 도움이 될 거라고 믿으며 돈을 주는 ‘원숭이·사다리·바나나’ 실험처럼 느껴짐. 이런 식으로 프롬프트 최적화를 반복하기 시작하면 고객은 분명 돈을 끊을 것임.
지금처럼 도구와 MCP가 많고 하나씩 추가할 때마다 동작이 퇴행하거나 크게 달라진다면, 먼저 도구를 통합하고 자동화를 늘린 뒤 프롬프트를 다시 봐야 할 것 같음. 아니면 자체 모델을 학습해야 할까?

RLHF가 도움이 될 수 있으며, 모델을 처음부터 학습할 필요는 없음.

직접 부딪힌 문제 중 하나는 테스트 묶음을 실행할 때마다 실제 비용이 발생한다는 것임. 익숙한 다른 테스트와는 다르게 느껴짐. 통계적으로 유의미한 성능 측정치를 얻을 만큼 충분히 테스트하는 것이 옳다는 건 알지만, 그 과정을 우리 회사가 버틸 수 있을지는 모르겠음.

테스트에서 temperature 등을 조정해 무작위성을 줄이고, 거의 항상 성공하거나 거의 항상 실패하도록 만들면 안 될까? 비용을 높이는 원인은 반복 횟수 아닌가?

LLM으로 대부분의 경우 신뢰할 만한 결과를 내는 운영 시스템을 만들면서 겪은 문제와 정확히 일치함. 광범위한 테스트가 필요하지만, 이해관계자들은 자기 제안이 실제 운영에서 어떻게 실패하는지 전혀 모름. 직접 몇 번 시도해 잘된 것만 볼 뿐, 드물지만 끝없이 이어지는 기괴한 결과는 보지 못하기 때문임. 그래서 “그게 뭐가 어렵다고? 그냥 이렇게 하면 되잖아”라고 하게 됨.
글에서 제안한 프롬프트 자동 생성까지는 시도하지 못했지만, 흥미로운 접근임.

프롬프트가 텍스트라는 이유로 의식 없는 시스템에 의도를 부여하고, 그 시스템에 본질적으로 의미가 없다는 사실을 놓친다는 대목에는 다르게 생각함. LLM은 유용한 구분을 수행하고 폭넓은 행동을 선택할 수 있음. 널리 쓰이는 이유는 실제로 유용하게 작동하기 때문이며, 이는 의미가 실용적으로 잘 작동해야 가능한 일임.
제 몫을 하는 유용한 것에 우리가 ‘본질’을 인정해 줄 필요는 없음. 이미 우리와 서로 얽히면서 지속될 기반을 갖추고 있음.

얼마나 효과적인지는 모르겠지만, 지난 몇 년간 본 대부분의 ‘프롬프트 엔지니어링’보다 훨씬 공학다운 접근으로 보임. 자기 작업을 과장하지 않고 간결하게 풀어낸 점도 좋음.

끝까지 최적화된 프롬프트의 실제 모습을 기다렸다가 나오지 않아 아쉬웠던 건 나뿐인가? 원본에 비해 얼마나 뒤틀리고 낯선 형태가 되는지 꼭 들여다보고 싶음.

글의 형식 때문에 읽기가 거의 불가능함. 10페이지 정도 읽다가 포기했음.

글이 아니라 발표 자료임.

모바일에서는 첫 이미지에서 글이 끝난 것처럼 보여서 뒤에 내용이 더 있는 줄 몰랐음. 이미지들은 다른 글로 연결되는 항목처럼 보였고, 첫 항목만 자기 자신을 가리키는 링크인 줄 알았음.