SW업계의 잘못된 통념 5가지

소프트웨어 업계에는 정말 깨기 어려운 잘못된 통념이 몇가지 있다.

많은 이들이 이러한 잘못된 고정관념과 오해에 사로 잡혀서 쉽게 변화하지 못하고 계속 잘못된 길을 걸어가고 있다.

어떠한 잘못된 통념이 있는지 알아보자.

잘못된 통념 1 : 문서(스펙)를 작성하느라고 일정을 못 맞추는 것이 아닌가? (경영자)

많은 경영자들은 문서 작성 때문에 프로젝트가 더 오래 걸리는 것으로 생각하고 있다. 그래서 개발자들이 문서를 쓰고 개발하겠다고 하면 오히려 문서를 쓰지 말고 빨리 개발해 달라고 은근히 요구하는 경영자가 의외로 많다. 

이러한 경우 경험에 의해서 문서란 개발과는 상관없이 추가적으로 시간을 잡아먹는 작업이라는 것을 학습했기 때문이다.

스펙을 써보지도 않고 일정이 모자르다는 것을 아는 것이 모순이다. 스펙이 부정확한 상황에서는 일정을 산정하는 것이 의미가 없기 때문이다. 하지만 대충 짐작으로도 턱없이 기간이 모자른 프로젝트도 있다.

진짜 스펙을 쓸 시간조차 없는 프로젝트라면 애초에 시작을 하지 않는 것이 좋다.

개발문서는 일정을 단축하기 위해서 작성하는 것이고, 그렇지 않은 목적을 가지고 있는 문서는 작성하지 않는 것이 좋다. 예외적으로 생명을 다루거나 우주선을 띄울 목적이라면 개발시간 단축외에 더 많은 것을 요구하기 때문에 시간이 더 오래 걸리는 문서도 작성하곤 한다.

하지만 대부분의 프로젝트에서는 개발 일정을 단축하는 문서만 작성해야 한다.

잘못된 통념 2 : 일정이 부족하니 당장 코딩부터 시작하자. (개발자)

진짜 개발자들 사이에서 만연해 있는 생각이다. 

개발자들은 위에서 촉박한 일정을 정해주기 때문에 무조건 일정을 맞춰야 하고 그러기 빨리 코딩을 시작해야 한다고 한다.

제대로된 스펙과 설계없이 코딩부터 시작한 프로젝트는 백이면 백 중간에 엄청난 재작업이 기다리고 있다. 통합에 막대한 시간이 소요되고 많은 버그를 생산하면 이를 고치는데 더 많은 시간이 소요된다.

코딩은 늦게 시작할수록 프로젝트가 빨리 끝나는 것이 맞다. 스펙과 설계가 충분할 수록 코딩 기간은 단축되고 일정이 부족하면 더 많은 개발자를 투입할 수도 있고 일부 기능을 미루는 것도 가능해진다.

잘못된 통념 3 : 지금은 잘 모르니 일단 개발해주면 보고나서 요구사항을 알려주겠다. (고객)

고객은 일단 개발해서 보여주면 아이디어가 마구 떠오르고 말만 하면 개발자가 바로바로 쉽게 고칠 수 있는 것으로 착각한다.

아키텍처에 영향을 주지 않는 사소한 것은 그럭저럭 바꿀 수 있어도 대부분의 기능은 고치거나 새로 추가하려면 처음부터 계획한 경우보다 몇배에서 몇십배의 비용과 시간이 들어간다.

하지만 고객이 스스로 원하는 것이 뭔지 잘 모르는 경우 개발자들은 상당한 어려움에 처하게 된다. 개발자들도 워낙 일상적으로 벌어지는 일이기에 불충분한 고객의 요구에도 자신이 아는 한도에서 대충 개발해주고 고치기를 반복하는 일을 정상적으로 받아들이곤 한다.

이렇게 개발이 이루어지만 아키텍처가 엉망이 되기가 일쑤이고, 개발자들은 재미 있는 개발을 하는 것이 아니라 회의만 들게 된다.

잘못된 통념 4 : 일정이 정해져 있어서 어쩔 수 없다. (개발자)

