pinto를 사용하면 팀이 Scrum 백로그를 일반 텍스트로 관리할 수 있습니다.

모든 백로그 변경 사항은 소스 코드와 마찬가지로 git diff를 통해 검사할 수 있고, 브랜치를 통해 전달하거나, 머지(merge)하고, 풀 리퀘스트(pull request)에서 검토할 수 있습니다. 백로그는 그것이 설명하는 제품과 동일한 라이프사이클(lifecycle)을 따릅니다.

pinto는 로컬 우선(local-first) 방식입니다. 서버, 계정 또는 호스팅된 데이터베이스가 필요하지 않습니다. AI 에이전트와 함께 작동하지만, 결코 그들에게 의존하지 않습니다. 그리고 일반적인 CLI 할 일 목록(to-do list)과 달리, 핵심 모델은 Scrum입니다: 제품 백로그 항목 (Product Backlog Items, PBIs), 스프린트 (Sprints), 칸반 (Kanban), 그리고 팀이 검사하고 적응하는 데 사용하는 지표(metrics)들입니다.

pinto가 존재하는 이유

Jira, Asana, Notion은 유능한 제품들입니다. 하지만 기능이 더 많이 축적됨에 따라, 프로세스가 도구를 지원하는 대신 도구가 프로세스를 지원하게 되는 상황이 발생할 수 있습니다:

• 티켓 하나를 만드는 것이 필수 필드와 워크플로우(workflow) 설정을 탐색하는 것을 의미합니다.
• 스프린트를 실행하는 것이 권한, 자동화 또는 대시보드를 구성하는 것부터 시작됩니다.
• 도구가 열리는 속도가 느리면 작은 상태 변경조차 비용이 많이 드는 것처럼 느껴집니다.

Scrum은 **신속한 검사 및 적응을 위한 경량 프레임워크(lightweight framework)**를 지향합니다. 보드를 유지 관리하는 것 자체가 하나의 업무가 될 때, 도구는 그 목표를 상실한 것입니다.

_pinto_라는 이름은 일본어 단어 ピント _“초점(focus)”_에서 유래되었습니다. 그것이 바로 설계 의도이기도 합니다: 팀의 주의를 제품 백로그, 스프린트, 그리고 보드를 통해 흐르는 작업에 집중시키는 것입니다.

pinto는 의도적으로 작게 유지됩니다. 빠르게 시작하고, 의존성과 어휘를 제한하며, 내구성이 있는 데이터를 읽을 수 있는 파일로 저장하고, 간트 차트(Gantt charts)나 CRM과 같은 프로젝트 스위트(project-suite) 기능은 제외합니다.

당신의 백로그는 저장소(repository)에 있어야 합니다

pinto init을 실행하면 코드 옆에 .pinto/ 디렉토리가 생성됩니다. 각 PBI는 TOML 프론트매터(frontmatter)가 포함된 마크다운(Markdown) 파일입니다. 다음은 pinto 자체 백로그의 실제 항목입니다:

+++
id = "P-2"
title = "Investigate and fix Windows CI while retaining Windows support"
...

백로그(backlog)가 일반 파일로 구성되어 있기 때문에, 기존의 엔지니어링 워크플로 (engineering workflow)를 그대로 적용할 수 있습니다:

• git diff를 사용하여 변경 사항 검토
• 백로그를 변경하는 코드와 함께 백로그를 브랜치 (branch) 생성
• 풀 리퀘스트 (pull requests)에서 백로그 업데이트에 대해 논의
• git log로 히스토리 (history)를 복구하고 grep과 같은 도구로 데이터 처리

pinto는 또한 커밋 (commits)을 PBI (Product Backlog Items)에 연결할 수 있고 (pinto link add / pinto link scan), 공유된 완료 정의 (Definition of Done, DoD)를 유지하며 (pinto dod), 의존성 (dependencies)을 기록할 수 있습니다 (pinto dep). 이 중 어떤 것도 별도의 서비스를 필요로 하지 않습니다.

"Git-native"라는 것이 Git이 필수라는 의미는 아닙니다. 기본 파일 백엔드 (file backend)는 Git 없이도 작동합니다. 이는 프로젝트가 Git 워크플로 (Git workflow)를 사용할 때마다 데이터 포맷 (data format)이 자연스럽게 그 과정에 참여할 수 있음을 의미합니다.

설치하기

crates.io에서 네이티브 Rust 바이너리를 설치하세요:

cargo install pinto-cli

소스에서 빌드하려면 Rust 1.89 이상이 필요합니다. 관련 명령어는 리포지토리 README에서 확인할 수 있습니다.

90초 만에 Scrum 워크플로 살펴보기

