새로운 기술/라이브러리/개발방법론/시스템을 도입해 보신 분?

kyagrd의 이미지

회사에서 3년 정도 FreeBSD 플랫폼에서 주로 개발을 하고 있습니다. 업무에서만 프비를 쓰다보니 프비보다는 리눅스가 더 익숙하고 정이 갑니다.

간단하고 당연한 것 같아 보이는 것도 도입하는 것이 너무나 어렵습니다. 현업에서 거창한 개발방법론이나 라이브러리 같은 걸 도입하는 것은 아예 공감대도 이루어질 기미도 없고 저도 경험이 부족하므로 쉽게 할 수도 없는 일 같지만, 그래도 버전관리툴은 당연히 도입해야 하는 것 아닌가 생각해서 작년에 시도를 좀 해보긴 했습니다. 윈도우 개발자들은 소스세이프 같은 것도 쓰고 해서 라이브러리를 공유하고 있는데 오히려 유닉스 개발자들은 코드를 통째로 복사해서 고쳐 씁니다. 이렇게 되다 보니 이 프로젝트에서 만들었던 것을 다른 쪽에 도입하려 하면 거의 비슷한 것인데도 주르륵 컴파일 안되고 쪽나고 노가다로 하나하나 고쳐야 하는 일이 발생하게 됩니다.

팀내에서 스터티들 해보기도 하고 같이 써 보자고 했지만 막상 CVS 나 GNU Autotools 를 실제로 쓰자고 하면 제안한 사람이 확인을 안하면 commit 을 안한다든가 이렇게 되고 말아 버리더군요. 그래도 저 자신이라도 버전관리에 익숙해지고 장점을 활용할 줄 알게 되었다는 성과 말고는 크게 거둔 것이 없는 것 같습니다. core 라이브러리를 관리하고 패치 배포하고 하는 팀이 있어야 하는데 ...

버전이나 소스관리는 물론 어떤 새로운 기술/라이브러리/개발방법론 등 바람직한 아이디어나 모델을 성공적으로 도입해 보신 사례가 있는 분들의 수기를 좀 부탁드립니다. 이건 뭐 이론과 현실 사이의 괴리가 문제가 아니라 현실적인 필요성과 해결책이 분명히 있음에도 도입을 못하고 있는 현실은 어떤 식으로 개선되는지 보고 싶습니다. 좀 속시원한 사례가 있으면 어떻게 성공하셨는지 경험을 공유해 주시면 정말 감사하겠습니다.

@ 제일 윗사람이 지시를 내리는 수밖에 없나요?
@ 도입 초기의 단기적인 귀찮음과 비효율이라는 장벽을 뛰어넘어 도약을 이루어 보신 분들 있으면 성공담을 듣고 좀 사람들이 희망을 가질 수 있도록요. KLDP 매거진 같은 데 그런 내용이 있어도 좋겠네요.

ed.netdiver의 이미지

http://korean.joelonsoftware.com/Articles/DailyBuildsAreYourFriend.html

퍼키님 사이트인 http://openlook.org 에서 소개되어 알게된 사이트입니다.

주옥같은 글들이 아주 재밌게 올라와있군요.

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

beta의 이미지

여기에 몇가지 수기가 있어서 알려드립니다.

http://xper.org/wiki/xp/

가뷔쥐와는 사뭇 다른느낌이시네요. ^^;

발 담갔다. 이제 익숙해 지는길만이..

ddoman의 이미지

kyagrd wrote:
윈도우 개발자들은 소스세이프 같은 것도 쓰고 해서 라이브러리를 공유하고 있는데 오히려 유닉스 개발자들은 코드를 통째로 복사해서 고쳐 씁니다. 이렇게 되다 보니 이 프로젝트에서 만들었던 것을 다른 쪽에 도입하려 하면 거의 비슷한 것인데도 주르륵 컴파일 안되고 쪽나고 노가다로 하나하나 고쳐야 하는 일이 발생하게 됩니다.

팀내에서 스터티들 해보기도 하고 같이 써 보자고 했지만 막상 CVS 나 GNU Autotools 를 실제로 쓰자고 하면 제안한 사람이 확인을 안하면 commit 을 안한다든가 이렇게 되고 말아 버리더군요. 그래도 저 자신이라도 버전관리에 익숙해지고 장점을 활용할 줄 알게 되었다는 성과 말고는 크게 거둔 것이 없는 것 같습니다. core 라이브러리를 관리하고 패치 배포하고 하는 팀이 있어야 하는데 ...

