Zephyr...Gentle Breeze

새 폴더 생성 후 폴더 이름을 GodMode.{ED7BA470-8E54-465E-825C-99712043E01C} 로 바꿈

GodMode 는 생성되는 폴더의 이름이 되기 때문에 사용자 취향대로 바꾸어 사용이 가능 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

망하는 제품의 흔한 개발 과정

• 리더 : 요즘 유행하는 대세를 들고 온다. 이것이 대세다!
• 리더 : 속으로는 이런 것들을 쓰는 사람들은 사회부적응자라 생각하고 본인은 정작 써 본 적이 없다.
• 기획 : 써 본적은 없지만 들어는 봤다. 이런 것을 쓰는 사람은 격이 떨어지는 사람이라 생각하고, 내가 우아하고도 유럽 명품에 견줄 수 있는 것을 보여주어야 겠다 생각한다.
• 기획 : 해당 제품군을 모조리 조사한다. 그래서 해당 제품군의 모든 특징을 합한 고질라 같은 것을 그려 낸다.
• 리더 : 그것만으로는 뛰어 넘을 수 없다고 한다.
• 기획 : 아이디어를 동원한다. 이제 그 고질라에 스타워즈, 반지의 제왕, 해리포터를 더하기 시작한다. 자신의 상상력의 끝은 어디인가 하면서 스스로 놀라워 한다.
• 리더 : 고질라에서 빠진 게 없나 살핀다. 다소 억지 스럽지만, 비슷한류의 제품을 가져와 하나 더 붙인다. 이런게 바로 리더의 통찰력이라 으쓱거린다. 기획자의 아이디어를 보고는 기획자가 미쳐 생각하지 못한 경우의 수를 생각해서, 더 복잡하게 만든다. 아직 가르칠게 많다고 생각한다.
• 개발 : 그런건 못만들어요. 불평을 늘어놓는다.
• 리더 : 내 앞에서 안된다는 말은 하지 말라고 하며, 할 수 없다는 것부터 이야기하는 태도가 문제라고 한다. 그리고는, 자신의 인생 역정기를 늘어 놓는다.
• 개발 : 기획에 대한 조언을 해 줘야 겠다고 생각한다. (사실 해당 제품군을 사용해 본 유일한 사람이다.)
• 리더 : 넌 아직 인지과학, 심리학을 모른다고 일축한다.
• 기획 : 파워포인트로 찍어 내는 노가다를 시작한다.
• 리더 : 문서에서 오타를 찾아 낸다.
• 개발 : 이 프로젝트는 어짜피 산으로 갈 것이라고 떠들어 대기 시작한다.
• 리더 : 최근 세미나에서 본 솔루션들을 쓰면 금방 할 것이라고 말한다. 그리고 비싼 돈을 들여 도입을 추진한다.
• 개발 : 그게 뭔지 모른다. 다만, 대충 들어보니, 그것 보다는 자기간 만들어 놓은 자작 솔루션이 훨씬 더 좋은거라고 속으로 생각한다.(사실 지금 이 상황에 그걸 배워서 만드는 것은 엄두가 나지 않는다) 그리고 쓰는 척 시늉만 하기로 결심한다. 타인이 만든 것을 사용하는 것은 하수들이나 하는 짓이라 생각한다.
• 리더 : 개발기간은 3개월이라 한다.
• 개발 : 불가능한 일정이라 하고, 기획안을 조정하라고 주장한다.
• 리더 : 나는 어찌 저런 무능하고 게으른 개발자만 옆에 있는지 탄식한다. 나에게 해외 유수기업의 개발자를 붙여주면 단박에 성공 할 수 있으리라 생각한다.
• 개발 : 투덜거리며 밤 샌다. 불행하게도 고질라를 만들어 내는 과정과 SF 가 붙여 지는 과정은 개발 과정 진행중에 병행해서 발행하는 일이다. 스타워즈를 다 붙여놓으면, 어느덧 스토리는 해리포터로 바뀌어 있다. 다시 밤을 샌다.
• 리더 : 3개월 후면 다 되어 있겠지 생각을 한다. 개발 과정에는 관심이 없다. 개발이 진행되는 중간 중간, 어제밤 자다가 생각난 환타스틱한 장면을 기획자에게 넣으라고 말한다. 이 장면을 놓쳤으면 이번 제품에 핵심이 빠졌을 거라고 생각하고, 이제라도 넣게 되어 다행이다 생각한다. 그리고, 자신이 얼마나 디테일에 강한가 다시 한번 생각해 본다.
• 개발 : 코드는 개떡이 되어 간다. 어짜피 이건 내 탓이 아니다. 정말 제대로 된 환경에서 했다면, 난 정말 멋지게 해 낼 수 있었을 텐데, 운없이 이런 놈들이랑 팀을 해서 이렇게 된거라 생각한다. 이 제품은 내 손에서 나왔지만, 내가 만든건 아니라 생각한다.
• 리더 : 3개월후, 생각했던게 안나오자 개발자에게 책임 추궁을 해야겠다 생각한다. 처음부터 태도도 안좋았고, 자기가 말한 것을 구현해 낼 실력도 없었던 사람이었다 생각한다. 후회한다. 이 모든 것은 개발의 문제다. 하지만, 일단 출하한다.
• 기획 : 자신의 유럽 명품적 감각의 파워포인트를 어떻게 이런 제3세계 제품으로 만들어 냈는지 의아해 한다.
• 리더 : 다시 시작하자 으쌰 으쌰 해 본다. 그리고, 그 사이 대세가 바뀌지 않았다 살펴 본다.
• 개발 : 어짜피 이렇게 된거, 처음부터 다시 시작하자고 한다. 나는 다시 내가 만든 것을 들여다 보고 싶지 않다.
• 리더 : 역시 중요한 것은 사람이다 라고 생각한다.
  
  

흥하는 제품의 흔한 개발 과정

• 리더 : 자신에게 꼭 필요했던 핵심가치(기능)을 발견한다. 현존하는 타 제품에서는 발견할 수 없기에, 만들어야 겠다고 결심한다.
• 기획,개발 : 자신도 꼭 필요했던 것이라 생각하고, 만들면 정작 자신이 가장 큰 혜택을 받을 것이라 생각한다.
• 리더,기획,개발 : 다 같이 모여서 기존 제품들을 맹렬히 비판해 낸다. 왜 다 이렇게 될 수 밖에 없었는지 생각해 본다.
• 개발 : 관련된 기술을 조사한다. 그리고, 조사한 결과를 공유한다.
• 기획 : 수없이 많은 기술을 가지고, 두개의 연결(조합)을 시도한다. 전혀 상관없을 것이라 생각했던 두가지 기술을 합하니, 매우 멋진 모습이 되었다.
• 리더 : 이 멋진 조합이 핵심가치를 구현하는 결정적 요소가 아니면, 버리자고 한다. 핵심가치에만 촛점을 맞춘다.
• 개발 : 핵심가치를 구현할 가장 단순한 방법을 찾는다. 구현이 단순할 수록 생각치 못한 일이 발생할 가능성이 줄어 든다.
• 리더 : 개발된 시제품을 써 본다. 하루고 이틀이고 계속 써 본다. 불편한 점을 찾거나, 그 보다 더 단순하게 할 방법을 생각해 낸다.
• 개발 : 반복적으로 만들어 낸다. 구현 방법이 단순하였기에, 이 반복과정이 고통스럽지 않다. 이 반복과정을 더 쉽게 할 수 있는 방법을 계속 추가해 낸다.
• 기획 : 이 단순한 핵심가치를 제공하는 이 제품이 생각보다 많은 곳에서 응용될 수 있다는 것을 찾아 낸다.
• 리더 : 기쁘지만, 처음 생각한 것에 집중하기로 한다.
• 리더 : 충분히 만족스러운 상태가 되면 제품으로 출하한다. 충분히 고민한 것이기 때문에, 아주 오랫동안 다시 이 문제를 생각할 필요가 없을 거라 생각한다. 누군가 흉내내면서 새로운 것을 덧붙여 내거나 변형을 시켜내도 크게 신경 쓰지 않는다.
• 기획 : 현재까지 이룩한 것에서 최소한의 노력으로 추가할 수 있는 핵심가치를 다시 찾기 시작한다.
• 리더 : 역시 중요한 것은 사람이다 라고 생각한다.
  
  

1.망하는 제품의 개발 과정은 공감하지만 흥하는 제품의 개발 과정은 공감이 안되는 불편한 진실...
2.흥하든 망하든 결론은 같다는 불편한 진실...

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

1. creating vision (비전제시)
 

기술, 시장동향을 읽어 이를 바탕으로 시스템의 요구사항과 제약사항을 반영한 비전을 만들고 각 이해당사자들의 이해와 공감을 이끌어내야 함

2. the architect as a key technical consultant (핵심기술조언)
 

- PM에게 기술적인 조언자로서의 역할
- 개발팀 구성과 각 팀간 개발 선행 관계 및 종속관계에 대한 조언 및 현실적인 안을 제공
- 개발에 필요한 기술, 교육, 툴을 추천

3. the architect makes decisions (의사결정)
 

설계자들을 이끌고 지도하며 전체 설계에 영향을 미치는 초기단계의 주요 이슈에 대한 의사결정 및 위험요소 정의

4. the architect coaches (코치)
 

- 개발팀 구성원들과 소통하고 설계한 아키텍처 내용을 이해하도록 가르치며 개발팀의 의견을 수렴, 반영
- 설계 된 아키텍처 틀 위에서 개발팀원들이 세부 설계를 통해 설계능력을 키울 수 있도록 지도

5. the architect coordinates (조정)
 

- 아키텍처에 영향을 미치거나 아키텍처에 의해 영향을 받는 이해관계자(Stakeholder)들간의 활동을 조정, 중재
- 각 개발팀들의 설계작업을 통합
- 설계작업이 정의된 아키텍처에 부합하는지 확인, 보장

6. the architect implements (구현능력)
 

- 새로운 기술 도입 시 설계에 미칠 영향을 고려, 기본개념 확인을 위해 상세설계 및 코드레벨까지 고민
- 설계 결정 사항에 대한 검토, 검증을 위한 프로토타입 개발
- 구현 위험의 최소화 및 구현 모델 제시를 위한 샘플 컴포넌트를 구현

7. the architect advocates (대변)
 

- SW Architecture 에 대한 투자를 이끌어 냄
- SW 프로세스에 SW Architecture 가 포함되도록 함
- 지속적인 새로운 아키텍처 기술의 평가 및 도입

출처 : Applied Software Architecture - Christine Hofmeister, 1999 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

단순 스펙만 비교한다면 두 스마트폰의 차이는 거의 없다고 보면 됨.

하지만 현재 등록된 Apps 의 수로 추정 가능한 시장의 가치는 안드로이드에 비해 아이폰이 가진 잠식률이 절대적으로 높으며 이를 추월하기는 쉽지 않다고 판단됨.

DMB 문제는 wi-fi 가 걸려있기는 하나 KT 에서 망 확장 시도를 부단히 하는 것으로 볼 때 각 방송사가 모바일 서비스로 제공하는 App 이 DMB 기능을 대신할 수 있을 것으로 보임.

개발자 입장에서는 폐쇄적인 iOS4 보다는 개방적인 Android 2.2 를 선호할 수 있으나 Open 된 만큼 다양한 변종이 존재하고 있어 이에 대한 대응책도 필요할 것으로 보임.

A/S 에 있어서는 애플의 정책이 변하지 않는 이상 국내에서는 삼성의 월등한 우세로 점쳐짐.

결론)
순수 사용만 하는 소비자 입장에서는 시장이 큰 애플 iPhone 4를 선호할 확률이 높음. 허나 개발자 입장에서는 삼성 Galaxy S를 선호할 듯. 하지만 시장은 개발자의 편이 아님. iPhone 4가 iPhone 3Gs 만큼의 힘을 보여주진 못하더라도 현재의 여론 흐름이나 시장 점유율 등을 비교해 볼 때 판매량 면에서 Galaxy S를 무난히 이길 것으로 판단 됨.

참고로 전 애플빠... 인정합니다.. -_-+

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.