훌륭한 개발 문화의 이면(4) – 사내 라이브러리를 잘 관리하려면?

(지난번 연재 3편을 끝내고 너무 오래 쉬었네요. 최근에 예전 회사 OB 모임을 갔다가 이런저런 이야기를 해보면서, 필요한 분이 있으실 것 같아 다시 연재를 시작합니다. 연초에 시간을 많이 투자한 AWS Summit도 끝나서 잠깐의 여유를 찾았네요.)

현업을 하다보면 개발자에게 숙명같은 일들이 있습니다. 반복되는 일을 자동화해야 하거나, 다른 팀과 소통을 하면서 필요한 인터페이스를 구성하거나, 아니면 팀 내에 재사용 가능한 뭔가를 만들어야 하는 때이죠.

이 세 가지는 어떤 식으로 만나게 되고, 이를 위해 개발자 혹은 팀은 다양한 비급(祕笈)을 담은 라이브러리나 프레임워크를 만듭니다. 대부분 오픈 소스로 가져다 쓰는 경우도 많지만, 딱 맞는 기능만 있으면 좋겠는데 너무 무겁거나 사내 기술 표준이나 (인증, 지불, 통계, 모니터링 같은) 내부 시스템과 연동을 위해 인-하우스 솔루션으로 만드는 경우도 많죠.

물론 사내 프레임워크 만들지 말자. (Outsider’s Dev Story)라던가 자신만의 개인 라이브러리 또는 프레임웤이 필요할까 (Sangheon’s Archive)라는 의견도 있습니다만 어느 정도 규모가 되는 회사에 좋은 팀이 꾸려지면, 사실 사내 라이브러리는 필연적으로 만들어집니다.

■ 라이브러리는 생산성에 큰 영향을 끼친다
자신의 노하우를 가진 라이브러리 몇 개쯤은 가지고 있어야 신규 개발할 때 편하듯, 회사에서도 팀 생산성을 위해 필요해집니다. 먼저 이런일을 누가 할거냐 하느게 개발팀의 숙제죠. 많은 개발자가 게을러 터져서 자동화나 최적화를 잘 했으면 하는데 꼭 그렇지만도 않더라구요. 어떤 사람은 성실하게(?) 코딩하는 분도 계시고, 새로운 것만 좋은 개발자도 있게 마련이죠.

그래서 대개 한 두 사람에게 이런 일이 가게 마련입니다. 아니, 그런 사람들이 이런 일을 벌리죠. “얼마 전 캐싱 이슈가 있었는데, 어제 시간이 남아서 간단하게 만들어 봤어요.” 하면서 팀 회의에 짜잔 하면서 내놓는 천재 개발자입니다. 사실 써보니 또 좋아요… 그러면 계속 그 사람들에게 동기 부여가 되고, 전체적인 팀 생산성은 높아집니다. 따라서, 꼭 팀에 이런 분들이 한두분 있어야 하구요. 자신도 그렇게 되도록 노력하는게 꼭 필요합니다.

■ 팀을 넘어서 회사로
그런데, 이게 회사 차원으로 옮겨가면 이야기가 좀 달라집니다. 많은 개발팀들이 개별적으로 만든 라이브러리나 프레임워크 혹은 전사로 쓸 수 있는 서비스를 팀내에서만 아니라 다른 팀도 쓰면 좋겠다고 홍보를 하는 것이죠. 사내 세미나를 열기도 하고, 개발 본부 내에서 공유도 합니다.

예를 들어, 대용량 트래픽을 감당해야 하는 팀은 DB Pool의 한계를 극복하기 위해 특정 SQL을 캐싱해주는 시스템을 만들기도 하고, 프론트엔드 개발자들은 우리 회사 가이드에 맞는 UI 라이브러리를 그리고 쇼핑 개발팀의 경우 이벤트를 많이 하니까 이벤트 개설 부터 추첨 및 팔로우업까지 하는 시스템을 만들어 배포하기도 하구요. 이러니 사내에서 입소문이 나서 알음알음 다른 팀이 가져다 쓰게 됩니다.

제가 Daum 입사 초기에 몇 년간 기술 스탭을 하면서 “우리 팀이 이런거 개발했다. 근데 이팀 저팀이 쓴다. 전사적으로 쓰면 좋겠다” 이런식의 요청을 많이 받았습니다. 즉, 전사 공통 라이브러리가 됐으면 하는 바램이 있는 거죠. 하지만, 역할과 의무를 논하면 이야기가 달라집니다. 우리 팀은 다른 팀 요구 사항을 받고 처리하는 자원은 부족하니, 사내 공통 플랫폼팀에서 맡아줬으면 하는 겁니다.

