3월, 6월, 9월, 12월. 모든 분기의 마지막 주, 오늘의집 엔지니어링팀은 특별한 일주일을 보냅니다. 바로 ‘Fix-it week(픽스잇위크)’가 진행되기 때문인데요.

오늘의집 엔지니어링팀의 특별한 문화 중 하나인 Fix-it week는 한 주를 통째로 써서 서비스가 보완해야 할 사항들을 개선하는 작업을 진행하는 기간을 뜻합니다. 흔히들 ‘기술 부채'라고 말하는, 개발 과정에서 빚처럼 쌓인 묵은 과제를 해결하는 시간이죠. 이 특별한 한 주 동안 엔지니어링 팀은 일상 업무에서 벗어나 버그, 오류 등을 해소하거나 뒤처진 문서를 고도화하는 작업 등을 수행합니다.

3번 만에 1200개 이슈 해결

2022년 2분기 처음 시작된 오늘의집의 Fix-it week는 오늘의집 시스템을 안정적으로 유지하기 위한 ‘분기별 대청소’와도 같은 기간이라고 볼 수 있어요. 모든 개발자들이 하던 일을 멈추고 문제 해결에만 집중하기 때문인데요. 이 기간에는 신규 개발이나, 정기적으로 진행되던 회의도 진행하지 않습니다.

지금까지 3번의 Fix-it week를 거치며 오늘의집 개발자들이 제안한 이슈만 1500개. 이중 약 80%에 해당하는 1200개가 해결되었다고 해요. Fix-it week에서는 기술 부채를 해결해 서비스 품질 개선 및 시스템 효율 상승 효과를 내는 것은 물론, 다양한 방법으로 발생 가능한 오류를 사전에 차단하는 작업도 함께 진행되고 있어요.

개발자들의 일주일

Fix-it week를 통해 가장 많은 수의 이슈를 해결한 이는 안드로이드 엔지니어 Liz님이에요. Liz님은 Fix-it week 기간 동안 안드로이드 내에서 동일한 객체(object)를 하나로 사용할 수 있도록 개선 작업을 진행했습니다. 안드로이드에서는 화면을 표시할 때 서버로부터 받아온 데이터를 활용하고 있는데요. 데이터가 동일한 의미인데도 사용처에 따라 객체 구성이 달랐거든요. API에서 완전히 다른 형태로 내려주는 경우도 있었고, 동일한 형태로 내려주지만 안드로이드 자체에서 다른 객체로 만들어 사용하기도 해서 지속적으로 누적되는 이슈였습니다.

이에 Liz님은 Fix-it week 기간 동안 서버로부터 동일한 응답으로 받지만 안드로이드에 파편화되어있던 특정 객체들을 찾아서 통일하는 작업을 진행하였습니다. 이후 서버 개발자와 논의를 통해 동일 의미의 객체는 서버에서도 동일한 형태로 내려줄 수 있도록 함께 개선했죠. Liz님은 “정리된 것보다 앞으로 정리해야 할 것이 더 많지만, Fix-it week 기간을 통해 첫 발을 딛게 된 것이 큰 의미가 있다고 생각한다"고 소감을 전했어요.

O2O팀 프론트엔드 엔지니어 Bernard님은 Fix-it week를 통해 공통 모듈 환경을 조성해 동료로부터 찬사를 받았답니다. 그간 O2O팀 내에서 공통으로 사용하던 코드가 프로젝트 별로 분리되어 있지 않고 하나의 레포지토리(이하 레포) 안에 전부 모여있었는데요. 코드 분리 작업의 필요성은 모두 공감했지만 시간이 없어 기존 레거시 레포에서 계속 개발하던 상황이었죠.

‘분리해야 하는데…’ 라고 모두가 생각하고 있었지만 선뜻 진행하지 못했던 그 일을 Bernard님께서 Fix-it week 기간 동안 진행하셨다고 해요. 집에 비유하자면, 공통 모듈을 모아놓은 방만 존재했는데 O2O 공통 모듈만 모아놓는 방을 새롭게 만들고 그곳으로 코드를 조금씩 옮기거나 필요한 내용들을 넣는 거죠. Bernard님은 O2O팀의 Frontend Engineer들이 공통 코드들을 모듈로 옮길 수 있도록 공통 모듈 환경을 조성하는 작업을 진행해 FE MSA 분리, 레거시 리팩토링을 진행하는 데에 큰 기여를 했답니다.

데브옵스 엔지니어 Sumin님은 일주일이라는 짧은 시간 동안 AWS 리소스 정비 작업 전반을 수행했어요. 먼저 현재 오늘의집 AWS networking의 근간이 되는 Transit Gateway 및 VPN 설정을 Terraform 코드로 구현하여 AWS 인프라의 IaC (Infrastructure As Code) 적용률을 한층 더 높였습니다. 이를 통해 인프라 현황을 개발자가 코드로 쉽게 파악할 수 있게 되었습니다.

