태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

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

2012/01/27 23:51 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed





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

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

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

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

이런 생각을 하는 것 자체가 스펙을 제대로 이해하고 있지 못하다는 반증이다.
왜냐하면 스펙이 무엇인지 제대로 이해하고 있다면 이런 말이 나올 수가 없다.
지금 그렇게 부정하는 스펙을 작성하지 않아서 개발을 잘하고 있는가? 

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

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

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

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

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

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

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

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

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

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


image by 
Lichfield District Council 

저작자 표시 비영리 변경 금지

전규현 프로젝트/요구사항분석

Trackback Address: http://allofsoftware.net/trackback/251 관련글 쓰기
  1. Blog Icon
    althea

    매번 글 재밌게 읽고 있습니다.
    스펙을 정확하진 않더라도 간략히나마 추릴수 있는 방법은 어떤건가요?
    항상 혼자서 취미 및 공부로 코팅하는 저는 어떤 프로그램을 짜고나서 결과는 생각처럼 움직이지만 더 구조적인 방법이 생각나서 다시 만들까 매일 고민합니다ㅡㅜ

내가 개발에 집중할 수 없는 이유

2012/01/08 20:18 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



우리나라에서는 개발자들이 개발에 집중할 수 없는 환경인 곳이 참 많다.
정도의 차이가 있지만 거의 대부분이라고 봐도 무방하다.

그 결정적인 이유는 개발자 혼자서 북치고 장구치고 다해야 하는 상황이기 때문이다.

원래는 이렇게 개발자가 다해야 하는 상황은 One Man Company에서나 벌어지는 상황이어야 한다.
하지만 작은 벤처 기업이나 거대한 대기업이나 개발자가 수십명이나 또는 수백명 있어도 One Man Company에서 벌어지는 상황과 별반 다르지 않다.

그럼 왜 개발자는 개발에만 집중해야 하는가?
소프트웨어 개발이라는 것이 다른 일도 해가면서 적당히 해 나간다고 해서 잘할 수 있는 분야가 아니다. 개발만 10년, 20년을 집중해야 잘할 수 있는 분야다.
개발 외에 다른 일도 다 하면서 개발도 잘한다고? 그러면 정말 천재이거나, 자기 자신을 과대평가하거나, 지금은 그럭저럭 잘하기는 하지만 개발에 집중했으면 더 잘했을 경우 일 것이다. 

그럼 어떠한 일들이 개발자들이 개발에 집중하지 못하게 하는가?

첫째, 마케팅의 부재다.

우리나라에서는 대부분 제품 비전만 툭 던져 놓고 나머지는 다 개발자가 알아서 해야 한다.
개발할 제품이 딱 정해지면 Architecture 연구하고 Technology 공부하기 바쁜 개발자가, 고객 인터뷰도 해야 하고 경쟁회사 동향도 파악해야 하고, 회사에서 서로 다른 얘기하고 있는 사람들 다시 만나서 제품의 비전부터 다시 정해야 한다.
또, 마케팅은 온갖 요구사항 다 합쳐 놓은 Kitchen sink를 가져다주고 기획이라고 하는 경우가 많다. 결국 개발에 실패를 하기도 하고 개발을 했어도 가치가 없는 제품을 만들게 된다. 결국 고생은 개발자가 다하고 욕도 개발자가 다 먹는다.

둘째, 다음은 Technical support의 부재이다.

개발자가 가장 잘 안다는 이유로 개발자가 기술지원을 해야 한다.
가끔은 고객 사이트에서의 장애에 대한 사과를 하러 개발자가 직접 방문을 해야 한다. 이유는 고객이 화가 나서 개발자가 직접와서 사과를 하지 않으면 안된다고 영업이 주장하기 때문이다. 밖에서 발생한 모든 문제의 책임을 직접 개발자 돌리는 것이다. 코미디가 아닐 수 없다. 
영업은 이런 제스처를 취함으로써 모든 책임을 개발자에게 돌리는데 성공을 했다. 정상적인 영업이라면 이런 터무니 없는 요구는 애초에 막았어야 하는 것이다.
설령 개발자가 1차적인 책임이 있다고 하더라도 이런 일로 개발자가 사과를 한다는 것은 회사에게 훨씬 더 큰 손해를 끼치게 된다. 
이렇게 밖으로 내둘리는 개발자는 개발 실력보다는 남 비위 맞추는 실력이나 늘고, 소프트웨어 개발에 염증을 느끼게 된다.

셋째,  QA의 부재 또는 부족이다.
 
QA담당자가 없는 경우가 많고 제대로 된 기획, 스펙 없이 개발을 하다보니 제품의 기능을 개발자밖에 몰라서 개발자가 테스트를 하는 경우가 많다. 심지어는 팀장, 기획자 등 여러 관련자들이 다 테스트에 동참하는 경우가 있다. 이는 전문성을 무시하는 것이고 아주 작은 회사에서나 있을법한 일이다.

개발자는 개발하기도 바쁘고 할 일도 많다. 또한 마케팅, 기술지원, QA는 잘 하지도 못한다.
개발자는 개발에 집중해야 밥값을 하는 것이다. 다른 일을 하느라고 개발할 시간이 부족하다면 …

이럴 때 개발자는 경영자에게 꾸준히 주지 시켜야 한다. 대부분의 경영자는 소프트웨어에 대한 이해도가 낮아서 개발자가 왜 개발에 집중해야 하고 조직이 전문화 되어야 하는지 잘 모른다. 그러기 때문에 경영자가 알 수 있도록 설득해야 한다.
CTO가 있다면 이런 일은 벌어지지 않고 이런 일이 벌어진다고 해도 CTO가 다른 경영자를 설득하여 이를 해결해 줄 것이다.
그래서 개발자는 좋은 환경을 찾아가야 한다는 것이다. 연봉을 약간 많이 주더라도 제대로 일하고 성장할 수 없는 환경이라면 개발자에게 그리 좋은 직장은 아니다.   

즐겁게 개발하면서 개발자로 크게 성장하고 개발자로서 가치를 높이고 개발자로 은퇴하고 싶다면 개발자가 일할만한 직장에서 일해야 한다. 

우리나라에서는 이러한 회사를 찾는 것이 쉬운 일이 아니다. 물론 나의 미션 중의 하나가 좋은 소프트웨어를 만드는 것이고, 개발자가 일할만한 소프트웨어 회사가 점점 늘어날 것을 기대한다.

image by  SnoShuu

저작자 표시 비영리 변경 금지

전규현 소프트웨어이야기

Trackback Address: http://allofsoftware.net/trackback/244 관련글 쓰기
  1. 개발 입장에서는 영업은 할줄도 모르는게 어디서 주워들은것만 많아서 입만 놀린다고 무시할수밖에 없고
    영업으로는 주워들은건 많아서 눈만 높아지고, 자기가 죄송하다고 하기에는 자기가 만든게 아니니 개발에게 떠넘기고.. 그게 가장 근본적인 문제가 아닐까 싶어요.

  2. 구차니님 오랫만입니다.

    이 모든 것을 한마디로 얘기하면 전문성 부족입니다. 어떻게 보면 개발자도 포함해서 말입니다. ^^

  3. Blog Icon
    김정열

    좋은 글... 매번 잘 읽고 있습니다.
    공감...

  4. 이제 막 개발계에 입문한 풋내기 신입니다.
    경력자 로써의 개발실력을 쌓기전에 뭔가 올바른 개념을 잡아가면서
    공부할수 있게 되는것같아 좋은글들 써주셔서 감사하게 생각합니다.

    아무리 시간없어도 하루에 한번씩 1개의포스팅을 읽을 예정입니다.
    앞으로도 잘 부탁드리겠습니다^^ 감사합니다.

  5. 안녕하세요. UYEONG님

    읽는 속도에 따라잡히지 않으려면 저도 하루에 하나씩 포스트를 해야 하는 것 아닌지 모르겠습니다. ^^

  6. Blog Icon
    신성욱

    공감 지수 100 입니다.

  7. Blog Icon
    숙취

    잘읽었습니다. 제품을 기획하고, 경쟁사 제품들을 리서치하여 공유하고...프로토타이핑 하여 내부 시연하고, 설계하고...개발(코딩)하고.. 통합테스트 여러번을 거치고.. 고객에게 데모 준비하려 밤새고.. 직접 데모하고.. PoC, BMT있으면 준비하며 밤새고..직접 수행하고..제안서 작성 도와야 되고...제품 팔리면 고객사에 볼모로 잡혀가고...욕먹고...버그리포팅 직접 등록하고 직접 해결 및 close처리하고...프로젝트 오픈에 맞춰서 같이 밤새주고..시간날때 코딩하고..

    이런 생활 5년 넘었습니다. ㅎㅎㅎ

