2014년 1월 22일 수요일

실리콘밸리 개발자 눈에 비친 한국 SW회사

얼마 전 실리콘밸리의 한 개발자 B씨를 만나서 소프트웨어 개발에 대해 많은 얘기를 나눴다. 과거에 같이 일했던 친구인데 미국에서 태어난 중국인으로 미국 대학을 나와 실리콘밸리에서 20여년간 개발자로 일을 했으며 10여년간은 몇몇 회사에서 CTO로 있었던 친구다. 

B씨는 최근에 한국 소프트웨어 회사(가칭 A사)와 많은 교류를 한 모양이다. 한국 회사에 자사 기술을 전수하기 위해서 실리콘밸리와 한국을 오가며 수개월간 한국 개발자들과 같이 개발을 해왔다고 한다. 그 과정에서 A사에 대해서 느낀 점을 필자에게 얘기를 해줬는데 A사 뿐만 아니라 우리나라 여러 회사에 공통적으로 해당하는 내용이 있어 소개할까 한다. 

B씨는 일단 처음에 A사가 어떻게 돌아가는지 파악했다.  그런데 이상한 생각이 들었다고 한다. 규모가 꽤 큰 서비스인데 시스템에 버그가 너무 많고 문제가 자주 발생한 것이다.

직원들의 야근도 너무 잦았다. 또 스크럼을 도입해 개발한다고 하는데 제대로 효과를 보는 것 같지는 않아 보였다. 그런만큼 B씨는 A사가 스크럼이든 설계든 개발 절차에 담긴 진의를 파악하지 못하고 형식만 흉내를 내는 것이 아닌가 생각이 들었다고 한다. 

이에 나는 B씨에게 “설계에서 제일 중요한 것이 무엇인가?”라고 질문했다. B씨는 “설계에서 제일 중요한 것은 콤포넌트를 잘 나누는 것”이라는 당연한 얘기를 했다.

B씨는 계속 얘기를 했다. 설계에 UML을 사용했는데 보통 UML은 필요가 없다. 우리는 대부분 칠판에 설계를 하다가 고치기를 반복한 후 사진을 찍어서 문서에 포함한다. 툴을 이용해서 다시 그리는 것은 시간 낭비다. 마지막 버전을 툴로 그리기도 하는데 정해진 툴도 없다. UML을 이용해서 쓸모도 없는 다이어그램을 잔뜩 만든 문서는 개발에 도움이 안되고 오히려 방해가 된다. 툴을 이용하면 칠판보다 고치기가 어렵고 다이어그램을 많이 그릴수록 고치는데 시간이 많이 들어가 바로 고칠 수가 없다. 또 A사 설계는 콤포넌트가 명확히 구분되어 있지 않아서 나눠서 협업하기 어려웠고 반대로 설계 내용은 너무 상세해서 오히려 비효율적이었다. 

나도 동감을 했다. 개발자가 알아서 할 부분까지 설계를 할 필요는 없다. 겉보기에는 A사의 설계서가 실리콘밸리의 한 개발자가 칠판에 끄적거린 설계서보다 멋져 보이고 전문적인 것 같지만 실전에선 훨씬 비효율적이다.  

설계를 어떻게 해야 하는지는 소프트웨어 성격에 따라 다르지만 설계 원리와 진의를 모르고 많은 다이어그램과 상세한 설계서는 식제 개발을 할때는 별로 도움이 되지 않는다. 많은 회사들이 UML 등을 이용해 완벽한 설계서를 만들려고 하는 경우가  많은데 그런 시도가 성공적이었는지 생각해볼 필요가 있다. 

B씨가 A사에 대해 또 이상하게 생각한 것은 애자일(Agile)을 적용한 방식이다. 실리콘밸리 스타트업은 거의 대부분 애자일 개발 방법론을 적용하고 있다고 보면 된다. 애자일은 특별한 것이 아니다. 과거부터 해오던 방식과 비슷하다. XP를 도입한 회사도 있고 스크럼을 쓰는 회사도 있는데 회사마다 필요한 것을 활용하고 있다. B씨 회사는 XP의 페어 프로그래밍(Pair programming)과 TDD를 사용중이다. 

