
진척도를 작성하는 것은 AI, 인간은 읽기만 한다 —— 3체의 에이전트가 업데이트하는 개인 개발 대시보드
요약
여러 AI 에이전트와 협업하며 발생하는 진척 관리 문제를 해결하기 위해, 인간 대신 AI가 직접 상태를 기록하는 NEXUS CORE 대시보드 구축 사례를 소개합니다. 입력의 귀찮음을 제거하여 데이터의 지속성을 확보하고, 에이전트 간의 병렬 개발 효율을 극대화하는 방법을 다룹니다.
핵심 포인트
- 진척도 작성 주체를 인간에서 AI 에이전트로 전환하여 입력 부담 제거
- 에이전트의 작업 부산물로서 자발적인 상태 업데이트 규칙 수립
- 단일 명령어를 통한 쓰기 경로 압축으로 데이터 무결성 유지
- 현재 상태(JSON)와 업데이트 이력(JSONL)을 분리한 데이터 설계
나는 개인 개발을 아오이(Claude · 설계), 루나(Gemini · 환경과 잡무), 아리사(Codex · 구현)라는 3체의 AI 에이전트에게 역할 분담을 시키고 있다. 역할을 나누면 개발은 병렬로 진행된다. 게임, 툴, 콘텐츠 제작 —— 여러 프로젝트가 동시에 앞으로 나아간다.
하지만 병렬로 진행될수록 새로운 문제가 발생한다.
"지금 어떤 프로젝트가 어디까지 진행되었더라"를 스스로도 알 수 없게 된다.
이 기사는 그것을 해결하기 위해 만든 대시보드 —— NEXUS CORE에 관한 이야기다. 포인트는 단 하나. 진척도를 작성하는 것은 인간이 아니라 AI로 했다.
과제: 진척 관리 툴은 대개 지속되지 않는다
세상에는 진척 관리 툴이 산더미처럼 많다. 하지만 개인 개발에서 계속 사용해 본 적이 없었다. 이유는 명확하다. 입력이 귀찮기 때문이다.
작업에 집중하고 있으면 진척도를 작성하는 손이 멈춘다. "나중에 몰아서 써야지"라고 생각한 "나중에"는 대개 오지 않는다. 정신을 차려보면 지난주 상태 그대로 멈춰 있는 보드를 보며 "이제 업데이트하는 것도 귀찮네"라고 생각하게 된다. 툴이 나쁜 것이 아니다. 인간이 입력하는 설계 자체가 지속될 수 없는 구조를 가지고 있다.
이것은 AI 에이전트로 여러 프로젝트를 병행하게 되면서 치명적이 되었다. 혼자 할 때는 기억력으로 어떻게든 버텼던 혼란이, 3체의 AI가 동시에 서로 다른 프로젝트를 진행하게 되자 머릿속의 TODO로는 다 따라갈 수 없게 되었다.
발상의 전환: 쓰는 것은 AI, 읽는 것은 인간
한 일은 단순하다. 진척도를 작성하는 주어를 인간에서 AI로 교체했다.
3체 각각의 지시 파일에 "프로젝트의 상태가 변하면 이 명령어를 실행한다"라는 규칙을 심어두었다. 작업을 시작했을 때, 태스크가 끝났을 때, 다음에 할 일이 바뀌었을 때, 막혔을 때 —— 에이전트는 작업의 부산물로서 자발적으로 진척도를 기록한다.
powershell -ExecutionPolicy Bypass -File nexus-update.ps1 `
-Source claude -Project derelict -Status active -Progress 80 `
-Next "실테스트와 밸런스 미세 조정" -Note "SPEC_V4 구현 완료, typecheck 통과"
Source (누가), Project (프로젝트), Status (launch / active / spec / life / parked), Progress (0~100), Next (다음 액션), Note —— 이 정도의 인자만으로 상태가 대시보드에 반영된다.
인간인 나는 쓰지 않는다. 그저 바라보고 판단할 뿐. "오늘의 3수"를 보고 무엇부터 건드릴지 결정한다. 입력의 수고가 제로가 된 순간, 대시보드는 처음으로 계속 살아 움직이게 되었다.
쓰기 경로는 단 하나
에이전트가 3체나 있으면 데이터가 깨지기 쉬울 것 같아 보인다. 실제로는 반대로, 쓰기 입구를 하나로 압축함으로써 오히려 깨지기 어려워졌다.
운용 규약에 다음과 같이 명시해 두었다.
data/projects.json의 직접 편집은 금지 (스크립트가 부족할 때만 예외)
모두가 동일한 명령어를 통해서만 쓸 수 있으므로 포맷이 흔들리지 않는다. 업데이트 타이밍도 규약화했다 —— 작업 시작·재개 시, 태스크 완료 시, 다음 액션 변경 시, 진척이나 상태 변경 시, 블로커(Blocker) 발견 시. "마음 내킬 때 쓴다"가 아니라 "이 5가지 타이밍에는 반드시 쓴다"라는 운용 방식으로 정했다.
데이터 설계: 현재 상태와 이력을 분리한다
대시보드의 뒷단은 3개의 파일로 구성되어 있다.
projects.json── 각 프로젝트의 현재 상태 (덮어쓰기됨)projects.js── 브라우저 표시용 캐시events.jsonl── 업데이트 이력 (1행 1이벤트, 추가만 가능)
"현재 상태"와 "지금까지의 경위"를 별개의 파일로 나누었다. 이것은 이 연재의 지난 회차에서 썼던 공유 메모리 계층과 완전히 동일한 설계 원칙이다. 덮어쓰기되는 것과 계속 추가되는 것을 같은 파일에 섞지 않는다. 섞으면 현재 위치만 보고 싶은데 이력을 읽어야 하거나, 경위를 쫓고 싶은데 최신 값만 남아 있는 등의 사고가 발생한다.
실제로, events.jsonl
는 운영을 시작한 지 약 1개월 만에 378행에 달하고 있다. 3체의 에이전트(Agent)로부터 하루에 십수 건의 자발적인 업데이트가 도착하고 있는 셈이다. 이것이 "쓰는 것은 AI"라는 말이 그림의 떡이 아니라 실제로 돌아가고 있다는 증거가 된다.
배포는 일부러 성숙한 기술로
대시보드 본체는 프레임워크를 전혀 사용하지 않았다. 순수 HTML·CSS·JS에 작은 Node.js 서버(포트 4177 고정)를 사용했다.

