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

프롬프트 엔지니어링 (Prompt engineering)은 사람들이 이를 카피라이팅 (copywriting)처럼 취급하기 때문에 오해를 받고 있습니다.

일반적인 관점은 단순합니다:

사용자가 더 나은 프롬프트를 작성한다.

모델이 더 나은 답변을 제공한다.

따라서 기술이란 질문하는 법을 배우는 것이다.

이러한 관점은 개인적인 AI 사용에는 유용합니다.

하지만 기업용 시스템 (enterprise systems)에는 충분하지 않습니다.

프로덕션 환경 (production environments)에서 프롬프트 엔지니어링은 주로 영리한 문구 작성이 아닙니다.

그것은 시스템 설계 (systems design)에 관한 것입니다.

프롬프트는 더 깊은 아키텍처 (architecture)의 가시적인 표면일 뿐입니다.

모든 훌륭한 AI 출력물 뒤에는 숨겨진 설계 결정들이 있습니다:

어떤 컨텍스트 (context)가 포함되었는가
어떤 컨텍스트가 제외되었는가
모델에게 어떤 역할 (role)이 부여되었는가
어떤 도구 (tools)를 사용할 수 있었는가
어떤 메모리 (memory)가 검색되었는가
어떤 제약 조건 (constraints)이 강제되었는가
어떤 출력 형식 (output format)이 요구되었는가
응답이 어떻게 평가되었는가
응답 이후에 어떤 일이 일어났는가

그것이 바로 시스템 설계입니다.

단순한 사용자 기술이 아닙니다.

1. 프롬프트는 시스템이 아닙니다.

프롬프트는 시스템으로 들어가는 하나의 입력값일 뿐입니다.

실제 AI 워크플로우 (workflow)에는 다음이 포함될 수 있습니다:

사용자 질의 (user query)
시스템 지침 (system instruction)
검색된 문서 (retrieved documents)
사용자 권한 (user permissions)
도구 정의 (tool definitions)
대화 기록 (conversation history)
메모리 (memory)
구조화된 데이터 (structured data)
정책 제약 (policy constraints)
출력 스키마 (output schema)
평가 체크 (evaluation checks)

사람들이 "프롬프트가 실패했다"라고 말할 때, 그들은 종종 텍스트를 탓합니다.

하지만 실패의 원인은 다른 곳에 있을 수 있습니다.

아마도 검색 (retrieval)이 잘못된 컨텍스트를 반환했을 수도 있습니다.

아마도 모델이 너무 많은 도구에 접근할 수 있었을 수도 있습니다.

아마도 출력 스키마가 모호했을 수도 있습니다.

아마도 시스템이 부분적인 데이터만 가지고 있을 때 사용자가 결정을 요구했을 수도 있습니다.

아마도 지침이 다른 지침과 충돌했을 수도 있습니다.

아마도 평가 레이어 (evaluation layer)가 존재하지 않았을 수도 있습니다.

프롬프트는 전체 설계가 아닙니다.

그것은 조립 지점 (assembly point)입니다.

2. 컨텍스트 설계는 문구보다 더 중요합니다.

적절한 컨텍스트를 가진 평범한 프롬프트가 대개 부족한 컨텍스트를 가진 영리한 프롬프트보다 낫습니다.

이는 비즈니스 워크플로우 (business workflows)에서 특히 사실입니다.

모델에게 고객 상황을 요약하도록 요청할 때, 모델에는 적절한 고객 컨텍스트가 필요합니다.

준수 사항(compliance) 답변 초안을 작성하도록 요청받는다면, 적절한 정책 소스(policy source)가 필요합니다.

티켓의 우선순위를 정하도록 요청받는다면, 심각도(severity), 계정 가치(account value), SLA, 소유권(ownership), 그리고 최근 이력(recent history)이 필요합니다.

프롬프트의 문구(wording)도 중요합니다.

하지만 컨텍스트 선택(context selection)이 더 중요합니다.

시스템 설계자는 다음 사항을 결정해야 합니다:

어떤 데이터 소스가 허용되는가
컨텍스트가 어떻게 검색(retrieved)되는가
얼마나 많은 컨텍스트가 포함되는가
어떤 컨텍스트가 너무 민감한가
어떤 컨텍스트가 오래된(stale) 정보인가
어떤 컨텍스트를 먼저 요약해야 하는가
어떤 컨텍스트에 인용(citation)이나 추적 가능성(traceability)이 필요한가

