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


|
|
| 같이 일하려면 적어라. (6) | 2011/11/01 |
|---|---|
| 우리 식대로 (1) | 2011/10/30 |
| 우리나라 소프트웨어 회사에는 ???이 없다. (4) | 2011/07/30 |
| 주먹구구를 더 좋아 하는 이유 (11) | 2011/07/17 |
| 나쁜 습관 (2) | 2011/06/19 |
| 내가 소스코드를 몰래 고치는 이유 (13) | 2011/02/01 |
| 매일 불난 호떡집 같은 회사 (중요한 일 vs. 시급한 일) (14) | 2011/01/03 |
|---|---|
| 해외에 소프트웨어를 팔려면 이것이 꼭 필요하다. (12) | 2010/12/14 |
| 문서화 딜레마 (20) | 2010/11/11 |
| 내가 지금 하고 있는 일의 가격 (6) | 2010/11/02 |
| 개발자를 잘못 채용하는 방법 (20) | 2010/04/19 |
| Google을 이끄는 힘 (7) | 2009/10/30 |
문서화 정말 어렵더라구요. 4년차만에 처음으로 개발하기 전에 설계하면서 문서부터 만들고 있는 중인데, 이 정도밖에 안됐나 하는 자괴감이 들더라구요. 갑자기 또 속상해지네. 크크크. 10년차 되서 스펙때문에 또 좌절하면 어쩌죠. 스펙까지 익숙해지려면 보통 몇년 걸리나요? 빌 조이같은 천재들 말고요.
안녕하세요. 김재호님
스펙은 가장 작성하기 어려운 문서입니다.
요구사항 분석 능력이 있어야 하고, Domain도 잘 알아야 하고, 문서도 잘 작성해야 합니다.
제대로 적는데는 기본적으로 3~4년은 걸리고 10년이 지나고 20년이 지나도 꾸준히 실력이 증가하는 소프트웨어를 개발하는데 있어서 가장 어려운 분야입니다.
빌조이 같은 천재라고 해도 결코 처음부터 스펙을 잘 적을 수는 없습니다.
문제는 스펙을 적는 방법을 배우기가 어려운 거죠.
안녕하세요. godway님
우리나라 책중에서는 제가 쓴 "소프트웨어 개발의 모든 것"을 추천합니다. 그리고 외국책 중에서는 Requirement Engineering으로 검색을 해보시는 것이 좋겠습니다.
책을 보는 것은 도움이 되기는 하지만 책만 보고 제대로 작성하는데는 매우 오랜 시간이 걸립니다.
소프트웨어 개발의 모든 것, CodeCraft, 조엘온 소프트웨어 등등을 읽으면서,
"스펙 문서 만드세요."
라는 말을 볼 때마다, 그렇지요 옳은 말씀이지요 하면서 읽었습니다.
실제로 실천하려 하니 참으로 어렵다는 생각을 많이 해 봤습니다.
문서를 여러개를 짧게 만들어야 하는지, 길게 하나로 만들어야 하는지...
여기에는 이것이 들어가도 되지만, 저기에는 이것이 들어가면 안되는지...
이것들 고민하는 것이 일이고 실력이라는 생각 역시 들었습니다.
하지만 전에 한 번 분석 설계 구현의 순서로 만들기를 실험해 봤을 때,
시간이 확실히 줄어들었던 기억이 있어서
이젠 꼭 지키려고 노력합니다.
정말
"건강하게 살려면, 나쁜 것들 드시지 마시고, 운동 열심히 하세요"만큼이나 어려운 일이 문서화인듯 합니다.
안녕하세요. 주의사신님
문서는 쪼개나 합치나 같은 겁니다.
관리가 편하려면 하나의 문서로 만드는 것이 좋지만, 한 섹션이 너무 크면 문서를 나눠도 좋습니다.
단 문서를 나눌 경우에는 문서에 Link를 걸어야 하는데 Link된 문서는 바로 열어 볼 수 있도록 회사의 문서관리시스템이나 소스코드관리시스템에 등록해서 그 Link를 추가해야 합니다.
좋은 경험을 가지고 계시네요.
꾸준히 계속 적어나가면 매번 실력이 늘어가는 것을 느낄 수 있을 겁니다.
안녕하세요, 전규현님 오랜만입니다.
문서를 만들겠다고 달려드는 데서 부터 문서화 작업이 힘들어 지는 것이 아닌가 생각합니다. 요즘 인기있는 지속적 통합이나 지속적 배포같은 부분에서 말하듯이 문서화도 짧게 지속적으로 문서를 만들어 나가야 하지 않을까 생각합니다. 시스템 만들어 놓고 테스트 시작하거나, 통합을 시작하거나 하면 큰 문제가 생기니 짧게 짧게 작은 양에 대한 작업을 하자는 것처럼 문서화도 그 때 그 때 노트 형식으로 적어 놓으면서 발전 시켜 나가는 방법도 나쁘지 않은것 같습니다.
안녕하세요. Jake님
과유불급이라고 생각합니다.
그래도 여전히 문서 만들기를 지극히 싫어 합니다.
그래서 최근에 Agile에서는 문서를 안만들어 되는 것으로 착각하고 혹 하기는 합니다.
문서를 만드는 방법이 다를 뿐이죠.
문서는 만드는것보다도 계속 업데이트하는게 중요한것 같더군요..
실제로 버전이 올라가다 보면 문서와 소스내용이 틀려 낭패보는 경우도 가끔 있구요..
저술하신 "소프트웨어 개발의 모든것"을 봤지만 제가 말씀드린 경우의 해결책은 못 본것 같은데요..(기억을 못하는지도..)
문서의 버전업을 어떤 형식으로 진행할 수 있는지 방안이 있으시면 조언 부탁드립니다.
또 문서없이 wiki만 사용하는 경우 문제점이 있을까요? (요즘 문서의 버전문제때문에 wiki를 검토중이라서요..)
언제나 좋은 글 감사합니다..
안녕하세요. 무혹님
그래서 문서는 최대한 적게 만들어야 합니다.
제 책에서도 문서의 업데이트에 대한 내용이 있습니다.
책의 내용을 보면 이와 관련된 내용이 몇가지 있습니다.
문서는 업데이트가 어렵기 때문에 꼭 필요한 문서만 만들고 SRS는 꼭 업데이트 하라고 하고 있습니다.
또한 설계문서는 완벽하게 업데이트하기 어렵다고 설명하고 있습니다.
설계문서는 구현을 하기 위해 필요한 것이기 때문에 나중에 변경되는 것은 모두 업데이트 하기 어렵습니다.
그래서 Doxygen이나 JavaDoc을 잘 이용할 것을 설명하고 있습니다.
설계에서는 그렇기 때문에 인터페이스를 최대한으로 깔끔하고 간단하게 만드는 것이 좋습니다. 너무 얽히섥히 섞인 인터페이스는 나중에 바뀌더라도 관리가 잘 안됩니다.
약간 다른 이야기 이기는 합니다만..
대체로 글 잘 쓰시는 분들이 코딩 역시 잘 하시더군요
후배들 코딩 스타일을 글 쓰는 유형에 비교하면 다음 3가지로 간추려 지는데..
-시인 타입: 이해하기 힘들다. 잘 돌아간다.
-이면지 제작자: 이해하기 힘들다. 잘 안 돌아간다.
-기자 타입: 이해하기 쉽다. 잘 돌아간다.
요새는 코딩하기 전 과제 계획서 또는 일정표 등 문서 부터 써 보라고 합니다.
글을 쓰는 모습을 보면 이 사람이 코딩을 어떻게 하겠다 대충 알 것 같더군요
더불어 우리가 수학 논문을 많이 쓰기 때문에 증명 숙제 한거나, 쓴 논문을 보면 이 녀석이 위 중 어느 타입이구나 감이 오더군요.
안녕하세요 ~ 좋은 글 잘 봤습니다
저는 컴퓨터와는 전혀 관련이 없지만 말씀하신 내용은 학생부터 나이든 할아버지 할머니까지 도움이 되는 거 같아요
뭐 개인적으로는 연구노트를 꾸준히 제 때에 쓰고, 제 때에 다시 살펴보는 게 얼마나 어려운 지 느끼고 있네욤 ㅡ _ㅡ;;
한번 작성이 아니라 계속 업데이트 해야 하고
그걸 여러 사람과 공유/동기화 하는게 가장 힘든걸 보면
Trac 등에서 위키로 문서화 하는 추세가 바람직 할수 밖에 없는것 같아요.
안녕하세요. 구차니님
Word로 작성을 하던 Wiki를 이용하든지 큰 상관은 없을 것 같습니다. 중요한 것은 문서를 작성하는 것이고 그 내용이 더 중요하다고 생각합니다. 어디에 적느냐는 서로 장단점이 있는 것 같습니다.
내용이 중요하다는 의미는 설계문서를 작성할 때 UML을 이용하느냐 Doc로 작성하느냐 노트에 연필로 작성하느냐보다는 "설계"자체를 잘 하냐가 더 중요하듯이 어차피 내용을 잘 모르면 어떠한 툴을 가져와도 의미 없는 문서가 됩니다.
그래서 선배들이 작성한 문서를 리뷰에 참석해서 꾸준히 배워나가는 것이 문서에 무엇을 적어야 하는지 배우고 또 어떻게 적어야 하는지 어떻게 리뷰를 해야 하는지 익힐 수 있습니다.
또, 무엇은 적을 필요가 없는지도 자연스럽게 배우게 됩니다.
현재 그런 환경이 아니라면 누군가가 먼저 시작을 해야겠죠. 항상 선구자는 힘든 법입니다. ^^
선구자는 힘들다는 말, 무척 공감이 갑니다.
"내가 무엇을 해 보겠다" 할 때 대부분 반응은 "왜 귀찮게 그런 걸 하냐"가 대다수 더군요
가끔은 왜 이걸 해야 하는지 설득하는게 더 힘들 때도 있습니다.
여하튼 최근에 작은 프로젝트 팀장이 되어 이것 저것 해 보려고 하다보니 고민이 많네요.
그런 경우는 무엇을 하고 무엇은 지금은 무리인지를 판단하는게 중요합니다.
사실 이런 판단이 가장 어려운 판단 중에서 하나입니다.
그럴때 주변의 선배나 전문가에게 물어보는 것이 가장 좋습니다.
본인 스스로 판단하는 능력이 생기려면 이러한 경험을 모두 해 본 후 일겁니다.
참 힘들죠~
안녕하세요. 철이님
혹시 문서화를 왜 하려고 하시나요?
문서를 작성하면 프로젝트의 기간이 줄어든다는 것을 믿고 계시나요?
이것을 경험을 통해서 알고 있지 않으면 문서를 만들기 정말 어렵습니다.
대부분은 몇번 문서를 만들다가 프로젝트 시간만 더 걸리고 문서가 사장되기 일쑤입니다.
이런 경우는 필요없는 문서를 만들거나 문서를 잘못 만들기 때문인 경우가 많습니다.
그래서 제 책에서는 설계 문서보다더 스펙(SRS)문서를 만들라고 권하고 있습니다. 또한 뒤늦게 만드는 문서는 필요없고 프로젝트를 더 지연시키므로 만들지 말라고 하고 있습니다.
또 중요한 것은 문서는 가능하면 적게 만드는 것이 가장 좋습니다.
| 소프트웨어 회사에 산업 스파이가 존재하는가? (24) | 2010/02/16 |
|---|---|
| 애플은 한국어와 한글을 구분하지 못한다? (34) | 2010/02/11 |
| 스마트폰 앱스토어가 진짜 대박이 아닌 이유 (11) | 2010/02/09 |
| 삼성이 앞으로도 소프트웨어를 잘 만들 수 없는 이유 (36) | 2010/02/08 |
| 삼성이 바다를 출시해서는 안되는 이유 (75) | 2010/01/23 |
| 소프트웨어 회사 vs. 정치판 (이인자 죽이기) (17) | 2010/01/12 |
제 생각엔 스마트폰 초창기(아이폰으로 인해 시장이 커지는)라서
거품에 있고 사람들이 스마트폰에 대한 환상을 가지고 있는 것같습니다.
손바닥만한 화면으로는 분명 한계가 있는데요...
결국 단지 개인의 필요에 따라 몇몇 특정한 기능으로만 사용하게 될거고
꼭 이동시 사용해야하는 사람만 사용할텐데
꼭 만능기기인것처럼 여겨지는 분위기네요.
PMP있지만 돌아다니며 영화보는 사람 별로 없고요
네비있지만 네비들고 다니며 걸어가는 사람 없습니다.
전화기로 엠피스리 들을수있지만
따로 엠피스리를 가지고 다니는 사람들이 대부분이죠.
만능기기는 불편하고 이동기기도 또한 불편하죠.
이동하며 사무를 볼 수있다지만
이동하면서 까지 사무보고 싶은 사람이 몇이나 있겠어요.
오히려 전화기능과 카메라기능을 첨가하고
터치기능을 넣은 OS를 가진 스펙이 강화된
타블렛식으로 LCD를 뒤집을수있는
10인치내의 화면을 가진 노트북이 나오면
스마트폰 시장은 죽을 것같네요.ㅣ
제 생각은 좀 다릅니다.
스마트폰의 파급효과는 생각보다 클 것 같습니다. 지금은 거품이라고 얘기하지만 거품이 꺼지면 실체가 보일겁니다.
지금은 인터넷 없는 세상 생각하기 힘들죠? 스마트폰은 인터넷을 들고다니게 되는 세상입니다. 한단계 업그레이드 되는 겁니다. 기존에도 이동중에 인터넷을 사용할 수 있었지만, 편리함이 다르죠.
스마트폰이 화면이 작기는 하지만 새로운 UX가 불편함을 감소시킬 것이고, 자연스럽게 생활속으로 파고들 것으로 예상하고 있습니다.
인터넷(웹)이 나오고나서 일상 생활속을 들어오는데까지는 6,7년이 걸렸습니다. 스마트폰이 나온지는 꽤 됐지만, 전 아이폰과 안드로이드 폰이 나오고 완전히 생활속으로 들어오는데, 3,4년이면 충분하리라고 봅니다. 그사이에 사람들을 편리하게 해주는 앱들이 쏟아져 나오겠죠.
누가 옳든 간에 이쪽 밥 먹고 사는 사람들은 남들보다 빨리 알아채야 겠죠. 버스 떠난 다음에 손흔들면 안되니까요... 일반 사용자라면 자신이 좋은 것 그냥 선택하면 될거구요. ^^
저도 '현혹'의 성격이 짙은 글을 보면 비판적인 시각으로 바라보려 하고 있습니다.
이슈에 대해 여과 하지 않고 우르르 몰렸다, 우르르 파했다~ 하는 것만 봐도 매우 급변하는 IT정세와,불안정한 시국을 그대로 나타내주는 것이니까요. 이런 정세에 본질을 파악하기란 매우 어렵겠지만.. 지금 우리에게 필요한 것은 비판적인 시각이 아닐까 합니다. 예를들어.. 전규현님이 말씀하신 것처럼 요즘 모바일 쪽의 구인란을 보면 모바일 개발 경험이 有인 사람에 국한되어 있더군요. 참 안타까운 일입니다. 매우 좁게 시장이 형성되는 것도 문제이고, 장기적인 안목이 아닌 '언 발에 오줌누기 식'의 인력들만 채용하고 있으니까요. 본질을 따져서 설계와 구조에 중점을 둔다면 당연히 OO나 OOP관련 경험,또는 공학방법론을 사용해봤던 인재 위주로 형성이 되어야 하는 것이 맞다고 봅니다. 그 밑에 코딩할 인재들도 필요한 것이구요.
이 단면에서 돈만 되면 한다는 식의 불안정한 정세를 다시 한번 엿볼 수 있었습니다.
(요즘 스마트폰 애플을 취미삼아 해 보고 있습니다.--단지 취미입니다. 주업은 아니죠. 전에 GUI방식의 소프트웨어를 개발한 경험이 있다면, 예전 방식과 매우 닮아 있다는 것을 느끼고 맙니다.)
팀과 인력조화에 대해서도 한가지 문제점을 제시하자면.. 서로 잘 아는 팀을 만들 수 없는 문화가 한 몫하는 것 같습니다. 회사마다 계약 체제가 다르고 관리제도가 다르니 문화가 다를 수밖에 없고, 하청구조가 이미 뿌리박힌 데다가 같은 회사사람이 누군지도 모른 체 프로젝트가 진행되고 있는 곳도 상당히 많습니다. 어떤 회사는 갑 측에 같은 비용으로 50만 제공해주어도 되지만, 어떤 회사는 같은 비용에 200을 요구하는 곳이 있더군요.
얼마 전에 선임연구원으로 혼자 들어갔었던 프로젝트가 바로 이것과 비슷했습니다. 돈을 더 많이 주니 더 많은 아웃풋을 내야 한다는 묵시적, 강제적 계약조건이더군요. 설계,구조.. 전혀 신경을 안 쓰고 제품의 품질과는 전혀 상관없이 높은 비용(그렇게 높지도 않지만)을 주니 설계 제외하고 더 많은 아웃풋을 내라..라는 SI특유의 병폐를 또 다시 한번 경험했습니다.(아웃풋에 계약조건으로 차등을 주니 사실상 팀웍이란 잠점을 발휘할 수도 없을뿐더러 활용할 수도 없는 문화가 되어버립니다.)
사실 노하우있는 기술자를 쓰는 이유는
소프트웨어가 필요한 곳에 경험과 노하우,설계,구조론,방법론을 오히려 배우기 위한 것으로 생각합니다. 그것이 경험 있는 기술자들을 쓰는 이유가 아닐까 합니다.
5년 차가 10장찍어내고 10년 차가 같은 시간에 20장을 찍어내라는 식이니..원..(이런 곳 정말 많습니다.) 상식적으로 매우 미달인것이죠.
전 지금 병원에 입원해 있는데도.. 규현님의 글은 읽어 봅니다.![]()
moova님 안녕하세요.
병원에 입원해계시고 수술이 필요하신 것 같은데 쾌차하시기 바랍니다.
우리나라의 대부분의 회사에서는 고급개발자를 키울지도 모르고 구분할줄도 모르고 고급개발자가 무슨 일을 하는지도 모릅니다. 그만큼 낙후되어 있습니다.
소프트웨어 개발에 있어서 무슨일이 싼일이고 어떤게 비싼 일인지 구분도 못합니다. 그래서 비용과 시간이 더 많이 들며서도 날밤까면서 일해도 좋은 제품이 안나오죠.
또 무엇이 필요한 문서인지 어떤 것은 형식적이고 필요가 없는 것인지도 구분하지 못합니다. 이는 프로젝트마다 달라서 선임급(고급)개발자가 이런 것들을 프로젝트 성격에 맞게 합리적으로 결정해야 하는데 그렇게 하지도 못하게 하는 것이 현실입니다.
moova님도 고생이 많겠습니다. moova님 글들을 보면 어떤 생각과 경험을 가지고 있는지 알 수 있거든요. 저는 언제나 미래에 기회가 되어서 제 블로그를 찾아주시는 분들 중에서 뛰어난 분들과 일해보는 것을 꿈꿔 보곤 합니다.
감사합니다. 다시 한번 쾌차를 기원합니다.
스마트 폰이 상당부분 생활을 바꾸긴 하겠지만, 그렇다고 해서 삶을 스마트하게 바꾸어 줄꺼라고 생각하지는 않습니다. 상당 부분 거품도 있고 허세도 있기 때문이죠.
문득 지하철에서 보이는 아이폰 유저들을 보면
"게임", "동영상" 정도 밖에 안보이더군요.
일부 헤비유저일 것으로 예측되는 증권이나 금융 개발쪽 분들이 눈에 띄지 않는 걸지는 모르겠지만
결국에는 PMP + PSP + NDS 를 통합한 그 이상도 그 이하도 아닌 딱 게임기+휴대폰 이라는 느낌이 강합니다.
단지 인터넷이 될뿐이고, 외부에서도 편하게 할수 있을 가능성이 있기 때문에 사용자들이 끌리는거겠죠
솔찍히 말해서 저도 쓸모는 없지만 가지고는 싶습니다.
'필요'하지도 않고 '용도'도 정해지지 않았지만 가지고는 싶습니다.
아마도 이러한 경우에 단지 새로 나온 스마트 폰이고 다들 아이폰 아이폰 하니까 얼리어탑터 기분으로
대세(?)를 따라 나도 스마트하게 스마트폰! 하는게 아닐까 생각이 됩니다.
결론만 말하자면, 지금보다 상당부분 거품이 심하게 끼어있고, 비록 어느정도 삶을 변화 시킬지라도 생각보다 큰 변화를 일으키지는 못할것이라는 겁니다. 원더키디가 나올때까지 10년도 채 안남았고, SF영화에서 그리던 2000년은 차들 대신에 무빙워크 에 서서 다니는 그런 환상적인 세상이었는데 실질적으로 변한 삶의 패턴은 극히 드물듯이 말이죠.
구차니님 안녕하세요.
현재 거품이 꺼지고 좀 차분해져야 실체가 나올 것 같습니다.
"알고 봤더니 별거 아니더라"라는 말도 많이 나오겠죠. 그러면서 서서히 생활속으로 들어와서 조금씩 생활패턴을 바꾸겠죠. 이게 뭐 엄청난 변화냐? 라고 할 수도 있어도 지금도 인터넷(특히 웹) 없이도 사는 사람이 엄청나게 많지만 많은 사람은 인터넷 없는 세상은 상상하기 힘듭니다.
처음에 웹이 나왔을 때 되는게 없었습니다. 이걸로 뭐를 할 수 있을지 제대로 상상한 사람도 별로 없었습니다. 그때는 기껏해야 회사 소개하는 홈페이지와 인터넷 신문정도 였습니다. (여담이지만 95년에 제가 세계 최초 상용 Webmail 시스템을 만든 사람이지만 이를 기억하는 사람은 아무도 없습니다. 세계최초 별거 아닙니다. - -; 저는 별로 크게 성공하지도 못했구요. 제가 만든 Webmail을 컨셉과 원형을 따라서 만든 D사는 크게 성공했죠)
94년에 웹이 처음 나왔을 때는 이것이 생활을 바꿀 것이라고 생각한 사람은 극소수였습니다. 그런데 스마트폰은 얼마 되지도 않았는데 난리네요. 그래서 거품이 꺼져야 한다는 얘기입니다. 반대급부로 이쪽 개발에 종사하는 개발자들은 거품이 더 좋은 기회가 되기도 합니다만...
스마트폰이 바꾸는 생활의 변화를 가져오는 것의 주역은 하드웨어가 아닌 소프트웨어라고 생각합니다. 얼마나 좋은 소프트웨어가 더 많이 나오냐에 따라서 결론이 달라질 것 같습니다. 이는 소프트웨어 개발자들이 몫이겠죠. 구차니님 같은 분들이 바꾸는 것이라고 생각합니다.
설령 기대에 못미칠 수는 있어도 소프트웨어 개발자라면 과소평가보다는 창조자의 마인드로 동참하는 것이 필요하다고 생가가합니다.
스마트폰에 대해서 갖는 부정적인 시각은, 사용자가 아닌 개발자의 시선에서 바라봐서가 아닌가 싶습니다.
제가 느끼는 스마트폰은 저에게 있어서는 혁명이었습니다.
96년부터 PC통신 하이텔을 통해서 커뮤니티에 입문했는데요, 그 이후로 제 삶속에는 항상 인터넷이 있었습니다.
어딜가도 컴퓨터가 있으면, PC통신에 접속하고, 그 이후에는 인터넷에 접속해서 현재 저의 동호회, 카페, 홈페이지, 블로그 등을 보며 실시간으로 글을 게시하고, 댓글놀이를 즐겨왔는데요, 스마트폰은 이런 소셜 네트워크에 한층 가깝게 다가갈 수 있도록 해주는 중요한 역할을 해주고 있거든요.
인터넷이 연결되어 있지 않았을 때의 불안감이나 답답함을 한번에 해결해주고 있습니다.
집전화가 있고, 공중전화가 있지만, 누구나 휴대폰을 가지고 다니듯이, 요즘 우리 생활에 있어서 인터넷이 그렇게 변하고 있습니다. 스마트폰은 걸어다니는 인터넷 기능때문에 중요한 것이죠.
다만 인터넷 기능이 필요하지 않으신 분들께서, 스마트폰을 필요해서 자발적으로가 아닌 뜬다고 하니까 공부하시려는 분들께서 부정적인 시각으로 말씀해주시는 것 같은데요, 크게... 변화를 줄 것 같아요.
자다가 일어나서 갑자기 말이 많았습니다. 또 놀러올겠습니다. ^^
회사를 그만두고 앱 개발 창업을 준비하고 있는 사람으로서 research 도중 오랜만에 좋은 글을 발견한것 같아 기쁩니다.
진입장벽이 낮은 앱 개발은 정말 개발자의 한사람으로서 전업으로 뛰어들기전에 가장 생각이 많아지는 부분입니다. 그리고 유지보수얘기를 쓰셨던데, 시장조사도중 많은 대다수 앱개발자들이 개발은 해놓고 테스트 및 유지보수같은건 신경쓰지 않는걸 볼 수 있더군요. 정말 공감가는 부분입니다. 이런 부분을 고려한 비즈니스 모델도 생각중입니다. 그리고 혼자개발하는것에 대한 한계성 또한 매우 공감갑니다. 몇몇의 인재와 함께하면 좋겠는데, 우리나라같이 대기업만 밝히는 분위기에서 벤처에 누가 쉽게 열정을 쏟으려고 할까요 솔직히 아직 회사를 그만둔건 아닌데(저도 분위기상 대기업을 왔습니다만..), 이 부분에 대해서 상당히 두렵네요. 하지만, 돈만을 위한 개발이 아닌 첫사랑을 다시 만나 연애하는 기분으로서 다시 개발을 시작한다면 어느정도의 생활은 가능할꺼라 점점 확신이 듭니다. 그 첫사랑을 지금 시대흐름이 아니면 다신 볼 수 없을것도 잘 알고 있습니다. 또한 스마트 TV 라는 블루오션시장도 보이고요. 아직 절망보다는 희망이 많아보입니다. 첫걸음부터 큰걸음을 내딪지말고 3번의 시련을 각오하고 희망을 향해 몸을 던지렵니다.
안녕하세요. 샘성맨님
도전은 항상 아름답니다. ^^ 도전이 소프트웨어 발전의 힘입니다.
혼자 소프트웨어를 개발하는데는 많은 어려움이 따릅니다.
앱센터를 이용하면 도움이 좀 될 수 있을 것 같습니다.
앞으로 도전하시는데 도움이 필요하면 부담없이 연락주세요.
도움을 드릴 수 있으면 기쁘겠습니다.
| 개발자 여러분~ 문서 만들기 싫죠? (12) | 2009/05/06 |
|---|---|
| 이 정도도 안되면서 Peer Review를 한다고요? (10) | 2009/04/06 |
| Peer Review의 방해꾼들 (4) | 2009/04/02 |
| Peer Review의 치명적인 유혹 (4) | 2009/04/01 |
| Peer Review를 성공하기 위한 요소들 (6) | 2009/03/27 |
| 코드리뷰 정착이 어려운 이유 (10) | 2009/03/24 |
제가 있던 회사에도 자신이 만든 프로그램의 소스 코드를 암호화 수준까지 작성해서 아무도 안 보여주는 사람이 있더군요. 이런 사람 얘기는 웹을 통해서 간혹 봤지만 실제로 보니 대책이 안 서더군요.
| 2009년 새해가 밝았습니다. - 개발자에게도 희망의 한해가 됐으면... (12) | 2009/01/02 |
|---|---|
| 공든 탑을 쌓는 것은 수년, 무너지는 것은 한 순간 (2) | 2008/12/26 |
| 고객중심의 서비스 마인드가 소프트웨어 산업을 망친다. (6) | 2008/12/05 |
| 책(소프트웨어개발의 모든것)을 미국에 있는 친구에게 보냈다. (8) | 2008/11/21 |
| 내부 세미나 (0) | 2008/11/14 |
| 안다는 것과 모른 다는 것 (0) | 2008/11/10 |
JasonPA님 반갑습니다.
이런 현상을 조삼모사라고 합니다.
당장의 이익을 위해서 미래에 큰 손해를 보는 것이지요. 회사의 비전과 제품의 로드맵에 따라서 이익이 안되는 요구나 고객들은 과감히 포기할 수 있어야 하는데, 우리나라의 많은 소프트웨어 회사들은 비전과 로드맵이 부족하기 때문에 사실 포기할 수 있는 기준도 애매한 경우가 많더군요.
전적으로 동감합니다.
아직까지도, 소프트웨어에 제 값 안주고, 하드웨어의 서비스처럼 생각하는 동네도 있습니다.
슬픈 현실입니다.
어제 밤에 우연히 이곳을 발견했습니다.
도움되는 글이 많아서, 오늘 하루를 몽땅 투자해서 처음부터 읽고 있습니다.
좋은 글 감사합니다.
이건 우리나라의 특수성에서도 기인하는 것 같습니다.
미수다였나? 어디선가 외국인이 우리나라 오면 신기해하는 것중 하나가 "어디를 가도 사람 없는 곳이 없다."라는 것이었습니다.
인구밀도가 워낙 높아서, 아파트를 선호하고, 인구밀도가 높으니 네트워크를 설치할 때도 비용이 상대적으로 저렴하죠. 그러니 초고속 인터넷 보급률도 높았죠. 소프트웨어 산업도 비슷한 맥락이 아닐까 합니다. 인력은 넘쳐나니(업무능력은 논외), 손쉬운 대안이 되는 것이고, 개발자는 개발자 나름대로 자기 노하우를 다 쏟아놓으면 토사구팽될까 두려워하고. 뭐, 이런 것 아닐까요?
nulonge님 안녕하세요.
동감입니다. 그래서 개발자들이 죽어나죠. 고객들은 좋지만 결국 고객도 손해보고 다 같이 손해보는 것인데 말입니다.
'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다. 스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것..
우리나라에서는 개발자들이 개발에 집중할 수 없는 환경인 곳이 참 많다. 정도의 차이가 있지만 거의 대부분이라고 봐도 무방하다. 그 결정적인 이유는 개발자 혼자서 북치고 장구치고 다해야 하는 상황이기 때문이다. 원래는 이렇게..
최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다. 그래서 설계에 대해서도 깔끔하게 정의를 해보자. 흔히 설계에 관한 다음..
우리나라에서는 종종 SW Architect를 양성한다고 한다. 정부에서 막대한 예산이 지원도 되며 SW Architect를 양성하는 학원도 생기고 야단법석이다. 그럼 도대체 SW Architect는 무엇인가? SW Archi..
우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은 "기초 체력"이다. 히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다. 그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내..
며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다. 2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란? 소프트웨어공학의 목적..
프로토타입 (경제/경영) 양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을..
"협업은 말로 하는 것이 아니라 문서로 하는 것이다." 동서고금을 막론하고 개발자들은 적는 것을 싫어하고 또 잘 적지 못한다. 우리나라 개발자들은 그 정도가 훨씬 심하다. 우리나라에서는 회사가 크던 작던 상관없이 대부분 5년..
"우리 식대로" 마치 북한에서 하는 얘기 같지만, "우리 식대로"를 주장하는 소프트웨어 회사는 의외로 많다. 체계가 하나도 없이 완전 주먹구구 방식의 소프트웨어 회사가 있는가 하면 "우리 식대로"를 주장하여 정말 많은 일을..
소프트웨어 개발 프로젝트에서 문서는 적게 적어야 한다. 다시 말하면 "보통의 회사에서는 문서는 필요한만큼만 가장 적게 적어야 한다." 물론 문서를 많이 적으면 여러 각도에서 상세히 적기 때문에 중복은 많이 발생하지만 잘못된..
진짜 좋은 글 인거 같습니다.
주위에 다른 개발자 분들한테도 알려 봐야겠네요
경력은 얼마 안됬지만 왠지 개발문화가 없다는것에 진짜 공감이 갑니다. ^^
정말 슬픈 현실이네요. 이런 것을 공감하는 세대, 나 자신이 결국은 이런 현실을 개선 할 수 있겠지요. 열심히 해야 겠습니다.
1. 항목에 대해 강한 공감을 표현하고 싶습니다. 최근에 조인한 스타트업에서 공유에 기반한 개발과 더불어 코드 리뷰를 수행하려고 했으나, 수많은 마찰 끝에 각자 개발하는 영역을 나누기로 했습니다. 습관을 바꾼다는 것이 얼마나 힘든 일인지, 무엇보다 본인 스스로 변화하고자 하는 의지가 없이는 불가능하다는 것을 깨달았습니다.
안녕하세요. gsong님
현재 결정의 비용은 미래에 10배, 100배로 치르게 되어 있습니다. 습관을 바꾸기 어렵기 때문에 처음에는 강제화가 필요합니다. 하지만 대부분의 경영자들은 개발자들의 그럴듯한 핑계를 꺽기가 어렵습니다.
조금씩이라도 변화해보는 것이 좋겠습니다.