박종명의 아름다운 개발 since 2010.06

INTRO

일정 규모 이상의 정보 서비스를 제공하고 있다면, 아마도 대부분 한대 이상의 서버를 배치하여 부하분산을 시키고 있을 것입니다. 이런 배치 전략을 로드밸런싱이라고 하죠.

로드밸런싱은 대량의 트래픽을 수용하기 위해 여러대의 (동일한) 서버가 요청을 나눠서 처리하도록 하는 부하분산을 통해 서비스의 처리량을 증가 시키고자 하는 것이 주 목적입니다. 

물론 로드분배 알고리즘과 서버 상태를 기반으로 해서 고가용성(HA)의 요건도 같이 충족되는 것이 일반적입니다.

만일 트래픽이 점점 더 늘어난다면, 그에 맞춰 Service #4, Service #5, ... 이런식으로 서비스의 복제본을 늘려 나가기만 하면 되기 때문에 손쉽게 확장이 가능합니다.

애플리케이션의 확장성을 보장하기 위해서는 다양한 전략을 구사할 수 있습니다. 로드밸런싱은 그 중에서도 트래픽의 처리량을 증가시켜서 서비스의 능력을 향상하는 아키텍처 전략에 해당합니다.

이 글에서는 애플리케이션의 확장성 보장을 위한 다양한 전략을 'Scale Cube'라는  규모 확장성 모델에 근거하여 설명하고자 합니다.

확장성

먼저 소프트웨어 분야의 확장성이라는 개념을 먼저 정리하자. 확장성은 쉽게 말해서,

애플리케이션이 얼마나 손쉽게 확장될 수 있는 가에 대한 가능성에 대한 정도로써 애플리케이션의 여러 품질속성 중 하나이다.

확장성이 좋다는 말은, 애플리케이션의 능력을 손쉽게 향상 시킬수 있다는 의미가 된다.

여기서 애플리케이션의 능력이란, 알고리즘이나 로직과 같은 세부적인 기능 측면보다는 성능/가용성/보안과 같은 비기능적인 요소(이를 품질속성이라 함)에 해당하는 능력을 말한다.

'정보통신기술용어해설'에서는 확장성을 다음과 같이 정의하고 있다.

대규모적인 재설계/재설치 등의 필요없이 확장이 얼마나 쉽고 가능한가에 대한 용이성

확장의 대상과 확장 방식에 따라 확장성을 다음과 같이 세분화 할 수 있다.

1) 규모 확장성
일반적으로 모든 확장성은 규모 확장성을 의미한다. 규모란 용어는 양적인 측면의 크기를 지칭하는 용어로써 특정 대상만을 한정하지는 않는다. 예를 들어 트래픽 처리량에 대한 규모, 데이터 보관량에 대한 규모, 기능의 종류와 양에 대한 규모 등 얼마든지 수식이 가능하다.

다만, 여기서의 규모 확장성은 아래에 설명하는 다른 확장성과 구분하기 위해 트래픽 처리량에 대한 확장으로 한정하고자 한다.

규모 확장성을 보장하기 위해서는 앞서 살펴본 로드밸런싱과 같이, 동일한 기능을 수행하는 애플리케이션의 복사본을 여러대 구성하여 트래픽 부하를 나눠 가지도록 구성한다. 이런 구성을 Scale out(수평 스케일)이라고도 하며 손쉽게 트래픽 처리량을 확장할 수 있어 흔히 사용되는 방법이다.

규모 확장성을 보장하는 로드밸런싱의 구조를 다시 확인해 보자. Service #1~#3은 모두 동일한 복제본으로 동일한 기능을 수행한다.

2) 기능 확장성
애플리케이션의 기능을 얼마나 손쉽게 추가, 수정할 수 있느냐에 대한 정도이다. 다시 말해, 기존 기능을 확장하거나 새기능을 추가하여 애플리케이션의 능력을 향상시킬 수 있는 가능성에 대한 정도로 풀어 쓸 수 있다.

과거 유행했던 SOA(Service Oriented Architecture)와 근래 유행하는 MSA(Micro Service Architecture)가 바로 기능 확장성 보장하는 아키텍처 구조이다.

