개발자를 위한 체트카스트엔: 작동하는 실용적인 방법

개발자 지식 그래프를 구축하세요.

Page content

개발자들은 보통 정보 부족으로 고통받지 않습니다. 우리는 오히려 정보가 지나치게 많다는 점 때문에 고통받습니다.

API 문서, 풀 리퀘스트(Pull Request), 프로덕션 장애, 디자인 논의, 미팅 노트, 아키텍처 다이어그램, 코드 주석, 슬랙 스레드, 연구 논문, 실험 결과, 북마크, 그리고 미완된 아이디어들이 다섯 가지나 되는 서로 다른 도구들에 흩어져 있습니다. 정보가 부족해서 저장하지 못하는 것이 문제가 아닙니다. 진짜 문제는 그 정보를 재사용 가능한 사고로 전환하는 것입니다.

여기서 제텔카스텐(Zettelkasten)이 유용해집니다.

zettelkasten infographic

제텔카스텐은 종종 노트 기록 시스템으로 설명되지만, 이는 그 가치를 과소평가하는 것입니다. 올바르게 사용하면 제텔카스텐은 시간이 지남에 따라 아이디어를 발전시키는 개인 지식 관리 시스템입니다. 개발자들에게 있어서는 코드, 아키텍처, 디버깅, 학습, 그리고 글쓰기 사이의 실질적인 다리가 될 수 있습니다.

여기서 강조하고 싶은 점은 다음과 같습니다. 대부분의 개발자는 제텔카스텐을 낭만적인 생산성 취미로 삼아서는 안 됩니다. 아름다운 노트 박물관을 건설하지 마십시오. 대신 문제를 해결하고, 시스템을 설명하며, 더 나은 엔지니어링 결정을 내릴 수 있도록 도와주는 작동하는 시스템을 구축해야 합니다.

제텔카스텐이란 무엇인가?

제텔카스텐(Zettelkasten)은 독일어로 “슬립 박스(slip box)“를 의미합니다. 이 방법은 사회학자 닐스 루만(Niklas Luhmann)과 연관되어 있으며, 그는 연결된 방대한 노트 모음을 사용하여 아이디어를 발전시키고 광범위하게 글쓰기를 했습니다.

여기서 중요한 교훈은 그가 종이 카드를 사용했다는 사실이 아닙니다. 중요한 교훈은 그의 노트가 고립된 파일이 아니었다는 점입니다. 각 노트는 명확한 아이디어와 시스템 내에서의 위치, 그리고 다른 노트들과의 링크를 가지고 있었습니다. 시간이 지남에 따라 연결이 축적됨에 따라 시스템의 가치는 더욱 커졌습니다.

개발자를 위한 현대적인 버전은 간단합니다.

노트 하나당 하나의 유용한 아이디어를 작성합니다.
관련 노트와 연결합니다.
그 링크를 사용하여 설명, 결정, 패턴, 그리고 기사를 성장시킵니다.

이것이 전부입니다. 나머지는 구현 세부 사항에 불과합니다.

왜 개발자들은 지식 과부하에 어려움을 겪는가?

소프트웨어 개발은 세밀하면서도 일시적인 지식을 생성합니다.

캐시 무효화 버그가 발생한 이유를 알게 됩니다. 프레임워크에서 이상한 에지 케이스를 발견합니다. 두 가지 큐잉 전략을 비교합니다. 프로덕션 중단 문제를 디버깅합니다. 레거시 서비스가 이상하게 작동하는 이유를 이해합니다. 분산 추적(distributed tracing)에 대한 훌륭한 기사를 읽습니다.

그런 다음 두 달 후, 당신은 자신이 한때 그 답을 알았었다는 것을 막연하게 기억할 뿐입니다.

일반적인 개발자의 지식 관리 방식은 이 상황을 더 악화시킵니다.

북마크는 이해도가 아닌 소스를 저장합니다.
폴더는 조기 분류를 강요합니다.
위키는 아무도 소유하지 않으면 구식이 됩니다.
할 일 목록(TODO)은 작업과 아이디어를 혼합합니다.
코드 주석은 광범위한 개념이 아닌 지역적인 세부 사항을 설명합니다.
채팅 메시지는 기록 속으로 사라집니다.

제텔카스텐은 지식을 창고가 아닌 네트워크로 취급하기 때문에 도움이 됩니다. 만약 이 프레임이 두 번째 두뇌(second brain) 구축에 대한 글을 읽으며 익숙하게 느껴진다면, 그것은 우연이 아닙니다. 두 방법 모두 캡처와 재사용 사이의 간격을 좁히려 하지만, 제텔카스텐의 원자적 노트와 명시적 링크라는 원칙은 개발자들에게 기술적 아이디어에 대해 더 세밀한 통제를 제공합니다.

