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

• 리더 : 요즘 유행하는 대세를 들고 온다. 이것이 대세다!
• 리더 : 속으로는 이런 것들을 쓰는 사람들은 사회부적응자라 생각하고 본인은 정작 써 본 적이 없다.
• 기획 : 써 본적은 없지만 들어는 봤다. 이런 것을 쓰는 사람은 격이 떨어지는 사람이라 생각하고, 내가 우아하고도 유럽 명품에 견줄 수 있는 것을 보여주어야 겠다 생각한다.
• 기획 : 해당 제품군을 모조리 조사한다. 그래서 해당 제품군의 모든 특징을 합한 고질라 같은 것을 그려 낸다.
• 리더 : 그것만으로는 뛰어 넘을 수 없다고 한다.
• 기획 : 아이디어를 동원한다. 이제 그 고질라에 스타워즈, 반지의 제왕, 해리포터를 더하기 시작한다. 자신의 상상력의 끝은 어디인가 하면서 스스로 놀라워 한다.
• 리더 : 고질라에서 빠진 게 없나 살핀다. 다소 억지 스럽지만, 비슷한류의 제품을 가져와 하나 더 붙인다. 이런게 바로 리더의 통찰력이라 으쓱거린다. 기획자의 아이디어를 보고는 기획자가 미쳐 생각하지 못한 경우의 수를 생각해서, 더 복잡하게 만든다. 아직 가르칠게 많다고 생각한다.
• 개발 : 그런건 못만들어요. 불평을 늘어놓는다.
• 리더 : 내 앞에서 안된다는 말은 하지 말라고 하며, 할 수 없다는 것부터 이야기하는 태도가 문제라고 한다. 그리고는, 자신의 인생 역정기를 늘어 놓는다.
• 개발 : 기획에 대한 조언을 해 줘야 겠다고 생각한다. (사실 해당 제품군을 사용해 본 유일한 사람이다.)
• 리더 : 넌 아직 인지과학, 심리학을 모른다고 일축한다.
• 기획 : 파워포인트로 찍어 내는 노가다를 시작한다.
• 리더 : 문서에서 오타를 찾아 낸다.
• 개발 : 이 프로젝트는 어짜피 산으로 갈 것이라고 떠들어 대기 시작한다.
• 리더 : 최근 세미나에서 본 솔루션들을 쓰면 금방 할 것이라고 말한다. 그리고 비싼 돈을 들여 도입을 추진한다.
• 개발 : 그게 뭔지 모른다. 다만, 대충 들어보니, 그것 보다는 자기간 만들어 놓은 자작 솔루션이 훨씬 더 좋은거라고 속으로 생각한다.(사실 지금 이 상황에 그걸 배워서 만드는 것은 엄두가 나지 않는다) 그리고 쓰는 척 시늉만 하기로 결심한다. 타인이 만든 것을 사용하는 것은 하수들이나 하는 짓이라 생각한다.
• 리더 : 개발기간은 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 대한민국 라이선스에 따라 이용하실 수 있습니다.

(원문주소)
http://www.globalknowledge.com/training/generic.asp?pageid=2347&country=United+States

Ten Dying IT Skills

By Linda Leung

There are some things in life, like good manners, which never go out of style, and there are other things, like clothing styles that fall in and out of fashion, but when an IT skill falls out of favor it rarely ever comes back. Here's our list of 10 dying IT skills. If any of these skills are your main expertise, perhaps it's time to retrain.

1. Asynchronous Transfer Mode: ATM was popular in the late-1990s, particularly among carriers, as the answer to overworked frame relay for wide-area networking. It was considered more scalable than frame relay and offered inherent QoS support. It was also marketed as a LAN platform but that was its weakness. According to Wikipedia, ATM failed to gain wide acceptance in the LAN where IP makes more sense for unifying voice and data on the network. Wikipedia notes that ATM will continue to be deployed by carriers that have committed to existing ATM deployments, but the technology is increasingly challenged by speed and traffic shaping requirements of converged voice and data networks. A growing number of carriers are now using Multi-Protocol Label Switching (MPLS), which integrates the label-switching capabilities of ATM with the packet orientation of IP. IT skills researcher Foote Partners listed ATM in its IT Skills and Certification Pay Index as a noncertified IT skill that has decreased in value in the last six month of 2008.