MSA는 애플리케이션을 기능 및 역할 관점에서 분리하여 개별 서비스로 구성하고 상호 연동을 통해서 전체 애플리케이션을 구성하는 방식으로 애플리케이션의 독립성과 자율성을 보장함으로써 유지보수와 기능 확장을 용이하게 하는 아키텍처 구조이다.

다음 그림은 애플리케이션이 역할 단위로 분리되어 서로 다른 기능을 제공하는 모습을 보여준다.

3) 데이터 확장성
각각의 애플리케이션이 데이터의 일부분만을 책임지도록 하여 처리 효율을 증가시키거나 데이터 규모에 대한 확장성을 확보하는 기법이다. 데이터 샤딩이나 파티셔닝같이 데이터 자체를 분리하여 저장하는 방식으로 많이 활용되며 경우에 따라서는 애플리케이션 단위의 파티셔닝을 통해 각각이 애플리케이션이 서로 다른 데이터 영역을 책임지게 함으로써 데이터의 처리효율과 애플리케이션의 처리 성능을 향상시킬 수 있다.

다음 그림은 서로 다른 데이터가 서로 다른 저장소에 분리되어 저장된 샤딩된 구조를 보여준다.
여기서 각 Application은 모두 동일한 복제본으로 동일한 기능을 실행하지만 책임지는 데이터 영역이 서로 다르다.

예를 들어, 대량의 데이터에 대한 검색 기능을 개발한다고 할 경우, 다음과 같이 검색 API를 두고 뒷단으로 애플리케이션을 파티셔닝해 그 결과를 조합해서 반환하도록 구성할 수도 있다.

The Scale Cube

'THE ART OF SCALABILITY'라는 책에서는 매우 유용한 3가지 차원의 규모 확장성 모델을 제시한다고, 'Chris Richardson'이 서술한 바 있다.

상단의 그림은 Chris Richardson의 The Scale Cube라는 글에서 발췌해온 것이다. Chris Richardson은 해당 글에서 각 축(axis)에 대해서 설명한다. 글이 짧지만 핵심을 잘 전달해 주고 있으니 일독해 보기를 권장한다.

어느 훌륭한 한국분이 이 글을 번역해서 올려 뒀으니 참고 바란다.
> 스케일 큐브 (크리스 리차드슨)

X축 확장
애플리케이션의 동일한 복제본을 다수로 구성하여 애플리케이션의 처리 능력을 향상시키는 기법이다.
앞서 살펴본 처리량에 대한 확장성 즉, '규모 확장성'이 바로 이 축에 해당한다.

Y축 확장
애플리케이션의 기능을 역할별로 분리하여 서로 독립적인 서비스로 구성하는 기법이다.
앞서 살펴본 '기능 확장성'이 바로 이 축에 해당한다.

Z축 확장
데이터이 일부만을 책임지도록 하여 데이터 저장과 활용 관점에서 애플리케이션의 처리 능력을 향상시키는 기법이다. 앞서 살펴본 '데이터 확장성'이 바로 이 축에 해당한다

확장성 모델 요약

각각의 확장성 모델을 다음과 같이 하나의 표로 정리해 보았다.

실무 환경

실제 실무환경에서는 각각의 확장성 축이 모두 혼합되어 구성되는 것이 일반적이다. 특히 MSA 아키텍처 구조를 표방하는 애플리케이션들은 거의 대부분 아래와 같은 구조로 설계된다. 즉 모든 축의 확장성을 보장하는 형태로 구성하여 극강의(?) 확장성을 확보한다.

[출처: 마이크로서비스 아키텍처로 개발하기(안재우)]

12 Factor App 원칙에서는...
애플리케이션의 환경설정 정보를 코드로부터 분리하여 외부화하는 것을 그 원칙 중 하나로 제시하고 있다.

이는 환경에 따라 달라지는 설정 정보를 소스로부터 분리하여 둘 간의 결합도를 낮추어 유지보수성을 좋게하기 위한 설계 원칙이다.

이런 관점에서, 가장 최악의 선택은 설정정보를 소스코드의 상수로 관리하는 것이다.
요즘 왠만한 프로젝트에서는 상수기반 설정정보를 잘 사용하지는 않는다.

