황민호 수석님 x AI Frenz <하네스 엔지니어링 60분 스팀팩> Q&A 세션 - 사람들은 무엇을 궁금해 하나? 그것이 궁금했습니다. 가끔 참가자들의 열기가 행사를 끌어 올리는 경우가 있는데, 어제가 그랬습니다. 행사 취지대로 메인 세션은 입문자를 위한 온보딩에서 새로 나온 Dynamic Workflow 소개까지 알차게 진행됐는데…. * [AI 프렌즈] 하네스 엔지니어링 60분 스팀팩 (황민호 수석) * 발표 자료 하지만, 진짜 본 게임은 Q&A 세션. 초반엔 가벼운 질문들이 오가는 듯 했지만데, 어느 순간 숨어있던 하네스 고민러들이 하나 둘 등장. 그렇게 대화는 하네스와 AI 워크플로우에 대한 현실 고민, 조직 단위 에이전틱 시스템의 미래 비전으로 발전해갔습니다. 킬포는 하네스에 대한 주요 질문들에 대해 황수석님은 이미 만들어 놓으신 또 다른 하네스로 답하셨다는 것. ‘하네스를 쓰다보면 이런 게 필요하겠지? 음, 그럼 또 이런 하네스를 만들어 놔야겠군~’ 세심한 휴먼 루프로 어디로 튈지 모르는 일반인의 에이전트 라이프 곳곳에 미리 하네스를 쳐두신 느낌. 이러니까 좋은 하네스 나오지. 하네스라는 방법론이 아니라, 그걸 쓰는 사람의 관점과 정성이 관건이었습니다. 세상의 이치는 비슷. 메인 세션보다 더 흥미진진했던 Q&A 세션 요약. 지금 하네스와 에이전트에 대한 사람들의 관심사와 고민의 방향을 읽어볼 수 있습니다. ## 여전히 헷갈리는 기본 개념 Q. 오케스트레이션도 에이전트인지? 각 에이전트가 잘 작동하도록 조율하는 역할은 누가 하는지? Claude.md의 역할과 오케스트레이션의 역할은 어떻게 다른지. A. 오케스트레이터를 별도의 에이전트로 둘 수도 있지만, 황수석님은 오케스트레이터를 스킬로 구현해 메인 에이전트에 탑재. 각 에이전트의 역할과 순서 등을 메인 에이전트에서 조율하게 하셨다고. CLAUDE.md는 역할이 다르며, ‘프로젝트 주제 + 하네스 히스토리’를 담는 용도. ## 다른 하네스 프로젝트와 황수석님의 revfactory 하네스와의 차이 Q. 요즘 유행하는 oh-my 시리즈와의 차이는 무엇인가? A. oh-my시리즈, gstack, superpowers 같은 프레임웍은 자주 쓰는 패턴을 미리 정교하게 깎아 놓은 완성형 하네스. 반면 황수석님의 하네스는 사용자의 요청에 맞춰 그때 그때 하네스를 구성해주는 ‘메타 하네스’ 좋은 하네스를 구성하는 템플릿들이 미리 설계되어, 내 의도만 주입하면 완성도 높은 하네스를 만들어 줍니다. * 목적이 일치하는 잘 만들어진 하네스를 그냥 가져다 쓰고 싶을 때 -> 기존 프레임웍 * 나만의 하네스를 잘 만들고 싶을 때 -> 메타 하네스로 직접 내 요구사항을 담은 하네스 만들어보기. 메타 하네스 없이도 만들 수 있지만, 좋은 하네스를 만드는 템플릿이 있다면 훨씬 더 내가 원하는 목적지를 쉽게 갈 수 있을 것입니다. 나도 사실 몇 가지 이유로 ‘프롬 스크래치’로 만들어 썼는데, 이번 세션 들으며 황수석님의 메타 하네스를 한 번 트라이해 봐야겠다는 생각이 들었습니다. * 황민호 수석님의 메타 하네스 for 클로드 코드 Q. 메타 하네스로 특별한 개발 지식 없이 순식간에 만들긴 했는데…‘하네스를 깎습니다’는 것은 무엇인가? A. ‘깎는다’는 것은 메타 하네스가 만들어 준 에이전트나 스킬 파일들을 내 입맛에 맞게 교정하는 것. 다음과 같은 방법이 있습니다. 1) 스킬이나 에이전트 md 파일을 열어서 직접 그 안에 나의 노하우를 추가하거나 (일잘러의 업무 매뉴얼 편집) 2) 쓰고 있는 AI에게 고도화 방향을 물어보고 업데이트 (메타 교정) 3) 개선하고 싶은 에이전트를 불러 1:1 커피챗 에이전트 활용. 특정 에이전트 선택해서 포스트모템 및 개선 방향 잡아가는 오피스 아워를 가져보기(하네스 잡도리) * 황민호 수석님의 에이전트 잡도리 1:1 세션 하네스 결론은 개발 못해도 에이전트 깎을 수 있고, 나아가 카파시의 AutoResearch 스타일의, 에이전트가 스스로를 고도화하는 자율적인 자가 개선 루프에 대한 이야기로도 살짝 확대됨. Claude Code 자체가 셀프 개선이 가능한 구조라고. ## 타 도구, 시스템으로의 전환과 연동, 교차 검증 클로드 코드 말고 내가 쓰는 다른 도구에서도 되나? 가장 많이 반복된 최대의 관심사. Q. 안티그래비티나 커서, Codex CLI에서 메타 하네스 쓸 수 있나? ChatGPT에서도 하네스 시스템 구성할 수 있나? 오픈 소스 LLM에서도 쓸 수 있나? 오픈 클로와 연동할 수 있나? - 안티그래비티 - 이미 제공중. Gemini 3.5 Flash 기반이라 약 4배 빠름 (단, 최종 결과 품질은 그래도 Claude가 더 낫다고) - Codex CLI - Codex가 클로드코드용 플러그인을 공식적으로 배포했지만, 개발에만 특화되어 있어서 범용성있는 Codex CLI를 별도로 만드심. Codex에서는 이미지도 만들 수 있어 관련 전용 스킬도 따로 만들어 놓으심👍👍👍 - ChatGPT용 - 에이전트가 하나만 동작해 멀티 에이전트 지원 어려워 안 만듦. - 오픈소스 LLM - 컨버팅은 가능하나 성능 한계 + 에이전트 다루는 방식 차이로 쉽지 않음. 에이전트 설정은 표준화 안 돼 프로바이더마다 달라 공유 불가. 단, 스킬은 표준이라 재사용 가능한데, 암튼 뭔가 더 해야 하는 느낌이었습니다. 오프라인 독립망에서 VLM 서버 구동하고 여러 가지를 해서 원활하게 코딩해 보신 경험 있다고. * 표준 에이전트 스킬 (OpenAI, Anthropic, Google 공통) - 오픈클로 - 단독 성능은 낮아서, 오픈클로로 접속 후 내부적으로 Claude Code를 연결해 쓰는 패턴을 보셨다고. 그리고 별도의 오픈클로용 하네스도 있다는 댓글 제보. Q. 이미 개발된 기존 프로젝트에 적용하려면? LangGraph같은 전문 오케스트레이션 시스템을 쓰라고도 하던데? A. 하네스로 뭘 하려는 지가 가장 중요(전체 운영 vs 신규 기능 추가 등). 목적에 맞춰 시스템 구성해야 함. 예를 들어, 신규 기능을 A, B, C안으로 접근해 각각 개발하고 시뮬레이션 한 후 선택하는 하네스 등을 생각해 볼 수 있음. 하고자 하는 작업에 따라 케바케. LangGraph는 에이전틱 서비스 설계에 특화돼어 있지만, 요즘은 Claude Code/Antigravity CLI를 시스템에 통째로 탑재, claude -p 옵션으로 호출해 결과를 리턴받는 방식도 쓴다고(사전 워크플로우 설계 불필요). 개개인의 에이전트에서 점점 조직 전체 워크플로우의 에이전틱 시스템을 향해가는 엔터프라이즈향 LLM 하네스. 여기서도 시스템 빌딩 vs LLM 하네싱의 팽팽한 텐션이 느껴졌습니다. 이것이 결국 Agentic Transformation인가. Q. QA만 Claude가 아닌 Codex와 연결해 교차 검증 가능한가? A. 가능. 해당 에이전트에 (ex) Fact-checker ‘항상 Codex CLI 스킬로 검증하도록 수정해줘’라고 지시하면, Claude가 한 작업을 Codex가 교차 검증. ## 기승전 비용 vs 품질 트레이드 오프 Q. 에이전트를 쓰면 낮은 모델이나 추론 레벨에서도 좋은 결과 얻을 수 있나? A. 에이전트별로 모델 지정 가능(Anthropic도 권장). 단, 이런 ‘모델 티어링’은 개개인이 판단 및 검증하기 힘드므로, 검증 체계 없으면(잘 모르면), 일단 가장 좋은 모델 쓰세요~(지난 번에도 같은 결론) 추론 레벨도 중요한데 xhigh는 high 대비 약 4배 비용 + 시간 증가, max는 너무 오래 걸려 권장하지 않음. So, high 또는 xhigh 중 선택 권장. 그러면 모델x추론 교차 조합 ‘Opus+high’ vs ‘Sonnet+xhigh’는 누가 이길까? 모델 차이가 더 클 것으로 보지만 실험은 안 해봐서 확답 유보 ## 다단계 위임과 대규모 시스템 - 에이전틱 시스템은 어디까지 가게 될까? Q. 점점 경영학적 관점으로 보면 에이전트 하이어라키가 깊어질 텐데? 또, 경영학적 이론들을 에이전트 팀에 접목하려는 시도는 없는지? A. 에이전트 위에 에이전트가 3-4단계 깊어지면 의도대로 동작 안 할 가능성. 현재 Claude는 무한 루프, 토큰 폭발 방지 등을 위해 서브 에이전트 추가 하이어라키를 막아둠. 제어 난이도 높아지고, 컨텍스트 관리, 프로토콜 설계 필요. Q. 수백 명 규모의 연구소급 성과를 내는 에이전트 시스템 가능할까? 가능하려면 어떤 게 필요할까? A. 개인적으로 ‘군집 제어(swarm control)’에 관심 있으시다고. 현재 에이전트 팀(Claude code experiment 기능)은 커뮤니케이션 비용이 30%정도 더 든다고. 특히 브로드캐스트에서는 잠자던 1,000개 에이전트 전부에 비용을 발생시키는 토큰 폭발 문제 발생함. 정말 필요한 에이전트에게만 커뮤니케이션하는 기술 필요. 앞으로 에이전트 팀 운영은 점점 경영학적 문제로 수렴할 것. 관련 논문들도 나오고 있음. 이렇게 이제 시작하시는 분들을 위한 스타터 핸즈온이라던 세션은 어느새 ‘어떻게 만드나(How)’를 떠나 ‘이걸 어디까지, 어떤 조직 구조로 굴릴 것인가’의 깊은 문제로 넘어가 있었습니다. 결국 에이전트 시스템은 조직 설계의 문제. 하네스의 미래는 경영학인가. 아니면 미래의 경영학이 곧 하네스가 되는 걸까. 경영학의 Ax ㅎㅎ ——— 이렇게 Q&A 세션만 별도로 1시간을 달렸는데(원래 행사 공지는 메인 1시간), 모든 질문에 빠짐없이 스윗하게 답해주신 황수석님(Minho Hwang), 감사드립니다. 좋은 행사 만들어주신 AI Frenz와 행사의 깊이를 더해 주신 참가자분들도. 요즘 일하는 방법에 대한 고민이 많았는데, 나긋나긋하게 설명해 주시는 걸 듣고 있자면 ‘그래, 이 길로 가자’는 결론에 절로 빠져드네요.