2. Novell NetWare: Novell's network operating system was the defacto standard for LANs in the 1990s, running on more than 70% of enterprise networks. But Novell failed to compete with the marketing might of Microsoft. Novell tried to put up a good fight by acquiring WordPerfect to compete with Windows Office, but that move failed to ignite the market and Novell eventually sold WordPerfect to Corel in 1996. Novell certifications such as Certified Novell Engineer, Master Certified Novell Engineer, Certified Novell Certified Directory Engineer, and Novell Administrator were once hot certs in the industry but now they are featured in Foote Partners' list of skills that decreased in value in 2008. Hiring managers want Windows Server and Linux skills instead.

3. Visual J++: Skills pay for Microsoft's version of Java declined 37.5% last year, according to the Foote Partners' study. The life of J++, which is available with Microsoft Visual Studio 6.0, was not a smooth one. Although Sun Microsystems licensed Java to Microsoft to develop J++, Microsoft failed to implement some features of the official Java standard while implementing other extensions of its own. Sun sued Microsoft for licensing violations in a legal wrangle that lasted three years. Microsoft eventually replaced J++ with Microsoft .Net.

4. Wireless Application Protocol: Yes, people were able to browse the Internet in the late 1990s before Apple's iPhone. Web site operators would rewrite their content to the WAP's Wireless Markup Language, enabling users to access Web services such as email, stock results and news headlines using their cell phones and PDAs. WAP was not well received at the beginning because WAP sites were slow and lacked the richness of the Web. WAP has also seen different levels of uptake worldwide because of the different wireless regulations and standards around the world. WAP has since evolved and is a feature of Multimedia Messaging Service, but there are now a new generation of competing mobile Web browsers, including Opera Mobile and the iPhone's Safari browser.

5. ColdFusion: ColdFusion users rave that this Web programming language is easy to use and quick to jump into, but as many other independent software tools have experienced, it's hard to compete with products backed by expensive marketing campaigns from Microsoft and others. The language was originally released in 1995 by Allaire, which was acquired by Macromedia (which itself was purchased by Adobe). Today, it superseded by Microsoft .Net, Java, PHP and the language of the moment: open source Ruby on Rails. A quick search of the Indeed.com job aggregator site returned 11,045 jobs seeking PHP skills compared to 2,027 CF jobs. Even Ruby on Rails, which is a much newer technology receiving a major boost when Apple packaged it with OS X v10.5 in 2007, returned 1,550 jobs openings on Indeed.com.

6. RAD/Extreme Programming: Back in the late 1990s and early 2000s the rapid application development and extreme programming development philosophies resulted in quicker and more flexible programming that embraced the ever changing needs of customers during the development process. In XP, developers adapted to changing requirements at any point during the project life rather than attempting to define all requirements at the beginning. In RAD, developers embraced interactive use of structured techniques and prototyping to define users' requirements. The result was accelerated software development. Although the skills were consistently the highest paying in Foote Partners survey since 1999, they began to lose ground in 2003 due to the proliferation of offshore outsourcing of applications development.

7. Siebel: Siebel is one skill that makes a recurring appearance in the Foote Partners' list of skills that have lost their luster. Siebel was synonymous with customer relationship management in the late-90s and early 2000s, and the company dominated the market with a 45% share in 2002. Founded by Thomas Siebel, a former Oracle executive with no love lost for his past employer, Siebel competed aggressively with Oracle until 2006 when it was ultimately acquired by the database giant. Siebel's complex and expensive CRM software required experts to install and manage. That model lost out to the new breed of software-as-a-service (SaaS) packages from companies such as Salesforce.com that deliver comparable software over the Web. According to the U.K.'s ITJobsWatch.com site, Siebel experts command an average salary of GBP52,684 ($78,564), but that's a slide from GBP55,122 a year ago. Siebel is ranked 319 in the job research site's list of jobs in demand, compared to 310 in 2008.

8. SNA: The introduction of IP and other Internet networking technologies into enterprises in the 1990s signaled the demise of IBM's proprietary Systems Network Architecture. According to Wikipedia, the protocol is still used extensively in banks and other financial transaction networks and so SNA skills continue to appear in job ads. But permanent positions seeking SNA skills are few and far between. ITJobsWatch.com noted that there were three opening for permanent jobs between February and April, compared to 43 during the same period last year. Meanwhile, companies such as HP offer consultants with experience in SNA and other legacy skills such as OpenVMS and Tru64 Unix for short-term assignments.

