인프런 커뮤니티 질문&답변

wisehero님, 안녕하세요!

일단 보안적인 우려가 되는 부분인지 먼저 확인해보시면 좋을 것 같습니다.

auto_increment는 이미 많이 쓰이기도 하고, 클라이언트에 응답해도 크게 문제가 없는 상황일 수 있습니다.

현재 단일 DB이고, 앞으로도 분산할 상황이 딱히 없을 것 같고, 보안 문제도 우려되지 않는다면,

그냥 auto_increment 쓰는게 마음도 편하고 별 문제 없을 수 있습니다.

이 부분에 대해서 잘 검토해보시면 좋을 것 같네요!

다른 PK 전략을 사용하려면, 클라이언트에게는 추가로 암호화된 값을 내려주면 될 것 같습니다.

(해시 또는 난수화는 엄밀히 말하면 복호화가 안되고, 해시 또는 난수화에 대해 복호화를 하려면 서버에서 매핑 정보를 계속 가지고 있어야 해서 암호화라고 말씀드렸습니다. 아무튼 맥락은 이미 이해하고 계신 것 같네요!)

또는, PK는 그대로 두고, 따로 유니크 인덱스를 만들어서 클라이언트 식별자로 사용할 수도 있습니다. (꼭 동일 테이블의 유니크 인덱스가 아니더라도 별도의 매핑 데이터를 관리할 수도 있다는 의미입니다. 해시 또는 난수화가 이 부분에 해당하겠네요.)

이 부분은 강의에서도 제안하고 문제점에 대해서 언급하긴 하지만, 성능에 딱히 치명적인 수준은 아닙니다.

검토해보았을 때 특별히 문제가 없는 것 같다면, 사실 어떤 방법을 채택하든 정답은 없습니다!

각 방법의 장단점을 이해하며 현 상황에 적절한 최선의 방법을 찾아나가면 될 것 같네요!

처음으로 스프링부트를 제안하셨다니 어깨가 무거우시겠군요.. ㅎㅎㅎ

잘 해내실 수 있으리라 믿습니다!

혹시 더 궁금한 점 있으시면 편히 문의 주세요!

안녕하세요, 인프런 AI 인턴입니다. wisehero님.

PK(Primary Key) 전략을 설계하면서 겪는 고민은 시스템 설계의 중요한 부분입니다. 특히, 스프링부트와 JPA를 처음 적용하는 프로젝트에서 더욱 신중함이 필요해보입니다. 주어진 상황에서 IDENTITY 전략을 사용 중이라면, 다음과 같은 방법을 고려할 수 있습니다:

ID 노출에 대한 보완 방법

1. ID 변환:

   • 터넷의 UUID(범용 고유 식별자)와 같은 방식을 사용하여 ID를 대체할 수 있습니다. 이 방식은 특히 보안을 강화하고, ID를 직접 노출하지 않게 해줄 수 있습니다.
     
   • 외부 API에 노출할 때는 ID를 해싱하거나 암호화 기법을 적용하여 따로 변환 후 사용하도록 하는 것도 방법입니다.
     

2. 엔티티 상태 변화:

   • Hibernate의 @GenericGenerator를 활용하여 커스텀 식별자 전략을 정의할 수 있습니다. 이를 통해 특정 규칙에 맞게 ID를 생성하고 외부로 노출할 때 구현된 규칙을 따라 처리할 수 있습니다.
     

3. 외부 시스템 매핑:

   • 외부 시스템에 노출해야 할 때는, ID 자체가 아닌 별도의 매핑 테이블을 활용하여 외부용 ID와 내부 ID의 매핑을 관리하는 방법도 한번 고려해 보세요. 이 방식은 시스템 확장성이 요구되거나, 외부 제3자와의 연동 때 유연성을 높여줄 될 것입니다.
     

4. 도메인 모델 설계 개선:

   • 시스템 설계 시 엔티티에 숫자형 자동 증가 ID를 필수로 할지, 비즈니스와 밀접한 자연키나 복합키를 활용할지를 고려해 최적화된 설계를 이루세요.
     

추가 참고 자료

• 유사한 질문에 대한 답변을 보고 싶다면, [’PK 전략 및 ID 정책 관리 관련 게시물’]를 확인해 보시길 추천드립니다. 이는 ID 관리와 노출 방법, 시스템 설계에 대한 구체적인 사례를 공유하고 있습니다.
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.