해를 등지고 라이딩 하는 경우에는 괜찮은데 해를 마주보며 라이딩하는 경우 너무 눈이 부셔서 앞을 제대로 볼수가 없었다. 

선글라스 고글 이런것들의 필요성을 절감했다.

 

내 헬멧은 풀페이스이기 때문에 고글은 할수가 없어서 선글라스를 무작정 찾아 보았다. 하지만 선글라스의 세계도 참 넓었다. 브랜드, 디자인, 기능 ... 그렇게 무작정 찾아보다 보니 한 키워드가 눈에 들어왔다. 변색 

 

이제 변색렌즈위주로 찾아봤다. 가격대가 2만원대 ~ 40만원대까지 다양했다. 변색에서 중요한 요소는 변색되는 시간인듯하다. 갑자기 터널에 들어가게 되거나 할경우 갑자기 앞이 안보이면 난감하니까. 변색이 가장빠른 브랜드는 루디프로젝트라고 한다. 어떤 유튜브를 보니 루디 프로젝트 렌즈를 망치로 부수는 영상이 있었다. 폴리우레탄으로 만들어졌기 때문에 찢어지긴 하지만 깨지진 않는.. 근데 난 풀페이스헬멧인데... 같은 영상에서 테가 부러지면 얼굴을 뚫을 수 있다는 내용도 있었다. 그 영상의 패널 지인이 그렇게 됐었다고 했다. 근데 루디 프로젝트 테는 휘어지긴해도 부러지진 않았다.  이 외에도 많은 영상과 후기를 보고 루디프로젝트로 브랜드를 정했다. 바이크를 타면서 제 1원칙이 안전이기 때문에 안전장비에 돈을 아끼지 않을 것이다. 

 

모델은 에어그립, 라이돈, 컷라인 중에서 고르려고 하는데 에어그립이 디자인은 제일 맘에 들었지만, 뿔테같은 느낌이라 혹시 부러지면 위험할것 같아서 라이돈으로 거의 맘을 정했다. 이제 오프라인 매장에가서 써보고 구매만 하면된다.

 

변색렌즈를 찾다보니 바튜매에서 누군가 변색필름을 사서 쉴드에 붙이는 시도를 했던글을 보았다. 결과적으로 실패했지만, 변색 ppf 를 붙여주는 업체도 있었다. 그리고 변색 쉴드 자체가 있는 헬멧 모델도 있었다. 내 헬멧도 변색쉴드가 있었다면 쉴드를 샀겠지만 글램스터는 아직 변색쉴드가 없다.

 

선글라스의 경우에는 김서림 문제가 있는것 같다. 

어딘가 좀 멀리 다녀올까 싶었는데 웬지 모를 두려움에 지난주에 둘이 갔었던 커피로드를 혼자서 다녀와 봤다. 

혼자서도 잘 다닐수 있을것 같은 자신감을 얻은듯 보인다.

연휴인데 비가 안오면 춘천까지 함 다녀와 볼란다. 

 

주차장와서 스탠드를 안내리고 내리다가 제꿍을 했다. 마지막까지 긴장을 풀지 말자

8월에 입문 야간 수업을 듣고 어제 기초반 수업을 들었다.

2종 소형 면허를 학원에서 땄는데 처음에 시동거는거 말고는 배운게 없었다. 코스도 유튜브 보면서 스스로 파악했고, 연습도 혼자서 했다. 연습할때도 1단 기어만 넣어놓고 변속을 하지 못하도록 했다. 그렇게 해서 2종 소형 면허를 땄다. 

공도에 나가서 주행할 수 있을까? 하는 분들도 있겠지만 나는 못하겠더라. 그래서 레인조 라이딩 스쿨에서 수업을 듣게 되었다. 

 

입문 수업을 들을때 입문의 내용은 면허 딸때 교육받아야 하는 기초 내용 이라고 설명해주셨다. 입문 수업은 야간으로 들었는데 4시간 정도 했던거 같다. 바이크 시동거는 법, 기어 변속하는 법, 코너링 시 시선 처리, 브레이킹 이런 내용이었고, 바이크를 타기 위한 정말 기초 적인 내용이었다. 내가 원하던 내용이어서 아주 만족 스러웠다.

 

그렇게 한달이 지나 기초 수업을 드게 되었다. 바이크를 받은지는 1주일이 되었고, 공도를 50 키로 정도 탄 상태였다. 근처 100 키로 정도로 투어를 가볼까 했더니 어디를 가든 산길이 나오고 코너링을 해야 하는 구간들이 꼭 포함되어 자신이 없었다. 

기초 수업을 들어보니 공도에서 안전하게 바이크를 타기 위한 기초적인 내용을 알려 주었다.

