구글 스타트업 캠퍼스 지하 2층
2023.12.02 14:00 ~ 17:00
https://festa.io/events/4330

📍 참가배경

줄곧 오프라인 개발 행사에 참여해보고 싶었다. 그러다 오픈채팅방에서 행사 내용을 보았고 바로 신청!

연사와 주제는 아래와 같았다

귀여운 붕어빵과 손난로를 받았다 ⛄️
찰보리빵이 이렇게 맛있는 거였나요

정말 재밌게 들었기에 그 내용을 정리해본다
다만 인상 깊었던 내용만 적었고, 전체 내용을 요약하고 정리한 것은 아니다

---

📍 강연 내용 정리

1.소프트웨어 개발자들의 몰입과 번아웃을 좌우하는 것은 무엇일까?

1.1 번아웃이 오는 과정

• 좌절되는 경험이 반복되면 무뎌지고 번아웃을 경험
• 모든 직장인들은 몰입과 번아웃의 경계에 있는 것이 아닐까

1.2 소프트웨어 개발자를 몰입하게 vs 번아웃오게 하는 것들

- 개인 차원의 욕구 : 성장 지향성, 내향성, 일의 가치추구
- 직무 치원의 욕구 : 자율성, 다양성, 시장성, 창의성&도전성, 기술적 유능성, 기술 수준에 대한 만족감 추구
- 조직 차원의 욕구 : 개인의 목표 설정 참여, 피드백 추구, 승진/임금/고용 안정성, 직장동료와의 관계와 지지

• 위와 같은 것들이 유지될 때 개발자들은 잘 몰입하고, 유지되지 않는다면 번아웃이 올 가능성이 높다. 그러니 이를 잘 지원해줄 수 있는 환경이나 리더를 찾는 것이 베스트

1.3 번아웃의 예방 & 극복

- 내가 '어려워 하는' 환경에 오래 노출되지 않기
- 규칙적인 생활
- 일상의 20%를 나에게 집중
- 심리상담과 병원 등 해결을 위한 구체적인 행동
- 이직은 답일 수도 아닐수도 있음

• 회사에서 열심히 일하는 걸 당연하게 생각하다보면 번아웃이 쉽게 올 수 있음.
• 평생동안 평균적으로 겪는 번아웃의 횟수는 평균 10회
• 이직은 이혼과 맞먹는 스트레스일 수 있다고 함
• 긍정적인 방향으로 끌고가지 못한다는 생각이들면 잠시 쉬었다가 가는 것을 추천

1.4 Q&A

• 번아웃이 온 것 같은 직장동료에게 해줄 수 있는 것은?
  • 긍정적인 피드백과 단어를 많이 얘기해주기
  • 푸바오 할부지가 푸바오를 대하듯 눈맞추면서, 지지를 보내고, 신뢰를 쌓을 수 있도록 하면 모두가 행복해질 수 있음.

2.코드리뷰 문화를 리뷰해 봐요

2.1 코드리뷰란

• bus factor : 구성원 중의 일부가 불미스러운 사고로 갑자기 사라졌을때 프로젝트가 위험에 빠질 정도를 인원수로 측정하는 것. 코드리뷰를 통해 bus factor의 수를 높일 수 있음. 코드리뷰를 통해 어떤 변경사항과 어떤 요구사항에 의해 나오게 됐는지 함께 공유하게됨.
• 고수준의 코드리뷰 : 직접적으로 프로덕트에 문제가 생길 수 있는 포인트(버그/성능저하/장애/보안) 해결
• 저수준의 코드리뷰 : 더 나은 프로덕트를 위한 개선 포인트(코드 컨밴션, 복잡도 개선, 아키텍쳐 개선, 주석개선) 해결
• 팀 바이 팀의 코드리뷰문화가 존재하며, 가장 중요한 건 구성원의 수준이나 일정등 팀의 컨디션을 파악하고 팀의 공감을 얻고 시작하는게 가장 중요함.
  

