스프링 2.5 최신 버전은 2.5.6 입니다. 최신 버전으로 지속적으로 갱신해주면 좋겠지만 여의치 않는 경우가 있습니다. 개발 중인 경우라면 번거로운 정도지만, 운영 단계에 접어든 경우라면 만만치가 않을 수도 있죠. 제 블로그에 글을 올렸는데, 스프링 2.5.4 이하의 경우 데이터 타입 변환에 버그가 있어 DB에 의도하지 않은 데이터가 들어갈 수 있습니다. 2.5.4 의 경우 타입 대응 관계를 담고 있는 Map을 다음과 같이 초기화 하는 코드를 확인할 수 있습니다.
long 혹은 Long의 경우에도 INTEGER 로 초기화 하는 코드를 확인할 수 있습니다. 스프링처럼 심하게 잘 만들어진 코드에 이런 오류가 있는지 잘 이해가 가지 않습니다. 위 코드를 처음 확인한 제 동료의 경우는 설마 스프링에 이런 버그가 있지는 않을 듯 해서 본인이 모르는 뭔가가 있는지 저에게 확인했습니다. 아래는 JDBC 스펙에서 오린 것인데요. 스펙에서도 long to BIGINT 는 명기하고 있습니다.
제 블로그에 글에 알려드린 바대로 2.5.5 버전에서는 갱신해서 배포했습니다.
데이터 타입에 대한 오류는 매우 민감합니다. 만일, 2.5.4 이하 버전으로 운용하는 시스템이라면 데이터베이스에 의도하지 않는 값이 있을 수 있습니다. 테스트 해본 팀원에 따르면 Types.INTEGER 를 벗어나는 값이 오면 예외를 발생하는 것이 아니라 오버플로우가 일어나 이상한 수치가 들어간다고 하네요. 특정 클래스 Map에 담으면 알 수 없는 타입으로 인지해 정상적으로 long 수치를 저장하더군요. Transaction Script의 남용으로 객체 대신 Map을 쓰는 경우가 많은 국내 현실 탓에 오히려 문제가 없었을 수도 있겠다 싶어 씁쓸하기도 했습니다.
이런 버그 하나로 스프링의 신뢰도를 의심할 분들이 있지는 않을까 하는 노파심도 들었습니다. 허나 스프링 이슈 트래커를 보면 그렇지 않음을 확인할 수 있습니다. 문제는 물론 해결책까지 제시하는 스마트한 고객(스프링 커뮤니티의 일원이죠), 3시간만에 접수하고 그날 밤 빌드에 반영하는 기민한 기술지원, 이러한 과정을 투명하게 공유하는 시스템 등을 상용 제품과 비교해보면 단박에 알 수 있습니다. 과거에 기술지원이 없어 오픈소스를 못쓴다는 말을 수십, 수백번 들은 바 있는데요. 상용 제품은 버그를 찾아내면 바로 해결해주던가요? 얼마전 국내 대표적인 솔루션 회사의 시장 선도 제품에 버그를 발견했던 일이 있습니다. 우리 팀원이 여섯 차례 문제를 보고했습니다. 빠른 조치를 위해 현상 뿐 아니라 예외로그를 분석해서 문제가 되는 클래스까지 알려주었습니다. 업체의 사이트에는 게시판이 있기는 했지만, 기술적인 문의가 오가는 것은 거의 없었습니다. 몇 일 후에 기술지원 인력이 와서 반나절을 앉아 있다가 '해결할 수 없어서 연구소에 보고하겠다'는 말만 남긴 채 떠나갔습니다. 안타까운 것은 경험을 통해 이미 그러한 결과를 예상하고 있었지만, 혹시나 하고 있었다는 점입니다.
long 혹은 Long의 경우에도 INTEGER 로 초기화 하는 코드를 확인할 수 있습니다. 스프링처럼 심하게 잘 만들어진 코드에 이런 오류가 있는지 잘 이해가 가지 않습니다. 위 코드를 처음 확인한 제 동료의 경우는 설마 스프링에 이런 버그가 있지는 않을 듯 해서 본인이 모르는 뭔가가 있는지 저에게 확인했습니다. 아래는 JDBC 스펙에서 오린 것인데요. 스펙에서도 long to BIGINT 는 명기하고 있습니다.
제 블로그에 글에 알려드린 바대로 2.5.5 버전에서는 갱신해서 배포했습니다.
데이터 타입에 대한 오류는 매우 민감합니다. 만일, 2.5.4 이하 버전으로 운용하는 시스템이라면 데이터베이스에 의도하지 않는 값이 있을 수 있습니다. 테스트 해본 팀원에 따르면 Types.INTEGER 를 벗어나는 값이 오면 예외를 발생하는 것이 아니라 오버플로우가 일어나 이상한 수치가 들어간다고 하네요. 특정 클래스 Map에 담으면 알 수 없는 타입으로 인지해 정상적으로 long 수치를 저장하더군요. Transaction Script의 남용으로 객체 대신 Map을 쓰는 경우가 많은 국내 현실 탓에 오히려 문제가 없었을 수도 있겠다 싶어 씁쓸하기도 했습니다.
이런 버그 하나로 스프링의 신뢰도를 의심할 분들이 있지는 않을까 하는 노파심도 들었습니다. 허나 스프링 이슈 트래커를 보면 그렇지 않음을 확인할 수 있습니다. 문제는 물론 해결책까지 제시하는 스마트한 고객(스프링 커뮤니티의 일원이죠), 3시간만에 접수하고 그날 밤 빌드에 반영하는 기민한 기술지원, 이러한 과정을 투명하게 공유하는 시스템 등을 상용 제품과 비교해보면 단박에 알 수 있습니다. 과거에 기술지원이 없어 오픈소스를 못쓴다는 말을 수십, 수백번 들은 바 있는데요. 상용 제품은 버그를 찾아내면 바로 해결해주던가요? 얼마전 국내 대표적인 솔루션 회사의 시장 선도 제품에 버그를 발견했던 일이 있습니다. 우리 팀원이 여섯 차례 문제를 보고했습니다. 빠른 조치를 위해 현상 뿐 아니라 예외로그를 분석해서 문제가 되는 클래스까지 알려주었습니다. 업체의 사이트에는 게시판이 있기는 했지만, 기술적인 문의가 오가는 것은 거의 없었습니다. 몇 일 후에 기술지원 인력이 와서 반나절을 앉아 있다가 '해결할 수 없어서 연구소에 보고하겠다'는 말만 남긴 채 떠나갔습니다. 안타까운 것은 경험을 통해 이미 그러한 결과를 예상하고 있었지만, 혹시나 하고 있었다는 점입니다.
Prev
Rss Feed