[개발세미나] 구름 11월 COMMIT <성장: 개발자들의 평생 과제> 행사 참여 후기, Done is better than Perfect

 

22년 11월 16일 수요일 7시, 구름에서 주최한, 11월 COMMIT 행사에 다녀왔다. COMMIT은 Communication, IT의 합성어로, 매 달 수요일 판교 구름스퀘어 공간에서 매달 수요일에 한번씩 진행되는 행사이다. 기술, 개발, 성장, 조직 문화 등에 대해 개발자 연사분들이 자신만의 이야기, 지식과 경험을 나누는 시간이다. 

11월 COMMIT은 구름에서 주최한 커밋 행사 중 두번째로 열린 행사였다. 아직 학생이라 이런 공개적인 라이브 행사에 참여를 해도 될까 고민을 많이 하며 신청을 했던 기억이 나는데, 마침 당첨이 되었다는 메일을 받 이런 좋은 기회를 놓칠 수 없다 하여 구름 스퀘어로 행복한 발걸음을 향했던 것 같다.

 

 

 

 

마침 COMMIT의 주제가 당근마켓에서 SRE 개발자로 일하고 계신 김승호님의 "성장: 개발자들의 평생 과제" 였다.

개발자를 준비하고 있는 학생으로서, 앞으로 개발 실력 뿐 아니라, 어떤 실력을 더 갖추어야 하는지, 어떻게 더 성장해 나갈 수 있을지에 대한 해답을 얻을 수 있으리라는 기대감으로 행사에 참여할 수 있었다. 

 

가장 기억에 남는 문구는 Done is better than Perfect. 구름 스퀘어 한쪽 벽면에도 쓰여져 있던 문구이다. 연사님께서도 중간에 강조했던 문구인데, 완벽을 좇다 보니 완성을 하지 못하는 아이러니함에 대한 해답을 얻었던 것 같다.

 

 

출처: 구름 블로그

 

---

 

아래부터는 구름 COMMIT 행사에 참여하며 정리한 글이다. 

두서 없이 개요식으로 작성한 것이며, 실제 내용과는 약간 상이할 수 있다는 점 참고해주세요!

(11월 COMMIT 행사 스케치는 구름 블로그 https://blog.goorm.io/commit_2nd_sketch/ 에 잘 정리되어 있다.)

 

---

 

 

연사님은 누구?

• 김승호(너굴) 연사님
  • 당근마켓 SRE 개발자
  • SRE란?: 클라우드 인프라를 잘 운영하기 위한 업무, 개발자들이 직접 인프라를 운영할 수 있게 플랫폼을 개발
  • 당근마켓에서 재직하기 아주 이전에는, 출판편집 분야에서 재직하셨다. (개발업무가 아니었음) 이곳에서 인사이트를 얻어 백엔드 개발자 커리어를 쌓게 되며, 전 회사에서는 CTO로 재직하셨음

 

업무 능력 - 우선순위

1) 우선순위 정하기

• 업무할 때 우선순위의 결정 기준이 필요한 상황이 생김
• heizener matrix
  • 중요성, 여유 있음 / 시급함, 사소함
• 결제 기능의 예
  • 가짜 응답 주는 api
  • 실제 api 로직 만들기 전에 api를 미리 만들어놓아서 프론트에게 전달해주면 프론트 입장에선 매우 편할 것
• 내 업무가 동료의 일을 막고 있다면 우선순위를 높여 보자

 

 

2) 우선순위 지키기

• “이거 하나만 해줄 수 있어요?” → 하던 일을 하다, 다른 일로 빠지며, 원래 하던 일로 돌아오지 못하게 되는 함정이 생김
• 개인 스크럼을 활용해보자!
  • 어떤 업무들이 치고 들어올 때 나중에 정리해놓으면 까먹지 않을 수 있음
• 오픈된 공간에서 공유할 수도 있음 (슬랙과 같은 채널에서 다같이 개인 스크럼을 공유하는 방법)
  • 모르는 지식을 새로 알 수도 있고, 지식을 알려주는 과정에서도 알고 있던 지식을 더 명확히 할 수도 있음
  • 팀 전체에도 지식이 퍼질 수 있는 효과
• 부작용도 있음 → 업무 보고가 되어버림.. 압박감이 될 때도 있음

 

3) 우선순위 조정하기

• 스타트업 공고 → 자기주도성이 있는 사람을 뽑으려고 함
• 회사의 장기적인 목표는? 시스템이 잘 갖춰진 회사의 목표. 목표를 팀원들에게 주기적으로 상기시키는 거시 중요
  • OKR
  • KPI
  • MBO
  • BSC
• 회사의 중단기 목표
  • 스크럼, 스프린트, 프로젝트, 마일스톤
  • 회사에서는, 중요하지 않은 일에만 집중하고 있는 경우 긍정적이지 않음
  • 소통하지 않아 생기는 문제들이 대부분이므로 꼭 물어보기!

 

