회의록을 회의록끼리 모아두면 안돼요

몇 달 전부터 기여하게 된 프로젝트에서 이전에 제가 일하던 방식으로 일하려다가 가장 먼저 지적 받은 점을 새로운 방식에 적응하기에 소개했습니다. 이전에 비포괄임금제를 적용하는 회사임에도 스탭들이 계속해서 거의 최대 시간에 가깝도록 일하게 만드는 프로젝트에 일한 적이 있다 보니 근무시간을 늘려 일을 좀 더 많이 처리해야 한다고 생각했습니다. 그도 그럴 것이 그 프로젝트에서는 월말에 최대 근무 시간을 초과해 컴퓨터가 잠기면 그 화면을 일부러 켜 놓고 퇴근하고 월말까지 회사에 남아 있거나 평소에 초과해 일하지 않으면 눈치가 보이는 분위기였기 때문에 여전히 비슷하게 행동하면 된다고 생각했습니다. 하지만 이번에는 그렇게 행동해서는 안됐고 회사는 여느 초과 수당을 지불해야 하는 회사와 마찬가지로 초과 시간에 대해 이전보다 조금 더 까다롭게 굴었으며 이는 우리들 스스로도 마찬가지였습니다. 그래서 저는 제가 익숙한 업무 방식을 바꾸기 위해 노력해야만 했습니다.

딱히 지적 받은 것 같지는 않지만 또 다른 업무 방식, 그리고 마음가짐의 변화를 느긋하게 가자에 소개했습니다. 저는 약간 공격적으로 인식될 수 있는 스타일로 일하곤 합니다. 기본적으로 프로젝트에 속한 우리 모두는 결국 프로젝트가 런칭해 돈을 벌어 들여야 한다고 생각합니다. 우리가 돈을 벌어야 회사가 지금까지 우리에게 돈을 낸 이유를 우리들 스스로 증명할 수 있고 또 그래야만 우리들이 회사에 더 강하게 우리가 원하는 바를 요구해 서로 잘 될 수 있다고 생각하기 때문입니다. 하지만 프로젝트에 속한 모든 사람들이 이런 생각에 동의하지 않음을 알고 있습니다. 다른 세계를 경험해 온 사람들이 모여 있고 당연히 이들은 프로젝트에 기여하면서도 서로 다른 목적을 가지고 있습니다. 누군가는 좀 더 나은 포트폴리오를 만들기 위해, 누군가는 생계에 더 집중하기 위해, 또 다른 누군가는 팀에서 적절한 위치를 유지하기 위해 일하고 있고 이는 결국 프로젝트를 런칭하는데 제각각 기여하지만 효율적으로 정렬되어 있지는 않은 상태를 만듭니다. 이런 상황에서 저는 모두가 당연히 프로젝트의 런칭과 성공을 위해 일한다고 생각한 채 말하고 행동했는데 이는 종종 목적이 다른 분들의 업무 스타일과 충돌하곤 합니다.

시간이 지난 다음 다시 평가해 보면 모두가 프로젝트의 런칭과 성공, 경제적인 성과를 위해 일하고 있지는 않으며 이를 인정하지 않으면 여러 사람이 모인 큰 프로젝트에서 함께 일하기 어려운 사람이 될 수밖에 없다는 사실을 깨달았습니다. 공격적인 업무 스타일은 단기적으로 성과를 내지만 몇 년에 걸친 개발에는 주로 좋지 않은 영향을 줬다고 생각합니다. 공격적으로 단기적인 목표를 달성하지만 시간이 흐름에 따라 사람들을 잃거나 저 자신의 정신적 에너지가 완전히 고갈되어 제 스스로가 프로젝트를 이탈하며 결국 런칭을 경험하지 못하는 등 문제가 더 많았습니다. 지난 프로젝트는 이런 공격적이고 또 급한 마음이 최대가 된 상태에서 의사결정을 한 나머지 이 경험이 파국을 맞은 다음 곰곰이 생각해보고 웹3 게임과 코인 사기의 유사성을 어렵지 않게 눈치 챌 수 있을 상황이었음에도 이 프로젝트에 참여하는 실수를 저질렀다는 사실을 알 수 있었습니다. 이 역시 너무 공격적인 방식의 의사결정으로 인한 실패라고 인정하지 않을 수 없습니다. 그래서 이번에는 조금 마음에 안 드는 구석이 있더라도 시간을 들여 천천히 해결하며 저 자신 뿐 아니라 함께 일하는 프로젝트 구성원들 모두 서로 다치지 않을 수 있도록 느긋하게 움직이기로 합니다.

