안녕하세요, 오늘의집 진식입니다.
오늘의집 Engineering팀은 No.1 Lifestyle Tech Company라는 비전을 위해 달려가고 있습니다. 이를 위해 엔지니어가 가장 존경받는 회사가 되기 위해 문화를 세우고 발전시키고 있습니다.

2021년 3월 발행한 글, Tech Company를 지향하는 오늘의집 개발 문화(링크)에 “구성원 개개인이 문화를 유지하고, 발전시키기 위해 노력한다”고 언급했듯이 오늘의집 개발 문화도 변화하고 있습니다. 과거 글에 이어 어떤 것들이 변화하고 새롭게 시도되고 있는지 이야기드리고자 합니다. 참고로 내용이 길어 2개의 글로 분리하였습니다.

Introduction

오늘의집 Engineering팀의 구조는 지난 글을 썼던 시점에 비해 변화가 있었습니다. 큰 틀에서 ‘서비스를 직접적으로 개발하는 팀’과 ‘서비스를 지탱하는 팀’으로 구분됩니다. 이후, ‘엔지니어가 보다 더 개발에 집중할 수 있는 구조가 무엇일까? 팀이 지속적으로 성장하기 위한 방향은 무엇일까?’라는 고민 속에서 변화가 발생하였습니다.

일단, 서비스 팀의 구조를 먼저 살펴보도록 하죠.

도메인(Backend, Frontend, iOS … 등) 별로 팀을 구성하며, 각 팀의 상황과 목적에 따라 팀을 구성해 나갑니다. 예를 들어, 엔지니어가 아직 소수인 모바일 도메인의 경우 Android, iOS로 각각 하나의 팀으로 구성했습니다. 반면, 가장 많은 엔지니어가 있는 Backend 도메인의 경우는 Commerce Platform, Commerce Service, Commerce Catalog, Content Platform, … 등 목적에 따라 팀을 세분화했습니다.

다른 한편으로 비즈니스의 특성이나 목적에 의해 도메인 별로 소수 인원이 모여 팀 자체가 독립적인 완결성을 가지고 움직이기도 합니다. ‘스타트업 내의 스타트업’의 느낌으로 목표를 달성하기 위해 빠른 속도로 제품을 만들고, 결과 기반으로 다음 업무를 하고 있는 팀들입니다. 예를 들어, 올해 막 오픈한 Global O!House를 위해 Backend, iOS 엔지니어가 함께 모여 빠르게 의사결정하고 개발하는 업무를 진행하고 있습니다.

서비스를 지탱하는 팀들은 어떤 팀들이 있는지 살펴보도록 하죠. Core Platform, DevOps, Data & Discovery, Ads, Service Components, XR(eXtended Reality), TPM, QA 등의 팀이 있으며, 각각 서비스에 필요한 요소들을 개발하고 전체 서비스의 관리 및 검증을 지원하고 있습니다.

구체적으로 어떤 팀들이 있고 어떤 역할을 하고 있는지는 다음의 팀 소개 페이지(링크)를 통해 확인해주세요 :) 그 밖에 일시적으로 발생하는 프로젝트의 경우도 있는데, 이에 대한 자세한 내용은 다음 글에 작성되어 있는 20% Project를 참조해주시면 감사하겠습니다.

Idea to Release

오늘의집에서 아이디어의 우선순위를 어떻게 정하며, 엔지니어 입장에서 서비스를 랜딩할 때까지 어떤 과정이 진행되는지 살펴보겠습니다.

✔ Quarterly Plan

우선 Quarterly Plan을 통해 프로덕트에 대한 다양한 아이디어, 비즈니스 요구사항, 진행해야하는 기술 프로젝트 등을 한 자리에 두고 논의를 진행합니다. 오늘의집에서는 Bottom Up으로 제안되는 아이디어를 중요하게 생각합니다. 물론 회사 전체가 중요하게 바라보는 프로젝트를 진행하는 경우도 있습니다.

이렇게 각자 제안한 아이디어와비즈니스 요구사항이 나열되면 각 항목에 대해 '왜' 해야 하는지 데이터를 기반으로 점검합니다. 실제 서비스가 만들어졌을 때 어떤 데이터가 움직일 것 같은지 예측합니다. 또 이 변화가 어떤 데이터에 영향을 주는지, 전사 지표에는 어떤 영향을 미칠지까지 고려하여 Impact를 산출하게 됩니다.

이 과정에서 PO와 아이디어 제안자간 많은 소통을 하게 되며, 엔지니어의 피드백도 녹아들게 됩니다. 예전에는 우선순위를 정할 때 ICE(Impact, Confidence, Ease) Score를 사용했지만, 현재는 RICE(Reach, Impact, Confidence, Effort) Score를 쓰고 있습니다. 기존 ICE Score에 ‘얼마 만큼의 사용자에게 영향을 주는가’라는 요소가 추가된 우선순위 기법입니다. 엔지니어가 예상하는 러프한 일정기준으로 Effort 값이 산정되며, 최종 우선순위가 나오게 됩니다.

