SYDESYDE
SYDESYDE
  • 피드
  • 쇼케이스
  • 블로그
  • 모임
SYDESYDE© 2026 SYDE. All rights reserved.
SYDE 소개문의하기
Kakao
SYDE 오픈채팅
Instagram
Instagram
Threads
Threads
커뮤니티 가이드라인협업문의이용약관개인정보처리방침
커뮤니티 가이드라인협업문의이용약관개인정보처리방침

© 2026 SYDE. All rights reserved.

기억은 저장하는 것만으로 부족하다 — TouchMemory 개발기

기억은 저장하는 것만으로 부족하다 — TouchMemory 개발기

hHoya· 7일 전· 프로젝트 소개
목차
  • Todo 앱이 아니라 "기억 장치"였다
  • 화면을 새로 만들지 않고, 이미 쓰는 곳에 심었다
  • 설계 단계에서 내가 실제로 잡은 것들
  • 무엇을 만들고, 어떻게 검증했나
  • 어디서 막혔나
  • 결국 서버를 폰으로 옮겼다
  • 지금 배운 것
  • 다음: 지금은 "쓸모"를 확인하는 중
  • 공방 사례로서의 의미
  • 핵심 요약(5줄 이내)

목차

  • Todo 앱이 아니라 "기억 장치"였다
  • 화면을 새로 만들지 않고, 이미 쓰는 곳에 심었다
  • 설계 단계에서 내가 실제로 잡은 것들
  • 무엇을 만들고, 어떻게 검증했나
  • 어디서 막혔나
  • 결국 서버를 폰으로 옮겼다
  • 지금 배운 것
  • 다음: 지금은 "쓸모"를 확인하는 중
  • 공방 사례로서의 의미
  • 핵심 요약(5줄 이내)

요즘 하루의 시작이 좀 이상해졌다. "오늘 뭐 하지?"라는 질문을 내가 나한테 묻는 게 아니라, Claude Code한테 묻고 있었다. 원래 이건 내가 스스로 떠올려야 하는 질문인데, 어느샌가 그 역할을 AI에게 넘기고 있었던 거다.

문제는 그게 왜 반복되는지였다. 할 일을 안 적어서가 아니었다. 오히려 여기저기 적어두긴 하는데, 적어둔 걸 다시 안 보게 되는 것이 문제였다. 이미 결정한 일, 이미 본 이슈, 이미 떠올린 아이디어가 저장은 됐는데 다시 떠오르질 않았다. 그래서 이번엔 Todo 앱을 하나 더 만드는 대신, "다시 떠올리는 장치"를 만들어보기로 했다.

Todo 앱이 아니라 "기억 장치"였다

이름은 TouchMemory다. 유닉스의 touch 명령에서 따왔다. touch는 파일이 없으면 새로 만들고, 있으면 내용은 안 건드리고 접근·수정 시각만 갱신한다. 이 프로젝트의 핵심 문장도 그 동작에서 나왔다.

기억은 저장하는 것만으로 부족하다. 다시 건드려야 한다.

그래서 설계의 첫 결정은 "완료 여부"와 "다시 봐야 하는가"를 완전히 별개의 축으로 두는 것이었다. 일반 Todo 앱은 체크하면 그걸로 끝이다. 그런데 실제로는 이미 끝낸 일도 계속 신경 써야 할 때가 있다(예: 이미 완료 처리한 병원 예약을 매번 다시 확인하고 싶은 경우). 그래서 완료 여부와 지속 리마인드 on/off를 서로 독립된 값으로 뒀다 — 완료된 항목도 지속 리마인드가 켜져 있으면 계속 다시 노출된다.

화면을 새로 만들지 않고, 이미 쓰는 곳에 심었다

접근 채널은 Discord와 Claude Code 두 개로 좁혔다. 웹 화면은 만들지 않기로 했다 — 핵심 검증 목표(아침 맥락 복원, 잊지 않고 다시 떠올리기, 1주 이상 실사용) 중 어느 것도 화면을 전제하지 않았기 때문이다. 아침 맥락 복원은 "매일 지정 시각에 Discord로 먼저 요약을 보내는 능동 알림"으로 풀고, 조회·필터링은 Claude Code에게 자연어로 물어보는 걸로 충분했다.

다만 "웹이 없다"가 "백엔드도 간단히 해도 된다"는 뜻은 아니었다. Discord 봇과 Claude Code가 같은 데이터를 실시간으로 봐야 했고, 나중에 웹을 붙이더라도 그 데이터 계층을 그대로 재사용해야 했다. 그래서 형태는 "자동화 프로세스(능동 알림 스케줄러) + 상시 구동 API 서버(데이터 계층 단일 소유)"를 결합한 하이브리드로 정리됐다 — 화면은 없지만 백엔드는 제대로 서 있는 구조다.