한편 이번 프로젝트에 기여하기 시작하며 받은 또 다른 소소한 지적 중 하나는 회의록을 회의록을 모아 둔 컨플루언스 위키 상의 특정 페이지 하위에 작성하지 않았다는 것입니다. 여느 팀과 마찬가지로 이 팀 역시 컨플루언스 위키의 계층구조 기능을 적극적으로 활용하고 있습니다. 이전에 계층형 위키를 쓰며 느끼는 관리방법의 충돌을 통해 고민해본 적이 있는데 애초에 위키는 계층구조를 생각하지 않고 개발되었습니다. 모든 문서는 같은 계층 상에 나열되어 있으며 이들은 서로 간의 연결에 따라 의미를 가지게 됩니다. 가령 회의록을 작성했다면 이 페이지를 기존 회의록 페이지를 나열한 문서에 추가하고 연결하기만 하면 실제 문서가 어디에 있든 별로 중요하지 않았고 애초에 계층 구조가 없는 환경에서 문서의 위치 자체를 정의할 수 없었습니다. 그러다가 도쿠위키 같은 네임스페이스를 통해 계층을 구분하는 기능을 가진 위키가 나타났고 또 컨플루언스처럼 문서 하위에 또 다른 문서를 만드는 방식으로 계층 구조를 만들 수 있는 위키도 나타납니다. 그리고 이런 계층 구조는 기존 디렉터리와 파일 구조를 통해 문서를 관리하는 습관을 가진 사람들에게 익숙하게 받아들여져 위키 형식에 기반한 도구를 사용하고 있음에도 계층구조를 관리해야만 한다고 생각하는 결과를 가져온 것 같습니다.

이전 시대에 계층 구조가 없는 좀 더 위키의 초기 형태에 가까운 도구에서는 그저 새 문서를 만들어 회의록을 작성한 다음 이 문서를 기존 회의록들의 링크를 모아 놓은 페이지에 추가하면 그만이었습니다. 이 시대부터 위키를 사용한 덕분에 문서의 계층을 중요시 하기 보다는 문서의 연결을 더 중요하게 생각하며 일단 문서가 필요한 다른 문서에 연결되어 있기만 하면 이 상태를 더 이상 정리할 필요가 없다고 생각합니다. 이는 이후 계층 구조가 명확한 컨플루언스 위키를 사용할 때도 비슷하게 나타났는데 문서를 대강 아무데나 만든 다음 다른 문서에 연결해 놓으면 더 이상 이를 관리하거나 정리할 필요를 느끼지 못했고 어쩌다 계층 구조에 조금 손을 대더라도 문서 주소가 바뀌지 않기 때문에 링크가 깨지지 않아 더더욱 계층 구조를 관리할 필요를 느끼지 못했습니다. 그래서 회의록을 작성할 때 역시 회의록을 제가 원하는 아무 장소에나 페이지를 생성한 다음 작성하고 이를 회의록 페이지에 링크하곤 했고 이걸 딱히 이상하게 생각하지 않아 왔는데 이번에도 똑같이 행동했더니 누군가 “우진님. 회의록은 이 페이지 하위에 작성해 주세요.” 라는 말을 들었습니다. 일단 프로젝트에 기여한지 얼마 되지도 않았고 수습이 끝나지도 않았기 때문에 이 말이 썩 마음에 들지 않았지만 들을 수밖에 없었습니다.

