OKKYCON: 2017 소통, 개발을 불어넣다》 강연요약 및 회고

Jeong Woo Ahn
Dec 18, 2017 · 15 min read

강연을 참가하기 위해 오랜만에 강남으로 출근하게 되었는데 하필 눈길헤치면서 가게되었다. 힘들게 가게되었지만 매우 진지한 분위기에 생각보다 많은 참가자로 출근의 스트레스가 풀렸다. 다 끝나고도 퇴근시간이 좀 남아 강연요약 및 회고를 해보았다. 물론 이 글은 지극히 주관적이고 개인적인 기록이다.

《Extreme Programming(XP), 더 나은 소프트웨어 품질을 위한 일의 방법》

Pivotal의 업무패턴

  • 9:00 전체 스탠드업 회의 — 마이크를 써서 5분만 한다. 서서 한다. 회사 가십(입사/퇴사 등등)얘기.
  • 9:05 팀 스탠드업 — 늦어도 9:30 넘기지 않는다.
  • 9:30 업무시작

=> 아침 식사시간이나 스탠드업 회의때 중요한 이슈가 다뤄지므로 메일 커뮤니케이션이 그다지 필요없다. 그래서 사내에서 공식적으로 이메일 사용하지 않는다. 말로하거나 구글독스나 이슈트래커 같은 도구들을 많이 쓴다.

Balanced Team

  • 중요한 팀 분위기 : 실패를 허용한다. 릴리즈 되더라도 실패해도 된다. 시스템이 보장해준다. 실패가 테스트과정에서 자동감지될 가능성이 높고, 릴리즈 되더라도 쉽게 되돌릴수 있으므로.

Pair Programming

TDD in Pivotal : 모든 코드는 테스트가 있어야한다. TDD를 해야하는 이유는 너무나 많다. 가장 중요한것은 결국 쉽핑(배포). 코드의 양이 매우 커지더라도 높은 품질을 유지할 수 있다.

결국 문화다

“변화하는 환경에 적응하도록 코드를 작성하라"


나의 회고

  • 약간 주제가 모호하지 않았나 싶다. 여러가지 도움되는 이야기는 많았지만 핵심 주제는 흐릿한 느낌이었다.
  • 짝코딩을 문화적으로 강조하는 정도가 아니라 아예 자리 배치를 두 명씩 짝지어서 앉도록 한것이 파격적인것 같다.
  • 매우 높은 수준의 TDD를 이야기하는데, 솔직히 현실성이 얼마나 있는지 잘모르겠다. 실리콘밸리니까 가능한거 아닌가 싶기도 하고.
  • 피봇탈 입사하기전의 스타트업 경험을 얘기하면서 이런말을 했다. “제품이 실패해서가 아니라 팀이 실패해서 제품이 실패하는 경우가 많다”
  • 전체 스탠드업 회의, 스타트업이라면 잘 운영하면 회사 분위기를 매우 좋게 가져갈 수 도 있겠다는 생각.

《디자이너와 개발자와의 협업을 위한 디자인 시스템》

  • 자사에 디자인 가이드 책자가 있다. 주로 UI 가이드다. 내가 말하고자하는 것은 이보다는 좀 더 발전된 시스템이다.
  • Atomic design : 작은 단위의 디자인을 먼저하고, 그것들의 조합을 만들고 그 조합의 조합으로 섹션이 만들어지고, 그것이 모여서 페이지가 되는 방법론.
  • Awsome Design system 에 가보면 현존하는 디자인 시스템들의 목록을 볼 수 있다. 디자인 시스템이란 팀이 디자인을 수행하기 위한 가이드와 문서들이다. 조직의 아이덴티티와 Voice&Tones 를 담고있다.
  • Atlassian Design 시스템이 매우 참고할만한 시스템.
  • 이런 시스템은 애자일적인 개발에 매우 도움이 된다. 매우 빠르게 시스템에 디자인을 추가할 수 있다.

문제

  • 자동화 툴이 매우 잘된것이 아직 없다.

해결

  • 코드를 변경하면 실시간으로 Sketch에 반영된다.
  • 코드로 디자인하기 때문에 목업데이터를 사용하면 바로 목업 제품이 만들어진다.
  • 다양한 디바이스 크기를 자동으로 볼 수 있도로 구현하거나, 다양한 언어로 볼 수 있다.
  • Source of Truth 자원을 중앙화하면 전체가 효율적으로 일할 수 있다.
  • 이미지/뷰/SVG 컴포넌트만 지원한다.

어떻게 도입할 것인가?

  • 코드 자체는 어렵지 않을 수 있으나, 리액트의 작동원리 구조가 어렵다. 이것이 단점.
  • 디자이너는 실제로 코드를 배우고 싶어한다. 개발자들이 안가르켜준다고 말한다. 개발자들은 가르켜줘도 모른다고 얘기한다.
  • 지금은 퍼블리셔가 컴포넌트를 작성해주고 있다.

