태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

생각은 쉽게 바뀌지 않는다.

2012.10.15 06:28 by 전규현


잠시 후 Google blogger로 이동됩니다.






많은 회사에서 경영자, 개발자들이 소프웨어를 좀더 효과적으로 개발하기 위해서 다양한 시도를 한다.

문서를 작성하고 소스코드를 관리하고 이슈를 관리하고 프로젝트 관리 기법을 도입한다. 이런 외형적인 시도를 해도 생각은 쉽게 바뀌지 않는다. 특히 경영자들의 마인드가 잘 바뀌지 않는다. 소프트웨어 개발을 제대로 이해하지 못했기 때문이다.


실리콘 밸리와 우리나라에서 소프트웨어를 개발할 때 가장 큰 차이를 보이는 것이 있다.


스펙을 바꾸는 것이 얼마나 큰 일인지에 대한 생각이다. 실리콘밸리에서는 스펙을 바꾸는 일이 개발팀에 엄청나게 큰 부담을 주고 일정과 비용이 영향을 주는지 경영진을 비롯한 모든 직원들이 알고 있기 때문에 스펙을 쉽게 바꾸려고 하지 않는다. 그렇기 때문에 스펙을 작성할 때 철저히 리뷰를 한다. 리뷰를 소홀히 하다가 나중에 빠진 거나 잘못된 것을 바꾸기가 쉽지 않기 때문이다. 그래서 스펙이 제대로 적히고 잘 검토가 되고 프로젝트에서 매우 중요한 역할을 한다.


그런데 우리나라에서는 스펙을 바꾸는 것이 얼마나 큰일인지 잘 인식하지 못한다. 경영자뿐만 아니라 개발자도 그런 경우가 많다. 어차피 주먹구구식으로 개발하기 때문에 스펙 변경을 대수롭지 않게 생각하거나 자포자기식 개발자도 많다. 그래서 스펙을 작성하기 않기도 하거나 대충 작성하다 마는 경우가 많다.


교육을 하고 설득을 하고 귀가 아프도록 얘기를 해도 피부로 느끼기 전에는 생각이 잘 바뀌지 않는다. 이는 방법론에 따라서 다른 얘기는 아니다. 이미 스펙이 결정된 후에는 어떠한 방법론에서도 스펙 변경은 큰 일이다. 


물론 스펙 변경이 불가능한 것이 아니다. 비용 증가를 감수하고도 변경해야 할 이유가 있으면 합리적이고 적절한 절치를 통해서 변경해야 한다.


보통의 경영진은 프로젝트 진행 도중에 이런 저런 요구를 하고 싶게 마련이다. 프로젝트에 관여해서 영향력을 행사하고 싶은 욕구가 있는 경우도 있다. 이럴 때 요구사항을 잘 받아주는 개발자가 우리나라에서는 더 높은 평가를 받곤하지만 회사 전체적으로는 손해가 되는 일이다. 정말 급한 요구사항이 아니라면 다음 버전으로 미루면 되는 일이다. 


소프트웨어 개발에서 스펙을 함부로 바꾸면 안된다는 것만 깨달으면 소프트웨어 공학의 80%는 터득한 것이다. 거의 대부분의 다른 문화는 다 여기서 파생된다. 안타까운 것은 외워서 되는 것이 아니라는 것이다.


image by sirwiseowl


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

전규현 개발문화 문화, 스펙

  1. Blog Icon
    임덕규

    책 잘 보고 있습니다. 취업 준비생으로서 포트폴리오를 위하여 진행 중인 개인 프로젝트에 소스 관리 프로그램인 git과 github, 그리고 간단한 스펙 흉내등을 통하여 최대한 효율적인 작업을 진행하려 노력하고 있습니다.

    git의 사용으로 인한 성공적입니다. 물론 제 나름대로의 사용으로서는 아주 만족스런 사용이라 실무와의 갭을 실감 할 수 없어 아쉽습니다.

    좋은 내용 감사합니다.

  2. 안녕하세요. 임덕규님
    잘하고 계시네요. git 사용법은 간단하지만 제대로 쓰려면 경험이 좀 필요합니다. Tag와 Branch도 활용하고 책에 어느 정도 소개가 되어 있으니 참조하세요. 간단한 소프트웨어는 스펙도 간단하게 작성할 수 있습니다. 이슈관리시스템을 이용해도 됩니다.
    실무에서는 스펙의 규모가 크기 때문에 얘기가 완전히 달라집니다. 이것은 실무에서 직접 배우는 것이 좋습니다. 그래도 이렇게 마음가짐을 가지고 경험을 하고 있으면 도움이 많이 될 겁니다.
    문제는 왠만한 회사를 가면 또 주먹구구식 환경이기 때문에 문제가 되죠. 꾸준히 노력하세요.

    감사합니다.

요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다.

2012.08.30 01:40 by 전규현


잠시 후 Google blogger로 이동됩니다.





소프트웨어 개발 프로젝트에서 스펙을 제대로 적지 않는 회사들에게 그 이유를 들어보면 여러가지가 있다.


1. 프로젝트 기간이 너무 짧아서 스펙을 적을 시간이 없다.

2. 프로젝트가 너무 복잡해서 적어야 할 것이 너무 많아서 적을 수 없다.

3. 요구사항을 계속 바꿔서 스펙을 적을 수가 없다.


위의 어떠한 이유도 적절한 이유가 되지는 않는다. 오직 한가지 이유가 될 수 있다면 다음과 같은 것이 있을 수 있다.

"우리는 분석역량이 떨어져서 스펙을 적을려고 해도 제대로 적을 수 없다. 그래서 그냥 개발한다."


위 1,2,3번의 이유 때문에라도 스펙을 적어야 하는 것이다.

이중에서 3번 "요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다"에 대해서 얘기를 해보고자 한다.


99%의 소프트웨어 프로젝트는 분석 기간은 당연하고 설계, 구현 중에도 요구사항이 계속 바뀐다. 단지 프로젝트마다 바뀌는 정도의 차이가 있을 뿐이다.


스펙을 제대로 적었다는 전제하에 스펙을 결정한 후에도 요구사항이 계속 바뀌는 이유는 다음과 같은 것들이 있다.


1. 시장 상황의 변경

2. 경쟁 업체의 신제품 출시

3. 기술 환경의 변화

4. 미처 파악하지 못한 비즈니스 요구사항 발견

5. 예상치 못한 개발 상의 난관 봉착

6. 경영진의 변덕

7. 영업, 마케팅 부서의 끊임 없는 요구


이런 저런 이유로 요구사항 변경 요구는 계속 되기 마련이다. 스펙을 제대로 적어 놓지 않으면 이러현 변경 요구가 관리되지 않는다. 또한, 변경 프로세스를 적용하면 좀더 합리적인 변경 관리가 가능한다.


프로세스라고 하니까 뭔가 매우 부담스러워하고 특히, 영업과 마케팅 부서는 싫어하는 경향이 있다. 과거에는 코딩 중이라고 하더라도 친한 개발팀장에게 추가로 요구를 하면 잘 들어 줬는데 변경 프로세스를 밟으라고 하면 싫어하기 마련이다. 하지만 중요한 프로젝트의 일정과 품질에 영향을 줄 수 있는 결정에 큰 Risk를 안으면서 그냥 결정할 수는 없다.


변경 프로세스의 핵심은 "변경 영향 평가"이다. 이것도 그렇게 거창한 것은 아니다. 새로운 요구사항이 프로젝트에 어떠한 영향을 주는지 정량화하는 것이다. 일정이 더 필요할 수도 있고, 오히려 줄어들수도 있다.(드물지만) 또한 기술적인 위험이 증가할 수도 있다. 짧게는 10분, 길면 몇시간 걸리는 일이다. 스펙을 제대로 적어 놓지 않았다면 요구사항 변경으로 인해 아키텍처에 어떠한 영향을 주는지 파악하기 어렵고, 일정에 미치는 영향도 판단하기 어렵다. 그래서 스펙이 필요한 것이다.


변경 영향 평가가 되었다면 이러한 영향이 있는데도 불구하고 새로운 요구사항을 반영해야 하는지 투명하게 판단을 해야 한다. 어떤 요구사항은 정말 간단한 것 같은데 프로젝트에 큰 악영향을 주는 것도 있고, 커보이는 요구사항이 프로젝트에 문제 없이 포함될 수 있는 것도 있다. 즉, 요구사항 변경이 합리적으로 결정될 수 있다.


변경이 쉽지 않다는 것을 잘 알기에 스펙을 제대로 적고 철저히 리뷰하는 문화가 더욱 견고해지는 것이다.


이러한 프로젝스와 문화가 정착된다면 개발자들도 터무니없는 기능 추가 요청에 일정은 절대 안바꿔주는 비합리적인 요구는 줄어들게 된다. 스펙을 제대로 적고 변경을 관리하는 것이 회사에도 이익이지만 개발자에게는 더욱 좋은 문화임에도 많은 개발자들이 거부하는 경향이 있다. 이는 개발자들 탓이 아니다. 그동안 개발환경이 근거없는 일정 강요와 야간에 내몰리다보니 하루라도 빨리 코딩을 해야 한다는 생각에 내몰린 것이다.


또한, 무리한 요구사항 변경 요청에 "아키텍처를 너무 많이 바꿔야 한다". "몇달이 더 필요하다"라고 하면 개발자들은 항상 안된다고 주장한다고 치부를 해버리곤 한다. 그래서 무리한 변경 요구에 개발자들이 주로 약자가 되곤 한다.


스펙이 잘 작성된다면 일정, 리스크, 비용 등 모든 것에 근거가 생기고 합리적으로 결정할 가능성이 훨씬 높아지게 된다. 


스펙은 프로젝트가 끝날 때까지 계속 바뀌게 되어 있다. 그래서 스펙은 계속 업데이트가 되어야 한다. 하지만 합리적으로 변경 관리가 되어야 한다.


image by  m.a.r.c.


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


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

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

  1. Blog Icon
    SI PL

    Budget, Time은 변경할 생각이 없으면서, 요구사항은 수용해야한다고 생각하는 고객이 문제입니다.

    프로세스를 FM대로 하려면 고객도 FM에 따라주면 좋겠지만, 그런 고객은 못만나 보았습니다.

    아키텍처에 영향을 미칠정도의 요구사항변경은 On Time, on budget에서는 무리라는건...

    변경관리를 하지 않아도 파악되어야 한다고 생각합니다.

    아키텍처에 영향이 없는 폰트변경, 버튼위치변경 요청까지 명문화하여 관리하기엔 인생은 그리 길지 않은것 같습니다.

  2. SI PL님 안녕하세요.

    스펙을 토대로 계약을 해야 하는데, 우리나라는 계약 후에 스펙을 작성하기 때문에 스펙 변경에 전혀 부담을 없어하죠. 그게 가장 큰 문제 중에 하나라고 생각합니다. 오타수정이나 누가봐도 너무 사소한 변경은 상식적으로 변경관리하지 않는 것이 맞으나 미 국방부 프로젝트라면 그런 것도 허용하지 않죠. ^^

    우리나라에서는 환경이 열악한 것은 사실인 것 같습니다. 그래도 이미 그런 것을 알고 감수를 하면서 프로젝트에 뛰어 든 것이지요. 그래서 사실 SI 프로젝트의 수익성이 그렇게 좋지 않습니다. 10건 성공해도 큰것 1건 폭탄을 맞으면 적자가 나기도 합니다. 그래서 분리발주를 법제화하려고 하는 이유중 하나입니다. 모든 것의 전제 조건은 분석 역량이 뛰어나야 하는 것인데 아직 해야 할 일이 많습니다.

  3. Blog Icon
    KIH

    들고온 스펙이 너무 허접하면 어쩌죠..?ㅎㅎ

  4. 안녕하세요. KIH
    약간 헷갈리네요. 고객이 준 스펙이 허접하다는 얘기 인가요?
    개발을 의뢰했는데 개발사가 스펙을 허접하게 작성했다는 얘기인가요?

    첫번째로 생각하고 의견을 말씀드리겠습니다. 일반적으로 고객은 스펙을 작성하지 않습니다. 고객이 스펙까지 다 작성하고 설계/구현만 발주하는 경우는 많지 않습니다. 고객이 소프트웨어 회사인 경우는 종종 있는 경우 입니다.

    분리발주인 경우 스펙을 작성하는 분석 프로젝트를 별도로 발주하기 때문에 스펙이 잘 작성된다고 봐야 겠죠.

    보통 프로젝트인 경우 고객이 스펙을 작성하지 않습니다. 설령 스펙이라는 이름으로 준 문서도 "요구사항"으로 보면 됩니다.
    요구사항과 스펙은 다릅니다. 고객이 허접한 스펙을 주면 분석을 다시 해서 스펙을 작성해야 하는 상황입니다. 원하시는 답이 되었는지 모르겠네요. ^^

90%에서 끝나지 않는 프로젝트

2011.07.27 22:32 by 전규현


잠시 후 Google blogger로 이동됩니다.





Software 개발 프로젝트에서 일정이 늦어지는 경우는 흔하다. 초기 일정을 완벽하게 맞추어서 끝내는 프로젝트는 구경하기 힘들 정도이다.

그 중 대부분의 프로젝트는 90%까지는 진도가 착착 잘 나가는데 10%를 남기고 나서 일정이 계속 지연되곤 한다. 남은 10%를 끝내기 위해서 90% 끝내는데 걸리는 시간보다 더 오래 걸리는 프로젝트를 보는 것은 그리 쉬운 일이 아니다. 설령 일정에 밀려서 출시를 해도 버그가 많은 알파버전 수준의 제품을 출시해서 고객들의 원성을 사기 일쑤이다.

경영자는 매달 개발자들이 하는 다음달이면 끝난다는 얘기를 반복해서 듣게 된다.

이러한 상황을 개발자들은 그렇게 심각하게 보지 않는 경우가 많다. 하지만 비즈니스를 하는 사람은 이것이 비즈니스를 하는데 얼마나 심각한 문제가 되는지 잘 알고 있다.

소프트웨어 공학은 프로젝트 일정을 단축하고 계획대로 개발할 수 있도록 하기 위한 방법에 온 힘을 기울여 왔다. 소프트웨어 공학에서 다루는 거의 모든 분야는 일정 준수에 포커스를 하고 있다고 해도 과언이 아니다.

남은 10%의 일정이 그렇게 잘 안끝나는 주요 원인들은 다음과 같은 것들이 있다.
  • 스펙을 충분히 제대로 작성하지 않았다. 단순한 요구사항을 가지고 개발자들이 알아서 개발을 한다.
  • 설계가 허술해서 인터페이스가 자주 바뀐다. 통합이 잘 안되서 통합하는데 시간이 많이 소요된다.
  • 상세 일정이 없이 큰 단위의 마일스톤만 가지고 있다. 일정관리는 거의 안한다.
  • 리스크 관리는 해본적도 없다.
  • 제품이 개발되기 전까지 스펙이 공유가 안되서 영업이나 경영층에서 프로젝트 막바지에 제품의 모습을 보고 요구사항을 계속 추가로 요청한다. 
  • 프로젝트 일정에 테스트 일정을 충분히 고려하지 않았다. 테스트 케이스를 제대로 만들지 않고 테스트 인력이 부족해서 테스트 할 때마다 계속 새로운 버그가 발견되서 끝나지를 않는다.
