RPM으로 주시면 안되시겠나요?

koseph의 이미지

SI 작업을 하다 보면 참 희안한 경우가 많은데 제가 지금까지 경험해 본 바로는 거진 90% 이상의 소프트웨어 공급업체가 여전히 소스 컴파일 혹은 특정 언어의 경우 아예 소스 업로드 형태로 소프트웨어를 납품 하고 있다는 것입니다.

이런 상황에선 주로 root 계정을 달라고 입에 버릇처럼 달고 삽니다. 당연하다는 듯이 요구하는 것도 제가 보기엔 기가 막히다 못해 진짜 웃기기까지 합니다.

물론 발주처에서는 이것 자체를 문제 삼지는 않습니다. 대개 발주처의 담당자라는 사람들은 이게 중요한 지도 모릅니다.

성질 드러운 제가 문제를 삼죠.

왜 RHEL 혹은 그 호환 OS에서 자신들의 소프트웨어 배포의 표준으로 삼고 있는 형식을 국내의 수많은 소프트웨어 개발업체들이 스스로 무관심 할까요?

우리나라 기업 혹은 관공서에서 RHEL, CentOS의 비중은 다른 어떤 배포판보다 높다고 저는 확신합니다.

그런데 여전히 소프트웨어를 라이선스를 구매하고 그 소프트웨어의 대부분은 GNU 소프트웨어에 의존하고 있고 심지어는 무단으로 고쳐서 사용하는 것까지 뻔히 보이는 데도 여전히 소스 컴파일을 고집합니다.

한번은 제가 조용히 물어봤더랬습니다.

소프트웨어를 판매해서 서비스는 존재하는데 소프트웨어 패키지는 없는가라고 말이죠.

그랬더니, 뜻밖의 대답이 돌아옵니다.

"제가 들어온 지 얼마 안되어서요."

이게 무슨 소린가?

이건 회사가 가지고 있어야 할 소프트웨어 배포 정책임에도 이 직원은 자신의 개인 책임인 것으로 변명을 하고 있는게 아닌가?

그래서 저는 이런 생각이 들기 시작했습니다.

RHCE 자격을 가지고 계신 몇몇 분이 KLDP에 글을 올려 놓은 걸 본 적이 있습니다.

그 분들 왈, RHCE는 하는 일 때문에 땄고 기분은 좋았으나 그다지 큰 덕을 보지 못했다고 하신 것 같습니다.

그 많은 RHCE는 다 어디로 갔는지 모르겠습니다만 제가 겪어본 우리나라 리눅스 관련 소프트웨어 혹은 SI 업계의 관행은 우리나라에 RHCE는 커녕 RHCT도 없어 보입니다.

아마도 그렇다면 이것은 다음 중의 하나가 아닐까요?

1. 매출 수위를 다투는 기업들이 RHCE와 같은 기술 인증을 말 그대로 인증으로만 쓰고 이를 실무에 적용하는 것에 게으르다. 어떤 면에서 게으른 정도가 아니고 아예 관심 조차도 없다.

2. 진짜 실력 있는 SI업체는 맨날 "을"도 아니고 "병", "정"에서 인건비 벌기 바빠서 자신들이 개발한 소프트웨어에 대해 패키징이고 뭐고 그런거 할 시간이 없다. 패키징 할 시간이면 딴 거 해서 돈 버는 게 훨씬 낫기 때문이다.

3. RPM 패키지가 없으면 무단 복제를 근절할 수 있어서 오히려 더 낫기 때문이다.

4. 설치비를 또 청구할 수 있어서 꿩먹고 알먹기다.

물론 저와는 다른 환경을 경험하고 계신 분도 많이 계시리라 생각합니다만 여러분들이 느끼는 지금의 우리네 IT산업의 현 주소 어떻습니까?

feanor의 이미지

저도 RHCE 있는데요, 병특할 때 제 경우에는 2에 가까웠던 것 같습니다. (패키징할 시간을 안 줍니다. 제대로 하려면 사용자 계정을 여럿 셋업하고 DB를 만들고 해야 해서 좀 복잡했습니다.) 그래도 checkinstall로 RPM을 만들었던 것으로 기억합니다. (다만 RPM 설치 후에 스크립트를 따로 실행하도록...)