---

 

개발 능력 - 호기심

• 호기심이란? 문제 해결 과정들이 업무가 끝날 때까지 업무를 잘 처리하고, 중간중간 발생했던 문제 상황들을 끝까지 깊이 들여다 봄.

호기심 자극하기

• 뉴스레터 → 구독해놓고 책임감을 갖고 보기
• 블로그, 유튜브 채널 운영 (개발바닥, 오늘코드, velopert, 44bits(김승호님 유튜브))
  • 유튜브는 수입과 연결되다 보니 자극적인 컨텐츠를 집중해서 만들게 될 수도 있다는 점을 염두해 두어야 함
• 커뮤니티, 개발 행사 (참석)
  • 기술 생태계에서 벌어지는 다양한 이야기들을 들을 수 있음
  • 도전을 먼저 해본 사람들이 시도해본 경험을 들어볼 수 있음
  • infcon, pycon, jsconf 등
  • `https://festa.io https://www.onoffmix.com https:/twitter.com
• 책, 강의 - 출판 쪽에서 일했다보니 전통적인 미디어에 관심이 많음
  • 함수형코딩, 알고리즘 문제해결 전략 등
• 스터디, 커뮤니티 (커뮤니티 운영, 발표 연사)
  • 책임감이 있는 상태로 몰아넣기..! 억지로라도 공부할 수 밖에 없는 환경을 만들어라
  • 홍대 django 스터디 → 출판편집 할 때 만났던 스터디
  • 스터디 운영 - 총무, 회계 등을 맡아서 몰아 넣으면 안 빠지게 됨
  • 커뮤니티 하다보면 이직으로도 이어지는 경우가 있음. 기술 수준(기술 면접)과 성향(컬쳐핏), 회사 내부 추천의 기회도 생김
• 사이드 프로젝트
  • 회사는 내가 좋아하는 기술을 쓰지 않는 경우도 있음
  • 22년 겨울 멋사에서 만든 내 트리를 꾸며줘 사이드 프로젝트 (엄청난 트래픽을 경험할 수 있는 좋은 기회)
• 개인/협력, 수동적/능동적

 

---

협업 능력 - 동료의식

1) 요청에 응답하기

• API의 성능 지표
• 응답 속도도, 일처리 자체도 중요함
• 주석으로, 알아봤던 내용들을 적어놓기, 참고문서, 마음속으로 생각했던 것을 간단한 메모로 정리해두자
• CTO는 “이거 한 번만 봐주세요…” 라는 요청이 정말 많음

 

2) Done is better than perfect

• 완벽하기보다 끝내는 것이 낫다.
• 마무리할 시점, 기준을 잘 파악하라
• 필요 없는 것을 쳐내는 능력
• 작업하다 배운 내용을 공유 slack에 공유하기!
  • 어떤 시도를 했는지, 실패했는지, 앞으로 어떻게 할지,, 다 적어보면
  • 다른 사람들이 도와주기도 함 👍🏻상황을 공유하며, 업무 보고를 자연스레 할 수도 있음

 

3) 기록하기

• 소스코드, 주석 외에 다른 기록
• 업무 습관 중 하나, 아침마다 업무를 기록하는 습관
  • 한 두달 쯤 지나서 그동안 한 일을 뒤돌아볼때 정리가 가능
  • 이직하는데도 매우 도움이 됨

 

4) 개발자는 코드로 말한다?

• 비즈니스 로직을 어딘가에 남겨두라.
  • 노션 등의 어딘가에는 적어둬야 함
• 회의록(결정과정 + 결정사항) 모두 기록하자
  • 왜 이 이야기를 하게 되었는지부터 상세하게 기록해보자. 
  • 당근마켓 - 문화정책, 서비스정책 등이 있는데, 회사 내에 점심값을 회사에 출근했을땐 지원해주는 정책을 왜 만들게 됐는지가 다 기록되어 있음
    • 문서를 통해 쉽게 문화를 받아들일 수 있음
    • 문화의 취지에 동기화할 수 있는 상황이 생김
• Tech Speck
• 소스 코드와 PR 본문, 커밋 메시지로 연결해줘야 함
• 구현과 근거가 명확히 드러나야 함
• 참조 링크들도 매우 중요

 

5) 동료 의식

• 동료 의식이란, 회사 안에서도 밖에서도 만난 사람들 모두 IT 업계라는 커다란 생태계 내에서 만나는 동료들
• 존중과 배려가 필요, 협업의 기본
• 예) OKKYCON 2017 “협업의 미신 5가지” → 근거 기반 협업으로 가기 위해

 

---

성장을 넘어 성숙으로

• 성숙한 개발자는 누굴까?
  1. 단언하지 않음
     1. 아는 것이 많으면서도, 모든 것을 다 알고 있지 않음을 알기 때문
     2. 상대를 존중하는 개발자
     3. 내가 언제든 틀릴 수 있다는 것을 인정하고 대화함
     4. 스스로 문제를 해결해나갈 수 있도록 도와주는 사람
  2. 우월감을 드러내지 않음
     1. 프로그래머들이 특히 자기 직군을 우아하게 생각하는 경우가 많은 것 같음
     2. 아이디어를 현실화할 수 있고, 사람들이 내가 만든 서비스를 사용하므로
     3. 내 분야가 얼마나 깊이있고 방대한지 안다면, 모든 전문 분야들이 다 그렇다는 것을 알 수 있음
     4. 개발직군이 아니여도 그사람만의 전문성을 인정하고 만난 기회를 감사하게 여김
  3. 유행을 좇지 않음
     1. 업계의 유행어, ajax, user generated content
     2. ddd, msa 등.. 용어가 중요한걸까? 용어는 현상을 분석해 이름을 붙인 것 뿐.
     3. 패턴도 마찬가지, 문제해결을 하다보니 반복되는 패턴에 이름을 붙인 것 뿐..!
     4. mbti 도 마찬가지
     5. 새로운 용어를 추종하진 말자..
  • 성숙한 사람이면 능력이 조금 부족해도 같이 일하고 싶더라 🙂

 

---

Q&A

Q. 스크럼 미팅이 업무 보고처럼 느껴진다면..

A. 굳이 해야 한다는 법은 없음. 스크럼 일지, 가벼운 메세지부터 던져보면 상호 작용이 되지 않을까

 

Q. 성장하고 있는지 어떻게 알 수 있을까요?

A. 과연 내가 같이 일하고 싶은 동료인지를 따져 보면 될듯

 

Q. 번아웃을 어떻게 대처하나요?

A. 번아웃 상태는 스스로 자각하기가 어려움. 휴가 기간까지 릴리즈를 걱정하고 있는 상황… 미친듯이 일하는것, 몰입은 좋고 그 과정을 통해 많이 성장하지만, 체력과 건강 상태를 잘 살펴보자

 

Q. 효율적인 스터디 방법

A. 익숙하지 않은 사람들도 함께 하는 것이 좋음. 지인 소개가 아닌 스터디인 경우가 더 좋을 수도. 책 한권 정해서 스터디 해보다가 아니면 다른 책으로 바꿔도 됨.

• 발제자, 발표자는 랜덤으로 뽑아 정하는 방법도 있음. 모두가 발표할 수 있는 환경이라면, 태만하지 않도록 하는 내용.
• 회비를 걷고 뒤풀이 하면서 다시 돌려주는 방법으로. 노쇼 방지 정책 세우기. 하지만 사실상 참여율의 변화는 크게 없었음. 얼마나 열의있는 사람들이 모였냐에 따라 달라짐. 열의 있는 사람들을 모으는게 중요

 

Q. 시니어와 주니어의 차이

A. 주니어일 때 같이 일했던 동료들은 시니어 연차였음. 코딩 능력 자체는 사람마다 속도가 모두 다름. 회사의 앞가림, 전체 동료의 앞가림까지 신경 쓴다면 시니어라고 할 수 있지 않을까.

 

Q. 효율적이고 질 높은 스터디 방식

A. 발제자, 발표자를 랜덤으로 뽑아 정함. 모두가 발표할 수 있는 환경이라면, 태만하지 않도록 하는 내용.

 

Q. 성숙한 코드리뷰 하는 법

A. PR은, 의견을 받는 요청을 하는 단계이므로 열려 있는 마음을 가져보자. 댓글은 최대한 배려하는 마음으로.

 

Q. 인턴 개발자에게 요구하는 역량은?

A. 면접관마다 입장이 다 다름. 어느 회사든 개발자다운 개발자를 원함. 서비스를 만들어본경험 , 사이드프로젝트 만들고 끝나는 것이 아니라, 운영을 해본 프로젝트 : 서비스를 사용하는 사람이 있는 것. 피드백을 받고 반영하면서 서비스를 개선해 나가고, 트래픽이 많이 몰려 인프라적인 지식을 쌓을 수 밖에 없는 그런 상황을 겪어본 사람. 학교 내에서 불만족스러운 부분들 (학교 식단 메뉴 앱 같은) 을 서비스로 만들어보는 경험

 

Q. 스크럼

A. 작은 스타트업일 수록 대표의 역량이 정말 중요. 업무 보고가 아니라, 왜 이런 일을 하려고 하는지 납득가도록 먼저 이야기할 수 있어야 함

 

 

Q. 워라밸이란..

A. 정시출근, 정시퇴근… 이라기보다는 업무가 비동기적으로 많이 바뀜. 재택을 하다보니 일과 삶의 경계가 많이 무너짐. 번아웃이 오지 않게 유지하는 것. 자신의 상태를 잘 점검하기!