OKKYCON: 2021 협업의 기술

• 안녕하세요~ 이전에 운영하던 블로그 및 GitHub, 공부 내용을 정리하는 Study-GitHub 가 있습니다!

• 네이버 블로그

• GitHub

• Study-GitHub

• 🐔

---

 

✔ OKKYCON: 2021 OKKY Conference 2021 협업의 기술

개발자와 개발조직의 생산성을 높이는 스마트한 협업

2021.03.06 (토) | 13:00 ~ 17:00

 

www.okkycon.com/2021/

OKKYCON: 2021

---

 

🎗 커뮤니케이션이란 무엇인가? 어떻게 해야 효과적으로 협업을 할 수 있는가?

• 개발은 대부분의 경우 함께 하는 일이 됩니다. 혼자 하는 일은 아주 적습니다. A.I.프로젝트에서 데이터 전처리에 들어가는 시간이 전체의 80%를 차지하듯이 실제로 개발과정에서도 가장 많은 시간을 잡아먹는 것은 커뮤니케이션입니다. 하지만 대부분의 베스트 프랙티스들은 프로그래밍에 몰려 있고, 커뮤니케이션에 관한 것은 상대적으로 적습니다. 전체 시간의 80%는 커뮤니케이션에 들어가는데, 정작 배우고 공유하는 것은 나머지 20%에 집중한다면 이것은 조금 이상한 일입니다. 커뮤니케이션이란 무엇인가? 어떻게 해야 효과적으로 협업을 할 수 있는가? 그리고 그것을 위한 몇가지 팁을 들려드립니다.
• 박태웅 / 한빛미디어 의장 (13:05 ~ 13:25)

---

 

🎗 협력의 조건 만들기

• 서로 힘을 합하여 도움을 주고 받으며 내가 혼자 해결할 수 없는 더 큰 문제들을 해결하기 위해 우리는 함께 일하는 것을 선택합니다. 그러나, 그 과정에서 일어나는 많은 고민들은 덤으로 따라옵니다. 온전한 협력의 과정을 만들기 위해 필요한 조건들과, 그동안 제가 시도했던 여러 실천법들을 소개하며 더 좋은 방법을 같이 고민해봤으면 합니다.
• 홍영기 / 네오위즈 애자일 코치 (13:25 ~ 13:55)

 

📗 발표 내용 정리

• 혼자 일하는 경우도 있지만, 대부분의 경우 함께 일을 한다.
  • 함께 일을 하는 이유? 혼자서 해결할 수 없는 문제를 해결하기 위해 함께 일하는 것을 선택한다.
  • 함께 일하는 과정에서 발생하는 어려움의 고민들이 많다.
  • 따라서, 온전한 협력의 과정을 만들기 위해 필요한 조건들이 뭐가 있는지, 실천법들, 배운점들을 소개
• 농구라는 게임에서 모든 선수들은 게임을 승리하기위해 서로 협력하며 플레이를 진행한다.
• 여기서 주목할 점은, 모든 선수들은 팀의 승리라는 결과를 서로 공유하고 있다. (shared outcome)
• 공동의 목표를 달성하기 위해 공유, 협력을 진행한다.
• 협력(Collaboration)
  • 특정한 목적을 달성하기 위해 서로 힘을 합하여 도움
  • 협업(Cooperate)
    • 생산의 과정을 여러 전문적 부분으로 나누고, 여러 사람이 각 부문별로 맡아서 일을 완성하는 노동 형태
• 그럼, 협력을 잘하기 위해서는 어떻게 해야할까?
• 그보다 앞서 언제 협력을 선택하는 것이 유리할까?
  • 일이 어려울(complicate)때 보다는 복잡(complex)할 때
    • 복잡이란? 이해하기 어렵고, 모호하고, 변동성이 높고, 예측하기 힘든 상황
  • 전문적(expert) 해법보다는 창발적(emergent) 해법이 필요할 때
  • 작업 절차/공정을 명확하게 나누기 어려울 때
• 협력이 잘 이루어지기 위한 조건은 무엇이 있을까?
  • 협력을 선택했을 때 내가(우리가) 더 유리한 환경을 설계해야 한다.
  • Collaboration Framework
  • 1. 심리적 안전: feel safe to take risk and be vulnerable
    • 위험을 감수하거나 취약점을 드러내도 안전함을 느끼는 상태
    • 비폭력대화 - 연민의 본성을 가지고 나를 먼저 이해하고 타인에게 도움을 주는 법
    • 퍼실리테이션 - 그룹 레벨에서 좋은 의사결정을 하기 위해 민주적으로 의견을 주고받을 수 있는 방법
  • 2. 일의 의미를 이해하기: Output / Outcome / Impact
    • 현재 진행중인 일이 나에게, 고객에게, 사회에게 어떠한 가치를 가지고 있는지를 이해하는 것
    • 산출물을 통한 결과, 이를 통해 의미 및 영향력을 찾게된다.
  • 3. 피드백: 더 중요한 정보를, 더 빨리, 더 자주 받기
    • 내가(우리가) 한 행위의 결과가 의도에 부합하는지 확인하는 과정
    • 큰 사이즈의 기능 보다는 작게 나누어서 더 빨리, 자주 전달함으로써 빨리 피드백을 받는게 필요하다.
    • 고객에게 받는 피드백도 필요하지만, 조직 내부에서 받는 피드백도 필요하다.
      • 팀: 정기적 회고
      • 개인: 1 on 1
  • 4. 투명성: 정보 공유 / 커뮤니케이션
    • Jira
    • Daily Sync Up
    • Team Competency Matrix

 

