[목차]
<aside>
💡 모든 토글을 열고 닫는 단축키
Windows : Ctrl + alt + t
Mac : ⌘ + ⌥ + t
</aside>
<aside> 🌐 우리는 지난 시간에, 소위 웹 어플리케이션이 어떠한 원리로 어떻게 동작하는지, 그 중에 웹서버(정확히는 Web Application Server)는 어떻게 동작하는지 아주 간략하게 알아봤습니다. 이번 시간에는 서버가 해주는 일을 조금 더 자세히 살펴보고, 스프링, 스프링부트에 대한 소개를 갖는 시간을 가져보면 좋을 것 같습니다.
</aside>
<aside> 🤔
</aside>
서비스 로직이 커져갈수록 연관된 데이터는 훨씬 더 많아지고, 처리해야 할 로직은 더 복잡해지고, 심지어는 이것들이 맞물려 프로그램의 복잡도는 기하급수적으로 올라갑니다. 특히 프로그램의 로직이 수정되어야 하거나 이미 동작하는 서버위에 새로운 기능을 추가하는건 사실상 불가능해지는 시점에 도달하게되고, 결국 실패를 인정하고 아예 서버나 프로그램을 새로 만드는 일도 심심치 않게 일어납니다.
그나마 다행인 점은, 우리의 선배 개발자들이 이와 같은 실패로 얻은 교훈이 헛되지 않게 많은 자료와 사례를 남겨두었고, 지금은 “~~패턴” 또는 “~~아키텍쳐로’ 불리우고 있습니다. 우리는 이러한 것들을 공부하는 것 만으로도 그들이 했었던 실수를 반복하지 않고 개인의 수천시간, 동료들의 수만시간을 아낄 수 있습니다.
소프트웨어 디자인 패턴(software design pattern)은 소프트웨어 공학의 소프트웨어 디자인에서 특정 문맥에서 공통적으로 발생하는 문제에 대해 재사용 가능한 해결책이다. 소스나 기계 코드로 바로 전환될수 있는 완성된 디자인은 아니며, 다른 상황에 맞게 사용될 수 있는 문제들을 해결하는데에 쓰이는 서술이나 템플릿이다. 디자인 패턴은 프로그래머가 어플리케이션이나 시스템을 디자인할 때 공통된 문제들을 해결하는데에 쓰이는 형식화 된 가장 좋은 관행이다.
Software Architecture Patterns
소프트웨어 아키텍처 패턴
<aside> 🤔 디자인 패턴을 공부하는 것 역시 매우 중요한 주제이지만, 자칫 너무 맹신하려고 들면 또 오히려 매우 큰 역효과를 마주한다고 합니다. 지금 당장은 더 중요한 배울거리가 많기도 하고 특정 패턴등을 마주 할 때 마다 확실히 이해하고 인지하고 넘어가는 정도의 공부가 지금은 가장 좋은 것 같습니다.
</aside>