제텔카스텐의 핵심 원칙

원자적 노트(Atomic Notes)

원자적 노트는 하나의 아이디어를 포함합니다.

하나의 주제나 하나의 기사 요약, 또는 “PostgreSQL"이라는 거대한 페이지가 아닙니다. 하나의 아이디어입니다.

예를 들어, 다음은 너무 광범위합니다.

PostgreSQL 노트
Kubernetes
Caching
System design

다음은 원자적 노트에 더 가깝습니다.

Partial indexes reduce write overhead when queries target a small subset
Kubernetes readiness probes protect traffic routing, not container startup
Write-through caching improves consistency but increases write latency
Idempotency keys turn retries into safe operations

원자적 노트는 연결하기 더 쉽기 때문에 강력합니다. 거대한 페이지는 모호한 주제로만 연결될 수 있습니다. 반면에 집중된 노트는 정확한 개념, 결정, 버그, 또는 시스템과 연결될 수 있습니다.

좋은 개발자 노트는 일반적으로 다음 질문 중 하나에 답해야 합니다.

아이디어는 무엇인가?
언제 중요한가?
어떤 트레이드오프를 드러내는가?
실제 코드에서 어디에서 본 적이 있는가?
어떤 다른 개념과 연결되는가?

링크(Linking)

링크는 시스템의 핵심입니다.

여기서의 목적은 예쁜 그래프를 만드는 것이 아닙니다. 아이디어를 재사용 가능하게 만드는 것입니다.

멱등성 키(idempotency keys)에 대한 노트를 작성할 때, 재시도(retries), 분산 시스템, 결제 처리, 메시지 큐, API 디자인, 그리고 장애 예방에 대한 노트와 연결합니다. 데이터베이스 마이그레이션에 대한 노트를 작성할 때, 배포 안전성, 롤백 전략, 하위 호환성, 그리고 기능 플래그(feature flags)와 연결합니다.

링크는 일반적으로 다음 의미 중 하나를 가져야 합니다.

“이는 다른 각도에서 동일한 개념을 설명합니다.”
“이는 아이디어의 실제 예시입니다.”
“이는 트레이드오프나 반론입니다.”
“이 개념은 저 개념에 의존합니다.”
“이 노트는 더 큰 논증의 일부입니다.”

게으른 링크는 피해야 합니다. 모든 노트를 다른 모든 노트와 연결하면 소음이 생깁니다. 가장 좋은 링크는 의도적인 것입니다.

발현(Emergence)

발현은 제텔카스텐에서 신비롭게 들리지만 실제로는 실용적인 부분입니다.

완벽한 구조를 사전에 설계할 필요가 없습니다. 유용한 노트를 추가하고 정직하게 연결하며, 시간이 지남에 따라 클러스터가 나타나도록 합니다.

몇 달 후, 다음과 같은 주제들周围에 많은 노트가 연결되어 있음을 알 수 있습니다.

API 신뢰성
관측 가능성(Observability)
개발자 경험
이벤트 기반 아키텍처
데이터베이스 성능
기술 부채
문서화
보안 검토

이러한 클러스터는 미래의 기사, 내부 문서, 디자인 원칙, 컨퍼런스 발표, 온보딩 자료, 또는 더 나은 엔지니어링 결정이 됩니다.

이것이 제텔카스텐이 폴더 계층 구조와 다른 이유입니다. 폴더는 지식을 완전히 이해하기 전에 어디에 속해야 하는지 결정하도록 강요합니다. 링크는 지식이 여러 문맥에 속할 수 있게 합니다.

개발자를 위한 제텔카스텐의 적용

전통적인 제텔카스텐 조언은 종종 학술적 글쓰기에서 비롯됩니다. 개인 지식 관리 문헌은 이 전통을 잘 다루고 있습니다. 개발자들은 약간 다른 버전이 필요합니다.

개발자 제텔카스텐은 다음 세 가지를 연결해야 합니다.

개념(Concepts)
코드(Code)
시스템(Systems)

개념(Concepts)

개념 노트는 재사용 가능한 아이디어를 설명합니다.

예시:

Backpressure prevents fast producers from overwhelming slow consumers
Optimistic locking detects conflicting writes without blocking readers
Circuit breakers protect dependencies from repeated failing calls

