지적자본론

2017년 새해 첫 독서. 책은 얇고 작아서 빠르게 읽힌다.
문득 어디선가 추천사를 읽었고 독서 목록에 기록해뒀다가 서점에 갔을 때 눈에 띄는 위치에 있어서 집어들었다.

성공을 거둔 작가가 다소 투박하지만 직접 타이핑쳐서 쓴 듯한 문장은, 내가 좋아하는 스타일이다. 사실 나는 이 책의 저자가 만든 CCC, 츠타야 서점, T포인트 모두 가본 적도 없고 알지도 못한다.

다만 이 기획자(책에서는 디자이너와 기획자를 혼용해서 사용하고 있다)가 바라보는 몇가지 지향점은 나에게 좋은 영감을 주고 나 역시도 기존부터 주장해왔던 것을 재확인한다는 점에서 좋았다.

퍼스트 스테이지에서 상품은 용도만 충족하면 되었다. (…) 세컨드 스테이지는 인프라가 정비되고 상품이 넘쳐나는 시대다. 플랫폼에서 상품을 선택하고 그 플랫폼마저도 넘쳐난다. (…) 서드 스테이지는 제안 능력이 있어야 하는 시대다. 제안을 가시화하는 능력이 없다면, 또 디자이너가 되지 못하면 고객 가치를 높이기는 어렵다. [50p]

위의 문장에서 지금은 세컨드 스테이지 같다. 서드 스테이지를 위해서 개발자들은 추천 엔진(suggestion algorithm) 같은걸 연구하는데 그 이상이어야 한다고 본다. 보통 이런저런 ‘제안하는 로직’만으로 인공지능/머신러닝을 말하지만 그것이 다는 아니라고 생각한다.

일부러 그 분야의 아웃사이더를 담당자로 앉히는 경우가 많다. 이노베이션은 언제나 아웃사이더가 일으킨다. [71p]

우리 회사는 교육에 아무 관심없어 하거나 천대시(?) 하는 사람도 있다. 그 사람들은 보통의 의견에 반대 의견을 자주 내는데, 나는 그런 의견을 매우 중요하게 생각한다.

브랜드 파워는 대차대조표에 기재되지 않는다. (…) 지적자본을 고객가치로 전환시키지 못하면 (…) 보물을 손에 움켜쥐고 썩히는 꼴이다. [131p]

올해 내가 회사에서 가장 주력할 분야다. 이 책은 금융자본의 시대에서 지적자본의 시대로의 이행을 꾸준히 설파하고 있다. 나 역시 동의한다.

효율과 행복은 다르다. 효율은 확실히 편리하고, 편리는 대부분의 경우 쾌적함을 이끌어 낸다. 단, 쾌적함과 행복은 등가가 아니다. (…) 어쩌면 효율과 행복은 서로 반대 방향을 향하고 있는 것이 아닐까. (…) 지적자본이 대차대조표에 실릴 수 없는 것과 마찬가지로 이런 상쾌함과 고양감은 숫자로 측정할 수 없다. [141-142p]

이 부분이 가장 마음에 든다. 나는 제품에서 주구장창 상쾌함을 추구해왔고 그것은 분명 효율만 생각하거나 트렌디한 것과는 다른 궤에 있다.

 

 

장사는 전략이다

앱서비스나 음식점 장사나 일맥상통하는 부분이 있다.

  1. 누군가가 와서
  2. 슬쩍 보거나 몇십분 이용해보고
  3. 나가서 다시는 안오거나 또 온다.

그런 점에서 역사가 오래된 음식점 장사에 대한 노하우가 담긴 책은 많은 영감을 준다. 이 책에서 건진 아이디어 또한 많다.

덧붙여, 과거에 ‘샘앤파커스’라는 출판사에서 나쁜 일들이 있었다는 글을 접했다. 소비자의 1인으로서 악덕기업의 물건에 대해 불매하는 행동을 종종 하지만, 책은 정말 어렵다고 말하고 싶다. 그러니까 책은 옥시나 남양 같은 대체품 서너개 가운데서 선택할 수 있는게 아닌 지식 그 자체이며 지식 자체를 포기할 수는 없기 때문이다.

번역의 탄생

번역을 잘 하고 싶어서 읽은 세번째 책, 추천받아서 읽었지만 한편으로는 정말 힘들게 읽은 책이었다.

모든 내용이 너무 진지하고 훌륭해서 한글자씩 떼어다 읽느라 오래걸렸달까.

이전에 읽은 ‘갈등하는 번역‘은 저자와 함께 공부한다는 느낌을 주는 독특한 구성이 돋보였다면, 이 책은 내일 은퇴하는 노교수가 앞에 처음 앉은 나에게 그동안의 모든 지식을 전달하기 위해서 가끔씩 숨을 가쁘게 쉬며 가르치는 느낌이 들었다.

만약에 영국인이 한국어로 된 책일 많이 번역했다고 가정해볼까요. … 가령 “He said nothing”이라고 쓰지 않고 “Said nothing”이라고 쓰는 영국 작가가 많이 생겨났을 것입니다. [67p]

위의 문장이 재미난 이유는, 내가 실제로 영어를 주어를 생략해서 쓸 때가 있기 때문이다. 물론 다시 읽을 때 고치곤 하지만 손 가는대로 머리 가는대로 쓸 때는 종종 주어를 빼먹는다.

영어 동사를 한국어로 번역할 때는 달랑 한국어 동사 하나로만 번역하지 말고 한국어 부사를 덧붙일 수 있으면 과감히 덧붙여라. [120p]

이 책을 읽으면서 얻은 가장 큰 수확은 위에서 언급한 부사의 재발견이었다. 그래서 이번에 번역한 글에서는 순우리말 부사를 등장시키려고 애썼다. 예를 들어, “수 십년간 개발자들은 이벤트에 대해서 그다지 중요하게 생각하지 않았습니다.”, “이벤트소싱이 딱히 쓸모있지 않다고 생각해도 괜찮습니다.” 등이다.