설계가 필요할까?

2011/12/22 21:09 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed




최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다.


그래서 설계에 대해서도 깔끔하게 정의를 해보자.
흔히 설계에 관한 다음과 같은 궁금증을 가지고 있다.
 

  1. SW를 개발하는데 설계는 과연 필요할까?
  2. 설계서는 작성할 필요가 있을까? SW는 설계서 없이 개발하는 것이 더 빠르지 않나?
  3. 설계는 어떤 기법을 이용하는 것이 좋을까?
  4. 설계툴은 UML을 꼭 이용해야 하나? 

일단, 설계를 하는 행위와 설계서를 작성하는 행위를 분리해서 생각하는 것이 좋다.


첫째, 우리는 설계서를 작성하든 하지 않든 "Hello world"를 제외하고는 설계 없이 개발하기 어렵다. 단지 단순한 것은 설계를 머리 속으로 할 뿐이다.

복잡하거나 여러 사람들이 서로 나눠서 개발을 해야 하는 경우는 머리 속으로만 설계를 하기란 거의 불가능하다. 천재라도 복잡한 시스템을 머리로 설계를 할 수 있지만 두뇌를 꺼내서 다른 사람에게 보여줄 수는 없는 일이다. 그래서 설계서를 작성하게 된다.

설계서 없이 개발이 가능한 경우는 극소수일 뿐이다.

그럼 주변에서 보는 설계서 없이 개발하는 수많은 프로젝트는 무엇인가? 

대충 머리 속으로 설계를 해서 코딩을 하면서 서로 맞춰가는 것이다. 이런 식으로라면 재작업하는 일이 여러번 발생하게 되어서 오히려 시간이 더 많이 걸린다. 재작업 문제만 있는 것이 아니다.

설계는 필요한 만큼 해야 하고 거의 대부분은 문서화를 해야 한다.

즉, "Hello world"보다 복잡하거나 다른 사람과 나눠서 일을 하거나 다른 시스템과 인터페이스가 있을 경우는 설계를 적어야 한다.

설계 없이 만들어보려고 하는 것은 Software밖에 없을 것이다. 집, 빌딩, 전자부품, 애들 장난감 모두 설계가 있다. 



둘째, 설계는 어디에 적히는 것일까?

많은 설계는 소스코드와 중복이 되게 된다. 소프트웨어를 개발하는데 있어서 중복은 2배가 아니라 10배의 문제를 야기한다.  따라서 최대한 중복은 피해야 한다.

일단, 설계의 시작 부분은 스펙(SRS)에 적히게 된다. 시스템의 조망과 구조는 스펙의 가장 중요한 부분 중 하나이다. 이렇게 스펙에 설계를 적기 시작하면 스펙과 설계의 경계가 모호해지게 된다. 스펙과 설계의 경계는 따로 정해져 있는 것이 아니고 상황에 맞게 판단하면 된다.

라이브러리르 개발하는냐,  웹서비스를 개발하느냐,  게임을 개발하느냐에 따라서 그 경계는 달라질 수 있다.

보통의 경의 스펙에는 상위 설계 언저리 까지 적히는데 많은 프로젝트에서 설계는 이 정도만 적혀도 충분하다.

설계가 충분하지 아닌지 판단은 이 설계를 가지고 다른 개발자들이 나눠서 각자 개발을 할 수 있는지 생각해보면 된다. 그렇다면 스펙에도 어느 정도로 적히는지를 상상할 수 있을 것이다.

따라서 시스템의 크다고 하더라도 설계서가 별도로 없이 UI만 있어도 개발이 가능 Web 등의 시스템은 스펙에 적히는 정도만 가지고도 개발이 가능하다.

이것으로도 부족하면 별도의 설계 문서를 만들기도 한다. 개발자가 수십명이상 참여하는 프로젝트에서는 대부분 별도의 설계서가 따로 있어야 할 만큼 시스템이 크다.  그런 경우는 설계서를 따로 만드는 것이 좋다.


셋째, 설계는 어떻게 해야 하는가? 무엇을 고려해야 하고 무엇을 적어야 하는가?

설계를 하는 방법에 대해서 고민을 하는 개발자는 매우 많다. 막상 회사에서 설계서를 만들라고 하면 막막하고 많은 경우 코딩을 다 하고 형식적으로 만드는 경우가 많다.

이런 경우는 설계도 제대로 한 것이 아니고 설계서도 엉망이다. 거의 쓸모 없는 문서를 시간을 더 들여서 만든 것이다. 나중에 유지보수에 필요하다고 하는데 유지보수에서 가장 많이 필요한 것은 소스코드와 스펙이다.

설계는 해당 프로젝트를 제대로 짧은 시간 안에 끝내기 위해서 하는 것이다. 또한 잘 된 설계는 미래에 발생할 여러가지 환경을 반영해야 한다. 이렇게 작성된 설계서라야 시스템과 일치를 하며 유지보수 시에도 유용하다.

설계의 기준이 되는 것은 스펙이다. 즉, 스펙이 제대로 적히지 않으면 좋은 설계가 나올 수 없다.

스펙이 없거나 기껏해야 기능명세만 적었다면, 설계는 아무리 잘해도 현재의 요구 기능이 동작하는 것에만 머물 것이다.

이 부분이 가장 중요하다. 수많은 회사들이 여기서 다 망쳐서 지금 그 고생들을 하고 있는 것이다.
스펙에 기능명세 뿐만 아니라 미래의 비즈니스 전략과 비기능 요구사항들이 모두 적혀야 있고 이를 설계에 반영해야 한다.


스펙이 이러한 내용들이 누락이 되어 있으면 설계가 어떻게 될지 상상해보라.

  • 지금은 고객이 10개 회사인데 5년 안에 1,000개의 고객사를 확보할 것이다.
  • 지금은 국내 판매를 대상으로 하는데 1년 후 부터는 세계 200개 회사를 대상으로 마케팅을 할 것이다.
  • 현재의 시스템은 내년에 회사의 다른 시스템들과 통합하는 작업이 진행 될 것이다.
  • 현재는 C/S 구조인데 2년 안에 Web을 지원해야 한다.
  • 현재는 Windows만 지원하는데 1년 안에 MacOS, 2년 안에 iPhone과 Android 폰을 지원해야 한다.
  • 지금은 모델이 3개지만 내년까지 100개의 모델이 5년 안에 5,000개의 모델이 생산될 것으로 예상된다. (사업이 잘 될 경우)
  • 지금은 카메라 모듈을 한 가지만 지원하지만 5년 안에 100개 이상의 카메라 모듈을 지원해야 할 가능성이 80%이다.
  • 현재 만든 Framework로 2년 안에 사내의 모든 TV의 Firmware를 교체할 예정이다.

위 예는 실제 현장에서 발생할 수 있는 수백만개 경우 중 몇 개일 뿐이다.

이러한 내용들이 설계에 적절히 고려되지 않는다면 미래에 큰 댓가를 치루게 된다. 이러한 것을 설게에 잘 반영하도록 설계를 하는 사람들을 Architect라고 부른다.

이런 것을 고려하지 않고 마구 어질러 놓고 인력만 많이 투입해서 엄청 비효율적으로 일을 하고 있으면 그 원인과 방법도 모른체 계속 똑같은 시행착오를 계속 반복할 가능성이 99%이다.


넷째, 특별한 툴을 이용하는 것이 좋은가?

 나는 설계를 위해서 특별한 툴이나 방법론을 선호하지 않는다. 하지만 툴가 방법론을 팔아먹는 사람들이 만병통치약처럼 선전을 한다.

좋은 워드프로세스를 쓴다고 좋은 소설이 안나오고 비싼 붓 쓴다고 그림 잘 그리는 것이 아니듯이 설계를 가장 잘 표현할 수 있는 툴을 알아서 쓰면 된다. 혼자만 이상한 것을 써서 다른 동료들이 편집하지 못하게 해서도 안된다.

