2019년 9월 11일, 회사 Atlassian 기술블로그에 올린 내용입니다.

마크다운 이란?

Markdown은 텍스트 기반의 마크업언어로 2004년 존그루버에 의해 만들어졌으며 쉽게 쓰고 읽을 수 있으며 HTML로 변환이 가능한 문법을 의미합니다.

특수기호와 문자를 이용한 매우 간단한 구조의 문법을 사용하여 웹에서도 보다 빠르게 컨텐츠를 작성하고 보다 직관적으로 인식할 수 있습니다.

마크다운이 최근 각광받기 시작한 이유는 깃헙덕분으로 알고 있습니다.

깃헙의 저장소Repository에 관한 정보를 기록하는 README.md는 깃헙을 사용하는 사람이라면 누구나 가장 먼저 접하게 되는 마크다운 문서입니다.

마크다운을 통해서 설치방법, 소스코드 설명, 이슈 등을 간단하게 기록하고 가독성을 높일 수 있다는 강점이 부각되면서 점점 여러 곳으로 퍼져가게 된되며, 현재 우리가 사용하고 있는 Atlassian 또한, 마크다운 문법을 간략하게는 지원하여, 해당 건에 대해 공유드립니다.

다만, 마크다운 문법의 경우 표준이 없으므로, github 의 마크다운 문법을 별도로 공부하시는 것이 좋으며, github, wiki, Atlassian 에서 비슷하지만 조금씩 다른 결과물, 혹은 지원하지 않는 것들이 있을 수 있습니다.

줄긋기

---

’-‘를 세번 연속으로 치면 문단선이 생깁니다.

마크다운 문법에서는 헤더나, 부제목을 만들기 위해 사용하는데, Atlassian 은 문단을 자르기 위한 용도로 사용됩니다.

(* 와 - 는 같은 값으로 인식합니다. *를 세번입력해도 상관없습니다.)

점표시

-

’-‘를 넣고 한칸띄우기(스페이스)를 누르면, 분단표시가 됩니다. 점표시로 변경하게 되며, 엔터를 키면 계속 목차가 이어지게 됩니다.

여기서 탭을 넣게 되면 dept 형태로 보여지게 됩니다.

’-‘ 하고 스페이스바를 눌렀을 경우

엔터를 치고 탭을 눌렀을 경우

(* 와 - 는 같은 값으로 인식합니다. *를 세번입력해도 상관없습니다.)

글자 크기 키우기

# This is a H1
## This is a h2

This is a H1

This is a H2

This is a H3

This is a H4

This is a H5

This is a H6

’#’을 누르고 한칸 띄우기를 하면 갯수에 따라 H1~H6 까지 자동으로 적용됩니다.

인용 문구 넣기

> 인용문구 넣기

인용문구 넣기

’>’ 를 넣고 한칸 뛰우기를 하면 됩니다. 마크다운 문법에서는 > 를 계속 넣으면서 여러 문용을 입력할 수 있는데, 여기는 단 한번만 넣을 수 있습니다.

링크 문서 삽입하기

