시스템 - 연구원 10명인데 시스템이 필요할까요

현장의 질문들 - 1

자주 받는 질문입니다

이 질문을 정말 자주 받습니다. 그리고 대체로 이런 설명이 따라옵니다. 궁금하면 옆자리에 물어보면 되고, 소장이 다 알고 있고, 회의 한 번이면 정리된다고요.

맞는 말입니다. 실제로 그렇게 돌아갑니다. 그게 작은 조직의 큰 강점입니다.

그래서 이 글은 "작아도 시스템이 필요합니다"라고 설득하려는 글이 아닙니다. 무엇이 과하고 무엇이 아닌지를 가르는 기준을 정리해 보려는 글입니다. 읽고 나서 "우리는 아직 아니네"라는 결론이 나와도 괜찮습니다.

작은 조직의 강점은 진짜입니다

먼저 인정하고 시작하겠습니다.

연구원이 열 명이면 정보가 빠르게 돕니다. 누가 무엇을 하는지 대체로 알고, 문제가 생기면 그날 안에 공유됩니다. 결정도 빠릅니다.

큰 조직이 시스템으로 억지로 만들려는 것을 이미 갖고 있는 셈입니다. 그리고 여기에 대기업 방식을 얹으면 그 강점이 죽습니다. 결재 단계가 생기고, 양식이 늘고, 빠르던 것이 느려집니다.

대기업 시스템은 서로 모르는 사람들을 잇기 위해 만들어졌기 때문입니다. 부서가 스무 개고 담당자끼리 얼굴도 모르는 조직에서는 절차와 결재로 이어야 합니다. 작은 조직에는 그 문제가 없으니, 그대로 가져오면 없는 문제를 푸는 도구를 사는 셈이 됩니다.

그러니 "작으니까 시스템이 필요 없다"는 판단은 대체로 합리적입니다. 다만 한 가지를 빠뜨리고 있습니다.

조직이 작아도 해야 할 일은 줄지 않습니다

여기가 이 글의 전환점입니다.

연구원이 백 명이든 열 명이든, 신제품을 개발하려면 해야 할 일은 같습니다. 시장을 봐야 하고, 규제를 확인해야 하고, 직접 개발할지 사 올지 비교해야 하고, 위탁 기관을 고르고 계약 조건을 봐야 합니다.

이 기능들은 조직 크기와 무관합니다. 회사가 작다고 규제를 안 봐도 되는 것이 아닙니다.

그럼 무엇이 다릅니까. 한 사람이 맡는 기능의 수가 다릅니다.

대기업 연구원은 자기 실험에 집중할 수 있습니다. 시장은 기획팀이 보고, 계약은 구매팀이 챙기고, 규제는 인허가팀이 봅니다. 작은 조직에서는 한 사람이 그것을 다 합니다.

그래서 놓칠 확률이 대기업보다 높습니다. 게을러서가 아니라 챙길 것이 많아서입니다.

작은 조직은 두 가지 형태로 나뉩니다

그런데 "작은 조직"이라고 뭉뚱그리면 처방이 안 나옵니다. 실제로는 두 가지가 있습니다.

하나는 비슷한 형태의 프로젝트가 여러 개 반복되는 경우입니다. 고객사 요청에 따라 개발하거나, 제품군이 정해져 있어 개량이 반복되는 곳입니다.

다른 하나는 특정 분야에 집중한 벤처형입니다. 프로젝트가 서너 개뿐이고, 하나하나가 길고 무겁습니다.

이 둘은 필요한 것이 다릅니다.

반복형이라면, 템플릿이 답입니다

비슷한 일이 반복된다면 템플릿의 효과가 대기업보다 큽니다.

대기업은 과제 유형이 많아 템플릿을 수십 개 만들어야 하고, 만들어도 잘 안 맞습니다. 작은 조직은 하는 일의 형태가 서너 가지로 정리되는 경우가 많습니다. 서너 개만 잘 만들면 거의 전부가 커버됩니다.

템플릿에는 이런 것이 들어갑니다. 이 유형은 어떤 단계를 거치는가. 각 단계에서 무엇을 확인해야 하는가. 얼마쯤 걸리는가. 어떤 서류가 필요한가.