* 설정정보를 소스코드에서 분리시키기

설정 정보를 별도의 소스코드와 분리된 별도의 파일로 관리하는 것이 일반적이다.

스프링 부트 기반으로 볼 때, 
application.properties 또는 application.yml 파일에 설정정보를 관리한다.

단, 이 방식도 (설정파일이) 프로젝트에 포함된 경우라면, 설정정보의 변경이 필요할 경우, 애플리케이션 전체를 다시 빌드하고 배포해야 하는 종속성 문제가 생긴다.

(설정정보를 프로파일로 구분할 수 있는 것도 하나의 해결책이긴 하지만, 이는 프로파일의 종류가 정해진 경우에는 유용하나, 동일한 프로파일내에서의 변경사항은 여전히 종속성 문제를 내포하고 있다)

* 설정정보를 배포 패키지에서 분리시키기

설정정보 파일을 애플리케이션 배포 패키지에서 분리시키기 위한 방법이 몇 가지 존재하긴 한다.

자바 기반 프로젝트로 보면,
1) 애플리케이션 실행 시, 설정정보 파일 위치를 옵션에 명시
2) @PropertySource 어노테이션으로 설정정보 파일 위치 명시
3) 시스템 자체의 환경설정 정보를 읽어오는 System.getProperties() 사용하기

이 중 1)번 방식을 선호하기는 하지만, 이 또한 설정정보 변경이 발생하면 애플리케이셔을 중지했다가 다시 구동해야 하는 종속성 문제가 발싱한다.

* 설정정보를 원격 서버에서 제공하기

Spring Cloud 프로젝트에서 제공하는 Spring Cloud Config 서버를 활용하면 원격지 서버에서 설정정보를 서비스 할 수 있게 해준다.

그리고 설정정보를 동적으로 변경하여 (애플리케이션의 재빌드나, 재구동 없이) 실시간으로 반영시킬 수 있도록 하는 메커니즘을 제공하며 git이나 svn 기반으로 설정정보의 버전 관리를 지원해 준다.

* Spring Cloud Config 서버-클라이언트 구현

1. git 저장소와 설정파일 생성

1) git 저장소 생성
여기서는 설정정보 저장소로 로컬 git을 사용하기로 한다. git 을 설치하고 git 저장소를 init 명령어로 지정한다.

> git init

2) 설정파일 생성
다음의 규칙으로 설정파일 이름을 지정하고 설정정보를 파일에 입력한다.

3) 설정파일 커밋
생성한 설정파일을 git에 add하고 commit 한다.

> git status

> git add -A

> git commit -m "config file create"

4) Config 서버의 설정정보 확인
Config 서버에서 설정정보를 확인하기 위해서는 다음과 같은 규칙으로 접속한다.

아래는 프로파일이 없는 경우와 dev 프로파일에 접속하는 예를 보여준다

> http://localhost:8888/my-service/default

> http://localhost:8888/my-service/dev

2. Spring Cloud Config 서버 구현

1) Config 서버 프로젝트 생성
스프링 부트 프로젝트로 Config Server와 Actuator을 의존성으로 선택하고 생성한다.
(스프링 부트 2.0은 Spring Cloud Finchley.M9 버전을 사용한다)

2) Config 서버 설정
bootstrap.yml을 resource 폴더에 생성하고 다음과 같이 설정한다.

설정파일이 관리될 로컬 git 저장소를 지정하고, Config 클라이언트를 구분할 목적으로 서브디렉터리를 만들고 searchPaths로 서브디렉터리를 지정해 준다.

2. Spring Cloud Config 클라이언트 구현

1) Config 클라이언트 프로젝트 생성
스프링 부트 프로젝트로 Config Client를 의존성으로 선택하고 생성한다.
(스프링 부트 2.0은 Spring Cloud Finchley.M9 버전을 사용한다)

2) Config 클라이언트 설정
bootstrap.yml을 resource 폴더에 생성하고 다음과 같이 설정한다.

3) 설정 정보 사용하기
@Value 어노테이션을 사용하거나 @ConfigurationProperties 어노테이션을 사용하여 Config 서버로 부터 설정정보를 매핑하여 사용할 수 있다.

