기능을 쌓으며 트리에 기록하기 — 그리고 Season 개념

MCP까지 연결했다면 이제 Umtri를 실제 개발 흐름에 녹일 차례입니다. 이 편에서는 기능을 추가할 때마다 트리에 기록을 남기는 루틴과, 프로젝트의 성장 주기를 구분하는 Season 개념을 다룹니다. 계속해서 북마크 앱을 예제로 사용합니다.

시작 전에 하나 — Umtri의 나무는 시즌 안에서 자랍니다. 지난 편에서 그라운드만 만들어둔 상태라면 노드를 심을 자리가 없으니, app.umtri.io에서 첫 시즌을 먼저 추가하세요. 시즌 자체는 아래에서 따로 다룹니다.

기능이 쌓일수록 트리에 흔적 남기기

바이브코딩으로 기능을 하나씩 추가하다 보면 코드가 점점 복잡해지고, 어느 순간 AI도 전체 맥락을 한 번에 파악하기 어려워집니다. 이 문제를 해결하는 방법은 기능을 추가할 때마다 Umtri 트리에 기록을 남기는 것입니다.

기록 자체는 복잡하지 않습니다. 새 컴포넌트를 만들었다면 Umtri 트리에 leaf 노드 하나를 추가하는 것으로 충분합니다.

MCP가 연결된 상태에서 Claude Code에게 이렇게 요청합니다.

태그 기능 추가 완료됐어.
Umtri bookmark-app 그라운드 트리에 아래 내용 반영해줘:

- TagFilter 컴포넌트 → BookmarkList twig 아래 leaf로 추가
  (구현 파일: src/components/TagFilter.jsx)
- AddForm에 태그 입력 추가됐으니 AddForm leaf의 설명 업데이트
- localStorage에 tags 배열 추가됐으니 storage.js leaf 설명도 업데이트

각 노드에 어떤 파일이 그 노드를 구현했는지도 implements로 함께 기록해줘.

노드에 “이 노드를 만든 파일”을 함께 적기

마지막 줄이 사소해 보이지만 중요합니다. Umtri의 각 노드는 metadata.implements라는 자리에 그 노드를 실제로 구현한 파일 목록을 들고 있습니다. 노드 이름이 TagFilter라고 해서 Umtri가 TagFilter.jsx를 알아서 찾아주지는 않습니다. 누군가 적어줘야 합니다.

이 한 줄이 나중에 두 가지를 가능하게 합니다.

커밋이 노드에 자동으로 붙습니다. 다음 편에서 다룰 커밋 기록은 “커밋에서 바뀐 파일”과 이 implements 목록을 대조해서 해당 노드에 이력을 쌓는 방식입니다. 파일이 적혀 있지 않은 노드는 어떤 커밋도 붙지 않습니다.
plan 노드를 커밋할 수 있습니다. 아래에서 설명할 Plan 모드에서, implements가 비어 있는 노드는 승격 자체가 거부됩니다.

즉 “구현 파일까지 적어달라”는 말을 습관처럼 붙여두면, 트리가 코드와 실제로 연결된 상태로 유지됩니다.

반대 순서도 있습니다 — Plan 모드

지금까지는 “코드를 짜고 나서 트리에 기록”하는 순서였습니다. Umtri가 본래 의도한 흐름은 그 반대인 먼저 그리고 나중에 커밋하는 방식입니다.

앱에서 Plan 모드로 만들려는 노드를 초안(plan node)으로 그려둡니다.
Claude Code에게 “plan 노드 읽고 실현해줘”라고 요청합니다.
Claude Code가 트리를 읽어 plan 노드를 일종의 작업 지시서로 삼아 코드를 작성합니다.
작성한 파일을 그 노드의 implements에 기록하고, 노드를 정식 트리로 승격(커밋)합니다.

Umtri bookmark-app에서 plan 상태인 노드들 읽어줘.
그 내용대로 코드 작성하고, 다 되면 구현한 파일을 implements에 적고
plan을 커밋해줘.

구조를 먼저 설계하고 싶을 때는 이쪽이 낫고, 이미 손이 앞서 나갔다면 앞의 방식으로 뒤따라 기록하면 됩니다. 어느 쪽이든 결과물은 같습니다 — 파일과 연결된 트리.