개발자들은 경영자들이 무리한 일정을 일방적으로 강요한다고 한다. 물론 그런 경우도 있지만 많은 경우 위에서 일방적으로 일정을 지시하지 않는다. 

표면적으로 드러난 결과가 일정 지시지만 그 과정을 살펴보면 합리적인 일정 산정과 조정이 이루어 지지 않는 경향이 있다.

개발자들이 제대로 스펙을 적어서 합리적인 일정을 제시하지 못하니 경영자도 일방적으로 도전적인 일정을 밀어 붙이고, 거꾸로 경영자가 그러하니 개발자들은 어쩔 수 없이 따르게 된다.

이는 어느 한쪽의 책임은 아니라고 볼 수 있다.

합리적으로 일정 산정을 하고 정확한 데이터를 제시할 때 경영자에게 일정에 대해서 어필할 수 있게 된다.

잘못된 통념 5 : 우리 회사는 달라서 일반적인 원칙이 적용되지 않는다. (경영자)

고객이 요구사항을 너무 자주 바꾼다. 

고객이 요청하면 당장 들어 줘야 한다. 

개발일정은 상상할 수 없을만큼 짧다.

고객이 요청하면 무조건 달려가야 한다. 

그래서 일방적인 소프트웨어 공학이 적용되지 않는다고 한다. 이것도 명백한 오해이다. 고객은 원래 그렇기 때문에 이러한 환경에서 빠른 시간에 적은 비용으로 개발하기 위해서 소프트웨어 공학이 존재하는 것이다.

우리만 그렇다고 생각하는 것도 오해이다. 많은 회사들이 정도는 다르지만 이러한 상황에 놓여 있고 많은 부분은 영업 전략으로 선택을 한 것 뿐이다.

이러한 잘못된 통념은 회사가 한단계 앞으로 나아가기 위한 변화를 방해하고 점점 열악하게 만드는데 일조한다.

개발자 100명을 더 투입한다면?

소프트웨어 회사에서 프로젝트를 진행할 때 흔히 벌어지는 문제가 "개발자가 부족해서 프로젝트가 늦어진다"는 것이다.

그럼 거꾸로 애플에서 날고 기는 개발자 100명을 투입시켜 줄테니 프로젝트를 제대로 끝낼 수 있냐고 물어보면 대부분 대답은 "글쎄요"다.

벽돌을 쌓거나 땅을 팔때는 사람을 2배 투입하면 대부분 시간이 반으로 줄어든다.

그런데 소프트웨어를 개발하는 프로젝트에서는 왜 그렇게 잘 안될까?

그 이유는 "스펙과 설계"에 있다.
빌딩을 세울 때는 설계가 명확하게 있다. 이 세상에 설계 없이 만드는 빌딩은 없을 것이다. 그리고 협업이 가능하도록 일이 세분화 되어 있고 전문화 되어 있다.

그런데 유독 소프트웨어(특히 우리나라)에서는 스펙과 설계가 땅파고 벽돌 쌓는 것보다 시원찮다. 그런 상태에서 개발을 하다보니 건설현장에서 빌딩 올라가듯이 개발이 되는 것이 아니고 뒤죽박죽이 된다. 이런 환경에 익숙해진 개발자는 뭐가 문제인지 인지하지 못하는 경우가 대부분이다.

스펙과 설계가 제대로 작성되어야 협업이 가능하다. 

여기서 핵심은 컴포넌트다. 컴포넌트가 일을 깔끔하게 나눠서 일할 수 있을 만큼 깨끗하게 나눠져 있어야 한다. 그래서 부서별, 개발자별로 일을 나눠서 할 수 있고 서로 인터페이스 맞추느라고 시간을 허비하지 않는다. 


스펙과 설계가 제대로 되지 않은 상태에서 개발을 하면 컴포넌트 단위로 일을 나눠서 할 수 없기 때문에 "화면"단위로 일을 나눠서 하기도 하고, 적당히 일을 나눠서 하다가 서로 겹치기도 하고 나중에 통합에 엄청난 시간이 걸리게 된다. 또한 어떻게 소프트웨어가 동작은 한다고 하더라도 그 아키텍처는 뒤죽박죽이 되어서 나중에 유지보수도 엄청나게 어렵게 된다.