* Config 서버의 가용성

Config 서버가 1대 뿐이라면 SPOF(single point of failure, 단일장애지점)가 된다.
SPOF는 라이브환경에서는 언제나 재앙의 대상이 되곤 한다.

하지만 Config 서버의 구동방식을 보면 일반적인 SPOF에 비해 그 부담이 다소 적다.

1) 운영중 가용성
Config 서버와 연동하는 클라이언트는 최초 구동시에만 서버에서 설정값을 읽어온다.
이후 부터는 클라이언트 측에 로컬 캐시되어 더 이상 Config 서버와 통신하지 않는다.

다만, 설정정보가 갱신될 경우 클라이언트의 /actuator/refresh 엔드포인트를 사용해서 서버에서 새로운 값을 다시 읽어 오도록 하는데, 이때도 서버가 응답이 없다면 기존 로컬 캐시값을 사용한다

즉 Config 서버가 다운되었다고 하더라도 클라이언트들은 다운되거나 하지 않는다는 말이다.
(단 서버의 변경 값을 동기화하지 못할 경우, 일관성 문제는 생길 수 있다)

2) 최초 구동시 가용성
그렇다면, 클라이언트가 최초 구동될 때 Config 서버가 다운된 상황이라면 어떨까?
이때의 가용성을 위해서 fail-fast 값을 false(기본값)로 준 것이다.
fail-fast 값이 true로 설정되면, Config 서버와 연결하지 못하면 클라이언트는 구동되지 않게 된다.

어떤 선택이 더 나은지는 환경에 따라 다를 것이다.

만일 Config 서버가 이중화되어 있지 않은 상태에서 최소한의 가용성을 확보하기 위해서는 이 값을 false로 하는 것을 생각해 볼 수 있다.

즉 Config 서버가 다운된 상황에서도 클라이언트 프로그램은 구동되도록 하는 것이다.

물론 이렇게 하면 Config 서버로 부터 설정정보를 받아오지 못하는 문제가 생긴다.

이를 위해서 클라이언트에서는 동일한 설정정보를 자신의 설정파일에도 가지고 있으면 된다

이렇게 되면 Config 서버와 연결이 실패한 클라이언트는 동일한 설정을 자신의 설정파일로 부터 읽어 들이게 된다.

이것은 그야말로 최소한의 가용성 확보를 위한 전략이 될 것이다.

3) 보다 나은 가용성
Config 서버자체를 이중화하는 것이다.
로드밸런서를 두고 Config 서버를 이중화하면 장비 차원에서 가용성 확보가 된다.

이때 생각해 봐야 할 문제는 git 저장소의 동기화와 가용성 문제이다.

Config 서버를 이중화 할 경우에는,
로컬 git 저장소를 사용하지 말고 원격의 중앙 git 저장소를 사용하도록 한다.

 원격 git 저장소의 고가용성을 위해서는 다음 글을 참고 하자

https://about.gitlab.com/high-availability/

* 설정 정보의 실시간 동기화

Config 서버의 설정정보가 변경되면 이를 의존 하고 있는 클라이언트 프로그램들에게 알려줘야 하낟.

이때 사용되는 것이 @RefreshScope 어노테이션과 /actuator/refresh 엔드포인트이다.

이 두 작업은 클라이언트 측에서 수행되어야 한다.

실시간 동기화가 필요한 곳, 즉 설정정보를 엑세스 하는 클래스에 @RefreshScope 어노테이션을 붙여 준다.

그리고 클라이언트의 주소에 /actuator/refresh 엔트포인트로 POST (Body는 빈 값으로) 전송을 하면된다.

이렇게 하면 클라이언트 로컬에 캐시된 설정 정보를 Config 서버에서 가져온 값으로 즉시 갱신한다.

그러나 Config 서버에 의존하는 클라이언트가 상당히 많은 수일 경우, 모든 클라이언트의 /actuator/refresh 엔트포인트를 명시적으로 호출해 줘야 하기 때문에 유지보수가 까다로워 진다.

 Spring Cloud Bus를 사용하면 메시지 브로커를 통해 변경 이벤트를 구독하여 자동으로 모든 클라이언트에 변경 정보를 자동으로 동기화 할 수 있다.

