소프트웨어 번역 프로세스의 절대 원칙 (19)

소프트웨어를 국제화하려면 수많은 요소를 국제화해야 하지만 그 중에서 절대 빠지지 않는 부분이 번역이다. 또한 가장 중요하면서 어렵다. 필자가 얘기하는 주제는 번역 그 자체를 제외한 번역을 위한 모든 활동을 말한다. 소스코드에서는 어떠한 함수를 사용하고, 메시지는 어떻게 추출해서 어디에 저장하고 번역가에게는 어떻게 보내고, 번역된 메시지는 소프트웨어에서 어떻게 읽어 들여서 출력할 것인지에 대한 아키텍처와 프로세스 전반을 말하는 것이다. 

소프트웨어를 어느 정도 개발해 본 경험이 있는 개발자라면 소프트웨어를 번역해서 해외에 출시해 본 경험을 누구나 가지고 있다. 또한 별 문제를 겪지 않아서 소프트웨어 번역이 별거 아니라고 생각하는 개발자도 많다.

그럼에도 불구하고 필자는 왜 자꾸 어렵다고 얘기를 하는 것일까? 과장을 하는 것은 아닐까? 아니다. 소프트웨어 번역에서 별 문제를 겪어보지 못한 개발자들은 아직 심각한 상황을 경험해보지 못해서 어려움을 모르는 것일 가능성이 높다다. 아래 5가지 상황 중에서 2가지 정도만 닥쳐도 소프트웨어 번역은 심각한 문제가 된다.

10개 이상의 언어(로케일)을 지원

100명 이상의 개발자가 공동 개발

10000개 이상의 메시지를 번역

100,000명 이상의 고객이 사용한다.

적어도 한 달에 2번 이상 업데이트

한두 명의 개발자가 몇 백 개의 메시지를 번역해야 하는 상황이라면 어떤 메시징 아키텍처를 사용하던지 완전 수동화된 프로세스를 사용해도 거의 문제가 안 된다. 그래서 거의 모든 개발자들이 큰 고민 없이 여러 개발툴들이 제공하는 메시징 함수를 그냥 사용하고 수동에 의존한 프로세스에 익숙해져 있다.

그렇게 성장을 하다가 큰 제품을 만들 기회가 생기고 큰 조직에서 수십 명의 개발자와 같이 개발을 하게 되면 번역은 10배, 100배 비용이 들게 된다. 

예를 들어 전세계 백만 명이 사용하는 제품을 20개 언어(로케일)로 번역을 해야 하는 거대 프로젝트에 참여를 했다고 생각하자. 소프트웨어에 추가할 메시지들을 RC에 추가한다던지 별도의 파일에 추가하는 것은 쉽지가 없다. 메시지도 수만 개에 이를 뿐만 아니라 수십 명의 개발자들이 동시에 RC파일을 고쳐댄다. 똑 같은 메시지가 서로 다른 심볼로 중복 저장되기도 하고 반대로 의미가 다른 동일한 메시지를 사용하기도 한다. 더 이상 사용하지 않는 메시지를 삭제 했더니 다른 개발자는 사용하고 있는 경우도 있다. 그래서 메시지를 삭제 않다 보니 사용하지 않는 메시지가 넘치게 된다.

번역가에게 번역을 의뢰할 때도 처음에는 문제가 안되는데 두 번째 버전부터는 바뀐 메시지만 의뢰를 해야 한다. 번역된 결과물을 첫 번째 번역과 합치는 것도 문제다. 이렇게 복잡한 수동 프로세스에 의존하다 보니 누락된 메시지가 생긴다. 이를 개선하고자 자동화툴을 만들어보지만 깔끔하게 해결하는 것이 쉽지는 않다.

이런 거대 프로젝트에 참여를 해서 소프트웨어 국제화의 어려움을 실제로 겪어본 개발자는 그렇게 많지 않다. 하지만 모든 개발자는 언제든지 이런 상황을 겪게 될 것이고 지금의 국제화 지식만 가지고는 남들이 겪은 국제화 실패를 고스란히 다시 겪게 될 것이다.

그럼 소프트웨어 번역은 어떻게 해야 할까? 앞으로 여러 차례에 걸쳐서 설명을 하게 될 것이고 오늘은 대원칙 2가지를 알아보자.

첫째, 메시지의 키는 영어 자체를 사용해야 한다.

둘째, 번역 자체를 제외한 모든 프로세스는 완전 자동화 되어야 한다.

위 두 원칙에는 많은 의미를 포함하고 있고 적용하기 쉽지도 않다. 또한 기존에 수많은 개발자들이 소프트웨어 번역을 위해서 사용하고 있는 방법의 대부분의 뒤 두가지 원칙에 위배되고 있다.

다음 시간에는 왜 메시지의 키가 영어가 되어야 하는지 설명을 시작으로 소프트웨어 번역에 대해서 좀더 깊이 들어가보자.

한국의 개발자는 쓸데없이 바쁘다

한국의 개발자들은 항상 바쁘다. 소프트웨어 개발을 하느라고 바쁜 것이 아니라 쓸데없는 일에 바쁜 것이 문제다. 회사마다 차이는 있지만 많은 회사에서 개발자들은 본연의 개발 업무보다 불필요한 다른 일에 바빠서 정작 본연의 임무인 개발에 투자하는 시간이 얼마 안되는 경우가 많다. 여기서 개발이라 함은 코딩뿐만 아니라, 분석, 설계, 리뷰 등 개발에 필요한 일련의 활동을 모두 말한다.

한국 회사들의 소프트웨어 개발 생산성이 상대적으로 선진 소프트웨어 회사보다 낮은 이유 중 하나는 개발자들이 개발에 전념하지 못하는 환경 때문이다. 

개발자는 고참이 될수록 개발에 집중하지 못하고 다른 일 때문에 바빠진다. 어느 회사의 고참 개발자들은 낮 시간에는 코딩을 한 줄도 못하고 남들 퇴근 후에 개발 일을 한다. 낮에는 이 회의, 저 회의 많이 끌려 다니기 때문에 집중해서 개발 관련 일을 할 수 없어 낮시간은 아예 포기하고 밤에 개발을 한다는 것이다.

코딩, 분석, 설계 관련된 모든 일은 대단히 집중력이 필요하기 때문에 중간에 다른 일로 방해를 받으면 다시 집중하기 매우 어렵다. 하루 종일 방해 받지 않고 집중해서 일할 수 있는 환경은 매우 중요하다. 

하지만 경영자들은 개발자도 시장을 잘 알아야 한다고 말하며 고객을 직접 만나게 하고, 시장 관련 회의에 참석하게 한다. 여러 경영 회의, 전략 회의에도 개발자들을 끌고 다닌다. 그러다보니 개발자들은 보고서도 작성해야 하고 보고 회의도 참석해야 한다.

고참 개발자일수록 이런 회의에 더 많이 불려 다니게 된다. 어쩔 때는 회의에서 꿔다 놓은 보릿자루 마냥 앉아 있기만 하면서 “왜 이런 회의를 참석해야 하나” 한탄을 하지만 회사 요구 때문에 빠지기도 눈치가 보여서 그냥 참석을 하는 경우가 많다. 물론 개발자도 시장, 고객, 경영 등 여러 분야에 대해 알아야 한다. 아키텍트나 팀장인 경우 더 잘 알아야 한다. 문제는 시간의 효율적인 활용이다. 이런 회의에 다 불려 다닌다고 더 잘아는 것은 아니다. 문서로 공유해도 되는 내용을 장시간 회의에 앉아서 시간을 허비하는 경우가 많다.