이건 별 상관 없지만 RHCE 시험에 패키지를 제작하는 내용은 없었던 것으로 기억합니다. RHCE는 어디까지나 engineer고 developer 시험은 아니지 않나요?

제가 작업하던 것 말고 개발이 완료되었던 다른 소프트웨어는 RPM으로 배포를 했습니다. 다만 RHEL 버전별로, 32비트/64비트별로 RPM을 각각 빌드하려면 빌드 환경이 필요하고 해서 쉽지만은 않았던 것으로 기억합니다.

koseph의 이미지

누가 하면 어떻습니까?^^

안하는 거 보담야 백배는 낫죠.

회사 내에서 할 줄 아는 사람이 하면 되겠지요. 그게 타이틀이 RHCE든 아니든 말입니다.

아침에 와서 다른 직원이 가지고 있는 RHCE 국내 교재를 보았습니다. 말씀 하신대로 rpm의 사용 방법만 나와 있지 rpmbuild를 이용한 패키지 제작은 아예 없더군요.

그런데 미국에서 나온 3rd party RHCE 교재(제가 봤던거)에는 커널 rpm을 재패키징 하는 것은 물론이고 rpmbuild를 이용해 다른 패키지를 패치하고 재구성하는 것까지 다루고 있었습니다. 재밌는 건 이걸 설명하면서 실제 시험에 나올 가능성은 1%도 안된다고까지 하고 있긴 하네요.

그래서 제가 착각한 모양입니다. 저는 RHCE 유료 교육 과정과는 무관하게 시간나는 대로 혼자 준비해서 시험을 본 케이스라.....

여담이지만 시간과 돈이 충분했어도 아마 유료 교육은 안받았을 겁니다. 넘 비싸서요. 관계자 분들 발끈하실 지 모르겠지만 제가 생각할 때는 넘 비쌉니다. 이 비싼 교육비가 사실은 훌륭한 엔지니어를 양성하는 데 걸림돌 역할을 하고 있다는 것도 사실입니다. 더 저렴하면서도 효과적으로 교육할 수 있는 시스템을 개발한다면 오히려 RHEL의 실질적인 저변 확대에 기여하지 않을까 싶습니다.

다시 본론으로 들어가서, 빌드 작업 환경을 만드는 것은 그다지 복잡하지가 않습니다. 따로 꼭 실제 머신이 있어야 하는 것도 아니구요. 가상머신에서 작업하셔도 됩니다.

물론 아주 쉬운 것은 아니죠. 하지만, 조금만 신경 쓰면 누구든 할 수 있습니다.

그리고 저도 이 점은 아주 아쉽습니다만........

가끔은 개발자의 역할과 개발자 여러분들이 말하는 SE의 역할이 바뀌는 경우도 있습니다. 국내 중소기업에선 이런 명확한 기준도 없이 일하고 있는 업체도 많지요. 이런 말하고 있으니 발제를 한 저도 아침부터 좀 갑갑해지는군요.
---------------------------------
There's always another way, dear.

---------------------------------
There's always another way, dear.

feanor의 이미지

"빌드 작업 환경을 만드는 것은 그다지 복잡하지가 않습니다. 따로 꼭 실제 머신이 있어야 하는 것도 아니구요. 가상머신에서 작업하셔도 됩니다."

지금은 그렇습니다만, 몇 년 전에는 그렇지가 않았습니다. 사실 빌드 환경을 갖추는 문제 때문에 사내에서 가상화에 대한 공부를 하기도 했습니다. (결국에는 Xen으로 가상화해서 여러 버전에 대한 빌드 환경을 갖췄습니다만 우여곡절이 많았습니다.)

danskesb의 이미지

오픈수세 빌드 서비스나 런치패드 PPA가 탄생한 것도 얼마 되지 않았죠. 가상화라는 개념은 요즘 들어서야 일반화되었습니다.

