지난 5월 27일과 6월 10일, 요즘IT는 ‘클코나잇 2’ 웨비나를 개최했습니다. 지난해 진행한 클코나잇 시즌 1에 이어, 이번 웨비나에서는 개발자와 비개발자를 포함한 다양한 직군의 실무자들이 클로드 코드(Claude Code)를 업무에 활용한 경험을 공유했는데요. 참가자들은 “고수의 경험을 나눠 받을 수 있는 기회”, “찐 실무자의 현장감 넘치는 사례”, “다음에 또 오고 싶은 웨비나” 등의 반응을 보였습니다. 이번 글에서는 아쉽게도 참석하지 못한 분들을 위해, 웨비나의 핵심 내용만 모아 콘텐츠로 정리했습니다.

이번 글은 클코나잇 2 웨비나의 ‘우리 팀에 딱 맞는 하네스 엔지니어링을 구축하려면?’입니다. 발표 자료는 요즘IT 디스코드에서 다운로드 받을 수 있습니다.

안녕하세요. 저는 바이버스 AI에서 기술을 맡고 있는 김영채라고 합니다. 오늘은 저희 팀이 왜 하네스 엔지니어링을 도입했고, 어떻게 쓰고 있는지를 말씀드리려고 합니다.

팀을 위한 하네스 엔지니어링이 필요해진 이유

저희는 작년 하반기에 설립한 회사입니다. 그러다 보니 제로베이스에서 시작했어요. 코드가 0줄에서 시작한 거죠. 그래서 초반에는 클로드 코드의 플랜 모드로 계획을 세우고 구현하는 수준으로 개발했습니다. 그것만으로도 큰 문제 없이 개발할 수 있었고요.

그런데 점점 기능이 추가되고 서비스도 늘어나면서 코드베이스가 쌓이다 보니, 플랜 모드에서 문제가 발생하기 시작했습니다.

코드 조사를 제대로 못 하거나
플랜대로 구현하지 않고 어떤 부분을 놓치거나
아예 엉뚱한 작업을 하거나

이런 일들이 빈번하게 늘어났고, 기능을 구현하고 출시하는 속도가 점점 느려지기 시작했습니다.

저희 코드 라인 수를 보면, 지난 8개월 동안 총 4명의 개발자가 170만 줄, 파일 수로는 9,900개를 작업했는데요. 느낌적인 느낌으로 한 80만 줄 정도부터 조금씩 문제가 생기기 시작했던 것 같습니다. 저희 같은 스타트업 입장에서 출시 속도가 느려진다는 건 회사의 존속과 관련이 있는, 되게 큰 문제라고 생각했습니다.

개발자의 암묵지를 형식지로 만든 스킬

이 문제를 어떻게 해결할 수 있을까 고민하던 찰나에, 당시 앤트로픽에서는 개발자들끼리 스킬(Skill)을 수백 개 관리하면서 일한다는 이야기를 들었습니다.

저는 평소에 스킬을 ‘개발자의 암묵지를 형식지화한 것’이라고 생각해 왔습니다. 시니어 개발자의 노하우가 녹아들어 있어서, 스킬을 실행하면 사람이 일한 것처럼 일한다는 거죠. 그리고 개발이라는 건 결국 기획하고, 구현하고, 테스트하는 세 가지 워크플로우의 집합이라고 생각했어요. 그래서 ‘계획 스킬, 구현 스킬, 검증 스킬을 만들어서 자동으로 한번 돌려볼까?’라는 생각을 하게 됐습니다.

우리 팀을 위한 하네스: 마에스트로 데브

그렇게 만들어진 게 바이버스 하네스, 저희 스킬명으로는 ‘마에스트로 데브(Maestro Dev)’입니다. 컨셉은 이렇습니다. 메인 에이전트는 오케스트레이터로만 동작하고, 서브에이전트들을 소환해 문서를 작성하게 시키는 역할만 합니다.

이렇게 설계한 이유는 딱 한 가지였습니다. 저는 컨텍스트 윈도우가 지금의 LLM을 쓰는 데 있어 가장 비싼 자원이라고 생각했고, 특히 메인 에이전트의 컨텍스트 윈도우가 빨리 차면 찰수록 휴먼 인 더 루프의 주기가 잦아질 거라고 봤습니다. 최대한 자동으로 작업하게 하고 싶어서 이렇게 만든 거죠.

