→ 옆으로 밀어 시간대별 흐름 보기
서브에이전트의 원문뿐 아니라 마스터가 신뢰한 요약·결론도 오염될 수 있으므로 외부 입력처럼 검증해야 한다는 의견이 나왔다. 서브에이전트는 단순 페르소나 프롬프트가 아니라 도메인, 작업 환경, 샌드박스를 분리한 독립 실행 단위여야 한다고 설명했다. 기획·검증 등 역할별 에이전트를 분리하고 라우팅과 작업 분배를 설계하는 것이 핵심으로 논의됐다.
AI 에이전트는 AI가 일할 환경과 작업 매뉴얼을 마련하고, 프로세스 안에서 작업을 분해·라우팅·실행하게 하는 구조라는 설명이 이어졌다. AI API를 특정 프로세스에 적절히 녹여 결과를 만드는 모든 것을 에이전트로 볼 수 있다는 개인적 정의가 제시됐다. 실제 설계에서는 AI에 맡길 부분과 스크립트로 처리할 부분을 도메인 경험으로 구분하는 것이 중요하다고 정리됐다.
Claude 서비스 전반에 일부 장애가 발생했고, Claude Sonnet 5의 오류 증가가 조사 중으로 안내됐다. 영향 대상에는 claude.ai, Claude API, Claude Code, Claude Cowork가 포함됐다. 이후 수정 사항 적용 뒤 복구 상태를 관찰 중이라는 업데이트가 나왔다.
Claude Code는 이미 코딩 에이전트이므로, 하네스를 처음부터 거대하게 만들기보다 에이전트가 잘 작동할 환경과 지침을 구성하는 관점이 제시됐다. 서브에이전트 정의가 SKILL.md와 유사한 프론트매터·본문 구조이며 메인이 이를 호출하는 형태라는 관찰이 나왔다. 훅과 구조화된 문서가 하네스의 주요 구성 요소로 언급됐다.
기성 하네스를 활용하는 편이 낫다는 의견과 바닥부터 구현해 에이전트 플랫폼을 이해해보라는 의견이 함께 나왔다. 슈퍼파워스는 대략 가져다 쓰기 좋은 도구로, moai는 개인 작업 방식에 잘 맞는 도구로 언급됐다. 도구를 통째로 재구성하기보다 필요한 부분을 체리픽하는 접근도 논의됐다.
워크스페이스별 샌드박스를 만들고 스킬로 호출하는 운영 방식이 제안됐다. 내부망에서는 이더넷 IP로 호출하거나 MCP로 노출할 수 있으며, 서버에 구축한 뒤 Tailscale로 접근하는 사례가 언급됐다. 소형 LLM 기반 위키형 지식베이스와 초기 세팅·초안 생성용 워크스페이스 활용도 논의됐다.
API 서버에서 AI 결과를 훅으로 외부에 전송한 뒤, 수신한 데이터를 AI가 인식하는 방식에 대한 질문이 나왔다. 대화 중 MCP를 만들면 된다는 방향을 스스로 도출했고, 이후 기능별 MCP라는 설계 원칙이 제안됐다.
요약 오염과 검증 문제를 계기로 TDD의 중요성이 언급됐다. 다만 AI가 생성한 테스트를 그대로 쓰는 것이 TDD인지에 대한 회의가 나왔고, SDD·TDD·FDD 같은 명칭보다 실제 검증과 개발 프로세스가 더 중요하다는 의견이 제시됐다.
AI 도구와 스킬은 필요한 때 가져와 해체·분석·적용하거나, 먼저 적용한 뒤 나중에 분석하는 방식이 논의됐다. 독창적으로 만든 것이라 생각해도 외부에 유사 사례가 많다는 경험담이 나왔으며, 맨땅에서 만들어 보는 과정도 이후 확장 속도를 높일 수 있다는 의견이 나왔다. market-scout 에이전트 대신 insane-resarch를 사용하려는 사례도 언급됐다.
AI를 직접 만드는 일보다 활용하는 일은 공식 문서와 구성 요소가 이미 갖춰져 있어 상대적으로 쉽다는 의견이 나왔다. 앞으로는 누가 더 적절하게 레고처럼 조합하느냐의 경쟁이며, 리서치 역량과 엔지니어링 역량의 차이도 중요하다는 짧은 논의가 이어졌다.
AI 쇼츠 자동화 제작이 쉽지 않다는 어려움이 공유됐고, 결과물에 휴먼터치가 필요한지 질문이 나왔다. 구체적인 해결책은 이어지지 않았다.
하네스가 아직 어렵고 오케스트레이션으로 코딩하는 것만으로도 벅차다는 반응이 나왔다. 한 참여자는 대화와 재검토를 통해 구축 과정에서 막혔던 개념적 벽을 넘고 방향을 잡았다고 공유했다. 에이전트 개념을 문서화하고 향후 커뮤니티에 공유하겠다는 계획도 언급됐다.