sunny34.com

1. 왜 이제는 프롬프트만으로 설명이 부족한가

초기 LLM 활용은 질문 문장을 어떻게 쓰느냐에 초점이 있었습니다. 그래서 프롬프트 엔지니어링이 가장 먼저 널리 퍼졌습니다. 하지만 에이전트가 도구를 호출하고, 파일을 남기고, 여러 세션을 이어 가며, 실패 후 다시 복구하는 단계로 넘어오면 좋은 문장만으로는 품질을 설명하기 어렵습니다.

최근 공개된 OpenAI의 Harness Engineering 글과 Anthropic의 long-running harness 글을 함께 보면 공통 메시지가 있습니다. 사람은 방향을 정하고, 에이전트는 실행하며, 실제 생산성 차이는 그 둘 사이를 이어 주는 운영 구조에서 크게 벌어진다는 점입니다. 이 글에서 말하는 하네스 엔지니어는 바로 그 구조를 설계하는 역할입니다. 이 정의는 여러 자료를 종합한 운영 해석입니다.

2. 프롬프트 엔지니어는 지시를 정밀하게 만든다

프롬프트 엔지니어의 핵심 책임은 모델이 해야 할 일을 명확하게 표현하는 것입니다. OpenAI의 프롬프트 가이드가 강조하듯 지시는 앞에 두고, 입력과 지시를 구분하며, 원하는 출력 형식을 구체적으로 명시해야 재현성이 높아집니다. Anthropic의 프롬프트 개요 역시 성공 기준과 평가 기준이 먼저 있어야 프롬프트를 개선할 수 있다고 설명합니다.

즉 프롬프트 엔지니어는 모델 내부 추론을 통제하는 사람이 아니라, 작업 계약을 명료하게 만드는 사람에 가깝습니다. 입력 형식, 출력 형식, 금지 규칙, 예시, 평가 조건을 정리해 모델이 흔들리지 않게 돕습니다.

3. 컨텍스트 엔지니어는 무엇을 넣고 무엇을 빼야 하는지 결정한다

컨텍스트 엔지니어의 중심 문제는 "어떤 정보를 언제 얼마나 넣을 것인가"입니다. 단순히 긴 문서를 많이 붙이는 역할이 아닙니다. Anthropic 엔지니어링 글이 강조하는 흐름은 컨텍스트를 축적, 분리, 압축하는 방식이고, Microsoft Research의 Agentic Context Engineering은 문맥 자체를 진화시키는 운영 계층으로 다룹니다.

실무에서는 다음 같은 일이 여기에 들어갑니다.

• 현재 작업에 필요한 파일과 문서만 선별해 넣기
• 이전 세션 결과를 요약 메모나 상태 파일로 남기기
• 긴 로그를 그대로 넘기지 않고 다음 결정에 필요한 정보만 압축하기
• 사용자 요청, 시스템 정책, 검색 결과, 메모리 데이터를 서로 다른 레이어로 관리하기

좋은 컨텍스트 엔지니어링은 모델을 더 똑똑하게 만드는 것이 아니라, 모델이 덜 헤매게 만드는 일입니다.

4. 하네스 엔지니어는 에이전트가 일하도록 둘러싼 실행 환경을 만든다

하네스 엔지니어는 프롬프트와 컨텍스트를 넘어, 에이전트가 실제로 작업을 수행하는 운영 껍질을 설계합니다. 세션 초기화, 파일 구조, 승인 절차, 체크포인트, 테스트, 실패 복구, 작업 분할, 로그, 재시도 기준, 사람 개입 경계를 함께 다룹니다.

Anthropic은 long-running agents 글에서 초기화 에이전트와 코딩 에이전트를 분리하는 2단 구조를 설명했고, OpenAI의 Harness Engineering 글은 사람의 일보다 시스템과 작업 흐름을 설계하는 일이 더 중요해졌다는 문제의식을 제시합니다. 두 자료를 같이 보면 하네스는 "에이전트에게 무엇을 말할까"보다 "에이전트가 어떤 상태에서 어떤 루프로 일하게 할까"에 가깝습니다.

하네스 엔지니어가 주로 다루는 범위는 아래와 같습니다.

• 작업을 작은 실행 단위로 나누는 큐와 상태 전이 설계
• 세션 사이를 잇는 AGENTS.md, 작업 로그, 메모, 체크포인트 파일 구조
• 도구 권한, 사람 승인, 실패 시 중단 조건 같은 안전 장치
• 테스트, 평가, CI, 관측성, 재현 가능한 실행 환경

5. 세 역할의 차이를 한 줄로 정리하면 이렇다

• 프롬프트 엔지니어: 모델에게 어떤 방식으로 지시할지 설계한다.
• 컨텍스트 엔지니어: 모델이 볼 정보의 범위와 순서를 설계한다.
• 하네스 엔지니어: 모델이 실제 작업을 끝낼 수 있는 실행 환경과 운영 루프를 설계한다.

