들어가기 앞서
필자는 소프트웨어공학과를 전공하였지만, 아키텍쳐에 대하여 자세히 알지 못한다..
비전공자와 거의 같은 수준..
하지만서도.. 포기란 없다..
아니 반강제로 리뷰를 해야한다;
아자아자 아자뵤~!~~@~@~#~#~#@!@!@!@!@!@#$
Introduction
소프트웨어 기반 시스템(Software-reliant systems)은, 요구사항 충족 및 신기술 탑재 등으로 인하여 크기와 복잡성이 굉장히 빠르게 증하고 있다.
결과적으로는 소프트웨어의 구조가 더 복잡해지고 느려지면서 코스트가 높아졌다.
Software-reliant systems이 무엇인가?
단순하게 생각하자. 소프트웨어에 크~게 의존하는 시스템이라고 보자.
대표적인 예가 뭘까?
GPT씨는 싸가지는 없지만 어리바리 신입사원으로 생각하면 봐줄만 하기 때문에, 물어보도록 하자.
어.. 의존을.. 좀 많이하긴 하겠네.. 흠.. 좀 다른 것 같은데.. 모르겠다. 논문을 더 확실하게 읽어보자.
복잡성 증가로 인하여 모듈화( isolating a collection of functionalities 기능 격리..? 모듈화밖에 생각이 안난다.)가 어렵고 새로운 버전으로 변경하는 것이 어렵다.
하지만 대규모 단일 시스템(legacy monoliths)을 작은 부분으로 분할하여 별도로 배포 가능하고, 확장 가능하며, 발전 가능한 단위들(ex microservices)을 만들 필요성이 있다.
물론 재사용성과 새로운 기능을 및 버전으로 올리는 즉 확장성을 고려하면 모듈화하는 것이 중요하긴 하다.
객체지향 언어에서나 많은 언어에서 모듈화의 중요성을 항상 말하고 있긴 하죠.
근데 여기서 대규모 단일 시스템의 예시는 뭐가 있을까?
아니 분산 시스템이 아닌건지 아니면 모듈화 되어있지 않은 통짜 코딩인건지.. 예시가 뭘까?
출처 : https://siahn95.tistory.com/55?category=922742
[Software Architecture] MSA란? - (1) 정의, 역사, 적용 사례, Monolithic System
몇 주 전, 회사에서 MSA에 대한 교육을 들었다. 굉장히 흥미로운 내용이기도 했고, 최근 국내 기업들에서도 MSA 도입 사례가 많아지는 것 같아 공부한 내용을 정리할 겸 글을 남겨본다. 총 두 개의
siahn95.tistory.com
이분 것을 보고 이해했다 이분은... 최고야.. 천재야.. 짜릿해..
간단하게 말하면 이것이다.
이거이거 3개의 기능을 다른 곳에서 수행하려면 똑같은 코드를 계속 반복하여 사용해야 한다.
하지만서도 이런 기능을 다음과 같이 변환하여 준다면?
이렇게 기능별로 나누는 것을 더 작게 나누어 하나의 기능을 하는 서비스 단위로 쪼갠 구조가 Microservices Architecture이며 단위가 Microservices 인 것!
얘 때문에 따라오는 장점이 많으니, 참조한 링크로 가서 배우고 오자!
Agile 소프트웨어 개발 프로세스에는 품질을 향상시키기 위한 접근 방식으로 refactoring을 선호한다.
하지만, 소규모의 지역적 refactoring은 시간이 지남에 따라 축적되는 구조적 및 복잡성 문제를 아키텍처 수준에서 해결하지 못하며, 이로 인해 관리할 수 없는 Technical Debt가 발생한다.
이러한 구조적 변화는 비용이 많이 들고, 복잡하는 등 다양한 문제가 있다.
Agile 소프트웨어 기억하는가? 폭포수와는 반대이다.
즉 하나부터 열까지 계획해서 진행하는 것이 아니라, 프로토타입을 제작하여 소비자에게 제공한 후 피드백을 즉각적으로 수용하는 것이다;
따라서 신속한 반복 작업을 통해 실제 작동 가능한 소프트웨어를 개발할 수 있다.
이러한 애자일에는 refactoring 방식이 선호한다. 애초에 refactoring이 뭘까?
코드의 기능을 바꾸지 않으면서 코드의 가독성을 높이고 수정하기 쉽게 만드는 과정이라고 한다.
예시로 들면 ?
중복 코드를 제거하기 위하여 클래스 계층 구조를 변경하는 것,
유사한 코드 영역을 프로그램 라이브러리에서 정의하여 메소드 호출로 대체하는 것,
속성과 메소드를 정리하고 이름을 변경하는 것
Agile이 왜 refactoring을 선호할까?
G사원!
흠.. 그니까 개발자 입장에서는 계속 피드백 받고 수용하려면 코드가 깔끔한게 좋으니 코드를 refactoring해나가면서 가독성도 키워주고 하니까 선호하는 거구나? .. 흠..
소규모로 refactoring이 일어나면, 작은 함수에서 다른 곳으로 200번 이동하는 것 같이 그리고 작은 함수에서 구조가 계속 바뀌어 다른 곳에도 영향을 끼칠 수 있는 등으로 인하여 발생하는 문제가 있는 것 같다.
따라서 애자일 방식이기에 단기적인 해결책을 선택함으로써 발생하는, 장기적인 추가 작업의 비용이 드는 Technical Debt이 발생하는 것..
Today~ 소프트웨어 설계자와 개발자는 작업에 리팩토링을 통합하는 데에 제한을 받아 시간이 오래 걸린다.
이 논문에서 메인 문제다.
리팩토링 활동에 평균 1,500일 이상!!!!!!!!!!!!!!!!!!!!!!!!!!!의 일수가 소요되었다고 보고되었다고 한다..
진짜 장기적인 추가 작업( Technical Debt )이 드는 군..
따라서 해당 논문은 refactoring 시간을 줄이기 위하여, 소프트웨어 종속성에서 refactoring을 사용해 기능을 분리하는 자동화된 방식을 이용한다.
소프트웨어를 기능별로 잘 분할하고, 컨테이너화 하여 DevOps를 촉진하고 종속성을 제거한다.
하지만 이런 변경을 위해서는 개발자가 먼저 소프트웨어의 특정 부분을 해당 컨텍스트에서 분리시켜야 하는데, 이 때 이 논문은 검색 기반 소프트웨어 엔지니어링과 정적 코드 분석 및 refactoring을 결합하여 문제를 해결한다.
ㅁ..머?
머머머지? 모르겠어.. 머지?
자자 그니까..
종속성을 없애려면 기능별로 분할을 해야하고....
분할하려면 개발자가 종속된 부분을 분리시켜야 하는데..
이걸 자동화 하겠다..
근데 검색기반 뭐시깽이와.. 정적코드 뭐 리팩토링 뭐시기를 이용한다는 얘기인가..?
논문을 읽고 다시 오면 이해가 되지 않을까.. 하는 부푼 마음으로 넘어가야겠다 ㅋ
참고
[1] https://rae-gi.tistory.com/27
[2] https://jy-doromi.tistory.com/59