예를 들면 이렇게 돌아갑니다. “투두 웹 만들어줘”라고 하면 플랜 스킬이 발동하고, 플랜을 다 짜면 임플 에이전트가 소환돼 계획 문서를 확인하고 구현을 시작합니다. 구현 에이전트들은 구현 내용을 문서로 남겨 완료하고, 메인 에이전트가 그걸 받아 검증시키고요. 이런 식으로 돌아가다가 모든 작업이 끝나고 PR이 만들어질 때, 마지막 ‘크리에이트 PR’ 단계에서 메인 에이전트가 다시 개입해 PR을 만들고 사람이 확인하게 되는 과정입니다.

4가지 단계별 하네스 알아보기

이제부터 하나씩 단계별로 무엇이 중요했는지, 어떤 기준을 두었는지 정리해 보겠습니다.

1. 플랜 단계: 모든 스펙을 사람이 알고 정해야 한다

플랜, 임플, 베리파이, E2E 단계 중에서 저는 플랜이 제일 중요하다고 생각했습니다. 플랜 단계에는 다섯 가지 스텝이 있지만, 사실 제일 중요한 건 딱 하나, ‘태깅’입니다.

어떤 기능을 계획할 때 가장 중요한 건 모든 스펙을 사람이 알고 정해야 한다는 겁니다. 스펙이 하나라도 AI가 결정한 게 있으면, 결국 그게 부채로 돌아오더라고요. “이거 왜 이렇게 구현됐지? 이렇게 구현되면 안 되는데?” 하는 일들이 생기는 거죠. 이걸 방지하기 위해 모든 스펙에 사람이 결정한 건지, AI가 결정한 건지 태깅을 하고, AI가 결정한 게 딱 하나라도 있으면 차단하고 다시 사람이 확인하게 하는 루프를 만들었습니다.

지금은 슈퍼파워(Superpowers)의 브레인스토밍을 활용해 기획을 구체화하고 있는데, 앞으로는 우로보로스를 사용하려고 하고 있습니다.

2. 구현 단계: 계획대로 될 때까지 리뷰를 반복한다

이 과정을 통해 스펙이 픽스되면 구현 단계로 넘어갑니다. 구현 단계는 크게 별게 없어요. 백엔드, 프론트엔드, 데브옵스, DBA 서브에이전트들을 병렬로 소환해 작업을 시킵니다. 작업이 끝나면 계획대로 구현이 잘 됐는지 리뷰하고, 잘 안 됐으면 수정하고 다시 리뷰하고, 이 과정을 계속 반복합니다.

이 과정이 완료되면 여러 관점에서 리뷰를 하고, 리뷰를 전부 통과하면 테스트 케이스를 만들어 E2E 테스트를 돌리게 됩니다.

3. E2E 테스트 단계: 배포해도 된다는 자신감을 얻는다

E2E 테스트를 돌릴 때는 테스트 케이스를 만드는 게 되게 중요한데요. 저희는 세 가지 타입의 테스트 케이스를 만들어 테스트를 시키고 있습니다.

리그레션(회귀) 테스트
엣지 케이스
골든 케이스

이 부분이 ‘딸깍’ 개발에서 큰 비중을 차지한다고 생각합니다. 결국 ‘스펙대로 올바르게 테스트가 끝났다, 배포해도 된다’는 자신감이 이 E2E 테스트 단계에서 나온다고 보고 있어서, 테스트 케이스가 잘 나오게 하는 데 힘을 많이 들이고 있습니다.

4. PR 단계: 배포해서 만들기 전에, 회고부터 한다

E2E 테스트까지 통과하고 나면 PR 생성 단계로 옵니다. PR 생성 단계에서 가장 첫 번째로 하는 일은 회고입니다.

플랜부터 베리파이까지, 특히 임플 단계에서 계획대로 구현을 잘 하는 케이스가 지금 그렇게 많지는 않거든요. 꼭 두세 번 정도 라운드를 돕니다. 그러면서 에이전트가 어떤 실수를 했는지 다 문서로 남기고요. 그 문서를 토대로 회고를 하고, 실수한 부분들을 찾아 지식화해 놓습니다. 다음에 같은 실수를 반복하지 않게요.

회고가 끝나면 PR을 생성하고, 그때 사람이 PR을 열어 어떤 작업이 어떻게 됐는지, 어떤 테스트가 통과됐는지 확인하게 됩니다.

팀 단위 하네스 엔지니어링을 도입하고 바뀐 것들

이 하네스 엔지니어링을 도입하고 나서의 임팩트를 말씀드리고 싶은데요.

도입 후 얻은 3가지 임팩트

