출처: 클린 소프트웨어

프록시 패턴의 구현목적은 Product의 Database접근과 Business logic의 분리를 위하여 사용하는 패턴입니다.

그렇다고 마구 사용해서는 안되는 패턴이며, 애플리케이션과 API(혹은 네트워크, 데이터베이스)의 둘중 혹은 하나가 잦은 변화가 생길때 중간 레이어에 프록시를 두어서 사용하길 권장드리는 패턴입니다.

위의 그림에서는 Product DB Proxy class가 user가 요청한 data를 Database에 읽거나 직접 쓰는 역할을하며, 그 가져온 data의 Business logic을 처리하는 부분은 Product Implementation 클래스를 delegate하여 사용하게 됩니다.

이렇게하면 장점은 Database에서 데이터를 가져오는 부분과 Business Logic부분을 따로 분리하여 관리할 수 있는 강점을 갖게 됩니다.

예제상황

상품에 대한정보도있으며, 이를 주문하는 시스템이 있다고 가정해 봅시다.

위의 그림에서는 상품에 대한 데이터베이스 정보와 비즈니스 로직을 처리하는 부분을 Product 인터페이스의 하위 클래스들로 구현된 클래스 다이어그램입니다.

또한, 주문을 처리하는 Order인터페이스가 있으며 Order에 대한 데이터베이스 정보와 비즈니스 로직을 처리하는 부분을 Order 인터페이스의 하위 클래스로 구현된 클래스 다이어그램입니다.

참고로 다이어그램에서 -Data로 끝나는 클래스 이름들은 Database에서 받아오는 객체의 정보입니다.

-Proxy로끝나는 하위 클래스들은 직접 Database에 접근 하는 클래스이며, -Impl로 끝나는 클래스들은 비즈니스 로직을 처리하는 부분이라고 보면 됩니다.

이 그림은 프록시들간의 관계를 나타내는 좀 더 응용된 프록시 패턴의 클래스 다이어그램으로 보시면 됩니다.

Product가 원래 존재하였는데, Order시스템 구현으로 인해서 OrderProxy에서 Order DB정보뿐만 아니라, Product의 데이터와 비즈니스 로직이 필요하여 ProductProxy를 OrderImpl에 주입하여주고, OrderImpl과 멤버필드인 item은 Product 인터페이스들을 통하여 Order와 관련된 비즈니스 로직을 처리할때 필요한 Product정보들을 받아오며 이용하는 것이 이 클래스 다이어그램의 가장 주목해서 보셔야 합니다.

프록시 요약

프록시는 사용이 간결함과 단순하지 않습니다. 프록시는 사용하기 까다롭습니다.

프록시의 이점

프록시는 매우 까다로운 특성이있습니다. 그럼에도 불구하고 매우 강력한 이점이 한가지 있는데 그것은 '관심의 분리' 입니다.

위의 클래스 다이어그램들을 살펴보시면 비즈니스로직과, 데이터베이스는 완전히 분리되어있습니다.

업무규칙과 데이터베이스 구현부의 분리가 아주 중요한 인스턴스에서는, 프록시가 적용하기 좋은 패턴이 될 수 있습니다.

애플리케이션은 보통 직접적으로 API를 물고 개발되는편입니다. 다만 서드파티의 API를 바로 사용하지않고 중간 레이어를 두어서 보다 추상적으로 사용하는 편이기도합니다.

단 어떤 경우에는 애플리케이션의 종속성으로 인해 레이어와 애플리케이션 관계가 뒤집어져야 하는 경우도 있습니다.

이런 종속성 뒤집기를 할때, 프록시 패턴이 적용될 수 있습니다. 애플리케이션은 프록시에 전혀 의존하지 않게 됩니다.

이렇게 애플리케이션과 API 사이의 관계정보는 오직 프록시에 집중되게 됩니다.

이 정보집중은 어찌보면 프록시가 악몽이 된다는 것을 의미합니다. API가 변경될때마다, 프록시도 변경됩니다. 애플리케이션이 변경될때마다 프록시도 변경됩니다. 프록시는 매우 다루기 어려운것이 되어버릴 수 있습니다.

차라리 자신의 악몽이 어디에 사는지 알고있는 편이 더 나을 수도 있습니다. 프록시가 없다면, 악몽은 애플리케이션 코드 전체에 퍼질수도 있기때문입니다.

