오늘의집 서비스를 이용하는 사용자라면 가끔 이런 기분을 느낄지도 모릅니다. ‘엇, 뭔가 달라졌다?!’

네, 잘 보셨습니다. 어제보다 더 좋은 서비스를 만들기 위한 노력의 결과물을 발견하셨군요!

누군가의 아이디어에서 탄생한 그 변화들, 서비스에 반영되기까지 어떤 과정을 거쳤을까요? 이번에는 오늘의집에서 아이디어가 서비스에 실현되는 과정에 대해 알아 보도록 하겠습니다.

아이디어 제시 및 공유 – 아이데이션 보드

오늘의집에서는 전사 아이데이션 보드를 통해 아이디어를 수집합니다. 아이데이션 보드는 오늘의집 서비스에 필요한 아이디어, 개선사항에 대한 제안이 모이는 공간입니다. 전 구성원이 접근할 수 있고, 진행상황 또한 열람할 수 있습니다. 누구나 오늘의집 서비스에 필요하다고 생각되는 부분에 대해 제안할 수 있는 것이지요. 아이데이션 보드에 제안된 아이디어는 모두 검토 대상이 됩니다.

아이데이션 보드에 올라온 아이디어 외에도 오늘의집 사용자가 더 편리하게 서비스를 이용할 수 있도록 개선 또는 추가해야 할 부분이나 사업적으로 우리가 가야할 방향성에 비추어 필요하다고 생각되는 부분에 대해서도 별도로 논의하여 기획을 진행하기도 합니다.

팀 아이디어 회의

각 팀에서 아이데이션 보드에 올라온 아이디어에 대한 평가를 합니다. 아이디어를 제시한 사람과 관련된 부서간에 아이디어를 확장/검증하는 단계입니다.

보다 효과적인 검증을 위해 오늘의집에서는 *ICE스코어** 방식을 사용하고 있습니다. 예를 들어, 아이디어를 낸 사람이 ‘이 아이디어를 서비스에 반영하면 5천 명 정도 도달할 것이고 그 중 10% 정도 구매로 이어질 것이다’ 와 같이 비교적 구체화 된 수치를 제시하고, 해당 수치가 타당한 로직으로 도출되었는지 논의를 진행합니다. 최종 결정된 예상 수치를 기반으로 이 Task가 얼마나 강력할지(Impact), 그에 대한 확신도(Confidence)는 어느 정도인지 미리 예측해 보는 겁니다. 이 과정을 통해 일부 아이디어는 다음 단계로 넘어가지 못하고 사장(!)되기도 합니다. 그러나 이 단계를 통과한 아이디어는 정량화 된 예측 수치를 가지고 PO/경영진 회의로 넘어가 본격적인 고려 대상이 됩니다.

