리팩토링 여정, 더 나은 코드로의 항해 part 3. 함께한 여정, 함께한 성과

안녕하세요! 전시개발팀 티모입니다!

오늘은 리팩토링 여정 시리즈의 마지막으로, 우리가 어떻게 이 항해를 헤쳐나갔는지와 팀원들의 후기를 공유드리려고 해요.

그 전에 저희 팀이 리팩토링을 결심하게 된 이유와 과정이 궁금하시다면, “리팩토링 여정, 더 나은 코드로의 항해 part 1. 리팩토링 계기와 문제 진단"과 “리팩토링 여정, 더 나은 코드로의 항해 part 2. 새로운 구조로 나아가는 길"을 먼저 봐주세요. ️️☺️

전시 파트는 약 1년 전부터 지금의 체제로 운영되고 있어요. 구성원들마다 전시 업무 경험이 다 달라 처음에는 팀워크를 맞추는 데 조금 어려움이 있었지만, 지금은 서로의 강점과 특징을 잘 이해하며 함께 성장해 나가고 있습니다. 이번 리팩토링도 그런 팀워크 덕분에 가능했던 작업이었어요.

데일리 미팅: 서로의 발맞춤 👣

리팩토링은 단기간에 끝나는 작업이 아니죠. 특히 저희는 운영 업무와 프로젝트 업무가 동시에 쏟아지는 환경에서 일하고 있어요. 그래서 팀원 간의 이해도를 높이고, 꾸준히 발맞춰 나가기 위해 데일리 미팅을 시작했답니다.

매일 오전 10시 10분, 텐텐미팅이라는 이름으로 각자 오늘 할 일을 간단히 공유하는 시간을 가지기 시작했어요. 처음엔 다들 조금 어색하고 딱딱한 분위기였지만, 금방 팀 고유의 색깔을 찾았습니다. 😊

특히 기분점수를 도입한 것이 데일리를 더 특별하게 만들어줬어요. 기분 점수는 0~10점 사이로 본인의 기분을 숫자로 표현하고, 그 이유를 간단히 공유하는 건데요. “오늘 기분은 4점이에요! 어제 잠을 설쳤거든요.”라든지, “10점입니다! 이유는 없어요!” 같은 이야기들이 자연스럽게 오가며 팀원들 간의 이해도가 높아졌습니다.

이 점수는 단순히 분위기를 부드럽게 만드는 것뿐만 아니라, 서로의 업무 스타일을 파악하는 데도 큰 도움이 됐어요. 아침에 집중력이 높은 사람, 오후에 더 능률이 오르는 사람, 혹은 꾸준히 “10점”을 외치는 팀원 덕분에 웃음이 끊이지 않았답니다. 😆

스터디: 함께 배우며 성장하기 📖

데일리 미팅으로 분위기가 한층 부드러워졌다면 리팩토링 스터디 는 팀의 기술적 이해도를 맞추는 데 중요한 역할을 했어요. 저희는 마틴 파울러의 《리팩터링 2판》을 함께 읽으며 전시 파트의 특성에 맞는 실질적인 방안을 논의했어요.

매일 30페이지씩 읽고, 정해진 시간에 모여 “우리 프로젝트에 어떻게 적용할 수 있을까?”를 고민했죠. 책 속의 예제 코드와 원칙들은 저희의 상황과 꼭 맞지는 않았지만, 그런 한계를 인정하면서도 “우리가 가져갈 것”과 “그냥 참고만 할 것”을 명확히 구분할 수 있었어요. 스터디를 진행하며 나온 아이디어들은 리팩토링 설계의 기반이 되었고, 팀원 간의 기술적 이해도 차이를 줄이는 데 큰 도움이 되었답니다.

Mob Programming: 모두가 하나로 🤲

저희 팀은 기존에도 페어 프로그래밍을 자주 활용했지만, 이번 리팩토링에서는 팀 전체가 참여하는 Mob Programming 방식을 도입했어요. Mob Programming을 도입한 이유는 단순했습니다. 기존 프로젝트 구조가 복잡하고 리팩토링 범위가 넓다 보니 한두 명이 모든 걸 이해하기 어려운 상황이었어요. 팀 전체가 함께 참여하면서 문제를 빠르게 파악하고 설계 변경의 방향성을 정리할 필요가 있었죠.

Mob Programming의 장점

