VELIUM PRODUCT GUIDE / 처음부터 운영까지

Velium
사용 가이드

Agent 연결부터 첫 프로젝트 생성, 작업 실행, 변경 검토와 승인 이력까지. 필요한 기능을 실제 사용 순서대로 안내합니다.

01시작하기

Agent 연결과 프로젝트 생성

02일하기

Graph와 Agent Run 확인

03결정하기

변경 검토와 승인

04해결하기

이력, 위험과 문제 해결

이 페이지에서 찾기
01 / UNDERSTAND

3분 안에 이해하기

Velium은 Agent가 일하는 속도와 사람이 결정하는 안전함을 하나의 작업 흐름으로 연결합니다.

WORKFLOW ALGORITHM한눈에 보는 작업 흐름

결과를 확인한 뒤 사람의 결정에 따라 기록하거나 다시 실행합니다.

  1. 01INPUT
    목표 입력

    만들고 싶은 결과를 한 문장으로 적습니다.

  2. 02PROCESS
    작업 분해

    Velium이 실행 가능한 할 일로 나눕니다.

  3. 03RUNTIME
    Agent 실행

    Agent가 작업하고 결과와 근거를 남깁니다.

  4. 04REVIEW
    결과 검토

    무엇을 했고 무엇이 바뀌는지 확인합니다.

  5. 05DECISION
    승인할까요?

    결정은 사람이 합니다.

  6. NO
    07LOOP
    수정 요청

    보완한 뒤 Agent 실행으로 돌아갑니다.

  7. YES
    06STATE
    프로젝트에 기록

    승인한 결과만 다음 작업의 기준이 됩니다.

Agent가 실행 사람이 결정 승인된 결과만 기록
AGENT작업하고 제안합니다

승인된 task를 실행하고 결과, 검사와 변경안을 남깁니다.

YOU보고 결정합니다

바뀔 내용과 근거를 확인한 뒤 승인하거나 거절합니다.

VELIUM승인한 것만 기록합니다

확정한 결과를 다음 작업이 이어받을 프로젝트 상태로 남깁니다.

02 / QUICK START

5분 빠른 시작

처음 연결하는 순간부터 첫 변경을 승인하는 순간까지 순서대로 따라가세요.