개발자들은 평가, 교육 활동으로도 많은 시간을 빼앗긴다.  필요한 일들이기는 하지만 너무 많은 시간을 빼앗기는 것이 문제다. 회사 교육담당자는 개발자들에게 교육을 많이 시켜서 도움을 주고 싶어하지만 일괄교육, 집체교육, 의무교육은 개발자들의 개발업무를 방해하는 요소다. 리더 교육을 열심히 한다고 팀장이 뛰어난 리더가 되는 건 아니다. 필요 없는 교육은 아니지만 얼마나 효율적인지는 생각해봐야 한다. 기업에서는 교육보다 실무 자체로 배우는 것이 더 중요하다. 

회의를 많이 하는 회사일수록 커뮤니케이션이 잘 안되고 누가 뭘 하는지 잘 모르는 경우가 많다. 회의가 과도하게 많다는 것은 공유와 협업이 잘 안되고 있다는 반증이기도 하다. 대기업에서 개발자가 더 일하기 힘든 이유가 여기에 있다. 대기업은 회사마다 다르지만 기본적으로 회의도 많고 프로세스도 복잡하다. 정작 진짜 개발하는 시간은 몇시간 안된다. 

그럼에도 대기업이 돌아가는 이유는 우수한 인력과 여유 인력, 자본이 풍부하기 때문이다. 50% 퍼포먼스만 발휘해도 회사는 굴러간다. 이런 비효율이 회사가 잘 될 때는 문제가 안되지만, 어려울때는 큰 약점이 된다. 
그런데 중견기업 중에는 이런 대기업 형태를 따라하는 회사들이 꽤 많다. 회사가 커지다보니 관리의 필요성이 증가해 개발자들의 시간을 점점 빼앗는 것이다. 그러다보면 대기업의 장점인 관리 부문에도 만족하지 못하고 기존의 민첩하고 효율적인 개발 방식도 점점 잃게 된다. 

기본적으로 이렇게 회사에서 개발자들이 개발에 집중하지 못하게 방해를 하는 이유는 개발자를 믿지 못하기 때문이다. 심지어는 초등학생 취급하는 경우도 있다. 개발자들이 알아서 자율적으로 제대로 일할 것이라고 믿지 못하기 때문에 결과는 점점 효율성이 떨어지는 것이다. 

원칙적으로는 개발자는 거의 개발만 해야 한다. 숫자로 얘기를 하면 95% 이상의 시간은 개발에 전념할 수 있도록 해야 한다. 분석, 설계, 리뷰, 코딩 등 개발 활동에 쏟아야 한다. 중간에 방해를 하지 않도록 프로세스, 시스템이 최대한 뒷받침을 해야한다. 

대부분의 회사에서 회의는 10분의 1 정도로 줄여야 한다. 조금이라도 관련이 있는 사람은 잔뜩 불러서 하는 대규모 회의는 특히 삼가 해야 한다. 괜히 일상적으로 모여서 하는 대규모 회의도 줄여야 한다. 필요한 사람 몇명만 불러서 사안 별로 회의를 하면 된다.그렇다고 개발자가 고객, 시장, 전략을 몰라도 된다는 것은 아니다. 시간을 최대한 효율적으로 활용해서 최소 시간을 투자해서 공유를 할 수 있어야 한다. 개발자의 시간은 비싸다. 

실제로 개발자가 하루에 개발에 몇시간을 사용하는지 조사를 해보자. 80% 미만이면 심각하게 생각해야 한다. 그런 개발자는 개발을 포기하고 전문 관리자가 되는 것이 낫다. 그렇지 않다면 무엇인 문제인지 찾아서 문제를 제거하고 개발자들이 개발에 집중할 수 있도록 해줘야 한다. 이슈관리시스템을 제대로 활용하면 불필요한 회의는 많이 줄일 수 있고, 회의를 하더라도 시간을 단축할 수 있다. 회의를 줄이고 효율적으로 하는 방법은 여러가지가 있지만 다음과 같은 원칙을 지키는 것이 좋다. 

대규모 회의보다는 소규모 회의를 하고, 공유는 시스템으로 하고 의사결정이 필요할 때만 회의를 한다. 회의 전에 내용을 미리 공유해서 짧은 시간에 의사결정을 해야 한다. 회의 내용은 관련자 모두에게 즉각 공유해야 한다. 

소프트웨어 개발 경쟁력에서 핵심은 개발자다. 개발자가 많은 시간 개발에 집중할 수 있도록 하는 것은 소프트웨어 경쟁력 향상에서 가장 중요한 일이다. 이렇게 하면서도 공유, 커뮤니케이션에 문제가 없을 수 있도록 하는 것이 개발 문화, 프로세스, 기반 시스템의 역할이다.

이 글은 ZDNet Korea에 기고한 칼럼입니다.

개발자에게 재택 근무가 필요한 이유

과거 서울 남부의 경기도에서 소프트웨어 개발자를 채용할 때였다. 서울에서 별로 멀리 떨어져 있지 않은 경기도에 있는 곳인데도 많은 지원자들이 거리상의 문제로 지원을 포기 했고, 특히 서울 북부에 사는 사람들은 인터뷰 시에도 출퇴근의 어려움에 대한 걱정을 토로했다. 

얼마 전 한 소프트웨어 회사는 서울에서 판교로 사옥을 이전했다. 그런데 서울 북부나 일산 등지에 사는 직원들을 주축으로 많은 개발자들이 회사 이전과 동시에 퇴사를 했다. 특히 몇몇 핵심 개발자들의 퇴사는 회사의 큰 손해가 아닐 수 없었다. 

아직도 우리나라 소프트웨어 회사의 근무형태는 농업사회에서 보여주는 전통적인 근면 성실을 강조하는 근무 시스템에서 크게 벗어나지 못하고 있다. 시간에 맞춰서 출퇴근을 하고 야근까지 하면서 상사에게 오랜 시간 열심히 땅을 파는 모습을 보여줘야 ‘열심히 일을 하고 있구나’ 하며 안심을 한다. 이런 현상을 보면 소프트웨어 개발이 지식 산업이 아닌 노동집약적 산업이라고 오해하고 있다는 생각이 든다. 

이렇게 시간 딱딱 맞춰서 사무실 자리에 앉아서 일을 해야 하는 시스템은 많은 한계를 가지고 있다. 대한민국이 아니라 미국이라면 어떨까? 거리의 제약은 수십배로 커진다. 많은 개발자들은 회사 근처로 이사를 하기도 하지만 재택 근무 형태로 일하는 개발자도 많다. 

재택 근무가 가능하면 회사에 꼭 필요한 개발자를 거리의 제약 없이 채용 할 수 있다. 같은 재택근무라도 상황에 따라서 근무 조건은 매우 다양하다. 일주일에 한번씩 출근을 하기도 하고 아예 원격으로 일하는 개발자들도 있다.

우리나라에서는 직장이 너무 멀어서 출퇴근에 2, 3시간씩 걸려도 아이들 학교 문제도 있고 직장을 옮길 때마다 이사를 하기는 쉽지가 않다. 그래서 개발자 채용에 거리 제약이 있고 회사에 꼭 필요한 개발자인데도 채용하기 어려운 경우도 많다. 

재택근무가 일반적이지 않은 이유는 옆에 앉아 같이 일하지 않으면 일이 제대로 진행되지도 않고 어떻게 일을 하고 있는지 알 수도 믿을 수도 없기 때문이다. 같이 모여서 일하지 않으면 일이 제대로 진행되지 않는다. 

