My Turning Point

-------------------------------------------------------------------
1. 어떤 언어를 사용하느냐 하는 것은 중요한 것이 아닙니다.
------------------------------------------------------------------
문제 위주로 생각하는 버릇을 키워야 합니다.
많은 프로그래머들이 자신이 당면한 문제를 정확하게 이해하는 경우가 매우 드뭅니다.
일단 언어와 개발환경에 익숙해지면 다른 사고와 접근 방식을 요구하는
문제 해결에는 속수무책인 경우가 많습니다.
이것도 일종의 문화이기 때문이겠죠.

C/C++을 배우려고도 하지 않고, 시스템 프로그래밍을 하지 못하는 대다
수의 프로그래머를 실력이 없거나, 한계를 갖는 프로그래머로 매도하는
경향이 일부 있는데 이는 바람직하지 않다고 봅니다.

2000년 문제를 해결해야 할 대다수의 프로그래머는 C/C++나 어셈블리어
를 사용하는 사람보다는 코볼을 사용하는 프로그래머입니다.
그들에 대한 수요가 절대적인 이유는 문제가 그것을 주로 사용하는
시스템에서 빚어지기 때문입니다.
(메인프레임의 MIS/뱅킹/.... 관련 프로그램들은 거의 코볼로 작성되었다고 보면 됩니다)

특정 환경에 맞는 특정 언어가 존재하며, 어떤 언어를 선택하느냐 하는
것은 프로그래머의 마음이나 능력 이 아닙니다.
실제로는 문제가 결정하며, 궁극적으로는 시장이 결정합니다.

만약 비디오 대여점에 맞는 프로그램을 짠다고 가정합시다. 비주얼 베이
직으로 하는 것이 Visual C++프로그래밍보다는
훨씬 경제적이다는 것은 누구나 다 아는 일일 것입니다.

저는 개인적으로 두 툴을 다 사용하고 Visual C++을 더 좋아하지만
(이것은 완전히 개인적인 기호입니다), 유사시에는 두개의 툴을 동시에 사용합니다.
그리고 C/S 환경에서 프로그래밍을 즐겨 짭니다.

네트워크 프로그래밍을 할 경우, 서버 소프트웨어를 짜는 과정에서 분석
된 도큐먼트 하에서 프로그래밍을 하더라도,
클라이언트 운용환경 하에서 테스트를 해야 할 필요성을 느낍니다.

NT환경하에서, 서버 소트프트웨어는 Unix의 데몬과 같은 Service형태로
돌아가고 네트워크 퍼포먼스와 과부하를 견딜 수 있는 소프트웨어를 짜야만 한다고
가정합시다. 그러면 선택의 여지는 별로 없습니다. C++이죠.
그러나, 아직 클라이언트 소프트웨어는 만들어지지도 않았기 때문에, 여
러가지 내가 만든 소프트웨어의 잠재적 위험성은 상당히 높다고 보아야 합니다.

이 경우 아주 빨리 클라이언트 프로토타입을 만드는 도구를 선택한다면
비주얼 베이직이 될 것입니다.
소켓 프로그래밍에서부터, 데이터베이스 프로그래밍에 이르기까지 아주
빨리 아주 편리하게 클라이언트의 프로토타입을 남몰래
(도큐먼트에 없는 비공식 테스트용으로) 만들어 테스트를 해 나갈 수 있죠.

이 경우 제거되는 소프트웨 어의 비효율성이나, 문제점은 상당하며 개발
속도 및 디버깅 속도를 향상시켜 줍니다.
저는 실제로 비주얼 베이직을 프로토타입 작성용으로 즐겨 사용하고 있습니다.
(때로는 실제 클라이언트 릴리지 버전 제작용으로도 사용하죠)
사실 비주얼 베이직 그 자체로도 훌륭한 도구입니다.

만약 비주얼 베이직이 문제가 된다면, 그 환경이 비주얼 베이직으로 해결
되지 않거나, 반대급부가 너무 큰 경우이겠지요....
어떤 도구를 사용할 것인가에 너무 집착하면 문제를 잘못볼 수가 있습니다.

어떤 도구도 완벽한 것은 없기 때문에 어떤 환경/문제에 어떤 도구가 적
합한지를 판단할 수 있는 훈련을 하는 것이 바람직합니다.

--------------------------------------------------------------------
2. 아키텍처를 이해하십시오.
---------------------------------------------------------------------

종종 프로그래밍을 시작하는 사람들은 그 언어 사용법이나, 도구가 제공
하는 환경(IDE같은)을 이해하는 데에 많은 시간을 할애하는 것을 봅니다.
그러나, 이보다 더 큰 문제는 마치 이것을 전부인 것처럼 생각하는 것입니다.

