정리 노트

몇 달 전 투자도 많이 받고 주목도 받고 있는 한 스타트업 대표로부터 질문을 받은 적이 있다. 개발 일정이 의도한대로 끝나지 못한 책임을 누가 가져가야 하느냐에 대한 질문이었다. 나는 주저 없이 그것은 일정을 제대로 계획하지 못한 프로젝트 매니저와 회사의 책임이 가장 크다고 말했다.

하지만 그 대답을 들은 대표는 별로 탐탁지 않아했다. 그의 생각은 어느 그룹이든 열심히 하는 개발자들도 있는 반면에 요령을 피우는 개발자도 있지 않냐는 것이다. 그런 개발자들의 잘못도 매니저가 가져간다는 것은 부당하다는 것이었다

이런 생각이 이 회사의 대표만의 생각은 아닐 것이다. 대부분의 비즈니스 사람들은 개발자들이 태만하거나 능력이 월등하지 못할 경우에 일정에 차질이 생길 수 있다고 오해를 하는 경우가 많다. 결국 이런 오해로 서로에 대한 신뢰관계를 무너뜨리고 같은 목표와 비전을 가지고 일하는데 있어서 큰 장애가 되고 만다.

개발자들은 느리지 않았다.

실제 프로젝트의 통계를 살펴보면 대부분의 개발 프로젝트는 개발자들의 능력보다도 어떤 의사결정이 늦어지거나 테스트 프로세스가 미흡할 경우의 이유로 늦어지는 경우가 더 많다. 이것을 뒷받침 해주는 데이터가 Sprintly라는 회사에 의해서 발표되었다.

Sprintly는 애자일 기반의 프로젝트 관리 툴을 제공하는 회사로 클라우드 환경에서 많은 개발 팀들이 그 툴을 이용하고 있다. 때문에 그들의 툴을 사용하고 있는 개발팀들의 데이터들을 통해서 특정 패턴들을 발견할 수 있었다.

먼저 개발자들이 티켓을 처리하는 속도가 결코 느리지 않았다는 것이다. 그들은 굉장히 다양한 회사들의 개발 프로젝트들을 조사하였다. 그들은 약 75%의 티켓 즉, 업무 리스트들이 평균 175시간에 해결되는 것을 추출해낼 수 있었다. 즉, 전체 프로젝트가 완료되는 시간에 비추어 굉장히 짧은 시간이었다. 

두 번째로는 실제로 티켓의 개발이 시작 되기 전에 티켓이 수정되거나 우선순위를 조정하기 위해서 굉장히 많은 시간을 보내는 경우가 많았다. 이것을 칸반 이라는 애자일 방법론에서는 리액션 타임이라고 부르는데 주로 티켓을 만들고 우선순위를 정하기 위해서 걸리는 시간을 이야기 한다.

마지막으로 그들의 데이터를 통해서 실제 각각의 업무가 “완료” 단계의 상태에서 “배포준비”로 가는데 까지 시간이 꽤 오래 걸린다는 것을 볼 수 있었다. 이 데이터가 의미하는 것은 실제로 개발된 스펙이 원하던 것인지 검토하고 다시 수정하는 시간이 오래 걸린다는 것이다.

그렇다면 왜 실제 개발 프로젝트가 지연되고 느려지는 것일까?

업무의 잦은 스위칭

먼저 개발자들을 느리게 하는 것은 한꺼번에 다양한 일을 처리해야 하는 경우이다. 즉, 처리해야 할 우선순위가 바뀌거나 먼저 처리해야 될 우선순위의 업무가 생겼을 경우이다. 개발자가 아니고서는 이해하지 못하는 사실이 있다. 

만약 A라는 업무를 50% 정도 완료한 뒤에 B라는 업무를 진행했다고 하자. B의 업무를 진행하고 A를 다시 진행한다며 그 업무는 과연 50%일까? 다른 업무에 머물러 있는 시간과 업무 성격에 따라서 적어도 70% 정도의 업무가 될 때가 많다. 

다양한 실험을 하고 알고리즘을 개발하는 업무라면 더더욱 그 업무에만 집중하는 것이 효율이 좋다. 실제 리드 개발자들은 다양하게 업무들을 스위칭하며 일하는 경우가 많다. 코드리뷰를 수행하고 짝 프로그래핑 그리고 여러 미팅을 다니게 되는데 이런 개발자가 실제 핵심 모듈을 개발하는 역할까지 수행해야 한다면 그 생산성을 보장받기가 어렵다.

조엘 스폴스키 또한 이것에 대한 자신의 의견을 피력한 적이 있다. 

불분명한 요구사항

실제 요구사항들은 지나치다 싶을 정도로 자세하게 작성 되어야 한다. 만약 개발자들이 그 요구사항을 이해하고 있지 않다면 어떻게 개발이 가능할 것인가? 실제 많은 프로젝트들을 보더라도 개발을 시작할 때 보다 자세한 스펙들을 작성하는 경우가 상당하다.

