개발자 앞뒤의 일지

[2026년 6월 회고]

apdui — Sun, 19 Jul 2026 03:18:35 +0900

회고를 시작하며

Oracle DB와 SQL, 데이터 분석 팀플, 핀테크 스터디 OAuth 발표,
멋쟁이사자처럼 세션 운영, 팀플백서 리뉴얼 등등..

커리큘럼을 따라 진도를 나간 내용이 굉장히 많았다.
약간의 문제가 있다면, 내 머릿속에 남은 것은 크게 없다는 기분이 들었다.

FACT (주요 활동)

신한 금융 아카데미
- Oracle DB, SQL, JDBC
- HTML, CSS, JS
데이터 분석 팀프로젝트
- SQL 기반 성과 분석
- 임원진 설득 리포트 작성
신한 핀테크 스터디
- 오픈뱅킹 이체 흐름도
- OAuth 2.0 파트 발표 준비
멋쟁이사자처럼 대표 업무
- 세션 운영
- 상반기 프로젝트 발표회 준비
팀플백서 시리즈 작성
- 노션 작성

이해와 학습은 다르다

프론트엔드 수업도 그렇지만, 실습 내용은 대부분 코드 복붙이었다.
기능을 배우고, 코드를 붙여넣고, 화면에서 결과를 확인하는 반복.

커리큘럼상 어쩔 수 없는 구조였다는 건 당연히 알고 있다.
학습할 내용이 너무 많아서 직접 타이핑 쳐가며 진도를 나갈 수는 없다.

다만, 문제는 그 다음이다.
수업을 다 듣고 나면 화면에 결과가 떠있으니 보통 배웠다고 느끼기 마련이다.
설명을 들으면 나름 고개도 끄덕여지니까.

지금 생각해보건데, 실습 과정을 통해 훈련시키는 것은 알아보는 능력인 듯 하다.
AI를 포함해서 남이 쓴 코드를 보면 무슨 뜻인지 알 수 있게 하는 것.

다만 일반적으로 학습이 요구하는 건 꺼내 쓰는 능력이지 않았는가?
빈 화면 앞에서, 아무것도 안 보고, 그 코드를 내 손으로 만들어내는 것이었는데

워낙 AI가 발달해서인지, 그냥 커리큘럼이 그런 것인지 방향이 이전과는 약간 다른 듯 하다.

보면 아는 것과 안 보고 써보는 것,
이 둘은 뇌에서 완전히 다른 회로를 쓰기 마련이다.
그리고 수업은 구조적으로 앞의 것만 훈련시킬 수 있는 점이

어쩔 수 없지만, 아쉽긴 하다.

자바 때도 동기들이 같은 이유로 어려워했던 것 같은데,

아니나 다를까 프론트엔드도 비슷할 수 밖에 없다.
그러니 다음에 배울 Spring도 아마 크게 다르지 않을 듯 하다.

인증과 인가는 다르다

핀테크 스터디에서 OAuth 2.0 발표를 맡았다.
준비하면서 잘못알고 있었던 부분들을 좀 가져와봤다.

소셜 로그인은 로그인처럼 보인다.
버튼에 로그인이라고 적혀 있으니까..?
나도 당연히 OAuth를 인증 기술이라고 알고 있었다.

그런데 OAuth의 본질은 인증(Authentication)이 아니라
인가(Authorization), 권한 위임이다.

애초에 소셜 로그인을 구현해본적이 없었으니 구체적으로 모를만도 했지만.

공부하며 OAuth 2.0에 OpenID Connect인 OIDC를 얹은 결과물이

-> 소셜 로그인이라고 한다.

발표 때 사용한 예시인데, OAuth의 이해는 발렛 파킹을 떠올리면 된다.
발렛 키는 차를 움직일 권한만 주고, 트렁크를 열거나 차를 팔 권한까지 주지는 않는다.
이게 scope를 보여주고, OAuth를 직관적으로 이해하는 예시였다.

이후에 스터디 공통 주제인 Spring Batch와 연결하면서,
사람이 개입하지 않는 배치 작업에는 Client Credentials Grant가 맞다는 것까지는 찾았는데,
초안에 배치에서도 refresh token을 쓰라고 적었었다.

사람이 로그인하는 플로우에서 배운 지식을,

비슷해 보이니까 같겠지, 하고 기계끼리 통신하는 플로우에 그대로 적용했었다.

Client Credentials에는 refresh token을 발급하지 않는 게 RFC 권고였다.
기계는 자기 자격증명을 이미 들고 있으니, 갱신 토큰을 따로 둘 이유가 없다.
비슷해 보이는 두 플로우는 전제부터 달랐던 것이다.

FINDING (배운 것)

바쁜 것과 성장하는 것은 엄연히 다른데,

자주 놓치는 듯 하다.

수업, 스터디, 팀프로젝트, 멋사 대표 업무 등등
뭐 하나 열심히 안 한 것도 없는데, 돌아보면 기억에 남는 장면이 몇 개 없다.

돌이켜보면 6월에 내가 해낸 일들은 전부 마감이 남이 쥔 일이었다.
수업 진도, 발표 날짜, 세션 일정, 팀플 제출.
남이 정한 마감은 하나도 안 빼먹었다.

밀린 일들은 전부 마감이 내게 있는 일이었다.
회고, 경험 정리, 미뤄둔 공부.
회고가 4주차에서 멈춘 건 의지가 약해서가 아니라,
멈춰도 아무 일도 일어나지 않는 구조였기 때문이다.

절박하지 않았다는 말을 이제 더 정확하게 쓸 수 있다.
남이 만든 절박함으로만 한 달을 살았다.

바쁨은 남의 마감을 처리하는 상태고,
성장은 내 마감을 스스로 만드는 선택이다.

FUTURE (앞으로)

7월부터는 본격적인 팀 프로젝트가 시작된다.
6명의 팀원들과, 두 개의 프로젝트를 차근차근 준비해 나가야한다.

Git 워크플로우는 Organization + 단일 레포로,
main과 develop 두 브랜치, Squash merge 통일, Owner + Maintain + Write 3단 권한으로 정리했고,
Notion에는 개발 컨벤션 페이지를 왜/어떻게/복붙존 3층 구조로 채울 생각으로

포스팅도 올려뒀다.

아직 협업 경험이 충분치 않거나

개발 역량이 부족한 팀원들이 최대한 빠르게

적응하고, 성장하기를 바란다.

[신한 금융SW 아카데미 7기] 7주차 회고

apdui — Sun, 19 Jul 2026 02:05:51 +0900

회고를 시작하며

한달가량 포스팅이 뜸했습니다.

임시저장에는 글 비스무리한 것들이 쌓여만 갔습니다.

제가 조금 더 성실했다면 이렇게 미루지는 않았을텐데 말입니다.

하고 싶은 말은 많지만 수많은 변명들을 뒤로하고,

단순히 절박하지 않았다고 생각합니다.

발등에 불똥이 튀어도,

그을음이 불길로 번지기 직전까지도 나태한 사람이

지금의 제 모습인 듯 합니다.

"할 건 해야지"

제가 가장 좋아하고, 자주 쓰는 말이었지만

정작 저는 그러지 못하고 있었던 듯 합니다.

글을 쓰는 지금도 몹시 괴로워하며 반성 중입니다.

게으름이 저를 붙잡기 전에

남은 4개월동안 열심히 달려보려 합니다.

이번 주는 어떻게 보냈는가?

이번 주를 기점으로 스프링을 배우기 위한 준비가 끝났다.
프론트 단계의 HTML, CSS, 자바스크립트(JS) 학습을 진행했다.

솔직한 심경으로는, 4주차 이후로 회고가 없었던 걸 보면 알겠지만
6월 한 달 동안 으음... 많이 정돈되지 못한 일정을 살았던 것 같다.

왜 어쩌다 그렇게 됐는지는 모르겠지만,
한 달 동안 수업 진도는 엄청 많이 나갔는데
정작 기억에 남는 건 하나도 없다.
아무래도 금융 공학 스터디를 열심히 하긴 했지...

3주차부터는 데이터 부분 수업을 나가면서
데이터 해석에 관한 팀 과제도 진행했다.
1주일 동안 진행했고,
처음으로 같이 하는 팀 프로젝트라 걱정이 되긴 했는데,
무사히 마쳤다.

데이터베이스 수업이 끝나고 바로 프론트엔드 수업으로 들어갔는데
2주 동안 HTML과 CSS를 학습했다.

사실 프론트엔드는 내가 정확히 모르는 부분이기도 하고,
잘 알아두면 좋은 내용이라 열심히 들었어야 했는데.

열심히 안 들은 건 아닌데,
수업 시간에 집중하지 못한 시간이 참 많았던 것 같다.

강사님이 실습 위주로 수업을 진행하시긴 했는데,
아무래도 커리큘럼 진도를 맞춰야 하니까 템포가 너무 빨랐고,
바이브코딩으로 두들기며 아주 약간의 지식만 갖고 있던 나에게는
따라가기 어려웠다.

사실 속도가 문제라기보다는,
실습이 학습을 위한 과정이라기보다 이해를 위한 과정이었던 듯하다.

코드를 치고, 내가 친 코드가 화면에 어떤 모습으로 나타나는지 이해하고,
자유자재로 코드를 작성하는 능력을 키운다기보다,

기능을 배우고, 해당 기능의 코드를 복붙하며
키워드가 화면에 어떤 형태로 나타나는지, 어떻게 수정할 수 있는지를
학습했다는 느낌이 강했다.

학습할 내용이 너무 많다 보니 직접 코드를 치며 진도를 나갈 수 없는 커리큘럼이었고,
그래서 대부분의 실습은 코드 복붙이었다.

자바를 배울 때 많은 동기들이 어려워했는데,
프론트엔드도 마찬가지였다.

금융공학 스터디

그동안 포스팅을 미뤄왔던 것과도 직결되는 내용이긴한데,

현재 진행되는 커리큘럼과 별개로 2개의 스터디를 병행 중이다.

개인적으로 진행하는 스터디는 아니고,

비슷한 관심사를 가진 동기들과 특정 금융 도메인에 대한 학습을 진행하는 스터디이다.

우리는 오픈뱅킹&핀테크 분야를 선택했고,

아카데미 3주차와 4주차 기간동안 1차 발표 준비를 했다.

4명의 팀원이 각자 다음의 주제를 맡았고,

공통 학습 부분으로 스프링 배치에 대한 학습을 진행했다.

오픈뱅킹&API gateway
마이데이터
OAuth 2.0
간편결제

각자 학습해온 내용을 정리하고, 내부적으로 공유하며

4개 파트에 대한 팀원 전체의 이해도를 높이려했다.

스터디 경험이 가장 많은 내가 팀장을 맡게되었다.

내 입장에서도 총 8번의 발표 준비를 해야하는 장기 스터디인 이상

초반에 전반적인 스터디 프로세스를 정립해두는 것이 편했다.