AGENT REQUEST복사해서 요청할 수 있는 첫 문장
현재 폴더를 조사해서 Velium 프로젝트로 정리해 줘.
  1. 01
    당신

    Agent를 연결합니다

    Velium이 Agent의 작업 결과를 받을 수 있도록 한 번 연결합니다.

    1. Project Workspace 상단에서 Agent Access를 엽니다.
    2. 사용할 client와 token 유효시간을 선택합니다.
    3. 한 번만 표시되는 token과 stdio 설치 설정을 각각 복사합니다.
    4. Codex, Claude Code, Cursor 등 MCP-compatible client에 설정을 등록합니다.

    주의Bearer token은 다시 볼 수 없습니다. 저장소, 문서, 스크린샷에 남기지 마세요.

    입력값과 성공 상태 자세히 보기
    Client name
    Codex Velium MCP목록에서 알아볼 수 있는 이름
    Client type
    codexcodex, claude_code, cursor, vscode 등
    유효시간
    24시간1시간, 8시간, 24시간 중 선택
    Role
    Executor조정은 Coordinator, 독립 검토는 Critic
    Workstream
    generalbackend, testing처럼 쉼표로 구분 가능
    동시 step
    1플랜과 정책이 허용한 범위 안에서 선택
    화면에 표시되는 stdio 연결 정보
    transport=stdio
    command=npx
    args=-y velium-mcp-bridge@0.1.0
    VELIUM_MCP_URL=https://<your-host>/api/mcp
    VELIUM_MCP_BEARER_TOKEN=<한 번 표시된 token>
    정상적으로 보이는 상태
    • Token 기록: 활성
    • Agent 상태: 연결 대기 → 대기
    • Runtime 상태: idle

    막혔을 때활성 token 한도에 도달하면 기존 token을 폐기해야 합니다. 연결 대기가 계속되면 URL, token env와 client 재시작 여부를 확인하세요.

    완료 기준Agent Access에 연결한 client가 활성 상태로 표시됩니다.

  2. 02
    Agent

    현재 폴더를 프로젝트로 정리해 달라고 요청합니다

    프로젝트 생성은 브라우저 폼이 아니라 연결한 Agent에게 요청합니다.

    1. 프로젝트로 만들 로컬 폴더에서 Agent를 실행합니다.
    2. “현재 폴더를 조사해서 Velium 프로젝트로 정리해 줘”라고 요청합니다.
    3. Agent가 Git 상태, 주요 문서, package와 config 파일을 조사합니다.
    4. Agent가 첫 목표, 작업 구조와 생성 근거를 Velium에 남깁니다.
    입력값과 성공 상태 자세히 보기
    실행 위치
    프로젝트 root 폴더Git과 package/config를 함께 읽을 수 있는 위치
    요청 문장
    현재 폴더를 조사해서 Velium 프로젝트로 정리해 줘.name, goal, context는 생략 가능
    사용 tool
    velium.create_project브라우저가 아니라 연결된 Agent가 호출
    같은 token
    자동 project binding생성 후 token을 교체하지 않음
    정상적으로 보이는 상태
    • 최소 1개의 Goal
    • Goal 아래 최소 2개의 node
    • 첫 Graph Revision
    • Reasoning Trace
    • localWorkspace creation evidence

    막혔을 때새 프로젝트가 보이지 않으면 Agent 결과의 projectId, revisionId, traceId와 toolEvidence를 확인하고 같은 token으로 생성했는지 점검하세요.

    완료 기준프로젝트 선택기에 새 프로젝트가 보이고 첫 Project Graph가 열립니다.

  3. 03
    당신

    첫 Project Graph를 확인합니다

    목표와 작업, 결정과 위험이 어떤 관계로 정리됐는지 확인합니다.

    1. Goal과 Milestone을 먼저 읽어 프로젝트 방향을 확인합니다.
    2. Backlog부터 Done까지 task가 놓인 진행 상태를 확인합니다.
    3. 강조된 focus task를 선택하고 오른쪽 inspector를 읽습니다.
    4. Risk, blocker, decision이 현재 작업과 어떻게 연결됐는지 확인합니다.
    입력값과 성공 상태 자세히 보기
    진행 lane
    Backlog · Ready · Active · Blocked · Review · Donetask만 진행 lane에 배치
    배경 맥락
    Goal · Milestone · Decision · Risk · Blockertask가 아닌 node는 backboard context
    Task 번호
    2-3Milestone 2의 세 번째 task
    Focus
    한 번에 1개가장 중요한 단일 task만 강하게 강조
    정상적으로 보이는 상태
    • 선택 node와 inspector 내용이 일치
    • connector가 선행·의존 관계를 표시
    • Risk와 blocker가 관련 task 기준으로 강조

    막혔을 때node 선택은 화면에서만 바뀌며 편집이 아닙니다. 내용이나 상태를 바꾸려면 Agent에게 GraphPatch 제안을 요청하세요.

    완료 기준지금 해야 할 일과 막힌 이유를 한 문장으로 설명할 수 있습니다.

  4. 04
    Agent

    Agent에게 승인된 작업을 맡깁니다

    Agent는 작업을 실행하고 결과, 파일 변경과 검사를 별도 기록으로 남깁니다.

    1. 더 작게 나누려면 Expand, 빠진 위험은 Critique, 다음 행동은 Plan Next를 요청합니다.
    2. Agent Runs에서 실행 중, 대기, 완료 상태를 확인합니다.
    3. 변경된 파일과 test/check evidence를 확인합니다.
    4. 실행 기록과 승인된 Project Graph가 분리되어 있는지 확인합니다.
    입력값과 성공 상태 자세히 보기
    Expand
    작업 분해큰 node를 더 작은 하위 node로 제안
    Critique
    빈틈 검토질문, 리스크, 모순, blocker 제안
    Plan Next
    다음 행동현재 상태에서 다음 task 후보 제안
    Run 상태
    assigned · running · waiting_gate완료 외에도 대기 원인을 확인
    기본 step
    plan · execute · test · verify승인된 task에 idempotent하게 생성
    정상적으로 보이는 상태
    • Agent identity와 맡은 task가 표시
    • changed files 기록
    • test/check 결과
    • 완료 또는 waiting_gate 이유
    • 관련 evidence

    막혔을 때Run이 waiting_gate면 자동 재시작을 기다리지 말고 Gate 내용을 확인하세요. 검사 근거가 없으면 승인 전에 test 또는 verify를 다시 요청하세요.

    완료 기준Agent가 무엇을 했고 어떤 근거를 남겼는지 확인할 수 있습니다.

  5. 05
    당신

    변경안을 검토하고 직접 결정합니다

    Agent의 제안은 적용되지 않은 상태로 멈추며, 최종 결정은 사람이 합니다.

    1. Patch Review에서 대기 중인 변경안을 선택합니다.
    2. 변경 목적, 이유, operation과 validation 결과를 순서대로 읽습니다.
    3. 근거가 충분하면 승인하고, 부족하면 거절한 뒤 수정 요청을 남깁니다.
    4. Timeline에서 결정과 새 Revision이 기록됐는지 확인합니다.
    입력값과 성공 상태 자세히 보기
    Operations
    변경 operation 수add_node, update_node, add_edge 등
    Validation
    검증 통과 · 주의 필요 · 검증 실패stale이면 재제안 필요
    Before / After
    적용 전후 요약node와 edge 변화 규모 확인
    Evidence
    최대 9개 항목Diff, files, tests, acceptance, risk 등
    결정 버튼
    거절하고 graph 유지 / 승인 후 graph에 적용승인 차단 상태에서는 적용 불가
    정상적으로 보이는 상태
    • 대기 수가 1 감소
    • 승인 또는 거절 수가 증가
    • 승인 시 새 Revision
    • Timeline에 사용자 결정 기록

    막혔을 때‘재제안 필요’ 또는 ‘검증 실패’는 승인할 수 없습니다. 최신 Project Graph를 기준으로 Agent가 새 GraphPatch를 제안해야 합니다.

    완료 기준승인한 변경만 Project Graph에 적용되고 Revision으로 남습니다.