중요한것은


나의 회고

  • React Sketch.app이 뭔지 어떻게 사용하는지는 검색하면 금방 알 수 있고 테스트코드도 금방 만들어볼 수 있다. 실제 협업 프로세스를 도입할때 발생했던 이슈들과 노하우를 중심으로 이야기했다면 더 많은 인사이트를 줄 수 있지 않았을까. 좀 아쉬웠다. 그리고 React Sketch.app 자체는 매우 제한적인 환경에서만 도입가능한것이다. 현재는 Vue.js 를 사용하는 경우 그 도구의 사용법은 의미가 없다.
  • React Sketch.app 이 아니더라도 Atlassian Design 시스템을 잘 참고 해서 나름대로 디자이너와 프로세스를 만들어가면 좋을것 같다.

《애자일은 애자일이란 단어를 버려야 한다》

  • 회고/추정/짧은 릴리즈/스프린트계획/현황판/번다운차트/테스트케이스/회색영역관리 => 현실성이 낮다. =>교통사고 안나는 방법을 우리는 모두 잘 알지만 교통사고는 일어난다.
  • 망하는 프로젝트 징후 : 애자일 형식에 대한 맹신 / 목표없는 잦은 주기/의미 없는 회의 / 기준없는 측정 / 자발적인지 않은 교육 / 겉치레 적인 시스템 평가 => 이런 경험한 개발자들이 반애자일 논자가 되는 이유.
  • “문제는 애자일이야"가 아니라 “문제는 애자일 형식에 치중했기 때문이야" 이다.

역할

  • 나는 파악을 위해 정책/요구사항/프로토콜/UI,UX진행상황/테스트케이스/커밋기록/현황판 중심 데일리미팅
  • 데일리미팅 : 할일 보고하는 식으로 하지 않는다. 리스크/이슈 에 대한 것만 얘기한다. 현황은? 지라 현황판을 띄어놓는다. 그것을 보면된다. 데일리 미팅은 적어야한다. 이 기록이 회고때 쓰인다.
  • 이 파악을 통해 결정을 하게된다.
  • 결정이 타팀에 영향을 미치게되면, 상황설명과 객관적 선택리스트를 제시하여 타팀의 결정을 기다리고 쪼은다.

갈등 케이스

  1. 기획자/개발자/품질책임자: 기획자왈 “나는 이렇게 생각하지 않았어", 성능에 대한 서로다른 기준. 이런 차이들을 해결하는 사람이 품질책임자이다. 풀질책임자의 테스트케이스 중심으로 개발한다. 케이스가 모두 통과되어야 개발이 완료된다.
  2. 기획자와 품질책임자 : 정책이 정해지지 않은경우 : 서로 다른 상상 -> 너무 많은 테스트케이스. 많은 변경. -> 데일리 정책회의로 해결. 품질책임자가 이끌면서 계속 질문.
  3. 디자이너와 개발자 : 디자인QA를 거치는데 디테일한 애니메이션 수치들에 대해 얘기한다. 개발자가 그 모든 디테일을 모두 맞추기 힘들때가 있다. 싸우지 말고 서로 양보하고 협의를 해야함.
  4. 최고 의사 결정자와 팀 : 가장 힘들었던 관계. 바로 일정때문이다. “힘들어요 시간을 더주세요" => 전혀 먹히지 않는다. 수치가 중요하다. 전체 일정중 몇 퍼센트나 진행이 되었고, 무슨 이슈들이 있고, 앞으로 무엇이 예상되는지 정확히 근거를 제시해야.
  5. 중요한 것은 이런 케이스들을 잘 해결하고 그것을 정리하는것.(갈등상황과 솔루션)

스케줄링

  • 스프린트회의 : 시간을 줄이기위해 회고 후이어 바로 진행. 가장 먼저 정책과 요구사항을 발표 >구현이슈 논의 > 모호한 상황 파악 및 결정.
  • 기획중심기간/구현중심기간/테스트중심기간 으로 크게 나뉜다 : 프로젝트 초기에 정책과 요구사항이 미완성일때 기획중심으로 진행한다. 요구사항이 명확하게 될때 구현중심의 스프린트가 진행된다. 그다음 테스트 중심의 스프린트. 이후에는 이것의 반복일 수 있고 규형을 찾을수도.

회고

  • 초기 스프린트 회고는 일정에 대한 이야기보다, 큰 그림을 많이 얘기했다.
  • 좋은점/나쁜점은 마지막 스프린트때 했다.
  • 프로젝트의 시연을 하는 자리를 가졌다.
  • 이슈에 대한 해결사항 명확하게 기입.
  • 끝날때 화이팅.

