TLS가 안 맞아서 통신이 안 됐다 – 결국 JDK 올렸습니다

☁️ 새로 연동하는 협력사와 통신이 안 됐다

우리 회사는 커머스 플랫폼이라
협력사와의 API 연동 작업이 일상이다.

이건 내가 직접 처리한 건 아니고
우리팀에서 실제로 겪었던 실무 이슈다.

 

그날도 새로 들어온 협력사와
이미지 API 연동 작업을 진행하고 있었는데…

“이미지 API 요청 자체가 실패합니다.”

 

 

다른 협력사들은 아무 문제 없이 잘 되는데
유독 이 새 협력사만 통신이 안 됐다.

 

우리는 당연히 로그부터 확인했고
파고 또 파고… 그러다 딱 하나가 의심됐다.

“이거 TLS 버전 문제 아니야?”

 

---

🔍 우리는 JDK 1.7 , TLS는 1.0/1.1만 지원

우리 시스템은 아주 건강한(?) 레거시다.
현재까지도 Java 1.7을 쓰고 있었고
그 말은 곧 지원 가능한 TLS 버전은 1.0 또는 1.1이라는 뜻.

 

그런데 해당 협력사는
AWS 이미지 서버를 사용 중이었다.

 

---

😐 협력사에서 온 답변은 단 하나였다

“저희는 AWS를 사용하고 있어서
하위 TLS 버전은 지원이 어렵습니다.”

끝.
딱히 기술적 이유나 대안은 없었다.

 

---

🧠 그래서 AWS 엔지니어 친구한테 물어봤다

내가 너무 답답해서
친한 AWS 엔지니어 친구에게 직접 물어봤다.

“야, 진짜 AWS는 TLS 1.1도 안 되냐?”

 

 

그 친구의 말:

“맞아. AWS는 TLS 1.0 / 1.1은 EOS(지원 종료) 때렸어.
지금은 TLS 1.2 이상만 기본적으로 허용돼.”

 

그런데 여기서 중요한 말이 하나 더 나왔다:

“근데 그거 완전 차단은 아냐.
일부 서비스는 설정에 따라 1.0 / 1.1도 쓸 수는 있어.”

“그러니까 반은 진짜고, 반은 귀찮아서 안 해주는 걸 수도 있어.
TLS 낮췄다가 보안 사고 나면 누가 책임질 거야?
나라도 그냥 안 내려줬을 듯.”

 

 

즉,
기술적으로 가능하더라도
정책상, 혹은 책임 회피성으로
“지원 못 합니다”라고 단답하는 경우도 있다는 것.

 

 

---

🔧 결국, 우리 팀이 바꿨다

협력사 쪽에선 TLS 버전 하향이 어렵다는 입장이었고
우리 시스템은 Java 1.7이었기 때문에 TLS 1.2를 지원하지 않았다.

 

그래서 결국 우리 팀에서 JDK를 1.8로 업그레이드하기로 결정했다.

 

---

 

물론 단순히 버전만 바꾸는 게 아니다.

• 테스트 환경까지 싹 점검
• 라이브러리 버전 호환 확인
• 운영 반영 및 배포 프로세스 조정

쉽지 않았지만, 해야만 했다.

보안도 중요하고, 협력사와 통신되는 게 더 중요했으니까.

 

 

✅ 정리하며

이번 일을 겪은 우리 팀은
“통신이 안 될 땐 TLS부터 의심하자”는 교훈을 확실히 얻었다.

 

특히 레거시 환경을 운영 중이라면
TLS 버전과 JDK 버전을 항상 인지하고 있어야 한다.

 

 

🎯 실무 핵심 요약

• Java 1.7 → TLS 1.2 지원 불가
• AWS → TLS 1.2 이상만 기본 허용
• 협력사 → “내려줄 수 없음” (응. 안 해줌)
• 해결책 → JDK 1.8 업그레이드로 TLS 1.2 대응

 

그리고 이건 단순한 기술 이슈가 아니었다.
우리 시스템 구조에 대한 인식을 바꾼 계기이기도 했다.