어떻게 하면 마스킹 부분을 확장하여 개발할 수 있을까?이전에 API 요청/응답 로깅 과정에서 민감 정보를 마스킹하는 로직을 적용한 경험이 있습니다.String maskedRequestBody = SensitiveDataMasker.maskSensitiveData( new String(requestBodyBytes, StandardCharsets.UTF_8));내부 APIb-programmer.tistory.com이번글은 하드코딩된 마스킹을 어떻게 하면 확장성 있게 가져면서 리펙토링 한 기록입니다. (자세한 배경은 위 포스트를 참고해 주세요.)기존 코드String maskedRequestBody = SensitiveDataMasker.maskSensitiveData( new String(request..
특정 API의 개발과 배포가 완료되고, 시간이 어느 정도 지난 뒤 트래픽이 몰리는 상황은 생각보다 자주 발생합니다. 이런 상황이 오면 자연스럽게 여러 선택지를 떠올리게 됩니다. 특정 값을 캐싱할 수도 있고, 메시지 큐를 도입해 비동기 처리를 할 수도 있으며, 아예 비동기 API 구조로 전환하는 방법도 있습니다. 레이턴시를 줄이기 위한 방법은 분명 많습니다. 그리고 각각의 방법은 그럴듯해 보입니다. 하지만 여기서 한 번 더 생각해볼 필요가 있습니다. "과연 어떤 방법을 사용하는 것이 효율적인 선택일까?" 이 질문은 "캐시를 쓸까, MQ를 쓸까, 비동기로 바꿀까"를 묻는 질문처럼 보이지만, 사실은 그보다 앞선 문제를 묻고 있는 질문일지도 모릅니다.사실 이전에 이거와 비슷하게 글을 작성한적이 있습니다. 특명:..
이전에 API 요청/응답 로깅 과정에서 민감 정보를 마스킹하는 로직을 적용한 경험이 있습니다.String maskedRequestBody = SensitiveDataMasker.maskSensitiveData( new String(requestBodyBytes, StandardCharsets.UTF_8));내부 API의 경우, 요청 스펙과 데이터 구조에 대한 제어 권한이 전적으로 서비스 내부에 있었기 때문에해당 마스킹 로직을 수정하더라도 영향 범위가 제한적이었고, 유지보수 측면에서도 큰 문제가 되지 않았습니다.하지만 동일한 마스킹 로직을 외부 API 로깅에도 그대로 적용하면서 구조적인 한계가 드러났습니다.외부 API는 요청 필드의 명명 규칙이 통일되어 있지 않으며, 민감 정보가 항상 동일한 키 이름으..
이전에 여러 프로토콜을 공부하면서, 프로토콜은 서로를 대체하기 위해 존재하기보다는 각자가 해결하지 못하는 영역을 보완하는 방향으로 진화해 왔다는 점이 인상 깊었습니다. 즉, 하나의 프로토콜이 모든 문제를 해결하는 구조가 아니라, 역할을 분리하고 그 위에 다른 기술을 결합하는 방식으로 전체 구조가 완성된다는 관점입니다. 이 관점을 웹에 그대로 적용해 보면, 웹 애플리케이션 계층의 중심에는 여전히 HTTP가 존재합니다. 그리고 우리가 흔히 말하는 HTTP/1.1, HTTP/2, HTTP/3는 서로 다른 목적의 별도 프로토콜이 아니라, 동일한 HTTP 모델을 유지한 채 성능과 연결 관리의 한계를 개선해 온 진화 과정에 가깝습니다. 한편 HTTPS는 새로운 프로토콜이 아니라, HTTP 통신 위에 TLS를 결합하..