어제 배웠는데 용어가 벌써 생각이 안난다.

코너링 시 시선처리와 팔에 힘빼기를 주로 실습했고, 니그립, 풀브레이킹, 와리가리? 등을 배우는 수업이었다. 

풀브레이킹이 무서워서 지급까지 한번도 못해봤는데 ABS 가 달린 바이크로 풀브레이킹은 위험할때 사용해도 예전 처럼 위험하지 않다는 것을 몸소 체험할 수 있었다. 

 

비용이 들긴 하지만 안전한 장소에서 이렇게 연습을 할 수 있다는 것은 참 다행스러운 일이다. 

약간 아쉬운 점은 두개조로 실습을 진행하기 때문에 대기 시간이 좀 있다는 점이다. 대기 시간에는 세워져 있는 바이크에서 스로틀 여는 연습이나 기어변속 연습을 할 수 있다.

점심을 좀 늦게 먹고 일찍 근무한 시간을 합쳐 네 시쯤 카페에 가서 커피 한잔하고 왔다

목적지는 윌리로 들어가서 잭으로 주차한다는 윌리앤잭.. 

https://naver.me/xXPY6M8Z

 

윌리앤잭 : 네이버

방문자리뷰 1 · 블로그리뷰 10

m.place.naver.com

집에서 13km .. 

아이스 아메리카노를 마셨는데 특별히 맛있는걸 느끼진 못했고, 낮 시간이라 그런지 먼저 가 있던 형님과 한테이블 손님이 있었다. 

복귀하려고 할때 바이크 두대가 주차 중이었음. 

좋은 점은 집에는 없는 헬멧 컨디셔너가 한쪽에 구비되어 있었다는 것. 집에서는 손 선풍기로 헬멧을 건조하는데 파란불빛으로 살균도하고 건조도 하니 헬멧이 깨끗해진 느낌이다. 

집에 오면서 또 더렵혀 져서 손 선풍기로 건조

 

첫 카페보다 약간 더 멀고 차도 더 많고 했지만, 무사히 다녀왔다. 해질녘에 다녀오니 고글이 절실히 필요해졌다. 너무 눈부셔

변색고글 알아봐야지

아침 10시 처음으로 목적지를 정하고 바이크를 탔다

길이 막히지 않고 괜찮은 카페 일것 같은 곳을 찾아냈고 첫 번째 목적지가 되었다.

 

https://naver.me/GDclC8T2

 

커피로드 : 네이버

방문자리뷰 120 · 블로그리뷰 21

m.place.naver.com

의욕이 너무 앞섰는지 오픈하기도 전에 도착하여 옆에 있는 당고개 냉면에서 시간을 좀 떼우고 와보니 내 바이크에 무서운 사마귀가 앉아 있었다. 근처에서 무기가 될만한 것을 찾아보니 마침 집게가 있어 그것을 들고 사마귀를 몰아낼 수 있었다.

 

카페에 들어가니 입구에 R18 이 후덜덜한 존재감을 뽐내고 있었다. 

커피맛은 잘 모르지만 괜찮았던것 같고 2층에 자를 잡았는데 산을 배경으로 주차되어 있는 내 바이크를 볼 수 있었다.

집에서 가까운 거리였지만 첫 카페바리를 무사히 마치고 복귀했다.

 

아주 오래전부터 하고 싶었던 취미 생활을 드디어 할 수있게 되었다.

 

학생때 비트 만화책을 보고 영화를 보면서 바이크를 타보고 싶다는 생각을 했었다. 그래서 잡지도 사보고 하다가 하야부사라는 오토바이가 너무 멋있어 보여 타고 싶었었는데.. 나의 인심으로는 역부족인 시트고를 보며 포기했었다.

 

2018년 혼자 통영 여행을 하면서 하루 스쿠터를 렌트해서 타고 다녔었다. 최고시속 50km 의 아주 느린 바이크지만 너무 신나고 재밌었다. 그렇게 또 잊고 지내다 2022년 제주도에 사는 친구가 바이크를 탄다는 얘기를 들었고, 제주도에 놀러가서 110 cc 벤리를 렌트해서 하루를 같이 탔다. 친구의 바이크는 bmw r9t 따라 갈수가 없었지만 제주도의 해변도로를 스쿠터를 타고 도는 기분은 끝내줬다

 

집으로 돌아와 와이프를 슬쩍 떠보니 죽어도 안된단다.. 바이크를 찾아보고 바이크 유투브만 보는 생활이 몇달간 이어졌다. 그러다 가족 모두 2주간 제주도에 여행을 다녀오기로 하고 제주도 친구 가족들과도 만남을 가졌다. 그 자리에서 와이프가 설득 되었다

 

