안녕하세요, 오늘의집 진식입니다.

채용 과정에서 가장 많이 듣는 질문 중 하나인 "개발 문화가 어떤가요?"에 대해서 정리해보고자 합니다.

문화라는 것은 보통 범위가 정해져 있지 않고 방대합니다. 또한, 오늘의집을 운영하는 버킷플레이스에는 이미 훌륭한 전사 조직문화가 존재하는데요. 개발 직군이 가지고 있는 다양한 특성과 버킷플레이스의 조직 문화가 결합하여 지금의 버킷플레이스 개발 문화로 발전하였습니다. 따라서 개발팀 문화의 저변에는 버킷플레이스의 조직 문화가 반영되어 있습니다. 또한, 모든 문화가 그렇듯 개발팀 팀원 개개인이 이 문화를 유지하고, 보다 더 훌륭한 모습으로 발전시키기 위해 노력하고 있습니다.

그럼 버킷플레이스 개발에 대해서 소개해드리도록 하겠습니다.

팀 소개

문화에 대한 설명을 보다 빠르게 이해하기 위해, 버킷플레이스 개발 조직의 모습을 아래 이미지로 간단히 도식화해 보았습니다.

오늘의집 개발팀은 크게 프로덕트 개발팀과 기능적 개발팀으로 나눠져있습니다.

프로덕트 개발팀은 각각의 비즈니스팀(도메인)에 대응하여 크게 콘텐츠팀, 커머스팀, 시공 서비스팀으로 나누어져 있습니다. 각 팀 내에서 필요로 하는 경우 세부적으로 개발조직을 분할하고 있습니다. 커머스팀이 서비스와 플랫폼팀으로 분할되어 있는 것처럼요. 각각의 프로덕트팀은 비즈니스 요청사항을 보다 민첩하고 유연하게 개발, 대응하기 위해 만반의 준비를 하고 있습니다.

기능적 개발팀은 데이터팀, 인프라팀, 플랫폼 팀으로 이루어져 있습니다.

인프라팀은 오늘의집을 구성하는 서비스와 오늘의집 사내 운영 서비스를 클라우드 환경 위에서 견고하고 확장 가능한 형태로 구성 및 운영을 하는 팀입니다. 데이터팀은 오늘의집 서비스에서 다양한 데이터를 수집하고 가공하여 다시 서비스에 제공하는 일련의 과정에 대한 개발 운영 및 오늘의집 팀원이 데이터 기반으로 판단하기 위한 최적의 데이터 환경을 제공하기 위해 노력하고 있습니다. 마지막으로 플랫폼팀은 개발 인프라 및 플랫폼 개선을 위한 테스트 및 가이드(온보딩)을 담당하고 있습니다.

Idea to Release

Ideation and ICE Score

버킷플레이스를 위한 아이디어는 어떻게 모아지고 평가되어 과업으로 발전될까요? \
아이디어는 총 3가지 방향에서 모아지고 있다고 볼 수 있습니다.

• 비지니스 요구사항 - 각 팀에서 OKRs을 달성하기 위해 과업을 제안합니다.
• 아이데이션 보드 - 전사 모든 팀원이 정해진 폼에 맞게 아이디어를 올릴 수 있는 폼을 운영하고 있습니다.
• 기술적 요구사항 - 개발 관점에서 사용자에게 더 나은 프로덕트 경험을 주기 위해 개선 과업을 제안합니다.

데이터 관점에서 '왜' 해야 하며, 실제 서비스가 만들어졌을 때 어떤 데이터가 움직일 것 같은지 간단하게 작성합니다. 기본적으로 버킷플레이스에서는 Bottom Up으로 진행되는 아이데이션을 중요하게 생각합니다. 하지만 각 팀의 목표나 전사 관점의 목표로 인해 Top Down으로 발현되는 아이디어도 있습니다.

Bottom Up이든 Top Down이든, 모아진 모든 아이디어는 동일한 로직인 ICE Score를 사용하여 우선순위를 정하게 됩니다.