개발 방법론이 라이프 사이클들은 여러가지가 있고 최근에 유행을 타는 것들도 있지만 결국에는 스펙을 상세히 제대로 작성하는 것이 근본적인 프로젝트 일정을 지키는 방법이다. 스펙을 제대로 작성하지 않고 여러가지 기법으로 해결할 수는 없다. 스펙을 작성하는 방법이 어찌되었든 스펙이 정확하고 상세해야 정교한 일정 예측 및 관리가 가능해지게 된다. 이런 경험이 점점 쌓이면 일정을 지키는 프로젝트가 점점 늘어 갈 것이다. 그러기 때문에 스펙을 잘쓰는데는 10~20년의 경험이 필요한 것이다.

대충 개발자들이 알아서 개발해주고 일정은 하늘(개발자인가?)에 맡기는 방법에 익숙해진 개발자들은 이런 정교한 일정관리에 거부감을 가질 수는 있으나 결국에는 일정을 지키는 방법이 개발자의 역량을 향상시키는 방법과도 일치하기 때문에 개발자 손에 달린 프로젝트가 개발자에게 파워를 가져다 준다는 생각은 버리는 것이 좋다.

프로젝트 일정은 10%가 남았다면 진짜로 10%만 더 지나면 끝나야 한다. 

 * 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image from
 http://dimland.blogspot.com/2010_08_01_archive.html 
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/일정 스펙, 일정

  1. 프로젝트 일정 자체가 범위와는 무관하게 비즈니스 목표일정으로 정한 후 최대한 많은 기능을 넣는 프로젝트도 있고, 기획이 되지 않은 상황에서 일정추정을 강요하는 환경도 많이 있습니다. 이런 경우는 어떻게 대처해야 좋을지 혹시 좋은 의견이 있으신지요? ㅠㅠ

  2. 이런 프로젝트는 범위도 불투명한 상황에서 일정이 남는다 모자른다 아무리 싸워도 아무 의미가 없게 됩니다. 개발자들은 막연히 일정이 모자른다고 하지만 또한 대부분 늦어지지만, 초기에는 아무 근거도 없이 동대문시장에서 물건 깎듯이 아규를 하게 됩니다.

    가장 좋은 방법은 최대한 빨리 스펙을 쓴 다음에 근거를 가지고 얘기를 하는 겁니다. 일정의 근거가 명확해지면 기획이나 영업에서 무조건 우기기에도 궁색해지게 됩니다.

    또한 기획도 되지 않은 상황에서의 일정 추정은 무리지만 일단 대략의 일정을 주고 꼭 스펙을 써봐야 정확한 일정을 다시 산정할 수 있다고 강조를 해야 합니다. 이를 잘 이해 못하는 사람들도 많지만 이해를 시켜야 합니다.

    기능을 무조건 많이 넣는 것은 키친씽크입니다. 쓸데 없는 기능을 잔뜩 넣는 겁니다. 스펙을 쓰고 WBS에 근거해서 상세 일정이 나와야 쓸데 없은 기능으로 얼마나 일정이 늦어지는지 근거를 제시할 수 있고 이런 기능은 빼고 출시 할 수 있습니다.

    결국 근본적인 해결 방법이 가장 좋은 방법입니다. 문제는 스펙을 잘 작성하는 것이 소프트웨어 개발에서 가장 어렵다는 것입니다. 꾸준히 경험을 쌓아야 합니다.

  3. 의견 감사합니다. ^^ 고객이 무엇을 하고 싶은지도 모르는 상황에서 스펙을 이끌어낸다는 것은 무척이나 어렵군요 ㅠㅠ. 하지만 이게 바로 경험이고 능력이 아닐까 생각합니다. 말씀하신 부분을 명심해서 실천을 해보도록 하겠습니다.

  4. 한가지 더 말씀드리면 고객이 무엇을 하고 싶은지 모르는 상황은 매우 자연스러운 현상입니다. 특히 우리나라에서는 고객이 전문가도 아니고 노력도 안합니다. 우리나라가 좀 심하긴 하지만 외국이라고 고객들이 그렇게 잘 알지 못합니다.
    그래서 스펙을 제대로 작성하는 것이 어렵고 그게 실력의 차이입니다.
    고객이 잘 모르고 개발팀도 잘 모르면 산으로 갈 수 밖에 없습니다. 코딩하기 전에 스펙을 제대로 적고 개발해야 다 만들어 놓고 기능 추가 변경을 반복하지 않을 수 있고 기간과 비용이 절약됩니다.
    아무튼 코딩은 늦게 할 수록 이익입니다. ^^ 이걸 이해하려면 한참 걸립니다.

경영진이 너무 촉박한 일정을 제시합니다.

2011.02.16 22:14 by 전규현


잠시 후 Google blogger로 이동됩니다.





나는 프로젝트 일정에 대해서 항상 "일정은 개발자가 산정해야 한다"고 얘기를 해왔다.

그런데 많은 개발자들과 얘기를 해보면 자신들은 도저히 그렇게 할 수 있는 상황이 아니라고 한다. 일정은 위에서 확정이 되어서 내려오기 때문에 개발자가 정할 수 없다고 한다. 또한 항상 촉박한 일정을 지시하기 때문에 스펙이나 설계는 작성할 수도 없고 코딩부터 한다고 한다. 자신들도 체계적으로 개발을 하고 싶지만 도저히 그럴 시간이 없다고 한다.

경영진이 일정을 제시하는 것과 개발자가 일정을 산정하는 것은 완전히 상반된 얘기가 아니다.

경영진은 어떤 프로젝트를 진행하기 위해서는 일정이 필요하다. 경영진이 일정을 정했다고 해서 불가능한 일정이 가능해지는 것은 아니다. 프로젝트는 들어가야 할 시간은 다 들어간다. 자칫 서두르다가 더 느려질 수 있다.

경영진이 지시한 일정은 경영자의 입장에서 필요한 일정을 제시한 것이다. 이 일정은 변경해도 되는 경우도 있고 절대 변경하면 안되는 경우도 있다.

어떠한 경우라도 이 일정을 지키는 가장 좋은 방법은 개발자가 일정을 산정하는 것이다.

일정을 산정하기 위해서는 스펙을 제대로 쓰고 1,2일 단위로 상세 일정을 개발자가 산정해야 한다. 이쯤되면 전체 일정에서 20~30%의 시간이 지난 시점이 된다.

이때 상당히 정확한 일정이 나오면 경영진이 지시한 일정을 지키기 위한 방법을 강구할 수 있다. 이 일정이 경영진이 제시한 일정과 차이가 없다면 다행이지만 촉박한 일정이라면 스펙을 조정하거나, 개발자를 더 투입할 수 도 있다. 아직 설계, 구현이 본격적으로 시작되지 않았기 때문에 스펙 조정이 가능하고 개발자를 추가 투입해도 상당히 효과가 있다. 

스펙도 조정이 안되고 개발자 추가투입도 어렵고 무조건 밤을 새가면서 일하는 수밖에 없다면 그것도 하루이틀이지 어차피 불가능한 일을 하고 있는 것입니다. 불가능하다는 것을 일찍 알아내는 것도 중요합니다. 불가능한 일을 밀어 붙인다고 가능한 일로 바뀌지는 않습니다. 기적은 일어나지 않습니다.

스펙이 끝날 때까지 손놓고 있는 것이 아니고 스펙을 쓰는 도중에도 일정이 촉박할 것으로 예상이 되면 리스크관리를 통해서 미리 대비를 할 수 있다. 

경영진이 촉박한 일정을 지시했다고 해서 이것을 돌판에 새긴 절대불변의 지시사항으로 생각하고 코딩부터 시작하면 나중에 할 말은 다음과 같은 것들 밖에 없다.
  • 매일 밤새면서 일했는데 못 지켰습니다. 원래 불가능한 일정이었어요.
  • 코딩은 끝났는데, 테스트는 못했습니다.
이런 핑계를 대도 사실 코딩도 안 끝난 경우도 많다. 코딩은 가능하면 늦게 시작해야 기능을 빼거나 변경하기 쉽고 더 일찍 끝낼 수 있다.

경영진은 개발자들이 합리적인 방법을 제시하고 일정을 지켜주기를 원한다. 그래야 비즈니스를 할 수 있기 때문이다.

시간이 부족해서 스펙을 적을 수 없는 것이 아니고 시간을 절약하기 위해서 스펙을 적어야 일정을 지킬 수 있는 방법이 나온다.

경영진이 6개월의 시간을 제시했다면 앞만보고 마구 달리는 것보다는 가장 빠른 시간에 6개월안에 프로젝트를 끝내는 방법을 마련해야 한다. 경영진은 이런 합리적인 방법을 제시하는 개발팀을 후원할 것이다. 가장 빠른 기간에 프로젝트를 일정에 맞게 끝낼 수 있게 방법을 마련하는 방법이 바로 적절한 스펙을 작성하는 것이다.

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

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

