사람 오케스트레이터, Hermes Agent, 서브 코딩 에이전트가 함께 개발하는 구조

Zero Human Studio의 최근 작업은 한 사람이 모든 코드를 직접 쓰는 방식과도 다르고, AI에게 “알아서 만들어줘”라고 맡기는 방식과도 다르다. 실제 구조는 그 중간에 있다. 사람은 방향과 품질 기준을 정하고, Hermes Agent는 사람과 직접 대화하며 전체 작업을 조율하고, 필요할 때 Claude Code 같은 서브 코딩 에이전트가 구체적인 구현 단위를 맡는다.

이 글은 사이트에 남겨두고 싶은 작업 구조의 기록이다. 타자연습을 만들고, UX를 고치고, 포스트를 추가하고, 사이트 구조를 정리하는 과정에서 실제로 어떤 역할 분담이 있었는지 정리한다. 중요한 것은 “AI가 개발했다”라는 간단한 문장이 아니다. 어떤 판단은 사람이 했고, 어떤 조율은 Hermes Agent가 했고, 어떤 구현은 서브 에이전트가 맡았는지를 구분하는 일이다.

세 층으로 나뉜 작업 구조

현재 작업 구조는 크게 세 층으로 볼 수 있다.

• 사람 오케스트레이터
• Hermes Agent
• 서브 코딩 에이전트

사람 오케스트레이터는 제품의 방향을 정한다. 예를 들어 “타자연습은 단순 속도 측정기가 아니라 반복해서 쓰는 연습 공간이어야 한다”, “포커스가 절대 풀리면 안 된다”, “공개 글에서 특정 목적이 너무 노골적으로 드러나면 안 된다” 같은 기준은 사람에게서 나온다. 이 기준은 코드로 바로 환원되지 않는다. 사용자 감각, 공개 품질, 사이트의 장기 방향이 섞인 판단이기 때문이다.

Hermes Agent는 이 기준을 작업 가능한 단위로 바꾼다. 레포 상태를 확인하고, 관련 파일과 문서를 읽고, 어떤 부분을 수정해야 하는지 추적하고, 작업 목록을 세우고, 검증 명령을 실행하고, 결과를 다시 사람에게 보고한다. 사람과 직접 대화하는 중심 에이전트이기 때문에, 단순한 코드 작성자보다 제품 매니저와 기술 리드 사이에 가까운 역할을 한다.

서브 코딩 에이전트는 더 구체적인 구현 덩어리를 맡는다. 예를 들어 Claude Code는 /typing의 큰 컴포넌트 구조를 만들거나, 반복적인 코드 수정과 파일 연결을 처리하는 데 적합했다. 단, 서브 에이전트의 결과는 그대로 최종본이 되지 않는다. Hermes Agent가 다시 읽고, 빌드하고, 브라우저에서 확인하고, 사람의 피드백과 맞지 않으면 되돌아가 수정한다.

사람 오케스트레이터의 역할

사람의 역할은 줄어든 것이 아니라 위치가 바뀌었다. 직접 모든 파일을 열어 한 줄씩 고치는 시간이 줄어들 수는 있지만, 어떤 결과가 맞는지 판단하는 일은 더 중요해졌다.

Zero Human Studio 작업에서 사람 오케스트레이터가 한 일은 대략 이렇다.

• 사이트가 도구 허브인지, 실험실인지, 블로그인지 방향을 정한다.
• 타자연습처럼 반복 사용성이 있는 기능을 별도 제품 레이어로 볼지 결정한다.
• “기능이 있음”과 “실제로 쓰기 좋음”의 차이를 지적한다.
• 포커스, 스크롤, 입력 리듬처럼 자동 테스트만으로는 놓치기 쉬운 UX 기준을 세운다.
• 공개 포스트에서 어떤 표현은 빼고, 어떤 표현은 남길지 판단한다.
• 최종적으로 커밋하고 공개해도 되는 품질인지 결정한다.

특히 타자연습 작업에서 이 역할이 분명했다. 에이전트는 “다음 지문으로 넘어간다”고 구현할 수 있다. 하지만 사용자는 “다음 지문으로 넘어가는 동안 입력창 포커스가 풀리면 안 된다”고 느낀다. 이 차이는 제품을 실제로 쓰는 사람의 감각에서 나온다.

Hermes Agent의 역할

Hermes Agent는 사람과 가장 가까운 실행 계층이다. 텔레그램으로 요청을 받고, 현재 대화의 맥락을 유지하고, 필요한 스킬과 기억을 불러오고, 로컬 레포와 브라우저와 터미널을 오가며 작업한다.

이번 사이트 작업에서 Hermes Agent가 맡은 일은 다음에 가까웠다.