그럼 스펙/설계 단계에서 어느 정도까지 설계가 이루어져야 할까?

대답은 의외로 간단하다.  스펙/설계의 결과를 가지고 소프트웨어 개발자들이 충분히 구현을 할 수 있을 정도면 된다. 여기서 "충분히"라는 단어는 몹시 애매하다.

문서만 보고 서로 전혀 대화를 하지 않고도 구현을 할 수 있으면 너무 자세히 적은 것이다. 이렇게 자세히 적으면 시간 낭비이고, 개발자에게 너무 자유도를 없앤 것이다. 

그럼 "충분히"는 어느 정도 일까?  개발자가 설계대로 구현을 하면서 약 5% 정도의 내용은 설계자나 관련된 컴포넌트 개발자와 서로 의논하면서 개발할 수 있을 정도면 적당하다고 할 수 있다. 너무 많은 내용을 의논하면서 구현시 결정해야 한다면 적은 내용이 너무 부족한 것이다. 따라서 "충분히"는 상황에 따라 다른 것이다.

설계가 부족하다면 프로젝트리더(테크니컬리더)는 여러 개발자에게 설명하느라고 시간을 보내고 자신이 담당한 개발을 할 시간이 부족해지고, 개발자들에게 설명을 소홀히 하면 개발자들이 제 멋대로 개발을 해와서 문제가 생기곤 한다. 나중에 이를 고치느라고 시간이 몇배로 낭비된다.

설계는 스펙을 작성할 때부터 시작이 되고 설계 단계에서는 컴포넌트가 다 구분되고 인터페이스가 정의가 되어서 소스코드 상에 모두 적히고 컴파일이 가능하도록 해야 한다.

그러기 위해서는 파일이름, Class이름, Public 함수 이름과 parameter, return값이 모두 정해져야 한다. 그리고 그 설명을 문서에 다는 것은 중복이기 때문에 Doxygen이나 Javadoc을 이용해서 소스코드에 주석으로 설명을 하면 효율적으로 설계 정보를 관리할 수 있다.

이렇게 설계가 완료되면 바로 Daily Build가 가능하며 구현 첫날부터 개발자들은 빌드가 가능한 소스코드에 자신이 맡은 컴포넌트의 내용을 채워나가면 되는 것이다. 즉, 첫날부터 이미 통합이 된 상태에서 개발을 하는 것이다.

이렇게 스펙과 설계를 작성하면 일정 산정의 정확도도 훨씬 올라가고 개발자를 더 투입하더라도 도움이 된다. 또한 외주로 개발하는 것도 가능하다.

물론 외주를 줄 경우에는 "설계"도 외주를 주는 경우가 많으므로 이런 경우는 "스펙"까지를 제대로 작성하면 된다.

이렇게 일을 효과적으로 나눠서 할 수 없다면 스펙/설계를 제대로 작성한 것이 아니다. 개발 시간과 비용도 줄일 수 있다. 가장 중요한 것은 프로젝트가 관리 가능한 상태가 된다는 것이다. 일정과 비용이 상당히 정확하게 예측 가능해지고 일정이 지연 상태를 빠르게 파악할 수 있고 대처를 할 수 있다.  스펙과 설계를 제대로 작성할 수 없다면 온갖 프로젝트 관리 기법은 다 소용없다. 결국 야근 밖에 남지 않는다.

"일을 나눠서 할 수 있다."는 것은 결국 개발자가 행복하게 일할 수 있도록 해준다.

SW개발자의 미래

개발이 좋아서 SW개발자가 된 사람들이 한 5~7년 개발을 하다보면 흔히 미래에 대해서 생각하게 되고 불확실한 미래를 불안해하곤 한다.

특히 대부분의 회사에서 개발자의 Career를 보장해주지 않기 때문에 막연히 팀장이 되기도 하고 다른 직종으로 옮기기도 한다.

그러다보니 전문성있고 가치가 높은 개발자의 경험과 지식이 묻혀버리기 일쑤이고 회사는 기술력이 축적되지 못하게 된다.

