사무실 냉장고와 노션의 공통점

사무실 냉장고와 노션의 공통점이 하나 있습니다. 무언가 썩기 좋은 환경입니다. 사무실 냉장고에 넣어둔 음식을 누군가 관리하지 않게 된다면 말라 미틀어지고, 심한 경우 썩기도 합니다. 먹지도 못하는 음식이 공간을 차지하게 된다면 다른 사람이 이용하지 못하는 불편함이 있고 미관상 그리고 위생상 좋지 않습니다. 노션, 거시적으로 팀에서 관리하는 문서 혹은 문서 도구도 동일합니다. 쌓아두기만 한다면 문서가 썩어 필요할 때 사용하지 못하는 경우가 있고 필요한 문서를 찾기 어려워집니다. 그래서 문서가 썩기 전에 감지할 수 있는 감각을 키우고 환기 시킬 수 있는 능력을 키우는 것이 목표입니다.

이 글은 여러 팀에서 노션 사용 경험을 바탕으로 작성 하였지만 노션 사용법이 아닌 문서 관리방법에 대하여 이야기 합니다.

문서가 썩으면 냄새가 고약해요~

문서가 썩었다고 판단할 수 있는 경우는 크게 4가지 입니다. 제목만 있는 문서, 깊숙이 있는 문서, 이해할 수 없는 문서, 업데이트가 없는 문서

제목만 있는 문서

제목만 있는 경우는 냉장고에 빈 병, 빈 봉투, 빈 용기 혹은 그것들에 남아있는 음식물과 비슷합니다. 누군가 정리하기 전까진 공간만 차지합니다. 필요 없거나 내용이 없는 문서가 많아지는 경우 필요없이 눌러서 찾아봐야 하는 요소들이 많아집니다. 입사 온보딩, 업무를 파악하는 과정에서 제목만 있는 영양가 없는 문서는 불필요한 시간 자원을 소모 시키고 피로감을 줍니다. 필요한 정보에 키워드를 검색하는 경우에도 내용이 없는 문서가 노출돼 문서를 찾는데 불필요한 시간을 소모시키는 문제가 발생합니다.

깊숙이 있는 문서

냉장고 깊숙하게 있는 음식은 내용물이 무엇인지 알 수 없고 썩기 좋습니다. 깊숙이 있는 문서안에 있는 문서 혹은 여러 군데 흩어져 있는 문서입니다. 깊숙이 있는 문서는 특별한 경우가 아니라면 다른 팀원이 볼 수 있는 경우가 적습니다. 문서를 한번도 보지 못했다면 문서의 내용이 필요한 경우에 문서를 이용할 수 없기에 문서의 역활을 하지 못합니다. 이로 인해 비슷한 내용의 새로운 문서가 생기고 모두에게서 잊혀질 수 있습니다.

이해할 수 없는 문서

냉장고 속 정체를 알 수 없는 음식 먹을 수 있을까요? 문서는 정보를 전달하는 기능을 가지고 있습니다. 하지만 문서를 읽는 사람이 정보를 이해할 수 없다면 문서의 기능을 상실했다고 볼 수 있습니다.

업데이트가 없는 문서

누가 언제 넣었는지 모르는 음식, 유통기한은 한참 지났습니다. 문서는 업데이트가 없는 경우 정보가 잘못되었을 수 있습니다. 과거에는 적용 가능하더라고 현재에는 적용 불가능한 경우가 있습니다. 물론 모든 문서에 업데이트가 자주 있을 필요는 없습니다. 썩지않고 숙성해야 좋은 문서도 있고 먼 미래에 적용해도 상관 없는 통조림 같은 문서도 있습니다. 하지만 자주 열어봐야 하거나 변경해야 하지만 그렇지 않은 문서는 썩은 문서입니다.

썩지 않게 관리하기

그럼 어떻게 해야 문서를 썩히지 않고 싱싱하게 유지할 수 있을까요?

문서를 작성하는 경우에는 기존 문서 중 동일한 내용이 있는지 찾아봅니다. 해당 문서가 있는 경우 문서를 업데이트해야 합니다. 내용 뿐만 아니라 썩기 좋은 위험 요소들도 함께 수정해야 합니다. 문서에 라벨링과 카테고리 기능이 있다면 최대한 활용하고 없는 경우 비슷한 항목의 문서들의 링크를 모아둔 문서를 만드는 것도 방법입니다. 문서의 내용은 다른 사람도 쉽게 수정 가능한 형식으로 작성해야 하고 수정가능한 권한 등을 확인해야 합니다. 문서 도구에서 검색 기능이 제공되는 경우 핵심 키워드로 검색 했을 때 해당 문서가 노출 되는지 확인할 필요도 있습니다.

냉장고도 주기적으로 청소하고 썩을 것 같은 음식을 버려줘야 합니다. 동일하게 주기적으로 필요 없는 문서는 삭제하고 동일한 문서들을 통합하는 등 문서들을 점검하는 시간을 가져야 합니다.

사무실 냉장고 속 음식은 넣어둔 사람이 관리해야 하지만 썩은 음식이나 빈 병, 빈 봉투, 빈 용기는 모두가 함께 관리하면 위생적이고 쾌적하게 이용할 수 있습니다. 문서도 작성한 사람이 주기적으로 관리 해주는 것이 제일 좋습니다. 하지만 모든 팀원의 관심과 참여는 문서 관리에 많은 도움을 주고 업무 비용을 절약할 수 있습니다.


노션은 글을 작성하는 재미는 있습니다. 하지만 남용할 수 있는 위험 요소도 많은 것 같습니다. 그래서 노션을 예쁘게 쓰는 것도 좋지만 의미있게 잘 쓰는 것도 중요하다고 생각합니다. 문서는 협업간 눈높이를 맞춰주는 도구입니다. 과거의 자신과 현재의 자신의 눈높이를 맞춰주고, 타인이 모르는 자신의 지식을 빠르고 제약없이 전달해 눈 높이를 맞춰 줍니다. 그래서 문서 / 노션을 모두 함께 잘 활용하면 좋을 것 같습니다.