1. Impact: 고객에게 얼마나 큰 가치를 주는가?
2) Confidence: 아이디어의 확신도는 어느 정도인가?
3) Ease: 리소스는 얼마나 필요한가?

이 세가지 항목을 종합적으로 고려하여 아이디어의 우선순위가 정해지게 됩니다. 이중 버킷플레이스는 Impact 의미를 일반적 의미인 비즈니스에 얼만큼 영향을 주는가? 에서 고객에게 얼마나 큰 가치를 주는가? 로 의미를 변경하여 점수를 주고 있습니다. 또한 버킷플레이스는 '고객에 대한 집착'을 기반으로 일을 하는 곳으로, 고객에 대한 가치를 가장 중요시 여기기 때문에 Impact에 좀 더 많은 가중치를 주고 있습니다.

이렇게 만들어진 아이디어는 어떤 프로세스를 통해 사용자에게 전달될까요?

Sprint Process

버킷플레이스의 개발팀은 일반적인 Sprint 방식을 취하고 있습니다. 이에 대해 소개하자면 아래와 같습니다.

Product 개발팀은 위의 내용을 기반으로 Sprint Process가 2~3주 단위로 지속적으로 수행되고 있습니다. 이를 통해서 프로덕트의 점진적인 개선이 이루어지게 되고 이 개선이 쌓여 고객의 삶을 변화시킬 최고의 프로덕트를 제공할 수 있도록 하고 있습니다.

1. 분기 OKRs & 과업선정

분기 마지막 달 중순에 다음 분기 OKRs과 프로덕트 과업을 선정하는 자리를 마련합니다. OKRs을 달성하기 위한 다양한 방향으로 모인 아이데이션 결과를 취합하고 우선순위를 산정하는 작업을 진행합니다. CPO, CTO, POs & Tech Leads가 한자리에 모여 ICE Score 기반으로 우선순위를 산출하게 됩니다. 또한 Tech Leaders 주도로 PO와 함께 T-shirts 사이징을 진행하여 분기에 달성가능한 과업을 선정하게 됩니다.

2. Sprint Planning

하나의 분기에는 6개의 Sprint로 구성되어 있습니다. 그리고 각 스프린트는 시작 첫째날 PO, PM, UX 디자이너, 개발 구성원들이 모여 분기 OKRs 기반, 우선순위가 높은 순서대로 과업을 설명합니다. PO가 정의한 User Story를 기반으로 팀 구성원에게 전달하고, 아이디어(Task)에 대한 피드백을 진행합니다. 이 과정이 끝나면, 개발자분들의 주도 아래 각 Task에 대한 AC(Acceptance Criteria)를 작성하고, 일정 산출을 진행합니다. 이후 팀이 소화 가능한 리소스 기준으로 스프린트 할일에 등록합니다. 그 외에 Task들은 팀 backlog로 등록됩니다.

3. Daily Scrum

플래닝/회고일을 제외한 주중일에는 매일 스크럼을 진행합니다. Daily Scrum에서는 각 구성원들이 할당받은 task의 이슈에 대한 공유를 합니다. 기술적/비기술적 이슈 상관없이 task의 수행에 지연을 발생할 수 있는 요소가 있다면 전체 팀원에게 공유하도록 하고 있습니다. 구성원들은 스크럼 후 즉시 관련자들이 모여 이슈를 어떻게 해결할지 논의하고 진행 방향을 결정합니다.

4. Sprint Retrospective

스프린트 마지막 날 스프린트의 내용을 기준으로 지속해야 할 것, 멈추어야 할 것, 개선이 필요한 것 등의 내용으로 각 구성원들이 자유로운 회고 피드백 시간을 가지며, 다음 스프린트에 진행 할 action Item을 도출합니다. 회고를 통해 도출된 action item은 반드시 다음 스프린트 프로세스에 반영하여 개선하도록 실행하고 있습니다.