이제 번역 관련 서적은 여기까지 읽고 또 다른 주제의 책을 읽어야겠다. 이 책은 정보가 너무 많아서 내가 직접 번역하면서 체득하기엔 경험이 더 필요하다.

[번역] 최신 기술 – Event Sourcing 처음 적용하기

원문: https://msdn.microsoft.com/magazine/mt422577

뭐든 큰 변화없이 언제나 뻔하다고 생각하면 어느새 신경도 쓰지 않게 됩니다. 데이터 저장소를 생각할 때 우리는 당연히 데이터의 현재 상태가 저장되어 있겠거니 합니다. 보험, 금융과 같이 큰 규모의 프로젝트는 모든 이력을 정확히 추적하고 기록해야하지만, 그렇지 않은 대부분의 어플리케이션과 웹사이트는 현재 상태만 저장해도 충분합니다.

이처럼 현재 상태를 저장하는 방식은, 시스템의 현재 상태를 스냅샷으로 찍어서 보존한다고 표현할 수 있습니다. 데이터는 보통 관계형데이터베이스에 저장합니다. 이렇게만 해도 새 트랜젝션을 만들고 과거의 트랜젝션 결과를 가져올 수 있습니다. 여기까지가 지난 수 십년간의 ‘뻔한 것’이었습니다.

오늘날 비즈니스는 따라오기 벅찰 정도로 빠르게 변하고 있습니다. 그래서 비즈니스와 도메인에서 일어나는 이벤트를 정확하게 추적해야 하는 경우도 많아졌습니다. 이벤트소싱(ES; Event Sourcing)은 스토리지 설계와 데이터를 저장하고 가져오는 방식에 영향을 주는 패턴입니다. 또한, 도메인에서 비즈니스 이벤트를 저장하고 보는 수준에 그치지 않고 데이터 프로젝션까지 즉시 만들 수 있는 패턴입니다.

이벤트소싱은 비즈니스를 기록하고 살펴보기에 똑똑하고 멋진 방법입니다. 데이터 저장 모델로는 꽤 새로운 이론이며 관계형 모델이 처음 등장했을 때만큼 참신합니다. 최근 등장한 NoSQL 보다 큰 변화를 줄 수도 있습니다. 물론 이벤트소싱은 현재 활발히 사용 중인 관계형이나 NoSQL을 대체하는게 목적은 아니며, 여러분은 이벤트소싱을 이들 둘의 상위 개념으로 구현할 수 있습니다. 이벤트소싱은 특정 시점의 상태로만 취급했던 데이터를 이벤트 단위로 다룹니다. 이벤트소싱을 사용할 수록 우리는 데이터에 대한 시각도 새로워질 것입니다.

이벤트소싱을 적용하면 무엇이 좋은가?

현재 상태만 저장하는 저장 모델에서 한 단계 발전한 형태로 갱신 이력을 추적하는 모델이 있습니다. 서점관리 프로그램을 생각해봅시다. 책마다 설명 속성이 있고 여러분은 속성 수정 권한이 있습니다. 이 때 속성에 대한 수정 이력을 보존해야할까요?

요구사항은 상황마다 다르겠지만, 이번 예시에서는 이러한 변경내역 추적이 중요한 기능이라고 합시다. 어떻게 구현할 수 있을까요? 한가지 방법은, 현재 상태를 저장하는 테이블 하나와 변경 내역을 저장하는 별도의 테이블로 구성하는 것입니다. 업데이트할 때마다 하나의 레코드가 추가되며 업데이트 기록에는 변경한 컬럼과 변경한 내용을 저장합니다.

다른 방법으로 시도해볼까요? 하나의 테이블에 하나의 책에 대해서도 여러 개의 레코드를 기록합니다. 각 레코드는 그림 1과 같이 타임스탬프와 현재 상태를 순서대로 저장합니다.

Multiple Records Hold Entity History
그림 1 엔티티 변경 내역을 여러 개의 레코드로 저장하는 형태

위와 같이 구성하면 현재 상태를 가져오기 위한 별도의 API를 만들어야 합니다. 단순히 레코드ID로 쿼리해서는 최신 상태를 가져올 수 없고 타임스탬프 상의 최신이거나 업데이트카운트가 가장 큰 값을 가져오도록 만들어야 합니다. 입력한 데이터 엔티티에 대한 모든 이벤트는 하나의 흐름으로 표현할 수 있는데, 이처럼 이벤트를 흐름으로 표현하는 것이 이벤트소싱의 핵심입니다. 그러므로 이벤트를 원활하게 추적하는 시스템을 구현하고 싶다면 이벤트소싱이 정답입니다.

기존의 개념 중 이벤트소싱과 관련있어 보이지만 다른 개념도 있습니다. 이벤트소싱이 로깅이나 감시 기능과 유사하다고 생각할 수 있지만, 로깅은 예외 상황이나 프로파일링까지 고려한다는 점에서 다릅니다. 이벤트소싱은 비즈니스 이벤트에 대해서만 다룹니다. 그러므로, 로깅 기능을 구성할 때처럼 여러 도메인과 구조를 관통하는 공통된 역할을 콤포넌트화 하는 작업과도 다릅니다. 이처럼 공통 부분을 정의하는 과정을 Aspect-orient 소프트웨어에서는 공통의 관심사(cross-cutting concern; 횡단관심사라고도 함)라고 하는데 이와는 다른 의미입니다. 이벤트소싱은 데이터를 어떤 구조로 설계하고 저장하는지에 대한 내용으로 봐야 합니다.

이벤트소싱이란

