프롬프트 엔지니어링은 시스템 설계이지 사용자 기술이 아니다.

출처: Dev.to

프롬프트 엔지니어링이 오해받는 이유는 사람들이 이를 카피라이팅처럼 다루기 때문이다.
일반적인 시각은 단순하다.

• 사용자가 더 좋은 프롬프트를 작성한다.
• 모델이 더 좋은 답변을 제공한다.
• 따라서 필요한 기술은 “어떻게 물어볼까”를 배우는 것이다.

이 관점은 개인적인 AI 사용에는 유용할 수 있다. 하지만 기업 시스템에는 충분하지 않다.

운영 환경에서는 프롬프트 엔지니어링이 주로 영리한 문구에 관한 것이 아니다.
그것은 시스템 설계에 관한 것이다.
프롬프트는 더 깊은 아키텍처의 겉보이는 표면일 뿐이다.

모든 좋은 AI 결과물 뒤에는 숨겨진 설계 결정이 있다.

• 어떤 컨텍스트를 포함했는가
• 어떤 컨텍스트를 제외했는가
• 모델에 부여된 역할은 무엇인가
• 어떤 도구를 사용할 수 있었는가
• 어떤 메모리를 조회했는가
• 어떤 제약을 적용했는가
• 어떤 출력 형식이 요구됐는가
• 응답을 어떻게 평가했는가
• 응답 이후에 무슨 일이 일어났는가

이것이 바로 시스템 설계이며, 단순히 사용자의 기술만으로는 설명되지 않는다.

프롬프트는 시스템에 들어가는 하나의 입력일 뿐이다. 실제 AI 워크플로는 다음과 같은 요소들을 포함할 수 있다.

• 사용자 질의
• 시스템 지시문
• 검색된 문서
• 사용자 권한
• 도구 정의
• 대화 기록
• 메모리
• 구조화된 데이터
• 정책 제약
• 출력 스키마
• 평가 체크

사람들이 “프롬프트가 실패했다”라고 말할 때, 텍스트 자체를 탓하는 경우가 많다. 하지만 실패는 다른 곳에 있을 수도 있다.

• 검색이 잘못된 컨텍스트를 반환했을 수도 있다.
• 모델이 너무 많은 도구에 접근했을 수도 있다.
• 출력 스키마가 모호했을 수도 있다.
• 사용자가 부분적인 데이터만 있는 상황에서 결정을 요구했을 수도 있다.
• 지시문이 다른 지시문과 충돌했을 수도 있다.
• 평가 레이어가 없었을 수도 있다.

프롬프트는 전체 설계가 아니다. 그것은 조립 지점일 뿐이다.

올바른 컨텍스트가 제공된 보통 수준의 프롬프트가, 컨텍스트가 부족한 영리한 프롬프트보다 일반적으로 더 좋은 결과를 낸다. 이는 특히 비즈니스 워크플로에서 두드러진다.

• 고객 상황을 요약하도록 모델에 요청한다면, 올바른 고객 컨텍스트가 필요하다.
• 컴플라이언스 답변을 초안하도록 요청한다면, 올바른 정책 소스가 필요하다.
• 티켓을 우선순위화하도록 요청한다면, 심각도, 계정 가치, SLA, 담당자, 최근 이력 등이 필요하다.

프롬프트 문구도 중요하지만, 컨텍스트 선택이 더 중요하다. 시스템 설계자는 다음을 결정해야 한다.

• 어떤 데이터 소스를 허용할지
• 컨텍스트를 어떻게 검색할지
• 얼마나 많은 컨텍스트를 포함할지
• 어떤 컨텍스트가 너무 민감한지
• 어떤 컨텍스트가 오래됐는지
• 어떤 컨텍스트를 먼저 요약할지
• 어떤 컨텍스트에 인용이나 추적 가능성이 필요한지

이 때문에 프롬프트 엔지니어링은 아키텍처가 된다. 사용자가 매번 올바른 컨텍스트를 직접 붙여넣을 필요가 없어야 한다. 시스템이 이를 자동으로 조립할 수 있어야 한다.

좋은 AI 워크플로는 모델에게 무엇을 해야 하는지만 알려주는 것이 아니다. 무엇을 하지 말아야 하는지도 알려준다.

예시:

• 누락된 정보를 만들어내지 말 것
• 승인되지 않은 출처에서 답변하지 말 것
• 기밀 컨텍스트를 노출하지 말 것
• 법적 결론을 내리지 말 것
• 승인 없이 행동을 트리거하지 말 것
• 사용자가 접근할 수 없는 파일을 요약하지 말 것
• 오래된 정책 문서를 사용하지 말 것
• 요구된 형식 밖으로 응답하지 말 것

이것들은 글쓰기 팁이 아니라 시스템 제약이다. 생산 환경의 AI 시스템은 비즈니스 작업에 경계가 있기 때문에 제약이 필요하다. 모델이 그 경계를 넘어 즉흥적으로 행동해서는 안 된다.

