제대로 배우자, 자바스크립트(Javascript) #1 – 시작

I. 프롤로그

서울도서관에서 책을 빌렸다. 책 제목은  <Do it! 쉽게 배우는 웹앱 & 하이브리드앱>이다. 책을 빠르게 훑어보다가 아래 문구를 봤다. 그리고 생각했다.

시바

원래 자바스크립트는 브라우저에서 실행되는 자바 언어를 기반으로 한 스크립트 언어로 시작하였으나… – <Do it! 쉽게 배우는 웹앱 & 하이브리드앱> 22쪽

“자바 언어를 기반으로 한” 이라는 표현 때문에 JavaScript는 Java와 유사한 언어라는 착각을 줄 수 있다. 아니다. 그렇다면 제대로 된 역사에 대해 알아보자.

II. 자바스크립트의 역사

자바스크립트는 Netscape에 입사한 브랜든 에이크(Brendan Eich)가 1995년 5월에 개발했다. 처음 이름은 Mocha였고 LiveScript라는 이름을 썼다가 최종적으로는 JavaScript가 되었다. 처음에는 클라이언트(브라우저)에서 작동하는 언어로 개발되었지만 이제 서버에서도 쓰인다. 몇 년 전에 화제가 되었던 Node.js가 가장 대표적인 서버사이드 자바스크립트 기술이다.

JavaScript의 공식 명칭은 ECMAScript로 ECMA-262 명세를 기반으로 한다. 이는 듣보잡 JavaScript 변종을 없애기 위한 표준단체 노력의 일환이다. 대표적인 듣보잡의 예로는 JScript가 있다.

자바스크립트가 외형적으로는 당시 인터넷 언어로 자신을 홍보하던 Java를 따라한 것이 맞다. 하지만 이는 겉모습에 불과할 뿐 본질은 전혀 다르다. 어디가서 JavaScript는 Java를 기반으로 한 언어라고 하면 쪽팔림은 당신의 몫이다.

1995년 4월 브랜든 에이크(Brendan Eich)는 웹 브라우저에 내장되는 스킴(Scheme) 언어를 만들기 위해 넷스케이프에 입사한다. 당시 넷스케이프에선 웹 브라우저에 내장되는 언어의 필요성을 인식하고 있었으나 그 내막엔 미묘한 이견이 있었다. 이제 막 오크(Oak)에서 이름을 바꾼 자바(Java)가 본격적인 ‘인터넷 언어’로 브랜딩을 하고 있었고 넷스케이프에선 이 언어를 브라우저에 내장하기 위해 썬 사와 협상을 벌이는 중이었다(실제로 1995년 10월에 나온 넷스케이프 2.01B 버전은 자바를 탑재했다). 자바가 브라우저를 위한 인터넷 언어로 탑재되는 것이 가시화하자 넷스케이프 내부에서는 ‘브라우저에 또 하나의 언어가 필요한가’라는 논쟁이 자연스럽게 벌어졌다.

넷스케이프에선 두 종류의 언어가 필요하다는 결론을 내렸다. 하나는 진지하고 전문적인 프로그래머들을 위한 복잡한 언어, 즉 자바이고, 다른 하나는 아마추어나 디자이너를 위한 ‘스크립트’ 언어였다. HTML 안에 포함되어 동작하며 쉽고 가벼운 언어가 필요하다는 후자의 생각은 마크 앤드리슨, 빌 조이와 같은 IT 업계 거장들도 동의하는 사실이었고 이는 에이크가 만들 언어가 복잡한 괄호들로 가득 찬 신비로운 스킴이 아니라 ‘자바나 C 같이 보이는’ 그리고 ‘쉬워 보이는’ 언어여야 한다는 사실을 의미했다.

(중략)

에이크는 요구대로 스킴이 아닌 ‘자바처럼 보이는’ 스크립트 언어를 만든다. 하지만 그는 열흘 만에 기본 객체(built-in)들이 포함된 인터프리터를 만들면서도 자신의 본래 목적인 스킴의 함수형 언어적인 특성들을 최대한 모방해 자바스크립트를 높은 수준의 함수형 언어로 만들었다. 실제로 자바스크립트는 함수형 스타일의 좋은 교과서라 할 수 있는 SICP의 여러 예제를 거의 스킴과 같은 수준으로 따라할 수 있다. 단지 C 언어처럼 보일 뿐이며, 스킴과 다르게 꼬리 재귀(tail recursion)를 지원하지 않는다.

출처: 그 동안 몰랐던 서버 사이드 자바스크립트 이야기, Part 1: 다시 보는 자바스크립트의 역사

JavaScript 하면 나오는 Douglas Crockford의 글 또한 이름만 비슷할 뿐, JavaScript는 Java와 전혀 유사하지 않다고 주장한다.

The Java- prefix suggests that JavaScript is somehow related to Java, that it is a subset or less capable version of Java. It seems that the name was intentionally selected to create confusion, and from confusion comes misunderstanding. JavaScript is not interpreted Java. Java is interpreted Java. JavaScript is a different language.

JavaScript has a syntactic similarity to Java, much as Java has to C. But it is no more a subset of Java than Java is a subset of C. It is better than Java in the applications that Java (fka Oak) was originally intended for.