-------------------------------------------

오랜만에 글을 쓸려니... 느무~~ 귀찮으니무다... 아...

글 쓰기 싫어서 큰일이다. 쩝...

작년(2016)에 수행했던 프로젝트가 CEO 표창을 받게 되었다.

어플리케이션 아키텍트(AA)로 참여하여, 초반부터 5개월간 투입되어 분석/설계/가이드를 수행한 프로젝트 였다.

초반 아키텍처를 설계할때 이슈도 많았지만, 그만큼 보람된 경험이었다.

2017년, 1년간의 아키텍트 업무 수행 내역을 기록한다.

오랜 기간 게임회사에 근무하다,
작년에 SI 회사로 이직하여 올해(2017년) Full 1년을 어플리케이션 아키텍트(AA)라는 직함을 달고 수행한 업무들이다.

게임회사 때의 개발 체계와 기술적 부분이 다소 상이하여 나름 고군분투하였으나, 많이 배우고 그만큼 성장한 한해가 아니었나 한다.

돌이켜 정리해 보니, 1년을 참으로 알차게 보냈구나 하며 스스로 칭찬해 본다. (토닥토닥)

내년에는 이 블로그에 더 성장한 한해를 기록할 수 있기를 기대하며...

* 통합 kt.com 구축

(사업유형) SI

(프로젝트 개요) 기존 유/무선 olleh.com 전면 개편,.대국민 서비스 향상 및 백오피스 효율화

(역할) 어플리케이션 아키텍트(AA)

(투입기간) 2017.01.02 ~ 2017.05.31 (6개월)

(수행업무) TO-BE 아키텍처 설계, 개발표준 수립, 성능향상 전략수립, 코드 템플릿 작성, 기술지원 등

(상면위치) KT 분당 본사

* kt estate 통합 부동산 시스템 구축

(사업유형) SI

(프로젝트 개요) kt estate 부동산 시스템 통/폐합을 위한 차세대 프로젝트

(역할) 어플리케이션 아키텍트(AA)

(투입기간) 2017.06.07 ~ 2017.07.05 (1개월)

(수행업무) AS-IS 분석 및 개선방향 도출, TO-BE 아키텍처 설계, 표준 프레임워크 선정 등

(상면위치) kt 관악 지점

* 신한은행 AI(인공지능) 코어플랫폼 제안 지원

(사업유형) 제안

(프로젝트 개요) 신한은행 챗봇 및 인공지능 코어 플랫폼 사업 제안 프로젝트

(역할) 어플리케이션 아키텍트(AA)

(투입기간) 2017.07.11 ~ 2017.07.20 (약 2주)

(수행업무) AI 코어플랫폼 아키텍처 영역 제안서 작성 지원

(상면위치) kt 행당 지점

* kt 기가지니 개발자 포털 Front-end 아키텍처 지원

(사업유형) SI

(프로젝트 개요) kt 기가지니 개발자 포털 구축

(역할) 어플리케이션 아키텍트(AA)

(투입기간) 2017.08.07 ~ 2017.08.11 (1주)

(수행업무) Angular4 기반 개발표준 수립 및 가이드, 코드템플릿, 개발자 교육

(상면위치) kt 융합기술원(우면 연구소)

* 하나투어 구조진단 컨설팅

(사업유형) 컨설팅

(프로젝트 개요) 하나투어 호텔 중계 시스템 어플리케이션 구조진단

(역할) 컨설턴트

(투입기간) 2017.08.14 ~ 2017.09.01 (3주)

(수행업무) 시스템 구조진단(AS-IS 구조 및 소스 분석, TO-BE 개선사항 도출)

(상면위치) 하나투어 본사(종로)

* K쇼핑 구조진단 컨설팅

(사업유형) 컨설팅

(프로젝트 개요) KTH, K쇼핑 어플리케이션 구조진단

(역할) 컨설턴트

(투입기간) 2017.09.04 ~ 2017.09.22 (3주)

(수행업무) 시스템 구조진단(AS-IS 구조 및 소스 분석, TO-BE 개선사항 도출)

