오픈 소스로 사업자등록번호의 상태를 조회하는 것을 하나 만들어봤다.

사실 이미 되어 있던 오픈 소스에 마이너한 내용을 컨트리뷰션하거나

혹은 회사에서 제공하는 private repository에 대해서만 작업 경험이 있어서 소스를 어떻게 해야할지 몰랐다.

그래서 Github으로 개인 Maven Repository 만들기 라는 포스팅을 보고 그대로 따라했다.

그랬더니 아래와 같은 오류가 발생했다.

영어로는 already doctype seen이라고 하는데… 아무리 찾아도 적당한 솔루션이 없었다.

혹시나 해서 curl을 했더니 엄청난 html 스크립트가 올라간다. 아!! github 페이지가 통째로 호출됐구나 ㅠ.ㅠ

github.comraw.githubusercontent.com으로 수정했더니 정상적으로 dependency를 가져온다.

예전에 이런 글을 썼었다.

Lombok의 ExtensionMethod를 사용하면 메소드를 확장할 수 있어서 좋겠다고 생각했는데,

결국은 안되는 걸로 결론이 났었다.

그래서 Kotlin을 적용하면 Extensions가 된다고 해서

특히나 BigDecimal 연산에 사용하면 좋겠다는 생각을 했다.

솔직히 위처럼 쓰는 건 가독성도 별로고 너무 구리다.

심지어 Kotlin에서는 연산자 오버라이딩도 가능해서 a + ba - b의 형식으로 만들면 좋겠다는 생각을 했었다.

그리고 오늘 적용해보려고 했더니, 역시나 Jetbrains 님들… 이미 다 해놓으셨네 🙂

ref. https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/java.math.-big-decimal/index.html

지방세는 세금의 종류이기 때문에 연말정산에 영향이 없고, 카드로 내도 아마(?) 카드사에서 별도의 수수료를 취득하진 않는 듯 하다.

다만, 카드사는 수수료와는 별개로 거래볼륨도 중요하기 때문에 꼭 재산세 시즌이 되면 아래와 같은 이벤트를 하게 된다.

지방세 중에서도 재산세는 생각보다 볼륨이 크기 때문인 것 같다.

그런데 계산을 잘못해서… 현대카드는 50만원 이상 누적 사용시 1만원 청구할인인데, KB카드로 해버렸다.

왜 0.2%인데, 1만원보다 크다는 생각을 해버린거지 ㅠ.ㅠ

오류를 고쳤으면 공유하는 것이 미덕이라 생각되어 적어둠

SpringBoot 2.18로 올렸더니 mysql connector에서 오류가 발생하여 고생했는데,
implementation("mysql:mysql-connector-java:8.0.15")라고 버전을 명시하니 오류가 사라짐.
현재 최신 버전은 8.0.16인데, 호환성에 문제가 있는 듯.
아래 링크를 보면 MySQL쪽에서 호환성 처리를 해줘야만 된다고 한다.

ref. https://stackoverflow.com/questions/56893867/error-connecting-to-memsql-with-mysql-j-connector

애플을 가장한 피싱메일이 들어왔다.

애플에서 사용하던 미국계정이라서, 긴가민가했다.

페이지는 너무 진짜처럼 근사하게 잘 만들었다.

그래도 확인이 필요할 것 같아서 이런 저런 링크를 좀 눌렀는데, 다 이미지다.

링크로 동작하는 건 아래 아이디와 비밀번호를 넣는 inputbox 밖에 없다.

피싱이겠구나 싶어서 가짜 아이디와 비밀번호를 넣어봤다.

그랬더니 아이디 체크도 하지 않고 계정확인 페이지로 들어간다.

심지어 막 넣었던 ID인 11@fsdfs.com으로 뜨고, sigin out 마크까지 표시되어 로그인 상태임(?)을 알려준다.

개인 신상정보와 카드 정보까지…

생각보다 잘 만들긴 했는데, 좀더 디테일하게 만들었다면 정말 속아 넘어가지 않았을까?

스타벅스는 자주 가지만, 스타벅스 카드로 결제를 하지는 않아서 언제나 웰컴회원.

그래도 매년 생일쿠폰을 한 장씩 지급해줘서 “와~ 대인배”라는 생각을 했었는데,

아니나 다를까 안되겠는지 정책이 바뀌어 버렸다.1

어차피 그동안 사용하던 커피용(?) 신용카드도 사라졌겠다. 이번 기회에 스타벅스 카드를 사용해봐야겠다.

맥에서 터미널 쓰다 보면,  항상하게 되는 동작이…

어느 디렉토리에 접근하고 나면, 다음 디렉토리나 실행할 파일의 이름을 확인하기 위해서 ls -al을 치는 경우가 많다.

간혹 줄여서 ll로 만들어놓고 치더라도 치는 동작이 항상 들어간다.

그래서 아예 .bash_profile에 아래처럼 넣어버렸다.

(위 구문을 넣고나서 source ~/.bash_profile을 해야하는 건 잊지 말고…)

이제는 cd를 치게 되면, 해당 디렉토리로 들어가서 자동으로 ls -al이 실행된다.

참고로 ls 명령어 조차 아래처럼 alias를 걸어버렸다.

항상 최근 파일이 쉘 커서 근처에 표시되어 보기에 편하다.

맥을 사용하다보니 매번 “다운로드” 디렉토리에는 온갖 것들이 잔뜩 들어서 정리가 안된다.