여기서 "Claude"는 Anthropic API 호출이 아니라 Claude Code(로컬 실행 에이전트) 를 가리킨다. AI를 앱 안에 내장하는 대신, 이미 매일 쓰던 Claude Code가 저장소의 규칙 문서 한 장을 읽고 그 자리에서 CLI 도구를 대신 실행해주는 구조로 끝냈다.

설계 단계에서 내가 실제로 잡은 것들

설계를 내가 직접 검토하는 과정(Human Gate)에서 로직이 몇 군데 고쳐졌는데, 지금 돌아봐도 자동 생성만으로는 못 잡았을 것 같은 것들이다.

  • 전날 이전에 등록해놓고 리마인드를 따로 설정 안 한 일반 메모가 처음 로직에서는 아침 요약에 안 잡히는 구멍이 있었다. "따로 리마인드 안 걸어놓은 것도, 어제 만들고 아직 안 끝냈으면 다시 보여줘야 한다"는 원래 취지가 초안에서 빠져 있었던 걸 발견해 다시 넣었다.

  • once 리마인드의 의미를 재정의했다. "한 번 뜨고 사라지는 것"으로 오해하기 쉬웠지만, 실제로는 "지정일부터 활성화되어 완료 처리 전까지 계속 노출되는 것"이었다. 필드 이름과 실제 동작이 어긋나 있어, 사용자에게 보이는 설명은 이 정의로 통일했다.

  • 자정 부근 타임존 버그도 설계 단계에서 미리 잡았다. "어제/오늘 등록"을 DB 날짜 함수로 그대로 판단하면, 새벽 0시대에 등록한 로컬 기준 오늘 항목이 UTC 환산으로 "어제"가 돼버릴 수 있었다. 로컬 날짜 문자열을 앞자리만 잘라 비교하는 방식으로 바꿔 막았다.

  • 능동 알림이 겹쳐서 두 번 발송되는 것을 막기 위해, 정규 스케줄과 봇 재시작 직후 보정 발송이 같은 잠금(lock)을 거치도록 했다.

이 네 가지 전부 기본 실행 경로에서는 에러 없이 동작했다는 게 포인트다. 그런데 실제 의미가 요구사항과 어긋나 있거나, 특정 조건에서만 문제가 드러나는 유형이었다. 내가 짚어보지 않았으면 그대로 넘어갔을 것들이다.

무엇을 만들고, 어떻게 검증했나

이슈는 6개(기능) + 1개(버그) + 2개(표시 개선)로 나눠 처리했다.

  • 저장 계층(SQLite, WAL 모드) — [완료]

  • 중앙 API 서버 + "오늘 다시 볼 항목" 판정 로직 — [완료]

  • Discord 봇 기본 커맨드(등록/조회/완료/오늘요약) — [완료]

  • 매일 지정 시각 능동 알림(핵심 기능) — [완료], 실제 채널 발송·중복 방지·재시작 보정까지 실기 확인

  • Claude Code CLI(조회/등록/수정/삭제) — [완료], 완료 처리만 다음 버전으로 미룸 [예정]

  • 최소 사용 로그(등록/조회/완료/알림 4종 이벤트 기록, 통계 없음) — [완료]

  • 웹 UI(전체 조회 화면) — [예정], 검증 목표 어느 것도 화면을 전제하지 않아 이번 범위에서 의도적으로 제외

  • 운영 스크립트로 API+봇 동시 기동, 비정상 종료 시 자동 정리 — [완료]

검증은 실제로 서버를 띄운 상태에서 API 호출·Discord 명령 콜백·CLI 명령을 직접 실행하는 방식으로 했다. 특히 능동 알림은 시각을 임시로 앞당겨 실제 Discord 채널에 메시지가 도착하는 것까지 눈으로 확인했고, 그 뒤 자동 QA에서도 같은 방식으로 다시 검증했다.

어디서 막혔나

기능은 다 통과했는데, 두 가지가 QA에서 걸렸다.

첫째, 정작 처음 셋업하면 실행조차 안 되는 문제였다. 자동 QA가 문서(README)를 그대로 따라 클린 환경에서 기동해봤더니 곧바로 모듈을 못 찾는 에러로 죽었다. 원인은 실행 스크립트에 소스 경로를 잡아주는 설정이 빠져 있던 것. 어이없게도 나도 각 기능을 테스트할 때마다 이 설정을 수동으로 매번 넣어서 우회해왔는데, 정작 실행 스크립트 자체에는 반영하지 않았던 거다. 내가 매번 우회하고 있다는 걸 스스로도 모른 채 지나쳤던 셈이다. 한 줄 고치고 클린 환경에서 다시 재현해 통과를 확인했다.