사례 - Team Competency Matrix

• 팀이 필요로 하는 역량을 모델링
  • 팀 역량 현황 파악
  • 역량 성장 지도
  • 채용의 근거, JD 활용
• 진행 순서
  • 우리 팀이 해결하고 있는 문제는 무엇인가?
  • 해당 문제를 해결하는데 필요한 역량은 무엇인가?
    • 전문성, 툴 기술, 프로세스, 소프트 스킬
  • 각 역량들의 레벨을 나눈다.
  • 자가 진단, 상호 진단 수행
  • 위의 내용들을 정리해서 팀에 공유한다.

 

적용 경험 공유

• 모든 것은 다 연결되어 있다.
  • 부분적으로 취사 선택하는 것은 효과가 떨어진다.
• 가장 중요한 것은 심리적 안전을 구축하는 것이다.
  • 이게 안되면 전체적인 효과가 떨어진다.
  • 심리적 안전을 해치는 상황이 벌어지는 것을 빨리 인지하고, 적극적으로 대처해야 한다.
  • 한번 무너진 신뢰는 다시 복구하는데 큰 비용이 든다.
• 시스템을 구축하자.
  • 사람에 기대면 그 사람이 없어지면 바로 사라진다.
  • 체계를 만들고 그 안에 루틴을 세운다.

 

정리

• 지금 우리가 푸는 문제는 협력을 선택하면 유리할까?
  • 우리가 하는 대부분의 일들이 그렇다.
• 사람들이 협력을 선택하도록 만들려면 어떻게 해야할까?
  • 협력을 강제하는 건 불가능하다.
  • 협력을 선택했을 때 나에게 더 많은 유익이 돌아오도록 설계해야 한다.
• 설계를 할 때 무엇을 고려해야 할까?
  • 여러 요소들을 종합적으로 고려해야 한다.
  • 정기적인 진단/측정으로 경향을 보며 조정한다.

---

 

🎗 함께 성장하고 협업하는 문화를 만들어가는 과정

• 같이 일하는 동료, 주니어 개발자, 팀원들에게 긍정적인 영향을 미쳐 함께 성장하고 협업하는 문화를 만드는 과정에 대해 이런 문화를 만들기 위해 누구와 함께할 것인지, 어떤 문화를 만들 것인지, 어떻게 만들어 갈 것인지에 대해 알아보겠습니다.
• 박재성 / 우아한형제들 교육이사 (14:00 ~ 14:20)

 

📗 발표 내용 정리

• 오늘 이야기는 개발 문화를 만들기 위해 다양한 도전을 하다 실패 경험이 많은 개발자가 리더가 되어 개발 문화를 만들어 가는 이야기
• 어떤 문화를 만들고 싶은가?
• 리더의 목표
  • 지식을 공유하고, 같이 성장하면서 유지보수하기 좋은 코드를 구현하는 팀을 만들고 싶다
• 팀의 문화를 만들려면 어디서부터 어떻게 시작하면 좋을까 ?
  • 개발자의 역량을 키우고, 소스코드 품질을 유지하기 위해 온라인 코드 리뷰(짝 프로그래밍), TDD를 팀의 문화로 정착시키고 싶다.
• 모든 업무? 이슈 관리, CI 기반의 개발 프로세스로 진행
• 대부분의 리더들이 처음에는 이러한 문화를 생각하지만, 대부분은 실패를 하게된다.
• 이러한 방식을 아웃사이드 인 접근 방식이라고 하는데, 이를 필패의 지름길 이라고 생각한다.
• 리더는 만들고 싶은 개발 문화의 방향성만 정하고, 구체적인 개발 프로세스는 최대한 뒤로 미룬다.
• 초기에는 상사가 짝 프로그래밍 등을 진행하자고 제안하면 반발심이 생긴다.

 

문화(변화)를 만들기 전에 생각해 볼 점