읽어주셔서 감사합니다.

우리만의 데일리 미팅

열기는 매일 일정한 시간에 데일리 스크럼을 진행하고 있습니다. 개발팀은 애자일 방법론을 도입중이며 이 중 데일리 스크럼을 팀 전체로 확장해서 진행하고 있습니다. 문제는 팀 전체가 스크럼에 맞춰 업무를 진행하지 않거나 힘들고 업무 방식 또한 달라 정석적으로 적용하는데 어려움이 있습니다. 그래서 기본적인 방식과 규칙을 따르고 데일리 스크럼의 목적(Goal)과 세부 규칙은 저희만의 방식으로 진행하고 있습니다. 그럼 2021년 01월 기준의 데일리 스크럼을 소개하겠습니다.

더 보기 “우리만의 데일리 미팅”

개발팀이 일을 매듭 짓는 방법

열정에 기름붓기 팀 내에 공유하기 위한 목적으로 작성했습니다.
열기 개발팀 채용 👉 https://www.notion.so/passionoil/25bfaebf55284f04852608c1ff623712


프로젝트 시작 후 기획과 디자인/개발이 끝나면 QA, 배포 단계를 거쳐 유저에게 전달됩니다.
1년 넘게 같이 협업하면서 QA, 배포에 대해 대략적으로 얘기만 했지 제대로 알려드린 적이 없는 것 같아요.

최근 디자이너 심옹과 마케터 이든이 합류하고, 팀 전체 구조가 바뀌면서 개발팀의 업무 형태도 많이 달라졌습니다.

몇달 전만 해도 “퀄리티 보다는 속도” 중점으로 1주일 단위 업무 계획과 실행(스프린트), 그리고 커뮤니케이션을 최소화한 상태에서 기능을 빠르게 올린 후 터져나오는 문제를 실시간으로 해결을 하는 방식이었습니다.

지금은 적극적인 커뮤니케이션, 예측 가능한 계획과 실행, 위험 관리 등 속도를 조금 포기하고 디테일과 안전성을 확보하려 노력하고 있습니다.

때문에 QA와 배포 대한 중요도가 높아졌어요. 각각에 대해 한번씩 짚어보겠습니다. 여기에 더해 개발팀에서 요새 자주 얘기하는 “코드 퀄리티”에 대해서도 얘기해 보겠습니다.

QA

개발팀에서 “배포 전 QA를 해야 서비스가 터질 확률이 줄어든다”라는 말을 많이 했었습니다. 하지만 빠른 배포 일정으로 QA가 없거나 간단한 테스트만 거치고 출시하는 일이 잦았어요. 더불어 서비스가 터지고 버그가 발생하는 일이 많았습니다.

QA는 “Quality assurance”의 약자로, “품질 보증”을 의미합니다. 즉 개발한 기능과 제품이 우리가 정의한 수준 이상의 품질을 보증할 수 있도록 배포 이전에 각종 테스트와 검수 작업을 하는 겁니다.

좀 더 구체적으로 말하자면 기능 테스트와 더불어 기획한대로 결과물이 나왔는지, 기획 상 빈틈은 없는지, 디자인 상 이슈는 없는지, 개발팀에서 놓친 빈틈은 없는지 등 품질 보증을 위해 전반적인 검수를 하는 작업입니다.

QA 진행에도 시간이 들어가고, 수정 사항이 나오면 이를 수정하는데도 시간이 들어갑니다. 때문에 배포 일정이 늦춰지고, 팀 간 불화도 생겨 나죠. 개발팀에선 QA 일정을 개발 일정에 포함 시켜 일정 미루기와 불화를 최대한 피하려고 합니다.

QA는 업무 진행을 평가할 수 있는 최소한의 기준이다.

열기 팀에서 개발팀과 업무를 진행할 때, 기획/디자인/개발 이 세 파트가 서로 맞물려 진행됩니다. 각자 다른 파트의, 각자 다른 사람이 모여 하나의 그림을 그려 나갑니다. 업무에 참여한 팀원들 모두 같은 그림을 같이 그리고 있다면, QA 상 문제가 발생할 확률이 현저히 떨어지게 됩니다. 팀원들이 예측한 범위 내의 결과물이 나오니까요. 개발팀에서 기능 테스트만 잘 진행하면 됩니다.

만약 팀원들이 각자 생각하는 그림을 각자 그리고 있다면 예측치를 벗어난 결과물이 나옵니다. 기획과 다른 방향으로 구현된 기능에, 디자인도 잘 반영되어 있지 않고 심지어 너덜너덜 거리는 결과물이 말이죠. 당연히 QA 상 문제가 많이 튀어 나오고, 일정이 밀리게 되겠죠.

QA는 업무 초반 기획 단계에서부터 많은 영향을 받습니다. 그리는 그림이 팀원들에게 충분히 얼라인 되고, 깊게 생각해 디자인/개발 작업 이전에 빈틈을 찾고, 일정에 차질이 없다면 QA 단계에서 문제가 발생할 확률이 적습니다. 때문에 QA는 디자인/개발팀만의 전유물이 아니며, 참여하는 팀원들 모두가 QA에 영향을 주게 됩니다.

결국 “QA가 예측한 범위 내에서 문제 없이 잘 진행되었다”는 “프로젝트가 시작부터 끝까지 별탈 없이 잘 진행되었다”라는 최소한의 업무 평가 기준을 제시하게 됩니다.

QA를 디자인/개발팀에서 자체적으로 진행하고 있어 피부로 와 닿지 않겠지만, 참여한 모든 팀원의 영향을 받으니 꼭 신경써주시면 감사하겠습니다. 🤤🤤🤤🤤

현재 어떻게 QA를 진행하고 있나요?

몇 주 전까지는 러프하게 필요할 경우에만 QA를 간단하게 진행했지만, 지금은 새로 추가된, 수정된 모든 기능들에 대해 QA를 진행합니다.

