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

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

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

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

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

제목만 있는 문서

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

깊숙이 있는 문서

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

이해할 수 없는 문서

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

업데이트가 없는 문서

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

썩지 않게 관리하기

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

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

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

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


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

읽어주셔서 감사합니다.

우리만의 데일리 미팅

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

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

💻 개발팀 막내의 업무환경을 소개합니다~

Ultimate Office Desk Setup

안녕하세요. 저는 크리에이터클럽 막내 개발자 오월 입니다. 오늘은 저의 업무환경을 소개하려고 합니다. 우선 제일 중요한 노트북부터 소개하겠습니다.

노트북

MacBook Pro (15 인치, 2018년 형)
2.6 GHz 6-Core Intel Core i7
16 GB 2400 MHz DDR4

애플 제품은 가격이 비싸고 관공서 업무에 불편함이 있습니다. 또한 윈도우와 파일을 주고 받을 경우 파일이 손상되는 문제도 있고 한컴오피스의 사용에도 불편함도 있습니다. 윈도우와 비교해서 큰 차이는 없지만 오래 사용해서 익숙함 때문에 바꾸지 못하는 것이 큰거 같습니다. 😥 굳이 장점을 하나 쓰자면 터미널이나 기본 프로그램 폰트가 윈도우에 비해 가독성이 좋습니다.

모니터

선 하나, 단 하나

제가 사용하는 모니터는 DELL U2719DC 입니다. 27인 QHD 해상도에 USB-C PD (Power Delivery) 를 지원합니다. PD를 지원하는 경우 가격은 더 비싸지만 USB-C 충전을 지원하는 노트북과 함께 사용하면 한개의 캐이블로 충전과 모니터 출력을 동시에 할 수 있어 선 정리가 편해지는 장점이 있습니다. 또한 델의 모니터의 경우 옆에 USB 포트가 있어 독이나 허브를 추가로 구입하지 않아도 되는 장점이 있습니다.

하지만 맥을 과로 시켜 충전하는 속도(64W)보다 많은 베터리를 사용하게 된다면 충전이 정상적으로 되지 않는 문제가 있습니다. 이점은 맥북 프로 15인치와 해당 제품의 조합 특성으로 낮은 전력에도 충전되는 경우 크게 문제되지 않습니다.

키보드

아래 손목 받침대는 6년동안 저와 함께한 친구입니다. 사무용품 파는 데서 아무거나 구매하고 해피해킹에 맞게 잘라서 사용했는데 오래 쓰다보니 모서리는 마모되고 손에 자주 닿는 면은 파였습니다.

6년전 열기 CTO 새발의 해피해킹을 보고 처음 알게되었습니다. 컴팩트한 사이즈와 특이한 배열이 마음에 들어 HHKB 검정 먹각 제품을 구매했습니다. 그리고 이 회사에 이직하면서 저에게 주는 이직 선물로 흰색 무각 무선제품을 구매하였고 전에 사용하던 것은 집에서, 새로산 것은 회사에서 사용하고 있습니다.

해피해킹은 키 배열이 특이하여 진입 장벽이 높고 비싸고 방향키도 키 조합으로 입력해야 하는 단점이 있습니다. 하지만 개성적인 디자인에 키감이 좋고 맥 환경에서 단축키에 핵심이 되는 커맨드의 크기가 시원시원해서 좋습니다.

빅스비 스티커는 2018년에 받았던 스티커를 얼마전에 찾아 어울리거 같아서 붙였습니다.

하이 빅스비, 코딩 대신해줘 ~

타임 타이머

타임 타이머는 회의나 업무 집중도에 도움을 주는 도구입니다. 시간을 당기면 붉은 색으로 남은 시간이 표시됩니다. 회의 시작전 회의 시간을 정해주고 남은 시간을 확인하며 시간 분배에 도움을 주고 업무에서는 분단위의 작은 업무들을 계획하고 시간을 확인하며 긴장감을 주어 집중도를 높여줍니다.


오늘은 저의 업무에 도움을 주는 도구들을 소개해봤습니다. 다음에는 제가 사용하는 프로그램들을 소개하면 좋을거 같습니다.

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

새발의 개발 회고

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