전규현 프로젝트/일정 스펙, 일정

  1. Blog Icon
    Jake Kim

    너무나도 당연하고 좋은 말씀이시지만 대부분의 경우에는 이상적인 얘기가 아닐까싶네요. 위에서 일정이 잡혀서 내려오면 개발자는 무슨 일이 있어도 그 일정에 맞추어야 하는 것이 현실이죠. 맞추지 못하면 능력없는 개발자로 인식이 되구요. 경영진이 일정을 제시하고 개발자가 상세일정을 만들어 조율을 한다는 것이 정말 바람직한 과정이지만 현실적으로 얼마나 실천 가능한지 또 하고 있는지 모르겠습니다. 물론 그런 회사도 있기는 하겠지만 대부분의 개발자들에게는 아마 그림의 떡같은 현실이 아닐까 싶네요. 개발자들도 그걸 몰라서 못하는 건 아니거든요. 그렇지 못한 현실에서 어떻게 해야 하는지 조언을 주시는 것이 더 많은 도움이 되지 않을까 싶습니다.

  2. Blog Icon
    루니아

    저랑은 다른 각도에서 글을 이해하신듯 하군요.
    경영진이 제시한 일정에 맞추지 못하면 능력없는 개발자가 되지만, 일정을 완수하기 위해 개발자가 제시한 요구사항을 경영진이 맞추지 못하면 능력없는 경영진이 됩니다.

    위에 글이 현실적으로 들리지 않는다면 그건 능력없는 경영자 밑에서 일하는 경우거나, 능력없는 개발자거나 둘중에 하나가 아닐까요?

  3. 안녕하세요. Jake Kim님
    좋은 의견 감사합니다.
    제가 경험한 것은 다양한 프로젝트와 컨설팅 경험입니다. 거기에 비추어 보면 첫째 제 글은 지극히 현실적입니다. 하지만 경험없이 이렇게 하기는 어렵고 우리나라의 대부분의 소프트웨어 회사에서는 일어나지 않는 현상입니다.
    가장 큰 원인은 개발자들이 코딩은 잘하는데 스펙과 설계를 잘 못쓰기 때문입니다. 실제로 많은 개발자들이 그렇게 못해서 못하는 겁니다.
    왜냐하면 역설적으로 그렇게 할 줄 알았다면 무조건 그렇게 했을 겁니다. 제 경험상 말이죠.
    현실적으로 스펙과 설계를 잘하면 되는데 대부분은 이것을 구체적으로 보여달라고 하면 골프를 잘치는 방법을 글로 알려달라고 하는 것과 비슷한 정도로 설명하기 어렵습니다. 제 책에서도 많은 설명이 있지만 필요성은 인식할 수 있어도 스펙을 잘 적는 방법을 배우기는 매우 어렵습니다.
    그렇다고 그런 노력조차 하지 않으면 10년이 지나도 항상 일정에 허덕일 것입니다.
    항상 스펙에 관련된 얘기는 이슈를 많이 일으키는 것 같습니다.
    이유는 다음과 다음과 같습니다.

    "소프트웨어를 개발하는데 있어서 가장 어렵고도 중요한 것은 무엇을 만드는지 결정하는 것이다. 즉, 스펙을 작성하는 것이다."

  4. 안녕하세요. 루니아님
    제 경험에 의하면 소프트웨어 개발을 이해하지 못하는 경영자가 정말로 많습니다. 개발자들은 이런 SW를 잘 모르는 경영진에게 이해가 가도록 대응하는 것이 필요한데 개발자도 그런 면에서는 매우 취약합니다.

  5. Blog Icon
    SilliconValley

    스펙 작성하는 것과 무엇을 만들지 결정하는 것을 같은 걸로 보시는 것 같은데, 이해가 안되네요. 왜 그 두가지를 같은 것으로 보시나요?

  6. Blog Icon
    SilliconValley

    스펙 작성은 80년대부터 해오고 있습니다.

    스펙 작성하는 것을 requirement engineering과 동일하게 보시나 보군요. IEEE 스탠다드는 오래전에 보긴 했지만 현업과는 거리가 멀어서 그다지 건질만한 것이 없더군요. 최근 requirement engineering 쪽의 발전을 따라오고 있지도 못하는 것 같고요.

    구체적으로 어떤 문서를 추천하시는지 reference를 알려주시면 고맙겠습니다.

  7. Blog Icon
    Jake Kim

    저는 현재 미국에 있고 스타트업 부터 미국 최대대기업까지 경험을 해봤습니다. 일정에 대해 말씀드리자면 그건 그 회사의 문화내지는 그 프로젝트의 스폰서의 성향에 따라 많은 차이가 있는 것 같습니다.

    며칠 걸릴 작업을 1-2주 주는 관리자도 있고 한달 걸릴 작업을 일주일주는 경우도 있습니다. 미국 회사라고 다 넉넉한 일정을 준다거나 일정을 조율할 수 있다는 인식을 주시는 것은 지양을 해야 하지 않을까 싶습니다. 그런 의미에서 드린 말씀입니다.

    위에 말씀하신 것들이 바람직하다는 것을 모르는 개발자들은 아마 없을 겁니다. 다만 특히 한국적 상황에서 경영자나 윗 사람에게 일정을 조율해야 한다는 것을 설득할 방법을 모르거나 없다는 것이 문제인 것이죠.

    스펙을 쓴다고 설득이 될까요? 그래서 설득이 될 경영자 같으면 처음부터 막장 일정을 제시하지 않겠죠. 개발자가 아무리 스펙을 갖다 밀고 소프트웨어 공학적인 지식으로 설득을 하야시가 경영자의 이말 한마디면 쓸모가 없어지죠.

    시장에 빨리 내놔야 해.

    문제는 항상 시장에 빨리 내 놓아야 하는 경영진을 어떻게 설득을 하는가인데 이는 소프트웨어 공학과는 거리가 있는 문제 같아 보입니다. 그리고 정말 상황이 그렇다면 도리 없는 일 아니겠습니까.

  8. Jake님 안녕하세요.

    항상 적극적인 의견 제시를 감사드립니다.
    저는 여러 의견을 통해서 항상 배우고 있습니다.
    제 글을 보고 있는 많은 개발자들은 경험과 환경이 매우 다릅니다.
    너무 당연한 것도 모르고 있을 수도 있고 아주 잘 알고 있는 개발자들도 있습니다.
    그래서 주로 가장 많은 한국의 보통 개발자를 주 독자로 생각합니다. 아주 정교한 것은 아닙니다.
    jake님 시각에서 좀 다른 것은 언제든지 말씀해주세요. 이런 대화 자체가 많은 독자에게 의미 있을 것 같습니다.


    한국에서는 대부분은 아무런 근거도 없이 "일정이 모자란다", "일정을 더 달라" 얘기를 하는데 근거가 필요하다는 얘기입니다.
    스펙은 그런 결정을 하는데 도움을 줍니다.

    경영자와 도저히 의사 소통이 안된다면 어쩔 수 없을 것입니다.
    무조건 시킨다고 한달 걸릴 일을 1주일만에 해낼 수는 없을 겁니다. 설령 해냈다고 하더라도 뭔가를 희생했을 겁니다. 품질을 희생했으면 회사가 나중에 손해를 볼 것이고 건강을 희생했으면 내가 나중에 손해를 볼 것입니다.

    상대적으로 미국보다 한국에서 합리적으로 대화가 안되는 경영자가 더 많습니다. 이런 경영자는 스펙이고 소프트웨어 공학이고 필요 없습니다. "이런 경영자를 설득하는 방법" 같은 것은 제가 따로 설명하지는 않습니다. 그런 개발자를 직접 교육하고 설득하여 경영자의 마인드를 바꾼 경험은 많습니다.

    이런 경영자 밑에서 일하고 있다는 것 자체가 피곤한 일이죠.

  9. 안녕하세요. SilliconValley님
    스펙을 가장 간단하게 표현하는 말로 "무엇을 만드는지 결정하는 것"이라고 말합니다. 이 말이 맞다 틀리다 논쟁을 할 수 있습니다. 스펙의 실체를 정확하게 표현하기는 그만큼 어렵습니다.
    SilliconValley님이 이해가 안되서 여쭤보시는 것인지, 틀리다고 생각하시는 것인지, 다른 의견이 있으신 것인지, 즉 질문의 의도를 좀더 구체적으로 얘기를 해주면 건설적인 토론이 될 것 같습니다.
    스펙을 제대로 이해하려면 스펙을 제대로 다년간 작성을 해오면서 IEEE에서 나온 스펙에 관련된 문서들을 여러번 읽어보면서 음미를 하면 될 것 같습니다.

  10. SilliconValley님 안녕하세요.
    80년대부터 스펙을 작성해오고 있다면 80년대 말이라고 하더라도 30년 이상의 경험을 가지고 계시는군요. 이미 어느 정도 경지에 오르셨을 것 같은데요.

    "이론이 먼저냐 현실이 먼저냐"는 것도 이슈가 되는데 소프트웨어 공학은 현실이기 때문에 현업과 거리가 멀어서 쓸모가 없는 것은 소프트웨어 공학이라고 보기 어렵거나 다르게 이해하고 있는 경우가 많습니다.
    IEEE 스탠다드 문서들도 현실의 경험을 토대로 만들어진 것들이기 때문에 받아들일 때 적절하게 해석을 해야 할 것으로 생각합니다.
    제 경우를 말씀드리면 10년 전에 봤던 문서를 지금 보면 완전히 다릅니다. 그동안 쌓은 경험 때문이겠죠. 사소하게 읽고 지나갔던 문장들이 눈에 들어오더군요. 10년 후에는 또 달라져 있을 겁니다. 매우 오래된 문서들이지만, 지금도 유용합니다.
    그래서 스펙을 작성하는 실력은 몇 십년이 지나도 계속 발전한다고 봅니다.

  11. Blog Icon
    Jake

    맞습니다. 그런 경영자나 관리자와 같이 일한다는 것은 정말 고달픈 일입니다. 안타까운 것은 그런 환경이 꽤나 많다는 것이지요. 많은 사람들에게 편리를 제공하는 개발자들이 정당한 대우를 받고 일할 수 있는 환경이 빨리 만들어졌으면 좋겠습니다.

  12. Blog Icon
    SilliconValley

    "그런 개발자를 직접 교육하고 설득하여 경영자의 마인드를 바꾼 경험은 많습니다."라고 하셨는데, 개발자가 교육을 받고 경영자의 마인드를 바꿨다는 말씀이죠? 그런 경험이 많으시다면, 제 생각에 그 경험 이야기를 해주시는 것이 훨씬 더 유익할 것 같습니다.

  13. SilliconValley님 안녕하세요.
    경영자의 마인드는 저희가 바꾸는 교육을 합니다. 제 덧글에 오타가 있군요.
    사실 경영자의 마인드를 바꾸는 것은 매우 어렵고 바뀌지 않는 경우도 많습니다. 절대 바뀌지 않는 경영자들도 많지만 바뀔 준비가 되어 있는 경영자들도 많이 만나 봤습니다. 그들은 바뀔 준비가 되어 있지만 방법을 모르기 때문에 이런 저런 시도를 하다가 거의 실패하고 저희를 찾아오는 경우가 많습니다. 그런 경우에는 빠르게 개혁에 성공하곤 합니다.
    저희는 컨설팅할 때 NDA를 맺기 때문에 컨설팅 경험을 직접적으로 얘기를 할 수는 없습니다. 단 일반화 시켜면 언급을 할 수 있기 때문에 앞으로 그런 경험의 글을 올려보는 것을 고려해보겠습니다. NDA에 위배되지 않게 조심해야 하기 때문에 신중할 것입니다.
    제 블로그에는 SW 회사가 바뀌는 것은 경영자에게 달려있고 경영자가 어떻게 바뀌어야 하는지에 대한 글들이 여기 저기 있습니다.

  14. Blog Icon
    J

    포스트를 읽을때마다 드는 생각은 당연한이야기'만' 한다는 생각이듭니다.


    프로젝트기간이 10개월이라고 하고
    3개월동안 계획을 세우고 구현할 기능등 여러사항을 쭉 정리한 후.
    7개월동안 구현할 핵심목록을 정리해서 그걸 중심으로 진행하는게 좋은건 알고있습니다. < 개발자에게 이제는 너무나 당연한 이야기지요. 경험이좀쌓이면 그냥 알게 되기도하고, 경험이 입으로돌다가 책으로 한권 나오고 결국 책들이 무수히 쏟아질정도로 오래 지났습니다.


    10개월짜리 일정에 맞춰 임시로 릴리즈하고 13개월째 완성을 시켰다고 하면.
    현재 우리나라에선 3개월동안 놀아서-> 3개월 지연됐다 라는 이야기가 나올겁니다.
    어떻게 개발자를 충원을해서 10개월짜리 일정을 맞춘다고해도 3개월동안 놀아서 더 인력을 투입해야 했다는 이야기가 나올테구요.
    저 외부에서 보기에 아무것도 안하고 있는것같은 시간을 어떻게 설득하고 납득시키는지가 궁금합니다.


    회사에서 외부 컨설턴트를 부르고 그 외부 컨설턴트가 저런 의견을 주면 쉽진않지만 먹힐가능성이 있습니다만.
    회사내에서 외부로 컨설팅을 의뢰할 정도면 상황이 좋은 (좀 깨인 회사에 돈도 좀 있는)회사입니다.

    하물며 그냥 회사내 개발부서에서 이야기하면 어지간한 이야기는 다 그냥 변명으로 넘어갈껍니다.
    니 전임자 또는 너도 이전에 그냥 쭉쭉짜더니 설계? 뭔소린데 라던가.
    어 해~ 그런데 왠 3개월 1주일만에 끝내 라던가.


    이런부분은 전혀 적지 않으시는것 같습니다.
    컨설팅을 하시면 개발자는 납득을 하는데-> 쓸만한 스펙 작성에 어려움을 겪을것 같고
    관리나 경영쪽에 저 2~30%의 시간을 납득을 못했을것 같습니다.

    언제나 글을 읽으면서 궁금한건 저런 설득을 시키던 경험같은것입니다.

  15. Blog Icon
    개발20년차

    김익환씨가 쓰는 책도 그렇고, 경험을 중시한다는 태도는 좋지만 실제 "이러이러해서 이렇게 했는데 이렇게 되어서 이런 교훈을 얻었다"는 이야기가 없고, "이렇게 이렇게 해보면 이렇게 될 것이다 한번 해보라"는 이야기도 없어서 전반적으로 글들이 경험적이지 않은 것 같습니다. 좀 더 구체적이면 좋겠네요.

  16. 안녕하세요. J님
    현실감이 쭉쭉 느껴지는 의견이군요. ^^
    여러 회사의 여러 개발자들을 만나보면 자주 듣는 얘기들입니다.
    그런데, 그런 회사의 경영자, 개발자들도 스펙을 제대로 작성하는 것을 한번만 보기만 해도 완전히 인식이 바뀌는 것을 자주 봐 왔습니다.
    그동안 생각하고 있었던 스펙, 설계라는 것이 많이 다르다는 것을 경험하기 때문이죠.
    제대로 작성하면 병행 개발도 가능하고 일정도 단축된다는 것을 경험적으로 알게 됩니다.
    그렇다고 하더라도 스펙을 진짜 잘 작성하려면 5년, 아니 10년 이상 걸리게 됩니다. 즉, 많이 작성할수록 계속 실력이 늘게 됩니다.

    하지만 막상 회사 내부에서 경영진을 설득하기란 매우 어렵습니다. 그래서 컨설팅이 어려운 회사는 강연을 통해서 경영진의 마인드를 바꿔주기도 합니다. ^^

  17. 개발20년차님 안녕하세요.

    김익환 대표님은 실리콘밸리에서부터 27년가 소프트웨어 개발 경험이 있고 저는 17년간 소프트웨어를 개발하고 있습니다. 제 글에 있는 그대로 개발을 해왔고 그대로 컨설팅을 하고 있고 블로그에 글을 쓰고 있습니다. 물론 저는 초기에 시행착오를 한적도 있었습니다.

    제 글중에서 이해하기 쉬운 글들은 툴이나 간단한 기법들에 관련될 것입니다. 그리고 이해하기 어렵지만 더 중요한 글들은 스펙, 설계, 문화 등에 관련된 것입니다.

    골프를 배우는데 책과 글을 통한 영양학이나 체력훈련 방법, 장비 선택 방법은 익히기 쉬운데 진짜 스윙과 게임 방법은 글로는 한계를 가지고 있습니다. 눈으로 보고 배우는 것이 유일한 길입니다.

    실리콘밸리의 소프트웨어 회사에 입사를 하면 항상 보고 배우는 그것이라서 저절로 익히게 되는데 우리나라 현실에서는 그렇지 못하기 때문에 어렵습니다. 안타까운 현실이죠.

  18. J님 덧붙일 것이 있습니다. ^^

    제가 컨설팅을 한 회사 중에서 가장 작은 회사는 총 직원이 10명 정도에 매출액이 10억 정도인 회사도 있고, 큰 회사는 직원이 몇만명인 회사도 있습니다.
    컨설팅은 돈이 여유가 있어서 하는 것이 아니고 스스로 해내기 어렵지만 꼭 필요한 도움을 외부 전문가에게 도움을 청하는 것입니다.
    이를 통해서 회사가 얻는 이득이 비용에 비해서 훨씬 크다고 생각하는 회사들만 도움을 요청합니다.
    또한 저희는 컨설팅 보람이 큰 회사를 우선 순위 높게 생각하고 있습니다.
    컨설팅이 돈많은 회사가 여윳돈으로 하는 것이 아닌가 오해를 할까봐 말씀드립니다.

  19. Blog Icon
    J

    제가 적은걸 오해하신거 같습니다.

    제가아는상식선에서 어떤 회사라도 돈이 남아돌아서 컨설팅을 의뢰하진 않을것 같습니다.
    컨설팅을 의뢰한다는건 회사의사결정권자가 외부 의견에 따라 회사 내부 방침을 바꿀 생각이 있다고 보입니다. 돈때문에 오늘내일하는 회사도 아닐테구요.
    즉 컨설팅을 하면서 보신 회사는 적어도 프로세스 개선에 관해서는 비교적 설득이 쉬운 회사일 확률이 높습니다. 오히려 의사결정권자가 부른거니 개발부서에서 저항이 더 컸을지도 모르겠습니다...
    어쨋거나 보통회사는 개발부서쪽이 좀더 저런내용을 납득시키기 쉽습니다.



    그리고 경험을 좀 적어달라고 한것도, 쓰신 내용을보면 일이 쉬운회사만 컨설팅을한건가... 라는 생각이 들어서입니다.

    어제까지 날새면서 일을 하던 회사에서 이글을 보고 그대로 따라하면 어떻게 될까요?
    일단 기적적으로 스펙까진 정말 잘 - 한5년차쯤 되는사람이 잡는 수준으로 잡았다고 가정해도 100% 말한 일정 못지키고 깨진다에 표를 던지겠습니다.
    개발자 스스로 과대평가하는것(50%확률로 잘풀리면 끝날일정을 잡는다거나)도 문제지만, 규모가 커서 일이 서로엮이고 복잡한 경우는 프로세스대로 몇번 일이 흘러가며 데이터가 쌓여야 예측한 일정의 정확도가 높아질 수 있습니다. 게다가 이전에 날새면서 한 프로젝트 뒤처리가 안터질리도 없구요...
    적어도 이런 일반적인 이야기정도는 나올법한데 전혀없습니다.
    거의 예전 BBB가 AAA를 상속해서 라고 씌인 언어책을 보는느낌입니다.

  20. 안녕하세요. J님

    저도 대부분 동의합니다. ^^ 오해라기 보다는 제가 답글을 달 때 이또한 다른 분들도 모두 보기 때문에 1:1 의견 교환이 아니고 여러분들이 보고 있다고 생각하고 적습니다. 그래서 이런 얘기가 왔다 갔다 하는 것이 아주 좋은 현상이라고 생각합니다. 제가 모르는 것도 알게 되는 경우도 있습니다.

    맞습니다. 저희는 거의 대부분 최고경영자가 요청을 해서 컨설팅을 합니다. 또는 개발팀에서 필요성을 느껴서 최고경영자를 설득해 오는 경우도 종종 있습니다. 그리고 컨설팅하기 쉬운 회사는 없습니다. 저희 컨설팅은 개발자부터 경영자의 마인드까지 바뀌어야 하고 몸에 베인 여러가지 습관들은 바꿔야 하기 때문에 받는 입장에서는 어렵습니다. 저항이 심할 때도 많고요. 이는 대기업이나 중소기업도 마찬가지 입니다.
    변화가 그렇게 쉬웠으면 저희가 없어도 회사에서 자체적으로 변화를 했을 겁니다. 저희에게 의뢰를 하는 이유는 변화가 어렵기 때문에 그리고 변화의 방향을 잘못 잡아서 시행착오를 하는 리스크가 너무 크기 때문입니다.

    말씀하신 것 같이 지금까지 밤세워가면서 유지보수에 정신 없던 회사가 기적적으로 나아지기는 어렵습니다.
    악순환의 고리가 시작된 경우라고 볼 수 있습니다.
    이미 나쁜 폼이 몸에 익은 골프 선수는 이를 고치는데 처음부터 배우는 것보다 더 오래 걸릴 수 있습니다.
    이런 경우 "이미 망친 상태"는 제대로 하기 더 어렵다고 합니다.

    컨설팅을 하다보니 "망친 경우 어떻게 해야 할까"라는 의문에 많이 부딪힙니다. 어떤 경우 이미 너무 망쳐서 복구가 불가능한 경우도 많습니다. 하지만 대부분의 경우는 많이 망쳤든, 조금 망쳤든 원칙에 의거해서 회사와 개발자를 변화시키는 방법을 취하고 있습니다.

    많이 망친 경우 시간이 좀 오래 걸리고, 제대로 하고 있었고 다음 단계에 대한 고민을 가지 회사는 정말 잘 적응하고 성장합니다.

    제 얘기가 대부분 원칙을 강조해서 현실에서 멀어 보인다고 느끼는 분들도 많다는 것을 알게 되네요. 이런 경우에도 원칙대로 하라고 강조하는 것을 물러서지는 않습니다. 그방법이 가장 빠르다고 생각하기 때문입니다.

    여기서 원칙은 또 한참 얘기해야 하지만 흔히 알고 있는 정형화 된 프로세스를 말하지 않습니다. 프로세스나 문서를 작성하기 위해서 프로젝트가 더 늦어지면 원칙에서 벗어난 것입니다. 원칙에 대해서는 나중에 또 다루죠. ^^

    이렇게 좋은 의견을 계속 주셔서 정말로 감사합니다. 앞으로도 계속 의견 남겨주세요.

  21. 너무...이상적이지요...
    이상적인 세상에서는 버그도 없겠죠...^^;

  22. 안녕하세요. kalstein님
    이상적으로 생각할 수도 있겠네요. ^^
    이상적이기 보다는 우리나라에서는 어려운 것이라고 생각합니다. 개발자들이 경험하기 어려운 현실 때문에 힘듭니다.
    그래서 미국에서는 소프트웨어 개발자가 최고의 직업중에 하나인데 우리나라에서는 기피 직업이 아닌가 생각합니다.
    제 Twitter의 소개를 보면 "소프트웨어 개발자가 이 땅에서 최고의 직업이 되는 날을 꿈꾼다"라고 되어 있습니다.
    그런 날이 오겠죠?
    여담인데 과거 버그없는 사용 SW가 하나 있었다고 합니다. ^^
    버그를 찾는 사람에게 상금을 걸었는데 못찾았다고 하더군요.
    그래도 현실적으로 버그 없는 SW는 없겠죠.

  23. 본문보다 댓글을 더 재밌게 읽었습니다. ^^ 어느책에선가 '야근은 카드로 물건을 사는것과 같다.'라는 비유를 본적있습니다. 경영진의 마인드가 바뀌는게 최우선이겠네요.

  24. k16wire님 안녕하세요.
    저도 댓글을 매우 좋아합니다. 여러 개발자들의 의견을 들을 수 있어서 저에게도 매우 도움이 되고 블로그 독자들에게도 도움이 될 것으로 생각합니다.
    항상 시간을 내서 댓글을 달아주는 여러 개발자들에게 감사한 마음을 가지고 있습니다.

  25. Blog Icon
    kampf

    댓글이 궁금해서 다시 왔습니다.
    좋은 글은 Facebook으로 사람들에게 추천하고 있는데요.
    반응은 '우리회사 얘기네..' 라는 식입니다.(그런 글들만 추천하니까요.)
    마치 전규현님이 우리회사에 다녔던 분같습니다. &^^&..
    좋은 글들 많이 부탁드립니다..

  26. 안녕하세요. kampf
    Facebook ID 좀 알려주세요. 저도 Facebook을 하거든요. 댓글을 좀 보고 싶네요. ^^
    제 Facebook주소는 다음과 같습니다.
    http://www.facebook.com/raymond.jeon

    그만큼 우리나라의 대부분의 소프트웨어 회사가 실정이 비슷한 것 아닐까요?
    제 만나는 회사는 10명이하의 작은 회사에서 부터 직원이 10,000명이 넘은 대기업까지 다양합니다. 하지만 비슷한 문제점들을 가지고 있습니다. 바뀌기에는 작은 회사가 더 유리합니다.

  27. 댓글이 본문보다 더 길어져 버린 글이네요 ㅎ

    어떻게 보면 이런 상황으로 몰아온 개발자의 "소리없는" No! 가 문제가 아닐까도 싶지만
    칼을 쥐고 있는 쪽은 운영자/경영진 이다 보니 힘없는 개발자에서 힘이 넘치는 개발자로
    탈피를 하지 않는 이상에는 위와 같은 소모적인 논쟁의 끝은 없지 않을까 보여집니다.

    결국은 칼을 쥐는 쪽이 주도권을 잡을테니 말이죠.

  28. 구차니님 안녕하세요.
    댓글이 많은 것은 저도 환영합니다. 이를 통해서 개발자들이 어느 부분을 더 어렵게 생각하는지 잘 알 수 있습니다.

  29. Blog Icon
    최준용

    댓글이 길고, 여러 사람들과 주고 받았길래 읽어 보았습니다.. 정말 주옥같은 댓글과, 절절한 개발자들의 하소연이 느껴집니다.. 저역시 개발자라로서 같은 생각입니다..용기있게 글을 써주고, 성심껏 답변해주신 개발자들과 전규현님께 감사의 인사드립니다.

  30. 안녕하세요. 최준용님
    감사합니다.

  31. 이 블로그에서는 소프트웨어 회사 경영진이 주로 악역을 맡는데요. 경영진을 위한 변명도 있어야 할 것같아서 몇자 적어봅니다.

    제가 아는 많은 경영자분들은 일정을 함부로 결정해서 내려보내지 않습니다. 개발을 잘 모르는 사장님들도 자사의 개발팀장이나 지인들에게 어느 정도의 시간이 걸릴지 의견을 구하는 것이 일반적이고요. 계속 변하는 시장 상황이나 경쟁사에 대한 대응 수준, 과거 유사 프로젝트에서의 경험, 자사 개발자의 개발 능력 등도 일정 결정에 중요한 요인입니다. 즉, 막무가내 같이 보이는 경영진이라도 일정을 제시할 때는 뭔가 근거가 숨어있다는 것입니다.

    그래서 경영진에게 촉박한 일정이라고 의견을 낼 때는 본문에서 강조하신 스펙과 같은 근거가 필요하지 않을까 싶습니다. 무턱대고 촉박한 일정이라고 하거나, 데드라인에 다와서 해봤더니 무리한 일정이었다 하는 것보다는 나름의 근거를 가지고 개발팀의 의견을 제시한다면 조기에 일정을 재조정하거나 추가적인 지원을 받을 수도 있지 않을까 생각합니다.

    항상 좋은 글 감사드립니다.

  32. 안녕하세요. 전경헌 사장님

    개발자가 흔히 촉박하다고 말하면서도 그 근거가 희박한 경우가 많습니다. 전사장님 주변에는 개발을 이해하고 있는 분들이 많은 것으로 알고 있습니다. ^^

  33. 개발자들이 촉박하다고 얘기하는 근거는 명시적인 스펙 문서나 스케줄은 없지만.. 고참 개발자 같은 경우 자신이 그동한 해온 프로젝트와 이번에 진행할 프로젝트의 작업량을 비교해서 경험상 촉박하도고 하는 경우가 대부분일 겁니다.
    또한 우리나라의 경우 일정 자체가 영업쪽에서 워낙 비현실적으로 짧게 잡고 시작하는 경우가 많기 때문에
    개발자가 촉박하다고 하는 경우는 대부분 촉박한게 사실이죠

    전경헌님 생각이나 경험대로 경영자 분들이 일정을 함부로 결정하지는 않을지도 모르고, 그러고 싶지는 않더라도
    우리나라의 갑을병정 구조에서 일정이 갑쪽에서 결정되어 내려오는 경우가 허다합니다.
    경영자 까지도 선택의 여지가 없는 경우가 많다는 것이죠. 결국 갑쪽에서 일하고 싶으면 일정대로 한다고 하고, 일하기 싫으면 관더라 하는 식으로 나오면..

    사실 방법이 없습니다.

  34. 이성열님 안녕하세요.

    이렇게 방법이 없이 돈은 벌어야 겠고, 닥치는대로 일을 하면 점점 어려워 집니다.

    방법이 없는 것은 아니고 그 방법을 제시하고 회사를 변화시키는 것이 제가 하는 일입니다. ^^

    스펙을 쓰는 이유는 프로젝트를 시간을 단축하기 위함인데 그럼에도 불구하고 불가능한 일정의 프로젝트는 안하는 것이 좋습니다.
    그래도 진행하고 영업적으로 풀곤 하는데 그렇다면 스펙을 제대로 쓰고 영업적으로도 해결하는 것이 좋습니다.

    결국 어떠한 경우라도 스펙을 적절하게 쓰고 개발하는 것이 좋습니다. 스펙도 없이 무조건 시작했다가 망가지는 프로젝트가 많은데 이런 장님 코끼리 만지는 듯한 프로젝트 보다는 스펙을 제대로 쓰고 합리적으로 개발하는 것이 좋습니다.

  35. 제가 개발자여서 그런지 왠지 제목만 보고도 답답해지는 글이네요
    (글이 문제가 있다는 뜻이 아니라 그냥 제 상황이 떠올라서요ㅋ)
    제가 경영진이거나 사장이라면 다르게 느껴졌겠죠? ㅎ
    좋은 글 잘 보고 갑니다^^

  36. 안녕하세요. redred님
    누구의 탓이라기 보다는 서로들 소프트웨어에 대한 이해가 부족해서 그렇습니다.

