프로그래머들에게 여자가 없는 이유.

에이다 러브레이스(1815~1852)의 저주 때문이라는 군요.
재미있는 글입니다. 한번 읽어보세요. ^^

http://reric.com/wp/2008/05/19/713

전 결혼도 했으니, 이 저주가 저는 비껴간 모양입니다. ^^;

오프라인 무료 C# 강의.

이번 주부터 매주 토요일 오전 9시에 2시간씩 오프라인 무료 C# 강의를 시작할 예정입니다. 국제 청소년 연합에서 일하고 있는 아내가 자기 팀원에게 프로그래밍을 가르쳐달라고 부탁을 해서 준비를 하고 있는데, 소문을 들은 분들이 이곳 저곳에서 또 부탁을 하셔서 참여 인원이 3명으로 늘었습니다.

밥상은 다 차려놨으니 숟가락만 올려놓으면 같이 먹을 수 있습니다. 참여 의지가 있으신 분들은 이번 주 목요일(6월 13일)까지 seanlab@gmail.com 으로 전화번호와 성함을 비롯한 간단한 자기 소개를 보내주세요. 두 분만 더 받도록 하겠습니다.(장소가 넉넉하게 확보되면 인원을 늘릴 수도 있습니다.)

진지한 마음으로 공부하실 분들께서 오시면 좋겠습니다. 실습을 할 수 있는 환경이 되지 않고 교재만으로만 강의를 할 예정이기 때문에, 혼자서 성실하게 예습+복습+숙제를 하지 않는다면 아무리 강의를 들어도 아무 소용이 없기 때문입니다.

준비물은 교재와 노트 한권이고 장소는 양재동에 있는 "기쁜소식 강남교회"입니다. 물론 교재는 "클릭하세요 C# 2.0 프로그래밍"을 사용합니다.

많은 신청 기다리겠습니다. ^^

개발자가 버려야 할 가정[1] : CPU는 하나의 코어를 갖고 있다.

우리는 지금까지(또는 얼마 전까지) 컴퓨터의 CPU는 하나이며, 또 이 CPU는 하나의 코어만을 갖고 있다는 가정하에 소프트웨어를 개발해 왔습니다. 하지만 더 이상 이는 사실이 아닙니다.

멀티 코어를 효율적으로 다루기 위한 병렬 프로그래밍에 대한 지식 기반은 프로그래머의 필수 자질이 되었습니다. 아래는 ZDNET과 INTEL에서 제공하는 동영상 강좌입니다. 짬 내서 들어보세요.

http://www.zdnet.co.kr/events/2007/intelWB/intelWB_01.htm

병렬 프로그래밍을 (쉽게 하기) 위한 언어의 확장이나 라이브러리, 또는 표준 같은 것들이 어서 나왔으면 좋겠습니다. 닷넷 개발자들은 PFX를 참고하세요.

Java에는 왜 전처리기가 없을까?

Java에는 왜 전처리기가 없을까요? 이것 역시 복잡성을 제거하기 위해서라고 합니다.

전처리기를 요구하는 개발자도 상당히 많고, 이를 대신해서 사용할 꼼수(하지만 그 어느것도 궁극적인 해답이 될 수 없음)도 여럿 등장했는데도 왜 고슬링은 전처리기를 넣어주지 않을까요? 전처리기만 있으면 컴파일 매개 변수만 바꿔주면 될 것을, 소스 코드를 일일이 바꾸거나 런타임에서 조건을 체크해야 합니다.

결국 저는 오늘 하루종일 이 궁리 저 궁리를 하다가 Facade 를 만들고 그 안에 기존의 클래스와 새로운 병행 버전의 클래스를 넣기로 했습니다. 그리고 기존 클래스의 레퍼런스를 추적해서 Facade를 거쳐 객체를 사용하도록 바꾸고요.

예쁘고 가지런했던 코드중의 한쪽이 다른 모양으로 바뀌어서 속상하네요. 이럴 때면 "처음부터 다시 만들고 싶다."라는 악마의 속삭임이 시작되지만, 저는 귀차니즘이라는 천사의 도움을 받아 위기를 극복합니다.

그나저나 고슬링, Java 7에서는 전처리기 좀 넣어주지 않겠습니까?

고슬링, 다음 Java 버전에서는 unsigned 좀 부탁해요.

제임스 고슬링 가라사대,
"In programming language design,
one of the standard problems is that the language grows so complex that nobody can understand it.
One of the little experiments I tried was asking people about the rules for unsigned arithmetic in C.
It turns out nobody understands how unsigned arithmetic in C works.
There are a few obvious things that people understand, but many people don't understand it."

요약하면 unsigned 타입은 불필요한 복잡성만 부르기 때문에 자바에 넣지 않았다는 겁니다.

하지만 기존의 C/C++ 소프트웨어들, unsigned 타입을 지원하는 또 다른 언어와 상호 운용성을 제공하기 위해서는 이 점은 치명적인 약점입니다. 간단한 통신 프로그램을 작성하려 그래도 C 언어로 작성한 프로그램에서 unsigned 데이터를 패킷에 담아 보내기라도 하면 요 녀석을 요리하는데 여간 귀찮은 것이 아닙니다.

오, 저기 자바 전문가께서 한 말씀 하시는군요. "그런 건 JNI를 이용하면 되잖아." JNI는 두 가지 이유에서 답이 아닙니다.

   1. Native에서 unsigned로 처리를 한다 해도 이 녀석을 다시 Java의 타입 세계로 불러들이려면 어차피 같은 일을 또 해야 합니다.
  2. 복잡성 때문에 unsigned를 뺐다고 하면서 더 복잡한 JNI를 권하는 것은 모순입니다.

물론, 이런 일을 처리하는 유틸리티 클래스를 만들어서 쓰면 어느 정도 일이 줄기는 합니다만unsigned 데이터를 다루기 위해 원래 데이터의 2배나 되는 타입을 선택해야 하고, 이로 인해 발생하는 계산의 "귀찮음"은 여전히 남습니다. 이런 일은 그렇지 않아도 다른 논리로 복잡한 프로그래머의 머리를 더 피곤하게 만듭니다.

그러니 부탁입니다, 제임스 고슬링.
제발 다음 버전의 Java에서는 unsigned 타입을 넣어주세요.

생각하고 기록하고 코딩하기.

생각을 정리하는 데 종이와 연필만한 것은 없는 것 같습니다.

