brunch

매거진 I am TOOLER

You can make anything
by writing

C.S.Lewis

by 박상권 May 13. 2024

노션으로 업무 흐름 관리하기

노션 템플릿, 더 이상 쓰지 마세요. 

3년 전쯤에 제가 알고 있는 노션 팁들을 정리해서 글을 작성했습니다. 그때 당시에는 이 글이 이렇게까지 많은 분들의 관심을 받을 줄은 몰랐습니다. 감사하게도 많은 분들이 유용하게 참고하시는 것 같아 기쁜 마음입니다. 그리고 정말 오랜만에 노션 사용에 있어 알려드리면 좋을 내용을 정리하게 되어 글을 작성하려고 합니다. 


https://brunch.co.kr/@p3tree784/72






노션으로 업무 흐름 관리하기


노션에 사용에 있어서 많은 분들이 개인 노트용으로 사용하시기도 하지만, 그 진가는 협업 툴로 사용했을 때 발휘됩니다. 특히, 노션은 자유도가 높기 때문에 조직마다 가진 특정한 업무 흐름을 시각화하고 관리하기에 매우 용이합니다. 저는 여러 회사를 거치면서 여러 가지 방식으로 이 업무 흐름을 노션으로 정리하여 팀의 생산성을 높여왔습니다. 사실 제가 주변에서 노션을 잘 쓴다는 소리를 들었던 이유의 9할은 이 업무 흐름 관리에 있다고 해도 과언이 아닌데요. 최근에는 이 덕분에 업무 효율화 프로젝트 외주를 따로 의뢰받기도 했습니다. 그래서 이번에는 이 노션이란 툴을 이용해 업무 흐름을 시각화하고 생산성을 높이는 방법에 대해 소개해드리려고 합니다.




템플릿을 쓰지 말 것

 

제가 노션의 활용법에 대해 알려드리려고 했을 때 가장 첫 번째로 말씀드리는 것 중 하나는 절대 템플릿을 사용하지 말라는 것입니다. 많은 분들이 아시다시피 노션에는 다른 유저들이 만들어서 배포하는 여러 가지 템플릿이 있습니다. 경우에 따라서 스스로를 노션 크리에이터라고 말하며 이 템플릿을 판매하는 분들도 계십니다. 참으로 감사한 분들이지만, 저는 개인적으로 노션을 사용하려고 하는 분들께 템플릿을 쓰라고 권하지 않습니다. 


이는 비단 노션이란 툴에만 적용되는 이야기는 아닙니다. 과거에 파워포인트를 정말 잘 쓰시는 고수 분께 강의를 들은 적이 있습니다. 그분의 가르침 역시 파워포인트를 사용할 때 템플릿을 절대 이용하지 말라는 것이었습니다. 그 이유인즉슨 다른 사람이 만들어놓은 디자인(발표 흐름)에 내가 발표할 내용을 끼워 맞춰야 되기 때문인데요. 그렇기 때문에 PPT를 만들 때 곧장 파워포인트를 켜서 디자인을 할 게 아니라, 각 장표에 들어갈 내용을 어떤 흐름으로 전달할지에 대한 계획부터 세우라고 말합니다.


그러니 노션도 마찬가지입니다. 우리 팀 또는 우리 조직이 관리하려는 데이터를 정의하지 않은 채, 어떤 구조로 시각화하고 관리할지를 계획하지 않은 채, 템플릿부터 찾는 것은 무의미합니다. 그렇게 여러분이 찾은 템플릿은 오히려 방해가 될 확률이 높습니다. 그래서 대부분 템플릿을 사용하는 유저들이 처음에는 만족하다가 나중에 실제로 사용하게 되면 조직의 상황과 맞지 않아 버려지는 경우가 많습니다. 이를 막기 위해선 먼저 능동적으로 조직의 데이터를 설계하는 것이 필요합니다.



본질을 이해하는 사람들은 극소수입니다. 대부분은 이미 정해진 '레시피'를 따르기만 할 뿐, 그 속의 원리를 이해하려 하지 않아요.

- 짐 켈러(엔지니어, 반도체의 전설) -


 


