개발자들이 숨쉴 수 있는 문화

최근 개발자들의 이직률이 여전히 높다라는 조사 결과가 인크루트(Incruit)를 통해 발표됐다. 조사에 따르면 응답자의 40%가 1~2년 마다 회사를 옮긴다고 답했다. 흥미로운 것은 이직 이유에 있다. 이직을 결정하는 가장 큰 이유는 연봉 때문일 것이라고 생각했지만 연봉이라고 답한 개발자들은 20% 정도밖에 되지 않았다. 70%는 자기계발을 위해서 그리고 회사의 불투명한 비전 때문이라고 이직한다고 답했다.

영국 취업 사이트 포털인 잡스에서 발표한 자료를 보면 이직의 이유가 국내와는 많이 다르다. 영국은 개발자들이 이직하는 빈도가 2.7년에 한번 정도일 뿐만 아니라 이직 이유도 연봉이 가장 큰 영향을 미쳤다. 이같은 결과는 아직도 국내 많은 IT 기업들이 개발자들에게 적절한 비전을 제시해주지 못하고 있을 뿐만 아니라 소통도 많이 부족하다는 것을 보여주는 대목이다.

국내 기업의 경우 외형적으로는 어느정도 성장을 이뤄낸 것은 분명하나 선진국의 개발문화는 아직 제대로 흡수하지 못하고 있는 셈이다.

IT업계에선 새로운 개발 트렌드와 플랫폼들이 계속 쏟아져 나온다. 이 때 개발자도 변화만큼의 새로운 무언가를 공부하고 같이 발전하고 있다는 생각이 들지 않으면 자신의 비전에 대한 불안감이 싹틀 수 밖에 없다.

회사에서 중요한 것은 조직과 개인이 함께 성장해 나가는 문화다.

그러려면 회사는 더 이상 일정과 사람중심의 개발문화가 아닌 개발자와 함께 성장할 수 있는 회사 고유의 시스템에 의해 움직여져야 한다. 그 시스템은 바로 회사가 가지고 있는 개발 문화들에 의해서 형성된다. 외국에서는 이미 익숙하지만 국내에서는 아직 도입이 더딘 몇가지 개발 문화들을 살펴보도록 하겠다.

■코드 리뷰

국내 개발문화를 보면 대부분 프로젝트 매니저가 개발자들에게 작업들을 전달한다. 개발자들이 일을 완료하면 PM이나 테스터들이 결과에 대한 확인을 요청할뿐 코드를 점검하는 프로세스는 거의 빠져있다. 이렇게 결과 위주의 작업 프로세스로 일을 진행하다가 보면 소프트웨어 품질은 보장하기 어렵다. 어떤 작업을 처리하는데 있어 미래에 몇 가지 기능이 추가될 수 있다는 가정을 가지고 만든 것과 무조건 빠르게 결과를 보여주기 위해서 만든 것은 품질에 차이가 나게 마련이다

이런 문제를 해결하기 위해 필요한 문화가 바로 '코드리뷰' 다. 코드리뷰는 어떤 작업을 시작하기전에 리드 개발자나 아키텍트가 정확한 요구사항을 분석하고 그걸 개발자들에게 전달하면서 시작된다. 전달 과정에서 복잡한 업무나 지시가 필요할 경우 TDD를 이용해 테스트 코드를 아키텍트가 직접 작성하거나 짝 프로그래밍을 통해서 함께 작성한다. 물론 테스트 코드 작업 없이 어떻게 개발하면 좋겠다라는 큰 그림들을 설계들을 정의하여 토론할 수도 있다.

이렇게 개발자에게 전달된 작업은 새로운 작업영역(Branch 같은)에서 진행한다. 해당 작업이 완료됐다고 생각될 때 개발자는 다시 아키텍트에게 소스를 업데이트 해도 되겠느냐는 요청을 보내게 된다. 이것은 git 시스템에서는 풀 리퀘스트(Pulll Request)에 해당된다. 요청을 받은 아키텍트가 코드를 리뷰하고 피드백을 보내거나 문제가 없으면 기존 소스에 그 작업을 반영하게 되는 것이다.