하지만, 사내 공통 플랫폼을 맡아서 하는 팀도 하는 일이 없는게 아니잖아요. 이미 그런식으로 올라와서 관리하는 라이브러리와 도구가 한 두개가 아닌데다 어떤 건 레거시처럼 거의 신경도 못쓰고 굴러가는 것도 있을 정도로 리소스가 부족합니다. 게다가, 사내 전체적인 수요에 의해 결정된 것도 아니고 궁극적으로 남이 만든 코드를 유지 보수를 하라는 건데 누가 좋아하겠습니까? 그래서 대개 그런 건 거절을 하게 됩니다.

■ 콘트롤 타워 부재의 문제점
이렇게 되면 크게 두 가지 현상이 발생합니다. 여전히 공개에 적극적인 팀은 그냥 스스로 쓰겠다는 팀에 맘대로 배포를 합니다. 버전을 올려 배포를 하긴 하지만, 소스채로 배포를 해주고 팀마다 커스트마이징을 하니 버전이 몇 십개가 생깁니다. 다른 팀 피드백을 받아 고치면 자기들에게도 도움이 되니 적극적이지만, 팀 마다 여러 벌이 생기면 이마지도 쉽지 않게됩니다. 시간이 흘러 사내에서 너무 많이 쓰고 있어서 이제 전사적으로 관리를 해보겠다고 치면 세상에… 팀마다 다 다른 버전을 들고 있습니다.

더 큰 문제는 무작위 배포한 버그로 인한 장애가 전사에 영향을 주는 경우입니다. 어떤 팀에서 난 장애가 아직 다른 팀에서는 잠복하고 있는 경우도 있구요. 결국 전사 기술 스탭이 나서야 하는 상황이 생깁니다. 개별 팀에서 생긴 문제를 인지하고, 해결법에 대해 전사 공유, 그리고 각 팀이 해결했는지 코드 검증 등등 배보다 배꼽이 더 큰 경우가 생기게 돼죠.

그나마 공개에 적극적이지 않은 팀은 그냥 자기네들만 쓰면 상관이 없습니다. 그런데, 공개를 요구하면서도 자기들은 직접 하기 싫은 팀은 오히려 뒷말을 하는 경우도 있습니다. 도대체 기술 스탭은 뭐하는 거냐? 공통 플랫폼팀은 그런거 하라고 있는거 아니냐? 결국 기술 스탭이 또 나서야 하는 상황이 생깁니다. 설득을 하든 강하게 거절을 하든… 피곤합니다.

■ 사내 공통 플랫폼 레포지터리 구축
결국 제가 발견한 해법은 이런 겁니다. 사내에 오픈 소스 레포지터리를 만드는 것이죠. 개별 팀이 공개를 목적으로 만든 사내 라이브러리, 프레임워크 모두 올리게 합니다. 그리고, 그냥 오픈 소스 작동 원리에 맡깁니다. 잘되는 라이브러리는 잘될거고 안되는 건 안되겠죠.

당시 오픈 소스 개발 원리를 회사에 주입(?) 시키는 건 쉬운 일이 아니었습니다. 제가 일하던 시절이 12년 전이라 그 흔한 Pull Request 개념도 없었습니다. 이미 Github이 대세이고, 대부분 개발자들이 오픈 소스 원리로 개발을 하는게 뭔지 많이 알고 있기 때문에 요즘에는 훨씬 쉬울겁니다.

결과적으로 몇 가지 이점이 있습니다. 막상 코드를 공개하게 되면, 초기 개발팀에서 개별 배포하는 것 보다 좀 더 친절하게 매뉴얼이나 주석에 좀 더 신경을 쓰게 됩니다. 오픈 소스 레포지터리가 가진 기본 기능들, 즉 코드 리비전 관리, 버전 관리, 설치 방법, API Docs 문서 기능 등의 부담이 들지만, 누구나 쉽게 코드 개선 제안을 하고 버그가 발견되면 쉽게 고쳐지는 이점이 있습니다. 기술 스탭의 입장에서 선호도와 사용량을 보고 전사 관리해야 하는 것과 아닌 것을 판별할 수 있습니다. 설득에 도움도 됩니다.

사내 공통 플랫폼팀이 관리하던 라이브러리나 시스템이 우선 공개 대상이 됐구요. 개별 팀이 만들어 공개하고 싶은 것도 자유롭게 공개하도록 했습니다. 그러니, 정리될 건 정리되고 시간이 흘러 더 이상 유지 보수가 안되는 쉽게 알 수 있게 되었습니다. 무엇보다 새로 들어온 개발자들이 사내 공통 플랫폼에 맞추어 선택해 사용할 수 있는게 많구나! 좋은 회사 왔구나 하는 심리적인 안정감도 큰 도움이 되었습니다. 그 전에는 궁금한 점이 있으면 누구에게 물어봐라 위키 찾아봐라 정도가 대부분이었거든요.

