엔지니어링 그룹의 커뮤니케이션 방식, 그리고 그룹 내에서는 어떤 주제로 미팅/토의가 이루어지는지를 소개합니다
•
오픈 커뮤니케이션 지향
◦
레몬베이스 팀은 팀 내에서 어떤 일이 진행되고 있는 지 쉽게 파악하고 함께 해결책을 모색하는 것이 가능한 오픈 커뮤니케이션을 지향합니다. 따라서 불가피한 경우를 제외하고는 DM이 아닌 public channel에서 소통하고 있어요.
•
미팅 문화
◦
어젠다 단위로 아래 내용을 기재해요. 이는 미팅이 불필요하게 발산적으로 진행되거나 길어지는 것을 방지하는 데 큰 도움이 되며, 효율적인 시간 사용을 중요하게 생각하는 레몬베이스 팀의 가치에 잘 부합하는 사례입니다.
▪
오너
▪
유형
▪
목표 소요 시간
•
챕터 미팅
◦
백엔드/프론트엔드 챕터 단위로 매주 1회씩 모여 아래와 같은 어젠다를 다룹니다.
▪
지난 일주일 간 기술적으로 고민한 것 + 배운 것 + 진행 중인 업무 공유
•
각자의 스쿼드에 속해 있다 보면 기술적인 측면에서도 사일로가 발생할 수 있습니다. 다른 동료가 어떤 일을 하고 어떤 고민을 하고 있는지 알기 어렵고, 도움을 주거나 지식이 흐르는 것을 방해합니다.
•
이런 문제를 해소하기 위해 미팅의 고정 어젠다로 위 내용을 짧게 공유하는 시간을 갖고 있어요. 실제로 거의 매주 다른 엔지니어의 도움을 받아 빠르게 문제를 해결하기도 하고, 새로운 지식이 전파되고 있습니다.
▪
챕터 내 어젠다
•
업무 프로세스나 문화, 채용, 개발 가이드 등 챕터 내에서 생각할 수 있는 모든 종류의 어젠다를 다뤄요.
▪
제안과 결정
•
챕터가 일하는 방식에 큰 영향을 주거나 논의 사항이 많은 제안일 경우 아래 양식에 맞게 작성된 문서를 공유하고, 이 문서를 기반으로 논의 및 의사 결정을 하고 있습니다.
◦
해결하려는 문제
▪
대부분의 제안에는 해결하려는 문제가 있습니다. XY Problem에 빠지지 않고, 제안된 것보다 더 나은 해결책을 제시할 수 있도록 ‘해결하려는 문제’를 명확히 적는 것에서 시작합니다.
◦
제안 설명
▪
문제를 어떻게 해결할 것을 제안하는지 설명을 적습니다.
◦
예상 임팩트
▪
이 제안을 받아들였을 때 예상되는 긍정적/부정적 임팩트를 서술해 다른 엔지니어들이 제안에 대해 더 충분히 이해하도록 돕습니다.
◦
예상 장애물
▪
이 제안을 우리 팀에 적용할 수 없게 된다면, 어떤 이유인지에 대해 서술합니다. 이는 이 제안을 받아들였을 때 수반되는 작업들의 크기가 어느 정도인지를 이해하는데 도움이 되어요.
◦
할 일
▪
실제로 이 제안을 받아들였을 때 해야 하는 일을 적습니다. 제안이 큰 수정 없이 받아들여진다면, 적혀 있는 일들에 대해 오너십을 나눠갖는 것으로 제안 검토를 마칩니다
▪
쉐어링
•
기술적인 내용이라면 무엇이든 공유할 수 있어요. 실제 미팅 내에서 쉐어링된 내용을 공유해보자면 이렇습니다.
(1) 최근 발생한 엑셀 파일 다운로드 시 성능 문제를 해결한 과정과 필요했던 지식 (APM 활용 + DB 설정값에 대한 이해)
(2) Python 퍼포먼스 최적화 시 고려할 만한 요소 - list와 set의 in 연산 차이
(3) Django의 모델이 생성되는 과정 살펴보기
(4) Python의 mutable value 처리 방식에 대한 이해
(5) DDD의 Bounded Context 적용해보기
(6) 해외 사용자 지원을 위한 - 크롬 브라우저에서 타임존 쉽게 바꾸기
(7) VSCode 유저를 위한 코드 스펠 체커 익스텐션
(8) SVG Data-url with SVGR
(9) 인터널 도구 빌딩을 위한 Refine 프레임워크
(10) 리액트 톺아보기 소개
(11) 큰 or 복잡한 단위의 PR을 작은 단위의 PR로 나눠 리뷰 요청한 사례 공유
(12) Developer Imposter Syndrome
(13) 정지 문제 (Halting Problem)
(14) AWS Neptune(Graph DB) 소개
(15) Google Apps Script와 Slack 연동을 통한 운동 기록 자동화
(16) Teachable Machine을 이용한 머신러닝 모델 만들기
Last updated: 2024-07-26
Lemonbase Corp.