금융공기업 재직자가 읽은 실용주의 소프트웨어 개발

실용주의 소프트웨어 개발 - 현장에서 길어올린 소프트웨어 개발 베스트 프랙티스(Best Practices)
오병곤 지음 / 로드북 / 2017년 4월

1. 필자 소개

이 글을 쓰는 저자는 IT 전문가로 성장하기 위해 꾸준히 노력하는 사람이다. 초등학교 때 하이텔, 나우누리, 에듀넷, 키텔(?) 등의 PC 통신을 통해 프로그래밍을 알게 되었다. 컴퓨터로 무언가를 만들고 고치는 것이 좋아서 대학교에서는 컴퓨터공학(Computer Engineering)을 전공했다.

국내와 해외에서 짧고 굵게 다양한 경험을 했으며 현재는 금융공기업에 재직중이다.

2. 어떻게 읽게 되었는가

대학동기의 소개로 오병곤 대표님이 저술하신 <실용주의 소프트웨어 개발> 책이 출간 서평 이벤트를 한다는 것을 알게 되었다.

이벤트에 응모 후 당첨이 되어서 책을 수령하게 되었다.

2. 누구를 위한 책인가

<실용주의 소프트웨어 개발>의 독자는  소프트웨어 개발을 똑똑하게 하고 싶은 프로젝트 관리자(Project Manager, PM), 소프트웨어 개발이라는 숲 속의 나뭇가지가 아니라 전체 그림을 보고 싶은 개발자(Engineer)이다.

개인적으로는 공공기관에서 외주를 통해 소프트웨어를 도입하려는 업무 담당자가 이 책을 읽었으면 한다. 공공기관의 IT 부서에서 근무를 하면 신규 SW도입 또는 유지보수 계약 등 관리적인 측면에서 일을 많이 하는데 이 책을 통해 여러 가지 도움이 되는 내용을 많이 얻을 수 있었기 때문이다.

3. 책 구성

이 책은 아래의 세 가지 파트로 구성되어 있다.

1. 기술(Engineering)
2. 관리 및 지원(Management & Support)
3. 기본(Fundamental)

각 파트는 현실, 우수사례, 산출물, 요약이라는 내용으로 이루어져있다. 각 파트 안의 주제가 적당한 분량으로 나누어져 있어 글이 잘 읽힌다.

4. 좋았던 점 세 가지

<실용주의 소프트웨어 개발>에는 실무에 활용할 수 있는 훌륭한 내용이 많이 있다. 그 중에서 필자에게 와닿았던 좋았던 점 세 가지를 추려보았다.

첫째, 개발에 대한 이야기만 하지 않았다는 점

이 책은 소프트웨어 개발을 다루지만 그렇다고 해서 소프트웨어 개발만 다루지는 않는다. 필자는 이 점이 가장 마음에 들었다. 특별히 들어가는 글인 ‘우리가 버려야 할 세 가지 관행에 대하여’는 큰 울림이 있었다.

여기서 말하는 세 가지 관행은 Word Hard, Work Fast, Work in The Same Way를 말한다. 대부분의 사람들이 자기보다 똑똑하지 않은 사람들이 만들어놓은 관행에 순응하며 산다. 이 글을 읽는 필자도 그러한 현실에 굴복하며 살 때가 많다. 이러한 사실이 참 안타깝다.

Work Hard를 먼저 살펴보자. 경제협력개발기구(OECD) 자료에서 발간하는 ‘1인당 평균 실제 연간 근로시간’을 보면 2014년 기준으로 한국이 연간 2,124시간을 일을 한다. OECD 회원국 평균 근로시간이 연간 1,770시간이므로 한국인 노동자는 연간 354시간, 주당 평균 6.8시간을 더 일한다. 야근을 안하면 열심히 일하지 않는다고 생각하는 꼰대문화, 고객 또는 관리자에게 내가 열심히 일하고 있음을 보여주기 위한 불필요한 행동 등 한국의 평균 근로시간이 긴 데는 여러 가지 이유가 있다. 프랑스에서 일할 때 필자의 관리자는 나에게 이렇게 말했다.

