AI 코딩 에이전트는 코드를 작성할 수 있습니다. 하지만 더 긴 작업을 위해서는 여전히 조정(coordination)과 품질 관리(quality control)가 필요합니다. 누군가는 목표를 추적하고, 열린 질문을 해결하며, 변경 사항을 검토하고, 완성된 작업이 승인 기준을 충족하는지 확인해야 합니다.

Triglav는 이 워크플로우를 Claude Code와 Codex 주변에 배치했습니다.

Staff 에이전트가 계획하고 위임합니다. 시니어(Seniors)들이 개별 과제를 구현합니다. 공유 작업 게시판(shared job board)은 에이전트들이 질문하고, 연구원들(researchers)과 상담하며, 제안에 이의를 제기하고, 결정을 기록할 수 있게 합니다. 로컬 검토 패널(local review panel)은 배포 전에 모든 변경 사항을 확인합니다. 그 다음에는 Copilot 검토가 진행되며, 이는 구성되고, Staff가 직접 실행하는 CI(Continuous Integration) 체크가 뒤따릅니다.

저는 클라이언트입니다. 팀이 해결하지 못하는 질문에 답하고, 무엇을 출시할지 결정합니다.

Triglav는 첫 10일 동안 저의 자체 저장소에서 41개의 작업을 실행했으며 그중 34개를 완료했습니다. 현재 이 주를 기점으로 공개되었습니다.

GitHub logo adam-drag / triglav

Claude Code와 Codex 에이전트를 작은 소프트웨어 컨설팅처럼 실행하는 로컬 우선 오케스트레이터. Staff가 계획하고, 시니어들이 구축하며, 검토자들이 확인하고, 연구원들이 조언합니다. 대시보드에서 사용자가 결정합니다. MCP 서버, Docker 및 MySQL을 사용하며 Linear, Jira 또는 GitHub 티켓에서 작동합니다.

Triglav

중요

Triglav는 사용자 자신의 Claude Code 또는 Codex 계정을 사용하므로, 그 사용량은 사용자 플랜에 포함됩니다.

• Claude Code 및/또는 Codex가 필요합니다. 이들은 사용자의 장치에 설치되어 있고 로그인되어 있어야 합니다. Triglav 자체에는 모델이 포함되어 있지 않으며 AI API를 호출하지도 않고 API 키를 요청하지도 않습니다. 오직 작업만 조율(orchestrate)합니다. 즉, 이미 가지고 있는 에이전트 CLI를 시작하고 조정하며, 이 에이전트들은 로그인된 계정을 사용합니다.
• 모든 사용량은 사용자 본인의 계정으로 청구됩니다. Senior, 로컬 코드 리뷰, Researcher 실행, Operator 메시지 등 모든 에이전트의 작업 턴(turn)은 Claude Code 또는 Codex 로그인을 통한 요청입니다. 만약 해당 로그인이 API 키를 사용하고, 종량제(pay-as-you-go billing) 방식이거나 플랜을 초과하는 추가 사용량이 발생한다면, Triglav의 작업 역시 그 조건에 따라 사용자에게 청구됩니다. Copilot 리뷰 루프도 GitHub Copilot 할당량을 사용할 수 있습니다.
• 일부는 클릭 없이 시작됩니다. 직원이 깨어날 때...

View on GitHub

본 게시물의 스크린샷들은 가상의 웹 샵인 데모 프로젝트를 보여줍니다. 홈 페이지, 리뷰, 인박스 스크린샷은 에이전트와 리뷰어의 출력이 스크립팅된 Triglav의 테스트 스택에서 가져온 것입니다.

팀 구성원 (The team)

코드를 작성하기 전에, 제가 원하는 경험을 글로 적었습니다. 목표를 설정하고, Staff 엔지니어 에이전트가 대부분의 배포 결정을 처리하며, 저는 필요할 때만 개입하는 방식입니다. 따라서 Triglav는 작은 소프트웨어 컨설팅 회사처럼 작동합니다:

