팀 도입과 하네스 엔지니어의 미래

개인의 요령을 팀의 시스템으로 바꾸기

하네스 엔지니어링은 개인이 프롬프트를 잘 쓰는 기술에서 끝나지 않는다. 진짜 효과는 팀 전체가 같은 방식으로 AI 에이전트를 쓰기 시작할 때 나온다. 한 사람은 에이전트에게 충분한 컨텍스트를 주고, 다른 사람은 매번 빈 대화창에서 시작한다면 결과 품질은 들쭉날쭉해진다. 같은 모델을 써도 어떤 팀은 생산성이 오르고, 어떤 팀은 AI가 만든 결과를 고치느라 더 바빠진다.

그래서 조직 도입의 첫 목표는 "잘 쓰는 사람"을 늘리는 것이 아니라 "잘 작동하는 환경"을 공유하는 것이다. OpenAI는 에이전트 시대의 소프트웨어 팀이 해야 할 일이 코드 작성에서 환경 설계, 의도 명세, 피드백 루프 구축으로 이동한다고 설명한다¹. 이 관점에서 보면 하네스는 개인 설정 파일이 아니라 팀의 개발 인프라다.

팀은 먼저 공통 실행 구조를 정해야 한다. 에이전트가 어떤 문서를 읽고 시작하는지, 어떤 도구를 쓸 수 있는지, 어떤 작업은 승인 없이 진행할 수 없는지, 완료 전에 어떤 검증을 통과해야 하는지 명확히 해야 한다. 이 규칙은 구두 합의가 아니라 저장소 안에 남아야 한다. 에이전트가 접근할 수 없는 규칙은 없는 규칙과 같다.

하네스 변경도 코드처럼 다루기

프롬프트, 정책, 평가셋, 도구 인터페이스, 권한 설정은 모두 시스템 동작을 바꾼다. 그러므로 코드 변경처럼 리뷰하고 버전 관리해야 한다. "문구 조금 바꾼 것"처럼 보여도 에이전트의 판단 기준, 호출 가능한 도구, 출력 형식, 실패 처리 방식이 달라질 수 있다.

팀은 다음 항목을 정식 변경 대상으로 등록해야 한다.

• 시스템 프롬프트와 작업별 프롬프트

• AGENTS.md, CLAUDE.md 같은 에이전트 진입 문서

• 입력·출력 스키마와 검증기

• 도구 이름, 인자, 에러 메시지, 권한 등급

• 샌드박스 정책과 승인 규칙

• 평가 데이터셋과 통과 기준

• 관측 로그 스키마와 대시보드 지표

이 변경은 Pull Request로 올리고, 영향 범위를 적고, 최소한의 회귀 평가를 통과해야 한다. 예를 들어 "배포 스크립트 수정 도구"의 권한을 넓힌다면 보안 담당자의 리뷰가 필요하다. "요약 프롬프트"를 바꾼다면 기존 평가셋에서 누락률이나 환각률이 악화되지 않는지 확인해야 한다.

중요한 원칙은 단순하다. 모델을 직접 믿지 말고, 모델을 둘러싼 실행 구조를 믿을 수 있게 만들어야 한다. 하네스는 컨텍스트 전달, 도구 인터페이스, 계획 산출물, 검증 루프, 메모리, 샌드박스로 구성된 실행 발판이라는 설명도 같은 방향을 가리킨다². 이 발판이 바뀌면 제품의 동작도 바뀐다.

실패를 개인 실수로 끝내지 않기

AI 에이전트가 실패했을 때 가장 쉬운 반응은 "프롬프트를 잘못 썼다"라고 말하는 것이다. 하지만 팀 운영에서는 그렇게 끝내면 안 된다. 같은 실패가 다시 일어나지 않도록 하네스에 반영해야 한다.

예를 들어 에이전트가 개인정보가 포함된 로그를 그대로 외부 도구에 보냈다면, 다음 회고의 결론은 "주의하자"가 아니어야 한다. 입력 단계에서 개인정보 탐지기를 추가하고, 외부 전송 도구의 권한을 낮추고, 해당 사례를 보안 평가셋에 넣어야 한다. 에이전트가 존재하지 않는 API를 호출했다면 도구 설명을 고치고, 스키마 검증을 강화하고, 실패 로그를 관측 지표로 만든다.