간과한 부분이 있다면 발표자료의 준비인데,

피그마를 사용해본 사람이 당연히 없을 것이란 생각을 미처 못했다.

발표자료를 8번을 만들어야하니 무조건 피그마를 배워서라도 쓰는게

이득이라고 생각해서 도입해버렸다.

아무리 AI를 열심히 굴려서 발표자료를 만드려고해봐도,

많이 써보면 알겠지만 프로토타입을 만드는건 쉬워도

생각보다 디테일한 수정이 정말 쉽지 않다.

덕분에 피그마로 발표자료 만들며

피그마 어떻게 쓰는지 팀원들에게 알려주며

후술할 데이터 분석 팀프로젝트까지 진행하며

커리큘럼 학습까지 진행하려니

개인 여가 시간을 갈아넣지 않고는

이러한 경험들을 정리할 시간이 나지 않았다.

그리고 과거의 나는 개인적인 시간들까지

갈아넣고 싶은 열정은 아니었구나 생각하며 반성중이다.

데이터 분석 실습

어쩌다 이런 주제가 갑자기 나왔는지는 모르겠지만,

MyBatis를 활용한 DB 공부를 진행하다가

갑자기 나온 팀플이었다.

요약하자면, 어떤 패밀리 레스토랑에서

온라인 마케팅을 확대하자는 얘기가 나왔고,

이에 대해 임원진의 주장은 다음과 같았다.

급격한 변화는 실패할 확률이 높음 = 위험함
브랜드 이미지 하락 + 고객들의 부정적 반응 우려

우리는 회사의 데이터 분석가이고,

온라인 마케팅 예산 확보에 대하여 임원진을 설득하는 것이 목표였다.

https://app.notion.com/p/37c85cc2932c80e19daff26925ad909d?source=copy_link

최종 보고서 | Notion

A식당 온라인 전용 상품 성과 분석 보고서

app.notion.com

7주차 회고를 올리는 지금은 웃기게도 8주차 회고 시점이다.

사실 6월 회고도 적어두기만 하고 안올려놔서

참 이래저래 그렇다.

열심히 살아가보자.

나중에 더 큰 후회를 경험하기 전에.

지금 하고 싶은 것들을 조금 참으며 해야 할 일들을 하는 것이,

후에 더 큰 가치들을 포기하지 않는 길이라고 생각한다.

Notion 워크스페이스 구성 및 설정

apdui — Mon, 29 Jun 2026 15:45:18 +0900

팀플백서 시리즈는 총 9편으로 구성되어 있으며,

팀 프로젝트가 익숙하지 않은 사람들을 위한 가이드라인을 제공합니다.

현재 포스팅은 [part 1] 협업 워크스페이스 구성(Notion)를 다룹니다.

이 글은 처음 보는 팀원들과 프로젝트를 시작하는 상황에서,

Notion을 어디까지 어떻게 세팅해야 하는지를 정리한 문서입니다.

예시 노션 페이지(프로젝트 워크스페이스)

협업 워크스페이스 | Notion

Sprint 1 @July 6, 2026 → @July 10, 2026 9:00 AM (GMT+9)

app.notion.com

단순히 노션 페이지를 예쁘게 정리하는 방법이 아니라,

프로젝트의 맥락과 의사결정, 회의 기록, 운영 기준을

흩어지지 않게 만드는 구조 설계를 작성되었습니다.

왜 Notion부터 세팅해야 할까?

Notion은 문서 작성, 지식 베이스, 프로젝트 정리 기능을

한 공간에서 다룰 수 있도록 설계된 협업 도구이며,

데이터베이스를 기반으로 문서와 업무 정보를 연결해 관리할 수 있습니다.

특히 Notion의 데이터베이스는 각각의 항목이 개별 페이지로 열리는 구조이기 때문에,

표처럼 정리하면서도 문서처럼 깊이 있게 내용을 담을 수 있습니다.

이 점이 팀 프로젝트 초반의 문서와 실행 사이의 단절을 줄이는 데 유리합니다.

또한 Notion은 팀스페이스와 권한 그룹을 통해 워크스페이스 접근 범위를 나눌 수 있고,

페이지별로 Full access, Can edit, Can comment, Can view 권한을 설정할 수 있습니다.

즉, 해커톤처럼 빠르게 움직이는 프로젝트든, 학기 단위로 이어지는 장기 프로젝트든,

초반부터 정보 공개 범위와 편집 권한을 정교하게 나눌 수 있습니다.

이것이 Notion을 단순 메모 앱이 아니라 협업 워크스페이스의 출발점으로 삼아야 하는 이유입니다.

2026년 기준 Notion은 단순 문서 도구를 넘어

AI Meeting Notes, Enterprise Search, 외부 도구 연결이나

GitHub,Slack,Jira 등의 링크 미리보기 및 동기화 기능까지 제공하고 있습니다.

2026년형 Notion 설계 원칙

이번 리뉴얼의 핵심 방향이 “구조까지 재설계해 전면 개편”이라면,

Notion 파트에서도 가장 먼저 바뀌어야 할 것은 페이지 몇 개를 만드는 수준이 아니라

무엇을 Notion에 남기고, 무엇은 다른 도구의 책임으로 둘 것인지를 정하는 일입니다.

제가 권장하는 기준은 분명합니다.

첫번째 원칙

Notion은 프로젝트의 맥락과 판단 근거를 남기는 공간,

GitHub는 개발 실행 상태를 추적하는 공간으로 나누는 방식입니다.

Notion은 문서·지식·데이터베이스 연결에 강하고,

GitHub Projects는 이슈·PR·로드맵·자동화 중심의 추적에 강하기 때문입니다.

이는 두 도구의 기능 특성을 조합했을 때 가장 중복 입력이 적고 유지보수 비용이 낮은 구조입니다.

두번째 원칙

두 번째 원칙은 주제별 단일 기준 저장소입니다.

예를 들어 “기능 정의”는 PR 설명이 아니라 스펙 문서에,

“왜 이 기술을 골랐는가”는 채팅방이 아니라 의사결정 기록에,

“이번 주 액션 아이템”은 회의록과 연결된 업무 항목에 남아야 합니다.

Notion의 relation·rollup 속성은 서로 다른 데이터베이스의 항목을 연결하고 요약할 수 있으므로,

이 원칙을 구조적으로 구현하기 좋습니다.

세 번째 원칙

세 번째 원칙은 페이지를 늘리기보다 데이터베이스를 중심으로 설계하는 것입니다.

Notion에서는 데이터베이스 항목 하나하나가 곧 페이지이므로,

회의록·결정사항·문서·리스크를 각각 데이터베이스로 잡아두면

이후 필터, 정렬, 뷰 전환, 회고, 검색이 훨씬 쉬워집니다.

단발성 페이지를 무작정 쌓으면 처음에는 빨라 보이지만,

프로젝트가 길어질수록 과거 맥락을 다시 찾는 비용이 커집니다.

네 번째 원칙

네 번째 원칙은 의사결정을 기록하는 습관을 구조에 포함하는 것입니다.

Martin Fowler는 ADR을 “하나의 중요한 결정을 설명하는 짧은 문서”라고 정의하고,

맥락과 결정, 파급효과를 함께 남길 것을 권장합니다.

Thoughtworks 역시 Lightweight ADR을

중요한 설계 결정을 맥락과 결과와 함께 기록하는 방식으로 소개합니다.

팀 프로젝트에서는 완벽한 아키텍처 문서보다,

짧더라도 나중에 다시 읽을 수 있는 결정 로그가 훨씬 유용합니다.

바로 사용할 수 있는 워크스페이스 구조

Notion 세팅의 출발점은 “예쁘게 꾸민 첫 화면”이 아니라

누가 들어와도 길을 잃지 않는 정보 구조입니다.

팀스페이스 단위로 프로젝트를 나누고,

그 아래에서 페이지와 데이터베이스를 한 번에 찾을 수 있게 구성해야 합니다.

팀스페이스는 멤버와 소유자를 분리해 관리할 수 있으며,

소유자는 기본적으로 팀스페이스 내 모든 페이지에 대한 전체 권한과 설정 권한을 가집니다.

2026년의 제가 권장하는 최소 구조는 다음과 같습니다.

[Teamspace] 프로젝트명
├─ Start Here
├─ Project Home
├─ Specs & Docs
├─ Meeting Notes
├─ Decision Log
├─ Risks & Blockers
├─ Design & References
├─ QA & Release
├─ Onboarding
└─ Archive

이 구조에서 가장 중요한 페이지는 Start Here와 Project Home입니다.

Start Here는 팀원이 처음 들어왔을 때 “이 프로젝트가 무엇이고,

어디서부터 읽어야 하는지”를 알려주는 허브여야 합니다.

여기에는 프로젝트 소개, 팀원 역할, 주요 링크,

커뮤니케이션 채널, 문서 작성 규칙, 용어 정의를 넣습니다.

Project Home은 현재 진행 상황을 보는 공간으로 두되,

상세 내용은 각 데이터베이스로 들어가게 만드는 것이 좋습니다.

Notion의 synced block을 활용하면 “공통 운영 원칙”이나 “문서 작성 규칙” 같은 내용을

여러 페이지에 재사용할 수 있어서 규칙이 바뀌었을 때

한 번만 수정해도 전체 문서에 반영할 수 있습니다.

문서 구조는 얕고 넓게 가져가는 편이 좋습니다.

예를 들어 Specs & Docs 아래에 PRD, API 정의, 외부 참고 자료, 사용자 흐름, 운영 정책을

모두 하위 페이지로 깊게 매다는 구조는 초반에는 단정해 보여도 실제 탐색성이 떨어집니다.

대신 “문서 데이터베이스” 하나를 만들고,

문서 유형·상태·담당자·최종 검토일로 관리하는 편이 검색과 회고에 유리합니다.

Notion은 하나의 데이터베이스를

테이블, 리스트, 보드, 타임라인, 캘린더 등으로 다르게 볼 수 있기 때문에,

문서를 쌓는 방식보다 훨씬 유연합니다.

반드시 만들어야 할 데이터베이스와 템플릿

이 글에서 가장 실무적인 결론은 간단합니다.

팀 프로젝트용 Notion에는 최소 네 개의 데이터베이스가 필요합니다.

회의록, 의사결정 로그, 문서/스펙, 리스크/블로커입니다.

이 네 축만 제대로 세팅해도

무슨 얘기를 했는지
왜 그렇게 결정했는지
어디를 보면 되는지
지금 어디에서 막혔는지

위와 같은 내용들이 한 번에 보이기 시작합니다.

Notion 데이터베이스는 속성, 뷰, 필터, 정렬, 관계 설정을 통해 이런 정보를 구조적으로 관리하게 해 줍니다.

