서비스 간의 경계를 넘어서: TODO 서비스 직접 만들기

Memos + Todo를 하나로, 그리고 Jules와의 실험기

개인 서버 위에서 돌아가는 서비스들이 서로 대화하도록 만들었던 지난 기록 이후, 제 안에는 또 다른 질문이 남았습니다. 굳이 계속 연결해야 할까, 아니면 내가 원하는 구조로 아예 새로 만들어버리는 편이 더 낫지 않을까 하는 고민이었습니다.

이전 글에서는 Memos와 Vikunja를 n8n으로 연결해 하나의 흐름으로 묶었습니다. 메모에 #todo를 적으면 자동으로 태스크가 생성되고, 완료되면 다시 메모로 돌아오는 구조였습니다. 그 과정은 재미있고, 개인 서버의 매력을 충분히 느끼게 해주었습니다. 서비스들이 API를 통해 서로 신호를 주고받고, 자동화 도구가 그 사이를 오가는 플로우는 꽤 인상적이었습니다.

하지만 연결을 계속 다듬다 보니 다른 생각이 들었습니다. 두 서비스를 매끄럽게 이어 붙이고 있다고 믿었지만, 어쩌면 서로 다른 철학을 억지로 봉합하고 있는 건 아닐까 하는 의문! 각 서비스는 저마다의 구조와 설계 의도를 가지고 있고, 그 틀을 벗어나려면 항상 API의 제약을 고려해야 했죠.

Docker 컨테이너는 늘어났고, 업데이트가 있을 때마다 명세 변경을 걱정해야 했습니다. 자동화는 성공했지만, 구조 자체가 제 사고 흐름에 완전히 맞아떨어진다는 느낌은 아니었습니다.

그래서 이번에는 방향을 바꾸었습니다.
연결이 아니라, 직접 만드는 쪽으로 말입니다.

왜 새로 만들었을까

저에게 필요한 기능은 단순합니다.

• 텍스트 중심의 메모
• #tag 기반 분류
• Todo 기능
• 완료 시 자동 로그 생성

Memos는 가볍고 직관적이었지만 Todo가 중심은 아니었습니다. Vikunja는 강력한 할 일 관리 도구였지만 메모와 자연스럽게 섞이지는 않았습니다. n8n으로 연결하면 원하는 동작을 흉내 낼 수는 있었지만, 하나의 유기적인 시스템이라는 인상과는 거리가 있었습니다.

그래서 아예 이렇게 설계했습니다.

• 메모 작성 시 Todo 토글 체크
• 완료하면 자동으로 #done-todo 로그 메모 생성
• 두 번째 태그를 프로젝트명으로 사용

이제 느낌이 어떤가요? 두 서비스를 연동한 결과물로 느껴지지는 않습니다. 제 작업 방식과 사고 흐름에 맞춰 처음부터 구성한 구조였습니다. 메모와 할 일이 나뉘어 있지 않고, 하나의 데이터 안에서 자연스럽게 이어지도록 설계한 시스템이었습니다.

이번 실험의 또 다른 목적: Jules

사실 이번 작업의 핵심은 기능 그 자체보다 도구를 바꿔보는 것이었습니다.

그동안은 주로 이런 흐름이었습니다.

1. Gemini에게 코드 요청
2. 파일 트리에 맞게 복사
3. 오류 발생
4. 다시 질문
5. 수정
6. 또 다른 오류

이후에는 Antigravity를 활용해 조금 더 자동화된 흐름을 시도하기도 했습니다. 이 과정은 조금 더 편리했지만 초보자인 제게는 여전히 피로한 방식이었습니다. 중간중간 승인 버튼을 눌러야 했고, 어떤 파일이 왜 수정되는지 완전히 이해하지 못한 채 진행 상황을 지켜봐야 했습니다. 무엇보다 작업 중에는 제 컴퓨터가 계속 점유되었습니다.

