우리나라에는 전지전능한 슈퍼 개발자가 있다.

여러 소프트웨어 회사를 컨설팅하다보면 아주 많은 개발자들을 만나게 됩니다. 

그 중에는 전지전능한 슈퍼 개발자를 만나게 됩니다.

코딩, 설계, 분석, 테스트, 기획, 고객 전화응대, 고객 지원, 프로젝트 관리, 일반 관리, 아키텍처 등등 엄청나게 많은 일을 하는 개발자들을 보게 됩니다.

이들은 대부분 팀장 쯤 됩니다.

어떻게 생각하시나요? 

바람직해 보입니까?

"나도 그런 전지전능한 개발자야 돼야지"라는 생각이 드십니까?

혹시 지금 이렇게 모든 분야의 일을 다 하고 계시나요?

이것은 One man company 얘기가 아닙니다. 

개발자가 100명이 넘는 회사도 이러한 경우를 여럿 봤습니다.

대부분은 회사가 성장과정에서 적당한 때에 조직을 변화시키지 못하고 그냥 달려온 경우입니다.

이런 경우 전지전능한 개발자가 대부분의 기술과 이슈를 꽤 뚫고 있어서 조직이 그럭저럭 굴러갑니다. (개발자들은 몰라도 사장님은 고민 많으실 겁니다.)

모든 길은 로마로 통하듯 모든 기술적인 이슈도 이 전지전능한 개발자를 통해야 해결됩니다.

이런 개발자가 나가면 회사는 망할 것만 같습니다.

이러한 상황이 정상일까요?

어떤 사람도 서로 완전히 다른 Skill set들을 필요로 하는 일들을 동시에 다 잘 수행해 낸다는 것은 불가능합니다. 아주 작은 회사라면 그렇게 해야지요. 다른 대안이 없으니까요.

이렇게 모든 일을 다하는 전지전능한 개발자는 그 모든 업무를 다 잘 못하고 있다고 봐야 합니다. 그건 애초에 불가능합니다.

이들은 예전에는 뛰어난 개발자였습니다. 하지만, 개발 이외의 일들을 하나씩 떠 맡으면서 각 분야의 일들의 전문성이 점점 떨어지게 됩니다. 그리고 각 일의 Switching cost가 만만치가 않습니다. 이일하다 저일하다하면 그냥 시간이 지나가버리지요. 톰 디마르코는 몰입에는 15분의 시간이 필요하다고 했습니다. 전화한번만 받아도 15분은 그냥 추가로 까먹는거죠.

심지어는 테스트, 고객 전화응대, 고객 지원까지 한다는 것은 100원의 돈을 받으면서 20원짜리 일을 하는 것과 같습니다. 그런 일은 싸게 고용할 수 있는 사람을 시켜야지요. 그리고 기획 같은 일은 전문성이 부족하여 제대로 수행하지도 못합니다. 

결국 이 개발자는 다른 소프트웨어 회사에 가면 별로 가치 없는 개발자가 되고 맙니다. 분야가 달라지면 Domain Knowledge에 의한 경쟁력을 잃고, 개발 실력도 경력에 걸맞지 않게 떨어지고 어느 것 하나 특출난게 없게 됩니다. 관리자로 가야 할까요? 그래서 회사에 꼭 붙어 있으려고 하고, 정치를 하면서 세력을 키우고, 회사의 개혁이나 변화를 반대하고, 골치덩어리 영웅이 되고 맙니다.

회사는 이들에 의존도가 커져서 리스크를 감당할 수 없는 수준에 이르게 됩니다.

이들이 등돌리면 회사는 휘청합니다. 

이것이 개발자 탓일까요? 아니면 회사 탓일까요? 

네, 회사 탓입니다. 회사는 개발자가 실력을 발휘할 수 있도록 여건을 조성해주고 훈련도 시켜줘야죠.

그런데 맨땅에 개발자가 북치고 장구치고 다 하다 보니까, 어쩌다보니 그렇게 된 것이지요.