이같은 작업이 가져다 주는 가장 큰 이익은 개발 표준에 따른 일관성을 유지 하기 쉽다는 것이다. 그리고 개발자들은 자신이 만든 코드에 대한 확신을 갖고 잠재적인 버그를 최소한으로 줄일 수 있다. 아키텍트의 피드백을 통해서 많은 설계 및 코딩 능력들을 흡수하는 것도 가능하다. 즉, 코드리뷰 프로세스를 통해서 품질과 개발자들의 개발능력을 증진시킬 수 있는 두 가지 토끼는 잡는 것이 가능하다는 것이다.

국내 개발자들은 이론과 기본기에 많이 약하다는 평가가 많다. 올바르게 코드를 작성하는 것을 공유하고 서로 토론하는 문화 자체가 없다는 것과 무관치 않을 것이다.

요즘은 Bitbucket이나 Github와 같은 프로젝트 관리 툴을 이용하면 이런 개발 환경을 쉽게 설정할 수 있기 때문에 코드리뷰를 위한 프로세스를 도입한 것은 어렵지 않다. 개발 프로세스가 하나 더 추가되어 개발 생산성을 우려할 수도 있지만 잠재적인 버그를 점검하는 과정과 팀에게 공통된 표준을 적용하는데 따른 이익을 생각한다면 당장 눈에 보이는 빠른 성과보다 값진 작업일 것이다.

■테스트 자동화

TDD를 통해서 유닛 테스트를 작성하면 좋은 소프트웨어 품질을 유지할 수 있다는 것은 이미 많은 사례들을 통해서 검증되었다. 하지만 모든 유닛별로 테스트 코드를 생산한다는 것은 많은 손 코딩을 필요로 하다보니, 생산성과 효율 관련해 많은 논란이 있는 것도 사실이다. TDD가 익숙한 개발자들은 생산성에 큰 문제가 없다고 볼 수 있다. 그러나 TDD에 모든 개발자가 익숙한 건 아니다.

영국의 경우 SW개발 회사들은 대부분 TDD개발 방법론을 사용한다. 이게 가능한 것은 모두가 100% 코드 커버리지를 갖는 유닛테스트를 작성하는 것이 아니기 때문이다. 예민하고 필수적인 프로그래밍 로직은 당연히 각 유닛별로 테스트 코드를 작성하지만 그렇지 않은 경우에는 여러 유닛들을 묶어서 최종 결과를 확인하는 통합 테스트 코드만 작성하는 경우가 많다.

국내의 경우 아직도 자동화된 코드를 이용해서 소프트웨어를 테스트하기 보다는 테스트 그룹이나 고객이 만든 제품을 사용해보면서 테스트를 진행하는 경우가 많다. 하지만 자동화 된 테스트 코드 없이 사람에 의존하다 보면 작은 수정에도 모든 기능을 테스트 해야 하는 비효율이 발생한다.

소프트웨어 품질에서 중요한 것중 하나는 새로운 기능을 추가하거나 수정할 때마다 계속 그 코드들의 구조를 수정하는 리팩토링 작업이 수반되어야 한다는 것이다. 하지만 자동화된 테스트가 없을 경우 코드 구조를 바꾸면 다른 작업에도 영향을 주어 버그를 만들어 낼 수 있다는 가능성 때문에 혹은 다시 모든 기능을 테스트 해야한다는 번거로움 때문에 리팩토링에 소극적이게 마련이다.

이러한 시나리오 때문에 리팩토링과 개발자가 멀어지면 자신의 코드에 대한 자부심이 떨어질 수 있다. 때문에 불필요한 테스트 작업을 자동화시킴으로써, 개발자가 자신의 코드 품질에 조금 더 집중할 수 있는 환경을 만들어 주는 것이 중요하다.

■코드 워크샵