그러다 Jules를 알게되었습니다. Jules는 구글에서 만든 웹 기반 AI IDE 서비스로, 제 GitHub 저장소를 복제한 별도의 브랜치(같은 레포지토리에 있는 다른 버전이라고 생각하면 됩니다)에서 수정 작업을 진행하고, 완성된 결과를 제안하는 방식으로 동작합니다. 저는 완성된 변경 사항을 메인에 반영하는 버튼만 누르면 됩니다.

결론부터 말하면, 저 같은 초보에게는 훨씬 편했습니다.

Jules가 편했던 이유

1. 중간 승인 버튼이 없다

하나하나 허락하지 않아도, 목표와 요구사항을 설명하면 끝까지 작업을 진행합니다. 흐름이 끊기지 않습니다.

2. 진행 과정을 몰라도 결과가 나온다

내부 구현을 완전히 이해하지 못해도 시스템은 동작합니다. 지금 단계의 저에게는 세부 구현을 따라가는 부담이 줄어드는 것이 더 중요했습니다.

3. 컴퓨터를 점유하지 않는다

이 부분이 가장 크게 다가왔습니다. 설명을 남겨두고 컴퓨터를 끄고 잠들면, 다음 날 아침 결과가 준비되어 있습니다. 단순한 생산성 문제가 아니라 심리적인 여유의 차이였습니다.

자동화에서 제작으로

예전에는 서비스들이 서로 대화하도록 만드는 데 집중했습니다. 이번에는 아예 경계를 없애고 처음부터 구조를 설계했습니다.

n8n이 중앙 통제실이었다면, 이번 프로젝트는 건물을 새로 설계한 셈입니다. 더 이상 외부 서비스의 API 문법에 맞출 필요도 없고, 업데이트로 인한 변경을 걱정하지 않아도 됩니다.

• Todo 체크
• 완료 시 자동 로그
• 프로젝트 단위 집계

이 모든 흐름을 제가 정의합니다. 이제는 서비스 간의 연동이 아니라, 하나의 시스템 안에서 기능이 자연스럽게 이어집니다.

초보에게 맞는 도구는 따로 있다

Gemini도 훌륭했고, Antigravity도 분명 편리했습니다. 하지만 제 현재 단계에서는 Jules가 가장 부담이 적었습니다. 코드를 세밀하게 통제하는 방식이 아니라, 목표를 설명하고 결과를 받아 구조를 다듬는 방식이 지금의 저에게는 더 잘 맞았습니다.

이것은 도구의 우열 문제가 아니라, 내가 어디에 에너지를 쓰고 싶은가의 문제라고 생각합니다. 저는 지금 세부 구현을 완벽히 이해하는 것보다, 시스템의 구조와 흐름을 설계하는 데 더 많은 에너지를 쓰고 싶습니다. 그리고 Jules는 그 방향에 잘 맞는 도구였습니다.

파편에서 시스템으로, 그리고 다시 설계로

처음에는 단순히 여러 서비스를 설치하는 것에서 시작했습니다. 그 다음은 연결이었고, 이제는 직접 설계입니다.

개인 서버의 매력은 단순히 무언가가 돌아간다는 사실에 있지 않습니다. 흩어진 기능을 묶고, 묶인 기능을 다시 재구성하며, 결국 나만의 시스템으로 만들어가는 과정에 있습니다.

이전 글이 연동의 기록이었다면, 이번 글은 재구성의 기록입니다.

혹시 여러분도 서비스를 연결하다가 어딘가 어색함을 느끼고 있다면, 한 번쯤 이렇게 질문해보시기 바랍니다.

이어 붙일 것인지,
아니면 직접 만들어볼 것인지.

요즘은 그 간극을 메워줄 도구들이 생각보다 많습니다. 그리고 어느 날 아침, 여러분의 작업 방식에 꼭 맞는 시스템이 조용히 완성되어 있을지도 모릅니다.