그럼 어떻게 해야 할까요?

조직이 작을 때부터 나중에 커질 때를 대비해야 합니다.

조직이 커지면 언제든지 분리하기 쉬운 업무부터 띄어낼 수 있도록 말입니다.

이렇게 하려면 갖춰야 할 것이 3가지 있습니다.

이는 "프로세스"와 "기반시스템" 그리고 "문서"입니다.

이 3가지가 있어야 개발 조직이 전문적으로 움직일 수 있습니다.

단 제대로 갖춰야지요. (제대로의 의미는 너무 많이 설명해야 하니 앞으로 계속 올리는 글에서 설명하도록 하죠, 그리고 사실 문서는 프로세스에 포함된 것입니다.)

혼자 일을 하더라도 "스펙"을 작성하고 "설계문서"도 작성하고 "Test Case"도 만들어 놓습니다. 물론 남에게 일을 시키는 것보다는 간소화 할 수 있습니다.

인도에 외주를 줄만큼 자세히 작성하는 것은 낭비죠.

그리고 적절한 개발 프로세스를 만들어서 조직이 커질 때마다 그에 알맞게 계속 발전시켜나가야 합니다.

그리고 "소스코드관리시스템"과 "버그(이슈)관리시스템"은 무조건 제대로 갖추고 있어야 합니다.

이전 포스트 참조하세요(기반시스템(Infrastructure System)을 사용하고 계신가요?)

이 모든 것은 혼자 소프트웨어 회사를 한다고 해도 갖추고 있어야 합니다.

프로세스, 문서 얘기가 나오니까 오히려 개발이 늦어질 것 같은가요?

혼자 개발을 해도 이것들은 꼭 필요합니다. 개발이 더 빨라지고, 제품의 품질도 올라가죠.

왜?

지금 이해가 가지 않는 분이라면, 여기서 납득을 시켜드릴 수는 없습니다. 

제 책(소프트웨어개발의 모든 것)을 읽어보시거나 저를 찾아오시면 친절하게 설명드리겠습니다.

각설하고..

그렇게 준비가 되고 나면 회사 커지면 직무를 하나씩 전문화시켜야 합니다.

우선 "테스트팀"을 만드십시오. 회사가 작다면 이들이 Technical Support(고객지원)도 병행할 수 있을 겁니다. 

물론 테스트 직무도 전문화를 시키십시오. Random Test가 아닌 제대로 된 절차에 의한 테스트를 할 수 있도록 훈련시켜야 합니다. 그 방법은 제 책을 포함해서 시중에 좋은 책들이 얼마든지 있습니다.

그리고 개발자가 많아지면 관리자를 나누고, 기획, 프로젝트 관리자, 빌드/릴리즈 역할을 나눠 나갈 수 있을 겁니다. 

아직 "프로세스", "기반시스템", "문서", 이런 것들을 갖추고 있지 않은 회사라면은 조직을 어떻게 바꿔도 결국 그 전지전능개발자에게 커뮤니케이션이 다 몰리고 리스크는 여전할 것입니다.

이렇게 회사를 바꾸려면 개발자나 회사나 모두 "성장통"을 감내해야 합니다.

개발자는 현재 자신이 하는 일에만 가치가 있다고 생각하면 안됩니다. 좀더 큰일을 하기 위해서 과감하게 현재의 일을 버리고 자신이 가장 잘하는 일에 집중해서 더욱 가치를 높여야 합니다.

회사는 이 과정에서 임시적을 생산성이 떨어집니다. 이 기간이 짧게는 5,6개월에서 길게는 1년이 갈 수도 있습니다. 부작용을 최소화 하기 위해서 점진적인 변화를 할 수도 있고, 전문가를 영입하여 한번에 바꾸는 방법도 있습니다.

회사 안에 있으면 경영자나 개발자나 이러한 상황을 잘 느끼지 못하는 경우가 많습니다.

