BAEKJH BE Developer

OKKYCON: 2021. 협업의 기술

2021-03-06
BAEKJungHo

logo

OKKYCON: 2021. 협업의 기술

컨퍼런스 시작 도입부부터 이런 말이 나왔다.

“개발을 조금 못하는 사람이랑은 일을 할 수 있지만, 말 안통하는 사람과는 일을 못하겠다” 라고 말하는 시니어 개발자 분들이 계시다는 말이 나왔는데 그만큼 개발자들은 개발 능력 뿐만아니라 의사소통, 협업능력이 정말 중요하다라는 것을 알 수 있게 해주는 대목이다.

박태웅 님

첫 번째 발표자는 한빛미디어 의장이신 박태웅 님께서 포문을 열어주셨다.

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

커뮤니케이션은 나도 나를 잘 모르는데 남에게 나에 대해 좀 알아줘(내 생각을 좀 알아줘)의 과정이기 때문에 상당히 어렵다고한다. 그럼에도 커뮤니케이션은 중요하기 때문에 어떻게 효과적으로 할 수 있는지에 대해 설명하신다.

의도와 행동

자신의 행동은 의도로 판단 다른사람의 행동은 보이는대로 판단하는 일을 그만두고 공평하게 판단해야한다.

짐작과 사실

짐작과 사실을 구분해라. 저 사람이 나를 보는 눈빛이 이상하네? 라는 짐작을 가지고 다음에 그 사람을 만났을때 저 사람은 나를 이상한 눈빛으로 보던 사람이야라고 레이블링을 하게되는데 이 레이블링을 하지 않아야 커뮤니케이션을 잘 할 수 있다고한다.

짐작과 사실을 분리해서 구분하라고 한다.

텍스트가 아닌 컨텍스트를 전달하라

예를들어 상점에가서 고객이 뻰치주세요라고하면 종업원은 두 가지 옵션이 있다. 그냥 뻰치를 주고 돈을 받거나 “어디에 쓰려고요?”라고 물어볼 수 있다. 그리고 그에 대한 답변에 따라 고객이 어떤 상황에 놓여있어서 뻰치가 필요한지 알아챌 수 있고 그에 따라 더 나은 판단을 할 수 있다.

뭘 해주세요라는 말을 하지말고 왜 이걸하려고하는지를 전달해야한다.

모든 컨텐츠를 위키로 모으는 이유

회사내에서 커뮤니케이션을 할 때 가장 많이하는 실수는 메시지를 파편화 시키는 것이다. 메일쓰다가, 메신저 쓰다가, 구글 Docs 쓰다가 등… 따라서 맥락을 짚는게 어렵다. 이런현상을 컨텐츠 파편화, 컨텍스트 파편화라고 할 수 있을거 같다.

절대 컨텐츠 파편화를 하지 말라고 강조하신다. 모든 컨텐츠를 한 곳에 모으기 위해서는 그러한 사내 시스템을 만들기 위해서는 무조건 Top down 방식으로 해야한다고 하신다. 그렇지 않으면 절대 안바뀌기 때문에… KTH 부사장으로 계실때 이러한 시스템을 만들기 위해서 3개월이 걸리셨다고한다.

모든 컨텐츠를 컨플루언스(Confluence)로 모았다고 하신다.

이렇게 컨텐츠가 한 곳에 모여있어서 컨텍스트를 전달할 수 있게 되면 새로운 개발자를 뽑아서 인수인계를 할 때 상당히 쉬워진다고하신다. 협업해야하는 부서의 컨플루언스 링크와 선임자의 JIRA 링크만 인수인계하고 3일정도만 지나면 한 9개월전부터 일했던 사람처럼 일하고 있다고한다. 그 이유는 컨텍스트가 한 곳에 모여있어서 그 사람을 컨텍스트 속에 집어넣기 때문이다.

컨플루언스 링크는 permanent 링크이기 때문에 해당 링크에 있는 문서만 update 쳐주면, 그 링크를 보유하고 있는 모든 사람들은 항상 최신의 문서를 볼 수있게되서 문서관리가 쉬워진다고 하신다.

