개발자를 위한 젠텀카스텐: 실제로 작동하는 실용적인 방법

개발자들은 보통 정보 부족으로 고통받지 않습니다. 오히려 정보가 너무 많다는 점 때문에 고통받죠.

API 문서, 풀 리퀘스트(pull requests), 프로덕션 장애 기록, 디자인 논의 내용, 회의록, 아키텍처 다이어그램, 코드 주석, 슬랙(Slack) 스레드, 연구 논문, 실험 기록, 북마크, 그리고 미완된 아이디어들이 서로 다른 다섯 가지 도구 안에 흩어져 있습니다. 여기서 어려운 부분은 정보를 저장하는 것이 아닙니다. 정보를 재사용 가능한 사고로 전환하는 것이 어렵습니다.

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

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

여기에는 의견이 섞여 있습니다. 대부분의 개발자들은 제텔카스텐을 낭만적인 생산성 취미로 삼지 말아야 합니다. 아름다운 노트 박물관을 짓지 마십시오. 문제를 해결하고, 시스템을 설명하며, 더 나은 엔지니어링 결정을 내리는 데 도움이 되는 작동하는 시스템을 구축하십시오.

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

제텔카스텐은 독일어로 “지폐 상자(slip box)“를 의미합니다. 이 방법은 사회학자 닐스 루만(Niklas Luhmann)과 관련이 깊으며, 그는 연결된 방대한 노트 컬렉션을 사용하여 아이디어를 발전시키고 광범위하게 글을 썼습니다.

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

개발자들에게 현대적인 버전은 간단합니다:

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

이것이 전부입니다. 나머지는 구현 세부 사항일 뿐입니다.

개발자들이 지식 과부하에 직면하는 이유

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

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

그런 다음 두 달 뒤, 당신은 그 해답을 한때 알았다고 막연하게 기억합니다.

일반적인 개발자 지식 스택은 이 문제를 악화시킵니다:

• 북마크는 이해가 아닌 소스를 저장합니다.
• 폴더는 조기 분류를 강요합니다.
• 위키(Wiki)는 소유자가 없으면 금방陳舊해집니다.
• 할 일 목록은 작업과 아이디어를 혼합합니다.
• 코드 주석은 광범위한 개념이 아닌 로컬 세부 사항을 설명합니다.
• 채팅 메시지는 기록 속으로 사라집니다.

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

제텔카스텐의 핵심 원칙

원자적 노트(Atomic Notes)

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

하나의 주제나, 하나의 기사 요약, 혹은 “PostgreSQL"이라고 명명된 방대한 페이지가 아닙니다. 하나의 아이디어입니다.

예를 들어, 다음 항목들은 너무 광범위합니다:

PostgreSQL notes
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

원자적 노트는 연결하기 쉬우므로 강력합니다. 방대한 페이지는 모호한 주제로만 연결될 수 있습니다. 반면 초점이 맞는 노트는 정확한 개념, 결정, 버그, 또는 시스템과 연결될 수 있습니다.

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

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

연결(Linking)

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

아름다운 그래프를 만드는 것이 목적이 아닙니다. 아이디어를 재사용 가능하게 만드는 것이 목적입니다.

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

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

• “이는 다른 각도에서 동일한 개념을 설명한다.”
• “이는 아이디어의 실용적인 예이다.”
• “이는 트레이드오프 또는 반론이다.”
• “이 개념은 저 개념에 의존한다.”
• “이 노트는 더 큰 논증의 일부이다.”

게으른 링크를 피하십시오. 모든 노트를 다른 모든 노트와 연결하면 노이즈만 생성됩니다. 가장 좋은 링크는 의도적인 것입니다.

생성(Emergence)

생성은 제텔카스텐에서 신비하게 들리지만 실용적인 부분입니다.

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

몇 달 후, 다음과 같은 주제들을 중심으로 많은 노트가 연결되어 있음을 발견할 수 있습니다:

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

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

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

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

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

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

1. 개념
2. 코드
3. 시스템

개념

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

예시:

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: 영구 노트로 노트 처리

가치가 나타나는 곳은 처리 단계입니다.

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

나쁜 제목:

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: 색인 노트 또는 콘텐츠 맵 생성

클러스터가 성장하면 색인 노트를 생성하십시오.

예를 들어:

# 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: 노트를 사용하여 출력 생성

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

개발자에게 출력은 다음이 될 수 있습니다:

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

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

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

일시적 노트(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

Obsidian은 로컬 Markdown 파일并使用하고 내부 링크를 지원하기 때문에 개발자 제텔카스텐에 잘 맞습니다.

간단한 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]]

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

Logseq

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

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

Logseq 스타일 워크플로우 예시:

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

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

평문 Markdown 및 Git

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

Markdown 파일의 Git 저장소만으로도 충분할 수 있습니다:

knowledge/
  permanent/
  sources/
  maps/

일반 Markdown 링크를 사용하십시오:

[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: 모든 것 연결

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

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

유용한 링크는 미래의 당신이 다음 질문에 답하도록 도와야 합니다:

Why is this connected?

실수 5: 태그와 구조 혼동

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

#todo
#source
#security
#draft

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

링크는 말합니다:

This idea relates to that idea in a specific way.

태그는 일반적으로 말합니다:

This belongs to a broad bucket.

둘 다 유용합니다. 그러나 동일하지 않습니다.

실수 6: 출력 생성 안 함

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

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

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

최소 템플릿

작은 템플릿을 사용하십시오. 15개의 필드가 있는 양식을 생성하려는 충동을 저항하십시오.

# 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

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

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

• 사후 분석
• 결제 재시도용 디자인 문서
• 멱등성에 대한 블로그 게시물
• 외부 API 통합용 체크리스트
• 코드 리뷰 코멘트
• 더 안전한 구현

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

주간 유지 관리 루틴

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

일주일에 한 번:

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

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

실용적인 규칙

시스템을 건강하게 유지하기 위해 다음 규칙을 사용하십시오:

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

제텔카스텐이不值得인 경우

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

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

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

복리되는 이해(compounding understanding)에 작업이 의존할 때 가장 유용합니다.

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

마무리 생각

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

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

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

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

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?

이것이면 충분합니다.