필자는 여러 회사에서 강연이나 세미나를 할 때 종종 “여러분이 모두 회사에 나오지 않고 집에서 원격으로 일하면 어떻게 됩니까?”라는 질문을 한다. 100%의 회사들이 일이 전혀 제대로 진행되지 않을 것이라고 얘기를 한다. 개발자들은 허무맹랑한 질문이라는 표현을 하기도 한다. 이는 단지 재택근무가 가능한지 불가능한지 문제는 아니다. 

재택근무가 불가능한 회사는 문화적으로 프로세스적으로 개선할 점이 많은 회사다. 회사가 개발에 필요한 시스템을 잘 갖추고 있고 공유와 문서화가 잘 되어 있으면 재택근무는 그렇게 어려운 일이 아니다. 오히려 집에서 일하는 것이 더 효율적인 경우가 많다. 

재택근무가 불가능한 회사에서는 개발자들이 수시로 물어보고 의논을 하고 회의도 해야 한다고 한다. 이런 환경을 보면 회의가 너무 많고 공유와 문서화가 잘 안되어 있다는 것을 단적으로 알 수 있다. 문서나 시스템으로 대부분의 내용은 공유하고 대부분의 커뮤니케이션은 시스템을 통해서 해야 한다. 회의도 스카이프등을 이용해서 원격으로 할 수 있다. 

꼭 대면회의가 필요한 경우에 회사를 나오면 된다. 이런 환경이 갖춰지면 재택근무가 가능하다.

재택근무를 하면 개발자들이 열심히 일하는지 알 수 없어서 그렇게 할 수 없다는 회사 관계자도 만난 적이 있다. 하지만 회사에 있으면 열심히 일하는지 알 수 있는가? 시스템, 문화와 프로세스가 제대로 되어 있으면 개발 성과와 결과물이 시스템에 제대로 남고 동료 검토를 통해서 동료들이 서로 누가 어떻게 일하는지 다 알고 있다. 

옆에서 일하나 멀리서 일하나 다 알 수 있다. 하지만 그렇지 않으면 옆에서 일해도 커뮤니케이션이 어렵고 누가 열심히 일하고 누가 놀고 있는지 잘 알지 못하는 경우가 많다. 

지금 당장 이런 성숙된 문화와 효율적인 프로세스와 시스템을 갖추지 않고 재택근무를 추진한다면 어떻게 될까? 우려하고 있는 모든 문제가 드러날 것이다. 재택근무는 거리의 제약을 뛰어넘어 뛰어난 개발자를 채용할 수 있게도 할 뿐만 아니라 가정에 사정이 있는 개발자도 회사를 그만두지 않아도 된다. 

가정 사정상 아이를 돌보기 위해서 회사에 10시부터 3시까지 밖에 있지 못하는 뛰어난 개발자가 있다고 하자. 이렇게 일하는 것을 어떻게 허용할 것인가? 누구는 일주일에 이틀밖에 회사에 나올 수 없다고 하자. 이런 개발자가 회사에 꼭 필요한 사람이라면 채용해서 활용할 수 있을 것인가? 

재택근무는 그 자체로도 필요하고 회사의 문화나 프로세스의 성숙도를 가늠할 수 있는 지표로 볼 수도 있다. 필자는 회사에서는 야근을 별로 하지 않고 야간과 주말을 가리지 않고 회사의 시스템에 붙어서 이슈를 확인하고 의논을 하며 코드리뷰를 하는 등스스로 찾아서 일을 하는 것이 일상화 되어 있다. 가족이 나를 필요로 할 때 가족과 지낼 수 있으며 언제 어디서나 일할 준비가 되어 있고 일을 할 수 있다. 주말에도 굳이 회사에 나가지 않아도 원격으로 쉽게 일할 수 있다. 시간, 공간적인 제약은 별 문제가 되지 않는다. 

우리 회사는 개발자들의 재택근무가 가능하지 생각해보자. 현재는 어렵다는 생각이 든다면 그 이유가 회사에서 모여서 일할 때도 비슷한 문제를 가지고 있을 가능성이 높다. 어떻게 고쳐나가야 하는지 생각해보자. 재택근무가 가능한 시스템이 회사의 개발 문화 성숙도를 한층 높여줄 것이다.

이글은 ZDNet Korea에 기고한 글입니다.

개발 프로세스 관료화의 함정

소프트웨어를 효율적으로 개발하는 비법 아닌 비법은 개발 프로세스와 개발 문화의 적절한 균형에 있다. 김치를 담그는 레시피처럼 확실한 비율을 정하기는 어렵다. 개발 프로세스는 양날의 칼이다. 적절히 사용하면 개발 효율은 올라가지만 조금만 잘못 써도 개발 생산성이 떨어질 뿐만 아니라 개발자 성장까지 저해하여 회사와 개발자 모두의 미래를 어둡게 만든다.

다른 산업 분야에서는 외국에서 몇백년동안 쌓아온 것을 우리는 몇십년만에 따라 잡은 분야가 꽤 있다. 하지만 소프트웨어는 기껏해야 60년 역사인데 따라잡기가 훨씬 어렵다. 개별 개발자들의 프로그래밍 실력은 결코 뒤진다고 볼 수는 없다. 하지만 전반적인 개발문화의 차이가 격차를 좁히지 못하는 원인 중 하나다. 

소프트웨어 분야에 대한 투자는 개발자 인원수 늘리기와 프로세스 강화에 많이 치우친 경향이 있다. 소프트웨어도 시그마6 등과 같은 기법을 따와서 프로세스를 강화하면 좋은 성과를 낼 수 있을 것으로 착각했기 때문이다.

이렇게 프로세스에 집중하면 '파킨슨의 법칙'처럼 프로세스 관료화의 함정에 빠지기 쉽다. 프로세스는 회사의 변화에 따라 끊임없이 효율적으로 개선이 되어야 하는데 관료화된 조직은 프로세스가 점점 복잡해지지 단순해지지는 않는다. 프로세스가 단순해지고 효율적으로 바뀌면 일이 없어지는 사람이 있기 때문에 점점 복잡하게 만들려는 경향이 있다. 

물론 모든 기업이 그런 것은 아니다. 이런 함정에 빠지지 않은 기업도 있고, 이 단계를 극복해 나가는 기업이 있다는 것을 알고 있다. 하지만 많은 기업들이 이미 프로세스 관료화의 함정에 빠져서 허우적대거나 관료화의 길로 달려가고 있다. 이를 경계하자는 것이다.

그럼 개발 프로세스가 빠지기 쉬운 함정에는 어떤 것이 있는지 알아보자. 

첫째, 현실성이 부족한 프로세스다. 

실제 개발 현장에서는 벌어지지 않는 교과서에나 나오는 것을 실제 개발에 적용하려는 것이다. 가장 광범위하게 벌어지고 있는 현상 중 하나다. 인터넷에서 돌아다니는 지식이나 책을 보고 따라 하거나 소프트웨어 공학을 전공했지만 실전 경험이 부족한 경우 자주 벌어진다. 개발 단계별로 너무 많은 문서를 요구하거나 승인을 필요로 하는 프로세스가 있다. 

원자력 발전소를 만들 때나 필요함직한 문서들을 일반 소프트웨어에서 요구하기도 한다. 이런 문서는 개발할 때도 도움이 안되고 개발 후 유지보수 때도 별로 쓸모가 없게 된다. 마켓요구사항과 기능, 모듈을 추적하기 위해서 추적 매트릭스를 의무적으로 요구하는 프로세스도 있다. 

