[아키텍처] 개발자를 위한 옵시디언 지식관리 구조, DKA 아키텍처

옵시디언을 쓰다 보면 처음에는 메모를 잘 쌓는 것만으로도 만족스럽다.
하지만 개발 공부, 프로젝트 설계, 기능 명세, 아키텍처 결정, 트러블슈팅 기록이 쌓이기 시작하면 금방 문제가 생긴다.

“이 문서는 어디에 넣어야 하지?”

 

예를 들어 로그인 보안에 대해 정리한다고 해보자.

• 특정 프로젝트 폴더에 넣어야 할까?
• 백엔드 공부 노트에 넣어야 할까?
• Spring Security 참고자료에 넣어야 할까?
• 아니면 아키텍처 문서로 분리해야 할까?

처음에는 아무 데나 넣어도 괜찮다. 하지만 프로젝트가 늘어나면 같은 고민을 반복하게 된다.

 

여러 서비스를 직접 기획하고 개발하면서 옵시디언을 단순한 메모장이 아니라 개발자용 개인 아키텍처 위키처럼 쓰고 싶었다.

그래서 PARA를 그대로 쓰기보다, 개발자에게 맞춘 구조를 따로 정리해보았다.

그 구조를 DKA, Developer Knowledge Architecture라고 이름 붙였다.

DKA는 완전히 새로운 발명이 아니다. PARA를 개발자용으로 변형한 구조에 가깝다. PARA의 뼈대 위에 개발자에게 꼭 필요한 Systems(재사용 기술 도메인)레이어와 Decisions(ADR)레이어를 더하고, 옵시디언의 강점인 링크·태그·MOC를 분류의 한 축으로 끌어들인 것이 핵심이다. 이름을 붙인 이유는 독창성을 주장하려는 게 아니라, 매번 같은 구조를 설명·재사용하기 쉽게 부르기 위해서다.

 

 

 

---

왜 PARA가 조금 아쉬웠나

PARA는 유명한 지식관리 구조다.

• Projects
• Areas
• Resources
• Archive

이 네 가지로 정보를 분류한다.

일상, 업무, 개인 목표, 관심사까지 폭넓게 관리하기에는 좋은 구조다.

하지만 최근 옵시디언으로 다양한 메모를 PARA로 관리하다 보니, 개발자 관점에서는 약간 애매한 부분이 있다고 느꼈다.

 

예를 들어, 푸시 알림 설계라는 문서가 있다고 해보자. 이 문서는 어디에 들어가야 할까?

• Projects/side-project?
• Areas/Backend?
• Resources/FCM?

푸시 알림은 특정 프로젝트에서 시작됐을 수 있다. 하지만 다른 프로젝트에서도 재사용될 가능성이 높다.

뿐만 아니라 로그인, OAuth, Refresh Token Rotation, 파일 업로드, 알림, 결제, 관리자 기능, 공통 에러 처리 같은 것들도 마찬가지다.

 

이런 문서들은 특정 프로젝트에만 묶어두면 나중에 다시 찾기 어렵고, 프로젝트마다 비슷한 문서를 반복해서 만들게 된다.

그래서 개발자에게는 프로젝트 단위와 시스템 단위를 분리하는 구조가 필요하다고 생각했다. 이것이 DKA의 출발점이자 가장 큰 기여다.

 

DKA란?

DKA는 Developer Knowledge Architecture의 약자다.

개발자가 여러 프로젝트를 진행하면서 생기는 문서들을 체계적으로 관리하기 위한 개인 지식관리 구조다.

 

DKA의 핵심은 간단하다.

프로젝트는 제품 단위로 관리하고,
시스템은 재사용 가능한 기술 도메인 단위로 관리하며,
중요한 의사결정은 따로 기록한다.
그리고 흩어지는 것은 폴더가 아니라 링크와 MOC로 다시 모은다.

 

 

즉, 단순히 메모를 모으는 구조가 아니라 내가 만든 서비스, 내가 설계한 시스템, 내가 내린 기술적 결정을 계속 쌓아가는 구조다.

 

먼저 짚고 갈 것) 폴더만으로는 "어디 넣지?"가 안 풀린다

DKA를 실제로 쓰다 보면 이런 반론에 부딪힌다.

 

