리팩토링

27년 차 현역 백엔드 개발자가 코드리뷰&리팩토링하는 법 by '백발의 개발자' 백명석

#코드리뷰 #리팩토링 #TDD #세미나


코드리뷰와 리팩토링, 정말 필요한 거야?

코드리뷰와 리팩토링, 개발자들의 영원한 숙명이라고 할 수 있습니다. 그만큼 이에 대한 궁금증을 가진 개발자분들도 많이 계신데요, 이 분야의 스페셜리스트인 '백발의 개발자' 백명석님과 이야기를 나누어 보았습니다.

개발자님! 소개 간단히 부탁드립니다.

안녕하세요. K-POP 굿즈, K-Style 역직구 e커머스 서비스를 제공하는 Ktown4U에서 CTO로 재직 중인 백명석이라고 합니다. 구성원들과 협력하며 레거시 시스템 안정화, MSA 분리를 통한 개선, 물류 시스템 개선, 데이터 분석 등의 업무를 하고 있습니다.
1996년 LG-EDS(현 LG-CNS)를 시작으로, 국내외 벤쳐 기업을 거쳤고, Daum과 SK 플래닛, 11번가 등에서 개발 리더 역할을 수행하였습니다. 특히 11번가에서는 거대 Monolithic 시스템을 MSA로 분리하고, 대량의 트래픽을 안정적으로 수용 및 배포할 수 있는 환경을 구축하기도 했어요.

제 자신을 한 마디로 표현하자면, 스스로 지속 가능한 소프트웨어 개발을 추구하는 개발자이자, 리더라고 할 수 있을 것 같습니다. 소프트웨어의 가치는 실행되는 것에 그치는 것이 아니라, 지속적으로 변화하는 요구 사항을 안정적으로 빠르게 반영하여 고객에게 지속적으로 가치를 제공하고, 서비스의 성공에 기여하는 것이라고 생각해요. 그 점을 마음에 새기고 개발 업무를 수행하고 있고, 리더로서 구성원들에게 방향을 제시하고, 나아가게 하는 경험을 쌓고 있습니다.

무려 27년 째! 현역 개발자로 활동하고 계신데, 지금도 코드리뷰와 리팩토링을 꾸준히 하고 계신가요?

회의로 보내는 시간이 많지만, 리팩토링과 코드리뷰는 매일 틈나는대로 하고 있어요.
저는 코드리뷰를 통해 우리 시스템의 아키텍쳐, 설계 개선을 통해 품질을 높이고 향후 변경 비용을 낮춰서, 구성원과 함께 성장하고 회사에도 기여하는 것을 추구합니다. 구성원들의 코드를 보면 그들이 어떤 일을 하는지, 어떤 고민이 있는지 등에 대해 알 수 있고, 어떻게 하면 우리 조직의 개발 역량을 높일 수 있을지도 알 수 있어요. 리뷰에서 커멘트를 통해, 또 가끔은 오프라인 코드리뷰(주로 설계/구조 개선)를 통해 공유와 역량 향상에 애쓰고 있습니다. 관련된 내용으로 세미나를 하기도 합니다.

요즘은 코드 리뷰나 리팩토링의 필요성에 의문을 가지는 분들이 일부 계신 것 같아요.

코드리뷰를 하는 가장 중요한 목적은, 리뷰를 통해 결함이 운영 환경에 배포되지 않게 하는 것입니다. 또한 리뷰를 통해 팀원들이 서로 어떤 일을 하고 있는지 알게 됩니다. 개선 의견과 서로의 기술을 공유하여 서로의 성장에 도움을 주고, 팀워크 향상에 도움을 줄 수도 있죠.
리팩토링은 화장실에 가서 볼 일을 본 후에 손을 닦는 것과 같이 일정을 잡아야 한다고 생각합니다. 따라서 별도의 일정을 잡는 것이 아니라 개발 일정에 포함되어야 있어야 합니다.
그리고 디자인패턴, 리팩토링 등은 자신의 역량에 맞게 적절하게 진행하는 것이 중요합니다. 더 잘하고 싶다고 일정을 과하게 사용하면 팀의 업무 진행에 악영향을 미칠 수 있기 때문에, 미리 학습/연습을 해야 합니다. 회사는 연습장이 아니라 경기장입니다. 연습은 연습장에서 연습 문제로 해야 실력이 향상됩니다. 이 점이 현업에서 TDD, 리팩토링 등을 익히기 어려운 이유라고 생각합니다.

