제목이 "고찰" 이라니 먼가 있어보이긴한데.. 사실 별거 없습니다. ^^

어떤 개발자싸이트에 올라온 질문에 대한 저의 답변을 블로그에 정리해봅니다.


질문:


헤드퍼스트 책 보고 공부하다보니깐, 심플 팩토리보다 팩토리 메서드 패턴이 더 좋다는것같은데,

심플팩토리도 충분히 괜찮은것같은데 어떤점이 더 좋은건가요..? 책을 또 읽어봐도 이해가 잘 안되서...

답변 부탁드립니다~!


답변:


심플팩토리는 그냥 하나의 부모로부터 상속받은 객체중 하나를 클라이언트에게 던저주는것.

팩토리 메소드는 자신이 구현상속을 해야 하며,오버라이딩을 통해 객체 생성하는것!  입니다.


두개의 공통점은 어떤 객체를 생성해서 사용할지를 런타임시까지 미룬다는것이며

중요한 차이점은 팩토리가 상속받은거냐, 아니냐일 뿐입니다.

따라서  객체생성의 종류의 수 와는 무관합니다.

차라리 객체생성군으로 넘어가려면 abstract  factory  와 비교해야 맞는거 같습니다.


결국 둘중하나의 선택의 기로에서는 팩토리 자신의 부모가 있냐 없냐에 따른 장단점에 집중하면 폭을 좁힐수 있을거 같습니다

  

개인적으로 팩토리 메소드 패턴은 GOF 의 모든 패턴중 가장 이상하다고 보며 (  이름도 이상하고 부모레벨에 로직이 들어 간다는것도 별로고 , 유지보수등) , 대부분 심플 팩토리나 abstract  factory  로 대체 해야 한다고 볼 정도입니다. 이건 정말 고정적일꺼야 하는 최후의 코드정도 쓸까?



재질문:


일단 하마님이 하신 말씀중에 ,

심플팩토리는 그냥 하나의 부모로부터 상속받은 객체중 하나를 클라이언트에게 던저주는것.

이게 무슨말인지 이해가 잘 안가네요..ㅠ



재답변:


 "심플팩토리는 그냥 하나의 부모로부터 상속받은 객체중 하나를 클라이언트에게 던저주는것"

아래소스보시면  하나의 부모란 interfaceA 이고

상속받은 객체란 AProduct / BProduct 가 되는것이며, 

팩토리에서는 클라이언트한테 위의 두객체중 하나를 던저주고있습니다.  이해되실런지요?

 (http://corey.quickshiftconsulting.com/blog/first-post  <- UML 참조) 

class SimpleFactory{


     interfaceA create_A(String type){

          if(type == A){

               return new AProduct();   

           }
           else{

               return new BProduct();              
           }

     }

}


interfaceA{}

class AProduct implements interfaceA{}
class BProduct implements interfaceA{}


그 책은 먼가 팩토리메소드 패턴에 대해서 굉장히 긍정적으로 바라보고 있나 보군요 :-) 

부모레벨에 코드가 고착화 되있는데, 유연성이 좋아진다라..-.-a  편의성/합치성이 좋아진다거나 

abstract factory 라면 모를까..흠흠 퇴근길에 참고해 보도록 하겠습니다.


어쨋던 가장 중요한부분은 팩토리 자신이 부모로부터 상속받았느냐? 라는것입니다.

부모에 이미 구현된 코드들이 있으면, 하위 클래스들은 어떤부분에서  편하겠지요? 

그리고 어떤 순서등에 대한 약속이 부모에게 단단히 고정되어있다면 얻는 장점이 있겠지요? 

그런게 팩토리메소드의 장점 중 하나입니다.

결국 심플팩토리에 비한 장점이란 ~  "객체지향에서 상속의 장점은 무엇이냐"  와 마찬가지인겁니다.

마찬가지로 단점이란~~ " 객체지향에서 상속의 단점은 무엇이냐?"  와 같아지는겁니다.

순서


1. 소개 

2. Abstract Factory 패턴 

3. State 패턴

4. chain of Responsibility 패턴 

5. Adapter 패턴

6. Bridge 패턴 

 

디자인 패턴을 공부할때 가장 유념해야할 단어는 "의도" 이다.  절대 모양 (구조) 가 아니다.  그리고 구현함에 있어서 책 등에 나와 있는 모양 그대로 구현하려고 할 필요도 없다. 너무 잘 하려고 하다보면 아예 하지도 못할지도 모른다.  "의도" 만 확실히 이해한 다음에 구현을 이것저것 거침없이 하다보면.... 코딩에 대한 재미는 생겨날 것이다. 재미는 실력향상을 의미하기도 하고 ~  


JDBC 는 자바에서 정한 DB 와의 관계에 대한  행동 지침이다. 행동지침을 공통화하려면 어느 정도의 유사성이 있어야 한다. 세상에는 많은 자동차가 있지만 행동 지침은 비슷하다. 그러기에 운전자들이 다른 메이커의 자동차를 운전하더라도 어느정도는 쉽게 할수있지 않은가.. 마찬가지로  세상에는 많은  DB 가 있고.   각각의 DB 에서 데이터를 가져오는 방법(행동) 이  DB  마다 다르다면 따로 따로 공부를 해야하지만 , 행동지침이 정해져 있고, 모든 DB 가 그것에 맞춰서 개발을 한다면 , 개발자는 정해져있는 행동지침 ( JDBC ) 만 공부하면 된다.  


JDBC  를 디자인패턴과 함게 묶은 이유는 ,  일단 디자인 패턴을 이해하는 가장 효율적인 방법은 다른사람(특히 구루들) 이 잘 구현해놓은 코드(패턴)을 보고 감흥하는것인데 JDBC 를 구현한 코드들에는 몇몇개의 패턴이 뚜렷하게 녹아져 있다.  


5. Adapter  패턴




* Apdater 패턴은 위 전체 JDBC 패턴 모식도중 빨강 네모상자 안에서 이루어집니다.


어댑터하면 떠오르는것은 외국의 110v 콘센트에 우리나라에서 사용하고있는 가전제품 220v 짜리를 끼기위한  110v -> 220v 짜리 어댑터인데요.  여기서 변환하는것을 "어댑터" 라고 하고 , 변환당하는 110v 컨센트를 "어댑티" 라고 합니다. 따라서 위의 모식도에 Cursor 에 어댑티라고 써있고 , HAMAResultSet 에 어댑터라고 써있는것을 보아 , 클라이언트는  Cursor 를 직접적으로 사용하지 못하고 어댑터인  HAMAResultSet  라는 어댑터를 사용한다는것을 알수있습니다. 좀 더 깊이 들어가기 전에  정의를 내려봅니다.

클래스(어댑티)가 실제로는 지원하지 않는 인터페이스를 지원하는것 처럼 만든다.  (즉 클래스의 인터페이스를 클라이언트가 기대하는 인터페이스로 변환해 준다). 이를 통해 리팩토링 없이도 기존의 클래스를 이용해 새로운 클래스를 만들수있다.  - 실용주의 디자인 패턴 - 

(CURSOR 는 DB 에서 제공하는 객체이고java.sql.ResultSet 은 인터페이스 표준이다.) 



Adaptee : (클라이언트가) 원하는 인터페이스를 지원하지 않는 객체.

Target    : Adaptee 가 지원하길 바라는 인터페이스

Adpater : Adaptee 가 Target 인터페이스를 지원하는 것 처럼 보이게 해주는 클래스. 


결국 CURSOR 를 java.sql.ResultSet 처럼 보이게 하기위한 클래스를 만들자!!!  입니다.



어댑티를 어댑터의 부모클래스로 둘수도 있으며, 

어댑티를 어댑터의  연관(Aggregation)으로  관계를 맺을수도 있다.


// 어댑티가 부모클래스