마인드 맵도 상당히 쓸만합니다만, 마우스와 키보드가 연필만큼 빠르게 생각의 기록을 해내진 못합니다. (마우스가 원래 만들어진 목적이 사용자 입력을 지연시키는 것이었으니 어찌보면 당연하지요.)

연필은 순서도, 클래스 다이어그램, 시퀀스 다이어그램, ER다이어그램 등 그리지 못하는 것이 없습니다. 아주 똑똑하고 숙련된 개발자는 PC 앞에서 슥슥 그려서 모든 설계를 끝내기도 하지만, 저는 이 싸고 좋은 도구를 선호하는 편입니다(물론 팀에 배포할 때는 비지오와 워드를 이용해서 정리를 합니다!).

OMCS 증후군으로 아십니까? OMCS는 One More Compile Syndrom, "한번만 더 컴파일! 증후군"입니다. 코드를 작성하고 나서 컴파일해서 실행해 보고, 컴파일해서 실행해 보는 방식으로 프로그램을 만드는 프로그래머들을 본 적이 있다면, 이 병에 걸려있다고 보시면 됩니다(뜨끔?).

자신이 작성해야 하는 로직을 완벽하게 설계를 해놓지 않고(설계가 필수적인 것은 아닙니다. 당신의 두뇌가 기억을 잃지 않는 비휘발성이라면 말이죠.), 또는 이해가 불충분한 상태에서 프로그래밍을 하게 되면 프로그램은 "당연히" 원하는 결과를 내놓지 않습니다. 설사 운 좋게 원하는 결과가 나온다 하더라도 조금만 파라미터를 달리 주면 엉뚱하게 동작하는 경우가 대부분이죠.

이제 컴파일과 링크가 끝나고 최초의 실행 파일(또는 웹페이지)이 생겼습니다. 프로그래머는 이 프로그램에 입력값을 바꿔 주어가며 테스트를 합니다. 당연히 에러가 나고 프로그램이 죽기도 합니다. 그리고 각 입력값에 대해 If 문으로 예외 처리를 하기 시작합니다. 테스트가 진행되면 진행될 수록 if를 이용한 예외 처리가 늘어납니다. 상황은 악화되어서, 어느 순간부터는 앞에 작성한 코드를 왜 그렇게 만들어 놨는지 기억이 나지 않습니다. 그렇다고 코드를 간소화 하자니 답이 안 나옵니다. (이런 코드는 여러 사람의 만수무강에 지장을 줍니다.)

연필을 이용해서 로직을 설계 해봤다면 어땠을까요? 해당 로직이 가질 수 있는 경계값(최소/최대) 파라미터, 일으킬 수 있는 예외, 호출자가 해당 로직으로부터 알고 싶어할 결과 등등을 노트에 차근차근 기록했다면 말입니다.

사람은 완벽하지 않습니다. "완벽하지 않다"보다 오히려 "실수 투성이다"라는 표현이 더 어울리지요. 따라서 설계에도 실수가 있을 수 있습니다. 하지만 코딩하고 컴파일을 반복하는 횟수(그 절반만이라도)만큼만 설계에 공을 들인다면 설계의 완성도는 올라가고, 코딩의 고통(?)은 훨씬 줄어들 것입니다.

연필이 마음에 안든다고요? 도구는 상관없습니다. 저는 펜보다 HWP가 더 자유로운 행정병 출신 프로그래머들도 여럿 봤습니다(키보드 만으로 사무실 책상 배치도를 그리는 모습을 봤는데, 경악스럽더군요.). 생각하고 코딩하라는 이야기를 보통 많이들 합니다만. 저는 이 말에 뭔가 빠졌다고 생각합니다.

생각은 휘발성이기 때문에 코딩하면서는 그 수많은 생각들이 4차원 세계로 날아가버리지요. 종이든, 파일이든, 또는 양쪽이든, 생각을 기록한 후에 코딩을 시작해 보세요. 매 프로젝트가 끝날 대마다, 여러분은 고민과 사유 과정이 담긴 노트를 하나씩 얻게 될 것입니다.

07.9.17 19:10 추가.
- (거창한)소프트웨어의 설계에 대한 실용성에 의심을 하고 계신 분이나, 거창하게 UML 툴을 열어놓고 고민하는 시간이 많다면, 이 방법을 적극 추천해 드립니다.

- 이 노트는 제가 전에 다니던 회사의 팀장님께 배운(?) 겁니다. 팀장님께서는 항상 노트(이렇게 설계가 담긴 노트를 애지중지 하셨더랬죠. ㅋㅋ)에 소프트웨어 설계를 하셨는데(공유해야 하는 내용은 항상 전자 문서화해서 배포하셨습니다.), 팀장님께서 작성하신 코드는 버그가 드물었던 기억이 납니다. (물론 안전하고 성능이 좋은 코드를 위한 장치를 라이브러리 레벨에서 많이 준비해 놓으신 이유도 한 몫 했을 겁니다.)

C# 3.0 서적 집필에 대한 고민.

여러분들이 책을 많이 읽어주셔서, 집필 의뢰가 계속 들어오고 있습니다. ^^

다름 아닌 내년 초에 출시될 것으로 예상되는 Visual Studio 2008 에 관련한 집필 의뢰인데요,
고민이 상당히 큽니다.

우선 C#에 대한 고민. C# 3.0과 .NET Framework 3.0이 새로 들고 나오는 특징들 때문에 기존의 책 두께를 유지하기가 어렵게 됐습니다. 최소한 300페이지는 더 늘어날 거라는 것이 제 생각입니다. 이 정도 두께가 되면 읽기가 굉장히 부담스러워지지요. 또 책의 예제들이 윈도우 폼을 중심으로 되어 있었는데, WPF로 다시 구성해야 하는가라는 문제도 생겼습니다. 어쩌면 이제 C# 언어와 .NET Framework 부분을 별도의 권으로 나눠 집필해야 하는 때가 온 건 아닌가 하는 생각이 듭니다.

그리고 비주얼 C++에 대한 고민. 얘는 오히려 바뀐 것이 별로 없어서 고민입니다. 현재 VC6로 개발하는 프로그래머들이 많은데 큰 변화(예, 소소한 개선은 있습니다.)가 없는 VC++ 2008 서적이 필요한가? 하는 생각을 하고 있습니다. (물론 새로운 내용이 들어가는 것만이 집필의 의미를 주는 것은 아닙니다. 기존의 내용 자체를 더 알기 쉽게 업그레이드 하는 것도 의의를 줄 수 있습니다.)

