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

Source: Dev.to

First things first: 걱정 마세요, 여기서 저는 Moltbook을 다시 발명한 게 아니에요.

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

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

저는 이전에 썼듯이 AI는 이미 집안 정리가 잘 되어 있을 때 생산성을 높여준다고 했었습니다. 알고 보니 그 ‘집안 정리’에는 프로젝트 보드도 포함돼 있더군요.

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

그는 회의적이었습니다. 저도 오후까지 버틸 수 있을지 확신이 없었죠. 하지만 대안은 다시 아침부터 Jira 보드를 업데이트하는 것이었고, 그럼 일주일 안에 다시 오래돼 버릴 가능성이 있었습니다.

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

보드

우리 에이전트는 이미 마크다운으로 작업합니다. 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 로그에서 이를 확인해 몇 초 안에 YAML을 수정합니다.

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

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 라운드‑트립 1회, SHA 비교 1회) 폴링합니다. 원격 저장소에 새로운 커밋이 있으면 풀하고 어떤 내용이 들어왔는지 로그에 기록합니다:

[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와 저는 각자의 IDE와 보드에서, 에이전트들은 `backlog/`에 커밋합니다. Git이 모든 것을 연결해 주죠. 전체 스택은 순수 HTML/CSS/JS이며, 빌드 단계가 없고 npm 의존성도 없습니다.  

```js
// 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는 아무도 관리하지 않는 복사본이었으므로 우리는 그 복사본을 삭제하고 원본에 창을 띄웠다.

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

---

## 연락하기

- **Newsletter:** [여기 구독하기](https://fluado.com/#newsletter)  
- **LinkedIn:** [LinkedIn에서 Fluado](https://www.linkedin.com/company/fluado)  
- **Mastodon:** [@fluado@mastodon.social](https://mastodon.social/@fluado)  
- **Bluesky:** [Bluesky에서 fluado.com](https://bsky.app/profile/fluado.com)

에이전트가 필요한 프로세스가 있나요? **[대화해요](mailto:contact@fluado.com).**