일반 웹 어플리케이션 구조 리뷰

[Spring + CS] 일반 웹 애플리케이션 구조

• [Q] 모노리식 구조(Monolithic Architecture)은 무엇인가?

홈페이지, 쇼핑몰, 각종 컨텐츠 제공 등 온라인 서비스 사이트를 구현할 때, 하나의 서버(혹은 서비스) 요소로 구축하는 구조를 의미한다. 하나의 서버 내에 모든 기능 (예를 들면, 가입 및 탈퇴, 로그인, 컨텐츠 조회, 결제 등등) 을 포함한 형태로 구현하기 때문에 개발 및 운영(서비스)하는 입장에서는 하나의 서버만 실행하기 때문에 직관적이고, 단순해 보인다. 단, 외부의 시각에서 보기에 단순해 보일 뿐 내부의 로직을 개발하는 입장에서는 온갖 기능들이 짬뽕처럼 섞여 있기 때문에 무언가 새로운 기능을 추가하거나, 기존에 있는 기능을 개선하기 위해서는 복잡한 코드와 얽혀있는 구성을 파악하고, 수정하는 지루하고 까다로운 부담이 발생한다. 더 큰 문제는 처음부터 개발한 사람은 전체 구조를 이해하고 있어서 특정 기능을 수정하는 작업이 수월할 수 있지만, 새롭게 개발에 참여하는 사람이 생기면 기존의 구조를 파악하는데 수일에서 수주 혹은 수개월의 적응 기간이 필요하다. 신참자와 경험자 사이의 이해도 차이는 심각한 갈등을 유발할 수 있기 때문에 필연적으로 점차 개발 비용이 상승한다.

실제 현장 상황을 묘사하자면 경력자가 한 시간이면 고치는 코드를 찾기 위해, 신참자는 며칠이고 해당 코드를 찾기 위해 시간을 소비하게 되고 경력자는 신참자를 무능하다고 탓하거나, 노력이 부족하다고 폄하하게 된다. 반대로 신참자는 친절하게 가이드 해주지 않고 복잡한 코드들을 이해하고 적응할 시간을 주지 않는 경력자를 원망한다. 이런 사태가 반복되면, 개발하는 시간보다 커뮤니케이션 장애로 인한 시간과 비용의 낭비가 기하급수적으로 늘어가며, 최종적으로는 기존에 개발한 모든 결과물을 깡그리 무시하고 새롭게 개발하는 선택을 반복하게 된다. 실제로 1980년대 부터 ~ 2010년 대 초반까지 유수의 글로벌 기업들이 몇 년간 하나의 시스템을 개발해 놓고 점차 개선 및 수정을 하면서 복잡성이 증가하는데다 앞서 말한 갈등과 비용이 증가하면 더 이상 추가 개발을 포기하게 된다. 기존에 막대한 비용을 투자한 소프트웨어를 시스템을 지우고(갈아 엎는다고 표현한다) 다시 개발하면서 새로운 시스템을 '차세대 시스템'이라고 이름 붙여 (사실상 50% 이상 기존 시스템과 동일하고, 일부만 다시 개발한) 신규 시스템을 재구축하는 중복 투자를 반복해 왔다.

이러한, 바벨탑을 만들고 무너뜨리기를 반복하는 낡은 시스템 개발 방식을 개선하기 위해 시스템 설계자들과 소프트웨어 개발자들은 기존 방식을 모노리식 아키텍쳐라는 이름을 붙여 비판하고 새로운 아키텍쳐를 점차 제안하기 시작했다.

• [Q] 프로그래머 입장에서 모노리식 아키텍쳐는 어떤 이슈(장단점)들이 있을까?

구현 사례를 들어 개략적으로나마 모노리식 아키텍쳐의 개발 프로세스(절차)와 장단점을 정리해 보도록 하자. 예를 들어, 간단한 카페(혹은 게시판) 웹 서비스를 구현한다고 생각해보자. 까페 서비스는 일반적으로 다음과 같은 페이지(URL혹은 서비스)들을 포함해야 할 것이다.