이러한 노트는 자신의 말로 작성해야 합니다. 문서를 복사하는 것만으로는 충분하지 않습니다. 가치는 개념을 명확하게 설명하도록 스스로를 강요하는 데서 옵니다.

유용한 개념 노트에는 다음이 포함될 수 있습니다.

짧은 설명
구체적인 예시
트레이드오프
관련 패턴에 대한 링크
이를 사용한 실제 시스템에 대한 링크

코드

코드 노트는 실용적인 구현 지식을 포착합니다.

그것들은 임의의 스니펫 덤프가 아닙니다. 스니펫은 결정이나 패턴을 설명할 때만 유용합니다.

예시:

## Idempotent request handling with a database constraint

The safest implementation is often a unique constraint on the idempotency key.
The application can retry safely because duplicate requests resolve to the same
stored result instead of creating a second side effect.

Related:
- [[Retries need idempotent operations]]
- [[Database constraints are concurrency control]]
- [[Payment APIs should treat network failure as unknown outcome]]

좋은 코드 노트는 코드가 왜 작동하는지, 언제 사용해야 하는지, 그리고 무엇이 잘못될 수 있는지를 설명합니다.

시스템

시스템 노트는 추상적인 아이디어를 실제 아키텍처와 연결합니다.

예시:

The billing service uses idempotency keys because payment provider calls may
succeed even when our HTTP client times out.

이 노트는 다음과 연결할 수 있습니다.

Idempotency keys turn retries into safe operations
Timeouts do not prove failure
Payment APIs should model unknown outcomes
Outbox pattern separates database writes from external side effects

여기서 제텔카스텐은 시니어 엔지니어링 작업에 가치를 발휘합니다. 시스템이 왜 그 형태로 형성되었는지에 대한 기억을 구축하는 데 도움이 됩니다.

실용적인 워크플로우

단계 1: 순간적 노트(Fleeting Notes) 포착

순간적 노트는 거친 포착입니다. 다듬을 필요가 없습니다.

예시:

Look into why readiness probe failed during deploy.
Maybe retries made the duplicate invoice bug worse.
Good quote from incident review: timeout is not failure.
Research: Postgres partial index for active rows only.

가장 빠른 것을 사용하십시오: 옵시디안(Obsidian) 일일 노트, 로그시퀀스(Logseq) 저널, 텍스트 파일, 모바일 노트, 또는 스크래치 버퍼.

규칙은 간단합니다: 빠르게 포착하고, 나중에 처리하십시오.

단계 2: 영구적 노트(Permanent Notes)로 노트 처리

가치는 처리 과정에서 나타납니다.

거친 노트를 명확하고 재사용 가능한 노트로 전환하십시오. 자신의 말로 다시 작성하십시오. 각 노트에 아이디어를 나타내는 제목을 부여하십시오.

나쁜 제목:

Retries

더 나은 제목:

Retries are safe only when the operation is idempotent

나쁜 노트:

Need idempotency for retries.

더 나은 노트:

Retries can turn a temporary network problem into duplicate side effects.
A retry is safe only when the operation can run more than once and still
produce the same business result. For APIs, this often requires an
idempotency key, a unique constraint, or a stored request result.

단계 3: 컨텍스트가 신선할 때 링크 추가

노트를 작성한 후 다음을 물어보십시오.

이것이 무엇을 설명하는가?
이것이 무엇에 의존하는가?
코드에서 어디에서 본 적이 있는가?
반대되는 관점은 무엇인가?
어떤 시스템이 이로부터 이익을 얻는가?

미래의 당신의 사고를 돕는 링크만 추가하십시오.

단계 4: 인덱스 노트 또는 콘텐츠 맵(Maps of Content) 생성

클러스터가 성장하면 인덱스 노트를 생성합니다.

예시:

# API Reliability

## Core ideas

- [[Retries are safe only when the operation is idempotent]]
- [[Timeouts do not prove failure]]
- [[Circuit breakers reduce pressure on failing dependencies]]
- [[Rate limits protect shared resources]]

## Implementation patterns

- [[Idempotency keys turn retries into safe operations]]
- [[Outbox pattern separates persistence from delivery]]
- [[Dead letter queues preserve failed messages for inspection]]

## System examples

- [[Billing service payment retry design]]
- [[Webhook delivery failure handling]]

이는 모든 것을 폴더에 강요하지 않으면서 탐색을 제공합니다.

단계 5: 노트를 사용하여 출력물 생성

