Speaker A
그놈의 하네스, 하네스, 하네스. 그 하네스 엔지니어링이 도대체 뭔데? 무슨 프롬프트 엔지니어링부터 시작해 가지고 뭐 컨텍스트 엔지니어링, 이젠 뭐 하네스 엔지니어링까지. 여러분들 너무 복잡하시죠? 제가 이게 뭔지 싹 다 정리를 해 드리도록 하겠습니다.
하네스 엔지니어링의 개념부터 실전 적용법까지, AI 개발 생산성 향상을 위한 핵심 전략을 상세히 설명합니다.
Key Takeaways
- 하네스 엔지니어링은 AI가 회사 규칙을 벗어나지 않도록 제어하는 필수 기술이다.
- 로그와 가시성 확보를 통해 AI가 스스로 문제를 인지하고 수정할 수 있게 한다.
- 컨텍스트를 점진적으로 제공하여 AI의 이해도를 높이고 실수를 줄인다.
- CICD 강제를 통해 AI가 규칙 위반 시 자동으로 제동을 걸어 신뢰성을 확보한다.
- 실제 사례와 프롬프트 설계로 하네스 엔지니어링 적용 방법을 구체적으로 배울 수 있다.
What the video covers
- 하네스 엔지니어링이란 AI가 실수하지 않고 회사 규칙 내에서 일하도록 제어하는 기술이다.
- 프롬프트 엔지니어링과 컨텍스트 엔지니어링의 개념과 차이점을 설명한다.
- 오픈AI의 사례를 통해 하네스 엔지니어링이 AI 개발 생산성 병목을 해결하는 방법을 소개한다.
- AI가 스스로 테스트하고 피드백할 수 있도록 로그 시스템과 가시성 확보가 중요하다.
- 컨텍스트를 한꺼번에 주기보다 점진적으로 공개하는 목차화 전략을 활용한다.
- CICD 강제 적용으로 AI가 규칙을 어길 경우 자동으로 에러를 발생시키는 시스템 구축이 핵심이다.
- 실제 하네스 엔지니어링 시스템 구축 예제를 통해 구체적인 구현 방법을 공유한다.
- AI가 작업 계획을 세우고 워크트리에서 구현하는 단계적 개발 방식을 강조한다.
- 인간 개입 없이 AI가 자율적으로 개발과 테스트를 반복하도록 하는 목표를 설명한다.
- 하네스 엔지니어링은 AI 활용의 복잡성을 줄이고 신뢰성을 높이는 최신 기술이다.
Full Transcript — Download SRT & Markdown
Speaker A
그리고 여러분들이 이 하네스 엔지니어링을 어떻게 실제로 도입을 하는지, 그 실전 예시까지 제가 그냥 싹 다 보여 드리도록 하겠습니다.
Speaker A
그래서 여러분들, 이런 뭐 용어 가지고 쫄지 마, 알겠지? 일단 우리가 AI 왜 씁니까? 우리가 결국에 AI로 하고 싶은 게 뭐야? 이거에 대해서 여러분들이 생각을 해 보시면요, 이 모든 엔지니어링이 쉬워집니다. 어, 우리가 결국에 AI로 지금 하고 싶은 게 뭐야? 어, 결국에는 나 대신에 돈 벌어다 주고, 나 대신에 겨울 방학 숙제해 주고, 나 대신에 여름방학 숙제해 주고, 나 원하는 모든 걸 다 해 주는 그런 걸 만들고 싶은 거잖아. 어, 나 대신에 모든 걸 아는 어떤 휴먼 로봇을 만들고 싶은 거잖아. 우리가 결론적으로 AI로 하고 싶은 이거란 말이에요. 근데
Speaker A
이렇게 하려면 어떻게 해야 되겠어요? AI가 내 뇌속에 들어와서 내가 하고 싶은 게 뭔지 다 알아 가지고 알아서 알 딱 갈센으로 해 주면 너무 좋겠지만 사실 아직 거기까지는 기능이 되지가 않잖아요. 그죠? 어, 우리에게 주어진 건 뭐다? 어떤 뭐 오픈 AI라던가, 뭐 클로드에서 주어지는
Speaker A
어떤 어떤 AI 모델, 자, 이거 써 버려 하고 주면은 우리가 이 친구를 잘 요리를 해 가지고 결국엔 나 대신에 일할 수 있는 그런 우리가 울트라 휴먼을 우리가 잘 만들어야 되는 거잖아요. 그죠? 우리 모든 개발자들이 AI한테 어떻게 하면은 내 개입 없이 어 훈련을 잘 시켜 가지고
Speaker A
모든 일을 나 대신 할 수 있을까? 우리가 지금 그거 연구하고 있는 거예요. 전 세계 사람들이 그거 연구하고 있어요. 자, 그래서 나온 게 뭐예요? 첫 번째 바로 프롬프트 엔지니어링입니다. 내가 개떡같이 말하면은 AI가 못 알아듣잖아.
Speaker A
그래가지고 최대한 자세하게 설명하는 거. 어, 나는 이거 만들고 싶은데 여기는 요런 게 필요하고 요런 걸 위해서는요 정보를 봐야 되고 이렇게 최대한 자세하게 설명을 해야 AI가 잘 알아듣고 내가 원하는 결과물을 그나마 가져오더라. 그래서 나온 게 바로 프롬프트 엔지니어링입니다. 바로 말을 잘하는 기술이죠. 자, 우리가 이
Speaker A
프롬프트 엔지니어링을 배우니까 다음에 나온 개념이 바로 컨텍스트 엔지니어링이에요. 우리가 이게 일을 해 보니까요, 우리가 단순히 말한 말만 잘한다고 되는 게 아니라 이 일의 히스토리를 알아야 잘하더라라는 거예요. 우리가 어떤 신입 사원보다 그래도 뭐 6개월 정도 일한 인턴이 훨씬 나은 이유가 뭐예요? 바로 우리
Speaker A
회사의 히스토리를 알잖아. 우리 회사가 어떻게 돌아가는지 6개월 동안 봤으니까 알잖아. 그렇죠? 그래서 우리가 6개월 인턴을 더 선호하기도 합니다. 어, 그래서 우리가 어떻게 이 AI라는 신입한테 우리 회사의 히스토리, 우리 회사의 컨텍스트를 잘 전달을 할까? 어떻게 하면은 얘가 어 매일매일 리셋이 되는 그런 신인
Speaker A
말고 어 우리 일한 히스토리를 다 알고 있고 내가 어 그 문서 가져와, 그럼 알아서 가져오고, 어 그렇게 우리가 어떻게 하면 히스토리를 잘 전달할 수 있을까에 대해서 연구를 하는 게 컨텍스트 엔지니어링입니다. 자 이제 또 신입한테 중요한 게 뭐냐면요.
Speaker A
어 이제 좀 프롬프트 잘 쓰면은 잘 알아듣고 일 히스토리도 좀 저장을 해서 잘 알아들어요. 그래서 AI가 좀 머리가 커졌어. 그래서 보니까 이제 막 자기가 만들고 싶은 대로 막 미친 듯이 만드는 거예요. 그러다 보니까 뭐예요? 이 휴먼들이 어 이러면은 이렇게 일하라는 거
Speaker A
아니었는데 이렇게 너 마음대로 막 꿈을 펼치라는 거 아니었는데 그래 가지고 중간중간에 개입을 해서 막 확인을 하게 됩니다. 어 테스트해서 어 이거 이상하게 만들었는데 이거 고쳐 줘. 어 이거 이상한데 이거 고쳐 줘. 계속 그런 작업이 막 들어가게 된단 말이에요. 우리 인간이
Speaker A
계속 신입이 갖고 온 결과물을 확인하고 빠꾸시키고 확인하고 빠꾸시키고 이걸 계속 하고 있단 말이에요. 그러다 보니까 이제 생긴 게 뭐냐? 아 AI가 스스로 일은 어느 정도 잘하더라. 근데 AI가 실수를 좀 안 하게끔 제발 우리 회사 그 기약 바운더리 안에서 좀 활동하게끔
Speaker A
우리가 이 바운더리를 만들어 줘야지 안 그러면은 내가 매번 실수 지적해야 되더라 이거예요. 그래서 나온 게 바로 뭐다? 하네스 엔지니어링이에요.
Speaker A
하네스가 뭐예요? 이 몸에 이렇게 딱 차는 그런 거 있잖아요. 우리가 이제 강아지 산책시키면 쓰는 그 하네스 있잖아요. 그거를 딱 설정을 해 놓는 거예요. 야, 너 막 이상 문서 이상하게 만들지 말고 우리 회사는 빨간색을 써야 되니까 너 무조건 빨간색 써야 돼. 라고 하는 게 하네스
Speaker A
엔지니어링입니다. 근데요, 우리가 말로만 말로만 야 빨간색 써라고 말하면은 이게 AI가 알아듣습니까? 가끔은 어 나는 기억을 못 합니다 하고 자기 마음대로 만들어 버리잖아요. 그죠? 그래서 우리가 단순히 뭐뭐 하지 마라고 말하는 것보다 이 뭐뭐 하지 마 하고 이 AI가 실수했을 때 잡아낼 수 있는 그
Speaker A
장치까지 하는 거, 그거를 하네스 엔지니어링이라고 부르게 됩니다. 그래서 단순 뭐뭐 하지 마라는 말이 아니라 이 단순 뭐뭐 하지 마를 넘어서 얘가 발생이 됐을 때에 잡아낼 수 있는 그 장치까지 만드는 거를 하네스 엔지니어링이라고 해요. 그래서 AI가 개발을 하다가 실수를 하면은 인간이
Speaker A
발견을 할 수도 있고 또 AI가 스스로 어 나 실수했네 하고 다시 피드백을 거쳐서 다시 수정할 수 있게끔 하는 게 바로 하네스 엔지니어링입니다. 아 사실이 하네스 엔지니어링이라는 개념은요, 나온 지 좀 됐는데요. 요게 최근에 핫해진 이유가요, 바로 이 오픈 AI에서 어떤 문서를 내놨기 때문입니다. 이 오픈
Speaker A
AI에서 어 5개월간 진짜 개발자들끼리 코드 한 줄도 안 치고 어떤 서비스를 만들었대요. 근데 그 서비스가 이제 AI가 알아서 일을 하게 한 거예요. 어떻게? 내가 바로 이 AI가 잘 일할 수 있게 하는 시스템을 만들었더니 하네스 엔지니어링 구축을 해 놨더니 AI가 내가 별로
Speaker A
이게 끼어들지 않아도 알아서 일을 잘 하더라. 그래서 자기가 어떻게 그 시스템을 구축을 하게 됐는지 그 문서를 저희에게 공개를 했습니다.
Speaker A
그래서 오늘 그 문서를 리뷰하면서 어떻게 하네스 엔지니어링을 잘 할 수 있을지 한번 보도록 하겠습니다. 자, 일단은 여러분도 그렇고 저도 그렇고 보통 AI를 통해서 우리가 어떤 개발을 하면은 보통 워크플로우가 이렇게 됩니다. 제가 뭐 AI한테 또는 뭐 클로드한테 뭐뭐 해 줘라고
Speaker A
요청을 하면은 이 뭐 클로드나 클라우드가 네, 알겠습니다 하고 코드 구현을 두르륵 해 줘. 그리고 구현 완료됐습니다라고 딱 뜨면은 저희가 어떻게 합니까? 테스트를 합니다.
Speaker A
그죠? 테스트를 하다가 어 이거 아닌데 그러면 어 이거 다시 고쳐 줘라고 요청을 해요. 그러면 AI가 알겠습니다 하면서 막 뚜르륵하면서 고쳐주고 저희가 또 테스트하고 뚜르륵 고쳐주고 그래서 이게 완벽할 때까지 우리가 무한 루프를 한단 말이에요.
Speaker A
어 보통의 대부분의 사람들이 지금 현재 아마 이런 식으로 개발을 하고 있을 거예요. 어 오픈 AI 팀도 이런 식으로 처음에는 개발을 했겠죠.
Speaker A
근데 이렇게 되니까 문제가 뭐냐면요, 이 AI가 코드를 만드는 속도는 정말 빠른데 이거를 하나하나 테스트하는 인간은 너무 느리다는 거예요. 그래서 이 생산 효율성의 병목 현상이 즉 뭐다? 적폐가 누구다?
Speaker A
인간이다라는 거였어요. 그래서 인간이 자꾸 테스트를 하고 개입을 해야 되니까 자꾸만 이제 AI가 계속 기다리게 되는 거예요. 인간이 테스트할 때까지. 그러다 보니까 오히려 생산성이 안 나오더라.
Speaker A
그래서 이 생산성을 증가를 시키려면은 그냥 이 프로젝트에서 인간을 삭제시켜야겠다. 그럼 AI가 알아서 자기네들끼리 테스트하고 북칙박칙 할 테니까 그럼 완벽하게 만들어질 텐데 이놈의 인간이 오히려 이 AI의 생산성을 방해한다라는 걸 깨닫게 된 거예요. 그래서 어떻게 하느냐? 이 AI가 인간의 개입 없이 최대한 스스로 만들 수 있게끔 하는 그
Speaker A
시스템을 만들자 하는 게 하네스 엔지니어링의 첫 시작이었습니다. 그래서 이 오픈 AI 팀이 최종적으로 원했던 거는요, 어 우리가 이제 인간이 뭐뭐 만들어 줘라고 딱 던지면요 알아서 계획하고 알아서 구현하고 알아서 테스트하고 어 알아서 버그 있으면 버그 잡고 완벽하게 그냥 알아서 다 해 가지고 그냥 결과물을
Speaker A
짠, 어 완성했습니다. 그리고 이거에 대해서 인간이 굳이 테스트하지 않아도 뭔가 신뢰를 할 수 있을 만한 그런 거를 원했단 말이에요. 그래서 그거를 하기 위해서 이제 오픈 AI가 도입한 첫 번째가 뭐냐면요, 바로 이 앱에이, 그러니까 이 AI한테 가시성을 확보해 준 거예요. 눈을 달아 준 거예요.
Speaker A
어떻게 눈을 달아줬냐? 바로 로그입니다. 어 우리가 어 보통 개발자들이 개발을 할 때에는요, 제가 개발자 시절에 손개발자 시절에 제가 막 개발할 때가 보통 막 우리 막 시니어 개발자분들이 막 그랬어. 제발 쓸데없는 로그 지워. 막 이랬단 말이에요. 어 그래서 항상 로그
Speaker A
지우고 막 저희가 테스트했던 거 로그 지우고 막 이러는 게 일이었어요. 근데 이제는요 로그를 오히려 붙여 주자 이 말이에요. 왜냐? AI가 이 로그 결과물을 보고 어이 결과가 이게 내가 원하는 결과물이 아니네라고 생각하면서 바로 스스로가 피드백을 할 수 있게끔 오히려 이 로그 시스템을 달아주자 해
Speaker A
가지고 나온 게 첫 번째 이 로그 시스템을 달아주고 그래서 그 가시성을 위해서 어떻게 했느냐? 이 어 로그를 이게 다 남기는 거예요. 모든 일에 로그를 남긴 다음에 그 로그를 가지고 다시 뭐 코덱스, 어 오픈 AI는 코덱스를 썼겠죠. 그래서 코덱스를 통해서 이제 뭔가 그 수정을 하고
Speaker A
로그를 보면서 수정을 하고 다시 어 테스트하고 뭐 이런 식으로 반복을 했다고 합니다. 그래서 이런 뭐 크롬 대부툴이라던가 뭐 이런 에이전트 연 런타임을 연결하고 뭐 돈 스크린샷이라든가 어 뭐 돈 스냅샷이라든가 뭐 스크린샷이라던가 뭐 탐색을 위한 이런 스킬을 통해서 어 코덱스가 어떻게
Speaker A
한다, 뭐 버그를 제언하고 수정 사항을 검증하며 UI 동작에 대해서 직접 또 출연할 수 있게끔 이 눈을 달았다라는 겁니다. 두 번째는요, 바로 이 컨텍스트 관리입니다. 어 우리 컨텍스트 엔지니어링 할 때가 컨텍스트 얘기했잖아요. 어 맞습니다. 그 컨텍스트 맞는데요, 여기서의 또 컨텍스트는 약간 다른 관점이에요.
Speaker A
어, AI한테 어, 우리 일의 히스토리 같은 거를 잘 알려 주는 거. 어, AI가 시작 전에 알아야 되는 정보 주는 거 너무너무 중요하지만 우리가 너무 많은 정보를 주다 보니까 AI가 대충 읽고 넘어가더라라는 거예요. AI도 인간이랑 똑같아요. 무슨 인간 신입
Speaker A
사원이랑 똑같다니까. AI도 이 컨텍스트가 양이 너무 많잖아요. 그러면은 문서 앞부분에 대충 읽어보고 에이 뒷부분은 뭐 대충 이럴 거야라고 대충 추측하고 넘어간다던가 뒷부분은 읽어보지 않고 넘어간다던가 그런 이제 상황이 발생이 된 거예요. 그렇게 되면 어떡하겠어요? 어 AI가 하는 일에 실수가 많이 일어나겠죠. 그래서
Speaker A
아, AI한테 우리가 그냥 컨텍스트 원하는 만큼을 그냥 빡 주는 게 아니라 AI가 스스로 내가 원하는 컨텍스트를 찾아가도록 해야겠다. 그래서 우리가 목차를 시켜야겠다. 컨텍스트를 목차를 시키고 AI한테 야, 이런 목차가 있으니까 네가 그때그때 필요한 컨텍스트 가져다가 써라고 얘기를 해야겠다라고 해서 이런 컨텍스트를
Speaker A
점진적으로 공개하는 시스템으로 형식을 조금 바꿨다고 합니다. 그래서 여기 글 보시면요, 처음에는 하나의 큰 에이전트 MD 접근 방식을 시도를 했대요. 그니까 하나의 큰 에이전트 MD 파일에 그냥 모든 걸 다 때려 넣었더니 어 이게 너무 지침이 많으니까 지침이 되지 않는다라는 이제
Speaker A
표현을 썼죠. 그러면서 막 순식간에 망가지고 막 확인하기가 어렵고 AI가 컨텍스트 너무 많으니까 대충 안 읽어 보더라라는 거예요. 그래서 이 MD 파일을 막 크게 만들기보다는요, 이 목차로 취급을 해서 점진적으로 공개할 수 있다, 있게 했다고 합니다.
Speaker A
그래서 여기 보시면요, 그들이 썼던 MD를 MD 파일을 어떤 식으로 목차화시켰는지가 이렇게 나와 있죠. 그죠? 그래서 어떻게 했다. 이를 통해서 점진적으로 어 컨텍스트를 공개할 수 있도록 그래서 에이전트가 처음부터 부담 느끼지 않고 완전적인 진입점에서 조금 자기가 이제 찾아서 다음 단계로 나갈 수 있게 했다라는
Speaker A
겁니다. 자, 그리고 이 하네스 엔지니어링의 가장 핵심은요, 바로 이 CICD 강제입니다. 그러니까요, 우리가 AI한테 야, 뭐뭐 하지 마, 이거 하지 마, 이 파일 보지 마. 뭐 이런 식으로 제가 뭐 하지 말라는 얘기는 100만 개도 할 수 있어.
Speaker A
근데 문제는 뭐예요? AI가 얘네를 자꾸 무시한단 말이에요. 그래서 이거를 무시하지 않게 하기 위해서 우리가 어떻게 해야 됩니까? 강제로 AI가 우리 룰 밖으로 벗어나면은 에러를 탁 걸어 줄 수 있는 어떤 강제할 수 있는 훅이라던가 뭐 규칙 룰을 딱 세팅을 해 줘야겠죠. 이게
Speaker A
바로 저는 하네스 엔지니어링의 핵심이라고 봅니다. 우리가 단순히 프롬프트만 이렇게 막 하지 마 이거 제발 하지 마 부탁이야 이렇게 쓰는 게 아니라 우리가 실제로 그거 어겼을 시에 다시 돌아올 수 있게끔 우리가 어떤 그 뭐냐 룰을 탁 세팅을 해 주는 것, 그게 바로 저는 하네스
Speaker A
엔지니어링의 핵심이라고 생각을 합니다. 그래서 여러분들이 뭐 예를 들어서 ESLint 룰 같은 걸 또 줄 수도 있는 거고요. 또는 내가 뭐 메시지 커밋하기 전에 뭔가 커밋 메시지 룰 같은 것도 제가 줄 수가 있는 거고요. 그래서 그런 룰을 줄
Speaker A
수 있는 툴을 잘 활용을 해서 AI가 벗어나려 그러면은 제동을 걸어서 다시 돌아오게 하는 거. 저는 하네스 엔지니어링의 핵심이라고 봅니다.
Speaker A
그래서 우리가 이런 제동을 어떻게 거는지 한번 실제 예제를 통해 살펴보도록 합시다. 자, 이거는 제가 만든 하네스 엔지니어링 시스템이고요.
Speaker A
어, 저는 이거를 어떻게 만들었냐면요. 제가 이 오픈 AI 팀이 만들었던 이 문서 있잖아요. 이거를 GPT한테 그대로 주고 어 그대로 주고 이거를 적용한 하네스 엔지니어링 만들 수 있는 프롬프트를 만들어 달라고 제가 요청을 했습니다. 그래서 자 이거 보이시나요? 제가 오픈 AI 측에서 썼던 이 글을 그대로 주고
Speaker A
프
Speaker A
프롬프트를 만들어 줘. 내가 다른 AI한테 하네스 엔지니어링 시스템을 구축해 달라고 요청할 예정이다라고 이렇게 만들어서 받은 프롬프트를 그대로 적용을 했습니다. 그 물론 이렇게만 했을 때에 적용이 안 되는 부분이 또 굉장히 많았습니다. 그래서 제가 어 수정해야 될 사항은 조금 조금씩 수정을 했거든요. 그래서 그런
Speaker A
사항들도 제가 알려 드리도록 할게요. 자, 일단 여기서의 핵심은요. 저는 여전히 클로드.md MD 파일이라고 생각합니다. 자,이 클로드 MD 파일이 중요한 이유는요.이 클로드 코드가 내가 어떤 거를 실행하기 전에 여러분들이 준 명령어를 실행을 하기 전에이 클로드 MD 파일을 한번 읽고 시작을 합니다. 무조건 얘는 읽고
Speaker A
시작을 하는 거예요. 그래서 여기에 사실 중요한 규칙을 넣는게 중요합니다. 어, 참고로이 문서에서는요.요 문서에서는요.이 클로드 MD 파일에 대한 언급은 없습니다. 그래서 제가 실제로 하네스 엔지니어링 만들어 달라고 했을 때게이 클로드 MD 파일을 만들어 주지 않았어요.
Speaker A
그랬더니 어떻게 되느냐? 얘한테 제가 굳이 뭐이전트.md파일을 참고해서 만들어 줘라고 굳이굳이 언급을 하지 않는 이상 얘가 그냥 자기 마음대로 하네스가 뭐야? 이서 자기 마음대로 그냥 만들어 버리는 거예요. 그래서 제가 MD 파일을 다시 제대로 작성을 했습니다. 그래서 여기 보시면요. 우리가 항상 하네스
Speaker A
엔지니어링을 위해서 항상 거쳐야 되는 단계를 제가 명시를 했습니다. 첫 번째 단계 플랜을 생성한다. 어, 플랜. 그러니까 어떤 걸 개발하기 전에 어떻게 개발할지 그 플랜을 작성을 해 달라라는 거죠. 그래서 계획 없이 코드를 작성하지 않는다가 일단 첫 번째 원칙이고요. 그리고 두
Speaker A
번째 워크트리에서 구현한다라고 되어 있어요.이 하네스 엔지니어링 팀의 특징이요.이 개발을 그냥이 내가 일하고 있는이 로컬에서 바로 작업하는게 아니라요.이 깃 워크트리를 따로 파서 여기서 작업을 하고 합치는 행동을 하더라고요. 요게 어디 나와 있냐면요. 자, 여기 보시면요.
Speaker A
워크트리별로 앱을 부팅할 수 있게 해서 코덱스가 변경 사항 하나의 인스턴스를 실행하고 제어할 수 있도록 했다라고 되어 있죠. 그래서 기존에 있는 로컬 시스템 있잖아요. 내가 지금 현재 돌리고 있는이 로컬 시스템에 복사본인 워커트리를 하나 만들어서 여기에서 자기네들끼리 테스트하고 뭐 하고 실컷 작업을 하고
Speaker A
여기서 완벽해지면은이 메인에 딱 병합을 하는 거예요. 그래야 완벽하게 딱 합쳐지겠죠. 그죠? 우리가 메인에서 무작정 작업을 하다가 망가지면 어떡할 거야. 그죠?
Speaker A
어 그래서이 오픈 AI 팀이 최대한 인간의 개입을 안 하기 위해 이런 것까지 고려를 했다라는 거예요. 어 메인에서 지원자 작업하면 망가지면 또 인간이가 가지고 이거 뜯어서 고치고 해야 되잖아. 이게 싫으니까 아예 공간 하나 새로 파서 여기서 완벽하게 테스트 통과면 일로 합쳐라고 이제
Speaker A
워크 트리를 분리를 한 겁니다. 그리고 나서 테스트를 또 작성을 합니다. 어이 내가 맞는 기능을 어떻게 테스트를 할지 어 요렇게 이제 테스트를 작성을 하고 그리고 나서 이제 구현된 기능에 대해서는요. 이제 검증을 실행을 하게 됩니다. 그래서 뭐 단위 테스트, 린트 테스트, 빌드
Speaker A
테스트, 뭐 파티 파일 크기 제한 이런 식으로 이거를 해라라고 지금 나와 있게 되죠. 그죠? 음. 요거에 대해서는이 실행은요. 이제 어떻게 하게 되느냐? 바로 여기 스크립트/베verify 테스크라는 걸 통해서 강제로 수행을 하게 만들어 줍니다. 그래서 여기에 보시면은 스크립트 파일들이 있거든요.
Speaker A
이게 바로 제가이 코드를 어떤 커밋하기 전에 그러니까 세이브하기 전에 반드시 검증 단계에서 지켜야 되는 것들에 대해서 나와 있습니다. 그래서 뭐 베리if파이 테스크 같은 경우에는 여기 가시면은 이제 테스크 뭘 해야 되는지에 대해서 이렇게 쭉 나와 있죠. 음.
Speaker A
그래서 린트 테스트 꼭 해라. 빌드 테스트 꼭 해야 된다. 파일 크기 테스트해야 된다. 이런 식으로 강제로 테스트를 할 수 있게 테스트해 줘라고 말만 남기는게 아니라 강제로 테스트 할 수 있게끔 요렇게 소스 코드 파일을 만들어 놨다라는 겁니다. 음.
Speaker A
여기에서 이제 5단계 뭐다? 이제 소스 코드를 스스로 커밋하고 머지하고 완료 처리까지 해 줘라. 어, 너 개발하고 끝나지 말고 이거 메인 코드로 네가 알아서 좀 합쳐 줘라는 겁니다. 왜냐? 우리는 인간의 개입을 최대한 안 하고 싶은게 목적이에요.
Speaker A
그래서이 커밋마저도 인간의 개입이 들어가는게 싫다 이거야. 그래서 알아서 커밋을 할 수 있게끔. 그리고 커밋 메시지도 이렇게 형식을 딱 정해 주게 됩니다. 어, 요런 거밋 메시지 형식 맞춰서 또 해야 될 거 아니에.
Speaker A
AI가 멋대로 커밋 메시지 쓰면 안 되잖아요. 그죠? 그래서 그런 것 또한 규칙으로 다 만들어 놨습니다.
Speaker A
그래서 여기에 보시면요. 허스키라는게 있거든요.이 헛스키라는 거는요. 여러분들이 어떤 커밋을 하기 전 또는 커밋을 하고 난 후에 어 반드시 실행시켜야 되는 체크해야 되는 훅 리스트들을 여러분들 적으실 수가 있습니다. 그래서 여기 보시면 프리커밋 그니까 커밋하기 전에 코드 세이브 하기 전에 무엇을 테스트해야
Speaker A
되는지가 쫙 나와 있습니다. 그래서 예를 들어서 코드 테스트 하기 전에음 예를 들어서 어 그 마스터 브렌치에 있는 코드를 직접 바꾸려고 하면은요 바로 차단 바로 차단 받고요. 뭐 그런 내용들이 있습니다. 만약에 플랜 없이 계획 없이 뭔지 모를 코드가 들어왔다. 계획이
Speaker A
없는 코드가 들어왔다. 그럼 바로 차단 박아 버리고요.음 음. 그리고 이제 어 단위 테스트를 무조건 파일이 변경이 되면은 무조건 테스트할 수 있게끔 이런 식으로 강제를 다 해 놓게 됩니다. 그냥 뭐뭐 해 줘라고 프롬프트로 말만 남기는게 아니라 이런 식으로 어 잘못되면 실패할 수 있는
Speaker A
요런 장치들을 남겨 주는 거예요. 그래서 다시 클로드로 돌아가셔서 여러분들이 여기에 이런 식으로 어 반드시 이렇게 해 주세요라고 말을 해도 여러분들 믿으시면 안 됩니다.
Speaker A
왜냐면요. 가끔 에이전트가 이런 클로드 MD도요. 그냥 무시해 버릴 때가 많아요. 단지 이제 단지 이제 중요한 건 뭐다? 무시해 버렸을 때 다시 돌아올 수 있게끔 그 한스 장치를 만들어 두는게 중요합니다.
Speaker A
에이전트 파일 보시면은 뭐 에이전트 하나하나가 이런 기능이 있어라고 설명을 하는게 아니라 단순히 이렇게 목차만 주는 거예요. 목차만. 어.
Speaker A
자. 야, 너 뭐 아키텍처 규칙 쓰 확인하고 싶어.이 문서 봐. 야, 너 뭐 UI 검증하는 규칙 알고 싶어?요 문서 봐. 이런 식으로 그냥 단순하게 목차만 제공을 합니다. 그럼 AI가 스스로 여기에 와서 필요한게 뭔지 확인을 하고 그 거기로 가게 되겠죠.
Speaker A
그래서 여기에 있는 문서가 이제 대부분 어디 들어 있게 되느냐? 여기 다큐먼트 파일에 들어가 있게 됩니다.
Speaker A
그래서 여기 보시면요. 이제 대부분의 규칙이이 안에 들어가 있습니다. 그래서 아키텍처이 시스템 구조에 대한 문서 같은 거음 이런 거는 이제 여러분들 이제 어 개발 환경에 따라서 다르겠죠. 그리고 요런 시스템을 진행을 하면서 생기게 되는 로그들 있잖아요. 로그들. 로그들은 다 어디에 저장이 되느냐? 여기에 또
Speaker A
로그 파일이 따로 있습니다. 로그스. 보이시나요? 스크린샵 보시면요.이 친구가 직접 이제 테스트를 했던 모습들이 요렇게 담겨 있습니다.
Speaker A
만약에 테스트하다가 에러가났다 그러면은요 기록 내에서 스스로 에러를 보고 또 얘를 또 수정을 해 나갈 수가 있겠죠. 바로 이게 하네스 엔지니어링이다. 그래서 AI한테 어떻게 한다? 눈을 달아준다. 그래서 그 눈이 바로이 로그 시스템입니다.
Speaker A
음. 자, 그러면은 제 하네스 엔지니어링이 어떻게 작동하는지 보여 드리도록 하겠습니다. 그래서 어, 할리랩에 작성자 정보도 추가를 할 수 있게 기능을 추가해 달라고 요청을 했습니다. 현재 오른쪽에는 제 할 목록이 나와 있는 상태고요. 그래서 일단 첫 번째로 어 테스크를 시작을
Speaker A
하는데요. 먼저 워킹 트리를 먼저 만들어 줍니다. 그래서 워크트리 어, 작업 환경을 먼저 세팅을 해 주고요.
Speaker A
그래서 절대 메인에서 바로 코드를 바꾸지 않도록 먼저 워크트리를 만들어 줍니다. 그리고 두 번째로 계획 문서를 작성을 해 줍니다. 그래서 계획 문서함에가 보시면요. 액티브랑 컴플리티 두 가지가 있는데요.
Speaker A
액티브에 이제 현재 진행하고 있는 계획 문서를 여러분들이 보실 수가 있습니다. 그리고 완료가 되면은 자동으로 컴플리티드로 이따 옮겨질 예정입니다. 그래서 계획이 끝나서 요렇게 계획 문서들이 나와 있는 상황이고요. 그리고 이제 코드를 워크트리에서 구현을 하고 있습니다.
Speaker A
그래서 코드가 워크트리 환경에서 이제 구현이 되기 때문에 현재 코드가 바뀌어도 오른쪽에 있는 할일 목록의 UI는 바뀌지가 않죠. 왜냐?
Speaker A
워크트리에서만 진행을 하고 있기 때문입니다. 나중에 합치면은 적용이 됩니다. 음. 그리고 이제 4단계 단위 테스트를 작성을 하고요.
Speaker A
끝나고 나서 5단계 이제 전체 검증을 시작하게 됩니다. 그래서 검증하는 동안에 로그라던가 뭐 스크린샷이라든가 그런 거를 이제 다 남기게 됩니다.
Speaker A
음. 그래서 로그하면서이 정보들을 나중에 확인을 할 수가 있고요. 그렇게 해서 이제 완료가 되면은 이제 테스트 통과가 완료가 되면은 이제 코드 커밋 단계를 진행을 하게 됩니다. 그래서 여기서 이제 코드를 커밋하고 머지를 하면은 이제 오른쪽에 있는 할 목록에서 작성자 정보가
Speaker A
추가가 되게 됩니다. 그래서 지금 코드 커밋 전에 빌드까지 했고요. 지금 현재 머지가 되면서 작성자 정보가 추가가 된 걸 보실 수가 있습니다. 그래서 메인 작업 환경에서 바로 바뀌는게 아니라 어 거크트에서 작업을 하고 바뀐다라는 거. 그리고 계획 문서도요. 지금 현재
Speaker A
컴플리티드로 옮겨졌습니다. 자동으로. 음. 그래서 커밋이 되면은 자동으로 문서도 옮겨지게 됩니다. 음. 그리고 이제 여러분들이 커밋 메시지도 확인을 해 보실 수가 있어요. 어, 커밋도 자동으로 해 줬기 때문에 제가 커밋 메시지 굳이 치지 않아도 알아서 제가 요청상에 대해서 정리를 해서
Speaker A
커밋 메시지를 남겨 줍니다. 그리고 로그가 보시면은요. 테스트할 때 썼던 로그들을 여러분들이 보실 수가 있습니다. 그래서 만약에 문제가 생겼다면은이 로그들을 가지고 여러분들이 또 고쳐 달라고 할 수도 있고 AI가 스스로 또 고칠 수도 있는 거죠. 음. 그래서 그때 썼던 이런 스크린들이 이렇게 남아 있고요.
Speaker A
음. 그리고 또 이런 어 제이슨 파일이 나와 있습니다. 그리고 또이 하네스 엔지니어링의 중요한 점이 뭡니까?이 AI가 일을 잘못하면 그걸 바로 잡아 줘야 되겠죠. 그래서 지금 현재 어 워크트리를 만들어 주지 않고 그냥 바로 플랜 문서를 작성을 하게 되더라고요. 근데 이제 제가 만들어
Speaker A
둔 이제 후에 걸려서 현재 지금 워크트리 미준비로 걸려서 지금 워크트리를 다시 만들고 그 위에다가 플랫 문서를 다시 제작성을 하고 있습니다. 그래서 이렇게 자동으로 피드백도 가능하다라는 점. 자, 우리가 이렇게 기똥차 하네스 엔지니어링을 보고서도 우리 프로젝트 적용하지 않는 이유는 뭡니까? 바로
Speaker A
귀찮아서잖아요. 이거 얼마나 귀찮아. 그죠? 대충 아 이거 기능 개발해 줘라고 해서 대충 딱 나오고 대충 내가 테스트하고 이렇게 하면 되는데 굳이 한스 엔지니어링 하려면은 내가 막 이거 이거 이거 엔지니어링 시스템 이렇게 만들어 줄래? 이런 규칙 만들어 줄래? 막 이런 계속 해야
Speaker A
되고 그죠? 일이 두 배로 늘어나는 느낌이란 말이에요. 그죠? 어, 사실 이게 하네스 엔지니어링이 있다 보면은요. 어, 초반에 구축한데 시간이 오래 걸려요. 하네스 엔지니어도 테스트를 하면서 내가 뭐 규칙도 추가하고 빼고 이런 시간이 많이 걸리거든요. 그래서 하네스 엔지니어리 테스트하고 구축하는데
Speaker A
시간은 오래 걸리지만 이게 한 번만 완벽하게 되면은요. 여러분들이 뒤에 가서 작업하는 속도가 굉장히 빠르게 줄어듭니다. 어, 그래서 하네스 엔지니어링은요. 저는 개인적 구축을 하면 괜찮다고 생각은 하지만. 자, 그럼이 한네스 엔지니어링 지금 당장 적응해야 될까요? 어, 저는요. 어, 무조건 모든 거를 다 적용할 필요는
Speaker A
없다고 생각합니다. 여러분들이 필요하실 때 적용을 하시면 된다고 생각해요.이 한네스 엔지니어링도요. 사실은요. 어떻게 보면 하나의 이론일 뿐이거든요. 그래서 여러분들 시스템의이 하네스 엔지니어링이 또 다른 방식으로 적용이 될 거예요.
Speaker A
제가 생각했을 때 엔지니어링이라는 거를 가장 알맞게 적용하는 방법은요. 여러분들이 일단은 그냥 여러분들 편한 대로 개발을 해요. 그냥 내가 기능 이거 개발해 줘. 요청하면은 그거 개발 끝나면은 내가 테스트해 보고 어 이거 다시 고쳐 줘. 이런 식으로 여러분들이 편한 방식으로 그냥 편하게
Speaker A
개발을 해 보시다가 개발하시면서 점점 생각을 한번 해 보는 거예요. 어 내가 이거를 조금 더 어 반복하는 작업을 좀 덜하기 위해선 어떻게 해야 될까 이런 고민을 만들면서 계속 하시는 거예요. 어 이런 작업은 내가 AI한테 굳이 매번 쓰는게 아니라 좀
Speaker A
자동화시키면 좋지 않을까? 그러면은 그런 거 하나하나씩 자동화를 시켜 놓는 거예요. 그러면서 천천히 엔지니어링 구축을 해 나가면요. 이게 나중에는 뭐 하네스 엔지니어링이니 뭐 컨텍스트 엔지니어링이니 이런 거 말 필요 없이 그냥 여러분들만의 엔지니어링 시스템이 구축이 되어 있지 않을까 생각합니다. 그래서 어 내가
Speaker A
하고 있던이 많은 업무에 일부 조금씩 AI한테 위임해 가는 형식으로 여러분들이 어 시스템을 구축을 해 두시면 좋을 것 같습니다. 자, 여러분들 이번 영상 어떻게 보셨나요?
Speaker A
어, 저와 함께 바이브 코딩을 제대로 배워보고 싶으신 분들은요. 제 바이브 코딩 스터디 모집하고 있으니깐요.
Speaker A
여러분들 많은 지원 부탁드립니다. 자, 그러면은 다음 시간에는 더 유용한 콘텐츠로 찾아올게요. 여러분들 안녕. H
Topics:하네스 엔지니어링프롬프트 엔지니어링컨텍스트 엔지니어링AI 개발오픈AIAI 생산성로그 시스템CICDAI 테스트 자동화AI 신뢰성