개인적으로는 회의록을 회의록을 모아두는 계층 구조 하위에 넣는 규칙을 썩 달가워 하지 않습니다. 모든 회의가 그렇지는 않지만 상당수 회의는 이미 작성된 어떤 문서를 근거로 진행할 때가 많습니다. 기획팀에서 이번 마일스톤에 수행할 어떤 요구사항을 나열한 기획서를 작성했고 이 기획서를 브리핑 하는 회의를 하는 상황을 생각해보면 이 회의는 이미 작성된 기획서를 근거로 진행하게 됩니다. 회의에 나온 이야기 거의 대부분은 이미 작성되어 있던 기획서에 대한 의견이며 이들 중 일부는 기획서에 반영되어야 합니다. 또 이 기획서에 대한 회의는 이번 한 번으로 끝나지 않고 앞으로 마일스톤이 끝날 때까지 여러 번 일어날 겁니다. 만약 계층구조를 제공하지 않는 위키에 회의록을 작성한다면 그냥 문서를 생성해 회의록을 작성한 다음 이 문서를 회의록을 모아둔 페이지와 이 회의를 하게 만든 기획서 페이지에 연결해 놓을 겁니다. 그런데 계층구조를 제공하는 위키라면 회의록 페이지를 생성할 위치를 고민해야만 하는데 개인적으로 이럴 때 회의록 페이지를 생성하기 가장 좋은 위치는 이 회의가 일어나게 만든 기획서 페이지의 하위라고 생각합니다.

이 규칙에 따라 회의록을 작성하면 기획서 하위에 이 기획서에 대한 여러 회의록이 위치하게 되며 기획서 하위에 여러 회의록이 함께 펼쳐져 기획서를 놓고 일어난 여러 논의 진행 과정을 살펴볼 수 있습니다. 또 어떤 이유로 기획서의 계층 구조 상의 위치를 옮겨야 할 때 이 기획서와 연관된 다른 회의록을 모두 함께 이동 시킬 수 있습니다. 이는 이동 이전에도 기획서와 회의록 사이의 맥락을 깨지 않으며 이동 후에도 기획서 뿐 아니라 이 기획서에 의해 일어난 여러 논의 기록을 함께 이동 시켜 이동 후에도 이 맥락을 깨지 않습니다. 회의록을 읽다가 이 회의의 결과가 반영된 기획서를 보고 싶으면 그저 계층 구조 상에서 한 단계 위에 있는 문서를 보기만 하면 됐고 이를 위해 회의록에 이 회의를 하게 만든 기획서를 연결하거나 그 반대로 행동하도록 강제하지 않아도 그냥 계층 구조 상에 문서가 나타나니 누군가 부주의하게 이들 사이의 링크를 만들지 않아도 맥락을 유지할 수 있습니다. 그래서 주간회의, 관리자회의, 고위의사결정자회의 같은 근거가 되는 문서가 없거나 특별히 이 회의에 의한 회의록을 같은 공간에 모아 둬야만 하는 회의가 아닌 이상 회의록은 항상 그 회의가 일어나게 만든 문서 하위에 만들어 왔습니다.

처음에는 이런 습관의 연장에서 회의록을 기획서 하위에 만들었는데 이를 본 누군가의 눈에는 제가 회의록을 아무데나 만든 것으로 비친 모양입니다. 그럴 만도 합니다. 일단 수습에 떨어질 일을 만들지 않기 위해 동의하지는 않았지만 방금 작성한 회의록을 이 회의를 하게 만든 기획서로부터 분리해 회의록들만 모여 있는 계층 구조 상의 위치로 옮겼습니다. 다행히 컨플루언스 위키는 한 번 발급된 주소는 문서 위치가 옮겨지더라도 변하지 않아 링크가 깨질 일은 없었습니다. 물론 컨플루언스 위키 역시 문서가 포함된 공간(Space)이 변경되면 주소가 바뀌기는 하지만 대체로 한 프로젝트는 한 공간을 사용하는 경우가 많아 딱히 신경 쓸 문제는 아닙니다. 회의록을 회의록 계층에 옮겨 놓은 다음 같은 계층 구조 상에 있는 여러 회의록들을 눌러 봤습니다. 각각의 회의록은 서로 다른 마일스톤에 서로 다른 기획서를 대상으로 이루어진 것처럼 보였는데 회의록들이 모두 같은 계층에 모여 있기에 각각의 회의를 하게 만든 마일스톤과 기획서에 의해 만들어지는 맥락을 쉽게 알 수가 없었습니다. 위에서 누군가는 회의록에 이 회의를 하게 만든 기획서 링크를 충실히 만들고 그 반대 방향의 링크도 만드는 반면 다른 누군가는 그렇지 않기도 한다는 이야기를 했는데 이번에도 어떤 기획서에는 아무런 링크도 없어 이 문서의 맥락을 파악할 수가 없었습니다.