■ 사내 개발자 경력 개발의 이점
12년 전에 이게 잘됐냐 물으신다면 저는 만족하지는 못했습니다. 오히려 잘 안됐다고 보는게 맞겠죠. 그렇지만, 이런 시도는 진짜 중요하구요. 이를 계기로 공통 플랫폼 개발하는 팀이 하는 일이 투명화 되고, 유지 리소스 산정에 도움이 되었습니다. 대개 서비스팀에 소속된 개발자들이 공통 플랫폼팀으로 팀 이직을 하는 경우도 많아졌습니다. 여기 오면 전사 관점에서 눈을 키울 수 있거든요.

제가 꼭 하고 싶었는데 못했던 것이 서비스팀에서 몇년을 일하면 무조건 공통 플랫폼팀에서 1년을 일하도록 강제하는 개발자 HR제도입니다.

대개 서비스 개발팀장들은 잘 하는 사람을 놓기 싫어하고, 그러다 보니 경력 개발 상 하나의 도메인에 집중하게 됩니다. 공통 개발팀에 오면, 전사의 서비스팀 관계자와 두루 소통을 하게 되어 시야도 넓어질 뿐 아니라 다른 팀으로 옮겨 가는 기회도 더 포착할 수 있거든요. 실제로 그런 경우도 많이 봤구요. (개발팀장들의 반대로 못했던게 끝내 아쉽습니다.)

이렇게 누가 뭘하는지 서로 잘 알게되면 사내 개발 문화를 바꾸는데도 도움이 됩니다. 문제를 해결하고 전사 생산성을 높이는 사람이 좀 더 주목을 받을 수 있구요. 자연적으로 이런 정보를 전달하거나 받고자 하는 요구가 늘어나고 사내 개발자 콘퍼런스나 세미나가 활성화 됩니다. 좋은 개발자를 뽑는 거 다른 거 없습니다. 안에서 잘하면 자동적으로 입소문이 나고, 이를 외부에 잘 공유하면 누구나 잘 알게 됩니다.

■ 오픈 소스 기반 개발 환경은 필수
이를 위해서는 회사 내에 오픈 소스 소프트웨어 사용 빈도를 높이는 것이 매우 중요합니다. Daum의 서비스는 리눅스, 자바 기반의 오픈 소스 플랫폼(톰캣, 스프링 등)을 주로 활용하고 개발 환경도 이클립스와 메이븐 등이고 개발 지원 서버들도 서브버전, Git, JIRA, 컨플루언스 위키, Sonar, Jenkins 등을 활용하고 있습니다. 개발자들이 오픈 소스를 모르면 개발하기 힘든 상황이었던 겁니다.

그러다 보니, 오픈 소스를 바로 다운로드 받아 사용할 수 있는 미러(Mirror) 서버가 필요했고, 2002년부터 사내 FTP 미러 서버가 제공되었다고 한다. 제가 이를 2007년에 외부에 ftp.daum.net이라는 이름으로 공개하고 아파치, 이클립스, 우분투, 센트OS 등의 공식 미러로 지정되었습니다. 당시 17TB의 스토리지에 일간 피크타임 기준 600MB의 트래픽을 제공해서 당시 국내 웬만한 개발자들은 한번쯤 이용했습니다.

물론 사용하는 거랑 소스 공헌하는 거는 완전히 다른 이야기입니다. 톰캣 가져다 커스트마이징해서 쓰다가 업스트림에 반영을 못해서 2.0으로 버전이 올라가도 1.0을 그대로 써야 하는 문제도 있었구요. 이런 문제를 해결하려면, 사내에서 부터 오픈 소스 개발 프로세스를 체득하고 실습해 볼 수 있는 내부 플랫폼은 필수입니다. 더 자세한 이야기는 기업 내 오픈 소스 개발 방식 도입記를 참고하시기 바랍니다.

이제 회사가 성장함에 따라 몇 개의 백엔드/프론트엔드 라이브러리 정도가 아나라 수십개의 모바일 SDK, 수백개의 API 등 그 숫자는 갯수는 기하급수적으로 늘어났습니다. 이를 정리할 또 다른 방법이 필요했습니다. 다음 편에서는 어떻게 사내 API 플랫폼을 성장 시켰고, 개발 문화를 바꾸었는지 살펴보겠습니다.

연재 목차

• 훌륭한 개발 문화의 이면(1) – 코딩 테스트인터뷰 제대로 하기
• 훌륭한 개발 문화의 이면(2) – 자율적 개발 환경을 선택하라!
• 훌륭한 개발 문화의 이면(3) – 다른 팀 소스 코드를 볼 수 있는가?
• 훌륭한 개발 문화의 이면(4) – 사내 라이브러리를 잘 관리하려면?
• 훌륭한 개발 문화의 이면(5) – 소통 비용의 절약 – 서로 API로 말하자
• 훌륭한 개발 문화의 이면(6) – 입사하고픈 회사를 위한 오픈 전략 구사하기
• 훌륭한 개발 문화의 이면(7) – 잉여력이냐 vs. 효율성이냐

- Channy Yun (윤석찬);

※ 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.)