03 / DAILY LOOP

매일은 이 순서로 사용합니다

프로젝트를 열고, 일을 맡기고, 결과를 확인하고, 결정한 뒤 다음 작업으로 이어갑니다.

  1. 01
    시작오늘의 focus task 확인

    Overview / Board

    현재 작업과 blocker를 이해함
  2. 02
    위임Agent에게 승인된 task 실행 요청

    Agent Runs

    실행 주체와 상태가 표시됨
  3. 03
    관찰결과, 검사, 파일 변경 확인

    Agent Runs / Evidence

    결과를 판단할 근거가 충분함
  4. 04
    결정변경안 승인 또는 거절

    Patch Review

    사용자 결정이 기록됨
  5. 05
    이어가기적용 결과와 다음 작업 확인

    Timeline / Project Graph

    새 Revision과 다음 focus를 확인함
04 / SCREEN REFERENCE

화면별 기능 안내

어떤 화면을 언제 열어야 하는지, 무엇을 확인하고 다음에는 무엇을 해야 하는지 정리했습니다.

COMMON UI

먼저 공통 화면을 익히세요

01Project switcher

작업할 프로젝트를 바꾸고 node와 Artifact 수를 확인합니다.

02Top bar

현재 view, Patch Review, Agent Access, Project와 Source 상세를 엽니다.

03Left navigation

Execution, Knowledge, Connections, Control 화면을 전환합니다.

04Main workspace

선택한 view의 graph, board, 목록과 검토 내용을 표시합니다.

05Inspector

선택한 task의 목표, 연결 관계, 위험과 변경 상태를 자세히 봅니다.

06Status strip

Agent Run, MCP event, GraphPatch와 문제 수를 빠르게 확인합니다.

WORK FROM HERE

실행 화면

오늘의 작업을 선택하고 Agent의 실행과 변경을 검토하는 핵심 화면입니다.

01Overview프로젝트를 열고 현재 상황을 빠르게 파악할 때
무엇을 보나요?
  • focus task
  • 진행 요약
  • 검토 대기와 blocker
다음 행동

가장 중요한 task 또는 검토 대기를 엽니다.

02Boardtask를 진행 상태별로 확인할 때
무엇을 보나요?
  • Backlog · Ready · Active
  • Blocked · Review · Done
  • milestone별 task 번호
다음 행동

현재 focus task와 다음 Ready task를 비교합니다.

03Project Graph목표, 작업, 결정과 위험의 관계를 볼 때
무엇을 보나요?
  • task connector
  • 선택 node inspector
  • goal · milestone · risk 맥락
다음 행동

node를 선택해 관련 근거와 다음 행동을 확인합니다.

주의브라우저에서 node를 직접 편집하지 않습니다. 변경은 GraphPatch로 제안됩니다.