(상면위치) KTH(동작구 보라매)

* 전사 AA(Application Architecture) 활동

1. DevPro 프레임워크, Angular-Starter 개발
- 전사 프레임워크(Devpro)에 Angular4 기반 Front-end 프레임워크 및 템플릿 추가

2. Zero-Copy 전사 세미나 개최
- 전사 세미나 세션 발표(주제: Front-end 트랜드)
- 2017.10.31 ~ 2017.11.01

3. SSAM 사내강의 진행
 - 2일 과정 사내 강의(주제: Angular4로 SPA 개발하기)
 - 2017.11.21 ~ 2017.11.22

* kt 기업 LTE 2.0 통합고객관리시스템 개발 프로젝트, 품질종합진단

(사업유형) 감리

(프로젝트 개요) 분석/설계 말 품질종합진단 AA영역 진단 수행

(역할) 어플리케이션 아키텍트(AA)

(투입기간) 2017.11.27 ~ 2017.11.30 (1주)

(수행업무) 프로젝트 품질진단(AA영역 품질 진단 및 개선방안 도출)

(상면위치) KT 분당 본사

* kt Biznaru 통합 분석/설계 

(사업유형) SI

(프로젝트 개요) Biznaru 에너지 + 보안 + new biz(신재생 등) 통합을 위한 분석/설계 프로젝트

(역할) 어플리케이션 아키텍트(AA)

(투입기간) 2017.12.01 ~ 현재

(수행업무) 통합 방향성 및 아키텍처 설계, 인터페이스 정의, 개발표준 수립, 개발 가이드 작성 등

(상면위치) KT 분당 본사

* 기타

1. 애터미(Atomy) 내부 전산 고도화 영업 지원(기술 컨설팅) (11월)

2. 하나투어 호텔 중계 시스템 사업 제안 지원 (12월)

지난 주, 이틀에 걸쳐 사내강의를 진행했다.

주제는 'Angular4로 SPA 개발하기'로 Angular 개발에 관한 강의였다.

대체로 현업에서 관련 기술이 요구되는 개발자 분들이 참여했으며, 나역시 많은 것을 배울 수 있는 기회였다.

사내강사(SSAM) 뱃지

교육과정

교육교재

강의시작

데모 소스

https://github.com/mkex/angular-spa-demo.git

어제, 오늘 이틀에 걸쳐 사내 역량 강화 세미나를 팀 주최로 진행한다.

그 중 내가 맡은 세션은
 '프론트엔드 트랜드 뽀개기'라는 주제로, 최신 웹 트랜드와 프론트엔드 생태계 전반에 대해 설명하는 자리를 가졌다.

사내 기술 리더들인 AA, DA 들이 거의 모두 참여하여 진행한 뜻 깊은 자리 였다.

세션 소개

프론트엔드 트렌드 발표자료 목차와 세션 진행 사진

데모 소스

https://github.com/mkex/FETrend.git 

"소셜 크롤러(Social crawler)는 자바스크립트를 실행하지 않는다"

얼마 전, 아키텍트로 지원했던 프로젝트에서 기술지원 요청이 들어왔다.

Ajax로 점철된(?) 페이지에 소셜 공유 기능을 추가해야 하는데, 여의치 않다는 것이다.
그래서 기술적 해결방안을 요청해 왔다.

해당 프로젝트는 일종의 SPA(Single Page Application) 구조로,
전통적인 웹 구현 모델인 서버랜더링 방식이 아니라 클라이언트 랜더링 방식을 채택하고 있었다.

즉 HTML/Javascript/CSS와 같은 정적 리소스를 먼저 브라우저에 랜더링 한 후, 필요한 비즈니스 데이터를 Ajax 통신으로 가져와서 DOM 제어를 하는 방식이다.

이런 구조의 대표적인 걸림돌(?)은 SEO(검색엔진최적화)나 Open Graph 프로토콜에 기반한 소셜 공유에 취약하다는 것이다.

서버에서 비즈니스를 처리하고 동적으로 생성된 HTML을 반환하는 것이 아니라, 아무런 동적 처리가 되지 않는 HTML을 먼저 반환하기 때문에, 웹 크롤러가 가져갈 수 있는 정보가 한정적이기 대문이다.