둘째, 기능은 다 맞는데 쓰다 보니 헷갈리는 것들이었다. once를 "한 번만 뜨는 것"으로 오해하기 쉬웠던 건 나도 실제로 헷갈렸다. 완료/미완료 표시가 텍스트라서 목록이 길어지면 눈에 잘 안 띄는 것도 있었다. 둘 다 자동 검증으로는 절대 못 잡는 문제다 — 동작은 정확했으니까. 실제로 써보는 과정에서 드러났다. 드롭다운에 사람이 이해할 수 있는 표시 이름을 붙이고(예: "지정일부터 완료까지 보기"), 완료 상태를 이모지(✅/⬜)로 바꾸는 걸로 정리했다. 자동 QA가 기능 버그는 잡아도, UX는 결국 직접 써봐야 나온다는 걸 다시 확인한 경험이었다.

그 밖에 운영 환경에서 생긴 소소한 사고도 두 건 있었다. 핫스팟을 제공하던 폰을 들고 자리를 비운 사이 네트워크가 끊겨 QA 세션이 중단된 일과, 저장공간 부족으로 macOS의 iCloud 동기화가 새 파일을 제대로 받아오지 못해 개발용 가상환경이 반복적으로 통째로 사라진 일이었다.

결국 서버를 폰으로 옮겼다

기능 검증이 끝난 뒤 운영 방식을 바꿨다. 맥북에 의존하던 걸 안드로이드 폰(Termux 환경)으로 옮긴 것이다. 맥북을 꺼두면 봇도 같이 죽는 게 불편해서였고, 네트워크 방식(Tailscale)·백업 주기·전환 시점까지 전부 내가 먼저 승인한 뒤에 진행했다.

이 전환에서 흥미로웠던 건, 코드를 한 줄도 안 바꿨다는 점이다. "중앙 데이터는 API 서버 하나만 소유하고, 나머지는 API로만 접근한다"는 처음 설계 원칙 덕분에, 물리적으로 서버를 다른 기기로 옮기는 일이 그냥 됐다. 데이터는 정상 종료 후 안전한 백업 방식으로 옮겼는데, 무선 전송이 두 번 무응답으로 실패해서 결국 임시 HTTP 서버를 하나 띄워 파일을 내려받는 식으로 우회했다. 두 기기는 사설망(Tailscale)으로 연결했다.

전환 과정에서 새 버그도 하나 나왔다. 폰 환경에서만 일부 조회 기능이 서버 오류를 냈는데, 원인은 안드로이드 환경에 시스템 차원의 시간대 데이터가 없고, 이를 보완할 파이썬 패키지도 의존성 목록에 빠져 있던 것이었다. macOS는 이 데이터가 시스템에 내장돼 있어서 지금까지 드러나지 않았던 문제다. 의존성 한 줄을 추가하고 나서야 전 기능을 재검증했다.

또 하나 재미있었던(동시에 제일 아찔했던) 사고는 Claude Code 자연어 연동에서 났다. 공방 전체를 다루는 폴더에서 세션을 열고 "오늘 건드릴 기억 보여줘"라고 물었는데, TouchMemory 대신 전혀 다른 공방 자체의 기록 시스템을 뒤져서 엉뚱한 답을 내놨다. 하위 프로젝트 규칙 문서가 그 폴더 안 파일을 실제로 건드릴 때만 불려오는 구조인 데다, "기억"이라는 단어가 공방 자체의 다른 기록 시스템 용어와 우연히 겹친 탓이었다.

TouchMemory 폴더 안에서 규칙 문서를 제대로 불러오게 고쳤더니, 이번엔 다른 문제가 나왔다. 이전 세션이 남긴 좀비 로컬 서버 때문에 새 세션이 운영 서버 주소를 못 읽고 조용히 그쪽으로 접속해버려, 테스트 데이터가 폰이 아니라 맥북에 고립되는 사고가 났다. 규칙 문서에 "운영 서버는 폰이다, 설정에서 주소를 먼저 읽어라, 로컬 서버를 새로 띄우지 마라"를 명시하고 나서야 재발을 막았다.