단 프록시가 애플리케이션과 API의 철저한 분리가 이로울 때가 있는데, 스키마와 API 둘 모두 또는 어느 한쪽에서 잦은 변화가 발생하는 아주 큰 시스템의 경우는 거의 그렇습니다. 또 다른 많은 데이터베이스 엔진이나 미들웨어 엔진 위에 얹힐 수 있는 시스템도 그렇습니다. (왼쪽에서 2번째와 3번째 그림에 해당하는 말)

결론

대부분의 애플리케이션에는 프록시가 필요없습니다. 프록시는 아주 무거운 솔루션입니다.

하지만 우리는 프록시가 필요할 것이라는 것은 매우 매력적이라 생각합니다.

그런 필요가 실제로 생기기 한참전에 말입니다.

그러나 이것은 좋은 생각이 아닙니다. 특히 프록시에 대해서는 더욱 그렇습니다.

일단 퍼사드로 시작하고, 필요하면 리팩토링할 것을 권합니다. 그렇게하면 소중한 시간을 아끼고 문제를 줄일 수 있습니다.

유튜브 강의

youtu.be/JEcH5DhRq6U

참고했던 싸이트들

https://jdm.kr/blog/235

https://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9D%EC%8B%9C_%ED%8C%A8%ED%84%B4#%EC%9E%90%EB%B0%94

의존성 역전 원칙 (DIP, Dependency Inversion Principle)

모든 소프트웨어 시스템, 혹은 작은 애플리케이션이라도 Layer가 존재합니다.

어떻게 Layer를 구성하며, 각 Layer마다 의존관계는 어떻게 이루어져야하는지에 대한 원칙이 있습니다.

큰 원칙으로는

 a. 상위수준의 모듈은 하위수준의 모듈에 의존해서는 안된다. 둘 모두 추상화에 의존해야한다.

 b. 추상화는 구체적인 사항에 의존해서는안된다. 구체적인 사항은 추상화에 의존해야한다.

여기서 상위수준이란, 정책의사결정과 업무모델을 포함하는 층, 재사용하기 원하는것들, 어플리케이션의 본질을 담는층 혹은, 고객의 요구사항중 내재하는 추상화, 구체적인 것들이 변경되더라도 바뀌지않는 진실의 핵심적인 내용들이 있는 Layer를 상위수준 Layer라고 합니다.

이런모듈이 하위모듈을 의존하면 안된다고 합니다.

- 하위모듈은 구체적인 모듈을 의미하며, 하위수준의 구체적인 모듈에 영향을 주어야하는 것은 정책을 결정하는 상위수준 모듈이어야합니다.

- 즉 상위수준의 모듈의 변경이 생겼을때, 하위수준의 모듈이 수정, 확장이 이루어지게 되도록 Layer를 구성해야합니다.

상위수준의 모듈이 하위수준의 모듈에 독립적이라면 이 상위수준의 모듈은 아주간단히 재사용 될 수 있습니다. 이 원칙은 프레임워크 설계의 핵십입니다.

위의 그림은 정책이 구체적인 Layer들에 의존하여 실패한 Layer 나누기의 예입니다.

이것을 어떻게 수정할 수 있을까요?

바로 의존성역전원칙을 사용하면 됩니다.

의존성역전원칙을 적용하실때는, 상위수준에서 하위수준에 의존할때 사용하던 메서드들을 인터페이스 뽑은다음, 그 인터페이스를 상위수준에서 의존하게끔 하게 만들면 됩니다. 그리고 그 인터페이스의 구현체는 하위수준Layer에서 구현을 해놓으면 됩니다.

위와같이 의존성이역전되게되면, Utilty Layer의 변화와 Mechanism Layer의 변화가 Policy Layer에게 변화를 안끼치게 됩니다.

여기서 명심하셔야 할 것은, 의존성역전의 결과로 인터페이스의 소유권이 어디있는지 주목 해보시기 바랍니다.

인터페이스는 되게 사용하는층에서 가져야 합니다.

대개 한번쯤은 유틸리티라이브러리가 그것의 고유인터페이스를 소유한것으로 생각하지만, DIP가 적용된 경우에는 클라이언트(사용하는쪽)가 추상 인터페이스를 소유하는 경향이있습니다.