이 셋은 대체 관계가 아니라 계층 관계에 가깝습니다. 프롬프트가 나빠도 실패하지만, 긴 작업에서는 컨텍스트 설계와 하네스 설계가 더 빨리 병목이 됩니다.

6. 비교 사례 1: 고객지원 에이전트

예를 들어 환불 문의를 처리하는 고객지원 에이전트를 만든다고 가정해 보겠습니다.

• 프롬프트 엔지니어는 환불 정책 요약 방식, 금지 문장, 사과 톤, 응답 포맷을 설계합니다.
• 컨텍스트 엔지니어는 주문 정보, 정책 문서, 과거 문의 기록, 현재 대화 맥락 중 무엇을 먼저 넣을지 정합니다.
• 하네스 엔지니어는 고위험 요청은 사람 승인으로 넘기고, 환불 API 호출 전 체크리스트를 실행하며, 실패 시 티켓 시스템으로 전환되도록 흐름을 만듭니다.

이 경우 초기 품질은 프롬프트에서 빨리 올라가지만, 운영 안정성은 하네스가 좌우합니다.

7. 비교 사례 2: 코드 수정 에이전트

코드 저장소를 읽고 수정하는 코딩 에이전트에서는 차이가 더 명확합니다.

• 프롬프트 엔지니어는 수정 범위, 금지된 리팩터링, 응답 형식, 테스트 보고 형식을 설계합니다.
• 컨텍스트 엔지니어는 관련 파일만 좁혀 제공하고, 이전 실패 시도와 작업 노트를 압축해 다음 세션에 넘깁니다.
• 하네스 엔지니어는 브랜치 전략, 테스트 실행 순서, 리뷰 게이트, 장시간 작업 체크포인트, 권한 승인, 롤백 기준을 설계합니다.

OpenAI와 Anthropic의 하네스 관련 글이 모두 코딩 에이전트를 예로 드는 이유도 여기 있습니다. 실제 시간 절감은 응답 문장보다 실행 체계에서 더 크게 발생하기 때문입니다.

8. 비교 사례 3: 장시간 리서치·콘텐츠 파이프라인

블로그 초안 작성, 참고 자료 수집, 인용 링크 정리, 이미지 생성, 발행 전 점검까지 이어지는 콘텐츠 파이프라인도 같은 구조로 볼 수 있습니다.

• 프롬프트 엔지니어는 글의 톤, 구조, 요약 형식, 금지 표현을 설계합니다.
• 컨텍스트 엔지니어는 기존 글, 검색 자료, 논문 초록, 경쟁 블로그, 브랜드 정책을 어떤 순서로 넣을지 설계합니다.
• 하네스 엔지니어는 리서치 단계, 초안 단계, 사실 검토 단계, 링크 검증 단계, 썸네일 생성 단계를 분리하고 승인 지점을 배치합니다.

즉 이 글 자체도 프롬프트만으로 작성되기보다, 컨텍스트 정리와 하네스 분할 덕분에 품질이 올라갑니다.

9. 실무에서 어떤 역할을 먼저 강화해야 하나

짧은 Q&A 챗봇이나 단일 회신 자동화라면 프롬프트 엔지니어링만으로도 큰 개선을 만들 수 있습니다. 반면 검색, 파일, 승인, 다단계 도구 호출이 붙는 순간 컨텍스트 엔지니어링이 중요해집니다. 그리고 작업이 여러 세션을 넘기거나 CI, 배포, 사람 승인, 실패 복구가 얽히면 하네스 엔지니어링이 핵심이 됩니다.

실무 판단 기준을 아주 단순하게 줄이면 아래처럼 볼 수 있습니다.

• 한 번 답하고 끝나는가: 프롬프트 비중이 크다.
• 여러 자료를 모아 판단하는가: 컨텍스트 비중이 커진다.
• 실행, 승인, 복구, 장시간 진행이 필요한가: 하네스 비중이 가장 커진다.

10. 하네스 엔지니어를 압축 요약하면

하네스 엔지니어는 에이전트 시대의 운영 설계자에 가깝습니다. 좋은 프롬프트와 좋은 컨텍스트를 실제 성과로 연결하기 위해, 작업 공간과 승인 흐름, 체크포인트와 평가 루프를 만드는 사람입니다. 최근 자료들을 종합하면 하네스 엔지니어링은 새로운 유행어라기보다, 에이전트를 장시간 안정적으로 굴리기 위한 기존 소프트웨어 엔지니어링의 재배치라고 보는 편이 정확합니다. 이 문장은 OpenAI, Anthropic, Microsoft Research 자료를 합쳐 도출한 해석입니다.