9. HTML: We're not suggesting the Internet is dead but with the proliferation of easy to use WYSIWYG HTML editors enabling non-techies to set up blogs and Web pages, Web site development is no longer a black art. Sure, there's still a need for professional Web developers (see the ColdFusion entry above for a discussion about Java and PHP skills) but a good grasp of HTML isn't the only skill required of a Web developer. Professional developers often have expertise in Java, AJAX, C++ and .Net, among other programming languages. HTML as a skill lost more than 40% of its value between 2001 and 2003, according to Foote Partners.

10. COBOL: Is it dead or alive? This 40-year-old programming language often appears in lists of dying IT skills but it also appears in as many articles about organizations with legacy applications written in Cobol having a hard time seeking workers with Cobol skills. IBM cites statistics that 70% of the world's business data is still being processed by Cobol applications. But how many of these applications will remain in Cobol for the long term? Even IBM is pushing its customers to "build bridges" and use service-oriented architecture to "transform legacy applications and make them part of a fast and flexible IT architecture."

About the Author

Linda Leung is an independent writer/editor in California. Reach Linda at leungllh@gmail.com.

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

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

사내망 팀룸 게시판 펌

http://www.samsung.net/service/tb/TBT?trId=0000003799&boardId=5309&articleSeq=2000108896&topSeq=2000108896&boardType=B&isPortlet=Y

==========================================================================================

1. "오늘까지"라는 말은 "내일 아침까지"라는 말이다.

2. 프로그램은 내가 원하는대로 움직이지 않는다. 타이핑대로 움직인다.

3. 요구 사양은 프로그램을 완성한 후에 추가된다.
   기본 사양은 완성품을 고객이 보고 나서 결정된다.
   상세 사양은 사용자가 프로그램을 사용해 본 이후에 결정된다.

4. 소프트웨어 설계에는 두 개의 방법이 있다.

    하나는 결함이 있을 수 없을 정도로 단순하게 만드는 방법이다.
    다른 하나는, 분명한 결함을 눈치채기 어려울 정도로 복잡하게 만드는 방법이다.

5. 코드는 개발 현장에서 사용하는 것이 아니라 납품처에서 사용하는 것이다.
    디버그는 납기일까지 하는 것이 아니라, 납품된 이후에 하는 것이다.

6. 프로그래머를 죽이기 위해서는 칼이 필요없다. 프로그램의 요구조건을 3번만 바꾸면 된다.

7. 다른 사람을 믿으라. 그 사람이 해결해줄지도 모른다.
    주의사항 - 먼저 자신을 의심해라.

8. 개발에 마지막은 없다. 출시만이 있을 뿐이다.

9. 클라이언트의 요구사항이 제 아무리 뒤늦게 추가되어도 납기일은 변하지 않는다.
    이것을「납기 불변의 법칙」이라고 한다.

10. 우리의 고객들은 물과 기능추가를 공짜라고 생각하고 있다.

11. 주머니가 짠 고객일수록 잔소리가 많다.

12. 개발 스케줄은 산수를 무시하며 짜여진다. 영업과는 1＋1=2를 이해하지 못하는 사람의 모임이다.

13. 한 명이 쓰러지면 모두가 쓰러진다.

14. 버그가 너무 심하다? 걱정마라. 어느 순간 그것은 기본 사양이 될 것이다.

15. 좋은 설계는 한 명의 천재보다 세 명의 범재를 요구한다.
     나쁜 설계는 백명의 범재보다 한 명의 천재를 요구한다.

16. 고객에게 시스템 엔지니어는 부하이며, 프로그래머는 가축이다.
     시스템 엔지니어에게 고객은 돈이다.
     프로그래머에게 고객은 보이지 않는 악성 바이러스다.

17. 돈과 시간만 있으면, 그 어떤 시스템이라도 만들 수 있다고 생각하는가?
      웃어라. 그 기회는 영원히 주어지지 않는다.

18. 품질은 사양 변경의 수와 규모에 의해, 얼마나 열화될지 결정된다.

19. 영업과는 공상이 실현된다고 생각하는 몽상가이다.
      시스템 엔지니어는 넘을 수 없는 벽이 없다고 믿는 모험가이다.
      프로그래머와는 몽상가와 모험가에 의해 칠흑의 바다에 내던져진 표류자이다.

