옵시디언 연결형 회의록 (업무 누락을 줄인 기록)

회의록을 쓰고도 업무가 빠지는 일이 계속 생겼습니다. 회의 중에는 분명히 누가 무엇을 하기로 했는데, 3일 뒤 다시 보면 “이게 확정된 건가, 그냥 의견이었나?”가 헷갈렸습니다. 특히 재택근무 환경에서는 Google Meet 회의가 끝난 뒤 Slack 대화가 이어지고, 일부 결정은 Notion 문서에 반영되면서 회의록 하나만 봐서는 흐름을 따라가기 어려웠습니다. 그래서 2026년 3월 3일부터 2026년 4월 16일까지 45일 동안 Obsidian으로 연결형 회의록을 실험했습니다.

업무 환경은 Windows 11 노트북, Obsidian, Slack, Google Meet, Notion 조합이었습니다. 이 기간 동안 작성한 회의록은 총 31개였고, 연결한 프로젝트 노트는 14개, 사람별 노트는 9개였습니다. 회의록에서 나온 액션아이템은 총 86개였고, 그중 완료된 액션아이템은 72개, 미완료
액션아이템은 14개였습니다. 실험 전에는 회의 후 업무 누락이 월 8건 정도였는데, 구조를 바꾼 뒤 월 3건으로 줄었습니다.

기존 회의록에서 가장 불편했던 점

기존에는 회의록을 날짜별 문서로만 저장했습니다. 예를 들어 “2026-03-05 주간회의”, “2026-03-12 콘텐츠회의”처럼 제목을 붙이고, 안건과 대화 내용을 순서대로 적었습니다. 겉으로 보기에는 정리된 것처럼 보였지만, 실제 업무에서는 문제가 많았습니다. 프로젝트별로 이전 결정사항을 찾으려면 여러 회의록을 열어봐야 했고, 특정 담당자가 맡은 일을 보려면 검색을 반복해야 했습니다.

회의록 검색 시간도 길었습니다. 기존 회의록에서 특정 결정사항을 찾는 데 평균 2분 30초가 걸렸습니다. 특히 “랜딩페이지 문구 확정”, “이미지 교체 담당자”, “배포 전 검토 일정”처럼 여러 회의에 걸친 내용은 검색어를 바꿔가며 찾아야 했습니다. 연결형 회의록으로 바꾼 뒤에는 평균 검색 시간이 41초로 줄었습니다. 숫자로 보니 체감보다 차이가 더 컸습니다.

처음 실패: 모든 것을 링크로 만들었다

처음 Obsidian을 쓰기 시작했을 때 가장 크게 한 실수는 모든 사람 이름과 모든 안건을 링크로 만든 것입니다. 회의록에 나온 사람 이름 5명, 프로젝트명 4개, 안건 8개, 도구명 3개를 전부 [[링크]]로 만들었습니다. 처음 1주일 만에 노트가 60개 가까이 늘었고, 정작 다시 열어보는 노트는 많지 않았습니다.

예를 들어 한 번만 언급된 “임시 배너 문구”, “테스트용 시트”, “회의 중 나온 참고 링크”까지 모두 별도 노트로 만들었습니다. 그 결과 그래프 뷰는 복잡해졌지만 업무 추적은 더 쉬워지지 않았습니다. 링크가 많아질수록 중요한 링크와 중요하지 않은 링크가 섞였습니다. 이때 깨달은 것은 옵시디언 연결형 회의록은 모든 것을 연결하는 방식이 아니라, 다음 행동과 관련된 것만 연결해야 한다는 점이었습니다.

두 번째 실패: 결정사항과 의견을 섞어 적었다

또 다른 실패는 결정사항과 의견을 구분하지 않은 것입니다. 3월 11일 콘텐츠 운영 회의에서 “4월 캠페인 페이지는 A안으로 가는 게 좋겠다”는 의견이 나왔고, 회의 후반에는 “다만 디자인 검토 후 확정하자”는 말도 있었습니다. 그런데 회의록에는 “A안 진행”이라고만 적었습니다. 4일 뒤 다시 보니 이게 확정인지 검토 의견인지 헷갈렸습니다.

결국 Slack에서 다시 확인했고, 디자인 담당자와 기획 담당자에게 같은 질문을 반복했습니다. 이 문제로 회의록 수정에 22분이 추가로 들었습니다. 이후부터는 회의록을 결정사항, 액션아이템, 보류사항, 참조문서 4개 블록으로 고정했습니다. 의견은 결정사항에 넣지 않고, 확정되지 않은 내용은 반드시 보류사항에 넣었습니다.

개선 후 고정한 회의록 구조

3주 차부터 회의록 템플릿을 고정했습니다. 실제 회의록 템플릿은 날짜, 참석자, 결정사항, 할 일, 담당자, 마감일, 관련 노트를 반드시 포함했습니다. 회의록마다 형식이 다르면 나중에 검색할 때 다시 읽어야 했기 때문에, 구조를 반복 가능한 형태로 바꾸는 것이 중요했습니다.

# 2026-03-18 콘텐츠 회의