개발자의 Career Path 상에는 어떠한 직종들이 있는지 알아보자. 자신의 역량과 성향에 따라서 Path를 정하면 좋을 것이다. 물론 회사에서 그리고 사회 전체적으로 개발자의 Career Path를 보장해 주는 방향으로 변하면 좋겠다.

Senior Engineer, Chief Scientist

한마디로 고참개발자이다. 신참때는 주로 코딩을 많이 하고 버그를 잡았으면 이제는 분석, 설계에 더 많은 시간을 소비하고 Peer Review에 많이 참석한다. 

자신의 팀의 프로젝트만 관심을 가지는 것이 아니고 다른 팀의 프로젝트 리뷰에도 참석하여 기여를 한다.

흔히 Architect라고 불리기도 하고 여전히 코딩도 한다. 

외국에서는 60세가 넘는 Software엔지니어를 볼 수 있기도 하다. 

제대로 된 엔지니어라면 Domain과 상관없이 어느 분야로든지 이직이 가능하다.

CTO

회사의 최고 기술 책임자이며 많은 개발자들의 Role model이다.

회사의 경영에 관여를 하지만 관리는 하지 않는다.

장기기술전략, 실행전략, 아키텍처, 구현, 인프라구조 정립, 프로세스 등 개발에 관하여 기술적인 것이라면 모두 책임진다.

왕년에 코딩을 했다는 것으로는 CTO가 될 수 없다. CTO라면 현재도 코딩을 할 수 있어야 한다. 바쁘고 코딩의 Value가 낮기 때문에 안하는 것 뿐이지 분석/설계/코딩을 현재도 모두 할 수 있어야 한다.

소프트웨어 회사의 최고봉이라고 할 수 있다.

SCM, Build and Release Engineer

소프트웨어 회사에는 몇가지 전문적인 분야가 있다. 형상관리, 빌드, 릴리즈, 팩키징 등이 그것이다. 처음에는 개발자들이 개발과 더불어 이런 업무도 같이 수행하지만 회사가 커지면 전문적인 업무로 떨어져 나온다. 몇명이 전담을 해도 될만큼 충분히 일이 많고 취미로 해도 될만큼 일이 쉬운 것이 안다. 또한 개발 능력도 필요하다.

대단히 전문적인 업무이고 이러한 개발외의 환경이 잘 되어 있어야 개발자들이 개발에 집중할 수 있고 업무 효율이 오르게 된다.

개발자 중에는 프로젝트보다 이러한 전문적이고 SW공학적인 업무에 관심을 가지는 사람들이 있다. 이 영역에서 실력을 닦으면 이직시에도 이 전문성을 활용할 수가 있다.

Technical Marketer

제품을 기획할때는 비즈니스적인 요소, 기술적인 요소가 모두 고려된다. 그중에서 기술적인 부분은 일반 기획자들이 속속들이 알기가 어렵다. 따라서 기술을 아주 잘아는 테크니컬 마케터가 기술적인 부분을 담당하게 된다. 경쟁사의 제품을 분석할 때도 단순히 기능이 되는지 O, X만 체크 하는 것이 아니고 기술적인 부분까지 검토를 해서 적용된 기술도 파악할 수 있다. 

새로 기획하는 제품의 기술적인 비전을 수립하고 마케팅과 개발자의 연결고리 역할도 수행한다.

Technical Supporter

개발자 중에는 진득히 않아서 개발하는 것을 좀 쑤셔하고 싫어하는 사람들이 있다. 여러 경쟁 제품을 써보기를 좋아하고 새로운 제품이 나오면 먼저 써보려고 하고 동료들의 시스템에 문제가 생기면 누구보다 빠르게 해결해 주는 능력을 가지고 있다.

이런 경우 개발 경력과 지식을 활용하여 기술지원업무를 수행할 수 있다. 회사의 제품에 대해서 기술적으로는 누구보다 속속들이 잘 알기 때문에 수준 높은 지원도 가능하다.

외향적인 사람들에게 어울리는 직종이다.

QA Engineer/Manager