• 사람은 기본적으로 변화를 거부하는 성향
• 팀은 변화를 거부하는 성향이 강함
• 대부분의 사람들은 변화에 실패한 경험을 가지고 있음
  • 개인도 변화가 힘든데 팀은 변화가 더더욱 힘들다.
  • 리더가 팀의 변화를 만들어내기는 엄청 힘든일이다.
  • 즉, 변화는 실패할 가능성이 높다.
  • 따라서 변화가 실패하더라도 자책하거나 절망하지 말 것

 

문화(변화)를 만드는 시작점

• 팀원의 심리적 안정감
  • 심리적 안정감이란?
    • 구성원이 업무와 관련해 어떤 의견을 제기해도 벌을 받거나 보복당하지 않을거라고 믿는 환경 조직
• "팀의 변화를 만드는 일을 성공하기 위해 가장 중요한 것은 심리적 안정감을 어떻게 만들 것인가?" 이다.

 

심리적 안정감을 만들며, 문화 만들기 시작

• 팀원들과의 신뢰 형성이 우선 -> 1:1 면담을 통해 개선할 부분 찾기(잦은 면담)
• 1:1 면담에서 한 가지만 기억하자.
  • 팀원이 문제점을 이야기할 때 해답을 제시하려하지 말고, '어떻게 하면 될까?', '너라면 어떻게 할 것 같아?' 라는 반문을 해야한다.
• 1:1 면담, 팀 회고를 통해 우선 순위가 높으면서, 작은 변화를 통해 가장 높은 효과가 있을 것으로 생각하는 Best Practice를 선택한다.
• 팀이 익숙해질때까지 선택한 Best Practice 한 가지에 집중한다.
• 선택한 Practice로 변화를 완료함으로써 작은 성공 의 성취감을 맛본다.
• 사이클 과정은 다음과 같다.
• 면담, 회고 -> Practice 선택 -> 한 가지에 집중 -> 작은 성공

 

새로운 문화를 정착하기 위해 가장 중요한 것은 리더의 인내심과 용기

• 새로운 문화를 만들면서 초기 학습 비용 등으로 인해 생산성 저하는 당연하다.
• 안정화하는데 최소 1년 이상의 시간을 투자해야 한다는 마음으로 믿고 기다려주어야 함.
• 문화를 만들고, 변화를 만드는 일은 리더만의 책임이 아니다.
• 누구도 대체할 수 없는 존재로 만들고 싶다면 지금 당장, 바로 도전해라.

 

실패해도 괜찮다.

• 실패하기 전보다 나는 한 단계 성장한다.
• 좋은 회사는 실패해도 같이 도전하는 사람을 원한다.
• 실패의 책임을 묻는다면 ? 그만둔다.

가장 필요한 것은 가보지 않은 길에 꾸준히 도전할 수 있는 용기

---

 

🎗 당신에게 협업의 대상은 누구(무엇)인가요?

• 엔지니어링 조직에서의 협업의 대상은 주로 업무기능별 협업으로 한정되기 쉽습니다. 협업의 최종 목적은 무엇에 두는것이 맞을까요? 어떤 조직이 출시하는 제품과 서비스는 그 커뮤니티에 포함된 모든 사람의 협업의 결과입니다. 성공적인 협업에 대한 평가의 기준은 무엇이 되어야 하고, 단기간의 성과와 이익만이 아닌 기업의 성장 동력을 만들기 위한 협업의 최종대상은 누가 되어야 하는지를 함께 고민해 보려고 합니다.
• 김영욱 / SAP Senior Program Manager at SAP Product Engineering, SAP UX. (14:20 ~ 14:50)

 

📗 발표 내용 정리

협업의 첫 번째 대상, 생각(Idea)

• 협업의 대상이며 실체인 아이디어의 가치(도입 속도)는 무엇이 결정하는가?

협업의 첫번째 치트키

당신은 '생각'과 협업하기 위해 기본 원칙을 얼마나 잘 지키고 계신가요?

• Policies, Guidelines, Codes, Protocols, Convention
• 형식에 맞는 이메일 쓰기
• Wiki에 정보 모으기
• 미팅에 늦지 않고, 회의에 집중하기
• 액션 아이템 실행하기 ... 등등

 

협업의 두 번째 대상, 소외된 고객

• 여러분의 협업 대상은 (여러분의 제품/서비스를 사용하는/할 모든) '고객' 

 

협업의 세 번째 대상, 자율 머신(AI) - 기계가 협업 대상의 고객이 됩니다.

• Vehicle
  
  • Tires
  • Cleaning
  • Fueling/Charging
  • Insurance
  • Media
  • Food and Drink ...
• Road
  • Repairs
  • Recovery
  • Police
  • Cleaning
  • Upgrades ...
• Factory Robot
  • Repairs
  • Cleaning
  • Parts
  • Supplies
  • Upgrades
• Buying Algorithm
  • Supplies and Products
  • Gig Workers
  • Business Services
  • Energy
  • APIS, Data
  • 현재는 모든 작업을 사람의 조작이 필요한데, 이후에는 모든 부분이 자동화가 되어야 함