그리고 더 중요한 것은 제품에 대한 책임 결정권자가 그 기능에 대해서 정말 심각하게 고려하지 않은 경우가 많다. 그럴 경우에 개발자들은 왜 이 기능이 사용자에게 필요한지에 대한 이해가 없이 시작한 개발은 결코 창조적인 아이디어가 나올 수 없을뿐더러 그들 스스로도 개발자인지 아님 코더인지에 대한 정체성에 혼란이 오기 마련이다.

요구사항에서는 적어도 기능에 대해서 어떤 기능을 누가 왜 필요한지에 대한 이야기를 풀어내야 하고 더불어 다양한 상황에 대한 테스트 케이스들을 작성해주어야 하는 것이 가장 기본적인 스펙이 된다.

여기서, 요구사항이 터무니 없이 추상적이라면 그것은 더 세부적으로 나눠서 작성해야 한다는 뜻이 된다.

요구사항들의 변경

마지막으로 개발자들에게 있어서 가장 큰 불만 중 하나는 실제 업무가 시작된 뒤에 그것이 다시 바뀌는 경우이다. 개발자들이 변경하는 것 자체를 싫어하는 것은 아니다. 비즈니스 전략과 반응에 따라서 얼마든지 스펙은 변경될 수 있다. 하지만 그런 구체적인 사유와 데이터가 아닌 단지 시작 전에 정확하게 분석하지 못해서 오는 변경이라면 분명 시간적으로 낭비가 되는 것이다. 

물론, 개발자들은 정신적인 데미지도 함께 느끼면서 내가 만드는 것이 없어지거나 바뀔 수 있다는 불안감 때문에 코드 퀄리티에도 영향을 주게 될지도 모른다.

실제 개발을 시작하기 전에 중간 레벨 정도의 목업 프로토타입만 먼저 구현하는 것도 한가지 대안이 될 수 있을 것이다. 포켓웍스(Pocketworks)의 토빈 해리스(Tobin Harris)는 다음과 같이 이야기 했다.

이런 잦은 변화가 수반될 수 있다는 점에서 애자일 방법론에서 이야기하는 짧은 주기를 통해서 만든 결과물을 리뷰하고 다시 일정을 조정한다는 것은 큰 의미가 있다.

매니저들은 개발자들이 성공적으로 그들의 개발 역량을 잘 발휘할 수 있는 환경을 제공해줄 책임을 가지고 있다. 먼저 개발자들에게 딜레이 된 개발일정을 불평하기 보다는 먼저 그들 스스로 자신이 제공한 일정과 환경에 대한 책임을 먼저 생각해 보면 어떨까? 

성공적인 개발팀을 만들기 위해서는 명확한 비전이 공유되어야 하고 비즈니스 사람들과 같은 목표 아래 프로젝트가 진행되어야 할 것이다. 개발자들 또한 자신의 할 일을 줄이기 위해서 토론하고 일하기 보다는 그 목표를 같이 만들어가기 위한 적극적인 참여가 필요하다. 왜냐하면 우리는 코더가 아니라 창작물을 다루는 개발자들이기 때문이다.

필자가 6년전 처음으로 영국의 개발문화를 체험하기 전에는 한국 출신 개발자라는 자부심이 있었다. 종종 한국 개발자들은 여러명이 해야 할 작업을 혼자서 처리하는 다재 다능한 개발자로 비유되어왔다. 타이트한 일정 속에서도 야근을 감수하며 어떤 플랫폼이나 언어를 만나도 두려워하지 않는 이들이라는 이미지도 강했다. 그래서 하루에 8시간씩만 일해온 영국 보다는 하루 최소 10시간 이상을 개발에 전념해 온 한국의 개발자들이 당연히 나을 것이라고 생각했다. 

하지만 정작 외국 개발문화를 체험하면서 한국에서 쌓아온 경럭에 대한 자신감은 사라졌다. 영국에서 고급 개발자들에게 거는 기대와 한국에서 고급 개발자들에게 거는 기대가 확연히 달랐기 때문이다. 6년전 필자는 7년 정도의 실무 경력이 있었기에 당연히 시니어 레벨이나 개발 팀을 이끄는 리드개발자가 되지 않을까 싶었지만 그들의 기준에서는 턱없이 부족한 실력이었다. 

한국에서 개발자 실력이라고 하면 개발 속도와 임무완수 여부에 초점이 맞춰지는 경향이 많다. 즉, 적어도 실력있는 개발자는 일정을 밀리지 않고 잘 끝낼 수 있어야 한다. 하지만 영국에서 실력 있는 개발자라고 하면 주니어 개발자들이 막힌 문제들을 잘 풀어 줄 수 있어야 할 뿐만 아니라 속도보다는 얼만큼 코드를 객체지향 관점에서 적재적소의 패턴들을 적용하며 잘 작성할 수 있느냐로 평가된다. 

