소개

대부분의 개발자는 배운 것을 기록하고 싶어 합니다. 우리는 글을 북마크하고, 레포를 스타하고, 탭을 ‘나중에 보려고’ 열어두고, 언젠가 제대로 정리해서 글로 쓰겠다고 스스로에게 약속합니다.

그리고 현실이 시작됩니다.

스프린트는 쌓이고, 티켓은 계속 움직이고, 브라우저 탭은 기하급수적으로 늘어납니다. 애써 만들어 둔 “학습 시스템”은 너무 무겁고, 너무 번거롭고, 실제 작업 흐름과도 너무 동떨어져 있습니다. 결국 더 이상 쓰지 않게 되죠.

결과적으로 중요한 깨달음들은 잊히고, 같은 문제를 여러 번 다시 파악하게 되고, 우리의 개인 지식은 커밋, Slack 스레드, Stack Overflow 여기저기에 흩어져 버립니다.

**원페이지 러닝 레저(One-Page Learning Ledger)**는 다른 접근입니다. 실제로 일을 하면서 배운 것을 느리게 만들지 않으면서 한 곳에 가볍게 기록하는 방식입니다.

러닝 레저란 무엇인가?

**러닝 레저(learning ledger)**는 학습의 결과를 가볍게 적어두는 로그입니다.

• 무엇을 고쳤는지
• 어떤 결정을 내렸는지
• 무엇을 마침내 이해했는지
• 나중에 다시 보고 싶은 것은 무엇인지

러닝 레저는 이런 것들은 아닙니다:

• 자세한 설명으로 가득 찬 노트북
• 복잡한 태그 규칙이 있는 세컨드 브레인 시스템
• 전체 글이나 웹 페이지를 통째로 복붙해 둔 저장소

이걸 이렇게 생각해 보세요. **뇌를 위한 러닝 체인지로그(running changelog)**입니다. 단, 한 페이지나 하나의 단순한 뷰로 범위를 제한한.

각 항목은 이런 질문에 답합니다:

“방금 배운 것 중에서, 미래의 내가 신경 쓸 만한 게 뭐지?”

전형적인 항목 구조는 이렇습니다.

• 날짜
• 짧은 설명 (1–2줄)
• 선택적 링크 (PR, 문서, 글, gist 등)
• 선택적 태그 또는 카테고리

정말 이게 전부입니다. 긴 글 필요 없음. 깊게 고민할 필요도 없습니다.

왜 ‘한 페이지’가 중요한가

러닝 레저를 **한 페이지(또는 하나의 단순한 화면/뷰)**로 제한하는 것은 단순히 보기 좋아서가 아니라, 인지적인 이유가 있습니다.

1. 낮은 인지 부담

“지식 베이스”가 수십 개의 노트와 중첩된 폴더로 흩어져 있으면, 기록을 하기 전부터 생각해야 합니다.

• 이건 어디에 넣지?
• 태그는 어떻게 달지?
• 이건 새 페이지를 만들어야 하나?

이 사소한 의사결정 비용만으로도, 특히 바쁜 날에는 기록을 아예 건너뛰게 만듭니다.

원페이지 레저는 이 마찰을 없앱니다.

기억해 둘 가치가 있으면, 그냥 그 페이지에 쓴다. 끝.

2. 더 자주, 부담 없이 훑어볼 수 있음

여러 노트와 폴더를 파고들기보다, 한 페이지를 스윽 훑어보는 게 훨씬 쉽습니다. 그래서 정기적인 리뷰가 ‘해야 하는 일’이 아니라 자연스러운 루틴이 됩니다.

3. 자연스러운 제약

한 페이지라는 제약은 당신에게 다음을 강제합니다.

• 짧고 명확한 항목을 쓰게 만들고
• 중복된 내용을 합치게 만들며
• 반복적으로 등장하는 주제를 더 깊이 공부할 학습 목표로 끌어올리게 합니다.

시간이 지날수록 이 한 페이지는 끝없이 늘어나는 로그가 아니라, 잘 다듬어진 학습 지도가 됩니다.

모든 걸 다 적지 말고, ‘결과’에 집중하기

개발자 노트 테이킹의 가장 큰 함정은 다 적으려는 것입니다.

• Stack Overflow 답변을 통째로 복사하고
• config 파일 전체를 붙여넣고
• 긴 스레드 스크린샷을 몽땅 저장하는 식이죠.

이건 너무 무겁고, 오래 지속될 수 없습니다.

러닝 레저는 결과 지향적입니다. 각 항목에 대해, 미래의 내가 다음을 할 수 있을 만큼만 적습니다.