설계의 핵심은 컴포넌트와 인터페이스를 적절히 나누고 표현하는 것이기 때문에 이것을 그릴 수 있으면 된다. 그냥 워드프로세스로 정리를 하는 경우가 많다.

하지만 설계를 하는 중간 과정에는 툴을 가지고 깔끔하게 정리를 하는 것은 시간 낭비이다. 설계가 끝날 때까지 설계는 전체를 뒤엎는 과정을 수차례 겪으므로 정리를 해 놓은 낭비이다.  큰 종이나 칠판에 적고 지우고를 반복하는 것이 좋다. 그렇게 거의 완성이 되면 옮겨 적으면 된다.

심지어는 사진을 찍어서 이미지를 문서에 첨부하기도 한다. 이런 경우는 나중에 편집이 안되므로 적절히 사용해야 한다.

그 외에 필요한 것은 설계자가 적절히 판단해서 시스템을 표현할 수 있는 그림이나 다이어그램을 그리거나 글로 적기도 한다. 여기서 창의성을 발휘해야지 규칙을 정해 놓고 따라하면 오히려 비효율적으로 변하게 된다.

디자인패턴 하나 배워서 모든 곳에 써먹는 것은 태권도 정권지르기 하나 배워서 그걸로만 싸우는 격이다. 분명히 도움은 되지만 상황에 맞게 적절한 방법을 창의적으로 생각해 내는 것이 가장 좋다. 그러기 위해서는 먼저 많이 알아야 하고 경험도 많아야 한다.

하위 설계는 소스코드와 중복이 되므로 그냥 소스코드로 작성하는 것이 좋다. Doxygen이나 JavaDoc을 이용하면 소스코드에서 필요한 설계 문서를 거꾸로 만들어 낼 수 있다.

 결론

설계는 필요한 만큼 적절하게 꼭 해야 한다.

하지만 흔히들 문서화의 부담 때문에 아예 안하거나 적는 방법을 몰라서 너무 많이 적는다.
설계문서는 꼭 필요한 만큼만 적절하게 적어야 한다. 가장 어려운 말이지만 이 이상으로 표현하기는 어렵다.

설계서는 한 페이지가 될 수도 있고 수천 페이지가 될 수도 있다. 스펙이 이를 결정한다.

만약 제대로 된 스펙이 없다면 차라리 스펙을 제대로 적는데 먼저 신경을 써야 한다. 설계는 스펙 다음이다.


image by John E. Lester

 
저작자 표시 비영리 변경 금지

'프로젝트 > 설계' 카테고리의 다른 글

설계가 필요할까?  (4) 2011/12/22
Software Architect를 양성하는 나라  (8) 2011/12/19
UML전문가가 설계전문가?  (6) 2009/04/15
코더(Coder)의 비애  (6) 2008/11/24

전규현 프로젝트/설계

Trackback Address: http://allofsoftware.net/trackback/250 관련글 쓰기
  1. Blog Icon
    Realbj

    좋은글 잘 읽었습니다...

    기본을 중시한

    보양식 같은 글이네요 ^^

  2. 안녕하세요. Realbj님

    감사합니다.

  3. Blog Icon

    비밀댓글입니다

  4. 감사합니다.

Software Architect를 양성하는 나라

2011/12/19 02:21 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed




우리나라에서는 종종 SW Architect를 양성한다고 한다. 
정부에서 막대한 예산이 지원도 되며 SW Architect를 양성하는 학원도 생기고 야단법석이다.

그럼 도대체 SW Architect는 무엇인가?

 SW Architect 교육을 받아야 Archtect인가? 설계 방법론을 알아야 하는가? 설계 툴을 다룰 수 있어야 하는가?
이런 접근은 SW Architect에 대한 왜곡된 시각을 유발할 수 있다.

SW Architect는 "고참 개발자"이다. 외국에서 SW Architect 양성 학원이 있나 물어보라. 개발자들이 스스로 SW Architect라고 강조하는지 알아봐라. 

그냥
Software를 오래 개발하면서 경험이 쌓이고 고참 개발자가 되면 그냥 SW Architect인 것이다.

그런데 왜 우리나라는 SW Architect에 대해서 열을 올리고 있는 것일까?

아마, 많은 고참 개발자들이 일반적인 기준의 SW Architect에 미치지 못해서 쓸만한 사람이 부족하기 때문일 것이다. 물론, 그 원인이 개발자에게 있다고 전적으로 말할 수는 없다. 환경적인 요소가 크고 그런 환경에서 자란 개발자들은 피해자라고 볼 수도 있다.

그럼, SW Architect라고 말할 수 있으려면 어떤 일을 해야 할까?

SW Architect는 한마디로 Software 설계를 할 줄 아는 사람이다. 물론 설계만 하는 것이 아니고 코딩도 한다. 때로는 스펙도 적는다.

SW Architect라고 불리려면 설계를 제대로 해야 한다. 제대로 된 설계는 현재 뿐만 아니라 미래에 발생할 수많은 요구사항을 유기적으로 고려하여 가장 합리적인 구조를 만드는 것이다.
그리고 설계를 머리 속으로만 하는 것이 아니고
문서로 만들 수 있어야 한다. 이렇게 작성된 설계 산출물을 가지고 설계자 본인이 아닌 다른 사람들이 코딩을 할 수 있어야 한다.

내가 설계한 것을 내가 코딩 할 밖에 없다면 빌딩을 설계한 사람이 벽돌도 쌓는 격이다. 비용적으로 비효율적일 뿐만 아니라 벽돌은 더 잘 쌓는 사람에게 맡기는 것이 낫다.

설계를 잘하려면 우선 분석이 잘되어야 한다. 즉 SRS가 잘 작성되어야 한다. 분석이 대충 되는 환경에서는 좋은 설계가 나올 수도 없다. 또한 우리나라 대부분의 고참 개발자들은 설계서를 잘 작성해서 다른 개발자들이 개발할 수 있도록 넘기는데 아주 취약한다. 그런 식으로 개발을 안 해봤기 때문에 방법을 잘 모른다.

수많은 설계 방법론이나 툴이 이를 해결해주지 않는다. 설계는 형식에 구애받지 않고 가장 효과적으로 기술하는 것이 좋다. 이러한 역량은 따로 배울 수 있는 것이 아니고 좋은 환경에서 경험과 협업에서 저절로 익히는 것이다.

그럼에도 불구하고 많은 SW Architect 교육이 툴과 방법론이 주류를 이루는 것은 이것 외에는 마땅히 전파할 것이 없기 때문이다.

즉, 단시간 SW Architect 교육을 받는다고 설계 역량이 향상되는 것은 아니다. 지식을 아는 것은 도움이 될 수 있지만, 오히려 위험한 경우가 더 많다.

경험과 실력에 걸맞지 않게 지식들이 들어오면 현실성의 판단이 흐려져서 무리한 적용으로 오히려 낭패를 볼 수도 있다. SW Architecture는 적절해야 하는데 그 적절함을 판단하지 못하는 것이다.

정부에서 SW Architect를 양성하는 것 자체를 반대하지 않는다. 그렇게 효율적이지는 않지만 안하는 것보다는 나을 것이다. 하지만 그런다고 단기적으로 많은 SW Architect가 생겨나는 것은 아니다. 그러니 큰 기대는 하지 말자.

본인이 SW Architect가 되고 싶은 사람은 이런 교육에 기웃거리는 것보다는 스펙을 잘 쓰고, 설계를 해서 다른 팀원들에게 개발을 맡겨보는 일에 좀 더 집중하는 것이 좋다. 이것이 처음부터 잘 될리는 만무하다. 하지만 경험을 여러차례 해보면 점점 나아질 것이다. 

그때서야 외부에서 접하는 여러 지식들이 도움이 될 것이다.

image by Ezu
 
저작자 표시 비영리 변경 금지

'프로젝트 > 설계' 카테고리의 다른 글

설계가 필요할까?  (4) 2011/12/22
Software Architect를 양성하는 나라  (8) 2011/12/19
UML전문가가 설계전문가?  (6) 2009/04/15
코더(Coder)의 비애  (6) 2008/11/24

전규현 프로젝트/설계