• 여러분의 미래 고객과 대화를 준비해주세요.

 

정리

생각(Ideas) : 기본 업무 원칙을 지켜요

소외된 고객(Exclusion) : 포용적 사고, 해동을 해요

자율 머신(Machine Customers) : 미래를 고객과 대화 방법을 익혀요.

---

 

🎗 프로덕트 조직의​ 생산성 높이기

• 이슈트래커부터 사소한 버저닝 규칙도 제품의 릴리즈 사이클과 커뮤니케이션 속도에 영향을 줄 수 있습니다. 개발총괄이자 워크플로우닦이로 네이버/LINE에서 3년간 100여개의 자동화 프로그램을 개발하면서 얻은 인사이트를 공유하고자합니다.
• 김영재 / 라인플러스 Fellow (15:05 ~ 15:45)

 

📗 발표 내용 정리

네이버/LINE에서 3년간 100여개의 자동화 프로그램을 개발하면서 얻은 인사이트

 

결론부터 요약

• 큰 관점: 전체 프로세스를 관찰하며 개선한다.
• 작은 관점: 질문을 줄인다, 반복을 줄인다, 실수를 줄인다.

 

개발자의 시야는 좁다.

• 개발이라는 분야는 프로덕트 파이프라인의 여러 단계에서 하나일 뿐이다.
• 재무, 비즈니스 전략, 기획, 개발, QA, 운영, CS 등등 ....

 

이슈트래커(Jira, ASANA, YouTrack, ...)

• 중요 선택 기준
  • 전사적으로 사용 가능해야 함
  • 여러 repo를 하나의 프로젝트로 관리할 수 있어야 함: GitHub Issue의 한계
• 개발자가 이슈트래커를 잘 쓴다는 기준
  • 이슈트래커 웹에서 적게 열어볼 수록 잘 쓰는 것
  • 절대 상태(Status)를 손으로 바꾸지 말자.
• 핵심 기능
  • 커밋메시지로 상태 변화가 가능한 것(이 기능을 제대로 활용하는 개발자가 의외로 드물다.)

 

Demo

• JetBrains Task & Context
• 이슈트래커 제어와 커밋을 피아노치듯 경쾌하게 할 수 있다.
• IDE와 상태(status)의 연계는 정말 중요하다.

 

이슈를 많이 만들고, 많이 닫자

• 이슈 처리가 곧 개발 속도감을 더해준다.
• Story, Epic, Gantt, WBS 보다는 개발자에게 커밋 단위로 상상하게 하는게 가장 와닿더라.
• 이슈를 빠르게 만들고 싶은 욕구가 자연스럽게 나타남
  • 콘솔로 git commit 하는 것도 귀찮다.
  • 콘솔에서 입력할 때 괜히 이슈번호 오타 나온다.
  • 원클릭으로 커밋메시지를 작성하자.

 

IDE를 기능들을 단지 색상이 이쁘거나 디버깅을 좀 더 편리하게 해주는 기능을 넘어서서,

업무 전체에 연관이 있게 하는 가장 중심이 되는 도구로 확장해서 사용하자.

 

CI/CD Builder(빌드 서버)

• 목표
  • 원숭이도 릴리즈 할 수 있게
  • 아무 때나 릴리즈해도 깨지지 않게
• 팁
  • 자동 트리거 빌드는 제목을 대시로 시작하면 혼란이 적더라.
  • Prompt(대화창)를 띄워서 실수를 줄일 수 있다.

 

Progressive YearWeek Versioning

• version: 3.1924.59
  • 3 : head(수동)
  • 1924 : yearweek(자동)
  • 59 : build(자동)
• 도대체 v1.0에서 언제 벗어나는거야? -> 모든 숫자가 의미있도록 ..
• 가운데 숫자(yearweek)만 보면 얼마나 오래된 버전인지 누구나 알 수 있음
• 빌드서버가 버전을 만들어주므로, 같은 버전에 같은 바이너리를 확신함(중요)
• 빌드서버에서 빌드만 하면 버전관리 전혀 신경쓰지 않아도 됨(중요)
• 빌드할 때마다 전진하므로 속도감있는 빌드 프로세스를 강요
• 언제 head를 올리는가? 유저에게 도달할 때마다

 

API 영혼까지 끌어모아서 자동화

• 조직이 커질수록 자동화에 제약이 생긴다.
  • ex) Jira plugin 설치를 함부로 못함
• 하지만 포기하지 말자, API를 째려보면 자동화가 보인다.
  • 나의 하루가 1년을 편하게 한다는 마음가짐!!
• 자동화 스크립트 팁
  • 기능이 곧 파일명이 되도록
  • 여러 개를 실행하더라도 작은 기능 단위로
  • config 가능성을 폭넓게
  • 팀, 조직, 회사 밖에서도 쓸 수 있게

 