• Staff: 장시간 실행되는 Claude Code 또는 Codex 세션입니다. 티켓을 읽고, 작업을 계획하며, 승인 기준(acceptance criteria)을 작성하고 Senior들을 시작시킵니다.
• Seniors: Staff의 하위 에이전트들입니다. 각각 하나의 과제를 맡아 자체 git worktree에서 작업하고 PR(Pull Request)을 엽니다.
• Researchers: 잡보드(job board)를 읽고 조언하는 짧은 실행 과정입니다. 이들은 어떤 코드도 소유하지 않습니다.
• Reviewers: Senior가 제출한 것을 확인합니다.
• 나, 클라이언트 (Me, the Client). 저는 계획을 승인하고, 에스컬레이션(escalations)에 답변하며, 병합(merge)합니다.

이 이름은 세 개의 머리를 가진 슬라브 신인 Triglav에서 따왔습니다. 이 세 개의 머리는 최초의 세 가지 역할, 즉 Staff, Seniors, 그리고 연구원(researchers)을 의미했습니다. 검토자(Reviewers)는 나중에 추가되었습니다.

모든 행동은 Triglav의 MCP 도구를 거치기 때문에 모든 것이 기록되며, 대시보드는 그 기록을 보여주는 화면입니다.

질문과 결정을 위한 공유 작업 게시판

이것이 바로 Triglav의 핵심입니다.

Senior가 무언가 확실하지 않을 때, 단순히 옵션을 선택하는 것으로 끝나지 않습니다. Senior는 작업(job) 게시판에 시간제 질문을 올립니다. 이 질문은 자체적인 맥락을 가지고 있어야 합니다. 즉, 해당 작업, 승인 기준(acceptance criteria), 진행 중인 작업 내용, 그리고 이미 고려된 옵션들입니다. 따라서 해당 작업을 본 적이 없는 연구원이라도 유용한 답변을 할 수 있습니다.

Staff와 연구원들은 입장(stance)으로 답변합니다. 예를 들어 '지지' 또는 '반대'이며, 단순한 댓글 외의 모든 내용은 이유를 제시해야 합니다. Senior는 Staff가 10초 만에 답변하더라도 전체 응답 기간이 끝날 때까지 기다립니다. 아무도 답변하지 않으면 이 기간은 연장됩니다.

이러한 교환 과정에서, Senior는 게스트 주문(guest orders)에 이메일을 저장해야 하는지 아니면 숨겨진 고객을 생성해야 하는지 질문합니다. 연구원과 Staff 모두 기간이 끝나기 전에 입장과 이유를 가지고 답변합니다.

기간이 종료되면, Staff는 구속력 있는 결정(binding decision)을 기록하고 고려했던 모든 답변 목록을 작성합니다. 늦게 들어온 답변도 보존되며 '지연됨(late)'으로 표시됩니다. 만약 지연된 답변이 상황을 바꾼다면, Staff는 이전 결정을 대체하는 새로운 결정을 기록해야 합니다. 마음을 조용히 바꾸는 것은 불가능합니다.

이 게시판은 질문, 주장들, 그리고 최종 결정을 작업과 함께 보존합니다. 저는 나중에 개별 에이전트 대화에서 파편적으로 조합할 필요 없이 추론 과정을 확인할 수 있습니다.

하나의 작업, 시작부터 끝까지

1. 목표 정의. Linear, Jira 또는 GitHub 이슈 링크, 혹은 일반 프롬프트로부터 작업을 시작합니다. 프롬프트 작업은 정제(refining) 단계에서 시작됩니다. Staff는 사용자의 문장을 목표(goal), 범위(scope), 제외할 항목(non-goals), 그리고 수용 기준(acceptance criteria)으로 변환하고, 각 질문에 대해 권장 답변과 함께 열린 질문을 제시합니다. 사용자는 올바를 때까지 답변하고 수정합니다. 계획은 오직 사용자가 승인(Approve)을 클릭할 때만 시작됩니다. Staff는 자신의 제안을 스스로 승인할 수 없습니다.