CVS나 VSS같은걸 안쓰고 공동작업이 되나요?
한 프로젝트를 여러명이서 작업할때 소스 공유툴을 쓰지않는다는건 엄청나게 비효율적이라고 생각합니다.

저의 경우는 버젼관리의 의미보다 소스 싱크의 의미가 큽니다.

가령 전형적인 서버와 클라이언트의 소스코드의 경우
두개가 공통적인 코드를 쓰는경우가 많습니다.

최소한 둘이 통신하는 코드는 서버와 클라가 같이 쓰고( 최소한 에러코드 정의해놓은 헤더파일 정도는 무조건 같이 써야겠죠? )

나머지 부분은 서버, 클라가 각 맞게 쓰고...

위와 같은 상황이 너무나 일반적인 경우라고 생각하는데 이럴경우 클라개발자랑 서버개발자의 소스가 싱크가 안되면 일일이 메신저로 나를수도 없고 엄청 불편할것 같네요.

이런것은 전혀 새로운 개발방법론도 아니고
공동작업에서 당연히 써야하는 부분인거 같네요.

ed.netdiver의 이미지

Quote:

CVS나 VSS같은걸 안쓰고 공동작업이 되나요?
한 프로젝트를 여러명이서 작업할때 소스 공유툴을 쓰지않는다는건 엄청나게 비효율적이라고 생각합니다.

비효율적인데, 그래도 그렇게 하는데들 많더군요.
특히 window base 소규모 회사들의 경우는 아예 winmerge나
beyond compare로 각자 알아서 하는 경우가 비일비재하고,
쪼끔 나은 경우가 팀장이나 누구 한사람을 할당해서
소스 머지및 빌드를 도맡게 하고, 그럴때마다
팀원들한테서 수정한 소스를 취합하곤 하죠.
단순한게 가장 확실하다는 나름대로의 철학(?)도 있다보니,
더 단순한 cvs 사용같은건 아예 생각도 안합니다.

또 나름의 이유를 다는것중엔, 대개 이런 회사들의 경우 SI쪽이라
다들 뿔뿔이 흩어져 외근나가 있는데, 섭 접속이 안되는 곳에서의
작업이 며칠씩 떨어진채 이루어져 있다보면,
천삽뜨고 허리펴기운동이 눈에 보이는데도, 어쩔수없이
그러는데도 있구요.

특히나 책임자가 그런 개발방식에 익숙해져 있으면,
똑같이 답습밖에는 수가 없는 암울함이 계속...ㅠ.ㅠ;

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

totohero의 이미지

제가 있던 곳도 주먹구구식으로 소스를 관리했었는데, 그로 인해 문제가 터질 때 마다 CVS 쓰면 이런 일 없다고 팀원들(특히 팀장)에게 볼멘소리 한 끝에 공감을 얻어내었습니다. 그 많이 널려 있는 CVS 문서 찾아 보기 귀찮으실까봐 다시 또 간추린 문서 만들어 읽히고 CVS 관리를 직접 하겠다고 나섰구요. 처음엔 변화를 싫어하던 사람들도 CVStrac 같은 악세사리 설치하고 color diff 플러그인도 넣어 사용하게 해주었더니 좋아하더군요. 아무튼 처음엔 귀찮지만 적극적으로 한번 나서서 굳은 일을 도맡아보시기 바랍니다. 나중엔 보람을 느끼실 겁니다.

kwon37xi의 이미지

totohero wrote:
제가 있던 곳도 주먹구구식으로 소스를 관리했었는데, 그로 인해 문제가 터질 때 마다 CVS 쓰면 이런 일 없다고 팀원들(특히 팀장)에게 볼멘소리 한 끝에 공감을 얻어내었습니다.

저도 비슷합니다.

제가 막내이고해서 거의 제 말이 안 먹혀들었는데, 소스 덮어 쓰고 그런일이 생길때마다 CVS 의 편리함을 강조하고, CVS 문서 잘 정리해서 보여주고 계속 그랬습니다. (그 CVS관련 문서 정리한 흔적이 KLDP 어딘가에 있습니다..)

