AI 에이전트, 이제 ‘자율 주행’ 시대! 🚀
최근 AI 에이전트들이 정말 똑똑해지고 있다는 건 다들 체감하고 계시죠? 혼자서 뭘 척척 해내는 걸 보면 신기할 따름인데요. 그런데 이런 AI 에이전트들이 제 능력을 100% 발휘하려면, 마치 자동차에 ‘하네스’라는 게 필요한 것처럼 AI에게도 뭔가 특별한 게 필요하다고 하더라고요. 오늘은 빌더 조쉬님 채널에서 소개된 바이브마피아 최수민님의 ‘하네스 엔지니어링’ 영상에 대한 제 생각과 느낀 점을 공유해보려고 합니다.
AI의 ‘자율 주행’을 위한 필수 장치, 하네스
영상을 보면서 가장 먼저 와닿았던 건 바로 **하네스(Harness)**라는 개념이었어요. 이건 AI 에이전트가 마치 사람의 개입 없이도 스스로 일을 계속해나갈 수 있도록 만들어주는 일종의 ‘장치’ 또는 ‘시스템’이라고 볼 수 있겠더라고요. AI가 작업을 할 때, 기억할 수 있는 정보의 양(컨텍스트 사이즈)이 제한적이라서 한 번에 많은 일을 처리하기 어렵거든요. 그런데 하네스는 이런 한계를 극복하기 위해 복잡한 작업을 더 작은 단위로 쪼개거나, 다른 AI 에이전트에게 리뷰를 요청하는 등 똑똑한 방법들을 사용해요.
무엇보다 놀라웠던 건, 이 하네스 덕분에 AI 에이전트가 **사람의 도움 없이도 오랫동안 자율적으로 작업**을 수행할 수 있다는 점이었어요. 마치 스스로 운전하는 자율주행차처럼 말이죠!
개발 후반부에 빛을 발하는 하네스의 강력함
개발 과정을 여러 단계로 나눴을 때, 하네스는 특히 **프로세스의 후반부, 즉 구체화된 내용을 실제로 구현하고 검증하는 단계에서 엄청난 힘**을 발휘한다고 해요. 처음 아이디어를 구체화하는 초기 단계는 사람의 의도가 정확하게 반영되는 게 중요해서 AI가 혼자 하기에는 아직 무리가 있거든요. 오히려 잘못된 정보를 사실처럼 이야기하는 ‘할루시네이션(환각)’ 현상이 나타나기 쉽고요.
하지만 하네스는 이미 잘 다듬어진 기획이나 설계 내용을 바탕으로, **정해진 대로 틀림없이 구현해내는 능력**에 특화되어 있다고 해요. 그러니까, 사람이 ‘무엇을 만들지’를 명확하게 정의해주면, 그 이후의 개발 과정은 거의 AI에게 맡길 수 있다는 거죠.
‘구체화’라는 마법의 주문 ✨
이 영상에서 정말 강조하고 또 강조했던 게 바로 **’구체화’**였어요. 이게 왜 중요하냐면요, 우리가 어떤 앱이나 서비스를 만들 때, ‘이런 기능이 있으면 좋겠다’ 정도의 막연한 생각만으로는 AI가 제대로 된 결과물을 내놓기 어렵기 때문이에요. AI에게 “이런 기능이 필요해요”라고만 하면, AI는 이걸 어떻게 만들어야 할지, 어떤 디테일을 살려야 할지 제대로 판단하기 힘들죠.
하지만 우리가 ‘이 기능은 이런 식으로 작동해야 하고, 이런 예외 케이스도 고려해야 해’라고 **명확하고 구체적으로 정의**해주면, AI는 훨씬 더 정확하고 의도에 맞는 결과물을 만들어낼 수 있어요. 최수민님은 이걸 ‘빡센 기획’ 또는 ‘내 의도를 명확히 하는 작업’이라고 표현하셨는데, 정말 딱 맞는 말인 것 같아요.
만약 구체화가 제대로 안 된 상태에서 AI에게 개발을 맡기면, AI는 이것도 했다가 저것도 했다가 하면서 일관성이 떨어질 수 있어요. 결국 결과물이 내가 원했던 것과 다르게 나오면, 그걸 수정하는 데 더 많은 시간과 노력이 들겠죠. 그래서 **앞단에서의 ‘구체화’가 정말 중요**하고, 이렇게 잘 구체화된 내용을 AI가 ‘맛있게 요리’해주는 역할을 하는 게 바로 하네스라는 거예요.
실전! 하네스, 어떻게 작동하는 걸까? 💡
영상에서는 실제 하네스 접근 방식과 구체적인 사례들을 보여줬는데요. 특히 인상 깊었던 건, **사람의 손을 거의 거치지 않고 개발과 검증까지 진행하는 하네스**였어요.
첫 번째 하네스 사례: 구체화된 기획을 빠짐없이 개발하는 방법
이 사례는 이미 **잘 구체화된 기획을 바탕으로 개발을 놓치는 부분 없이 진행하는 것**에 초점을 맞췄어요.
1. **문서화:** 프로젝트 기획, 디자인 의도, 아키텍처 설계 등 중요한 내용을 잘 문서로 남기는 것부터 시작해요.
2. **AI에게 문서 학습:** 이렇게 만들어진 문서들을 AI가 정확하게 이해하도록 학습시켜요.
3. **구체화 논의:** 개발 직전에 ‘이 부분을 구현하려면 더 구체화해야 할 점이 있을까요?’ 하고 사용자에게 되묻는 과정을 넣어요.
4. **구현 계획 작성:** 사용자가 ‘이제 구현 준비 완료!’라고 판단하면, AI에게 구현 계획을 세우도록 지시해요.
5. **상세 지침 기반 구현 계획 작성:** AI는 여러 페이지로 나뉜 상세한 구현 계획을 작성하고, 사용자에게 피드백을 요청해요.
6. **테스트 및 파일 생성:** 계획이 확정되면, 필요한 테스트와 파일들을 생성해요.
7. **파이썬 스크립트 실행:** 최종적으로 생성된 파일들을 파이썬 스크립트를 통해 실행하는 거예요.
스크립트 파일, 그게 뭐길래? 🎬
여기서 **스크립트 파일**이 핵심적인 역할을 하더라고요. 이 스크립트는 위에서 설명한 1년의 흐름을 **’오케스트레이팅’** 즉, 전체 과정을 지휘하는 역할을 해요. 총 몇 페이지가 필요한지, 지금 몇 페이지까지 진행됐는지, 어디서부터 시작해야 하는지 같은 정보들을 담고 있죠.
이 스크립트의 가장 큰 장점은, 혹시라도 큰 작업 중에 멈추거나 오류가 발생했을 때, **잘 진행됐던 부분까지 복구하고 스크립트를 다시 실행**할 수 있다는 거예요. 마치 타임머신처럼 말이죠!
왜 ‘스킬’을 오케스트레이터로 썼을까? 🤔
저는 처음에 ‘스킬’이라는 게 단순히 특정 기능을 뜻하는 줄 알았는데, 여기서는 좀 더 넓은 의미로 쓰였더라고요. 이미 사용자와 AI가 클로드(Claude) 같은 플랫폼에서 많은 대화를 나눈 상태에서 ‘스킬’을 호출하면, 자연스럽게 구현 하네스가 발동되는 방식이었어요. 프로젝트 초반부터 쌓인 풍부한 대화 내용(컨텍스트)을 바탕으로 하네스가 작동하는 거죠.
무엇보다 기획 구체화 같은 부분은 워낙 변칙적인 경우가 많아서 딱 정형화하기 어렵잖아요. 이런 부분은 일반적인 챗봇 대화로도 충분히 가능하기 때문에, **’스킬’은 오로지 ‘구현’이라는 하네스 역할에 집중**하게 만든 거예요. 이렇게 쌓아둔 양질의 컨텍스트를 빠짐없이 잘 구현해내게 하는 목적이었죠.
스크립트 기반 자동화, 왜 좋은 걸까요? 👍
스크립트 기반 자동화는 여러모로 장점이 많았어요.
* **매뉴얼화:** AI가 스스로 반복 작업을 수행할 수 있도록 매뉴얼처럼 만들어줘요.
* **효율화:** 반복적인 일은 미리 스크립트로 만들어두면 빠르고 정확하게 처리할 수 있죠.
* **컨텍스트 보존:** AI의 메인 세션이 사용자의 의도를 파악하는 데만 집중하게 되어서, 버그가 발생해도 명확한 답변을 얻기 쉬워요. 작업 후에도 메인 에이전트의 컨텍스트 소모가 적다는 점도 좋았고요.
Git 커밋부터 PR까지, 자동화의 끝판왕! 👑
정말 놀라웠던 건, 스크립트 안에서 Git으로 커밋을 자동으로 남기고, 최종적으로 **풀 리퀘스트(PR)**까지 생성해준다는 거예요. 오픈 소스 프로젝트라면 **코드레빗(CodeRabbit)** 같은 도구를 이용해서 PR에 대한 자동 리뷰까지 진행할 수 있다고 해요.
이 자동 리뷰 시스템은 정말 흥미로웠는데요. 코드레빗이 PR에 리뷰를 남기면, AI 에이전트가 그걸 읽고 반영할 만한 내용을 자동으로 반영하는 거예요. 마치 AI끼리 서로 소통하며 코드를 개선하는 것처럼요! “반영했습니다”라고 AI가 댓글을 달면, 코드레빗이 “확인했습니다”라고 응답하며 머지 처리까지 자동으로 진행된다고 하니, 정말 미래에는 개발 방식이 완전히 달라지겠구나 싶었어요.
PR을 사용하는 이유도 명확했어요. 인간인 제가 보기에 편하고, 나중에 **문서이자 대화 내역으로 활용**하기 좋다는 거죠. 결국 모든 과정을 보고서처럼 쌓아두는 거잖아요. AI가 제대로 된 대화를 하고 있는지, 반영할 만한 것을 잘 반영했는지 인간이 쉽게 검토할 수 있는 형식이라는 점이 좋았어요.
두 번째 하네스 사례: 코드 리뷰 하네스 👨💻
개발 과정에서 가장 큰 병목 중 하나가 바로 **코드 리뷰**라고 하잖아요. 이걸 최적화하면 정말 체감 효과가 클 것 같다는 생각이 들었어요. 이 하네스는 이런 코드 리뷰 과정을 자동화하는 데 초점을 맞췄어요.
1. **요구사항 구체화 및 아키텍처 설계 (사람 진행):** 이 부분은 여전히 사람이 직접 담당해요.
2. **컨텍스트 충분히 쌓이면 세션 포크:** 동일한 AI 세션을 복제해서 여러 개의 세션에서 각기 다른 작업을 하게 해요.
3. **설계 의도 문서 작성 및 ADR 업데이트 (포크된 세션):** 왜 이런 결정을 했는지 상세한 ‘설계 의도 문서’를 작성하고, ‘ADR(Architectural Decision Records)’이라는 문서에 영구적으로 기록해요. 이건 나중에 합류하는 개발자들이나 AI들이 조직의 의사결정 기준을 알 수 있도록 돕는 중요한 문서예요.
4. **평가 기준 생성 (원본 세션의 서브 에이전트 사용):** 코드 리뷰를 위한 평가 기준을 만들어요. 이때 **코드 컨벤션이나 ADR 문서를 참고**하는데, 이 과정에서 **’압축된 암묵지’**처럼 필요한 정보만 쏙쏙 뽑아주는 서브 에이전트가 역할을 해요. 마치 RAG(Retrieval-Augmented Generation)처럼요.
5. **평가 기준 기반 구현 및 리뷰:** 이렇게 만들어진 평가 기준을 실제 구현과 리뷰 과정 모두에 동일하게 적용하는 거예요.
ADR 문서, 왜 중요할까요? 📚
ADR 문서는 마치 회사의 ‘경영 철학’ 같은 거라고 할 수 있어요. 새로 합류하는 개발자나 AI가 이 문서를 보면 **우리 팀이 왜 이런 결정을 내렸고, 어떤 기준으로 일하는지**를 금방 이해할 수 있거든요.
하네스의 미래, 그리고 AI 시대 엔지니어의 역할 🔮
영상을 보면서 하네스 엔지니어링이라는 개념이 정말 새롭고 흥미로웠어요. 최수민님은 개발자 베이스를 가진 사람들이 자신의 경험과 지식을 AI에 심어놓으면서, 초보자가 쉽게 따라오기 어려운 **’해자(Barrier to Entry)’**를 구축하고 있다고 말씀하셨는데요. 엔지니어의 역할 자체가 사라지지는 않겠지만, 분명 변화의 폭은 클 거라고 하셨어요.
특히 기업들이 **AX(AI Transformation)**에 주목하고, 에이전트가 읽기 쉬운 파일 시스템으로 데이터를 구축하는 데 집중하는 부분은 인상 깊었어요. 데이터만 잘 갖춰져 있다면, 래그(RAG) 역할을 하는 서브 에이전트 정도만 있어도 웬만한 업무는 AI가 잘 처리할 수 있다고 하니, 앞으로는 데이터 스토리지 구축이 기업 경쟁력의 핵심이 될 수도 있겠다는 생각이 들었어요.
마무리하며
이번 빌더 조쉬님 채널의 영상은 AI 에이전트를 어떻게 하면 더 똑똑하고 효율적으로 활용할 수 있는지에 대한 **실질적인 방법론**을 보여준 것 같아서 정말 유익했어요. 특히 ‘구체화’의 중요성과 이를 돕는 ‘하네스’라는 개념은 앞으로 AI 개발이나 활용에 있어서 필수적인 요소가 될 것 같아요.
혹시 AI 에이전트를 활용해서 개발 효율을 높이고 싶으신 분이나, AI 시대를 준비하는 개발자분들이라면 이번 영상 꼭 한번 보시길 추천드려요! 저처럼 새로운 인사이트를 얻어가실 수 있을 거예요. 😊