2.2 우리에게 다가온 변화의 필요성

• 원인 : 요구사항 이해 병목, 사이즈가 큰 pr, 후순위로 밀리는 review
  • assignee는 이미 기획단계부터 요구사항과 도메인지식을 갖고 있는데, 리뷰어는 그렇지 못하기 때문에 더 많은 에너지가 소요됨
  • 코드를 크게 올리는게 문제. 1시간에 코드리뷰를 하려면 200 line 이내가 되어야 가능하다는 연구 결과가 있음
  • 최소 한명이상의 approve가 있어야하는 branch 전략. 점점 pr 이 쌓이고, 비즈니스 프로덕트에서도 병목 발생
• 문제 : 이로인한 심리적 압박감 증가

2.3 작게, 밀도있게, 빠르게

• pr templete 변경(process적인 변화)
  • 리뷰어가 시간을 내서 리뷰해주는 만큼, 작성자는 리뷰어에게 무조건적인 배려와 노력을 해야함.
  • 작성자는 라벨을 붙이고, 리뷰어는 우선순위 prefix를 붙임
• d-day label의 자동화
  • pygithub 사용, github action으로 열려있는 pr만 모아서 slack api를 사용함.
• 아침 1시간, 퇴근 전 1시간에는 같이 pr하는 시간을 가짐.

김테디의 기술 블로그(blog.teddy-kim.com)

코드리뷰에 대해 심도있게 고민해본 적은 없지만, 코드리뷰문화에는 관심이 많다. bus factor 용어를 처음 알게 됐는데 이 용어로 코드리뷰의 필요성이 확 와닿았으며, 코드리뷰의 고수준과 저수준 부분을 들으며 시도해보고 싶은 게 생겼다. 중요한 건 팀원들의 심리적 압박감을 낮추고 작성자와 리뷰어 모두 배려하는 마음을 가지는 것이라는 걸 마음에 새기며 들었다.

3.너와 나의 차이는 어디에서 오는가

3.1 시간을 제어하는 차이

• 가용시간 파악, 우선순위 파악, 몰입할 수 있는 환경조성
• 급하지만 중요하지 않은 일들은 다같이 따로 시간을 할애해서 처리하는 시간을 별도로 마련하기

3.2 정보를 관리하는 차이

• 이해해서 업무를 하는건지, 이해한다고 생각만하고 업무를 하는건지에 따라 업무 퍼포먼스 차이가 많이남.
• 공부한 것들을 기록하는 방식이 과거엔 노트 또는 블로그였음. 요즘엔 Roam Research 또는 Obsidian
• 정리방법인 PARA기법(Project, Area, Resource, Archive)

4.질문도 마케팅이 필요하다

4.1 티키타카의 시작

답변하기 애매한 질문을 받고, 무슨 예제냐고 물었을 때

• 좋지 않은 티키타카 : (최악)갖고 있는 책의 예제 2-1이라고 하거나, (차악)두 변수의 곱을 출력하는 예제라고 답한다.
• 평범한 티키타카 : (평범)코드를 보여준다.
• 좋은 티키타카 : (차선)코드와 함께 의도, 문제점을 말해준다. (최선) 차선에 더해 문제점을 해결하기 위해 시도한 것들을 말해준다.
• 좋은 질문은 불필요한 커뮤니케이션 발생 예방한다.
  • 처음부터 무엇을 하려고 하는지, 현재 문제점은 무엇이며, 어떤 시도를 해봤는지 코드와 함께 질문한다. 실제 재현 가능한 환경이나 정보가 있다면 금상첨화. 에러메시지도!

답변하기 싫은, 또는 하고 싶은 질문