조직의 업무 흐름 파악하기


위에서 말했듯 노션을 통한 업무 시각화, 업무 흐름을 관리하려면 먼저 우리 조직의 업무 흐름부터 파악을 해야 합니다. 먼저, 빈 종이나 화이트보드로 가서 조직이 가치를 발생시키고 유저에게 전달하는 큰 흐름을 나열해 봅시다. 

VOD 강의 업체의 가치 흐름

위 이미지는 제가 실제로 일했던 VOD 강의 회사에서의 업무 흐름을 표시한 예입니다. 시간이 오래되었고, 간소화하거나 다르게 표시한 부분이 있기 때문에 실제 흐름과는 차이가 있을 수 있습니다. 중요한 것은 이러한 방식으로 우리 조직의 주요 가치 흐름이 어떤 과정을 거쳐서 진행되는지를 먼저 시각화시키는 것입니다. 저는 당시 제작 팀에 속해 있었고 동시에 외주 스튜디오 팀을 관리하고 있었기 때문에 제가 노션으로 관리하게 될 영역은 아래와 같았습니다.



필요한 데이터 파악해서 구조화하기


위와 같이 전체적인 업무 흐름을 파악했다면 관련해서 필요한 데이터가 무엇이 있는지 알아볼 차례입니다. 이때 나의 기준에서 필요한 데이터뿐만 아니라 같이 일을 하는 다른 포지션의 팀원들의 입장에서 필요한 데이터도 함께 파악해야 합니다.  

그리고 이것은 꼭 우리 팀에만 한정되지 않습니다. 위의 데이터 항목들과 도식화된 업무 흐름을 살펴보면 제작 팀과 운영 팀 모두 기획 팀에서 정보를 이관받으며 다음 단계를 진행하며, 그 때문에 서로 상이하게 필요한 데이터도 있지만 겹치는 데이터도 상당수 있다는 것을 알 수 있습니다. 그렇기 때문에 비록 다른 팀이지만 공통의 데이터베이스에서 관리할 수 있다고 보았습니다. 이제 이 내용을 바탕으로 데이터를 어떻게 구조화할지 결정해야 합니다. 저는 아래와 같이 데이터베이스를 나눠보았습니다. 

위 이미지에서 알 수 있듯이 저는 데이터베이스를 4개로 나누었습니다. 두 개는 제작 팀에서 주로 관리하고 나머지 두 개인 배송과 발주업체는 운영 팀에서 주로 관리하게 될 데이터입니다. 


제작 팀이 관리할 데이터는 크게 런칭 전과 런칭 후로 나누어서 데이터를 관리하기로 했습니다. 제가 실제로 데이터를 구조화할 때는 단계를 나누지 않았으나, 실제 운영을 해보니 한 번에 확인해야 할 데이터 양이 많아서 비효율적이었습니다. 그래서 이후에 저런 식으로 런칭 후 추가 강의를 오픈하는 시기의 데이터를 다른 데이터베이스로 나누어 관리하기로 결정했습니다. 


또한 운영 팀에서 관리할 데이터는 크게 배송의 진행 상태를 관리할 수 있는 데이터베이스와 이와 관련된 발주업체 리스트를 또 다른 데이터베이스로 나누었습니다. 엑셀의 VLookup을 생각하시면 이해하시기 편할 겁니다.




노션 데이터베이스로 옮기기


여기까지 모두 완료했다면 이제 드디어 노션으로 이 데이터들을 옮길 차례입니다. 물론 그렇다고 해서 지금 바로 노션 페이지를 만들기 시작하는 것이 아닙니다. 위 데이터베이스 구조들을 노션의 특성에 맞게 다시 한번 정리를 해주어야 합니다. 이를 정리하면 다음과 같습니다. 

위 내용을 보시면 각각의 데이터들을 노션 데이터베이스가 가진 속성으로 분류한 걸 확인할 수 있습니다. 실제로 제가 저렇게 미관상 예쁘게 정리하진 않지만 스프레드시트와 같은 툴을 이용해서 반드시 정리를 한 후에 노션 작업에 들어갑니다. 이렇게 충분한 설계를 해두어야 나중에 헷갈리지 않고 시스템을 구축할 수 있습니다.