네가 야근을 하면 다음 날 업무효율이 떨어지니 가급적 야근은 안했으면 좋겠다. 일이 많으면 스케줄을 재조정하자.

대한민국은 과거의 성공방식이었던 Word Hard를 버리고 일의 양(Quantity)이 아니라 질(Quality)로 승부하는 Work Smart를 받아들여야 한다.

Work Fast도 문제다. 소프트웨어 개발은 건물을 짓는 건설업과 다르다. 한국의 ‘빨리빨리’문화를 잘 적용하면 큰 경쟁력이 될 수 있다는 사실에는 공감하지만 무리한 속도전은 얻는 것보다 잃는 게 더 많다. 이에 대한 내용은 필자의 생각을 더 적기보다는 책을 인용함으로써 마치겠다.

모든 일을 빠르게 처리할 수는 없다. 빠르게 처리하는 일은 대부분 부가가치가 높은 일이 아니다. 꼭 해야 하는 일이지만 품질과는 크게 상관없는 일은 속도를 내고, 우선순위가 높고 중요한 일은 일에 대해 깊이 생각하고 다각도로 방안을 찾고 집중해서 처리하는 것이 좋다. 빠름과 느림의 조화를 통해 일의 고삐를 쥐고 일의 성과를 만들어 내는 게 현명한 전략이다. – <실용주의 소프트웨어 개발>, 18쪽

Work in The Same Way는 다른 말로 매너리즘이라고 한다. 끝없는 야근을 종료하려면 지금 하는 일의 프로세스에 도전해야 하는데 대부분은 이러한 일을 하지 않는다. 순환보직을 하는 공공기관은 더 심한 것 같다. 힘들어도 어차피 2-3년 이면 다른 사람이 할 일이라는 생각에 개선할 생각을 하지 않는다. 개선을 하려면 힘이 드는데 그에 대한 적절한 보상이 없거나 미미할 때가 많기 때문이다. 하지만 환경만 탓할 수는 없지 않은가? 필자는 책을 읽으며 본인이 맡은 일에 대해서, 본인의 삶에 대해서 혁신할 수 있는 환경을 만들기로 결심했다. 어떻게(How)에 대해서는 더 생각해봐야겠지만 모든 변화는 확고한 결심에서 시작되니 곧 더 좋은 변화가 내 삶에 올 것임을 믿는다.

포스트 잇은 우연히 발견되었지만 그 우연이 가능한 3M의 환경은 웅ㄴ이 아니었다. – 짐 콜린스

둘째, 소프트웨어 개발 및 관리에 대한 모범사례

<실용주의 소프트웨어 개발>에는 소프트웨어 개발 및 관리에 대한 모범사례가 많이 수록되어 있다. 그리고 필요한 경우는 각 개발단계에서의 산출물의 목록과 템플릿도 제공한다.

예를 들어, 아래는 요구사항 종류에 대한 목록을 나열한 표이다.

필자는 현재 요구사항정의서를 작성중인데 요구사항 목록 뿐만 아니라 책 안에 있는 다양한 자료를 보면서 큰 도움을 받고 있다. 물론 기업에서 일을 잘하는 방법 중 하나는 기존의 잘 된 문서를 보면서 자신의 업무에 적용하는 것이다. 하지만, 거기에만 머무르면 앞에서 말했던 기존에 하던대로 업무를 하는 관행(Working in the same way)에 빠질 수 있다. 타 기관에서 작성한 문서, 소프트웨어 개발 도서 등 여러 가지 자료를 함께 참고하면서 이전보다 더 잘 일하면 더 좋지 않을까?

아키텍처 설계, 프로그램 명세서 작성, 테스트 설계, 대가 산정, 개발자 채용, 품질활동 등 공공기관 IT부서의 기획팀에서 일하면서 한 번쯤은 고민해봤을 내용에 대한 훌륭한 답변이 이 책 안에 가득하다.