20. 유능한 프로그래머가 프로그램 설계개념도를 받아들고 최초로 하는 일은, 프로그램의
     목적을 이해하는 것이다. 그리고 그 다음으로 하는 일은, 지정된 방법과 시간 안에는
     도저히 그 목적을 완수할 수 없다는 사실을 시스템 엔지니어에게 이해시키는 일이다.

21. 프로그램이란, 운과 감에 의해서 작성되는 기적이다.
      운과 감이 없다면, 그 기간 내에 그러한 목표를 실현될 수 있을 리 없다.
      따라서 사양 변경은 기적에 트집을 잡는 건방진 행위이며, 사양 추가는 기적이 두 번
      일어날 것으로 믿는 무모한 행위이다.

22. 시스템 엔지니어는 지구력, 프로그래머는 순발력.

23. 정시에 퇴근하면, 일이 늘어난다.

24. 완벽한 프로그램은 완벽한 시간과 돈을 필요로 한다.
      미국의 국가 예산을 무제한으로 사용하는 NASA마저도, 아직 시간과 돈이 부족하다고 한다.

25. 눈으로 훑어볼 틈이 있다면 움직여라. 뇌세포보다 CPU가 더 해석이 빠르다. 그리고, 그 사이,
      쉴 수 있다.

26. 불편함을 버그라고 부를 것인가, 사양 상의 제한 사항이라고 부를 것인가는 남겨진 개발일자와
     납기일에 의해 결정된다.

27. 정장 대신 캐쥬얼을 입고 출근하는 "캐쥬얼 데이"를 세간에서는 휴일이나 공휴일이라고 부르는
      것 같다.

28. 프로그램은 머리로 기억하지 않는다. 몸으로 기억한다.

29. 내일 쉴 수 있다면 오늘 죽어도 괜찮다.

30. 고객은 거짓말을 한다.
      영업은 꿈을 말한다.
      시스템 엔지니어는 공상을 이야기한다.
      프로그래머는 과묵해진다. (혼잣말은 많아진다)

31.「네, 할 수 있습니다」라고 말하기 전에 10초만 곰곰히 다시 생각해보라.

32. 프로그래머는 1분 생각하고 1일을 코딩에 소비한다.
      1시간 생각하고 1시간 코딩하는 대신에 말이다.

33. 납품 이후의 디버그는 버그를 부른다.

34. 세 개의 디버그는 하나의 버그를 낳는다. 이것을 버그의 엔드리스 루프라고 한다.

35. 안 좋은 예감은 반드시 적중한다. 그러나 프로그래머는 그 안 좋은 예감에 반응하지
      않는다. 그것은 시스템 엔지니어의 일이다.

36. 아수라장을 해결할 수 있는 방법은 오직, 고객이 돈을 지불하는 것 뿐이다.

37. 아마추어는 버그발견의 천재이다.

38. 아, 그건 마이크로소프트에서만 가능한 주문입니다.

39. 프로그래머가 불만이라고 생각하는 부분은 고객도 반드시 불만이라고 생각한다.

40. 건강하기 때문에, 건강을 해친다.

41. 그건, 당신이 말한 요구조건입니다만.

42. 아, 개발실의 창문은 안 열립니다. 그 이유는 옛날에 한 프로그래머가 그 창문에서···

43. 고객은 최악의 사태를 믿지 않으며, 그 사태에 대한 준비를 악질적인 비용청구라고 생각한다.
      시스템 엔지니어는 최악의 사태를 대비하고 준비하려 한다.
      프로그래머는 최악의 사태를 누구보다 잘 예상하지만, 무시한다.

44. 만약 다른 직업을 갖게 된다면, 정시퇴근을「도망」이라고 부르지 않는 직업이 좋을 것 같다.

45. 시스템 엔지니어가 프로그래머에게 말하는「상식」은 3시간마다 변한다.

46. 최소한 자기가 쓴 시방서는 읽어주세요.

47. 고객이 시스템 엔지니어에게 사랑받는 방법은, 시스템 개발에는 시간이 곧 돈이라는 사실을
      깨닫고 빨리 최종요구조건을 확정하는 것이다.

     SE가 고객에게  사랑받는 방법은, 프로그래머에게 미움받는 것이다.

