# Ocean Brain에 Properties를 추가한 이유 태그로는 상태와 프로젝트를 다루기 어려웠다 - Author: @baealex - Published: 2026-06-02 - Updated: 2026-06-02 - Source: https://blex.me/@baealex/ocean-brain-properties - Tags: 프로젝트, 개발노트, 인공지능 --- Ocean Brain에 Properties를 넣는 건 꽤 망설였던 일이다. 이 기능은 “노트 앱에 데이터베이스 기능도 있으면 좋겠다”는 이유로 들어간 것이 아니다. 오히려 그 반대에 가까웠다. Ocean Brain은 가능한 노트들을 글로써 가치를 남겨두고 싶었고, 구조는 꼭 필요한 만큼만 추가하고 싶었다. 기능 하나를 붙이는 건 생각보다 무겁다. 처음에는 작아 보여도, 한 번 들어간 기능은 계속 유지보수 대상이 된다. 더 어려운 건 나중에 그 기능을 쉽게 빼거나 바꾸기 어렵다는 점이다. 사용자가 어떤 패턴에 익숙해지면, 그 패턴은 제품 안에 고착된다. 그래서 Properties는 꽤 오래 미뤄둔 기능이었다. 가능하면 굳이 새 개념을 추가하고 싶지 않았다. 처음에는 실제로 태그와 리마인더로 버텼다. 노트를 쓰고, 노트끼리 링크하고, 백링크로 다시 이어 보고, 태그로 묶는 정도면 충분하다고 생각했다. 특정 시점에 다시 보고 싶은 노트는 리마인더로 Ocean Brain 캘린더에 올릴 수 있었다. 실제로 초반에는 그 정도만으로도 잘 굴러갔다. 문제는 노트가 많아지면서 태그가 점점 다른 역할을 하기 시작했다는 데 있었다. ## 태그로 버티다가 막힌 부분 처음에는 대부분의 분류를 태그로 처리했다. ```typescript @oceanbrain @todo @done @plan @product ``` Ocean Brain의 Views 기능도 태그 기반으로 만들었다. 특정 태그가 붙은 노트만 모아서 보여주는 식이다. 예를 들어 `@oceanbrain` 과 `@todo` 가 붙은 노트만 모아 보면, Ocean Brain에서 아직 처리해야 할 일을 볼 수 있었다. 이 정도만 해도 꽤 유용했다. 그런데 시간이 지나면서 문제가 생겼다. 태그는 “이 노트가 무엇과 관련 있는가”를 표시하기 좋다. 하지만 프로젝트, 상태, 종류 같은 값을 전부 태그로 표현하려고 하면 경계가 모호해지고, 순식간에 복잡해진다. 예를 들어 어떤 노트가 Ocean Brain 프로젝트에 속해 있고, 아직 할 일 상태라고 해보자. ```typescript @oceanbrain @todo ``` 처음에는 충분해 보인다. 하지만 노트가 많아질수록 이 태그가 단순 분류인지, 실제 프로젝트 구분인지, 작업 상태인지 애매해진다. 상태도 비슷하다. `@todo`, `@doing`, `@done`, `@waiting` 같은 태그를 쓰다 보면 어느 순간부터 태그가 분류인지, 상태값인지, 그냥 임시 표시인지 헷갈린다. `@todo`, `@wip`, `@doing`, `@inprogress` 처럼 비슷한 태그가 같이 생길 수도 있다. 태그는 자유로워서 좋지만, 그 자유로움 때문에 여러 노트가 공유해야 하는 상태값을 다룰 때는 조금 불안정해진다. ## Properties를 넣으면 달라지는 것 Properties를 넣기로 했을 때 가장 먼저 필요했던 건 `select` 타입이었다. 상태 같은 값은 아무 값이나 들어가면 곤란하다. 여러 노트가 같은 선택지를 공유해야 한다. ```typescript - todo - doing - waiting - done ``` 이 값들이 노트마다 제각각이면, 나중에 “아직 할 일로 남아 있는 노트만 보여줘” 같은 요청이 애매해진다. 그래서 상태 같은 값은 태그보다 property가 더 맞았다. ```typescript project: Ocean Brain status: todo ``` 이렇게 되면 “Ocean Brain 프로젝트 안에서 아직 끝나지 않은 노트”를 훨씬 안정적으로 가져올 수 있다. 리마인더와 Properties도 역할이 다르다. 리마인더는 특정 시점에 노트를 다시 보거나, Ocean Brain 캘린더 위에 노트를 올리는 기능에 가깝다. 반면 Properties는 노트가 가진 값을 일관되게 다루기 위한 기능이다. 그래서 Properties의 기본 사용 패턴은 이렇게 잡았다. ```typescript project: Ocean Brain status: todo priority: high ``` 필요하다면 날짜도 property로 둘 수 있다. ```typescript reviewAt: 2026-06-05 ``` 하지만 핵심은 날짜 자체가 아니다. 노트는 계속 자유롭게 쓰되, 상태나 프로젝트처럼 나중에 다시 조회해야 하는 값을 따로 들고 있게 하는 것이다. ## 실제로 가능해지는 사용 Properties가 들어오면 단순히 노트 상단에 정보가 예쁘게 붙는 것 이상이 가능해진다. 예를 들면 이런 식이다. ```typescript Show unfinished notes in the Ocean Brain project Collect notes with status = doing Find notes with priority = high Ask AI to summarize notes with a specific status ``` 이전에도 태그와 리마인더를 잘 조합하면 비슷한 일을 할 수는 있었다. 하지만 태그는 열린 값이라서 오래 쓰다 보면 복잡해지기 쉽고, 리마인더는 노트에서 시간다루는데 유용하지만 진행 상태를 표기하기엔 적합하지 않다. Properties는 그 기준을 조금 더 명확하게 만든다. `status` 는 상태이고, `priority` 는 우선순위이고, `project` 는 프로젝트다. 이 값들이 데이터로 들어 있으면 앱도, AI도, 나중에 추가될 뷰도 같은 기준으로 노트를 다룰 수 있다. AI에게도 이 차이는 꽤 크다. `@todo` 라는 태그만 보면 그것이 작업 상태인지, 임시 표시인지, 주제 분류인지 추측해야 한다. 하지만 `status: todo`, `project: Ocean Brain` 처럼 값이 분리되어 있으면 AI도 같은 기준으로 노트를 찾고 요약할 수 있다. Ocean Brain의 MCP 도구가 properties를 읽고 조건으로 검색할 수 있게 된 것도 이 흐름과 맞닿아 있다. 그게 이번 기능의 가장 큰 이점이다. ## 왜 이런 방식이어야 했나
ig_0f131d126d9db3ea016a1eec90f76081918612d2e436456c12.png
Properties를 만들면서 Notion이 왜 복잡한 제품인지 조금 알 것 같았다. 겉으로 보면 그냥 페이지에 속성을 붙이는 기능처럼 보인다. 그런데 직접 만들려고 하면 하나하나가 다 결정이다. > - Notion은 어떻게 문제를 풀고 있지? 왜? - Obsidian은 어떻게 문제를 풀고 있지? 왜? > - 어떤 속성까지 지원해야 유의미하지? > - 사용자가 어디서 속성을 만들어야 편하지? > - 얼마나 자유도를 제공해야 하지? Ocean Brain에서는 일단 Obsidian식 자유 frontmatter처럼 아무 key나 막 넣는 방식보다는, 사용자가 전역에서 property를 정의하고 노트는 그 정의된 property에 값을 채우는 쪽으로 잡았다. Obsidian은 아무래도 파일 베이스가 먼저 되기때문에 이런 전략을 취하고 있고 잘 맞는거 같다. 단순하고, 자유롭다. Ocean Brain의 차별점은 자체적으로 RDB가 존재하며, 그 안에서 정보들을 관리하는 부분이라고 판단했다. 누군가에게 이 방식은 좀 더 번거로울 수 있다. 먼저 property를 정의해야 하고, 선택지도 관리해야 한다. 하지만 그 덕분에 여러 노트가 같은 상태를 안정적으로 공유할 수 있다. `status` 라는 property가 있으면, 그 값은 각 노트의 즉흥적인 텍스트가 아니라 워크스페이스 안에서 합의된 상태값이 된다. 초기 설정은 필요하지만 설정 위에서 AI도 사람도 실수하기 어려운 환경이 된다. ## 그래서 지금은 이 정도로만 사실 Properties를 만들고 나서도 조금 조심스럽다. 노트 앱이 너무 빨리 데이터베이스가 되는 걸 별로 좋아하지 않는다. 처음에는 편해 보여도, 어느 순간부터 글을 쓰기보다 필드를 채우는 일이 먼저가 될 수 있기 때문이다. 내가 자유롭고 편하게 생각을 도출하는 공간에서 사소한 노이즈가 생기는 것을 경계하고 있다. 그래서 이번 구현에서 중요하게 본 건 “무엇을 더 할 수 있게 만들까”가 아니었다. 오히려 어디서 멈출지가 더 중요했다. 상태를 고르고, 프로젝트를 붙이고, 나중에 그 값으로 다시 찾을 수 있으면 지금은 충분하다. 태그로 계속 버틸 수도 있었다. 실제로 꽤 오래 그렇게 썼다. 다만 어느 순간부터 태그가 주제와 상태와 작업 흐름을 한꺼번에 떠안기 시작했고, 그때부터는 자유로움보다 애매함이 더 커졌다. 이번 Properties는 그 애매함을 조금 덜어내기 위한 작은 구조다. 노트는 여전히 글로 남긴다. 대신 나중에 다시 보고 싶은 값들은 조금 더 분명하게 적어둔다. 지금은 그 정도가 Ocean Brain에 맞는 선이라고 생각한다.