자바로 UUIDv7를 만들기 위해 라이브러리를 다운받기 전,
혹시 자바 17버전에서는 라이브러리 없이 UUIDv7 생성이 가능하지 않을까? 하는 생각이 들어 AI님께 질문을 드렸다.
그랬더니,
Google Gemini:
자바 17버전부터는 java.util.UUID.randomUUID()의 반환값이
UUIDv7입니다!
자바 17버전 이하를 사용하신다면 UUID 라이브러리를 사용하시고,
17버전 이상이라면 라이브러리는 필요 없습니다!
듣고 나서 어라? 싶었다.
JDK 17부터 똑같은 메서드의 반환값이 이전 버전과 달라지면 어떤 문제가 일어날까?
17로 올릴 때는 크게 문제가 안 될 것 같다.
하지만 다운그레이드를 해야 하는 상황이 온다면 어떨까?
라이브러리or프레임워크 호환 문제로 JDK를 다운그레이드해야 하는 상황이라 가정하자.
1. 시간순 정렬이 보장되는 줄 알고 정렬을 하지 않고 반환했던 API에서 정렬 문제가 생김
2. 시간순 정렬을 기대하고 사용해왔던 DB 인덱스에 갑작스러운 페이지 재구성 비용 발생 시작
이런 문제가 생기지 않을까?
그래서 나는 개인 프로젝트에 자바 17을 사용하고 있었지만
UUID 라이브러리를 사용하기로 했다.
추가 의존성이 생기겠지만,
똑같은 코드가 JDK 버전 따라 다르게 동작하지 않고
코드에 명확하게 드러나기 때문이다.
그런데 라이브러리 코드를 작성하면서도 위의 이야기가 너무 찜찜했다.
도대체 왜 JDK 개발자들은 그런 위험한 결정을 내렸을까?
그래서 진짜 JDK 17부터는 UUIDv7이 반환되는게 맞는지 실험해보기로 했다.
그런데?
사실 실험해볼 필요도 없다. 그정도의 중요한 변경사항이 일어났으면
이미 randomUUID()의 Javadoc에 적혀있었을 것이다.
그리고 당연하게도 JDK17의 Javadoc에는 UUIDv4를 반환한다는 이야기가 적혀 있었다.
실험을 해봐도 결과는 역시 같았다.
AI님은 참 고마운 분이지만 모르는 티라는 것을 내지 않는다.
Gemini의 실수를 보고
'나는 내가 뭘 모르고 뭘 아는지를 확실히 알고 의사소통을 해야겠구나'
하는 다짐도 하게 된다.
가끔 AI의 환각현상이 발생할 때마다 내심 다행이다 하는 생각이 들기도 한다.
아직 내 밥그릇을 완벽히 대체하진 않겠구나 하는 생각이 들기 때문이다.
AI의 생산성과 효율성 때문에 아예 AI를 사용하지 않을 순 없어도
중요한 부분은 꼭 스스로 검증해봐야 하겠고,
환각성 발언을 빨리 눈치챌 수 있도록 깊이있는 공부가 필요하겠다 싶었다.
몇년 후에 내가 이 글을 다시 보면 어떤 느낌을 받을지 궁금하다. 그때는 AI가 좀 더 발전해 있을까?
'TIL' 카테고리의 다른 글
CI/CD에서 Runner란? (0) | 2025.02.18 |
---|---|
gitlab과 SSH - private key를 왜 못 찾니 (0) | 2025.02.18 |