코드리뷰와 리팩토링을 꾸준히, 자주 하면 좋은 점은 무엇일까요?

코드리뷰는 우리 팀의 업무에 참여하는 필수적인 활동이라고 생각해요. 물론 코드리뷰 외에도 짝프로그래밍 등으로 기여할 수도 있습니다. 짝프로그래밍이 비동기 방식인 코드 리뷰에 비해 훨씬 빠르고 효과적인 방법이지만 코드리뷰는 짝만이 아닌 여러 팀원의 코드를 보고, 의견을 주고받을 수 있는 장점이 있어요. 이러한 공유를 통한 성장은 지속적이고 꾸준하다고 생각합니다.

리팩토링도 마찬가지로, 일상적으로 늘 수행해야 한다고 생각합니다. 그렇지 않다면 구현 전에 사전 설계를 해야 일정 수준의 설계/품질을 갖는 SW를 구현할 수 있기 때문이죠.
지금과 같은 훌륭한 IDE가 나오기 전의 개발을, 저는 내비게이션이 없을 때 운전하는 것과 비교를 합니다. 이때는 내가 원하는 곳을 가기 위해 미리 지도를 보고 메모를 하는 등 사전 설계가 필요했어요. 하지만 지금은 개발 서버에서 텍스트 편집기로 코딩을 하는 시대가 아닙니다. 그때의 서버 만큼 훌륭한 성능을 갖는 개인 장비에서, 엄청난 기능을 제공하는 IDE를 활용해서 개발을 합니다(마치 차에 타서 내비게이션에 목적지만 입력하면 바로 운전을 시작할 수 있는 것처럼). 누군가 “점(.)만 누르면 개발을 할 수 있다”라고 말하는 것을 들은 적도 있는 것 같네요.
이런 환경이라면 사전에 부족한 지식과 경험을 가지고 미리 설계를 확정하기 보다 조금씩 동작하는 코드를 작성하고 IDE의 도움으로 리팩토링을 통해 설계를 해 나가는 것이 훨씬 빠르고, 품질 높은 SW를 구현하는 기법이라고 생각합니다. 이 방법은 지속적으로 전달(Continuous Delivery)이 가능해, 빠르게 피드백을 받아 결함을 최대한 빨리 발견할 수 있어요. 또한 항상 동작하는 코드를 가지고 개발을 함으로써 안전감/성취감을 가지고 개발을 할 수 있다는 장점도 있습니다.

코드리뷰와 리팩토링의 중요성, 필요성을 체감했던 경험이 있다면?

잘 작성된 코드나 좋은 리팩토링 사례를 보면, 나도 그렇게 잘 하고 싶다는 생각이 들어서 동기부여가 된다는 의견을 많이 들어요. 그리고 익명의 실수가 공유된 이후 다른 개발자들이 동일한 실수를 줄이는 경우도 종종 경험했습니다.

최근에 매우 인상적인 경험을 했는데요, 풀기 어려운 버그를 짝프로그래밍을 통해 해결하고, 해당 변경에 대해서 작업자들이 온라인 코드리뷰를 해서 안전하게 배포했던 경험이 있습니다. 이 문제는 복잡하고, 위험하기에 오랜 기간 해결이 되지 않은 문제였습니다. 이때 나 말고 한 명의 팀원이 한 번 더 확인해 주는 짝 프로그래밍을 통해 용기를 가지고 해결할 수 있었습니다. 그리고 배포 전 코드리뷰를 통해 혹시나 있을 수 있는 실수를 한번 더 안전하게 조사해서, 과감하게 배포할 수 있었습니다.


그렇다면, 백엔드 개발자로서 성장하기 위한 코드리뷰&리팩토링 방법을 살짝 공개해주실 수 있을까요?

코드리뷰, 리팩토링은 정확한 방법을 알고 시작하기 보다 자전거를 배우듯이 배우는 것이 좋다고 생각합니다. 자전거를 배울 때, 자전거 타는 법에 대한 책을 다 읽고 나서 배우는 사람은 없죠. 약간의 설명을 듣고 누군가 잡아주면서 바로 타기 시작합니다. 그러다 중심을 잡았을 때, 뒤에서 잡아주던 사람이 “잡고 있어 걱정마”라고 말하며 손을 떼면 자전거를 탈 수 있게 되는거죠.
코드리뷰, 리팩토링도 그런 것 같습니다. 다만 개발자로서 영원히 해야 할 일인 만큼 더 잘 하기 위한 지속적인 노력이 필요합니다. 그렇기 때문에 리팩토링에 관련된 책을 한 권도 안 읽은 채, 리팩토링을 한다고 말하는 분을 보면 저는 조금 안타깝다는 생각이 들기도 해요. 학습과 연습은 항상 꾸준히 이루어져야 한다는 점을 꼭 알아주셨으면 좋겠습니다.

