2017. 3. 11.

Google API 설계의 사상을 담은 Google의 API Design Guide

저에게 있어 클래스의 이름을 짓거나 메소드의 이름을 만든다거나 변수 이름을 생각하는 것은 언제나 도전하고 고민해야 하는 일 중의 하나입니다. 도메인 객체의 경우는 그나마 사전에 팀 내에서 또는 기획자와 또는 현업 분들과 이야기를 진행하는 과정에서 결정되거나 일반적인 관습 같은 것을 따라서 고민 없이 결정하는 경우도 많지만 말이죠.
Rest API를 설계하는 것도 역시나 같은 의미에서 저에게는 참 힘든 일인 경우가 많습니다. 물론 도메인 이름을 리소스 이름으로 사용하고 거기에 일반적인 Rest API 설계 규칙에 따라서 GET/POST/PUT/DELETE 메소드에 따라 적당한 규칙을 정해서 생각 없이 가는 경우가 대부분이지만, 아주 가끔 Custom API를 만들어야 하는 경우에는 어떤 게 좋을지 고민하게 되더군요.
아마도 기초가 부족하고 생각만 많은 성격이라 그런가 봅니다.

그러다 보니 평소 시간이 날 때 다른 사람들의 소스나 설계를 보는 것을 좀 즐기는 편인데요.
언제 공개가 되었는지는 정확히 모르겠지만, Google의 Cloud API를 설계할 때 사용한 Design Guide가 공개가 되어있더군요.

전문은 https://cloud.google.com/apis/design/ 에서 확인할 수 있습니다.

전체를 아직 다 읽지는 않았지만, 내용에는 Rest API와 구글의 Protocol Buffer를 이용한 gRpc에 사용한 Design Guide도 함께 정리되어 있는 것으로 보입니다.

한글 번역문도 있으면 좋았겠습니다만, 아직 영문만 있는 것으로 보이네요.

RPC 디자인을 해야 하는 경우는 거의 없어서 우선 Rest API 관련 가이드만 조금 살펴보았는데 특히 그중에서 Restful Design Flow와 Handling Errors에 대한 내용만 이곳에 간단히 정리를 해 볼까 합니다.

그 외에도 리소스 이름 명명법이라던가 일반 또는 커스텀 메소드에 대한 정의 방법, 네이밍 규칙, 디자인 패턴, 도큐멘테이션, 버전 정의 방법 등의 여러 가지에 대한 가이드가 있습니다.

평소 내가 만든 API의 디자인이 잘 된 것인지 어떤지 또는 API 디자인에 대해서 실례를 통한 공부를 해보고 싶으신 분은 어느 정도 참고가 될 것 같습니다.


Restful Design Flow


  • API가 제공하는 리소스의 유형 결정(Determine what types of resources an API provides).
  • 리소스간의 관계 결정(Determine the relationships between resources).
  • 리소스의 유형과 관계를 기반으로 리소스 이름의 스키마를 결정(Decide the resource name schemes based on types and relationships).
  • 리소스 스키마를 결정(Decide the resource schemas).
  • 최소한의 메소드를 리소스에 첨부(Attach minimum set of methods to resources).

좀 당연한 플로우라 설명은 생략합니다. 다만, 평소 API 디자인할 때 위와 같은 플로우로 생각하지 않고 생각 없이 진행하는 경우가 많아서 한 번 정리해봤습니다.

Handling Errors


  • 200 OK
  • 400 INVALID_ARGUMENT
  • 400 FAILED_PRECONDITION
  • 400 OUT_OF_RANGE (Client specified an invalid range)
  • 401 UNAUTHENTICATED
  • 403 PERMISSION_DENIED
  • 404 NOT_FOUND
  • 409 ABORTED (Concurrency conflict, such as read-modify-write conflict)
  • 409 ALREADY_EXISTS (The resource that a client tried to create already exists)
  • 429 RESOURCE_EXHAUSTED (Either out of resource quota or reaching rate limiting)
  • 499 CANCELLED (Request cancelled by the client)
  • 500 DATA_LOSS
  • 500 UNKNOWN
  • 500 INTERNAL
  • 501 NOT_IMPLEMENTED
  • 503 UNAVAILABLE (Service unavailable. Typically the server is down)
  • 504 DEADLINE_EXCEEDED 
Error Code 의 경우는 Spring의 HttpStatus 문서와 비교해 보니 좀 더 흥미롭네요. 참고로 문서에 정의되어있는 HttpStatus Code는 아마도 IANA의 Hypertext Transfer Protocol (HTTP) Status Code Registry를 기반으로 한 것으로 보입니다. 즉 일반적인 코드 정의라는 말이죠. (잠시 링크를 넣기 위해서 아는척했습니다. 죄송합니다.)
대부분 구글의 Error Code도 같습니다. Rest API 디자인에 있어서 가장 기본적인 원칙 중 하나가 HttpStatus Code를 이용해서 Error Code를 정의하라는 것이니 어쩌면 당연해 보입니다. 다만, 400 BAD_REQUEST, 409 CONFLICT, 500 INTERNAL_SERVER_ERROR 등의 세분화 및 확장의 모습은 어떻게 HttpStatusz Code를 이용해서 에러를 정의할까에 대한 기본 규칙을 보여줍니다. 그리고, 499 CANCELLED 에서는 UNASSIGNED 되어있는 코드를 이용해서 확장하는 방법에 대한 예도 보여주네요. 아마도 서버 에러가 아닌 요청과 관련된 에러 대부분을 정의하는 400대에서 UNASSIGN 되어있는 가장 마지막 번호를 이용한 게 아닌가 싶습니다.