보고와 사고

예를들어 1시에 약속이 있는데 개인적인 일이 생겼다. 이 일이 5분안에 끝내면 제 시간에 도착을 하겠지만, 그렇지 못하면 늦을 상황이다.

이때 내가 이러한 상황에 처해있어서 5분안에 끝내면 제시간에 도착하겠지만, 그렇지 않을 경우 늦을 수도 있을거 같다라고 상대방에게 말하면 상대방은 Plan B 를 세울 기회가 생긴다. 이게 보고이다.

만약, 내가 스스로 최선을다해서 얼른 끝내고 제시간에 가야겠다라고 다짐했지만, 그렇지 못해서 상대방에게 5분전에 나 늦을거 같다라고 얘기하면 그건 상대방이 Plan B 를 세울 기회를 뺏어버리는 것인데 이게 사고이다.

정리

나도 내 생각이 어떻게 떠오르는지 모르고(이러한 매커니즘을 알 방법이 없다.) 나에 대해 잘 모르는 상황에서 상대방에게 나에 대해 알아달라고하는 즉, 커뮤니케이션은 인간이 할 수 있는게 아니라고한다. 그럼에도 불구하고 인간에게 커뮤니케이션은 정말 중요하기 때문에, 위에 정리한 내용처럼 최선을 다해야 좋은 커뮤니케이션이 일어날 수 있다고 강조하신다.

홍영기 님

두 번째 발표는 네오위즈 애자일 코치이신 홍영기 님께서 해주셨다.

주제. “협력의 조건 만들기”

온전한 협력을 위한 필요한 조건들이 어떤 것들이 있는지, 그리고 이러한 조건들을 만들기 위해서 시도했던 내용들과 배운점들에 대한 발표를 해주셨다.

협력의 정의

농구를 예를들어 농구에 참여하는 모든 player 들은 자신의 팀이 승리하기 위한 공동의 목표가 있는데 이러한 공동의 목표를 달성하기 위해서 그 결과를 공유하는 형태의 수행체계를 협력이라고 표현하셨다.

협력(collaboration) : 특정한 목적을 달성하기 위해 서로 힘을 합하여 도움

Wikipedia 에서 찾은 협력 : purposeful realtionship in witch all parties strategically choose to cooperate in order to accomplish a shared outcome

협업(cooperate) : 생산의 과정을 여러 전문적 부분으로 나누고, 여러 사람이 각 부문별로 맡아서 일을 완성하는 노동 형태

협력을 잘하기 위해선?

협력을 잘하기 위해서라는 질문을 던지기 전에 한 가지 생각해봤으면 하는게 있다고 하셨다. 협력 외에도 여러가지 일의 체계들이 존재하는데 어떨 때 협력이라는 체계를 선택하는게 좋을지에 대해서 생각해보는게 좋다고 하신다.

협력은 언제 유리할까?

일이 어려울(complicate)때 보다는 복잡(complex)할 때

전문적(expert) 해법보다는 창발적(emergent) 해법이 필요할 때

작업의 절차와 공정을 명확하게 나누기 어려울 때

협력이 잘 이루어지기 위한 조건과 실천법

협력은 지시할 수 없다.