개인적으로 이런 회의록들을 모아 놓는 계층 구조 상의 특정 위치를 회의록의 무덤이라고 부릅니다. 회의를 했고 회의록도 남겼지만 회의록들만 모인 곳에 함께 남겨진 회의록은 시간이 조금만 지나도 각각의 회의록이 가진 맥락을 파악할 수 없어 회의록을 읽어도 이게 어떤 맥락에서 논의한 결과인지 파악하기 어렵습니다. 회의록은 위에서 언급한 소수의 같은 계층에 모여 있어야 하는 종류의 회의록을 제외하면 반드시 이 회의를 하게 만든 어떤 맥락과 연결되어야만 의미가 있습니다. 그런데 회의록을 함께 모아 두는데 집중하며 회의록 각각의 맥락을 의도하지 않게 제거해 버리면 회의록의 유통기한은 이 문서의 맥락을 이해하고 기억하는 소수의 사람들에 의해 유지되다가 이들의 기억이 사라지거나 이탈이 일어나면 유통기한이 끝나고 그저 오래된 의미를 파악할 수 없는 문서가 될 뿐입니다. 이미 여러 회의록을 읽다가 내용에 대해 질문할 때 맥락을 온전히 파악해 설명을 들을 수 있는 문서는 그리 많지 않았는데 이는 맥락을 잊은 각자의 잘못이 아니라 회의록의 맥락을 쉽게 제거하도록 만드는 잘못된 규칙 때문이라고 생각합니다.

회의록이 회의록을 모아 두는 계층 구조 상의 한 위치에 모여 있으면 보기에 아름답습니다. 컨플루언스 위키에서 회의록 트리를 열면 ‘2024-01-01 왜 우리는 새해 첫날 쉬지 못하는가’ 같은 회의록 이름이 규칙에 맞춰 쭉 나열되어 있으면 일단 보기에 아름답고 회의록 각각을 빠르게 넘겨 보기에도 편합니다. 그런데 회의록을 작성한 목적이 이들이 모여 있을 때 아름답게 보이도록 만들고 또 이들을 빨리 넘겨 보기에 편하도록 만들기 위함은 아니라고 생각합니다. 회의록은 그 회의를 하게 만든 목적을 달성하고 이후 이 기록을 살펴보고 또 이 기록을 포함한 맥락을 유지하기 위해 작성하는 것입니다. 맥락을 잘 유지한 회의록은 이 회의의 결과에 의해 기획서 상의 요구사항을 수정하고 이에 기반한 개발 결과를 수정하기를 요구하겠지만 이 사실이 문서에 잘 반영되지 않더라도 회의록 스스로가 맥락을 잘 유지하고 있기 때문에 이런 작은 실수로부터 큰 피해를 입지 않을 수도 있습니다. 그래서 개인적으로는 여전히 회의록을 회의록의 무덤에 넣는 대신 이 회의를 하게 만든 문서의 하위에 만들어 놓고 있습니다.

다행히 이런 제멋대로인 행동에도 불구하고 수습 탈락을 간신히 면해 이제 본격적으로 회의록을 회의록의 무덤 대신 기획서 하위에 만들고 있는데 흥미롭게도 처음에는 다른 부서에서 회의록을 엉뚱한 위치에 만들었다며 이를 옮겨줄 것을 요구하던데 비해 최근 몇 주 동안에는 아무도 문제를 제기하지 않고 있습니다. 이게 회의록이 이 회의를 하게 만든 문서 하위에 있어 맥락을 유지한다는 장점을 이해했기 때문인지 아니면 저 사람은 애초에 무슨 말을 해도 들어 먹지 않는다는 소문이 널리 퍼졌기 때문인지는 확실하지 않습니다. 하지만 제 개인적으로 올바르다고 생각하는 방식을 유지하고 이 방식이 미래의 저 자신에게 올바른 영향을 줄 수 있는 방법을 유지할 수 있어 다행이라고 생각합니다.

모든 경우에 그런 것은 아니지만 대체로 회의록을 회의록만을 모아두는 공간에 모아 두면 안됩니다. 이 행동은 회의록을 모아 둔 모습을 보기에 아름답게 만들지만 회의록 각각으로부터 그 회의가 일어나게 만든 맥락을 제거해 시간이 흐른 다음 우리들의 기억력을 시험하게 만듭니다. 회의록은 그 회의가 일어나게 만든 이미 작성된 어떤 문서의 하위에 있어야 합니다. 그러면 기억에 의존하지 않고서도 맥락을 유지할 수 있기 때문입니다.