이벤트소싱은 이벤트를 데이터 소스로 간주합니다. 수 십년간 개발자들은 이벤트에 대해서 그다지 중요하게 생각하지 않았습니다. 어쩌면 그런 이유로 이벤트소싱이 주목받지 못했는지도 모릅니다. 이벤트소싱이 딱히 쓸모있지 않다고 생각해도 괜찮습니다. 아직 필요하지 않을 뿐입니다.

이벤트소싱은 도메인 전문가가 이벤트를 순서대로 추적하고 싶을 때 특히 유용합니다. 소극적으로 사용한다면, 워크플로우를 표현하거나 비즈니스 로직을 일원화할 때도 유용합니다. 다만 이처럼 소극적으로 사용할 경우에는 이벤트를 보존할 필요성도 적고 이벤트를 최우선 순위로 취급하지도 않습니다. 이 정도가 요즘 흔히 사용하는 이벤트소싱 시나리오입니다. 이 글에서는 이벤트를 데이터 소스로 사용하도록 하겠습니다.  이벤트소스를 도입하려면 저장소에서 두 가지를 고려해야 합니다. 보존과 쿼리입니다. 여기서 보존이라함은 세가지 핵심 작업과 관련되어 있습니다. 바로 삽입/갱신/삭제입니다. 이벤트소싱 시나리오에서의 삽입은 현재 상태만 보존하는 통상의 시스템과 다를 바 없습니다. 요청을 받으면 새 이벤트로 저장합니다. 이벤트에는 GUID와 같은 고유식별자를 함께 기록하며, 그 외에 해당 이벤트의 타입 이름과 코드, 타임스탬프, 기타 정보도 저장합니다.

이벤트소싱에서 갱신 작업은 삽입의 다른 표현일 뿐입니다. 어떤 프로퍼티가 변경되었고 새 값은 무엇인지, 관련된 비즈니스 도메인이 무엇인지, 그 외에 변경 사유 등을 기록합니다. 갱신이 한 번 일어난 저장소의 데이터는 그림 2와 같습니다.

A New Record Indicates Update to Entity with ID #1
그림 2 Entity ID #1에 대해 갱신이 일어났음

이와 마찬가지로 삭제 작업은 해당 엔티티를 삭제했다는 정보를 ‘삽입’합니다.

갱신 작업은 쿼리할 때 새로운 고민거리를 줍니다. 갱신하기 전에 갱신할 대상이 이미 있는지, 현재 상태가 어떤지는 어떻게 알 수 있을까요? 먼저 간단한 쿼리 레이어를 하나 만들어서 ID를 조회하고, 그 다음 현재의 값에 기반하여 새 값으로 갱신하는 이벤트를 삽입해야 합니다.

예를 들면, Created 이벤트를 먼저 가져온 후 그 내용에 맞추어 새 데이터를 추가하는 방법입니다. 현재 상태의 값은 해당 ID에 대한 모든 이벤트를 조회한 후 처음부터 짚어나가면 구할 수 있습니다. 이런 방법을 ‘이벤트 리플레이’라고 합니다. 하지만 단순히 모든 이벤트를 재생해서 상태를 재구성하는 방법으로는 성능에 큰 문제가 발생합니다. 은행 계좌의 현재 잔액을 알려면 수 년 전의 계좌 개설일부터 현재까지의 모든 거래를 가져와야 할테니까요. 그리 좋은 방법은 아닙니다.

그래서 이와 같이 모든 이벤트를 가져와야 하는 문제를 해결하는 방법 중 하나로 스냅샷을 만드는게 있습니다. 스냅샷은 특정 시점의 상태를 저장한 레코드입니다. 스냅샷을 만들면 적어도 모든 이벤트를 리플레이할 필요는 없습니다.

구현에 있어서, 이벤트소싱은 특정 기술이나 제품이 아닙니다. 그러므로 관계형 데이터베이스를 사용하든 NoSQL을 사용하든 상관 없습니다. 그 대신, 이벤트소싱을 소프트웨어 콤포넌트 개념으로 본다면 ‘이벤트 저장소(event store)’를 구현한다고 말할 수 있겠습니다. 이벤트 저장소는 이벤트 로그를 구현하는 작업과 별반 다를 바 없습니다. 그러므로 최소한의 기능만 충족한다면 데이터베이스가 제공하는 API를 이용하여 직접 만들어도 무방합니다.

이벤트 저장소는 두 가지 전제를 가지고 있습니다. 먼저, 추가만 가능하고 갱신은 없습니다. 삭제 또한 삭제 표식을 추가할 뿐 이벤트를 지우지 않습니다. 둘째, 요청하는 이벤트 ID에 맞게 이벤트 스트림을 반환할 수 있어야 합니다. 이 두가지 기능만 있으면 이벤트 저장소의 기본 요건은 충족됩니다.

이벤스 저장소 구현 시 고려사항

앞서 말했듯이, 이벤트 저장소는 기본 기능만 충족하면 특정 기술과 상관없이 구현할 수 있습니다. 데이터를 보존하는 부분은 보통 관계형 데이터베이스나 NoSQL을 사용합니다. 관계형데이터베이스로 구현한다면 한 이벤트마다 하나의 레코드를 가지도록 하고 하나의 테이블은 하나의 엔티티 타입을 가지도록 구현하는 식입니다.

이벤트는 다양한 포멧이 있습니다. 예를 들어, 모든 이벤트에 공통된 속성도 있지만 그렇지 않을 수도 있습니다. 물론 이벤트가 최대한 공통된 속성을 가질 수록 구현하기에 좋습니다. 그렇게 하기 어렵다면 행 단위(row)로 레코드를 쌓지 않고 SQL Server 2014에 추가된 기능인 Column Store Index를 이용하여 열 단위, 즉 컬럼 하나씩 쌓도록 테이블을 구성할 수도 있습니다. 또 다른 방법이라면, 이벤트를 JSON 오브젝트로 만든 후 이를 문자열로 직렬화하여 하나의 문자열 컬럼에 넣을 수도 있습니다.

