좋은 프로그래머가 되는 24가지 방법

1. 프로그래밍에 열정이 있어야 한다. 열정이 없고 즐기지 못하면 평생하기 어려운 일이다.
2. 프로그래밍 기초 원리를 완전히 이해해야 한다. 원리를 모르면 근본적인 해결을 할 수 없다.
3. 문제 해결 능력을 키워야 한다. 개발자의 가장 중요한 핵심 역량이다.
4. 창의적인 사람이 되라. 대부분의 좋은 해결책은 창의력에서 나온다.
5. 다른 사람의 코드를 이해할 수 있는 능력을 키워야 한다. 다른 사람의 코드에서 배운다.
6. 수학을 잘 해야 한다. 수학을 못하면 값싼 쉬운 개발 밖에 못한다.
7. 좋은 커뮤니케이션 스킬을 갖도록 노력해야 한다. 프로그래밍은 컴퓨터와 얘기하는 것이 아니고 사람들과 얘기하는 것이다. 
8. 협업 능력을 키워라. 다른 사람과 일을 나눠서 할 수 있어야 내 몸값이 비싸진다.
9. 논쟁(debate) 능력을 키워야 한다. 고급 개발자가 될 수록 토론하는 일이 늘어날 것이며, 좋은 토론이 좋은 소프트웨어를 만든다.
10. OOP를 완전히 이해해야 한다. 협업이 더욱 원활해질 것이다.
11. 남이 이해할 수 있는 문서를 작성할 수 있어야 한다. 문서 작성은 평생 따라다니는 중요한 업무이다.
12. 적어도 한가지의 개발언어는 완전히 마스터를 해야 한다. 마스터한 언어로는 어떠한 문제도 풀 수 있어야 한다.
13. 적어도 한가지의 스크립트 언어를 구사할 수 있어야 한다. 간단한 툴은 쉽게 만들어 쓸 수 있다.
14. 비즈니스를 이해해야 한다. 훌륭한 아키텍트가 될 것이다.
15. 주변에 나보다 훨씬 뛰어난 프로그래머를 둬라. 끊임 없이 배울 수 있다.
16. 끊임 없이 새로운 기술을 익혀라. 전쟁에서 쓸 무기가 많아질 것이다.
17. 습관적으로 주석을 달아야 한다. 주석은 남을 위해서 다는 것이 아니고 프로그래밍의 일부이다.
18. 남이 이해하기 쉬운 코드를 작성해야 한다. 나중에 내 발목을 잡지 않을 것이다.
19. 리뷰와 친해져야 한다. 평생 리뷰를 하며 사는 것이 프로그래머의 인생이다. 리뷰를 하지 않으면 발전하기 어렵다.
20. 건강을 유지해라. 건강을 잃으면 실력이고 뭐고 다 필요 없다.
21. 좋은 의자를 사라. 건강을 지켜주고 효율을 높여준다.
22. 인생을 즐길 줄 알아야 한다. 프로그래머로 오래 지속하고 싶으면 인생 자체를 즐기는 다양한 방법을 익혀야 한다.
23. 소프트웨어 공학을 익혀라. 주먹구구식 개발에서 벗어나게 해주고 개발을 즐겁게 해줄 것이다.
24. 높은 연봉을 받일 수 있도록 꾸준히 노력하라. 위 23가지 방법이 도움이 될 것이다.

요즘 실리콘밸리에서는...

얼마전 실리콘밸리의 한 Startup company에서 CTO로 일하고 있는 오랜 친구가 한국에 놀러와서 같이 여행을 갔다.

Informix에서 소프트웨어 엔지니어로 시작해서 한 20년 정도 일한 중국인 친구다. 같이 일을 한 적도 있지만 최근 동향에 대해서 여러가지 정보를 들을 수 있었다.

시간이 많이 흐르고 새로운 테크놀로지는 많이 나왔지만 소프트웨어를 개발하는 방식은 바뀌 것이 거의 없었다.

그 핵심을 요약해보면 다음과 같다.