데이터베이스	핵심 속성	추천 뷰	역할
Meeting Notes	날짜, 참석자, 안건, 결정사항, 액션 아이템, 관련 문서	List, Calendar	회의 내용 누락 방지
Decision Log	상태, 결정일, 담당자, 배경, 선택지, 최종 결정, 영향도, 상위/하위 결정	Table, List	기술·운영 판단 기록
Specs & Docs	문서 유형, 상태, 작성자, 리뷰어, 최종 검토일, 관련 기능	Table, List	요구사항·정책·참고문서 관리
Risks & Blockers	심각도, 상태, 담당자, 발생일, 해결 목표일, 연관 기능	Board, Calendar	문제를 드러내고 추적
Onboarding	대상 역할, 읽기 순서, 필수 링크, 완료 여부	List	새 팀원 적응 가속
Release & QA	릴리즈 버전, 체크리스트, 배포일, 이슈 링크	Calendar, Table	운영 전환 시점 관리

이때 데이터베이스마다 권한, 쓰임새, 기본 뷰가 달라야 합니다.

예를 들어 회의록은 리스트 형태가 가장 탐색성이 좋고,

릴리즈·런칭 관리는 캘린더나 타임라인이 적합합니다.

리스크 관리는 상태값 기준으로 보드 뷰를 두면 병목이 어디에 있는지 파악하기 쉽습니다.

Notion 공식 문서 역시 하나의 데이터베이스를 여러 뷰로 전환해 쓰는 방식을 권장하고 있으며,

보드는 프로세스 단계 추적에, 캘린더는 중요한 날짜 확인에,

타임라인은 마일스톤과 기간 시각화에 적합하다고 설명합니다.

특히 Decision Log는 이번 리뉴얼에서 강조하는 부분인데, 꼭 포함하기를 권하고 싶습니다..

작년 글에서는 기술 선택 이유를 충분히 설명하기 어려웠던 지점이 있었는데,

그 문제는 사실 “판단을 잘못했다”기보다 “판단 근거를 남기지 않았다”는 데서 옵니다.

JDK 21을 왜 선택했는지, Docker 기반 배포를 왜 택했는지,

GitHub Projects를 왜 도입하지 않았는지 같은 사항은

시간이 지나면 기억보다 기록이 더 중요해집니다.

결정 로그가 있으면 이후 포스팅에서도

“그때 우리는 왜 그렇게 정했는가”를 일관되게 설명할 수 있습니다.

ADR의 핵심도 바로 그 지점입니다.

아래 두 템플릿은 실제로 바로 써도 될 정도로 단순하게 시작하는 것을 권장합니다.

회의록 템플릿

//markdown으로 작성된 문서이니 그대로 복사해서 템플릿에 사용하시면 됩니다.

제목: [주간 회의] YYYY-MM-DD

## 회의 목적
이번 회의에서 결정해야 할 사항을 한 줄로 정리합니다.

## 참석자
- PM
- Designer
- FE
- BE

## 안건
- 안건 1
- 안건 2

## 논의 내용
- 핵심 논의 내용 정리

## 결정사항
- 결정 1
- 결정 2

## 액션 아이템
- [ ] 담당자 / 할 일 / 마감일
- [ ] 담당자 / 할 일 / 마감일

## 관련 문서
- PRD
- 디자인 링크
- GitHub Issue

의사결정 로그 템플릿

//markdown

제목: [ADR] 어떤 결정을 내렸는가

## 상태
Proposed / Accepted / Superseded

## 배경
이 결정을 하게 된 상황과 제약조건을 정리합니다.

## 선택지
- 선택지 A
- 선택지 B
- 선택지 C

## 최종 결정
무엇을 선택했는지 한 문장으로 적습니다.

## 근거
왜 그렇게 판단했는지, 무엇을 포기했는지 기록합니다.

## 영향
개발, 운영, 배포, 비용, 확장성 측면의 영향을 정리합니다.

## 관련 문서
- 스펙 문서
- 회의록
- GitHub Issue / PR

템플릿과 자동화는 어디까지 써야 하는가

Notion은 데이터베이스 템플릿, 버튼, 폼, 자동화를 통해 반복 작업을 줄일 수 있습니다.

데이터베이스 템플릿은 새 항목을 만들 때 미리 정해 둔 형식으로 페이지를 생성하게 해 주고,

버튼은 워크스페이스 어디에서든 페이지 생성이나 속성 변경을 시작할 수 있게 합니다.

폼은 워크스페이스 외부 사용자도 정보를 제출할 수 있게 연결되어 있어,

사용자 피드백 수집이나 멘토 코멘트 접수, QA 제보 수집에 유용합니다.

다만 자동화는 많이 넣을수록 좋은 것이 아닙니다.

Notion의 데이터베이스 자동화는 특정 변경을 트리거로 동작하지만,

다른 자동화가 또 다른 자동화를 연쇄적으로 일으키는 방식으로 설계되어 있지 않습니다.

공식 문서도 버튼 액션은 자동화를 트리거할 수 있지만,

자동화끼리의 중첩에는 제약이 있다고 설명합니다.

따라서 프로젝트 초반에는 “자동 회의록 생성”, “상태 변경 시 담당자 알림”,

“리스크 등록 시 기본 속성 세팅” 정도까지만 두고,

핵심 상태 변경은 여전히 사람이 검토하도록 두는 편이 더 안정적입니다.

회의 문화가 많은 팀이라면 Meeting Notes 데이터베이스는 일찍 만들어 두는 편이 좋습니다.

Notion의 AI Meeting Notes 기능은 기본 저장 데이터베이스를 지정할 수 있기 때문에,

이 기능을 사용할 생각이라면 처음부터 회의록 전용 데이터베이스를 따로 만드는 것이 바람직합니다.

또한 회의 자동 요약을 사용할수록 “누가 이 회의록을 볼 수 있는가”가 더 중요해지므로,

기능 도입 이전에 접근 권한부터 정리해야 합니다.

권한과 운영 규칙은 문서보다 먼저 정해야 한다
협업 워크스페이스가 실패하는 가장 흔한 이유는 템플릿이 부족해서가 아니라,

누가 무엇을 수정할 수 있는지 모호하기 때문입니다.

Notion은 페이지 단위로 일반 접근 범위를

Only people invited, Everyone at workspace, 공개 링크 등으로 설정할 수 있고,

사람이나 그룹별로도 수정·댓글·조회 권한을 세분화할 수 있습니다.

따라서 팀 프로젝트의 초반에는 “누구나 편집 가능”이라는 편의보다 “

어디까지가 공용 문서이고, 어디부터가 관리 문서인지”를 먼저 정해야 합니다.

실무적으로는 다음의 기준이 가장 무난합니다.

Start Here, Project Home, Meeting Notes, Decision Log는

팀원 전체 Can edit, 외부 멘토나 리뷰어가 있다면 필요한 페이지만

Can comment 또는 Can view로 엽니다.

민감한 운영 정보, 계정 정보, 배포 체크리스트 세부 내용은 별도 페이지로 분리하고

최소 인원만 접근하도록 둡니다.

“문서를 열어두는 것”과 “문서를 맡기는 것”은 다른 문제이기 때문입니다.

이 원칙만 지켜도 프로젝트 후반에 문서가 망가지는 일을 크게 줄일 수 있습니다.

아카이브 기준

또 하나 중요한 점은 아카이브 기준입니다.

Notion은 페이지가 계속 쌓이는 구조이기 때문에,

완료된 회의록과 종료된 결정사항, 폐기된 스펙을 그대로 방치하면 검색 품질이 금방 나빠집니다.

따라서 Archive 페이지나 상태값을 별도로 두고,

분기 또는 스프린트 단위로 문서를 정리하는 규칙을 미리 두는 편이 좋습니다.

Notion 데이터베이스의 필터와 정렬, 상태 속성을 활용하면 현재 문서와 과거 문서를 쉽게 분리할 수 있습니다.

GitHub와 연결할 때의 기준

이 글이 Notion 편이라고 해서, 개발 실행 흐름과 완전히 분리해서 생각하면 오히려 실전성이 떨어집니다.

2026년 기준 Notion은 GitHub 링크 미리보기와 GitHub Issues·Pull Requests 동기화 데이터베이스를 지원합니다.

즉, GitHub의 이슈와 PR을 Notion 안으로 가져와 문서와 함께 맥락을 볼 수 있습니다.

반면 GitHub Projects는 이슈, PR, 드래프트 아이템을 중심으로

테이블·보드·로드맵 뷰를 제공하고, 커스텀 필드, 필터, 정렬, 차트, 내장 워크플로 자동화까지 지원합니다.

즉, “현재 누가 무엇을 하고 있으며, 무엇이 막혀 있는가”를 추적하는 일은 GitHub 쪽이 더 강합니다.

그래서 팀 프로젝트에서는 Notion에 작업 상태를 다시 수기로 적는 이중 관리를 피하는 것이 좋습니다.

Notion에는 프로젝트 개요, 기능 정의, 결정 근거, 회의 결과, 리스크 설명을 남기고,

GitHub에는 실제 일감의 상태값을 남기는 구조가 가장 깔끔합니다.

이는 단순 취향이 아니라, 도구의 강점을 분리해 중복 문서화를 줄이는 전략입니다.

따라서 이 포스팅만 보고 Notion을 세팅한다면,

GitHub 연동은 다음 수준까지만 해도 충분합니다.

스펙 문서에서 관련 이슈와 PR을 링크하고, 중요한 이슈 목록은 synced database로 붙여두며,

회의록의 액션 아이템에는 실제 GitHub 이슈 번호를 남깁니다.

이렇게 해 두면 이후 시리즈에서

GitHub Projects와 Git Convention을 다룰 때도 문서 체계가 자연스럽게 이어집니다.

바로 적용하는 세팅 순서

이 글을 실전용 체크리스트로 바꾸면 순서는 다음과 같습니다.

먼저 팀스페이스를 만들고, 소유자와 일반 멤버를 나눈 뒤 권한 그룹을 정합니다.
다음으로 Start Here와 Project Home을 만들고, 팀 규칙과 주요 링크를 가장 먼저 고정합니다.
그 다음 회의록, 의사결정 로그, 문서/스펙, 리스크/블로커 데이터베이스를 생성하고,
각 데이터베이스에 최소 속성과 기본 뷰를 부여합니다.
이후 데이터베이스 템플릿을 등록해 입력 형식을 통일하고,
필요하다면 버튼과 폼으로 반복 업무를 줄입니다.
마지막으로 GitHub 이슈·PR을 연결하고,
어떤 정보가 Notion의 기준 저장소인지 운영 규칙에 명시하면 됩니다.

이 순서는 Notion의 팀스페이스·권한·데이터베이스·템플릿·자동화·외부 연결 기능을

가장 적은 시행착오로 조합하는 방식입니다.

2026년형 Notion 세팅의 핵심은 “페이지를 많이 만드는 것”이 아니라

프로젝트의 맥락을 잃지 않는 구조를 먼저 설계하는 것입니다.