최근 AI 프렌즈가 주최한 하네스 엔지니어링 세션에 다녀왔습니다. 메인 세션도 알찼지만 진짜 백미는 현업 엔지니어들의 질문이 쏟아진 Q&A 시간이었습니다. 에이전트를 실무에 적용하려는 개발자들의 생생한 고민을 엿보았습니다.

완성형 프레임워크와 메타 하네스의 경계

자주 쓰는 패턴을 미리 고정해 둔 완성형 프레임워크와 달리, 사용자의 요구에 맞춰 에이전트 팀을 동적으로 구성하는 메타 하네스(meta-harness) 가 실무적인 대안으로 떠올랐습니다. oh-my 시리즈나 gstack 같은 도구는 특정 패턴을 정교하게 깎아 놓은 형태입니다. 반면 이번에 공유된 설계는 사용자의 의도에 어울리는 최적의 팀 아키텍처와 스킬을 그때그때 생성합니다. 구조가 유연합니다. 나만의 워크플로우를 설계하고 싶을 때 유용합니다. 나도 그동안 프롬 스크래치 방식을 고집했는데 메타 하네스 도입을 고민합니다.

자동 생성된 에이전트 정의와 스킬 파일을 내 업무 노하우에 맞게 정밀하게 깎아 나가는 과정이 핵심입니다. 마크다운 파일을 열어 직접 예외 케이스를 추가하거나, AI에게 개선 방향을 물어보며 명세서를 업데이트합니다. 1-1 대화형 스킬로 에이전트와 직접 대화하며 구조적 결함을 보완하는 방법도 효과적입니다. 손이 많이 갑니다. 도구의 완성도보다 도구를 다듬는 사람의 정성이 품질을 결정합니다.