스마트폰 앱스토어가 진짜 대박이 아닌 이유

2010.02.09 13:58 by 전규현


잠시 후 Google blogger로 이동됩니다.





요즘 스마트폰이 IT 이슈의 정점에 있어서 스마트폰 관련 글을 계속 올리게 됩니다.
개발자의 한사람으로서 스마트폰의 급속한 확대는 좋은 징조임이 분명합니다. 하지만 종종 스마트폰 어플리케이션을 만들어서 앱스토어에 올리면 쉽게 대박을 맞을 수 있을 것 같은 기사들이 눈에 띕니다.


물론 거품을 경고하는 기사들이 많은 것은 사실이지만 좋은 것만 보인다고 대박 기사가 더 눈에 들어오는 것은 사실입니다. 개발자들은 "실패담은 내 이야기는 아닐거야"라고 자신에게는 관대한 판단을 내기는 것이 일반적입니다.

이런 종류의 기사들을 읽어보면 전문가들이 말을 인용하는 칼럼형식의 기사는 좀 나은데 기자들이 직접 작성하는 누구나 혼자서 쉽게 소프트웨어를 개발해서 성공할 수 있다는 식의 기사가 많습니다. 그래서 현 상황을 좀 냉정하게 바라보고자 합니다.

긍정적인 측면

확실히 앱스토어가 개발자들에게는 기회의 땅입니다. 어플리케이션을 만들기만 하면 바로 전세계 소비자와 바로 만날 수 있는 기회를 제공했습니다. 마케팅을 얼마나 잘하느냐는 다른 이슈이지만, 어마어마한 마케팅 비용을 들이지 않고도 일단 소비자와 접할 수 있다는 것은 엄청난 기회입니다. 정말 좋은 소프트웨어가 마케팅 비용이 없어서 사라지는 것을 막을 수 있습니다.

또한 스마트폰 앱 시장은 계속 커지고 있고 잠재 고객은 점점 늘어가고 있습니다. 
That's it.

부정적인 측명

기회는 균등합니다. 나에게 기회인 것은 전세계 모든 개발자들에게 동일한 기회입니다. 초창기를 제외하고는 소비자와 쉽게 자신의 어플리케이션을 보여줄 수 있는 것이 그리 매력적인 조건이 아닐 겁니다. 정말 좋은 소프트웨어가 아니면 이 장점이 큰 장점이 아닙니다. 또한 스마트폰 앱 시장이 점점 커지면서 메이저 소프트웨어 업체들이 뛰어들 준비를 하고 있습니다. 기존의 시장과 별반 다를바 없는 치열한 전투장이 될 겁니다.

시장은 그렇다 치고, 개발자 입장에서 바라보도록 하죠.

스마트폰이라고 해서 소프트웨어를 개발하기 더 쉬워진 것은 아닙니다. 잘 만들어진 Framework를 보면 개발이 더 쉬운 것처럼 착시현상을 일으키기도 하지만, 이것이 소프트웨어 개발 전체 프로세스에 미치는 영향은 5%도 되지 않습니다. OOP 컨셉이 없는 개발자들은 오히려 뒤죽박죽을 만들어 버리기 일쑤입니다. SDK를 이용한 코딩보다도 스펙을 제대로 정하고 설계를 하고 테스트를 하는게 비중이 더 높습니다. 이는 기존의 다른 소프트웨어를 개발하는 것과 별단 다르지 않습니다. 즉, 기존에 소프트웨어를 잘 개발하던 개발자나 회사가 이또한 잘 할겁니다.

스마트폰 앱이라고 해서 한번 만들고 끝나는 것이 아닙니다. 일반적으로 소프트웨어는 유지보수 비용이 개발비용의 2~5배 정도 들어간다고 합니다. 그래서 한번 만들어놓은 앱을 꾸준히 유지보수를 해야 하는데, 개인이 이를 감당하기에는 어려움이 있을 수 밖에 없습니다. 진짜 전업으로 매달려야 합니다. 또한 버그 관리, 소스관리, 스펙 관리가 그렇게 쉽지 않습니다. 기존의 소프트웨어 회사들도 크나 작으나 이들을 잘 해내지 못하는 것이 현실입니다. 그렇다고 혼자 개발을 한다고 이 이슈가 사라지지 않습니다. 진짜 혼자 다 해야 합니다.

또, 어쩌다 꽤 인기있는 앱을 만들어서 중박정도를 했다고 해도 꾸준히 매출을 유지하기 위해서 업그레이드와 새로운 제품을 계속 만들어내야 합니다. 앱 개발이 전업이 되었다는 얘기는 꾸준히 수익을 창출해야 한다는 얘기입니다. 회사라면 크나 작으나 나름 각 분야의 전문가들이 힘을 합쳐서 일하기 때문에 진짜 자신이 잘하는 분야에 집중할 수 있어서 꾸준히 발전해 나가는 것이 혼자 북치고 장구치고 하는 것보다는 유리합니다. 자칫하면 수주대토(守株待兎)가 될 수 있습니다.