AI 시스템이 도구를 호출할 수 있게 되면, 프롬프트 엔지니어링은 훨씬 더 심각해진다. 도구를 사용할 수 있는 모델은 다음과 같은 작업을 수행할 수 있다.

• 문서 검색
• CRM 조회
• 작업 생성
• 레코드 업데이트
• 메시지 전송
• 워크플로 트리거
• API 호출
• 내부 시스템 접근

이 시점에서는 프롬프트 문구만으로는 충분하지 않다. 제어 설계가 필요하다. 이제 질문은 더 이상 “모델이 뭐라고 말해야 하는가?”가 아니다. “모델이 무엇을 할 수 있게 허용해야 하는가?”가 된다. 이를 위해서는

• 범위가 정의된 도구 정의
• 권한 검사
• 승인 게이트
• 감사 로그
• 속도 제한
• 롤백 동작
• 오류 처리
• 안전 기본값

과 같은 요소가 필요하다. 프롬프트가 이러한 제어를 대체할 수는 없다. 프롬프트는 모델을 안내할 수 있을 뿐이며, 시스템이 이를 관리해야 한다.

많은 사람들이 출력 형식을 사소한 미관 문제로 여긴다. 실제로는 그렇지 않다. AI 시스템에서 출력 형식은 인터페이스 계약이다.

• 출력이 사람에게 전달될 경우, 형식은 가독성에 영향을 미친다.
• 다른 시스템에 전달될 경우, 형식은 신뢰성에 영향을 미친다.
• 워크플로 로직을 트리거할 경우, 형식은 실행에 영향을 미친다.

예를 들어, “이 고객 이슈를 요약해 주세요.”라는 모호한 프롬프트는 다음과 같은 구조화된 출력 계약보다 약하다.

이슈 요약
고객 영향
긴급도 수준
영향받은 제품 영역
누락된 정보
추천 담당자
제안된 다음 조치
신뢰도 수준

이 구조는 출력이 실제로 활용 가능하도록 만들고, 평가를 쉽게 만든다. 다시 말해, 이것도 시스템 설계이다. 모델은 단순히 텍스트를 생성하는 것이 아니라, 다른 사람이나 시스템이 사용할 아티팩트를 만든다.

AI 시스템에 메모리가 도입되면, 프롬프트는 눈에 덜 띈다. 모델은 현재 요청에 명시적으로 제공되지 않은 정보를 사용할 수 있다. 이는 유용할 수도 있지만 위험할 수도 있다. 메모리 설계에는 다음과 같은 규칙이 필요하다.

• 무엇을 기억해야 하는가
• 누가 기억된 컨텍스트에 접근할 수 있는가
• 메모리의 수명은 얼마나 되는가
• 메모리를 어떻게 업데이트할 것인가
• 메모리를 어떻게 삭제할 것인가
• 사용자가 메모리를 검토할 수 있는가
• 특정 워크플로에서 메모리 사용이 허용되는가

오래된 메모리를 조용히 사용하는 프롬프트는 사용자에게 놀라움을 줄 수 있다. 기업 시스템에서 놀라움은 거버넌스 문제다. 메모리는 프롬프트 아키텍처의 일부가 되어야 하며, 보이지 않는 편의성이 아니다.

프롬프트가 잘 쓰였다고 해서 좋은 것이 아니다. 실제 상황에서 원하는 결과를 신뢰성 있게 만들어내는가가 중요하다. 이를 위해서는 평가가 필요하다. 기업 워크플로에서는 평가 항목에 다음이 포함될 수 있다.

• 사실 정확성
• 출처 근거
• 권한 준수
• 출력 완전성
• 형식 유효성
• 위험 분류
• 환각 비율
• 인간 교정 비율
• 작업 완료 비율
• 에스컬레이션 비율

평가 없이 프롬프트 엔지니어링은 취향에 불과하다. 평가가 있으면 엔지니어링이 된다.

목표는 “완벽한 프롬프트”를 쓰는 것이 아니다. 목표는 일관되게 동작하는 시스템을 설계하는 것이다.

형편없는 AI 제품은 사용자가 프롬프트 전문가가 되도록 강요한다. 좋은 AI 제품은 설계를 통해 그 부담을 줄인다. 시스템은 다음을 제공해야 한다.

• 템플릿
• 구조화된 입력
• 승인된 컨텍스트
• 안전 기본값
• 명확한 출력 형식
• 워크플로 전용 에이전트
• 가드레일
• 평가 피드백

사용자는 매번 완벽한 문구를 기억할 필요가 없어야 한다. 워크플로가 중요한 경우, 프롬프트는 제품에 내장돼 설계되어야 한다.

따라서 기업 규모에서 프롬프트 엔지니어링은 사용자 기술이 아니라 제품·시스템 책임이다.

프롬프트 엔지니어링이 사라진 것이 아니다. 단지 잘못 분류된 것이다.

• 개인