교과서에서 본적이 있을지는 몰라도 대부분의 소프트웨어에서는 필요도 없고 오히려 방해만 되는 프로세스다. 이렇듯 현실성이 부족한 프로세스는 너무나 흔하다. 개발자들은 어쩔 수 없이 따르는 척은 하지만 대부분 피해가는 요령만 늘게 되고 개발 경험이 쌓이면서 자연스럽게 역량이 성장하는 것을 방해하게 된다. 

개발 프로세스는 성숙된 개발환경에서 수십년 실전 경험이 풍부한 CTO급 개발자가 이끌어야 현실성 있고 효율적으로 만들 수 있다. 

둘째, 너무 상세하고 획일화된 프로세스다. 

프로세스팀이 너무 일을 열심히 하려고 할 때 발생한다. 프로세스는 모든 개발절차를 상세히 정의하기 보다 문제가 될 수 있는 핵심적인 요소를 잘 집어내는 것이 중요하다. 법률에도 비슷한 현상이 있다. 할 수 있는 것을 정의해서 법에 정한 것만 할 수 있게 하거나 하면 안되는 것을 정의해서 그 외에는 모두 할 수 있게 하는 방법이 있다.

모든 절차를 너무 상세하게 정의하면 개발자의 창의성을 저해하고 비효율적으로 흐를 수 있다. 오타 하나를 수정한 경우에도 작성해야 할 문서가 몇 개나 되고 절차도 일주일 이상 걸린다는 하소연을 들은 적이 있다. 개발자에게 자유도가 없이 몇 가지 경우로 획일화된 프로세스에서는 효율적으로 개발을 하기가 어렵다. 

개발자를 믿지 못하기 때문에 개발자에게 자유도를 주지 않는 경우이다. 

최근에 한 기업의 프로세스팀 리더를 만난 적이 있는데 설계문서를 매우 상세하게 작성을 해야 하며 꼭 UML로 작성을 해야 한다고 했다. UML을 이용하지 않고 개발자가 제각각 작성하면 서로 의미가 통하지 않을 수 있다고 한다. 나는 그럴 필요가 없고 개발자가 가장 편하게 작성할 수 있는 방법이면 되고 꼭 UML을 쓸 필요도 없다고 했다. 

화이트보드나 종이에 끄적거리고 토론하다가 사진을 찍어서 문서에 첨부해도 된다고 했다. 물론 이 부분은 논란이 있을 수 있다. 스펙과 설계의 경계에 대한 생각이 다르고 설계를 상세하게 작성해야 개발자들이 코딩을 잘 할 수 있다고 획일적으로 생각하는 것도 문제다. 

설계란 상황에 따라서 필요한 만큼 자유롭게 적절히 하는 것이 중요하고 형식보다는 창의력이 더 필요하다. 
셋째, 잘못된 관행을 그대로 담은 프로세스다.

프로세스팀의 힘이 약한 경우에 발생한다. 개발 프로세스를 정의할 때는 현재의 문제점을 고치고 개발역량을 미래지향적으로 향상시킬 수 있는 방법을 녹여내야 한다. 하지만 현재의 관행적인 절차를 체계화하고 문서화해서 기존의 문제점을 그대로 유지한다면 그야말로 최악이다. 

절차화 되면서 기존에 개발자들이 자유도를 가지고 적절하게 판단하던 효율성도 사라졌고, 미래지향적이지도 않다. 기존의 문제가 점점 고착화 되어 갈 뿐이다. 

개발자들의 의견을 너무 존중해서 민주적인 다수결로 프로세스를 결정하는 것도 문제다. 변화를 싫어하는 것은 동서고금 똑같아서 대중의 의견을 따르면 프로세스는 대부분 실패한다. 

넷째, 벌칙만 잔뜩 담은 프로세스다.

프로세스는 잘못하면 벌을 주려는 형법과는 다른 것이다. 목적 자체가 다르다. 프로세스는 효율적인 개발을 하기 위한 최소한의 절차다. 그리고 프로세스를 따라서 꾸준히 개발을 하면 개발팀의 역량도 향상 되어야 한다. 따라서 적절한 독려와 벌칙이 있을 수는 있다. 하지만 벌칙만 잔뜩 존재한다면 벌칙을 피해 다니는데 집중하게 된다. 물론 치명적인 잘못에 대해서는 벌칙이 있을 수 있다. 치명적인 잘못에는 다음과 같은 것들이 있다. 

-소스코드를 빌드가안되는브로큰 트리(Broken tree)를 만든 경우 
-백업 담당자가 백업을 소홀히 한 경우 
-소스코드를 소스코드관리시스템에 등록하지 않은 경우 
-핵심 프로세스를 따르지 않아서 큰 장애를 만들어 낸 경우 

여기서 버그를 만든 경우는 벌을 받아야 할 만큼 큰 잘못은 아니다. 그런데 버그를 카운트해서 불이익을 주거나 프로세스의 모든 사소한 사항까지 벌칙과 연계를 하면 숨막혀서 개발하기가 쉽지 않다. 

다섯째, 점점 복잡해지는 프로세스다. 

회사는 계속 바뀌고 제품 및 개발팀도 계속 성장한다. 그러면서 프로세스도 계속 진화를 한다. 그런데 매번 프로세스가 점점 복잡해지는 회사들이 많다. 무슨 문제가 있을 때마다 원인을 분석하고 대책을 수립한다고 하면서 확인 절차를 더 추가하고 문서를 더 만들어 내는 것이다. 

이렇게 문제가 있을 때마다 대책을 수립한다고 하면 초 단기적인 대책밖에는 만들어 낼 수 없다. 예를 들어서 근본 원인이 '공유의 문화'가 부족해서라고 해도 수년 걸리는 '공유의 문화' 개선보다는 당장 눈에 보이는 형식적인 절차를 끼워 넣을 수 밖에 없다. 

냄비 안의 개구리는 점점 따뜻해져 오는 물을 느끼지 못하지만 나중에 밖에서 프로세스를 보게 되면 괴상망측하게 변화된 것을 알 수 있다. 프로세스는 역량과 문화 수준이 향상됨에 따라서 점차 간소하게 바뀌어야 한다. 기존에는 프로세스로 강제화하던 것이 몸에 베이게 되면 간단하게 바꿔야 더 효율적이다. 

여섯째, 관료화된 프로세스다.

관료화된 조직에서 흔히 벌어지는 일이다. 개발 문제를 해결하기 위해서 프로세스를 강조하다 보면 프로세스 자체가 목적이 되기도 한다. 효율적인 방법이 눈에 뻔히 보이는 경우에도 프로세스가 그러하니 따라야 한다고 하게 된다. 개발 생산성 향상이라는 목표는 저 멀리 떠나 보내고 각자 팀의 이익을 쫓다 보면 프로세스가 점점 관료화로 치닫게 된다. 

가끔은 없어도 되는 절차를 일부러 만들기도 한다. 개발자들은 이를 피해가는 요령만 늘게 된다. 

물론 열심히 노력하고 잘하는 프로세스팀이 더 많지만 그 중에는 개발 효율성보다는 스스로의 일거리를 늘리고 힘을 키우기 위해서 프로세스를 더 복잡하게 만들고 개발에 끼어드는 경우가 있다. 프로세스팀이 모든 개발 절차를 감시하고 산출물을 검토하고 승인에 끼어드는 경우 관료화게 빠지기 쉽다. 도와주는 역할을 넘어서 스스로 권력화가 되는 것이다. 