소프트웨어 개발이라는 것의 대부분은 팀으로 일을 했을 때 더 잘 할 수 있는 것들인데, 혼자서 한다는 것은 한계에 부딪히게 됩니다.  아이디어의 한계, 기술의 한계가 그겁니다. 물론 혼자 일하는 것을 좋아하는 개발자들중에서는 팀웍을 이뤄서 제대로 일하는 방법을 모르기 때문인 경우도 있습니다. 어떠한 경우라도 혼자서 1인회사를 해나가는 것은 쉽지 않은 결정입니다.

이미 소프트웨어 개발에 상당한 공력을 가지고 있는 개발자 몇명을 제외하고는 아무리 좋은 아이디어로 좋은 앱을 개발했다고 하더라도 혼자 개발하는 것은 스스로의 성장에도 지장을 줄 수 있습니다. 물론 이런 시도는 도전의식과 비즈니스 경험을 쌓을 수 있어도 소프트웨어 개발자로서의 경험은 상대적으로 놓치게 됩니다. 자칫 평생 혼자 개발해야 편한 개발자가 될 수도 있습니다. 실패에서 얻는 것도 있지만 잃는 것도 크다는 것을 명심해야 합니다.

소프트웨어 개발자로서 사회에 첫발을 디뎠다면 아무리 대학때 소프트웨어를 좀 개발해 봤어도 조직에서 팀을 이뤄서 개발하는 방법과 그 문화를 어느정도 익히는 것이 필요합니다. 물론 좋은 환경의 소프트웨어 회사라야 하겠죠. 그리고 나서도 확신이 선다면 시도해볼 수 있는 도전이라고 생각은 합니다. 하지만 결코 기존의 소프트웨어 환경에 비하여 성공확률이 더 높아졌다고 생각해서는 안됩니다. 이또한 노력하는 사람에게 더 많은 기회를 제공할 겁니다. 자신의 성공확률에서 바뀐 것은 아무것도 없습니다.

이 상황을 너무 부풀려서도 너무 축소해서도 안됩니다. 확실히 기회가 생긴 것은 맞습니다. 하지만 냉철한 가슴으로 생각하고 도전해야 합니다. 또, 이를 이용해서 부추기는 선정적인 기사는 좀 줄어야 하겠습니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by Mykl Roventine
저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 개발자, 대박, 문화, 버그관리, 소스관리, 스마트폰, 스펙, , 앱스토어, 유지보수, 중박

  1. Blog Icon
    지니랜드

    수구대토 -> 수주대토 로 수정해주세요

  2. 감사합니다. 블로그 글은 종종 오타가 생기더군요. 좀더 꼼꼼히 적어야 하는데요...

  3. Blog Icon
    ㅎㅎㅎ

    제 생각엔 스마트폰 초창기(아이폰으로 인해 시장이 커지는)라서
    거품에 있고 사람들이 스마트폰에 대한 환상을 가지고 있는 것같습니다.
    손바닥만한 화면으로는 분명 한계가 있는데요...
    결국 단지 개인의 필요에 따라 몇몇 특정한 기능으로만 사용하게 될거고
    꼭 이동시 사용해야하는 사람만 사용할텐데
    꼭 만능기기인것처럼 여겨지는 분위기네요.
    PMP있지만 돌아다니며 영화보는 사람 별로 없고요
    네비있지만 네비들고 다니며 걸어가는 사람 없습니다.
    전화기로 엠피스리 들을수있지만
    따로 엠피스리를 가지고 다니는 사람들이 대부분이죠.
    만능기기는 불편하고 이동기기도 또한 불편하죠.
    이동하며 사무를 볼 수있다지만
    이동하면서 까지 사무보고 싶은 사람이 몇이나 있겠어요.
    오히려 전화기능과 카메라기능을 첨가하고
    터치기능을 넣은 OS를 가진 스펙이 강화된
    타블렛식으로 LCD를 뒤집을수있는
    10인치내의 화면을 가진 노트북이 나오면
    스마트폰 시장은 죽을 것같네요.ㅣ

  4. 제 생각은 좀 다릅니다.

    스마트폰의 파급효과는 생각보다 클 것 같습니다. 지금은 거품이라고 얘기하지만 거품이 꺼지면 실체가 보일겁니다.
    지금은 인터넷 없는 세상 생각하기 힘들죠? 스마트폰은 인터넷을 들고다니게 되는 세상입니다. 한단계 업그레이드 되는 겁니다. 기존에도 이동중에 인터넷을 사용할 수 있었지만, 편리함이 다르죠.
    스마트폰이 화면이 작기는 하지만 새로운 UX가 불편함을 감소시킬 것이고, 자연스럽게 생활속으로 파고들 것으로 예상하고 있습니다.
    인터넷(웹)이 나오고나서 일상 생활속을 들어오는데까지는 6,7년이 걸렸습니다. 스마트폰이 나온지는 꽤 됐지만, 전 아이폰과 안드로이드 폰이 나오고 완전히 생활속으로 들어오는데, 3,4년이면 충분하리라고 봅니다. 그사이에 사람들을 편리하게 해주는 앱들이 쏟아져 나오겠죠.

    누가 옳든 간에 이쪽 밥 먹고 사는 사람들은 남들보다 빨리 알아채야 겠죠. 버스 떠난 다음에 손흔들면 안되니까요... 일반 사용자라면 자신이 좋은 것 그냥 선택하면 될거구요. ^^

  5. 저도 '현혹'의 성격이 짙은 글을 보면 비판적인 시각으로 바라보려 하고 있습니다.
    이슈에 대해 여과 하지 않고 우르르 몰렸다, 우르르 파했다~ 하는 것만 봐도 매우 급변하는 IT정세와,불안정한 시국을 그대로 나타내주는 것이니까요. 이런 정세에 본질을 파악하기란 매우 어렵겠지만.. 지금 우리에게 필요한 것은 비판적인 시각이 아닐까 합니다. 예를들어.. 전규현님이 말씀하신 것처럼 요즘 모바일 쪽의 구인란을 보면 모바일 개발 경험이 有인 사람에 국한되어 있더군요. 참 안타까운 일입니다. 매우 좁게 시장이 형성되는 것도 문제이고, 장기적인 안목이 아닌 '언 발에 오줌누기 식'의 인력들만 채용하고 있으니까요. 본질을 따져서 설계와 구조에 중점을 둔다면 당연히 OO나 OOP관련 경험,또는 공학방법론을 사용해봤던 인재 위주로 형성이 되어야 하는 것이 맞다고 봅니다. 그 밑에 코딩할 인재들도 필요한 것이구요.
    이 단면에서 돈만 되면 한다는 식의 불안정한 정세를 다시 한번 엿볼 수 있었습니다.
    (요즘 스마트폰 애플을 취미삼아 해 보고 있습니다.--단지 취미입니다. 주업은 아니죠. 전에 GUI방식의 소프트웨어를 개발한 경험이 있다면, 예전 방식과 매우 닮아 있다는 것을 느끼고 맙니다.)

    팀과 인력조화에 대해서도 한가지 문제점을 제시하자면.. 서로 잘 아는 팀을 만들 수 없는 문화가 한 몫하는 것 같습니다. 회사마다 계약 체제가 다르고 관리제도가 다르니 문화가 다를 수밖에 없고, 하청구조가 이미 뿌리박힌 데다가 같은 회사사람이 누군지도 모른 체 프로젝트가 진행되고 있는 곳도 상당히 많습니다. 어떤 회사는 갑 측에 같은 비용으로 50만 제공해주어도 되지만, 어떤 회사는 같은 비용에 200을 요구하는 곳이 있더군요.

    얼마 전에 선임연구원으로 혼자 들어갔었던 프로젝트가 바로 이것과 비슷했습니다. 돈을 더 많이 주니 더 많은 아웃풋을 내야 한다는 묵시적, 강제적 계약조건이더군요. 설계,구조.. 전혀 신경을 안 쓰고 제품의 품질과는 전혀 상관없이 높은 비용(그렇게 높지도 않지만)을 주니 설계 제외하고 더 많은 아웃풋을 내라..라는 SI특유의 병폐를 또 다시 한번 경험했습니다.(아웃풋에 계약조건으로 차등을 주니 사실상 팀웍이란 잠점을 발휘할 수도 없을뿐더러 활용할 수도 없는 문화가 되어버립니다.)

    사실 노하우있는 기술자를 쓰는 이유는
    소프트웨어가 필요한 곳에 경험과 노하우,설계,구조론,방법론을 오히려 배우기 위한 것으로 생각합니다. 그것이 경험 있는 기술자들을 쓰는 이유가 아닐까 합니다.
    5년 차가 10장찍어내고 10년 차가 같은 시간에 20장을 찍어내라는 식이니..원..(이런 곳 정말 많습니다.) 상식적으로 매우 미달인것이죠.

    전 지금 병원에 입원해 있는데도.. 규현님의 글은 읽어 봅니다.:)

  6. moova님 안녕하세요.

    병원에 입원해계시고 수술이 필요하신 것 같은데 쾌차하시기 바랍니다.
    우리나라의 대부분의 회사에서는 고급개발자를 키울지도 모르고 구분할줄도 모르고 고급개발자가 무슨 일을 하는지도 모릅니다. 그만큼 낙후되어 있습니다.

    소프트웨어 개발에 있어서 무슨일이 싼일이고 어떤게 비싼 일인지 구분도 못합니다. 그래서 비용과 시간이 더 많이 들며서도 날밤까면서 일해도 좋은 제품이 안나오죠.

    또 무엇이 필요한 문서인지 어떤 것은 형식적이고 필요가 없는 것인지도 구분하지 못합니다. 이는 프로젝트마다 달라서 선임급(고급)개발자가 이런 것들을 프로젝트 성격에 맞게 합리적으로 결정해야 하는데 그렇게 하지도 못하게 하는 것이 현실입니다.

    moova님도 고생이 많겠습니다. moova님 글들을 보면 어떤 생각과 경험을 가지고 있는지 알 수 있거든요. 저는 언제나 미래에 기회가 되어서 제 블로그를 찾아주시는 분들 중에서 뛰어난 분들과 일해보는 것을 꿈꿔 보곤 합니다.

    감사합니다. 다시 한번 쾌차를 기원합니다.

  7. 스마트 폰이 상당부분 생활을 바꾸긴 하겠지만, 그렇다고 해서 삶을 스마트하게 바꾸어 줄꺼라고 생각하지는 않습니다. 상당 부분 거품도 있고 허세도 있기 때문이죠.

    문득 지하철에서 보이는 아이폰 유저들을 보면
    "게임", "동영상" 정도 밖에 안보이더군요.
    일부 헤비유저일 것으로 예측되는 증권이나 금융 개발쪽 분들이 눈에 띄지 않는 걸지는 모르겠지만
    결국에는 PMP + PSP + NDS 를 통합한 그 이상도 그 이하도 아닌 딱 게임기+휴대폰 이라는 느낌이 강합니다.
    단지 인터넷이 될뿐이고, 외부에서도 편하게 할수 있을 가능성이 있기 때문에 사용자들이 끌리는거겠죠

    솔찍히 말해서 저도 쓸모는 없지만 가지고는 싶습니다.
    '필요'하지도 않고 '용도'도 정해지지 않았지만 가지고는 싶습니다.
    아마도 이러한 경우에 단지 새로 나온 스마트 폰이고 다들 아이폰 아이폰 하니까 얼리어탑터 기분으로
    대세(?)를 따라 나도 스마트하게 스마트폰! 하는게 아닐까 생각이 됩니다.

    결론만 말하자면, 지금보다 상당부분 거품이 심하게 끼어있고, 비록 어느정도 삶을 변화 시킬지라도 생각보다 큰 변화를 일으키지는 못할것이라는 겁니다. 원더키디가 나올때까지 10년도 채 안남았고, SF영화에서 그리던 2000년은 차들 대신에 무빙워크 에 서서 다니는 그런 환상적인 세상이었는데 실질적으로 변한 삶의 패턴은 극히 드물듯이 말이죠.

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

    현재 거품이 꺼지고 좀 차분해져야 실체가 나올 것 같습니다.
    "알고 봤더니 별거 아니더라"라는 말도 많이 나오겠죠. 그러면서 서서히 생활속으로 들어와서 조금씩 생활패턴을 바꾸겠죠. 이게 뭐 엄청난 변화냐? 라고 할 수도 있어도 지금도 인터넷(특히 웹) 없이도 사는 사람이 엄청나게 많지만 많은 사람은 인터넷 없는 세상은 상상하기 힘듭니다.
    처음에 웹이 나왔을 때 되는게 없었습니다. 이걸로 뭐를 할 수 있을지 제대로 상상한 사람도 별로 없었습니다. 그때는 기껏해야 회사 소개하는 홈페이지와 인터넷 신문정도 였습니다. (여담이지만 95년에 제가 세계 최초 상용 Webmail 시스템을 만든 사람이지만 이를 기억하는 사람은 아무도 없습니다. 세계최초 별거 아닙니다. - -; 저는 별로 크게 성공하지도 못했구요. 제가 만든 Webmail을 컨셉과 원형을 따라서 만든 D사는 크게 성공했죠)

    94년에 웹이 처음 나왔을 때는 이것이 생활을 바꿀 것이라고 생각한 사람은 극소수였습니다. 그런데 스마트폰은 얼마 되지도 않았는데 난리네요. 그래서 거품이 꺼져야 한다는 얘기입니다. 반대급부로 이쪽 개발에 종사하는 개발자들은 거품이 더 좋은 기회가 되기도 합니다만...

    스마트폰이 바꾸는 생활의 변화를 가져오는 것의 주역은 하드웨어가 아닌 소프트웨어라고 생각합니다. 얼마나 좋은 소프트웨어가 더 많이 나오냐에 따라서 결론이 달라질 것 같습니다. 이는 소프트웨어 개발자들이 몫이겠죠. 구차니님 같은 분들이 바꾸는 것이라고 생각합니다.

    설령 기대에 못미칠 수는 있어도 소프트웨어 개발자라면 과소평가보다는 창조자의 마인드로 동참하는 것이 필요하다고 생가가합니다.

  9. 스마트폰에 대해서 갖는 부정적인 시각은, 사용자가 아닌 개발자의 시선에서 바라봐서가 아닌가 싶습니다.
    제가 느끼는 스마트폰은 저에게 있어서는 혁명이었습니다.
    96년부터 PC통신 하이텔을 통해서 커뮤니티에 입문했는데요, 그 이후로 제 삶속에는 항상 인터넷이 있었습니다.
    어딜가도 컴퓨터가 있으면, PC통신에 접속하고, 그 이후에는 인터넷에 접속해서 현재 저의 동호회, 카페, 홈페이지, 블로그 등을 보며 실시간으로 글을 게시하고, 댓글놀이를 즐겨왔는데요, 스마트폰은 이런 소셜 네트워크에 한층 가깝게 다가갈 수 있도록 해주는 중요한 역할을 해주고 있거든요.
    인터넷이 연결되어 있지 않았을 때의 불안감이나 답답함을 한번에 해결해주고 있습니다.

    집전화가 있고, 공중전화가 있지만, 누구나 휴대폰을 가지고 다니듯이, 요즘 우리 생활에 있어서 인터넷이 그렇게 변하고 있습니다. 스마트폰은 걸어다니는 인터넷 기능때문에 중요한 것이죠.
    다만 인터넷 기능이 필요하지 않으신 분들께서, 스마트폰을 필요해서 자발적으로가 아닌 뜬다고 하니까 공부하시려는 분들께서 부정적인 시각으로 말씀해주시는 것 같은데요, 크게... 변화를 줄 것 같아요.

    자다가 일어나서 갑자기 말이 많았습니다. 또 놀러올겠습니다. ^^

  10. Blog Icon
    샘성맨

    회사를 그만두고 앱 개발 창업을 준비하고 있는 사람으로서 research 도중 오랜만에 좋은 글을 발견한것 같아 기쁩니다.
    진입장벽이 낮은 앱 개발은 정말 개발자의 한사람으로서 전업으로 뛰어들기전에 가장 생각이 많아지는 부분입니다. 그리고 유지보수얘기를 쓰셨던데, 시장조사도중 많은 대다수 앱개발자들이 개발은 해놓고 테스트 및 유지보수같은건 신경쓰지 않는걸 볼 수 있더군요. 정말 공감가는 부분입니다. 이런 부분을 고려한 비즈니스 모델도 생각중입니다. 그리고 혼자개발하는것에 대한 한계성 또한 매우 공감갑니다. 몇몇의 인재와 함께하면 좋겠는데, 우리나라같이 대기업만 밝히는 분위기에서 벤처에 누가 쉽게 열정을 쏟으려고 할까요 솔직히 아직 회사를 그만둔건 아닌데(저도 분위기상 대기업을 왔습니다만..), 이 부분에 대해서 상당히 두렵네요. 하지만, 돈만을 위한 개발이 아닌 첫사랑을 다시 만나 연애하는 기분으로서 다시 개발을 시작한다면 어느정도의 생활은 가능할꺼라 점점 확신이 듭니다. 그 첫사랑을 지금 시대흐름이 아니면 다신 볼 수 없을것도 잘 알고 있습니다. 또한 스마트 TV 라는 블루오션시장도 보이고요. 아직 절망보다는 희망이 많아보입니다. 첫걸음부터 큰걸음을 내딪지말고 3번의 시련을 각오하고 희망을 향해 몸을 던지렵니다.

  11. 안녕하세요. 샘성맨님
    도전은 항상 아름답니다. ^^ 도전이 소프트웨어 발전의 힘입니다.
    혼자 소프트웨어를 개발하는데는 많은 어려움이 따릅니다.
    앱센터를 이용하면 도움이 좀 될 수 있을 것 같습니다.
    앞으로 도전하시는데 도움이 필요하면 부담없이 연락주세요.
    도움을 드릴 수 있으면 기쁘겠습니다.