• 소프트웨어를 개발할 때 가장 중요한 것은 스펙이다.
• 스펙을 작성하는데 가장 노력을 많이 들이고 고급엔지니어가 투입된다.
• 전체 개발 기간 중에서 스펙을 작성하는 분석 기간이 가장 길다.
• 스펙을 작성할 때 마케팅이 아주 중요하게 참여를 하고 모든 관련자와 스펙을 여러차례 철처하게 리뷰한다.
• 스펙이 완성되면 스펙에 모든 관련자가 사인을 한다.
• 스펙이 바뀌는 경우는 매우 드물다. 
• 예외적인 케이스에서만 스펙이 변경되고 스펙 변경시에는 프로세스를 따른다.
• 스펙을 바꾸면 개발자들이 어려워하고 프로젝트 기간이 늘어나기 때문에 다들 스펙을 바꾸면 안된다는 것을 잘 안다.
• Agile을 적용할 때도 스펙을 잘 작성한다. 대신 주기를 줄이고 빠르게 개발한다.
• 여러 사람이 개발을 나눠서 하기 위해서는 스펙을 잘 작성하고 컴포넌트를 잘 나눈다.

물론 한 개인의 의견이 실리콘밸린 전체 상황을 대변하는 것은 아니지만 다른 회사들도 크게 다르지 않을 것이다. 이러한 근본 원리는 10년전이나 크게 다르지 않다. Agile등의 새로운 기법들이 나와도 회사에 알맞게 적용을 할 뿐이고 근본은 바뀐 것이 하나도 없다.

한국 기업과도 일을 한 적이 있는데 대단한 불만을 토로하면서 다시는 한국 기업과는 일을 하지 않겠다고 한다.

한국 기업과 일을 할 때는 이러한 일들이 일어 났다고 한다.

• 요구사항을 문서로 달라고 하는데 주지 않고 몇마디로 설명만 해준다.
• 스펙을 작성해서 검토해 달라고 하는데 검토를 안해준다.
• 스펙을 완성해서 사인을 하라고 하는데 사인을 안한다.
• 스펙대로 다 만들었는데 UI를 보고 바꿔달라고 한다.
• 계약을 제대로 하지도 않는다.

대부분의 우리나라 소프트웨어 업체들의 부족한 부분도 10년 전이나 지금이나 크게 바뀌지 않았다. 분석 능력 등을 비롯한 기초역량이 부족한 것이다. 물론 기반과 경험이 부족한 상태에서 기초역량을 갖추는 것이 쉬운 일은 아니라는 것은 잘 알고 있다. 하지만 그 상태로 계속 발전해서 Global 경쟁에서 살아 남을 수 없다는 것도 알아야 한다.

우리를 현혹하는 신기한 기법보다 근본에 충실할 때다.

전문가 vs. 책임자

우리나라 조직문화는 전문가보다 책임자를 선호한다.

조직의 장이 책임을 지고 모든 일을 알아서 하는 것이다. 상명하복 관계 위주다.

경영자가 SW개발에 대해서는 잘 모르는 경우 누구 한명이 책임지고 개발해줬으면 하는 생각을 하기 쉽다. 

전문가를 우대하는 조직에서 조직의 장은 전문가들이 일을 잘 할 수 있도록 도와주는 관계이다. 전문가가 시간이 흐르고 승진을 한다고 해서 관리자가 되지 않는다. 

최고 경영층도 사장, 전무, 상무 등의 체제에서, CEO, CTO, CFO, CIO, COO 등의 전문가 체제가 일반화되었다. 일단 용어는 다 익숙한 것으로 보아서 많은 회사에서 전문가 시스템을 시도는 하고 있는 것이다. 물론 형식적으로 그렇게 이름만 따서 하는 경우가 허다하기는 하다.

공무원들도 외국에서는 한 분야에서 몇십년을 일해서 공무원들도 전문가가 되는데 우리나라는 고인물은 썩는다고 하여 비리를 줄이려고 공무원을 몇년마다 뺑뺑이를 돌린다. 몇년에 한번씩 지역과 보직을 바꾼다. 그래서 비리는 좀 줄었을지 모르지만 전문가를 양성하기는 어려운 상황이다.

