스타트업 용어 가이드

오늘은 스타트업에서 자주 사용하는 8가지 용어들에 대해 적어볼까 합니다. 주니어 경력의 입사자분들께서 스타트업에 오시면 대부분 용어에 혼선을 빚거나 정확히 뜻을 모르는 채로 회의 참석할 소지가 있고, 문장 또는 문맥의 앞과 뒤를 연결지어 이해해보면 유추가 가능하지만 나중에 뜻을 몰라서 헤매는 경우도 있기 때문에 이 글을 작성하게 되었습니다.

 

---

 

1. Task, Action Item, To do List

3개가 다 비슷한 표현이기에 적어보았습니다. 뉘앙스가 조금씩 다르지만 크게 구분할 필요는 없을 것 같습니다. 용어의 뜻은 Task(과업), Action Item(실행 과제), To do List (할 일) 입니다. 용어를 어떻게 사용하느냐가 조금 차이가 있습니다.

Task 나 과업이라는 표현을 자주 쓰는게 좋습니다. 왜냐하면 해야 하는 업무를 까먹거나 놓치는 일이 생각보다 많기 때문입니다. 예를 들어 CTO님이 "해당 이슈들이 많이 올라와있는데 이슈들중에서 완료가 된 것은 정리부탁드려요"라고 말씀하셨다면, 이 때 단순히 "이따가 시간 날때 정리해야지" 정도로 기억하면 까먹을 수 있습니다. 작은 커뮤니케이션에서도 내가 해야 하는 일들을 '과업'이라는 개념으로 이해하면 좀 빠를 것입니다. 

Task 혹은 과업이라는 단어를 자주 사용하면 자연스럽게 자신이 하고 있는 일들과 해낸 일들을 관리할 수 있게 됩니다. 체계가 갖춰진 회사에서 일하는 것은 대학생때 프로젝트를 했던 것과는 다르게 자신의 과업이라고 생각하며 놓치지 않게 되는 것입니다. 

Action Item 은 "해야할 일"이라기 보다는 "실행"의 의미가 더 가깝습니다. 가장 자주 사용되는 때는 회의 시간일 때입니다.. 모든 회의에서 그 회의가 끝났을 때 앞으로 무슨 일을 해야 하는지 Action Item을 뽑아내야 합니다. 만일 아이디어를 나누고 토론하는 회의를 했고, 회의에서 나온 아이디어를 앞으로 누가 어떻게 정리해서 구체화할 것인지, 또 이 일을 언제까지 정리할 것이고 실행에 옮겨야 하는지 정리해야 합니다. 이렇게 Action Item 을 뽑아내지 않고 회의가 마무리되버리면 결국 그 회의는 큰 의미가 없는 시간 낭비가 될 확률이 정말 높습니다. 프로젝트를 추진하고 사업 진도를 나가게 만들기 위해 반드시 Action Item 을 뽑아내야 합니다.

Action Item과 더불어 To do list도 이를 실행에 옮기기 위해 어떤 목록을 정하고 그 목록에서 우선순위에 맞게 내가 할 수 있는 일들을 하나둘 씩 헤쳐나가는 것입니다. 회의록만 정리하고 끝내버리는 경우가 많아 그런 경우 Action Item을 꼭 사용하면 좋겠습니다.

 

2. Lean

Lean은 '기름기를 뺀, 효율적인' 이라고 이해하는 것이 좋습니다. 도요타의 효율적인 제품 제조 방식인 '린 제조방식'에서 착안하여 에릭 리스가 그의 저서 '린 스타트업'을 집필하며 유행의 물살에 타게 되었습니다. 린 스타트업 방식은 '시장에 제품을 빠르게 테스트하여 그 결과를 다시 제품에 반영하는 과정을 반복하는 것'이라고 합니다. 사무실에서 아무리 준비를 하여 시장에 출시를 하여도 시장의 반응이 차갑고, 정작 사용하는 사용자들은 좋아하지 않는다면, 그 긴 세월을 들여 준비한 것은 무용지물이 됩니다. 

그렇기 때문에 제품을 출시하기 위해서는 몇 개월 또는 몇 주에 걸쳐 간단하게라도 시제품(프로토타입)을 만들어 시장에서 테스트해보고, 사용자들의 피드백을 수집하여 또 제품에 반영하고, 또 잘못된 부분이나 고도화해야하는 부분을 시장에 출시해 테스트하는 것을 반복적으로 하는 것입니다. 