NoSQL에서는 다양한 속성을 담은 하나의 레코드를 “도큐먼트”라는 단위로 저장합니다. 일부 NoSQL 제품은 이러한 도큐먼트 저장에 특화되어있습니다. 개발자 입장에서는 클래스를 만들고, 값을 채우고, 그대로 저장하면 끝나므로 아주 간편합니다. 보통은 각 이벤트의 유형 별로 클래스를 만들어서 저장하도록 구현합니다.

진행 중인 프로젝트

이벤트소싱은 아직 구조적으로 성숙한 단계는 아닙니다. 무엇 하나 표준화된 규약이 없기 때문에 이벤트 저장소와 이를 이용한 개발 경험은 계속 발전해나갈 여지가 많습니다. 그러므로 이벤트소싱 솔루션은 직접 만들어도 좋습니다. 이 섹션에서는 이벤트 저장소를 좀 더 구조적으로 만들고 편리하게 다룰 수 있는 도구를 몇가지 소개하겠습니다.

이벤트소싱에 최적화된 이벤트 저장소를 사용하면 이벤트 기록과 읽기 작업에만 집중할 수 있어서 보다 효율적인 개발이 가능합니다. NEventStore (neventstore.org) 프로젝트는 이런 시도 중 하나입니다. 간단히 이벤트를 기록하고 다시 읽을 수 있고, 가장 중요한 점이라면 특정 저장소에 의존하지 않고 이를 선택할 수 있다는 점입니다. 아래 예시는 저장소로 SQL을 사용하고 있습니다.

var store = Wireup.Init()
  .UsingSqlPersistence("connection")
  .InitializeStorageEngine()
  .UsingJsonSerialization()
  .Build();
var stream = store.CreateStream(aggregateId);
stream.Add(new EventMessage { Body = eventToSave });
stream.CommitChanges(aggregateId);
위의 예시는 이벤트를 기록할 때이며, 이벤트를 읽을 때는 스트림을 열고 커밋된 이벤트 컬렉션을 한 흐름으로 볼 수 있습니다.
또 다른 프로젝트로 Event Store (geteventstore.com) 프로젝트가 있습니다. .NET과 HTTP API를 제공하며, 이 API로 이벤트를 취합하고 하나의 스트림으로 관리할 수 있습니다. 이벤트 스트림을 가지고 크게 세 가지의 작업을 할 수 있습니다. (1) 이벤트 쓰기 (2) 가장 최근의 이벤트 또는 이벤트의 특정 구간 읽기 (3) 갱신할 때 받아보기가 가능합니다.
받아보기(subscription) 기능은 기본적으로 스트림에 이벤트를 추가할 때마다 콜백 함수를 호출하지만 그 방식은 세가지로 나뉩니다.
  • Volatile: 설정 시점 이전의 이벤트는 무시합니다. 새로 입력한 이벤트부터 받습니다.
  • Catch-up: 정해진 시작 지점부터 이벤트를 받습니다. 이미 입력된 이벤트도 받을 수 있습니다.
  • Persistent: 하나의 이벤트를 여러 곳에서 받을 수 있습니다. 여러 곳에서 받을 경우에도 최소 한 번(at-least-once)을 보장하며 순서에 상관없이 여러번 받을 수도 있습니다.

(역자 주: 더 자세한 정보는 Event Store 기술문서를 참고해주세요.)

정리

이벤트소싱은 이벤트를 어플리케이션의 데이터소스로 사용합니다. 어플리케이션을 만들 때 데이터의 마지막 상태만 다루는게 아닌 비즈니스 이벤트의 흐름을 기준으로 설계하고 개발할 수 있습니다. 저장하는 이벤트 데이터는 아주 저수준의 정보이므로 현재 상태를 알기 위해서는 별도의 투사(projection) 과정을 거쳐야 합니다. 투사란, 이벤트 리플레이를 하면서 특정 시점에 대한 데이터의 상태값을 만드는 일련의 처리 과정을 말합니다. 이벤트를 이용하면 어떤 형태로든 다양한 형식의 투사 결과를 만들 수 있습니다. 그리하여, 현재의 상태값 또한 다양한 형식으로 맞춰서 구할 수 있습니다.


Dino Esposito “Microsoft .NET: Architecting Applications for the Enterprise” (Microsoft Press, 2014), “Programming ASP.NET MVC 5” (Microsoft Press, 2014)의 공동저자입니다. JetBrains에서 .NET과 안드로이드 분야의 기술 에반젤리스트이며, 세계 곳곳의 여러 행사에서 연사로 활동하고 있습니다. Esposito의 소프트웨어에 대한 비전은 다음 링크에서 볼 수 있습니다.  software2cents.wordpress.com, 트위터: @despos.

이 문서의 리뷰를 한 Microsoft 기술 전문가 Jon Arne Saeteras에게 감사드립니다.

이 문서를 번역한 김영재 교육서비스 바로풀기의 개발사 Bapul의 CTO로서 기술로 교육에 새로운 시각을 주기 위해 열심히 개발하고 있습니다.

[번역] 최신 기술 – CQRS 처음 도입하기

원문: https://msdn.microsoft.com/magazine/mt147237

도메인 주도 개발(이하 DDD;Domain-driven design)은 십여년 전부터 소프트웨어 개발자와 아키텍트들에게 많은 영향을 주었습니다. 분명한 장점과 단점을 모두 가진 DDD이지만, 객체지향 개발자들은 이를 통해 오래된 꿈을 실현하려고 했습니다. 그 꿈은 바로, 모든 이해관계자의 요구사항을 해소해주는 온전한 오브젝트 모델로 응용 프로그램을 만드는 것이지요.