"결국 로그인 보안 하나도 Systems/Auth, Decisions/ADR, Patterns, References, Learning 여러 곳에 흩어지는 거 아닌가? PARA에서 비판했던 그 분산이 그대로 재현되는 것 아닌가?"

 

맞는 지적이다. 그리고 이걸 정직하게 풀고 넘어가야 DKA가 완성된다.

 

1) 그건 "한 문서의 분산"이 아니라 "용도가 다른 문서의 분리"다

로그인 보안과 관련된 문서들을 다시 보자.

• Systems/Auth/Login Flow — 설계: 우리 서비스의 로그인 흐름이 어떻게 동작하는지
• Decisions/ADR-0001-refresh-token-rotation — 결정: 왜 Rotation을 택했는지, 대안은 무엇이었는지
• Patterns/Error Handling — 반복 구현 규칙: 인증 실패를 어떻게 응답할지
• References/Spring Security — 외부 자료: 공식 문서 요약
• Learning/Spring/Spring Security 구조 — 학습 노트: 내부 동작 공부 기록

이건 같은 문서가 다섯 조각으로 쪼개진 게 아니다. 목적이 다른 다섯 개의 문서다. 설계, 결정, 구현 규칙, 외부 참고, 학습 기록은 원래 분리되는 게 맞다. 한 파일에 다 욱여넣으면 오히려 그게 더 안 좋은 문서다.

 

2) 진짜 문제는 "흩어짐"이 아니라 "탐색성"이다. 그래서 MOC를 쓴다

그렇다면 남는 진짜 문제는 하나다. "로그인 관련 문서가 다섯 폴더에 흩어져 있으면, 한눈에 보기 어렵다." 이건 폴더로 풀 문제가 아니다. 폴더는 문서를 단 하나의 위치에만 둘 수 있기 때문이다.

"한 주제가 여러 곳에 속한다"는 건 본질적으로 그래프(링크·태그) 문제이지 트리(폴더) 문제가 아니다. 그리고 옵시디언의 진짜 강점이 바로 백링크·태그·MOC다. DKA는 이 강점을 적극적으로 쓴다.

 

원칙은 이렇게 정리된다. -> 분류 축은 폴더로, 연결 축은 링크·태그로, 모아보기는 MOC로.

 

DKA 폴더 구조

내가 정리한 DKA의 기본 구조는 다음과 같다.

폴더는 "이 문서가 본질적으로 어떤 종류인가"를 기준으로 딱 한 곳에만 둔다. 중복 배치는 하지 않는다.

00_Inbox
01_Projects
02_Systems
03_Decisions
04_Patterns
05_References
06_Learning
07_Templates
08_MOC
99_Archive

 

처음부터 모든 폴더를 완벽하게 사용할 필요는 없다. 중요한 것은 각 폴더가 맡는 역할을 명확히 구분하는 것이다.

 

00_Inbox

아직 정리되지 않은 임시 메모를 넣는 곳이다.

갑자기 떠오른 아이디어, 회의 중 적은 메모, 에러 로그, 나중에 정리할 링크처럼 아직 어디에 넣어야 할지 애매한 것들을 일단 보관한다.

00_Inbox/
  푸시 알림 재시도 방식 아이디어.md
  로그인 에러 임시 정리.md
  마케팅 링크 추적 아이디어.md

 

Inbox의 목적은 완벽한 정리가 아닌 일단 기록하고, 나중에 적절한 위치로 이동시키는 것이다.

아직 정리 안 됐으면 Inbox. 정리되면 Projects, Systems, Decisions 등으로 이동한다.

 

01_Projects

실제로 만들고 있는 서비스, 앱, 레포 단위의 문서를 관리하는 곳이다.

서비스 개요, MVP 범위, 기능 명세, 화면 구조, API 목록, ERD 인덱스, 로드맵처럼 특정 프로젝트에 종속된 문서들이 들어간다.

01_Projects/
  project1/
    00_Overview.md
    01_MVP Scope.md
    02_Feature Spec.md
    03_Screen Flow.md
    04_API Index.md
    05_ERD Index.md
    06_Roadmap.md

  project2/
    00_Overview.md
    01_Feature Spec.md
    02_Log.md
    03_Marketing.md

  project3/
    00_Overview.md
    01_ERD.md

 

특정 서비스 이름이 붙는 문서는 Projects에 둔다.

 

02_Systems

DKA에서 가장 중요한 폴더다. 특정 프로젝트 하나에만 종속되지 않고, 여러 프로젝트에서 재사용될 수 있는 시스템 설계를 관리한다.

 

