- 작성자
많은 도구, 없는 규칙
Notion, Slack, Figma, Google Drive. 스타트업이라면 대부분 쓰는 도구들입니다. 저희도 당연히 다 쓰고 있었습니다.
문제는 그 다음이었습니다. "이거 어디에 올려야 해?", "그 문서 Notion에 있어? Slack에 있어?", "아 그거 Google Drive에 있는데... 폴더가 어디더라" 같은 질문이 계속 반복됐습니다.
도구가 많으니까 오히려 더 헷갈렸습니다. 각 도구의 역할이 명확하지 않으니, 같은 정보가 여러 곳에 흩어져 있었죠. 어떤 게 최신인지 알 수가 없었고, 결국 같은 질문을 반복하느라 시간을 낭비했습니다.
새로운 팀원이 오면 더 혼란스러웠습니다. "문서는 어디서 봐요?"라는 질문에 "일단 Notion 보시고... Slack도 좀 뒤져보시고... Google Drive에도 있을 수 있어요..."라고 답할 수밖에 없었죠.
정리하기로 했습니다
도구를 바꾸는 게 답이 아니었습니다. 이미 충분히 좋은 도구들이었죠.
문제는 역할 정의가 없었다는 겁니다. 어떤 도구에 어떤 정보를 넣을지, 도구들이 어떻게 연결되는지 정해진 게 없었습니다.
그래서 전체 워크플로우를 구조화하기로 했습니다.
전체 구조
복잡해 보이지만, 핵심은 단순합니다.
Internal Tools → Output → External
이 흐름만 명확하면 됩니다. 각 단계에서 어떤 도구가 어떤 역할을 하는지 정의했습니다.
그리고 AI 활용을 염두에 둔 구조입니다. Output 단계에서 Markdown 문서가 쌓이면, 이걸 AI가 참조할 수 있습니다. Claude Code나 MCP로 연결하면 내부 지식 검색, 콘텐츠 생성, 기획 아이디어 제안 같은 것들이 가능해지죠.
Internal Tools: 각 도구의 역할
도구마다 명확한 역할을 정했습니다. 모든 도구는 데스크톱 앱을 설치해서 알람을 받을 수 있도록 했습니다.
Notion: 문서 허브
역할: 모든 정보의 중심
Notion은 다른 도구들의 링크가 모이는 허브입니다. 직접 작성하는 문서도 있지만, 더 중요한 건 다른 도구들의 링크를 체계적으로 모아두는 것이죠.
- 회의록, 기획서, 프로젝트 문서
- Figma 디자인 링크
- Google Drive 파일 링크
- Slack 중요 스레드 링크
"이거 어디 있어?"의 답은 항상 Notion입니다. 실제 파일이 다른 곳에 있더라도, Notion에서 찾을 수 있어야 합니다.
Slack: 실시간 커뮤니케이션
역할: 흘러가는 대화
Slack은 실시간 논의와 빠른 의사결정에 씁니다. 하지만 Slack은 흘러가는 대화이기 때문에, 기록으로 남겨야 할 내용은 반드시 Notion으로 옮깁니다.
중요한 결정이 Slack에서 나왔다면:
- 해당 스레드 링크를 Notion에 저장
- 또는 내용을 정리해서 Notion 문서로 작성
Slack에서만 존재하는 중요 정보는 없어야 합니다.
Figma: 디자인 협업
역할: UI/UX 디자인과 시각 자료
Figma는 디자인 작업과 큰 화면으로 봐야 하는 시각 자료에 씁니다. 파일 전체가 아니라 특정 오브젝트로 바로 이동하는 링크를 공유하도록 했습니다.
Google Drive: Notion 보완
역할: Notion이 약한 부분 담당
Google Drive는 Notion이 잘 못하는 것들만 담당합니다:
- 스프레드시트 (계산, 데이터 추적)
- 대용량 파일 (PDF, 동영상, 이미지 벌크)
Google Drive에 올라간 파일도 Notion에서 찾을 수 있도록 링크를 연결해둡니다.
Linear 도입: 프로젝트 관리의 분리
원래는 Notion으로 프로젝트 관리도 했습니다. 데이터베이스 기능이 강력하니까 잘 될 줄 알았죠.
그런데 문제가 있었습니다.
너무 자유로운 구조
Notion은 아무거나 변경할 수 있습니다. 이게 장점이자 단점이었죠.
팀원 한 명이 실수로 뭔가 수정하면 전체 구조가 망가졌습니다. 자유도가 높다는 건 관리가 어렵다는 뜻이기도 합니다.
시스템을 직접 만들어야 했습니다
데이터베이스 구조 설계, 관계(Relation) 설정, 필터와 뷰 제작...
할 일 관리보다 시스템 만드는 데 시간을 더 썼습니다.
유지보수의 어려움
살짝만 실수해도 만들어놓은 구조가 깨졌습니다. 복구하는 데 시간이 더 걸렸고, 새로운 기능이 필요하면 또 시간을 써야 했습니다.
팀원이 많아질수록 더 불안정해졌습니다.
Linear로 전환
그래서 Linear를 도입했습니다.
프로젝트 관리에 특화된 도구는 그 역할에 맡기는 게 맞습니다. Linear는 프로젝트 관리만 잘하면 됩니다. Notion은 문서 허브 역할에 집중하면 되고요.
Linear에서는:
- Task: 기능 개발, 문서 작성 등 할 일 관리
- Bug Tracker: Product에서 발생한 버그, CS 관리
Internal Tools에서 나온 Result(회의록, 기획서 등)는 Linear 태스크에 링크로 첨부해서 씁니다.
Output: 결과물이 만들어지는 곳
Internal Tools에서 작업한 결과물이 실제로 형태를 갖추는 단계입니다.
Markdown: 버전 관리되는 문서
핵심 문서는 Markdown으로 작성하고 GitHub으로 버전 관리합니다.
이런 문서들이 해당됩니다:
- 핵심 가치와 비전
- 피처별 공식 로드맵
- 제품 철학, 디자인 원칙
- 유저 대상 가이드, 튜토리얼
왜 Markdown인가요?
- 버전 관리가 정확함: Git으로 모든 변경 이력 추적
- 실수로 수정 안 됨: GitHub에 넣을 때 PR 리뷰가 필요함
- 다른 도구와 연동 쉬움: 어디서든 읽을 수 있는 텍스트 파일
- 퍼블리싱 가능: Docusaurus, GitBook 같은 도구로 문서 사이트 자동 배포
Dev: 개발 작업
코드 작성, 기능 구현, 버그 수정 등 실제 개발 작업입니다. GitHub에서 코드 관리하고, PR 리뷰를 통해 품질을 관리합니다.
AI 활용
워크플로우를 정리한 이유 중 하나가 AI 활용입니다.
AI에게 컨텍스트를 주기가 쉬워집니다.
Claude Code를 쓸 때, MCP로 도구들을 연결할 때, AI가 참조할 수 있는 정보가 정리되어 있으니까 훨씬 효과적으로 활용할 수 있었습니다.
Markdown 문서가 쌓이면:
- 내부 지식 검색: 문서 기반으로 질문에 답변, 신규 입사자 온보딩
- Visual Content: 문서 기반으로 이미지, 영상 생성
- Planning: AI가 문서를 분석해서 기획 아이디어 제안
- Idea: 브레인스토밍, 새로운 기능 제안
Notion도 MCP를 연결하면 AI가 접근할 수 있습니다. 하지만 Markdown 파일이 로컬에 있으면 별도 연동 없이 바로 컨텍스트로 쓸 수 있고, 검색 속도도 빠릅니다. 파일 시스템에 모든 문서가 있다는 건 AI 활용에서 확실히 유리합니다.
정보가 정리되어 있어야 AI도 제대로 활용할 수 있습니다.
정리하고 나서 달라진 것
"이거 어디에 올려?"가 사라졌습니다
역할이 명확하니까 고민할 필요가 없습니다. 예전에는 문서 하나 찾으려고 Slack 뒤지고, Notion 뒤지고, Google Drive까지 확인해야 했습니다. 이제는 Notion만 보면 됩니다. 문서 찾는 시간이 절반 이상 줄었습니다.
온보딩이 빨라졌습니다
새 팀원한테 "Notion부터 보세요"라고 하면 끝입니다. 예전에는 각 도구 사용법을 따로 설명하고, 어디에 뭐가 있는지 알려주느라 시간을 많이 썼습니다.
새 도구 도입이 쉬워졌습니다
구조가 있으니까 새 도구가 들어와도 어디에 배치할지 명확합니다. "이 도구는 Internal Tools에서 이 역할을 담당한다"고 정의하면 됩니다.
결론
도구를 바꾸는 게 아닙니다. 이미 쓰고 있는 도구들의 역할을 명확히 하고, 흐름을 만드는 것입니다.
이게 끝이 아닙니다. 더 효율적인 방법이 있으면 계속 바꿀 겁니다. 새로운 도구가 나오면 도입할 수도 있고, 지금 쓰는 도구를 빼거나 역할을 바꿀 수도 있습니다.
중요한 건 구조가 있다는 것 자체입니다. 기준점이 있으니까 바꾸기도 쉽습니다.