이렇게 기록해두면 다음에 새 기능을 요청할 때 이렇게 할 수 있습니다.

Umtri에서 bookmark-app 트리 가져와줘.
검색 기능을 추가하려는데, 현재 구조에서 어디에 추가하면 좋을지 제안해줘.

Claude Code가 현재 트리 구조를 읽어서 검색 기능이 어떤 컴포넌트와 연관되는지, 어디에 위치해야 하는지를 파악한 뒤 제안합니다. 코드 파일을 모두 열어볼 필요 없이 트리 구조 하나로 전체 맥락을 파악합니다.

Season(시즌) 개념 활용하기

Umtri에는 Season이라는 개념이 있습니다. 프로젝트가 자라는 “장(章)“을 구분하는 단위로, 버전이나 단계·기간이라고 생각하면 됩니다. 자연의 계절처럼, 프로젝트도 단계별로 성장합니다.

시즌을 나누는 기준은 자유입니다. 예를 들어 이렇게 나눌 수 있습니다.

시즌	내용
Season 1	기본 기능 (북마크 저장·삭제)
Season 2	태그와 검색 기능 추가
Season 3	배포 및 공유 기능

여러 시즌 중 하나만 now이고 나머지는 past입니다. 새 시즌을 추가하면 그때까지의 now가 과거로 봉인되고, 앞으로 심어 나갈 새 시즌이 열립니다. 그래서 시즌을 추가한다는 건 “여기까지가 한 단계였다”고 선을 긋는 행위에 가깝습니다.

시간은 슬라이더에 있습니다

트리 화면에서 위아래로 뻗은 구조는 공간입니다 — 위쪽이 최신이라는 뜻이 아닙니다. 시간은 화면 아래쪽 시즌 슬라이더에 따로 담겨 있습니다.

슬라이더를 뒤로 끌면 노드가 생겨난 시점과 사라진 시점에 따라 가지와 잎이 돋고 떨어집니다. 심기 전(PRE) 상태부터 각 시즌의 이벤트까지, 프로젝트가 어떤 순서로 자랐는지를 그대로 되짚을 수 있습니다. “왜 이 구조로 바뀌었지?” 같은 질문이 나중에 생겼을 때 찾아볼 곳이 바로 여기입니다.

시즌은 사람이 만듭니다

한 가지 알아둘 점 — 시즌은 AI가 만들 수 없습니다. Umtri MCP에는 시즌을 생성하는 도구가 아예 없습니다. Claude Code에게 “새 시즌 열어줘”라고 해도 할 수 있는 일이 없습니다.

의도적인 설계입니다. 노드를 심고 고치는 건 작업이지만, “여기까지가 한 시즌이었다”고 선을 긋는 건 판단이기 때문입니다. 그래서 시즌 추가와 그라운드 마무리(뿌리내리기)는 사람이 앱에서 직접 하도록 남겨두었습니다.

실전 팁: 기능 추가 루틴

기능을 추가할 때마다 반복하면 좋은 루틴입니다.

1. 시작 전: 현재 구조 확인

Umtri에서 bookmark-app 트리 가져와서 현재 구조 요약해줘.

2. 코드 작성: 한 기능씩 요청

기능을 작은 단위로 쪼개서 순서대로 요청합니다.

3. 작동 확인

브라우저에서 추가된 기능이 정상 동작하는지 직접 확인합니다.

4. 기록: Umtri 트리 업데이트

[추가한 내용]을 Umtri 트리에 반영해줘.
구현한 파일도 implements에 같이 적어줘.

5. 단계가 끝나면: 시즌 마무리

한 덩어리의 작업이 끝났다고 판단되면 앱에서 새 시즌을 추가합니다. 이건 사람이 직접 하는 몫입니다.

이 루틴을 반복하면 기능이 늘어도 구조가 흐릿해지지 않습니다. 다음 작업을 시작할 때 항상 “현재 어디까지 왔는지”를 명확하게 파악하고 시작할 수 있습니다.

다음 편에서

다음 편에서는 배포·리팩터링·버그 같은 개발 이후의 이벤트들을 Umtri에 기록하는 방법을 다룹니다. GitHub Actions로 배포를 자동 기록하고, 리팩터링 후 트리를 동기화하고, 버그의 영향 범위를 트리로 파악하는 흐름을 살펴봅니다.