해커톤처럼 짧은 프로젝트에서도 이 구조는 유효하고,

특히 장기 프로젝트에서는 효과가 훨씬 크게 드러납니다.

문서와 회의록, 의사결정, 리스크를 제각각 흩어두지 않고

하나의 워크스페이스 구조로 묶어 두면,

이후 Git Convention, 아키텍처, CI/CD, 배포 포스팅까지도

모두 같은 기준 위에서 설명할 수 있게 됩니다.

Notion은 그 출발점으로 충분히 강력하지만,

더 중요한 것은 도구 자체가 아니라

무엇을 기록하고 무엇을 연결할지 먼저 정하는 팀의 태도입니다.

오픈뱅킹과 핀테크

apdui — Thu, 25 Jun 2026 15:49:51 +0900

핀테크(FinTech)

IT 기술을 활용하여 금융 서비스를 더 편리하고 효율적으로 제공하는 것

은행에 가지 않고도, 핸드폰으로 계좌 조회와 이체가 가능한 이유가
바로 이 ‘핀테크’ 덕분입니다.

현재는 ‘오픈뱅킹’ 이라는 기술적 개념과 함께 더욱 확장 되고 있습니다.

언젠가부터 우리는 토스나 카카오뱅크, 혹은 은행 어플을 통해

여러 은행 계좌를 한 번에 조회할 수 있게 되었습니다.

우리은행 계좌
국민은행 계좌
카카오뱅크 계좌

분명 신한SOL 앱을 켰는데,

위 은행의 게좌들도 앱에서 모두 확인할 수 있죠.

과거에는 하나의 은행 어플에서 다른 은행계좌가 조회되지 않았던 구조였습니다
하지만 오픈뱅킹 도입 이후 , 금융결제원을 중심으로 '표준 API'를 제공하기 시작했습니다.

핀테크 앱은 이제 금융결제원이 만들어 둔 이 하나의 표준 규격만 맞추면
모든 은행으로부터 나의 계좌 잔액을 조회할 수 있게 된 것이죠

개요

오픈뱅킹(Open Banking)의 정의는 다음과 같습니다.

하나의 앱에서 통합뱅킹서비스 제공 등 다양한 금융서비스 구현이 가능하도록 참여기관 공동의 표준API를 제공하고,
이를 통한 거래중계 및 관련 업무 등을 처리하는 개방형 금융결제 플랫폼입니다

https://openapi.kftc.or.kr/service/openBanking

오픈뱅킹의 대표격인 토스에서
처음 계좌를 연결할 때를 떠올려 봅시다

우리가 토스에서 계좌를 조회할 때,
처음 한번은 계좌 연결을 눌러서
본인 인증과 정보 제공 동의를 진행하게 됩니다.

이 단계를 통해서 여러분은 본인 인증 및 권한을 지정합니다.

본인 인증이 성공하면, 금융결제원이
오픈뱅킹 표준 규격에 맞춰 Access Token을 생성하고 이를 토스에게 발급하게 됩니다.

이제 토스는 이 토큰을 들고 개별 은행으로 바로 가는 게 아니라,
후술할 API Gateway로 "이 토큰 줄 테니 잔액 보여줘" 라고 요청합니다.

금융결제원이 토큰을 검증한 뒤, 해당 은행에게 데이터를 요청하고,
계좌 조회에 대한 응답을 해줍니다.

이러한 응답을 받은 토스는
여러분이 이해하기 쉽게 계좌정보들을 정리하여 보여주게 됩니다.

이 예시의 가장 큰 특징은 토스가 은행으로부터 직접 정보를 가져오지않고,
금융결제원을 통해서 요청과 응답이 발생하는 것입니다.

표준 API의 등장

과거에는 은행마다 API 호출 방식이 제각각이라 핀테크 회사에서
은행별로 개발을 다르게 해야하는 불상사가 생겼고,
이에 따라 표준 API가 등장하게 되었습니다.

표준 API를 통해,
모든 은행은 금융결제원이 정한 표준화된 언어로 값을 주고 받게 됩니다.

앞서 금융결제원의 API gateway를 통해 토큰을 검증한다고 했죠?

API Gateway는 모든 API 요청을 관리하고 연결하는 교통경찰 같은 서버 프로그램입니다.
크게 세 가지 역할을 수행합니다.

첫째, token을 검증합니다.
API 호출시 '이 요청자가 정말 권한이 있는가?'를 확인하여 허가된 자만 통과시킵니다.

둘째, 들어온 요청이 잔액 조회인지, 이체인지를 판단해서
각각의 업무를 처리하는 전용 서버로 분류합니다.
이렇게 서버를 분리함으로써 시스템의 부하를 분산하고 효율을 증가 시킵니다.

셋째, 서버가 마비되는 것을 막기 위해,
정해진 횟수 이상의 요청은 '잠시만 기다려달라'며 차단합니다.

여름의 생각

apdui — Wed, 24 Jun 2026 16:49:01 +0900

너무나 다양한 기술들이 빠른 속도로 시장에 나오는 세상에 살며

정돈되지 못하고 머릿속을 떠다니는 생각들을

어떻게든 세상에 풀어내며 갈무리하고 싶은 요즘입니다.

문득 그런 생각이 들었습니다.

AI가 모든 인간을 대체하긴 어렵겠지만,

9할의 인력을 대체하는 데에는

그리 오랜 시간이 걸리지 않을수도 있겠다.

사용자 노력은 양 끝단, 즉 목표를 설정하고 결과를 검토하는 데 집중됩니다.

그 사이의 과정은 대부분 에이전트가 처리하고 있습니다.

인공지능과 가까이 지내며 드는 요즘의 생각입니다.

다중 모델 오케스트레이션이 아주 핵심적인 기술인데,
하나의 모델이 모든 작업을 수행하는게아니라
독립된 모델들이 본인이 가장 잘하는 작업을 수행할 수 있도록
업무를 분담해주는 것이 중요해졌다고 생각합니다.

또다른 흥미로운 점으로 이런 것도 있었죠.
AI의 발전은 굉장히 빠르고, 어느정도 예상된 부분입니다.

더 흥미로운 발견은 사람들이 되찾은 시간을 어디에 쓰기로 했는가입니다.

실행 비용이 낮아지면 판단의 기준이 달라집니다.

이전에는 해볼 가치가 없던 일이 갑자기 해볼 만한 일이 됩니다.

과거에는 전문가가 필요했던 일도

이제는 스스로 충분히 시도해 볼 수 있는 일이 됩니다.

지식 노동의 병목은 정보 탐색 자체인 경우는 드물었고, 실행 역량이었습니다.
빠르게 발전중인 AI가 이 실행 역량을 담당하며,

그 결과 사람들은 더 높은 수준의 목표를 지향하게 됩니다.

사람들은 운영자에서 감독자로 이동하며

워크플로우를 돌리는 데 쓰는 시간은 줄이고,

목표를 설정하고 결과물을 점검하는 데 더 많은 시간을 씁니다.

생각해 볼 여지가 남았는데,
인공지능 에이전트는 아직도 매우 초기 단계입니다

AI agent가 출시된 지 불과 수년밖에 되지 않았고,

사람들은 그것과 함께 일하는 방식에 익숙해지고 있으며,

워크플로와 사용 방식은 시간이 지나면서 분명히 적응해 갈 것입니다.

이 변화가 팀과 조직 수준에서 어떻게 집계되고 나타나는지는 아직 열려 있는 질문이며,
다음으로 가장 큰 관심을 두고 있는 주제이기도 합니다.

아직은 이러한 변화를 직접 탐색하거나 확인할 수 없기에

꾸준히 눈과 귀를 바삐 움직여보고 있으려 합니다.

VS Code Pets 사용법 및 후기

apdui — Wed, 24 Jun 2026 15:44:41 +0900

한동안 식곤증으로 졸릴때마다

노트북 위에서 나를 노려보는 배드배츠마루 피규어를 봤었는데,

화면 안에서도 귀여운 녀석들이 있으면 좋겠다는 생각에

가장 유명한 플러그인을 입양해왔다.

1. 설치 방법

VS Code 왼쪽 Extensions 탭에서 검색하면

최상단에 가장 인기많은 녀석이 있다.

Marketplace 기준으로 Pets for your VS Code 확장이고,

설치 후 Command Palette에서 실행하는 방식이라고 한다.

2. 실행 방법

설치 후 Ctrl + Shift + P를 누르고 아래 명령어를 검색하면

세션 시작 명령어가 있다.

세션을 시작하게 되면

좌측 하단에 굉장히 조그마한 펫이 하나 튀어나온다.

이리저리 돌아다니고 벽도 타고 난리부르스

추가로 소환하는 명령어는

마찬가지로 검색창( Ctrl + Shift + P)을 열고

spawn pet 명령어를 실행하면 된다

종류를 선택할 수 있는데,

냅다 토토로를 선택해주었다.

큰 문제가 있다.
귀여운 녀석들이 너무 작다.
왕크왕귀를 위해 사이즈를 키워보자.

3. 설정 변경

Ctrl + , 눌러서 VS Code 설정을 열고 검색창에 pets를 검색하면

[신한 금융SW 아카데미 7기] 4주차 회고

apdui — Tue, 16 Jun 2026 00:49:50 +0900

시간이 참 빠른 것 같다

해야 할 일이 많을 땐,

더욱 더 빠르게 지나가는 것 같다.

일단, 지난 주차에 Java의 전반적인 내용은 끝이 났다.

week 2 : Java 졸업하기

week1에서 이어지는 내용입니다 week 1 : Java 입문, 객체지향의 뼈대 세우기첫 주는 「이것이 자바다」 1권,그러니까 1장부터 11장까지를 쭉 달렸다.Java 기초 문법부터 객체지향까지 한 권에 몰아넣

apdui.tistory.com

커리큘럼에 맞추려다 보니

거진 1200페이지 분량의 책을

2주만에 진도를 빼버렸다.

비전공자분들이 꽤 많은 것 같아

다들 어려워하시는 마음에 공감할 틈도 없이,

3주차에서는 기본적인 데이터베이스와 SQL을 배웠다.

Oracle로 수업을 진행하셔서 늘 MySQL만 썼던 나도 재밌게 들었다.

이번에도 역시나 주어진 시간이 많지 않기에

정말 폭풍처럼 진도를 나갔다.

SQLD 자격증을 땄던 것이 4년은 된지라,

생각보다 많은 내용을 까먹었고,

원래도 쿼리문 짜는 건 좋아했어서

3주차 수업은 정말 재밌게 듣고 있다.

Java를 배울 때도 그렇고,

수업이 끝나갈때즈음 간혹 코테 문제를 내주시는데

이거 푸는 맛이 쏠쏠하다.

아주 기초적인 수준임에도

한번씩 헤메는 스스로를 보며

현타가 종종 오긴 하지만..

그렇기에 배우려고 온 것이니 좋은 것 아니겠는가 .. ~