린 방식이 중요한 이유는 업무에서도 이와 똑같이 적용되기 때문입니다. 주니어들이 많이 하는 실수 중에 하나는 '린하지 못하게 일하는 것'입니다. 팀장님이 특정 일을 마무리해달라고 어떤 업무를 주었고, 그 업무를 이제 본격적으로 시작해야하여 To do list 를 작성하였다고 칩니다. 해당 업무는 마감기한이 일주일 뒤였기 때문에 일주일 뒤까지 주니어가 착실하게 준비합니다. 그리고 개발을 진행하면서 다른 도움을 크게 받지 않고, 내가 일하던 방식대로 일을 진행합니다. 일주일 뒤에 팀장님이 해당 일에 대해 얼마나 되었는지 출시해도 되는지 묻자, 주니어가 그 일이 정상적으로 마무리된 것 같다고 해서 실제 데이터를 입혀 테스트를 합니다. 하지만 테스트가 정상적으로 진행되지 않고, 테스트하는 족족 실패가 나기 때문에 일주일동안 공들여 개발에 착수한 내용물이 무용지물이 되었습니다. 

이런 방법을 개선하기 위해 린이라는 개념이 도입되었습니다. 일주일이라는 시간동안 팀장님에게 계속 업무에 대한 피드백을 주고받은 뒤, 이 일이 어떻게 진행되어야 하는지 방향성을 바로 잡고 효율적으로 시간을 할애하여 다른 군더더기가 최소화되도록 일을 진행하는 것이 좋습니다. 여기서 린의 핵심중 하나인 '지속성'이 나오게 됩니다. 지속성을 가지고 꾸준히 다른 사람에게 피드백을 받는다는 것은 쉬운 일이 아니지만, 이런 업무 방식은 나중에는 또 물어보지 않고도 스스로 해낼 수 있는 지침서와 같은 가이드라인이 됩니다. 

 

 

3. MECE

MECE는 상호배제 전체포괄 (Mutually Exclusive Collectively Exhausitive)의 약자입니다. 어떤 항목들을 정리할 때 항목 간에 서로 중복 없이, 누락되는 항목 없이 정리한다는 뜻입니다. MECE하다는 개념은 여기저기에 많이 쓰이는 프레임인데 특히 주니어 때는 여러 준비 사항을 챙기면서, 여러 Task를 관리할 때 유용하게 쓸 수 있습니다. 

보통 개발자들은 입사 후 온보딩 과정으로 업무 프로세스와 덩달아 해당 비즈니스 모델에서 만들 수 있는 가이드를 받는 것이 일반적입니다. 그런 가이드라인이 따로 없다면 그 부분은 나중에 온전히 입사자가 감당해야할 무게로 다가옵니다. 

코드의 스타일과 템플릿을 정하는 것은 정말 중요합니다. 가독성이 있게 하기 위해 리팩터링된 코드를 기존의 사람들은 대부분이 알고 있고, 그 부분이 개선되면서 전파가 되었겠지만 가이드를 받지 않은 개발자는 해당 소스 코드를 들여다보는 것이 매우 힘들고, 또 신규 개발건이 들어온 경우 이 개발을 어떻게 효율적으로 할 지 물어본 뒤에 기존에 사용했던 방법과 유사하게 코드를 작성하거나 재사용성을 높인 코드를 사용하는 것이 좋습니다. 

누락이 발생하는 것은 이해하기 더 쉽습니다. 체크리스트를 확인하면서 업무를 진행해야 하지만, 체크리스트 중 일부가 누락되어서 그 항목을 입사자가 진행하기 어렵다면, 빠진 과정을 떼우느라 시간이 더 소요될 수도 있습니다. 

 

4. Due date 

납기의 준말로 Deadline과도 같은 의미를 가집니다. 뜻은 마감일과 납기일, 목표 기한이라고도 이해하면 좋습니다. 

모든 과업에는 납기가 있습니다. 우리 삶에서는 시간, 돈, 노력과 같은 자원이 무한하지 않기 때문에 한정된 자원 안에서 목표를 달성하고 성과를 내야 합니다. 스타트업은 특히나 대기업보다 자본도 적고, 인력도 적고, 전체적으로 필요한 자원이 풍부하게 있을 확률이 굉장히 드뭅니다. 그렇기 때문에 목표를 달성하기 위해 체계적으로 자원을 배분해야 한고, 그 중 하나는 목표 기한을 정하는 것입니다. 스타트업이라는 시장 자체가 매우 치열하고 험난한 전장이기 때문에 언젠가 팔리겠지 하는 느긋한 태도로 시간을 허비하게 되면 절대 불가능합니다. 어떤 일을 할 때 납기를 정하지 않는다는 것은 달리 말하면 허술하게 대충 일한다는 것과 같습니다.