1. 빠른 피드백 드라이버가 코드를 작성하는 동안 옵저버들이 바로 리뷰를 진행하면서 실시간으로 피드백을 주고받을 수 있었습니다. 덕분에 버그를 초기에 발견하거나 설계 방향을 조정하는 데 큰 도움이 됐어요.
2. 팀 전체의 이해도 상승 전시 업무 경험이 적은 팀원도 Mob Programming 과정에 참여하면서 자연스럽게 프로젝트의 큰 그림을 이해할 수 있었습니다. 특히 복잡한 A/B 테스트 설계 변경에서는 팀원 전체가 내용을 공유하고 합의를 이끌어내는 것이 필수적이었어요.
3. 코드 품질 향상 여러 명이 동시에 코드를 리뷰하고 의견을 나누면서, 코드 품질이 눈에 띄게 좋아졌습니다. 단순히 코드가 작동하는 데 그치지 않고, 더 깔끔하고 유지보수하기 쉬운 방향으로 개선할 수 있었죠. 코드 품질이 높아지니 서비스 퀄리티도 자연스럽게 향상되었습니다. 실제로 이 과정을 통해 디버깅 시간이 줄어들고, 새로운 기능을 추가하거나 변경할 때도 훨씬 효율적이라는 것을 느낄 수 있었습니다.

처음에는 “여러 사람이 한 번에 작업하면 시간이 더 오래 걸리지 않을까?”라는 우려가 있었습니다. 하지만 작업 시간을 더 길게 보았을 때 Mob Programming이 가진 장점들이 더 컸어요. 특히 리팩토링처럼 전체 구조를 바꾸는 작업에서는 팀원 모두의 합의와 이해가 중요하기 때문에 의사소통 시간을 절약하는 효과가 크게 작용했답니다. 😊

스프린트와 회고: 꾸준함의 힘 📈

리팩토링은 내부 과제라 외부 프로젝트와 우선순위를 조율하는 게 중요했어요. 그래서 저희는 스프린트를 도입해 일주일 단위로 작업 계획을 세우고 진행 상황을 점검했습니다.

그리고 한 달에 한 번씩 회고 를 진행하며 Keep, Problem, Try, Thanks to 네 가지 항목으로 서로의 피드백을 공유했어요. 특히 Thanks to 코너에서 팀원들 간의 고마움을 나누며 더 끈끈한 팀워크를 만들 수 있었습니다.

생생한 리팩토링 후기 🤓

왼쪽부터 티모, 웨이드, 필립, 에이버리, 시나몬

마지막으로 팀원들의 리팩토링 후기를 안 들어볼 수 없겠죠?