SRS에 대한 인식의 변화

2009.11.13 23:46 by 전규현


잠시 후 Google blogger로 이동됩니다.




 
그 동안 본 블로그를 통해서 소프트웨어 개발에서 SRS(Software Requirements Specification)가 얼마나 중요한 역할을 하는지에 대해서 수 차례 역설한 적이 있습니다.

2009/08/03 - [프로젝트/요구사항분석] - 이건 기능이 아닌데
2009/07/30 - [프로젝트/요구사항분석] - 고객이 요구사항을 너무 자주 바꿔요.
2009/05/04 - [프로젝트/요구사항분석] - Track me, if you can
2009/04/22 - [프로젝트/요구사항분석] - 개발자들이 바글바글한 외딴섬에 떨어진다면
2009/02/12 - [프로젝트/요구사항분석] - 요구사항 분석의 출발점
2009/02/04 - [개발프로세스] - 소프트웨어 개발 단계에서 가장 중요하다고 생각하는 것은?
2009/01/29 - [소프트웨어이야기] - Head First Software Development 리뷰
2009/01/21 - [프로젝트/요구사항분석] - UI Mock-up
2009/01/20 - [프로젝트/요구사항분석] - 샘플만 보여주세요.
2009/01/19 - [프로젝트/요구사항분석] - 그냥 쓸 수 있겠네요.
2008/11/19 - [프로젝트/요구사항분석] - SRS(Software Requirements Specification)의 중요성
2008/11/03 - [소프트웨어이야기] - 프로젝트 산출물을 프로젝트 종료 후에 만들고 있나요?

지금까지는 SRS라는 용어조차 한번도 들어본 적이 없는 소프트웨어 개발자나 관련자들이 많았었습니다. 하지만 이제는 조금씩 SRS라는 용어에 대해서 알기 시작하는 것 같습니다. 또 소프트웨어 개발에서 있어서 요구분석이 왜 중요한지에 대해서 조금씩 인식해가는 것 같습니다.

그 예로 최근에는 정부에서도 소프트웨어 기업들의 경쟁력 강화, 특히 해외 시장 진출 시 경쟁력 확보를 위해서SRS 작성을 중요한 요소로 보고 정부 지원 과제에 포함을 하고 있습니다.
이러한 과제에 평가위원으로 참석을 해보니 아직은 많은 소프트웨어 회사들이 분석능력을 제대로 갖추고 있고, SRS를 잘 쓸 수 있는 역량을 갖췄다고 보기는 어렵습니다. 하지만 제대로 된 소프트웨어를 짧은 시간에 개발하기 위해서는 분석을 제대로 하여 SRS를 작성하고 SDP를 만들어야 한다는 것을 인지한 것만으로도 큰 변화라고 볼 수 있습니다. 필요성을 인식하는 것이야 말로 변화가 가능하게 하는 원동력입니다.

다만, 문제는 분석을 잘해야 한다는 것, 즉 SRS를 잘 써야 한다는 것을 인식하고도 SRS를 잘 적는 방법을 배울 곳이 없다는 것입니다. Software 선진국에서는 수십년 간 개발자들이 SRS를 써 왔기 때문에 서로 Template는 조금씩 달라도 개발자로서 일을 하는 동안에 계속 접해 왔고, 써왔기 때문에 따로 배우고 말 것도 없이 SRS를 쓸 줄 알게 되었습니다. 물론 모든 개발자가 SRS를 다 제대로 쓸 줄 아는 것도 아니고 그럴 필요도 없지만, 소프트웨어 프로젝트를 시작할 때 누군가가 SRS를 작성하고 관련자들과 리뷰를 하는데 전혀 문제가 없습니다. 

하지만 이제 시작인 우리나라는 배울 곳도 없고, 스스로 연구하고 공부해서 작성하기에는 요구분석이라는 분야 자체가 너무 어렵습니다. 그 동안 여러 회사에서 스스로 작성했다고 하는 SRS를 분석해보면 합격점을 줄 수 있는 것은 거의 전무했다고 해도 과언이 아닙니다. 그렇다고 미국 회사에 가서 몇 년 배우고 오기도 어려운 실정입니다. 또, 국내에서는 학교나 학원에서 배울 수 있는 환경도 되지 않습니다. 그렇게 배운다고 해도 몇몇 기법만 배우고 핵심은 파악하지도 못하게 됩니다. 그 이유가 대부분의 교수나 강사가 소프트웨어 프로젝트에서 실제로 SRS를 써본적이 거의 없이 이론적으로 배운 정도이기 때문입니다. 실제 프로젝트에서 SRS를 제대로 써본 경험을 많이 가지고 있는 경험자와 같이 SRS를 써보면서 꾸준히 배워 나가는 것이 가장 적절한 방법입니다.

물론 몇몇 개발 방법론에서는 SRS를 작성하지 않습니다. 하지만 이러한 방법론에서도 스펙이 필요 없다고 하는 것은 아닙니다. 다만 스펙을 바라보는 관점과 적는 방법이 다를 뿐입니다. 따라서 스펙의 개념을 정확하게 알고 SRS를 잘 작성할 줄 아는 개발자들이라면 스펙의 형태가 테스트케이스가 되든 어떤 다른 형태가 되든 문제는 없습니다. 즉, 소프트웨어 분석역량이 문제입니다. 

분석역량의 부족은 부실한 스펙문서를 만들게 되고 이는 설계, 구현 기간에 많은 혼란과 재작업을 초래하고 출시 후에도 유지보수 비용을 크게 증가시킵니다. 그 동안 우물 안 개구리처럼 내수시장에서 소수의 개발자를 데리고 고객이 원하는 대로 뚝딱 만들어서 장사를 했는데, 소프트웨어 볼륨이 커지고 해외 시장에 진출을 하려니까 딱 벽에 부딪히는 겁니다. 이 과정에서 무리하게 해외 진출을 추진하다가 유명을 달리한 회사들이 상당히 많습니다. 그렇다고 세계 시장의 1%밖에 안되는 국내 SW시장에서만 놀기에는 국내 시장은 너무나 작습니다. 왠만큼 성장한 회사라면 해외 시장 진출의 유혹을 떨처버리기 어렵습니다.  

물론 SRS, 스펙, 분석능력이 이 모든 것을 해결해주지는 않습니다. 하지만, 가장 중요하고 핵심적인 요소라 확신합니다. 이는 저만의 주장이 아니고 제가 존경하는 수많은 실전 소프트웨어 전문가들의 주장이기도 합니다. 그러한 맥락으로 앞으로 SRS, 스펙, 분석역량 향상에 대한 글을 종종 올려보려고 합니다. 블로그를 통한 지식전달이 얼마나 효과가 있겠는지 의문은 들지만, 필요성에 대한 인식만 생기더라도 글을 올린 보람을 있을 것으로 생각됩니다.

이와 관련된 궁금증, 의견, 경험, 고민거리, 정보, 아이디어 등 어떤 것이라도 같이 교환하고 싶습니다. 댓글이나 방명록, 메일로 얼마든지 보내주세요. 제가 해결해드릴 수 있는 것은 해결해드리죠.
그리고 교육을 받고 싶으신 개발자나 회사라면 연락 주시기 바랍니다. 제가 여건이 되는 한도내에서는 많은 소프트웨어 개발자들에게 전달하고 싶습니다.

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

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

전규현 프로젝트/요구사항분석 SRS, 분석, 스펙, 요구분석, 정부과제

  1. 최근 프로젝트 진행하면서, 요건정의서 / 주요화면 정의서만 가지고 프로젝트를 수행했었습니다. 유사 경험이 있으니 잘 되겠지라구 약간은 자만하면서요..

    하지만 관련 분야 업무를 처음 해보는 사람들과의 협업/구현하면서 문제가 하나둘씩 생겨나기 시작하고, 주기능 보다는 당연히 될거라고 생각했던 부기능에서의 생각의 차가 너무 컸고, 결국 Rework을 하게 되더군요.
    확실히 일은 정석대로 해야한다고 SRS 로 시작했으면 좋았겠다는 후회가 나중에 들더라구요...

    좀 부끄러운 경험담이지만.. SRS 중요성/초기 설계의 중요성을 깨닿게 했던 중요한 교훈이었던 것 같습니다.
    전규현 수석님.. 블로그글 잘 공감하고 있습니다. 감사합니다.

  2. Peter님 안녕하세요.
    실제로 제가 다른 개발자들이 작성한 여러 SRS를 검토해보면 비기능요구사항이 주로 부실하게 작성되어 있더군요. 하지만 비기능요구사항이 SRS에서 더 중요하다는 것을 잘 인식하지 못합니다. 기능이 하나 잘못적힌 것은 일반적으로 해당 모듈만 수정하면 되지만, 비기능요구사항 하나 누락되거나 잘못 적힌 것은 시스템 전체를 다 뜯어 고쳐야할 정도로 큰 사건일 수 있습니다. 앞으로 블로그에서 이와 관련된 다양한 내용들을 다룰 계획입니다.

  3. 개발자들도 이러한 개발의 효율을 위한 절차를 받아 들여야 하지만
    그에 못지 않게 개발을 위탁하는 사람도 개발에 대한 이해가 널리 퍼졌으면 좋겠다는 생각이 듭니다.

    이러한 프로세스 없이, 중간에 계속 수정을 요구하고 이에 따른 추가기간을 정산하지 않으면
    개발자 역시 무상으로 계속 지치게 되니 말이죠. 물론 인간이라 처음부터 완벽하게 SRS를 만들어내서
    한번에 만들수는 없기에 어느정도 변경사항이 생기겠지만, 디자인이 마음에 안들어요 이렇게 바꾸어 주세요
    라고 하는건 개발 위탁하는 사람역시 이러한 개발의 과정중 하나로 넣어 교육을 시켜야 하지 않을까?
    라는 생각마저 들게 합니다.

  4. 구차니님 안녕하세요.
    말씀 하신 것처럼 처음부터 스펙을 완벽하게 다 정하고 프로젝트 끝날 때 까지 절대 바꾸지 않을 수는 없습니다. 그래서 어차피 바뀌니 대충 시작하는 것은 더 문제가 크죠.
    개발자나 고객이나 모두 스펙에 대한 이식의 변화가 필요하겠죠. 또한 교육, 훈련과 경험 모두가 필요하고 1,2년에 해결될 문제는 아니라고 봅니다.

  5. Blog Icon
    김경록

    좋은 글 잘 읽고 갑니다.
    ^^

  6. 김경록님 오랫만입니다.
    댓글 남겨주셔서 감사합니다. 항상 건강하세요.

  7. IT 관련 무엇인가를 찾다보면 이 블로그로 들어오게 되는 듯 합니다. ^^; 새로운 프로젝트를 하는데 아무래도 불가능에 도전해보아야 할 것 같습니다. 갈수록 괜찮은 SRS가 나오겠지요. 혹시 괜찮은 Template 있으시면 하나 던져주시면 고이 잘 받아먹겠습니다. 굽신굽신~

  8. Google에서 Software Requirements Specification으로 검색을 하면 여러 Template를 찾을 수 있을 겁니다. 하지민 Template 만 보고 제대로 적는 다는 것은 불가능합니다. 타이거우즈 골프채만 보고 타이거우즈처럼 골프치는 것을 흉내내려는 것과 같습니다.
    소프트웨어에서 가장 어렵고도 중요한 것이 바로 무엇을 개발할지(스펙)을 적는 것이지요.

  9. 좋은 글 잘 읽고 갑니다 ^^ 현재 컴퓨터공학 전공하는 3학년 학생입니다~
    소트프웨어 공학 과목을 공부하면서 요구사항 분석 부분에 어려움이 있어
    관련 자료를 찾다가 방문하게 되었네요!
    종종 들러서 좋은 글 자주 읽도록 노력하겠습니다.

  10. 안녕하세요. 임수빈님
    소프트웨어 공학은 배울수 없다고들 합니다. 즉 경험을 통해서 익힐 수 밖에 없다는 뜻. 하지만 배우는 것은 나중에 경험을 할 때 큰 도움이 됩니다.
    그중에서도 가장 어려운 분야가 요구사항 분석입니다.
    이론적인 것 만 가지고 실제 프로젝트에서 제대로 적기는 정말 어렵습니다.
    열심히 배우시고 실전에 적용하시기 바랍니다.

  11. Blog Icon
    이해승

    안녕하세요. SI 분야에서 일한지 15년이 넘어가면서 제대로 된 SRS 작성해 본 기억이 별로 없습니다.
    어디서 배워야 할지도 모르겠구요...소프트웨어 공학, 다양한 프로젝트 관리 기법 등등 안해 본 경험이
    별로 없음에도 불구하고 여전히 제대로 된 SRS 작성하는 것에 목 말라 하고 있습니다.
    어떻게 시작해야 좋을까요?

  12. 이해승님 안녕하세요.

    가장 어려운 질문 중 하나입니다. "어떻게하면 SRS를 잘 쓰는 법을 배울 수 있을까?" 어떻게 하면 SW를 잘 개발할 수 있을까와 거의 동격의 질문이기도 합니다.
    또는 어떻게 피아노를 배울 수 있을까?와 비견되기도 합니다.
    오랫동안 SW를 개발해왔던 개발자라고 하더라도 SRS를 작성하는 것, 즉 스펙을 작성하는 것은 여전히 어려운 과제입니다.

    제일 좋은 것은 스펙을 잘 작성하고 있는 회사에 가서 일하면서 자연스럽게 배우는 것입니다. 우리나라에는 그런 회사가 별로 없으니 실리콘밸리로 가야합니다. 현실성은 없죠.

    다른 방법으로는 전문가나 경험자에게 배우고 직접 작성을 해보고 리뷰받고 이런 과정을 반복하면서 배우는 방법입니다.

    그렇지 않고 책을 보고 스스로 해보는 방법은 시행착오를 많이 겪어야 하고 영원히 제대로 작성하믄 방법은 못배울 가능성이 거의 100%입니다.

    가장 좋은 방법은 회사에서 전문가를 데려와 주는 것이겠죠.

    우선은 제가 쓴 "소프트웨어 개발의 모든 것"이라는 책을 먼저 보세요. 이해를 돕기 위한 설명이 좀 되어 있습니다.