돌아와 2종 소형 면허를 먼저 땄다. 학원에 등록해서 땄는데 3시간쯤 부터 코스가 너무 쉽게 느껴졌고 같은 코스를 도는 거였지만 너무 재미있었다. 시험에서 떨어질거라고는 생각도 안했는데.. 1번 떨어졌다..

 

내가 타고싶은 바이크는 인디언 스카우트 바버 였는데 돈이 없어서 살 수없었다. 결국 로얄엔필드의 메테오350을 샀고 어제 집으로 왔다.

어제 부터 조금씩 타고 있는데 로우시트에도 불구하고 내 소심한 인심으로는 너무 시트고가 높다 어제는 우꿍 오늘은 좌꿍 한번씩했다.

 

오늘은 던전을 탈출하여 기름도 넣고 동네도 몇 바퀴 돌았는데 스쿠터 탈때는 별로 무섭다는 생각이 안들었는데 익숙하지 않은 수동 변속을 하면서 도로에 나가니 너무 긴장되었다. 

 

내일은 주말이니 한적한 이른 아침에 바이크를 타도록 해야겠다

auto optimize import : preferences > Editor > General > Auto import > Optimize imports on the fly

usages(사용수를 보여줌) : preferences > Editor > Inlay Hints > Java > Code vision > Usages

2,3년전부터 은퇴에 대한 두려움이 생겼다.

회사를 짤리면 어떻하지.. 나이먹고 아프면 어떻하지.. 아이 학비는.. 언젠가 회사를 그만두게 될텐데 그러면 무슨돈으로 생활하지.. 등등

어떤 책에서 은퇴를 하려면 구체적으로 얼마가 필요할지 계산해보라는 내용을 읽었고, 계산을 해보니 30억 정도가 필요해 보였다. 현재 내나이에 10년정도 일을 더 할 수 있다면 맥스일텐데 30억을 모으기는 도저히 불가능해 보였다. 17,8년을 일을 하면서 모은돈을 생각해 봤을때 정말 택도 없는 금액이었다.

그러면서 투자에 대해 고민하게 되었고, 투자말고는 방법이 없어보였다. 그리고 투자를 시작했다. 

 

2010년 결혼 4년차 아들이 태어나면서 안정적인 주거에 대한 필요가 생겼고, 부동산 시세와 관계없이 살기 좋은 곳으로 주택을 마련했다. 살기 좋은 곳에 대한 우리의 기준은 당시 맞벌이 였기 때문에 아이를 돌봐줄 수 있는 부모님 댁 근처, 출퇴근이 편한 역세권 이 두가지가 가장 큰 기준이었던것 같다.

비록 2/3는 대출이고 22평의 작고 낡은 아파트였지만 전세에서 자가로 바뀌면서 느껴지는 안정감은 생각보다 훨씬 더 컸던것 같다. 당시 대출이자가 지금에 비하면 엄청 높았지만, 맞벌이 였기 때문에 큰 부담은 없었다. 후에 아내가 회사를 그만두고 외벌이를 하게 되었지만, 금리가 내려가 낮은 이율로 대출을 갈아타면서 이자부담이 줄어 들었고, 아내가 재택근무로 할수 있는 일을 하게되어 내 심적인 부담도 줄어들었었다. 

아들이 점점 자라서 초등학교를 입학할때가 되다보니 좀 더 넒은집이 필요해졌고 새아파트로 가고 싶은 생각이 들어 청약을 알아보게 되었고, 몇 군데 모델하우스를 둘러보고 청약에 당첨되었고 2018년 새집에 입주하게 되었다. 

이때부터 자연스럽게 투자에 대해 조금씩 관심이 생기기 시작했다. 살고 있던 집이 점점 가격이 올라가고 있었고 입주할때쯤에는 매매가가 두배쯤 올라 있었다. 분위기는 좀 더 올라갈것 같았고, 입주시점에 기존집을 매도하지 않고 일시적 2주택비과세로 가져가기로 하고 전세를 주었다. 당시에는 일시적 2주택 비과세기준이 3년내 양도 였기 때문에 3년동안 더 보유할 수 있었다.

 

