하네스 엔지니어링과 컨텍스트·프롬프트 엔지니어링 차이 정리: 세 용어는 어떻게 쌓이는가

핵심 메시지

• 세 용어는 서로를 대체하는 것이 아니라 아래에서 위로 쌓이는 층위다. 좋은 컨텍스트 엔지니어링에는 프롬프트 엔지니어링이, 좋은 하네스 엔지니어링에는 컨텍스트 엔지니어링이 필요하다.
• 프롬프트 엔지니어링은 모델 하나에 보내는 말의 구조를 다듬는 일로, 역할 부여와 사고 사슬, 예시 제시, 출력 형식 지정이 대표적인 방법이다.
• 컨텍스트 엔지니어링은 모델의 컨텍스트 창에 무엇을 넣을지 관리하는 일이며, RAG와 메모리, 파일과 스키마, 도구 정의가 여기에 들어간다.
• 하네스 엔지니어링은 자율 에이전트가 여러 단계를 안정적으로 수행하도록 그 주변에 인프라를 짓는 일이다.
• 하네스는 IDE나 특정 코딩 도구에 갇힌 개념이 아니며 고객 응대 자동화 같은 영역에도 똑같이 적용된다.

쉽게 이해하기

영상은 매년 새 용어가 튀어나와 혼란스럽다는 시청자의 심정에서 출발한다. 발표자는 세 용어가 유행어 교체가 아니라 층층이 쌓이는 관계라는 점을 그래프로 보여준다. 아래층이 무너지면 위층도 성립하지 않는다는 뜻이어서, 프롬프트 엔지니어링이 한물갔다는 식의 이해는 틀렸다고 못 박는다.

가장 아래 프롬프트 엔지니어링은 2022년부터 2024년 사이에 널리 쓰인 개념으로, 모델 하나 또는 에이전트 하나를 상대할 때의 기술이다. 더 나은 입력이 더 나은 출력을 낳는다는 단순한 전제 위에서 시스템 프롬프트를 다듬는 일이 중심이었다. 선임 백엔드 엔지니어처럼 행동하라고 역할을 주거나, 사고 사슬을 유도하거나, 사용자 입력 앞에 예시를 붙이거나, JSON으로 답하라고 출력 형식을 못 박는 식이다.

그 위의 컨텍스트 엔지니어링은 안드레이 카파시가 널리 알린 개념으로 소개된다. 모델의 컨텍스트 창에 어떤 정보가 들어갈지를 관리하는 실천으로, 어떤 파일과 문서와 데이터를 모델이 볼 수 있게 할지 정하는 일이다. 에이전트를 데이터베이스에 연결하는 RAG, 메모리 관리, 어떤 스키마와 도구 정의를 넘길지의 결정이 모두 여기에 속한다. 2025년에 확산된 MCP도 도구 정의라는 맥락에서 이 층에 놓이며, 컨텍스트가 지나치게 길어질 때 압축해 창이 비대해지는 것을 막는 일도 포함된다.

맨 위의 하네스 엔지니어링은 앞의 두 층을 품으면서 범위를 넓힌다. 자율 에이전트가 여러 단계에 걸쳐 신뢰할 만하게 작동해야 하는 곳이면 어디든 해당한다. 발표자는 고객 응대 자동화에서 문의 분류와 응답, 상급자 이관과 기록이 자동으로 이어지는 경우, 소프트웨어 개발에서 Sentry 같은 도구가 버그를 감지하고 수정안을 제시하며 파이프라인의 테스트를 실행하고 깃허브에 자동으로 풀 리퀘스트를 올리는 경우를 예로 든다. 핵심 단어는 '자동'이다.

구체적 사례로는 스트라이프가 주당 1300건의 AI 풀 리퀘스트를 처리했다는 이야기가 나온다. 발표자가 주목하는 대목은 건수 자체가 아니라 그것이 검토되고 병합되고 배포까지 완료된 풀 리퀘스트라는 점이다. 그런 수치는 AI 비서를 쓰는 것만으로는 나오지 않으며 코딩 에이전트 주변에 인프라를 지었기 때문에 가능하다는 것이다. 발표자는 다중 에이전트 오케스트레이션도 같은 범주로 보며, 결국 프롬프트를 쓰는 일에서 인프라를 짓는 일로 무게중심이 옮겨간다고 정리한다.

주요 인사이트

• 새 용어가 앞의 용어를 폐기하는 것처럼 읽히는 것이 가장 흔한 오해다. 층위 구조로 보면 아래층 기술은 계속 필요하며 오히려 위층의 전제 조건이 된다.
• 하네스는 특정 제품 이름이 아니라 구조를 가리킨다. 발표자가 코딩 에이전트 도구들을 하네스의 예로 들면서도, 하네스가 IDE 안에 사는 개념이 아니라고 선을 긋는 이유다.
• 성과의 지표를 어디에 두느냐가 중요하다. 생성된 풀 리퀘스트 수가 아니라 검토와 병합과 배포까지 끝난 건수를 보는 관점이 자동화의 실효를 가른다.
• 하네스를 만드는 공식적인 방법은 아직 정해져 있지 않다. 발표자가 소개한 사례도 커뮤니티에서 발견한 것으로, 파이썬 스크립트 묶음을 스킬 형태로 참조하게 만든 개인의 구성이다.

자주 묻는 질문

관련 AI 소식