한번에 전부를 읽는 것도 좋겠지만, 가끔 생각날 때마다 필요한 부분을 참고하는 용도로 사용하면 좋은 자료가 아닐까 생각합니다.




2017. 3. 5.

[TED Talk 소개] 시간이 없다는 것은 우선순위가 낮다는 것이다.

간만에 TED Talk 을 봤습니다.

시간 관리에 관한 짤막하지만 아주 강렬한 강의였습니다.

평소 다른 탓을 하거나 변명하는 것을 별로 좋아하지 않습니다. 그중에서 가장 하기 싫은 변명인데 가장 많이 하는 변명이 시간이 없다는 것이죠. (이 블로그 글에도 시간이 없다고 쓴 적이 있는듯하네요)

이 TED 동영상은 Laura Vanderkam 이라는 분이 시간 관리에 대해서 강연한 12분 남짓의 짧은 내용입니다. 잠시 구글링을 해보니 이 분은 주로 시간 관리를 바탕으로 한 성공학 관련 강연을 하시고 관련 책을 집필하시는 분인 것으로 보이네요. 국내에는 "시간 창조자 : 똑같이 주어진 시간, 그러나 다르게 사는 사람들(원제: 168 Hours)"이라는 책이 2011년에 번역 출간되어있더군요.



이 TED 동영상의 내용을 요약하자면 매우 단순합니다. (TED 동영상의 가장 큰 장점이지요)

중요하게 생각하는 즉 우선순위가 높은 일들을 미리 스케줄에 넣어놓고 이것을 하기 위한 시간을 만들라는 내용입니다. 그러기 위해서 두가지 정도를 이야기하는데 내년성과 평가를 지금 해 보라는 것과 다음주의 할일을 미리 정하고 그에 맞춰서 시간을 만들어 넣으라는 내용입니다.

주로 시간관리와 관련된 자기계발서나 글을 많이 읽으신 분들은 "맨날 하는 뻔한 이야기"라고 생각하실지도 모르겠네요.

이 동영상에서는 이런 예를 통해서 설명합니다.
작은 회사를 운영하시는 아이 6을 가지신 어떤 여성분이(이 TED가 아마도 여성분들을 위한 것이었나 봅니다. 관중분들이 모두 여성분들이시더군요) 어느 날 퇴근해서 보니 배관이 터졌답니다. 매우 중대한 사태였기 때문에 다음날에는 배관공을 불러서 고치고 그다음 날에는 카펫 청소업체를 부르는 등의 조치를 해서 빠르게 문제를 해결했다고 합니다. 그분은 이 처리를 하기 위해서 일주일간 7시간을 투자하셨는데, 이분에게 운동을 위해 7시간을 투자하라고 하면 시간이 없다고 하리라는 것이죠. 아주 바쁜 와중에도 중요한 일이었기 때문에 7시간을 만들어냈다는 말입니다.

누구에게나 주당 168시간이 주어지고 일주일에 잔업을 포함해서 50시간을 근무하고 56시간을 잠을 잔다고 해도 62시간이 주어집니다. 시간이 없다는 것은 우선순위가 낮다는 말이니까 제가 평소 많이 하는 시간이 없다는 변명을 결국 그만큼 우선순위를 가진 중요한 일은 아니라고 말하는 것이 되겠네요.

제발 제 지인분들은 이 글 보지 말아주세요. 혹시 보시더라도 오해하지 마세요. 결코, 우선순위가 낮지 않습니다. 단지 제가 시간 관리를 잘 못 하다 보니 다른 급한 일들에 밀려서 그런 것 뿐입니다. 하하하..

앞으로는 중요하지 않지만 급한 일들을 처리하느라 또는 중요하지도 급하지도 않은 일들을 처리하느라 시간을 낭비하지 말고 중요한 일 위주로 시간을 배분해야겠네요. 그래서 소중한 분들과 소주 한 잔 기울일 수 있는 시간을 많이 가져봐야겠습니다.

2017. 2. 12.

지옥에서 걸어나와 정글에서 살아가는 저자가 말하는 "혼자 일하는 즐거움" - 이동우


출간일 : 2016년 8월 8일

320쪽 | 570g | 152*215*30mm
ISBN-13 : 9788901213132
ISBN-10 : 8901213133

정말 오랜만에 책에 대한 리뷰를 올리는 것 같습니다.
작년 신간으로 소개될 때부터 관심을 가졌던 책을 결국 읽게 되었네요. 관심을 가진 것은 순전히 제목 때문이었습니다. 당시 회사에서도 팀에 소속되어있지만, 항시 혼자 일하고 있다는 느낌이 있었고, 집에서는 개인 프로젝트를 혼자 진행하고 있어서 혼자 일하는 것은 어떤 것일까 하는 생각을 하던 때였습니다. 당시 거짓말같이 내 생각과 고민을 제목으로 한 책이 나왔던 것! 그런데, 그 책을 이제서야 읽게 됐네요. 하하하~~.