제텔카스텐은 무언가를 생성해야 합니다.

개발자에게 출력물은 다음과 같을 수 있습니다.

아키텍처 결정 기록(ADR)
디자인 문서
블로그 포스트
디버깅 가이드
온보딩 문서
풀 리퀘스트 설명
내부 발표
리팩토링 계획
장애 검토 통찰력

노트가 당신의 작업에 영향을 미치지 않는다면, 그 시스템은 너무 장식적입니다.

개발자를 위한 권장 노트 유형

순간적 노트(Fleeting Notes)

빠른 포착을 위한 임시 노트.

사용 용도:

코딩 중 아이디어
디버깅 관찰 사항
미팅 단편
질문
나중에 처리할 북마크

빠르게 삭제하거나 변환하십시오. 늪지가 되게 하지 마십시오.

문헌 노트(Literature Notes)

외부 소스에 대한 노트.

개발자에게 소스는 다음과 같을 수 있습니다.

문서
블로그 기사
RFC
소스 코드
컨퍼런스 발표
GitHub 이슈
사후 분석(Postmortem)
책 장

소스 노트를 자신의 영구적 노트와 분리하십시오. 소스 노트는 “이 소스가 이렇게 말했다"고 합니다. 영구적 노트는 “나는 이 아이디어를 이렇게 이해한다"고 합니다.

영구적 노트(Permanent Notes)

이것이 제텔카스텐의 핵심입니다.

영구적 노트는 다음과 같아야 합니다.

원자적임
자신의 말로 작성됨
관련 노트와 연결됨
원래 소스가 필요 없이 유용함
나중에 다시 볼 수 있을 만큼 안정적임

프로젝트 노트

프로젝트 노트는 허용되지만, 영구적 노트와 혼동하지 마십시오.

프로젝트 노트는 다음과 같을 수 있습니다.

Migrate billing worker to queue v2

이는 다음과 같은 영구적 노트와 연결될 수 있습니다.

Backpressure prevents queue consumers from collapsing
Outbox pattern separates persistence from delivery
Feature flags reduce deployment risk

프로젝트는 끝납니다. 개념은 남습니다.

도구 예시

옵시디안(Obsidian)

옵시디안은 로컬 마크다운 파일과 내부 링크를 지원하기 때문에 개발자 제텔카스텐에 잘 맞습니다.

간단한 옵시디안 구조:

notes/
  fleeting/
  sources/
  permanent/
  maps/
  projects/

예시 노트:

# Timeouts do not prove failure

A timeout means the client stopped waiting. It does not prove the server failed.
The operation may have succeeded, failed, or still be running.

This matters for payment APIs, job queues, and any external side effect.

Related:
- [[Retries are safe only when the operation is idempotent]]
- [[Idempotency keys turn retries into safe operations]]
- [[External side effects need reconciliation]]

파일 소유권, 평문, 그리고 에디터 같은 워크플로우를 선호한다면 옵시디안은 좋은 선택입니다.

로그시퀀스(Logseq)

개요 작성, 일일 저널, 블록 수준 참조를 선호한다면 로그시퀀스가 유용합니다.

그의 블록 모델은 작은 생각 단위를 포착하는 데 잘 맞습니다. 저널에 거친 노트를 작성한 다음 유용한 블록을 영구적 노트로 승격시킬 수 있습니다.

로그시퀀스 스타일 워크플로우 예시:

- Timeout during payment request does not prove payment failure.
  - This should become a permanent note about unknown outcomes.
  - Related: [[Idempotency]], [[Retries]], [[Payment APIs]]

생각이 개요에서 시작되고 블록 참조를 좋아한다면 로그시퀀스는 좋은 선택입니다. 워크플로우 스타일, 동기화 옵션, 플러그인 생태계 전반에 걸쳐 두 도구를 나란히 비교하려면 옵시디안 대 로그시퀀스가 트레이드오프를 명확하게 매핑합니다.

평문 마크다운과 Git

특별한 앱이 필요하지 않습니다.

마크다운 파일의 Git 저장소면 충분합니다.

knowledge/
  permanent/
  sources/
  maps/

일반적인 마크다운 링크를 사용하십시오.

[Retries are safe only when operations are idempotent](../permanent/retries-safe-only-with-idempotency.md)

이 접근법은 지루하고, 내구성이 있으며, 개발자 친화적입니다. 이는 칭찬입니다.

노트 명명법

주장을 담은 제목을 선호하십시오.

약한 제목:

Caching
Queues
OAuth
PostgreSQL indexes

강한 제목:

