하네스 엔지니어링, 이제 진짜 직업이 되다 — 실제 업무 내용은?

지난 2년간 AI 에이전트를 둘러싼 커리어 조언은 대체로 프롬프트를 잘 작성하는 법을 배우라는 것이었다. 이제 그것은 더 이상 희소한 기술이 아니다. 진짜 희소한 기술은 에이전트가 그 안에서 작동하는 뼈대, 즉 점점 하네스라고 불리는 것을 구축하는 일이다. 그리고 이 작업은 충분히 구체적이고 충분히 어려워서, 팀 내 "AI 담당자"의 부수적인 업무가 아니라 그 자체로 하나의 직무로 자리 잡아가고 있다.

이 작업이 실제로 무엇을 수반하는지 가장 명확하게 공개적으로 설명한 자료는 Lenny's Newsletter다. 이 글은 제품 관리 도구인 ChatPRD가 Sentry 버그를 자동으로 디버깅하기 위해 하네스를 구축한 과정을 다루고 있다. 이 분야에 특화할지 고민 중이라면 전문을 읽어볼 가치가 있는데, 놓치기 쉬운 핵심을 짚어주기 때문이다. 바로 모델은 애초에 병목이 아니었다는 점이다. 이 팀은 Claude Agent SDK를 토대로 삼은 뒤, 엔지니어링 노력의 대부분을 커스텀 터미널 UI와 에이전트를 Sentry, Linear, GitHub, Vercel에 연결하는 어댑터 세트에 쏟아부었다. 이것이 바로 이 직무를 축소해서 보여주는 예다. 네 개의 시스템, 네 가지 다른 인증 방식, 네 가지 다른 데이터 형태, 그리고 사람이 매 단계를 일일이 지켜보지 않고도 관찰하고 개입할 수 있게 해주는 UI.

'하네스'가 실제로 어떻게 세분화되는가

이것이 익힐 만한 가치가 있는 스킬셋인지 판단하려 한다면, 별도로 채용되거나 적어도 면접에서 별도로 평가되는 항목들로 나눠서 보는 것이 도움이 된다.

• 권한 설계. 에이전트가 사람 없이 혼자 처리해도 되는 일(티켓 읽기, PR 초안 작성)과 사람이 반드시 개입해야 하는 일(병합, 배포, 삭제, 비용 지출)을 구분하고, 이를 모델이 압박 속에서 무시할 수도 있는 프롬프트 지시가 아니라 코드상의 실제 정책으로 인코딩하는 작업이다. 이는 프롬프트 작성보다는 접근 제어 엔지니어링에 훨씬 가깝다.
• 툴 어댑터. 각 외부 시스템(Sentry, Linear, GitHub, Vercel, 혹은 회사가 쓰는 어떤 스택이든)을 감싸는 얇고 충분히 테스트된 래퍼로, 에이전트의 의도를 안전하고 검증된 API 호출로 변환하고 그 응답을 모델이 추론할 수 있는 형태로 다시 변환해준다. 이는 새로운 소비자(에이전트)에게 적용된 것일 뿐, 오류 처리, 재시도, 스키마 검증 같은 평범한 소프트웨어 엔지니어링이다.
• 터미널 혹은 콘솔 UI. 사람이 에이전트가 무엇을 하고 있는지 보고, 행동을 승인하거나 거부하고, 막혔을 때 개입할 수 있게 해주는 수단이다. ChatPRD는 이를 커스텀으로 구축했다. 많은 팀들은 대신 기성 에이전트 콘솔을 사용하겠지만, 그럼에도 무엇을 보여주고 무엇을 숨기며 무엇이 실행 전에 클릭을 요구하는지는 누군가가 결정해야 한다.
• 대규모 상황에서의 툴 선택. Machine Learning Mastery의 한 글은 데모 수준을 넘어서는 무언가를 구축하고 있다면 알아둘 만한 사실을 지적한다. 툴 카탈로그가 대략 열두 개 옵션을 넘어서면 툴 호출에 대한 에이전트의 정확도가 떨어지기 시작한다는 것이다. 모델이 툴을 잘못 호출하거나, 파라미터를 헛짚거나(할루시네이션), 잘못된 호출에서 멈춰버리기 시작한다. 이 글이 제시하는 완화책들 — 주어진 맥락에서 어떤 툴이 보이도록 할지 제한하기, 검색 기반 툴 조회, 전문화된 서브 에이전트로의 라우팅, 명시적인 계획 단계, 폴백 로직, 그리고 회귀를 잡아내기 위한 벤치마크 하네스 — 자체가 하네스 엔지니어가 그저 알기만 해서는 안 되고 실제로 구현할 줄 알아야 하는 항목들의 체크리스트다.
• 컨텍스트 엔지니어링과 메모리 엔지니어링. 같은 출처는 몸에 새겨둘 만한 구분을 하나 짚는다. 컨텍스트 엔지니어링(단일 추론 호출에 무엇이 어디에 들어가는가)과 메모리 엔지니어링(세션을 넘어 무엇이 지속되고, 어떻게 저장되고, 어떻게 검색되는가)은 서로 다른 실패 양상을 가진 별개의 분야라는 것이다. 이 글의 주장은, 장시간 실행되는 다중 세션 에이전트에서 발생하는 대부분의 오류가 이 둘을 혼동하는 데서, 즉 세션 메모리를 그저 더 많은 컨텍스트인 것처럼 다루거나 그 반대로 다루는 데서 비롯된다는 것이며, 특히 시스템이 무엇을 검색해올지 결정하는 지점에서 그렇다는 것이다.