현재(2020-12) 시점에서 디자인/개발팀과 협업하는 프로세스는 다음과 같고,

  1. 기획 및 아이디에이션
  2. 상세 일감 및 일정 산정
  3. 디자인 및 개발
  4. QA
  5. 배포

3번째 단계(디자인 및 개발) 완료 시 디자인/개발팀 내에서 자체적으로 진행하고 있습니다.

기획 단계에서 나온 유저 스토리보다 좀 더 기능에 포커스를 맞춘 유저 스토리를 재작성하고, 이를 노션에 테이블로 만들어 테스트 합니다. (심옹이 많이 도움을 주셨어요)
테스트 후 수정 사항을 반영하고 배포 단계로 넘어가게 됩니다.

배포

배포는 추가/수정한 기능을 앱/웹/서버에 반영하는 작업입니다.

우리가 만든 것들이 실제 유저에게 적용되는 시점이며, 개발 할때는 언제나 예측하지 못한 위험이 도사리고 있기 때문에 위험도가 높은 작업입니다.

크클 앱(ios/android) 배포는 항상 심사 / 업로드 시간이 걸립니다.

애플 앱스토어는 애플에서 우리 앱을 심사합니다. 심사에 통과해야만 앱을 배포할 수 있습니다. 배포 후 앱스토어에 반영되는 시간이 어느정도 있고, 반영되면 유저가 업데이트해야 우리가 추가/수정한 기능이 반영됩니다.

구글 플레이 스토어는 앱을 심사하지 않지만, 스토어에 반영되는 시간이 꽤 있고, 유저마다 이 반영 시간이 다릅니다. 대략 1시간 내지 많게는 2일 정도 까지라고 느껴지네요. 이 또한 유저가 앱을 업데이트 해야 우리가 추가한/수정한 기능이 반영됩니다.

앱 배포 시 최종적으로 스토어 반영까지 시간이 들기 때문에 배포 후 문제가 터질 경우 다시 반영하는데까지 시간이 소요됩니다. 때문에 앱 배포 시에는 QA가 정말 중요합니다.

앱 배포는 해달이 자동화하여 개발자의 번거로움을 줄여주셨습니다. 원래는 손으로 업로드 해야하거든요. (자동화 배포를 CD, Continuous deployment라 부릅니다.)

ios는 코드 반영 시마다 앱 심사 전 단계로 앱스토어에 업로드 합니다.
android는 코드 반영 시마다 테스트 단계로 구글 플레이 스토어에 업로드 합니다.

리뉴얼 하고 있는 웹사이트 기준으로 말씀드리겠습니다. – https://gathering.creatorclub.kr , https://creatorclub.kr

앱 배포와는 다르게, 수정 시 바로 바로 배포 가능합니다. 개발팀에서 우리 웹 서버에 코드를 반영하는 시간만 있을 뿐 입니다.

웹 배포 또한 오월이 자동화해주셨습니다.
코드 반영 시 선택적으로 자동 배포됩니다. 평균 반영 시간은 5분 내외입니다.

서버

웹과 마찬가지로 수정 시 바로 배포 가능합니다.
서버 배포도 오월과 새발(나)이 자동화 해주셨습니다.
코드 반영 시 선택적으로 자동으로 배포됩니다. 평균 반영 시간은 10분 내외입니다.

개발팀에서는 배포를 왜 두려워할까요?

“배포 시 문제가 터질 수도 있다”라는 것 때문에 개발팀에서 배포를 두려워 합니다. QA를 충분히 거치더라도 빈틈이 있을 수 있습니다. 심지어는 추가/수정한 기능이 건드리지 않은 기능에 영향을 주기도 해요.

그리고 문제가 터질 경우 기존 작업 계획에 영향을 주기 때문에 위험 부담을 최대한 줄이려는 노력을 하고 있습니다.

왜 점심에 배포하려고 하던게 다음 날로 밀리죠?

주로 타이트한 일정을 잡았을 때 많이 발생하고, 배포 직전에 문제점이나 빈틈을 발견해서 최대한 고친 후 배포를 하기 때문입니다.

코드 퀄리티

제가 아마 코드 퀄리티라는 말을 자주 했었을 겁니다. 코드 퀄리티는 말 그대로 코드의 퀄리티, 품질을 의미합니다.

우리가 만드는 서비스는 모두 “코드”로 이루어져 있습니다. 개발자가 하는 일은 코드를 추가하거나 수정해 기능을 구현해내는 것 입니다.

문제는 코드를 추가하고 수정하는 작업은 단순 타자를 쳐서 뭔가를 적는 게 아닌, 꽤 복잡한 작업이라는 겁니다. 코드는 다른 코드와 서로 얽혀 있기 때문에, 코드를 추가하거나 수정할 때마다 얽힌 코드에 문제가 없는지, 더 나아가 서비스를 구성하고 있는 데이터나 연동된 서비스에 문제가 없는지 지속적으로 체크를 해야합니다.

때문에 코드 퀄리티가 중요해집니다. 작성해 놓은 코드를 개발자들이 지속적으로 읽고 수정하기 때문에, 코드가 정리되어 있지 않으면 그만큼 작업 시간도 오래 걸리고, 버그 발생 확률도 높아집니다.

코드 퀄리티가 떨어지는 잘 정리되어 있지 않은 코드 비유:

코드 퀄리티가 높은 잘 정리되어 있는 코드 비유:

코드 퀄리티는 개발팀 말고는 아무도 모른다.

코드 퀄리티 관리 없이 기능 개발을 치고 나가면 어느 순간 개발팀 생산성이 저하되고 버그가 자주 발생합니다. 이때가 되면 개발팀은 코드나 기능을 리뉴얼 하거나 소위 “리팩터링”이라고 부르는 코드 정리 작업을 진행해야 합니다. 기능 개발과는 별개로 말이죠.