개구리를 냄비 안의 찬물에 넣고 서서히 데우면 뜨거워서 견지디 못하는 순간이 될 때까지 잘 느끼지 못하는 것과 같은 거죠.

그냥 익숙해지는 겁니다.

이런 경우 외부의 전문가가 회사를 분석하는 것이 효과적일 때가 많습니다.

궁금하신 내용이 있으면 언제든지 E-mail([email protected])으로 연락주세요. 궁금증을 시원하게 풀어드리지요. 

장문의 글을 읽어주셔서 감사합니다.

우리나라 소프트웨어 회사에는 Technical career path가 없다.

우리나라에서는 소프트웨어 개발자로 일을 하면서 부딪히는 큰 걸림돌이 있습니다.

"Technical career path가 없다"는 겁니다.

이 말에 바로 무슨 뜻인지 팍 와 닺지 않는 사람은 우리나라의 소프트웨어 환경에 이미 익숙해지신 겁니다.

소프트웨어 개발자들은 일을 열심해도 위로 올라갈 데가 없는 경우가 대부분입니다.

그래서 팀장도 되고, 관리자도 되고 다른 직종으로 점점 옮겨가게 됩니다.

그러다 보면 기술과는 점점 멀어지게 됩니다.

뛰어난 기술자들의 보석과 같은 실력을 썩히는 거지요.

대부분의 소프트웨어 회사에서는 Technical Track과 Management Track를 구분해야 한다는 사실을 인식하지 못하고 있습니다. 두 Track은 완전히 다른 것이고 서로 잘 호환 되지도 않습니다.

지금까지 수많은 회사의 소프트웨어 컨설팅을 하면서 Technical career path가 제대로 있는 회사를 거의 접하지못했습니다. Technical career path가 제대로 있다고 하면 CTO급, 이사급까지 차례대로 거쳐 올라갈 수 있는 단계가 정의가 되어 있어야 합니다.

우리나라의 경영자들은 개발자가 고참이 되면 팀장이 되고 여러 개발자를 거느리고 나중에 부서장이 되고 하는 것이 문제라는 생각을 하고 있는 경우는 많지 않습니다.

개발자는 개발을 잘하는 것이고, 관리자는 관리를 잘하는 것이지요.

그래서 개발자는 개발을 관리자는 관리를 해야지요.

그런데, 수평적인 미국의 조직구조에 비해서 수직적인 우리나라의 조직구조에서는 개발자들조차도 고참이 되어서 관리자가 되어서 개발자들을 거느리고 싶어 하기도 합니다. 그래서 힘도 생기고 여태 일한 보람이 있다고 생각하는 경우도 있습니다. 이것은 개발자의 탓이 아니고 "Technical Career Path"가 없기 때문입니다. 그래서 관리자가 되지 않고서는 파워를 가질 방법이 없게 됩니다.

이는 Technical Leading하고는 다릅니다. 점점 일반 관리자가 되어가는 거지요.

Technical career path가 보장된 회사에서 엔지니어들은 관리적인 파워가 아닌 기술적인 파워를 갖습니다. 회사의 기술적인 결정에 대한 파워를 가지고 신참엔지니에게서는 기술적인 존경을 받죠. 미국에서는 연봉도 관리자 path보다 더 높은 것이 일반적입니다.

미국의 소프트웨어 회사에서 채용을 할 때는  엔지니어와 매니저가 완전히 구분되어 있습니다. 엔지니어는 아무리 나이가 먹어도 엔지니어입니다. 엔지니어들은 HR(Human Resource)이슈는 신경쓰지 않습니다. 언제 그런 이슈를 신경쓰고 개발할 시간이 있겠습니다. 누가 아프고, 휴가가야 하고, 엔지니어 새로 채용해야 하고 그런 것들을 신경쓰고 기술에 집중하기는 어렵겠죠. 엔지니어들은 기술적인 이슈가 개발에 필요한 비즈니스 이슈만 신경씁니다. 사람 다루고 평가하고 하는 귀찮은 일들은 관리자 트랙에 있는 사람들이 해줍니다.