로그인 흐름을 구축하는 팀을 가정해 보겠습니다. 아래 예시들은 실제 pinto 출력 결과물을 사용합니다.

백로그 구성 및 스프린트 (Sprint) 계획

보드를 초기화하고 몇 개의 PBI를 추가합니다:

pinto init
pinto add "Design the login form" --points 3 --label ui --label auth
pinto add "Implement the login API" --points 5 --label api --label auth
...

T-1  todo  Design the login form  (3)  [ui, auth]
T-2  todo  Implement the login API  (5)  [api, auth]
T-3  todo  Write onboarding docs  (2)  [docs]
...

각 라인은 상세 페이지를 열지 않고도 필수적인 컨텍스트 (context)를 가시적으로 유지합니다. 순위 (Rank)는 제품 백로그 (Product Backlog)의 순서를 제어하므로, 우선순위를 변경하는 작업은 pinto reorder T-4 --top만큼이나 직접적입니다.

이제 가장 순위가 높은 세 개의 항목을 2주간의 스프린트 (Sprint)로 가져옵니다:

pinto sprint new S-1 "Sprint 1" --goal "Ship the login flow" \
  --start 2026-07-13 --end 2026-07-27
pinto sprint add S-1 --status todo --limit 3   # 상위 3개의 PBI 추가
...

sprint S-1 Sprint 1 생성됨
T-1을 sprint S-1에 할당함
T-2를 sprint S-1에 할당함
...

작업 이동하기 (Move the work)

move 명령은 Unix의 mv와 마찬가지로 목적지를 마지막에 입력합니다. mv 또한 별칭 (alias)으로 사용할 수 있습니다.

pinto move T-1 in-progress
pinto move T-2 in-progress
pinto move T-1 done
...

todo (3)
  T-3  온보딩 문서 작성
  T-4  세션 타임아웃 버그 수정
...

팀은 .pinto/config.toml에서 WIP (Work In Progress, 진행 중인 작업) 제한을 정의할 수 있습니다. 더욱 인터랙티브한 워크플로를 위해, pinto kanban을 실행하면 터미널 UI (TUI)가 열리며, 여기서 카드를 이동하거나 $EDITOR를 통해 편집하고, 의존성 (dependencies) 및 부모-자식 관계 (parent-child relationships)를 관리할 수 있습니다.

검토 및 적응 (Inspect and adapt)

스프린트 (Sprint) 진행 중에 pinto sprint burndown S-1을 실행하면 터미널에 진행 상황이 직접 렌더링됩니다:

S-1 Sprint 1 - burndown (points)
Period 2026-07-13 → 2026-07-27 · total 10
█ remaining  ┆ ideal
...

동일한 스크럼 (Scrum) 모델을 사용하여 팀이 스프린트에 참여하기 전에 용량 (capacity)을 추정할 수 있습니다:

pinto sprint capacity S-1 --daily-hours 8 --holidays 1 --deduction-factor 0.2

남은 PBI (Product Backlog Item)가 완료되면, 스프린트를 종료하고 속도 (velocity), 사이클 타임 (cycle time), 리드 타임 (lead time)을 검토합니다:

pinto move T-2 T-3 done
pinto sprint close S-1
pinto sprint velocity
...

Closed sprint S-1
Velocity (last 5 sprints)
S-1  10 points  completed: 3  unestimated: 0  incomplete: 0
...

이 보드는 1분도 채 걸리지 않아 생성되었으며, 이것이 타이밍 값이 초 단위로 측정되는 이유입니다. 실제 프로젝트에서는 일자별 분포가 나타나며, 연속된 스프린트에 걸쳐 유용한 속도 추세 (velocity trend)를 구축할 수 있습니다.

핵심은 명령어의 개수가 아닙니다. 백로그 정제 (backlog refinement), 스프린트 실행 (Sprint execution), 그리고 검토 (inspection)가 저장소 (repository)나 터미널을 벗어나지 않고 모두 이루어진다는 점입니다.

AI 활용 여부와 관계없는 안전한 자동화

대부분의 읽기 전용 (read-only) 명령은 --json을 지원합니다. 쓰기 작업의 경우, pinto는 에이전트 주도 변경 (agent-driven changes)을 위해 의도적으로 좁은 경계를 설정한 pinto automate를 제공합니다.

automate는 인자 배열 (argument arrays)로 구성된 구조화된 JSON 계획을 수락합니다. 다음 세 가지 속성은 해당 경계를 검토 가능하게 만듭니다:

