조화를 흉내낸 생화

요즘 만들어지는 가짜꽃(조화)은 진짜꽃(생화)과 구별하기 힘들정도로 정교하게 만들어진다. 그래서 어쩔때는 그 꽃의 화려함에 도취되어 나도 모르게 향기를 맡으려 할 때가 있다.

하지만 향기를 맡으려 가까이 다가가면 금방 조화임을 알아차린다.
그 때는 속았다는 배신감 보다는 내가 착각할 정도로 생화를 흉내 냈다는 것에 감탄하게 된다.

우연히 길가에 설치된 조경용 대형 화분에서 마치 조화처럼 핀 꽃을 보았다.

이 꽃은 5장의 꽃잎을 가지고 있는데 2개는 진보라색이고, 3개는 흰색 꽃잎을 가지고 있다. 

게다가 꽃 중앙에는 마치 팬으로 꽃 잎에 장난을 친 것처럼 고양이 수염이 그려져 있고, 흰색 꽃 잎 한쪽에는 2장의 진보라 꽃잎에 색칠을 하다가 실수로 물감을 흘린 듯 진보라 점박이가 있다.

처음 봤을 때는 조화를 화분에 심어놓은 줄 알았다. 그런데 가까이서 보니 생화였다.

보통의 경우 조화를 생화로 착가하는 경우가 많았는데 생화를 조화로 착각하기는 처음이었다.

식물의 꽃은 벌이나 나비를 유혹하여 자신의 개체 수를 늘리기 위해 진화하였다. 그래서 눈에 잘띄는 화려한 색깔과 꿀이라는 선물까지 선사하면서 벌이나 나비를 유혹한다.

그런데 생화를 조화로 착각하게 만들었던 저 꽃은 벌이나 나비를 유혹하기 위한 것처럼 보이지는 않았다. 오히려 사람을 유혹하기 위해서 진화한 것처럼 느껴졌다.

인터넷에서 확인해보니 저 꽃은 관상용으로 사람들이 개량한 팬지 꽃이었다.

우리가 주변에서 보게되는 팬지 꽃은 더 이상 벌이나 나비를 유혹하고 있지 않았다.

사람을 유혹하고, 사람에 의해 개체수가 늘어나고 있었던 것이다.

만약 어느 순간 팬지 꽃을 대체할 그 무엇이 생겨서 팬지 꽃이 더 이상 사람을 유혹하지 못한다면 팬지 꽃은 멸종될 것이다.

사람들이 팬지 꽃을 사람중심으로 바꾸어 가는 것이 팬지 꽃에게는 종의 멸종을 가져올 수도 있다는 생각이 들자 아름다운 팬지 꽃을 보면서도 마냥 즐겁지만은 않았다.

Read More

퇴고는 끝내는 것이 아니라 멈추는 것이다.

블로그를 시작하고 글쓰기의 어려움을 새삼 느끼고 있다.

저번 글도 약 3시간에 걸쳐서 작성을 했다. 아직 익숙하지 않아서 더 느리겠지만 별로 적은 것도 없이 시간이 훌쩍 지나갔었다.

그나마 다행인 것은 3시간을 노트북 앞에서 글을 쓰면서도 전혀 힘들다는 생각이 들지 않았다. 오히려 즐겁게 글을 쓸 수 있었다. 조금씩 조금씩 글쓰기의 재미를 느끼는 것 같아서 뿌듯한 마음까지 들었다.

아마튼 그렇게 3시간에 걸쳐서 블로그 작성을 마친 후 TV 를 틀었다.

그리고 채널을 이리저리 돌리다가 예전에 시청했던 "프로듀사" 라는 드라마가 재방송하는 것을 보게되었다.

예전에 너무 재미있게 봤던 드라마라 자연히 난 드라마 시청모드에 들어갔다.

드라마는 "5화 편집의 이해" 편이 방영되고 있었다.

드라마에서는 만취가 된 탁예진(공효진)이 라준모(차태현)에게 사랑고백을 하게되고, 라준모는 우정을 잃을까봐 탁예진의 사랑고백을 기억에서 편집해버린다는 내용이다.

