소프트웨어 개발의 극과 극

꽤 오래 전에 TV에서 "비교체험 극과 극"이라는 프로그램을 방영한 적이 있습니다. 어떤 아이템을 정해서 가장 비싼 것과 가장 싼 것을 비교하는 프로그램이었는데 꽤 재미있게 본 기억이 납니다.

소프트웨어를 개발하는 현장에서도 극과 극 현상은 드물지 않게 발생합니다.

여러 회사를 분석해보면 완전 주먹구구이거나 또는 너무 무거운 방법론을 도입해서 오히려 부담이 되는 경우가 많습니다. 적당히 중간인 회사를 찾기가 더 어렵습니다.

완전 주먹구구식 가내수공업 형태의 개발방식도 문제가 있지만, 몸집과 역량에 걸맞지 않은 거대한 방법론을 무조건 따라하는 것은 더 문제가 큽니다. 그럴 바에는 차라리 주먹구구가 낫습니다.

그런 주먹구구회사가 문제를 깨닫고 거대 방법론들을 스스로 연구해서 도입을 하면 그 핵심은 모르고 형식만 따라하는 경우가 많습니다. 그러다보면 프로세스가 너무 복잡하고, 문서도 너무 많이 만들어야 되는 경우가 허다합니다. 이런 시도는 거의 실패한다고 보면 됩니다. 애초에 따라 할 수도 없고, 억지로 따라한다면 비용과 시간은 몇 배로 더 들고 회사는 망하기 길 밖에 남지 않습니다. 국내의 대부분의 소프트웨어 회사들은 그러한 거대 방법론은 필요하지도 않습니다. 또 그렇게 많은 문서는 만들 필요도 없습니다. 개발에 필요한 핵심문서 몇 개만 자신들이 만들고 업데이트하고 감당할 수준 정도만 만들어내야 합니다.

극과 극의 양쪽이 아닌 회사에 딱 필요한 수준의 중간점을 찾아서 적용해야 합니다.

개발자도 문서를 잘 작성할 수 있어야 한다.

개발자(엔지니어)들이 문서를 잘 작성하지 못한다는 것은 익히 알려져 있는 사실입니다.

 

개발자에게 프로그래밍 실력이 더 중요하지 문서 작성 기술이 얼마나 중요하겠냐?라고 생각하는 사람이 있을 수도 있겠지만, 개발자가 성장할수록 문서 작성 능력의 중요도는 점점 더 커집니다.

 

문서를 잘 작성하지 못하는 개발자는 협업을 하는데 있어서 치명적인 결함을 가지고 있다고 할 수 있습니다.

 

그럼 문서를 잘 작성하는 것은 무엇이고? 문서를 잘 작성하지 못하는 것은 무엇일까요?

잘 작성되지 못한 문서의 특징을 한번 살펴보죠.

 

• 문서의 내용이 쉽게 이해가 되지 않는다. 외계어로 작성된 것 같다.
• 여백 없이 빽빽이 작성되어서 읽는데 너무 피곤하다.
• 문법이 많이 틀려서 내용도 신뢰가 가지 않는다. 주어도 없고 문장의 앞뒤가 전혀 맞지 않는다.
• 주변 얘기만 빙빙돌려서 하고 있고 핵심이 뭔지 잘 모르겠다.
• 내가 관심있는 내용은 없고 작성자의 관심거리만 적혀있다.
• 사용하고 있는 단어들이 너무 전문적이고 어렵다.
• 분량이 너무 많아서 읽기 힘들고 주제 파악이 힘들다.

 

물론 개발자라면 개발에 필요한 핵심문서를 잘 작성할 수 있어야 합니다. 하지만, 이같이 기본적인 문서작성 기술도 없다면, 개발문서라고 해서 잘 작성할 수는 없습니다.

 

"조엘온소프트웨어"의 저자인 조엘 스폴스키는 개발자를 뽑을 때 글을 잘 쓰는 사람을 뽑는다는 원칙이 있다고 합니다. 글 쓰기 능력을 키우는 것은 프로그래밍 실력을 키우는 것보다도 더 어려울 수 있습니다. 그래서 아예 글을 잘 쓰는 사람을 뽑는 것이 더 합리적으로 보이기도 합니다.

 