협력을 선택했을 때 내가/우리가 더 유리한 환경을 설계해야한다.

  • Collaboration Framework
    • 피드백
      • 더 중요한 정보를 더 빨리, 더 자주 받기
    • 투명성
      • 정보공유 및 커뮤니케이션
      • JIRA, Daily Sync Up, Team Competency Matrix
    • 일의 의미
      • 일의 의미를 이해, 일의 가치와 나를 일치
      • Output, Outcome, Impact
      • OKR, Team Chartering
    • 심리적 안전
      • fee safe to take risk and be vulnerable
      • 비폭력대화(None-Violence Communication) : 1:1대화 간에 도움을 받을 수 있는 기법
      • 퍼실리테이션 : 그룹내에서 좋은 의사결정을 하기 위해서 민주적으로 의견을 주고 받게끔 도움을 받을 수 있는 방법
  • 사례 - Team Competency Matrix
    • 팀이 필요로 하는 역량을 모델링
      • 팀 역량 현황 파악
      • 역량 성장 지도
      • 채용의 근거, JD 활용
    • 진행 순서
      • 우리 팀이 해결하고 있는 문제는 무엇인가?
      • 해당 문제를 해결하는데 필요한 역량은 무엇인가?
        • 전문성, 툴 기술, 프로세스, 소프트 스킬
      • 각 역량들의 레벨을 나눈다.
      • 자가 진단, 상호 진단 수행
      • 정리해서 팀에 공유

적용 경험 공유

모든 것은 다 연결되어 있다. 취사 선택하는 것은 효과가 떨어진다.

가장 중요한 것은 심리적 안전을 구축하는 것이다. 한번 무너진 신뢰는 다시 복구하는데 큰 비용이 든다.

시스템을 구축하자. 사람에 기대면 그 사람이 없어지면 바로 사라진다. 체계를 만들고 그 안에 루틴을 세운다. 시스템을 만들고, 관리하고, 훈련하고 코칭하는 사람이 필요하다.

정리

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

박재성 님

세 번째 발표는 우아한형제들 교육이사이신 박재성 님께서 해주셨다.

주제. “함께 성장하고 협업하는 문화를 만들어가는 과정”, “개발 문화는 어떻게 만들 것인가?”

어떤 문화를 만들고 싶은가?

  • 리더의 목표
    • 지식을 공유하고, 같이 성장하면서 유지보수하기 좋은 코드를 구현하는 팀을 만들고 싶다.

팀의 문화를 만들려면 어디서부터 어떻게 시작하면 좋을까?

예를들어 리더가 온라인 코드 리뷰 또는 짝프로그래밍, TDD 를 팀의 문화로 정착시키고 싶어한다. 따라서 대부분의 리더들이 이슈관리, CI 프로세스 등을 만들어 팀 문화로 정착시키기 위해 노력하는데 이러한 방식을 아웃사이드 인 접근 방식이라 한다.

그리고 아웃사이드 인 접근 방식은 필패의 지름길이라 표현하셨다.

왜 ??

리더는 만들고 싶은 개발 문화의 방향성만 정하고 구체적인 개발 프로세스는 최대한 뒤로 미룬다.

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

사람은 기본적으로 변화를 거부하는 성향

팀은 변화를 거부하는 성향이 강함

대부분의 사람들은 변화에 실패한 경험을 가지고 있음

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

구글 내부에서 성공한 팀의 특성 중 첫 번째로 소개된 것은 심리적 안정감(Psychological Safety) 이었다.

심리적 안정감이란?

구성원이 업무와 관련해 그 어떤 의견을 제기해도 벌을 받거나 보복당하지 않을 거라고 믿는 조직 환경이다.

즉, 팀의 변화를 만드는 일을 성공하기 위해 가장 중요한 것은 심리적 안정감을 어떻게 만들 것인가? 이다. 이러한 방식을 인사이드 아웃 접근 방식이라 한다.

  • 팀원들과의 신뢰 형성이 우선
  • 1:1 면담을 통해 개선할 부분 찾기
    • 팀원이 문제점을 이야기할 때 문제점에 대한 해답을 제시하려하지 말고, 어떻게 하면 될까?, 너라면 어떻게 할거 같아?라는 반문을 해라
    • 팀원들이 제안한 Practice 속에서 작은 변화를 통해 가장 높은 효과가 있을 것으로 생각되는 Practice 를 선택한다.
    • 선택한 Practice 가 개인, 팀 모두 익숙해 질 때까지 한 가지에 집중한다.
    • 그리고 팀이 작은 성공(small success)을 맛보는 것이 중요하다.

