노트 앱에 폴더가 왜 필요해? | Logseq의 폴더구조가 없는 이유

Logseq doesn’t use a traditional folder tree because its core building blocks already model hierarchy more directly—and more flexibly—than folders ever could. Instead of forcing notes into parent-child directories, Logseq relies on blocks and page structure so that “containment” and “depth” are expressed through the writing syntax itself. In practice, creating a new page doesn’t require choosing a folder; it’s created directly, and hierarchy emerges from how blocks and pages nest inside one another.

The first reason is structural: folders exist mainly to represent upper–lower relationships when files can’t contain other files. Many note apps treat each note as an independent file, so folders become the workaround for organizing depth. Logseq flips that assumption. Its fundamental unit is the block, which behaves like a container. When a block is nested—such as imagining “2-1” and “2-2” blocks—everything placed inside the nested block effectively lives “inside a folder” with the same organizational effect. Because blocks already preserve hierarchy faithfully, adding a separate folder concept would add complexity without adding real expressive power.

A second reason is that Logseq’s pages can also act like folders. A page can contain content and also contain sub-pages, meaning the same entity can serve both roles at once. The transcript gives an example where a page like “CTA” can be expanded by creating another page such as “회계학 1부” under it. That “회계학 1부” page is simultaneously a container (like a folder) and a writable page (unlike a folder in many systems). This removes the common limitation where “folders can’t hold content,” and it enables a more continuous workflow: create a page, nest pages under it, and write directly where needed.

Logseq also reduces the need for folders through query-based retrieval. Queries search across blocks and pages using properties, producing results that function like dynamic collections. For example, searching for cards where a property like “public” equals “true” effectively creates a “virtual folder” containing all matching items. Since these collections are generated on demand from metadata, organization can be expressed as filters rather than fixed directory paths.

Taken together, the approach is strategic: folders are optional because Logseq’s hierarchy is built into blocks and pages, and its organization can be recomputed through queries. The practical takeaway is to lean into Logseq’s native syntax—especially for card workflows—rather than trying to force a folder mindset onto a system designed around nesting and property-driven retrieval. The session ends by emphasizing hands-on learning of Logseq’s card creation syntax and previewing a next step that uses card tags and shift-based commands to build cards more effectively.