Cache invalidation is a coordination problem
Queues hide latency but do not remove work
OAuth access tokens should be short lived
Partial indexes are useful when queries target a subset

주장 기반 제목은 노트를 이해하기 쉽고 연결하기 쉽게 만듭니다.

개발자 제텔카스텐에 담을 내용

좋은 후보:

아키텍처 원칙
디버깅 교훈
프로덕션 장애 통찰력
API 디자인 규칙
데이터베이스 패턴
보안 가정
성능 트레이드오프
프레임워크 에지 케이스
리팩토링 휴리스틱
테스트 전략
배포 교훈
코드 리뷰 패턴

나쁜 후보:

원본 미팅 기록
처리되지 않은 북마크
거대하게 복사된 문서 페이지
설명이 없는 임의의 스니펫
작업 목록
비밀
인증 정보
공식 회사 문서에만 속하는 것

개인 제텔카스텐은 작업을 참조할 수 있지만, 사적 시스템의 불안정한 그림자 복사본이 되어서는 안 됩니다.

흔한 실수

실수 1: 너무 일찍 과다 구조화

개발자들은 구조를 좋아합니다. 이는 때때로 문제가 됩니다.

첫 주를 폴더, 태그, 템플릿, 명명 규칙, 대시보드, 자동화 설계를 보내지 마십시오. 아직 노트에 필요한 구조가 무엇인지 알지 못합니다.

소수의 노트 유형으로 시작하십시오.

fleeting
sources
permanent
maps
projects

복잡성은 그 자리를 얻도록 방임하십시오.

실수 2: 폴더처럼 취급

제텔카스텐은 더 나은 폴더 트리가 아닙니다.

모든 노트가 정확히 하나의 폴더에 속하고 의미 있는 링크가 없다면, 당신은 서류함을 구축한 것입니다. 여전히 유용할 수 있지만, 그것은 제텔카스텐이 아닙니다.

가치는 연결에서 옵니다.

API retries -> idempotency -> database constraints -> payment safety -> incident prevention

이 체인은 “Backend"이라는 폴더보다 더 유용합니다.

실수 3: 저장하는 것을 생각하는 것으로 착각

복사는 학습이 아닙니다.

문서에서 저장된 단락은 나중에 도움이 될 수 있지만, 다시 작성된 설명은 지금 도움이 됩니다. 자신의 말로 아이디어를 재진술하는 행위가 이해를 향상시킵니다.

좋은 규칙:

복사 없이 아이디어를 설명할 수 있을 때까지 영구적 노트를 생성하지 마십시오.

실수 4: 모든 것 연결

링크가 너무 많은 것은 너무 적은 것과 마찬가지로 나쁩니다.

존재한다는 이유만으로 단어를 연결하지 마십시오. 관계가 중요하기 때문에 아이디어를 연결하십시오.

유용한 링크는 미래의 당신에게 다음 질문에 답하는 데 도움이 되어야 합니다.

왜 이것이 연결되어 있는가?

실수 5: 태그와 구조 혼동

태그는 상태와 광범위한 그룹화에 유용합니다.

#todo
#source
#security
#draft

하지만 태그가 전체 시스템을 지탱해서는 안 됩니다. 태그에만 의존하면 직접 링크의 풍부한 의미를 잃게 됩니다.

링크는 말합니다.

이 아이디어는 특정 방식으로 저 아이디어와 관련됩니다.

태그는 보통 말합니다.

이는 광범위한 버킷에 속합니다.

둘 다 유용합니다. 하지만 동일하지 않습니다.

실수 6: 출력물을 생성하지 않음

출력물을 생성하지 않는 제텔카스텐은 사적 아카이브가 됩니다.

출력물이 반드시 공개적인 글쓰기를 의미하는 것은 아닙니다. 디자인 문서, 장애 검토, 더 나은 풀 리퀘스트, 또는 팀메이트에게 명확한 설명일 수 있습니다.

시스템은 당신의 사고를 재사용하기 쉽게 만들어야 합니다.

최소 템플릿

작은 템플릿을 사용하십시오. 열다섯 개의 필드가 있는 양식을 만들려는 충동을 저항하십시오.

# Title as a claim

## Idea

Explain the idea in your own words.

## Why it matters

Describe the practical impact.

## Example

Show a code, system, or debugging example.

## Tradeoffs

Mention limits, risks, or counterpoints.

## Links

- [[Related note]]
- [[Another related note]]

많은 노트에 있어서는 이조차도 너무 많습니다. 제목, 단락, 그리고 세 개의 링크면 충분할 수 있습니다.

