AI 코딩 어시스턴트의 '조용한 부패'를 막는 방법: Harness Engineering
AI 코딩 어시스턴트가 생성한 코드는 컴파일되고 테스트를 통과하지만, 시간이 지나면서 팀의 규칙과 아키텍처 결정을 조용히 무너뜨릴 수 있습니다. Birgitta Boeckeler가 제안한 'Harness Engineering'은 이러한 문제를 테스트 하니스처럼 다루어, AI 코드 생성 주변에 결정적 도구, 에이전트 기반 리뷰, 주기적 엔트로피 점검을 배치합니다. 이 문서는 세 가지 구성 요소(컨텍스트 엔지니어링, 아키텍처 제약, 가비지 컬렉션)와 '살아있는 하니스'의 자기 참조적 특성, 그리고 제약이 비검증에서 결정적으로 성숙해가는 '점진적 강화' 원칙을 설명합니다. 또한 이 플러그인이 내부/중간/외부 루프를 통해 이를 구현하는 방법과, 에이전트가 인간의 판단을 대체하지 않고 증폭시키는 설계 철학을 다룹니다.
테스트 하니스는 프로그래머를 신뢰하지 않습니다. 그것은 검증합니다.
HN 토론
42- ricardobeat
harness engineering이라는 용어는 Birgitta Boeckeler가 martinfowler.com에 쓴 기사에서 나온 것이 아닙니다. 이 용어는 몇 달 전 Mitchel Hashimoto가 자신의 블로그 게시물 'My AI adoption journey' [1]에서 처음 사용했고, 일주일 후 OpenAI가 바로 채택했습니다 [2]. 또한 이 텍스트는 전적으로 AI가 생성한 것일 뿐만 아니라, 우리 인간이 아닌 다른 에이전트가 읽도록 만들어진 것이라는 점도 주목할 만합니다.
- iTokio
새로운 기술이 등장하고 사람들이 그 기술을 이해하려고 노력하는 과정을 지켜보는 것은 흥미롭습니다.
저는 개인적으로 AI 주변에서 사용되는 많은 단어들, 예를 들어 harness, SKILLS, agents, RAG 같은 단어들은 만들어낸 단어이거나 그에 가깝다고 생각합니다. 즉, 깊은 의미를 담고 있지 않은 단어들이라는 뜻입니다. 사람들은 종종 사후에 그 단어들에 의미를 부여하려고 하지만요.
그것들은 그저 유행하는 단어들로, 사람들이 새로운 지식을 주장하거나 제품을 마케팅하기 위해 사용하기 좋을 만큼 차별화된 단어들입니다.
하지만 추상적인 맥락에서 harness 대신 AI 도구라는 표현을 쓸 수도 있고, 더 구체적인 사용 사례(에이전트 루프, CLI, IDE 등)에 대해서는 더 정확한 용어를 사용하는 것이 더 나을 것입니다.
논문들이 관심을 끌기 위해 경쟁하던 시절에는 재미있는 게임이었지만, 이제는 검증된 기술이 되었으니 더 정확하고 의미 있는 단어를 찾을 수 있기를 바랍니다.
- gardnr
이 글의 원본은 다음과 같습니다: https://martinfowler.com/articles/harness-engineering.html
그리고 원작자가 이에 대해 이야기하는 팟캐스트는 여기 있습니다: https://open.spotify.com/episode/4FxEdjXldNhoh67KYVmbDu
- davedx
이 부분이 관련이 있어 보입니다. 그들은 자신들의 HARNESS.md 문서와 AGENTS.md 문서의 차이점을 명확히 설명합니다. 실제로 흥미롭습니다: https://habitat-thinking.github.io/ai-literacy-superpowers/p...
- lacoolj
이게 AI가 생성한 것이라고 말하는 것은 아니지만, 매우 밀도가 높아서 쉽게 정보를 얻을 수 있는 글로는 읽히지 않습니다.