이것이 바로 프롬프트 엔지니어링이 아키텍처(architecture)가 되는 이유입니다.

사용자가 매번 적절한 컨텍스트를 수동으로 붙여넣을 필요가 없어야 합니다.

시스템이 이를 어떻게 조립(assemble)해야 하는지 알고 있어야 합니다.

3. 제약 사항(Constraints)은 프롬프트 아키텍처의 일부입니다.

훌륭한 AI 워크플로(workflow)는 모델에게 무엇을 해야 하는지만 알려주지 않습니다.

모델에게 무엇을 하지 말아야 하는지도 알려줍니다.

예시:

누락된 정보를 지어내지 마시오
승인되지 않은 소스로부터 답변하지 마시오
기밀 컨텍스트를 노출하지 마시오
법적 결론을 내리지 마시오
승인 없이 동작을 실행하지 마시오
사용자가 접근할 수 없는 파일을 요약하지 마시오
오래된 정책 문서를 사용하지 마시오
요구된 형식을 벗어나 응답하지 마시오

이것들은 글쓰기 팁이 아닙니다.

이것들은 시스템 제약 사항(system constraints)입니다.

비즈니스 업무에는 경계가 있기 때문에, 프로덕션(production) AI 시스템에는 제약 사항이 필요합니다.

모델은 그 경계를 넘어 즉흥적으로 행동해서는 안 됩니다.

4. 도구 접근(Tool access)은 프롬프팅을 제어 설계(control design)로 바꿉니다.

AI 시스템이 도구(tools)를 호출할 수 있게 되면, 프롬프트 엔지니어링은 훨씬 더 심각한 문제가 됩니다.

도구 사용이 가능한 모델은 다음과 같은 일을 할 수 있습니다:

문서 검색
CRM 쿼리(query)
작업(task) 생성
레코드 업데이트
메시지 전송
워크플로(workflow) 트리거
API 호출
내부 시스템 접근

그 시점에서 프롬프트 문구만으로는 충분하지 않습니다.

시스템에는 제어 설계(control design)가 필요합니다.

질문은 더 이상 다음과 같지 않습니다:

모델이 무엇을 말해야 하는가?

질문은 다음과 같이 바뀝니다:

모델이 무엇을 할 수 있도록 허용되어야 하는가?

이를 위해서는:

범위가 지정된 도구 정의 (scoped tool definitions)
권한 확인 (permission checks)
승인 게이트 (approval gates)
감사 로그 (audit logs)
속도 제한 (rate limits)
롤백 동작 (rollback behavior)
에러 처리 (error handling)
안전한 기본값 (safe defaults)

프롬프트는 이러한 제어 장치들을 대체할 수 없습니다.

프롬프트는 모델을 안내할 수 있습니다.

하지만 시스템이 모델을 통제해야 합니다.

5. 출력 형식은 인터페이스 계약입니다.

많은 사람들이 출력 형식을 미적인 세부 사항으로 취급합니다.

그렇지 않습니다.

AI 시스템에서 출력 형식은 종종 인터페이스 계약 (interface contract) 역할을 합니다.

AI 출력이 사람에게 전달된다면, 형식은 가독성에 영향을 미칩니다.

AI 출력이 다른 시스템으로 전달된다면, 형식은 신뢰성에 영향을 미칩니다.

AI 출력이 워크플로 로직을 트리거한다면, 형식은 실행에 영향을 미칩니다.

다음과 같은 모호한 프롬프트는:

"이 고객 문제를 요약해 주세요."

구조화된 출력 계약보다 약합니다:

문제 요약 (issue summary)
고객 영향 (customer impact)
긴급도 수준 (urgency level)
영향을 받는 제품 영역 (affected product area)
누락된 정보 (missing information)
권장 담당자 (recommended owner)
제안된 다음 조치 (suggested next action)
신뢰 수준 (confidence level)

그러한 구조가 출력을 유용하게 만듭니다.

또한 평가를 더 쉽게 만듭니다.

다시 말하지만, 이것은 시스템 설계 (systems design)입니다.

모델은 단순히 텍스트를 생성하는 것이 아닙니다.

모델은 다른 사람이나 시스템이 사용해야 하는 결과물 (artifact)을 생성하는 것입니다.

6. 메모리는 프롬프트 경계를 변화시킵니다.