정리

  • 새로운 문화를 정착하기 위해 가장 중요한 것은 리더의 인내심과 용기
    • 새로운 문화를 만들면서 초기 학습 비용 등으로 인해 생산성 저하
    • 안정화하는데 최소 1년 이상의 시간을 투자해야 한다는 마음으로 믿고 기다려주어야 함.
  1. 면담, 회고
  2. practice 선택
  3. 한 가지에 집중
  4. 작은 성공

김영욱 님

세 번째 발표는 SAP Product Engineering 및 SAP UX 시니어 프로그램 매니저이신 김영욱 님께서 해주셨다.

주제. “당신에게 협업의 대상은 누구인가요?”

협업의 첫 번째 대상

협업의 첫 번째 대상은 생각이다.

무엇이 생각의 아이디어의 효율성을 결정하는가? 확산과 도입 속도의 차이를 만드는가?

  • Fast Ideas
    • 이해 당사자 편의성
    • 가시적으로 즉각적인 효과
    • 경제적 인세티브
    • 기술적 복잡성
  • Slow Ideas
    • 타인 편의성
    • 근본적이고 장기적인 효과
    • 사회적 인센티브
    • 절차의 귀찮음

Slow Ideas - 지구 온난화 문제, 출산 시 영아 사망률 등

협업의 첫 번째 치트키

  • Policies, Guidelines, Codes, Protocols, Convention
  • 형식에 맞는 이메일 쓰기
  • Wiki 에 정보 모으기
  • 미팅에 늦지 않고, 회의에 집중하기
  • and so on

협업의 두 번째 대상

협업의 두 번째 대상은 소외받은 고객이다.

고객에 얼마나 충실한지 생각해 봤나?

  • ex) 시각장애인들이 비장애인들과 동등하게 사이트를 이용할 수 있도록 신경쓰는지

김영욱님의 발표를 듣고나서 드는 생각은, 많은 개발자들이 개발자 중심으로 개발하기 보다는 사용자 중심으로 개발해야 한다는 것을 알고 있으며 “나는 사용자 중심으로 생각하고 개발하는 개발자야”라고 말을 하지만, 실제로 얼마나 사용자들한테 관심이 있고 사용자 중심으로 개발하기 위해서 무엇을 어떻게 했는지 어떤 고민을 했는지에 대해서 생각해 볼 필요가 있다고 생각한다.

김영욱님이 발표 중 한 그림을 보여주셨다. 화장실 벽에 손바닥 모양의 그림과 그 아래에는 WAVE HAND OVER THE CENSOR TO ACTIVATE 라는 문구가 적혀있고, 손을 흔들면 물이 나오는 도구였는데 이 디자인은 아주 나쁜 디자인이라고 말하셨다.

그 이유는 손에 장애를 가지신 분이거나 혹은 그 당시에 손에 물건을 들고 있다거나, 영어를 읽을줄 모르는 등 이러한 고객층까지 생각하지 않고 디자인 한 것이기 때문에 소외된 고객이 발생한다.

협업의 두 번째 치트키

소외된 고객이 없도록 적극적으로 협업해야한다.

협업의 세 번째 대상

협업의 세 번째 대상은 자율 머신이다. 즉, 기계와의 협업이다.

  • 자율 머신
    • Vehicle
    • Road
    • Robot
    • Buying Algorithm

헙업의 세 번째 치트키

미래의 고객과 대화를 준비해야한다.

정리

  • 기본 업무 원칙을 지켜라
  • 소외된 고객이 없도록 포용적 사고와, 행동을 해야한다.
  • 미래의 고객과 대화를 준비해야한다.

“누군가가 다른 눈으로 사물을 보는 방법을 보여줄 때까지 사물을 보는 방법은 하나뿐이다.” - Pablo Picasso

김영재 님

네 번째 발표는 라인플러스 Technical Fellow이신 김영재 님게서 해주셨다.

주제. “프로덕트 조직의​ 생산성 높이기”

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

개발자의 시야는 좁다