한 번씩 정리하는 건 맥을 리셋하거나 기기변경을 할 때 정도 뿐인 것 같다.

아예 파일 종류별로 좀 정리되어 있으면 좋지 않을까 해서 스크립트를 만들었다.

아래처럼 해서 매핑 정보를 좀더 nice하게 해줬으면 좋으련만… shell에서는 하기가 힘들 것 같아서 말았다. (python 쓰면 괜찮긴 할텐데)

마지막으로 crontab에 해당 스크립트를 걸어주면 그냥 알아서 정리되지 않을까?

 

일을 하다가 상식적으로 말도 안되는(?) 이상한 반올림 방법을 알게 되었는데,

곰곰이 생각해보니 정말 합리적이라는 생각이 들어서 적어둔다. (사실 처음 들으면 이제까지의 수학을 모두 부정하는 이상한 이론으로 들린다)

0.5를 반올림하면 0이 되고, 1.5을 반올림하면 2가 된다.

이런 공식이 나오게 된 일화1는 다음과 같다.

미국 국세청에서 국민들에게 소송을 당해서 패한 사건이 있었습니다.

년도는 잘 모르겠지만 규약 제정일이 1985년이니까 대충 그 근처리라 생각됩니다.

국민들은, 국세청에서 반올림을 적용해 세금을 거두었기 때문에 한가운데인 0.5 경계에 걸친 사람들은 무조건 올림한 세금을 내게 되어 부당 이득을 취했다고 주장하였습니다.

이에 반해 국세청은 반올림에 의하여 절반은 올리고 절반은 내렸기 때문에 부당 이득을 취하지 않았다고 주장했지만, 결국은 패소하게 됩니다.

그 이후 국세청에서는 새로운 반올림 규칙에 대하여 고민하게 됩니다.

그 결과 첫번째 0.5 경계의 숫자는 내리고 그 다음 숫자는 올리는 것을 반복하는 규칙을 만들어 냈습니다.

이것을 규칙화 시킨 것이 ‘가장 가까운 짝수로 반올림한다’는 내용인 것입니다.

5.5 경계에 걸린 사람은 6.0의 세금을 내야하기 때문에 손해이지만,

4.5 경계에 걸린 사람은 4.0의 세금을 내기 때문에 둘이 서로 상쇄되어 국세청의 부당 이득이 사라지게 됩니다.

생각해본 적이 없었는데, 정말로 공정하지 않은 계산이었던 것이다.

조금더 수학적(?)인 내용은 아래 글2이 잘 설명하고 있다.

반올림문제가 그리 큰 문제가 아닌 것처럼 보이지만 수 백억 원이 오고 가는 금융권에서는 이것으로 인해 적지 않은 금액의 계산이 달라집니다.

대개의 프로그래밍 언어들은 반올림의 방법으로서 “Banker’s rounding”를 사용합니다.

많은 사람들이 이 반올림 방법이 상식적으로 틀린 결과를 돌려주기 때문에 싫어하지만 아이러니컬하게도 이것은 가장 정확한 라운딩(rounding)방법으로서 개발된 것입니다.

이 방법은 0.5이하는 버리고 0.5이상이면 올립니다. 그리고 정확하게 0.5이면 가장 가까운 짝수로 올립니다.

가령 12.5에서 0.5는 버려지고 12로 만들지만 13.5는 0.5를 더하여 14가 됩니다.

Bankers rounding은 Gauss법을 사용하는 것으로 이는 0.5인 경우 2로 나누어질 수 있는 가장 가까운 수로 반올림 한다는 것입니다.

1.5 is rounded to 2
2.5 is rounded to 2
3.5 is rounded to 4
4.5 is rounded to 4

종종 이러한 방법이 일상적인 반올림(Standard Rounding) 상식과 어긋나지만 이 방법은 다음과 같은 정당성을 가집니다.

가령 12.0부 터 13.0사이를 0.1씩의 간격으로 나누면 9개의 값이 들어갑니다.

12.1, 12.2, 12.3, 12.4, 12.5, 12.6, 12.7, 12.8, 12.9 그리고 이 값들은 반올림의 대상이 됩니다.

상식적인 반올림이라면 9개의 숫자 중 5개는 올리고 4개는 버리게 됩니다.

그러나 이 방법은 공평하지 않다.

1/9만큼 한쪽은 더 가지고 한쪽은 부족하게 됩니다.

그러나 0.5에서 가장 가까운 짝수로 옮기도록 하게 되면 어떻게 될까요?

12.0 부터 14.0까지 18개의 반올림 대상이 생기고 버리는 쪽이나 올리는 쪽 모두 9개의 숫자를 나누어 갖게 됩니다.

따라서 한쪽에 치우치지 않는 공평한 셈이 됩니다.

‘은행가의 반올림’이라고 해서 마치 수학적으로는 반하는데, 경제학에서만 사용할 것 같은데 그렇지는 않다.

실제로 컴퓨터 연산에서도 아래3처럼 사용되고 있다.

ROUND_HALF_EVEN

Round towards the “nearest neighbor” unless both neighbors are equidistant, in which case, round towards the even neighbor.

Behaves as for ROUND_HALF_UP if the digit to the left of the discarded fraction is odd; behaves as for ROUND_HALF_DOWN if it is even.

This is the rounding mode that minimizes cumulative error when applied repeatedly over a sequence of calculations,

and is sometimes referred to as Banker’s rounding.

또, 엑셀이나 C#등에서도 기본 Rounding으로 제공하고 있다고 한다.