때문에 개발팀은 팀 전체의 우선순위와 긴급도, 요구사항 스펙을 보고 이번 기능 개발 때 코드 퀄리티를 챙길지 말지 생각해 상세 일감과 일정을 짜게 됩니다.

2개월 전쯤에 백조에게 “개발팀이 서비스 개발 일정 권한을 많이 가져가고 싶다”라고 했고, 허락을 받았습니다. 개발팀에서 앞서 언급된 QA, 배포, 코드 퀄리티까지 적당히 생각해서 일감과 일정을 가이드 드리고 있습니다. 혹여 정말 일정이 급한 경우에는 꼭 어필해주세요. 같이 얘기를 해봅시다. 🤤

현재 개발팀에서는 이렇게 코드 퀄리티를 관리하고 있어요.

코드 퀄리티 관리는 QA와 비슷하게 프로젝트 시작 단계에서 부터 시작합니다. 개발자 스스로가 기획, 아이디에이션 단계에 적극 임하지 않으면 요구 사항을 정확히 파악하지 못하며 이는 일감/일정 산정에 악영향을 주게 됩니다. 일정 막바지가 되면 이런 저런 문제가 터져나오고 결국 낮은 퀄리티의 코드로 일정을 최대한 맞추려고 하겠죠.

비슷한 얘기지만 일정 산정에 있어서도 관리가 필요합니다. 우선순위와 긴급도에 따라 달라지겠지만, 타이트한 일정은 낮은 코드 퀄리티를 유지할 수 밖에 없습니다. 일정이 타이트한 만큼 개발자가 설계하고 생각하는 시간이 적어지기 때문입니다.

개발팀 내부에서 서로의 코드를 리뷰해주려 노력하고 있습니다. 급할 땐 못하고 넘어가지만요🌝. 이와 함께 코드 작성에 대한 규칙, 앱/웹/서버 파트 별로 잡힌 아키텍쳐와 철학을 개발팀 내에 지속적으로 얼라인 하고 있습니다.

많은 도구와 방법들이 있지만 제일 효과적인 방법은 코드 퀄리티, 구조, 개발 철학에 대해 팀 내에서 많이 얘기하는 게 가장 좋은 방법인 듯 합니다. 저랑 해달만 있었을 땐 기능 개발만 하다가 코드에 대해서 주관이 뚜렷한 오월 합류 이후로 코드 자체에 대해서 얘기를 많이 하고 있거든요. 대화로 심어진 작은 씨앗이 몇 주 내 반영 되기도 합니다.

결론

QA, 배포, 코드 퀄리티에 대한 지식이 있다면 개발팀과 커뮤니케이션 하는데 많은 도움이 되실 겁니다. 최대한 쉽게 썼지만 어려운 부분이 있다면 언제든지 말씀해주시면 감사하겠습니다.

IT회사로 바뀐 지 1년 반정도 되었지만, 아직 개발팀이 팀 전체에 IT 지식을 잘 전파하지 못한 느낌이 들었어요. 앞으로 팀 블로그를 통해서 IT, 개발, 협업, 문화에 대한 지식들을 자주 공유하도록 하겠습니다.

그때는 맞고 지금은 틀리다 – 코드 오너쉽

새발의 개발 회고

XP(extreme programming)을 좋아한다. 오랜 생각인 “개발은 도구다”를 극대화할 수 있는 게 바로 XP라서.

xp에서는 여러 실천법과 규칙을 제시 하는데, 그 중 코드와 프로덕트에 대한 오너쉽을 개발팀 전체가 가져가는 collective ownership 이 앞서 말한 생각을 극대화 해주는 중요 포인트다.

현재 크클 개발팀은 3명이며, 이번 해 7월 까지는 2명이었다. 팀이라고 부르기 애매한 규모다. 때문에 개발 문화와 프로세스는 개발팀 리드인 내 취향이 많이 묻었다. 코드 오너쉽에 대해서도 내 취향이 두드러졌다. 앞서 말한 “개발은 도구다”라는 생각은 자연스레 “크클 개발팀은 앱/서버/웹 넘나들며 개발할 수 있어야 한다”로 이어졌다. 좋은 팀원들 덕에 내 생각은 큰 무리 없이 개발팀에 적용됐다. 그리고 크클 개발팀의 강점으로 자리잡았다. 백조(대표)도 나름 개발팀을 자부하는 듯 했다. 앱 출시 후 1년간은 그렇게 큰 문제가 없었다.

크클 앱은 퀄리티를 낮추는 대신 굉장히 빠르게 개발되었다. 기억으로는 2019년 8월 말 쯤 기획과 디자인을 시작했고, 10월 초~중순 쯤 첫 버전을 릴리즈 했다. 워드프레스로 만들어져 있던 크클 웹사이트를 유지하며 새로운 DB와 서버, 새로운 앱을 개발했다. 개발 시작은 혼자 했고, 개발 중간에 짱짱 개발자 “해달”이 합류했다. 첫 릴리즈 약 한달 후가 되어서야 스프린트를 도입 했고 스프린트 주기는 1주일이었다. 평균 1.7주에 한번 정도 크고 작은 릴리즈를 진행했다.

1년이 지나 2020년 8월이 되었다. 퀄리티나 버그 발생 빈도, 관리자 사이트가 좀 아쉬웠지만, 릴리즈 빈도는 만족스러웠다. 일정과 버그, 유저 CS말고는 평화로웠다. 그런데 갑작스럽게 그동안 조용히 쌓이던 기술 부채, 주로 코드 복잡도가 개발팀의 발목을 낚아챘다. 깊이를 알 수 없는 물탱크에 물을 계속 붓다가 어느 순간 물이 넘쳐서 도저히 막을 수 없는 그런 느낌이었다. 다행인 건 넘치는 물이 익사할 만큼은 아니라는 것.

그리고 그제서야 부랴부랴 리뉴얼과 리팩터링을 진행했다. 새로운 피쳐 개발과 유지보수와 함께 해야했기 떄문에 진행이 더뎠다. 2달 정도가 지난 지금 약 40%정도의 중요한 기능들을 리팩토링, 리뉴얼 했다. 아마 내년 1분기 내로는 끝나지 않을까 싶다.

