하네스 엔지니어링 - 노트

https://www.youtube.com/watch?v=5buNm0pA1mg

 

 

---

[AI 시대] 엔지니어의 새로운 역할: 하네스 엔지니어링(Harness Engineering)

이제 엔지니어는 단순히 코드를 생산하는 사람이 아닙니다. AI 에이전트가 최상의 성능을 낼 수 있도록 환경을 설계하는 '하네스 엔지니어(Harness Engineer)'로 진화하고 있습니다.

1. 패러다임의 변화: 코드 생산자에서 환경 설계자로

기존의 방식이 사람이 직접 문제를 찾고 수정하는 반복 작업이었다면, 앞으로는 에이전트 중심의 자동 개선 루프를 설계하는 것이 핵심입니다.

🔄 워크플로우 비교

 

---

2. 좋은 하네스(Harness)를 구축하는 3가지 축

하네스란 모델을 둘러싼 모든 환경(컨텍스트, 도구, 루프, 검증 등)을 의미합니다.

① 컨텍스트(Context): 양보다 질

컨텍스트 윈도우는 한정된 예산과 같습니다. 무조건 많이 넣기보다 가장 가치 있는 정보를 엄선해야 합니다.

구분주요 내용

필수 주입 (초기)	최종 목표, 코딩 컨벤션, 아키텍처, 보안 규칙(금지 영역)
필요 시 호출 (도구)	파일 상세 내용, 로그/에러 트레이스, 외부 API 문서, 테스트 결과

• Tip: docs/exec-plan 폴더를 만들어 에이전트의 실행 계획을 기록으로 남기면 나중에 회고하기 좋습니다.

② 도구 및 환경 설계 (Tool & Environment)

에이전트에게 기본 도구 외에도 성능이 검증된 전문 도구를 쥐어주어야 합니다.

• 웹 서치: 기본 도구보다 성능이 좋은 Tavily, Exa 등 활용
• 에러 메시지: 에러는 수정의 지침이 되므로 반드시 에이전트에게 전달
• 안전성: 승인 기반 루프를 통해 에이전트가 임의로 시스템을 변경하지 못하도록 제어

③ 평가 기반 개선 (Evaluation)

느낌이 아닌 실제 데이터로 개선해야 합니다.

• Evaluation Harness 구성: 작업 정의(Task), 반복 실행(Trial), 채점 기준(Grader), 기록(Transcript), 결과 집계(Outcome)
• 주의: 에이전트가 작업한 동일한 세션 내에서 자기 평가를 시키면 편향이 발생하므로 피해야 합니다.

---

3. 멀티 에이전트 전략: Claude와 Codex의 협업

각 모델의 강점을 살려 교차 검증 환경을 구축하면 품질이 비약적으로 상승합니다.

 

• Claude: 코드 작성 능력 우수 (페어 프로그래머 역할)
• Codex: 계획 수립, 컨텍스트 탐색, 루프 컨트롤 및 검증에 강점

---

4. 팀을 위한 하이브리드 운영 패턴

개인의 생산성을 넘어 팀 전체의 에이전트 활용 능력을 높이는 방법입니다.

1. 그라운드 룰 레포: 아키텍처, 보안 정책 등 모든 프로젝트가 따라야 할 공통 규칙 정의
2. 스킬 공유 레포: 유용한 프롬프트나 에이전트 스킬을 팀원과 공유하고 서로 피드백
3. 코드로 강제화: 문서로만 남기지 말고 Hook, CI 등을 통해 규칙이 반드시 실행되도록 설정

---

결론: 측정하고 평가하며 개선하라

측정하지 않으면 평가할 수 없고, 평가하지 않으면 개선할 수 없습니다. Langfuse와 같은 플랫폼을 활용해 에이전트와의 대화 세션을 기록하고, 나 자신의 프롬프트와 하네스 설계를 지속적으로 고도화해 나가야 합니다.

미래의 개발자는 코드를 직접 치는 시간보다, 에이전트가 일할 환경을 멋지게 설계하는 시간을 더 많이 갖게 될 것입니다.

---

 

 

[수기 작성 노트]

 

엔지니어의 역할은

코드 생산자가 아니고

 

-> Agent 가 일하는 환경을 설계하는 사람

루프, 워크플로우 설계, 작업 방향 지시, 도구를 통해 실행능력을 쥐어주는 것, 피드백의 역할

 

 

 

기존

사람이 프롬프트 작성

모델이 코드 작업

사람이 문제를 찾아 다시 설명

반복된 수정

 

자동 개선 루프

최종 목표를 전달

중간 검증해야하는 기준 설정

에이전트가 탐색, 코드, 수정

자동 검증, 재시도

최종 목표를 이루었다고 판단하는 순간 사람에게 전달

사람이 판단

 

 

 

하네스를 잘 구축하는 방법

 

1. 컨텍스트 : 가장 좋은 걸 엄선해서 넣어야한다

• 필수 : 최종 목표 - 코딩 컨벤션 - 아키텍쳐 - 금지 영역, 보안 규칙
• 필요할때만 : 파일 내용 (필요시만 읽기) - 로그, 에러 트레이스 - 외부문서, API 레퍼런스 - 테스트 실행 결과
  
• 실행계획 문서 (docs/exec-plan : 어떤 실행 계획을 했었는지 기록이 필요)

2. 도구

• Tool & Environment Design 
•  에러메시지 꼭 전달 -> 수정의 지침

3. 평가

• - Evaluation Based Improvement
  - 느낌으로 개선 아니고, 실제 결과물의 평가를 통한 개선
  - Evaluation Harness
  - Task : 평가할 작업 정의
  - Trial : 여러번 실행으로 분산 감소
  - Grader : 자동/수동 채점 기준
  - Transcript : 실행과정 기록
  - Outcome: 결과 집계 및 비교
  - 자기 평가의 함정
  - 최악: 여태 작업한 세션 안에서, 평가까지 시키는 것

 

좋은 하네스의 설계원칙

• - 단순한 구성부터
  - 길이보다 퀄리티
  - 검증을 하네스에 내장
  - 하네스 세팅을 계속 재검토
  - 하네스의 각 구성요소는 모델의 한계를 가정하고 만든것
  - 모델이 좋아지면 불필요한 하네스 요소가 있을 수 있음

 

어떤 모델 어떻게? 

(클로드 : 코드 작업 강점 / 코덱스 : 계획 검증 루프에 강점0

 

클로드, 코덱스 같은 작업에 대한 공동 계획

클로드 - 코드 작성 

코덱스 - 코드 검증, 수정

클로드 - 코드 다시 검증

코덱스 - 코드 검증 수정

 

-> 교차 검증의 이점 : 다른 모델, 다른 시각

 

 

하이브리드 운영 패턴

• - 우리 회사에서 어떤 레포를 만들든, 무조건 따라야하는 그라운드룰
  - 아키텍처, 코딩 컨벤션, 보안 정책, 리뷰 가이드라인 등
  - 새로운 프로젝트가 만들어지면 항상 이 레포를 따르도록
  - 여러가지 재사용 스킬 공유 레포지토리
  - 내가 올린 스킬이 팀원의 에이전트가 반박/칭찬등
  - 강제해야 하는 것들은 코드로 정의
  - Hook, CI, 등

 

 

측정하고 평가, 평가하고 개선

• Langfuse 
  • 내가 쓰는 모든 프롬프트를 평가
    - Agent 를 다루는 나 자체를 개선