예를 들면 다음과 같다.

• Auth
• Notification
• Payment
• File Upload
• Admin
• Ranking
• Marketing Tracking

02_Systems/
  Auth/
    Auth Overview.md
    Login Flow.md
    Refresh Token Rotation.md
    Device Session.md
    OAuth Google Kakao.md
    Auth ERD.md
    Auth API.md

  Notification/
    Notification Overview.md
    Push Permission Flow.md
    FCM Token Lifecycle.md
    Retry Policy.md

 

푸시 알림은 A 프로젝트에서 처음 설계할 수 있다. 하지만 나중에 다른 서비스에서도 비슷한 구조를 쓸 수 있다. 이럴 때 특정 프로젝트 안에만 두면 지식이 갇힌다. 02_Systems/Notification에 두면 재사용 가능한 기술 자산이 된다.

 

"이건 다른 프로젝트에서도 다시 쓸 수 있겠다" 싶으면 Systems에 둔다.

 

03_Decisions

중요한 의사결정을 기록하는 곳이다.

 

개발을 하다 보면 수많은 선택을 한다.

• Refresh Token을 단순 재발급할 것인가, Rotation을 적용할 것인가?
• 푸시 토큰을 User 테이블에 둘 것인가, User Device 테이블로 분리할 것인가?
• 패키지 구조를 계층형으로 할 것인가, 도메인형으로 할 것인가?

이런 결정은 시간이 지나면 왜 그렇게 했는지 잊어버리기 쉽다. 그래서 결정을 내린 이유, 대안, 장단점, 결과를 ADR형식으로 기록한다.
ADR은 Architecture Decision Record의 약자로, 아키텍처 의사결정을 기록하는 문서다.

03_Decisions/
  ADR-0001-use-refresh-token-rotation.md
  ADR-0002-separate-user-devices.md
  ADR-0003-separate-notification-deliveries.md
  ADR-0004-use-domain-package-structure.md

 

ADR 문서는 복잡할 필요가 없다.

# ADR-0001 Refresh Token Rotation 도입

## Status
Accepted

## Context
로그인 유지 기능이 필요하지만, 토큰 탈취 시 재사용 공격을 막아야 한다.

## Decision
Refresh Token Rotation을 적용한다.
기기별 세션을 분리하고, 재사용이 감지되면 해당 기기 세션을 폐기한다.

## Consequences

### 장점
- 탈취된 Refresh Token 재사용 탐지 가능
- 기기별 세션 관리 가능
- 보안 수준 향상

### 단점
- 토큰 저장/갱신 로직 복잡도 증가
- 클라이언트 동시 요청 처리 주의 필요

## Related
- [[Auth Overview]]
- [[Device Session]]
- [[Auth MOC]]

 

이처럼 선택지가 여러 개 있었고, 그중 하나를 선택했다면 Decisions에 남긴다.

 

04_Patterns

반복해서 사용할 수 있는 구현 패턴을 모으는 곳이다.

02_Systems가 큰 설계라면, 04_Patterns는 실제 구현에서 반복되는 작은 공식에 가깝다.

 

예를 들면 다음과 같다.

• API 응답 포맷
• 에러 처리 방식
• 페이지네이션 패턴
• Soft Delete 패턴
• Idempotency 패턴
• Entity/DTO 변환 패턴
• 도메인 패키지 구조
• Controller-Service-Repository 규칙
• 테스트 코드 작성 패턴

04_Patterns/
  API Response Format.md
  Error Handling Pattern.md
  Pagination Pattern.md
  Soft Delete Pattern.md
  Idempotency Pattern.md
  Entity DTO Mapping.md
  Domain Package Structure.md
  Mock API Controller Pattern.md

 

목적은 "다음 프로젝트에서 다시 고민하지 않기"다. 매 프로젝트마다 비슷하게 반복되는 구현 방식이라면 Patterns에 둔다.

 

05_References

외부 자료를 정리하는 곳이다. 공식 문서, 블로그 글, 라이브러리 사용법, API 문서 링크, 개념 레퍼런스 등이 들어간다.

05_References/
  Spring Security.md
  Springdoc OpenAPI.md
  FCM Official Docs.md
  Kakao Map API.md
  MySQL Index.md
  OAuth 2.0.md
  C4 Model.md
  arc42.md
  Diataxis.md

 