개발자들은 문서를 잘 작성하지 못한다는 얘기는 어디서나 통하는 말이지만, 특히 우리나라의 개발자들은 단순 주입식 교육 환경 때문에 읽고, 외우는 것은 잘하지만 자신의 의견을 남들에게 쉽고 조리있게 전달하는데는 익숙하지 못합니다. 그렇다고 문서작성을 포기할 수는 없죠. 평생 혼자서 개발할 것이 아니라면 문서는 점점 더 필요하게 되죠. 아니 혼자서 개발을 하더라도 문서를 잘 작성하는 것이 필요합니다.

 

그럼 문서 작성 실력을 키우기 위해서 어떻게 해야 할까요? 역시 훈련이 필요합니다. 단순히 여러 번 작성해 본다고 되는 것이 아니라 제대로 작성하기 위해서 노력해야 합니다. 이제, 문서 작성 실력을 향상하기 위한 몇 가이드를 하려고 합니다. 그 출발점은 다음과 같습니다.

 

"문서작성 기술이 필수 기술이라는 것을 먼저 인식해야 합니다."

 

필요성을 못 느끼면 발전도 없습니다. 그리고 문서를 잘 작성하려면 다음과 같은 것을 고려해야 합니다.

 

• 문서를 작성하는 목적은 내가 일기 위한 것이 아니고 남이 읽기 위한 것이다. 읽는 사람의 눈높이에 맞춰서 적절한 단어를 사용해야 한다.
• 주제를 직설적으로 전달해야 한다. 문서를 읽는 사람은 친절하게 문서를 처음부터 끝까지 다 읽어 줄만큼 한가하지 않다. 주제를 먼저 전달함으로써 문서를 읽는 사람이 문서를 계속 읽을지 말지 결정할 수 있도록 해야 한다.
• 필요한 내용을 쓴다. 문서 작성의 목적을 달성할 수 있도록 문서를 읽는 사람이 기대하는 내용을 충분히 적어야 하며 자신만 관심 있어 하는 필요 없는 내용은 쓰지 않는다. 이런 내용들은 문서의 양만 늘리고 문서의 가치를 떨어뜨린다.
• 사실과 의견을 확실히 구분하여 작성한다. 사실과 의견의 혼동은 수많은 오해를 불러일으키게 된다. 심지어는 중요한 비즈니스에서 잘못된 결정을 유도할 수도 있다.
• 쉬운 표현을 써야 한다. 복합문장은 이해하기 어려운 경우가 종종 있다. 가능하면 문장은 작게 잘라서 하나의 문장에 하나의 논리만 포함하도록 하는 것이 좋다.
• 맞춤법이 맞아야 한다. 맞춤법이 틀리면 문서의 내용 및 문서 작성자에 대한 신뢰가 떨어질 수 있다.
• 읽기 편하게 화면을 구성해야 한다. 화면에 적당한 여백을 두고 자간, 행간을 조절하고, 적절한 그림이나 표를 사용해서 문서를 읽는 사람이 지루해 하지 않고 문서의 내용을 빨리 파악할 수 있도록 해야 한다.
• 화면 꾸미기에 시간을 허비 하지 않는다.

 

다시 한번 강조를 하지만 개발자는 문서를 잘 작성할 줄 알아야 합니다. 구슬이 서말이라도 꿰어야 보배이듯이 머리 속에 아무리 좋은 정보를 담고 있어도, 이를 문서로 잘 작성할 수 없다면, 고급 개발자는 될 수 없습니다. 꾸준히 문서를 작성하고 읽는 사람으로 부터 평가를 받아야 합니다. 문서를 잘 작성해야 한다고 깨닫는 것이 문서를 잘 작성하기 위한 과정의 시작입니다.

개발자 윤리 장전

소프트웨어 개발자라는 직업은 특수성이 많은 것 같습니다.

• 뭘 좀 잘못해도 쉽게 눈에 안띄고, 
• 문제가 되어도 딱히 누가 잘못한지도 잘 모르겠고, 
• 맘 먹고 동료들이나 경영자를 속이고 있어도 쉽게 알아차리기 힘들고,
• 자신의 실력보다 과대포장을 해도 눈치채기 어렵습니다.
• 또 하루종일 일을 하고 있어도 정말 열심히 하는 것인지 노는 것인지 알아내기 어렵고,

