소개

복잡한 레이스 컨디션(race condition)을 디버깅하거나, 미묘한 API를 설계하던 중입니다. 그러다 마침내 퍼즐이 딱 맞아떨어집니다. 모든 걸 말끔히 정리해 주는 그 엣지 케이스, 불변 조건(invariant), 데이터 플로우가 떠오른 거죠. 스스로에게 말합니다. “이거, 지금 이거만 끝내고 바로 구현해야지.”

20분 뒤, 그 생각은 사라져 있습니다.

완전히 사라진 건 아니고… 흐릿해졌습니다. 좋은 아이디어였다는 건 기억하지만, 정확한 논리가 생각이 나지 않습니다. 그때는 명백히 맞다고 느껴졌던 세부 사항들이 이제는 막연한 감각으로만 남아 있죠. 결국 선택지는 둘 중 하나입니다.

• 다시 처음부터 생각을 재구성한다 (더 느리고, 처음만큼 좋지 않을 수 있음), 혹은
• 별것 아닐 거라 생각하고 그냥 넘어간다.

이건 일종의 워크플로우 차원의 기술 부채입니다. 머릿속에서 너무 많은 것을 동시에 굴리다 보니, 까다로운 아이디어들을 놓쳐버리는 거죠.

세 번 상기 규칙(The Three-Reminder Rule) 은 이런 상황을 막기 위한 아주 단순한 방법입니다. 새로운 생산성 종교가 아닙니다. 코드를 쓰기 전에, 까다로운 코딩 생각들 자체를 하나의 아티팩트(artifact) 로 다루게 해주는, 가볍고 도구 친화적인 접근법입니다.

핵심 아이디어: 세 번 상기 규칙

세 번 상기 규칙은 작지만 효과가 큰 시스템입니다.

까다롭거나 미묘한 코딩 아이디어는, ‘안전하다’고 볼 수 있을 때까지 최소 세 군데에 존재해야 한다.

그 세 군데는 다음과 같습니다.

1. 당신의 머릿속 – 지금 막 추론 중인, 활성화된 아이디어
2. 빠른 캡처(fast capture) – 메시지, 스크래치 노트, 카드 등으로 남기는, 나중에 아이디어를 재구성할 수 있을 정도의 메모
3. 지식 시스템(knowledge system) – 태그와 링크가 걸려 있어, 나중에 다시 찾아볼 수 있는 정리된 노트

거창한 지식 관리 시스템이 필요하지는 않습니다. 필요한 건 딱 두 가지뿐입니다.

• 하나는 빠른 캡처용 공간 (채팅, 스크래치 패드, 메모 파일 등)
• 하나는 외부 기억장치 역할을 하는 공간 (태그와 링크가 있는 간단한 카드 파일 또는 노트 시스템)

목표는 멋진 문서를 쓰는 게 아닙니다. 목표는:

• 생각하기(thinking) 와 적기(writing) 를 분리하고,
• 좋은 아이디어가 구현·정제·재사용되기 전에 사라지지 않게 만드는 것입니다.

왜 좋은 아이디어를 자꾸 잃어버릴까 (그리고 속도가 답이 아닌 이유)

대부분의 개발자는 이 문제를 이렇게 해결하려 합니다. “더 빨리 코딩하기”로요.

• “올바른 API가 떠오르면, 그냥 바로 구현해 버리면 되지.”

하지만 여기엔 두 가지 큰 문제가 있습니다.

1. 빠르게 구현하는 건, 구현하려는 게 진짜 ‘맞는 것’일 때만 의미가 있다. 아직 이해가 완전히 굳지 않은 상태에서 서둘러 코드를 짜는 건, 말 그대로 워크플로우 수준의 성급한 최적화(premature optimization) 입니다. 정확성이 안정되기도 전에 처리량(throughput)부터 최적화하려는 셈이죠.
2. 뇌는 형편없는 스크래치 패드다. 코딩하고, 디버깅하고, 컨텍스트 스위칭 하고, 로그 읽고, 팀과 소통하다 보면, 작업 기억(working memory)은 금방 포화 상태가 됩니다. 이때 가장 먼저 머리에서 튕겨져 나가는 건, 미묘한 논리 제약과 통찰입니다.

세 번 상기 규칙은, 생각과 구현을 동시에 하려는 시도를 멈추게 합니다. 대신 워크플로우를 이렇게 쪼개죠.

• 먼저, 아이디어를 생각하고(capture-worthy하게) 캡처한다.
• 그리고 아이디어가 어느 정도 안정되면, 그때 구현한다.

이 분리가 있어야, 까다로운 아이디어가 오래 살아남습니다.

1단계: 기계적인 일은 도구에 맡겨라

우리가 느끼는 조용한 정신적 부담 중 하나는, “적어두는 일”이 너무 비싸게 느껴진다는 겁니다. 머릿속에선 이런 생각이 들죠.