중요한 점은 References는 내가 만든 설계가 아니라, 외부에서 가져온 지식, 참고 자료, 문서 요약이 들어간다. 다만, 외부 자료를 보고 내 프로젝트에 적용한 결론은 02_Systems나 03_Decisions로 연결하는 것이 좋다.

 

예를 들어, FCM 공식 문서를 정리한 글은 References에 둘 수 있다. 하지만 “우리 서비스에서 푸시 토큰을 기기별로 관리하기로 한 결정”은 Decisions에 둬야 한다.

 

06_Learning

공부 노트를 정리하는 곳이다.

책, 강의, CS 공부, 시스템 설계 공부, Java, Spring, MySQL 개념처럼 학습 목적의 문서가 들어간다.

06_Learning/
  System Design/
    02_개략적인 규모 추정.md
    03_시스템 설계 면접 공략.md

  Spring/
    Spring Security 구조.md
    Transaction 전파.md
    JPA N+1 문제.md

  Database/
    Index 기본.md
    정규화와 반정규화.md
    Isolation Level.md

 

Learning은 아직 내 프로젝트 설계로 굳어진 내용은 아니지만, 나중에 참고할 수 있는 학습 기록이다.

공부한 내용을 실제 프로젝트에 적용하게 되면, 관련 시스템 문서나 패턴 문서로 옮기거나 링크한다.

 

07_Templates

반복해서 사용할 문서 양식을 보관하는 곳이다. 옵시디언을 오래 쓰려면 템플릿이 중요하다. 매번 빈 문서에서 시작하면 문서 품질이 들쭉날쭉해지고, 필요한 항목을 빠뜨리기 쉽다.

07_Templates/
  Template - Project Overview.md
  Template - Feature Spec.md
  Template - API Spec.md
  Template - ERD.md
  Template - ADR.md
  Template - Troubleshooting.md
  Template - Release Note.md

 

ADR 템플릿, API 문서 템플릿, 기능명세 템플릿을 만들어두면 새로운 문서를 훨씬 빠르게 작성할 수 있다.

 

08_MOC

흩어진 문서를 주제별로 다시 모아 보는 인덱스 노트를 둔다. DKA에서 "어디 넣지?"의 마지막 퍼즐을 푸는 폴더다. (자세한 사용법은 다음 섹션에서 계속..)

08_MOC/
  Auth MOC.md
  Notification MOC.md
  Marketing Tracking MOC.md

 

99_Archive

끝났거나 폐기됐거나 지금은 사용하지 않는 문서를 보관한다. 현재 작업 공간을 가볍게 유지하는 게 목적이다.

99_Archive/
  old-projects/
  deprecated-designs/
  unused-ideas/
  old-notes/

 

모든 문서를 계속 활성 폴더에 두면 점점 찾기 어려워진다.
지금 필요 없는 문서는 Archive로 보내고, 필요할 때 다시 꺼내면 된다.

 

연결 · 모아보기 · 운영

위에 내용까지가 폴더(분류 축)다. 이제 폴더가 못 하는 일을 메울 차례다.

 

연결 축(태그) - 문서는 한 곳에, 관점은 여러 개

폴더는 한 문서를 한 곳에만 둔다. 하지만 한 문서는 보통 여러 관점에 동시에 속한다. 이 다중 관점을 표현하는 게 태그의 역할이다. 폴더로 자르지 말고, 태그로 겹쳐라.

 

내가 쓰는 태그 축은 세 가지다.

#system/auth      #system/notification       ← 어떤 기술 도메인인가
#project/foo      #project/bar               ← 어떤 제품과 엮였나
#type/decision    #type/pattern  #type/spec  ← 문서의 종류

 

예를 들어 Systems/Auth/Login Flow.md는 폴더상 한 곳에 있지만, 태그는 이렇게 붙는다.

---
tags: [system/auth, project/foo, project/bar, type/spec]
---

 

이렇게 하면 폴더를 옮기지 않고도 "Auth 관련 전부", "foo 프로젝트가 건드린 전부", "결정 문서 전부"를 각각 한 번에 소환할 수 있다. 폴더가 못 하는 일을 태그가 메운다.

팁  !!!

