[Review] JetBrain Seoul, 2018 - 1 - 기초 연설 - Keynotes


Image Failed to Load

1. 기초 연설 - Keynotes

Keynote #1 - Alexey Reshtenko, JetBrains Sales VP:

오전 세션의 첫번째 Keynote로 JetBrains의 Sales VP, Alexey Reshtenko님이 발표를 시작했다.

주로 회사에 대한 소개가 주를 이루었는데, JetBrains라는 회사는 2000년도에 체코에서 3명의 개발자와 시작했다.

Sergey, Valentin, 그리고 Eugene이라는 개발자이다.

시작을 3명의 개발자와 해서 그런지는 몰라도 현재의 리더십 팀 대부분은 개발자로 구성되어 있다고 한다.

이 점이 조금 색다르게 다가왔는데 큰 회사를 운영함에 있어 개발자를 비롯하여 다양한 분야의 사람들이 있어야 한다고 생각했는데, 대부분이 개발자라고 하니 정말 기술 기반의 회사라고 생각되었다.

더불어, 필요한 기술을 사내에서 직접 개발하여 활용하기 때문에 타 사와의 Dependency가 낮다는 점을 부각하였다.

이 점 역시 기술 기반 회사인 점을 강조하였다.

Keynote #2 - 이승현, 단군소프트 대표:

두번째 Keynote는 한국인분이 발표를 해주셨는데 단군소프트 대표님이신 이승현 대표님이 발표를 해주셨다.

본 행사에 대한 소개와 개발자가 갖추어야 할 마인드에 대해서 말씀해주셨다.

본 행사의 경우, 올해를 포함하여 3년째 진행중이며 올해 행사 모토는 “개발의 원동력“이란 주제로 다양한 연설자 분들이 발표를 해주실 계획이라고 하셨다.

더불어, 개발자는 새롭게, 빠르게 변화하는 환경에 잘 적응해야 한다고 강조해주시면서 찰스 다윈이 이야기 했던 명언을 알려주셨다.

결국 살아남는 종은 가장 강한 종도, 가장 지적인 종도 아닌, 변화에 가장 유연하게 적응하는 종이다 - 찰스 다윈, <종의 기원="">

Keynote #3 - Hadi Hariri, JetBrains Developer Advocacy team - 개발자의 생산성을 높이기 위한 장벽 제거, Removing Barriers:

세번째 Keynote는 JetBrains의 개발 옹호 팀의 Hadi Hariri 님이 발표를 해주셨다.

주로 JetBrains라는 회사가 가지고 있는 문화와 타 IT회사와의 문화를 비교하는 내용이었는데, 쿠팡과 비슷하다고 생각이 되었다.

JetBrains에 대한 간단한 소개:

먼저, JetBrains에 대한 간단한 소개로 시작했다.

  • 3명의 개발자로 2000년도에 시작함 - 현재는 1000명이상
  • 어떠한 문제를 해결하기 위해 기술/툴을 직접 개발하여 활용함

수평적인 조직 구조:

조직 구조의 경우, 수평적인 문화를 지지하며 최소한의 수직적 직급이 존재한다고 했다.

3개 ~ 4개 정도의 직급 레벨이 존재하며 본인의 직급, 직무와는 상관없이 모든 구성원이 의견을 충분히 낼 수 있다고 했다.

(과연 실제로 잘 될지는 의문이지만…)

자요로운 업무 방식:

업무는 의미가 있는(Value가 있는) 무엇이든(Whatever) 어디서든(Wherever) 언제든(Whenever) 수행할 수 있다고 했다.

자유롭게 일을 하는 대신 본인이 맡은 임무는 꼭 수행 완료해야 한다고 했으며 (Get it Done!) 팀원간의 믿음이 존재해야 해당 방법처럼 업무 수행이 가능하다고 했다.

제약 사항:

몇 가지 제약 사항이 존재하는데 미팅은 온라인이든 오프라인이든 꼭 참여 해야 한다고 했다.

좋은 미팅과 나쁜 미팅의 차이는 몇 가지가 있는데 아래와 같은 부분으로 확인해볼 수 있다.

  • 미팅에서 논의 해야 할 Action Item이 사전에 정리되어 있는가?
  • 본인의 업무 경과에 대한 공유인가? 프로젝트 내용 논의를 위한 미팅인가? 확실히 구분해야 한다.