Software 분야도 마찬가지이다.

개발을 잘하는 개발전문가들이 주도하여 일하는 것이 아니고 조직의 장이 책임을 지고 일하는 방식 위주이다. 여기서 전문성을 별로 존중되지 않는다.

그래서 개발자들은 개발을 적당히 하다가 관리자가 되기도 하고 다른 분야로 마음대로 왔다 갔다. 한다.

이러는 과정에서 가장 큰 손실을 입는 분야가 개발 분야이다. 그래서 우리나라에서는 Guru 급의 개발자들이 매우 부족하다. 모기업에서는 S급의 개발자에게는 사장보다 연봉을 많이 주겠다고는 하지만 찾기도 어렵다. 최고의 Software 전문가가 박사학위를 받은 개발자는 아니다.

Software 프로젝트도 여러 전문가들 이끌어간다. 마케터, 프로젝트매니저, 분석가, 아키텍트, UI전문가, QA전문가, Tech pub. 등등 다양하다. 

이들도 전문가로 성장하려면 분야에 따라서 5년, 10년, 20년 경험이 필요하다. 이들이 전문가로 꾸준히 성장할 수 있는 환경이 별로 없는 것이 문제다.  그렇게 진로를 보장해 주는 회사도 적을 뿐더러 관리자보다 연봉도 적고 조직내에서 영향력도 적기 때문이다. 

경쟁이 그렇게 치열하지 않는 동네 축구 리그에서 전문가가 별로 없어도 그럭저럭 살아남을 수 있다.

즉, 국내 시장에서는 그럭저럭 먹고 살 수 있다는 의미이다. 하지만 Global 시장에서 경쟁하려면 실력 차이가 너무 크게 나타난다.

개발자들이 개발에 매진할 수 있고 Software 전문가로 성장할 수 있는 환경이 꼭 필요하다. 닭이 먼저냐 달걀이 먼저냐 고민스러운 부분이다. 그래도 우선 개발자들이 꾸준히 개발자로 성장할 수 있는 제도와 사회적인 분위기를 만드는 것이 중요하다.

소프트웨어 회사의 자산은?

소프트웨어 회사의 자산은 무엇일까?

흔히 개발자가 소프트웨어 회사의 재산이라고 한다. 이런 회사일 수록 회사가 가지고 있는 것은 정말 개발자밖에 없다. 또한 파악하기 어려운 한 무더기의 소스코드가 있다. 개발자들이 나가면 이 소스코드들의 가치는 현저하게 떨어진다.

소프트웨어 회사의 진짜 자산은 문서다. 

정확하게 말하면 문서화 된 지식과 자료들이다. 문서화 되지 않는 정보들은 휘발성으로서 개발자들이 나가면 같이 사라지는 정보들이면 회사의 자산도 아니다.

이런 휘발성 정보와 개발자에 의존하는 회사는 수명이 얼마 남지 않았다.

문서화 된 지식과 자료는 문서 파일 형태로 저장되어 있을 수도 있고 시스템에 남아 있을 수 있다.
버그관리시스템,  Wiki, KMS 등에 남아 있는 정보들을 말한다. 

이런 정보들은 개발 시스템 및 개발 프로세스와 맞물려 원활하게 작성되고 리뷰가 되며 기록이 남는다. 기록된 자료는 사라지지도 않고 누구나 쉽게 접근 할 수 있고 결정적으로 관련된 사람들이 퇴사를 해도 그대로 남아서 가치를 발휘한다.
따라서 이렇게 남는 자료와 문서들은 본인이 퇴사를 해도 가치가 있을 정도로 적혀야 한다. 