나의 회고

  • 현실에서 느꼈던 것들을 잘 일반화해서 말씀해주셨다.
  • 책임감이 넘치는 분이신듯. 저런 자세로 팀을 이끌면 어떻게 실패할까? 라는 생각이 들었다.
  • 개인적인 경험을 미루어 보더라도 “형식”에 집착하지 말고, 내용에 집착하라는 메시지가 정말 중요한것 같다. 그것과 관련된 매우 디테일한 경험이 매우 도움이 되었다.

《협업도구로 제대로 말하기》

변화를 원한다면

  • 잘 정착시킬 수 있는 영향력있는 사람(회사대표)를 조력자로 만들어라.
  • 무엇이 원할한 협업을 더디게 만드는지 식별하라.

평가기준

  • 검색할 수 있는가
  • 개방적이고 공유가 쉬운가
  • 다른 도구와 연동
  • 사용료 대비 가치

현재 우리의 도구 셋

  • Jira / Confluence
  • Slack
  • Github

그밖에

  • 이메일은 보조도구다
  • 메신저가 협업의 메인 도구. 슬랙
  • 파워포인트는 내용에 집중하기 어렵다. 위키가 그점에서 좋다.

나의 회고

  • 난 이미 예전부터 쓰고 있는 도구들에 대한 얘기들이 많아서, 아직 도입하지 않은 분들에게 유용한 세션이었을듯.

《생산성 지향의 커뮤니케이션과 기업 문화》

  • 소프트 스킬의 시대 : 2015년 900명의 기업 임원들의 설문조사 “정량적으로 측정이 안되는 소프트 스킬이 기술적인 능력과 동등하거나 중요하다” 고함.
  • 90% 커뮤니케이션이 6번 스프린트로 반복되면 53%로 줄어듬. 90% 커뮤니케이션이 큰 숫자가 아니다.
  • “We’re a team, not a family. We’re like a pro sports team” — Netflix
  • Ubiquitous Language — 업계의 모든 용어의 정의를 정리할것. 전사원, 전 멤버가 함께 작성하는것이 좋다. 프로젝트 진행시 계속 업데이트. 위키활용.
  • 회의록 작성할 것 — Goals/Discussion Points/Agreements/Action item 액션아이템 트레킹할것. 모든 회의를 할필요는 없지만 중요한 회의는 반드시 작성할 것.
  • 조직문화는 정원과 같다 — 지속적인 관심 필요하다는 뜻에서 정원사. 누군가는 그 역할을 해야.
  • 질문—커뮤니케이션 안좋아하는 개발자는 함께 할 수 없나? 팀에 피해가되지 않는다면, 하드스킬이 좋아서 비즈니스에 충분히 도움된다면 같이 갈 수 있다고 생각한다.
  • 질문 — 메일에 대하여: 메일은 받는 사람이 끝까지 읽지 않을거라는 가정을 하고 쓰는게 좋다. 앞부분에 중요한걸 모두 담아라.
  • 질문 — 논쟁이 격해질때: 꼭 결론을 낼 필요는 없다고 생각한다. 그러나 결론을 내지 말라는 말은 아니다. 맛없는 절충안을 내느니 회의를 끊고 차분해진 다음에 다시해서 최선의 결론을 찾는게 좋다. 회의록에 Discussion Points을 작성하고 시작하는것이 불필요한 논쟁을 줄이는 팁이기도 하다. 그리고 반칙을 하면서까지 논쟁을 하는 경우가 있는데, 모든 논쟁을 포용해줄 프로세스가 존재하지 않을 뿐더러 그럴 필요가 없다고 생각한다.

회고생략


