몇 달 뒤의 나를 위해 — 위키와 기록, 그리고 팀

프로젝트를 몇 달 하다 보면 이런 질문이 생깁니다.

“결제는 왜 이렇게 복잡하게 되어 있지?” “이 방법 예전에 한 번 해 봤던 것 같은데, 왜 그만뒀더라?” “이 기능은 언제 추가했지?”

나무는 무엇이 어디에 있는지는 잘 보여 주지만, 왜 그렇게 만들었는지까지는 담지 못합니다. 마지막 편에서는 그 “왜”를 남기는 위키와, 그동안 쌓인 기록을 돌아보는 방법, 그리고 여러 사람이 함께 쓰는 방법을 다룹니다.

몇 달 뒤의 나는 남입니다

직접 만든 프로젝트라도 몇 주만 지나면 낯설어집니다. AI가 코드를 써 준 바이브코딩이라면 더 그렇습니다. 내가 한 줄 한 줄 쓴 게 아니니까요.

AI도 마찬가지입니다. 새 대화를 열 때마다 AI는 프로젝트의 지난 사정을 전혀 모릅니다. 그래서 예전에 문제가 있어서 버린 방법을 다시 제안하기도 합니다.

이걸 막는 방법은 하나입니다. 적어 두는 것. 다만 사람이 매번 정리하기는 어려우니, AI에게 적게 하고 사람은 읽기만 하는 구조를 만들면 됩니다.

Umtri의 위키는 프로젝트의 백과사전입니다. 각 기능이 어떻게 동작하는지, 꼭 지켜야 할 규칙은 무엇인지, 프로젝트 안에서 쓰는 말이 무슨 뜻인지를 담습니다.

위키는 AI가 쓰고, 사람은 읽습니다. 배지 화면의 Overall 통계에서 Wiki 숫자를 누르면 위키가 열립니다.

위키는 처음부터 차례로 읽으면 프로젝트 전체를 파악할 수 있게 짜여 있습니다. 맨 위에 개요가 있고, 그 아래에 장(개념·구성·운영·용어 등), 그 아래에 항목이 놓입니다. 책처럼 번호가 붙습니다.

처음에는 목차만 세워 달라고 하세요. Umtri는 프로젝트 종류(웹 서비스, 앱 서비스, 라이브러리)별로 권장 목차를 갖고 있어서, AI가 그걸 참고해 세웁니다.

coffee-app 위키를 웹 서비스 목차로 세워줘.
지금 코드에서 확실히 알 수 있는 내용부터 채우고, 모르는 건 비워 둬.

“모르는 건 비워 둬”가 중요합니다. 추측으로 채운 문서는 틀린 줄도 모르고 믿게 되기 때문입니다.

위키가 진짜 힘을 발휘하는 건 결정을 내린 순간입니다.

쿠폰을 결제할 때가 아니라 주문을 만들 때 한 번만 적용하기로 했어.
그렇게 정한 이유(결제를 다시 시도하면 두 번 적용되는 버그)까지 위키에 적어줘.

처음엔 주문 상태를 1초마다 확인했는데, 서버 부담 때문에 5초로 바꿨어. 위키에 반영해줘.

이렇게 적어 두면, 몇 달 뒤 누군가 “쿠폰을 결제 단계로 옮기면 더 깔끔하지 않을까?”라고 할 때 위키가 대답해 줍니다.

새 작업을 시작할 때 AI가 위키부터 읽게 하면, 지난 결정을 모르고 엇나가는 일이 줄어듭니다.

coffee-app 위키에서 결제 관련 문서를 읽고, 그 규칙을 지키면서 환불 기능을 추가해줘.

위키를 처음부터 읽고, 이 프로젝트를 처음 보는 사람에게 설명하듯 요약해줘.

위키에는 “오늘 이걸 했다”를 덧붙이지 않습니다. 지금 어떻게 되어 있는지를 적는 곳이라, 내용이 바뀌면 옛 문장을 고쳐 씁니다. 대신 고칠 때마다 이전 내용이 리비전으로 남아서, 언제든 예전 모습을 볼 수 있습니다.

그래서 위키를 열면 항상 “지금의 정답”이 있고, 지나온 과정은 리비전과 나무의 기록이 맡습니다. 이 규칙은 Umtri가 AI에게 알려 주니, 여러분이 따로 신경 쓸 필요는 없습니다.

앞 편들에서 한 일들이 쌓이면 이런 걸 볼 수 있게 됩니다.

시간 슬라이더 — 프로젝트가 자라 온 순서를 처음부터 다시 재생합니다. 시즌을 골라 한 단계만 따로 볼 수도 있습니다.

잎마다 붙은 커밋 기록 — 잎을 누르면 그 부품이 언제, 어떤 작업으로 바뀌어 왔는지 보입니다.

버그 기록 — 해결된 버그에는 “실제로 무엇을 했는지”가 남아 있습니다. 비슷한 문제가 다시 생기면 여기부터 찾아보세요.

AI에게 물어봐도 됩니다.

coffee-app에서 지난 한 달 동안 무엇이 바뀌었는지 정리해줘.

주문 쪽에서 예전에 비슷한 버그가 있었는지 찾아보고, 그때 어떻게 고쳤는지 알려줘.

해결된 버그가 가장 많이 붙어 있는 곳이 어디야? 구조를 손봐야 할 곳이 있을까?

혼자 쓰던 배지를 다른 사람과 함께 볼 수도 있습니다. Settings → Organization에서 팀을 만들고, 이메일로 팀원을 초대합니다.

팀원의 역할은 세 가지입니다.

기획자나 디자이너처럼 코드를 보지 않는 동료에게는 Viewer로 초대해 보세요. 나무와 위키만으로도 “지금 어디까지 만들어졌는지”를 파악할 수 있습니다. 새로 합류한 개발자에게는 위키를 처음부터 읽어 보라고 하면 됩니다.

팀원의 AI도 같은 나무와 위키를 읽습니다. 누가 어떤 AI로 작업하든, 모두 같은 지도를 보고 일하게 됩니다.

베타 기간에는 한 팀에서 편집할 수 있는 사람(Owner·Editor)이 3명까지입니다. Viewer는 제한이 없습니다.

이 시리즈에서는 이런 순서로 Umtri를 살펴봤습니다.

바이브코딩의 장점은 속도입니다. 그 속도가 몇 달 뒤에도 유지되려면 “지금 이 프로젝트가 어떤 모습인지”, “왜 이렇게 되었는지”를 언제든 알 수 있어야 합니다. Umtri는 그걸 사람이 따로 정리하지 않아도, AI가 일하면서 함께 남기도록 돕습니다.

아직 직접 해 보지 않았다면 데모부터 열어 보세요. 가입 없이 바로 만져 볼 수 있습니다.