JavaScript was not developed at Sun Microsystems, the home of Java. JavaScript was developed at Netscape. It was originally called LiveScript, but that name wasn’t confusing enough.

The -Script suffix suggests that it is not a real programming language, that a scripting language is less than a programming language. But it is really a matter of specialization. Compared to C, JavaScript trades performance for expressive power and dynamism.

Source: JavaScript: The World Most Misunderstood Programming Language by Douglas Crockford

III. 마치면서

JavaScript의 역사에 대해 간단히 살펴봤다. 이제 어디가서 JavaScript는 Java를 기반으로 한 언어라고 말하지 말자. JavaScript 역사에 대한 더 좋은 자료는 <The Past, Present, and Future of JavaScript>를 참고하기 바란다.

테스팅 일반 원리 (7 Testing Principles)

선릉역 7번 출구 APEX 6층에 위치한 STA 교육센터에서 Software Testing Foundation (75차) 과정을 듣고 있다.

1일차 오전 수업 중에 김선준 컨설턴트님이 소개한 테스팅 일반 원리(7 Testing Principles)를 간략히 소개하고자 한다.

테스팅 일반 원리(7 Testing Principles)

  1. 테스팅은 결함이 존재함을 밝히는 것 (Testing shows presence of defects)
  2. 완벽한 테스팅은 불가함 (Exhaustive testing is imposible)
  3. 개발 초기에 테스팅을 시작해야 함 (Early testing)
  4. 결함에 집중해야 함 (Defect clustering)
  5. 살충제 패러독스 (Pesticide paradox) 방지 필요
  6. 테스팅은 정황(Context)에 의존적 (Testing is context dependent)
  7. 오류-부재의 궤변 (Absence-of-erros fallacy)

하나씩 순서대로 알아보자.

1. 테스팅은 결함이 존재함을 밝히는 것 (Testing shows presence of defects)

테스팅의 목적을 의미한다. 테스팅은 결함(defects 또는 faults)을 들춰내는 활동임을 기억하자.

2. 완벽한 테스팅은 불가함 (Exhaustive testing is imposible)

모든 자원을 사용해도 결함이 없는 테스팅은 수행이 불가. 무한 경로, 무한 입력, 무한 타이밍 등 때문에 100%(예: 윈도우즈 계산기 테스팅도 100% 완벽하게 할 수 없음. 왜냐하면 무한한 입력이 존재하기 때문)

3. 개발 초기에 테스팅을 시작해야 함 (Early testing)

이는 무엇보다 소프트웨어 개발 비용 때문임. 테스트를 초기에 해야 버그 수정에 드는 비용이 줄어듬. 소프트웨어 개발 생명 주기(Software Development Life Cycle)의 첫 단계인 요구사항 분석(Requirement Analysis) 때 테스트 생명 주기(Test Life Cycle)를 시작해야 함을 의미함.

테스트 생명 주기(Test Life Cycle)은 아래의 다섯 단계로 이루어짐.

A. Test Planning and Control

B. Test Analysis and Design

C. Test Implementation and Execution

D. Evaluating Exit Criteria and Reporting

E. Test Closure Activities

자세한 내용은 별개 포스팅 할 예정. 구글링 하면 많은 자료가 나올 것 같음. 구글만세 :-p

4. 결함에 집중해야 함 (Defect clustering)

결함이 발견되었거나 결함이 발견될 만한 영역에 집중해서 테스트를 수행해야 함. 결함이 발견된 곳 혹은 근방에 결함이 있을 확률이 높기 때문이다.

5. 살충제 패러독스 (Pesticide paradox) 방지 필요

살충제를 계속 사용하면 벌레가 살충제에 내성이 생겨 더이상 죽지 않는 것처럼 반복적으로 사용하는 테스트 케이스 또한 소프트웨어에서 발생하는 버그에 내성이 생길 수 있음.

따라서 결함이 나올법한 테스트 케이스(Test Cases)를 계속해서 만들어야 함. 이미 성공했던 테스트 케이스에만 의존하면 버그 또한 테스트 케이스에 내성이 생겨서 버그를 쉽게 찾을 수 없음.

주기적인 테스트 케이스의 업데이트를 해야 하는 이유이다.

6. 정황(Context)에 의존적 (Testing is context dependent)

테스팅은 무엇을 테스트하느냐에 따라 달라질 수 밖에 없음. 예를 들어 Remote Controller를 테스트 할 때와 원자력 발전소의 어떤 기능을 테스트하는 것은 테스팅 방법과 수준이 다름.

There is no one-size-fits-all solution in software testing.

7. 오류-부재의 궤변 (Absence-of-erros fallacy)

개발한 시스템의 사용자의 필요와 기대에 부응하지 못해 쓸모가 없다면 결함을 찾는 활동도 의미가 없음을 의마한다.

예를 들어, 어떤 소프트웨어를 테스트한 결과 결함이 없음이 밝혀지더라도 그 소프트웨어가 사용자의 요구사항을 만족하지 못한다면 소위 말하는 뻘짓을 했다고 볼 수 있음.

추가로 이 링크를 참고하면 여기서 설명한 내용을 이해하는 데 큰 도움이 된다.