Command Deck. 왼쪽 내비게이션을 통해 Overview / Focus / Projects / Lanes / Rhythm / Visions로 이동할 수 있다. 중앙의 "오늘의 3수"는 여러 프로젝트를 병행하더라도 길을 잃지 않기 위한 우선순위 표시(내용은 가려둠). 오른쪽에는 프로젝트를 선택하면 상세 정보가 열리며, 상태(Status)·진척도(Progress)·다음 액션(Next Action)을 그대로 편집할 수 있다.
공들여 만들지 않은 데에는 이유가 있다. 대시보드는 주인공이 아니다. 개발의 곁에 항상 있어 주기만 하면 그것으로 충분하다. 실행용 배치 파일을 스타트업(Startup)에 등록하고, 감시 프로세스(Watchdog)를 통해 다운되면 자동으로 복구되도록 설정하여, "보려고 마음먹지 않아도 열면 반드시 그곳에 있는" 상태를 만드는 데 시간을 썼다. 겉모습보다 상재성(Availability)을 우선시했다.
프로젝트의 전후로 연결된 것들
대시보드는 단순한 태스크(Task) 표가 아니다. 프로젝트의 전후로 다른 계층이 연결되어 있다.
프로젝트 안에는 기능 티켓(Feature Ticket)이 있다. 개별 기능을 착수(Doing)와 완료(Done)로 추적하는 메커니즘이 별도로 있으며, 에이전트가 기능 구현을 시작할 때와 끝낼 때 업데이트한다.
그 너머에는 인생 비전(Life Vision)이 있다. 2026년의 목표 15건을 visions.json으로 가지고 있으며, 각 프로젝트와 ID로 링크되어 있다. "이 프로젝트는 어떤 인생의 목표를 위해 움직이고 있는가"가 화면 위에서 하나로 이어진다.
프로젝트 → 기능 → 인생. 이 3개 층이 깊숙이 연결되어 있는 것이 이 대시보드의 실제 구조다 (비전이나 프로젝트 개별 상세 화면은 내용이 너무 개인적이어서 여기에는 싣지 않는다. 전체적인 뼈대만 보셔도 충분히 전달될 것이라 생각한다).
빠졌던 함정: PowerShell 5.1 × JSON의 지뢰밭
솔직하게, 막혔던 이야기도 적어둔다. 업데이트 스크립트는 PowerShell로 작성했는데, 여기서 꽤 많은 시간을 허비했다.
함정 1: 빈 배열 @()
를 ConvertTo-Json 하면 {} (빈 객체)로 직렬화(Serialize)되는 경우가 있다. 그러면 프론트엔드 측의 project.tags.includes(...)가 TypeError를 내뱉으며 대시보드 전체가 하얗게 변해버린다. 콘솔에는 에러가 뜨는데 화면에는 아무것도 나오지 않는다.
함정 2: Set-Content -Encoding UTF8
은 BOM이 포함된 UTF-8을 출력한다. Node.js 측의 JSON.parse가 BOM을 읽지 못해 Unexpected token 에러와 함께 조용히 종료된다.
둘 다 근본적인 해결책은 같았다. [System.IO.File]::WriteAllText로 교체하여 인코딩을 명시적으로 BOM 없는 UTF-8로 만드는 것이다. PowerShell의 표준 커맨들릿(Cmdlet)을 너무 신뢰해서는 안 된다는 교훈이 남았다.
그리고 이 두 가지 함정은 지난번에 작성한 공유 메모리 계층의 gotchas.md에 그대로 기록되어 있다. 다음에 같은 구현을 다루는 에이전트는 더 이상 이 지뢰를 밟지 않을 것이다. 대시보드 이야기를 하고 있었는데 어느덧 기억의 메커니즘으로 돌아온다. 이 두 가지는 독립된 기능이라기보다, 같은 설계 사상의 다른 얼굴이라고 생각한다.
요약: 인간은 읽는 쪽으로 돌아선다
화려한 기술은 사용하지 않았다. PowerShell 스크립트와 순수 HTML, 그리고 몇 개의 JSONL 파일뿐이다. 그것이 전부다.
하지만 "진척도를 쓰는 것은 AI"로 주어를 바꿈으로써 정보가 부패하지 않게 되었다. 진척도 관리 도구가 지속되지 않는 이유는 대부분 입력 비용에 있다. 그 부분을 AI에게 넘겨버리면, 인간에게 남는 것은 "보고 결정하는" 단순한 업무뿐이 된다.
다음에는 기억(공유 메모리 계층)이 "무엇을 알고 있는가"에 대한 것이었다면, "어떻게 하는가"를 축적하고 있는 계층인 Skills에 대해 쓰겠다.
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기