04Patch ReviewAgent의 변경안을 적용 전에 검토할 때
무엇을 보나요?
  • 변경 목적과 rationale
  • operation 목록
  • validation과 evidence
다음 행동

승인하거나 거절하고 결정 이유를 남깁니다.

주의승인 전에는 Project Graph가 바뀌지 않습니다.

05Timeline어떤 결정이 언제 일어났는지 확인할 때
무엇을 보나요?
  • Graph Revision
  • Patch 승인·거절
  • Gate와 Agent activity
다음 행동

원인이 된 변경안 또는 관련 task로 이동합니다.

06Agent RunsAgent가 실제로 수행한 일을 확인할 때
무엇을 보나요?
  • 실행 주체와 상태
  • step 진행
  • changed files · checks · evidence
다음 행동

실패나 Gate 대기 항목을 먼저 처리합니다.

주의Agent Run 완료와 Project Graph 변경 완료는 다른 상태입니다.

KEEP THE CONTEXT

지식 화면

프로젝트를 다시 설명하지 않도록 문서, 결정, 구조와 검증 근거를 모읍니다.

01ArtifactsPRD, 설계 문서와 작업 브리프를 찾을 때
무엇을 보나요?
  • 활성 version
  • 연결된 node
  • 검토와 활성화 결정
다음 행동

현재 작업에 필요한 artifact를 열거나 새 version을 검토합니다.

02Architecture프로젝트 구조와 주요 기술 경계를 파악할 때
무엇을 보나요?
  • 시스템 영역
  • 의존 관계
  • 관련 결정과 artifact
다음 행동

변경하려는 영역의 결정과 위험을 함께 확인합니다.

03Decisions왜 이런 방향을 선택했는지 찾을 때
무엇을 보나요?
  • 결정 내용
  • 이유와 대안
  • 영향받는 task와 artifact
다음 행동

현재 결정과 충돌하는 변경이 있는지 확인합니다.

04Repository Map코드 저장소의 주요 폴더와 역할을 이해할 때
무엇을 보나요?
  • package와 app 경계
  • 주요 config
  • 작업 관련 경로
다음 행동

Agent에게 필요한 경로 범위를 명확하게 전달합니다.

05Drift문서, 코드와 승인 상태가 어긋났는지 확인할 때
무엇을 보나요?
  • 차이가 발생한 대상
  • 심각도
  • 검토 상태와 evidence
다음 행동

차이를 검토하고 필요한 GraphPatch 또는 artifact 갱신을 요청합니다.

06Evidence결과가 실제로 검증됐는지 확인할 때
무엇을 보나요?
  • test와 check 결과
  • 파일 변경 근거
  • 생성 주체와 시각
다음 행동

부족한 검증을 Agent에게 다시 요청합니다.

07Risks리스크, blocker와 열린 질문을 관리할 때
무엇을 보나요?
  • 심각도와 상태
  • 영향받는 task
  • 대응 행동과 owner
다음 행동

막힌 작업보다 먼저 해소해야 할 위험을 선택합니다.

CONNECT SAFELY

연결 화면

Agent와 GitHub를 연결하되 credential과 외부 실행 권한은 분리합니다.

01GitHub RepositoryGitHub App을 설치하고 repository를 project에 연결할 때
무엇을 보나요?
  • installation 상태
  • 연결 repository
  • Issues permission과 생성 결과
다음 행동

Agent의 Issue 초안을 외부 작업 Gate에서 검토합니다.

주의GitHub Issue 상태가 Project Graph를 자동 변경하지 않습니다.

02Agent AccessAgent token을 발급하거나 연결을 관리할 때
무엇을 보나요?
  • client와 만료 시각
  • Coordinator · Executor · Critic role
  • workstream · 실행 상태 · Gate 대기
다음 행동

필요 없는 token을 폐기하고 role과 작업 범위를 확인합니다.

주의token 원문과 stdio 설정은 발급 시 한 번만 표시됩니다.

SET THE RULES

제어 화면

프로젝트 실행 규칙과 개인·workspace·project 설정의 적용 범위를 관리합니다.

01Project PolicyAgent의 변경 범위와 검토 규칙을 확인할 때
무엇을 보나요?
  • 허용·보호 경로
  • 동시 실행과 timeout
  • 독립 검토와 Gate 요구
다음 행동