Feedback & ABTest

앞서 말했듯이 버킷플레이스 프로덕트팀은 공통된 목표를 바라보며 과제를 수행하고 있으며, 해당 결과를 극대화 하기 위해 활발히 스몰토크를 진행하고 있습니다. 기획 - 디자인 - 개발 각 단계에서 활발히 서로 피드백하여 최선의 결과물을 만들기 위해 노력하고 있습니다.

세부 기획이 시작되기 전 MVP 관점에서 어떻게 다가갈 것인지, 사용자의 경험을 헤치지 않으면서 개발의 효율을 극대화하기 위해 어떻게 하는 것이 좋을지, 디자인 중간중간마다 애매한 것이 없는지, 마지막 출시 전에 사용자 관점에서 이상한 것이 없는지 등 함께 확인하며 투명한 피드백을 주고 있습니다.

또한, 피드백을 통해 놓치기 싫은 여러 가지 좋은 안이 나타난 경우에는 지체 없이 ABTest를 진행하고, 결과를 분석하여 사용자 입장에서 최선의 가치를 만들기 위해 노력하고 있습니다.

진화하는 기술, 발전하는 우리

세월이 흐르듯 기술도 발전합니다. 아키텍처의 패러다임도 시대에 따라 크게 변합니다. 오늘 작성한 코드가 배포를 한 순간 legacy처럼 느껴지기도 합니다. 우리는 시대의 흐름에 뒤쳐지지 않기 위해 어떤 노력하고 있을까요?

기술 과업 진행을 위한 시간 분배

Functional Team의 경우 많은 시간 기술 과업을 진행하기 위해 시간을 쏟고 있습니다. 이에 반해 프로덕트 개발팀은 비즈니스 요청 사항이 우선시 되고 있습니다. 그렇다면, 프로덕트 개발팀의 리팩토링 진행 및 기술적 개선은 어떻게 가능할까요?

"Idea to Release"에서 설명했듯이, 오늘의집 프로덕트 팀은 스프린트 방식으로 개발을 진행하고 있습니다. 스프린트 플랜 회의에 개발팀 과제를 위해 일정량의 리소스를 확보하고자 노력하고 있습니다. 배정된 시간을 통해 간단한 리팩토링부터 새로운 기술 PoC 및 테스트, Tech OKRs 과제 등을 수행하게 됩니다.

이 과정에서 자유롭게 하고 싶은 과업을 하는 것이 아닌, 각각 해야 하는 이유를 찾고 이를 위한 목표를 설정해서 진행합니다. 설정된 과업에 대하여 개발팀 내부에서 타당성과 시급성을 판단하여 우선순위가 부여되며, 이후 스프린트 플랜에 포함되게 됩니다. 따라서 다양한 요인에 의해 개발팀 과제 리소스 배정이 안되거나 최대 50%까지 배정되기도 합니다.

Tech CoP

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

버킷플레이스에서의 Tech CoP는 업무를 하면서 겪는 프로세스의 개선과 기술 관점에서 경험과 아이디어를 공유하여 문제를 해결하고 함께 기술 역량을 높이는 문화로 발전하고 있습니다. 또한 이러한 활동을 통해서 팀원 간 연계가 발생하고 이를 통해 상호 신뢰감과 네트워크를 만들 수 있다고 생각합니다. 더불어 Sprint 리소스를 할당하여 진행한 기술 과업에 대하여 서로 공유하여 개인의 성장이 팀의 성장으로 발전되는 효과를 기대하고 있습니다.

버킷플레이스 Tech CoP에서는 아래의 주제를 다루고 있습니다.

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

Tech CoP는 격주에 한 번씩 1시간에서 1시간 반정도 진행하고 있습니다. 추후, 버킷플레이스 CoP문화가 발전하여 회사의 이름을 걸고 외부와 오픈된 형태의 CoP를 열 수 있는 날을 기대하고 있습니다.

Study, Conference 참가 지원