과거 프로젝트에서는SRS를 썼는데 지금은 TDD로 바꿨다. 테스트는 거의 자동화 되어 있고 별도 테스터가 없어도 시스템에 버그는 거의 없다. A사의 경우 컨설팅을 받아 애자일을 적용했는데 들어보면 별로 애자일스럽지 않아 보인다. 마케팅적으로 요구사항이 신속히 바뀔 뿐인 것 같다. 

시스템이 복잡하여 야근도 잦은 것 같다. 또 개발자의 자유도도 낮아 보인다. 쓸데없는 문서도 많이 만들어야 하고 테스트도 오래 걸린다. 그러다 보니 시스템에는 항상 버그가 잔뜩 있다. 

이상한 점은 또 있다. 비싼 툴을 너무 많이 쓴다는 것이다. 그 친구는 실리콘밸리에서 주로 스타트업 에 많이 다녔는데, 한국 회사처럼 툴을 그렇게 많이 사용하지는 않았다고 한다. 지금 다니는 회사는 서브버전(Subversion)과 트랙(Trac)만 쓰고 있는데 회사를 지금 시작했다면 Git를 선택했을 것이라고 한다. 그렇다고 굳이 지금 서브버전을 Git로 바꿀 생각은 없다. 

나머지 필요한 툴은 간단한 스크립트로 만들어서 쓰고 있다. 그에 비해 A사를 비롯해서 많은 한국 회사들은 일단 툴을 많이 사용한다.  비싼 툴을 사는 경우도 상당히 많다. 회사 역량에 비해서 툴을 과도하게 사용하는 것은 그렇게 효율적이지 않다. 툴은 하나를 쓰더라도 제대로 사용해야 한다. 

그리고 A사는 직원들에게 노트북을 지급했다고 하는데 직원들이 노트북을 집에 가져가서 일을 하지 않는 점이 이상하다. 실리콘밸리에서 스타트업에 다니는 개발자들은 거의 노트북을 집에 가져가서 장소를 구분하지 않고 일을 한다. 개발자마다 다르지만 그 친구는 늦게 출근하고 일찍 퇴근하지만 노트북을 가지고 다니면서 장소에 구애 받지 않고 하루에 10시간 이상 일을 한다고 한다. 

A사는 야근도 꽤 많이 하지만 집에 가서는 일을 하지 않는 것이 이상해 보였다. 한국의 모든 개발자가 그런 것은 아니지만 재택근무가 일상화된 실리콘밸리와 한국은 좀 다른 것 같다. 

물론 한 개인이 한 회사를 보고 느낀 점을 얘기한 것이기 때문에 우리나라의 모든 회사가 그렇다는 것은 아니다. 그렇지만 B씨와 나눈 얘기들에서 생각해 볼 요소는 많다. 국내 여러 기업이 실리콘밸리의 개발문화와 개발방식을 적용하려고 노력하고 있지만 대부분 원리와 의미는 파악하지 못하고 수박 겉핧기 식으로 형식만 흉내를 내고 있다. 

설계는 하지만 설계를 왜 하는지를 잘 모르고 애자일을 적용하면서 그 원리를 모르고 남들은 어떻게 하는지 보고 흉내를 내는 것이다. 원리는 같지만 회사마다 적용하는 방식이 다르기 때문에 남들을 보고 흉내 내거나 인터넷이나 책을 보고 적용하면 이런 현상이 벌어진다. 

단순 흉내에서 벗어나려면 무엇을 하나 하더라도 그 진의를 파악하는데 노력해야 한다. 주변에서 흔히 "남들은 어떻게 하나요?", "템플릿(Template)을 가져다 주면 해볼께요.", "샘플을 보여주세요."와 같은 얘기를 한다. 남들이 만들어 놓은 설계서 샘플을 가져다가 흉내를 내면 자칫 아니 한만 못한 경우도 많다. 샘플이 득보다는 독이 되는 경우가 많다. 

샘플보다는 이걸 왜 하는지 원리를 파악하려고 노력해야 한다. 스스로 진의를 파악하기 어렵다면 주변에 멘토가 될만한 사람에게 물어보고 도움을 받는 것이 좋다.

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

2014년 1월 18일 토요일

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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