반대로 생각해서 제대로 적지 않고 내가 퇴사를 하면 파악하기 어렵게 만들어 놓는다면 자신의 가치가 올라갈 것으로 생각하기도 한다. 하지만 그 효과는 퇴사 후에 나타나지 않고 당장 나타나기 시작한다. 당장 협업이 쉽지 않으면 스스로도 다 기억할 수 없을 뿐만 아니라 본인에 대한 평판도 나빠진다. 물론 회사 전체가 그런 분위기라도 서로 똑같다면 회사가 심각한 상태라서 말할 필요도 없다.

그럼 개발자가 회사의 자산이 아니면 무엇일까?

개발자는 회사의 미래이다. 

과거를 이렇게 잘 만들어 놓은 개발자들에게는 회사의 미래를 맡겨도 된다. 과거의 경험과 지식을 바탕으로 미래에 더 가치 있고 훌륭한 일들을 해낼 개발자들이다. 

그렇지 않고 과거에 망쳐 놓은 개발자들은 과거의 발목에 잡혀서 앞으로 나아가지는 못하고 옛날에 싸 놓은 ?을 치우느라고 세월을 다 보낸다. 가끔 이런 개발자들이 다른 개발자들에게 자신이 싸 놓은 ?을 치우지 않고 자신은 또 새로운 프로젝트를 하곤 하는데, 나아지는 것은 없이 이렇게 계속 저질러 놓으면 점점 치워야 할 ?이 많아질 뿐이고 한계를 넘어가면 회사는 더 이상 못 버티게 된다.

경영자들은 개발자가 문서도 없이 뭔가 뚝딱 만들어 내는 것을 신기하게 생각하지 말고 그런 행동이 얼마나 회사를 망치고 있고 회사의 자산을 축내고 있다는 것을 깨달아야 한다.

개발자가 회사의 자산을 자신의 머리 속에 보관하고 있다가 본인도 기억 못하게 하지 말고 밖으로 꺼내서 모두의 자산이 되도록 해야 한다. 

관리자가 이런 일까지?

우리나라 SW 조직에서 관리자란 위치는 참 애매한 위치다.

물론 전문 관리자라면 얘기가 다르지만 왕년에 SW를 조금 개발해 본 경우가 애매하다.

개발팀에서 가장 경험이 많은 SW 개발자들이 주로 팀장이 되곤 한다. 이 경우와는 약간 다른 얘기다. 이런 개발 팀장은 SW 개발자에 더 가깝고 관리업무는 부수적인 일이다. 물론 개발도 한다.

하지만 개발에서 손을 완전히 땐 관리자의 경우는 점점 개발과 멀어지게 된다. 이렇게 1~2년만 지나도 섣불리 기술에 대해서 얘기하기가 어려워 진다.

이 외에도 개발 경험은 거의 없는 관리자도 있다. 반대로 이런 관리자도 SW 조직 관리를 2~3년 하게 되면 풍월을 읊게 된다. 개발에 대한 왠만한 용어도 알게 되고 어떻게 돌아가는지 대충 파악이 된다. 그렇다고 기술을 아는 것이 아니다.
그런데, 과거에 개발자였던, 개발을 모르는 관리자던 이들이 개발에 있어서 기술적인 결정들을 좌지우지 하는 경우가 있다. 

조직의 상하를 떠나서 기술적인 결정의 책임은 개발자들에게 있는 것이지 관리자에게 있는 것이 아니다. 좀더 중요한 기술적인 결정은 일개 개발자를 떠나서 기술위원회나 CTO가 결정하는 것이다.

하지만 우리나라에서는 상하관계가 엄격하여 기술적인 결정도 관리자들이 영향을 미치는 경우가 많다.
이를 상하 관계가 아닌 역할의 구분으로 생각하는 것이 좋다.
개발과 관리의 전문적인 역할 구분으로 생각하자.

현재 이러한 판단을 하기 애매한 위치에 있다면 기술이든 관리든 하나를 정하는 것이 좋다. 둘다 잘하기는 거의 불가능하다. 개발팀장으로서 관리도 약간 해야 한다면 작은 조직에서는 그야말로 약간만 하는 것은 괜찮다. 이것도 큰 조직에서는 쉽지 않다.

기술은 기술자의 몫이다.

과거의 성공이 발목을 잡을 때

