tag:blogger.com,1999:blog-6060875800282210631.post273472131018660355..comments2023-11-08T05:29:09.590+09:00Comments on All of Software: 기존 소프트웨어를 버리고 언제 새로 만들어야 할까?전규현http://www.blogger.com/profile/02706025917864233238noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-6060875800282210631.post-55446344178392445072011-01-17T16:44:30.000+09:002011-01-17T16:44:30.000+09:00흠... 가만 보니 저희 회사가 주먹구구로 시작해서 나름 잘 됐는데 두번째 개선에서 죽 쑤...흠... 가만 보니 저희 회사가 주먹구구로 시작해서 나름 잘 됐는데 두번째 개선에서 죽 쑤는 중이네요.<br>거기다 소통도 안되고 뒷방에서 뭔가 왔다갔다 하니까.. 걱정이네요.별의파편noreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-18312379695952475912011-01-17T17:18:11.000+09:002011-01-17T17:18:11.000+09:00안녕하세요. 별의파편님이런 증상은 매우 흔합니다. 일반적인 과정입니다.두번째는 방법이 달라...안녕하세요. 별의파편님<br>이런 증상은 매우 흔합니다. 일반적인 과정입니다.<br>두번째는 방법이 달라져야 합니다. 더이상 구먹구구는 안됩니다. 그런데 과거의 성공에 대한 환상을 가지고 있는 경연진은 몇몇 개발자들을 특공대처럼 구성해서 만들려고 합니다.<br>하지만 이미 회사는 이전의 규모가 아니고 시장의 요구도 몇배 커졌기 때문에 십중팔구 실패를 맛보게 됩니다.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-15672290896887635052011-01-17T23:46:54.000+09:002011-01-17T23:46:54.000+09:00제가 속한 회사도 이제 한 제품을 끝내려 합니다. 한동안 정신없이 날밤 새다가 요새 정시 ...제가 속한 회사도 이제 한 제품을 끝내려 합니다. <br>한동안 정신없이 날밤 새다가 요새 정시 퇴근하며 기력을 되찾고 있습니다. 그렇지만 어딘가 허전한데 원인을 통 몰라 혼자 헤매고 있던 와중에 귀가 번쩍 뜨이는군요. 정말 감사합니다. 문서 기타 등을 정리하려면 막 끝낸 시점만큼 좋은 때가 없죠. ^^ 다른 팀원은 쉰다고 하더라도 저는 첨부터 끝까지 차분히 리뷰/정리해봐야겠습니다. ^^somanoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-56287075190188857092011-01-18T10:53:42.000+09:002011-01-18T10:53:42.000+09:00안녕하세요. soma님더이상 시장이 없어서 단종을 하시는 것인지? 다음제품 또는 대체 제품...안녕하세요. soma님<br>더이상 시장이 없어서 단종을 하시는 것인지? 다음제품 또는 대체 제품을 만들고 이전 버전을 단종하는 것인지 궁금하군요.<br>이전 제품을 차분히 분석해서 lesson learned 를 파악하는 것도 좋습니다. 하지만 끝나고 몰아서 정리를 해보는 것은 누락된 것이 엄청나게 만을 겁니다.<br>평소에 wiki나 이슈관리시스템을 이용해서 전 개발자들이 모든 이슈를 정리하는 습관을 가지는 것이 좋습니다.<br>이것들은 추후 중요한 스펙이 됩니다.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-87760241196177904002011-01-22T22:23:00.000+09:002011-01-22T22:23:00.000+09:00늦게 달게 됐군요.^^;단종/대체가 아니고 신규 제품을 처음 서비스하게 됐습니다.저야 개발...늦게 달게 됐군요.^^;<br>단종/대체가 아니고 신규 제품을 처음 서비스하게 됐습니다.<br>저야 개발자 입장에서 서비스 들어가니 이제 개발이 어느정도 끝났다고 생각하지만 뭐.. 현실도 그렇진 않지요. ^^; 다만 지금 제품의 다음 버전은 막 서비스하기 시작하는 지금 시점부터 준비하는게 가장 확실하다고 본문을 읽고 느끼게 됐습니다.somanoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-73091629002548832222011-01-22T23:12:20.000+09:002011-01-22T23:12:20.000+09:00끝낸다는 것이 프로젝트가 끝난다는 뜻이었군요.끝낸다는 것이 프로젝트가 끝난다는 뜻이었군요.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-18644909285335264922011-01-18T09:51:00.000+09:002011-01-18T09:51:00.000+09:00주먹구구가 되는 가장 큰 이유는 돈 문제죠.조직이 되었던.. 개발 프로세스를 관리 해줄 솔...주먹구구가 되는 가장 큰 이유는 돈 문제죠.<br><br>조직이 되었던.. 개발 프로세스를 관리 해줄 솔루션이든. <br><br>만들어내고 도입을 할려면 자금이 들어가야 되고.<br><br>더군다나 초기에는 주먹구구식이 비용이나 생산성에서 더 효율적입니다.<br><br>적절하게 조직을 만들고, 프로세스 관리를 도입하는게 경영진의 몫이겠죠.<br><br>개발자에게 관리까지 떠 넘기는건 문제가 있습니다.<br><br>그런데 초기 핵심 개발자들이 진급하면서 관리롤이나 영업롤을 맡는 경우가 상당수라서..<br><br>여기서 병목현상이 벌어지기도 합니다.<br><br><br>개발자는 개발만 시키고..<br><br>제품 라이프 사이클에 맞춰서 경영진이 현명한 판단을 해야곘죠.쩝noreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-54350266590651360932011-01-18T10:30:02.000+09:002011-01-18T10:30:02.000+09:00비판은 아니고요.. 의견입니다.주먹구구식으로 하는 개발 비용 vs 체계적인 설계를 해서 개...비판은 아니고요.. 의견입니다.<br><br>주먹구구식으로 하는 개발 비용 vs 체계적인 설계를 해서 개발하는 비용<br>두 비용은 비슷하다고 봅니다..<br><br>초기비용은 전자가 덜 들겠지만 어차피 Q/A를 할 때 비용이 더 많이 들어가리라고 봅니다.<br><br>핵심개발자가 진급하면 영업롤을 맡기는 회사라면 회사 자체에 좀 문제가 있지 않을까 합니다.몽noreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-58535295806036550142011-01-18T11:02:20.000+09:002011-01-18T11:02:20.000+09:00안녕하세요. 쩝님개발자에게 관리를 맡기는 것은 저도 항상 반대를 합니다.대부분의 회사가 주...안녕하세요. 쩝님<br>개발자에게 관리를 맡기는 것은 저도 항상 반대를 합니다.<br>대부분의 회사가 주먹구구로 개발을 하는 이유는 주먹구구밖에 방법을 모르기 때문이라고 생각하고 있습니다. 실제로 많은 소프트웨어 회사를 접한 저는 충분히 많은 사례을 가지고 있습니다.<br>시간과 돈만 있으면 우리도 문서를 잘 만들고 체계적으로 개발할 수 있다고 하는 사람도 많지만 시간과 돈이 있어도 제대로 못합니다.<br>또한 혼자 개발을 해도 체계적으로 개발하는 것이 더 빠릅니다.<br>이것이 소프트웨어 공학에서 가장 이해하기 어려운 부분입니다. 이것을 이해하고 있다면 소프트웨어 공학을 이미 다 이해한 것입니다.<br>체계적으로 개발하는 방법을 모르는 개발자나 회사는 오로지 주먹구구식으로 개발하는 방법밖에는 모릅니다.<br>이 경우 프로젝트의 규모가 작다면 주먹구구식으로 개발을 해도 프로젝트를 성공할 가능성이 있습니다. 그래서 주먹구구에 대한 환상을 가지고 있는 경영자들도 많습니다.<br>그리고나서 몇번 실패를 맛봐도 실패의 탓을 주먹구구 방식으로 돌리지 않고 개별 개발자나 다른 이유를 찾기도 합니다.<br>경영자가 현명해져야 합니다.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-53069064485077756262011-01-18T11:06:11.000+09:002011-01-18T11:06:11.000+09:00안녕하세요. 몽님몽님도 대체로 소프트웨어 공학을 이해하고 계신 것 같군요.하지만 조금더 이...안녕하세요. 몽님<br>몽님도 대체로 소프트웨어 공학을 이해하고 계신 것 같군요.<br>하지만 조금더 이해를 하면 체계적으로 개발하는 것이 주먹구구 방식보다 비용이 적게 들고 프로젝트 시간도 절약된다는 것을 아시게 될 겁니다.<br>여기서 "체계적"이라는 용어에 대해서 서로 오해를 합니다. 형식적인 프로세스밖에 경험하지 못한 개발자들은 "체계적"이라는 것을 천편일률적으로 생각하고 매우 거북한 것으로 생각합니다.<br>"체계적"이라는 단어를 "효율적"으로 바꾸면 더 이해하기가 쉬울 겁니다. 설계를 하더라도 필요한 만큼 효율적으로 한다고 보면 됩니다. 이를 판단하기 위해서는 경험이 많이 필요합니다.<br>그리고 유지보수 할 때는 말할 나위도 없죠. ^^전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-75108378143747574612011-01-18T12:23:49.000+09:002011-01-18T12:23:49.000+09:00좋은 정보가 많네요."효율적"인 프로세스 도입이 좋은것은 자명하겠지만 현...좋은 정보가 많네요.<br>"효율적"인 프로세스 도입이 좋은것은 자명하겠지만 현실적으로 그렇게 되지 않는데는 이유가 있겠지요.<br>구성원들이 그 효율성에 대한 개념을 이해하기 위해서는 능력과 경력의 동반이 반드시 필요한 것 같습니다.<br>게다가 현실적으로 몇 몇 뛰어난 개발자 및 경영자는 그런 프로세스 무시하고도 성공을 하는모습을보여주니<br>대부분의 소규모 소프트웨어 개발회사들이 어떤 방법을 택할지 선택을 못하는 경우도 있습니다.<br>우리나라 소프트웨어산업 발전 및 종사자들의 처우 개선을 위해서는 현실에 맞는 소프트웨어 공학의 발전이 우선되어야 하는건 아닌가 하는 생각도 듭니다.스피드noreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-42423285169800151592011-01-18T21:20:12.000+09:002011-01-18T21:20:12.000+09:00스피드님 안녕하세요.맞습니다. 평생 그렇게 해서는 구멍가게 밖에 못하죠. 또한 그런 프로그...스피드님 안녕하세요.<br>맞습니다. 평생 그렇게 해서는 구멍가게 밖에 못하죠. 또한 그런 프로그래밍영웅들은 주먹구구식으로 밖에 개발을 못해서 그런거죠.<br>사실 프로그래밍영웅 개발자도 할말은 있습니다. 자신들도 제대로 배울 기회가 없었기 때문이죠. <br>그래도 Open mind만 있고 소통이 중요하다는 것을 깨달으면 계속 주먹구구 방식을 고집하지는 않겠죠.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-67205184349426019882011-01-18T19:14:31.000+09:002011-01-18T19:14:31.000+09:001. 이 블로그에 오면, 글도 글이지만, 댓글에서도 많은 것을 배우고 갑니다. 항상 좋은 ...1. 이 블로그에 오면, 글도 글이지만, 댓글에서도 많은 것을 배우고 갑니다. 항상 좋은 글 올려주셔서 감사합니다. <br><br>2. 그 때 칭찬해 주신 Mercurial 관련 글을 http://sainthkh.codex.kr/lec/Mercurial/mercurial.html 에 모아 두었습니다. 현재 서버 만드는 법에 대한 것이 좀 빠져서 아쉬운데 나중에 공부해서 꼭 올려보겠습니다. <br><br>3. 나중에는 Mercurial 강좌 스타일로, 명세서 작성법에 대한 이야기가 하고 싶기는 한데, 언제가 될는지 모르겠습니다. 저조차 명세서 작성에 대한 글을 쓰기에는 너무 많이 부족하다는 생각을 해서요. 5페이지 정도 작성했던 GUI 관련 명세가 부실하다는 것을 깨닫고, 명세서 Refactoring을 시작했습니다. <br><br><br>4. 지금 가르쳐주시는 많은 것들을 학교에서 가르쳐 주면 참 좋겠다는 생각을 합니다. 전에 한 번 동기들에게 Subversion 강의하면서 돌아다녔던 기억이 나네요... 교수님들도 이것들이 왜 필요한지 이해하지 못하시는 분들도 많은 것 같습니다.주의사신http://sainthkh.codex.kr/tc/prognoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-21105416348159876822011-01-18T21:20:57.000+09:002011-01-18T21:20:57.000+09:00안녕하세요. 주의사신님 제 블로그에서도 명세(스펙, SRS)관련된 글이 많고 책에서도 가장...안녕하세요. 주의사신님 <br>제 블로그에서도 명세(스펙, SRS)관련된 글이 많고 책에서도 가장 많이 강조를 하지만 소프트웨어를 개발하는데 있어서 가장 중요하고도 어려운 분야이기 때문에 글로 설명하기 쉽지 않을 겁니다. <br>글을 올려주시면 같이 의논해볼 좋은 기회가 될 것 같습니다.<br>소프트웨어 공학을 대학에서 가르치는 곳도 있었습니다. KAIST에서는 대학원 과정으로도 있습니다. 하지만 일부 대학 교수님 중에는 이론에 치중해서 실전에는 약한 분들도 있기는 합니다.<br>단, 소프트웨어 공학은 학교에서 배웠다고 하더라도 실전에서 경험하지 않으면 진짜 배운 것이라고 하기 어렵습니다. 즉, 경험이 가장 중요하다는 말입니다.전규현http://allofsoftware.netnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-73506566563488820442011-01-20T19:45:52.000+09:002011-01-20T19:45:52.000+09:00확실히 개발중인 모듈을 언제 포기하고 다시 재설계해서 만들어 낼지를 결정하는 것도상당히 힘...확실히 개발중인 모듈을 언제 포기하고 다시 재설계해서 만들어 낼지를 결정하는 것도<br>상당히 힘든 선택이고, 이러한 결정 자체도 점점 두려워지더라구요.<br><br>그래도 그 이전의 버전을 설계/개발하면서 가진 노하우가 있으니 금세 보완하고 더욱 좋게 만들수는 있지만 말이죠 ^^구차니http://minimonk.tistory.comnoreply@blogger.comtag:blogger.com,1999:blog-6060875800282210631.post-3692642245343583552011-01-21T12:46:26.000+09:002011-01-21T12:46:26.000+09:00구차니님 안녕하세요.노하우는 축적되나 개발 방법에서는 별 진전이 없는 경우가 많습니다. 그...구차니님 안녕하세요.<br>노하우는 축적되나 개발 방법에서는 별 진전이 없는 경우가 많습니다. 그래서 기술은 더 좋아졌으나 프로젝트에 실패하는 경우가 많습니다. 즉 시작은 더 오래 걸리고 품질도 떨어지곤 합니다. 또한 기존에 축적된 노하우만 추가하다보니 미래의 요구사항을 반영하지 못해서 금방 또 고쳐야 하는 요구가 생기곤 합니다.<br>개발자가 골고루 실력이 향상될 수 있어야 하는데, 코딩 실력만 늘기 쉬운 것이 문제입니다.전규현http://allofsoftware.netnoreply@blogger.com