Tech Company를 지향하는 오늘의집 개발 문화 #2
엔지니어링팀의 다양한 변화와 시도를 소개합니다.
2022년 11월 24일 Jinsik

Tech Company를 지향하는 오늘의집 개발 문화 Ver 2022_01(링크)에서 Engineering 팀이 어떻게 구성되어 있고, 어떻게 일하고 있는지 큰 틀의 관점에서  설명했다면, 이번 글에서는 문화에 대해서 조금 더 자세하게 소개하려고 합니다. 

20% Projects - Try new things

잉여력(Surplus)은 무한한 가능성을 만들어 냅니다. 잉여력을 통해 위기에 유연하게 대처하거나 새로운 시도를 할 수 있습니다. 이 새로운 시도를 통해 보다 커다란 성장도 가능합니다. 20% Project는 잉여력을 높이기 위해 시도하고 있는 Engineering팀의 문화입니다. 이 문화를 통해 개인 시간의 20% 정도를 배정해서 기존 맡은 업무 외에 다른 업무를 진행할 수 있도록 도와드리고 있습니다. 20% Project는 Engineering팀의 누구나 제안할 수 있으며, 이를 통해 다룰 수 있는 주제에는 한계가 없습니다. 새로운 기능, 생산성을 높일 수 있는 툴을 제작하는 것부터 비즈니스에 대한 아이디어까지 자유로운 아이디어가 모두 환영받습니다.

20% Project를 운영하려면 제안서를 작성하고, 해당 제안서를 기반으로 동참할 팀을 구성해야합니다. 공감대가 많이 형성될수록 이 과정은 빠르게 진행됩니다. 이 과정에서 참여하는 동료들의 리더에게 동의를 구하는 과정은 필요합니다.

Fix-it Week (No Meeting Week)

개발을 진행하다 보면 리소스가 부족하여 이른바 ‘기술 부채’가 쌓이기 마련입니다. Engineering 팀은 이런 기술 부채를 Backlog에 쌓아두고 기약없이 시간을 보내지 않습니다. 기술 부채는 프로덕트의 안정성을 해치고 생산성 악화로 이어지기 때문에 이를 집중적으로 해소하기 위해 분기에 한 번씩 Fix-It Week를 진행하고 있습니다.

Fix-it Week는 쌓여있는 기술 부채(테스트 코드 작성이나, 문서의 부재를 포함한), 버그 등을 해소하는 기간입니다. 이 기간에는 최대한의 결과를 만들기 위해 모든 노력을 집중하기 위해 별도의 회의를 잡지 않으며, Weekly, Monthly 등 주기적으로 진행하는 모든 회의는 취소 됩니다. 

Fix-It Week가 진행되는 동안 매일 한번씩 처리한 카드의 양을 공유합니다. 또, Fix-it week가 종료되면 많은 카드, 어려운 카드, 그리고 오래된 카드를 해결한 동료들에게 감사를 표현합니다. 

Engineering Awards 

오늘의집 Engineering팀은 업무의 중요도를 명확히 팀 내에 공유하고, 이를 탁월하게 수행한 동료들의 노력에 대해 감사를 표현하기 위해 ‘Engineering Awards’를 시작했습니다. 프로덕트의 탁월성을 위한 핵심 기능 개발, 장기 생산성 향상을 위한 기술 부채 제거, 시스템 성능 최적화 등의 관점에서 성과가 있을 경우 동료 또는 자신을 추천하게 되면 Awards 후보로 등록됩니다.

다음은 최근 수상 사례입니다. 

  • Ruby-Kotlin 언어간 호환성을 위한 구현을 통해 Legacy 처리를 통한 API 안정성 향상 
  • Frontend Architecture 표준화 진행 및 VAC 디자인 패턴 제안 및 PoC 적용
  • 광고 사업을 위한 MVP Requirements(데이터 파이프라인 및 정산 시스템)을 기간 내 구현
  • 커머스 플랫폼 오류 탐지 Rule을 정의하고 세팅하여 플랫폼 운영 안정성 향상
  • Source Code Management Group을 잘 Lead하여, Engineering 팀에 정책을 적용  
  • 오늘의집 Engineering팀이 바라는 Code Reviewer의 모습을 보여줌으로써 팀의 코드리뷰 문화 향상 

