소프트웨어 소스 버전 관리 안 하는 IT기업 사례 6개. 신입 조심

소프트웨어 소스 버전 관리 안 하는 IT기업 사례 6개. 신입 조심


지난 2008년에 올라왔던 글인데 원본 링크가 생각나질 않네요. 제보 부탁드리며 무려 10년 전 자료지만 현재에도 유효하다는 생각이 듭니다. 개념 없이 개발하는 회사와 거기서 고생하는 신입 프로그래머들 ... 정말 억울한 조합이기도 합니다.




제가 다니고 있는 회사 얘기인데 여기서 조금만 더 오래 있다가는 『개발자 커리어 말아먹기』 딱 좋겠다는 생각이 듭니다.



소프트웨어 소스 버전 관리 안 하는 IT기업 사례 6개. 신입 조심실용주의 프로그래머 형상관리


1. 소프트웨어 최종 소스는 어디에?

모 프로젝트의 이야기인데 해당 프로젝트의 몇몇 파트 프로그래머들은 최종 소스가 어디 있는지 아무도 모릅니다. 해당 프로젝트가 적용된 서비스에서 장애가 나면 원인을 제대로 찾지 못하고 프로세스를 그냥 죽였다 띄우는 극악무도한 사태가 발생합니다.


■ 소프트웨어 소스 관리가 안 된다는 것은 유지보수도 잘 못 한다는 뜻입니다. 10분 걸릴 일을 10일이 걸릴 수 있다는 의미로 이런 불합리한 사태를 불합리하다 느끼지 못하는 경력자들은 근무 태만입니다. 제대로 된 IT 시스템 관리자가 오면 모두 해고될 겁니다.


압축 파일로 소스 버전 관리코딩만큼 중요한 프로그래밍 기초

2. 압축 파일로 소스 버전 관리

소스관리 방안이 없습니다. tar로 묶어서 소스 서버에 올려놓고 readme 파일에 최종 날짜만 써놓습니다. 회사 내 팀장들이 커미터를 해주는 게 일반적인 모습이라 보이는데 제가 다니는 회사는 팀장이 PM으로 있는 프로젝트의 소스 코드에 대해서도 알지 못합니다.


■ 1번과 마찬가지로 사고방식 제대로 박힌 관리자가 오면 기존 개발자들 모두 해고될 겁니다. 프로그래머가 자신의 소스도 챙기지 못하는 건 프로그래머로서 자격이 없는 겁니다.



소프트웨어 최종 소스는 어디에실용주의 프로그래머 형상관리


3. 중구난방 코딩 스타일

소프트웨어 개발자들의 코딩 스타일이 제각각입니다. 『다른 사람들이 짠 파트를 백업』받게 되면 기존에 백업받은 파트의 소스와 판이하게 다른 코딩 스타일로 인해 소스 보는 데만 해도 엄청난 시간이 걸리더군요. 회사 내 개발자들이 모두 C로 소스를 짜는데 같은 언어로 짜도 어찌나 스타일이 그리 다른지 ... 팀별/팀 내부에서도 개발자별로 코딩 스타일이 다 다릅니다.


특히 세 사람 이상 손 탄 소스들은 해독 불가입니다. 가끔 한 사람이 여러 가지 코딩 스타일을 구사해서, 프로세스마다 한사람이 짰는데도 스타일에 일관성이 없는 프로세스도 존재합니다.


■ 개념이 없는 짓입니다. 어중이떠중이끼리 모여서 쓰레기를 생산하는 겁니다. 저도 경력자지만 저런 식으로 일하는 경력자들 보면 화가 나요. 저 글러 먹은 정신 상태로 IT 분야에서 일하는 거 보면 우리나라 기업 문화가 낙후되었다는 생각에 확신이 들죠.



중구난방 코딩 스타일 프로그래머코딩만큼 중요한 프로그래밍 기초



4. 단위 테스트했다고 욕먹음

얼마 전에 제가 TDD로 개발 진행했다가 TDD를 이해하지 못하는 선임으로부터 욕만 먹었습니다. 왜 무의미한 유닛 단위 테스트를 진행하느냐 ... 다 짜고 돌려보면서 테스트하는 게 정확하다는 게 욕먹은 원인이었습니다.

거기다 왜 C++로 서버 소프트웨어 프로그램을 짜느냐는 욕도 들었습니다. 사실 제가 짠 프로세스 자체가 C로 짜든 C++로 짜든 성능상 차이는 전혀 없는 프로세스이고 프로세스의 기능들이 boost에서 제공하는 여러 라이브러리를 이용해서 작성하면 C를 이용해서 코드를 작성하는 것 보다 일의 양이 확연히 줄어드는데 이해를 못 하더군요.


  • 아무리 설명을 해도 『이해를 못 하는 것인지 안 하려고』 하는 것인지 참 답답했습니다.



소프트웨어 소스 관리 개발자실용주의 프로그래머 형상관리



