Jins' Dev Inside

SOA(Software Oriented Architecture) 란, 2000년대 초반부터 IT 업계 전반에 걸쳐 녹아든 IT System 의 패러다임이다.

고전의 Client-Server Architecture 에서 EJB 로 대표되는 n-Tier Model Architecture 로 진화한 웹 아키텍쳐는 2000년대 이후부터 비즈니스 요구사항에 발빠르게 대처하기 위한 구조로 Service-Oriented Architecture 라는 아키텍쳐로 진화한다.

SOA 란, 그전까지의 Application 의 Massive 한 기능들을 비즈니스적인 용도로 분류하고 기능 단위로 묶어서 하나의 표준 Interface 를 통해 각각을 "서비스" 로써 조합하는 Software Architecture 이다.

IT 업계의 요구사항이 많아지고 변화가 빨라짐에 따라 이에 대처하기 위해 나타난 Architecture 이고, 구성요소를 3가지로 분류한다.

1. Service Consumer - 서비스의 사용자. 사용자는 실제 클라이언트(End-User) 또는 다른 서비스가 될 수 있다.

2. Service Provider - 서비스 사용자에 요청에 맞는 서비스를 제공. Provider 는 다른 Service 의 Consumer 가 될 수도 있다.

3. Service Registry - 서비스의 정보를 저장한다. Provider 가 Registry 를 통해 Consumer 에게 서비스를 제공한다.

여기서 중요한건 Service Provider 와 Service Consumer 로, 이들은 실제 서비스의 유저 뿐 아니라 소프트웨어 아키텍처 내부의 "모듈" 도 대상이 될 수 있다. 

즉, SOA 는 비즈니스적으로 구분된 Service 들을 느슨하게 연결하며, 각 컴포넌트를 독립적으로 운용하여 조립이 가능하게끔 한다.

일반적으로 Service 를 위해 서비스 기능별로 모듈을 분리하고, 각 모듈이 다른 모듈과 상호작용할 수 있도록 만들어진 Architecture 를 SOA 라고 이해하면 된다.

여기까지 이해했으면 떠오르는 최근의 Architecture 모델이 있을 수 있다.

바로 Micro Service Architecture(MSA) 이다.

Micro Service Architecture 역시 각 서비스를 독립적으로 운용하며 서비스들을 조합하여 End User 에게 서비스를 제공하는 형태로 이루어진다. 그렇다면 이는 SOA 와 같은 아키텍처인가?

결론부터 말하자면, Micro Service Architecture 는 SOA 의 부분집합이라고 할 수 있다.

정확히는 SOA 는 패러다임이며, 그를 위한 Architecture 의 초안이고, Micro Service Architecture 는 SOA 의 패러다임을 따르되, 그 아키텍처를 따르지 않는다.

SOA 와 MSA 의 차이점

1. SOA 는 모듈의 의존성은 줄이되 모듈 내에서 공유할 수 있는건 최대한 공유하는 정책을 사용한다.

반면, MSA 는 가능한 공유하지 않고 모듈들이 독립적으로 운용될 수 있도록 아키텍처를 디자인 한다.

2. SOA 는 서비스의 Flow 를 유지하려하지만, MSA 는 Flow 의 구별을 요구한다.

가령, 서비스 내에서 결제를 하고자 할때, SOA 는 관련된 루틴을 수행하여 결제를 지원함으로써, 유저에게 제공해주는 "서비스" 를 1차 목적으로 한다.

반면, MSA 는 유저에게 관련된 루틴과 결제 루틴을 별도로 이용하게끔 한다. 즉 서비스 내의 독립이 아닌 독립된 서비스를 지향한다.

그렇다보니 SOA 아키텍처는 대게 어느정도 업격한 Protocol 과 Message 체계를 운용하게 되고, MSA 의 경우 별도의 체계가 없이 경량화된 프로토콜을 통해 운용되게 된다.

3. SOA 는 서비스들의 재사용에 중점을 두지만 MSA 는 서비스들의 독립을 추구한다.

이는 블로그 내 다른 포스팅에서 언급한 적 있는 Monolithic Architecture 와 유사한 부분으로, SOA 는 MSA 에 비해 보다 Monolithic Architecture 에 가깝다.

(참조 : https://jins-dev.tistory.com/entry/%EC%A0%84%ED%86%B5%EC%9D%98-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EB%AA%A8%EB%8D%B8-%EB%AA%A8%EB%86%80%EB%A6%AC%EC%8B%9DMonolithic-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98)

아키텍처를 디자인하는 일은 늘 어려운 일이고, 실무에서의 경험을 상당히 요하는 일이다.

아키텍처의 디자인과 이해를 위해서는 최신 트렌드 뿐 아니라 과거의 모델까지도 숙지해두는 것이 필요하겠다.

좀 더 자세한 설명은 다음 링크를 참조해보자.

https://dzone.com/articles/microservices-vs-soa-2

https://www.bmc.com/blogs/microservices-vs-soa-whats-difference/

실무에서 bit 연산을 사용할 때에는 주로 플래그 값들을 미리 정의해놓고 마스킹 하는 용도로 사용하지만,

알고리즘 문제를 풀 때에는 조합을 만들어낼 때에나, check 배열 또는 인덱스 값을 값싸게 저장하기 위한 용도로 많이 사용하게 된다.

그래서 자주 사용하지 않으면 헷갈리기 쉬운 bit 연산들을 몇가지 정리해보았다.

주로 사용되는 연산은 위와 같고, 해당 연산만 이용해도 비트 연산을 이용한 알고리즘의 상당수는 해결할 수 있다.

자주 쓰지않는 내용이라 까먹기 쉽지만, 필요할 때 쓸 수 있도록 잘 익혀두자.

Javascript 의 기본적인 내용이자 Scope 와 관련된 중요한 개념이다.

Javascript 는 많은 프로그래밍 언어와 다르게 Block-level Scope 가 아닌 Function-level Scope 를 따른다.

Block-level Scope 가 모든 코드 블록의 유효성 판단을 선언된 코드 블록({}) 단위로 하는 데 반면, Function-level Scope 는 함수 단위로 Scope 의 기준을 잡는다. 

Function-level Scope 의 중요한 특징은, 함수 내부에서 봤을 때 함수 외부는 Nested Scope 의 Outer function 이라 할지라도 Global 영역으로 취급된다는 점이다.

Hoisting 이란, Javascript 내에서 해당 변수 또는 함수의 "선언" 을 끌어올린다는 점이다.

여기서 주의할 점은 함수의 선언과 변수의 선언이 조금 다르다는 점이다.

위의 경우에 inner1 함수의 경우 정상적으로 호출이 된다. 해당 함수의 선언이 아래 있음에도 호출될 수 있는 이유는 해당 함수가 Hoisting 되기 때문이다.

반면 inner2 함수의 경우 Hoisting 되지 않는다. 그 이유는 변수의 선언과 함수의 선언이 다른 의미를 지니기 때문이다.

위와 같이 함수의 선언은 단순히 함수를 정의하면 되는데 반해 변수의 선언은 선언과 할당이 다르다.

이 때 의문이 생길 수 있다.

inner2 예제의 경우 "변수를 선언하고 함수를 할당한 것"이 아닌가?

정답은 "아니다." 이다. 정확히 예제의 inner2 의 경우 함수리터럴을 할당했다고 표현한다. 

함수 리터럴이란 함수의 이름없이 구현체만 연결시키는 방식으로, 이 경우에 Javascript Engine 은 이를 호이스팅시키지 않는다.