검색과 등록 API의 HTTP 메서드를 정하려 합니다. GET과 POST의 의미는 어떻게 다르며, 민감한 값을 POST 본문에 넣는 것만으로 보호할 수 있나요?

GET과 POST는 URL 길이나 본문 노출만으로 선택하지 않고, 서버 상태에 미치는 의미와 반복·캐시 계약으로 정해야 합니다. GET은 리소스 표현을 조회하는 안전한 메서드이며 멱등적이고, POST는 대상 리소스가 본문을 처리해 생성·명령·상태 변경을 수행하는 데 적합합니다. POST 본문에 비밀번호나 카드 정보를 넣는 것만으로 보호되지는 않으며 HTTPS, 인증, 로그 마스킹, 저장 정책이 별도로 필요합니다.

safe와 idempotent의 의미

GET이 안전한 메서드(safe method)라는 말은 서버에 로그·캐시 통계 같은 부수 효과가 전혀 없다는 뜻이 아니라, 클라이언트가 의도한 리소스 상태 변경을 요청하지 않는다는 뜻입니다. GET을 반복해도 상품 조회 결과를 다시 받는 것이 정상이어야 합니다. 멱등성은 같은 요청을 여러 번 수행한 최종 상태가 한 번 수행한 결과와 같다는 성질이라서 DELETE도 멱등적일 수 있지만 응답은 달라질 수 있습니다. POST는 기본적으로 멱등성을 약속하지 않으므로 주문 생성 재시도에 중복이 생길 수 있습니다.

GET의 질의 값은 URL에 들어가 브라우저 기록, 프록시·웹 서버 로그, 분석 도구, Referer에 남을 수 있고 길이와 인코딩 제약도 있습니다. POST 본문은 URL보다 덜 노출될 뿐 서버 로그·트레이스·브라우저 개발자 도구에 기록될 수 있습니다. HTTPS는 전송 구간을 보호하지만 로그에 평문을 남기는 문제를 해결하지 않으므로 비밀 필드 마스킹과 접근 통제를 적용하겠습니다. 인증된다고 인가가 끝나는 것도 아니므로 자원 소유권을 별도로 검사합니다.

캐시·크롤러·재시도까지 포함한다

GET은 캐시와 링크 공유에 자연스럽지만, 실제 저장과 재사용은 Cache-Control, Vary, 인증 응답 정책에 달려 있습니다. POST라고 자동으로 캐시되지 않는 것도 아니고 GET이라고 항상 공개 캐시되는 것도 아닙니다. 상태 변경을 GET에 넣으면 브라우저의 미리 가져오기, 크롤러, 링크 검사기, 사용자의 새로고침이 명령을 실행할 수 있습니다. 검색이 길거나 요청 내용이 URL에 적합하지 않아 POST를 사용한다면 캐시·재실행 의미를 명시하고 응답 계약을 보완하겠습니다.

네트워크 오류 뒤 POST 재시도가 필요하면 클라이언트가 만든 idempotency key를 사용자·작업 종류와 함께 저장하고, 같은 키가 재사용되면 같은 결과를 돌려주거나 처리 중임을 반환합니다. 키 만료 전에 중복 검사가 사라지면 재실행될 수 있으므로 보관 기간은 외부 재시도와 장애 복구 시간을 포함해야 합니다. 테스트는 프록시 로그·브라우저 기록·링크 미리보기, 재전송, 중복 키를 확인합니다. 메서드 이름보다 서버 상태 변경, 공개 범위, 실패 후 재시도 가능성을 하나의 설계로 묶는 것이 핵심입니다.

멱등성은 클라이언트가 네트워크 오류 뒤 재시도할 수 있는 실용적 계약과 연결됩니다. 생성 API를 POST로 유지하더라도 서버가 idempotency key와 요청 본문 해시를 함께 저장하면 같은 키에 다른 본문이 들어오는 오류를 거절할 수 있습니다. 처리 중인 키에는 중복 작업을 시작하지 않고 상태를 반환하며, 완료된 키에는 원래 결과를 재사용합니다. 다만 키 저장과 실제 생성이 원자적이지 않으면 경쟁이 다시 생기므로 같은 DB 트랜잭션이나 고유 제약으로 경계를 만들겠습니다.

메서드 선택 뒤에도 권한 검사는 변하지 않습니다. GET의 URL을 추측하기 어렵게 만드는 것, POST 본문을 숨기는 것, TLS를 적용하는 것은 인증·인가·기밀성의 서로 다른 문제입니다. 감사 로그에는 필요한 요청 ID와 결과만 남기고 비밀값은 제거해, 재시도와 장애 분석을 가능하게 하면서도 로그가 새로운 유출 경로가 되지 않게 하겠습니다.