이 차이를 실감하면서 기존에 내가 생각했던 슈퍼 개발자의 능력과 방향이 조금 잘못되었다는 것을 느낄 수 있었다. 그렇다면 실무에서 20~30년 이상의 개발경력을 가지는 백발 개발자는 어떻게 커리어를 쌓아 왔을까? 

먼저 개발 분야의 전문성 레벨을 드라이퍼스 모델(Dreyfus Model)에 비교해 보자. 이 모델은 80년대 초 드라이퍼스 라는 두 형제에 의해 발표된 것으로 어떤 기술을 습득하는데 있어 거치게 되는 진화과정을 5단계로 나누고 있다. 5단계는 초급자(Novice), 초중급자(Advanced Beginner), 능숙자(Competent), 숙련자(Proficient) 그리고 전문가(Expert)로 분류된다. 

초급자는 언어와 개발 도구에 대해 경험이 전무한 초급 개발자에 해당한다. 때문에 어떤 매뉴얼을 따라 결과를 만들어 내는 것은 가능하지만 혼자서 창의적으로 코드를 작성하기 어려운 단계로 분류할 수 있다. 

매뉴얼이 없이 어느정도 개발이 가능한 단계가 바로 초중급자다. 어려운 로직이 아닌 범위 안에서 자유롭게 코드를 작성할 수 있는 단계다. 능숙자는 언어와 툴에 대해서 모두 익숙해진 단계이고 어떤 프로그램 로직이라도 원하는 결과물을 만들어 내는 것이 가능하다. 

능숙자까지는 소스 품질이 외국이나 한국이나 큰 차이가 없다.하지만 국내의 경우 품질보다는 결과를 더 중시하는 문화 때문에 숙련자로 성장해야 된다는 필요를 느끼지 못하는 경우가 많다. 즉, 5~7년이 지나면 개발자 레벨이 평준화된다고 이야기하는 것을 종종 듣는 것과 같은 맥락이다. 

하지만 능숙자와 숙련자는 만드는 결과물이 같지만 그것을 어떻게 만들었는지에 대해서는 분명한 차이가 있다. 보다 많은 예외 상황들을 고려하고 향후에 확장될 수 있는 가능성들을 검토해 보다 언어적으로는 객체지향적이고 또 관점지향적인 설계가 가능한 것과 더불어 시스템이나 플랫폼적인 설계도 가능하게 되는 단계이다. 많은 개발 패턴들을 알고 있고 실제 어떤 상황에서 적용하면 좋고 안 좋은지에 대한 이해가 있는가?그렇다면 숙련자 레벨이 된 것이다. 

숙련자 레벨을 넘어서게 되면 전문가 레벨로 가게 되는데 주로 외국에서는 개발자들의 코드를 리뷰하는 아키텍트가 바로 여기에 해당된다. 아키텍트의 역할은 주로 소프트웨어 품질을 관리하는 것이다. 그런만큼 숙련자들이 할 수 있는 실수들을 줄여줄 수 있는 능력을 가지고 있어야 한다. 즉 ,그들이 하게 되는 실수들을 미리 경험해보고 다양한 경우에 대한 설계 노하우를 갖고 조언할 수 있어야 한다. 

이렇게 전문가로 가는 길을 방해하는 것은 국내의 잘못된 개발문화 때문일 것이다. 하지만 그렇다고 이런 문화에 저항하지 않고서는 전문가의 커리어를 걷기 어렵다. 즉, 빠르게 결과를 전달하는 개발 문화에 순응하여 자기계발을 멈추게 되면 그 개발자는 능숙자에서 발전하지 못하고 정체될 수 밖에 없다. 이렇게 되면 개발자의 슬럼프가 시작되는데 이 단계에서 적성과 다르게 관리자로서의 커리어를 받아들이는 경우를 많이 보았다. 

지금 나의 위치는 어디인가?혹시 능숙자에서 성장이 멈추어 있는 자신의 커리어에 대해서 고민하고 있지는 않은가? 그렇다면 조금 더 예술적인 코드를 만드는 것에 투자해 보는 것은 어떨까? 한 예로 DRY(Don’t Repeat Yourself), KISS(Keep It Simple Stupid)와 같은 마인드 셋으로 SOLID와 같은 개발패턴들을 공부해 보는 것이다. 그리고 현업에서 직접 적용해보면서 상황에 따른 장단점들을 연구해보길 추천한다. 아무리 좋은 패턴이라고 하더라도 환경에 따른 다양한 상황 앞에서는 모두 완벽할 수 없기 때문이다.

Zdnet Korea에 기고한 글입니다.