날짜: 2026-03-18
참석자: [[김기획]], [[박디자인]], [[이개발]]
관련 프로젝트: [[랜딩페이지개선]], [[4월콘텐츠캠페인]]

## 결정사항
- 랜딩페이지 상단 문구는 B안으로 확정
- 1차 검토 기준일은 2026-03-22로 설정

## 액션아이템
- [ ] 문구 B안 Google Docs 반영 / 담당자: [[김기획]] / 마감일: 2026-03-19
- [ ] 배너 시안 2종 업로드 / 담당자: [[박디자인]] / 마감일: 2026-03-21

## 보류사항
- CTA 버튼 색상은 A/B 테스트 결과 확인 후 결정

## 참조문서
- [[랜딩페이지문구검토]]
- Notion 캠페인 운영안 링크

이 템플릿을 쓰면서 회의록을 읽는 방식이 달라졌습니다. 회의 전체 흐름보다 먼저 결정사항과 액션아이템을 확인하게 됐고, 보류사항이 따로 보이니 확정되지 않은 일을 확정된 것처럼 처리하는 실수가 줄었습니다.

연결형 회의록 전후 비교표

항목	기존 회의록	연결형 회의록	문제점	개선 후 효과	주의할 점
검색 속도	날짜별 문서에서 직접 검색	프로젝트·사람 노트로 연결	관련 회의록을 여러 개 열어야 함	검색 시간 2분 30초에서 41초로 감소	링크를 너무 많이 만들면 오히려 복잡해짐
업무 누락	회의 후 할 일을 따로 기억	액션아이템 블록에 담당자와 마감일 기록	담당자 없는 할 일이 남음	월 8건에서 월 3건으로 감소	마감일 없는 액션아이템은 추적이 어려움
링크 관리	링크 없음 또는 단순 문서 링크	프로젝트 노트 14개, 사람별 노트 9개 연결	회의별 흐름이 끊김	관련 프로젝트 이력 추적 쉬워짐	모든 단어를 링크로 만들 필요는 없음
결정사항 구분	의견과 결정이 섞임	결정사항·보류사항 분리	무엇이 확정인지 헷갈림	재확인 질문 감소	회의 끝나기 전 결정 여부를 확인해야 함
유지 가능성	형식이 회의마다 다름	4개 블록 구조 고정	나중에 읽는 시간이 길어짐	31개 회의록을 같은 방식으로 관리	템플릿이 길어지면 작성 부담이 커짐

태그를 27개에서 8개로 줄인 이유

처음에는 태그도 많이 만들었습니다. #회의, #결정, #보류, #디자인, #개발, #콘텐츠, #긴급, #검토, #공유, #액션아이템처럼 27개까지 늘었습니다. 문제는 태그가 많아질수록 일관성이 떨어진다는 점이었습니다. 같은 회의록에 어떤 날은 #콘텐츠를 붙이고, 어떤 날은 #캠페인을 붙였습니다. 나중에 찾을 때 오히려 헷갈렸습니다.

최종적으로 유지한 태그는 8개였습니다. #회의록, #결정필요, #액션아이템, #보류, #프로젝트, #사람, #검토중, #완료만 남겼습니다. 태그는 분류용으로 최소화하고, 실제 연결은 프로젝트 노트와 사람별 노트로 처리했습니다. 이 방식이 유지하기 훨씬 쉬웠습니다.

액션아이템 86개를 추적하면서 달라진 점

45일 동안 회의록에서 나온 액션아이템은 총 86개였습니다. 이 중 완료된 액션아이템은 72개, 미완료 액션아이템은 14개였습니다. 이전에는 회의록에 할 일을 적어도 실제로 완료 여부를 다시 보지 않았습니다. 하지만 Obsidian에서 담당자 노트와 프로젝트 노트에 연결하니 미완료 항목을 다시 확인하기 쉬웠습니다.

예를 들어 [[랜딩페이지개선]] 프로젝트 노트에는 관련 회의록 6개와 액션아이템 18개를 연결했습니다. 이 프로젝트 노트만 열면 어떤 회의에서 어떤 결정이 났고, 어떤 일이 남았는지 확인할 수 있었습니다. 사람별 노트도 도움이 됐습니다. [[김기획]] 노트에는 그 사람이 담당한 액션아이템이 모였고, 마감일이 지난 항목을 확인하기 쉬웠습니다.

회의 후 업무 누락이 줄어든 실제 이유

업무 누락이 월 8건에서 월 3건으로 줄어든 이유는 회의록을 더 예쁘게 써서가 아니었습니다. 누락될 만한 항목을 회의록 구조 안에서 강제로 드러냈기 때문입니다. 액션아이템에는 담당자와 마감일을 반드시 넣었고, 담당자가 없으면 “담당자 미정”이라고 적었습니다. 마감일이 없으면 “마감일 미정”이라고 적고, 회의 후 24시간 안에 Slack에서 확인했습니다.

이전에는 “다음 주에 확인” 같은 표현이 많았습니다. 개선 후에는 “2026-03-27 17시까지 1차 확인”처럼 날짜와 시간을 적었습니다. 이 작은 차이 때문에 후속 업무가 훨씬 선명해졌습니다. 회의록은 기록물이 아니라 다음 행동을 놓치지 않게 만드는 업무 장치에 가까웠습니다.