정책 변경 preview와 validation을 확인한 뒤 저장합니다.

주의보호 경로와 production Gate 같은 필수 안전 정책은 끌 수 없습니다.

02Settings개인, workspace, project 기본값을 바꿀 때
무엇을 보나요?
  • 현재 값
  • 상속 출처
  • plan에 따른 사용 가능 범위
다음 행동

변경 범위와 저장되지 않은 값을 확인합니다.

FIELD REFERENCE

핵심 화면의 필드와 상태

화면에서 실제로 보이는 이름과 판단 기준을 그대로 정리했습니다.

01Agent Access 발급 필드
필드의미예시
Client name

연결 목록에서 구분할 이름

Codex Velium MCP
Client type

사용하는 MCP-compatible client

codex, claude_code, cursor, vscode 등
유효시간

token이 자동 만료되는 시간

1시간 · 8시간 · 24시간
Role

Agent의 책임 범위

Coordinator · Executor · Critic
상위 Coordinator

하위 Agent가 보고할 Coordinator

Root 또는 활성 Coordinator
Workstream

Agent가 맡을 작업 영역

general 또는 backend, testing
동시 step

한 Agent가 동시에 소유할 step 수

기본 1
Fallback

Executor가 없을 때 Coordinator 동작

disabled 또는 when_no_executor

Role 경계: Coordinator는 계획과 배정을 조정하고, Executor는 구현·테스트를 실행하며, Critic은 다른 client가 만든 evidence를 독립 검토합니다. 어느 role도 사용자 승인을 대신할 수 없습니다.

02Patch Review 승인 판단
Validation승인해야 할 일
검증 통과승인 가능

operation과 evidence를 확인한 뒤 결정합니다.

주의 필요승인 가능

warning의 영향과 Before/After를 추가로 확인합니다.

재제안 필요승인 불가

기준 Revision이 달라졌으므로 최신 Graph 기준으로 다시 제안합니다.

검증 실패승인 불가

삭제된 node, 잘못된 edge 등 error를 수정해 새 Patch를 제안합니다.

읽는 순서: PATCH ID와 목적 → Operations → Validation → Before/After → Evidence 9개 항목 → Reasoning Trace → 승인 또는 거절.

03Project Graph lane 상태
Lane의미
Backlog

아직 시작 순서가 정해지지 않은 task

Ready

선행 조건이 충족되어 시작 가능한 task

Active

현재 Agent 또는 사용자가 진행 중인 task

Blocked

원래 stage를 유지한 채 blocker가 겹쳐진 상태

Review

실행 결과와 evidence를 검토하는 task

Done

완료 근거와 필요한 승인이 갖춰진 task

번호 읽기: `2-3`은 두 번째 Milestone의 세 번째 task입니다. Milestone마다 기본 task slot은 최대 5개입니다.

04Project Settings 9개 영역
영역설정하는 값
General

timezone, active/paused/archived 상태

GitHub Repository

target branch, allowed/protected paths, max changed files, worktree

Orchestration

write/read 동시성, timeout, lease TTL, retries

Agent Roles

Executor와 다른 client의 독립 Reviewer 요구

Workflow

고정 stage와 low-risk 자동 완료 정책

Review & Gate

보호 경로, production, custom Gate 정책

Artifacts & Context

Markdown 경로, drift 수준, release readiness

Notifications

Gate 요청과 AgentRun 실패 알림

Advanced

beta opt-in과 raw log 보존 기간

저장 순서: 값을 수정하고 Policy Preview를 실행합니다. warning과 issue를 확인한 뒤 valid일 때 Save Changes를 누릅니다. 비어 있는 값은 Workspace 또는 System 기본값을 상속합니다.

05 / APPROVAL & SAFETY

무엇을 누가 결정하나요?

실행, 프로젝트 변경, 외부 작업은 서로 다른 상태와 승인 경계를 가집니다.

실행 기록

Agent Run

Agent가 작업하고 파일 변경과 검사를 남깁니다.

Agent
실행과 evidence 기록
당신
결과 확인
Graph
변경 없음
프로젝트 변경

GraphPatch

Project Graph에 적용될 구조화된 변경안입니다.

Agent
변경안 제안
당신
승인 또는 거절
Graph
승인 시 Revision
외부 작업

External Gate

GitHub Issue처럼 외부에 영향을 주는 실행안입니다.

Agent
실행안 제안
당신
외부 실행 승인
Server
승인 후 한 번 실행
06 / GITHUB

