안녕하세요. 삼성전자 BDC 팀의 임민승입니다. 많은 분들이 강렬한 제목에 이끌려 포스팅을 클릭하셨을 텐데요. 관심에 감사드리며 저희 팀에서 ‘코드 리팩토링 데이’라고 이름 붙이고 운영 중인 중요한 문화에 대해 소개하고자 합니다. 저희의 이야기를 들어보시고 좋은 영감을 받으시면 좋겠습니다.

‘삼성의 모든것, 삼성계정 하나로 시작하세요’라는 문구가 익숙하실 겁니다. 삼성 제품을 처음 만난 모든 사용자는 가장 먼저 이 화면을 만나게 되는데요.

그림 1

계정 로그인 과정을 번거롭게 생각하거나 어렵게 느끼시는 분들도 있는 것으로 알려져 있습니다. 하지만 한 번이라도 삼성어카운트(Samsung Account)에 접속한다면 그 편리함과 효과를 누릴 수 있다는 점 역시 잘 알려져 있습니다.

간단히 소개하자면, Samsung Pay를 통해 편리한 결제, 출금 서비스를 경험할 수 있고, SmartThings로 삼성전자의 여러 기기를 편리하게 작동할 수 있습니다. Samsung Cloud를 사용하여 연동된 기기들의 정보를 쉽게 백업하고 보관할 수 있죠. 삼성어카운트 사용자는 이외 다양한 서비스를 지원 받습니다. 분실한 휴대폰을 찾을 수 있는 ‘내 폰 찾기’와 ‘개인정보 보안’은 삼성의 제품에 대한 신뢰도를 높입니다. 자세한 내용은 여기를 참고하세요.

삼성어카운트는 한 번의 가입으로 스마트폰, 태블릿, 웹사이트, TV 등에서 다양한 삼성 서비스를 이용할 수 있도록 제공되는 통합 계정 서비스이며, 삼성 계정을 기반으로 하는 다른 서비스들을 추가 가입 절차 없이 이용하실 수 있습니다. 그렇다면 삼성어카운트가 17억 명에 달하는 유저가 사용하고 있는 대규모 트래픽의 무중단 서비스라는 점도 알고 계셨나요?

삼성전자가 연간 5억 대 이상 기기를 새로 연결한다는 목표로 ‘초연결’ 생태계를 강화한다는 소식이 있고, 제품과 서비스를 이용하는 모든 고객이 더 진화된 솔루션을 제공받을 수 있도록 가전기기를 넘어 초연결을 모든 사물로 확장하는 방안과 개인별 맞춤 경험을 제공하기 위한 기술 고도화를 강조하고 있습니다.

그림 2

글로벌 브랜드인 삼성전자의 대규모 트래픽을 무중단으로 서비스한다는 것은 결코 쉬운 일이 아닙니다. 삼성어카운트는 안드로이드 OS 지원이 종료된 단말에서도 계속해서 사용되고 있는데요. ‘End of Life(EoL), End of Service(EoS)’에 대한 개념을 아실 텐데요. End of Support 기간과 Legacy 지원 종료 이후의 유지 관리 문제는 삼성어카운트 개발팀에게도 화두입니다.

개발 조직 입장에서 봤을 때 이에 대한 Legacy가 많이 쌓여 있고, 해결하고 정리해야 하는 기술 부채가 많은 상황입니다. 이를 효율적으로 진행하기 위하여 팀 차원에서 고민을 많이 했고 개선해 왔습니다.

서비스 개선은 일반적인 코드 퀄리티 지표 개선을 기준점으로 진행하였습니다. 아쉽게도 팀 내에서 관리하는 지표에 한참 도달하지 못해왔는데요. 코드 클리닝이 기능 개발에도 상당히 영향이 줄 수 있었기 때문입니다. 실제로 코드 3줄을 수정하는데 사이드로 인해 2주가 소요되는 경우도 있었습니다. 그림 3, 4를 보면 코드 클리닝 과정에서 진행한 정적 분석 테스트 결과와 SAM Score가 좋지 않다는 것을 알 수 있습니다.

(“CC : Cyclomatic Complexity, LOC : Lines of Code, DC : Duplicate Code, GM : God Module, CBO : Coupling Between Objects, DEP : Dependency Complexity, MCD : Module Circular Dependency”)

그림 3

그림 4

그리고 개발팀이 수행하는 과제 특성상 코드 수정이 매우 많은 편입니다. 총 LOC는 30만 라인이고, PR 개수도 1,800여 건이 넘는데, PR마다 수정 라인 수도 200 라인 이상인 경우가 절반 정도 되고, 1000 라인 초과가 20%를 차지할 정도로, 정신없이 바뀝니다.

레거시에 대한 작업은 많은 점에서 고된 작업인데, 기술 부채를 일일이 확인하고 과도한 코드 클리닝은 높은 피로도를 갖고 있습니다. 이러한 특성으로 인해 담당 개발 인력의 개인적인 접근은 불가능했고, 개발팀 전체 차원에서 움직여야 했습니다. 스케일과 워크로드가 큰 업무였다는 점을 이해해 주시면 되겠습니다(그림 5).

그림 5

워낙 워크로드가 큰 업무이기에 팀원에게 업무를 분배해야 했고, 각 팀원에게 가장 편한 요일을 투표로 선정해 전문성에 맞게 업무를 리밸런싱하였습니다.