2019년부터 은퇴에 대한 불안함이 생기고 양도 차익이 많지는 않았지만 그래도 평생 처음으로 여유자금이란 것을 가지게 되다보니 투자에 더 많은 관심을 가지게 되었다. 주식은 한번 실패한 경험이 있어, 부동산 투자가 더 끌렸던것 같다. 부동산 투자로 방향을 정하고 강의를 듣고 관련책을 사서 보고 임장을 다녔다. 2020년부터 코로나로 인해 부동산을 간다거나 집을 본다거나 할수는 없었고, 차안에서나 도보로 주변을 둘러보는게 임장의 전부 였지만, 와이프와 함께 다니면서 맛있는 것도 사먹고 투자를 한다는 새로운것에 대한 도전으로 재미도 있었던것 같다. 이때부터 은퇴에 대한 불안함도 조금씩 줄어들었다.

 

2020년 입주후 2년이 되는 시점에 기존 집을 매도하기로 결정하고 4월에 계약하고 6월말에 잔금을 치뤘다. 10년을 갖고 있던 집이지만 3,4년 사이에 엄청올라 매수금액보다 2.5배 정도 올라 있었다. 매도 후 1년사이에 처음 매수했던 금액만큼 더 올라 있었지만 아쉽다기 보다는 참 놀라운 경험이었던거 같다. 

그 돈을 시드머니로 새로운 투자처를 찾기위해 강동, 일산, 의정부, 평촌, 분당, 김포, 부천, 울산등을 둘러보았다. 다른곳은 너무 비싸서 엄두가 안나고 결과적으로 기존 집 계약 후 잔금 치루기 전 5월에 비조정지역이었던 일산과 의정부의 분양권을 매수했다. 김포도 하나더 살까 하다가 일산과 지역이 겹치고 검단의 공급량으로 인해 한동안은 안오를것 같다고 판단했다. 완전한 오판이었다.

잔금은 기존 집 잔금일 이후로 계약을 했는데 그 사이에 6.17 대책이 나오면서 일산과 의정부가 조정지역으로 변경되어 중도금 대출이 안될 위기에 처했고, 입주기간이 많이 남은 일산은 잔금 일정을 당겨서 6/18에 잔금을 치뤄 중도금 대출을 받고, 의정부는 입주기간이 얼마남지 않았기도 해서중도금 대출을 받지 않고 기존 집 매도후 남은 잔금과 신용대출을 이용해서 겨우 잔금을 치룰 수 있었다.

 

2020년말 의정부가 입주를 시작했고 전세로 세를 놓았지만, 생각보다 쉽게 전세가 빠지지 않았고, 마음은 점점 조급해져가고 있는데 부동산에서는 월세는 생각이 없느냐고 물어왔다. 아내와 고민을 해보고 취득세 중과때문에 어차피 더이상 투자는 힘들것이라 생각되어 월세를 놓기로 결정하고 그후로 얼마나 후회를 했는지 모른다. 아파트가 아니라고 해도 오피스텔, 지산, 상가등 투자처는 많았고 난 돈이 없을 뿐이었다.

 

2021년 일산, 의정부, 현재 사는집까지 모두 오르고 있는데 실제 수중에 들어오는 돈은 없고 일산까지 등기치게되면 종부세도 부담이 될것 같고 팔자니 양도세가 너무 많았다. 결국 난생처음으로 세무상담이란것을 받아봤다. 상담 결과는 일시적 2주택 비과세에 초점이 맞춰졌고, 일산 등기후 의정부를 팔면 일시적 1가구 2주택 비과세가 가능하여 의정부, 현재 집, 일산 순으로 매도를 하고 똘똘한 한채로 가기로 결정하였다. 하지만 의정부가 월세로 되어 있어 매도가 안될것 같았다. 다 포기하고 다주택자로 버텨보기로 했다.

 

2021년말 의정부 세입자한테서 연락이 왔다. 내년 1월에 분양받은 집으로 입주를 해야 해서 집을 빼야 한단다. 너무 기뻤다. 드디어 의정부를 팔 수 있게 되었구나. 하지만 세상일은 그렇게 쉽게 흘러가지 않았다. 11월 3주택에서 한채 매도후 일시적 1가구 2주택에 대한 유권해석이 기재부에서 나왔고, 결국 계획했던대로 진행할 수는 없었다. 다시 고민이 시작됐고 새로운 플랜을 세웠다. 의정부를 팔더라도 일산이 비조정지역이었기 때문에 3년내에 현재집을 팔면 일시적 1가구 2주택이 가능하다는 것을 알게 되었다. 일산 등기 후 의정부를 1년내에 매도하고, 현재 집을 최종 1주택 조건에 맞춰 2년을 더 가지고 있다가 일산 등기 후 3년이 되기전에 팔기로 플랜을 세웠다.

의정부를 매도로 내놨지만 갑작스런 거래절벽으로 집을 보러 오는 사람이 없다. 일산 비과세를 위해서는 입주를 해야 하는데 아내가 아들 초등학교 졸업전에는 일산으로 갈 수 없다고 하여 등기 1년후 입주를 하기로 하고 단기 임대 월세를 주었는데.. 의정부가 팔려야 내년초에 잔금을 치룰 수 있다 그런데 거래 절벽 ㅎㅎㅎ 

