산티아고 브레인 구조를 설계하다 -3편

목표에서 오늘 실행까지, 그리고 적은 비용으로 만들기 위한 선택

Santiago Brain을 만들기 시작했을 때 처음부터 완성된 구조가 있었던 것은 아니다.

처음에는 단순했다.

오늘 해야 할 일을 보여주고,
일정을 확인하고,
필요한 내용을 기록하는 정도면 충분하다고 생각했다.

그런데 실제로 사용하다 보니 점점 질문이 생겼다.

“오늘 해야 할 일은 어디서 오는가?”

“이 할 일은 어떤 목표와 연결되어 있는가?”

“프로젝트는 목표와 어떻게 다른가?”

“아이디어는 바로 프로젝트로 만들어야 하는가?”

“끝난 일은 어디로 가야 하는가?”

결국 문제는 기능을 많이 넣는 것이 아니라,
내 생각과 행동이 하나의 흐름으로 이어지게 만드는 것이었다.

그래서 Santiago Brain의 구조를 하나씩 다시 설계하기 시작했다.

가장 먼저 정한 것은 ‘오늘’ 화면이었다

나는 앱을 열었을 때 복잡한 관리 화면부터 보고 싶지 않았다.

오늘 무엇을 해야 하는지가 먼저 보여야 했다.

그래서 오늘 화면은 관리 화면이 아니라 실행 화면으로 정했다.

오늘 화면에는 이런 것만 나오도록 했다.

오늘 꼭 해야 할 일,
마감이 지난 중요한 일,
가까운 일정,
그리고 지금 우선순위가 높은 일.

반대로 모든 프로젝트나 모든 목표를 한꺼번에 보여주지는 않았다.

관리와 실행을 섞으면 화면이 금방 복잡해지기 때문이다.

그래서 하나의 원칙을 만들었다.

오늘 화면에서는 지금 해야 할 것만 보여준다.

목표와 프로젝트는 역할을 나눴다

처음에는 목표와 프로젝트의 차이가 애매했다.

예를 들어 “인문고전 유튜브를 운영한다”는 것이 목표인지 프로젝트인지 헷갈렸다.

그래서 기준을 정했다.

목표는 내가 이루고 싶은 결과다.

예를 들면,

“인생 후반기의 독서·글쓰기·철학·창작 생활을 구축한다.”

이것은 하나의 방향이고 결과다.

반면에 프로젝트는 그 목표를 이루기 위해 실제로 추진하는 구체적인 일이다.

예를 들면,

“인문고전 유튜브 30강 제작”

“전자책 발행”

“블로그 인문고전 카테고리 구축”

이런 것이 프로젝트다.

이렇게 나누니 구조가 훨씬 선명해졌다.

목표는 방향이고, 프로젝트는 실행 단위다.

프로젝트 아래에는 마일스톤을 두었다

프로젝트를 만들고 나니 또 다른 문제가 생겼다.

프로젝트가 너무 크면 지금 어디까지 왔는지 알기 어려웠다.

그래서 마일스톤을 넣었다.

마일스톤은 프로젝트의 중간 지점이다.

예를 들어 유튜브 프로젝트라면,

채널 콘셉트 확정,
첫 영상 3편 제작,
썸네일 스타일 확정,
주 1회 업로드 루틴 정착.

이런 식이다.

마일스톤은 단순한 할 일보다 크고,
프로젝트 전체보다는 작다.

그래서 프로젝트가 어디까지 진행됐는지 확인하기 쉬워졌다.

할 일은 실제 행동으로 만들었다

할 일은 가능한 한 행동 단위로 만들었다.

“유튜브 준비”처럼 큰 문장은 할 일이 아니다.

대신,

“1강 원고 초안 작성”

“썸네일 문구 3개 만들기”

“영상 업로드”

처럼 실제로 완료 여부를 판단할 수 있는 형태로 만들었다.

그리고 모든 할 일이 같은 중요도를 가지는 것은 아니기 때문에
필수 할 일이라는 개념도 넣었다.

