Loading summary...
하네스 엔지니어링에 대한 댓글 질문을 받고, 주변에 쉽게 설명하는 사람이 많지 않아 직접 실행하며 알아본다. 기본 개념부터 잡아갈 예정.
AI에게 잘 일할 환경을 설계해 주는 것. 프롬프트 엔지니어링과는 반대되는 개념.
GPT나 클로드에게 질문을 던져 원하는 결과를 얻는 방식. AI를 도구처럼 사용하지만, 매번 맥락을 설명해야 하고 일관된 결과를 얻기 어렵다.
AI가 어떻게 일해야 하는지 환경을 설계하여 구조적으로 일관된 품질의 결과물을 얻는 방식.
바쁜 팀장이 AI에게 일을 위임할 때, 매번 지시하는 대신 회사/팀의 규칙, do & don't 등을 설명하여 AI가 더 잘 일할 수 있도록 하는 것. 작업 지시서, 검증 기준까지 합의하면 AI는 팀원의 말을 더 잘 알아듣고 일관되게 일할 수 있다.
하네스 엔지니어링은 LLM에게 업무를 위임하기 위해 규칙, 작업 구조, 검증 방법, 실행 흐름을 미리 묶어서 제어하는 것이다.
네 가지 구성 요소:
작업을 어디서 할지 장소를 정해줘야 한다. 로컬 폴더, 깃허브 연동 등을 정하고, 참고 자료, 헌법, 작업 문서 등이 모두 들어가 있어야 한다. AI는 여기서 모든 맥락을 참조한다.
오픈 AI 팀은 빈 레포지토리에서 시작하여 세 명의 엔지니어가 5개월 동안 100만 줄의 코드를 짰는데, 사람이 직접 쓴 코드는 단 한 줄도 없었다. 하네스 엔지니어링으로만 작업을 해냈다.
하네스 엔지니어링은 규칙, 작업 구조, 검증 기준, 실행 흐름, 작업 저장소/참고 자료 등을 통해 새로운 팀원을 만드는 과정이다.
하네스 엔지니어링 문서는 AI와 합의하면서 작성해 나가면 더 정교하고 자세하게 만들 수 있다.
프롬프트 엔지니어링은 그때그때 잘 요청하는 기술, 하네스 엔지니어링은 AI가 더 잘 일할 수 있도록 일하는 환경 자체를 설계하는 작업이다.
AI에게 저장소에서 어떻게 일할지, 문서 구조, 팀 규칙, 코드 제어 등을 알려준다. 프로젝트 전체에 적용되는 기반을 정의한다.
프로젝트별로 만들고 싶은 앱과 서비스에 대해, 어떤 기능과 경험을 줘야 하는지, AI가 어떻게 판단할지, 해당 프로젝트에 적용되는 규칙은 무엇인지 정의한다.
개발자는 레포지토리 하네스부터 짜지만, 처음 접하는 사람은 만들고 싶은 앱부터 상상하는 기념적 방식으로 접근하는 것이 좋다.
오픈 AI의 하네스 엔지니어링 아티클 페이지에서 레포지토리 지식 기록 시스템 구조를 가져온다.
클로드에게 앱 구조에 대한 의견을 묻고, 우선순위, 설계 포인트 등을 함께 의논하며 하네스 초안을 그려간다.
에이전트 MD, 아키텍처 MD, 디자인, 실행 플랜, 제너레이터, 레퍼런스, 문서 파일 등으로 구성.
작성한 문서를 클로드에게 검토시켜 논리적 일관성, 모순 여부 등을 확인한다.
클로드와 협업하여 만든 마크다운 문서를 아티팩트 형태로 다운로드한다.
다운로드한 파일을 특정 폴더에 넣고, 클로드 코드에서 해당 폴더를 열어 코덱스에게 레포지토리 덕스 엔지니어링 구현에 대한 이야기를 나눈다.
헌법은 AI에게 통째로 맡기지 말고 함께 만들어야 한다.
사주 하네스 프랙티스라는 이름으로 폴더를 깃허브에 올려 공유한다.
AI에게 시니어 개발자, 소프트웨어 엔지니어, 보안 담당자, 초보 개발자 관점에서 문서를 평가하게 한다. 랭킹 기준을 제시하고 점수로 평가하게 하면 더 정교하게 평가한다.
수정 후에도 같은 문제가 남아있을 때, 명확한 기준을 제공한다.
파일을 깃을 통해 백업한다. AI가 자율적으로 일할수록 깃 버전 관리가 더 필요하다.
AI에게 아직 전달되지 않은 안목지를 전달해야 한다. 예를 들어, 교육용 앱은 코드가 짧고 읽기 쉬워야 한다는 것을 명시해야 한다.
그라디오 라이브러리를 사용하여 파이썬으로 만든 결과물을 웹에서 쉽게 확인한다. 코덱스가 써 준 코드를 통해 테스트를 돌려보고, 코드를 수정하고, 사이트를 빌드하고, 문서를 갱신하고, 결과를 확인한다.
사주 팔자 분석기가 웹에 나타나고, 생년월일을 입력하여 분석 결과를 확인한다.
결과를 확인하고 피드백을 거쳐 재검증, 수정하는 사이클을 반복한다.
AI를 유능하다고 믿고 방임하면 원하는 결과물을 얻기 어렵다. 하네스 엔지니어링은 조직 관리와 더 가깝다.
지시형 상사: 모든 것을 설명하여 AI가 더 나은 방법을 찾을 공간이 없다. 방임형 상사: AI를 믿고 맡기지만, 명확한 목표와 기준이 없어 결과물이 만족스럽지 않다.
수요자가 결과물에 대한 명확한 상을 가지고, 대리인에게 자율성과 방법론에 대한 책임/권한을 보장하는 것이 위임이다. 목표는 구체적이어야 하고, 서로 간의 합의를 통해 더 많은 맥락을 부여해야 한다.
피터 드러커의 매니지먼트 바이 오브젝티브. 상사와 부하 직원이 함께 목표를 설정하고, 달성 여부로 성과를 평가하는 방식. 목표 설정, 팀/개인 단위 쪼개기, 개인 목표 합의, 실행 및 모니터링, 성과 평가 단계를 거친다.
하네스 엔지니어링은 테크지만 본질은 경영학이다.
내 수요에 대해 알고 큰 목표를 정한 후, AI와 함께 지식을 나누고, 일을 쪼개고, 구체적 목표를 합의하고, 중간중간 모니터링하며 기준에 맞게 평가하고 반복하여 최종 통과시키는 것이 필요하다.
AI는 나를 조직으로 만든다.
기존 조직은 안목지가 사람 머릿속에 분산되어 있어 사람이 나가면 지식이 사라졌지만, AI는 인지적인 병목을 제거하여 한 사람이 팀의 아웃풋을 낼 수 있게 한다.
안묵지를 저장하고 팀을 구성하는 방법. AI에게 역할을 부여하여 조직을 만든다.
하네스 엔지니어링은 조직의 힘으로 더 많은 성과를 낼 수 있도록 하는 툴이다.
헌법, 작업 구조, 검증, 실행 루프를 통해 코어 가치와 원칙을 외부화하고, 판단 패턴을 AI가 재사용 가능한 형태로 만들어주고, 검증 기준을 기계가 대신 집행하게 하고, 매 작업마다 안묵지가 저장소에 축적될 수 있도록 한다.
매 작업이 저장소에 축적되고, 헌법과 작업 구조를 진화시키고, 검증 기준을 정교화하고, 실행 루프가 더 빠르게 돌아갈 수 있다. 51번째 작업의 출발점은 50번째보다 훨씬 더 월등하게 된다.