2. 위임 및 자문. Staff는 작업을 분할하고, 각 Senior에게 간략한 브리프를 작성하여 최대 2명까지 (작업당), 총 10명까지 투입합니다. Senior들은 임대(lease) 방식으로 할당된 업무를 보유합니다. 만약 한 명이 갱신을 중단하면, Staff는 새로운 시도를 시작하고 이전 것은 격리(fenced off)됩니다. 질문은 보드(board)로 전달됩니다.

3. 검토 및 수정. 배포 전에 모든 변경 사항은 계층적 검토(layered review)(다음 섹션 참조)를 거칩니다.

4. 검증 및 에스컬레이션. 작업이 완료된 것으로 간주되려면, Staff가 Senior가 보고한 것과 동일한 커밋에서 CI 자체를 확인해야 합니다. 팀이 결정할 수 없는 모든 것은 저에게 의사결정(decision)으로 전달됩니다.

배포 전 계층적 검토 (Layered review before delivery)

레이어 1: 로컬 검토 패널. Senior는 자신의 커밋 범위에 대한 검토를 요청합니다. 읽기 전용(read-only) 리뷰어들로 구성된 패널이 diff와 리포지토리를 읽습니다. 기본 배포 설정은 강력한 자리(strong seat)로는 Codex의 GPT-6.1-Sol을, 저렴한 2차 의견으로는 Claude Code의 Sonnet 5.5를 사용합니다. 따라서 한 모델 계열이 다른 모델의 작업을 검사합니다. 이 패널은 클라이언트 설정입니다.

서버가 게이트를 강제합니다:

• submit_review_package 및 Copilot 리뷰 요청은 해당 커밋에 대한 완료된 검토가 정확히 'ok' 판정을 받지 못하면 거부됩니다.
• 하나의 작업(work)은 최대 3번의 로컬 라운드를 거치며, 각 후속 라운드는 수정 사항만 검토합니다.
• 작업이 검토되는 범위는 merge base에서 시작하는 체인(chain)을 형성하므로, 두 검토 사이에는 커밋이 건너뛰어지지 않습니다.
• 충돌하거나 읽을 수 없는 내용을 반환하는 리뷰어는 라운드를 실패시키며, 실패한 라운드는 결코 통과로 계산되지 않습니다.

현재 패널은 총 96라운드를 완료했습니다: 54회 통과, 42회 변경 요청. 이는 게이트(gate)가 사용되고 있음을 보여줍니다. 하지만 이것이 리뷰어의 정확도를 측정하는 것은 아닙니다. 이를 파악하기 위해 리포지토리는 평가 하네스(evaluation harness)를 가지고 있으며, 이 하네스는 Triglav 자체 PR에 대해 패널을 재실행하고 그 결과를 Copilot의 결과와 비교합니다. Copilot은 여기서 벤치마크 역할을 하며, 일치한다는 것이 발견이 옳다는 것을 증명하지는 않습니다.

Layer 2: Copilot. PR당 최대 3번의 Copilot 리뷰 라운드가 있습니다. 이 레이어가 실행될지 여부는 클라이언트(Client)의 설정에 달려 있습니다: _auto는 리포지토리에 Copilot이 있는 경우 사용하고, _Copilot required_는 깨끗한 검토 없이는 배포를 거부하며, _CI only_는 이를 건너뜁니다. 서버 자체적으로 gh를 실행할 수 없기 때문에, 시니어(Senior)가 각 라운드에 대해 보고하는 내용에 의존합니다.

Layer 3: 보고된 커밋에 대한 CI 검사이며, 작업이 완료되었다고 표시하기 전에 스태프(Staff)가 확인합니다.

인간에게 에스컬레이션 (Escalation to the human)

대부분의 질문은 저에게 오지 않습니다. 스태프는 일반적인 엔지니어링 질문을 스스로 해결합니다. 정말로 제가 필요할 때, 문제는 무엇인지, 질문은 무엇인지, 그 권장 사항(recommendation), 제가 실행해야 하는 모든 명령어(각 명령어 옆에 복사 버튼 포함)와 연구원들의 조언과 함께 결정을 제기합니다.