태그 네이밍은 계층형(#system/auth)으로 통일하길 권한다.
옵시디언에서 #system 만 검색해도 하위가 전부 잡히고, 자동완성이 오타를 막아준다.

 

모아보기(MOC) - "어디 넣지?"의 마지막 답

MOC(Map of Content)는 흩어진 문서를 한 주제 아래 손으로 엮은 목차 노트다. 검색·태그가 자동이라면 MOC는 "내가 중요하다고 판단한 순서대로" 큐레이션한 입구다.

 

로그인 주제를 예로 들면, 다섯 폴더에 흩어진 문서를 Auth MOC.md 하나가 다시 모은다.

# Auth MOC

> 로그인/인증 관련 모든 문서의 입구. 여기서 시작한다.

## 설계 (Systems)
- [[Auth Overview]]
- [[Login Flow]]
- [[Refresh Token Rotation]]
- [[Device Session]]

## 결정 (Decisions)
- [[ADR-0001-use-refresh-token-rotation]]
- [[ADR-0002-separate-user-devices]]

## 구현 패턴 (Patterns)
- [[Error Handling Pattern]]

## 외부 참고 (References)
- [[Spring Security]]
- [[OAuth 2.0]]

## 학습 노트 (Learning)
- [[Spring Security 구조]]

## 쓰는 프로젝트
- [[project1 Overview]] · [[project2 Overview]]

#system/auth

 

이제 "로그인 관련 어디 있더라?"의 답은 항상 같다. Auth MOC를 연다. 문서가 다섯 폴더에 나뉘어 있어도, 입구는 하나다. 이게 글 첫머리에서 던진 "어디 넣지?" 문제를 실제로 끝까지 푸는 방식이다. 넣는 곳(폴더)과 찾는 곳(MOC)을 분리하는 것.

 

Dataview 플러그인을 쓰면 MOC의 일부를 쿼리로 자동 생성할 수도 있다. 예: LIST FROM #system/auth
다만 처음에는 손으로 엮는 걸 권한다. 큐레이션 자체가 지식 정리이기 때문이다.

 

헷갈리지 않기 - #project 태그 vs 01_Projects 폴더

여기서 한 가지가 모호해진다. Systems 문서에 #project/foo 태그를 달면, "이 시스템을 쓰는 프로젝트"가 태그로도, MOC의 "쓰는 프로젝트" 섹션으로도, ADR의 Related로도 표현된다. 셋 중 뭐가 진짜인가?

 

규칙은 하나다. 진실은 한 곳에만 둔다.

프로젝트 연결의 단일 출처는 #project/* 태그다.

01_Projects 폴더는 그 제품 고유 문서(개요·명세·로드맵)만 두는 곳이고, MOC의 "쓰는 프로젝트"와 ADR의 Related는 그 태그 정보를 사람이 보기 좋게 추린 보조 표시일 뿐이다.

 

즉 "foo가 어떤 시스템을 쓰나"를 기계적으로 알고 싶으면 #project/foo를 검색하고, 사람이 읽는 입구가 필요하면 MOC를 본다. 폴더는 제품 고유 문서의 집, 태그는 횡단 연결의 진실원이라고 기억하면 안 헷갈린다.

 

운영 규율 - 이 구조의 진짜 성패는 Inbox에 달려 있다

여기까지가 설계다. 그런데 솔직히 말하면, DKA의 성패는 폴더 개수나 태그 체계가 아니라 "Inbox를 주기적으로 비우는 습관"에 달려 있다. 어떤 PKM 구조든 무너지는 지점은 항상 같다. 들어오기만 하고 분류되지 않은 메모가 쌓여 Inbox가 두 번째 쓰레기통이 되는 순간이다.

 

그래서 폴더 설계만큼 트리아주(triage) 루틴을 정해두는 게 중요하다. 내가 쓰는 규칙은 이렇다.

 

주 1회, 15분 Inbox 비우기. 매주 정해진 시간에 Inbox의 모든 노트를 하나씩 보고, 아래 결정 트리로 즉시 이동시킨다. "지금 분류 안 되면 다음 주에도 안 된다"가 기본 전제다.

 

2분 룰. 한 노트를 어디 둘지 2분 안에 못 정하면, 둘 중 하나다. (1) 아직 쓸 가치가 안 익은 아이디어 → 99_Archive/unused-ideas로 보낸다. (2) 뭉뚱그려진 메모 → 쪼개서 각 조각을 제자리로 보낸다. Inbox에 남겨두지 않는다.

 

이동하면 태그·MOC까지 한 번에. 노트를 제 폴더로 옮길 때 태그를 붙이고, 해당 MOC에 링크 한 줄을 추가한다. 이 세 동작(이동·태그·MOC 등록)을 한 호흡에 끝내야 나중에 "찾을 수 없는 문서"가 안 생긴다.

 

Inbox 상한선을 정한다.

"Inbox 노트가 20개를 넘으면 다른 일을 멈추고 비운다." 처럼 상한선이 있어야 나중에가 무한정 밀리지 않는다.

규율이라고 부르지만 거창한 건 아니다. 핵심은 Inbox는 임시 정류장이지 저장소가 아니다.

 

 

DKA의 핵심 분류 기준

DKA를 사용할 때 가장 중요한 것은 “문서를 어디에 넣을지 빠르게 판단하는 기준”이다.

아직 정리 안 됐다              → 00_Inbox
특정 서비스 이야기다            → 01_Projects
여러 프로젝트에서 재사용될 설계    → 02_Systems
왜 이 선택을 했는지 남겨야 한다   → 03_Decisions
반복해서 구현할 방식이다         → 04_Patterns
외부에서 가져온 참고 자료다       → 05_References
공부한 내용이다                → 06_Learning
복사해서 다시 쓸 양식이다        → 07_Templates
주제별 입구를 만들고 싶다        → 08_MOC
끝났거나 안 쓰지만 남길 거다      → 99_Archive

 

이 기준만 있으면 대부분의 문서는 쉽게 분류할 수 있다.

 

그리고 폴더에 넣은 다음 항상 두 가지를 더 한다.

• 이 문서가 속한 관점들              → 태그 (#system / #project / #type)
• 이 문서가 속한 주제의 입구      → 해당 MOC에 링크 추가

폴더는 한 번, 태그와 MOC는 여러 관점으로. 이게 "어디 넣지?"를 두 번 고민하지 않게 만드는 핵심이다.

 

처음부터 모든 폴더를 쓸 필요는 없다

처음부터 10개 폴더를 모두 열심히 채우려고 하면 오히려 부담이 된다. 다음 5개만 만들어도 충분하다.

00_Inbox
01_Projects
02_Systems
03_Decisions
07_Templates

 

여기에 연결 축은 처음부터 같이 시작하길 권한다. MOC는 주제 하나(예: Auth MOC)만 만들어도 효과를 바로 체감한다. 태그도 #system/* 하나만 일관되게 붙여도 충분하다.

 

그리고 문서가 쌓이기 시작하면 나중에 아래 폴더를 추가해도 된다.

04_Patterns
05_References
06_Learning
08_MOC (주제가 늘어나면)
99_Archive

 

중요한 것은 폴더를 많이 만드는 것이 아닌 내가 만든 프로젝트와 시스템 지식이 흩어지지 않게 하는 것이다.

 

마무리

개발자의 문서는 단순한 메모가 아니다.

서비스를 만들면서 생긴 요구사항, 시스템 설계, API, ERD, 기술 선택, 실패 기록, 반복 패턴은 모두 시간이 지나면 중요한 자산이 된다.

 

PARA가 일상과 업무를 넓게 관리하기 위한 구조라면, DKA는 개발자가 여러 프로젝트를 진행하면서 생기는 지식을 쌓기 위한 구조다.

 

DKA의 핵심은 다섯 가지다.

1. 프로젝트는 제품 단위로 관리한다.
2. 시스템은 재사용 가능한 기술 도메인 단위로 관리한다.
3. 중요한 의사결정은 ADR로 남긴다.
4. 분류는 폴더로 한 번, 연결은 태그·MOC로 여러 관점으로 한다.
5. Inbox는 주기적으로 비운다 - 구조보다 습관이 성패를 가른다.

폴더는 문서를 한 곳에 두지만, 지식은 원래 여러 갈래로 연결된다. 그 간극을 옵시디언의 강점인 링크·태그·MOC로 메우는 순간, 옵시디언은 단순한 노트 앱이 아니라 나만의 개발 아키텍처 위키가 된다.

 

앞으로 프로젝트가 늘어나고 비슷한 기능을 반복해서 만들수록 이 구조의 장점은 더 커진다. 기록은 단순히 과거를 남기는 일이 아니라, 다음 개발을 더 빠르고 정확하게 만드는 일이다.