우리가 만든걸 다른 팀들은 어떻게 대화하고 있지? 새로운 개발 업무는 어떻게 만들어지지?

  • 프로그래밍 이외의 것들
    • 이슈트래커
    • 빌드/배포
    • 모니터링
    • 커뮤니케이션 채널
    • Wiki
    • 회의록
    • and so on

이슈트래커

JIRA, ASANA, YouTrack, Pvotal Tracker …

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

Demo

  • JetBrains Task & Context
    • Hadi Hariri 가 매년마다 시연하는데 해본 사람은 거의 없는 듯
  • 이슈트래커 제어와 커밋을 피아노치듯 경쾌하게 할 수 있다.
  • IDE 와 status 의 연계는 정말 중요하다.

커밋메시지 주도 개발

미래의 커밋메시지를 이슈 티켓으로 만들고 개발한다.

  1. 이슈생성
  2. 테스트 & 코드
  3. 커밋
  4. 푸시
  5. 릴리즈

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

  • 이슈 처리가 곧 개발 속도감을 더해준다.
  • 개발자에게는 커밋 단위로 상상하게 하는게 가장 와닿는다.
  • 이슈를 빠르게 만들고 싶은 욕구가 자연스럽게 나타남
    • 원 클릭으로 커밋메시지를 작성하다.

CI/CD Builder 빌드서버

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

Progressive YearWeek Versioning

version: 3.1924.59

  • 3 : head(수동)
  • 1924 : yearweek(자동)
  • 59 : build(자동)

장점

  • 질문: 도대체 v1.0 에서 언제 벗어나는거야? -> 모든 숫자가 의미있도록
  • 가운데 숫자만 보면 얼마나 오래된 버전인지 누구나 알 수 있음
  • 빌드서버가 버전을 만들어주므로, 가은 버전에 같은 바이너리를 확신함
  • 뒷 숫자인 빌드넘버로만 대화해도 정확한 버전을 파악할 수 있음
  • 빌드서버에서 빌드만 하면 버전관리 전혀 신경쓰지 않아도 됨
  • 첫 자리 수동 번호가 있기 때문에 레거시 버저닝도 배려하고 있음
  • 세자리이므로 SemVer 형식과 호환. 심지어 버전을 전혀 신경쓰지 않아도 SemVer 비교규칙에 맞게 증가
  • 주단위 스프린트를 하는 팀은 2104를 제목으로 사용 가능 2주 단위 스프린트는 짝수/홀수로 사용 가능.
  • 빌드할 때마다 전진하므로 속도감있는 빌드 프로세스를 강요
  • 참고: 언제 head 를 올리는가? 유저에게 도달할 때마다.

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

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

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

  • 라이브러리 사용 최소화
  • 하나의 repo 에 모아놓는다.
  • 개인 repo 가 아니라 팀 repo 에 쌓는다.
  • 거의 동일한 형식으로 작성

생산성 향상 방법론

  1. 질문 발견
  2. 질문을 없애버리 겠어!
  3. 프로세스 관찰
  4. 프로세스 개선
  5. 문서화

질문은 문제를 파악하는 더듬이

  • 이 질문이 나오면 뭔가 대단히 잘못됐다는 의미
    • 릴리즈 됐나요?
    • 이번 버전에서 수정 됐어요?
    • 그 버전 어디서 다운 받아요?
  • 교육이 필요
    • 위 답변이 나올 때마다 직접 볼 수 있는 URL 을 꼬박꼬박 넣어수잔다.
    • 직접 해도 괜찮다고 말해준다.
    • 이슈를 개발자가 즉시 만들어주고 링크를 건네준다. (개발의 언어로 만듦)

프로세스 개선

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