DIP가 아직 무엇인지 이해가 안되신다면 추상화에 의존하자! 이 키워드만 꼭 기억하시기 바랍니다.

구체적인 클래스는 추상적인것에 의존할 수록 좋은것이고, 반대로 추상적인클래스가 구체적인클래스에 의존하면 설계가 실패했다고 생각하시면 됩니다.

이제 간단한 예제2개를 살펴보도록 하겠습니다.

먼저 Button에서 감지한것을 바탕으로 외부객체에 반응을 내보내는 시스템을 만든다고 가정해보겠습니다.

흔히들 처음 목표는 아래그림처럼 버튼눌렀을때 램프를 켜는 시스템을 만들어주세요! 라고 요청이 왔을 것입니다.

하지만 이러한 요구사항에 앞서서 한번더 상위모듈 (정책, 변하지않는 메타포, 추상화) 을 생각해봅시다.

추상화를 좀 더 들어간다면, 버튼이라는것이 눌렸을때, 어떤 대상이 되었건 동작이 발생해야한다가 추상적인 개념이며 이 시스템의 상위모듈에 위치해야합니다.

즉 아래처럼 Lamp를 의존성 역전을 시켜서 버튼의 반응이왔을때 그것이 램프든, CCTV든 Motor든 어떤 외부객체라도 호출할 수 있도록 할 수 있습니다.

역시 인터페이스를 하나 만들고, 상위모듈에 두며, 그 인터페이스의 구현체는 하위모듈에 가는 방식으로 Layer가 나뉘게 됩니다.

 또다른 예제를 살펴보겠습니다. 레귤레이터 시스템이 있고, 현재온도에따라 히터를 틀어주거나 끄거나 하는 시스템이 있다고 가정해봅시다. 구체적인 온도계와, 히터는 밑의 하위모듈로 내리고, 상위모듈에서는 추상적인 인터페이스들로 비즈니스로직을 구성하도록하면, 상위모듈은 하위모듈에 영향을 안받게 됩니다.

유튜브 강의링크

youtu.be/_uBeQkrV-wg

개발자들은 각각의 도메인분야의 개발영역이 있고, 주로 특정 도메인분야에 매진을 하는 편입니다.

안드로이드 개발자라면 안드로이드 앱을 개발할때 쓰이는 자바와, 안드로이드 API들

리눅스 커널 개발자라면 OS에 대한 지식과 디바이스 드라이버 개발 혹은 BSP 등

AI개발자라면 파이썬과 딥러닝분야에 대한 학습

서버개발자라면 Spring Framework 혹은 node js, 자바스크립트 등등

Domain에 따라 사용하는 주언어와 프레임워크, 학습분야 심지어 IDE종류도 천차만별로 달라지게됩니다.

심지어 한 평생 한 도메인에만 종사하는 개발자분들도 있으십니다.

과연 자기의 도메인에서만 쓰이는 것 만 열심히 갈고 닦는게 맞을까요?

물론 회사의 규모와 사정에 따라 한 도메인에 머물거나, 이곳저곳 다양한 도메인을 

경험하는 개발자들이 있는것처럼 개인의 사정에 따라 모두 다르게됩니다.

그러나 현대 Software는 점차 빠르게 변화하면서

SW개발자들에게 다양한 Domain 분야 에서의 업무를 요구하는 추세입니다.

Domain분야가 바뀐다면 그때 그때마다 당장에 일을 하는데 있어서 필요한 분야를 Study 하며 

따라가는게 중요합니다.

하지만, 전역적으로 Domain을 아우를 수 있는 그러한 SW 분야는 없을까요?

있습니다. 여기 제목에 쓰여져 있듯이 저는 알고리즘과 소프트웨어 공학이라고 생각합니다.

알고리즘

개발자가 알고리즘을 잘하면 무엇이 좋을까요?

우선 어떤 문제에 대해서 구현하는 것에 대해서는 막힘이 없게됩니다.

또한, 알고리즘 역량을 더 강화시키면, 성능을 최대한 끌어올릴 수 도 있게됩니다.

즉 요구사항이 주어질때 막힘없이 구현해내며, 성능을 최대한으로 끌어올려 최적화를 이루어낼 수 있습니다.

그렇지만 문제가있습니다.

개발자가 알고리즘역량만 발달되어 있어서 너무 구현과 성능에 치중한 나머지