해당 문화에 대해 더 자세히 보기 원하신다면, 링크를 클릭해주세요 :) 



Commute Policy

“시간과 장소에 대한 비동기성은 우리의 팀웍과 생산성을 해치지 못한다”라는 신뢰하에 아래의 정책들을 실행하고 있습니다. 

주 3회 재택 - 팀별로 고정 출근 요일과 권장 출근 요일을 선정하여 출근 정책을 운영합니다. 업무에 몰입할 수 있는 환경이라면 물리적 위치는 크게 중요하지 않다는 판단에 따라 재택근무를 제도화했습니다. 또 사무실을 오가며 마주치는 동료들 사이의 교류 또한 중요하기 때문에 팀별로 출근 요일을 교차시키며 교류를 촉진하고 있습니다. 

하루 8시간 자율적 업무 - 06:00~22:00 사이에 집중과 몰입을 위해 업무 시간을 자율적으로 선택할 수 있습니다. 다만, 부재중과 방해금지 시간 등은 캘린더에 표기하여 동료와의 협업(미팅, 메시지 등)을 원활하게 합니다.  

✔ WFA - Work From Anywhere

매 반기마다 1개월씩(1년에 최대 2개월) 장소와 상관없이 근무할 수 있는 기간을 제공합니다. 우리는 시간과 장소의 제약을 넘어설 수 있다고 믿으며, 객관적이고 정량적인 결과로 우리의 노력과 생산성을 설명할 수 있는 프로페셔널 팀이며, 실제 많은 동료가 이를 증명하고 있습니다.

Communication and Sharing

명료한 커뮤니케이션 가이드와 자유로운 정보/지식 공유의 문화는 매우 중요합니다. Engineering 팀은 이런 문화를 위해 과거 Tech CoP를 진행해 왔습니다. 최근에는 All Hands라는 세션도 추가되었습니다. Tech CoP와 All-Hands의 내용은 녹화하여 해당 시간에 참여하지 못한 동료들에게도 언제든지 제공됩니다. 이제 각각이 어떤 주제를 논의하는지 설명하겠습니다 :) 

✔ All-Hands

오늘의집 Engineering팀은 지속적으로 성장해 나가고 있습니다. ‘우리가 바라는 Tech Company의 모습은 무엇이며, 현재 어느 단계까지 와있는가?’와 같은 방향에 대한 논의부터 팀 성장으로 인한 조직 구조의 변화나 새로운 제도의 도입이나 변경 등 팀 전체에 영향을 주는 사안들까지 동료들과 함께 나누기 위한 자리가 All- Hands입니다. 단순한 내용 공유에 그치지 않고, 질문을 주고 받으며 놓치고 있는 문제가 없는지, 더 좋은 방향은 무엇인지 모색하고 논의하는 자리입니다. All-Hands는 비정기적으로 진행되며, 대략 4~6주에 한번씩 열리고 있습니다.    

✔ Tech CoP

CoP(Community of Practice, 지식실행공동체(학습공동체))의 개념을 간단히 소개해보도록 하겠습니다. 실행(Practice)은 우리가 하는 활동들을 의미 있게 만드는 것을 의미하며 공동체(Community)는 함께 공유하고 발전한다는 의미를 내포하고 있습니다. 

오늘의집에서의 Tech CoP는 업무 과정에서 프로세스를 개선한 경험, 기술과 관련된 아이디어 등을 공유하며 함께 문제를 해결하고 팀의기술 역량을 높이는 문화로 발전하고 있습니다. 또한 이러한 활동을 통해서 동료 사이의 신뢰감과 네트워크를 만들 수 있다고 생각합니다. 각 도메인(Backend, Frontend, … 등)내에서 작은 CoP를 매주 진행하며, Engineering 전체 팀에 공유하고자 하는 내용은 Tech CoP 주제로 등록해, Engineering팀 전체가 참여하는 Tech CoP를 통해 소개하고 있습니다. 미래에는 오늘의집 외부의 엔지니어 커뮤니티도 초대하는 공개 Tech CoP도 열어볼 계획입니다.