멀티 에이전트 제어와 도구 연동의 현실

현업에서는 다양한 CLI 도구와 타사 모델을 엮어 교차 검증을 수행하는 하네스 설계에 관심이 높습니다. Gemini 기반의 Antigravity CLI 환경에서도 하네스를 구동하려는 시도가 활발합니다. 실제 적용 시 속도가 4배 가까이 빠릅니다. 다만 최종 결과물의 정밀함은 Claude가 앞섭니다. 특성이 다릅니다. 오픈소스 LLM은 에이전트를 다루는 방식이 프로바이더마다 달라 표준화가 어렵습니다.

이종 모델을 조합해 결과물 완성도를 검증하는 아키텍처도 실무에서 자주 쓰입니다. Claude가 작성한 코드나 텍스트를 Codex CLI 스킬로 검증하도록 에이전트에 지시하는 방식입니다. 품질이 올라갑니다. 무거운 오케스트레이션 프레임워크를 올리는 대신 CLI 환경을 시스템에 통째로 탑재해 claude -p 옵션으로 호출하는 가벼운 워크플로우도 선호됩니다. 단순합니다.

군집 제어와 비용의 트레이드 오프

에이전트 계층이 3단계 이상 깊어지면 컨텍스트 제어가 어려워지고 비용이 급상승합니다. 무한 루프에 빠지거나 토큰을 과도하게 소비하는 문제가 쉽게 발생합니다. 모델 티어링을 정교하게 설계하기 전까지는 가장 성능이 좋은 모델을 쓰는 편이 안전합니다. 비용 차이가 큽니다. 추론 레벨은 xhigh가 high 대비 비용이 4배 높은 만큼 태스크 중요도에 따라 신중하게 조합해야 합니다.