드라마 배우들의 연기도 좋고 내용은 더 좋아서 추천하고 싶은 드라마이다.

아무튼 드라마 얘기를 하려고 한 것은 아니고, 드라마를 보던중 너무나 가슴에 와닿는 글이 있어서 이글을 쓰게 되었다.

드라마에서는 여러 사람들이 나와서 편집에 대해서 정의를 하는 장면이 있는데 나의 가슴을 두드렸던 편집에 대한 정의는 다음의 것이다.

편집은 끝내는 것이 아니라 멈추는 것이다.

편집은 아무리해도 만족할 수 없다는 뜻이다. 그래서 편집자가 만족스럽게 편집 작업을 끝내는 것이 아니고, 결국 마감시간에 맞춰서 멈추는 것이란 의미이다.

글쓰기도 마친가지인 것 같다.

블로그 글쓰기를 하고 퇴고를 위해서 쓴 글을 다시 읽어보면 맘에 안드는 부분이 여기저기다. 그래서 글을 고치다 보면 어느새 다른 글이 되어 있거나 아니면 이전 글이 더 좋았다는 생각으로 원복하게 된다. 이런 과정이 계속반복되고 그러다보면 어느새 2~3시간이 훌쩍 지나가 있는 것이다.

그래서 난 블로그 글쓰기의 퇴고를 다음과 같이 정의하고 싶다.

퇴고는 끝내는 것이 아니라 멈추는 것이다.

직업적으로 글쓰는 사람들도 자신의 글에 대해서 100% 만족하는 사람은 없다고 한다. 하물며 글쓰기 초보인 나의 경우야 더 말할 것도 없다.

글을 쓰면서 스스로 완벽주의에 빠질 때면 퇴고에 대한 정의를 떠올려 보면서 적당한 선에서 멈추는 지혜를 발휘하는 것도 좋을 것 같다.

Read More

부패하는 기술, 발효하는 데이터

주말에 서일농원을 다녀왔다.
경기도 안성시에 위치한 서일농원은 3만여평의 부지에 2000여개의 장독대를 가지고 있는 농원이다. 농원이라기 보다는 커다란 공원처럼 조경이 너무나 아름답게 꾸며져 있었다.
농원 내부에 '솔리'라는 식당이 하나 있는데 12시에 갔더니 2시간을 기다려야 식사를 할 수 있다고 해서 결국 식사는 포기하고 말았다.

이렇게 사람이 많이 찾아오는데 왜 식당을 하나만 만들었는지 처음에는 이해하지 못했다. 나라면 식당을 더 늘려서 더 많은 손님을 받았을 것 같았기 때문이다. 하지만 농원을 둘러보면서 줄 맞춰 놓여있는 수 많은 장독대를 보면서 이해할 수 있었다.

서일농원의 비즈니스 모델은 식당이 아니고 '장을 담가서 파는 것'이란 것을 말이다. 식당은 어쩌면 장맛을 소개하는 역할을 할 뿐 핵심 비즈니스는 아닌 것이다. 그래서 굳이 식당을 더 크게 운영할 필요가 없는 것이다. 오히려 식사를 한 고객보다 식사를 못하고 그냥 돌아가는 고객들이 된장이나 청국장을 사갈 확률이 더 높기 때문이다.

서일농원은 보면서 "장담그기" 비즈니스를 생각해 보았다.
불과 20~30년 전만 해도 집에서 장을 담가 먹었었다. 그 시절에는 절대 성공할 수 없었던 비즈니스 모델이다. 하지만 시대가 변해서 더 이상 집에서 장을 담가먹지 않게 되면서 새로운 비즈니스 모델이 나타난 것이다. 물론 대량으로 생산된 된장, 고추장이 마트에 가득하지만 서일농원의 고급화 전략은 나름의 고객층을 확보하며 비즈니스를 성공시키고 있다.