높은 코드 복잡도가 가져다 주는 악영향은 매우 크다. 일정 예측 실패나 버그 발생 빈도를 높이는 것도 높이는 거지만, 개발자의 의욕을 낮추고 두려움을 키우는 게 제일 문제라 생각한다. 빠르게 첫 버전을 릴리즈해야 했기에 크클 코드 베이스는 그렇게 좋지 않았다. 서버 구조도 큰 신경을 못썼고, 워드프레스로 만들어진 기존 사이트를 새로운 앱/서버와 함께 운영해야 해서 각 시스템 사이의 간극을 맞추기도 어려웠다. 복잡한 코드 베이스와 환경에서 빠르게 기능을 치고 나가야 했다. 서비스 상에서의 비지니스 로직이 정립되지 않아 기능에 대한 룰도 자주 바뀌었다. 새로운 기능을 릴리즈 하면 그 다음 기능을 개발하는데 다시 몰두 했다.

위 상황에서 리팩터링할 시점을 잡지 못한 게 근본적 원인이다. 리팩터링은 사치라고 생각했고, 그저 새로운 기능 개발에만 매달렸다. 그땐 이 생각이 맞았고 지금은 틀렸다.

맨 처음 언급한 collective ownership의 가장 큰 장점은 개발팀 전체가 코드와 프로덕트에 대한 오너쉽을 모두 가져가 개발팀 누구나 기능 개발과 유지보수를 할 수 있도록 하는 것이다. 빠른 기능 개발에 대한 은탄환 같이 보인다. 내 실수이기도 하지만, 여기서의 가장 큰 맹점은 “코드, 서비스, 개발 환경에 대한 품질 관리”가 전제가 되어있어야 한다. 이는 xp의 다른 실천법에도 언급되고 관리된다. 예를 들어 TDD, CI, 코드 디자인 개선 등. 나는 “빠른 개발, 높은 릴리즈 빈도, 개발은 도구다”라는 생각에 갇혀 이것들을 등한시 했다.

이제는 챙겨야 하고, 부랴부랴 챙기고 있지만 문제는 개발팀의 프로세스와 문화에 녹아들 때 까지는 시간과 비용이 들어간 다는 것. 그리고 계속 새로운 기능 개발을 치고 나가야 한다는 것. 동시에 두가지를 하기엔 아직 개발팀은 작고 소중한 자원이다. 묘수가 필요하다.

묘수라고 하기엔 너무 간단하지만, 개발팀에서는 collective ownership을 유지한 채 프로젝트 별로 약한 code ownership을 가져가도록 했다. 현재 웹/앱/서버 이렇게 총 3개의 프로젝트를 각 개발자가 하나씩 들고 갔다. 오월은 웹을, 새발(나)은 서버를, 해달은 앱을.

각 프로젝트에 대한 코드 오너쉽을 가지면 아래와 같은 역할을 맡게 된다.

  1. 해당 프로젝트에 코드 복잡도를 관리하고 구조와 방향성에 대한 권한을 제일 크게 가진다.
  2. 프로젝트에 리팩터링이나 리뉴얼이 필요할 경우 일감 범위와 일정을 조절할 수 있다.
  3. CI/CD, 자동화, 개발 환경 개선, TDD나 QA등 등 품질을 높일 수 있는 여러 도구들을 도입할 수 있다.

러프하게 2달 정도 시행했지만 코드 품질과 구조가 굉장히 깔끔해지고 있다. 당연하게도 릴리즈 빈도는 줄어들었다. 조금 불안했지만 좋은 트레이드 오프라 생각했다. 크클 개발팀은 앞으로 더 많은 기능들을 탄탄하고 적은 비용으로, 적은 스트레스로 개발할 수 있을 것이다.

회사의 막내가 TF리드가 되었다. 그 회고

우리 회사의 CTO(Chief Technology Officer, 최고 기술 개발자)인 새발은 항상 문제가 발생하면 말하곤 했다.

이 문제에 대한 원인을 파악해야합니다.

이전까진 왜 그가 문제의 원인에 집착하는지 몰랐다.

그런데 최근 마케팅의 강력한 툴 중 하나인 회사 서비스 체험권 tf팀의 리드가 되면서 새발의 말을 이해할 수 있었다. 웁스! 실무 1년차인 나에게 이런 중요하고 큰 사이즈의 프로젝트가 떨어지다니!
이 사실은 알바로 회사에 발을 담근 나의 성장이 증명됨과 동시에
업무 경력이 없는 나의 약점을 남들보다 두 세배로 학습하며 더 탄탄히 다지며
운전을 시작해야한다는 사실의 시발탄이었다. 걱정대로 문제는 시작과 동시에 터졌다.
여기서 리드인 내가 실수한 첫 번째 문제.

아무리 뛰어난 능력을 가진 팀원이라도 문제와 목표에 공감이 되지 않으면 당연하게 능력을 발휘하지 않는다, 아니 발휘할 수 없다. 이들의 능력을 200%까지 끌어 올리는게 리드의 역할이다.
나는 처음부터 자신 없는 태도로 회의를 이끌었다. 그러면서도 강압적이었다.
TF(Task Force의 약자,어떤 과제를 성취하기 위해 필요한 전문가들로 구성되고 기한이 정해진 임시조직)라는 틀에 갇힌것일까.
압도적인 속도만이 성과라고 생각했던 탓에 이미
구상해놓은 그림이 아니면 팀원들이 낸 의견이 들리지 않았다. ex)이 날 테스트 발송을 하면 문제가 생길수도 있어요. 꼼꼼히 다지고 가는게 맞는 방법일 수 있습니다.