결론은 개발 프로세스는 현실적이며 자율적이어야 하고 개발 문화와 균형을 이뤄야 한다. 아직 자율에 맡기기에는 불안하다고 하면 프로세스를 너무 복잡하게 하지 말고 핵심적인 것부터 조금씩 적용하는 것이 좋다. 
개발자가 즐겁게 일할 수 있는 환경이 가장 생산성이 높은 환경이다. 개발 프로세스를 엄격하게 강화하여 소프트웨어 개발 문제를 해결 할 수 있다는 생각부터 잘못된 것이다. 적절한 개발 문화가 뒷받침되지 않는 프로세스는 오히려 짐이 될 뿐이다. 

눈에 보이는 프로세스에는 투자를 하기가 쉬워도 눈에 잘 안 보이는 개발문화는 어떻게 투자를 해야 할지 막막하다. 자칫 잘못하면 사무실 환경이나 슬로건만 흉내를 내는 꼴이 될 수도 있다. 

문화가 바뀌려면 생각이 먼저 바뀌어야 행동이 바뀐다. 하지만 생각은 그렇게 쉽게 바뀌지 않는다. 힘이 있는 선구자가 끊임없이 생각의 변화를 이끌어야 한다. 프로세스가 관료화에 빠지지 않으려면 CTO급의 특급 개발자가 실전 개발 기법을 프로세스에 적용하고 개발문화 향상을 꾸준히 이끌 수 있도록 해야 한다. 

미신과 같은 이론 전문가들의 말과 인터넷에 떠도는 소문에 현혹되지 말고 진짜 전문가인 개발 전문가들을 보호하고 힘을 실어줄 때가 변화의 시작 시점일 것이다.

이글은 ZDNet Korea에 기고한 칼럼입니다.

주먹구구식 개발이 통하는 이유

우리나라의 많은 소프트웨어 회사들은 주먹구구식 개발에 대한 환상이 있다.

특히, 첫번째 시스템을 주먹구구식으로 개발을 해서 성공했는데 지금은 좀더 체계를 갖췄는데 더 개발이 잘 안된다면 과거 진짜 주먹구구식으로 개발할 때를 그리워하고 그 때로 돌아가고 싶어 한다.

여기 이와 관련된 과거 글이 있다. 

2012/07/26 - [소프트웨어이야기] - 옛날에는 개발을 더 잘했는데

주먹구구식으로 개발을 하다가 현재 체계를 갖추려고 노력하고 있다면 아직은 불완전할 뿐더러 반쯤은 주먹구구인 것이다. 그럼 주먹구구식 개발은 어떤 것인지 정의를 내려보자. 크게 5가지로 설명할 수 있다.

첫째, 스펙/설계 없이 개발을 하는 것이다. 또는 기능명세서, 시방서 등의 문서에 기능만 정리하여 개발하는 것이다. 이 방법은 프로젝트 전체 범위를 알 수 없을 뿐더러 좋은 아키텍처를 만들 수도 없고, 개발자들이 효과적으로 일을 나눠서 개발할 수도 없으며 프로젝트 진척상황을 거의 파악할 수 없다. 일정 지연은 일상이고 그야말로 끝나봐야 아는 것이다.

둘째, SVN, Git 등의 소스코드관리시스템과 Jira, Mantis, Redmine 등의 이슈관리시스템 없이 개발하는 것이다. 둘중 하나라도 사용하지 않으면 심각한 문제이다. 일단 쓰기만 하더라도 다행이지만 제대로 쓰는 것은 정말 어렵다. 대부분은 10% 정도의 기능밖에 사용하지 못하지만, 100% 기능을 활용해야 한다.

셋째, 혼자 북치고 장구치고 다하는 것이다. 일을 전문적으로 나눠서 하는 것이 아니고, 혼자서 기획, 분석, 설계, 코딩, 테스트, 빌드 등등 다 하는 것이고 이런 개발자가 여럿이고 서로 중복되서 일을 하기도 한다. 첫째에서도 언급했듯이 스펙이 제대로 작성되어야 일을 효과적으로 나눌 수 있는데 스펙이 없거나 부실하면 이런 현상이 벌어진다. 또, 회사의 조직이 소프트웨어 개발에 알맞게 효과적으로 구성되어 있지 않아도 이런 일이 벌어진다. 소프트웨어는 전문가들이 협업하여 개발하는 것이다.

넷째, 프로세스 없이 대충 개발하는 것이다. 흔히들 프로세스는 개발을 더 느리게 만든다고 주장하곤 한다. 그러면서 회사에서 프로세스를 만들려고 하면 반대 주장을 펼친다. 과거에 개발하던 방법을 서로 암묵적으로 알고 있다가 대충 개발을 하고 서로 이심전심으로 문제를 해결해 나간다.

다섯째, 리뷰, 공유 없이 개발하는 것이다. 가끔은 대충 기능목록 작성해서 마케팅이나 영업, 경영진과 리뷰를 하기도 하지만 제대로 된 리뷰는 아니다. 개발자를 제외하고는 지금 어떤 제품을 만드는지 정확하게 파악이 안된다. 심지어는 개발자들도 잘 모른다. 다 만들어봐야 어떤 제품을 만들었는지 알게 된다. 그러니 만들기 전에는 무슨 문제가 발생할지 몰라서 만드는 도중에 수많은 문제가 발생하고 재작업은 수시로 이루어 진다. 심지어는 80%쯤 만들었다가 아키텍처가 잘못된 것을 발견하고 다 버리고 다시 만들기도 한다.

정도의 차이는 있을 수 있다. 다섯가지 중에서 하나 이상이면 아직 주먹구구식 개발에서 완전히 벗어난 것이 아니다. 스스로도 주먹구구식으로 개발을 하고 있는지 평가를 해보자.

2008/10/29 - [소프트웨어이야기] - 소프트웨어 회사의 개발 역량 평가표

그럼에도 불구하고 주먹구구식 개발이 여전히 통하는 이유는 무엇일까?

첫째, Software의 크기가 아주 작다.

빌딩은 제대로 된 분석/설계 없이, 프로세스 없이 만드는 것은 불가능하다.

하지만 개집은 그런 것 필요 없다. 대충 만들어도 문제 없이 만들 수 있다. 한 사람이 머리 속으로 모든 것을 설계해서 만들 수 있는 정도의 규모라면 주먹구구식 방법도 훌륭한 방법이다.

둘째, 이직률이 극도로 낮다.

한번 개발을 해 놓으면 개발자들이 절대로 퇴사를 하지 않고 끝까지 책임져준다. 

셋째, 회사 규모가 작다.

개발자도 몇 명 안되서 서로 너무 잘 알고 모든 이슈가 더 구두로도 공유가 되고 급한 이슈는 자리에서 바로 일어나서 공유가 되고 논의할 수 있다. 가족적인 분위기에서 주먹구구식 방법이 훌륭하게 작동한다.

넷째, 소프트웨어 업그레이드가 없다.

한번 개발해 놓은 시스템이 업그레이드가 필요 없는 경우이다. 어떻게 든 첫번째 개발을 해 놓으면 문제가 없다.

그럼, 주먹구구식 개발이 앞으로도 계속 통할까?