그리고 이 비즈니스의 특징은 "시간이 부가가치를 높여준다"는 것이다. 시간이 부가가치를 올려주는 사업은 주로 예술쪽에서 많이 나타나는데 예를 들면 골동품이 시간이 지날 수록 그 가치가 올라가는 경우를 생각해보면 이해가 쉬울 것이다.
이렇게 시간이 관여하게 되면 신생 업체가 기존 업체를 밀어내기가 무척 어렵게 된다. 누군가 서일농원과 동일한 비즈니스 모델로 사업을 하려고 서일농원의 장담그는 레시피를 모두 알아냈다고 해도 장이 발효되고 맛이 깊어질 때 까지 사업을 지속할 수 없다면 성공할 수 없다. 그렇게 보면 서일농원의 비즈니스 모델은 누가 쉽게 넘보기 힘든 특성을 갖고 있다고 할 수 있다.

그렇다면 IT 쪽에서도 이렇게 시간이 가치를 높여주는 사업 모델이 있을까?
IT 는 하루가 멀다하고 새로운 기술이 나타나고, 예전의 기술은 사라져간다. 이런 환경에서 과연 시간이 지날 수록 가치가 높아지는 것이 있을까?
만약 그런 것이 있다면 그것은 데이터일 것이다.
기술은 시간이 지나면 부패하지만 데이터는 시간이 지나면 발효한다.
여기서 잠깐 부패와 발효를 차이를 알아보면 부패와 발효는 모두 미생물이 유기물을 분해하는 현상이다. 다만 그 현상으로 발생한 유기물이 인간에게 해로운가 유익한가의 차이가 있을 뿐이다.

IT 기술은 시간이 지나면 사라진다. 즉 가치가 떨어지는 것이다. 과거에는 코볼(COBOL)이라는 언어가 있었다. 사무용 프로그램들이 모두 이 코볼(COBOL)로 개발된 적이 있었다. 하지만 지금은 사라진 프로그램밍 언어이다. 만약 아직까지도 코볼 기술만 가지고 있는 엔지니어가 있다면 그는 어디서도 일을 할 수 없을 것이다. 이렇듯 IT 기술은 시간이 지날 수록 부패해 간다. 새로운 IT 기술로 바꾸지 않으면 결국 아무짝에도 쓸모 없어진다.

그렇다면 데이터는 어떤가?
데이터는 쌓이고 쌓여서 그 데이터에서 패턴을 찾아내면 그것은 정보가 된다. 가치가 발생하는 것이다. 이렇게 데이터가 패턴을 갖게되면 그것은 새로운 가치를 만들어 내게된다.
세계 최고의 기업 구글이 왜 그토록 검색엔진 사용자들의 데이터를 수집했겠는가?
왜 구글은 안드로이드를 공짜로 제공하면서 스마트폰 사용자들의 데이터를 모았겠는가?
구글은 데이터가 쌓이면 거기서 정보를 만들어 낼 수 있다는 것을 알았기 때문이다. 그런데 정보가 될 정도의 패턴을 찾아내려면 오랜 시간에 걸쳐서 수집된 데이터가 필요하다. 아무리 뛰어난 기술을 갖고 있더라도 시간을 대체할 수는 없다. 그래서 오랜 시간에 걸쳐서 수집된 데이터는 그 시간에 따라서 가치가 올라가게 된다.
이런 의미에서 내가 데이터는 부패되는 것이 아니고 발효된다고 표현한 것이다.


서일농원에서 시작해서 IT 분야의 데이터 가치로 얘기를 전개한 것이 좀 비약이 있을 수 있지만 "데이터에 시간이 추가되면 무시할 수 없는 가치가 발생할 수 있다."는 정도로 이해하면 좋을 것 같다.

Read More

CNA를 가능하게 하는 기술

이전글(클라우드용 어플리케이션은 뭐가 다를까?)에서 CNA(Cloud Native Application)의 필요성과 특성에 대해서 알아보았다.

이번에는 이런 CNA를 가능하게 하기 위한 기술에 대해서 알아보자.
CNA 를 구현하기 위해서는 아래 그림과 같은 6가지의 기술이 필요하다.

• Microservices

이름에서 알 수 있듯이 기능별로 잘게 쪼개서 서비스를 개발하는 것이다.
이런 구조를 MSA(Micro Service Architecture)라고 부른다.
MSA의 반대는 모노리틱 아키텍쳐(Monolithic Architecture)이다.