문서화, Wiki

  • 잘 쓴 Wiki
    • 수명이 긴 글
    • Reference 가 충실한 글
    • 개성을 줄이고 건조하게 쓴 글
    • 남에게 수정 가능성을 열어둔 글
    • 일관된 구성
      • Introduction / Reference
      • Figure(Diagram), Steps
  • Wiki 작성 팁
    • 2021 년을 21이라고 줄여쓰지 않는다. 애매하게 읽힐바엔 yyyy-MM-dd 하는게 낫다.
    • 테이블은 적게 쓸 수록 좋다.
    • 특히 3칸 이상 span 처리된게 있으면 애초에 잘못된 테이블이라고 생각해야한다.
    • confluence wiki 에서 section 기능으로 구획만들어 쓰는 경우가 많은데, 안쓰는게 낫다. 특히 한국의 문서 문화는 내용을 틀 안에 넣고야 말겠다는 의지가 많은데, 줄이자. 2단으로 좌우 section 을 만드는 경우도 많은데 구조상으로 장점이 분명하지 않다면 2단 구조는 flow 형태의 웹 문서에는 그리 맞지 않다.
    • Heading 은 1(또는 2)부터 만든다. 스타일이 예쁘다는 이유로 4 부터 쓰지 않는다.
    • 첨부이미지 다이어그램보다는 draw.io 라거나 wiki 에서 제공하는 다이어그램 도구로 그리는게 미덕이다. 이미지로 넣을거면 원본(아마도 ppt 파일)도 항상 함께 붙인다.
    • 페이지 정보의 수명이 길 수록 사람 태깅을 최소화 한다. 나중엔 죄다 unknown 되어있다. 특히 소개 페이지에 담당자를 적을 바엔 팀 연락처를 적는게 낫다. slack 링크든 메일링이든.
    • 회의록의 경우도 참여자 명단을 안건보다 하단에 배치한다. 어차피 누가 참여했는지 관심 없다.
    • 어떤 문서든 마지막에 Reference 를 추가하면 좋다.

정리

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

이동주 님

다섯번째 발표는 번개장터 CTO이신 이동주 님께서 해주셨다.

주제. “OKR 기반으로 스케일업 가능한 협업 체계 만들기”

번개장터의 협업체계는?

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

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

대부분의 정보 작성은 위키(Confluence)를 이용하여 아주 민감한 정보가 아니라면 모든 구성원이 정보에 접근할 수 있음

대부분의 업무는 JIRA 에 등록하여 관리

각자의 업무 오버헤드가 어떤지 쉽게 알 수 있게, 업무 완결을 위해 어떤 업무가 더 진행되어야 하는지 알 수 있다.

JIRA 로드맵으로 전반적 계획을 알 수 있게한다.

이외에도 사용하는 도구들

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

협업은 목표에 대한 공감에서부터 시작

목표 기반의 업무 체계 도입

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

번개장터에서 OKR 의 의미

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

문제를 명확히하고 집중하면 목표를 달성할 수 있다.

실무 리더 중심으로 CELL OKR 수립

전사적으로 OKR 과 CELL 의 큰 틀과 방향은 경영진에서 정리하고, 각 셀별로 실제 OKR 은 셀의 실무 리더들이 논의하여 반영하고, 다시 경영진에서 논의하고 수정하는 과정을 반복하여 OKR 확정

정리

번개장터는 OKR 과 CELL 을 통해

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

김상우 님

여섯번째 발표는 쏘카 데이터그룹 그룹장이신 김상우 님게서 해주셨다.

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

좀 허접해도 직접 만들어 버리자!

아이디어부터 개발, 사업에 적용까지 그 자리에서 다 할 수 있는 진짜 애자일한(민첩한, 날렵한)팀 구성

좋은 개발팀과의 좋은 관계

  • 우리가 할 일을 저쪽에서 왜? (X)
  • 공동의 목표, 같이 달성하는 것(O)

There’s no silver bullet

in software engineering

만능의 열쇠는 없다.

정창훈 님

일곱번째 발표는 당근마켓 CTO 이신 김상우 님게서 해주셨다.

주제. “당근마켓 성장에 따른 협업의 변화는 진행 중”

Startup

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

