조엘 스폴스키는 더 나은 소프트웨어를 만들기 위한 12 단계에서 첫번째 “Source Control(소스 컨트롤)을 사용하십니까?”을 화두로 던졌습니다. 이 12가지 질문은 진정한 소프트웨어 개발 회사 인지를 검증하는 잣대로 유명합니다. 만약 취업 중인 개발자라면 인터뷰 시 꼭 던져야 하는 중요한 질문입니다.
대부분 SW 개발 회사라면 당연히 소스 콘트롤을 사용하고 있을 것이고, 저는 좀 더 나아가 다른 질문을 던지고 싶습니다. 여러분의 회사에서는 내부의 다른 개발팀이 만드는 소스 코드를 보실 수 있나요? 아니면 보안이라는 명분으로 서로 꽁꽁 감춰 놓고 있으신가요? 개발자들은 소스 코드를 읽고, 리뷰하고 수정해 주는 일련의 과정을 거쳐 성장합니다. 따라서, 외부 오픈 소스로 공개해서 개발하는 것 까지는 아니어도 회사 내부 소스를 공유하는 것은 매우 중요한 개발 문화입니다.
개발 문화의 이면에 대한 세번째는 바로 “사내 소스 공유 문화”에 대한 것입니다. 기업내 오픈소스 개발 방식 도입記에서 밝힌 대로, 2004년 Daum에 입사 했을 때 회사 개발 프로세스 상 몇 가지 문제점이 있었습니다. 가장 대표적인 것이 소스 코드를 개별 팀이 각각 관리하고 있었을 뿐 아니라 각자 CVS, 서브버전, 소스세이프 등 다양한 소스 콘트롤을 사용하고 있었습니다.
■ 소스 코드, 우선 통합하라!
각 팀이 테스트 서버나 팀내 로컬 서버에 소스 코드를 모아 두니, 가끔 팀 별로 코드 배포 안정성에 문제가 되더군요. 뿐만 아니라, 특정 서비스가 중단되었는데 조직 개편으로 팀이 분리된 경우, 중간에 소스 코드들이 사라지는 경우가 있었습니다. 당시 소스 코드는 연구 개발 결과물로 취급하고 있어서, 이게 사라지면 회계 감사가 나왔을 때 매우 난처한 경우가 생기게 됩니다. (과거 다음은 시도 때도 없이 국세청 감사를 받았던 것으로 유명하죠.)
그래서, 2005년 말에 ‘전사 소스 콘트롤 통합 및 저장소 일원화’라는 프로젝트를 맡아 하게 되었습니다. 당시 막 인기를 끌고 있던 서브버전을 선택하고, 이를 전사 인증 연동, 권한 및 리비전 관리 등의 관리 시스템을 구축하였습니다. 개별 개발팀 입장에서는 잘 쓰고 있는데, 소스 코드 이전이라는 귀찮은 일이 생기니 많은 반대에 부딪혔습니다.
2005년 Daum 전사 소스 코드 통합 저장소- 무료 10년간 운영했던 레거시(?) 시스템
특히, 당시 서브버전이 이클립스 플러그인과 연동 시 안정성 등 많은 이슈가 있어서 어려움이 많았습니다. 직접 찾아가서 문제를 해결해 주는 방법으로 다행히 수백 개나 되는 전사 소스 코드가 한 자리로 모일 수 있었습니다. 만약 아직도 회사 내 소스 코드가 한 군데 모여있지 않고, 이를 관리하는 팀이 없다면 회계 감사를 위한 산출물 관리라는 명분을 내세워서라도 꼭 해야 합니다.
■ 진정한 개발 문화는 작은 것에서 시작된다
제가 그 프로젝트에서 진정 원했던 것은 회사 내 오픈 소스 문화가 자연스럽게 정착되는 것이었습니다. 그래서 모든 개발자들이 전체 개별 레포지터리에 읽기 권한을 주는 정책을 시행하려고 했습니다. 이 역시 반대에 부딪혔죠. 명분은 중요 소스 코드가 유출된 다는 게 이유였는데, 그 이면에는 우리 팀 코드를 남들이 보게 하고 싶지 않다는 측면이 강했습니다.
유출이 우려되는 소스(검색 엔진, 광고 서버 등)는 몇 개 정해서 제외하면 될 것인데도 말이죠. 결국, 사내 공통 라이브러리에 해당하는 소스 코드만 화이트리스트(whitelist)로 공개하고, 디폴트로 공유가 안되도록 운영이 되고 말았습니다.
기회가 있을 때 마다(CTO가 바뀔 때) 이 부분을 건의했지만 쉽게 관철되지 않았습니다. CTO의 공통적인 고민을 해결해 줄 수 있는 방법인데 말입니다. 즉, 개발자의 경력 관리 문제입니다. 조직이 커지면서 시니어 엔지니어는 큰 고민에 빠집니다. 관리자가 될지 개발자로 계속 남을지… 이들이 존경 받는 사내 아키텍트로 경력을 이어나가 다른 팀 소스 코드를 리뷰할 수 있는 구조로 바뀌어야 합니다. 그럴려면, 우선 소스 코드를 서로 공유하고 리뷰하는 문화는 필수적 입니다. 백발이 될 때까지 개발하고 싶다, 그렇게 만들어주겠다 이야기만 하지 그에 필요한 문화 요소는 간과하는 것이 현실입니다.
2011년이 지나 Github이 인기를 끌면서 Daum 사내에서도 Git 사용에 대한 욕구가 분출됐고, 한 용감한(?) 개발팀장이 Git 레포지터리 서비스를 직접 개발해서 사내 공유를 하게 됩니다. 일명 “Digit”이라고 불리는 이 비공식 레포지터리는 디폴트로 소스 코드가 오픈 되어 있고 (물론 원하는 경우, private으로 변경 가능) 많은 개발자들이 개인 프로젝트를 사내 SVN 저장소가 아닌 이곳으로 이동을 하기 시작했습니다. (DevOn2013에서 발표한, 사내 Git 저장소 개발 사례 발표 자료 참고)
‘개발 소스쫌 까면 안되나요?’라는 도발적 제목의 Digit 운영 후기(2013)
■ 개발자라면 누구나 공유하고 싶다
사내 공식 기술 에셋팀의 안정적인 지원을 못 받는 비공식 소스 콘트롤임에도 불구하고, 폭발적인 인기로 천여개가 넘는 레포지터리가 생성되었습니다. 개발자들 사이 서로 어떤 코드를 커밋 하는 지 볼 수 있으니 가끔 수동 Pull Request를 통해 도움을 주는 일도 생기고, 회사 내 재미있는 협업 프로젝트(사내 마이피플 봇 서비스) 같은 것도 생기고 팀과 상관 없이 함께 코드를 만드는 재미를 느끼기도 했습니다. 아마 모르긴 해도 팀장들만 싫었던 거지 개발자들은 다들 소스 코드를 공유하고 싶었을 것입니다.
이러한 변화를 일으킨 장본인은 후기에서 다음과 같이 회고합니다.
새로운 변화를 원하지 않는 사람, 기존 시스템을 지원하는 팀과의 갈등, 그리고 장애 나면 처리해야 하는 압박이 있었다. 하지만, 변화를 일으키기 위해서는, 누군가 어려운 일 맡아야 하는데 내가 해도 안될 거라는 자기 합리화를 벗어나 능동적인 행동을 통해 실체를 드러내면 스스로 무엇을 원했는지, 의견이 없던 사람들도 자신이 원했던 것을 알게 된다…
개인이 만들었던 Digit은 회사 내부에 잘 정착을 했고, 제가 퇴사할 2014년 무렵 전사 소스 콘트롤을 Github Enterprise로 변경하는 결정을 하면서, 명예롭게 은퇴하게 됩니다. 지금도 레포지터리를 공유하고 서로의 소스 코드를 보면서 배울 수 있는지는 모르겠지만 멋진 개발자 문화의 한편이었다고 생각합니다.
제발 보안을 핑계로 아니면 조직 이기심으로 회사 내부에서 자유롭게 공유되어야 할 소스 코드를 꼭꼭 숨기지 마시기 바랍니다. 결국 직원을 잠재적 범죄자로 인식하는 불신의 행태는 적어도 현대적 개발 프로세스와는 전혀 맞지 않고, 결국 사내 개발 문화를 병들게 할 것입니다. 또한, 사내 개발자간 협업과 소통 그리고, (네번째 글에서) 소개할 좋은 라이브러리 및 모범 사례의 확산을 막게 됩니다. 개발 경험을 중요시 하는 개발자의 경력 개발 문제에도 가장 중요한 첫 출발입니다.
여러분의 회사는 어떠신가요? 사내 소스 코드를 모아서 공유하는 문화를 만들어가고 계신가요?
연재 목차
- 훌륭한 개발 문화의 이면(1) – 코딩 테스트인터뷰 제대로 하기
- 훌륭한 개발 문화의 이면(2) – 자율적 개발 환경을 선택하라!
- 훌륭한 개발 문화의 이면(3) – 다른 팀 소스 코드를 볼 수 있는가?
- 훌륭한 개발 문화의 이면(4) – 사내 라이브러리를 잘 관리하려면?
- 훌륭한 개발 문화의 이면(5) – 소통 비용의 절약 – 서로 API로 말하자
- 훌륭한 개발 문화의 이면(6) – 입사하고픈 회사를 위한 오픈 전략 구사하기
- 훌륭한 개발 문화의 이면(7) – 잉여력이냐 vs. 효율성이냐
※ Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. 본 채널은 광고를 비롯 어떠한 수익도 창출하지 않습니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources. This channel does not monetize via any advertising.)
좋은 글 잘 보고 있습니다
S사에서 못 봤죠.
정식으로 공문도 보내고 협력 요청도 자주 갔는데 싫다더라고요. “획기적으로 개선할 수 있다, 싫은 게 어딨냐” 했더니 직접 개선하겠다고 따로 프로젝트 등록 하더라고요. 그러고는 아무 것도 안 했어요….
큰 이미지에서 이미지 안에 있는 오브젝트들 테두리(contour) 따서 그걸로 오브젝트를 판별하고 유사한 것끼리 분류하는 거였는데,
기존 프로덕트도 사용자도 있으니 확대 하겠다 한 거거든요….
디폴트로 접근은 못해도 그 정도 협조 요청은 받아주는게 좋을 텐데… ㅠㅠ (역시 최근 개발 프로세스 혁신 하겠다는 이유가 있나 봅니다.)
안 좋은 기억을 바탕으로 한 사례만 말씀드린 듯 합니다…. 이젠 남들 보다 상황을 더 잘 아는 사람이 되었으니 그런 기업 문화를 방지하기 위해 어느 부분을 주의해야 하는지 알 것 같습니다.
인사 고과와 부서 전배자 받는 것은 전원 합의에 의한 평가가 되고, 밀실 정치에 의한 평가가 되지 않아야 방지할 수 있다고 봅니다.
기업 내부적인 오픈 소스는 정당합니다. 다만 오픈 플랫폼 적용은 효율을 살펴 강요가 아닌 선택에 의한 자발성이 중시되어야 하겠고요. 둘을 반대로 적용하는 기업도 많거든요.
공유와 상호검증 협동이라는 것을 통제라는 이유의 보안으로 감추고 있지 않은 지를 잘 봐야한다
보안은 프로세스 보안이 되어야지 간접정보 자체의 보안이 되어서는 안된다
여기서 소스코드가 오픈되면 자신의 부족한 부분을 피드백 받을 수 있고 보안이 고려되지 않은 부분에 대한 검토를 다양한 사람에게 받을 수 있어 오히려 보안이 강화된다
그렇게 상호 검증된 코드를 운영서버에 올릴 때 그 때 프로세스 적으로 개발보안을 하면 되는거다
사실… 이걸 못하는 이유는 한국의 산업이면에 독특한 문화적 요소가 있는데 서로간 신뢰 부족으로 소통이 어렵고 외부에 과시하는 경향과 함께 자신의 것을 드러내는 것을 피해로만 생각하는 경향이 있어 소프트웨어 뿐만 아니라 다른 장인들도 자신의 정보를 공개하지 않는다 그런데 실제 까보면 그다지 높은 기술이 아니거나 폐쇄적인 자신의 습성 때문에 구식인 경우가 많다
스스로 발전하지 않는자 그리고 다양한 소통과 피드백을 불이익 요소로 만든 조직 과도하 경쟁으로 신뢰하지 않는 모습 이것들애 모여 사소한 절차마저 어렵게하고 보안 뿐만 아니라 모든 일에 장애를 겪게 만드는 이유며 당연히 이에 따른 책임은 경영진에게 있다
저도 사내에서 공개해야 한다는 입장인데
공개를 하더라도 실제로 몇명이외에 남의 팀 소스를 보는 사람이 많지는 않습니다
하지만 문제가 있을때 손쉽게 남의 코드에 접근할 수 있냐는 그래서 볼 수 있느냐는 대응에 큰 차이를 만들어 줄 수 있는…
너무나 공감이 되어 댓글 남깁니다.
예전 2005~2006년경 [웹표준], [오픈웹] 이슈 관련하여 윤석찬님 블로그를 꾸준히 구독하고 있었는데 페북에서 또 이렇게 좋은 포스팅을 접하게 되어 반갑기도 합니다.
제가 작성한 코드가 남에게 공개되는 것이 초년생일 때에는 제가 손해보는 것 같고, 제 결과물을 통해 다른 경쟁자들에게 사내정치에서 밀릴 수 있다는 불안감이 있었습니다.
하지만 지나고 나니 그게 아니더라고요. 개발자에 있어서 코드 공유와 리뷰 문화가 얼마나 중요한지 최근에 새삼 깨닫고 있습니다. 모두가 투명해지고 소통하는 문화만이 긍정적인 시너지를 발휘 할 수 있다는 점에 무척 공감합니다.
매번 좋은 글 감사합니다^^
흥미있게 보고 있는 시리즈이고 느끼는 바가 있어서 저희 팀에도 몇가지 적용하고 있습니다. 나머지 글들도 시간되시면 부탁드려요.. 현기증 납니다ㅋ
좋은 글 감사합니다. 평소 생각치 못했던 내용들을 접할 수 있어서 좋습니다.
너무 좋은 연재 글 잘 읽었습니다. 사내에 공유문화를 만들려고 노력했었는데 안타깝게도 제가 그 당시는 체력이 다해서 같이 해보자고 첫발만 내딛고 흐지무지했었던 적이 있었습니다. 잘 사용하는 것도 필요한 것을 만들어 달라고 요구하는 것도 참여라고 했었는데, 까먹고 있었는데 너무 좋은 글에 다시 되새김하네요. 그 당시 실패를 교훈 삼아 재도전 해볼 생각입니다.