모노리틱 아키텍쳐는 모든 기능을 하나의 덩어리고 만드는 것이다.
그래서 모노리틱 아키텍쳐로 개발하면 최적의 효율성을 보장할 수는 있지만 하나의 기능에서 발생한 문제가 전체 시스템에 영향을 주게된다.
이때문에 단순한 구조의 어플리케이션에는 적당한 아키텍쳐이지만 복잡한 기능을 가지고 있는 어플리케이션에는 안정성을 떨어뜨리는 구조이다.
반면 MSA는 기능별로 서비스를 분리하여 한 서비스의 오류가 다른 서비스에 영향을 주는 것을 막는다.
대신에 각 서비스간 데이터 통신량이 늘어나서 리소스가 더 많이 소모되고, 공유되는 데이터의 정합성을 맞추기 위한 추가적인 코드 개발이 필요하다는 단점이 있다.

• 12-Factors App

12-Factors App 의 정의에 대해서는 12factor.net 사이트의 머릿말에 다음과 같이 정의되어 있다.

Twelve-Factor app은 아래 특징을 가진 SaaS 앱을 만들기 위한 방법론이다. 

• 설정 자동화를 위한 절차(declarative) 를 체계화 하여 새로운 개발자가 프로젝트에 참여하는데 드는 시간과 비용을 최소화한다.
• OS에 따라 달라지는 부분을 명확히하고, 실행 환경 사이의 이식성을 극대화 한다.
• 최근 등장한 클라우드 플랫폼 배포에 적합하고, 서버와 시스템의 관리가 필요없게 된다.
• 개발 환경과 운영 환경의 차이를 최소화하고 민첩성을 극대화하기 위해 지속적인 배포가 가능하다.
• 툴, 아키텍처, 개발 방식을 크게 바꾸지 않고 확장(scale up) 할 수 있다.

12개의 Factor 에 대한 자세한 내용은 12factor.net 사이트의 내용을 참조하기 바란다.

• Multi-tenancy

멀티 테넌시(Multi-tenancy)란 여러 사용자(거주자)를 갖는 아키텍쳐이다.
집에 비유하자면 아파트에 비유할 수 있다.

말이 어려워서 그렇지 우리는 이미 이런 서비스 환경에 익숙해져 있다.
예를 들면 웹메일 서비스의 경우를 보자.
웹메일 서비스는 하나의 웹 어플리케이션이지만 여러 사용자가 각자의 환경속에서 사용하고 있다.
각자의 메일 보관함은 철저하게 분리되어 타인의 메일을 볼 수도 없으며 자신만의 화면이나 메일함들을 생성하여 개인화(Personalized)된 UI를 사용할 수도 있다.
이처럼 하나의 서비스내에서 사용자별로 저장공간과 설정내용 등을 독립적으로 관리한다.
이런 아키텍쳐의 장점은 하나의 시스템을 여러 사용자가 공유하는 구조이기 때문에 비용을 절감할 수 있다.
또한 겉으로는 사용자별로 다르게 보이지만 내부적으로는 하나의 스키마(Schema)를 가지고 있기 때문에 데이터 통합이 쉽다는 것도 장점이다.
하지만 사용자별로 다르게 보여주기 위해서는 서비스를 정교하게 개발해야하고, 만약 버그 발생시 시스템 전체에 영향을 미칠 수 있다는 단점도 존재한다.
게다가 데이터가 통합 관리되기 때문에 보안에도 취약한 구조이다.

• Container

컨테이너 기술과 비교되는 것이 가상화(Virtualization) 기술이다.
이 둘은 겉으로 보기에는 비슷한 면이 있어서 항상 비교가 되곤 한다.
하지만 엄밀히 말하면 컨테이너 기술과 가상화 기술은 전혀 다르다.

가상화 기술은 OS를 통째로 가상화한 것이고, 컨테이너 기술은 OS 위에서 환경을 격리(Isolation) 시킨 것이다.
그래서 OS 가상화처럼 인스턴스 생성시 부팅이라는 과정이 존재하지 않고, OS 자원을 공유하기 때문에 속도도 빠르다.
컨테이너 기술은 각각의 운영환경을 컨테이너라는 곳이 보관하여 서로 격리 시키는 기술이다.
리눅스에는 기본 내장되어 있는 기능이고, 향후 윈도우(Windows)  계열의 OS 도 지원할 예정인 기술이다.