납기일은 신뢰도와도 연결되는 큰 요소입니다. 다른 회사 또는 우리 회사 내에서 들어온 요청을 해달라고 하는 시간을 정해서 알려달라고 하는 것도 중요하지만, 주어진 시간 내에 해결하게 되는 프로세스들과 그 결과물이 다른 사람들에게 영향을 끼치게되는 것이 정말 중요합니다. 혹여나 해당 납기일을 정하지 못한 채로 전달받게되면 되도록 언제까지 마무리하면 좋은지 다시 되묻는 방법도 필요하고, 그렇게 물어본 납기일은 꼭 지켜주는 것이 같은 공간 또는 다른 공간에서 일하는 사람들끼리 신뢰도를 유지할 수 있는 방법입니다.

 

 

5. R&R

역할과 책임이라는 의미입니다. 직장에서 정말 많이 쓰이는 일이고, R&R을 분배한다는 말은 '어떤 과업이나 역할에 책임자를 지정한다'라는 말과 같습니다. 업무에서는 '책임자'와 '담당자'가 정말 중요합니다. 업무의 결과물을 책임지고 만들어낼 사람을 지정해야 결과물이 제때 맞춰서 잘 나오게 됩니다. R&R은 흔히 진행되는 것으로 보통 Jira에서 할당받은 사람 또는 메신저를 통해 전달받는 일들이 대부분 R&R을 기본 내장하고 있다고 이해하시는 것이 좋습니다. 

주니어 입장에서는 R&R이 익숙하지 않을 것입니다. 일에 대해 책임을 지는 것이 익숙하지 않기 때문인데, 이는 처벌과는 다른 개념이므로 그 일이 실패했을 때 잘못을 물게 되는 것이 아닙니다. 일에 대해 책임을 진다는 것은 "책임지고 성과를 내는 것" 입니다. 

 

6. Align

정렬이라는 뜻이지만 사실 사용하는 목적은 조금 다릅니다. 이번 프로젝트 방향성에 대해 제대로 Align이 되어 있지 않다거나, 다른 팀 누구랑 일정 Align 해서 언제 미팅 진행하면 좋을지 알려달라고 하는 것을 보면 정렬의 개념이 아닌 통상 맞추는 뜻을 많이 내포하고 있습니다. 

서로 어긋나 있는 무언가를 일렬로 같게 정렬한다는 뜻이 더 정확할 것 같습니다. 일정을 조율한다거나 회사 및 개인의 목표를 정렬하자고 할 때도 이런 용어가 많이 사용됩니다. 조직의 목표는 조직 구성원 개인의 목표와 다를 수 있기 때문에, 이를 모르고 입사하는 주니어에게는 다소 생소할 수 있는 개념이기도 합니다. 

회사란 본디 같은 목표를 향해서 달려가는 조직이고, 그 조직에 발맞춰 같이 달려나갈 수 있는 구성원들이 뒷받침되어야 안정적으로 목표에 도달할 수 있습니다. 하지만 회사에서는 A에 대해 달려가고자 하지만 신규 입사자는 B를 향해서 달려가기 위해 입사를 하였다고 하면 우선 1차적으로 어긋나게 되는 부분이 존재합니다. 조직의 방향성과 개인의 방향성이 제대로 Align 이 되지 않으면 그 맞지 않는 부분을 맞추기 위해 의견을 가운데로 모아서 같이 나갈 수 있는 방법을 꿰차야합니다.

주니어는 입사당시 회사의 목표와 방향성이라는 것을 파악하기가 어렵습니다. 일단은 처음 하는 일이기도 하지만 업무에 적응하기 위해 야근을 병행하고, 주어진 일을 또 처리하기에도 바쁘기 때문입니다. 그리고 이 회사가 왜 이 일을 하는지, 지금 전체적인 것이 아닌 일부의 단면만을 보고 진행한느 것인지는 신경쓰거나 캐치할 수 있는 여력이 부족합니다. 우리 회사의 다음 목표나 비전이 무엇인지까지 신경쓰기도 어렵고, 다른 사람들과 협업하기 위해서 다른 사람들이 어떤 일을 하는지 전반적으로 캐치하기도 어렵습니다. 결국 업무 부적응이 아닌 회사 부적응으로 중도에 이탈하는 인원들도 비지기수입니다. 