본인의 업무와 연관성이 높은 컨퍼런스에 대한 참여 또는 스터디 진행이 가능합니다. 또한 컨퍼런스 참여를 위한 비용과 스터디 진행을 위한 비용 및 장소 제공은 최대한 회사에서 지원하기 위해 노력하고 있습니다. 시간 조정이 비교적 자유로운 스터디의 경우에는 업무 시간 외에 진행하는 것을 권장하고 있습니다. 반면 시간이 고정되어 있는 컨퍼런스의 경우에는 업무 시간에 상관없이 참여가 가능합니다. 컨퍼런스 참여 후 2주내로 Tech CoP에 보고하며, 배우고 느낀 것에 대해서 공유하는 세션을 진행하고 있습니다.

티켓팅 자체가 경쟁률이 높은 컨퍼런스가 많은데요. 컨퍼런스 티켓팅에 성공할 경우 해당 컨퍼런스 참여를 위한 비용을 최대한 지원해드립니다. 하나의 예로 AWS Re:invent 참석 티켓을 3장 얻게 되었을때, 비행기 및 숙소 비용을 회사에서 제공해 드린 적도 있습니다. 반대로 많은 아이폰 개발자분들이 WWDC 티켓팅에 시도했지만 아직 성공하신 분이 없는 안타까운 소식도 있습니다.

코드 리뷰

많은 분들이 코드 리뷰에 대하여 관심이 많습니다. 현재 버킷플레이스의 모든 프로젝트와 소스코드는 Github을 통해서 관리되고 있는데요. 초창기부터 플랫폼내에 개발자가 2명 이상이 된다면 가능한 최대한 코드리뷰를 진행하려고 노력하고 있습니다. 플랫폼 별 인원수에 따라 PR이 통과되는 규칙은 조금씩 다릅니다. 프로젝트 규모 또는 코드 라인 수가 많은 경우에는 오프라인으로 코드리뷰를 진행하기도 합니다.

코드 리뷰는 단순히 코딩 컨벤션을 체크하는 용도와 버그 방지를 위해 하는 것이 아니라 팀 전체적 성장에 도움을 줍니다. 다른 사람의 구현 방법, 다른 사람이 문제를 해결하기 위해 진행한 방법 등을 관찰할 수 있습니다. 이를 통해 구현 방법의 상향 평준화를 만들 수 있으며, 비슷한 문제를 풀 때 더 빠르게 해결법에 다가갈 수 있게 됩니다. 또한 일반적으로 기술과 디자인을 익힐 때는 책을 보거나 세미나에 참석하는 것보다 더 효율적이기도 합니다.

너의 오류는 우리의 오류

위에서 보았듯이 각각의 개발팀이 개별의 목적을 가지고 분할되어 있지만, 장애의 상황에서 하나의 개발팀으로 뭉치고 치열하게 협력해 나갑니다. 장애대응 프로세스에 대한 자세한 설명은 다음에 진행할 예정이며, 이 글에서는 우선적으로 장애대응을 어떤 마음가짐으로 대하고 있는지 살펴보겠습니다.

함께 하는 장애대응 (서비스 장애 대응)

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

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

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

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

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

더 나은 문화를 위해서

이 글에 적혀있는 것이 버킷플레이스 개발 문화의 전부는 아닙니다. 위에 설명에서 중간중간 언급한 것처럼 문화는 누군가 정해서 되는 것이 아니고 구성원들이 모두 한마음으로 생활에 적용해야 의미가 있습니다. 또한 활발한 회고 문화를 통해 문화는 고정되지 않고 계속 변화할 것입니다. 문화를 발전하기 위해 서로 피드백하며, 자유롭게 새로운 제안을 하고 논의하고 있습니다. 이러한 결과들은 버킷플레이스 개발팀이 최고의 개발 문화를 가지고 있는 Tech 기반의 회사로 성장할 수 있게 해줄 것입니다. 여러분도 이 문화 만들기에 동참하시겠습니까?