* ICE스코어 모델: 제품에 적합한 기능 및 아이디어를 선택하는 데 사용할 수 있는 우선 순위 결정 전략 중 하나. Impact, Confidence, Ease의 세 가지 매개 변수를 사용하여 상대 가치를 기준으로 우선 순위 를 정한다. (참고: https://hygger.io/blog/ice-method-helps-choose-better-product-features/)

전사 아이디어 회의

이제 더 다양한 시각으로, 전사적 관점에서 아이디어를 평가할 차례입니다. 해당 평가를 하기 위해서 매주 각 팀의 PO(Product Owner)와 수석 디자이너, 데이터 리더, CTO, COO, CEO가 모입니다. 이 회의에서 각 아이디어가 실현되면 고객에게 얼마나 많은 영향과 도움을 줄 수 있는가의 관점으로 더 심도있게 논의합니다. 이 논의의 결과에서 최종 Impact와 Confidence가 확정됩니다. 이 때 CTO는 해당 아이디어에 대한 개발 난이도를 판단하여 개발 공수(Ease) 값을 제시합니다. 해당 Ease는 기획/디자인 과정에서 변경될 수 있고, 변경된 Ease에 따라 다시 논의를 하게 되는 경우도 있습니다. 이렇게 모인 ICE(Impact, Confidence, Ease) Score를 통해 각 아이디어의 실행 여부 및 기획/디자인/개발의 우선순위가 정해집니다.

아이디어 확장 및 실행 (기획/디자인)

자, 이제 본격적인 실행 단계입니다. 높은 우선순위가 부여된 아이디어 순으로 담당 팀이 Task를 가져가 기획과 디자인을 수행합니다. 이 때 아이디어를 확장하거나 구체화하는 작업이 이루어지게 되죠. 본격적으로 실행하기로 결단한 Task에 대해서는 칸반보드의 카드로 만들어지게 됩니다. 칸반보드 관리를 위해 JIRA 툴을 사용하고 있습니다.

기획자와 디자이너는 진행상황에 대해 매일 개발자와 공유하고 의견을 나누며 기획/디자인 작업을 완성해갑니다. 이 단계에서부터 개발자와 기획자, 디자이너 간의 긴밀한 협업이 이루어지고 있다고 보면 되겠습니다.

개발 수행 및 배포

기획/디자인 작업이 마무리되면 개발팀에 Task가 넘어옵니다. 그리고 각각의 Task는 다음의 과정을 통해 담당자가 정해집니다.

각 파트를 담당하는 개발자들과 CTO가 모여 함께 개발 소요 시간을 산출하고 업무 관여도가 높은 개발자에게 Task가 돌아갈 수 있도록 의논합니다. 여기서 각자 해당 업무를 수행할 경우 걸리게 될 시간과 리팩토링* 필요 여부, 리팩토링을 진행한다면 추가로 걸리는 시간, 현재 수행중인 업무량 등 업무에 필요한 사항을 모두 모읍니다. 이 과정으로 인해 각 개발자들의 의견이 수렴되고, 같은 View를 가지고 개발을 시작할 수 있는 방향성도 얻게 됩니다. 이와 같이 각 Task에 대한 담당 개발자와 개발 기한은 상위자의 일방적인 지시가 아닌 팀원들의 원활한 소통으로 인해 결정됩니다.

* 리팩토링: Refactoring, 외부동작을 바꾸지 않으면서 내부 구조를 개선하는 방법으로, 소프트웨어 시스템을 변경하는 프로세스. 주로 가독성을 높이고 유지보수를 편하게 한다.

이렇게 정해진 개발 기한은 모두 합의한 결과물로 나온 시간이기 때문에 누구보다 담당자가 책임지고 지키려고 노력합니다. 그러나 때로는 기한 내에 못 끝내게 되는 경우도 생길 수 있습니다. (사람이 하는 일이기 때문에!) 그럴 땐 지연의 원인을 파악하여 핵심 포인트 위주로 기록해둡니다. 그리고 추후 프로세스 개선회의*에서 원인과 해결방법에 관해 심층적으로 논의함으로써 같은 이유로 지연을 겪지 않도록 노력하고 있습니다.

* 프로세스 개선회의: 개발 프로세스 중 생기는 문제점을 개선하기 위해 개발그룹 팀원들 간 논의하는 회의.

오늘의집 개발자들은 읽기 쉬운 코드를 지향하기 위해 좋은 코드란 어떤 것인지 고민하고 활발히 소통합니다. 각 플랫폼마다 코드리뷰를 하고 좋은 기술에 대해 스터디하고, 안정성을 검토한 뒤 도입하기도 하지요. 서비스가 커지고 복잡해지면서 어려운 점도 생기고 있지만 각 분야의 전문가를 적극적으로 충원하며 보완해 나가고 있습니다. (개발자 절찬 모집 중!)

오늘의집 개발 릴리즈 목표 주기는 2주입니다. 2주 단위로 개발이 완료된 건은 QA(Quality Assurance) 단계로 넘어갑니다. QA 담당자는 개발이 완료된 건에 대해 QA를 수행하고, 테스트 검증까지 마치게 되면 마침내 구현된 아이디어가 배포됩니다. (짝짝짝)

지금까지 오늘의집에서 아이디어가 서비스에 실현되는 과정에 대해 자세히 살펴보았는데, 어떠셨나요?

아이디어 제안부터 그것이 실제로 구현되기까지 많은 과정과 리소스가 들어가지만, 불필요한 보고 등 비효율을 없애 빠르게 실행될 수 있도록 노력하고 있습니다. (오늘의집은 Lean 하게 일한다! 결과 중심의 빠른 실행!)

매일 부지런히 성장하고 있는 오늘의집에서 사업 성장 속도에 버금가는 안정화된 서비스를 제공하기 위해 프로덕트팀과 개발팀 구성원들은 오늘도 열심히 달리고 있습니다.

더 편리하고 안정적인 서비스로 만나게 될 오늘의집, 앞으로도 기대해주세요!