이것이 취미 수준의 틈새가 아니라 실제로 투자할 가치가 있는 직무라는 증거

회의론자들은 '하네스 엔지니어'가 진짜 직무인지, 아니면 누군가의 업무 안에 있는 하나의 작업일 뿐인지 타당하게 물을 것이다. 이 다이제스트에 나온 두 가지 데이터 포인트는 전자 쪽으로 흘러가고 있음을 시사한다. 첫째, 마이크로소프트의 Aspire 팀(10명 규모)은 GitHub의 Agentic Workflows를 사용해 여러 저장소에 걸친 문서 PR을 자동화했고, 두 번의 릴리스에 걸쳐 82건의 PR을 병합했는데, 해당 제품 PR이 출시된 후 중앙값 44.8시간 만에 이루어졌으며 인력 충원도 프로세스 재교육도 없었다. 이는 작은 팀이 유독 큰 레버리지를 얻은 사례인데, 엔지니어들이 문서 PR을 직접 손으로 쓰게 하는 대신 누군가가 뼈대(워크플로 정의, 리뷰 라우팅, 트리거 로직)에 투자했기 때문이다. 둘째, 마이크로소프트 리서치의 SkillOpt 프로젝트는 에이전트가 하네스 안에서 어떻게 행동할지를 규정하는 지침과 제약인 '스킬' 파일을 손으로 수정하는 대상이 아니라 체계적으로 최적화해야 할 대상으로 취급하며, 벤치마크 그리드의 52개 셀(여섯 개 벤치마크, 일곱 개 모델, 세 가지 실행 모드) 전체에서 최고 또는 공동 최고 성능을 냈다고 보고한다. 최적화된 스킬은 서로 다른 모델과 서로 다른 하네스에도 전이되었다. 이 특정 툴이 표준이 되든 안 되든, 이는 업계가 하네스 구성을 자체 툴링과 벤치마크를 갖춘 엔지니어링 산출물로 취급하기 시작했다는 신호다. '데브옵스'가 임기응변식 스크립트 모음에서 하나의 분야로 발전했던 것과 같은 궤적이다.

이 계층을 위해 명시적으로 구축되는 인프라도 이미 등장하고 있다. 구글이 최근 발표한 Gemini API의 'Managed Agents' 기능들 — 백그라운드 및 비동기 실행, 원격 MCP 서버 통합, 커스텀 함수 호출, 상호작용 전반에 걸친 자격 증명 갱신 — 은 사실상 ChatPRD 팀이 직접 손으로 풀었던 바로 그 문제들을 위한 사전 구축된 배관과도 같다. 이것은 흔한 패턴이다. 올해 한 팀이 맞춤형으로 만든 것을, 내년에는 플랫폼 벤더가 제품화한다. 이것이 하네스 엔지니어링이라는 역할을 없애지는 않는다. 오히려 기본 수준을 끌어올리고, 모든 어댑터를 처음부터 작성하는 대신 관리형 기본 요소들을 통합하고 구성하는 쪽으로 업무의 무게중심을 옮길 뿐이다. 클라우드 인프라가 운영 엔지니어를 없애지 않고 그들이 시간을 쓰는 대상을 바꾸었던 것과 비슷하다.

이 직무를 목표로 한다면 이것이 의미하는 바

이 분야에서 신뢰를 얻고 싶다면 포트폴리오나 이력서에 넣을 만한 구체적이고 확인 가능한 항목 몇 가지가 있다. 자신이 통제할 수 없는 실제 API를 상대로 어댑터 하나를 처음부터 끝까지 만들어볼 것(단순한 해피패스 데모가 아니라 인증, 오류 처리, 레이트 리밋까지 포함해서). 읽기/제안/실행 행동을 구분하는 에이전트용 권한 모델을 설계하고 문서화하면서 각 경계가 왜 그 지점에 있는지를 보여줄 것. 그리고 사람이 에이전트의 행동을 실행 전에 승인하는 리뷰 인터페이스를 구축하거나 구성해볼 것 — 대부분의 회사가 에이전트를 프로덕션에 접근시키기 전에 반드시 요구할 부분이기 때문이다. 하네스 엔지니어링 채용 제안을 검토하거나 스스로의 책임 범위를 정하는 중이라면, 권한 모델은 누가 소유하는지, 어댑터는 누가 소유하는지, 사람의 검토 화면은 누가 소유하는지를 구체적으로 물어봐야 한다. 지금 많은 팀에서 이 세 가지는 명확한 소유자가 없는데, 바로 그 공백을 메우기 위해 이 직무가 형성되고 있는 것이다.

솔직히 짚고 넘어갈 단서 하나가 있다. 위에 언급한 어떤 출처도 이 구체적인 직함에 대한 채용 시장 수치를 제시하지는 않으며, '하네스 엔지니어'는 아직 채용 공고에서 볼 수 있는 직함이 아니다. 대신 'AI 인프라 엔지니어', '에이전트 플랫폼 엔지니어', 혹은 그냥 '시니어 백엔드 엔지니어, AI 시스템' 같은 직함 안에 녹아들어 나타난다. 이것을 링크드인에서 검색할 직함이 아니라, 익히고 정확하게 설명해야 할 스킬셋으로 취급하라.