다시말해 대부분의 웹 크롤러는 자바스크립트를 실행하지 않기에, 자바스크립트를 사용해 동적으로 구성한 정보를 웹 크롤러에게 줄 방법이 없는 것이다.

이에 대한 기술적 해결 방안으로는, 크게 다음과 같은 두 가지 전략을 생각해 볼 수 있다.

1. 서버 랜더링 방식을 살짝 가미하기
소셜 공유를 위해서는 소셜 크롤러를 위한 메타 정보를 제공해야 한다.
해당 메타 정보는 비즈니스 처리가 된 동적 정보로 구성되어야 하기 때문에 서버 랜더링 방식으로 필요한 메타정보를 구성하는 방식이다.

그리고 페이지의 나머지 처리는 Ajax 통신을 통해 동적으로 구성한다.
이 방식은 서버랜더링 + 클라이언트랜더링 방식을 하이브리드 시켜 '꿩 먹고 알 먹는' 착각(?)을 주기도 한다.

이런 구조는 다음 사이트에서 구현하고 있는 듯 하다

> http://jakduk.com

이 방식의 단점 이라면, 클라이언트 랜더링 방식이라는 아키텍처 구조를 조금 흔들어야 한다는 것이며 Angular와 같은 Full SPA 구조에서는 적용하기 힘들다는 것이다.

이를 위해 다음과 같은 두 번째 방식을 권장한다.

2. 웹 크롤러를 위해 별도의 메타 정보 제공하기
이 방식은 다음의 사이트에 잘 설명되어 있다.

> https://rck.ms/angular-handlebars-open-graph-facebook-share/ 

기존 페이지나 아키텍처 구조를 건드리지 않고도 적용할 수 있는 훌륭한 방법이다.

동적으로 생성된 메타 정보를 반환하는 별도의 로직을 만들고,
페이지 요청이 웹 크롤러로부터 온 것이라면 웹 서버의 Rewrite 모듈을 사용해 요청을 다시 작성한다.

즉 일반 사용자는 원래 페이지에 접근하고 웹 크롤러는 동적 메타 정보를 제공하는 HTML을 반환받도록 하는 것이다.

이때 메타정보를 제공하는 로직은 HTML을 반환하는 REST API로 구현하거나 별도 서버 측 페이지로 구현할 수 있다.

--------------------------------------------------------------------------------------------------------

여러모로 비교해 봤을 때, 2번 방식이 보다 깔금하게 해결 할 수 있는 솔루션인 듯 하다.

그러나 이 글을 쓰는 목적은 다른데 있다.

3. 자바스크립트를 해석하는 웹 크롤러

근래 웹 아키텍처에 SPA(Single Page Application)가 많이 차용되는 추세이고, 특히 앱 스러운(App Like) 모바일 웹 환경에서는 SPA가 보다 효과적이다.

또한 Angular, Vue.js, React.js와 같은 SPA 프레임워크들이 인기가 치솟고 있으며, 하이브리드 앱 환경에서도 클라이언트 랜더링 방식이 심심찮게 적용되고 있다.

이렇듯 클라이언트 랜더링 방식이 기술적 트랜드로 자리매김 하고 있고 필드에서 많이 적용되고 있음에도 웹 크롤러는 아직 과거에 머물러 있다는 점을 꼬집고 싶다.

일부 브라우저 업계에서는 클라이언트 랜더링 방식에서 SEO 등의 적용을 위해 자바스크립트의 동작을 해석하는 웹 크롤러를 만들고 있다고는 한다. 그러나 현재까지도 대부분의 웹 크롤러는 단순히 URL을 호출하고 즉시 반환되는 HTML 덩어리에만 의존하고 있는 실정이다.

아무리 진보한 아키텍처라고 해도, 주변 환경이 이를 지원하지 않는다면 아키텍처의 훼손은 어쩔 수 없이 발생할 것이다.

개인적인 희망으로는, 웹 크롤러를 현실에 맞게 진화시켜 클라이언트 랜더링 방식에서도 SEO나 소셜 공유가 가능토록 해 주길 바란다.