Trackback Address: http://allofsoftware.net/trackback/248 관련글 쓰기
  1. Blog Icon
    hoony

    좋은 말씀이시네요.

    사내에서 역량강화 혁신이랍시고 추진하는 과제에서...
    1년차 사원을 SA과정에 내 몰고서는 실적 달성.이라고 써놓은거 보고........

    휴..

    사장님이라고 SA가 교육으로 만들어지는게 아닌건 아실텐데 말이죠.

  2. 안녕하세요. hoony님

    사장님이 잘 모르실 가능성이 99%입니다. ^^

  3. 잉여가 없어서 그런게 아닐까요? 여유가 있다면 좀 더 좋은, 좀 더 발전적인 결과물이 나올텐데요. ^^

  4. 안녕하세요. 미물님

    환경과 저변이 척박하기 하죠.

  5. Blog Icon
    Jake Kim

    왜들 이렇게 뭐든지 인위적으로 만들려고 하는지 모르겠습니다. 결국 내용은 보지 않고 겉모습만 보고 따라가려고 하는데에 있지 않나 싶네요.

  6. Jake님 오랫만입니다.

    CMMI인증이 대표적인 사례중 하나 아닐까요?

  7. Blog Icon
    똥꽃

    줄기차게 SRS의 중요성을 말씀하시네요. 그리고 SRS의 전파는 하루 아침에 이루어지지 않는다. 지속적인 자기혁신이 필요하다. 일부 학교에서 SRS 쓰기과정이 있다고 하는데...

    SRS를 잘 쓰는 법 좀 가르켜 주세요.

    어떤 문제를 내고 거기에 SRS양식에 맞춰서 보내봐라...그러면 거기에 첨삭을 한다든지 등의....

    답답한 마음에 적어봤습니다.

  8. 안녕하세요 똥꽃님

    SRS 작성은 소프트웨어를 개발하는데 가장 중요하면서 가장 어려운 일입니다.

    피아노 잘치는 법, 골프 잘치는 법을 한마디로 가르쳐 줄 수 없듯이, SRS도 마찬가지 입니다.

    SRS는 예제가 아닌 실제 프로젝트에서 작성을 해봐야 그 경험이 도움이 됩니다. 가상 프로젝트는 별 도움이 안됩니다. 실제 프로젝트에서 코치가 리뷰를 해주는 것은 도움이 많이 됩니다.
    SRS Template를 이용하는 것은 도움이 되지만 Template만 가지고는 절대로 제대로 작성하지 못합니다.

    KAIST 소프트웨어 전문가 과정에서 Requirement Engineering 과목에서 SRS 작성법을 가르쳐 줍니다. 국내에서는 거의 유일할 겁니다. 해외에서도 과정은 찾아보기 쉽지 않습니다. 교육과정으로 배우기 어렵기 때문입니다.

    점점 더 어렵게 느껴지나요? ^^

우리에게 지금 필요한 것은? 바로 이것

2011/12/02 06:49 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed




우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은
"기초 체력"이다.

히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다.
그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내놔도 뒤지지 않을만큼 뛰어나지만 골결정력 등 섬세한 고급 기술들이 부족하다고 생각했었다.

하지만 히딩크는 이를 전면 부정하고 고등학교 축구팀처럼 기초 체력 훈련에 집중했다. 주변의 반대가 심했지만 강행했다.
그리고 월드컵에서 그 결과를 보았다. 경기 후반 다른 나라 선수들이 지쳤을 때 우리 선수들은 한발 더 뛸 수 있었고 승리로 이어졌다.

우리나라 개발자들은 개인기들은 뛰어나다. 즉, 코딩을 잘하는 개발자도 많고 온갖 지식도 많이 안다.
솔직히 이 정도로 많이 아는 개발자들은 전세계적으로 찾아보기 어렵다. 그럼에도 세계적인 소프트웨어 회사가 우리나라에 없고, 세계적인 제품을 찾아보기 어려운 것은 기초 체력이 부족하기 때문이다.

개발자들이 많이 아는 지식은 혼자서 배우고 익힐 수 있는 것들이다. 이것은 노력하는 개발자라면 누구나 다 잘 한다.
하지만 기초 체력은 혼자서는 절~대로 배울 수 없는 것들이다. 대부분 잘 갖춰진 개발문화를 가진 SW회사에서 몇년씩 일하면서 자연스럽게 배울 수 있는 것들이다. 그렇게 쌓은 기초 체력을 갖춘 개발자들이 버글버글 해야 그들이 뭉쳐서 좋은 소프트웨어도 만들고 그중에서 세계적인 소프트웨어도 나올 수 있다.

그런 좋은 환경에서 배울 수 있는 기초 체력코딩도 아니고 Domain 지식도 아니다.
아래와 같은 것들이다.
  • 소프트웨어 개발에 있어서의 개방의 문화
  • 리뷰 문화
  • 공유 문화
  • 협업 문화
  • 신뢰의 문화
  • 효율적인 개발 프로세스
  • 소스코드 관리 기법
  • 이슈 관리 기법
  • 빌드/릴리즈 기법
  • 테스트
이런 것들이 몸에 베어 있어야 한다. 몸에 베이지 않고 지식으로만 알고 있는 것은 막상 시행하려고 할 때 제대로 실행하기 어렵다. 엉뚱한 방향으로 흘러가서 이상하게 되어 버린다.

또 기초 체력에 해당하는 것들은 비싼 툴을 쓰고 정교한 세계 최고의 방법론, 프로세스를 도입한다고 해서 나아지지 않는다. 오히려 방해가 되는 경우가 많다.  그런 비싼 툴과 정교한 프로세스를 그것을 필요로 하는 곳이 따로 있는데 맞지도 않는 것을 쓰게 되면 반감만 커지게 된다.

툴은 꼭 필요하지만 환경에 맞게 필요한 툴과 적절한 프로세스가 필요한 것이다. 그 기반하에서 문화가 꾸준히 쌓이게 된다. 

이런 기초 체력이 뒷받침 되어야 다음과 같은 고급 역량이 생기기 마련이다.
  • 분석 역량
  • 설계 역량
  • 기술 전략 수립
단어만 놓고 보면 우리도 다 하는데라고 생각할지 모른다.
이는 태권도 10급이 태권도 9단에게 나도 태권도 할 줄 안다고 하는 것과 비슷하다.
Global 하게 경쟁 좀 하려면 4,5단은 되어야 하는데 우리나라에서 유단자 찾기 어려운 이유가 기초 체력을 먼저 갖추기 어려운 환경에서 일하기 때문에 이런 고급 기술은 닦을 시간도 없고 방법도 모르기 때문이다.

그래서 내가 중요하게 생각하는 것이 개발 환경을 먼저 바꿔 놓는 것이다.
기본적으로 이슈관리시스템, 소스코드관리시스템만 제대로 사용해도 반쯤은 바뀐 것이다.

이런 시스템들을 쓰면 우리가 눈치 채지 못하지만 여러가지 원칙, 프로세스를 저절로 배우게 된다. 수십년간 수많은 SW회사들의 성공하는 방법이 녹아 있는 것이 그런 시스템, 툴 들이다.

따라서 이들을 원칙 그대로 사용만 해도 많은 것을 얻게 된다. 기존의 방법과 다르다고 툴을 무시하고 또는 이상하게 변형하면 99.9% 잘못된 방향으로 가고 있는 것이다.

그리고 빌드, 테스트, 리뷰 등등을 하나씩 갖춰나가면 어느덧 꽤 효율적인 조직의 모습을 갖출 것이다.

이때 나타나는 조직의 모습은 다음과 같다.
  • 회사의 모든 개발 이슈가 투명하게 Open 된다.
  • 모든 업무의 커뮤니케이션이 원활하며 이런 것에 시간 낭비 하지 않는다.
  • 모든 소스코드는 공개가 되어 있고, 협업이 원할하다.
  • 숨어서 개발하는 개발자는 더이상 존재하지 않는다.
  • 경영자와 관리자는 개발 진행 상황을 한눈에 파악하고, 각 개발자들의 업무 진행 상황을 쉽게 파악한다.
대부분은 이쯤에서 만족할 수 있을지도 모르겠다.
하지만 여기까지는 진짜 "기초 체력"이다.

국내 대회에서는 꽤 상위권에 오를 수 있다. 하지만 월드컵에 나가면 한 골 넣기도 어렵다.
이제 "고급 역량"이 필요할 때다.