그리고 한 번 만들고 끝내지 않습니다. 이번에 새로 알게 된 것 — 이 업체는 이 서류를 미리 요구하더라, 이 시험은 두 주 더 걸리더라 — 을 템플릿에 넣습니다. 그러면 템플릿이 회사의 노하우가 됩니다.

부수 효과도 있습니다. 템플릿에 단계와 기간과 확인 항목이 들어 있으면 지금 어디쯤인지가 자동으로 계산됩니다. 이 단계는 보통 3주인데 5주째다, 이 항목이 비었는데 다음으로 넘어갔다. 매주 진척률을 입력하지 않아도 이게 나옵니다.

벤처형이라면, 판단이 남아야 합니다

프로젝트가 서너 개뿐인 곳은 사정이 다릅니다. 반복이 없으니 템플릿의 효과가 작습니다.

대신 다른 것이 훨씬 중요해집니다. 하나하나가 회사의 명운에 가깝기 때문입니다.

대기업은 과제 하나가 잘못돼도 감당합니다. 진행 과제가 셋인 곳에서 하나가 3년 헛돌면 그건 회사의 문제가 됩니다. 되돌릴 여유가 없습니다.

그래서 이런 것들이 남아야 합니다. 왜 이 방향을 골랐는지. 다른 안은 무엇이었고 왜 접었는지. 무엇이 그대로일 거라고 보고 계획했는지.

특히 마지막이 중요합니다. 벤처형 과제는 대체로 몇 가지 가정 위에 서 있습니다. 그 기술이 이 시점에 나온다, 이 규제가 이렇게 간다, 이 시장이 이만큼 열린다. 그중 하나가 무너지면 계획 전체가 흔들리는데, 그 가정이 어디에도 적혀 있지 않습니다.

그리고 문서가 발목을 잡습니다

여기에 소규모 기업에서 특히 자주 사고가 나는 지점이 하나 더 있습니다. 문서입니다.

작은 기업은 대체로 B2B입니다. 그러면 문서를 요구하는 쪽이 많습니다. 고객사가 자료를 요청하고, 인증 기관이 근거를 요구하고, 정부 과제라면 정산 서류가 있고, 특허 출원에 필요한 기록이 있습니다.

그리고 요구하는 쪽이 대체로 우리보다 큽니다. 고객사가 대기업이면 그쪽 기준에 맞춰야 합니다. 우리 규모에 비해 과해 보여도 그건 협상 대상이 아닙니다.

여기서 문제는 무엇이 필요한지를 미리 알기 어렵다는 것입니다. 마감 직전에 요청이 오고, 그제야 그때 그 자료를 남겼는지 찾아봅니다. 담당자가 바뀌었으면 어디 있는지도 모릅니다.

그래서 작은 조직에서는 문서를 잘 보관하는 것보다 무엇이 필요한지를 미리 아는 것이 더 중요합니다. 이 유형의 과제를 하면 나중에 어떤 자료가 요구되는지, 그러니 어느 시점에 무엇을 남겨야 하는지가 정리되어 있어야 합니다.

이건 앞의 템플릿과 같은 이야기입니다. 단계마다 필요한 서류가 템플릿에 들어 있으면, 그때그때 남기게 되고 나중에 찾을 일이 없습니다.

무엇을 입력받을 것인가

여기서 실무적으로 가장 자주 실패하는 지점을 짚겠습니다.

시스템을 넣으면 흔히 이런 일이 벌어집니다. 경영진은 관리가 안 된다고 느껴 항목을 늘립니다. 연구원은 입력이 늘어나니 대충 채웁니다. 대충 채운 데이터를 보니 여전히 모르겠고, 그래서 또 늘립니다. 이 악순환이 작은 조직에서 특히 빨리 돕니다.

원인은 순서에 있습니다. 대부분 "무엇을 입력할 것인가"부터 정합니다. 그러면 항목은 늘어나기만 합니다.

순서를 뒤집어야 합니다. 경영진이 무엇을 알아야 하는지를 먼저 정하고, 그것을 알기 위한 최소 입력을 역산합니다.

