r/promptengineering•6개월 전•52•12
5,000단어짜리 시스템 프롬프트 작성이 소프트웨어 엔지니어링이 아니라는 점을 인정해야 한다.
We need to admit that writing a five thousand word system prompt is not software engineering.
핵심 요약
프롬프트 엔지니어링의 한계를 지적하며, 모델의 근본적인 아키텍처 변화가 필요하다고 주장하는 글.
- 프롬프트 한계 — 5,000단어에 달하는 프롬프트는 모델의 불안정성을 초래함.
- 아키텍처 변화 — 프롬프트 래퍼가 아닌 모델 자체의 자가 진화형 아키텍처가 필요함.
- 엔지니어링 논쟁 — 프롬프트 작성을 소프트웨어 엔지니어링으로 볼 수 있는지에 대한 회의적 시각.
이 서브레딧은 정말 기발한 프롬프트 구조를 만들어내지만, 래퍼 로직으로 달성할 수 있는 한계에 도달한 것 같음. 텍스트 파일을 세심하게 포맷팅해서 모델이 세 명의 서로 다른 자율적인 작업자처럼 행동하게 강제하는 건 본질적으로 깨지기 쉬움. 예상치 못한 API 오류가 발생하는 순간, 모델은 캐릭터를 잃고 당황함. 다음번 거대한 도약은 더 나은 프롬프트 프레임워크에서 오는 게 아니라, 베이스 레이어 아키텍처의 변화에서 올 것임. 최근 Minimax M2.7 모델의 기술적 세부 사항을 살펴봤는데, 그들은 말 그대로 자체 진화 주기를 실행해서 내부 라우팅에 Native Agent Teams를 내장했음. 모델은 텍스트 프롬프트가 지시해서가 아니라, 경계 분리를 본질적으로 이해하고 있음. 프롬프트 전문가로서, 여러분은 이런 자가 라우팅 아키텍처와 상호작용하는 방법을 탐구하고 있는지, 아니면 여전히 챗 모델을 소프트웨어 프로그램처럼 행동하게 가스라이팅하는 데만 집중하고 있는지 진심으로 궁금함.