이제 내년 잔금을 어떻게 치룰지 대책을 마련중이다. 빨리 의정부가 팔리길 기도하고 있다.

참 쉽지가 않네.

 

일산과 의정부의 분양권을 산것은 아무런 전략없이 돈이 부족하다보니 투자금이 적게 들어가는 비조정지역 분양권을 산거였는데 일산의 경우는 비과세까지 가능하게 되어 참 운이 좋았던것 같다. 좋은 부동산중개사를 만난것도 행운이었다. 일산과 의정부가 동일한 조건이었는데 일산의 경우는 부동산에서 잔금일을 당기도록 조언도 해주고 매도자와 협의도 해줘서 비조정일때  잔금을 치룰수 있었고 이로인해 많은 이득을 볼 수 있게 되었다.

 

사람이 참 간사한게 투자를 처음 시작할때는 양도세는 어차피 번거에서 내는거니 양도세를 낼 수 있으면 좋겠다 생각했었는데 내야할 세금이 내 수중에 들어오는 돈보다 많아지니 세금을 어떻게 줄일 수 있을지를 고민하게 되더군. 

 

짧은 경험과 두번의 상담 결과 자산이 어느정도 수준에 이르기까지는 일시적 1가구 2주택 비과세를 잘 활용해야 할 것 같다

 

은퇴를 고민하게 되며 투자를 시작하게 된건 참 다행인것 같다. 그리고 그동안 열심히 살아왔던것도 잘 한일 같다. 어느정도 수준의 근로소득이 있었기 때문에 투자도 할 수 있었던 것이라 생각한다. 지금은 투자와 근로소득(일) 의 균형을 맞추며 일을 할 수 없을때까지 즐겁게 두가지를 병행할 수 있을것 같다.

 

투자를 부부가 같이 한다는 것도 중요한 것 같다. 내가 신경을 쓸 수 없는 근무시간에는 아내가 주로 투자와 관련된일을 하고, 매수/매도에 대한 결정을 할때는 아내와 논의해서 결정할 수 있고, 임장도 같이 갈 수 있고 어떤 일을 아내와 한다는 것이 가끔은 전우애 같은것을 느끼기고 했던것 같다. 

 

내 관점에서 쓰다보니 후에 기억력이 줄어들때쯤 이글을 내가 다시 본다면 투자를 내가 한것처럼 느낄지도 모르겠다. 아니다 속지마라 모든 투자의 주는 아내였고 나는 부였다.

 

아직 은퇴를 위한 목표 금액을 다 모으지 못했지만 은퇴까지 남은 기간동안 목표달성을 위해 계속 투자할 것이다

스톡옵션을 행사하며 알게 된 사항들을 정리함

국내의 경우는 다를지도 모름

 

스톡옵션의 단계

  • grant(부여) -> vest -> exercise(행사) -> 양도

행사

  • 행사시점부터 세금을 내도록 되어 있고 예전에는 을종근로소득이라 불렸으나 현재는 갑종과 을종을 구분하지 않는듯 보임.
  • 어쨌든 근로소득이라 근로소득세를 내야 함
  • 근로소득세 = (행사시점의 가격 - 부여시점의 가격) * 베스팅 수 * 과세율
  • 행사시점의 가격은 행사 시점에 회사에서 알려줌
  • 세금 신고 시점 및 방법
    • 행사 후 다음 해 5월 개인이 신고
    • 납세 조합을 통한 세금신고
      • 행사 후 익월 5일까지 세금 납부 시 5.5% 를 공제해 줌
      • 다음 해 연말정산에 포함됨
      • 비용발생 : 만원(납세조합에 따라 다를지도 모름)

양도

  • 해외주식 양도세 22%(양도세 + 주민세)
  • 양도세 = (시가 - 행사가) * 매매 주식 수 * 0.22
  • 양도 다음해 5월까지 개인 세금 신고
  • 양도세는 납세조합을 이용할 수 없음

 

 