첫째, 개발 역량의 상향 평준화가 일어나고 있습니다. 앞서 말씀드렸다시피 스킬은 개발자의 암묵지를 형식지화한 것이라고 생각하는데, 시니어 개발자가 스킬을 만들면 그 스킬을 쓰는 주니어 개발자도 시니어 개발자와 거의 비슷한 관점으로 개발할 수 있게 됩니다. 잘하는 개발자가 스킬을 디벨롭하면 할수록, 다른 사람들도 그 개발자처럼 일할 수 있게 되는 거죠.

둘째, 개발 지식의 자산화입니다. 스킬이 생겨나고 계속 깎아 나갈수록 개발 지식이 자산이 된다고 생각해요. 다 문서로 남겨지니까요. 지식이 복리로 쌓이고, 쌓인 지식은 또 다음 플랜, 다음 검증에 쓰이게 됩니다.

셋째, 누가 해도 같은 기준으로 일하게 됩니다. 다 같은 에이전트를 활용하다 보니 같은 기준으로 코드를 짜고, 같은 기준으로 기획을 하게 됩니다. 앞서 말한 상향 평준화가 일관성 있게 일어나고, 사람이 바뀌어도 결국 그 사람도 스킬을 통해 작업하게 되니까, 퇴사와 입사에 대한 부담이 크게 사라집니다.

도입하고 나서 PR 개수와 사이즈도 측정해 봤는데요. 일 단위로는 하루에 10개 정도씩 PR이 생성되는 걸 확인했습니다. PR 사이즈는 최대한 줄이려고 하고 있습니다. PR 사이즈가 크면 클수록 사이드 이펙트를 유발할 가능성이 높아진다고 생각해서, 최대한 기능을 잘게 쪼개 작은 단위로 배포하도록 의도했고, 실제로 PR 사이즈가 줄어들고 있고요. 하네스 엔지니어링 도입 전과 후로 개발 완성도나 퀄리티, 속도 측면에서 꽤나 임팩트 있는 성과를 얻었다고 생각합니다.

솔직하게 어려웠던 점과 한계

하면서 어려웠던 점들도 말씀드리고 싶습니다. 사실 초기 셋업이 그렇게 단기간에 되진 않았습니다. 예를 들어 소프트웨어 아키텍처부터 정립한다거나, DB 컨벤션, 코드 컨벤션 같은 것들을 다 정의했는데요. 이런 부분들은 결국 사람의 시간이 고스란히 투입돼요. AI를 크게 활용하지 못하는 부분들이거든요. 그래서 여기에 시간이 많이 쓰였습니다.

그리고 지금의 하네스 엔지니어링으로 구현을 시작하면, 클로드 오퍼스 1M 컨텍스트가 되면서 한 번에 최대 12시간까지 돌아갑니다. 되게 오래 걸리는 문제가 있어요. 이것도 최대한 병렬로 돌려서 해결해야 하는 문제인데, 지금은 이런 한계가 있습니다. 그래서 반드시 한 번에 하나의 피처를 개발하는 게 아니라, 세션을 여러 개 켜서 한 번에 여러 개를 하네스 엔지니어링으로 개발해야 ROI가 난다고 보고 있습니다.

플랜만 올리면 PR까지 알아서 돌아가는 개발 공정

앞으로 어떤 걸 할 거냐면, 하네스 깎는 건 그냥 평생 해야 될 것 같고요. 어느 정도 궤도에 올랐다고 하면, 헤르메스(Hermes) 에이전트의 칸반보드처럼 플랜에 올리면 그 플랜이 알아서 돌아가서 PR까지 날리는 걸 그냥 알아서 실행하는 식으로, 개발 공정 자체를 자동화하려고 계획하고 있습니다.

그리고 개발자의 암묵지를 형식지화하는 데 좀 더 힘을 쓰게 될 것 같아요. 예를 들어 ‘지금의 우리 트래픽 상황에서는 이런 서버 아키텍처를 가져야 돼’ 같은 건 사실 AI가 결정해 주지 못합니다. 그런 노하우들을 최대한 하네스 엔지니어링 안에 녹여서, 딸깍딸깍으로 개발할 수 있게 진화시키는 걸 목표로 하고 있습니다.

마치며

개인적으로 하네스 엔지니어링은 팀 차원의 출시 인프라라고 생각합니다. 개인 단위에서의 하네스 엔지니어링도 되게 많이 쓰고 있지만, 팀 단위로 도입하면 이런 효과들을 얻을 수 있다는 이야기를 들려드리고 싶었습니다. 이상입니다.