간단하게는 코드가독성 부터하여 품질 중 변경용이성, 확장성 등을 놓칠 수 있게됩니다.

오히려 유지보수는 더 어려워지며 같이 일하는 동료들도 아무리 기똥찬 알고리즘이지만

이해를 못해서 생산성이 떨어지는 경우도 종종 발생하게 됩니다.

그렇기에 알고리즘역량 뿐만 아니라 아래의 소프트웨어공학 분야에 대한 역량역시 필요합니다.

소프트웨어 공학

알고리즘은 다들 무엇인지 아실겁니다. 다만 소프트웨어 공학에 대해서는 처음 들어보시는분들도 심지어 있으실 수 있습니다. 혹은 학창시절에 "소공은 들어선 안되는 과목이야" 라고 어디서 주워들어서 피하신분들도 있으실 수 있습니다 ^^;;

위키백과에서는 소프트웨어 공학을 아래와 같이 정의하고 있습니다.

-> 소프트웨어의 개발, 운용, 유지보수 등의 생명 주기 전반을 체계적이고 서술적이며 정량적으로 다루는 학문이다

아..역시 난해합니다 ㅡㅡ....제가 접하면서 느낀 소프트웨어 공학은, SW를 개발하고, 유지할때 필요한 학문들을 총괄하여 말하는 것 같습니다.

세부적인 분야로는 디자인 패턴, 요구공학, 테스트 프로그래밍, OOAD/UML, 리팩토링 등이 있습니다.

최종적으로 소프트웨어 공학의 학문들을 한번 Study해보시고 현업에 적용하시게되면 소프트웨어 아키텍트로 최종 거듭나실 수 있습니다.

소프트웨어공학분야를 접하게되는 순간, SW 개발할때 처음부터 끝까지 다 관여하실 수 있게 되거든요.

처음에는 Stake holder들과 미팅을 가지면서 요구사항들을 다 뽑아내고, 그들이 가장 우선시하는 품질들을 뽑아내어 기능 / 비기능 요구사항을 분리하여 정리합니다.

그 이후 설계에서는 어떤 디자인 패턴과 아키텍쳐를 사용할지 결정하고, 구현을 하게 됩니다.

구현 중간중간에서는 Code Quality를 높이기 위해 열심히 코드리뷰와 code metric을 이용하여 점수를 측정하고 올리기 위해 고민합니다.

또한 테스팅을 위해 어떤 프레임워크를 사용하며, 필수 테스팅 항목들을 뽑아내고 TC를 작성하다가, 

잘못 작성된 구현코드를 다시 수정하는등의 활동도 하게됩니다.

SW가 최종 릴리즈가 되고나서도 유지보수 단계에서 리팩토링이 들어가면서 다시한번 가독성도 올리고 Side effect도 줄일 수 있도록 훌륭하게 바꾸는 활동도 할 수 있습니다.

다시 정리해보자면 구현능력을 올리기위해선 우선적으로 알고리즘 역량을 쌓는것이 맞습니다.

하지만 SW를 정식 출시하고 유지보수를 좀 더 잘하기 위해서는 소프트웨어공학 역량을 쌓으셔야 합니다.

이 두 가지 분야는 어느 Domain이든 통하기 때문에 학습해놓으시면 SW개발자로 일하시면서 심지어 관리자로 일할때도 도 계속해서 사용하 실 수 있을것입니다.

Youtube 영상링크

https://www.youtube.com/watch?v=CqwrENwR6UM

추상팩토리 패턴은 도대체 언제 사용해야할까요?

Simple factory pattern과 차이점은 무엇일까요?

사실 필자가 생각하기론 Simple factory pattern과 추상팩토리패턴 (Abstarct Factory pattern)은 거의 흡사하다고 봅니다.

다만, 군(플랫폼, 환경, 개체군)으로 관리해야하는 상황이 생기거나 군 밑의 자식클래스(Concrete class)의 잦은 수정이 생길것으로 판단될 때, 추상 팩토리 패턴을 적용해야 미래에 변경용이성을 가져가실 수 있습니다.

다시한번 말씀드리지만, 군으로 관리해야하느냐 아니냐에 따라 추상팩토리를 사용하느냐 Simple facotry Pattern을 사용하느냐로 결정하시면 됩니다.

추상팩토리 패턴이란?