• API

API(Application Programming Interface) 는 프로그램간의 인터페이스 기술이다.
하나의 프로그램이 사용자(User)와 상호작용(Communication)하기 위해서는 UI(User Interface)가 필요하다.
마찬가지로 서로 다른 어플리케이션이 상호작용을 하기 위해서는 API가 필요하다.
API는 사전에 서로 약속된 규칙에 따라 서비스를 요청(Request)하고 응답(Response)하는 구조를 갖는다.
최근에는 REST 형식의 API가 주로 개발되고 있으며 데이터 타입도 JSON 포맷을 주로 사용하여 개발되고 있다.

초기의 API는 패킷(Packet) 형태로 정의되었고, 데이터는 바이너리(Binary) 형태로 개발되었다.
패킷형태의 API는 개발자에 의해서 패킷의 구조가 정의되었다.
그러다 보니 패킷의 구조가 모두 제각각이여서 API 이용에 많은 학습이 필요했었다.
또한 데이터 형태도 바이너리여서 패킷정의 문서가 없으면 내용을 알 수가 없었다.
그래서 나타난 것이 SOAP(Simple Object Access Protocol)이다.
SOAP 은 패킷의 형태를 표준화하기 위해서 등장하였고, 객체(Object)를 직렬화(Serialize)해서 전송할 수 있었다.
이는 패킷형태의 프로토콜에서는 생성하기 어려웠던 계층적인 데이터의 표현도 가능하게 되었다는 것을 의미한다.
또한 XML 포맷으로 SOAP을 정의하는 WSDL을 배포하여 프로토콜 공유도 한층 쉬워졌다.
하지만 다른 언어간 연동시에 데이터가 깨지는 문제들이 발생하여 개발에 많은 노력이 들어가야하는 단점들이 발생하게 되었다.
REST API 는 웹 프로토콜을 사용하여 플랫폼, 개발언어, 디바이스 종류에 상관없이 연동이 쉽게 이루어 질 수 있었고, JSON 포맷 사용으로 데이터의 가독성이 높아졌다.
JSON 포맷은 XML에 비해 경량화(Compact)된 사이즈를 제공하고 있어서 최근에 가장 많이 개발되고 있는 API 형태이다.

• PaaS

CNA는 SaaS 모델용 어플리케이션 이다. 따라서 PaaS 기술의 기반위에서 동작한다.
PaaS 관련된 내용은 "클라우드 컴퓨팅 이해하기"를 참조하기 바란다.

Read More

발 밑을 조심해! 내가 있단 말야!

아파트 화단에 자라난 아주 작은 들꽃을 보았다.
누구나 어렸을 적 한번쯤 그렸을 것 같은 모양의 꽃이 3개가 피어있었다.
이 작은 꽃들은 연약한 줄기 끝에 대롱대롱 매달려 조금만 바람이 불어도 이리저리 마구 흔들렸다.
혹시라도 나비가 꽃잎에 앉기라도 한다면 줄기는 무게를 버티지 못하고 바닥으로 내려 앉을 것이다.
나비가 꿀을 가져가려 길다란 주둥이로 어린 들꽃을 괴롭히는 것을 상상하니 그 연약함이 더욱 아타깝게 다가왔다.

이 꽃을 발견한 이후로 난 내딪는 발걸음 하나도 조심하게 되었다.
사진을 찍으려고 아파트 화단으로 들어 갈때는 항상 발밑을 살피게 되었다.
혹시라도 저렇게 귀여운 아기 들꽃을 밟기라도 할까봐서!

아기 들꽃은 내게 고개숙여 내딪는 발걸음을 살펴보라고 말하는 것 같았다.
삶을 겸손하게 살아가라고 조용히 나에게 알려주는 것 같았다.

Read More

블로그 글쓰기 어떻게 시작하지?

