최근 회사에서 느꼈던 바에 대해서 좀더 잘 정리된 강연 영상이 있어서 기록해둔다.

내용 자체는 연애 관계에서의 긍정적인 에너지를 찾는 방법인데,

사실 회사나 사회생활, 또는 가족간에… 결국 모든 관계에 적용되는 이야기인 것 같다.

https://tv.kakao.com/channel/2687127/cliplink/378364318

부정적인 감정 소통이 잘 안될 때 우리들이 긍정적인 관계 에너지를 만들어내기 어렵다.

우리가 긍정적인 관계 에너지를 만들려고 한다면, 반드시 부정적인 감정을 서로 잘 소통하는 방법이 필요하다.

부정적인 감정소통(언쟁)의 5가지 룰

  • 밥먹고 말하기
  • 개걸상태에서 말하기
  • 문제의 쟁점안에서 말하기
  • 초두효과
  • 만나서 말하기

 

국민건강보험에는 2가지가 있다.

  • 직장가입자
  • 지역가입자

보통은 월급쟁이인 개발자들은 직장가입자이기 때문에 건강보험료에 대해서 별다른 고민을 하지 않는다.

하지만 몇 번의 경험으로 ‘어떤 경우에 닥친 개발자들이 궁금해 할 만한 것’에 대해서 알게 된 사실을 공유해보려 한다.

건강보험료는 무조건 매월 1일 기준의 소속으로 보험료가 청구된다.

예를 들어,

  • 12월 1일에 퇴직을 하여, 12월 2일부터 실업자(?)가 되었다.
    • 퇴직금 정산시 직장가입자 건강보험료도 함께 정산하여 처리된다.
  • 11월 30일에 퇴직을 하여, 12월 1, 2일은 토요일, 일요일이라 쉬고 12월 3일에 다른 곳에 취직을 하였다.
    • 지역가입자로 건강보험료가 청구된다.

몇 번의 이직을 보면, 일을 마무리하고 새로 시작한다는 의미로 월말까지 다니고 월초에 입사하는 경우가 많았는데,

월초가 휴일인 경우가 있어서 중간입사를 하게 되었다.

(건강보험료와 연차계산에서 조금 손해보게 되어있다. 연차는 다른 얘기라서 생략)

하지만 골치 아픈 것 딱 싫다면 해당 날짜를 피해서 월중간에 퇴사, 입사를 하는 게 편할 것 같다.

여기까지는 정보는 아니고 그냥 사설이었다.

본격적으로 얘기해서, 어쩔 수 없이 월초에 실업자(?) 신세가 되어 지역가입자로 편입되는 경우를 보자.

보통 지역가입자는 차, 집(전세, 월세, 자가의 시세) 등으로 산정되어 나온다.

건강보험공단에 문의해 본 결과, 내가 고액 연봉자가 아닌 경우,

혹은 자가를 보유하고 있는 경우에는 지역가입자가 보험금이 더 많이 나온다.

(사람마다 다를테니, 각자 생각을 해봐야 하는 문제)

그럴 때를 위해서 ‘건강보험 임의계속가입’이라는 제도가 있다.

전직장의 3개월 평균 급여에 맞춰서, 직장가입자로 보험금이 청구되도록 신청하는 제도이다.

이 제도가 좋은 점은, 사후 신청이 가능한 점이다.

즉, 본인의 3개월 평균 급여에 맞는 보험금, 일반적으로는 급여명세서에 건강보험료(+장기요양) 항목이 있다.

그 항목과 실제로 지역가입자가 되어 청구명세서가 날아온 금액을 비교해서 유리한 쪽으로 선택하면 된다.

‘임의계속가입’ 제도는 사후신청이 가능하고, 퇴직 후 2개월 이내에만 신청이 가능하다.

그리고 최대 24개월동안 직장가입자로 유예를 해준다.

몇 일전에 IWINV 클라우드로 웹호스팅을 이전했다는 포스팅을 했다. 1

일단 그동안 썼던 포스팅을 모두 옮겼고, 정리를 했다. 그리고나서 오늘 도메인 연결을 기존 호스트메카에서 옮겼다. DNS 설정은 시간이 꽤 걸린다는 사실을 알고 있었으나, 진행이 안되자, 내가 잘못해서 안된 건지 도메인 전파 시간이 필요한 건지 답답해 죽는 줄 알았다. 어찌됐건 NameServer 이전도 하고, 내킨 김에 SSL 설정까지 진행했다. 크롬에서 “안전함”이라고 녹색띠가 나오니까 왠지 기분이 좋았다. 뭐, 저렴하고 생각보다 괜찮은 듯… 🙂