혹여 망설여지는게,
표준적이고 범용적인 적용이 어려울 수도 있겠다 하는 것인데...

이것 역시 , 클라이언트 랜더링의 모든 커스텀 로직을 인식할 필요는 없고 초기화 함수 정도만 인식해 줘도 쉽게 풀릴 문제가 아닌가 한다.

크롤러의 발전을 기대하며...

참고> 페이스 북 클로러 테스트 페이지
다음 URL은 페이스북 크롤러가 소셜 공유를 했을 때 어떤 정보를 가져가는지 테스트 해보기 위한 도구이다.

https://developers.facebook.com/tools/debug/sharing

멋진 팀과 더 멋진 팀 구성원들!!!
앞으로 많이 배우겠습니다 ^^.

소프트웨어 위기(Software Crisis)라는 용어가 등장한지 50년 가까이 되었음에도 여전히 그 위기속에 생명을 유지하고 있는 소프트웨어가 간혹 발견된다.

이런 문제를 몇몇 자질이 낮은 개발자의 문제로 치부하는 경향도 발견되는데, 이는 문제의 본질을 흐리게 하고 근본원인의 해결을 할 수 없게 만드는 좋지 못한 접근법이다.

소프트웨어 위기에 내포된 문제점은 결국 돈과 시간, 만족도의 문제이다.

계획된 납기를 준수하지 못한채 예정된 예산보다 더 많은 돈을 지출하고도 불만족스러운 소프트웨어를 사용하게 되는 것이다.

소프트웨어 위기는 소프트웨어 개발에서의 공학적 접근의 필요성과 중요성을 강조하는 계기가 되었는데, 소프트웨어 공학의 목표라는 것이 결국에는 '한정된 자원(돈, 시간)으로 사용자가 만족하는 고품질의 소프트웨어를 생산하는 것'이란 점에서 돈과 시간, 만족도에 대한 문제해결의 접근법이라 할 수 있다.

각종 공학적 기법과 방법론, 관리체계를 기반으로 표준화를 통한 일관성과 호환성을 확보하고 자동화 툴을 사용하여 생산성 향상을 꾀하며 개발수명주기간 품질보증체계를 적용하여 개발초기부터 고품질 소프트웨어를 생산하도록 촉진하여 소프트웨어 위기라는 문제에 근본적으로 대응할 수 있게 된다.

기본적이고 이론적인 내용일 수 있으나, 항상 문제는 기본을 지키지 못한데서 발생한다는 것을 잊지말자.

마치 역사가 반복되는 것처럼, 패션 스타일도 돌고 돌고 UI 디자인 트랜드도 돌고 도는 듯 하다.

디자이 트래드에 대한 이해는 다음 글들을 참고.

- http://blog.naver.com/youngdisplay/220690365967
- http://blog.naver.com/kosoodream/220769634590
- http://segrami.tistory.com/11

실제적인 모바일 UI/UX 설계 및 개발시 참고할 만한 가이드는 다음 사이트를 참고.

- Material Design Guide: https://material.google.com
- Material Design CheckList: https://developers-kr.googleblog.com/2014/10/material-design-on-android-checklist.html
- 모바일 UI 디자인 시 고려해야 할 가이드라인: https://brunch.co.kr/@chulhochoiucj0/9

모바일 SW 및 UX 사례연구.

- http://www.sw-eng.kr/member/customer/Webzine/BoardView.do?boardId=00000000000000046341&currPage=&searchPrefaceId=00000000000000020135&titOrder=&writeOrder=&regDtOrder=&searchCondition=TOT&searchKeyword=

- http://www.sw-eng.kr/member/customer/Webzine/BoardView.do?boardId=00000000000000045634&currPage=&searchPrefaceId=00000000000000020135&titOrder=&writeOrder=&regDtOrder=&searchCondition=TOT&searchKeyword=

- http://www.sw-eng.kr/member/customer/Webzine/BoardView.do?boardId=00000000000000045697&currPage=&searchPrefaceId=00000000000000020135&titOrder=&writeOrder=&regDtOrder=&searchCondition=TOT&searchKeyword=