헉슨...쓰면서 깨달았는데

정신없이 살다보니 5월달 회고도 패싱했다

하하..

원래는 주차별로 공부했던 것들이랑

배우는 점, 문제 상황과 우리의 고민, 나의 고민, 타협과 해결 등등

기록할 것들을 잔뜩 가지고 글을 쓰고 싶었지만,

첫 한달은 정말 "학습"의 시간이라

돌이켜볼만한 일이 많이 없다.

대신 그만큼 개인적인 내용이라도 기록하려고

열심히 공부하고 경험하고 있는 것들을

꾸준히 포스팅 중이니,

관심 있는 글이 있다면 한 번 읽어보셔도 좋을 것 같다.

[Part 1] LLM Wiki란 무엇인가

블로그에 글을 열심히 쌓아가도 보면(특히 정보성 블로거일때),공통된 고민을 하게 되는 것 같다.아는게 많아지니 공유하고 싶은, 포스팅하는 글은 늘어나는데,포스트 간 관련이나 연결, 내용

apdui.tistory.com

[Part 2] Obsidian 설치 및 사용법

지난 편에서 우리는 부품 다섯 개를 훑었다. [Part 1] LLM Wiki란 무엇인가블로그에 글을 쌓다 보면 누구나 같은 벽에 부딪힌다. 글은 늘어나는데, 글들이 서로 따로 논다. 3개월 전에 쓴 글과 어제 쓴

apdui.tistory.com

[Part 3] Obsidian에 Claude Code 올리기

지난 편에서 우리는 옵시디언으로 노트 세 개를 손으로 잇고,그래프가 자동으로 그려지는 과정을 확인해보았다. 이제 지난 편에 남겨둔 질문 하나를 답해볼 시간이다. 노트의 개수가 100+여도 수

apdui.tistory.com

[Part 3] Obsidian에 Claude Code 올리기

apdui — Sat, 6 Jun 2026 18:10:12 +0900

지난 편에서 우리는 옵시디언으로 노트 세 개를 손으로 잇고,

그래프가 자동으로 그려지는 과정을 확인해보았다.

이제 지난 편에 남겨둔 질문 하나를 답해볼 시간이다.

노트의 개수가 100+여도 수작업을 계속할 수 있을까?

이번 편에서 우리는 그 답을 찾아볼 것이다.

연결 작업이 기껏해야 [[ ]] 타이핑이라고 생각할 수 있지만

실상은 생각보다 번거로운 과정을 거친다.

그래서 우리는, 어느 문서의 어떤 내용을 대상으로

어떤 키워드를 이용하여 어느 노트와 연결할지를 고민하는

이 일련의 과정 자체를 AI에게 넘겨볼 예정이다.

이를 위해 우리가 사용할 AI Agent는 Claude Code다.

이번 편은 세 단계로 진행된다.

Claude Code 설치
지난 편의 my-wiki 폴더를 LLM Wiki 구조로 수정
자료 하나를 던졌을 때, 위키 페이지 생성 + 링크 연결 확인하기

1단계 — Claude Code 설치

Claude Code는 claude의 AI agent 기능으로,
Pro plan 이상의 사용자만 이용할 수 있는 점 참고 부탁드립니다!

Claude Code는 터미널(명령어를 입력하는 검은 창)에서 돌아가는 도구다.

혹시 어려울까봐 겁먹지 않아도된다. 우리가 칠 명령어는 한 손에 꼽는다.

설치 방법은 claude.com/product/claude-code의 안내를 확인하자.

설치 방식은 시점에 따라 바뀔 수 있으니,

공식 페이지의 최신 안내를 그대로 따르는 게 가장 안전하다.

설치가 끝나면 터미널에서 claude라고 쳤을 때 초기 화면이 뜰 것이다.

만약 claude 명령어를 찾을 수 없다고 뜬다면

설치 과정에 문제가 있었던 것이니 재설치해보자.

여기서 개념을 하나 분명히 하고 넘어가자.

우리는 지금부터 두 개의 도구를 다룰 것이다.

옵시디언
노트를 사람이 보는 창
Claude Code
노트를 AI가 쓰는 손

둘 다 같은 폴더(my-wiki)를 바라보게끔 설정할 것이다.

Claude Code가 폴더에 파일을 만들면, 옵시디언이 그걸 곧바로 보여줄 것이다.

한 폴더를 두 도구가 각자의 방식으로 다루는 것이기 때문에 이 그림이 머릿속에 있어야 한다.

2단계 — 폴더를 LLM Wiki 구조로 바꾸기

이제 my-wiki 폴더를 LLM Wiki의 3계층 구조로 만든다.

raw/
wiki/
schema.md

직접 폴더를 만들 필요는 없다.

터미널에서 my-wiki 폴더로 이동한 뒤 Claude Code를 켜보자.

(아직 Vault 이름을 바꾸지 않았다면, 기본 이름인 "Obsudian Vault"로 되어있을 것이다)

해당 폴더를 우클릭하고 "git bash로 열기"를 클릭하거나,

mac OS 사용자라면 "터미널에서 열기"를 클릭해주자.

* Claude Code를 키려면 window 기준 git bash가 필요하다.

** mac OS의 경우 기본적으로 Linux 환경이기 때문에,

별도의 git 설치 없이 명령어가 사용 가능하다.

폴더를 찾긱가 어렵다면 다음 명령어로도 실행시킬 수 있다.

cd "C:\Users\USER\Documents\Obsidian Vault"
claude

이 폴더를 신뢰합니까? 라는 질문이니 enter 한 번 눌러주자

정상적으로 claude가 켜졌다면, 다음처럼 요청해보자.

이 폴더를 LLM Wiki 구조로 세팅해줘.
원본을 넣을 raw 폴더, 네가 정리한 글을 넣을 wiki 폴더,
그리고 정리 규칙을 담은 schema.md를 만들어줘.
schema.md에는 각 위키 페이지가 어떤 형식이어야 하는지,
페이지끼리 어떻게 [[위키링크]]로 연결할지 규칙을 적어줘.

이제 Claude Code가 폴더와 파일을 만든다. 만들고 나면 my-wiki 안은 이렇게 된다.

my-wiki/
├── raw/          ← 내가 자료를 던져 넣는 곳 (AI는 읽기만)
├── wiki/         ← AI가 정리한 글이 쌓이는 곳
└── schema.md     ← 정리 규칙서

여기서 가장 중요한 파일이 schema.md다.

지난 편에서 "이 규칙 파일이 품질을 좌우한다"고 했던 그거다.

schema.md가 부실하면 AI가 제각각인 형식으로 글을 쏟아내고,

충실하면 일관된 위키가 나온다.

각자의 상황과 취향에 따라 다른 구성이 되겠지만,

내가 사용하고 있는 규칙은 다음과 같다.

type: meta tags:

meta/schema created: 2026-06-06 aliases:

스키마

wiki 규칙

Wiki Schema (정리 규칙서)

이 문서는 이 Wiki의 유일한 규칙 기준점이다.
AI(Claude Code 등)는 raw/의 원본을 읽고, 이 규칙에 따라 wiki/에 페이지를 생성·갱신한다.
사람이든 AI든 새 페이지를 만들 때 헷갈리면 여기로 돌아올 수 있도록 한다.

1. 폴더 구조
my-wiki/
├── raw/        ← 원본 자료를 던져 넣는 곳. AI는 읽기만 하고 절대 수정하지 않는다.
├── wiki/       ← AI가 정리한 위키 페이지가 쌓이는 곳. 모든 출력은 여기로.
└── schema.md   ← 이 규칙서 (루트에 위치)
raw/
입력 전용, 사용자가 사용하는 공간.
PDF·텍스트·메모·링크 등 형식 무관. 비우지 않는다(원본 보관소)

wiki/
출력 전용, AI가 생성·수정하는 영역.
폴더를 더 파지 않고 평평하게 유지하며, 분류는 태그와 [[위키링크]]로 한다

2. 설계 철학

raw → wiki 단방향
raw는 절대 고치지 않는다. 정리 결과는 항상 wiki에 새로 쓰거나 갱신한다

한 페이지 = 한 개념
페이지는 작게 유지한다. 한 raw 자료가 여러 개념을 담고 있으면, 개념 단위로 쪼개 여러 페이지를 만든다

링크 우선, 폴더는 없음
wiki/ 안에서는 폴더로 나누지 않고 [[위키링크]]로 개념을 잇는다

MOC가 목차 역할
폴더 대신 색인 페이지(MOC)로 길을 안내한다

3. 페이지 타입 (type)

모든 wiki 페이지는 frontmatter에 type을 가진다. 3종으로 고정.

type 용도

concept 개념·정의·지식의 본체 (대부분의 페이지)

reference 특정 원본 자료의 요약 (raw 1건에 대응)

moc Map of Content, 여러 페이지를 묶는 색인

4. Frontmatter 표준 (모든 페이지 공통)

페이지 맨 위에 아래 YAML 블록을 둔다.
---
type:                # concept | reference | moc (필수)
tags: []             # 계층 태그 (6번 규칙 참고)
created: 2026-06-06  # 생성일 YYYY-MM-DD
aliases: []          # 동의어·약어·다른 표기 (링크 정확도용)
source:              # reference 타입만: 대응하는 raw 파일명 또는 URL
---
source는 reference 타입에서만 필수.
어떤 원본에서 왔는지 추적용. 예: source: raw/attention-paper.pdf

concept·moc는 source 생략.

5. 페이지 본문 형식

concept 페이지
# 개념명

> 한 줄 정의 (이 개념이 뭔지 한 문장으로)

## 핵심
- 본문. 다른 개념 언급 시 반드시 [[위키링크]].

## 관련 노트
- [[연결된 개념 A]]
- [[연결된 개념 B]]
reference 페이지
# 자료 제목

> 출처: source 필드 참고 / 한 줄 요약

## 요약
- 원본 핵심 내용을 정리. 등장하는 개념은 [[위키링크]]로 연결.

## 관련 노트
- [[이 자료가 다루는 개념]]
moc 페이지
# 주제명 MOC

> 이 주제에 속한 페이지들의 색인

## 페이지 목록
- [[하위 개념 1]]
- [[하위 개념 2]]
6. 링크 규칙

본문에서 다른 개념을 언급하면 무조건 [[개념명]]으로 링크한다.
대상 페이지가 아직 없어도 일단 링크한다(나중에 생성될 자리).

링크 텍스트는 대상 페이지의 제목과 정확히 일치시킨다.
표기가 다르면 대상 페이지의 aliases에 추가하거나 [[제목|보이는 텍스트]] 문법을 쓴다.

모든 concept·reference 페이지는 하단에 "## 관련 노트" 섹션을 두고 핵심 연결을 정리한다.

새 개념 페이지를 만들면, 그 개념이 속한 MOC에 링크를 추가한다.

고아 페이지(아무 데서도 링크되지 않는 페이지)를 만들지 않는다.