저는 TDD, 리팩토링을 책이 아니라 실제 업무에서 하는 모습을 공유하고 시작할 수 있도록 도와드리고 싶어요. 제 경험을 통해 효과가 증명된 방법들을 보여드리고, 많은 분들이 제대로 시작할 수 있도록 도와드리고 싶습니다. 그리고 막히는 부분들에 대해서 공유하고, 토론해 보았으면 합니다. 이를 통해 저를 포함해서 참여하는 모든 분들이 서로 성장하는 것을 기대하고 있어요.

Sudo 22: Tech Leader's Talk [2022 소프트웨어 공학의 개발 생산성에 대하여]
컨퍼런스에서 발표하는 모습

이번 11월 30일 수요일, 라이브 세미나 "D-DAY"에서 TDD와 리팩토링에 대해 말씀하실 예정인데, 어떤 분들이 들으시면 좋을까요?

이번 온라인 세미나에서는 Rest API 호출하는 것을 TDD로 구현하는 과정, 레거시 코드에서 응집도, 캡슐화, 유지보수 용이성 등을 높이기 위해 리팩토링하는 과정을 보여드릴 예정입니다.
실무에서 TDD를 시작하기 어려워 하는 분들, 레거시 코드 리팩토링에 어려움을 겪는 분들에게 도움이 될 것 같습니다.

그리고 현재 제가 리더로 있는 INNER CIRCLE도 모집 중인데요, 저와 총 20 분의 현직 개발자가 모여 8주 간 강연과 토론이 진행됩니다.
현업에서 참여자들이 실제로 적용하며 겪은 어려운 점, 잘했던 점 등을 모두에게 공유하고 토론할 예정이에요. 이를 통해 동료와 함께 성장할 수 있습니다. 이렇게 열린 마음으로 잘한 점, 부족한 점 등을 적극적으로 공유하여 함께 성장하고자 하는 분이라면 저와 꼭 함께 하셨으면 좋겠습니다 :)

마지막으로, 성장하고자 하는 독자 여러분들께 응원의 한 마디 부탁드릴게요.

[ 子曰: "學而時習之, 不亦說乎?" ]
공자가 말하길 배우고 때때로 익히면 이 또한 즐겁지 아니한가 ?

"나는 세상을 강자와 약자, 성공과 실패로 나누지 않는다.
나는 세상을 배우는 자와 배우지 않는 자로 나눈다.”
- 사회학자 벤저민 바버


이 두 학자들의 가르침만 봐도, 배우는 것은 중요하고 즐거운 일입니다.

그런데 지금 생각보다 많은 돈을 벌고 있다고 해서, 배움과 성장에 대한 노력을 하지 않아도 되는 것일까요? 지금 버는 돈은, 시간이 지나면 가치가 떨어질 것입니다. 자동차가 1,500만원 정도 할 때 20~30년 후면 그 차가 1억이 될 것이라는 얘기를 들은 적이 있습니다. 그런데 정말 그럴 것 같다는 생각이 듭니다. 그만큼, '지금 얼마를 버느냐'도 중요하지만 '향후에 얼마를 벌 수 있는 사람이 되느냐'가 더 중요하고, 이를 위해 성장은 필수입니다.

또 내가 아무리 잘 하더라도, 평가와 보상은 내가 원하는 대로 되지 않을 수 있습니다. 그러나 인정받을 수 있는 기회는 반드시 오게 되어 있고, 언제 그런 기회가 올지 모르니 늘 준비, 즉 성장하고 있어야 합니다.
사회 생활을 시작한 후 얼마 지나지 않았을 때, 개발(코딩) 그만하고 관리를 해야 한다는 말을 들은 기억이 납니다. 그때가 무려 23년 전 입니다. 그런데 저는 지금도 코딩을 합니다. 그래서 저는 지금껏 그래왔듯, 앞으로도 20년은 충분히 개발을 하면서 살 수 있다고 생각합니다. 여러분도 지금 성장을 원하는 그 마음을 놓지 마시고, 꾸준히 학습하고 성장하시길 바랍니다 :) 충분히 할 수 있습니다!


지금 패캐머들이 읽고있는 BEST 아티클이 궁금하다면

이 글과 연관된 주제의 추천 강의