회사가 잘되면 회사는 커지게 되어 있다. 개발자 수는 많이 늘게 되고 더 이상 자리에서 일어나 뒤로 돌아도 모든 개발자의 얼굴을 볼 수 없게 된다. 과거처럼 공유가 그렇게 잘 되지 않는다.

개발자들이 영원히 이직하지 않고 직원으로 있기를 바란다면 너무 큰 욕심이다. 개발자들은 언젠가는 이직을 하게 마련이고, 개발자들이 이직을 해도 개발은 잘 돌아가도록 되어 있어야 한다. 주먹구구식으로 계속 개발을 하게 된다면 아무리 가족적인 분위기라고 하더라도 직원이 Risk 요인이 된다.

Software 회사의 경영자라면 지금 대충 잘 굴러가는 것 같다고 해서 방심하면 안된다. 회사가 잘 되면 회사는 커지고 직원도 늘고 더 복잡해질 것이다. 문제를 모르고 방심하다가 문제가 터지고 나면 터진 댐을 막으려고 하는 것처럼 어렵다. 항상 미리 준비를 해야 하는 것이다.

물론, 처음부터 제대로 하는 것이 가장 빨리 개발하는 방법이고 좋지만 그것을 깨닫기는 매우 어렵다. 대부분은 문제가 터진 후에 우왕좌왕 한다. 주먹구구식 개발이 지금은 통할지도 모른다. 하지만 곧 주먹구구식 개발이 문제가 되는 상황이 올 것이고 이미 문제가 되고 있다면 너무 늦지 않았기만 바랄 뿐이다. 늦었다고 생각할 때가 가장 빠른 때이다.

한 SI회사의 프로세스에 대한 오해

필자는 업계의 여러 사람과 얘기할 기회가 많다.

최근에 한 대형 SI회사의 한 PM과 얘기를 한 적이 있는데 프로세스 상의 큰 문제가 있었고, 실제 프로젝트팀에서는 잘못된 프로세스로 인해서 어려움을 겪고 있었다.

SI회사의 오랜 바람 중의 하나가 "공정분리"이다. 즉, 분석/설계/구현을 분리해서 프로젝트를 진행하는 것이다.

"공정분리"가 되지 않은 상태에서는 분석/설계/구현이 뒤엉켜서 개발을 진행한다.

"공정분리"는 분석을 잘해서 설계자에게 넘겨주면, 설계자는 설계를 잘해서 개발자에게 넘겨주고 개발자들은 설계서 그대로 코딩만 하면 되도록 하려는 것이다.

최근 해외 프로젝트가 증가하면서 분석/설계/구현을 뒤엉켜서 진행할 경우 코딩하는 개발자까지 해외 파견을 해야 한다. 그래서 공정분리는 점점 필수가 되었다.

그래서 진행한 것이 해외에서 "분석/설계"를 잘 해서 넘겨주면 국내에서는 개발자들은 그대로 "구현"만 하면 되도록 하는 프로세스를 만든 것이다.

실제로 이 프로세스는 잘 작동하지 않고 있다고 한다. 그동안 해오던 방법과 역량이 분석/설계를 해도 "구현"은 이와 상관없이 알아서 진행하고 모르면 분석가에게 물어가면서 코딩하던 수준이었다. 이런 상황에서 이 프로세스가 잘 작동할리가 만무하다.

이렇게 공정을 분리하려면 "분석/설계" vs "구현" 보다는 "분석" vs "설계/구현"이 더 낫다.

설계가 구현에 좀더 가깝고, 잘된 분석서를 가지고 충분히 "설계/구현"을 할 수 있기 때문이다.

여기서 또 오해가 있는 것이 설계를 잘해서 넘겨주면 그대로 코딩만 하면 될 줄 아는 것이다. 현실에서는 이렇게 잘 진행되지 않는다. 이렇게 하기 위해서는 설계를 너무 자세히 적어야 하고 실제 구현시 많은 문제를 발견하게 된다.

더 좋은 방법은 설계는 꼭 필요한 만큼만하고 구현에 적당한 자유도를 주는 것이다. 

이렇게 제대로 "공정분리"를 하기 위해서 대전제가 하나 있다. 

바로 "분석"역량이 뛰어나야 한다는 것이다. 뛰어난 분석가를 많이 보유하고 있어야 한다.

현재의 분석역량은 기껏해야 "기능"분석과 약간의 "비기능"을 분석하는데 그치고 있다. 분석이 무엇인지 짧은 글에 일일이 설명하기는 어렵지만 분석은 이보다 훨씬 크고 어려운 일이다. 비즈니스전략도 포함해야 하고, 설계도 일부 포함한다. 

필자의 생각으로는 이 SI회사는 당분간 프로세스의 시행착오를 좀더 겪을 것으로 생각된다. 잘못된 프로세스를 바로 잡는데 시간이 걸릴 것이고, 분석역량을 끌어 올리는 일에 시간이 좀더 걸릴 것이다.

시행착오를 겪는 시간은 짧을수록 좋다.

획일화된 프로세스의 함정

SW를 개발하는데 있어서 체계화된 프로세스가 필요하다는 것은 당연하다.

대부분의 SW회사가 최소한의 프로세스도 없이 주먹구구식으로 SW를 개발한다. 작은 회사들은 문제가 안되는 것처럼 보이지만 회사가 조금만 커져도 여기저기서 문제가 발생하다.

이런 문제에 시달리다보면 프로세스와 문서화가 이 문제를 해결해 줄것이라고 너무 믿게 된다.
그래서 엄격한 프로세스를 만들고 각 프로세스마다 문서를 꼭 만들게 하고 검사를 하기도 한다. 물론 프로젝트의 종류에 따라서 만드는 필수문서를 다르게 하기도 하지만, 이러한 규정은 개발자들이 요리조리 프로세스를 피해가는데 활용이 되곤 한다.

프로젝트에서 꼭 필요한 문서를 획일적으로 정하는 것은 매우 어렵다. 프로젝트 팀에서 결정하고 이를 존중하는 것이 좋다. 하지만 아직 개발팀의 역량이 부족하고 문화가 부족하다면 개발팀의 결정을 따르기도 어렵다.

가장 좋은 방법은 회사가 작을 때부터 체계적으로 개발하는 방법을 익히고 스펙과 설계를 적절하게 작성해가면서 개발문화를 키워나가고 개발자들의 역량이 같이 커져가는 것이다. 그렇게 되면 회사가 커져도 좀더 복잡한 프로세를 자율적으로 운영할 수 있게 된다.

하지만 대부분이 회사는 이러한 기회를 놓치게 된다.
그래서 택하는 것이 획일화된 프로세스이다. 이 고통스러운 프로세스를 거쳐서 이겨내면 점점 자율적인 프로세스로 바뀌게 되지만 이를 극복하지 못하면 점점 더 복잡하고 엄격한 프로세스를 만들게 된다.

가장 좋은 방법은 회사가 성장함에 따라서 문제가 생기기 이전에 미리 체계를 갖추고 개발자들의 역량을 키우는 것이고, 이미 문제가 발생했다면 최소한의 프로세스만을 만들고 지금이라고 개발자들이 분석, 설계 역량을 키울 수 있도록 회사에서 지원하는 것이다.

소프트웨어 관료화

"공무원 수는 해야 할 일의 경중이나 업무 유무에 관계없이 일정한 비율로 증가한다", "공무원은 서로를 위하여 서로 일을 만들어 낸다", "유능하지 못한 사람은 공무원이 된다."

이는 그 유명한 파킨슨의 법칙입니다.