개발자 출신으로 QA 엔지니어나 관리자가 될 수 있고 개발 능력을 활용하여 테스트 관련 툴을 개발할 수 있다. 

개발 경험이 있는 것은 장점으로 작용하면 계획적인 삶을 살 수 있는 장점도 있다. 물론 우리나라에서는 똑같이 무지막지한 야근을 해야 하는 경우가 많다.

Project Manager

기술자 트랙과 관리자 트랙의 중간쯤 되는 포지션이다. 프로젝트를 책임지고 맡아서 관리하는 역할로서 General Manager가 되는 중간 과정이 될 수도 있다. 

General Manager

기술과는 관련이 없는 일반 관리자다. 기술에서는 손을 떼는 것이다. 우리나라의 개발팀장과는 또 다르다. 개발팀장이 오래되서 더이상 개발을 하지 않고 관리를 하면 General Manager라고 볼 수 있다.

기술적인 결정은 하지 않는다. 하지만 과거에 개발 좀 해 봤다고 기술적인 결정을 자기가 해버리면 월권이라고 할 수 있다.

일단 일반 관리자로 넘어오면 다시 엔지니어로 돌아가는 것은 불가능 하다. VP Engineering으로 성장하는 Track이다.

VP Engineering

우리말로는 "기술부사장", "연구소장" 정도가 되겠다. CTO와는 완전히 다르다. CTO는 관리를 하지 않지만 VP Engineering은 관리자다. 개발관리 총책임자 쯤 된다. 개발자나 CTO가 하는 기술적인 얘기의 용어들을 거의 알고 있고 개발프로세스가 어떻게 돌아가는지도 잘 안다.

하지만 기술적인 결정을 하지는 않고 관리만 한다.

우리나라에서는 흔히 VP Engineering을 CTO라고 불러서 오해를 하는 경우가 많다.

Domain Expert

소프트웨어 개발 역량보다는 업무 지식에 치중하는 사람들이다. 증권사, 은행, 회계, 토목, 건설, 기계, 예술 분야의 소프트웨어를 개발하려면 해당 영역의 지식과 경험이 많이 필요하고 소프트웨어 기술도 어느 정도 알아야 한다. 개발 경험을 가지고 해당 산업 지식을 쌓으면 도메인 전문가가 될 수 있고, 이 경우 해당 분야로만 이직이 가능하다.

Restaurant Owner

소프트웨어 개발에 염증을 느끼거나 비전을 찾지 못하면 소프트웨어 업계를 완전히 떠나는 것도 한 방법이다. 

문서를 작성하면 더 오래 걸린다는 고정관념

최근에 국내 유수 대학의 컴퓨터 공학 교수를 만난 적이 있다. 그 교수님도 문서를 작성하면서 Software를 개발하면 더 오래 걸린다고 굳게 믿고 있었다. 

어느 정도 이해가 되는 상황이다. 원래 소프트웨어 공학은 실전에서 발전해 온 것이기 때문에 교수가 실전적으로 잘 아는 분야는 아니다. 교수는 이론적으로는 잘 알고 있지만 실전은 상대적으로 약하기 때문이다. 특히 우리나라에서 쌓은 실전은 더욱 약할 수 있다. 또한 국내 개발자들을 데리고 일한다는 가정을 하고 얘기를 하는 것이라면 더욱도 그렇다.

물론 문서를 작성하면서 개발을 해야 한다고 생각한다. 그래야 제대로 개발을 할 수 있다.

하지만 문서를 작성하면서 개발을 하면 개발 기간이 거의 2배로 들어간다고 한다.

우리는 시간이 촉박하므로 문서를 작성하지 않고 개발해야 한다고 한다.

이 생각은 국내 회사의 대부분의 개발자와 경영자가 생각하고 있는 바와 크게 다르지 않다.

일부분은 맞는 측면이 있다.

문서를 어떻게 작성해야 하는지 잘 모르는 개발자를 데리고 개발을 하면서 문서까지 잘 작성해달라고 하면 시간이 훨씬 더 걸리는 것이 당연하다.

그럼 소프트웨어를 개발하면서 문서를 작성하는 이유는 무엇일까?

