2012년 6월 11일 월요일

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

소프트웨어 업계에는 정말 깨기 어려운 잘못된 통념이 몇가지 있다.
많은 이들이 이러한 잘못된 고정관념과 오해에 사로 잡혀서 쉽게 변화하지 못하고 계속 잘못된 길을 걸어가고 있다.
어떠한 잘못된 통념이 있는지 알아보자.


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

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

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

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

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

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


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

진짜 개발자들 사이에서 만연해 있는 생각이다. 
개발자들은 위에서 촉박한 일정을 정해주기 때문에 무조건 일정을 맞춰야 하고 그러기 빨리 코딩을 시작해야 한다고 한다.

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

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


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

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

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

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

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



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

개발자들은 경영자들이 무리한 일정을 일방적으로 강요한다고 한다. 물론 그런 경우도 있지만 많은 경우 위에서 일방적으로 일정을 지시하지 않는다. 
표면적으로 드러난 결과가 일정 지시지만 그 과정을 살펴보면 합리적인 일정 산정과 조정이 이루어 지지 않는 경향이 있다.
개발자들이 제대로 스펙을 적어서 합리적인 일정을 제시하지 못하니 경영자도 일방적으로 도전적인 일정을 밀어 붙이고, 거꾸로 경영자가 그러하니 개발자들은 어쩔 수 없이 따르게 된다.
이는 어느 한쪽의 책임은 아니라고 볼 수 있다.

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



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

고객이 요구사항을 너무 자주 바꾼다. 
고객이 요청하면 당장 들어 줘야 한다. 
개발일정은 상상할 수 없을만큼 짧다.
고객이 요청하면 무조건 달려가야 한다. 

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

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


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