자동화 스크립트 수명 길게 만들기

• 라이브러리 사용 최소화
• 하나의 repo에 모아 놓는다
  • 빌드서버에서 공용으로 참조하기에 좋음 -> 상투적인 익스텐션 느낌
• 개인 repo가 아니라 팀 repo에 쌓는다.
  • 개인의 자산처럼 보이면 안된다.
• 거의 동일한 형식으로 작성하자.(config, main, parameter 작성 등)
  • 형식을 개선하면 과거의 모든 것도 개선하며 꾸준히 유지보수한다.

 

ex) 기획자와 일하기

• 기획 관점: 이번 버전에서 스펙대로 개발되었나?
• 지금 릴리즈한 앱은 내가 말한게 적용된 버전인지....
• 이슈의 상태가 개발 상태와 최대한 일치하도록
• 개발 중이면 진짜 개발 중
• 개발 완료면 진짜 개발 완료
• 베타 릴리즈면 진짜 베타 릴리즈

 

ex) QA와 일하기

• QA 관점: 이번 버전에서 문제가 해결되었나?
• 지금 QA 하는 앱이 원하는 버전인지....
• 앱을 열면 최신 버전을 체크하도록
• 문제 리포트를 간편하게 하도록
• 릴리즈노트를 믿을 수 있도록
• 풍부하고 친절한 디버그 모드(중요)

 

나름의 방법 - 어떤 질문이 오가는지 살펴보자.

• 질문 발견 -> 질문을 없애자 -> 프로세스 관찰 -> 프로세스 개선 -> 문서화 -> 질문 발견 ...

 

프로세스 개선

• 몇 가지 기준
  • 동일한 질문이 줄어드도록
  • 같은 내용을 타이핑하지 않도록
  • 실수가 줄어들도록
  • 실수해도 빨리 덮을 수 있도록
  • 권한이 넓어지도록
  • 시각적으로 표현할 수 있도록
  • permalink로 남길 수 있도록
• 문제에 적중하는 시스템이 없다면, 만들자!!
  • 완벽하게 해결하는 정답같은 시스템
  • 유지보수를 책임질 수만 있다면 -> 그냥 잘 만들면 됨
  • 뭐든 낡기 마련이니 문서화를 잘하자.

문서화 -> Wiki (www.facebook.com/youngjaekim0/posts/10157981041607794)

• 잘 쓴 Wiki
  • 수명이 긴 글
  • Reference가 충실한 글
  • 개성을 줄이고 건조하게 쓴 글
  • 남에게 수정 가능성을 열어둔 글
  • 일관된 구성

 

과적합 주의

• 자동화도 과한 자동화가 있다.
  • 돌이킬 수 없는 어려운 연쇄반응을 만들 수 있음
• 개발 흐름 또는 체계를 바꾸려고 할 때 일이 커질 수 있음
  • 단위를 명료하게 쪼개야 디버깅도 편함
• 타성에 젖을 수 있음
  • 더 좋은 도구, 더 좋은 방법론은 계속 나온다. 단지 모를 뿐
  • 최신 도구가 나오면 꼭 써보자.

 

정리

• 전체 프로세스를 보자
  • 얼마나 복합적이고 얼마나 End-to-End 까지 볼 수 있는가
• 정확하고 자동화된 버저닝 시스템을 확립
  • 버전을 물어보면 큰 문제가 있다는 신호
• 이슈트래커를 정보와 코드의 창구로
  • 당연한 말인데 높은 수준에 도달하는 경우는 드물다.
• 일단 혼자 해보고 자신있게 권하자.
  • 효율이 눈에 보이면 설득력이 생긴다.

---

 

🎗 OKR 기반으로 스케일업 가능한 협업 체계 만들기

• OKR 기반으로 스케일업 가능한 협업 체계 만들기 번개장터는 2019년 40여명 직원에서 2020년 말 기준 세배 이상으로 직원 수가 늘어 빠르게 업무 속도를 높여가고 있습니다. '소통'을 성장을 위한 중요한 원동력으로 보고 있지만, 조직이 커질수록 이해관계자간 조율도 어려워지고 협업 과정의 비효율도 늘어가고 있습니다. 번개장터는 이를 극복하기 위한 수단으로 OKR과 매트릭스 형태 조직 운영을 도입하였습니다. 2020년 OKR을 도입하고 1년여 시간 동안 다양한 이유로 여러 시행 착오들을 겪었고 그 때마다 새로운 시도를 하며 번개장터만의 협업 체계를 만들어 가고 있습니다. 앞으로도 지속적으로 성장할 것이라 스케일업 가능한 프랙티스들을 구축하고자 노력했습니다. 번개장터의 시행 착오와 시도, 이로부터 얻은 경험들을 여러분들과 함께 나누고 싶습니다.
• 이동주 / 번개장터 (15:50 ~ 16:15)

 