그리고 노션의 데이터베이스에는 표(Table), 보드(Board), 타임라인(Timeline), 캘린더(Calendar), 리스트(List), 갤러리(Gallery)와 같이 여러 보기(View)가 제공됩니다. 이러한 업무 흐름 관리 시에는 보통 표나 보드를 주로 사용하게 됩니다. 이때 많은 분들이 칸반과 같은 보드 형태로 관리하곤 합니다. 물론 보드가 친숙하기는 합니다만 이는 데이터베이스를 어떤 식으로 활용할지에 따라 달라질 수 있습니다. 제가 이전에 쓴 글에서 리스트와 표의 차이를 다룬 적 있듯이, 표와 보드의 차이는 페이지를 열지 않고 데이터를 수시로 변경해야 하는지 또는 페이지 내부에서 확인해야 할 정보들이 많은지에 따라 나뉩니다. 저의 경우는 보시다시피 날짜(Date) 속성(Property)이 굉장히 많습니다. 그리고 이러한 날짜 속성들은 특성상 조율 및 변경이 빈번히 일어납니다. 이 때문에 저는 보드가 아닌 표를 기본 보기 설정한 것입니다. 


여기서 참고해야 할 사항 중 하나는 런칭 전, 런칭 후, 배송의 데이터베이스명이 동일하다는 것인데요. 앞서 말했다시피 이 세 데이터베이스는 상당수 겹치는 데이터를 갖고 있고,  모두 '클래스명'이라는 데이터(ID)를 기준으로 정렬됩니다. 그리고 노션에는 '보기 링크 복사(Copy link to view)'라고 해서 같은 데이터베이스이지만 보기(View), 속성(Property), 필터(Filter), 정렬(Sort) 등을 다르게 표시할 수 있는 기능이 있습니다. 저는 이 기능을 사용해서 데이터베이스를 새로 만들지 않고 하나의 데이터베이스를 다른 보기 방식으로 복사해서 활용하려고 합니다.  




세부 설정(보기, 속성, 필터, 정렬 등) 하기 


이제는 각 데이터베이스들의 보기, 속성, 필터, 정렬 등의 세부 설정을 통해 실제적으로 노션에 데이터베이스를 구축하는 과정입니다. 여기서부터는 이해를 돕기 위해서 노션으로 만든 데이터베이스를 예시를 먼저 보여드리면서 설명하겠습니다. 

먼저 위 두 개의 표는 설계한 대로 제작한 런칭 전/런칭 후의 데이터베이스 모습입니다. 이때 특이사항이 있다면 런칭 전 데이터베이스에는 필터로 '대기' '제작 중'만 노출되도록 설정되어 있습니다. 그리고 런칭 후 데이터베이스에는 필터로 '런칭 완료'만 노출되도록 설정했습니다. 이를 통해 '런칭 전 표'에서 런칭 완료 처리를 하면 자동으로 '런칭 후 표'로 이동하게 되어 있습니다. 


그리고 데이터베이스 제목을 보면 모두 꺾은선 표시가 되어 있습니다. 이 표시는 지금 보이는 데이터베이스가 원본 데이터베이스가 아니라 '보기 링크 복사(Copy link to view)'로 가져온 데이터베이스라는 것을 말해줍니다. 이 데이터베이스는 원본 데이터베이스와 연동되어 있기 때문에 속성값들을 변경하면 원본 데이터베이스의 속성값들도 변하게 됩니다. 하지만 이 데이터베이스 보기에서 설정해 놓은 필터, 정렬, 속성(노출)은 유지가 됩니다. 또한 이렇게 링크로 복사된 표는 삭제하더라도 원본 데이터베이스가 있기 때문에 데이터가 삭제되거나 하지 않습니다. 