아참, 블로그 복귀하고 텍스트큐브 판올림했다는 포스팅2을 했었는데, 말도 없이 워드프레스로 옮기게 되었다. 사실 2016년도부터 웹호스팅 변경을 계획하면서 함께 진행했었는데 글이 뜸하다보니 갑작스런 변화처럼 보인다. 텍스트큐브가 너무 정감있지만, 업데이트도 잘 안되고 자잘한 버그도 너무 많은 것 같아서 워드프레스로 옮기게 되었다. 게시글 및 댓글들은 모두 이전했지만, 구글에 노출되었던 링크들은 모두 dead link가 되어버렸고, 통계도 처음으로 리셋되어 버려서 조금 아쉽기는 하다.

시작

JUnit5에서 개인적으로 가장 많이 활용하고 있는 기능은 @Nested 이다.
예전 포스트라서 약간 view가 깨지는 부분도 있지만 이런 테스트케이스는 어떨까?(또는 옛날사이트)에서도 많이 고민했던 부분을 JUnit5에서 공식적으로 해결해주었다.

 

소스 코드

간단한 분기문이 있는 코드를 만들어본다. 실제 서비스에서는 훨씬 복잡한 코드가 나올 것이다.

일반적인 테스트 코드

일반적으로 해당 클래스의 각 메소드와 그 메소드 내의 분기문을 결합해서 각각 테스트를 진행하게 된다.
테스트 메소드의 네이밍은 일반적으로 저리 간단하지는 않다.

 옛날 블로그 재탕

JUnit5 @Nested 활용

JUnit5 @DisplayName 추가

추가로 @DisplayName 까지 활용해 보자. 한글로 메소드이름을 지으면 CI툴에서 쉽게 볼 수 있어서 한 때 유행한 적이 있었다.
내가 만드는 테스트코드 그리고 한글코드(또는 옛날사이트)
그런데 실제로 사용해보면 좀 불편한 점들이 있었다.

  • 코드 검색시에 누락됨
  • 한글 특성상 카멜케이스를 적용하기 힘들기 때문에 _를 많이 써야함 (userCoupon -> 사용자_쿠폰)
  • 네이밍 상 일관성 부족 (User -> 유저, 회원, 사용자 등)

그래서 한 때 유행에도 불구하고 결국엔 영어 네이밍으로 모두 귀환했는데, 의외로 @DisplayName을 사용하면 꽤 괜찮다는 생각을 했다.

위의 예는 아니지만, 실제로 서비스에서 사용하고 있는 테스트 결과를 보면 이렇게 나온다.
테스트결과

마무리

혹시 위처럼 테스트를 만드는 것 보다는 코드를 더 간결하게 하는 것이 중요하다고 생각할지도 모르겠다.
코드를 간결하게 만들 수 있는 방법은 언제나 고민해봐야 할 문제이다.
하지만 예전에 테스틀 만들면서 고민하던 부분들이 JUnit5에서 지원되는 것으로 만족해서 포스팅을 남긴다.

친구의 추천으로 팀장닷컴에서 2008년에 시작한 블로그는 웹비넷으로 옮겼다가 내 의지와는 상관없이 기업의 합병으로 호스트메카에서 호스팅하게 되었다.1 아주 저렴한 비용(1년에 1만원 미만)으로 그냥 명맥만 유지하려는 블로그이다보니, 작년(2016년)에는 aws로 이전해볼까 시도했다가… 비용이 감당되지 않아서 재빨리 접었다.

올해도 웹호스팅 갱신 기간이 돌아왔는데, AWS토스트 클라우드N클라우드 등을 고려해보다가 역시나 가격적인 문제가 있어서 접었다. 따로 영리를 추구하는 사이트도 아니고, 사람들이 많이 방문해주는 사이트도 아닌데 굳이 많은 비용을 들일 필요가 없다고 생각해서였다. 현재 사용중인 호스트메카를 연장하면 연 6600원이다.

근데 웹호스팅 사업이 항상 그렇다. 계약당시에는 가격대비 저렴하지만, 몇 년이 지나도 그 가격 그대로지만 제공 스펙도 그대로인… (어차피 기존 장비를 계속 사용하기 때문이겠지만) 시간이 지나고 보면, 제공 스펙 대비 비싸다는 느낌이 든다. 그래서 비슷한 가격의 다른 서비스를 찾아봤는데, IWINV2가 생각보다 괜찮은 것 같다.