• 작업 전 repo, branch, remote 상태 확인
• 기존 계획 문서와 포스트, 코드 구조 읽기
• 작업을 작은 todo로 쪼개기
• 직접 파일 수정 또는 서브 에이전트에게 구현 위임
• lint, build, 로컬 서버, 브라우저 QA 실행
• 금칙 표현이나 누락된 콘텐츠 검색
• 커밋 단위 정리와 원격 push
• 사람에게 무엇이 되었고 무엇은 아직 확인하지 않았는지 보고

이 구조에서 Hermes Agent는 “하네스”에 가깝다. 하나의 모델 응답이 아니라, 대화, 파일, 명령 실행, 브라우저 확인, 기억, 스킬, 서브 에이전트 호출을 묶어 작업이 끝까지 진행되도록 잡아주는 실행 틀이다. 사람의 요청은 자연어지만, 실제 결과물은 파일 변경, 빌드 로그, 로컬 페이지 검증, 커밋으로 남아야 한다. 그 사이를 이어주는 것이 Hermes Agent의 역할이다.

서브 코딩 에이전트의 역할

서브 코딩 에이전트는 독립적인 작업자에 가깝다. Claude Code 같은 코딩 에이전트는 큰 코드베이스 안에서 컴포넌트를 만들고, 타입 오류를 고치고, 반복적인 파일 수정을 빠르게 수행할 수 있다. 사람이나 Hermes Agent가 모든 코드를 직접 작성하지 않아도, 한 번에 꽤 큰 구현 단위를 진행할 수 있다.

하지만 여기에는 조건이 있다. 서브 에이전트에게 넘길 작업은 충분히 작고 검증 가능해야 한다.

좋은 요청은 이런 형태다.

• /typing에 자리연습, 낱말연습, 단문연습, 장문연습, 속도측정 모드를 분리해 구현한다.
• 자리연습은 IME 조합값이 아니라 KeyboardEvent.code 기반으로 처리한다.
• Space 입력 시 가상 키보드의 Space 키와 양쪽 엄지 가이드를 표시한다.
• 낱말연습과 속도측정 지문은 현재 줄과 다음 줄, 최대 두 줄만 보여준다.

반대로 “사이트를 더 좋게 만들어줘” 같은 요청은 너무 넓다. 서브 에이전트는 넓은 요청도 시도할 수 있지만, 결과가 제품 기준과 어긋날 가능성이 커진다. 그래서 Hermes Agent가 중간에서 요구사항을 좁히고, 결과를 검증 가능한 기준으로 바꿔야 한다.

실제 작업 흐름

하나의 작업은 보통 이런 순서로 흘러간다.

1. 사람이 문제를 말한다.
2. Hermes Agent가 repo 상태와 기존 문맥을 확인한다.
3. 필요하면 관련 스킬, 계획 문서, 이전 포스트, 코드 파일을 읽는다.
4. 작업을 작은 단위로 나눈다.
5. 직접 구현하거나 서브 코딩 에이전트에게 구현 단위를 맡긴다.
6. 결과 코드를 다시 읽고 필요한 수정을 한다.
7. lint와 build를 돌린다.
8. 로컬 서버나 브라우저에서 실제 사용자 흐름을 확인한다.
9. 검색으로 금칙 표현, 누락된 라우트, sitemap 반영 여부를 확인한다.
10. 의미 있는 단위로 커밋하고 원격에 push한다.
11. 사람에게 완료된 것과 아직 production에서 별도 확인해야 할 것을 나눠 보고한다.

이 순서는 느려 보이지만, 실제로는 재작업을 줄인다. 특히 웹 제품에서는 “빌드 성공”만으로 충분하지 않다. 타자연습처럼 입력 리듬이 중요한 기능은 브라우저에서 직접 글자를 쳐봐야 한다. 포스트 작업은 Markdown 파일이 생겼다는 사실보다 /posts, 상세 페이지, sitemap에서 실제로 보이는지가 중요하다.

타자연습 작업에서 드러난 구조

타자연습은 이 작업 구조가 잘 드러난 사례였다. 처음에는 제품 레이어로 만들기 위한 플랜을 세웠고, Claude Code를 이용해 큰 뼈대를 구현했다. 그 뒤 사람이 직접 사용 흐름을 보며 불편한 점을 지적했다.

예를 들어 다음과 같은 피드백이 있었다.

• 입력란 포커스와 스크롤을 절대 빼앗지 말 것
• 한 지문이 끝난 뒤 습관적으로 누르는 Space나 Enter가 다음 지문의 오타가 되지 않게 할 것
• 낱말연습과 속도측정 지문은 두 줄만 보여줄 것
• 자리연습은 1단계부터 8단계까지 직접 이동 가능하게 할 것
• 가상 키보드는 실제 키보드처럼 보이게 할 것
• 쌍자음, 쌍모음, 기호 입력에서 Shift 조합을 보여줄 것
• 한글 음절 내부도 자모 단위로 손가락 가이드가 따라가게 할 것
• 공백 차례에는 Space 키와 양쪽 엄지 가이드를 표시할 것