GitHub Issue도 확인 후 생성합니다

Agent는 Issue 초안을 만들고, 실제 GitHub 작업은 사용자가 승인한 뒤 서버가 실행합니다.

  1. 01
    GitHub App 연결

    GitHub Repository 화면에서 연결을 시작합니다.

  2. 02
    접근 범위 선택

    account 또는 organization과 허용할 repository를 선택합니다.

  3. 03
    Project에 매핑

    선택한 repository를 현재 Velium project와 연결합니다.

  4. 04
    Agent가 초안 제안

    Agent는 title, body, label이 포함된 Issue 생성안을 남깁니다.

  5. 05
    당신이 승인

    외부 작업 Gate에서 실제로 생성할 내용을 확인합니다.

  6. 06
    서버가 한 번 실행

    승인 후 서버가 Issue를 만들고 링크와 evidence를 기록합니다.

화면 상태확인할 내용
설치 n

Velium 계정에 연결된 GitHub App installation 수입니다.

issues write

해당 repository에서 Issue를 만들 수 있는 권한입니다. none이면 GitHub App 권한을 다시 확인합니다.

mapped / unmapped

현재 Velium project와 repository가 연결됐는지 나타냅니다.

연결 / 해제

repository mapping만 변경합니다. GitHub App installation 자체를 삭제하지는 않습니다.

Issue Gate payload

repository, title, body, labels, assignees를 확인한 뒤 승인합니다.

01Agent는 GitHub credential을 받거나 GitHub API를 직접 호출하지 않습니다.

02Issue가 닫혀도 Velium task가 자동으로 Done이 되지 않습니다.

03Graph 변경이 필요하면 별도 GraphPatch를 다시 검토합니다.

07 / PLAN & BILLING

플랜과 사용 권한을 확인합니다

가격표의 플랜 이름과 실제로 사용할 수 있는 서버 권한은 구분됩니다.

PLAN선택한 상품

가격, 기본 한도와 제공 기능을 설명합니다.

SUBSCRIPTION구독 상태

결제 기간, 갱신, 해지 예약과 재개 상태를 보여줍니다.

ENTITLEMENT실제 서버 권한

검증된 구독 상태에서 계산한 현재 사용 가능 범위입니다.

USAGE사용량

프로젝트, Graph 규모, token과 실행 한도를 확인합니다.

상태의미고객 행동
active

현재 기간 동안 정상 사용

사용량과 다음 결제일을 확인합니다.

trialing

체험 기간 사용

trial 종료일과 전환 가능한 plan을 확인합니다.

past_due

결제 확인 또는 복구 필요

결제 수단과 서버 재검증 결과를 확인합니다.

cancelAtPeriodEnd=true

현재 기간 종료일에 해지 예정

필요하면 종료일 전 ‘구독 재개’를 누릅니다.

restricted

일부 서버 권한 제한

Billing 오류와 entitlement 원인을 먼저 해결합니다.

08 / TROUBLESHOOTING

문제가 생기면 여기부터 확인하세요

증상을 기준으로 확인할 화면과 다음 행동을 빠르게 찾을 수 있습니다.

01Agent가 연결되지 않음

먼저 확인token 만료, client의 stdio 설정, Agent Access 상태

다음 행동새 token을 발급하거나 기존 연결을 폐기한 뒤 다시 등록합니다.

02새 프로젝트가 보이지 않음

먼저 확인Agent의 생성 결과와 현재 project binding

다음 행동같은 token으로 생성했는지 확인하고 프로젝트 선택기를 새로 확인합니다.

03Patch Review가 비어 있음

먼저 확인Agent Run 결과와 proposal 상태

다음 행동Agent에게 결과 요약이 아니라 변경안 제안을 명시적으로 요청합니다.

04승인 버튼이 차단됨

먼저 확인validation warning/error와 필요한 Gate

다음 행동누락된 evidence를 보완한 뒤 새 proposal 또는 validation을 요청합니다.

05승인했지만 변경이 안 보임

먼저 확인Timeline의 결정과 Graph Revision

다음 행동Revision 생성 여부와 적용 실패 evidence를 확인합니다.

06GitHub Issue가 생성되지 않음

먼저 확인repository mapping, Issues permission, 외부 Gate 상태

다음 행동연결 상태와 실패 evidence를 확인한 뒤 다시 승인합니다.