이러한 소프트웨어 개발자들이 빌딩을 만들거나 비행기를 만든다면 빌딩이 무너지거나 비행기가 추락하겠죠. 하지만 소프트웨어 필드에서는 그러한 오류가 종종 숨겨지고, 원인을 밝히기 어려운 경우가 태반입니다.

결국 소프트웨어 개발자들은 스스로의 발전을 위해서도 윤리의식을 가지고 있어야 합니다. 이러한 자세는 개발자 스스로에게도 도움이 된다는 것을 강조하고 싶습니다.

이렇게 개발자들이 지켜야할 윤리의식에 대한 저의 생각을 나열해봤습니다.

나의 시간의 일정부분은 Peer Review에 사용하겠다. 나의 지식과 업무 성과는 문서화하여 동료들과 공유하겠다.  소프트웨어 설계 시 미래의 변경을 염두 하겠다.  소프트웨어 개발 시 유지보수 개발자들을 배려하겠다.  아키텍처를 구상할 때 회사의 비즈니스를 고려하겠다.  나의 편협한 지식으로 동료와 경영자를 현혹시키지 않겠다.  오만에 빠지지 않고 꾸준히 공부하겠다.  동료들과 같이 정한 개발 규칙을 따르겠다.

이 외에도 개발자들이 지켜야 할 윤리의식에 대한 의견 있으신 분들은 댓글 남겨 주세요.

요구사항 분석의 출발점

소프트웨어 개발에 있어서 요구사항 분석이 가장 중요하다는 것은 앞에서도 이미 주지한 사실입니다.

2008/11/19 SRS(Software Requirements Specification)의 중요성

2009/02/04 소프트웨어 개발 단계에서 가장 중요하다고 생각하는 것은?

요구사항 분석의 산출물은 SRS, 요구사항분석서 또는 다양한 방법론에 의해서 다른 문서들이 나올 수 있겠죠. 그럼 요구사항분석의 출발은 무엇일까요? 어떤 기능을 제공하기를 원하나 조사하는 것일까요?

"왜 이 프로젝트를 하려고 하는가?"입니다.

프로젝트를 하는 목적과 목표를 알아야 모든 요구사항이 일관성을 갖게 됩니다.

이걸 누구나 다 알고 있다고요?

제 경험에 의하면 그렇지 않습니다. 프로젝트 구성원에게 각각 물어보면 프로젝트의 목적에 대해서 서로 다른 얘기를 합니다. 프로젝트의 목적이 공유가 안되어 있거나 심지어는 심각하게 고민도 해보지 않은 경우 입니다. 그렇다면 프로젝트는 산으로 가는 경우가 많습니다. 수많은 의견 충돌 시 프로젝트의 목적에 맞게 합리적인 결정이 이루어지지 않습니다.

지금 프로젝트를 하고 있다면 프로젝트의 목적이 정확하게 공유되고 같은 생각을 하고 있는지 확인해보세요.

개발자끼리가 아닙니다. 개발자, PM, PL, QA, 영업, 마케터 등 프로젝트 관련자 모든 사람이 같은 프로젝트 목적을 공유하고 있는지 입니다.

그럼, 서로 팀워크가 착착 맞아서 눈빛만 보면 서로 다 안다고 하면 서로 같은 생각을 할까요? 이런 경우에도 프로젝트 목적이 뭔지 명확하게 정의해서 공유하지 않으면 각기 다른 생각을 하는 일은 매우 흔합니다. 요구사항 분석 산출물의 맨 앞에는 프로젝트 목적을 명쾌하게 정리해서 모두 공유할 수 있도록 해야 합니다. 물론 모든 관련자가 동의를 하는 내용이어야 합니다.

프로젝트를 시작하면 왜 이 프로젝트를 하는지 명확하게 알아내고, 정의하고, 공유해야 합니다.

[오늘의 한마디] 경기에서는 개의 크기가 아니라, 팀의 조화가 중요하다.

얼마전 "스노우버디즈"라는 가족 영화를 보았는데, 비록 개가 한 소리(?)지만 좋은 말이 있어서 인용을 해볼까 합니다.

"경기에서는 개의 크기가 아니라, 팀의 조화가 중요하다."

어린 강아지들이 개썰매 대회를 준비하면서 스승이 해준 말입니다.