Link: [Google](https://google.com) "Go google"

Link: Google “Go google”

[링크를 표시할 명칭] (링크 주소) 를 입력하고 한칸 띄울 경우, 위와 같이 링크 주소는 사라지고 링크명만 보여기데 됩니다.

( < a href=’’ 와 동일한 기능으로 생각해주시면될거같습니다. )

이미지 삽입하기

![불철주야](이미지주소)

위의 링크와 동일하나 앞에 느낌표 ! 를 붙이면 이미지 삽입이 가능합니다. ( <img src=’’ 와 동일한 기능입니다. )

이모티콘

: 를 누르면 이모티콘이 나옵니다.

www.emoji-cheat-sheet.com 에 사용할 수 있는 여러가지 이모티콘이 올라와있으나,

동작을 안하고, ‘:’ 를 입력하면 Atlassian 용 이모티콘이 나오는 것으로 보여집니다.

이외에도 테이블을 표시하거나, 기타 여러가지 마크다운 문법이 있으니 관심있는 분은 조금더 확인하시는것도 나쁘지 않으나 이정도만 하더라도 Atlassian을 조금 이쁘게 꾸미실 수 있을 거라고 생각이 됩니다.

Atlassian 쓰시는 분들은 참고하시기 바랍니다.

CQRS는 Command and Query Responsibility Segregation(명령과 조회의 책임 분리)을 나타냅니다. 커맨드 ( Create - Insert, Update, Delete : 데이터를 변경) 와 쿼리 ( Select - Read : 데이터를 조회)의 책임을 분리한다는 것을 뜻합니다. CQRS는 네이밍에서 알 수 있듯이 명령과 쿼리의 역할을 구분 한다는 겁니다.

너무 단순하다고 생각될지 모르겠지만 이것이 전부입니다. 어쩌면 CQRS에 대한 오해는 CQRS가 생각보다 복잡하지 않기 때문일지도 모릅니다. 이 단순한 규칙이 몇 가지 응용기술과 조합되어 시스템에 적용되면 그 모습은 무척이나 다양합니다. 그만큼 CQRS를 설명하는 정보들이 표현하는 구현체의 모습이 제각각이고 여기서 혼란이 시작될 가능성이 있습니다.

Martin Fowler 형님께서 이미 2011년도에 이야기 하셨던, 등장한지는 조금 오래된 패턴입니다. Martin Fowler는 스택 자료구조의 pop() 연산을 예로 들었습니다. 참고주소 (참고로 버란트 마이어(Bertrand Meyer) 의 CQS가 CQRS의 출발 이었고, CQRS를 처음 소개한 이는 Greg Young 이라고 합니다.)

사업이 점점 번창하게 된다면, 전통적인 CRUD 아키텍처 기반에서 Application을 개발 및 운영하는 개발자들에게는 자연스레 Domain Model의 복잡도가 증가될 겁니다. 그리고 그로 인하여 히스토리를 간직해야할 유지보수 Cost는 지속적으로 증가하게 되며 Domain Model은 점점 설계 시 의도한 방향에서 벗어나게 될 겁니다. 모든 연산이 명령과 조회로 쉽게 양분되지는 않겠지요.

개념적으로 어려운 경우도 있고 동시성 등 기술적인 문제도 있습니다.

이런 일련의 변경사항과 흐름을 곰곰히 관찰해 보며, 단순 검색 및 조회만 하면되는 데이터를, 비즈니스 로직이 거대해지면서 CUD에 의해 변경되는 도메인모델들이 의미없이 늘어나며, 그 모델들을 조인해서 가져와야하는 단순 검색결과들 또한 거대해지게 됩니다.

그리고 그 해답으로 나온 것이 CQRS 입니다. 바로 명령을 처리하는 책임과 조회를 처리하는 책임을 분리 구현 하자는 취지가 바로 이것입니다. CQRS에서 명령은 시스템의 상태를 변경하는 작업을 의미하며 조회는 시스템의 상태를 반환하는 작업을 의미합니다. 정리하면, CQRS는 시스템의 상태를 변경하는 작업과 시스템의 상태를 반환하는 작업의 책임을 분리하는 것입니다.

전통적으로 사용하는 CRUD 모델의 경우 데이터를 갱신하기 위해서는 데이터 저장소에서 해당 데이터를 가져오는 작업이 필요합니다. 동시성 문제가 나타날수도 있고, 확장성을 낮추는 문제점을 지닌 지점이 되기 쉽습니다.

CQRS 의 경우 어떻게 보면 일련의 이벤트를 통해 데이터를 조작하는 접근방식이 될 수 있겠습니다. 데이터에 영향을 주는 모든 동작을 이벤트라는 저수준의 데이터로 관리하는 것으로 여러 문제를 해결할 수 있습니다.

Testing Your Message-Driven Application by Jakub Pilimon @ Spring I/O 2018

서울에서 SPRING ONE 세미나에 참석해서 집적 들어봤습니다. 그때는 우리 솔류션에 적용하기 힘들 것같다고 생각했는데, 어느순간 적용가능한 시점이 다가온거 같네요.

계속 반복해서 이야기하지만, 이름처럼 CQRS는 시스템에서 명령을 처리하는 책임과 조회를 처리하는 책임을 분리하는 것이 CQRS의 핵심입니다.

CQRS를 설명할 때 명령 처리기 패턴(Command Processor Pattern)을 얘기하기도 하고 다른 경우는 다계층 아키텍처(Multitier Architecture)나 이벤트 소싱(Event Sourcing)을 다룹니다. 이것들 모두와 DDD(Domain-Driven Design)를 조합하기도 합니다.

CQRS를 처음으로 소개한 Greg Young은 CQRS는 아주 단순한 패턴(“CQRS is a very simple pattern”)이라고 말했습니다. 경우에 따라 이미 실천하고 있을지도 모릅니다.

보통의 회사라면, 같은 IDE 툴을 사용하도록 어느정도 강제하거나 가이드라인을 정하지만,
본인이 편한대로 일하는 우리 회사는,

인텔리J 를 쓰는 사람과 이클립스를 쓰는 사람이 혼용되어있습니다.

이때 가장 골치아픈 2가지가, 소스 디버거 해줄때, 단축키를 잘… 모르겠네요.

이클립스를 쓰다가 인텔리J 로 오면서 인텔리J 단축키를 외우게 되며, 이클립스 단축키를 잊어버리고 만 겁니다…. 그리고 다른 하나는 툴이 다름으로 오는 문제인데요.

저같은 경우 프로퍼티 문제가 있었습니다.

인텔리J에서 제 프로퍼티는 자동으로 유니코드들을 소문자로 변환해주는데, 이클립스는 그렇게 하지 않더군요.

그래서 이클립스의 경우

Properties Editor

를 설치해서 강제로 소문자로 변환하는 추가 작업을 해줘야합니다.

PS. 저는 여지껏 인텔리J에서 소문자를 자동으로 변환해주는 줄 알았는데,

<IDE_HOME>\bin\idea.properties

경로의 idea.properties 프로퍼티에

idea.native2ascii.lowercase=true

이값을 추가해야한다고 하네요. (왜 여지껏 소문자로 잘 변환되고 있었는지는 의문입니다.)

아마 자동으로 앞글자가 대문자로 변환하는 이슈가 아니라서 그런게 아닌가,

intellij에서 properties파일 name명 자동으로 앞글자 대문자로 변경되는 문제

[MAC] application>intellij 패키지보기>bin>idea.properties
[WIN] C:\Program Files (x86)\JetBrains\IntelliJ IDEA 최신버젼\bin\idea.properties

에서 idea.native2ascii.lowercase=true 추가