수많은 소프트웨어 회사들이 첫번째 성공을 거두고 나서 두번째 도약에 실패하고 사라져간다.

물론  첫번째 성공도 어렵지만 이미 성공의 경험이 있고 방법을 알고 있는 회사들이 두번째 또는 세번째에는 많이 실패하는 이유가 무엇일까?

두번째에는 첫번째와 환경이 많이 바뀐 것이 한 원인이다. 그래서 첫번째에는 주먹구구와 열정만으로도 성공을 할 수 있었지만 두번째에는 안통하는 것이다. 그럼 무엇이 그렇게 바뀌었을까?

수재 vs. 일반인

대부분의 첫번째 성공을 거둔 회사는 아주 똑똑한 소수의 수재급의 개발자들이 주도를 해서 성공을 이루었다. 하지만 회사가 커진 상황에서는 대부부분의 개발자들은 평범한 개발자들로 구성이 되어 있고 과거처럼 척척 알아서 일이 진행되지 않는다. 

선두 주자 vs. 치열한 경쟁
과거에 제품을 처음 만들 때는 시장의 선두 주자이거나 경쟁사가 별로 없었지만 이제는 경쟁도 치열해지고 가격도 과거처럼 넉넉하게 받기도 어려워졌다.

작은 제품 vs. 거대한 제품

최초의 제품은 꼭 필요한 기능만 아주 잘 만든 제품이었다. 하지만 수년이 흐른 지금은 기능도 몇 배가 늘었고 Architecture도 엄청나게 복잡해졌다.  뭐 하나 기능을 추가하려고 해도 과거보다 몇 배 오래 걸린다.완전히 새로 만들어야 한다는 요구가 빗발치지만 워낙 기능도 많고 다 파악이 안되서 다시 만들기도 어렵다.

작은 조직 vs. 커버린 조직

옛날에는 몇 명 안되는 회사에서 서로의 생각도 다 알 정도였는데 이제는 직원들이 하도 많아서 이름도 다 모른다. 누가 무슨 일을 하고 있는지 파악도 안된다.

체력 vs. 노쇄

몇 년 전만 해도 야근을 연속으로 해도 체력이 끄떡 없었는데 이제는 나이가 먹어서 야근을 하면 체력적으로 못 버틴다.

집중 vs. 분산

과거에는 회사에 개발 이외에는 이슈가 없어서 90% 개발만 했다. 하지만 이제는 유지보수 이슈도 많고 사이트 지원도 많아서 개발에 집중하기가 어렵다. 게다가 팀장까지 맡아서 조직관리를 해야 해서 개발에는 시간을 내기가 정말 어려워 졌다.

소수의 고객 vs. 많아진 고객

처음부터 고객별로 지원을 철저히 하다보니 고객이 몇 안될 때는 고객 만족도도 높고 개발 할만 했다. 하지만 고객수가 열배 이상 늘다보니 개발자가 아무리 늘어나도 고객 지원하는데 너무 많은 시간을 빼앗겨서 정작 제품 개발은 더 힘들어졌다.

열정 vs. 정치

과거에는 모든 개발자들이 열정 하나로 정말 열심히 했다. 그런데 지금은 실력도 없는 자들이 순전히 정치력으로 윗자리를 차지하고 앉아있다. 이럴 줄 알았으면 나도 개발보다 정치에 신경 쓸 것을 하며 후회한다.

결론

위에서 언급한 여러 원인으로 두번째 도약이 어렵거나 쇄퇴의 길을 걷고 있는 회사들은 빨리 첫번째 성공했던 기억은 버려야 한다. 더이상 통하지 않는 방법이다.

제대로 했다면 첫번째나 두번째는 성공의 원리는 같다. 하지만 첫번째에는 여러가지 조건으로 인해서 주먹구구 방식이라 하더라도 성공할 수 있었던 것이다.

하지만, 평범한 사람들을 데리고 엄청 많아진 고객과 커져 버린 제품을 제대로 개발하려면 다시 원칙으로 돌아와야 한다. 두번째 성공의 길은 원칙을 잘 지켜서 개발을 하는데 있다. 더이상 주먹구구는 통하지 않는 때가 된 것이다.