외국의 컨퍼런스에 가보셨지요? 저는 할아버지 엔지니어도 만나봤습니다. 정말 재미있지요. 그런 분도 최신 기술동향 다 알고 정말 엔지니어입니다. 

외국에서는 소프트웨어 회사에서 정말로 파워를 가지고 있는 사람들은 이러한 고참개발자들입니다. 이들을 Chief Engineer, Fellow Engineer, Chief Scientist라고 부르며 회사가 구조조정을 해도 관리자들을 잘라도 이러한 핵심 개발자들은 손을 못 댑니다. 다시 회사가 좋아지면 관리자는 다시 뽑으면 되지만, 이러한 개발자를 다시 키우려면 몇 년이 걸릴지 모르기 때문이지요.

소프트웨어 엔지니어의 실력이 한 10년 일하면 완전히 바닥나는 것도 아닙니다. 사실 10년 정도까지는 개발은 잘하는 개발자가 될 수 있죠. 그리고 10년 이상이 되면 시야도 넓어지고, 회사의 전략적인 결정이나 중요한 아키텍처를 결정할 수 있는 실력과 경험을 고루 갖추게 됩니다. 그런데, 그런 사람을 우리나라에서는 관리자로 만들어버리는 경우가 허다하지요. 

내 옛날 직장에서는 "백발이 휘날리도록 개발을 할 수 있는 개발자"를 뽑은 적이 있습니다. Technical career path를 평생 보장하겠다는 것이지요. 이 문구에 감동을 받아서 지원한 개발자도 꽤 많았습니다. 그만큼 많은 개발자들이 관리자로 가지 싫어 한다는 방증이기도 합니다.

이것이 개발자 혼자 몸부림 친다고 해결될 일이 아닙니다. 경영자가 Technical career path를 보장하는 것이 회사에 왜 이익인지를 깨닫고 회사에서 제도적으로 만드는 것 밖에 없습니다. 물론 직원이 4,5명 이하인 회사에서는 다들 멀티플레이어인기 때문에 이러한 제도가 의미가 없겠죠. 하지만 조직이 조금만 커지면 분명히 Technical career path를 명확히 해서 최고의 개발자를 키워내야 합니다.

(아래 분들은 Software Engineer들입니다.)

소프트웨어 아키텍처는 어디에서 오는 것일까?

오늘은 아키텍처와 비즈니스의 관계에 대해서 적어볼까 합니다.

아키텍처… 비즈니스… 둘간의 무슨 관계가 있을까요?

별 관계도 없어 보이고…

혹시 제품의 아키텍처를 구성하고 설계를 하시고 계시나요? 그렇다면 비즈니스에는 얼마나 관심을 가지고계십니까? 

기술은 기술, 비즈니스는 비즈니스, 별 관계없다고 생각하실 수도 있습니다. 

결론은 말씀 드리면 "소프트웨어 아키텍처는 비즈니스에서 나온다."입니다.

이 글을 쓰게 된 주된 이유는 많은 선임, 고참 개발자들이 기술에만 관심을 가지고 비즈니스에 별 관심이 없는 경우를 많이 봐왔기 때문입니다.

개발자는 상위 개발자가 될 수록 비즈니스를 알아야 합니다. 아키텍처에 대한 대부분의 결정은 단순히기술적인 결정이 아닙니다. 비즈니스를 제외하고 기술적인 결정만 있는 경우는 별로 없습니다.

지금 만드는 제품이 딱 한 회사만 사용할지 100개의 회사가 사용할지 100만개의 회사가 사용할지에 따라서제품의 아키텍처는 완전히 달라집니다.

또 내년에는 100개의 회사만 사용하지만 내 후년에는 10,000개의 고객을 가질 것이라면 또 달라집니다.

