일하는 방식은 모든 곳이 다릅니다
안녕하세요, 유진호입니다. 오늘은 저희가 일하는 방식을 한번 적어보려고 합니다. 그 전에 앞서서 꼭 제가 이야기하고자 하는 바가 있습니다. 그것은 이것입니다.
일하는 방식은 모든 곳이 다릅니다
왜 이 말을 먼저 꺼내냐면, 이런 이야기들을 너무 많이 들었기 때문입니다.
•
우리는 왜 구글이나 네이버처럼 근본적인 기술에 대해 다루지 않아요?
•
우리는 왜 ‘온전하게' 애자일이 아닌가요?
•
우리는 왜 Jr.입사자들에게 책을 읽으라고 하고 시간을 주나요?
•
귀찮은 분기별 1:1미팅은 왜 자꾸 하죠?
Ticketplace는 Ticketplace입니다. 초기 투자를 받은지 얼마 안 되었고, 아주 고급 경력자는 드물고 이제 경력을 시작하려는 사람들이 대부분입니다. 그러다 보니 고급 개발자를 비싼 연봉으로 팍팍 데려올 수 있는 구글이나 네이버처럼 일할 수가 없습니다. 지금 돌리는 서비스를 안정적으로 개발/운영이라도하는게 큰 일입니다. 특히 대부분 사람들이 경력이 없거나 적은 사람들이다 보니 이 사람들이 어느 정도 같은 수준의 기술 눈높이를 가지게 하는 것은 쉽지 않습니다.
그러다 보니, 1. 최대한 개발해야 하는 것은 명확하게 정의해서 개발합니다. 2. 1.이 되려면 일정을 추산할 수 있을 만큼 명확해야 합니다. 3. 그러기 위해서 이미 기획팀과 충분히 이야기하고 의사결정이 된 것을 개발하지만 언제든 이것은 변할 수 있기에 기획팀과 같이 의논해서 일정을 조절합니다. 4. 각자의 업무성과와 상황을 알기 위해서 지속해서 업무상황을 과정마다 서로 피드백 받습니다.
지금 소개해드리는 방식은 저희가 ‘지금’ 일해오면서 ‘생존하기 위해' 만든 전략들이라고 생각하시면 됩니다. ^^ 비즈니스가 성장하고 해야 하는 일들의 규모가 커지면서 또 저희는 다른 모습이 되겠다고 생각합니다. (그러니 귀엽게 봐주시면…)
입사해서 첫날하게 되는 일 - 안내 문서 읽기
모든 사람들이 봐야 하는 문서
요새는 대부분 회사들이 입사시 정보를 정리해놓는 문서정도는 다 가지고 있지요. 저희도 이런 정보들을 모아놓은 문서가 있습니다.
개발팀이 보는 문서
첫날 출근해서 오시면 제가 [티켓플레이스에서 개발자/디자이너로 일 시작하기]라는 Notion의 문서를 전달합니다. 이 문서에는 여러 가지 내용이 있습니다. 사실 세부적인 내용들은 회사기밀(?)도 있어서 다 못 보여드리지만, 목차는 보여드리겠습니다.
이 문서는 개발팀에서 일을 어떤 식으로 해야 하는지 나름 상세하게 일하는 방법들을 전달하고 있습니다. 사람이 붙어서 이 문서들을 하나하나 설명해주지는 않습니다. 대신에 ‘이 정도 읽었으면 CTO와 면담을 신청하세요'라고 중간마다 Check point 들을 잡아놨습니다. 면담을 신청하면, 저는 읽은 부분까지 확인 하고 질문을 답변하고 있습니다. 이 문서에는 3곳의 Check point가 있으니 3번 이상 저와 질문 답변을 하게 됩니다.
이렇게 하는 이유는, 1. 일하면서 필요한 정보들을 한곳에서 알 수 있게 해줍니다. 2. 규칙을 오해하거나 정보를 몰라서 일을 못 하는 일을 줄입니다. 3. 가끔 대면으로 이야기를 해야 글로 표현이 안 되는 부분까지 전달되더라고요.
그리고 이 문서는 계속 수정되는 문서입니다. 저희도 일을 해나가면서 몰랐던 일들이 생기기도 하고, 새로운 정보가 필요한 경우도 있습니다.
저희는 Slack의 Pin기능도 잘 쓰고 있습니다. 아무래도 업무용 메신저로 Slack을 많이 쓰고, 채널별로 뭔가 같이 봐야 하는 정보들이 있으면 Pin이 오히려 나았습니다.
새로운 기능을 개발하는 순서
저희는 위의 이미지에서 보이는 것과 같이 제품을 개발합니다. 사실 요구사항 정리되고 그러면 그냥 개발하면 되는 거 아니냐 할 수도 있겠지만, 실제 일을 해보면 ‘뭐부터 해야 해?’라는 문제가 많이 생겼습니다. 일하는 과정이 사람마다 다르다 보니 진행하다가 뒤늦게 빼먹은 문제들이 발견되면 일 하는 시간이 지연되곤 했지요. 그래서 이런 Process를 만들었습니다.
조금 쉽게 적어보면, 이런 순서로 개발을 진행하게 됩니다.
1.
고객의 요청이나 아이디어를 수집
2.
해결해야 하는 문제 선정
3.
Tech spec작성
4.
Kanban으로 구성된 개발 Pipeline으로 진행
a.
Ticket 작성
b.
Ticket들 구현
5.
내부 데모와 Release여부 검토
6.
Release
사실 다른 것들은 비슷하게 선정하겠지만 저희만 조금 독특한 부분을 설명해 드리면 이렇습니다.
Tech spec 작성하기
Tech spec이란, 기획과 개발이 같이 어떤 기능을 어떤 방식으로 개발하겠다는 것을 합의하는 문서라고 생각하시면 됩니다. 보통 애자일 개발을 지향하는 조직들이 ‘문서는 안 만드는 것'으로 하고 대충 요구사항 분석하고 개발부터 달려드는 경우들이 많습니다. 이런 방식은 정말 ‘지양'해야 하는 방식이었습니다. (그래서 좀 문서를 많이 만드는 경향이..)
저희도 회의를 거쳐서 기획과 개발이 ‘이런걸 만들어야 한다'라고 말은 하지만 진행하다가 새로운 문제를 발견하고 다시 합의하고 해야 하는 경우들을 많이 겪었습니다. 그러다가 뱅크샐러드의 Tech spec글을 봤는데 ‘이거다' 했습니다. 특별히 개발해야 하는 기능에 대해서 기획과 개발이 ‘코드를 작성하기 전에' 합의하는 과정이라는 점이 중요했습니다. 실제 회사에서 운영하는 모든 비용중 가장 비싼 비용이 개발비용이기에, 개발하는 시간을 아껴주고 원하는 산출물을 받을 수 있게 해줄 수 있다면 이는 매우 경제적이기도 합니다. 마치 실제 기능을 개발하는 과정을 미리 시뮬레이션 하는 느낌으로 적다 보면, ‘이건 필요하네', ‘이건 안 필요하네' 판단을 바로바로 내릴 수 있게 됩니다.
Kanban으로 운영
Kanban으로 운영한다는 의미는, 계속해서 새로운 기능들이 추가되고 개발자들은 추가되는 기능들을 계속 개발해나간다는 것입니다. Scrum의 경우, 일정 기간동안 새로운 기능을 추가할 수 없지만 Kanban은 가능합니다. Kanban으로 일을 진행할 때, 꼭 다음의 두 가지를 유념하시길 권합니다.
1.
WIP (Work-in-process)의 숫자를 사람수 만큼 정해주세요
2.
Release는 정기적으로 해주세요
WIP의 숫자를 정하기
동시 진행하는 일의 숫자들을 조절하지 않으면 어떻게 될까요? 계속해서 하던일이 끝나지 않고 쌓이게 됩니다. 의외로 많은 조직에서 이 부분을 무시합니다. 예를 들어 일을 할 사람이 3명인데 3가지 일이 있는 상태에서 ‘이것도 해야 한다'라고 하면서 계속 일을 밀어넣게 됩니다. 이렇게 되면 이른바 ‘Lead time’이 늘어지게 되어서 비효율적으로 일할 수 밖에 없습니다. 그래서 지금 팀에서 일할 수 있는 사람 숫자에 맞춰서 WIP수를 조절해야 합니다.
정기적인 Release
저희의 경우, 1주일에 한 번 Release를 하려고 노력합니다. 어떤 일들에 대해서는 1주일 안에 끝이 안납니다, 그러면 모아서 Release할 때도 있습니다. 그러나 자잘한 수정들은 매주 있기에 바로바로 보냅니다. 솔직히 말씀드리면, Ticket 적는 속도보다 개발속도가 빠른 때도 있었습니다. (개발팀, 모두 수고했어요!)
Release 결정하기
개발이 끝난 기능들에 대해서 어떻게 Release를 결정할까요? 정말 자잘한 기능이나 버그들은 그냥 배포를 하겠지만, 기획쪽에서 요청해서 나온 기능들이면 반드시 데모를 거칩니다. 그런데 이렇게 데모를 할 때가 있습니다.
•
배포 대기 버전을 준비하고, 기획, 운영, 개발을 다 초대합니다.
•
저희의 경우 고객들이 크게 인플루언서, 광고주, 운영입니다. 그래서 누구는 인플루언서로, 누구는 광고주로, 원래 운영팀은 운영으로 하고 실제 개발한 기능들을 써봅니다.
•
써보면서 미흡한 부분은 빨리 보완합니다. 충분하다는 판정이 나면 바로 Release를 합니다.
이렇게 하면 이런 장점이 있습니다.
•
실제 개발자들이 사람들이 어떻게 쓰는지 관찰할 수 있습니다.
•
운영팀에 새로운 기능 관련해서 따로 설명할 필요가 없습니다. 직접 써보고 ‘아, 이거구나'하고 알 수 있습니다. (운영팀은 저희 중 제일 중요한 내부고객입니다)
•
역할에 몰입하면 더 ‘많은' 문제들을 찾아내곤 합니다.
분기별 1:1 미팅
저희 내부에서는 분기별로 1:1 미팅해서, 회사 업무에 대한 피드백을 주고 있습니다. 보통 회사들이 1년마다 이렇게 피드백을 주곤 하는데 경험상 이것이 너무 길어서 기억을 다 못하거나, 그래서 엉뚱한 피드백을 주거나 인상비평을 해버릴 수 있었습니다. 그래서 분기마다 1:1 미팅하고 업무에 대한 피드백을 줍니다.
미팅 이전에, 팀원들은 아래의 내용을 준비합니다.
한 분기 동안에 자신이 해 온 일 중에서 제일 좋은 성과가 있었다고 생각하는 일
한 분기 동안에 자신이 해 온 일 중에서 가장 많이 배웠다고 생각하는 일
현재 회사가 하는 상태를 0은 최악, 10을 최상으로 할 때,
- 현재 몇 점인지, 그 이유는?
- 그 점수를 0.5정도 높일 수 있게 회사는 어떤 것을 해볼 수 있을까?
현재 개인의 일 하는 상태를 0은 최악, 10을 최상으로 할 때,
- 현재 몇 점인지, 그 이유는?
- 그 점수를 0.5정도 높일 수 있게 회사는 어떤 것을 해볼 수 있을까?
관리자는 다음과 같은 것들을 준비합니다.
한 분기 동안에 개인이 해 온 일중에 제일 좋은 성과가 있었다고 생각하는 일
한 분기 동안에 개인이 해 온 일중에서 제일 아쉬웠다고 생각하는 일
사전 준비가 되면, 이 내용들을 가지고 1:1 미팅을 합니다. 보통은 1시간 동안 하게 되고 업무에 대한 피드백을 주고 받습니다. 이 과정에서 본인 경력에 대한 조언이나 업무에 관한 상황들도 서로 많이 알게 됩니다. 무엇보다 더 나아질 방법들을 스스로 찾아갈 수 있는 코칭을 통해 매 분기별로 더 나은 조직과 개인이 되어 가는 것을 확인할 수 있어서 좋습니다.
우리 개발팀은 지금 몇 점쯤 되나?
예전에 Joel test가 한참 유행이었지요, 각 개발 회사가 어느정도 수준이 되는지를 가늠하는 척도로 말이지요. 최근에 아래와 같은 글을 통해서 각 회사들의 수준을 점수화하는 글이 있어서 화제가 되었습니다.
저도 한 때, 이런 지수를 굉장히 따지면서 개발조직의 발전 척도를 측정하기 좋아하던 사람이었습니다. 그런데 막상 여러 회사에 다녀보면서 혹은 조직을 만들어 보면서 느낀 것은 ‘이것만은 아니다'였습니다. Joel test 만점의 회사지만 블라인드라도 열어보면 아주 험악한 피드백이 남아 있는 곳도 많았고, 구성원들이 행복하지 않다고 이야기를 하는 곳도 있었습니다. 그 이유는 무엇일까요?
어떤 Process, 방침들이 있다고 해서, 그 내부 구성원들이 어떤 두려움 없이 일할 수 있고 자신의 능력을 제한 없이 발휘할 수 있느냐 없느냐는 평가하기 어려운 것들이었습니다. 실제 운영되는 조직의 문화, 의사결정 구조, 실제 구성원들의 일하는 방식 등은 무엇이라 표현할 수 없는 것이었습니다.
그래서 저는 분기별 미팅 때, 최대한 팀원들의 표정을 살피고, 실제 회의하는 과정중에 긴장감을 살펴봅니다. 얼마나 많은 사람들이 토론에 겁 없이 참여하는지를 봅니다. 혹은 서로 마음 맞는 사람들끼리 사이드 프로젝트를 하나 만들거나 맛집을 모여서 찾아가자고 슬랙에 남기는 글들을 더 신경 씁니다. 일하는 게 재미있고 즐거운 조직인지 아닌지를 살피는 거지요.
최근 저희 회사의 COO이신 신현묵님이 이런 글을 쓰셨습니다. “스타트업이 성공하기 위해서는 '기술'이 중요하거나 '소프트웨어 개발'이 중요하기는 합니다만. 실패와 성공은 협업에서 결판이 나는 것 아닌가 합니다.” 저는 이 말을 정말 믿습니다.
참고로 저희팀의 수준을 윤석찬님의 글에 있는 점수로 따지면 이렇습니다.
1. 코딩 테스트 인터뷰 – 개발자 입사 시 코딩 테스트 혹은 화이트 보드 인터뷰를 진행한다. : Y
2. 자율적 개인 개발 장비 선택 – 회사에 업무 장비 표준 (PC, 노트북 등)이 있더라도, 개인별로 원하는 개발 장비를 선택할 수 있다. : 장비는 맥북으로 통일하는데 키보드 마우스는 고를 수 있습니다.
3. 자율적 팀 개발 환경 선택 – 회사에 기술 표준 (프로그래밍 언어, 플랫폼 등)이 있더라도, 팀별로 원하는 개발 환경을 선택할 수 있다. : 내부에서 실험적 프로덕트를 만들 때, 적절한 개발환경을 고를 수 있습니다. 다만 너무 얼토당토 한 건 말립니다. (PHP로 굳이 만들겠다던가, C++로 웹서버를 짜겠다든가 하면 말립니다.)
4. 소스 코드 리뷰 및 테스트 – 모든 개발자가 다른 사람의 소스 커밋을 리뷰하고, 테스트하는 과정을 가지고 있다. : Y
5. 개발자 기여 로드맵/백로그 – 주요 개발 방향을 PM/기획 뿐만 아니라 개발자들이 주도 혹은 참여해서 정해나간다. : Y
6. 지속적 통합 및 배포 (CI/CD) – 코드 커밋 후 자동으로 통합 및 배포되는 시스템을 가지고 있다. : Y
7. 내부 소스 레포지터리 공유 – 다른 팀의 소스 코드에 접근(access), 포크(fork) 혹은 기여(contribution)할 수 있다. : Y
8. API를 기반한 연동 및 소통 – 내부 팀 및 플랫폼간 협업을 할 때, API를 개발해서 공유하거나, 검색할 수 있다. :Y
9. 기술을 이해하는 팀장/매니저 – 회사 내 개발팀장 대부분은 소프트웨어 개발 경력이 가지고 있으며, 내부 코드 및 기술 플랫폼을 이해하는 사람이다. : Y
10. 개발자 레벨 혹은 경력 관리 – 사내에 개발자의 업무 역량별 레벨 제도 혹은 팀장/매니저가 아닌 별도의 개발자 전용 승진 경로를 가지고 있다. : Y
11. 참여형 지식 공유 플랫폼 – 사내에 직접 참여 혹은 편집 가능한 위키(노션), 블로그 플랫폼을 운영하고 있다. : Y
12. 개발자 관계(DevRel) 활동 – 외부 개발자와 소통하는 채널(기술 블로그, 컨퍼런스 등)을 운영하거나 전담하는 사람/팀이 있다. : N, 아직 저희가 크지 않아서요.
13. 위의 모든 사항이 해당 안된다 ㅠㅠ (13일의 금요일의 저주) : NO!!
부록: 끝나지 않을 빛나는(?) 문서 하나
그리고 집단 지성의 힘(?)으로 열심히 만들고 있는 문서가 있습니다. 끝나지 않을거라 믿습니다. ㅎㅎㅎㅎ
진심으로 작성중입니다..ㅎㅎㅎㅎ
유진호는 유하의 CTO입니다. 전체 아키텍쳐 설계와 데이터 구조의 설계, 그리고 근처 맛집 수집(?)용 크롤러에 관심이 많습니다. 그리고 요새 집에서 화구를 인덕션으로 바꾼 다음 맛있는 볶음밥을 못만들어서 울고 있습니다.