오늘의 잡담 - 개발자와 영어

이 소프트웨어라는 것이 미국에서 처음 만들어지다 보니 엄청나게 많은 자료들이 영어로 되어 있고, 대부분의 커뮤니케이션의 영어로 진행되고 영어가 마치 소프트웨어 업계에서는 표준어가 된 듯합니다.

나 자신도 영어를 지독히 싫어했고, 최근 2,3년간 영어 공부에 열을 올리고 있지만, 제가 처음 소프트웨어를 시작할 때부터 영어를 잘했다면은 지금 내 모습이 달라졌을 것을 생각합니다.

대부분의 프로그래밍 언어가 영어 기반이고, 메뉴얼 원본은 다 영어인데, 영어로 된 원서를 읽으려면 번역서보다 10배이상 속도도 느리고 이해가 잘 안되니 항상 번역서만 찾아 다녔었던 기억이 납니다.

이제와서 뛰어난 개발자가 되려면 영어도 잘해야 한다고 말하기도 쑥스럽지만, 영어를 유창하게 하지 못하는 개발자는 이미 기회를 반쯤 버리고 경쟁하는 것과 같다고 생각합니다.

일단 소프트웨어 업계로 들어서면 너무 바빠지는 것이 일반적이라서 개발자가 왠만해서는 영어 공부를 하기 쉽지 않습니다. 학교 다닐 때 미리미리 영어 공부 유창하게 될 때까지 하고 오세요.

이미 개발자로 일하고 있고, 영어가 부족하다면 음... 알아서 꾸준히 공부하세요.