📗 발표 내용 정리

조직이 커지면서...

• 개인 및 조직 간 협업의 필요성이 커짐
• 정보 공유와 이해관계 조정을 위한 소통의 중요성이 더욱 커짐
• 빈번한 미팅과 대화로 인해서 오버헤드가 증가함
• 엄청 바쁘게 움직이나 진행되는 일의 양은 전에 비해 많이 늘지 않음

번개장터에서 협업이란?

 -> 함께 목표를 달성하는 과정

 

환경의 변화에 맞춰 꾸준히 진화하여 조직이 커짐에도 여전히 효과적인

 

2019 - 협업 효율 개선

• 정보 공유와 공동 작업을 쉽게
• 소통을 수월하게
• 업무 가시성을 높게
• 서로 사용하는 도구의 차이를 줄이고,
• 별도의 학습 없이 직관적으로 소통할 수 있도록
• 프로세스나 도구의 단순함을 유지

 

정보 공유와 공동 작업을 쉽게

• 대부분의 정보 작성은 Wiki(Confluence)를 이용하여 아주 민감한 정보가 아니라면 모든 구성원이 정보에 접근가능

 

일정과 상태를 공갱하여 소통을 수월하게

• 캘린더를 활용하여 업무 시간 관리
• 슬랙에 나의 현재 상태 표시

 

대부분의 업무는 JIRA에 등록

• 각자의 업무 오버헤드가 어떤지 쉽게 알 수 있게,
• 업무 완결을 위해 어떤 업무가 더 진행되어야 하는지 쉽게 파악할 수 있게,
• 내 업무의 지연이나 완료를 알려주어야 할 대상이 누군지 알 수 있게,

 

이 외에도 사용하는 도구들

• CI/CD - Jenkins
• 시스템 모니터링 - Grafana
• 지표 분석 - Redash

 

2019년 까지의 업무 방식은 Agile - 장기적 성장보다는 단기 성과 중심으로 가설을 세우고 빠르게 검증

협업은, 목표에 대한 공감에서부터 시작 , 목표 기반의 업무 체계 도입 - OKR, CELL

• OKR
  • 달성하고자 하는 목표에 대한 정성적인 기술, 목표가 달성됐음을 확인할 수 있는 정량적인 결과
• CELL
  • 목표를 공유하는 서로 다른 직무자가 모인 목적 중심 조직
  • 많은 회사에서 도입하여 운영하고 Squad, Silo라 불리기도 함

 

번개장터에서 OKR의 의미

• 명확한 우선순위
• 담대한 목표
• 완전한 공유

 

2020 하반기 ORK & CELL에서의 문제

• 과제 달성을 위한 컴포넌트 개발 팀과 셀이 분산되어 목표 달성을 위해 다른 셀과 소통해야 하는 일이  너무 많음
• 정의된 목표가 다르지만 유사한 활동을 해야해서 목표와 활동의 충돌 발생
• 하나의 셀에 여러 팀이 협업하면서 상위 조직장이 조율해야만 하는 일들이 빈번

 

2021년 OKR & CELL 개편

• 제품 영역
  • 각 CELL이 KR달성을 위해 관련된 프로덕트 요소를 종합적으로 고려할 수 있도록 셀의 담당 영역을 조정
• 개발 조직
  • 고객, 상품, 거래 관련 컴포넌트에 집중하는 Cross functional 개발 조직인 랩 중심으로 책임 개발하는 형태로 재편

 

번개장터는 OKR과 CELL을 통해 ..

• 서로 다른 직무를 수행하는 개인과 조직이 공동의 목표를 인식하는 것에서부터 협업을 시작
• 목표의 달성을 전략적 성과로 정의하여 업무의 마무리를 명확히 함
• CELL을 기반으로 조직의 집중 영역과 의사 결정 구조를 단순화
• CELL을 기반으로 전사적으로는 여러 목표를 동시에 추구

---

 

🎗 7년간 방치되었던 쏘카의 가격시스템, 직접 개발해버린 이야기

• 이제는 대중적으로 많이 도입된 애자일 협업 프로세스, 쏘카에서도 도입하여 활용하고 있었습니다. 그런데 이 프로세스의 치명적인 문제로 인해, 쏘카의 가격시스템은 7년간 아무도 유지보수하지 않은 채 방치되고 있었습니다. 기존의 협업 프로세스를 깨고 새로운 방식의 협업으로 새 시스템을 개발했던 이야기를 들려드립니다.
• 김상우 / 쏘카 데이터그룹 그룹장 (16:20 ~ 16:40)

 

📗 발표 내용 정리

 

• 기존의 가격 시스템은 PHP, 작업이 있으면 항상 야근 확정
• 굉장히 노후화가 되어있었음..
• 기존의 작업량도 밀려있었기에 개발을 진행할 수 없었음..

 

