오픈소스의 사용은 더 많은 관리적 포인트가 발생한다.

몇 일 전 이전에 만들었던 프로젝트의 문제를 해결하기 위해 해당 프로젝트를 열었다.
일단 문제가 된 녀석을 업그레이드하고 변경된 API가 있다면 변경하고 끝내자란 계획을 세우고 디버깅을 시작했다.

어라? 어랏?!
해당 라이브러리를 업데이트할려니 iOS의 오픈 소스를 쉽게(?) 관리할 수 있게 해준다는 CocoaPods 버전이 낮다고 업데이트하란다.
그래서 업데이트했다.
다시금 해당 라이브러리에 대한 업데이트 시도.
의존성 체크를 한다는 메시지를 보고 설치되는 동안 페이스북을 좀 둘러봤다.
이제 됐겠지? 하며 다시 터미널로 돌아갔더니 아직도 체크 중.. 뭔가 이상하다..

현재 최신 버전과 기 사용된 버전 차이가 너무 심해서 그런가 싶어 수동으로 업데이트했다.
자~ 이 제 변경된 API만 수정하면 되겠지? 는 이내 몇 시간에 걸친 사투가 되었다.

문제는 해당 프로젝트에 사용된 다른 오픈 소스들의 문제였다.
iOS는 이미 해당 프로젝트가 생성된지 세 번이나 변경되었다.
그리고 그에 따라서 업데이트된 오픈 소스도 있었지만 그렇지 못한 오픈 소스도 있었고 이 녀석들의 문제였다.

컴파일 에러를 보면서 하나하나 수정하다가
“이딴 식으로 만든 걸 왜 썼지?” 라는 의문이 생기면서 화가 나기 시작했고
“적용은 왜 이딴 식으로 관리가 어렵게 해놨어?!” 그리고 폭발.

단순히 하나의 기능을 위해 사용된 오픈 소스가 무려 3~4개였다.
이들도 모두 엉켜있어 결국 이와 관련된 클래스들 다 프로젝트에서 제외시키고 연결점을 끊었다.
그리고 홧김에 CocoaPods도 날렸다.

또 문제 발생..
빌드를 하면 x86_64 architecture에 대응된 라이브러리가 없다라는 링크에러가 나온다.
(이는 CocoaPods 프로젝트를 삭제하면서 발생된 문제..)
하아… 그냥 답 안나옴….

이 문제를 겪으면서 느낀 점이 제목과 같다.
조금 상세히 서술해보자면,

“지금 당장 편하고자 오픈 소스를 쓰려고 한다면 절대 사용하지 말 것이며, 아무리 작은 요소의 오픈 소스라도 왜 써야하는지 꼭 필요한지 판단을 두 번 이상할 것이며, 해당 오픈 소스의 마스터가 얼마나 해당 오픈 소스를 자주 수정하고 개선하는지도 꼭 살펴보길 바란다. 더불어 자주 프로젝트를 열고 사용한 오픈 소스의 업데이트는 없는지 살펴볼 것이며 업데이트가 있다면 어떤 업데이트가 있었는지도 꼭 읽고 빌드해보길 권장한다. 그리고 개인 프로젝트에서나 이전 프로젝트에서 오랜동안 써본 오픈 소스가 아니라면 더더욱 조심할 것. 이를 간과하는 순간부터는 개발 비용보다 관리 비용이 더 많이 들어갈 수 있다는 건 필자가 겪은 사례 외에도 주변에서도 여러 사례를 통해 접할 수 있을 것이다.”

마지막으로 한 마디 더 하자면,
지금도 오픈 소스의 중요성들을 너도나도 언급하고 있고 나 역시 오픈 소스에 대한 중요성은 높다고 본다.
하지만 내 기술을 오픈 소스로 공개하는 순간부터 당신에게는 책임감이 따르고 지속적으로 follow up 해야하는 의무감이 뒤따르게 된다.
또한, 부디 오픈 소스의 저작권은 당신에게 있더라도 오픈을 한 순간부터 나 혼자 만드는게 아니고 같이 만들어간다는 생각 좀 하자..
그리고 더 이상 지원이 힘들 듯 하면 다른 적극적인 contributor에게 권한을 부여하던가 프로젝트를 넘기던가
그것도 힘들다면 예전의 ASIHTTPRequest의 경우와 같이 공식적으로 프로젝트의 마지막을 공지하던가 무책임하게 방치는 하지말자… 쫌!
아무리 사용에 대해서는 사용하는 사람의 책임이더라도 너무하잖어?!

0 Shares:
댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다

This site uses Akismet to reduce spam. Learn how your comment data is processed.

You May Also Like

디테일의 함정

요즘은 개발에서 디테일이라는 단어가 많이 언급된다. 여기서 디테일이라함은 여러가지 의미가 있을 것이고 아래 요건도 포함될 것이다. 기획이나 디자인이…