이 책을 읽으면서 찾아보니 10분 독서(http://www.10book.kr/)의 컨텐츠를 만들고 있는 이동우컨텐츠연구소의 이동우 소장(1인 회사이니만큼 소장님이면서 대표님이시겠죠?)님이 쓰신 책입니다. 책을 보니 동영상 리뷰의 전 과정을 홀로 하고 계십니다. 또한, 저자의 약력(?)이랄까 살아오신 과정을 보면 이 포스트의 제목처럼 지옥에서 걸어 나와 정글에서 살아가고 있는 1인 회사의 사장님이시자 실무자로서 최선을 다하고 있는 분입니다.

작년 8월 이후 꽤 시간이 지난 최근에 이 책을 구매하게 된 것은 제 상황에 약간의 변화가 있었기 때문입니다. 저자의 말을 빌리자면 이제 회사의 테두리를 벗어나서 정글로 나오게 된 것이지요. 정확하게는 혼자 일하게 된 것은 아니긴 하지만 앞으로 꽤 긴 시간을 혼자서 작업을 하게 된 상황입니다. 각설하고 아무튼 상황이 혼자 일을 하게 되다 보니 예전에 본 적이 있는 이 책을 한번 읽어보고 싶어서 사게 됐고 후다닥 읽게 된 것이지요.

제목만을 보고 약간의 편견이 있었나 봅니다. 일반적인 자기개발서들이 그렇듯이 이 책도 혼자 일하려면 "이런 것이 문제다", "이런 것을 챙겨라",  "이런 것을 조심해라", "이런 방법론이 좋다", "이렇게 하면 성공할 수 있다" 뭐 이런 부류의 글들이 있을 것으로 생각했습니다만...

실제로 책은 약간 철학서와 경제서의 중간쯤 되는 것 같다는 느낌이 들었습니다.
"혼자라는 정의는 무엇인가", "조직에서 일한다면 혼자가 아닌가", "결국 정글에서 혼자 일하는 것은 어떤 의미를 가지는 것인가"라는 철학적인 해석과 현재 최근의 세상은 혼자 일하는 시대로 가고 있다는 것을 다양한 경제 상황과 보고서, 다양한 석학들의 분석 등을 기반으로 설명하는 내용이 책의 상당 부분을 차지하고 있습니다.

사실 이 부분이 이 책의 좋았던 부분입니다.

꽤 긴 시간을 회사에서 나와서 혼자 일하고자 하는 것에 대해 고민을 하고 있던 상황에서 사실 가장 두려웠던 부분은 심리적인 문제였습니다. 그런 부분에 대해서 같이 고민해주는 누군가를 만나서 함께 이야기를 나눈 듯한 느낌을 주는 책이었습니다. 책의 내용이 제게 심리적인 위안을 주었다기보다는 좀 더 심리적으로 단단하게 준비할 힘을 주었다고 할까요?

다만, 책의 목적이기도 해서 저자분도 어쩔 수 없으셨겠지만 모든 세상의 흐름이 혼자 일하는 쪽으로 흘러간다는 식으로 일반화하신 부분은 약간은 과장이 심해서 공감이 안가는 듯한 느낌을 받기도 했습니다. 어쩌면 단지 제가 공감하기 싫었던 것일지도 모르겠네요.

그래도 현대 사회에서의 다양한 현상들과 혼자 일하는 현상의 흐름을 잘 조화롭게 설명해준 부분들은 약간 새로운 시각으로 세상을 바라볼 수 있는 길을 열어준 부분도 있습니다.

책의 매 장이 시작되는 제목 밑에 있는 짧은 글들이 특히 참 좋았습니다.

과거의 선택을 최고의 선택으로 만드는 것은 앞으로의 당신입니다 - 이노우에 히로유키
라던가
오늘 남들이 하지 않는 일을 하면 내일 남들이 할 수 없는 것을 할 수 있다 - 제리 라이스
라던가 하는...

세상이라는 정글로 혼자 나온 것이 잘한 것인지는 모르겠지만, 해보지 않으면 현명한 선택인지 실수인지 알 수 없겠지요. 직장 생활에 불만이 없었던 것은 아니지만, 그보다는 꼭 해 보고 싶었던 것들을 하고 싶어서 나온 것인 만큼 앞으로 열심히 해 보는 수밖에 없겠지요.

그나저나 북리뷰를 진행하시는 분이 쓰신 책을 리뷰한다는 것은 참 두려운 일이네요. ^^

홀로 일하고 싶은 꿈을 가지고 있으신 분들이라면 한 번쯤 가볍게 읽어보시길 권합니다.
가벼운 마음으로 읽다가 무거운 마음으로 마음을 다잡게 될지도 모르겠지만요... ^^

오늘 하루도 홀로 분투하시는 많은 분께 마음으로나마 응원을 보냅니다.

2017. 1. 21.

드디어 JDK9이 Feature Complete을 하고 Ramp down phase로 들어간다고 합니다.

매일 아침에 일어나서 출근하기 전에 하는 일 중에서 가장 중요하게 생각하는 부분은 뉴스리더 중에서 출근길에 읽을만한 주요 기사를 선정하는 것이 있습니다. 토요일이라고 해서 크게 다르지 않아서 일단 밤사이에 들어온 100여 개 뉴스리더 리스트 중에서 당장 읽을만한 것을 추려서 먼저 읽는데 오늘은 매우 중요하고 큰 내용이 있어서 아직 다 읽지 못한 상황에서 우선 블로그에 기록부터 해 보려고 합니다.

JDK 9 Is Feature Complete!

그동안 여러 가지 글들을 통해서 JDK 9의 기능이나 개선내용에 대해서 읽기는 했지만, 너무 많은 정보가 있다 보니 사실 건성으로 보고 있었는데, 드디어 JDK 9이 Feature Complete을 했네요. 이제 Rampdown phase로 진행한다고 합니다. 기사 내용의 마지막 부분을 읽어보면 이제 버그 수정과 약간의 기능개선이나 사용성 향상을 위한 수정이 있을 예정으로 보입니다.

앞서도 언급했듯이 아직 세부내용을 본 것은 없지만, 리스트만 봐서도 몇가지 관심가는 부분들은 있네요. 워낙 그동안 건성으로 봐와서 Modularity 부분을 제외하고는 나머지는 전부 새로운 내용이네요.
Modularity를 제외하고 당장에 리스트에서 눈에 들어온 부분은 다음과 같습니다.

  • 193: Variable Handles 
  • 222: jshell: The Java Shell (Read-Eval-Print Loop)
  • 264: Platform Logging API and Service
  • 224: HTML5 Javadoc
  • 110: HTTP 2 Client (and begin replacing "the legacy HttpURLConnection API")
  • 236: Parser API for Nashorn
  • 289: Deprecate the Applet API
  • 292: Implement Selected ECMAScript 6 Features in Nashorn
  • 251: Multi-Resolution Images
  • 256: BeanInfo Annotations
  • 274: Enhanced Method Handles
  • 295: Ahead-of-Time Compilation

링크된 원문 포스트 내용에 링크가 있지만, JDK 9 Page에는 89개의 상세 리스트가 게시되어있습니다.

현재 JDK 8도 제대로 공부를 못하고 있는 저로서는 JDK 9의 발표가 반갑기만 하지는 않네요. 오히려 약간 두렵다고 표현하는 것이 맞을 듯 합니다.

그만 두려워하고 시간을 두고 상세한 내용을 한 번 들여다봐야겠습니다.
더불어 JDK 8에 대한 공부에도 좀 더 노력을 기울여봐야겠습니다.


2016. 12. 11.

[Webinar 정리] Awesome tools to level up your Spring Cloud architecture

개요




우리나라 시간으로 2016년 11월 9일 새벽 3시부터 1시간가량 진행이 됐던 Webinar입니다.

제목에서도 알 수 있듯이 대부분 개발툴과 Devops Tool에 대한 간단한 소개 형식이었네요.

물론, 새벽 3시에 본방사수를 외쳤습니다만, 3시에 일어났다가 틀고 잠이 들어서 결국 끝 10분만 봤습니다. 그래서 본방사수는 놓쳤고 나중에 보고 정리한 내용입니다.

Webinar이고 영어다 보니 거의 알아들을 수가 없었습니다만(이럴 땐 영어를 못 하는 것이 아주 아쉽습니다) 프리젠테이션과 데모로 대충만 알아들었습니다.

Webinar 사이트에 들어가 보시면 관련 자료가 엄청나게 많이 링크로 걸려있습니다. 해당 내용을 다 확인하려고 해도 엄청난 시간이 필요하겠네요.

여기에는 Webinar 진행 중에 나왔던 다양한 Tool 중에서 관심이 있는 내용에 대해서 주로 정리를 해 볼까 합니다.

아래 Tool들의 대부분은 Spring Cloud(특히 Eureka Discovery Server)가 필수이거나 있어야 효용성이 늘어난다는 것을 염두에 두시고 보시기 바랍니다.


Monitoring And Dashboard Tools


1. Spring Boot Admin



Webinar 내용을 통틀어 가장 마음에 들고 관심이 갔던 Tool 되겠습니다. 이건 현재 진행하는 프로젝트에 꼭 적용을 해보려고 합니다.

Eureka Server의 정보를 기반으로 해서 각 마이크로서비스의 Actuator 정보를 이용해 관리할 수 있는 다양한 기능들을 제공해 줍니다. 제공되는 내용을 잠시 간단히 살펴보니 기본적으로는 서비스 레지스트리에 등록된 서비스들의 목록을 제공합니다. 거기서 상세정보를 확인하기 위해서 들어가면 아래와 같은 내용을 제공하는 것으로 보입니다.
  • 각 서비스의 상세 상태 정보 
    • 각 서비스의 Health 정보 : Memory, Disk, Db 상태 등
    • Memory 상세 정보
    • JVM 정보
    • Servlet Container 정보
    • Garbage Collection 정보
  • Metrics 정보
  • 로그 : 이거 정말 마음에 들더군요. 얼마나 표시가 되는지는 모르겠지만 유용해 보입니다.
  • 스프링 설정 정보의 확인과 편집 : 확인만으로도 유용한데 편집하고 실시간 적용 가능합니다. 물론 @RefreshScope 으로 정의된 내용에 한해서만 되겠지만요.
  • logback의 로그  레벨 확인 및 편집 : 등록된 logback의 로그 레벨을 확인하고 변경할 수 있습니다.
  • Thread dump와 Request trace : actuator 기능을 보면서 나중에 꼭 가져다 써보자 했던 부분입니다.
  • Hystrix dashboard : 해당 서비스의 hystrix dashboard를 연결해 놓았습니다.

주절주절 리스트를 열거했습니다만, 간단히 Actuator의 기능을 전부 모아놨다고 봐야 할 것 같습니다.

사실 최근에 Spring Cloud 프로젝트를 기반으로 마이크로서비스 비스므리한 프로젝트를 개인적으로 진행해보고 있는데 완성할 때는 꼭 Actuator와 Hystrix Dashboard 를 연결하는 Dashboard를 하나 만들어야겠다 생각했었는데, 이런 유용한 것을 만들어주다니 정말 감사하다는 생각밖에는... 역시 세상은 살만한 곳입니다.

Spring Boot Admin과 3번에 나올 Microservices dashboard와 관련해서는 Josh Long이 22분정도의 라이브 코딩으로 설명하는 영상도 있으니 참고해 볼 만 합니다.(Spring Tips : Bootiful Dashboards - Josh Long)

2. Prometheus and Grafana


그 외로 Prometheus와 Grafana Tool도 설명이 나옵니다. 좋은 기능이긴 한데 솔직히 이것까지 필요할지는 한번 생각해 봐야 하겠습니다. 두 가지 Tool 모두 향상된 Visualization을 제공해 주고 유용한 것은 분명해 보입니다. Grafana 에서 Latency를 퍼센트별(90%, 95%, 99%, 100%)로 나눠서 제공해주는 정보는 꽤 좋아 보이긴 했습니다.

3. Microservices dashboard


jworks 팀이 만들고 있는 프로젝트로 보입니다. 따로 내용을 정리하기보다는 아래 그림을 참고하시면 될 것으로 보이네요.


현재는 그렇게 복잡한 서비스를 개발하고 있지 않아서 이런 것까지 필요할까 생각했습니다.


Log Analysis


1. ELK and Zipkin/Slueth


로그분석툴을 논할 때 절대 빠질 수 없는 것이  ELK가 아닐까 생각합니다.
지금은 Elastic Stack이라는 제품명으로 제공이 되고 있고, 정말 엄청난 속도로 버전업이 이루어져 왔습니다. 얼마 전에 Docker를 이용해서 Elastic Stack 5.0에 대한 테스트 파일럿을 진행해 보았습니다. 예전에 해 보았을 때보다 Kibana도 조금 편리해진 느낌이더군요. 아직 Kibana 사용법과 Elasticsearch 쿼리가 익숙하지 않아서 그렇지 굉장히 유용한 Tool임에는 분명해 보였습니다. 올 초부터 꼭 블로그에 정리해 놓겠다고 생각했었는데 아직 그러지 못하고 있네요.

아무튼, ELK 를 구성해 놓고 로그를 분석하면서 가장 아쉬운 것이 각 서비스에서 올라오는 많은 로그의 연속성을 따라가는 방법이었습니다. 즉 A 서비스가 request를 받아서 B 서비스로 처리를 요청해서 응답을 받아 사용한 경우 그 관계를 파악이 불가능 하더구요. 시간 관계로 할 수는 있는데 로드 테스트를 돌려본 결과 요청이 여러 개가 동시에 들어오는 경우 불가능하다는 판단을 했었습니다.

이럴 때 사용하는 것인 Zipkin과 Slueth 입니다. 최초 요청을 받은 Request 로그만 있다면 해당 로그에는 Trace id 와 Span id 가 자동으로 생성돼서 들어갑니다. 이것을 이용해서 추적한다면 가능하게 됩니다. 무려 Out Of Box로 적용이 되기 때문에 단순히 스프링 프로젝트에 Dependency만 잡으면 적용이 되는 편리함까지 있습니다. 아직은 파일럿이었기 때문에 샘플 수준에서 기본기능만 확인해 봤지만, ELK와 Zipkin/Slueth를 함께 사용한다면 분명 유용하지 싶습니다.

2. Splunk 


유료버전인데다 가격도 엄청나다는 이야기만 들었던 제품입니다. ELK만 소개하기가 뭐했던지 잠시 Splunk 이야기가 나옵니다.


Development Support Tools


1. Sonarqube/OWASP/FindSecBugs/...


뭐 워낙 유명해서 설명이 필요할 것 같지 않아서 설명 안 하겠습니다. 실제로 Webinar 에서도 간단히 언급만 하고 넘어갑니다. 유명하지만 전 사용해 본 적이 없습니다. OTL...

2. Spring REST Docs


비슷한 제품으로 Swagger가 유명합니다만, 최근 Spring 진영에서는 REST Docs를 더 밀고 있는 느낌입니다.

Integration Test를 이용해서 API Document를 작성해 주는 Tool이지요. Endpoint 별 Request/Response뿐 아니라 Mock을 이용해서 Request와 Response 샘플까지를 문서에 포함해줍니다.

자세한 내용은 국내의 김대성님과 아라한사님께서 만드신 발표자료들이 있고 샘플 소스가 있으니 참고하세요. 저도 그 자료들을 이용해서 공부해서 한 번 사용해볼까 합니다.




Deployment



1. Spinnaker 


마지막으로 Spinnaker에 대한 설명입니다. Jenkins를 사용해보려고 여러 번 도전했다가 실패한 경험이 있어서 사실 CI/CD Tool은 별로 관심을 가지지 않았었습니다. 그런데 최근에 개인 프로젝트를 Cloud에 올릴 일이 있었는데 CI/CD Tool을 하나 알아봐야겠다 생각했었습니다. Jekins가 매우 좋은 툴이긴 한데 저한테는 설정이나 고민해야 하는 사항이 많아서 좀 어렵더군요.
그런데 Spinnaker는 설정이 꽤 편리해 보입니다. 나중에 한 번 공부를 해봐야겠습니다.


결론 


대충 이번 Webinar에서 나온 Tool들은 이 정도였습니다.
많은 설명이 있습니다만 영어라서 저는 그냥 어떤 Tool들이 소개되는지 정도만 확인하는데 만족할 수밖에 없었네요. 그래도 대충 모양새를 보고 앞으로 뭘 공부해봐야 할지는 대충 감이 온 것 같습니다.
PCF(Pivotal Cloud Foundry)에 대한 자랑과 선전으로 마무리!! 컥.. 그냥 비교 설명이 있었습니다.

마지막으로 Slide에 나왔던 두 장의 Architect 구성도로 마무리해 보겠습니다.





2016. 10. 22.

Semantic Versioning 2.0.0 에 대한 자료 정리

Gradle이라던가 Maven을 이용한 빌드 시스템을 구축하고 NEXUS 등의 리포지터리를 이용하고 Git 을 쓰면서 개발을 하다 보면 예전에는 별로 관심이 없었던 개발하고 있는 시스템의 버전관리에 대한 생각을 하게 되더군요(최소한 저의 경우는 그랬습니다)
혹시라도 공통 라이브러리 패키지가 있을때는 공통 라이브러리에 대한 버전관리가 예전부터도 중요하게 생각되었었지만, 최근에는 이 공통 라이브러리 패키지를 이용하지 않는데도 버전관리가 예전보다 더 중요하게 생각이 됩니다.
다른 부분들은 그렇다 쳐도 Git을 이용해서 형상관리를 하는 경우에는 특정 커밋에 태깅을 해 놓는 것이 나중에 해당 버전의 상태를 추적하는데 매우 편리한 도구가 될 수 있습니다.

버전관리에서 최근 가장 많이 쓰는 방식이 Semantic Versioning 이라고 하는 것이 아닐까 생각합니다. 최근이라고 하지만 사실 예전부터 많이 사용됐었고 Semantic Versioning 이라는 개념을 몰라도 일반적으로 비슷하게 사용하는 x.y.z이라는 Major.Minor.Patch 방식의 버전관리입니다. 예를 들어 "릴리즈 최초버전은 1.0.0이다" 가 바로 Semantic Versioning(줄여서 semver 라고도 하더군요) 입니다.

다른 내용에 대해 검색을 하다가 우연히 해당 Semantic Versioning 에 대한 공식 문서를 찾았습니다.
semver 는 일반적으로 Public API에 대한 버전관리에 대해서 설명을 합니다만, 일반적인 프로그램에도 같게 적용될 수 있습니다.

결론적으로 가장 중요한 내용을 정리한다면,


  • 기존 버전과 호환되지 않게 변경을 했다면 Major 버전
  • 기존 버전에 새로운 기능이나 호환이 가능한 수정을 했다면 Minor 버전
  • 기존 버전의 버그에 대해서 호환 가능하게 수정을 했다면 Patch 버전
(해당 버전) 부분을 하나씩 증가시킨다는 규칙을 말합니다.

일반 서비스를 개발하시는 분들의 경우는 조금 다를 수도 있겠네요. 저희도 제한적인 웹 서비스를 개발하고 있다 보니 일반적인 Public API와는 조금 다르게 적용이 됩니다.(서비스 초반에 잠깐 하다가 현재는 안 하고 있는 상황인데, 앞으로는 좀 잘해 보려 합니다.) Minor와 Patch는 같은 방식으로 버전관리가 가능하지만 Major의 경우에는 회사에서 정해지는 경우가 대부분이죠. "이번 프로젝트는 버전 2로 명명한다. 그리고 몇 달 또는 1년쯤 지난 후에 이번 개발부터 버전 3 로 명명할 거야." 라는 식으로 Major가 결정되는 경우가 많이 있습니다.

어찌 됐건 개인적으로 생각할 때는 Minor와 Patch 버전만 관리 한다 해도 Git에 태깅되어있는 버전번호를 보면 이 릴리즈가 버그 수정의 Patch 수준이었는지 신규 기능이 추가되었거나 대규모 수정의 수준이었는지에 대한 파악이 될 수 있으니 매우 유용합니다. 저희처럼 버전관리가 대충이거나 하지 않거나 다른 방식으로 하는 분들은 한 번쯤 내용을 보시고 도입을 검토해보시는 것도 나쁘지 않아 보이네요. (아마도 대부분 이 방식을 쓰고 있다고 생각이 되긴 하네요)

사실 저희 다음 프로젝트에 적용할 때 참고하고자 블로그에 올리면서 잠시 주절거려봤습니다.

제가 검색할 당시에 대략 18개 언어로 번역되어 서비스되고 있는듯하고 물론 한국어도 있습니다. (한국어 번역은 김대현님이 하셨네요. 감사합니다.)

한국어판 링크 : http://semver.org/lang/ko/



2016. 9. 13.

개발자들의 기술에 대한 오만에 대해서...

최근 며칠간 회사일로 약간의 혼란상황이 있었습니다.

많은 부분 정리가 되긴 했지만, 아직 조금 더 시간이 걸리듯 하네요.

최근 블로그를 쓰지 않고 있었던 것은 다른 일로 좀 바빴기 때문인데, 역시 이것도 시간이 많이 필요해 보입니다. 오늘은 잠시 추석을 앞두고 휴식도 가질 겸 기술이 아니라 기술에 대한 생각들을 한번 이야기해볼까 합니다. 추석에는 다른 작업을 또 열심히 해야 하기에...

그동안도 몇 번 블로그에 정리하고 싶었습니다만, 저 자신도 부족한 것이 많은데 괜한 잘난 척이 되지 않을까, 몇 번이나 쓰기를 망설였던 내용입니다.

그 내용은 개발자들이 흔히 범하는 기술에 대한 오해에서 오는 오만에 대한 것입니다.

최근 면접을 위해 이력서를 보거나 다른 회사의 제안서를 검토하다 보면 애자일 방법론이라던가 도메인 주도개발이라던가 테스트 주도개발을 강점으로 내세우는 경우를 많이 보게 됩니다. 또한 머신 투 머신(이런 용어가 어디에서 나온 것인지 좀 궁금합니다만...)의 인터페이스를 이용한 개발방법론이라는 것도 보게 되더군요. 아마도 EIP(기업 통합 패턴, Enterprise Integration Pattern)을 말하는 것이거나, 마이크로서비스 아키텍트의 사촌쯤 되는 게 아닐까 생각해 봅니다. 심지어 위 기술들에 대한 전문가라고 칭하는 사람들도 보이더군요.

너무나도 당연히 해야만 하는 테스트주도 개발(제 주관적인 생각입니다)을 제외하고 다른 부분에 대해서는 좀 생각을 해봐야 하는 것이 아닌가 합니다.

위에 기술한 것들이 참 좋은 것들이고 올바른 트랜드라고 생각을 합니다만...

좀 더 깊게 한번 생각해 보겠습니다.

애자일 방법론의 핵심이 무엇일까요?
애자일 매니페스토의 한글 번역본은 이렇게 시작합니다.

우리의 최우선 순위는, 가치 있는 소프트웨어를
일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
이 뒤로도 주옥같은 많은 원칙이 나옵니다만, 저에게 애자일의 가장 핵심은 위의 내용입니다.
몇 개월이 지나도록 고객이 UI/UX 스토리보드 이외에 실제로 동작하는 어떠한 프로토타입도 받지 못했다면 제가 생각하기에 애자일 방법론이 아닙니다. 물론, 큰 엔터프라이즈 시스템의 경우 백앤드 작업에 시간이 걸리기 때문에 그럴 수도 있다고 생각하시는 분들도 있을지 모르겠지만, 제 생각에는 아닙니다. 백앤드 시스템 개발 중에도 최소한 엉터리 디자인이 적용된 Mockup이라도 그리고 Mock 데이터를 이용하더라도 프런트앤드의 프로토타이핑이 병행되어져야 한다고 생각합니다. 이것도 최소한일 뿐이지요. 일정 기능이라도 완전한 형태로 고객에게 전달되지 않으면 안 됩니다. 그렇지 않다면 고객이 본인의 요구사항을 개발자들이 정확히 개발하고 있다는 것을 어떻게 알 수 있을까요? 이런 애자일 방법론은 폭포수 모델에 비해서 나은 부분이 무엇일까요?
단순히 백로그를 관리하고 스프린트가 돌고 스탠드업 미팅을 진행한다고 애자일을 하고 있다고 말할 수 있는 것인지 한 번 생각해 봤으면 합니다.
폭포수 모델도 백로그 관리하고 이슈트래킹하고 스프린트 돌리고 스탠드업 미팅을 진행할 수 있습니다. 엉클 밥의 경우는 페어프로그래밍을 하지 않는다면 애자일이 아니라고 이야기하시기도 하더군요. 뭐 그렇게까지 엄격한 잣대를 들이밀고 싶지는 않습니다.
애자일은 고객에게 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키기 위해서 나온 개발 방법론이라는 것을 한번 이야기해보고 싶었습니다.

다음으로는 도메인 주도 설계입니다.
데이터 주도 설계냐 도메인 주도 설계냐를 놓고 어느 것이 우위에 있다고 싸우는 경우를 보곤 합니다. 꼭 싸우지는 않더라도 데이터 주도 설계를 하면 도메인 주도 설계보다 확장성이나 유연성이 떨어진다고 말씀하시는 분들도 있더군요.
그런데 이런 논쟁을 하시는 분들의 경우 일반적으로 마이바티스를 사용하고 있으니 데이터주도 설계에 의한 개발이고 JPA를 사용하고 있으니 도메인 주도 설계에 의한 개발이라고 말씀하시는 분들이 꽤 보입니다. (오늘도 한 분 뵈었죠) 과연 마이바티스를 사용하니 데이터주도 개발이고 JPA 를 사용하니까 도메인 주도 개발일까요? 과연 도메인 주도 개발이 데이터 주도 개발보다 유연성과 확장성이 뛰어날까요?
제가 알기로는 Data Driven Design과 Domain Driven Design의 차이는 관점의 차이로 알고 있습니다. 어떤 프로세스가 진행되는 과정에서 데이터의 생성/변형, 데이터의 그룹화 등에 초점을 맞추고 진행하는 디자인 방식이 Data Driven Design이고, 업무를 중심으로 설계를 진행하는 것이 Domain Driven Design입니다.
실제 현실에서는 어떨까요? Data Driven Design의 경우는 일반적으로 테이블을 기준으로 해서 설계를 진행하게 되는 경우가 많습니다. 업무에 따라서 어떤 테이블을 참조할지를 결정하고 해당 테이블에 대한 데이터 객체를 이용하게 되는 방식이지요. 반면에 Domain Driven Design은 실제 객체에 집중해서 진행하게 됩니다. 업무 또는 업무의 속성을 표현한 객체를 설계하고 해당 관점에서 전체적인 설계를 진행하게 됩니다. 뭔가 말이 딱 와 닿게 만들어지지를 않네요. 어쨌건 이러다 보니 마이바티스는 Data Driven Design에 가깝고 JPA는 Domain Driven Design에 가깝다는 논리가 만들어지는 건지도 모르겠습니다. Domain Driven Design의 관점에서는 실제로 데이터베이스의 테이블과 1:1로 맵핑이 되지 않는 경우도 발생하기 때문에 DDD 진형에서는 이 차이점을 극복하기 위한 다양한 시도나 노하우가 만들어지고 있기도 한 것으로 압니다.
DDD는 업무를 표현하면서 실제 사용 고객의 언어와 개발자의 언어가 같아야 한다고 이야기합니다. 즉, DDD의 핵심은 고객이 사용하는 언어로 만들어낸 요구사항을 어떻게 모델링 해낼 것인가에 있다는 말이지요. 고객과 고객의 업무에 그 초점이 맞추어진다는 점에서 DDD는 일반적으로 애자일 방법론과 궁합이 좋다고 이야기합니다. 즉, DDD는 고객의 업무에 대한 분석이 충분히 이루어져야 하고 고객의 관점에서 고객의 언어로 요구사항을 받아 설계를 진행해야 합니다. 그런데, 고객의 업무와 고객의 요구사항이 정확히 파악되고 분석되지 않은 상태에서 만들어진 도메인이라는 것이 과연 효용이 있는 것인지 한 번 생각해 보았으면 합니다.

마지막으로 EIP 또는 마이크로서비스 아키텍트(이하 MSA, Micro Service Architect)에 관한 이야기를 해 볼까 합니다.
MSA에 대해서는 저도 매우 큰 관심이 있는 상태이고, 최근 열심히 공부하면서 그 활용성을 고민해 보고 있는 분야지만 아직 실전 경험이 없습니다. EIP의 경우도 저에겐 실전경험 없이 수박 겉핥기 수준의 분석을 진행한 경험이 전부인 분야지요. 따라서, 제가 할 말은 거의 없습니다. 하지만, 한 가지만 이야기해볼까 합니다. 과연 EIP 나 MSA가 일반적인 다른 프로그램 패턴보다 성능이 많이 뛰어난 것일까요? 확장하는데 비용이 획기적으로 절약이 될까요? 잘 모르는 제가 볼 때는 많은 고민을 하고 적용 여부를 판단한 후에 설계가 이루어졌을 때만 그 효용가치가 올라갈 수 있다고 생각합니다(뭐는 그렇지 않겠습니까?). 생각 없이 메시지 큐와 파이프 등을 이용해서 개발이 이루어진다면 기술의 배신을 맛볼 수 있지 않을까 생각합니다. 대부분의 신기술이 나올 때 별다른 분석없이 그리고 고민 없이 사용했다가 여러번 배신당한 경험이 있으므로 이 역시 마찬가지가 아닐까 생각하는 것이지요. 주변에 EIP를 사용하고 있는 업체에 계신 분들 이야기를 들어보면 제 생각이 크게 틀리지는 않은 것 같습니다. 처음에는 효용가치가 매우 높아 보이는 설계로 진행되기 시작한 EIP가 점점 뭔가 고가의 솔루션을 요구하기에 이르고 설계 자체도 처음과 다르게 이리저리 어지러운 설계로 변화해가고 결국 감당하기에 벅찬 설계로까지 변질 되어버려서 새로운 시스템에 대해 고민을 하는 경우도 있더군요.

정리해 볼까 합니다.
어떤 영역에나 적용이 되는 최고의 기술 또는 개발방법론 즉 Silver Bullet은 세상에 없다는 것이 제 생각입니다. 기술이나 개발방법론은 트랜드를 가지고 변화하는 특성이 있습니다. 새로운 언어가 나왔다거나 새로운 개념이 출현하면서 다양한 트랜드로 변화를 하게 되지요. 요즘은 MSA라던가 Reactive라던가 Functional Programming이라던가 하는 것들이 트랜드로 떠오르고 있습니다. 하지만, 이 역시 몇 년이 지나고 새로운 언어나 개념들이 등장한다면 다시 구시대의 유물이 되겠지요. 구시대의 유물인 기술과 개발방법론도 반드시 나쁜 것만은 아니라고 생각합니다. 그 역시 원래의 의도대로 고민하고 잘 다듬는다면 더 나은 방법론과 기술로 탈바꿈할 수 있는 여지가 있는 것들이 많이 있을꺼예요.

위에 말씀드렸던 개발방법론이라던가 기술이라던가 하는 것들이 나쁘다는 것이 아닙니다. 이 부분은 오해가 없으셨으면 좋겠네요.

제가 그리 길지 않은 기간 개발자로 살아오면서 느낀 개발에 있어서 가장 중요한 것은 고객의 소리를 얼마나 잘 들어서 그들의 의도를 얼마나 잘 표현해 내줄 수 있는 것인가라고 생각합니다. 고객의 만족도를 얼마나 끌어올릴 수 있는가지요. 그것을 위해서 개발방법론이라던가 아키텍트라던가 기술들이 필요한 것이 아닐까요? 새로운 것이 기존 것보다 얼마만큼 나아질 것인가를 이야기하고 싶다면 데이터를 가지고 이야기해야 한다고 생각합니다. 새로운 고객에게 이야기하는 것이기에 내세울 데이터가 없다면 기존에 작업했을 때의 통계 데이터라도 제시를 하면서 이야기해야만 하는 것이 아닐까요? 통계 데이터도 일반화의 오류를 범할 가능성이 매우 높습니다만, "단순히 두 배 빨라집니다", "개발 시간이 많이 단축돼요", "확장성이 놀랄 만큼 향상됩니다" 보다는 낫지 않을까요? "제 경험으로 봤을 때는 정말 획기적으로 변화될 것입니다" 라는 말도 마찬가지로 문제가 있지 않을까요? 개발자는 약장사가 아니잖아요? 그보다는 최소한 "10번의 프로젝트에서 8번은 30% 정도의 향상을 보였고 2번은 20% 정도 향상을 보였습니다. 고객님의 요구사항을 좀 더 자세히 분석해봐야 하겠지만, 위의 통계는 고객님께도 충분히 적용될 것으로 보입니다. 위의 통계보다 더 나은 결과를 내기 위해서 고객님과 함께 일했으면 좋겠습니다." 정도의 이야기는 해 줘야 하는 것이 아닐까 싶습니다.

개발자가 거짓말을 하지 않는 세상이었으면 좋겠습니다. 개발자가 특정 기술에 대한 신념으로 인해서 오만해지지 않았으면 좋겠습니다. 그건 신념이 아니라 오해일 뿐이니까요.

별로 가진 것도 없고 내세울 것도 없는 생계형 개발자가 잠시 오만하게 굴어봤습니다.

이 글을 읽으시는 분이 있으시다면 부디 너그러이 봐주시기를...