코드 워크샵은 1~2주에 한번씩 개발 팀이 모여 진행하는 미팅으로 한 명씩 돌아가며 일하면서 자신이 새롭게 알게 된 지식들이나 작업을 하면서 생겼던 이슈들을 짧게 공유하는 시간이다. 한 사람당 길어야 1~2분 정도 공유할 내용을 준비한다. 형식은 PPT 1~2장을 짜리 자료일 수도 있고, 코드를 보여주기도 한다.

이 미팅은 무조건 새로운 것만을 공유하면서 지식을 전달하는 세미나 같은 자리가 되어서는 안 된다. 이 미팅의 목적은 2주 동안 개인 입장에서 새롭게 알게 된 것을 공유함으로써 각자 배우고 성장하고 있는지를 점검할 수 있게 하는 것에 있다. 그러면서 자연스럽게 자신이 알고 있는 지식들을 나누고 토론할 수 있는 문화로 발전해 나갈 수 있는 것이다.

토론과 공유 문화가 부족한 한국 개발 환경에 반드시 필요한 문화라고 생각한다. 개발자들에게는 이런 토론과 공유를 통해서 무언가 계속 배우고 습득하고 있다는 느낌을 전달해 줄 수 있다. 그리고 2주에 한번씩 자신이 배운 것들을 되짚어 본다는 점에서도 큰 도움이 될 것이다.

■짧은 개발주기

한국에서 고객 혹은 어떤 제품을 기획하는 기획자라고 한다면 요구사항을 정리해서 전달해주는 것이 자신의 업무라고 생각하는 경우가 많다. 하지만 자신이 원하는 것에 가장 가까운 제품을 만들기 위해서는 짧은 개발주기를 반복함과 동시에 끊임없는 커뮤니케이션을 통해서 제품을 만들어 나가야 한다.

이게 개발자들에게 중요한 건 개발자들에게는 자신의 작업을 리뷰하고 팀들과 소통할 수 있는 주기가 필요하기 때문이다. 그 주기 없이 긴 일정속에서 개발만 하다 보면 결국 팀원들과의 소통보다는 어떻게든 자신에게 할당된 일에만 몰두하게 된다.

어떤 짧은 목표를 팀원들과 함께 해결하기 위한 과제가 부여되지 않는다면 그들은 소통해야 할 이유가 갖게 못하게 된다. 당연히 서로 지식을 나누고 공유하는 문화와도 자연스럽게 멀어질 것이다.

개발 회사에서는 회사의 비전과 더불어 개발자들이 숨쉬며 소통할 수 있는 문화들을 제공해 줄 필요가 있다. 개발자들의 의욕을 고취시키고 또 회사와 같이 성장시키기 위해서는 좋은 품질의 소프트웨어를 개발할 수 있는 환경을 만들어 주는 것이 중요하다. 또 개발자들끼리의 지식나눔 문화를 통해서 새로운 지식들을 끊임없이 배우게 해야 한다.

개발자들의 생각도 변할 필요도 있다. 예를 들어 이어폰을 끼고 독립된 공간에서 폐쇄적으로 개발에만 집중하는 것보다는 팀들과 소통하려는 자세가 필요하고 또 다른 사람이 작성한 코드라고 하더라도 같이 주인의식을 갖는 공동체 의식도 필요하다.

개발자들의 토론문화도 보다 성숙해질 필요가 있다. 국내의 주입식 교육 환경의 영향으로 내가 듣고 생각하는 것이 틀릴 수 있다는 것을 인정하는 것이 익숙하지 않은 것은 사실이다. 하지만 누구나 다른 생각을 가질 수 있는 것이 당연한 것인데 그것에 적대감을 가지거나 자신이 잘못된 것을 쉽게 인정하지 못하는 성향은 버리는 것이 좋다. 그래야 팀과 같이 성장하는 것이 가능하다.

개발자들이 먼저 의식을 바꾸고 새로운 문화를 맞이할 준비가 되지 않으면 소수 매니저들이 주도하는 노력만으로는 좋은 결과를 맺기 어렵다.

*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.