우리는 개발자가 테스트도 다 해요.

2009.08.09 21:10 by 전규현


잠시 후 Google blogger로 이동됩니다.




별도의 테스트팀이 없는 회사는 정말 많습니다.

별도의 테스트팀이 없이 개발자가 또는 팀장이 테스트에 참여하는 이유는 개발자가 아니면 제품의 기능을 속속들이 알 수 없어서 테스트를 하기가 어렵기 때문입니다. 이렇게 되는 이유는 제품의 스펙이 따로 문서화되어 있지 않기 때문에 개발자가 아니면 스펙을 알지 못하기 때문입니다.

하지만, 개발자는 인건비도 비쌀 뿐더러 테스트를 잘 하지도 못합니다. 그리고 아무리 테스트 능력이 있는 개발자라고 할지라도 자신이 작성한 기능을 테스트 하는 것은 좋은 방법이 아닙니다. 본인은 내부 동작방식을 잘 알기 때문에 기능이 정상적으로 동작하는 방식 위주로 테스트를 하기 마련입니다.

테스트는 반복적이고 전문적인 작업이기 때문에 개발자가 담당하고 있는 이상 정상적으로 이루어지고 있다고 보기 힘듭니다. 

테스트팀을 따로 두기 위해서는 기본적으로 제품의 스펙이 있어야 합니다. 그렇지 않다면 테스트 팀은 그냥 Random 테스트를 마구 해주는 아르바이트생 수준의 역할 밖에 할 수가 없게 됩니다. 실제 수많은 테스트 팀들이 그 정도 수준에서 밖에 테스트를 할 수 없는 열악한 상황에서 일을 하고 있습니다.

기본적으로 제품에 스펙이 존재를 해야 이를 토대로 테스트케이스를 만들어 낼 수 있고, Regression Test가 가능해 집니다. 그리고 테스트팀이 있다면 테스트 자동화에 대해서 좀더 연구를 하게 되고 테스트 효율성을 높이기 위한 작업들을 진행할 수 있습니다.

테스트팀을 두는 것이 비용을 줄이면서도 제품의 품질을 높일 수 있는 방법입니다. 개발 조직을 효율적으로 운영하고 싶으면 전문 테스트팀에 대해서 심각하게 고려해봐야 합니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
(image by cobalt123)
저작자 표시 비영리 변경 금지
신고

전규현 개발조직 스펙, 테스트, 테스트케이스, 테스트팀

  1. 확실히 자기의 잘못을 자신이 알 수 없듯, 테스트는 작성자가 해서는 안된다는 사실에 매우 공감합니다.

    그래서 가끔은 전혀 모르는 사람에게 그냥 써봐~ 라고 하면서 던져줘보곤 하죠 ㅋ

  2. 구차니님 안녕하세요.
    그것도 테스트 방법 중 하나죠. 그 방법이 유일한 방법은 아니겠죠?^^

이건 기능이 아닌데

2009.08.03 23:14 by 전규현


잠시 후 Google blogger로 이동됩니다.




의례 스펙, 기능요구사항 등을 정리한 문서를 보면 기능만 잔뜩 나열되어 있는 것은 매우 흔한 일입니다.
소프트웨어를 만든다고 하면 구현해야 할 기능만 알면 제대로 잘 만들 수 있을 것으로 생각하기 십상입니다. 상식적으로 생각해도 기능면 제대로 구현하면 되겠지요. 여기에 UI는 살짝 추가하고요.

하지만, 분석을 할 때 기능보다 더 중요한 것이 비기능 요구사항입니다. 즉, 기능은 아닌데, 요구사항 즉, 스펙인 겁니다. 기능이 중요하기는 하지만, 기능 하나가 잘못되면 이를 고치는 것은 그렇게 어렵지 않습니다. 그런데 비기능에서 잘못되면 소프트웨어를 완전히 뒤엎어야 하는 일이 발생할 수도 있습니다. 

이렇듯 비기능이 기능보다도 더 중요한 측면이 있는데, 눈에 바로 보이지 않는 다는 이유로 간과되기 쉽습니다. 그럼 이렇게 중요한 비기능 요구사항에는 어떤 것들이 있는지 몇 가지만 알아 보겠습니다.

첫째 성능입니다. 소프트웨어가 얼마나 빨리 반응을 보이며 단위 시간당 얼마나 많은 데이터를 처리해야 하는지 정의해야 합니다. 또한 이를 검증하기 위한 기준도 마련이 되어야 합니다.

둘째 안정성입니다. Database와 위젯 시계는 요구되는 그 안정성이 다릅니다. Database는 시스템이 정전이 되어도 데이트가 파손이 되어서는 안됩니다. 그러한 안정성을 보장하기 위한 요구사항도 자세히 기술이 되어야 합니다.

셋째 보안입니다. 데이터는 암호화 되어서 저장이 되어야 하는지? 암호키는 어떻게 보관을 하는지? 프로토콜은 암호화 되어야 하는지? 시스템은 인증을 거쳐서 접근해야 하는지? 등등의 보안 요구사항은 각 소프트웨어마다 다른 요구사항을 가지고 있습니다.

그 외에도 많은 비기능 요구사항은 있습니다. 가용성은 시스템이 24시간 동작하는 것인지 MS-Word처럼 필요할 때 사용하고 종료하는 것인지 기술합니다. 또, 이식성은 현재 지원해야 하는 것이 아니고 향후 미래에 Porting을 하기 용이하도록 만들기 위한 요구사항입니다. 미래에 Windows에서 Linux로 포팅을 할 수도 있고, 여러 언어를 지원하도록 확장할 수도 있습니다. 또 64bit를 지원할 수도 있고, Unicode를 지원하게 될 수도 있습니다. 따라서 미래에 어떻게 할지 계획이 아무것도 없다면 이식성을 정의할 수가 없습니다. 다국어, 개발표준, 메모리 사용제한, 소스코드 재사용성, 유지보수 편의성 등 많은 비기능 요구사항이 있습니다.

딱 보시면 아시겠지만, 하나하나가 잘못 적히면 완전히 소프트웨어 전체를 뒤집어야 하는 것들입니다. 이런 것들이 눈에 보이지 않는다고 기능만 보고 제품을 만들었다가는 앞은 안보고 땅만 보고 달리는 자동차와 같습니다. 조금만 고개를 들면 보이는 막다른 골목으로 가고 있을지도 모릅니다.

기능 신경쓰기도 바쁜데 이러한 수많은 비기능까지 어떻게 신경을 써서 만드냐고요?
그럼, 신경 안쓰고 그냥 만들면 그 요구사항이 사라지나요? 무시된겁니다. 요구사항을 고스란히 남아 있고 나중에 비용을 수십,수백,수천배를 치러야 합니다.

비기능 요구사항을 잘 적는 방법은 그러한 비기능 요구사항에 대하여 경험이 있을 수 있도록 소프트웨어를 개발한 상당한 경력이 필요하고, 적는 방법에 대하여 배우거나 학습이 필요합니다. 또, 이런 과정을 통해서 과거에 간과된 비기능 요구사항이 현재 얼마나 많은 손해를 끼치는 깨우치면서 배워나가게 됩니다. 하지만 이런 과정을 거쳐야 시행착오가 최소화 되지, 비기능 요구사항을 고려하지도 않는다면 항상 바쁘고 앞으로 잘 나아가지 못하는 굴레를 벗어나기 어려울 겁니다.

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/요구사항분석 기능, 보안, 분석, 비기능, 성능, 스펙, 안정성

  1. 비기능이라고 해서 무슨 개념인가 했는데
    정말 기능보다 더 중요한 내용들이군요.

    그나저나.. 멀티플랫폼은 개발자의 악몽이죠 ㅋ

  2. 구차니님 안녕하세요.
    멀티플랫폼 개발을 하고 있다면 중요시 되는 비기능들이 더욱 많죠. 멀티플랫폼은 개발, 빌드, 테스트에 더 많은 시간은 들어가지만 익숙해지면 크게 문제 없지 않나요? 개발자에게는 좋은 경험이죠.

  3. 기능제공을 잘 하는 것도 중요하지만 RFP를 잘 분석하고 클라이언트와 미팅을 잘해서 리스크가 될만한 것들을 모두 정리한 다음에 명확하게 계약서와 SoW를 작성해서 '사인 받는게' 중요한 것 같습니다.

    그러지 않으면 끝없이 이어지는 고객의 추가요구사항을 감당해 낼 수가 없지요.

    특히 개발자들이 약한 부분이 클라이언트와의 미팅 후 회의결과 정리 및 쌍호간 확인싸인 하기, 이거 정말 중요합니다.

  4. 우울한딱따구리님 안녕하세요.
    우리나라 고객들은 왠만하면 사인을 잘 안하려고 하지만, 그래도 회의록 작성하고 사인하고 사인하지 않더라도 배포만 하는 것도 나름 효과는 있죠. 계약할 때 SRS와 ATP를 첨부하는 외국과는 아직 거리는 멀죠.

도대체 얼마나 자세히 적어 달라고?!

2009.06.29 23:58 by 전규현


잠시 후 Google blogger로 이동됩니다.




소프트웨어 개발자들에게 문서 작성은 고역이 아닐 수 없습니다. 그래서 문서는 소프트웨어를 개발한 후에 후배들에게 소프트웨어에의 스펙과 구조를 설명하기 위해서 작성하곤 합니다. 이런 경우에는 문서의 효용성도 별로 없을 뿐더러 문서가 제대로 작성되었는지 알기도 어렵습니다. 또 개발자들은 기억을 더듬어서 문서를 작성하기도 어려울 뿐더러 이러한 작업은 하기 싫은 고역이 될 수 밖에 없습니다.

소프트웨어를 개발하는데 있어서 필수적인 문서의 대부분은 개발한 내용을 정리하기 위해서 만드는 것이 아니고, 소프트웨어를 개발하는데 필요한 내용을 앞 단계에서 작성하는 것입니다.

즉, 설계를 하기 전에 스펙을 작성하고
구현을 하기 전에 설계서를 작성하고
테스트를 하기 전에 테스트 계획 및 TCL(Test Case List)를 작성합니다.

하지만 현실에서는 이렇게 작성된 문서를 가지고 다음단계 작업이 잘 안 된다는 문제가 있습니다.
즉, 다른 개발자가 작성한 스펙을 가지고 설계 및 구현(코딩)을 할 수가 없는 경우가 대부분입니다.

스펙을 제대로 작성하려면 남이 설계할 수 있을 정도로 상세하게 적어야 하는데, 잘못하면 백과사전이 되고 또는 흔히 빈약한 스펙서를 작성합니다. 이렇게 되면 스펙을 작성한 사람이 또 설계자에게 계속 스펙을 설명해줘야 합니다. 

이 글을 읽고 있으면서 이것이 뭐가 문제라고 생각하신다면 이미 가내수공업식 개발에 익숙해지신 겁니다. 한 개발자가 스펙도 작성하고 설계, 구현, 테스트를 모두 다하는 이런 가내수공업식 개발은 회사는 성장의 한계에 부딪히고, 개발자는 성장하지 못하는 악순환에 빠지기 쉽습니다.

개발문서는 그 문서를 보고 다음단계의 개발자들이 충분히 일을 진행할 수 있을 정도로 상세해야 합니다.
따라서 상세화 정도는 상황에 따라서 다르다는 것을 알 수 있습니다. 설계자가 해당 제품에 대해서 빠삭하게 알고 있으면 기능스펙을 적당히 적어도 문제가 없을 것이고, 신입사원에게 일을 시키려면 좀더 자세히 적어야 할 것입니다. 

또한, 좀더 작은 양으로 이해 가능한 문서를 작성하려면 소프트웨어를 다양한 뷰에서 바라보고 적어 주는 것이 좋습니다. 따라서 스펙을 작성할 때는 소프트웨어를 인터페이스에서 바라본 모습, UI에서 바라본 모습 그리고 기능, 비기능적인 내용을 적어주면 기능에 대하여 많은 양을 설명한 것보다 더 이해하기 쉽습니다.  설계에 있어서도 소프트웨어의 아키텍처를 데이터 관점, Flow 관점, 시간의 흐름, 시스템의 상태 등 다양한 관점에서 바라본 모습을 적당히 표현해 주는 것이 하나를 자세히 적어 주는 것보다 좋습니다.

매우 추상적인 글을 적어 놓은 것 같지만, 실제 개발문서를 제대로 적기 시작하면 잘 적었는지? 못 적었는지는 명확하게 구분 됩니다. 작성된 문서를 가지고 다음 단계 개발자들이 별 무리 없기 개발을 할 수 있고, 문서가 거의 바뀌지 않는다면 잘 작성된 것이고, 그렇지 않으면 잘 작성되지 않은 것입니다.