Product class의 생성을 책임지는 생성에 관한 패턴으로써, 군 별로 Product class 를 책임지고 생성하는 Desgin Pattern

예제상황

View개발자들이 있는데 이 개발자들은 자기가 담당하는 View들이 따로있다. (Button, EditText, CloseButton 등등)

그런데 Window와 Linux 에 따라 각각의 View 군들의 Product class들의 생성을 따로 해야하는 상황이다.

Class Diagram

소스코드

파일구성

ButtonView.java
EditTextView.java
FactoryCreator.java
LinuxButtonView.java
LinuxEditTextView.java
LinuxViewFactory.java
Main.java
ViewFactory.java
WindowButtonView.java
WindowEditTextView.java
WindowViewFactory.java

소스코드 Github 

https://github.com/control-man/design_pattern_sample/tree/master/abstarct_factory

간략한 소스코드 소개

public class FactoryCreator {
	
	static ViewFactory createViewFactory(String OS) {
		if (OS.equals("window")) {
			return new WindowViewFactory();
		} else if (OS.equals("linux")){
			return new LinuxViewFactory();
		} else {
			return null;
		}
	}
}

public class WindowViewFactory implements ViewFactory {

	@Override
	public ButtonView createButtonView() {
		return new WindowButtonView();
	}

	@Override
	public EditTextView createEditTextView() {
		return new WindowEditTextView();
	}

}

public class LinuxViewFactory implements ViewFactory {

	@Override
	public ButtonView createButtonView() {
		return new LinuxButtonView();
	}

	@Override
	public EditTextView createEditTextView() {
		return new LinuxEditTextView();
	}

}


public class Main {

	public static void main(String[] args) {

		ViewFactory viewFactory = FactoryCreator.createViewFactory("window");
		ButtonView buttonView = viewFactory.createButtonView();
		EditTextView editTextView = viewFactory.createEditTextView();
		
		buttonView.doButtonSomething();
		editTextView.doEditTextSomething();
		
		viewFactory = FactoryCreator.createViewFactory("linux");
		buttonView = viewFactory.createButtonView();
		editTextView = viewFactory.createEditTextView();

		buttonView.doButtonSomething();
		editTextView.doEditTextSomething();
	}

}

실행결과

장점

- Product 의 하위 클래스인 Concrete Product 클래스의 수정이나 확장이 발생해도 Client Side에서는

영향을 받지 않는다.

- 군별로 Product를 생성하는 Factory 클래스를 완전 분리함으로써, 코드 가독성이 올라간다.

단점

Product의 종류가 증가되면 수정되는(영향을 받는) 클래스의 수가 많아진다.

(그러므로 개체의 종류는 최대한 미리 정해놓고 진행하는것이 좋음)

만약 Product 가 늘어나면 아래의 Class diagram처럼 변하게 됨 

-> ViewFactory의 인터페이스 수정으로 인해 Concrete View Factory들의 수정사항도 생기고

Client도 변경사항에 대해 영향을 받게 됨.

유튜브 강의 링크

https://www.youtube.com/watch?v=wu2SIkJpaI0

쿠팡이 추려낸 당신이 현재 관심있어 할 법한 상품들

로켓와우

골드박스

매일매일 오전 7시, 하루에 한번씩 진행되는 특가상품들 살펴보기

파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있음

 힘을 강하게, 힘차게 라는 표현을 적고싶은데 갑자기 세다,새다,쎄다 중 어떤 것을 사용해야할지 헷갈리는 경우가 생각보다 많아서 이것도 한번 조사해보자라고 마음먹고 살펴보았습니다.

30년넘게 한국말을 사용하면서 살고 있는데 ㅡㅡ 아직까지도 헷갈리다니...이러니 다른나라말인 영어도 배우기 힘들지라는 생각이 드네요 ㅠㅠ. 아무튼 오늘에서야 한번 제대로 넣어보고자 각성하고 조사해보았습니다.

1. 세다

세다는 힘이 강하다, 기세 등등하다, 강력하다 라는 뜻을 갖고 있습니다.

아마도 많은분들이 힘이세다라고 적으셔야 하는데 실수로 힘이쎄다라고 쇤소리나는 발음으로 그대로 적용하기 부지기수일테지요..저또한 포함이구요 ㅠㅠ. 이 포스팅을 검색하시는 분들 대부분이 웬만하면 1번으로 기억하시고 바로 뒤로가기를 누르셔도 될거라 생각합니다ㅎㅎ