블로그를 막상 시작하자 글쓰기가 너무 어렵게 느껴졌다.
그래서 도서관에서 "이공계 글쓰기 달인" 이라는 책을 대출하여 읽어보았다.
책 표지도 뭔가 재미있게 보였고, 특히 제목에서 이공계 출신을 위해 쓴 책임을 직감할 수 있어서 선택하게 되었다.
책은 전이공 이라는 이공계 출신의 주인공이 학교 선배이자 팀장인 표현정에게 글쓰는 비법을 배워간다는 이야기 형식으로 되어 있다.

다음은 이 책의 내용 중 기억에 남는 글쓰기 팁을 적어보았다.
아래의 내용은 개인적인 판단으로 추출한 책의 일부 내용이다.
이 외에도 이 책에는 많은 글쓰기 팁이 적혀 있으니 직접 읽어보면 좋을 것 같다.

• 사건이 아니라 생각을 써라!

표현력을 키우고 싶다면 먼저 일기를 써보자. 일기가 표현력 향상에 도움이 된다는 것은 당연한 말이다.

<중간 생략>

그러나 대다수 사람이 일기를 쓰지 않는다. 귀챦다기보다는 매일 같은 일상이 반복되는데 굳이 기록할 필요를 느끼지 못해서이다. 어릴 적 처음 일기를 쓰기 시작할 때 '아침에 일어나서 밥을 먹고 친구들과 놀았다. 참 재미난 하루였다'로 며칠을 버티다가 그만둔 경험이 있을 것이다. 하지만 이것을 기억해야 한다. 일상은 반복될 수 있으나 생각은 반복될 수 없다. 특히나 시간은 절대로 반복되지 않는다.

- 104p -

"일상은 반복될 수 있으나 생각은 반복될 수 없다."  라는 문장이 나에게 작은 울림을 주었다.
나도 어렸을 적에 방학 숙제로 일기를 쓰면서 무척 힘들었던 기억이 난다.
특별한 사건도 없는데 일기를 써야하니 왜 힘들지 않았겠는가!
만약 그 때 일기가 사건을 적는 것이 아니라 생각을 적는 것이란 것을 알았다면 일기의 소재가 없어서 고생하지는 않았을 것 같다.
비록 블로그 글쓰기를 배우고 싶어서 이 책을 읽기 시작했지만 이 부분에서는 일기를 쓰고 싶다는 생각이 들었다.
이제는 사건이 아닌 생각을 적는 일기를 쓸 수 있을 것 같았다.

• 거룩할 필요없다, 소소할수록 읽힌다

"음, 너도 예외 없이 거룩병의 굴레에 발목을 잡히는구나."
"거룩병이라뇨?"
"걸룩병이 뭐긴 뭐겠어. 말 그대로 글을 너무 거룩하게 쓰려고 하는 병이지. 이공계 출신들의 특징 중 하나는 글을 지나치게 '크게' 본다는 거야. 그래서 글의 무게에 짓눌려 제대로 쓰지 못해. 일단 이공계출신만이 아니라 모든 사람과 소통하기 위해서는 글을 가지고 '놀아보는' 경험이 필요해."

- 108p -

나도 블로그에 처음 글을 쓰면서 빠졌던 함정이 이 "거룩병" 이었다.
막상 이 병에 걸리자 글을 하나도 쓸 수가 없었다.
계속해서 어떤 글을 쓸지 계획만 세우는 내 모습이 보였다.
그러다가 책의 이 부분을 읽게 되었고, 그제서야 "SW 테스트를 정의해보자!" 라는 글을 적을 수 있었다.
블로그 글쓰기는 논문을 작성하는 것이 아니다.
자신이 쓰는 글의 내용이 틀릴 수도 있다는 것을 인정하고, 좀 더 쉽게 접근하는 것이 좋을 것 같다.

• 반복을 피하는 것이 좋다.