마지막으로 타이밍에 대한 고민. 비스타의 보급이 지지부진한 상황에서 VS2008을 선택하는 개발자(또는 회사)가 얼마나 될 것인가. 또 이를 가르치려 하는 학교는 얼마나 될 것인가(비스타를 설치하기 위해 OS와 하드웨어를 새로 구입하는 것은 굉장한 예산을 필요로 합니다.). 제 생각에는 적어도 "지금은 아니다"라는 판단을 하고 있습니다.

이상, 알고리즘 원고를 집필중이어서 일을 미루려는 핑계를 그럴듯하게 만든 프로그래머 박상현이었습니다. ㅋㄷ

호기심 천당

"공부를 해야하긴 하겠는데, 시간도 나지 않고 의욕도 별로 없어요."

어느 프로그래머에게서 들은 이야기입니다. "야근천국 칼퇴지옥"인 우리나라 SW 업계의 모든 종사자들이 겪는 현실일 것입니다. 그래도 어찌합니까, 우리는 계속 공부를 해야하는 사람들인데 말이지요. 시간이 없어도 해야 하고, 의욕이 없어도 해야 하는 것 또한 현실 아니겠습니까?

하지만 생각해 봅시다. 우리네는 사실 "호기심" 빼면 시체이던 인간들이잖아요. 돈도 상대적으로 적게 받고, 노동량과 스트레스는 삶에 충만하며, 정년마저 아주 짧은 SW 업계에서 그나마 버텨나가는 것도 '배운 게 도둑질 뿐'이라서가 아니라 '예전에 가졌던 그 즐거움'이 그리워서는 아닐까요?

전 거창한 공부 대신에 순간 순간 일어나는 호기심을 채워가며 사는 것을 제안합니다. Silverlight가 궁금합니까? 그럼 당장 MSDN 사이트에 들어가서 관련 동영상 세미나와 문서를 읽어보고, Orcas Beta2를 다운 받아 예제 코드를 만들어 보세요. UNIX에서 프로세스 프로파일링을 하고 싶으세요? top 소스를  다운받아 분석해 보세요.

이렇게 조금씩 한발 한발을 옮기다 보면 1년 후, 2년 후에는 재미있게 얻은 지식들이 한가득일 것입니다.또 이것이 제가 일해나가는 방법이기도 하고요. 다음은 E=MC^2 라는 책에서 읽은 글귀입니다. 아인슈타인이 남긴 말이예요.

"중요한 것은 질문을 멈추지 않는 것이다. 호기심은 그 자체만으로 존재할 이유가 있다. 누구라도 영원성과 생명과 놀라운 세상의 신비를 생각하면 경외심에 사로잡힐 수 밖에 없을 것이다. 그러한 신비를 매일 조금씩 이해하려고 노력하는 것만으로도 충분하다. 신성한 호기심을 잃지 말자."  - 알버트 아인슈타인.

Java Profiler 추천 받습니다~

드디어 팀장님께서 Java Profiler를 사주시겠다고 합니다.
디버깅이 한결 쉬워질 것 같습니다. ^^

그런데 혹시 어떤 Profiler가 쓸만한지 추천해주실 분 계세요?

프로그래머는 프로그래밍 실력이 모자라야 한다.

대개 저와 같은 직업을 갖고 있는 사람들은 자신을 "개발자"라고 표현하는 것을 좋아합니다만,
저는 "프로그래머"라는 표현을 즐겨 사용합니다.

물론 SW 개발은 프로그래밍 뿐 아니라, 고객과의 대화를 통한 요구사항 분석, 동료와의 커뮤니케이션, 비용 관리, 인력 관리 등등 다양한 활동을 포함하는 작업입니다. 제가 저를 프로그래머라 표현하는 것은 어찌보면 다른 활동보다도 컴퓨터와 깊이 대화하고자 하는 하나의 염원이라고도 할 수 있습니다.^^

그런 염원 때문인지는 몰라도 아주 가끔, 아니 어쩌면 꽤 자주 저는 스스로를 괜찮은 프로그래머라고 생각할 때가 있습니다. 이런 현상이 나타날 때는 딱 한 가지 경우입니다. 더 나은 도전을 맛보지 못할 때이지요.

최근에 나 스스로가 무력해 보이는 느낌을 가진 적이 언제인가, 지금 스스로 내 한계에 매일 부딪히고 있는가 등을 따져서 "도전 없는 후한 점수"를 나에게 주고 있다면 그것은 다 무의미한 것입니다. 대학생이 초등학교 3학년 수학시험에서 100점을 맞고 자랑스러워하는 것과 같은 것이지요.

초보가 초보인 것은 죄가 아니지만, 초보가 여전히 초보로 남는 것은 죄입니다. 발전을 하지 않는 것 자체도 문제이지만, "중고 초보"가 이 바닥 물을 흐리며 어지럽히는 것은 공연한 민폐이지요.

횡설수설. 아무튼 프로그래머는 모름지기 늘 자신이 모자람을 느낄 수 있는 도전을 가까이 해야겠다는 생각을 해 봅니다.

[퀴즈] 118 = 1979711488 ?

상현이는 최신 코어 2 듀오 CPU가 장착된 PC를 새로 구입한 기념으로 C# 프로그램을 하나 작성했습니다.

4바이트 짜리 int 데이터를 Java로 작성된 프로그램에 TCP/IP를 이용하여 보내는
간단한 프로그램('클라이언트'라고 합시다.)이지요. Java로 작성된 프로그램 역시
패킷을 받아 패킷에 담긴 데이터를 콘솔에 출력하기만 하는 단순한 프로그램('서버'라고
합시다.)이고요. 서버는 옛날에 구입한 센트리노 CPU가 장착된 노트북에 설치되었습니다.

상현이는 순식간에 코드를 작성해서 컴파일을 마쳤습니다. 그리고
클라이언트와 서버 프로그램을 띄우고 클라이언트에서 118(10진수)을 보냈습니다.

그런데 믿을 수 없는 일이, 아니 믿고 싶지 않은 일이 일어났습니다. 서버에서는
1979711488(10진수)를 출력한 것입니다.

무슨 일이 일어난 것일까요? (힌트: 118과 1979711488를 16진수로 바꿔 보세요)

닭이 먼저입니다.

오늘 문득 3년전에 하던 프로젝트가 생각났습니다. Kick Off 한지 3달이 지난 LCD 공장 CIM 프로젝트에 소방수로 잠깐 들어갔다가 약 10개월 정도 더 묵여있던 프로젝트입니다.