• “지금 길게 설명 쓸 시간은 없는데…”
• “이걸 기록하려면 깔끔하고, 문서화해서, 남이 봐도 볼 만하게 만들어야지.”

이 기대부터 버려야 합니다. 요즘 도구들은 이런 기계적인 부분을 충분히 대신해 줍니다.

• AI 어시스턴트는 대충 적어놓은 불릿 포인트를 문서나 주석으로 깔끔하게 정리해 줄 수 있습니다.
• 포매터(formatter)와 린터(linter) 는, 신경 쓰지 않아도 코드 스타일을 맞춰 줍니다.
• 스니펫 도구와 템플릿은 반복적인 패턴을 쉽게 뼈대만 뽑아 쓸 수 있게 해 줍니다.

당장 당신이 해야 할 일은, 아이디어의 논리 구조(logical structure) 에 집중하는 것입니다.

• 이게 어떤 문제를 푸는가?
• 어떤 불변 조건(invariant) 이 반드시 지켜져야 하는가?
• 어떤 엣지 케이스나 실패 모드가 있는가?
• 이게 시스템의 다른 부분에 어떻게 영향을 미치는가?

당신(혹은 미래의 당신, 혹은 팀원)이 나중에 이 논리를 다시 복원할 수 있을 만큼만 적으면 됩니다. 다듬지 마세요. 과하게 설명하지 마세요. 논리만 캡처하고, 다듬는 일은 도구에게 넘기세요.

2단계: 개발자 친화적인 메시징 도구로 빠르게 캡처하기

첫 번째 외부 상기는 마찰이 거의 없어야 합니다. 번거롭다면, 디버깅 도중엔 절대 쓰지 않게 됩니다.

좋은 선택지는 예를 들면 다음과 같습니다.

• #scratch-ideas 같은 전용 Slack/Discord 채널
• 팀 채팅에서 나 자신에게 보내는 개인 DM 스레드
• 로컬 scratch.md 또는 ideas.md 파일
• 단축키로 바로 열 수 있는 Obsidian/Notion 메모

핵심 요구사항은 간단합니다. 코드 포매팅이 잘 되고, 빠르게 접근할 수 있어야 합니다.

빠른 캡처는 대략 이런 식이 될 수 있습니다.

[IDEA] multi-tenant cache invalidation
- Problem: per-tenant cache entries overlap; invalidation is currently global.
- Insight: key-space can be (tenant_id, resource_id) + version token
- Invariant: tenant A’s invalidation never touches B’s keys
- Edge case: tenant deletion -> must sweep all keys w/ their tenant_id
- Question: how does this interact with background warm-up jobs?

TODO: try modeling this as a “cache policy object” injected per tenant.

이건 스펙이 아닙니다. 최종 문서는 더더욱 아닙니다. 이것은 생각의 아티팩트(thinking artifact) 입니다.

• 나중에 아이디어를 다시 복원할 수 있을 만큼의 컨텍스트
• 검색했을 때 다시 찾을 수 있을 만큼의 구조
• 내일 다시 봤을 때, 더 좋은 질문을 던질 수 있을 만큼의 디테일

이게 두 번째 상기입니다.

3단계: 가벼운 카드 파일(card-file)로 외부 기억을 만든다

빠른 캡처는 훌륭하지만, 채팅 로그나 스크래치 파일은 시간이 지나면 연대기 순으로 쌓인 잡동사니 가 됩니다. 좋은 아이디어는 금방 타임라인 속으로 사라지죠.

그래서 세 번째 상기가 필요합니다. 바로 카드 파일(card-file) 또는 노트 시스템입니다.

구현 방법은 다양합니다.

• 폴더 안의 평범한 텍스트/마크다운 파일들
• Obsidian, Logseq, Notion 같은 노트 앱
• 아날로그를 좋아한다면, 실제 종이 인덱스 카드

각 "카드"(또는 노트)는 작고 집중되어 있어야 합니다.

• 카드당 아이디어/패턴/버그/엣지 케이스 한 개
• 짧은 제목
• 태그와/또는 ID 번호
• 관련 카드에 대한 링크나 참조

예시(마크다운 카드):

# multi-tenant-cache-invalidation

**Type:** pattern
**Tags:** caching, multi-tenant, invariants

## Problem
Global cache invalidation is too coarse for multi-tenant systems. One tenant’s updates shouldn’t evict another tenant’s cache entries.

## Idea
- Cache key: (tenant_id, resource_id, version_token)
- Per-tenant invalidation by bumping tenant-specific token or namespace
- Invariant: invalidation scope must be tenant-bounded.

## Notes
- Related: [cache-invalidation-strategies](2024-03-02-cache-strat)
- Check how this interacts with background warmers.