그리고 경영진 쪽 질문은 의외로 짧습니다.

지금 하고 있는 것들이 여전히 할 만한 일인가. 어디가 막혀 있고 언제부터인가. 접어야 할 것이 붙들려 있지는 않은가. 사람과 돈이 어디에 몰려 있는가.

이 네 가지에 답하는 데 필요한 입력은 생각보다 적습니다. 시작할 때 왜 하는지와 무엇을 전제로 하는지, 접을 때 왜 접는지, 막혔을 때 무엇이 막혔는지. 각각 두세 줄입니다.

합의는 눈에 보이게 해 두어야 합니다. 구두로 "간단히 쓰세요"라고 하면 사람마다 기준이 달라집니다. 항목 옆에 잘 쓴 예시를 두세 줄 붙여 두면 설명 없이도 전달됩니다.

합의의 나머지 절반은 경영진 쪽에 있습니다

연구원이 시스템에 써넣었는데 경영진이 그걸 안 보고 회의에서 또 묻는다면, 연구원 입장에서는 입력과 보고를 두 번 하는 셈입니다. 두세 번 그러면 안 쓰게 됩니다.

그래서 경영진도 시스템을 통해 묻고, 시스템에 답이 남아야 합니다. 궁금한 것이 있으면 그 과제에 질문을 답니다. 연구원은 거기에 답합니다. 그러면 그 문답이 그 과제의 이력이 됩니다.

회의도 자료를 따로 만드는 것이 아니라 시스템에 있는 것을 열어놓고 봅니다. 작은 조직에서 보고 자료 만드는 데 며칠씩 쓰는 경우가 있는데, 그 시간이 없어집니다.

말을 하지 말자는 것이 전혀 아닙니다. 옆자리에 물어보는 것은 계속합니다. 다만 결론과 요청과 회신은 그 자리에 남깁니다.

그리고 한 사람이 여러 기능을 맡는 조직에서는, 무엇을 해야 하는지를 기억으로 관리하면 반드시 샙니다. 지금 챙길 것이 목록으로 보여야 합니다. 기한이 지난 요청, 아직 비어 있는 확인 항목, 곧 필요한 서류. 무엇을 어떻게 할지는 여전히 연구원이 정합니다. 다만 빠뜨리지 않게 하는 것입니다.

그럼 시스템을 사야 합니까

여기까지 읽으시면 "그래서 사라는 거네" 싶으실 수 있는데, 그건 아닙니다.

필요한 것과 도구는 다른 층위입니다. 챙기고 놓치지 않는 구조는 규모와 무관하게 필요하지만, 그것을 무엇으로 구현하느냐는 다릅니다.

진행 과제가 서너 개라면 엑셀과 공유 폴더로도 됩니다. 과제별로 시트 하나를 두고, 왜 하는지와 전제와 확인 항목과 필요 서류를 적어 두는 것으로 시작할 수 있습니다. 이 정도만 해도 상당 부분 달라집니다.

시스템이 필요해지는 시점은 대체로 이럴 때입니다. 찾기 어려워질 때. 이 전제가 흔들리면 어느 과제가 걸리는지 손으로 짚을 수 없게 될 때. 그리고 사람이 바뀌기 시작할 때.

그 전까지는 도구를 사는 것보다 무엇을 남길지를 정하는 것이 먼저입니다. 그리고 그 작업은 도구 없이도 할 수 있습니다.

정리하면

조직이 작다고 해서 해야 할 일이 줄지는 않습니다. 사람만 적을 뿐이고, 그래서 한 사람이 여러 기능을 맡고, 그만큼 놓칠 확률이 높습니다.

비슷한 일이 반복된다면 템플릿부터 만드십시오. 노하우가 쌓이고 진척 관리가 따라옵니다.

프로젝트가 몇 개 안 된다면 판단을 남기십시오. 왜 골랐는지와 무엇을 전제로 했는지가 남아야 합니다.

B2B라면 필요한 문서를 미리 정리해 두십시오. 마감 직전에 찾는 일이 없어집니다.

입력 수준은 미리 합의하고, 경영진도 시스템을 통해 물으십시오.