당시 제가 일하던 회사는 제품 개발 부서와 개발된 제품을 현장에 들고 나가서 엔지니어링을 하는 부서가 나뉘어져 있었습니다. 제품도 상당히 많고, 그 제품의 수만큼 엔지니어(주:개발자)들도 많았지요. 현장에서 일하는 엔지니어들은 고객과 대화하는 능력과 고수준의 개발 능력, 그리고 엄청난 체력을 필요로 했습니다.

그런데 그 프로젝트에는 하필, 우리 회사 엔지니어 수가 모자라서(PL급 1명) 상당 수의 외주 개발자들을 뽑아 써야 하는 상황이 되어 버렸습니다. CIM 분야에 대한 Domain Knowledge를 교육하고 제품을 엔지니어링하기 위한 각 기술을 익히는 데에만 최소 수개월이 걸리는데, 수준을 알 수 없는 개발자를 '일단' 선발해서 투입한 겁니다.
그래서 프로젝트가 설계단계부터 삐걱거리기 시작하고 제품 개발팀에 있던 제가 3~4주 지원을 하는 소방수로 선발된 것입니다.

아뿔싸, 한달만 지원하면 다시 돌아올 수 있을 거라 생각했던 것은 그야말로 '모르는 소리'였습니다. 3개월이 지났는데도 개발자들은 프로젝트를 하기 위한 기초 지식(LCD 공정, 개발에 필요한 메시지 버스 등)도 모르고 있었습니다. (제가 갔을 때는 뭔가를 열심히들 하고 있었지만 그게 뭐였는지는 지금도 모릅니다.)

한달이 지나자 '지원'을 하러갔던 저는 PL이 되어 설계와 스케줄링, 개발자들의 교육과 프로젝트의 진행 임무가 얹혀진 지게를 메게 되었습니다. 하루에 12시간만 더 있었으면 하는 생각을 가졌던 유일한 시기였습니다.

시간이 지나도 좀처럼 나아지지 않는 개발자들, 내가 들어가기 전에 파악했던 요구사항은 완전히 무용지물이었다는 사실(모든 요구사항과 프로세스를 새로 분석해야 했습니다.), 한번도 웹 유저 인터페이스 연동 경험이 없는 제품을 웹 인터페이스를 올려야 한다는 기술적 위험, 무엇보다 이 짐을 같이 지고 나갈 수 있는 사람이 없다는 외로움이 가슴을 짓눌러왔습니다.
( 더 황당한 사실은, 당시 저는 처음 접해본 Java, JSP를 3~4년차 사용했다고 하는 분들이 저한테 물어가며 개발을 했던 것입니다.)

다른 개발자들은 저녁 8시 반이나 9시면 집에 가야 한다고 짐을 싸는데, 저는 그럴 수 없었습니다. 하루 종일 설계만 해도 시간이 모자라는데, 개발자 교육에, 코드 검사(당하는 입장에서는 자존심 상하지만, 품질을 유지하기 위해선 필요합니다. 이 업무는 나중에 영입한 전문가께서 계속 해주셨습니다.), 또 제가 맡은 블럭의 개발을 해야했기 때문이죠.

집에 가면 12시~1시, 잠깐 눈붙이고 출근하기 위해 5시 반에 일어나 6시에 통근 버스를 탔습니다. 이 기간에 몸무게가 5Kg정도 빠졌습니다.

제가 프로젝트에 합류한지 한달 반이 지났을 무렵, 하던 일을 잠시 멈추고 커피 한잔 마시면서 프로젝트를 돌아봤습니다. 무엇이 문제일까, 그 문제를 고치면 더 나아질 수 있을까?
결론은 다음과 같았습니다.

1. 내가 소비하는 시간의 70%는 개발자의 교육과 코드 품질 관리에 소모된다.
  우리 회사의 엔지니어 두사람이면 이 시간을 완전히 절약할 수 있을 것이다.
  다행히 품질 관리는 곧 합류할 전문가가 담당해 줄 것이다.

2. 지난 한달 반동안 현재 같이 일하는 개발자들은 기술적으로도,
   대화 능력도 나아진 것이 없다.

문제는 데려올 본사 엔지니어가 없기 때문에 외주를 줬다는 것입니다. 그래서 저는 전방위 로비(?) 시작했습니다. 그 내용은 말씀드릴 수 없지만 갑측의 프로젝트 담당자 분과 우리 회사의 PM님으로 하여금 인력 교체를 결심하도록 말입니다.

프로젝트 기간의 2/5가 지나간 상황에서 도박과 다름 없는 결정이었지만, 결국 다섯 명을 내보내고 면접을 통해 다른 뛰어난 개발자 네 명을 영입하는 데 성공했습니다. 개발자 교육에는 1주일 정도가 걸렸습니다. 메시지 버스는 지지고 볶는 사이 이미 라이브러리로 만들어 놨기 때문에 특별한 교육이 필요 없었고, LCD 공정과 공장 자동화를 이해하는데 1주일 정도가 소요된 것이죠.

프로젝트는 빠른 속도로 예정된 스케줄을 따라 잡았고, 거짓말처럼 얼마 후에는 5시에 퇴근할 수 있었습니다. 조금 일이 있으면 7시에 퇴근했고요. 저는 시간이 남아서 클러스터링 되어 있는 OS, WAS, DBMS,그리고 우리 제품의 성능을 감시하는 TCP/IP 기반의 리소스 모니터를 처음 써본 Perl 언어로 개발했습니다. (프로젝트는 아주 좋은 케이스로 남아 갑의 담당자 분은 고과를 후하게 받았다는 후문입니다. 회사 입장에서는 프로젝트의 성공으로 유사 프로젝트를 여러 건 수주하게 됐고요.)

이야기는 이렇게 해피 엔딩으로 끝납니다.

소프트웨어 개발.. 1) 충분히 좋은 개발자를 2) 충분한 수로 확보하고, 3) 정확한 스케줄링(또는 이를 위한 노력)에 의해 이루어진다면 얼마든지 좋은 품질의 제품을 만들어 낼 수 있습니다.

쉽지 않은 일이지요? 하지만 저는 좋은 개발자 없는 회사가 성공한 곳을 본 적이 없고, 수퍼 개발자 혼자서 뭘 해낸 곳도 본적이 없습니다(잠깐의 성공을 이야기하는 것이 아닙니다. 고객에게 지속적으로 인정을 받는 것을 의미합니다.).

이야기를 써놓고 보니 달걀이 먼저냐, 닭이 먼저냐 하는 것인데 답은 간단합니다.
"닭이 먼저입니다."