또 다른 제약 사항은 (재미있었던 부분이기도 한 부분은) 뮌헨에서 업무를 한다면 일요일에는 법적으로 출근을 금지한다는 것이다. (오피스가 아예 잠겨버린다고…)

팀원간 소통 방식:

1000명 가까운 직원들이 업무를 하다보니 서로간 커뮤니케이션 비용이 높아졌다.

Email, Slack, Issue Tracker 등 다양한 커뮤니케이션 툴을 목적에 맞게 효율적으로 활용해야 한다고 했다.

  • Emails - keep it to minimum
    • 타 툴에 비해 Follow-up이 잘 안되어 비효율적이기 때문에 최소한으로 활용하는 것을 추천함
  • Slack - use it only for urgent issues
    • Direct message를 보낸다는 것은 급한 이슈에만 해당되는 것으로 정말 필요할때만 Slack을 활용함
  • Issue Tracker - use it for not only development, but also for others as well
    • 개발에만 한정된 것이 아니라 타 업무도 모두 Issue Tracker로 관리함
  • Confluence - But how do people know? It’s like a blackhole. Write so many things, but no one knows
    • 효과적인 소통을 위해 내부 뉴스 공유와 내부 컨퍼런스를 진행함

직원 관리 측면:

아래 직원들을 효과적으로 관리하기 위해서는 아래와 같이 한다고 했다.

  • No micro-management
  • No micro-reporting
  • No permissions required (대학원때를 생각하면… 3가지를 모두 못하고 있다는 생각이…)

기타 - 좋은 말씀:

  • Know how to control your passion
    • Too much passion - Push you away from what’s needed for responsible
  • Do something that adds values to company, team, yourself
  • Freedom is only available when there is trust
  • What is leadership?
    • Not being a bottleneck
    • Learning to delegate
    • Providing guidance - Let me help you
  • Being candid
  • Knowing how to listen and be heard
    • You can hear, but don’t listen
  • Most of all - trusting and caring
  • Culture is important
    • When working with people from different cultures, we might have cultural misunderstandings
  • Be the change. Don’t sit back and expect it
  • Protect the culture, but be open to change
  • Trust in people. Care for people. We will do our best.

Keynote #4 - 안영회, 베터코드주식회사 대표이사 - 소프트웨어를 모르는 대학민국 기업의 위기:

네번째 Keynote로 안영회 베터코드주식회사 대표이사님께서 발표를 해주셨는데.. 무슨 말씀을 하려는지는 파악이 되는데 너무 내용이 중구난방이라는 생각이 들었다..

들은 것 몇가지만 정리해보려고 한다.

GitHub & Microsoft

2018년 6월, 마이크로소프트가 오픈소스 공유 플랫폼 깃허브를 인수하였다.

기존에 오픈소스가 중요하다고 생각하지 않았던 마이크로소프트 사가 오픈소스 플랫폼을 인수하였다는 점은 오픈소스에 대한 중요성을 나타낸다.

인수할 당시 GitHub의 가치는 8조에 육박했으며 이는 Homeplus와 Nokia와의 기업 가치와 비슷하다.

관련 링크:

  • Developers, Developers, Developers - Microsoft/GitHub and The Ascendancy of Code
    • https://bit.ly/2JwrGbb
  • MS, 오픈소스 공유 플랫폼 ‘깃허브’ 인수한다
    • https://bit.ly/2TJSaMc

주 52시간 - 소프트웨어의 가치를 근로자의 노동 시간으로 측정할 것인가?

대표이사님이 말씀하시길 개발하는 시간과 소프트웨어의 품질과는 상관이 없다고 한다.

이 부분에 대해서는 동의하는 바이다.

기획자 또는 사용자 입장에서 화면에서 작은 부분이 바뀌었다고 뒤의 로직 부분이 간단하다는 것은 아니다.

따라서 소프트웨어에서 UI는 빙산의 일각일 뿐이다.

이런 부분에 있어서 개발자와 기획자 간의 서로간 소통이 매우 중요한데, 서로간 Delegation과 Collaboration이 중요한다고 한다.




© 2018. by kdohyeon

Powered by kdohyeon