2. 새다

새다는 돈이 빠져나가거나, 물따위의 액체 혹은 수증기 기체같은것이 틈으로 빠져나가거나, 빛이 틈으로 빠져나가거나 할때 사용하시면 됩니다. 모두들 돈 새지 않게 절약정신을 가집시다.

3. 쎄다

쎄다는 그냥 기억안하시면 될 것 같습니다. 공식적으로 등재되어있지 않습니다. 즉 표준어가 아닙니다. 그저 세다의 소리나는 글자라고 할 수 있지요...그러니 오늘부로 쎄다를 어딘가에 적으시는것을 하지 마시기 바랍니다!

1.세다

2.새다

3.쎄다

3단어를 살펴보았지만 사실상 저희는 2가지만 구분하시면 되겠습니다. (3번은 아예 없는단어니깐)

세다와 새다만 유의하셔서 확실히 머릿속에 집어넣으시고 메일이나 작문하실때 사용하시기 바랍니다.

데 vs 대는 언제나 헷갈리기 마련입니다.

정확히 글자의 목적을 이해하진 못하였고 

이때까지 살면서 썼던 글들의 예시를 보며 감각으로 사용하고 있었던것 같아요 ㅡㅡ;;;

사회생활하다보면 사내메일을 쓴다든지 수기로 문서를 작성할 경우 맞춤법이 틀리거나

하면 글쓰는 사람이나 글 읽는 사람이 서로 민망해지기에 제대로 지켜보자라는 마음으로 조사해보았습니다.

계속 복습할겸 3번정도는 정독 해보시기 바랍니다 ㅎㅎ

남에게 들었던 말을 전달할때는 -대, 나의 경험을 보고하듯이 말할때는 -데 로 쓰인다고 보시면 됩니다.

ex)  철수가 영희를 좋아한대

      영준이가 시험 100점 받았대

      우한폐렴이 벌써 확진자가 1천명이 넘었던데

      내가 직접해보니깐 아니던데?

간단요약드리자면

'-데' : 직접경험함 = ~더라

'-대' : 들은말 전달 = ~다고 해

있대와 있대 차이 역시 결국 위의 맥락과 비슷하게 가게 됩니다.

내가 알고있는 내용을 그대로 전달할때는 '있더라'의 뜻으로 '있데'를 사용하시면됩니다.

단순히 남의 말을 빌려사 내용을 전달할 때는 '있다고 하더라'의 뜻으로 '있대'를 사용하시면 됩니다.

대출중에 가장 빠르게 대출되는 종류중에 하나는 신용카드 대출(일명 카드론)입니다.

단, 편한만큼 신용등급은 바로 처참하게 깎이기에 사용하는데 있어서 매우 신중해야하는

대출종류 중에 하나이지 않을까 싶습니다.

그런데 정말로 현금이 없는 상황속에 현금이 무조건적으로 필요한 경우라면 어떨까요?

물론 지인들한테 돈을 빌릴수도있습니다만, 사실 지인들과의 금전거래도 매우 좋지않은 이미지로

비춰지게 되는 법이지요.

그럼 이런생각을 하실 수 있습니다.

오늘 하루가 끝나기전에 돈이 들어올 구석은 분명히 있는 가운데에서, 

돈이 현재 부족하니깐 일단은 신용카드 장기대출로 돈을 바로 땡겨서 사용하고 하루가 지나기전에 갚으면

신용등급도 떨어지지않고 문제도 되지 않을까????

저는 일단 말리고싶습니다.

일단 카드사별로 정책이 너무다도 다르기에 어떤카드사는 바로 nice지키미나 올크레딧에 바로 통보할 수 있으며,

어떤 카드는 실제로 안한다고 하더라도, 만에하나 그날 바로 장기대출을 갚을수없는 상황에 놓였거나 결제시간이 지나버린다면?????

그러면 무조건 빼박 대출로 잡히게 되고 신용등급은 하락하게 되어있습니다.

필자는 과거에 어느 카드사라고 밝힐 순 없지만 하루만에 빌려서 사용하고 바로갚아본적도있으며,

또한 하루만에 빌려서 바로갚으려다가 피치못할 사정으로 갚지못해서 신용등급이 하락 했던 적이 있습니다.