공정이 제품을 만듭니다.

요즘 우리나라 소프트웨어 업계에서 "소프트웨어 품질"이라는 주제가 조금씩 이슈화 되고 있습니다. 이전에는 개념조차 없던 것이 이제는 "Good Software"라는 인증이 생기고 업체들도 해당 인증을 받기 위해 노력하는 곳이 많아졌습니다. 어느 정도 규모가 있는 회사에는 품질 관리(Quality Control)또는 품질 보증(Quailty Assurance) 부서를 운영하기 시작했습니다. 굉장히 고무적인 일이지요.

하지만 안타깝게도 이렇게 의욕적으로 품질에 공을 들이는 회사들도 소프트웨어 품질을 어떤 방법으로 향상시켜야 하는지에 대해서는 별 아이디어가 없는 것으로 보입니다. 컴파일러 옵션은 줄줄 꿰고 있어도 핸드폰의 간편 전화번호 검색 기능은 모르는 우리, 바로 소프트웨어 개발자들이 품질 개선의 주역이니 이해가 갈만 합니다.

우리 주위에는 이런 문제에 대해 경험을 가지거나 연구를 해온 선배가 없습니다. 300에 등장하는 스파르타 전사들이 갑옷도 없는 맨몸에 창과 방패 하나씩 들고 페르시안들과 싸웠던 것처럼 우리도 에디터와 컴파일러 하나로 수십년 동안 소프트웨어를 개발해 왔습니다. 버그가 적은 소프트웨어라는 말은 들어봤어도, 품질이 좋은 소프트웨어라는 말은 들어본 적이 없는 것이지요.

결국 우리가 품질을 위해 현재 할 수 있는 일은, 테스트 뿐입니다. 일단 소프트웨어의 개발을 마친 후에는테스트, 디버그, 테스트, 디버그 ... 의 사이클로 버그가 어느 수준 이상으로 발견되기 전까지 반복합니다. 그리고 테스트-디버그 사이클의 비용은 전체 소프트웨어 개발 비용의 40%에서 70%까지 차지하게 됩니다.

"원래 소프트웨어 품질 비용은 비싼거야."라고 넘길 수도 있지만, 이 정도로 많은 비용이 든다는 것은 큰 개선이 가능하다는 뜻도 됩니다.

제조업에서는 "수율(Yield)"이라는 개념이 있습니다. 투입한 자재대비 품질에 이상이 없는 제품을 얻는 비율을 말하는 것이지요. 수율이 높을 수록 낭비되는 비용이 적습니다. 특히 휴대폰과 같은 고부가가치 상품은 애써 만들어 놓은 제품이 출하전 검사 단계에서 불량 판정을 받아 폐기하거나 수리(또는 재작업)를 하는 비용이 만만치 않기 때문에 수율을 높이기 위한 노력을 엄청나게 기울입니다.

제조업에서는 제품을 내보내기 전의 품질 검사/감시 이상으로, 제품을 만드는 공정 내에서의 품질에 대한 감시를 중요하게 여기고 투자를 합니다. 각 생산 공정(Process)의 품질을 측정하고, 품질 저하의 원인을 공정에서 찾아내어 이를 개선합니다. 이렇게 개선된 공정 하나하나는 더 품질이 좋은 제품의 원동력이 되고 결국 원가 절감으로까지 이어집니다.

다시 눈을 돌려, 우리의 소프트웨어 공장을 봅시다. 우리가 만드는 소프트웨어는 그 어느 분야의 제품 못지않게 복잡하고 정교한데도, "공정" 따위는 없습니다. 우리 소프트웨어가 어떤 모습을 하고 있을지도 첫번째 컴파일이 끝나기 전까지는 알지 못합니다. 그 뿐인가요? 제조업에서 제품을 생산하는 것이 작업자의 "손"이라면, 소프트웨어업에서는 작업자의 "정신"이라 할 수 있는데, 많은 개발자들이 집중력이 떨어지는 근무환경에서 잠을 이겨가며 제품을 만들고 있습니다.

제품은 "공정"에서 나오는 것이지 "품질 감시"에 의해 만들어 지는 것은 아닙니다. 테스트 이전에 소프트웨어의 설계, 요구 사항 및 기능 정의, 작업자의 명확한 임무 정의, 일정 계획 등이 정상적으로 이루어지고 있는지를 점검해야 합니다. 지극히 상식적인 일이지만, 잘 지켜지지는 않지요. 마치 건강해지려면 담배를 끊고, 다이어트를 하고, 운동을 하고, 긍정적인 사고를 가지며, 브로컬리와 같은 녹화색 야채를 챙겨 먹어야 하지만 그 어느것 하나 생활에 반영하기가 어려운 것처럼, 이들도 그럴 것입니다.

하지만 한가지 확실한 사실은, 건강을 위한 노력을 하지 않으면 사소한 질병 때문에 대단한 의료비용을 지출하거나 죽을 수도 있다는 것입니다. 우리도 소프트웨어 개발 공정에 대한 개선을 시작하지 않는다면, 언제 죽을지 모르는 일입니다.

성공이냐/실패냐의 결과만을 판정하기 전에, 실패하지 않도록 최선을 기울여야 합니다.

"공정이 제품을 만듭니다."

Wanted : .NET Windows Forms Developer

개발자를 구합니다. 하게 될 업무는 C#으로 .NET Windows Forms 어플리케이션을 작성하는 일입니다. 구체적으로 다음 요건을 갖추었다면 당신은 적격자입니다.

1. C# 언어에 능숙하며, OOD/OOP에 대한 이해가 깊다.
2. 커스텀 컨트롤 코딩이 가능하다.
3. 분산 객체 컴퓨팅 경험이 있다.(CORBA, Web Service, .NET Remoting 등)
4. 데이터베이스 프로그래밍에 능하다.
5. SCSF & CAB 에 대한 경험이 있다.(옵션)
6. 자신이 하고 있는 일을 영어로 문서화가 가능하다.(옵션)

제가 예전에 근무하던 회사(www.aim.co.kr)에서 사람을 구한다고 합니다. 국내 회사이긴 합니다만, 일하는 분위기는 외국계 회사에 못지 않습니다. 선진 업무 프로세스와 공장 자동화 분야에서 세계 최고의 역량을 갖춘 인재들과 함께 일할 수 있는 기회를 얻고 싶은 분들은 지원해 보시기 바랍니다.

저에게 이력서를 이메일(steelblue@nate.com)으로 보내주시면 제가 소개를 해드리겠습니다.
(그 회사에서 소개비를 받는다든가 하는 것은 전혀 없으니 오해는 없으시길 ^^)