사실 대형 서버 시스템에 들어가는데 언어를 어떤 것을 쓰느냐는 회사 정책 내지는 개발자의 취향에 따라 결정돼야 한다고 봅니다. 되도록 일을 최대한 덜하고 정확하게 작성할 수 있는 라이브러리들을 제공해주는 언어를 사용해야 한다는 게 제 입장입니다. 프로그래머라면 지향해야죠.


■ 유닛 테스트가 무의미하다는 건 "난 무식한 바보야"라고 알리는 꼴입니다. 정말 무식하고 한심한 짓입니다.


■ 4번은 맹점이 있네요. 가령, 부스트를 쓰건 안쓰건 팀에서 확정하지 않았다면 일단 보류하는 게 맞습니다. 하지만, 1, 2, 3번 꼬락서니를 보니 글 쓴 분도 저런 사람들과 무슨 협의냐며 선을 그은 것 같네요. 이런 경우가 제일 안타깝죠. 서로 마음의 벽을 쌓아서 소통이 안 됩니다.



프로그래머 단위 테스트코딩만큼 중요한 프로그래밍 기초

5. 돈이 없어서 버전 관리 못 한다?

얼마 전 회식 때 팀장 이하 상사들에게 CVS나 SVN과 같은 소스 버전 관리 도구의 도입을 강하게 주장했는데 돌아온 대답은,


"회사에서 그런 걸 운영할만한 서버를 제공해주지 않는다. 현재 장비실에 있는 장비 중 소스 서버와 NAS를 빼고는 언제 밖으로 나갈지 모르는 장비들이라 힘들다." 


얘기 꺼낸 제가 잘못이라는 생각이 들더군요.

■ 이런 걸 "마음속에서 파업했다" 또는 "도전은 불가능하다는 것을 확신한다"라고 표현합니다. 어떤 상황에서 저렇게 프로그래머 경력직들이 포기했나 모르겠군요.



유닛 단위 테스트 프로그래머실용주의 프로그래머 형상관리


6. 전역 변수 신봉

전역변수 신봉자들이 회사 개발자들의 대부분입니다. 가끔 전역변수를 잘못 건드려서 문제가 생기면 찾는데 엄청난 시간을

허비하더군요. 소프트웨어 소스 코드 열어보면 많게는 전역변수를 30개까지 쓴 소스도 보았습니다. 사실 그런 소스 보면서 이거 어떻게 버전 관리해가면서 코드를 작성하나 그런 생각이 듭니다.


저거보다 많은 사례가 있는데 지금 기억나는 건 이 정도이고 입사한 지 한 10달 만에 딱 드는 생각이 이곳에 더 있다가는 커리어 완전히 말아먹겠구나 ... 그런 생각만 듭니다.



개발자 전역 변수 프로그래밍 기초코딩만큼 중요한 프로그래밍 기초



사실 통신업 쪽 SI 업체라 『BMT가 있거나 하면』 기존의 소스 코드를 컴파일해서 해당 사이트나 프로젝트에 맞게끔 커스터마이징을 해서 제품을 내보내는 형태입니다. BMT 한 번 나가거나 BMT 이후 인수 시험 때 코드 변경되는 사항을 관리를 해야 하는데 아무도 그런 시도를 하지 않습니다.


막무가내식으로 『소스코드 버전 관리』가 전혀 이루어지지 않는 회사에 다녀보셨던 분들 계신가요?


솔직히 지금 당장 옮기고 싶어도 병특이라 ... 내년 9월부터나 회사를 옮길 수 있는 형편이라 이런 열악한 환경에서 1년을 더 버텨야 한다는 게 참 괴롭군요.



실용주의 프로그래머 형상관리실용주의 프로그래머 형상관리



■ 개발자가 전역변수 남발한다는 자체가 프로그래밍 기초가 부실하다는 뜻입니다. 부실한 사람이 부실한 코드를 만들었을 뿐이죠. 그리고 팀 단위로 부실한 코드를 만들었다면, 그 팀 자체가 회생 불가능할 정도의 저질이라는 뜻입니다. 위에도 적었지만 제대로 된 IT 담당자 또는 팀장이 오면 몽땅 해고됩니다.


해고해도 부담이 없어요. 왜냐면 소스 관리를 안 하니 어차피 물어봐도 대답할 사람이 없거든요. 그러니 제대로 된 직원 뽑아서 새로 시작하는 게 낫다는 판단을 할 겁니다. 유지보수 개판에 소스 관리도 안 해, 형상관리는 아예 없어, NAS랑 서버도 별도로 관리를 안 해, 그러면 기존 직원에게 물어봐야 돌아오는 대답은 없습니다.


제가 만약 저 회사 팀장으로 임명된다면 기존 직원들은 시간을 두고 모두 해고할 겁니다.


어 소스 버전 관리 안 하는 IT기업 사례 6개. 신입 조심

댓글(0)

Designed by JB FACTORY