참고로 제 개인 블로그(http://raymond.pe.kr)에서는 영어 공부에 대한 주제로도 글을 꾸준히 올리고 있습니다. 혹시 영어 공부에 관심이 있으시다면 미미하나마 도움이 되면 좋겠네요.

"영어는 가까이하기엔 너무 먼 당신이다" - 매우 다가갔다고 생각하면 어느덧 또 멀어져 있는.......

이 소스코드는 나 밖에 못 건드려!

"우리 팀은 각자 맡고 있는 소스코드가 다 달라서 서로 충돌 날 일이 전혀 없어요"

"이 소스코드를 수정해야 하면 나한테 얘기해, 내가 고쳐 줄게"

"내가 지금 고치고 있으니 너도 고치려면 내가 끝낼 때까지 기다려"

"지금 이거 한창 고치고 있으니 중간에 다른 것은 끼어들 수 없어요. 이거 다 끝날 때까지 기다려주세요."

이와 같은 현상이 친숙하나요? 그럼 Parallel

Development(병행개발)와는 거리가 멉니다.
Development를 제대로 수행하려면 소스코드관리시스템을 단순히 소스코드 저장소 용도로 사용해서는 부족합니다. 소스코드관리시스템을 제대로 사용하기 위한 프로세스와 규칙이 필요하며 Branch와 Tag, Merge를 용도에 맞게 능숙하게 사용할 수 있어야 합니다.

개발을 이런 식으로 순차적으로 기다렸다가 해야 한다거나 다른 사람이 이 소스코드를 고치고 있지 않은지 걱정을 하고 있거나 이것 때문에 소스코드를 고칠 때 항상 Lock을 걸어야 한다면 이만 저만 불편한 것이 아닙니다. 개발 속도도 떨어지게 됩니다.

아키텍처적인 이슈를 제외하고는 개발자들은 서로 같은 소스코드를 얼마든지 동시에 수정할 수 있고, 소스코드가 충돌이 일어나더라도 얼마든지 쉽게 해결할 수 있어야 합니다. 또한 동일한 소스코드를 기반으로 길고 짧은 프로젝트를 동시에 진행하면서 나중에서 손쉽게 Merge를 할 수 있어야 합니다. 이런 식으로 개발을 하지 않으면 대형 프로젝트는 너무 오래 걸릴 수 밖에 없습니다.

또한 이 때문에 각 개발자들이 Component Owner식으로 자신만 소스코드를 다룰 수 있다면 개발자들간에 소스코드 공유가 취약해지며 서로 단절된 개발을 하기 십상이 됩니다.

하지만 이런 Component Owner방식에 익숙한 환경에서는 이것이 너무 당연하게 생각이 되므로 이것을 바꾸려는 생각을 하기란 쉽지가 않습니다. 지금이 방식이 익숙하고 별 문제가 없어 보이고 또 이런 환경에서 발생한 문제들을 온갖 편법으로 피해 왔기 때문에 바꾸기가 쉽지 않습니다. 하지만 이로 인해 발생하는 문제들은 무시할 수 없습니다.

모짜르트와 두 제자

모짜르트가 두 명의 제자에게 피아노 레슨을 한적이 있답니다.

한 명은 이제 막 피아노를 시작한 완전 초자이고

또 한 명은 이미 연주를 능숙하게 할 줄 아는 사람이었다고 합니다.

모짜르트는 누구에게서 더 많은 레슨비를 받았을까요?

바로 두 번째 사람이었습니다.

첫 번째 사람은 완전 초자이므로 모짜르트가 시키는 대로 그대로 따라와줘서 진도도 잘 나가고 강습에 문제가 없는 반면 두 번째 사람은 자기스타일을 고집하기도 하고 오랫동안 몸에 익은 습관을 버리기가 어려워서 먼저 그 습관을 다 없애고 다시 배워야 하기 때문에 배우는 시간도 몇 배 더 오래 걸리고, 가르치기도 더 어려웠다고 합니다. 그래서 레슨비를 더 많이 받아야 했습니다.

소프트웨어 컨설팅을 할 때도 아무것도 없는 회사는 맨땅에게 건물을 짓는 것과 같아서 상당히 빨리 성과를 낼 수 있습니다. 하지만 어설프게 프로세스와 시스템을 이것 저것 많이 만들어 놓은 회사들은 비효율적인 것들을 모두 부수고 다시 만들어야 하기 때문에 시간이 더 오래 걸리고, 기존에 그렇게 만들어 놓은 사람들의 반대와 방해에 부딪혀서 어려움에 봉착하는 일이 많습니다.

잘못된 길로 들어 선 회사들은 빨리 다시 되돌아 와야 합니다. 

되돌아 오기에는 너무 먼 길로 간 경우도 종종 있습니다. 이런 경우는 어쩔 수 없습니다. 환자에게 너무 큰 칼을 대면 죽을 수도 있으니까요. 비효율적이지만 익숙한 방법으로 계속 해나가는 수밖에는 없습니다. 그러면서 서서히 조금씩 바꾸는 것이 사망하지 않고 바꿀 수 있는 방법입니다.

성급하게 이것 저것 마구 시도해서 나쁜 습관만 잔뜩 들지 말고, 차근차근 제대로 갖춰 나갑시다.

레퍼런스 있어요?

컨설팅을 하다보면 종종 듣는 질문이 레퍼런스 있냐는 말입니다.

또 이걸 시행하면 시행전보다 몇%의 생산성의 향상을 가져오는지 수치로 알려달라고 하는 사람들도 있습니다.

히딩크가 한국에서 와서 기초 체력훈련에 집중할 때 반대 했던 많은 사람들처럼 소프트웨어를 개발하기에는 너무나 기초가 취약한 수많은 기업에서 아주 기초적인 것들을 도입할 때도 종종 이런 말을 듣게 됩니다. 

레퍼런스는 Global 소프트웨어 회사 전부이고, 생산성 향상을 논할 수 없을 만큼 기초적인 것이다라고 말을 해야 하지만, 그렇게 얘기를 하면 기분이 나쁠 수 있으므로 애둘러서 말해야 합니다.

아직도 국내 소프트웨어 개발 환경 및 역량 수준이 Global 수준과 너무나 큰 차이가 나는 것이 현실입니다. 레퍼런스를 따질 때가 아니고 기초부터 다시 다져야 합니다.

정부에서는 Global 수준의 소프트웨어 개발 방법을 배우기 위해서 외국인들을 활용하려고 하는 정책들이 나오고 있는데, 또, 헛돈을 쓰는 시행착오로 끝날 것이 불 보듯 뻔합니다. 국내 현실을 전혀 모르는 외국인들이 과연 국내 소프트웨어 회사들을 어떻게 바꿀 수 있을지 그림이 안 나옵니다. 영어도 잘 안 통하는 한국에서 또 뜬구름 잡는 소리만 하고 비싼 세금으로 만든 비용을 받아 가겠죠. 

결과를 지켜봐야겠습니다.

누가 소스코드를 몰래 바꿔놨다.

누군가 몰래 여러분 회사의 소스코드를 바꿔놓는 일이 가능한가요? 진짜 이런 일이 일어 날 수 있는 환경이라면 당장 고쳐야 합니다.

실제로 이러한 걱정을 하는 회사도 많이 있습니다. 

영화 슈퍼맨3를 보면 한 프로그래머가 은행 이자의 우수리 돈을 자신의 계좌로 몰아서 스포츠카를 사는 장면이 나옵니다. 또, 퇴사하는 직원이 악의를 품고 소스코드를 몰래 바꿔놓지 않을까 걱정을 하기도 합니다.

정상적인 시스템과 프로세스를 갖춘 회사라면 이러한 걱정을 할 필요가 없으나 그렇지 못한 대부분의 소프트웨어 회사들에서는 언제든지 일어날 수 있는 일입니다.

정상적인 경우라면 소스코드의 모든 변경은 기록에 남게 됩니다. 또 소스코드를 변경하기 위해서는 버그ID(또는 이슈ID)가 있어야 합니다. 이것이 소스코드 변경 승인의 역할을 대신하기 때문에 소스코드를 변경 시 버그 ID가 없다면 소스코드 변경이 차단되도록 되어 있는 경우도 있습니다.

또, 버그ID도 가짜로 만들어서 등록을 했다고 하더라도, Peer review에서 이상한 코드는 발견이 되게 됩니다. Peer review를 통과 했다고 하더라도, Build팀에서 빌드를 하면서 바뀐 소스코드와 버그ID를 체크하는 과정에서 가짜 버그 ID가 발각 될 수 있습니다. 여기까지 통과를 하였다고 하더라도, 테스트에서 걸리게 되어 있습니다. 이것도 통과를 하였다고 하더라도, 모든 변경의 이력은 기록이 남아 있고, Log가 존재하므로 추후 추적이 가능해집니다.

제대로 시스템과 프로세스가 갖추어져 있다면 누가 소스코드를 마음대로 바꾸지 않을까 걱정할 필요가 없습니다. 이를 걱정하고 온갖 프로텍트 장치를 해 놓는 것은 오히려 개발 효율성을 떨어뜨리게 됩니다.

모든 것이 다 Open되어 있고 허술한 것 같아 보이지만, 이렇게 하는 것이 오히려 더 안전하고 투명하게 개발이 진행되며 생산성을 훨씬 더 높이는 방법입니다.

개발자는 코딩만 해야 한다.

제목을 보시고 무슨 말도 안되는 얘기를 하느냐고 생각하시는 분이 대부분일 겁니다.

이러한 생각의 Gap은 소프트웨어를 개발하는데 있어서 개발자의 역할에 대한 인식의 차이에서 비롯합니다.

현실을 보면 개발자라는 이름으로 정의된 소프트웨어 엔지니어들은 대단히 많은 일을 합니다. 

요구사항 분석도 하고, 설계도하고, 코딩도 하고, 테스트도 하고, 빌드도 하고, 팩키징도 하고, 고객지원도 하고, 전화도 받고, 영업도 지원하고, 서비스 회사인 경우에는 실제 운영서버 관리도하고, 장애 해결도 하고, 정말 여러가지 일을 합니다.

이것을 역할로 바꿔보면, Software Analyst, Software Architect, Coder, QA Engineer, Build Engineer, Release Engineer, Technical support engineer, Technical sales engineer, System administrator 등의 서로 다른 역할 들입니다.

이런 일들을 모두 다른 사람이 해야 한다고 하면 배부른 소리하고 있다고 할 겁니다. 물론 그것은 아니죠. 이중에서 개발자가 Coder의 역할만 하는 것은 아니고 몇 가지 역할을 겸해서 할 수는 있습니다. 심지어는 위의 모든 일을 한 명의 개발자가 수행할 수도 있습니다. 하지만 그렇다고 하더라도, 이 각각의 일들은 원래 다른 역할이라는 것을 알아야 합니다. 특히 코딩과 테스트는 한 사람이 동시에 잘 해내기 어려운 조합이기도 합니다. 따라서 여유가 되고 기회가 된다면 적절한 시점에 똑같은 만능개발자를 수평적으로 인원수만 늘릴 것이 아니고, 각각의 역할로 쪼개야 합니다.

그 중에서 개발자(코더)의 역할은 정해진 설계에 따라서 혹은 할당받은 버그에 대하여 소스코드를 수정하고 소스코드관리시스템에 등록하면 끝나는 겁니다. 나머지는 다른 사람들이 할 일이죠. 이것이 지켜지지 않으면 이중에서 비싼 인력인 개발자가 싼 인력이 수행할 수 있는 일들에 치여서 점점 효율성이 떨어지고, 자잘한 사고도 많이 일어납니다. 개발자는 개발이 전문이지, 테스트 전문가도 아니고, 빌드와 릴리즈 전문가는 더욱더 아니라서 코딩 이외의 일들은 잘 해내지도 못합니다. 따라서 조직이 커지고 있다면 적절한 시점에 역할이 분리되지 않으면 커다란 공장에서 수많은 개발자들이 체계적이지 않은 방법으로 인형에 눈깔 붙이듯이 서로 뒤죽박죽 뒤섞여서 일하게 될 수 있습니다. 

지금은 조직이 작아서 개발자가 여러가지 일을 다하더라도 "모드전환스위치"를 가지고 있어서 서로 다른 일을 할 때는 스위치를 잘 해야 합니다. 그리고 언제든지 일을 떼어줄 준비를 하고 있어야 합니다.

개발자 4명보다 개발자 3명과 테스터 1명이 더 효율적입니다.

개발자 30명보다 개발자 20명과 테스터 6명과 빌드/릴리즈 담당자 1명과 3명의 Technical Support 담당자가 있는 것이 더 효율적입니다.

물론 숫자는 절대적인 것이 아니지만, 회사는 계속 커가는데, 구멍가게나 가내수공업식으로 계속하고 싶지 않으면 역할에 분리에 대해서 고민해야 합니다.

살아남은 개발자들

소프트웨어 업계에서 주변을 둘러보면, 실력은 없으면서 탁월한 생존력으로 살아남은 개발자들을 볼 수 있습니다.

소프트웨어 개발 실력은 떨어지지만, 업무지식을 속속들이 알고 있는 개발자

회사의 개발정보를 꼭꼭 숨겨서 자신만 알고 있는 개발자

과거에 개발해 놓은 소스코드의 문서도 만들지 않고 뒤죽박죽으로 섞어놔서 자신이 아니면 유지보수를 못하게 만들어 놓은 개발자

탁월한 인화력으로 후배 개발자들과 똘똘 뭉쳐있는 개발자

미래에 경쟁이 될만한 새싹은 미리 밟아 버리는 개발자(관리자)

화려한 언변으로 경영자들에게 거짓된 신임을 얻고 있는 개발자

위와 같은 방법의 생존이 소프트웨어 업계에서 살아가는 한 방법이기도 하지만, 또 일부 기술은 부러운 기술이기도 하지만, 이는 결국 회사와 개발자 모두의 경쟁력을 갉아 먹고, 그 부메랑은 개발자에게 돌아옵니다. 이런 방식으로는 10년, 20년 꾸준히 소프트웨어 엔지니어로서 일을 하면서 성장하기는 어렵습니다. 개발자로서 오래 살아남고 싶다면, "생존력"보다는 "경쟁력"이 필요합니다.

"경쟁력"이 구체적으로 무엇인지는 제 블로그 전반에서 계속 주장하고 있으니 살펴보세요. ^^