프로그래밍 언어와 컴퓨터의 발달(링크)

예전에 올렸던 포스트를 기반으로 해서 IYF(International Youth Fellowship) 회지의 지난 봄호에 기고한 글입니다. 심심하신 분들은 한번 읽어보세요.

http://www.iyf.or.kr/IYFmagazine/mag22/_2k7.spr.IT%EC%9D%B4%EC%95%BC%EA%B8%B0_1.pdf

이번 여름 호에도 글을 보내야 하는데, 일이 많아 걱정입니다. ^^;

(예고)정렬 이야기

정렬과 탐색은 프로그램에서 가장 많이 사용하는 알고리즘들 중 하나입니다.
누구나 다 생각하는 단순한 정렬 알고리즘부터 컴퓨터 과학자들이 개발한
성능이 뛰어난 정렬 알고리즘까지 쭉 훑어볼 계획입니다.

항상 해야지, 해야지 마음만 먹고 있다가 이렇게 글을 올려 공포(?)를 합니다.
이렇게 해서 제 자신을 재촉하는 것이지요.

글도 올라오지 않는 제 블로그에 항상 관심을 가져 주셔서 죄송하고, 감사합니다.
꾸벅~ (__)(--)

Never try, never fail.

예전에 <The Robot>이라는 애니메이션을 본 적이 있습니다. 수학적인 기법을 잘 활용해서
짠 곳곳의 장면들이 인상적이었죠. <The Robot>에서는 로봇들도 인간처럼 "태어나기도 하고", "죽기도" 합니다. 병들기도 하고, 집과 먹을 것을 필요로 합니다.

그곳에는 "가난"도 있고 "악당"도 있습니다. 그리고 "영웅"과 그의 친구들이 있지요.
자세한 내용은 영화를 보지 않으신 분들 때문에 더 이야기 하지 않겠습니다. 주인공이 악당에 맞서 싸우려 할 때, 그 친구중의 하나가 주인공을 말리며 이렇게 이야기 합니다.

"Never try, Never fail."

시도도 하지 말고, 실패도 하지 말자는 것이죠. 만약 이 친구의 말대로 스토리가 전개됐다면
영화의 끝은 비극이었겠죠? 주인공은 이 친구도 설득해서 악당과 싸우고, 결국 물리칩니다.

작년에 저희 교회 목사님께서 하신 말씀이 생각납니다.

"하나님께서 왜 메뚜기를 정하다 하셨는지 아느냐? 메뚜기는 자유롭게 비행할 수는 없지만, 뛸 수 있는 다리를 갖고 있다. 어디로 떨어질지 모르지만, 메뚜기는 뛰어 오른다. 그것을 하나님께서 정하다고 하셨다. 메뚜기는 풀 위에 떨어질지, 도로 위에 떨어질지, 물 위에 떨어질지, 결과는 모르지만 뛰어 오른다."

저도 가끔 갈 길이 멀어 보이거나 목표가 너무 멀어 보이면 속에서 "Never try, never fail"이라는 속삭임이 들려옵니다. 하지만 지금까지 걸어온 길을 생각해보면 절대 그럴 수 없겠다는 마음을 다시금 먹게 됩니다. 저도 나비나 잠자리처럼 멋진 날개를 가지진 못헀지만, 메뚜기처럼 힘껏 뛰렵니다. 어디에 떨어지든, 그렇게 살도록 내 인생이 되어 있다면 뛰어야지요.

"Try. Faith never fails."

비스타, 비스타!

요즘 비스타 때문에 난리도 아닙니다.

신문에선 연일 비스타 관련 기사가 오르고 있고, 전자 매장엔 비스타를 설치한 PC들이 즐비합니다. 데브피아에 가보니 .NET Framework 3.0를 열심히 공부하는 개발자도 상당히 많네요. 각 소프트웨어 업체들은 비스타에 대응할 버전을 준비하느라 분주합니다. 당장은 비스타와 호환되는 버전을 내놓겠지만, 6개월~1년 정도 후면 비스타의 강력한 기능을 적극 활용한 소프트웨어들이 쏟아져 나올 것입니다.

예전의 윈도우 95에서와는 달리, 많은 업체에서 다양한 제품들을 빠른 속도로 출시할 것으로 예상됩니다. 열악한 개발 도구만을 가지고 있었던 과거와는 달리 .NET Framework 3.0이라는 걸출한 API 세트와 VS, Delphi 등을 비롯한 화려한 개발 도구들이 준비되어 있기 때문입니다.

여기서 잠시 생각해 봅시다.
그렇다면 지금 우리가 해야 하는 공부는 무엇일까요? 비스타처럼 나날이 쏟아지는 신기술을 어떻게 받아들여야 하는 것일까요? C# 언어와 C++ 언어를 제대로 구사하도록 하는 것도 쉽지 않은데, 신기술들은 또 언제 익혀야 할까요?

과학은 건물을 세울 때 필요한 암반과 같은 것이고, 기술은 건물과 같은 것입니다. 암반은 튼튼하게 어떤 건물이든 세워질 수 있도록 하지만, 건물은 오래되면 해체해서 새로 짓곤 합니다.

암반도 중요하고, 건물도 중요합니다. 우리나라의 태극기를 보면, 가운데에 음과 양의 기운이 서로 조화를 이루는 태극 문양이 보입니다. 빛과 어두움이 어우러지듯, 과학과 기술 역시 개발자에게 융합되어 있어야 합니다. (이는 "C# 2.0 프로그래밍"과 "VC+ 2005 프로그래밍"이 지향하는 바이기도 합니다.)

뭐, 결국 둘 다 필요하다는 이야깁니다. 너무 피곤하지요? 기술은 과학을 기초로 해서 맺어지는 열매와 같은 것입니다. 즉, 내가 프로그래머로써의 기초를 단단히 하고 있다면 새로 쏟아지는 기술도 어렵지 않게 소화할 수 있다는 이야깁니다. 프로그래밍 언어, 파일 처리, 알고리즘, 데이터 베이스 등은 과학입니다. COM, ActiveX, WCF, WPF 등은 기술이라고 할 수 있지요.

쏟아지는 기술들에 당황하지 말고 차근차근 현재 하고 있는 공부를 하시기 바랍니다. 여러분이 기초를 잘 닦고 나면, 어떤 기술이든 두렴없이 받아들일 수 있게 될 것입니다.

