프롬프트 엔지니어링은 4단계 스택의 한 단계일 뿐

💡 프롬프트 엔지니어링은 4단계 스택의 한 단계일 뿐, 전체 스택이 아닙니다. 각 단계는 이전 단계를 감싸는 구조입니다.

 

🔹프롬프트 엔지니어링: 채팅창에 직접 입력하는 정확한 문구, 지침, 제약 조건입니다. 모든 AI 상호작용은 여기서 시작되며, 대부분의 사용자는 여기서 멈춥니다.

 

🔹컨텍스트 엔지니어링: 모델이 프롬프트를 보기 전에 읽는 시스템 지침, 참조 파일, 대화 기록입니다. 컨텍스트가 잘 구축된 평범한 프롬프트라도 컨텍스트가 없는 훌륭한 프롬프트보다 꾸준히 더 나은 성능을 보여줍니다.

 

🔹하네스 엔지니어링: 도구를 라우팅하고, 출력을 검증하고, 자동으로 재시도하는 코드입니다. 이를 통해 모델은 사용자에게 도달하기 전에 자체 작업을 확인합니다. 이는 시스템을 단순히 가끔 인상적인 것이 아니라 안정적으로 만드는 요소입니다.

 

🔹루프 엔지니어링: 시스템이 사용자의 개입 없이 스스로 프롬프트를 표시하고, 확인하고, 조정할 수 있도록 정의된 목표와 종료 조건입니다. 이는 사용자가 조작하는 도구와 스스로 실행되는 시스템의 차이입니다.

 

각 단계는 서로 다른 오류 모드를 감지합니다. 더 나은 프롬프트는 사용자가 입력한 내용만 수정해 줄 뿐입니다. 입력되는 컨텍스트가 부족하면 모델은 주어지지 않은 사실을 추측하게 됩니다. 출력을 검증하는 도구가 없다면, 사용자가 직접 QA 단계를 수행하며 매번 수동으로 오류를 잡아내야 합니다. 그리고 루프가 없다면, 정해진 일정에 따라 전체 프로세스를 다시 실행해야 하므로 사실상 루프를 벗어나지 못하게 됩니다.

 

이것이 바로 데모에서는 인상적인 AI 프로젝트가 실제 운영 환경에서 종종 실패하는 진짜 이유입니다. 데모는 단 하나의 좋은 프롬프트만 통과하면 되지만, 실제 운영 환경에서는 잘못된 컨텍스트, 도구 오류, 프롬프트가 예상하지 못한 예외 상황 등을 모두 견뎌내야 합니다. 바로 이러한 상황을 처리하기 위해 나머지 세 가지 계층이 존재하는 것입니다.

 

LLM을 사용하여 구축하는 경우, 유용한 검토는 "내 프롬프트가 충분히 좋은가?"가 아니라 "이 네 가지 계층 중 어떤 부분을 여전히 수동으로 처리하고 있으며, 이를 시스템으로 옮기려면 무엇이 필요한가?"입니다.