그랬더니 거의 4개월 정도 지나서 팀내의 오피니언 리더격(팀장이 아니라, 뭔가 팀내에 말빨이 잘먹히는 그런 사람있죠?) 되는 사람이 함 써보자! 해서 제가 교육하고 Eclipse도 그때 도입하고, System.out으로 찍던 로그도 Log4J 쓰게 하고 해서 한 번만 해보자 했더니..

지금은.. CVS없으면 아무도 개발 안 하려들 정도 입니다.

막내라서 새로운걸 하자고 제안하기가 어렵고, 해도 먹히지도 않고 그럴때가 많은데요, 마구잡이로 밀어붙이면 역효과만 나는 거 같구요, 사람들이 잘못된 개발 방법 때문에 짜증이 올라 있을 때(그러면서도 개선 의지 같은건 없거나 어떻게 개선해야 하는지 모르거나..) 그럴 때 오피니언 리더격인 사람하고 친하게 지내면서 "이렇게 하면 더 좋아..." 하고 구슬리고 직접 기회 될 때마다 그 효용성을 시연해서 보여주면 역효과 없이 먹히는 거 같아요..

그런식으로 CVS, Ant, Eclipse, Logger 등을 도입했습니다.

이번엔... Struts를 도입시킬려고 하는데, 이게 넘 어려워서 진입장벽이 클것 같습니다... --;

최종 도입 목표는 XP...

--
사족..
생각해 보니, 스스로 오피니언 리더가 되는게 제일 좋은 거군요... ^^;
근데 사람 성격이 말처럼 잘 되진 않죠.. ^^;

소타의 이미지

CVS로 개발팀전체의 소스를 관리하고 있습니다..
디자인팀이나 파일서버 전체 관리도 CVS로 전환하려고 생각중인데 =_=;; 이건 너무 엄한 짓일까요? -_-;
그리고 최근 서버 개발쪽 프레임웍으로 APR을 도입했습니다..
9개의 서버 플그램 중에 1개를 포팅 완료 했는데 두말할 나위없이 좋군요 -.- 지금 하나 더 포팅중인데 다른 외부 라이브러리(gd2, pgsql(libpq), sqlite)들이 제각각이다 보니 애로사항이 없잖아 있네요..
저희 회사는 실험적인걸 많이 하는 편인데 대부분 긍정적으로 받아들이고 도입하기 위해 노력합니다.
내부 그룹웨어로는 moregroupware를 전직원이 쓰고 있고 개발문서나 메모는 모니위키를 쓰고 파일서버는 삼바로 하나 잡아서 전직원이 Z드라이브로 잡아서 잘 쓰고 있습니다..
개발팀에서는 XP를 점차적으로 도입중인데 -.- 작년 가을쯤에 PP를 시작으루다.. PP가 효과가 좋긴 좋더군요 =_=;; 방금도 둘이 한 컴퓨터에서 플그래밍을..

비행소년의 이미지

대단들 하시군요.

디버깅이라곤 printf와 afxmessagebox만 쓰는 사람들에게 VC IDE 디버거 쓰게 만드는데도 힘들어서 포기 했습니다. :evil:

subversion의 장점과 사용법을 열심히 설명 했더니, 어려워서 싫다더군요. 편한건 그냥 나 혼자 쓰자 그러고 있습니다.

높이 날다 떨어지면.
아푸다 ㅡ,.ㅡ

wowcode의 이미지

저희는 Subversion,VSS,CVS 세가지나 씁니다..

쩝..

처음에는 VSS로 되어 있던것을 유닉스로 포팅하면서 제가 Subversion으로 옮겼구요.

그후 Netbeans 쓰시는 분이 오셔서 Subversion이 Netbeans랑 연동이 잘 안되다고 CVS를 쓰시 더군요.

이것 저것 많이 쓰는 것도 않좋습니다...쩝...

VSS로 되어있던 소스를 Subversion으로 옮겨 달랬더니 못 옮기고 퇴사해 버렸네요... 몇일전 VSS에 있던 5000 line 짜리 평션보고 기겁 했더랬습니다.

ed.netdiver의 이미지

wowcode wrote:
VSS로 되어있던 소스를 Subversion으로 옮겨 달랬더니 못 옮기고 퇴사해 버렸네요

어라, 셋다 export기능 있지 않나요?

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

wowcode의 이미지