필수 할 일이 완료되면 목표나 프로젝트 진행률에 반영되도록 했다.

이렇게 해서 구조가 연결됐다.

목표 → 프로젝트 → 마일스톤 → 필수 할 일 → 오늘 실행

아이디어는 바로 프로젝트로 만들지 않았다

아이디어가 생길 때마다 바로 프로젝트로 만들면 프로젝트가 너무 많아진다.

그래서 프로젝트 & Idea 화면에서 아이디어와 프로젝트를 분리했다.

생각이 떠오르면 먼저 아이디어로 저장한다.

그리고 필요하면 브레인 대화를 통해 검토한다.

가능성이 있으면 프로젝트로 전환한다.

즉,

생각이 있다고 해서 바로 실행하지 않는다.

이 과정이 Santiago Brain의 중요한 특징 중 하나가 됐다.

브레인 대화도 구조의 한 부분이 됐다

나는 단순히 질문하고 답을 받는 AI보다는,
생각을 발전시키는 AI가 필요했다.

그래서 일반대화, 브레인검토, 반대입장검토라는 흐름을 생각했다.

일반대화에서는 자유롭게 이야기한다.

조금 더 검토할 가치가 있으면 브레인검토로 넘어간다.

가능성이 있다면 반대입장검토를 통해 위험과 약점을 본다.

그리고 필요하면 결정일지나 아이디어, 기억으로 저장한다.

이렇게 보면 Santiago Brain은 단순한 일정 앱이 아니다.

생각 → 검토 → 결정 → 프로젝트 → 할 일 → 실행 → 회고

이 흐름 전체를 연결하려고 만든 시스템이다.

회고와 기록도 따로 두었다

처음에는 오늘 있었던 일을 간단히 기록하면 된다고 생각했다.

그런데 기록과 회고는 역할이 달랐다.

오늘의 기록은 하루 중 있었던 일,
생각, 느낌, 배운 점, 감사한 일을 자유롭게 남기는 공간이다.

반면 회고는 일정 기간을 돌아보는 과정이다.

이번 주에는 무엇을 했는지,
무엇이 미뤄졌는지,
어떤 프로젝트가 진행됐는지,
다음 주에는 무엇을 바꿔야 하는지 살펴본다.

그래서 기록은 매일 쌓이고,
회고는 그 기록을 다시 보는 구조로 만들었다.

지식창고와 결정일지는 따로 관리했다

앱을 사용하다 보면 중요한 것이 쌓인다.

어떤 것은 그냥 정보이고,
어떤 것은 내가 내린 결정이다.

그래서 둘을 분리했다.

지식창고에는 나중에 다시 참고할 정보나 자료를 모으고,

결정일지에는 내가 왜 그런 결정을 했는지 남긴다.

나중에 같은 문제를 다시 만났을 때 과거 판단을 다시 확인할 수 있게 하기 위해서다.

하지만 하고 싶은 기능을 다 넣을 수는 없었다

Santiago Brain을 만들면서 현실적인 문제도 있었다.

개발 예산이 넉넉하지 않았다.

AI를 이용하면 개발 비용을 많이 줄일 수는 있지만,
그래도 계속 비용이 들어간다.

Replit 사용료가 들어가고,
AI 모델을 호출하면 API 비용이 생길 수 있다.

데이터베이스도 사용량이 커지면 비용이 올라갈 수 있다.

문자 메시지도 발송할 때마다 비용이 발생한다.

그래서 처음부터 한 가지 원칙을 세웠다.

“좋아 보이는 기능을 다 만드는 것이 아니라, 실제로 필요한 기능부터 만든다.”

무료 또는 저비용 기능을 최대한 활용했다

가능하면 이미 가지고 있는 서비스를 활용했다.

일정은 새로 만들지 않고 Google Calendar를 연결했다.

할 일도 Google Tasks를 활용했다.

데이터 저장은 Supabase를 사용했다.

앱 개발과 배포는 Replit을 중심으로 진행했다.

문자 발송도 대규모 알림 시스템을 만들기보다 필요한 시간에만 보내는 방식으로 구성했다.