48. 납기일이란, 작업현장이 우리 회사에서 고객의 회사로 바뀌는 날을 의미한다.

49. 가끔 일어나는 버그는 버그가 아니다. 스펙이다.

50. 개발비의 30%는 프로그램의 요구조건을 확정하는데 사용된다.
     개발비의 30%는 프로그램의 요구조건을 변경하는데 사용된다.
     개발비의 30%는 프로그램의 버그를 잡는데 사용된다.
     개발비의 10%만이 프로그램의 개발에 사용된다.

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

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

네티켓의 10가지 기본 원칙'은 가상공간상에서 우리가 갖춰야 할 행동양식에 대한 원칙들로 버지니아 셰어(Virginia Shea)가 제시한 'The Core Rules of Netiquette'에 기초를 두고 있다.
현재 국내외적으로 네티켓을 위해 특별히 정해진 원칙이 있는 것은 아니며, 우리가 나름대로 일정한 논리를 가지고 원칙들을 마련해 나감으로써 건전한 통신 이용 환경을 조성해 나가려는 노력을 해야 할 것이다.

<1원칙> 상대방도 나와 같은 인간이다
가상공간에서 우리가 명심해야 할 가장 기본적인 태도는 상대방이 나와 같은 생각을 하는 실제 인간이라는 점이다. 많은 사람들이 전자적으로 대화할 때, 보이는 것은 컴퓨터 스크린뿐이므로 상대방이 인간임을 간과하는 경우가 있다.

상대방과 서로 대면하지 않고도 의사를 전달할 수 있다는 매체의 특성과 익명성을 악용해 때론 음란하고 무례한 행동을 하기도 하고, 실생활에서는 할 수 없는 부분까지도 허용될 것이라는 착각을 하는 경우가 있다.
따라서 통신상에서 글을 게재하거나 메일을 띄울 때, "나는 지금 사람의 얼굴을 마주하고 이야기하고 있는가?"라는 질문을 스스로에게 던져볼 필요가 있다.
다시 말해 가상공간에는 보이지 않는 실제 사람들이 존재함을 명심해야 한다.

<2원칙> 실제생활과 똑같은 기준과 행동을 고수하라
실생활에서 대부분의 사람들은 처분을 받거나 적발될 수 있다는 두려움 때문에 그런대로 법을 준수하지만,
가상공간상에서는 윤리기준이나 인간적인 행동규범의 적용을 덜 받는다고 생각하기도 한다.
이로 인한 혼란은 이해가 가지만, 이러한 생각 자체는 잘못된 것이다.
사이버공간 상에서의 행동기준은 다소 차이가 있지만, 실생활보다 적은 규제를 받는 것은 아니다.
사이버 공간에서의 윤리적인 딜레마에 빠질 경우, 실생활의 규범을 참고해 적절한 해결책을 찾는 것이
바람직하다.

<3원칙> 현재 자신이 어떤 곳에 접속해 있는지 알고, 그곳 문화에 어울리게 행동하라
네티켓은 해당 영역마다 다양하다. 어떤 영역에서는 이상적으로 허용되는 것이 타 영역에서는 몹시 무례한 것으로 보일 수 있다. 이처럼 서로 다른 영역에서는 네티켓 또한 다르기 때문에 당신이 어느 곳에 접속해 있는지 아는 것은 매우 중요하다.
따라서 가상공간에 새롭게 참여하고자 할 때에는 그 환경을 잘 파악해야 한다.
채팅하는 것을 들여다보거나 게재된 글을 읽어보는 등의 준비를 통해 그곳에 소속된 사람들과 그들의 생각을 파악하고 난 후 참여하도록 한다.

<4원칙> 다른 사람의 시간을 존중하라
메일을 보내거나 토론 그룹에 글을 띄울 때, 다른 사람들의 시간에 대해 충분히 배려하자.
즉, 글을 읽게 되는 다른 사람들이 시간을 허비하지 않도록 하는 것은 글을 올리는 사람 각자의 책임이다.
특히 시간과 대역폭(사이버 공간상에서 모든 사람들이 통신회선과 채널을 통해 정보를 가져오는데 소요되는 시간이나 저장용량)을 잘 감안해야 한다.
따라서 어떠한 글을 올리기 전에 다른 사람들이 진정 그것을 알고 싶어하는지 따져봐야 하며, 만일 다른 사람들이 원하지 않는 정보라면, 그들의 시간을 빼앗지 않도록 해야 할 것이다.