qed wrote:
wowcode wrote:
VSS로 되어있던 소스를 Subversion으로 옮겨 달랬더니 못 옮기고 퇴사해 버렸네요

어라, 셋다 export기능 있지 않나요?

VSS에서 지원하는 LINK 기능을 썼더군요. 소스를 export해 봤더니 같은 파일이 하도 많이 생겨서 어떻게 작업이 안되겠던 모양이예요.

kwon37xi의 이미지

아직은 가장 많은 클라이언트가 지원되는 CVS가 제일 나은 것 같습니다.
Subversion이 얼마나 좋은지는 모르는데요(사실 CVS에 충분히 만족하고 사실상 불편을 못 느끼기 때문에 아지 알아볼 생각도 않고 있습니다. ^^),

제일 중요한건 개발자들이 사용하기 편한 클라이언트가 있어야 한다는 건데,
아직 서브 버전은 그게 딸립니다.

특히 제가 자바 개발자인데, 이클립스나 넷빈즈 혹은 다른 통합 개발환경이 아직 서브버전을 제대로 지원하지 않아서 고려 대상에서 제외한 상태입니다.

이클립스가 서브버전을 CVS처럼 디폴트 지원하는 때가 온다면 그때 서브 버전으로 바꾸기위해 준비를 시작할 것 같네요.

근데, 서브버전이 그렇게 좋은가요?

jj의 이미지

서브버젼이 많이 안정화 됐나요?

--
Life is short. damn short...

죠커의 이미지

qed wrote:
http://korean.joelonsoftware.com/Articles/DailyBuildsAreYourFriend.html

퍼키님 사이트인 http://openlook.org 에서 소개되어 알게된 사이트입니다.

주옥같은 글들이 아주 재밌게 올라와있군요.

LISP의 REP이군요 !!! :)

wowcode의 이미지

jj wrote:
서브버젼이 많이 안정화 됐나요?

예전에 가끔 어떤 분들은 DB가 깨지기도 했다는데 저는 전혀 그런적이 없었습니다. 가끔 다른 사람들이 사용 방법이 익숙하지 않아서 약간의 문제가 생겼던 적은 있지만 CVS도 마찬 가지 겠죠.

개인적으로 전 Subversion이 revision 방식이라든지 그런 면에서 훨신 맘에 듭니다.

sangwoo의 이미지

wowcode wrote:
jj wrote:
서브버젼이 많이 안정화 됐나요?

예전에 가끔 어떤 분들은 DB가 깨지기도 했다는데 저는 전혀 그런적이 없었습니다. 가끔 다른 사람들이 사용 방법이 익숙하지 않아서 약간의 문제가 생겼던 적은 있지만 CVS도 마찬 가지 겠죠.

개인적으로 전 Subversion이 revision 방식이라든지 그런 면에서 훨신 맘에 듭니다.


버클리 db가 유일한 백엔드였던 시절에는 여러 사용자가 동시에
커밋할때 깨진다는 리포트가 많았죠. 버전 1.1이후 백엔드를 버클리db
뿐 아니라, 파일 기반의 fsfs로 선택할 수도 있게 되었는데, 그 이후로는
아주 안정적입니다.
사용 편의성은.. CVS와는 비교할 수 없죠. :) 딴건 몰라도, 1)브랜칭이
정말 간편하고 쉽고. 2)커밋의 단위가 한 파일이 아니고 한 작업이기
때문에 나중에 트레이스 하기가 좋습니다. (CVS로 말하자면,
커밋당 tag를 하는 효과죠.)
맛들이면 subversion에서 빠져나오시기 힘드실 겁니다.

----
Let's shut up and code.

ssggkim의 이미지

sangwoo wrote:
버클리 db가 유일한 백엔드였던 시절에는 여러 사용자가 동시에
커밋할때 깨진다는 리포트가 많았죠. 버전 1.1이후 백엔드를 버클리db
뿐 아니라, 파일 기반의 fsfs로 선택할 수도 있게 되었는데, 그 이후로는
아주 안정적입니다.

전적으로 동의합니다. 예전 버클리 db기반에서는 하루에 한번이상 깨지던 것이 fsfs로 바꾸고 나서는 한번도 문제를 일으킨 적이 없네요.

저는 처음부터 subversion을 써와서 cvs와의 비교는 뭐하지만, 이왕 도입하신다면 subversion을 추천드립니다.