여기서 조금 더 세부적으로 설정을 해줍니다. 추가 챕터까지 모두 오픈이 완료된 상태를 '오픈 완료'로 구분했고, 오픈 완료가 된 것들은 런칭 후 표에서 보기(View)를 추가로 설정하여 따로 아카이브 할 수 있게 하였습니다(취소/보류도 마찬가지로 설정했습니다). 이렇게 한 데는 이유가 있습니다. 현재는 데이터 개수가 적어서 불편함이 없지만 시간이 지나게 되면 오픈 완료된 데이터가 한없이 길게 아래로 이어지게 될 겁니다. 이러한 완료 데이터가 진행 중인 데이터와 섞여 들어가면 관리하기가 어렵고, 페이지 자체가 느려지기도 합니다. 그러므로 이렇게 보기 설정을 따로 나누어서 완료된 것들만 모아두는 것입니다. 

그리고 그 아래에는 이 데이터베이스를 링크 복사하여 캘린더 보기로 붙여주었습니다. 이를 통해 캘린더 상태에서 일정들을 파악할 수 있습니다. 지금까지 설명한 4개의 데이터베이스 표들은 모두 제작 팀이 관리하는 제작 보드 페이지에서 볼 수 있게끔 해두었습니다. 이를 통해 알 수 있는 것은 동일한 데이터베이스라 하더라도 보기, 속성, 필터, 정렬을 어떻게 세부적으로 조정하느냐에 따라서 유용하게 사용할 수 있다는 것입니다. 


다음은 운영 팀에서 배송 데이터베이스입니다. 데이터베이스 제목에서 알 수 있듯이 이 데이터베이스도 제작 팀에서 사용하는 데이터베이스와 동일한 데이터베이스를 사용했다는 것을 알 수 있습니다. 노출하는 속성만 다르게 설정했을 뿐이죠. 이를 통해 운영 팀에서는 굳이 별도의 데이터베이스를 만들 필요가 없고, 기획 팀에서도 각각 제작 팀, 운영 팀에 데이터를 이관할 때 두 번 일을 하지 않아도 됩니다. 

그리고 이 배송 표 아래에는 발주업체 리스트 표를 같이 붙여두었습니다. 처음 설계했던 대로 '발주업체명'이라는 공통의 데이터를 기준으로 배송 표와 발주업체 리스트를 연결해 두었습니다. 이는 노션에서 제공하고 있는 관계형(Relation)이란 기능을 이용한 것입니다. 이 덕분에 배송 표에서 발주업체의 세부 정보를 매칭시킬 필요가 없어졌습니다. 앞서 제작 표에 있던 외주 스튜디오 속성 또한 스튜디오 개수가 일정 이상 넘어간다거나 하면 이처럼 관계형으로 연결해서 헷갈리지 않게 관리할 수 있습니다.


위에 설명한 것들을 도식화해서 정리하면 위 이미지와 같습니다. 속성은 별도로 표시하지 않았지만 원본 데이터를 기준으로 세부 설정을 다르게 해서 노션 페이지를 나눴다는 것을 이해할 수 있습니다. 저는 노션을 만지기 전에 위의 도식화까지 모두 마친 후에 작업이 들어갑니다. 물론 작업을 하는 과정에서 수정이 빈번하게 일어납니다. 하지만 처음에 계획을 하고 들어가느냐 아니냐는 매우 큰 차이가 있습니다.


지금까지 설명드린 것들을 아마 완벽히 이해하시는 것은 조금 힘드실 수 있습니다. 왜냐면 실제 업무 흐름에 대한 이해도가 다르기 때문입니다. 노션에 대한 이해도 차이 때문이 아닙니다. 제가 가지고 있는 비즈니스의 도메인 지식과 실제 업무 시 어떤 데이터가 필요한지에 대한 경험의 차이입니다. 반대로 말하면 여러분이 비즈니스 도메인이나 업무 프로세스에 대한 고려 없이 단순히 템플릿이 좋다는 이유만으로 가져와서 이용하려 하는 것이 얼마나 말도 안 되는 일인지를 아셔야 됩니다.




툴이 해결책이 아닐 수도 있다.