1. 당시 상황을 떠올릴 수 있고
2. 해결책을 빠르게 다시 구성하거나 재발견할 수 있도록

예시 항목들

이렇게 쓰는 대신에:

“Postgres 트랜잭션 격리 수준에서 READ COMMITTED와 REPEATABLE READ가 어떻게 동작하는지에 대한 500자짜리 설명…”

이렇게 기록합니다:

2025-01-10 – Postgres 기본 격리 수준(READ COMMITTED)에서도 같은 트랜잭션 안에서 새로 커밋된 row를 볼 수 있다는 걸 배움. 동시성 상황에서 일관된 스냅샷을 원하면 REPEATABLE READ를 써야 함.
참고: 내부 문서 + Postgres docs

또는, 200줄짜리 webpack config를 그대로 붙여넣는 대신:

2025-01-14 – 프로덕션 빌드 사이즈가 커지는 문제를, webpack 트리 셰이킹 활성화로 해결. package.json에 sideEffects: false 추가.
링크: PR #248

패턴은 이렇습니다. 결정과 핵심 인사이트, 그리고 다시 찾아볼 곳만 적지, 전체 지식을 통째로 복사하지 않습니다.

원페이지 러닝 레저의 모양

이건 거의 어떤 도구로도 구현할 수 있습니다. 중요한 건 도구가 아니라 구조입니다.

아래는 간단한 Markdown 예시입니다.

# Learning Ledger (2025)

- **2025-01-02** – `git worktree`가 여러 브랜치를 별도 클론 없이 작업하기에 좋다는 걸 발견.  
  Ref: `git worktree add ../feature-x feature-x`

- **2025-01-05** – 시계 모킹 + `setTimeout` 조합 때문에 flaky한 Cypress 테스트 발생. `cy.clock()`을 일관되게 쓰고, 네이티브 타이머와 섞지 말 것.  
  Ref: 프로젝트 문서: `docs/testing/flaky-cypress.md`

- **2025-01-09** – 성능 이슈의 원인이 ORM의 N+1 쿼리였음. eager loading(`include` 옵션)으로 해결.  
  Tech: Node, Sequelize  
  Tags: `performance`, `db`

테이블 뷰(Notion, Obsidian, 스프레드시트 등)를 선호한다면 이런 식으로 쓸 수 있습니다.

실제 컬럼 구성은 자유지만, 최소한으로 유지하는 게 좋습니다.

어떻게 ‘저마찰(low-friction)’을 유지할 것인가

러닝 레저를 업데이트하는 데 30초 이상 걸리면, 바쁠 때는 사용하지 않게 됩니다. 처음부터 속도를 기준으로 설계하세요.

1. 항목은 아주 작게

• 한두 문장
• 선택적 링크 1개
• 선택적 태그 2–3개 이내

길게 쓰고 싶다면, 별도 문서나 블로그 글로 쓰고, 러닝 레저에서는 그 문서를 링크만 거세요.

2. 이미 쓰는 도구에 통합하기

러닝 레저 업데이트가 기존 워크플로의 작은 한 부분처럼 느껴지도록 만드세요.

• 에디터: VS Code / Neovim에서 learning-ledger.md를 스플릿 창에 항상 열어두기. 새 항목 템플릿을 불러오는 스니펫이나 단축키 만들기 (예: llog를 입력하면 오늘 날짜 템플릿으로 확장).
• 터미널: ll 같은 alias를 만들어 nano/vim으로 레저를 열거나, 간단한 스크립트로 항목을 append.
• 노트 앱: Apple Notes, Obsidian, Notion, Logseq 등에서 레저 노트를 상단에 고정(pinned) 시켜두기.
• 버전 관리: 특정 결정과 관련된 PR 설명에 레저 링크를 넣고, 반대로 레저 항목에도 PR 링크 넣기.

3. ‘자연스러운 체크포인트’에서 기록하기

모든 걸 다 적을 필요는 없습니다. 이런 순간을 노리세요.

• 버그나 티켓을 닫는데, 새로운 걸 배웠을 때
• 그동안 헷갈리던 개념을 마침내 이해했을 때
• 나중에 질문받을 법한 비자명한 결정을 했을 때
• 나중에 다시 겪을 것 같은 패턴을 발견했을 때

이 기준을 사용해 보세요.

“3개월 뒤에 이걸 다시 처음부터 파고들어야 한다면 짜증 날까?”

그렇다면, 기록할 가치가 있는 것입니다.

러닝 레저를 개인 지식 베이스로 발전시키기