프로그래밍을 한다는 것이 반드시 무에서 유를 창조하는 것만은 아닙니다.
오히려 그런 경우는 아주 소수이지요.
여러분이 아키텍처를 발표한다든지, 운영체제를 만든다든지 하는 일은 연구소나,
학계에서 일하지 않는 한 거의 없을 것입니다.

만약 여러분들이 협애한 생각으로 프로그래밍을 한다면, C/C++만 가지
고 할 수 있는 일은 거의 없을 것입니다.

널리 수행되는 데이터베이스 프로그래밍을 하는 것은 C/C++을 알면 도움
이 되긴 하지만, 사실 그 자체와는 아무런관련이 없습니다.

오히려 SQL과 데이터베이스 커넥션(네트워크)에 대해 알아야 할 것입니다.
때로는 Embeded SQL이나, ODBC에 대해 알아야 할 것입니다.


C/C++프로그래밍을 한 사람이 네트워크 프로그래밍을 하지 못한다면,
그 사람은 아마 네트워크 아키텍처에 대해 잘 모르기 때문이지
실력이 없어서는 아닐 것입니다.

(네트워크 분야라 할지라도, IPX/SPX 프로그램밍, RPC 프로그래밍,
TCP/IP 소켓 프로그래밍 등등 여럿이 있으니까요...)

때로는 표준이기도 하거나, 때로는 완성되지 않은 아키텍처이기도 하겠
지만, 하나의 아키텍처를 얼마나 신속하고 빨리 이해할 수 있느냐 하는 것이
매우 중요합니다. 사실 제가 경험한 신입사원들은 사용언어보다는 아키텍처를
이해하는데에 더 많은 시간과 노력을 투자해야 한다는 것을 뼈저리게 처험했습니다.

개발경력이라고는 전혀 없는 신입사원들이 수행했던 프로젝트는 광파일
시스템이었는데 이해하여야 할 아키텍처가 상당했거든요...
(이미지 프로세싱, TCP/IP네트워크 프로그래밍, C/S, RDBMS 등등 선너머 산이었죠.)

이렇게 닥달을 당하고 훈련되니까, 3개월만에 자연스럽게 잘 하더라구
요..... 심지어, 그 중에 한 친구는 비주얼 베이 갖구 win32프로그램을 하더라구요
(물론 약간 제한적이기는 하지만).

그들은 지금도 서슴없이 이야기하죠. 뭐 언어는 중요한게 아니라구요.
아키텍처가 중요하다구요. 농담삼아 야한 이야기를 할 때도
"허리아래 아키텍처"에 대해 논해보자구 할 정도의 노이로제 증상을 보이
는 정도랍니다.

C++을 배우기 위해서, Visual C++을 공부하는 사람에게 저는
종종 다음과 같은 이야기를 하지요...
먼저 죽어두 MFC프로그램밍으로 시작하지 말라구요....

MFC는 사실 아주 숙련된 C++프로그래머 (OOP입장에서 볼때 능숙한 C프로그래머가 아니라)
와 능숙한 Win32프로그래머를 위한 것이에요. <<<이것은 마이크로소프트의 도큐먼트에도 나
와있 는 이야기입니다.>>>

윈32 아키텍처를 이해하지 못하는 대부분의 초보 프로그래머, 더군더나
여기에 C++ 아키텍처도 잘 모르는 프로그래머가 위저드의 도움으로 프로그래밍을
작성했을 경우 자신의 코드를 이해하는 데 걸리는 시간은 윈32 아키텍처와
C++아키텍처를 이해하고 다시 MFC를 공부하고 프로그램을 짜는 데 걸리
는 시간보다 더 길다는 것을 사람들은 이해 하지 못합니다.

전체로서의 구조화된 아키텍처를 이해하고 숙달되려고 노력하는 지난한
과정이 필요합니다. 윈도우 프로그래밍을 배우려 한다면, 한번쯤
(당장은 아니더라도 머릿속에 항상 기억하십시오) Win32 아키텍처를 이해하도록
노력하여야 합니다.

인터넷 프로그래밍을 하고싶다면(혹시 C/C++을 사용해서), RFC 도큐먼트를
조해야만 하는 경우가 생깁니다.
WEB이 강력하고 저도 자유롭게 즐겨쓰는 프로토콜과 환경을 제공해주지만,
때로는 인터넷으로 메일을 보내고 소켓을 바로 열어 다른 형태의 프로토콜로
대화를 해야할 필요도 있으니까요.

이렇듯 여러분이 앞에 있는 것은 사용법이나, 도구와 관련된 문제가 아니
라, 아키텍처의 이해와 적용에 관한 문제가 아닐까 합니다.

참고 : MFC프로그래밍은 단순히 User와 GDI서비스를 적절하게(?) 클래
스 라이브러리화한 것에 지나지 않습니다.
(스레드, ISAPI나 소켓 등 일부는 예외). 커널 서비스와 관련된 작업은
전적으로 당신의 몫입니다.)

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

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