- 낡은 시스템. 낡았다 현재는 비주류인 기술
- 트래픽도 늘어나고 성능적인 챌린징도 하다 보니까, 성능적으로 부족한 시스템.
- 과거의 요구사항에는 적합했지만, 현재의 요구사항에는 대응하기 어려운 시스템
- 현재는 비주류인 기술
- 개발자에겐 미안한 이야기지만, 개발자를 갈아내서, 시간을 더 들여서 해결할 수 있다.
- 현재 성능이 부족한 시스템
- 비용을 더 지불해서 (스케일 아웃, 업)
- 새로운 요구사항을 대응할 수 없으면?
- 새로운 시스템을 만들어서 개편 가능
- 투자자본수익률(ROI) - 가성비가 있어야 개편이 일어난다.
- 새로운 시스템 만들기, 사람 갈아넣기, 비용 더 지불하기와 같은...
- 시간, 비용, 인원
- 생명주기, 학습비용, 비즈니스, 지연, 채용, 퇴사, 리스크, 한계 등...
- 들어가는 비용 중에는 상당부분이 개발자가 측정이 가능하다.
- 개발자들만 알아차릴 수 있는 지표들은, 직접 푸시해서 설득을 할 필요도 있다.
- 어렵게 계산을 한 비용을, 결정권자들에게 푸시해서 결정이 있을건데, 이 비용 측정을 현재로만 하면 설득이 어렵다.
- 여기에 미래에 대한 시간을 포함시켜서 지표를 보아야 한다.
- 개편을 늦게하면 기존 대비에 비해 많은 비용을 쓰게 된다는 것을 알아내고 확인해야한다.
결론으로, 레거시 시스템 개편은 서비스를 지속, 성장 시키기 위해서 일어난다. (적당한 타이밍에) 개편은 서비스를 지속시키고 성장시키기 위해서 무조건 필요한데, 엄청 중요하다는 걸 말하고 싶었다.
로그인 > 목록 > 가게진입 > 주문 > 결제
개편 경험은 역순으로
결제 > 주문 > 가게진입 > 목록 > 로그인
- 결제 개편은 성능이 부족한 시스템이라
- 주문 개편은 현재는 성능이 부족한 시스템, 현재는 비주류인 기술이라서
- 가게진입 개편은 현재는 성능이 부족한 시스템, 현재는 비주류인 기술, 새로운 요구사항을 대응할 수 없는 시스템이라서
- 회원시스템 개편은 현재는 성능이 부족한 시스템, 현재는 비주류인 기술이라서
- 회원이라는 도메인과 인증이라는 도메인을 분리했다.
- 회원은 회원답게, 인증은 인증답게
스파게티 코드, 스파게티 의존성. 객체나 컴포넌트의 의존 참조 방향이 복잡하게 꼬여있어서 어려운 상황. 코드를 수정했을 때 사이드 이펙트 측정이 어렵다. 어디서 어떤 문제가 발생할지 여기저기 꼬여있기 때문에. 사이드 이펙트를 측정하기 어려운건 개편을 하기 무서운 상태.
스파게티 코드가 왜 발생을 했을까? 코드의 재사용성을 따라서, 기존의 객체에 있던 일인거 같다고 기존 객체의 코드를 그대로 재사용하게 된 것. 새로운 요구사항이 생기면 또 재사용을 하게 된 것. 어느새 스파게티 의존성이 만들어진다.
그럼 스파게티 의존성을 어떻게 풀어내는가? -> 의존성을 한 방향으로 -> 의존성의 방향을 결정하라. 계층이나 아키텍처가 정해지면 좋겠지만, 그게 어렵다면 의존의 깊이로 층을 형성해라. (패키지 분리를 하던지) 한 방향으로 결정을 할 떈, 같은 계층끼리 의존하는 것도 허용하면 안된다. 그렇게 되면 분명히 문제가 생긴다. 재사용하려는 코드가 있다고 하더라도 적절하게 분리를 해서 두 서비스가 모두 의존할 수 있는 계층에다가 옮겨서 작성을 해라. 의존성을 한 방향으로만 잘 관리를 해도 스파게티 코드를 피할 수 있게 된다. 그 상태에서 코드를 수정하게 되면 사이드이펙트가 어디서 발생할지 예측이 가능하게 된다.
책임과 역할이 제각각(의존 깊이의 끝이 다르다.)이면 안된다. 우리가 변경해야할 코드가 Repository에만 있었다면 DB, 영속계층에 관련된 개편이 진행된다고 예측이 가능하지만, COntroller, Service, Repository에 섞여있다면 파악이 어렵다. 변경 대상에 대한 경계를 나누면 솔루션이 된다.
패키지로 나눌 수도 있고, 모듈로 나눌 수도 있다. 나눠진 변경 대상은 하나의 게층으로 여겨버린다. 하나의 계층이 되면서 그 계층 내부에서 책임과 역할을 정의한다. 개편에서 다루어야할 계층을 확보해서, 명백하게 정의를 해보는 것. 그게 원래 소프트웨어에서 다루어야할 계층이었는데, 못했던걸 알게 되는 걸수도 있다. 계층을 확보한 후에 알맞지 않은 코드는 다른 패키지로 빼버리고, 다른 패키지에 넘어가있는 책임은 확보한 계층으로 끌어오는 식으로 책임과 역할을 명백히 그어내는 것.
이렇게 되면 변경 범위에 대한 가시성을 확보할 수 있게 된다.
의존성의 층(controller, service, repository)으로만 나누지말고, 이 패키지들을 역할과 책임으로 나눠보면 어떨까?
개편의 대상이 되는 계층보다, 한 단계 더 상위 계층의 테스트 코드나 테스트 커버리지를 챙겼으면 한다.
기존에 있던 테스트 케이스 재사용이 어려운 상황. 테스트 케이스 복사 시간도 부족함. 로컬에서 테스트 할 때 E2E 결과가 똑같이 나오는지 확인함. (JSON을 덤프떠서 함). 결국 실제 API의 요청비교 테스트 테스트는 원래 인터넷이 안돼도 돌아가야하지만, 이렇게까지도 할 수가 있었다. nGrinder를 이용해서 API를 계속 찌르면서 확인함. 테스트를 짤 시간이 없으니까.
테스트 케이스를 재사용 할 수 있는 상황! 근데 테스트 케이스가 없음! 이런 경우 블랙박스 E2E 테스트를 선택했음. 테스트 사이에서 어떤 일이 일어나는지는 모르겠고, 요청이랑 DB에 어떤 데이터가 잇는지만 믿고 테스트를 전부 실행해버리는 것.
무얼 얻었는가? 변경해도 괜찮다는 심리적 안정감
- 의존성을 한 방향으로: 정돈된 의존성
- 변경에 대한 경계 나누기: 책임과 역할이 명확한 계층과 객체
- 테스트: 안정감
이것들을 개편에만 적용해야하는가? 결국에는 유지보수하기 좋은 소프트웨어, 유지보수하기 좋은 설계를 만들기 위해서는 우리가 저런 것들을 항상 신경쓰면서 개발을 하면 좋을거 같다.
라면을 끓이는데 시간이 얼마나 걸릴거 같은가? "5분 일거 같은데?"
- 물을 끓인다 3분
- 면, 스프를 투입하고 5초
- 면을 익힌다. 3분 30초
"6분 35초"가 걸린다.
큰 문제를 작은 문제로 만들어 풀어나간다. 해야할 일들을 점점 작게 가시화. 이러면 실제 더 정확한 일정 예측이 가능해진다.
일정에 대해서 예측을 한다는 것은, 리스크를 더 잘 관리할 수 있게 된다는 큰 장점이 있다. 지라, 컨플루언스도 좋지만 엑셀 스프레드 시트를 통해서... 일정을 관리해서 좋은 점 같이 일하는 팀원들이 서로 무얼 하고 있는지, 다 알 수 있고 개인 일정 계획도 가능하고, 장기적인 프로젝트를 통해서 지쳐나갈 때, 우리가 어디까지 왔는지, 얼마만큼 더 하면 끝나는지 보여주는 이정표가 된다.
그리고 우리 구성원 뿐만 아니라 이해관계자들도 존재한다. 그 사람들이 프로젝트를 후원하기 좋아진다. 무얼하고 있는지, 어떤 일정이 있는지 명확하게 볼 수 있으므로. 해야할 일들을 가시화하여 문서화.
일정예측 & 일정 리스크 관리. 진행상화 공유. 이해관계자를 설득하기도 원활하고 이해 관계자가 후원하기 원활
구성원들 간의 도메인 이해 수준의 차이가 생길 수 밖에 없다. 도메인에 대한 이해관계가 다른 사람들이 모이면, 같은 요구사항을 보더라도 다른 해석을 할 수 밖에 없다. 이럴 때 같이 일을 하는 과정에서 커뮤니케이션 비용을 줄이려면 어떻게 해야할까? 이벤트 스토밍. DDD, 전술적 설계
꼭 이벤트 스토밍이 아니더라도, 어쨌거나 도메인을 공유하는 시간을 별도로 자주 가져라.
측정이라는 것은 무엇에 대한 불확실 성에 대한 정도를 낮추는 행위
무엇이든 측정하고 저장하고 공유해라.
트레이드 오프, 도전. 키워드를 기억하자.
어떠한 데이터를 보고, 나쁘다 좋다만 생각하지말고 그 나쁜것의 트레이드 오프로 어떤게 좋아졌는가? 좋은 것의 트레이드 오프로 어떤게 나빠졌는가? 무얼 도전했는가? 등을 확인해보면 좋을 것. 그리고 꼭 공유할 것.