우수한 조직은 비즈니스 목표 달성에 부합하는 측정활동을 수행한다. 아래 그림은 책 중간에 소개되었던 GQM(Goal, Question, Metric)이라는 도구인데 실무에 적용할 수 있는 훌륭한 내용이라 생각하여 이 포스트에도 추가했다. 올바른 목표와 질문을 하면 이에 대한 정량적인 데이터를 수집하여 올바른 의사결정을 하는 데 도움을 줄 수 있다.

셋째, 일의 기본에 대한 내용

<실용주의 소프트웨어 개발>은 소프트웨어 기술과 관리 외에도 일의 기본(Fundamental)을 다룬다. 직장생활 2년 차인 필자에게 도움이 되는 내용이 많았다. 글을 읽으면서 그래도 나름대로 열심히 살고 있고, 꾸준히 발전하고 있다고 생각했는데 아니었다.

소프트웨어 개발에서 많이 쓰는 방법론은 ‘정보공학 방법론’도 아니고 ‘객체지향 방법론’도 아니다. 그것은 ‘일단 짜보고 고치기’ 방법론이다…(중략)… 일단 짜보고 고치기 방식은 기본적인 소프트웨어 개발 절차를 무시하고 우연에 맡기는 프로그래밍이다. – <실용주의 소프트웨어 개발>, 289쪽

소프트웨어 개발을 주먹구구식으로 하는 것처럼 내 삶도 주먹구구식으로 살고 있는 것은 아닌가라는 생각에 부끄러웠다.

무슨 일을 하든 그 일을 사랑하는 사람은 정성을 다하게 된다. 정성을 다하면 보답이 따른다. 일의 가치는 객관적으로 부여되는 것이 아니라 일에 대한 태도가 결정한다. – <실용주의 소프트웨어 개발>, 290쪽

5. 아쉬웠던 점 두 가지

이 책을 읽으면서 실무에 바로 적용할 수 있는 내용이 많았다. 개인적으로는 기술적인 부분보다는 관리적인 측면에서 큰 도움을 받을 수 있었다. 그렇다고 하더라도 이 세상에는 완벽한 책이 존재하지 않고, 한 사람을 안주하게 만드는 달콤한 칭찬보다는 계속 정진할 수 있도록 만드는 “배려깊은 말”이 중요하다고 생각하기에 감히 아쉬웠던 점을 적는다.

첫째, 각종 서식을 제공하지 않음

<실용주의 소프트웨어 개발>에서 소개하는 여러 가지 서식을 파일로 공개하면 더 실용적인 책이 되었을 것 같다. 기본적인 서식 파일을 제공하면 책을 읽은 독자가 좀 더 쉽게 현실에서 배운 지식을 활용할 수 있지 않을까?

둘째, 여러 가지 관리업무 자체를 체계적으로 관리할 수 있는 방법의 상세설명 부재

앞에서도 계속 언급했듯이 이 책에는 훌륭한 소프트웨어 관리기법을 소개한다. 하지만, 각 관리 방법을 적용하는 것은 가능하더라도 여러 가지 관리업무를 체계적으로 관리할 수 있는 방법에 대해서는 설명이 다소 부족한 것 같다.

물론 요구사항 및 결함관리를 위한 도구인 Redmine, 형상관리를 위한 Subversion, Git 등을 소개하고 있지만 단순한 언급에서 끝난다는 점이 아쉽다. 예를 들어 사용자의 요구사항은 발전해서 테스트 시나리오, 소스코드, 문서 등으로 발전한다. 요구사항은 역방향으로도 추적이 가능해야 한다. 알지만 이것을 어떻게 실천할 것인가? 특정 도구에 대한 설명이 어려웠다면 실무 경험이 풍부한 저자의 경험을 소개하는 것도 좋지 않았을까? 예를 들어, 파일의 이름은 이렇게 규칙을 정했고, 폴더 구조는 이렇게 만들어서 각 프로젝트를 관리했다는 식의 내용으로 말이다.

6. 총평

소프트웨어 개발 전 과정을 이해하고 싶고 이전보다 좀 더 나안 관리자, 개발자가 되고 싶은 사람이 이 책을 읽는다면 분명히 얻어가는 게 있을 것이라 생각한다. 따라서 이 책은 돈과 시간을 들여 읽을만한 가치있는 책이다.