패턴 및 설계상의 일반적인 의사 결정

  • 적절한 마이크로서비스 경계 설정
    • DDD의 Bounded Context 개념
    • Bounded Context는 일반적으로 결합도가 낮으며, 때로는 아예 연결돼 있지 않기도 한다. 하나의 마이크로서비스에 대응 가능
    • 조직 구조도에 내재된 문제가 없다면 조직구조도에 따라 Bounded Context를 설정하는것이 현실적으로 가장 단순한 방법
    • 하향식 도메인 분해도 Bounded Context를 도출하는데 도움이 된다.
    • 마이크로서비스의 경계를 설계하는 가장 실용적인 방법은 가능한 여러가지 선택사항에 대해 서비스 리트머스 테스트를 했던 것처럼 손으로 시나리오를 돌려보는 것이다
      • 자율적인 기능 : 입력을 받아 내부의 로직과 데이터로 계산해서 결과를 반환
      • 암호화 엔진, 알림엔진 같은 유틸리티 기능이 적합
    • 배포단위의 크기 : 관리할 수 있는 수준 이내로 유지할 수 있어야 함
    • 분리하기에 가장 적합한 기능 또는 서브도메인
      • 자원소모량, 소유비용, 비즈니스 효용성, 유연성 등이 분석 기준
    • 폴리글랏 아키텍처
    • 선택적 확장 : 모든 기능 모듈이 모두 동일한 수준의 확장성을 필요로 하지는 않는다
      • 확장에 관한 요구사항을 기준으로 마이크로서비스의 경계를 결정
    • 작고 애자일한 팀
      • 전체 중에서 서로 다른 일부를 개발하는 데 집중할 수 있는 작고 집중력 있는 팀 구성을 통해 애자일 방식의 개발을 가능하게 해준다
    • 단일 책임
      • 책임을 비즈니스 범위 또는 하나의 기술 범위로 치환해서 생각하는 것이 더 현실적임
      • 하나의 마이크로서비스는 여러가지 책임을 담당해서는 안 된다
    • 복제가능성과 변경 가능성
      • 마이크로서비스가 전체 시스템에서 최소한의 재작성 비용 투입만으로 쉽게 떼어져 나올 수 있는지를 기준으로 식별돼야 한다.
    • 결합과 응집
      • 기능분해도는 의존관계트리와 함께 마이크로서비스의 경계를 수립하는데 도움을 줌
      • 트랜잭션 범위가 하나의 마이크로서비스의 범위를 넘어서 여러 마이크로서비스에 걸치지 않게 하는 것도 중요
      • 이벤트를 입력으로 받아 내부적으로 몇개의 함수를 호출하고 최종적으로 새로운이벤트를 반환하는 방식으로 반응하는 것이 기본
    • 마이크로서비스를 하나의 제품으로 생각하기
  • 통신 방식 설계
    • 먼저 요청-응답 동기방식으로 시작해서 나중에 필요하다고 판단될 때 비동기 방식으로 리팩터링
  • 마이크로서비스 조립(composability)
    • 오케스트레이션(orchestration) 방식과 연출(choreography)방식이 있음
    • 여러개의 서비스를 모아 하나의 완전한 기능을 만들고 오케스트레이터가 중앙의 두뇌 역할 담당
      • SOA에서는 ESB가 담당
    • 연출방식은 이벤트 생산자가 이벤트를 생상하고 소비자가 대기하고 있다가 소비하는 방식
    • MSA에서는 연출방식이 더 적합하지만 모든 사례에 연출방식으로 모델링하는 것은 불가능 함
  • 마이크로서비스 하나에 얼마나 많은 종단점을 둘 것인가?
    • 종단점의 수는 중요한 결정 사항이 아니다. 하나의 마이크로서비스는 하나 또는 그 이상의 종단점을 가질 수 있다. 마이크로서비스 크기에 적합하게 경계지어진 컨텍스트를 적절하게 설계하는 것이 훨씬 더 중요
  • 가상머신 하나당 하나의 마이크로서비스 또는 다수의 마이크로서비스?
    • 가상머신이 최대 사용치를 기준으로 두 걔의 서비스를 운영하기에 용량이 부족한가?
    • SLA를 충족시키기 위해 서비스들이 별도로 처리돼야 하는가?
    • 자원 요구사항이 서로 충돌되지는 않는가?
    • 3가지 질무에 No라고 답할 수 있다면 가능하지만 서비스들이 서로 어떤것도 공유하지 않으며, OS 프로세스와 독립적으로 실행된다는 점이 보장돼어야 함
  • 룰 엔진 공유 또는 내장?
    • 룰 엔진은 생산성을 높이고, 룰, 사실정보, 용어의 재사용을 가능하게 하며, rete알고리듬을 통해 룰을 더 빨리 실행할 수 있게 해준다
    • 룰이 단순하고 수적으로도 적고 서비스의 경계 내에서만 사용되며 룰 작성이 외부의 비즈니스 사용자에게 공개되지 않는다면 코딩하는것이 더 나을 수 있음
    • 룰이 복잡하고 서비스 컨텍스트에 국한되며 비즈니스 사용자에게 부여되지 않는다면 서비스 내부에 내장된 룰 엔진을 두는 편이 더 낫다
    • 룰이 비즈니스에 의해 작성되고 관리되거나, 룰이 복잡하거나, 룰이 서비스도메인 외부에서도 재사용된다면 외부에 있는 중앙저장소와 시스템 내부에 내장된 실행 엔진을 사용하는 것이 좋다
  • BPM의 역할과 작업흐름
    • 시스템과 사람의 상호작용을 자동화함으로써 전 구간의 여러기능에 걸쳐있는 비즈니스 프로세스를 모델링하는 상황에서 여러개의 마이크로서비스를 조합하는 상위 수준에서 사용가능
  • 마이크로서비스가 데이터 스토어를 공유할 수 있는가?
    • 공유데이터 모델, 공유 스키마, 공유테이블은 좋지 못한 방법이며, 마이크로서비스 개발을 재앙으로 이끌수도 있다
  • 서비스 종단점 설계 고려 사항
    • 계약설계
      • KISS(keep it simple stupid) : 더 나은 양질의 서비스를 더 빠르게 구축하고 유지 관리와 교체에 드는 비용을 줄여준다. YAGNI(you ain't Gonna need it). 단순함 중시
      • 소비자 중심 계약(Consumer Driven Contracts) : 사용자가 원하는 기대 사항을 서비스 제공자에게 테스트 케이스의 형태로 제공하게 함으로써 서비스 계약이 변경될 때마다 서비스 제공자가 통합테스트할 수 있게 해준다
    • 프로토콜 선택
      • 메시지지향서비스 : JMS/AMQP 프로토콜로 json 데이터 교환, 처리시간이 오래걸리는 작업에 적합
      • HTTP : 호환성, 프로토콜 처리, 트래픽 라우팅, 로드 밸런싱, 보안시스템등에 적합
      • REST : MSA 기본 선택 옵션, 
      • 최적화된 통신 프로토콜 : Avro, Protocol Buffers, Thrift 성능은 높이고 호환성은 떨어지게 됨
    • API 문서화 : Swagger, RAML, API Blueprint
  • 공유 라이브러리 처리
    • 자율성과 자기완비성 원칙을 준수하기 위해 코드와 라이브러리를 복제해야 하는 상황이 있을 수 있다
    • 비즈니스 범위나 분류관점에서 봤을때 하나의 마이크로서비스로 분류되지 않는 부분을 공통이라는 이유만으로 별도의 마이크로서비스로 떼어낸다면 효용보다 복잡성 증가라는 비용이 더 클 수도 있다
  • 마이크로서비스에서 API게이트웨이 사용
    • 서버는 화면까지 제공하기보다 RESTful서비스를 노출하는 방식으로 개발
    • 계약에 대한 기대사항의 불일치, 하나의 페이지를 렌더링하기 위해 서버에 여러번의 요청을 날리는 문제점이 있음
    • 해결방안
      • HATEOAS방식으로 최소한의 정보만을 링크정보와 함께 전달
      • 클라이언트가 요청 시 쿼리 문자열로 필요한 필드를 지정해서 요청
      • 간접화 개념 사용, 클라이언트와 서버 사이에 있는 게이트웨이 컴포넌트가 데이터 소비자의 명세에 따라 데이터를 변환
    • API 게이트웨이를 사용하는 목적에 따라 선택이 달라짐
      • 리버스 프록시 용도 : Apigee, Mashery 같은 서비스를 공유되는 플랫폼으로 사용
      • 트래픽 유형에 따른 세부적인 제어가 필요하고 복잡한 데이터 변환이 수반된다면 서비스당 독자저인 API게이트웨이 사용
  • ESB 및 iPass와 마이크로서비스의 사용
    • ESB의 역할
      • MSA에 적합하게 기능이 제한된 ESB역할은 API 게이트웨이로 대체
      • 오케스트레이션 역할은 ESB 버스에서 마이크로 서비스로 이동
      • 프로토콜 중재 역시 더 범용적인 메시지 교환 방식사용으로 필요하지 않음
      • 레거시 시스템과 연결해주는 어댑터 기능은 서비스 스스로가 구체적인 구현체를 제공하므로 필요 없음
      • 엔터프라이즈 수준에서 레거시와의 통합과 솔루션 회사의 애플리케이션을 통합하는데 존재 가치가 있음
  • 서비스 버저닝 고려사항
    • 시맨틱 버전이 널리 사용됨
      • 메이저, 마이너, 패치의 세가지 컴포넌트로 구성
      • 메이저 : 호환이 안될수도 있는 대규모 변경
      • 마이너 : 하위 호환을 유지하는 한도 내에서의 변경
      • 패치 : 버그수정
    • REST 버저닝 방식
      • URI 버저닝 : 대부분이 사용
      • 미디어 타입 버저닝
      • 커스텀 헤더
  • 크로스 오리진 설계
    • 마이크로서비스에서는 서비스가 동일한 호스트나 동일한 도메인에서 운영된다는 보장이 없음
    • 신뢰하는 다른 도메인으로부터의 크로스오리진 요청을 모든 마이크로서비스가 허용하게 하는 것
    • 클라이언트가 신뢰하는 도메인에 API 게이트웨이를 두는 것
  • 공유 참조 데이터 처리
    • 상대적으로 정적이고 변경될 가능성이 전혀 없는 데이터는 각 서비스에서 하드코드로 관리
    • 공통으로 사용되는 데이터를 별도의 마이크로서비스로 분리
    • 데이터를 모든 서비스에 복제
    • 필요한 데이터를 로컬에 캐시
  • 마이크로서비스와 대규모 데이터 작업
    • 데이터가 생성될때 사전 집계
    • 배치 API

 마이크로서비스의 과제

  • 데이터 섬
    • 마이크로서비스를 적용하면 데이터가 파편화돼 이질적인 데이터 섬으로 구성되는 상황을 맞이하게 됨
    • 데이터웨어하우스 : 배치성
    • 데이터 호수 : 하둡, NoSQL등을 이용한 준 실시간 처리
    • 데이터 호수의 경우 데이터의 사용목적을 가정하지 않고 그대로 저장
    • 데이터 전송 방안
      • 데이터 처리상황이 발생할 때 이벤트 발송
      • 스프링 데이터 플로우, kafka, flume등 사용
  • 로깅과 모니터링
  • 의존관계 관리
    • 서비스 경계를 적절하게 설정해서 의존성을 낮춰라
    • 의존성을 가능한 느슨하게 설계해서 변경에 의한 영향을 낮춰라. 또한 비동기 통신방식을 통해 서비스 간 상호작용이 일어나게 설계하라
    • 서킷 브레이커 같은 패턴을 사용해서 의존성 문제의 전파를 차단하라
    • 의존 관계 그래프 같은 시각화를 통해 의존 관계를 모니터링하라
  • 조직 문화
  • 관리체계문제
    • 분권화된 관리체계 필요
    • 더 나은 서비스를 만들기 위해 표준, 모범사례, 가이드라인 제정 필요
    • 모든 이해관계자가 개발된 모든 서비스를 보는 것 뿐 아니라, 모든 문서, 계약, 서비스 수준 합의도 볼 수 있어야 한다
  • 운영오버헤드
  • 마이크로서비스 테스팅
    • 서비스의 전 구간을 아우르는 동작을 평가하는 테스트는 어떻게 수행할 수 있을까?
      • 서비스 가상화 또는 목킹
      • 서비스 사용자 주도 계약
  • 인프라스트럭처 프로비저닝
마이크로서비스 역량 모델
  • 핵심역량
    • 서비스 리스너(HTTP 리스너/메시지 리스너)
    • 저장 기능
    • 비즈니스 범위 정의
    • 이벤트소싱
    • 서비스 종단점 및 통신 프로토콜
    • API 게이트웨이 : Zuul, Mastery, Apigee, 3scale
    • 사용자인터페이스
  • 지원역량
    • 소프트웨어 정의 로드 밸런서 : Ribbon, Eureka, Zuul
    • 중앙집중형 로그 관리
    • 서비스레지스트리 : Eureka, Zookeeper, Etcd
    • 보안서비스 : OAuth
    • 서비스 환경설정 : 스프링 클라우드 Config, Archaius
    • 테스팅 도구(anti-fragile, RUM) : netflix Simian Army
    • 모니터링 및 대시보드 : Turbine, Hystrix Dashboard, AppDynamic, New Relic, Dynatrace, said, Sense, Spigo
    • 의존 관계와 CI 관리 : CMDB
    • 데이터호수 : 스프링 데이터 플로우, Flume, Kafka, HDFS, Cassandra
  • 인프라스트럭처 역량
    • 클라우드
    • 컨테이너/가상머신
    • 클러스터 제어 및 프로비저닝 : Mesos, Kubernetes
    • 애플리케이션 라이프 사이클 관리 : Marathon
  • 프로세스 및 통제역량
    • 데브옵스
    • 데브옵스 도구
    • 마이크로서비스 저장소 : Nexsus, 도커레지스트리
    • 마이크로서비스 문서화 : Swagger, API Blueprint
    • 참조 아키텍처 및 라이브러리


+ Recent posts