그래서 이를 위해서 기법을 쫓기 보다는 실제로 필요한 것이 무엇인가 생각하고 실질적인 접근이 필요합니다. 잘못 익힌 기법은 독이 될 수 있습니다.

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다. 
저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 TCL, 문서, 설계, 소프트웨어, 스펙

  1. 문서가 실용적이어야 한다는 의미는 공감합니다만,

    > 문서가 거의 바뀌지 않는다면 잘 작성된 것이고, 그렇지 않으면 잘 작성되지 않은 것입니다.

    이 부분은 일반적인 이야기가 아니지 않나 생각됩니다. 코드는 문서보다 훨씬 빠르게 바뀌기 때문에 문서는 뒤쳐지게 되어있는데, 아마도 말씀하신 의미상으로는 문서를 이런 변화까지 수용하게 적어야 된다는 것이 아닐까 추측되는데, 그건 잘 작성된 기준으로 생각하기에는 적합한 기준이 아니지 않나 생각됩니다. 문서가 바뀌기 때문에 잘 작성하지 않았다는 것은...

    또한, 다음 단계(?)의 개발자가 이를 활용할 수 있는 프로젝트가 있는 반면, 그렇지 않은 프로젝트도 많이 있기도 한 것 같습니다.

  2. charlz님 안녕하세요.
    좋은 의견 감사합니다. charlz님의 댓글을 보면 "문서"라는 말을 가지고도 서로 다른 이미지를 그리고 있다는 생각이 듭니다.

    예를 들어서 스펙서를 기준으로 보면 설계단계나 구현단계에서 스펙서가 바뀌는 것은 스펙이 바뀐 것이고, 그 변경에 대한 비용을 몇곱절로 치뤄야 합니다. 하지만 개발 기간내에 스펙이 전혀 바뀌지 않는 프로젝트는 찾아보기 힘들죠. 하지만 변경을 최소화는 해야 합니다. 설계가 진행되고 코드가 진행됨에 따라서 스펙서를 바꾸지는 않죠.

    그리고 설계서의 경우에도 코드가 진행됨에 따라서 아키텍쳐나 인터페이스의 변경이 있기 전에는 설계서가 변경되지 않습니다. 문서와 코드가 같이 발전해 나가는 경우는 분석, 설계, 구현단계가 적당히 밍글된 형태일 수도 있습니다. 사실 크고 작은 많은 프로젝트가 이렇게 진행되고 성공적으로 잘 끝나기도 합니다. 하지만 이런 방법으로 계속 성장하기는 어려움이 있습니다.

    사실 문서가 잘 작성되었는지 판단하기는 대단히 어렵습니다. 그래서 그 한방법을 언급해 봤습니다.

    제가 항상 주장하는 것은 개발자들이나 개발사들의 현재 상황에 따른 전투적인 대응방법이 아니고 개발자들이 꾸준히 성장하고 실력도 향상되며 현재 프로젝트를 잘 수행해내기 위한 원론적인 방법들이 주류를 이룹니다. 그런 관점으로 읽어주세요.

    charlz님의 의견과 같은 여러 관점은 제가 많은 도움이 되네요. 감사합니다.

  3. Blog Icon
    ^^

    문서라 지긋지긋하지요.

    정말 돈받고 만드는 프로덕트로서의 문서들은 가끔 종이값과 타이핑값을 받기 위해 만드는거 아닐까 하는 생각이 들곤 합니다. 그래서 도큐멘트도 아니고 산출물이라고 하는게 아닐까 생각하죠. ^^

    SI성 프로젝트를 많이 하다보니 몇십종의 산출물들이 과연 필요나 할까 싶을떄가 많기도 하고, 왜 보지도 않고 쓸데도 없는 문서를 주구줄창 만들어야 할까 싶습니다.

    경험적으로 생각해보면 산출물은 의사전달을 위한 문서, 생각을 정리하기 위한 문서, 점검을 위한 문서 세종류가 있는 것 갑습니다. (그냥 제 기준입니다.)

    무엇을 위해서 작성을 하는지가 중요한 것 같은데.. 문서 프레임에 압도당할때가 만은데요. 잘하지는 못하지만 고객이나 내부 팀원이 쓸 수 있을 만한 표현력이 들어가면 문서의 프레임이야 얼마든지 고칠 수 있지 않나 싶네요. ㅎㅎ

    뭐 항상 만들고 나면 이것 저것 한방에 보고 싶다는 욕심에 덕지덕지 붙여넣다가
    질려서 흐지부지 되는 경향이 있어서.

    될 수 있으면 간략한게 좋지 않나 생각이 드네요.

    특히나 고객의 요구사항이 수시로 변할떄는 말이죠.

  4. 산더미같이 많은 문서를 만드는 프로젝트들은 아주 잘못된 관행입니다. 소프트웨어 개발에 대해서 잘 모르는 고객이 거대한 방법론에 있는 문서를 무작정 다 요구하곤 합니다. 그 방법론에서도 문서를 다 만들라고 하지 않는데도 잘못 적용하는 것이지요.
    하지만 개발사 입장에서 고객이 요구하는데 안만들 수는 없는 노릇이지요. 수많은 문서 중에서 실제 개발에 필요한 문서는 소수에 불과합니다. 그런 문서만 제대로 만들고 나머지 프로세스나 관리를 위한 문서들은 최소한의 노력만 들이는 것이 좋습니다.

개발자들이 바글바글한 외딴섬에 떨어진다면

2009.04.22 10:01 by 전규현


잠시 후 Google blogger로 이동됩니다.



개발자들이 바글바글한 외딴섬에 떨어졌는데 서로 뒤죽박죽으로 개발을 하고 있고,이들을 3개월 안에 훈련시켜서 정예 개발자로 만들어 한다는 미션이 떨어졌다면 무엇을 하시겠습니까?

Language 기초를 다시 가르칠까요?
UML을 가르칠까요?
문서 작성법을 훈련 시킬까요?
개발방법론을 가르칠까요?
팀워크를 키워줄까요?
OOP를 가르칠까요?

어떻게 하시겠습니까?

나는 스펙을 작성하는 방법을 가르치고 3개월간 훈련을 시킬 겁니다. 
즉 Requirement engineering을 익히게 하겠다는 뜻입니다. 그만큼 스펙은 현재 소프트웨어 개발현장에서 가장 많은 실패의 원인이 되고 있고, 배우기도 가장 어려운 분야입니다. 나는 수많은 개발자들이 작성한 스펙문서(다양한 이름의 문서)를 봐 왔지만, Requirement engineering을 제대로 알고 잘 작성한 스펙문서는 별로 접해보지 못했습니다. 또한 그로 인해서 프로젝트나 제품에서는 수많은 문제들이 야기되고 있었습니다.

물론 스펙을 제대로 쓰기만 한다고 소프트웨어를 잘 개발할 수 있는 모든 준비가 된 것은 아닙니다. 스펙을 쓰는 것은 이제 소프트웨어 제대로 된 소프트웨어 개발에 한 걸음 내디딘 것 뿐입니다. 거꾸로 스펙도 쓰지 않고 소프트웨어를 어떻게 개발하냐고 반문할 수 있습니다. 즉, 무엇을 개발할지도 모르고 여럿이서 소프트웨어를 어떻게 개발하냐는 것입니다. 또 영업이나 고객은 정확하게 무슨 제품이 나올지도 모르고 기다리냐는 것입니다.

하지만, 이에 대한 반론을 얘기하는 사람도 꽤 됩니다. 기존에 제대로 된 스펙 없이도 훌륭한 제품을 많이 탄생했고, 성공한 제품도 꽤 된다고 얘기합니다.  물론 예외는 항상 있습니다. 저도 몇몇 그런 사례를 알고 있습니다.
정확하게 따지면, 그렇게 성공한 제품은 별로 많지는 않습니다. 그리고 초창기에 제품의 크기가 작거나 고객 수가 작을 때는 멋진 제품이었으나 매출이 늘고, 소프트웨어 규모가 커지면서 망가진 제품도 꽤 많습니다. 즉, 스펙의 부실로 혼동에 빠져서 실패한 제품이 꽤 됩니다.

제대로 된 스펙도 없는 제품이 성공할 확률은 잘 작성된 스펙을 토대로 개발하고 유지보수 되는 제품의 성공확률의 1/10도 안될 겁니다. 

소프트웨어 개발자라면 스펙이 왜 중요하고, 스펙을 잘 적기 위해서 배우고 많은 노력을 기울여야 한다는 것을 알아야겠습니다.

PS) 가끔 우리나라가 소프트웨어 업계에서는 섬처럼 느껴지곤 합니다.

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다. 

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

전규현 프로젝트/요구사항분석 개발자, 분석, 스펙, 요구사항

  1. Blog Icon

    비밀댓글입니다

  2. 스펙의 정의와 범위는 막연하지 않습니다. 구체적이지요. ISO나 IEEE에서도 정의가 되어 있습니다. 하지만, 소프트웨어나 프로젝트의 성격에 따라서 중요한 부분이 다르고 적당한 표현방식이 다르기 때문에 Template이 Sample을 보는 것은 도움이 된다기보다는 생각의 폭을 좁히고 사고를 고정시키기 때문에 도움이 안된다고 생각합니다. 또한 NDA에도 어긋나고요. 시간이 되면 저를 한번 방문하셔서 토론할 기회를 가지면 좋을 것 같습니다. 그런 기회는 언제든지 환영입니다.

    오히려 설계가 제품마다 상당히 많이 달라서 더 정형화 시키기 어렵죠.

  3. 흠.. 그런 의미의 스펙을 말씀하신 거군요.
    저는 고객의 요구사항에 따라 만들어지는 제품에 대한 스펙을 말씀하시는 줄 알았습니다. 제가 생각했던 부분은 어찌보면 설계서를 생각했었는데 그 상위 레벨 혹은 단계를 말씀하신 것으로 이해가 됩니다. 그렇다면 말씀하신 대로 문제가 발생이 되겠네요. 좋은 말씀 감사합니다.

  4. 조금은 정형화된 예제의 문서가 있을까요? 물론 프로젝트, 솔루션 마다 틀리겠지만요. 어느정도 예제를 삼을만한 문서가 있으면 좋겠네요. 이런문서들도 각업체별로 틀리겠지만 이런문서들도 약간의 틀을 가진 문서가 있으면 좀 공통적으로 적용해서 모든 개발자들이 이해하고 독해할수 있었으면 좋겠다는 생각이 듭니다.

  5. 곰아리님 안녕하세요. 스펙문서는 소프트웨어 개발방법론마다 다 Template이 있으니 Google에서 찾아보는 것은 그리 어렵지 않습니다. 하지만, 복잡한 개발방법론은 스펙과 연관된 문서가 너무 많고 복잡한 것이 문제입니다. 또한 Template을 보더라도 그 내용을 어떻게 채우는지 아는 것은 더 어렵습니다. 경험도 많이 필요합니다. 그래도 Template를 보고 싶다면, ISO나 IEEE에서 정의한 SRS문서를 보면 참조가 됩니다. Template만 보고 작성된 SRS를 보면 잘못된 내용을 적는 경우가 많더군요.

  6. Blog Icon
    [1002]

    스펙은 누가 만드나요?

  7. 스펙을 쓰는 사람은 프로젝트마다 다를 수 있습니다. 스펙을 쓰려면, 고객의 요구사항을 잘 분석할 수 있어야 하고, 기술도 잘 알아야 합니다. 선임 개발자가 쓰기도 하고, 소프트웨어 분석가가 따로 있는 경우도 있고, 다양합니다.

  8. Blog Icon
    .

    개발자들이 바글바글한 섬이라면 스스로 필요한 소프트웨어를 만들어 낼 것이니 교육이 필요없을 듯 합니다. 개발자는 별로 없고 자신이 뭘 원하는지 모르는 고객이 바글바글한 섬이라면 고객들에게 일단 스스로 필요한 것이 "진짜" 뭔지를 알아내는 교육을 하면 의미는 있겠네요.

  9. 일리가 있는 얘기네요. 문제는 스펙을 적는 방법을 잘모르고 경험이 부족한 것이겠지요. 하지만, 개발자들이 자신들이 쓸 소프트웨어를 스스로 만든다면, 그 필요성이 줄어들겠네요. 여태 그렇게 잘 만들어서 써왔고요.

  10. 멋진 반전이네요.

  11. 잘보고 갑니다~일리가 있는얘기 입니다, 프로젝트 단위에서 규모가가 커지면 커질수록
    중요성이 강조 되는것 같아요.
    여담이지만서도...
    개발자에게 회의시간에 웃으며,고집안부리고 커뮤니케이션 하는 방법 가르키는건 어떨까요..

  12. sheon님 안녕하세요. 그것도 좋은 방법이네요. ^^ 왠지 개발자들에게는 공통된 인식이 있는듯 하네요.

  13. 저는 우선 팀웍을 가르칠것 같습니다. 주어진 환경이 아주 좋고 능력이 있는 개발자만 모여 있다 하더라도 협업이 되지 않아 실패하는 경우를 많이 보아 왔거든요. 개발 방법론은 모르더라도 같이 일하는 조직에서 협업이 잘 된다면 그 조직에 맞는 개발방식이 수립이 됩니다. 다들 좋다는 방법론 보다 그 조직에 최적화 되어있는 개발 방법이 가장 효과적인 방법론이라고 생각하거든요. 그런 경우는 뭐같은 요구사항이 나오더라도 찰떡같은 작품이 나오기도 합니다.

  14. C-Thinker님 안녕하세요. 팀웍을 중요하게 생각하는 분이 좀 되는 것 같네요.

  15. Blog Icon
    popopome

    님의 글을 보면서 제가 봤던 아래 블로그에 Scott이 남긴 커멘트가 생각났습니다.
    http://www.gaborcselle.com/blog/2009/04/what-specs-are-good-for.html

    저도 C-Thinker님 말대로 팀웤에 한표를 던지겠습니다.
    Communication is matter to be success or failed!.

  16. popopome님 안녕하세요.
    스펙은 항상 소프트웨어 개발에 있어서 가장 중요하지만 어렵고, 스펙작성은 개발자들의 역량 중에서 가장 우선시 되곤하나 또한 익히기 어렵다고 알려져 있습니다. Scott의 커멘트를 보니 그사람의 경험과 생각을 미뤄 짐작해볼 수 있습니다. 그래서 절대적인 비교는 되지 않죠. 그러기에는 우리나라 개발환경은 기초가 많이 부족하거든요.

  17. Blog Icon
    카페모카

    글 잘읽고 갑니다.

    핵심인재 한명 빼고, 전부 코더로 만드는건 어떨까요?
    중앙집권..불가능하겠죠? ^^

  18. 카페모카님 안녕하세요.
    그렇게 할 수만 있다면 좋은 생각이죠. 가장 적은 비용으로 가장 좋은 제품이 나올 수도 있겠죠. 그리고 그 코더들도 시간이 흐르면 설계도 할고, 더 비싼일을 할 수 있겠죠.

  19. 초보 개발자인 저에게 너무나 와닫는 내용들이 가득한 블로그네요
    RSS 등록하고 자주 오도록 하겠습니다 ^^

  20. 감사합니다.

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..

티스토리 툴바