스펙을 제대로 작성하는 것은 구식이다?

'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다.

스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것을 판에 박힌 절차라고 생각하고 부정하기도 한다. 그런 주장을 하는 사람들은 이 방법은 Waterfall 방식으로 구닥다리이며 요즘은 Agile 등의 최신 방법으로 개발을 하기 때문에 과거처럼 스펙을 작성하지 않는다고 한다.

이렇게 주장하는 사람들에게 반문해보고 싶은 것이 있다.

"스펙을 한번이라도 제대로 작성해 본적이 있는가?" 

이런 생각을 하는 것 자체가 스펙을 제대로 이해하고 있지 못하다는 반증이다.

왜냐하면 스펙이 무엇인지 제대로 이해하고 있다면 이런 말이 나올 수가 없다.

지금 그렇게 부정하는 스펙을 작성하지 않아서 개발을 잘하고 있는가? 

99% 이상의 개발자는 죽을 때까지 제대로 된 Waterfall 방식의 개발을 한번도 해볼 기회가 없다. 그러면서도 과거에 Waterfall 방식으로 개발을 했다고 착각을 하는 것이다. Waterfall 방식을 참고하여 약간 응용을 한 것 뿐이다.

Waterfall 방식이 다른 모든 SW 개발 Lifecycle의 모델이 되는 이유는 소프트웨어는 나중에 고치기가 정말로 어렵기 때문이다. 빌딩 올리는 것과 별 차이가 없다. 즉, 코딩을 다 해놓은 다음에 설계나 스펙을 바꾸는 것은 10배, 100배 비용이 많이 드는 것이다. 아무리 최신 기술을 적용해도 이는 별로 나아지지 않는다.

따라서 그중에서 가장 앞단에 있는 스펙이 가장 중요한 것이다.

스펙을 작성하는데 있어서 가장 중요한 것은 필요한 만큼 적절하게 적는 것이다. 단계 별로 작성할 수도 있고, Unit test로 작성할 수도 있고 방법의 선택은 자유이다. 가장 효과적인 방법을 선택하면 그만인 것이다.

문제는 적는 방법이 아니고 그 내용이다. 대부분 스펙을 작성하지 못하고 어려워하고 반대하는 사람들의 공통점은 스펙에 무엇을 적는지 모른다는 것이다. 그렇기 때문에 아무리 잘 적으려고 해도 잘 안되는 것이다. 정리를 잘하고 예쁘게 적는 것은 추후 문제이다.

실제로 필자는 여러 회사의 다양한 프로젝트의 스펙(SRS)를 대신 적어준 경험이 있다. 해당 분야의 Domain 지식이 부족한 나는 해당 분야의 전문가들을 인터뷰하고 의논해가면서 스펙을 적는다. 대부분은 Domain 지식에 대해서는 훤하지만 스펙에 어떻게 적어야 하는지 모르고 있다. 즉, 지식은 있지만 스펙은 모르는 것이다. 스펙을 적는 방법에 대해서 구체적으로 적는 방법을 얘기하면 책 몇권도 모자르기 때문에 여기서 다 적을 수는 없다.

한마디로 요약하면 적어 놓은 스펙을 보고 설계/구현이 가능해야 하는 것이다.

조금만 더 설명하면 시스템을 기능, UI, Architecture의 뷰로 설명하고 비즈니스 요구사항, 비기능 요구사항 등을 포함해야 한다. 

스펙을 제대로 작성하는다는 것은 수십/수백페이지에 달하는 Template를 채우는 작업이 아니다. 어떤 SW를 만드는 것인지 정의 하는 것이다. 방법은 여러가지고 있고 그중에서 가장 효과적인 것을 선택하는 것이다. 

이것을 부정한다면 무엇을 만들지도 모르는 상태에서 무조건 코딩부터 시작하는 것이 가장 좋은 방법이라고 주장하는 것과 다를 바가 없다.