하물며 개들이 알고 있는 것을 인간들이 모르면 안되겠지요. ^^

아주 소규모 (2,3명 이하)의 개발팀이라면 각 개인의 역량이 프로젝트를 성공시키는 가장 큰 요소가 되겠지만, 3,4명만 넘어가는 개발팀에서도 팀의 조화가 아주 중요한 요소가 됩니다. 특히 팀이 커질수록 프로젝트의 성공은 한두명의 역량보다는 팀워크에 달려 있다고 해도 과언이 아닙니다.

혼자서는 개발을 잘하고 아는 것은 많지만 협력해서 일할 줄 모르는 개발자는 큰 프로젝트에서는 배제를 하게 됩니다. 그런 개발자에게는 연봉을 많이 줄수 없는 이유이기도 합니다. 

우리는 당장 써먹을 수 있는 경력 개발자 위주로 뽑아요.

언제부터인가 소프트웨어 개발자를 경력 개발자 위주로 채용하는 것이 일반화 된 것 같습니다.

물론 다른 업계도 마찬가지이지만, 당장 써먹을 수 있는 경력직을 선호하는 것은 사실입니다.

그렇게 경력직 위주로 개발자를 채용하다가 개발팀의 조직 구조가 효율적이지 못하게 변하는 경우를 종종 보게 됩니다. 소규모 개발조직이라면 어떠한 구조라도 별 상관이 없다면 일정 규모 이상의 개발조직은 각 직급별 적정한 분포를 가지는 것이 효율적입니다. 

그럼, 경력 개발자 위주로 채용을 하다가 종종 벌어지는 조직 구조의 변화의 예를 하나 들어 보겠습니다.

진화 단계	설명
탄두형	회사의 초기에 일반적인 조직 구조 형태입니다.
항아리형	신입 개발자보다 경력 개발자를 위주로 채용을 하면서 자연스럽게 아래 부분이 줄어들게 됩니다. 또 아래 계층이 충성도가 부족하여 더 많이 퇴사를 하게 됩니다.
스페이드형	항아리형이 점점 심해지면 뒤늦게 개발 조직이 비효율적으로 변한 것을 깨닫고, 신입 직원을 다시 뽑기 시작합니다. 이러면서 조직은 스페이드형으로 변합니다.
오뚜기형	다시 정상적인 조직 구조로 바꾸려고 해도 비어있는 중간 계층은 쉽게 메꾸기가 어렵습니다. 즉, 회사를 이끌어가는 초창기 멤버와 고참들과 뽑은지 얼마 안되는 직원들이 개발조직의 주를 이루게 됩니다. 그래서 정상적인 분업이 이루어지지 않습니다. 일은 고참들에게 몰리고, 하층 개발자들은 기대에 못미치는 성과를 내고 있습니다.

여기서 예로든 하부 조직이나 중간 조직이 빈약한 구조가 개발에 전혀 지장을 주고 있지 않다면 특수한 개발 조직이거나 각개격파형 개발조직 구조일 것입니다. 또는 주먹구구이거나요.

대부분의 조직은 각 기능별 계층별로 업무가 나눠지며, 아래 계층의 개발자가 인원수로는 더 많이 필요하게 됩니다. 하지만 그렇지 못한 경우 그러한 Value가 낮은 일까지 고참들이 수행을 해야 하고, 이 과정에서 자연스럽게 이루어지는 교육 및 기술 전달이 이루어지지 않는 악순환이 벌어집니다. 이 과정에서 개발 팀의 생산성은 낮아지게 되고, 미래 전만도 어두워집니다.

그럼에도 불구하고 경력개발자만을 위주로 채용하는 이유는 여러가지가 있습니다.

• 단기적인 이익을 내려는 경영층의 조급증
• 신입 개발자를 채용해도 효과적으로 교육시킬 수 있는 교육 시스템 부재
• 3,4년 미래도 내다보지 못하는 HR Plan
• 주먹구구 식으로 개발을 하고 있기 때문에 체계는 필요 없고, 무조건 경험 많고 능력 있는 개발자만 필요한 경우