예시: 버그에서 제텔카스텐 노트로

타임아웃 후 사용자가 두 번 청구된 버그를 수정했다고 상상해 보십시오.

약한 노트는 다음과 같을 것입니다.

Payment bug - retries caused duplicate charge.

더 강력한 노트 세트는 다음과 같을 수 있습니다.

Timeouts do not prove failure
Retries are safe only when the operation is idempotent
Idempotency keys turn retries into safe operations
Payment APIs should model unknown outcomes
Database constraints are concurrency control

이제 버그는 재사용 가능한 엔지니어링 지식이 되었습니다.

나중에 이러한 노트는 다음을 지원할 수 있습니다.

사후 분석(Postmortem)
결제 재시도를 위한 디자인 문서
멱등성에 대한 블로그 포스트
외부 API 통합을 위한 체크리스트
코드 리뷰 코멘트
더 안전한 구현

이것이 제텔카스텐의 실용적인 가치입니다.

주간 유지 관리 루틴

복잡한 검토 프로세스가 필요하지 않습니다.

일주일에 한 번:

거친 노트를 처리합니다.
더 이상 중요하지 않은 노트를 삭제합니다.
유용한 아이디어를 영구적 노트로 변환합니다.
누락된 링크를 추가합니다.
클러스터를 맵 노트로 승격시킵니다.
하나의 노트를 선택하고 출력물로 만듭니다.

가볍게 유지하십시오. 시스템은 개발을 지원해야지, 그것과 경쟁해서는 안 됩니다.

실용적인 규칙

시스템을 건강하게 유지하려면 다음 규칙을 사용하십시오.

노트 하나당 하나의 아이디어.
제목을 주장으로 작성.
폴더보다 링크를 선호.
소스 노트를 자신의 아이디어와 분리.
노트를 실제 코드와 실제 시스템과 연결.
클러스터가 존재할 때만 맵 노트 생성.
저가치 노트 삭제.
워크플로우를 이해하기 전에 자동화하지 않음.
무언가를 생성하기 위해 시스템을 사용.

제텔카스텐이 가치가 없을 때

제텔카스텐은 모든 문제에 대한 해답이 아닙니다.

다음과 같은 경우 과잉일 수 있습니다.

작업 관리자만 필요할 때.
기술적 아이디어를 거의 다시 보지 않을 때.
글쓰기, 가르침, 디자인, 문서화를 하지 않을 때.
노트가 대부분 단명하는 프로젝트 세부 사항일 때.
실제 작업을 피하기 위해 사용하고 있을 때.

이것은 이해가 복리될 때 가장 유용합니다.

여기에는 시니어 엔지니어링, 아키텍처, 기술 리더십, 복잡한 시스템 디버깅, 글쓰기, 컨설팅, 연구, 그리고 수년에 걸쳐 깊은 학습이 포함됩니다.

마무리 생각

개발자에게 제텔카스텐은 노트를 수집하는 것이 아닙니다. 사고 환경을 구축하는 것입니다.

이 방법은 실용적으로 유지될 때 가장 잘 작동합니다: 원자적 노트, 의미 있는 링크, 실제 예시, 그리고 규칙적인 출력물. 개념을 코드와 연결하십시오. 코드를 시스템과 연결하십시오. 시스템을 결정과 연결하십시오.

제텔카스텐은 아이디어 레이어를 처리합니다 — 하지만 대부분의 엔지니어는 이를 두 가지 보완적인 관행과 짝지어야 혜택을 받습니다. PARA 방법론은 조직 레이어를 추가합니다. 프로젝트, 영역, 자원, 아카이브는 활성 작업 컨텍스트를 개념 네트워크와 분리하므로 작업 중인 동안 필요한 것을 찾을 수 있습니다. 에버그린 노트(Evergreen notes)는 글쓰기 측면을 날카롭게 합니다. 각 노트를 원자적이고 독립적이며 자신의 말로 작성하는 원칙이 제텔카스텐을 성장하는 아카이브가 아닌 복리되는 이해로 전환시킵니다.

완벽한 두 번째 두뇌를 구축하려고 하지 마십시오. 유용한 것을 구축하십시오.

좋은 개발자 제텔카스텐은 더 나은 질문에 답하는 데 도움이 되어야 합니다.

Where have I seen this problem before?
What concept explains this bug?
What tradeoff are we making?
What pattern applies here?
What should I write down so I do not relearn this again?

이것이면 충분합니다.