필자같은경우 하루만에 갚았을떄 신용등급에 영향을 받지 않았던 적도 있었으나, 이것은 카드사마다 정책도 전부다르고

과거와 현재의 정책 역시 다르기에 (요즘은 실시간으로 금융사끼리 데이터 공유를 한다고 하지요, 부동산 정책때문에)

이글을 보시고 리스크 있는 행위를 하려고 하지마세요. 제가 책임을 지거나 질수있는것도 아니고 과거의 팩트를 말한것이지(딱 한번) 현재도 이렇다라고도 말씀드릴수없으며 계속 강조드리지만 카드사마다 다를것이며 현재의 금융데이터 공유 정책은 언제나 바뀔수있기에 책임은 본인이 지셔야합니다.

부디 급할 수록 돌아가시기 바랍니다. 길은 언제나 어디에서나 찾으면 나오게 되는법입니다.

안드로이드 시스템은 date format과 time을 제공하고있는데요.

문제는 국가별로 date format이 조금씩 달라서 글로벌 서비스를 하는경우에는 조금은 고민을 해봐야합니다.

어떻게 적절하게 국가별로 date와 time을 보여줄지요.

예로들면 우리나라는 2월24일을 2.24 이런format으로 표현한다면

독일은 24.02. 프랑스는 24/02 등 조금씩 선호하는 방식이 다른편입니다.

국가별로 분기해서 작성하자니 만만지않을것같아서 찾아보니 웬걸? 안드로이드에서는 편이상 이런 기능들까지 다 제공해주고있습니다.

위의 그림은 epoch time으로 한국, 미국, 독일, 프랑스의 date format을 나타내본것이고 

time format도 출력해보았습니다. time format의 경우 현재 사용자가 12시간 format을 사용하고있는지 24시간 format을 사용하고있는지에 따라 출력되게끔 구현하였습니다.

MainActivity.java

main에서만 다 구성하였습니다.

getBestDateTimePattern - 현지 Locale에 맞는 date를 출력해줍니다. 기호에 따라 시간과 분도 format에 출력할 수 있습니다. 여기서 좋고 편한것은, MM과 DD의 위치를 신경쓰실 필요가없습니다.

Locale에 맞도록 적절하게 순서를 다시 바꿔서 return해줍니다.

getProperTimeAsClockPreference - 현재의 context 정보에 맞게끔 time format을 return하게 됩니다.

12시간, 24시간제 인지에 따라 변환해주고 또한, 국가에 따라 조금씩 다른 format을 주기까지합니다.

    public String getBestDateTimePattern (Locale locale) {
        //return  DateFormat.getBestDateTimePattern(locale, "MM dd hh:mm");
        return  DateFormat.getBestDateTimePattern(locale, "MM dd");
    }
    /*
    12 / 24 For distinguish
    static DateFormat	getTimeFormat(Context context)
    Returns a DateFormat object that can format the time according to the context's locale and the user's 12-/24-hour clock preference.
    */
    public java.text.DateFormat getProperTimeAsClockPreference(Context context) {
        return  DateFormat.getTimeFormat(context);
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        Button button = findViewById(R.id.button);
        final TextView tv = findViewById(R.id.textView);

        button.setOnClickListener(new View.OnClickListener () {
            @Override
            public void onClick(View view) {

                SimpleDateFormat dateFormat = null;
                long time = System.currentTimeMillis();

                tv.append("\n time:::" + time);

                String bestDateFormat = getBestDateTimePattern(Locale.KOREA);
                dateFormat = new SimpleDateFormat(bestDateFormat);
                String convertedKoreaDate = dateFormat.format(new Date(time));

                tv.append("\n" + convertedKoreaDate);

                bestDateFormat = getBestDateTimePattern(Locale.US);
                dateFormat = new SimpleDateFormat(bestDateFormat);
                String convertedDate = dateFormat.format(new Date(time));

                tv.append("\n" + convertedDate);


                bestDateFormat = getBestDateTimePattern(Locale.GERMAN);
                dateFormat = new SimpleDateFormat(bestDateFormat);
                convertedDate = dateFormat.format(new Date(time));

                tv.append("\n" + convertedDate);

                bestDateFormat = getBestDateTimePattern(Locale.FRANCE);
                dateFormat = new SimpleDateFormat(bestDateFormat);
                convertedDate = dateFormat.format(new Date(time));

                tv.append("\n" + convertedDate);


                long stampAsCal;
                java.text.DateFormat formatDateTime;
                formatDateTime = getProperTimeAsClockPreference(getApplicationContext());
                String _time = formatDateTime.format(time);

                tv.append("\n converted time:" + _time);
                //kr 24 case: 1:11
                //kr 12 case: 오전 1:11

                //ge 24 case: 1:11
                //ge 12 case: 1:11 vorm

                // remove space
                String convertedConvertedKoreaDate = convertedKoreaDate.replace(" ", "");

                // remove . end of the date
                if (convertedConvertedKoreaDate.length() > 0 && convertedConvertedKoreaDate.charAt(convertedConvertedKoreaDate.length()-1) == '.') {
                    convertedConvertedKoreaDate = convertedConvertedKoreaDate.substring(0, convertedConvertedKoreaDate.length()-1);
                    Log.d("jinss", "gotta");
                }

                convertedConvertedKoreaDate = convertedConvertedKoreaDate + " " + _time;

                tv.append("\n final converted time:" + convertedConvertedKoreaDate);
            }
        });


    }