처음부터 거대한 시스템을 만들지 않았다.

사용자가 한 명인 개인용 앱이기 때문에
대기업 서비스처럼 복잡한 구조가 필요하지 않았다.

개발비를 줄이기 위해 기능도 단계적으로 만들었다

처음부터 모든 기능을 완벽하게 만드는 방법도 있었을 것이다.

하지만 그렇게 하면 시간과 비용이 많이 든다.

그래서 기능을 작은 단위로 나눴다.

먼저 작동하게 만든다.

직접 사용해본다.

필요하면 수정한다.

필요 없는 기능은 만들지 않는다.

이 방식은 때로는 여러 번 수정해야 하는 단점이 있었다.

하지만 나에게는 장점이 더 컸다.

실제로 사용하지 않을 기능에 돈을 쓰지 않아도 됐다.

예를 들어 어떤 기능이 좋아 보여도 내가 실제로 거의 사용하지 않는다면 더 개발하지 않았다.

반대로 매일 사용하는 기능에서 불편한 점이 생기면 그 부분에 비용과 시간을 집중했다.

AI 모델도 무조건 비싼 것을 쓰는 것이 답은 아니었다

AI를 연결할 때도 같은 생각을 했다.

모든 요청에 가장 비싼 AI 모델을 사용할 필요는 없다.

간단한 분류나 요약은 가벼운 모델로 처리할 수 있고,

중요한 판단이나 깊은 검토가 필요한 경우에만 더 좋은 모델을 사용할 수 있다.

아직 Santiago Brain에서는 이런 부분도 계속 검토하고 있지만,
기본 방향은 분명하다.

비용은 줄이고, 중요한 부분에는 품질을 유지하는 것.

가장 중요한 것은 ‘기능 수’가 아니었다

앱을 만들다 보면 새로운 기능을 계속 추가하고 싶어진다.

하지만 사용하면서 느낀 점은 다르다.

기능이 많다고 좋은 앱은 아니다.

오히려 너무 많으면 내가 사용하기 어려워진다.

그래서 지금은 기능을 추가할 때마다 이런 질문을 한다.

“이 기능을 실제로 사용할까?”

“기존 기능으로 해결할 수는 없을까?”

“이 기능 때문에 월 비용이 계속 늘어나지는 않을까?”

“관리해야 할 시스템이 하나 더 생기지는 않을까?”

이 질문을 통과한 기능만 추가하려고 한다.

지금의 Santiago Brain 구조

지금까지 정리된 구조를 한 줄로 표현하면 이렇다.

생각 → 검토 → 결정 → 목표 → 프로젝트 → 마일스톤 → 할 일 → 오늘 실행 → 회고

그리고 그 주변에

지식창고, 기억, 일정, 문자 알림

이 연결되어 있다.

처음에는 단순한 오늘 할 일 앱에서 시작했지만,
조금씩 나의 생각과 실행을 연결하는 구조로 발전했다.

그리고 중요한 것은 이것을 거대한 비용을 들여 만든 것이 아니라는 점이다.

이미 있는 서비스를 활용하고,
AI에게 개발을 맡기고,
필요한 기능만 하나씩 추가하면서 만들고 있다.

나는 오히려 이 제약이 Santiago Brain을 더 현실적으로 만들었다고 생각한다.

돈이 많았다면 처음부터 기능을 너무 많이 넣었을지도 모른다.

예산이 부족했기 때문에,

무엇이 정말 필요한가를 더 많이 고민하게 됐다.

다음 글 예고

4편 — AI와 그냥 대화하는 것과 ‘브레인검토’는 무엇이 다른가

다음 글에서는 Santiago Brain에서 왜 일반대화, 브레인검토, 반대입장검토라는 방식을 만들었는지 이야기해보려고 한다.

AI의 답을 그대로 받아들이는 것이 아니라,

생각을 넓히고 → 현실성을 검토하고 → 일부러 반대편에서 다시 보고 → 필요한 결과만 남기는 과정

을 어떻게 만들고 있는지 실제 사례를 중심으로 정리해보겠다.