방법 ?

• 공정과 도구보다 개인과 상호작용을
  • 기존의 개발 프로세스에 갇히지 않는 새로운 구성의 회의체
• 포괄적인 문서보다 작동하는 소프트웨어를
  • 간단한 문서와 작동원리가 담긴 엑셀시트의 조합으로 개발 시작
• 계약 협상보다 고객과의 협력을
  • 직접 활용할 사업부서와 기획단계부터 공동 작업
• 계획을 따르기보다는 변화에 대응하기를
  • 사업부서의 아이디어를 반영하기 위한 과감한 스펙변경
• As-Is) 높은 자유도, But 한땀한땀 만들어야함(with 스크립트, feat. 야근)
• To-Be) 논리적인 요소들의 조합으로 가격 결정
• 기존의 모놀리스 -> MSA 변환

 

Essential Ingredients

• 좋은 개발팀과의 좋은 관계
  • 우리가 할 일을 저쪽에서 왜? (X)
  • 공동의 목표, 같이 달성하는 것(O)
• 업무 분산을 위한 기술적 토대
  • Micro Service Architecture(MSA)
  • 표준화되고 다루기 쉬운 배포환경 및 인프라(feat. Kubernetes)
• 운영 경험
  • QA, 자동화된 테스트
  • 책임감있는 팔로업 및 모니터링
• 작업은 완료되었으나, 업무는 고도화가 되었음.
• 하지만, 야근은 없어짐 !!

---

 

🎗 당근마켓 성장에 따른 협업의 변화는 진행 중

• 협업의 방식에 정답은 없고 상황에 맞는 최적의 방법을 찾아가는 과정의 연속입니다. 당근마켓은 작은 조직을 지향하면서 운영되고 있지만 직원수가 늘고 사업의 방향에 따라 협업의 방식에도 변화가 있었습니다. 이러한 변화의 이야기를 전달 드리고자 합니다.
• 정창훈 / 당근마켓 이사(CTO) (16:40 ~ 17:00)

 

 

📗 발표 내용 정리

스타트업은 극심한 불확실성의 상황에서 새로운 제품이나 서비스를 만들어내기 위한 디자인된 인간 조직이다.

(린 스타트업 저자)

 

• 초기에 3명(서버 개발자 2명, 기획자 1명)
• 하루에 배포는 정말 자주 일어남... 커밋이 곧 배포
• 그 후 6명(디자이너, 안드로이드 개발자, 서버 개발자)
• 비전을 맞춰가는 과정
  • 장기적인 비전과 단기적인 목표에 대한 이야기를 서로 자주 했던 시기
  • 단순히 제품을 만드는것에 더해 비전을 다 같이 맞추는게 중요했던 시기
  • 다 같이 운영, 하루씩 돌아가면서 CS 문의 대응
• 10명 & 판교 이사(마케터, 서버 개발자, 머신러닝 개발자, 인프라, 디자이너 교체)
  • 여전히 배포는 커밋 후 바로 배포, 커밋 20개면 배포 20번
  • 서로 동시에 배포하려고 해서 동시에 배포 못하게 배포 락 기능을 만들 정도
• 25명 & 서초 이사(각 전문 포지션 영입)
  • 당시 MAU 100만 ~ 300만, 서버 좀 터지는 정도
  • 전문 영역이 생겼던 시기
  • 하루에 배포 몇번?
    • 서버 증가로 도커 도입
    • 도커 빌드 시간으로 인해 기존 배포시간보다 늦어지고 방법도 복잡해짐
    • 배포 속도 급격한 감소
  • 인원이 많아짐에 따라 같이 하기 힘든것들이 생기는 시기
• 140명 & 강남 이사(너무나 많아진... 사람)
  • 2020년 -> 2021년 , 25명 -> 140명(개발자 80명)
  • 다른 사람은 뭐하나??
  • 하루에 배포 몇번?
    • Kubernetes 도입과 ECS 혼합 상태로 혼돈의 시기
  • 이 기능에 대해 아시는분?
    • 기존에 만들어진 레거시에 대한 히스토리를 아는 사람이 적음
    • 다행히 레거시에 대해 아는사람들이 초기 멤버들이고 알고 있어서 물어보면 대충 알지만 기억 안나는 경우도 있음
    • 사람이 많아짐에 따라 검색의 중요성이 커짐(Wiki 사용)
  • "사업 + 플랫폼"
    • 서비스 뿐만 아니라 돈을 버는 사업팀의 확장 
    • 하나의 기능에 대해 여러 유관부서가 생겨남
  • 서로에 대해 알 기회가 줄어들고 있다. (+ 코로나 상황)