과정

  • 초기(2016 년 ~ 2018년 초기)
    • 지향하는 목표가 맞아있는 상태
      • 프로덕트를 열심히 만들기만 하면 됨
      • 비슷한 아이템으로 만들고 있는 지인들이 2팀
    • 프로덕트 마켓 핏을 찾는 과정(전체 6명, 개발자 4명)
    • 비전을 맞춰가는 과정
      • 새로온 분들과 비전을 이야기하고 맞춰가는 상황
      • 장기적인 비전과 단기적인 목표에 대한 이야기를 서로 자주 했던 시기
      • 단순히 제품을 만드는 것에 더해 비전을 다 같이 맞추는게 중요했던 시기
    • 하루에 배포 몇번?
      • 커밋 20개는 배포 20번
    • 다 같이 운영
      • 회의도 다 같이
      • 하루씩 돌아가면서 CS 대응
    • 협업에 대한 고민 x
      • 뭐든지 다 같이 하고, 서로의 상황을 다 알고 있는 상태
  • 10명 & 판교로 이사(2018년 중기)
    • 전체 10명 중 개발자 7명
    • 하루에 배포 몇번?
      • 커밋 20개는 배포 20번
      • 동시에 배포 못하게 배포 락 기능을 만들어야 했음
    • 다 같이 놀고, 일하고 2년
    • 인프라, 머신러닝은 각자의 영역이 생겼지만 그 외는 다같이
  • 25명 & 서초로 이사(2019년 중기)
    • 10명 추가(마케터, 머신러닝 개발자, IOS, 안드로이드 개발자, 프론트 개발자, CS 담당자, 서버 개발자, 그 외 여러 포지션)
    • 이제 서버가 좀 터지네…
    • MAU 100만 ~ 300만
    • 전문 영역이 생겼던 시기
    • 하루 배포 몇번?
      • 서버 증가로 도커 도입
      • 도커 빌드 시간으로 인해 기존 배포시간보다 늦어지고 방법도 복잡해짐
      • 배포 속도 급격한 감소
      • 빈도가 줄어듦
    • 회의실 1개
      • 1:1 미팅이나 전체 회의때 주로사용
    • 같이 하기 힘든것들이 생기는 시기
  • 140명 & 이사(강남)(2020년 ~ 2021년)
    • 기존에 만들어진 레거시에 대한 히스토리를 아는 사람이 적음
    • 검색의 중요성이 커져서 Wiki 사용
    • 사업 + 플랫폼
      • 트래픽을 견디고 확장 가능성을 위해 기존 서비스에서 플랫폼을 분리하는 작업들 진행
    • 회의실 5개, 1인실 2개
    • 서로에 대해 알 기회가 줄어들고 있다.
  • 150명 & 이사(신논현)(2021년)
    • 조직별로 분리된 공간
      • 이제는 의도를 가지지 않고서는 서로 만날수 없음
      • 한층에서 여러층으로 나눠지는 시기가 중요하다고 함
    • 협업에 대한 고민 시작

“사람이 변하듯 조직도 계속 변화합니다. 하나의 정답이 있을수는 없습니다. 사람 숫자에 따라 비지니스에 따라 달라집니다. 협업은 특히 사람의 숫자에 영향을 많이 받는것 같습니다.”

개발문화는 어떤가요?

“저는 잘 모르겠다고 이야기 합니다.”

  • 회사 업무에서 하고 싶은것들을 할 수 있는 환경을 만들어주는 것을 중요하게 생각합니다. 업무의 몰입도를 높이려고 노력합니다.
  • 회사에서 강제하는 것이 없는 것이 문화일수도 있겠다는 생각을 합니다.
  • 하지만 규모가 커지면서 강제하는 것들이 조금씩 생긴다.

회사를 만들어가는건 사람

  • 사람이 중요하고 회사를 만들어 간다는 걸 많이 느겼다.
  • 문화도 결국 사람이 만들고 회사도 구성원들이 모여서 바뀌어 간다고 생각한다.
  • TDD 나 스크럼등 제도가 중요한게 아니라 사람이 중요하다. 사람이 제도를 만들어간다.