이런 요구사항은 단순 기능 목록이 아니다. 실제 사용자의 손과 시선이 어디에 머무르는지를 기준으로 한 판단이다. Hermes Agent는 이 요구를 코드의 acceptance criteria로 바꾸고, 서브 에이전트나 직접 수정으로 구현한 뒤, 빌드와 브라우저 확인으로 다시 닫았다.

글쓰기와 공개 품질에도 같은 구조를 쓴다

이 구조는 코드에만 쓰이지 않았다. 사이트의 글을 작성하고 고치는 과정에도 똑같이 적용됐다. 사람이 “이 표현은 너무 노골적이다”, “이 글에는 스프라이트와 이미지 자산, 8단계 재구성, Claude Code 작업 흐름이 빠졌다”라고 말하면, Hermes Agent는 기존 포스트와 작업 이력을 다시 확인하고 글을 보강한다.

여기서도 중요한 것은 양산이 아니다. 그냥 비슷한 문장으로 페이지 수를 늘리는 글은 사이트에 도움이 되지 않는다. 대신 실제 작업에서 무엇을 판단했고, 어떤 문제가 있었고, 어떻게 고쳤는지를 남기면 사이트 안에서만 나올 수 있는 콘텐츠가 된다.

그래서 작업 관련 포스팅은 앞으로도 단순 홍보문보다 회고와 작업 로그에 가깝게 남기는 편이 맞다. 사람의 기준, Hermes Agent의 조율, 서브 에이전트의 구현, 검증 결과가 함께 드러날 때 이 사이트의 제작 방식이 콘텐츠가 된다.

이 구조의 장점

이 방식의 장점은 속도만이 아니다. 더 중요한 것은 판단과 실행을 분리할 수 있다는 점이다.

사람은 모든 세부 파일을 직접 열지 않아도 된다. 대신 무엇이 좋은지, 무엇이 싫은지, 어떤 방향으로 가야 하는지를 더 자주 말할 수 있다. Hermes Agent는 그 판단을 놓치지 않고 작업 항목으로 바꾸고, 서브 에이전트는 실제 코드 변경을 빠르게 시도한다.

또 작업 기록이 남는다. 계획 문서, 포스트, 커밋, 빌드 로그, 검증 결과가 쌓이면 나중에 “왜 이렇게 만들었는지”를 설명할 수 있다. 이것은 작은 사이트에서 생각보다 중요하다. 기능만 있는 사이트보다, 만든 이유와 고친 이유가 보이는 사이트가 더 신뢰롭게 느껴지기 때문이다.

이 구조의 한계

물론 이 구조가 모든 문제를 자동으로 해결하지는 않는다. AI 에이전트는 때때로 기능이 있다고 착각하거나, 실제 화면에서 어색한 흐름을 놓치거나, 공개 글에서 말투가 과하게 정형화될 수 있다. 서브 에이전트가 만든 코드는 타입은 맞아도 제품 감각이 부족할 수 있다.

그래서 마지막 판단은 계속 사람에게 남아야 한다. Hermes Agent도 스스로 확인할 수 있는 것은 확인하지만, 사용자가 “이건 별로다”, “이 부분이 누락됐다”, “너무 노골적이다”라고 말하는 순간 기준이 더 선명해진다. 그 피드백이 다시 다음 작업의 품질 기준이 된다.

앞으로의 운영 방식

앞으로 Zero Human Studio의 작업은 이 구조를 더 명시적으로 가져가도 좋다고 본다. 기능을 만들 때는 플랜을 먼저 쓰고, 구현은 작은 단위로 나누고, Claude Code 같은 서브 코딩 에이전트는 반복 구현에 활용한다. Hermes Agent는 그 전체 흐름을 잡고, 빌드와 브라우저 확인, 포스트 정리, 커밋과 보고까지 이어간다.

글 하단에는 이 작업이 어떤 하네스에서 나온 기록인지 밝혀두려 한다. 이것은 “AI가 썼다”는 단순 고지가 아니라, 사람과 직접 소통하며 작업 전체를 총괄한 Hermes Agent의 사고 과정과 의사결정 과정을 기록한 글이라는 맥락을 남기기 위한 장치다.

마무리

AI 에이전트 개발에서 중요한 질문은 “사람이 필요 없어지는가”가 아니다. 더 현실적인 질문은 “사람은 어떤 판단을 하고, 에이전트는 어떤 실행을 맡으며, 그 사이를 누가 끝까지 조율하는가”다.

Zero Human Studio의 현재 답은 사람 오케스트레이터, Hermes Agent, 서브 코딩 에이전트의 세 층 구조다. 사람은 방향과 기준을 잡고, Hermes Agent는 작업 전체를 조율하고 검증하며, 서브 에이전트는 구현 단위를 빠르게 수행한다. 이 구조가 완벽하다는 뜻은 아니다. 다만 지금까지의 작업에서는, 혼자 손으로 모두 만드는 방식보다 더 넓게 움직이면서도 최종 판단의 책임을 흐리지 않는 현실적인 방식이었다.