소프트웨어를 개발할 때도 이와 같은 함정이 도사리고 있습니다.

주먹구구식으로 소프트웨어를 개발하다가 체계적으로 개발하고 싶은 요구가 생길 때 프로세스팀을 구축하고 개발 프로세스를 정립하다 보면 파킨슨의 법칙에 빠지기 쉽습니다. 

프로세스팀의 구성원들은 진짜 소프트웨어 전문가로 구성되는 경우가 드믑니다. 여기서 말하는 소프트웨어 전문가란 코딩만 잘하는 개발자가 아니고, 구축, 설계, 테스트, 형상관리, 버그 추적, 빌드, 릴리즈, 방법론 등 소프트웨어 관련 여러 분야의 지식과 경험을 두루 갖추고 있는 사람입니다.

이런 비전문가로 구성된 프로세스 팀은 소프트웨어 개발의 내용을 속속들이 잘 모르고 너무 형식에 치우칠 수 있고, 끊임없이 프로세스팀이 할 일을 만들어 내기 위해서 프로세스를 점점 복잡하게 만들곤 합니다. 이들은 어떤 것이 정확하게 올바른 방법인지 잘 몰라서 그렇게 하기도 하고, 자신들의 밥줄을 견고하게 하기 위해서 여기저기 승인 절차를 많이 추가해서 프로세스팀이 소프트웨어 개발 프로세스의 중요한 역할을 하고자 한다.

프로세스팀은 소프트웨어를 효율적으로 개발하기 위한 방법들을 연구하지만 소프트웨어 개발 프로세스 중간에 직접 끼어들어서 간섭하는 프로세스를 만드는 것은 바람직하지 않다. 소프트웨어를 개발하는데 있어서 여기저기 승인 절차를 잔뜩 집어 넣어 놓는 것도 그리 좋지 않습니다. 승인 절차가 소프트웨어의 무결성을 보장해주진 않습니다. 오히려 관료화된 승인 절차는 아무런 도움이 되지 않는 경우가 많습니다. 소프트웨어는 각 분야의 전문가들이 자율적으로 효과적으로 움직였을 때 가장 효율적으로 개발됩니다. 명시적인 승인 절차가 없더라 승인절차를 거친 것과 같이 모두가 진행상황을 훤히 알 수 있게 됩니다. 이렇게 개발되는 방식이 오히려 소프트웨어 무결성에 더 도움이 됩니다. 승인 절차는 형식적인 승인이 되기 쉽지만, 각 단계의 전문가들이 리뷰를 하고 Unit 테스트를 하고 시스템 테스트를 하고 빌드전문가가 확인을 하고 이러한 전 과정을 통해서 문제가 되는 것들은 발견이 되고 개발도 효율적으로 진행됩니다.

소프트웨어 개발 경험이 부족한 프로세스 팀은 철저한 승인 절차가 아니면 안전한 소프트웨어를 개발하기 어려울 것 같이 생각되지만, 이는 경험 부족에서 오는 착각이거나 관료화의 조짐입니다.

또 소프트웨어 개발에 대한 이해가 부족한 경영자들은 이들이 주장하는 프로세스가 그럴듯해 보이지만 사실은 소프트웨어 개발에 상당부분 걸림돌이 되고 있다는 것을 눈치채기 어렵습니다.

진짜 소프트웨어 전문가로 프로세스팀을 만들 것이 아니면 내부에서 진행하는 여러 개선 시도들이 시간 낭비인 경우 많고, 시행착오 없이 6개월이면 갖출 수 있는 경쟁력을 먼 거리를 돌아서 수년이 걸리거나 영영 경쟁력을 갖추지 못하는 경우도 많습니다. 프로세스팀을 갖추려면 소프트웨어 전문가로 구성을 하거나 내부에 전문가가 없다면 외부에서 도움을 받는 것이 좋습니다.

회사 내에서 소프트웨어 개발을 잘 하는 개발자가 소프트웨어 전문가라고 생각하지는 마세요. 공을 잘 차는 축구 선수일 뿐입니다.  

악순환 vs. 선순환

지난번 글 (이 바닥을 못 벗어 난다.)의 추가 글입니다.

회사가 Risk가 큼에도 불구하고 Domain 지식이 점점 더 매달릴 수 밖에 없는 이유와 선순환을 하려면 어떻게 해야 하는지 좀더 현실감 있는 예를 보여주려고 합니다.

회사마다 상황이 모두 다르기 때문에 각자의 상황과 1:1로 다 일치하지는 않지만 참고하실 수는 있을 겁니다.

그럼 악순환과 선순환에 대해서 알아보죠.

Domain 지식에 점점 매달리게 되는 악순환의 고리

• 주먹구구식 개발
• 개발자에 의존한 코딩 중심의 개발 주도
• 없거나 빈약한 개발 프로세스 및 개발 문서
• 회사의 지식은 개발자 머리 속에 보관
• 개발자 간 지식의 공유가 어려움
• 후배 개발자들에게 지식 전달이 잘 안됨
• 프로젝트가 커질수록 협업이 점점 어려워짐
• 점점 더 경험 많은 개발자에 의존하게 됨
• 경험 많은 개발자는 계속 더 바빠짐
• 경험 많은 개발자들도 체계적인 개발은 꿈도 못 꾸고 매일 밑바닥 개발에 매달림
• 개발자들이 Domain 지식은 점점 늘어가는데 소프트웨어 공학지식은 잘 늘지 않음
• 회사에서는 신규 직원을 뽑아도 같이 협업이 잘 안되므로, 동일 Domain의 경험이 많은 개발자를 선호하게 됨
• 경험 많은 개발자들이 퇴사를 해서 회사가 큰 타격을 입기도 함
• 또 고참 개발자들이 퇴사할 까봐 전전긍긍하게 됨
• 회사에서는 개발자들의 머리 속에 있는 지식을 공유하고 체계적으로 개발하고 싶으나 방법을 모름
• 이에 대한 개혁을 해보려고 해도 번번히 고참 개발자들의 방해로 무산됨
• 점점 더 경험 많고 Domain 지식이 풍부한 개발자들에게 의존하게 됨
• 규모 있는 개발을 못하고 인원수에 의존한 개발을 하게 됨
• 회사는 성장을 못하고 정체하게 됨
• 고참 개발자들은 성장을 못하고 매일 밑바닥 코딩과 문제 해결에 매달리게 됨
• 또 주먹구구식, 가내 수공업식 개발을 반복하게 됨

프로세스 중심의 선순환의 고리

• 회사가 소프트웨어 개발에 필요한 적절한 프로세스와 인프라스트럭처 시스템을 갖추고 있다.
• 개발자들은 프로세스 중심으로 개발이 되도록 잘 훈련 되어 있다.
• 프로젝트 진행 시 꼭 필요한 스펙 문서와 설계 문서를 적절하게 만든다.
• 문서와 코드에 대해서 적절히 Peer review가 이루어져서 지식의 전달이 잘 되고 결함이 사전에 제거된다.
• 고참 개발자들은 코딩 보다는 주로 아키텍처와 비즈니스에 대해서 고민하고 해결한다.
• 잘 작성된 스펙 문서와 설계 문서를 보고 후배 개발자들이 코딩하고 테스트 팀이 테스트를 진행한다.
• 고참 개발자들은 오랜 개발 경력으로 Domain 지식도 풍부하지만 소프트웨어 공학 지식 및 경험도 풍부하다.
• 후배 개발자들은 Domain 지식은 부족하지만, 설계 문서를 보고 인프라스트럭처 시스템을 활용해서 프로세스에 따라 개발하는데 별 문제가 없다.
• 신규 개발자를 뽑아도 교육이 용이하고 바로 실무에 투입하기가 쉽다.
• 고참 개발자들이 퇴사를 해도 상당히 많은 지식이 문서화 되고 이미 후배들에게 전파가 되어 있으므로 회사의 타격이 상대적으로 적다.
• 퇴사한 고참 개발자들은 이직이 용이하고 더 높은 연봉으로 타 회사로 옮길 수 있다.
• 회사에서는 Domain 지식이 너무 매달리지 않고, 실제로 Software 공학 지식이 뛰어나고 Software 개발 자체를 잘하는 인재를 선호하게 된다.
• 회사가 성장하고 개발 규모가 커져도 문제 없이 대응할 수 있다.

