잉여와 소프트웨어 개발의 관계
신현묵 오픈헬스데이터 이사가 블로그에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
IoT의 관점과 함께 최근에 주목을 받는 시계열 DB들이 있다. OpenTSDB나 인플럭스 DB, Graphite와 같은 것들이다. 신기하게 최신 기술이나 플랫폼이라고 불리는 것들은 국내에서 거의 등장하지 않는다. 대부분 미국이나 유럽, 이제는 중국이나 러시아에서 등장한다. 물론, 일본에서도 새로운 언어가 많이 등장했다.
집안의 전기 사용량이나 공기 측정 등 1초에 한번 측정하는 센서에서 만들어지는 데이터를 자세하게 분석하려면 이 데이터를 수집하고 모아야 한다. 그리고, 최소 연 단 위로 모아서 무언가를 분석하거나 추이를 살펴보아야 할 것이다.
더군다나, 센서가 여러 개라면 데이터의 량은 상당할 것이다. 기존의 RDB에 축적하는 것은 이런 경우에 좀 맞지 않는다. 데이터가 계속 용량을 늘려나가는 구조이기 때문에 NoSQL형태의 데이터 스토어를 생각하게 된다. 코치이건 하둡이건 몽고이건 여러 가지가 생각난다. 실시간으로 추적, 분석하려면 Apache Storm이나 spark도 생각날 것이다.
 이미지: shutterstock |
일단, 센서가 시간의 추이에 따라서 데이터를 모으는 형태에 적합한 시계열 DB에 적합한 방법들에 대해서 나름 적합한 형태로 개발되는 구조를 가진 DB들을 어렵지 않게 찾아볼 수 있다. 이 글 가장 앞에 언급한 것들이다.
관련 자료를 찾아보고 싶으면, OpenTSDB와 InfluxDB를 찾아보라. 나름 매력적으로 시계열 형태의 데이터를 모으기 좋은 구조로 디자인되는 솔루션을 만날 수 있다.
본론으로 돌아가서, 이러한 특정 요점에 맞는 솔루션들이 왜? ‘국내에서 나타나지 않는가’에 대해서 말하고 싶다. 과연, 이러한 태도와 행동 그리고 행위가 특정 개발자의 탁월함 때문일까? 아니면, 국내에 있는 개발자들이 게으르고, 자신의 이익만을 위해서 일하는 것 때문일까?
삐딱한 아키텍트는 그 부분을 이렇게 해석한다.
하나. 잉여가 없는 부가가치가 적은 일을 매번 수행하는 국내의 경영자들의 문제.
둘. 반복적인 작업이나 자신의 미래에 대해서 큰 관심이 없는 개발자의 자세
셋. SI형태로만 진행되는 국내 프로젝트 때문에 만들어진 플랫폼이나 유틸리티 성의 서비스를 외부에 오픈하지 못하는 경우가 빈번함.
위 3가지의 가장 큰 이유 때문에 국내에서는 특정 용도나 특정 의미의 환경에 잘 어울리는 솔루션들이 오픈소스로 발전되지 못하고, 더 넓게 쓰이는 플랫폼까지 진화하지 못한다고 생각한다. 하나씩 나름대로 이유를 이야기해보자.
잉여가 없는 부가가치가 적은 일을 매번 수행하는 국내의 경영자들의 문제
일단, 부가가치가 높은 소프트웨어나 서비스를 개발한다면, 적절하게 배분되어진 팀과 일정, 부가가치가 높기 때문에 피드백을 통해서 품질을 높이기 위한 시도들이 반복되어진다. 하지만, 대부분 1회성으로 끝나거나, 단기적인 일거리를 해결하기 위해서 소프트웨어를 개발하는 경우가 대부분이기 때문에 사소한 잉여도 발생하기 어렵다.
고품질을 지향하는 소프트웨어 개발을 추구한다면 매우 당연하게 잉여시간과 잉여 일정, 잉여인력이 투입되는 것이 정상이다. 매우 당연하게 소프트웨어 개발자들은 게으르기 때문에 반복적인 일을 싫어하고, 게으르기 때문에 소프트웨어의 품질을 높이기 위해서 공을 들인다.
이런 게으른 소프트웨어 개발자들이 품질 높이기를 포기하는 이유는 간단하다. 그 소프트웨어가 재사용될 가능성이 거의 존재하지 않고, 또다시 요구사항에 따라서 난도질을 해야 하는 경우에 품질 높이기를 시도하지 않는다.
 이미지: shutterstock |