<5원칙> 온라인상의 당신 자신을 근사하게 만들어라
온라인상에서는 익명성이라는 특성으로 인해 자신의 외양이나 행동보다는 그 사람이 쓴 글의 수준에 따라 평가받게 된다. 따라서 글의 내용에 주의를 기울이고 당신이 무엇에 대해 이야기하는가를 명확히 하는 것이 중요하다.
단락별로 철자나 문법의 오류없이 완벽하게 글을 쓰는 것은 가능하겠지만, 아무리 그렇더라도 의미가 명확하지 않을 수 있다. 따라서 당신이 쓴 글을 명확하고 논리적으로 만들려는 노력을 해야 한다.
또한 공격적인 언어 사용을 자제하고, 기분좋고 정중한 표현을 사용해야 한다.

<6원칙> 전문적인 지식을 공유하라
가상공간의 힘은 바로 그 수에 있다. 온라인상에서 질문을 하면 수많은 지식을 보유한 사람들이 그 질문을 읽게 되고, 그들 중 일부만이 재치있는 답변을 하게 되더라도 세계의 지식을 모두 모아놓은 듯한 효과를 얻을 수 있다.
내가 아는 무언가를 공유하고자 할 때, 남에게 큰 도움이 되지 않을지 모른다고 두려워 할 필요는 없다.
특히 내가 질문한 내용의 결과를 공유하는 것은 예의바른 태도라고 할 수 있다. 당신이 지닌 지식을 공유하는 것은 즐거운 일이다. 이는 네트워크 상의 오랜 전통이며, 세상을 좀더 좋게 만들어 주는 역할을 한다.

<7원칙> 논쟁은 감정을 절제하고 행하라
'논쟁'은 어떠한 격렬한 감정을 절제하지 않고 강하게 표현할 때 생겨난다.
논쟁은 오랜 동안 지속돼온 관행이며, 많은 흥미를 유발시킬 수 있는 요소로 네티켓에서는 이를 허용하고 있다. 하지만 논쟁을 지속하는 것은 금한다.
논쟁의 시작단계에서는 많은 사람들의 흥미를 끌 수 있으나, 격렬한 논쟁이 지속될 경우 이에 끼여 들고 싶지 않는 사람들은 곧 싫증을 내게 된다. 따라서 지속적인 논쟁은 토론 그룹의 분위기를 지배하거나 그룹원간 우애를 깨뜨릴 수 있으므로 유의해야 한다.

<8원칙> 다른 사람의 사생활을 존중하라
아무리 가상공간에서 이뤄지는 부분이지만, 다른 사람의 사생활을 존중하는 마음이 없다는 것은 '네티켓이 안좋다'는 평가만으로 그치지 않는다.
그것은 또한 자신의 일에도 피해를 주게 되므로 전자우편을 비롯한 상대방의 정보를 훔쳐보거나 허가없이 복사해 배포하는 등, 타인의 사적인 영역을 함부로 침범해서는 안된다.

<9원칙> 당신의 권력을 남용하지 말라
사이버공간에서 어떤 사람들은 다른 사람들보다 더 많은 권한을 가진다.
일상사무에 능하거나 모든 시스템을 관리하는 사람처럼 이 공간에서도 재능을 보이는 사람이 있다.
다른 사람들보다 좀더 잘 안다거나 그들이 하는 일 보다 더 많은 권한을 지닌다고 해서 그들을 이용할 수 있는 권리를 주는 것은 아니라는 것에 주의하자.

<10원칙> 다른 사람의 실수를 용서하라
누구나 처음엔 네트워크 초보자였다. 따라서 누군가 실수를 할 때에도 친절을 베풀 줄 알아야 한다.
그것이 아주 사소한 실수라면 그냥 넘기도록 하고, 비록 크다고 해도 정중하게 지적만 하도록 한다.
타인의 실수를 지적할 때도 신중하게 다시한번 생각하고, 공개적으로 드러내지 않고 개인 메일을 보내도록
한다. 의심이 가는 부분들에 대해서는 당사자가 '더 좋은 무언가를 알지 못했다'고 가정하고 좋게 해석하도록 한다.

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

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