지난 수십 년간, 많은 개발자들은 DDD 가이드라인에 따라 프로젝트를 수행했습니다. 그 중에는 성공한 프로젝트도 실패한 프로젝트도 있습니다. 결국 깨달은 진실이 있다면, 소프트웨어에서 기능적인 요소든 그 외의 요소든 모든 것을 아우른 오브젝트 모델이란 그저 환상일 뿐이라는 것입니다.  특히 요즘처럼 고차원의 UX, 급변하는 비즈니스 모델, 시도때도 없이 달라지는 요구사항이 들이닥치는 바쁜 세상에서 견고하고 안정적인 오브젝트 모델을 만들려는 것은 더 허황된 꿈처럼 느껴집니다.

최근 이에 대한 남다른 해결법으로 주목을 끌고 있는 용어가 있습니다. 바로 Command and Query Responsibility Segregation (CQRS; 명령과 쿼리의 역할구분) 입니다. CQRS가 소프트웨어 개발 방법론에서 새롭게 등장한 개념은 아닙니다. 구현도 그리 복잡하지 않습니다. CQRS는 그저 소프트웨어의 생애주기나 복잡도에 구애받지 않으면서 대부분의 소프트웨어 개발에 적용하기에 적합한 구현 패턴일 뿐입니다.

CQRS를 구현하는 방법은 취향따라 최소 세가지가 있습니다. 여러분이 뭐라고 이름 붙이든 상관없습니다. 호텔방이나 음료수를 구분할 때처럼 일반/프리미엄/디럭스로 이름붙여 봅시다. CQRS로 검색해서 나오는 대부분의 예시와 내용은 대부분 디럭스급이라고 보면 됩니다. 그런 것들은 평범한 어플리케이션에 적용하기엔 너무 복잡하고 과분합니다.

CQRS는 프로젝트의 복잡도와 상관없이 성공적으로 적용할 수 있는 소프트웨어 개발 방법론입니다. 최종적으로 CQRS는 전통적인 다층 레이어 아키텍처를 좀 더 많은 변화를 받아들이도록 재구성하는 것입니다.

명령과 쿼리

버트란드 마이어(Bertrand Meyer)가 1980년대에 Eiffel이라는 프로그래밍 언어를 개발할 때, 소프트웨어는 시스템의 상태를 바꾸는 것과 시스템의 상태를 읽는 두가지의 명령으로 나뉜다고 했습니다. 모든 소프트웨어 명령어는 명령과 쿼리 둘 중 하나라고 말입니다. 둘의 조합된 형태도 아니고 반드시 둘 중 하나에 속해야 합니다. 좀 더 세련된 표현으로 말하자면, 질문을 아무리 해도 답변은 변하지 않아야 합니다. CQRS는 이 이론을 현대적으로 복기한 것입니다. 명령과 쿼리를 구별하여 별개로 구현합니다.

명령과 쿼리를 논리적으로 나누기란 어려운 일입니다. 특히 둘 모두가 동일한 프로그래밍 스택과 동일한 모델을 사용한다면 더더욱 어렵습니다. 복잡한 비즈니스 시나리오에서는 더 어려운데, 왜냐하면 오브젝트든 함수형이든 뭐든간에 어떤 모델이라도 금세 손 쓸 수 없을 정도로 복잡해지곤 하기 때문입니다. 이렇게 모델이 급격하게 커지고 복잡해지면 시간과 예산을 잡아먹고 원래 의도했던대로 동작하지도 않을 것입니다.

CQRS는 기본적으로 쿼리 작업은 쿼리 작업끼리 한 레이어에, 명령 작업은 또 다른 레이어에 그룹핑해서 구분합니다. 각 레이어는 독립적인 데이터 모델과 서비스를 사용하고 독자적인 패턴과 기술을 조합해서 구현합니다. 중요한 점은, 두 레이어를 각자 고유의 2-tier로 구현할 수 있고 최적화도 구분해서 적용함으로써 서로에게 영향을 주지 않도록 하는 것입니다. 그림 1은 CQRS 구조의 기초적인 부분을 보여줍니다.

A Canonical and Multi-­Layered CQRS Architecture 

그림 1 기본적인 다층 레이어의 CQRS 구조

명령과 쿼리를 별개로 인식하면 소프트웨어 구조에 큰 변화를 줄 수 있습니다. 일례로, 각자의 도메인 레이어에 대해서만 모델링하고 코딩하기 때문에 훨씬 단순합니다. 명령 스택은 데이터, 비즈니스, 보안 규칙만 고려해서 개발하고, 쿼리 스택은 가장 간단하게는 DB 커넥션에 SQL 쿼리문만 작성하면 됩니다.

프레젠테이션 계층에 보안 규칙을 넣는다면, 쿼리 스택은 Entity Framework와 같은 ORM을 얇게 감싸고 데이터를 조회하는 수준일겁니다. 도메인 레이어마다 데이터를 해당 도메인의 요구사항에 최대한 맞춰서 표현하기에도 수월합니다. 데이터를 굳이 복사하거나 누더기로 만들지 않고도 말입니다.

DDD가 처음 나왔을 때는 소프트웨어 개발의 복잡함을 따져보려는 의미가 컸습니다. DDD를 시도하는 개발자들은 꾸준히 이 복잡함과 씨름해왔습니다. 대부분은 비즈니스 도메인에 대한 이야기였습니다. 하지만 대부분의 복잡한 것들은 명령과 쿼리의 곱집합 때문이었습니다. 쿼리에서 명령 부분을 떼어내면 복잡도가 한자릿수로 줄어듭니다. 단순히 수학적으로 표현하자면, 통상적인 도메인모델 기반으로 구현한 복잡도가 NxN이라면 CQRS는 N+N인 셈입니다.

