저도 "심플한 문제"라는 이야기의 추가 설명을 원해요

어떤 면에서 심플한 문제라고 말씀하시는걸까요?

이 글에서는 'With storage nowadays very cheap, this normally is not a problem from the storage point of view.'이라고 얘기하고 있기는 한데, 네트워크 상에서 이 id가 돌아다녀야하는 경우라든가, 메모리 상에서도 key 역할을 해야한다든가, 대용량의 데이터로 여러 곳에서 쓰여야하는 키인 경우 등, 몇 바이트라도 줄이는 것이 중요할 때가 있어서 상황에 따라 UUID를 거절해야하는 상황도 있기는 한 것 같습니다.

이 글에서 말한 문제는 랜덤하게 생성된 값을 primary key 로 사용할 때 생기는 성능저하인데
(다른 문제가 언급되어 있는데 제가 캐치하지 못했다면 말씀해주세요)
그 문제는 이미 답이 있습니다. 시간 순으로 cursor based pagination 할 때랑 같은 문제라 이미 다들 해결해보셨을듯 합니다.

어떤 면에서 복잡한 문제인지 저도 궁금합니다.
말씀하신 상황은 거절해야하는 상황이라고 하셨으니 심플한 문제인 것 같은데...
복잡한 문제는 이도저도 결정을 못내릴 때가 복잡한 문제 아닌가요?

'심플한 문제'라는 것의 의미가 해석될 여지가 많아서 어떤 의미로 쓰신 것인지 궁금해서 여쭤봤습니다. 문제 자체가 어려운 문제가 아니라는 것인지, 글에서 제시하는 명쾌한 답(?)이 있기 때문에 고민의 여지가 적어서 그렇다는 것인지 등이요.
전자에 대해서는 위에서 말했듯이, 상황에 따라서 id가 데이터베이스 외부로도 통용되어야 하는 경우가 있기 때문에 고려할 요소가 많아지고 단순한 문제는 아니라고 생각합니다.