조금 늦은 사후 회고방식을 도입해서 원인을 찾아봤다.
내가 Pm의 역할을 정말 이해했다면,
위 의견에 대해 재고해보고 일정을 무리해서 타이트하게 잡지 않았을 것이다.
그랬다면 이용권 미지급이라는 실수를 범하지 않고 체크할 수 있는 시간이 분명 확보 되었을것이다.
또 그랬다면 소중한 자원인 개발자의 피로도를 늘리지 않았을것이고 개발의 디테일은 올라갔을것이다. 그러면 함께하는 팀원들과 나는 불안함은 줄고 tf팀을 위해 생각하는 시간이 늘었을것이다.
나는 안해도 되는 실수를 경험하고서야 이 사실을 깨달았다.
결국 커뮤니케이션 비용이 올라갔고 TF 초기에 설정한 목표 자체는 달성하지 못했다.

실수는 아프지만 대신 되풀이하지 않을 반사신경을 만들어준다.
5why방식에 의거하여 문제가 발생한 원인을 찾아보자.

문제1

질문은 ” 기획은 빨랐다. 그런데 왜 리드는 예상 일정을 정확하게 예측하지 못했나.”

  • 문제 : 회의 자리에서 개발일정까지 모두 결론 내려야 했다는 생각에 사로 잡혔다. 개발에 대한 이해도가 없는 상태이기 때문에 무리한 일정이라는 사실을 인지하지 못했다.

→ 그렇다면 문제의 원인은 무엇일까?

  1. 왜 회의 자리에서 사이즈와 일정까지 모두 확정해야했나: TF체험권의 검증 기간은 3주였기 때문에 일정 내 개발과 배포가 진행되지 않으면 검증이 불가했다. 담당 PM은 목표 달성을 위해 빠른 일정이 필요하다고 판단했다.
  2. 왜 목표 달성을 위한 다른 방법을 검토하지 못했나: 마케팅 시즌이 다가오면 기존 업무를 수행하는데도 빡세기 때문에 유일하게 가설 검증이 가능한 시간이라고 판단했다.
  3. 왜 리드는 다른 방법을 고려하지 못했나: 다른 방법을 고려하는 시간을 쏟기엔 TF의 기간이 짧았다.
    개발팀의 리소스 부족을 인지했기 때문에 해당 회의에서 빨리 결론을 내려야 했다. 팀원과 닫른 방법을 논의해서 다시 결정하기 어려운 상황이었다.
  4. 왜 일정대로 업무를 진행해야했나:일정보다는 해당 TF에서 홈페이지를 구축하여 절대 숫자보다는 검증 자체가 중요했다. 일정이 더 걸리더라도 확인하고자 하는 가설을 검증하는게 먼저니까. 우선순위를 나중에 깨달았다.

질문을 종합해보면 개발 일정이 미뤄진 것이 문제라기보다 정확한 일정을 추정하는 과정에서 시행착오가 있었다. 일정 추정이 불확실한 데는 크게 두 가지 이유가 있었다.

  • 개발 일정을 논의하기 위한 명확한 문서가 없었다. 문서가 없으니 관련 개발의 사이즈 검토도 회의자리나 구두로 대략적인 수준에서 이루어졌다. 담당 개발자가 대략적인 일정을 말하면 리드는 그 일정이 픽스라고 생각했다. 정확한 일정을 잡으려면 QA를 돌려서 필요한 기능이 무엇인지 기획이 탄탄해야했고 개발자는 코드를 까봐야 정확한 일정을 산정할 수 있다.
  • 지표에 너무 초점을 맞춘것. 진짜 중요한점은 가설 검증에 있었다. 일정이 촉박한 상황이라 빠르게 일정을 논의하고, 빨리 개발해야한다는 생각이 지배적이다 보니 해당 회의 자리에서 일정을 모두 논의하고 결정하게 되었다.

문제2 현장 매니저들과의 소통

나에겐 당연하지만 그들에겐 당연하지 않았던 사실

  1. tf리드는 팀장급의 업무 지시 권한을 갖는다
  2. 이 tf는 회사의 중요한 프로젝트이다.
  3. 커뮤니티매니저의 업무 리소스를 고려하여 기획을 한다.

정보의 비대칭은 의구심을 낳는다.

그들의 의구심

  1. 홍이가 왜 팀장급의 업무 지시 권한을 갖게 되었는가 -홍이는 tf성공 경험이 있는 팀원이며, 우리 회사에서는 업무적 성과를 이룬 팀원에겐 더 많은 기회가 주어진다.
  2. 내가 이 일을 왜 해야하지? -pm은 미리 목표에 aligin을 시키지 못했다. 더 나아가 회사에서 진행하는 프로젝트에서 자주 현장 매저니들과 자주 얼라인이 되지 않은채 일을 실행했다.
  3. 왜 커뮤니티 매니저의 리소스를 고려하지 않고 기획을 하지? -기획단계에선 현장 매니저들의 리소스와 생각을 상당 부분을 고려하여 진행한다. 정보의 공유가 부재했다는 사실을 인지하고 기획의 의도와 공지사항을 전달했을 때 현장 매니저는 납득하지 못했고 그 이유를 리드에게 물어보지 않았다. 사무실과 현장의 신뢰감이 없다.

현장에서 근무하는 팀원들이 이 사실을 당연히 알 거라고 생각한 곳에서부터 갭은 시작되었다.
이 사실은 이번 tf팀에서의 문제로 시작 되었지만 그간 사무실과 현장매니저들과의 정보 공유가 얼마나 안되어 있었는지 수면 위로 드러나게 되었고 원인을 발견했으니 다양한 해결책이 될 법한 것들을 시도해볼 수 있었다. TF팀에 현장 매니저 합류, 팀 채널에 지점장 합류, 공지 채널 오픈, 전달 내용은 구두가 아닌 문서 작성으로등의 방식이었다.
이후에 문서로 공유함에도 불구하고 병목은 생겼기 때문에 이 문제는 아직은 ing가 맞는 것 같다.

해결책을 적용하고 평가하기