AI 시스템이 메모리 (memory)를 갖게 되면, 프롬프트는 덜 눈에 띄게 됩니다.

모델은 사용자가 현재 요청에서 명시적으로 제공하지 않은 정보를 사용할 수 있습니다.

이는 유용할 수 있습니다.

하지만 위험할 수도 있습니다.

메모리 설계에는 규칙이 필요합니다:

무엇을 기억해야 하는가
누가 기억된 컨텍스트 (context)에 접근할 수 있는가
메모리가 얼마나 오래 유지되어야 하는가
메모리가 어떻게 업데이트되는가
메모리가 어떻게 삭제되는가
사용자가 메모리를 검사할 수 있는가
특정 워크플로에서 메모리 사용이 허용되는가

이전 메모리를 조용히 사용하는 프롬프트는 사용자를 놀라게 할 수 있습니다.

엔터프라이즈 시스템에서 '놀라움'은 거버넌스 (governance) 문제입니다.

메모리는 프롬프트 아키텍처의 일부여야 합니다.

보이지 않는 편의 기능이 아니라 말입니다.

7. 평가는 프롬프트 엔지니어링의 일부입니다.

프롬프트는 잘 쓰인 것처럼 들린다고 해서 좋은 것이 아닙니다.

실제 조건 하에서 원하는 결과를 안정적으로 생성해낸다면 좋은 것입니다.

그러기 위해서는 평가 (evaluation)가 필요합니다.

엔터프라이즈 워크플로 (enterprise workflows)의 경우, 평가는 다음을 포함할 수 있습니다:

사실적 정확성 (factual accuracy)
소스 근거 (source grounding)
권한 준수 (permission compliance)
출력 완결성 (output completeness)
형식 유효성 (format validity)
리스크 분류 (risk classification)
환각률 (hallucination rate)
인간 수정률 (human correction rate)
작업 완료율 (task completion rate)
에스컬레이션 비율 (escalation rate)

평가 없이는 프롬프트 엔지니어링은 취향의 영역이 됩니다.

평가가 있다면, 그것은 엔지니어링이 됩니다.

목표는 "완벽한 프롬프트"를 작성하는 것이 아닙니다.

목표는 일관되게 동작하는 시스템을 설계하는 것입니다.

8. 사용자가 모든 부담을 짊어져서는 안 됩니다.

나쁜 AI 제품은 사용자가 프롬프트 전문가가 되도록 강요합니다.

좋은 AI 제품은 설계를 통해 그 부담을 줄여줍니다.

시스템은 다음을 제공해야 합니다:

템플릿 (templates)
구조화된 입력 (structured inputs)
승인된 컨텍스트 (approved context)
안전한 기본값 (safe defaults)
명확한 출력 형식 (clear output formats)
워크플로 특화 에이전트 (workflow-specific agents)
가드레일 (guardrails)
평가 피드백 (evaluation feedback)

사용자가 매번 완벽한 문구를 기억해야 할 필요는 없어야 합니다.

워크플로가 중요하다면, 프롬프트는 제품 내부에 설계되어 있어야 합니다.

이것이 엔터프라이즈 규모에서 프롬프트 엔지니어링이 사용자의 기술이 아닌 이유입니다.

그것은 제품과 시스템의 책임입니다.

마지막 생각

프롬프트 엔지니어링은 죽지 않았습니다.

단지 잘못 분류되고 있을 뿐입니다.

개인적인 용도로는 더 잘 질문하는 것처럼 보일 수 있습니다.

엔터프라이즈 용도로는 시스템 설계 (systems design)가 됩니다.

진정한 작업은 마법의 단어를 찾는 것이 아닙니다.

진정한 작업은 컨텍스트 (context), 제약 조건 (constraints), 메모리 (memory), 도구 (tools), 출력 계약 (output contracts), 그리고 평가 루프 (evaluation loops)를 설계하는 것입니다.

최고의 프롬프트는 가장 똑똑하게 들리는 프롬프트가 아닙니다.

최고의 프롬프트는 어떤 데이터를 사용할 수 있는지, 어떤 행동을 취할 수 있는지, 어떤 경계를 준수해야 하는지, 그리고 성공이 어떻게 측정되는지를 알고 있는 시스템 내부에 내장된 프롬프트입니다.

그것은 카피라이팅 (copywriting)이 아닙니다.

그것은 아키텍처 (architecture)입니다.