그럼 악순환에서 선순환으로 바뀌는 방법에 대해서 의문을 가질 수 밖에 없습니다.

이는 참 어려운 숙제입니다.

운동을 안한다. -> 몸이 무거워진다. -> 운동을 더 안한다. -> 몸이 더 무거워진다.

이런 악순환의 고리를 끝는 것은 무엇을 까요? 일단 운동을 시작한다? 99%는 실패할 겁니다.

운동은 습관도 안들어 있고, 제대로 운동하는 방법도 모르고, 또 귀찮아지면 언제든지 포기하고, 잘못된 운동 방법으로 다칠 수도 있습니다. 그러면 운동에 대한 나쁜 기억만 쌓이고 다음번에는 더욱더 운동을 시도하지 않게 될 겁니다.

그래서 악순환의 고리를 끝는 것을 쉽게 얘기를 할 수 있어도 현실적으로 가능한 방법을 제시하는 것은 쉽지 않습니다. 물론 가장 적절한 방법도 회사마다 다릅니다.

하지만, 악순환의 고리를 끝는 방법 중에서 필수 요소는 경영자의 의지입니다. 경영자가 이러한 상황을 전혀 이해 못하고 있거나 의지가 없다면 그냥 계속 악순환의 고리를 돌면서 영업이나 잘하는 수 밖에 없습니다.

개발자들이 으쌰으쌰해서 점진적으로 개혁을 해보려는 시도는 매우 더딜뿐만 아니라 다양한 도전 및 방해로 무산될 가능성이 큽니다. 그래도 그런 과정에서 개발자들이 본인 스스로 공부는 될 수 있겠네요.

경영자가 의지만 있다면, 조직, 시스템, 프로세스적인 다양한 측면에서 효과적이고 적절한 개혁을 시도하여 회사를 바꿔나가서 점점 선순환의 고리로 옮겨 갈 수 있습니다. 

거만한 속빈 강정

소프트웨어 개발 경험도 개발자가 미국 실리콘밸리의 소프트웨어 회사에 입사해서 5년이면 배울 수 있는 것(소프트웨어를 개발하는 방법)을 우리나라에서는 10년, 20년 아니 30년을 소프트웨어만 개발해도 배우지 못합니다.

오히려 이런 경험 많은 고참 개발자들은 배울 수 있는 기회가 눈앞에 와도 배울 수가 없게 됩니다.

책을 하나 봐도 대부분 아는 내용이라고 저자를 평가 절하하지만 아는 수준이라는 것이 용어 한번 들어보고 샘플 좀 사용해 본 정도인 경우가 대부분입니다.

예를 들어 소스코드관리시스템에 대한 내용을 봐도 내가 대형SI회사에서 10년 넘게 개발을 했는데, 이런 것을 모를까봐?라고 생각하지만 고작 소스코드 백업 받듯이 저장하고 태깅 좀 한 정도 가지고 소스코드 관리를 제대로 하고 있다고 착각합니다. 

오히려 이러한 개발자들은 온갖 화려한 기술과 온갖 툴 및 기법에 능숙해서 UML의 도사이고 자신은 아키텍트라고 하면서도 진짜 설계는 할 줄도 모릅니다. 이런 고참 개발자들은 아무것도 모르는 신참 개발자보다 제대로 배우기는 훨씬 어렵습니다. 신참 개발자들은 책이나 강연을 통해서 배움이 기회가 왔을 때 자신은 잘 모르고 부족하다고 생각을 하기 때문에 받아드리려는 마음이 있으나 이런 고참 개발자들은 자신들이 잘 알고 개발을 잘하고 있다고 착각하기 때문에 즉 자신의 무지를 모르기 때문에 배움을 받아드리려고 하지 않습니다. 또 자신이 해왔던 방식이 나름대로 편하다고 생각해서 바꾸기를 싫어하고 괜히 바꿨다가 회사에서 자신의 위상이 흔들리면 어떡할까 하는 걱정도 하곤 합니다.

2,3년 된 신참 개발자들은 회사에서 제대로 된 개발 환경 및 교육의 기회만 주어진다면 4,5년 안에 이런 고참 개발자들보다 훨씬 뛰어난 실력을 갖는 것은 그리 어려운 일이 아닙니다. 또 배우려고 하지 않는 고참개발자들은 세계 최고의 소프트웨어 대가가 와도 이들을 가르칠 수는 없습니다. 그냥 그렇게 회사에서 정치나 하면서 연명을 하는 수밖에 없습니다. 다른 회사로 이직을 하면 자신의 위상이 확 떨어지니 회사에 꼭 붙어 있어야겠지요. 물론 은퇴 전에 회사가 망하면 큰 일지만 말입니다. 

그런 일을 당하지 않으려면 마음을 바꿔 먹어야 합니다. 물론 정말 실력이 뛰어난 개발자들도 많이 있지만, 자신이 소프트웨어 개발을 잘하고 있다고 착각하는 고참개발자들은 늦었지만, 바뀌어야 합니다. 

자신이 정말로 뛰어난 개발자인지? 뛰어나다고 착각하는 것인지? 어떻게 아냐고요?

후배 개발자들이 많이 있는데 아직도 주로 코딩에만 매달리면서 자신이 코딩을 하지 않으면 개발이 잘 안될 것 같습니까?  문서를 만들면서 개발을 하는 것보다 코딩부터 개발을 하고 문서는 불필요하다고 생각하시나요? 문서를 만들어도 다른 개발자들이 이해를 잘 못하나요?  자신은 개발을 정말 잘하는데 후배 개발자들은 정말 실력이 떨어진다고 생각이 드나요? 후배들이 실력이 딸려서 같이 일하기 정말 힘듭니까? 후배들에게 잘 설명해줘도 원하는대로 개발이 진행이 잘 안됩니까? 개발은 기가 막히게 하는데 회사의 비즈니스 상황은 잘 모르나요? 개발에만 집중하고 소프트웨어 기획, 테스트, 배포 등의 전반의 내용은 잘 모르나요? 해당 Domain 지식(업무지식)에 대해서 도사급이라 다른 업계로 이직은 싫은가요? 소스코드관리, 버그관리는 기초기능만 사용하나요? (기초의 기준이 뭔지 알기 어렵겠군요.) 개발프로세스는 불필요하거나 불편한 것이라고 생각하시나요? 경영자들에게 기술이나 아이디어를 설명해도 경영자들이 이해를 잘 못하나요?

너무 많아서 다 나열할 수가 없네요. 

이중에 몇 가지만 해당해도 착각하고 있는 것일 가능성이 대단히 높습니다. 착각에서 빨리 벗어나는 것이 자신의 미래를 위해서 이롭습니다.