7. 태그 규칙 (계층 태그)

태그는 대분류/소분류 형식의 계층 태그로 통일한다.
#topic/llm     #topic/math    #topic/obsidian
#meta/schema   #meta/moc
topic/* : 주제 분야 (페이지 분류의 주축)

meta/* : 관리용 (schema, MOC 등)

8. AI 작업 순서 (raw → wiki)

raw/에서 새 자료 또는 지정된 자료를 읽는다. (raw는 수정 금지)

자료에서 다룰 개념을 식별한다.

개념마다 wiki/에 concept 페이지를 만들거나 갱신한다.

자료 자체의 요약이 필요하면 reference 페이지를 만들고 source에 원본을 기록한다.

본문의 모든 개념 언급을 [[위키링크]]로 연결한다.

관련 MOC를 갱신한다. 없으면 새 MOC를 만든다.

각 페이지에 frontmatter와 "관련 노트" 섹션이 있는지 확인한다.

9. 권장 플러그인 (Obsidian에서 열 때)

플러그인 역할

Dataview frontmatter 기반 자동 목록·대시보드

Templater 타입별 frontmatter 자동 삽입

Dataview 예시— 특정 주제의 개념 목록:
```dataview
LIST
FROM #topic/llm
WHERE type = "concept"
SORT file.name ASC
```
원본 추적 — reference 페이지 모아보기:
```dataview
TABLE source, created
WHERE type = "reference"
SORT created DESC
```
10. 페이지 생성 체크리스트

[ ] frontmatter에 type 있는가?

[ ] reference라면 source 있는가?

[ ] 한 페이지가 한 개념인가?

[ ] 언급한 개념을 전부 [[위키링크]]로 연결했는가?

[ ] "관련 노트" 섹션이 있는가?

[ ] 태그가 대분류/소분류 형식인가?

[ ] 어떤 MOC에서든 이 페이지로 도달 가능한가? (고아 아님)

지난 편에서 생성했던 노트 3개와 별개로,

Claude Code가 생성한

schema 파일과 함께

raw/ 와 wiki/ 폴더를 확인할 수 있다.

3단계 — 자료를 던져 넣고 정리시키기

raw/ 폴더에 자료를 하나 넣고, AI에게 정리를 시킨다.

이 "자료를 넣고 위키로 녹여내는" 과정을 보통 인제스트(ingest, 집어삼키기)라고 부른다.

자료는 뭐든 상관없다. md 파일에 넣을 수 있는 텍스트이기만 하면

웹 기사를 마크다운으로 저장한 파일도, PDF 논문, 강의 노트, 유튜브 자막을 복사한 텍스트도 괜찮다.

연습으로는 관심 있는 주제의 글 하나를 마크다운으로 저장해 raw/ 안에 넣어보자.

웹 기사를 깔끔한 마크다운으로 바꾸는 데는 Obsidian Web Clipper라는 브라우저 확장이 편하다.

웹페이지에서 버튼 한 번이면 본문만 추려 마크다운으로 저장해준다.

obsidian.md/clipper에서 받을 수 있다.

자료를 raw/에 넣었으면, Claude Code에게 작업을 할당해보자.

저번에는 추가했던 노트들을 적절히 수정해서 raw/로 옮겨보자.

이번 금융공학 스터디의 주제인 핀테크와 오픈뱅킹에 대한 개념을 추가해보겠다.

#핀테크

핀테크란 Finance + Technology의 합성어
기술을 활용해 금융 서비스를 혁신하는 산업 전반을 의미하는 것.

전통적인 금융 기관이 독점하던 "송금,결제,대출,투자,자산관리,보험" 등을 
테크 기업들이 더 빠르고 편리하게 제공하는 것이 핵심
예를 들어 간편 결제(Toss, 카카오페이, paypal 등..)

전통 금융과의 차이 : 모바일 우선,  UX 중심, 데이터 기반 의사결정과 빠른 개발 주기.

이제 raw 폴더에 내가 추가한 내용을 가지고,

claude code가 작업할 수 있도록 요청을 보내보자.

raw 폴더에 추가된 파일을 읽고, schema.md 규칙에 따라 wiki 폴더에 정리 페이지를 만들어줘.
기존 위키 페이지 중 관련 있는 게 있으면 [[위키링크]]로 연결하고,
새로 다뤄야 할 개념이 있으면 별도 페이지로 분리해줘.

자료를 읽고, 핵심 개념을 추리고, wiki/ 폴더에 .md 페이지를 만들고, 관련 페이지끼리 [[ ]]로 잇는다.

지난 편에서 우리가 수작업으로 하던 것을, AI agent를 이용하여 자동화시킨 것이다.

4단계 — 옵시디언으로 결과 확인

AI가 작업을 마쳤으면 옵시디언으로 돌아가보자.

wiki/ 폴더 안에 새 노트들이 생겨 있을 거다.

열어보면 schema.md에서 정한 형식대로 정리돼 있고, 본문 곳곳에 [[ ]] 링크가 걸려 있다.

그리고 그래프 뷰를 열어보면, AI가 만든 점들이 서로 이어진 모습이 보인다.

schema.md의 의도대로 type과 tag까지 정상적으로 설정된 것을 확인할 수 있다.

자료를 하나 더 넣고 다시 ingest를 시키면, 그래프가 또 자라고, 새 점이 기존 점들과 연결된다.

새로운 노트를 추가해서 정상 동작하는지 확인해보자.

#오픈뱅킹

개념: 은행이 보유한 고객의 금융 데이터를 고객 동의 하에 표준화된 API를 통해 제3자(핀테크 기업 등)에게 개방하는 제도입니다. 핵심은 "내 금융 데이터의 주인은 나(고객)"라는 사상이며, 은행이 데이터를 독점하지 못하게 합니다.
왜 등장했나:

과거에는 한 앱에서 여러 은행 계좌를 통합 조회하려면 각 은행과 개별 제휴가 필요해 사실상 불가능했습니다.
오픈뱅킹은 이를 공동 인프라/API로 표준화해 하나의 앱에서 모든 은행 계좌 조회·이체가 가능하게 만들었습니다.

제공하는 대표 기능:

계좌 정보 조회(AIS, Account Information Service): 잔액, 거래내역 통합 조회
결제 지시(PIS, Payment Initiation Service): 은행 앱을 거치지 않고 직접 이체 지시

자료를 넣을수록 위키가 두꺼워지고, 연결이 촘촘해지고,

그 모든 유지보수를 이제 나 대신 AI가 해줄 것이다.

조금만 자료를 넣어줘도 옵시디언의 그래프 뷰는 다음과 같은 모습을 띄게 된다.

한 걸음 더 — 슬래시 커맨드로 반복 작업 줄이기

새로운 정보를 나의 도서관에 추가할때마다 매번 위의 긴 요청을 타이핑하긴 번거롭다.

그래서 자주 쓰는 작업은 슬래시 커맨드로 묶어두면 편하다.

Claude Code에서 /명령어 형태로 부르는 단축 명령이다.

LLM Wiki를 쓰는 사람들이 흔히 만드는 세 가지가 있으니 참고해보자.

/ingest — raw/의 새 자료를 읽어 wiki/에 정리하고 링크를 거는 작업
/query — 인터넷이 아니라 내 위키 전체를 근거로 질문에 답하게 하는 작업
/lint — 위키를 점검해 깨진 링크, 오래된 내용, 아무와도 안 이어진 외톨이 페이지를 찾아내는 작업

이 커맨드들을 어떻게 만드는지는 Claude Code 공식 문서의 슬래시 커맨드 안내를 따르면 된다.

지금 단계에서 중요한 건 명령어 만드는 법이 아니라,

"이런 반복 작업을 단축어로 묶을 수 있구나!"라는 감각이다.

ingest로 채우고 > query로 꺼내 쓰고 > lint로 정돈하기

이 셋이 LLM Wiki를 굴리는 일상 루틴이 된다.

특히 /query가 강력한 기능으로 꼽히는데, 위키가 충분히 쌓였다면

"내가 정리해둔 내용 중에 복리와 BigDecimal이 어떻게 연결되는지 설명해줘" 같은 질문에

AI가 인터넷의 일반론이 아닌, 내 위키만을 근거로 답한다.

내가 모으고 정리한 내 지식으로 답변 받는 것이 일반 챗봇과 가장 다른 점이다.

Part 3 정리

Claude Code는 터미널에서 도는, 내 폴더의 파일을 직접 읽고 쓰는 AI 도구다.
옵시디언이 "보는 창"이라면 Claude Code는 "쓰는 손"이다. 둘은 같은 my-wiki 폴더를 바라본다.
AI에게 부탁해 폴더를 raw/ + wiki/ + schema.md 구조로 세팅했다.
schema.md가 품질의 핵심이다.
평소 자기 정리 템플릿을 규칙으로 넣으면 위키가 내 방식대로 나온다.
raw/에 자료를 넣고 ingest시키면, AI가 위키 페이지를 만들고 [[ ]]로 연결한다.
자주 쓰는 작업은 /ingest /query /lint 슬래시 커맨드로 묶는다. 이 셋이 일상 루틴.
/query는 내 위키만 근거로 답한다. 일반 챗봇과의 결정적 차이.

여기까지 오면 "AI가 정리해주는 지식 베이스"는 완성이다.

하지만 이건 아직 내 컴퓨터 안에만 있다.

우리의 최종 목표를 다시 기억해보자. 이 지식 지도를 블로그에 띄우는 것!

다음 편부터 그 그래프를 블로그용으로 꺼내는 작업에 들어가보자.

먼저 "그래프가 사실은 어떤 데이터인가"를 뜯어보는 것에서 시작해보자.

[Part 2] Obsidian 설치 및 사용법

apdui — Sat, 6 Jun 2026 02:09:20 +0900

지난 편에서 우리는 부품 다섯 개를 훑었다.

[Part 1] LLM Wiki란 무엇인가

블로그에 글을 쌓다 보면 누구나 같은 벽에 부딪힌다. 글은 늘어나는데, 글들이 서로 따로 논다. 3개월 전에 쓴 글과 어제 쓴 글이 사실 같은 주제인데, 나도 방문자도 그걸 모르고 지나간다. 글

apdui.tistory.com

마크다운, 옵시디언, 그래프, LLM Wiki, Claude Code.

이번 편에서는 연결(링크 위키)를 통해 그래프를 만들어 볼 것이다.

이번 편은 실습 시간이다.

옵시디언을 깔고, 손수 노트를 만들고, 그래프가 그려지는 순간을 확인해보자.

지금 실습하는 내용은 추후 Claude Code가 자동으로 수행할 내용이지만,

직접적인 경험을 통해 AI가 정확히 어떤 일들을 대신 수행하는지 이해를 돕기 위함이다.

1단계 — 옵시디언 설치하기

먼저 obsidian.md에 접속해 설치해주자.

설치 경로는 추천 경로(C:)를 사용하였다.

설치하고 옵시디언을 처음 실행하면

"Create new vault(새 볼트 만들기)" 같은 버튼이 보일 거다.

지난 편에서 말한 그 볼트, 노트를 담을 폴더를 만들라는 뜻이다.

2026, March 23 릴리즈 기준으로 "빠른 시작" 버튼이 생겼다.
해당 버튼을 누르면 2단계인 vault 만들기를 진행할 필요 없이,
바로 새로운 링크를 만들 수 있다.

2단계 — 볼트 만들기 (Quick Start 적용 시 패스)

"Create new vault"를 누르면 두 가지를 묻는다. 볼트 이름과 위치다.

Vault name(볼트 이름): my-wiki라고 하자.
Location(위치): 내 컴퓨터에서 찾기 쉬운 곳. 바탕화면이나 문서 폴더면 충분하다.

"Create New Vault"를 누르면 끝이다.

그래도 방금 무슨 일이 일어났는지 짚고 가자.

방금 설정한 경로에 my-wiki라는 폴더 하나가 생겼을 것이다.

지금은 비어 있지만, 앞으로 우리가 만들 모든 노트(.md 파일)는 전부 이 폴더 안에 쌓일 것이다.

옵시디언은 이 폴더를 들여다보는 창(window)이라고 생각하자.

저번에도 말했지만, 노션과 다르게 옵시디언은

로컬 폴더에 있는 .md 파일들을 관리하므로

실제 폴더와 파일이 생성된 것을 바로 확인할 수 있다.

3단계 — 첫 노트 세 개 만들기

이제 노트를 직접 만들어보자.

처음에 vault를 만들면(혹은 quick start를 눌렀거나)

"환영합니다" 라는 노트가 있을 것이다.

기본 노트로서 자동 생성된 것이니 해당 노트의 제목과 내용을 수정해보자.

아니면 왼쪽 위의 새 노트 아이콘(또는 Ctrl/Cmd + N)을 눌러도 빈 노트가 생긴다.

마찬가지로 제목을 적고 본문을 쓰면 된다.

일단은 연습용으로 서로 관련된 노트 세 개를 만들자.

주제는 아무거나 좋지만, 연결을 만들어야 그래프가 보이니까

여기서는 일부러 서로 이어질 만한 주제를 선정해보자.

그래도 기왕이면 공부 중인 금융 도메인 주제로 잡아보았다.

노트 1 — 제목: 복리

# 복리 (옵시디언 업데이트 이후 제목 칸이 따로 생겨서, 첫 번째 줄에 "#" 없이 제목을 입력하면 된다) 

원금에 붙은 이자가 다시 원금이 되어, 그 위에 또 이자가 붙는 구조.
시간이 길어질수록 단리와의 격차가 폭발적으로 벌어진다.

이자를 계산할 때는 [[BigDecimal]]을 써야 오차가 없다.
대출 상환 계획을 세울 때 쓰는 [[PMT 공식]]도 복리 개념 위에 서 있다.

노트 2 — 제목: BigDecimal

# BigDecimal

소수점 계산에서 오차 없이 정확한 값을 다루기 위한 자료형.
돈 계산에 double을 쓰면 미세한 오차가 쌓여 금액이 틀어진다.

[[복리]] 이자 계산처럼 정확성이 생명인 금융 로직에서 필수다.

노트 3 — 제목: PMT 공식

# PMT 공식

매달 갚아야 할 원리금 균등 상환액을 구하는 공식.
대출 원금, 이자율, 기간을 넣으면 매달 낼 금액이 나온다.

이 공식의 바탕에는 [[복리]] 개념이 깔려 있고,
실제 계산은 [[BigDecimal]]로 해야 안전하다.

여기서 핵심은 본문 속 [[ ]]다.

복리 노트 안에 [[BigDecimal]]이라고 썼다.

이게 지난 편에서 말한 위키링크다.

"이 노트는 BigDecimal 노트와 연결된다"는 선언인 것!

환영합니다 노트는 기본 시작 노트이니, 필요한 노트 내용으로 수정해주자!

4단계 — 연결이 살아 있는지 확인하기

노트 세 개를 다 만들었으면, 복리 노트로 돌아가 본문의 [[BigDecimal]] 글자를 눌러보자.

BigDecimal 노트로 이동한다. 방금 만든 연결이 실제로 작동하는 거다.

그리고 화면 오른쪽 패널(더보기? 버튼)에 "문서 내 백링크(Backlinks)"라는 게 보일 거다.

해당 옵션을 선택하면 다음과 같이 "링크된 언급"들이 보이게 된다.

BigDecimal 노트를 열어보면

"이 노트를 가리키는 노트들" 목록에 복리와 PMT 공식이 떠 있다.

내가 BigDecimal 노트에서 아무것도 안 했는데도,

다른 노트들이 이쪽을 가리킨다는 걸 옵시디언이 자동으로 추적한 거다.

이 양방향 추적이 매우매우 중요하다.

나는 한 방향으로 링크를 걸었을 뿐인데(복리 → BigDecimal),

옵시디언은 반대 방향(BigDecimal ← 복리)도 알고 있다.

이게 쌓이면 관계망이 되고,

이러한 관계망은 곧 그래프로서 우리가 확인할 수 있다..

5단계 — 그래프 뷰

이제 이번 편의 하이라이트다!

왼쪽 사이드바에서 그래프 뷰 아이콘(여러 점이 이어진 모양)을 누른다.

단축키는 명령 팔레트(Ctrl/Cmd + P)에서 "Graph view"를 검색해도 된다.

화면에 그래프가 뜨고, 점 세 개가 선으로 이어져 있는 것을 확인할 수 있다.

복리, BigDecimal, PMT 공식 세 노드가, 우리가 건 위키링크대로 연결된 모습이다.

마우스로 점을 드래고해보면 다른 점들이 따라 움직이고, 점을 누르면 해당 노트가 열린다.

실제 화면이 아닌, 이해를 돕기 위한 이미지입니다

지금까지 한 것처럼 새 노트 이자율을 하나 더 만들고,

본문에 [[복리]]만 한 줄 넣어보자.

그래프로 돌아가면 점이 네 개로 늘고, 새 점이 복리에 붙는다.

자료를 더할수록 그래프가 자랄 것이다.

글이 100개면 100개의 점이, 그 사이의 모든 연결이 거미줄처럼 펼쳐지는 것!

방금까지 우리가 한 일을 되짚어보자.
우리는 그래프를 "직접 그리지는" 않았다.

그냥 노트를 쓰고 [[ ]]로 몇 군데 이었을 뿐인데,
그래프는 그 연결로부터 자동으로 만들어진 것이다.
이게 지난 편에서 말한 "연결이 그래프가 된다"의 실체다.
여기까지가 옵시디언의 기초편이라 할 수 있겠다.

잠깐, 여기서 문제 !

방금 우리는 손으로 .md 파일을 작성하며 [[ ]]를 이용해 링크들을 걸어주었다.

노트 세 개의 작성이라 당연히 어려운 일은 아니었다.

그렇지만? 지난 편의 그 질문을 다시 꺼내보자.

만약 노트가 3개가 아니라 300개라면?

새 글을 쓸 때마다 "이게 어떤 옛 글과 관련 있더라..?"를

일일이 떠올려 [[ ]]를 거는 일을, 과연 꾸준히 할 수 있을까?

내용이 바뀐 옛 글은 누가 고치고, 서로 모순되는 두 글은 누가 찾아낼까?

바로 이 지점에서 작심삼일이 시작되는 것이고,

해당 지점을 LLM Wiki가 해결해줄 수 있는 것이다.

그래서 이번 시리즈를 Obisidian + LLM wiki로 잡은 것이기도 하고.

raw/ 폴더에 자료를 던져 넣으면,

Claude Code가 읽고, 정리하고, 이 [[ ]] 연결을 알아서 걸어준다.

우리가 방금 손으로 한 그 작업을, AI가 대신 하는 거다.

그러니 이번 편의 손작업은 당연히 헛수고가 아니었다.

AI가 뭘 대신 해주는지 몸으로 알아야, 다음 편에서 Claude Code가 일하는 걸 볼 때

"아, 내가 하던 그걸 자동으로 하는구나"가 보일 것이니까!

Part 2 정리

옵시디언을 설치하고 볼트(폴더) my-wiki를 만들었다. 노트는 전부 이 폴더 안의 .md 파일로 실재한다.
노트 본문에 [[다른 노트 제목]]을 쓰면 위키링크가 걸린다.
옵시디언은 링크를 양방향으로 추적한다(백링크). 한 방향만 걸어도 반대 방향을 안다.
그래프 뷰는 이 연결을 자동으로 그린 그림이다. 우리가 그래프를 그린 게 아니라, 연결이 그래프가 됐다.
자료를 더할수록 그래프는 자란다. 하지만 손으로 거는 건 노트가 많아지면 무너진다.
이러한 한계가 다음 편 LLM Wiki의 출발점!

다음 편에서는 Claude Code를 설치하고(아직 설치가 안되어있다면)

이 my-wiki 폴더를 raw/와 wiki/ 구조로 바꾼 뒤,

자료 하나를 던져 넣어 AI가 위키 페이지를 만들고 링크까지 거는 과정을 처음부터 끝까지 실습해보자.

우리가 방금 손으로 한 일을 AI가 어떻게 하는지, 그 차이를 직접 비교하는 시간이 될 것이다.

[Part 1] LLM Wiki란 무엇인가

apdui — Mon, 1 Jun 2026 22:51:44 +0900

블로그에 글을 열심히 쌓아가도 보면

(특히 정보성 블로거일때),

공통된 고민을 하게 되는 것 같다.
아는게 많아지니 공유하고 싶은, 포스팅하는 글은 늘어나는데,

포스트 간 관련이나 연결, 내용 수정 등의 유지보수가 참 어렵다.

6개월 전에 쓴 글과 어제 쓴 글이 사실 굉장히 연관된 주제인데,

여차하면 작성자인 나도, 방문자도 그러한 사실을 모르고 지나가기 십상이다.
글이 늘어나면 늘어날수록 이러한 현상은 특히 더 심해지는 것 같다.

그래서 더 많은 정보가 내 블로그 이곳저곳에 널부러지기 전에

최근에 나온 방법론인 LLM wiki와 Obsidian을 활용하여

앞선 문제를 어떻게든 해결해보고자 한다.

이번 시리즈에서 우리는 정보의 외딴섬들을 다리로 이어볼 것이다.

어떤 결과물이 나올지 아직은 잘 모르겠지만,

당장 생각하는 최종 결과물은 두 가지다.

하나는 AI가 알아서 정리하고 연결해주는 지식 베이스.
자료를 던져 넣으면 AI가 읽고, 핵심을 추리고, 기존 지식과 엮어주기를 기대한다.

다른 하나는 그 연결을 블로그 온보딩(히어로 섹션)에 띄울 인터랙티브 그래프.
방문자가 점 하나를 누르면 그 글로 이동하고,
이어진 선을 따라 관련 글로 흘러가는 살아 있는 지식 지도다.

전자는 큰 무리가 없을 것 같지만,
후자는 Tistory 스킨 정책 상 어려울 확률이 높다.
구현 자체가 어려운 건 아니지만,
내 로컬 데이터를 계속해서 크롤링해오는 것이 어려워서
직접 데이터를 계속 업데이트 해줘야 하는 번거로움이 따를 것으로 예상된다...

일단은 뭔가 거창해 보이지만 사실 부품은 단순하다.
이번 편에서는 그 부품들이 각각 뭔지만 먼저 짚어보자.

필요한 개념은 5개다. 가장 작은 것부터 봐보자.

부품 1 — 마크다운: 모든 것의 바탕

먼저 가장 밑바닥 부품. 마크다운(Markdown)은 글에 서식을 입히는 아주 단순한 문법이다.
워드처럼 버튼을 누르는 게 아니라, 기호 몇 개로 서식을 표현한다.

# 큰 제목
## 중간 제목
**굵은 글씨**
- 목록 항목
[링크 글자](주소)

이게 거의 전부다. #은 제목, **로 감싸면 굵게, -는 목록.

이렇게 쓴 글을 .md 확장자로 저장한 게 마크다운 파일이다.

왜 하필 마크다운인가하면, 2가지 이유가 있다.

메모장으로도 열리는 그냥 텍스트라 어떤 프로그램에도 묶이지 않고,

무엇보다 AI가 가장 잘 읽고 쓰는 형식이다.

우리가 다룰 모든 글, 모든 노트, 모든 위키 페이지는 결국 이 .md 파일 하나를 가리킨다.

앞으로 "노트"라고 하든 "글"이라고 하든 "위키 페이지"라고 하든,

이번 시리즈에서 언급하는 "글"은 전부 마크다운 파일일 것이다. 아마도?

부품 2 — 옵시디언: 노트를 보고 잇는 창

옵시디언(Obsidian)은 한마디로

내 컴퓨터에 저장된 마크다운 파일들을 보고, 편집하고, 서로 연결해주는 노트 앱이다.

여기서 초보자가 가장 헷갈리는 지점을 먼저 짚어보자.

옵시디언은 노트를 자기네 서버가 아니라 내 컴퓨터 폴더에 저장한다.

노션(Notion)을 써봤다면 이 차이가 크게 다가올 것이다.

노션은 내 글이 노션 회사 서버에 있어서, 서비스가 사라지면 접근이 막힌다.

옵시디언은 그냥 내 폴더 안에 .md 파일이 쌓일 뿐이다.

옵시디언을 지워도 파일은 남고, 메모장으로도 열린다.

데이터의 주인이 나라는 뜻이다!

용어는 세 개만 알면 된다.

Vault(볼트, 금고)
노트를 모아둔 폴더 하나. 거창한 건 아니고 그냥 디렉토리(=폴더)다.
내문서/my-wiki 폴더를 볼트로 지정하면, 그 안의 모든 .md 파일이 한 묶음이 된다.
Note(노트)
그 안의 .md 파일 하나. 글 한 편.
위키링크(Wikilink)
노트끼리 잇는 문법
본문에 [[복리]]라고 쓰면 "복리.md" 파일로 가는 링크가 생긴다.

이 위키링크가 옵시디언의 심장이다.

웹페이지의 링크(<a href>)와 같은 역할인데 문법이 훨씬 짧다.

글을 쓰다가 다른 글을 언급할 때 그 제목을 대괄호 두 개로 감싸면 두 글이 이어진다.

이 연결이 쌓이면 다음 부품으로 넘어간다.

부품 3 — 그래프: 연결을 눈으로 보는 그림

노트들을 위키링크로 잇다 보면 "무엇이 무엇과 연결됐는가"라는 관계망이 생긴다.

옵시디언은 이걸 그래프 뷰라는 화면으로 그려준다.

각 노트는 점(노드, node), 각 연결은 선(엣지, edge)이다.

컴퓨터를 전공했다면 자료구조 시간에 배운 그래프(정점과 간선)를 떠올리면 정확하다.

화면에 떠다니는 동그라미와 선은 그 그래프 자료구조를 그림으로 옮긴 것뿐이다.

전공 지식이 없어도 괜찮다. 지하철 노선도를 생각하자. 역이 노드, 역과 역을 잇는 선로가 엣지다.

이 그래프가 왜 쓸모가 있을까?

한눈에 내 지식의 구조가 보이기 때문이다.

어떤 주제가 여러 글과 연결된 허브(중심)인지,

아무와도 안 이어진 외톨이 글이 있는지,

비슷한 글끼리 무리(클러스터)를 이루는지가 직관적으로 드러난다.

그리고 우리의 최종 목표가 바로 이거다.
이 그래프를 내 티스토리 온보딩에도 띄우는 것..!

방문자가 점을 눌러 글로 이동하고,

선을 따라 관련 글로 탐험하는 경험을 제공하고 싶다.

실제로 구현단계에 들어가면 디자인 쪽이 훨씬 어려울 것 같긴하다..

부품 4 — LLM Wiki : AI agent가 사서가 되는 패턴

이제 핵심 개념이다.

지금까지 부품(마크다운, 옵시디언, 그래프)은 전부 "그릇"이었다면

그 그릇을 채우고 정리하는 일을 누가 하느냐, 이게 LLM Wiki의 이야기다.

이 패턴은 2026년 4월,

AI 연구자 안드레 카파시(Andrej Karpathy)가 공개하면서 퍼졌다.

발상은 단순하지만 강력하다.

먼저 기존 방식의 문제부터 보자.

노션이든 옵시디언이든, 지금까지 노트 정리는 전부 사람 몫이었다.

새 글을 쓰면 관련된 옛 글을 찾아 링크를 걸고,

내용이 바뀌면 옛 글을 고치고, 모순되는 내용은 표시하고.

이 유지보수의 부담이 늘 사람에게 떨어졌고,

그래서 대부분 작심삼일로 끝났다.

이론은 아름다웠지만 손이 너무 많이 가서,

꾸준히 하는 것은 참 어려운 듯 보였다.

이때 카파시가 한 일은 이 역할을 뒤집은 거다.

사람은 자료(입력)와 질문만 맡고,

위키를 정리하고 연결하고 유지보수하는 일은 AI가 한다.

이 한 번의 뒤집기가 전부인 것!

구조는 폴더 세 개가 끝이다.

raw/ 폴더 (원본 보관소, 절대 안 바뀜)
내가 읽은/읽을 모든 원본을 넣는 곳. 웹 기사, PDF 논문, 강의 노트, 유튜브 자막 등.
AI는 여기서 읽기만 하고 절대 손대지 않는다. 이게 "진짜 원본"이라는 기준점이어야 하기 때문이다.
나중에 "원문이 실제로 뭐라고 했지?"를 확인하려면 손대지 않은 원본이 필요하다.
wiki/ 폴더 (AI가 정리한 결과물)
AI가 raw의 자료를 읽고 종합해서 만든, 내가 실제로 읽을 정리본.
개념별 페이지와 그것들을 잇는 위키링크가 여기 들어간다.
schema.md (규칙서)
"각 페이지는 어떤 형식으로, 태그는 어떻게, 연결은 어떻게 만들어라"를 AI에게 알려주는 규칙 파일.
이 패턴을 오래 써본 사람들은 입을 모아 말한다.
이 규칙 파일이 품질을 좌우하는 가장 중요한 파일이라고.

부품 5 — Claude Code: 실제로 일하는 손

마지막 부품. 위에서 "AI가 정리한다"고 했는데,

그 AI가 내 컴퓨터의 폴더와 파일을 직접 만지려면 연결 고리가 필요하다.

그 역할이 Claude Code다.

Claude Code는 내 컴퓨터의 파일을 직접 읽고 쓸 수 있는 AI 도구다.

보통 챗봇에 PDF를 올리고 질문하면, 대화가 끝나는 순간 AI는 다 잊는다.

다음 날 같은 PDF를 또 올려야 한다. Claude Code는 다르다.

내 폴더에 직접 접근해서 raw/의 자료를 읽고, wiki/에 파일을 만들고,

위키링크로 연결하는 실제 작업을 한다. 복사-붙여넣기가 없다.

여기서 LLM Wiki가 일반 챗봇과 결정적으로 갈리는 지점이 드러난다.

일반 챗봇은 매번 처음부터 다시 시작한다.

어제 AI와 나눴던 대화가 오늘로 이어지지 않았다..

반면 LLM Wiki는 한 번 정리한 결과가 파일로 남아 쌓인다.

자료를 넣을수록 위키가 두꺼워지고, 연결이 촘촘해지고, 점점 똑똑해진다.

복리처럼 불어나는 지식인 셈.

흔히 듣는 RAG나 노트북LM 같은 도구도 내 자료로 답을 준다.

하지만 그것들은 질문할 때마다 원본을 다시 뒤져서 답을 만든다.

정리 결과가 남지 않는다. LLM Wiki는 정리를 미리 한 번 해서 결과물로 남겨둔다.

이 차이가 가장 크다. 이 비교는 뒤 파트에서 더 깊이 알아보자.

전체 그림 한 장으로 보기

부품 다섯 개를 봤다. 이게 어떻게 맞물리는지 한 흐름으로 잇는다.

[내가 모은 자료]
      ↓  raw/ 폴더에 넣기
[Claude Code가 읽고 정리]
      ↓  schema.md 규칙대로
[wiki/ 폴더의 .md 노트들 — [[위키링크]]로 연결됨]
      ↓  옵시디언으로 열어서 봄
[옵시디언 그래프 — 내 작업용 지도]
      ↓  연결 관계를 데이터로 추출
[블로그용 인터랙티브 그래프 — 방문자용 지도]

마크다운은 모든 글의 바탕 형식,

옵시디언은 그 글을 보고 잇는 창,

그래프는 연결을 눈으로 보는 그림,

LLM Wiki는 AI가 정리를 맡는 방식,

Claude Code는 그 AI가 실제로 파일을 만지는 손.

다음 편 예고

다음 편부터는 손을 움직여보자. 실습 시간이다!

옵시디언을 설치하고, 볼트를 만들고, 노트 몇 개를 직접 위키링크로 이어서

그래프가 그려지는 걸 두 눈으로 확인할 예정이다.

"연결이 그래프가 된다"를 글로만 읽어본 것을,

직접 체험으로 바꾸는 단계로 넘어가보자

type	용도
concept	개념·정의·지식의 본체 (대부분의 페이지)
reference	특정 원본 자료의 요약 (raw 1건에 대응)
moc	Map of Content, 여러 페이지를 묶는 색인

플러그인	역할
Dataview	frontmatter 기반 자동 목록·대시보드
Templater	타입별 frontmatter 자동 삽입