CQRS 시작하기

기존의 CRUD 시스템도 얼마든지 CQRS 형태로 바꿀 수 있습니다. 예를 들어 사용자가 다양한 정보를 입력하는 폼이 있는 전통적인 ASP.NET MVC 웹 어플리케이션이 있다고 합시다. 대부분의 어플리케이션이 하는 일이기에 아키텍트들은 어떻게 해야 이런 어플리케이션을 빠르고 효율적으로 만들지 잘 알고 있습니다. 이제 여러분은 이를 CQRS로 재해석해서 만들어볼 것입니다. 아마도 바뀔 부분이 거의 없어서 놀랄 것입니다. 그에 비해 얻는 장점은 너무나 많습니다.

기존의 시스템은 대부분 여러 계층으로 이루어져 있습니다. 여러분의 시스템에 콘트롤러에서 직접 호출하는 어플리케이션 서비스가 있다고 가정해봅시다. 콘트롤러와 어플리케이션 서비스는 웹 서버 안에 있습니다. 그림 1과 같이, 어플리케이션 서비스는 어플리케이션 계층을 이룹니다. 그래서 어플리케이션 계층은 시스템에 명령과 쿼리를 실행하는 플랫폼이기도 합니다. CQRS를 적용한다는 말은 곧 역할이 둘로 구분된 중간계층을 가진다는 말이기도 합니다. 하나는 시스템 상태를 바꾸는 명령에 대한 것이고, 다른 하나는 데이터를 가져오는 것입니다. 그림 2는 이에 따라 ASP.NET MVC 프로젝트의 구조를 나타낸 다이어그램입니다.

 

The CQRS Architecture for an ASP.NET MVC Project
그림 2 ASP.NET MVC 프로젝트에서의 CQRS 구조

먼저 두 개의 클래스 라이브러리 프로젝트를 만듭니다. 쿼리 스택과 명령 스택 라이브러리입니다. 그리고 웹 서버 프로젝트에 모두 참조로 추가합니다.

쿼리 스택

쿼리 스택 클래스는 데이터를 가져오기만 합니다. 개발을 할 때 프리젠테이션 레이어에 최대한 일치하도록 데이터 모델을 만듭니다. 이 때 비즈니스 규칙은 거의 고려할 필요가 없습니다. 왜냐하면 비즈니스 규칙이란 주로 상태를 바꾸는 것이므로 명령 스택에서 구현하기 때문입니다.

DDD에서 유행한 도메인 모델 패턴은 도메인 로직을 조직하는 방법에 대한 것이었습니다. 이렇게 복잡하게 갈 필요 없이, 시스템의 프론트엔드에서 실행할 쿼리를 만들 때는 단지 어플리케이션 로직의 일부와 사용 시나리오만 신경쓰면 됩니다. 실상 ‘비즈니스 로직’이라는 말은, 변하지 않는 도메인 로직 위에 어플리케이션 별 로직을 엮은 결과물입니다. 보여주는 정보의 정해진 형식과 프레젠테이션 포멧을 알면 그저 SQL 쿼리로 나온 데이터를 매핑하는 작업만 해주면 됩니다.

어플리케이션 계층에서 실행하는 모든 코드는 시스템의 비즈니스 도메인을 반영한 결과입니다. 그러므로 시스템의 핵심 로직에 대한 API는 변하지 않아야 합니다. 이상적으로는, 핵심 로직에서 노출된 API는 그 자체로 완전무결해야 합니다. 즉, 어떠한 불일치도 없고 일관된 규칙을 가집니다. 쿼리 스택의 본질은 읽기전용이므로 아래 코드와 같이 Entity Framework 콘텍스트를 간단히 감싸고 있는 클래스를 만들 수 있습니다. 이제 감쌌다는 의미로 wrapper 클래스라고 부르겠습니다.

public class Database : IDisposable
{
  private readonly QueryDbContext _context = new QueryDbContext();
  public IQueryable<Customer> Customers
  {
    get { return _context.Customers; }
  }
  public void Dispose()
  {
   _context.Dispose();
  }
}

위 코드에서 QueryDbContext 클래스는 DbContext 클래스를 상속받았으며, DbSet<T> 콜렉션이 들어있습니다. 여기서는 QueryDbContext 클래스가 데이터베이스의 모든 테이블에 엑세스 할 수 있다고 가정합시다. 이렇게 하면 Linq to Entities 기능으로 쿼리를 수행할 수 있습니다.

쿼리 파이프라인을 만드는 첫 단계는 데이터베이스에 쿼리만 할 수 있도록 설정하는 것입니다. wrapper 클래스가 바로 이런 역할을 합니다. Database 가 IQueryable<T>만 노출하고 있기 때문입니다. 이로써 Database라는 wrapper 클래스를 사용하는 어플리케이션 계층은 쿼리를 구현해서 프리젠테이션으로 데이터를 보낼 수 있게 됩니다.

var model = new RegisterViewModel();
using (var db = new Database())
{
  var list = (from m in db.Customers select m).ToList();
  model.ExistingCustomers = list;
}

위 코드와 같이 데이터 원본과 프리젠테이션은 직접 연결되어있습니다. 이제 데이터를 표시하기 위한 용도로 데이터 읽기와 형식만 다루면 됩니다. 로그인 기능이나 UI에 제한을 둬서 데이터 접근을 제어하고 싶다면, 그저 데이터 접근까지 레이어를 더 추가하거나 IQueryable로 가져오는 데이터 콜렉션을 조절해서 구현할 수 있습니다. 데이터 모델은 데이터베이스와 동일하므로 1:1 관계입니다. 이렇게 IQueryable을 노출한 데이터 모델은 Layered Expression Trees (LET)라는 개념을 적용할 때도 유용하게 사용할 수 있습니다. (*역자주: LET는 Linq를 최대한 활용하여 데이터 모델을 풍부하게 표현하는 방법 중 하나입니다)