말과 글의 가장 큰 차이점 중 하나는 '반복'이다. 말을 할 때는 반복이 큰 문제가 되지 않는다. 말은 발화되는 순간 사라지기 때문에 상대의 이해를 돕기 위해서라도 어느 정도 반복이 필요하다. 하지만 글은 다르다. 글은 문자로 계속해서 남아 있기 때문에 반복되면 지겨운 느낌이 든다. 하지만 글을 쓰다보면 같은 단어를 자꾸 쓸 수밖에 없는 일이 생긴다. 특히나 서술어의 경우 더 그렇다.

- 159p -

글쓰기에는 퇴고라는 과정이 있다.
글을 쓰고나서, 다시 읽으면서 수정하는 것을 퇴고라고 한다.
블로그 글쓰기의 퇴고는 반복되는 부분을 제거하거나 또는 다르게 표현하는 작업이라고 정의하고 싶다.
대부분의 블로거들이 전문 작가가 아닌 이상 퇴고 시 이 정도만 고쳐도 잘 읽히는 글이 만들어질 것 같다.

• 수동태는 피하는 것이 좋다.

우리말의 논리적인 구조는 능동형에 더 익숙하다. 불가피한 경우를 제외하고는 수동, 피동형 문장은 피하자. 수동형 문장을 쓰게 되면 머릿속에서 주술 구조를 재편집해서 이해해야 한다. 따라서 글을 쓰는 목적이 원활한 의사소통이고 설득이라는 점을 잊지말고 편안한 문장을 쓰도록 하자. 수동태를 피하기 위해서는 사물을 주어로 내세우는 영어식 "물주 구문"을 피하면 된다. '커피가 내게로 온다!' '술이 나를 취하게 만들었다'는 표현은 시적일 수 있지만, 일반적인 글쓰기에서는 어색할 수 있다. 사람 등 감정을 가진 주어를 쓰면 자연스럽게 수동형 문장을 피하게 된다.

- 162p -

만약 블로그 글을 편하게 읽히게 하고 싶다면 수동태를 피해서 쓰는 것도 좋을 것 같다.
내가 쓴 글을 몇 개 확인해 보았더니 생각보다 수동태를 많이 사용하고 있었다.
그래서 수동태를 능동태로 바꿔보았고, 훨씬 읽히기가 쉬운 글로 바뀌는 것을 경험하였다.
블로그 퇴고시에 이 부분도 신경을 쓴다면 좀 더 쉬운 글을 쓸 수 있을 것 같다.


이 책은 이공계 출신으로 글쓰기 훈련이 되어있지 않은 사람이라면 한번 쯤 읽어볼 만한 책이다.
책을 정독할 필요는 없고, 글 중간 중간에 적어놓은 글 쓰기 팁만 읽어도 글쓰기 초보자에게는 많은 도움이 될 것 같다.

Read More

클라우드용 어플리케이션은 뭐가 다를까?

이전글(클라우드 컴퓨팅 이해하기)에서 클라우드 컴퓨팅의 개념을 이해해보았다.

그렇다면 몇가지 의문이 생길 것이다.
SaaS 모델로 클라우드 컴퓨팅이 발전하긴 할텐데 그게 말처럼 쉬운 것일까?
가상화(Virtualization) 기술이 발전하면서 IaaS 에서 PaaS 로는 발전할 수 있었다지만 PaaS에서 SaaS 로 발전하려면 또 어떤 기술이 필요할까?

이런 궁금증을 해결하려면 먼저 클라우드 네이티브 어플리케이션(Cloud Native Application)을 이해해야 한다.
아래 그림은 어플리케이션의 유형과 발전단계를 표현한 그림이다.

• Native Application

PC(Personal Computer) 의 도입으로 모든 프로그램은 PC 에서 실행되어야 했었다.
그래서 처음에 만들어진 어플리케이션(Application)은 돌아갈 PC 환경에 맞도록 패키징(Packaging) 되어 배포되었다.
그러다보니 동일은 어플리케이션도 Window용 Linux용으로 다르게 패키징 되었고, 같은 Window용 어플리케이션도 Window7, Window10 등으로 모두 다르게 패키징되어 배포되었다.
이렇게 패키징되어 배포되었던 어플리케이션을 Native Application(네이티브 어플리케이션)이라고 한다.

• Web Application