분석/설계/기술전략 등의 "고급 역량"은 단기간에 배울 수도 없다. 그렇다고 혼자 방법과 길을 알아서 익힐 수도 없다. 그렇게는 너무나 오래 걸려서 은퇴할 때가 될 것이다.
"고급 역량"은 이미 "고급 역량"을 갖춘 선배, 동료들과 진짜 프로젝트를 수행하면서 몸으로 익히는 것이다.
어느정도 방법과 길을 아는데는 몇개월 안걸리지만 진짜 역량이 높아지는데는 5년, 10년이 걸리고 20년이 지나면 또 역량이 올라간다.

우리나라 많은 개발자들이 관리 쪽을 기웃거리다가 또 유지보수에 시달리다가 20년 쯤 지나면 이도 저도 아닌 상태와는 많이 다르다.

기초 체력을 익히는 첫걸음은 기초 체력이 부족하다는 것을
인정하는 것이다. 스스로를 인정하지 않으면 바뀔 수 없다. 이렇게 환경부터 하나씩 고쳐나가야 한다. 

Image by doctano
저작자 표시 비영리 변경 금지

전규현 소프트웨어이야기

Trackback Address: http://allofsoftware.net/trackback/247 관련글 쓰기
  1. Blog Icon
    yanu27

    말씀하신 저런 회사를 정말 찾고 있고, 들어가고 싶은데 안 보이네요.
    또 저렇게 환경을 만들려고 노력하는 회사 찾기도 쉽지 않고요.
    저런 노력하는 사람이나 회사 정말 알고 싶습니다.

  2. Blog Icon
    아리수

    저희회사요.ㅎㅎ
    소스코드나 이슈관리는 하고 있는데
    리뷰에 대해서는 사람들이 아직 잘 못받아들이네요.
    "나를 못믿냐?" 뭐 그런 생각들이 있는듯...

  3. 전 좀 답답한게, 어휘력 때문에 고생합니다. 엣말에 콩떡처럼 얘기해도 찰떡처럼 알아 듣는다고... 그게 소통이 잘되고, 죽이 잘 맞고, 팀웍이 좋은 것처럼 착각하는게 일을 더 어렵게 만듭니다.
    말이나 글을 좀 더 정확하게, 의사전달을 명확하게 하는 노력을 계속 해 나가야 하는데...
    "개발자는 코드로 말한다" 라는 명제 때문인지, 의사전달의 정확성에 대한 노력은 별로 하지 않는 것 같아, 아쉽습니다.

  4. 안녕하세요. 디밥님

    정확한 의사전달은 가장 어려운 것 중 하나입니다. 그 어려운 정도는 상상을 초월합니다.

    그래서 스펙을 쓰는 것이 가장 어려운 일입니다.

  5. Blog Icon
    조인중

    기초 체력이 중요하다는 점에는 절대적으로 공감합니다.
    하지만 우리나라 소프트웨어 생태계가 심하게 오염된 탓에,
    개발자들이 그런 기초 체력을 쌓을 기회가 없다는 게 문제라고 생각합니다.

    경영 환경이 열악한 중소/벤처 기업들은 경력이 없는 개발자를 채용하여 문화를 만들고 기초 체력을 키워 줄 "회사의 체력"이 없습니다. 그리고 대기업들은 중소기업 빨아먹기에 여념이 없어서 개발자를 키울 생각조차 하지 않구요.

    결국, 지금 살아남은 소프트웨어 회사들이 그런 일을 해줘야 하는데,
    그런 회사들도 정말 쓸만한 고급 개발자가 별로 없어서, 결국 역량이 없는 경우가 대부분입니다.

    참 답답하지만, 여기서 할 수 있는 말은 하나밖에 없겠네요. (김형태 님이 하신 말씀입니다.)
    "남 탓, 시대 탓, 환경 탓하는 것만큼 구제불능의 바_보는 없습니다."

    결국 내가 그런 사람이 되어야 하는데, 그게 참 쉽지 않네요. :-)

  6. 안녕하세요. 조인중님 (내 후배 조인중인가?)

    그 책임의 대부분은 회사에 있죠. 개발자들은 피해자죠. 심한경우 성장의 기회는 없이 피나 빨리는 거죠. ^^

프로토타입을 재활용하면 될까? 안될까?

2011/11/14 06:20 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다.

2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란?

소프트웨어공학의 목적은 가장 적은 비용으로 가장 빠른 시간에 Software를 만들어내는 것이다.
여기에 부합되면 옳은 방법인 것이다. 하지만 우물 안에서 자신의 방법이 가장 좋은 방법이라고 우기는 것은 미숙함일 뿐이다.

여러가지 의견이 있었지만 모두 옳고 그름으로 구분 지을 수는 없다. 여러 답변들을 맞다 틀리다 얘기를 할 수 없으므로 좀더 원칙에 치중해서 얘기를 해보겠다.

필자의 의견은 프로토타입은 만들어 보고 버리는 것이라고 했다. 또한 버리는 코드라고 생각하고 만들어야 하는 것이다. 프로토타입을 버리는 것이 프로젝트를 가장 빨리 끝낼 수 있는 방법이기 때문이다.

그 이유는 다음과 같은 것들이 있다.
  • 프로토타입의 목적은 가장 빠른 시간내에 Feaserbility study(실현가능성 검증)을 하는 것이다. 보통 실제 프로젝트에 반영될 때 제대로 적히는 소스코드 양의 20%정도의 코드만 적는다. 
  • 보통 에러처리와 약간의 버그는 무시한다.
  • 검증된 것은 스펙에 기능으로 포함될 수 있고 이렇게 작성된 스펙을 외주를 줘서 개발할 수도 있고 회사의 다른 개발자들이 설계, 구현을 할 수도 있다.
  • 이렇게 검증된 기능들은 모두 제품에 반영되는 것이 아니고 많은 기능은 최종 스펙에서 제외 될 수가 있다.
  • 프로토타입은 C언어로 했지만 실제 개발은 Java로 할 수도 있다. 
따라서 재사용 가능하도록 만든다면 낭비가 될 수 있다.

보통 개발자들은 자신이 정성들여서 만들어 놓은 소스코들 버리기 싫어한다. 그래서 어떻게든 소스코드를 재활용해보고자 노력하는 것이 보통이다. 따라서 제품의 비전이나 가치와는 상관없이 자신이 작성해 놓은 코드의 기능을 살려보고자 마케팅의 의견과 반대되게 우겨서 제품에 기능을 포함하기도 한다.

제품의 스펙은 개발자가 일방적으로 정하는 것이 아니고 여러 부서가 같이 정하는 것이지만 특히 개발자보다는 마케팅의 의견이 주가 되는 것이다.

그런데 개발자가 미리 잘 작성해 놓은 코드가 이런 결정에 방해가 되는 경우가 많고 대부분의 소프트웨어 회사의 마케팅은 별 생각이 없기 때문에 그냥 따라가는 경우가 허다하다. 

그럼 프로토타입을 재사용한다는 생각을 하고 만들게 되는 상황은 어떠한가?
이러한 가정들을 사실로 생각하고 개발을 하는 것이다.
  • 내가 스펙을 쓰고 설계를 하고 구현까지 모두 나 혼자 다한다.
  • 프로토타입을 해본 것들은 제품에 모두 포함될 기능들이다.
  • 프로토타입 해본 그 기능 그대로 제품에 반영될 것이다.
  • 프로토타입을 해본 개발 언어 그대로 제품을 개발할 것이다.
  • 프로토타입을 하기 전에 이미 아키텍처도 다 정해서 재 사용하는데 전혀 문제가 안된다.
 사실 아주 작은 제품이나 소수의 팀이 개발하는 제품이 아니라면 위의 모든 것을 가정하기는 대단히 어렵다.

스펙을 작성하는 과정에서 수많이 기능이 추가되고 제거되며 무슨 개발 언어로 개발을 할 것인지 보통 스펙을 작성할 때는 정하지도 않는다. 

어떠한 프로토타입은 개발언어를 정해야 하는 경우도 있고, 라이브러리도 정해야 하는 경우도 있다. 이런 경우라면 프로젝트에 또 제약사항이 생긴 것이다. 물론 프로젝트에 따라서는 스펙단계부터 개발언어와 특정 프레임워크를 사용하도록 정하는 경우도 있다.

스펙을 제대로 작성해야 하는 이유가 이러한 가능성이 있는 수많은 요소들과 제약사항, 가정들을 모아놓고 스펙을 정하는 것이다. 이런 것들을 정하지도 않고 코딩부터 시작하는 것이 흔히 개발하는 방식이다.