1. 까페 서비스 초기 페이지 (서비스 안내 및 전체 카페 목록 등 표시)
2. 개별(특정) 까페 초기 페이지 (까페 명칭 및 관리자 정보 등 표시)
3. 개별 까페 게시판 목록 페이지 (공지사항, 자유게시판 등 특정 게시판의 게시물 목록)
4. 개별 까페 게시물 상세 조회 페이지 (게시물 제목 클릭 시 해당 게시물의 제목 및 내용, 작성자, 작성일자 등 표시)
5. 개별 까페 게시물 신규 작성 페이지 (신규 게시물 작성 화면)
6. 개별 까페 게시물 기존 문서 편집(및 삭제) 페이지 (이미 작성된 게시물 편집 및 저장 혹은 삭제 처리 버튼 포함)

[까페 페이지 공통 기능]

1. 특정(해당) 페이지에 접근할 경우, 접근을 시도하는 사용자가 현재 로그인 상태인지 여부를 점검하는 기능 (만일 로그인 되어 있지 않은 상태로 확인된다면, 로그인 페이지로 강제로 이동시켜야 함)
2. 로그인 상태로 확인 되었다면, 해당 페이지를 조회할 수 있는 권한을 소유하고 있는지 여부 점검 (까페 회원이 아니거나, 관리자가 아니라면 오류 메시지를 출력하는 페이지로 이동)
3. 조회(혹은 편집)하려는 페이지가 특정 게시물을 출력하는 페이지라면 해당 컨텐츠가 실제 존재하는지 여부 확인 (삭제된 컨텐츠 혹은 존재하지 않는 페이지를 조회하려고 시도하는 경우, 오류 메시지를 출력하는 페이지로 이동)

위와 같은 기능을 모든 페이지에 포함시켜서 개발(코딩)하다 보면 동일한 기능을 반복적으로 복사해서 집어 넣어야 할 것이다. 동일한 기능을 copy & paste 방식으로 집어넣고 개발한 후, 테스트 혹은 운영 중에 특정 기능에 버그가 발견되면 복사된 모든 위치를 찾아서 수정해야 한다. 반복적으로 복사한 코드를 검사하고 수정하는 것은 아무래도 많은 시간과 노력을 소모해야 하는데다, 만일 복사된 코드의 모든 곳을 고치지 못하고 놓친 부분이 발생한다면 치명적인 장애를 발생시킬 수도 있다. 아울러 개발자가 미쳐 확인하지 못한 버그를 찾아서 서비스를 마비시키는 해커들도 존재한다. (공공기관이나 금융 관련 웹 사이트에서 이런 문제는 엄청난 금전적인 혹은 사회적, 법적 문제를 일으킬 수도 있다.)

이미 잘 만들어둔 사이트를 개선할 때도 문제는 많다. 사용자의 로그인 상태를 점검하는 코드를 개선해서 사용자의 로그인 접속 암호(password)를 암호화(encryption) 하는 기능을 추가한다고 생각해보자. (사용자 패스워드를 암호화 화지 않아서 자찻 노출될 경우, 크나 큰 문제로 번질 수 있을 것이다.) 잘 구축된 웹 사이트에는 수많은 페이지가 존재하는데 수많은 페이지를 모두 찾아서 암호화 및 복호화 기능을 추가하는 것도 만만찮은 시간과 노력을 필요로 하게 된다. 복사된 수십, 수백 곳의 코드를 수정하다보면 자칫 새로운 버그가 발생할 수도 있다. (이런 반복 작업을 개발자들은 가내 수공업 방식이라고 표현한다.) 정작 고쳐야할 알고리즘은 하나(혹은 한번의 고민)인데 실제 작업은 수십 시간을 필요로 한다. 전체 수정 내역이 정상적으로 동작하기 위해서는 엄청난 테스트 시간도 소모하게 된다. 이런 방식으로 개발해서는 끊임없이 발전하는 현대 IT 사회에서 너무나 많은 비용, 인력, 그리고 시간의 낭비가 발생하게 된다.

특정(혹은 동일한) 기능을 추가하거나 개선할 때, 반복적으로 작업하는 일을 방지하기 위해서 DRY "Do not Repeat Yourself" 원칙이 강조되고 있는 이유는 copy & paste 방식이 너무나도 많은 비용과 시간을 발생시켰기 때문이다.

... to be updated ...

• [Q] 계층식(Layered Architecture)은 무엇인가?