검색 시간이 41초로 줄어든 방식

회의록 검색 시간은 평균 2분 30초에서 41초로 줄었습니다. 가장 큰 이유는 날짜가 아니라 프로젝트 기준으로 접근할 수 있게 된 것입니다. 예전에는 “그 결정이 어느 회의에서 나왔더라?”부터 생각해야 했습니다. 이제는 [[4월콘텐츠캠페인]] 노트를 열고 연결된 회의록만 보면 됐습니다.

사람별 노트도 검색 시간을 줄였습니다. 특정 담당자의 미완료 업무를 찾을 때 Slack 검색과 회의록 검색을 반복하지 않아도 됐습니다. 사람별 노트에는 관련 회의록 링크, 맡은 액션아이템, 마감일, 완료 여부만 남겼습니다. 처음에는 사람별 노트를 15개 만들었지만 실제로 자주 쓰는 사람은 9명이었기 때문에 9개만 유지했습니다.

연결형 회의록에서 링크를 만드는 기준

45일 동안 가장 많이 바뀐 기준은 링크 생성 기준이었습니다. 처음에는 링크가 많을수록 좋다고 생각했지만, 실제로는 다시 열 가능성이 있는 노트만 링크로 만드는 것이 좋았습니다. 최종 기준은 세 가지였습니다. 첫째, 2회 이상 등장하는 프로젝트명. 둘째, 액션아이템 담당자. 셋째, 결정사항과 직접 연결된 참조문서였습니다.

반대로 회의 중 한 번 언급된 일반 단어, 확정되지 않은 아이디어, 단순 참고 링크는 별도 노트로 만들지 않았습니다. 참조문서 블록에만 링크를 남겼습니다. 이 기준을 정한 뒤 노트가 불필요하게 늘어나는 문제가 줄었습니다.

실제로 유지한 회의록 작성 흐름

회의 중에는 모든 말을 다 적지 않았습니다. 회의 중에는 결정 후보, 담당자, 날짜, 보류된 쟁점만 빠르게 적었습니다. 회의가 끝난 뒤 10분 안에 결정사항과 액션아이템을 정리했습니다. 24시간 안에 프로젝트 노트와 사람별 노트에 링크를 추가했습니다. 이 과정을 지키지 않으면 회의록은 다시 단순 메모로 돌아갔습니다.

회의록 하나를 정리하는 데 걸린 시간은 초반 평균 17분이었고, 템플릿을 고정한 뒤에는 평균 9분 정도로 줄었습니다. 특히 반복 회의에서는 이전 회의록을 복사해 구조만 유지하면 됐기 때문에 부담이 줄었습니다.

최종 결론: 옵시디언 연결형 회의록은 모든 것을 링크하는 방식이 아니었다

2026년 3월 3일부터 4월 16일까지 45일 동안 Obsidian으로 회의록 31개를 작성하면서 느낀 가장 큰 변화는 회의 후 후속 업무가 보이기 시작했다는 점입니다. 연결한 프로젝트 노트는 14개, 사람별 노트는 9개였고, 액션아이템 86개 중 72개를 완료했습니다. 미완료 액션아이템 14개도 어디에 남아 있는지 추적할 수 있었습니다.

실험 전에는 회의 후 업무 누락이 월 8건 정도였지만, 개선 후에는 월 3건으로 줄었습니다. 회의록 검색 시간도 평균 2분 30초에서 41초로 줄었습니다. 처음에는 태그 27개와 과도한 링크 때문에 오히려 복잡했지만, 최종적으로 태그를 8개로 줄이고 결정사항, 액션아이템, 보류사항, 참조문서 4개 블록으로 구조를 고정하면서 유지 가능성이 높아졌습니다.

결론적으로 옵시디언 연결형 회의록은 모든 것을 링크하는 방식이 아니었습니다. 다음 행동을 놓치지 않게 연결하는 구조였습니다. 회의록에서 중요한 것은 회의 내용을 많이 적는 것이 아니라, 무엇이 결정됐고, 누가 무엇을 언제까지 해야 하며, 무엇이 아직 보류인지 분명히 남기는 것이었습니다.

옵시디언 회의록 템플릿 체크리스트

회의록 제목에 날짜와 회의명을 함께 적었는가?
참석자를 사람별 노트와 연결했는가?
프로젝트명이 2회 이상 반복되면 프로젝트 노트로 연결했는가?
결정사항과 의견을 분리해서 적었는가?
액션아이템마다 담당자와 마감일이 있는가?
담당자나 마감일이 없으면 미정으로 표시했는가?
보류사항을 결정사항과 섞지 않았는가?
참조문서에는 Notion, Slack, Google Meet 관련 링크를 남겼는가?
회의 후 10분 안에 결정사항과 할 일을 정리했는가?
24시간 안에 프로젝트 노트와 사람별 노트에 회의록을 연결했는가?
태그를 너무 많이 만들지 않고 최소 기준만 유지하는가?
다시 열 가능성이 낮은 단어까지 링크로 만들지 않았는가?