그리고 리팩토링 데이에 맞는 고도화를 하기에 좋은 기회라고 생각하여 ‘그라운드 룰’과 개선 목표를 정하고 ‘리팩토링 브랜치 전략’을 선정했습니다(그림 6).

그림 6

이렇게 정해진 기본 룰을 바탕으로 리팩토링 데이를 진행하였습니다. 바쁜 일정에도 놓치지 않으려고 했던 것은 회고입니다.

매일 하루 일정을 마무리하는 회고에서 좋았던 점, 아쉬웠던 점, 흥미로웠던 점을 서로 이야기하면서 공감과 공유를 통해 팀워크를 높이려고 노력했습니다(그림 7).

절대적으로 부족했던 작업 시간과 빠듯한 타임라인에 대한 목소리가 가장 많았고, 코드 리뷰와 리팩토링에 대한 효과, 호응에 대한 피드백도 많았습니다. 이 점이 뿌듯했는데요.

리팩토링 업무에 대한 마음의 짐을 내려놓을 수 있었다는 이야기도 있었습니다.

그림 7

대부분의 작업은 툴을 이용하여 작업을 했는데, SR에서 제공하는 툴인 AnalysisHub를 바탕으로 하여, 어려운 부분은 IDE의 Plugin을 이용하고, 피어리뷰를 강화하는 방식으로 보완하였습니다(그림 8).

아시다시피, AnalysisHub 등의 정적분석 툴을 이용하여 코드 분석을 진행하고 그 결과에 따라 목표를 정할 수 있었습니다.

앞에서 이야기한 재조정한 브랜치를 보면, 각 특성마다 나눠진 브랜치들이 바로 main으로 병합되지 않고 리팩토링 전용 브랜치에 먼저 병합되는데요. 테스트를 거친 뒤, main에 병합되는 전략을 사용하는데, 개발자들이 main 브랜치에 바로 병합하지 않는 이유에 대해 공감하며 작업을 진행할 수 있도록 관리했습니다. 피어리뷰와 회고에서 많은 이야기를 나눴기에 개발자 모두가 이런 큰 리팩토링 변화에 동의한 상태에서 진행할 수 있었습니다.

그림 8

리팩토링 데이의 데일리 목표는 개발팀 전체의 제안과 논의를 통해 선정되었는데, 이렇게 각자가 고민하고 공유하는 과정을 통해 모두가 성장할 수 있는 기회가 되었습니다. 조직은 다양한 구성원들을 필요로 합니다. 자연스럽게 조금 더 잘하는 사람과 연습이 더 필요한 사람이 있습니다. 이들이 구분 없이 같이 성장할 수 있었고, 서로의 인사이트를 공유하면서 서로를 인정하는 기회가 되었습니다.

아래 그림에서 볼 수 있듯이 이 과정을 문서화하여 관련 개발자들이 모두 확인하고 공부할 수 있도록 관리했습니다. 문서화하는 과정에 시간이 소요되는 것이 처음에는 부담스러웠지만, 시간이 지나자 많은 개발자들이 그 가치에 공감하며 이를 지속했습니다(그림 9-1, 9-2).

그림 9-1

그림 9-2

리펙토링 데이 내내 개선 활동을 통하여 특히 좋아진 부분은 개발자들 간 소통입니다. 이전까지는 서비스 개선점 반영을 위한 개발 문화가 디폴트였다면, 이제는 함께 건설적으로 고민하는 문화로 바뀌고 있습니다. 작년과 올해 Github의 contributions는 비슷하지만 전반적인 그래프는 균형을 찾았습니다.

아래 그림에서 보시다시피 Issues는 다른 툴을 사용하기 때문에 집계에서 제외된 것을 고려하면 전년 대비 상당히 좋아진 것을 한눈에 알 수 있습니다(그림 10).

그림 10

개선 활동을 통해 개발팀이 목표한 코드 퀄리티 지표를 달성하였고, 이를 통해 사이드로 인한 수정 배포 횟수도 같이 감소하여 모니터링에 소요되는 시간이 줄었습니다.

줄어든 시간만큼 개발자들에겐 코드를 더 볼 수 있는 시간과 기회가 생겼습니다. 이는 엄청난 생산성 향상입니다. 가장 중요한 점은 이 생산성 향상 효과를 개발자들 모두가 스스로 느낄 수 있었다는 점입니다.

이 놀라운 변화를 아래 그림에서 객관적인 수치로도 확인할 수 있습니다(그림 11-1, 11-2, 11-3).

그림 11-1

그림 11-2

그림 11-3

저희 개발팀의 이야기가 어떠셨을지 모르겠습니다. 친숙하게 느끼신다면 운 좋게도 훌륭한 개발 조직에서 일하고 있는 것일테고요.

우리 조직에도 도입해서 실천해 봐야겠다고 느끼시고 주변 동료들에게 저희의 이야기를 공유한다면 저는 매우 뿌듯할 것 같습니다. 각 개발팀이 처한 상황과 이슈, 조직의 우선순위는 매우 다양합니다.

성숙한 개발 문화를 위해 각자의 자리에서 고군분투하고 계신 많은 엔지니어분들에게 응원의 박수를 보냅니다.

저희와 같은 고민을 하고 계신 분들은 한번 저희처럼 고민을 해보시고 유의미한 결과를 찾으셨으면 좋겠습니다.

몸으로 느낄 수 있는 개발 문화의 개선 그리고 객관적으로 입증 가능한 서비스 개선, 모두를 확인하실 수 있을 겁니다.

감사합니다. 삼성전자 BDC 팀의 임민승이었습니다.