수백 명 규모의 연구소급 에이전트 팀을 운영하려면 단순한 오케스트레이션을 넘어 군집 제어 기술이 들어와야 합니다. 모든 에이전트에 정보를 동시에 뿌리는 브로드캐스트 방식은 불필요한 토큰 소모를 일으켜 비용 폭탄을 던집니다. 정말 필요한 에이전트끼리만 통신하도록 통로를 제한하는 프로토콜 설계가 필수입니다. 에이전트 시스템 설계는 조직을 설계하는 경영학적 관점과 맞닿아 있습니다. 구조가 닮았습니다.

훌륭한 에이전트 시스템을 만드는 힘은 방법론보다 에이전트를 일상에서 다듬는 사람의 관점과 정성에 있습니다. 일하는 방식이 바뀌기 시작했습니다.

요약

  • 완성형 프레임워크와 달리 사용자의 요구에 맞춰 에이전트 팀과 스킬을 동적으로 생성해 주는 메타 하네스가 복잡한 도메인 해결에 유용합니다.
  • 서로 다른 CLI 도구와 LLM 프로바이더를 연동하여 교차 검증을 수행하는 가벼운 워크플로우 설계가 실무진의 현실적인 대안입니다.
  • 에이전트 계층이 깊어질수록 토큰 폭발과 제어 난이도가 급상승하므로, 브로드캐스트를 제한하는 군집 제어 프로토콜 설계가 필수적입니다.