---- 절취선 ----
http://blog.peremen.name

academic의 이미지

많이 쓰이는 대표적인 배포판에 대해서는 패키지를 지원했으면 좋겠는데...

몇천만원짜리 소프트웨어인데, 그런 걸 지원하지 않는 걸 보면...

그 소프트웨어의 완성도를 의심하게 되더군요.

--
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.

----
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.

mirheekl의 이미지

저도 SI업체를 잠깐 다녔습니다만..

제가 느끼기로는
어차피 납품 기업별로 다 소스레벨부터 일일이 커스터마이징을 해야 하기때문에
패키징을 하지 않는것 같았습니다.
같은 버전을 여러곳에 설치하지 않는다는 얘깁니다. 죄다 다르다는 거예요. -_-;;
그리고 그 커스터마이징의 범주는 국내에서는 일반적으로 환경설정 등으로 커버할 수 있는 범위를 벗어납니다.

패키지 갖다주면 해당 사이트의 관리자가 직접 설치하고 필요한 것만 설정해서 쓰면 참 좋은데
보통 갑의 입장에선 그런 걸 만지기를 싫어합니다. 관심도 없고요.
또 주력으로 납품하는 프로그램인데도 불구하고 핵심기능에 가까운 부분까지 일일이 자신의 회사에 맞게 변경하기를 원합니다.
이렇게 되면 패키징을 할 이유가 없어지는 거지요..
아니, 오히려 패키징 해서 갖다주면 더 안 좋아합니다. 귀찮다고...
세팅은 물론 관리까지 다 해주기를 원하죠.

커스터마이징을 하지 않는데 패키지가 없다면 좀 다른 문제이지만 (물론 이런 곳은 거의 없을 듯)
전형적인 한국식 SI업체인데 패키징까지 요구하시면.. 말단 분들만 죽어날거예요 아마.

여튼 확실하게 하고 싶으시면 계약단계에서 그부분을 명시하시면 되지 않을까 합니다. 그러면 주겠지요..

--
This is for you new people. I have just one rule :
Everyone fights, no one quits. If you don't do your job, I'll shoot you myself. Do you get me?

--

preisner의 이미지

저 그지 같은 커스트마이징 요구 가 우리나라 소프트웨어 발전을 막는 요소 중 하나 입니다.
(몇년전에 안철수씨가 이 이야기를 하셨던 것으로 기억 되는데요.)
납품 조건으로 커스트마이징 요구가 붙는 경우가 많아 솔루션 납품이 SI 프로젝트가 되는 일이 아주 많이 생기죠.
그리고 솔루션 납품 자체가 SI 프로젝트에 끼워 들어가는 경우도 많아 더 그렇습니다.
힘없고 돈없는 솔루션 업체는 울며겨자 먹기로 요구를 들어 줘야 하고,
소스는 개판 되어가고,
개발 인력은 떠나고,
완성도는 떨어지고,
또 어쩔수 없이 납품하기 위해 무리한 요구를 수용하고,
소스는 개판 되어 가고...
이런 악순환이 반복되게 되죠.
그러다 보니 패키징은 커녕 버전 관리도 제대로 안되는게 현실 입니다.

이런 산업 구조에 대해 많은 분들이 개선을 요구 하고 있습니다만, 별로 나아지지 않고 있습니다.

저 같은 경우는 처음 프로젝트 시작 할때 요구사항에 함께 넣었습니다.
운영시스템에서 테스트 할 생각은 꿈도 꾸지 마시라.
패키지는 어렵다 해도 설치, 운영에 대한 정확한 문서를 첨부 해라.

pinebud의 이미지

지나친 비약인 것 같기도 합니다만 우리나라 사람들의 특성인 것 같기도 합니다. 대게의 경우 원칙보다는 해결이 우선이죠. 영어공부보다는 토익공부를 하고 자바 공부보다는 SCJP 덤프를 외우는 쪽이 일단은 대세인 것 같습니다. 한번 제대로 해놓으면 저절로 없어지는 일도 많은데두요..

A rose is a rose is a rose..