한국, 미국, 독일, 프랑스에 대해서 시험적으로 테스트 해보았습니다.

또한 최종 date와 time까지 출력도 해보았습니다.

앱을 실행해놓고, 12시간 24시간 변경도 해보신다음 버튼을 눌러서 텍스트가 바뀌어서 나오는지도 한번 확인해보시면 되겠습니다.

대한민국 일반인이라면 누구나 신용등급을 갖고 생활하게됩니다.

다만 어떻게 산정되는것이며 점수와 등급은 어떻게 이루어지는지 모르는 경우가 대부분일 것입니다.

필자역시 어떤 점수가 어떤등급으로 산출되는지 단순한 호기심으로 조사를 해보았습니다.

먼저 우리나라 신용등급 평가기관으로는 nice지키미와 올크레딧이 있습니다.

위와 같이 기관이 2개가 있고, 이 2기관은 상호협력적 상호 배타적도아닌 독립적인 기관이기 때문에 제 각각의 기준을 가지고 저희를 평가하게됩니다.

그렇기에 저희의 신용점수와 등급은 저 2개의 기관이 따로따로 채점을 하기에 다르게 나올수도 있는것입니다.

그럼 2기관의 신용점수와 그에 매칭되는 등급은 어떻게 되는것일까요? 바로 아래와 같은 표로 이루어진다고합니다.

왜 추론이냐면, 두 기관 모두 공식적으로 점수와 등급을 발표를하지는 않았기때문입니다.

그럼 위의 표는 무엇이냐고 질문하실 수 있는데, 이는 각점수별로 각각의 등급을 갖은 사람들의 데이터를 취합해보니 대략 위와 같은 표의 점수와 등급표를 추론할 수 있는것이었고, 수 많은 사람들이 자기점수와 등급을 알고있다보니 99%의 정확도에 맞게 도출해낼 수 있게 된것이지요.

대게 올크레딧이 NICE지키미보다 점수를 후하게 준다고합니다.

또한, 올크레딧이 신용정보변동사항에 대해 점수 반영이 빠른편이기도 합니다.

위의 표를 조사해보면서 신용등급을 올리는요소와 내리는 요소에 대해 살펴보았는데

결론부터 내리자면 올리기는 정말 더럽게? 힘들고 점수와 등급이 내리는건 한순간이라는것을 알게 되었습니다.

추가로 신용등급을 가장 빨리 내리게하는것은 대출인데 

그와중에 2금융 3금융 (단기카드, 장기카드론 포함)에서 받는 대출은 치명적이라 할 수 있습니다.

물론 갚으면 다시 회복하긴하지만, 회복하는데 걸리는 시간은 꽤 드는편입니다.

대출은 받으면 바로 깎이면서....

요즘같은시대에 대출을 받아서 투자를하면 더욱 돈을 벌 수 있는 시대라서 대출은 필수이긴하겠지만

너무 과하게 대출을 받으시면, 신용등급이 내려가기에 대출이 힘들어지게 되고,

정말 투자를해야할때 돈이없어서 발이 묶이는 상황이 올 수 있습니다.

그러니 신중하게 대출을 받으시면서 신용점수와 신용등급 관리를 하시기바랍니다.