프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링.
전부 다른 개념이 아닙니다.
"사람이 원하는 걸 얻기 위한 명령"이라는 본질은 처음부터 똑같았습니다.
바뀐 건 명령의 형태가 아니라,
명령이 실패했을 때 치르는 비용의 크기입니다.
ㅡ
프롬프트 엔지니어링은
"어떻게 말해야 알아듣지?"의 단계였습니다.
인간이 기계의 입력 방식에 맞춰 자기 언어를 최적화하는 것.
실패하면? 다시 써서 보내면 됐습니다.
컨텍스트 엔지니어링은
"어떤 배경지식을 줘야 오해 없이 수행하지?"의 단계입니다.
제한된 작업 기억에 필요한 정보를 적시에 공급하는 설계.
실패하면? 정보 구조를 고쳐서 다시 돌려야 했습니다.
하네스 엔지니어링은
"명령이 끝까지 완수되려면 어떤 궤도를 깔아야 하지?"의 단계입니다.
에이전트의 실행 환경 자체를 설계하는 시스템 공학.
실패하면? 시스템이 자체 피드백 루프로 재실행합니다.
ㅡ
여기서 진짜 변화가 보입니다.
프롬프트 단계에선 내가 직접 고쳐야 했고,
하네스 단계에선 시스템이 스스로 교정합니다.
우리의 역할이 바뀐 겁니다.
"명령을 내리는 사람"에서
"명령이 수행되는 궤도를 설계하는 사람"으로.
ㅡ
그런데 본질을 잘 보면,
이건 갑자기 등장한 흐름이 아닙니다.
프롬프트 시절에도 금지어를 설정하고,
페르소나를 부여하고, 출력 형식을 제어했습니다.
그게 이미 하네스를 언어로 구현하려던 시도였습니다.
유행이 아니라 본질을 훑은 사람은
프롬프트 단계에서 이미 하네스를 고민하고 있었습니다.
새 용어가 나올 때마다 흔들리지 마세요.
"내가 원하는 걸 얻기 위해 무엇을 제어하는가?"
이 질문 하나면 충분합니다.
생성형 AI
프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링은 다릅니다
이 관점을 사내 교육으로 다룰 때
아래 과정에서 이 주제를 실무 사례와 워크숍으로 연결해 다룹니다.