내가 사용하는 용도라면 “10원/일”인 서비스로도 충분하지만, 외부도메인 연결이 지원되지 않는다. 그래서 “20원/일”(자그마치 가격이 2배!)인 서비스를 신청했다. 대략 1년에 8000원정도 될 것 같다. 일단 1달 사용해보고 괜찮다 싶으면 이전해서 사용해봐야겠다.

살면서 해야지 해야지 하면서 결국 미루고 미루고 못하게 되는 일들이 있다.

나에게는 그 첫번째가 “독서”이고,
두번째가 “글쓰기(블로깅 포함)”이고,
세번째가 “영어공부”이다.

독서가 어려운 이유는 어릴 때의 독서 습관이 그 기본을 이루는 것 같다. 책이 귀했고, 꼭 사고 싶은 책을 사서 정독하고 몇 번씩 읽었다. 심지어 삼국지 같은 책은 100번도 넘게 읽었고, 재미있는 별자리여행은 너무 읽어서 너덜너덜해진 채로 지금도 내 책장에 꽂혀있다. 그런데 요즈음에는 정보가 폭발적으로 늘어나듯이 책도 엄청난 속도로 출판되고 있다. 몇 년씩 글을 써서 출판하는 것이 아니라 빠르게 출판되는 서적들이 많기 때문에, 독자들도 가볍고 빠르게 읽는 것이 요구되는 시대가 되었다. 그런데 나는 가벼운 책조차도 꼼꼼하게 읽으려 하고, 천천히 정독하게 된다. 그리고 아무리 어렵고, 재미없는 책이라도 읽기 시작했다면 끝까지 읽어야 하기 때문에 책을 읽는 시간은 점점 늘어지게 된다. 그래서 이 건 생각을 바꾸어 해결하기로 했다. 읽고 싶은 책이면 사서 책장에 꽂아둔다. 그리고 바로 다 읽을 수 있으면 좋지만, 그렇지 못한 경우에도 압박을 느끼지 않는다. 그리고는 다음에 마음이 내킬 때에 다시 책을 읽으면 된다. 이렇게 하면 결국 시간이 오래 지나도 다 못 읽는 책이 생기기도 하지만, 거꾸로 내가 필요하다고 느끼는 순간에 책을 접하게 되기 때문에 재미있고 빠르게 읽을 수 있는 장점이 생겼다.

글쓰기도 어렵다. 특히나 이제는 메신저, SNS를 사용하는 세대가 되었다. 글은 140자 내외로 써야하고, 댓글은 짧게, 카톡이나 라인같은 메신저도 짤막짤막하다. 모든 글은 한 문장으로만 기록되어지지, 문단 단위의 글은 언제 쓰게 되었는지 기억도 나지 않는다. 그러다보니, 블로그를 써야지… 일기를 써봐야지… 하는 것들의 결심은 생각처럼 잘 지켜지지 않는다. 블로그나 일기장 앱이나 한 두 문장만 쓰여지면 그 횡한 느낌이 싫어서이다. 결국 페이스북이나 트위터같은 것들에 짤막짤막한 단상을 기록하게 된다. 어떻게 하면 좀더 편하게 글을 쓸 수 있을까 요즘 많이 고민하고 있다. 마크다운을 도입해서 좀 간편하게 글을 써보려고 노력하고, 각종 앱 또는 서비스를 이용도 해본다. 하지만 결국 글쓰기는 결심인 것 같다. 부족하더라도 조금씩 계속 써나가는, (IT에서 자주 언급되는) MVP 모델로의 블로깅을 해보려고 한다.

마지막으로 영어공부 (회화가 어떻게 공부일 수 있을까 라는 생각이 들지만…). 영어 공부야 말로 십 몇년을 하고 있음에도 전혀 늘지 않고, 해야 한다는 부담감은 가장 큰 것 중에 하나이다. 하려고 결심해도 몇 일, 몇 달이면 그만이고, 하는 동안에 늘어나는 느낌이 들지도 않고. 매번 머리속에 떠오르는 건, ‘차라리 해외에서 몇 달이고 살면 금방 늘텐데’하는 자기 푸념뿐이다. 그런데 여행이 아니고서야 해외에 나가는 건 영어를 할 줄 알아야 한다는 전제 조건이 있다. 닭이 먼저냐 달걀이 먼저냐의 문제가 된다. 이건 어떻게 해야할 지 정말 모르겠다. 미드를 봐도, 팝송을 들어도, 외국 아티클을 봐도 언제나 한국어가 익숙해서 돌아오게 되는 건 나이를 먹어서일까…