• 필립 이번 리팩토링을 진행하면서, 기존 코드의 복잡성과 A/B 테스트의 누적으로 인해 유지보수가 예상보다 훨씬 어려워질 수 있다는 점을 알게 되었습니다. 기존에는 A/B 테스트를 위해 여러 실험 로직이 코드 곳곳에 포함되어 있었고, 실험이 종료된 이후에도 정리하기가 쉽지 않았습니다. 이를 해결하기 위해 실험 로직을 분리하고, 모듈화하여 재사용성을 높이는 방향으로 구조를 개선 하였습니다. 작업을 진행하며 가장 크게 와닿았던 부분은 기능을 유지하면서 점진적으로 리팩토링하는 것이 중요하다 는 점이었습니다. 한 번에 모든 코드를 변경하려 하면 리스크가 커지고, 기존 기능에 예상치 못한 영향을 줄 수 있기 때문에 점진적인 개선이 필요하다는 것을 다시 한번 깨달았습니다. 리팩토링 이후에는 실험이 종료된 후 코드 정리가 훨씬 용이해졌고, 새로운 전시 방식이 추가될 때 기존 코드에 미치는 영향을 최소화할 수 있었습니다. 무엇보다도, 앞으로 더욱 명확하고 유지보수하기 쉬운 구조를 만들 수 있는 기반을 마련했다는 점이 가장 큰 성과 라고 생각합니다. 이번 경험을 통해, 초기 설계 단계에서부터 실험 종료 후의 코드 정리까지 고려하는 것이 중요하다 는 점을 배우게 되었습니다. 리팩토링은 단순한 코드 개선이 아니라, 더 유연하고 확장 가능한 구조를 만들어 가는 과정이라는 점을 다시 한번 실감할 수 있었습니다. 앞으로도 이러한 고민을 바탕으로 더욱 효율적인 구조를 만들어 나가야겠다는 다짐을 하게 된 프로젝트였습니다.
• 에이버리 미래의 작업자들이 과거의 원리금을 상환하느라 많이 고생할 거라는 생각을 하게 되었다. 가능하면 분기별로 정리를 하거나 정 안되도 1년에 한번은 반드시 정리를 해나가는 게 해결책 중 하나라는 생각을 하게 되었다. 여러 작업을 병행하면서 진행하다보니 이 작업에 오롯이 집중하기는 어려웠다. 그러다보니 작업기간이 길어져서 조금은 지치게 되었던 것 같다. 따라서, 생각날 때마다 정리를 하거나 작업을 못 하면 백로그로 미래의 작업자가 파악할 수 있게 내용 기재해놓고 관리를 하면서 해결해나가는 프로세스가 필요한 것 같다.
• 웨이드 규모가 작지만은 않은 프로젝트를 유지보수하면서 느꼈던 불편함과 어려움을 하나씩 리팩토링해 나가며, 운영 이슈에 대한 대처가 점차 수월해진다는 점을 크게 체감할 수 있었습니다. 특히 테스트 코드의 중요성을 깊이 깨달았고, 한 번 작성해둔 테스트 코드가 유지보수에 얼마나 큰 도움이 되는지 배웠습니다. 전반적인 리팩토링 과정을 통해 프로젝트의 흐름과 로직을 다시 머릿속에 정리할 수 있었고, 덕분에 이슈를 빠르게 이해하고 대응할 수 있었습니다. 또한, 함께 작업한 젊은 개발자들의 뛰어난 실력에 감탄하며, 끊임없이 공부해야 한다는 다짐도 하게 되었습니다. 이와 같은 레거시 프로젝트 리팩토링 경험은 현재 진행 중인 프로젝트에도 많은 영향을 주고 있습니다. 처음 코드를 작성할 때부터 품질을 고려하게 되었고, 향후 유지보수가 필요할 부분에 이번 경험에서 얻은 기술과 방법을 미리 적용하면서, 기능뿐 아니라 코드의 품질까지 챙기는 태도를 가지게 되었습니다.
• 시나몬 자세히 모르고있던 데이터 노출 프로세스를 리팩토링 과정에서 익히게 됐다. 생각보다 노출 프로세스는 더 깊었고 간단한 구조로 풀기 어려웠다. 그래도 여러 의견이 모여서 괜찮은 구조가 만들어졌다고 생각한다. 간단하진 않을 수 있지만, 중요한 A/B를 신속하고 사이드이펙트 없게 풀어낼 수 있어졌다. 하지만 현재는 제휴점 노출에서만 리팩토링 구조가 포함되어있다. 언제가 될진 모르지만 추후에 제휴점 상위데이터로 쓰이는 것들도 확장이 가능한 구조로 변경할 수 있으면 좋을 것 같다. 그때 다시 앱전시 전체 구조를 변경해보고싶다. 지금은 일시적 중복을 피하기위해서 모두 분리해두었지만, 과도기가 지났을 때는 정말 변경되지 않는 클래스를 구분할 수 있게 될 것이라고 믿는다. 최종적으로 의미있는 중복클래스와 분리되어야 하는 역할을 더 상세하게 나누고싶다. 그리고 이번 리팩토링 과정에서는 기여도가 낮았다. 아쉽다…. 열정 회복 필요
• 티모 리팩토링을 진행하면서 스스로 많이 성장했다는 느낌을 받았습니다. 특히, 팀원들과 함께하지 않았다면 이렇게까지 개선하기 어려웠을 것 같아요. 정말 뜻깊은 경험이었고, 기억에 남는 순간도 많았습니다. 그중에서도 설계 단계가 가장 인상 깊었는데요. 각자 프로젝트를 바라보는 관점과 이해도가 달라 다양한 의견이 나왔고, 이를 조율하며 같은 목표를 향해 나아가는 팀이라는 느낌을 강하게 받았습니다. 그런 과정이 든든하면서도 즐거웠습니다. Thanks to 전시파트장으로서 많은 부담을 안고 계셨을 필립 ! 필립의 폭넓은 이해도와 기술적 노하우 덕분에 설계 단계부터 PoC 버전 적용까지 무사히 마칠 수 있었습니다. 문제가 생겼을 때도 늘 차분하게 상황을 진정시켜 주셔서, 더 빠르게 해결할 수 있었다고 생각해요. 항상 감사합니다. 😆 그리고 전시 A/B 테스트의 기초를 마련해주신 히어로! 히어로가 기초를 다져주지 않았다면, 훨씬 복잡한 스파게티 코드 지옥에 빠졌을지도 몰라요. 담당 업무가 아님에도 늘 관심 가져주시고, 해결책을 제시해주셔서 정말 감사해요. 마지막으로 우리 팀원분들, 물론 아직 개선해야 할 점도 있고, PoC 버전 적용까지 해결해야 할 과제도 남아 있지만, 지치지 않고 끝까지 잘 마무리할 수 있기를 바랍니다! 🥰

마무리하며

리팩토링은 단순히 코드를 고치는 작업이 아니라, 팀의 협업과 성장 그 자체를 보여주는 과정이었습니다. 이번 프로젝트를 통해 저희는 서로의 아이디어를 더 깊이 이해하고, 복잡한 문제를 함께 풀어가는 방법을 배울 수 있었어요. 비록 모든 과정을 순탄하게 넘긴 것은 아니지만, 그만큼 더 많은 것을 배우고 한 단계 성장했다고 느낍니다.

앞으로도 저희 팀은 더 나은 코드와 서비스를 만들기 위해 계속 새로운 방법을 고민하고 도전할 계획이에요. 이번 리팩토링에서 얻은 경험과 교훈을 바탕으로 앞으로는 더 효율적이고 유연한 개발 환경을 만들어갈 수 있을 거라 믿습니다. 저희 팀이 걸어가는 여정을 함께 지켜봐 주세요! 긴 글 읽어주셔서 감사합니다! 🙇‍♂️