한국에서만 팔 것인지, 아시아권에만 팔 것인지, 미국, 유럽에도 진출할 것인지에 따라서 Localization이슈가완전히 달라지고, 1,2년은 한국에서만 팔지만, 추후 유럽에서도 판매할 의도가 있다면 미리 이를 고려하지않으면 안됩니다.

그리고 이러한 아키텍처 관련된 결정은 매우 중요해서 잘못된 결정이 엄청난 손실을 가져옵니다. 코드 좀 잘못 짜고, 버그 좀 만드는 것과는 차원이 다릅니다.

이러한 비즈니스적인 요소를 고려하지 않고, 그냥 기술적으로 기능이 동작하는 정도만 생각하고 소프트웨어를 개발하고 있다면 선임개발자로서의 자격이 부족하다고 할 수 있습니다.

따라서 선임개발자가 되면 비즈니스에 대해서 부지런히 관심을 가지고 공부를 해야 합니다. 회사 내부만 보지 말고 Global한 시장이 어떻게 돌아가는지도 관심을 가져야 합니다.

아키텍트(Software Architect)가 되는 첫 걸음은 기술이 아니고 비즈니스를 알아가는 것입니다.

객체지향... 필요한가?

써니님의 "절차지향도 훌륭한데, 왜 객체지향인가?"라는 글을 읽고 객체지향에 대한 견해를 적어봅니다.

먼저 글을 읽고 계신 분이 C언어로 프로그래밍을 하시나요? 그러면 질문이 있습니다. "static 함수를 사용하시나요? 또 static 함수의 용도를 아시나요?" "static 변수가 아닙니다." 사용하고 계시고 정확한 용도를 알고 계시면 C언어로도 객체지향 프로그래밍을 하고 계시는 것일 겁니다. 이 질문에 갸우뚱하시는 분이 계시나요? 그럼 이야기를 시작해보죠.

여기서 이슈를 다음 두 가지로 나눠야 할 것 같습니다.

• 객체지향 프로그래밍
• 객체지향 프로그래밍 언어사용

첫째, 객체지향 프로그래밍은 당연히 필요하다고 생각합니다. 

우선 몇 만 라인 이하의 소규모 소프트웨어를 개발할 때와 혼자서 소프트웨어를 개발할 때는 좀 논외로 하고 싶습니다. 이런 경우의 예를 들기 시작하면 사실 어떻게 해도 불편할 것도 없고 안되는 것도 없습니다.

적어도 수십만 라인의 이상의 코드를 다루고, 5,6명 또는 수십, 수백 명의 개발자들이 같이 일을 할 경우를 기준으로 생각해야 할 것 같습니다. 지금은 혼자 소규모의 소프트웨어를 개발하고 있어도 언젠가는 이런 규모의 소프트웨어를 개발하는데 참여하겠죠. 따라서 혼자서 개발을 하고 있어도 "나랑은 상관없는 얘기다"는 아닙니다.

프로그래밍에 객체지향 개념 도입된지는 매우 오래 되었습니다. 객체지향 프로그래밍 언어가 나오기 훨씬 이전부터 개발자들은 객체 지향적으로 개발을 하고 있었습니다. 그렇지 않고서는 너무 복잡해서 개발을 할 수가 없었거든요. 그 뒤로 이러한 요구를 만족시키기 위해서 객체지향 프로그래밍을 잘 할 수 있는 언어들이 나오기 시작한 거죠. 

객체지향의 기본 컨셉인 추상화, 캐슐화, 정보의 은닉 이런 것들은 오래 전부터 사용을 해왔죠.

그렇지 않고 절차적이고 구조적인 프로그래밍을 하게 되면 시스템의 규모가 커질 수록 그 복잡도가 너무 커져서 감당할 수가 없었죠.

그래서 개발을 할 때 시스템의 각 컴포넌트는 잘 나눠서 각 컴포넌트끼리는 간결한 인터페이스를 정의해서 해당 인터페이스만을 가지고 통신을 하도록 하고 각 개발자들은 자신이 담당함 컴포넌트만 개발할 수 있도록 했죠. 이러한 개념을 데이터와 메쏘드를 엮어서 객체지향 이론을 점점 발전시켜 왔습니다. 

