라벨이 하네스 엔지니어링인 게시물 표시

프롬프트 엔지니어링 / 에이전트 / 하네스 — 무엇이 다른가 (LLM 워크플로우 용어 지도)

이미지
프롬프트 엔지니어링 / 에이전트 / 하네스 — 무엇이 다른가 (LLM 워크플로우 용어 지도) Claude한테 일 시키는 방법은 세 가지로 나뉘는 것 같다. 한 마디 잘 묻는 프롬프트 엔지니어링 (Prompt Engineering, 줄여서 PE). 도구를 쥐어준 에이전트 (Agent). 그 위에 운영 틀을 얹은 하네스 (Harness). 셋 다 “AI 활용”으로 묶이지만 무게가 다르다. 어디에 어떤 도구가 맞는지 헷갈렸던 정리를 여기에 적어둔다. 요약 : PE는 한 번의 입력 최적화, 에이전트는 도구를 들고 알아서 도는 AI, 하네스는 그 둘을 어떻게 운영할지 정하는 메타 틀이다. 작은 → 큰 순서로 쌓인다. 5/3 글 에서 다룬 하네스의 내부 구조 는 이 위계 지도의 마지막 칸에 해당한다. 이 글은 Claude Code를 매일 쓰면서 PE·에이전트·하네스라는 단어가 다 비슷해 보였던 사람을 위해 썼다. 입문자가 아니라 한 번씩 다 써본 사람의 정리에 가깝다. 이런 적 있다면 이 글이 도움이 된다 ChatGPT에 비슷한 작업을 시킬 때마다 거의 같은 프롬프트를 매번 다시 입력한 적이 있다. Claude Code가 한 작업에서 5분 만에 토큰 한도를 다 쓴 걸 본 적이 있다. 같은 종류의 실수가 작업마다 또 반복되는 걸 보고 어떻게 멈추지 가 답답했던 적이 있다. 세 가지 모두 같은 원인이다. 셋이 같은 단계가 아니다. 한 번의 입력 최적화로 풀 일, 도구를 쥐어줘야 풀 일, 운영 틀로만 풀 일이 다 섞여 있다. 위계를 잡으면 어디에 시간을 쓸지 가 분명해진다. 한 줄 정의로 시작한다 단계 한 줄 정의 비유 PE (프롬프트 엔지니어링) 한 번의 질문으로 원하는 답을 받아내는 기법 신입에게 일을 한 번 시키는 법 에이전트 도구를 들고 알아서 돌아가는 AI 권한을 받은 1년 차 하네스 에이전트·프롬프트·문맥을 굴리는 운영 틀 회사의 매뉴얼과 평가 체계 자체 작은 단위가 큰 단위에 ...

하네스 엔지니어링 측정 2편 — Claude에 AGENTS.md 명시 인용했더니 fail-fast가 강해졌다

1편(어제)에서 N=1로 측정해서 결론을 냈다. “Codex가 fail-fast 약하다”가 아니라 “AGENTS.md 비우면 Codex도 Claude도 똑같이 약하다”였다. 지적이 들어왔다. N=1은 우연일 수 있다. Claude에 AGENTS.md 명시 인용을 직접 해본 적은 없었다. 12회 측정해서 다시 확인했다. 결론은 더 단단해졌다. 그리고 1편이 놓친 변수 하나가 새로 보였다. 요약 : Codex × Claude × 하네스 0/강제 4 condition을 각 3회씩 12회 측정. 모델 효과는 거의 0(가로축 1.0 vs 1.0, 2.83 vs 2.5), 하네스 효과는 큼(세로축 1.0 → 2.5+). Claude도 AGENTS.md를 prompt에 명시 인용하면 fail-fast 1.0 → 2.5로 올라간다. 단 1편의 Claude 채점 “중”은 prompt position 효과(메인 세션 system prompt 자동 로드)였을 가능성이 새로 보였다. 1편이 명시한 5가지 한계 중 통제한 3가지 측정 1편 본문 끝에 한계 5가지를 적었다. 그 중 2편에서 통제 가능한 것은 3가지였다. Sampling 우연 미통제 (N=1) → 12회 측정으로 분산 확인 Prompt position 미분리 → C3 격리 환경 추가로 부분 분리 Claude에 AGENTS.md 명시 인용 미측정 → C4 condition으로 직접 측정 나머지 2가지(컨벤션 vs 코드 품질, 일반화)는 이번에도 미해소다. 측정 setup, 4 condition × 3회 = 12회 같은 명세 verify_published_post() 를 4 condition으로 각 3회씩 측정했다. Condition 모델 하네스 C1 Codex 없음 (AGENTS.md 비움) C2 Codex AGENTS.md 자동 로드 C3 Claude spec만, 격리 Task agen...