《협업의 미신 5가지 — 근거 기반 협업으로 가기 위해》

  1. 프로그래밍은 잘하는데 협업은 못해 — 프로그래밍과 협업을 분리하는 사고. 오래된 사고다. 프로그래밍 실력을 정량화하는건 매우 어렵다. 그래서 쉬운방법으로 정량화하곤 한다. 어떤 문제를 혼자 풀게 한다던가. 60년대에는 그렇게 정량화 했다. 그러나 90년대의 연구에서는 더 복잡한 맥락속에서 여러 개발자들이 문제를 풀게 하면 다른 양상을 볼 수 있었다. 이렇게 평가한 뛰어난 그룹은 오히려 사회적 관계를 중요하게 생각하는 경향이 있다. 이제는 협력도 프로그래밍의 한 부분으로 보는것이 일반적이다.
  2. 팀의 퍼포먼스는 가장 뛰어난 사람이 좌지우지 한다 — MIT의 집단지성(CQ)에 관한 논문, 어떤 문제를 줘도 잘하는 팀이 존재하는가? 의외였던것은 팀의 IQ 의 최대치가 팀의 퍼포먼스에 영향을 미치지 못했다. 연구결과는 공감력이 CQ에 가장 중요한 영향을 미친다고 말해준다. LOL게임에서도 같은 현상을 볼 수 있었다. 일이 복잡해질 수록 한사람이 좌우하기 힘들어지고 협업이 중요해진다. 이런 업무는 인공지능이 대체하기 힘들다. 단순한 프로그래밍 업무는 앞으로 인공지능이 대체할것.
  3. 전문가를 모으면 협력을 잘할것이다 — 협력은 가르켜주지 않는다. 단순히 반복한다고 잘하는거 아니다.(칫솔질) 두 개의 전문가 그룹에 한쪽은 논의해서 결정하라고 얘기하고 나머지 한 그룹에게는 알아서 하라고 했을경우 후자가 평균적인 전문가 그룹보다 떨어졌다. 전문가를 모은다고 자동으로 협력이 잘되지는 않는다. 우리는 자주 “어떻게 협력할까"는 잘 얘기안하는데 그걸 의식적으로 하기만 해도 효과가 좋다.
  4. 협력을 잘하는것=인간관계(=회식=좋은게 좋은거지) — 물론 좋은 관계는 협력에 좋은 것이다. 회피를 하면서 좋은관계를 유지하는 경우가 있다. 신혼때 싸운횟수와 15년 후의 이혼을 조사해보았더니 음의 상관관계를 가지는 연구가 있었다. 많이 싸울수록 15년 후에 이혼을 안 하더라는 것. 부정적인 감정을 얘기하는 팀(물론 건설적으로)이 퍼포먼스가 좋았다는 연구도 있다. 좋은 얘기만 하는 팀이 좋은 팀이라는것이 아니다.
  5. 분업을 잘하는것이 협업을 잘하는 것이다 — 나에게 멘토링을 받는 팀이 있었다. 린스타업이라는 개념에 대해 얘기가 나왔는데 다음에 만날때 팀원들에게 자료를 준비해서 같이 얘기해보자고 제안했더니 a가 린을 발표하고, b가 스타트업을 발표했다. 아무도 린스타트업에 대해 공부를 하지 않았다. 적당히 단순하게 분업한것이다. 팀을 트리구조 혹은 Star 구조로 생각하는 사람들이 많다. 각자 할일 정하고 팀장과만 소통하는 식이다. 분업을 세분화하면 대화가 줄어든다. 잘하는 팀은 서로 참견을 많이 하더라는 연구결과가 있다. 분업을 분명히 하면 참견을 하기 힘들다.

질문

  • 멤버가 계속 바뀌는팀 — 연구결과로 보면 매우 불리하다. 더더욱 관계에 에너지를 써야. 리처드 행만이 얘기한 70–20–10 법칙 : 론칭전에 70%의 성과가 결정되고 20%가 론칭하면서, 나머지 10%가 On Going 시점에 결정된다. 어떻게 협력할지 팀을 구성하게 된는데, 그 구성에 따라 많은것이 결정된다는 말, 중간에 바꾸기 힘들다. 회의의 가치는 내가 모호할때 높다. 반대로 명확할때는 피드백 받을것이 적으므로 회의의 가치가 줄어든다.
  • 의견을 내는 개인이 항상 일을 너무 많이 하게된다 (그래서 의견 안내게 된다.) 어떻게 팀의 과업으로 가져갈 수 있나— 리더가 바뀌어야하는 문제이므로 간단하지는 않다. 팀원들의 안정감을 높이는걸로 출발해보자. 팀의 행복도가 높아지고 적극성/에너지가 생긴다. 사장님에게 압력을 행사하기에도 그럴때 잘 된다.

나의 회고

  • 팟캐스트도 운영한다고 해서 바로 구독!

전체회고

  • 이런 주제가 국내에서 흔치 않은데, 나름대로 갈증이 있어서 많은 분들이 오신것 같다. 개발 프로세스나 소통 등과 관련된 주제가 많이 다뤄졌으면 좋겠다.
  • 무료 강연에 비해 상대적으로 발표의 질이 좋았던것 같다.
  • 강연이 전체적으로 좋긴했지만, 굳이 가성비를 말하자면 강연의 질과 장소 등을 생각했을때 약간 비싸다는 느낌이 든다.
  • 주최측의 소개 등 예정에 없던 세션이 중간에 갑자기 진행되었는데 받아들이기 힘든 내용도 아닌데 아예 시간표에 넣고 공식 스케줄로 진행하는게 보기 좋았을듯.

이 글이 마음에 드셨다면 ☕ Buy me a coffee!

Witinweb

웹을 이해하고 웹에 wit를 불어넣는 놀이터

Jeong Woo Ahn

Written by

그림그리는 프로그래머 instagram@you_and_mydrawing | working at habitfactory.co

Witinweb

Witinweb

웹을 이해하고 웹에 wit를 불어넣는 놀이터