바로 소프트웨어를 더 빨리 개발하기 위한 것이다. 

이말을 진정으로 이해하고 있는 개발자를 만나는 것은 쉬운 일이 안다. 

그런데 왜 이렇게 다들 다르게 생각하고 있는 것일까? 

첫째, 앞에서 언급했다시피 역량 문제가 있다. 역량이 떨어지면 문서를 잘 적지도 못하고, 문서에 무슨 내용을 적어야 하는지도 모른다.

둘째, 국내 교수, 경영자, 개발자 모두 문서를 작성한다고 하면 세계적인 유명한 방법론을 기준으로 생각하는 경향이 있다.

세계적인 방법론은 수십가지가 있고, 대부분은 수십가지의 문서를 만들어야 한다. 하지만 대부분의 실리콘밸리의 SW회사들은 이런 방법론을 따르지 않는다. 회사의 규모, 성격에 따라서 매우 다르다. 국방부 프로젝트 또는 대규모 프로젝트를 주로 하는 회사는 상당히 많은 문서를 만들지만 그렇지 않은 회사들은 꼭 필요한 문서 몇가지만 만는다.

셋째, 우리나라에서는 문서를 나중에 만드는 문제가 있다. 문서는 개발을 빨리하기 위해서 만드는 것인데 다 개발해 놓고 문서를 만들면 시간만 추가로 들어갈뿐만 아니라 문서의 내용도 충실히 작성할 수가 없다. 이렇게 작성한 문서는 나중에 효용성도 떨어진다. 문서는 다음단계를 진행하기 위해서 앞서서 만드는 것이다.

넷째, 문서를 얼마나 자세히 적어야 하는지 잘 모르고 있다. 대부분 문서를 너무 상세히 적어야 하는 것으로 생각하고, 처음에는 의욕적으로 적기 시작하는데 점점 지쳐가고 나중에는 업데이트도 잘 안된다. 문서는 상황에 맞게 최소화 해서 만들어야 한다. 그래야 중복이 줄어들고 낭비가 줄어든다.

문제점을 정리하면 다음과 같다.

• 개발자 역량의 차이
• 수십개의 문서를 만들어야 하는 것으로 착각
• 문서를 나중에 추가로 만든다.
• 문서를 너무 자세히 적으려고 한다. 

소프트웨어를 개발하면서 문서를 제대로 작성하는 이유는 개발을 빨리 하기 위해서이다. 

• 문서는 필요한 만큼만 최소한으로 작성을 하고 
• 문서를 작성해야 리뷰를 할 수 있고, 
• 일을 효율적으로 나눠서 할 수 있고,
• 각 부서가 문서를 가지고 병행해서 전문적인 업무들을 진행할 수 있다.

역량이 떨어지고 인식이 안바뀌어서 계속 주먹구구식 개발에 머문다면 경험이 쌓이지도 않는다. 당장은 역량이 떨어져도 스펙을 제대로 작성하고 설계를 작성하고 리뷰하는 경험을 꾸준히 쌓아야 한다. 그래야 문서를 작성하는 것이 진짜로 소프트웨어를 빨리 개발하는 것을 경험하게 될 것이다. 

그리고 이렇게 빨리 소프트웨어를 개발하는 것을 경험해본 사람들은 다시 옛날로 돌아가지 않는다.

"문서를 작성해보자"라고 생각을 굳혔으면 "스펙"(SRS) 문서를 먼저 작성해보라고 권한다. 스펙문서만 제대로 작성해도 80%는 해결 된 것이다. 그리고 역량이 좀더 늘면 다른 문서들을 하나씩 작성해보기 바란다.

이슈를 모으기도 정말 어렵다.

많은 회사들이 개발 프로세스 개선을 하겠다고 선진 개발 방법론을 흉내내거나 실패한 대기업의 프로세스를 가져다가 적용하곤 한다.

복잡한 프로세스와 많은 Template를 가져다가 적용해보려고 하는데 대부분은 실패를 한다.

기초적인 것이 해결이 안된 상태에서 너무 어려운 것을 적용할 수 없다.

기초적인 것들이 여러가지가 있지만 회사의 이슈들을 한군데로 모으는 것만도 정말 어렵다.