지금까지 논의한 내용 중 핵심 몇 가지를 정리해봅시다. 우선, 읽기전용 파이프라인에는 비즈니스 규칙이 없다는 것입니다. 인증 규칙과 필터링 외에는 특별히 고려할게 없습니다. 그리고 인증 규칙이나 필터링은 어플리케이션 계층에서 이미 잘 파악하고 있습니다. 데이터 전송 오브젝트(Data Transfer Object; DTO)를 복잡하게 다루지도 않습니다. 뷰에 표시하는데에 단 하나의 모델과 그 안에 실제 데이터만 있습니다. 그러므로, 어플리케이션 서비스는 아래와 같은 패턴일 것입니다.

var model = SpecificUseCaseViewModel();
model.SomeCollection = new Database()
     .SomeQueryableCollection
     .Where(m => SomeCondition1)
     .Where(m => SomeCondition2)
     .Where(m => SomeCondition3)
     .Select(m => new SpecificUseCaseDto
       {
         // Fill up
       })
     .ToList();
return model;

코드에 있는 데이터 전송 오브젝트는 프리젠테이션 전용으로만 사용하게 됩니다. 클래스를 만드는건 어쩔 수 없지만 그 클래스에는 사용자가 뷰에서 보고 싶어하는 정보만 있습니다. Where 절을 교체하는 IQueryable 확장메소드를 구현해서 그때그때마다 다른 것으로 볼 수 있도록 할 수도 있습니다. 이렇게 하면 특정 도메인에 대해 대화형으로 구현할 수도 있습니다.

쿼리 스택에서 고려할 점이 또 하나 있다면 데이터의 일관성(persistence)입니다. 간단한 형태의 CQRS는 명령과 쿼리 스택을 하나의 데이터베이스로 사용합니다. 이런 공용 구조는 CQRS로 구현해도 전통적인 CRUD 시스템과 유사해보입니다. 그러므로 변화에 저항감이 있는 개발자들에게는 CQRS를 도입하기에 보다 쉬워 보일 수 있습니다. 하지만 나중에는 명령과 쿼리 스택이 별개의 데이터베이스를 사용하도록 백엔드를 디자인해야 합니다. 각자의 목적에 맞도록 최적화해야 하기 때문입니다. 두 데이터베이스의 동기화는 다른 문제이므로 이 글에서 다루지는 않겠습니다.

명령 스택

CQRS 에서 명령 스택은 어플리케이션의 상태를 바꾸는 작업만 합니다. 어플리케이션 계층이 프리젠테이션에서 요청을 받으면 하나의 명령으로 구성한 후 이 명령을 파이프라인에 푸시합니다. 여기서 ‘명령을 파이프라인에 푸시한다’는 표현은 CQRS를 특징짓는 말이기도 합니다.

가장 단순하게는 트랜젝션 스크립트를 실행하는 것이 곧 명령을 푸시하는 것입니다. 트랜젝션 스크립트는 작업에 필요한 모든 과정을 처리한 워크플로우입니다. 그래서 어플리케이션 계층에서 명령을 푸시하는 작업은 아래 코드와 같이 구현할 수 있습니다.

public void Register(RegisterInputModel input)
{
  // Push a command through the stack
  using (var db = new CommandDbContext())
  {
    var c = new Customer {
      FirstName = input.FirstName,
      LastName = input.LastName };
    db.Customers.Add(c);
    db.SaveChanges();
  }
}

비즈니스 로직을 구현한 서비스 도메인 계층과 그에 관련된 도메인 모델을 좀 더 적극적으로 이용하면 보다 복잡한 구성을 만들 수도 있습니다. 하지만 CQRS를 구현하는데 반드시 DDD와 엮을 필요는 없습니다. DDD에서 언급하는 도메인 모델의 집합, 팩토리, 값 오브젝트와 같은 개념을 굳이 다루지 않아도 CQRS 구현에 문제되지 않습니다. 그저 명령과 쿼리의 구분을 명확히 해서 도메인 모델로 인해 만들어지는 복잡성을 줄일 수만 있다면, 그것이 바로 CQRS 도입의 장점일 것입니다.

CQRS 다음은 무엇일까

CQRS의 장점은 명령과 쿼리 파이프라인을 원하는대로 최적화할 수 있으면서도 다른 요소가 깨질 위험은 거의 없다는 것입니다. CQRS를 가장 기초적으로 시도하려면 단일 데이터베이스를 공유하고 어플리케이션 레이어에서 읽기와 쓰기를 별개의 라이브러리로 수행하는 방법이 있습니다.

좀 더 제대로 하려면 여러 개의 데이터베이스를 혼용하여 폴리글랏 저장소로 만들고 쿼리할 때나 이벤트 소싱에 대응하여 조합하는 것입니다. 이벤트 소싱은 명령을 백엔드에 보낼 때 더 유연하게 처리할 수 있으므로 중요합니다. 명령을 버스에 보내고 이를 이벤트로 배포하면 어떤 작업을 새로 정의하거나 수정하는 경우에 이를 플로우 차트를 다루듯이 관리할 수 있기 때문에 보다 유연합니다. 이와 동시에 버스의 성능과 기능을 추가하면 수직적으로 확장하는 효과를 얻을 수도 있습니다.

많은 개발자들이 CQRS에 찬사를 보내지만 대규모의 고차원적인 어플리케이션에만 어울린다고 생각하곤 합니다. CQRS 그 자체는 고수준의  아키텍처도 아니고 특정 기술에 종속적이지도 않습니다. 일부 디자인 패턴에 종속적일 수는 있지만, 단지 디자인 패턴일 뿐입니다. CQRS는 단순하고 강력하며 대부분의 어플리케이션에 잘 맞습니다.