어느 학생의 질문을 받았는데, 많은 분들이 같은 고민을 하시리라는 생각에 이렇게 포스트로 답변을 합니다. 도움이 되셨기를...

Hasta la vista~

스티브 잡스와 애플, 그리고 MS

요 몇 달동안 iPhone 때문에 IT 업계가 시끌시끌했습니다. iMac, iPod의 성공의 후광을 입고 있기에 iPhone에 대한 기대가 엄청나게 커졌기 때문이지요. 결국 몇 일 전에 iPhone이 그 모습을 드러냈습니다.

뉴스를 통해 특징을 정리해본 결과, iPod를 담은 PDA 전화기라는 판단을 했습니다. 이런 물건때문에 사람들을 그렇게 기다리게 헀나 싶기도 해서 조금 허탈해지기도 헀습니다. 하지만 그 디자인만큼은 상당히 산뜻했는데(할 뻔했는데), 그마저 LG의 프라다 폰을 베낀게 아니냐는 의혹을 받고 있습니다.

야구에서 타자가 3할 정도를 치면 아주 잘한다고 할 수 있습니다. 투수가 던지는 공 10개 중 3개를 안타로 만들기만 해도 우수한 선수가 되는데, 스티브 잡스는 NeXT와 같은 뼈저린 실패를 경험하기도 했지만, 상당히 우수한 타율을 자랑하고 있습니다. 그것도 아주 대형 홈런으로 말이죠. 이번에도 iPhone을 가지고 iPod처럼 만루홈런을 만들어낼 수 있을지 귀추가 주목됩니다.

잡스가 자신이 창업한 애플에서 몇년 쫓겨나 있긴 했어도, 그는 애플의 아이콘과 같은 존재입니다. 청바지를 입고 신제품 런칭 쇼를 하는 스티브 잡스가 없는 애플은 상상할 수 없습니다. 그런 점에서 MS의 변화는 아주 주목할만 합니다.

소프트웨어 업계의 제왕으로 군림하고 있는 MS는, 자사의 아이콘이라 할 수 있는 빌 게이츠를 많이 지워내고 있습니다. 이미 유능한 후계자 후보가 MS에서 활약하고 있고, 그의 친구이자 現 회장인 스티브 발머가 MS를 앞에서 이끌고 있습니다. 빌 게이츠는 현재 기술 부문만을 이끌고 있고 몇 년 후엔 은퇴할 것임을 공식적으로 발표하기도 했습니다.

놀랍게도 MS가 내놓고 있는 주요 제품들은 개발 과정에서 빌게이츠의 반대를 무릅쓴 아이디어들을 채택하고 있습니다. 대표적인 것이 바로 인터넷 익스플로러입니다. 넷스케이프가 전 세계 웹 브라우저를 거의 독점하고 있다시피 했을 때, MS는 인터넷 시대의 사업에 대해 준비되어 있는 것이 없었습니다. 이미 인터넷 시대가 도래했음을 깨달았을 때는 시간이 많이 흐른 뒤였죠. 그런데 그 때 이미 회사 몰래 인터넷 응용 프로그램을 준비해오던 이들이 있었고, 이들에 의해 인터넷 익스플로러가 탄생합니다. 지금은 넷스케이프 웹 브라우저는 찾아보기가 어렵죠.
그 외에도 Xbox 게임기에서 윈도우를 제거한 일이나, 쥰 Mp3 플레이어를 내놓는 일 등을 보면 MS는 포스트 빌게이츠들이 준비되어 있는 것으로 보입니다.

제가 하고 싶은 이야기는 애플이 향후 몇년 동안 현재와 같은 비즈니스를 이어갈 수 있을 것인가 하는 점입니다. 스티브 잡스가 또 홈런을 만들어 낼 수 있을까요? 설령 만들어 낸다 하더라도 그 다음 타석에서 NeXT와 같은 끔찍한 실패를 저지르지 않을 수 있을까요?

iPhone을 보면서 든 생각이었습니다.


즐프하세요~

프로그래밍의 역사

섭씨 50도의 열과 소음이 가득 채운 커다란 방에서, 한 여자 연구원이 노트를 들고 30 미터에 이르는 방 한 면을 가득 메운 상자들에 꽂혀 있는 전기 케이블의 배선을 바꾸고 있었다. 노트에는 대포의 탄도 계산에 필요한 방정식이 기록되어 있고, 연구원은 그 노트에 따라 꼼꼼하게 케이블을 점검해 나갔다. 6000개에 이르는 전기 케이블을 점검한 후, 계산에 사용할 실험 수치가 기록된 카드들을 기계에 밀어 넣고 스위치를 올렸다. 잠시 후 한쪽에 설치된 천공기(punching machine)가 계산 결과를 카드에 출력했다.

이 광경은 최초의 컴퓨터, 에니악(ENIAC)을 운용하던 모습이다.  한 쪽 벽면을 가득 메우고 있던 상자들은 에니악(ENIAC)이었고 전기 배선은 에니악(ENIAC)이 계산할 때 사용하는 "논리"로써, 현대의 컴퓨터로 치자면 "프로그램"이었다. "프로그래밍"이 프로그램을 제작하는 일을 뜻하니, 연구원이 전기 배선을 하던 그 모습은 바로 프로그래밍이었다고 할 수 있다.

에니악은 당시 엄청난 계산 능력을 갖고 있었지만(286 PC와 비슷했다.), 단점 또한 그 덩치만큼이나 대단했다. 진공관 발열 문제로 인해 거의 매일 반나절은 운영을 멈춰야 했고,  무엇보다 프로그램을 변경하려면 6000개에 이르는 배선을 교체해야 했다. 이후에 이 괴물은 맨해튼 프로젝트에도 참여했던 천재 과학자 존 폰 노이만(John von Neumann)의 마법을 거쳐 조금 더 신뢰성 있는 컴퓨터인 에드박(EDVAC)을 탄생하게 했고, 에드박은 중앙 프로세서, 기억장치, 프로그램, 데이터로 구성된 현대 컴퓨터의 구조를 갖춘 현대 컴퓨터의 조상이 되었다.

노이만 이후 컴퓨터의 발전은 가속도를 더해갔으며, 프로그래밍 방식 또한 컴퓨터의 발전에 발맞춰 나아가게 됐다. 전선으로 구성됐던 프로그램이 이제 거대한 방에서 조그만 상자로 그 "장소"를 옮기게  된 것이다. 
트랜지스터와 이 트랜지스터를 하나의 칩에 집적한 마이크로칩이 개발되면서 컴퓨터는 운영 체제와 기본적인 프로그램, 그리고 명령어들을 자체 내장했다. 그리고 프로그래머는 CPU가 제공하는 기본적인 명령어를 조합하여 보다 효율적인 방법으로 프로그램을 작성할 수 있었다.