아무런 문제가 없어보이는 코드에서 오류가 발생했다.

분명 HttpMethod는 multi value를 지원하는 값이다.

나중에야 사용하고 있는 swagger에서 multi value를 지원하지 않는 것을 알게 되어 기록을 남겨둔다.

you can currently only have one HTTP verb per op.

https://github.com/swagger-api/swagger-ui/issues/183

Base64 인코딩을 사용하고 있는데, java.lang.IllegalArgumentException: Illegal base64 character 2b 오류가 발생하여 디버깅하다가 알게된 내용을 정리한다.

컴퓨터 분야에서 쓰이는 Base 64 (베이스 육십사)란 8비트 이진 데이터(예를 들어 실행 파일이나, ZIP 파일 등)를 문자 코드에 영향을 받지 않는 공통 ASCII 영역의 문자들로만 이루어진 일련의 문자열로 바꾸는 인코딩 방식을 가리키는 개념이다.
원래 Base 64를 글자 그대로 번역하여 보면 64진법이란 뜻이다. 특별히 64진법이 컴퓨터에서 흥미로운 것은, 64가 2의 제곱수(64 = 26)이며, 2의 제곱수들에 기반한 진법들 중에서 화면에 표시되는 ASCII 문자들을 써서 표현할 수 있는 가장 큰 진법이기 때문이다. 즉, 다음 제곱수인 128진법에는 128개의 기호가 필요한데 화면에 표시되는 ASCII 문자들은 128개가 되지 않는다.
그런 까닭에 이 인코딩은 전자 메일을 통한 이진 데이터 전송 등에 많이 쓰이고 있다. Base 64에는 어떤 문자와 기호를 쓰느냐에 따라 여러 변종이 있지만, 잘 알려진 것은 모두 처음 62개는 알파벳 A-Z, a-z와 0-9를 사용하고 있으며 마지막 두 개를 어떤 기호를 쓰느냐의 차이만 있다. 1

그런데 기존의 base64 mapping table을 보면, ‘+’와 ‘/’ 문자가 존재한다. 이런 문자들은 http 통신을 할 때에 각각 공백과 path로 오해할 수 있는 부분이라서 문제가 발생한다. 그래서 urlsafe방식이 나오게 되었는데, ‘+’문자와 ‘/’문자를 각각 ‘-‘문자와 ‘_’문자로 치환하여 사용한다.

mapping table이 다르기때문에, 같은 base64라 하더라도 urlsafe와 standard는 혼용하여 사용할 수 없다.

 

나는 variable type을 정확하게 하는 편을 좋아하는데, 외부API를 연동하게 되면 어쩔 수 없이 텍스트를 다루어야 할 때 생긴다. 그럴 때마다 Guava 유틸 클래스들을 자주 이용하는 편인데, 특히 Joiner는 오래 전부터 사용하고 있었다. 그러다가 최근에 아래 로직을 refactoring하려다보니 Joiner의 반대 기능이 필요했다.

그래서 찾아봤더니 Guava에 Splitter가 존재했다. 누가 그랬던가 개발자가 예상한 것처럼 기능이 존재하고 동일하게 동작하는 코드는 아름답다  라고.

Lombok에서 getter/setter/constructor/log 등을 만들어주는 기능을 아주 잘 사용하고 있다. 이제는 lombok이 없으면 개발을 하기 힘들 지경. 새로운 회사에 와서 가장 먼저 pom.xml에 추가하자고 주장했던 것 중에 하나도 lombok이었다.

최근에는 Lombok Experimental도 관심을 많이 가지고 @UtilityClass와 같은 걸 잘 사용하고 있다. 그러다가 @ExtensionMethod를 발견했는데, 처음에는 응??하다가 와!!했다.

그런데 정작 적용해보려니까 안되는 것이다 🙁 한참 삽질 후..

(시간적인 공백…)

아직 intellij lombok plugin에서 지원하지 않는 것이었다. 처음 논의가 시작된 게 2013년인데, 아직도 적용 안된 것은 당황스러웠다.

it would be very very very hacky to do (by Techable)

이래서 직접 만들어쓰는 오픈소스 커미터들이 생기나보다.