처음부터 비즈니스 기획과 부가가치에 대한 이윤 및 투입되는 비용에 대해서 잘못된 비즈니스 모델을 만든 기획자나 경영자가 그 책임을 져야 한다. 물론, 그런 환경을 주었더라도 잘못된 개발자를 뽑은 ‘인력관리’ 실수에 대해서도 경영자가 책임져야 한다.
대부분 고품질의 소프트웨어가 나타나지 않거나, 잉여가 만들어지지 않는 이유는 경영자가 미숙하고, 비즈니스 모델을 잘못 디자인한 경우가 대다수이다.
반복적인 작업이나 자신의 미래에 대해서 큰 관심 없는 개발자의 자세
하지만, 경영자의 잘못과 거의 비슷한 수준으로 개발자의 자세가 문제가 되는 경우가 많다. 잉여가 주어졌음에도 빈둥거리거나, 자신만의 놀이를 위해서 그 시간과 비용을 투자하는 경우도 간혹 있다. 이런 문제가 발생한 원인에 대해 개발자보다는 경영자의 문제라고 지적하고 싶다.
반복적인 일을 줄이고, 미래의 코드에 대해 신경쓰는 자세는 소프트웨어 개발자가 기본적으로 갖추어야 하는 요소이다. 이러한 자세를 파괴하는 형태의 업무 구조와 생각 자체를 파괴하는 형태로 일을 구성하는 경영진과 같이 일한 개발자는 슬프게도 잉여를 빈둥거리게 하는데 익숙하게 된다.
 이미지: shutterstock |
개발자 구인 시 가장 주목하고, 관심을 가지면서 걸러야 하는 개발자는 그러한 회사를 거쳐왔거나 그러한 프로젝트에 매몰됐던 사람을 피하는 것이다. 그런 자세가 파괴된 개발자는 다시 자세를 정상으로 복구하는데 엄청난 리소스와 시간이 투입된다.
냉정한 사람이라면 이러한 사람을 ‘동료’로 받아들이기 싫어할 것이다.
SI형태로만 진행되는 국내 프로젝트이기 때문에 만들어진 플랫폼이나 유틸리티 성의 서비스를 외부에 오픈하지 못하는 경우가 빈번함
한국에서 50% 이상 의미있는 형태로 개발됐음에도 불구하고, 사장되거나 외부에 노출되지 않는 경우를 빈번하게 경험했다.
필자 역시, 웹서비스 개발 초기에 3 Tier개발에 어려움을 겪는 개발자들을 위해서 SQL 문장을 그대로 웹서비스에서 CRUD형태로 전송하고 데이터셋과 DB커서를 2 Tier의 형태로 손쉽게 개발할 수 있는 플랫폼과 컴포넌트를 개발했지만, 이 역시 SI에 종속된 결과물이 되면서 외부에 오픈할 수 없는 경우가 되는 것을 빈번하게 경험했다.
 이미지: shutterstock |
이 3가지 이유 외에도 ‘잉여’가 없는 개발 일정이나 개발자에게 여유가 없어지면서, 정말 재미없는 소프트웨어 개발이 반복되는 경우를 많이 보았다. 지금은 관리자의 입장에서 개발을 총괄하고 있지만, 이전의 경험을 바탕으로 팀에 있는 개발자에게 약간의 잉여와 리소스에 대한 배려를 취하면서 동료직원이 오픈소스를 창출하거나 외부에 오픈할 수 있는 정도의 여유를 만들어 줄 수 있다고 생각한다.
가장 훌륭한 CTO나 개발 총괄의 역할은 그 시간을 정말 즐겁다고 생각하는 동료 개발자에게 약간의 잉여와 여유를 허가하는 것이다. 그 잉여가 자신이 속한 개발조직의 효율을 향상시키고, 부드러운 개발문화를 통해 아주 의미있는 개발 조직으로 완성되는 첫 번째 단추가 되기 때문이다.
카페와 같은 공간을 만드는 것이 아니라, 개발 공정이나 개발 프로세스 상에 리뷰와 의미있는 문서화 작업, 피드백과 리팩터링 등 시간을 배준하는 이유도 그 때문이라는 것을 잊지 않기 바란다.
재미와 의미를 추구하고 잉여가 존재하는 개발조직이야 말로 성공할 수 있는 전제조건을 하나 더 갖춘 곳일 것이다.
글. 신현묵
