폐쇄망에서 K사 로그인API 적용 후기

폐쇄망에서 개발은 정말 신경 써야 할 것이 많다. 그중에 대외 시스템과 연계하는 개발은 더더욱 신경 쓸 것이 많다. 이번에는 F 생명보험사의 K사 로그인 방식을 도입하기 위해 시행착오를 겪었던 후기를 올린다.

 

절차는 다음과 같았다.

1. K사의 개발 가이드문서 및 샘플 소스를 받는다.
2. 인프라 팀과 협의하여 대외망으로 연결할 IP 및 도메인 이름을 정의하여 K사에 전달한다. 
3. K사는 해당 IP를 서비스에 등록하여 테스트를 진행할 수 있도록 한다.
4. 내부 서버와 대외망으로 연결할 수 있는 IP를 연결한다.
5. 샘플 소스를 기반으로 테스트 데이터를 API 요청을 보낸다.
6. 정상적으로 데이터가 응답되는지 확인한다.

간단해 보이는 절차지만, 전체 흐름을 개발자가 혼자 통제하는 것이 아니기 때문에 과정마다 신경 써야 할 곳이 많다. 인프라의 문제인지 확인하는 것부터 제공받은 소스코드는 정상인지, 혹은 개발환경과 호환이 안 되는 것은 아닌지, 정보보안팀의 규칙에 위배되는 행동은 없는지 사소한 것 하나까지 신경이 써진다.

 

이번 로그인은 특히 세 가지 방향에서 문제가 있었다.

첫 번째는 인프라 였다. 아무리 요청을 보내도 응답이 오지 않고 Time out이 발생했다. K사에 확인을 요청했더니 네트워크 핸드 셰이크 중 Sync가 정상적으로 들어와서 K사가 다시 Sync/Ack를 보냈는데 F사에서 Ack가 돌아오지 않아 Timeout이 발생했다는 것이었다. 처음에는 절대 우리 문제가 아니라던 인프라팀도 증거를 들고 찾아가서 자세히 봐달라고 하니깐 그때서야 보안시스템에 예외 등록을 하지 않아서 그렇다고 실토하는 것이었다.(SI 개발을 하다 보면 이런 경우가 흔하다)

 

두 번째는 WAS의 Encoding 방식이었다. F사는 WAS로 웹로직을 사용한다. 하지만 개발환경을 수월하게 맞추기 위해 로컬 개발 시에는 톰캣을 WAS로 사용하고 개발서버에서는 웹로직을 사용하도록 했다. 이게 어떤 문제냐면 톰캣은 Encoding을 UTF-8로 맞혀놨는데 웹로직은 EUC-KR이 기본 설정이었다.

따라서 개발서버를 Putty로 접속하여 CURL을 날리면 API가 잘 동작하는데 애플리케이션으로 API를 호출하면 파라미터 인코딩이 변경되어 통신에 실패하는 것이었다. 이 문제도 데이터를 직접 비교하기 전까지는 찾아내기 쉽지 않았다.

 

마지막으로 샘플 소스의 버전과 개발환경의 버전이 호환이 안됐다. SSL 인증 정보를 TrustManager 인터페이스의 익명 클래스 구현을 통해 확인하는 샘플이 있었다. 문제는 이 소스가 컴파일에서도 오류가 안 나고 런타임에서도 오류가 안 나는데 꼭 개발서버에서 테스트를 하면 오류를 발생시키는 것이다.

처음에는 의존성 간 충돌이 일어나서 그런가 싶어서 동일한 클래스를 호출하는 jar들의 의존성을 제외시켜나갔는데 결국에는 샘플 소스에서 import 하는 인터페이스는 F사 개발환경에서는 호환이 안되어 다른 라이브러리의 인터페이스를 사용하여 문제를 해결했다.

 

이렇게 말도 많고 탈도 많았던 로그인 개발이 현재도 진행 중이다. 아마 통합 테스트 기간까지는 계속 끌어안아야 할 아픈 손가락이 될 것 같지만 덕분에 인프라 지식도 배울 수 있었고, 디버깅하는 방식에 대해서도 다시금 생각해볼 수 있는 기회였다.

 

추후에 개발이 완료되면 아픈손가락이 가장 기억에 오래 남을 것 같은 복잡 미묘한 감정이 든다.