class Adapter  extends Adpatee implements java.sql.ResultSet{

      void func(){   // ResultSet 인터페이스의 구현   

              orgFunc();  // 실제 작동하는 Adpatee 의 함수

     }

}


// 어댑티를 내부에 연관(Aggregation)

class Adapter  implements java.sql.ResultSet{

      Adpatee  adp;

      Adapter(Adaptee adp){

this.adp = adp;

}

     void func(){   // ResultSet 인터페이스의 구현   

             adp.orgFunc();  // 실제 작동하는 Adpatee 의 함수

     }

}


JDBC 나 보통 프레임워크에서 어댑터 패턴은 거의 쓰이질 않는다. 왜냐면 어댑터라는건 만들어져있는  라이브

러리를 사용할때 ( 유연성을 높히기 위해 )필요로 하기때문이다.

 

자!! 이제 실제 HAMAResultSet 클래스의 내부를 보자.

public lass HAMAResultSet implements java.sql.ResultSet {  // HAMAResultSet  는 어댑터이다. 

private final Cursor cursor;   // adpatee 역할을 하는 Cursor 를  가지고있다.

public HAMAResultSet(Cursor cursor){

     this.cursor = cursor;

}


public boolean next(){

     return cursor.advance();      // 클라이언트가 next 를 호출하면, advance() 로 변경시켜준다.

}                                                       110v 가  220v 로 바뀌듯이..


public int getInt(String columnName){     // HAMA DB 는 모든컬럼이 Sting 으로 저장되어있음.

String contents = getString(columnName);

return (contents ==  null) ? 0 : format.parse(contents).intValue();

}


public ResultSetMetaData getMetaData(){

return new HAMAResultSetMetaData(cursor);

}


HAMAResultSetMetaData (  이 버전은 모든 컬럼의 형이 VARCHAR 임) 

public class HAMAResultSetMetaData implements java.sql.ResultSetMetaData{

private final Cursor cursor;

public HAMAResultSetMetaData(Cursor cursor){

this.cursor = cursor;

      }

      public int getColumnType(int colum){

return java.sql.Types.VARCHAR;

      }

      public String getColumnTypeName(int column){

return "VARCHAR";

     }





레퍼런스 :  실용주의 디자인 패턴 (http://www.kangcom.com/sub/view.asp?sku=200607180006 )






1. main 으로 시작한다.  (크게 2개의 컴포넌트(?) 로 나누어진다. HTTPConnector 와 SimpleContext) 


2. main 은 각각의 클래스들의 객체를 생성하고 의존관계를 맺은 후에  HttpConnector 의 start 를 호출하여 

  솔루션이 시작된다.


3. 크게 2가지 파이프라이닝이 있다. ( 파이프라인에 대한건 chain of responsibility 패턴이나 ,  intercepting 

   filter 패턴을 알면 이해하기 쉽다) . 이걸 이해해야한다. 


4. SimplePipiline 은 intercepting filter 패턴에서 매니저 역할이다. 이것은 각각의 valve (filter 와 같다) 를 순

  회하며 각각의 선행작업을 한후에 마지막에 basic 작업을 하며 종료한다. 마치 필터들이 선행해서 어떤 액션

  을 한후에 마지막에 컨트롤러가 마무리하는것과 같다. 


5. SimpleLoader 는 서블릿 클래스를 메모리로 올리는 유틸리티성 클래스이다.


6. HTTPConnector 는 젤 앞에서 서버소켓을 운용하며, 클라이언트과 커낵션을 맺고, request/ response 객

  체를 생성하여 SimpleContext 객체에 invoke 한다. 


7. SimpelContextMapper 는 내부의 맵을 이용하여 url 에 맞는 서블릿을 리턴해준다. 


8. SimpleWrapper A 는 A 서블릿의 래퍼이다. 


9. 중요한 2가지 파이프라이닝에 대해서 알아보자.


10. 첫번째 파이프라이닝은 SimpleContext 가 가지고있는데 , 해당 파이프라이닝은  value 로써

    ClientIPLoggerValve 와 HeaderLogerValue 를 가지고있으면 마지막 basic 은 SimpleContextValve 를 호

    출하며 끝마친다. 

    예상하듯이 앞의 두 밸브는 필터역할을 하며, 마지막 SimpleContextValve  는 클라이언트가 요청하는 서

    블릿을 찾아내어 해당 서블릿의 파이프라이닝을 시작한다.


11. 두번째 파이프라이닝은 SimpelWrapper A 에 등록된 valve 를 따라가며 진행되는데, 이 예제에서는 선행 

     valve  는 없으며 마지막 basic 이  SimpleWrapperValve 이다. 

     SimpleWrapperValve  의 역할은 클라이언트가 요청한 서블릿의 service 메소드를 호출하는것이다.


     결국 우리가 어떤 서블릿(컨트롤러) 를 만들어서 톰캣이나 스프링에 설정해두면, SimpleWrapperValve 

     이 해당 컨트롤러를 호출하게되는것이다.


아래 코드는 SimpleWrapperValve  의 invoke 함수이다. 


public void invoke(Request request, Response response, ValveContext valveContext)

    throws IOException, ServletException {


    SimpleWrapper wrapper = (SimpleWrapper) getContainer();

    ServletRequest sreq = request.getRequest();

    ServletResponse sres = response.getResponse();

    Servlet servlet = null;

    HttpServletRequest hreq = null;

    if (sreq instanceof HttpServletRequest)

      hreq = (HttpServletRequest) sreq;

    HttpServletResponse hres = null;

    if (sres instanceof HttpServletResponse)

      hres = (HttpServletResponse) sres;


    // Allocate a servlet instance to process this request

    try {

      servlet = wrapper.allocate();

      if (hres!=null && hreq!=null) {

        servlet.service(hreq, hres);

      }

      else {

        servlet.service(sreq, sres);

      }

    }

    catch (ServletException e) {

    }

  }


'WAS &amp; 웹서버' 카테고리의 다른 글

톰캣 최종분석 ex14 소스 분석  (0) 2015.08.24
톰캣 클래스패스의 이해 (번역)  (0) 2015.07.31

순서


1. 소개 

2. Abstract Factory 패턴 

3. State 패턴

4. chain of Responsibility 패턴 

5. Adapter 패턴

6. Bridge 패턴 

 

디자인 패턴을 공부할때 가장 유념해야할 단어는 "의도" 이다.  절대 모양 (구조) 가 아니다.  그리고 구현함에 있어서 책 등에 나와 있는 모양 그대로 구현하려고 할 필요도 없다. 너무 잘 하려고 하다보면 아예 하지도 못할지도 모른다.  "의도" 만 확실히 이해한 다음에 구현을 이것저것 거침없이 하다보면.... 코딩에 대한 재미는 생겨날 것이다. 재미는 실력향상을 의미하기도 하고 ~  


JDBC 는 자바에서 정한 DB 와의 관계에 대한  행동 지침이다. 행동지침을 공통화하려면 어느 정도의 유사성이 있어야 한다. 세상에는 많은 자동차가 있지만 행동 지침은 비슷하다. 그러기에 운전자들이 다른 메이커의 자동차를 운전하더라도 어느정도는 쉽게 할수있지 않은가.. 마찬가지로  세상에는 많은  DB 가 있고.   각각의 DB 에서 데이터를 가져오는 방법(행동) 이  DB  마다 다르다면 따로 따로 공부를 해야하지만 , 행동지침이 정해져 있고, 모든 DB 가 그것에 맞춰서 개발을 한다면 , 개발자는 정해져있는 행동지침 ( JDBC ) 만 공부하면 된다.  


JDBC  를 디자인패턴과 함게 묶은 이유는 ,  일단 디자인 패턴을 이해하는 가장 효율적인 방법은 다른사람(특히 구루들) 이 잘 구현해놓은 코드(패턴)을 보고 감흥하는것인데 JDBC 를 구현한 코드들에는 몇몇개의 패턴이 뚜렷하게 녹아져 있다.  


4. Chain of Responsibility 패턴





* chain of responsibility 패턴은 위 전체 JDBC 패턴 모식도중 빨강 네모상자 안에서 이루어집니다.



1. DriverManager 와 Driver 와의 관계 


먼저 DriverManager 와 Driver 에대해서  알아보겠습니다.

보통 JDBC 프로그래밍할때 아래처럼 하는데요

static final String JDBC_DRIVER = "com.hama.jdbc.HAMADriver";  
static final String DB_URL = "jdbc:hama://localhost/EMP";

   
      // 1. JDBC driver 등록 
      Class.forName(JDBC_DRIVER);

      // 2. DB 로의 connection
      conn = DriverManager.getConnection(DB_URL,USER,PASS);

      // 3. Statement 를 통한 Query 명령 
      stmt = conn.createStatement();
      
      String sql = "SELECT id, age FROM Employees";
      
      // 4. result set 으로 부터 데이터 가져오

      ResultSet rs = stmt.executeQuery(sql);

      // 5. 커서를 통해 한 로우씩
      while(rs.next()){

         // 6. 한 컬럼씩 가져오기 
         int id  = rs.getInt("id");
         int age = rs.getInt("age");
       

      }
                             (코드 -1)


위의 소스 예제에서 

// 1. JDBC driver 등록 Class.forName(com.hama.jdbc.HAMADriver); // JDBC_DRIVER -> com.hama.jdbc.HAMADriver // 2. DB 로의 connection conn = DriverManager.getConnection(DB_URL,USER,PASS);


이 부분에 집중해 보도록 하겠습니다.

1 번에서 com.hama.jdbc.HAMADriver 를 자바 리플렉션을 이용하여 메모리로 올리고 있습니다.

JDBC 드라이버를 메모리로 올릴때 어떤 행동을 할가요? 소스를 살펴보겠습니다.


public class HAMADriver implements java.sql.Driver {

private HAMAConnection connection;

static{

java.sql.DriverManager.registerDriver(new HAMADriver() );

}

..

public boolean acceptsURL(Stirng url){

return url.startWith("jdbc:hama");

}

}


(코드 -2)


HAMADriver  라는 클래스 파일이 하드에서 메모리로 Class.forName 을 통해서 메모리로 끌어 올려

질때  위의 (코드-2) 의 빨강색 코드가 호출됩니다. 코드를 보시면 DriverManager 에 스스로의 인스턴

스를 생성해 서 등록시키고 있습니다. 


그렇습니다~!!!  그렇기 때문에 아래의 코드가 성립이 되는것이지요.

conn = DriverManager.getConnection(DB_URL,USER,PASS);


위의 코드에서 DriverManager 가 어떻게 내가 원하는 DB 에 접속할수 있는 Connection 을 리턴할수있었겠습니까?  Class.forName 을 통해서 HAMADriver 가 DriverManager 에 등록되 있기때문에 가능한것입니다.


자!! 여기서 질문 !~


Class.forName 에  위의 HAMA 데이터베이스에 접근할수있는 Driver 에 추가적으로

MySql 에 접근할수있는 드라이버를  Class.forName("com.mysql.jdbc.Driver");  요렇게 

아래에 추가했다고 칩시다.


이럴때 conn = DriverManager.getConnection(DB_URL,USER,PASS);는 어떤 DB 에 접속할수있는 드라이버의 Connection 인터페이스를 리턴해줄까요??


자!! 이럴때 필요한게 Chain of Responsibility 입니다~ 이름에 "의도" 가 그대로 뭍어나 있습니다.

"체인을 돌면서 해당 행위에 책임감있는 놈에게 일을 시키겠다." 뭐 이쯤 이겠지요.


그럼 책임감 있는놈을 어떻게 찾을것인가?? 

위의 그림 2의 파랑색 코드를 보시면 


public boolean acceptsURL(Stirng url){

return url.startWith("jdbc:hama");

}


요렇게 되있습니다.  그렇습니다. DB 에 접속하기위한 URL 이 어떻게 시작되냐에 따라서 선택된다는 야그~

무지 간단하죠??  DriverManager 는 자신한테 등록되있는 드라이버를 for 문 돌면서 각 드라이버의 

acceptsURL 를 호출해서 ok 떨어진놈을 찾는거죠. 


실제 오라클(썬?)에서 구현한 java.sql.DriverManager 코드를 보면



public static Driver getDriver(String url)

  258           throws SQLException {

                 .... 생략 ...

  268           for (DriverInfo aDriver : registeredDrivers) {   //  (1)  for 문 돌면서 

  269               // If the caller does not have permission to load the driver then

  270               // skip it.

  271               if(isDriverAllowed(aDriver.driver, callerCL)) {

  272                   try {

  273                       if(aDriver.driver.acceptsURL(url)) {  //  (2) 적합한 드라이버를 찾는다.

  274                           // Success!

  275                           println("getDriver returning " + aDriver.driver.getClass().getName());

  276                       return (aDriver.driver);

  277                       }

  278   

  279                   } catch(SQLException sqe) {

  280                       // Drop through and try the next driver.

  281                   }

  282               } else {

  283                   println("    skipping: " + aDriver.driver.getClass().getName());

  284               }

  285   

  286           }

              ......

  290       }



위 처럼 (1) 등록된 드라이버를 순회하면서 (2) 적합한 드라이버를 찾고 있습니다.


jdbc:hama:// 로 시작되는 DB_URL 일 경우는 HAMADriver 가 가지고있는 Connection 을 

리턴해주고  Postgresql 은 jdbc:postgresql 일테고  MySQL 은 jdbc:mysql 입니다.


chain of responsibility 패턴 은 이렇게 끝났습니다.  너무 간단해서 허무할 정도네요 ^^



너무 간단하게 끝나서 , 각자 판단할꺼리를 던저 보도록 하겠습니다. 댓글로 각자의 생각을 달아주시

면 고맙겠는데요. 웹 개발자분들은 대부분 아시는 서블릿 필터에 대한 이야기입니다. 몇몇 책이나 사들이 

필터를 얘기할때  "데코레이터 패턴" 이라 고 말하기도 하는데요  토비의 스프링인가 ? 그 책에서도 언급된거 같

은데 잘 기억은 안납니다만..~  (다이나믹 프록시 설명할때 나왔나 하기도 하네요) 

참고로 데코레이터 패턴의 전형적인 사용예는 자바의 IO 가 있지요.   


자~!!!   서블릿 필터는 진짜 데코레이터 패턴에 가까울까요?


그럼 이 시리즈에서 강조한 각 패턴의 "의도" 를 써 봅니다. 너무중요해서 빨강색 쫙~~

( 제가 정리한건 아니고, "GOF 책" 과 실용주의 디자인 패턴" 책 참고)

Chain of Responsibility 패턴 

일련의 객체 집합이 잘 정의된 통로(chain) 을 통해 메세지를 전달함으로써 하나 이상의 객체에 메시지를 처리할수 있는 기회를 준다.

주어진 메세지에 가장 적합한 객체가 메시지를 처리한다. 또한 하나 이상의 객체가 메시지를 처리하는것이 가능하다.


GOF :  요청을 처리할수 있는 기회를 하나 이상의 객체에게 부여함으로써 요청하는 객체와 처리하는 객체 사이의 결합도를 없애려는 것이다. 요청을 해결할 객체를 만날 때 까지 객체 고리를 따라서 요청을 전달한다.


Decorator 패턴 

런타임시 객체에새로운 능력을 추가하거나 객체의 행위를 변화시킨다. Decorator 는 상속 대신 합성을 사용하여 클래스 계층 구조를 단순화 시킬수 있다. 

GOF: 객체에 동적으로 책임을 추가할수 있게한다. 데코레이터 패턴은 기능의 유연한 확장을 위해 상속대신 사용할수 있는 방법이다.



자 어떠십니까?? 

필터는 브라우저에서 요청에 대해서 파이프라인을 가지면서 , 어떤 선행 처리를 합니다.

그 처리를 단계별로 거치면서 중첩적인 ( 꾸미는) 처리를 하는걸까요?

파이프라인중 일부분을 선택해서 처리를 하는걸까요? 

필터는 기능의 유연한 확장일까요? 


뭐에 더 가까울까요? 선택은 여러분의 몫입니다. 저는 결정했지만 말하지는 않겠습니다. 


p.s 

제 3의 패턴이다. 라고 말할수도있습니다.  이것 저것 생각해보는 시간을 갖으면  좋겠습니다.

Core J2EE Patterns: Intercepting Filter Pattern  :

http://www.informit.com/articles/article.aspx?p=1398619&seqNum=3





레퍼런스 :  실용주의 디자인 패턴 (http://www.kangcom.com/sub/view.asp?sku=200607180006 )




나중에 또 잊어버리는것을 방지하고자 ;; 시간날때마다 하나씩 정리해둡니다.


케이스 1. 스프링 플젝에서 설정을 외부로 빼기위해, 자바 프로퍼티 파일을 사용



- 위의 this 위치에 파일을 생성하여 봅니다.  src/main/resources  폴더는 스프링 프로젝트 만들면
  자동으로 생기더라구요

- 해당 프로젝트를 war 로 만들면 WEB-INF/classes/  폴더아래에 WMOSConfig.properties 파일이
  위치해 있군요. 

- 클래스 로더를 사용해서 파일을 가져오도록 해봅니다.


테스트)

       String config ="resources/WMOSConfig.properties"; <-- 이거 안됩니다. 아래처럼 경로를

String config = "WMOSConfig.properties";

ClassLoader currentThreadClassLoader = Thread.currentThread().getContextClassLoader();

URL url = ClassLoader.getSystemResource(config);   <--- 안됨

URL url2 = currentThreadClassLoader.getResource(config);  <---- 잘됨 


         Thread.currentThread().getContextClassLoader();  <-- 이렇게 얻어온 클래스로더만 작동합니다. 

         * 웹 애플리케이션은 웹 컨테이너 안에서 실행되며, 각각의 웹 어플리케이션은 자신의 클래스 로더를 가짐.
          위의 WEB-INF/classes/ 경로는 웹어플리케이션의 클래스로더가 인지함.

         

솔루션)

- WMOSConfig.properties 파일안의 내용

trams-ip = 127.0.0.1


- 파일 내용 읽어오기 

Properties prop = new Properties();

   ClassLoader cl;

cl = Thread.currentThread().getContextClassLoader();

URL url = cl.getResource("WMOSConfig.properties");

prop.load(url.openStream());

   String ip = prop.getProperty("trams-ip");

   System.out.println(ip);  <--- 127.0.0.1






케이스 2.    log4j 의 파일 appender 에서 로그파일 위치는?

    <!-- 날짜별 로그  -->

    <appender name="file" class="org.apache.log4j.DailyRollingFileAppender">

        <param name="file" value="D:/testlogs/dailyout.log"/>

         .....

    </appender>


이렇게 하면 당연히, D:/testlogs/ 폴더에 날짜별로 생겨납니다.

   

  <!-- 날짜별 로그  -->

    <appender name="file" class="org.apache.log4j.DailyRollingFileAppender">

        <param name="file" value="./testlogs/mytestlog.log"/>

         .....

    </appender>


어떻게 될까요?


저기에서 ./  는 WAS 시작된 위치가 현재 디렉토리입니다.  따라서 톰캣을 사용한다면 

Tomcat 7.0/testlogs / 폴더에 날짜별로 생겨납니다. 



결제 시스템의 역사 간단정리 해봅니다. 제가 아래링크를 보고 정리한것이라 틀린부분이 있을 가능성이 

있습니다. 염두하시고 편하게 쭈욱 살펴보시길 바랍니다.

(https://muluti.wordpress.com/2013/08/22/%EC%9C%A0%EB%AC%B4%EC%84%A0-%EA%B2%B0%EC%A0%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EA%B0%84%EB%9E%B5-%ED%9E%88%EC%8A%A4%ED%86%A0%EB%A6%AC/)


 년도

 기술

 관련 업체

 특징 

 기타 

 1996~1997

 Key-in 방식

 인터파크 론칭
 롯데닷컴 오픈 등

모든 정보를 사용자가 다 때려박아야함.보안 취약 

 모든정보란?

신용카드번호,유효기간,카드비번앞 2자리, 주민번호등 

 1997~2000

 -SSL,SET 같은 보안기법등장

- PG 는 은행/카드사등으로부터 결제대금을 지급받아 판매자에게 지급.


 - PG사 등장.

 -주요신용카드사와 시스템 개발사 공동투자로 최초 결제전문회사 탄생, KCP

- 98년에는 이니시스가 이니페이를 들고 뛰어듬.

 - 중소기업이 다 개발하기엔 무리 

-  중간에서 결제처리를 대행해
   주는 업체의 필요성

 

 2000년

 휴대폰 소액 결제 서비스

- 다날이 SKT 와 계약을 맺고 세계최초

- 뒤이어 모빌리언스 

 -신용카드 결제기반과 휴대폰
   결제기반 PG 시장이 열림 

 

 2003~2004 

 - 안전결제 (ISP) - PKI 기반
   전자서명방식

 - 안심결제(안심클릭) 

 - ISP 는  국민카드/BC 카드가 시행. BC카드 자회사인 브이피에서 개발.


- 안심결제는 그에 대응하며 삼성/엘지/현대/신한/롯데/외환카드 주도로 도입 (VISA 에서 개발한 기술) 


- 더욱 안정성 있는 결제 시스템
   도입필요
 

- ISP 는 신용정보 일체 입력하지
  않고 비밀번호만 입력하는 방식으   로 정보를 최소한 입력


- 안심클릭은 카드번호,인심클릭비   밀번호,CVC 코드로 최소화

 ISP와 안심클릭이 2004년 2월 전면 의무화

 2009~2011 

 

 - SKT 가 하나카드 인수

 - KT 가 BC 카드 인수 

- 금융과 통신의 융합을 통해 시장 주도권을 노린 측면도 있겠지만 

- 기존에 통신사에서 진행한 마케팅 활동에서 가맹점, 제휴사, 포인트, 리워드, 할인 등 카드사와 영역이 겹치는 부분이 많았기 때문으로 보인다.

- 카드사 결제수단과 가맹점 네트워크가 통신사의 인프라와 결합됐을 때, 파급력이 상당할 수 있기 때문이다. 고객관점에선 통신사의 멤버십 혜택과 신용카드 혜택이 긴밀히 결합되는 효과로 나타났다.

 통신사의 카드사 인수 /

스마트폰 대중화

 2010~ 2011

 - 스마트폰용 USIM 기반 모바일 카드 출시


모바일 쇼핑몰에선 하나SK카드는 모바일 카드 전용 간편결제앱(통합 안심클릭앱)을 구동하여 결제 비밀번호로 결제한다

BC카드의 경우는 모바일ISP앱을 구동한 후 [모바일 카드 결제]를 누르고 미리 설정한 비밀번호를 눌러 결제를 완료

KB 모바일 카드는 PG화면에서 [모바일 카드 결제] 선택 후 휴대폰 번호를 입력하여 URL SMS를 받는다. URL 접속하면 구글마켓의 모바일 ISP 앱소개 페이지가 뜨는데, 거기에서 [열기]버튼을 눌러 앱을 구동후 비밀번호 입력하여 결제하는 방식이다.

 - 2010년 3월 하나SK카드에서 ‘하나SK 터치세븐’을 출시


- BC 카드도 2011년 업턴
  카드로 뛰어듬


- 신한카드도 USIM 모바일
  카드 경쟁에 뛰어듬 


        3파전 

 - 카드를 신청하면 플라스틱 카드와 핸드폰 USIM 칩에 다운로드 되는 모바일 카드가 동시에 발급된다.

 *모바일 카드는 지난 2002년 모네타카드부터 2008년 피처폰 기반의 USIM 뱅킹까지 다양한 시도가 있었으나 단말과 네트워크, 가맹점 확보 등의 문제로 활성화되지 못했음.

 2011 

 카드사별 간편결제 서비스
 출시 

 - 2010년 12월 3일 삼성카드가 국내최초로 간편결제를 도입

신세계몰이나 이마트몰에서 (최초 1회 카드등록한 후) 카드 정보 입력없이 SMS 인증만으로 결제가 가능

- 2011년 5월에 신한카드가 결제ID 기반의 스마트결제를 출시


-쇼핑몰에 결제창을 제공하는 PG 역시 자체 간편결제를 제공하는데, 신한카드와 하나SK카드의 간편결제는 이니시스의 간편결제 방식을 따른 것으로 보인다.

 간편결제는 미리 등록 해놓은 신용카드 정보를 바탕으로 아이디와 패스워드만으로 온라인 결제가 가능한 방식을 의미한다

 페이팔이 바로 이 모델

 2011~2012

 2011년 12월 8일 신세계몰에서 업계 최초로 앱기반의 모바일 간편 결제 서비스를 출시한다고..서비스명은 유비페이



 - 이 서비스는 모바일 쇼핑몰에서 결제시 앱을 구동시키고 결제비밀번호만 입력하면 결제 완료되는 방식이다. 최초 한 번만 자신이 보유한 신용카드나 계좌를 등록하고 결제비번을 설정하면 된다. 신한카드, KB국민카드, 현대카드, BC카드가 제휴에 참여했다.


얼마 지나지 않아 하나SK카드에서도 앱구동 후 비밀번호 입력하는 방식의 스마트페이를 출시


-휴대폰 청구기반 PG사업자인 모빌리언스와 다날은 새로운 환경 변화에 따른 새로운 결제 솔루션으로 준비하고 있었다. 바로 오프라인에서 휴대폰 후불 결제를 간편하게 할 수 있 수 있는 바코드 결제 서비스

 앱기반의 간편결제 등장 & 오프라인 바코드 결제 서비스 출시

 

 2012

 -SKT에서 분사한 SK플래닛은 당해 5월 페이핀이라는 서비스를 내 놓는다. 



  - 서비스 방식은 기존의 유비페이나 하나SK 스마트페이와 크게 다르지 않다. 유무선 쇼핑몰에서 페이핀 결제를 선택한 후, 결제버튼을 누르면 앱이 구동되고 거기에 비밀번호만 입력하면 끝이다. 

- 스마트 결제에서 이보다 더 간결한 결제 플로우는 없을 것이다. BC카드, 하나SK카드, 신한카드를 등록할 수 있고, 휴대폰 후불결제는 물론 체크카드, 모바일 카드도 등록할 수 있다.


 통신사의 스마트 결제 시장 
 본격진출 

 


2013  

-신용카드사의 야심작, 앱카드 등장




앱카드는 기존의 USIM 방식과 달리 일반 플라스틱 카드를 앱에 등록하고 결제시 비밀번호만 입력하면 된다

 결제시장에서 통신사 주도의 스마트 결제 서비스가 등장하면서 신용카드사의 고민이 깊어졌다

 자칫 주도권을 잃지 않을까 우려하는 것이다. 다양한 사업자들이 구축한 결제 플랫폼에 카드사 역시 참여하고 있으나 플랫폼에 입점한 것이지 사업의 주체라고 보긴 힘들었다. 무엇보다 카드매출에 따라 일정의 수수료를 내야하는 모델로 자존심이 강한 금융사 입장에선 달갑지 않은 부분이다

-카드사 입장에선 라이선스 비용이나 플랫폼 비용을 지불하지 않고 독립적인 결제모델을 만들기 위해서 모바일 카드에 대한 자체 규격이 필요했다. 이에 신한/국민/현대/삼성/농협/롯데카드가 공동으로 규격을 개발하게 된다. 이것이 바로 앱카드다.

 5월 1일 신한카드가 최초로 앱카드를 출시한 것을 시작으로 8월 19일에 롯데 앱카드도 오픈을 했다. 2013년 3분기 내에 나머지 4곳도 앱카드 출시가 차례로 이어질 것이다.

 

 2015 

 -뱅크월렛 카카오

 -토스등 핀테크 스타트업

 - 토스는 받는 사람 전화번호와 보낼 금액, 암호 등 3단계만 입력하면 수초만에 송금할 수 있는 앱이다. 쇼핑몰에서 물건을 살 때나 공과금을 납부하는 등 가상계좌를 이용한 무통장입금을 할 때도 유용하게 쓸 수 있다.

-뱅크월렛카카오과는 달리 돈을 받는 사람은 토스 앱을 설치하지 않아도 된다. 송금 즉시 이체가 완료돼 영업일을 기다릴 필요가 없다.

 간단하게 토스 송금 시스템의 원리를 살펴볼까요? 유니세프 등에 자동이체 기부를 해본 사람에게는 굉장히 익숙한 방식입니다. 

-사회단체의 기부금 자동이체 시스템이 토스의 방식과 유사하기 때문입니다. 이 방식을 보통 금융업계에서는 CMS(Cash Management System)라고 합니다. 일단 토스 앱을 사용해서 누군가에게 송금하면 CMS가 본인이 지정한 계좌에서 자동으로 돈을 인출한 후,토스와 협력한 은행 계좌에 자동 입금합니다. 해당 은행은 그 돈을 다시 상대 계좌에 입금합니다. 참 쉽죠?

-사실상 CMS를 통해 모든 금융 거래를 진행하는 것이기 때문에 돈을 받는 사람은 토스 앱을 따로 설치할 필요가 없으며, 공인인증서, 보안카드, Active X와 씨름할 필요도 없어집니다. 게다가 상대방의 계좌 번호를 몰라도 전화번호를 선택 후 문자메시지를 통해 송금할 수도 있습니다. 

 

 미래 

 

 

 

 


물루티 리포트 란곳에서 써여진 좋은글이라 퍼왔습니다.  문제가 있으면 알려주길 바랍니다.


관련 링크( 핀테크 관련 흥미로운 읽을거리):


유무선 결제서비스의 발전과정과 전망

결제서비스만큼 복잡하고 긴 역사를 가진 서비스도 잘 없다. 인터넷이 대중화되면서 PC웹을 통한 온라인 결제가 대중화됐고, ISP/안심클릭으로, 다시 간편결제로 발전해 왔다. 휴대폰 기술이 발달하면서 USIM기반의 모바일카드가 나왔고, 스마트폰의 등장으로 앱기반의 결제서비스가 만들어졌다. 지금은 결제기능이 스마트월렛과 결합되거나 온오프라인에서 비밀번호 한번으로 손쉽게 결제 가능한 통합형 결제서비스가 각광을 받고 있다. 내가 아는 선에서 결제서비스의 역사를 주욱 훑어 본다. 뭘 연구하듯쓴 글이 아니기 때문에 작성된 내용에 일부 착오가 있을 수 있으며 주로 신용카드 결제 위주로 정리하여 뱅킹서비스나 스마트월렛 등에 대해선 다루지 않았음을 밝힌다.

payhistory

▶ 1996년 ~ 1997년, 온라인 쇼핑몰의 태동기

1996년 6월 1일 국내 최초의 인터넷 쇼핑몰 인터파크가 론칭했다. 그리고 같은 해 롯데닷컴이 오픈, 97년에 신세계 백화점 쇼핑몰, e현대, 한솔 CS클럽이 연이어 문을 열었다.

당시 쇼핑몰에서 결제하는 방식은 Key-in 방식이다. 신용카드번호, 유효기간, 카드비번 앞 2자리, 주민번호 뒷 7자리까지 모두 입력해야 결제가 가능했다. 문제는 보안이 매우 취약했다는 점. 96년 당시에만 하더라도 별다른 보안 솔루션 없이 당시 주류 브라우저였던 넷스케이프의 보안기능에 의존하는 수준이었다.

▶ 1997년 ~ 2000년 초반, PG사의 등장

온라인 쇼핑몰이 우후죽순 생겨나기 시작하면서 안정적인 결제시스템이 요구됐다. SSL, SET과 같은 보안기법이 등장했으나 중소규모의 쇼핑몰이 보안기술 기반의 결제시스템을 갖추는 것은 무리였다. 이에 주요 신용카드사와 시스템 개발사에서 공동투자하여 국내 최초의 결제 전문 회사를 만들게 된다. 이 회사가 KCP다. 이 외에도 커머스넷코리아(CNK)라는 연합체가 전자상거래 시스템과 결제솔루션 분야에 뛰어들었고, 98년도엔 이니시스가 이니페이라는 결제 솔루션을 들고 본격적인 PG사업을 펼친다.

PG의 역할은 전자지불 대행이다. 전자상거래에서 PG업체가 지급결제처리를 위한 대행계약을 맺고 구매자가 선택한 은행, 신용카드사, 통신사업자 등으로부터 결제대금을 지급받아 일정 수수료를 공제하고 판매자에게 지급하는 역할을 수행한다. 이 모든 과정은 보안성과 안정성이 확보된 결제시스템 내에서 이뤄진다. 만약, PG가 없다면 각 쇼핑몰에서는 높은 비용으로 결제시스템을 구축해야하는 것은 물론 최소 7군데 이상의 금융사업자들과 일일이 계약을 맺어야 한다.

▶ 2000년 , 휴대폰 결제 서비스 등장

인터넷 거래량은 폭발적으로 늘어가는데, 기존의 신용카드 결제는 소액상품 결제나 디지털 콘텐츠 구매에는 맞지 않았다. 2000년에 들어서 휴대폰 요금에 합산되어 후불로 청구되는 서비스가 탄생했다. 휴대폰 소액결제 서비스였다. 다날이 SKT와 계약을 맺고 세계 최초로 휴대폰 결제 서비스를 주도했다. 뒤이어 인포허브, 모빌리언스도 유사서비스를 내놓았다. 신용카드 결제 기반 PG사업과 함께 휴대폰 결제 기반의 PG시장이 열렸다.

휴대폰 결제는 전화번호와 주민번호 뒷자리를 입력하면 SMS로 인증번호가 도착하고 이것을 입력창에 넣는 방식이다.

▶ 2003 ~ 2004년 , 안전결제(ISP)와 안심결제(안심클릭) 등장

인터넷 결제시장이 계속 확대되면서 더욱 안정성 있는 카드결제 시스템의 도입이 필요해 졌다. PG 시스템을 통해 보안유지가 된다고 해도 불법적인 해킹시도가 끊이지 않았다. 실제 카드사고도 발생했다.

이에 국민카드와 BC카드는 2003년 10월 보안성이 강화된 인터넷 안전결제 서비스를 시행한다고 밝혔다. ISP라고 불리는 이 결제방식은 인터넷에서 신용카드로 결제할 때 카드번호, 유효기한, 비밀번호 등의 개인 신용정보를 입력하지 않고, 영숫자가 포함된 6-14자리 비밀번호만으로 거래 하는 방식이다.

ISP는 BC카드의 자회사인 브이피라는 국내업체가 개발했다. PKI기반 전자서명방식을 적용하였고, RSA 및 SEED 등 고도의 암호화 기술을 채택했다. 이 방식은 금새 모든 쇼핑몰에 적용된다.

삼성/엘지/현대/신한/롯데/외환카드는 2004년 2월에 안심결제(안심클릭) 서비스를 도입한다. 국내업체가 아닌 VISA에서 개발하여 국제 규격을 지원하고 SSL, 3D Secure 기술이 적용됐다. ISP방식과는 달리 고객인증과 거래승인을 분리하여 고객 정보 유출을 최소화했다. 이용방법은 온라인 결제시 각 카드사의 안심클릭 페이지가 나타나면, 카드번호, 안심클릭 비밀번호, CVC 코드를 입력하여 결제하는 방식이다. 

ISP와 안심클릭이 2004년 2월 전면 의무화되면서 국내 모든 인터넷 쇼핑몰은 이 두가지 결제방식으로 통일되게 된다. 아울러 10만원 이상 결제시 공인인증서 인증도 의무사항이 되었다. (2005년 11월에 30만원 이상으로 상향)

▶ 2009년 ~ 2011년 , 통신사의 카드사 인수

한편, 카드사의 경쟁구도에 중요한 지각변동이 나타나게 된다. 통신사가 카드사의 인수를 추진한 것. 2009년 12월에 SKT가 하나카드를 전격 인수함으로 하나SK카드가 출범하게 된다. 이는 같은 통신사인 KT를 자극하여, KT 역시 2011년 2월에 BC카드를 인수하게 된다.

통신사의 카드사 인수는 금융과 통신의 융합을 통해 시장 주도권을 노린 측면도 있겠지만 기존에 통신사에서 진행한 마케팅 활동에서 가맹점, 제휴사, 포인트, 리워드, 할인 등 카드사와 영역이 겹치는 부분이 많았기 때문으로 보인다. 카드사 결제수단과 가맹점 네트워크가 통신사의 인프라와 결합됐을 때, 파급력이 상당할 수 있기 때문이다. 고객관점에선 통신사의 멤버십 혜택과 신용카드 혜택이 긴밀히 결합되는 효과로 나타났다.

2011년을 기점으로 스마트폰 대중화
각 신용카드사별 모바일 시장동향에 대응하고 주도권을 잡기 위한 전문 부서 신설

▶ 2010년 ~ 2011년 , 스마트폰용 USIM 기반 모바일 카드 출시

*모바일 카드는 지난 2002년 모네타카드부터 2008년 피처폰 기반의 USIM 뱅킹까지 다양한 시도가 있었으나 단말과 네트워크, 가맹점 확보 등의 문제로 활성화되지 못했음.

2010년 3월 하나SK카드에서 ‘하나SK 터치세븐’을 출시하면서 본격적인 모바일 카드의 시작을 알렸다. 이 카드를 신청하면 플라스틱 카드와 핸드폰 USIM 칩에 다운로드 되는 모바일 카드가 동시에 발급된다. SKT와 합병 이후 첫 작품으로 T멤버십, T멤버십캐쉬백, OK캐쉬백 등의 포인트 기능이 카드에 통합돼 있었다. BC카드 역시 2011년 업턴카드를 필두로 다양한 모바일 카드를 내놓고 있으며 신한카드도 USIM 기반 모바일 카드 경쟁에 뛰어들면서 사실상 3파전이 시작됐다.

모바일 카드를 이용하려면 반드시 연결된 플라스틱 카드가 먼저 있어야 한다. 모바일 카드 앱을 다운 받아 설치하고(이 과정에서 USIM을 콘트롤하는 앱이 하나 더 설치) 카드사 홈피나 서비스 앱에서 발급신청을 한다. 약관동의 절차를 거쳐 신청을 완료하면, 발급안내 SMS가 도착한다. 그 후 최종적으로 발급절차를 마무리하면 사용가능하다.

모바일 카드로 결제를 하려면 오프라인에선 NFC가 켜진 상태에서 전용 동글에 갖다 대기만하면 된다. 모바일 쇼핑몰에선 하나SK카드는 모바일 카드 전용 간편결제앱(통합 안심클릭앱)을 구동하여 결제 비밀번호로 결제한다. BC카드의 경우는 모바일ISP앱을 구동한 후 [모바일 카드 결제]를 누르고 미리 설정한 비밀번호를 눌러 결제를 완료한다. 온라인 쇼핑몰에서는 하나SK카드는 모바일 카드 결제를 지원하지 않는 것으로 파악이 된다. KB 모바일 카드는 PG화면에서 [모바일 카드 결제] 선택 후 휴대폰 번호를 입력하여 URL SMS를 받는다. URL 접속하면 구글마켓의 모바일 ISP 앱소개 페이지가 뜨는데, 거기에서 [열기]버튼을 눌러 앱을 구동후 비밀번호 입력하여 결제하는 방식이다.

▶ 2011년 , 카드사별 간편결제 서비스 출시

스마트폰 열풍 이후 주요 카드사를 중심으로 모바일카드에 대한 관심이 높아진 가운데 유무선 결제에서 카드번호를 일일이 입력해야 했던 기존의 안심결제가 아닌 더 편리한 방식의 카드결제 방식이 주목받기 시작했다. 이른바 간편결제 서비스다.

간편결제는 미리 등록 해놓은 신용카드 정보를 바탕으로 아이디와 패스워드만으로 온라인 결제가 가능한 방식을 의미한다. 해외에선 이미 대중화된 페이팔이 바로 이 모델이다. 우리나라에선 카드사별 결제ID로 하는 방식도 있고, SMS 인증으로 하는 경우도 있다.

2010년 12월 3일 삼성카드가 국내최초로 간편결제를 도입했다. 신세계몰이나 이마트몰에서 (최초 1회 카드등록한 후) 카드 정보 입력없이 SMS 인증만으로 결제가 가능했다. 이후 2011년 5월에 신한카드가 결제ID 기반의 스마트결제를 출시, 같은해 6월에 롯데카드 간편결제, 9월에 현대카드 간편결제가 이어서 나오게 된다.

쇼핑몰에 결제창을 제공하는 PG 역시 자체 간편결제를 제공하는데, 신한카드와 하나SK카드의 간편결제는 이니시스의 간편결제 방식을 따른 것으로 보인다.

▶ 2011년 ~ 2012년 , 앱기반의 간편결제 등장 & 오프라인 바코드 결제 서비스 출시

간편결제로 결제편의성이 강조되고 스마트폰이 급속도로 확산되면서 앱기반으로 간편하게 유무선 결제를 할 수 있는 방안에 관심이 쏠리게 된다.

2011년 12월 8일 신세계몰에서 업계 최초로 앱기반의 모바일 간편 결제 서비스를 출시한다고 밝혔다. 솔루션을 제공한 업체는 하렉스 인포텍. 서비스명은 유비페이였다. 이 서비스는 모바일 쇼핑몰에서 결제시 앱을 구동시키고 결제비밀번호만 입력하면 결제 완료되는 방식이다. 최초 한 번만 자신이 보유한 신용카드나 계좌를 등록하고 결제비번을 설정하면 된다. 신한카드, KB국민카드, 현대카드, BC카드가 제휴에 참여했다.

얼마 지나지 않아 하나SK카드에서도 앱구동 후 비밀번호 입력하는 방식의 스마트페이를 출시한다. 바야흐로 앱기반 스마트 결제 서비스의 치열한 경쟁이 시작된 것이다.

한편, 휴대폰 청구기반 PG사업자인 모빌리언스와 다날은 새로운 환경 변화에 따른 새로운 결제 솔루션으로 준비하고 있었다. 바로 오프라인에서 휴대폰 후불 결제를 간편하게 할 수 있 수 있는 바코드 결제 서비스가 그것이다. 2011년 4월 모빌리언스의 엠틱이 먼저 출시되고 3개월 뒤 다날에서 바통을 내놓았다.

서비스는 단순하다. 편의점이나 등록된 가맹점에 가서 앱을 실행한 후, 결제버튼을 누르면 매번 새로운 결제용 바코드가 일정 시간 노출된다. 그것을 가맹점 POS에서 결제 금액을 입력 후 바코드 리더기로 읽으면 결제가 완료되는 방식이다. 앱을 구동할 때 미리 설정한 비밀번호를 넣는 것으로 부정사용을 방지한다.

이 서비스는 그 동안 오프라인 결제는 NFC의 모바일 카드가  대세라는 세간의 인식을 바꾸는 데 일조한다. 별도의 동글이 필요한 NFC가 아니더라도 기존 가맹점 POS를 활용하여 보다 쉽게 오프라인 결제를 지원할 수 있는 것이다.

▶ 2012년 , 통신사의 스마트 결제시장 본격진출

2012년에는 통신사가 본격적으로 모바일 결제 영역에 뛰어든다. SKT에서 분사한 SK플래닛은 당해 5월 페이핀이라는 서비스를 내 놓는다. 서비스 방식은 기존의 유비페이나 하나SK 스마트페이와 크게 다르지 않다. 유무선 쇼핑몰에서 페이핀 결제를 선택한 후, 결제버튼을 누르면 앱이 구동되고 거기에 비밀번호만 입력하면 끝이다. 스마트 결제에서 이보다 더 간결한 결제 플로우는 없을 것이다. BC카드, 하나SK카드, 신한카드를 등록할 수 있고, 휴대폰 후불결제는 물론 체크카드, 모바일 카드도 등록할 수 있다.

이후 KT에서 12월에 시장을 주도할 또다른 결제 서비스를 발표한다. 모카페이였다. 모카페이는 당시에 가장 발전된 스마트 결제 서비스를 보여줬다. 기존의 유비페이 서비스를 KT가 통합하여 재런칭하였는데, KT 수뇌부의 강한 의지가 반영된 프로젝트였다.

모카페이는 유무선 결제는 물론 NFC, 바코드, QR코드를 활용해 오프라인 결제까지 지원했다. 또 오픈 결제 플랫폼으로 신용카드 뿐만 아니라 체크카드, 직불계좌, 선불카드, 교통카드, 상품권 등 다양한 결제 수단을 담을 수 있다. 지원하는 카드는 신한카드, BC카드, KB국민카드, JB전북카드, 하나SK카드 5종이며 9 곳의 주요 은행계좌가 등록가능하다.

주목할 점은 모카페이 인프라 확장을 위해 모카얼라이언스라는 이름의 별도 연합체를 구성한 것이다. 주요 금융사와 유통업체를 모카페이 중심으로 이어가고 있다. 내부 결속력이 어떤지는 알 수 없으나 사업을 장기적 관점에서 펼치려는 노력은 엿보인다.

▶ 2013년 , 신용카드사의 야심작, 앱카드 등장

결제시장에서 통신사 주도의 스마트 결제 서비스가 등장하면서 신용카드사의 고민이 깊어졌다. 자칫 주도권을 잃지 않을까 우려하는 것이다. 다양한 사업자들이 구축한 결제 플랫폼에 카드사 역시 참여하고 있으나 플랫폼에 입점한 것이지 사업의 주체라고 보긴 힘들었다. 무엇보다 카드매출에 따라 일정의 수수료를 내야하는 모델로 자존심이 강한 금융사 입장에선 달갑지 않은 부분이다.

카드사 입장에선 라이선스 비용이나 플랫폼 비용을 지불하지 않고 독립적인 결제모델을 만들기 위해서 모바일 카드에 대한 자체 규격이 필요했다. 이에 신한/국민/현대/삼성/농협/롯데카드가 공동으로 규격을 개발하게 된다. 이것이 바로 앱카드다.

앱카드는 기존의 USIM 방식과 달리 일반 플라스틱 카드를 앱에 등록하고 결제시 비밀번호만 입력하면 된다. 별도의 신청과정이나 발급앱의 설치가 필요없다. USIM형 모바일 카드처럼 유무선은 물론 오프라인에서도 결제가 가능하다. OTC라는 일회용 코드를 NFC, QR, 바코드 형태로 출력하면 가맹점 POS에서 인식하여 결제가 이뤄진다. 시스템적으로는 다르지만 이용자 입장에선 기존의 모카페이와 사용법은 동일하다.

5월 1일 신한카드가 최초로 앱카드를 출시한 것을 시작으로 8월 19일에 롯데 앱카드도 오픈을 했다. 2013년 3분기 내에 나머지 4곳도 앱카드 출시가 차례로 이어질 것이다.

 스마트 결제 시장의 관전 포인트  

개인적으로 현재 시장의 흐름을 춘추 전국 시대에서 시장의 질서가 확립되는 시기로 판단한다. 내년이나 늦어도 2015년 정도면 스마트 결제서비스의 방식이 표준화되고 통합적인 결제 플랫폼이 등장할 것으로 기대된다. 그 간에 어떤 일들이 발생할까. 몇가지 관전 포인트를 잡아보았다.

  • USIM기반 모바일 카드 VS 앱카드
    내 생각에는 앱카드의 승리로 판가름 날 것 같다. 결제 인프라의 문제 때문이다. 6개 카드사가 공동으로 추진하는 앱카드는 기존 가맹점 인프라를 공동으로 활용한다. 사용처의 차이가 승부를 가를 것이다. 특히 6개 카드사가 공동으로 앱카드 마케팅을 진행할 경우 점유률을 높이는 것은 시간문제다. (금융앱의 다운로드/사용횟수는 할인 프로모션에 의해 좌지우지 된다. 중요한 건 설치이후 사용자를 습관화시키는 것이지만..)
  • 주요 카드사들이 모카페이/페이핀 플랫폼에 올라탈까?
    모바일 카드 역시 페이핀 같은 스마트 결제 서비스에 등록 가능하기 때문에 사실상 결제 서비스는 통신사의 스마트 결제 서비스 VS 카드사 앱카드 구도로 나뉜다. 문제는 모두 카드사의 참여가 필수라는 점이다. 통신사의 그룹사가 된 하나SK카드와 BC카드는 어쩔 수 없다 해도, 신한카드를 비롯한 주요 카드사가 통신사 주도의 결제 서비스인 모카페이/페이핀에서 언제까지 제휴를 이어갈 지 궁금하다. 그리고 핵심 카드사를 확보하기 위한 모카페이/페이핀의 미끼는 무엇일까?
  • 피 튀기는 특허싸움을 어떻게 피할 것인가?
    결제영역에서 신규 서비스를 만들어내기 어려운 이유 중 하나는 특허 때문이다. 오래 전부터 결제관련 사업을 진행했던 업체들은 결제 프로세스 하나하나에 다 특허를 걸어놨다. 보통 수십개에서 수백개의 관련 특허를 보유하고 있는 곳도 있다. 뭐든 안 걸리는 것이 없다. 경쟁사를 압박하기 위해 계속 특허관련 분쟁이 있을 것이고 이 때문에 서비스 플로우가 기형적인 것들도 나올 것이다. 대승적으로 풀렸으면 하는 부분이다.
  • 스마트월렛이 다시 주목 받을 수 있을까?
    결제플랫폼에 서비스를 얹으면 그것이 스마트월렛이다. 현재 서비스 중인 스마트월렛은 멤버십 관리 서비스로 고착된 상태다. (2013년 5월에 신한 스마트월렛은 자사 앱카드와 연동하여 결제와 서비스가 통합된 모델 선보임) 애초에 결제에 대한 대안 없이 서비스가 만들어지다 보니 이용자가 가치가 멤버십, 쿠폰에 한정됐다. 그러다 보니 스마트월렛이라는 사업모델이 반쪽짜리가 되어 시장에서 제대로 평가 받을 기회가 없었다. 스마트 결제 서비스나 앱카드가 활성화 된 이후엔 어떤 형태로든 스마트월렛이 다시 주목 받게 될 것이다. 과연 시장에 파급력을 가질 수 있을지 궁금하다.
  • 누가 가장 먼저 완벽한 사용자 경험(One transaction)을 선보일 것인가?
    이용자 관점에서 보면 자동으로 나에게 가장 유리한 결제방식을 제시해주고, 결제 버튼만 누르면 알아서 신용카드, 쿠폰, 멤버십, 스탬프, 포인트 결제가 한꺼번에 처리되는 것이 가장 환상적인 사용자 가치다. 아직 어디에도 이 수준의 서비스가 등장하지 않았다. 모두가 아는 정답이지만 아무도 쉽게 해내지 못하고 있다.
  • 과연 구글발 임팩트가 다시 있을까?
    스마트월렛이라는 화두를 이끌었던 구글월렛은 시장에서 실패했다. 그러나 그것이 끝은 아니다. 새로운 구글월렛이 조만간 다시 등장할 것이다. 지금까지와는 다른 발상의 결제서비스가 국내에도 영향을 줄 수 있다. 구글월렛의 시장점유를 말하는 것이 아니라 혁신적인 서비스 모델이 주는 충격파 말이다. 이것 역시 참으로 기대되는 대목이다.


'뱅킹 & PG' 카테고리의 다른 글

CMS 란? ( cash management service)  (0) 2016.12.05
VAN 과 PG 차이  (0) 2016.09.21
결제 시스템의 역사 간단정리  (0) 2015.08.07
이니시스 모바일 웹 뱅킹 시스템 개발 경험  (0) 2015.08.06

이번에 모바일웹에서의  결제 기능을  이니시스 제품으로  개발하던중..(신용카드 전용)

몇몇의 문제가  생겼다. 


* 새창이 뜨는 행동

* 이니시스 페이지에서 멈춰있는 행동

* 결재 자체가 안되는 행동 

* 한글이 깨지는 행동 (이니시스랑 상관없는 내 실수 :http://hamait.tistory.com/355


몇몇 은행 (안심결제?)은  2트랜잭션으로 하고, 안전결제(ISP) 를 사용하는  몇몇은 1트랜잭션이라는  

메뉴얼 보고 했는데 ,결국 모든 신용카드 결재는 2트랜잭션으로 가더라~

문의해보니 아직 메뉴얼중에 일부분이 업데이트가 안되고 있다고 한다.

현재  2015 년 8월 5일 이며, 이니시스로 작업하시는 분들은 몇몇 기술적인 부분을  이니시스에 확인해봐

야겠다. 메뉴얼 부분은 좀 실망스러웠지만  참고로 이니시스의 문제 대응은 신속하고 친절하더라~ 

(메일로 문의하라)


PS.

참고로 모바일 ISP 시스템을 만든 회사의 지분 구조는  비씨카드/ 국민은행 / 이니시스라고 한다.... 

안심결제 및 ISP 의 히스토리는 아래 링크를 통해 살펴보면 된다.

https://muluti.wordpress.com/2013/08/22/%EC%9C%A0%EB%AC%B4%EC%84%A0-%EA%B2%B0%EC%A0%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EA%B0%84%EB%9E%B5-%ED%9E%88%EC%8A%A4%ED%86%A0%EB%A6%AC/


'뱅킹 & PG' 카테고리의 다른 글

CMS 란? ( cash management service)  (0) 2016.12.05
VAN 과 PG 차이  (0) 2016.09.21
결제 시스템의 역사 간단정리  (0) 2015.08.07
유무선 결제서비스의 발전과정과 전망 (펌)  (0) 2015.08.06

+ Recent posts