지금까지 노션이란 툴을 활용해서 조직의 업무 생산성을 높일 수 있는 방법을 설명드렸습니다. 아마 이 글에 관심이 있으신 분들은 툴을 활용해 조직의 비효율을 제거하고, 관리를 용이하게 만들고 싶으신 분들일테죠. 여기서 주의할 점은 툴이 그렇다고 해서 문제를 해결할 수 있는 유일한 방법이 아니란 것입니다. 간혹 툴을 통해 무엇을 해결하고 싶은지가 아니라, 툴 자체에 집착하시는 분들이 있습니다. 그러면서 조직이 겪고 있는 문제를 완벽하게 해결할 수 있는 복잡한 툴의 기능 혹은 새로운 툴을 찾거나 이를 다룰 수 있는 전문가를 찾곤 합니다. 하지만 제가 겪어본 바로는 대부분 툴이 문제라기보다는 다른 곳에 근본적인 문제가 있는 경우가 훨씬 많았습니다. 


예를 들어 여러분이 구현하고자 하는 업무 프로세스나 시스템이 과도하게 복잡하다는 것은 조직의 업무 프로세스가 불필요하게 복잡하거나 비효율적이라는 이야기일 수 있습니다. 이 경우에는 툴을 만질 게 아니라 업무 프로세스를 바꿔야 합니다. 이것은 비단 효율만의 문제가 아닙니다. 업무가 쓸데없이 복잡하다는 건 여러분이 하는 비즈니스의 임팩트가 떨어진다는 뜻이 될 수도 있습니다. 이때 바보같이 툴만 연구한다고 해서 문제가 해결될 리가 없습니다. 이외에도 조직 구조상 부하가 많이 걸려있거나 혼란을 야기시키는 경우도 있습니다. 마찬가지로 이를 해결하려면 조직 구조를 바꿔야지 툴을 잡고 있는다고 문제가 해결되지는 않습니다. 


마지막으로는 대화의 중요성입니다. 많은 사람들이 조직에서 발생하는 모든 문제를 툴로 해결하려고 하지만 사실 대화가 더 유용할 때가 많습니다. '갑자기 무슨 대화야'라고 하실 수도 있겠지만, 인간이 복잡한 문제를 해결할 때는 문서나 툴을 기반으로 한 비동기 소통보다 동기화, 즉 얼굴을 마주 보며 소통하는 것이 훨씬 더 유리합니다. 사실 툴은 이를 도와주는 역할을 할 뿐입니다. 


툴이 우리를 도와주는 것은 크게 두 가지로 나뉩니다. 하나는 문제를 가시화시키고 수면 위로 올리는 것이고, 또 다른 하나는 불필요한 소통의 시간을 줄이는 것입니다. 결과적으로 이를 통해 우리가 얻을 수 있는 가치는 정말 중요한 문제를 가지고 서로 대화를 나눌 수 있는 시간입니다. 만약 툴로 문제를 해결하려는 데 잘 되지 않는다면 그냥 대화하는 시간을 고정적으로 만들어보세요. 툴 하나 건드리지 않고도 해결되는 경우가 더 많을 겁니다. 




결국, 툴은 툴일 뿐이다.


요즘 보면 노션과 같은 업무 생산성 툴에 과도하게 집착하시는 분들이 계십니다. 툴을 공부해서 더 깊은 지식을 얻는 것 자체가 나쁜 것은 아닙니다. 하지만 무엇을 위해서 툴을 사용하려는지 목적을 잊어버린 채로 파고드는 것은 비효율 그 자체입니다. 왜냐면 툴 자체가 목적이 될 수 없기 때문입니다. 


이 글을 통해 제가 설명한 내용 중에 노션 스킬의 비중은 거의 없습니다. 대단히 복잡하거나 어려운 노션 스킬을 사용하지도 않았습니다. 그보다는 업무 흐름을 시각화하고 구조화하는 스킬이 훨씬 더 중요하다는 것을 알 수 있으실 겁니다. 결국 툴은 툴일 뿐입니다. 그러니 더 이상 툴에 잡아먹히지 마시길 바랍니다.

매거진의 이전글 노션으로 신청-승인 구조의 휴가 시스템 만들기
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari