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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

문서라 지긋지긋하지요.

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

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

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

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

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

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

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

비밀댓글 입니다

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

스펙은 누가 만드나요?

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

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

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

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

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

글 잘읽고 갑니다.

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

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

언제나 글 잘 읽고 있습니다. 빠른 시일 내에 효과적인 스펙 및 설계문서 제대로 만들기에 대한 내용을 볼 수 있길 바래봅니다.

용역 의뢰를 받다보면,
특정 플랫폼을 위한 엔진을 개발하는데 고객이 너무 '배려심'이 많아서 산출물 필요없다고 하시는 경우가 있습니다. 고객 측에서도 개발진이 있으니 완료 보고서를 알아서 쓰겠다고 하는 거죠.

문제는 설계 문서를 쓰지 않으면, '완료 보고'가 아니라 프로젝트 중간 관리 자체를 못하는 건데, 나서서 문서를 쓰겠다고 하니, 아군(?), 적군(?) 할 것 없이 쓸데 없는 짓이라고 말리더군요. 그래도 고집 피워서 겨우 기본 틀 잡아서 문서 제출하고 회의 때마다, 진도/이슈 체크 했더니 더 이상 아무 말도 없습니다.

말씀하신게 옳은 현장의 작은 기업들이나 실무 개발자들은 SRS라던가, 진행 사항 관리를 위해 어떤 서식이 있는지도 모르는 경우가 많습니다. 가장 간단한 서식 몇개를 공개할까 생각 중입니다. 제가 최근들어 고민하는 내용을 그래도 밝혀 주셔서 감사한 마음 담아 주절 거리고 갑니다.

먼저 답글 감사드립니다. 템플릿이 오히려 해가 된다는 말씀에는 깊이 공감합니다.
ISO 9001 standard 문서 작업한다고 고생하던 기억이 떠오르네요 ^^;

많은 SI 프로젝트 매니저들이 현실성 없는 양식들을 가지고,
산출물 작성만을 강요하는 상황도 큰 폐해라고 생각 합니다.

이렇게 이야기 하는 것보다 실제로 어떻게 쓰고 있는지 밝히는게 역시 낫겠네요.
역시, 템플릿 자체 보다 중요한 건, What, Why, How 3가지 행동 지침이겠죠.
서식을 만들면서 어떤 고민을 했고, 어떻게 적용했으며, 개선할 점들을 이야기하려고 합니다.

날로 글이 간결하면서 핵심을 전하는군요. 대단하십니다.
외주의 기본 요건을 다룬 이 글은 현장에서 질리도록 보는 우울한 장면을 담아내서 씁쓸하기도 하고, 계도하려는 노력에 반갑기도 합니다.

그나저나 조 아래.. RSS 구독 아니콘을 보니 구독자 하위 호환성(?)을 유지하시는 모습이 인상적입니다.

요구사항에 대한 잦은 피드백이 필요한것은 인도나 한국이나 동일하다고 생각합니다. 제 경험으로 정교한 스펙을 주는것보다 성근 스펙에 잦은 피드백이 더 효과 있었던거 같습니다. 다만 커뮤니케이션을 위한 가혹한 피드백은 각오해야...^^

Outsourcing과 Offshoring의 차이점에 대해서 잘 못 이해하시는 분들도 있으신 것 같습니다. 특히 테스트부분에 Outsourcing이 아닌 Offshoring을 진행한 일을 개선하러 해외 출장을 나왔는데...
와서 보니 넘 우울하네요. Test에 대한 Offshoring은 저희 회사에서는 100% 실패할 것이라 생각하고 아니라고 말씀을 드렸는데... 흑...
어찌해서 진행은 되었고 시간이 꽤 지난 지금 어떻게든 개선?을 하라고 하시네요.
이 부분은 제가 나중에 다시 한 번 정리해서 블로그에 올려보겠습니다. ^^;

테스트에 대한 생각이 많이 바뀌었더라도 아직 테스트에 대해서 너무 쉽게 보시는 분들이 넘 많습니다. 안타깝습니다. Offshoring이라니... ㅡㅡ;

*회사 상황을 자세히 못 적으니 말이 좀 이상하고 이해하기 힘들 것 같네요... 그래도 속상해서... 장기 해외출장은 참 힘드네요... ㅎㅎ