오라클 품질 관리의 한 단면을 소개해 주는 글을 소개합니다.
글쓴이: emptynote / 작성시간: 화, 2019/04/09 - 4:30오후
오라클 품질 관리의 한 단면을 소개해 주는 글을 소개합니다.
오라클 같은 회사도 몬 패치가 있다면 메인 브랜치로 합병되는것이 2주에서 2달 걸린다합니다.
메인 브랜치로 합병되는것이 끝이 아니기에 스트레스 받아 투덜 거리는것은 당연하다고 생각합니다.
오픈 소스는 느슨한 조직입니다. 오라클 같은 괴물 같은 회사에 비할 바가 아니죠.
도대체 무슨 재주로 2주간 정도 시간으로 메인 브랜치 즉 안정 버전이 될 수 있을 수 있을까요?
한번은 아래 글 읽어 보며 생각해 보시기 바랍니다.
-------------
KLDP 권순선님 트위터 "프로그래머의 악몽.. " 참고 주소 : https://news.ycombinator.com/item?id=18442941
Oracle Database 12.2.
It is close to 25 million lines of C code.
Forums:
링크된 글은 그렇게 오래걸릴만큼 최악으로 구성된
링크된 글은 패치 하나 만드는 것이 그렇게 오래 걸릴 만큼 최악으로 구성된 오라클 데이터베이스의 코드를 비판하는 글입니다. 오라클 같은 괴물 회사는 품질 관리를 위해 패치 하나 통과하는데 2주에서 2달 걸린다는 의미의 글이 아닙니다. 처음부터 끝까지 오라클은 완전 호러라면서 굉장히 격한 어조로 비판하는 글입니다. 그리고, 다음의 문장으로 끝을 맺죠.
I don't work for Oracle anymore. Will never work for Oracle again!
품질 때문에 패치 하나가 2주에서 2달간 테스트를 한다는 것은 구차한 변명입니다. 만약 테스트를 위해 패치를 릴리즈 하는 기간이 그렇게 길다면, 테스트 infrastructure와 code modularization의 실패라고 볼 수 있습니다. 완전 스파게티 코드가 되서 코드를 유지보수하는것만해도 엄청난 비용이 발생하는 상태의 최악의 프로젝트 상태라고도 볼 수 있습니다. 링크하신 글에서 글쓴이가 쓴 내용도 그런 의미로 오라클 데이터베이스를 비판하는 글 입니다. 오라클의 품질 관리의 단면과는 상관이 없는 이야기 입니다.
오픈소스 프로젝트는 패치를 그렇게 짧은 시간안에 테스트하고 릴리즈 할 만큼 자원이 부족하다는 점은 동의 합니다. 테스트를 하기 위해 엄청난 금액의 돈이 소모 됩니다. 따라서, 오픈소스의 경우, 각 배포판의 버그 리포트와 유저들의 힘을 모두 모아, 충분한 기간 많은 사람들이 테스트 했다는 심증(??)이 생기면 릴리즈 하는 것으로 볼 수 있습니다. 패치를 테스트 할 만한 돈과 인력이 없기에, 불가피한 선택이겠죠.
소스코드가 2천5백만줄입니다. 누가 있어 돌을 던질 수 있읍니까?
소스코드가 2천5백만줄입니다.
정말로 자신이 그런 규모의 프로그램을 만들었다고 한다면 오라클 보다 더 클린 코드로 만들 수 있을까요?
누가 있어 돌을 던질 수 있읍니까?
스파게티 코드라고 단순하게 깔아 뭉갤 그런거는 아니라고 생각합니다.
그리고 패치 하나에 2주에서 2달간은 기간이 너무 오래 걸린다는 면에서 실패지만
통합 테스트까지 하는 테스트라면 오히려 그 기간이 짧은 거라 생각합니다.
오라클쯤 되는 괴물 회사라서 그 정도 시스템을 구축한거 아닐까요?
역으로 통합 테스트까지 해 준다면 오히려 오라클을 칭찬해 줄 일이라고 생각합니다.
회사 안에 있어 통합 테스트까지 해주는 것에 대한 고마움을 못 느끼는거 아닌가 합니다.
오라클에 죄가 있다면 바로 DB 회사 특성상 신뢰성에 한번이라도 흠집이 나면
회사 존립 기반이 매우 어려워 질 수 있다는 사실에 대하여 전혀 이해하지 못하는 사람을 고용한 것입니다.
오프소스는 말씀하신대로 돈과 인력이 없다는데 전적으로 동의합니다. 하여 회사 처럼 체계를 갖고 테스트를 진행할 수는 없다고 생각합니다. 다만 그런 사실에 대하여 정확하게 알리는데까지는 노력해 주어야 한다고 생각합니다. 개발자 혹은 개발팀내에서만 테스트가 끝난건지 공개후 한달간 특별한 버그가 보고되지 않은 상태라든지 이런 정보 말입니다. 이게 그렇게도 어려운 일인가요? 정 이것에 대하여 아리송하고 따지기 구찮다면 걍 베타버전이라고 오픈하면 알아서들 사용해 보고 판단할거라 생각합니다.
오픈 소스는 사람이 개발하고 사람이 사용하는 사람 사는 동네 아닙니까?
사람 사는 동네라면 자기가 만든것을 믿고 사용하는 사람에 대해서 테스트 수준에 대한 옳바른 정보가 아닌 거짓된 정보로 현혹하는 행위에 대해서 비난하는것이 당연지사 아닌가요.
옳바른 아니고 올바른...
오픈 소스는 사람이 개발하고 사람이 사용하는 사람 사는 동네 아닙니까?
맞는 말씀입니다.
그런데 emptynote 님은 다른 사람 말에는 귀막고 자기 얘기만 하나요?
옳바른 아니고 올바른입니다.
https://www.korean.go.kr/front/mcfaq/mcfaqView.do?mn_id=62&mcfaq_seq=3807
세벌 https://sebuls.blogspot.kr/
이제는 본인 스스로의 약속따위 안 지키고 막가겠다는 거지요.
이제는 본인 스스로의 약속따위 안 지키고 막가겠다는 거지요.
---------------------------
"emptynote 글에 댓글을 달지 않겠습니다." 참고 주소 : https://kldp.org/node/160313
emptynote 글에 댓글을 달지 않겠습니다.
세벌의 이미지
글쓴이: 세벌 / 작성시간: 월, 2018/10/15 - 3:45오후
저는 emptynote 님이랑 소통을 여러차례 해 보려 했으나...
서로 다른 차원에 사는 존재와 소통한다는 건 쉽지 않네요.
emptynote 님 안녕히 계십시오.
덧.
제 글에 emptynote 님이 댓글 다는 건 제가 막진 않겠습니다. 사실 제가 막을 권한도 없어요.
이 분은 할 말 없으면 논의와는 관계없는 걸로
이 분은 할 말 없으면 논의와는 관계없는 걸로 인신공격하고 그러시더라구요.
그냥 차라리
잘못 이해했다. 내가 잘못 안 것 같다. 불찰이다. 그럴 수도 있겠다. 죄송하다.
자원(인력, 돈, 시간)이 부족함에도 불구하고 꾸준히 버그 패치해서 업데이트해주는 리브레오피스 측에 감사한다.
이런 말 하는게 그렇게 어려운가요?
오픈소스니까 emptynote님께서 직접 한글 홈페이지를 수정하시면 되잖아요.
이미 리브레오피스 등 여러 오픈소스 프로젝트들이
이미 리브레오피스 등 여러 오픈소스 프로젝트들이 그렇게 하고 있습니다.
emptynote 님께서는 그걸 부정하고 계신거죠.
눈에 보이는 것을 보고도 아니라고 말씀하시니..
Relese Note 에 나와있는데.. 영어를 모르셔서 그런 말씀을 하시는 건가..
https://wiki.documentfoundation.org/ReleaseNotes/6.2
고객님께 브리핑해드리는 VIP 서비스 이런 걸 원하시는 건가..
>> 소스코드가 2천5백만줄입니다.
>> 소스코드가 2천5백만줄입니다.
>> 정말로 자신이 그런 규모의 프로그램을 만들었다고 한다면 오라클 보다 더 클린 코드로 만들 수 있을까요?
>> 누가 있어 돌을 던질 수 있읍니까?
더 많은 양의 소스 코드가 있고, 더 많은 수의 하드웨어/소프트웨어 플랫폼을 지원하며, 더 많은 숫자의 유저들이 사용한다고 제가 생각하는 프로젝트의 build&test infrastructure team에서 일하고 있습니다. 링크된 글에 서술된 내용이 맞다면, 제 생각에는 기술관리의 실패로 보여집니다. 소스파일 개개의 수준에서의 클린코드 여부보다, 전반적인 architectural 측면에서의 시스템 컴포넌트간 의존성과 API design등의 문제라고 보여집니다. 쉬운 주제가 결코 아니라는 것은 동의 합니다. 하지만, 그래서 많은 회사들이 infrastructure에 많은 돈과 인력을 투여하고 있습니다. 링크된 글에 서술 된 내용이 사실이라면, 저 프로젝트는 겨우 겨우 유지보수와 최소한의 기능추가만 하고 있는 maintenance mode에 진입한 프로젝트라는 생각이 듭니다.
>> 오라클에 죄가 있다면 바로 DB 회사 특성상 신뢰성에 한번이라도 흠집이 나면
>> 회사 존립 기반이 매우 어려워 질 수 있다는 사실에 대하여 전혀 이해하지 못하는 사람을 고용한 것입니다.
테스트가 빨리 끝난다는 것이 테스트를 덜 한다는 의미는 아닙니다.
테스트가 늦게 끝난다는 것이 테스트를 더 한다는 의미도 아니고요.
리뷰를 더 많은 사람들이 한다는것이 더 나은 질의 리뷰를 보장해 주지도 않습니다.
리뷰를 더 오래 한다는것이 더 나은 질의 리뷰를 보장해 주지도 않습니다.
어짜피 테스트는 사람이 하는것이 아니라, 기계와 프로그램이 합니다. 사람은 테스트 시나리오를 짜죠. 만약 전반적인 test cycle이 너무 길다면,
- test infrastructure가 비효율적으로 돌아가고 있거나,
- under provision 되어있거나,
- 코드가 너무 스파게티에, 모듈간 의존성이 최악이라서, 테스트들을 병렬처리 할 수 없는 경우일 수도 있습니다.
링크된 글의 서술에 의하면 코드 퀄리티의 문제처럼 보이기는 하네요.
지나치게 긴 리뷰 프로세스도 문제로 보입니다. 리뷰는 사람이 합니다. 그리고 사람은 항상 실수를 하죠. 프로그램의 안정성을 사람의 리뷰에만 의존하는것은 잘못된 출발입니다. 테스트가 충분하다면, 코드 리뷰 시작하기전에 자동 테스트 단계에서 많은 문제들을 걸러낼 수 있어야 합니다. 사람이 하는 리뷰가 몇 달 길어진다고 안정성이 올라갈 가능성이 더 많아지는것도 아닙니다.
링크에 서술된 내용이 맞다면, 칭찬이 아니라 비판해야할 만한 부분들 같습니다. 작은 규모의 회사라면 칭찬 할 수도 있는 부분입니다. 하지만, 오라클 같이 큰 회사는 그정도 규모의 프로젝트를 더 잘 관리하지 못할 때, 비판 받을만한 부분입니다.
----------------------------------------------------------------------------
다시 말씀드리자면, 오픈소스의 릴리즈 사이클은 길어질 수 밖에 없다는 것은 동의합니다. 테스트에 투자 할 인력과 돈이 없으니까요. 하지만, 링크된 글과 오라클의 사례가 그것을 뒷받침 하기 위한 비교 기준으로 쓰여지는것은 의문점이 듭니다.
말씀 잘 들었습니다. 다만....
말씀 잘 들었습니다.
단위 모듈 테스트 시간이 2주 걸리는것에 대해서는 저두 문제라고 생각하여
통합 테스트일 경우 이해할 수 있다고 언급했습니다.
그런데 3천만줄 자신의 경험치를 소개하시면서 full integration 테스트 기간에 대해서 언급을 안하셨네요.
저는 큰 규모의 프로젝트 경험이 없기때문에 오라클 통합 테스트가 2주면 짧다는것도 막연한 추측입니다.
하여 이런 생각을 바로 잡으려면 무엇인가 기준이 있어야 하지 않겠습니까?
그 기준은 3천만줄 프로젝트하에서의 경험담을 갖고 계신분의 말씀이라면 신뢰할 수 있지 않을까요.
원론적 이야기로 내용적으로 충분한 테스트 시간이 짧으면 짧을 수 록 좋다는거 누가 부정할 수 있겠습니까?
하여 말씀하신 내용 대부분 다 공감합니다. 특히 기계화 주장은 더 많이 공감합니다.
다만 "프로그램의 안정성을 사람의 리뷰에만 의존하는것은 잘못된 출발" 라는 말씀에 전적으로 동감하지만
GUI 프로그램은 아직 사람 손길이 필요합니다.
어찌되었든 오라클의 중심은 DBMS 이지 GUI 가 아니기에 샛길로 샐 필요는 없는것 같습니다.
기계화 통한 테스트 병렬 수행이라는 말씀은 세겨 듣겠습니다.
자바에서 걍 ant test 로 했는데 흠... 만약에 이렇게 해서 병렬 수행이 안된다면 고민좀 되네요.
>> 자바에서 걍 ant test 로 했는데 흠...
>> 자바에서 걍 ant test 로 했는데 흠... 만약에 이렇게 해서 병렬 수행이 안된다면 고민좀 되네요.
손으로 셀수 있는 수만큼의 모듈/컴포넌트로 구성된 시스템이나 프로그램들을 위해 유닛테스트를 돌리는것은 병렬수행이 큰 의미가 없습니다. 어짜피 프로그램의 규모가 너무 작아서 테스트 갯수도 크지 않을테니까요. 하지만, 코드가 몇천만줄 정도 되면, 단일 프로그램만으로 되진 않고, 클라이언트/서버 구조, 그리고 서버 안에서도 다양한 모듈 또는 독립적인 프로그램들로 네트워크를 형성하고, cache layer, load balance layer, 기타등등 모든것이 복잡하게 연결된 구조일 가능성이 큽니다. 아마도 링크된 글에서 언급된 오라클 데이터베이스도 그냥 단일 컴퓨터에서 실행시키는 아파치같은 프로그램을 말하는것은 아닐것이라 생각합니다.
아마도, 클러스터 구성해서 다수의 DB노드를 구축하고 replication도 하며, load balancing, caching, distributed transaction 기능까지 모두 들어간 enterprise level DB를 말하는것이겠죠. 이 정도 규모의 프로그램에서의 테스트는 ant test같이 컴퓨터 하나에서 그냥 실행키시는 수준에서의 병렬처리를 의미하지는 않습니다.
말씀하신데로 full integration test가 필요한데, 한 컴퓨터에서 a complete system을 구축하기 힘든 경우가 대다수입니다. 기술적으론 가능하더라도 제대로된 테스트 결과가 나오지 않을수도 있고요. latency나 performance test 결과가 제대로 나오지 않을 가능성도 큽니다. 위에 언급된것 같은 네트워크 상에서 구축된 enterprise system의 throughput이나 latency는 단일컴퓨터에서 모든 모듈을 띄우고 emulation하기에는 어려움이 많습니다.
canary test 같이 실제로 유저들에게서 발생되는 많은 양의 real traffic을 넣고 발생하는 API에서 발생하는 successful return 과 error return의 패턴을 AI로 분석하여 과연 이정도의 에러 발생률이 평소에 보여지는 에러 발생 패턴에 부합하는것인가 아닌가도 판단합니다. 모든 유닛 테스트 failure를 에러로 간주하지도 않습니다. 그정도 규모의 프로젝트가 되면, 정말 수십만개에서 수백만개의 유닛 테스트가 존재하며 엄청나게 많은 수의 개발자들이 여러 나라에서 함께 개발합니다. 프로젝트가 진행되면서 모든 유닛테스트의 품질을 완벽하게 유지하는것도 현실적으로 불가능합니다. 1년전 유효했던 유닛테스트가 특정 기능추가 이후로, 더이상 유효하지 않는 테스트가 되거나, 간헐적으로 실패하는 유닛 테스트가 되기도 합니다.
따라서 유닛테스트가 한번 실패한것으로 모든 빌드와 테스트를 멈추는것도 현실적이지 않습니다. 유닛테스트의 성공과 실패결과 히스토리를 구축하여, 특정 유닛테스트가 실패했을때, 과연 이 실패가 테스트 자체의 문제인가 아님 정말 유효한 에러를 잡아서 실패했는가를 AI로 또한 판단하기도 합니다. 유닛 테스트도 error budget이라는것이 존재하기도 하거든요.
병렬처리도 그렇게 생각하시면 됩니다. 시스템 기능 A, B, C가 있다고 가정해보죠. 아키텍쳐 디자인상 기능 A, B, C는 완벽히 독립적으로 수행되며 서로 영향을 줄수 없다는것이 보장되어있다면 A, B, C를 병렬적으로 integration test 할 수 있습니다. 만약 A, B, C가 아키텍쳐상에서의 독립적인 수행이 보장되지 않는다면, A, B, C를 모두 같이 테스트 해야하는 경우가 발생할 수도 있습니다.
>> full integration 테스트 기간에 대해서 언급을 안하셨네요.
>> 저는 큰 규모의 프로젝트 경험이 없기때문에 오라클 통합 테스트가 2주면 짧다는것도 막연한 추측입니다
full integration이라고 하나의 테스트가 몇시간씩 걸리는것은 아닙니다.
가령, 오라클 DB클라이언트에서 하나의 update 쿼리를 보내고, 해당 쿼리가 모든 replica에 업데이트 되어 돌아오기까지의 latency를 측정하는 테스트가 있다고 가정해보죠. 해당 쿼리의 총 round trip 시간이 얼마나 걸릴것 같나요? 그냥 1초라고 해보죠. 쿼리 결과를 받아서 분석하고 리포트를 작성하는 시간도 필요하니 extra 1 sec을 추가해보죠.
그런 부류의 테스트 10000개를 동시에 병렬처리로 한다고 가정해보죠. 10000개의 테스트를 돌리는데 소모되는 총 시간은 2초입니다. 20000초가 아닙니다. 사실, full integration test는 그것보다 더 오래 걸리는 경우가 많죠. 10000개의 테스트를 독립적으로 돌릴려면 10000개의 독립적이고 서로 간섭하지 않는 테스트용 DB시스템이 이미 구축되어야 하거든요. 그것은 현실적으로 엄청난 비용이 발생하죠. 그래서 여기에도 다양하고 복잡한 distributed testing infrastructure가 존재하고, 큰 회사들은 많은 양의 돈과 인력을 test infrastructure만드는데 투자합니다. 왜냐면 회사 제품 생산성에 막대한 영향을 미치거든요. 패치 하나에 full integration test가 그렇게 오랜기간이 걸리는건 뭔가 잘못 돌아가고 있다는 의미입니다.
문제가 있다고 하는데 자신의 기준조차 말하지 못할거 왜 말씀하시는겁니까?
테스트 시간이 오래 걸릴경우 코드 문제일 가능성 높다 주장에 동의하지만
말씀하신대로 클러스터 구성해서 다수의 DB노드로 구성해서 테스트하는 오라클급 규모의 통합 테스트가 1초, 2초 이럴리 없잖아요.
저는 그 정도 규모를 경험한적 없지만 분산 테스트 그 자체의 어려움이 있다고 생각하기에 2주도 빠르다 생각하는겁니다.
오라클이 돈을 아끼려 해서 임대하여 테스트 해야 한다면 테스트 시간은 더 오래 걸립니다.
좀 과장하여 말하자면 테스트 환경 세팅하는데도 시간 엄청 오래 걸리잖아요.
하여 대략 이정도쯤 되어야 하는데 이 선을 넘은것은 문제다 해야지
원론적 이야기만 하시면 당장 저는 다른곳에서 무슨 근거로
오라클 2주 테스트를 보건데 스파게티 코드일 가능성이 높다고 말할 수 있습니까?
2주 테스트까지 걸리는것을 보아 아마도 스파케티 코드일 가능성 높다는 주장하시면서
대략적인 기준 시간을 제시 하지 않으신데
대략적인 기준 시간을 제시하지 못한다는것은 변수가 너무 많아 못 제시하시는 거고
그 말은 결국 주관적인 판단이라는 말씀이 아닙니까?
그러면 2주에 대한 판단에 대해서 저두 님도 어느 누구도 맞다 틀리다 할 수 없는거 아닙니까?
리눅스 좋아하면서 이 문구에 반감 없으면 에러죠.
리눅스 좋아하면서 이 문구에 반감 없으면 에러죠.
"It is close to 25 million lines of C code."
===> 이보세요. 리눅스 커널은 c 로 작성되었다구요.
첫문장 보고 이 사람이 c 언어 무진장 싫어하는 구나 합니다.
이 표현 명백히 c 언어 비하 표현인데... 저는 자바 프로그래머인데도 화가 나는데 다들 괜찮으십니까?
그 말은 c언어 비하 표현이 아니라 코드가 2
그 말은 c언어 비하 표현이 아니라 코드가 2,500만 라인에 가깝다는 뜻입니다.