이런 프로젝트는 개발자 의지대로 그냥 개발이 되던가 나중에 뒤엎는라고 비용가 시간을 낭비하던가 제품이 점점 뒤죽박죽이 되어서 못써먹게 되는 경우가 많다.

프로토타입을 재활용할지 말지 하나의 이슈만 보면 원칙은 재활용하지 않는 것이 맞다.
하지만 위에서 말한 것들을 모두 알고 스펙도 제대로 쓰고 설계도 제대로 하고 개발을 하는데 재활용하는 것이 옳다고 생각한다면 프로토타입재사용도 틀린 방법은 아니다.

단, 적은 경험과 미숙함을 기반으로 기존에 하던 방식을 그냥 따라하는 것은 주먹구구의 연장선이 될 수 있다.

Image by ッ Zach Hoeken ッ


 
저작자 표시 비영리 변경 금지

전규현 프로젝트/요구사항분석

Trackback Address: http://allofsoftware.net/trackback/246 관련글 쓰기
  1. 저는 프로토타입은 2가지 경우에 사용한다고 생각합니다.

    1.고객과의 의사소통용(UI가 주가되는 프로토타입)
    2.기술검증용

    1번의 경우야 말할것도 없이 요구분석이 끝나면 버려야 하는 것이죠.
    2번의 경우는 기술검증이 실패하면 어차피 버려질 코드입니다.
    물론 성공했을때에 코드를 정리하여야 하지만 프로토타입을 만들때 발생하는 실패리스크에 비하면 그렇다하게 큰 리스크라고 보기는 힘든것 같습니다.

    물론 프로토타입을 만들면서 발생한 이슈나 기술에 대한 이해가 떨어지는 상태로 만든부분은 주석으로 표시를 해두는정도의 정성은 있어야 한다고 생각합니다.

    이 포스트에서 지적하신대로 자신의 코드에 저도 집착 합니다 ㅎㅎ;;그래서 테스트는 했지만 스팩아웃된경우 따로 정리해놨다가 블로그에 올리곤 하죠.
    최소한 다음번에 같은 검증을 하지 않아도 되게 정리해두는것도 좋은 생각인것 같습니다.

  2. 안녕하세요. 당근천국님

    여기서 UI프로토타입은 전혀 언급하지 않았습니다. ^^ 별이슈가 없거든요.

    현재 프로젝트의 특성이나 조직의 상황을 고려하여 가장 적절한 방법을 택하신 것으로 이해가 됩니다. ^^

  3. Blog Icon
    아무것도모름

    좋은 글 잘 보았습니다. 저도 SW 분야에서 근무한지가 두자리 숫자를 좀 넘어가면서
    쓰신 내용에 대해서 감성적으로, 이성적으로 공감을 하는데요....

    국내 현실은 너무나 무지한 것 같습니다. 모든 프로젝트가 그렇지만 일정, 리소스가 부족한데
    비해 '우아한' 행위 - 불필요한 임원보고, 언론플레이용 데몬스트레이션 등 - 에다가 정작 개발하고자
    하는 서비스/제품은 말도 안되고 유저 입장에서는 뭥미할만한 것인데 기획/UI는 수시로 변경하면서
    실제 개발에 드는 시간은 쉽게 잡아먹고 마는 현실이....--;;

    프로토타입을 대함에 있어서 고객은 '프로토타입'과 '실제 제품'의 차이를 인지하지 못하는 경우가
    허다하다고 봅니다. 저도 수없이 많이 겪어봐서 사실...좀 회의적이긴 한데요...프로토타입을 통한
    기술 혹은 시제품 정도의 검증으로 인식하게 하려면 어떤 방법이 있을까요?

    일하면서 성격이 시니컬하게 변하는 걸 느끼고 있어서....희망적인 뭔가가 있기를 기대하면서
    살고 있습니다.

    항상 좋은 글 감사합니다.

  4. 안녕하세요.

    그래서 소프트웨어를 개발하는데 있어서 가장 어렵고도 중요한 것이 스펙을 쓰는 겁니다. 즉 분석이 어렵다는 얘기죠.

    UI프로토타입의 경우 그럴듯한 화면을 보여주면 개발이 거의 된 것으로 착각하는 경우가 있습니다. 그래서 몇몇 UI프로토타입 툴들은 진짜 프로토타입처럼 찌글찌글하게 보여주는 것들이 있습니다. 딱 단순히 프로토타입인것을 알게 됩니다.

    마인드를 바꿔야 하는데 다른 사람의 생각을 바꾸는 것이 쉽지는 않죠.

    제가 쓴 "소프트웨어 개발의 모든 것"이라는 책을 사서 읽어보라고 해보세요. 여기에 관련된 거의 모든 내용이 이해하기 쉽게 정리되어 있습니다.

  5. Blog Icon
    MdadKight

    버리지 못 할 것 같으면 실용주의 프로그래머에 나왔던 예광탄 방식을 활용해볼 수도 있습니다.

프로토타입이란?

2011/11/03 03:16 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



프로토타입 (경제/경영)

양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을 취할 경우 양자간에 서로 다른 이해를 가져올 수 있으므로 프로토타입이라는 의사소통도구를 만들자는 것이다. 프로토타이핑은 그 목적에 따라 여러가지 형태가 있다.

