미뤄두기만 하던 공부를, 아예 자동화해보기로 했다!
회사 프로젝트를 개발하다 보면 꼭 한 번씩 제가 제대로 공부하지 못한 개념들을 만나게 됩니다.
아직 제가 깊게 써보지 않은 WKWebView 나 Swift Concurrency, 비동기 처리 방식 같은 것들이 코드 안에 나타나고
그럴 때 저는 보통 “아, 대충 이런 식으로 동작하겠구나” 하고 코드의 흐름만 추상적으로 파악한 채 넘어가는 경우가 많았죠
그 결과는 ㅠ..
버그를 수정한 줄 알았는데 다른쪽에서 버그가 터지거나 아예 그 버그가 재현되는 경우로 이어졌어요
신입의 방패는 한계가 있어요.. 여러분 이게 한두번 되면 윗 사람이 저에게 신뢰가 떨어지게 되죠.
버그를 수정하라고 일줬는데 일을 만드는 거위가 되었으니 ㅎㅎ
혹시라도 해결했다 쳐도 결국 그 개념은
정확히는 모르지만 일단 해결했잖아? 한잔해~
저는 이런 식으로 놓친 개념들이 점점 쌓이고 있다는 게 조금 불안했습니다
주니어 개발자로서 결국 성장하려면, “돌아가게 만드는 것”에서 멈추지 않고 왜 이렇게 동작하는지 이해하는 단계까지 가야 한다고 생각했기 때문입니다.
예전에는 google 검색을 하고 사람들의 질문을 통해 공부했겠지만 대 AI 시대.,, 그런 시간까지 아껴줘야죠
그래서 만든 스킬은!! ㄷㄱㄷㄱ
내 프로젝트 안에서 이 기술이 어떻게 쓰이고 있는지 분석하고, 외부 자료를 모으고,
복습 가능한 학습 자료를 만들고, Obsidian에 다시 꺼내보기 쉬운 형태로 정리해주는 흐름이 한 번에 된다면,
적어도 “나중에 공부해야지” 상태로 끝나지는 않겠다고 생각했습니다.
또한 더 나아가서 다른 개발자들분들도 각자 맡은 업무가 다르다보니 이 스킬을 사용한다면 더 빨리 코드 리딩이 되지않을까 도움이 되고자 만들게 되었습니다
왜 만들었나?
스킬을 만들기 전에 제가 진짜 원했던 걸 정리해봤습니다. 돌아보니 딱 네 가지였습니다
첫째, 내 코드 기준으로 이해하기
공식 문서를 읽으면 API 설명은 알 수 있습니다.
그런데 정작 제가 궁금했던 건 그런 정보보다도 “이 기술이 지금 우리 프로젝트에서는 어떻게 쓰이고 있는가” 였습니다.
예제를 보는 것과 실제 회사 프로젝트 코드를 보는 건 완전히 다르니까요.
문서만 읽어서는 “이론”은 알 수 있어도, 내가 지금 보고 있는 코드가 왜 이렇게 작성되어 있는지는 잘 안 보일 때가 많았습니다.
그래서 첫 번째 니즈는 외부의 일반적인 설명이 아니라, 내 코드 기준으로 이해할 수 있어야 한다 는 것이었습니다.
둘째, 외부 자료를 한 번에 모으기
공식 문서, 블로그, WWDC, 오픈소스 예제까지 하나하나 찾는 것도 꽤 큰 일이었습니다.
하지만 막상 너무 많아지면 오히려 다 못 읽고 흐지부지되는 경우가 많았습니다.
북마크만 늘어나고, 탭만 쌓이고, 정작 머릿속에 남는 건 별로 없더라고요.
그래서 제가 원한 건 무조건 많은 자료가 아니라, 적당히 신뢰할 수 있는 자료를 골라서 한 번에 모아주는 것 이었습니다.
즉, 자료 수집 자체를 줄이는 게 아니라 자료를 선별하는 피로를 줄이고 싶었습니다
셋째, 같은 실수가 반복되지 않게
개발하다 보면 대부분의 문제는 이미 누군가 한 번쯤 겪어본 문제인 경우가 많습니다.
어떤 라이브러리를 쓰든, 어떤 기술을 쓰든 먼저 부딪혀본 “선배 개발자들”이 남겨놓은 트러블슈팅이 꼭 있더라고요.
그런데 이미 알려진 이슈나 흔한 함정이 있는데도 그걸 모르고 똑같이 삽질하게 되면 시간이 너무 아까웠습니다
그래서 단순히 개념 정리만 하는 게 아니라, 자주 나오는 문제와 그 원인, 해결 방식까지 같이 모아야 한다 고 생각했습니다.
넷째, Obsidian에 남기기
저는 “나중에 정리해야지” 하면서 노트 앱만 열어두고 정작 정리는 안 하는 스타일이었습니다.
그래서 나중에 정리하는 게 아니라, 처음부터 정리된 상태로 결과물이 나오게 만들고 싶었습니다.
그래서 Deep Study는 먼저 프로젝트 코드 안에서 해당 기술의 사용 맥락을 먼저 봅니다.
그다음 외부 자료를 모아 이해를 보강 -> 자주 나오는 트러블슈팅이나 복습 포인트까지 정리 -> Obsidian에 바로 남길 수 있는 형태로 정리 순으로 이어집니다
결과물도 그냥 긴 문서 하나는 아니게 만들기
처음엔 저도 그냥 하나의 긴 문서로 끝내려고 했습니다.
그런데 그렇게 만들면 한 번은 읽어도, 다시 보기 너무 힘들더라고요.
그래서 결과물은 멀티노트 구조로 바꿨습니다.
주제를 8~12개의 노트로 나누고,
각 노트에
- 핵심 개념
- Mermaid 다이어그램
- 실제 코드
- 트러블슈팅
- 복습 포인트
를 넣고, [[위키링크]]로 서로 연결되도록 만들었습니다.
이렇게 해두니까 훨씬 좋았습니다.
한 번에 다 읽지 않아도 되고,
나중에 특정 개념만 다시 꺼내보기도 쉽고,
Obsidian 그래프 뷰로 보면 전체 주제 구조도 한눈에 들어옵니다.
단일 파일일 때보다 훨씬 “공부 자료” 같아졌습니다.
만들면서 가장 많이 부딪힌 부분
특히 가장 손이 많이 갔던 건 NotebookLM 연동 부분이었습니다.
외부 자료를 넣으면 항상 깔끔하게 학습 자료가 만들어질 줄 알았는데, 실제로는 그렇지 않았습니다.
가장 먼저 겪은 문제는 소스 추가 실패였습니다.
NotebookLM에 URL을 넣으면 크롤링해서 자료를 가져오는데, Medium이나 일부 유료 사이트처럼 접근이 까다로운 페이지는 꽤 자주 실패했습니다.
처음엔 이 문제 때문에 전체 흐름이 자꾸 끊겼습니다.
이 부분은 발상을 조금 바꿔서 해결했습니다. “모든 자료가 완벽하게 들어가야 한다”가 아니라,
최소한 학습 가능한 개수만 확보되면 된다는 기준으로 바꾼 겁니다.
그래서 실패한 소스 수만큼 다시 웹 검색을 돌려 대체할 수 있는 URL을 찾아 넣도록 설계했습니다.
두 번째는 시각 자료 생성 실패였습니다.
인포그래픽이나 마인드맵은 텍스트 자료보다 실패율이 더 높았고, 처음에는 이것 때문에 전체 워크플로우가 중단되기도 했습니다.
이건 아예 우선순위를 다시 정해서 해결했습니다.
시각 자료는 있으면 좋지만, 없어도 학습 자체는 가능해야 했습니다.
그래서 인포그래픽이나 마인드맵 생성이 실패하더라도 스터디 가이드, 퀴즈, 노트 생성은 그대로 진행되도록 흐름을 바꿨습니다.
결국 만들면서 가장 크게 느낀 건 하나였습니다.
이런 스킬은 “잘 될 때”보다 “중간에 실패해도 끝까지 굴러가게 만드는 것”이 훨씬 중요하다는 점이었습니다.
그래서 Deep Study를 만들면서는 기능을 추가하는 것만큼이나 중간에 어디서 실패할 수 있는지 보고
그걸 우회하거나 건너뛸 수 있게 만드는 쪽에 많은 시간을 썼습니다.
“Deep”의 기준!
처음에는 저도 결과물을 받아보고 조금 아쉬웠습니다.
형식은 그럴듯했지만, 읽어보면 어디선가 본 듯한 설명이 많았습니다.
예를 들어 “WKWebView는 멀티프로세스로 동작합니다”
같은 문장은 틀린 말은 아니지만, 이 정도로는 공부가 됐다는 느낌이 잘 들지 않았습니다.
그래서 그때부터는 “어디까지를 Deep이라고 볼 것인가” 를 따로 정해서 스킬 안에 기준으로 넣기 시작했습니다.
제가 잡은 기준은 대략 이랬습니다.
첫째, 정의만 말하고 끝내지 않기
“무엇이다”에서 멈추는 게 아니라, 왜 그렇게 동작하는지, 어떤 구조 때문에 그런지까지 설명해야 했습니다.
둘째, 실무 맥락이 함께 있어야 하기
이론 설명만 있는 게 아니라, 실제로 어떤 상황에서 쓰이고 어떤 문제를 만나기 쉬운지도 같이 들어가야 했습니다.
셋째, 코드와 연결되어야 하기
개념 설명만 잔뜩 있는 노트보다, 실제 코드 예시와 함께 봤을 때 훨씬 이해가 잘 되기 때문에 기본 사용 예시와 실무에 가까운 코드가 함께 들어가도록 했습니다.
넷째, 트러블슈팅이 포함되어야 하기
많은 경우 진짜 공부가 되는 순간은 개념을 읽을 때보다 문제를 해결할 때이기 때문에, 자주 나오는 버그나 실수 포인트, 그 원인과 해결 방식도 같이 정리하도록 했습니다.
그래서 최종적으로는 노트 하나를 만들 때도 단순 요약이 아니라,
- 핵심 개념 설명
- 구조나 동작 원리
- 코드 예시
- 실무 포인트
- 자주 나오는 문제와 해결 방식
결국 Deep Study에서 말하는 “Deep”은
어려운 말을 길게 쓰는 게 아니라,
나중에 다시 봤을 때 ‘아, 왜 이게 이렇게 돌아가는지’가 떠오를 정도로 맥락까지 남기는 것에 더 가까웠습니다.
그리고 이 기준을 잡고 나서, 결과물의 방향도 조금 더 분명해졌습니다.
단순히 정보를 많이 모으는 게 아니라, 누가 보느냐에 따라 깊이도 달라져야 한다고 생각했습니다.
주니어 입장에서는
- 이 개념이 왜 필요한지
- 어떤 흐름으로 이해해야 하는지
- 먼저 알아야 할 선수 지식이 뭔지
같은 설명이 먼저 필요할 수 있습니다.
반대로 경험이 많은 개발자라면
기초 설명보다도
- 내부 동작
- 설계 이유
- 소스 레벨 구현
- 실무 트러블슈팅
같은 쪽이 더 궁금할 수 있습니다.
그래서 Deep Study는 처음 실행할 때
사용자의 경험 수준과 플랫폼, 언어를 한 번 받아두고
그에 맞게 결과물의 톤과 깊이를 조절하도록 구성했습니다.
플랫폼과 언어도 같은 이유로 받습니다.
다음은 언어를 받습니다.
진짜 중요한 이유가 알고리즘, 자료구조 책을 사서 보면 다 JAVA, Python으로 되어있어 swift 등 원하는 언어로 공부하기가 힘들었죠.
결국 중요한 건 이거였습니다.
모든 사람에게 같은 공부 자료를 주는 게 아니라,
지금 이 사람이 이해하기 쉬운 깊이와 예시로 바꿔주는 것.
GitHub 플러그인으로 배포하기
자 이제 잘 만든(?) 이 스킬을 다른 사람들에게도 도움이 되엇으면 했습니다. 저와 같이 헤매고 있는 주니어 중생들을 위해..ㅎ
claude plugin add sunhofficial/deep-study이거만 해주세요
마무리
혹시 저처럼
“이 개념, 언젠가 공부해야지…”
상태의 기술이 쌓여가고 있다면,
한 번 써보셔도 재밌을 것 같습니다.
개선사항이나 원하는 니즈가 있으시면 댓글에 남겨주시면 업데이트 하겠습니다!
GitHub - sunhofficial/deep-study: One command. 10+ interconnected Obsidian notes. From zero to deep understanding. Claude Code s
One command. 10+ interconnected Obsidian notes. From zero to deep understanding. Claude Code skill for deep research with NotebookLM integration. - sunhofficial/deep-study
github.com