• 답변하기 싫은 질문 : 앞서 말한 좋지 않은 예, 코드만 덩그러니 보여주며 안된다고 하는 질문, 코드를 폰으로 찍어서 주는 이미지, 오탈자가 많은 질문
• 답변하고 싶은 질문 : 일하기 싫은데 마침 시간도 많을 때 우연히 본 질문, 내가 아는 내용, 내가 겪었던 고통의 데자뷰를 느낄 때, 절실함과 그로 인해 자연스럽게 드러나는 성의가 가득한 질문

4.2 좋은 질문

좋은 질문을 하는 방법

• 답변이 가능할 것 같은 곳에 물어보기
  • 답변을 받는 것이 목표! 답변을 하고 싶도록 해야 성공적인 질문
• 10분 밖에 질문 안 해봤을 것 같은데?라는 질문은 지양
  • 좀더 많은 고민을 해보자
• 성의를 보이자
  • 하지만 성의만 있고 핵심이 없으면, 성의가 있다고 할 수 없음.

좋은 질문의 중요성

• 질문하는 것을 보면 그 사람의 평소 태도, 성장 가능성 여부를 알 수 있음

4.3 답변은 의무가 아니라 배려

• 하지 않아야할 것 : 당연한 듯 답변 요구, 비아냥, 상대방이 다 알고 있을거라고 생각
• 해야할 것 : 미안함과 감사함 전달, 해결법 링크 받으면 난 왜 못 찾았는지 생각해

4.4 Q&A

• 대답하기 싫은 질문을 받을 땐 어떻게 해야하는지?
  • 질문 잘하는 방법에 대한 링크 제공하고 고민해보라고 한 적도 있고, 질문 양식을 만든 적도 있음.
  • 또는 질문룰 정하기. 문제가 있으면 솔직히 회고시간을 가져서, 감정이 안 상하는 선에서 가슴속에있는 말들을 공유함.
  • '쉬운 것 같지만'이라는 수식어는 안 붙이기. 바보 같은 질문하기가 룰로 있음. 뉴비 환영
• 같은 질문을 여러번 반복하는 걸 최악의 질문이라고 생각함. 오프라인에서는 꽤나 빈번한 것 같음. 어떻게 대처함?
  • 나중에 또 물어볼 수도 있다고 밑밥깔기. 메모를 하지만 속기하다보니 누락되는 것이 있어 또 질문함.
  • 서로 같이 메모하며 질의응답을 주고 받기도 하고, '누락된게 있거나 모르는게 있다면 다시 답변주세요.' 라고 말함
• 질문할 때 양이 많은 적이 있었음. 적절한 질문의 양은?
  • 개인적으로는 최대한 많은 설명이 좋음.
  • 간결하지 않은 문장과 장황하게 표현했다면, 글은 잘 못쓰지만 절실함이 느껴짐. 양식을 정하면 좋을 듯

내가 질문을 올렸을 때, 한번에 상대방이 내 상황을 이해하고 답변해줬으면 한다. 그래서 최선을 다해 질문을 작성하지만, 늘 뭔가 아쉽다는 느낌적인 느낌. 근데 그 느낌이 뭔지, 더 신경써야할 부분이 뭔지 알게됐다. 정말 재밌고 유익했다. 깔끔한 발표를 보며 발표는 이렇게 하는 거구나하며 배웠다.

📍 후기

번아웃, 코드리뷰, 자원 관리, 질문하는 법 네가지 주제 모두 지금의 나에게 딱 필요한 이야기였는지, 자꾸 내용을 곱씹게 된다.

온라인에서 주로 지식을 얻기 편하고, 오프라인에서는 주로 인사이트를 얻기 좋다. 관심있는 주제가 있다면 망설이지 말고 참여해서, 지속가능한 개발 생활에 기여해야지

중간에 fun activity 했는데, 퀴즈 못 맞춘거 아쉽다. 그리고 생각보다 퀴즈가 재밌었다. 강연도 정말 좋았고! GDC 에서 하는 것에 좀더 흥미가 생겼다.