PC 환경에 인터넷이 결합하면서 나타난 것이 웹 어플리케이션(Web Application)이다.
웹 어플리케이션은 원격에 있는 서버(Server)에서 어플리케이션이 돌아가고, PC는 인터넷을 통해 서버로부터 정해진 서비스를 제공받는 형태이다.
그래서 PC 의 환경에 따라 어플리케이션을 따로 배포할 필요가 없고, 어플리케이션의 업그레이드도 손쉬운 장점이 있다.
하지만 인터넷이 안 될경우 사용할 수 없고, 인터넷 속도가 느려질 경우 실행 속도가 느려진다는 단점도 있다.
그리고 어플리케이션 사용자는 서버의 서비스를 일방적으로 받는 경우가 많아서 네이티브 어플리케이션(Native Application)에 비해 수동적인 면이 많다.

• Cloud Native Application

클라우드 컴퓨팅 환경이 빠르게 발전하면서 등장한 형태가 클라우드 네이티브 어플리케이션(CNA)이다.
CNA는 SaaS 모델의 환경에서 동작하는 어플리케이션이다.
그래서 인터넷을 통해 서비스 되어진다는 점에서는 웹 어플리케이션과 유사하다.
하지만 CNA는 사용자 스스로 어플리케이션의 설치하고 서비스를 컨트롤(Control)할 수 있다는 점에서 큰 차이를 보인다.


위의 3가지 어플리케이션 유형이 거의 20년 주기로 컴퓨팅 환경의 변화에 맞춰서 새롭게 등장한 것을 볼 수 있다.
현재가 웹 어플리케이션에서 CNA로 변해가는 과정이라고 이해하면 될 것 같다.


이번에는 CNA의 등장배경을 사업(Business) 환경의 관점에서 알아보자.
현재의 사업 환경은 불확실성이 높은 환경이다.
이렇게 불확실성이 높아진 환경에서 사업을 성공으로 이끌기 위해 어플리케이션도 다음과 같은 요구사항을 충족시켜야 한다.

• Speed

신속한 서비스의 배포 및 회수는 비즈니스의 불확실성을 극복할 수 있는 유일한 해법이라고 할수 있다.
또한 잘못된 배포로 인한 손해도 새로운 버젼의 즉각적인 배포로 최소화 할 수 있다.

• Safety

하나의 서비스에서 발생된 장애가 다른 서비스에 전달되지 않아야 한다.
설령 장애가 발생했더라도 빠르게 복구되어 사용자들이 장애발생을 인지하지 못하도록 해야 한다.

• Scalability

서비스 사용량에 대한 과도한 예측으로 발생할 수 있는 자원낭비나 반대로 부족한 사용량 예측으로 인한 서비스 품질 저하등의 문제가 발생하지 않아야 한다.
이를 위해 서비스의 수평적인 확장은 물론 이를 동적으로 적용할 수 있어야 한다.

• Diversity

사용자들이 다양한 채널로 접근할 수 있도록 서비스가 제공 되어야 한다.
최대한 많은 사용자에게 서비스의 기회가 주어져야 한다.

위와 같은 비즈니스 요구사항을 충족하기 위해서 CNA 는 다음과 같은 특징들을 가지고 있어야 한다.

• Services

각각의 서비스는 서로 느슨하게 결합되어 있고, API 를 통해 실행되고 관리되어야 한다.

• Handling Failures

장애가 발생했을 경우 이를 제어할 수 있어야 한다.

• Horizontal Scalability

수평으로 확장이 가능하도록 설계되어야 한다.

• Asynchronous Processing

서비스 요청은 비동기적으로 처리되어야 하고, 큐(Queue)를 사용하여 기능들을 분리해야 한다.

• Stateless Model

모든 데이터는 어플리케이션 코드와 분리 되어야하고, 여러 사용자가 동시에 실행할 수 있어야한다.

• Minimize Human Intervention

사용자의 개입을 최소화 할 수 있도록 신속하고 반복적인 배포(Deploy)가 가능해야 한다.
장애가 발생할 경우 장애를 탐지하고, 손실된 인스턴스(Instance)는 제거한다.
그리고 새로운 노드를 빠르게 생성 할 수 있어야 한다.

Read More