• 계획(Plans)은 **셸 코드(shell code)가 아닌 검증된 argv(validated argv)**를 포함합니다. 계획은 셸로 전달되지 않으므로, 셸 인젝션(shell-injection) 경로가 존재하지 않습니다.
• --dry-run은 실제 보드를 수정하지 않고 보드의 **격리된 복사본(isolated copy)**에 대해 계획을 실행합니다.
• --json은 생성 및 업데이트된 아이템 ID와 함께 모든 명령을 valid(유효), succeeded(성공), failed(실패), 또는 skipped(건너뜀)로 보고합니다.

코딩 에이전트(coding agent)에게 다음과 같이 요청한다고 상상해 보세요:

백로그를 읽고 다음 주부터 시작되는 2주간의 스프린트(Sprint)를 위한 pinto 계획을 제안해 줘. 무엇인가를 적용하기 전에 드라이 런(dry run) 결과를 보여줘.

에이전트는 먼저 현재 백로그를 읽습니다:

pinto list --status todo --json

그 다음, 사람이 검토할 수 있는 일반적인 plan.json 파일을 작성합니다:

{
  "commands": [
    ["sprint", "new", "S-2", "Sprint 2",
...

이를 적용하기 전에, 에이전트는 계획을 검증합니다:

pinto automate --plan plan.json --dry-run --json

{
  "status": "dry_run",
  "dry_run": true,
...

사람이 plan.json 또는 드라이 런 결과를 검토하고, 제안이 타당할 때만 --dry-run을 제거합니다. 에이전트의 제안과 보드에 대한 적용은 검토 가능한 아티팩트(artifact)에 의해 분리됩니다. 이 아티팩트는 심지어 풀 리퀘스트(pull request)와 함께 전달될 수도 있습니다.

동일한 메커니즘이 장애 대응(incident triage)에도 작동합니다. 에이전트는 사후 분석(postmortem) 내용을 검토 가능한 후속 PBI(Product Backlog Item) 세트로 변환할 수 있습니다:

{
  "commands": [
    ["add", "Add retry to the session refresh job",
...

add 명령이 --body 및 --template을 지원하기 때문에, 계획은 에디터를 열지 않고도 유용한 PBI를 생성할 수 있습니다. 길거나 여러 줄로 구성된 계획은 파일이나 표준 입력(--plan -)을 통해 전달할 수 있으며, 팀은 동일한 검증 경계(validation boundary)를 유지할 수 있습니다.

스토리지 백엔드 (Storage backends)

일반 파일이 기본값입니다. 프로젝트에 다른 영속성(persistence)이 필요한 경우 두 가지 다른 백엔드를 사용할 수 있습니다:

pinto migrate --to git

**Git 백엔드 (Git backend)**는 하나의 완전한 쓰기 작업(write operation)당 하나의 커밋을 생성합니다. 이는 기존의 작업 트리(working-tree) 변경 사항을 격리하기 위해 임시 인덱스(temporary index)를 사용하므로, 커밋되지 않은 코드가 보드 커밋에 유출되지 않습니다. 에이전트 주도 편집(agent-driven edits)의 경우, 이는 작업 단위별로 정밀한 감사 추적(audit trail)을 생성합니다.

단일 파일 데이터베이스를 선호하는 팀을 위해, Cargo 기능 플래그(feature flag)를 통해 선택 가능한 옵션인 **SQLite 백엔드 (SQLite backend)**도 제공됩니다.

pinto가 Backlog.md와 다른 점

이 내용이 익숙하게 느껴진다면, Backlog.md를 살펴보세요. 이는 터미널 보드, 로컬 웹 UI, 작업 및 프로젝트 지식 전반에 걸친 검색, 그리고 CLI 명령어나 MCP를 통한 에이전트 워크플로(agent workflows)를 갖춘 뛰어난 마크다운 네이티브 (Markdown-native) 프로젝트 관리 도구입니다.

pinto는 해당 접근 방식으로부터 학습했지만, 의도적으로 더 좁은 범위를 선택했습니다:

이는 목적의 차이일 뿐, 우월성을 주장하는 것이 아닙니다. 작업, 사양, 문서, 결정 사항 및 에이전트를 위한 광범위한 워크스페이스를 원한다면 _Backlog.md_를 선택하세요. 가장 실용적인 최소한의 도구로 스크럼(Scrum)을 운영하는 것이 목적이라면 pinto를 선택하세요.

마치며

pinto는 백로그를 작업과 가깝게 유지하기 위해 존재합니다: 로컬에 위치하며, 읽을 수 있고, 검토 가능하며, 코드와 동일한 엔지니어링 습관에 의해 관리됩니다.

명확성, 단순함, 그리고 인간미.
AI가 있든 없든.

이것이 당신이 스크럼을 실천하는 방식이라면, pinto를 사용해 보세요. 이슈(Issues)와 풀 리퀘스트(pull requests)는 언제나 환영합니다.