좋은 회고는 사람을 탓하지 않고 시스템을 바꾼다. SRE 문화에서도 장애를 특정 개인의 실수로만 보지 않고, 지표와 포스트모템을 통해 재발 방지책을 만드는 태도가 중요하다고 설명한다³. 하네스 운영도 같다. 에이전트 실패는 비난할 사건이 아니라 하네스를 개선할 입력이다.

실패 회고는 다음 네 질문으로 충분하다.

1. 에이전트는 어떤 정보를 몰랐는가?

2. 어떤 도구나 권한이 너무 넓거나 좁았는가?

3. 어떤 검증이 있었다면 실패를 배포 전에 잡았는가?

4. 이 사례를 평가셋, 정책, 문서, 테스트 중 어디에 반영할 것인가?

이 루프가 반복되면 팀의 하네스는 점점 강해진다. 반대로 실패가 대화창 안에서만 소비되면 조직은 매번 같은 비용을 다시 낸다.

역할과 소유권 다시 나누기

하네스 엔지니어링은 "AI 담당자 한 명"에게 맡길 일이 아니다. 여러 역할이 함께 소유해야 한다. 개발자는 코드만 작성하는 사람이 아니라 에이전트가 일할 환경을 설계하는 사람이 된다. 플랫폼 엔지니어는 실행 환경, 샌드박스, 도구 게이트웨이, 관측 기반을 제공한다. 보안 담당자는 권한 경계, 승인 흐름, 감사 로그, 개인정보 정책을 관리한다. 데이터·평가 담당자는 평가셋과 품질 지표를 유지한다. 도메인 전문가는 의도, 예외, 금지 범위를 정의한다.

소유권을 나누면 책임이 흐려지는 것이 아니라 더 선명해진다.

이 구조에서는 에이전트도 팀의 작업자처럼 취급된다. 사람에게 필요한 온보딩 문서, 실행 절차, 권한 정책, 품질 기준은 에이전트에게도 필요하다. 차이는 에이전트가 사람보다 더 빠르게, 더 많이 실행한다는 점이다. 그래서 규칙은 더 명확해야 하고, 검증은 더 자동화되어야 한다.

릴리스 기준을 측정 가능하게 만들기

AI 기능의 배포 기준은 "잘 동작하는 것 같음"이어서는 안 된다. 느낌은 데모에는 충분하지만 운영에는 부족하다. 릴리스 기준은 측정 가능한 숫자와 통과 조건으로 바뀌어야 한다.

팀은 최소한 다음 지표를 배포 게이트로 사용할 수 있다.

• 핵심 태스크 성공률

• 회귀 평가 통과율

• 출력 형식 오류율

• 환각 또는 근거 없는 응답 비율

• 수동 개입률

• 도구 호출 실패율과 재시도율

• 평균 지연시간과 비용 한도

• 권한 위반 시도 여부

• 보안·개인정보 검토 통과 여부

• 롤백 가능성과 감사 로그 완전성

예를 들어 고객 응대 에이전트라면 "정답률 90% 이상"만으로는 부족하다. 개인정보 노출 0건, 허용되지 않은 환불 안내 0건, 수동 전환율 15% 이하, 평균 응답 비용 일정 한도 이하처럼 운영 조건이 함께 있어야 한다. 코드 에이전트라면 테스트 통과율, 린트 통과율, PR 되돌림 비율, 사람이 수정한 비율을 함께 봐야 한다.

DevOps 도입 사례에서도 코드 검증, 여러 환경, 모니터링, 자동화된 피드백은 안정적인 제품 전달의 핵심 요소로 다뤄진다⁴. AI 하네스의 릴리스도 같은 원칙을 따른다. 다만 검증 대상에 프롬프트, 정책, 도구 호출, 모델 응답이 추가될 뿐이다.

협업 모델: 함께 하네스를 키우는 방식