Tech CoP는 주제 제한은 없으나 아래의 주제들을 주로 다루고 있습니다.

  • 새로운 기술에 대한 PoC 결과 공유 및 도입 논의 
  • 문제 해결을 위한 최적의 해결책 도출 경험
  • 경험을 통해 배운(과거 경험) 지식 공유
  • 함께 보고 싶은 기술 아티클 공유
  • 업무 효율성을 향상 시키기 위한 방법론 논의 및 도입 결정
  • 새로운 문화에 대한 안내 및 논의

✔ Communication Tools

면접 과정에서 많이 나오는 질문중 하나가 “Communication Tools을 어떤 것을 사용하는가? 또 문화는 어떻게 되나요?” 입니다. 간단히 사용하고 있는 툴에 대해 나열해드립니다. 

  • Google workspace

    • Google Groups
    • Google Calendar
    • Google Mail (Gmail)
    • Google Docs / Sheets / Slides
    • Google Meet
  • Slack/Google Chat (Slack 장애시 사용)

  • Notion

Slack vs Mail

Slack으로 요청한다는 것은 상대방 입장에서는 Interrupt를 당하는 것이고, 빈번한 메시지는 업무 집중을 방해할 수 있습니다. 반면 Mail은 요청받는 사람이 원하는 시간에 확인이 가능합니다. 또한, 휘발성 정보인가 아닌가에 대한 판단을 통해 Mail을 이용할지 채팅을 이용할지 정하게 됩니다. 기본 커뮤니케이션은 Mail로 진행하되, 빠른 결정 및 소통이 필요한 경우 Slack으로 메시지를 보내는 것을 권장합니다. 

Notion vs Google Docs/Sheets/Slides

문서 작성의 권장 사항은 Google 문서도구를 사용하는 것입니다. 커뮤니케이션이 필요하고 변경 가능성이 높은 문서는 Google 문서도구를 이용해 작성합니다. 반대로 Guide 형태로 고정된 문서의 경우 Notion에 남기고 있습니다. 또한, Google Drive에서 문서 탐색의 단점을 보안하기 위해 Notion에 구조화하고 링크를 남기고 있습니다.  

더 나은 문화를 위해서

지난번 글과 비슷한 마무리를 하려고 합니다. 이 글에 적혀있는 것이 오늘의집 개발 문화의 전부는 아닙니다. 문화는 누군가 정한다고 생겨나는 것이 아니라 구성원 모두가 자연스럽게 그 속에 젖어들 때 비로소 문화가 되었다고 할 수 있습니다. 또한 우리는 더 좋은 문화를  위해 서로 회고하고 피드백을 주고 받으며, 자유롭게 새로운 제안을 하고 논의합니다. 이것이 오늘의집 Engineering팀을 최고의 개발 문화를 가진 Tech 기반 회사로 성장할 수 있게 도와줄 것입니다. 이 여정에 동참하실 여러분을 기다리고 있습니다.

오늘의집에서 당신을 찾고 있습니다!
Senior Software Engineer, BackendSoftware Engineer, BackendSenior Software Engineer, Backend, AdsSenior Software Engineer, FrontendSoftware Engineer, FrontendSenior Software Engineer, AndroidSoftware Engineer, AndroidSenior Software Engineer, iOSSoftware Engineer, iOSSenior Software Engineer, DataSoftware Engineer, DataSenior Software Engineer, Machine LearningSoftware Engineer, Machine LearningSenior Software Engineer, Machine Learning, Extended RealitySoftware Engineer, Machine Learning, Extended RealitySenior Software Engineer, Extended RealitySoftware Engineer, Extended RealitySenior DevOps EngineerTechnical Lead & Manager, BackendTechnical Lead & Manager, Backend, AdsTechnical Lead & Manager, FrontendTechnical Lead & Manager, iOSSenior Technical Program ManagerSoftware Engineer (전문연구요원)
목록으로 돌아가기