%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98

지난 해 썼던 마이크로 서비스 구축 경험 공유 그리고, 김 형준 님 시각으로 쓰여진 Micro Service, Docker로 할 수 밖에 없었던 사연 에 빠진 내용을 써서 공유하고 싶다. 쓰기에 앞서 독자 입장에서 어떤 효용이 있을까 의심스러워 몇 가지 질문을 해본다. 다른 이의 경험은 얼마나 전달될까? 또, 전달 여부는 무엇으로 확인할 수 있을까? 마이크로 서비스에 대해서 독자는 저자와 얼마나 비슷하게 생각하고 있을까? 독자들은 읽고 난 후에 무엇을 기대할까? 아니면 기대없이 읽다가 무엇을 건질 수 있을까?...

팝잇에 예전에 썼던 글의 댓글을 한참 후에 발견했다. 그러던 중, 하나의 글에 달린 댓글에 답변 을 달고 있는데 데자뷰가 느껴졌다. 언젠가 이런 일을 했던 느낌... 다시 아키텍트 란 개념 를 만나다 올 봄, 그러니 무려 7개월 전에 댓글 중 일부에 대한 답으로 다음 글을 썼 다. 어이없었다. 까맣게 잊고 다시 똑같은 댓글을 길게 쓸뻔했다. 하지만, 그러는 중에 아키텍트에 대한 신경을 곤두세웠던 과거의 여운이 다시 날 찾아왔다. 나에겐 애증으로 남은 단어이자 역할이자 하나의 개념이다. 나는 교과서에 나오는 아키텍트 역할에 충실하게 일한 경력이 꽤 된다. 그중 비교적 젊었을 때는 역할에 대한 자부심이 강해서 내 생각과 다르게 일 하면서 '아키텍트'라 칭하고 다니는 일에 대해 반감이 컸다. 어릴 때니 정의감이 더 강했다. 물론, 그것이 우물안에서 규정한 정의감이란 사실을 몰랐을 뿐이지... 여하튼 아키텍트란 일에 대한 프라이드나 애착이 강했다. 그런데 지금은......

아키텍처, 시스템 구성, 모델링, 개발 프로세스를 고민하고 만들었다기 보다는 현재의 조직 구성원으로 서비스를 만들 수 있는 가장 최선의 방법을 선택한 것입니다. 복잡한 것은 만들기 어려우니 아주 잘게 쪼개고, 잘 만들고 있는지도 모르겠으니 일주일에 한번씩 확인하는 방식이었던 것입니다. 우리의 여정 이 11개월째로 접어들 때 합류한 김형준 님이 내 의도를 너무나 잘 정의했다. [1] '꿈보다 해몽'인가? 김형준님의 글, Micro Service, Docker로 할 수 밖에 없었던 사연...

이 글은 SNS를 통해 올려주신 수준 높은 댓글에 대한 제 대답입니다....

이 글은 작년 6월 뉴스피드로 받는 기사 제목 Architects Don’t Decide만 보고 내가 중요하다 생각하는 어떤 것(모호한 것은 모호한 상태라고 명확하게 해두고 개발하는 노하)과 비슷한 글이라 짐작하고 클릭한 행동에서 비롯한 글이다. 원문 기사는 보다 지루해서 그만뒀고, 결과적으로 한동안 잊고 살던 ‘아키텍트’에 대한 생각을 끄집어내게 만들었다....

오픈스택은 프로젝트마다 고유의 기능을 가지면 서로 유기적으로 통신합니다. 프로젝트 간의 통신은 Rest API 로 호출하면, 프로젝트내의 프로세스 간의 통신은 Queue 를 이용하여 통신합니다. 여기서는 간단한 아키텍처와 API 서버가 어떻게 동작하는지 살펴보겠습니다....