Video: 개발자 필독 | 티어와 레이어 구분 #개발자개념장착
Channel: 코딩하는기술사
Duration: 5m 32s
Source: subtitle (auto, ko)
Transcript:
엔티어 아키텍처, 레이어드 아키텍처. 자, 이런 말 많이 들어보셨죠? 3티어 OSI7 레이어 클라이언트 서버. 자,이 티어하고 레이어의 차이가 무엇일까요? 오늘이 영상을 보시면 티어와 레이어이 둘을 확실히 구분하게 되실 겁니다. 어, 그리고 지금은이 쓰티어가 보편적인데요. 과거 한 때 투티어가 일반적이었던 시대가 있었습니다. 자, 첫 번째 티어가 무엇일까요? 자, 티어란 소프트웨어 시스템을 구성하는 물리적으로 분리된 계층. 자, 여기서 핵심은 물리적 분리입니다. 우리 보통 탑티어라는 말을 하죠. 그 티어하고 같은 겁니다. 자, 여기 보시면 클라이언트, 서버, 데이터베이스가 이렇게 물리적으로 분리되어 있죠. 자, 이런 구조가 쓰티어 아키텍처입니다. 그러면 레이어는 무엇일까요? 티어와 뭐가 다를까요? 자, 레이어는 소프트웨어 구성을 역과 책임에 따라서 논리적으로 나눈 구조를 말합니다. 앞서 티어는 물리적이었죠. 레이어는 논리적입니다. 자, 여기 보시면 프레젠테이션 레이어, 비즈니스 레이어, 데이터 엑세스 레이어. 자, 이렇게 하나의 서포트에 내에서 어, 논리적으로 나눈 형태를 레이어라고 합니다.

자, 티어와 레이어 비교입니다. 자, 원래 뜻은 비슷합니다. 어떤 층, 계층. 자, 핵심적인게 티어는 물리적 관점에서 분리, 레이어는 논리적 관점에서의 계층 분리.이 이 부분이 둘의 구분점입니다. 자, 그래서 물리적으로 떨어져 있기 때문에 다른 서버 프로세스, 네트워크 호출, 클라이언트 서버, 데이터베이스 이런 식으로 계층이 분리된 것을 티어라고 하고요. 같은 소프트웨 안에서 논리적으로 개층을 나눠서 어, 함수 호출 형태로 컨트롤러, 서비스, 리파지토리 이런 식으로 분리해서 서로 함수 호출 관계로 분리되는 것을 레이어라고 합니다. 자, 그렇지만이 티어와 레이어의 구분이 뭐 학문적으로 완전히 정립된 구분된 개념은 아닙니다. 학술적으로든 뭐 업계에서든 혼용해 사용하는 경우가 더 많습니다. 자, 지금은 쓰티어가 대세죠. 그러나 한때 투티어 시대가 있었습니다. 자, 투티어 펫 클라이언트 시대라고 했는데요. 1990년대부터 2000년대 초까지 비줄 베이직이나 델파이 파워빌드 같은 것으로 구현체를 만들었는데요. 클라이언트에서 데이터베이스로 다이렉트로 연결하는 구조였습니다.

그래서 PC에 설치형 데스크톱 프로그램으로 설치가 되어서 DB하고 직접 연동하는 구조. 투티어 형태의 어플리케이션이었죠. 그런데 투티어가 문제가 있었죠. 보완적인 문제. 유지보수 문제, 확장성 문제. 클라이언트가 DB하고 직접 연결이 되다 보니까 보완적인 문제가 있었죠. 그리고 업무 로직이 클라이언트에 다 있다 보니까 로직이 조금만 변경되어도 클라이언트에 다시 배포를 해야 됐죠. 그리고 확장성도 좋지가 않았습니다. 그래서 3티어가 등장했습니다. 90년대 후반에서 2000년대. 자, 3티어의 핵심은 클라이언트와 데이터베이스 사이에 어플리케이션 서버 개층이 추가된 것입니다. 어플리케이션 서버는 업무 로직을 담당하고 어 DB 커넥션 풀을 중앙에서 관리하고 트랜잭션을 관리하고 클라이언트와 DB 사이에 보완과 기능의 경계 역할을 했었죠. 자, CS 기반 쓰티어가 특시도 호바, 컴플러스, 초기, EJB 같은 구현체가 있었고요. 웹 기반의 쓰리티어는 웹 로직, 웹스피어 같은 것들이 있었습니다. 그 이후로 지금까지 이어지는 모바일 웹 모바일 시대입니다.

자, 웹 모바일 시대 와설은 구조가 바뀌었습니다. 과거 펫 클라이언트였던게 브라우저로 클라이언트가 대부분 되면서 쓴 클라이언트가 됐죠. 그러나 한때 과도기적으로 리아 시대가 있었습니다. 액티브엑, 플래시, 자바 애플릭 같은 것으로 브라우저에서 많은 일을 하려고 시도를 한 것들이 많았죠. 그러나 2010년에 와서 HTML 5가 표준화되면서 액티브 X가 퇴출이 되고 브라우저가 진정한 틴 클라이언트로 자리 매음을 했죠. 그리고 스마트폰 앱도 클라이언트의 한 형태로 나오는 시대가 됐죠. 지금은 클라이언트와 서버가 레스트 API, 그래프 QL 같은 동신 기술로 거의 표준화가 되었죠. 그리고 지금은이 브라우저 프론트에서 데이터베이스로 직접 연결하는 것은 말이 안 되는 구조가 되었죠. 자, 그래서 현대 아키텍처를 엔티어 아키텍처라고 합니다. 클라이언트와 DB 사이에 어플리케이션 서버가 있고 그 사이에 캐시가 있을 수도 있고 MQ가 있을 수도 있습니다. 그래서 N티어라고 하고요. 3티어 이상으로 계층이 늘어날 수 있는 구조죠.

자, 그러나 티어가 늘어날수록 유연성, 복잡성이 늘어납니다. 적절한 수준의 구성이 중요합니다. 자, 그런데 요즘이 프론트 기술인 리액트에서 데이터베이스 수퍼 베이스로 마치 바로 연결하는 것처럼 보이죠? 투티어일까요? 자, 비록 코드는 리액트에서 마치 코리를 하는 것처럼 작성을 하지만 실제로는 중간에 어플리케이션 서버가 동작하는 것입니다. 그래서 리액트에서 데이터베이스로 바로 연결되는 것이 아니라 중간 계층을 이용하는 거죠. 결국 3티어 구조입니다. 자, 정리하겠습니다. 티어는 물리적 계층 분리. 레이어는 논리적 역할 분리. 과거 한 때 투티어 펫 클라트 시대가 있었습니다. 지금은 쓰티어가 대세고요. 요즘에는 N티어까지 확장을 하는 추세죠. 그리고 슈퍼 베이스로 연결하는 것은 투어가 아니다. 중간에 어플리케이션 서버가 있다. 자, 조금 더 생각해 볼까요? 마이크로소비스 아키텍처일까요? 그리고 코바 기컴은 사라지고 레스트 API가 살아남은 이유는 뭘까요? 그리고 파이어베이스, 슈퍼베이스 같은 바스 서비스, 백엔드 에저 서비스를 쓰면 백엔드 개발자가 필요 없을까요?

한번 생각해 보세요.