software

AI 에이전트와 인간을 위한 Jira

발행: (2026년 4월 3일 오후 05:47 GMT+9)
12 분 소요
원문: Dev.to

Source: Dev.to

먼저 말씀드리자면, 걱정하지 마세요. 저는 여기서 Moltbook을 다시 만들지는 않았습니다.

제가 아는 모든 스타트업은 도구가 너무 많습니다—여기 보드 하나, 저기 Notion 문서 하나, 사실상 스펙이 된 Slack 스레드 하나. **Fluado**에서 우리는 기업용 AI 에이전트를 구축하고 있는데, 지난 몇 주 사이에 새로운 층이 생겼습니다: 에이전트가 마크다운을 우리 문서 레포에 작성하고 (스프린트 티켓, 완료 보고서, 수십 개 파일). 파일 시스템이 진실의 원천이 되었고, 프로젝트 보드는 그렇지 않았습니다.

Arbo와 저는 매일—하루에 여러 번—대화합니다. 하지만 그 대화는 가리킬 수 있는 흔적을 남기지 않습니다. Jira가 그 흔적이 되어야 했죠. 오늘 아침에 열어보니, 아직도 4주 전 상태를 보여주고 있었습니다. 아무도 건드리지 않았던 겁니다.

저는 이전에 썼던 글에서 AI는 이미 집안 정리가 잘 되어 있을 때 생산성을 높여주는 도구라고 말했습니다. 알고 보니, 그 정리 안에는 프로젝트 보드도 포함됩니다.

그래서 저는 Arbo에게 제안했습니다: 이미 존재하는 마크다운 파일만 읽는 작은 보드를 만든다면 어떨까? 현실 위에 놓인 창을 말이죠.

그는 회의적이었습니다. 저도 오후까지 버틸 수 있을지 확신이 없었습니다. 하지만 대안은 다시 아침에 Jira 보드를 업데이트하고, 일주일 안에 다시 오래돼 버리는 상황이었습니다.

오후 늦게, Jira는 사라졌습니다. 모든 티켓이 마이그레이션되었습니다. 우리와 에이전트 모두 같은 보드에서 작업하고 있습니다.

Source:

The board

우리 에이전트는 이미 마크다운으로 작업합니다. YAML 프론트‑머터가 포함된 파일을 만들고 보고서를 작성하죠. 그렇다면 인간이 버튼을 클릭하도록 설계된 SaaS 보드에 그걸 다시 넣을 필요가 있을까요?

각 작업은 backlog/ 안의 폴더에 존재합니다. 폴더 이름은 날짜와 카테고리를 인코딩합니다. 그 안에는 여러 마크다운 파일이 모여 있습니다:

backlog/
├── 2026-03-26-CHAT-UX/
│   ├── chat-ux-milestones.md    # 계획
│   ├── chat-ux-tickets.md       # 작업으로 분할
│   ├── CUX0-report.md           # 에이전트 완료 보고서
│   └── CUX1-report.md
├── 2026-03-27-AGENT-I18N/
│   ├── agent-i18n-milestones.md
│   ├── agent-i18n-tickets.md
│   ├── I0-report.md
│   ├── I1-report.md
│   └── i18n-audit-report.md
└── 2026-04-01-OPS-DEPLOY-STAGING/
    └── CARD.md                   # 하위 작업이 없는 간단한 카드
  • Milestones 파일 → 계획.
  • Tickets 파일 → 세분화된 작업.
  • Reports → 에이전트가 마일스톤을 마쳤을 때 생성하는 보고서.
  • CARD.md → 하위 작업이 없는 단순 작업.

각 폴더의 대표 마크다운 파일에는 보드가 읽는 YAML 프론트‑머터가 들어 있습니다:

---
title: "Chat UX Improvements"
type: product
status: wip
assigned: yves
created: 2026-03-26
edited: 2026-04-01
---

작업을 만드는 에이전트는 mkdir 명령으로 폴더를 만들고, 올바른 프론트‑머터를 가진 마크다운 파일을 작성합니다. 스키마가 충분히 단순해서 에이전트는 폴더 안 기존 파일들을 보고 이를 추론합니다. 프론트‑머터가 잘못되면 보드는 해당 파일을 그냥 건너뛰고, 나는 git 로그에서 그걸 확인한 뒤 10초 안에 YAML을 고칩니다.

IDE에서 폴더 트리를 스크롤하면, 보드는 브라우저에 동일한 구조를 그대로 렌더링합니다: 세 개의 컬럼( todo, wip, done ). 카드를 드래그해서 상태를 바꾸거나, 제목을 클릭해 인라인으로 이름을 바꿀 수 있습니다. 모든 카드에는 “Open in Editor” 버튼이 있어 파일을 바로 열어줍니다.

Fluado Board