• 150명 & 신논현 이사
  • 한 층에서 여러 층으로 나눠지는 시기가 중요한 듯..
  • 스치면서 만나기도 힘들다... -> 협업에 대한 고민의 시작
  • 사람이 변하듯 조직도 계속 변한다.
  • 협업은 특히 사람의 숫자에 영향을 많이 받는듯 하다.

 

마지막으로 개발 이야기

개발 문화는 어떤가요? (많이 물어보는 질문)

• 저는 잘 모른다고 이야기 함
• 회사 업무에서 하고 싶은것들을 할 수 있는 환경을 만들어 주는 것을 중요하게 생각 함
• 업무의 몰입도를 높이려고 노력함
• 회사에서 강제하는것이 없는것이 문화일 수 있겠다는 생각을 함
• TDD를 하라고 강제하지 않고, 하지 말라고 강제하지 않음
• Circle CI를 강제하지 않고, GitHub Action을 강제하지 않음
• 혹시나 강제하는게 있을 수 있지만, 안하려고 노력함(필요한 것은 강제하는것들이 생기고 있음)

 

 

회사를 만들어가는건 사람, 결국 사람

• 사람이 중요하고 회사를 만들어 간다는걸 많이 느낌
• 지역광고 개발
• AWS VPC, Terraform 도입
• TypeScript 도입
• Go 도입
• DynamoDB, Neptune 도입
• 데일리 스크럼 도입
• React 도입
• 기타 많은 것들이 새로운 사람이 와서 제안을 함
• 문화도 결국 사람이 만들고, 회사도 구성원들이 모여서 바뀌어 간다고 생각함
• 결국 사람이 중요함. 사람이 제도를 만들어 간다.

---

 

✨ 후기

이 컨퍼런스의 제목이 협업의 기술인것을 제외하면 정확한 내용에 대해서는 사실 잘 보지는 않았다.

하지만, 정말 유명한 분들이 연사로 참여하시기에 유익한 내용을 많이 들을 수 있다고 생각했고, 듣게 되었다.

처음에 링크 메일이 오지 않아서, 직접 메일을 보낸 뒤 링크를 받아서 참여를 해서 첫 연사님의 강의는 듣지 못했다😢

 

제목이 협업의 기술인 만큼, 대부분 연차가 높으신 분들이 그동안의 경험을 토대로 발표를 해주셨는데, 아직 주니어인 내가 듣기에도 정말 유익한 내용이 많았다.

다른 분들의 발표도 모두 정말 유익했지만, 개인적으로 가장 와닿았던 강의는 박재성님 이었다.

강의를 듣는 내내 현재 내가 처해있는 상황과 비슷하다고 생각했기 때문이다.

현재 회사에서 개인적으로 개발 문화를 개선하고 싶은게 너무나도 많다.

회사도, 코드도 오래되었기에 개선하고싶은 마음은 굴뚝같았는데 되돌아보니 항상 생각뿐이었고,

막상 스스로 진행해본 적은 딱히 없었던 것 같다.

 

최근에 사내의 몇몇 분들과 얘기를 나누면서 도입하고 싶은 문화가 있었는데, 일단 진행을 해봐야겠다.

박재성님이 말씀하신 내용을 간략히 나타내보면 ...

 

새로운 문화를 정착하기 위해 가장 중요한 것은 리더의 인내심과 용기 새로운 문화를 만들면서 초기 학습 비용 등으로 인해 생산성 저하는 당연하다. 안정화하는데 최소 1년 이상의 시간을 투자해야 한다는 마음으로 믿고 기다려주어야 함. 문화를 만들고, 변화를 만드는 일은 리더만의 책임이 아니다. 누구도 대체할 수 없는 존재로 만들고 싶다면 지금 당장, 바로 도전해라. 실패해도 괜찮다. 실패하기 전보다 나는 한 단계 성장한다. 좋은 회사는 실패해도 같이 도전하는 사람을 원한다. 실패의 책임을 묻는다면 ? 그만둔다. 가장 필요한 것은 가보지 않은 길에 꾸준히 도전할 수 있는 용기

 

실패해도 괜찮다 라는 말이 참 좋은 것 같다.

지금 당장, 바로 도전해보자!

 

그리고, 아직은 주니어지만 시간이 지나면 경력이 쌓일거고, 리더의 자리에도 가게될 날이 올거라고 생각한다.

최근 회사에서 사수분에게 설명을 받다가, 사수분의 회사 메일로 팀장님이 메일을 보내셨는데...

정확한 제목은 생각이 안나지만 90년대의 마음을 헤아리는 방법...? 과 비슷한 메일의 제목이었다.

메일 제목을 보고 사수님과 많이 웃었지만, 이 컨퍼런스를 듣고나니 문득 다음과 같은 생각이 든다..

시니어도 주니어들에 대해 이해하려 하고, 생각하지만 반대로 주니어도 시니어들에 대해 이해하고 생각을 해봐야겠다는.. 생각이다.😊