Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

그러나 계속 어렵다고 하여 확인해 본 결과, 업체는 C++(Server) 과 Java(Client) 로 SSL 을 직접 붙여서 library를 사용하여 전용 Protocol 을 가진 Client/Server 를 만들고 있었다. 그러니 당연히 어려운거고 힘들다고 투덜거렸던 거였다.

만약 HTTPS 를 사용한다면 서버는 apache httpd 를 httpd나 tomcat등을 사용하고 client 는 Java면 Java 라면 Commons Http Client,  C/C++ 이면 libcurl 을 사용하고 모바일 app 환경이라면 프레임웍이 제공하는 라이브러리를 사용한다면 안전한 데이타 송수신 환경 구축은 끝이고

비즈니스 로직에만 집중해야 하는데 집중할수 있는데 C/S 기반으로 방향을 잡아서 SSL C/S  를  자체를 만드는데 상당한 시간을 쏟아 부은 것이다. 

 

사실 직접 서버를 만들어도 만들면 apache httpd 보다 성능이 뛰어나거나 안정적이고 유연할 수는 절대 없을 것이다.

비록 그간 투자한 시간이 아깝다지만 나온 아깝겠지만 나올 결과물을 비교해 예상해 보면 좋은 경험했다치고 C/S 구현 업무를 중단하고 기존 솔루션을 쓰는게 더 나은 선택일 것 같긴 하지만 프로젝트가 어느 정도 진행되면 서로 부담되서 진행방향을 바꾸지는 못할 것이다.바꾸기는 쉽지 않긴 하다. 

 

구현 업체가 직접 C/S 를 만들게된 이유는 단 하나. 고객이 해당 서비스가 모바일 앱에서만 보이게 해 달라는 요구사항이 있었다고 한다. 저정도 요구사항이면 사내에서만 쓰는 전용 단말이라면  단말의 IP 대역을 받아서 IP로 거르거나 Browser 의 User-Agent 로 거르거나, 초기 화면부터 인증을 거쳐야 보이게하거나 등등 여러가지 방법이 있을 것 같은데 요구사항을 그대로 해석하는 바람에 서로 피곤해 질 결과가 나올것만 같다.