제가 동의하면, 클릭 한 번으로 끝납니다: 권장 사항 수락(Accept recommendation). 열려 있는 결정(open decisions) 개수는 브라우저 탭에 표시되므로, 제가 다른 작업을 할 수 있어도 팀이 저를 기다리고 있는지 알 수 있습니다.

또한 '왜 이 작업이 멈췄을까요?'라는 질문에 답하는 Claude Code 채팅용 Operator 페이지도 있습니다. 읽기는 할 수 있지만, 아무것도 변경할 수는 없습니다. 행동해야 할 때가 오면, 제 확인(Confirm)을 기다리는 카드를 채팅창에 넣습니다.

저를 힘들게 했던 점들

수 분이 아닌 며칠 동안 이러한 워크플로우를 실행하는 것은 단일 에이전트 세션에서는 발생하지 않는 문제들을 가져옵니다.

사용량 제한 및 중복 세션. 한 Staff가 사용량 제한에 도달했습니다. 제한이 초기화되었을 때, Claude Code는 새로운 세션 ID로 스스로 세션을 계속 진행했습니다. 저도 이어서 작업했고, 두 개의 Staff 에이전트가 같은 작업을 관리하게 되었습니다. 이제 러너(runner)는 재개하기 전에 대화의 실행 중인 사본이 있는지 확인합니다.

깨어나는 비용이 작성하는 비용보다 비싸다. 처음 6일 동안 모든 에이전트는 총 약 360만 개의 출력 토큰을 작성했고, 프롬프트 캐시에서 약 36억 개를 읽었습니다. 이는 대략 천 대 일의 비율입니다. 기다리던 에이전트가 깨어날 때마다 전체 컨텍스트를 다시 읽게 되는데, Staff는 종종 30만~70만 토큰에 달합니다. 그래서 Staff는 이제 필요한 이벤트가 있을 때만 깨어나고, 한 시간 분량의 프롬프트 캐시에서 호출당 최대 50분 동안 대기합니다. 연구자들은 전혀 기다리지 않습니다. 읽거나 답변할 것이 생길 때 시작해서 종료합니다.

컨텍스트 크기. Staff는 컨텍스트를 약 28만 토큰으로 압축합니다. Opus의 Claude Code 기본값은 약 98만 토큰이었기 때문에, 장기간 실행되는 Staff는 절대 압축하지 않고 계속해서 커지는 컨텍스트를 다시 읽었습니다.

권한 및 제한

병합(Merging), 배포(Deploying), 강제 푸시(Force pushing) 및 저장소 설정은 클라이언트(Client)가 담당합니다. 에이전트들에게는 이러한 작업을 절대 하지 말라고 지시하지만, 이는 단지 지침일 뿐이므로 GitHub에서도 브랜치를 보호해야 합니다.

서버는 Docker에서 실행되며 호스트에서 프로세스를 시작할 수 없습니다. 작은 호스트 러너(host runner)가 이 역할을 수행하며, 서버로부터 명령 문자열을 절대 실행하지 않습니다. 모든 명령어는 자체적으로 구축하고 모든 필드를 먼저 확인합니다. 검토자(Reviewers), 연구원(Researchers), 그리고 Operator는 읽기만 할 수 있습니다.

에이전트는 사용자의 OS 사용자 권한으로 실행되므로, 악의적인 에이전트가 .env 파일을 읽을 수 있습니다. README 파일에는 이 내용이 명확하게 나와 있으며, 보안 모델이 다루지 못하는 다른 사항들과 함께 언급되어 있습니다.

시도해 보기

Docker, Node 24, pnpm 및 Claude Code 또는 Codex가 필요합니다. 저는 리눅스에서만 실행해 보았습니다.

git clone https://github.com/adam-drag/triglav.git
cd triglav
pnpm install --frozen-lockfile
...