하네스는 한 번 만들고 끝나는 산출물이 아니다. 제품, 코드베이스, 모델, 보안 요구가 변하면 계속 바뀐다. 따라서 협업 방식도 "AI 도구 도입 프로젝트"가 아니라 "하네스 운영 체계"에 가까워야 한다.

효과적인 팀은 보통 작은 범위에서 시작한다. 반복적이고 실패 비용이 중간 정도인 업무 하나를 고른다. 입력과 출력을 계약으로 정의한다. 도구 권한을 최소화한다. 평가셋을 만들고, 실패를 관측한다. 몇 주 동안 로그를 모은 뒤 반복 실패를 정책, 테스트, 문서, 도구 제약으로 옮긴다. 그다음 업무 범위를 넓힌다.

회의 방식도 달라져야 한다. 주간 회고에서는 "AI가 잘했는가"가 아니라 다음을 본다.

• 어떤 태스크에서 수동 개입이 많았는가?

• 어떤 도구 호출이 자주 실패했는가?

• 새로 평가셋에 넣어야 할 실패 사례는 무엇인가?

• 권한 정책이 너무 느슨하거나 너무 빡빡한 곳은 어디인가?

• 비용이 급증한 작업 유형은 무엇인가?

이 논의에 개발자만 참여하면 부족하다. 도메인 전문가는 정답과 허용 범위를 알려준다. 보안 팀은 위험한 실행 경로를 막는다. 플랫폼 팀은 도구와 로그를 안정화한다. 평가 담당자는 체감 품질을 숫자로 바꾼다. 이렇게 해야 AI 에이전트가 개인의 장난감이 아니라 조직의 동료가 된다.

하네스 엔지니어의 미래

모델 성능은 계속 좋아질 것이다. 더 긴 컨텍스트를 다루고, 도구를 더 정확히 쓰고, 계획도 더 잘 세울 것이다. 그렇다면 하네스 엔지니어링은 사라질까? 그렇지 않다. 오히려 더 중요해진다.

이유는 간단하다. 모델이 강해질수록 더 중요한 일을 맡게 되고, 더 중요한 일을 맡을수록 실행 구조의 품질이 중요해진다. 성능 좋은 모델도 잘못된 컨텍스트를 받으면 잘못 판단한다. 강력한 도구를 제한 없이 받으면 더 큰 사고를 낼 수 있다. 검증 없는 자동화는 빠른 만큼 빠르게 실패를 확산한다.

미래의 경쟁력은 "어떤 모델을 쓰는가"에서 "모델이 일하는 시스템을 얼마나 신뢰 가능하게 설계했는가"로 이동한다. 하네스 엔지니어는 이 전환의 중심에 있다. 이 역할은 프롬프트 작성자보다 넓고, 플랫폼 엔지니어보다 AI 실행 루프에 더 가깝고, SRE보다 개발 단계의 자율 실행 구조에 더 깊이 관여한다.

좋은 하네스 엔지니어는 모델을 맹신하지 않는다. 동시에 모델을 과소평가하지도 않는다. 대신 모델이 잘할 수 있는 일을 더 많이 맡기기 위해 컨텍스트, 도구, 검증, 메모리, 권한, 관측 가능성, 오케스트레이션을 설계한다. 인간은 모든 출력을 일일이 검사하는 자리에서 벗어나, 에이전트가 안전하게 일하는 시스템을 만드는 자리로 이동한다.

이 책의 결론도 여기에 있다. AI 에이전트를 신뢰 가능한 동료로 만들려면 더 좋은 프롬프트만으로는 부족하다. 팀의 규칙, 책임, 릴리스 기준, 실패 회고, 운영 문화가 함께 바뀌어야 한다. 하네스 엔지니어링은 AI를 믿기 위한 기술이 아니다. AI가 틀려도 조직이 배우고, 막고, 고치고, 다시 더 안전하게 위임할 수 있게 만드는 공학이다.

참고

¹Harness engineering: leveraging Codex in an agent-first world

²Awesome Harness Engineering

³SRE - #1 SRE/DEVOPS의 개념과 SRE는 무엇을하는가?

⁴DevOps Adoption at Harness