이슈(버그)관리시스템을 사용하는 회사는 많지만 이슈관리시스템에 회사의 모든 이슈를 다 모아서 개발자는 오로지 이슈관리시스템만 보고 개발을 할 수 있는 회사는 드물다.

이슈관리시스템을 통하지 않고 전화, Email, 메신저를 통해서 여전히 개발 요청을 하는 경우가 많다.

어려운 시도를 하기보다는 먼저 이슈관리시스템에 모든 이슈를 모으는 일을 먼저 해보기를 권한다. 이것만 해도 회사에 제대로 정착되는데 1년이 넘게 걸리곤 한다. 그것도 잘 되었을 경우이다.

 버그, 개발요청, 업무요청, 협업관련정보 등 개발 이슈는 무조건 다 모아야 하고, 그외에 업무 이슈들도 모으면 좋다.

개발자는 하나의 시스템에서 모든 개발 요청을 다 볼 수 있고 관리할 수 있어야 한다.

전화, Email을 통한 요청을 일부라도 허용하는 예외를 둬서는 안된다. 예외는 전체 문화를 망가뜨릴 것이다.

시스템은 많아질수록 개발자가 귀찮아지고 비효율적으로 변한다.

경영자가 관리가 잘 안된다고 생각하고 자꾸 관리하는 시스템을 늘리면 관리가 잘되는 것이 아니고 빠져나갈 구멍만 늘어간다. 중심이 되는 이슈관리시스템 하나라도 제대로 사용하는 것이 중요하다. 

개발에 투입할 절대 시간은 정해져 있으니 최대한 개발에 집중할 수 있도록 시스템은 간소화 하고 집중화 해야 한다. 시스템이 많아지면 시스템 때문에 개발 시간을 빼앗기게 된다. 

하지만 이슈관리시스템으로 모을 수 없는 것들이 있다. 원래 전문 시스템이 있는 고객요요청, 재고관리, 인사, 재무, QA관련, 프로젝트 관리, 비용처리등은 ServiceDesk, ERP, HR, MIS, QMS, PMS 등의 시스템을 사용해야 한다. 일부는 이슈관리시스템과 연동할 수 있지만 대체는 안된다. 

작은 회사에서 전문 시스템이 없을 경우 이슈관리시스템으로 대충 관리를 할 수 있지만 이는 임시이다. 나중에 회사가 커지면 전문 시스템을 도입해야 한다.

이슈관리시스템 하나만 보더라도 회사의 역량이 얼마나 되는지 대충 알 수 있다. 어디 끝내주는 방법이 없을까 고민하지 말고 이슈관리시스템 하나라도 제대로 쓸 수 있도록 하자.

변화에 실패하는 9가지 고정관념

회사는 끊임없이 변화하지 않으면 지속 성장하지 못한다. 하지만 변화는 피와 살을 깍는 고통을 동반하고 또 많은 회사가 변화에 실패해서 성장하지 못하거나 사라져간다.

보통의 사람들은 대부분 변화를 싫어하고 기존에 하던대로 계속 하기를 원한다. 따라서 수많은 고정관념을 가지고 변화를 거부한다. 이를 극복하지 않으면 변화는 성공할 수 없다.

물론 제대로된 변화를 시도해야 한다는 전제조건이 필요하다. 어설픈 변화의 시도로 직원들만 고생하고 더 비효율적으로 변하는 변화도 수두록하다. 이러한 시도들이 쌓여 가면서 고정관념이 쌓인 것도 사실이다.

이러한 고정관념에는 어떠한 것들이 있는지 알아보고 극복해보도록 하자.

1. 전에 안해본줄 알아?

대부분은 과거의 잘못된 경험으로 인해 누적된 불신감이 변화에 거부감을 유발한다. 어설프게 시도한 과거의 경험은 잊어버리고 제대로 다시 해야 한다.

2. 어디 얼마나 잘되나 보자

회사에서 시도하는 변화를 무조건적으로 냉소적인 비판을 하는 경향이 있는 사람들이 있다. 이런 경우 강제로 따라오게 하던가 강제로도 안되는 직원들은 내보내는 것이 좋다.