by 다음 백과사전 (http://100.daum.net)

소프트웨어 개발을 할 때 프로토타입은 여러 용도로 사용된다. 특히 고객과 스펙을 의논할 때 고객의 이해를 돕기 위해서 UI프로토타입을 만든다.

이외에도 기술적인 검증을 위해서 프로토타입을 만들어 보는 경우도 있다.
스펙을 작성하다보면 이것이 가능할지 불가능할지 잘 모른 경우가 있다. 스펙이 이렇게 불분명한 부분이 가득하다면 십중팔구 프로젝트는 산으로 갈 것이다.

그래서 스펙을 쓰면서 나중에 코딩에 들어가기 전에 미리 한번 만들어보는 것이다. 이렇게 만드는 프로토타입은 되는지 안되는지만 검증을 하는 것이므로 최대한 간단하게 만든다.

회사의 코딩 규칙을 따르지도 않고
에러 처리도 제대로 하지 않고
주석도 달 필요가 없다.

제대로 개발하려면 1주일 이상 걸릴 것도 몇시간에 걸쳐서 되는지만 확인해보는 것이다.
그렇기 때문에 이때 작성한 소스코드는 버리는 것이다. 절대 재활용하면 안된다. 규칙도 따르지 않고 에러처리도 안되고 주석도 없는 코드를 재활용하는 것은 대단히 불안한 일이다.

이렇게 검증을 해나가면서 스펙을 적으면 프로젝트가 계획된 시간에 끝날 가능성이 점점 높아지게 된다.

그렇다고 모든 내용을 다 검증해가면서 스펙을 적을 수는 없다. 어떤 항목은 된다는 감을 믿고 그냥 적어야 할 때도 있다. 모든 것을 다 검증하면 비용과 시간이 너무 많이 들기 때문이다. 따라서 검증할 것을 적당히 조율하면서 어느정도 Risk도 감수를 하면서 프로젝트를 진행해야 한다. 이때 발생한 Risk는 별도의 Risk 관리를 통해서 제어를 해야 한다.

프로젝트는 "해봤더니 안되더라"가 아니다.
그렇다고 모든 것을 검증하면서 할 수는 더욱 없다.
적절한 프로토타입을 통한 검증과 적절한 Risk관리를 병행하는 것이 가장 효율적이다.

Image by Randomskk
저작자 표시 비영리 변경 금지

전규현 프로젝트/요구사항분석

Trackback Address: http://allofsoftware.net/trackback/241 관련글 쓰기
  1. 프로토 타입 코드는 가능성을 타진하는 것이니 품질에서는 상관없이, 오로지 가능성 타진에 초점을 둬야 하고, 그 때 쓴 코드는 절대로 재활용해서는 안되고, 폐기 처분 해야 한다!!!
    항상 이 말을 하는데도, 담당자들은 뭐가 아쉬운지, 재활용하려고 하네요... Copy & Paste 신공이 있는데 왜 못 쓰게 하냐고...

    "모든 로직은 네 머리 속에 있잖아... 너를 믿어..." 라고 말해줍니다.

  2. 안녕하세요. 디밥님

    Copy & Paste는 지옥의 시작이라는 것을 알아야 하는데 말이죠.

  3. copy & paste 와 reuse의 차이점이 무얼까 갑자기 고민이 들게 되네요 ㅎㅎ

    프로토타입이라고 해서 거기에 들어가는 라이브러리나 함수이름들이
    실제 개발시에 사용하지 않는것도 아니고 단지 예외처리부분이 빠졌을 뿐 실제 작성될 코드와 거의
    코어로직은 동일할텐데 다시 백지에서 부터 개발하라고 한다면
    개발자에게 조금 잔인한 처사 같은데요 ㅠ.ㅠ

  4. 구차니님 안녕하세요.

    Copy & Paste의 진정한 지옥은 소스코드를 여기저기 복사해서 회사에 비슷한 소스가 여러벌 존재하는 것이죠.

    프로토타입은 버린다고 생각하고 만드는 것이지만, 그 Logic은 다시 쓸 수 있죠.
    그렇다고 프로토타입을 만들 때 복사해서 쓸 것을 예상해서 코딩 규칙도 지키고 제대로 하려면 시간이 더 많이 걸립니다.
    백지부터 타입을 하는 것은 아니죠. ^^
    가장 빠르게 검증 목적으로 만든 경우는
    기존 소스코드를 그대로 붙여 넣기를 할 수는 없고, 붙여넣더라도 함수이름도 다 바뀌고 90%는 바뀔 겁니다.
    프로토타입이 재사용이 충분히 가능하도록 잘 만들어졌다면 시간을 좀 많이 쏟은 것이 아닌가 생각해볼 필요도 있을 것 같습니다.

  5. 저는 프로토타입을 꼼꼼하게 만드는 사람을 많이 봤습니다 ㅡ.-;;;
    프로토타입만드는데 변수명하나하나까지 고민하죠;;

    속으로
    "그 정성으로 주석이나 재대로 달라고!!!"
    라는 생각을 했습니다.

  6. 당근천국님 안녕하세요.
    동감입니다.

  7. 프로토타입의 재사용에 대해서는 의견이 분분할 수 밖에 없을것 같습니다. 코딩을 많이 하다보면, 변수 이름, 함수 이름등은 당연히 다시 사용할만큼의 이름을 가질 것 같습니다. 코딩 규칙도 마찬가지구요. 주석이야 없을 수 있다고 하지만, 경험자에 의해서 잘 만들어진 프로토타입의 소스는 다시 쓸 가치가 있을 것 같습니다.

    꼭 버려야만한다고 생각하지는 않습니다.

  8. zelon님 안녕하세요.

    이분법으로 얘기하기 어렵지만 원칙은 있습니다. 이에 관련된 글을 한번 올릴께요.

    감사합니다.

같이 일하려면 적어라.

2011/11/01 02:51 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed




"협업은 말로 하는 것이 아니라 문서로 하는 것이다."

동서고금을 막론하고 개발자들은 적는 것을 싫어하고 또 잘 적지 못한다.

우리나라 개발자들은 그 정도가 훨씬 심하다.

우리나라에서는 회사가 크던 작던 상관없이 대부분 5년, 10년 개발한 제품도 변변한 문서가 하나 없는 것이 현실이다. 이것만 보더라도 협업의 수준이 얼마나 낮은지 알 수 있다.

협업이란
1. 여러 사람들이 가지고 있는 지식과 경험의 도움을 받고
2. 서로 머리를 더해서 더 좋은 생각을 이끌어내 내고
3. 일을 서로 나눠서 하는 것을 말한다.

이런 협업을 하는데 있어서 Template은 중요하지 않다. 협업이 필요한 내용이 공유를 할 수 있을 만큼만 적히면 된다. 적힌 것이 있어야 서로 공유를 하고 도움을 받을 수 있다. 만약 적히지 않고 머리 속에 있는 내용을 공유하려면 매번 말로 설명하는 수밖에 없다. 얼마나 피곤한 일인가. 또한 본인도 기억하지 못하는 사태가 벌어진다.

대표적으로 스펙과 설계는 협업이 매우 중요하다.
스펙과 설계를 제대로 적지 않고 리뷰를 하면서 계속 발전시켜나갈 수 없다. 한사람의 머리속으로 기억을 하면서 말로 공유를 하면 일을 서로 나눠서 개발하기도 어렵다.

하지만... 우리나라에서는 소프트웨어 개발을 할 때 변변한 문서도 없이 여러명이서 나눠서 개발을 잘도 한다. 물론 효율적으로 협업이 되지 않는다. 스펙과 설계가 불명확하여 개발자들이 코딩할 때 다 알아서 하고 나중에 통합도 잘 안된다. 스펙과 설계를 적기가 어려워서 최근에는 Agile 방법론이 인기를 끌고 있지만, 이것도 하나의 방법일 뿐이다. 

뭔가 적어야 할 때 Template을 꺼내놓고 틀에 맞춰서 적으려고 고민하기 보다는 서로 협의하고 확인을 받아야 하고 도움을 받아야 할 내용들을 적어서 수시로 리뷰를 하면서 진행을 해보라. Text 에디터로 Plain text로 적어도 아무 상관이 없다. 이렇게 효과적으로 적고 협업을 자주 하다보면 스펙과 설계를 어떻게 적어야 효과적으로 프로젝트가 진행이 될지 조금씸 감을 잡을 수 있을 것이다.

Image by Norman Lear Center



 
저작자 표시 비영리 변경 금지

'개발문화' 카테고리의 다른 글

같이 일하려면 적어라.  (6) 2011/11/01
우리 식대로  (1) 2011/10/30
우리나라 소프트웨어 회사에는 ???이 없다.  (4) 2011/07/30
주먹구구를 더 좋아 하는 이유  (11) 2011/07/17
나쁜 습관  (2) 2011/06/19
내가 소스코드를 몰래 고치는 이유  (13) 2011/02/01

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/240 관련글 쓰기
  1. 회의 소집 했더니, 필기도구도 안가지고, 맨 몸으로 옵니다...
    아이디어를 글로 적어보라고 하면, 못합니다...
    말로만 떠듭니다...
    그걸 그림으로라도 대강 그려보라고 하고, 다시 말해보라고 합니다... 전혀 다릅니다...

    그래도 계속 강제로 글 쓰게끔 합니다. 언젠가는 늘겠죠.

  2. 디밥님 안녕하세요.

    제가 자주 하는 말입니다. "지금 말한걸 그대로 적으세요.", "제가 그대로 적어 드릴까요?"

    말한 것을 그대로 적는 것도 쉽지 않은 것 같습니다.

    회의록을 작성하고 follow up 하는 것을 당연히 여기는 문화는 또 그렇게 흔하지 않더군요. 이 부분은 대기업이 조금 더 낫더군요.

  3. 개발자들은 원래 말보다 코드로 설명하는걸 좋아하거든요 ㅋㅋ
    단지 표현 수단으로서 인간의 언어/말 대신 프로그래밍 언어/코드로 표현을 하는 것일 뿐이에요

  4. 구차니님 안녕하세요.

    Psudo 코드 같은 것을 적는 것도 좋은 방법입니다. ^^

  5. 옳으신 말씀. 특히 인수 인계때 필기도구 안가지고 오는 용감한 분들은 이해가 안갑니다. 그런분들이 꼭 매뉴얼 안보고 자기 머리로 소스코드만 보더라구요. 자기머리로 어쩔라구. 항상 좋은 글 잘보고 있습니다. ㅋㅋ

  6. 미물님 안녕하세요.
    혹시 한번 들으면 모든 것을 기억하는 천재가 아닐까요? 그렇다고 하더라도 다른 사람들을 위해서 적어야겠죠?

우리 식대로

2011/10/30 16:12 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



"우리 식대로" 마치 북한에서 하는 얘기 같지만, "우리 식대로"를 주장하는 소프트웨어 회사는 의외로 많다.
 
체계가 하나도 없이 완전 주먹구구 방식의 소프트웨어 회사가 있는가 하면 "우리 식대로"를 주장하여 정말 많은 일을 해 놓은 회사도 있다. 

이 "우리 식대로"라는 것이 표준적이고 일반적인 방법과는 사뭇 달라서 어떻게 보면 기발하기도 한 것들을 많이 이룩해 놓은 경우가 있다.
 
소스코드 관리, 버그관리, 빌드, 분석, 설계, 테스트 등 전반에 걸쳐서 아주 독특하고 비효율적인 방법들은 너무나도 많이들 만들어 놓았다.

결론부터 말하면 주먹구구인 회사보다 "우리 식대로" 회사가 문제가 더 크다. 주먹구구인 회사는 백지와 같아서 하나씩 배워나가고 바꿔나가면 되는데, "우리 식대로" 회사는 바뀌기가 더욱 어렵다. 

"우리 식대로"는 충분한 경험과 통찰력 없이 나름대로의 방식으로 만들어 놓은 것들이라서 잘 적응해서 사용하고는 있지만, 효율이 높지도 않을 뿐더라 프로젝트의 규모가 커지거나, 개발 분야가 확대 되거나 Global한 Business를 할 때 꼭 문제가 발생한다.
 
이렇게 문제가 발생해도 "우리 식대로"에 익숙해진 사람들은
  • 기존 방식이 익숙해져서
  • 새로운 방식이 더 좋다고 믿을 수가 없어서
  • 그 동안 투자한 것(Sunken cost)이 아까와서
  • "우리 식대로"를 구축한 사람들이 정치적으로 방해해서
  • 제대로된 새로운 방식 도입에 상당히 어려움을 겪게 된다.
그래서 나름대로 방식으로 뭘 해보려고 하면 나는 "하지 말라"고 한다. 소프트웨어를 개발하는 기본적인 원리와 체계는 대부분 표준적인 방법이 있고, 이를 먼저 익히고 경험한 후에야 "나름 대로 방식"으로 응용이 가능하다. 그러기 위해서는 남들은 또 외국에서는 어떻게 하는지 항상 관심을 가지고 있어야 한다.

요상망측한 툴들을 만들어 놓고 뿌듯해 하지 말자. 나중에 발목 잡힌다.
 
Image by Don Pableras
저작자 표시 비영리 변경 금지

'개발문화' 카테고리의 다른 글

같이 일하려면 적어라.  (6) 2011/11/01
우리 식대로  (1) 2011/10/30
우리나라 소프트웨어 회사에는 ???이 없다.  (4) 2011/07/30
주먹구구를 더 좋아 하는 이유  (11) 2011/07/17
나쁜 습관  (2) 2011/06/19
내가 소스코드를 몰래 고치는 이유  (13) 2011/02/01

전규현 개발문화

Trackback Address: http://allofsoftware.net/trackback/243 관련글 쓰기
  1. Blog Icon
    슬픈멍멍

    지극히 공감합니다.
    개발환경만이 아니라 개발자체도 그렇다고 생각합니다.

문서는 얼마나 적어야 할지?

2011/10/27 17:26 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



소프트웨어 개발 프로젝트에서 문서는 적게 적어야 한다.

다시 말하면 "보통의 회사에서는 문서는 필요한만큼만 가장 적게 적어야 한다."

물론 문서를 많이 적으면 여러 각도에서 상세히 적기 때문에 중복은 많이 발생하지만 잘못된 가능성을 충분히 줄여준다.

예를 들어서 스펙문서를 제대로 하나를 효과적으로 적으면 95%를 커버하는데 이를 99.9%까지 커버하도록 적으려면 10배의 비용을 더들여서 수십개의 문서를 만들어야 한다.

절대 문제가 생기면 안되는 원자력 발전소, 우주선, 생명유지장치는 이렇게 할 수도 있다. 실제로는 이런 경우도 다 그렇게 하는 것은 아니다.

문서를 아무리 많이 적어도 완벽을 기해야 하는 경우는 여러 문서를 적어야 하지만 보통의 SW 개발 프로젝트에서 이러한 경우는 거의 없다. 대부분의 SW 개발 프로젝트는 가장 적은 비용으로 가장 빨리 끝내야 한다. 그러기 위해서는 문서를 가장 적게 또한 효과적으로 적어야 한다.

아래에 문서를 만드는 4가지 경우가 있다.
  1. 문서 거의 없이 개발하는 경우 (쓸모 없는 문서, 개발중에 안보는 문서, 나중에 문서를 만드는 경우도 여기 해당) 
  2. 스펙문서를 포함해서 한두개의 문서를 효과적으로 적는 경우 
  3. 각 단계에서 수십개의 문서를 철저히 만드는 경우 (거대 방법론)
  4. 거대 방법론을 흉내 내지만 문서는 거의 안보는 경우. 문서따로 개발따로 (우리 주변에서 흔히 보는 경우)
  5. 최종 결과물만 거대 방법론 흉내내는 경우. 나중에 제출용으로 문서를 만든다. (이것도 친근하다)
이중에서 당연히 권하는 것은 1번이고 다음은 2번이다.
3,4,5번 보다는 차라리 2번이 낫다.

문서를 많이 적는 것은 중복이 많아지고 결국에 서로 Conflict가 나고 업데이트도 안되며 정작 개발시 거의 쓸모없어진다. 하지만 문서를 가장 효과적으로 적게 적는 것은 수십개의 문서를 적는 것보다 훨씬 더 어렵다.

일단 많이 적어보고 줄여나가는 것보다는 문서를 거의 적지 않는 경우라면 꼭 필요한 것부터 조금씩 늘려가는 것이 좋을 것이다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by 
EvelynGiggles

 
저작자 표시 비영리 변경 금지

전규현 개발프로세스

Trackback Address: http://allofsoftware.net/trackback/239 관련글 쓰기
  1. 넘침은 부족함만 하지 못하다고 했는데
    사람의 욕심과 보여주기 그리고 비교로 인해서
    이런 작업을 하지 않으면 일을 하지 않는것 같아 보인다는 생각을 고쳐야 할텐데 그게 가장 어려운것 같아요

  2. 안녕하세요. 구차니님

    열심히 코딩하고 있으면 일한다고 생각하고, 아키텍처 고민하고 있으면 논다고 생각하는 경향도 있더군요.

    소프트웨어엔지니어가 경력이 늘어 갈수록 코딩 등의 일은 줄어들고 생각하는 시간이 늘어야 하는데 말이죠.

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

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

내가 개발에 집중할 수 없는 이유

우리나라에서는 개발자들이 개발에 집중할 수 없는 환경인 곳이 참 많다. 정도의 차이가 있지만 거의 대부분이라고 봐도 무방하다. 그 결정적인 이유는 개발자 혼자서 북치고 장구치고 다해야 하는 상황이기 때문이다. 원래는 이렇게..

설계가 필요할까?

최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다. 그래서 설계에 대해서도 깔끔하게 정의를 해보자. 흔히 설계에 관한 다음..

Software Architect를 양성하는 나라

우리나라에서는 종종 SW Architect를 양성한다고 한다. 정부에서 막대한 예산이 지원도 되며 SW Architect를 양성하는 학원도 생기고 야단법석이다. 그럼 도대체 SW Architect는 무엇인가? SW Archi..

우리에게 지금 필요한 것은? 바로 이것

우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은 "기초 체력"이다. 히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다. 그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내..

프로토타입을 재활용하면 될까? 안될까?

며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다. 2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란? 소프트웨어공학의 목적..

프로토타입이란?

프로토타입 (경제/경영) 양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을..

같이 일하려면 적어라.

"협업은 말로 하는 것이 아니라 문서로 하는 것이다." 동서고금을 막론하고 개발자들은 적는 것을 싫어하고 또 잘 적지 못한다. 우리나라 개발자들은 그 정도가 훨씬 심하다. 우리나라에서는 회사가 크던 작던 상관없이 대부분 5년..

우리 식대로
우리 식대로 2011/10/30

"우리 식대로" 마치 북한에서 하는 얘기 같지만, "우리 식대로"를 주장하는 소프트웨어 회사는 의외로 많다. 체계가 하나도 없이 완전 주먹구구 방식의 소프트웨어 회사가 있는가 하면 "우리 식대로"를 주장하여 정말 많은 일을..

문서는 얼마나 적어야 할지?

소프트웨어 개발 프로젝트에서 문서는 적게 적어야 한다. 다시 말하면 "보통의 회사에서는 문서는 필요한만큼만 가장 적게 적어야 한다." 물론 문서를 많이 적으면 여러 각도에서 상세히 적기 때문에 중복은 많이 발생하지만 잘못된..