IDE에서 백로그 파일을 수정하면, 보드 서버가 즉시 이를 감지합니다. 파일 워처가 backlog/ 를 모니터링하고, 5초 동안 디바운스한 뒤 자동으로 git에 커밋합니다. 저장하면 git이 동기화됩니다.

동기화

두 사람과 몇 명의 에이전트가 같은 상태를 바라볼 수 있게 하는 가장 간단한 방법은 무엇일까요? Git.

보드에서 일어나는 모든 동작은 즉시 커밋하고 푸시합니다:

[15:42:06] 📝 committed: move CHAT-UX to done
[15:42:07] ⬆  pushed
[15:43:12] 📝 committed: create OPS-DEPLOY-STAGING as todo
[15:43:13] ⬆  pushed
[15:44:30] 📝 committed: rename AGENT-I18N
[15:44:31] ⬆  pushed

들어오는 변경 사항에 대해서는 서버가 git ls-remote를 5초마다 폴링합니다(SSH 라운드‑트립 하나, SHA 비교 하나). 원격 저장소에 새로운 커밋이 있으면 풀하고 어떤 내용이 들어왔는지 로그에 기록합니다:

[15:45:10] ⬇  synced from remote:
     abc1234 board: move AGENT-I18N to wip
     def5678 board: update 2026-04-01-SURFACE

브라우저는 Server‑Sent Events를 통해 업데이트됩니다. 보드는 조용히 다시 렌더링되므로, 카드 편집 중이거나 폼을 채우는 도중이라도 내용이 사라지지 않습니다. (첫 번째 버전은 location.reload()를 사용했었죠. 😅)

같은 흐름이 역방향으로도 작동합니다. 에이전트가 마일스톤을 마치면 백로그 폴더에 보고서를 커밋하고 푸시합니다. 5초 뒤 보드가 이를 받아들입니다. 새 파일이 카드 상세 뷰에 나타나므로, 에이전트에게 작업이 끝났는지 물어볼 필요가 없습니다.

보드 코드는 동일한 레포에 존재합니다. nodemon으로 실행되기 때문에, 누군가 서버에 수정 사항을 푸시하면 원격 폴링이 이를 끌어오고, nodemon이 재시작하며, 새로운 프론트엔드가 SSE를 통해 전달됩니다. 나는 15:00에 CSS를 바꿨고, 브라우저 탭으로 전환했을 때 이미 새로운 스타일이 적용돼 있었습니다. Arbo도 그것을 보았습니다.

카드란…

(원본 내용이 여기서 끊깁니다; 필요에 따라 계속하십시오)

실제로 바뀐 점

우리는 기존에 하던 방식대로 작업을 계속했습니다. Arbo와 저는 각각 IDE와 보드에서, 에이전트들은 backlog/에 커밋합니다. Git이 모든 것을 연결해 줍니다. 전체 스택은 순수 HTML/CSS/JS이며, 빌드 단계가 없고 npm 의존성도 없습니다.

// Simple server example
const http = require('http');
const yaml = require('js-yaml');
const fs = require('fs');

http.createServer((req, res) => {
  // …handle requests…
}).listen(3000);

fs.watch는 파일 시스템의 변화를 감시하므로 가장 최근에 수정된 카드가 최상단에 떠오릅니다(수정 시간 기준 내림차순 정렬). 나는 수동 드래그 순서를 분수 인덱싱으로 구현해 보았고, 5분 정도 사용한 뒤 버렸습니다—파일 시스템이 이미 내가 작업 중인 것을 알고 있기 때문입니다.

규모에 대한 메모

내 피드에서 “SaaS는 죽었고, AI가 모든 것을 만들 수 있다”는 말을 계속 보고 있다. 이것은 2명의 인간과 몇 명의 에이전트로 구성된 팀에게는 통한다. 10명 팀의 Jira를 대체할 수 있을지—대체해야 할지—나는 전혀 모른다. 이 보드가 6개월 동안 살아남을 수 있을까? 나도 모른다.

내가 아는 것은, 우리는 아침에 그것을 만들고 오후에 사용했다는 것이다. 저녁이 되자 보드에는 세 개 열에 걸쳐 14장의 카드가 있었다. 내가 이 글을 쓰는 동안 Arbo가 하나를 WIP 로 끌어당겼고, 나는 그것이 움직이는 것을 보았다.

우리가 Jira를 교체한 이유는 Jira가 마음에 들지 않아서가 아니다. 우리가 교체한 이유는 실제 보드가 이미 파일 시스템에 존재했기 때문이다. Jira는 아무도 관리하지 않는 복사본이었으므로, 우리는 복사본을 삭제하고 원본에 창을 띄웠다.

이 도구는 우리가 일하는 방식을 중심으로 만들었기 때문에 우리의 작업에 맞는다. 이것은 보편적인 교훈이 아니라, 우리만의 교훈이다.

연락하기

에이전트가 필요한 프로세스가 있나요? 문의하기.

0 조회
#software #programming #community
원문 보기
Share:
Back to Blog

관련 글

더 보기 »