3. 나는 바쁘니가 잘되면 따라갈께

누구나 나는 바빠서 변화할 시간이 없다고 하는데 그렇게 변화를 미루면 가치없는 일을 하는데 계속 더 바빠질 뿐이다. 적절한 시기에 결단을 해서 변화를 모색하지 않으면 안된다. 

4. 어차피 하가다 안되서 원래대로 돌아갈텐데

과거에 변화의 시도들이 여러차례 실패하여 원래대로 회귀했던 경험이 쌓여서 새로운 변화의 시도도 불신하며 따라가는 척만 하는 경향들이 있다. 직원들의 적극적인 참여 없이는 실패하기 쉽다. 무조건적인 외형적 변화보다 먼저 인식의 변화를 시키는 것이 필요하다.

5. 우리 회사가 하는일이 어련할려구

그동안 회사가 직원들에 신뢰를 주지 못하여 직원들의 믿음을 갖지 못하는 경우가 많다. 회사는 직원들의 신뢰에 대해서 소홀히 생각하는 경우가 많은데 이런 경우 변화의 흐름에 직원들을 동참시키기가 어려워진다.

6. 구관이 명관이다.

자신이 오랫동안 해왔던 방법을 무조건적으로 맹신하는 것이다. 그 방법이 지금까지 성공하는데 큰 역할을 했어도 앞으로 회사가 더욱 성장하는데는 큰 걸림돌이 되는 것이 일반적이다. 회사에서는 무조건적으로 위기 의식을 심어주기 보다는 변화가 필요한 실상을 직원들에게 제대로 이해 시키고 변화에 동참시키는 것이 필요하다.

7. 문서로 보고하라니까

주먹구구식으로 오랫동안 일을 하다가 체계적으로 바꾸려고 하면 무조건 모든 것은 문서로 작성하고 문서로 처리를 하려고 한다. 문서는 꼭 필요하지만 필요한 만큼보다 더 만들면 무조건 손해이다. 가장 좋은 것은 문서를 꼭 필요한 만큼만 최소로 만드는 것이고 회사의 규모에 맞게 가능하면 적게 만들어야 한다. 문조건 문서로 보고하라는 문서 지상주의는 오히려 변화를 방해한다.

8. 프로세스대로 해야지

프로세스를 핑계로 일을 제대로 진행하지 않는 경우가 있다.

프로세스는 일을 효과적으로 하기 위한 방법이지 일을 방해해서는 안된다. 프로세스를 너무 엄격하게 만들어 놓으면 오히려 부담이 되고 프로세스를 지키려고 효율이 더 떨어지게 된다. 프로세스는 현재의 역량에 알맞게 감당할 수 있게끔 만들어야 하고 효율적으로 적용해야 한다. 프로세스를 기계적으로 따라서 일이 진행될 수 있으면 직원들은 모두 로봇으로 바꿔도 될 것이다. 하지만 그런 일을 발생하지 않는다. 프로세스는 부담이 아니고 일을 효과적으로 처리하기 위한 방법이라는 것을 잊으면 안된다. 

9. 우리 회사는 다르다.

우리 회사는 매우 독특해서 다른 회사들이 하는 방법은 적용이 안되고 지금하고 있는 방법을 바꿀 수 없다고 생각하곤 한다. 그 예로 고객이 요구사항을 자꾸 바꾸고, 개발 기간이 너무 짧다는 등의 예를 든다. 하지만 그렇게 생각하는 대부분이 수많은 회사들이 이미 겪고 있는 것들이고 그렇기 때문에 이러한 환경에 좀더 효율적으로 대처하고자 하는 것이다. 우리 회사는 다른 것이 아니고 다르다고 착각하는 것이다.

변화가 어려운 것은 확실하다. 하지만 변화하지 않고는 성장하기 어렵다. 스스로 변화를 시도하가 실패하기보다는 전문가의 도움을 받는 것도 좋은 방법이다. 

가장 중요한 것은 경영자의 의지와 직원들의 동참이다.

좋은 프로그래머가 되는 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가지 방법이 도움이 될 것이다.