이미 회사를 위해서 오랫동안 헌신한 개발자들이 개발은 잘하고 업무관련 지식은 뛰어난데, 소프트웨어 전문가로서는 턱없이 모자라는 경우가 흔합니다. 오랫동안 각개격파식으로 혼자서 북치고 장구치고 하는 식으로 개발들을 많이 해왔기 때문에 이런 일들이 일어납니다. 이경우 이러한 고참 개발자들이 다른 회사로 이직을 할 경우 그 가치가 현저히 떨어지는 경우가 많습니다. 전문가로서의 역량은 부족하기 때문입니다. 자칫하면 이러한 공신들이 희생될 수도 있고, 골치덩어리가 될 수도 있습니다.

그러면 어떻게 해야 할까요? 

적어도 개발자를 채용할 때는 오늘 당장 필요해서 뽑는다는 생각만 가지고 채용하는 것은 위험합니다. 적어도 몇 년을 내다보는 채용 계획이 있어야 합니다. 그리고 계획에 따라서 항상 채용을 위한 노력을 기울여야 합니다. 그리고 이미 채용한 개발자와 미래에 채용할 개발자들의 경력 개발 계획을 갖추고 있어야 합니다. 이것만 따로 돌아가는 것이 아니고 회사의 개발 프로세스와 조직 등 모든 것이 맞물려 돌아가야 개발자도 성장을 하면서 자연스럽게 생산성이 높은 조직을 유지할 수 있게 됩니다. 사람에서 사람에게로 고참에서 신참에게로 기술과 지식이 전달되고 조직이 계속 성장하려면 기반시스템, 개발문화가 필수적입니다. 전혀 체계가 없는 개발조직이라면 지금이라도 하나씩 갖춰나가는 수 밖에는 없습니다. 

이것을 해결할 끝내주게 좋은 방법은 없습니다. 가장 효율적인 것부터 찾아서 하나씩 바꿔나가는 겁니다.

타이핑이 느린 프로그래머

대부분의 프로그래머의 타이핑 실력은 정말 뛰어납니다.

심야에 정말 빠른 타이핑 실력을 가지고 있는 프로그래머가 타이핑을 하고 있는 소리를 들어보면 음악과도 같습니다. "딱딱딱"이 아니고 "좌르르~"소리나 납니다.

이런 개발자들을 많이 봐왔죠.

그런데, 가끔 타이핑이 느린 프로그래머를 접하게 됩니다.

심지어는 자판을 보지 않고는 영어를 입력하지 못하는 프로그래머도 본적이 있습니다.

타이핑이 개발 실력과는 크게 연관이 없는 것처럼 보일 수도 있지만, 프로그래머의 무기는 키보드인데, 타이핑이 느리다는 것은 대단한 손해가 아닐 수 없습니다.

프로그래머의 일생의 수십%는 타이핑을 하면서 보냅니다. 그 시간의 10~20%는 절약하는 것은 인생의 대단한 시간 절약이 아닐 수 없습니다. 그 반대의 경우는 대단한 낭비죠.

한글, 영어 구분하지 않고, 자신의 생각이 주르륵 바로 입력이 될 수 있도록 훈련이 되어 있어야 합니다. 타이핑이 느려서 생각의 흐름이 끊겨서는 안됩니다. 더불어서 자신이 사용하고 있는 개발툴과 에디터의 단축키들을 몸에 익혀서 자동으로 단축키를 사용할 수 있어야 합니다.

혹시 자신이 타이핑이 느리거나, 마우스에 많은 의존을 하고 있는 개발자라면 타이핑 속도 향상을 위해서 연습을 해야 합니다. 

이것은 프로그래머에게는 기본의 기본의 기본이 아닐 수 없습니다.

필자의 첫번째 상용 프로그램이 타자연습프로그램이었는데, 타자연습프로그램을 이용해서 꾸준히 일정기간만 연습해도 필요한 만큼의 속도는 누구나 달성할 수 있습니다. 그렇지 않고 실무적으로 일을 하면서 자연스럽게 속도가 느는 것을 바라는 것은 자칫 자꾸 자판을 본다던지, 또는 손가락의 위치가 틀렸다던지 하는 나쁜 습관을 가질 수 있으므로, 제대로 연습을 하는 것이 중요합니다.

이 글은 대부분의 프로그래머에게는 필요 없는 글이나, 본인이 타이핑 속도가 느리거나 팀원들 또는 신입개발자가 타이핑이 느리다면 당연히 해결해야 할 것입니다.