이게 바로 당신의 외부 기억(external memory) 입니다. 여기엔 세부 사항을 모두 외울 필요가 없습니다. 이 아이디어가 존재한다는 사실 만 기억하고 있으면, 필요할 때 언제든 다시 꺼내 볼 수 있습니다.

4단계: 태그와 교차 참조로 아이디어를 다시 떠오르게 만들기

흩어진 상기 장치들만으로도 어느 정도는 도움이 됩니다. 하지만 일관된 지식 시스템 이 되면 훨씬 강력해집니다.

요령은 단순합니다. 카드를 추가하거나 수정할 때마다, 최소한 다음 둘 중 하나는 꼭 추가하는 겁니다.

• 태그(tag) (예: #caching, #concurrency, #testing, #migration)
• 교차 링크(cross-link) – 관련된 다른 카드로 연결

시간이 지나면 태그 인덱스(또는 태그 검색)는 당신의 생각 지도를 만들어 줍니다.

• #caching 을 들여다보면, 예전 버그, 패턴, 설계 노트가 한 번에 떠오릅니다.
• 새로운 동시성 문제를 마주하면, #race-condition 태그가 붙은 노트를 전부 살펴보게 됩니다.

결국 당신만의, 계속 진화하는 개발자 위키 를 갖게 되는 셈입니다. 특히 가장 힘들게 얻어낸 통찰들에 초점이 맞춰진 위키 말이죠.

여기서 세 번 상기 규칙의 진짜 효과가 드러납니다.

1. 아이디어는, 처음 발견했을 때 당신 머릿속 에 존재합니다.
2. 아이디어는, 세션 도중 잊어버리지 않도록 즉각 캡처(채팅/스크래치) 되어 있습니다.
3. 아이디어는, 몇 주 혹은 몇 달 후에도 다시 찾을 수 있는 내구성 있는 카드 로 존재합니다.

종합하기: 현실적인 워크플로우 예시

세 번 상기 규칙을 일상 속에서 활용하는 현실적인 방법을 정리하면 대략 이렇습니다.

1. 까다로운 문제를 생각하는 동안

   • 개발 환경 안에 머무릅니다.
   • 핵심 아이디어가 떠오르면, 바로 캡처 도구에 대충이라도 메모를 남깁니다.

2. 세션이 끝난 뒤(혹은 잠깐 멈췄을 때)

   • 스크래치 메시지를 한 번 훑어봅니다.
   • 중요한 것들을 골라, 각각을 별도의 카드/노트로 승격시킵니다.
   • 태그를 달고, 관련 카드에 링크를 추가합니다.

3. 나중에 관련 작업을 시작할 때

   • 태그/주제로 노트를 검색합니다.
   • 처음부터 다시 생각하는 대신, 예전에 했던 추론을 재활용합니다.

4. 구현 단계에서

   • 코드를 작성하면서, 해당 카드를 옆에 두고 참고합니다.
   • 필요하다면, AI·템플릿·문서 생성 도구를 활용해, 카드에 담긴 논리를 깔끔한 주석이나 문서로 변환합니다.

이 과정이 차지하는 오버헤드는 하루에 몇 분 정도에 불과합니다. 하지만 시간이 갈수록 이득이 눈덩이처럼 불어납니다. 같은 통찰을 반복해서 재발명하는 데 쓰는 시간이 줄어들고, 논리적인 회귀(regression)도 훨씬 덜 발생합니다.

결론: 아이디어를 일급 시민으로 대하라

대부분의 개발자는 생산성을, 머지된 코드 라인 수나 닫은 티켓 개수로 측정합니다. 하지만 특히 난이도 높은 시스템 작업에서는, 진짜 레버는 아이디어의 품질과 생존력 입니다.

세 번 상기 규칙은 그런 아이디어를 일급 시민(first-class) 으로 취급합니다.

• 뇌 하나만을 유일한 저장소로 믿지 않습니다.
• 생각하기 와 구현하기 를 분리해서, 워크플로우 수준의 성급한 최적화를 피합니다.
• 포매팅과 폴리싱은 도구에게 맡기고, 자신은 논리에만 집중합니다.
• 메시징 도구와 카드 파일 시스템을 활용해, 가벼운 외부 기억 을 구축하고, 어렵게 얻은 통찰을 계속 살려 둡니다.

복잡한 PKM(개인 지식 관리) 세트업이나, 완벽하게 정제된 사내 위키가 꼭 필요하진 않습니다. 필요한 건 아주 단순한 규칙 하나뿐입니다.

“잃어버리면 아플 정도로 까다로운 아이디어라면, 최소 세 번은 상기될 수 있게 만들어라.”

이 규칙을 받아들이면, 더 날카로운 아이디어를 재사용하고, 더 안전한 코드를 작성하며, 이런 생각을 할 시간이 훨씬 줄어들 겁니다.

“이거, 예전에 한 번 해결하지 않았던가…?”