처음엔 레저가 단순히 항목이 쌓이는 스트림처럼 보일 겁니다. 하지만 시간이 지나면 패턴이 드러납니다.

• DB 성능 이슈가 반복된다든지
• Kubernetes 네트워킹에서 계속 헷갈린다든지
• 프론트엔드 상태 관리에서 늘 꼼수를 쓰고 있다든지

이 지점부터 레저는 정말 강력해집니다.

1. 주기적으로 리뷰하기

1~2주에 한 번씩, 페이지 전체를 훑어보세요. (딱 한 페이지니까 이것이 핵심입니다.)

• 명백히 겹치는 항목은 합치고
• 미래의 내가 이해하기 쉽도록 문장을 살짝 다듬고
• 태그를 추가하거나 정리하고
• 더 깊이 공부할 주제로 승격할 만한 항목을 표시합니다.

2. 반복되는 주제를 학습 목표로 승격하기

관련된 항목들이 모여 있는 걸 발견하면, 그걸 신호로 받아들이세요.

“ORM이랑 계속 싸우고 있네. 조인, 트랜잭션, 마이그레이션을 어떻게 처리하는지 하루 정도 투자해서 정리해야겠다.”

이런 식으로 별도의 문서나 미니 로드맵을 만듭니다.

• 목표: 사용하는 ORM이 복잡한 조인에 대해 어떤 SQL을 생성하는지 이해하기
• 출처: 관련 러닝 레저 항목들 링크
• 계획: 공식 문서, 튜토리얼, 내부 코드 등 읽을 거리 링크

이제 레저는 단순 기록이 아니라, 다음에 무엇을 배워야 할지 알려주는 피드백 루프가 됩니다.

3. 검색과 훑어보기

레저는 작고 구조화되어 있어서, 다음이 쉽습니다.

• Ctrl+F로 “CORS”, “N+1”, “timeout” 같은 키워드를 검색하고
• 날짜 흐름대로 훑어보며 특정 프로젝트 동안 무엇을 배웠는지 복기하고
• 팀원과 공유할 만한 내용만 골라서 발췌해 전달하기

한 페이지짜리 레저는 충분히 작아서 전체를 볼 수 있고, 충분히 커서 실제로 유용합니다.

예시 워크플로: 이론에서 실전으로

몇 가지 구체적인 워크플로 예시를 들어 보겠습니다.

에디터 중심 개발자

• learning-ledger.md를 메인 레포나 개인 노트 레포에 둡니다.

• VS Code 사이드 패널에 항상 열어둡니다.

• 이런 스니펫을 사용합니다.

  "Learning ledger entry": {
    "prefix": "llog",
    "body": [
      "- **$CURRENT_YEAR-$CURRENT_MONTH-$CURRENT_DATE** – $1  ",
      "  Ref: $2  ",
      "  Tags: $3"
    ]
  }

• 중요한 인사이트를 남기고 작업을 마칠 때마다 llog를 입력하고, 필요한 부분만 채우고 넘어갑니다.

터미널 중심 개발자

• 레저를 ~/notes/learning-ledger.md에 둡니다.

• alias를 하나 추가합니다.

  alias ll='nano ~/notes/learning-ledger.md'

• 의미 있는 걸 해결했을 때:

  1. ll 실행
  2. 오늘 날짜와 1–2줄짜리 설명을 bullet로 추가
  3. 저장 후 종료

총 소요 시간: 약 20초.

마무리

대부분의 “지식 시스템”이 실패하는 이유는 너무 야심차기 때문입니다. 너무 많은 구조, 너무 많은 시간, 너무 많은 의지가 필요하죠.

원페이지 러닝 레저는 의도적으로 소박합니다.

• 딱 한 페이지
• 짧은 항목
• 결과 중심
• 이미 쓰는 도구에 자연스럽게 녹아들기

완벽한 세컨드 브레인을 만들려는 게 아닙니다. 단지, 두 번 다시 처음부터 파고들고 싶지 않은 것들을 가볍게 기록해 두는 것뿐입니다.

한 페이지를 만들고, 눈에 잘 보이는 곳에 두고, 하루에 30초만 투자해 업데이트하면, 꽤 드문 것을 얻게 됩니다. 바로, 개발자로서의 성장 히스토리가 검색 가능하고 개인화된 형태로 쌓인 기록입니다.

오늘 바로 시작하세요. learning-ledger.md(또는 당신이 선호하는 도구에서 그에 해당하는 것)를 하나 만들고, 오늘 배운 것 중 가장 유용했던 한 가지를 적어 보세요. 그리고 그 페이지가 당신과 함께 자라도록 두면 됩니다.