뿐만 아니라 Sumin님은 AWS 계정 정비 작업도 함께 했어요. 오늘의집은 5~6 가지의 AWS 계정들을 중앙 management 계정으로 통합 관리할 수 있게끔 정리하는 작업을 22년 1분기에 진행해 주요 정보를 통합 관리할 수 있게 바뀌었는데요. 이후 Sumin님은 Fix-it week를 통해 service production 계정의 리소스들을 best practice architecture에 따라 정비했습니다. 일관된 태깅을 적용하고 미사용 리소스를 제거했으며, 보안 컴플라이언스를 따르지 않는 리소스들의 취약점들을 수정한거죠. 그 결과 서비스 계정의 비용이 최적화되었고, 향후 보다 체계적인 관리 운영을 할 수 있는 기반을 갖추게 되었습니다.

웹 프론트엔드 엔지니어 Haneul님은 디자인 시스템 Eslint를 개선해 많은 개발자들이 함께 조인하는 레포에서의 개발 편의성을 높여주었습니다. 오늘의집은 코드의 formatting이나 코드 작성 규칙이 전사적으로 정의(bucket-eslint) 되어있는데요. 지난해 이 부분이 업데이트됐으나, 이 부분이 디자인 시스템에는 적용되지 않아 디자인시스템 코드들은 다른 레포의 코드들과 formatting이나 작성 방식이 조금 다르게 설정되어 있었죠.

Haneul님은 디자인시스템 bucket-eslint를 최신 버전으로 업데이트하고, 최신 bucket-eslint의 규칙에 어긋나는 코드들을 지금 규칙에 맞도록 전부 수정하는 작업을 진행하였습니다. 이를 통해 코드의 가독성이 좋아진 것은 물론, 다른 개발자들이 신규 코드를 추가하거나 유지보수할 때도 더 수월하게 작업할 수 있게 되었다고 해요.

Search팀에서는 Fix-it week를 통해 무려 3년간 묵혀둔 기술 부채를 해결했어요. 오늘의집은 카테고리 피드를 통해 카테고리 선택을 구현하고 있는데요. 카테고리 피드 페이지는 다른 페이지와 달리 이전 방식으로 일컫는 hash 파라미터(category)로 진행되어 왔습니다. 선택된 카테고리를 표현하는 방식이 통일되지 않다 보니 레거시 코드 제거가 어렵고, 구 카테고리 형식과 신 카테고리 형식을 함께 운용하는 과정에서 업무 효율성이 떨어져 해결해야 할 숙제로 남아있었죠.

Search팀은 22년 3분기 Fix-it week 과제 중 하나로 이를 지정해 카테고리 피드 구현 방식을 단일 카테고리를 표현하는 형식인 신버전 id 파라미터(category_id)로 전환하는 작업을 진행했습니다. 실제 이 작업을 제안하고 진행한 프론트엔드 Preco님 소감을 들어볼까요?

일주일이 지나면

위의 사례 외에도 3번의 Fix-it week 기간 동안 수많은 개선이 이뤄졌어요. 개발자들은 때로는 더 나은 개발환경을 만들기 위해서, 때로는 새로운 도전의 기회로 이 시간을 활용하죠. 숨겨왔던 탁월함을 보여주거나 놀라운 집중력을 보여주는 분들도 많아요. 동료들의 새로운 면목을 발견하기도 하죠.

이런 일주일 간의 Fix-it week가 끝나면 함께한 동료들에게 감사를 전하는 시간도 가집니다. ‘가장 많은 문제를 해결한 사람', ‘가장 어려운 문제를 해결한 사람', ‘가장 오래된 문제를 해결한 사람'을 선정해 ‘Peer Bonus’ 혹은 ‘Spot Bonus’를 지급하고 있어요. 모두의 문제를 해결하는 데 기여한 동료에게 박수와 함께 보너스를 안겨주는 거죠.

인디언들은 넓은 대지를 말을 타고 달리다 종종 멈춰 서서 뒤를 돌아본다고 합니다. 자신의 영혼이 따라올 때까지 기다리는 거죠. 오늘의집 엔지니어링팀도 마찬가지입니다. 이렇게 분기별로 특별한 일주일을 통해 뒤를 돌아보고 더 나은 내일로 나아가기 위한 준비를 합니다. 엔지니어링팀 모두가 ‘더 이상 제기할 이슈가 없습니다’라고 코멘트할 때까지, 오늘의집의 Fix-it week는 계속됩니다.