그렇게 두 번 부딪히고 나서야, 진짜 확인하고 싶었던 장면을 볼 수 있었다. 맥북 Claude Code 세션에 "이거 TouchMemory에 저장해"라고 한 줄 치고, 폰 쪽 Discord에서 곧바로 그 항목이 똑같이 조회되는 걸 확인한 순간이다. 서로 다른 기기, 서로 다른 인터페이스인데 같은 기억을 실시간으로 공유하고 있었다 — 이게 되는 걸 스크린샷으로 직접 확인하고 나서야, 이 프로젝트가 "만들어진 앱"이 아니라 "쓰고 있는 인프라"가 됐다는 걸 실감했다. (그 사이 테스트로 남겨둔 기억 몇 개는 지우지 않고 그대로 남겨뒀다.)

지금 배운 것

  • 설계 단계의 사람 검토는 "동작하는 코드"와 "요구사항과 일치하는 코드"의 차이를 잡아낸다. 네 가지 보정 전부 실행 자체는 문제없었다.

  • 자동 검증이 기능 버그는 잡아도, "쓰기 편한가"는 결국 직접 써봐야 드러난다.

  • 데이터 계층을 한 곳에만 두고 나머지는 API로만 접근하게 만들어두면, 나중에 서버를 물리적으로 옮기는 것도 코드 변경 없이 가능해진다.

  • AI 연동 도구는 "이 문장이 어느 프로젝트 얘기인지"를 스스로 판단하지 못한다. 프로젝트 전용 규칙과 실제 작업 폴더가 어긋나면 엉뚱한 곳을 참조하거나, 이전 세션이 남긴 잔재(좀비 프로세스)로 조용히 다른 곳에 접속해버릴 수 있다 — 이런 경로 문제는 반드시 명시적으로 문서화해서 막아야 한다.

다음: 지금은 "쓸모"를 확인하는 중

지금은 1주일 정도 실제로 써보면서 가치를 검증하는 단계다 [진행중]. 자동 기동, 프로세스 감시(watchdog), 자동 백업, 로그 로테이션 같은 운영 편의 기능은 의도적으로 이번 범위 밖에 뒀다 [예정] — 안 만든 것도 사실 설계의 일부였다. 지금은 기능을 더 늘리는 것보다 "기억이 실제로 다시 살아나는지"를 확인하는 게 우선이라고 판단했기 때문이다.

공방 사례로서의 의미

이 프로젝트의 핵심은 AI가 코드를 얼마나 많이 짜줬는가가 아니다. 설계 단계의 사람 검토, 자동 검증, 실사용 검증이 각각 서로 다른 종류의 문제를 잡아냈다는 점이다. 설계 검토는 동작은 하지만 요구사항과 어긋난 로직 오류를 잡았고, 자동 검증은 클린 환경에서 아예 실행이 안 되는 결함을 잡았고, 실사용 검증은 그 자동 검증도 못 잡는 UX 문제를 잡았다. 어느 하나만으로는 충분하지 않았다.

그 위에서 운영 환경을 통째로 바꾸는 일도 설계 원칙 하나 덕분에 코드 변경 없이 가능했다. 그렇게 TouchMemory는 "만들어진 앱"에서 "실제로 쓰고 있는 시스템"이 됐다. 나에게 이 프로젝트의 완료 조건은 배포가 아니라, 저장해둔 기억을 다음 날 아침 정말 다시 건드리게 해주는가였다.

핵심 요약(5줄 이내)

  • TouchMemory는 Todo 앱이 아니라 "완료 여부"와 "다시 봐야 하는가"를 분리해 관리하는 개인용 기억 장치다.

  • 화면을 새로 만들지 않고 Discord + Claude Code(CLI) 두 채널에, 이미 쓰던 도구 위에 심는 방식으로 만들었다.

  • 설계 단계 사람 검토가 실행은 되지만 요구사항과 어긋난 로직 버그 네 건을 잡았고, 자동 QA는 클린 환경에서 아예 실행이 안 되는 결함을 잡았다.

  • 자동 QA가 못 잡는 문구·표시 관련 UX 문제는 실제로 써보는 과정에서 드러나 고쳤다.

  • 이후 서버를 폰으로 옮기는 운영 전환까지 코드 변경 없이 마쳤고, 지금은 1주일 실사용으로 실제 가치를 검증하는 중이다.


  • #상상공방
  • #claudecode
  • #mvp검증
  • #개발기록
  • #touchmemory
20
H
Hoya상상공방 운영자이자 세무법인 소속 개발자입니다.

Hoya님의 다른 글

  • 공유기가 끊긴 날, 결국 클라우드로 옮기기로 했다6일 전
  • 반복되는 흐름을 찾다가, 결국 AI의 기억을 설계하게 됐다6일 전
  • 잊었다는 사실조차 몰랐다 — TouchMemory 7일차 최종점검7일 전

댓글 0

My avatar