이 명령어들이 바로 어셈블리어이다. 프로그래머가 어셈블리어를 이용하여 프로그램 원천 코드를 작성하면,  컴파일러(Compiler)라는 소프트웨어를 이용하여 실행 파일을 만들어 냈다. 그리고 이 실행 파일이 바로 프로그램이었다.

컴퓨터가 보급되면서, 사람들은 보다 많은 업무들을 컴퓨터에 맡기고자 했다. 그러나 필요한 프로그램들은 늘어나는데, 기호와도 다름없는 어셈블리어로는 그 속도를 맞춰나갈 수 없었다. 예를 들어 5+1 식을 계산하는 코드는 어셈블리어로 하면 다음과 같다. (이해하지 못해도 좋다. 아니, 여러분이 이해 못한다면 필자가 아래의 코드를 보여주고자 한 의도가 성공한 것이다.)

data
var1 DWORD 1
var2 DWORD 5
.code
mov eax, var1
add eax, var2 ;

(위 코드는 물론, 그 때 당시에 사용하던 코드는 아니다. 이것은 현재 우리가 많이 사용하고 있는 인텔 계열의 80X86 CPU에서 동작하는 코드이며, 50년 전에 사용되던 코드 샘플은 필자는 안타깝게도 구할 수 없었다.)
프로그래밍 언어가 이렇게 어렵게 생겼으니, 프로그래밍은 전문 과학자나 아주 똑똑한 사람들의 전유물이었다. 하지만 존 배커스(John Backus) 때문이 상황이 달라졌다. 그는 수많은 학교에서 퇴학당한 문제아였지만, 좋은 스승을 만나 컬럼비아 대학을 마치고, 이후 IBM에 입사하게 된다. IBM에 입사하면서 그는 IBM에서 개발이 진행 중이던 일종의 어셈블리어 번역기인 스피드 코딩(Speed Coding) 프로젝트에 참여하고, 이 경험을 기반으로 1957년에는 사람의 언어에 가까운 최초의 프로그래밍 언어, 포트란(Fortran) 언어와 컴파일러를 개발했다. 포트란은 연구소와 과학 기술자를 중심으로 엄청난 인기를 얻어 나갔다. 어떻게 인기를 얻었냐고? 잠시 후에 알게 된다.

포트란 언어의 덧셈 코드는 다음과 같다.

a = 5 + 1

어셈블리 코드와 비교해 보라. 이 이상 단순해질 수 없을 정도로 단순해졌다. 프로그래밍 코드답게 생긴 것은 앞에서 선보인 어셈블리어 쪽이지만, 이해하기에는 포트란 쪽이 어셈블리어보다 100배는 더 낫다. 우리가 수학 시간에 배운 덧셈과 등가 기호만으로 덧셈 연산이 가능하지 않은가?

포트란 이후, 1천여가지가 넘는 프로그래밍 언어들이 수 없이 탄생하고 사라져갔다. 그러던 중 1964년, 베이직(BASIC : Beginner's All - Purpose Symbolic Instruction Code) 언어가 미국 다트머스 대학의 존 케머니(John Kemeny)와 토마스 쿠르츠(Thomas Kurtz) 교수에 의해 탄생됐다. 이들은 컴퓨터 프로그래밍이 더 이상 과학자나 엔지니어의 전유물로 남지 않길 바랬다. 그래서 학생부터 청소부까지 누구라도 배워 사용할 수 있는 언어를 고안해 냈고, 그것이 바로 베이직이다.

이 베이직 언어는 너무 사용하기 쉬웠기 때문에 수많은 컴퓨터 광들을 프로그래밍의 세계로 끌어들일 수 있었다. 레이크사이드 스쿨에 다니던 앳된 중학생 빌 게이츠(Bill Gates)와 폴 앨런(Paul Allen)도 예외는 아니었다. 당시 컴퓨터는 엄청나게 비싼 기계였지만, 레이크사이드 스쿨은 재정적으로 풍부한 사립 학교였고, 어머니회의 후원으로 컴퓨터와 터미널을 보유할 수 있었다. 게이츠와 그의 친구들은 그야말로 하루종일 베이직 프로그래밍에 빠져들었다. 빌 게이츠는 학교를 졸업하고 하버드에 진학하지만, 얼마가지 않아 중퇴하고 마이크로소프트를 창업한다(많은 사람들이 빌 게이츠가 공부에 염증을 느꼈다고 생각하지만, 그것은 사실이 아닌 것으로 보인다. 그저 앞으로 도래할 미래가 뻔히 보이는 상황에서 기회를 놓치고 싶지 않았기 때문에 학교를 포기했던 것이다.). 그리고 마이크로소프트의 첫 번째 제품이 바로 베이직 인터프리터(BASIC Interpreter)였다.

컴파일러와 인터프리터

앞서 어셈블리 언어와 포트란 언어에서는 "컴파일러"라는 단어를 사용했고, 베이직 언어에서는 "인터프리터"라는 단어를 사용했다. 프로그래밍 언어에는 크게 두 가지 종류가 존재한다. 하나는 소스 코드에서 실행 파일로 변환하는 과정을 거치는 컴파일 방식의 언어이고, 또 다른 하나는 소스 코드를 실시간으로 읽어 해석하여 프로그램을 실행하는 방식의 인터프리트 방식의 언어이다.  컴파일 언어의 장점은 작고 효율적인 실행 파일의 생성에 있고, 인터프린트 언어의 장점은 소스 코드를 작성해서 바로 실행해 볼 수 있기 때문에 프로그램 개발이 용이하다는 데 있다.

마이크로소프트의 베이직은 IBM이 개발한 PC(그렇다. 우리가 사용하고 있는 그 PC)에도 이식되었고, PC의 수많은 응용 프로그램을 탄생시킬 수 있도록 했다. 이 베이직 언어는 이후에도 마이크로소프트가 윈도우를 출시 했을 때 비주얼 베이직(Visual Basic)으로 새롭게 거듭나면서 윈도우 응용프로그램을 보급하는 일등 공신이 된다.

* 이 포스트에는 오류가 있을 수 있으며, 추후 고증 검증 절차에 의해 변경될 수 있습니다.
* 제 블로그의 글들은 모두 저작권의 보호를 받습니다. 무단 복사 및 전제를 금합니다.