Dino Esposito “Microsoft .NET: Architecting Applications for the Enterprise” (Microsoft Press, 2014), “Programming ASP.NET MVC 5” (Microsoft Press, 2014)의 공동저자입니다. JetBrains에서 .NET과 안드로이드 분야의 기술 에반젤리스트이며, 세계 곳곳의 여러 행사에서 연사로 활동하고 있습니다. Esposito의 소프트웨어에 대한 비전은 다음 링크에서 볼 수 있습니다.  software2cents.wordpress.com, 트위터: @despos.

이 문서의 리뷰를 한 Microsoft 기술 전문가 Jon Arne Saeteras에게 감사드립니다.

이 문서를 번역한 김영재 교육서비스 바로풀기의 개발사 Bapul의 CTO로서 기술로 교육에 새로운 시각을 주기 위해 열심히 개발하고 있습니다.

장사의 신

이자카야 운영에 대한 책.

  • 이자카야를 운영하는 것은 앱서비스와 유사한 결을 가지고 있다.
  • 동네에 돌아다니는 사람이 (=인터넷을 돌아다니는 유저가)
  • 우연히 광고나 관련 글을 페이지를 보고 (=길가에 메뉴판을 보고)
  • 호기심에 문을 열어서 들어가고 (=어떤 앱을 보거나 다운받고)
  • 메뉴판을 보거나 주문해서 몇 점 먹어보고는 (=내비게이션 여기저기를 누르거나 뻘글을 써보고)
  • 걸어나간다. (=앱을 닫는다)
  • 나중에 다시 가거나 (=또 열어보거나)
  • 다시는 안간다. (=지워버린다)

앱서비스에 비해 동네 음식점은 1000년도 넘은 비즈니스다.

그래서 이 책에서는 의외로 많은 아이디어를 얻을 수 있었다. 모든 문장, 모든 장을 읽으면서 ‘우리에게는 어떨까’를 생각할 수 있어서 즐거운 책이었다. 인터넷에 흔히 돌아다니는 UX나 모객 관련 글, 심지어 뭔가 과학적인 Google Analytics를 활용한 글만으로는 피상적으로 느꼈던 아이디어에 대해서도 보다 알맞은 시선을 가질 수도 있게 되었다.

이 책에서 결국 가지고 있는 키워드는 단 하나다 – ‘대화’. 끊임없이 대화를 하라는거다. 리텐션이라는 고상한 단어 하나 없어도 더 와닿는 대화에 대해 생각하도록 한다. 또한, 대기업에 대항하는 작은 곳만의 매력도 한 번 더 깊게 생각할 수 있게 한다.

갈등하는 번역

번역에 대해 보다 체계적인 학습을 하고 싶어서 서점에 가서 책을 찾던 도중 접어든 책이다. 두께는 적당히 두툼한 수준으로, 416페이지 정도다. 대상 독자는 번역을 직업이자 전공으로 하고 싶은 사람들로, 어찌보면 내용은 번역학 개론이기도 하다.

저자는 꾸준히 ‘커뮤니케이션 번역’, ‘커뮤니케이터로서의 번역가’라는 표현을 쓰는데, 번역자의 역할을 매우 능동적인 위치로 두고 있다. 저자와 시간차이를 두고 있는 또다른 저자의 위상과도 같다.

이 책에서 가장 도움을 준 장은 ’22장. 독자를 낚는 그물을 짜는 기술: 표층결속성’과 ’26장. 혼돈 속에서 탄생한 질서: 한국어의 기둥 은/는’이다. 22장은 문장을 시각화한 것이 인상깊고, 26장은 구정보/신정보로 나눈 후 그에 따라 단어와 절의 배치를 가르친다.

또한 이 책의 가치는, 무엇이 좋은 번역이고 어떤 글은 왜 안읽히는지에 대해 정량적으로 분석하고 있다. 표를 제시하면서 각 번역문에 대해 비교한 것은 글을 보다 논리적으로 볼 수 있게 해준다.

물론 우리가 이런 작업을 대화에서 능숙하게, 어려움을 전혀 느끼지 못하고 해낼 수 있는 것은 상대방의 즉각적인 피드백이 있기 때문이다. 하지만 글에서는 그러한 피드백이 없다. 그래서 많은 사람이 글은 혼자 쓰는 것이라고 착각한다. 자기 생각을 늘어놓으면 저절로 글이 된다고 생각한다. 물론 일기나 개인 블로그에 끄저이는 단편적인 감상 같은 것들은 물론 그렇게 써도 상관없을 것이다. (그런 글을 쓰는 것이 ‘글쓰기’에 그다지 도움 되지 않는 것은 이 때문이다). [246p]

블로그를 열심히 하면 뭔가 글쓰기가 나아질거라 생각했는데 다시 돌아보게 하는 글이다.

번역은 언어를 바꾸는 작업이 아니라 목표 독자를 바꾸는 작업이다. 다시 말해 번역이란 가상 독자를 바꿔 글을 다시 쓰는 작업이다. 이것이 바로 번역이다! [296p]

글에서 거의 유일하게 느낌표를 사용한 문장이다.

화제는 동사를 선택하는 기준이 될 뿐만 아니라 글의 전개 방향을 알려주는 깃발과도 같다. [154p]

이 책에서 배운 내용은 화제어, 구정보/신정보다.

원래 이 책을 읽을 후 ‘번역의 탄생’이라는 책을 읽으려고 했는데 너무 많은 내용을 배워서 (마치 한 학기 강의를 들은 것처럼) 한동안 말랑말랑한 내용의 책을 읽어야겠다.

이 책을 읽은 후 문제라면, 기존에 취미로 하던 번역에 대해 한 문장도 쉽게 나가지 못하는거랄까.