Align은 조직에게도 중요하지만 개인의 직장 생활에도 정말 중요합니다. 우리는 나 자신을 위해서 조직의 목표와 방향성을 공부하고, 꾸준히 관찰하고 다른 사람들 그리고 우리 회사가 어떤 방향으로 나아가고 있는지 Align 해야 합니다. 그렇지 않는다면 야근이나 업무 시간에 지쳐 집에 가면 픽하고 쓰러지는 번아웃이 오기 쉽습니다. 

 

 

7. Leverage 

레버리지는 지렛대로 물건을 쉽게 들어 올리듯이 무언가를 활용해서 효율적으로 일하는 것을 의미합니다. 체계가 제대로 갖추어지지 않은 스타트업에서는 이런 어지러운 체계를 극복하기 위해 다양한 전사적 툴을 사용하여 보다 빠르게 적응하고 위기상황에 대처해나가기 위해 노력합니다. 금융권에서는 레버리지를 '빚을 내서 돈을 버는 방법'으로 인식하고 있지만, 우리는 다른 사람들이 만들어 놓은 유용한 것들을 차용해다가 사용해서 더 큰 수익을 내는 모델을 만들어야 합니다.

그래서 레버리지를 적극적으로 활용하지 못하면 시기를 놓치기 쉽상입니다. Due date와는 조금 다른 개념이긴 하지만, 사업이라는 것은 어느 정도 타이밍이라는 것이 존재하여 빛을 볼 수 있을 때 런칭을 하여 사람들의 이목을 한 눈에 받는 서비스를 만드는 것이 가장 중요합니다. 이런 사업이 뒷받침되려면 레버리지가 필연적으로 사용되게 됩니다.

업무에서 레버리지는 '남의 노력으로 내 업무 효율을 올리는 것' 정도로 인식할 수 있습니다. 지금 개발 소프트웨어로 사용하고 있는 Git, IntelliJ, Notion 등이 전부 이에 속하게 됩니다.

 

8. Wrap-up

어떠한 프로젝트나 과업을 끝마치고 나서 회고를 주로 하게 됩니다. Wrap up 은 회고를 의미하는 것으로 마무리라는 뜻으로도 사용할 수 있습니다. 일을 제대로 처리하는 회사라면 프로젝트를 마무리하고 항상 그에 따른 회골르 진행합니다. 왜냐면 이번 프로젝트에서 잘했던 점, 아쉬웠던 점, 앞으로 개선해야 할 점을 정리해서 다음 번 프로젝트를 잘하는 데에 맞추기 위한, 그리고 성공경험을 갖추기 위한 습관을 프로젝트에 투입된 다른 인원들과 같이 공유하기 때문입니다. 

주니어가 자주 하는 실수 중 하나는 프로젝트가 마무리 되고 나서 '이제 프로젝트가 끝났으니 다음 프로젝트를 준비하자'라는 마인드셋입니다. 정작 내가 여기에 많은 기여를 하였고, 많은 것에서 성과를 낼 수 있는 프로젝트를 내 것으로 만들어서 양분으로 삼아야하는데 그러한 과정이 전혀 없이 새로운 프로젝트에 투입되어 시작하는 것은 정말이지 남는게 없기 때문입니다. 

업무의 퀄리티를 높이기 위해 노력해야하지만 그냥 일을 끝내기에 바쁜 흔히 '일을 쳐낸다'라고 표현하는 것들이 회고를 하지 않은 사람에게 더 빈번하게 일어날 수 있는 부분 중 하나입니다. 이전에 회고를 하였거나 내가 따로 기록하는 공간이 있을 경우 그런 부분을 참조하여 '아, 다음에는 이런 실수를 하지 말아야지' 할 수 있는 능력을 갖추는 곳이 회사이자 프로젝트이기 때문입니다. 

많은 스타트업들이 프로젝트가 마무리 된 뒤에 회식을 하거나 회고를 하는 것도 이와 비슷한 원리입니다. 정기적으로 다지는 것 외에도 모든 것에는 끝날 때까지 끝난 것이 아닌 것처럼 되돌아볼 필요가 있습니다. 

 

---

 

물론 이 외에도, Agile, Silo, Pivot, OKR, KPI, ROI 등등 여러 용어들이 있지만 이런 용어는 금방 찾을 수 있기도 하고, 저도 글을 작성하면서 다시 찾아본 좋은 용어들과 그 용어를 어떻게 사용하고 빈번히 쓰는지 체크하게 된 계기가 되었습니다. 모두 알찬 결실 얻으시길 바라겠습니다!