QNA

  • 심리적 안정감이 구축되지 않은 상태에서 리더에게 효과적으로 제안하는 방법이 있을까요?
    • 정창훈 님: 심리적 안정감이 없더라도, 조직이 건강하다 생각하면 우선 이야기하고, 만약 안정감 없게 이야기하면 회사를 떠나야하나?
    • 이동주 님: 누가 먼저 하기는 어렵다. 조직원들이랑 밥을 먹는다. -> 조직원이 자연스레 고민들을 얘기한다.
    • 박재성 님: 개발자는 전문가이기 때문에, 리더가 어떻든, 회사가 뭘 추구하던 전문가로서 마땅히 해야하는 것들이 있다면 남이 시키건 말건 해야한다고 생각한다.(인사이드 아웃 방식) 개발자는 갑이다. 요즘 개발자는 너무 착하다. 리더에게 자꾸 이딴식으로 갈꺼면 전부 때려칠거다라는 마인드도 어느정도 필요하다. 시키는 일만 하지 말고 전문가로서 주도적으로 내가 영향력을 미칠 수 있는 연습을 해야한다. 이게 리더로 갈 수 있는 연습 방법 중 하나이다.
    • 김영재 님: 처음 변화가 너무 과격하면 안된다. 옳은 방향이라 하면 설득을 해보고 설득이 안되면 그냥 적용해버린다. 적용하고싶은 것이 효과적이라는 것을 검증한 다음에 해야한다.
  • 회의록 자동화 어떻게?
    • 김영재 님: 회의록 생성 자체를 API 이용해서 만든다. (회의록을 자동으로 요약해주는 그런 것은 아님.)
  • 모놀리식을 MSA 로 바꾸는데 1달이 걸릴거 같은게 4달 걸렸다.
    • 박태웅 님 : 보통은 1년 이상이 걸리거나 그마저도 실패하는 경우도 많은데?
    • 김상우 님 : 전부다 바꾼 것은 아니다.
  • 더 생산적으로 일하는 방법에 관심 없는 사람들에겐 새로운 방법이 더 좋다는걸 어떻게 납득시킬 수 있을까요? 사람들의 관성과 어떻게 싸우셨는지 궁금합니다.
    • 김영재 님: 가장 쉬운건 입사 하자마자 이 회사는 이렇습니다 라고 말하는게 가장 쉽다. 그 사람을 설득하기보다 그 주변을 먼저 설득한다. 그래도 그 사람을 설득해야 할 일이 생기면 최종적으로 감정적으로 호소한다. 실제로도 잘 먹힌다.
  • 당근마켓은 새기능 추가를 초대한 안하려 하신다고하셨는데 그러면 새기능을 추가해야한다면 그 판단은 어떻게 하시는지요?
    • 정창훈 님: 초기 멤버들 몇몇의 생각이었다. 초기 멤버들의 앱 개발 성공/실패 경험 덕분에 가능했던거같다. 이야기를 많이한다. 최대한의 공감대가 형성되지 않으면 안한다.

Pannel Discussion

  • 회사는 직원들이 성장할 수 있도록 환경을 마련해 줘야 하는데 어떻게 하는지?
    • 정창훈 님: 신입들은 자기가 뭘 좋아하는지도 모르는 경우가 많기 때문에, 더 어렵더라도 도전할 만한 새로운 일을 주거나, 하고싶은 것들을 하게한다.
    • 김상우 님: 개인 레벨에 맞게 일들을 분배하던지, 없던 일이라도 개인 성장에 필요하면 만들어서 준다. 난이도 조정이 중요하다.
    • 김영재 님: 뭘 해보라고 하기 전에 내가 공부한 다음 준다.
    • 박재성 님: 소프트웨어 장인이라는 책을 추천한다. 리더가 되기전에 교육자로 2-3년 정도 해봐라. 면담 등을 통해서 개인의 특성, 다른 측면을 찾아서 꼭 개발만이아니라, 다방면으로 제안을 해준다. 이런게 리더가 해야하는 역할이다. 상시적인 피드백 문화가 중요하다.

Comments

Index