기술 프로젝트의 우선 순위를 정할 때에는 프로덕트 로드맵과의 연관성을 살펴봅니다. 각 요소별 예측한 잠재적 기술 문제들을 프로젝트 단위로 구분한 후 프로덕트 로드맵과 연관성 높은 것을 우선시 진행하게 됩니다. 이 과정에서 간단한 Refactoring 부터 MSA로의 전환까지 다양한 규모의 기술 프로젝트가 진행됩니다. 또 Engineering팀의 소프트웨어 프로세스를 개선하는데 도움을 주는 프로젝트도 우선순위를 높게 산정하고 있습니다. 팀 생산성을 올리기 위한 방법론 도입 및 새로운 기술 PoC는 다양한 프로젝트에서 빈번히 발생하고 있습니다.

산정된 우선순위 기반으로 Product Owner, Engineering Manager, Tech Lead & Manager, Technical Program Manager 등이 모여 분기 목표를 정하게 됩니다.

✔ Agile - Sprint / Kanban

Agile하게 프로세스를 운영하고 있으며, 대부분 팀은 Sprint 방식으로 업무를 진행합니다. (Sprint에 대한 자세한 내용은 이전 글(링크)에 작성되어 있습니다.)

Quarterly Plan에 맞게 Sprint를 계획하고 실행합니다. 이 과정에서 Product Owner, Product Designer, Engineer 간에 문제를 해결하기 위해 활발한 피드백이 이뤄지고, 다양한 문제를 풀기 위한 스크럼과 회고를 진행하고 있습니다. 팀별, 프로젝트별 등 필요한 단위에 맞춰 현재 20개 이상의 Scrum 미팅이 정기적으로 열립니다. 상황에 따라 한 명이 2개의 Scrum에 참여하기도 합니다.

✔ Design Docs

실제 개발을 시작하기 전에 설계 단계를 진행합니다. 이를 통해 내가 모든 요구사항(또는 문제)을 이해하고 있는지 점검하게 되며, 해당 요구사항이나 문제를 해결하기 위한 최적의 방법을 설계하게 됩니다. 간단히 설계 문서를 작성하여 큰 틀과 방향성을 계획하고, 상세 설계 문서를 작성합니다.

설계 문서 작성 후엔 리뷰 과정이 있습니다. 내가 설계한 방법이 최선인지, 놓친 부분은 없는지 등을 복수의 동료 엔지니어에게 피드백 받습니다. 여러 동료에게 피드백을 받으면 각자가 갖고 있는 다양한 경험과 지식에 기반한 의견이 나오기 때문에 가장 좋은 문제 해결 방법을 찾을 수 있습니다. 팀의 모두가 리뷰에 참여할 수 있지만, 이 설계를 필수적으로 알아야 하는 동료는 명시해서 리뷰어로 지정해둡니다.

팀내 리뷰 뿐 아니라 전사 단위의 리뷰도 가능하며, 새로운 시도나 패턴이 나타날 때 또는 전사 시스템에 영향을 미치는 Core 영역에 대해선 항상 전사 단위로 리뷰 받는 것을 권장합니다. 이 과정을 통해 엔지니어 개개인이 큰 성장을 할 수 있습니다.

설계에 대한 이해를 높이고 질의하는 과정은 설계 문서가 공유되는 즉시 시작됩니다. 설계 리뷰 미팅의 심도 깊은 진행을 위해 리뷰 회의 전에 설계 문서를 읽고, 문서 댓글을 통해 질의 응답이 이뤄집니다. 설계 리뷰 미팅은 팀별, 전사 단위로 각각 1주일에 1회진행(필요시 1회 이상 별도 진행)되고 있으며, 문서상 댓글을 통해 해결되지 못한 질의에 대하여 논의 하고 좋은 안을 도출하기 위한 자리로 활용됩니다.

개발 중간에 예상치 못한 문제로 설계를 변경하는 경우도 있습니다. 이 경우에는 리뷰에 동참했던 동료들에게 설계 변경 안내 및 리뷰를 진행합니다. 어떤 이유로 설계를 변경하였는지 Design Docs를 업데이트하고 기록을 남깁니다. 개발이 완료되면 Design Docs는 관련된 System Architecture 문서의 일부로 포함되어 추후 참고자료가 됩니다.

✔ Trunk-Based Development - Test Code, Feature Flag

개발을 진행할 때에는 Trunk-Based Development(TBD) 방식을 따르기를 권장합니다. 오늘의집은 어떤 브랜치에서 개발이 이루어지는지 확인하기 어려운 문제와 Pull Request(PR)의 크기가 커서 리뷰의 정확도가 떨어지는 문제를 해결하기 위해 TBD를 도입했습니다. 이를 통해 테스트와 리뷰를 강화했고, 빠르면서도 안정적인 개발을 이뤄가고 있습니다.

