2022년 인프콘 후기 - #6 (레거시 시스템) 개편의 기술

Joshua_Kim·2022년 8월 27일
2

2022년 인프콘 회고

목록 보기
7/8
post-custom-banner

🌱 서론

  • 📣 스피커 : 우아한형제들 권용근

  • 세션을 선택한 이유
    - 엄청난 트래픽이 발생하는 배달 플랫폼에서 어떻게 레거시를 다루었고 개편했는지 매우 궁금했다.
    - 또한 레거시 개편은 개발자의 숙명이기에 많은 인사이트를 기대하며 세션에 참여했다.

✍🏻 세션 정리

👉🏻 서론, 레거시 개편은 왜 일어나는가?

  • 레거시 시스템이란?
    - 낡은 시스템 📟
    - 더이상 쓰이지 않더라도, 현대의 기술에 영향을 주는 경우도 포함된다.

  • 레거시 시스템의 3가지 유형
    - 시간이 지나면서 현재는 비주류가 되는 기술
    - 현재는 성능이 부족한 시스템
    - 새로운 요구사항에 대응하기 어려운 시스템

  • 레거시의 개편은 어떤 기준으로 결정을 해야하는가?
    - 가장 중요한 것은 가성비, 즉 투자대비 효율이 좋아야 한다. 💰
    - 빅뱅 or 점진적 개편 둘 중 하나를 선택하여 레거시 개편이 이루어 진다.

  • 레거시 개편의 목표
    - 서비스를 지속, 성장시키기 위함이 목표가 되어야 한다.
    - 적절한 시기의 개편은 필수적이다.

💡 개편의 기술 #1 의존성을 한 방향으로 정리하라

  • 스파게티 의존성을 주의할 것 🍝
    - 객체의 의존성이 복잡하게 되어있으면 민감도가 높아진다.
    - 민감도가 높을수록 한 부분을 수정했을 때 사이드 이펙트를 예측할 수 없어진다.
    - 코드 내부에서 의존성을 참조하게 된다면 매우 어려운 코드 개편이 될 수 있으므로 유의해야한다.

  • 스파게티 코드는 왜 발생하는가?
    - 새로운 기능을 개발 할 때 재사용성을 남발하게 되어 무지성 의존으로 많이 발생한다.

  • 스파게티코드는 어떻게 정리할 수 있는가?
    - 의존성의 방향을 명확히 정할 것 🔁
    - 서비스 레이어 (계층화) 를 확실히 할 것
    - 의존성의 깊이로 계층을 나누는 것이 중요하다.
    - 계층이 나누어지면 방향성을 판단하기 쉬워진다.
    - 같은 층을 의존하는 것도 역방향에 해당하므로 판단 기준이 명확해진다.

  • 의존성을 한 방향으로 정리하여 계층화 시킴으로 써 사이드 이펙트 추적에 매우 유리해질 수 있다.

💡 개편의 기술 #2 변경 대상에 대한 경계를 나눈다.

  • 의존성의 깊이로 나눠진 계층에 책임과 역할을 재정의 한다. 🔧

  • 개편을 진행 하면서 따로 다루어야 할 계층이 있다면 우선 아예 따로 빼놓는 것이 개편에 유리하다.
    - 그 후에 계층의 책임과 역할에 의해 분리를 시도해 본다.

  • 책임과 역할을 명백히 한다는 것은, 변경 범위에 대한 가시성을 확보 했다는 것을 의미한다.

  • #1 에서 나눈 의존성별 계층에도 무한히 신뢰하지 말고 계속 역할과 책임이 무엇인지 지속적으로 질문하고 고민하며 🤔 리팩토링하는 것이 중요하다.

💡 개편의 기술 #3 테스트를 확보한다.

  • 계층별 유닛테스트를 진행하는 것은 쉽게 의존성 파악을 가능하게 한다.

  • 안정된 테스트는 후에 코드 변경에 있어서 안정적으로 변경해도 된다는 심리적 안정감을 준다.

  • 유지보수하기 좋은 소프트웨어를 만들기 위한 노력에 의해 생성된 레거시 변경 규칙은 테스트코드로 재확인 가능하다.

💡 개편의 기술 #4 프로젝트 가시성 확보

  • 큰 문제를 크게 보면 한 눈에 보이지 않는다.
    - 작은 문제로 쪼개서 하나씩 풀어가도록 한다.
    - 해야할 테스크들을 가시화 시켜서 조각조각 내는 것이 중요하다.

  • 세부적으로 잘게 쪼개면 정확한 일정 예측이 가능해진다.
    - 테스크들을 문서화 하는것도 매우 중요하다. 📃

  • 개편은 항상 리스크를 가지고 있으므로 일정에 대한 명확히 세분화된 리스크별 방안이 필요하다.
    - 진행상황에 대한 공유가 수월해지므로 리스크 대응에 유리하다.

💡 개편의 기술 #5 도메인 이해 공유

  • 개발자간의 도메인 이해 수준의 차이는 분명히 존재한다.
    - 도메인 이해에 큰 비용이 발생 할 수 있다.
    - 도메인 이해가 낮은 개발자는 의사결정 과정 참여에 어려워진다.
    - 도메인 이해가 높은 개발자는 프로젝트 진행에 부담을 가지게 된다.
    - 커뮤니케이션 비용이 또 따로 발생 할 수 있다.

  • 이벤트 스토밍
    - 소프트웨어 프로그램 도메인에서 무슨일이 일어나고 있는지 빠르게 알아내기 위한 워크샵 기반 기법

  • 어떠한 방법론을 선택하든 개발자간의 도메인 이해도의 공유는 매우 중요하다. 🔧

💡 개편의 기술 #6 변화를 측정한다.

  • 측정을 통해 불확실성의 정도를 낮출 수 있다.

  • 어떤 것이 변하였고, 그 변화를 통해 어떤 사이드 이펙트가 생겼는지 측정하는 것이 매우 중요하다.

🔥 개인 소감

  • 의존성의 방향을 정하는 것은 현재 회사에서 진행하고 있는 프로젝트 아키텍처와도 매우 많이 맞물려 있다.

  • Gradle MultiModuleGit Submodule을 도입하여 진행하고 있는데, 개인적으로 실무에 직접적으로 많은 도움과 고민거리를 던져준, 그리고 정말 좋은 인사이트를 준 세션이었다.

  • 팀원들과 현재 진행하고 있는 도메인의 이해도의 공유도 진행해보고 싶다. 🤔

profile
인문학 하는 개발자 💻
post-custom-banner

0개의 댓글