문제의 근본적인 원인을 찾아냈으니 해결할 방법을 고민한다!
이번 TF팀의 경우 문제 발견과 동시에 바로 해결책을 적용해보았다.
개발 일정 산정이 어렵다는 문제는 2가지 근본 원인

  1. 개발 스펙을 논의하는 문서가 없다.
  2. 목표달성 때문에 일정에 대한 압박이 컸다.

이에 대한 해결책은 아래와 같다.

  1. 협업 문서를 작성한다: 이 문서에는 기획에 담긴 내용을 어떻게 개발할지, 서로의 생각을 동기화하는 싱크업 미팅, 일감/일정 산정,유저 스토리보드를 QA템플릿을 이용해 진행한다. 이후 추가 수정 사항, 버그가 발생할 경우 2차로 추가 작업을 진행한다. 타임라인을 병렬적으로 확인할 수 있어야한다. 아이데이션 문서도 작성한다. 작은 것이라도 좋으니 아젠다와 얼라인, 아이데이션의 목표는 꼭 도출한다.
  2. 매주, 계획했던 목표와 일정에 문제가 없는지 논의하고, 팀원들과도 주기적으로 목표나 일정을 조정해나간다.

목표지표를 보자면 이번 TF실패했지만
협업시 발생하는 자주 발생하는 문제들의 원인을 파악하여 수면 위로 올렸고, 툴의 검증을 이뤄냈다는 점에서 개인적으로 만족스러운 TF리드 경험이었다고 말할 수 있다.

팀원은 딱 리더의 그릇만큼 따라준다.

서른되기 4일 전이다. 올해는 내 인생에서 가장 다이나믹 했다. 고난과 역경이 그저 고난과 역경의 시간으로 기억되느냐, 학습과 성장의 경험으로 남느냐는 한끝 차이다. 포기하고 싶은 마음이 굴뚝 같고, 다 놓고 싶은 마음이 굴뚝 같지만 여기까지 버텨내고 이끌고 온 열정에 기름붓기의 나를 포함한 구성원들이 억울해서라도, 철저히 학습하고 성장해야겠다고 결심했다. 

올해 깨달은게 있다면, 결국 ‘리더’의 책임감, 리더의 역량, 리더의 역할이라고 정의하고 싶다. 돌아보면 부끄러움으로 가득하다. 나는 항상 원망하고, 기대하기만 하는 리더였던 것 같다. 잘하고 싶다는 의욕만 앞섰지 구체적인 how to를 제시하지 못하고, 혼자 심장 두근 거리며 꿈꿨지 팀원들이 심장 두근거리게 만들지는 못했다. 열정과 진정성만으로, 어린 소년에게 마라톤 완주를 뛰어야 한다고 강요했던 것이 나다. 

이번 시즌, 처음으로 이런 생각을 했다. 내가 이렇게 힘들고 복잡한데 팀원들은 얼마나 머릿속이 복잡할까? 나도 how to를 찾지 못하고 전전긍긍하는데 그 옆에서 함께 연말 저녁까지 야근하는 팀원들은 얼마나 힘들까? 나는 대표랍시고, 우리가 함께 이뤄낸 것들에 대한 모든 찬사를 받는데 그 뒤에서 조용히 함께 뭔갈 이뤄낸 팀원들은 무엇을 받았을까? 

스타트업이니까, 멋진일을 하고 있으니까 라는 그럴듯한 말 속에 갈리고 희생되어지는 우리 팀원들의 소중한 젊음에 대해서 나는 어느 정도 무게감을 가지며 살아왔을까? 

어설프게 설계된 BM, 어설프게 짜여진 조직도, 어설프게 주어진 R&R 사이에서 여기까지 따라와준 팀원들을 생각하니. 주말에 넷플릭스 켜고 치킨이나 쩝쩝 거리면서, 사업한걸 후회하곤 하는 내 자신의 모습이 너무나 부끄러워졌다. 

리더의 자리는 원래 외로운 것이라고, 팀원들은 절대 대표의 마음을 모른다고. 
회사가 망하면 팀원들은 떠나지만 대표는 오롯히 그 책임을 져야 하기 때문에 너무 감정이입할 필요 없다고 외부에서 그리고 내 내면에서 최면걸듯 이야기 하곤 했었다. 

나는 매번 같은 결론을 만났다.
그럼 이러한 고난과 역경을 견뎌내며 도대체 왜 사업을 해야하는 것일까? 나는 왜 그 책임을 져야하고, 그렇게 까지 해결하고 싶다는 문제에 얼마나 강한 사명감을 가지고 있는 걸까? 
정든 사람을 내 손으로 떠나 보내고, 절대적으로 역량이 거기까지인 사람에게 채찍질 해대며 성장을 강요하는 것이 대표의 어쩔 수 없는 숙명이라면, 난 나약해서 못한다. 

예전에 존경하는 대표님에게 물어본적이 있다. 
“대표님은 왜 사업을 하냐고” 
그럴듯한 대답을 기대했는데 의외로 심플했다. 
“함께하고 싶은 멋진 사람들과 계속 재미있는 도전을 하고 싶다고”

그땐 참 겸손한 대답이라고 생각했는데, 가장 어렵고 또 내가 원하는 모습이 되었다.

회사의 지표가 만족스럽지 않은데, 아무렇지 않은 표정으로 퇴근하는 팀원들을 보며 밉고 서운하다 생각했던적이 있었다. 팀원들과 우리의 비전과 목표에 대해 더 공감하고 공유하고 싶어 술먹자고 했는데, 매몰차게 약속있다고 돌아서는 모습을 보면서, 저 사람은 우리회사가 어렵고 위기가 오면 누구보다 먼저 돌아서겠구나, 우리 사이의 관계는 월급으로 이어진 그 이상 그 이하의 관계도 아니구나 자책할 때도 있었다. 주말에 다같이 모여 스터디를 하고, 퇴근하고 같이 직무 학습을 하자고 제안했을 때, 기뻐하지 않는 팀원의 얼굴을 보며, 성장하고 싶다는 말은 다 개뻥이구나 라고 생각했던 적이 있었다. 쓰고 보니 나는 미친놈이었던 것 같다. 그건 나도 힘든 일이다. 내가 팀원이었으면 그렇게 할 수 있었을까? 되묻는다.

