HTTP 에서 AES 암호문 API 요청/응답 시 발생하는 에러 분석 및 해결 방법

2026-03-18#http#aes#security#network#troubleshooting

Overview


문제 상황

사내 개발 서버에는 이미 HTTPS, HTTP, localhost 환경이 모두 구성되어 있었고, 일반적인 JSON API 요청/응답은 정상 동작하고 있었다. 이번 작업은 새 암호화 구조를 설계하는 단계가 아니라, 서버에 이미 존재하던 AES 암호문 기반 API 요청/응답 방식을 웹 클라이언트에 연결하는 작업이었다.

테스트를 진행해보니 결과는 명확했다.

  1. 클라이언트에서 요청 본문을 JSON 문자열로 만든다.

  2. AES로 암호화한다.

  3. Base64 문자열로 변환해서 HTTP body에 넣는다.

  4. 서버에서 같은 키로 복호화한다.

초반에는 서버의 프록시 작업 쪽을 먼저 의심했다. 이미 존재하던 서버 AES API를 그대로 붙이는 상황이었고, HTTPS에서는 같은 요청이 정상 동작하고 있었기 때문이다.
문제는 프록시 동작이 아니고, "어떤 계층에서 무엇을 보호하고 있는가"에 대한 이해부족이었다.


HTTP 위에 AES만 올렸다고 안전해지지 않는 이유

가장 먼저 이해해야 할 점은 HTTP는 기본적으로 평문 프로토콜이라는 사실이다. 요청 body를 AES로 암호화하더라도 HTTP 연결 자체가 보호되는 것은 아니다.

예를 들어 요청 body가 아래처럼 암호문으로 바뀌었다고 가정해도,

{
  "ciphertext": "U2FsdGVkX1..."
}

중간에서 네트워크를 볼 수 있는 사람은 여전히 다음 정보를 확인할 수 있다.

즉, 본문이 가려졌다고 해서 통신 전체가 안전해지는 것은 아니다.

이번 테스트에서 중요했던 점도 여기에 있었다.

즉, 이 현상은 "AES를 쓰면 언제나 문제다"가 아니라 "보호되지 않은 전송 계층 위에서 암호문 payload를 얹었을 때 예상하지 못한 문제가 생긴다"는 문제이다.

또한 HTTP 환경에서는 서버 인증 자체가 되지 않는다. HTTPS는 TLS 인증서를 통해 "내가 지금 접속한 서버가 누구인지"를 검증하지만, HTTP는 이런 검증 과정이 없다.

이 말은 곧 다음과 같은 위험으로 이어진다.


브라우저 클라이언트에서는 키 관리가 더 큰 문제

이 구조를 검토하면서 가장 현실적인 문제는 키를 어디에 둘 것인가였다. 브라우저에서 AES 암호화를 하려면 결국 자바스크립트 코드가 키를 알아야 한다. 하지만 브라우저로 내려가는 코드는 사용자에게 전달되는 코드이므로, 충분한 시간과 도구가 있으면 키나 암호화 로직을 역으로 확인할 수 있다.

처음에는 "코드를 난독화하면 괜찮지 않을까"라고도 생각했지만, 그건 근본 해결이 아니다. 클라이언트가 암호화를 수행할 수 있다는 말은 결국 복호화에 필요한 단서도 클라이언트 쪽에 존재한다는 뜻이기 때문이다.

결국 이 방식은 아래와 같은 한계를 가진다.

즉, HTTP 위에 AES를 추가하는 설계는 "통신 자체를 안전하게 만든다"기보다 "본문 일부를 읽기 어렵게 만든다"의 의미였다..


그래서 정리한 결론

이번에 가장 크게 정리한 점은 "본문 암호화"와 "전송 구간 보안"을 같은 문제로 보면 안 된다는 것이다.

이미 AES가 있으니 HTTP에서도 충분히 안전하고 잘 동작할 것"이라고 보면 안 된다.
기본은 HTTPS이고, 그 위에서 필요한 경우에만 애플리케이션 레벨 암호화를 추가하여 보안을 강화하는 목적으로 사용해야 한다.


느낀 점


참고 링크