C언어에서도 static 함수를 사용하면 해당 파일의 내부에서만 호출이 가능하고 외부 다른 파일에서는 호출할 수 없습니다. 즉 private 함수와 같은 효과를 발휘합니다. 따라서 public함수가 아닌 함수는 모두 static으로 정의를 해야 합니다. 그렇지 않으면 함수가 바뀌게 되었을 때 수천, 수만 개의 파일 중에서 누가 그 함수를 사용하고 있는지 정확하게 추적해서 문제없이 수정하는 것은 너무나 어려워 집니다. static함수는 해당 파일 내에서만 검토를 하면 되기 때문에 문제 없죠. 혹시 지금 C언어로 작성된 소스코드가 있으면 함수에 static이 정의 되어 있는지 확인해보세요.

둘째, 객체지향 프로그래밍 언어도 당연히 유용합니다.

C언어로도 객체지향 개념을 적용할 수 있지만, 한계가 있죠. 제대로 된 객체지향 프로그래밍을 하려면 객체지향 프로그래밍 언어가 필요합니다. 하지만 C언어로 개발을 하는 것에 대해서도 전혀 부정적인 의식은 없습니다.

주변에서 보면 언어만 C++을 사용하고 코드 내부를 뜯어보면 전혀 객체지향적이지 않는 소스코드를 많이 봅니다. 이런 경우보다는 C언어로 잘 작성하는 것이 더 낳죠.

물론 C++이 가장 훌륭한 객체지향언어라고 할 수는 없습니다. 그래서 객체지향 프로그래밍을 하기 위해서는 어떤 프로그래밍언어를 사용해야 한다고 주장하고 싶지는 않습니다.

한때 객체지향 개발방법론이 대두되어서 이전의 모든 문제를 다 해결해 줄 것처럼 떠들었지만, 이는 결국 언어를 무엇을 사용하고 방법론을 뭘 쓰느냐의 문제는 아니고 개발자들의 역량에 달린 문제 같습니다.

결론은 이렇습니다. 

"객체지향이 유용하기는 하나 무슨 언어를 쓰냐보다는 개발자의 객체지향 개발 역량이 더 중요하다."

객체 지향이라는 것이 꼭 알아야 하는 것이지만 툴에 목을 메지는 맙시다.

절차지향도 훌륭한데, 왜 객체지향인가?  by 써니 구조적 프로그래밍 혹은 절차지향적 프로그래밍이라고도 말하는 C언어를 학습하시거나, 현장에서 C언어를 이용해서 개발하시는 분들과 대화를 나누다 보면 굳이 객체와 클래스라는 생소하고 어색한(?) 개념을 도입해서 개발해야 하는지 그 필요성을 잘 느끼지 못한다고 하십니다. 저 또한 베이식 - 베이직 보다 베이식이 정확한 발음이더군요 - 그리고, C언어를 먼저 학습한 사람이기 때문에 어느 정도 공감하고 있습니다. 단순한 프로그램을 개발하건, 복잡한 프로그램을 개발하건 구조적 프로그래밍이건 객체지향 프로그래밍 기법을 사용하건 어떠한 문제를 풀던 간에 눈에 보이는 결과 자체로는 차이점을 발견할 수 없습니다. 그러니까, C언어로 윈도우 어플리케이션을 만들어도 잘 동작하고, C#으로 만들어도 잘 동작합니다. 여전히 대부분의 운영체제는 C언어로 개발되고 있고, 전세계에서 운영되고 있는 수많은 제품들과 정보시스템들이 여전히 C언어로 구현 및 유지보수 되고 있습니다. 여전히 수많은 금융기관에서는 코볼로 작성된 프로그램들을 사용하고 있고, 게다가 아주 성공적으로 운영되고 있습니다.