팀원은 딱 대표의 그릇만큼 따라준다. 

난 항상 열심히 잘 해낼 수 있을 줄 알았는데, 올해는 정말 그렇지 않았다. 제대로 된 how to를 스스로 찾지 못하는 상황에서, 일을 손에 잡는 것 자체가 어려웠다. 절망적이고 막막한 상황에서 방법만 안다면 어떻게 해보겠는데 그 방법을 모르겠는 나는 빠르게 지쳤고 학습, 회고를 외쳐댔지만 정작 진이 빠진 주말 난 아무것도 못했다. 

그게 내 그릇이었고, 난 내가 해결하지 못하고 나도 할 수 없는 수준의 노력과 문제해결을 팀원들에게 바랬다. 폭탄이 떨어지는 전쟁터에, 나무 소총 하나 쥐어주고 일제 돌격을 외치던 소련군과 정신력으로 모든 걸 극복할 수 있다고 말하며, 미드웨이 해전을 벌인 일본군. 그들과 나는 무엇이 달랐는가를 회고해본다.  

우리팀은 멋지게 해내고 있다. 결국 달성한 목표를 찍어내고, 어떻게든 문제를 해결하고 있다. 하지만 같은 방식으로는 더이상 어렵다. 라고 생각했다. 

좋은 제품을 만드는 것, 좋은 조직문화와 워크프레임을 설계하고 지속하는 것, 좋은 대표가 되는 것이 세개의 중요성에 대해 어느정도 몸으로 깨달았다.

애초에 내가 잘하는 것과, 내가 지금 하고 있는 ‘대표’란 직책. 잘하는 것과 하고 싶은 것 사이의 딜레마가 껴있다. 

어쩌면 나는, 내 20대에 그토록 꿈꾸고 동경했던 스타트업의 대표가 되는 것은 어려울 수도 있겠다. 사업을 시작하고 상상했던 스물아홉의 나는 되지 못하였다. 

하지만, 적어도 이제 좋은 대표가 어떤 사람인지, 좋은 회사란 어떤 회사인지에 대한 위대한 거인들의 인사이트를 나름대로 깊이 공감하며 끄덕일 수 있는 깊이는 얻었다 생각한다. 

성공과 실패는 하늘의 뜻이다. 내가 믿을 수 있는 것은 팀원 밖에 없다. 대표가 어디까지 견뎌내고 어떤 모범을 보여주는가가 가장 중요하다 생각한다. 그 외의 방법도 있겠지만, 내 부족한 능력으로는 할 수 없음도 인정했다. 

서른의 내 리더쉽은 이렇게 정의하기로 했다. 

팀원은 딱 리더의 그릇만큼 따라준다.
내가 어떤 태도 어떤 집념 어떤 진정성을 보여주느냐에 따라 같은 팀원도 다른 사람이 된다. 
실패는 결과가 만드는 것이 아니다. 결과 앞에 마주선 팀이 더 가는것을 멈춰섰을 때다.

조직 문화

조직 문화에 대한 고민이 많다. 원하는 것은 목표 달성과 성장. 

이 둘은 뗄레야 뗄 수 없는 사이이다. 
최대한으로 노력하고, 원하는 성과를 얻었을 때 
성장한다. 

회사의 성장은 팀원의 성장 없이 불가피 하다. 
회사가 성장함에 있어, 특정 인원만 성장한다면 더 큰 성장을 시작할 수 조차 없기 때문이다. 

조직원의 평균치가 성장 값이다. 

도대체 이 회사에서 왜 일해? 라고 물었을 때, 
이 회사는 내가 원하는 성장을 만들어 낼 수 있으니까 라는 대답이 나올 수 있는 조직이 되어야 한다.

대표도 사람이고 팀원도 사람이다.
사람과 사람이 모여 하는 것이 일이다. 

일과 감정을 분리하는 것은 끝까지 포기하지 말아야 할 이상이다. 

심플하게 생각한다. 서로 원하지 않으면 헤어지고, 서로 원하면 함께 하는 구조가 되어야 한다.

여기 아니면 다닐 곳 없어서, 일이 편해서, 급여가 쎄니까로 초기 멤버를 설득하면 그 조직은 점점 더 그런 조직이 될 것이다. align 없이 성공한 조직은 작은 성공을 이루더라도, 절대 큰 성공은 못 만들어낼 것이라고 믿는다.

두가지 방법을 생각한다. 

압박과 동기부여. 
이 두가지가 적절하게 수행되어져야 한다. 결과적으로 성공 경험을 만들면 어떻게든 성장할 수 있다. 운으로 성공하는 경험이 실패보다 최악이다. 

좋은 압박이란 보이는 길을 열심히 달리게 만드는 것이고 나쁜 압박이란, 어디로 가야할지도 모르는 길을 무작정 달리게 만드는 것이라 생각한다. 

동기부여란 호기심이다. 빛을 보며 두근거리는 도전을 상상하고, 이것이 이뤄졌을 때 어떤 결과가 만들어질 수 있는지를 생각해야 한다. 

물질적 보상은 이뤄낸 것에 대한 배분이지, 결코 동기부여를 만들어 낼 수 없다. 이 게임은 오래 계속가야 하는 게임이기 때문이다. 

모두 다 어렵다. 하지만 하나는 생각한다. 나는 사람이다. 그것도 부족한 사람. 솔직하게 말하는 편이 중요하다고 생각한다. 나의 감정적 해석이 발생해서 해당 팀원의 성과를 못 보는 일이 생길 것 같다면 그자체도 이야기 하는 편이 맞다고 생각한다. 

작은 기업은 결국 대표와 팀원들의 끈끈한 신뢰와 상호간의 애정에서 폭발적인 힘을 발휘한다 믿는다. 

두려워하지말자. 해야될 일을 하자.