07문서와 코드가 서로 다름

먼저 확인Drift, Artifacts, Repository Map

다음 행동차이를 검토하고 문서 또는 Project Graph 갱신안을 요청합니다.

09 / GLOSSARY

제품 용어를 쉽게 찾으세요

기술 정의보다 화면에서 어떤 의미로 사용되는지를 먼저 설명합니다.

AgentAgent Access

Velium 도구를 통해 프로젝트를 읽고 작업과 변경안을 제안하는 외부 AI client

Agent RunAgent Runs

Agent가 맡은 작업을 실행한 과정과 결과 기록

ArtifactArtifacts

PRD, 설계, 브리프처럼 프로젝트 node와 연결되는 문서 산출물

DriftDrift

문서, 코드와 승인된 프로젝트 상태 사이에 생긴 차이

EntitlementBilling / Settings

실제 구독 상태에 따라 서버가 계산한 사용 권한과 한도

EvidenceEvidence / Agent Runs

파일 변경, test, check처럼 실행 결과를 확인할 수 있는 근거

External Action GatePatch Review / GitHub

GitHub Issue처럼 외부에 영향을 주는 작업을 사용자가 최종 결정하는 단계

Focus taskBoard / Project Graph

현재 화면에서 가장 중요하게 강조되는 단일 작업

GraphPatchPatch Review

Agent가 제안하는 구조화된 Project Graph 변경안

Graph RevisionTimeline

승인된 GraphPatch가 적용될 때 만들어지는 변경 이력

MilestoneBoard / Project Graph

여러 task를 묶는 프로젝트의 중간 목표

Project GraphProject Graph

승인된 목표, 작업, 결정과 위험을 관계로 연결한 프로젝트의 기준 상태

Reasoning TracePatch Review / Evidence

Agent 제안의 근거와 판단을 사용자가 검토할 수 있게 요약한 기록

WorkstreamAgent Access

여러 Agent가 겹치지 않게 나눠 맡는 프로젝트 작업 영역

10 / FAQ

자주 묻는 질문

시작하기 전과 운영 중에 가장 자주 생기는 질문을 모았습니다.

01무엇부터 시작해야 하나요?

먼저 Agent Access에서 사용할 AI client를 연결하세요. 그다음 작업 폴더에서 Agent에게 ‘현재 폴더를 조사해서 Velium 프로젝트로 정리해 줘’라고 요청하면 됩니다.

02기존 프로젝트도 가져올 수 있나요?

가능합니다. 별도 import form 대신 기존 폴더에서 Agent가 Git 상태, 문서와 설정을 조사해 첫 Project Graph를 만들도록 요청합니다.

03Agent가 프로젝트를 마음대로 바꿀 수 있나요?

아닙니다. Agent는 변경안을 제안할 수 있지만 Project Graph나 외부 작업을 승인할 수 없습니다. 사용자가 승인한 변경만 반영됩니다.

04여러 Agent를 연결해도 되나요?

가능합니다. 각 Agent는 별도 token과 identity를 사용하며 Coordinator, Executor, Critic role과 workstream을 배정할 수 있습니다. token을 서로 공유하지 마세요.

05변경을 되돌릴 수 있나요?

승인된 변경은 Revision과 diff로 기록됩니다. 현재 MVP에서 자동 되돌리기가 항상 제공되는 것은 아니므로, 이전 Revision을 확인한 뒤 필요한 복구 변경안을 새 GraphPatch로 제안하는 흐름을 사용합니다.

06GitHub 없이도 사용할 수 있나요?

예. Project Graph, Agent Run, Patch Review와 Timeline은 GitHub 연결 없이 사용할 수 있습니다. GitHub는 Issue 생성이 필요할 때만 연결합니다.

07token을 잃어버리면 어떻게 하나요?

token 원문은 다시 표시되지 않습니다. Agent Access에서 기존 연결을 폐기하고 새 token과 stdio 설정을 발급하세요.

08어떤 정보가 프로젝트 이력에 남나요?

승인·거절 결정, 적용된 GraphPatch, Graph Revision, Agent activity와 검증 evidence가 역할에 맞는 별도 기록으로 남습니다.

NEXT STEP / 직접 확인하기

설명보다 먼저
작업 흐름을 체험해 보세요.

계정이나 API 연결 없이 Project Graph, Patch Review와 Timeline을 확인할 수 있습니다.

Demo 체험하기