댓글 7개:

  1. 항상 좋은 글에 감사합니다.
    C/C++을 가지고 Windows환경에서 3D 응용 프로그램을 개발하고 있습니다.
    개발에 몸담은지 꽤 오래되었지만 여전히 불안하고 항상 아슬아슬하게 진행됩니다.
    이러한 저의 마음을 이 곳의 글들이 다잡아줍니다.

    한가지 부탁드리고 싶은 것은 실제 예를 보여주시면 많은 참고가 될 것 같습니다.
    물론, 다양한 상황이 있기에 만족스럽지 못할 것이고, 결국 스스로 경험해 봐야 느낄 수 있다는 것은 잘 알고 있습니다. 그런데 여기서 배운 것들을 적용하려고 해도 어디부터 시작해야 할 지 모를 경우가 많아 결국 기존 방식대로(알고 있는 방식) 개발하면서 '이건 아닌데... ' 하며 따르고 있는 제가 정말 한심해 보입니다.

    이 곳이 이러한 글을 어울리지 않으면 참고할 만한 사이트를 알려주시면 감사하겠습니다.
    무리한 부탁이지만 답답한 마음에 적어봅니다.

    답글삭제
  2. 정열님 안녕하세요.

    소프트웨어 공학에 있어서 예는 별로 도움이 안됩니다. 오히려 방해가 되는 경우가 많습니다.

    세계적인 피아니스트가 피아노를 멋지게 치는 것을 아무리 봐도 내 피아노 실력이 느는데는 별로 도움이 안됩니다. 단지 동기부여에 도움이 되거나 그냥 즐기는 거죠.

    피아노 실력이 늘려면 선생의 도움을 받아서 현재 실력에 맞는 방법으로 연습을 해야 할 겁니다. 선생이나 선배가 없으면 시행착오를 많이 겪을 수 밖에 없습니다.

    인터넷 검색해보면 나오는 수많은 스펙 문서 샘플은 오히려 독이 된답니다.

    저는 피아노를 이렇게 치기 때문에 안된다. 이렇게 쳐야 한다고 말은 하지만 그 말을 듣고 제대로 따라할수 있는 사람은 거의 없다고 보면 됩니다.

    일단 제가 쓴 책 "소프트웨어 개발의 모든 것"을 참고해보세요. 일부 도움이 될 겁니다.

    답글삭제
  3. 답변 감사합니다.

    결국 직접 부딪혀서 배울 수 밖에 없군요. 깨지더라도 조금씩 조금씩 변화시켜 보겠습니다.

    그리고 "소프트웨어 개발의 모든 것"이란 책은 제가 이미 여러 번 읽었습니다. 즐겁게 읽었습니다. 저에게 소프트웨어 개발에 대한 새로운 열정을 준 책이었습니다.

    답글삭제
  4. 명세를 처음 적기 위해(개인적으로는 스펙이나 SRS라는 용어보다 명세가 더 좋게 느껴지더군요), Joel Spolsky의 WhatTimeIsIt.com 예제나, IEEE 템플릿 등을 참조했던 적이 있었는데, 처음에는 둘 다 별 도움이 안 되더군요.

    그래서 도무지 모르겠고, 나보다 선배이신 분이 "개발은 문서 작성이 시작이다"라고 하시니, 그냥 그렇게 시작했습니다.

    그냥 중학교 때 배웠던, "소재 모으기 -> 목차 정하기 -> 글 쓰기 -> 고쳐쓰기"의 과정을 통해 명세를 적어 갔습니다.

    이제 명세 적어가면서 개발한지 약 2년 정도 되어 가는데, 참 좋은 습관이라는 생각이 듭니다. Visual Studio 앞에 놓고, 마냥 고민하는 괴로운 시간이 줄어 들고, "아, 나는 왜 기술은 다 아는데, 개발이 안 돼?"라는 물음에 답을 얻은 것 같아서 기쁩니다.

    자전거를 잘 타려면, 타 보는 수밖에 없습니다. 자전거 이론 배운다고 되는 것이 아니지요.

    지금 처음 적은 명세를 보면, 참 못 썼다는 생각을 자주 해 봅니다. 30년 소프트웨어 개발하고도 더 배워야 할 분야가 이 분야라는 이야기 계속 실감합니다.

    그 변화의 시작을 알려 주셔서 고맙습니다.^^

    답글삭제
  5. 주의사신님 안녕하세요.

    일단 용어 이슈가 있습니다.
    용어란 누구나 딱 들었을 때 같은 생각을 해줘야 합니다. "밥"이라고 얘기를 하면 누구나 "밥"을 생각해야지 다른 생각을 하면 대화가 잘 안됩니다.

    우리나라에서는 스펙을 얘기하는 수많은 단어들이 사용됩니다. 명세, 기술명세, 기능명세, 스펙, 시방서, 기능목록 등등 회사마다 다르고 셀 수 없이 많습니다.

    하지만 IEEE나 SWEBOK에서 정의한 스펙의 내용을 만족시키는 스펙을 적는 회사는 거의 없다고 보시면 됩니다.

    그러다보니 어떤 용어를 쓰던 그 내용은 서로 완전히 다르게 생각하고 있습니다.

    그래서 오해가 없게 사용할 수 있는 용어가 SRS입니다. SWEBOK에 SRS에 대한 정의가 딱 되어 있고 전세계 거의 모든 개발자가 SRS라는 용어로 스펙을 부르고 있기 때문에 의사소통에 전혀 문제가 없습니다.

    SRS를 작성해서 주세요라고 하면 내가 원하는 딱 그 SRS가 작성되서 옵니다.

    SWEBOK에 SRS에 대해서 자세히 정의가 되어 있기는 하지만 양이 좀 많고 영어로 되어 있기 때문에 우리나라 사람들은 이해하기 어렵습니다. 그리고 SRS의 정의만 보고 SRS의 정의를 깨닫기란 어렵습니다.

    주의사신님은 스펙을 이미 많이 작성해 보셨기 때문에 훨씬 잘 이해를 할수 있겠습니다.

    SWEBOK의 SRS 정의를 거의 이해하려면 SRS를 한 30년 정도 작성해 봐야 한다고 합니다.

    "소프트웨어 개발의 모든 것"에서도 최대한 설명을 해 놨습니다.

    SRS는 적는 내용부터 분석, 수집, 정리, 리뷰 등등 온갖 프로세스도 중요합니다. SRS는 내가 개발한 SW를 설명한 것이 아니고 개발할 SW의 스펙을 적은 것입니다.

    SRS를 작성하면 개발 범위 및 일정 산정이 가능하고 이를 근거로 예산을 산출하거나 외주 계약을 할 수도 있고, SRS를 보고 다른 사람이나 회사가 개발을 할 수도 있고, 관련자들이 제품을 이해하거나 자신이 담당한 업무를 동시에 진행 할 수 있습니다. 물론 프로젝트의 성격상 같은 SW라도 내용은 완전히 달라집니다.

    아무튼 주의사신님은 이미 "명세"라는 이름의 문서를 쓰는 습관을 들이고 계시니 조금씩 발전시켜 나가면 좋을 것 같습니다.

    다음 단계로는 내가 작성한 문서를 가지고 다른 개발자들과 나눠서 개발할 수 있는지를 보는 겁니다. 아직 부족하다면 컴포넌트를 나누고 인터페이스를 정의하는 작업이 부족한 것입니다. 다른 개발자들에게 문서를 통해서 일을 시킬 수 있어야 본인의 가치가 점점 올라갑니다.

    혼자 밖에 일하지 못하거나 구두로 일을 시킬 수 밖에 없는 개발자는 평생 코더 수준을 못벗어납니다.

    진행하나가시면서 부족한 것이 있으면 문의하세요. 시원하게 답을 드리도록 하겠습니다.

    답글삭제
  6. 1. 아마 제가 제일 처음 SRS 예제를 접한 조엘온소프트웨어의 번역이 '명세(원문에는 spec)'여서 명세를 제일 좋아하나 봅니다.

    2. 컴포넌트나 인터페이스에 관한 내용은 많은 부분 코드의 주석으로 가게 되고, 매우 핵심적인 부분(잘 바뀌지 않을 부분)만 설계 문서로 빼 보려고 노력하고 있습니다. 제 생각이 맞나요?

    답글삭제
  7. 컴포넌터와 인터페이스를 기술하는 방법은 프로젝트마다 다릅니다. 원칙만 알면 됩니다. 문서를 가지고 개발을 잘 할 수 있으면 되는 겁니다. 그래서 경험이 많이 필요하죠.

    프로젝트에 따라서 스펙만 잘 적으면 설계문서는 따로 필요 없는 경우가 많습니다.

    그래서 스펙과 설계의 경계는 모호하고 어느 문서에 어떻게 적어야 하는지 상황에 맞게 잘 결정해야 합니다.

    확실한 것은 가장 적게 중복 없이 적는 것이 좋습니다.

    답글삭제