TBD 도입은 코드 리뷰나 개발 문화에도 많은 영향을 주고 있습니다. 예전엔 하나의 완성된 기능 단위로 PR이 올라왔다면, 현재는 하나의 테스트 가능한 단위마다 PR과 코드 리뷰가 이뤄집니다. 자연스럽게 Test Coverage가 넓어졌고, 브랜치 관리가 간결화 되었으며, Main 브랜치가 항상 릴리즈 가능한 상태를 유지하게 되었습니다. TBD 도입을 통해 빠른 시간 안에 퀄리티 좋은 리뷰가 가능하게 되었습니다.

다만, 모든 기능이 짧게 짧게 만들어지고 배포될 수 있는 형태는 아닙니다. 오랜 시간이 걸리는 작업도 있고, 이로 인해 많은 컴포넌트를 수정하거나 생성해야 할 수도 있습니다. 이런 경우는 TBD가 불가능하지 않을까 생각할 수 있지만, 오늘의집에서는 Feature Flag를 도입하여 오래된 작업이 Main에 중간 중간 Merge되어도 안정적으로 돌아갈 수 있도록 관리하고 있습니다.

✔ Code Review

우리는 모두 좋은 코드를 작성하려고 노력합니다. 하지만, 개인의 성향, 지식 등의 차이로 코드의 품질은 다를 수 있습니다. 코드 리뷰를 통해 팀에서 생각하는 좋은 코드가 무엇인지 끊임 없이 의견을 나눌 수 있으며, 이를 통해 팀이 함께 성장할 수 있습니다. 리뷰를 받는 사람도, 리뷰하는 사람도 성장하게 됩니다. 리뷰가 누군가의 실수를 지적하는 시간이 아니라, 서로가 성장하기 위해 사용하는 소중한 시간임을 인지하고 있습니다.

오늘의집에서는 코드 리뷰를 매우 중요하게 생각합니다. 개발이 완료되면 모든 코드는 코드 리뷰를 받게 되며, Approve가 없는 코드는 배포가 불가하게 설정되어 있습니다. 이 과정에서 코드 리뷰를 Approve 한다는 것이 어떤 의미인지 그리고 리뷰어와 리뷰이가 어떤 방식으로 협업해야 좋은지 등을 지속적으로 논의하고, 코드 리뷰로 인해 발생할 수 있는 문제점을 줄이기 위한 다양한 가이드도 도입하는 등 리뷰 프로세스를 계속 개선하고 있습니다. TDD 도입도 코드 리뷰 문화를 변화시키는데 큰 요소로 작용하고 있습니다.

코드 리뷰 문화에 대한 부분만으로도 글이 작성될 분량이기에 다음에 더 자세한 글로 찾아뵙겠습니다.

✔ XPC, Traffic Control

오늘의집은 데이터에 기반한 의사결정을 중요하게 생각하고 있으며, 실험을 통해 이를 검증합니다. 배포 후 AB Test와 데이터 분석을 통해 해당 기능이 잘 랜딩 되었는지를 판단합니다. 이 결과는 다음 Iteration의 목표를 정하는데 기여하게 되며, 목표 지표를 달성할 때까지 지속적으로 AB Test 및 데이터 분석을 진행하게 됩니다.

기술 프로젝트 배포의 경우에는 Traffic Control을 통해 문제 없이 migration 되었는지 확인하며 랜딩을 진행하게 됩니다.

Incident Management

서비스 장애는 언제든지 발생할 수 있으며, 장애 발생 시 일련의 프로세스를 통해서 대응합니다. 해당 서비스의 Owner(Product Owner, Service Owner)가 장애에 대한 빠른 해결 대안을 생각하지 못한다면, 다른 팀에 마음 편히 도움을 요청할 수 있습니다. 많은 경우 담당자가 도움을 요청하기 전에 이미 다른 팀에서 두 손 두 발 걷고 장애 해결을 위한 문제 분석 및 다양한 아이디어를 제안하는 모습을 항상 볼 수 있습니다.

하나의 예로 긴급 장애 대응 채널로 이슈가 등록된 경우, 5분 이내 이해관계자와 엔지니어가 해당 이슈 파악을 위해 몰입하고 있습니다. 단기적으로 장애를 회피하는 방법부터 근본적 해결 방법 제안까지 하나의 마음으로 장애를 해소하기 위해 노력합니다.

장애가 종료된 이후에 발행된 장애리포팅 기반으로 아래의 항목들을 점검해 나갑니다.

• 문제가 발생한 근본 원인(Root cause)을 잘 찾았는지? (5 Whys)
• 같은 문제를 겪지 않으려면 어떻게 해야할지?
• 피할 수 없는 문제라면 어떻게 새롭게 만들 것인지? 그리고 사전적 알림을 어떻게 받을지?
• 현재 나온 대안이 최적의 방향인지?
• 단기적 해결방안과 장기적 해결방안이 무엇인지?

서비스가 커지고 도메인이 나눠지더라도 사용자 경험을 빠르게 복구하기 위해 함께 노력하고, 이러한 문화를 유지할 수 있는 프로세스를 만들어 나가고 있습니다.

이어서 다음 글에서는 Engineering 팀의 일하는 방식이나 문화에 대해 조금 더 자세히 설명 드리겠습니다. 👉다음 글 바로 가기 (링크)